TC3: Dokumentation und Tipps gesucht, wie man Redundanz plant.

Beiträge
6.532
Reaktionspunkte
1.558
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo alle zusammen,
ich betrete gerade, was das Thema angeht, völliges Neuland.
Es geht um einen USV Verbund. Der Verbund besteht aus 8 USVen, die immer in Zweierpacks zusammengebaut sind.
Die einzelnen USVen kommunizieren über spezielle Boards miteinander und regeln sich gegenseitig. Das läuft alles autonom und ist schon redundant.
Via Modbus und I/Os werden Daten von den USVen von einem übergeordneten System eingesammelt und dieses stellt verschiedene Daten wiederum wieder via Modbus einem Verwaltungs-/Überwachungssystem (Oder was auch immer) des Kunden zur Verfügung. Dieses System fragt auch zwei Ziehl UFR1001E ab. Eins kontrolliert die Frequenz und Spannung der NV-Seite des Mittelspannungstrafos, das Andere die Frequenz und Spannung der Generatorversorgung.
Sobald die Versorgungsspannung wegbricht erkennen die USVen dies selbstständig und handeln entsprechend. Das übergeordnete System erkennt den Ausfall durch das Ziehl Gerät und gibt über einen digitalen Ausgang einen Startimpuls an das Dieselaggregat. Sobald sich die Frequenz und Spannung des Dieselaggregates innerhalb der zulässigen Toleranz befindet und eine Wartezeit abgelaufen ist, wird über einen digitalen Ausgang ein Öffnungsimpuls an den Schalter an der NV Seite des Trafos gesendet und anschließend ein Schließimpuls an einen Schalter am Dieselaggregat.
Der Kunde von meinem Auftraggeber kommt nächste Woche zu Besuch, daher sind die Angaben die ich bisher machen kann relativ wage, aber ich wollte mich vorab schon informieren, Entschuldigung dafür.
Das übergeordnete System ist derzeit ein CP2715 Panel mit TwinCAT 4024 (Die Unterversion kann ich gerade leider nicht nachsehen, müsste aber 50 sein) unter Windows CE. Auf diesem läuft das SPS Programm und die TF1810 als Visu. Wenn möglich soll die Visu auch nicht auf die TE/TF2000 umgestellt werden. Beim Kunden werden mehrere USV-Verbünde in dieser Konstellation zum Einsatz kommen.
Zwei dieser USV-Verbünde sind jetzt wohl besonders wichtig, was dem Kunden jetzt erst, kurz vor Fertigstellung der Systeme, aufgefallen ist. :unsure:
Hier soll nun eine Redundanz realisiert werden. Meine Frage wäre jetzt nur wie? Sobald das Paket TF1100 verfügbar ist kann eine CPU Redundanz unter TwinCAT realisiert werden, natürlich dann nicht mehr mit dem CP2715, sondern, zum Beispiel, mit zwei C60XX.
Hier stellt sich für mich nun aber die erste Frage, die Visu läuft ja auf beiden CPUs vermutlich getrennt. Wie müsste das gehandhabt werden? Rein Interessehalber, weiß einer, wie das bei der TE/TF2000 laufen würde?
Was muss jetzt noch berücksichtigt werden? Es gibt ja noch die Funktion TF6220 für die Kabelredundanz, da wäre dann die Frage, ob das mit der CPU Redundanz zusammenläuft?
Als nächstes wären dann noch die Rückmeldungen vom Generator und die Steuersignale zu diesem, die müssten ja auch doppelt ausgeführt werden.
Wie gesagt, es ist alles Neuland für mich. Sobald klar ist, was für eine Redundanz der Kunde haben möchte sollte sich der Auftraggeber sicher auch mal Beckhoff für 1-2 Tage ins Haus holen, zwecks einer Beratung, aber da ich das Ganze vermutlich umsetzen muss/soll, wollte ich mich schon einmal vorab informieren.
 
"Das redundante System ist dabei über das Automation Device Specification (ADS)-Protokoll transparent als ein System ansprechbar, was dazu führt, dass überlagerte Systeme wie HMI oder MES die redundante Auslegung nicht zu berücksichtigen brauchen"

So hab ich es auch von Beckhoff erfahren, das HMI kann dann allein iergendwo laufen und verbindet sich mit dem "Gesamtsystem". Wie das technisch genau aussieht, bleibt abzuwarten bis mind. 3.Quartal.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"Das redundante System ist dabei über das Automation Device Specification (ADS)-Protokoll transparent als ein System ansprechbar, was dazu führt, dass überlagerte Systeme wie HMI oder MES die redundante Auslegung nicht zu berücksichtigen brauchen"

So hab ich es auch von Beckhoff erfahren, das HMI kann dann allein iergendwo laufen und verbindet sich mit dem "Gesamtsystem". Wie das technisch genau aussieht, bleibt abzuwarten bis mind. 3.Quartal.
Stimmt das hatte ich auch gelesen, aber dann wohl leider ignoriert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmi ist Wohl unproblematisch in diesem Fall einfach per commd Line den Server Neustarten oder Client Side die Seite neu laden so lange das HMI nur als Anzeige und Eingabe der Daten funktioniert
 
Hoffen wir mal, dass sich das angegebene Jahr nicht ändert und eine erste finale Version in den nächsten Wochen rauskommt.
Ich weiss ja nicht, was Du vorhast, aber in ner hochwichtigen Anlage eine grad rausgekommene redundante Steuerung einzusetzen ist Irrwitz perse.

Für "Redundanz" bzw. "Hochverfügbarkeit" muss man sich in Ruhe überlegen, was man überhaupt will und wie man das umsetzt.
Das geht von der Mechanik über Sensorik/Aktorik über IO über Bussystem über Steuerung über Visualisierung über Netzeinspeisung über Medienversorgung (Druckluft)... u.U. alles zu betrachten.

Ich überlege mir konkret, läuft die Anlage bei Defekt EINES BELIEBIGEN Bauteils unbeeinträchtigt weiter. Das kann z.B. ein defekter Sicherungsautomat oder auch Sensor oder Netzwerkstecker oder Koppelrelais oder auch CPU-Stop sein...
Doppelfehler betrachte ich normalerweise nicht.
Nächste Überlegung, kann jedes beliebige defekte Teil im laufenden Betrieb getauscht werden.

In Deinem Fall führt ja ein Ausfall Deiner Steuerung erstmal zu garkeinem Problem, solange nicht gleichzeitig ein Stromausfall passiert (Doppelfehler)? U.U. brauchst Du garkeine Redundanz wenn ein Defekt Deiner Steuerung kurzfristig behoben wird? Oder bei Defekt Deiner Steuerung wird der Notdiesel immer gestartet (Drahtbruchsichere Freigabe...)

Ich denke Du brauchst für wirkliche Redundanz zwei unabhängige Dieselaggregate, die jeweils so groß sind, dass auch eines alleine die notwendige Leistung bereitstellen kann. Dass der Notdiesel im Bedarfsfall nicht anspringt ist vermutlich 1000mal wahrscheinlich als dass Deine CPU grad zufällig defekt ist.

Also man muss sich konkret überlegen, welche Defekte man mit welchen Maßnahmen redundant aufbauen muss/will/kann.

Bei Thema Redundanz "nur" die CPU als H-System aufzubauen ist Quatsch.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Oliver,

es gibt ja verschiedene Ebenen der Redundanz, was in der Regel vom zu steuernden System abhängt, wie lange es ausfallen darf, bzw. wie lange die Recovery-Zeit betragen darf:
Cold Standby: Du hast ein zweites System, das zugeschaltet werden muß und sich auch neu in den Prozeß einbindet - kann auch ein Ersatzteil sein, daß innerhalb einer definierten Zeit auszutauschen sein muß.
Warm Standby: Du hast zwei Systeme, die parallel laufen, aber die Übernahme durch die Standby-CPU nimmt eine Zeit X in Anspruch (z.B. ein paar SPS-Zyklen)
Hot-Standby: Beide Systeme arbeiten parallel, aber nur vom Aktiven werden die Befehle angenommen. Bricht der Master weg, kann ohne Verzögerung vom zweiten System übernommen werden.

Da steckt schon einmal viel "Kosten"-Potential drin. Ich kann das am Beispiel von der Marine sagen. In den Rules der Klassifikationsgesellschaften steht für bestimmte Systeme nur was von Redundanz. Bei Kunden bzw. Herstellern von diesen Systemen wird dann gerne an die Hot-Standby-Redundanz gedacht. Wenn man sich aber dann tiefer mit den Rules beschäftigt, merkt man, daß irgendwo "Recovery-Zeiten" stehen. Die können dann z.B. 30 Minuten betragen. Das reicht, um im Schiffsbetrieb eine bereitliegende Ersatz-CPU einzusetzen. Das heißt, es ist eine Redundanz im eigentlichen Sinne garnicht notwendig, sondern nur eine organisatorische Sache. Damit kann ein System schonmal mehrere 1000€ günstiger werden.

Auch bei Deiner USV lohnt es sich ja, nachzufragen, ob diese für eine Zeit X (Sekunden oder Minuten) ausfallen darf.

Dann kommt dazu, wie viele Fehler gleichzeitig Du betrachtest. In der Regel betrachtet man einen Fehler. Nach Behebung dieses Fehler hat das System Zeit, sich zu erholen. Prüfer machen nämlich gerne aus Unwissenheit gleichzeitig oder zu kurz hintereinander mehrere Fehler und beschweren sich dann, daß das System aus dem Tritt kommt.

Bei der Redundanz ist auch immer das Thema Lizenzen zu betrachten: Häufig doppelte Lizenzen.

Natürlich muß auch betrachtet werden, welche Fehler erwartet man, also wie tief muß man mit der Redundanz gehen.
Geht man die Redundanz nur bis zur CPU, oder bis auf die I/Os. In der Marine ist dann schnell das Bild vom zweiten Schiff, was in Standby nebenherfährt, bemüht. Weil man es eben bis auf die Spitze treiben kann und alles doppelt ausführt.

Wenn Du über das Thema Netzwerkredundanz nachdenkst, mußt Du dabei beachten, daß dann natürlich die redundanten Leitungen auch verschiedene Wege laufen sollten. Z. B. Brand: Wenn eine Ecke brennt, soll das 2. Kabel in der anderen Ecke noch funktionieren. Dabei muß man dann aber auch wieder aufpassen, daß man sich (bei Kupferleitungen) keine große Antenne in Form einer großen Kupferschleife aufbaut. Hier sollte man dann über LWL nachdenken. Das betrifft dann auch die CPUen: Sollte man sie in einen Schrank setzen, deckt man wirklich nur den technischen Ausfall einer CPU ab. Setzt man sie in verschiedene Orte, hat man z.B. im Bandfall ggf. eine Längere Zeit, in der das System läuft.

Insgesamt läßt sich als Fazit sagen: In der Redundanz läßt sich eine Menge Geld versenken, aber mit einmal ruhig hinsetzen, nachdenken und mal mit dem Kunden bzw. dem Regelwerk ins Gebet gehen, läßt sich auch viel Aufwand vermeiden, weil man plötzlich merkt, daß doch nicht alles so heiß gegessen wird, wie es gekocht wurde.

Viele Erfolg und ein schönes Pfingstwochenende!
Jens
 
Ich überlege mir konkret, läuft die Anlage bei Defekt EINES BELIEBIGEN Bauteils unbeeinträchtigt weiter. Das kann z.B. ein defekter Sicherungsautomat oder auch Sensor oder Netzwerkstecker oder Koppelrelais oder auch CPU-Stop sein...
Doppelfehler betrachte ich normalerweise nicht.
Nächste Überlegung, kann jedes beliebige defekte Teil im laufenden Betrieb getauscht werden.
Einen Punkt vermisse ich in dieser Diskussion. Wie stellt ihr in euren Redundanten Systemen zuverlässig fest, dass ein Fehler vorliegt?
 
Ich weiss ja nicht, was Du vorhast, aber in ner hochwichtigen Anlage eine grad rausgekommene redundante Steuerung einzusetzen ist Irrwitz perse.

Für "Redundanz" bzw. "Hochverfügbarkeit" muss man sich in Ruhe überlegen, was man überhaupt will und wie man das umsetzt.
Das geht von der Mechanik über Sensorik/Aktorik über IO über Bussystem über Steuerung über Visualisierung über Netzeinspeisung über Medienversorgung (Druckluft)... u.U. alles zu betrachten.
Ich habe erstmal gar nichts vor, außer mich zu informieren, was man bei dem Thema beachten sollte. Was letzten Endes der Kunde meines Auftraggebers wünscht, muss sich noch klären.
Die Steuerung ist nicht neu, lediglich der Softwareaufsatz für die CPU Redundanz. Redundanzlösungen für andere Dinge gibt es von Beckhoff schon länger. Außerdem hat Beckhoff aus den diversen Fehlschlägem bei der 4022 und 4024 gelernt und führt gründliche Betatedts durch, sowohl intern, als auch mit Kunden.
Bezüglich Deiner Bedenken neue Produkte einzusetzen ist das Problem dabei, dass man manchmal gar keine Wahl hat. Manchmal ist man aber auch die Ursache für die Entwicklung eines neuen Produktes, dann kommt man um den frühen Einsstz gar nicht herum. So war es zum Beispiel bei einem großen Autokranhersteller der die ABB AC500 eingesetzt hat.
Bei einem meiner Auftraggeber hatten wir eine Beta der TE1111 (TC3 EtherCAT Simulation) einsetzen müssen. Die TE1111 gab es zwar schon als Produkt, aber noch ohne Safety Unterstützung, die wir damals brauchten und die wäre erst mit der 4026 herausgekommen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Einen Punkt vermisse ich in dieser Diskussion. Wie stellt ihr in euren Redundanten Systemen zuverlässig fest, dass ein Fehler vorliegt?
Wir sind im Anlagenbau tätig, für Infrastruktur bzw. Medienversorgung allgemein.
Hab ich grad mal drüber nachgedacht, eigentlich krig ich so ziemlich alle Ausfälle mit. Vom Prinzip genauso wie bei nichtredundanten Anlagen.
Bei Aktoren überwache ich die Rückmeldung bzw. Betriebsmeldung, Wenn ich einen Aktor ansteuere und die Rückmeldung kommt nicht, egal warum, Fehlermeldung.
Bei redundanten Sensoren, wenn Abweichung beider Sensoren grösser 10%, egal warum, Fehlermeldung usw...
Bei mechanisch redundanten Anlagenteilen, ein Ablagenteil tut nicht was erwartet wird, egal warum, Fehlermeldung.

Die Analogie mit dem zweiten parallel fahrenden Schiff find ich super!👍
Ich kenne einen Spediteur, der Just in Time für die Automobilindustrie liefern muss. Der hat immer einen Reserve-LKW auf halber Strecke in Standby zu stehen...
Im Anlagenbau wird das oft so gemacht, das bestimmte Anlagenteile doppelt gebaut werden. Nicht nur wegen Defekten sondern auch für Wartung, Umbauten, Reserven für Spitzenlast... Ob man dann zwei separate Steuerungen einsetzt oder eine zentrale H-CPU hängt am Ende davon ab, wieviel Querkommunikation notwendig wäre bzw. umfangreiche übergeordnete Steuerlogik.
 
So ne wirkliche stoßfreie Hochverfügbarkeit ist nicht trivial.
Das stimmt wohl, aber wenn Beckhoff auf der Messe nicht getrickst hat, klappt das ganz gut.
Hochdynamische Regelung, bei der ein Tischtennisball mit Luft in einer Röhre auf einer Höhe gehalten wird. Die Master Steuerung wird ausgeschaltet, der Slave übernimmt und der Ball ist nicht abgesunken.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab ich grad mal drüber nachgedacht, eigentlich krig ich so ziemlich alle Ausfälle mit. Vom Prinzip genauso wie bei nichtredundanten Anlagen.
Bei Aktoren überwache ich die Rückmeldung bzw. Betriebsmeldung, Wenn ich einen Aktor ansteuere und die Rückmeldung kommt nicht, egal warum, Fehlermeldung.
Bei redundanten Sensoren, wenn Abweichung beider Sensoren grösser 10%, egal warum, Fehlermeldung usw...
Bei mechanisch redundanten Anlagenteilen, ein Ablagenteil tut nicht was erwartet wird, egal warum, Fehlermeldung.
OK, in deinen aufgezeigten Beispielen stellst du fest, dass etwas nicht passt.

Wie kannst du bei 2 Redundanten Signalen „wissen“ welches der beiden Signale fehlerhaft ist?
 
OK, in deinen aufgezeigten Beispielen stellst du fest, dass etwas nicht passt.
Ja, und dann muss halt der Instandhalter schaun und reparieren.
Wie kannst du bei 2 Redundanten Signalen „wissen“ welches der beiden Signale fehlerhaft ist?
Wenn ein Signal komplett ausfällt, kannst es ja erkennen. Bei gültigem Signal aber Unterschieden weisst Du es nicht. Für die SPS nutze ich in der Regel den min oder max Wert der zwei Signale, je nachdem was für die Verfügbarkeit besser ist.
Bei großen Abweichungen muss wieder der Instandhalter schaun, u.U. mit einer händischen Referenzmessung.
Wenn zwei Messungen auseinanderdriften passiert das in der Regel schleichend und nicht schlagartig. So dass genug Zeit zum reparieren bleibt...

Wenn Du Angst hast, dass z.B. ein Drucksensor schlagartig 5bar zu viel anzeigt, und das ein Problem für die Verfügbarkeit darstellt, musst Du zur Not 3 Drucksensoren auf 3 verschiedenen ET200 einbauen... machen wir manchmal.

Am Ende, für jedes denkbare Problem eine Lösung ausdenken. Am besten Lösungen, die mehrere bzw. alle denkbaren Probleme eines Anlagenteils abdecken...
 
Zuletzt bearbeitet:
Das stimmt wohl, aber wenn Beckhoff auf der Messe nicht getrickst hat, klappt das ganz gut.
Hochdynamische Regelung, bei der ein Tischtennisball mit Luft in einer Röhre auf einer Höhe gehalten wird. Die Master Steuerung wird ausgeschaltet, der Slave übernimmt und der Ball ist nicht abgesunken.
Natürlich klappt das auf der Messe. In der Praxis scheiterts dann irgendwann an irgendwas woran keiner gedacht hat. Und bis diese Bugs irgenwann raus sind, dauerts ne Weile.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Natürlich klappt das auf der Messe. In der Praxis scheiterts dann irgendwann an irgendwas woran keiner gedacht hat. Und bis diese Bugs irgenwann raus sind, dauerts ne Weile.
Das stimmt wohl, aber manchmal hat man halt keine andere Wahl.
Außerdem wurden von den verschiedenen Herstellern die Systeme auch kaputt aktualisiert.
 
Das stimmt wohl, aber manchmal hat man halt keine andere Wahl.
Außerdem wurden von den verschiedenen Herstellern die Systeme auch kaputt aktualisiert.
Ja natürlich. Drüber nachdenken und entscheiden, was die aktuell richtige Lösung ist.

Bei ner nagelneuen hochverfügbaren Lösung würd ich persönlich die Ausfallwahrscheinlichkeit durch Bugs höher einschätzen als die einer bewährten Einzel-SPS durch Defekt. Aber meine persönliche Meinung.

Und irgendjemand muss ja der erste sein 😂
 
Hallo Oliver,

ich hoffe, ich sprenge mit meinen vielen Rückfragen nicht deinen Thread – aber beim Lesen deiner Anfrage ist mir aufgefallen, dass ich mir ganz ähnliche Gedanken zum Thema mache.

Da hier am Feiertag nicht viel los ist, habe ich kurzerhand mal ChatGPT gefragt, in welchen Bereichen hochverfügbare Steuerungen typischerweise zum Einsatz kommen.

Die generierte Liste sieht wie folgt aus:
  1. Kraftwerke und Energieversorgungsanlagen
  2. Chemie- und Prozessindustrie
  3. Öl- und Gasindustrie
  4. Wasser- und Abwasseranlagen
  5. Verkehrs- und Infrastruktursysteme
  6. Automobilindustrie (selektiv)
  7. Pharmaindustrie
  8. Rechenzentren (Versorgungstechnik)
In vielen dieser Anwendungsfälle wäre es meiner Meinung nach oft sinnvoller (oder wirtschaftlicher), gleich ganze Anlagenteile redundant oder modular-parallel aufzubauen – also z. B. durch strukturelle Redundanz im Anlagenlayout, nicht zwingend auf Steuerungsebene.
Eine hochverfügbare Steuerung erscheint mir nur dann wirklich notwendig, wenn ein technischer Umschaltmechanismus unabdingbar ist – also wenn z. B. ein kontinuierlicher Prozess (wie in der Chemie) nicht unterbrochen werden darf, oder wenn eine Anlage sicherheitskritisch und öffentlich zugänglich ist (z. B. Tunnelsteuerung).
Letztlich ist die Steuerung dabei nur ein kleiner Baustein im Gesamtkonzept zur Verfügbarkeitsabsicherung.

@All:
Was haltet ihr von der obigen Liste – ist die so schlüssig?
Fehlen euch typische Branchen oder Spezialanwendungen?
Oder hat sich in der Praxis inzwischen gezeigt, dass andere Konzepte (z. B. organisatorische Redundanz, modulare Architektur) heute Vorrang haben?

Freue mich auf eure Rückmeldungen!

LG Cassandra
 
Zurück
Oben