Upgrade-Notizen

Hier werden die Punkte aufgeführt, die bei einem Versionssprung in Bezug auf die Integrationen angepasst werden müssen, sowie die Vorgänge, die beim Erststart ablaufen. Die Upgrade-Verfahren (Neuausführung des Installations-One-Liners) finden Sie unter Upgrade. Die neuesten Versionen stehen oben.

2026.11 — Vorbereitungen und Namensänderungen

Unterstützungsbereich

Unterstützt werden die letzten drei Versionen ab 2026.11. Ein Upgrade von Versionen vor 2026.10 ist nicht möglich; führen Sie in diesem Fall eine Neuinstallation durch (ein Upgrade-Versuch würde fehlschlagen und automatisch ein Rollback auf die ursprüngliche Version ausführen). Siehe Upgrade. Die unten aufgeführten Namensänderungen und Integrationsanpassungen gelten auch bei einer Neuinstallation.

Bereiten Sie sich in der folgenden Reihenfolge vor. Upgrades von Cassandra können nicht rückgängig gemacht werden, und es gibt keine Abwärtskompatibilität für Namensänderungen — alte Pfade, Spalten und Tool-Namen verschwinden im Moment des Upgrades. Daher müssen Integrationen gleichzeitig mit dem Server aktualisiert werden. Aktualisieren Sie auch die Frontline-Apps auf die gleiche Version. Informationen zur Änderung von Workorder-Mengen und Namen finden Sie im Abschnitt «2026.11 — Workorder-Mengen und Namen nach ISA-95 / B2MML».

1. Backup — Cassandra r4 ist irreversibel

Die in dieser Version verwendete Cassandra-Instanz ist Aster TSDB v6.0.0-r4.

Knoten, die einmal auf r4 aktualisiert wurden, können nicht auf r3 oder niedriger zurückgesetzt werden

Das Format der Cluster-Metadaten-Snapshots hat sich geändert, sodass ältere Instanzen diese nicht lesen können. Um einen Rückweg zu gewährleisten, müssen Backups vor dem Upgrade erstellt werden.

Vollständiges Backup von PostgreSQL — ./backup.sh --postgres full
Vollständiges Backup von Aster TSDB — ./backup.sh --cassandra full(Backup und Wiederherstellung)
Kopieren Sie system_cluster_metadata aus dem Cassandra-Datenverzeichnis auf jedem Knoten
Installieren Sie anschließend die neue Version

2. Migration V121~ — Der Erststart kann lange dauern

Beim Erststart wendet Flyway die Migrationen V121 bis V152 in einem Durchgang an. Dies umfasst grundlegende Strukturänderungen wie die Bereinigung der Alarm-Tabellen (V121~~V124), den fünfstufigen Anlagen-Baum (V137~~V139), Schlüssel für Protokolltabellen und Instandhaltungsnamen (V140) sowie Fremdschlüssel (V127~V133). Da V123 mm_alarm für alle Zeilen anpasst, erhöht sich die Dauer proportional zur Anzahl der Alarm-Zeilen. Währenddessen reagiert der Server nicht, und ein Healthcheck könnte zunächst unhealthy auslösen — starten Sie den Container nicht neu, sondern warten Sie auf Flyway migration completed. im Log.

Falls Daten nicht den Anforderungen entsprechen, stoppt die Migration und der Server startet nicht. Änderungen der gestoppten Stufe werden rückgängig gemacht, vorherige Stufen bleiben erhalten. Korrigieren Sie die Daten gemäß dem im Log nach Platform version update failed folgenden Satz und starten Sie den Server erneut; die Migration setzt an dieser Stelle fort. Vor dem Upgrade können Sie die betroffenen Daten in der DB mit folgendem Befehl prüfen:

-- V121: 0 행이어야 합니다 — 숨겨진 채 켜져 있는 알람
SELECT alarm_seq FROM pp.mm_alarm WHERE shelved AND is_on;

-- V121: 0 이어야 합니다 — 숨겨진 알람에 확인 · 라벨이 붙은 행
SELECT count(*) FROM pp.mm_alarm
 WHERE shelved AND (is_read IS TRUE OR read_user_id IS NOT NULL OR disposition IS NOT NULL
       OR cause_note IS NOT NULL OR labeled_by IS NOT NULL OR labeled_at IS NOT NULL
       OR failure_record_id IS NOT NULL);

-- V128: 0 이어야 합니다 — 고장 기록을 가리키지 못하는 알람 연결
SELECT count(*) FROM pp.mm_alarm a
 WHERE a.failure_record_id IS NOT NULL
   AND (a.failure_record_id !~ '^[0-9]{1,18}$'
        OR NOT EXISTS (SELECT 1 FROM pp.mm_ram_failure f WHERE f.failure_id = a.failure_record_id::bigint));

-- V137: 1 행이어야 합니다 — 설치당 기업은 하나
SELECT enterprise_id FROM pp.mm_enterprise;

3. Namensänderungen — Keine Abwärtskompatibilität

Alte Namen werden weder akzeptiert noch zurückgegeben. Alte V5-Pfade führen zu einem 404-Fehler.

Instandhaltungs-«Protokoll» heißt nun Instandhaltungs-«Auftrag».

Ort	Alt	Neu
V5-Pfad	`/api/v5/maintenance-records…`	`/api/v5/maintenance-orders…`
V5-Pfad	`/api/v5/asset/{asset_id}/maintenance-records`	`/api/v5/asset/{asset_id}/maintenance-orders`
MCP-Tool	`list_maintenance_records`	`list_maintenance_orders`
Spalte · Abfrage	`record_id`	`maintenance_order_id` — Zahl → Zeichenfolge
Spalte · Abfrage	`kind` · `status` · `cancel_reason`	`maintenance_kind_code` · `status_code` · `cancel_reason_code`
Spalte	`failure_id`	`failure_record_seq`
Spalte	`plan_id` · `plan_name`	`maintenance_plan_id`(Zahl → Zeichenfolge) · `maintenance_plan_name`
Spalte · Abfrage	`failure_mode` · `failure_mechanism` · `failure_cause` · `maintainable_item`	Danach `_code`. Anzeigenamen `*_name` und `cause_code` bleiben gleich
Spalte	`checklist_results[].attachment_id`	`checklist_results[].maintenance_attachment_seq`
Anhang-Antwort	`attachment_id` · `record_id`	`maintenance_attachment_seq` · `maintenance_order_id`
Listenwert `sort`	`status` · `kind`	`status_code` · `maintenance_kind_code`
Instandhaltungsplan-Kalender	`record_id` · `record_status` · `open_record_id` · `open_status` · `record_ids`	`maintenance_order_id` · `maintenance_order_status_code` · `open_maintenance_order_id` · `open_status_code` · `maintenance_order_ids`
DB-Tabelle	`mm_maintenance_record` · `mm_ram_failure`	`mm_maintenance_order` · `mm_failure_record`

Lesen oder vergleichen Sie maintenance_order_id · maintenance_plan_id nicht als Zahlen. Alte Zeilen sind Zeichenfolgen("12"), die die Nummer beibehalten; neue Zeilen folgen dem Format MAINTENANCE_ORDER_000013.

Schlüssel für CMMS-Webhooks (PP_MAINTENANCE_WEBHOOK_URL) — Passen Sie zuerst die empfangende Seite an.

Alter Schlüssel	Neuer Schlüssel	Wert
`record_id`	`maintenance_order_id`	Zeichenfolge
`kind`	`maintenance_kind_code`	Identisch
`status`	`status_code`	Identisch
`failure_mode`	`failure_mode_code`	Identisch
`cancel_reason`	`cancel_reason_code`	Identisch
`plan_id`	`maintenance_plan_id`	Zeichenfolge
`checklist_results[].attachment_id`	`checklist_results[].maintenance_attachment_seq`	Identisch

text · event · asset_id · asset_name · description · requested_by · accepted_by · assignee_employee_id · external_system · external_id · owner · anomaly_found · plan_due_at · at · version bleiben unverändert — CMMS-Webhooks.

Übrige Protokollschlüssel und ID-Spalten.

Ort	Alt	Neu
`/ram/failures…`	`failure_id` · `asset_class` · `equipment_class` · `code_status`	`failure_record_seq` · `asset_class_code` · `equipment_class_code` · `raw_code_status_code`
`/ram/failures…`	`failure_mode` · `mechanism` · `iso_cause` · `maintainable_item`	`failure_mode_code` · `failure_mechanism_code` · `failure_cause_code` · `maintainable_item_code`
Störungs- · Instandhaltungs-Code-Mapping	`map_id`(Zahl)	`fault_code_map_id` · `maintenance_code_map_id`(Zeichenfolge)
`/defects…`	`defect_id`	`defect_record_seq`
`/order/{id}/notes` · `/progress`	`note_id` · `progress_id`	`order_note_seq` · `order_progress_seq`
`/alarm/config/{id}/revisions`	`revision_id`	`alarm_config_revision_seq`
Schichtplan-Intervall	`generation_id`	`asset_plan_generation_seq`
Alarm `label`	`failure_id`	`failure_record_seq`

Anlagen · Standorte.

Alt	Neu	Bemerkung
`table_type`	`asset_class_code`	UI-Bezeichnung «Anlagenklassifizierung». Spalte `mm_asset_class` im Code ist `code`
Standort `status`	`operational_status_code`	`ACTIVE` → `IN_OPERATION`, `INACTIVE` → `OUT_OF_SERVICE`, `CLOSED` → `DECOMMISSIONED`. Gemeinsame Spalte für alle Ebenen
Baum nur mit Bereich · Linie · Anlage	Unternehmen → Standort → Bereich → Linie → Anlage	In `asset_type` erscheinen neu `E` · `S`. Diese beim Zählen der Anlagenanzahl ausschließen

ID-Format. Neu erstellte IDs bestehen aus dem vollständigen Domainnamen + einer sechsstelligen Nummer. Bestehende IDs bleiben gültig und unverändert. Leiten Sie die Ebene oder Art nicht aus dem ID-Präfix ab, sondern lesen Sie asset_type.

Domain	Altes Format (bleibt gültig)	Neues Format
Bereich · Linie · Anlage	`ASSET_…`	`AREA_000001` · `LINE_000001` · `EQUIPMENT_000001`
Workorder	`ORD_…`	`ORDER_000001`
Kalender · Schichtausnahme	`CAL_…` · `OV_…`	`CALENDAR_000001` · `SHIFT_OVERRIDE_000001`
Anlagenbeziehung · Prozesssegment	`REL_…` · `SEG_…`	`ASSET_RELATION_000001` · `PROCESS_SEGMENT_000001`
Befehlsbereich · Anlagenbefehl	`CMDAREA_…` · `CMD_…`	`COMMAND_AREA_000001` · `ASSET_COMMAND_000001`
Bild	`IMG_…`	`IMAGE_000001`
Mitarbeiter	`EMP_…`	`EMPLOYEE_…`
Alarm-Einstellung	`ALARM_CONFIG_00375` · `ALARM_CONFIG_<태그 ID>`	`ALARM_CONFIG_000376`

Nummern können Lücken aufweisen; bei Überschreitung von 999999 erhöht sich die Stellenzahl. Details unter Domain-ID-Regeln.

Alarm-Einstellungen.

Die Eingabe einer selbst definierten ID in POST /alarm/config führt zu 422 alarm.invalid.alarm_config_id. Neue IDs werden über GET /alarm/config/new-id empfangen. IDs im alten Format können nur bearbeitet werden.
Bandalarm-Einstellungen sind pro Tag limitiert auf eins. Eine zweite Einstellung führt zu 409. EQL-Alarm-Einstellungen haben keine Mengenbeschränkung.
Suchen Sie Bandalarm-ID nicht über ALARM_CONFIG_<태그 ID>. Neue Einstellungen existieren nicht unter diesem Namen. Suchen Sie in GET /alarm/config/list/by-tag?tag_id=… nach dem Eintrag, bei dem alarm_config_priority gleich BAND ist.

Erforderliche Felder für Statements

Beim Speichern werden die erforderlichen Ausgabefelder je nach Typ geprüft. Fehlende Felder führen zur Ablehnung mit 422 asset_statement.eql.missing_columns und einer Meldung der fehlenden Felder.

Typ	Erforderliche Felder
`EVENT`	`timestamp` · `plugin` · `name` · `color` · `from_timestamp` · `to_timestamp` · `value`
`CONTEXT` · `AGGREGATION` · `COMMAND`	`timestamp` · `plugin` · `key` · `value`

Bereits gespeicherte Statements werden durch das Upgrade weder gelöscht noch gestoppt, sondern beim Start identisch bereitgestellt. Statements ohne erforderliche Felder konnten jedoch bereits zuvor keine Ergebnisse aufzeichnen — dies führt weiterhin zu Fehlern pro Ereignis und aktiviert die Diagnose diagnostic.asset.statement_failing. Solche Statements müssen beim Bearbeiten und Speichern die Prüfung bestehen, sodass die Felder gefüllt werden müssen. Suchen Sie diesen Code nach dem Upgrade im Diagnosebildschirm und beheben Sie ihn.

4. Diagnose — CEP Dead-Letter-Aufbewahrung: 24 Stunden / 256 MiB

Für Dead-Letter-Queues (PP:CEP-DEAD-LETTER), in denen Ereignisse gespeichert werden, die CEP nicht verarbeiten konnte, wurde ein Limit für Alter und Größe festgelegt. Wenn 24 Stunden verstrichen sind oder die Summe 256 MiB überschreitet, werden die ältesten Einträge gelöscht. Es werden nur Ereignisse aufgenommen, die nach drei Zustellungsversuchen nicht verarbeitet wurden. Zur Untersuchung fehlgeschlagener Ereignisse müssen diese innerhalb des Zeitfensters geprüft werden — Datenaufbewahrung.

5. CEP — Esper-Backend und CPU-Metriken pro Statement entfernt

Der Wert von cep.backend beträgt aster · flink; ist er nicht konfiguriert, gilt aster. Da die Standard-Bereitstellungsvorlage cep.backend=aster verwendet, sind bei Installationen ohne manuelle Änderungen keine Maßnahmen erforderlich.

CEP startet nicht, wenn Wert auf cep.backend=esper gesetzt ist

Der Bootvorgang stoppt bei falschem Wert. Ändern Sie die entsprechende Zeile in plantpulse-cep.properties vor dem Upgrade zu aster oder löschen Sie diese.

Installationen, die Esper nutzten, sollten vor dem Upgrade mittels GET /api/v1/eql/portability prüfen, welche Statements nicht von Aster CEP verarbeitet werden können. Nicht verarbeitete Statements werden nicht gelöscht, sondern bleiben als REJECTED bestehen — Limits und Reject-Token.
GET /api/v1/eql/{name}/metrics wurde entfernt. CPU- und Wallclock-Zeit pro Statement sind nicht mehr über Gauge, REST, Console-Panel oder Storage verfügbar. Für Statement-Metriken werden die Match- und Output-Raten von GET /api/v1/eql/metrics/snapshot verwendet. Das Panel EQL_CPU_TIME im PlantPulse Dashboard erhält keine Werte mehr.
Die folgenden Einstellungen werden nicht mehr ausgelesen: cep.ha.* · cep.monitor.statement_metrics_enabled · cep.monitor.cpu_estimate_max_error · cep.performance.cpu_warn_threshold_ns · cep.performance.wall_warn_threshold_ns · cep.storage.max_inflight_writes. Die Erhaltung des Regelstatus erfolgt über cep.aster.state.* — Property-Referenz.

6. Nach dem Upgrade

Tragen Sie in die Einstellungsseite PP_UI_CONSOLE_URL ein. Wenn dieses Feld leer ist, fehlen Links in Alarm-E-Mails und QR-Label können nicht erstellt werden. Bei Nutzung von Frontline-Apps tragen Sie auch PP_UI_FRONTLINE_URL ein.
Die öffentliche QR-Seite ist für alle Standorte standardmäßig deaktiviert.
Es wurden Fehler behoben, bei denen der Wert von MAIL_SMTP_* in der Einstellungsseite nicht auf den Versand angewendet wurde und STARTTLS mit «No appropriate protocol» fehlschlug. E-Mails könnten nun tatsächlich versendet werden; prüfen Sie daher Ihre Einstellungen — E-Mail-Einstellungen.

Plugins, die auf einem 2026.11-Stand vor dem 2026-11-05 angewendet wurden — RAM_FAILURE_CODE_TAG und OEE_PRODUCT_BAD_COUNT_CODED behalten ihre alten Anweisungen und überwachen nicht vorhandene Tags (<Tag>_CODE, <Tag>_CAUSE). Erneutes Anwenden allein ändert nichts, weil der Dialog «bereits vorhanden (übersprungen)» zeigt. Löschen Sie diese Anweisungen (DELETE /api/v5/asset/{asset_id}/statement/{statement_name}), wenden Sie das Plugin erneut an und wählen Sie dabei den Code-Tag und den Tag für die Ausschussursache. Andere Anweisungen bleiben unverändert. Ausfälle vor dem erneuten Anwenden bleiben ohne Code. Installationen, in denen der Code-Tag tatsächlich als <Ausfall-Tag-ID>_CODE existiert und alles lief, müssen nichts tun.

2026.11 — Workorder-Mengen und Namen nach ISA-95 / B2MML

Die Workorder-Menge wurde von einer «einzelnen Zahl» auf ein Wert + Einheit Objekt (ISA-95 / B2MML QuantityValueType) umgestellt. Die Spaltennamen wurden auf ISO 22400-Terminologie angepasst, und Ausschuss wurde in Ausschuss und Nacharbeit unterteilt. In der gleichen Version wurden die Spaltennamen für Workorders, Kalender, Kunden und Produkte auf ISA-95 / B2MML-Namen geändert(title → order_name, fix_start_timestamp → planned_start_timestamp …, siehe Namensänderungen). Es gibt keine Kompatibilitätsspalten, Kompatibilitätspfade oder Aliasnamen — Integrationen, die alte Namen lesen oder senden, müssen zeitgleich mit dem Upgrade angepasst werden.

Referenz: V5 API 5.0 · Mengenkontrakt 2026-10-30 · Namens-Wave 2026-10-31 · server-web 974891b4 (Mengen-Wave ab 30b7d9af) · Flyway V99·V100·V103 · core Migration V12~~V16·V21~~V23 · Ereignisschema plantpulse.order.*·plantpulse.calendar.* major 2, plantpulse.kpi.oee.finalized major 1.

Was sich ändert

Bereich	Änderung	Details
V5 Mengen-Spalten	`target_units`+`unit` → `planned_quantity`, `total_good_count` → `good_quantity`, `total_bad_count` → `scrap_quantity`, `total_production_count` → `produced_quantity` usw. Werte sind `{quantity_string, data_type, unit_of_measure}` Objekte	Order-Service — Menge
Ausschuss · Nacharbeit	`scrap_quantity` gilt nur für Ausschuss(ISO 22400 SQ), Nacharbeit erfolgt in neuer Spalte `rework_quantity`(RQ). Das alte `total_bad_count` war die Summe beider Werte — für die Summe müssen beide addiert werden. In der UI wird die Stelle nur für Ausschuss als «Ausschuss» und die Summe als «Ausschuss» bezeichnet	Order-Service — Ausschuss und Nacharbeit
Einheiten	13 zugelassene Einheiten nach UN/ECE Rec 20(`EA`·`H87`·`C62`·`BX`·`SET`·`KGM`·`GRM`·`TNE`·`LTR`·`MLT`·`MTQ`·`MTR`·`MTK`). Ist-Meldungen werden nur in der Workorder-Einheit empfangen (keine Umrechnung). Ablehnungen erfolgen über 422 `E1002` + `reason`(`quantity.unit_mismatch`·`quantity.not_integer` …)	Order-Service — Anforderungsregeln und Ablehnung
Standardeinheit Produkt	Das Feld `unit_of_measure` des Produkts wird zur Standardeinheit neuer Workorders. Alte Werte werden in Codes übertragen(`BOX`→`BX`, `KG`→`KGM`, `PCS`·`개`→`EA` …), unbekannte Werte als «Keine Einheit» (neue Workorder für dieses Produkt erhält `EA`)	Produktionsmanagement — Mengen und Einheiten
Priorität	`priority` wird zur B2MML-Priorität als Ganzzahl (1 Dringend, 2 Hoch, 3 Normal, 4 Niedrig, kleinere Zahl ist höher). Alte Werte `URGENT`·`HIGH`·`NORMAL`·`LOW` werden auf 1~4 abgebildet
Zeitraum-KPI	Bei einer Einheit: Zahl + `unit_of_measure`, bei gemischten Einheiten: keine Summierung, sondern `quantities_by_unit`	Gleicher Ort
EMS-Wert pro Einheit	Neben `energy_per_unit_kwh`·`co2_per_unit_kg` wird die Nenner-Einheit `unit_of_measure` ergänzt	Gleicher Ort
Namen (Workorder·Kalender·Kunde·Produkt)	`title` → `order_name`, `fix_start_timestamp`/`fix_end_timestamp` → Workorder: `planned_start_timestamp`/`planned_end_timestamp`, Kalender: `start_timestamp`/`end_timestamp`, `external_order_id` → `external_id`, `external_po_id` → `customer_po_id`, Kunden/Produkte: `external_customer_id`/`external_product_id` → `external_id`(+ `external_system`). Gilt für V5·SDK·Ereignisse·MCP·Flow-Knoten·DB-Spalten. Keine Aliasnamen	Namensänderungen
Externe Workorder-Identifikation	Paar `(external_system, external_id)`. V5 `POST`·`PUT`·`PATCH /order` empfangen beide und führen beide in Antwort- und Ist-Dokumenten. `GET /order/performance/by-external/{external_order_id}` wird gelöscht und durch `…/by-external/{external_system}/{external_id}` ersetzt. Eine Workorder besitzt `GET /order/by-external/{system}/{external_id}`	MES-Integration
Ereignisse	`planned_quantity_unit_of_measure`·`external_system` in `plantpulse.order.`, `_quantity` + `unit_of_measure`(Original) und Nacharbeit `rq`·`rq_quantity` in `plantpulse.kpi.oee.finalized`. Ergänzung am Ende ohne Typänderung. Durch Namensänderung sind `plantpulse.order.`·`plantpulse.calendar.` nun Schema major 2(`dataschema` endet auf `:2`)	Order-Service — Menge
Flow	Mengen in `OEE_EVENT` werden zu Quantity-Objekten (Zusatz `rework_quantity`). In `flow_create_work_order` ist der Einheitenwert erforderlich(Pfad `unit_of_measure_field`, Standard `data.unit_of_measure`). Namensänderung der Pfad-Konfigurationsnamen dieses Knotens(`title_field` → `order_name_field` …)	Flow
UI	Zu jeder Menge wird das Einheitenzeichen angehängt (sprachunabhängig — `EA`, `kg`, `L`, `m²` …). Im Workorder-Formular gibt es ein Feld für Einheiten	Produktionsmanagement — Mengen und Einheiten

Zahlenwerte ändern sich nicht. Alle Workorders vor dem Upgrade werden in EA übertragen; da die Ganzzahlwerte identisch bleiben, sind OEE, Verfügbarkeit, Leistung, Qualität und Mengensummen vor und nach dem Upgrade gleich. Die Nacharbeit wird aus der Summe alter REWORK-Ausschussaufzeichnungen gefüllt (ansonsten 0), wodurch scrap_quantity im Vergleich zum alten total_bad_count entsprechend sinkt.

Namensänderungen — Alte und neue Namen

Die Spaltennamen für Workorder und Kalender wurden auf einen einzigen ISA-95 / B2MML-Namen vereinheitlicht. Wire, SDK, Ereignisse und DB-Spalten verwenden denselben neuen Namen. Es gibt keine Aliasnamen, Kompatibilitätsviews oder Dual-Write-Mechanismen(server-web 974891b4, Flyway V103 order_calendar_names_isa95).

Alter Name	Neuer Name	Betroffene Stellen
`title`	`order_name`	Workorder — V5 Anfrage·Antwort·`/order/query`-Zeile, SDK `setOrder_name`, Ereignisse `plantpulse.order.*`(alle Arten, inkl. `deleted`), MCP `list_work_orders`·`get_work_order_kpi`, DB `mm_order`·`mm_order_revision`, Cassandra `tm_asset_order`
`fix_start_timestamp` / `fix_end_timestamp`	`planned_start_timestamp` / `planned_end_timestamp`	Workorder — s.o. In MCP: `fix_start_at`/`fix_end_at` wird zu `planned_start_at`/`planned_end_at`
`fix_start_timestamp` / `fix_end_timestamp`	`start_timestamp` / `end_timestamp`	Kalender — V5 Anfrage·Antwort·Revisionshistorie, SDK `setStart_timestamp`/`setEnd_timestamp`, Ereignisse `plantpulse.calendar.created`·`updated`·`entry.*`, DB `mm_calendar`·`mm_calendar_revision`·`mm_shift`
`target_units`	`planned_quantity`	DB-Spalten `mm_order`·`mm_order_revision`·`mm_order_oee`. V5·SDK·Ereignisse waren bereits `planned_quantity`
`external_order_id`	`external_id`	Workorder — V5 Anfrage·Antwort·Ist-Dokument·`/order/query`-Filter, SDK `setExternal_id`·`OrderQuery.externalId(..)`, Ereignisse, MCP `get_work_order_kpi`, DB
`external_po_id`	`customer_po_id`	Workorder — V5 Anfrage·Antwort·Ist-Dokument, SDK `setCustomer_po_id`, Übergangsereignisse(`started`~`aborted`), MCP, DB
`external_customer_id` / `external_product_id`	`external_id` + neue Spalte `external_system`	Kunden·Produkte — V5 Anfrage·Antwort, SDK, DB. Paarsuche `GET /customer/by-external/{system}/{external_id}`·`/product/by-external/…` ist neu hinzugekommen
`baseline_fix_start` / `baseline_fix_end`	`baseline_planned_start_timestamp` / `baseline_planned_end_timestamp`	Workorder `deviation`-Objekt(V5·SDK·MCP)
Sortierung `fix_start_desc` / `fix_start_asc`	`planned_start_desc` / `planned_start_asc`	`/order/query` in `sort`
Flow `title_field` · `target_units_field` · `external_order_id_field` · `external_po_id_field`	`order_name_field` · `planned_quantity_field` · `external_id_field` · `customer_po_id_field`	`flow_create_work_order`-Knotenkonfiguration. Standardpfade ebenfalls zu `data.order_name` · `data.planned_quantity` · `data.planned_start_timestamp` · `data.planned_end_timestamp` · `data.external_id` · `data.customer_po_id`

Alte Namen werden nicht akzeptiert — da manche Stellen diese stillschweigend ignorieren, passen Sie die Integrationen zuerst an.

Wenn in POST·PUT /order ein alter Name gesendet wird, wird dieses Feld nicht gelesen. order_name bleibt leer, was zu einem Validierungsfehler führt(order_name ist erforderlich, darf nicht leer sein — order.name.required), und die Planzeit wird ebenfalls leer. Wenn neue und alte Namen gemischt gesendet werden, wird zwar gespeichert, aber da PUT das gesamte Anfragefeld ersetzt, werden in alten Namen gesendete external_order_id·external_po_id gelöscht.
Das Senden eines alten Namens an PATCH /order führt zu 422 «not patchable».
/order/query?external_order_id=… wird nicht ignoriert, sondern mit 422 abgelehnt — verwenden Sie external_id und external_system.
Ereignisse werden nur noch als Major 2 versendet. Schema-Dateien für Major 1 bleiben nur zum Replay erhalten; neue Ereignisse verwenden die neuen Namen.
Die Feldnamen in /kpi/*-Antworten und plantpulse.kpi.oee.finalized sind nicht Teil dieser Änderung(bleiben gleich).

Vor dem Upgrade — Prüfung auf Duplikate externer Identifikationspaare

Die neue Version setzt einen Index, der sicherstellt, dass Workorders, bei denen beide Felder des externen Identifikationspaars nicht leer sind, eindeutig sind (Flyway V100, ux_mm_order_external_pair). Falls zwei oder mehr Workorders bereits das gleiche Paar besitzen, schlägt dieser Schritt fehl. Prüfen Sie dies vor dem Upgrade. Das folgende SQL wird in der DB vor dem Upgrade ausgeführt und verwendet daher den alten Spaltennamen external_order_id (V103 ändert diesen später in external_id).

SELECT external_system, external_order_id, count(*)
  FROM pp.mm_order
 WHERE external_system <> '' AND external_order_id <> ''
 GROUP BY 1, 2
HAVING count(*) > 1;

Das Ergebnis muss 0 Zeilen sein. Falls Zeilen erscheinen, korrigieren Sie external_system oder external_order_id auf einer Seite, bevor Sie fortfahren. Workorders, bei denen nur external_order_id existiert und external_system leer ist, gelten nicht als Paar und sind nicht betroffen(bleiben unverändert).

Vorgänge beim Erststart

Speicher	Zeitpunkt	Aktion
PostgreSQL	server-web Start(Flyway V99 `order_quantity_isa95` · V100 `order_external_id_pair_unique`)	Mengenspalten in `numeric(18,4)` ändern und für jede Workorder `unit_of_measure` mit `'EA'` füllen. `mm_order_oee.total_rework_count` addieren und als Summe alter `REWORK`-Ausschussaufzeichnungen füllen. Produktseinheiten in Codes übertragen und `priority` in Ganzzahl ändern
PostgreSQL	Anschließend Flyway V103 `order_calendar_names_isa95`	DB-Spalten aus der oben stehenden Namensänderungs-Tabelle in `RENAME COLUMN` ändern — Daten, Indizes, Constraints und Views bleiben erhalten. Kunden/Produkte erhalten eine `external_system`-Spalte und einen Unique-Index für Paare (Systemfelder bestehender Zeilen bleiben leer). Wenn Workorder `status` außerhalb von `WAIT`·`START`·`PAUSED`·`END`·`ABORTED` liegt, stoppt der Vorgang. Trigger sorgen dafür, dass Statusänderungen nur gemeinsam mit Revisionszeilen erfolgen
Cassandra · EQL-Speicher	Plattform-Erststart(core V21~V23)	`order_name`·`planned_start_timestamp`·`planned_end_timestamp` zu `tm_asset_order` hinzufügen und alte Spaltenwerte übertragen (V21·V22, Dauer wenige Sekunden, alte Spalten werden nicht gelöscht). Alte Attributnamen gespeicherter Anlagen-Statements(EQL) werden durch neue Namen ersetzt (V23, SYSTEM-Revision) — nicht konvertierte Statements bleiben als Diagnose `diagnostic.asset.statement_not_renamed` bestehen
Cassandra	Plattform-Erststart	Versionsmigration fügt in kleinen Tabellen(OEE·EMS current·order, `tm_asset_order`) neue `decimal`-Mengenspalten und `unit_of_measure` hinzu und füllt bestehende Zeilen(`'EA'`) — Dauer wenige Sekunden. Große Tabellen(OEE·EMS rolling·rollup·history, `tm_kpi_oee_count`) werden nach dem Start im Hintergrund migriert. Der Startvorgang selbst ist wie gewohnt

Während der Migration großer Tabellen werden Historie-KPIs aus den alten Spalten mit denselben Werten gelesen. Sobald die Migration einer Tabelle abgeschlossen ist, werden automatisch nur noch die neuen Spalten gelesen. Der Fortschritt wird im server-web-Startlog in Zeilen, die mit «Cassandra migration» beginnen, angezeigt(docker logs plantpulse-server-web | grep 'Cassandra migration').
Alte Ganzzahlspalten(target_units·total_production_count·total_good_count·total_bad_count) werden nach Abschluss der Migration weder gelesen noch geschrieben. Das Löschen dieser Spalten erfolgt erst in einer späteren Version. In neu installierten Clustern existieren diese Spalten nicht.

2026.11 — Vorbereitungen und Namensänderungen​

1. Backup — Cassandra r4 ist irreversibel​

2. Migration V121~ — Der Erststart kann lange dauern​

3. Namensänderungen — Keine Abwärtskompatibilität​

Erforderliche Felder für Statements​

4. Diagnose — CEP Dead-Letter-Aufbewahrung: 24 Stunden / 256 MiB​

5. CEP — Esper-Backend und CPU-Metriken pro Statement entfernt​

6. Nach dem Upgrade​

2026.11 — Workorder-Mengen und Namen nach ISA-95 / B2MML​

Was sich ändert​

Namensänderungen — Alte und neue Namen​

Vor dem Upgrade — Prüfung auf Duplikate externer Identifikationspaare​

Vorgänge beim Erststart​

Integrations-Checkliste​