AI// Plattform und Werkzeuge: versionieren → bauen und testen → nachweisen → mit KI entwickeln
Produkte für die SPS-Entwicklung
Eine Plattform und vier Werkzeuge für Steuerungssoftware, unabhängig vom Hersteller. IndustrialFlow bringt geprüfte Stände bis auf die Anlage und ist als 90-Tage-Pilot verfügbar. Die vier PLC-Werkzeuge decken einzelne Schritte ab, für Teams, die ihre eigene Pipeline behalten wollen.
30 Minuten · unverbindlich · kein Vertriebsgespräch
INDUSTRIALFLOW VERFÜGBAR · VIER WERKZEUGE IN ENTWICKLUNG · TIA PORTAL · CODESYS · TWINCAT · STUDIO 5000
Warum eigene
Werkzeuge?
Weil zwischen Engineering-Umgebung und CI/CD-Pipeline Werkzeuge fehlen, die bisher jedes Team selbst schreibt, und zwar für jeden Hersteller neu.
Jeder Hersteller liefert Schnittstellen: TIA Portal das Version Control Interface und Openness, CODESYS File-Based Storage und eine Scripting-Schnittstelle, TwinCAT das Automation Interface, Studio 5000 den L5X-Export und das Logix Designer SDK. Was zwischen diesen Schnittstellen und Git, Pipeline und SBOM fehlt, ist überall dasselbe. Die vier Produkte haben dafür einen gemeinsamen Kern und je Umgebung einen Adapter. Wer Steuerungen mehrerer Hersteller betreut, arbeitet damit überall nach denselben Regeln. Wer die ganze Strecke bis zur Anlage will, nimmt die Plattform IndustrialFlow; wer seine Pipeline behält, setzt einzelne Werkzeuge ein.
- Status
- IndustrialFlow als 90-Tage-Pilot verfügbar, die vier PLC-Werkzeuge in Entwicklung
- Hersteller
- Adapter für Siemens TIA Portal, CODESYS, Beckhoff TwinCAT 3 und Rockwell Studio 5000
- Erweiterbar
- Weitere Umgebungen über eigene Adapter, etwa über PLCopen XML
- Betrieb
- Im eigenen Netz; das KI Tool wahlweise mit lokalem Modell
- Einbindung
- Jenkins, GitLab CI, Azure DevOps und Ihr vorhandener Git-Server
Bei vielen Maschinenbauern entscheidet der Kunde, welche Steuerung in die Maschine kommt. Die Siemens-Projekte liegen dann in Git, die Rockwell-Projekte als Dateien mit Datum im Namen auf dem Netzlaufwerk, und für die Beckhoff-Zelle hat ein Kollege ein eigenes Skript. Drei Arbeitsweisen für dieselbe Frage: Welcher Stand läuft beim Kunden?
Welche Produkte
gibt es?
AIPlattform · Verfügbar als 90-Tage-Pilot
IndustrialFlow
Die CI/CD-Plattform für SPS und Leittechnik: Jenkins im Kern, ein Dashboard für Flotte und Stationen, ein OT-Proxy bis zur Anlage, alles im eigenen Netz.
Versionieren, bauen und testen, Nachweise erzeugen, dazu Freigabe im Vier-Augen-Prinzip und Deployment im Wartungsfenster.
- /01
AIPLC Git Bridge
Versionieren · in Entwicklung
Ein Git-Ablauf für SPS-Projekte aller unterstützten Hersteller, mit Prüfung vor dem Commit und Archiv zum Release.
- /02
AIPLC Build Tool
Bauen und testen · in Entwicklung
Ein Befehlssatz zum Übersetzen, Prüfen und Testen, gleich für jede Engineering-Umgebung und aus jeder Pipeline.
- /03
AIPLC SBOM Builder
Nachweisen · in Entwicklung
Eine Software-Stückliste für die ganze Maschine, auch mit Steuerungen mehrerer Hersteller, in jedem Build neu.
- /04
AIPLC KI Tool
Mit KI entwickeln · in Entwicklung
KI schreibt Vorschläge für den Steuerungscode, die Pipeline prüft sie, ein Mensch gibt frei.
Wie hängen Plattform
und Werkzeuge zusammen?
Die vier Werkzeuge bilden eine Kette. Die Git Bridge legt den Stand in Git ab, das Build Tool übersetzt und testet ihn, der SBOM Builder dokumentiert, was in der Steuerung steckt, und das KI Tool arbeitet nur über diese Kette.
IndustrialFlow deckt die ersten drei Schritte als Stufen der eigenen Pipeline ab und geht weiter bis zur Anlage. Die Werkzeuge sind für Teams, die ihre vorhandene Pipeline behalten wollen. Jedes läuft auch allein; wer schon versioniert, beginnt mit dem Build Tool.
- AI01 · VersionierenPLC Git Bridge
- AI02 · Bauen und testenPLC Build Tool
- AI03 · NachweisenPLC SBOM Builder
- AI04 · Mit KI entwickelnPLC KI Tool
Die Schritte 01 bis 03 als Stufen einer fertigen Pipeline, dazu Freigabe im Vier-Augen-Prinzip, Deployment über den OT-Proxy im Wartungsfenster und das Dashboard für Flotte und Stationen.
Welche Hersteller
werden unterstützt?
Geplant sind Adapter für vier Engineering-Umgebungen. Ein Adapter kennt die Schnittstellen seiner Umgebung, die Produkte darüber bleiben gleich. Der CODESYS-Adapter deckt damit auch Marken ab, die auf CODESYS aufbauen.
Welche Adapter zuerst fertig werden, ist noch offen. Weitere Umgebungen wie PLCnext Engineer oder B&R Automation Studio lassen sich über eigene Adapter anbinden, Projekte ohne eigene Schnittstelle über das herstellerneutrale PLCopen XML.
| Umgebung | Quellen als Text | Build ohne Oberfläche | Prüfung und Test |
|---|---|---|---|
| Siemens TIA Portal V21 | SIMATIC SD über das Version Control Interface | TIA Portal Openness | TIA Portal Test Suite, S7-PLCSIM Advanced |
| CODESYS V3.5 | File-Based Storage, CODESYS Git oder PLCopen XML | Scripting-Schnittstelle ohne Oberfläche | CODESYS Static Analysis, CODESYS Test Manager |
| Beckhoff TwinCAT 3 | Projekt liegt schon als XML- und Textdateien vor | TwinCAT Automation Interface | TwinCAT 3 PLC Static Analysis, TcUnit, Usermode Runtime |
| Rockwell Studio 5000 | L5X-Export aus dem binären .ACD-Projekt | Logix Designer SDK | Tests gegen FactoryTalk Logix Echo |
Die Hersteller-Schnittstellen im Vergleich: SPS-Hersteller, Vergleich und Git-Eignung
Was geht schon heute?
Den Weg ohne Produkt. Für TIA Portal V21 beschreibt je ein Whitepaper den Ablauf, den das Produkt später übernimmt, Schritt für Schritt und mit Quellen; die Grundsätze gelten auch für die anderen Hersteller. Wo Ihr Team heute steht, ordnet der DevOps-Reifegrad-Check ein.
Früh dabei,
am eigenen Projekt.
Wir suchen Automatisierungsteams, die eines der Produkte früh an einem eigenen Projekt einsetzen wollen. Welches passt, was dafür nötig ist und ab wann es geht, klären wir in einem kurzen Gespräch.