DeusterDevelopment
← Zurück zur Übersicht

Die stille Langlebigkeit industrieller Protokolle (3/8)

Industrielle Protokolle wie Modbus, Profibus oder CAN überleben seit Jahrzehnten — nicht aus Sturheit, sondern weil ihr Umfeld Austausch ökonomisch und regulatorisch massiv bestraft. Ihre Langlebigkeit beruht auf Selbstbeschränkung: sie wachsen nicht mit, sondern lassen sich von anderen Schichten ergänzen. Fitness zum Kontext ist ein systematisch unterschätzter Designwert.

Die stille Langlebigkeit industrieller Protokolle (3/8)

Einleitung

Modbus ist älter als das Web.

1979 bei Modicon entworfen.

Für die Kommunikation zwischen Steuerungen in Fabriken.

HTTP gab es damals nicht.

Gopher und NNTP waren mindestens eine Dekade entfernt.

Modbus ist immer noch da.

Gopher ist es nicht.


Die Frage

Die industrielle Welt behält Protokolle über Jahrzehnte.

Die Web-Welt ersetzt sie alle paar Jahre.

Warum?


Nicht Haltung, sondern Kosten

Die reflexhafte Antwort lautet: die Industrie ist konservativ.

Ich halte das für zu bequem.

Die Industrie lehnt das Neue nicht ab.

Sie führt Industrial Ethernet, MQTT, OPC UA, TSN und 5G in Produktionsumgebungen ein.

Sie tut es nur, wenn der Nutzen den Austauschaufwand rechtfertigt.

Ein Web-Framework auszutauschen ist ein Commit.

Ein Bus-System in einer Werkhalle auszutauschen heißt:

  • Kabel ziehen
  • Steuerungen ersetzen
  • Produktion stilllegen
  • Sicherheitsabnahmen neu machen
  • Zertifizierungen erneuern
  • Personal schulen

Wenn derselbe Vorgang im Web drei Tage dauert

und in der Fabrik drei Monate Stillstand bedeutet,

darf man erwarten, dass die Bereitschaft unterschiedlich ausfällt.


Fit für den Kontext

Industrie-Protokolle überleben, weil das Umfeld Austausch bestraft.

Das macht sie nicht rückwärtsgewandt.

Es macht sie fit für ihren Kontext.

Das Protokoll, das in einer Chemieanlage über 25 Jahre in Betrieb bleibt,

ist genau das, das dorthin gehört.


Die Bescheidenheit von Modbus

Modbus ist technisch extrem bescheiden:

  • Master-Slave
  • ein paar Funktionscodes
  • Register als Speicheradressen
  • CRC, keine Authentifizierung, keine Verschlüsselung

Das war 1979 angemessen — die Netze waren physisch isoliert.

Heute ist das ein Problem.

Aber Modbus hat diese Lücken nie gefüllt.

Stattdessen wurde TLS darunter gelegt. VPNs darüber.

Modbus blieb, was es war.

Nicht weiterentwickeln.

Freihalten.


Was klein bleibt, altert langsam

Profibus, CAN, S7, Modbus haben alle dieselbe Eigenschaft:

Ihr Wesen lässt sich in einem Absatz erklären.

Das ist das Gegenteil davon, wie moderne Protokolle wachsen.

HTTP/2, HTTP/3, OAuth 2.1 — jede Spezifikation wird dicker.

Jedes neue Bedürfnis wandert hinein.

Wer etwas klein hält, altert langsam.


Zertifizierungsträgheit

Eine SPS in einer Lebensmittelproduktion ist für einen bestimmten Betriebsmodus zugelassen.

Wenn jemand einen Austausch vorschlägt, der die Zertifizierung berührt,

wird aus einem Softwareprojekt ein Regulierungsprojekt.

Die meisten Unternehmen ziehen das nicht durch, solange die Anlage läuft.

Das ist keine Trägheit aus Faulheit.

Es ist Trägheit aus Verantwortung.


Zentrale Beobachtung

Fitness zum Kontext ist ein unterschätzter Designwert.

Ein Protokoll ist nicht gut, weil es modern ist.

Es ist gut, wenn es zum Umfeld passt, in dem es laufen muss.


Abschlussgedanke

In vielen industriellen Umfeldern heißt das:

einfach, eng definiert, ohne Ambitionen jenseits seiner Aufgabe.

Das ist keine Eigenschaft, die auf Folien gut aussieht.

Sie ist einfach effektiv.

Verwandte Beiträge

Backups, die niemand übt

Backups, die niemand übt

Backups existieren überall, geprüfte Restores fast nie. „Wir haben Backups" und „wir können wiederherstellen" sind zwei verschiedene Aussagen — die erste beschreibt einen Zustand, die zweite eine Fähigkeit. Die Lücke dazwischen ist fast nie technisch, sondern organisatorisch: fehlende Übung, veraltete Runbooks, Wissen, das das Haus verlassen hat. Der geübte Restore ist der ehrlichste Reifegrad-Indikator, den eine Organisation hat. Die Frage lautet nicht „Haben wir Backups?", sondern „Wann sind wir den Weg zurück zuletzt wirklich gegangen?".

Systeme für das Altern entwerfen (8/8)

Systeme für das Altern entwerfen (8/8)

Systeme, die altern sollen, müssen ohne ihre Autoren funktionieren — das verlangt langlebige Schnittstellen, vorsichtige Versionierung, ehrliche Dokumentation und das bewusste Vermeiden ephemerer Abhängigkeiten. Legacy ist kein Scheitern, sondern Erfolg, der lange genug angehalten hat, um außer Mode zu kommen. Die Frage beim nächsten Projekt lautet nicht „wird das modern sein?", sondern „kann ich mir vorstellen, dass das in zwanzig Jahren noch läuft, ohne dass mich jemand dafür verflucht?".