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: Die neunte Ausgabe von Rockwell Automations „State of Smart Manufacturing“ Report liefert Einblicke in Trends und Herausforderungen für Hersteller. Dazu wurden über 1.500 Fertigungsunternehmen befragt, knapp 100 der befragten Unternehmen kommen aus Deutschland. ‣ weiterlesen
KI in Fertigungsbranche vorn
- Zertifizierte Hardware Plattform (DIN EN 50128 SIL 4)
- Zertifiziertes Betriebssystem (IEC 61508 1st Edition SIL 3)
- Zertifiziertes Board Support Package (DIN EN 50128 SIL 4)
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.
