Was vor der Wiederherstellung einer F-CPU zu erfassen ist

Eine failsichere CPU, meist F-CPU geschrieben, führt zwei Programme gleichzeitig aus: das normale Steuerungsprogramm und ein separates Sicherheitsprogramm, das die Runtime des Herstellers davon isoliert hält. Sie bauen eine CPU aus, lesen Familie und Nummer, und alles wirkt standardmäßig. Dann verweigert die Maschine das Sicherheitsprogramm. Das ist die Falle bei failsicheren CPUs.

Vergrößertes Systemdiagramm

×

Die Trennung ist funktional, nicht physisch: Beide Programme laufen auf derselben Einheit, doch die Runtime isoliert die Sicherheitsseite.

Siemens liefert failsichere Varianten innerhalb der Familien S7-1200F und S7-1500F. Die F-Kennzeichnung erscheint in der Bestellnummer und auf dem Gehäuseetikett. Die Hardware kündigt den Unterschied nicht von selbst an. Die Kennzeichnung ist daher das Erste, was Sie prüfen und erfassen sollten. Ein zusätzliches Zeichen in der Bestellnummer trennt eine Einheit, die ein Sicherheitsprojekt annimmt, von einer, die dies nicht kann.

Die beiden Programme bleiben konstruktionsbedingt getrennt. Das Sicherheitsprogramm läuft nach eigenen Runtime-Regeln, und das Standardprogramm kann es nicht verändern. Diese Isolierung erklärt, warum eine Standard-CPU nicht einfach mit einem Sicherheitsprojekt geladen werden kann und warum der F-Status jede folgende Wiederherstellungsfrage prägt.

Sie erkennen die F-Kennzeichnung, ohne etwas zu öffnen. Bei Siemens erscheint die failsichere Fähigkeit in der Referenz selbst, und das Gehäuseetikett trägt die Kennzeichnung ebenfalls. Das Engineering-Tool zeigt sie auch, sobald die Einheit im Netzwerk ist. Was Sie nicht tun können, ist sie aus dem Maschinenverhalten abzuleiten. Eine Standard-CPU kann denselben Prozess bis zu dem Moment ausführen, in dem jemand ein Sicherheitsprojekt laden möchte. Die Kennzeichnung ist eine aufgedruckte Tatsache. Behandeln Sie sie als solche und lesen Sie sie ab.

Die Kennzeichnung verändert, was eine passende Referenz enthalten muss. Zwei CPUs mit derselben Grundnummer können sich darin unterscheiden, ob sie überhaupt ein Sicherheitsprogramm akzeptieren, und diese Fähigkeit ist an die konkrete Einheit und ihre Konfiguration gebunden. Deshalb gehört der F-Status in die erste Zeile Ihres Datensatzes, noch vor Revision oder Fotos.

Vergrößertes Systemdiagramm

×

Die Grundnummer öffnet die Tür, doch der F-Datensatz entscheidet, was hindurchgehen kann. Dies ist eine Funktionsprüfung, keine Verdrahtungsprüfung.

Sicherheitsprogramm und seine F-Konfiguration, also die Einstellungen, die die Sicherheitsfunktion an die Einheit binden, sind auf eine zweite Weise Teil der Identität. Eine Einheit mit der richtigen Bestellnummer kann ein Sicherheitsprojekt dennoch nicht ausführen, wenn ihre Konfiguration nicht den Erwartungen des Projekts entspricht. Kein Typenschildwert beweist, dass ein Ersatz das Projekt annimmt. Dieser Nachweis muss erfasst und darf nie angenommen werden. Die Liste der F-Module schützt die Prüfung zudem vor einer zweiten Falle: einer Ersatz-CPU, die auf dem Papier vollständig wirkt, während die konfigurierte Gruppe um sie herum nicht erfasst ist.

Die verbundenen failsicheren E/A-Module, die F-Module, gehören zu derselben konfigurierten Gruppe. Eine F-CPU und ihre F-E/A werden im Projekt gemeinsam konfiguriert, und eine Änderung an jedem Mitglied dieser Gruppe kann verlangen, dass das Sicherheitsprogramm erneut validiert wird. Die Abgleichfrage endet daher nie bei der CPU. Sie erstreckt sich auf jedes F-Modul um sie herum. Von außerhalb des Schaltschranks ist diese Unterscheidung nicht sichtbar, weshalb die aufgedruckte Kennzeichnung so viel Gewicht trägt.

Für eine Anfrage ist die praktische Folge die Reichweite. Sagen Sie, dass die CPU in einer failsicheren Anwendung sitzt, auch wenn Ihre Frage nur die CPU betrifft. Die prüfende Person kann sonst nicht wissen, ob die F-Module um sie herum Teil der Frage sind. Erfährt sie während der Prüfung von den F-Modulen, muss sie die Aufnahme neu öffnen. Die zuvor genannten F-Modulreferenzen sind dann der Grund, warum dies nicht nötig war.

Erfassen Sie die vollständige Bestellnummer mit F-Kennzeichnung, die aufgedruckte Firmwareversion und die Hardwaregeneration. Fotografieren Sie Typenschild und jede sicherheitsbezogene Kennzeichnung im Schaltschrank, einschließlich Schildern oder Unterlagen, die die Sicherheitsfunktion der CPU benennen. Fotos tragen den Wortlaut genau, und paraphrasierte Sicherheitskennzeichnungen verlieren im Datensatz ihre Bedeutung. Zwei Kennzeichnungsquellen für dieselbe Einheit sind normal, und jede fotografierte Quelle ist ein Detail weniger, das später aus der Erinnerung rekonstruiert wird.

Vergrößertes Systemdiagramm

×

Vier Erfassungsgruppen speisen das Paket. Jede beantwortet eine Frage, die sonst zweimal gestellt werden müsste.

Listen Sie die verbundenen F-Module mit ihren eigenen Referenzen. Nennen Sie jedes F-Modul, seinen Steckplatz oder seine Stationsposition und seine vollständige Bestellnummer, genau wie Sie die CPU selbst erfasst haben. Wo die Module sitzen, ist wichtig, weil die Frage der erneuten Validierung der Verdrahtung folgt.

Existiert ein Projekt-Backup, erfassen Sie die Version des Sicherheitsprogramms und den Speicherort des Backups neben der Version des Standardprogramms. Die beiden Versionen können abweichen, und eine prüfende Person benötigt beide, um zu beurteilen, was eine wiederhergestellte Einheit tatsächlich ausführen würde. Existiert kein Backup, schreiben Sie diese Tatsache in den Datensatz, weil sie jeden folgenden Wiederherstellungsweg verändert. Der Speicherort ist ebenso wichtig wie die Version. Ein Backup, das niemand findet, verhält sich wie ein fehlendes Backup.

Sicherheitskennzeichnungen verdienen einen gezielten Durchgang. Suchen Sie an Schaltschranktür, Dokumententaschen und jedem Schild nach der Sicherheitsfunktion, der die CPU dient, und fotografieren Sie Ihre Funde. Diese Elemente tragen den Wortlaut, mit dem Sicherheitsprüfende arbeiten, und eine Paraphrase in Ihren Notizen kann ihn nicht wiedergeben. Ist nichts gekennzeichnet, erfassen Sie dieses Fehlen als Tatsache. Es zeigt der prüfenden Person, wie viel Sicherheitskontext nicht dokumentiert ist.

Datieren Sie jeden Eintrag und halten Sie das Paket sachlich. Meinungen dazu, was einen Fehler wahrscheinlich verursacht hat, oder dazu, was ein Lieferant möglicherweise im Bestand haben könnte, gehören nicht neben gemessene Tatsachen. Das Datum macht eine Behauptung erst zu einem Datensatz, denn eine Tatsache ohne Datum kann gegen nichts erneut geprüft werden.

Vergrößertes Systemdiagramm

×

Vertrauen entsteht aus drei Feldern je Zeile. Genannte Lücken sind Teil des Nachweises, kein Fehler des Datensatzes.

Ein datiertes Paket mit Quellen erlaubt der nächsten Person, jede Zeile zu prüfen statt sie herzuleiten. Jeder Wert sollte seine Quelle tragen: Typenschild, Engineering-Tool oder Projektdatei. Stimmen zwei Quellen nicht überein, erfassen Sie beide Ablesungen statt sie zu mitteln und überlassen Sie die Konfliktauflösung der Prüfung.

Dieselbe Disziplin gilt für Lücken. Ein unbekannter Firmwarestand oder ein fehlendes Backup ist eine Tatsache über den Datensatz, und dies offen zu nennen, ist ein stärkerer Nachweis als zu raten. Die Lücken zeigen der prüfenden Person auch, welche Identifikationsschritte zuerst wiederholt werden müssen.

Wenn zwei Quellen abweichen, erfassen Sie beide Ablesungen mit Quellen und Daten und überlassen Sie das Urteil der Prüfung. Ein Firmwarewert aus dem Engineering-Tool und ein anderer aus einer Stückliste sind in einer alternden Anlage ein normaler Befund. Eine stillschweigend gewählte Angabe macht aus Ihrem Datensatz eine Behauptung. Zwei erfasste Ablesungen sind Nachweise, eine ausgewählte Ablesung ist eine Meinung. Die prüfende Person löst den Konflikt einmal mit den Quellen vor sich, statt ihn zweimal zu entdecken.

Eine failsichere CPU ist nicht nur eine Frage nach einem gleichwertigen Austausch. Sicherheitsbezogene Arbeiten gehören unter den für die Maschine geltenden Regeln zu qualifiziertem Personal. Kein Katalogeintrag, Datenblatt oder Lieferantenhinweis ändert dies. Das Nachweispaket ist ein Eingang für diese Arbeit, kein Ersatz dafür.

Vergrößertes Systemdiagramm

×

Das Paket endet dort, wo Sicherheitsqualifikation beginnt. Die Pfeile zeigen die Übergabe von Fragen, nicht die Übergabe von Arbeit.

Erfassen Sie Bekanntes und nennen Sie Unbekanntes. Leiten Sie Fragen zum Sicherheitsprogramm dann an die Personen weiter, die für die Maschine verantwortlich sind. Ein Datensatz, der seine Lücken offen auflistet, ist für eine prüfende Person nützlicher als einer, der sie verdeckt. Benennen Sie bei einer Lücke, wer sie üblicherweise schließen würde und welches Werkzeug diese Person bräuchte.

Behandeln Sie Kompatibilität und Ergebnisse in der Anfrage als offene Fragen. Ob ein bestimmter Ersatz das bestehende Sicherheitsprojekt akzeptiert und ob eine Reparatur die F-Konfiguration bewahren kann, sind Entscheidungen der Prüfung mit verantwortlichen Personen, gestützt auf Ihre Nachweise. Unsicherheit ist hier normal. Sie zu benennen hält eine Sicherheitswiederherstellung sachlich.

• Erfassen Sie Bestellnummer mit F-Kennzeichnung, Firmwareversion und Hardwaregeneration.
• Listen Sie jedes verbundene failsichere E/A-Modul mit eigener Referenz und Position auf.
• Erfassen Sie beide Programmversionen oder nennen Sie klar, dass kein Backup existiert.
• Arbeiten am Sicherheitsprogramm gehören zu qualifiziertem Personal. Nennen Sie diese Grenze in der Anfrage.

• die Kategorieseite für SPS-CPUs
• die Anleitung zu Typenschildfeldern
• das Nachweispaket für eine SPS-Anfrage