Redundante SPS - Ja oder Nein?
Artikel#: 00115
Datum: 2026-02-01
Autor: Radim
In der industriellen Automatisierung gibt es viele Möglichkeiten, die Maschinenverfügbarkeit zu verbessern.
Eine Idee, die dabei recht häufig auftaucht, ist der Einsatz einer redundanten SPS.
Auf den ersten Blick scheint die Überlegung einfach: Wenn ein Ausfall der SPS die Maschine stoppen kann, sollte der Einsatz von zwei SPSen in einer redundanten Konfiguration das Risiko von Stillständen reduzieren.
Wie bei vielen technischen Entscheidungen ist jedoch nicht die Frage entscheidend, ob diese Lösung funktioniert, sondern ob sie die tatsächlichen Ursachen von Produktionsstillständen adressiert.
Aus praktischer Erfahrung heraus stoppen Maschinen in der Regel nicht aufgrund von Ausfällen der SPS-Hardware
(softwarebedingte Probleme sind ein anderes Thema und häufig eine bedeutende Ursache für Stillstände, werden jedoch durch SPS-Hardware-Redundanz nicht gelöst).
Maschinen stoppen, weil ein Sensor verschmutzt, verstellt oder beschädigt ist.
Ein Ventil schaltet nicht.
Ein Antrieb meldet eine Störung.
Ein Netzteil fällt aus.
Ein Kabel oder Steckverbinder verursacht einen Wackelkontakt.
Oder ein mechanisches Bauteil ist verschlissen oder defekt.
Und manchmal ist die Ursache schlicht eine falsche Bedienung oder Wartung.
Verglichen mit all diesen Ursachen gehört die SPS-CPU in der Regel zu den zuverlässigsten Teilen der gesamten Maschine.
Wird ausschliesslich die SPS redundant ausgeführt, wird damit nur ein sehr spezifischer Fehlerfall abgedeckt: der Ausfall der SPS-Hardware selbst.
Gleichzeitig erhöht Redundanz jedoch immer die Komplexität.
Es gibt mehr Hardware, mehr Software, mehr Konfiguration und mehr Dinge, die getestet, in Betrieb genommen, diagnostiziert und gewartet werden müssen.
Das bedeutet auch höhere Kosten - nicht nur in der Projektphase, sondern über die gesamte Lebensdauer der Maschine hinweg.
Ein komplexeres System bedeutet auch mehr Möglichkeiten, wie etwas schiefgehen kann, und mehr Situationen, die schwer zu verstehen und zu beheben sind.
Das bedeutet nicht, dass Redundanz grundsätzlich falsch oder nutzlos ist.
Es gibt Anwendungen, in denen Redundanz nicht nur sinnvoll, sondern zwingend erforderlich ist.
Typische Beispiele sind kontinuierliche oder teilkontinuierliche Prozesse, 24/7-Betriebe oder Anlagen, bei denen ein Wiederanlauf viele Stunden dauert und eine Stunde Stillstand sehr hohe Verluste verursacht.
In solchen Fällen geht es bei Redundanz jedoch nie nur um zwei SPSen in einer redundanten Konfiguration.
Die gesamte Systemarchitektur wird von Anfang an auf Verfügbarkeit ausgelegt: Stromversorgungen, Netzwerke, I/O-Systeme, Steuerungen und häufig auch Feldgeräte (z.B. Sensoren, Aktoren, dezentrale I/O-Module und Ventilinseln).
Wenn wir uns fragen, was unsere Maschine tatsächlich stoppt und was zu langen Stillstandszeiten führt, lautet die Antwort nur selten "Ausfall der SPS-Hardware".
Sehr oft liegen die Ursachen vielmehr in schlecht entworfener und unzureichend getesteter Steuerungssoftware, unklarer Diagnose, fehlenden oder verwirrenden Meldungen auf dem HMI, schlechter oder veralteter Dokumentation, schwierigem Zugang zu Maschinenkomponenten für Inspektion oder Austausch sowie kritischen Abhängigkeiten von anderen oder übergeordneten Systemen.
Eine Maschine ist immer nur so zuverlässig wie ihr schwächstes Glied.
Und die Maschinenverfügbarkeit ist stets das Ergebnis des gesamten Systementwurfs: Mechanik, Elektrik, Pneumatik, geeignete Architekturen und Modularisierung, Softwarequalität, Dokumentation, verfügbares Know-how, Diagnosekonzepte, Servicekonzept, Wartung und Ersatzteilstrategie.
© Radim-Automation, 2020–2026. Alle Rechte vorbehalten.
Die Verbreitung dieses Artikels ist mit Angabe der Quelle (Link zur Originalseite) ausdrücklich gestattet.
Verwandte vorherige Artikel:
- Wie lange wird eine Störung unsere Produktion stilllegen?
- Resilient Machine Control Design
- Wann ein Touchpanel nicht ausreicht
- Was macht eine HMI intuitiv?
- High Performance HMI
- Halte alles, was du brauchst, zusammen
- Traum von einem plattformunabhängigen SPS-Programm
- Mache Backups, nehme kleine Änderungen vor und teste viel
- Pflege Ordnung im Programmkode
- Halte die Dokumentation während des gesamten Projekts auf dem neuesten Stand
- SPS-Netzwerkdiagramm
- Versionskontrollsystem
- Diagnosetools
- Ereignislogger als allererste im Programm implementierte Funktion
- Ohne Sensoren geht es nicht
- Klare Signale
- Designüberlegungen für effektive HMIS
- Software-Update
- Sicherheitsrelais versus Sicherheits-SPS
- Dokumentationsprobleme
- Erkenntnisse aus einem abgeschlossenen Projekt sind unbezahlbar
- Maschinenmodularisierung
- Modulare Softwarearchitektur
- Hardwarekonzept
- Ein gutes Konzept = Kompletter Satz geeigneter Lösungen
- Gibt es auch Nachteile?
- Denke kritisch!
- Entwerft Maschinen mit Fokus auf die Fähigkeiten und Bedürfnisse des Benutzers
- Warum scheitern Automatisierungsprojekte?
- Sammelt alle Anforderungen und sortiert sie!
- Wer wird operieren?
- Funktionelles und intuitives HMI
- HMI- und SPS-Anwendungen sollen zusammenwachsen
- Mehr als nur starten und stoppen
- Sicherheit zuerst!
- Mach die richtigen Dinge und mach sie richtig!
- Definiere kontinuierlich Testszenarien und Testfälle!
- Mach es nicht schlimmer!
- Behaltet die Antworten auf die Frage "Warum"
- Führt die Terminologie ein und vereinheitlicht sie!
- Industrielle Evolution - Höre eurem Kunden zu und folge neuen Trends!
- Hab einen Experten zur Hand!
- Was braucht der Kunde?
- Enttäuscht euren Kunden nicht!
- Konzentriere dich auf das Ziel!
- Verstecke kein Problem!
- Überprüfe das Ergebnis!
- Halte es einfach!
- Verlass kein Arbeitspaket halbfertig!
- Erfolg ist kein Zufall
- Entwicklung ist Evolution
- Transparenz und Zuverlässigkeit
- Von einer Idee zu einem konsistenten System
Verwandte nächste Artikel:
- Taster: Start, Stop und ein zusätzlicher
- Unterschiedliche Arten des Maschinenstopps
- Sicherheitsstopps müssen höchste Priorität haben