Startseite > Automation > Safety generisch gelöst

Vernetzte Sicherheitstechnik

Safety generisch gelöst

19. November 2014, 10:52 Uhr | von Michael Volz

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Das Rad immer wieder neu erfinden?

Im Gegensatz zur Standardkommunikation gibt es auf dem Gebiet der funktionalen Sicherheit bisher kaum generische Lösungen, daher realisieren heute Entwickler ihre Safety-Lösungen in über 90 Prozent der Fälle individuell auf der Basis des jeweiligen Feldbus- beziehungsweise Ethernet-Stacks und des Safety-Protokoll-Stacks und implementieren die Safety-Standards selbst. Für eine Safety-Entwicklung sind allerdings strenge normative Entwicklungsgrundsätze gemäß Normen wie IEC 61508, IEC 62062, ISO 13849 oder auch IEC 61511 einzuhalten. Hier ist sehr genau hinterlegt, wie der Entwickler vorgehen muss und wie er zu verifizieren hat, dass die Entwicklung korrekt erfolgt ist.

Während der Implementierung gilt es, das eigene Tun immer wieder zu hinterfragen, um zufällige Fehler zu beherrschen und systematische Fehler zu vermeiden. Der Entwickler kann nicht etwa den Code schreiben und hinterher ein Review aufsetzen, sondern muss immer wieder Zwischenschritte und Checks von zweiter, unabhängiger Stelle einschalten. Die Dokumentation einer Safety-Entwicklung ist zudem sehr umfangreich, der Entwickler muss jeden einzelnen Schritt verifizieren und schließlich für die Zertifizierung die Wirksamkeit jedes einzelnen Schritts zur Fehlervermeidung durch Berechnungen und Messungen nachweisen. Und nach erfolgreicher Zertifizierung setzt das Lifecycle-Management ein; es ist genau zu dokumentieren, welche Komponente in welchem Softwarestand an wen geliefert wurde, was getan wurde, um auftretende Fehler zu beheben und Kunden zu informieren. Dies alles macht eine Safety-Entwicklung im Vergleich zu einer Standardentwicklung um den Faktor drei bis acht aufwendiger, je nach Kenntnisstand und Erfahrung des Entwicklerteams. Auf diesem Gebiet wird also bisher das Rad meist immer wieder neu erfunden. Wie könnte nun eine generische Lösung für den Safety-Teil aussehen? Zunächst ist wichtig, auch hier die beiden Blöcke Standardkommunikation und Safety klar zu trennen. Dafür wird der Safety-Block mit dem eigentlichen Safety-Protokoll in einer eigenen Hard- und Softwarekomponente gekapselt, dann muss auch nur diese Komponente die aufwendigen Verifikationen und Zertifizierungsprozesse durchlaufen. Durch Trennen, Kapseln und das Schaffen einer definierten Schnittstelle (Black Channel) zwischen den Teilen wird der Aufwand reduziert. Zur sicheren Anwendung hin stellt so ein gekapseltes Modul fertig auskodierte 24-V-Eingangs- und Ausgangssignale bereit, hier lässt sich dann beispielsweise ein Not-Aus-Taster anschließen oder ein Sicherheitsrelais ansteuern, das in einer sicherheitsrelevanten Situation Lasten wegschalten kann.