Reading IEC 62304 safety classification honestly

Classification under IEC 62304 is determined by the harm that can result from a software failure, after external risk controls are considered. Architecture quality, team seniority and the care taken over the code do not enter the argument.

The common mistake

A team assesses the whole product as Class B because most of it is a dashboard, then discovers that one dosing calculation places a component in Class C. The lifecycle obligations for that component are different, and retrofitting detailed design documentation for it is expensive.

Segregation is a design decision

The standard permits segregation of software items so that a lower class applies to the remainder, but the segregation must be justified and demonstrated, usually through process, memory or network boundaries rather than a folder structure. Decide this at architecture time, and document the rationale while the reasoning is still fresh.

• —Write the intended use statement before the classification argument.
• —Identify hazards that software can cause or fail to mitigate, not generic risks.
• —Justify segregation with an enforced technical boundary and a test that proves it holds.
• —Re-open the classification whenever intended use changes, however small the change appears.