Три устройства могут поддерживать один и тот же протокол и все равно не суметь установить связь
В коммерческом BESS BMS сообщает о состоянии батареи и операционных ограничениях, PCS преобразует мощность и выполняет команды зарядки/разрядки, а EMS решает, когда эта мощность должна перемещаться в соответствии с целями сайта. Общение обычно использует интерфейсы на базе CAN, RS485, Modbus RTU/TCP или Ethernet. Но наличие общего названия протокола не доказывает совместимость — устройства также должны согласовать карты данных, масштабирование, адреса, тайминг, контрольные полномочия, логику сигнализации и поведение в случае сбоя.
Архитектура BESS DOE иллюстрирует это как разные уровни управления: BMS находится близко к модулям батареи, PCS контролирует преобразование мощности, в то время как EMS работает на уровне управления сайтом.
Эта иерархия легче для понимания, если мы следуем одной команде.
EMS говорит 100 кВт. PCS не может просто подчиниться.
Представьте, что спрос на заводе приближается к своему предельному значению.
EMS рассчитывает:
Необходимый разряд BESS = 100 кВт
Он отправляет запрос мощности к PCS.
Но прежде чем предоставить 100 кВт, цепочка управления имеет другое мнение.
BMS может в данный момент сообщать:
SoC: 24%
Максимально допустимый разряд: 62 кВт
возможно, из-за SoC, напряжения ячейки, температуры, тока или другого ограничения батареи.
Правильный результат не является:
Команда EMS = 100 кВт → Выход PCS = 100 кВт
PCS должен работать в пределах допустимого диапазона батареи.
Концептуально:
BMS → “Что батарее разрешено делать”
EMS → “Что сайт хочет, чтобы батарея делала”
PCS → “Что преобразование мощности может фактически выполнить”
Это разделение является основополагающим для безопасного управления BESS.
CAN и Modbus — это языки, а не соглашения
Здесь спецификации закупок часто становятся слишком оптимистичными.
Поставщик A говорит:
Связь BMS: CAN.
Поставщик B говорит:
PCS поддерживает CAN.
Покупатель пишет:
Совместимо.
Еще нет.
CAN описывает механизм связи. Устройства все еще нуждаются в совместимых определениях сообщений.
Та же проблема возникает и с Modbus.
Два устройства могут поддерживать Modbus RTU, но не соглашаться по поводу:
адресов регистров
типа данных
порядка байтов
масштабирования
прав доступа на чтение/запись
идентификаторов устройств
скоростей обновления
кодам тревог
Значение регистра500не имеет смысла, пока все не согласны, что оно означает:
500 А
50.0 А
или что-то совершенно другое.
Вот почему я бы попросил фактический протокол связи или карту регистров перед вводом в эксплуатацию.
DawniceПродуктыПокажите, почему интерфейс зависит от границы системы
Не каждый коммерческий продукт батареи предоставляет один и тот же интерфейс.
Dawnice'sBS09-225-D 225.07 кВтч на стороне постоянного тока, например, публикуетCAN/RS485интерфейсы и определяет CAN как метод связи BMS.
Его интегрированнаяBS07-265-ES-X 125 кВт/265.3 кВтчсистема вместо этого публикуетModbus TCP/RTUи готовность EMS/облака.
А спецификация контейнера Dawnice на 1 МВт/2.089 МВтч указывает на связь EMS черезRS485 и TCP/IP..
Эти различия имеют смысл.
Батарея на стороне постоянного тока нуждается в интерфейсе с внешним PCS.
Система «всё в одном» уже содержит больше внутренних связей между батареей и PCS.
Контейнеризированному заводу требуется более высокий уровень связи с EMS, мониторингом, счетчиками и, возможно, SCADA на площадке.
Архитектура связи следует заграницей системы.
Счетчик тоже является частью разговора
Примером может служить сглаживание пиковых нагрузок.
Счетчик на площадке сообщает:
Импорт из сети = 680 кВт
Цель EMS составляет:
600 кВт
EMS рассчитывает примерно:
необходимый разряд 80 кВт
и отправляет команду.
PCS выполняет её.
Счетчик затем сообщает новое состояние сети, позволяя EMS снова скорректироваться.
Таким образом, реальная петля ближе к:
Счетчик на площадке → EMS → PCS ↔ BMS → PCS → Счетчик на площадке
Вот почему обратный CT или неправильное масштабирование счетчика могут заставить совершенно исправную батарею вести себя неправильно.
EMS принимает рациональные решения на основе плохой информации.
Архитектура связи BESS от DOE аналогично включает счетчики, EMS, PCS, BMS, системы управления окружающей средой, HMI, системы пожаротушения и сетевую инфраструктуру, а не рассматривает связь батареи как один CAN-кабель.
Сбой связи требует определения безопасного состояния
Теперь отключите сеть 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 кВт PCS с хранилищем Dawnice 100/143 кВтчиMegarevo 500 кВт PCS с хранилищем Dawnice 860 кВтч C&I, что иллюстрирует, что фактическое сопряжение устройств требует настройки и интеграционной работы, выходящей за рамки простого указания протокола в техническом паспорте.
Что бы я протестировал, прежде чем считать интерфейс завершенным
Я не считаю связь установленной, потому что каждое устройство показывает зеленую иконку.
Во время FAT/SAT я хочу доказать:
значения SoC и температуры правильно масштабированы
пределы зарядки/разрядки BMS достигают PCS
команды мощности EMS выполняются корректно
направление и масштабирование счетчика правильные
сигналы тревоги передаются на целевую HMI/SCADA
временные метки согласованы
поведение при потере связи соответствует спецификации
система восстанавливается правильно после восстановления связи
Для проекта Ruibit/Dawnice эта ответственность должна быть заморожена перед отправкой, когда вовлечены внешние PCS, EMS, счетчики или SCADA-системы. Dawnice утверждает, что его C&IПродуктыподдерживает стандартные интерфейсы, включая CAN, RS232 и RS485, и предоставляет услуги по интеграции систем и вводу в эксплуатацию для более крупных проектов C&I.
Список протоколов говорит мне, какие разговоры могут быть возможны.
Запущенная BESS доказывает, что устройства понимают одни и те же данные, соблюдают одну и ту же иерархию управления, безопасно выходят из строя, когда разговор прекращается, и не оставляют неопределенности относительно того, кто отвечает за работу интерфейсов.
Часто задаваемые вопросы
1. Как BMS, PCS и EMS общаются в коммерческом BESS?
СистемаBMS предоставляет статус батареи, SoC, сигналы тревоги и рабочие пределы,EMS определяет необходимую мощность заряда или разряда, иPCS выполняет команды по преобразованию мощности, соблюдая пределы батареи и системы.
2. Какие протоколы связи обычно используются в коммерческих BESS?
Общие интерфейсы включаютCAN, RS485, Modbus RTU/TCP и Ethernet-ориентированную связь. Поддержка одного и того же протокола не гарантирует автоматически совместимость между устройствами.
3. Почему два устройства BESS могут поддерживать CAN или Modbus, но все равно не могут общаться?
Они могут использовать разныеопределения сообщений, адреса регистров, масштабирование, порядок байтов, идентификаторы устройств, скорости обновления, коды тревоги или логику управления. Фактическая карта протоколов/регистров должна быть проверена.
4. Что должно произойти, если связь между BMS, PCS или EMS потеряна?
Система должна войти в предопределенное состояние на основе неработающего интерфейса. Спецификация должна определитьвремя ожидания, резервные действия, поведение сигналов тревоги и условия восстановлениядля каждого сбоя связи.
5. Кто отвечает за интеграцию BMS–PCS–EMS?
Ответственность должна быть явно определена в проектной документации. Покупатели должны определить, кто владеет каждым интерфейсом междубатареей, PCS, EMS, счетчиком, SCADA, удаленной платформой и сетевой инфраструктурой сайтадо FAT и ввода в эксплуатацию.
