Типы данных для телеметрии
Nov. 1st, 2016 03:06 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
В процессе пиления датчика 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-форматов, или массив "тип, имя, длина" для бинарных структур или еще что-нибудь в том же духе.
Поначалу данные в 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-форматов, или массив "тип, имя, длина" для бинарных структур или еще что-нибудь в том же духе.
no subject
Date: 2016-11-01 12:35 pm (UTC):-)
no subject
Date: 2016-11-01 01:22 pm (UTC)Нужно проверить эту идею :)
no subject
Date: 2016-11-01 03:48 pm (UTC)no subject
Date: 2016-11-01 05:31 pm (UTC)(все идут на кухню, открыв окно)
no subject
Date: 2016-11-01 12:45 pm (UTC)no subject
Date: 2016-11-01 02:51 pm (UTC)Я еще всегда стараюсь уговорить передать хотя бы версию протокола. Жалко, что ли.
no subject
Date: 2016-11-01 04:32 pm (UTC)А потом метаданные метаданных метаданных.
А потом метаданные метаданных метаданных метаданных.
А потом метаданные метаданных метаданных метаданных метаданных.
А потом метаданные метаданных метаданных метаданных метаданных метаданных.
А потом метаданные метаданных метаданных метаданных метаданных метаданных метаданных.
А потом метаданные метаданных метаданных метаданных метаданных метаданных метаданных метаданных.
no subject
Date: 2016-11-01 05:44 pm (UTC)Получается метациркулярный интерпретатор метаданных, это хороший кстати тест-кейс для проверки таких вещей. Если метаданные могут описать сами себя полностью - значит все сделано хорошо.
no subject
Date: 2016-11-01 05:30 pm (UTC)no subject
Date: 2016-11-01 05:43 pm (UTC)no subject
Date: 2016-11-01 06:30 pm (UTC)no subject
Date: 2016-11-01 07:41 pm (UTC)no subject
Date: 2016-11-01 05:45 pm (UTC)no subject
Date: 2016-11-01 08:30 pm (UTC)no subject
Date: 2016-11-01 10:06 pm (UTC)А вместо ардуины ща ставят stm32, в который я уже впихивал парсеры на конечных автоматах, сгенерированные рагелем да плюс командную строку с виртуального ком-порта :)
no subject
Date: 2016-11-02 03:30 am (UTC)Проблемы начинаются когда данные:
а) не сэмплированы;
б) не фильтрованы;
в) непонятно в каких единицах измерения.
Еще хуже, когда измерения по одной и той же физической величине валятся в разных единицах измерения. Или со временем по тому же тегу UOM меняется, т.к. поменяли исходный прибор.
Т.к. мы находимся уже после OPC-сервера, то решать приходится проблемы не с самим протоколом, а с озвученными выше. Там мы просто наколхозили модель метаданных по каждому измерению и источнику данных и сопоставляем их между собой. Поначалу страшно, но когда привыкаешь - удобно.
no subject
Date: 2016-11-03 06:40 pm (UTC)