Bei einer vernetzten Maschine ist es nicht so, dass sie, einmal ausgeliefert, weitgehend unverändert sich selbst überlassen wird. Stattdessen bleibt sie über ihre gesamte Laufzeit hinweg per Netzwerk mit dem Hersteller verbunden. In dieser Zeit entstehen neue Sicherheitslücken in der eingesetzten Software, die bei der Entwicklung schlichtweg noch nicht bekannt waren. Mit dem Cyber Resilience Act und der NIS-2-Richtlinie wird die Pflicht, diese Lücken zu schließen, zur gesetzlichen Anforderung. Damit stellt sich für Hersteller eine klare Frage: Wie lassen sich Sicherheits- und Funktionsupdates kontrolliert, nachvollziehbar und ohne ungeplante Stillstände in laufenden Produktionsumgebungen ausrollen?
Updates in der Produktion
Diese Frage stellt sich vor allem deshalb, weil vernetzte Geräte in der Produktion unter ganz anderen Bedingungen betrieben werden als typische IT-Systeme. Eine Anlage kann nicht einfach für ein Update angehalten werden. Jeder ungeplante Stillstand kostet Geld und ein fehlerhaftes Update kann im schlimmsten Fall dazu führen, dass eine Maschine danach gar nicht mehr anläuft. Hinzu kommt die Realität gewachsener Maschinenflotten: Geräte unterschiedlichen Alters, mit unterschiedlichen Softwareständen, verteilt auf Standorte, Länder und Kunden. Updates müssen deshalb gezielt ausgerollt werden: Ein Softwarepaket, das auf einer Anlage problemlos läuft, kann auf einer anderen – etwa wegen eines anderen Softwarestands – zu Problemen führen. Hersteller müssen also genau festlegen können, welche Geräte ein Update erhalten und in welcher Reihenfolge. Dafür brauchen sie zunächst den Überblick, welcher Softwarestand auf welchem Gerät vorliegt. Wer diesen Überblick zentral pflegt, hat zugleich die Dokumentation, die CRA und NIS-2 einfordern.
Updates in der Praxis
Den Ausgangspunkt bildet ein Softwarepaket wie ein Sicherheitspatch, eine Funktionserweiterung oder ein Update für die Steuerungssoftware. Bevor dieses Paket ausgerollt wird, legt der Hersteller fest, welche Geräte es überhaupt betrifft. Das geschieht regelbasiert: etwa nur Geräte mit einem bestimmten Softwarestand, nur eine bestimmte Maschinenvariante oder nur Anlagen an einem bestimmten Standort. Der eigentliche Rollout startet dann nicht flächendeckend, sondern in Wellen. Eine Lösung wie der Update Manager von Double-Slash, Software- und IoT-Dienstleister aus Friedrichshafen, unterstützt genau diesen Prozess: Zunächst erhält eine kleine Testgruppe – z.B. einige Geräte im eigenen Haus oder bei einem ausgewählten Kunden – das Update. Erst wenn sich dort zeigt, dass alles wie erwartet funktioniert, wird der Kreis zunächst auf einen Standort und dann schrittweise auf die gesamte Flotte erweitert. Während des gesamten Prozesses behält der Hersteller den Status jedes einzelnen Geräts im Blick: Wurde das Paket übertragen? Wurde es vom Gerät angenommen? Wurde die Installation erfolgreich abgeschlossen? Genau hier zeigt sich der Mehrwert für die Produktion: Statt wie bisher in Excel-Tabellen herauszufinden, welches Gerät welchen Softwarestand hat, liefert eine zentrale Plattform diese Statusinformationen in Echtzeit – gegliedert nach Kampagnen, Gerätegruppen und Einzelgeräten. Bleibt ein Gerät bei einem dieser Schritte hängen, etwa weil es offline ist oder die Installation wiederholt fehlschlägt, wird das sofort sichtbar. Bei wiederholt fehlgeschlagenen Installationsversuchen kann der Verantwortliche dann gezielt reagieren, statt blind eine weitere Aktualisierung anzustoßen. Stellt sich heraus, dass ein ausgeliefertes Paket fehlerhaft ist, lässt sich der Rollout auch kurzfristig stoppen. Betroffene Geräte können automatisch oder gezielt auf die vorherige Version zurückgesetzt werden, ohne die übrigen Geräte zu beeinflussen. Gerade dieser Rollback-Mechanismus ist für den Produktionsbetrieb entscheidend: Ohne ihn besteht das Risiko, dass ein fehlerhaftes Update installiert wird und eine Anlage anschließend gar nicht mehr betriebsbereit ist.
Entscheidung und Umsetzung
Mit der Einführung eines zentralen Update-Managements verändert sich auch, wer im Unternehmen für Updates verantwortlich ist. Eine Lösung wie der Update Manager ist dabei bewusst als Brücke zwischen IT und OT konzipiert: Die IT erhält eine zentrale Steuerungsebene für Rollout-Management, Freigabe-Workflows und Audit-Trails, während operative Teams vor Ort Rollout-Fenster und Zielgruppen definieren – etwa bestimmte Anlagentypen oder Standorte. Treiber ist häufig das Produktmanagement: Es trägt die Verantwortung für ein Produkt über dessen gesamte übliche Lebensdauer und damit auch für dessen Update-Fähigkeit. Die operative Durchführung liegt hingegen häufig bei der Serviceorganisation. Deren Rolle verschiebt sich in diesem Zuge: Wo früher Servicetechniker für jedes Update zum Kunden vor Ort fahren mussten, lösen sie Updates heute remote über die zentrale Plattform aus, verfolgen den Status der Kampagne und greifen nur dann persönlich ein, wenn ein Gerät tatsächlich Probleme bereitet. Aus einer ressourcenintensiven Vor-Ort-Tätigkeit wird so eine zentrale Steuerungs- und Kontrollaufgabe, die sich auch bei wachsenden, heterogenen Geräteflotten effizient skalieren lässt.
