The System Architecture describes how a (medical) product is composed of components and how the components are related to each other via interfaces. In stand-alone software systems architecture and software architecture fall together.
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.
There are some regulatory requirements for documentation of system architectures. On the one hand calls for the Medical Device Directive MDD 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 can not 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 Audit Guarantor you will find video training on safety-critical system architectures.
Risk in relation to dismantling systems in layers
In the dismantlement of systems into components, some manufacturers tend to dismantle them in different ‘subsections’, for example, in mechanics, electro-mechanics, electronics and software. We would advise against this because on the one hand this layered system architecture (hopefully) does not reflect reality and on the other you can not consistently think in 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 stand-alone 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 (ie, 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.
The team of Johner Institute specialises in using, creating and testing system architectures with and for medical device manufacturers and thus:
Wha not get in touch now with our experts?