Как научить железо и софт говорить на одном языке?

Вещи, которые в парадигме IoT подключены к Интернет, генерируют самую разнообразную информацию: дискретные состояния и непрерывные значения датчиков,  настройки и режимы работы, счетчики физических величин, текстовую информацию, картинки, видео и звук.  Назовем такую информацию Параметры. Параметрами устройства обмениваются с сервером и между собой.  Параметры отображаются на индикаторе устройства, в интерфейсных и служебных программах. По сути, вся концепция IoT сводится к сбору, обработке и отображению параметров устройств. 

Огромной проблемой развития концепции IoT является потеря взаимопонимания на сегментах firmware-firmware, software-software, и особенно firmware-software.  Проблема почти не проявляется пока параметров менее 10 и все элементы системы разработаны одной компанией. При несколько десятках параметров от IoT  устройств, особенно произведенных в разных фирмах, проблема проявляется в явном виде, при сотнях и тысячах параметров задача интеграции становится нерешаемой.

Откуда могут взяться сотни и тысячи параметров?

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

Б) Объект использующий сеть смарт-сенсоров, например умный дом.

В) Служебные параметры IoT устройства: серийный номер, настройки подключения к сети, калибровочные коэффициенты сенсоров, заводские и монтажные настройки устройства, статистика работы устройства.

Популярные IoT платформы Azure,  AWS, Watson и т.п. предлагают только транспортный уровень протокола передачи данных, а то что должно быть внутри транспорта отдается пользователю. То есть по аналогии с почтой: вам гарантируют, что письмо до вас дойдет, но вскрыв его вы можете увидеть незнакомый язык текста. Таким образом, интерпретация параметров попадает в руки software программистов, которые далеки от железа (things) либо firmware программистов, которым чужды инструменты серверного ПО.

Типичные проявления проблемы недопонимания

1. Растут сроки разработки железа и софта за счет большой работы по тестированию и устранению ошибок.

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

3. Снижается точность измерения параметров за счет конвертации в другие типы данных.

4. Медленная работа серверного софта

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

6. Ограниченный функционал. Потенциально функцию можно реализовать, но трудоемкость разработки аналитического софта съедает возможные выгоды.

7. Проблемы документирования и техподдержки. Один и тот же параметр проходит в различных документах под разными названиями или что еще хуже – разные параметры имеют схожие названия и возникает путаница.

 

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

 

Стандартизация подразумевает

1. Уникальный номер (идентификатор параметра)

2. Название сокращенное и полное

3. Единицу измерения

4. Формат представления: тип, смещение, дискретность, длина

5. Описание параметра и правил его использования

 

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

 

Александр Каплунский,

Основатель и системный архитектор Технотон Инжиниринг