Schneider Foxboro SDA bewegt das DCS in Richtung Software

Schneider Electric kündigte am 2. September 2026 auf dem ARC Industry Leadership Forum in Orlando die softwaredefinierte Automatisierung EcoStruxure Foxboro an. Das Unternehmen beschrieb sie als offenes, softwaredefiniertes verteiltes Leitsystem für die Prozess- und Hybridindustrie. Die Ankündigung ist aktuell, doch ihre technische Bedeutung hängt weniger von der Bezeichnung ab als davon, wie Regelungsfunktionen, Hardware, Verfügbarkeit, Cybersicherheit und Zuständigkeiten über den Lebenszyklus umgesetzt werden.

Was Schneider Electric angekündigt hat

Foxboro Software Defined Automation, kurz Foxboro SDA, wird als Weiterentwicklung des Foxboro-DCS-Portfolios positioniert. Schneider zufolge trennt die Architektur die Automatisierungssoftware von dedizierter Hardware, sodass Regelungsfunktionen flexibler bereitgestellt und gewartet werden können. Die Plattform basiert auf EcoStruxure Automation Expert und soll die von einem DCS erwartete Betriebskontinuität aufrechterhalten und zugleich die Abhängigkeit von einer festen Controller-Generation verringern.

In der Ankündigung des Unternehmens wurden Offenheit, integrierte Cybersicherheit, Echtzeitintelligenz und eine schrittweise Modernisierung betont. Schneider brachte die Einführung außerdem mit einer gemeinsam mit Omdia durchgeführten Untersuchung in Verbindung, der zufolge geschlossene Leitsystemarchitekturen durch Ausfallzeiten, Ineffizienz und nachträgliche Anpassungen an Compliance-Anforderungen erhebliche Kosten verursachen können. Solche geschäftlichen Schätzungen müssen standortspezifisch validiert werden, doch das zugrunde liegende technische Problem ist bekannt: Hardwareveraltung, eng gekoppelte Upgrades und proprietäre Schnittstellen können Veränderungen verteuern.

Softwaredefiniert bedeutet nicht hardwareunabhängig

Eine Regelungsanwendung läuft immer auf physischen Rechen-, Netzwerk-, Stromversorgungs-, I/O- und Zeitsteuerungsressourcen. Eine softwaredefinierte Architektur verändert, wie Funktionen gebündelt, zugewiesen und verwaltet werden; sie beseitigt diese Einschränkungen nicht. Ingenieure benötigen weiterhin deterministische Ausführung, ein bekanntes Abtastverhalten, Zeitsynchronisation, Redundanz, Eignung für die Umgebungsbedingungen und Fehlerbegrenzung.

Die entscheidende Designfrage lautet, welche Zuständigkeiten in die Software verlagert werden und welche an ein Gerät gebunden bleiben. Ein virtualisierter übergeordneter Dienst kann häufig andere Wiederherstellungszeiten tolerieren als eine Regelungsaufgabe im geschlossenen Kreis. Eine Sicherheitsfunktion unterliegt anderen Anforderungen an Zertifizierung, Unabhängigkeit und Änderungssteuerung als ein Historian-Konnektor. Anlagen sollten Workloads klassifizieren, bevor sie entscheiden, wo diese ausgeführt werden dürfen.

Für die installierte Basis ist diese Unterscheidung wichtig. Die Foxboro-Kollektion des Standorts umfasst die Hardwarefamilien, die bestehende Anlagen während eines schrittweisen Übergangs möglicherweise weiter unterstützen müssen. Ein Modernisierungsplan muss jedes I/O-Modul, jede Feldbusschnittstelle, jede Controller-Abhängigkeit, jedes Anwendungspaket und jeden Wartungsablauf erfassen, statt automatisch davon auszugehen, dass Softwareportabilität veraltete Einschränkungen beseitigt.

Potenzielle Vorteile für die Modernisierung bestehender Anlagen

Herkömmliche DCS-Upgrades verbinden häufig mehrere Risiken: Controller-Austausch, Wechsel des Betriebssystems, Konvertierung von Anwendungen, Netzwerkmigration, Anpassung der Grafiken und Schulung der Bediener. Die Entkopplung von Funktionen kann kleinere Migrationsschritte ermöglichen, jedoch nur, wenn Schnittstellen und Regeln für den Parallelbetrieb eindeutig festgelegt sind.

Ein belastbarer Plan für bestehende Anlagen sollte ermitteln, welche Assets weiterverwendet werden können, welche Gateways benötigen und welche ersetzt werden müssen. Er sollte Rücksetzpunkte, temporäre Architekturen, Datenverantwortlichkeiten und das getestete Verhalten bei Ausfall eines neuen Softwaredienstes festlegen. Der Vorteil besteht nicht lediglich darin, Hardwarekäufe aufzuschieben. Es geht darum, die Zahl der während jedes Stillstands geänderten Variablen zu reduzieren.

Offenheit braucht messbare Schnittstellen

Eine offene Architektur ist dann aussagekräftig, wenn Ingenieure unterstützte Protokolle, Datenmodelle, APIs, Portabilitätsgrenzen und Konformitätsanforderungen identifizieren können. Eine veröffentlichte Schnittstelle garantiert nicht, dass zwei Anbieter Alarme, Qualitätsstatus, Zeitstempel, Redundanz oder die Zuständigkeit für Konfigurationen auf dieselbe Weise interpretieren.

Beschaffungsteams sollten fragen, welche Schnittstellen nativ sind, welche optionale Komponenten erfordern und welche nur für die Überwachung vorgesehen sind. Außerdem sollten sie klären, ob Anwendungen von Drittanbietern an der Regelung teilnehmen, auf kontextualisierte Daten zugreifen oder nur ausgewählte Werte konsumieren können. Leistungsgrenzen, Aktualisierungsrichtlinien, Lizenzierung und Supportverantwortlichkeiten gehören in die technische Spezifikation.

Die umfassendere Kollektion zu DCS- und Leitsystemen bietet Kontext zu den installierten Plattformen, die Prozessanlagen miteinander vergleichen. Unabhängig von der gewählten Architektur benötigen Bediener stabiles Verhalten bei Controller-Umschaltungen, Netzwerkfehlern, Serverwartung und einem teilweisen Verlust der Infrastruktur.

Cybersicherheit wird Teil des Lebenszyklus

Schneider beschreibt Cybersicherheit als Bestandteil der Foxboro-SDA-Architektur. Der Cybersicherheitsleitfaden und der technische Lösungsleitfaden des Unternehmens vom Juli 2026 bieten einen nützlicheren Ausgangspunkt als allgemeine Aussagen zur Einführung, da sie Planung und Konfiguration behandeln. Die offiziellen Dokumente beziehen sich auf die Systemarchitektur; die Umsetzung am Standort bestimmt weiterhin das endgültige Sicherheitsniveau.

Bei softwaredefinierten Systemen gewinnen Identität, Zertifikatsverwaltung, signierte Software, Rollentrennung, Patch-Qualifizierung, Protokollierung, Sicherung und Wiederherstellung an Bedeutung. Außerdem können sie häufigere Softwareänderungen mit sich bringen als ein herkömmlicher Controller-Lebenszyklus. Anlagen benötigen ein kontrolliertes Verfahren, um Aktualisierungen vor der Bereitstellung in der Produktion gegen Regelungsanwendungen, Treiber, Grafiken, Zeitdienste und Redundanz zu testen.

Eine Netzwerksegmentierung bleibt erforderlich. Verwaltungsverkehr, Engineering-Zugriff, Regelungskommunikation und der Datenaustausch mit dem Unternehmensnetz sollten definierte Pfade und Berechtigungen besitzen. Fernadministration darf nicht zu einer undokumentierten Umgehung des OT-Zugriffsprozesses am Standort werden. Die Sicherheitsüberwachung sollte erwartete Orchestrierungsaktivitäten von nicht autorisierten Konfigurationsänderungen unterscheiden können.

Verfügbarkeit muss auf Funktionsebene nachgewiesen werden

Eine Verfügbarkeitsaussage zu einem DCS sollte in Fehlerszenarien aufgeschlüsselt werden. Was geschieht, wenn ein Rechenknoten ausfällt, ein Netzwerkpfad unterbrochen wird, ein Orchestrierungsdienst nicht verfügbar ist oder eine Softwarebereitstellung unvollständig bleibt? Welche Regelkreise laufen weiter, welche Bedieneransichten werden beeinträchtigt und wie lange dauert die Wiederherstellung?

Ingenieure sollten Nachweise für Umschaltzeit, Zustandsynchronisation, stoßfreie Übergabe, Alarmkontinuität, Pufferung von Historian-Daten und Wiederherstellung nach gleichzeitig auftretenden Fehlern verlangen. Eine Sicherung ist nicht dasselbe wie Hochverfügbarkeit, und Redundanz ist nicht hilfreich, wenn Fehler gemeinsamer Ursache nicht berücksichtigt wurden. Die Werksabnahme sollte auch degradierte Betriebsarten und nicht nur den Normalbetrieb umfassen.

Wie Anlagen Foxboro SDA bewerten können

Ein klar abgegrenztes Pilotprojekt definieren

Wählen Sie eine nicht kritische Einheit oder ein repräsentatives Testsystem mit realen I/Os, Alarmen, Sequenzen, Kommunikationsverbindungen und Bedienergrafiken aus. Dokumentieren Sie die aktuelle Leistung, damit die neue Architektur mit einer Ausgangsbasis verglichen werden kann.

Jede Abhängigkeit erfassen

Erfassen Sie Controller, I/O, Server, Switches, Zeitquellen, Domänendienste, Lizenzen, Engineering-Tools und Pakete von Drittanbietern. Ermitteln Sie, wer für jede Abhängigkeit zuständig ist und wie sie wiederhergestellt wird.

Änderungen und Wiederherstellung testen

Spielen Sie ein Softwareupdate ein, setzen Sie es zurück, ersetzen Sie einen ausgefallenen Knoten, unterbrechen Sie Netzwerkpfade und stellen Sie eine Sicherung wieder her. Bestätigen Sie, dass die Verfahren mit den am Standort verfügbaren Kenntnissen und Werkzeugen funktionieren.

Aussagen von Abnahmekriterien trennen

Übersetzen Sie Offenheit, Flexibilität und Cybersicherheit in messbare Anforderungen. Beispiele sind unterstützte Protokollversionen, maximale Wiederherstellungszeit, validierte Betriebssysteme, Aufbewahrungsdauer von Protokollen, Rollenberechtigungen und Grenzwerte für die Controller-Ausführung.

Technische Perspektive

Foxboro SDA ist ein ernsthafter Versuch, die Bereitstellung und Erneuerung von DCS-Funktionen zu verändern. Die offizielle Einführungsankündigung vom 2. September von Schneider Electric beschreibt die Produktrichtung, während der technische Lösungsleitfaden zu Foxboro SDA Umsetzungskontext bietet.

Die Chance liegt in größerer Flexibilität bei der Modernisierung. Das Risiko besteht darin, Abstraktion als Beweis dafür zu betrachten, dass Probleme bei Zeitverhalten, Sicherheit, Verfügbarkeit und Support verschwunden sind. Anlagen, die Workload-Klassifizierung, schrittweise Migration, eindeutige Schnittstellen und fehlerbasierte Abnahmetests einsetzen, sind besser in der Lage zu beurteilen, an welchen Stellen die Architektur einen Mehrwert bietet.