Kolumne

Knigge für Softwarearchitekten: Wie Sie die Industrie-4.0-Zukunft mitgestalten

Gernot Starke, Peter Hruschka

Remote is the new local: Waren, Maschinen, Fabriken, Lieferanten, Kunden, Menschen und Bots koordinieren automatisch Entwicklung, Lieferung, Produktion, Bestellung und Abwicklung von Produkten und Dienstleistungen. Hinter dem globalen – und nichtssagendem – Stichwort Industrie 4.0 verbirgt sich die nächste Evolutionsstufe unserer ohnehin schon ziemlich elektronifiziert-vernetzten Gesellschaft: die postindustrielle Revolution. Fabriken erhalten jetzt neben der physischen Dimension eine zusätzliche; nämlich die komplette Interorganisationsvernetzung.

Die Versprechen

Industrie 4.0 steht für die intelligente Vernetzung von Produktentwicklung, Produktion, Logistik und Kunden. Der Kunde konfiguriert im Web ein Produkt. Diese Konfiguration wird direkt in Bestell-, Liefer- und Produktionsprozesse umgewandelt. Genauer gesagt: „Industrie 4.0 bedeutet die Vernetzung von autonomen, sich situativ selbst steuernden, sich selbst konfigurierenden, wissensbasierten, sensorgestützten und räumlich verteilten Produktionsressourcen (Produktionsmaschinen, Roboter, Förder- und Lagersysteme, Betriebsmittel) inklusive deren Planungs- und Steuerungssysteme.“

Die Risiken

Als Softwerker wissen Sie nur zu gut um die Herausforderungen – faktisch: Probleme – vernetzter Systeme: inkompatible Schnittstellen, mehr Fehlerquellen, Sicherheit und Volumen. Zuerst zu den inkompatiblen Schnittstellen: Neben Syntax und Semantik haben wir für die Industrie 4.0 noch die Kleinigkeiten von gemeinsamen technischen Protokollen zu klären. IP V4 genügt sicherlich nicht mehr, aber IP V6 ist ja bis heute nicht wirklich in Schwung gekommen. Mehr beteiligte Kommunikationspartner und mehr Kommunikationskanäle bedeuten zwangsläufig neue Fehlerquellen. So lange wir Systeme in Zukunft nicht eine Größenordnung fehler- und ausfalltoleranter entwickeln als heute, wird uns bei Totalvernetzung der Fehlerteufel einholen. Auch handelt kaum einer der großen Beteiligten an Industrie-4.0-Ansätzen aus Gemeinsinn, Gerechtigkeit oder Gutmütigkeit, sondern aus zutiefst kommerziellen Motiven. Die Menge der Angriffsvektoren gegen diese Daten und damit die Optionen für deren Missbrauch steigen stark an: Beispielsweise ist die Datenhoheit bei internationalen Projekten im Bereich Connected Car ein ganz zentrales Thema: Automobilhersteller möchten die vom und im Kfz erfassten Daten gerne für sich behalten. Andere Projektpartner, etwa aus den Bereichen Kommunikation, Navigation, Pannenhilfe oder auch Social Media hätten gerne zumindest Teile dieser Daten für sich. Da sehen wir erhebliches Konfliktpotenzial. Seit Big Data wissen wir, dass Daten fast gleichbedeutend mit Geld sind. Und durch die totalvernetzte Industrie 4.0 werden sich die Datenmengen vervielfachen: 1 Milliarde PCs, 5 Milliarden Smartphones, dazu noch geschätzte hunderte Milliarden datenproduzierende Sensoren zusammen mit aggregierenden Steuergeräten, korrelierenden Bots und Co. schaffen komplett neue Herausforderungen in puncto Volumen. Technische Kleinigkeiten wir Latenz, Deadlocks, Parallelität und Datenintegrität wollen wir hier aufgrund der Kürze der Kolumne mal ignorieren.

Ein Risiko der ganz anderen Art sehen wir hingegen im technischen Unverstand von Entscheidungsträgern: Wenn wir alleine die unsägliche Telekommunikationsüberwachungsverordnung aus dem Jahre 2002 als Beispiel wählen und uns entsetzt vorstellen, wie eine völlig vernetzte Industrie aufgrund solcher Verordnungen in die Mühlen technisch dilettierender Juristen oder Verwaltungskräfte gerät … Wir sagen nur Neuland.

So, genug der Schwarzmalerei. Schon lange arbeiten Forscher an Lösungsvorschlägen. Aber die bisherigen Ergebnisse lassen, vorsichtig formuliert, noch eine Menge Raum für Verbesserungen.

Referenzarchitektur 4.0?

Wir mögen ja Modelle, aber der hohe Abstraktionsgrad des „Referenzmodell RAMI für die Industrie 4.0“ (Abb. 1) flößt schon etwas Angst ein. Auf Basis von drei Dimensionen, sechs Schichten und sieben so genannten Funktionalitäten soll die komplett vernetzte Industrie entwickelt werden? Uns erscheint das zu wolkig, um wirklich interoperable und vernetzte Software darauf zu entwickeln. Vielmehr befürchten wir einen Blackout 4.0, wenn wir nicht etwas klarer definierte und weniger wolkige Architekturen für die zukünftige Industrie bekommen. Aber woher nehmen? Wir haben natürlich keinen fertigen Vorschlag, sondern möchten Sie – ja, Sie werte Leserschaft – hier in die Pflicht zur Mitwirkung nehmen.

Herausforderungen für Softwarearchitektur

Wir haben das in der einführenden Folge dieser Staffel in ähnlicher Form bereits formuliert: Sie, Entwickler und Softwarearchitekten, müssen 4.0 aktiv mitgestalten. Sie müssen Ihren eigenen Horizont bezüglich Architekturmustern, Entwurfs- und Implementierungsprinzipien hinsichtlich der durchgängigen Vernetzung erweitern, denn „remote is the new local“. Garantien, die uns homogene, lokale Laufzeitumgebungen bisher sicherstellten, gelten in 4.0 oftmals nicht mehr. Wir brauchen andere Größenordnungen von Interoperabilität, Resilienz und Fehlertoleranz und möglicherweise komplett neue Mechanismen für die Zusammenarbeit räumlich getrennter Softwarebausteine.

Fazit

Industrie 4.0 birgt eine Menge Chancen für Sie, Ihre und andere Organisationen sowie für unsere Gesellschaft als Ganzes. Aber dem Optimismus sollte neben Pragmatismus auch eine Portion Skepsis gegenüberstehen. Nicht jede Vernetzung von Geräten und Dingen bedeutet automatisch einen Vorteil. Denn sie enthält fast zwangsläufig zusätzliche Fehlerquellen und Risiken. In diesem Sinne wünschen wir Ihnen eine angemessene Vernetzung in der Software/Industrie 4.0.

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: