Architektur des Engineering-Betriebssystems für FMEA
Worum es hier geht
- Ein Engineering-Betriebssystem für FMEA besteht aus vier Schichten: Frontend (austauschbar), Skills-Schicht, Datenraum und LLMs.
- Das Frontend ist je nach Kundenkontext wählbar: meinGPT (Default), Open WebUI (LLM-agnostisch, von Cloud-API bis lokal), oder Microsoft Copilot Studio (M365-Häuser).
- Die Skills-Schicht ist self-hosted n8n. Sie orchestriert die einzelnen Fähigkeiten und verbindet sie mit dem Datenraum.
- Der Datenraum ist PostgreSQL mit pgvector und JSONB. Er bildet die FMEA-Struktur ab (Strukturanalyse, Funktionsnetz, Fehlernetz, Maßnahmen) und hält den Audit-Trail.
- Bestehende FMEA-Software (PeakAvenue/APIS IQ, Plato e1ns) und Wissensmanagement-Systeme (Empolis, Elunic) werden integriert, nicht ersetzt.
Drei Architektur-Prinzipien
Ein Engineering-Betriebssystem folgt drei Prinzipien, die es von einem Tool-Stack unterscheiden.
Modularität. Jede Schicht ist austauschbar, ohne dass die anderen Schichten neu gebaut werden müssen. Das Frontend kann von meinGPT auf Open WebUI wechseln, ohne dass die Skills-Schicht oder der Datenraum angepasst werden. Diese Modularität ist nicht ein Komfort-Feature, sondern eine Anforderung: Die Datenschutz-Lage eines Kunden bestimmt, welches Frontend möglich ist.
Datenraum-Anker. Der gemeinsame Datenraum ist der Punkt, an dem die Schichten zusammenkommen. Jeder Vorschlag, jede Bewertung, jede Maßnahme landet dort als strukturierter Datensatz. Damit ist die einzelne KI austauschbar — die Datenbasis bleibt.
Souveränität. Hosting, Datenflüsse und Vertragsstruktur sind so gewählt, dass die FMEA-Daten in Europa bleiben. Das ist nicht ein Marketing-Argument, sondern eine technische Eigenschaft, die sich in der Architektur ablesen lässt.
Die Frontend-Schicht — drei Varianten
Das Frontend ist der Punkt, an dem das FMEA-Team mit dem System interagiert. Drei Varianten kommen je nach Kontext in Frage.
*Variante 1: meinGPT — der Default.** Cloud-basiert, aber mit Hosting bei Hetzner in Deutschland und ISO-27001-Zertifizierung. Bringt Projektdateien als RAG mit, Microsoft-365-Konnektoren (SharePoint, OneDrive, Outlook im Lesemodus), eigene Skills und Workflows, und die für n8n unverzichtbare Custom-MCP-Einbindung. AVV nach Art. 28 DSGVO ist innerhalb von 2-3 Werktagen verfügbar. Für die meisten Mittelständler ohne strikte on-premise-Anforderung ist das der schnellste Weg zum produktiven System.
Variante 2: Open WebUI — das LLM-agnostische Self-Hosted-Frontend. Open WebUI läuft im eigenen Rechenzentrum oder bei einem EU-Hoster und spricht jedes LLM, das eine OpenAI-kompatible API anbietet — Anthropic Claude, OpenAI GPT, Google Gemini, oder lokale Modelle via Ollama. Mit einem LiteLLM-Gateway davor sogar 100+ Provider parallel. Vorteile: volle Kontrolle über Frontend, freie LLM-Wahl je nach Datenschutz-Lage, kein Vendor-Lock-in. Geeignet für Kunden, die bewusst kein Cloud-Frontend wollen, aber dennoch leistungsstarke LLMs nutzen.
Variante 3: Microsoft Copilot Studio mit FMEA-Copilot — für M365-Häuser. Wenn das Unternehmen ohnehin tief in Microsoft 365 lebt, wird der FMEA-Copilot in Copilot Studio gebaut. Wie bei meinGPT oder Open WebUI ist das Frontend ein Assistent mit System-Prompt, Methoden-Wissen, n8n-Skills als Tools und Internet-Zugriff — die Engineering-Spezialisierung kommt vom Setup, nicht vom Frontend. Vorteile: nahtlose Integration mit SharePoint, Teams, Outlook, niedrige Hürde für Endanwender. Voraussetzung: bestehende M365-Lizenzierung und AVV mit Microsoft.
Welche Variante die richtige ist, hängt nicht an einer Vorliebe, sondern an der Datenschutz-Anforderung, der bestehenden Infrastruktur und den Compliance-Vorgaben des Kunden. Die übrigen Schichten bleiben gleich. Die Methodik-Tiefe — System-Prompt, Methoden-Wissen, AIAG/VDA-Treue — ist in allen drei Varianten identisch, weil sie vom Assistent-Setup kommt, nicht vom Frontend.
Die Skills-Schicht — n8n als Klammer
self-hosted n8n ist die Automatisierungs- und Workflow-Schicht. Jede Fähigkeit des Engineering-Betriebssystems läuft als n8n-Workflow. Die Skills-Schicht hat drei Aufgaben:
- Orchestrierung. Workflows rufen einander auf. Die Strukturanalyse-Fähigkeit ruft die Funktionsanalyse-Fähigkeit auf, die wiederum die Plausibilitäts-Fähigkeit. Alles ohne, dass ein Mensch dazwischen klickt.
- Schnittstellen-Erfüllung. Jede Fähigkeit erfüllt die fünf Eigenschaften einer Engineering-Fähigkeit. Selbstbeschreibung, standardisierte Schnittstellen, Gedächtnis, Orchestrierbarkeit, Rückkopplungsschleife.
- MCP-Brücke. n8n exponiert seine Workflows als MCP-Server. Damit kann das Frontend (meinGPT, Open WebUI, Copilot Studio) die Fähigkeiten direkt aufrufen. Der Anwender chattet mit dem Frontend, das Frontend ruft im Hintergrund den passenden n8n-Workflow auf.
self-hosted n8n läuft im eigenen Rechenzentrum oder bei einem EU-Hoster (etwa Hetzner). Damit bleibt die Orchestrierungs-Schicht in europäischer Kontrolle, unabhängig davon, welches Frontend gewählt wird.
Der Datenraum — PostgreSQL und FMEA-Schema
Der Datenraum ist PostgreSQL mit zwei Erweiterungen: pgvector für Embeddings und JSONB für flexible Struktur-Repräsentation. Was hier abgebildet wird:
- FMEA-Struktur — Strukturanalyse, Funktionsnetz, Fehlernetz, Maßnahmen, jeweils mit Versionierung
- KI-Vorschläge — jeder Vorschlag mit Zeitstempel, Quell-KI, Eingabe-Kontext, Status (angenommen/abgelehnt/geändert)
- Wissensbasis — eingebettete Dokumente aus eurem Lastenheft, aus AIAG/VDA, aus früheren FMEAs, mit pgvector-Indexierung für semantische Suche
- Audit-Trail — was hat welche KI wann mit welchem Prompt vorgeschlagen, und wer hat es wie entschieden
Dieser Datenraum ist der Anker des Systems. Die Schichten darüber sind austauschbar. Der Datenraum ist der Grund, warum die nächste Sitzung weiß, was die vorige getan hat.
In Hochsicherheits-Szenarien läuft PostgreSQL on-premise. Im Standardfall bei einem EU-Hoster mit Verschlüsselung at-rest und in-transit.
Die LLM-Schicht — eine Deployment-Entscheidung
Die LLM-Schicht ist die Stelle, an der die Architektur ihre Compliance-Wahl trifft. Sie ist ein Deployment-Thema, kein Architektur-Thema — die Wahl folgt vier Achsen, die im Erstgespräch geklärt werden:
- Datenschutz-Anforderung — geht der Datenfluss über eine Cloud-API mit Auftragsverarbeitung in der EU? Oder muss das LLM das eigene Netz nicht verlassen?
- Reasoning-Anspruch — wie komplex ist die Aufgabe? Mehrstufiges Tool-Use mit MCP und FMEA-Methodik stellt höhere Anforderungen als einfache Klassifikation oder Übersetzung.
- Latenz — wie reaktiv soll das System in interaktiven FMEA-Sitzungen sein?
- Hardware-Verfügbarkeit — welche GPU-Ressourcen stehen für lokale Modelle bereit, jetzt und im Wachstum?
Die Modelle sind in jedem Fall austauschbar. Ein Wechsel von einem Provider zu einem anderen erfordert eine Konfigurationsänderung in n8n, nicht eine Neuaufstellung des Systems. Welche konkrete Konfiguration für euren Kontext richtig ist, entscheiden wir gemeinsam im Erstgespräch.
Integration mit bestehender Software
Das Engineering-Betriebssystem ersetzt nichts, was schon läuft.
- FMEA-Software — Bestehende Installationen von PeakAvenue/APIS IQ oder Plato e1ns bleiben. Das System liest aus der vorhandenen Datenbank und schreibt Vorschläge zurück als nachvollziehbare Datensätze.
- Wissensmanagement — Bestehende Wissens-Systeme (Empolis, Elunic und andere) werden als RAG-Datenquelle eingebunden. Die KI-Schicht greift auf ihre Inhalte zu, das System konsolidiert es mit den FMEA-Daten. Das ist die Brücke zwischen Engineering-Wissens-Konservierung und FMEA-Arbeit.
- Microsoft 365 / Google Workspace — Dokumente, die in SharePoint, OneDrive oder Google Drive liegen, werden im Lesemodus eingebunden. Das Frontend (meinGPT mit MS-Konnektoren oder Copilot Studio) macht das ohne Spezialentwicklung.
- PLM-Systeme — Wenn vorhanden, werden Stücklisten, Anforderungsdokumente und Änderungsstände aus dem PLM gelesen, um die FMEA mit aktuellen Engineering-Daten zu speisen.
Integration heißt: Das Engineering-Betriebssystem ist eine zusätzliche Schicht, kein Ersatz. Es macht aus eurem Tool-Stack ein System, ohne ihn neu zu kaufen.
Was austauschbar ist, was nicht
Die Modularität dieser Architektur hat klare Grenzen.
Austauschbar:
- Frontend (drei Varianten beschrieben)
- LLM-Provider (jeder mit OpenAI-kompatibler API: Anthropic, OpenAI, Google, Mistral, lokale Modelle — Wahl folgt der Deployment-Entscheidung)
- Einzelne Skills (jede Fähigkeit kann ergänzt, geändert oder ersetzt werden)
- Hosting-Provider (Hetzner, anderer EU-Hoster, on-premise)
Nicht austauschbar — sonst ist es kein Engineering-Betriebssystem mehr:
- Der gemeinsame Datenraum als Anker (ohne den ist es wieder Tool-Zoo)
- Die FMEA-Schema-Treue (Strukturanalyse, Funktionsnetz, Fehlernetz, Maßnahmen als getrennte, verknüpfte Entitäten)
- Die fünf Eigenschaften jeder Fähigkeit (sonst bekommt man Custom GPTs zurück)
- Die AIAG/VDA-2019-Methodik-Treue als nicht verhandelbarer Anker
Nächste Schritte
- Erstgespräch — kostenfrei, 30 Minuten, wir schauen uns eure aktuelle Architektur an und benennen die nächste sinnvolle Schicht. Kontaktformular.
- Übersicht — wenn ihr die Architektur in eine größere Story einbetten wollt: der Pillar zum Engineering-Betriebssystem.
- Frontend-Wahl — wenn die Entscheidung meinGPT vs. Open WebUI vs. Copilot Studio bei euch ansteht, dazu kommt ein eigener Artikel — oder direkt im Erstgespräch klären.
Hinweis: Mit * gekennzeichnete Links sind Werbung (Affiliate-Links).
Thomas Luft ist PCC-zertifizierter FMEA-Experte und AGILean Coach. Er berät Engineering-Unternehmen beim Aufbau KI-gestützter Prozesse. Kontakt und weitere Infos: fmea-ki.de.