Software architecture (compliant with IEC-62304)

Manufacturers almost always have to design and verify a software architecture for medical device software.

1. Basics

a) Objective

The software architecture serves as input for the software development team to develop the software as planned (time, money, quality). It is intended to minimize development risks and ensure that the software meets the software requirements.

b) Definition

Software architecture is understood to be both a phase with a set of activities as well as the output of these activities. Most definitions are aimed at the latter.

An illustrative definition comes from Martin Fowler:

2. Software architecture in the development life cycle

a) Standalone software (Software as a medical device)

For standalone software, the software architecture is the “blueprint” that specifies how the software requirements (the input) are to be implemented in software (see Fig. 1). The output of this phase is the documented software architecture. This includes the software items and their requirements.

Fig. 1 is reminiscent of a V-model. However, in this context it is to be understood more as a software development documentation model than a process model.

b) Software as part of a device (software in a medical device)

For the software part of a device, the software requirements also serve as input for the software architecture. However, they do not correspond to the system or product requirements (see Fig. 2 and Tip 1).

The output here is also the documented software architecture, including the requirements for the software items.

c) Interaction with risk management

For medical devices, software architecture and software risk management must work hand in hand. This applies in particular to software risk analysis, for example, with the help of a software FMEA or threat modeling.

Risk-minimizing measures, such as the segregation of components, should also be defined in this phase.

d) Demarcation (abdominal architecture)

In contrast to software architects, building architects not only create the construction plan. They also determine the stakeholder requirements (together with the client).

Software architects should only create the blueprint (the software architecture). Eliciting the requirements is the task of requirements engineering.

Regulatory requirements

Europe

MDR, IVDR

The MDR and IVDR require software life-cycle processes according to the state of the art (see MDR, Annex I, Section 17.2) and the “description of the software design” (see Annex II, Section 6.1.b).

IEC 62304

The harmonized standard IEC 62304 for these EU regulations specifies a software architecture and a detailed software design in chapters 5.3 and 5.4. To this end, manufacturers must identify the software items and software units and specify the corresponding interfaces.

If manufacturers use off-the-shelf software (SOUP), they must also specify the requirements for this and document and guarantee the prerequisites for its use.

The standard obliges manufacturers to verify the software architecture, for example, whether all requirements have been taken into account and risk control measures have been implemented.

USA

The FDA acknowledges IEC 62304 as a “recognized standard”. However, the authority formulates the most relevant requirements for software architecture in its General Principles of Software Validation guideline.

In addition, the guideline Content of the premarket submission specifies which documents manufacturers must submit. In this document, the FDA also sets out requirements for the “software architecture” and the “software detailed design.”

Practical tips

Tip 1: Do not necessarily define the software system as the entirety of the software

Medical electrical equipment can contain more than one CPU and, therefore, more than one “software” (see Fig. 3). Manufacturers should not define the entirety of all software as the software system. Instead, the software for each processor unit (which may contain multiple cores) should count as a separate software system.

Manufacturers thus avoid layered architectures and devices mentally divided into mechanical, electronic, and software layers. They should divide devices according to functional considerations.

Tip 2: Choose the right timing

It is neither sensible nor legally compliant to specify and document the software architecture only after the software has been developed.

In agile software development, continuous refactoring is possible and common. However, experience shows that most manufacturers are challenged with a precise and viable upfront architecture. Maintaining the conceptual integrity of an architecture in agile development requires high skills.

It is, therefore, helpful to make the key design decisions early on and based on stable requirements.

Tip 3: Use defined notation

Some developers document the software architecture using boxes and arrows in PowerPoint. However, what an arrow indicates must be clear. A

• dependency relationship?
• association? Composition, or aggregation?
• inheritance relationship?
• direction of data flow?
• direction of method calls?
• implementation?

A model is only meaningful if the notation elements (shapes, colors, etc.) are clearly defined. Therefore, do not invent your notation language; use standardized languages such as UML.

Tip 4: Define integration strategy at an early stage

An essential characteristic of a good software architecture are components that are characterized by “weak coupling and strong cohesion” in the software system. This weak coupling is the prerequisite for later assembling and integrating the software piece by piece from the components.

Manufacturers should determine the integration strategy very early because this forces them to think about the strength of the coupling from the outset. The integration strategy also influences the integration tests.

Tip 5: Verification with checklists

The architecture must be verified before development begins. A change to the software architecture requires renewed verification (at least of the changes).

Conformity and completeness of the software architecture can be checked in an understandable manner using checklists such as those found in the medical device university. This helps manufacturers to avoid forgetting aspects.