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 conventional database (tables) is good at showing "lists." But it struggles with relationship tracing — questions like "Which sensors are connected to this equipment? Which alarms are configured on those sensors? Which work orders relate to those alarms?"
An ontology expresses these relationships as a graph so that AI can traverse them instantly.
With 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 synchronization behavior described below remain valid, and the graph tools are provided through the integrated MCP.
Tables vs. Graphs
Conventional 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 lines (relationships) connected to the injector node → Results returned in milliseconds
PlantPulse Ontology Structure
14 Node Types (Entities)
Everything in the plant is represented by 14 types of nodes.
┌─────────────────────────────────────────────┐
│ 자산 계층 │
│ │
│ Company ─→ Site ─→ Area ─→ Line ─→ Equipment │
│ │ │
│ Tag ←┘ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 운영 데이터 │
│ │
│ AlarmConfig Order Calendar │
│ (알람 설정) (작업지시) (일정) │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 마스터 데이터 │
│ │
│ Product Customer Employee Opc │
│ (제품) (고객) (직원) (OPC서버) │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 문서 데이터 │
│ │
│ AssetStatement AssetDocument │
│ (설비 명세서) (설비 문서) │
└─────────────────────────────────────────────┘
Relationships (Edges)
Connections between nodes are expressed as relationships. Each relationship has a direction.
| Relationship | Meaning | Example |
|---|---|---|
OWNS_SITE | A company owns a site | KOPENS → Daejeon Plant |
HAS_AREA | A site contains an area | Daejeon Plant → Manufacturing Building |
HAS_LINE | An area contains a line | Manufacturing Building → M_01 line |
HAS_EQUIPMENT | A line contains equipment | M_01 → Injector |
HAS_TAG | Equipment holds a sensor | Injector → Temperature sensor |
HAS_ALARM | An alarm is configured on equipment/a tag | Temperature sensor → High-temperature alarm |
HAS_ORDER | A work order is assigned to equipment | Injector → Inspection task |
PRODUCES | A line produces a product | M_01 → Product A |
CONNECTED_TO | Connected to an OPC server | Injector → OPC Server 1 |
Subgraph Traversal
The most powerful capability of the ontology is subgraph traversal.
Specify a depth around a given node, and all connections within that range are retrieved at once.
depth=1 (Direct connections only)
질문: "주입기에 직접 연결된 것들을 보여줘"
[라인: M_01]
│
┌───────┼───────┐
▼ ▼
[온도센서] [압력센서]
│
[고온알람]
depth=2 (Up to two hops)
질문: "주입기와 2단계 이내 연결된 모든 것을 보여줘"
[구역: 제조동] ← depth 2
│
[라인: M_01] ← depth 1
│
┌────────┼────────┐
▼ ▼ ▼
[온도] [압력] [고온알람] ← depth 1
│ │
▼ ▼
[OPC1] [작업지시] ← depth 2
│
[김기사] ← depth 2
Increasing the depth explores a wider range, but too large a value produces an overwhelming result set. depth=2 is suitable for most analyses.
Automatic Synchronization
Whenever data changes in the PlantPulse main DB (PostgreSQL), the Neo4j graph is synchronized automatically.
PlantPulse IIoT DB (PostgreSQL)
│
│ 60초마다 변경 감지
│
▼
Ontology 동기화 엔진
│
│ 변경된 엔티티만 업데이트
│ 배치 크기: 500건
│
▼
Neo4j 그래프 DB
(항상 최신 상태 유지)
There is no need to manage Neo4j manually. When equipment is added or a work order is created, it is reflected in the graph automatically.
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
| Query Type | Relational DB (PostgreSQL) | Graph DB (Neo4j) |
|---|---|---|
| Single-entity lookup | Fast | Fast |
| 2-hop relationship traversal | Requires 2 JOINs | Instant |
| 3-hop relationship traversal | 3 JOINs, progressively slower | Instant |
| N-hop relationship traversal | N-JOINs, very slow | Constant speed |
| "Everything connected" | Requires a complex query | A single subgraph call |
Relational DBs excel at "list lookups"; graph DBs excel at "relationship traversal." PlantPulse uses both together to leverage the strengths of each.