TIA "Reflection" in der SPS?

[Alpini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und hiermit wird dann auch noch jeder zum kaputtsteuern der Anlage eingeladen, der Zugriff zum Netzwerk der SPS hat.

Das "hiermit" habe ich für's Forum gewürfelt und den Baustein-Code auch auf's Wesentliche reduziert. Aber selbst wenn nicht, ich weiß nicht, ob du die einschlägigen Bibliotheken kennst (Deiner Signaturzeile nach kennst du dich sicher perfekt in dem Bereich aus) und was damit möglich ist. Wenn jemand Zugriff auf das SPS-Netzwerk / Port 102 erlangt, egal wie, dann ist doch irgendwo eh alles zu spät (Stuxnet lässt grüßen)? Da muss der Angreifer auch keine DB-Nummern mehr kennen, denn im Zweifel hat der Angreifer sogar die Programmiersoftware. Sprich, mit oder ohne PC-Wartungsmodus ist eine Netzwerktrennung dringend notwendig.

Wie würdest du selbst vorgehen?

-ausschließlich wie in Post #13? Wenn ja welchen Sicherheitsgewinn bringt das gegenüber der Zeigervariante? (Mal davon abgesehen, dass man mit deiner Variante besonders sensible Ausgänge von der PC-Steuerung ausschließen könnte - theoretisch zumindest)
-hunderte Taster in den Schaltschranktüren verteilen?
-zusätzliche Sicherheit einbauen, z.B. den Wartungssteuerungsmodus (FB-Aufruf) zusätzlich von einem Handschalter abhängig machen?
-gar nicht machen und mit großer Ausfallzeit das defekte Teil aus der Anlage ausbauen, gesondert außerhalb laufen lassen und einstellen, um dann festzustellen, dass es im eingebauten Zustand etwas verwunden doch wieder nicht läuft?
...

Ich bin für eine konstruktive Diskussion offen, weiß dein Fachwissen sehr zu schätzen und bin auch nicht beratungsresistent wenn man mir Vor- und Nachteile plausibel erklärt. Der Bereich Netzwerksicherheit ist dann auch eher wieder mein Gebiet.

@ducati: Für wesentliche Sachen haben wir es so wie du beschreibst (siehe weiter oben). Das Problem sind eher "unwichtige" Ausgänge, für die bisher kein Handmodus nötig war. Dieser ließe sich relativ einfach implementieren, deren schiere Anzahl schreckt aber sehr ab und macht viel Arbeit - daher suchte ich eine Lösung mit geringerem Aufwand. Wenn mir jemand plausibel erklärt, warum es so besser ist, kann ich das auch jederzeit ändern. Noch sehe ich sicherheitstechnisch aber wenig Unterschiede. Ein Angreifer, der auf ISO on TCO / Port 102 Zugriff hat und Merker ändern kann, kann auch nicht-Wartungssteuerungs-Merker ändern und damit erhebliches Chaos anrichten.

 

[ducati]

Also keine Ahnung, dass jemand als "Handbetrieb" irgendwelche Ausgänge "forced" hab ich noch so noch nie gehört.
Was ist wenn der Eplan nicht stimmt? Und warum muss der Bediener überhaupt nen Ausgang kennen? Der Bediener will doch einfach Ventil 4711 auf HandEin setzen... Und dann wird in der Visu auch ersichtlich, dass das Ventil grad in Hand ist. Und es kann auch noch mitgeloggt werden, wer jetzt wann das Ventil geschalten hat...

Zum 102er Port sowie Security, wenn mann Risiken sieht, kann man das ja zu machen... bei der 1500er ist der erstmal sowieso zu und wenn man noch nen Passwort vergibt, geht garnix...

Wenn jemand unbedingt Ausgänge forcen will, soll er das TIA aufmachen...

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum reitest Du ständig auf diesen hunderten Tastern in der Schaltschranktür rum???
Jede vernünftige Anlage hat heutzutage nen Bedienpanel...

 

[TP-Inc]

Eine Betriebsart in der man einzelne Ausgänge steuern kann hab ich noch bie gesehen. Im Normalfall gibt es einen Einrichtbetrieb in dem man einzelne Aktoren steuern kann. Auch mit voller Verriegelung usw.

 

[Glon]

Mein Senf dazu:

In der Halbleiter Branche speziell in der Chemikalienversorgung war oft ein IO-Forcing über die Visualisierung gefordert.

Am Anfang fand ich das sehr gruselig und gefährlich. (Ich finde es immer noch gefährlich).

Wir haben das mit Peek und Poke umgesetzt. Der Input Forcing Baustein wurde als erstes und der Output Forcing Baustein als letztes im OB1 gerufen. Gefährliche Ausgänge konnten nicht geforced werden (Parametrierung).

Ziel ist es die Versorgung während Wartungsarbeiten nicht zu gefährden. Dazu erfolgte ein Stoßfreies Umschalten auf das IO-Forcing (Bei Aktivierung wurde der aktuelle IO Zustand geforced).
Bedienung erfolgte über Bildbausteine die mittels Textlisten die Adresse und das Symbol anzeigen. Es wurde auch der simulierte und tatsächlich Hardware Signal dargestellt.
Die Bedienung war nur durch entsprechende Nutzerstufe möglich und löste immer eine Warnung aus. Zusätzliche gab's einen Eskalation-Timer der bei zu langen IO-Forcing die Anlage stoppte.

Richtig zu schätzen lernt man das, wenn man sieht wie die Instandhaltung während des Betriebs eine Radarsonde tauscht/kalibriert. Oder wenn am Wochenende durch eine Überschäumung ein Überfüllsensor anschlägt und man ihn ausblenden kann, bis der Schaum weg ist.

Bei PCS7 fällt sowas sehr leicht, aber bei kleinen TIA Projekten ließ sich dieses IO-Forcing in jedes Projekt Nachrüsten.

 

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was soll denn das funktionelle Endziel an der Anlage sein?
Was unterscheidet dein Vorhaben von einem Handbetrieb, der bei jeder Anlage möglich sein sollte!

Der Grund meiner Frage ist, dass ich sowohl PC mit Hochsprachen als auch SPS programmiere.
Deine Frage ist sehr an die Denkweise einer PC-Programmierung angelehnt. Für SPS-Programmierung muss man
sich komplett von dieser Denkweise verabschieden! PC ist PC, SPS ist SPS => 2 Welten!

Einfach in einem Servicebetrieb Ausgänge wahllos durch den Bediener zu übersteuern führt unweigerlich zu Katastrophe
in mehrerer Hinsicht!

1. Wenn es dadurch die Möglichkeit eines Crash mit Zerstörung irgendwelcher Anlagenteile gibt, dann wird dass passieren
schneller als du denken kannst.

2. Im Problemfall
Servicefall, wenn du im Status einen Fehler suchen musst - am besten nach ein paar Jahren, nachdem man nicht mehr an der Anlage warst
oder ein Kollege muss das machen, da du gerade im Urlaub bist!
- Du siehst im Programm im Status nach -> Ausgang ist aus! Tatsächlich ist aber die LED am Ausgang ein!
Diagnose: Karte defekt!
- du suchst Querverweis. wo der Ausgang überall verwendet wird. Du findest das nicht, da die Ausgänge bei indirekter Adressierung
keinen Querverweis haben.

Für mich ist es jetzt schon sicher, dass hier irgendjemand Rachegelüste gegen dich entwickeln wird. Evtl. wirst du es selber sein, was hoffentlich zu einer heilsamen Wandlung führen wird. (Das haben wir leider wohl alle durchgemacht oder den Job quittiert!)

Vorschlag:
- Ausgang in der SPS nur 1x zuweisen, dann hat man kein Problem mit Querverweis und man kann Sicherheitsketten einprogrammieren,
an welchen niemand vorbeikommt. Servicesteuerung eines Antriebs oder Ventils immer mit einem extra Bit als Merker oder DB-Bit!

- Einen Betriebsartmerker Servicebetrieb erstellen und den Servicesteuermerker für jeden Aktor mit dem Betriebsartmerker Service
verknüpfen. Bei Betriebsartumschaltung alle Servicemerker löschen.

 

[ducati]

Mein Senf dazu:

In der Halbleiter Branche speziell in der Chemikalienversorgung war oft ein IO-Forcing über die Visualisierung gefordert.

Am Anfang fand ich das sehr gruselig und gefährlich. (Ich finde es immer noch gefährlich).

Wir haben das mit Peek und Poke umgesetzt. Der Input Forcing Baustein wurde als erstes und der Output Forcing Baustein als letztes im OB1 gerufen. Gefährliche Ausgänge konnten nicht geforced werden (Parametrierung).

Ziel ist es die Versorgung während Wartungsarbeiten nicht zu gefährden. Dazu erfolgte ein Stoßfreies Umschalten auf das IO-Forcing (Bei Aktivierung wurde der aktuelle IO Zustand geforced).
Bedienung erfolgte über Bildbausteine die mittels Textlisten die Adresse und das Symbol anzeigen. Es wurde auch der simulierte und tatsächlich Hardware Signal dargestellt.
Die Bedienung war nur durch entsprechende Nutzerstufe möglich und löste immer eine Warnung aus. Zusätzliche gab's einen Eskalation-Timer der bei zu langen IO-Forcing die Anlage stoppte.

Richtig zu schätzen lernt man das, wenn man sieht wie die Instandhaltung während des Betriebs eine Radarsonde tauscht/kalibriert. Oder wenn am Wochenende durch eine Überschäumung ein Überfüllsensor anschlägt und man ihn ausblenden kann, bis der Schaum weg ist.

Bei PCS7 fällt sowas sehr leicht, aber bei kleinen TIA Projekten ließ sich dieses IO-Forcing in jedes Projekt Nachrüsten.

Ja so Aussagen, "Hand ist Hand" usw. kenn ich auch...
Es gibt halt gute und schlechte Anlagenfahrer. Die guten können die halb defekte Anlage immer noch am Leben erhalten. Die schlechten fahrn Dir alles in Klump...
Bei PCS7 kannst Du quasi jeden Sensor und Aktor in Hand bzw. Simulation versetzen... das musst ohne PCS7 halt selber bauen

Bei Anlagen ohne Handmodus nachträglich die Ausgänge direkt zu forcen naja...
Irgendwann wird die ganze Anlage im "Forcebetrieb" über Wochen gefahren

 

[PN/DP]

Wer haftet eigentlich für den Schaden, wenn ein Anlagenbediener mit der Forcen-für-Jedermann-Funktion versehentlich eine oder mehrere Produkt-Paletten von einer Rollenbahn kippt? Oder versehentlich ein Dampfventil öffnet? Mit einer Funktion die geradezu nach Fehlbedienung schreit, so daß auch eigentlich nicht gewollte Ausgänge aktiviert werden können?
Der Programmierer der diese Funktion zur Verfügung gestellt hat? Weil er keine Lust hatte, eine verriegelte Hand-Funktion samt Bedienbild zu programmieren? Lohnt es, dieses Risiko eines Anlagenschadens einzugehen?

Was stellt sicher, daß eine aktivierte Ausgangs-Übersteuerung auch wieder beendet werden kann bevor was schlimmes passiert? Falls z.B. die Netzwerkverbindung zusammenbricht oder der steuernde PC abstürzt?

Wenn Du jetzt anfangen willst alle gefährlichen Ausgänge von der Übersteuerung auszunehmen, dann kannst Du auch gleich eine vernünftige Handbedienung programmieren, mit der man nicht die Anlage gefährden kann.

Ist Dein restliches SPS-Programm überall so programmiert, daß es nicht stört wenn da plötzlich Ausgänge angehen? Nicht daß da ungewollt noch weitere Aggregate anspringen weil Ausgänge zurückgelesen werden ala "Wenn A1.2 = 1 dann auch A3.4 = 1"? Weil A3.4 vielleicht mit keiner Betriebsart verknüpft ist, weil ja A1.2 normal nur in AUTO in Schrittkette Schritt 3 angehen kann?

Netzwerkabsicherung und Passwörter können gehackt werden. In einem ordentlich programmierten SPS-Programm ist es meist nicht weiter schlimm, wenn es dem Bösewicht gelingt, einen Ausgang-Ein-Befehl an die SPS abzusetzen, weil der Ausgang ein paar Millisekunden später wieder eine Zuweisung aus dem SPS-Programm erhält. Will er Schaden anrichten, dann muß er das SPS-Programm ändern (was zusätzlich abgesichert sein kann) oder zumindest aufwändiger analysieren. Muß man es dem Bösewicht so leicht machen und eine Comfortfunktion zum nachhaltigen forcen von Ausgängen zur Verfügung stellen?

Harald

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wer haftet eigentlich für den Schaden, wenn ein Anlagenbediener mit der Forcen-für-Jedermann-Funktion versehentlich eine oder mehrere Produkt-Paletten von einer Rollenbahn kippt? Oder versehentlich ein Dampfventil öffnet? Mit einer Funktion die geradezu nach Fehlbedienung schreit, so daß auch eigentlich nicht gewollte Ausgänge aktiviert werden können?
Der Programmierer der diese Funktion zur Verfügung gestellt hat? Weil er keine Lust hatte, eine verriegelte Hand-Funktion samt Bedienbild zu programmieren? Lohnt es, dieses Risiko eines Anlagenschadens einzugehen?

Wir hab 2 Arten von Kunden.
Beim ersten "Hand ist Hand" soll in Hand ALLES möglich sein.
Beim zweiten müssen ALLE "gefährlichen" Fehlbedienungen unter allen Umständen verhindert werden.
Ich kann beide verstehen. Der erste macht auch nur Sinn, wenn die Instandhalter und Anlagenfahrer wirklich nen Plan hhaben. Da werden auch mal schnell von Hand 10 Liter Salzsäure zum Neutralisieren irgendwo reindosiert, bevor halt irgendein anderes Problem entsteht....

Was stellt sicher, daß eine aktivierte Ausgangs-Übersteuerung auch wieder beendet werden kann bevor was schlimmes passiert? Falls z.B. die Netzwerkverbindung zusammenbricht oder der steuernde PC abstürzt?

redundante Anlagen und Visu und Notbedienplatz...

Wenn Du jetzt anfangen willst alle gefährlichen Ausgänge von der Übersteuerung auszunehmen, dann kannst Du auch gleich eine vernünftige Handbedienung programmieren, mit der man nicht die Anlage gefährden kann.

wenn ich die zwei Kollegen jetzt richtig verstanden habe, rüsten die dieses "forcen" eher an Bestandsanlagen nach, wo es aktuell eher garkeine Handbedienmöglichkeit gibt.


Es geht halt zum Teil auch darum "Softwarefehler" mal schnell durch Hanbdedienung überbrücken zu können. Zumindest übers Wochenende, bis am Montag der Programmierer anrückt.

Bei uns sind das halt Anlagen die 24/7 immer laufen müssen und für ne ganze Werkhalle oder das ganze Werk produktionsrelevant sind... Da ist der Schaden durch Produktionsausfall wenn die Anlage steht auch imens...

Da man nicht immer alles überreisst, passierts mir halt auch abundzu, dass irgendein Aktor in bestimmten Situationen "totverriegelt" ist. In solch einem Fall ist "Hand ist Hand" schon vorteilhaft. Auch für mich selber bei der IBN. Auf der andern Seite ist bei der IBN aber auch von Vorteil, wenn grundsätzlich der meiste Quatsch von Hause aus verriegelt ist, wie z.B. gleichzeitige Dosierung bon NaOH und HCl...

 

[Maagic7]

Bei uns sind das halt Anlagen die 24/7 immer laufen müssen und für ne ganze Werkhalle oder das ganze Werk produktionsrelevant sind... Da ist der Schaden durch Produktionsausfall wenn die Anlage steht auch imens...

Das Problem kenne ich auch zur genüge!
Wir haben das so gelöst!

Jedes Gerät bekommt seine eigene Betriebsart Aus/Hand(Ein)/Automatik
D.h. es gibt für jedes Gerät einen separaten Betriebsartenschalter.
Damit kann man z.B. eine Pumpe, ein Ventil aus der Automatiksteuerung rausnehmen und per Hand übersteuern,
ohne dass man Automatikprozesse beendet. Hat man das Problem behoben, schaltet man das Gerät in Automatik zurück.

Für einen normalen Bediener im Betriebsaltag ist es aber zu unübersichtlich, immer jedes Gerät einzeln in der Betriebsart zu schalten.
Deshalb gibt es eine "Parent" Übernahme der Betriebsart. D.h. im Normalbetrieb laufen alle Aktoren mit der Betriebsart der
übergeordneten Einheit. Man kann per Einstellung (Passwort) die Übersteurbetriebsart freigeben. Erst dann ist es möglich
die individuelle Handssteuerung zu aktiviern. Das hat sich bisher echt gut bewährt.

Ausgänge und Eingänge per "forcing" direkt zu übersteuern machen wir nicht!
Das kann der Elektriker, Service einfach mit einer Drahtbrücke bewerkstelligen.
Ventile haben normalerweise allesamt einen Handbedienknopf direkt am Ventil.
Damit kann man gut schnell mal einen Zylinder ausfahren lassen.

Was wirklich Sinn macht ist das simulieren von Analogsensoren, da hier im Fehlerfall eine Drahtbrücke nichts bringt.
Das Problem mit dem simulieren ist, dass das wirklich sauber durchdacht und programmiert werden muss.
z.B. 1x täglich quittieren, sonst geht das wieder aus!
Ist das nicht so, schafft es garantiert jemand die Handbedienung stehen zu lassen, obwohl der Sensor repariert ist.

Wen das interessiert mit der Parent Betriebsart:
FC366 "m7b_GlobalParent_Mode"
FC 86 "m7b_Aus_Hand_Auto"

GitHub - Maagic7/Maagic7

Contribute to Maagic7/Maagic7 development by creating an account on GitHub.

github.com

 

[ducati]

Ist das nicht so, schafft es garantiert jemand die Handbedienung stehen zu lassen, obwohl der Sensor repariert ist.

Wir geben Warnmeldungen im HMI aus, wenn Sensoren in Simulation oder Aktoren in Hand stehen...

 

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir geben Warnmeldungen im HMI aus, wenn Sensoren in Simulation oder Aktoren in Hand stehen...

Das auf jeden Fall! Aus Erfahrung werden aber Warnmeldung oft ignoriert! Anlage läuft doch! Warung ist ganz normal!
Selbst wenn das jahrelang gut funktioniert hat. Nachdem der originale Bediener nicht mehr da ist und das ein neuer machen muss.,
geht es los mit solchen Problemen!

 

[ducati]

Das auf jeden Fall! Aus Erfahrung werden aber Warnmeldung oft ignoriert! Anlage läuft doch! Warung ist ganz normal!
Selbst wenn das jahrelang gut funktioniert hat. Nachdem der originale Bediener nicht mehr da ist und das ein neuer machen muss.,
geht es los mit solchen Problemen!

Ja schon klar
Die ganze Welt kann man halt nicht retten
Ausblenden kannst die Warnmeldung ja auch noch...

Die Simulation nach einer gewissen Zeit wieder abzuschalten widerspricht halt der Prämisse "Hand ist Hand" Und wielange willst Du drüber diskuttieren, ob das nach 1 oder 3 Tagen rückgesetzt wird? Evtl. bei jedem Sensor nach einer anderen Zeit? Irgendwann steht die Rücksetzzeit dann auch auf 100Tage...

Ich bin aktuell eher auf dem Tripp "Weniger ist mehr", die Software mit immer mehr Sonderlockenfunktionen zuzuballern ist auch nicht wirklich die Lösung. Man schaue sich mal einen PCS7-Messwertbaustein an...