Как стать автором
Обновить

Знакомство со стеком DLMS/COSEM для микроконтроллеров семейства MSP430 компании Texas Instruments

Время на прочтение4 мин
Количество просмотров10K
Всего голосов 14: ↑13 и ↓1+12
Комментарии11

Комментарии 11

Этот протокол еще та кака… Имел с ним дело.
Действительно, протокол не идеален. Тем не менее альтернативы ему пока нет, а сам протокол позволяет обеспечить единую среду для структурного моделирования и обмена данными с приборами учета.
Скажите пожалуйста, есть ли возможность получить, с помощью этого протокола, архивные данные из приборов учета? А то из той информации, что доступна для первого знакомства с протоколом неясен этот функционал. И если да то как это примерно выглядит на практике?
Такая возможность есть. Архивные данные хранятся в объектах типа Profile Generic, а представляются в виде таблиц. Причем есть возможность осуществлять селективный доступ к архивным данным (например делать выборку по дате и времени, по диапазону номеров записей и пр.).
Ну… Как бы не совсем таблиц. Протокол все же объектно ориентирован. На сей момент наиболее активно его используют французы, в частности Sagem. Физика — по заказу французов TI делает модемы на базе Piccolo.
Все вместе кривое, как турецкая сабля… Для сравнения: Тот же UART можно спокойно «запулить» в провода со скоростью 20 кбит/сек. Протокол — напр. MODBUS. Все намного проще и устойчивее в работе.
Ну… сейчас «балуюсь» CAN over PLC. Те же 20 кбит, но множественный доступ.
Я имел ввиду что архивные данные представляют в виде таблиц на стороне клиента. А в приборе учета они доступны через объекты типа Profile Generic которые имеют более сложную структуру. Не совсем понял про Modbus и UART, а также в чем заключается простота и устойчивость, поясните пожалуйста.
Наверное я не совсем понятно выразился. В свое время пользовался четырьмя книгами 7-1 редакции (зеленой/желтой/белой, голубой). Много раз, при чтении сих опусов возникал вопрос: а нафига все это?! Стандарт DLMS описывает много чего. Начиная с физического уровня ( кодирование FSK ) и заканчивая уровнем описания объектов. Так вот, начиная с кодирования FSK — намного проще реализация UART модуляцией CW. Для увеличения надежности можно использовать кодирование хемминга. «Пробиваемость» сигнала поболее, чем у FSK. Для реализации IP поверх UART есть готовые, проверенные десятилетиями решения типа SLIP ( serial IP ). Для обменf информацией намного проще MODBUS. Если брать протокол CAN, то еще проще. В общем мне до сих пор так и не понятно, зачем весь этот огород с DLMS… Ну и как результат: не получили 100% опроса приборов учета. Т.е. некоторые счетчики не отдают информацию в течении месяца. Хотя физически они в сети. Кстати, в Штатах, Англии, Германии более популярен протокол HomePlug AV с пакетами MODBUS TCP. Скорость для приборов учета 10 мбит. А вообще модемы до 1 гбит. Т.е. реализация проще и универсальнее по всем статьям…
Правильно ли я вас понял, что при использовании S-FSK профиля DLMS/COSEM, информация передаваемая от счетчика к устройству сбора данных, по силовым линиям, искажалась настолько, что устройством сбора данных она не воспринималась? Какие PLC модемы вы использовали?

По поводу CW модуляции, вы хотите по PLC передавать данные «морзянкой»? Не уверен что 100% амплитудная модуляция обеспечит более надежную передачу данных в условиях нестабильности параметров канала связи, чем FSK или S-FSK. Ведь помеха, как правило, вносит искажение амплитуды, а не частоты сигнала.

SLIP это устаревший протокол, вместо него сейчас используют более совершенный протокол PPP, который кстати прописан в профиле TCP-UDP/IP стека DLMS/COSEM.
Да, Были случаи сильного искажения информации на сетях в населенных пунктах с одноэтажной застройкой.
«Морзянка» это не амплитудная модуляция. Это… «морзянка»:) Модуляции в классическом понимании там нет. Алгоритм: есть максимальная несущая — нет несущей. И да, это устойчивее, чем S-FSK. Даже на примере открытой частоты 160 м ( примерно 2 мГц ): при скорости передачи данных 20 кбит имеем 100 периодов несущей на один бит информации. При детекторе рассчитанном на частоту 20 кГц шумов практически не видно. ( всплески — режектируем, до 20-40 периодов подряд фильтрует детектор ). Изменения амплитуды несущей ( затухание ) компенсируем компаратором. Вот и получается, что «морзянка» надежнее передает сигнал…

SLIP привел как пример. PPP это Point-to-Point Protocol ( не канальный ). В Prime реализован именно канальный уровень. По сути Ethernet, с классическими MAC адресами. Использовал PLC модемы G3 на основе TI Piccolo. Точно не помню какие, давно это было, но что то из TMS320.

Если вы сами разрабатываете модемы, то я бы рекомендовал QCA700 от Qualcomm / Atheros.Скорость до 10 мбит. HomePlug, Метод модуляции CDMA+Q-FSK.DSP и усилитель все в одном корпусе. Питание 3.3 V На основе ARM Cortex M3. Одновременно используется 100+ частот в диапазоне от 2 мГц до 68 мГц.
Понятно, но ведь DLMS поддерживает передачу данных не только по PLC. Если так получилось что в данных условиях передача по PLC не обеспечивает требуемого уровня надежности, можно было бы, как вариант, использовать 485 или радиоканал… Возможно такое решение будет дороже или более «громоздким», но зато сохранилась бы интероперабельность…

За модемы спасибо, погляжу.
Алгоритм: есть максимальная несущая — нет несущей. И да, это устойчивее, чем S-FSK.

FSK и подобное кодирование используют для того, чтобы не было проблем с постоянной составляющей — решают проблему скажем большого количество нулей или единиц подряд. Если передавать данные без кодирования, то в приёмно- передающих трактах с большой степенью вероятности будут возникать проблемы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации