Pull to refresh

Comments 27

Интересно, много ли приборов поддерживают подобный протокол в России. Почему то кажется что если и существуют такие то только совсем свежие разработки. Сомнительно как то что подобный протокол реализовывали каких нибудь 51 совместимых микроконтроллерах или пиках.
Интересно, много ли приборов поддерживают подобный протокол в России. Почему то кажется что если и существуют такие то только совсем свежие разработки.
В комментариях к первой части публикации уже задавался подобный вопрос, я бы не сказал, что много приборов отечественного производства поддерживают этот протокол. Однако все больше производителей начинают обращать на него внимание и использовать в своих разработках. Повторюсь, конкретно у нас в стране компания ARGO сделала теплосчетчик поддерживающий этот протокол, а также у ЗАО Радио и Микроэлектроника есть электросчетчик РиМ 489.2Х.

Возможно есть решения на базе DLMS/COSEM и других отечественных производителей, но я таковых пока не встречал. Может плохо смотрел, не знаю, но если у кого-нибудь есть информация о решениях на базе DLMS/COSEM Российских производителей, будут рад если эту информацию предоставят в комментариях.
Сомнительно как то что подобный протокол реализовывали каких нибудь 51 совместимых микроконтроллерах или пиках.

Для 51 не знаю, но для «пиков» есть готовый стек DLMS/COSEM, в журнале КиТ можно прочитать короткую заметку о нем, для msp430 есть готовый стек, пост на habrahabr о нем здесь
Спасибо. Тема интересная но судя по всему будет внедряться поначалу всё таки в топовых продуктах, хотя для разработчиков именно это возможно и представляет повышенный интерес.
Как любое универсальное решение выглядит несколько громоздко, но при условии наличия бесплатного стека может найти своё применение в системах сбора данных. Встаёт правда ещё тема регистрации компании производителя для получения идентификатора — процедура может быть сложной и недорогой.
Вообще немного странно выглядит что существуют стеки для пиков и MPS, а не для ARM в которых с ресурсами всё много проще или там этот стек стандартными методами реализуется без кастомизации какой либо?
Наверняка и для ARM контроллеров есть готовые стеки, просто я эту тему не зондировал. Встречал зарубежные конторы у которых можно стек купить, а раз можно купить значить они могут и адаптировать его под конкретный контроллер. Думаю что это лишь вопрос цены.
Было бы полезно прямо в тексте дать ссылку на предыдущую часть.
Почитал. Не нужен никому этот протокол. НЕ ТУ задачу он решает.

Типовая задач — есть предприятие (завод, кампус, институт), надо купить умные счетчики и организовать учет. Тут лучше проприетарный протокол — он позволяет использовать возможности счетчика на 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 лет — минимум… КАКАЯ экономическая выгода потребителям, что энергосеть сможет мониторить их счетчики? Выгода идет энергосетям, а не потребителям. Поэтому такие счетчики будут бойкотировать.
В КАКОЙ ситуации вы видите экономический смысл закупать приборы разных производителей? Придумайте хоть одну такую ситуацию.
Например, в ситуации когда предприятию необходимо модернизировать АСКУЭ, в связи с расширением производства например. В этом случае если на рынке буду представлены более дешевые приборы учета, но другого производителя, есть экономический смысл закупать более дешевые приборы?
Проприетарный протокол может многое… как пример — инкрементальная передача данных, за счет чего можно работать на очень низкой битовой скорости. Например, радиопередатчики LoRa обеспечивают дальность 50-100 км при милливаттах мощности. Но на скорости 20-100 бит в секунду. см. http://www.lora-alliance.org
Протоколов для передачи информации великое множество, DLMS/COSEM — это стек протоколов, он определят несколько уровней модели OSI, например прикладной, канальный и др. Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов. Любой проприетарный протокол это вещь в себе, я не говорю что они хуже или лучше, нет. Но если все производители будут использовать один протокол обмена данных в своих устройствах, тогда не будет проблем с интеграцией такого оборудования.
Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов.

Для таких случаев давно придумано решение — 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, то есть с ведением архивов? у вас есть свой собственный аналог?

ModBus, LoraWan, CAMAC, OPC, XML, JSON…
Это стандартные протоколы. Можете в википедии ознакомится.
Например — https://ru.wikipedia.org/wiki/Modbus
На равновесном рынке отличия в стоимости — 5-10 процентов, не больше. ПОЧЕМ производитель Б продает в 2 раза ешевле, чем А? Он что, не хочет денег? Значит по каким-то параметрам у Б прибор хуже. А зоопарк вендоров — это увеличение стоимости обслуживания и увеличение цены отказа. Так что экономический смысл менять вендора бывает редко.

Вы не сравнивайте счетчики с компами — у компов технология все время развивается, поэтому рынок изначально неравновесный. Хотя на рынке мониторов — четко видно, что при одинаковых характеристиках отличие цен довольно мало и определяется логистикой дилера.

Проблемы с интеграцией ваш протокол решает лишь для тривиальных случаев. ПРИМЕР. Учет газа. Важная характеристика — влажность. В чем она? В процентах? В граммах на тонну? В миллилитрах на кубометр? В вашем протоколе специфицированы такие тонкости?

Уважаемый Jef239, DLMS/COSEM это не мой протокол, это международный стандарт. Вижу, что об этом стандарте вы знаете только из моих двух публикаций. Поэтому предлагаю закончить безпредметную дискуссию и дождаться либо других моих публикаций, посвещенных данному стеку протоколов, либо можете сами ознакомиться более подробно с этим набором протоколов, прочитав голубую и зеленую книгу. Тогда у вас как минимум невозникет вопросов про «учет газа», про «отказ от ОРС», про «ведение архивов».

Отвечая на ваш вопрос про учет газа, скажу, что в протоколе DLMS/COSEM такие тонкости специфицированы.
Спецификация таких тонкостей — это ужасно. Известный факт — язык, который нельзя модифицировать, умирает. см. например, историю BASIC engish. Чем тогда будут отличаться приборы учета? К какую сторону пойет развитие? Или развитие приведет к тому, что новые поля будут у всех разные. Или — развитие остановится и стандарт умрет, не распространившись.

Действительно, спор беспредметен. Мы говорим о протоколах, которые использовали в СВОИХ системах. У вас, как я понимаю, ни одной реализованной ВАМИ системы нет. Потому и получается спор практиков с теоретиками.
Еще одна вещь, которой нету в DLMS/COSEM — это функциональность, не относящаяся к учету. Ваш протокол — он же стандартный и не изменяемый. В отличие от всех остальных, развить его невозможно.

Киллер-фича — квартирный счет с пожарной и охранной сигнализацией. Ценой небольшого усложнения прошивки счетчика — экономим на отдельных пожарных и охранных сигнализациях. Застройщики в восторге будут.

Но… передача алармов не ложиться в клиент-серверную модель. Тут нужна передача по иницативе счетчика.
Справедливости ради охрана и пожарка — не счётчика дело. И не надо навешивать на устройство нетипичных для его типа задач.
Другое дело, если мы хотим организовать условное единое информационное пространство. «Умный дом» + «Умное ЖКХ». Но опять-же данный «Универсальный протокол» в этом деле нам не поможет.
Сигнализации должны быть всегда подключены. Служба охраны не знает — то ли пробки перегорели, то ли воры обрезали провода к датчику охраны. Выезд ОМОНа на перегоревшую из-за КЗ пробку — ещё так веселуха.

Так что логично размещать сигнализацию в счетчике, то есть ДО пробок.
Действительно, это шаг в сторону «умного здания». Сейчас и так в новых домах монтируется видеонаблюдение в подъездах + контролирующая его служба охраны (или консьержей). Ценой небольшого удорожания счетчиков получаются приличные маркетинговые преимущества.

Автоматизация выписки счетов за электричество — не так важна для жильцов, как дешевая и надежная система охраны.
Все системы охранных и пожарных сигналок, которые я видел имеют возможность подключения резервного источника питания, как правило это АКБ 1207.
Ну 1207 это такой гроб… Боюсь, что в реальной жизни — это всего лишь возможность…

В любом случае — плюсы от такого решения есть.

Ещё один плюс — счетчик знает энергопотребление в квартире. То же снятие с охраны можно сделать как 2 раза включить и выключить лампочку определенного номинала. Например — включаем в коридоре и в туалете.

Ну и контроль, что всё выключили, уходя из квартиры.
Sign up to leave a comment.

Articles