Как я сенсорную сеть изобретал ч.1
Сей сказ о том, что как я сенсорную сеть “изобретал”. Изобретал в кавычках потому что в общем-то технология эта уже достаточно зрелая, применяется в промышленности и придумывать что-то принципиально новое в ней сложно. Но у меня есть замечательная страсть к строительству велосипедов и собиранию граблей, поэтому в путь!
Что это и зачем нужно? Представим себе следующую задачу. Лето, активный сезон шашлыков и туристических прогулок. Все везде жгут костры, несмотря на особые режимы и драконовские штрафы. В жару, при высоком уровне пожарной опасности поджечь лес от обычного костра даже в трезвом состоянии не самая сложная задача, достаточно просто неправильно выбрать место под него или недоглядеть. И всё, начинается пал лесной подложки, который расползается по лесу и потушить его самостоятельно нет никакой возможности. А если на пути пала встретятся торфяные почвы, сухостой, это сильно усложняет ситуацию. Реагировать на каждый дымок в лесу пожарная охрана не может, у нее нет достаточного человеческого ресурса для этого. А если и реагируют то зачастую по месту прибытия оказывается группа мирно сидящих у костра туристов. Т е понять где реальный пожар а где контролируемый костер на начальных этапах почти невозможно. Ресурсы органов охраны лесов тратятся, леса продолжают гореть. А теперь представьте себе, по лесу была бы раскинута сеть устройств, которые работают годами без техобслуживания от солнечных панелей, собирают информацию о температуре, влажности воздуха и почвы, уровне CO2, скорости ветра, дисперсиях, могут подключать в случае необходимости тепловизор. Всё это связано между собой и через сетевые шлюзы отправляет данные в облако (или на edge севера). А там применив заточенные под эти цели ML модели, можно на выходе получить очень конкретный ответ на вопрос - а что это там за дым на горизонте? Это отдыхающие разожгли очередной костер на поляне на которой уже жарят шашлыки 50 лет без инцидентов, или пора ехать тушить реальный пал. Пример конечно утрированный, в реальности всё обстоит чуть более сложно, но чтобы уловить смысл зачем эти технологии нужны достаточен.
Такие требования и условия эксплуатации накладывают довольно серьезные требования на реализацию и организуют отдельный класс устройств - высоко автономные сетевые устройства работающие в условиях агрессивной внешней среды. Что это значит.
Электроэнергия это очень дефицитный ресурс. Всё что мы имеем в распоряжении это дай бог 5-15 вт солнечную панельку, которая кое-как проработав полдня, должна накопить достаточно энергии что что бы устройство проработало… Да бог знает сколько, может завтра снег пойдет и панелька окажется в сугробе. Соотвенно вся электронная база должна иметь минимальные паразитные токи. Тут счет идет на микроамперы, если использовать на в устройстве широко распространенные компоненты общего назначения, оно не проживет в таком режиме пары дней.
Устройство будет печься под зноем, заливаться дождями, и леденеть в тридцатиградусный мороз. Из этого следует что у него в составе должны быть компоненты которые поддерживают такие режимы эксплуатации (пламенный привет Li Ion аккумуляторам…).
Мы имеем дело с очень плохой радиосвязью и большими площадями. Наличие на пути сигнала леса, холмов/гор, представляют для него очень серьезное препятствие. Также нужно понимать что даже квадрат 10x10 км, это 100 кв. км площадей. И даже если повтыкать узлы через каждый километр, это непреодолимая дистанция для решений применяющихся в городской среде (к примеру в том же городском ZigBee). Поэтому мы вплотную сталкиваемся с вопросами усиления сигналов через внешние антенны и его трансляции на значительные дистанции.
Неустойчивость инфраструктуры. В таких жестких условиях эксплуатации любой узел в любой момент времени может приказать долго жить. Получить доступ к нему может оказаться задачей экспедиционного уровня (если это например узел находящийся на каком нибудь горном перевале или в глубокой тайге. Поэтому необходима предельная устойчивость сети к локальным травмам.
В общем-то с последнего пункта требований я и решил начать изобретать свой велосипед. Для решения таких задач применяются беспроводные сети с топологией - mesh. Такая сеть представляет из себя сетку, по которой строятся маршруты от одного узла до другого через промежуточные узлы, которые являюсь полноценными участниками сети, могут ретранлировать данные предназначенные для других узлов. Ядром такой сети является протокол маршрутизации - как ретрансляторы понимают, куда им направить пакет предназначенный для другого узла. Протоколов этих несколько, но для текущей задачи я выбрал AODV. Узел A желает понять куда (кому из ближайших нод, это называет шлюз) ему нужно передать пакет чтобы он достиг узла Б. Для этого он широковещательно закидывает в сеть пакет - узел Б откликнись. Получившие его ближайшие узлы, делают то же самое, соседние то же. И так пакет разлетается по сети пока не он не попадет на узел Б. К этому моменту информация о кратчайшем маршруте бедует уже храниться на промежуточных узлах (за счет прохождения поискового пакета). Всё что нужно сделать узлу Б, отдать в шлюз из которого пришел пакет сообщение - привет, я тут. Опять же очень упрощенное описание, есть много нюансов вроде TTL, hops, seen_packets, и прочее, но для понимания сути оно не нужно. Данный протокол был выбран мной на том основании, что в сенсорной сети которую я проектирую, практически нет подвижных узлов, а значит маршруты являются по большей части статичными. Они устаревают только тогда когда какой-то узел уходит с радиолинка. Поэтому AODV практически не дает служебного трафика в сравнении с другими типами маршрутизаций.
Кто-то может возразить что меш сеть это моветон для энергоэффективных устройств, много служебного трафика, большие пакеты. Но тут важно сделать уточнение. Меш сеть это уровень L3 модели OSI, а значит что она ничего не знает о физическом канале по которому проходят ее пакеты. За это отвечают уровни L2 (MAC) и L1 (PHY). На физический уровень я повлиять не особенно не могу. А вот уровень линка находится под моим полным контролем, а значит я могу управлять временем - когда и в каком количестве передаются данные. Таким образом я могу могу через управление трансивером сделать например heartbeat сеть, которая функционируют в определенные временные промежутки, например 55 секунд из 60 сеть молчит, 5 секунд происходит радиообмен. Или более серьезные решения вроде TDMA. Таким образом я получаю очень большое пространство маневра для работы над связкой L3-L2, что может дать приемлемый результат для меша в сенсорной сети.
И так, что было мной сделано на этом этапе. Бала сделана заготовка меш сети и оттестирована в эмуляторе (скришнот из него ниже), а именно реализовано:
Полная связность сети, пакеты могут проходить от узла к узлу в мультихоп режиме.
Полность релазиован протокол динамической маршрутизации AODV.
Реализован механизм beaconing, распространения данных об узлах по сети и соответственно поддержка node discovery и построения локальной топологии сети.
Базовое шифрование полезной нагрузки пакетов.
Механизм шлюзования или сопряжение с сетью другого рода.
Касательно аппаратной платформы под которую она предназначается. Всё это создается в инфраструктуре rust, embassy и embedded-hal. Соответственно основная шестерка продуктов которые активно участвуют в развитии этого стека - STM32, NRF, ESP32, TI, NXP, RPI. Я лично таргетируюсь на ESP32, как на платформу наиболее подходящая для быстрого прототипирования и на NRF, которая являются эталоном в сфере устройств с низким энергопотреблением.
С исходным кодом меш сети и эмулятора можно ознакомиться в моем GitHub.
