Ein cyber-physisches System als Architektur darstellen

Wenn eine Linie im Plan zu viel verspricht

Die Edelgrund Mehrwegservice GmbH reinigt Transportbehälter für regionale Lebensmittelbetriebe. In einer Waschlinie fördert eine Umwälzpumpe Wasser durch die Sprühdüsen. Ein Drucksensor liefert den aktuellen Sprühdruck an eine speicherprogrammierbare Steuerung, kurz SPS. Die SPS passt die Pumpendrehzahl über einen Frequenzumrichter an. Das Bedienpersonal sieht den Zustand an einem lokalen Bediengerät.

Nun soll ein externer Wartungsdienst Zustandsdaten auswerten. Ein Edge-Gateway soll dafür ausgewählte Mess- und Diagnosedaten an ein Wartungsportal übertragen. Der erste Entwurf zeigt alle Geräte als Kästen, verbunden durch gleichartige Linien. Dadurch bleiben wichtige Fragen offen:

• Welche Komponente misst und welche wirkt auf den Waschprozess?
• Darf das Wartungsportal die Pumpe steuern oder nur Zustände lesen?
• Welche Funktion bleibt erhalten, wenn Gateway oder Internetverbindung ausfallen?
• Wo endet die Verantwortung der lokalen Anlage?

Eine unklare Zeichnung kann versehentlich eine Funktion behaupten, die gar nicht vorgesehen ist. Eine Linie zwischen Wartungsportal und Pumpe wirkt schnell wie ein Steuerweg. Genau deshalb beginnt eine Architektur nicht mit hübschen Symbolen, sondern mit Systemgrenze, Rollen und gerichteten Flüssen.

Die Grundidee lautet: Eine Architektur zeigt, welche Teile für einen Zweck zusammenarbeiten, was zwischen ihnen fließt und wo Verantwortung oder Abhängigkeit wechselt.

Lege zuerst Zweck und Systemgrenze fest

Eine Systemgrenze legt fest, welche Teile du als betrachtetes System behandelst. Sie ist keine Naturgegebenheit. Du ziehst sie passend zur Fragestellung und machst deine Entscheidung sichtbar.

Für Edelgrund lautet der Zweck der Darstellung:

Die Architektur soll zeigen, wie die Waschlinie den Sprühdruck lokal regelt und welche Zustandsdaten den externen Wartungsdienst erreichen.

Zur lokalen Waschlinie gehören der Waschprozess, Drucksensor, SPS, Frequenzumrichter, Pumpe, Bediengerät und Edge-Gateway. Das Wartungsportal liegt außerhalb dieser Grenze. Es gehört zur Gesamtlösung, aber nicht zur lokal betriebenen Maschine. Die Grenze hilft später bei drei Aussagen:

1. Die Druckregelung bleibt eine lokale Funktion.
2. Der Übergang zum Wartungsportal ist eine externe Schnittstelle.
3. Ein Ausfall des Portals darf die lokale Regelung nicht unterbrechen.

Eine andere Fragestellung könnte eine andere Grenze brauchen. Für eine reine Netzwerkanalyse würdest du möglicherweise nur Gateway, Netzkomponenten und Portal betrachten. Für eine elektrische Dokumentation müsstest du Anschlüsse und Schutzkomponenten genauer darstellen. Schreibe deshalb immer dazu, wofür eine Sicht erstellt wurde.

Trenne physischen Prozess, OT und externe IT

Der physische Prozess ist der Teil, in dem sich reale Größen verändern. Bei Edelgrund sind das unter anderem Sprühdruck, Wasserfluss und Reinigungswirkung. Diese Größen sind keine Softwaredaten. Ein Sensor bildet eine ausgewählte physische Größe erst in ein auswertbares Signal ab.

Operational Technology, kurz OT, umfasst Technik, die den physischen Prozess beobachtet oder beeinflusst. Dazu gehören in diesem Szenario Sensor, SPS, Frequenzumrichter, Pumpe und lokales Bediengerät. Die Zuordnung beschreibt ihre Rolle in der Anlage, nicht nur den Standort eines Geräts.

Das Edge-Gateway bildet den kontrollierten Übergang von der lokalen OT zur externen IT. Es sammelt freigegebene Zustandsdaten und überträgt sie an das Wartungsportal. Das Portal speichert und visualisiert Daten, greift in diesem Szenario aber nicht in die lokale Regelung ein.

Zeichne erst Rollen, dann Produkte

Eine frühe Architektur sollte Rollen benennen. “SPS”, “Edge-Gateway” und “Wartungsportal” erklären mehr als drei Produktnamen. Produkte, Modellnummern, Adressen und Ports kommen in nachgelagerte Sichten oder in ein Schnittstellenverzeichnis.

Für Edelgrund entstehen diese Rollen:

Die Tabelle deckt einen häufigen Modellierungsfehler auf: Die Pumpe “sendet” nicht einfach Druckdaten an die SPS. Sie verändert den physischen Prozess. Erst der Sensor erfasst die Wirkung und erzeugt ein Signal. Wenn physische Wirkung und Datenfluss gleich gezeichnet werden, geht die Rückkopplung im Plan verloren.

Kennzeichne Daten- und Wirkrichtung

Die folgende Architektur verwendet beschriftete Pfeile. Ein Pfeil beantwortet immer zwei Fragen: Was fließt? In welche Richtung? Doppelpfeile sind nur dann sinnvoll, wenn beide Richtungen fachlich benannt sind.

Die Diagrammgrenze zwischen Gateway und Wartungsportal ist fachlich wichtig. Der Pfeil überquert die lokale Systemgrenze und erzeugt damit eine externe Abhängigkeit. Gleichzeitig zeigt die fehlende Rückrichtung: Das Portal besitzt in dieser Ausbaustufe keine Steuerfunktion.

Beschreibe Schnittstellen neben dem Diagramm

Ein Übersichtsdiagramm bleibt lesbar, wenn Details in einem kleinen Schnittstellenverzeichnis stehen. Jede Schnittstelle braucht mindestens Quelle, Ziel, übertragene Information, Richtung und Bedeutung bei einem Ausfall. Ein konkretes Protokoll ist nur dann nötig, wenn es für die aktuelle Entscheidung bereits feststeht.

Die Einträge nennen bewusst keine erfundenen Sicherheits- oder Echtzeitgarantien. Solche Eigenschaften müssen als Anforderungen ergänzt und später geprüft werden. Für die Architekturentscheidung reicht hier: S1 und S2 gehören zum lokalen Regelkreis. S4 und S5 dienen der Beobachtung und dürfen diesen Regelkreis nicht zur Laufzeit voraussetzen.

Lies Rückkopplung und Abhängigkeiten aus dem Plan

Eine Rückkopplung entsteht, wenn die Wirkung eines Aktors über den physischen Prozess wieder gemessen und in die nächste Steuerentscheidung einbezogen wird. Bei Edelgrund verläuft sie so:

1. Die SPS gibt einen Stellwert aus.
2. Frequenzumrichter und Pumpe verändern den Wasserfluss.
3. Der veränderte Wasserfluss beeinflusst den Sprühdruck.
4. Der Drucksensor erfasst den neuen Zustand.
5. Die SPS verarbeitet den neuen Messwert.

Der Regelkreis ist erst geschlossen, wenn der Wirkungspfad über den physischen Prozess wieder zum Messpfad führt. Eine reine Datenrunde zwischen SPS und Portal wäre keine physische Rückkopplung.

Aus der Architektur lassen sich außerdem Abhängigkeiten ableiten. Der Drucksensor und die SPS sind für die dargestellte Regelung unmittelbar erforderlich. Das Wartungsportal ist für die externe Auswertung erforderlich, aber nicht für die lokale Regelung. Diese Unterscheidung hilft bei Ausfallanalyse, Tests und Sicherheitsbetrachtung.

Prüfe eine Zeichnung auf fünf typische Lücken

Eine Architektur ist kein vollständiger Schalt-, Netzwerk- oder Sicherheitsplan. Sie muss aber genug zeigen, damit das Team dieselbe Systemaussage liest. Prüfe deshalb fünf Punkte:

1. Zweck und Grenze: Ist erkennbar, welche Fragestellung die Sicht beantwortet und was außerhalb liegt?
2. Rollen: Sind physischer Prozess, Sensor, Verarbeitung, Aktor, Übergang und externe Dienste unterscheidbar?
3. Richtungen: Ist jeder relevante Daten-, Steuer- oder Wirkweg gerichtet und benannt?
4. Rückkopplung: Führt die Aktorwirkung über den physischen Prozess wieder zu einer Messung?
5. Abhängigkeiten: Ist erkennbar, welche Funktion bei einem Schnittstellenausfall betroffen ist?

Mehr Details machen eine Zeichnung nicht automatisch besser. IP-Adressen, Klemmenbezeichnungen, Datenfelder und Sicherheitsregeln können eigene Sichten brauchen. Entscheidend ist, dass diese Sichten der Übersichtsarchitektur nicht widersprechen.

Entwirf eine zweite Architektur selbst

Was eine belastbare CPS-Architektur leistet

Eine gute Architekturzeichnung macht nicht jedes technische Detail sichtbar. Sie beantwortet die Fragen, die für ihren Zweck nötig sind. Dafür ziehst du eine begründete Systemgrenze, ordnest Komponenten nach ihrer Rolle und beschriftest jeden wesentlichen Fluss mit Inhalt und Richtung.

Der wichtigste Unterschied liegt zwischen Daten und Wirkung. Ein Sensor erzeugt aus einer physischen Größe ein Signal. Eine Steuerung verarbeitet Signale. Ein Aktor verändert den physischen Prozess. Erst wenn diese Wirkung wieder gemessen wird, entsteht eine physische Rückkopplung. Externe IT-Dienste können Daten nutzen, ohne automatisch Teil des lokalen Regelkreises zu sein.

Damit steht die Übersichtsarchitektur. Eine Kommunikationslektion kann darauf konkrete Protokolle und Zustellregeln planen. Eine Integrationslektion kann elektrische Schnittstellen und Signale ausarbeiten. Die Architektur hält diese Sichten zusammen, ohne sie vorwegzunehmen.

Belegmatrix

Die Ordnungsmittel belegen die berufliche Handlung, aber keine konkrete Produktarchitektur. Unternehmen, Geräteanordnung, Schnittstellen und Ausfallannahmen des Edelgrund-Szenarios wurden für diese Lektion neu erstellt. Die Lektion übernimmt keine Prüfungsaufgabe und trifft keine Aussage dazu, welches Thema in einem bestimmten Prüfungstermin vorkommt.