내 BMS가 통신하지 않는 이유는 무엇인가요? 상업용 BESS 통신 실패 문제 해결

배터리는 정상 상태였습니다. 메시지가 전달되지 않았습니다.

상업용 BESS에서 BMS 통신 실패는 일반적으로 BMS를 교체하기에 충분한 증거가 아닙니다. 어떤 통신 경로가 실패했는지 정확히 식별한 다음, 전원 및 작동 상태, 물리적 배선, 인터페이스 유형, 종단, 노드/주소 설정, 프로토콜 선택, 펌웨어 호환성 및 실제 메시지 트래픽을 확인하십시오. 통신 알람과 배터리 결함은 두 가지 다른 진단 문제입니다.

기술자들이 HMI가 보여준 것 때문에 몇 시간을 낭비하는 것을 보았습니다.BMS 통신 오류그리고 모두 즉시 배터리 랙에 대해 논의하기 시작했습니다.

내 첫 번째 질문은 더 간단합니다:

누가 누구와의 대화를 중단했나요?

C&I BESS에서 "BMS 통신"은 랙 BMS에서 마스터 BMS, BMS에서 PCS, BMS에서 EMS, 또는 에너지 저장 시스템에서 SCADA/cloud 모니터링으로의 경로를 설명할 수 있습니다. Dawnice의 현재 C&I제품다양성을 보여줍니다: BS09-225-D는CAN/RS485통신을 게시하고, BS07-265-ES-X는Modbus TCP/RTU를 게시합니다.및 EMS/클라우드 준비 상태.Dawnice BS09-225-D Dawnice BS07-265-ES-X

같은 광범위한 증상.

잠재적으로 매우 다른 결함.

08:17 — PCS가 "BMS 없음"이라고 말했습니다.

PCS에 연결된 가상의 400 kWh 상업용 배터리를 고려해 보십시오.

시스템은 금요일에 올바르게 설치되었습니다.

월요일 아침:

배터리 HMI:정상
랙 전압:존재
셀 온도:그럴듯한
PCS:BMS 통신 손실
EMS:배터리 사용 불가
컨택터:열기

유혹은 이렇게 말하는 것입니다:

"BMS가 실패했습니다."

나는 그렇게 말하지 않을 것입니다.

지역 배터리 HMI가 여전히 셀과 온도를 정확하게 읽고 있다면, BMS는 분명히 최소한 그 일의 일부를 수행하고 있습니다. 실패한 경계는 BMS와 PCS 사이일 수 있습니다.

그것은 즉시 조사를 변화시킵니다.

무언가를 만지기 전에 경고 타임스탬프를 기록한 다음 BMS, PCS 및 EMS 이벤트 로그와 비교합니다.

세 개의 시계가 여섯 분 차이가 나면, 그 문제도 해결합니다. 이벤트 연대기가 신뢰할 수 없을 때 근본 원인 분석은 놀라울 정도로 복잡해집니다.

노트북을 열기 전에 지루한 것들을 점검합니다.

교체 통신 케이블은 우아한 프로토콜 분석보다 더 많은 결함을 해결했습니다.

소프트웨어를 변경하기 전에 알고 싶습니다:

BMS가 전원이 공급되고 완전히 작동 중인가요?

올바른 통신 포트를 사용하고 있나요?

커넥터가 완전히 연결되어 있나요?

케이블 핀 배치가 RJ45 커넥터에서 가정된 것이 아니라 확인되었나요?

CAN-H/CAN-L 또는 RS485 A/B가 올바르게 연결되어 있나요?

차폐/접지가 승인된 설계와 일치하나요?

케이블이 손상되었거나 눌리거나 연장되었거나 시끄러운 전력 전도체 옆으로 재배치되었나요?

RJ45는 심리적으로 특히 위험합니다. 두 장치가 동일한 커넥터를 사용할 수 있지만 완전히 다른 핀 배치를 가질 수 있습니다.

예를 들어, Dawnice의 배터리 매뉴얼은 일반 네트워크 케이블이 호환 가능하다고 암시하는 대신 CAN 및 RS485 통신 핀을 별도로 정의합니다.Dawnice 배터리 매뉴얼

커넥터 모양은 프로토콜이 아닙니다.

심지어 배선 정의도 아닙니다.

여러 랙이 한 번에 사라지면 개별 랙을 비난하는 것을 멈춥니다.

실패 패턴은 내가 어디를 봐야 하는지를 알려줍니다.

그 표는 시스템 매뉴얼을 대체할 수 없습니다.

하나의 공유 통신 링크가 실패했기 때문에 네 개의 건강한 배터리 모듈을 교체하지 않도록 하는 방법입니다.

CAN과 RS485는 다르게 실패합니다.

"통신 케이블"을 하나의 범주로 취급하지 않습니다.

CAN 네트워크에서는 토폴로지, CAN-H/CAN-L 극성, 비트 전송률, 노드 구성, 종단 및 예상 프레임이 실제로 존재하는지 확인하고 싶습니다.

RS485/Modbus RTU 네트워크에서는 A/B 극성, 슬레이브 주소, 전송 속도, 패리티, 정지 비트, 레지스터 매핑 및 종단에 대해 생각하기 시작합니다.

그Modbus 조직현재 프로토콜 및 직렬 라인 구현 사양을 유지합니다. 그들의 직렬 라인 가이드는 통신이 신뢰할 수 없을 때마다 추가해야 할 임의의 저항이 아닌 네트워크 설계의 속성으로 종단 및 극성을 다룹니다.

여기서 나는 익숙한 것에 대해 조심스러워진다:

"60옴을 측정하면 끝이다."

두 개의 120옴 종단이 병렬로 연결되면 전원이 공급되지 않은 버스에서 대략 60옴을 생성할 수 있지만, 그 측정값은 그렇게 설계된 토폴로지에서 적절한 조건 하에 측정된 경우에만 의미가 있다.

이는 주소, 보드레이트, 프로토콜 또는 데이터 매핑이 올바르다는 것을 증명하지 않는다.

하나의 유용한 숫자. 진단이 아니다.

녹색 통신 LED가 여전히 당신에게 거짓말을 할 수 있습니다.

물리적 링크가 건강해 보인다고 가정해 보자.

프레임이 이동하고 있다.

PCS는 여전히 작동을 거부하고 있다.

이제 나는 스택을 통해 위로 이동한다.

BMS와 PCS는 전기 신호 이상으로 합의해야 한다. 아키텍처에 따라 다음에 대한 호환 가능한 정의가 필요할 수 있다:

SoC

SoH

팩 전압/전류

최대 충전 전류

최대 방전 전류

충전/방전 활성화

알람 상태

접촉기 상태

온도 한계

하트비트/감시

CAN 버스는 PCS가 다른 메시지 세트를 듣고 있는 동안 전기적으로 완벽할 수 있다.

마찬가지로, Modbus 마스터는 잘못된 레지스터를 읽으면서 슬레이브와 성공적으로 통신할 수 있다.

그래서 "CAN 지원" 또는 "Modbus 지원"은 호환성 진술이 아니다.

이는 나에게 언어 계열을 알려준다.

두 장치가 같은 대화를 이해하는지 여부는 아니다.

프로토콜 선택은 실제 결함이지 설정 세부 사항이 아닙니다.

이것이 내가 하드웨어를 교체하기 전에 구성을 확인하는 것을 좋아하는 이유 중 하나이다.

예를 들어, Dawnice 인버터 매뉴얼은 다음을 식별한다.BMS 통신 오류 [58]그리고 기술자에게 통신 케이블과 구성된 리튬 배터리 통신 프로토콜이 배터리에 해당하는지 확인하라고 지시한다.Dawnice 인버터 매뉴얼

이 문제 해결 논리는 하나의 제품을 넘어 확장된다.

커미셔닝 엔지니어가 선택한다고 가정해 보겠습니다:

배터리 프로토콜 03

대신에:

배터리 프로토콜 08

케이블은 완벽합니다.

BMS는 정상입니다.

PCS는 정상입니다.

시스템은 여전히 작동하지 않습니다.

아무것도 "고장 나지 않았습니다."

구성이 잘못되었습니다.

Ruibit/Dawnice 상업 프로젝트의 경우, 승인된 BMS–PCS 통신 조합과 전기 BOM을 동결하겠습니다: 정확한 배터리/BMS 버전, PCS 모델, 프로토콜, 인터페이스, 매개변수 세트 및 펌웨어 버전.

펌웨어 변경은 드라이버가 캐비닛에 닿지 않아도 구성 요소 변경이 될 수 있습니다.

간헐적인 통신은 내가 더 심각하게 받아들이는 결함입니다.

완전히 끊어진 링크는 종종 더 쉽습니다.

간헐적인 링크는 FAT를 통과하고 커미셔닝을 견딜 수 있지만, 현장이 뜨겁거나 부하가 많거나 전기적 잡음이 있을 때 실패할 수 있습니다.

PCS가 80% 전력을 초과할 때만 통신 중단이 발생한다고 상상해 보십시오.

그 타이밍이 중요합니다.

무작위 소프트웨어를 탓하기 전에 라우팅 및 전자기 간섭을 조사하겠습니다.

문제가 전력과 관계없이 20초마다 발생한다면, 심박수/감시 타이밍을 살펴볼 수 있습니다.

다섯 번째 랙을 추가한 후에 발생한다면, 토폴로지, 주소 지정 및 종단 처리를 검토하겠습니다.

펌웨어 수정 3.12 직후에 시작된다면, 다른 업데이트를 수행하기 전에 이전 버전 번호를 원합니다.

결함이 나타나게 하는 조건은 증거입니다.

먼저 모든 것을 재부팅하여 지우지 마십시오.

내 진단 순서는 비싼 추측을 방지하도록 설계되었습니다.

저는 일반적으로 바깥에서 안쪽으로 작업합니다:

1. 실패한 통신 경계를 정의합니다.

BMS–랙? BMS–PCS? PCS–EMS? EMS–SCADA?

2. 증거를 보존합니다.

알람 코드, 타임스탬프, 스크린샷, 펌웨어 버전 및 최근 변경 사항.

3. 운영 상태를 확인합니다.

전원 공급 장치, BMS 상태, 접촉기, 로컬 알람.

4. 물리적 계층을 확인합니다.

케이블, 핀배치, 극성, 커넥터, 토폴로지, 종단, 차폐.

5. 통신 설정 확인

인터페이스, 노드 ID, 전송 속도, 비트 전송률, 패리티 및 프로토콜 선택.

6. 데이터 계층 확인

프레임, 레지스터 맵, 스케일링, 하트비트 및 명령/상태 교환.

7. 변경 이력 검토

펌웨어, 교체 부품, 매개변수 변경 및 네트워크 수정.

프로토콜 분석이 느슨한 커넥터를 수리할 수 없기 때문에 6단계로 바로 넘어가지 않습니다.

연속성이 호환성을 증명하지 않기 때문에 4단계에서 멈추지 않습니다.

시스템 동작이 수정되면 결함이 수정됩니다.

통신 경고가 사라지는 것이 제 수용 기준이 아닙니다.

수리 후, PCS가 신뢰할 수 있는 배터리 데이터를 수신하고 BMS 한계를 준수하는지 확인하고 싶습니다.

배터리 온도가 상승하여 BMS가 허용 충전 전류를 줄이면, PCS는 이를 따르나요?

방전 허가가 제거되면, 실제로 전원이 중지되나요?

SoC가 EMS에 정확히 도달하나요?

경고가 원격으로 나타나나요?

제어된 재시작 후 통신이 제대로 복구되나요?

타임스탬프가 정렬되어 있나요?

Dawnice는 현재 C&I 시스템이 CAN, RS485 및 관련 모니터링 플랫폼을 포함한 인터페이스를 통해 원격 모니터링 및 진단을 지원한다고 명시하고 있으며, C&I 배터리/PCS 조합을 위한 특정 통신 연결 튜토리얼을 게시합니다.다우니스 FAQ Dawnice 기술 지원

B2B 구매자에게 마지막 포인트는 들리는 것보다 더 중요합니다.

배터리와 PCS만 구매하지 마세요.

구매하세요검증된 통신 관계그들 간의, 버전, 설정 및 지원 책임이 기록된.

BESS가 "BMS 통신 실패"라고 말할 때, 비싼 실수는 경고에서 언급된 첫 번째 구성 요소가 실패한 구성 요소라고 가정하는 것입니다.

먼저 고장난 대화를 찾으세요. 하드웨어는 두 번째로 교체하세요.

자주 묻는 질문

1. 내 BMS가 PCS와 통신하지 않는 이유는 무엇인가요?

일반적인 원인에는잘못된 배선 또는 핀배치, CAN/RS485 극성, 잘못된 프로토콜 선택, 주소 설정, 종단, 펌웨어 호환성 문제, 손상된 케이블 또는 통신 포트 구성 등이 포함됩니다..

2. BMS 통신 알람이 BMS가 실패했다는 의미인가요?

아니요. BMS가 셀을 올바르게 모니터링하고 있을 수 있지만, BMS와 PCS, EMS, 마스터 BMS 또는 SCADA 간의 통신이 실패할 수 있습니다. 하드웨어를 교체하기 전에 실패한 통신 경계를 식별하세요.

3. 두 장치가 CAN 또는 RS485를 지원할 수 있지만 여전히 호환되지 않을 수 있나요?

네. 동일한 물리적 인터페이스를 공유한다고 해서 호환성이 보장되는 것은 아닙니다. 장치들은 또한프로토콜, 비트 전송률 또는 보드 전송률, 메시지/레지스터 정의, 주소 지정, 데이터 스케일링 및 제어 로직.

4. BMS 통신이 간헐적으로 실패하는 이유는 무엇인가요?

간헐적인 결함은 느슨한 커넥터, 불량 종단, 전기 노이즈, 케이블 라우팅, 불안정한 전원 공급 장치, 네트워크 토폴로지, 감시 타이밍 또는 펌웨어 문제로 인해 발생할 수 있습니다. 시스템을 재부팅하기 전에 결함이 발생한 시점을 기록하십시오.

5. BMS 통신 결함을 수정한 후 무엇을 확인해야 하나요?

PCS가 올바른 정보를 수신하는지 확인하십시오.SoC, 전압, 전류, 온도, 알람 및 충전/방전 한계, BMS 보호 명령을 따르고, EMS에 올바르게 보고하며, 제어된 재시작 후 통신을 복구합니다.