EMS Builder 전체 아키텍처, 실행 모드 및 기능 범위

Edge-EMS Builder는 현장 장치와 상위 시스템 사이에서 엣지 자율 운영을 기반으로 작동하며, 클라우드와 엣지의 협업 및 다중 노드 협업으로 확장할 수 있습니다. “데이터 읽기, 상태 계산, 규칙 판단, 동작 실행”을 지속적으로 실행되는 폐루프 제어로 구성합니다.

이 문서는 네 가지 질문에 답합니다.

1. Edge-EMS Builder의 전체 아키텍처는 어떻게 계층화되어 있나요?
2. 어떤 실행 모드를 사용할 수 있나요?
3. 업무 요구 사항을 어떻게 조합하여 구현하나요?
4. 유선, 무선 및 사이트 간 연결을 어디까지 확장할 수 있나요?

이 문서의 “실행 모드”는 시스템의 작동 방식이며 상업적 협력 방식이 아닙니다. Platform, Solution, Co-create의 세 가지 협력 방식은 Edge-EMS Builder 서비스 모델을 참조하세요.

1. 전체 아키텍처: 현장, 엣지 및 클라우드의 폐루프 구성

Edge-EMS Builder는 엣지에서 실행됩니다. CommBridge가 현장 프로토콜 차이를 추상화하고, MQTT, WebSocket 및 HTTP가 클라우드, 프런트엔드 및 외부 시스템을 연결합니다.

계층	핵심 역할	대표 대상 / 경로
업무 및 클라우드 계층	통합 모니터링, 원격 설정, 전략 전달, 운영 분석 및 외부 업무 통합	JelinaCloud, 고객 클라우드 플랫폼, SCADA, 급전 시스템, MQTT / HTTP
상호작용 및 통합 계층	프런트엔드에 실시간 데이터 전송, 제어 명령 수신 및 외부 시스템에 읽기/쓰기 기능 제공	사용자 정의 Web 프런트엔드, 백엔드 서비스, WebSocket / HTTP
EMS Builder 엣지 엔진	데이터 통합, 실시간 계산, 전략 판단, 동작 실행, 알람, 공유 및 설정 확장	데이터 모델, 표현식 엔진, 트리거 구성, 공유 대상, UDE
CommBridge 수집 계층	하위 프로토콜을 지원하고 현장 데이터 포인트를 EMS Builder가 인식하는 데이터로 변환	Modbus, OPC UA, S7, 시리얼 포트, IEC 101/104, CAN 등
현장 장치 계층	실시간 데이터 제공 및 최종 제어 실행	PCS, BMS, 전력량계, 충전기, 태양광 인버터, 센서, 외부 장치

계층을 나누는 이유

• 장치가 바뀌어도 전략을 다시 작성할 필요가 없음: 하위 프로토콜과 데이터 포인트는 수집 계층에서 처리하고 상위 전략은 통합된 dataKey를 사용합니다.
• 업무 변경이 통신 드라이버에 영향을 주지 않음: 임계값, 시간대 및 제어 규칙을 전략 계층에서 조정하므로 장치 프로토콜 구현을 수정할 필요가 없습니다.
• 화면과 제어 엔진 분리: Edge-EMS Builder는 고정 UI에 종속되지 않으며, 프런트엔드는 표준 경로로 데이터를 구독하고 제어를 요청할 수 있습니다.
• 클라우드를 사용할 수 없어도 로컬 폐루프 유지 가능: 핵심 판단과 동작은 엣지에서 실행됩니다. 구체적인 오프라인 기능은 프로젝트 설정과 외부 의존성에 따라 달라집니다.

2. 한 번의 제어가 완료되는 과정

모든 업무 전략은 “수집 → 계산 → 결정 → 실행”의 네 단계로 나눌 수 있습니다.

단계	EMS Builder의 작업	예: 배전 변압기 공급 구역의 용량 지원
① 수집	CommBridge가 원본 데이터 포인트를 읽어 EMS Builder에 동기화	변압기 부하, PCS 상태 및 SOC 읽기
② 계산	표현식 엔진이 중간 상태, 여유 용량 또는 위험 계산	용량 부족분과 ESS의 가용 방전 전력 계산
③ 결정	트리거 구성이 조건을 판단하고 동작 선택	부하가 상한에 가까워지고 SOC가 허용할 때 지원 시작
④ 실행	장치 쓰기, 알람 기록, MQTT 발행 또는 프런트엔드 전송	PCS에 전력 지령 전달 및 실행 상태 보고

실행 후의 전력, SOC 및 장치 상태를 다시 수집하여 다음 판단 주기에 사용합니다. 안정적인 전략에는 단순한 IF / THEN 외에도 시작/종료 임계값, 디바운싱, 우선순위, 통신 이상 처리, 장치 보호 및 수동 제어 전환이 포함되어야 합니다.

폐루프 전반을 지원하는 두 가지 메커니즘

• 공유 대상: 다른 Edge-EMS Builder 노드의 데이터를 로컬 데이터처럼 표현식과 트리거 판단에 사용하여 장치 간 협업을 구성할 수 있습니다.
• 장치 유닛 동적 확장(UDE): 같은 유형의 장치에 템플릿을 한 번 정의하면 새 인스턴스 연결 시 집계, 그룹 및 공유 설정을 자동으로 실체화하여 반복 설정을 줄입니다.

3. 세 가지 실행 모드

세 모드는 같은 Edge-EMS Builder 엔진을 사용하며 독립적으로 사용하거나 한 프로젝트에서 조합할 수 있습니다.

1. 엣지 자율 운영

데이터 수집, 계산, 판단 및 제어가 모두 사이트 내부에서 완료됩니다. 응답 속도, 연속 운영 및 데이터 현지 보관 요구가 높은 상황에 적합합니다.

대표 흐름: 현장 장치 → CommBridge → Edge-EMS Builder 전략 → 현장 장치

적합한 요구: 시간대별 충방전, 역송 방지, 최대수요전력 제어, 장치 인터록 및 사이트 내부 알람.

설계 중점: 로컬 보호를 우선합니다. 외부 전기 요금, 날씨 또는 클라우드 명령에 의존하는 경우 캐시, 제한 시간 및 기능 축소 운영 방안을 설계해야 합니다.

2. 클라우드와 엣지의 협업

엣지는 실시간 실행을, 클라우드는 통합 관리, 전략 오케스트레이션, 원격 운영 관리 또는 사이트 간 분석을 담당합니다. MQTT는 양방향 발행/구독과 응답 메커니즘을 지원하며, Edge-EMS Builder는 HTTP로 승인된 외부 정보를 가져올 수도 있습니다.

대표 흐름: 클라우드가 목표/전략 전달 → 엣지가 검증 및 실행 → 결과를 클라우드로 반환

적합한 요구: 다중 사이트 모니터링, 원격 매개변수 조정, 계획 곡선 전달, 운영 분석 및 통합 알람.

설계 중점: 클라우드 목표가 현장 안전 한계를 우회해서는 안 됩니다. 네트워크 단절 중 계속 실행할지, 마지막 유효 값을 유지할지, 안전 전략으로 전환할지 명확히 해야 합니다.

3. 다중 노드 협업

여러 Edge-EMS Builder가 공유 대상으로 데이터를 동기화합니다. 주 노드는 하위 노드의 상태를 모아 통합 계산할 수 있으며, 하위 노드도 역할 전환 후 새 작업을 수행할 수 있습니다.

대표 흐름: 여러 하위 노드가 데이터 공유 → 주 노드가 사이트 목표 계산 → 각 노드가 할당 결과 실행

적합한 요구: 다중 장치 전력 배분, 구역 간 장치 군 제어, 사이트 수준 부하 분산, 이중화 및 역할 전환.

설계 중점: 주/종속 관계, 공유 주기, 데이터 유효 시간, 네트워크 이상 상태 및 연결 단절 후 로컬 전략을 정의합니다.

4. 핵심 기능 및 운영 지원

기능	해결하는 문제	폐루프 내 역할
데이터 모델	원본, 시간대별, 집계 및 공유 데이터의 구성 방식 통합	수집 및 계산 기반
표현식 엔진	Lua로 합계, 필터링, 상태 판단 및 장치 간 계산 수행	계산
트리거 구성	“조건 + 동작”으로 업무 규칙 구성	결정 및 실행
MQTT 클라우드와 엣지 협업	데이터 발행, 명령 구독, 응답 및 클라우드와 엣지의 양방향 통신	클라우드와 엣지 연결
장치 협업 및 공유 대상	여러 노드가 데이터를 공유하고 서로의 계산에 참여	분산 협업
장치 유닛 동적 확장(UDE)	템플릿, 동적 자리표시자 및 기존 인스턴스 조정	규모 확장
알람 수명 주기	이상, 복구 및 수동 해결 추적	상태 및 처리
이력 및 아카이브	추세 분석, 비동기 내보내기 및 다중 계획 아카이브	데이터 보존
운영 관리	용량 권장 사항, 설정 출처, 유지보수 잠금 및 제어 로그	지속 운영

또한 프런트엔드 실시간 전송 및 직접 제어는 프런트엔드와 백엔드 시스템에 WebSocket 채널을 제공하므로, 사용자 정의 화면에서 실시간 데이터를 구독하고 권한 및 안전 제약 내에서 제어를 요청할 수 있습니다.

5. 다양한 요구 사항을 조합하는 방법

Edge-EMS Builder는 “모든 프로젝트가 같은 전략을 사용해야 한다”고 가정하지 않습니다. 동일한 구성 방법으로 다양한 요구를 구현합니다.

요구 사항 = 필수 데이터 + 계산 규칙 + 트리거 조건 + 실행 동작 + 보호 및 검증

요구 사항	필수 데이터	계산 및 판단	대표 동작
피크 저감 및 경부하 시간대 충전 / 최대수요전력 제어	계통 연계점 전력, SOC, PCS 상태, 최대수요전력 목표	전력 부족분과 가용 충방전 능력 계산	PCS 전력 지령 전달, 전략 상태 기록
역송 방지	계통 연계점 전력, 태양광 전력, ESS 가용 전력	역송 추세 판단 및 출력 제한	ESS 충전으로 흡수, 태양광 출력 제한 또는 알람
충전기 부하 분산	변압기 여유 용량, 각 충전기의 요구 및 상태	배분 가능 전력 계산 및 규칙별 배분	각 충전기의 전력 상한 조정
다중 장치 조정	각 유닛의 SOC, 전력 상한 및 사용 가능 상태	SOC, 용량 또는 우선순위에 따라 사이트 목표 배분	여러 PCS/노드에 하위 목표 전달
시간대별 운영 및 계획 곡선	시간대, 전기 요금, SOC, 부하 예측	현재 시간대 매칭 및 보호 한계 확인	충방전 목표 전환, 실행 결과 반환
외부 정보 기반 운영	전기 요금, 날씨, 생산 계획, 예측 결과	데이터 최신성 검증 및 최적화 또는 판단에 활용	목표 조정, 기능 축소 전략 진입 또는 알람

예제: 업무 요구 문장을 EMS Builder 설정으로 변환

요구 사항은 다음과 같습니다.

“계통 연계점 전력이 800 kW를 초과하고 SOC가 20%를 넘으면 ESS가 자동으로 방전하고, 760 kW로 떨어지면 종료한다.”

구현하려면 최소한 다음을 설정해야 합니다.

1. 계통 연계점 전력, SOC, PCS 사용 가능 상태 및 최대 방전 전력 등의 데이터
2. 용량 부족분 및 목표 방전 전력 표현식
3. 800 kW에서 시작하고 760 kW에서 종료하는 이중 임계값 조건
4. PCS 전력 쓰기 동작, 빈도 제한 및 실패 처리
5. SOC/온도/알람 보호, 수동 제어 전환 및 통신 이상 전략
6. 정상, 경계 조건, 네트워크 단절 및 장치 고장 등의 테스트 사례

Edge-EMS Builder는 전략을 표현하고 실행하는 기반을 제공합니다. 전략의 안전성과 정확성은 요구 사항 정의, 장치 기능 및 검증 품질에 달려 있습니다.

6. 유선, 무선 및 사이트 간 연결의 가능성

Edge-EMS Builder의 핵심 로직은 특정 네트워크 매체와 분리되어 있지만, “네트워크 연결 가능”이 “모든 무선 링크가 실시간 제어에 적합함”을 의미하지는 않습니다.

상위 IP 네트워크

MQTT/MQTTS, HTTP 및 WebSocket은 연결 가능한 IP 네트워크에서 실행할 수 있습니다. 하드웨어와 네트워크 조건에 따라 이더넷, Wi-Fi, 4G/5G 또는 전용망으로 클라우드와 다른 노드를 연결할 수 있습니다.

이는 아키텍처상 가능성을 의미하며, Edge-EMS Builder 엣지 하드웨어에 무선 모듈이 내장되어 있다는 사양 보장은 아닙니다. 구체적인 무선 기능은 선택한 하드웨어, 통신사 네트워크, 현장 커버리지 및 인증 요구 사항을 바탕으로 확인해야 합니다.

현장 장치 네트워크

PCS, BMS, 전력량계 등을 무선으로 연결할 수 있는지는 장치 자체, 무선 게이트웨이 및 CommBridge의 프로토콜 지원에 달려 있습니다. 무선 링크는 전송 방식일 뿐이며 레지스터 매핑, 실시간성 또는 제어 권한 문제를 자동으로 해결하지 않습니다.

무선 또는 광역 연결에서 추가로 처리할 사항

• 지연 시간 및 지터: 밀리초 단위의 폐루프는 우선 로컬에 유지합니다. 광역 링크는 목표 전달, 데이터 보고 및 엄격한 실시간성이 필요 없는 협업에 더 적합합니다.
• 연결 단절 및 데이터 만료: 공유 데이터의 유효 시간을 표시하고 연결 단절 후 유지, 기능 축소 또는 종료 전략을 명확히 합니다.
• 보안: TLS, 인증, 최소 권한 및 감사를 적용하여 장치 제어 인터페이스가 공용 인터넷에 직접 노출되지 않도록 합니다.
• 현장 보호: 하드웨어 인터록, 장치 보호 및 로컬 안전 제어는 클라우드나 불안정한 링크에 의존해서는 안 됩니다.

따라서 다음과 같은 전체 원칙을 권장합니다.

실시간 제어는 엣지에 유지하고 최적화 목표는 클라우드에서 받을 수 있습니다. 무선은 연결을 담당하며 보안과 재해 복구가 안전망을 제공합니다.

7. “무선 연결”에서 “무한한 확장 가능성”으로

Edge-EMS Builder의 기능 범위는 세 가지 조건으로 판단할 수 있습니다.

전제	확인할 질문
데이터 확보 가능	필요한 상태를 안정적으로 수집할 수 있고, 출처가 신뢰할 수 있으며 최신성이 있는가?
규칙 표현 가능	목표, 제약, 우선순위 및 예외 경로를 명확하게 설명하고 테스트할 수 있는가?
동작 실행 가능	장치나 시스템이 규정을 준수하며 권한을 부여하고 검증할 수 있는 제어 인터페이스를 제공하는가?

세 조건을 모두 충족하면 Edge-EMS Builder를 기존 EMS뿐 아니라 단지 내 장치 군 제어, 유연 부하 조정, 생산 계획 연계 및 환경·에너지 협업 등 “감지 → 판단 → 실행”의 자동화 시나리오로 확장할 수 있습니다.

다만 다음 한계는 항상 존재합니다.

• Edge-EMS Builder는 장치 제조사의 보호 로직, 안전 인증 및 현장 인터록을 대체할 수 없습니다.
• 외부 예측 또는 AI 결과를 활용할 때는 범위 검증, 제한 시간 처리 및 안전 출력 제한을 적용해야 하며, 결정적인 규칙을 우회하여 핵심 장치를 직접 제어해서는 안 됩니다.
• 여러 장치의 협업 성능은 시계, 네트워크, 데이터 품질 및 목표 배분 알고리즘에 따라 달라집니다.
• 새로운 전략은 시뮬레이션 또는 테스트 환경에서 검증한 후 통제된 절차에 따라 운영 환경에 적용해야 합니다.

8. 배포 용량: 실측 데이터에서 시작

AFE-E630에서 현재 검증된 권장 시나리오 S3.5는 수집 설정 부하 초당 5,000포인트, 집계 연산 30개, Trigger 초당 90회, MQTT 초당 20회 및 협업 작업 초당 10회이며, 변경 기반 저장을 사용합니다(최대 10초 이내 저장).

2026-07-29 테스트 배치(보고서 v1.3)에서 이 시나리오의 Trigger / MQTT P95 지연 시간은 각각 56 ms / 77 ms이고, 전체 장치 CPU P95는 71.09%, 전체 장치 실제 메모리 사용률 P95는 41.41%입니다. 초기 운영 용량을 계획할 때는 이 실측 부하에서 약 20%의 엔지니어링 여유를 확보하는 것이 좋습니다.

이 결과는 지정된 소프트웨어와 하드웨어 및 유효한 단시간 샘플 2,000개를 기반으로 합니다. 72시간 안정성 결론이 아니며, 스크립트, 메시지 크기 및 데이터베이스 규모가 다른 환경에 그대로 확대 적용할 수 없습니다. AFE-E630 성능 테스트 보고서를 참조하세요.

운영 적용 전 점검 목록

• 장치 포인트 목록, 물리량 차원, 정밀도, 읽기/쓰기 권한 및 이상값을 확인했는가?
• 전략의 시작, 종료, 디바운싱, 우선순위 및 충돌 처리가 명확한가?
• 네트워크 단절, 데이터 만료, 장치 오프라인 및 쓰기 실패에 대한 기능 축소 경로가 있는가?
• 장치 보호, 하드웨어 인터록, 수동 제어 전환 및 권한 감사가 독립적으로 유효한가?
• 실제 스크립트, 메시지 크기, 이력 데이터 규모 및 대상 하드웨어로 부하 테스트를 완료했는가?
• 설정 버전, 롤백 계획, 로그 및 알람 모니터링을 마련했는가?

다음 단계

• 제품 가치와 활용 상황: Edge-EMS Builder 제품 소개.
• 설정 객체 이해: 핵심 개념.
• 업무 설정 과정: 배전 변압기 공급 구역의 임시 용량 증대 또는 충전기 클러스터 부하 분산.
• 프런트엔드 및 클라우드 통합: 프런트엔드 실시간 전송 및 직접 제어, MQTT 클라우드와 엣지 협업.