Tabelle 1. Dokumente des V-Modells: grün = existiert bereits in einem Projekt, gelb = nicht notwendig für einfache SPSen, blau = optional

© Hochschule Bonn-Rhein-Sieg

Daher lassen sich die Phasen „Software-Spezifikation“ und „Systemgestaltung“ zu einer Phase „Software-Entwurf“ zusammenfassen. Entsprechend wird der „Integrationstest“ mit der Phase „Validierung“ zur Phase „Software-Validierung“ kombiniert. Weiterhin macht es Sinn, die Entwicklung von eigenen Funktionsbausteinen (Modulen) in einem separaten V-Modell abzutrennen (Bild 1 unten). Damit ist das Vorgehensmodell der Norm in zwei einfachste V-Modelle zerlegt worden, die es nun zum Leben zu erwecken gilt.

Bild 2. Anlagenskizze „Roboterfertigungszelle mit zusätzlicher Schutztür“ als eines von zehn Beispielen, die im Rahmen des Projektes erarbeitet wurden.

© Hochschule Bonn-Rhein-Sieg

Die wesentlichen Inhalte der Dokumente des V-Modells in Tabelle 1 demonstriert ein Beispiel. Bei der im Folgenden betrachteten Anlage handelt es sich um eine Roboterzelle mit drei Betriebsarten (Bild 2): Der Roboter (Motor M1) füllt durch ein automatisches Tor (SG3) Schaum in ein Werkstück, das durch einen Werkstückträger bewegt werden kann (Motor M2). Nach einer definierten Aushärtezeit öffnet ein Werker das Schnelllauftor SG2 (Motor M3), entnimmt das Werkstück und säubert den Werkstückträger. SG1 ist eine Wartungstür für den Roboter. Der Werker wird vor Quetschungen durch SG2 über eine nicht abgebildete Sicherheitsleiste geschützt.

Tabelle 2. Liste der Sicherheitsfunktionen (SF). PL: Performance Level; SLS: Safely Limited Speed (Dokument A1).

© Hochschule Bonn-Rhein-Sieg

Dieser beschriebene Produktionsablauf entspricht dem Automatikbetrieb (auto). Daneben gibt es noch einen Einrichtbetrieb (setting): Der Werker öffnet in dieser Betriebsart das Schnelllauftor SG2 (SG3 ist geschlossen) und verändert im Schleichgang die Position des Werkstückträgers (Motor M2) durch Drücken eines der beiden Zustimmtaster (IS_TIP1/2). Der Not-Halt stoppt sämtliche Motoren.

Ein Resultat der Risikobeurteilung nach EN ISO 12100 (Sicherheit von Maschinen – Allgemeine Gestaltungsleitsätze –Risikobeurteilung und Risikominderung) sind die in Tabelle 2 gelisteten Sicherheitsfunktionen (Dokument A1 in Tabelle 1). Die in EN ISO 13849-1 geforderten Prioritäten und die zugeordneten Betriebsarten sind ebenfalls aufgeführt. Die aufgeführte dritte Betriebsart „All“ ist immer aktiv, obwohl die anderen Betriebsarten umschalten können. Sämtliche Sensoren, Taster und Schütze sind zweikanalig ausgeführt.

Der Motor M2 wird durch einen zertifizierten, per Feldbus angeschlossenen Umrichter angesteuert. Dieser Umrichter besitzt unter anderem die integrierten Sicherheitsfunktionen STO (safe torque off) und SLS (safely limited speed). Die relevante I/O-Liste (Dokument A2.4), welche zusätzlich Prüffelder enthält, die im Code Review (C1) und in der Software-Validierung (D1) Verwendung finden, sowie der Stromlaufplan (Dokument A2.2) und die Darstellung des Hardware-Aufbaus der SPS inklusive der Bustopologie (Dokument A2.3) sind aus Platzgründen weggelassen.

Die Modularchitektur des Safety-Programms

Bild 3 zeigt die Modularchitektur des Sicherheitsprogramms. Die SPS-Sicherheitsprogramme sind nach diesem Schema aufgebaut. Es gibt eine bekannte Eingangsverarbeitungsebene, die unter anderem aus zertifizierten Bibliotheksbausteinen (F_ESTOP1, F_SFDOOR) besteht. Hier werden die Eingangssignale etwa auf Fehler überwacht. Weiterhin wird der automatische Wiederanlauf gegebenenfalls verhindert. Zusätzlich können dort weitere, unter Umständen auch selbst entwickelte Funktionsbausteine vorhanden sein, die im Projekt bei der Abschaltlogik benötigte logische Signale erzeugen.

Bild 3. Skizze der Modularchitektur des Sicherheitsprogramms (Dokument B3).

© Hochschule Bonn-Rhein-Sieg

Ein Beispiel ist der Funktionsbaustein EN_SLS, der das Freigabesignal EN_SLS für den Einrichtbetrieb liefert. Die blau gekennzeichneten Ausgangssignale werden in der Abschaltlogik ACT (actuation) verarbeitet. Der Aufbau von ACT ist unbekannt und ist noch zu spezifizieren. Die Ausgangssignale von ACT steuern die Aktoren der Maschine an – zum Beispiel die Schütze der Motoren M1 und M3 –, welche über zertifizierte Bibliotheksbausteine (F_FDBACK) überwacht werden. Die restlichen Ausgangssignale gehen direkt in den Umrichter von M2.

Der Aufbau der Ausgangsverarbeitungsebene ist ebenfalls bekannt. Als einzige Unbekannte verbleibt also die Logik ACT. Letztere besteht ausschließlich aus einer Struktur aus UND-, ODER- und NICHT-Verknüpfungen. Das Dokument B3 enthält ebenfalls ein Prüffeld (V1), in dem gekennzeichnet wird, ob die Modularchitektur mit der Spezifikation der Sicherheitsfunktionen in Einklang ist.

Die Modularchitektur lässt sich wesentlich kompakter darstellen, wenn für alle Freigabesignale (zum Beispiel SG1_OK) von Standardkomponenten wie Schutztüren, Lichtschranke oder Not-Halt-Signalen eine Namenssystematik vorhanden ist. Dann muss dafür keine Skizze angefertigt werden. Gleiches gilt für die restlichen, in der Eingangsverarbeitungsebene gegebenenfalls noch benötigten Funktionsblöcke. Weiterhin wäre es für das verwendete Programmiersystem denkbar, dass für solche Standardkomponenten automatisch entsprechende Netzwerke angelegt werden, die vom Programmierer nur noch ergänzt werden müssten. Damit wäre schon ein hoher Prozentsatz der Anwendungen abgedeckt.

Die Spezifizierung der Logik

Bild 4. Die Ansteuerlogik (ACT): links im Bild die generische Struktur, rechts die Programmskizze (Dokument B5).

© Hochschule Bonn-Rhein-Sieg

Wie soll man nun die Ansteuerungslogik ACT möglichst einfach spezifizieren? Bild 4 zeigt links die generelle Struktur von ACT. Damit wird auch die logische Bedeutung der Prioritäten klar. Die Freigabesignale der Betriebsart „All“ haben die höchste Priorität 1 (zum Beispiel EMST_OK). Für jede weitere umschaltbare Betriebsart werden die Freigabesignale über die blauen UND-Glieder verarbeitet. Sämtliche Freigabesignale besitzen hier die Priorität 2, da diese gleichberechtigt sind. Für die Sicherheitsfunktionen, die den einzelnen Betriebsarten zugeordnet sind, gelten ähnliche Prioritätszuweisungen. Für die Spezifikation von ACT müssen also nur noch die Signale 1a, 1b, 2a, 2b usw. festgelegt werden. Das Ergebnis für ACT im betrachteten Beispiel zeigt der rechte Teil von Bild 4. Man erkennt, dass nur der STO vom Umrichter für Motor M2 (QS_M2_STO) drei Betriebsarten besitzt. Die restlichen binären Ausgangsgrößen besitzen jeweils nur eine Betriebsart. Die Betriebsarten sind links farbig gekennzeichnet.

Bild 5 zeigt schließlich die Schaltmatrix des Beispiels als Cause&Effect Matrix - kurz: C&E-Matrix. Dort werden von einem definierten Startzustand aus (gelb) pro Betriebsart die einzelnen Sicherheitsfunktionen (hellblau) ausgelöst und die Schaltzustände der binären Ausgänge dargestellt. Die Spezifikation der noch unbekannten Signale des Moduls ACT ist nun sehr einfach: Für jeden Binärausgang schreibt man bei einer Schaltungsänderung die logische Kombination der auslösenden blauen Freigabesignale (der Modularchitektur B3) in die entsprechende Zelle (blaue Variablen). Für jede Betriebsart eines Binärausgangs ergeben sich daraus unmittelbar die gesuchten Eingangssignale des zugeordneten UND-Gliedes in ACT (Bild 4 rechts). Damit ist alles spezifiziert.

Bild 5. Schaltmatrix des Beispiels (Cause&Effect- (C&E) Matrix) (Dokument B4).

© Hochschule Bonn-Rhein-Sieg

Es wäre auch denkbar, dass das Programmiersystem aus dieser Information den noch nicht existierenden Code von ACT generiert. Zusätzlich enthält B4 integrierte Prüffelder für die Verifikation V1 (Ist die Matrixspezifikation mit den Sicherheitsfunktionen A1 in Einklang?), das Code Review C1 (Entspricht der Code der Matrixspezifikation?) und die Software-Validierung D1 (Test der Sicherheitsfunktionen). Bei Bedarf lassen sich zusätzliche Testzeilen einfügen.

Für größere Anlagen wird die Darstellung in Bild 5 schnell sehr umfangreich. Bild 6 zeigt daher eine sehr kompakte Alternative, in der allerdings einige Detailinformationen verloren gehen – etwa der detaillierte Zusammenhang mit den Sicherheitsfunktionen und den Eingangssignalen. Die Darstellung zeigt eine Liste der relevanten Aktoren, in der pro Betriebsart die Eingänge der UND-Glieder von ACT eingetragen werden. Diese Darstellung eignet sich auch für sehr große Anlagen. Zudem können zusätzliche Testfälle problemlos berücksichtigt werden.

Im Anschluss an die Programmierung ist ein Code Review durchzuführen – möglichst durch eine zweite Person! – und in einem Protokoll festzuhalten, welches auf bereits abgearbeitete verteilte Informationen in den Vorgängerdokumenten verweist. Hierbei gilt es, folgende Fragen mit „ok“ oder „nicht ok“ zu beantworten:

Bild 6. Kompakte Alternative für die C&E-Matrix.

© Hochschule Bonn-Rhein-Sieg

- Erfüllt die Software die Regeln in A3?
- Stimmt der SPS-Aufbau mit A2.3 überein?
- Stimmt die Verschaltung der I/O-Signale in der Software (A2.4)?
- Stimmt die Aufrufhierarchie des SPS-Programms mit B1 überein?
- Stimmt der Software-Aufbau mit der Modularchitektur B3 überein?
- Stimmt die Software mit der Matrixspezifikation B4 überein?

Das Protokoll des abschließenden Abnahmetests beziehungsweise der Software-Validierung (D1) besteht schließlich aus den dokumentierten Tests in A2.4 und B4, den restlichen Dokumenten des V-Modells sowie zusätzlich aus Soft- und Hardware-Dokumentation, sämtlichen relevanten Handbüchern von Systemkomponenten, Konfigurationen sämtlicher Systemkomponenten, Dokumentation herstellerspezifischer Prüfungen von Systemkomponenten (zum Beispiel Umrichtern) und nicht zuletzt aus den relevanten C-Normen. Diese Dokumente können natürlich auch in elektronischer Form vorliegen.

Zusammenfassend lässt sich festhalten: Die geschilderte Vorgehensweise zur Abarbeitung des V-Modells der DIN EN 13849-1 ist unabhängig von der verwendeten Steuerung und dem erforderlichen Performance Level PLr. Sie basiert auf der immer möglichen Aufteilung der Software in drei Ebenen, wobei nur die mittlere Ansteuerungsebene (ACT) unbekannt ist. Letztere wird durch eine C&E-Matrix spezifiziert. Für diese Matrix gibt es eine ausführliche und eine sehr kompakte Variante. Die Software-Validierung besteht neben der Analyse der Dokumente aus I/O-Tests und Tests der Sicherheitsfunktionen, wobei sich in der zugrunde liegenden C&E-Matrix bei Bedarf weitere Test- und Fehlerfälle hinzufügen lassen. Selbst geschriebene Funktionsblöcke können nach einem ähnlichen Schema entwickelt werden.

Autoren: Prof. Dr. Norbert Becker ist Professor für Automatisierungstechnik an der Hochschule Bonn-Rhein-Sieg im Fachbereich EMT, Manfred Eggeling ist wissenschaftlicher Mitarbeiter im Fachbereich EMT der Hochschule Bonn-Rhein-Sieg und Dr. Michael Huelke leitet im IFA-Fachbereich 5 „Unfallverhütung – Produktsicherheit“ das Referat „Neue Technologien, Mensch und Technik“.