====== 2. CAFM-Architektur — Gesamtübersicht ======

//Stand: 2026-03-05//

Übergeordnet: [[de:int:wvdsshell:notes:start|WvdS-Plattform — Gesamtübersicht]]
Verwandt: [[de:int:wvdsshell:notes:02-cafm:asset-model|2.2 Asset-Modell]] | [[de:int:wvdsshell:notes:02-cafm:legacy-analysis|2.3 Legacy-Analyse]] | [[de:int:wvdsshell:notes:02-cafm:migration|2.4 Migration]] | [[de:int:wvdsshell:notes:03-pims:start|3. PIMS-Architektur →]]

===== Ausgangssituation =====

Über mehr als zwei Jahrzehnte wurden Anlagen und Betriebsmittel in zwei vollständig getrennten Systemen verwaltet: **AMED** für die Mechanik-Sicht (Apparate, Maschinen, Rohrleitungen) und **LD/ENIVERS** für die Elektriker-Sicht (EMR-Stellen, Betriebsmittel, Kraftverteiler). Eine Pumpe mit Antriebsmotor erscheint in AMED als Apparat unter einer Anlagennummer und gleichzeitig in LD als Betriebsmittel unter einer EMR-Stelle. Zwischen beiden gibt es keine formale Verknüpfung — nur implizite Konventionen wie gleiche Anlagenbezeichnung oder ähnliche Nummerierung, die jedoch nie garantiert konsistent gehalten wurden.

Das führt zu konkreten Problemen im Betrieb: Wenn ein Gerät in AMED als aktiv geführt wird, LD es aber bereits als außer Betrieb kennt, entstehen falsche Prüflisten und fehlgeleitete Reparaturaufträge. Wer wissen möchte, welche Geräte in einem bestimmten Gebäudebereich installiert sind, in welchem Zustand sie sich befinden und wer dafür verantwortlich ist, muss beide Systeme manuell abgleichen — eine Arbeit, die fehleranfällig ist und regelmäßig wiederholt wird, ohne dass sich die Qualität der Daten dadurch dauerhaft verbessert.

TecDB, das System für Rohrprüfungen, ist ein weiteres isoliertes Silo. Es wurde über viele Jahre als EAV-Modell mit bidirektionalen Triggern betrieben. Die ursprüngliche Flexibilität dieses Ansatzes ist längst zum Hauptproblem geworden: Erweiterungen sind riskant, Performance-Probleme schwer eingrenzbar, und die Logik ist über Trigger verteilt, die sich gegenseitig aufrufen.

Auf Anwendungsseite bedeuteten neue Gerätetypen immer auch neue Datenbankfelder und neue Formularmasken — eine Kopplung von Datenmodell und Benutzeroberfläche, die jeden Erweiterungsschritt aufwändig macht und Fehler begünstigt.

Die neue CAFM-Architektur löst diese Probleme nicht durch Kompromisse, sondern durch ein klares Strukturprinzip: Es gibt einen Datenbestand, nicht drei. Jedes physische Objekt — egal ob Mechanik, Elektrik oder Rohrleitung — ist ein ''asset.item''. Welche Felder dieses Item hat, bestimmt ''property_schema'' zur Laufzeit; die Disziplin ergibt sich aus dem ''type_code'', nicht aus dem Quellsystem. Das Ergebnis ist eine Bestandsführung, die disziplin-neutral und schema-flexibel ist — ohne dass dafür Anwendungscode geändert werden muss, wenn ein neuer Gerätetyp hinzukommt.

===== Abgrenzung CAFM ↔ PIMS =====

^ Schicht   ^ Datenbank     ^ Frage, die sie beantwortet                          ^ Schema(s)                    ^
| **CAFM**  | ENIVERSCAFM   | //Was gibt es? Wo ist es? In welchem Zustand?//     | ''org.*'', ''asset.*''       |
| **PIMS**  | ENIVERSPIMS   | //Was muss getan werden? Was wurde getan? Wer?//    | ''inspection.*'', ''work.*'', ''safety.*'' |

CAFM = **Computer-Aided Facility Management** — Bestandsführung.
PIMS = **Plant Inspection Management System** — Prozessführung.

Diese Seite dokumentiert ausschliesslich **CAFM (ENIVERSCAFM)**.
Prozesse, Prüfungen, Aufträge, Sicherheitsgespräche → [[de:int:wvdsshell:notes:03-pims:start|3. PIMS-Architektur]].

===== Konzept =====

Die CAFM-Architektur vereint die drei historisch getrennten Bestandssichten — Mechanik (AMED), Elektrik (LD/ENIVERS) und Rohrleitungen (TecDB) — in einem gemeinsamen, disziplin-neutralen Bestandsmodell. Die Grundidee ist dabei bewusst einfach gehalten: Es gibt eine Tabelle für alle physischen Objekte (''asset.item''), eine Tabelle für alle ihre Eigenschaften (''asset.property_schema'') und eine Tabelle für die Zuordnung von Equipment zu Technischen Plätzen (''asset.item_installation''). Aus diesen drei Bausteinen lässt sich die gesamte Komplexität der bisherigen Einzelsysteme abbilden — ohne deren strukturelle Schwächen zu übernehmen.

==== Drei Systemebenen ====

^ Ebene                ^ Datenbank     ^ Schema(s)                  ^ Zweck                                              ^
| **1. Anwendungssystem** | ENIVERSSIAM | ''auth.*'', ''core.person'' | Identität, Auth, Rollen, HR-Basisdaten             |
| **2. Bestandssystem**   | ENIVERSCAFM | ''org.*'', ''asset.*''      | Technische Plätze, Equipments, Anlagen, Standorte  |
| **3. Prozesssystem**    | ENIVERSPIMS | ''inspection.*'', ''work.*'', ''safety.*'' | Prüfpläne, Aufträge, Sicherheitsgespräche |

==== Leitprinzipien ====

  * **Technischer Platz (TP) zuerst** — Der TP ist ein struktureller Slot, der immer existiert, unabhängig vom verbauten Equipment.
  * **Equipment ist mobil** — Physische Objekte werden über ''asset.item_installation'' dem TP zugeordnet; Historisierung inklusive.
  * **Disziplin-neutral** — ''asset.item'' kennt keinen Unterschied zwischen Mechanik und Elektrik; ''type_code'' bestimmt das Schema.
  * **Metadaten-getriebene UI** — ''asset.property_schema'' beschreibt alle Felder; keine hardcodierten Formulare.
  * **Bausteine** — Wiederverwendbare Eigenschaftsgruppen (z.B. Standort, Abmessung) als COMPOSITE-Typen in ''property_schema''.
  * **Einheitliche Listen** — Alle Auswahllisten in ''shared.list_item'' (erweiterbare Enum-Tabelle).
  * **Kein dynamisches SQL zur Laufzeit** — DDL-Trigger ''trg_regen_type_views'' generiert Views bei Schema-Änderungen.

===== Drei-Datenbank-Topologie =====

<code>
┌──────────────────────────────────────────────────────────────────────────────┐
│  SQL Server (Windows)                                                        │
│                                                                              │
│  ┌─────────────────────┐   ┌─────────────────────┐   ┌───────────────────┐  │
│  │   ENIVERSSIAM       │   │   ENIVERSCAFM        │   │  ENIVERSPIMS      │  │
│  │                     │   │                      │   │                   │  │
│  │  core.person        │◄──│  Synonyme (13×)      │   │  inspection.*     │  │
│  │  auth.user          │   │                      │   │  work.*           │  │
│  │  auth.role          │   │  org.branch          │   │  safety.*         │  │
│  │  auth.permission    │   │  org.site            │   │  fault.*          │  │
│  │  auth.device        │   │  org.location        │   │  doc.*            │  │
│  │  auth.token         │   │                      │   │  hist.*           │  │
│  │  auth.mfa_*         │   │  asset.item          │   │                   │  │
│  │                     │   │  asset.item_type     │   │  (im Aufbau)      │  │
│  │  (Produktiv)        │   │  asset.property_sch. │   │                   │  │
│  │                     │   │  asset.item_install. │   └───────────────────┘  │
│  └─────────────────────┘   │  asset.electrical_c. │                          │
│                             │                      │                          │
│                             │  shared.list_item    │   ← genutzt von          │
│                             │  (Listen/Enums)      │     CAFM + PIMS          │
│                             │                      │                          │
│                             │  (Produktiv)         │                          │
│                             └─────────────────────┘                          │
└──────────────────────────────────────────────────────────────────────────────┘
</code>

===== Greenfield-Workflow (neue Anlage) =====

<code>
Organisationsebene aufbauen
  └─► org.branch (Betriebsstätte / Werk)
        └─► org.site (Gebäude / Halle)
              └─► org.location (Raum / Zone)

Technische Plätze anlegen (Status: 'planned')
  └─► asset.item (type_code, parent_id, branch_id, status='planned')
        └─► asset.property_schema → UI-Formular wird automatisch generiert
              └─► Bausteine wie 'standort' (Anlage, Betrieb, Gebäude, Stock, Zone)
                  werden als COMPOSITE-Eigenschaften eingebunden

Prüfregeln definieren (ENIVERSPIMS)
  └─► inspection.rule → Intervalle, Typen, Verantwortliche
  └─► inspection.prerequisite → Dokumentanforderungen pro Item

Equipment einbauen (Status: 'active')
  └─► asset.item_installation
        ├─ fl_item_id  → Technischer Platz (asset.item)
        ├─ eq_item_id  → Equipment (asset.item, status='active')
        └─ installed_from → Einbaudatum
</code>

===== Ausgangslage: Legacy-Systeme (CAFM-Perspektive) =====

^ System          ^ Technologie              ^ CAFM-Migrationsziel       ^ Status              ^
| AMED            | C#/.NET + SQL Server     | ENIVERSCAFM ''asset.*''   | Ausstehend Phase 3  |
| TecDB           | SQL Server + EAV         | ENIVERSCAFM ''asset.item'' (type_code='piping') | Phase 4  |
| LD / ENIVERS    | SQL Server + Delphi      | ENIVERSCAFM ''asset.*''   | Phase 2 done (auth) |

Details: [[de:int:wvdsshell:notes:02-cafm:legacy-analysis|2.3 Legacy-Analyse (CAFM)]]

===== Dokumente dieser Sektion =====

^ Nr   ^ Dokument                                                                                                           ^ Inhalt                                                                  ^
| 2    | [[de:int:wvdsshell:notes:02-cafm:start|CAFM-Architektur — Gesamtübersicht]]                         | Diese Seite                                                             |
| 2.1  | [[de:int:wvdsshell:notes:02-cafm:system-layers|Systemebenen]]                                      | ENIVERSSIAM / ENIVERSCAFM / ENIVERSPIMS — Rollen und Grenzen            |
| 2.2  | [[de:int:wvdsshell:notes:02-cafm:asset-model|ENIVERSCAFM Asset-Modell]]                            | asset.item, property_schema, Bausteine, Lists, item_installation, Trigger |
| 2.3  | [[de:int:wvdsshell:notes:02-cafm:legacy-analysis|Legacy-Analyse (CAFM)]]                            | AMED, TecDB — CAFM-Perspektive, Schwächen, Mapping                      |
| 2.4  | [[de:int:wvdsshell:notes:02-cafm:migration|Migrationsplan (CAFM)]]                                  | Phasen 3–4 CAFM, Mapping-Tabellen, Greenfield-Workflow                  |