The term software unit is defined in IEC 62304.
Many manufacturers experience difficulties when specifying and testing these software units. This article gives you tips on how to avoid them.
Definition
Definition of a software unit
IEC 62304 defines a software unit as “software item that is not subdivided into other items”.
Definition of software item
A software item is defined by the standard as “any identifiable part of a computer program”. A software component or software unit can be a logical component as well as a physical component.
Definition of a software system
Finally, a software system is an “integrated collection of software items organized to accomplish a specific function or set of functions”.
The standard does not define what manufacturers shall define as a software system: they can either define the entire software of a medical device as a software system or all software in each processor or memory area. This means that a medical device can have several software systems, meaning at least one per PESS (programmable electronic sub-system).
The video training courses in the Medical Device University describe how to design and document an architecture efficiently and in compliance with IEC 62304 and the FDA, as well as the regulatory requirements.
Logical software units
It is up to the manufacturer to decide when a software component should no longer be decomposed into separate entities. This means that the software unit does not have to be a class in an object-oriented language, for example. It would also be possible to define a package or an assembly as a unit. Consequently, components are identified in component or class diagrams.
Physical software units
Some manufacturers, however, especially where the development of an explicit architecture is not considered a self-evident requirement, refer to the identifiable parts of the compiled software as software units or components, i.e. *.exe, *.dll or *.HEX files. The appropriate UML diagram type would be the deployment diagram. However, because these manufacturers assume that components must be represented with a component diagram, they “misuse” component diagrams to describe distribution aspects.
IEC 62304 allows both perspectives. However, it certainly does not accept an entirely “retrospective description” of software units and software components.
Granularity of software units
Furthermore, it is helpful to understand that the granularity can be determined differently in different components. This means that software units can be found on different levels of a layer-oriented architecture, as shown in the following figure, which marks the software units with a red frame.
Alternative visualization
It is important to note that a software unit is defined as a component that is not further decomposed, not as a component that cannot be further decomposed.
Regulatory requirements
Specify software units
At least for safety class C, IEC 62304 requires the software system to be decomposed into units as part of the software architecture or detailed design. This means
- You need to identify the software items and units by designation (name), e.g., with the help of a component diagram. In doing so, you should specify at least the second level in the component tree. This means that your software units form the second level, the “leaves” of the component tree. Of course, it is recommended that you also specify at a deeper level, but this is not necessarily required.
- You need to specify the interfaces of these components and units. To do this, you should describe the API of these interfaces, including input and output types, and the behavior for correct and incorrect parameters.
- Likewise, you must describe which component or unit calls which interface of which other software component or unit. This can also be shown in the component diagram.
Verify software units
IEC 62304 requires that you define acceptance criteria for software units and strategies, methods, and procedures for their verification. However, the standard does not specifically regulate strategies, methods, and procedures or prescribe the selection of possible acceptance criteria. However, it provides examples such as coding guidelines or reviews to determine whether the code fulfills software requirements.
However, for class C, the standard specifies acceptance criteria such as resource allocation, which can no longer be evaluated by simply analyzing the code, i.e. requires the code to be executed, such as in unit tests.
Typical errors and how to avoid them
The unit tests do not test the software units
Software developers usually understand unit tests as software tests with which they test their classes, methods, or functions. In doing so, they regularly fail to test the software units specified in the architecture and are often much higher up in the component tree. This regularly leads to problematic situations in audits.
No testable specification of the requirements for a software unit
The task of software architects or component designers, respectively, is to specify the interfaces of the software units, as described above. This is often neglected. Representing the software units and their interfaces in a component diagram (e.g., using Lolipop notation) does not fulfill the requirement for specifying the interfaces.
Unclear requirements for the verification of software units
Another common mistake is that manufacturers do not provide specific instructions in the development plan on how software units are generally to be verified. Examples could be
- Every code must be subject to a code review.Every code must be subject to an (automated) static code analysis that checks metrics, coding guidelines, formatting, etc.
- All public functions/methods of all units must be tested. A measure of the completeness of these tests could be:
- % of functions (should be 100%)
- Code coverage (branch or statement coverage)
- % of requirements on the software unit that are tested (should be 100%)
- Use of (black box) test procedures, e.g. error, limit value, equivalence classes, state and decision table-based tests?
- % of the tested functions are safety-critical, although you cannot (!) evaluate this alone in the unit, but only in the overall context of the software architecture and risk analysis.
FAQ on software units
What do I do if the specification of the software units becomes too complex?
If you put too much effort into the specification of your units and their interfaces, this can have several causes:
- You have too many functions/methods per interface. In this case, it is not the effort that is your problem but your architecture. The architecture is suboptimal because you have a (too) broad interface and thus infringe/violate the fundamental paradigm of suitable architectures “Weak Coupling – Strong Cohesion”.
- You have decomposed your component tree too granularly. Decompose your software at least to the first two building block levels and then deeper, if necessary, until a developer can develop the software unit identified without significant ad-hoc design decisions.
- You just think it’s too much effort. The essential part of the added value in software development takes place within the framework of software architecture, no longer (only) during coding. Therefore, it is good and right to put a lot of thought into this phase and not have to go through the laborious process of “refactoring” the software later.
Do you have any further questions about the specification and verification of software units? Do you need support with your software architecture or with the approval of your software? Professor Johner and his team are happy to help!
