TIA ACK-OP - IN-Eingang nur mit unsicherem Signal möglich?

[marscho]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich bin aktuell darüber, einen Standard-Sicherheitsbaustein zu konzeptionieren, der intern einen ACK_OP-Baustein von Siemens nutzen soll.
Der Baustein an sich ist mir wohl bekannt und wurde in der Vergangenheit auch schon desöfteren genutzt, allerdings nicht innerhalb eines standardisierten Bausteins.

Nun war ich dran, die Schnittstellen für den Baustein zu definieren. Es gibt ein Schnitstellensignal (Integer) für den aktuellen Wert der zugeordneten Schaltfläche. Dies wäre "extern" am Baustein ja erstmal unsicher, wird aber durch die Schnittstelle "intern" zu einem "sicheren" (gelb gekennzeichneten) Signal.

Der ACK_OP innerhalb des Bausteins gibt mir bei entsprechender Beschaltung nun folgenden Fehler:
"Der Durchgangsparameter IN eines ACK_OP darf nur mit einem Merker oder einem Parameter eines Standard-DBs verschalten werden."

Ich stehe nun gerade etwas auf dem Schlauch, warum mir die Beschaltung mit einem sicheren Signal verwehrt wird (zunächst mal aus sicherheitstechnischer Sicht). Die Beschaltung mit einem Signal aus dem Standardprogramm funktioniert wie erwartet. Wird das gleiche Signal außen am Baustein verschalten und durchgeschliffen, geht's nicht mehr.

Gibt es aus eurer Sicht denn Alternativen hierzu, damit ein Standardbaustein dennoch funktioniert, Signaturänderungen also möglichst vermieden werden? Meine wären aktuell:

1. Globales "Standardsignal" definieren, dass für sonstige Verwendung gesperrt ist. Wirkt aber irgendwie hinten rum gedacht. Zudem sind unsere Anlagen fast immer Einzelprojekte.
2. ACK_OP selbst nachbauen (vermutlich sinnigerweise als separaten Baustein).

Aktuell bin ich fast soweit, der zweiten Variante den Vorzug zu geben.

Gruß

 

[Olli_BS]

Es gibt einen ACK_GL. Der ist für "normales" globales quittieren gedacht.
Der ACK_OP ist nur für quit über HMI Panels gedacht.
Da musst Du dir mal jeweils die Hilfe ansehen.
Sonst kannst Du aber auch jede Baugruppe einzeln über den Baugruppen DB quittieren...

 

[marscho]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt einen ACK_GL. Der ist für "normales" globales quittieren gedacht.
Der ACK_OP ist nur für quit über HMI Panels gedacht.
Da musst Du dir mal jeweils die Hilfe ansehen.
Sonst kannst Du aber auch jede Baugruppe einzeln über den Baugruppen DB quittieren...

Danke für die Antwort aber eigentlich geht es mir etwa nicht um die Reintegration von Baugruppen.
Ich will ja übers Panel quittieren. Allerdings geht das eher in die Richtung, dass eine bestimmte Vorwahl in der Visu sicher bestätigt werden soll.
Siemens nutzt das in den eigenen Applikationsbeispielen zur Änderung von sicherheitstechnischen Werten über das HMI.

Z.B. folgender Screenshot, Applikationsbeispiel zum Download ist hier zu finden: https://support.industry.siemens.co...r-kennwerte-über-webserver-hmi?dti=0&lc=de-WW



Soweit ist das ja schön und gut, am "IN" des ACK_OP kann ich aber nur ein unsicheres Signal einlesen, kein Signal, welches durch die Nutzung einer Baustellschnittstelle zu einem "sicheren" wird.

 

[Windoze]

Es gibt ein Grundsätzliches Problem Signale die vom HMI gesteuert werden in der Safety zu verwenden.
Wenn die Änderung aus dem HMI genau zwischen den Normalen und "Invertierten" Durchlauf des Safety-Programms fällt, geht die CPU mit "Datenverfälschung im Sicherheitsprogramm" in Stop.
Ich vermute das Siemens in dem ACK_OP Baustein eine Sonderbehandlung gegen dieses Verhalten eingebaut hat.
Wenn du jetzt aber das Signal über eine Sichere Variable / einen Sicheren Parameter schleifst geht wahrscheinlich diese Sonderbahndlung verloren.

 

[marscho]

Wenn die Änderung aus dem HMI genau zwischen den Normalen und "Invertierten" Durchlauf des Safety-Programms fällt, geht die CPU mit "Datenverfälschung im Sicherheitsprogramm" in Stop.
Ich vermute das Siemens in dem ACK_OP Baustein eine Sonderbehandlung gegen dieses Verhalten eingebaut hat.

Ein guter Hinweis.

Wenn du jetzt aber das Signal über eine Sichere Variable / einen Sicheren Parameter schleifst geht wahrscheinlich diese Sonderbahndlung verloren.

Kann ich mir irgendwie schwer vorstellen, wie Siemens das sicherstellen will.
Das mit der Datenverfälschung hat ja in aller Regel eher mit unsauberer Trennung von Safety und Standardprogramm zu tun. Deswegen sollte man ja (wie hier beschrieben) das über entsprechende Schnittstellen handhaben, die am Ende des normalen Programmablaufs beschrieben werden.
Die Datenverfälschung am ACK_OP kann ich so aber mit einem unsicheren wie auch sicheren Signal haben. Ich kann ja direkt den Integer der Taste im Display am IN-Parameter referenzieren - das funktioniert (auch innerhalb eines anderen Bausteins natürlich). Aber ein Signal aus der Schnittstelle, welches über eine Bausteinschnittstelle gezogen wird, geht nicht.

Aber nunja, hilft ja alles nix. Ich werde dann wohl neugierigerweise nochmal bei Siemens anfragen und mir in der Zwischenzeit schon mal Gedanken um eine eigene Lösung machen.

 

[Olli_BS]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK, das kenne ich so nicht.
Aber wen du über Panel quittieren willst, kann es ja unmöglich über eine sichere Variable funktionieren.
Guckt dir bitte mal die Hilfe zum ACK_OP an.
Da steht es erklärt: Über eine nur einmal zu vergebene Konstante und Zeitmuster wird eine gewisse Fehlerunwahrscheinlichkeit erreicht.

 

[marscho]

Aber wen du über Panel quittieren willst, kann es ja unmöglich über eine sichere Variable funktionieren.

Es soll dafür ja auch keine sichere Variable in dem Sinne verwendet werden. Extern wird der Baustein mit dem gleichen Signal beschalten werden, der sonst dem ACK_OP am IN-Parameter übergeben wird. Nur bausteinintern "denkt" der ACK_OP es wäre ein "sicheres" Signal. Genau deswegen wird es wohl aber so nicht funktionieren, ohne dass ich beschriebenes "gesperrtes" Signal (dass sich von einem Projekt zum nächsten nicht ändern darf), dauernd ändernde Bausteinsignaturen oder eben eine eigene Lösung hinnehme.

Wenn ich den Signalverlauf von der HMI-Taste zum ACK_OP hernehme, würde das grob quasi so aussehen:

Taste
--> Schnittstellen-DB-Standard-Safety (unsicher)
--> intButton-Parameter des Standardbausteins (außen immer noch unsicher)
--> IN von ACK_OP innerhalb des Standardbausteins (hier würde es nun "sicher", was so natürlich Blödsinn ist, der ACK_OP weiß darüber nur nix)

 

[Olli_BS]

Ich kann dir nicht ganz folgen : ?
Du willst Änderungen von Sicherheitsrelevanten Parametern von der Visu an der Visu quittieren.
Das aber aber mit einem Standardbaustein, der irgendwie (?) die Quittierung simuliert.
Wie bekommst Du denn bei deiner Lösung die Sache durchgehend sicher hin?
Irgendwo hast Du doch immer eine unterbrochene Kette ...
Geht es dir nur um die Parametrierung als Eingangssignal, die so nicht möglich ist ?
Wahrscheinlich kann man das aus Sicherheitssicht wieder so biegen, das es nicht parametrierbar sein darf. Nur so wird es ein bisschen weniger unsicherer.
Also alle Varianten ausprogrammieren und die entstehenden sicheren Bits an deinen Standard dranhängen.
Sonst bin ich raus ....

 

[marscho]

Zuviel Werbung?
-> Hier kostenlos registrieren

Geht es dir nur um die Parametrierung als Eingangssignal, die so nicht möglich ist ?

Genau das. Ich würde den ACK_OP ja gerne in einem standardisierten Sicherheitsbaustein (ich hoffe, die Wortwahl macht's nun klarer, habe ich wirklich schlecht geschrieben ) verwenden, der nach Freigabe über eine fixe Signatur verfügt. Funktioniert nur nicht, wenn IN kein "sicheres" Signal annimmt.
Die Funktion des ACK_OP wäre exakt die gleiche wie auch sonst, nur halt innerhalb eines validierten und freigegebenen Sicherheitsbausteins.

Wie aber geschrieben, werde ich hier vermutlich nicht um was eigenes herumkommen.

 

[Olli_BS]

Was ist mit alle Varianten ausprogrammieren und die entstehenden sicheren Bits an deinen Standard dranhängen?
Zuviele Varianten?

 

[marscho]

Der "umgebende" Baustein soll es Inbetriebnehmern (und nur für die ist das überhaupt vorgesehen) ermöglichen, einen Kommunikationsausfall eines Teilnehmers "anzumelden". Also z.B. einer Robotersteuerung. Bei anschließendem Ausfall der Kommunikation soll dann ein überwachtes Signal temporär gebrückt werden. Es gehört natürlich noch sehr viel mehr dazu, aber die Anmeldung soll dazu dienen, dass der Inbetriebnehmer ganz bewusst den kommenden Ausfall bestätigt. Daher weiß ich aber die Varianten nicht im Voraus (für wieviele Teilnehmer das denn nötig ist). Sondern ganz individuell wird der umgebende Baustein dann für jedes betroffene Signal separat als Multiinstanz aufgerufen.
Können mal 5 Instanzen sein, vielleicht aber auch 20.

PS: Wie oben schonmal geschrieben: Ja, da gehört sehr viel mehr dazu, als das was ich geschrieben habe (Komm weg, aber Signal noch da?; Signal nicht gebrückt solange Komm noch da, Komm zu lange weg, Komm kehrt wieder, Signal aber nicht usw.). Darum geht es mir hier in erster Linie aber nicht, sondern um das "Freischalten" der Anmeldung, damit es überhaupt erst zu einer Überbrückung kommen kann.

Ich sehe das funktionell recht ähnlich wie das Abmelden eines sicheren MobilePanels (z.B. KP700F).

PPS: Was ich zuvor auch nicht wusste, ist, dass der ACK_OP bei 1200/1500 mit einer beliebigen zweiten Zahl parametriert werden kann. Hilft mir in dem Fall zwar nicht, damit wäre aber grundsätzlich z.B. auch die IP-Endaddresse des Teilnehmers als "zusätzliche Plausibilität" bei der Anforderung möglich.

 

[Mecha2211]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vorab: Ich habe nicht alle Antworten gelesen.
Das Thema ist ein Compiler-Problem, dass ich ähnlich wie der TE auch schon hatte, allerdings ohne Sicherheitsrelevanz:

Ich möchte einen F-Bib-Baustein in einen Bibliotheks-FB kapseln, um ihn mit einem F-UDT zu versorgen. Es geht um den MUT-P-Baustein.
Den F-UDT kopiere ich in der F-Nachverarbeitung auf einen Standard-UDT um damit Stati abzufragen.
Nun knallt mir das beschriebene Problem in den Nacken, dass es in selbst erstellten F-Bausteinen keine "Standard" Variablen zu geben scheint.
Somit verweigert mit TIA das verschalten des DIAG-Ausgangs mit einer entsprechenden VAriable im F-UDT, weil der DIAG-Ausgang keine sicherheitsgerichtet verwertbaren Daten enthält.
Ich will die Daten zwar nicht sicherheitsgerichtet verwenden, sondern nur den Status im Standardprogramm auswerten, aber das erlaubt TIA nicht.
Sehr schade, verhindert eine sinnvolle Verwendung von Bibliotheks-Bausteinen bzw. F-UDTs im Sicherheitsprogramm.
Gerade solche validierten und freigegebenen Bibliothekstypen würden doch die Fehlerwahrscheinlichkeit bei der Programmierung des F-Teils verringern.


Wenn es eine Lösung gibt, bin ich sehr interessiert.

 

[Olli_BS]

Was möchtest Du denn genau mit DIAG machen?
An sich hilft der Status ja nur bedingt und davon abhängige Reaktionen im Programm machen ja kaum/selten Sinn.
Wenn es nur um OK / niO geht ist ja der DB zur Baugruppe erste Wahl (passiviert). Da hast DU ja ein Safetybit.
Fürs durchreichen an die HMI geht es nicht. Aber das kann/sollte man ja auch im Standardprogramm machen...

Edit: Ok, bei dem FB ist DIAG vielleicht schon hilfreich....
Also eine gute Lösung fällt mir da auch nicht ein.
Musst Du wohl im Standardteil noch mal Datenfelder extra anlegen. Ist eben keine fehlersichere Info und soll darum im F-Programm auch nicht weiterverarbeitet werden können.

 

[Mecha2211]

Naja, ich kann ja sogar nicht sichere DIs im F-Programm verwenden.
Ist eben eine nicht ganz zuende gedachte Compiler-Regel.
Entweder nicht konsequent umgesetzt oder, und das ist meine Meinung, wird im Fall der Siemens F-Bibliothek der Nutzer zu stark gegängelt.

 

[Olli_BS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Stimmt so nicht ganz.
Du hast aus einem Sicheren FB ein Output der NICHT sicher ist.
Da kannst eine Standard Variable dran hängen und die auch neu im Safety-Programm weiterverarbeiten. Die wird aber immer korrekt gekennzeichnet.

Du möchtest sie aber innerhalb von Safety durchreichen. Wenn sie dann aber immer als Sicher gekennzeichnet wäre: FAULT
Die Lösung wäre ja die Mischung von sicheren und unsicheren FB/UDT Parametern.
Das man das (noch) nicht macht, kann ich verstehen.
Und das ich Siemens verstehe, ist wirklich selten geworden ....

 

[Olli_BS]

Ich wundere mich auch immer wieder, was alles für EierlegendeWollmichSau-FBs gemacht werden.
Ich kenne nicht die Applikationsgrößen. Aber so ein Ding aus programmieren und 10 x kopieren und Variablen ändern:
So schlimm? Soviel Aufwand? Wird es dann so unsicher?
Sorry, ich schweife ab...

 

[Mecha2211]

@OIli_BS:
Du hast Recht, die Compiler-Regel ist konsequent. Ich kassiere meinen Siemens-Bash.
Zum FB:
Nicht eierlegende Wollmilchsau, sondern (so wie es Siemens ja mit F-UDT und F-Bibliothek vorschlägt/vorgibt) eine sinnvolle Kapselung zur einfachen Nutzung und Anbindung.

Aber ja, die Frage ist berechtigt, es ist nicht SO schlimm, SOVIEL Aufwand, SO unsicher. Aber es IST Aufwand, ein BISSCHEN schlimm (und das Fehlerpotenzial bei einer nicht sicheren Diagnose zugegebenermaßen nicht so groß). Aber es ist eben nicht futuristic blau-transparentes Totally Integrated Automation in zehn Minuten.

Die Mischung von F und Nicht-F Variablen im UDT fänd ich toll.

 

[Olli_BS]

Zuviel Werbung?
-> Hier kostenlos registrieren

@OIli_BS:

Aber es ist eben nicht futuristic blau-transparentes Totally Integrated Automation in zehn Minuten.

Da bin ich voll deiner Meinung ....