EMS Builder: Gesamtarchitektur, Betriebsmodi und Funktionsgrenzen

Edge-EMS Builder liegt zwischen Feldgeräten und übergeordneten Systemen. Es basiert auf autonomem Edge-Betrieb und kann um Cloud-Edge- sowie Mehrknotenkoordination erweitert werden. Datenerfassung, Zustandsberechnung, Regelauswertung und Aktionsausführung bilden einen kontinuierlich arbeitenden geschlossenen Regelkreis.

Dieser Artikel beantwortet vier Fragen:

1. In welche Schichten gliedert sich die Gesamtarchitektur von Edge-EMS Builder?
2. Welche Betriebsmodi sind möglich?
3. Wie werden Funktionen zu einer fachlichen Anforderung kombiniert?
4. Welche Erweiterungen ermöglichen kabelgebundene, drahtlose und standortübergreifende Verbindungen?

„Betriebsmodus“ bezeichnet hier die technische Betriebsweise, nicht das Geschäftsmodell. Die drei Kooperationsmodelle Platform, Solution und Co-create finden Sie unter Servicemodelle von Edge-EMS Builder.

1. Gesamtarchitektur: geschlossener Ablauf zwischen Feld, Edge und Cloud

Edge-EMS Builder läuft am Edge. CommBridge abstrahiert Unterschiede zwischen Feldprotokollen; MQTT, WebSocket und HTTP verbinden Cloud, Frontend und Drittsysteme.

Schicht	Kernaufgaben	Typische Komponenten / Kanäle
Geschäfts- und Cloudschicht	Zentrale Überwachung, Fernkonfiguration, Strategieverteilung, Betriebsanalyse und Integration externer Geschäftssysteme	JelinaCloud, Kundencloud, SCADA, Leitsysteme; MQTT / HTTP
Interaktions- und Integrationsschicht	Echtzeitdaten an Frontends senden, Steuerbefehle empfangen und externen Systemen Lese-/Schreibzugriffe bereitstellen	Individuelle Web-Frontends, Backend-Dienste; WebSocket / HTTP
EMS Builder-Edge-Engine	Einheitliche Daten, Echtzeitberechnung, Strategieauswertung, Aktionsausführung, Alarme, Freigaben und Konfigurationserweiterung	Datenmodell, Ausdrucksengine, Triggerschemata, Freigabeziele, UDE
CommBridge-Erfassungsschicht	Geräteprotokolle anbinden und Felddatenpunkte in für EMS Builder nutzbare Daten umwandeln	Modbus, OPC UA, S7, serielle Kommunikation, IEC 101/104, CAN usw.
Feldgeräteschicht	Echtzeitdaten bereitstellen und die tatsächliche Steuerung ausführen	PCS, BMS, Stromzähler, Ladestationen, PV-Wechselrichter, Sensoren und Drittgeräte

Gründe für die Schichtenarchitektur

• Geräteänderungen erfordern kein Umschreiben der Strategien: Protokolle und Datenpunkte werden in der Erfassungsschicht angepasst; übergeordnete Strategien verwenden einheitliche dataKey-Kennungen.
• Fachliche Änderungen greifen nicht in Kommunikationstreiber ein: Schwellenwerte, Zeitfenster und Steuerregeln werden in der Strategieschicht angepasst, ohne die Geräteprotokolle zu ändern.
• Oberfläche und Steuerungsengine sind entkoppelt: Edge-EMS Builder ist nicht an eine feste UI gebunden. Frontends können über Standardkanäle Daten abonnieren und Steueraktionen auslösen.
• Der lokale geschlossene Ablauf kann auch ohne Cloud erhalten bleiben: Kritische Entscheidungen und Aktionen werden am Edge ausgeführt. Die konkreten Offline-Funktionen hängen von Projektkonfiguration und externen Abhängigkeiten ab.

2. Ablauf einer Steueraktion

Jede fachliche Strategie lässt sich in vier Schritte gliedern: Erfassung → Berechnung → Entscheidung → Ausführung.

Schritt	Aufgabe von EMS Builder	Beispiel: Kapazitätsstützung im Trafobereich
① Erfassung	CommBridge liest Rohdatenpunkte und synchronisiert sie mit EMS Builder	Transformatorlast, PCS-Zustand und SOC lesen
② Berechnung	Die Ausdrucksengine berechnet Zwischenzustände, Reserven oder Risiken	Kapazitätsdefizit und verfügbare Entladeleistung des Speichers berechnen
③ Entscheidung	Triggerschemata prüfen Bedingungen und wählen Aktionen	Unterstützung starten, wenn sich die Last dem Grenzwert nähert und der SOC dies zulässt
④ Ausführung	Geräte beschreiben, Alarme protokollieren, MQTT veröffentlichen oder Frontends aktualisieren	Leistungsvorgabe an PCS senden und Ausführungsstatus melden

Nach der Ausführung werden Leistung, SOC und Gerätezustand erneut erfasst und in der nächsten Auswertung berücksichtigt. Eine stabile Strategie benötigt außerdem Ein- und Ausschaltschwellen, Entprellung, Prioritäten, Behandlung von Kommunikationsfehlern, Geräteschutz und manuelle Übernahme – über ein einfaches IF / THEN hinaus.

Zwei durchgängige Unterstützungsmechanismen

• Freigabeziele: Daten anderer Edge-EMS Builder-Knoten können wie lokale Daten in Ausdrücke und Triggerbedingungen einfließen und geräteübergreifende Koordination ermöglichen.
• Dynamische Erweiterung von Geräteeinheiten (UDE): Eine Vorlage wird einmal pro Gerätetyp definiert. Neue Instanzen materialisieren daraus automatisch Aggregationen, Gruppen und Freigabekonfigurationen und reduzieren wiederholte Konfiguration.

3. Drei Betriebsmodi

Alle drei Modi verwenden dieselbe Edge-EMS Builder-Engine. Sie können einzeln oder kombiniert im selben Projekt eingesetzt werden.

1. Autonomer Edge-Betrieb

Erfassung, Berechnung, Entscheidung und Steuerung erfolgen vollständig am Standort. Geeignet für hohe Anforderungen an Reaktionsgeschwindigkeit, kontinuierlichen Betrieb und lokale Datenhaltung.

Typischer Ablauf: Feldgeräte → CommBridge → Edge-EMS Builder-Strategie → Feldgeräte

Geeignete Anforderungen: Zeitabhängiges Laden und Entladen, Rückspeisevermeidung, Lastspitzenbegrenzung, Geräteverriegelungen und lokale Alarme.

Planungsschwerpunkt: Lokaler Schutz hat Vorrang. Für Abhängigkeiten von externen Stromtarifen, Wetterdaten oder Cloudbefehlen sind Zwischenspeicherung, Zeitüberschreitungen und Rückfallstrategien vorzusehen.

2. Cloud-Edge-Koordination

Der Edge übernimmt die Echtzeitausführung, die Cloud zentrale Verwaltung, Strategieorchestrierung, Fernwartung oder standortübergreifende Analyse. MQTT unterstützt bidirektionales Publish/Subscribe sowie Antworten. Edge-EMS Builder kann außerdem über HTTP autorisierte externe Informationen abrufen.

Typischer Ablauf: Cloud sendet Ziele/Strategien → Edge validiert und führt aus → Ergebnisse werden an die Cloud zurückgemeldet

Geeignete Anforderungen: Überwachung mehrerer Standorte, Fernanpassung von Parametern, Verteilung von Sollverläufen, Betriebsanalyse und zentrale Alarme.

Planungsschwerpunkt: Cloudziele dürfen lokale Sicherheitsgrenzen nicht umgehen. Für Netzunterbrechungen muss festgelegt werden, ob die Ausführung fortgesetzt, der letzte gültige Wert gehalten oder eine Sicherheitsstrategie aktiviert wird.

3. Mehrknotenkoordination

Mehrere Edge-EMS Builder-Knoten synchronisieren Daten über Freigabeziele. Ein Hauptknoten kann Zustände untergeordneter Knoten zusammenführen und zentral berechnen; untergeordnete Knoten können nach einem Rollenwechsel neue Aufgaben übernehmen.

Typischer Ablauf: Untergeordnete Knoten geben Daten frei → Hauptknoten berechnet Standortziele → Knoten setzen die zugeteilten Vorgaben um

Geeignete Anforderungen: Leistungsverteilung auf mehrere Geräte, bereichsübergreifende Gruppensteuerung, standortweites Lastmanagement, Redundanz und Rollenwechsel.

Planungsschwerpunkt: Haupt-/Unterknotenbeziehungen, Freigabeintervalle, Datenaktualität, Netzwerkfehlerzustände und lokale Strategien bei Verbindungsverlust definieren.

4. Kernfunktionen und Betriebsunterstützung

Funktion	Gelöste Aufgabe	Position im geschlossenen Ablauf
Datenmodell	Einheitliche Organisation von Roh-, Zeitplan-, Aggregations- und freigegebenen Daten	Grundlage für Erfassung und Berechnung
Ausdrucksengine	Summierung, Filterung, Zustandsbewertung und geräteübergreifende Berechnung mit Lua	Berechnung
Triggerschemata	Fachliche Regeln aus Bedingungen und Aktionen zusammensetzen	Entscheidung und Ausführung
Cloud-Edge-Koordination mit MQTT	Datenveröffentlichung, Befehlsabonnements, Antworten und bidirektionale Cloud-Edge-Kommunikation	Cloud-Edge-Verbindung
Gerätekoordination und Freigabeziele	Daten zwischen Knoten teilen und gegenseitig in Berechnungen einbeziehen	Verteilte Koordination
Dynamische Erweiterung von Geräteeinheiten (UDE)	Vorlagen, dynamische Platzhalter und Abgleich bestehender Instanzen	Skalierung
Alarmlebenszyklus	Störung, Wiederherstellung und manuelle Lösung verfolgen	Zustand und Bearbeitung
Historie und Archivierung	Trendanalyse, asynchroner Export und mehrere Archivierungspläne	Datenaufbewahrung
Betrieb und Wartung	Kapazitätsempfehlungen, Konfigurationsquellen, Wartungssperre und Steuerungsprotokolle	Dauerbetrieb

Zusätzlich bietet Echtzeitübertragung und direkte Steuerung für Frontends einen WebSocket-Kanal für Frontend- und Backend-Systeme. Individuelle Oberflächen können Echtzeitdaten abonnieren und innerhalb der Berechtigungs- und Sicherheitsvorgaben Steueraktionen auslösen.

5. Funktionen für unterschiedliche Anforderungen kombinieren

Edge-EMS Builder setzt nicht voraus, dass jedes Projekt dieselbe Strategie verwendet. Stattdessen unterstützt dieselbe Konstruktionsweise unterschiedliche Anforderungen:

Anforderung = erforderliche Daten + Berechnungsregeln + Auslösebedingungen + Ausführungsaktionen + Schutz und Validierung

Anforderung	Erforderliche Daten	Berechnung und Bewertung	Typische Aktion
Lastspitzenkappung / Lastverlagerung / Leistungsbegrenzung	Leistung am Netzanschlusspunkt, SOC, PCS-Zustand und Leistungsziel	Leistungsdefizit sowie verfügbare Lade- und Entladeleistung berechnen	PCS-Leistung vorgeben und Strategiestatus protokollieren
Rückspeisevermeidung	Leistung am Netzanschlusspunkt, PV-Leistung und verfügbare Speicherleistung	Rückspeisetendenz erkennen und Ausgangsleistung begrenzen	Speicher laden, PV-Leistung begrenzen oder alarmieren
Lastmanagement für Ladestationen	Transformatorreserve, Leistungsbedarf und Zustand jeder Ladestation	Verfügbare Leistung berechnen und regelbasiert verteilen	Leistungsgrenzen der Ladestationen anpassen
Koordination mehrerer Geräte	SOC, Leistungsgrenzen und Verfügbarkeit jeder Einheit	Standortziel nach SOC, Kapazität oder Priorität verteilen	Teilziele an mehrere PCS/Knoten senden
Zeitpläne und Sollverläufe	Zeitfenster, Stromtarif, SOC und Lastprognose	Aktuelles Zeitfenster bestimmen und Schutzgrenzen prüfen	Lade-/Entladeziele wechseln und Ausführungsergebnisse zurückmelden
Steuerung anhand externer Informationen	Stromtarif, Wetter, Produktionsplan und Prognoseergebnisse	Datenaktualität prüfen und Daten in Optimierung oder Bewertung einbeziehen	Ziele anpassen, Rückfallstrategie aktivieren oder alarmieren

Beispiel: eine fachliche Anforderung in EMS Builder-Konfiguration übersetzen

Die Anforderung lautet:

„Überschreitet die Leistung am Netzanschlusspunkt 800 kW und liegt der SOC über 20 %, soll der Speicher automatisch entladen. Unter 760 kW soll die Unterstützung enden.“

Für die Umsetzung müssen mindestens folgende Elemente konfiguriert werden:

1. Daten für Netzanschlussleistung, SOC, PCS-Verfügbarkeit und maximale Entladeleistung;
2. Ausdrücke für das Kapazitätsdefizit und die Zielentladeleistung;
3. Zwei Schaltschwellen: Start bei 800 kW, Ende bei 760 kW;
4. PCS-Schreibaktionen, Frequenzbegrenzung und Fehlerbehandlung;
5. Schutz anhand von SOC, Temperatur und Alarmen, manuelle Übernahme sowie Strategien bei Kommunikationsfehlern;
6. Tests für Normalbetrieb, Grenzfälle, Netzunterbrechung und Gerätefehler.

Edge-EMS Builder stellt somit die Infrastruktur zum Beschreiben und Ausführen von Strategien bereit. Ihre Sicherheit und Korrektheit hängen weiterhin von der Anforderungsdefinition, den Gerätefähigkeiten und der Qualität der Validierung ab.

6. Möglichkeiten kabelgebundener, drahtloser und standortübergreifender Verbindungen

Die Kernlogik von Edge-EMS Builder ist vom konkreten Netzwerkmedium entkoppelt. Netzwerkfähigkeit bedeutet jedoch nicht, dass jede drahtlose Verbindung für Echtzeitsteuerung geeignet ist.

Übergeordnetes IP-Netzwerk

MQTT/MQTTS, HTTP und WebSocket können über erreichbare IP-Netzwerke betrieben werden. Je nach Hardware und Netzwerkbedingungen können Projekte Ethernet, WLAN, 4G/5G oder private Netze zur Verbindung mit der Cloud und anderen Knoten verwenden.

Dies beschreibt die architektonische Machbarkeit und ist keine Zusicherung integrierter Funkmodule in der Edge-Hardware von Edge-EMS Builder. Konkrete Funkfähigkeiten müssen anhand der gewählten Hardware, des Mobilfunknetzes, der lokalen Abdeckung und der Zertifizierungsanforderungen geprüft werden.

Feldgerätenetzwerk

Ob PCS, BMS, Zähler und andere Geräte drahtlos angebunden werden können, hängt von den Geräten selbst, den Funkgateways und der Protokollunterstützung in CommBridge ab. Funk ist lediglich ein Übertragungsweg und löst nicht automatisch Fragen der Registerzuordnung, Echtzeitfähigkeit oder Steuerungsberechtigung.

Zusätzliche Anforderungen bei Funk- oder WAN-Verbindungen

• Latenz und Jitter: Geschlossene Abläufe im Millisekundenbereich sollten lokal bleiben. WAN-Verbindungen eignen sich eher für Zielvorgaben, Datenmeldungen und Koordination ohne harte Echtzeitanforderungen.
• Verbindungsabbrüche und veraltete Daten: Kennzeichnen Sie die Aktualität freigegebener Daten und definieren Sie Halte-, Rückfall- oder Abschaltstrategien bei Verbindungsverlust.
• Sicherheit: Verwenden Sie TLS, Authentifizierung, minimale Berechtigungen und Auditierung. Vermeiden Sie die direkte öffentliche Erreichbarkeit von Gerätesteuerschnittstellen.
• Schutz vor Ort: Hardwareverriegelungen, Geräteschutz und lokale Sicherheitssteuerung dürfen nicht von Cloud oder instabilen Verbindungen abhängen.

Daraus ergibt sich folgende allgemeine Empfehlung:

Echtzeitsteuerung bleibt am Edge; Optimierungsziele können aus der Cloud kommen. Funk stellt die Verbindung her, Sicherheits- und Ausfallkonzepte sichern den Betrieb ab.

7. Von drahtloser Vernetzung zu vielfältiger Erweiterung

Die Funktionsgrenzen von Edge-EMS Builder lassen sich anhand dreier Voraussetzungen beurteilen:

Voraussetzung	Zu klärende Frage
Daten sind verfügbar	Lassen sich die benötigten Zustände zuverlässig erfassen, und sind Quelle sowie Aktualität vertrauenswürdig?
Regeln sind ausdrückbar	Lassen sich Ziele, Einschränkungen, Prioritäten und Fehlerpfade eindeutig beschreiben und testen?
Aktionen sind ausführbar	Bieten Geräte oder Systeme regelkonforme, autorisierbare und überprüfbare Steuerschnittstellen?

Sind alle drei Voraussetzungen erfüllt, kann Edge-EMS Builder über klassische EMS-Anwendungen hinaus für Gerätegruppensteuerung auf Betriebsgeländen, flexible Lastregelung, Anbindung an Produktionspläne sowie gemeinsame Umwelt- und Energiesteuerung eingesetzt werden – überall dort, wo Erfassung → Entscheidung → Ausführung benötigt wird.

Folgende Grenzen bleiben jedoch bestehen:

• Edge-EMS Builder ersetzt keine Schutzlogik des Geräteherstellers, Sicherheitszertifizierung oder lokale Verriegelung.
• Externe Prognosen oder KI-Ergebnisse benötigen Bereichsprüfung, Zeitüberschreitungsbehandlung und sichere Begrenzung. Sie dürfen kritische Geräte nicht unter Umgehung deterministischer Regeln direkt steuern.
• Die Qualität der Mehrgerätekoordination hängt von Zeitbasis, Netzwerk, Datenqualität und Zielverteilungsalgorithmus ab.
• Neue Strategien müssen zunächst in einer Simulation oder Testumgebung validiert und anschließend kontrolliert in Produktion übernommen werden.

8. Bereitstellungskapazität: Messwerte als Ausgangspunkt

Das derzeit auf AFE-E630 validierte empfohlene Szenario S3.5 umfasst eine konfigurierte Erfassungslast von 5.000 Datenpunkten/s, 30 Aggregationsberechnungen, 90 Triggern/s, 20 MQTT-Vorgängen/s und 10 Koordinationsaufgaben/s. Gespeichert wird bei Änderungen, spätestens alle 10 Sekunden.

In der Testserie vom 2026-07-29 (Bericht v1.3) lagen die P95-Latenzen für Trigger und MQTT in diesem Szenario bei 56 ms bzw. 77 ms. Das P95 der CPU-Auslastung des Gesamtsystems betrug 71,09 %, das der tatsächlichen Arbeitsspeicherauslastung des Gesamtsystems 41,41 %. Für die erste Produktionsplanung wird eine technische Reserve von etwa 20 % gegenüber dieser getesteten Last empfohlen.

Diese Ergebnisse beruhen auf der angegebenen Hard- und Software sowie 2.000 gültigen Kurzzeitstichproben. Sie belegen keine Stabilität über 72 Stunden und lassen sich nicht direkt auf andere Skripte, Nachrichtengrößen oder Datenbankumfänge übertragen. Siehe AFE-E630-Leistungstestbericht.

Prüfliste vor dem Produktivstart

• Sind Gerätedatenpunktlisten, Dimensionen, Genauigkeit, Lese-/Schreibrechte und ungültige Werte geklärt?
• Sind Aktivierung, Beendigung, Entprellung, Prioritäten und Konfliktbehandlung der Strategie festgelegt?
• Gibt es Rückfallpfade für Netzunterbrechungen, veraltete Daten, offline befindliche Geräte und Schreibfehler?
• Sind Geräteschutz, Hardwareverriegelungen, manuelle Übernahme und Berechtigungsprüfung unabhängig wirksam?
• Wurden Lasttests mit tatsächlichen Skripten, Nachrichtengrößen, historischen Datenmengen und der Zielhardware durchgeführt?
• Sind Konfigurationsversionierung, Rollback-Verfahren sowie Protokoll- und Alarmüberwachung eingerichtet?

Nächste Schritte

• Produktnutzen und Einsatzszenarien: Produkteinführung zu Edge-EMS Builder.
• Konfigurationsobjekte kennenlernen: Grundbegriffe.
• Fachliche Konfigurationsabläufe: Temporäre Kapazitätserhöhung im Trafobereich oder Lastmanagement für Ladestationsgruppen.
• Frontend- und Cloudintegration: Echtzeitübertragung und direkte Steuerung für Frontends, Cloud-Edge-Koordination mit MQTT.