====== 2.3 CAFM — Legacy-Analyse ======

//Stand: 2026-03-05//

Übergeordnet: [[de:int:wvdsshell:notes:02-cafm:start|CAFM-Architektur — Gesamtübersicht]]
Verwandt: [[de:int:wvdsshell:notes:02-cafm:asset-model|2.2 Asset-Modell]] | [[de:int:wvdsshell:notes:02-cafm:migration|2.4 Migration]]

===== Überblick =====

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 — Mechanik-zentrisch =====

==== Fokus und Stärken ====

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

==== Objektdomänen ====

^ 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 |

==== Schwachstellen ====

  * **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.

<note>
**Benutzerdokumentation (Ist-Stand):** [[de:int:amed:01-assets:start|AMED 1. Apparatefunktion]] | [[de:int:amed:02-motors:start|AMED 2. Motorfunktionalität]]
</note>

==== Inspektionstypen (tdfObjectTypes — 17 Typen) ====

^ 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 — EAV-Problem =====

==== Architektur ====

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

==== Das Performance-Problem ====

<code>
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
</code>

In Zeiten geringer Rechnerleistung war dieses Modell ein sinnvoller Kompromiss.
Heute ist es ein **Engpass bei Massen-Updates** (z.B. Migration, Nachtjobs).

==== Exportproblem: procExportObjektAllePivot ====

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.

==== Migrationsziel ====

  * ''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 / PROOF — Prüfplanungs-Engine =====

==== Architektur ====

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).

==== Stärken ====

Die WIS TimeTrain-Engine ist architektonisch solide und wird vollständig in ENIVERSPIMS übernommen:

<code>
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)
</code>

==== Nachtjob sp_JedeNacht (Ablauf) ====

<code>
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
</code>

==== tf_GetCommonExtended — Kerndaten-View-Funktion ====

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

==== Schwachstellen ====

  * **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 / ENIVERS — Elektriker-zentrisch =====

==== Fokus und Stärken ====

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.

==== Kerntabellen ====

^ 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)  |

==== Schwachstellen ====

  * **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.

==== Was ENIVERS hatte, was AMED nicht hatte ====

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

==== Was AMED hatte, was ENIVERS nicht hatte ====

  * 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

<note>
**Benutzerdokumentation (Ist-Stand):** [[de:int:amed:start|AMED — Programmbeschreibung (Gesamtübersicht)]]
</note>

===== Fazit: "Beste beider Welten" =====

Die neue Architektur mit ''asset.item'' und ''asset.electrical_connection'' vereint:

<code>
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
</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.