Edge 컴퓨팅
VEXPLOR에서 현장 설비와 플랫폼을 연결하는 일은 Edge 게이트웨이가 맡습니다. 설비·센서를 디바이스로 등록하고 산업용 프로토콜(OPC-UA, MQTT, Modbus, HTTP)로 연결하면, 게이트웨이가 데이터를 받아 알람 규칙을 판정하고, 가벼운 이상 감지 모델로 바로 걸러 보고, 필요하면 업무 테이블에 저장하고, 3D 디지털 트윈 화면으로 실시간 전달합니다.
무엇인가
공장 설비는 저마다 다른 말을 사용합니다. PLC는 OPC-UA로, 센서 게이트웨이는 MQTT로, 오래된 장비는 Modbus로 데이터를 내보냅니다. 업무 시스템이 이 모든 프로토콜을 직접 다루면 복잡해지고, 설비 하나가 추가될 때마다 개발이 필요해집니다.
Edge 게이트웨이는 그 사이에서 통역사 역할을 합니다. 프로토콜이 무엇이든 받아들여 VEXPLOR가 이해하는 공통 형식으로 바꾸고, 그 데이터를 알람·분석·저장·시각화로 보냅니다. 다른 서비스와 마찬가지로 모든 디바이스와 데이터는 테넌트별로 분리됩니다.
구성 요소
| 구성 요소 | 하는 일 |
|---|---|
| 디바이스 등록부 | 설비·센서의 이름, 프로토콜, 연결 설정, 태그, 연결 상태, 마지막 통신 시각을 관리합니다. |
| 프로토콜 연결기 | OPC-UA, MQTT, Modbus, HTTP 방식으로 설비에 연결합니다. |
| 수집 스케줄러 | 정해진 주기마다 값을 읽어 오거나(폴링), 설비가 값을 보낼 때 곧바로 받습니다(구독). |
| 알람 판정 | 들어온 값을 알람 규칙과 비교하고, 조건에 맞으면 알림 서비스로 알립니다. |
| 현장 이상 감지 | 통계 기반 모델과 등록된 모델 파일로 값이 평소와 다른지 바로 판정합 니다. |
| 테이블 적재 | 수집한 값을 배포된 업무 테이블에 저장합니다. |
| 디지털 트윈 스트림 | 수집한 값을 3D 디지털 트윈 화면에 실시간으로 보냅니다. |
| OT 보안 | 디바이스 인증서 정보 관리, 접근 기록, 과도한 요청 제한을 담당합니다. |
데이터가 흐르는 순서
- 연결 -- 등록된 디바이스에 연결을 요청하면 게이트웨이가 프로토콜에 맞는 방식으로 접속하고 상태를 「연결됨」으로 바꿉니다. 실패하면 「오류」로 표시됩니다.
- 수집 -- 수집 규칙에 따라 값을 가져옵니다.
- 폴링: 정해진 주기마다 값을 읽습니다. 모든 프로토콜에 사용할 수 있습니다.
- 구독: MQTT와 OPC-UA는 설비가 값을 보낼 때 곧바로 받습니다. 구독을 지원하지 않는 경우에는 폴링으로 대신합니다.
- 판정 -- 들어온 값마다 알람 규칙을 확인합니다. 기준값을 넘는지(임계값), 정해진 범위를 벗어나는지(범위), 값이 급하게 바뀌었는지(변화), 여러 값을 조합한 조건식을 만족하는지(조건식)를 봅니다. 조건식은 안전하게 계산되는 범위 안에서만 해석됩니다.
- 저장 -- 센서 값은 시계열 데이터로 저장되고, 수집기에 대상 테이블이 지정되어 있으면 배포된 업무 테이블에도 저장됩니다. 이때 태그 이름과 같은 이름의 컬럼에 값이 자동으로 들어갑니다. 맞는 컬럼이 없는 태그는 건너뛰고 기록을 남깁니다.
- 전달 -- 3D 디지털 트윈 화면이 연결되어 있으면, 화면이 감당할 수 있는 빈도로 값을 줄여 실시간으로 보냅니다.
테이블 적재나 디지털 트윈 전달이 실패해도 센서 값 저장은 계속됩니다. 부가 기능의 문제가 핵심 데이터 수집을 멈추지 않도록 서로 분리해 두었습니다.
캔버스와의 관계 -- IoT 노드
현장 연결도 캔버스에서 설계할 수 있습니다. 캔버스의 IoT 노드는 Edge 게이트웨이의 구성 요소와 하나씩 대응합니다.
| IoT 노드 | 게이트웨이에서 만들어지는 것 |
|---|---|
| 데이터 소스 | 연결할 설비와 프로토콜 |
| 데이터 수집기 | 수집 주기·방식과 저장할 테이블 |
| 알람 규칙 | 알람 조건과 심각도 |
| 디지털 트윈 출력 | 3D 화면으로 보낼 값과 매핑 |
캔버스를 배포하면 배포 파이프라인이 이 노드들을 게이트웨이에 등록합니다. 설계와 운영 설정이 같은 캔버스에 있으므로, 「이 센서 값이 어느 테이블에 쌓이고 어떤 알람을 울리는가」를 한 화면에서 확인할 수 있 습니다.
현장 이상 감지 모델
Edge 게이트웨이는 무거운 AI 분석에 앞서 가벼운 모델로 값을 먼저 걸러 봅니다.
| 모델 | 판정 방식 |
|---|---|
| Z-점수 | 평균에서 표준편차 몇 배 이상 벗어났는가 |
| IQR | 사분위 범위를 벗어난 극단값인가 |
| EMA | 최근 값에 더 큰 비중을 둔 이동 평균과 비교해 추세가 오르는가·내리는가 |
| 모델 파일 (ONNX) | 미리 학습시켜 등록한 모델로 판정 |
모델마다 판정 횟수와 이상 비율이 집계되어 모델이 너무 자주 또는 너무 드물게 경보를 내는지 확인할 수 있습니다.
디바이스 관리 화면
Edge 관리 → 디바이스 목록에서 다음을 할 수 있습니다.
- 디바이스 등록: 디바이스 이름(예: CNC-01), 프로토콜, 연결 설정(JSON)을 입력합니다.
- 목록 확인: 프로토콜별 탭으로 걸러 보고, 이름으로 검색합니다. 상태는 연결됨·연결 끊김·오류·미등록으로 표시되고, 마지막 통신 시각이 「n분 전」처럼 표시됩니다.
- 연결·연결 해제: 목록에서 바로 연결하거나 끊습니다.
- 상세 보기: 디 바이스 정보, 인증서 정보(발급자·유효기간·지문), 최근 데이터 포인트와 최솟값·최댓값, 명령 이력, 이벤트를 확인합니다.
- 삭제: 더 이상 사용하지 않는 디바이스를 삭제합니다.
왜 이렇게 설계했나
- 프로토콜을 게이트웨이에 모은 이유: 업무 서비스는 프로토콜을 몰라도 됩니다. 새 설비가 추가되어도 게이트웨이에 디바이스를 등록하는 것으로 끝납니다.
- 가벼운 판정을 먼저 하는 이유: 모든 값을 무거운 AI 분석으로 보내면 느리고 비용이 큽니다. 명백한 이상은 들어오는 즉시 걸러 내고, 깊은 분석은 AI 서비스가 맡습니다.
- 부가 기능을 분리한 이유: 3D 화면이나 테이블 적재에 문제가 생겨도 센서 데이터 자체는 빠짐없이 쌓여야 하기 때문입니다.
실무 팁
수집한 값을 업무 테이블에 바 로 저장하려면 설비 태그 이름과 테이블 컬럼 이름을 같게 설계하세요. 이름이 다르면 그 값은 테이블에 들어가지 않습니다.
MQTT·OPC-UA 설비는 구독 방식을 사용하면 값이 바뀌는 즉시 들어오고, 불필요한 반복 조회도 줄어듭니다.
데이터가 안 들어온다면 디바이스 목록에서 상태와 마지막 통신 시각부터 확인하세요. 「연결됨」인데 마지막 통신이 오래전이면 설비 쪽 송신 설정을 점검합니다.
관련 문서
- Edge 게이트웨이 -- 기능 화면 안내
- IoT 노드 -- 캔버스에서 현장 연결 설계하 기
- 이상 감지 -- AI 서비스의 이상 감지
- AI/ML 통합 -- 수집 데이터를 사용하는 AI 구조
- 배포 파이프라인 -- IoT 노드가 등록되는 시점