Design Packages

Bei der Realisierung von funktional sicheren Komponenten der industriellen Automation ist zunächst eine intensive Beleuchtung des normativen Umfelds unumgänglich. Die passende Produktnorm, die EN61800-5-2, ist als B-Norm unter der EU-Maschinenrichtlinie gelistet. Für das Management der funktionalen Sicherheit, das u.a. Themenbereiche wie Verantwortlichkeiten, Qualifikation von Mitarbeitern und qualitätssichernde Maßnahmen einfordert, verweist diese Produktnorm direkt auf die IEC61508-1. Dieser Teil wird in dem Beitrag jedoch nicht im Detail betrachtet, da es sich dabei um einen komplexen, separaten Themenbereich handelt. Auf der technischen Seite werden die Anforderungen für die Hardware-Elektronik und die Gerätesoftware beleuchtet. Die grundlegendste Antriebssicherheitsfunktion Safe Torque Off (STO) kann prinzipiell rein hardwarebasiert umgesetzt werden. Die EN61800-5-2 gibt dazu Hilfestellung. Interessant hingegen wird es, wenn komplexere Antriebssicherheitsfunktionen gefordert sind. In der Praxis werden derartige Funktionen in Software realisiert. Für Software verweist die Antriebsnorm auf die IEC61508-3. Mit steigendem Sicherheitsintegritätslevel (SIL) werden sehr hohe Anforderungen an die Softwareentwicklung, wie etwa die verwendeten Methoden und die durchzuführenden Verifikationen, einschließlich der verwendeten Werkzeuge, gestellt.

Wie werden betroffene Normen zusammen angewendet?

Werfen wir hierzu einen Blick auf das typische Blockschaltbild für einen sicherheitsgerichteten Antrieb, wie es auch in der Produktnorm zu finden ist. Die Norm spricht von einem Powerdrive System safety related PDS(SR). Neben produktspezifischen Blöcken, wie dem Leistungsteil und der Steuereinheit, tauchen mit den Diagnostic Functions, sowie dem Communication & IO-Block die oben erwähnten Gleichteile auf. Im Funktionsblock Diagnostic Functions sind die antriebs- bzw. bewegungsspezifischen Sicherheitsfunktionen, wie sicherer Betriebshalt (SOS), sicher begrenzte Geschwindigkeit (SLS) oder sichere Drehrichtung (SDI) implementiert. Die typischen Eingangsinformationen für diesen Block sind die Geschwindigkeits- bzw. Positionsdaten, die als Rohdaten vom Encoder erfasst und in der Regel über eine Encoder-spezifische Kommunikationsschnittstelle an den Antrieb übergeben werden. Weitere Eingangsdaten gehen von lokalen Eingängen am Antrieb oder über die Feldbus-/Ethernet-Schnittstellen ein. Bei den Sicherheitsfunktionen (SF) handelt es sich – genau genommen – größtenteils um in Software realisierte Überwachungsfunktionen. Entsprechend der gewählten SF wird z.B. bei SLS permanent überwacht, ob sich die Drehgeschwindigkeit unter dem gewählten Grenzwert befindet. Die Norm fordert hier eine Unterscheidung zwischen der Reaktion auf erkannte Grenzwertverletzungen und intern festgestellte Fehler. Wird nun erkannt, dass die Geschwindigkeit über dem Limit liegt, wird eine der Applikation entsprechenden, sinnvolle Reaktionsfunktion ausgelöst. In der Praxis sind das üblicherweise die Sicherheitsfunktionen STO, SS1 oder SS2.

Bibliothek ‚Sichere Antriebsfunktionen‘

Interessant ist, dass die Software-technische Umsetzung dieser Antriebssicherheitsfunktionen generisch erfolgt und in Form einer Software-Bibliothek leicht wiederverwendet werden kann. Solch eine Bibliothek kann vom Antriebshersteller während seiner Entwicklungsphase integriert werden, um wertvolle Entwicklungsressourcen einzusparen. Den symbolischen Zusammenhang zwischen der Bibliothek, hier im Beispiel die von Mesco vorentwickelte Bibliothek ‚Sichere Antriebsfunktionen‘, und der überlagerten Gerätefirmware zeigt Bild 2. Die Bibliothek ist für einen zweikanaligen Betrieb ausgelegt und besitzt zwei unterschiedliche Arten von Schnittstellen. Zum einen benötigt sie Informationen, welche durch Callback-Funktionen, gekapselt in der Wrapperklasse, von der Gerätefirmware abgeholt werden. Typische Beispiele sind die Encoder- und Zeitinformation oder die Funktionsschnittstelle zum Anfordern bzw. zur Freigabe der gewünschten Sicherheitsfunktion, die von der Gerätefirmware aufgerufen wird. Die Bibliothek enthält derzeit die Sicherheitsfunktionen SS1, SS2, SOS, SLI, SLP, SCA, SMS, SLS, SSR, SDI, SSM und SBC/SBT. Der Antriebshersteller kann auf einer einheitlichen Hardware-Plattform beliebige Kombinationen der Sicherheitsfunktionen implementieren. Dies kann z.B. für individuelle Preismodelle, je nach freigeschaltetem Funktionsumfang, genutzt werden.

Design Packages für Functional Safety

Um den Nutzen von Design Packages bei der Entwicklung einer funktional-sicheren Komponente vollständig zu erfassen, hilft der Blick auf den normativ-geforderten Entwicklungszyklus (Bild 3). Die Antriebsnorm definiert acht Phasen, die mit der Planung des Managements der funktionalen Sicherheit beginnen und bei positivem Verlauf mit der Safety Validation abschließen. Kernbereiche sind die Entwicklungsphasen Safety Requirement Specification, Safety System Architecture, Design&Development und die Testphasen Integration und Safety Validation. Begleitende qualitätssichernde Maßnahmen sind der Phase 4 (Safety Validation Planning) zugeordnet. Phase 7 wird in der Praxis oft vom Produktmanagement ausgeführt, da das primäre Ergebnis die Betriebsanleitung bzw. das sogenannte Safety Manual ist. Ein Design Package, das nur die reinen technischen Unterlagen wie Sourcecode oder Stromlaufpläne, Stücklisten und Gerberdaten bei einem Hardware-Design Package beinhalten würde, wäre nur die Spitze des Eisbergs. Die (Safety)-Design Packages von Mesco beinhalten deswegen für jede dieser Phasen geeignete Hilfestellungen, die es dem Gerätentwickler erleichtern, die erforderliche Dokumentation aufzubauen. Die Integration der Bibliothek beginnt somit nicht erst in der Phase 5, sondern bereits in den davor liegenden Phasen. Die Hilfe ist unterschiedlicher Natur, wie Requirementsfragmente, Testspezifikationen, Source Code und die explizit normativ geforderten unterstützenden Nachweise. Unterstützende Nachweise sind einerseits klassische Testprotokolle, aber auch Nachweise der durchgeführten Verifikationen für die jeweiligen Phasen. Sie sind von großer Bedeutung bei der Safety Validation des vollständigen Antriebs, da sie nicht erst aufwändig durchgeführt und dokumentiert werden müssen. Auch hiermit wird Zeit gespart und Kosten reduziert. Dieser Ansatz bietet den Vorteil, dass der Anwender individuelle Anpassungen an der Bibliothek vornehmen kann. Eine starre Zertifizierung der Bibliothek würde Einbußen bei der Flexibilität bedeuten. Für den linken Ast des V-Modells (Phasen 2, 3 und 5) liefert das Design Package Daten zur Integration in das Requirements Tracking Tool, z.B. Polarion oder Doors. Für die Safety Requirements Specification werden für jede Sicherheitsfunktion eine detaillierte Beschreibung und Parametersatz wie (erreichbarer) SIL, Performance Level, Kategorie, PFH, Reaktionszeit, Fehlerreaktionsfunktion und Empfehlungen für die Verifikation wiedergegeben. Teilweise sind diese Parameter, im Kontext des zu entwickelnden Antriebs, anzupassen. Auch dazu liefert die Betriebsanleitung des Design Packages Hilfestellungen. Auf der folgenden Stufe Safety Architektur müssen die Anforderungen an die Sicherheitsfunktionen und die Softwarearchitektur weiter konkretisiert werden. Hierfür bieten sich Ablaufdiagramme zur Veranschaulichung an, in dem die relevanten Parameter dargestellt sind. Wiederum exemplarisch in Bild 4 dargestellt anhand der Sicherheitsfunktion SLS. Bild 5 zeigt, dass das Verhalten und der Aufbau der Module der Sicherheitsfunktion bereits weiter verfeinert sind und somit fassbarere Vorgaben für die anschließende Implementierung geliefert werden. Der Gedanke hinter dieser schrittweisen Verfeinerung der Anforderungen, ist die Vermeidung von systematischen Fehlern im Entwicklungsprozess. Nicht zuletzt spielt die Qualität des Sourcecodes und die zugehörigen unterstützenden Nachweise eine große Rolle. Angewandte Coding Standards, durchgeführte Code Reviews, statische Codeanalyse und Softwaremodultests mit zertifizierten Testwerkzeugen untermauern das.

Seiten: 1 2Auf einer Seite lesen