Архитектура Iot-Решения На Реальном Примере

Продолжаем говорить о компаниях-разработчиках решений (ISV).
В этом выпуске технический директор компании «ИНПРОСИСТЕМ» АлександрСурков рассказывает об опыте развития архитектуры Система безопасности SeSMIC IoT .
Многие люди полагают, что концепция "Интернет вещей" неразрывно связан с сетью, которую мы используем каждый день.
Можно представить картину, когда множество устройств, объединенных в единое целое через глобальную сеть, обмениваются данными между собой и серверами и создают цифровую картину мира.
В этой статье я расскажу о том, как мы сделали систему, объединяющую сотни датчиков.
Понятие «Интернет» следует рассматривать гораздо шире.
В данном случае это общая сеть для устройств.
Он может содержать 10 устройств, а может и 10 000. Он может быть проводным, а может быть беспроводным.
Он может располагаться в одном помещении, а может охватывать несколько стран.
Все зависит от задач, которые поставлены перед системой.
В то же время создание даже небольшой сети устройств сопровождается множеством сложностей.

Постановка задачи
Нам была поставлена задача разработать систему охраны периметра.
Периметр – это ограждение, окружающее какой-либо объект. Его длина не ограничена.
Система создавалась с нуля.
К моменту начала проектирования существовал прототип датчика, способного улавливать вибрации периметра, проанализировав который можно было однозначно определить факт преодоления или разрушения ограждения.
Опытным путем мы определили, что датчики необходимо устанавливать примерно через каждые 10 метров.
Помимо датчиков планировались также устройства управления с реле и управляемые устройства с «сухим контактом».
Система должна работать на открытом воздухе в широком диапазоне температур и погодных условий.
Итак, есть:
3 типа устройств;

Минимум 100 устройств на километр;

Количество километров не ограничено;

Система должна быть совместима с внешним оборудованием.

Сразу можно выделить основные вопросы, касающиеся архитектуры:
Организация передачи данных и электроснабжения;

Распределение информационных потоков: где и как анализировать данные;

Решение безопасности: какие протоколы использовать;

Как управлять таким количеством устройств.

Общая схема решения
Клеменс Вастерс написал отличная статья о том, с чем сталкивается разработчик системы Интернета вещей.
Нам пришлось решать те же проблемы.
Многие решения были продиктованы ГОСТами и другими требованиями к таким системам.
Но многое нам пришлось придумать самим.
Сначала нужно было понять, как распределять информационные потоки в системе.
Для анализа колебаний использовались как временная, так и частотная составляющие.
Диапазон частот от 0 до 500 герц.
Это означает, что измерения необходимо проводить 1000 раз в секунду.
Каждое измерение производится по 3 осям по 10 бит каждая.
Итого 3*10*1000 = 30 килобит в секунду только от одного датчика.
На километр (100 датчиков) это уже 3 мегабита.
Передавать эти данные можно, но как их обработать? Периметр в 10 км уже обеспечит 30 мегабит данных в секунду.
Оказывается, нагрузка на сервер увеличивается с количеством устройств.
Было решено, что каждый датчик будет сам обрабатывать данные и сообщать только о тревожных фактах.
Это существенно сократило объем данных и распределило вычислительную нагрузку.
Организация сети была выбрана проводной, поскольку для беспроводной связи требуется аккумулятор.
Поскольку наша система работает в режиме реального времени, время автономной работы будет очень коротким.
Кроме того, отрицательные температуры сильно снижают емкость силовых элементов.
Да и глушить беспроводную связь относительно легко, а это уже очень существенный недостаток для системы безопасности.
ГОСТы запрещают прокладывать 220В вдоль забора, поэтому наши устройства будут «питаться» от постоянного напряжения.
В качестве сетевой архитектуры мы выбрали шину.
Это позволило не тянуть провод к каждому датчику.
Однако шина накладывает ограничение на длину сети и количество устройств.
Поэтому было введено новое устройство: шлюз.
Он имеет 2 шины, управляет устройствами и передает данные на сервер и с него.
Он также контролирует параметры питания и окружающей среды.
Это снимает с сервера еще одну большую нагрузку: управление датчиками.
Кроме того, такой модульный подход с распределенной вычислительной нагрузкой позволяет объединить очень большое количество датчиков в общую систему без существенного увеличения требований к серверу.
Остальные исполнительные устройства, как и датчики, подключаются к шине.
В результате получается следующая диаграмма:

Выбор протоколов и методов взаимодействия Теперь нужно было решить, как именно будут передаваться данные.
Каждое устройство в системе участвует в 2 видах обмена:
команда от сервера – ответ серверу;

асинхронное событие от устройства к серверу.

Команды используются для изменения состояния устройства и его настройки.
События генерируются, если на устройстве есть информация для сервера (например, сигнал тревоги от датчика) Со стороны сервера шлюз считается таким же исполнительным устройством, как и все остальные, поскольку помимо управления устройствами на шине он также контролирует параметры электропитания и температуры.
В качестве шины выбор был в основном между RS485 И МОЖЕТ .
Только эти два стандарта позволяли подключать множество устройств на достаточно большие расстояния.
В результате анализа мы отдали предпочтение CAN. Выбранные параметры сети следующие:
Максимум 500 метров;

Максимум 100 устройств;

Скорость 50 кбит.

На наш взгляд, это оптимальный баланс скорости, плотности устройств и длины сети для нашей системы.
В шлюзе используется микроконтроллер с двумя CAN-драйверами на борту, что позволило сделать 2 фланга и покрыть одним шлюзом 1 км.
У CAN есть и другие преимущества: помехоустойчивость, разрешение коллизий и гарантированная доставка пакетов получателю.
Кроме того, он имеет достаточно сильную модель диагностики сетевых ошибок.
Однако CAN представляет собой только канальный уровень сети.
Существует множество протоколов более высокого уровня для работы напрямую с ним.
Самым известным из них является CANOpen .
Изучив различные варианты, мы пришли к выводу, что ни один из протоколов нам не подходит. Некоторые из них слишком сложны для наших целей, некоторые требуют отчислений за использование, а некоторые не поддерживают то, что мы хотели бы реализовать.
Но мне хотелось реализовать систему по принципу Подключи и играй :
Подключать и отключать устройства, не отключая питание;

Автоматическое обнаружение изменений конфигурации системы;

Система должна начать работать сразу после сборки.

.
В результате нам удалось сделать задуманное, написав собственный простой, но достаточно мощный протокол.
Поскольку речь идет о низкой пропускной способности шины и низкой вычислительной мощности микроконтроллеров, тип протокола был выбран байтовый.
За счет оптимизации пропускной способности протокол оказался довольно тесно связан с CAN, но нам удалось сделать его теоретически переносимым на другие стандарты.
Протокол позволяет:
обнаруживать подключенные устройства «на лету»;

обнаружить отключение устройства;

работа в режиме запрос-ответ;

передавать асинхронные события;

передавать данные с устройства.

Наладив обмен между устройствами и шлюзом, осталось разобраться с сервером.
У шлюза есть выход Ethernet .
Это наиболее универсальная технология передачи данных.
Сеть может быть организована как угодно: оптические каналы, беспроводные каналы, обычная витая пара – и мы всегда можем подключиться к этой сети с помощью оптических преобразователей и точек доступа.
Это позволяет заказчику спроектировать сетевую инфраструктуру любой сложности и протяженности.
Передача данных была организована с помощью Розетки Беркли на основе TCP/IP. Такое решение позволяет серверу надежно получать информацию от любого датчика и не зависеть от программных платформ.
Мы также разработали собственный протокол TCP/IP. Он также основан на байтах, чтобы оптимизировать работу на стороне микроконтроллера.
У байтовых протоколов есть большой недостаток: сложность с последующей модификацией.
Однако текстовый протокол слишком избыточен для микроконтроллерного устройства.
Сервер оказался самым сложным с точки зрения разработки ПО.
Мы реализовали асинхронную модель многопоточного взаимодействия, что позволило получить «живую» систему, мгновенно реагирующую на любые изменения.
Подключение нового устройства, потеря связи со шлюзом, тревога от датчика, открытие крышки устройства – любое событие в системе моментально фиксируется, даже если они происходят одновременно.
В результате мы получили гибкую модульную систему, управляемую через единый центр – сервер.
Он также имеет собственный протокол, который позволяет подключаться к нему и получать события в системе.
Это позволяет использовать нашу систему как неотъемлемую часть большого комплекса и масштабировать ее практически до бесконечности.

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

Что дальше?
Несмотря на то, что система уже сформирована, мы продолжаем активно ее развивать и искать новые пути применения.
Одним из направлений развития системы является машинное обучение.
Используя эти алгоритмы, можно фильтровать обычный шум, например шум грузовиков, поездов и самолетов.
Машинное обучение Azure очень помогает нам в экспериментах в этой области.
Он содержит множество готовых решений для машинного обучения, что позволяет довольно быстро получать результаты.
Анализ вибраций ограждения – далеко не единственный способ использования технологий, заложенных в нашу систему.
Вибромониторинг высотных зданий, трубопроводов и газопроводов, хрупких грузов, вибродиагностика турбин и движущихся частей различных конструкций – это далеко не полный перечень возможностей.
Количество датчиков в таких системах будет только увеличиваться, а переход к облачным системам на объектах, для которых не запрещено использование Интернета, практически неизбежен.
Новые технологии Интернета вещей от Microsoft кажутся нам очень перспективными.
Одна платформа Windows теоретически может сэкономить много времени, поскольку вы можете писать код, общий для разных аппаратных платформ.
А для обработки данных используйте Azure IoT Suite. По словам разработчиков, он содержит инструменты, которые позволяют не только объединять и управлять множеством IoT-устройств, но и обрабатывать с них большие объемы данных.
Это мы и собираемся проверить в ближайшее время.

Заключение
Когда мы приступили к разработке системы, концепция «Интернета вещей» еще не приобрела такой популярности.
У нас было мало опыта; со многими вещами мы столкнулись впервые.
Теперь, когда об этой концепции много написано и сказано, стало ясно, что путь выбран правильный.
Работа была трудной и долгой.
Создание первой коммерческой версии системы заняло около 3 лет. Первый пошел на разработку инженерных образцов отдельных устройств.
Еще год был потрачен на разработку системы в целом.
Третий год шла доводка и отладка.
За это время мы накопили большой опыт решения различных инженерных задач.
Причем подбор корпуса, кабельной продукции, организация производства и логистика потребовали не меньших усилий, чем разработка самой системы.
Сейчас система установлена и работает на многих объектах в России и за рубежом.
Самый крупный из них состоит из нескольких периметров общей длиной более 15 км.
Более крупные проекты также находятся на стадии планирования.
Более подробную информацию можно получить по адресу системный сайт .