EMBEDDED SOFTWARE MEDICAL
passed, the code implements this
requirement.
However, if this assignment has
been made in an appropriate tool, it
is possible to determine, with the aid
of the tool, whether all requirements
are linked to test cases and whether
these have been passed.
TESSY is a unit test tool
(see Figure 2) that can manage
requirements and their relationship
to test cases.
The goal is a completely filled
green circle, indicating that all
requirements are linked to test
cases and that all of these test
cases have been executed and
passed.
Acceptance criterion
“interface design”
Is the software code without
contradictions to the interface design
of the software unit? TESSY can
determine the interface of a software
unit from the software code and
display it in human readable form in
its GUI and reports, and additionally
in machine readable form (XML).
This can be used to check whether
the software code of the software
unit contains contradictions to the
interface design of the software unit.
The passing direction IN (Figure
3) indicates that the variable is only
read by the software unit, and as a
consequence, an input value must
be specified for this variable prior
to the test. The passing direction
OUT requires for a proper test
an expected value, which is then
compared with the actual value after
the test.
If the interface description
as result of the detailed design
exists in machine-readable form,
it might be feasible to automate
the comparison of the expected
interface (from the design) with the
actual interface (from the code) by
utilising the machine-readable format
(XML) that TESSY creates. This
would reveal contradictions of the
implemented design to the intended
design. Without effortless automated
comparison, manual review/
inspection is needed.
“Procedures and coding standards”
Does the software code conform to
programming procedures and coding
standards? IEC 62304 recommends
using coding standards in order to
consistently achieve the desirable
code characteristics.
Examples of coding standards
include (a) requirements for
understand-ability, (b) language usage
rules or restrictions on the use, and
(c) complexity management.
Requirements for understandability
of the code are usually
satisfied by application of a
programming style guide. Stylistic
rules usually concern aspects like
naming (e.g. CamelCaseNotation,
underscores in identifiers),
indentation, the setting of the curly
braces, and more.
Other sets of guidelines do
restrict the language, trying to
prevent undefined, unspecified, or
implementation-defined language
constructs. As a result unintended
behaviour of the software (e.g. a
crash) can be avoided. Examples for
guidelines which restrict the language
are in the MISRA guidelines.
To manage complexity certain
metrics should not exceed certain
values. For example, the Lines-of-
Code (LOC) metric, which indicates
the number of lines in a software unit,
prevents larger software units. One
metric that is often used to measure
complexity is McCabe’s cyclomatic
complexity. This metric is based on
the control flow graph of the software
unit and indicates the number of
complete, linearly independent
paths through it. This is also the
number of binary decisions plus one
in a software unit. Unfortunately,
this metric does not consider
calculations or compound decisions,
so you get surprisingly low values for
large calculations and complicated
decisions.
Figure 4 shows the cyclomatic
complexity for software units in the
TESSY tool. The value for nine units is
shown in the CC column. The values
are highlighted in colour: If the value
is highlighted in green, it is lower than
the threshold value for a warning,
which in the present example is set
to the value 10; values highlighted in
red are greater than or equal to the
threshold value for an error, which
in the present example is set to the
value 20; values highlighted in yellow
are between the two thresholds.
Further acceptance criteria
IEC 62304 specifies further
acceptance criteria for class C
software, for example related to
data and control flow or related to
boundary values in test cases.
The manufacturer must assign
a security class to the software
system. Class A software poses no
unacceptable risk to people; class B
software can cause non-serious injury;
and class C software can cause
death.
Figure 3: Interface
of the software
unit “func”
Figure 4: The
cyclomatic
complexity for
some software
units in TESSY
www.newelectronics.co.uk 23 February 2021 23
/www.newelectronics.co.uk