Warum kompliziert, wenn es auch standardisiert geht Ein Masterplan für alle Normen und Stufen der funktionalen Sicherheit

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Insider Research

Die Zertifizierung der funktionalen Sicherheit eines Systems ist komplex. Umso wichtiger ist es, die verschiedenen involvierten Stellen – einschließlich der Software-Entwicklung – rational zu orchestrieren. Wohl dem, der alle Prozesse vollständig im Blick hat.

Zur funktionalen Sicherheit (FuSi) haben alle beteiligten Hersteller ihren normenkonformen Beitrag zu leisten – von der Hardware mit seinen BSPs und Treibern über das Hypervisor- und Betriebssystem bis hin zum Applikationscode vom OEMs und Drittanbietern. Das hardwarespezifisch optimierte Betriebssystem und der bei Mixed-Critical-Systemen zum Einsatz kommende Hypervisor haben – zwischen Hardware und Applikation liegend – hier eine Schlüsselfunktion.

Wird dieser alles verbindende Funktionsblock nach einem harmonisierten Masterplan entwickelt, der für alle Standards und Stufen der funktionalen Sicherheit anwendbar ist, kommen OEM bei der konkreten Zertifizierungsaufgabe schneller und sicherer ans Ziel. Vollen Nutzwert entfaltet ein solcher Masterplan, wenn Teilfunktionen eines Mixed-Critical-Systems unterschiedliche Sicherheitslevel erreichen sollen und neben der Safety- auch noch die Security-Zertifizierung abzudecken ist.

Unterschiedliche Sicherheitslevel erfüllen

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.

Sowohl in den grundlegenden Anforderungen als auch bei der konkreten Zertifizierung und den dafür erforderlichen Dokumentationen gibt es nämlich große Unterschiede, die es punktgenau zu erfüllen gilt. 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 Automobilindustrie 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).

Letztere stellen derzeit das wohl größte Anwendungsfeld dar, weil 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. Deshalb werden 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.

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.

Infolgedessen 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 lassen sich identifizierte Schwachstellen im Rahmen des Projekts ausbessern oder Alternativen 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.

Darüber hinaus ergibt 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 allein beschränkt.

Synergieeffekte zwischen Safety- und Security-Zertifizierung

Die Prozesse, die man für eine Safety-Zertifizierung genutzt hat, lassen sich auch für Security-Zertifizierung heranziehen. 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 Anfälligkeiten und 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 selbst entwickelt Safety- und Security-Zertifizierungen des eigenen Betriebssystems PikeOS sowie kundenspezifische I/O und hardwarenahe Treiber und unterstützt somit einen Masterplan. Zusätzlich greift dieses Prinzip bei kundenspezifischen Lösungen auch innerhalb der Systemintegration. Zudem bietet PikeOS ein Bundle aus Echtzeit-Betriebssystem und Type-1-Echtzeit-Hypervisor, das bereits in vielen Branchen nach den höchsten Sicherheitsstufen der funktionalen Sicherheit zertifiziert wurde und dessen Separation Kernel der Version 5.1.3 zudem 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.

* Sven Nordhoff ist Director Certification bei Sysgo

(ID:49044452)