© PisitKhambubpha, 123RF

Während große IT-Unternehmen bereits von Edge-Infrastrukturen träumen, sieht die Realität oft anders aus: Ohne Open-Source-Support haben industrielle Steuerkomponenten bis zum Edge-Einsatz noch einen steinigen Weg vor sich, glaubt Autor Christofer Dutz.

Egal, ob cloudbasierte Fitness-Tracker, intelligente Lautsprecher oder ferngesteuerte Heizkörper: Edge Computing hält in immer mehr Haushalten Einzug. Ganz anders sieht es nach meiner Erfahrung in der IT-Landschaft im industriellen Umfeld aus (auch Operational Technology genannt, kurz OT).

Wer sich hierhin verwirrt, glaubt häufig, eine Reise in der Zeitmaschine hinter sich zu haben: An vielen Stellen sieht diese Welt noch so aus wie die IT-Welt vor etwa 15 bis 20 Jahren. Im Jurassic Park der IT ist Windows das vorherrschende System. In freier Wildbahn tummeln sich nicht nur Windows 7, 2000 und XP, sondern teilweise sogar noch Windows 95 und Windows CE. Windows 10 oder ein modernes Windows-Server-System habe ich in diesem Umfeld bislang nie angetroffen – geschweige denn Linux.

Der Grund dafür liegt in der Regel darin, dass die auf den Rechnern laufende Software nicht auf neueren Windows-Versionen funktioniert. Um die Sache spannender zu machen, sind die Systeme häufig nicht auf dem aktuellen Patchlevel, sondern hinken diesem oft nicht nur um Monate hinterher, sondern eher um Jahre.

Ein Beispiel: Ende 2017 machte ich mich daran, das damals aktuellste TIA-Portal 13 von Siemens zu installieren. TIA-Portal steht für Totally Integrated Automation Portal, eine IDE, mit der Entwickler Software für Siemens-Steuerungen (siehe Kasten “SPS”) programmieren.

Abbildung 1: SPS kommen in der Industrie zum Steuern von Anlagen zum Einsatz, finden sich aber durchaus auch in Privathaushalten. Quelle: Sorapol Ujjin, 123RF

Um die Software in Betrieb zu nehmen, musste ich zunächst eine VM mit Windows 7 (32 Bit) aufsetzen. Dabei durfte ich kein Service-Pack oder Update einspielen, da die Installation sonst fehlgeschlagen wäre. Das Release-Datum von Windows 7 war der Oktober 2009; folglich musste ich mit einem Betriebssystem arbeiten, das 8 Jahre lang kein Update erhalten hatte.

Ausfallsicherheit habe ich bisher nur bei Kontrollsystemen zum Überwachen und Steuern wichtiger Produktionsanlagen gesehen, die auch SCADA-Systeme heißen (für Supervisory Control and Data Acquisition [2]). Hier stellen die Admins Ausfallsicherheit meist durch einfache Redundanz her. Fällt eine Einheit aus, aktivieren sie deren Backup, das die Rolle des ausgefallenen Systems übernimmt.

Updates erhalten die Systeme – wenn überhaupt – nur während eines sogenannten Shutdowns. Dabei handelt es sich üblicherweise um sehr intensiv geplante und vorbereitete Phasen von teils bis zu mehreren Wochen. In diesen Phasen halten die Mitarbeiter die komplette Produktion an, um die Anlagen und IT-Systeme zu modifizieren, zu warten und zu aktualisieren.

Allerdings sparen sich Betreiber solche aufwendigen IT-Updates gern – nicht nur, weil die Produktion darunter leidet, sondern weil sie nicht selten das Erlöschen der Betriebserlaubnis zur Folge haben. In Industrien, die zum Beispiel Lebensmittel oder Arzneien herstellen, gelten strenge Compliance-Regeln. Aktualisierungen sorgen hier unter Umständen dafür, dass die entsprechenden Aufsichtsbehörden eine Anlage komplett neu abnehmen müssen.

In diesem Umfeld mit Linux, virtuellen Maschinen, Containern oder der Cloud zu argumentieren, sorgt meist für großes Unverständnis. Selbst wenn beim Begriff Cloud alle Mitarbeiter eifrig nicken, können sich nur wenige vorstellen, dass auf den dahinterstehenden Systemen heute meist Linux läuft und kein Windows.

Zu viele Daten

Möchten Unternehmen ihre Geräte, die sich “im Feld” (oder am Edge) befinden, an das eigene Netzwerk anbinden, entpuppen sich die dabei anfallenden Datenmengen als weitere Hürde. Im Zeitraum von einer halben bis fünf Sekunden sammelt ein Admin üblicherweise 1000 bis 3000 unabhängige Datenpunkte pro SPS ein – das macht bei größeren Setups Probleme.

In einem Projekt ging es beispielsweise darum, alle zwei Sekunden 2600 Datenpunkte von einer SPS zu erhalten. Das allerdings sollte zeitgleich auf 26 000 SPS weltweit passieren. Angenommen, pro Datenpunkt kommen 2 Byte plus 6 Byte Protokoll-Overhead zusammen – das wäre ein Datenvolumen von knapp 15 GByte pro Minute. Die entsprechende Internet-Verbindung muss ein Unternehmen sich erst einmal leisten wollen.

Selbst wenn sich die SPS auf nur sieben Werke weltweit verteilen, fällt noch immer eine große Menge an Daten an, die das Unternehmen übertragen, speichern und sinnvollerweise auch noch verarbeiten muss. Im Beispiel kämen so etwa 21,6 TByte pro Tag und ungefähr 7900 TByte pro Jahr zusammen. Das ist kein Data Lake mehr, sondern eher ein Data Ocean.

Als weiteres Problem erweist sich, dass viele Produktionsstätten an Orten liegen, die sich – jedenfalls zum heutigen Zeitpunkt – häufig schon glücklich schätzen, wenn sie über eine Modem-artige Verbindung im Kilobit-Bereich verfügen. Dabei ist ein lokales Vorverarbeiten und Filtern der Daten in der Regel unumgänglich. Mitunter ergibt es da sogar Sinn, die Daten regelmäßig mit einer Festplatte abzuholen.

Sicher, aber unsicher

Selbst wenn die Verfügbarkeit einer Breitband-Internet-Verbindung kein Problem bereitet, macht oft die Sicherheit einen Strich durch die Rechnung. Unsichere Produktionsanlagen an eine Cloud-Lösung zu koppeln, entpuppt sich in der Regel als schlechte Idee. So spuckt die unter Hackern beliebte IoT-Suchmaschine Shodan eine große Menge an S7-SPS von Siemens aus, die Angreifer potenziell übernehmen könnten (Abbildung 2). Während Entwickler mit aktuellen SPS zwar sehr unfallsichere Maschinen bauen (im Sinn von Safety), sind diese oft zugleich extrem unsicher (wie in Security).

Abbildung 2: Viele SPS lassen sich via Internet erreichen. Sie zu finden, braucht es lediglich eine spezialisierte Suchmaschine wie Shodan (Symbolbild). Quelle: Witoon Muenhong, 123RF

Bei einigen Steuerungen lässt sich zum Beispiel das komplette Programm ohne jegliche Authentifizierung austauschen. Passiert das, so nutzt es nur wenig, dass die ursprüngliche Software nur dann die Presse auslöst, wenn sich keine Hand unter dem Stempel befindet. Der Angreifer lädt dann einfach eine modifizierte Version der Software hoch, die diesen Check abstellt.

Das ist nicht ganz weit hergeholt: Stuxnet, der 2010 entdeckte Computerwurm, befiel unter anderem die Simatic S7 von Siemens. Er spielte zudem eine berüchtigte Rolle im Zusammenhang mit der Sabotage iranischer Anlagen für die Urananreicherung. Eine SPS direkt ans Netz zu hängen, halte ich aus diesem Grund für keine gute Idee, die Kombination aus Cloud Native und Industrie-Steuerungen für brandgefährlich.

Um auf die sichere Seite zu gelangen, gibt es meiner Meinung nach zwei Optionen: Entweder betreiben die Industrieunternehmen eine Cloud vor Ort, innerhalb des Produktionsnetzes, oder sie führen eine zusätzliche Ebene ein, die das Produktionsnetz vom restlichen Netz trennt: einen Edge-Layer.

Letzteres erscheint als wesentlich bessere Lösung. Auf dieser Ebene kann das Unternehmen Daten vorverarbeiten und somit das benötigte Datenvolumen für die Cloud-Verbindung minimieren. Gleichzeitig lassen sich die SPS so von unsicheren Netzen entkoppeln.

Änderungsversuche

Die IT-Umbrüche der letzten Jahre sind an den Herstellern der klassischen Automatisierungstechnik nicht ganz spurlos vorübergegangen. Auch sie sehen durchaus, dass die moderne IT ein gigantisches Potenzial für Produkte und Dienstleistungen in ihrem Sektor bietet.

Allerdings wissen die meisten wohl zugleich, dass die unter dem Stichwort Industrie 4.0 (siehe Kasten “Industrie 4.0”) verhandelten Themen nicht unbedingt zu ihrer Kernkompetenz zählen. Wer bis 2015 noch komplett in einer Windows-Blase lebte und monolithische Systeme baute, für den klingen Begriffe wie Container, Public und Private Cloud oder Big Data nach “Neuland”.

Im Kaufrausch

In der Regel fehlen solchen Firmen das Personal und das Know-how, um in diesem Sektor Lösungen zu entwickeln. In der Folge verging 2017 kaum eine Woche, in der nicht ein Big Player wie Siemens, Schneider Electric oder Rockwell ein relativ unbekanntes Unternehmen für eine unvorstellbare Summe kaufte.

Auf Basis dieser Käufe versuchten die Hersteller dann innerhalb kürzester Zeit, eigene Industrie-4.0-Produkte auf den Markt zu bringen. Am Ende entstanden bei so ziemlich allen dieser Initiativen proprietäre Cloud-Plattformen. Oftmals vertreiben die Unternehmen diese zusammen mit sogenannten Edge-Gateways, die allerdings selten eine nennenswerte Datenvorverarbeitung vornehmen. Vielmehr pumpen sie meist nur die Maschinendaten ihrer eigenen Automatisierungsprodukte in ihre eigenen Cloud-Lösungen – der Vendor-Lock-in bleibt so bestehen.

Allerdings vertreiben die Hersteller ihre neuen Produkte nicht wie übliche IT-Lösungen, sondern eher wie die anderen Produkte und Dienstleistungen in der Automatisierungstechnik. Schon für das reine Experimentieren mit den Industrie-4.0-Lösungen der großen Anbieter müssen die Kunden üblicherweise fünfstellige Beträge für Lizenzen pro Entwickler und Jahr in die Hand nehmen. Um die Industrie von ihren Produkten zu überzeugen, stecken die Unternehmen zudem sehr viel Geld in ein teilweise sehr aggressives Marketing.

Quo vadis?

Nach einer Aufbruchsstimmung 2018 erscheint es mir persönlich so, als hätten die Big Player 2019 ihren Ruf inzwischen teilweise beschädigt. Trotz einiger intensiv vermarkteter Erfolgsgeschichten traf ich 2019 zunehmend auf desillusionierte Kunden. Ihre Enttäuschung rührte einerseits von wenig erfolgreichen Versuchen her, ihre Lösungen mit den neuen Produkten umzusetzen. Andererseits war sie nicht selten die Folge einer intensiven Auseinandersetzung mit den proprietären Lizenzbestimmungen der neuen (Cloud-)Produkte.

OPC UA, der Heilige Gral?

Dass es auch anders geht, als proprietäre Silos zu bauen, zeigt das offene OPC-UA-Protokoll, das unter dem Dach der OPC-Foundation [3] entwickelt wurde und zur Maschine-zu-Maschine- beziehungsweise PC-zu-Maschine-Kommunikation dient. 2009, also vor ziemlich genau 10 Jahren, wurden die Kernelemente von OPC UA als IEC-Norm (IEC 62541) akzeptiert. Das Protokoll soll die einheitliche Kommunikation in der Industrie gewährleisten, und war ursprünglich nur den Mitgliedern der OPC Foundation zugänglich, die aber so ziemlich jeden ernstzunehmenden Hersteller industrieller Hardware an Bord hat.

In den folgenden 10 Jahren entwickelte die Organisation IEC 62541 weiter [4] und schuf so einen umfassenden Standard, der die Zukunft der industriellen Vernetzung prägen könnte. Im Herbst 2018 wurde zudem ein Publish- und Subscribe-Mechanismus ergänzt, wie ihn etwa MQTT nutzt. Das ist aus meiner Sicht eine gute Lösung, weil das bis dahin gebräuchliche Polling große Last auf den SPS erzeugte.

Tatsächlich geht OPC UA im Gegensatz zu den meisten anderen Industrieprotokollen einen Schritt weiter. Es beschreibt nicht nur den eigentlichen Austausch von Daten zwischen zwei Geräten, es kümmert sich auch um die Semantik der Daten. So ermöglicht es OPC UA den Geräteherstellern, genormte Daten untereinander auszutauschen.

Dennoch ist es fraglich, ob OPC UA eine Lösung für die momentan vorherrschenden Probleme bietet oder ob es nicht eher einen (vielversprechenden) Ansatz für eine Zukunft darstellt, in der die Branche noch nicht angekommen ist. Aktuellen Zahlen zufolge [5] bieten zwar 98 Prozent der Hersteller OPC-UA-fähige Lösungen an [6], allerdings unterstützten Mitte 2019 lediglich 25 Prozent der aktuell verkauften SPS den noch jungen Standard.

Das lädt zu einem Gedankenspiel ein. Angenommen, dass seit einem Jahr ein Viertel aller verkauften SPS einen Support für OPC UA mitbringen. Bei einer mittleren Betriebszeit einer Produktionsanlage von 15 bis 25 Jahren liegt die durchschnittliche Betriebszeit bei 20 Jahren. In diesem Fall wären rein rechnerisch 5 Prozent der aktuell betriebenen Anlagen in diesem letzten Jahr gebaut worden und würde damit neue SPS erhalten. Bekämen davon ein Viertel OPC-UA-Support, wären dennoch nur ein kleiner Prozentsatz der weltweit betriebenen Anlagen damit ausgestattet. Das halte ich noch nicht wirklich für eine Verbreitung, bei der es sich lohnt, sich allein auf diesen Standard zu konzentrieren.

Die Industrie verkauft OPC UA aktuell jedoch als Lösung für sämtliche Probleme, so etwa auf der diesjährigen SPS in Nürnberg Ende November 2019, einer der weltgrößten Messen für Automatisierungstechnik. Dort kam kaum ein Stand ohne Werbung für OPC-UA-Support aus.

Neben der mangelnden Verbreitung scheint die Performance der OPC-UA-Lösungen fast noch ein größeres Problem. So ließen sich zum Beispiel in einem Projekt mit dem nativen Protokoll einer Steuerung 2600 unabhängige Datenpunkte in nur 200 Millisekunden abgreifen, ohne die angeschlossene SPS signifikant mehr zu belasten. Dieselbe Steuerung ging beim Zugriff via OPC UA, den der Hersteller der SPS implementiert hatte, wegen Überlast in Störung, sobald die Abfrage mehr als 200 Datenpunkte in zwei Sekunden überschritt. Das wirkt fast so, als hätte der Hersteller seine eigene Schnittstelle nicht ausprobiert. Für Machine Learning, Deep Learning oder andere Tasks, die im Edge-Bereich eine Rolle spielen, eignet sich OPC UA daher aus meiner Sicht noch nicht.

Open was?

Es erfordert also noch einige Innovationen auf Seiten der industriellen Operational Technology (OT), um die traditionellen Anlagen fit für die Industrie 4.0 zu machen. Dabei gibt es bereits heute diverse Edge- und IoT-Lösungen, auch für so ziemlich alle Themengebiete der OT. Dazu gehören ausgereifte Cloud- und Container-Lösungen, Virtualisierung, Big Data und Machine-Learning-Frameworks – also eine breite Palette an Optionen. Zudem helfen eine Vielzahl von professionellen Dienstleistern beim Umsetzen.

Dass die meisten dieser Werkzeuge unter Open-Source-Lizenzen stehen, sollte die ganze Sache für die Industrie eigentlich noch interessanter machen. Tatsächlich ist oft das Gegenteil der Fall: Klassische Industriekunden macht das eher misstrauisch. Vielerorts herrscht noch die Einstellung, dass eine kostenlose Lösung unmöglich besser sein kann als eine für viele Tausend Euro. Das jedenfalls ist mein Eindruck aus den letzten drei Jahren, in denen ich vorwiegend bei Unternehmen aus dem Produktionssektor unterwegs war.

Ein wiederkehrendes Argument gegen Open Source lautet: Es gibt keinerlei Support. Ein weiteres: Die Verfügbarkeit des Quellcodes erleichtert es, Bugs und Sicherheitslücken aufzuspüren und auszunutzen. Zudem wird kritisiert, dass Open-Source-Lösungen üblicherweise nicht (Safety-)zertifiziert sind und daher aus Gründen der Betriebssicherheit nicht zum Einsatz kommen dürfen.

Während die ersten beiden Argumente vor ungefähr 20 Jahren ähnlich auch von der IT-Industrie (Microsoft und Co.) kamen, ist die Safety-Zertifizierung in sicherheitskritischen Bereichen tatsächlich eine Baustelle. Es gibt jedoch bereits Projekte, die daran arbeiten [7], weil die Frage auch andere Industriezweige betrifft, etwa die Automobilindustrie (siehe Kasten “Zertifizierungen”).

Ein Argument, das in der Regel für Open Source spricht, ist die Innovationsgeschwindigkeit. Hier geht es in der Automatisierungsindustrie eher gemächlich zu. Die Produktlebenszyklen sind auf bis zu 40 Jahre ausgelegt, in Jahren messen die Unternehmen auch die Abstände zwischen Major-Releases.

Im Open-Source-Umfeld liegen die Release-Zyklen hingegen oft bei Monaten, Wochen oder gar Tagen. Vor allem bei kritischen Bugs steht nicht selten schon nach wenigen Tagen eine neue Version bereit. Solche schnelle Reaktionen sind Programm: Repariert ein Projekt der Apache Software Foundation seine kritischen Bugs nicht innerhalb eines bestimmten Zeitraums, fliegt es im Extremfall aus der Foundation oder wird zumindest als inaktiv erklärt.

Zwar müssen quelloffene Lösungen im industriellen Umfeld oft andere Wege gehen, dennoch siedeln sich inzwischen verschiedene Open-Source-Projekte im Edge-Bereich an. Sie kommen entweder direkt aus der Community von interessierten Entwicklern, die ihre Projekt zum Beispiel einfach auf Github hosten. Eine Vielzahl von Projekten entstand in den letzten Jahren aber auch unter den Fittichen der großen Open-Source-Stiftungen.

Die Linux Foundation betreibt die für industrielles IoT interessanten Projekte unter der Haube der LF-Edge-Initiative. Hierbei handelt es sich zwar um eine relativ kleine Anzahl von Entwicklungsvorhaben, deren Scope aber sehr genau aufeinander abgestimmt ist. Auch die Eclipse und die Apache Software Foundation (ASF) bieten Projekten aus diesem Sektor einen sicheren Ort an, ohne aber direkt auf die Teilnehmer einzuwirken. Hier gibt es üblicherweise kein Steuerungsgremium.

Beispiel PLC4X

Gerade im industriellen Umfeld lassen sich die Foundations als sichere Häfen für Projekte einsetzen. Als ich Ende 2017 mit dem PLC4X-Projekt [8] startete, war für mich von Anfang an klar, dass sich diese Arbeit nur unter dem Schutzschirm einer Stiftung leisten ließe. Wer mit einem kleinen Projekt ein kostenloses Tool entwickelt, das auf einen Multi-Milliarden-Markt abzielt, kann unter dem Schutz einer Foundation deutlich ruhiger schlafen.

Das Ziel von Apache PLC4X besteht darin, ein einheitliches API bereitzustellen, um mit industrieller Hardware (also SPS oder PLCs) verschiedenster Hersteller zu kommunizieren. Zusätzlich liefert die Software eine Vielzahl an Integrationsmodulen für andere Open-Source-Frameworks mit. Nach zweieinhalb Jahren wurde PLC4X im Frühjahr 2019 zum Top-Level-Projekt der ASF.

In diesem sogenannten Connectivity-Bereich mit industrieller Hardware gab es zwar schon sehr lange eine Vielzahl von Projekten, die kommerziellen Lösungen sind hier aber nach wie vor sehr teuer: 500 bis 5000 Euro Lizenzkosten pro Gerät pro Treiber stellen keine Seltenheit dar. Dem steht eine überschaubare Anzahl von Open-Source-Lösungen gegenüber, die sich aber teilweise nicht für den gewerblichen Einsatz eignen, weil sie zum Beispiel die GPL verwenden.

Fazit

Generell bestimmt das verwendete Protokoll zu einem großen Teil die Struktur der Lösung. Software zu schreiben, die mit mehreren Protokollen und somit mit den Anlagen verschiedener Hersteller zurechtkommt, lässt sich heute noch sehr schwer umsetzen.

Das kann sich aber ändern. Es dürfte spannend sein zu beobachten, wie die Automatisierungsindustrie auf die Edge-Herausforderung reagiert: Folgt sie den Fußstapfen der IT-Industrie, deren große Player mittlerweile gemeinsam an Open-Source-Software arbeiten? Oder kochen die Hersteller der Industrie weiterhin ihr eigenes Süppchen und versuchen, Edge-Lösungen im Alleingang auf den Markt zu drücken? Das muss die Zukunft weisen. (kki)