Типы данных для телеметрии

[metaclass]

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

Поначалу данные в udp-пакетах с датчика выглядели так: 2016-10-29T21:26:40.990599,ff8601e440402eb92e
Потом вот так, чтобы сразу видеть концентрацию: 2016-10-29T23:48:35.310594,ff86027840042e305e,632

А потом я решил это дело засунуть сразу в эластик с кибаной, чтобы рисовать графики, причем у нас туда данные (мониторинг нашего софта) идут в виде json-объектов в сообщениях через mq-сервер. Наиболее прямой путь такое делать - это поля от датчика разложить в виде полей json-объекта, тогда эластик автодетектит типы полей и все становится сразу доступным для запросов и графиков.
Но прога, которая транслирует udp-пакеты в mq сообщения - вообще говоря, тестовый/отладочный клиент от моей mq-либы и впихивать в нее прибитые гвоздями имена полей от одного конкретного датчика - лютый грех, такой код должен быть универсальным, очевидно.
Поэтому формат пакета превратился в: "utc=2016-10-30T12:04:08.740605,hex=ff8602db40402e30bf,co2=731", а программа просто конвертирует это в json и добивает служебными полями от себя (уникальный идентификатор ноды, тип сообщения, и прочее такое). В таком варианте я смогу, например, добавить еще пакетов от других датчиков - давления, освещенности, влажности, радиации и температуры, не переделывая транслятор.

Фактически, это структурный тип данных - смысл данных определяется тем, какие в нем есть поля. Это очень удобно для обобщенной обработки.

При этом, когда я работаю с чужими железками, там почти всегда типы данных прибиты гвоздями - начиная от просто упакованных бинарных структур, заканчивая csv с позиционным назначением полей или бинарным массивом из кучи бинарных пакетов с CRC и прочим.
Понятно, что так сильно экономится GPRS-трафик для телеметрии и байтики в прошивке, но почему бы этим устройствам сразу после подключения по TCP не передавать метаданные протокола, которые можно было бы грузить в парсер и он автоматом бы становился совместимым с тем, что устройство будет передавать после этого.
Т.е. хотя бы передавать csv заголовок для csv-форматов, или массив "тип, имя, длина" для бинарных структур или еще что-нибудь в том же духе.

Comments

[aamonster.livejournal.com]

Не могу не отметить, что от изменения формата концентрация CO₂ выросла с 0.632% до 0.731%, что свидетельствует о тяжёлой работе программиста!
:-)

[metaclass.livejournal.com]

По ходу, концентрация зависит от того - пинать херы или работать
Нужно проверить эту идею :)

[bxs5fss.livejournal.com]

метакласcс, твои дети тупые из-за наследственности, или потому что ты бухал перед зачатием?

[aamonster.livejournal.com]

По моим экспериментальным данным, теин и кофеин вытесняют CO2. Особенно с булочками.
(все идут на кухню, открыв окно)

[develop7]

ребе, а ви таки изобрели netflow v9!

[juan-gandhi.livejournal.com]

Убедительно.
Я еще всегда стараюсь уговорить передать хотя бы версию протокола. Жалко, что ли.

[berezovsky.livejournal.com]

А потом метаданные метаданных.

А потом метаданные метаданных метаданных.

А потом метаданные метаданных метаданных метаданных.

А потом метаданные метаданных метаданных метаданных метаданных.

А потом метаданные метаданных метаданных метаданных метаданных метаданных.

А потом метаданные метаданных метаданных метаданных метаданных метаданных метаданных.

А потом метаданные метаданных метаданных метаданных метаданных метаданных метаданных метаданных.

[metaclass.livejournal.com]

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

[blackyblack.livejournal.com]

А чё бы вместо того, чтобы формат с utc=X колхозить, не слать сразу в JSON? Погляди, у Рича Хикки есть лекция на тему in-band/out-band форматов передачи данных.

[metaclass.livejournal.com]

Да мне лень было питоно-либу для json вспоминать :)

[blackyblack.livejournal.com]

Дак там без либы можно: sprintf(buffer, "{\"%s\":\"%s\"}", key, value)

[metaclass.livejournal.com]

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

[berezovsky.livejournal.com]

он хикки?

[antontsau.livejournal.com]

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

[metaclass.livejournal.com]

Либа кстати 1.6 мб размером и написана на сишечьке :)
А вместо ардуины ща ставят stm32, в который я уже впихивал парсеры на конечных автоматах, сгенерированные рагелем да плюс командную строку с виртуального ком-порта :)

[maksenov.livejournal.com]

В больших компаниях проблема с идентификацией сигнала решается достаточно просто с т.з. конечного потребителя: телемеханики конфигурируют SCADA так, чтобы данные с датчиков маркировались уникальным тегами, и потом выдавались на OPC-совместимый эндпоинт.

Проблемы начинаются когда данные:
а) не сэмплированы;
б) не фильтрованы;
в) непонятно в каких единицах измерения.

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

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

[b00ter.livejournal.com]

Нет ли здесь призыва к ASN.1?