Safety-Software gemäß IEC 61508-3
Modellbasiertes Testen sicherer Funktionsbausteine
Spätestens seit der zweiten Fassung der IEC 61508 hat in der Sicherheitstechnik das modellbasierte Testen Einzug gehalten. Ein wesentlicher Teil davon ist die automatisierte Testfallgenerierung. Bei richtiger Anwendung steigert diese Methode die Qualität deutlich – bei signifikanter Kostensenkung.
Sicherheitsgerichtete Funktionsbausteine für IEC-61131-Programmiersysteme werden häufig mit semiformalen Methoden wie dem Zustandsübergangsdiagramm spezifiziert (zum Beispiel PLCopen). Auf Basis dieser Zustandsübergangsdiagramme beziehungsweise den vorhandenen Systemmodellen lassen sich automatisiert Testdaten und Testfälle erzeugen mit dem Ziel, die normativ geforderte Testabdeckung zu erreichen. Neben der reinen Testfallerzeugung umfasst die im Folgenden geschilderte Lösung für das sichere IEC-61131-Prorammiersystem Safeprog eine automatisierte Testdurchführung sowie Testauswertung. Die Testdurchführung kann sowohl in einer Simulationsumgebung auf einem PC als auch auf einer realen Sicherheitssteuerung erfolgen. Somit ist auch der Test sicherer Firmware-Funktionen möglich.
Doch der Reihe nach. Die zentrale Frage bei jedem Software-Test lautet: Wann ist eine Funktion hinreichend getestet? Insbesondere auf der Ebene des Komponententests hat sich die sogenannte Code Coverage (Code-Abdeckung) als Maßzahl etabliert. Darunter versteht man den Anteil des Quellcodes, welcher in einem Test durchlaufen wird. Die Norm IEC 61508 empfiehlt diesbezüglich den Einsatz folgender Code-Coverage-Verfahren:
Entry Point Coverage
Die einfachste Ausprägung der Code Coverage ist die Entry Point Coverage. Diese Methode weist lediglich die Existenz einer spezifizierten Funktion nach und ist aufgrund der daraus resultierenden sehr geringen Aussagekraft nicht geeignet, die funktionale Testtiefe zu quantifizieren.
Bild 1. Veranschaulichung der Code-Coverage-Verfahren 'Statement Coverage' und 'Branch Coverage'. Das Beispiel zeigt die Summenbildung der Absolutwerte der Operanden a und b. Auf Basis des Quellcodes wird ein Automat beschrieben. Die grün eingefärbten Zustände und Kanten zeigen die entsprechende Code-Coverage-Methode.
© KW-SoftwareStatement Coverage
Bei der prozeduralen Programmierung – wozu auch die klassische SPS-Programmierung mit Funktionsbausteinsprache (FBS) oder strukturiertem Text (ST) zählt – ist es auf einfache Weise möglich, ein Programm als Automaten darzustellen. Die Statement Coverage beschreibt den Anteil der im Test abgedeckten Anweisungen beziehungsweise der Zustände im Automaten.
Branch Coverage
Die Branch Coverage erweitert die Statement Coverage um den Anteil der im Test durchlaufenen Kanten des Automaten. Bild 1 illustriert die beiden letztgenannten Verfahren. Das Beispiel zeigt die Berechnung einer Summe aus den Absolutwerten zweier Operanden.
Modified Condition/Decision Coverage (MC/DC)
Verzweigen in einem Zustand des Automaten verschiedene Pfade, so kommt die Modified Condition/Decision Coverage ins Spiel. Dabei werden zusammengesetzte Entscheidungen in ihre atomaren Bedingungen zerlegt.
Im Test wird nachgewiesen, dass jede atomare Bedingung, unabhängig von den übrigen Bedingungen, die Gesamtentscheidung auf 'true' und 'false' beeinflusst. Folgendes Beispiel verdeutlicht das Verfahren:
Die Entscheidung ((a OR b) AND c) besteht aus den atomaren Bedingungen (a OR b) und c. Für die vollständige Code Coverage mittels MC/DC ergeben sich mögliche Testfälle (siehe Tabelle links).
Die Norm IEC 61508 empfiehlt für Software in programmierbaren elektronischen Systemen bis SIL 3 das Erreichen von 100 % MC/DC. Für SIL 4 wird aus dieser Empfehlung eine Vorgabe. Wendet man das Verfahren auf Funktionsbausteine an, so ist schnell erkennbar, dass bereits bei geringer Komplexität mehrere Tausend Testfälle nötig sind. Typische Funktionsbausteine, wie sie beispielsweise die PLCopen (Technical Committee 5) spezifiziert, benötigen durchaus mehrere Millionen Testfälle, um die normativ geforderte Code Coverage zu erzielen.
Diese Zahlen machen deutlich, dass solche Tests nur Software-unterstützt erfolgen können. Mit anderen Worten: Sowohl Testfallgenerierung als auch -durchführung müssen vollständig automatisiert sein. Dieses Ziel kann durch modellbasiertes Testen erreicht werden.
Wie erwähnt, basiert das modellbasierte Testen auf einem formal beschriebenen Systemmodell. Letzteres ergibt sich aus der Spezifikation, die aus den Anforderungen abgeleitet ist. Es beschreibt das Systemverhalten des Funktionsbausteins und bildet die Grundlage für seine Programmierung. Für die formale Spezifikation bietet sich der Einsatz bekannter Notationen wie der Unified Modeling Language (UML) an.
Bild 2. Die Abbildung zeigt einen exemplarischen Ausschnitt aus einem UML- (Unified Modeling Language) Zustandsdiagramm, welches zur Modellierung eines sicheren Funktionsbausteins zum Einsatz kommt. Jeder Zustand definiert sein statisches Ausgangsabbild. Der Übergang von einem Zustand in einen anderen erfolgt mittels Transitionen. Letztere enthalten Bedingungen und Prioritäten, welche einen Zustandsübergang auslösen.
© KW-SoftwareBild 2 zeigt einen exemplarischen Ausschnitt aus einem UML-State-Diagramm, welches einen sicheren Baustein modelliert. Das davon abgeleitete Testmodell des spezifizierten Funktionsbausteins ist der zentrale Bestandteil des modellbasierten Testens und stellt den Funktionsbaustein aus Testsicht dar. Aus dem Testmodell wiederum leitet ein Testfallgenerator die konkreten Testfälle für den Funktionsbaustein ab. Ein integriertes Testsystem verarbeitet die erzeugten Testfälle entweder mittels einer Simulationsumgebung oder einer realen sicheren Steuerung. Zusätzlich bereitet das Testsystem die Ergebnisse zu einem Report auf, der für die Dokumentation und das Functional Safety Management verwendet wird.
Bild 3 zeigt die Anwendung des modellbasierten Ansatzes bei der Entwicklung sicherer Funktionsbausteine, wie sie zum Beispiel im Teil 4 der PLCopen-Spezifikation (Application Specific FBs for Presses) beschrieben sind.
Bild 3. Einsatz des modellbasierten Testens für sichere Funktionsbausteine. Einerseits werden auf Basis des Systemmodells die sicheren Bausteine implementiert, die zusammen mit der Sicherheitssteuerung das zu testende System ergeben. Weiterhin wird insbesondere aus dem Systemmodell automatisch ein Testmodell erzeugt. Dieses Testmodell dient zur Generierung der Testfälle für den Komponententest des sicheren Funktionsbausteins. Ein Testsystem ist für die automatische Testdurchführung und die Protokollierung der Ergebnisse verantwortlich.
© KW-SoftwareAus den geschilderten Eigenschaften des modellbasierten Testens ergeben sich folgende Vorteile:
Modellbasiertes Testen ist stark spezifikationszentriert. Das bedeutet, dass bereits in der Spezifikationsphase ein Schwerpunkt auf der Testbarkeit des spezifizierten Bausteins liegt. Lückenhafte oder nicht eindeutig formulierte Spezifikationen werden in einer sehr frühen Phase erkannt. Erfolgt die Spezifikationserstellung iterativ und parallel zur Testerstellung, werden Fehler im Design und in der Spezifikation frühzeitig erkannt. Mit dem Systemmodell entsteht implizit auch der Testplan.
Durch den analytischen Ansatz bei der Testfallerzeugung wird eine definierte Code Coverage erreicht. Der Einsatz eines integrierten Testsystems führt zu einer eindeutigen Wiederholbarkeit der Testdurchführung und zu einer signifikanten Kostenreduktion.
Bei Modifikationen des Systemmodells durch Erweiterungen oder die Beseitigung von Spezifikationsfehlern fallen keine oder nur sehr geringe Wartungskosten für die Testfälle an, da diese vollständig und automatisch aus dem aktuellen Systemmodell abgeleitet werden.
Die Adaption des modellbasierten Testens wurde bereits in mehreren Projekten erfolgreich als Lösung bei der Entwicklung von sicheren Funktionsbausteinen eingesetzt. Speziell eignet sich der vorgestellte Ansatz für den Bereich der Komponententests. Steckt ein Fehler allerdings bereits in den Anforderungen beziehungsweise in der abgeleiteten Spezifikation, so ist dieser Fehler auch im Systemmodell enthalten und kann hier nicht aufgedeckt werden. Fehler in den Anforderungen werden durch den Akzeptanztest, Fehler in der Spezifikation durch den Systemtest erkannt.
Ist das Systemmodell hingegen fehlerfrei, so erfüllt die aufgezeigte Entwicklung die normativen Anforderungen in Bezug auf Code Coverage mittels vollständiger Testabdeckung gemäß der Modified Condition/Decision Coverage. Geringere Werte der genannten Testabdeckung sind lediglich Spezifikations- beziehungsweise Designfehlern geschuldet. Zum Beispiel führen Überspezifizierung von Transitions-Bedingungen oder die defensive Programmierung zu Code-Passagen, die nicht erreicht werden. Dieser sogenannte 'tote Code' entzieht sich der Code Coverage. Neben der analytischen Untersuchung des entwickelten Algorithmus wurde die erreichte Code Coverage zusätzlich experimentell mittels Code-Coverage-Werkzeugen belegt.
Was die Performance der Lösung betrifft, so werden auf konventioneller PC-Hardware etwa 5.000.000 Testfälle pro Stunde generiert, deren Abarbeitung in einer PC-basierten Simulationsumgebung etwa acht Stunden erfordert. Die Performance der Testdurchführung auf einer realen Sicherheitssteuerung ist maßgeblich von der Geschwindigkeit des Datenaustauschs zwischen Testsystem und sicherer Steuerung abhängig. Durch Unterstützung von Multicore-Architekturen ist eine noch schnellere automatisierte Erzeugung von Testfällen angestrebt. Eine parallele Testdurchführung auf mehreren sicheren Steuerungen ist bereits heute möglich.
Autoren:
Dr. Tobias Frank ist Manager Safety Software bei KW-Software in Lemgo.
Harry Koop ist Test Analyst Safety Software bei KW-Software.
Das könnte Sie auch interessieren
Wandelbare Produktionssysteme
Traditionelle Sicherheitslösungen stoßen in dynamischen Produktions-umgebungen an ihre Grenzen, das heißt, es bedarf neuer, adaptiver Sicherheitsfunktionen. Wie kann das Projekt ‚SafeFloat‘ hier helfen?
mehr...Sicherheit geht vor
Die Entwicklung von Cobots zum Commodity-Produkt ist eng verzahnt mit dem Thema Safety in der Robotik – eine Herausforderung, die es effizient zu bewältigen gilt.
mehr...Zuhaltung mit Klärungsbedarf - Hilfe bei der Risikobeurteilung
Die DIN EN ISO 1419 ist bereits seit fünf Jahren verfügbar. Doch immer wieder gibt es Unsicherheiten bezüglich der eigentlichen Sicherheitsfunktionen einer Zuhaltung, die der Maschinenbauer aufgrund seiner Risikobeurteilung bewerten muss. Eine...
mehr...Sicher bedienen via Funk - (wie) geht das?
Viele Maschinenbauer möchten Tablets zusätzlich zur existierenden Maschinenbedienung verwenden. Nachgefragte Features wie WLAN, Kamera, Multitouch und vieles mehr sind hier zwar gegeben – sind allerdings Sicherheitsfunktionen gefordert, stoßen diese...
mehr...Schwerlast-MRK erfordert neue Safety-Ansätze
Das Thema MRK ist nicht nur etwas für 'Leichtgewichte'. Auch im Bereich der Schwerlast-Robotik werden künftig Lösungen gefragt sein, die eine direkte Zusammenarbeit von Mensch und Roboter ohne störenden Schutzzaun erlauben. Dies erfordert jedoch...
mehr...Validierung stiefmütterlich behandelt
Bei der Einbindung sicherheitsgerichteter Steuerungsfunktionen in Maschinen ist die EN ISO 13849 maßgeblich. Dabei wird allerdings der die Validierung betreffende Teil der Norm in der Praxis oftmals vernachlässigt – ein großes Manko.
mehr...Der intelligente Sicherheitsschalter
Auf I4.0-Niveau kommunizierende Sicherheitsmodule und Sicherheitsschalter vereinfachen die Fehlersuche. Aber auch für die vorausschauende Instandhaltung sowie den Manipulationsschutz birgt die Kommunikationsfähigkeit interessantes Potenzial.
mehr...Sicherer Halt im Schleifring
Sicherheitsrelevante Daten über Schleifringe zu übertragen ist nicht trivial. Motion-Control-Experten von Kollmorgen haben dafür gemeinsam mit dem Schleifringhersteller Stemmann-Technik eine TÜV-zertifizierte Safety-Lösung samt UL-Zulassung...
mehr...Gefährliche Bewegungen gut abgesichert
Wie lassen sich gefährliche Bewegungen absichern? Eine Herausforderung für den Anwender, da unterschiedlichsten Möglichkeiten funktionale und normative Anforderungen gegenüberstehen. Eine Übersicht.
mehr...