Lifecycle stage — Build
Die KI, die in einem physischen System läuft, ist ein anderes Ingenieursproblem als die KI, die in einer Cloud läuft. Ein Modell, das auf einer SPS in einer Produktionslinie, einem ECU in einem Fahrzeug, einem Rechenknoten in einer Umspannstation oder einem Flugsteuercomputer in einer Drohne eingesetzt wird, muss Echtzeit-SLAs einhalten, Netzwerkpartitionen überstehen, Sicherheitsenveloppen respektieren, die Ihre Zertifizierungsingenieure prüfen werden, und auf Hardware laufen, deren Kosten durch das genehmigte Betriebsbudget gedeckt sein muss. Generische Cloud-KI-Beratungsunternehmen können diese Arbeit nicht leisten — die Referenzarchitekturen gelten nicht und die Teams haben noch keinen Sicherheitsingenieur getroffen. Das ist die Build- und Ship-Phase des Hyperion-Lebenszyklus, angepasst für physische Systeme: ein 16-wöchiges eingebettetes Engagement.
Ihre Cloud-first-Datenplattform wurde nie darauf ausgelegt, ein Modell auf eine Robotik-SPS, ein Fahrzeug-ECU, einen AGV-Flotten-Controller oder einen Umspannstations-Rechenknoten zu übertragen — und ein Nachrüsten ist ein eigenständiges Dreivierteljahresprojekt. Der MLOps-Stack, den Ihr Team aufgebaut hat, setzt elastische Cloud-Inferenz, Netzwerkkonnektivität und Hardware voraus, die Sie überprovisionieren können.
Sicherheits- und Zertifizierungsingenieure haben Vetorecht und Sie haben keinen Prozess, der die benötigten Nachweise liefert. Das Modell funktioniert in der Simulation. Ihr Sicherheitsingenieur fordert die Hazardanalyse, die Fehlermodusabdeckung, die Envelope-Verletzungstests und die Nachweiskette, die eine Zertifizierungsüberprüfung nach ISO 26262 (ASIL), IEC 61508 (SIL), DO-178C für Drohnenavionik oder ISO 10218 für Robotersicherheit überstehen wird.
Ihr KI-Team und Ihr Betriebsteam sprechen verschiedene Sprachen, und ihre Ticket-Systeme kommunizieren nicht miteinander. Die Datenwissenschaftler sprechen in F1-Scores, Validierungssets und Modellkarten. Die Betriebsingenieure sprechen in OEE, MTBF, SPS-Scan-Zyklen, Fahrzeugbus-Timing und AGV-Pfadkonflikt-Raten.
Das Modell funktioniert im Labormaßstab und bricht zusammen, wenn es zum ersten Mal einem echten Sensor mit der falschen Kalibrierungsdrift begegnet. Die Robotikzelle in der Produktion hat eine Wärmeverzerrung, die niemand modelliert hat, eine Firmware-Version, die Ihr Team nicht kannte, und einen intermittierenden Encoderfehler, den das Wartungsteam seit drei Jahren toleriert.
Das Engagement läuft in vier vierwöchigen Phasen. Ich arbeite in der ersten und letzten Phase vor Ort und dazwischen remote eingebettet. Ihre Engineering-, Sicherheits- und Betriebsteams haben alle zugewiesene Zeit. Das Ergebnis ist ein Einsatz, der auf der Produktionshardware läuft, unter dem Sicherheitsregime, integriert in den Betriebsstack.
Strukturierte Sitzungen mit dem Sicherheitsingenieursteam, dem Zertifizierungsleiter, den Betriebsingenieuren, die das System betreiben werden, und dem ML-Team, das den Pilot aufgebaut hat. Wir dokumentieren die Sicherheitsenveloppe, die relevanten Fehlermodi, die erforderlichen Zertifizierungsnachweise (per ISO 26262 / IEC 61508 / DO-178C / ISO 10218 / EU-KI-Gesetz Anhang III nach Bedarf), die Hardware-Constraints, die Netzwerktopologie und die operationellen SLAs. Ende Woche vier haben wir ein schriftliches Constraint-Dokument, das der Sicherheitsingenieur unterzeichnet.
Die Modellarchitektur und das Trainingsrezept werden für die Hardware und Sicherheitsenveloppe neu gestaltet: Quantisierungsstrategie, Latenzbudget, Speicher-Footprint, deterministisches Verhalten wo Sicherheit es erfordert, graceful Degradation bei Sensorfehler. Wir führen Ablationen auf echter Hardware durch — dem Ziel-Robotik-Controller, dem Fahrzeug-ECU, dem AGV-Rechenboard — nicht in Simulation.
Das Modell integriert sich mit dem industriellen oder Fahrzeugstack auf echter Hardware — SPS-Programmierumgebung, OT-Netzwerk, Fahrzeug-CAN/Ethernet-Bus, AGV-Flottenmanagement-System, UAS-Flugsteuerungsschnittstelle oder Umspannstations-Automatisierungsrelais. Ende Woche zwölf läuft das Modell auf Produktionshardware in einer kontrollierten Pilotzone.
Das Betriebsteam besitzt den Einsatz. Wir erstellen die Runbooks, die Alarmschwellenwerte, die Modell-Performance-Dashboards und die Rollback-Playbooks. Wir expandieren von der Pilotzone zum Produktions-Footprint — Zelle für Zelle, AGV für AGV, Fahrzeug für Fahrzeug, Standort für Standort — mit der Unterschrift des Sicherheitsingenieurs für jede Expansion.
Hersteller, die KI in Robotikzellen oder AGV/AMR-Flotten einsetzen. Automotive-OEMs und Tier-1-Lieferanten, die KI in ADAS- oder AD-Stacks unter ISO 26262 und UNECE R155/R156 integrieren. Energieversorger, die prädiktive KI an Umspannstationen oder am Netzrand unter IEC 62443 einsetzen. Luft- und Raumfahrtprimes, die KI in UAS-Autonomiestacks unter DO-178C oder EASA-Frameworks integrieren. Kein Angebot für reine Softwareunternehmen — diese benötigen den Agentic System Engineering-Service.
Neben ihnen, mit klaren Umfangsgrenzen. Ihr Automatisierungspartner besitzt die SPS-Programmierumgebung, das OT-Netzwerk und die Betriebsintegrationsschicht. Ich besitze die Modellarchitektur, den Edge-Inference-Einsatz, die Zertifizierungs-Nachweiskette und den Sicherheitsprozess.
Das Engagement erzeugt die Zertifizierungs-Nachweiskette — Hazardanalyse, Fehlermodusabdeckung, Envelope-Verletzungstests — die der Norm entspricht, nach der Ihr Sicherheitsingenieur arbeitet. Ich bin keine Zertifizierungsstelle und ersetze nicht Ihren Sicherheitsingenieur. Ich verwechsle keine Cybernormen (UNECE R155/R156) mit Funktionssicherheitsnormen (ISO 26262/IEC 61508).
Ja — und oft muss es das. Ein Modell, das auf einem Fahrzeug-ECU, einer entfernten Umspannstation, einem AGV in einer GPS-verweigerenden Lagerzone oder einer UAS, die außerhalb der Funkreichweite operiert, läuft, muss während Netzwerkpartitionen operieren und den Zustand synchronisieren, wenn die Verbindung zurückkehrt.
Was auch immer Ihr Betriebsteam in den nächsten zehn Jahren genehmigen und warten wird. In Woche eins identifizieren wir die realistische Hardware-Enveloppe — was die Beschaffung kaufen, was der Betrieb installieren und was die Wartung warten wird.
Nicht nennenswert. Die vier Phasen repräsentieren jeweils eine andere Disziplin — Sicherheit, ML-Engineering, industrielle Integration, Betrieb — und jede braucht die Zeit, die sie braucht. Die einzige Stelle, wo ich manchmal Zeit sparen kann, ist wenn ein bestehender Automatisierungspartner bereits erhebliche Integrationsarbeit geleistet hat.
Entdecken Sie weitere Services, die dieses Angebot ergänzen
30 Minuten. Ich diagnostiziere Ihre Situation und sage Ihnen ehrlich, ob dieser Service passt — und wenn nicht, welcher.