Das Problem
Die Software auf der Anlage wird bei der Inbetriebnahme aufgespielt. Danach fährt entweder ein Techniker hin, oder sie bleibt, wie sie ist. Nach ein paar Jahren läuft auf jedem Gerät eine etwas andere Version, und niemand weiß genau, welche.
Dazu kommt das Netz. Ihre Kunden schotten ihre Produktionsnetze ab, Verbindungen brechen ab, Ports sind gesperrt. Eine Lösung, die dauerhaft mit der Cloud verbunden sein muss, scheitert dort.
Embedded Linux, Geräteidentität und OTA-Updates
Auf dem Edge-Gerät läuft ein schlankes Embedded Linux, die Anwendung läuft in Containern. Das Gerät liest die Daten der Steuerung, verarbeitet sie vor Ort und erledigt seine Aufgabe auch ohne Verbindung. Daten werden gepuffert und übertragen, sobald das Netz wieder da ist.
Jedes Gerät bekommt bei der Inbetriebnahme eine eigene Identität: Schlüssel, Seriennummer, Zuordnung zur Anlage. Damit wissen Sie, welches Gerät spricht, und können es gezielt aktualisieren oder sperren.
Updates für Betriebssystem und Anwendung kommen per OTA. Die Build-Pipeline baut Multi-Arch-Images, auch für ARM, versioniert jede Auslieferung und bringt sie vom Commit bis aufs Gerät. Ausgerollt wird schrittweise: erst ein Testgerät, dann eine kleine Gruppe, dann die Flotte.
Ein Inventar zeigt, welche Version auf welchem Gerät läuft und wie es konfiguriert ist. Das ist die Grundlage, um Schwachstellen später gezielt zu schließen.
Was Sie bekommen
- ein Geräte-Image mit dokumentiertem Provisioning für die Inbetriebnahme
- eine Build- und Update-Pipeline in Ihrer GitLab-Instanz oder Ihrer CI
- eine Rollout-Strategie, die zu Ihren Kunden und Servicezeiten passt
- eine Übersicht über die Flotte: Versionen, Konfiguration, Zustand
- auf Wunsch den laufenden Betrieb, sonst eine Übergabe an Ihr Team
Grenzen
Wir übernehmen alles ab der Steuerung. Das SPS-Programm, Elektrik und Sensorik bleiben bei Ihnen oder unserem Partner aus der Automatisierungstechnik. Die Hardware wählen Sie, wir beraten dabei. Eine Zertifizierung nach IEC 62443 bieten wir nicht an.