원격 설비 데이터 대시보드에서 운영 기준을 세우는 방법

먼저 결론부터 볼게요

원격 설비를 관리할 때 화면에 현재값 하나만 띄우면 운영이 끝난 것처럼 보이지만, 실제로는 그렇지 않아요. 지금 값이 얼마인지와 함께 언제 마지막으로 들어왔는지, 외부 전달이 정상인지, 지난 시간의 흐름이 어땠는지를 같이 봐야 다음 조치를 정할 수 있어요.

이번 글에서는 원격 현장의 온도·압력·운전 상태처럼 주기적으로 읽는 값을 한곳에서 확인하는 흐름을 예로 들게요. 현장 장치와 PLC에서 값을 읽고, 수집 계층에서 저장과 전달을 정리한 뒤, 운영 대시보드에서 현재값·마지막 수신 시각·전달 상태·이력을 함께 확인하는 방식이에요. 실제 PLC 주소와 단위는 장비 매뉴얼과 현장 필드 주소 맵을 기준으로 맞춰야 하며, 아래 이름과 값은 그 맵에 대조하기 위한 예시예요.

원격 데이터에서 먼저 정리할 네 가지

첫째는 현재값이에요. 예를 들어 원격 펌프의 토출 압력이나 제어반 내부 온도를 보여줄 수 있어요. 둘째는 마지막 수신 시각이에요. 화면의 값이 오래된 것인지 방금 들어온 것인지 구분해야 해요. 셋째는 전달 상태예요. MQTT, HTTP API, DB 같은 외부 경로를 쓰더라도 수집 상태와 전달 상태를 섞어 해석하면 안 돼요. 넷째는 이력이에요. 현재값이 정상이어도 추세가 계속 올라가는지, 통신이 끊긴 구간이 있었는지 확인해야 해요.

이 네 항목은 대시보드 카드와 추세 그래프를 나누어 구성하면 이해하기 쉬워요. 카드에는 현재값·단위·품질·마지막 수신 시각을 두고, 별도 상태 영역에는 전달 상태를 표시해요. 아래 그래프에는 시간 범위를 선택해 이력을 확인하도록 구성하면 원격지에 직접 가지 않고도 우선 점검할 범위를 좁힐 수 있어요.

EASY-LINK와 EASY LOGGER의 역할을 나눠요

현장 장치 한두 대의 값을 읽어 정해진 대상으로 보내는 것이 목적이라면 EASY-LINK만으로 시작할 수 있어요. EASY-LINK는 LS XGT, Mitsubishi MC, Modbus RTU/TCP 장비 데이터를 MQTT, HTTP API, MySQL, Firebase로 전송하는 게이트웨이 역할을 해요. 센서나 PLC의 실제 레지스터 정의와 단위는 장비 문서에서 확인하고, EASY-LINK에는 그 주소와 전달 대상을 맞춰 등록하는 흐름이에요.

주 전달 대상을 엣지 서버로 두는 이유는 여러 원격지의 값을 운영 화면과 이력으로 모으기 위해서예요. MQTT는 실시간 이벤트 전달에 유리하고, HTTP API는 요청·응답 중심의 상위 시스템 연계에 맞아요. MySQL은 외부 스키마에 이력을 적재하거나 조회할 때 적합하고, Firebase는 모바일·웹 중심의 빠른 동기화가 필요할 때 검토할 수 있어요. 이번 예시처럼 운영자가 현재값·마지막 수신 시각·전달 상태·이력을 한 화면에서 확인해야 한다면 edge-server를 주 전달 대상으로 두고, MQTT·HTTP API·MySQL·Firebase는 필요한 소비처에 맞춰 선택하는 편이 좋아요. 이 비교는 검증된 연계 형태를 기준으로 한 선택이며, 실제 endpoint·스키마·인증 방식은 대상 시스템 문서와 현장 주소 맵을 대조해야 해요.

반대로 여러 원격지의 값을 모아 저장하고, 대시보드와 외부 전달 상태, 이력을 한 운영 화면에서 관리하려면 EASY LOGGER가 더 잘 맞아요. EASY LOGGER는 PLC 데이터를 수집·저장하고 DB·MQTT·API·OPC-UA와 대시보드로 확장하는 데이터 허브 역할을 해요. 현장 연결 자체가 필요한 구간은 EASY-LINK가 맡고, 통합 운영과 이력 확인이 필요한 구간은 EASY LOGGER가 맡는다고 생각하면 구분이 쉬워요.

필드 주소 맵으로 확인한 값은 수집 계층에서 저장과 전달 경로를 분리해 관리하는 편이 좋아요.

EASY LOGGER 대시보드 예제

원격 펌프장의 예시를 들어볼게요. 필드 주소 맵에서 discharge_pressure가 PLC의 예시 주소 D0100에 연결되고, panel_temperature가 D0102에 연결되어 있다고 가정해요. 이 주소와 데이터 타입·단위·스케일은 실제 장비 매뉴얼과 현장 맵에서 대조한 뒤 사용해야 해요. 값이 EASY LOGGER로 들어오면 대시보드의 압력 카드와 온도 카드에 현재값을 보여주고, 각 카드 아래에 마지막 수신 시각과 품질 상태를 표시해요.

여기서 중요한 것은 화면 값만 믿지 않는 거예요. Dashboard에서 현재값을 확인한 다음, 같은 설정의 마지막 수신 시각이 최근으로 갱신되는지 봐야 해요. 외부 전달을 켰다면 delivery state를 별도 영역에서 확인하고, 이력 그래프에서 통신 공백과 값의 급격한 변화를 함께 살펴봐요. 현재값은 정상인데 마지막 수신 시각이 오래됐다면 설비 이상보다 통신 또는 수집 상태를 먼저 의심할 수 있어요.

필드 주소 맵의 신호명 discharge_pressure와 panel_temperature를 위젯 필드로 그대로 연결하면, 압력 위젯의 current value는 D0100의 스케일 적용값, 온도 위젯의 current value는 D0102의 단위 적용값으로 근거를 남길 수 있어요. 각 위젯에는 last reception time을 함께 표시하고, delivery state는 수집 상태와 분리해 보여 주세요. 같은 위젯의 history 그래프에서는 시간 범위와 통신 공백을 확인해야 하므로 Dashboard의 네 근거가 한 화면에서 이어져야 해요.

수집 주소와 대시보드 항목의 이름을 다르게 만들면 나중에 원인을 찾기 어려워져요. D0100을 임의로 다른 센서 이름으로 바꾸기보다, 필드 주소 맵의 신호명과 단위를 유지하고 대시보드에서는 사람이 읽기 쉬운 표시명을 추가하는 방식이 좋아요. 이 원칙은 여러 원격지를 합칠 때도 같은 값의 의미를 보존해 줘요.

대시보드가 보여줘야 할 운영 흐름

대시보드의 첫 화면에는 현재값만 크게 배치하지 말고, 현재값·마지막 수신 시각·전달 상태·이력을 서로 가까이 배치해 보세요. 예를 들어 압력 카드가 정상 색상이어도 마지막 수신이 오래됐다면 ‘정상 압력’으로 단정하지 않고 ‘오래된 수신값’으로 분류해야 해요. 전달 상태가 대기나 오류라면 수집은 정상인지, 외부 경로만 문제가 있는지 분리해 볼 수 있어요.

단계별로 도입하면 무엇이 달라질까요?

1단계는 한 원격지에서 주소와 단위를 맞추고 현재값·마지막 수신 시각을 확인하는 단계예요. 2단계는 여러 장치의 값을 같은 화면에 모으고 전달 상태와 이력을 함께 확인하는 단계예요. 3단계는 외부 서버나 상위 시스템으로 전달하면서 대시보드와 DB History를 기준 화면으로 삼는 단계예요. 단계가 올라갈수록 값의 개수보다 이름, 단위, 시간 기준, 장애 분류를 먼저 통일해야 해요.

한 지점의 수신 검증에서 여러 지점의 통합 이력과 대시보드 운영으로 범위를 넓히는 흐름을 보여줘요.

현장 적용 전에 확인할 체크리스트

• 필드 주소 맵의 신호명, PLC 주소, 데이터 타입, 단위, 스케일이 일치하는지 확인해요.
• Dashboard의 현재값과 마지막 수신 시각이 함께 갱신되는지 확인해요.
• 전달 상태가 수집 상태와 별도로 보이는지 확인해요.
• DB History에서 같은 신호의 시간 순서와 통신 공백을 조회해요.
• 외부 시스템을 연결한다면 수신 측의 스키마와 중복 처리 기준을 먼저 맞춰요.
• 쓰기나 원격 제어가 필요한 경우에는 테스트 주소만 사용하고 최소 권한과 허용 범위를 정한 뒤 PLC 인터록과 수동 복구 절차를 확인해요.

현장 연결 가능 여부와 필요한 운영 화면을 먼저 가볍게 확인해 보세요. 한 지점의 대표 신호로 주소·단위·수신 시각을 맞춘 다음, EASY-LINK와 EASY LOGGER 중 어느 계층이 필요한지 결정하면 됩니다.