TIA Redundante CPUs S7-1500R

Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, das Thema ist noch Neuland. Aber deshalb frag ich ja hier. Es gibt z.B. aber bestehende Anlagenteile, wo nicht einfach bautechnisch ein 2. Sensor angebaut werden kann. Da kommt man nicht an einer Signalvervielfälltigung vorbei
Man muss eines ganz klar sagen. Wenn man nicht viel Ahnung hat und eine laufende Anlage nun mit einem 1515R System ausrüstet und dann eben auch viele Besonderheiten im Umgang damit beachten muss, dann ist die Wahrscheinlichkeit nicht so gering dass ihr da in Zukunft mehr Ausfälle habt als mit einer Standard CPU.
 
Und geeignete Reaktionen programmieren. Was soll geschehen wenn.......
Das Programmieren ist am Ende eher einfach, wenn das Gesamtkonzept schlüssig ist.

Bsp.: Wenn Du digitale Sensoren als Sicherheitsabschaltung nur als Öffner doppelt auf die SPS legst, weisst Du nicht, welcher von beiden jetzt die Wahrheit sagt, also solche Schalter sind Käse, da braucht man dann entweder 3 oder Teile die noch ein Diagnosesignal liefern.

Weiterhin brauchst für alle möglichen Komponenten eigene selektive Sicherungen, sonst wird die EINE Sicherung der Flaschenhals.

Wir bauen öffters Anlagen, wo ein beliebiges Bauteil ausfallen darf,, ohne die Funktionalität zu beeinflussen. Das ist aber die hohe Schule, falls man was sinnvolles tun will...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, das Thema ist noch Neuland.
dann holt Euch jemanden, der damit Erfahrung hat, sonst bringt das ganze nur Ärger und keinen Mehrwert.
Aber deshalb frag ich ja hier.
Das reicht garantiert nicht...
Es gibt z.B. aber bestehende Anlagenteile, wo nicht einfach bautechnisch ein 2. Sensor angebaut werden kann. Da kommt man nicht an einer Signalvervielfälltigung vorbei
Signalvervielfältigung bringt nicht wirklich etwas... klar ist dann die DI-Karte redundant, aber das zusätzliche Koppelrelais nicht. Das Koppelrelais fällt vermutlich eher aus als die DI-Karte.
Wenn der 2. Sensor oder auch redundante Anlagenteil nicht möglich ist, dann weise den Kunden darauf hin, dass es an dieser Stelle nicht redundant ist...
 
ich gebe euch vollkommen recht, dass es Blödsinn ist, ein kritisches Sensorsignal zu doppeln. Aber wenn genau das ein Kundenwunsch ist, muss ich das so umsetzen. Die Redundanz gilt dementsprechend für die CPU, die ET200SP und die DI-Karte. Halt nicht für den Sensor.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Problem ist halt auch einfach, dass du den Kunden vor allem auch deshalb darauf hinweisen musst, weil sonst im Zweifel alles Redundant aufgebaut ist und dann steigt genau der eine nicht redundante 3,50€ Sensor aus und dann will euch der Kunde den Ausfall als Regress anrechnen. Dann lieber vorher für saubere Verhältnisse sorgen und auch dem Kunden realistisch umsetzbare Lösungen anbieten.
 
ich gebe euch vollkommen recht, dass es Blödsinn ist, ein kritisches Sensorsignal zu doppeln. Aber wenn genau das ein Kundenwunsch ist, muss ich das so umsetzen. Die Redundanz gilt dementsprechend für die CPU, die ET200SP und die DI-Karte. Halt nicht für den Sensor.
Da krigst Du halt dann in der Software nen Problem, weil Du das verdoppelte Sensorsignal plausibilisieren musst...

Wenn die eine DI-Karte jetzt für den Sensor true zeigt und die andere DI-Karte für den Sensor false, was machst Du dann???

Ich generiere in so einem Fall erstmal eine Plasibilitätsfehlermeldung, ob ich dann für die Software true oder false weiterverarbeite hängt dann halt vom Einzelfall ab. Bei digitalen Signalen krigst da im ersten Ansatz, keine andere Info.

Irgendwann bist dann halt mit entsprechendem Aufwand bei diagnosefähigen DI-Signalen.

Keine Ahnung, wann ich zum letzten Mal 1:1 ne Kundenidee umgesetzt habe? Noch nie vermutlich. Der Kunde ist doch nicht der Automatisierungsspezialist.
 
Wenn ein Kunde so ein System verlangt. Erstelle ich üblicherweise ein Konzept seines Systems und meiner Empfehlung. Die Konzepte kann man dann gegenüberstellen und verschiedene Ausfallsszenarien durchspielen. Und dann auch mit Preisschildern versehen um zusätzliche Ausfälle abzufangen oder zu ignorieren.

Das fängt einerseits schon damit an welche CPU Redundanz man wünscht. Softwareredundanz, R CPU, H CPU
Damit sind verschiedene CPU Ausfälle abgedeckt.
Dann überlegt man sich ob man ein Einfaches Remotesystem mit Redundanzfunktionen einsetzt, z.B. eine ET200sp HA. Da kann man dann wiederum die Anschaltung verdoppeln, die Elektronikmodule verdoppeln und auch Sensoren verdoppeln oder verdreifachen (für Plausibilisierung)
Man kann die geplanten Ausfälle bis ins Unendliche treiben und abdecken, es wird halt sehr schnell sehr teuer.

Auch die Art der IO Plausiblisierung lässt sich auf diverse Arten lösen. z.B. mit einer entsprechenden Anzahl Sensoren. Aber auch Logisch über Plausiblitätsberechnung aus dem Anlagenzustand heraus (Das Wasser kann nicht Kochen wenn keine Energie zugeführt wurde!).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ein Kunde so ein System verlangt. Erstelle ich üblicherweise ein Konzept seines Systems und meiner Empfehlung. Die Konzepte kann man dann gegenüberstellen und verschiedene Ausfallsszenarien durchspielen. Und dann auch mit Preisschildern versehen um zusätzliche Ausfälle abzufangen oder zu ignorieren.
Das kann man aber nur, wenn man entsprechende Erfahrung hat. Wenn man sowas noch nie gebaut hat, kann man auch nix sinnvolles vorschlagen.
Ich hab da zum Thema Redundanz auch schon diverse Jugend forscht Projekte gesehn... Am Ende macht das dann mehr Ärger und mehr Ausfälle, als wenn man es ordentlich ohne Redundanz gebaut hätte...
 
Redundanz und Hochverfügbarkeit macht bei kritischer Infrastruktur und Sicherheitsrelevanten Anlagen durchaus Sinn.
Kraftwerke usw...

Für normale Produktionsanlagen unter normalen Umgebungsbedingungen ist das nicht unbedingt der richtige Weg.
Aus Erfahrung:
- meist gibt es nach Jahren Probleme mit der Mechanik (Anruf vom Kunden, die Software geht nicht mehr...!)
- Was geht denn an Elektrik kaputt: hauptsächlich Sensoren, Frequenzumrichter, mal ein Schütz oder ein Relais.
- Displays!
- Ab und zu mal eine Ausgangskarte (speziell, wenn die Schütze dahinter nicht korrekt entstört sind oder die Schutzdioden bei Ventilen fehlen)in den seltensten Fällen die SPS. Meist liegt liegt das Problem eher bei Bugs in der eigenen Software

Und das alles nicht jede Woche, eher im Abstand von Jahren.

Die üblichen Probleme bei Anlagen bekommt man mit redundanter SPS nicht raus!
Man schafft sich eher noch mehr Probleme und einen erhöhten Schulungs- und Wartungsaufwand

Also: um welche Art von Anlage handelt es sich und wer kam auf die Idee, dass das redundant sein muss?

Signale verdoppeln und das auch noch mit Relais schafft erst die Probleme, die eigentlich mit Redundanz beseitigt werden sollen!
Das wird nicht nur eine Null-Nummer, das wird eine Minus-Nummer!
 
Die üblichen Probleme bei Anlagen bekommt man mit redundanter SPS nicht raus!
Man schafft sich eher noch mehr Probleme und einen erhöhten Schulungs- und Wartungsaufwand
Sehe ich auch so

Signale verdoppeln und das auch noch mit Relais schafft erst die Probleme, die eigentlich mit Redundanz beseitigt werden sollen!
Das wird nicht nur eine Null-Nummer, das wird eine Minus-Nummer!
100%
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gibt viele Gründe um irgendwas redundant zu bauen. Bei uns geht es nicht hauptsächlich um Defekte sondern eher darum bestimmte Teile auch mal für Umbaumaßnahmen abschalten zu können, ohne die Versorgung zu beeinträchtigen... usw.

Bsp. IOs sind redundant auf 2 Anschaltungen verteilt. Jetzt muss jeweils ne IO-Karte nachgerüstet werden. Da wird erst eine Anschaltung nachgerüstet dann die andere. Anlage läuft jeweils weiter.
HW-Konfig Änderung dann mit CiR bzw. H-CiR...
Oder es gibt noch die Möglichkeit mit Hardwarehandschaltungen nen kurzen CPU-Stop zu überbrücken... oder bestimmte Ausgänge bleiben durch Selbsthaltung bei CPU-Stop im letzten Zustand... im Zweifel sieht die konkrete Umsetzung bei jedem Sensor/Aktor etwas anders aus...
Pauschalaussagen, "ich verdopple mit nem Relais die DIs" bringen garnichts...
 
Zuletzt bearbeitet:
Verwirrend wird es manchmal, wenn ein Kunde von einem Marketingler bereits bearbeitet wurde. Ich hatte erst einen Kunden der sagte mir dass er eine F-CPU haben möchte damit seine Anlage sicherer wird. Sein Plan war einfach die Standard-CPU gegen eine F zu tauschen und fertig.... sonst nichts 🤔

Manchmal kann man es nicht glauben wenn man es nicht selbst gehört hat.
 
Redundanz und Hochverfügbarkeit macht bei kritischer Infrastruktur und Sicherheitsrelevanten Anlagen durchaus Sinn.
Kraftwerke usw...
Wir haben verschiedene Konzepte;
1 CPU 400 oder 1500 mit Einfach io. (Typisch für Retrofit)
1 CPU 400er mit Dreifach Anbindung Profibus und io (2v3)
1 CPU (1500er) mit Profinet Ring Anbindung io (2v3)
H-CPU Redundant (die 410H) mit Profibus Redundaz oder Profinet Ring Redundanz
Und noch ein paar exoten.
Die 24DCV versorgung auch Redundant in alle Fälle.

Ein einfaches Signal kann ein Flaschenhals werden.
Das kann schon ein 1 Kanalige Auslösung des Generatorschutz sein

Sonnst bei 1v2 und 2v3 ist es wichtig die Störung mit aus zu werten.
 
Für Interessierte:
Siemens Webseite: Neue Firmwareversion V3.1 für SIMATIC S7-1500 R/H CPUs
Siemens FAQ: Wie nutzen Sie den OPC UA-Server in einem S7-1500R/H-System
Mit Firmwareversion V3.1 wurde für die redundanten Steuerungen SIMATIC S7-1500R/H die Funktion OPC UA Server ergänzt. In den meisten Fällen verhält sich der Server wie bei den nicht redundanten Steuerungen. Es gibt jedoch auch einige Besonderheiten zu beachten, damit Auswirkungen der OPC UA Kommunikation auf Zyklus- und Reaktionszeiten reduziert bleiben.

Neue Funktionen mit Firmware V3.1 für S7-1500R/H CPUs:
  • Unterstützung OPC UA Server
    Ab Firmware-Version V3.1 unterstützt das redundante System S7-1500R/H den Datenaustausch als OPC UA Server gemäß dem Redundanzkonzept der OPC UA Spezifikation.
  • Unterstützung zentrale CP-Baugruppen und Systemstromversorgungen
  • Zur Erweiterung der Ethernet-Kommunikationsschnittstellen kann der Kommunikationsprozessoren CP 1543-1 jetzt auch im redundanten System S7-1500R/H eingesetzt werden. Durch den redundanten Aufbau der CPs (je R/H CPU) erhöht sich die Verfügbarkeit des redundanten Systems bei den Kommunikationsaufgaben.
    Der Einsatz des aktiven Rückwandbusses ermöglicht das rückwirkungsfreie Ziehen und Stecken des CP 1543-1 im Systemzustand RUN-Redundant.
    Ergänzt wird auch die Möglichkeit, Systemstromversorgungen (PS) im redundanten System S7-1500R/H einzusetzen.
  • Unterstützung IE/PB LINK HA
  • Das IE/PB LINK HA verbindet als Netzübergang PROFINET IO und PROFIBUS DP. Dadurch ermöglicht das IE/PB-LINK HA den Zugriff auf alle am unterlagerten PROFIBUS-Netz angeschlossenen DP-Devices. Beim redundanten System S7-1500R/H wird das IE/PB-LINK HA als S2-Device in den PROFINET-Ring integriert und ermöglich so die stoßfreie Anbindung der PROFIBUS Teilnehmer im Umschaltfall.
  • Zugriff über Web API
  • Ab Firmware-Version-Version V3.1 unterstützt das redundante System S7-1500R/H die Webserver API. Die CPU bietet Ihnen eine webbasierte API (Web API) als Schnittstelle für das Lesen und Schreiben von CPU-Daten. Eine Übersicht, welche Mechanismen und Methoden die R/H-CPUs unterstützen finden Sie im Funktionshandbuch Webserver.
  • Erweiterung der OB83 Ereignisse
  • Mit dem OB 83 (Ziehen/Stecken-OB) werden zusätzlichen Ereignissen beim redundanten System S7-1500R/H gemeldet
  • Data Logging
    Das redundante System S7-1500R/H unterstützt mit der neuen Firmware Version die Funktion Data Logging. Mit der Datenprotokollierung (Data Logging) speichern Sie Prozesswerte vom Anwenderprogramm in eine Datei, die Datenprotokolldatei (Data Log). Die Data Logs werden auf der SIMATIC Memory Card im CSV-Format gespeichert und im Verzeichnis "DataLogs" abgelegt.
  • User Files
    Zur Bearbeitung von Anwenderdateien werden im S7-1500R/H System folgende Anweisungen unterstützt:
  • FileReadC / FileWriteC / FileDelete
  • Erweiterungen RH_CTRL-Anweisung
    Die RH_CTRL-Anweisung wurde um zwei weitere Modes zur Steuerung des Betriebszustands und SYNCUP erweitert.
  • Unterstützung Long Term Trace
    Die Funktion „Long Term Trace” zum langfristigen Aufzeichnen von Signalverläufen steht nun auch bei den redundanten Controllern S7-1500R/H zur Verfügung.
  • Secure Open User Communication
  • Open User Communication (OUC) kann jetzt beim S7-1500R/H System auch in gesicherter Form (Secure OUC) erfolgen.
 
Zuletzt bearbeitet:
Für Interessierte:
  • Unterstützung zentrale CP-Baugruppen und Systemstromversorgungen
Sehr cool.
Das IE/PB LINK HA verbindet als Netzübergang PROFINET IO und PROFIBUS DP. Dadurch ermöglicht das IE/PB-LINK HA den Zugriff auf alle am unterlagerten PROFIBUS-Netz angeschlossenen DP-Devices. Beim redundanten System S7-1500R/H wird das IE/PB-LINK HA als S2-Device in den PROFINET-Ring integriert und ermöglich so die stoßfreie Anbindung der PROFIBUS Teilnehmer im Umschaltfall.
Und sogar Webserver ist möglich.
IMHO ein gewaltiger Schritt in die richtige Richtung.
Auf den Webserver im H System warte ich schon seit der 400er.
 
Ich binn mal gespannt was mir die 1500H Kommunikationstechnisch gibt.. Einfache S7 SPS Kommunikation ist schon ein Ding /kein ding..

Für die Modbus TCP/IP Kommunikation mit das übergeordnete Leitsystem (Einfach) traue ich die Siemens redconnect Bausteine auch nicht.
Wir setzen jetzt auf eine PtP Karte in ein ET200MP, die S2 am 1500H hängt. Und dann ein RTU TCP/IP Wandler. (Musst du nicht konfigurieren)
Die Art von Verbindung haben wir schon in Betrieb gesetzt.
Das muss später ohne viel Aufwand funktionieren. Die Anlage steht später in der Hölle. (Wüste Algeriens)
 
Zurück
Oben