Egal ob im Auto, in der Luft- und Raumfahrt, der Medizintechnik, Automatisierung, Robotik oder der Bahntechnik: Immer mehr Anwendungen nutzen Embedded-Software für sicherheitskritische Funktionen. Die hohe Flexibilität, einfache Änderbarkeit sowie die Update-Möglichkeit im Feld macht diese attraktiv, birgt aber auch Risiken. Hastige Änderungen und komplexe Software-Module können zu schwer erkennbaren Fehlern führen.

Auch Bedienungsfehler, ausgefallene Bauteile oder den Betrieb jenseits gültiger Umgebungsbedingungen müssen die Software-Entwickler berücksichtigen. Undefinierte Abstürze gilt es zu verhindern: Das System muss immer in einen für den Betroffenen sicheren Zustand münden.

Ergänzende Normen

IEC 61511: Funktionale Sicherheit. Sicherheitstechnische Systeme für die Prozessindustrie. Teil 1: Allgemeines, Begriffe, Anforderungen an Systeme, Software und Hardware.

IEC 62061: Sicherheit von Maschinen. Funktionale Sicherheit sicherheitsbezogener elektrischer, elektronischer und programmierbarer elektronischer Steuerungssysteme.

IEC 60601: Medizinische elektrische Geräte. Allgemeine Festlegungen für die Sicherheit.

EN 60601-1-4: Medizinische elektrische Geräte. Teil 1-4: Allgemeine Festlegungen für die Sicherheit; Ergänzungsnorm: Programmierbare elektrische medizinische Systeme.

DIN EN 62304: Medizingeräte-Software. Software-Lebenszyklus-Prozesse.

FDIS 26262: Road Vehicles. Functional Safety (löst die IEC 61508 für die Automobilindustrie ab).

Um diese Sicherheit zu gewährleisten, stellen einschlägige Normen hohe Anforderungen an die Qualität der Entwicklungsprozesse und Dokumentation. Es genügt nicht, sorgfältig zu implementieren und umfassend zu testen. Vielmehr müssen im Qualitätsmanagement die kompletten Softwareentwicklungs- und Änderungsprozesse klar definiert und durchgeführt werden.

Normative Anforderungen

Mit der IEC 61508 wurde bereits 1998 eine grundlegende Norm für die Entwicklung sicherheitskritischer, programmierbarer elektronischer Systeme geschaffen. Sie erstreckt sich über den kompletten Lebenszyklus: von der Konzeption über die Entwicklung, Inbetriebnahme und Modifikation bis hin zur Außerbetriebnahme. Um herauszufinden, welche Maßnahmen erforderlich sind, wird im Rahmen einer Risikoanalyse die Sicherheitsanforderungsstufe ermittelt (Safety Integrity Level, SIL1 bis SIL4).

Teil 3 der Norm IEC 61508 beschreibt den Software-Lebenszyklus und schlägt Techniken und Verfahren vor, wie sicherheitsrelevante Softwaremodule entworfen und dokumentiert sein sollten. Alle Tätigkeiten und Ergebnisse müssen dokumentiert werden.

Zahlreiche Normen für spezielle Anwendungsbereiche ergänzen diese anwendungsunabhängige Basisnorm (siehe Textkasten „Ergänzende Normen“). Zusätzlich existieren länderspezifische Regelwerke, etwa die „Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices“ der US-amerikanischen Food and Drug Administration (FDA). Sie gelten für die Zulassung in den entsprechenden Märkten. Begleitend werden beispielsweise in der Medizintechnik ein Qualitäts- und ein Risikomanagementprozess gefordert
(DIN EN 13485, DIN EN 14971).

Software-Entwicklungsprozesse

In vielen Unternehmen hat sich das V-Modell (Bild 1) etabliert. Bei diesem phasenorientierten Vorgehensmodell steht jeder Designphase eine entsprechende Testphase gegenüber. Die Anforderungen an das System / die Software müssen vor Beginn der Umsetzung möglichst vollständig und widerspruchsfrei definiert sein. Außerdem muss eine Architektur entworfen sein, bevor das Team mit der Implementierung beginnt.

Parallel zu den Anforderungen sollten bereits die entsprechenden Testfälle spezifiziert werden. Dabei ist die Rückverfolgbarkeit von der Anforderung über die Implementierung zum Test für sicherheitsrelevante Softwaremodule in der Dokumentation elementar.

Bild 1: Beim V-Modell steht jeder Designphase (links) eine entsprechende Testphase gegenüber (rechts).

Bild 1: Beim V-Modell steht jeder Designphase (links) eine entsprechende Testphase gegenüber (rechts).Helbling Technik

Das V-Modell hat aber auch Nachteile: Die Testaktivitäten beginnen recht spät und die Anforderungen müssen bereits zu Beginn sehr ausführlich dokumentiert werden – zu diesem Zeitpunkt sind oft noch nicht alle Implikationen im Detail bekannt. Als Ausweg kann man zum Beispiel einige Praktiken aus der agilen Software-Entwicklung in das V-Modell übernehmen, etwa die Test-getriebene Entwicklung sowie die wichtigsten Anforderungen zuerst zu realisieren und die Anforderungen dann im Lauf der Zeit weiter zu verfeinern.

Planung

Der Software-Entwicklungsplan beginnt mit der Definition der einzelnen Phasen und deren jeweiligem In- und Output. Die beteiligten Personen und ihre Rollen werden ebenso festgehalten wie der geplante Dokumentationsumfang.

Der Konfigurationsmanagementplan beschreibt, wie die Elemente einer Softwareentwicklung verwaltet und kontrolliert werden, etwa Sourcecode, Compiler, Tools, projektspezifische Einstellungen sowie die entwicklungsbegleitende Dokumentation.

Im Risikomanagementplan werden die Maßnahmen zur Risikoanalyse, Risikobewertung und Risikominimierung definiert. Hier gilt es, systematisch die potenziellen Gefährdungen zu ermitteln, sie nach ihrer Auftretenswahrscheinlichkeit und dem Schadensausmaß zu bewerten und bei Bedarf Risikominimierungsmaßnahmen zu definieren.

Der Testplan definiert schließlich, welche Testaktivitäten und -Tools eingesetzt werden um die Software zu verifizieren. Dazu gehören sowohl statische Codeanalysen als auch dynamische Tests.

Requirements Engineering

Der Entwicklungsprozess beginnt damit, Anforderungen an die Embedded-Software aus den Systemanforderungen abzuleiten. Sie werden im Laufe der Entwicklung ergänzt und verfeinert, zum Beispiel durch Anforderungen aus dem Risikomanagement oder von der Elektronik.

Viele Softwarefehler haben ihren Ursprung in der Analyse- und Spezifikationsphase. Um Spezifikationsmängel zu vermeiden ist es unerlässlich, die Software-Anforderungen umfassend und eindeutig zu definieren. Dabei sollte man die Testbarkeit der Anforderung im Auge behalten: Statt „der RAM-Test darf eine kurze Zeit dauern“ ist „der RAM-Test muss weniger als 0,3 Sekunden dauern“ viel klarer.

Bild 2: Das Datenflussdiagramm zeigt, welche Komponenten miteinander kommunizieren und welche Informationen sie dabei übermitteln.

Bild 2: Das Datenflussdiagramm zeigt, welche Komponenten miteinander kommunizieren und welche Informationen sie dabei übermitteln.Helbling Technik

Wichtig ist weiterhin, alle Anforderungen durch eine eindeutige ID zu kennzeichnen: Sie ermöglicht es, Anforderung nachzuverfolgen – vom Design und der Implementierung bis hin zum Test. Mit der ID lässt sich auch ein Bezug herstellen zu übergeordneten Anforderungsdokumenten wie den Systemanforderungen und der Risikoanalyse.

Von der Architektur zur Implementierung

Vor der Implementierung steht die Softwarearchitektur (Bild 2 und Bild 3). Sie beschreibt die Schnittstellen zwischen den Software-Schichten sowie zwischen Software und Hardware. Die Architektur beinhaltet die erforderlichen Programmmodule und erlaubt – soweit möglich – eine Eingrenzung der sicherheitsrelevanten Softwarefunktionen.

Bild 3: Das Blockschaltbild skizziert die Architektur einer Software, also die Schnittstellen zwischen den einzelnen Modulen und Komponenten sowie der Hardware.

Bild 3: Das Blockschaltbild skizziert die Architektur einer Software, also die Schnittstellen zwischen den einzelnen Modulen und Komponenten sowie der Hardware.Helbling Technik

Im Embedded-Bereich hat sich C als Quasistandard durchgesetzt. Die vielfältigen Möglichkeiten der Hardware-nahen Programmiersprache sind jedoch eine Risikoquelle, da die Compiler viele Programmierfehler kaum erkennen. Daher werden oft Konventionen definiert, um die Programmiermöglichkeiten auf ein vernünftiges Maß einzuschränken und zusätzliche Sicherheit zu gewinnen.

Software-Module von Drittanbietern (SOUP, Software of Unknown Provenance), zum Beispiel ein Echtzeit-Betriebssystem, brauchen bei sicherheitskritischen Anwendungen besondere Beachtung. Für SOUP-Komponenten sind laut IEC 62304 Funktions- und Leistungsanforderungen festzulegen und die Schnittstelle zur System-Software zu definieren. Bekannte Anomalien sind hinsichtlich ihres Einflusses zu evaluieren.

Bild 4: Das Ablaufdiagramm der Software-Erstellung zeigt, welche Schritte in welcher Reihenfolge nötig sind, um sicherheitskritische Programme und Systeme zu erstellen.

Bild 4: Das Ablaufdiagramm der Software-Erstellung zeigt, welche Schritte in welcher Reihenfolge nötig sind, um sicherheitskritische Programme und Systeme zu erstellen.Helbling Technik

Testing

Die einschlägigen Sicherheitsnormen schreiben vor, dass die Testaktivitäten von Beginn der Entwicklung an geplant werden. Die Testfälle und ihre erwarteten Ergebnissen sind parallel zu den Anforderungen zu definieren. Nebenbei können die Testergebnisse mit geeigneten Metriken auch als Software-Qualitätsmaß dienen. Statische Analysen wie PC-Lint, die Misra-C-Regeln und Code-Reviews sollten schon während der Entwicklung stattfinden, um Fehler früh zu finden. Die Testergebnisse sind so zu dokumentieren, dass eine Rückverfolgbarkeit der Ergebnisse gewährleistet ist.

Bei dynamischen Tests werden Programmteile mit definierten Eingangsgrößen ausgeführt und die Ergebnisse mit den Erwartungswerten verglichen. Ziel ist es, eine möglichst große Testabdeckung bei vertretbarem Aufwand zu erreichen. Dabei helfen verschiedene Testmethoden sowie unterstützende automatische Testwerkzeuge. Ein komplett durchgeführter und bestandener Testdurchlauf ist die Voraussetzung für die Freigabe der Software.

Änderungen

Der formale Änderungsaufwand hängt vom erreichten Reifegrad ab. Spätestens nach Freigabe einer ersten Version braucht jede Anpassung einen definierten Änderungsprozess. Die Softwaremodifikation beginnt dann mit einem Änderungsantrag. Der enthält eine eindeutige ID, die geforderte Änderung sowie eine Einschätzung, inwieweit diese Modifikation andere Systemfunktionen beeinflusst. Bei Fehlerkorrekturen (Bugfixes) sollte eine Problemrecherche durchgeführt werden, um Ursachen und Gegenmaßnahmen zu identifizieren.

Der Änderungsvorgang lehnt sich an den Entwicklungsprozess an: Er führt von der Planung über die eventuell notwendigen Anpassungen von Spezifikationen und Testfällen zur Implementierung und einer erneuten Verifizierung. Die Änderungsdokumentation umfasst alle Änderungen sowie Testergebnisse, die die Funktionalität der modifizierten Software nachweisen.

Umsetzung im Unternehmen

Bild 5: Helbling Technik setzt auf eine verzahnte Tool-Kette. Zum Beispiel kann das Bug-Tracking-Tool Trac auch auf die Versionsverwaltung SVN zugreifen, etwa beim Beheben eines Fehlers oder beim Umsetzen einer Anforderung direkt das Change-Set verlinken.

Bild 5: Helbling Technik setzt auf eine verzahnte Tool-Kette. Zum Beispiel kann das Bug-Tracking-Tool Trac auch auf die Versionsverwaltung SVN zugreifen, etwa beim Beheben eines Fehlers oder beim Umsetzen einer Anforderung direkt das Change-Set verlinken.Helbling Technik

Im Software-Entwicklungsprozesses für sicherheitskritische Funktionen kommen in der Regel viele Tools zum Einsatz. Helbling Technik stützt sich beim iterativen V-Modell auf eine Mischung ineinander greifender Tools (Bild 5). So kann das für Änderungs- und Problemmanagement eingesetzte Trac direkt auf die Elemente des zum Konfigurations- und Versionsmanagement genutzte Subversion (SVN) zugreifen.

Requirements verwalten, Traceability-Daten führen und Architektur sowie Design erstellen: Für diese Schritte gibt es das Modellierungswerkzeug Enterprise Architect (EA). Requirements und Traceability werden je nach Projekt auch mit dem Anforderungsmanagement-Tool Doors umgesetzt.

Als Entwicklungsplattform kommt Eclipse zum Einsatz. In dieser IDE lassen sich alle Tools als Erweiterungen integrieren. Beim Testing unterstützt Helbling Technik viele Tools; die wichtigsten sind QA-C, Codeanalyser, Cantata und Klokwork.

Sicherheitskritische Software entsteht im Hause Helbling heute, indem die Mitarbeiter die grundlegenden Prozesse abbilden und mit einem optimierten Toolansatz kombinieren. So sehr die Werkzeuge sie hierbei unterstützen: Wissen und Erfahrung sind bei sicherheitskritischen Projekten immer nötig.