Добрый день,  Меня зовут Алексей Бабушкин. Я СЕО независимого дизайн хауса электроники Hi-tech nation. Мы занимаемся контрактной разработкой продуктов в области интернета вещей. В свободное от работы время пилим свои решения с использованием беспроводной передачи данных и тестируем продуктовые гипотезы. Так родилась концепция независимой инфраструктуры для IIoT систем на основе mesh сети, которой я хочу с вами поделиться.  Промышленный Интернет вещей (IIoT) – это система объединенных компьютерных сетей и подключенных к ним производственных объектов со встроенными датчиками и программным обеспечением для сбора и обмена данными, с возможностью удаленного контроля и управления в автоматизированном режиме, без участия человека. При этом основной ценностью от внедрения IIoT является достижение максимальной результативности и экономичности производства за счет оптимизации его стоимости. Типовая архитектура таких систем состоит из следующих 3-х уровней: - оконечные периферийные устройства (датчики, контроллеры, исполнительные устройства и пр.). Этот уровень отвечает за сбор информации с устройств и за приведение её к стандартному виду, фильтрацию и локальное хранение; - сетевые шлюзы (роутеры, gateway станции и пр.). Они создают инфраструктуру для управления и обмена данными между устройствами посредством проводных или беспроводных протоколов (RS-485, Modbus, CAN, BLE, Wi-Fi, ZigBee, LoRa, и пр.). На этом уровне происходит предварительная обработка информации, выстраивается коммуникация с верхнем уровнем и предоставляется возможность настройки и управления через веб-приложения; - серверные решения (как правило в виде облачных платформ). Они обеспечивают удаленный доступ к системе и отвечают за более глубокий анализ собранных данных с использованием методов машинного обучения и за хранение больших объемов информации. На старте формирования нашей концепции мы решили проанализировать все три уровня и выделить их слабые стороны. На первом уровне главной головной болью является вопрос нахождения баланса между вычислительными возможностями оконечных устройств, их роли в работе всей системы и энергопотреблением. Современные сложные IIoT системы требуют большей автономности работы (в отрыве от сервера), быстрой реакции на команды (в части исполнительных устройств), дополнительной обработки информации, принятия решений на местах и простоты установки и настройки (желательно по принципу «plug and play»). При этом никто не отменял запрос на более низкую цену из-за большого количества подключенных устройств.  Слабые стороны второго уровня связаны, в первую очередь, с набирающим обороты переходом на беспроводную передачу данных. Радиоэфир становится все более перегруженным, поскольку большинство нелицензированных беспроводных технологий основаны на частоте 2,4 ГГц. Вскоре это станет одним из самых ограниченных ресурсов. Также стоит отметить неблагоприятную среду, в условиях реально работающих промышленных объектов, в которой приходится функционировать IIoT (большое количество металлоконструкций, высокочастотные помехи от работы производственного оборудования, Wi-Fi сети и пр.). Все эти факторы в совокупности могут привести к снижению качества работы IIoT системы или даже к полной остановке её работы. Чтобы избежать проблем со связью в будущем, современные беспроводные решения должны уметь сосуществовать с другими беспроводными технологиями, поддерживать динамическую смену каналов и работать на других частотах, например, 433 или 868 МГц. Что касается непосредственно сетевых шлюзов, то сегодня многие производители устанавливают в свое оборудование, например, в те же роутеры или gateway-станции, как можно более высокопроизводительное "железо". Делается это не для улучшения качество сигнала, а чтобы предоставить пользователю, дополнительный функционал управления, со сложными графическими интерфейсами, выводом статистики и т.д. В первую очередь они делают это для того, чтобы оправдать завышенную стоимость новинок. Во вторую — с целью улучшения пользовательского опыта при взаимодействии с продуктом. Понятно, что подобные действия продиктованы бизнесом. Возникает вопрос: зачем такое удорожание конечному пользователю. Такой подход противоречит основному принципу концепции промышленного интернета вещей, который гласит: стоимость решения не должна превышать ценность, которую пользователь получает в результате внедрения. Соответственно в интересах пользователей себестоимость отдельных компонентов должна не увеличиваться, а наоборот снижаться, как и стоимость обслуживания. Слабые стороны третьего уровня связаны в первую очередь с недостатками облачных решений. К таким можно отнести вопросы безопасности. Согласно исследованию Crowd Research, проведенному в 2019 году, около 90% специалистов по кибербезопасности обеспокоены безопасностью используемых облачных сервисов. В некоторых отраслях (например, оборонно-промышленный комплекс) службы безопасности на основе внутренних нормативных актов ограничивают передачу данных за периметр предприятия, что исключает возможность использования облачных решений в принципе. Ещё одним недостатком облачных сервисов считают большую степень зависимости от поставщиков услуг (так называемый «vendor lock-in»), которые помимо предоставления сервисов и инфраструктуры, потенциально получают неконтролируемое влияние на рынок и клиентов. Так же сюда можно отнести высокую стоимость предоставления подобного рода услуг. В ходе нашего исследования мы предположили, а что если, из архитектуры можно исключить элементы второго и третьего уровня, а весь их функционал оставить на стороне первого уровня оконечных периферийных устройств.  Все периферийные устройства мы, как  правило,  разрабатываем на основе микроконтроллера ESP32 разработанного компанией Espressif Systems. На наш взгляд, сегодня это один из лучших вариантов с точки зрения цена/качество/производительность на рынке. За вполне приемлемую цену мы получаем два ядра, аппаратные блоки шифрования, интегрированные Wi-Fi и Bluetooth модули, практически все периферийные интерфейсы и встроенный сопроцессор, на котором, посредством программирования на Assembler, можно весьма эффективно решать различные фоновые задачи в режиме ультранизкого потребления. Пришлось, конечно, практически полностью переписать китайский SDK, но сейчас не об этом.             Беспроводную передачу данных мы решили строить на основе разработанной нашими инженерами mesh-cети. Q-mesh — это сетевой протокол, построенный поверх протоколов IEEE 802.11n, IEEE 802.11lr и Bluetooth, позволяющий объединять многочисленные устройства, распределенные по большой площади как внутри, так и снаружи помещения в единую беспроводную локальную сеть. Сеть работает на частотах 2.4 ГГц и 868 МГц или 433 МГц. Частота 2.4 ГГц используется как основная, а частота 868 МГц или 433 МГц — как дополнительная, для повышения надёжности, а также для маршрутизации между удаленными сегментами сети. Наше решение отличается от аналогичных беспроводных решений тем, что не требует применения выделенной gateway станции. Любое из оконечных устройств, имеющих гарантированное питание, может полноценно взять на себя её функции. Выбор такого устройства происходит автоматически. Как правило, им становится то, у которого лучше условия обмена информацией. Например, самый низкий уровень помех, наибольшее число доступных устройств и т.д. Если устройство, выступающее в роли ведущего, по каким-либо причинам выходит из строя, то в течение нескольких секунд будет назначено другое. Замена происходит незаметно для пользователя. Все устройства оснащены достаточным объемом памяти, в которой постоянно накапливаются данные о работе устройства и, в некоторых случаях о состоянии внешней среды. Анализ этих данных позволяет не только эффективно использовать оборудование, но, также, в некоторой мере, прогнозировать поведение устройств и сети в целом, что обеспечивает постепенную автоматическую оптимизацию системы. Дополнительная экономия сетевого трафика и памяти в наших устройствах достигается за счет того, что исключается повторное хранение и передача одинаковых данных. Например, при накоплении данных о температуре опрос датчика происходит периодически, но в массив данных его показания, вместе с меткой времени, попадают только в случае их отличия от предыдущих. Таким образом, если за сутки температура объекта не изменялась, то и в памяти хранится всего один отсчет. В процессе работы такой системы может генерироваться значительный объем данных. Для их хранения, обработки и маршрутизации в системе предусмотрены сервера, построенные на микро сервисной архитектуре, которая позволяет распределять нагрузки. Это делает систему более устойчивой и надежной. Сервера обеспечивают передачу данных между удаленными ячейками mesh-сети, синхронизируют данные между собой и обновляют данные у пользователей в реальном времени. Устройства и пользователи подключаются к системе через веб-сокеты, что обеспечивает быстрый отклик устройств на команды и быстрое предоставление свежих данных пользователям. Все вычисления осуществляются внутри системы распределенным способом, в зависимости от источника питания. Что имеется в виду? Если одному из устройств с автономным питанием необходимо произвести сложные и энергозатратные вычисления, то система перенаправит эту задачу ближайшему устройству, имеющему постоянное сетевое питание. Такой подход обеспечивает приемлемый срок автономной работы для устройств с автономным питанием и ускоряет процесс принятия решения. Элементы такой системы с автономным питанием рассчитаны на длительную работу без обслуживания. С целью экономии энергии эти устройства большую часть времени проводят в спящем режиме и, соответственно, не имеют постоянной доступности. Для эффективной работы с такими устройствами предусмотрена их виртуализация. Реализуется она следующим образом: на одном из ближайших, в смысле топологии и доступности, устройств, имеющем постоянное питание, создается виртуальная копия реального устройства и вся работа других устройств системы ведется уже с ним. Реальное же устройство по собственной инициативе общается со своим двойником и синхронизирует его состояние с реальным. Таким образом, например, пользователю нет необходимости ждать, когда проснется удаленный датчик, работающий по технологии NB-IoT, чтобы передать ему новые настройки. Он просто настраивает его цифрового двойника, и все настройки будут загружены по назначению во время очередного сеанса связи. В отличие от традиционных сетей, например, Wi-Fi, Q-mesh поддерживает динамический выбор канала, основываясь на информации о загрузке каналов, интенсивности и спектре помех. Это способствует более устойчивой работе системы в условиях загруженного радиоэфира. Нагрузка на различные участки системы может значительно меняться с течением времени. Это может вызывать заметные задержки в работе устройств. Для исключения, или, по крайней мере, для уменьшения вероятности таких перегрузок предлагается анализировать статистику по распределению трафика и реализовать предиктивную маршрутизацию. Таким образом, маршруты будут строиться с учетом ожидаемой нагрузки.  Скорость передачи данных в диапазоне 2.4 ГГц составляет от 0.25 до 112 Мбит/сек, а время задержки передачи от точки к точке от 5 до 50 миллисекунд.  Скорость передачи данных в диапазоне 868 МГц составляет 1 Мбит/сек.  Передача данных в диапазоне 433 МГц происходит на скорости 0.25 Мбит/сек. Безопасность сети обеспечивается применением современных алгоритмов шифрования (AES с длиной ключа 192 или 256 бит) с использованием аппаратной поддержки. Трафик туннелируется между сервером и устройством или между парой устройств и шифруется отдельным ключом. Ключ генерируется из шума радиоэфира.  Вся система после включения настраивается автоматически, а в процессе работы перестраивается и подстраивается под внешнюю обстановку: расположение соседних устройств, уровень сигнала, загрузка радиоэфира. Процесс первоначальной настройки занимает от 3 до 60 секунд в зависимости от размера сети и заданной конфигурации. При выходе одного или нескольких устройств из строя перестроение системы происходит за время до 10 секунд. Управление и настройка такой системы происходит через веб-интерфейс, который может раздавать любое из устройств системы выполняющего роль сетевого шлюза (gateway станции). Учитывая ограниченные вычислительные возможности периферийных устройств, поддержку веб-интерфейса они отдают в виде скрипта на сторону браузера смартфона, ПК или планшета, которые, располагают куда большей производительностью. Так как это происходит только в момент, когда пользователь взаимодействует с системой, то нагрузки на принимающую сторону не значительны. В свою очередь, для того, чтобы устройство проснулось и передало необходимые данные дальше, ему также не нужны большие вычислительные ресурсы. Поэтому мы можем использовать более дешевые и менее производительные микроконтроллеры, создавая для пользователя дополнительную ценность. В дополнение к этому, решения для браузеров легко интегрировать, так как они работают практически с любой ОС: Linux, Mac, Android и т.п. Таким образом, на том же ESP32 с 256 Кбайт оперативной памяти, мы можем запускать веб-приложения практически, любой сложности и с любой графикой, производить сложные вычисления на стороне веб-приложения с приемлемой скоростью отображения.  Это возможно потому, что основная обработка происходит на стороне значительно более производительного оборудования и, поэтому, запас вычислительных ресурсов у нас практически безграничный.  В сочетании с преимуществами децентрализации, разработанной нами mesh-сети, такой подход позволяет нам разворачивать локально закрытую и самодостаточную инфраструктуру для реализации концепции промышленного интернета вещей, используя только оконечные устройства. Такая инфраструктура может обходиться без участия внешнего сервера, предоставляя при этом все необходимые сервисы. Что в свою очередь позволяет выстроить независимую от инфраструктурных операторов систему, подконтрольную только конечному пользователю, сокращает издержки на обслуживание и повышает безопасность и сохранность данных. Не смотря на то, что мы частично уже использовали подобный подход при реализации реальных проектов, к данной концепции мы все еще относимся как к гипотезе. Поэтому не стесняйтесь в комментариях, бросайте в нас камни, стучитесь в друзья и задавайте вопросы.