// Anwendung 01 · Maschinen- und Anlagenbau
Zuletzt fachlich geprüft: · Andreas Schönfeld
IndustrialFlow zeigt einem Maschinenbauer für jede ausgelieferte Maschine, welcher Programmstand dort läuft, wer ihn freigegeben hat und welche Tests er bestanden hat.
Anwendung /01Security und CRA
Maschine #1038, korrigierter Stand v4.8.3 wartet auf Freigabe
Demo-SzenarioEin Maschinenbauer hat 312 Maschinen im Feld.
Am Morgen geht die interne Meldung PSIRT-2026-017 ein, eine aktiv ausgenutzte Schwachstelle in einer Bibliothek der Baureihe VPA-200.
Die Abfrage zeigt 41 betroffene Maschinen bei 12 Kunden, die Frühwarnung ist in knapp 18 Stunden fällig.
// 01 Ausgangslage
Ein Inbetriebnehmer spielt das Update vor Ort per Laptop ein, ohne festen Ablauf.
Welcher Stand danach läuft, weiß oft nur er.
178.000
Fachkräfte fehlen dem deutschen Maschinenbau bis 2034.
Mit jedem Inbetriebnehmer geht Wissen über Anlagenstände.
Keine Versionskontrolle.
SPS-Programme liegen auf USB-Sticks und Netzlaufwerken.
Welcher Stand auf welcher Maschine läuft, weiß oft nur der Inbetriebnehmer.
Manuelle Deployments.
Updates spielt jemand vor Ort per Laptop ein, ohne festen Ablauf.
Bei zehn Anlagen ist das mühsam, bei hundert nicht mehr zu leisten.
Test erst an der Anlage.
PLCSim ist auf vielen Engineering-Rechnern installiert, gestartet wird er von Hand.
Fehler zeigen sich deshalb unter Zeitdruck bei der Inbetriebnahme.
Getrennte Freigabewege.
Die IT arbeitet mit Merge Requests, die Steuerungstechnik mit Wartungsfenstern und Abnahmen.
An der Übergabe wartet jedes Projekt.
// 02 Mit IndustrialFlow
Die Plattform baut auf Jenkins auf, testet SPS-Code gegen eine virtuelle Steuerung und spielt ihn nur im Wartungsfenster auf eine stehende Maschine.
/01
Die Flottenansicht vergleicht den freigegebenen Stand in Git mit dem Stand auf der Steuerung und meldet jede Abweichung.
/02
PLCSIM Advanced, CODESYS Test Manager, TcUnit oder FactoryTalk Logix Echo laufen bei jeder Änderung als Stage in der Pipeline.
/03
Jeder Build erzeugt eine SBOM, und eine Betroffenheitsabfrage listet alle Maschinen mit einer verwundbaren Komponente.
Jede ausgelieferte Maschine erscheint mit Kunde, Baureihe, Steuerung, Soll- und Ist-Stand.
Den Ist-Stand liest ein OT-Proxy per OPC UA; Maschinen ohne dauerhaften Fernzugang melden ihn über den Service-Einsatz oder das Edge-Gateway.
Die Maschinenakte zeigt alle Deployments, Freigaben und Service-Einsätze seit der Inbetriebnahme.
Die Betroffenheitsabfrage listet zu einer Schwachstelle alle Maschinen mit der betroffenen Komponente nach Kunde und Seriennummer.
Supportende und Restlaufzeit stehen je Baureihe und Maschine dabei.
Seit TIA Portal V21 schreibt das Version Control Interface auch KOP, FUP und SCL als Text (SIMATIC SD), sodass Reviewer im Merge Request jede geänderte Zeile sehen.
IT-Zone
Git-Server
Projekte als Text, SIMATIC SD · Merge Requests mit Review
Jenkins-Kern · IT-Phase
Export, Compile, PLCSim-Test · IEC-62443-Gate, SBOM, Signatur
Dashboard und KI-Assistent
Flotte, Freigaben, Nachweise · KI lokal über Ollama
DMZ
OT-Proxy
TLS-Tunnel, Zonen nach IEC 62443
OT-Zone an der Maschine
OPC-UA-Pre-Check
Betriebsart, laufender Auftrag · Wartungsfenster, Snapshot
SPS-Steuerung
TIA Portal, CODESYS, TwinCAT · Rollback zum letzten Stand
Edge-IPC
OPC-UA-Gateway, Node-RED · Argo CD oder Flux, automatisch
// 03 Anforderungen
Neun Anforderungen bestimmen, ob eine Plattform im Maschinenbau trägt.
| Anforderung | Umsetzung in IndustrialFlow | Umfang |
|---|---|---|
| Stand je ausgelieferter Maschine | Flottenansicht mit Soll- und Ist-Stand; Diff auf Bausteinebene, wo ein Textformat vorliegt (SIMATIC SD, ST, L5X); Datenalter immer sichtbar | Grundumfang |
| Test ohne reale Anlage | Simulationstest als Pipeline-Stage mit PLCSIM Advanced V8.0, CODESYS Test Manager, TcUnit oder Logix Echo; Ergebnisse einheitlich als JUnit-XML | Grundumfang |
| Passende Werkzeugversion und Lizenz | Übersicht der Windows-Build-Agenten nach TIA-Portal- und TwinCAT-Version, Lizenz und Belegung | Grundumfang; Warnung vor dem Build geplant |
| Freigabe nach dem Vier-Augen-Prinzip | Freigabe mit Merge Request, Testergebnis, Gate und Signatur; Pflicht bei Safety-CPU; die Entscheidung läuft zurück in den Jenkins-input-Step | Grundumfang |
| Deployment nur im Wartungsfenster und bei Stillstand | Zustand „Wartet auf Wartungsfenster“; OPC-UA-Pre-Check liest Betriebsart und Auftrag, bei laufender Produktion greift die Produktionssperre | Grundumfang |
| Geprüfter Weg zurück | Snapshot vor jedem Deployment, Rückkehr zum letzten freigegebenen Stand als eine Aktion | Grundumfang |
| Edge-Schicht und SPS getrennt | Edge-Workloads per Argo CD oder Flux automatisch auf Soll, SPS-Programm nur mit Freigabe im Wartungsfenster | Grundumfang |
| Cyber Resilience Act | SBOM in CycloneDX und SPDX mit VEX je Build; Betroffenheitsabfrage über die Flotte | Grundumfang; Meldefristen-Countdown geplant |
| Nachweise nach IEC 62443-4-1 | Nachweispaket je Release, gegliedert nach den Praktiken SM, SR, SD, SI, SVV, DM, SUM und SG | Grundumfang |
Grundumfang heißt: im Pilot und in der ersten Version enthalten; geplant heißt: als Ausbaustufe vorgesehen und nachrüstbar.
| Regelwerk | Was es verlangt | Nachweis aus IndustrialFlow |
|---|---|---|
| Cyber Resilience Act (EU) 2024/2847 | Meldung aktiv ausgenutzter Schwachstellen seit 11.09.2026, Frühwarnung binnen 24 Stunden; ab 11.12.2027 alle Pflichten einschließlich Software-Stückliste. | SBOM je Build, Betroffenheitsabfrage über die Flotte, Supportende je Maschine |
| Maschinenverordnung (EU) 2023/1230, Anhang III 1.1.9 | Ab 20.01.2027 Schutz gegen Korrumpierung, Erfassung von Eingriffen, Kennzeichnung sicherheitsrelevanter Software. | Audit-Trail je Stand, Hash und Signatur je Artefakt, Versionsnachweis je Maschine |
| IEC 62443-4-1 | Sicherer Entwicklungsprozess beim Hersteller. | Secret-Scan, SBOM, CVE-Prüfung, signierte Artefakte; Bericht aus dem Audit-Log |
| IEC 61508 / IEC 61511 | Traceability von der Anforderung zum Test, Coverage, Reviews. | Trace-Matrix, Coverage-Report und Review-Protokolle je Release |
// 04 90-Tage-Pilot
Der Pilot dauert 90 Tage und läuft an einer Baureihe und einer Pilotmaschine.
Jede Phase endet mit einem prüfbaren Kriterium.
Phase 1 · Woche 1–2
Pilot-Pipeline
TIA-Projekt in Git · Jenkins per Docker · Compile automatisch
Abnahme · erster grüner Build
Phase 2 · Woche 3–4
Test und KI
PLCSim-Smoke-Tests · 10 Build-Fehler per KI analysiert
Abnahme · Test bei jeder Änderung
Phase 3 · Woche 5–8
OT-Strecke
OT-Proxy in Staging · Wartungsfenster · Trockenlauf der Produktionssperre
Abnahme · Trockenlauf bestanden
Phase 4 · Woche 9–12
Nachweise
SBOM je Build · IEC-62443-Bericht · Flotte einer Baureihe · Übergabe ans Team
Abnahme · Pilot abgenommen
Phase 1 · Woche 1–2
Pilot-Pipeline
TIA-Projekt in Git · Jenkins per Docker · Compile automatisch
Abnahme · erster grüner Build
Phase 2 · Woche 3–4
Test und KI
PLCSim-Smoke-Tests · 10 Build-Fehler per KI analysiert
Abnahme · Test bei jeder Änderung
Phase 3 · Woche 5–8
OT-Strecke
OT-Proxy in Staging · Wartungsfenster · Trockenlauf der Produktionssperre
Abnahme · Trockenlauf bestanden
Phase 4 · Woche 9–12
Nachweise
SBOM je Build · IEC-62443-Bericht · Flotte einer Baureihe · Übergabe ans Team
Abnahme · Pilot abgenommen
Die Grundinstallation per Docker Compose dauert etwa zehn Minuten, die Zeit geht in die Anbindung der Engineering-Werkzeuge.
Scharf geschaltet wird das Deployment auf die Steuerung erst, wenn die Produktionssperre im Trockenlauf an der realen Maschine gegriffen hat.
Whitepaper · 22 Seiten · PDF · Oktober 2026
Was ein Maschinenbauer von einer CI/CD-Plattform verlangen muss und wie IndustrialFlow es umsetzt: SPS-Code in Git, Tests gegen eine virtuelle Steuerung, Deployment nur im Wartungsfenster.
Kostenlos · per E-Mail
Nächster Schritt
Ob sich ein Pilot für Ihre Anlagen lohnt, klären wir vorher.
Im Erstgespräch gehen wir Toolchain, Baureihe oder Anlage und die Rolle Ihres Systemhauses durch, und Sie wissen danach, wie die erste Pipeline aussähe.
30 Minuten · unverbindlich · kein Vertriebsgespräch