Was Kunden vor dem Pilot fragen

IndustrialFlow ist die CI/CD-Plattform von Comquent für Industrial DevOps.
Sie baut auf Jenkins auf, versioniert SPS- und Leittechnik-Projekte in Git, testet Steuerungscode gegen virtuelle Steuerungen und bringt freigegebene Stände nur über einen OT-Proxy und im Wartungsfenster auf die Anlage.
Die Plattform läuft vollständig im eigenen Netz.

Jenkins ist der Kern von IndustrialFlow, bestehende Jenkinsfiles und Shared Libraries laufen unverändert weiter.
Dazu kommen eine Weboberfläche mit Flotten- und Stationsansicht, ein KI-Assistent, OT-Proxy-Agenten für die segmentierte Fertigungszone und OT-Zustände in der Pipeline: Wartungsfenster, Produktionssperre nach OPC-UA-Abfrage, Snapshot vor jedem Deployment und ein Audit-Trail je Stand.
Die Übernahme einer bestehenden Jenkins-Instanz dauert nach unserer Erfahrung weniger als einen Arbeitstag.

Ja, der Betrieb ist vollständig ohne Verbindung nach außen möglich.
Private Container-Registry, lokaler Plugin-Mirror und ein lokales Sprachmodell über Ollama ersetzen alle externen Quellen; für das Modell planen wir einen GPU-Server mit mindestens 24 GB Grafikspeicher ein.
Der OT-Proxy baut seine Verbindung von innen nach außen auf, eingehende Verbindungen in die OT-Zone gibt es nicht.

Im Maschinenbau sind das TIA Portal, CODESYS, TwinCAT und Studio 5000, getestet wird gegen PLCSIM Advanced, den CODESYS Test Manager, TcUnit oder FactoryTalk Logix Echo.
Bei Versorgern liest der OT-Agent Stände über IEC 60870-5-104, IEC 61850, Modbus TCP und OPC UA.
Welche Werkzeugversion eine Station braucht und auf welchem Build-Agenten sie liegt, führt die Plattform als Inventar.

Der Einstieg ist ein Pilot über 90 Tage zum Festpreis: im Maschinenbau eine Baureihe mit einer Pilotmaschine, beim Versorger eine Anlage mit ihren Stationen.
Jede der vier Phasen endet mit einem messbaren Abnahmekriterium, und am Ende betreibt Ihr Team die Pipeline selbst.
Den Festpreis nennen wir nach dem Erstgespräch, weil er von Toolchain und Anlagenzahl abhängt; die Betriebskosten danach richten sich nach Pipelines, Umgebungen und Support-Level.

Nicht unbedingt: Wer nur sichern und den laufenden Stand mit dem freigegebenen vergleichen will, ist mit einem Change-Management-Werkzeug wie octoplant gut bedient.
IndustrialFlow setzt einen Schritt früher an.
Jede Änderung läuft als Merge Request durch Compile, Simulationstest, Security-Gate und Freigabe, bevor sie die Anlage erreicht, und aus jedem Build entstehen SBOM und Nachweispaket.
Ob das bei Ihnen den Aufwand rechtfertigt, klären wir im Erstgespräch.

Das Systemhaus reicht Änderungen als Merge Request in einen Git-Server im eigenen Netz ein, über den bestehenden Fernwartungszugang, und der Betreiber gibt frei.
Wer ändert, kann nicht selbst freigeben, kritische Anlagen brauchen eine zweite Bestätigung.
Eine Änderung ohne Merge Request fällt im nächsten nächtlichen Abgleich auf und wird der zeitlich passenden Fernwartungssitzung zugeordnet.

Jedes Release bringt ein Nachweispaket mit: einen PDF-Bericht, ein ZIP mit den Originalartefakten und ein JSON-Manifest mit den Hashes aller Dateien.
Im Maschinenbau ist es nach IEC 62443-4-1, Cyber Resilience Act und Maschinenverordnung gegliedert, bei Versorgern nach § 30 BSIG, B3S WA oder IT-Sicherheitskatalog.
Dazu kommt je Build eine SBOM in CycloneDX und SPDX mit VEX-Angaben.

Nein, IndustrialFlow steuert keine Prozesse und ersetzt weder Netzleitsystem noch Prozessleitsystem.
SPS-Code wird weiter im Engineering-Werkzeug bearbeitet, und aus der Oberfläche gibt es keinen direkten Download auf eine Steuerung, nur den Start einer Pipeline mit ihren Gates.
Schreibzugriff auf eine Station hat der OT-Agent ausschließlich im Auftrag einer freigegebenen Pipeline.