Kestra S.A.S.

Eine Palette wartet an einer Übergabestation, weil der autonome mobile Roboter (AMR), der sie abholen soll, hinter einem Gabelstapler in der Warteschlange steht. Zwei Gebäude weiter ist in einem Serverraum um zwei Uhr nachts der Exportjob ausgefallen, der das Qualitätssystem versorgt, und bemerkt hat es niemand bis zur Frühschicht. Keines der beiden Probleme ist ein Roboterproblem oder ein Datenbankproblem; beide sind Koordinationsprobleme.

Fabriken mangelt es nicht an Automatisierung, sondern an Koordination zwischen den Automatisierungen. Maschinen werden von SPSen automatisiert, die Datenerfassung übernehmen SCADA-Systeme und Historians, den Materialfluss automatisieren FTF (fahrerlose Transportfahrzeuge) und AMRs, und Produktionsaufträge laufen über MES und ERP. Jede dieser Schichten funktioniert für sich genommen tadellos. Die Fehler verstecken sich in den Übergaben dazwischen, wo kein einzelnes System zuständig ist.

Unified Orchestration schließt diese Lücke, indem eine Steuerungsebene Datenpipelines, IT- und Edge-Infrastruktur, Anwendungsintegration und Geschäftsprozesse koordiniert, inklusive einer agentischen KI, die über alle vier hinweg geregelt wird. Das ist weder ein neuer Datenbus noch ein neues MES oder ein Robotercontroller, sondern die Schicht, die entscheidet, was läuft, in welcher Reihenfolge und was passiert, wenn ein Schritt fehlschlägt. Dieser Beitrag überträgt das Konzept auf Fertigung und Logistik, vom Shop Floor bis in die Cloud.

Die Automatisierungssilos einer modernen Fabrik

Wer durch ein großes Werk geht, findet unabhängig davon, wie weit dessen Industrie-4.0-Fahrplan fortgeschritten ist, mindestens vier Orchestrierungssilos, die alle aus guten Gründen so gewachsen sind.

• OT-Datensilo: Sensor- und Maschinendaten laufen über OPC-UA-Server, MQTT-Broker und Streaming-Plattformen zu Historians und in die Cloud-Analytik, und obendrauf plant ein Python-basierter Orchestrator die Analyse-Pipelines.

• Werks-IT-Silo: Hunderte Industrie-PCs, Edge-Server und Dateitransfer-Jobs werden am Leben gehalten, oft zusammengehalten von geplanten Tasks und Skripten, die vor einem Jahrzehnt geschrieben wurden.

• Anwendungssilo: MES, ERP, Lagerverwaltung und Qualitätssysteme sind über Punkt-zu-Punkt-Schnittstellen miteinander verbunden.

• Geschäftsprozess-Silo: Freigaben, Instandhaltungs-Workflows und Ausnahmebehandlung laufen manchmal in einem BPM-Werkzeug, häufiger in E-Mail und Tabellenkalkulation.

Jedes dieser Silos verfügt über starke Werkzeuge, und die Kosten entstehen auch nicht innerhalb davon, sondern an den Rändern: beim ML-Modell, das neu trainiert werden sollte, sobald neue Produktionsdaten eintreffen, es aber nicht tut; beim Deployment, das auf dem Edge-Cluster erfolgreich durchläuft, von dem das MES-Team aber nie erfährt; bei der Instandhaltungsfreigabe, die in einem Postfach liegt, während eine Maschine stillsteht. Unified Orchestration spannt sich als eine Steuerungsebene über alle vier Silos hinweg und macht genau diese Übergaben zum eigenen Gegenstand.

Wo Orchestrierung im ISA-95-Stack sitzt

Leser aus der Fertigung reagieren zu Recht allergisch auf IT-Anbieter, die die Grenze zum Regelkreis verwischen, weshalb diese Grenze hier am Anfang steht.

Der harte Echtzeit-Regelkreis ist tabu. SPS-Logik, Sicherheitsfunktionen, SCADA-Steuerung und das Verkehrsmanagement einer AMR-Flotte laufen unter deterministischen Garantien mit festen Zykluszeiten, Sicherheitszertifizierung und Reaktionen, die jedes Mal pünktlich eintreffen müssen. Event-getriebene Orchestrierung ist zwar ebenfalls schnell und reagiert oft innerhalb von Millisekunden auf ein Ereignis, doch was die beiden Welten trennt, ist nicht die reine Geschwindigkeit, sondern der Determinismus und die Zertifizierung dahinter. Eine Orchestrierungs-Engine wiederholt und eskaliert, wenn etwas zu spät kommt; eine Sicherheitsfunktion hat diese Option nicht.

Wie weit reicht Orchestrierung nach unten?

In den Begriffen von ISA-95, dem Standard, der definiert, wo Unternehmenssysteme enden und Steuerungssysteme beginnen, arbeitet Orchestrierung auf den Ebenen 3 und 4, also bei Fertigungsabläufen und Geschäftsplanung, sowie an den Nahtstellen dazwischen. Nach Ebene 2 reicht sie nur hinunter, um Anlagen Befehle zu geben und ihren Zustand zu lesen: Eine Variable auf einem Robotercontroller setzen, eine Routine starten oder prüfen, ob die Zellentür geschlossen ist, bevor Arbeit zugewiesen wird, ist durchweg legitim.

Die Sicherheitsentscheidung selbst zu treffen, ist es dagegen nicht. Den Türzustand zu lesen, bleibt eine Vorbedingung und wird nie zur Sicherheitsfunktion, denn die Sicherheits-SPS und der Sicherheitscontroller des Roboters überwachen diese Tür unabhängig davon und stoppen die Maschine, egal ob der Orchestrator das Signal korrekt gelesen hat, zu spät gelesen hat oder überhaupt nicht. Orchestrierung entscheidet also, welche Arbeit angestoßen wird, während die Ebenen 0 bis 2 darüber entscheiden, ob diese Arbeit physisch stattfinden darf. Befehle und Zustandsabfragen reichen damit bis in Ebene 2 hinein, während Sicherheit und harter Echtzeit-Regelkreis unterhalb der Grenze bleiben.

Die strenge ISA-95-Pyramide flacht ohnehin ab, weil Unified Namespaces (UNS), Edge Computing und Cloud-Analytik die alten Netzebenen durchbrechen. Als Karte des Werks gelten die logischen Grenzen zwischen den Ebenen weiterhin, was sie allein nicht mehr klären, ist der Zuschnitt: Ob ein Schritt zur Orchestrierung gehört, hängt an der Garantie, die er geben muss, und nicht an der Ebene, auf der sein Ziel sitzt.

Wie sich der Unified Namespace zur Orchestrierung verhält

Auch die Datenbewegungsschicht ist eine Aufgabe für sich, und das vorherrschende Muster ist hier der Unified Namespace: eine event-getriebene Architektur, die Maschinen und Anwendungen verbindet, Daten in einer vorhersehbaren Hierarchie ordnet und sie per Publish-Subscribe verfügbar macht.

Die häufigste Umsetzung nutzt einen MQTT-Broker als Rückgrat, wobei Sparkplug B Topic-Struktur und Payloads definiert, während OPC UA den strukturierten Zugriff nahe an den Maschinen liefert. OPC UA, MQTT und Kafka bilden die Dreifaltigkeit des Data Streamings im industriellen IoT, weil sie unterschiedliche Teile des Problems lösen und gemeinsam am stärksten sind, wenn sie Maschinendaten ins Unternehmen und in die Cloud-Analytik tragen. Während der UNS die lebenden OT-Daten strukturiert, machen auf der IT-Seite Data Products aus diesem Strom geregelte, wiederverwendbare Assets mit Schemata, Ownership und Zugriffskontrolle, sodass zwei komplementäre Muster in einer Pipeline zusammenkommen. Die Data Integration Landscape 2026 kartiert diese Schicht Anbieter für Anbieter und lässt Workflow-Orchestrierung bewusst außen vor.

Nichts davon ist Orchestrierung, denn der UNS und die Streaming-Schicht bewegen Daten, während Orchestrierung entscheidet. Sie reagiert auf ein Ereignis im Namespace, stößt die Retraining-Pipeline an, koordiniert die Schemaänderung über alle Konsumenten hinweg, eröffnet das Ticket, wenn ein Konnektor ausfällt, und fordert eine menschliche Freigabe an, bevor irgendetwas die Produktion berührt. Die eine Schicht bewegt die Daten, die andere koordiniert die Arbeit darum herum, und sie getrennt zu halten ist der Grund, weshalb beide verlässlich bleiben.

Datenpipelines vom Sensor bis ins Lakehouse orchestrieren

Der übliche Telemetriepfad führt von SPSen über OPC UA in einen MQTT-Broker, wird im Unified Namespace normalisiert, strömt über Kafka in ein Cloud-Lakehouse und speist von dort Dashboards und ML-Modelle.

Jedes Stück dieser Pipeline hat einen Eigentümer, die Schritte drumherum in der Regel nicht. Welcher Job löst das Modell-Retraining aus, wenn eine neue Produktionscharge abgeschlossen ist? Was koordiniert den Rollout, wenn sich eine Topic-Struktur ändert und vierzehn Konsumenten nachziehen müssen? Und wem fällt auf, dass der tägliche Qualitätsbericht nicht gelaufen ist? Heute lauten die Antworten darauf: Cronjobs auf einer VM, ein Notebook, das jemand von Hand startet, und Hoffnung.

Genau hier rechtfertigt eine geregelte Orchestrierungsschicht ihren Platz, mit event-getriebenen Triggern bei Dateneingang, werkzeugübergreifenden Abhängigkeiten, Retries mit Backoff und einem Audit-Trail, der zeigt, was gelaufen ist und warum. Die Pipeline bleibt dabei, was sie ist, nur die Koordination darum herum wird explizit, versioniert und beobachtbar. Workflow-Orchestrierung und Process Intelligence gehören an dieser Stelle zusammen (siehe die Process Intelligence Landscape 2026), weil die eine die Abläufe ausführt und die andere zeigt, wie sie tatsächlich laufen und wo sie stocken.

Wo Orchestratoren in der Fertigung ihren Platz haben

Die meisten Hersteller betreiben bereits einen Orchestrator, ohne ihn so zu nennen, denn das Data-Science-Team, das Qualitätsvorhersage, Energieoptimierung oder Predictive Maintenance baut, plant seine Pipelines mit einem Workflow-Orchestrator wie Airflow, Dagster oder Prefect.

Diese Werkzeuge sind stark in ihrer Heimatdomäne, dem Data Engineering in Python. Airflow bringt das größte Ökosystem mit, und Airflow 3 hat die Engine um event-getriebenes Scheduling modernisiert, während das Kernmodell dasselbe bleibt: Pipelines als Python-Code, gebaut von Datenteams. Dagsters Asset-zentriertes Modell passt natürlich zum Data-Product-Denken, das gerade in IT/OT-Architekturen ankommt, und Prefect macht dynamische Python-Workflows einfach für Teams, die in Notebooks leben. Inzwischen sind die beiden ein Unternehmen, denn Prefect hat im Juli 2026 Dagster Labs übernommen und damit die zwei am weitesten verbreiteten Airflow-Nachfolger unter einem Dach vereint, wobei beide Produkte fortgeführt werden. Der Deal ist ein Signal für die gesamte Kategorie: Orchestrierung konsolidiert sich, und beide Unternehmen haben die Fusion um KI-Agenten herum positioniert und nicht um Datenpipelines.

Kestra geht einen anderen Weg, denn Workflows sind dort deklarative YAML-Definitionen statt Python-Code, jede Sprache läuft innerhalb eines Tasks, und menschliche Freigaben, Infrastrukturschritte und event-getriebene Trigger sind native Konzepte der Engine statt nachträglicher Erweiterungen. Dieser Entwurf zielt genau auf den Zuschnitt dieses Beitrags, nämlich auf eine Plattform, die Datenpipelines, Werks-IT, Anwendungen und Geschäftsprozesse koordiniert, weshalb Kestra hier über die Kategorien hinweg auftaucht und nicht nur in diesem Abschnitt. Der Gegenpunkt gehört in denselben Absatz: Ein Team, das vollständig in Python-nativen Asset-Pipelines lebt, verliert wenig, wenn es bleibt, wo es ist, und der Unterschied zeigt sich erst in dem Moment, in dem ein Workflow die Datendomäne verlassen muss.

Wo Python-DAGs an ihre Grenzen stoßen

Die Abwägungen der Python-nativen Werkzeuge treten an der Werksgrenze zutage. Weil Workflows Python-Code sind, muss jeder Mitwirkende Python-Entwickler sein, und so können der Automatisierungstechniker, der die Linie kennt, und das SAP-Team, dem die Auftragsdaten gehören, den DAG weder lesen noch erweitern, also jenen gerichteten azyklischen Graphen aus Python-Code, der jede Pipeline definiert.

Der Zuschnitt dieser Werkzeuge ist Daten, und entsprechend kennt ein Python-DAG weder eine menschliche Freigabe noch einen Infrastruktur-Provisioning-Schritt oder ein Patch-Fenster auf einem Linien-PC als natives Konzept. Dazu kommt die betriebliche Reibung der Werksrealität, denn Python-Dependency-Management innerhalb eines Air-Gapped-Netzes ist ein eigenes Projekt, und ein vollständiger Scheduler-Stack ist schwer für eine Edge-Box neben der Linie. Governance wie feingranulares RBAC und Audit-Trails steckt zudem oft in kommerziellen Tiers oder Bolt-ons. Nichts davon ist ein Mangel der Werkzeuge, denn sie wurden für Datenteams in vernetzten Cloud-Umgebungen gebaut, und dort glänzen sie.

Unified Orchestration reißt diese Werkzeuge deshalb nicht heraus, sondern koordiniert sie. Der Python-DAG läuft exakt weiter wie bisher, während die Steuerungsebene ihn bei einem Produktionsereignis auslöst, seinen Abschluss aufnimmt und den Ablauf weiterträgt in den Arbeitsauftrag im Instandhaltungssystem (CMMS), in die ERP-Prüfung und in die menschliche Freigabe, die eine Datenpipeline nie abbilden könnte. Teams, die später konsolidieren wollen, können dann Pipeline für Pipeline migrieren, und Teams, die ihr Tooling behalten möchten, gewinnen trotzdem die Koordinationsschicht darüber.

Werks-IT und Edge-Infrastruktur: das Problem der Windows-PCs auf dem Shop Floor

Das unglamouröseste Silo ist zugleich das lehrreichste. Jedes Werk betreibt Flotten von Windows-Industrie-PCs, von Maschinenterminals über Etikettendrucker und Bildverarbeitungsstationen bis zu Linienservern, und je tiefer man in die Hallen geht, desto älter werden die Betriebssysteme. Windows XP treibt in vielen Brownfield-Werken noch immer Maschinenterminals an, und irgendwo läuft eine eingebettete DOS-Box in einem Maschinencontroller, der seit den Neunzigern im Einsatz ist.

Der Grund dafür ist struktureller Natur: Eine Produktionslinie läuft zwanzig oder dreißig Jahre, der Betriebssystem-Support endet nach etwa zehn, und der Maschinenhersteller hat genau eine Version zertifiziert, sodass die Maschine jedes Betriebssystem überlebt, das mit ihr ausgeliefert wird. Jede Support-Ende-Welle erzwingt daher dieselbe Übung, nämlich Migrationsplanung über Hunderte Geräte, die nur in geplanten Stillstandsfenstern angefasst werden dürfen, mit kostenpflichtigem Extended Support als teurer Brücke für alles, was nicht rechtzeitig umziehen kann.

Legacy-Scheduler und undokumentierte Skripte

Auf diesen Maschinen laufen tatsächlich Windows-Tasks, die um Mitternacht CSV-Dateien auf eine Freigabe kopieren, Batch-Skripte, die einen Treiber neu starten, und Agenten von Enterprise-Job-Schedulern, die vor Jahren installiert wurden. In vielen Werken betreiben dieselben kommerziellen Workload-Automation-Plattformen, die im Bankwesen die nächtliche Abwicklung fahren, auch MRP-Läufe, Qualitäts-Batch-Exporte und Produktionsplanungsjobs. Der Markt hat sich dabei unter wenigen Eigentümern konsolidiert, denn BMC (Control-M), Broadcom (Automic, AutoSys) und Redwood (ActiveBatch, RunMyJobs, Tidal) halten den Großteil der installierten Basis. Die Lizenzkosten erreichen bei Großunternehmen jährlich siebenstellige Beträge, mit volumenbasierten Zählmodellen und zweistelligen jährlichen Preissteigerungsklauseln, die jede architektonische Verbesserung bestrafen.

Das ist Workload Automation in ihrer fragilsten und zugleich teuersten Form. Die kommerziellen Plattformen haben immerhin eine Änderungsverfolgung, während die Skripte drumherum weder Versionskontrolle noch Audit-Trail besitzen und das institutionelle Wissen dahinter mit der Person in Rente geht, die sie geschrieben hat.

Die Lücke zwischen GitOps und Cronjobs überbrücken

Gleichzeitig zieht die moderne Edge neben der Legacy ein, denn kleine Kubernetes-Cluster, die direkt in Fabriken laufen, sind in Automobilbau und Fertigung zu einem Grundmuster geworden und werden über GitOps und Flotten-Tooling verwaltet. Das Ergebnis ist ein Werk mit gespaltenem Hirn, mit deklarativer, Git-getriebener Automatisierung auf dem neuen Edge-Stack und undokumentierten Skripten auf dem alten.

Eine Orchestrierungsschicht, die beides überspannt, ist die pragmatische Brücke dazwischen. Patch-Sequenzen lassen sich mit Stillstandsfenstern und menschlichen Freigaben abstimmen, Dateitransfers werden zu überwachten, wiederholbaren Workflows, und Jobs aus Legacy-Schedulern wandern Schritt für Schritt in Definitionen, die in Git liegen. Modernisierung wird so zu einem gesteuerten Pfad statt zu einem Big Bang, was in einer Umgebung zählt, in der Stillstand in verlorener Produktion gemessen wird.

MES, ERP und der Mensch im Ablauf

Im Anwendungssilo zeigt sich schließlich der durchgängige Nutzen.

Predictive Maintenance: das kanonische Beispiel

Predictive Maintenance eignet sich als Beispiel, weil es jede Domäne quert. Ein Anomaliemodell meldet ein Lager, woraufhin im Instandhaltungssystem ein Arbeitsauftrag entstehen, die Teileverfügbarkeit im ERP geprüft, ein Techniker zugewiesen, der Eingriff in ein Stillstandsfenster eingeplant und der Abschluss an SAP zurückgemeldet werden muss. Die Hälfte dieser Schritte sind API-Aufrufe, bei der anderen Hälfte sind Menschen beteiligt. Ein Workflow, der die menschliche Freigabe als vollwertigen Schritt behandelt, mit demselben Audit-Trail wie die API-Aufrufe, macht den Unterschied zwischen einer Demo und einem Produktivprozess.

Intralogistik und die VDA-5050-Grenze

Die Intralogistik führt die Grenze am schärfsten vor Augen. Gemischte Flotten aus FTF und AMRs werden heute über den Standard VDA 5050 koordiniert, eine einheitliche, herstellerunabhängige Schnittstelle zwischen Fahrzeugen und einer zentralen Leitsteuerung. Der Standard entwickelt sich aktiv weiter, mit Version 3.0 als jüngstem Hauptrelease, und eine aktuelle Welle herstellerübergreifender Zertifizierungen umfasst Flottensoftware ebenso wie Roboterhersteller. Das ist Orchestrierung von Fahrzeugen, sie gehört zum Flottenmanager und damit auf die harte Echtzeitseite der Grenze.

Die Schicht darüber ist in den meisten Werken leer, obwohl der Transportbedarf im MES oder ERP entsteht, sobald ein Auftrag freigegeben wird. Irgendjemand muss dieses Produktionsereignis in einen Transportauftrag übersetzen, ihn an den Flottenmanager übergeben, auf Ausnahmen achten, eskalieren, wenn eine Übergabe in einen Timeout läuft, und die Zustellung an das Geschäftssystem zurückmelden. Der Flottenmanager orchestriert die Fahrzeuge, und die Steuerungsebene darüber orchestriert den Flottenmanager zusammen mit allem, was ihn umgibt.

Kann Orchestrierung direkt mit einem Roboter sprechen?

Das hängt davon ab, ob der Roboter sich durch geteilten Raum bewegt. Mobile Roboter brauchen Verkehrsmanagement mit harten Fristen, weshalb Orchestrierung über den Flottenmanager läuft und nie ein Fahrzeug direkt adressiert.

Bei ortsfesten Anlagen liegt der Fall anders, denn eine Roboterzelle, eine Presse oder ein Laborgerät hat kein Verkehrsproblem, sodass ein Workflow einen Auftrag über eine Hersteller-API direkt an den Controller geben und ihn an eine Bereitschaftsprüfung koppeln kann, während Sicherheit vollständig außen vor bleibt. Die Regel lautet also nicht, auf welcher ISA-95-Ebene das Ziel sitzt, sondern ob ein verspäteter Befehl einen Systemausfall verursacht oder lediglich eine Wartezeit.

Orchestrierung versus harte Echtzeitsteuerung

Das Beispiel des Flottenmanagers steht für eine Grenze, die überall in der Fertigung gilt. Event-getriebene Orchestrierung und harte Echtzeitsteuerung arbeiten beide im Millisekundenbereich und können von außen gleich aussehen, doch der Unterschied liegt nicht in der Geschwindigkeit. Eine Orchestrierungs-Engine ist schnell, wiederholt und eskaliert aber, wenn etwas zu spät kommt, während eine Sicherheits-SPS oder ein AMR-Verkehrscontroller diesen Rückfall nicht hat: Eine verpasste Frist ist dort ein Systemausfall.

Was beide trennt, sind deterministische Garantien und Sicherheitszertifizierung, und diese Unterscheidung gilt für SCADA, DCS und jeden Flottenmanager in der Halle gleichermaßen. Event-getriebene Orchestrierung reagiert in Millisekunden, harte Echtzeitsteuerung garantiert sie.

Unified Orchestration über Edge, Air-Gap und Cloud hinweg betreiben

Die Fertigung ist die schwierigste Deployment-Umgebung im Unternehmen. OT-Netze sind nach IEC 62443 in Sicherheitszonen segmentiert, manche Werke haben aus regulatorischen Gründen oder aus eigener Entscheidung überhaupt keinen Internetpfad, und konvergierte OT- und IT-Netze vergrößern die Angriffsfläche, weshalb Defense in Depth mit Segmentierung und DMZs weiterhin die Regel bleibt.

Daraus folgt unmittelbar eine Anforderung an die Orchestrierung: Die Steuerungsebene muss dort laufen, wo die Arbeit läuft, denn ein reiner SaaS-Orchestrator kann keine Workflows innerhalb eines Air-Gapped-Pharmawerks koordinieren. Die realistische Topologie ist hybrid und bidirektional, das heißt lokale Orchestrierung innerhalb des Werks übernimmt alles Latenzempfindliche oder Getrennte, die Cloud-Analytik konsumiert aggregierte Daten nach oben, und Entscheidungen, Modelle und Konfiguration fließen zurück nach unten.

Workflows auf beiden Seiten brauchen Koordination über diese Grenze hinweg, wobei das Werk autonom weiterarbeiten können muss, wenn die WAN-Verbindung ausfällt. Open Source zählt hier aus demselben Grund, denn eine selbst betriebene Steuerungsebene mit offenem Kern besteht die Souveränitäts- und Beschaffungsprüfungen, an denen eine weitere proprietäre SaaS-Abhängigkeit scheitert. In der Fertigung ist Deployment-Flexibilität damit eine Architekturanforderung und kein Komfortmerkmal.

Agentische KI auf dem Shop Floor braucht zuerst Governance

Agentische KI ist das lauteste Thema in der Industriesoftware, und die Berichte aus dem Feld fallen nüchterner aus als die Keynotes. Human-in-the-Loop bleibt eine Kernanforderung industrieller KI, weil eine falsche Entscheidung die Produktion stoppen, Anlagen beschädigen und Audit-Probleme schaffen kann. Am stärksten ist agentische KI derzeit bei Empfehlungen, Ausnahmebehandlung und überwachter Ausführung, während Multi-Agenten-Orchestrierung selten bleibt. Analysten sehen agentische KI-Plattformen dennoch als die größte neue Marktchance im Smart Manufacturing neben der Robotik.

Beide Befunde zeigen in dieselbe Richtung, denn Agenten werden über alle vier Domänen hinweg handeln:

• Ursachenanalyse: ein Agent, der eine Qualitätsabweichung zurück zu den OPC-UA-Tags korreliert, die ihr vorausgingen.

• Bildverarbeitung und Kalibrierung: ein Agent, der meldet, wenn eine Kamerastation aus der Spezifikation driftet.

• Produktionsplanung: ein Agent, der MES-Aufträge um ein ungeplantes Stillstandsfenster herum neu verteilt.

• Instandhaltungs-Triage: ein Agent, der offene Arbeitsaufträge nach Produktionswirkung ordnet, bevor ein Mensch entscheidet.

Diese Agenten analysieren Telemetrie, greifen auf Infrastruktur zu, rufen MES-APIs auf und nehmen an Geschäftsprozessen teil.

Unified Orchestration als Architektur für Smart Manufacturing

Drei Schichten übernehmen dabei drei Aufgaben. Unten bewegt event-getriebene Integration die Daten, mit OPC UA und MQTT an den Maschinen, einem Unified Namespace für die Struktur und Streaming ins Unternehmen und in die Cloud. In der Mitte entscheidet und koordiniert Workflow-Orchestrierung mit Process Intelligence, also Trigger, Abhängigkeiten, Retries, Freigaben und die Sicht darauf, wie Arbeit tatsächlich läuft. Obenauf handelt vertrauenswürdige agentische KI, geregelt und unter menschlicher Aufsicht. Der harte Echtzeit-Regelkreis bleibt neben allen dreien unangetastet.

Die gute Nachricht für Hersteller lautet, dass auf dem Shop Floor nichts ersetzt werden muss, denn das MES, der Flottenmanager, der Historian und die Python-DAGs bleiben alle. Was fehlt, ist die verbindende Schicht, die sie als ein System koordiniert, von der Änderung eines OPC-UA-Tags bis zur SAP-Bestätigung und über Edge, Air-Gap und Cloud hinweg. Fangen Sie mit einem Workflow an, der eine Silogrenze quert, stellen Sie ihn unter Versionskontrolle und Governance, und wachsen Sie von dort aus weiter. Die Werke, die Koordination beherrschen und nicht nur Automatisierung, werden das Tempo vorgeben.

Wie das in Ihrer Umgebung aussieht, zeigen wir am konkreten Workflow: Demo mit unserem Team vereinbaren.