Wer in der Produktions-IT arbeitet, kennt sie: die Automatisierungspyramide. Das Purdue-Modell und die ISA-95 haben über Jahrzehnte gute Dienste geleistet. Schaut man aber ehrlich auf den heutigen Shopfloor, zeigt sich: Als starrer Bauplan für moderne OT-Netzwerke funktioniert das Schichtenmodell nicht mehr.
Woher die Pyramide kommt
Das Purdue-Modell stammt aus den 90er Jahren. Es wurde für eine Welt entworfen, in der Daten geordnet Ebene für Ebene nach oben wanderten: vom Feld über die Steuerung und den Leitstand bis in die Unternehmens-IT. Die Systemgrenzen waren klar, die Wege überschaubar.
Wichtig dabei: Die Pyramide ist ein Referenzmodell, keine Sicherheitsnorm. Die ISA-95 beschreibt Funktionen in der Fertigung, keine Netzwerkarchitektur.
Was sich geändert hat
Heute sieht die Fertigung anders aus. Edge-Gateways, Cloud-Dienste und Fernwartung überspringen ganz selbstverständlich mehrere Ebenen. Protokolle wie MQTT arbeiten nach dem Publish/Subscribe-Prinzip, Sender und Empfänger sind voneinander entkoppelt. Die Maschine muss nicht wissen, auf welcher Ebene der Abnehmer sitzt. Ihre Daten erreichen MES und ERP über einen Broker, ohne Umweg über jede Ebene.
Dazu kommen Funksensoren, etwa für Temperatur oder Leckage. Sie hängen technisch an der Maschine, laufen aber über ein eigenes Funknetz. In welche Ebene gehören sie? In keine so richtig.
Neu im Spiel: KI-Agenten
Noch deutlicher wird es bei KI-Agenten. Ein Agent, der Stillstände auswertet, will Maschinendaten, Auftragsdaten aus dem ERP und Qualitätsdaten gleichzeitig sehen. Er arbeitet quer über alle Ebenen. Manche Agenten sollen nicht nur lesen, sondern auch eingreifen, zum Beispiel einen Auftrag umplanen oder einen Parameter vorschlagen.
Die Pyramide gibt darauf keine Antwort. Die sinnvolle Frage ist nicht „auf welche Ebene gehört der Agent?“, sondern:
- Welche Daten darf er lesen?
- Darf er überhaupt schreiben, und wenn ja, wohin?
- Über welchen kontrollierten Übergang läuft das?
Ein Agent, der nur liest, gehört in die IT-Zone und bekommt seine Daten über den Broker. Ein Agent, der schreiben darf, ist ein eigenes Risiko und braucht eine eigene Zone mit klar geregeltem Übergang.
Wo das starre Modell schadet
Wer das Ebenenmodell wörtlich als Netzwerkarchitektur erzwingen will, richtet oft mehr Schaden an als Nutzen. Da sind Ebenen-Firewalls, deren Regelwerk so komplex wird, dass es niemand mehr sauber pflegt. Noch schlimmer sind Schattenverbindungen. Ein bekanntes Muster: Ist der offizielle Weg durch drei Firewalls für den Instandhalter zu umständlich, hängt irgendwann ein eigener LTE-Router direkt an der Anlage. Am Ende steht Scheinsicherheit statt echter Kontrolle.
Was stattdessen zählt: Zones & Conduits
Die erste Fassung der IEC 62443 hat sich noch am Ebenenmodell orientiert. Heute sind Zonen nach Risiko die Grundlage. Teil 3-2 der Norm beschreibt, wie man eine Anlage in Zonen und Conduits aufteilt und für jede davon das Risiko bewertet. In der Praxis heißt das:
- Zonen nach dem tatsächlichen Risikoprofil der Anlagen bilden.
- Übergänge strikt regeln, möglichst nur mit ausgehenden Verbindungen aus der OT heraus.
- Gesicherte, verschlüsselte Protokolle wie OPC UA und MQTT über TLS nutzen.
Wie das in der Praxis aussieht, habe ich in zwei Beiträgen gezeigt: Sichere Maschinenanbindung mit Zones & Conduits und IEC 62443 zum Anfassen – live auf Proxmox.
Ein Beispiel
Ein Beispiel für so einen Aufbau: drei Zonen, das Maschinennetz ohne Gateway und ohne Internet, das IT-Netz und eine eigene Zone für Funksensoren. Zwischen den Zonen gibt es nur definierte Übergänge. Edge-Gateway und Funk-Gateway senden ausschließlich nach außen, per MQTT über TLS an einen Broker. Für die Wartung gibt es einen Jump-Host, der nur zeitweise freigeschaltet wird und jede Sitzung protokolliert. Direkt von außen in das Maschinennetz führt kein Weg.
Die Trennung bleibt also. Sie folgt aber dem Risiko und den Datenflüssen, nicht starr fünf Ebenen. Die Pyramide bleibt eine gute Landkarte, um Architekturen zu skizzieren. Ein Bauplan ist sie nicht.
Fazit
Modelle altern. Wer heute noch streng nach Pyramide baut, ist hinter der eigenen Norm zurück. Die Digitalisierung in der Fertigung braucht Architekturen, die den Produktionsalltag unterstützen und ihn nicht ausbremsen. Und spätestens mit KI-Agenten wird die Frage „wer darf was, über welchen Weg“ wichtiger als die Frage „auf welcher Ebene“.
Kurz gefragt
Ist das Purdue-Modell veraltet?
Als Orientierung nicht. Als starrer Bauplan für Netzwerke schon, weil heutige Datenflüsse mehrere Ebenen überspringen.
Schreibt die IEC 62443 das Ebenenmodell vor?
Nein. Grundlage sind Zonen und Conduits, die nach Risiko gebildet werden (IEC 62443-3-2).
Wohin gehört ein KI-Agent im OT-Netz?
Das hängt davon ab, ob er nur liest oder auch schreibt. Ein lesender Agent bekommt Daten über einen kontrollierten Übergang, ein schreibender Agent braucht eine eigene Zone mit klar geregeltem Zugriff.