Ontologie (Wissensgraph) verstehen

Was ist eine Ontologie?

Eine Ontologie (Ontology) ist eine kartenartige Darstellung der Beziehungen zwischen allen Dingen in einer Fabrik — Anlagen, Sensoren, Alarmen, Arbeitsaufträgen, Produkten usw.

Eine gewöhnliche Datenbank (Tabelle) zeigt "Listen" gut an. Aber Beziehungsverfolgung wie "Welche Sensoren sind mit dieser Anlage verbunden? Welche Alarme sind für diesen Sensor konfiguriert? Welche Arbeitsaufträge stehen mit diesem Alarm in Zusammenhang?" ist damit schwierig.

Eine Ontologie stellt diese Beziehungen als Graph dar, sodass die KI sie sofort durchsuchen kann.

info

Mit der Umstrukturierung vom 2026-07 wurde die Ontologie nicht mehr als eigenständiger Dienst, sondern in das integrierte MCP (server-web /api/v5/mcp) der PlantPulse Platform aufgenommen. Die untenstehenden Konzept- und Synchronisationsbeschreibungen bleiben unverändert gültig, die Graph-Werkzeuge werden über das integrierte MCP bereitgestellt.

---

Tabelle vs. Graph

Herkömmlicher Ansatz (relationale DB-Tabellen)

[설비 테이블]                    [센서 테이블]
+----------+--------+           +----------+----------+-------+
| 설비_ID   | 이름   |           | 센서_ID   | 설비_ID   | 단위  |
+----------+--------+           +----------+----------+-------+
| E001     | 주입기  |           | T001     | E001     | °C    |
| E002     | 포장기  |           | T002     | E001     | bar   |
+----------+--------+           | T003     | E002     | rpm   |
                                +----------+----------+-------+

"E001 설비와 연결된 모든 것을 찾으려면?"
→ 설비 테이블 조회 → 센서 테이블 조인 → 알람 테이블 조인 → 작업지시 테이블 조인 → ...
→ 테이블이 많아질수록 조인이 복잡해지고 느려짐

Ontologie-Ansatz (Graph-DB)

                    [엔터프라이즈: 코펜스]
                         │
                    OWNS_SITE
                         │
                    [사이트: 대전]
                         │
                    HAS_AREA
                         │
                    [구역: 제조동]
                         │
                    HAS_LINE
                         │
                    [라인: M_01]
                    ╱          ╲
          HAS_EQUIPMENT    HAS_EQUIPMENT
              ╱                    ╲
    [설비: 주입기]              [설비: 포장기]
      ╱    │    ╲                    │
 HAS_TAG  HAS_TAG  HAS_ALARM    HAS_TAG
    ╱      │          ╲              │
[온도]  [압력]    [고온알람]        [속도]
                      │
                 TRIGGERS
                      │
                 [작업지시: 점검]
                      │
                 ASSIGNED_TO
                      │
                 [직원: 김기사]

Wie findet man "alles, was mit dem Injektor zusammenhängt"? → Man folgt einfach den vom Injektor-Knoten ausgehenden Linien (Beziehungen) → Ergebnis in Millisekunden

---

Struktur der PlantPulse-Ontologie

14 Knotentypen (Entitäten)

Alles in der Fabrik wird durch 14 Knotentypen dargestellt.

┌─────────────────────────────────────────────┐
│                 자산 계층                      │
│                                              │
│Enterprise ─→ Site ─→ Area ─→ Line ─→ Equipment│
│                                       │       │
│                                    Tag ←┘     │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│                 운영 데이터                    │
│                                              │
│  AlarmConfig    Order    Calendar             │
│  (알람 설정)    (작업지시)  (일정)              │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│                 마스터 데이터                   │
│                                              │
│  Product   Customer   Employee   Opc         │
│  (제품)     (고객)     (직원)    (OPC서버)     │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│                 문서 데이터                    │
│                                              │
│  AssetStatement    AssetDocument              │
│  (설비 명세서)      (설비 문서)                │
└─────────────────────────────────────────────┘

Beziehungen (Kanten)

Verbindungen zwischen Knoten werden als Beziehungen dargestellt. Jede Beziehung hat eine Richtung.

Beziehung	Bedeutung	Beispiel
OWNS_SITE	Unternehmen besitzt Standort	KOPENS → Daejeon-Werk
HAS_AREA	Standort enthält Bereich	Daejeon-Werk → Fertigungsgebäude
HAS_LINE	Bereich enthält Linie	Fertigungsgebäude → Linie M_01
HAS_EQUIPMENT	Linie enthält Anlage	M_01 → Injektor
HAS_TAG	Anlage besitzt Sensor	Injektor → Temperatursensor
HAS_ALARM	Alarm an Anlage/Tag konfiguriert	Temperatursensor → Hochtemperaturalarm
HAS_ORDER	Arbeitsauftrag der Anlage zugewiesen	Injektor → Inspektionsauftrag
PRODUCES	Linie produziert Produkt	M_01 → Produkt A
CONNECTED_TO	Verbindung zum OPC-Server	Injektor → OPC-Server1

---

Subgraph-Durchsuchung

Die mächtigste Funktion der Ontologie ist die Subgraph-Durchsuchung.

Wenn man rund um einen bestimmten Knoten eine Depth (Tiefe) angibt, werden alle Verbindungen innerhalb dieses Bereichs auf einmal abgerufen.

depth=1 (nur direkte Verbindungen)

질문: "주입기에 직접 연결된 것들을 보여줘"

           [라인: M_01]
                │
        ┌───────┼───────┐
        ▼               ▼
   [온도센서]      [압력센서]
        │
   [고온알람]

depth=2 (bis zu zwei Stufen)

질문: "주입기와 2단계 이내 연결된 모든 것을 보여줘"

     [구역: 제조동]              ← depth 2
           │
     [라인: M_01]               ← depth 1
           │
  ┌────────┼────────┐
  ▼        ▼        ▼
[온도]   [압력]   [고온알람]     ← depth 1
  │                  │
  ▼                  ▼
[OPC1]          [작업지시]       ← depth 2
                     │
                [김기사]         ← depth 2

Eine größere Depth durchsucht einen breiteren Bereich, aber bei zu großer Tiefe werden die Ergebnisse unübersichtlich. depth=2 eignet sich für die meisten Analysen.

---

Automatische Synchronisierung

Wenn sich Daten in der Haupt-DB von PlantPulse (PostgreSQL) ändern, wird der Neo4j-Graph automatisch synchronisiert.

PlantPulse IIoT DB (PostgreSQL)
    │
    │  60초마다 변경 감지
    │
    ▼
Ontology 동기화 엔진
    │
    │  변경된 엔티티만 업데이트
    │  배치 크기: 500건
    │
    ▼
Neo4j 그래프 DB
    (항상 최신 상태 유지)

info

Eine manuelle Verwaltung von Neo4j ist nicht erforderlich. Wenn eine Anlage hinzugefügt oder ein Arbeitsauftrag erstellt wird, spiegelt sich dies automatisch im Graphen wider.

---

Wie die KI die Ontologie nutzt

Beispiel 1: Umfassender Anlagenbericht

사용자: "주입기 상태를 종합적으로 알려줘"

AI 내부 동작:
1. Ontology → 주입기 서브그래프(depth=2) 조회
   → 연결된 센서 5개, 알람 3개, 작업지시 2개 파악

2. 통합 MCP → 센서 5개 최신값 조회
3. TimeSeries → 이상 탐지 실행
4. 통합 MCP → 알람 3개 상태 확인
5. 통합 MCP → 작업지시 2개 진행 상황 확인

6. 종합 리포트 생성:
   "주입기는 현재 정상 가동 중입니다.
    센서 5개 중 온도센서에서 경미한 이상이 감지되었습니다.
    관련 점검 작업지시가 김기사에게 할당되어 있습니다."

Beispiel 2: Analyse des Auswirkungsbereichs einer Anomalie

사용자: "온도센서 이상이 어디까지 영향을 미칠 수 있어?"

AI 내부 동작:
1. Ontology → 온도센서 서브그래프(depth=3) 조회
   → 온도센서 → 주입기 → M_01 라인 → 제조동

2. 영향 범위 파악:
   "온도센서 이상 → 주입기 정지 가능
    → M_01 라인 가동률 저하
    → 같은 라인의 다른 설비(포장기)에도 영향"

Beispiel 3: Visualisierung der Fabrikstruktur

사용자: "대전 공장 구조를 보여줘"

AI 내부 동작:
1. Ontology → 대전 사이트 그래프 조회
2. Mermaid 다이어그램으로 자동 변환:

graph TD
    대전공장 --> 제조동
    대전공장 --> 유틸리티동
    제조동 --> M_01라인
    제조동 --> M_02라인
    M_01라인 --> 주입기
    M_01라인 --> 포장기
    ...

---

Leistungsvergleich: Graph-DB vs. relationale DB

Abfragetyp	Relationale DB (PostgreSQL)	Graph-DB (Neo4j)
Abfrage einer einzelnen Entität	Schnell	Schnell
Durchsuchung von Beziehungen über 2 Stufen	2 JOINs erforderlich	Sofort
Durchsuchung von Beziehungen über 3 Stufen	3 JOINs, zunehmend langsam	Sofort
Durchsuchung von Beziehungen über N Stufen	N-JOINs, sehr langsam	Konstante Geschwindigkeit
"Alles Verbundene"	Komplexe Abfrage erforderlich	Ein Subgraph-Aufruf

info

Relationale DBs sind stark bei "Listenabfragen", Graph-DBs sind stark bei der "Beziehungsdurchsuchung". PlantPulse nutzt beide gemeinsam, um die jeweiligen Vorteile auszuspielen.