PDC Edge Prozessdatenerfassung

Nutzen

Quelle: Vision und Scope (Kapitel 01, Ziele Z1–Z10). Die Ergebnisse beschreiben das Zielbild; der Umsetzungsstand steht unten unter «Status».

Stand-alone oder mit der DF

PDC Edge ist ohne DF voll funktionsfähig und separat lizenzierbar. Keine Funktion des Basisumfangs wird ohne DF künstlich begrenzt. Mit der DF erreichen Sie mehr: Was fachlich MES-Logik ist, etwa OEE, Zustandsmaschine oder Auftragsverwaltung, liefert die DF.

Sicherheit

Schreiben auf eine Anlage ist ein Eingriff in die Produktion. PDC Edge behandelt es so: Alles ist zunächst gesperrt und wird gezielt freigegeben.

Status und Roadmap

Das Grundgerüst steht. Die Arbeiten am ersten produktiven Stand (M1, «MVP Stand-alone») laufen. Ein Release-Datum ist noch nicht festgelegt.

• M0Grundgerüst: Simulator → Verarbeitung → REST/WebSocket inklusive Schreiben, JavaScript-Verarbeitung, Builds für amd64 und arm64umgesetzt
• M1MVP Stand-alone: S7, OPC UA, Modbus TCP, MQTT; UNS über MQTT; Benutzer, Rollen, Write-Gate, Audit; UI. S7 und OPC UA sind umgesetztin Entwicklung
• M1bStandardisierung: Datenmodelle, Templates, virtuelle Signale und Kontext, Schreiben über UNS, neue Bedienführunggeplant (M1b)
• M2DF-Kopplung, DF-Bindings mit v1-Parität, Migration von PDC v1, Node-RED-Nodes vollständiggeplant (M2)
• M3Rockwell EtherNet/IP, Kafka, CoAP, DF-Write-Actions, eingebetteter MQTT-Brokergeplant (M3)
• M4Replikation, Hochverfügbarkeit, Cloud-Replikageplant (M4)
• M5OPC-UA-Server und Migrationshilfe für KEPServerEXgeplant (M5)

Quellen: Kapitel 10 (Meilensteine), CHANGELOG der Repos pdc-edge, pdc-edge-ui und node-red-contrib-autexis-pdc-edge. M1b ist als eigener Meilenstein beschlossen (PO-Entscheid E43).

Vier Konfigurationsebenen

Ein Signal wird einmal adressiert und dann beliebig oft verarbeitet, publiziert und gebunden. Das ersetzt die acht Pfad/Adress-Paare pro Datenpunkt aus PDC v1.

Treiber und Adressen

Jeder Treiber versteht eine Kurzform der Adresse. Eine strukturierte Form ist ebenfalls möglich.

Virtuelle Signale und Kontext geplant (M1/M1b)

Nicht jeder Wert kommt aus einer Steuerung. Virtuelle Signale sind vollwertige Signale mit UNS-Topic, Kontext und Modellzuordnung. Es gibt drei Quellenarten:

signals:
  - id: line3-order-no
    dataType: string
    access: read
    source:
      kind: external
      broker: { sink: uns-main }
      topic: acme/werk1/presswerk/linie3/order/current
      extract: { jsonPointer: /orderNo }
      timestamp: { jsonPointer: /validFrom }
    initial: null

namespace:
  nodes:
    - id: linie3
      slug: linie3
      level: line
      parent: presswerk
      context:
        orderNo: line3-order-no   # Kurzform, join latest

Inbetriebnahme

Der Ablauf folgt der Logik der Ebenen. Jede Änderung entsteht zuerst als Entwurf und wird erst nach der Prüfung als Revision aktiv.

1. Edge installierenBinary mit systemd oder Docker-Image starten, Datenverzeichnis festlegen. Beim ersten Start erzeugt die Edge ein eigenes TLS-Zertifikat.
2. Konfiguration prüfenpdc-edge validate <datei> prüft Schema und Semantik und endet mit Exit-Code 1 bei Fehlern.
3. Geräte anlegen und Verbindung testenVerbindungstest mit den Entwurfseinstellungen, ohne zu aktivieren (POST /devices/{id}/test, M1).
4. Signale anlegenEinzeln, aus einem Template, per CSV-Import oder per Browse des Adressraums (OPC UA).
5. Verarbeitung festlegen und testenProzessoren konfigurieren, JavaScript im Dry-Run gegen Beispielwerte prüfen.
6. Namespace und Ausgabe festlegenUNS-Baum nach ISA-95 aufbauen, Sinks und Routen für MQTT bzw. Kafka definieren.
7. Schreiben freigebenNur die nötigen Signale und Kanäle freigeben, Schreibbereitschaft prüfen.
8. Prüfen und aktivierenDiff und Befunde in der Prüfansicht ansehen, Revision aktivieren. Ein Rollback auf eine frühere Revision ist jederzeit möglich.

Quellen: Kapitel 02 §7, 03 §8–§9, 16 §4. Die geführten UI-Abläufe sind für M1/M1b geplant; bis dahin sind die Funktionen über YAML und API nutzbar.

Migration von PDC v1 geplant (M2)

Umgestellt wird pro Workplace und Funktion, nicht pro Gateway. Pro Workplace und Funktion gibt es genau einen Owner – das verhindert Doppelbuchungen in der DF. Ein Importer übernimmt die v1-Konfiguration, eine CLI pdc-edge migrate v1 dient der Offline-Analyse.

1. Importv1-Konfiguration als Entwurf importieren, Migrationsbericht prüfen und nacharbeiten.
2. SchattenbetriebEdge koppeln, Revision ausrollen. Die Edge rechnet mit, sendet aber nicht an die DF.
3. VergleichMindestens eine Schicht lang Edge-Ergebnisse mit den v1-Buchungen in der DF vergleichen.
4. UmschaltenOwnership je Funktion auf v2 stellen: Sensor, Energie, Equipment Notification, Unterbrechung, Maschinenzustand.
5. BeobachtenMindestens eine Woche. Ein Rollback auf v1 wirkt sofort, ohne Deployment.
6. Aufräumenv1-Nodes aus den Flows entfernen, Flows auf die Node-RED-Nodes von PDC Edge umstellen.

Quelle: Kapitel 08 §12, ADR 0032.

REST Basis umgesetzt

Umgesetzt sind health, info, signals, value, values und write. Der übrige Vertrag (Konfiguration, Revisionen, Audit, Freigaben) ist für M1 geplant.

curl -s https://pdc-edge:8443/api/v1/signals/press1-temp-oil/value \
  -H "Authorization: Bearer $PDC_API_TOKEN"

{
  "signal": "press1-temp-oil",
  "uns": "acme/werk1/presswerk/linie3/presse1/oil-temperature",
  "v": 72.4,
  "q": "good",
  "reason": null,
  "sourceTs": "2026-11-13T09:15:02.470Z",
  "edgeTs": "2026-11-13T09:15:02.481Z",
  "unit": "°C",
  "rev": 42
}

curl -s -X POST https://pdc-edge:8443/api/v1/signals/press1-orderno/write \
  -H "Authorization: Bearer $PDC_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "value": "A-2026-004711",
    "correlationId": "01JCA0V8Q3H4X9M2N5P7R1T6YB",
    "timeoutMs": 5000,
    "verify": "readBack",
    "wait": true,
    "comment": "Auftragsstart Linie 3"
  }'

{
  "writeId": "01JCA0V8R0000000000000000A",
  "correlationId": "01JCA0V8Q3H4X9M2N5P7R1T6YB",
  "signal": "press1-orderno",
  "status": "succeeded",
  "reason": null,
  "value": "A-2026-004711",
  "rawValue": "A-2026-004711",
  "verified": true,
  "requestedAt": "2026-11-13T09:20:00.010Z",
  "completedAt": "2026-11-13T09:20:00.094Z",
  "deviceTs": null,
  "message": null
}

WebSocket /api/v1/stream Basis umgesetzt

Subprotokoll pdc-edge.v1. Maschinen authentisieren sich mit dem Authorization-Header beim Upgrade, Browser mit dem Feld token im hello. Anfragen tragen eine vom Client gewählte reqId.

{ "type": "hello", "reqId": "h1", "client": "node-red/gw-hall1",
  "version": "2027.1.0", "apiVersions": ["1"] }

{
  "type": "subscribe",
  "reqId": "s1",
  "subId": "in-node-4711",
  "select": ["acme/werk1/presswerk/linie3/#", "id:press1-*"],
  "options": {
    "snapshot": true,
    "minIntervalMs": 250,
    "maxBatch": 500,
    "includeMeta": false,
    "overflow": "dropOldest"
  }
}

{
  "type": "value",
  "subId": "in-node-4711",
  "initial": false,
  "items": [
    { "signal": "press1-temp-oil", "v": 72.4, "q": "good",
      "edgeTs": "2026-11-13T09:15:02.481Z" }
  ]
}

{
  "type": "write",
  "reqId": "w1",
  "signal": "press1-orderno",
  "value": "A-2026-004711",
  "correlationId": "01JCA0V8Q3H4X9M2N5P7R1T6YB",
  "verify": "readBack",
  "timeoutMs": 5000
}

Die Antwort auf write heisst write_result – auch bei Ablehnung. error ist für Protokollfehler reserviert. Weitere Typen: read/readResult, unsubscribe, event, ping/pong.

Unified Namespace über MQTT geplant (M1)

Topics folgen ISA-95. <node> ist die Kette der Namespace-Knoten, <signal> der UNS-Name des Signals. Systemsegmente beginnen mit _.

{
  "value": 184223,
  "quality": "good",
  "ts": "2026-11-13T09:41:12.381Z",
  "sourceTs": "2026-11-13T09:41:12.377Z",
  "seq": 991
}

Schreiben über UNS geplant (M1/M1b)

Ein Client publiziert auf …/_write und bekommt das Ergebnis auf sein Antwort-Topic. Ein Ablauf ist Pflicht, retained Anfragen werden verworfen. Writes über externe Broker sind standardmässig aus; das Signal muss den Kanal uns freigeben, und ein Auth-Modus (token oder brokerAcl) ist Pflicht.

Topic:   acme/werk1/presswerk/linie3/presse1/order-no/_write
MQTT 5:  Response Topic = clients/mes-01/replies, Correlation Data = 01JCA0V8Q3H4X9M2N5P7R1T6YB,
         Message Expiry = 10, User Property authorization = Bearer <Edge-JWT>
Payload: {"value":"A-2026-004711","correlationId":"01JCA0V8Q3H4X9M2N5P7R1T6YB","timeoutMs":3000}

Topic:   clients/mes-01/replies
Payload: {"correlationId":"01JCA0V8Q3H4X9M2N5P7R1T6YB","signal":"press1-orderno",
          "status":"succeeded","reason":null,"durationMs":38}

Bei MQTT 3.1.1 stehen replyTo, correlationId und notAfter in der Payload. Kafka nutzt <topic>.write und <topic>.write-results (geplant M3).

Verarbeitung mit JavaScript umgesetzt

Ausdrücke und Scripts laufen in einer QuickJS-Sandbox ohne Dateisystem-, Netzwerk- und Prozesszugriff, mit Zeit- und Speicherlimit. Ein Ausdruck (expr) ist ein einzelner JS-Ausdruck, ein Script (source) ein Funktionsrumpf mit return. Testen ohne Aktivierung: POST /api/v1/scripts/test (Dry-Run, auch als Dialog im UI).

signals:
  - id: sim-script
    group: sim-process
    address: "counter:step=1"
    dataType: uint32
    access: read
    history: { depth: 2 }
    uns: { name: script-demo }
    processing:
      - type: expression
        expr: "value * 10"
      - type: script
        outputType: json
        timeout: 20ms
        source: |
          state.calls = (state.calls ?? 0) + 1;
          log.debug("value", value, "prev", prev(1));
          return { v: value, prev: prev(1), calls: state.calls, even: value % 20 === 0 };

triggers:
  - id: sim-started
    on: { signal: sim-running, edge: rising }
    payload: { strokes: 'signal("sim-strokes")' }
    publish: true