본문으로 건너뛰기

온톨로지(지식 그래프) 이해하기

온톨로지란?

**온톨로지(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_TOOPC 서버에 연결주입기 → 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는 두 가지를 함께 사용하여 각각의 장점을 활용합니다.