Platform Engineering in der Industrie.
Self-Service bis runter zur SPS.
Platform Engineering lässt sich auf die Industrie übertragen — aber ehrlich betrachtet ist die OT noch nicht so weit wie die IT. Das Konzept der Internal Developer Platform mit Self-Service und Golden Paths passt auch auf die SPS-/PLC-Entwicklung. Nur fehlt ein herstellerübergreifendes Backstage-Äquivalent. Was real funktioniert: Git-Versionskontrolle für SPS-Code, simulationsgestützte CI und zentrales Lifecycle-Management. Die Hersteller-App-Stores sind dagegen meist Edge-Marktplätze, die den Lock-in verstärken.
DevOps vs. Platform Engineering — und wo die Industrie steht
Platform Engineering ist keine Ablösung von DevOps, sondern die organisatorische Antwort auf dessen Schattenseite: Wenn jedes Team seine Infrastruktur selbst bauen und betreiben muss, wächst die kognitive Last. Ein Plattform-Team fängt das mit einer Self-Service-Plattform ab. In der Industrie kommt die eigentliche Frage hinzu — wie weit trägt dieses Modell, wenn am Ende der Pipeline keine Cloud, sondern eine Steuerung in einer laufenden Anlage steht?
Was geht in der SPS-/PLC-Entwicklung heute?
Die unbequeme Wahrheit zuerst: Die OT hat noch kein Backstage. Es gibt kein etabliertes, herstellerübergreifendes Entwicklerportal, das Golden Paths für SPS-Projekte bereitstellt. Was real existiert, sind einzelne, sehr wirksame Bausteine — Git-Versionskontrolle für SPS-Code (über das Version Control Interface bzw. die Openness-API), simulationsgestützte CI mit der PLCSIM-Advanced-API oder der CODESYS-Simulation, und zentrales Lifecycle-Management über viele Controller hinweg.
Self-Service für Automatisierungs-Ingenieure — on-demand-Simulation, standardisierte Pipeline-Templates, geprüfte Bausteinbibliotheken — ist technisch machbar, wird heute aber meist projektindividuell zusammengebaut statt als fertiges Plattformprodukt geliefert. Genau hier liegt die Chance: aus den Bausteinen eine Plattform machen.
Wer baut Plattformen für die OT?
Belastbare End-to-End-Referenzen für eine Internal Developer Platform in der OT sind selten — und das beste Vorbild ist kein Industrieanbieter, sondern eine Forschungseinrichtung. Vier Beispiele, die zusammen ein ehrliches Bild ergeben:
CERN · UNICOS-Framework
Die am besten dokumentierte interne Plattform für OT-Test und CI: CERN generiert SPS-Code automatisch und testet ihn in einer Pipeline. Der Clou — Tests greifen über OPC UA auf SPS-Variablen zu, ohne das Programm zu verändern, ein Python-Wrapper erlaubt Unit-Tests, und die Simulatoren sind plattformunabhängig (Siemens, Schneider, CODESYS).
Quelle: cern.chSoftware Defined Automation
Herstellerunabhängige Industrial-DevOps-Plattform mit Browser-IDE, Backup-as-a-Service und Versionskontrolle über 12+ SPS-Vendoren. Genannte Anwender: Henkel, SEW-EURODRIVE, Fugro, Cytiva. Die plakativen Effizienzgewinne sind Anbieterangaben ohne unabhängigen Beleg — als Schätzung lesen.
Quelle: softwaredefinedautomation.ioVW CARIAD · das Lehrstück
Die Software-Plattform-Einheit des VW-Konzerns scheiterte nicht an der Technik, sondern an der Organisation: ein Plattform-Team ohne eigenes Budget und ohne Mandat, von den Marken als Dienstleister gesehen. Genau der Platform-as-a-Product-Konflikt — und eine Warnung, die sich 1:1 auf OT-Plattformteams übertragen lässt.
Quelle: germanautopreneur.comBosch „Digital Factory" · ehrliche Abgrenzung
Bosch baute mit einer Low-Code-Plattform über 500 Apps in vier Jahren und beseitigte Schatten-IT. Wichtig zur Einordnung: Das ist eine Fabrik-IT-App-Plattform, nicht Platform Engineering für die SPS-/OT-Steuerungsebene. Ein belegbares „OT-Backstage" gibt es bei keinem Hersteller.
Quelle: outsystems.comSechs Praktiken, die sich bewähren
Plattform als Produkt — mit Mandat
CARIAD zeigt das Gegenteil: Ein Plattform-Team braucht Budget, klare Product-Ownership und ein echtes Mandat. Sonst entsteht Patchwork statt Plattform. Automatisierungsteams sind die „Kunden", das Plattform-Team liefert Pipelines, Backup und Simulation als Service.
Golden Paths für SPS-Projekte
Geprüfte, versionierte Funktionsbaustein-Bibliotheken (PLCopen-konform), standardisierte Projekt-Templates nach IEC 61131-3 und fertige Pipelines (Compile → Simulation → Test → Download). Der kuratierte Pfad ist schneller und sicherer als jedes Projekt von Grund auf.
Self-Service-Test statt Prüfstand-Engpass
Simulation als on-demand-Stufe: Die PLCSIM-Advanced-API und die CODESYS-Simulation ersetzen den physischen Prüfstand pro Ingenieur. Tests laufen automatisiert in der Pipeline — Hardware-in-the-Loop nur für Timing- und Vendor-Spezifika.
Team Topologies in der OT
Plattform-Team, Stream-aligned (Linien/Werke) und vor allem ein Enabling-Team, das die Brücke zwischen klassischen Automatisierern und Platform Engineers schlägt. Genau dieses Enabling-Team adressiert den Skill-Gap, an dem sonst alles hängt.
Über Werke und Linien standardisieren
Zentrale Versionierung (Muster: CODESYS Automation Server), wiederverwendbare Bausteine und einheitliche Pipeline-Definitionen. Der Nutzen einer Plattform skaliert erst, wenn mehrere Standorte denselben Golden Path nutzen.
Auf eine herstellerneutrale API-Schicht zielen
Statt proprietärer Insellösung auf OPC UA und die Asset Administration Shell setzen. Diese Standards sind der aussichtsreichste Weg zur fehlenden, vendorübergreifenden Daten- und API-Schicht — die Voraussetzung für eine echte OT-Plattform.
Wo es in der Praxis hakt
Heterogene, proprietäre Vendor-Welt
Siemens, Rockwell, Beckhoff, CODESYS — kein gemeinsames Backstage-Äquivalent, und selbst IEC 61131-3 garantiert keine Portabilität zwischen Herstellern. Die Hersteller-App-Stores verstärken den Lock-in eher, als ihn aufzulösen.
Hardware lässt sich nicht „provisionieren"
Eine SPS ist keine Cloud-VM, die man per Knopfdruck bereitstellt. Virtuelle SPS (CODESYS Virtual Control, PLCSIM) mildern das, sind aber nicht für jede Safety-, Motion- oder Hart-Echtzeit-Anwendung produktionsreif.
Safety und Echtzeit setzen Grenzen
Funktionale Sicherheit und harte Echtzeit lassen sich nicht beliebig in Container oder Cloud verschieben. Self-Service endet dort, wo Determinismus und Zertifizierung beginnen.
Brownfield und lange Lebenszyklen
Maschinen laufen 20 bis 30 Jahre, mit gemischten Firmware- und Tool-Generationen. Eine Plattform, die nur Greenfield bedient, scheitert an der Realität der Werkshalle.
Skill-Gap und Kultur
Steuerungslogik und Domänenwissen treffen auf Git, CI/CD und Container — zwei verschiedene Welten. Ohne Enabling-Teams und echten Kulturwandel bleibt die beste Plattform ungenutzt.
Governance, IEC 62443 und ROI
Browser-IDE und Remote-Deployment müssen ins Zonen- und Conduit-Modell der IEC 62443 passen. Und der ROI einer eigenen Plattform ist schwer zu belegen — Vendor-Zahlen taugen nicht als Geschäftsgrundlage.
Welche Standards eine OT-Plattform tragen
Eine herstellerübergreifende Plattform braucht eine herstellerneutrale Schicht. Genau die fehlt der OT heute — aber drei Standards und eine Initiative arbeiten daran.
Die international standardisierte, herstellerneutrale digitale Asset-Beschreibung mit einer eigenen REST-API (Teil 2) und Registry. Getrieben von der IDTA, Open-Source-Umsetzung mit Eclipse BaSyx. Der heißeste Kandidat für die fehlende, vendorübergreifende API-Schicht — in der Produktion aber noch wenig verbreitet.
Etabliertes Kommunikations- und Informationsmodell. Bei CERN dient es als Test-Zugriffsprotokoll, das SPS-Variablen ausliest, ohne das Programm zu verändern — ein Muster, das jede OT-Testplattform übernehmen kann.
Glossar: OPC UAOffene Edge-Interoperabilitäts-Initiative der Linux Foundation (2024), getragen u. a. von ABB, Siemens, Rockwell, Schneider und Microsoft. Das wichtigste Standardisierungs-Signal Richtung herstellerübergreifendes Edge-Platform-Engineering — aber mit Preview Release 1 (Anfang 2026) noch unreif, ohne stabile API.
Der OT-Security-Rahmen aus Zonen, Conduits und Security Levels. Für jede Self-Service- oder Remote-Plattform ist er kein Add-on, sondern die Leitplanke — Remote-Engineering muss sich der Sicherheitsarchitektur unterordnen.
Glossar: IEC 62443Lässt sich Platform Engineering auf SPS/PLC anwenden?
Teilweise. Das Konzept — Self-Service, Golden Paths, Plattform als Produkt — überträgt sich gut, aber es gibt noch kein herstellerübergreifendes Backstage-Äquivalent für die OT. Die realen Hebel heute sind Git-Versionskontrolle für SPS-Code, simulationsgestützte CI (PLCSIM Advanced, CODESYS-Simulation) und zentrales Lifecycle-Management über viele Controller.
Was ist eine Internal Developer Platform in der Industrie?
Sie stellt Automatisierungs-Ingenieuren geprüfte Projekt-Templates, fertige CI/CD-Pipelines, Simulationsumgebungen und versionierte Funktionsbaustein-Bibliotheken als Self-Service bereit. Statt jedes SPS-Projekt von Grund auf aufzubauen, wählen die Teams einen kuratierten, abgesicherten Pfad — den Golden Path.
Gibt es ein Backstage für die OT?
Nein, kein etabliertes herstellerübergreifendes Äquivalent. Die Hersteller-App-Stores — Siemens Industrial Edge, Bosch ctrlX, Phoenix Contact PLCnext — sind Edge-Marktplätze plus Geräte-Management und verstärken den Lock-in. Am nächsten an einer echten Plattform sind der CODESYS Automation Server (Lifecycle) und herstellerneutrale Tools wie Software Defined Automation.
Was ist der Unterschied zwischen DevOps und Platform Engineering?
DevOps ist die Kultur, die Entwicklung und Betrieb zusammenbringt. Platform Engineering ist die organisatorische Antwort darauf, dass „you build it, you run it" Entwickler kognitiv überlastet: Ein dediziertes Plattform-Team baut eine Internal Developer Platform mit Self-Service und Golden Paths. Platform Engineering ersetzt DevOps nicht, sondern macht es skalierbar.
Welche Standards helfen bei der Standardisierung in der OT?
OPC UA als Kommunikations- und Testschicht, die Asset Administration Shell (AAS) als herstellerneutrale API- und Datenschicht und die Margo-Initiative für Edge-Interoperabilität. AAS gilt als aussichtsreichster Kandidat für die fehlende vendorübergreifende Schnittstelle — Margo ist strategisch wichtig, aber noch im Aufbau.
Wann lohnt sich eine eigene Plattform in der Industrie?
Sobald mehrere Werke oder Linien immer wieder ähnliche Pipelines, Tests und Bibliotheken neu aufbauen. Dann zahlt sich Standardisierung aus. Bei einzelnen Anlagen ist eine eigene Internal Developer Platform meist verfrüht — hier sind eine Hersteller-Plattform oder herstellerneutrale Tools die pragmatischere Build-vs-Buy-Antwort.
Verwandte Artikel
Platform Engineering: Der nächste Schritt nach DevOps
Self-Service-Plattformen, Golden Paths und Internal Developer Platforms.
GitOps in der Industrie: SPS/PLC versionieren & ausrollen
Was GitOps in der SPS-Entwicklung und am Industrie-Edge möglich macht.
IT/OT-Kulturwandel: Zwei Welten zusammenbringen
Wie Automatisierer und Software-Teams zu einer Organisation werden.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance