Understanding the Ontology (Knowledge Graph)
What Is an Ontology?
An Ontology is a map of the relationships between everything in a plant — equipment, sensors, alarms, work orders, products, and more.
A typical database (tables) is good at showing "lists." But it's hard to trace relationships like "Which sensors are connected to this equipment? What alarms are configured on those sensors? What work orders are related to those alarms?"
The ontology represents these relationships as a graph, letting AI explore them instantly.
As of the 2026-07 restructuring, the ontology is no longer a standalone service — it has been absorbed into the PlantPulse platform's integrated MCP (server-web /api/v5/mcp). The concepts and sync behavior described below remain valid; graph tools are now provided through the integrated MCP.
Tables vs. Graphs
Traditional Approach (Relational DB Tables)
[설비 테이블] [센서 테이블]
+----------+--------+ +----------+----------+-------+
| 설비_ID | 이름 | | 센서_ID | 설비_ID | 단위 |
+----------+--------+ +----------+----------+-------+
| E001 | 주입기 | | T001 | E001 | °C |
| E002 | 포장기 | | T002 | E001 | bar |
+----------+--------+ | T003 | E002 | rpm |
+----------+----------+-------+
"E001 설비와 연결된 모든 것을 찾으려면?"
→ 설비 테이블 조회 → 센서 테이블 조인 → 알람 테이블 조인 → 작업지시 테이블 조인 → ...
→ 테이블이 많아질수록 조인이 복잡해지고 느려짐
Ontology Approach (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
│
[직원: 김기사]
How do you find "everything related to the injector"? → Simply follow the connected lines (relationships) from the injector node → Results returned in milliseconds
PlantPulse Ontology Structure
14 Node Types (Entities)
Everything in the plant is represented as one of 14 node types.
┌─────────────────────────────────────────────┐
│ 자산 계층 │
│ │
│Enterprise ─→ Site ─→ Area ─→ Line ─→ Equipment│
│ │ │
│ Tag ←┘ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 운영 데이터 │
│ │
│ AlarmConfig Order Calendar │
│ (알람 설정) (작업지시) (일정) │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 마스터 데이터 │
│ │
│ Product Customer Employee Opc │
│ (제품) (고객) (직원) (OPC서버) │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 문서 데이터 │
│ │
│ AssetStatement AssetDocument │
│ (설비 명세서) (설비 문서) │
└─────────────────────────────────────────────┘
Relationships (Edges)
Connections between nodes are represented as relationships. Each relationship has a direction.
| Relationship | Meaning | Example |
|---|---|---|
OWNS_SITE | Enterprise owns a site | KOPENS → Daejeon Plant |
HAS_AREA | Site contains an area | Daejeon Plant → Manufacturing Building |
HAS_LINE | Area contains a line | Manufacturing Building → Line M_01 |
HAS_EQUIPMENT | Line contains equipment | M_01 → Injector |
HAS_TAG | Equipment has a sensor | Injector → Temperature Sensor |
HAS_ALARM | Alarm configured on equipment/tag | Temperature Sensor → High Temp Alarm |
HAS_ORDER | Work order assigned to equipment | Injector → Inspection Work Order |
PRODUCES | Line produces a product | M_01 → Product A |
CONNECTED_TO | Connected to OPC server | Injector → OPC Server 1 |
Subgraph Traversal
The ontology's most powerful feature is subgraph traversal.
By specifying a depth around a given node, you can retrieve all connections within that range in a single call.
depth=1 (Direct Connections Only)
질문: "주입기에 직접 연결된 것들을 보여줘"
[라인: M_01]
│
┌───────┼───────┐
▼ ▼
[온도센서] [압력센서]
│
[고온알람]
depth=2 (Up to 2 Levels)
질문: "주입기와 2단계 이내 연결된 모든 것을 보여줘"
[구역: 제조동] ← depth 2
│
[라인: M_01] ← depth 1
│
┌────────┼────────┐
▼ ▼ ▼
[온도] [압력] [고온알람] ← depth 1
│ │
▼ ▼
[OPC1] [작업지시] ← depth 2
│
[김기사] ← depth 2
Increasing the depth broadens the search scope, but setting it too high produces an enormous result set. depth=2 is suitable for most analyses.
Automatic Synchronization
When data in the PlantPulse main DB (PostgreSQL) changes, the Neo4j graph syncs automatically.
PlantPulse IIoT DB (PostgreSQL)
│
│ 60초마다 변경 감지
│
▼
Ontology 동기화 엔진
│
│ 변경된 엔티티만 업데이트
│ 배치 크기: 500건
│
▼
Neo4j 그래프 DB
(항상 최신 상태 유지)
There's no need to manage Neo4j manually. When equipment is added or a work order is created, it's automatically reflected in the graph.
How AI Uses the Ontology
Example 1: Comprehensive Equipment Report
사용자: "주입기 상태를 종합적으로 알려줘"
AI 내부 동작:
1. Ontology → 주입기 서브그래프(depth=2) 조회
→ 연결된 센서 5개, 알람 3개, 작업지시 2개 파악
2. 통합 MCP → 센서 5개 최신값 조회
3. TimeSeries → 이상 탐지 실행
4. 통합 MCP → 알람 3개 상태 확인
5. 통합 MCP → 작업지시 2개 진행 상황 확인
6. 종합 리포트 생성:
"주입기는 현재 정상 가동 중입니다.
센서 5개 중 온도센서에서 경미한 이상이 감지되었습니다.
관련 점검 작업지시가 김기사에게 할당되어 있습니다."
Example 2: Anomaly Impact Scope Analysis
사용자: "온도센서 이상이 어디까지 영향을 미칠 수 있어?"
AI 내부 동작:
1. Ontology → 온도센서 서브그래프(depth=3) 조회
→ 온도센서 → 주입기 → M_01 라인 → 제조동
2. 영향 범위 파악:
"온도센서 이상 → 주입기 정지 가능
→ M_01 라인 가동률 저하
→ 같은 라인의 다른 설비(포장기)에도 영향"
Example 3: Plant Structure Visualization
사용자: "대전 공장 구조를 보여줘"
AI 내부 동작:
1. Ontology → 대전 사이트 그래프 조회
2. Mermaid 다이어그램으로 자동 변환:
graph TD
대전공장 --> 제조동
대전공장 --> 유틸리티동
제조동 --> M_01라인
제조동 --> M_02라인
M_01라인 --> 주입기
M_01라인 --> 포장기
...
Graph DB vs. Relational DB Performance Comparison
| Query Type | Relational DB (PostgreSQL) | Graph DB (Neo4j) |
|---|---|---|
| Single entity lookup | Fast | Fast |
| 2-level relationship traversal | Requires 2 JOINs | Instant |
| 3-level relationship traversal | Requires 3 JOINs, increasingly slow | Instant |
| N-level relationship traversal | N-JOIN, very slow | Constant speed |
| "Everything connected" | Requires complex query | Single subgraph call |
Relational DBs excel at "list lookups," while graph DBs excel at "relationship traversal." PlantPulse uses both together to leverage the strengths of each.