상업용 BESS에서 BMS, PCS 및 EMS는 어떻게 통신합니까? 인터페이스, 프로토콜 및 통합 책임

세 장치가 동일한 프로토콜을 지원할 수 있지만 여전히 통신에 실패할 수 있습니다.

상업용 BESS에서 BMS는 배터리 상태와 작동 한계를 보고하고, PCS는 전력을 변환하며 충전/방전 명령을 실행하고, EMS는 사이트 목표에 따라 전력이 이동해야 할 시기를 결정합니다. 통신은 일반적으로 CAN, RS485, Modbus RTU/TCP 또는 이더넷 기반 인터페이스를 사용합니다. 그러나 프로토콜 이름을 공유한다고 해서 호환성을 증명하는 것은 아닙니다. 장치들은 데이터 맵, 스케일링, 주소, 타이밍, 제어 권한, 알람 논리 및 안전 장치 동작에 대해서도 합의해야 합니다.

How Do BMS, PCS, and EMS Communicate in a Commercial BESS? Interfaces, Protocols, and Integration Responsibilities

DOE의 BESS 아키텍처는 이를 서로 다른 제어 계층으로 설명합니다: BMS는 배터리 모듈에 가까이 위치하고, PCS는 전력 변환을 제어하며, EMS는 사이트 제어 수준에서 작동합니다.

이 계층 구조는 하나의 명령을 따를 경우 이해하기 더 쉽습니다.

EMS는 100 kW라고 말합니다. PCS는 단순히 따를 수 없습니다.

공장 수요가 최대 한계에 접근한다고 상상해 보십시오.

EMS가 계산합니다:

필요한 BESS 방전 = 100 kW

PCS로 전력 요청을 보냅니다.

하지만 100 kW를 전달하기 전에 제어 체인은 다른 의견을 가지고 있습니다.

BMS는 현재 다음과 같이 보고할 수 있습니다:

SoC: 24%

허용된 최대 방전: 62 kW

아마도 SoC, 셀 전압, 온도, 전류 또는 다른 배터리 제약 때문일 수 있습니다.

올바른 결과는 다음과 같지 않습니다:

EMS 명령 = 100 kW → PCS 출력 = 100 kW

PCS는 배터리의 허용된 범위 내에서 작동해야 합니다.

개념적으로:

BMS → “배터리가 할 수 있는 것”

EMS → “사이트가 배터리에게 원하는 것”

PCS → “실제로 실행할 수 있는 전력 변환”

이 분리는 안전한 BESS 제어의 기본입니다.

CAN과 Modbus는 언어이지 합의가 아닙니다.

여기에서 조달 사양이 종종 지나치게 낙관적이 됩니다.

공급업체 A는 말합니다:

BMS 통신: CAN.

공급업체 B는 말합니다:

PCS는 CAN을 지원합니다.

구매자는 다음과 같이 작성합니다:

호환 가능.

아직 아닙니다.

CAN은 통신 메커니즘을 설명합니다. 장치들은 여전히 호환 가능한 메시지 정의가 필요합니다.

Modbus에서도 동일한 문제가 발생합니다.

두 장치가 모두 Modbus RTU를 지원할 수 있지만 다음에 대해 의견이 다를 수 있습니다:

레지스터 주소

데이터 유형

바이트 순서

스케일링

읽기/쓰기 권한

장치 ID

업데이트 속도

알람 코드

레지스터 값은500모두가 그것이 의미하는 바에 동의할 때까지 무의미합니다:

500 A

50.0 A

또는 전혀 다른 것.

그래서 저는 커미셔닝 전에 실제 통신 프로토콜이나 레지스터 맵을 요청하고 싶습니다.

다니스제품인터페이스가 시스템 경계에 의존하는 이유를 보여주기

모든 상업용 배터리 제품이 동일한 인터페이스를 노출하는 것은 아닙니다.

Dawnice의BS09-225-D 225.07 kWh DC 측 시스템, 예를 들어, 다음을 게시합니다:CAN/RS485인터페이스를 제공하며 CAN을 BMS 통신 방법으로 식별합니다.

그의 통합된BS07-265-ES-X 125 kW/265.3 kWh시스템은 대신에Modbus TCP/RTU를 게시합니다.및 EMS/클라우드 준비 상태.

다우니스의 1 MW/2.089 MWh 컨테이너 사양은 EMS 통신을 통해RS485 및 TCP/IP.

이러한 차이는 이해가 됩니다.

DC 측 배터리는 외부 PCS와의 인터페이스가 필요합니다.

올인원 시스템은 이미 내부적으로 배터리–PCS 관계를 더 많이 포함하고 있습니다.

컨테이너화된 발전소는 EMS, 모니터링, 계량기 및 잠재적으로 현장 SCADA와의 고급 통신이 필요합니다.

통신 아키텍처는시스템 경계.

How Do BMS, PCS, and EMS Communicate in a Commercial BESS? Interfaces, Protocols, and Integration Responsibilities

미터기도 대화의 일부입니다

피크 셰이빙은 좋은 예를 제공합니다.

현장 계량기는 다음과 같이 보고합니다:

그리드 수입 = 680 kW

EMS 목표는:

600 kW

EMS는 대략적으로 계산합니다:

80 kW 방전 필요

그리고 명령을 보냅니다.

PCS는 이를 실행합니다.

그런 다음 계량기는 새로운 그리드 상태를 보고하여 EMS가 다시 조정할 수 있게 합니다.

따라서 실제 루프는 다음과 같습니다:

현장 계량기 → EMS → PCS ↔ BMS → PCS → 현장 계량기

이것이 역 CT 또는 잘못된 계량기 스케일링이 완전히 건강한 배터리를 잘못 작동하게 만들 수 있는 이유입니다.

EMS는 잘못된 정보로부터 합리적인 결정을 내리고 있습니다.

DOE의 BESS 통신 아키텍처는 배터리 통신을 하나의 CAN 케이블로 취급하기보다는 유사하게 계량기, EMS, PCS, BMS, 환경 제어, HMI, 화재 시스템 및 네트워크 인프라를 포함합니다.

통신 실패는 정의된 안전 상태가 필요합니다

이제 EMS 네트워크의 플러그를 뽑으세요.

무슨 일이 일어나야 할까요?

그 답은 설계 사양에 포함되어야 합니다.

응용 프로그램 및 승인된 아키텍처에 따라 시스템은 다음과 같을 수 있습니다:

정의된 기간 동안 마지막 유효 명령을 계속 수행

로컬 PCS 제어로 되돌아가기

전력을 줄이기

충전/방전을 중지합니다.

알람을 발생시킵니다.

또는 다른 미리 정의된 안전 상태로 들어갑니다.

다음과 같은 경우에도 동일한 질문이 적용됩니다:

BMS–PCS 통신이 실패할 때

계량기 데이터가 사라질 때

클라우드 연결이 끊길 때

SCADA가 사용할 수 없게 될 때

이러한 실패는 동등하지 않습니다.

클라우드 중단이 안전한 배터리 작동에 필요한 BMS 한계를 잃는 것과 반드시 같은 결과를 초래하지는 않습니다.

따라서 통신 손실 매트릭스는 다음을 정의해야 합니다:

손실 링크 → 타임아웃 → 대체 조치 → 알람 → 복구 조건

SAT 이전에.

책임 매트릭스가 프로토콜 목록보다 더 중요합니다

이 표를 기술 계약서에 넣고 싶습니다:

인터페이스데이터 / 기능책임 당사자
배터리 ↔ PCS한계, SoC, 알람, 명령지정된 공급업체/통합자
PCS ↔ EMS전력 명령/상태지정된 공급업체/통합자
계량기 ↔ EMS그리드/부하 측정EPC / EMS 파티
EMS ↔ SCADA모니터링/제어EMS / 사이트 통합자
원격 플랫폼데이터/지원 접근정의된 공급자
네트워크 인프라IP/VLAN/방화벽사이트/EPC 책임

마지막 열은 놀랍도록 흔한 시운전 대화를 방지합니다:

배터리 공급업체:

“우리 CAN은 작동합니다.”

PCS 공급업체:

“우리 CAN은 작동합니다.”

통합자:

“그렇다면 왜 통신이 이루어지지 않나요?”

Dawnice의 기술 지원 라이브러리에는 다음과 같은 조합에 대한 전용 통신 절차가 포함되어 있습니다:Solis 50 kW PCS와 Dawnice 100/143 kWh 저장 장치및Megarevo 500 kW PCS와 Dawnice 860 kWh C&I 저장 장치, 이는 실제 장치 쌍을 이루기 위해서는 데이터 시트에 프로토콜을 나열하는 것 이상의 구성 및 통합 작업이 필요함을 보여줍니다.

인터페이스가 완전하다고 부르기 전에 테스트할 사항

모든 장치가 녹색 아이콘을 표시한다고 해서 통신이 완료되었다고 생각하지 않습니다.

FAT/SAT 동안 다음을 증명하고 싶습니다:

SoC 및 온도 값이 올바르게 조정됩니다.

BMS 충전/방전 한계가 PCS에 도달합니다.

EMS 전력 명령이 올바르게 실행됩니다.

미터 방향과 스케일링이 올바릅니다.

알람이 의도된 HMI/SCADA로 전파됩니다.

타임스탬프가 일치합니다.

통신 손실 동작이 사양과 일치합니다.

통신이 복구된 후 시스템이 올바르게 복구됩니다.

Ruibit/Dawnice 프로젝트의 경우 외부 PCS, EMS, 미터 또는 SCADA 시스템이 관련될 때 배송 전에 해당 책임이 동결되어야 합니다. Dawnice는 그들의 C&I제품표준 인터페이스를 지원하며 CAN, RS232 및 RS485를 포함하고, 더 큰 C&I 프로젝트를 위한 시스템 통합 및 커미셔닝 서비스를 제공합니다.

프로토콜 목록은 어떤 대화가 가능한지를 알려줍니다.

커미셔닝된 BESS는 장치들이 동일한 데이터를 이해하고, 동일한 제어 계층을 존중하며, 대화가 중단될 때 안전하게 실패하고, 인터페이스 작동에 대한 책임이 누구에게 있는지에 대한 모호함이 없음을 증명합니다.

How Do BMS, PCS, and EMS Communicate in a Commercial BESS? Interfaces, Protocols, and Integration Responsibilities

자주 묻는 질문

1. 상업용 BESS에서 BMS, PCS 및 EMS는 어떻게 통신합니까?

그BMS는 배터리 상태, SoC, 알람 및 운영 한계를 제공합니다.,EMS는 필요한 충전 또는 방전 전력을 결정합니다., 그리고PCS는 배터리 및 시스템 한계를 존중하면서 전력 변환 명령을 실행합니다..

2. 상업용 BESS에서 일반적으로 사용되는 통신 프로토콜은 무엇입니까?

공통 인터페이스에는CAN, RS485, Modbus RTU/TCP 및 이더넷 기반 통신이 포함됩니다.같은 프로토콜을 지원한다고 해서 장치 간의 호환성이 자동으로 보장되는 것은 아닙니다.

3. 두 개의 BESS 장치가 CAN 또는 Modbus를 지원할 수 있지만 여전히 통신에 실패하는 이유는 무엇입니까?

그들은 서로 다른메시지 정의, 레지스터 주소, 스케일링, 바이트 순서, 장치 ID, 업데이트 속도, 알람 코드 또는 제어 논리를 사용할 수 있습니다.. 따라서 실제 프로토콜/레지스터 맵을 검증해야 합니다.

4. BMS, PCS 또는 EMS 통신이 끊기면 어떻게 해야 합니까?

시스템은 실패한 인터페이스에 따라 미리 정의된 상태로 진입해야 합니다. 사양은 다음을 정의해야 합니다.타임아웃, 대체 동작, 알람 동작 및 복구 조건각 통신 실패에 대해.

5. BMS–PCS–EMS 통합에 대한 책임은 누구입니까?

책임은 프로젝트 문서에서 명시적으로 할당되어야 합니다. 구매자는배터리, PCS, EMS, 미터, SCADA, 원격 플랫폼 및 사이트 네트워크 간의 각 인터페이스의 소유자를 정의해야 합니다.FAT 및 커미셔닝 전에.

완벽한 BESS 솔루션을 찾을 준비가 되었나요?

상업적 및 산업적 에너지 저장 요구에 맞춘 맞춤형 BESS 솔루션을 위해 Ruibit BESS에 무료 상담을 요청하세요.