IoT Smart Factory — 이상 감지부터 일별 rollup, 온톨로지까지

워크숍 목표

다 끝내고 나면 D.Hub 안에서 다음 흐름을 한 사이클 손으로 통과한 셈이 됩니다.

• 시나리오 1개를 포털로 적재해 raw 와 processed 두 sub-collection, 데이터셋 3종, 코드 노드 4종, 파이프라인 3종, 온톨로지 3엔티티/2관계, 대시보드를 한꺼번에 등록합니다.
• 30초 주기로 들어오는 machine_sensors 원시 row의 모양과 quality_flag 상태 신호의 분포를 살펴봅니다.
• anomaly_detection 파이프라인을 한 번 돌려 anomaly_detections 에 HIGH / MEDIUM / LOW 심각도가 어떻게 떨어지는지 봅니다.
• equipment_health_rollup 파이프라인이 가중 패널티(HIGH × 10, MEDIUM × 4, LOW × 1)로 0–100 점 일별 건강 점수를 만든다는 점을 확인하고, 매일 1am 스케줄로 자동 실행되도록 등록합니다.
• ontology_materialization 파이프라인을 한 번 돌려 IOT_Machine ─ IOT_reads_from ─ IOT_Sensor, IOT_Machine ─ IOT_triggers ─ IOT_MaintenanceEvent 두 경로를 그래프 탐색기에서 펼쳐 봅니다.
• (선택) 코드 노드 anomaly_detection.py 의 3-시그마 임계값을 살짝 만져 보고, 다시 돌렸을 때 심각도 분포가 어떻게 움직이는지 정성적으로 살펴봅니다.

엔지니어 코스의 코드 노드·파이프라인 옵션·스케줄링 레슨에서 익힌 개념을 제조 IIoT 시나리오 하나 위에 묶어 보는 통합 실습입니다. 권장 소요 시간은 90분, 선택 섹션까지 포함하면 100분쯤입니다.

사전 준비

• D.Hub 포털 접근 가능한 엔지니어 계정 (Editor 권한 이상, 파이프라인 실행과 스케줄 등록 가능)
• 약 50KB 의 zip 한 개를 받을 다운로드 여유

터미널·Python·dhub2-examples 클론은 필요 없습니다. 입문 튜토리얼인 시나리오 zip 으로 한 번에 가져오기 를 먼저 끝내 두면 1단계가 매끄럽게 풀립니다. 튜토리얼 페이지는 이 워크숍 상단의 사전 학습 카드에서 바로 열 수 있습니다.

1. 시나리오 적재 (10분)

zip 한 개를 받아 포털의 가져오기 다이얼로그로 올리면 시나리오에 묶인 자산이 한꺼번에 등록됩니다.

zip 을 받았다면 포털에서 좌측 사이드바의 컬렉션 으로 들어갑니다. Explorer 상단 헤더 — 페이지 제목 컬렉션 영역 — 오른쪽 더보기(⋯) 메뉴에 가져오기 항목이 있습니다. 이 항목을 눌러 가져오기 다이얼로그를 열고 방금 받은 zip 을 선택합니다. 업로드 진행률이 다이얼로그 안에 표시되고, 끝나면 컬렉션 두 개가 자동으로 만들어집니다.

manifest.json 순서대로 다음 자산이 차례로 올라갑니다.

1. 컬렉션 2종 — raw (alias: IoT 원시 수집 데이터), processed (alias: 가공된 IoT 데이터)
2. 데이터셋 3종 — machine_sensors (raw), anomaly_detections (processed), equipment_health (processed)
3. 코드 4종 (Python) — sensor_normalization, anomaly_detection, equipment_health_rollup, build_iot_ontology
4. 파이프라인 3종 — anomaly_detection, equipment_health_rollup, ontology_materialization
5. 온톨로지 — 엔티티 3종(IOT_Machine, IOT_Sensor, IOT_MaintenanceEvent), 관계 2종(IOT_reads_from, IOT_triggers)
6. 지식 1종 — maintenance_manual (유지보수 표준 운영 절차)
7. 대시보드 — equipment_health (alias: 설비 건전성 현황)

적재가 끝나면 포털 좌측 컬렉션 트리에 raw 와 processed 두 항목이 나란히 떠 있을 겁니다. 보이면 1단계 끝. 시나리오가 raw 랜딩 존 과 가공·파생 데이터를 일부러 분리해 두는 패턴이라는 점은 머리에 남겨 둡니다. machine_sensors 만 raw 컬렉션에 들어가고, 나머지 파이프라인 산출물과 온톨로지 평탄화 테이블은 모두 processed 컬렉션에 떨어집니다.

2. 데이터 둘러보기 (10분)

raw 컬렉션을 열어 machine_sensors 데이터셋부터 봅니다. 미리 보기 탭에서 6개 컬럼이 잡힙니다.

• reading_id — 측정 레코드 고유 식별자
• machine_id — 12대 CNC 머신 중 한 대 (M-001 ~ M-012 형식)
• sensor_type — vibration / temperature / pressure 중 하나
• value — sensor_type 별 단위. 진동은 m/s², 온도는 °C, 압력은 bar
• recorded_at — UTC timestamp. 약 30초 주기
• quality_flag — OK 가 정상. HIGH_VIBRATION / HIGH_TEMP / HIGH_PRESSURE 는 센서가 이미 상태 신호를 잡은 row

스키마 탭에서 value 와 quality_flag 가 nullable 인지도 확인합니다. 센서가 고장 나면 value 가 null 로 들어올 수 있고, 정제 파이프라인이 짧은 구간 한정으로 forward-fill 한다는 전제입니다.

quality_flag 분포를 한 번 살펴 두면 다음 단계의 이상 감지 결과를 해석할 때 편합니다. 대부분 OK 지만 HIGH_* 상태 신호가 일부 row 에 이미 박혀 있고, 이 row 들은 3-시그마 z-score 와 무관하게 곧장 HIGH 심각도 이상으로 승격됩니다.

이어서 processed 컬렉션을 엽니다. anomaly_detections 와 equipment_health 두 데이터셋이 자리만 잡혀 있고 행 0 인지 확인합니다. 적재 직후엔 비어 있고, 다음 단계 파이프라인이 첫 행을 채워 넣습니다.

3. 첫 파이프라인 — anomaly_detection (15분)

processed 컬렉션의 파이프라인 섹션에서 anomaly_detection 을 눌러 워크플로우 편집기를 엽니다. 노드 두 개가 보입니다.

• normalize_sensors — 스크립트 sensor_normalization. 입력 machine_sensors → 출력 machine_sensors (in-place 정규화)
• detect_anomalies — 스크립트 anomaly_detection. 입력 machine_sensors → 출력 anomaly_detections. normalize_sensors 에 의존

normalize_sensors 노드를 누르고 우측 패널의 스크립트 미리 보기를 펼치면 핵심 한 줄이 잡힙니다. quality_flag 가 ["OK", "HIGH_VIBRATION", "HIGH_PRESSURE", "HIGH_TEMP"] 중 하나인 row 만 남기고, machine 과 sensor 별로 정렬한 뒤 value 컬럼을 최대 연속 3 row 까지 forward-fill 합니다. 포인트는 HIGH_* 상태 신호 row 가 정규화 단계에서 버려지지 않는다는 점입니다. 다음 노드에서 곧장 HIGH 이상으로 승격되도록 일부러 통과시킵니다.

이어서 detect_anomalies 노드를 열어 봅니다. 스크립트 본문에 임계값 상수가 셋 있습니다.

• DEFAULT_SIGMA_MULTIPLIER = 3.0 — sensor_type 별 평균에서 |value − mean| / std 가 이 값을 넘으면 이상으로 플래그
• DEFAULT_HIGH_THRESHOLD = 5.0 — z-score 가 5.0 이상이거나 quality_flag 가 HIGH_* 면 HIGH
• DEFAULT_MEDIUM_THRESHOLD = 4.0 — z-score 가 4.0 이상이면 MEDIUM. 그 외 (3.0 ~ 4.0) 는 LOW

상단 Run 을 눌러 실행합니다. 끝나면 좌측 트리로 돌아가 anomaly_detections 의 미리 보기 탭을 엽니다. severity 컬럼 값이 LOW / MEDIUM / HIGH 셋 중 하나로 떨어져 있을 겁니다. row 한두 개를 골라 zscore 와 severity 가 위 임계값 규칙대로 맞는지 손으로 짚어 봅니다.

4. 일별 rollup + 스케줄 (15분)

이번 단계는 이상 로그를 유지보수 팀이 직접 읽지 않고 우선순위만 판단할 수 있는 형태로 압축합니다. processed 컬렉션의 파이프라인 섹션에서 equipment_health_rollup 을 클릭합니다. 노드는 하나, rollup_health 스크립트가 anomaly_detections 를 읽어 equipment_health 데이터셋을 만듭니다.

rollup_health 노드 스크립트 본문에서 핵심 계산식은 한 줄입니다.

health_score = clip( 100 − (high_severity × 10 + medium_severity × 4 + low_severity × 1), 0, 100 )

가중치 (10, 4, 1) 비율의 의미를 한 번 곱씹어 봅니다. HIGH 이상 한 건이 그 머신의 그날 점수에서 10점, MEDIUM 은 4점, LOW 는 1점을 깎습니다. HIGH 이상이 10건 이상 쌓이면 점수가 0으로 클리핑돼 긴급 점검 대상으로 표시됩니다.

Run 을 한 번 눌러 실행합니다. 끝나면 equipment_health 미리 보기에서 머신·일자 조합별로 health_score (0–100), anomaly_count, high_severity 컬럼이 채워졌는지 봅니다.

이제 이 파이프라인을 매일 1am 자동 실행 으로 등록합니다. 편집기 우상단의 파이프라인 설정 또는 스케줄 영역에서 다음 값을 잡습니다.

• 반복 단위: 매일 (daily)
• 시작 시각: 01:00 UTC
• 다음 실행: 1am 다음 도래 시각이 표시되는지 확인

저장하면 파이프라인 카드 헤더에 다음 자동 실행 시각이 뜹니다. 매뉴얼의 파이프라인 스케줄링 페이지가 이 설정 화면의 배경입니다.

5. 온톨로지 + 그래프 탐색 (15분)

마지막은 그래프 시점입니다. processed 컬렉션의 파이프라인 섹션에서 ontology_materialization 을 누릅니다. 노드는 하나, build_ontology_tables 스크립트가 machine_sensors + anomaly_detections + equipment_health 세 데이터셋을 batch 모드로 읽어 다음 5개 산출물을 upsert 모드로 적재합니다.

Run 을 한 번 눌러 실행합니다. 끝나면 좌측 사이드바의 온톨로지 영역으로 가서 엔티티 3종이 올라가 있는지 봅니다. IOT_Machine 카드를 누르고 빌더 탭에서 Backing dataset 가 machine_sensors 집계 결과로 잡혀 있는지, 식별 키가 machine_id 인지 확인합니다. 매뉴얼의 온톨로지 빌더 페이지가 매핑 화면을 정리해 둡니다.

이어서 그래프 탐색기를 엽니다. 두 경로를 손으로 펼쳐 봅니다.

첫 경로 — 머신에 어떤 센서가 붙어 있나
IOT_Machine (M-001) ── IOT_reads_from ── IOT_Sensor (M-001__vibration, M-001__temperature, M-001__pressure)

두 경로 — 한 머신에서 어떤 정비 이벤트가 트리거됐나
IOT_Machine (M-001) ── IOT_triggers ── IOT_MaintenanceEvent (ME-<anomaly_id>)

IOT_Machine 노드를 더블 클릭해 이웃을 펼치면 sensor_type 별로 IOT_Sensor 노드 3개가 한 번에 뜨고, 같은 머신에서 HIGH 심각도 이상이 한 건이라도 있었다면 IOT_MaintenanceEvent 노드가 함께 등장합니다. 12대 중 어떤 머신이 정비 이벤트를 많이 트리거하는지 그래프 시각으로 곧장 잡힙니다.

6. (선택) 코드 노드 깊이 보기 (10분)

여기까지가 핵심 경로입니다. 시간이 남으면 §3 의 anomaly_detection.py 를 다시 열어 임계값을 살짝 만져 보고, 결과가 어떻게 움직이는지 관찰해 봅니다.

detect_anomalies 노드의 스크립트 미리 보기에서 DEFAULT_SIGMA_MULTIPLIER = 3.0 을 3.15 로 (약 5% 증가) 바꾸고 저장한 뒤 다시 Run 합니다. 임계값이 살짝 빡빡해진 셈이라 z-score 가 3.0 ~ 3.15 사이의 경계선 위에 있던 row 들이 이상에서 빠집니다.

anomaly_detections 미리 보기로 돌아가 확인할 변화는 셋입니다.

• 전체 이상 건수가 줄어듭니다. HIGH_* 상태 신호 row 는 z-score 와 무관하게 보존되므로, 줄어드는 폭은 경계선의 LOW · MEDIUM 에 몰립니다.
• HIGH 비율 은 거의 그대로입니다. 5.0 이상은 5% 증가에 흔들리지 않습니다.
• LOW 가 MEDIUM 으로 바뀌거나 그 반대 는 일어나지 않습니다. 임계값 셋 모두 Z-score 의 절대 컷오프 고, LOW/MEDIUM/HIGH 구분 컷오프 (4.0, 5.0) 는 건드리지 않았기 때문입니다.

정확한 숫자는 학습자가 적재한 row 양에 따라 달라집니다. 이 단계의 목적은 얼마나 줄어드는가가 아니라 임계값 조정이 어느 결과 차원에 영향을 주는가를 손으로 느끼는 데 있습니다.

실험이 끝나면 임계값을 원래 3.0 으로 돌려놓고 한 번 더 실행해 결과 분포를 baseline 으로 복구합니다. 이 사이클이 엔지니어 코스의 코드 노드 레슨에서 익힌 읽기·수정·재실행의 한 turn 입니다.

7. 다음 단계 + 회고 (5분)

여기까지 왔다면 한 시나리오 위에서 다음 다섯 흐름을 한 번씩 통과한 셈입니다.

• 시나리오 적재 → raw 와 processed sub-collection 분기
• 코드 노드 본문 spot-check → 3-시그마 임계값 + HIGH_* 상태 신호 보존
• 파이프라인 실행 → 심각도 분포 확인
• 일별 rollup + 매일 1am 자동 스케줄 등록
• 온톨로지 평탄화 → 그래프 탐색기에서 머신·센서·정비 이벤트 경로 시각화

끌리는 방향으로 한 발 더 들어갑니다.

• 분석가 코스의 첫 대시보드 레슨으로 가서, 이 워크숍이 적재한 equipment_health 대시보드를 분석가 시점으로 다시 봅니다. 같은 데이터셋이 위젯 SQL 쿼리 모드와 그래프 시점에서 어떻게 다르게 그려지는지 비교해 봐도 좋습니다.
• 엔지니어 코스의 파이프라인 스케줄링 레슨으로 가서, §4 에서 손으로 잡은 매일 1am 등록이 어떻게 일반화되는지 (cron 표현식, owner, after-dependency) 파고듭니다.
• 자기 도메인 시나리오를 dhub2-examples/scenarios/ 에 추가합니다. 이 워크숍의 흐름 — 원시 텔레메트리 컬렉션 → 정규화 + 감지 파이프라인 → 일별 rollup → 온톨로지 평탄화 — 은 다른 제조 라인이나 인프라 텔레메트리에도 거의 그대로 형판처럼 들어맞습니다.

엔지니어 시점으로 한 사이클을 통과한 학습자는 dhub2-examples 의 한 시나리오가 포털 안에서 살아 움직이는 자원으로 풀리는 흐름을 IIoT 도메인 위에서 직접 거친 셈입니다. 분석가 워크숍 (retail-inventory-intelligence) 이 위젯과 그래프 라는 분석가 시점으로 같은 형판을 통과시켰다는 점을 떠올리면, 형판은 하나, 시점은 둘 이라는 구조가 머리에 자리 잡습니다.

검증 체크리스트

워크숍이 끝났는지는 다음 5가지로 자가 점검합니다.

• 컬렉션 트리에 raw 와 processed 두 컬렉션이 다 보이고, machine_sensors 가 raw 에, anomaly_detections · equipment_health 가 processed 에 떨어져 있는지
• anomaly_detection 파이프라인 1회 실행 뒤 anomaly_detections 미리 보기에서 severity 값이 LOW / MEDIUM / HIGH 세 라벨로 분포돼 있는지
• equipment_health_rollup 파이프라인 카드 헤더에 다음 실행이 다음 1am UTC 로 떠 있는지 (즉 스케줄 등록이 실제로 저장됐는지)
• 그래프 탐색기에서 IOT_Machine 노드 하나를 시작점으로 이웃을 펼쳤을 때 IOT_Sensor 노드 3개가 뜨고, HIGH 이상이 한 건이라도 있었다면 IOT_MaintenanceEvent 노드가 함께 나타나는지
• (선택 §6 을 했다면) 임계값을 3.0 으로 되돌리고 재실행한 결과 분포가 §3 단계의 baseline 과 같은지