IEC 62304 Amendment I: Wichtige Änderungen

Bei dem Amendment handelt es sich somit nicht um einen klassischen Anhang, sondern um eine Sammlungen an Änderungen. Dies ist Vergleichbar mit einem Gesetz, das ein anderes Gesetz ändert.

Ergänzung des Software-Entwicklungsplans
(Amendment I Kapitel 5.1.12)

Das Amendment I ergänzt das Kapitel 5.1 zum Software-Entwicklungsplan um ein neues Teilkapitel 5.1.12. Es trägt die Überschrift „Identification and avoidance of common software defects“.

Was versteht das Amendment I unter „Programming Technology“

Darin steht geschrieben, dass der Hersteller Risiken betrachten muss, die spezifische für die gewählte „Programming Technology“ seien. Dabei ist nicht sofort klar, was das Amendment I in Kapitel 5.1.12 unter diesem Begriff versteht. Es gibt jedoch zwei konkrete Anhaltspunkte:

1. Das Amendment I verweist auf die IEC 80002-1, die Beispiele nennt wie unten genannt.
2. In einer früheren Version des Amendment hieß es noch „“Progamming Language“ also Programmiersprache.

Beides zusammen lässt den Schluss zu, dass es primär um Programmiersprachen-spezifische Probleme geht. Man hat aber den Begriff erweitert um auch Probleme adressieren zu können, die sich durch andere Technologien wie z.B. .NET, Web-Technologien (AJAX, JSON, etc.), Datenbanken (MySQL, etc.), usw. ergeben.

Beispiele für Programmiersprachen-spezifische Probleme

Zu den Beispielen für Programmiersprachen-spezifische Probleme zählen

• Division by zero
• numeric overflow/underflow
• Rundung von Float-Werten
• Race Conditions
• Fehlerhafte Pointer und Null Pointer
• Fehler bei der Datentypkonvertierung und dem Casting (gerade in nicht-typisierten Sprachen wie JavaScript ein echtes Problem)
• Fehlende oder fehlerhafte Initialisierung von Variablen
• Memory-Leaks (auch der Laufzeitumgebung wie JRE oder .NET)

Liest man die Liste der IEC 80002-1 kommt man zur Vermutung, dass die Autoren C-Entwickler sind oder waren, die auch nicht mehr auf dem neusten Stand sind. Templates in C oder Beispiele für spezifische Probleme von Java, C# oder JavaScript fehlen.

Was man laut IEC 62304 Amendment I tun kann und soll

Die Hersteller sollen laut IEC 62304 Amendment I die Risiken durch die o.g. Probleme erkennen, dokumentieren, bewerten und geeignete Maßnahmen ergreifen. Maßnahmen könnten sein:

• Kodierungsrichtlinien
• Schulung der Programmierer
• statische Code Analyse
• Liste mit typischen Programmierfehlern in Abhängigkeit der Sprache zu erstellen und diese beim Code Review zu prüfen.
• Strengere Compiler-Settings
• Andere „Programmier-Technologie“ z.B. TypeScript (typisiert) zur Generierung von JavaScript

Änderung der Sicherheitsklassifizierung
(Amendment Kapitel 4.3)

Die bisherige Sicherheitsklassifizierung basierte ausschließlich auf dem Schweregrad eines resultierenden Schadens. Die meisten Hersteller konstruierten sehr unwahrscheinliche Fälle, die zu einem schweren Schaden führen. Weil die Definition der Sicherheitsklassen die Wahrscheinlichkeit aber nicht berücksichtigt, fiel die Software fast immer in die Sicherheitsklasse C, was nicht im Sinn der Norm war.

Das IEC 62304 Amendment I ändert das Kapitel 4.3. Mehr dazu finden Sie in einem Beitrag über die Sicherheitsklassifizierung.

Mit Dank an Luca Salvatore

Legacy Software

Das Ammendment I möchte den Herstellern auch eine Brücke zurück in die Legalität bauen, die sogenannte „Legacy Software“ im Markt haben und ggf. ändern wollen. Mehr dazu finden in einem eigenen Artikel zur Legacy Software.