10.11.2021
10 ноября 2021 года мы завершаем переработку программной системы мониторинга аккумуляторов. Изначально она создавалась для литиевых батарейных решений, однако по мере развития портфеля стало очевидно: отдельное программное приложение под каждый тип батарей создает лишнюю сложность для эксплуатации. Поэтому наши инженеры переписали ядро и интерфейс так, чтобы одна программная платформа могла работать с литиевыми системами, а затем использоваться и для свинцово-кислотных АКБ.
Батарейный контур — одна из наиболее инерционных, но критичных частей ИБП. В штатном режиме он может месяцами не отдавать энергию в нагрузку, и именно поэтому деградацию отдельного элемента легко пропустить до реального разряда. Для оператора ЦОД важно видеть не только общий факт «батарея подключена», а состояние системы на уровне параметров, событий и отклонений, которые позволяют планировать обслуживание до того, как проблема проявится во время аварии сети.
Литиевые и свинцово-кислотные батареи различаются по электрическому поведению, способам оценки состояния и набору данных, который доступен от конкретной системы. Унификация не означает попытку сделать их одинаковыми. Мы разделяем слой получения данных и слой, с которым работает оператор. Протоколы, структура измерений и диагностические признаки могут отличаться, но журнал событий, система тревог, пользовательские роли и принцип навигации должны оставаться едиными. Это снижает зависимость эксплуатации от конкретной батарейной технологии.
Для ЦОД такой подход особенно важен при смешанном парке. На одном объекте могут работать разные поколения ИБП и батарейных систем, а при модернизации часть свинцово-кислотных цепочек может сохраняться одновременно с вводом литиевых решений. Если каждая подсистема требует отдельного интерфейса и собственной логики реакции на событие, дежурный персонал вынужден переключаться между несколькими системами и сопоставлять сообщения вручную. Единая оболочка уменьшает этот разрыв.
Мы также закладываем единый принцип классификации событий. Не каждое отклонение требует немедленного аварийного действия: часть параметров является предупреждением о тренде, часть — признаком необходимости планового обслуживания, а часть должна быстро эскалироваться как критическая тревога. Когда эта логика реализована централизованно, проще связать состояние батарей с регламентом эксплуатации и избежать двух противоположных ошибок — игнорирования важного сигнала и постоянного потока малозначимых уведомлений.
Переработка программного ядра продолжает наш общий подход к модульности. В MIR3 мы унифицируем силовые блоки, в MIRMBC — батарейный конструктив, в MIRPD — распределение питания. В мониторинге тем же «модулем» становится программный драйвер конкретного оборудования, который подключается к общей платформе вместо создания новой системы с отдельным интерфейсом.
Следующий этап — адаптация этой архитектуры для свинцово-кислотных аккумуляторов и накопление диагностических данных по разным режимам эксплуатации. Для заказчика конечная цель проста: независимо от химии батареи оператор должен получать сопоставимое представление о ее состоянии, понимать приоритет события и видеть, какой элемент требует внимания. Мониторинг становится не экраном с набором параметров, а инструментом управления остаточным риском батарейной системы.
