Architektur

Dieses Dokument beschreibt, woraus PlantPulse AI besteht und warum es so aufgeteilt ist. Die Portliste finden Sie unter Service-Port-Map, die Installationsschritte unter Installation.

Die Struktur auf einen Blick

                        브라우저 (HTTPS · SSE)
                               │
                    ┌──────────▼──────────┐
                    │  plantpulse-proxy   │  ← 사용자 접점 (80 · 443, 콘솔 HTTPS 5960)
                    │  Host 로 뒷단을 고른다 │
                    └───┬──────────────┬──┘
           admin.* · 5960│              │그 외
     (평문 5959 는 직결) ▼              ▼
              ┌──────────────┐   ┌──────────────────────────────────┐
              │  관리 콘솔    │   │  코파일럿 (묻기·제안·자동화)       │
              │ admin-web    │   │  에이전트 루프 · 도구 호출          │
              │  + admin-api │   └───┬────┬────┬────┬────┬───────┬──┘
              └──────────────┘       │    │    │    │    │       │
                                     ▼    ▼    ▼    ▼    ▼       ▼
                                   시계열  RAG  문서  비전  디지털  모델
                                   인사이트     이해        스레드  게이트웨이
                                     │     │     │          │       │
                                     ▼     ▼     ▼          ▼       ▼
                                   추론  LightRAG docling    전용     vLLM
                                   서버  +Qdrant            Neo4j   임베딩·리랭커
                                        +Neo4j

Der Berührungspunkt für Benutzer ist der Proxy. Der Copilot (Fragen · Vorschläge · Automatisierung), die Verwaltungskonsole und alle APIs liegen dahinter — damit Firewall, TLS und Auditierung an einer Stelle gebündelt sind. Die Ausnahme ist der Klartext-Zugang der Verwaltungskonsole (5959), der für Betreiber, die sich im Firmennetz per IP verbinden, direkt den Konsolen-Container erreicht → Service-Port-Map

Aufteilung in sieben Stränge

Jeder Strang besteht aus einem Paar aus Zugang (API) und schwerem Arbeiter. Der Zugang ist leichtgewichtig und trägt die Policy, der Arbeiter nutzt die GPU. Dank dieser Trennung ändert sich die Adresse des Zugangs nicht, wenn der Arbeiter auf ein anderes Gerät verschoben oder auf mehrere Geräte skaliert wird.

Strang	Zugang	Arbeiter	Aufgabe
Chat	Copilot	—	Benutzeroberfläche (Fragen · Vorschläge · Automatisierung) · Agenten-Loop · Tool-Aufrufe · SSE-Streaming
Zeitreihe	Insight-API	Inferenzserver	Anomalieerkennung · Prognose (TSPulse · TTM)
Dokumentensuche	RAG API	LightRAG	Indizierung · hybride Suche
Dokumentenverständnis	Dokumentenverständnis-API	docling	PDF, Tabellen und Formeln nach markdown
Vision	Vision-API	LLM-Engine (direkt an vLLM) · docling	Messgerätablesung · Fehlerprüfung · OCR
Modelle	LiteLLM	vLLM · Embedding · Reranker	Modell-Anlaufstelle für Chat, Verwaltungskonsole und externe Aufrufe
Digital Thread	Digital-Thread-API	dediziertes Neo4j	Konnektorverzeichnis für Fremdsysteme (MES · SCM · ERP · PLM · QM) · Spiegel des Werksgraphen · Anlagen-Timeline

Der Digital Thread nutzt keine GPU

Dieser Strang gehört seit 2026.10 standardmäßig zum Stack. Er verknüpft das Anlagen- und Tag-Register der Plattform samt Ereignissen mit Arbeitsaufträgen, Teilen und Personen aus Fremdsystemen — ausschließlich als Referenzen — zu einem einzigen Graphen (Spiegel). Betreiber binden Konnektoren auf der Schiene Digital Thread der Verwaltungskonsole an; Fragen und Automatisierung lesen Anlagen-Timeline und Verknüpfungen über thread_-Tools — der Copilot erhält dafür keine eigene Oberfläche, sondern nur zusätzliche Fähigkeiten → Digital Thread

Die Verwaltungskonsole trifft keinerlei Entscheidungen

Die Oberfläche der Verwaltungskonsole (admin-web) besteht aus statischen Dateien; Anmeldeprüfung und Statusaggregation übernimmt das dahinterliegende admin-api. Das bedeutet: Es gibt nur eine einzige maßgebliche Instanz für die Authentifizierung.

Ablauf einer einzelnen Abfrage

「3라인 압축기 요즘 어때?」
   │
   ① 이름을 ID 로 바꾼다              search_domains        (플랫폼 통합 MCP)
   ② 무엇을 볼지 고른다                — 에이전트가 도구를 고른다
   ③ 데이터를 가져온다                 insight_analyze_asset · get_tag_history …
   ④ 필요하면 문서·사진을 더 본다        rag_search · vision_inspect
   ⑤ 모아서 답을 만든다                LiteLLM ─▶ Aura
   │
   └─▶ SSE 로 한 글자씩 화면에 흘린다

②–④ laufen nicht nur einmal durch. Der Agent betrachtet das Tool-Ergebnis und wählt daraufhin wiederholt das nächste Tool — das ist die Antwort auf „Warum dauert die Antwort so lange?" und zugleich auf „Warum müssen Tools eingeschaltet sein?".

🔴 Ausgeschaltete Tools sind für den Agenten unsichtbar. Welche Tools von Anfang an eingeschaltet und welche ausgeschaltet sind → MCP-Tool-Karte

Modelle — es gibt vier Aufrufnamen

Das Modell-Gateway (LiteLLM) stellt die internen Modelle über eine OpenAI-kompatible API bereit. Es gibt genau vier Aufrufnamen.

Aufrufname	Ziel	Tatsächliches Modell
`aura-lite`	interne LLM-Engine	Aura (Standard `Aura-Lite-NVFP4`) — Text und Bild
`aura-vision`	dieselbe Engine — Alias für Vision	dasselbe Modell wie oben
`aura-embedding-4b`	Embedding-Engine	Aura-Embedding-4B
`aura-reranker-0.6b`	Reranker-Engine	Aura-Reranker-0.6B

Die alten Namen gpt-4o · text-embedding-3-large gibt es nicht mehr

Früher erfolgte der Aufruf über OpenAI-kompatible Aliase (gpt-4o · gpt-4o-mini · text-embedding-3-large · rerank-multilingual-v3.0). Heute gibt es keine Kompatibilitäts-Aliase mehr — ein Aufruf unter dem alten Namen wird vom Gateway unmittelbar mit einem Fehler abgewiesen. Ersetzen Sie alte Namen in externen Integrationsskripten oder Konfigurationen durch die Namen aus der Tabelle oben.

aura-vision ist kein «separates Vision-Modell»

Aura liest Bilder bereits selbst. aura-vision ist lediglich ein vom Gateway vergebener Alias, damit die aufrufende Seite ihre Absicht über den Namen ausdrücken kann; unter beiden Namen antwortet dieselbe Engine.

Nicht alle Aufrufe laufen über das Gateway

Chat (Copilot) · Verwaltungskonsole · extern aufgerufenes /llm/ laufen über das Gateway. LightRAG · Vision-API · Zeitreihen-Insight-API verbinden sich direkt mit vLLM. Deshalb verwenden diese nicht den Gateway-Alias (aura-vision), sondern den von vLLM bereitgestellten Namen (aura-lite) — „Im Gateway-Log sind keine Vision-Aufrufe zu sehen" ist also kein Fehler.

Aura ist ein Eigenmodell, das auf einem Open-Source-Foundation-Modell basiert und mit Fertigungs- und Industriedaten nachtrainiert wurde → Aura LLM · KI-Modelle

Wo die Daten liegen

🔴 Der AI-Stack betreibt keine eigenen Datenbanken. Relationale Daten, Zeitreihen, Cache und Objektspeicher werden gemeinsam mit der Plattform genutzt. AI-exklusiv bleiben nur Graph- und Vektorspeicher.

Speicher	Zugehörigkeit	Inhalt
PostgreSQL	gemeinsam mit Plattform	Konfiguration · Chat-Verlauf · Status der Dokumentenindizierung · Konnektorverzeichnis (Schemata `co` · `dt` usw. in DB `pi`)
Aster TSDB	gemeinsam mit Plattform	Zeitreihen-Sensorwerte · Inferenzhistorie
Redis	gemeinsam mit Plattform	Cache · Sessions
RustFS	gemeinsam mit Plattform	Dokumente · Bilder
Qdrant	AI-exklusiv	Dokument-Embeddings (Vektoren)
Neo4j	AI-exklusiv	Wissensgraph der Dokumente
Neo4j (nur Digital Thread)	AI-exklusiv	Spiegel des Werksgraphen — nur Referenzen, aus der Quelle rekonstruierbar

Neo4j ist keine Ontologie, sondern ein «Dokumentengraph»

Die Anlagenontologie liegt bei der Plattform und wird über das integrierte MCP bereitgestellt. Das Neo4j hier ist der Graph, den die Dokumentensuche nutzt — früher gab es dafür einen eigenen Ontologie-Dienst, der inzwischen in der Plattform aufgegangen ist. Der Spiegel des Digital Thread liegt in einer separaten Instanz, damit sich beide nicht vermischen.

Steht die Plattform, steht auch die AI

Gemeinsam genutzte Daten bedeuten: Die Plattform ist eine harte Abhängigkeit. Bei „Die AI antwortet nicht" prüfen Sie in dieser Reihenfolge: ① Läuft die Plattform? ② Antwortet das Modell (Gateway · LLM-Engine)? ③ Sind die Tools eingeschaltet? → Problembehebung

Die Asset-Hierarchie folgt der Plattform

Die Daten-Tools adressieren ihre Ziele über eine Hierarchie auf Basis von ISA-95 / OPC-UA.

Enterprise ─ Site ─ Area ─ Line ─ Equipment ─ Tag ─ Point
엔터프라이즈 사이트   구역   라인    설비      태그   시계열 값

Der erste Schritt einer Abfrage besteht darin, zu bestimmen, welchem Knoten dieser Hierarchie eine Formulierung wie „Kompressor Linie 3" entspricht. Bild- und Dokument-Tools arbeiten unabhängig von dieser Hierarchie.

Observability und Air-Gap-Netzwerk

Komponente	Aufgabe
Phoenix	verfolgt, welche Tools in welcher Reihenfolge während einer Agenten-Runde aufgerufen wurden
DCGM	Kennzahlen zu GPU-Auslastung, Temperatur und Speicher
Interne Registry	damit Images im Air-Gap-Netzwerk intern bezogen werden

→ Monitoring · Installation im Air-Gap-Netzwerk

Die Struktur auf einen Blick​

Aufteilung in sieben Stränge​

Ablauf einer einzelnen Abfrage​

Modelle — es gibt vier Aufrufnamen​

Wo die Daten liegen​

Die Asset-Hierarchie folgt der Plattform​

Observability und Air-Gap-Netzwerk​

Verwandte Dokumente​