Sicherheitsbezogene Funktionsweise Des Rfc 4072S - Phoenix Contact Rfc 4072S Anwenderhandbuch

Verhalten der sicherheits-
bezogenen PROFINET-
Steuerung im PROFIsafe
(F-Host) / Sicherheits-
bezogene Steuerung
Anforderung einer
programmierten
Sicherheitsfunktion
Verhalten im Fehlerfall /
Sicherer Zustand
(Failure State)
Passivierung und Reinte-
gration (Wiedereinglie-
derung)
108580_de_02
2.2 Sicherheitsbezogene Funktionsweise des
RFC 4072S
Der RFC 4072S beinhaltet eine leistungsfähige zweikanalige sicherheitsbezogene Steue-
rung für PROFIsafe (sicherheitsbezogene PROFINET-Steuerung, kurz: iSPNS 3000). Die
iSPNS 3000 ist fest in den RFC integriert. Das PROFIsafe-Sicherheitsprotokoll wird über
das PROFINET-Netzwerk übertragen. Die Programmierung der Sicherheitsfunktion erfolgt
in der Software PLCnext Engineer.
Die iSPNS 3000 überwacht und steuert die Sicherheitsfunktion in einem PROFIsafe-
System. In ihrer Funktion entscheidet sie z. B., ob ein sicherer Ausgang gesetzt werden darf
oder nicht.
Im vorliegenden Dokument wird die iSPNS 3000 auch als sicherheitsbezogene Steuerung
bezeichnet.
Nach der Anforderung einer programmierten Sicherheitsfunktion (zum Beispiel Schutztür
geöffnet) führt die sicherheitsbezogene Steuerung die programmierte Sicherheitsfunktion
aus. Die entsprechenden sicheren Ausgänge der F-Devices werden auf den programmier-
ten Wert der Sicherheitsfunktion gesetzt.
Die integrierte Diagnose detektiert aufgetretene Fehler. Alle detektierten, schwerwiegen-
den Fehler im RFC mit sicherheitsbezogener Steuerung, die zum Verlust oder zur Beein-
trächtigung der programmierten Sicherheitsfunktion führen können, haben einen Übergang
in den sicheren Zustand (Failure State) zur Folge. In diesem Zustand werden die sicheren
Ausgänge der F-Devices auf Null (FALSE) gesetzt.
Der sichere Zustand wird im Display in der Kachel „Safety PLC" angezeigt:
– die Diagnose-Anzeige (LED) FS (Failure State) wird rot dargestellt.
– die Kachel „Safety PLC" selbst ist rot hinterlegt.
Falls Sie im Fehlerfall online mit PLCnext Engineer verbunden sind, werden Informationen
zum Fehlerfall auch in der Software angezeigt.
Beschreibungen von Fehlerzuständen, damit verbundener Auswirkungen und entspre-
chender Maßnahmen zur Fehlerbehebung, finden Sie im
gen und Behebung" auf Seite
Falls die Kommunikationsbeziehung zwischen der sicherheitsbezogenen Steuerung und
dem F-Device z. B. aufgrund eines Kommunikationsfehlers abbricht, wird das Gerät
passiviert. Die Passivierung verhindert, dass das Gerät bei wieder aktiver Kommunikations-
beziehung sofort anläuft. Angezeigt werden Passivierung und Reintegration über boole-
sche Variablen, die PLCnext Engineer automatisch für jedes F-Device generiert. Über
diese Variablen sind F-Devices auch aus dem Anwendungsprogramm heraus passivierbar
oder reintegrierbar.
Die PROFIsafe-spezifische Quittierung bei anstehendem Operator-Acknowledge-Request
des passivierten F-Devices kann mit einer anschließenden Operator-Acknowledge-Reinte-
gration erfolgen. Dafür ist z. B. ein nicht sicherheitsbezogenes Signal einsetzbar. Die Pas-
sivierung wird dadurch wieder aufgehoben. Das F-Device wird damit wieder reintegriert.
Weiterführende Informationen zur Passivierung und Reintegration (Wiedereingliederung)
finden Sie im Kapitel 4, „Inbetriebnahme und Validierung"
ment-/ Diagnosevariablen für F-Devices" auf Seite
len für jedes projektierte F-Device" auf Seite 183
/Diagnosevariablen für F-Devices" auf Seite
143.
121,
und
187.
Beschreibung des RFC 4072S
Kapitel „Fehler, Diagnosemeldun-
und in den Kapiteln
„Management-/Diagnosevariab-
„Globale Management-
PHOENIX CONTACT
„Manage-
25 / 274