Очередное задание из курса Системной инженерии: рассказать об опыте архитектурной работы.
Для описания архитектурной работы продолжу описывать систему, о которой рассказывал в посте про опыт разработки концепции системы. Интересный момент в том, что система "железная", а не программная. Поэтому любопытно, как на описание лягут SoTA практики из домена разработки ПО. C другой стороны, Every company is now a software company, и без программного обеспечения, конечно, система не обходится, к чему я еще вернусь ниже по тексту.
О системе
Система предназначена для сбора данных с территориально распределенных датчиков в полевых условиях при условиях полного отсутствия инфраструктуры. Потому география сразу определяет как минимум два модуля: центральный пост и подсистема в поле. Рассуждаем дальше. Отсутствие инфраструктуры связи задает ограничение: следует использовать канал спутниковый связи VSAT. Это дорого и энергозатратно, поэтому для полевой части решаем разделить модуль коммуникации и непосредственно модули сбора данных с подключенными проводными датчиками. В этом случае у нас появляется возможность собирать на месте в поле и затем отправлять на центральный пост через спутниковый канал связи данные с нескольких точек сбора.
Есть разбиение на три модуля, есть требования к надежности и масштабируемости - далее принимаем важные решения по реализации системы. К ним относятся: выбор типа батарей для модуля коммуникации, выбор протокола взаимодействия между модулем коммуникации и модулями сбора данных (регистраторами).
Вот пример, каким мог бы выглядеть ADR по протоколу взаимодействия:
ADR: Выбор протокола коммуникации между модулем коммуникации и регистраторами.
- Ситуация: данные, собранные датчиками, подключенными к регистраторам, необходимо передать на модуль коммуникации. Пожелания: расстояние - до 5 километров, объем данных - до 1 килобайта, периодичность - от 1 раза в минуту до 1 раза в сутки. Мы выбираем между различными реализациями протокола WiFi, BLE, LoRa .
- Решение: Используем LoRa. Выгоды: a) Использование нелицензируемого диапазона радиочастотного спектра; b) Зона покрытия от 5 до 10 километров; v) Низкое энергопотребление по сравнению с остальными вариантами.
- Следствия: a) Теряем в скорости и объемах передаваемых данных. На регистраторах не будет возможности установить, к примеру, фотокамеры; b) Малый ассортимент COTS (Commercial off-the-shelf) решений.
Следствие b описанного архитектурного решения приводит к необходимости заказа кастомизированного решения у разработчика. Выделенный внутри проекта кейс "Разработка прототипа регистратора и блока управления" стал его, проекта, критически важной частью.
Архитектурные стили
В описании архитектурных стилей стоит выделить физический слой и слой приложений. Физически это, конечно, звезда, или hub-and-spoke.
На уровне приложений - монолит для контроллеров регистратора и event-driven архитектура EDA c MQTT-брокером на центральном пост.
Принципы взаимодействия
Принципы взаимодействия в нашей распределенной системе лучше всего описывает паттерн Parallel Saga: асинхронные коммуникации и конечная согласованность.
Развилки в паттерне Parallel Saga
Архитектурные характеристики
Договариваемся, что, что важными архитектурными характеристиками, вокруг которых будем строить проект, для нас будут: возможность самостоятельного восстановления после сбоя, устойчивость и возможность апгрейда любой части системы.
- Возможность восстановления / Recoverability: так как оборудование находится в удаленной точке, куда иногда доступ возможен только вертолетом, крайне важно, чтобы оборудование могло самостоятельно после сбоев восстанавливать свою работоспособность. Пример ситуации: полный разряд аккумуляторов модуля управления, вызванный плохой погодой и недостаточной выработкой электроэнергии солнечными панелями. После того, как погода восстановится, контроллер должен выйти из спящего режима, подзарядить аккумуляторы и затем запустить все подсистемы, включая спутниковый канал связи. Внимание команде разработки: контроллер надо будет в этот спящий режим ввести и приберечь для поддержания режима резерв заряда на аккумуляторах.
- Стабильность / Maturity: где возможно, добавляем избыточность и запас ресурсов. Спроектированная мощность солнечных панелей, емкость аккумуляторов, температурный режим оборудования, скорость передачи данных на проводных интерфейсах и беспроводных каналах связи - все подбираем с запасом.
- Возможность апгрейда / Upgradability: используем стандартные интерфейсы, способы крепления компонентов к конструктивам, COTS решения. Для воспроизводимости подробно документируем и описываем систему. Примеры документов: функциональные описания, ведомости оборудования, модели в виде расчетов Excel по энергообеспечению, стоимостные расчеты по поставке системы и времени ее эксплуатации.
Функция соответствия
Увы, с автоматизацией функций соответствия архитектурным решениям не так все просто, как у разработчиков ПО. Поэтому все проверки - вручную, через обсуждения в проектной команде с последующим документированием принятых решений.
Зато верификация удалась полноценная - зимний сезон прототип простоял на площадке перед нашей мастерской. Не напрасно - значениях нескольких пороговых значений в настройке регистратора в итоге заметно скорректировали.
Часть документа, описывающего процедуру верификации системы
Fast flow разработка
Команда разработки вписывается в two-pizza рекомендации, над проектом работают 4-5 человек. Плоская структура, почти все задачи выполняются без задержек.
Почти - потому что было два внешних "контракта". Первый - отработка ценовой части и закупа с коммерческим департаментов организации. И второй - работа с подрядчиком, разработчиком ПО контроллера. И если в первом случае процессы выстроены, то в работе с подрядчиком иногда не хватало опыта, чтобы проработать все риски и обговорить принципиальные моменты заранее. В процессе взаимодействия проявилось несколько подводных камней. Благо, что с той стороны тоже была небольшая и гибкая команда, договариваться и находить компромиссы удается.
Итог, уроки полученные
Что будем делать по другому при запланированном масштабировании этого проекта и в аналогичных проектах новых:
- Документировать архитектурные решения, обязательно описывая развилки. Надо пробовать механики, но для первых итераций формат ADR из книги "Software Architecture: The Hard Parts" кажется подходящим.
- С самого начала явным образом прописывать архитектурные характеристики и функции соответствия по ним. Думаем с сторону чек-листов, поддерживаемых этой же командой разработки.
- При работе с подобными проектами команде очень бы помог сотрудник, с мастерством в разработке программного обеспечения. Цель - перевести "неизвестные неизвестные" риски хотя бы в "известные неизвестные".
- Часть уроков описал также в предыдущем посте.