Immer mehr Produkte und Prozesse arbeiten mit immer komplexerer Software. Damit wachsen natürlich auch die Risiken. Arbeitet ein Programm unter einmal nicht wie vorgesehen oder ist es leicht angreifbar, so ist das schon unter normalen Umständen ärgerlich. In vielen Bereichen wird es dann jedoch teuer oder richtig gefährlich – man denke nur an die Steuerung von Produktionsprozessen, an Flugzeuge oder Medizintechnik. Egal wie gut die Hardware und wie sorgfältig alles konzipiert ist: Nur wenn auch die zugehörige Software stabil und zuverlässig funktioniert, kann man von einem sicheren System sprechen.
Deshalb findet sich in den Produktbeschreibungen immer häufig der Hinweis, die Software sei zertifiziert, sie eigne sich also für den Einsatz in sicherheitskritischen Systemen. Mit dem Bedarf wächst auch die Zahl der Stellen, die entsprechende Zertifikate erteilen. Und das sorgt zunehmend für Missverständnisse.
Schon der Begriff „Zertifizierung“ wird häufig falsch verwendet. Die grundlegende Idee hinter der Zertifizierung von Software ist, dass umfangreiche Tests und Dokumentationen einer autorisierten Stelle effektiv beweisen, dass eine bestimmte Software wie erwartet läuft. Eine Systemsoftware sollte also auf Basis festgelegter Anforderungen geprüft werden – das Zertifikat ist dann der Nachweis, dass die Software eben diesen Anforderungen entspricht. Damit ist auch definiert, was in diesem Zusammenhang jeweils unter „sicher“ zu verstehen ist. Jetzt wird es kompliziert: Denn die Vielzahl von Normen in Kombination mit einer Menge schwer zu verstehender Begriffe kann selbst bei Entwicklern in sicherheitskritischen Bereichen für reichlich Verwirrung sorgen. Zudem geht es nicht nur um komplette Systeme, sondern auch um einzelne Module. Galten nämlich die meisten Normen für die Zertifizierung zunächst für Systeme, ist es inzwischen üblich, dass auch Softwaremodule, etwa Echtzeit-Kernel, damit vermarktet werden, dass sie eine bestimmte Norm erfüllen.
Verschiedene Begriffe, gleiches Prinzip
Was bedeutet es also, wenn ein Softwaremodul zum Beispiel „den Anforderungen der DO-178C entspricht“ oder nach „IEC 61508 zertifiziert“ wurde? Ein Entwickler, der genau wissen möchte, womit er es hier zu tun hat, sollte sich zunächst auf die angesprochene Norm und die damit verbundenen Anforderungen konzentrieren. Einige Beispiele: DO-178C gilt für die Luftfahrt, IEC 61508 für industrielle Steuerungen und IEC 62304 für medizinische Geräte. Die Ergebnisse, die für die Zertifizierung nach einer dieser Normen gefordert werden, können unterschiedliche Bezeichnungen haben. Doch obwohl sich die Terminologie unterscheidet, liegt der Einstufung ein vergleichbares Konzept zugrunde. Die Normen arbeiten mit mehreren Ebenen: Die Beschreibung eines Moduls, das für den Einsatz in Luft- und Raumfahrt gedacht ist, könnte zum Beispiel einen Verweis auf einen der fünf Design Assurance Levels (DALs) von DO-178C enthalten (A bis E). Der Text zu einem IEC 61508-Softwaremodul dürfte dagegen auf eines der Sicherheits-Integritätslevel (SIL) Bezug nehmen, die von 1 bis 4 abgestuft sind. Die Grundidee ist die gleiche: Je nach der Wahrscheinlichkeit oder der Schwere eines Fehlers dieses Elements wird einem System oder Sicherheitsmechanismus eine Ebene zugewiesen. Konkreter zeigen das die Beispiele in der Grafik: So bezeichnet DO-178C von DAL A ein System, dessen Ausfall einen katastrophalen Effekt auf ein Flugzeug hätte. Bei DAL E wäre das kein Sicherheitsproblem. Beachten Sie, dass die Zahlenangaben für IEC 61508 die Ausfallwahrscheinlichkeit darstellen, nachdem Sicherheitsmaßnahmen umgesetzt wurden. Damit sind die niedrigsten Wahrscheinlichkeiten den Systemen zugeordnet, bei denen die Nichteinhaltung der Anforderungen die schwersten Folgen hat – dies sind also die Systeme, die den stärksten Sicherheitsmaßnahmen unterworfen sind.
Integration zertifizierter Module
Im nächsten Schritt geht es um die Softwarekomponente und ihre Zertifizierung. Dazu sollte man als Entwickler wissen, dass die Anbieter eingebetteter Software darunter nicht alle dasselbe verstehen. Es ist deshalb wichtig, die Definition des Anbieters zu kennen. Denn dieser Punkt kann sich erheblich auf Aufwand und Kosten auswirken, wenn man diese Software in ein System integriert, das am Schluss selbst zertifiziert werden soll. Verwendet man ein zertifiziertes Softwaremodul in einem System, bedeutet das gewöhnlich nicht, dass damit das gesamte System von einer Zertifizierung befreit ist. Wer also eine Luft- und Raumfahrt-Anwendung entwickelt, die eine DAL-B-Zertifizierung nach DO-178C erfordert, kann nicht einfach die Anforderungen dieser Norm erfüllen, indem er einen Echtzeit-Kernel verwendet, von dem behauptet wird, für DO-178C-Projekte nach DAL B geeignet zu sein. Das endgültige System des Entwicklers und der gesamte darin enthaltene Code werden am Schluss der Zertifizierung unterworfen sein. Der Kernel-Code ist dabei natürlich nur ein Bestandteil des Systems.
Das bedeutet keineswegs, dass es für Entwickler in sicherheitskritischen Bereichen nicht interessant ist, einen irgendwie zertifizierten Kernel einzusetzen. Solche Software kann eine enorme Menge an Zeit und Mühe sparen. Ein wichtiger Vorteil ist, dass Entwickler durch ein Softwaremodul, das eine oder mehrere Zertifizierungsnormen unterstützen soll, Zugang zu wichtigen Information erhalten. Wirbt ein Kernel zum Beispiel mit IEC-61508-Compliance, so sollte der Entwickler Daten zu den festgelegten Anforderungen, zu Testergebnissen und anderen Dokumenten bekommen, die erforderlich sind, um den Kernel in einem 61508-zertifizierten System zu verwenden.
Nicht alles selbst machen
Da die Leistungen für ein Stück Software von der Komplexität eines Kernels mehrere Arbeitsjahre umfassen können, hat es für Entwickler natürlich seinen Reiz, dies selbst zu erstellen. Doch es gibt gute Gründe, auf Softwarekomponenten zurückzugreifen, die bereits mehrfach zertifiziert wurden. Ein solcher Zertifizierungs-Hintergrund bietet eine zusätzliche Absicherung, dass das Softwaremodul nicht zur Quelle größerer Probleme oder Verzögerungen wird, wenn das System, in dem es enthalten ist, den Zertifizierungsprozess durchläuft. Eine lange Geschichte von Zertifizierungen ist einer der Gründe, warum der µC/OS-II-Kernel von Micrium immer wieder für sicherheitskritische Anwendungen verwendet wird. Er wird seit dem Jahr 2000 in einer großen Anzahl von zertifizierten Projekten der Luft- und Raumfahrt, Medizintechnik und in industriellen Steuerungen eingesetzt und ist damit eine risikoarme Wahl für Entwickler.
Es gibt eine weitere, noch höhere Ebene der Risikoreduzierung und Zeitersparnis, und vielleicht ist dies die Kategorie von Softwarekomponenten, die den Begriff „zertifiziert“ wirklich verdient. Diese Softwaremodule besitzen tatsächlich ein Zertifikat, das ihre Übereinstimmung mit einer bestimmten Norm bestätigt. Das Zertifikat zusammen mit dem Nachweis, dass das Modul nach den geltenden Sicherheitsrichtlinien verwendet wird, ist im Wesentlichen ein Ersatz für die zuvor beschriebenen Arbeitsergebnisse der Zertifizierung. µC/OS-II von Micrium ist wieder eine Möglichkeit für Entwickler, die diesen Ansatz wählen möchten. In diesem Fall würde der Kernel von Embedded Office zur Verfügung gestellt, einem Micrium-Partner, der eine leicht modifizierte Version von µC/OS-II als Teil der Pakete namens „Cert-Kits“ (nach DO-178C, IEC 61508, IEC 62304 und EN 50128) anbietet.
Die Zertifizierung nach einer der verbreiteten Normen für sicherheitskritische Anwendungen ist keine einfache Angelegenheit. Die Entwicklung von entsprechenden Systemen ist eine herausfordernde Aufgabe – und sie kostet Zeit. Allerdings können Entwickler, die sich mit den Grundlagen der Zertifizierung und dem Angebot an sicherheitskritischer Software auseinandergesetzt haben, ihre eigene Arbeit erleichtern und erreichen, dass die Zertifizierung ihrer Systeme schneller abgewickelt wird.
