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 Firmware for Medical Devices – 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 article 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.