Comments 9
Понравилась, конечно.
Плюсом было бы чуть проще и понятней как это применяют в реальности)
В тех же годах разрабатывал мосты между промышленным оборудованием и центрами сбора и наблюдения.
Ничего не слышал тогда про EDDL (и до сегодняшнего дня не слышал), но все IT провайдеры от телекомов до энергетиков просили реализацию SNMP.
И делал вот такие штуки для них:
Работало и по проводному интернету и по беспроводному через два GSM модема.
Вместо EDDL применялся язык MIB. Был GPS. Совершенно бесплатно можно было получить уникальный идентификатор производителя SNMP агента. Уже тогда было ясно, что нужна более полная информация от объектов наблюдения, включая их геолокацию.
На сегодня настало время цифровых двойников, как это называют в индустрии. Пришёл язык Digital Twins Definition Language (DTDL) и куча IoT протоколов.
А я перешёл на разработку модулей для IoT с WiFi, Bluetooth и long range RF. Модули раз в 5 производительней, способны поддерживать шины: HATR, CAN, LIN, RS485, USB, 1-Wire, I2C, ...
Это к тому что в индустрии 4.0 нужна и возможна большая консолидация протоколов.
Нишевые языки типа EDDL думаю остаются только как преграды для доступа в некоторые отрасли новых участников, для ограничения конкуренции.
Проблема заключается не в консолидации протоколов. Это делают контроллеры и модули как ваш.
Проблема в том, как настраивать устройства из системы управления используя эти протоколы.
До всего этого обычно писалась отдельная приблудина, и обычно от производителя. И для настройки нужно было отрубиться от системы, и выполнить настройку. С введением языка описания EDDL эта проблема уходит.
В нем производитель и описывает то, как работать с устройством. Например формат команд общения с датчиком, как делать калибровку, настраивать разные параметры, стреппинг таблицы и так далее.
Да язык нишевый, преграда для конкуренции, тоже да, но без него решения этой проблемы(описание логики работы с устройством) нет, ну кроме как писать отдельноюые приложение.
В FCG порядка 30 000 зарегеных Edd и устройств, представляете себе 30 000 утилит для настройки.
Ну и побочным эффектом является, то что можно EDD использовать для обычного мониторинга и сбора данныз.
Единая утилита не избавляет от самой сложной работы, а именно от изучения мануала на устройство. Представляете себе изучить 30000 мануалов?
Поэтому в других областях пошли дальше. В Bluetooth специфицируют не язык, а сами устройства. Скажем, что может, а чего не может иметь измеритель пульса. Каждой его фиче присваивается глобально! (т.е. во всем мире Bluetooth устройств) уникальный идентификатор. Не нужно читать мануал, нужно только посмотреть справочник фичей.
Это один вариант.
Другой вариант, когда дивайс сам возвращает описатель своих фичей и параметров.
Например мои модули кроме самих параметров выдают и схему параметров, с описанием иерархии, форматирования, диапазонами и т.д. В IoT в качестве нотации такой информации принят JSON. Переносчиком служит обычно MQTT поверх стека TCP.
Нотация JSON легко парсится и браузерами и различными библиотеками в разных средах разработки.
И вот вопрос. Что лучше борется со сложностью: нишевой язык описания типа EDDL с жёсткой схемой и непонятной полнотой поддержки или собственная реализация минималистичных схем описания с использованием всем понятной нотации JSON?
Так ли уж сложно написать парсер своей схемы и так ли уж он будет неудобен чем достаточно специфичные браузеры для EDDL?
Я считаю что современные средства разработки позволяют легко написать собственный браузер(он же менеджер) для собственной схемы.
Да, в целом верно говорите, но проблема в том, что полевые устройства не имеют столько ресурсов, обычно это контроллер на 4 кбайта ОЗУ и 64 кбайт ПЗУ.
Они в принципе не могут столько содержать информацию, показывающую как с ними работать. А описание на EDDL занимает 3-4 Мбайта
Кроме того, например, датчик предоставляет возможность специфической трех-тотечной калибровки и пользователь для этого должен вначале снять точку один, потом 3, потом 2, потом посчитать коэффициенты и записать их.
Как это можно описать например через профили на Json?
Т. Е. где в парадигме, которую вы описали кодируется эта логика работы с устройством?
А EDDL именно это и делает. Запускаете хост и выполняете метод, который делает 3 точечную калибровки именно так как надо и никак иначе.
И да это избавляет от детального чтения 30000 мануалов, но конечно прочитать их надо, но так чтобы прямо помнить все уже нет.
Это уменьшает вероятность ошибок при работе с устройством и неправильной его настройки, а также делает это изи ту юз.
Персонал может быть уже менее квалифицированный, зарплата меньше и в общем затраты меньше.
Уфф, очень интересно.
лет 7-8 назад работал в компании Овен, в плк и модулях(техлидом), и не разу о таком не слышал, видимо в основном применения всё таки маленькие были, не запрашивали ни разу вроде описания.
а сейчас вот в Болиде работаю. да, не асу-тп, но приборов работающих в опс - прямо существенно больше. целая такая ниша, 24/7/365, со своими измерениями и прочими радостями приводов и клапанов.
Так я к тому что программа настройки приборов в своём протоколе одна - uprog. с интерфейсом аля 95-я,но при этом любой прибор 20-и летней давности достают из за потолка армстронга, сдувают пыль, программой накатывают, если можно, поновее прошивку, и конфигурируют.
Одна программа - конфигуратор на пару сотен приборов, с многими вариантами и версиями. Давно (лет 20) и стабильно и вот это всё. Жалко, конечно, что изначально не причалили к стандартному описанию, но это мне показывает что такой путь при правильной архитектуре и уровне абстракции, как описано в статье - вполне себе имеет право на жизнь и далеко не что то умозрительное, а вполне себе осязаемое и полезное.
Пять лет назад мне поставили задачу разработать датчик давления с поддержкой HART. Для того чтобы отлаживать его с помощью коммуникатора я прикидывался одним из Ханивеллов. Была идея сгенерировать свой бинарник и скормить его коммуникатору, но время на проект вышло и я забросил это. Интересно как распарить бинарник или его сгенерировать?
Сгенерить наверное только токенайзром, который продается в фонде, сейчас его не купить, но у нескольких Российских команий он есть. Ну либо читаем спецификацию и зная формат бинарника и граматику языка пишем свою генерилку. Скажу так распрарсить бинарник можно. Возможно чуть попозже напишу про это, почти пол года парились.
Интеграция полевых устройств в системы автоматизации производств (Язык описания электронных устройств EDDL)