Привет, Хабр! Я системный архитектор Sitronics Group. Сегодня хочу представить вам кейс разработки платформы indoor-позиционирования Sitronics Locus, а также непредвиденного импортозамещения. Программными методами нам удалось добиться точности позиционирования до 1 метра. Думаю, всем разработчикам схожих решений и сотрудникам IT-департаментов на опасных производствах и в промышленности будет интересно почитать.
В ходе работы над проектом не все пошло по плану: часть импортного оборудования стала недоступна в последние месяцы и его экстренно пришлось разрабатывать и производить самостоятельно. Об этом ниже в тексте.
Кому нужно точное indoor-позиционирование?
Зачем для определения координат нужны радиопередающие устройства в помещениях? Ведь есть, например, GPS/Глонасс с помощью которого можно получать отличные результаты. Проблема в том, что сигнал от навигационных спутников значительно хуже проникает в закрытые помещения, а на некоторые, в том числе нижние и подвальные этажи зданий, не проникает вообще. К тому же, точность позиционирования от GPS фактически составляет до 15 метров.
Заказчиками выступают клиенты, которым важно с высокой точностью определять местоположение людей или грузов в помещении. В первую очередь, это опасные химические производства и горнодобывающая промышленность. Для угольных шахт есть даже национальные требования к безопасности, по которым точность позиционирования не может быть хуже, чем 20 м.
На опасных производствах необходима максимальная точность позиционирования, чтобы контролировать движение по маршрутам. Погрешность в несколько метров при ЧП здесь легко может стать фатальной.
Также перспективным направлением является установка систем indoor-позиционирования в местах массового скопления людей. Здесь главной целью является облегчение навигации пользователя, поэтому подразумевается установка приложения-трекера на телефон. Кроме удобства пользователя, это позволит автоматически выявлять аномалии в скоплениях людей, определять оптимальные маршруты и реагировать на конфликтные ситуации.
Какие технологии мы применяли
Платформа Sitronics Locus взаимодействует с оборудованием, работающим на технологиях UWB (Ultra-Wide Band) и BLE (BlueTooth Low Energy) . Обе технологии имеют свои плюсы и минусы.
К достоинствам BLE, как следует из названия, относится низкое энергопотребление, а также невысокая цена. Но при большом количестве маяков и точек Wi-Fi на единицу площади сильно возрастают помехи, из-за интерференционных помех могут «теряться» advertise-сообщения.
UWB отличается большей точностью позиционирования и высокой устойчивостью к помехам, в том числе к многолучевому распространению сигнала. Главным недостатком является высокое энергопотребление, что сказывается на особенностях монтажа – нужно вести провод. Также сигнал распространяется на более короткое расстояние, а выбор радиомодемов UWB сильно ограничен.
По сумме качеств, в которую входит и цена оборудования, технология BLE в настоящее время выигрывает. Хотя традиционно UWB считается более точной системой позиционирования, программными методами нам удалось достигнуть сопоставимого уровня точности, используя технологию BLE.
Мы добились этого благодаря использованию не одного, а сразу нескольких математических алгоритмов фильтрации и расчета координат, а также собственных наработок с учетом конкретных особенностей помещений заказчика. При этом в рамках одной зоны контроля мы можем использовать одновременно несколько вариантов расчета, что не свойственно для остальных разработчиков аналогичного ПО.
Исходя из вышесказанного, а также особенностей зоны контроля заказчика, мы подбираем правильные алгоритмы схемы размещения маяков и их точной настройки. Собранное вместе, это приводит к кратному увеличению точности позиционирования.
Алгоритмы позиционирования
1) Уровень взаимодействия с оконечным устройством. Включает приём данных, отправку данных в сторону оконечного устройства, а также реализацию протокола взаимодействия. Обеспечивает нормализацию получаемых данных к внутреннему формату.
2) Уровень первичной аппроксимации и/или агрегации входных данных (в случае, если мы получаем с трекеров «сырые» значения метрик маяков с большой частотой измерений). Обеспечивает различные механизмы по фильтрации входных данных — «скользящее среднее», «фильтр Калмана» и т. д. Это глубоко настраиваемый механизм, позволяющий оперативно дорабатывать новые фильтры под «объективную реальность» помещений и топологию маяков, а также комбинировать существующие фильтры.
3) Уровень позиционирования. На данном уровне реализовано несколько схем определения координат — триангуляция, дифференциальная латерация, паттерн контрольных точек (радио-карта помещения). В последнем случае используется вероятностный механизм анализа нахождения объекта (трекера) в заданной контрольной точке помещения. Также на этом этапе производится анализ барьеров (стен, оборудования и т. д.) при вычислении координат конечной точки нахождения объекта. Также система позволяет привязывать перемещение объекта к заданному маршруту внутри помещения.
Всех тонкостей о работе системы рассказать, понятное дело, не получится. Но если есть вопросы по этому разделу, задавайте в комментарии.
Архитектура решения
Система реализована по модульному принципу. Каждый из модулей представляет из себя некоторый законченный функционал. Фактически речь идёт об микро-сервисной архитектуре. Это позволяет легко обеспечивать масштабирование производительности и возможностей системы путём простого увеличения количества запущенных модулей необходимого функционала.
Также такое решение обеспечивает отказоустойчивость системы, так как в парадигме архитектуры системы, выход из строя одного из равнозначных модулей не приводит к отказу системы в целом. Задачи вышедшего из строя модуля просто примет на себя работающий модуль.
Определенный набор функций выполняется сервисом, запускаемым в docker-контейнере. При росте нагрузки таких контейнеров можно запустить много. Например, такими сервисами могут быть:
Сервисы, отвечающие за обработку входящих данных от маяков, трекеров или внешних датчиков;
Сервисы, отвечающие за работу фронтэнда и бекэнда;
Сервисы, отвечающие за взаимодействие с внешними IT-системами.
Продолжая тему отказоустойчивости, в системе предусмотрена возможность обеспечения «горячего» масштабирования, то есть масштабирования без остановки работы самой системы. По сути, вы просто запускаете параллельно нужное число необходимых модулей, и они автоматически включаются в работу системы. Это касается и вопросов увеличения производительности и вопросов отказоустойчивости системы.
Сложности при разработке
Основные сложности на этапе разработки были на уровне самой технологии позиционирования, которые включают в себя аппаратную, программную и технологическую составляющую.
Много времени ушло чтобы добиться идеального расположения маяков. Их должно быть ровно столько, чтобы обеспечить максимальную точность, так как большое количество маяков будет «забивать» сигнал друг друга. В зависимости от требуемой точности позиционирования, расставляются маяки, обычно на расстоянии 4-6 метров. Далее снимаются данные RSSI маяков в помещении с требуемой точностью, обычно с интервалом в 1-2 метра. Создается нечто вроде тепловой карты помещения с уровнями мощности маяков. После этого остается оптимизировать излучаемую мощность маяков и откалибровать их расстановку, чтобы получать оптимальные данные. Требуется большой опыт в подборе оптимальных алгоритмов позиционирования, в зависимости от топологии и загруженности помещений. Работа в этом направлении продолжается в постоянном режиме. Как следствие, дорабатываются и сами алгоритмы, и технологии развёртывания, и правила размещения оборудования. Здесь подробности раскрывать я, к сожалению, уже не могу.
Второй проблемой стало то, что не всё оборудование удовлетворяет требованиям как заказчика, так и нашей системы в целом. Честно говоря, оборудование не всегда отвечало и заявленному производителем функционалу. Было принято решение разработать свои трекеры, чтобы закрыть потребности текущих заказчиков. Прошивку для них наши инженеры написали на C. Это самый распространенный и оптимальный язык для прошивок микроконтроллеров.
В «лабораторных» условиях и при использовании протокола UWB мы добились точности сигнала в 30 сантиметров. Даже перемещение телефона на столе отчетливо фиксируется. Тем не менее, исходя из потребностей заказчика мы решили остановиться на BLE. Точности, которой мы добились от платформы, оказалось вполне достаточно.
Разработка собственной платформы
Разрабатывая платформу мы протестировали трекеры от нескольких производителей. Критерием отбора было качество сигнала, его стабильность, RSSI (Показатель уровня принимаемого сигнала), уровень сигнала в dbm. Большинство трекеров были отбракованны из-за слишком низкой частоты сканирования и обработки сигнала
Для нас и для заказчика критичным было обновление данных в реальном времени, то есть отправка сигнала раз в 300-700 миллисекунд. Такая точность нужна далеко не всем и не всегда, поэтому производители трекеров зачастую останавливаются на частоте отправки информации на сервер раз в 5-10 секунд.
Маяки многих вендоров отправлять сигнал раз в секунду могут, но с трекерами возникает проблема. По факту реального тестирования дает задержку в 3 секунды и выше, а временами задержка доходит до 20-30 секунд! Вероятно, это связано с энергопотреблением трекера в режиме сканирования и/или мощностью контролера в трекере. Если кто-то может дать экспертный ответ на этот вопрос, добро пожаловать в комментарии.
Трекер, с которым мы хотели работать изначально, по заявленным характеристикам был способен на частоту отправки раз в секунду. В реальности все оказалось не так радужно, как в описании производителя. Сигнал отправлялся, но с зависаниями и задержками. Данные на сервер отправлялись, действительно, раз в секунду, но данные по сигналам маяков в реальности обновлялись с большими задержками.
В итоге оказалось, что на рынке по совокупности этих характеристик подходящей модели просто нет. Мы приняли решение взяться за разработку. Платформа, которую мы выбрали, показала прекрасную совместимость с написанным нами ПО. Это позволило добиться стабильного сигнала с частотой отправки менее секунды, а также расширить спектр поддерживаемых решений. Добавилась поддержка Wi-Fi, LTE, акселерометр, фиксирующий падение. Также на нашем трекере есть модуль GPS, который позволяет осуществлять сквозное позиционирование (indoor/outdoor). Этого на старых трекерах также не было.
Другая проблема — время автономной работы. “Западный” трекер, который мы хотели использовать изначально, был разработан для работы в GPS-сетях. Кроме длительных интервалов обмена сигналом это приводило к быстрой потере заряда батареей. В условиях работы на производстве это приводило к тому, что заряда не хватало даже на одну рабочую смену: он садился за 5-6 часов. Для наших трекеров мы сразу подобрали батареи большей емкости, чтобы их можно было заряжать раз в два дня.
Собираемые данные
я
Систему можно интегрировать с API существующей цифровой инфраструктуры, например к ERP-системам, в том числе к популярной 1С. Из самого простого — так можно оценить, кто из сотрудников слишком много времени проводит в курилке. В более сложных сценариях, оценивается время нахождения в опасной зоне, оценка эффективности труда, следование заданным маршрутам.
По требованию заказчика мы интегрировали трекеры в систему безопасности предприятия. В случае, если датчики газа в помещении фиксируют опасные значения, сигналы передаются на сервер и трекеры рабочих, оказавшихся в зоне загазованности, вибрируют, предупреждая об опасности. По желанию заказчика можно установить датчики газа в сами трекеры.
Перспективы развития
Также мы уделяем большое внимание антенне трекера и ее диаграмме направленности. Прикладываем усилия, чтобы компенсировать то, что между маяками и трекером могут находиться люди или предметы, искажающие, поступающий от маячков сигнал.
Очень интересно будет прочитать ваше мнение о разработке. Возможно, сталкивались с подобным? Делитесь в комментариях.