Jeder Roboter, jede Rezeptur, jeder Modelljahreswechsel – alles unter Versionskontrolle.

Octoplant x Automotive OEM Anwendungsfall #1

Beispielprofil

Ein Fahrzeughersteller betreibt elf Montagewerke in drei Regionen. In jedem Werk werden während eines fest definierten Sommerstillstands Teile des Karosseriebaus, der Lackiererei und der Endmontage für den Modelljahreswechsel umgebaut. Die Arbeiten werden von internen Engineering-Teams und externen Integratoren durchgeführt – häufig nachts und unter hohem Zeitdruck. Der Termin für den Produktionsanlauf steht fest und kann nicht verschoben werden.

Was heute nicht funktioniert.

Ein Modellwechsel bedeutet Tausende von Konfigurationsänderungen innerhalb weniger Wochen: Roboterbahnen, Schweißparameter, Drehmomentprofile, Fördertechnik-Logik und Sollwerte von Vision-Systemen. Innerhalb weniger Tage können dokumentierter und tatsächlich laufender Stand voneinander abweichen – ohne dass dies während der laufenden Produktion auffällt.

Das Problem zeigt sich oft erst später: Im Oktober fällt eine Steuerung aus. Das vermeintlich „aktuelle“ Programm, das eingespielt wird, ist bereits drei Revisionen alt – und aus einer zweistündigen Reparatur wird die Rekonstruktion einer ganzen Schicht. Oder die Qualitätswerte nach dem Produktionsanlauf erreichen nicht das gewünschte Niveau und niemand kann nachvollziehen, was sich zwischen dem funktionierenden Stand vom Dienstag und dem fehlerhaften Stand vom Donnerstag geändert hat.

Was sich mit Octoplant ändert.

Unterstützte Konfigurationsänderungen werden in der Versionshistorie erfasst und können verantwortlichen Benutzern, Zeitstempeln und dokumentierten Änderungsgründen zugeordnet werden. SmartCompare macht relevante Unterschiede zwischen Versionen sichtbar und hilft Teams, geplante Engineering-Änderungen von Abweichungen zu unterscheiden, die untersucht werden müssen.

Abweichungen von der freigegebenen Baseline werden erkannt, statt erst später entdeckt zu werden. Eine fehlerhafte Änderung zurückzusetzen wird damit zum definierten Wiederherstellungsprozess statt zur aufwendigen Fehlersuche. Zugriffe externer Integratoren lassen sich über Berechtigungen eingrenzen und ihre Änderungen nachvollziehbar dokumentieren – eine belastbare Grundlage, wenn sich eine Anlage nach einem Wochenende plötzlich anders verhält.

Was es wert ist.

Dafür nennen wir keine erfundene Zahl – die Rechnung lässt sich mit den eigenen Produktionsdaten aufstellen. Multipliziert werden die eigene Produktionsrate und Marge pro Einheit mit der Zeitdifferenz zwischen dem Rekonstruktionsaufwand beim letzten Produktionsanlauf und einer Wiederherstellung innerhalb weniger Minuten. Anschließend wird das Ergebnis mit der Anzahl solcher Vorfälle pro Anlauf multipliziert. Diese Berechnung bildet den individuellen Business Case. Der Mechanismus dahinter ist eindeutig: Die Kosten einer nicht dokumentierten Änderung entstehen zu einem großen Teil dadurch, herausfinden zu müssen, was überhaupt geändert wurde.

Octovision x Automotive OEM Anwendungsfall #3

Beispielprofil

Ein konzernweites Information-Security-Team, das gegenüber dem Management für OT-Risiken in elf Werken verantwortlich ist, diese jedoch nicht selbst betreibt. Die Werke befinden sich in drei unterschiedlichen regulatorischen Rechtsräumen – und das Team hat weder das Mandat, Agents zu installieren, noch Produktionsnetzwerke aktiv zu scannen.

Was heute nicht funktioniert.

Die Konzernzentrale fragt jedes Werk, welche Systeme dort im Einsatz sind. Zurück kommen elf Tabellen in fünf verschiedenen Formaten und mit unterschiedlich aktuellen Datenständen. Daraus lässt sich keine belastbare, konzernweite Aussage ableiten. Einigkeit besteht nur in einem Punkt: Aktives Scanning im Karosseriebau wird nicht freigegeben.

Was sich mit Octovision ändert.

Octovision baut die standortübergreifende Sicht auf den Konfigurationsdaten auf, die Octoplant bereits für Backup und Versionierung erfasst – darunter Hersteller, Gerätetyp, Firmware-Version und Lifecycle-Status.
Diese operativen Daten werden in Octovision zu einer unternehmensweiten Sicht auf Assets, Komponenten, Backup-Jobs, Konfigurationsinformationen, Lifecycle-Daten und bekannte Schwachstellen zusammengeführt. Schwachstelleninformationen werden um Risikokontext ergänzt. So können Teams Findings priorisieren, statt jede CVE als gleichermaßen dringend zu behandeln. Keine Agents. Keine Probes. Kein zusätzlicher Netzwerkverkehr. Die zugrunde liegende Analyse in Octovision erfordert kein aktives Scanning der Produktionsgeräte. Dadurch muss nicht allein für die unternehmensweite Transparenz zusätzlicher Traffic in der Produktionsumgebung erzeugt werden. Reports lassen sich nach Standort, Region oder Geräteklasse filtern und per CSV, JSON oder Open API in SIEM-, CMDB- oder Ticketing-Systeme exportieren – dorthin, wo die Security-Prozesse bereits stattfinden.

Was es wert ist.

Der Wert bemisst sich nicht allein in eingesparten Sekunden Produktionsstillstand. Er zeigt sich auch in weniger Stunden manueller Berichterstellung, früher erkannten Lücken, gezielterer Behebung kritischer Risiken und Managemententscheidungen auf Basis aktueller Betriebsdaten statt elf inkompatibler Tabellen.

Die Rechnung lässt sich mit den Daten der eigenen Organisation aufstellen: Wie viel Zeit investieren Werk- und Security-Teams in das Zusammenstellen von Asset-Inventaren, das Abgleichen von Tabellen, die Validierung von Findings und die Erstellung von OT-Risikoberichten? Und wie viel davon entsteht nur, weil die zugrunde liegenden Betriebsdaten nicht zentral verfügbar sind?

Unternehmensweite Transparenz macht Reporting von einer wiederkehrenden Datensammlung zu einer operativen Fähigkeit.