Мы продолжаем рассказывать о компаниях-разработчиках решений (ISV). В этом выпуске технический директор компании «ИНПРОСИСТЕМ» AlexandrSurkov рассказывает об опыте разработки архитектуры охранной IoT-системы СеСМИК.

Многие считают, что понятие «Интернета вещей» неразрывно связано с сетью, которой мы пользуемся каждый день. Можно представить себе картину, где множество устройств, объединенных в единое целое через глобальную сеть, обмениваются данными между собой и серверами и создают цифровую картину мира. В данной статье я расскажу о том, как мы делали систему, объединяющую сотни датчиков.


Понятие «интернет» стоит рассматривать гораздо шире. В данном случае это общая для устройств сеть. Она может содержать 10 устройств, а может и 10 000. Может быть проводная, а может быть беспроводная. Может располагаться в одной комнате, а может охватывать несколько стран. Все зависит от задач, которые ставятся перед системой.

При этом создание даже небольшой сети устройств сопровождается множеством трудностей.

Постановка задачи

Нам была поставлена задача по разработке системы охраны периметра. Периметр — это забор, окружающий некоторый объект. Его длина ничем не ограничена.

Система создавалась с нуля. К моменту начала проектирования существовал прототип датчика, способного собирать колебания периметра, проанализировав которые, можно было четко определить факт преодоления или разрушения забора. Опытным путем мы определили, что датчики нужно ставить примерно через каждые 10 метров.

Кроме датчиков планировались еще управляющие устройства с реле и управляемые устройства с «сухим контактом». Система должна работать в уличных условиях при широком диапазоне температур и погодных явлений.

Итак, имеется:

• 3 типа устройств;
• Минимум 100 устройств на километр;
• Количество километров не ограничено;
• Система должна иметь уличное исполнение.

Сразу можно выделить главные вопросы по архитектуре:

• Организация передачи данных и питания;
• Распределение потоков информации: где и как анализировать данные;
• Безопасность решения: какие протоколы использовать;
• Как управлять таким количеством устройств.

Общая схема решения

Clemens Vasters написал прекрасную статью о том, с чем сталкивается разработчик системы «Интернета вещей». Эти же проблемы пришлось решать и нам.

Многие решения диктовались ГОСТами и другими требованиями к таким системам. Но многое пришлось придумывать самим.

Сперва нужно было понять, как распределить информационные потоки в системе. Для анализа колебаний использовалась как временная, так и частотная составляющая. Диапазон частот от 0 до 500 герц. Значит, замеры нужно делать 1000 раз в секунду. Каждое измерение делаются по 3 осям по 10 бит на каждую.
Итого 3*10*1000 = 30 килобит в секунду только от одного датчика. На километр (100 датчиков) это уже 3 мегабита.

Передать то эти данные можно, но как их обрабатывать? Периметр в 10 км давал бы уже 30 мегабит данных в секунду. Получается, что нагрузка на сервер возрастает с увеличением количества устройств.

Было принято решение, что каждый датчик будет обрабатывать данные сам и отдавать только факты тревог. Это значительно снизило объем данных и распределило вычислительную нагрузку.

Организация сети была выбрана проводная из-за того, что беспроводная требует батареи. Так как система у нас реального времени, то срок жизни батареи будет очень маленький. Кроме того, отрицательные температуры сильно уменьшают емкость питающих элементов. Да и заглушить беспроводную связь относительно легко, а это уже является очень существенным недостатком для системы безопасности.

ГОСТы запрещают прокладывать по ограждению 220В, поэтому “питаться” наши устройства будут от постоянного напряжения.

В качестве архитектуры сети мы выбрали шину. Это позволило не тянуть провод к каждому датчику.

Однако шина накладывает ограничение на длину сети и количество устройств. Поэтому было введено новое устройство: шлюз. Он имеет 2 шины, занимается менеджментом устройств и трансляцией данных на сервер и от сервера. Также он занимается контролем параметров питания и окружающей среды.
Таким образом с сервера снимается еще одна большая нагрузка: менеджмент датчиков.

Кроме того, такой модульный подход с распределенной вычислительной нагрузкой позволяет объединять в общую систему очень большое число датчиков без существенного увеличения требований к серверу.

Остальные исполнительные устройства так же, как и датчики, подключаются к шине.

В итоге получается такая схема:



Выбор протоколов и способов взаимодействия

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

• команда от сервера — ответ серверу;
• асинхронное событие от устройства к серверу.

Команды используются для изменения состояния устройства и его настройки. События генерируются в случае, если у устройства появляется информация для сервера (например, тревога от датчика)

Со стороны сервера шлюз считается таким же исполнительным устройством, как и все остальные, так как он, помимо менеджмента устройств на шине, занимается еще отслеживанием параметров питания и температуры.

В качестве шины выбор стоял в основном между RS485 и CAN. Только эти два стандарта позволяли подключить множество устройств на достаточно больших расстояниях.

В результате анализа мы предпочли CAN. Параметры сети выбрали следующие:

• Максимум 500 метров;
• Максимум 100 устройств;
• Скорость 50 кбит.

По нашему мнению, это являются оптимальным балансом скорости, плотности устройств и длины сети для нашей системы.

В шлюзе используется микроконтроллер с двумя драйверами CAN на борту, что позволило сделать 2 фланга и закрыть одним шлюзом 1 км.

У CAN есть еще и другие преимущества: помехоустойчивость, разрешение коллизий и гарантированная доставка пакетов адресату. Кроме того, он имеет достаточно сильную модель диагностики ошибок в сети.

Однако CAN представляет собой только канальный уровень сети. Для непосредственной работы с ним существует множество протоколов более высокого уровня. Самый известный из них — CANOpen.

Изучив различные варианты, мы пришли к выводу, что ни один из протоколов нам не подходит. Некоторые слишком сложны для нашей задачи, некоторые требуют отчислений за использование, а некоторые не поддерживают то, что хотелось бы реализовать.

А реализовать хотелось систему по принципу PlugAndPlay:

• Подключение и отключение устройств без отключения питания;
• Автоматическая определение изменения конфигурации системы;
• Система должна начать работать сразу после сборки

.

В итоге нам удалось сделать то, что было задумано, написав свой простой, но достаточно мощный протокол. Так как речь идет о маленькой пропускной способности шины и небольшой вычислительной мощности микроконтроллеров, то тип протокола был выбран байтовый. Из-за оптимизации пропускной способности протокол получился достаточно сильно связанным с CAN, но нам удалось сделать его теоретически переносимым на другие стандарты.

Протокол позволяет:

• обнаруживать “на лету” подключенные устройства;
• обнаруживать отключение устройств;
• работать в режиме запрос-ответ;
• передавать асинхронные события;
• передавать потоковые данные с устройства.

Наладив обмен между устройствами и шлюзом, осталось разобраться с сервером.

Шлюз имеет выход Ethernet. Это наиболее универсальная технология передачи данных. Сеть может быть организована как угодно: оптическими каналами, беспроводными каналами, обычной витой парой — при этом мы всегда сможем подключиться к этой сети, используя оптические конвертеры и точки доступа. Это позволяет заказчику проектировать инфраструктуру сети любой сложности и протяженности.

Передача данных была организована с помощью Сокетов Беркли на базе TCP/IP. Такое решение позволяет серверу гарантированно получать информацию от любого датчика и не зависеть от программных платформ. Протокол поверх TCP/IP мы разработали так же свой. Он тоже байтовый, для оптимизации работы на стороне микроконтроллера. У байтовых протоколов есть большой минус: сложность с последующей модификацией. Однако текстовый протокол для микроконтроллерного устройства слишком избыточен.

Самым сложным с точки зрения разработки ПО оказался сервер. Мы реализовали асинхронную многопоточную модель взаимодействия, что позволило получить “живую” систему, мгновенно реагирующую на любые изменения. Подключение нового устройства, потеря связи со шлюзом, тревога от датчика, открытие крышки на устройства — любое событие в системе мгновенно регистрируется, даже если они происходят одновременно.

В итоге мы получили гибкую модульную систему, управляемую через единый центр — сервер. Он так же имеет свой протокол, позволяющий подключаться к нему и получать события в системе. Это позволяет использовать нашу систему как составную часть большого комплекса и масштабировать ее практически до бесконечности.

Вопросы безопасности

С безопасностью системы оказалось все достаточно просто. Дело в том, что все сети, которые находятся на охраняемых объектах, сами по себе являются охраняемыми объектами. Таким образом все сети, с которыми работает система, становятся “доверенными”.

Кроме того, “цена” взлома информационной системы охраны гораздо выше, чем другие способы преодоления. Иными словами, опытный нарушитель найдет более простой способ преодолеть заграждение, а менее опытный просто не сможет взломать систему.

Поэтому никакими особыми способами защиты информации мы не пользовались, ограничившись только базовыми принципами.

Что дальше?

Несмотря на то, что система уже сформировалась, мы продолжаем активно ее развивать и искать новые способы применения.

Одним из направлений развития системы является машинное обучение. Используя эти алгоритмы, можно отфильтровывать регулярные помехи, такие как шум от грузовиков поездов и самолетов. В экспериментах для этого направления нам очень сильно помогает Azure Machine Learning. Он содержит множество готовых решений для машинного обучения, что позволяет достаточно быстро получить результаты.
Анализ колебаний ограждения далеко не единственный способ использования технологий, заложенных в нашу систему. Контроль вибраций высотных зданий, трубопроводов и газопроводов, хрупких грузов, вибродиагностика турбин и подвижных частей различных конструкций — далеко не полный список возможностей.

Количество датчиков в таких системах будет только возрастать и тут практически не минуем переход к облачным системам на объектах, для которых не запрещено использование интернета.

Очень перспективными нам кажутся новые технологии IoT от Microsoft. Единая платформа Windows теоретически способна сэкономить много времени, так как можно написать общий для разных аппаратных платформ код.

А для обработки данных использовать Azure IoT Suite. По заявлениям разработчиков, он содержит в себе инструменты, позволяющие не только объединять и управлять множеством IoT устройств, но и обрабатывать большие объемы данных с них. Это мы и собираемся проверить в ближайшем будущем.

Заключение

Когда мы начинали разработку системы, понятие “Интернета вещей” еще не набрало такой популярности. Опыта было немного, со многими вещами мы столкнулись в первый раз. Сейчас, когда об этой концепции много пишут и рассказывают, стало ясно, что выбран правильный путь.

Работа была сложной и долгой. Создание первой коммерческой версии системы заняло примерно 3 года. Первый ушел на разработку инженерных образцов отдельных устройств. Еще год был потрачен на разработку системы в целом. Третий год шла доводка и отладка.

За это время мы получили огромный опыт в решении разнообразных инженерных задач. Причем подбор корпусов, кабельной продукции, организация производства и логистики отняли не меньше сил, чем разработка самой системы.

Сейчас система смонтирована и работает на многих объектах в России и зарубежом. Самый крупный из них состоит из нескольких периметров общей протяженностью более 15 км. В проектировании находятся и более масштабные объекты.

Более подробную информацию можно получить на сайте системы.