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

Задача

Мы в Synergy Team разрабатываем и выпускаем промышленные контроллеры. Они предназначены для учета ресурсов, управления объектами энергетики и других применений, которые принято называть Интернетом вещей (IoT). Часто нашим заказчикам не нужны просто контроллеры. Им нужно комплексное решение, включающее систему управления.

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


В этом посте мы ограничились классом задач, когда IoT контроллеры напрямую подключаются к управляющей системе (Directly-connected IoT). Итак, наша задача разработать систему управления, которая должна:

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

Если система состоит из большого количества объектов и/или выполняет ответственные задачи, она дополнительно должна:

• постоянно контролировать наличие связи с объектами,
• собирать статистику по своей работе,
• обновлять настройки и программное обеспечение контроллеров (по запросу);
• иметь защиту от несанкционированного доступа. Для государственных и крупных частных компаний система также должна соответствовать законодательству по работе с объектами критической информационной инфраструктуры (КИИ). В частности, требованиям 187-ФЗ, ФСБ, ФСТЭК, приказам Минкомсвязи и т.п.

Управление без выделенного сервера

Для нескольких объектов задача просто решается с управлением по GSM сети посредством SMS команд или звонков. Этот подход был популярен в начале 2010х, а его плюсы и минусы описаны, например, здесь. Для большинства серьезных систем этот подход на сегодня теряет актуальность.


Чуть более сложным является ручное управление контроллерами по выделенным IP через WEB или командную строку (CLI). Контроллеры должны быть постоянно включены в сеть, иметь статические белые или серые IP адреса. Альтернативно можно использовать динамические IP c привязкой к статическим доменным именам по технологии DynDNS или аналогичным. Это неплохо работает, если объектов мало и к надежности не предъявляется особых требований.

Недостатки:

• неудобно, если WEB страницы от всех контроллеров нельзя разместить на экране(ах) диспетчера;
• большая абонентская плата за статические IP адреса;
• сложно настроить неподготовленным пользователям, когда устройства расположены за NAT;
• долго согласовывать с оператором связи выделение пула адресов и доступ в IP подсеть. Например, для организации GSM APN у нас уходили недели;
• неудобно, поскольку диспетчеру необходимо анализировать данные на мониторе глазами;
• высокий риск несанкционированного доступа к контроллерам при использовании сетей общего пользования (Интернет).

Для быстрых демонстраций, контроля за несколькими объектами достаточно использовать управление по IP, SMS или телефонным звонкам.

Здесь мы не рассматривали ситуацию, когда на одном и том же компьютере работает диспетчер и установлена система управления, поскольку считаем ее вырожденным случаем следующего пункта.

Управление через выделенный сервер

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

Если контроллеры передают данные только в направлении сервера, например, счетчики воды или простейшие навигационные устройства (трекеры), достаточно однонаправленного соединения. При этом контроллерам достаточно знать IP сервера.

В нашей задаче для обновления ПО контроллера и передачи команд нужен двухсторонний обмен данными. Для организации такого обмена необходимо:

• периодическое считывание настроек или команд с сервера по инициативе контроллера (допустимо, если не нужна быстрая реакция на команды), либо
• использование на контроллерах статических IP или доменных имен, чтобы сервер мог достучаться до них самостоятельно, либо
• использование протоколов связи, предусматривающих установку туннеля. В частности, MQTT, EGTS или программных брокеров (надстроек над протоколами прошлых поколений). При этом контроллерам не нужны статические IP. После включения, потери связи или перезагрузки контроллеры инициативно установят и будут поддерживать туннельное соединение с сервером.

Разработка на базе коробочных продуктов

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

Если же нужен мониторинг и/или управление однотипными объектами (как в предложенной задаче), то использование SCADA может сделать решение слишком тяжелым из-за сложности настройки, трудоемкости добавления типовых объектов и повышенных требований к производительности сервера. Лучше использовать одну из специализированных коробочных систем, представленных на рынке, наиболее подходящую для задачи. Например:

• систему мониторинга и управления сетевым оборудованием Network management system (SNMP, TR-069, CLI);
• систему автоматизированного учета тепла, электричества, газа, воды. Для краткости АСКУЭ;
• систему навигационного трекинга подвижных объектов с контролем бортовых систем;
• систему управления климатом (вентиляция, кондиционирование и отопление) HVAC;
• систему умный дом/офис/здание;
• систему управления объектами энергетики: подстанциями, наружным (уличным) освещением, зарядными станциями для электротранспорта;
• систему контроля доступа и охранно-пожарной безопасности, и т.д.

Перечисленные системы часто перекрывают функционал друг друга. Например, на базе АСКУЭ можно реализовать управление наружным освещением, а на базе Умного дома сделать управление климатом и доступом. Расширение функционала живых систем происходит постоянно. Появляются новые API для интеграции коробочных продуктов в решения заказчиков, а также поддержка пользовательских функций в коробочном ПО. Огромным плюсом коробочных продуктов является тот факт, что их можно купить и поставить на свой сервер, получив отчуждаемое решение, работающее в закрытом контуре заказчика.

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

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

Разработка на базе IoT платформ

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

• регистрации и удаления IoT устройств,
• безопасной аутентификации IoT устройств и поддержания связи с ними,
• работы с данными (базы данных, оптимизированные для разных задач),
• регистрации пользователей и управления правами доступа,
• формирования аналитики по собранным данным,
• формирования уведомлений для пользователей (SMS, E-Mail, push сообщения, ),
• хранения последних данных, считанных с IoT устройств,
• выполнения различных действий по событиям,
• визуализации данных и т.п.

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

Систему на IoT платформе можно разработать за минимальное время. Ее архитектура не будет сильно меняться при увеличении размера.

Плюсы разработки на облачной IoT платформе:

• пилотный проект можно запустить с небольшими затратами. В AWS для большинства сервисов есть лимиты бесплатного использования. В Яндекс.Облаке предусмотрен тестовый период и стартовый грант.
• гибкая тарификация, например, стоимость сервиса базы данных зависит от количества запросов, а стоимость MQTT-брокера от количества обработанных сообщений. Это особенно выгодно на старте, когда надо считать каждую копейку.
• IoT платформы протестированы на миллионах устройств. Можно быть уверенным в масштабируемости (решение не придется сильно переписывать при увеличении количества устройств) и архитектурной грамотности решения (если советоваться с инженерами по поддержке используемых IoT платформ).
• информационная безопасность обеспечивается самой платформой на различных уровнях.
• задачу первичной разработки можно отдать на аутсорс. В перспективе решение смогут сопровождать не только разработчики изначальной системы, как это бывает обычно. Ведь IoT платформы имеют мощную техподдержку, подробно документированы, а количество разработчиков, умеющих с ними работать, неуклонно растет.

Недостатки:

• компоненты IoT платформ работают только на мощностях их владельцев, создать полностью отчуждаемую систему, которая будет работать в ЦОД заказчика, возможно в редких случаях;
• стоимость использования IoT платформы для крупных проектов может быть выше стоимости аренды виртуальных машин в ЦОД;
• миграция с одной IoT платформы на другую связана с изменением приличного объема кода. Хотя сейчас наметилась тенденция к стандартизации API;
• далеко не все IoT платформы развернуты в ЦОДах внутри России, что делает невозможным их использование в интересах государственных заказчиков.

Полностью своя разработка

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

Собственные решения часто реализуют на базе таких open-source систем, как ThingsBoard, OpenSCADA, MajorDoMo, Home Assistant, iobroker, Nokia glial. Для небольших проектов они могут оказаться слишком тяжелыми из-за:

• большого срока разработки и соответствующих финансовых затрат. Обычно счет идет на человеко-годы;
• c ростом количества объектов будут возникать узкие места в виде медленных баз данных, сборщиков, генераторов отчетов и т.п., для разрешения которых потребуется изменение архитектуры и дополнение ее баллансировщиками и дублирующими ресурсами;
• расходов на постоянное администрирование и техническую поддержку.

В то же время:
Своя разработка оправдана либо для госзаказа, либо проектов с амбициозными планами и большими бюджетами, либо, когда независимость и безопасность критически важна.

Если нужна быстрая демонстрация (MVP), то ее можно сделать на IoT платформе или коробочном ПО, взяв на вооружение проверенные временем подходы, параллельно разрабатывая свое большое решение.

Заключение

На основе сделанного анализа разных систем предлагаем следующий алгоритм выбора системы управления.



Для демонстраций и маленьких IoT проектов на несколько объектов можно использовать прямое управление по IP, SMS или через GSM звонки. В остальных случаях необходима система верхнего уровня. Использование SCADA оправдано в промышленной автоматизации и на больших объектах энергетики. Для учета ресурсов, управления сетевым оборудованием, трекинга, охраны, умного дома и т.п. удобно использовать коробочное решение нужной специализации. Разработка систем на IoT платформах сложнее, но дает больше перспектив и гибкости. Решения на зарубежных IoT платформах серьезно ограничены по масштабу и областям применений в России. Самой сложной является полностью своя разработка. И она оправдана только для госзаказа и самых амбициозных проектов. При этом для быстрых демонстраций и копирования лучших практик будет полезно параллельно с собственной разработкой сделать эскизный проект на IoT платформе.

Напоследок хотим поделиться небольшим прогнозом:

• в облачных IoT платформах стоит ждать появление преднастроенных шаблонов Умного дома, АСКУЭ, NMS, СКУД и т.п. Это еще больше упростит использование IoT платформ и привлечет к ним еще большую аудиторию.
• традиционные разработчики SCADA и других коробочных решений предложат больше инструментов для внешних разработчиков, которые хорошо зарекомендовали себя в IoT платформах. Закрытые коробочные решения вряд ли выдержат рыночную конкуренцию.
• отечественные IoT платформы для государственных и больших частных заказчиков будут развиваться еще активнее.
• API разных IoT платформ станут со временем более похожими друг на друга. Из-за этого переход с одной IoT платформы на другую будет упрощаться.

В следующем, более техническом, посте мы расскажем о нашем проекте по мониторингу систем связи на платформе AWS и контроллерах GIC.

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

В предыдущем посте мы рассматривали выбор системы управления под разные задачи Интернета вещей. Для недорогих решений среднего масштаба в соответствии с предложенным в посте алгоритмом оптимально использование облачных IoT платформ.

Этот материал о том, как мы реализовали систему мониторинга и управления на базе платформы Amazon WEB Services (AWS). В качестве объекта управления использован шкаф связи, напоминающий маленький Умный дом. Внутри шкафа, например, такого, установлено оборудование сотовой или фиксированной связи, городского WiFi, видеонаблюдения, управления освещением или т.п., а также устройства электропитания и климат-контроля. С использованием контроллера умного дома шкафа, набора датчиков и системы верхнего уровня оператор наблюдает за состоянием оборудования, микроклиматом и охранно-пожарной безопасностью.

Задача

Рассмотрим создание двухуровневой системы, структурная схема которой показана ниже.


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

Функции системы нижнего уровня и требования к контроллеру

Требования к системе верхнего уровня

• должна использоваться система управления на базе облачной IoT платформы,
• система должна предусматривать работу с тысячами контролируемых объектов без необходимости переделки архитектуры,
• архитектура системы должна подходить как для B2B решений, так и для B2C систем класса умный дом,
• система должна постоянно контролировать наличие связи с объектами,
• система должна собирать статистику по своей работе,
• система должна автоматизированно обновлять настройки и программное обеспечение контроллеров;
• в качестве основного пользовательского интерфейса должен использоваться WEB интерфейс,
• в перспективе система должна работать через мобильное приложение,
• система должна иметь защиту от несанкционированного доступа на уровнях связи с пользователями и оборудованием.

Разработка системы верхнего уровня

Сегодня в мире разработано более 600 IoT платформ и это количество постоянно растет. При этом наибольшей популярностью у разработчиков в 2019 году пользовалась платформа Amazon WEB Services (AWS). Доминирующая позиция AWS определила наш выбор данной платформы в качестве базовой для нашей системы ST-Eye. На решение также повлияла оперативная техническая поддержка и наличие большого количества справочной информации. Ребята из AWS поделились лучшими практиками и помогли выбрать наиболее эффективные технологии.

Ниже приведены архитектура и описание системы ST-Eye.

Архитектура IoT системы ST-Eye на платформе AWS

Уровень связи с контроллерами

Объектовые контроллеры подключаются к сервису AWS IoT-Core с использованием протокола TLS. Адрес сервера, используемый для подключения, содержит уникальный для учетной записи идентификатор. Аутентификация осуществляется по протоколу x509. Каждое устройство при этом использует собственный уникальный сертификат. Кроме собственного сертификата, на контроллере сохранен сертификат удостоверяющего центра для проверки подлинности сервера. Создание и распространение сертификатов осуществляется средствами платформы AWS. После успешной аутентификации используется протокол MQTT, ставший стандартом де-факто в IoT. В основе протокола MQTT лежит взаимодействие клиентов друг с другом по принципу pub/sub. Клиенты публикуют сообщения в каналы (топики)и подписываются на имеющиеся топики других клиентов. Это обеспечивается с помощью промежуточного сервиса брокера, который хранит список топиков и списки подписчиков по каждому из имеющихся топиков. Сервис IoT-Core предоставляет несколько стандартных топиков для подписки и публикации, можно создавать другие топики. Они будут доступны в пределах региона AWS и учетной записи. Например, контроллеры подписываются на топики прямого управления, а WEB-приложение публикует в них команды. Благодаря низким требованиям MQTT к ресурсам, время реакции контроллера на команду оператора минимально (в нашей системе не более 0.5 сек при использовании офисного Ethernet соединения). IoT-Core это управляемый (managed) сервис, соответственно, резервирование и масштабирование выполняются без участия пользователя.

Одна из ключевых функций сервиса IoT-Core виртуальный образ устройства (shadow, англ. тень). Он позволяет получать последнее известное состояние устройства и отображать его даже тогда, когда устройство не доступно по сети. Такая возможность незаменима для работы с GSM устройствами или устройствами на батарейном питании, поскольку они могут находиться не на связи длительное время. Shadow это JSON объект, содержащий два основных поля: reported и desired. В каждом поле содержатся пары ключ-значение, соответствующие выходным данным и/или параметрам устройства. При изменении желаемых параметров устройства формируется поле delta, содержащее разницу между полями desired и reported. Устройство подписывается на топик $aws/things/thingName/shadow/update/delta и обновляет свое внутреннее состояние при наличии параметров в поле delta. Shadow содержит дату и время последнего обновления. Таким образом приложение верхнего уровня получает информацию о том, как давно контроллер выходил на связь последний раз.

Сервис IoT-Core также предоставляет гибкую систему правил для взаимодействия с другими сервисами. В нашем приложении правила IoT-Core используются, например, для отправки уведомлений и для активации устройств. Настройка уведомлений производится в АРМ администратора. Доступны SMS оповещения, электронная почта, push.

К процессу обновления ПО в IoT устройствах предъявляются строгие требования. Источник обновления и контейнер с новой прошивкой должны быть проверены на подлинность и совместимость с контроллером. В противном случае контроллер может превратиться в кирпич. Для выполнения обновления ПО (Firmware over the air FOTA) или конфигурации устройства применяется механизм Job. Контроллер получает набор команд и дополнительные данные через специальный топик, затем последовательно выполняет команды. Например, скачивает прошивку с облачного хранилища AWS S3 по ссылке и проверяет ее подпись.

Уровень обработки данных

Для обработки данных, поступающих от сервиса IoT-Core в AWS, используется подсистема IoT-Analytics. Блок channel с помощью sql-подобных правил позволяет выбрать источник данных, например, отдельные поля сообщений, поступающих от устройств. Сырые данные, поступающие через channel, могут сохраняться во внутреннее хранилище сервиса или в S3. Компонент pipeline позволяет провести предварительную обработку, фильтрацию данных, или дополнить их. Например, на основе некоторых данных можно сделать запрос к базе данных (БД) или внешнему сервису и добавить информацию из ответа. Предобработанные данные сохраняются в базу данных datastore. Эта БД относится к типу time series database (TSDB) и предназначена для работы с данными, поступающими от датчиков с привязкой ко времени. С использованием этих данных можно отследить изменение каждого параметра системы в течение всего периода наблюдения. В отличие от других типов БД, в TSDB имеются такие инструменты, как политики хранения/удаления данных, планировщик запросов и гибкие функции агрегации.

К записям в datastore в последствии применяются выборки данных (datasets). Они могут быть реализованы в виде SQL запросов и выполняться планировщиком внутри подсистемы IoT-Analytics, а, если требуется более сложная логика, в Docker-контейнере. Результаты постобработки хранятся в сервисном хранилище и доступны в течение 90 дней из WEB приложения и сервиса визуализации данных (Quicksight). По истечении срока хранения, данные переносятся в холодное хранилище на S3 с помощью Lambda функции.

Уровень визуализации (WEB app)

На верхнем уровне системы реализован WEB портал, представленный несколькими автоматизированными рабочими местами (АРМ), в частности, администратора, аналитика/руководителя и диспетчера.

Рассмотрим АРМ диспетчера. Его главное окно имеет вид таблицы, в которую сведены данные по группам объектов.


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


Кликнув по соответствующему устройству в списке, можно открыть страницу его мониторинга и управления.

WEB приложение использует протокол TLS в качестве транспорта для подключения к AWS. Аутентификация работает по алгоритму Signature V4 и использует микросервис Cognito. Код приложения размещается в хранилище S3. Портал использует механизм Continuous Integration. Новые версии автоматически проходят тестирование и, при успешном результате, применяются к платформе. Для контроля версий и автоматического развертывания используется сервис Beanstalk.

Импортозамещение

В российском законодательстве для государственных применений (B2G) имеются ограничения по использованию серверов за пределами России, например, 187-ФЗ. Наиболее продвинутый российский облачный сервис Яндекс.Облако, частью которого является IoT платформа. На старте работ над нашей системой некоторые компоненты, доступные в AWS, еще не были представлены у Яндекса. В частности, для создания законченного решения требовался собственный бэкэнд для взаимодействия с WEB приложением и MQTT брокером. С другой стороны, Яндекс уже предлагал богатые инструменты аналитики и баз данных, средства для развертывания приложений и облачное хранилище (Object Storage). Уже доступен сервис Datalens для визуализации данных (аналог AWS Quicksight), а также БД ClickHouse, прекрасно подходящая для хранения time series данных.

Яндекс делает большой вклад в развитие Open Source в мире, а также, старается делать свои продукты совместимыми с уже существующими решениями. Так, например, можно работать с Object Storage Яндекс с помощью утилиты aws-cli, используя команды для AWS S3.

Выбор объектовых контроллеров

Рынок объектовых контроллеров достаточно большой. Количество опций и производителей, из которых можно выбирать, идет на десятки, а моделей на тысячи. Как правило, при создании систем управления используют контроллеры, с которыми уже умеют работать, либо которые рекомендует поставщик системы верхнего уровня. Такое положение вещей единственно возможно при использовании систем верхнего уровня, разработанных под определенное оборудование (hardware-specific software platforms) и работающих с контроллерами по закрытым протоколам обмена.

При использовании систем верхнего уровня, работающих с контроллерами по с открытым протоколам (облачные IoT платформы именно такие), можно сэкономить, подобрав оптимальное оборудование под проект. Пример таких требований приведен выше в пункте Функции системы нижнего уровня и требования к контроллеру.

Для B2G решений в соответствии с ПП-878 лучше ориентироваться на российские контроллеры. Для некоторых областей скоро станет важным использование оборудования на российской элементной базе.

Не всем известна опция по разработке контроллеров на заказ. Она может окупиться за счет использования недорогой элементной базы и реализации нужного количества функциональных блоков под конкретный проект. Кроме этого, комплекс оборудования на объекте будет состоять из минимального количества устройств (иногда всего одного), а значит будет меньше работ по сборке, установке и пусконаладке.

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

Для описанной задачи мы использовали контроллер GiC (Generic Internet Controller) собственной разработки. Он снабжен необходимым количеством портов ввода-вывода, встроенным сетевым блоком питания, поддерживает протоколы MQTT, WEB, SNMP, ModBUS и может опрашивать различные приборы учета и имеет 1 или 2 Ethernet порта.

Заключение

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

В IoT платформах стоит ждать появления преднастроенных шаблонов систем Умного дома, АСКУЭ, NMS, СКУД и т.п. Это еще упростит создание законченных решений, снизит порог входа в данный бизнес и привлечет дополнительную аудиторию к облачным технологиям.

IoT платформы используют открытые протоколы обмена с контроллерами. Благодаря этому пользователи получают свободу выбора объектового оборудования. Появляется возможность заказной разработки контроллеров (наша специализация). Использование заказных контроллеров может уменьшить бюджет проекта.

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

В большинстве проектов промышленного Интернета вещей (IIoT) заказчики используют контроллеры, с которыми работали раньше или рекомендованные поставщиками систем верхнего уровня. При этом счет IIoT контроллеров на рынке, из которых можно выбирать, идет на тысячи.


Не всем известна опция разработки оборудования на заказ. Для большинства промышленных контроллеров не нужен дальний космос в виде уникального функционала или дизайнерского корпуса. При удачном выборе подрядчика, имеющего необходимые наработки, за 2-3 месяца можно сделать опытные образцы, а еще через пару месяцев начать серийное производство. Разработка может окупиться за счет использования недорогой элементной базы и реализации нужного количества функций под конкретный проект. Комплекс оборудования на объекте будет состоять из минимального количества устройств (часто одного), а значит будет меньше работ по сборке, установке и пуско-наладке.

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

Шаг 1. А есть ли готовое?

Можно серьезно сэкономить, подобрав оборудование под проект, например, на этом сервисе.

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

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

Шаг 2. Выбор подрядчика: КогдаСколькоПочем и защита от итальянской забастовки

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

Если договориться не получилось, надо искать подрядчика по рекомендациям, либо в Сети по запросу контрактная разработка электроники. В помощь к работе с кандидатами вопросы из чек-листа ниже.

Для предварительно выбранного подрядчика(ов) надо сформулировать первичные требования к оборудованию. Чем детальнее будут требования, тем проще будет определить стоимость работ и время разработки образцов. Также можно показать подрядчику(ам) интересующие примеры готового оборудования.

Со встречи с потенциальным партнером надо уходить с ответом на вопрос когдасколькопочем?. Об этом часто забывают. Ожидания заказчика (цены, сроки) могут оказаться сильно меньше запросов подрядчика. Если в итоге их удалось синхронизировать, можно переходить к согласованию:

• тезисной концепции: ТЗ крупными мазками, сроки, стоимость разработки,
• цен на изделия в партиях, сроков поставки,
• условий договора (права, исходники, эксклюзив).

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

• При выборе подрядчика обязателен человеческий контакт. Идеальных заказчиков и подрядчиков не бывает, но совершенно реально найти партнера с которым будет комфортно работать именно вам.
• Отлично, если подрядчик проявляет инициативу и искренне болеет за дело (можно понять по ответу на вопрос как решали серьезные проблемы в прошлом?).
• Подрядчик должен быть управляемым. Соответственно, он должен слушать и слышать заказчика, а не только себя.

Чек-лист выбора подрядчика

Шаг 3. Согласование ТЗ на IIoT контроллер

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

Согласование типа конструктива

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

Для каждого применения и проекта оптимален свой форм-фактор:

• Для энергетики, промышленной автоматики и учета ресурсов используют корпуса на DIN рейку 35мм. Пожалуй, это самый популярный формат для промышленного IoT, однако, не является серебряной пулей для всех случаев;
• Для систем связи используют модули в 19 стойку. Они бывают различной высоты, которую измеряют в U (44,45 мм).
• В 19 стойку также могут устанавливать крейты (или кассеты). В них вставляют нужное количество модулей, конструктив которых объединяют понятием Евромеханика.
• Для контроля доступа и размещения отдельно стоящих компактных устройств применяют корпуса в настольном и/или настенном исполнении,
• Существует специализированные корпуса, в том числе: антивандальные, защищенные от воды и пыли (по международным кодам IP), приборные и т.п.
• Наконец, бывают устройства без корпуса, устанавливаемые внутрь бОльших устройств, либо устройства, состоящие из платы и передней панели (в частности, модули Евромеханики).

Часто конструктив выбирают по аналогии с готовыми устройствами (с рынка). В некоторых случаях это является ошибкой, поскольку дорогой фирменный корпус (с обработкой, маркировкой, системой соединителей и пр.) может стоить до 50% от себестоимости изделия. Для справки: аналогичная доля для бюджетного корпуса может составлять менее 5%.

Выбор процессорного ядра

В бюджетных устройствах обычно используют однокристальные микроконтроллеры (MCU), с оперативной памятью (RAM) и ПЗУ (Flash) в одном корпусе. Большинство устройств тянет компактную операционную систему (ОС) типа FreeRTOS или TNKernel, а может работать и без ОС. Будем называть их RTOS контроллерами.

В более мощных контроллерах используется процессор (CPU) с внешними микросхемами RAM и Flash. Большинство таких устройств использует различные версии ОС Linux (Linux контроллеры) или менее распространенные ОС типа VхWorks или Windows CE (здесь не рассматриваем). Сделать плату на современном процессоре не так просто: на плате от 4-х до 10-ми слоев нужно расположить несколько BGA корпусов с достаточно строгими требованиями к питанию, геометрии и длинам дорожек. Для упрощения жизни разработчиков предлагаются сотни процессорных модулей, которые могут быть выполнены в виде дочерней платы с разъемами или краевыми контактами под пайку (см. ниже).


Также на рынке появляются микросхемы System on chip (SoC), содержащие процессор и память большого объема, достаточную для работы Linux. Разводка SoC значительного проще, чем набора CPU+RAM+FLASH. Кроме этого, SoC-и могут быть очень бюджетными.

Ниже приведены типовые характеристики и цены для нескольких примеров процессорных ядер от ARM, которые могут быть использованы в IIoT контроллерах.


Часто оправдано использование в одном контроллере двух процессоров: мощного для ресурсоемких приложений и небольшого однокристального для простых приложений реального времени.

Согласование требований к системе питания

В зависимости от типа объектов определяются требования к блоку питания, который может быть, как внешним, так и встроенным в устройство:

• домашнее/офисное применение, энергетика ~220/380В,
• телеком 3672В (станционное питание) и PoE,
• промышленная автоматизация 18...36В,

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

Для многих задач требуется резервное питание от одной минуты (краткосрочный резерв, чтобы послать сигнал о пропадании питания) до нескольких часов/дней (охрана и промышленная безопасность). Для реализации краткосрочного резервирования сегодня популярны суперконденсаторы со сроком жизни до 15-ти лет и устойчивостью к отрицательным температурам. Для длительного резервирования нужны аккумуляторы, как правило, на основе лития.


Для всех российских устройств необходимы сертификаты ЕАС на электробезопасность и электромагнитную совместимость. Для прохождения испытаний нужно уметь проектировать фильтры и топологию плат, а также правильно выбирать компоненты.

Порты связи

Распространенные интерфейсы, используемые в IIoT контроллерах, показаны в таблице ниже. Выбор типов и количеств под задачу и бюджет.


* может использоваться и для локальной связи c оборудованием на объекте

Входы и выходы

Для подключения датчиков контроллеры оснащаются дискретными, счетными и аналоговыми входами. Аналоговые входы могут быть потенциальными (например, на 0..10VDC или изолированными на 220VAC), либо токовыми (4..20mA, NAMUR, пожарными). Для реализации выходов используют реле (обычные и полупроводниковые, например, оптосимисторы), а также транзисторы, включенные по схеме открытый коллектор (ОК).

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

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

Индикация

Продолжительное время в IIoT устройствах было достаточно использовать несколько светодиодов. В более продвинутых контроллерах использовали телевизоры линейки семисегментных LED индикаторов, электролюминесцентные, текстовые или графические LCD индикаторы. Но от телевизоров чаще все-таки отказывались из-за их дороговизны и небольшой пользы при эксплуатации.

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


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

Модельный ряд

Хорошей практикой является разработка не одного устройства, а целой линейки. В минимуме для этого требуется разработка всего одной платы, рассчитанной на максимальную комплектацию. Другие, более бюджетные, версии будут паяться на той же плате, но из меньшего количества деталей. Часть платы будет пустой, но это не проблема (текстолит стоит недорого).

Советую добавить этот пункт в ТЗ.

Требования к встроенному программному обеспечению

Разработка ВПО может занимать до 80% от времени реализации всего проекта. Поскольку данный пост про железо, ограничусь перечислением основных функций, которые должны быть реализованы практически в любом IIoT контроллере:

• Обмен данными с системой верхнего уровня, в том числе, передача экстренных оповещений;
• Обмен данными с нижестоящими устройствами и датчиками;
• Управление исполнительными механизмами;
• Обновление ВПО с защитой от перебоев питания и связи;
• Хранение настроек и их восстановление;
• Администрирование устройства с защитой от несанкционированного доступа;
• Ведение журналов событий;
• Анализ данных и формирования воздействий и событий (Edge логика);
• Синхронизация системного времени;

Проектная работа с подрядчиком

Если ТЗ согласовано, пора подписывать договор с приложениями (ТЗ, календарный план с ценами, методика испытаний, ) и приступать к реализации.

Разработка нового IIoT контроллера это сравнительно небольшой проект, для успеха которого, тем не менее, нужна слаженная работа сотрудников заказчика и исполнителя. Со стороны заказчика сразу нужен руководитель проекта, а позже инженер(ы) тестирования (без независимого тестирования продукта не сделать). Более того, обычно разработка передается на условиях As is. После подписания актов и оплаты работ доказать необходимость исправления по гарантии сложно.

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

• В начале работ нужен устав проекта (цели, проектная команда, деньги, сроки, ), и календарный план;
• В процессе реализации необходим периодический контроль календарного плана и его корректировка;
• Если в процессе работ внедряются хорошие идеи или новые требования, которых не было в ТЗ, то их надо вносить в реестр изменений. Ценность таких идей может значительно превышать дополнительную стоимость (обычно до 10% от первоначальной стоимости работ).
• По результатам испытаний нужны протоколы, которые будут использоваться, как основание для доработок и оплат.
• Хорошей практикой является подведение итога по проекту после его завершения. Часто этот момент пропускают, хотя итоговый отчет прекрасная страховка от граблей в будущих аналогичных проектах, а также основание для наказания невиновных награждения героев.

Хорошие формы документов по проектному управлению здесь.

Заключение

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


Одна из таких возможностей для IIoT проекта применение заказных контроллеров. Для ее реализации заказчику нужно пройти путь из трех быстрых шагов:

• анализ рынка,
• выбор подрядчика (например, нас),
• согласование ТЗ.

Далее предстоит работа с выбранным подрядчиком: разработка опытных образцов, производство и поддержка. Цены на заказные контроллеры, их монтаж и пуско-наладку могут быть значительно ниже по сравнению с использованием готового оборудования. Дополнительными ценностями для заказчика будут:

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