You have done your Software Risk Analysis and have identified your Firmware to be of Software Safety Class C. What next? There are 3 points of the IEC 62304 Standard specific to the design of Class C Medical Device Firmware: Segregation, Detailed Design for Interfaces, Additional Software Unit Acceptance Criteria.
IEC 62304 standardizes the Software Life Cycle Processes for Medical Device Software providing a common framework for software development and maintenance processes and activities. Written as a process standard, it tells what to do, but not how to do it. This blog shares the StarFish Medical approach to Segregation.
In chapter 5.3.5, the IEC 62304 states “The manufacturer shall identify any segregation between Software Items that is necessary for risk control, and state how to ensure that such segregation is effective.”
This means that depending on the outcome of the risk assessment, you will have to implement segregation and demonstrate its effectiveness.
And if your Software System is Class C, but you would like to lower the Software Safety Class of one or more Software Items to Class B ,or even Class A, you will have to implement segregation between the Class C Software Items and any Software Item of lower safety class.
To achieve Segregation:
- Use appropriate tools. I highly recommend an object-oriented programming language, which will allow for data encapsulation, thereby providing the means necessary for restricting access to data internal to an object. The most commonly used language for this purpose is C++.
- Design a Software Architecture that not only allows for but enforces segregation.
- Find means for a well-controlled data flow. We use a blackboard approach. Blackboards are data containers with controlled write access. Each blackboard is owned by a single Software Item. Only the owning Software Item can write to the blackboard. But any Software Item can read from it. Blackboards are the only means of data exchange within a Software System. This ensures segregation of all data and Software Item isolation: No Software Item can manipulate data that it does not own.
- Avoid shared resources.As an example, any access to a hardware resource, such as a stepper motor, must go through a driver. Each driver is declared (and fully encapsulated) within an interface object. The interface object will read data from a “control” blackboard but post its data to a “status” blackboard, owned by the interface itself. So, a stepper motor interface would read the stepper target position from a control blackboard and might put the current stepper position onto its stepper status blackboard.
- Implement restrictions and/or monitoring for resources for which sharing cannot be avoided (like the MCU itself and the system memory). Monitor execution times for all Software Items running on the same MCU. Restrict write access to memory; see the blackboard approach discussed above.
- If necessary, implement individual Software Systems on individual microcontrollers for logically separated Firmware Modules. For example, run the controlling logic on one MCU, and the error detection and alarm logic on another. Keep the blackboard approach in place and implement a mechanism to synchronize read-only copies of blackboards to the other Software System(s).
Figure A shows a simplified version of a Software Architecture for Safety Class C Firmware. It has an Application Controller, a UI-Controller and an Alarm Controller. Each of these controllers will only write to its own blackboard. For example, a user flips a (physical) switch on the user interface. The UserInput Interface will read the state of the switch via the UserInput Driver and post the switch state on its UserInput Blackboard.
The UI Controller will also read the switch state from the UserInput Blackboard and could give the user visual feedback by writing a status message to the LCD. However, it could not directly write to the LCD, but instead post the information on its blackboard, where the LCD Interface will pick it up and pass it on to the LCD driver.
At the same time, the Application Controller will read the switch state from the UserInput Blackboard and take action accordingly. Typically, it will read some sensor information from one of the Sensor Blackboards and control an actuator via its AppControl Blackboard, which again, gets read by the Actuator Interface etc.
Last but not least, the Alarm Controller will read the switch state from the UserInput Blackboard and adjust its alarm monitoring accordingly. In case of an alarm situation, the Alarm Controller will write to the AlarmOutput Blackboard. The Alarm Interface will then pick up this information and, using its drivers, sound alarm tones and flash alarm lights.
Figure A
Conclusion
When it comes to designing Class C firmware, having a clean and clear Software Architecture is key. Specifically, when Software Item segregation is required, an architecture like the one discussed above, combined with the blackboard approach, will structure the development process efficiently and allow for clear demonstration of the effectiveness of segregation.
Image: StarFish Medical
Bertram Hildebrand is a distinguished Senior Firmware Architect at StarFish Medical with an impressive tenure exceeding 30 years in firmware development. His expertise spans across the realms of industrial automation and medical devices. Bertram’s academic journey is founded on a solid German engineering degree and topped off with a master’s degree from the renowned Johner Institute of Constance, Germany. His German engineering degree reflects a commitment to precision and excellence, while his advanced studies at the Johner Institute underscore his dedication to medical device firmware engineering. Bertram’s career is a testament to his passion for engineering and his unwavering pursuit of innovation.
