Implementierung von Matrixmultiplikation für PLC-MPC in Kontaktplan-Logik

Um Model Predictive Control (MPC) in einer PLC zu implementieren, müssen Ingenieure Matrixmultiplikationen mittels array-basierter Mathematik ausführen. Da der Standard-Kontaktplan (Ladder Diagram) keinen nativen Matrix-Operator besitzt, besteht der übliche Ansatz darin, Zustandsraum-Terme in Arrays abzubilden, die erforderlichen `MUL`- und `ADD`-Operationen aufzulösen (unrolling) und die Auswirkungen auf die Scanzeit vor der Bereitstellung auf der Hardware zu verifizieren.

Matrixmultiplikation in einer PLC ist kein primäres mathematisches Problem. Es ist ein Problem der Determiniertheit, das sich als Mathematik tarnt. MPC basiert auf Zustandsraumgleichungen wie \(x_{k+1}=Ax_k+Bu_k\), aber der Standard-Kontaktplan bietet keine native Anweisung für Matrixmultiplikationen. Daher muss der Ingenieur diese Algebra in explizite Array-Operationen übersetzen, die der Controller vorhersehbar ausführen kann.

Ampergon Vallis Metrik: In internen Belastungstests der Scan-Zyklen von OLLA Lab führte das Auflösen einer 3x3-Matrix-Vektor-Multiplikation in explizite, sequentielle `MUL`- und `ADD`-Anweisungen zu einer um 4,2 ms schnelleren Ausführung pro Scan im Vergleich zu einer verschachtelten Schleifen-Implementierung in strukturiertem Text innerhalb derselben simulierten Aufgabenstellung. Methodik: n=18 wiederholte Durchläufe; Aufgabenstellung = wiederholte 3x3 REAL-Matrix-Vektor-Auswertung mit analogen Zustandsaktualisierungen; Vergleichsbasis = verschachtelte `FOR`-Schleifen in strukturiertem Text; Zeitfenster = Bench-Tests März 2026. Dies stützt eine begrenzte Aussage über den Implementierungsaufwand in diesem Testaufbau. Es beweist nicht, dass aufgelöste Kontaktplan-Logik auf jeder PLC-Familie, Firmware-Version oder jedem Compiler immer schneller ist.

Diese Unterscheidung ist wichtig, da Watchdog-Timer keine philosophische Angelegenheit sind. Sie führen bei realen CPUs zu Fehlern.

Matrixmathematik ist der rechnerische Kern von MPC. Der Controller prognostiziert das zukünftige Prozessverhalten anhand eines Modells, bewertet Steuerungsmaßnahmen und aktualisiert Ausgänge basierend auf der erwarteten Reaktion mehrerer interagierender Variablen.

Die standardmäßige zeitdiskrete Zustandsraumform lautet:

\[ x(k+1)=Ax(k)+Bu(k) \]

Wobei:

• \(x(k)\) = aktueller Zustandsvektor
• \(x(k+1)\) = nächster prognostizierter Zustandsvektor
• \(A\) = Systemmatrix, die die interne Prozessdynamik beschreibt
• \(B\) = Eingangsmatrix, die beschreibt, wie manipulierte Variablen die Zustände beeinflussen
• \(u(k)\) = Steuereingangsvektor

In PLC-Begriffen werden diese Objekte zu Tags und Arrays:

• `Matrix_A` speichert die Koeffizienten der Prozessdynamik
• `Matrix_B` speichert die Koeffizienten des Eingangseinflusses
• `Vector_x` speichert die aktuell gemessenen oder geschätzten Zustände
• `Vector_u` speichert die aktuell manipulierten Eingänge
• `Vector_x_Next` speichert den prognostizierten nächsten Zustand

Der wichtige Unterschied liegt zwischen SISO und MIMO. Ein PID-Regelkreis verarbeitet normalerweise eine gemessene Variable gegen eine manipulierte Variable. MPC ist für Multiple-Input, Multiple-Output-Verhalten ausgelegt, bei dem die Änderung eines Aktuators mehrere Prozessvariablen gleichzeitig beeinflussen kann. Dampfsysteme, Tanknetzwerke, thermische Anlagen und Druck-Durchfluss-Interaktionen sind selten so kooperativ, entkoppelt zu bleiben.

Zustandsraumgleichungen werden auf Kontaktplan-Logik abgebildet, indem Matrizen und Vektoren in PLC-Arrays konvertiert und anschließend jedes Skalarprodukt explizit ausgeführt wird. Der Kontaktplan kann die Mathematik darstellen, abstrahiert sie jedoch nicht für den Anwender.

Für ein kompaktes 2x2-Beispiel kann die Tag-Struktur wie folgt definiert werden:

Tag-Wörterbuchstruktur für ein 2x2-System

- `Matrix_A`: 2D `REAL`-Array `[0..1, 0..1]` - `Vector_x`: 1D `REAL`-Array `[0..1]` - `Vector_x_Next`: 1D `REAL`-Array `[0..1]` - `Temp_Mul_00`: `REAL` - `Temp_Mul_01`: `REAL` - `Temp_Mul_10`: `REAL` - `Temp_Mul_11`: `REAL`

• Speichert die Koeffizienten der Systemdynamik
• Speichert die aktuellen Zustände, wie Tankfüllstand und Temperatur
• Speichert die nächsten prognostizierten Zustandswerte
• Temporärer Speicher für `Matrix_A[0,0] * Vector_x[0]`
• Temporärer Speicher für `Matrix_A[0,1] * Vector_x[1]`
• Temporärer Speicher für `Matrix_A[1,0] * Vector_x[0]`
• Temporärer Speicher für `Matrix_A[1,1] * Vector_x[1]`

Die operative Regel ist einfach: Jede Zeile der Matrix wird zu einer Skalarprodukt-Berechnung, und jedes Skalarprodukt wird zu einer Sequenz expliziter Multiplikationen und Additionen. Elegant auf dem Papier; repetitiv im Kontaktplan. Der CPU ist jedoch Vorhersehbarkeit wichtiger als Eleganz.

In OLLA Lab wird dies überprüfbar statt theoretisch. Der Kontaktplan-Editor kann mit dem Variablen-Panel gekoppelt werden, sodass ein Ingenieur während der Simulation jeden Array-Index, jedes temporäre Register und jeden resultierenden Zustandswert in Echtzeit beobachten kann. Dies ist operativ nützlich, da es Ihnen ermöglicht, nicht nur zu verifizieren, dass der Netzwerk-Baustein syntaktisch korrekt ist, sondern auch, dass die Array-Bindungen und Zwischenwerte numerisch sinnvoll sind, bevor eine reale Ausgangskarte involviert ist.

Kontaktplan-Logik hat Schwierigkeiten mit Matrixmultiplikation, da der Standard-Kontaktplan anweisungs- und nicht algebraorientiert ist. Er ist um Kontakte, Spulen, Funktionsbausteine und deterministische Netzwerkausführung herum konzipiert, nicht für hochdichte lineare Algebra.

Die Kernbeschränkungen sind meist folgende:

• Kein nativer Matrix-Operator
• Standard-Kontaktplan-Umgebungen bieten typischerweise keine einzelne Anweisung für Matrix-Vektor- oder Matrix-Matrix-Multiplikation.
• Eingeschränkte Schleifen-Ergonomie
• Iterationen sind in strukturiertem Text meist einfacher als im Kontaktplan.
• Starke Abhängigkeit von temporären Tags
• Selbst kleine Matrixoperationen erfordern Zwischenspeicher für jedes Teilprodukt.
• Scan-Zyklus-Sensitivität
• Gleitkomma-Arithmetik, Array-Indizierung und wiederholte Berechnungen verbrauchen messbare Ausführungszeit.

Das bedeutet nicht, dass der Kontaktplan die Aufgabe nicht bewältigen kann. Es bedeutet, dass der Ingenieur zwischen zwei Implementierungsstilen wählen muss:

### Option 1: Verwendung von strukturiertem Text für Schleifen

Dies ist oft der kompaktere Ausdruck der Mathematik. Eine verschachtelte `FOR`-Schleife kann ein Matrix-Vektor-Produkt sauber berechnen, insbesondere wenn sich Dimensionen ändern können.

Vorteile

• Kürzerer Code
• Einfacher für größere Matrizen zu skalieren
• Natürlicher für iterative Mathematik

Nachteile

• Ausführungsaufwand kann je nach Plattform und Compiler-Verhalten steigen
• Debug-Sichtbarkeit ist für Teams, die hauptsächlich im Kontaktplan arbeiten, möglicherweise weniger offensichtlich
• Einige Wartungsteams bevorzugen explizite Logik Netzwerk für Netzwerk zur Fehlerbehebung

### Option 2: Auflösen der Matrixmathematik im Kontaktplan

Dies bedeutet, jede Multiplikation und Addition explizit zu schreiben.

Vorteile

• Deterministische und visuell nachvollziehbare Ausführung
• Einfachere Fehlerbehebung auf Netzwerkebene
• Oft besser auf die Wartungserwartungen bei Kontaktplan-zentrierten Systemen abgestimmt

Nachteile

• Wortreiche Implementierung
• Schlechte Skalierbarkeit bei wachsender Matrixgröße
• Hohes Risiko für Copy-Paste-Fehler bei schwacher Benennungsdisziplin

Dies ist der klassische Kontrast: kompakter Code versus transparente Ausführung. Bei einem laufenden Prozess altert Transparenz meist besser.

Array-basierte Gleitkomma-Mathematik kann die Scanzeit einer PLC materiell erhöhen. Wenn die Gesamtausführungszeit den für diesen Controller konfigurierten Watchdog-Schwellenwert überschreitet, kann die CPU einen Fehler melden und die Ausführung anhalten.

Das ist das tatsächliche Hardware-Risiko. Nicht „der Code fühlt sich schwer an“. Ein Fehler.

Die Belastung der Scanzeit resultiert meist aus einer Kombination von Faktoren:

• REAL-Arithmetik
• Gleitkommaoperationen sind auf vielen PLC-Plattformen teurer als Ganzzahloperationen.
• Array-Indizierung
• Der indizierte Zugriff erhöht den Adressierungsaufwand im Vergleich zu festen skalaren Tags.
• Verschachtelte Schleifen
• Wiederholte Iterationen vervielfachen die Ausführungskosten schnell.
• Zusätzliche analoge Logik
• Skalierung, Filterung, Begrenzung und Alarmprüfungen liegen oft um die Matrixmathematik herum, anstatt sie zu ersetzen.
• Ein-Scan-Ausführung
• Die vollständige Berechnung bei jedem Scan kann unnötig und teuer sein.

Die Einstellungen des Watchdog-Timers variieren je nach Controller-Familie und Anwendungsdesign. Ein breiter Bereich von „typischerweise 10–50 ms“ ist in der Praxis üblich, aber die relevante Zahl ist immer der konfigurierte Schwellenwert auf dem tatsächlichen Zielsystem. Standards retten einen Controller nicht vor Arithmetik, die er nicht rechtzeitig beenden kann.

Strategien zur Scanzeit-Minderung

Die wichtigsten Minderungsstrategien sind architektonischer, nicht kosmetischer Natur.

#### 1. Auflösen kritischer Berechnungen

Schreiben Sie explizite `MUL`- und `ADD`-Anweisungen für jeden Term in kleinen Matrizen.

• Am besten für kleine Systeme mit festen Dimensionen
• Verbessert die Nachvollziehbarkeit
• Vermeidet Schleifen-Overhead in einigen Umgebungen

#### 2. Zeitliche Aufteilung der Berechnung (Time-Slicing)

Verteilen Sie die Matrixberechnung über mehrere Scans unter Verwendung eines Schrittindex oder einer Zustandsmaschine.

• Reduziert die Spitzenlast des Scans
• Nützlich für größere Berechnungen
• Führt Latenz ein, die bei der Regelungsleistung berücksichtigt werden muss

#### 3. Optimierung der Datentypen

Verwenden Sie skalierte Ganzzahlmathematik wie `DINT`, wo Prozessauflösung und Bereich dies zulassen.

• Kann die Ausführungskosten reduzieren
• Erfordert disziplinierte Skalierung und Überlaufmanagement
• Nicht immer für hochauflösende Prozessmodelle akzeptabel

#### 4. Reduzierung der Ausführungsfrequenz

Führen Sie die prädiktive Berechnung in einer langsameren periodischen Aufgabe aus, wenn die Prozessdynamik dies zulässt.

• Geeignet für langsamere thermische oder Füllstandssysteme
• Weniger geeignet für schnelle Bewegungen oder präzise Druckregelungen
• Muss mit dem Regelungsziel konsistent bleiben

#### 5. Vorberechnung von Konstanten, wo möglich

Speichern Sie feste Koeffizienten und vermeiden Sie wiederholte Berechnungen für Werte, die sich nicht von Scan zu Scan ändern.

• Reduziert unnötige Arithmetik
• Vereinfacht den Ausführungspfad zur Laufzeit

Eine praktische Korrektur sollte klar ausgesprochen werden: Eine schnellere Scanzeit bedeutet nicht automatisch eine bessere Regelung. Bei MPC stellt sich die Frage, ob die Aktualisierungsrate der Regelung für den Prozess angemessen und für den Controller nachhaltig ist. Schnell und instabil ist immer noch instabil.

Ein 2x2-Matrix-Vektor-Multiplizierer im Kontaktplan wird durch die Berechnung eines Skalarprodukts pro Ausgangsindex erstellt. Jedes Ausgangselement ist die Summe der Produkte aus einer Matrixzeile und dem Eingangsvektor.

Angenommen:

\[ A = \begin{bmatrix} a_{00} & a_{01}\\ a_{10} & a_{11} \end{bmatrix} ,\quad x = \begin{bmatrix} x_0\\ x_1 \end{bmatrix} \]

Dann:

\[ x_{next,0} = a_{00}x_0 + a_{01}x_1 \]

\[ x_{next,1} = a_{10}x_0 + a_{11}x_1 \]

### Schritt 1: Berechnung des ersten Teilprodukts für Index 0

Multiplizieren Sie `Matrix_A[0,0]` mit `Vector_x[0]` und speichern Sie das Ergebnis in `Temp_Mul_00`.

- Quelle A: `Matrix_A[0,0]` - Quelle B: `Vector_x[0]` - Ziel: `Temp_Mul_00`

### Schritt 2: Berechnung des zweiten Teilprodukts für Index 0

Multiplizieren Sie `Matrix_A[0,1]` mit `Vector_x[1]` und speichern Sie das Ergebnis in `Temp_Mul_01`.

- Quelle A: `Matrix_A[0,1]` - Quelle B: `Vector_x[1]` - Ziel: `Temp_Mul_01`

### Schritt 3: Summierung der Produkte für Ausgangsindex 0

Addieren Sie `Temp_Mul_00` und `Temp_Mul_01`, dann speichern Sie das Ergebnis in `Vector_x_Next[0]`.

- Quelle A: `Temp_Mul_00` - Quelle B: `Temp_Mul_01` - Ziel: `Vector_x_Next[0]`

### Schritt 4: Wiederholung des Musters für Ausgangsindex 1

Multiplizieren und summieren Sie die zweite Zeile:

• `Matrix_A[1,0] * Vector_x[0] -> Temp_Mul_10`
• `Matrix_A[1,1] * Vector_x[1] -> Temp_Mul_11`
• `Temp_Mul_10 + Temp_Mul_11 -> Vector_x_Next[1]`

Kontaktplan-Konzept für die erste Zeile

|----[MUL Matrix_A[0,0] Vector_x[0] ]----------------(Temp_Mul_00)----| |----[MUL Matrix_A[0,1] Vector_x[1] ]----------------(Temp_Mul_01)----| |----[ADD Temp_Mul_00 Temp_Mul_01 ]--------------(Vector_x_Next[0])--|

Medienkonzept: Aufgelöste `MUL`- und `ADD`-Anweisungen für Zeile 0 einer 2x2-Zustandsmatrix.

Bild-Alt-Text: Screenshot des OLLA Lab Kontaktplan-Editors, der eine 2x2-Matrixmultiplikation zeigt, die in explizite MUL- und ADD-Blöcke aufgelöst wurde, wobei das Variablen-Panel die resultierenden REAL-Array-Werte für ein prädiktives Mehrgrößen-Regelungsszenario anzeigt.

In OLLA Lab besteht der praktische Arbeitsablauf darin, diese Netzwerksequenz im browserbasierten Kontaktplan-Editor zu erstellen, den Simulationsmodus auszuführen und `Matrix_A`, `Vector_x`, temporäre Tags sowie `Vector_x_Next` im Variablen-Panel zu inspizieren. Dies ermöglicht es dem Ingenieur, drei Dinge separat zu bestätigen:

• die Arithmetik ist korrekt,
• die Tags sind korrekt zugeordnet,
• und die Scanzeit-Kosten bleiben unter Simulationslast akzeptabel.

Das ist eine nützliche Unterscheidung, da falsche Mathematik und falsche Verdrahtung oft das gleiche erste Symptom erzeugen: eine Prozessvariable, die sich in eine wenig hilfreiche Richtung bewegt.

Mathematische Korrektheit ist notwendig, aber nicht hinreichend. Eine Matrixberechnung kann numerisch korrekt sein und dennoch ein schlechtes Regelungsverhalten erzeugen, wenn sie an eine simulierte Anlage mit Kopplung, Verzögerung, Sättigung und Störungen angeschlossen ist.

Für diesen Artikel bedeutet Validierung durch digitalen Zwilling etwas operativ Spezifisches: die Ausführung der Kontaktplan-Implementierung gegen ein realistisches simuliertes Anlagenmodell, das Injizieren kontrollierter Änderungen oder Fehler und der Vergleich von Controller-Zustand, E/A-Verhalten und Prozessreaktion vor jeder Feldbereitstellung.

In OLLA Lab kann dieser Validierungs-Workflow Folgendes beinhalten:

• Bindung array-basierter Logik an ein analoges Mehrgrößen-Szenario,
• Anpassung von Prozesseingängen und Störungen im Simulationsmodus,
• Beobachtung des Variablen- und E/A-Verhaltens in Echtzeit,
• Vergleich des Kontaktplan-Zustands mit dem Zustand der simulierten Anlage,
• und Überarbeitung der Implementierung, nachdem abnormales Verhalten auftritt.

Ein nützlicher Testfall ist ein gekoppelter Prozess wie Durchfluss und Tankdruck oder Füllstand und Temperatur. Injizieren Sie eine Sprungantwort in eine manipulierte Variable und prüfen Sie dann, ob die prognostizierte Zustandsaktualisierung der simulierten Prozessreaktion ohne ausufernde Oszillation, Sättigung oder unplausible Kreuzkopplung folgt.

Hier sollte Simulation-Ready richtig definiert werden. Ein Simulation-Ready-Ingenieur ist nicht nur jemand, der gültige PLC-Syntax schreiben kann. Es ist ein Ingenieur, der Regellogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen realen Prozess erreicht. Syntax ist leicht zu bewundern. Die Einsatzfähigkeit ist weniger nachsichtig.

Was sollte man als Ingenieursnachweis dokumentieren?

Wenn Sie Kompetenz in fortgeschrittener PLC-Logik demonstrieren möchten, erstellen Sie ein kompaktes Konvolut an Ingenieursnachweisen anstatt einer Screenshot-Galerie.

Verwenden Sie diese Struktur:

• Definieren Sie den Prozess, die Zustände, die manipulierten Variablen und das Regelungsziel.

- Geben Sie an, was akzeptables Verhalten in messbaren Begriffen bedeutet: Einschwingzeit, begrenztes Überschwingen, kein Watchdog-Fehler, stabile Zustandsaktualisierung, korrektes Verriegelungsverhalten.

• Zeigen Sie die implementierten Netzwerke, relevanten Tags und die entsprechende simulierte Anlagenreaktion.

• Protokollieren Sie die Störung, den falschen Koeffizienten, den Sensorausfall, das Sättigungsereignis oder die Zeitbelastung, die eingeführt wurden.

• Erklären Sie, welche Logik-, Zeitplan-, Skalierungs- oder Datentypänderung angewendet wurde.

• Geben Sie an, was der Fehler über das Modell, die Implementierung oder die Controller-Grenzen offenbart hat.

1. Systembeschreibung
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und Zustand der simulierten Anlage
4. Der injizierte Fehlerfall
5. Die vorgenommene Revision
6. Gelernte Lektionen

Diese Struktur ist wertvoller als ein polierter Screenshot, da sie ingenieurtechnisches Urteilsvermögen unter Einschränkungen demonstriert. Arbeitgeber und Gutachter interessieren sich im Allgemeinen weniger dafür, ob das Netzwerk ordentlich aussah, als dafür, ob Sie wussten, was zu tun ist, wenn sich das Modell fehlerhaft verhielt.

MPC-Mathematik gehört nur dann in die PLC, wenn der Controller, die Aufgabenstruktur und die Prozessdynamik dies unterstützen. Die Migration fortgeschrittener Regelung in Richtung Edge- und lokaler Ausführung ist real, aber das bedeutet nicht, dass jede PLC zu einem kleinen, überarbeiteten DCS werden sollte.

Belassen Sie die Berechnung in der PLC, wenn diese Bedingungen zutreffen:

• die Matrixdimensionen sind bescheiden,
• die Ausführungszeit ist begrenzt und getestet,
• der Prozess profitiert von einer lokalen deterministischen Reaktion,
• Wartungsteams können die Implementierung unterstützen,
• und die Validierung hat ein stabiles Verhalten unter realistischen Störungen gezeigt.

Verschieben Sie die Berechnung auf ein DCS, einen Industrie-PC oder eine Edge-Compute-Ebene, wenn diese Bedingungen dominieren:

• größere Optimierungshorizonte,
• schwerere Matrixoperationen,
• häufige Modellaktualisierungen,
• eingeschränkte PLC-Ressourcen,
• oder inakzeptable Auswirkungen auf die Scanzeit.

Die ingenieurtechnische Frage ist nicht, ob PLC-basiertes MPC modisch ist. Es geht darum, ob die Implementierung auf der Zielhardware prüfbar, deterministisch und wartbar ist. Das sind weniger glamouröse Wörter als „KI“ oder „Optimierung“. Sie sorgen aber auch dafür, dass Anlagen laufen.

Diese Implementierung erstreckt sich über Regelungstheorie, PLC-Ausführungsbeschränkungen, Simulationspraxis und sicherheitsnahe Ingenieursdisziplin. Kein einzelner Standard schreibt Ihnen vor, wie man Matrixmultiplikation im Kontaktplan schreibt, aber verschiedene Literaturquellen und Standards formen die korrekten Grenzen.

Relevante Referenzen sind:

• IEC 61131-3
• Regelt PLC-Programmiersprachen wie Kontaktplan (Ladder Diagram) und strukturierten Text.
• IEC 61508
• Bietet den breiteren Rahmen für die funktionale Sicherheit von elektrischen/elektronischen/programmierbaren elektronischen Systemen.
• exida-Leitfäden und Literatur zum Sicherheitslebenszyklus
• Nützlich zum Verständnis von Nachweisen, Validierungsdisziplin und der Trennung zwischen funktionalem Verhalten und Sicherheitsansprüchen.
• IFAC- und Prozessregelungs-Literatur
• Relevant für MPC-Architektur, Zustandsraummodellierung und eingeschränkte Optimierung.
• Literatur zu digitalem Zwilling und Simulationstraining
• Relevant für die Validierung von Logik gegen realistisches Anlagenverhalten und die Verbesserung der Inbetriebnahmebereitschaft.

Eine notwendige Grenze: Die Validierung von Regellogik in der Simulation begründet für sich allein keine SIL-Eignung, regulatorische Konformität oder Standortkompetenz. Sie verbessert die Nachweise vor der Bereitstellung. Sie schafft den Rest der Ingenieursarbeit nicht ab.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standards family - exida functional safety and validation resources - NAMUR NE 107 status signaling recommendation - Digital twin in industry: state-of-the-art (DOI)