Purdue-Modell vs. ISA-95 ist eine der häufigsten Quellen für Verwirrung in der industriellen Architektur, weil beide Ebenen von 0 bis 4 nummerieren und beide als übereinanderliegende Schichten dargestellt werden. In diesem Vergleich erfahren Sie, wofür jedes Modell entworfen wurde, wie sich ihre Ebenen zuordnen lassen, wo sie sich tatsächlich unterscheiden und wie MQTT und ein Unified Namespace (UNS) den Datenfluss zwischen den Ebenen verändern, ohne die Sicherheitszonierung aufzugeben, die Netzwerke nach Purdue-Art bieten.
Woher die Modelle stammen
Die Purdue Enterprise Reference Architecture wurde Anfang der 1990er-Jahre an der Purdue University als allgemeines Modell für die rechnerintegrierte Fertigung entwickelt. In der industriellen Sicherheit ist sie zum Kürzel für eine geschichtete Netzwerkarchitektur geworden: der physische Prozess unten, die Unternehmens-IT oben und kontrollierte Grenzen dazwischen. Sie dient in OT-Sicherheitsprogrammen breit als Referenz und hat den Zonen-und-Conduits-Ansatz von ISA/IEC 62443 beeinflusst.
ISA-95, auch als IEC 62264 veröffentlicht, ist ein Integrationsstandard. Sein Zweck ist es festzulegen, wie Geschäftssysteme wie ERP und Systeme der Fertigungssteuerung wie MES Informationen austauschen: Produktionspläne, Materialverbrauch, Anlagenfähigkeiten, Qualitätsergebnisse. Er liefert Objektmodelle, Aktivitätsmodelle und eine funktionale Hierarchie und definiert außerdem die rollenbasierte Anlagenhierarchie aus Unternehmen, Standort, Bereich, Arbeitszentrum und Arbeitseinheit.
Kurz gesagt: Purdue wird meist genutzt, um die Frage „Wie sollen die Netzwerke segmentiert werden?“ zu beantworten, während ISA-95 beantwortet: „Welche Funktionen gibt es auf jeder Ebene, und welche Informationen fließen zwischen Geschäftsebene und Betrieb?“
Wie die Ebenen zusammenpassen
Die Ebenennummern stimmen eng genug überein, um nützlich zu sein, und locker genug, um Diskussionen auszulösen.
| Ebene | Purdue-Modell (Netzwerksicht) | Funktionale Hierarchie nach ISA-95 | Typische Systeme |
|---|---|---|---|
| 5 | Unternehmensnetzwerk | Nicht gesondert definiert | Unternehmens-IT, internetseitige Dienste |
| 4 | Geschäftslogistik | Geschäftsplanung und Logistik | ERP, Planung, E-Mail |
| 3.5 | Industrielle DMZ | Nicht definiert | Jump Hosts, Patch-Server, Daten-Broker |
| 3 | Standortbetrieb | Manufacturing Operations Management | MES, Historian, Standort-SCADA-Server |
| 2 | Bereichsüberwachung und -steuerung | Überwachung und übergeordnete Steuerung | HMI, SCADA-Clients, Engineering-Stationen |
| 1 | Basissteuerung | Erfassen und Beeinflussen | SPS, DCS-Controller, RTUs |
| 0 | Physischer Prozess | Der physische Prozess | Sensoren, Aktoren, Antriebe |
Drei Unterschiede fallen auf:
- Level 3.5 ist ein Purdue-Konzept. ISA-95 kennt keine DMZ, weil es keine Netzwerke modelliert. Sicherheitsfachleute haben die industrielle DMZ zwischen Standortbetrieb und Unternehmensnetzwerk ergänzt, um direkten Verkehr zwischen IT und OT zu verhindern.
- Level 5 taucht in vielen Purdue-Diagrammen auf als eigene Unternehmens- oder Internetschicht. ISA-95 endet bei Level 4.
- Der Hauptbeitrag von ISA-95 ist die Schnittstelle zwischen Level 3 und Level 4, die Purdue-Diagramme als einzelne Firewall-Grenze behandeln.
Purdue-Modell vs. ISA-95: Die wichtigsten Unterschiede
| Aspekt | Purdue-Modell | ISA-95 |
|---|---|---|
| Art | Referenzarchitektur | Internationaler Standard (IEC 62264) |
| Heutiger Schwerpunkt | Netzwerksegmentierung und Sicherheit | Systemintegration und Informationsmodelle |
| Definiert Datenmodelle | Nein | Ja, für Produktion, Qualität, Instandhaltung, Bestand |
| Definiert Anlagenhierarchie | Nein | Ja, vom Unternehmen bis zur Arbeitseinheit |
| Definiert eine DMZ | Ja, üblicherweise als Level 3.5 | Nein |
| Typische Zielgruppe | OT-Sicherheit, Netzwerkingenieure | MES-Architekten, Integratoren, Betrieb |
| Relevanz für das MQTT-Topic-Design | Indirekt, über den Standort der Broker | Direkt, über die Anlagenhierarchie |
Die praktische Konsequenz: Wenn Sie MQTT-Topics entwerfen, verwenden Sie die ISA-95-Anlagenhierarchie, die unser Leitfaden zur ISA-95-Anlagenhierarchie erklärt. Wenn Sie entscheiden, wo der Broker läuft und welche Verbindungen die Firewalls zulassen, denken Sie in Purdue-Zonen.
Im UNS wird die ISA-95-Anlagenhierarchie direkt zur Topic-Struktur auf dem MQTT-Broker: Aus Enterprise → Site → Area → Line → Cell wird etwa acme/werk-stuttgart/abfuellung/linie-1/zelle-3/temperatur. Jeder Wert hat damit eine eindeutige Adresse, die MES, ERP und Analytics ohne Zuordnungstabellen verstehen. Wie Sparkplug B diese Struktur ergänzt, erklärt unser Artikel zu Sparkplug B und Unified Namespace.
Wie MQTT die Kommunikation über die Ebenen abflacht
In einem klassischen Werk nach Purdue-Art steigen Daten Schritt für Schritt durch die Ebenen auf. Eine SPS wird von SCADA auf Level 2 abgefragt, SCADA speist den Historian auf Level 3, der Historian wird durch die DMZ repliziert, und das ERP sieht schließlich eine Zusammenfassung. Jeder Schritt ist eine Punkt-zu-Punkt-Integration mit eigenem Protokoll, eigenem Mapping und eigenen Fehlerbildern.
Eine Publish-Subscribe-Architektur verändert den Datenfluss. Mit einem MQTT-Broker als Knoten des UNS publiziert jeder berechtigte Producer einmal, und jeder berechtigte Consumer abonniert direkt. MES, Historian, ein Dashboard und ein Cloud-Analytics-Job lesen alle dieselbe Abfüller-Telemetrie aus demselben Topic. Genau das ist gemeint, wenn es heißt, MQTT „flacht die Pyramide ab“.
Wichtig ist, genau zu sein, was abgeflacht wird. Die Informationsarchitektur wird flach: Es gibt einen Namespace statt einer Kette von Kopien. Die Netzwerkarchitektur muss es nicht: Zonen, Firewalls und die DMZ bleiben bestehen. MQTT hilft dabei, weil Clients immer ausgehende Verbindungen zum Broker aufbauen. Ein Gateway auf Level 2 kann an einen Broker in der DMZ oder in der Cloud publizieren, ohne dass ein eingehender Port ins Steuerungsnetz geöffnet werden muss.
Wo der Broker platziert wird
| Platzierung | Funktionsweise | Zu beachten |
|---|---|---|
| Standort-Broker auf Level 3 | Gateways publizieren innerhalb des Standorts; eine Bridge oder ein Consumer leitet nach oben weiter | Daten bleiben lokal; Sie betreiben den Server |
| DMZ-Broker auf Level 3.5 | OT-Clients verbinden sich ausgehend in die DMZ; IT-Clients verbinden sich von oben | Klare Grenze; keine Seite verbindet sich in die Zone der anderen |
| Cloud-Broker | Edge-Gateways verbinden sich ausgehend über TLS mit einem verwalteten MQTT-Broker | Kein eigener Server; erfordert ausgehenden Internetzugang aus einer kontrollierten Zone |
| Hybrid | Standort-Broker für lokale Consumer, Cloud-Broker für Unternehmen und standortübergreifende Nutzung | Mehr Komponenten, beste Ausfallsicherheit und Reichweite |
Unser Artikel MQTT in der DMZ behandelt das DMZ-Design ausführlich, einschließlich Firewall-Regeln. Wenn Sie sich für einen Cloud-MQTT-Broker entscheiden, übernimmt ein verwalteter MQTT-Broker wie ConnectMQ die Serverseite, während Ihre Firewall nur ausgehendes TLS aus der Zone des Gateways zulassen muss.
Einen ausgehenden Pfad aus einer OT-Zone testen
Bevor Sie sich auf eine Platzierung festlegen, prüfen Sie, ob ein Gateway in der vorgesehenen Zone den Broker auf dem richtigen Port erreicht und ob TLS validiert. Diese Befehle können Sie gefahrlos auf einem Linux-Gateway oder Jump Host ausführen; sie nutzen den öffentlichen MQTT-Broker, der nur für Tests gedacht ist, publizieren Sie also nichts Sensibles:
# 1. Ist ausgehendes TLS auf 8883 erlaubt, und wird das Zertifikat validiert?
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null 2>/dev/null | grep -E "Verify return code|subject="
# 2. Eine Retained-Testnachricht über TLS publizieren
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-pub-j2 -r -t "connectmq/demo/j2v6/zone-test/level2-gateway" -m "reachable"
# 3. Aus einer anderen Zone zurücklesen
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-sub-j2 -t "connectmq/demo/j2v6/zone-test/#" -v -C 1
Eine Zeile Verify return code: 0 (ok) bestätigt, dass die Zertifikatskette vertrauenswürdig ist. Wenn Schritt 1 hängt, blockiert eine Firewall Port 8883; sind WebSockets die einzige Option, ist Port 8084 mit dem Pfad /mqtt eine Alternative. Der kostenlose öffentliche MQTT-Broker eignet sich für diesen Konnektivitätstest; Produktionsverkehr gehört auf einen privaten Broker mit Zugangsdaten.
Sicherheit bleibt wichtig
Ein flacher Namespace macht Daten leicht erreichbar, daher werden Authentifizierung und das Prinzip der geringsten Rechte wichtiger, nicht unwichtiger. Für viele Betreiber in der EU kommen zudem die Anforderungen der NIS2-Richtlinie hinzu; eine dokumentierte Zonierung nach IEC 62443 hilft, sie nachzuweisen:
- Nur ausgehend. Gateways verbinden sich ausgehend mit dem Broker; öffnen Sie niemals eingehende Ports in die Level 0 bis 2.
- TLS überall. Port 8883 für MQTT über TLS, 8084 für sichere WebSockets.
- Eine Identität pro Client. Vergeben Sie Zugangsdaten pro Gateway und Anwendung, damit jeder Zugang unabhängig widerrufen werden kann. Bei ConnectMQ sind Client IDs an die ausgestellten Zugangsdaten gebunden.
- Getrennte Lese- und Schreibpfade für die Steuerung. Behandeln Sie Befehls-Topics als hohes Risiko und halten Sie geschlossene Regelkreise im lokalen Steuerungsnetz.
- Verbindungen überwachen. Achten Sie auf unerwartete Clients und fehlgeschlagene Anmeldungen. ConnectMQ sperrt IPs nach wiederholten fehlgeschlagenen Anmeldungen und wendet Flood-Schutz pro Mandant an.
Das Verhältnis der beiden Modelle ist Teil der umfassenderen Diskussion zur IT/OT-Konvergenz, und unser Leitfaden zu Industrial IoT mit MQTT zeigt, wie sich diese Bausteine in eine vollständige Werksarchitektur einfügen.
Verbinden Sie Ihre Ebenen mit ConnectMQ
Wer Zonen nach Purdue-Art beibehalten und gleichzeitig den Datenfluss abflachen will, braucht einen Broker, den jede Zone über ausgehendes TLS erreicht. ConnectMQ ist ein verwalteter MQTT-Broker mit TLS auf 8883, sicheren WebSockets auf 8084, Zugangsdaten pro Client und einer ISA-95-Geräteansicht, verfügbar als Shared-, Dedicated- oder BYOC-Bereitstellung. Starten Sie im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte.
Häufig gestellte Fragen
Ist das Purdue-Modell überholt?
Sein strikter Datenfluss von Ebene zu Ebene wird durch Publish-Subscribe-Architekturen abgelöst, aber seine Kernidee, Netzwerke in Zonen mit kontrollierten Grenzen zu segmentieren, bleibt zentral für die OT-Sicherheit.
Definiert ISA-95 Netzwerksicherheit?
Nein. ISA-95 definiert Funktionen, Informationsmodelle und die Anlagenhierarchie. Netzwerk- und Systemsicherheit für die industrielle Automatisierung wird von der Normenreihe ISA/IEC 62443 behandelt.
Welches Modell sollte ich für das MQTT-Topic-Design verwenden?
Verwenden Sie die ISA-95-Anlagenhierarchie für Topics und Zonen nach Purdue-Art, um zu entscheiden, wo der Broker läuft und welche ausgehenden Verbindungen erlaubt sind.
Bricht ein Unified Namespace das Purdue-Modell?
Er verändert den Datenfluss, nicht zwingend die Netzwerksegmentierung. Mit rein ausgehenden MQTT-Verbindungen und einem Broker in der DMZ oder in der Cloud bleiben Zonen und Firewalls bestehen.
