기술 인사이트 · 에이드소프트 Edge 연동
장비가 보내는 값을 운영자가 쓸 수 있는 정보로 바꾸는 것. 에이드소프트의 Edge 연동은 여기서 출발합니다. 현장 장비와 통신을 연결하고, 장비별 데이터 형식을 해석한 뒤, 저장과 조회를 거쳐 웹 관제에서 상태와 이력을 확인하는 흐름을 구축합니다.
에이드소프트의 LincoreAI에서는 Rust 기반 TCP 수집기와 MQTT 연계, 장비 데이터 파싱, QuestDB 시계열 기록, 웹 관제를 구성했습니다. 이 글은 해당 구성에서 에이드소프트가 장비 연결과 데이터 처리를 어떻게 나누고, 현장 조건에 맞춰 어떤 부분을 확인하는지 설명합니다.
에이드소프트가 Edge 연동을 구성하는 순서
연동의 기준은 기술 이름보다 장비가 실제로 보내는 데이터와 운영자가 확인해야 할 업무입니다. 연결 단계에서 받은 원문을 곧바로 화면에 표시하는 대신, 장비 식별·형식 해석·값 검증·기록·조회 단계를 나눠 구성합니다.
- 장비의 통신 조건을 확인합니다. 프로토콜과 메시지 경계, 수신 주기, 연결 식별 정보를 기준으로 수집 방식을 정합니다. TCP 장비와 MQTT 장비는 서로 다른 수집 경로로 연결할 수 있습니다.
- Edge에서 연결과 수신을 관리합니다. Rust 수집기가 TCP 세션과 수신 크기, 연결 생명주기를 다루고, 수신·전달·저장 문제를 각각 확인할 수 있도록 모듈과 로그를 분리합니다.
- 장비별 데이터 계약을 적용합니다. 필드 수와 숫자 형식을 검증하고, 기종별 측정 항목과 단위에 맞춰 해석합니다. 새로운 장비는 프로토콜과 값의 의미를 확인해 어댑터에 반영합니다.
- 필요한 기록을 저장하고 관제로 연결합니다. 원문, 정규화 샘플 또는 상태 구간을 목적에 맞춰 기록합니다. API는 이를 장비·현장 정보와 연결하고, 웹 화면은 최신 상태와 시간별 변화를 보여줍니다.
- 현장 조건에서 연동을 검증합니다. 분할 수신과 여러 메시지의 동시 도착, 연결 단절과 재접속, 저장 지연을 확인할 항목에 포함합니다. 데이터 보관 범위와 장애 복구 요구에 따라 확장 구성을 설계합니다.
현장 장비 → Edge 수집·파싱 → 전달·시계열 저장 → 조회 API → 웹 관제
장비마다 다른 통신과 데이터 의미를 수집 계층에서 정리하고, 운영자가 같은 기준으로 상태와 이력을 확인하도록 연결합니다.
현장 연결부터 모니터링까지
에이드소프트가 구성한 현재 수집 구조의 중심은 Rust Edge입니다. TCP로 들어오는 장비 데이터를 받아 지원하는 형식으로 파싱한 뒤, MQTT로 전달하거나 QuestDB에 상태 구간을 기록할 수 있습니다. MQTT 데이터를 받아 원문과 정규화 값을 저장하는 별도 수집 경로도 구성돼 있습니다.
다음 흐름표는 에이드소프트의 현재 구현 경로와 확장 설계를 구분합니다. 현장의 장비와 네트워크 조건에 따라 필요한 경로를 선택합니다.
TCP 연결 장비 → Rust Edge (연결 관리·데이터 수신) → 지원 형식 파싱 (필드 검증·장비 식별) → 상태 구간 집계 (배치 기록·재시도) → QuestDB
Rust Edge 또는 MQTT 지원 장비 → MQTT 브로커 → MQTT 수집기 (원문 보관·정규화) → QuestDB
QuestDB → 조회 API (최신 상태·시간대별 집계) → 웹 관제 (장비 상태·지도·추이)
BACnet 설비 ⇢ 프로토콜 어댑터 ⇢ 지원 형식 파싱
파싱 ⇢ Kafka 전달 계층 ⇢ 저장 작업자 (중복 처리·저장 확인) ⇢ QuestDB
저장 작업자 ⇢ WebSocket 이벤트 배포 ⇢ 웹 관제
MQTT 브로커는 장비와 수집기 사이의 메시지 전달을 담당하고, Kafka는 도입 시 서버 처리 과정의 기록·재처리·부하 분리를 담당합니다. 두 구성요소의 역할은 서로 다릅니다. 모든 현장에 같은 구성을 설치하기보다, 데이터량과 장애 복구 요구에 맞춰 전달 계층을 선택합니다.
Rust Edge로 장비 연결을 관리합니다
Edge는 장비와 가장 가까운 곳에서 연결 상태와 수신 데이터를 다룹니다. LincoreAI의 Rust 수집기는 TCP 세션 관리, 수신 크기 제한, 연결 생명주기, 상태 조회 API와 로그를 분리해 구성했습니다. MQTT 전달과 QuestDB 기록도 별도 모듈로 나눠, 수신·전달·저장 단계의 문제를 각각 확인할 수 있도록 했습니다.
Rust의 메모리 안전성과 명시적인 오류 처리를 활용하는 목적은 장시간 실행되는 현장 프로그램을 다루기 쉽게 만드는 데 있습니다. 운영 안정성은 언어 선택과 함께 큐의 크기, 재시도 정책, 프로세스 종료와 복구 동작을 설계하면서 확보해야 합니다.
TCP는 바이트 스트림이므로 한 번의 수신이 항상 장비 메시지 한 개와 같지는 않습니다. 장비별 연동 과정에서는 메시지 경계, 분할 수신, 여러 메시지가 함께 도착하는 상황까지 확인해야 합니다. 프로토콜에 맞는 프레임 처리와 실제 장비 시험을 연결 기준에 포함합니다.
파싱 엔진이 원시값을 업무 데이터로 바꿉니다
관제 화면이 장비별 원문을 직접 해석하면 새 장비가 추가될 때마다 화면과 저장 구조를 함께 수정해야 합니다. 수집 계층에서 형식 해석과 필드 검증을 맡으면 이후 저장·조회 계층은 일정한 계약을 기준으로 동작할 수 있습니다.
현재 Rust Edge는 정수 8개로 구성된 CSV와 IP 정보가 포함된 지원 형식을 처리합니다. 수신 주소와 메시지의 장비 식별 정보를 함께 사용하며, MQTT 원시 메시지에는 수신 시각·원문·해시 등 추적에 필요한 정보가 포함됩니다. 별도 MQTT 수집기는 원문과 파싱 결과를 나눠 저장합니다.
| 처리 단계 | 역할 |
|---|---|
| 장비 식별 | 메시지와 연결 정보를 이용해 데이터의 출처 구분 |
| 형식 해석 | 지원하는 프레임의 필드 분리와 값 변환 |
| 필드 검증 | 필요한 필드 수와 숫자 형식 확인 |
| 의미 부여 | 기종별 단위·측정 항목·상태 판단 규칙 연결 |
| 기록 추적 | 원문·수신 시각·파싱 결과를 연결해 문제 분석 |
여기서 자동 파싱은 미리 정의한 장비 계약을 반복적으로 처리하는 기능입니다. 신규 기종은 프로토콜, 필드 의미와 단위를 확인해 어댑터에 반영해야 합니다. 원시 정수를 온도·습도·전류로 사용할 때도 기종별 변환 규칙이 필요합니다.
BACnet 설비를 연결하는 확장에서는 수신 값 또는 읽어 온 객체의 식별자, 속성, 단위를 공통 데이터 계약에 매핑하는 어댑터를 두는 방향으로 설계합니다. 프로토콜별 연결 방식이 달라도 저장·모니터링 계층이 일관되게 데이터를 다루도록 하는 것이 목표입니다.
장애를 고려한 전달과 저장
현재 수집 코드에는 MQTT 재접속, 지수형 재시도 간격, 유한 큐, QuestDB 배치 기록과 재시도 처리가 있습니다. 반복되는 장애에서 계속 즉시 요청을 보내는 대신 대기 시간을 늘리고, 처리량과 대기량을 관리하는 구조입니다.
다만 메모리 큐와 재시도만으로 전원 장애나 장시간 단절까지 무손실 처리를 보장할 수는 없습니다. 데이터 누락을 줄이는 확장에서는 Edge의 디스크 버퍼와 Kafka의 전달 기록, 저장 작업자의 중복 처리 및 완료 확인을 함께 연결합니다.
수신 데이터 → Edge 디스크 버퍼 → Kafka 기록·복제 → 소비자 파싱·검증
- 처리 가능한 데이터: 안정적인 이벤트 식별자로 중복 처리하며 시계열 DB에 저장합니다.
- DB 저장 성공: 처리 위치를 확정하고 확인된 범위의 보관 데이터를 정리합니다.
- DB 저장 실패: 재시도하거나 보류합니다.
- 파싱·검증 실패: 별도 보관하고 원인을 수정한 뒤 재처리합니다.
이 순서도는 누락 방지를 강화하기 위한 확장 설계입니다. Edge 버퍼는 Kafka가 정해진 내구성 정책에 따라 수락한 범위부터 정리하고, 소비자의 처리 위치는 DB 저장 성공을 확인한 뒤 확정합니다. 재처리 과정의 중복에는 안정적인 이벤트 식별자와 저장 계층의 중복 처리 규칙이 필요합니다.
MQTT QoS 1은 최소 한 번 전달하는 방식이어서 중복이 발생할 수 있습니다. Kafka에서도 외부 DB까지 한 번만 반영되는 결과를 얻으려면 저장 계층과 처리 위치의 관계를 설계해야 합니다. 브로커를 설치하는 것과 장비에서 DB까지의 누락·중복 정책을 완성하는 것은 별도 작업입니다. MQTT 공식 규격, Apache Kafka 전달 의미.
시계열 DB로 현재 상태와 이력을 연결합니다
장비 관제에는 최근 상태와 과거 이력이 모두 필요합니다. 현재 연결돼 있는지, 같은 상태가 얼마나 지속됐는지, 특정 시간대에 어떤 변화가 있었는지를 함께 보여줘야 합니다.
LincoreAI는 QuestDB를 이용해 시간 기준 데이터를 저장·조회합니다. 수집 경로에 따라 원문과 정규화 샘플을 보관하거나, 동일한 장비 값이 이어지는 구간을 시작 시각·종료 시각·샘플 수로 묶어 기록할 수 있습니다. 상태 구간 기록은 반복 값의 저장 부담을 줄이는 방식이며, 모든 원시 샘플 보관이 필요한 경우에는 원시 저장 경로를 별도로 유지해야 합니다.
| 데이터 계층 | 사용 목적 |
|---|---|
| 원시 메시지 | 장비 연동·파싱 문제를 추적하고 재해석 |
| 정규화 샘플 | 장비별 측정 값과 시간 변화 조회 |
| 상태 구간 | 같은 상태가 유지된 시간과 변화 지점 분석 |
| 업무 데이터 | 장비·현장·사용자·점검·A/S 관계 관리 |
API는 시계열 정보를 장비·현장 정보와 연결해 최신 상태, 기간별 추이와 집계를 제공합니다. 웹 관제에서는 지도와 상태 카드, 추이 화면을 통해 운영자가 확인해야 할 장비를 찾을 수 있습니다.
WebSocket으로 확장하는 화면 갱신
현재 관제 화면은 HTTP 주기 조회로 최신 데이터를 갱신합니다. 다음 확장에서는 저장 완료 또는 상태 변화 이벤트를 WebSocket 게이트웨이로 전달해 변경된 장비의 정보만 화면에 반영하는 구조를 검토합니다.
화면 갱신과 데이터 보관은 분리합니다. 사용자가 브라우저를 닫아도 수집·저장은 계속되고, 다시 연결한 화면은 API에서 최신 상태를 가져온 다음 새로운 이벤트를 받습니다.
- 최초 연결·재접속: 관제 화면 → 조회 API → 시계열 DB에서 장비 상태·이력 조회
- 조회 결과: 시계열 DB → API → 관제 화면의 기준 상태 반영
- 이벤트 구독: 권한이 허용된 장비의 이벤트를 WebSocket 게이트웨이에 구독
- 상태 변화: 게이트웨이 → 관제 화면으로 이벤트 전달
- 누락 감지·재접속: API에서 최신 상태 재조회
실제 푸시 도입에서는 초기 조회와 구독 사이의 변화가 빠지지 않도록 이벤트 순번이나 기준 시각을 연결해야 합니다. 클라이언트의 재접속, 느린 구독자 처리, 현장별 접근 권한도 함께 다룹니다. 운영 화면이 MQTT 브로커나 Kafka에 직접 연결하지 않도록 서버가 조회·구독 범위를 관리하는 구조입니다.
연결부터 운영까지 이어지는 기술
LincoreAI의 기술 방향은 장비 데이터를 받는 단계에서 시작해 파싱·전달·저장·관제까지 하나의 흐름으로 연결하는 것입니다. 장비별 통신 차이는 수집 계층에서 다루고, 데이터 의미는 파싱 계약에서 정하며, 장애 복구와 이력 조회는 저장·전달 계층에서 맡습니다.
현재 구현한 Rust TCP 수집과 MQTT 연계, 시계열 기록·집계, 웹 관제를 바탕으로 현장 요구에 맞는 어댑터와 전달 구조를 확장해 나갑니다. 회사가 제공하는 가치는 각 구성요소의 설치를 넘어, 특정 장비와 네트워크 환경에서 이 흐름이 함께 동작하도록 연동하고 검증하는 데 있습니다.
사용 중인 장비의 통신 규격, 데이터 샘플, 수집 주기와 관제에서 확인할 업무를 알려주세요. 에이드소프트는 장비·센서 연동과 데이터 처리, 웹 관제를 현장의 운영 방식에 맞춰 구성합니다.
에이드소프트 도입 상담 →