The system architecture describes how a (medical) device is composed of components and how the components are related to each other via interfaces. In standalone software system architecture and software architecture fall together.
Documentation of the system architecture
The documentation should reveal the individual components and their interaction. We recommend that you use standard notations like UML or SysML and not to work in PowerPoint with undefined notation elements.
In addition to the charts with the different views, the interfaces of the individual components is to be specified. Here you will find instructions on how to fully describe the specific requirements of interoperability.
Regulatory requirements for the system architecture
There are some regulatory requirements for documentation of system architectures. On the one hand the Medical Device Directive MDD requires that manufacturers have to document design drawings […] as well as diagrams of components, sub-assemblies, and circuits in the product file. Without an explicitly documented system architecture this legal requirement would not be met.
The IEC 60601-1 requires that the medical device manufacturer identifies the Programmable Electrical Subsystems PESS, formulates requirements, and verifies their fulfillment. Without a documented system architecture the demand cannot be fulfilled.
A documented system architecture is also a necessary condition for a more accurate risk analysis for an FMEA. A suitable system architecture doubles the risk control. In the Medical Device University you will find video training on safety-critical system architectures.
Documentation: System architecture and component specification
Do two documents need to be created: a system architecture and a component specification? Should these two documents be written promptly? By the same person?
There is no general answer to whether the system architecture and component specifications (plural) should be packed into one or more documents. It depends, for example, on
- how many components there are
- how extensive the document would be
- whether the components are to be developed by one or more independent teams
- whether the component development is outsourced or not
- etc.
The component specifications should be made very promptly and in close coordination with the system architect. The system architect not only breaks down the system to be developed into components but also describes how these components interact through interfaces. In other words, the system architect describes how the components behave via their interfaces in the sense of a black box model (sometimes also referred to as a functional block diagram). And that model is exactly what a component specification is.
By the way, these considerations apply regardless of whether you are developing a medical device or standalone software; they are just as applicable to PEMS as to software systems. In one case, we are more within the scope of IEC 60601, and in the other, we are within the scope of IEC 62304.
Analysis of systems in components
Risk in relation to dismantling systems in layers
In the decomposition of systems into components, some manufacturers tend to decompose them in different “subsections,” for example, in mechanics, electro-mechanics, electronics, and software (see column 1 in the following illustration).
We would advise against this because, firstly because this layered system architecture (hopefully) does not reflect reality and secondly because it is not possible to think consistently in terms of components.
Only a component-based system architecture is a maintainable, testable, reusable architecture.
System architecture and software architecture
In particular, it can and should not be, that software components are modeled on the first level of the system architecture. Whether that’s the case for you also depends on what you define as software architecture.
Option 1: A software system is part of a PESS
If you define a software system as the totality of all software that runs in a memory / processor (and thus in a ) PESS, no software should be seen in the system architecture. Unless the system is a standalone software. Otherwise, you would only recognise in the system architecture, the components which are a subset of PESS. And in each PESS there is software (i.e., a software system), for which there is a software architecture and software requirements so that again and again software components are identified. But the latter is not visible in the system architecture.
Option 2: A software system is the totality of all software
If you, however, understand the totality of all software in the medical device under a software system (I do not recommend this definition), then you would get a “lasagna-subdivision.” They would then have no right system architecture but a software architecture, an electronic architecture, and a “mechanical architecture.”
The standard gives no specification as to which variant you have to choose.
Assistance in the creation and testing of system architectures
The Johner Institute team is specialized in using, creating, and testing system architectures with and for medical device manufacturers and, thus,
- identifying and dominating risks posed by the medical device,
- avoiding difficulties during the audit and in the approval,
- keeping system architectures condensed, precise, meaningful, and in compliance with standards, as well as
- finding mistakes early, fixing them, and thus avoiding costly rework and project delays.
Get in touch with the experts at the Johner Institute.
