• Home
• Funktionen/Funktionsbausteine - Referenz
• Sicherheitsbezogene Funktionsbausteine für Rezeptur-Handling
• SF_RecipeRead
• Fehlervermeidung

Fehlervermeidung

Dieses Thema enthält die folgenden Abschnitte:

• Validierung
• Erkennen von inkorrekten/ungültigen Rezepturdaten, die aus einer Datei (einem Datensatz) gelesen werden
• Datenvalidierung (CRCs und Seriennummer)
• Deaktivierung der Datenvalidierung
• Erlaubte Mehrfachzugriffe auf dieselbe Rezeptur-Datei durch verschiedene FBs
• Korrekte Verschaltung und weitere Verarbeitung von gelesenen Rezepturwerten
• Aktualität und Korrektheit der Rezepturwerte
• Plausibilitätsfehler und Verschaltungsfehler
• Sporadisch wechselnde oder toggelnde Signalpegel oder unzulässige Signale
• Anlauf der Maschine/Anlage ohne Funktionsprüfung der Schutzeinrichtung

Validierung

Einzig und allein Sie als Anwender, Maschinenbauer oder Systemintegrator sind sich sämtlicher Bedingungen und Faktoren bewusst, die im Design der Anwendung für die Maschine realisiert sind. Daher können nur Sie bestimmen, welche Automatisierungsgeräte und dazugehörige Sicherheiten und Verriegelungen verwendet werden können und deren Verwendung validieren.

WARNUNG

Unbeabsichtigter Betriebszustand des Geräts Validieren Sie die gesamte Sicherheitsfunktion und prüfen Sie die Applikation sorgfältig.

Erkennen von inkorrekten/ungültigen Rezepturdaten, die aus einer Datei (einem Datensatz) gelesen werden

Der Funktionsbaustein und die Sicherheitssteuerung implementieren mehrere Verifizierungs- und Validierungsmaßnahmen, die dazu beitragen, eine Fehlfunktion des FB (und damit ggf. der gesamten Sicherheitsfunktion) durch die Verwendung ungültiger Rezepturdaten zu verhindern.

Mögliche Fehler/ungültige Operation	Zu vermeidende Konsequenzen	Gegenmaßnahme des FB
Ungültige Dateikennung und/oder Datensatzkennung an den FB-Eingängen IDRecipeFile und/oder IDRecipeDataSet. Die IDs liegen nicht innerhalb des gültigen Wertebereichs.	Daten können nicht aus dem Datensatz gelesen werden.	Der FB verifiziert jede ID an den FB-Eingängen. In der Folge: werden keine Daten gelesen und der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang.
Die zu lesende Rezeptur-Datei (spezifiziert über den Eingang IDRecipeFile) ist nicht vorhanden.	Daten können nicht aus dem Datensatz gelesen werden.	In der Folge: werden keine Daten gelesen und die Payload-Werte (Failsafe-Werte), die an den Eingängen FV_PayloadRead** anliegen, werden an den FB-Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgegeben, und der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang.
Die zu lesende Rezeptur-Datei ist verfälscht oder beschädigt.	Es könnten falsche Rezepturwerte gelesen werden und die mit den PayloadRead**-Ausgängen (mit ** = 0 bis 15) verbundenen Variablen würden falsche Werte annehmen. Diese falschen Werte könnten zu einer Fehlfunktion der sicherheitsbezogenen Applikation und damit zu gefährlichen Situationen führen.	Die Sicherheitssteuerung berechnet CRCs über die Datei und die Datensätze und vergleicht diese mit den Prüfsummen, die in der Datei hinterlegt sind. Auf diese Weise können verfälschte/beschädigte Dateien und Datensätze erkannt werden. Diese Validierungen erfolgen unabhängig von den Einstellungen an den FB-Eingängen CheckDataSetCRC und CheckFileCRC, d.h. sie können über diese Eingänge nicht deaktiviert werden. Wird eine Inkonsistenz entdeckt, werden die Daten als ungültig erachtet und die Payload-Werte (Failsafe-Werte), die an den Eingängen FV_PayloadRead** anliegen, werden an den FB-Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgegeben, und der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang.
Die zu lesende Rezeptur-Datei gehört zu einer anderen sicherheitsbezogenen Applikation.	Es könnten unpassende Rezepturwerte gelesen werden und die mit den PayloadRead**-Ausgängen (mit ** = 0 bis 15) verbundenen Variablen würden falsche Werte annehmen. Diese falschen Werte könnten zu einer Fehlfunktion der sicherheitsbezogenen Applikation und damit zu gefährlichen Situationen führen.	Die Sicherheitssteuerung verifiziert die Projekt-CRC (vorausgesetzt, diese Validierung ist über den Eingang CheckProjectCRC aktiviert). Hintergrundinformationen zum Vergleich der Projekt-CRC Das Vergleichen der Projekt-CRC hilft dabei sicherzustellen, dass die zu lesende Rezeptur-Datei aus exakt demselben Applikationsprojekt (und auch derselben Version) geschrieben wurde. Die Projektprüfsumme wurde beim Erzeugen des Projekts in PLCnext Engineer berechnet und dann in die Projektdatei geschrieben. Der FB SF_RecipeWrite liest diese Prüfsumme aus der Projektdatei und schreibt sie in den Header der Rezeptur-Datei. Falls beim SF_RecipeRead-FB der Eingang CheckProjectCRC auf SAFETRUE gesetzt ist, liest dieser die ProjectCRC aus dem Header der Rezeptur-Datei und vergleicht sie mit der ProjectCRC des aktuellen Projekts. Wird eine Inkonsistenz entdeckt, werden die gelesenen Daten als ungültig erachtet und die Payload-Werte (Failsafe-Werte), die an den Eingängen FV_PayloadRead** anliegen, werden an den FB-Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgegeben, und der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang.
Die Flash-Speicherkarte wurde in ein anderes Gerät eingesteckt. Das bedeutet, die Rezeptur-Datei war zur Verwendung in einer andere Steuerung und möglicherweise auch in einer anderen sicherheitsbezogenen Applikation gedacht.	Es könnten unpassende Rezepturwerte gelesen werden und die mit den PayloadRead**-Ausgängen (mit ** = 0 bis 15) verbundenen Variablen würden falsche Werte annehmen. Diese falschen Werte könnten zu einer Fehlfunktion der sicherheitsbezogenen Applikation und damit zu gefährlichen Situationen führen.	Die Sicherheitssteuerung verifiziert die Seriennummer des Zielgeräts und erkennt eine unpassende Rezeptur-Datei (vorausgesetzt, diese Validierung ist über den Eingang CheckSerialNumber aktiviert). Das Vergleichen der Seriennummer hilft dabei sicherzustellen, dass die zu lesende Rezeptur-Datei auf exakt dieselbe Sicherheitssteuerung geschrieben wurde. In der Folge: werden die gelesenen Daten als ungültig erachtet und die Payload-Werte (Failsafe-Werte), die an den Eingängen FV_PayloadRead** anliegen, werden an den FB-Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgegeben, und der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang.
Die Rezeptur-Datei wurde absichtlich oder fälschlicherweise durch eine andere Datei ersetzt.	Es könnten unpassende Rezepturwerte gelesen werden und die mit den PayloadRead**-Ausgängen (mit ** = 0 bis 15) verbundenen Variablen würden falsche Werte annehmen. Diese falschen Werte könnten zu einer Fehlfunktion der sicherheitsbezogenen Applikation und damit zu gefährlichen Situationen führen.	Die Sicherheitssteuerung verifiziert die CRCs über die Datei und den Datensatz und vergleicht diese mit den Werten, die an den FB-Eingängen DataSetCRC und FileCRC anliegen. Außerdem wird die Projekt-CRC verifiziert. Hintergrundinformationen zum Vergleich der Projekt-CRC Das Vergleichen der Projekt-CRC hilft dabei sicherzustellen, dass die zu lesende Rezeptur-Datei aus exakt demselben Applikationsprojekt (und auch derselben Version) geschrieben wurde. Die Projektprüfsumme wurde beim Erzeugen des Projekts in PLCnext Engineer berechnet und dann in die Projektdatei geschrieben. Der FB SF_RecipeWrite liest diese Prüfsumme aus der Projektdatei und schreibt sie in den Header der Rezeptur-Datei. Falls beim SF_RecipeRead-FB der Eingang CheckProjectCRC auf SAFETRUE gesetzt ist, liest dieser die ProjectCRC aus dem Header der Rezeptur-Datei und vergleicht sie mit der ProjectCRC des aktuellen Projekts. Diese Validierungen werden nur dann durchgeführt, wenn sie über die FB-Eingänge CheckDataSetCRC, CheckFileCRC und CheckProjectCRC aktiviert sind. Des weiteren wird die Seriennummer der Sicherheitssteuerung verifiziert (sofern diese Validierung über den FB-Eingang CheckSerialNumber aktiviert ist). Wird eine Inkonsistenz entdeckt, werden die gelesenen Daten als ungültig erachtet und die Payload-Werte (Failsafe-Werte), die an den Eingängen FV_PayloadRead** anliegen, werden an den FB-Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgegeben, und der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang.
Der Datensatz wurde zwischenzeitlich durch einen SF_RecipeWrite-Funktionsbaustein überschrieben.	Es könnten falsche Rezepturwerte gelesen werden und die mit den PayloadRead**-Ausgängen (mit ** = 0 bis 15) verbundenen Variablen würden falsche Werte annehmen. Diese falschen Werte könnten zu einer Fehlfunktion der sicherheitsbezogenen Applikation und damit zu gefährlichen Situationen führen.	Die Sicherheitssteuerung verifiziert die CRCs über die Datei und den Datensatz und vergleicht diese mit den Werten, die an den FB-Eingängen DataSetCRC und FileCRC anliegen. Voraussetzung dafür ist, dass diese Validierungen über die FB-Eingänge CheckDataSetCRC und CheckFileCRC aktiviert sind. Wird eine Inkonsistenz entdeckt, werden die gelesenen Daten als ungültig erachtet und die Payload-Werte (Failsafe-Werte), die an den Eingängen FV_PayloadRead** anliegen, werden an den FB-Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgegeben, und der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang.
Aufgrund eines "Soft-Errors" wurden die Rezepturdaten im RAM der Sicherheitssteuerung verfälscht. Diese Verfälschung fand statt, bevor die Datei in das Dateisystem im Flash-Speicher geschrieben wurde.	Es könnten falsche Rezepturwerte gelesen werden und die mit den PayloadRead**-Ausgängen (mit ** = 0 bis 15) verbundenen Variablen würden falsche Werte annehmen. Diese falschen Werte könnten zu einer Fehlfunktion der sicherheitsbezogenen Applikation und damit zu gefährlichen Situationen führen.	Die Sicherheitssteuerung validiert die Daten, indem Sie einen Kreuzvergleich zwischen ihren beiden diversitären Kanälen durchführt. Wird eine Inkonsistenz entdeckt, werden die gelesenen Daten als ungültig erachtet und die Payload-Werte (Failsafe-Werte), die an den Eingängen FV_PayloadRead** anliegen, werden an den FB-Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgegeben, und der Ausgang Done bleibt SAFEFALSE und zeigt der FB einen Fehlercode an seinem DiagCode-Ausgang an und die Sicherheitssteuerung nimmt den definierten sicheren Zustand an.
Gleichzeitiges Lesen und Schreiben innerhalb eines Zyklus der sicherheitsbezogenen SPS.	Wenn eine bereits aktivierte SF_RecipeRead-Instanz zyklisch Daten aus einem Datensatz im RAM der Sicherheitssteuerung liest und der Datensatz dann zu Beginn des Zyklus (vor dem Lesevorgang) von einem SF_RecipeWrite-FB überschrieben wird, dann entsprechen die gelesenen Daten in diesem Zyklus unter Umständen nicht den erwarteten Werten. Dies könnte zu einer Fehlfunktion der sicherheitsbezogenen Applikation und damit zu gefährlichen Situationen führen. Im Beispiel eines Signalablauf-Diagramms finden Sie weitere Informationen hierzu.	Die Sicherheitssteuerung verriegelt eine Datei im RAM gegen Lesezugriffe, sobald deren Inhalt verändert wurde. Diese Verriegelung wird aufgehoben, nachdem die Daten erfolgreich in das Dateisystem (im Flash-Speicher) geschrieben und validiert wurden. Für die beteiligte SF_RecipeRead-Instanz gilt dabei: der Ausgang Done bleibt SAFEFALSE und der FB zeigt einen Fehlercode an seinem DiagCode-Ausgang. Die beteiligte SF_RecipeWrite-Instanz ist hiervon jedoch nicht betroffen und kann seine Operation erfolgreich abschließen (Done = SAFETRUE).

Datenvalidierung (CRCs und Seriennummer)

Die Sicherheitssteuerung kann eine Validierung der aus dem Rezeptur-Datensatz gelesenen Daten durchführen. Mit Hilfe dieser Validierungen lässt sich erkennen, ob die Daten ...Jedes Mal, wenn Rezepturdaten aus einer Datei gelesen wurden, berechnet der FB CRCs über den gelesenen Datensatz und die Datei. Der FB validiert dann die Daten wie folgt:

Voraussetzung für die Ausführung der Datenvalidierung: Jede der Validierungen muss aktiviert werden, indem der Wert SAFETRUE an den entsprechenden FB-Eingang CheckDataSetCRC, CheckFileCRC, CheckProjectCRC, und CheckSerialNumber angelegt wird. Es ist möglich nur eine, mehrere oder alle Validierungen zu aktivieren.

Falls aktiviert, läuft die Datenvalidierung wie folgt ab:

Die Daten werden nur dann als gültig erachtet und Ausgang Done wird nur dann auf SAFETRUE gesteuert, wenn bei diesen Vergleichen keine Inkonsistenzen erkannt werden.

Deaktivierung der Datenvalidierung

Die im Abschnitt "Datenvalidierungen" beschriebenen Prüfungen können über die FB-Eingänge CheckDataSetCRC, CheckFileCRC, CheckProjectCRC und CheckSerialNumber aktiviert oder deaktiviert werden.

Falls eine oder alle der Validierungen deaktiviert sind, muss der nachfolgende Gefahrenhinweis beachtet werden.

WARNUNG

Nichterfüllen der Sicherheitsanforderungen Stellen Sie sicher, dass geeignete Maßnahmen (gemäß zutreffender Sektornormen) getroffen wurden, um ausschließen zu können, dass die gelesene Rezeptur-Datei modifiziert wurde oder zu einer anderen sicherheitsbezogenen Applikation gehört, falls Sie die CRC-Validierungen deaktiviert haben (SAFEFALSE-Wert an CheckDataSetCRC, CheckFileCRC, oder CheckProjectCRC). Berücksichtigen Sie in Ihrer Risikoanalyse die Auswirkungen, die das Lesen falscher Rezepturwerte aus einer modifizierten oder falschen Rezeptur-Datei hat, falls die CRC-Validierungen deaktiviert sind. Validieren Sie die gesamte Sicherheitsfunktion im Hinblick auf die Auswirkungen, die das Lesen falscher Rezepturwerte aus einer modifizierten oder falschen Rezeptur-Datei hat, falls die CRC-Validierungen deaktiviert sind.

Erlaubte Mehrfachzugriffe auf dieselbe Rezeptur-Datei durch verschiedene FBs

Die folgenden Szenarien werden nicht als fehlerhaftes Verhalten betrachtet. Die sicherheitsbezogene Applikation muss dabei jedoch hinsichtlich ihres korrekten und beabsichtigten Verhaltens validiert werden.

Korrekte Verschaltung und weitere Verarbeitung von gelesenen Rezepturwerten

Die Werte, die der FB an seinen Ausgängen PayloadRead** (mit ** = 0 bis 15) ausgibt, werden üblicherweise an die Eingänge weiterer sicherheitsbezogener Funktionsbausteine weitergeleitet oder auf Variablen geschrieben, die dann in der sicherheitsbezogenen Applikation weiter verarbeitet werden. Auf diese Weise können diese Werte das Verhalten der Sicherheitsfunktion beeinflussen. Logisch inkorrekte Verschaltungen können vom Programmiersystem der Sicherheitssteuerung nicht erkannt werden. Es liegt deshalb alleine in Ihrer Verantwortung als Entwickler der sicherheitsbezogenen Applikation, dafür zu sorgen, dass die PayloadRead**-Ausgänge korrekt verschaltet sind und weiterverarbeitet werden. Beachten Sie den folgenden Gefahrenhinweis.

WARNUNG

Nichterfüllen der Sicherheitsanforderungen Stellen Sie sicher, dass die FB-Ausgänge PayloadRead** (mit ** = 0 bis 15) mit den korrekten Variablen/Bausteineingängen verschaltet sind und in Übereinstimmung mit Ihrer Risikoanalyse weiter verarbeitet werden. Validieren Sie die gesamte Sicherheitsfunktion in Bezug auf die Verschaltung der Ausgänge PayloadRead (mit ** = 0 bis 15) und prüfen Sie die Applikation sorgfältig.

Aktualität und Korrektheit der Rezepturwerte

Die in einer Rezeptur-Datei enthaltenen Daten müssen aktuell und passend sein für die korrekte Funktion Ihrer sicherheitsbezogenen Applikation. Falsche oder veraltete Werte können weder vom FB noch von der Sicherheitssteuerung erkannt werden. Beachten Sie den folgenden Gefahrenhinweis.

WARNUNG

Nichterfüllen der Sicherheitsanforderungen Stellen Sie sicher, dass die im zu lesenden Datensatz enthaltenen Rezepturwerte aktuell sind und den Ergebnissen der durchgeführten Risikoanalyse entsprechen. Stellen Sie sicher, dass Ihre Risikoanalyse eine Auswertung für den Fall enthält, dass veraltete oder inkorrekte Werte aus dem Rezeptur-Datensatz gelesen werden. Validieren Sie die gesamte Sicherheitsfunktion in Bezug auf die Aktualität und Korrektheit der gelesenen Rezepturdaten und prüfen Sie die Applikation sorgfältig.

Plausibilitätsfehler und Verschaltungsfehler

Plausibilitätsfehler sind Fehler, die beispielsweise durch Überschreiten von Wertebereichen oder unzulässiges Verschalten auftreten. Solche Fehler werden entweder vom Baustein selbst oder beim Kompilieren des Projekts erkannt und gemeldet. Bei Verschaltungsfehlern ist das jedoch nicht immer möglich.

So ist es beispielsweise nicht möglich, automatisch zu prüfen, ob:

WARNUNG

Unbeabsichtigter Betriebszustand des Geräts Führen Sie eine Validierung der Signale, Formeln, Variablen oder Konstanten durch, die mit den Formalparametern des sicherheitsbezogenen Funktionsbausteins verbunden sind, und prüfen Sie die Anwendung sorgfältig.

Sporadisch wechselnde oder toggelnde Signalpegel oder unzulässige Signale

Werden keine weiteren Maßnahmen zur Fehlervermeidung vorgenommen, führen sporadisch wechselnde oder toggelnde Signalpegel an den zustandsgesteuerten Eingängen möglicherweise dazu, dass dieses Signal eine entsprechende Aktion ungewollt auslöst.

Unzulässige Signale an Eingängen können zu einem unbeabsichtigten Anlauf oder zur Nichtausführung einer angeforderten Aktion oder zu einem Fehler führen.

Mögliche Ursachen dieser Signale können sein:

Um dies zu vermeiden, sind je nach Sicherheitsfunktion folgende Maßnahmen möglich:

Die genannten Maßnahmen können auch kombiniert werden, um Sie besser bei der Fehlererkennung und Fehlervemeidung zu unterstützen.

Anlauf der Maschine/Anlage ohne Funktionsprüfung der Schutzeinrichtung

Eine defekte Schutzeinrichtung wird nur durch eine Funktionsprüfung erkannt. Eine Funktionsprüfung wird vom Funktionsbaustein nicht unterstützt.

Mögliche Ursachen für eine defekte Schutzeinrichtung:

WARNUNG

Unbeabsichtigter Betriebszustand des Geräts Führen Sie eine Validierung der Schutzeinrichtung durch Funktionsprüfungen durch. Stellen Sie vor der Durchführung der Funktionsprüfungen sicher, dass geeignete Maßnahmen (gemäß zutreffender Sektornormen) getroffen wurden, um Gefährdungen im Falle eines unbeabsichtigten Verhaltens der Sicherheitslogik zu verhindern. Betreten Sie den Betriebsbereich nicht, während die Maschine in Betrieb ist. Stellen Sie sicher, dass keine anderen Personen den Betriebsbereich betreten können, während die Maschine in Betrieb ist. Beachten Sie die vorgegebenen Richtlinien in relevanten Sektornormen, wenn die Maschine in einer anderen Betriebsart als "In Betrieb" läuft. Verwenden Sie geeignete Sicherheitsverriegelungen, wenn eine Gefahr für Personen und/oder Ausrüstung besteht.