온톨로지(지식 그래프) 이해하기
온톨로지란?
**온톨로지(Ontology)**는 공장의 모든 것들 — 설비, 센서, 알람, 작업지시, 제품 등 — 사이의 관계를 지도처럼 그린 것입니다.
일반적인 데이터베이스(테이블)는 "목록"을 잘 보여줍니다. 하지만 "이 설비와 연결된 센서는? 그 센서에 설정된 알람은? 그 알람과 관련된 작업지시는?" 같은 관계 추적은 어렵습니다.
온톨로지는 이런 관계를 그래프로 표현하여 AI가 즉시 탐색할 수 있게 합니다.
2026-07 개편으로 온톨로지는 독립 서비스가 아니라 PlantPulse 플랫폼 통합 MCP(server-web /api/v5/mcp)에 흡수되었습니다. 아래 개념·동기화 설명은 그대로 유효하며, 그래프 도구는 통합 MCP를 통해 제공됩니다.
테이블 vs 그래프
기존 방식 (관계형 DB 테이블)
[설비 테이블] [센서 테이블]
+----------+--------+ +----------+----------+-------+
| 설비_ID | 이름 | | 센서_ID | 설비_ID | 단위 |
+----------+--------+ +----------+----------+-------+
| E001 | 주입기 | | T001 | E001 | °C |
| E002 | 포장기 | | T002 | E001 | bar |
+----------+--------+ | T003 | E002 | rpm |
+----------+----------+-------+
"E001 설비와 연결된 모든 것을 찾으려면?"
→ 설비 테이블 조회 → 센서 테이블 조인 → 알람 테이블 조인 → 작업지시 테이블 조인 → ...
→ 테이블이 많아질수록 조인이 복잡해지고 느려짐
온톨로지 방식 (그래프 DB)
[회사: 코펜스]
│
OWNS_SITE
│
[사이트: 대전]
│
HAS_AREA
│
[구역: 제조동]
│
HAS_LINE
│
[라인: M_01]
╱ ╲
HAS_EQUIPMENT HAS_EQUIPMENT
╱ ╲
[설비: 주입기] [설비: 포장기]
╱ │ ╲ │
HAS_TAG HAS_TAG HAS_ALARM HAS_TAG
╱ │ ╲ │
[온도] [압력] [고온알람] [속도]
│
TRIGGERS
│
[작업지시: 점검]
│
ASSIGNED_TO
│
[직원: 김기사]
"주입기와 관련된 모든 것"을 찾으려면? → 주입기 노드에서 연결된 선(관계)을 따라가기만 하면 됨 → 밀리초 단위로 결과 반환
PlantPulse 온톨로지 구조
14종 노드 (엔티티)
공장의 모든 것을 14가지 유형의 노드로 표현합니다.
┌─────────────────────────────────────────────┐
│ 자산 계층 │
│ │
│ Company ─→ Site ─→ Area ─→ Line ─→ Equipment │
│ │ │
│ Tag ←┘ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 운영 데이터 │
│ │
│ AlarmConfig Order Calendar │
│ (알람 설정) (작업지시) (일정) │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 마스터 데이터 │
│ │
│ Product Customer Employee Opc │
│ (제품) (고객) (직원) (OPC서버) │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 문서 데이터 │
│ │
│ AssetStatement AssetDocument │
│ (설비 명세서) (설비 문서) │
└─────────────────────────────────────────────┘
관계 (엣지)
노드 간의 연결은 관계로 표현됩니다. 각 관계에는 방향이 있습니다.
| 관계 | 의미 | 예시 |
|---|---|---|
OWNS_SITE | 회사가 사이트를 소유 | 코펜스 → 대전공장 |
HAS_AREA | 사이트가 구역을 포함 | 대전공장 → 제조동 |
HAS_LINE | 구역이 라인을 포함 | 제조동 → M_01 라인 |
HAS_EQUIPMENT | 라인이 설비를 포함 | M_01 → 주입기 |
HAS_TAG | 설비가 센서를 보유 | 주입기 → 온도센서 |
HAS_ALARM | 설비/태그에 알람 설정 | 온도센서 → 고온알람 |
HAS_ORDER | 설비에 작업지시 할당 | 주입기 → 점검작업 |
PRODUCES | 라인이 제품을 생산 | M_01 → 제품A |
CONNECTED_TO | OPC 서버에 연결 | 주입기 → OPC서버1 |
서브그래프 탐색
온톨로지의 가장 강력한 기능은 서브그래프 탐색입니다.
특정 노드를 중심으로 **depth(깊이)**를 지정하면, 그 범위 내의 모든 연결을 한번에 가져옵니다.
depth=1 (직접 연결만)
질문: "주입기에 직접 연결된 것들을 보여줘"
[라인: M_01]
│
┌───────┼───────┐
▼ ▼
[온도센서] [압력센서]
│
[고온알람]
depth=2 (2단계까지)
질문: "주입기와 2단계 이내 연결된 모든 것을 보여줘"
[구역: 제조동] ← depth 2
│
[라인: M_01] ← depth 1
│
┌────────┼────────┐
▼ ▼ ▼
[온도] [압력] [고온알람] ← depth 1
│ │
▼ ▼
[OPC1] [작업지시] ← depth 2
│
[김기사] ← depth 2
depth를 늘리면 더 넓은 범위를 탐색하지만, 너무 크면 결과가 방대해집니다. depth=2가 대부분의 분석에 적합합니다.
자동 동기화
PlantPulse 메인 DB(PostgreSQL)의 데이터가 변경되면 Neo4j 그래프가 자동으로 동기화됩니다.
PlantPulse IIoT DB (PostgreSQL)
│
│ 60초마다 변경 감지
│
▼
Ontology 동기화 엔진
│
│ 변경된 엔티티만 업데이트
│ 배치 크기: 500건
│
▼
Neo4j 그래프 DB
(항상 최신 상태 유지)
수동으로 Neo4j를 관리할 필요가 없습니다. 설비가 추가되거나 작업지시가 생성되면 자동으로 그래프에 반영됩니다.
AI가 온톨로지를 활용하는 방법
예시 1: 설비 종합 리포트
사용자: "주입기 상태를 종합적으로 알려줘"
AI 내부 동작:
1. Ontology → 주입기 서브그래프(depth=2) 조회
→ 연결된 센서 5개, 알람 3개, 작업지시 2개 파악
2. 통합 MCP → 센서 5개 최신값 조회
3. TimeSeries → 이상 탐지 실행
4. 통합 MCP → 알람 3개 상태 확인
5. 통합 MCP → 작업지시 2개 진행 상황 확인
6. 종합 리포트 생성:
"주입기는 현재 정상 가동 중입니다.
센서 5개 중 온도센서에서 경미한 이상이 감지되었습니다.
관련 점검 작업지시가 김기사에게 할당되어 있습니다."
예시 2: 이상 영향 범위 분석
사용자: "온도센서 이상이 어디까지 영향을 미칠 수 있어?"
AI 내부 동작:
1. Ontology → 온도센서 서브그래프(depth=3) 조회
→ 온도센서 → 주입기 → M_01 라인 → 제조동
2. 영향 범위 파악:
"온도센서 이상 → 주입기 정지 가능
→ M_01 라인 가동률 저하
→ 같은 라인의 다른 설비(포장기)에도 영향"
예시 3: 공장 구조 시각화
사용자: "대전 공장 구조를 보여줘"
AI 내부 동작:
1. Ontology → 대전 사이트 그래프 조회
2. Mermaid 다이어그램으로 자동 변환:
graph TD
대전공장 --> 제조동
대전공장 --> 유틸리티동
제조동 --> M_01라인
제조동 --> M_02라인
M_01라인 --> 주입기
M_01라인 --> 포장기
...
그래프 DB vs 관계형 DB 성능 비교
| 쿼리 유형 | 관계형 DB (PostgreSQL) | 그래프 DB (Neo4j) |
|---|---|---|
| 단일 엔티티 조회 | 빠름 | 빠름 |
| 2단계 관계 탐색 | JOIN 2회 필요 | 즉시 |
| 3단계 관계 탐색 | JOIN 3회, 점점 느려짐 | 즉시 |
| N단계 관계 탐색 | N-JOIN, 매우 느림 | 일정한 속도 |
| "연결된 모든 것" | 복잡한 쿼리 필요 | 서브그래프 1회 호출 |
관계형 DB는 "목록 조회"에 강하고, 그래프 DB는 "관계 탐색"에 강합니다. PlantPulse는 두 가지를 함께 사용하여 각각의 장점을 활용합니다.