Типовая задач — есть предприятие (завод, кампус, институт), надо купить умные счетчики и организовать учет. Тут лучше проприетарный протокол — он позволяет использовать возможности счетчика на 100%
Какие возможности прибора учета принципиально невозможно реализовать используя протокол DLMS/COSEM, но которые можно реализовать используя проприетарный протокол?
А DLMS/COSEM исходит из ИНОЙ предпосылки — есть ЗООПАРК разных счетчиков, но 95% поддерживают этот протокол. Причем выгоднее заменить эти 5%, а чем все 100%. То есть счетчиков много.
Зоопарк это место где много животных разного вида за которыми ухаживают и на которых можно посмотреть, как зоопарк соотносится с приборами учета? Здесь вы приводите какие то проценты, откуда они?
Встает вопрос — а ЗАЧЕМ владельцам счетчики с возможностью передачи информации? Что с этого получает владелец? При нашей модели, когда электричество оплачивает владелец счетчика — НИЧЕГО. При модели ДОХОДНОГО дома, где за электричество платит владелец дома, а не арендаторы — да, экономический смысл виден.
Вы тут опять всё в кучу намешали, и физических лиц и юридических… Скажу одно, применение протокола DLMS/COSEM позволяет избавиться, как вы говорите от того самого «ЗООПАРКА», поскольку становится возможным интеграция и взаимодействие оборудования разных производителей, ибо оборудование «одного вида». Вы же не думаете что приборы учета производит только одна компания?
Так что УВЫ. Какое-то применение в РФ этот протокол найдет лишь лет через 20, и то — ЕСЛИ нормативными документами потребуют, чтобы все новые счетчики имели эту функцию.
Россети уже об этом позаботились и сдается мне что этот протокол найдет применение в России не через 20 лет, а гораздо раньше.
Интересно, много ли приборов поддерживают подобный протокол в России. Почему то кажется что если и существуют такие то только совсем свежие разработки.
В комментариях к первой части публикации уже задавался подобный вопрос, я бы не сказал, что много приборов отечественного производства поддерживают этот протокол. Однако все больше производителей начинают обращать на него внимание и использовать в своих разработках. Повторюсь, конкретно у нас в стране компания ARGO сделала теплосчетчик поддерживающий этот протокол, а также у ЗАО Радио и Микроэлектроника есть электросчетчик РиМ 489.2Х.
Возможно есть решения на базе DLMS/COSEM и других отечественных производителей, но я таковых пока не встречал. Может плохо смотрел, не знаю, но если у кого-нибудь есть информация о решениях на базе DLMS/COSEM Российских производителей, будут рад если эту информацию предоставят в комментариях.
Сомнительно как то что подобный протокол реализовывали каких нибудь 51 совместимых микроконтроллерах или пиках.
Для 51 не знаю, но для «пиков» есть готовый стек DLMS/COSEM, в журнале КиТ можно прочитать короткую заметку о нем, для msp430 есть готовый стек, пост на habrahabr о нем здесь
Понятно, но ведь DLMS поддерживает передачу данных не только по PLC. Если так получилось что в данных условиях передача по PLC не обеспечивает требуемого уровня надежности, можно было бы, как вариант, использовать 485 или радиоканал… Возможно такое решение будет дороже или более «громоздким», но зато сохранилась бы интероперабельность…
Правильно ли я вас понял, что при использовании S-FSK профиля DLMS/COSEM, информация передаваемая от счетчика к устройству сбора данных, по силовым линиям, искажалась настолько, что устройством сбора данных она не воспринималась? Какие PLC модемы вы использовали?
По поводу CW модуляции, вы хотите по PLC передавать данные «морзянкой»? Не уверен что 100% амплитудная модуляция обеспечит более надежную передачу данных в условиях нестабильности параметров канала связи, чем FSK или S-FSK. Ведь помеха, как правило, вносит искажение амплитуды, а не частоты сигнала.
SLIP это устаревший протокол, вместо него сейчас используют более совершенный протокол PPP, который кстати прописан в профиле TCP-UDP/IP стека DLMS/COSEM.
Я имел ввиду что архивные данные представляют в виде таблиц на стороне клиента. А в приборе учета они доступны через объекты типа Profile Generic которые имеют более сложную структуру. Не совсем понял про Modbus и UART, а также в чем заключается простота и устойчивость, поясните пожалуйста.
Такая возможность есть. Архивные данные хранятся в объектах типа Profile Generic, а представляются в виде таблиц. Причем есть возможность осуществлять селективный доступ к архивным данным (например делать выборку по дате и времени, по диапазону номеров записей и пр.).
Про ФСК не в курсе, а вот Россети прописали в своей технической политике обязательное применение протокола DLMS/COSEM. В DLMS весь функционал счетчика представляется в виде COSEM объектов, т.е. в DLMS\COSEM, в частности, описывается интерфейсная модель счетчика, как с этим делом в 61850?
Если учесть, что Россети прописали в своей технической политике обязательное применение протокола DLMS/COSEM, то скоро он будет реализован у всех. Знаю что компания ARGO сделал теплосчетчик поддерживающий этот протокол, а также у ЗАО Радио и Микроэлектроника есть электросчетчик РиМ 489.2Х.
В статье есть глава «Отличие стандарта DLMS/COSEM от других стандартов обмена данными с приборами учета» почитайте её. Эта часть статьи дает лишь краткий обзор протокола, в последующих частях основные моменты протокола буду раскрыты более детально. Что касается «железок» и примеров опроса/управления датчиками можете посмотреть тут и тут.
В одной статье уместить описание всего протокола довольно сложно. Для того что бы стать членом DLMS UA и получить полный доступ к текстам стандарта зарегистрируйтесь здесь.
Действительно, протокол не идеален. Тем не менее альтернативы ему пока нет, а сам протокол позволяет обеспечить единую среду для структурного моделирования и обмена данными с приборами учета.
Какие возможности прибора учета принципиально невозможно реализовать используя протокол DLMS/COSEM, но которые можно реализовать используя проприетарный протокол?
Зоопарк это место где много животных разного вида за которыми ухаживают и на которых можно посмотреть, как зоопарк соотносится с приборами учета? Здесь вы приводите какие то проценты, откуда они?
Вы тут опять всё в кучу намешали, и физических лиц и юридических… Скажу одно, применение протокола DLMS/COSEM позволяет избавиться, как вы говорите от того самого «ЗООПАРКА», поскольку становится возможным интеграция и взаимодействие оборудования разных производителей, ибо оборудование «одного вида». Вы же не думаете что приборы учета производит только одна компания?
Россети уже об этом позаботились и сдается мне что этот протокол найдет применение в России не через 20 лет, а гораздо раньше.
Возможно есть решения на базе DLMS/COSEM и других отечественных производителей, но я таковых пока не встречал. Может плохо смотрел, не знаю, но если у кого-нибудь есть информация о решениях на базе DLMS/COSEM Российских производителей, будут рад если эту информацию предоставят в комментариях.
Для 51 не знаю, но для «пиков» есть готовый стек DLMS/COSEM, в журнале КиТ можно прочитать короткую заметку о нем, для msp430 есть готовый стек, пост на habrahabr о нем здесь
За модемы спасибо, погляжу.
По поводу CW модуляции, вы хотите по PLC передавать данные «морзянкой»? Не уверен что 100% амплитудная модуляция обеспечит более надежную передачу данных в условиях нестабильности параметров канала связи, чем FSK или S-FSK. Ведь помеха, как правило, вносит искажение амплитуды, а не частоты сигнала.
SLIP это устаревший протокол, вместо него сейчас используют более совершенный протокол PPP, который кстати прописан в профиле TCP-UDP/IP стека DLMS/COSEM.