TIA Konfigurierbares Safety Programm

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ist es erlaubt ein Konfigurierbares Sicherheitsprogramm zu haben, d.h. wir haben einen DB mit steurerbaren boolschen werten. Darf sich eine Sicherheitsfunktion durch Konfiguration ändern? Ohne das der hash sich ändert?

 

[UDP]

1. Was meinst du mit steuerbaren Werten? Wirklich normale DB Variablen und die dann steuern? Das geht im F-Programm nicht (und meiner Meinung nach auch aus gutem Grund)

2. Falls ich die Frage falsch verstanden hatte und die Konfiguration sich anders ändern soll - es kommt darauf an. Was gibt die Risikobeurteilung her und wird diese noch erfüllt?

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mir wäre jetzt keine Norm bekannt, die so etwas explizit verbieten würde....
Ob das geht kommt wohl stark auf die Anwendung/Risikobeurteilung an.
Wenn du aus dem F-Programm UND aus dem Standard-Programm eine Funktion freigeben würdest, sollte das gehen.
Oder das F-Docking zu dynamisch wechselnden Baugruppen aus dem Standard-Programm anzustoßen.
Das vorhandensein eines Not-Aus per Konfiguration parametrierbar zu machen wäre allerdings eher....schwierig.

Um was geht es dir denn konkret?

 

[JesperMP]

Ich kenne es so dass es gibt F-Eingänge die mit Brücken verbunden werden kann, und diese aktivieren oder deaktivieren dann Funktionen in F-Programm. Also keine F-Programm Änderungen.
Alles muss dokumentiert werden.

 

[thomass5]

Ich kenne Serienanlagen, da ist das entsprechend realisiert. Im Datenbaustein ist das Vorhandensein bestimmter Anlagenoptionen entsprechend konfiguriert.

 

[d.s.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube was all deine Fragen beantwortet ist folgende Regel in der F-Programmierung: Brücke niemals ein Sicheres Signal mit einem unsicheren Signal.

 

[Mrtain]

Ich glaube was all deine Fragen beantwortet ist folgende Regel in der F-Programmierung: Brücke niemals ein Sicheres Signal mit einem unsicheren Signal.

Und die Regel ist wo niedergeschrieben? Ich Frage das aus reinem fachlichen Interesse

 

[Blockmove]

Ich glaube was all deine Fragen beantwortet ist folgende Regel in der F-Programmierung: Brücke niemals ein Sicheres Signal mit einem unsicheren Signal.

Tja Siemens hat sichere Datenbausteine erfunden …

Bei einer Safety-Schulung bei Siemens wurde nach einem modularer Konzept gefragt.
Antwort war:
Entweder klassisch über F-DI und Brücken oder über sichere DBs bzw. Merker.
F-DI hat den Vorteil, dass sich keine Checksumme ändert.
Bei den sicheren DBs wurde empfohlen die Werte in einem FC zyklisch zu beschreiben um ein Überschreiben zu Verhindern.
Für die Doku wurde eine Konfigurationsmatrix und eine Validierungsmatrix empfohlen.

 

[d.s.]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Mrtain,
keine Ahnung ob das irgendwo so niedergeschrieben steht.
Ist auch egal, weil wenn ich anfange Sichere Signale mit unsicheren Signalen zu Brücken bekomme ich da von keinem Kunden abgenommen. Spätestens bei der Verifizierung bekomme ich sowas nicht durch.
Das zweite ist, wenn ich Sichere Signale mit unsicheren Signalen Brücke ist das Sichere Programm maximal soviel Wert wie das Unsichere Programm. Da kann ich die F-Steuerung gleich ganz weg lassen.
Ein unsicheres Signal ist und bleibt ein unsicheres Signal und kann auch plötzlich mal einen falschen zustand haben. Kommt selten vor aber passiert und wird im Idealfall durch ein Firmwareupdate der CPU beseitigt. Ein sicheres Signal dagegen durchläuft Prüfzyklen und führt im Fehlerfall dann auch mal zum Stop der CPU.

 

[Mrtain]

Ok, danke.
Aber es gibt ja auch auch die Möglichkeit, über die vor- und nachgeschaltete FCs Signale aus dem unsicheren Programm ins Safetyprogramm zu holen bzw. Sichere Signale ins unsichere Programm zu transferieren. Wäre das dann auch nicht tendenziell unsicher - oder habe ich da einen Denkfehler?

 

[d.s.]

@Mrtain,
Unsichere Signale werden schon auch im F-Programm verarbeitet. Wie z.B. Rückführsignale, Quittiersignale,... das ist grundsätzlich ok. Nur darf ein Unsicheres Signal niemals die Funktion eines Sicheren Signals beeinträchtigen was bei Brücken eines Sicheren Signals ja der fall wäre, womit eine Konfiguration (um auf die eigentliche Frage zu kommen) des Sicheren Programms durch unsichere Signale eigentlich nicht möglich ist.

 

[d.s.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn eine Konfiguration in einem F-Progamm erfolgt ist die geänderte Prüfsumme ja auch wichtig, da diese am Ende auch repräsentiert, dass niemand die Konfiguration verändert hat.

 

[Mrtain]

Ok danke, dann hatte ich da wohl einen Denkfehler.
Ändert sich die Prüfsumme auch, wenn ich beim FDI die drahtbrücke entferne und dann damit eine andere Konfiguration aktiviere?

 

[d.s.]

Die Vor- und Nachgeschalteten FC Signale haben den Zweck, dass bei der mehrfachen Verarbeitung des Sicheren Programms die Unsicheren Signale sowohl bei der ersten Berechnung als auch bei der Nachberechnung den gleichen Zustand haben und zum gleichen Ergebnis führen. Hab auch schon F-Programme gesehen wo Taktmerker verwendet wurden. Wenn die sich zwischen der ersten Berechnung und der Nachberechnung verändert haben ist das Ergebnis ein anderes und die CPU geht in Stop.
Ich würden die Konfiguration wenn möglich auch mit Hardwarebrücken lösen. Ein Nothalt-Taster den es nicht gibt ist gebrückt, meldet damit i.O. und alles ist gut. Das ändert auch nichts an der Prüfsumme, die bezieht sich ja auf die Software.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok danke, dann hatte ich da wohl einen Denkfehler.
Ändert sich die Prüfsumme auch, wenn ich beim FDI die drahtbrücke entferne und dann damit eine andere Konfiguration aktiviere?

Nein, die Prüfsumme ändert sich dadurch nicht. Das ist im Serienmaschinenbau ein Vorteil. Du kannst eine Anlage mit verschiedenen Optionen ausstatten und musst nichts am F-Programm ändern.

 

[Mrtain]

Bei optionalen Not-Halt Tastern ist mir das klar.

 

[Blockmove]

Bei optionalen Not-Halt Tastern ist mir das klar.

Das kann man auf ganze Maschinenkomponenten ausdehnen.
Beispiel:
Denk mal an ein Bearbeitungszentrum. Das hat im Normalfall eine manuelle Beladung und eine manuelle Entladung.
Als Option gibt es nun z.B. eine Beladung mit einem Shuttle und als weitere Option eine Entladung per Roboter.
Im Normalfall hast du vielleicht Lichtvorhänge. Bei den Optionen dann Not-Halt-Verkettung und Schutztüren.
Für jemand der Serienmaschinen baut, macht ein modulares Konzept unter Umständen Sinn. Über die Ausführung im Detail muss man sich halt im Vorfeld Gedanken machen.

 

[UDP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Frage die man sich halt auch irgendwie stellen sollte, wenn man sowas über normale DBs oder Merker etc. konfigurierbar macht: Gelegentlich gibt es ja noch Steuerungen die Put/Get-Schnittstelle aktiv haben - wenn da per Put auf den falschen DB geschrieben wird und sich dadurch das Safety-Verhalten ändert, kann ich mir nicht vorstellen, dass als PLd oder PLe zu bewerten. Und für PLc stellt sich ja die Frage, ob es dafür das F-Programm braucht. Oder jemand steuert den falschen Wert über ne VAT etc.

Ich kenne es auch nur mittels HW-Brücken bzw. Schlüsselschaltern, dass z.B. gewisse Funktionen aktiviert/deaktiviert werden. Das erfordert ja auch ein explizites Handeln und würde ja schon Vorsatz bedeuten, da ist die Gefahr einer ungewollten Manipulation deutlich geringer.

 

[Boxy]

Die Frage die man sich halt auch irgendwie stellen sollte, wenn man sowas über normale DBs oder Merker etc. konfigurierbar macht:

Das wäre vermutlich wiederum nicht erlaubt.
Du musst hier auch eine 2 Kanaligkeit haben. Konfiguration dann über sichere DB's usw.
Diese sicheren DB's kann man ja nicht von außen so beschreiben!

Im Serienbau mit NC, kann man z.B. die Sichere-Maschinendaten zur Vorgabe nutzen und bei Erst-IBN die Konfiguration auswählen, bestätigen usw. Somit kann man da verschiedene Maschinenausprägungen mit einem F-Programm ausführen.

 

[Holzmichl]

Ich könnte mir sowas schon vorstellen, aber eher mit mehreren Eingängen - z.B. 4 - als BCD-kodiert, was man auch im F-Programm problemlos als F-Integer auswerten und verarbeiten kann.
Ich hätte ein Problem damit, wenn das F-Programm anfängt anders zu arbeiten, weil eine F-DI-Karte einen Defekt hat und auf allen Kanälen 0 liefert.

Dann lieber BCD mit Plausibilität, dass alles 0 und alles 1 unplausibel sind.

Muss ja kein BCD-Schalter sein, sondern gern auch Drahtbrücken, die so ausgewertet werden.