27.03.2017

Produktionsumgebungen mit heterogenen Netzwerken meistern

Safe Motion als systemunabhängige Lösung

Die Einführung von sicherheitsbewährten Netzwerken macht Antriebs- und Motion-Steuerungen mehr und mehr zu einer Softwareangelegenheit: Festverdrahtete Systeme werden durch Softwarebefehle über vernetzte Systeme ersetzt. Diese Entwicklung wird ebenfalls von Initiativen wie Industrie 4.0 voran getrieben, um mehr Flexibilität mit möglichst gleicher Qualität und dem gleichen Preislevel zu gewährleisten. Jedoch ergeben sich durch die verschiedenen Netzwerke unterschiedliche Lösungen, was Probleme bei den Anwendern zur Folge hat, besonders in Produktionsumgebungen mit heterogenen Netzwerken.


Um das in Einklang zu bringen hat PLCopen eine Arbeitsgruppe für das Thema Safe Motion ins Leben gerufen, die einen übergreifenden Vorschlag aufgesetzt hat, um die Sicherheitsaspekte bei Motion Control über die verschiedenen Netzwerke zu lösen, darunter Profisafe, Safety over Ethercat, CIP Safety over Sercos, OpenSafety, CC-Link IE und Mechatrolink sowie Anwenderbereiche beschrieben in OMAC.

Die sich verändernde Motion-Control-Umgebung

Das Aufkommen (schneller) digitaler Netzwerke ermöglichte es, viele Motoren mit einer Steuerung zu verbinden. In vielen Fällen ersetzt Servotechnologie die großen Einzelmotor-Lösungen, wodurch die Funktionen lokal in der Machine verfügbar und außerdem die vorherigen mechanischen Lösungen durch Software-Steuerung ersetzt werden. Diese Lösung wird auch 'Mechatronische Lösung' genannt. Die Verwendung von multiplen Motoren verändert die Sicherheitsverbindungen: von einer festverdrahteten Sicherheitslösung hin zu einer Lösung über ein Sicherheitsnetzwerk mit einer geeigneten Sicherheitssteuerung, die der funktionalen Steuerung (SPS) hinzugefügt wird. Der nächste Schritt ist die Integration des Sicherheitsdaten-Transfers in das Standardnetzwerk, gleichzeitig mit den Logik- und Motion-Daten. Als Ergebnis ist nur noch ein Netzwerk für die gesamte Maschine nötig. Heutzutage sind solche Netzwerktypen weit verbreitet. Der nun folglich logische Schritt ist die Integration der Steuerungen auf eine einzige Plattform. Auf diese Art und Weise kann die Entwicklungsumgebung für Safety und Non-Safety in ein gewöhnliches System integriert werden, wodurch es möglich wird, die Sicherheitsfunktionalität von Beginn des Projektes an einzubeziehen. In Zukunft wird es ebenfalls möglich sein, Bewegungsinformationen der Achsen über die Sicherheitsprotokolle zu transferieren und Motion-Sensoren zu nutzen, die genaue Sicherheitspositionen digital zur Verfügung stellen können. Dies wiederum ermöglicht, das gesamte Verhalten einer Maschine zu kalkulieren - z.B. kann die Bewegung eines Roboterarms auf eine sichere Geschwindigkeit reduziert werden. Um diese Entwicklungen zu unterstützen ist es nötig, über die Sicherheitsfunktionalität in der Softwareumgebung nachzudenken. Nachfolgend werden daür anwenderfreundliche Lösungen präsentiert. Zu beachten ist dabei, dass ein 'Safety Drive' nicht das selbe ist wie ein 'Safe Drive [System]' in der Automobilbranche.

Allgemeiner Überblick

Wenn wir hier von Safe Motion sprechen, meinen wir die Sicherheit von Bedienpersonal bei der Arbeit mit beweglichen Maschinenteilen. Das beinhaltet die Bewegung von unterschiedlichen Motoren verbunden mit ihren Antrieben in Maschinen auf eine sichere Art und Weise. In vielen Fällen passiert das mit 'Safe Motion Monitoring Functionalities' (SMMF), wie sie in IEC61800-5-2 definiert sind. Die in Abbildung 2 bewegungszugehörigen Sicherheitsfunktionen können identifiziert werden.

Zuordnung zu sicheren Netzwerken

Um die sicherheitsintegrierten Netzwerke zu nutzen, müssen die Sicherheitsfunktionen zugeordnet werden. Der in Abbildung 3 dargestellte Überblick erhebt keinen Anspruch auf Vollständigkeit und ist daher nicht für die Implementierung vorhergesehen. Für diesen Zweck müssen geeignete Netzwerkstandards genutzt werden. Zu beachten ist außerdem, dass hier keine Präferenz oder Reihenfolge vorliegt. Typisch für den aktuellen Status von sicherheitsintegrierten Netzwerken ist, dass grundlegend zwei Bytes oder Befehle (Doppelbytes) beim Kommunizieren von Sicherheitsbefehlen und -status genutzt werden. Jedoch gibt es kleine Unterschiede beim Inhalt und der Bedeutung der Wörter auf Bit-Ebene.

Empfehlungen der Redaktion

Vorschläge für Sicherheitsantriebe

SF_SafetyRequest für die Aktivierung und Überwachung der Antriebsfunktionen

In PLCopen Safety Part 1 ist der Funktionsblock SF_SafetyRequest, wie in Abbildung 4 graphisch dargestellt, definiert. Die Beschreibung von SF_SafeRequest in Abbildung 5 bietet einen grundlegenden Überblick über die Funktionalitäten. Die Hauptein- und ausgaben des SF_SafetyRequest sollten wie folgt verlinkt werden:

  • • Oben links (Activation through safety logic): Eingang S_OpMode ist mit der Logik verbunden und bestimmt, ob die Safety-Drive-Funktion (z.B. sicherheitsbegrenzter Torque) innerhalb der in der Input-MonitoringTime (nicht gezeigt) spezifizierten Zeit aktiv werden muss. Dabei kann es sich um den Ausgabewert eines FB handeln, der ein Gerät überwacht (z.B. SF_ESPE überwacht ein Lichtgitter oder SF_ModeSelector überwacht ein modusbestimmendes Gerät), oder eine Kombination von Zuständen.
  • • Oben rechts (Further use in safety logic): Ausgabe S_SafetyActive gibt Feedback, ob die Safety-Drive-Funktion innerhalb der spezifizierten Monitoring-Zeit aktiv geworden ist, nachdem der Bedarf determiniert wurde (Input S_OpMode). Wenn diese Ausgabe aktiv ist, kann sie dazu genutzt werden, die nächsten Schritte einzuleiten, z.B. das Öffnen eines Tors.
  • • Unten links (Bit in drive's status word): Eingabe S_Acknowledge gibt den für die Safety-Drive-Funktion relevanten Antriebsstatus wieder, wie er vom FB angefordert wurde (z.B. ob die Begrenzung des Torques momentan aktiv ist), und ist das Abbild des Prozesseingabebildes in Bezug zum Antrieb.
  • • Unten rechts (Bit in drive's control word): Ausgabe S_SafetyRequested ist das Bit, welches zum Antrieb im sicheren Steuerwort geht, um die Funktionen im Antrieb zu aktivieren. Beachten Sie, dass es sich beim Steuerwort um einen Byte handeln und der Antrieb eine Safe Logic sein kann.

Ist die Eingabe S_OpMode 'FALSE', gibt es keine Aktivierung, also ist die Ausgabe S_SafetyActive 'FALSE'. Gibt es jedoch eine Sicherheitsnachfrage und die Eingabe S_OpMode ist 'TRUE', zeigt die Ausgabe S_SafetyActive den Status des Antriebes oder seine Überschreitung der Überwachungszeit an. Der Bit/Teil S_SafetyRequest spiegelt den Betrieb durch Aktivierung des relevanten Sicherheits-Bits im Steuerwort wider. Nach der Aktivierungsbestätigung im Sicherheitsantrieb zeigt die Eingabe S_Acknowledge diese Veränderung als 'TRUE' an. Diese SF_SafetyRequest-Funktionalität kann in einem weitreichenden Sicherheits-Verständnis genutzt werden, inklusive der Safe-Motion-Funktionalitäten. Beispielsweise, um dieses FB für SLT (Safely Limited Torque) zu nutzen, kann man die Eingaben Axis2SLT_noNeed und Axis2SLT_fdbk kombinieren, um die relevanten Sicherheitsausgaben Axis2SLT_Active und Axis2SLT_ctrl zu generieren, was die benötigten Sicherheitsfunktionalitäten gewährleistet. Mehrere Instanzen von SF_SafetyRequst können dazu benutzt werden, alle Safety-Drive-Funktionen abzudecken (IEC61800, Profiles, Anbieter-spezifisch). Auf diese Art und Weise können die meisten Funktionalitäten des Sicherheitsantriebes einfach abgebildet werden, besonders durch das Bereitstellen einer 'Guideline'. Dieser Leitfaden sollte ein generisches Schema enthalten, wie Signale in Bezug auf ihre vom Sicherheitsantrieb unterstützten Funktionen (siehe unten) benannt werden. Kombiniert mit einem E/A- oder Antriebs-Konfigurator können diese Bezeichnungen automatisch für die Bits im Antriebsstatus/ Steuerwort generiert werden - passend zum Antriebsprofil (symbolische Namen/Bezeichnungen). Dadurch bietet PLCopen all diese SafeMotion-Funktionen, während es mehrere Instanzen der selben Funktion auf dem selben Antrieb abdeckt, z.B. zweimal SLS mit verschiedenen Geschwindigkeiten. Und es erlaubt der Applikation in Antrieben, die diese Funktionen unterstützen, zwischen der Aktivierung von SS1 und der Aktivierung von STO zu unterscheiden, genauso wie zwischen der Aktivierung von SS2 und der von SOS. (Beachten Sie, dass der spezielle PLCopen FB SF_SafeStop1 nicht die Aktivierung von SS1 garantiert, aber abhängig vom Antrieb STO aktivieren könnte, und SF_SafeStop2 keine Aktivierung von SS2 garantiert, sondern SOS aktivieren könnte. Die Applikation kann im momentanen Zustand nicht auswählen, welche Funktion sie aktivieren soll.) Auch für den Lieferanten wird der Zertifizierungsprozess wesentlich einfacher, während der Anwender ein gleichbleibendes User Interface erhält, das alle benötigten Funktionen abdeckt und sogar die selben Funktionalitäten einfach gruppieren kann, um einen besseren Überblick über das Safety Application-Programm zu gewährleisten.

Das Sicherheitsantrieb-Benennungsschema

Um ein einheitliches Interface zu haben, wird das Bennenungsschema aus Abbildung 6 benötigt. Für jeden vom Antrieb passend zu seinem Profil und seiner Konfiguration unterstützten Sicherheitsantrieb d und jede Sicherheitsantriebs-Funktion f sollten die zugehörigen FB-Instanzen und E/A-Signale gemäß des Benennungsschemas aus Abbildung 6 erhalten.

Zur Erläuterung:

'd' steht für den in der Applikation vergebenen Namen des Sicherheitsantriebs (z.B. 'MyAxis');

'f' ist das Akronym für die Sicherheitsantriebs-Funktion; Für gängige Sicherheitsantriebs-Funktionen sollten folgende Akronyme benutzt werden: f { STO, SS1, SS2, SOS, SBC, SLA, SLI, SLP, SLS, SLT, SAR, SSR, STR, SDI, SEL, SCA, SSM, SMT };

'k' ist die Anzahl an Instanzen der Sicherheitsantriebs-Funktion (wenn der Antrieb so konfiguriert ist, dass mehrere Instanzen von der selben Antriebsinstanz verwendet werden)

Beispiel: Bei einem CIP-safety-on-Sercos-Antrieb 'MyAxis' ist die Safe Motion Monitoring-Funktion #1 als sicher begrenzte Geschwindigkeitsfunktion konfiguriert. Dann sollte die funktionsanzeigende SF_SafetyRequest-Instanz auf dem MyAxis die Bezeichnung 'MyAxisSLS_Mon' bekommen, Bit #2 des MyAxis-Statuswortes im Eingangsabbild sollte den symbolischen Namen 'MyAxisSLS_fdbk' bekommen und Bit #3 des MyAxis-Steuerwortes im Ausgangsabbild sollte den symbolischen Namen 'MyAxisSLS_ctrl' bekommen. Wollen wir als Beispiel die Safe-Torque-Off-Funktionalität abbilden, ist es das erste Bit sowohl in der Steuerung als auch dem Status-Byte. Nutzen wir für dieses Beispiel Axis 2, könnte die Implementierung von SF_SafetyRequest wie in Abbildung 7 aussehen.

Anzeige