IEC 60601-1 Clause 14.8 - Architecture


Im currently developing an anaesthetic workstation, looking at the 60601-1 standard, clause 14.8 Architecture, I don't get what architecture points to. Since my device has a PESS and other systemes, i don't understad if architecture only points to software architecture, or if subsystems like mechanical-structurale shall have an architecture too?

Thank you

Benjamin Weber

Trusted Information Resource
Since cl. 14 deals with PEMS / PESS the architecture shall descibe the software only. According to the rationale in annex A, this is an additional requirement to IEC 62304.


Super Moderator
I don't disagree with the response from @Benjamin Weber but after re-reading that section, I think you may also need to address the (hardware) components with which the software interfaces. For example, if you have a sensor that feeds data to the software, that may, based on risk, drive a high-integrity component or redundancy (3 sensor and 2 must agree, for example).

Curious if that lines up with others' understanding or if I'm going off the deep end (again).


Starting to get Involved
The architecture shall satisfy the requirement specifications. This should be in compliance with your QM (how do you develop a product? Which documents do you need?).
In our case and with help from a consultant, you definitly need system requirements and a system design. If you should feel the need to have component requirements for your sub-systems (or components), they shall have a component design / component architecture described.
So you should not only have your system as a black box, but have a system architecture described, which can be linked by your risk management (e.g. you can directly see that there is a backup power system in case the main power system fails, or directly show a redundancy of sensors).
Think of it not as much as a fully developed software architecture in UML, but just a white-box view of your system where you can see the interaction of all identified components.

Peter Selvey

Super Moderator
My impression was that in 601-1 they kind of confused things by referring to "architecture specification". In IEC 62304 they use "architecture design" which refers to the breakdown of the system into units. This breakdown is optional and depends on a lot of factors such as how well established the software is, criticality, importance of segregation (e.g. protection software from control software).

For a larger system including software and hardware, the principle is the same. As in IEC 62304, the degree and structure of breakdown is optional. You could call a block "motor system" even though internally it could include voltage regulators, motor drives, feedback sensors and the motor itself. If it was an off the shelf component from an approved supplier, or a sub-system that's been used for 10 years without trouble, or not that critical, that simplistic approach might be OK. But if it was custom built sub-system and/or has critical safety features, you might break it down further to enable better testing before placing on the market.

Plus, for high risk devices segregation is important to show in architecture. For example, if the data from the motor encoder is used for a risk control measure (motor going too fast, too slow or stalled, which could kill or seriously harm a patient) it makes sense to ensure that it is isolated or independent from the control system. An architecture is the place to show this. In that sense, the architecture is a specification, in that the isolation from a control system is something that should also be verified, ideally by engineers that are not involved with the design. This aspect - verification of independence in risk control measures - is often overlooked as an activity in the verification process.
Top Bottom