TIA 24h Prozessdatenpuffer remanent in der SPS

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Werte Freunde des Bitschubsens,
mein Häuptling will malwieder ulkige Dinge von mir & da das große G nicht viel zu diesem speziellen vorhaben ausgespuckt hat, bräuchte ich mal eure Meinung dazu.

Vorhaben/Anforderung:
- Kleine S7-1500 CPU (insgesammt ca. 40 jeweils eigenständige Anlagen), die verschiedene (noch zu definierende) Prozessdaten generieren
- Die Prozessdaten werden für gewöhnlich von einem Leitsystem in Empfang genommen & gespeichert
- Die SPSen sollen bei Ausfall der Verbindung zum Leitsystem die Prozessdaten für mindestens 24h zwischenspeichern können
- Nach Wiederherstellung der Verbindung zum Leisystem sollen die gepufferten Daten dem Leitsystem zur Abholung bereit gestellt werden.
- Sollte während der Ausfallphase die Stromversorgung der lokalen SPSen unterbrochen werden, darf es zu keinem Verlust der bereits gepufferten Prozessdaten kommen.

Bereits definierte Hardware:
- Die lokalen 1500er SPSen werden vermutlich 1510SP f-1 PN (6ES7 510-1SK03-0AB0)
- Tia V19

Mengengerüst Daten:
Abtastrate 1s
=> 86400 Datensätze je 24h
=> würde je Datensatz einen DTL-Timestamp und max. rund 180 byte Prozessdaten ermöglichen (wenn wir in den 16MB grenzen der SPS bleiben wollen).


Ich hab zum groben Ablauf bzw. der Struktur schon etwas gehirnt.
Generell würde ich das in einen Puffer und eine Handshake-Funktion zum Leitsystem aufteilen.


Die Handshake-Funktion zum Wegschaufeln der Daten soll uns an diesem Punkt mal nicht interessieren, problematisch ist für mich grade die Umsetzung des Puffers.
Prinzipiell hatte ich mir den internen Ablauf mal so etwa vorgestellt:


Soweit so undramatisch...dachte sich der kleine @Botimperator.
Knackpunkt ist das Thema "Remanenz & verfügbarer Datenspeicher".
Die 1510 hat 1MiB Datenspeicher und rund 216KiB remanente Daten.
Da bis zu 16MB Daten remanent unterzubringen könnte... a bissle eng werden.
Aber wir haben ja noch ne Speicherkarte & nur im Ladespeicher vorhandene DBs sind ja auch quasi remanent.
Da solche Verbindungsausfälle zum Leitsystem recht selten sein sollten, stellt diese geplante Funktion eher eine art Notfallsicherung dar.
=> sollte keine Probleme mit der Lebensdauer der SMC geben.

Bei der eigentlichen Umsetzung gestaltet sich die Angelegenheit aber nicht so einfach....

Idee: den zweiten FIFO-Puffer auf der SMC-Karte wie einen normalen DB behandeln
Wäre die einfachste Idee gewesen, funktioniert aber nicht.
Verschiedene Funktionen funktionieren mit Ladespeicher-DBs nicht.
"CountOfElements" gibt beispielsweise bei einem "Array[0..99] of UDT" (welches im Ladespeicher liegt) 0 zurück.
Eine normale Zuweisung auf ein Testarray im Ladespeicher...

...schickt die SPS mit einem Programmierfehler in STOP.


Idee: Die DataLog Funktionen als Speicher zu missbrauchen (づ￣ 3￣)づ
...funktioniert aber nur vom Programm ins Log.
Zurücklesen im SPS-Programm ist wohl nicht möglich.
Und die übergelaufenen Daten vom Leitsystem per SPS-Webserver und .csv-File abholen zu lassen ist nicht gewünscht.

Idee FileHandling per FileReadC/WriteC
Würde (theoretisch) funktionieren, allerdings würden die Daten dann, wenn ich das richtig verstanden habe, als ein Haufen Bytes geschrieben werden.
Da mal was im laufenden Betrieb kontrollieren sehe ich als schwierig.
Oder was tun wenn meine Funktion aus irgendeinem Grund den Schreib/Lese-Index verloren hat (=> Datenbaustein versehentlich initialisiert).


Idee: Datenbausteinfunktionen Read_DBL/Write_DBL für Zugriff auf Ladespeicher
Funktioniert aber nur mit dem kompletten DB, nicht mit Elementen des DBs.
Für nen Fifo eher doof....

Eine letzte Idee meinerseits wäre noch gewesen den Datenspeicher des FIFO vollaufen zu lassen & dann immer per "Create_DB" zur Laufzeit einen neuen DB auf der SMC zu erzeugen & dann die Daten aus dem vollen Puffer per "Write_DBL" in den neuen DB zu verschieben.

Meine Fragen wären:
- Hatte jemand von euch schonmal so eine Anwendung? Wie hab ihr das gelöst?
- Gibt es von euch aus Erfahrungen zum Thema "DBs zur Laufzeit zu erzeugen"? Gibt es da irgendwelche Fallstricke auf die ich achten muss? (Bin in dem Thema komplett jungfräulich)
- Gibt es ggf. noch eine elegantere Lösung auf die ich noch nicht gekommen bin?

 

[NBerger]

Bei der Anzahl an Schreibzugriffen auf die SMC lebt diese nicht lange...

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Muss es denn vorgehalten werden? 86k Werte und dein Vorgesetzter denkt nicht an eine Datenbank?

Sowas gehört ereignisgesteuert für jeden Wert in eine Datenbank abgelegt und hat 2024 nichts in einer Steuerung verloren.

 

[Botimperator]

Bei der Anzahl an Schreibzugriffen auf die SMC lebt diese nicht lange...

Wie gesagt:
der "normale" Betrieb würde über den Fifo im Arbeitsspeicher gepuffert werden, wie in meinem kleinen Ablauf dargestellt.

Die SMC würde ich AUSSCHLIEßLICH beschreiben wenn mir die remanenten Daten im Arbeitsspeicher nicht mehr reichen.
Das sollte nicht allzu häufig vorkommen und wenn die SMC nach jedem Verbindungsabbruch ersetzt werden muss wäre das immernoch akzeptabler als Teile der Prozessdatenaufzeichnung zu verlieren.

Muss es denn vorgehalten werden? 86k Werte und dein Vorgesetzter denkt nicht an eine Datenbank?

Sowas gehört ereignisgesteuert für jeden Wert in eine Datenbank abgelegt und hat 2024 nichts in einer Steuerung verloren.

Das Leitsystem IST die Datenbank.
Bringt halt nicht viel wenn die Netzwerkverbindung zwischen Datenquelle und Datenbank zusammenbricht.

Diese Funktion ist als Notfallpuffer gedacht wenn die Datenbank aus irgendeinem Grund kurzzeitig nicht zur Verfügung stehen sollte.
Im Normalbetrieb sollte diese SPS-Funktion die Prozessdaten immer unmittelbar an die Datenbankanwendung im Leitsystem weitergeben können und den Puffer auf der SMC nie tatsächlich nutzen.

Die Anforderung für 24h Notfallpuffer kommt daher, dass es schon vorgekommen ist das irgendjemand versehentlich das falsche Netzwerkkabel gezogen hat & dann plötzlich Feierabend war.
Oder der outgesourced IT-Inder irgendwas im Routing rumpfuschen musste & dann erstmal gar nichts mehr lief.

Und die 40 SPSen gegen IPCs mit eigener Datenbank tauschen? Ich habs vorgeschlagen, die Antwort kannst du dir denken.
Bin ja schon froh, dass wir über 1500er SPSen reden & nicht über 1200er oder Logo.

 

[DCDCDC]

Wie gesagt:
der "normale" Betrieb würde über den Fifo im Arbeitsspeicher gepuffert werden, wie in meinem kleinen Ablauf dargestellt.

Die SMC würde ich AUSSCHLIEßLICH beschreiben wenn mir die remanenten Daten im Arbeitsspeicher nicht mehr reichen.
Das sollte nicht allzu häufig vorkommen und wenn die SMC nach jedem Verbindungsabbruch ersetzt werden muss wäre das immernoch akzeptabler als Teile der Prozessdatenaufzeichnung zu verlieren.


Das Leitsystem IST die Datenbank.
Bringt halt nicht viel wenn die Netzwerkverbindung zwischen Datenquelle und Datenbank zusammenbricht.

Diese Funktion ist als Notfallpuffer gedacht wenn die Datenbank aus irgendeinem Grund kurzzeitig nicht zur Verfügung stehen sollte.
Im Normalbetrieb sollte diese SPS-Funktion die Prozessdaten immer unmittelbar an die Datenbankanwendung im Leitsystem weitergeben können und den Puffer auf der SMC nie tatsächlich nutzen.

Die Anforderung für 24h Notfallpuffer kommt daher, dass es schon vorgekommen ist das irgendjemand versehentlich das falsche Netzwerkkabel gezogen hat & dann plötzlich Feierabend war.
Oder der outgesourced IT-Inder irgendwas im Routing rumpfuschen musste & dann erstmal gar nichts mehr lief.

Und die 40 SPSen gegen IPCs mit eigener Datenbank tauschen? Ich habs vorgeschlagen, die Antwort kannst du dir denken.
Bin ja schon froh, dass wir über 1500er SPSen reden & nicht über 1200er oder Logo.

Wenn du mit den Schreibzyklen der Speicherkarten argumentierst? Sonst kann er bei Siemens mal ein 100er Pack vorbestellen, überspitzt gesagt.

Wie wäre eine shop floor Lösung? Lokal, direkt vor Ort?

Ist Server A nicht erreichbar, dann ab in die Datenbank auf Server B, und dann von da aus, bei wiederkehrender Verbindung von B nach A und von den CPUs wieder nach A.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du mit den Schreibzyklen der Speicherkarten argumentierst? Sonst kann er bei Siemens mal ein 100er Pack vorbestellen, überspitzt gesagt.

Das ich mit dem Thema "Schreibzyklen" vorsichtig sein muss ist mir auch klar, deswegen dieser Tread.

Schau dir bitte nochmal mein Ablaufdiagramm im ersten Post an.
Gerade wegen der "wann wird auf die SMC ausgelagert"-Diskussion habe ich mir die Arbeit mit dem Ding gemacht.

Der FIFO[1] liegt im remanenten Arbeitsspeicher der SPS (NICHT auf der SMC).
FIFO[1] bekommt die Prozessdaten und reicht sie an den Handshake zum Leitsystem (also an die Datenbank) weiter.
Da das Leitsystem um einige Größenordnungen schneller die Prozessdaten abholen kann als diese im Prozess anfallen sollte FIFO[1] nie voll laufen und FIFO[2] (der auf der SMC) nie in Aktion treten (das wäre die normale Produktions-Situation).

FIFO[1] würde ich groß genug dimensionieren um auch mal 1-2 Stunden Verbindungsverlust zu puffern ohne Daten in FIFO[2] (also die SMC-Karte) auszulagern zu müssen.

Das sollte in aller Regel mehr als ausreichen, gefordert sind aber bis zu 24h Puffer (Und 24h Daten bekomme ich halt nicht in den Arbeitsspeicher).
Sehr pessimistisch gerechnet würde ich einen 24h-Ausfall pro Jahr rechnen.
Das sind dann rund 16MB für einen 24h-Intervall, also 1,6GB Schreibvolumen auf 100 Jahre Anlagen-Lebensdauer.
Eine 32GB SMC (6ES7 954-8LT03-0AA0) hat laut Siemens (siehe <hier>) eine Lebensdauer von 32TB Schreibvolumen.
=> Unter Berücksichtigung der, aus meiner Sicht, schlimmstmöglichen Ausfallsituation würden die möglichen Schreibzyklen mit einer 32GB SMC für 20480 Betriebsjahre ausreichen (abzüglich ein bisschen fürs schreiben des SPS-Programms).

Wie wäre eine shop floor Lösung? Lokal, direkt vor Ort?

Der Leitsystem-Server ist bereits so nah wie möglich vor Ort.
Und wenn dir jemand das Netzwerk ausknipst bringt dir physische Nähe auch nichts mehr.

Ist Server A nicht erreichbar, dann ab in die Datenbank auf Server B, und dann von da aus, bei wiederkehrender Verbindung von B nach A und von den CPUs wieder nach A.

Punkte die dagegen sprechen:
- Umbau der bestehenden Software.
- Zusätzlicher (physischer) Server (ja, das mit dem einzelnen Server und dem riesigen Mimimi wenn mal ein paar Prozessdatensätze fehlen finde ich auch faszinierend)
- Wenn dir direkt an der SPS jemand das Netzwerkkabel zieht guckste auch in die Röhre.

 

[DCDCDC]

Eingangs klang das wie die normale Lösung, wenn dass nur die Fallback Lösung ist für die Eventualität dann passt das ja.

Auch die Ausfälle klangen regelmäßiger als jetzt im letzten Beitrag geschildert ist.

Hab aber tatsächlich in keiner Produktion bisher, selbst in China, jemanden gesehen, der einfach so Patchleitungen vom MES abzieht, oder sonst wo im Schaltschrank Man lernt ja nie aus

 

[JSEngineering]

- Sollte während der Ausfallphase die Stromversorgung der lokalen SPSen unterbrochen werden, darf es zu keinem Verlust der bereits gepufferten Prozessdaten kommen.

Ihr definiert hier ja schon eine 2-Fehler-Redundanz... Netzwerkfehler UND Stromausfall.
Wie wäre es, wenn Ihr den 2. Fehler "Stromausfall" derart unwahrscheinlich macht, daß Du Dir darüber keine Sorgen machen mußt?
Zum Beispiel eine USV einsetzen?
Die USV muß dann ja auch nur so groß/klein sein, daß die SPS vielleicht Zeit hätte, die aufgezeichneten Daten aus dem flüchtigen Speicher geordnet auf eine Speicherkarte zu schreiben. Also bräuchtest Du ja vielleicht nicht mehr als 3s Überbrückung --> Entsprechendes Netzteil raussuchen. Stromausfall -> Digitaleingang meldet -> SPS schreibt Daten geordnet weg -> Komplettausfall. Und beim Hochbooten liest Du dann einmalig diese Datei wieder ein und machst weiter, als wäre nichts geschehen.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hab aber tatsächlich in keiner Produktion bisher, selbst in China, jemanden gesehen, der einfach so Patchleitungen vom MES abzieht, oder sonst wo im Schaltschrank Man lernt ja nie aus

Du wärst fasziniert was den Leuten manchmal im Weg sein kann.
Und fangen wir garnicht erst damit an, dass Netzwerkkabel in bestimmte Buchsen müssen....
"...Aber zuhause ists doch auch schei* egal wo ich das Ding einstecke, funktioniert doch..."
Manche kapieren einfach nicht, dass das eine Industrieanlage ist & nicht ihr Weib (╯‵□′)╯︵┻━┻

Zum Beispiel eine USV einsetzen?

Es gibt eine Zentral-USV für die Steuer-Leistung.
Lokale USVs in den Maschinen sind nicht möglich.
Temperaturbereich 40-45°C in den Schaltschränken (Stahlindustrie), das ist schon für die normale Elektronik hart am Limit.
USVs oder Kondensatormodule halten da nicht lange.
Platzbedarf und Anschaffungskosten außen vorgelassen.

Die USV muß dann ja auch nur so groß/klein sein, daß die SPS vielleicht Zeit hätte, die aufgezeichneten Daten aus dem flüchtigen Speicher geordnet auf eine Speicherkarte zu schreiben. Also bräuchtest Du ja vielleicht nicht mehr als 3s Überbrückung --> Entsprechendes Netzteil raussuchen. Stromausfall -> Digitaleingang meldet -> SPS schreibt Daten geordnet weg -> Komplettausfall. Und beim Hochbooten liest Du dann einmalig diese Datei wieder ein und machst weiter, als wäre nichts geschehen.

Die SPS hat 1MB Datenspeicher, den sich der FIFO auch noch mit so unnötigen Sachen wie dem Rest des SPS-Programms teilen muss.
Ich komm selbst mit dem noch verfügbaren, flüchtigen Datenspeicher vllt. 4-5 Stunden weit, keine 24h.

Meine Fragen wären:
- Hatte jemand von euch schonmal so eine Anwendung? Wie hab ihr das gelöst?
- Gibt es von euch aus Erfahrungen zum Thema "DBs zur Laufzeit zu erzeugen"? Gibt es da irgendwelche Fallstricke auf die ich achten muss? (Bin in dem Thema komplett jungfräulich)
- Gibt es ggf. noch eine elegantere Lösung auf die ich noch nicht gekommen bin?

Meine dritte Frage bezog sich eigentlich konkret auf programmiertechnische Umsetzungsmöglichkeiten des remanenten 16MB FIFOs in der SPS.
Den "müssen wir das unbedingt in der SPS lösen?"-Teil habe ich schon zum Erbrechen hier intern diskutiert.

Klassisches: "wenn du gut darin bist den kranken schei* zum Laufen zu bekommen - sorge dafür, dass dein Vertrieb nichts davon erfährt. Er könnte auf Ideen kommen..."

 

[INSEVIS-Service]

Hallo

wir lösen so was mit einer CompactCPU:

- die Daten werden als CSV auf ein gesteckte µSD geschrieben. Die hält bei uns auch mehrere Jahre.

- nach Wiederkehr der Verbindung zum PLS werden die Daten gelesen und an das PLS geschickt. Kann euer PLS mit Historischen Daten mit Zeitstempel umgehen ?

- Kopplung zu den Maschinensteuerungen über TCP/IP S7 Komunikation.

Die dafür notwendigen SFC sind in unseren CPU immer vorhanden.

 

[Botimperator]

wir lösen so was mit einer CompactCPU:

Jup, war auch einer meiner Gedanken
Leider ist Kundenvorgabe das große S, ohne wenn und aber.
Ein zweiter Controller nur zum Zwischenspeichern ist explizit abgelehnt worden.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sodele, ich hab mal etwas weiter gehirnt und bin zumindest mal auf einem recht guten Weg zur Lösung.
Zumindest etwas was funktioniert, geht jetzt noch um die Details.

Die Idee DBs auf der SMC zu erzeugen & dann in diese Daten auszulagern habe ich verworfen.
Ich kann per CREATE_DB überhaupt nur eine sehr begrenzte Anzahl an DBs erzeugen (1000 stk), ich muss diese manuell numerieren (was bei mehreren dieser FIFOs auf einer SPS dann auch koordiniert werden muss) und ich muss teilweise nicht optimierte DBs verwenden (will nicht optimiert/nicht optimiert mischen).

Hab mich deswegen für die Speicherung per Auslagerungsdatei und den FileHandling-Funktionen entschieden.
Im Groben besteht dieser FIFO jetzt aus drei einzelnen FIFOs.
Die Datensätze werden zuerst in einen InputFIFO gespeichert.
Läuft dieser InputFIFO voll, wird dessen Datenpuffer zusammen mit den Arbeitsvariablen des InputFIFO auf die SMC geschrieben.
Die Datenverwaltung auf der SMC arbeitet mit einem Lese- und Schreibindex im Grunde ebenfalls wie ein FIFO.
Wenn jetzt Daten abgeholt werden...
...werden zuerst die Datensätze aus dem OutputFIFO ausgegeben.
...wenn der OutputFIFO leer ist und noch Datenblöcke im SmcFIFO enthalten sind, wird ein Datenblock aus dem SmcFIFO geholt, in den OutputFIFO geladen und von dort dann der nächste Datensatz ausgegeben.
...Wenn der OutputFIFO und der SmcFIFO leer ist, werden die Datensätze direkt aus dem InputFIFO ausgegeben.

Das ermöglicht es, solange der Puffer des InputFIFO nicht voll läuft, die Datensätze nur im Arbeitsspeicher rumzureichen und die SMC nur zu belasten wenn es zu einem Datenstau kommt.
Mögliche Speichermenge sind 16Mib Puffer-Blöcke (Bei jedem Speicherblock kommen zu den FIFO Pufferdaten noch 8byte Arbeitsdaten) + 2x FIFO Puffer-Array.

Wie gesagt:
Der Prototyp funktioniert schonmal, jetzt geht es um die Details.
Im Speziellen darum Fehlkonfigurationen zu erkennen und die Funktion gegen Datenverluste/Fehler bei RUN=>STOP Übergängen abzusichern.

Was die Fehlfigurationen angeht suche ich noch nach einer Lösung für die Remanenz der Puffer-Arrays im Arbeitsspeicher.
Diese Arrays müssen für meine Anforderung zwingend remanent sein & das möchte ich bei der Bausteinintialisierung prüfen.
Meine erste Idee war die Puffer mit Array-DBs zu realisieren und per ATTR_DB die Remanenz abzufragen.
Das Abfragen funktioniert, nur kann ich Array-DBs nicht als Remanent anlegen (╯‵□′)╯︵┻━┻
Wenn ich die Arrays in einem globalen DB anlege, liefert mir die Funktion VARIANT_TO_DB_ANY logischerweise einen Fehler (ist ja auch ne Variable & kein DB).

Daher meine Frage:
Gibt es eine Möglichkeit ein per Variant übergebenes Array auf seine Remanenz abzufragen?

 

[Botimperator]

Ich denke ich habe jetzt die letzten Bugs aus dem guten Stück raus geprügelt.
Anbei die Bausteinquelle mit Bitte um Feedback und Bugreports, falls ihr welche findet.

Daher meine Frage:
Gibt es eine Möglichkeit ein per Variant übergebenes Array auf seine Remanenz abzufragen?

Dafür hab ich bisher noch keine Lösung gefunden => gibt ein Update, falls mir dazu noch was einfällt.

 

[Botimperator]

Hab nochmal nen Nachtrag, da ich doch noch einen Bug gefunden habe.

Änderungen:
- Anlaufverhalten bei SPS-Neustart korrigiert. Einige Arbeitsvariablen waren noch als nicht remanent markiert, was zu Fehlern geführt hat.
- Zusätzlicher Diagnosepuffereintrag bei "ErrorUserCleared" (Neustart des Bausteins durch toggeln von "iEnable" notwendig)

 

[pvbrowser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein Ansatz bei diesem SPS Problem wäre folgender:

Man spendiere einen zusätzlichen Rechner (z.B. Raspi mit Linux, ohne Monitor) und
baue den auf dieselbe Hutschiene / Schrank wie die SPSen.

Man speichere dort die Daten in CSV Dateien in einer RAM-Disk und
verwende dabei Dateinamen, die das Datum/Uhrzeit mit im Namen haben

Man purge / säubere die Daten so, dass z.B. nur die neuesten 2..3 Tage vorhanden sind.
Altes Zeug werfe man in die Tonne.

Der Leitrechner kann dann die Daten asynchron (z.B. mit scp) abholen.

 

[Blockmove]

@Botimperator
Also sorry aber dein Konzept ist absolut nicht mehr zeitgemäß.
Wir haben so ein Konzept das letzte mal irgendwann in den 90ern umgesetzt.
Es gibt verschiedene Möglichkeiten ein Netzwerk ausfallsicher zu gestalten (z.B. Glasfaserring).
Hochverfügbarkeit bei Datenbanken ist heute quasi schon Standard.

 

[Onkel Dagobert]

Ich schmeiß mal Begriffe wie "Prozessleittechnik" und "Fernwirktechnik" in den Raum, ohne spezielle Kenntnisse meinerseits.

 

[pvbrowser]

Zuviel Werbung?
-> Hier kostenlos registrieren

In den 90ern war ich auch noch jünger.
Evtl. ist das Konzept deshalb bei mir hängen geblieben.
Inzwischen bin ich ja schon Rentner

PS: Warum fängt bei uns das ZDF an Klötzchen zu bekommen und dann ganz auszufallen , wenn es regnet.
Ich glaube mich zu erinnern, dass das in den 90ern schon mal besser war.

 

[Botimperator]

Also sorry aber dein Konzept ist absolut nicht mehr zeitgemäß.
Wir haben so ein Konzept das letzte mal irgendwann in den 90ern umgesetzt.
Es gibt verschiedene Möglichkeiten ein Netzwerk ausfallsicher zu gestalten (z.B. Glasfaserring).
Hochverfügbarkeit bei Datenbanken ist heute quasi schon Standard.

Ich würde es eher als eine Frage der zielführensten Lösung argumentieren.
Wie in #1 erklärt war die Anforderung lediglich einige Prozessdaten im Notfall (und nur im Notfall, wie in #6 präzisiert) zwischenspeichern zu können.

Natürlich hätte ich gerne eine Redundanzlösung gehabt.
Für die Netzwerkredundanz hätte ich das bestehende Netzwerk incl. einem großteil der aktiven Komponenten Umbauen oder austauschen müssen, neue Kabeltrassen legen (macht nicht viel Sinn redundante Verbindungen im gleichen Kabelkanal zu verlegen), uvm....
Im Endeffekt ein hoher 6stelliger Invest in meinem Fall.
Und vor einem "die IT hat das Routing begrabbelt und verkackt" würde es immer noch nicht schützen.

Der von @pvbrowser vorgeschlagene Raspi schlägt in die gleiche Kerbe wie die von @DCDCDC und @INSEVIS-Service vorgeschlagenen Lösungen mit zusätzlichen Bauteilen.
Klar würde das funktionieren, wäre im Prinzip aber auch nur ein zusätzlicher FIFO für Daten.
Außerdem hätte ich dann bei der Raspi-Lösung nochmal 40 vollwertige PCs zum Warten gehabt.
Vulnerability management, Wartung und noch mehr Gründe für die IT sich im Anlagennetz rumzutreiben.
Außerdem: Wie lange hält ein Raspi eigentlich?
Die Anlage um die es geht ist 60 Jahre alt und wird nach dem Retrofit nochmal >60 Jahre laufen.
Bekomme ich in 20 Jahren noch einen Raspi auf dem ich das Backup des heutigen Raspi einspielen kann & läuft? Ich hab da so meine Zweifel....
Selbst die Ersatzteilverfügbarkeit von Siemens ist hier manchmal...unbefriedigend.

Der in #14 vorgestellte Code erledigt das von mir benötigte Notfall-Zwischenspeichern ohne dass ich zusätzlichen Invest oder potenzielle Instandhaltungs-Baustellen aufwerfen muss.
Die Funktion läuft im Hintergrund, macht bei Bedarf ihre Magic und wird vermutlich auch noch auf die nächste Generation der Siemens SPSen migrierbar sein.
Macht für mich: der SPS-FIFO hat beim Erstellen nur ein paar Nerfen gekostet & Ersatzteilverfügbarkeit >40 Jahre für die SPS der Anlagen.
Das reicht selbst für mich knapp bis zur Rente.

Und wenn ich meinen faltigen Hintern in der Sonne bräune, kann mein Nachfolger gernen nen Raspi (oder KI-Chip, oder was auch immer es dann geben wird) in den Schaltschrank schrauben ¯\_(ツ)_/¯

 

[pvbrowser]

> Außerdem hätte ich dann bei der Raspi-Lösung nochmal 40 vollwertige PCs zum Warten gehabt.
1 Raspi kann doch die Daten von allen 40 lokalen SPSen zwischenspeichern, um sie der Überwachung bereitzuhalten.
Wir müssen heute mit Überwachbarkeit rechnen, immer.

In ein Paar Jahren, wenn es keinen Raspi mehr geben sollte,
gehe ich mal davon aus, dass es immer noch C und C++ Compiler geben wird.

Wenn ich den Quelltext der Saftware selber in der Hand habe, ist das alles kein Problem.

Die Leute auf der Anlage müssen halt C/C++ können.

Scriptsprachen haben alle mehr oder weniger starke Einschränkungen.