Просуммируйте, пожалуйста, стоимость все стандартов. Сколько сотен (тысяч?) евро нужно потратить, чтобы начать разработку?
Я же написал, 1000 евро. Это стоимость членства в ассоциации DLMS UA. За эти деньги вы получаете не только цветные книги, но и многое другое, включая техническую поддержку.
Я вот никак не пойму, какой смысл скрывать этот протокол?
Если речь идет про спецификацию СПОДЭС, то она доступна на сайте ПАО Россети.
Если речь идет о стеке DLMS, то полные тексты стандарта можно купить на сайте webstore.iec.ch или вступить в ассоциацию DLMS UA и получить доступ к полным текстам цветных книг.
Стек DLMS/COSEM никто и никогда не закрывал. Роялти за использование стека DLMS/COSEM платить не надо.
Вас смущает то, что надо купить эти книги? Так цена вопроса 1000 евро, месячная зарплата программиста… Там в ассоциации наверно тоже такие же люди работают, которые время от времени хотят кушать…
Чтобы это не осталось моим частным мнением, цитата из
Объективности ради, приведем цитату того же автора из той же статьи:
Достоинства протокола:
возможность широкого выбора интерфейсов для передачи данных: RS 232/485, PSTN, GSM, GPRS, IPv4, PPP и PLC;
определяет интерфейсную модель, действительную для любого типа энергоресурса. Система, построенная на базе протокола DLMS/COSEM, открыта для расширения путем добавления новых возможностей без изменения имеющихся сервисов;
стандартизует функционал прибора учета: регистрация потребления, тарифное планирование, измерение качества электроэнергии и др.;
обеспечивает контролируемый и безопасный доступ к информации внутри прибора учета (открытый доступ, доступ по паролю и с аутентификацией). Информация, передаваемая по коммуникационным линиям, может быть дополнительно зашифрована;
позволяет создавать унифицированные драйверы, посредством которых становится возможным связываться с приборами учета разных типов от различных производителей;
широко распространен среди зарубежных приборов учета.
Даже при прямом коннекте по оптоголовке стабильность связи, ну как сказать — да полностью отсутствовала, слишком много негоциаций нужно выполнить при каждом простом запросе.
Оптоголовка в принципе не отличается стабильностью связи и использовать её для сбора данных в АСКУЭ наверно не очень правильно, для этого есть другие, более надежные и стабильные интерфейсы: RS-485, Ethernet, радио, PLC. Тем не менее даже при непосредственном чтении данных со счетчика через оптоголовку стабильность связи должна обеспечиваться протоколом канального уровня.
Если говорить про приборы учёта соответствующие СПОДЭС, то у них, при обмене данными через оптопорт применяется протокол канального уровня HDLC, который как раз и обеспечивает стабильность связи. Разумеется что поверх HDLC идет DLMS. Так вот, если вдруг при обмене данными произошла их утеря, то HDLC восстановит этот обмен с того места где данные потерялись. Причем эту возможность проверял лично, когда реализовывал HDLC и DLMS, и на оптопорту и на RS-485.
Поэтому могу лишь догадываться, что в вашем случае либо неправильно был реализован HDLC, либо протокол канального уровня не использовался вообще, либо аппаратная часть оставляет желать лучшего.
Заменили на IEC 62056-21 — это не DLMS
:) надо было совсем отказаться от стека DLMS/COSEM и сделать что-то свое, ведь IEC 62056-21 это один из стандартов стека DLMS/COSEM.
Так насколько стек DLMS/COSEM «тяжелый» и по сравнению с чем? Наверно если бы он был таким «тяжелым» то LoRa Alliance не стала бы сотрудничать с ассоциацией DLMS UA и вести работы по созданию нового коммуникационного профиля для сетей LoRaWAN.
Уже теплее :) сколько программистов работало над проектом? Дело в том, что из той информации которая есть в заметке, можно сделать следующий вывод: один программист написал за год 38334 строк кода, попутно реализовав при этом 60870-5-101 и ModbusRTU. При этом его постоянно дёргали на другие проекты, да и ТЗ постоянно менялось… Так сколько времени в итоге было потрачено на проект?
На всякий случай оставлю здесь ссылку, вдруг кому-нибудь пригодится.
github.com/sensiki/quectel-cm
Я правильно понимаю, что эту программу можно использовать вместо пакета ppp и тех скриптов которые приведены в заметке? Есть на нее документация или только исходный код?
Наше исследование было сфокусировано на 10 моделях дисков, основные характеристики которых приведены в Таблице 1. Мы выбрали модели четырех производителей, каждая из которых отработала несколько миллионов дней, использующих три наиболее распространенных типа флэш-памяти (MLC, SLC, eMLC)
Оказывается SSD диски уже были, когда в Олимпии прошли 15-е Олимпийские игры (720 год до нашей эры :)
А что там надо контролировать с сертификатами? Let's Encrypt, certbot… и что там контролировать… тем более уже сейчас хостинги это делают бесплатно и быстро, нужна только заявка от пользователя.
Вывод: понимая и используя принцип «перспективных занятий», мы можем увеличить вероятность того, что будем жить без сожалений.
или наоборот, понизить :) ведь если человек не понимает сам чего он хочет от жизни, если он стремиться быть «успешным» следуя принципам «успешных людей» и применяя их методики, способы организации рабочего дня и пр., не факт что в конце пути он достигнет успеха «успешных людей». Но в погоне за этой успешностью может пролететь вся жизнь… а человек как был неудовлетворенным, так им и останется.
Мне кажется главное что объединяет успешных людей, так это их энтузиазм, оптимизм и стремление к самосовершенствованию имея эти три составляющие, человек будет и читать, и экспериментировать, и ходить и т.п. и делать он это будет без всяких пособий по тому как стать «успешным», поскольку для таких людей сама деятельность является своего рода кислородом без которого жить не возможно.
В протоколе DLMS/COSEM, условно, можно выделить два вида запроса типа GET. Запрос типа GET-Request-Normal и запрос типа Get-Request-With-List. Во всех типах запроса используется параметр типа COSEM Attribute Descriptor который содержит информацию, необходимую для запроса данных, например логическое имя объекта, идентификатор атрибута и др. Отличие GET-Request-Normal от Get-Request-With-List заключается в том, что в первом используется один параметр COSEM Attribute Descriptor, а во втором список параметров COSEM Attribute Descriptor. Таким образом, применяя запрос Get-Request-With-List можно запросить значения атрибутов сразу нескольких объектов COSEM или запросить значения нескольких атрибутов одного объекта COSEM, в общем возможны варианты…
В ответном же сообщении содержатся только запрашиваемые значения. Параметр COSEM Attribute Descriptor в ответном сообщении отсутствует, этим и объясняется то обстоятельство, что размер запроса больше, чем размер ответа. Тем не менее очень часто бывает так, что размер ответа превышает размер запроса, все зависит от размера запрашиваемого значения. Однако надо учитывать, что авторы статьи для расчета размера поля данных TCP рассматривали размер запрашиваемого значения равного четырем байтам, для всех протоколов.
И последнее, в случае запроса типа Get-Request-With-List в ответном сообщении содержится список запрашиваемых значений.
Уважаемый Jef239, DLMS/COSEM это не мой протокол, это международный стандарт. Вижу, что об этом стандарте вы знаете только из моих двух публикаций. Поэтому предлагаю закончить безпредметную дискуссию и дождаться либо других моих публикаций, посвещенных данному стеку протоколов, либо можете сами ознакомиться более подробно с этим набором протоколов, прочитав голубую и зеленую книгу. Тогда у вас как минимум невозникет вопросов про «учет газа», про «отказ от ОРС», про «ведение архивов».
Отвечая на ваш вопрос про учет газа, скажу, что в протоколе DLMS/COSEM такие тонкости специфицированы.
Наверняка и для ARM контроллеров есть готовые стеки, просто я эту тему не зондировал. Встречал зарубежные конторы у которых можно стек купить, а раз можно купить значить они могут и адаптировать его под конкретный контроллер. Думаю что это лишь вопрос цены.
Вы все правильно говорите, и так сейчас в принципе делается. Однако в такой системе слабым местом, как раз является та самая прослойка между «железом» и SCADA. Поскольку при изменении протоколов обмена в оборудовании придется ее менять, а производители вряд-ли будут гарантировать неизменность своих проприетарных протоколов. Ведь рынок это динамичная структура, сегодня одни производители, завтра другие, вот и получается что потребитель, в лице дочерних компаний Россетей, покупает не только прибор учета но и еще в довесок к нему «переводчика». А зачем тратить деньги на дополнительное оборудование, когда от него можно отказаться? В частности, эту возможность предоставлет стек протоколов DLMS/COSEM. Поскольку он напрямую ориентирован на организацию обмена данными между приборами учета и системами сбора данных, менуя аппаратную прослойку между уровнем представления данных и транспортным уровнем.
Еще раз, DLMS/COSEM это стек протоколов который определят и способ представления данных и способ их передачи, конкретно для систем учета энергоресурсов. OPC технология регламентирует только интерфейс между OPC-клиентами и OPC-серверами. И она абсолютно не регламентирует способ получения этих данных от оборудования.
По факту у вас всёго-лишь ещё один «универсальный» протокол приборов учёта
Приведите, пожалуйста, альтернативу протоколу DLMS/COSEM или те самые «ещё одни универсальные протоколы».
В КАКОЙ ситуации вы видите экономический смысл закупать приборы разных производителей? Придумайте хоть одну такую ситуацию.
Например, в ситуации когда предприятию необходимо модернизировать АСКУЭ, в связи с расширением производства например. В этом случае если на рынке буду представлены более дешевые приборы учета, но другого производителя, есть экономический смысл закупать более дешевые приборы?
Проприетарный протокол может многое… как пример — инкрементальная передача данных, за счет чего можно работать на очень низкой битовой скорости. Например, радиопередатчики LoRa обеспечивают дальность 50-100 км при милливаттах мощности. Но на скорости 20-100 бит в секунду. см. http://www.lora-alliance.org
Протоколов для передачи информации великое множество, DLMS/COSEM — это стек протоколов, он определят несколько уровней модели OSI, например прикладной, канальный и др. Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов. Любой проприетарный протокол это вещь в себе, я не говорю что они хуже или лучше, нет. Но если все производители будут использовать один протокол обмена данных в своих устройствах, тогда не будет проблем с интеграцией такого оборудования.
Если речь идет про спецификацию СПОДЭС, то она доступна на сайте ПАО Россети.
Если речь идет о стеке DLMS, то полные тексты стандарта можно купить на сайте webstore.iec.ch или вступить в ассоциацию DLMS UA и получить доступ к полным текстам цветных книг.
Стек DLMS/COSEM никто и никогда не закрывал. Роялти за использование стека DLMS/COSEM платить не надо.
Вас смущает то, что надо купить эти книги? Так цена вопроса 1000 евро, месячная зарплата программиста… Там в ассоциации наверно тоже такие же люди работают, которые время от времени хотят кушать…
Объективности ради, приведем цитату того же автора из той же статьи:
Оптоголовка в принципе не отличается стабильностью связи и использовать её для сбора данных в АСКУЭ наверно не очень правильно, для этого есть другие, более надежные и стабильные интерфейсы: RS-485, Ethernet, радио, PLC. Тем не менее даже при непосредственном чтении данных со счетчика через оптоголовку стабильность связи должна обеспечиваться протоколом канального уровня.
Если говорить про приборы учёта соответствующие СПОДЭС, то у них, при обмене данными через оптопорт применяется протокол канального уровня HDLC, который как раз и обеспечивает стабильность связи. Разумеется что поверх HDLC идет DLMS. Так вот, если вдруг при обмене данными произошла их утеря, то HDLC восстановит этот обмен с того места где данные потерялись. Причем эту возможность проверял лично, когда реализовывал HDLC и DLMS, и на оптопорту и на RS-485.
Поэтому могу лишь догадываться, что в вашем случае либо неправильно был реализован HDLC, либо протокол канального уровня не использовался вообще, либо аппаратная часть оставляет желать лучшего.
:) надо было совсем отказаться от стека DLMS/COSEM и сделать что-то свое, ведь IEC 62056-21 это один из стандартов стека DLMS/COSEM.
Так насколько стек DLMS/COSEM «тяжелый» и по сравнению с чем? Наверно если бы он был таким «тяжелым» то LoRa Alliance не стала бы сотрудничать с ассоциацией DLMS UA и вести работы по созданию нового коммуникационного профиля для сетей LoRaWAN.
Насколько он "тяжёлый" и по сравнению с чем? В каком конкретном случае он отвратительно показал себя на практике?
А что, atmega круче чем stm?
Уже теплее :) сколько программистов работало над проектом? Дело в том, что из той информации которая есть в заметке, можно сделать следующий вывод: один программист написал за год 38334 строк кода, попутно реализовав при этом 60870-5-101 и ModbusRTU. При этом его постоянно дёргали на другие проекты, да и ТЗ постоянно менялось… Так сколько времени в итоге было потрачено на проект?
А Вы один написали 38334 строк кода?
Я правильно понимаю, что эту программу можно использовать вместо пакета ppp и тех скриптов которые приведены в заметке? Есть на нее документация или только исходный код?
Оказывается SSD диски уже были, когда в Олимпии прошли 15-е Олимпийские игры (720 год до нашей эры :)
А что там надо контролировать с сертификатами? Let's Encrypt, certbot… и что там контролировать… тем более уже сейчас хостинги это делают бесплатно и быстро, нужна только заявка от пользователя.
или наоборот, понизить :) ведь если человек не понимает сам чего он хочет от жизни, если он стремиться быть «успешным» следуя принципам «успешных людей» и применяя их методики, способы организации рабочего дня и пр., не факт что в конце пути он достигнет успеха «успешных людей». Но в погоне за этой успешностью может пролететь вся жизнь… а человек как был неудовлетворенным, так им и останется.
Мне кажется главное что объединяет успешных людей, так это их энтузиазм, оптимизм и стремление к самосовершенствованию имея эти три составляющие, человек будет и читать, и экспериментировать, и ходить и т.п. и делать он это будет без всяких пособий по тому как стать «успешным», поскольку для таких людей сама деятельность является своего рода кислородом без которого жить не возможно.
счастьемпроектами» :)Видимо так: 12+6*30 = 192.
В ответном же сообщении содержатся только запрашиваемые значения. Параметр COSEM Attribute Descriptor в ответном сообщении отсутствует, этим и объясняется то обстоятельство, что размер запроса больше, чем размер ответа. Тем не менее очень часто бывает так, что размер ответа превышает размер запроса, все зависит от размера запрашиваемого значения. Однако надо учитывать, что авторы статьи для расчета размера поля данных TCP рассматривали размер запрашиваемого значения равного четырем байтам, для всех протоколов.
И последнее, в случае запроса типа Get-Request-With-List в ответном сообщении содержится список запрашиваемых значений.
Отвечая на ваш вопрос про учет газа, скажу, что в протоколе DLMS/COSEM такие тонкости специфицированы.
Приведите, пожалуйста, альтернативу протоколу DLMS/COSEM или те самые «ещё одни универсальные протоколы».
Протоколов для передачи информации великое множество, DLMS/COSEM — это стек протоколов, он определят несколько уровней модели OSI, например прикладной, канальный и др. Стек протоколов DLMS/COSEM ориентирован в первую очередь на достижение взаимодействия между устройствами различных производителей в области учета энергоресурсов. Любой проприетарный протокол это вещь в себе, я не говорю что они хуже или лучше, нет. Но если все производители будут использовать один протокол обмена данных в своих устройствах, тогда не будет проблем с интеграцией такого оборудования.