2. CAFM-Architektur — Gesamtübersicht

Stand: 2026-03-05

Übergeordnet: WvdS-Plattform — Gesamtübersicht Verwandt: 2.2 Asset-Modell | 2.3 Legacy-Analyse | 2.4 Migration | 3. PIMS-Architektur →

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

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 → 3. PIMS-Architektur.

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.

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

┌──────────────────────────────────────────────────────────────────────────────┐
│  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)         │                          │
│                             └─────────────────────┘                          │
└──────────────────────────────────────────────────────────────────────────────┘

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

Details: 2.3 Legacy-Analyse (CAFM)