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:

AMED ist auf Apparate (Maschinen, Behälter, Aggregate) ausgerichtet. APPMASTER.erwAppNr ist der universelle Primärschlüssel für alle mechanischen Objekte.

• Mechanik-zentrisch: Elektriker-Sicht (EMR-Stellen, Schaltschrank-Abgänge) ist nur über tblLocationKV und EZAMASTER ansatzweise abgedeckt.
• Kein Technischer Platz: APPMASTER beschreibt das physische Objekt, nicht den strukturellen Slot. Tausch eines Motors hinterlässt keine Slot-History.
• Kein TP-Konzept für Rohre: Rohre und Leitungen liegen separat in TecDB.

TecDB verwendet ein bidirektionales EAV-Modell (Entity-Attribute-Value):

• tblRohrMaster = flache Tabelle mit ~150 Spalten (eine pro Rohreigenschaft)
• tblObjektEigenschaft = EAV-Tabelle (Objekt → Eigenschaft → Wert)
• Beide Tabellen werden via bidirektionale Trigger synchron gehalten

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.properties
• Trigger entfallen; Views via trg_regen_type_views ersetzen den PIVOT
• Bidirektionale Synchronisation entfällt ersatzlos

WIS 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:

• Beschreibung aus APPMASTER (AppNr + AppBenennung) oder AVI_Equip (RegNr + INT_NR)
• Alle RuleBase-Codes (PIV, BZ, GP, EIE, AK, DK, PV, PO, MC, DAO, SU, SH, RM, MIN)
• Basis für alle TimeTrain-Forecast-Berechnungen

• Synonym-Abhängigkeiten: 63 Synonyme auf 3+ Datenbanken; wartungsintensiv
• PROOF extern: Kein direkter Zugriff aus WIS; Linked-Server-Abhängigkeit
• HIST extern: sp_TimeTrain2Hist schreibt in HIST.dbo.TimeTrain_Hist — ebenfalls extern
• Kein TP-Konzept: WIS kennt nur Common.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.

• Elektriker-zentrisch: Mechanik-Sicht (Apparat, Behälter, Aggregate) fehlt vollständig.
• EMR_STELLE als natürlicher Schlüssel: Umbenennungen erfordern Kaskaden-Updates.
• Kein TP-Konzept: BESTAND beschreibt das Betriebsmittel, nicht den Einbauort.

• Klare KV-Nummern und Schaltschrankzuordnung
• EMR-Stelle als standardisiertes Kennzeichnungssystem
• Vollständige Elektriker-Sicht auf Motoren und Antriebe

• Apparate-Hierarchie (was gehört zu welcher Maschine)
• Mechanische Inspektionstypen (Druckprüfung, Sachkundigenprüfung)
• TÜV-Überwachung (AVI_Equip)
• Vollständige mechanische Sicht auf Aggregate und Behälter

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.