Система удалённого мониторинга BMS

Международная компания AYK Energy обратилась к нам с задачей разработать интерфейс сервиса, позволяющего в режиме реального времени собирать и анализировать данные с батарей, которые располагаются на танкерах, рабочее название проекта — BMS (Battery Management System).

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

На старте проекта у нас были функциональные требования, которые мы детализировали на нескольких сессиях интервью со стейкхолдерами.

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

— Евгений Черниговский, Global Software Manager

В процессе проектирования системы мы непрерывно общались с рабочей группой на стороне клиента, параллельно углубляясь в требования и документацию к системе. Основная сложность заключалась в том, что инженеры никогда ранее не работали с подобного рода интерфейсами и не могли сформировать чётких требований к внешнему виду инструмента. Кроме того, продукт не имеет аналогов на рынке, а значит, нельзя провести бенчмаркинг. Поэтому мы начали действовать максимально аккуратно и исключительно от потребности оператора системы.

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

• Получение и обработка сообщений об ошибках (Alarm logs)
• Создание запроса на получение данных за конкретный период (до 10 минут) с батареи (Request Trace Log)
• Фильтрация и обработка данных Trace log (Filters)
• Скрин батареи за час и более (Continiuos log A1)
• Скрин батареи за сутки (Continious log A2)
• Поиск батарей по проектам и их владельцам (Batteries)
• Добавление батареи в систему и просмотр информации о ней (Add battery и Battery screen)

Для основного дашборда выделили три наиболее важные функции и отобразили их в прототипе:

1. Контроль стабильности батарей (All batteries)
2. Получение сообщений об ошибках (Alarm logs)
3. Быстрое действие создания запроса (Request Trace log) и его получение (Trace log)

При этом Trace log может прийти с десятками тысяч данных по батарее. Такое количество данных невозможно вывести в общий график, поэтому инженер настраивает параметры вручную с помощью фильтров и уже после этого работает с графиком. Так он имеет возможность обрабатывать разные показатели и сравнивать их поведение. Чтобы одновременно показывать разные метрики (например, вольтаж и температуру), мы перевели их процентные соотношения, где 0% — минимальное значение за период, а 100% — максимальное.

Для огромного массива данных, которое формирует Trace log, потребовалась удобная фильтрация по многоуровневой структуре.

Итого в системе может располагаться около 2400 элементов, которые формируют десятки показателей каждую секунду. Для удобства мы разработали навигацию по всем уровням элементов на странице фильтров (Filters).

Все батареи вложены в проекты (Projects) и закреплены за клиентами (Customers). Инженеру нужна возможность быстрого поиска батарей по клиентам. Мы разработали его в виде таблицы с раскрывающимися списками и разместили на отдельной вкладке на экране с батареями. Это удобно, потому что количество клиентов может измеряться сотнями и нужно максимально оптимизированное решение. В свёрнутом состоянии мы видим общее количество проектов, батарей и самый проблемный статус для вложенных батарей.

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

— Евгений Черниговский, Global Software Manager

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

В мудборд вошли примеры того, как можно оформить интерфейс в целом, а также предложения по основным элементам (таблицы, сложные фильтры и графики).

У заказчика был ранее разработанный дизайн интерфейса экрана BMS, который располагается прямо на аккумуляторном блоке, поэтому было принято совместное решение оставить преемственность в стилистике, чтобы продукты не разнились и выглядели как части одной большой системы.

Далее мы отрисовали экраны всех 14 разделов системы. Проработали все состояния и сценарии для последующей разработки и отрисовали UI-kit с состояниями мелких элементов.

Мы создавали интерфейсы таким образом, чтобы обеспечить возможность их легкого изменения в случае обновления бизнес-требований после тестирования интерфейса на реальных инженерах. Например, блоки дашборда выполнены в свободной сетке и их можно легко дополнить новыми виджетами ниже. Либо, наоборот, убрать часть элементов — и при этом ничего не сломается. Дашборд также выполняет функцию навигатора по вложенным разделам. Например, нажав на статус, можно попасть на страницу со всеми статусами по данной батареи.

Самой сложной задачей было правильно отобразить графики и фильтры, так как основное время инженеры будут работать именно с ними. Мы тщательно проработали функциональность графиков, в том числе добавили ручные настройки отступов (Offsets), чтобы инженерам было легче просматривать различные значения в периодах.

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

Крайне важно подходить к таким проектам с опытом структуризации огромных массивов данных в таблицы и иные экранные формы.

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

После отработки MVP на практике с реальными батареями планируется расширить инструменты контроля безопасности батарей, добавить доступ для конечных пользователей систем BMS, чтобы они могли контролировать свои батареи удаленно.

— Евгений Черниговский, Global Software Manager