Почему мой BMS не общается? Устранение неполадок в коммерческих системах BESS

Аккумулятор был исправен. Сообщение не доходило.

Отказ в связи BMS в коммерческой BESS обычно не является достаточным основанием для замены BMS. Начните с определения, какой именно путь связи вышел из строя, затем проверьте питание и рабочее состояние, физическую проводку, тип интерфейса, завершение, настройки узла/адреса, выбор протокола, совместимость прошивки и фактический трафик сообщений. Сигнализация о связи и неисправность батареи - это две разные диагностические проблемы.

Я видел, как техники теряли часы, потому что HMI показывалОшибка связи BMSи все сразу начали обсуждать батарейный блок.

Мой первый вопрос проще:

Кто перестал говорить с кем?

В C&I BESS "связь BMS" может описывать связь между BMS стойки и главным BMS, BMS и PCS, BMS и EMS, или путь от системы хранения энергии к SCADA/облачному мониторингу. Текущие C&I DawniceПродуктыиллюстрируют разнообразие: его 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"

Рассмотрим гипотетическую коммерческую батарею емкостью 400 кВтч, подключенную к PCS.

Система была введена в эксплуатацию правильно в пятницу.

В понедельник утром:

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 ом на неактивной шине, но это значение имеет смысл только для топологии, спроектированной таким образом, и измеренной при соответствующих условиях.

Это не доказывает, что адреса, скорость передачи, протокол или отображение данных корректны.

Одно полезное число. Не диагноз.

Зеленый светодиод связи может все еще вас обманывать

Предположим, физическое соединение выглядит здоровым.

Фреймы движутся.

PCS все еще отказывается работать.

Теперь я поднимаюсь вверх по стеку.

BMS и PCS должны согласовывать больше, чем электрическую сигнализацию. В зависимости от архитектуры им могут понадобиться совместимые определения для:

SoC

SoH

напряжение/ток пакета

максимальный зарядный ток

максимальный разрядный ток

включение/выключение заряда/разряда

состояния сигнализации

состояние контактора

температурные пределы

сигнал о состоянии/сторожевой таймер

CAN-шина может быть электрически идеальной, в то время как PCS слушает другой набор сообщений.

Аналогично, мастер Modbus может успешно общаться с ведомым, читая неправильные регистры.

Вот почему "поддерживает CAN" или "поддерживает Modbus" не является заявлением о совместимости.

Это говорит мне о языковой семье.

Не о том, понимают ли два устройства один и тот же разговор.

Выбор протокола — это реальная ошибка, а не деталь настройки

Вот одна из причин, почему мне нравится проверять конфигурацию перед заменой оборудования.

Руководство инвертора Dawnice, например, указываетошибку связи BMS [58]и направляет техника проверить как коммуникационный кабель, так и соответствует ли настроенный протокол связи с литиевой батареей самой батарее.Руководство по инвертору Dawnice

Эта логика устранения неполадок масштабируется за пределы одного продукта.

Предположим, инженер по пусконаладке выбирает:

Протокол батареи 03

вместо:

Протокол батареи 08

Кабель в порядке.

BMS в хорошем состоянии.

PCS в хорошем состоянии.

Система все равно не работает.

Ничего не "сломано."

Конфигурация неверна.

Для коммерческих проектов Ruibit/Dawnice я бы заморозил утвержденную комбинацию связи BMS–PCS вместе с электрической спецификацией: точная версия батареи/BMS, модель PCS, протокол, интерфейс, набор параметров и версии прошивки.

Изменение прошивки может быть изменением компонента, даже если ни одна отвертка не касается шкафа.

Периодическая связь — это ошибка, которую я воспринимаю более серьезно

Совершенно мёртвая связь часто проще.

Переменная связь может пройти FAT, пережить пусконаладку, а затем выйти из строя, когда объект горячий, сильно загружен или электрически шумный.

Представьте, что сбои связи появляются только когда PCS превышает 80% мощности.

Это время имеет значение.

Я бы исследовал маршрутизацию и электромагнитные помехи, прежде чем обвинять случайное программное обеспечение.

Если проблема появляется каждые 20 секунд независимо от мощности, я бы посмотрел на тайминг сердцебиения/сторожевого таймера.

Если она появляется после добавления пятого стойки, я бы пересмотрел топологию, адресацию и терминаторы.

Если это начинается сразу после ревизии прошивки 3.12, я хочу знать номер предыдущей версии, прежде чем кто-либо выполнит другое обновление.

Условие, которое вызывает появление неисправности, является доказательством.

Не стирайте его, перезагружая всё сначала.

Мой диагностический порядок разработан, чтобы предотвратить дорогие догадки

Я обычно работаю снаружи внутрь:

1. Определите границу неработающей связи

BMS–стойка? BMS–PCS? PCS–EMS? EMS–SCADA?

2. Сохраните доказательства

Коды тревог, временные метки, скриншоты, версии прошивки и недавние изменения.

3. Проверьте рабочее состояние

Источники питания, состояние BMS, контакторы, местные сигналы тревоги.

4. Проверьте физический уровень

Кабель, распиновка, полярность, разъемы, топология, терминаторы, экранирование.

5. Проверьте настройки связи

Интерфейс, идентификатор узла, скорость передачи, битрейт, выбор четности и протокола.

6. Проверьте уровень данных

Фреймы, карта регистров, масштабирование, обмен сигналами и командами/статусами.

7. Просмотрите историю изменений

Прошивка, заменяемые компоненты, изменения параметров и модификации сети.

Я не перехожу сразу к шагу 6, потому что анализ протокола не может исправить плохой разъем.

Я не останавливаюсь на шаге 4, потому что непрерывность не доказывает совместимость.

Ошибка исправлена, когда поведение системы исправлено

Устранение сигнала тревоги связи не является моим критерием приемки.

После ремонта я хочу подтвердить, что PCS получает правдоподобные данные о батарее и соблюдает ограничения BMS.

Если BMS снижает допустимый зарядный ток из-за повышения температуры батареи, следует ли PCS за этим?

Если разрешение на разряд снято, действительно ли подача энергии останавливается?

Достигает ли SoC EMS правильно?

Появляются ли сигналы тревоги удаленно?

Восстанавливается ли связь правильно после контролируемой перезагрузки?

Синхронизированы ли временные метки?

Dawnice в настоящее время утверждает, что ее системы C&I поддерживают удаленный мониторинг и диагностику через интерфейсы, включая CAN, RS485 и связанные платформы мониторинга, и публикует конкретные учебные материалы по связи для комбинаций батарей/PCS C&I.Часто задаваемые вопросы Dawnice Техническая поддержка 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 и восстанавливает связь после контролируемой перезагрузки.