Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Интересно, много ли приборов поддерживают подобный протокол в России. Почему то кажется что если и существуют такие то только совсем свежие разработки. Сомнительно как то что подобный протокол реализовывали каких нибудь 51 совместимых микроконтроллерах или пиках.
Интересно, много ли приборов поддерживают подобный протокол в России. Почему то кажется что если и существуют такие то только совсем свежие разработки.В комментариях к первой части публикации уже задавался подобный вопрос, я бы не сказал, что много приборов отечественного производства поддерживают этот протокол. Однако все больше производителей начинают обращать на него внимание и использовать в своих разработках. Повторюсь, конкретно у нас в стране компания ARGO сделала теплосчетчик поддерживающий этот протокол, а также у ЗАО Радио и Микроэлектроника есть электросчетчик РиМ 489.2Х.
Возможно есть решения на базе DLMS/COSEM и других отечественных производителей, но я таковых пока не встречал. Может плохо смотрел, не знаю, но если у кого-нибудь есть информация о решениях на базе DLMS/COSEM Российских производителей, будут рад если эту информацию предоставят в комментариях.
Сомнительно как то что подобный протокол реализовывали каких нибудь 51 совместимых микроконтроллерах или пиках.
Для 51 не знаю, но для «пиков» есть готовый стек DLMS/COSEM, в журнале КиТ можно прочитать короткую заметку о нем, для msp430 есть готовый стек, пост на habrahabr о нем здесь
Спасибо. Тема интересная но судя по всему будет внедряться поначалу всё таки в топовых продуктах, хотя для разработчиков именно это возможно и представляет повышенный интерес.
Как любое универсальное решение выглядит несколько громоздко, но при условии наличия бесплатного стека может найти своё применение в системах сбора данных. Встаёт правда ещё тема регистрации компании производителя для получения идентификатора — процедура может быть сложной и недорогой.
Вообще немного странно выглядит что существуют стеки для пиков и MPS, а не для ARM в которых с ресурсами всё много проще или там этот стек стандартными методами реализуется без кастомизации какой либо?
Как любое универсальное решение выглядит несколько громоздко, но при условии наличия бесплатного стека может найти своё применение в системах сбора данных. Встаёт правда ещё тема регистрации компании производителя для получения идентификатора — процедура может быть сложной и недорогой.
Вообще немного странно выглядит что существуют стеки для пиков и MPS, а не для ARM в которых с ресурсами всё много проще или там этот стек стандартными методами реализуется без кастомизации какой либо?
Было бы полезно прямо в тексте дать ссылку на предыдущую часть.
Сделал.
Почитал. Не нужен никому этот протокол. НЕ ТУ задачу он решает.
Типовая задач — есть предприятие (завод, кампус, институт), надо купить умные счетчики и организовать учет. Тут лучше проприетарный протокол — он позволяет использовать возможности счетчика на 100%
А DLMS/COSEM исходит из ИНОЙ предпосылки — есть ЗООПАРК разных счетчиков, но 95% поддерживают этот протокол. Причем выгоднее заменить эти 5%, а чем все 100%. То есть счетчиков много.
Что это за задача? Это управление ГОРОДОМ или районом. На худой конец — микрорайоном, домом. Местом, где много разных владельцев и централизованную закупку не сделать.
Встает вопрос — а ЗАЧЕМ владельцам счетчики с возможностью передачи информации? Что с этого получает владелец? При нашей модели, когда электричество оплачивает владелец счетчика — НИЧЕГО. При модели ДОХОДНОГО дома, где за электричество платит владелец дома, а не арендаторы — да, экономический смысл виден.
Так что УВЫ. Какое-то применение в РФ этот протокол найдет лишь лет через 20, и то — ЕСЛИ нормативными документами потребуют, чтобы все новые счетчики имели эту функцию.
В результате получается, что ваш материал интересен лишь разработчикам счетчиков. И то — для продажи их моделей заграницу.
Типовая задач — есть предприятие (завод, кампус, институт), надо купить умные счетчики и организовать учет. Тут лучше проприетарный протокол — он позволяет использовать возможности счетчика на 100%
А DLMS/COSEM исходит из ИНОЙ предпосылки — есть ЗООПАРК разных счетчиков, но 95% поддерживают этот протокол. Причем выгоднее заменить эти 5%, а чем все 100%. То есть счетчиков много.
Что это за задача? Это управление ГОРОДОМ или районом. На худой конец — микрорайоном, домом. Местом, где много разных владельцев и централизованную закупку не сделать.
Встает вопрос — а ЗАЧЕМ владельцам счетчики с возможностью передачи информации? Что с этого получает владелец? При нашей модели, когда электричество оплачивает владелец счетчика — НИЧЕГО. При модели ДОХОДНОГО дома, где за электричество платит владелец дома, а не арендаторы — да, экономический смысл виден.
Так что УВЫ. Какое-то применение в РФ этот протокол найдет лишь лет через 20, и то — ЕСЛИ нормативными документами потребуют, чтобы все новые счетчики имели эту функцию.
В результате получается, что ваш материал интересен лишь разработчикам счетчиков. И то — для продажи их моделей заграницу.
Почитал. Не нужен никому этот протоколПроводили опросы?
Типовая задач — есть предприятие (завод, кампус, институт), надо купить умные счетчики и организовать учет. Тут лучше проприетарный протокол — он позволяет использовать возможности счетчика на 100%Какие возможности прибора учета принципиально невозможно реализовать используя протокол DLMS/COSEM, но которые можно реализовать используя проприетарный протокол?
А DLMS/COSEM исходит из ИНОЙ предпосылки — есть ЗООПАРК разных счетчиков, но 95% поддерживают этот протокол. Причем выгоднее заменить эти 5%, а чем все 100%. То есть счетчиков много.Зоопарк это место где много животных разного вида за которыми ухаживают и на которых можно посмотреть, как зоопарк соотносится с приборами учета? Здесь вы приводите какие то проценты, откуда они?
Встает вопрос — а ЗАЧЕМ владельцам счетчики с возможностью передачи информации? Что с этого получает владелец? При нашей модели, когда электричество оплачивает владелец счетчика — НИЧЕГО. При модели ДОХОДНОГО дома, где за электричество платит владелец дома, а не арендаторы — да, экономический смысл виден.Вы тут опять всё в кучу намешали, и физических лиц и юридических… Скажу одно, применение протокола DLMS/COSEM позволяет избавиться, как вы говорите от того самого «ЗООПАРКА», поскольку становится возможным интеграция и взаимодействие оборудования разных производителей, ибо оборудование «одного вида». Вы же не думаете что приборы учета производит только одна компания?
Так что УВЫ. Какое-то применение в РФ этот протокол найдет лишь лет через 20, и то — ЕСЛИ нормативными документами потребуют, чтобы все новые счетчики имели эту функцию.Россети уже об этом позаботились и сдается мне что этот протокол найдет применение в России не через 20 лет, а гораздо раньше.
Проприетарный протокол может многое… как пример — инкрементальная передача данных, за счет чего можно работать на очень низкой битовой скорости. Например, радиопередатчики LoRa обеспечивают дальность 50-100 км при милливаттах мощности. Но на скорости 20-100 бит в секунду. см. http://www.lora-alliance.org/
Проценты идут из экономической эффективности.
В КАКОЙ ситуации вы видите экономический смысл закупать приборы разных производителей? Придумайте хоть одну такую ситуацию.
Не-а, 20 лет — минимум… КАКАЯ экономическая выгода потребителям, что энергосеть сможет мониторить их счетчики? Выгода идет энергосетям, а не потребителям. Поэтому такие счетчики будут бойкотировать.
Проценты идут из экономической эффективности.
В КАКОЙ ситуации вы видите экономический смысл закупать приборы разных производителей? Придумайте хоть одну такую ситуацию.
Не-а, 20 лет — минимум… КАКАЯ экономическая выгода потребителям, что энергосеть сможет мониторить их счетчики? Выгода идет энергосетям, а не потребителям. Поэтому такие счетчики будут бойкотировать.
В КАКОЙ ситуации вы видите экономический смысл закупать приборы разных производителей? Придумайте хоть одну такую ситуацию.Например, в ситуации когда предприятию необходимо модернизировать АСКУЭ, в связи с расширением производства например. В этом случае если на рынке буду представлены более дешевые приборы учета, но другого производителя, есть экономический смысл закупать более дешевые приборы?
Проприетарный протокол может многое… как пример — инкрементальная передача данных, за счет чего можно работать на очень низкой битовой скорости. Например, радиопередатчики LoRa обеспечивают дальность 50-100 км при милливаттах мощности. Но на скорости 20-100 бит в секунду. см. http://www.lora-alliance.orgПротоколов для передачи информации великое множество, DLMS/COSEM — это стек протоколов, он определят несколько уровней модели OSI, например прикладной, канальный и др. Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов. Любой проприетарный протокол это вещь в себе, я не говорю что они хуже или лучше, нет. Но если все производители будут использовать один протокол обмена данных в своих устройствах, тогда не будет проблем с интеграцией такого оборудования.
Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов.
Для таких случаев давно придумано решение — OPC. Есть верхний уровень системы, есть OPC прослойка. Если руководство компании настолько некомпетентно, что решает превратить номенклатуру приборов учёта в зоопарк — добавляется драйвер (интерпретатор, переводчик, неважно, как называется) нового прибора для OPC сервера. Верхний уровень уже работает с универсальными данными.
По факту у вас всёго-лишь ещё один «универсальный» протокол приборов учёта.
Для таких случаев давно придумано решение — OPC. Есть верхний уровень системы, есть OPC прослойка. Если руководство компании настолько некомпетентно, что решает превратить номенклатуру приборов учёта в зоопарк — добавляется драйвер (интерпретатор, переводчик, неважно, как называется) нового прибора для OPC сервера. Верхний уровень уже работает с универсальными данными.
По факту у вас всёго-лишь ещё один «универсальный» протокол приборов учёта.
Еще раз, DLMS/COSEM это стек протоколов который определят и способ представления данных и способ их передачи, конкретно для систем учета энергоресурсов. OPC технология регламентирует только интерфейс между OPC-клиентами и OPC-серверами. И она абсолютно не регламентирует способ получения этих данных от оборудования.
По факту у вас всёго-лишь ещё один «универсальный» протокол приборов учётаПриведите, пожалуйста, альтернативу протоколу DLMS/COSEM или те самые «ещё одни универсальные протоколы».
OPC технология регламентирует только интерфейс между OPC-клиентами и OPC-серверами. И она абсолютно не регламентирует способ получения этих данных от оборудования.
В том то и прелесть, что OPC технологии совершенно неважно откуда и как пришли данные. Задача только в том, чтобы преобразовать полученную последовательность байт по стандарту OPC в соответствии со спецификацией протокола и наоборот. Преобразование происходит на промежуточном уровне между железом и SCADA системой, ни верх, ни низ, при этом занимаются своими делами совершенно не заботясь о взаимной совместимости.
Это нам даёт возможность объединения в одной системе разнотипного оборудования разных годов выпуска, работающего по различным каналам связи с применением любого протокола обмена.
Вы все правильно говорите, и так сейчас в принципе делается. Однако в такой системе слабым местом, как раз является та самая прослойка между «железом» и SCADA. Поскольку при изменении протоколов обмена в оборудовании придется ее менять, а производители вряд-ли будут гарантировать неизменность своих проприетарных протоколов. Ведь рынок это динамичная структура, сегодня одни производители, завтра другие, вот и получается что потребитель, в лице дочерних компаний Россетей, покупает не только прибор учета но и еще в довесок к нему «переводчика». А зачем тратить деньги на дополнительное оборудование, когда от него можно отказаться? В частности, эту возможность предоставлет стек протоколов DLMS/COSEM. Поскольку он напрямую ориентирован на организацию обмена данными между приборами учета и системами сбора данных, менуя аппаратную прослойку между уровнем представления данных и транспортным уровнем.
Вы не понимаете роли OPC. Сейчас все SCADA его используют. Одни — как единственный протокол, другие — как основной (при вспомогательном старом проприетарном).
В итоге все приборы, предназначенные для автоматизации, имеют OPC-сервера. то есть при замене мы просто покупаем пару — прибор + OPC-сервер к нему.
Относительно отказа от OPC — планируется написание собственных SCADA? Или просто OPC-сервер, переводящий ваш протокол в OPC?
А что с OPCHD, то есть с ведением архивов? у вас есть свой собственный аналог?
В итоге все приборы, предназначенные для автоматизации, имеют OPC-сервера. то есть при замене мы просто покупаем пару — прибор + OPC-сервер к нему.
Относительно отказа от OPC — планируется написание собственных SCADA? Или просто OPC-сервер, переводящий ваш протокол в OPC?
А что с OPCHD, то есть с ведением архивов? у вас есть свой собственный аналог?
ModBus, LoraWan, CAMAC, OPC, XML, JSON…
На равновесном рынке отличия в стоимости — 5-10 процентов, не больше. ПОЧЕМ производитель Б продает в 2 раза ешевле, чем А? Он что, не хочет денег? Значит по каким-то параметрам у Б прибор хуже. А зоопарк вендоров — это увеличение стоимости обслуживания и увеличение цены отказа. Так что экономический смысл менять вендора бывает редко.
Вы не сравнивайте счетчики с компами — у компов технология все время развивается, поэтому рынок изначально неравновесный. Хотя на рынке мониторов — четко видно, что при одинаковых характеристиках отличие цен довольно мало и определяется логистикой дилера.
Проблемы с интеграцией ваш протокол решает лишь для тривиальных случаев. ПРИМЕР. Учет газа. Важная характеристика — влажность. В чем она? В процентах? В граммах на тонну? В миллилитрах на кубометр? В вашем протоколе специфицированы такие тонкости?
Вы не сравнивайте счетчики с компами — у компов технология все время развивается, поэтому рынок изначально неравновесный. Хотя на рынке мониторов — четко видно, что при одинаковых характеристиках отличие цен довольно мало и определяется логистикой дилера.
Проблемы с интеграцией ваш протокол решает лишь для тривиальных случаев. ПРИМЕР. Учет газа. Важная характеристика — влажность. В чем она? В процентах? В граммах на тонну? В миллилитрах на кубометр? В вашем протоколе специфицированы такие тонкости?
Уважаемый Jef239, DLMS/COSEM это не мой протокол, это международный стандарт. Вижу, что об этом стандарте вы знаете только из моих двух публикаций. Поэтому предлагаю закончить безпредметную дискуссию и дождаться либо других моих публикаций, посвещенных данному стеку протоколов, либо можете сами ознакомиться более подробно с этим набором протоколов, прочитав голубую и зеленую книгу. Тогда у вас как минимум невозникет вопросов про «учет газа», про «отказ от ОРС», про «ведение архивов».
Отвечая на ваш вопрос про учет газа, скажу, что в протоколе DLMS/COSEM такие тонкости специфицированы.
Отвечая на ваш вопрос про учет газа, скажу, что в протоколе DLMS/COSEM такие тонкости специфицированы.
Спецификация таких тонкостей — это ужасно. Известный факт — язык, который нельзя модифицировать, умирает. см. например, историю BASIC engish. Чем тогда будут отличаться приборы учета? К какую сторону пойет развитие? Или развитие приведет к тому, что новые поля будут у всех разные. Или — развитие остановится и стандарт умрет, не распространившись.
Действительно, спор беспредметен. Мы говорим о протоколах, которые использовали в СВОИХ системах. У вас, как я понимаю, ни одной реализованной ВАМИ системы нет. Потому и получается спор практиков с теоретиками.
Действительно, спор беспредметен. Мы говорим о протоколах, которые использовали в СВОИХ системах. У вас, как я понимаю, ни одной реализованной ВАМИ системы нет. Потому и получается спор практиков с теоретиками.
Еще одна вещь, которой нету в DLMS/COSEM — это функциональность, не относящаяся к учету. Ваш протокол — он же стандартный и не изменяемый. В отличие от всех остальных, развить его невозможно.
Киллер-фича — квартирный счет с пожарной и охранной сигнализацией. Ценой небольшого усложнения прошивки счетчика — экономим на отдельных пожарных и охранных сигнализациях. Застройщики в восторге будут.
Но… передача алармов не ложиться в клиент-серверную модель. Тут нужна передача по иницативе счетчика.
Киллер-фича — квартирный счет с пожарной и охранной сигнализацией. Ценой небольшого усложнения прошивки счетчика — экономим на отдельных пожарных и охранных сигнализациях. Застройщики в восторге будут.
Но… передача алармов не ложиться в клиент-серверную модель. Тут нужна передача по иницативе счетчика.
Справедливости ради охрана и пожарка — не счётчика дело. И не надо навешивать на устройство нетипичных для его типа задач.
Другое дело, если мы хотим организовать условное единое информационное пространство. «Умный дом» + «Умное ЖКХ». Но опять-же данный «Универсальный протокол» в этом деле нам не поможет.
Другое дело, если мы хотим организовать условное единое информационное пространство. «Умный дом» + «Умное ЖКХ». Но опять-же данный «Универсальный протокол» в этом деле нам не поможет.
Сигнализации должны быть всегда подключены. Служба охраны не знает — то ли пробки перегорели, то ли воры обрезали провода к датчику охраны. Выезд ОМОНа на перегоревшую из-за КЗ пробку — ещё так веселуха.
Так что логично размещать сигнализацию в счетчике, то есть ДО пробок.
Действительно, это шаг в сторону «умного здания». Сейчас и так в новых домах монтируется видеонаблюдение в подъездах + контролирующая его служба охраны (или консьержей). Ценой небольшого удорожания счетчиков получаются приличные маркетинговые преимущества.
Автоматизация выписки счетов за электричество — не так важна для жильцов, как дешевая и надежная система охраны.
Так что логично размещать сигнализацию в счетчике, то есть ДО пробок.
Действительно, это шаг в сторону «умного здания». Сейчас и так в новых домах монтируется видеонаблюдение в подъездах + контролирующая его служба охраны (или консьержей). Ценой небольшого удорожания счетчиков получаются приличные маркетинговые преимущества.
Автоматизация выписки счетов за электричество — не так важна для жильцов, как дешевая и надежная система охраны.
Все системы охранных и пожарных сигналок, которые я видел имеют возможность подключения резервного источника питания, как правило это АКБ 1207.
Ну 1207 это такой гроб… Боюсь, что в реальной жизни — это всего лишь возможность…
В любом случае — плюсы от такого решения есть.
Ещё один плюс — счетчик знает энергопотребление в квартире. То же снятие с охраны можно сделать как 2 раза включить и выключить лампочку определенного номинала. Например — включаем в коридоре и в туалете.
Ну и контроль, что всё выключили, уходя из квартиры.
В любом случае — плюсы от такого решения есть.
Ещё один плюс — счетчик знает энергопотребление в квартире. То же снятие с охраны можно сделать как 2 раза включить и выключить лампочку определенного номинала. Например — включаем в коридоре и в туалете.
Ну и контроль, что всё выключили, уходя из квартиры.
Как это я промахнулся по кнопке «ответить»… мои извинения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DLMS/COSEM – открытый протокол для обмена данными с приборами учета. Часть 2: интерфейсные классы, модель прибора учета