Stand: 2026-03-05
Übergeordnet: CAFM-Architektur — Gesamtübersicht Verwandt: 2.2 Asset-Modell | 2.4 Migration
Vier Quellsysteme fließen in die neue Architektur:
| System | Fokus | Stärken | Schwächen | Ziel |
|---|---|---|---|---|
| AMED | Mechanik | Vollständige Apparatehierarchie | Kein Elektriker-Modell; kein TP | ENIVERSCAFM |
| TecDB | Rohre / EAV | Flexible Objekteigenschaften | Dynamisches SQL, kein Plan-Cache | ENIVERSPIMS |
| WIS/PROOF | Prüfpläne | Bewährte TimeTrain-Engine | 63 Synonyme; externe PROOF/HIST-DB | ENIVERSPIMS |
| LD/ENIVERS | Elektrik | EMR-Stellen, Kv-Nummern, BESTAND | Kein Mechanik-Modell | ENIVERSCAFM |
AMED ist auf Apparate (Maschinen, Behälter, Aggregate) ausgerichtet.
APPMASTER.erwAppNr ist der universelle Primärschlüssel für alle mechanischen Objekte.
| Tabelle | Zweck | Verknüpfung | Anzahl (ca.) |
|---|---|---|---|
APPMASTER | Basisobjekt: Mechanische Apparate | erwAppNr = PK | ~11.650 |
MOTORMASTER | Motoren (Untertyp von APPMASTER) | FK → APPMASTER | ~8.460 |
EZAMASTER | Elektrische Zonierung / SIL-Einstufung | FK → APPMASTER | variabel |
AVI_Equip | TÜV-/§29-überwachungspflichtige Anlagen | FK → APPMASTER | variabel |
tblLocationKV | Elektrische Zonen (KV-Nummern, Motoren) | polymorphisch via IDObType | variabel |
tblLocationKV und EZAMASTER ansatzweise abgedeckt.| ID | Kürzel | Beschreibung |
|---|---|---|
| 1 | PIV | Periodische Prüfung intern |
| 2 | BZ | Betriebszustandsprüfung |
| 3 | GP | Gesetzliche Prüfung |
| 4 | EIE | Elektrische Inspektion |
| 5 | BGV/A3 | Elektrische Prüfung BGV A3 |
| 6 | KV | KV-Motoren-Prüfung |
| 7 | EX | Explosionsgefährdete Bereiche |
| 8 | BS | Brandschutz |
| 9 | SS | Sicherheitsstufe |
| 10 | FI | FI-Schutzschalter |
| 11 | BL | Blitzschutz |
| 12 | AK | Ankerprüfung |
| 13 | DK | Druckprüfung |
| 14 | PV | Prüfvorschrift intern |
| 15 | SU | Sachkundigenprüfung |
| 16 | SH | Sicherheit halbjährlich |
| 17 | RM | Regelmäßige Messung |
TecDB verwendet ein bidirektionales EAV-Modell (Entity-Attribute-Value):
tblRohrMaster = flache Tabelle mit ~150 Spalten (eine pro Rohreigenschaft)tblObjektEigenschaft = EAV-Tabelle (Objekt → Eigenschaft → Wert)trgRohrMasterInsertUpdate (Insert/Update auf tblRohrMaster): → Dynamisches UNPIVOT aller 150 Spalten → MERGE tblObjektEigenschaft → sp_executesql pro Datenschreib-Operation → Kein Plan-Cache möglich trgObjektEigenschaftUpdate (Update auf tblObjektEigenschaft): → Lookup: idEigenschaft → Spaltenname → sp_executesql: UPDATE tblRohrMaster SET [dynamische Spalte] → Kein Plan-Cache möglich
In Zeiten geringer Rechnerleistung war dieses Modell ein sinnvoller Kompromiss. Heute ist es ein Engpass bei Massen-Updates (z.B. Migration, Nachtjobs).
Diese Stored Procedure erzeugt einen dynamischen PIVOT über alle Eigenschaften — der resultierende SQL-Text ändert sich je nach Anzahl der Eigenschaften. Kein Plan-Cache, keine stabile Ausführungszeit.
tblRohrMaster → asset.item (type_code='piping', properties=JSON)tblObjektEigenschaft → JSON-Felder in asset.item.propertiestrg_regen_type_views ersetzen den PIVOTWIS ist eine Synonym-Datenbank: 63 Synonyme zeigen auf AMED, HIST und AUDIT. PROOF ist eine externe Datenbank (nicht lokal verfügbar; Zugriff via Linked Server).
Die WIS TimeTrain-Engine ist architektonisch solide und wird vollständig in ENIVERSPIMS übernommen:
WIS-Funktionsfamilie (5-Phasen-Zyklus):
RuleBase-Tabelle
└─► tf_GetScheduledTasksForecast (Vorausplanung: welche Tasks wann fällig)
└─► sp_TimeTrain_AppendMissingTasks (Materialisierung in TimeTrain)
└─► sp_TimeTrainRun / sp_JedeNacht (Nachtjob)
└─► tf_GetScheduledTasksListCurrent (aktuelle Aufgabenliste)
└─► tf_GetScheduledTasksTreeCurrent (Baumansicht)
└─► sp_TimeTrain2Hist (Archivierung → HIST-DB)
1. CUTOFDAY-Schleife: Fehlende Tage aufholen (Catch-up bei Ausfällen) 2. sp_Deactivate: Inaktive Anlagen aus TimeTrain ausblenden 3. sp_TransferRules: Regeländerungen propagieren 4. sp_Activate: Neue/reaktivierte Anlagen aktivieren 5. sp_TimeTrain_AppendMissingTasks: Neue Tasks generieren (Fenster bis +90 Tage) 6. sp_TimeTrain2Hist: Erledigte Tasks → HIST-DB archivieren 7. Überfällige Tasks markieren (InProcess=4) 8. dtShow-Korrektur für Tasks ohne EIE-Datum
Verbindet Common + Names + RuleBase + App + AVI_Equip zu einer flachen Zeile:
APPMASTER (AppNr + AppBenennung) oder AVI_Equip (RegNr + INT_NR)sp_TimeTrain2Hist schreibt in HIST.dbo.TimeTrain_Hist — ebenfalls externCommon.IdSub (Geräte-ID aus AMED), keinen strukturellen TP
LD (früher: dbTECC) ist auf Betriebsmittel aus Elektriker-Perspektive ausgerichtet.
BESTAND.EMR_STELLE ist der natürliche Schlüssel für alle elektrischen Objekte.
| Tabelle | Zweck |
|---|---|
BESTAND | Betriebsmittel mit EMR_Stelle (Kennzeichnung) |
MOTORSTAMM | Motorenstammdaten (Elektriker-Felder) |
KV_NUMMER | Kraftverteiler-Nummern |
tblPerson | Benutzer (migriert → ENIVERSSIAM Phase 2) |
tblRolle | Rollen (migriert → ENIVERSSIAM Phase 2) |
Die neue Architektur mit asset.item und asset.electrical_connection vereint:
AMED (Mechanik-Sicht) LD/ENIVERS (Elektriker-Sicht) erwAppNr → asset.item.id EMR_STELLE → asset.item.item_number APPMASTER → type_code='device' BESTAND → type_code='electrical' MOTORMASTER → type_code='motor' KV_NUMMER → asset.electrical_connection.kv_number Beide Sichten auf dasselbe physische Objekt: asset.electrical_connection verknüpft device_id + motor_id + kv_code
Der Technische Platz ist weder AMED-Apparat noch ENIVERS-Betriebsmittel — er ist der neutrale strukturelle Slot, dem Equipment aus beiden Welten zugewiesen werden kann.