Web-HMI-Runtime

Diese Notiz hält die entstehende Idee einer modernen PCS-HMI-/Runtime-Plattform neben dem Siemens-PLC-Projekt fest. Sie ist keine finale Architekturentscheidung. Sie ist eine Arbeitsvision für Experimente, Diskussion und Lernen.

Die Kernidee ist, die PLC deterministisch und Siemens-standardkonform zu halten, während Visualisierung, Dokumentation, Alarmhistorie, Diagnosen und Bediener-/Service-Tooling in einen versionierten Web-Stack verlagert werden.

Git repository
  -> TIA SCL source
  -> HMI frontend
  -> backend / PLC gateway
  -> alarm model
  -> documentation
  -> release manifest

Industrial box PC
  -> serves HMI
  -> serves version-specific docs
  -> communicates with PLC
  -> stores alarm/event history

S7 PLC
  -> deterministic control
  -> interlocks and trips
  -> process status
  -> command and parameter interface

Motivation

Traditionelles TIA-HMI-Engineering ist vertraut und integriert, kann sich im Vergleich zu moderner Softwareentwicklung aber auch einschränkend anfühlen:

• UI-Design ist oft schwer sauber, responsiv und bedienerfreundlich umzusetzen.
• Wiederverwendung über Projekte hinweg ist durch herstellerspezifische Engineering-Workflows begrenzt.
• HMI, PLC-Logik, Dokumentation und Commissioning-Wissen gemeinsam zu versionieren ist schwierig.
• Moderne Engineering-Praktiken wie Code Review, statische Assets, automatisierte Builds, Package-Manifeste und webbasierte Dokumentation sind im klassischen HMI-Workflow nicht first-class.

Die vorgeschlagene Richtung ist nicht "Web, weil Web modern klingt". Das nützliche Argument ist:

Den zuverlässigen Siemens-PLC-Kern behalten, aber Wartbarkeit, Versionierung, Dokumentation, Servicefähigkeit und Bedienerlebnis darum herum verbessern.

Vorgeschlagene Architektur

Für ein ernsthaftes System soll der Browser in der finalen Architektur nicht direkt mit der PLC sprechen. Ein kleines Backend auf dem Industrial Box PC soll als PLC-Gateway dienen.

Browser HMI
  -> HTTPS
Node.js backend / gateway on box PC
  -> S7 Web API, OPC UA, or another PLC protocol
S7 PLC

Das Backend stellt eine kontrollierte Grenze bereit:

• PLC-Sessions und Zertifikate verwalten,
• rohe PLC-Adressen vor dem Browser verbergen,
• domänenorientierte HMI-APIs bereitstellen,
• Bedienerschreibzugriffe validieren,
• Befehle rate-limiten und loggen,
• Alarm-/Event-Historie speichern,
• Live-Updates über WebSockets oder Server-Sent Events bereitstellen,
• die versionsspezifische Dokumentationsseite bereitstellen.

Das Browser-Frontend kann dann mit einem modernen Stack wie Vue und Tailwind gebaut werden, während die PLC für Echtzeit-Control-Verhalten verantwortlich bleibt.

Hardware- und Netzwerkkonzept

Eine realistische Entwicklungs- und spätere Produktionsform ist ein Multi-Interface-Box-PC zwischen PLC, lokalem HMI-Touchscreen und optionalem Service- oder Crew-Netzwerk.

Beispielhardware:

Komponente	Entwicklungsrolle	Produktionsrichtung
S7-1500 CPU	Echte PLC-Zielhardware für Web-API-/OPC-UA-Tests	PCS-Controller mit getrennten Anlagen- und Visualisierungsschnittstellen
Mini-PC / Box-PC	Führt Backend, Frontend, Docs und Logs aus	Industrial PC mit 24 VDC, Watchdog, Lifecycle, Montage und Zulassungen nach Bedarf
Touchdisplay	Browser im Kiosk-Modus	Maritimes/industrielles Touchpanel mit geeigneter Helligkeit, Dimmung, IP-Schutzart und Zulassungen
Service-/ECR-PC	Liest Docs und eventuell read-only Diagnosen	Eingeschränkter Netzwerkzugriff auf Dokumentation und Service-Seiten

Beispiel-Netzwerklayout:

PLC X1:
  Plant / PROFINET IO
  192.168.0.1/24

PLC X2:
  Visualization backend
  192.168.240.1/24

Box PC NIC 1:
  PLC network
  192.168.240.100/24

Box PC NIC 2:
  Local touchscreen / kiosk network
  192.168.241.100/24

Box PC NIC 3:
  Service / ECR / crew network
  192.168.50.100/24

Der Box-PC soll normalerweise nicht als IP-Router zwischen diesen Netzwerken agieren. Das PLC-Netzwerk soll nicht dadurch vom Service- oder Crew-Netzwerk erreichbar werden, dass beide Kabel im selben Computer stecken.

Stattdessen veröffentlicht das Backend nur die beabsichtigten Informationen erneut:

• PLC-Kommunikation ist auf das Backend an der PLC-seitigen Schnittstelle begrenzt.
• Der lokale Touchscreen erhält das vollständige HMI-Erlebnis.
• Das Service- oder Crew-Netzwerk kann Dokumentation, Release Notes, Versionsinformationen und read-only Diagnosen erhalten.
• Steueraktionen bleiben auf das vorgesehene HMI-Netzwerk und autorisierte Rollen beschränkt.

Das gibt nützlichen Zugriff, ohne versehentlich einen breiten Pfad in die PLC zu erzeugen.

Zugriffstrennung

Die Runtime soll Netzwerktrennung mit Applikationsrollen kombinieren.

Beispiel für Route-Exposition:

Route	Touchscreen-Netzwerk	Service-/ECR-Netzwerk
/hmi	erlaubt	blockiert oder read-only Variante
/alarms	erlaubt	optional read-only
/diagnostics	erlaubt	optional read-only
/docs	erlaubt	erlaubt
/release-notes	erlaubt	erlaubt
/admin	nur Engineer/Admin	nur Engineer/Admin

Beispielrollen:

Rolle	Beabsichtigte Berechtigungen
Viewer	Docs, Version, Release Notes, read-only Status
Operator	HMI-Screens, normale Befehle, Alarmquittierung
Engineer	Diagnosen, Parameterseiten, Commissioning-Tools
Admin	Benutzer, Konfiguration, Updates

Für einen lokalen Kiosk kann der Touchscreen als Operator-Rolle angemeldet bleiben. Auf Service- oder ECR-PCs sollen Benutzer sich mit eigenen Credentials anmelden und nur die Berechtigungen erhalten, die sie brauchen.

Mögliches Runtime-Layout

Box PC
  C:\PCS\
    app\
      backend\
      frontend\
      docs\
      config\
      logs\
      data\
        alarms.sqlite
    releases\
      PCS_1.2.0\
        manifest.json
        changelog.md
        plc\
        hmi\
        docs\

Mögliche lokale URLs:

https://pcs-hmi.local/
https://pcs-hmi.local/alarms
https://pcs-hmi.local/diagnostics
https://pcs-hmi.local/docs
https://pcs-hmi.local/version

Die Dokumentation kann mit MkDocs gebaut und vom selben Backend, von nginx, von Caddy oder von einem anderen kleinen statischen Webserver als statische Dateien bereitgestellt werden.

PLC-Datenschnittstelle

Die PLC soll absichtliche HMI-Interface-DBs bereitstellen, statt dem HMI zu erlauben, beliebige Interna zu lesen und zu schreiben.

Beispiel:

DB_HMIStatus
  read-only status values for visualization

DB_HMICommands
  operator command requests
  command IDs
  acknowledgements
  rejection reasons

DB_HMIParameters
  editable parameters with validation in PLC logic

DB_AlarmActive
  active alarm states
  priorities
  acknowledgement states

DB_EventBuffer
  sequence-numbered event/alarm transitions

Das HMI soll Befehle senden, nicht direkt internes Verhalten forcieren. Die PLC validiert jeden Befehl und bleibt die Instanz für akzeptierte Steueraktionen.

Rolle der S7 Web API

Das erste erfolgreiche Experiment verwendete die Siemens S7 Web API, bereitgestellt von einer simulierten S7-1500 in PLCSIM Advanced.

Der Grundablauf ist:

1. Eine JSON-RPC-Api.Login-Anfrage per POST an die PLC senden.
2. Ein Authentifizierungstoken empfangen.
3. Spätere Anfragen mit dem Header X-Auth-Token senden.
4. PLC-Variablen über PlcProgram.Read und PlcProgram.Write lesen und schreiben.

Beispiel-Endpunkt:

https://192.168.240.1/api/jsonrpc

Beispiel-Login-Request:

[
  {
    "jsonrpc": "2.0",
    "method": "Api.Login",
    "params": {
      "user": "Anonymous",
      "password": ""
    },
    "id": 1
  }
]

Beispiel-Read-Request:

[
  {
    "jsonrpc": "2.0",
    "method": "PlcProgram.Read",
    "params": {
      "var": "\"DB_HMIStatus\".inCounter"
    },
    "id": 11
  }
]

Die Web API ist vielversprechend, weil sie HTTP/JSON-basiert ist und gut zu einem Node.js-Backend passt. Für Produktion soll OPC UA trotzdem ernsthaft verglichen werden, besonders für Subscriptions, Informationsmodellierung, Zertifikatsbehandlung und Third-Party-Integration.

Minimaler Counter-Prototyp

Ein erster Proof of Concept existiert im Repository:

tools/s7-webapi-counter/
  index.html
  README.md

Die Seite ist bewusst einfach und frameworkfrei. Sie demonstriert die kleinste nützliche Schleife:

Browser
  -> Api.Login
  -> PlcProgram.Read "DB_HMIStatus".inCounter
  -> PlcProgram.Write "DB_HMIStatus".inCounter

Die UI hat drei Kernelemente:

<button id="minus" type="button" disabled>-</button>
<output id="value">?</output>
<button id="plus" type="button" disabled>+</button>

Wenn verbunden, macht die Seite Folgendes:

• Anmeldung an der PLC als Anonymous,
• Speichern des zurückgegebenen Tokens,
• Lesen von "DB_HMIStatus".inCounter,
• Schreiben von currentValue - 1, wenn - geklickt wird,
• Schreiben von currentValue + 1, wenn + geklickt wird,
• periodisches Senden von Api.Ping, um die Session am Leben zu halten.

Das ist kein Production-HMI-Pattern. Es ist ein nützlicher Beweis, dass ein Browser über die S7 Web API mit der simulierten PLC kommunizieren kann.

In der Produktion sollen Login, Token-Handling, Zertifikatsvalidierung, Schreibvalidierung und Reconnect-Logik in einen Backend-Service wandern.

Cybersecurity und Zuverlässigkeit

Das Produktionsdesign muss von maritimem 24/7-Betrieb und eingeschränkten Betriebsnetzwerken ausgehen.

Wichtige Prinzipien:

• Die PLC muss sicher bleiben, wenn HMI oder Box-PC ausfallen.
• Der Browser soll sich mit dem Box-PC verbinden, nicht direkt mit der PLC.
• PLC-Schreibzugriff soll auf dedizierte Befehls- und Parameterschnittstellen begrenzt werden.
• Anonymous Access ist nur für isolierte Experimente akzeptabel.
• Produktion soll benannte Benutzer, Least-Privilege-Berechtigungen und verwaltete Zertifikate verwenden.
• Der Box-PC soll eine Firewall haben und nur erforderliche Ports öffnen.
• PLC-Web-API-Zugriff soll nur auf der vorgesehenen Visualisierungs-/Service-Schnittstelle aktiviert sein.
• Zertifikatsablauf, PLC-Zeitsynchronisierung und DNS-/IP-Namensgebung müssen Teil der Inbetriebnahme sein.
• Das HMI muss veraltete Daten, verlorene PLC-Verbindung, Backend-Fehler und Degraded Mode klar anzeigen.

Zertifikatsbehandlung braucht besondere Aufmerksamkeit. Eine schlechte Architektur würde verlangen, dass jeder Bedienerbrowser jedes PLC-Zertifikat manuell vertraut. Eine bessere Architektur ist:

Browser trusts box PC certificate.
Box PC backend trusts PLC certificate.
PLC certificate is managed through TIA Portal / project security settings.

Das reduziert bedienerseitige Zertifikatsprobleme und hält PLC-Authentifizierungsdetails in der Service-Schicht.

Richtung des Alarmsystems

Das Alarmsystem ist der sensibelste Teil dieser Idee.

Die PLC soll die Instanz für aktive Prozessalarme, Interlocks, Trips und sicherheitsrelevante Zustände bleiben. Der Box-PC kann Darstellung und Historie verbessern:

PLC
  -> active alarm state
  -> alarm ID
  -> priority
  -> acknowledgement state
  -> event sequence number
  -> optional timestamp

Backend
  -> polls or subscribes to alarm changes
  -> stores history
  -> handles filtering and sorting
  -> serves current alarm list
  -> exports reports

Für zuverlässige Ereigniserfassung soll die PLC einen Event Buffer oder Sequenzzähler bereitstellen. Das Backend darf nicht davon abhängen, dass ein Browser-Screen genau in dem Moment geöffnet ist, in dem sich ein Alarm ändert.

Research-Themen:

• PLC-generierte Event Buffer.
• Timestamp-Quelle und Clock-Synchronisation.
• Quittier-Handshake.
• Alarm Shelving-/Suppression-Regeln.
• First-up-Alarm-Logik.
• Historisches Speicherformat.
• Mapping auf maritime/Class-/Kundenanforderungen.

Argumente für interne Diskussion

Diese Idee soll nicht als Ablehnung von Siemens präsentiert werden. Ein stärkeres Framing ist:

• Die Siemens PLC bleibt die Control Authority.
• TIA Portal bleibt Engineering- und Compile-Umgebung.
• Die Web Runtime verbessert die Bediener- und Service-Schicht.
• Git wird zur Source of Truth für PLC-Code, HMI, Docs und Releases.

Nützliche Argumente:

Zielgruppe	Argument
Operator	Sauberere Screens, schnellere Navigation, bessere Touch-Ergonomie, bessere Alarmübersicht.
Commissioning Engineers	Versionsspezifische Docs, Live-Diagnosen, Signalübersicht, Release Notes vor Ort.
Service Engineers	Exakte Softwareversion, lokale Dokumentation, Logs, Alarmhistorie, einfacheres Troubleshooting.
Engineering Team	Wiederverwendbare Plattform, Code Review, strukturierte Releases, weniger Copy/Paste-Engineering.
Management	Stärkerer PCS-Standard, weniger projektspezifische Neuerfindung, bessere Wartbarkeit.

Verkaufe es nicht als "modernes Web ist besser als TIA HMI". Verkaufe es als kontrollierte Erweiterung des Siemens-PLC-Systems, die Lifecycle-Qualität verbessert.

Roadmap

Meilenstein 1: Schnittstellen erkunden

• S7-Web-API-Experimente mit PLCSIM Advanced fortsetzen.
• Ausgewählte HMI-DB-Werte lesen und schreiben.
• Reconnect-Verhalten und Token-Ablauf testen.
• Echte Hardware testen, sobald verfügbar.
• OPC UA für dieselben Werte vergleichen.

Meilenstein 2: HMI-DB-Vertrag definieren

• DB_HMIStatus entwerfen.
• DB_HMICommands entwerfen.
• DB_HMIParameters entwerfen.
• Alarmstatus-/Eventstrukturen entwerfen.
• Erlaubte Schreibzugriffe und Befehls-Handshakes dokumentieren.

Meilenstein 3: Backend-Prototyp

• Kleines Node.js-Gateway bauen.
• PLC-Login-/Token-Handling aus dem Browser herausziehen.
• Einfache REST-/WebSocket-API für das Frontend bereitstellen.
• Verbindungszustand und Reconnect-Logik ergänzen.
• Strukturiertes Logging ergänzen.

Meilenstein 4: Frontend-Prototyp

• Kleinen Vue-/Tailwind-HMI-Prototyp bauen.
• Statusübersicht-Screen ergänzen.
• Befehls-Testscreen ergänzen.
• Einfache Alarmliste ergänzen.
• Diagnoseseite ergänzen, die Backend-, PLC- und Release-Status zeigt.

Meilenstein 5: Dokumentations-Runtime

• MkDocs während des Release bauen.
• Statische Docs vom Box-PC bereitstellen.
• Sichtbare Softwareversion und Release-Manifest ergänzen.
• HMI-Screens dort mit relevanter Dokumentation verlinken, wo es nützlich ist.

Meilenstein 6: Commissioning-Paket

• Wiederholbares Box-PC-Deployment-Bundle erstellen.
• HMI, Backend, Docs, Config, Release-Manifest und Changelog einschließen.
• Backup/Restore für Konfiguration und Alarmhistorie definieren.
• Update- und Rollback-Schritte dokumentieren.

Meilenstein 7: Production Hardening

• Zertifikatsstrategie.
• Benutzer- und Rollenmodell.
• Netzwerksegmentierung.
• Watchdog und Service-Überwachung.
• Offline-/Degraded-UI-Zustände.
• Langzeit-Endurance-Test.
• Security Review.
• Maritime-/Kundenanforderungsreview.

Research-Checkliste

Zu untersuchende Themen:

• Methodenumfang und Grenzen der S7 Web API.
• S7-Web-API-Performance mit realistischen HMI-Tag-Anzahlen.
• Bulk Reads/Writes versus Einzelrequests.
• Token-Lebensdauer und Session-Limits.
• Zertifikatserzeugung und Trust-Chain-Management.
• PLC-Benutzerberechtigungen für Lese-/Schreibzugriff.
• OPC-UA-Subscriptions und Datenmodellierung.
• PLCSIM-Advanced-Netzwerkmodi.
• Verhalten echter S7-1500 CPUs im Vergleich zu PLCSIM Advanced.
• Browser-Kiosk-Modus auf dem maritimen Ziel-Touchdisplay.
• Box-PC-Betriebssystem und Service-Überwachung.
• Offline- und Degraded-Operation-Verhalten.
• Persistenz von Alarm-/Event-Historie.
• Class-/Kunden-Cybersecurity-Erwartungen.
• Backup-, Restore- und Update-Workflow.

Offene Fragen

• Welches Protokoll soll die primäre PLC-to-backend-Schnittstelle sein: S7 Web API, OPC UA oder eine Kombination?
• Wie viele Werte lassen sich bei der Ziel-Update-Rate komfortabel lesen?
• Wie sollen HMI-Screens deklarieren, welche Tag-Gruppen sie brauchen?
• Wo sollen Alarm-Timestamps erzeugt werden?
• Wie sollen Bedienerquittierungen in PLC-Logik dargestellt werden?
• Wie soll projektspezifische Schiffskonfiguration gespeichert und versioniert werden?
• Sollen HMI und PLC in einem Repository oder in Schwester-Repositories liegen?
• Was ist die kleinste nützliche Demo für Management und das breitere Team?

Ressourcen

• Siemens S7-1500 Web API overview
• Siemens Web API security notes
• Siemens certificate management for the web server
• S7-Web-API-Counter-Prototyp im Repository: tools/s7-webapi-counter/README.md