- IT&Production - https://www.it-production.com -

Softwarekomponenten vor dem Einsatz analysieren

Commercial off the shelf-Komponenten

Softwarekomponenten vor dem Einsatz analysieren

Bei der Entwicklung neuer Produkte greifen viele Unternehmen auf Commercial off the shelf Hard- und Software-Komponenten zurück. Dabei gilt es sicherzustellen, dass sich diese in die Funktion eines Produktes oder Systems reibungs- und problemlos einfügen. Beim Einsatz solcher Softwarekomponenten im Bereich der Funktionalen Sicherheit muss eine Untersuchung im Vorfeld Gewissheit bringen. Dabei helfen Analyse-Anwendungen für Failure Modes Effects and Diagnostic Analysis.

Bild: © Oliver Sved / Fotolia.com

Der Druck wird immer größer, neue und umfangreichere Produkte schneller zur Marktreife zu bringen – auch für Hersteller im Umfeld der Funktionalen Sicherheit. Eine Herausforderung dabei ist, diese Produkte auch bei Einsatz von Zukaufteilen ’sicher‘ zu realisieren. Die (Wieder) Verwendung von bereits fertig erstellten Software- und Hardwarekomponenten in der Entwicklung bietet sich oft als eine Möglichkeit, um Kosten zu reduzieren und Projektrisiken zu minimieren, an. Bei solchen Komponenten spricht man auch von COTS (Commercial off the shelf) beziehungsweise SOUP (Software of unknown pedigree). In Produkten im Umfeld der funktionalen Sicherheit ist der Einsatz von COTS oder SOUP nicht verboten, erfordert jedoch eine genaue Betrachtung der Risiken, die durch den Einsatz der Komponenten entstehen. Unter Umständen sind dann zusätzliche Maßnahmen in der Entwicklung vorzusehen. Die Aufgabe bei Safety-Projekten lautet: Kann einer COTS vertraut werden, sicherheitsrelevante Funktionen auszuführen, beziehungsweise kann eine COTS die Ausführung einer sicherheitsrelevanten Funktion des ansonsten ’sicher‘ entwickelten Systems verhindern?

Verschiedene Szenarien

Beim Einsatz von COTS sind verschiedene Szenarien zu unterscheiden. Das erste beschreibt den Idealzustand: Die Softwarekomponente besitzt ein Zertifikat entsprechend der für den Einsatz des Produktes relevanten Norm und erfüllt auch die Anforderungen bezüglich des beabsichtigten Sicherheitslevels. Da die Komponente somit den gleichen Standard wie die sicherheitsrelevanten Funktionen des ansonsten ’sicher‘ entwickelten Systems erfüllt, fällt bei diesem Szenario meist sehr wenig an Zusatzaufwand an. Es können jedoch auch in diesem Fall zusätzliche Anforderungen während der Entwicklung zu erfüllen sein, wie sie im Safety-Manual der COTS genannt werden.

Szenario Typ Zwei beschreibt den noch als vorteilhaft zu sehenden Fall, dass die Softwarekomponente zwar ein Zertifikat besitzt, dies jedoch nur für eine anwendungsnahe Norm und damit nur für ein vergleichbares Sicherheitslevel. Eine Analyse, welche die Unterschiede in den betreffenden Normen beziehungsweise der in den Normen definierten Sicherheitslevel berücksichtigt, führt hier zu den Anforderungen und Testfällen, die während der Entwicklung zusätzlich zu den im Safety-Manual der COTS genannten zu erfüllen sind. Im Szenario Drei besitzt die Softwarekomponente kein Zertifikat. Dies ist dann der arbeitsintensivste Fall, trotz oder gerade wegen des Einsatzes von COTS. In diesem Fall bietet sich eine Analyse auch unter dem Gesichtspunkt an, ob eine sichere Neuentwicklung der Komponente nicht unter Umständen die effizientere Lösung für das Projekt sein kann.

Vorgehensweise beim Einsatz

Wie ist nun die Vorgehensweise beim Einsatz einer solchen Komponente in einem sicheren System? Ausgehend von der Worst- Case-Annahme, dass die Softwarekomponente Fehler einbringt, die das System beeinflussen können, erfolgt eine Analyse unter der folgenden Fragestellung:

Im nächsten Schritt ist zu prüfen, welche bereits getroffenen Maßnahmen im System diese Fehler adressieren. Ist hier keine Maßnahme zu identifizieren, müssen neue, dem Fehler angemessene Maßnahmen im System getroffen werden. Für diese Maßnahmen sind neue Anforderungen und damit einhergehende Testfälle zu definieren und umzusetzen. Das angestrebte Ziel ist die Validierung, dass der Einsatz der COTS durch die getroffenen Maßnahmen keinen negativen Effekt auf das System haben kann. Als ein geeignetes Analyseverfahren für Softwarekomponenten bietet sich das Erstellen einer Failure Modes Effects and Diagnostic Analysis (FMEDA) an. Die FMEDA ist ein Verfahren zur detaillierten Ermittlung von Fehlerursachen und deren Auswirkung auf das System. In den folgenden Beispielen wurde eine FMEDA erfolgreich umgesetzt:

Beispiel: Editor

Das erste Beispiel entspricht dem Szenario Drei: Es soll ein neuer Editor für eine bereits nach IEC 61508 2nd Edition SIL 3 zertifizierte Programmers Workbench erstellt werden. Dabei handelt es sich um den Cause and Effect Editor (C&E) von infoteam, eine .NET-Anwendungskomponente. Aufgrund ihrer Schnittstellen ist sie für eine Integration in Programmiersysteme konzipiert. Die wesentliche Anpassung besteht in der Erstellung eines Postprozessors für die Zielsprachen C, ST, AWL oder eine beliebige andere Syntax, in welche die C&E-Diagramme übersetzt werden sollen. Varianten der Integration reichen von einer einfachen flachen Integration, basierend auf einer losen Kopplung wie über OPC, bis hin zu einer tiefen Integration in das Programmiersystem, dessen Variablenverwaltung, Online- und Debugging-Funktionen.

Als COTS wiederverwendet wird dabei die Programmumgebung Microsoft Windows, die aber kein Zertifikat gemäß IEC 61508 besitzt. Eine sichere Neuentwicklung des Betriebssystems Microsoft Windows stellt jedoch im vorliegenden Fall keine Alternative dar. Während der Software FMEDA ist folgender Fehlerfall identifiziert worden: Eine Eingabe von Werten durch die Elemente, die Microsoft Windows zur Verfügung stellt, ist als nicht sicher zu betrachten. Somit ist ein Wert nach der Eingabe nicht identisch mit dem Wert in der Datenhaltung des Editors. Um diesen Fehler zu adressieren, wurde das Konzept ‚visuelle Diversität‘ im Editor umgestetzt. Ein weiteres Beispiel: Durch unter Microsoft Windows parallel ausgeführte Prozesse kann es zu einer Verfälschung der Daten in der Datenhaltung des Editors kommen. Dies führte zur Umsetzung einer ’sicheren Datenhaltung‘ im Editor.

Beispiel: Steuerungssystem

Um ein sicheres Steuerungssystem zu entwickeln, bedarf es aufeinander abgestimmter, sicherer Systemkomponenten, die nicht nur einzeln für sich, sondern auch in ihrem Zusammenwirken in individuellen Anwendungsbereichen verifizierbar und validierbar sind. Die infoteam Software AG zeigt mit dem iFSC-Konzept einen Ansatz zur Realisierung sicherer Funktionen und zur Entwicklung sicherer Steuerungssysteme nach individuellen Kundenanforderungen auf. Einem Szenario Typ Zwei entspricht die Umsetzung eines ‚Certification Packages‘ für folgendes Systemdesign:

Dieses System soll als Certification Package Anforderungen nach DIN EN 50128 SIL 4 erfüllen. Während der Software FMEDA ist folgender Fehler identifiziert worden: Der Scheduler des Betriebssystems aktiviert einen Prozess nicht wie vorgesehen. Als Maßnahme, um diesen Fehlerfall zu adressieren, wurde an die Hardwareentwicklung die Anforderung ‚Umsetzen eines Watchdogs‘ gestellt. In einem weiteren Beispiel werden Nachrichten an einen falschen Prozess geleitet. Als Resultat wurde für die Softwareentwicklung daher die Anforderung gestellt, einen Nachrichten-Header umzusetzen.

Risiken genau betrachten

Der Einsatz von COTS beziehungsweise SOUP in Produkten im Umfeld der Funktionalen Sicherheit ist möglich. Es bedarf aber einer genauen Betrachtung der Risiken. Der Aufwand für den Einsatz bestimmt sich dabei aus dem Typ des Szenarios. Bei einem Szenario Typ Drei sollte eine Analyse unter dem Gesichtspunkt, ob eine sichere Neuentwicklung der Komponente nicht unter Umständen die effizientere Lösung für das Projekt sein kann, als ein Teil der Entscheidungsgrundlage für die Verwendung der Komponente erfolgen. Das Erstellen einer Software FMEDA bietet sich als ein geeignetes Analyseverfahren für Softwarekomponenten an und liefert als Ergebnis eventuell zusätzliche Anforderungen und Testfälle an die Entwicklung, mit dem Ziel zu validieren, dass der Einsatz der COTS beziehungsweise SOUP keinen negativen Effekt auf das zu entwickelnde ’sichere System‘ hat.