Die Prozesse der Softwareentwicklung sind für jedweden Anwendungsfall der funktionalen Sicherheit zwar in weiten Teilen identisch. Das, was für die jeweilige Branchenzertifizierung ganz konkret verlangt wird, ist oftmals jedoch sehr spezifisch. Selbst wenn eine Software höchste Anforderungen wie den DO 178C-Level A erfüllt, der in der Luftfahrtbranche zum Einsatz kommt, kann sie nicht 1:1 für die ISO 26262 Zertifizierung der Automotive-Branche genutzt werden, da es sowohl Nuancen in den grundlegenden Anforderungen, als auch große Unterschiede bei der konkreten Zertifizierung und den dafür erforderlichen Dokumentationen gibt, die es punktgenau zu erfüllen gilt.

Unterschiedliche Sicherheitslevel erfüllen

Heterogene Anforderungen gibt es aufgrund der unterschiedlichen Sicherheitslevel selbstverständlich auch innerhalb einer jeden einzelnen Zertifizierungsnorm. In der Avionik gibt es beispielsweise den DO-178C Level A, der für den Schutz vor einem „catastrophic effect“ geschaffen wurde – ganz konkret also für den Schutz vor einem Flugzeugabsturz. Hierfür sind höchstredundante Systeme und Software zu entwickeln. Beim DO-178C Level D, der für Software gilt, die bei Versagen die Sicherheitsmarge nur geringfügig verändert – also beispielsweise die Arbeitsbelastung der Besatzung geringfügig verändert, zu Unannehmlichkeiten für Passagiere oder zu einer routinemäßigen Flugplanänderung führt – sind die Anforderungen deutlich geringer. Aufwendungen, die man für den höchsten Level tätigen muss, will man für niedrigere Level nicht tätigen, weil sie natürlich Zeit und Geld kosten. Ein ähnliches Konzept verfolgt quasi jeder Zertifizierungs-Standard der einzelnen Industriebereiche. So ist der ISO 26262 ASIL-D der Automobil-Industrie für die höchste funktionale Sicherheit, der ASIL-A für die niedrigste Stufe vorgesehen.

Dennoch kann man ein und dasselbe Master-Prozessmodell nutzen, um alle Anforderungen der unterschiedlichen Normen und Level für Funktionale Sicherheit (FuSi) mittels standardisierter Vorgehensweisen erfüllen zu können. Der Prozess muss lediglich die für den konkreten Anwendungsfall erforderliche Route nehmen können, um bei minimalem Aufwand das jeweils geforderte Ergebnis einer normenkonform zertifizierbaren Lösung zu schaffen – ganz gleich, welche Norm nun erreicht werden soll.

Unterschiedliche Branchen bedienen

Ein solch branchenübergreifendes Prozessmodell ist beispielsweise für Lösungsanbieter interessant, die Steuerungen mit integrierter Situationserkennung entwickeln. Sie wollen ihre Technologie mit immensem Wachstumspotenzial schließlich in möglichst allen Branchen vertreiben: Von autonomen kollaborativen Robotern (IEC 61508) und bildgeführter Operationsrobotik (IEC 62304) über automatisiert geführte innerbetriebliche Logistikfahrzeuge und autonome Landmaschinen bis hin zu autonomen Bahnen (EN 50128), Flugzeugen (DO178C) und Drohnen sowie selbstverständlich für Kraftfahrzeuge (ISO26262), die derzeit das wohl größte Anwendungsfeld überhaupt darstellen, da für die e-Mobilität und das autonome Fahren zahlreiche neue Lösungen entwickelt werden. Und selbst im Automotive-Bereich gibt es aufgrund der unterschiedlichen Autonomielevel unterschiedliche Anforderungen an die funktionale Sicherheit.

Geht es hier beispielsweise um die Kollisionsvermeidung mit zunehmend komplexer Logik zur Entscheidungsfindung auf Basis der Daten von unterschiedlichster Sensorik, die zur Umwelterkennung eingesetzt wird, wird die Aufgabe, eine ASIL D konforme Logik zu entwickeln, extrem komplex, weshalb hier bereits Ansätze diskutiert werden, wie man die Umwelterkennung mit spezifischen Methoden (z.B. SOTIF-Tests, HARA-Analysen) ohne die komplexen Entwicklungs-Anforderungen der ISO26262 ausführen kann. [1]

Zertifizierbare funktionale Sicherheit ist also schon aufgrund der Vielfalt der möglichen unterschiedlichen Anforderungen und damit einhergehenden erforderlichen Lösungsansätze keine einfache Aufgabenstellung. Sie erfordert vielmehr profundes Know-how bezüglich der einzelnen Normen, ihrer unterschiedlichen Sicherheitslevel und den sich daraus ergebenden unterschiedlichen Anforderungen an die Softwarefunktionalität und die Prozesse, wie man zu ihr kommt und wie man dies auch zertifizierbar dokumentiert.

Die Anforderungen beziehen sich zudem selbstverständlich nicht nur auf den eigentlichen Applikationscode. Die Lösung ist vielmehr in ihrer Gesamtheit zu betrachten. Bei Embedded- und Edge-Computing-Systemen geht es also immer auch um das Zusammenspiel von Hardware, Betriebssystem und Drittsoftware mit dem Applikationscode des Lösungsanbieters.

Mixed-Critical-Applikationen entwickeln

Aufgrund höher integrierter Prozessortechnologie werden die Aufgabenstellungen zudem zunehmend komplexer: Wurden einzelne Aufgaben einer Gesamtlösung je nach Level ihrer funktionalen Sicherheit früher diskret auf dedizierte Controller verteilt und Zertifizierungen einzeln angegangen, ist es heute das Ziel, Mixed-Critical-Systeme auf heterogenen SoCs (System-on-Chip) zu integrieren. Infolge multiplizieren sich die Aufgaben und Interdependenzen, sodass ganzheitliche Lösungsansätze gefunden werden müssen. Ansonsten kann man sich nämlich verzetteln und Effizienzsteigerungspotenziale lassen sich nicht nutzen, wenn für einzelne Teilaufgaben unterschiedliche Herangehensweisen gewählt werden.

Wie geht man also eine Zertifizierung bei zunehmender Komplexität möglichst effizient an? Grundsätzlich lässt sich der Prozess unabhängig von der Komplexität der Gesamtlösung in vier Phasen unterteilen. Zuerst kommt die grundlegende Planung, danach die eigentliche Entwicklung gefolgt von der Analyse und Verifizierung des Ergebnisses bis man am Ende des Prozesses das System abschließend für die Zertifizierung qualifiziert.

Alle Prozessbeteiligten orchestrieren

Bereits in der Planungsphase sind die Grundlagen einer erfolgreichen Zertifizierung zu entwickeln. Nach der Festlegung der angestrebten Normen und Zertifizierungsprozesse gilt es im ersten Schritt, die Expertise aller beteiligten Partner in Bezug auf die avisierten Normen zu analysieren. Gegebenenfalls sind identifizierte Schwachstellen im Rahmen des Projekts ausbesserbar oder Alternativen zu finden. Nicht ohne Belang ist auch das Zusammenspiel aller Partner von der Hardware mit Sicherheitsnachweis über das zertifizierbare Betriebssystem bis hin zur Applikationssoftware, da alle Parteien in der Regel unterschiedliche Interessen haben und ihren Aufwand minimieren wollen. Hier sind ein gemeinsames Verständnis in Bezug auf die Zuständigkeiten zu schaffen und Aufgaben eindeutig zuzuordnen. Jede gekaufte Komponente hat schließlich auch „Usage Constraints“, die es zu beachten gilt bzw. die zwischen den einzelnen Entitäten abgestimmt werden müssen.

Für Mixed-Critical-Applikationen, die auf heterogenen SoCs basieren, ist zudem sicherzustellen, dass nicht-zertifizierbare Software-Komponenten wie ein Linux-basiertes GUI mittels Separation-Kernel und Hypervisor-Technologie von sicherheitsrelevanten Instanzen getrennt werden. Durch die Verlagerung in eine sauber und sicher abgrenzbaren Partition, die keinen kritischen Code ausführt, kann sichergestellt werden, dass sie keinerlei Auswirkung auf die zu zertifizierenden Teile des Systems haben. Je mehr Funktionen man auf diese Weise aus der Zertifizierung ausklammern kann, desto geringer der Aufwand. Soll das GUI jedoch ebenfalls funktional sicher sein, muss es Bestandteil des Safety-Engineering-Prozesses werden. Je vielfältiger und heterogener die Safety-Anforderungen einer Gesamtapplikation sind, desto wichtiger wird der Masterplan.

Auch ist die Selektion der Zertifizierungsstelle nicht unerheblich, da von ihr auch abhängt, welche Grundlagen bis wann für die konkreten Audits der Zertifizierung zu schaffen sind. Zudem macht es Sinn, diese Autoritäten direkt in der Planungsphase in die Prozesse zu integrieren. So können sie die aufzusetzenden Planungsdokumente auch direkt überprüfen. Namentlich sind dies der Safety Plan, die Entwicklungspläne (Development, Verifikation und Validation, Qualität und Konfigurations-Management) und insbesondere die Compliance-Tabellen, in denen ausgeführt wird, mit welchen Prozessen man welche Normen-Teile erfüllt.

Master-Safety-Plan und Compliance-Tabellen für alle Zertifizierungsanforderungen

Genau an dieser Stelle ist es enorm vorteilhaft, einen Master-Safety-Plan für alle Zertifizierungsanforderungen zu haben. In ihm wird unter anderem festgelegt, wie das Betriebssystem und seine BSPs und hardwarenahen Treiber entwickelt, validiert, getestet und dokumentiert werden. Dieser kann dann unterschiedliche Routen nehmen, je nachdem für welchen Standard und welchen Sicherheitslevel die Lösung entwickelt werden soll. Unterstützt wird dieses Vorgehen durch Compliance-Matrizen für jede Zertifizierungsnorm, die auf ein generisches Entwicklungskonzept aufsetzen.  

Vorteilhaft für Kunden ist dabei, dass der Aufwand für die Erstellung der Safety-Pläne deutlich minimiert wird, da es bereits einen Masterplan gibt, der für alle Normen adaptierbar ist. Auch ist durch zahlreiche Zertifizierungen bereits belegt, dass sie die Anforderungen an die Zertifizierung vollumfänglich erfüllen, was Kunden entsprechende Verfahrenssicherheit bietet. Schlussendlich schafft ein Masterplan auch die Grundlage, Zertifizierungen einer Branche leicht in andere Branchen portieren zu können oder ursprünglich niedrigere Sicherheitslevel einfacher auf höhere Level heben zu können, da alles ineinandergreift. Evaluiert man also beispielsweise, Funktionen für das autonome Fahren zukünftig auch für höhere Autonomielevel zu zertifizieren, als aktuell angestrebt, kann man bereits im Rahmen der aktuellen Entwicklungen die Grundlagen für spätere Upgrades schaffen. Durch einen solchen Masterplan und mit Hilfe von adaptierbaren Compliance-Matrizen schützt man sich auch vor Sackgassen in der Entwicklung, die man nicht erkennt, wenn man sich auf den jeweils ganz konkreten Projektfokus alleine beschränkt.

Synergieeffekte zwischen Safety- und Security-Zertifizierung

Die Prozesse, die man für eine Safety-Zertifizierung genutzt hat, können auch für Security-Zertifizierung herangezogen werden. Im Umkehrschluss ergibt sich daraus der Vorteil, dass Safety-Entwicklungen, die auf Basis eines Safety & Security Masterplans entwickelt wurden, bereits wesentliche Grundlagen für die Security-Zertifizierung schaffen. Für die Security-Zertifizierung einer Safety-Applikation sind dann nur noch die Elemente zu ergänzen, die nicht bereits über die Safety-Zertifizierung abgearbeitet wurden. Derart ganzheitlich integrierte Lösungsansätze bieten dem OEM deutliche Effizienzsteigerungen, da alles ineinandergreift und aufeinander abgestimmt ist.

Aufgaben, die über die Safety-Zertifizierung hinausgehen sind beispielsweise die Implementierung eines Secure Developments zur Vermeidung der Infiltrierung durch Schadcode. Auch muss sichergestellt werden, dass Schwachstellen NICHT offengelegt werden, damit Hacker diese nicht auf dem Tablett serviert bekommen, um sie ausnutzen zu können. Auch sind zusätzliche Vulnerability-Analysen bzw. Penetrationstests typischerweise nicht Bestandteil einer Safety Zertifizierung, für eine Security Zertifizierung aber unerlässlich. Die Spezifikation, wie Requirements ausgelegt sein sollten und dass es einen Code-Review geben muss, um Vulnerabilitäten/Schwachstellen zu evaluieren, kann bereits den Safety-Spezifikationen entnommen werden. So können Projekte mit Safety- und Security-Zertifizierung von Anfang an harmonisiert angegangen werden. Beim Thema Security kann man sich schlussendlich vollkommen auf das konzentrieren, was speziell für Security erforderlich ist, was wiederum Effizienzsteigerungspotenziale mit sich bringt.

In heutigen Zeiten wird man Safety- und Security ohnehin nicht mehr voneinander trennen können, denn Safety kann es bei IoT-angebundenen Devices ohne Security eigentlich gar nicht mehr geben. Insofern werden Masterpläne für eine ganzheitliche Sicherheit ohnehin mandatorisch. Haben Applikationsentwickler für Safety ihren OS-Zuschnitt folglich bereits nach einem solchen Masterplan entwickeln lassen, kann eine spätere Security-Zertifizierung ’davon profitieren.

Ganzheitlicher Lösungsbaukasten

SYSGO ist ein Unternehmen, das Safety- und Security-Zertifizierungen für das eigene Betriebssystem PikeOS sowie für kundenspezifische I/O und hardwarenahe Treiber durchführt in Zusammenarbeit mit Autoritäten und Prüflaboren und somit einen solchen Masterplan vollumfänglich unterstützt. Zusätzlich unterstützt Sysgo dieses Prinzip bei kundenspezifischen Lösungen auch innerhalb der Systemintegration. Zudem bietet es mit PikeOS ein Echtzeit-Betriebssystem und Type 1 Echtzeit-Hypervisor Bundle an, das bereits in vielen Branchen nach den höchsten Sicherheitsstufen der funktionalen Sicherheit zertifiziert wurde und dessen Separationkernel der Version 5.1.3 zudem nachweislich höchste Security-Levels bis hin zum Common Criteria Evaluation Assurance Level EAL 5+ erreicht. Mit ELinOS bietet das Unternehmen auch eine Embedded Linux Distribution an, die in Mixed-Critical-Applikationen die nicht primär zu zertifizierenden Applikationen hosten kann. Die gesamte Mixed-Critical-Applikation lässt sich zudem in einer einzigen integrierten Entwicklungsumgebung CODEO entwickeln. Auch ist der Datenaustausch zwischen funktional sicheren und sonstigem Applikationscode in verschiedenen Partitionen mittels dedizierter „Communication Ports“ orchestrierbar, sodass die Zustellung von Nachrichten garantiert ist. Und dies auch ganz gleich zwischen welchen OS oder welcher Art von Prozessor (MMU oder MPU) kommuniziert werden soll. Das gesamte Zusammenspiel von Mixed-Critical-Applikationen ist bereits in den Safety & Security Masterplänen eingearbeitet und im Rahmen von Kundenprojekten der gesamte Prozess umfassend durch Beratungs- und Schulungsangebote flankiert, sodass OEM schneller und sicherer ans Ziel kommen, als wenn sie eigenständig versuchen, ihr spezifisches Lösungspaket auf Basis heterogener Komponenten zu schnüren. Schlussendlich ist es ja der Applikationscode, der wettbewerbsentscheidend ist. Alles weitere überlässt man lieber den Experten, die tagtäglich nichts anderes machen, als Kunden den Technologiebaukasten bereitzustellen und sie bei der Erstellung hardwarespezifisch optimierter Betriebssystem- und Hypervisor-Zuschnitte zu unterstützten.

Mehr Informationen unter www.sysgo.com/pikeos

Quellen Informationen

[1] Source: Elektroniknet.de, Roland Rathmann, May 5, 2021, retrieved June 12, 2022 https://www.elektroniknet.de/automotive/assistenzsysteme/umwelterkennung-nach-iso-26262.186049.html