Научно-технический центр Арго  
Москва: +7 (499) 677-17-10
Иваново: +7 (4932) 34-56-77
 
 
от учета к оптимизации потребления энергоресурсов
Логин
Пароль
Регистрация / Забыли пароль?

 
 
   

Система Orphus

+7 (4932) 34-56-77 (многокан.)
+7 (499) 677-17-10 (многокан.)

 
Страницы: 1 2 След.
Концепция SmartOn, интерфейсы
 
Concept SmartOn Device

Являясь интегратором различных типов измерительных приборов в единую систему НТЦ «Арго» накопил большой опыт по взаимодействию с творческими коллективами, реализовавшими отличные друг от друга концепции обмена данными с внешними системами. Не являясь, по сути, производителем первичных измерительных приборов (электросчетчиков, счетчиков тепла, газа, расходомеров для различных сред), но в активном взаимодействии с коллегами – разработчиками постепенно сформировалось представление об «идеальном» счетчике.
Невозможно реализовать в одиночку проект, который потенциально может повлиять на развитие приборостроения. Поэтому НТЦ "АРГО" ищет стратегического партнера (сообщество) для реализации концепции идеального счетчика.
Основные положения (детали сознательно опущены)
концепции «идеального» счетчика
1. Требования к конструкции счетчика
1.1. Корпус должен предусматривать наличие четырех независимых отсеков, каждый из которых имеет возможность независимой пломбировки.
1.1.1. Первый отсек для интерфейсных компонент. Желательно иметь два крейта с унифицированным интерфейсом. Необходимо реализовать следующие интерфейсные модули:PLC, GSM/GPRS, Bluetooth, оптопорт, радиоканал,
RS-485, RS-232, Ethernet.
1.1.2. Второй отсек собственно для измерительной части (может быть заменен для смежных приложений). Конструктив измерительной части должен быть инвариантен к функциональному назначению.
1.1.3. Третий отсек для входных коммуникационных и отключающих (ограничивающих) элементов.
1.1.4. Четвертый отсек для системы индикации-навигации (в некоторых частных реализациях может отсутствовать).
Подобная конструкция счетчика подходит и для сплит-систем, и для теплосчетчика и для коммуникатора-УСПД, что позволяет строить расширяемые многофункциональные системы.

Дизайн концепт модели приведен ниже.

2. Требования к протоколу.
Вокруг этого вопроса сегодня ведутся жаркие споры, переходящие в подковровые интриги и откровенные войны. В самом деле, вопрос нешуточный. Объективно складывается такая ситуация, что каждый производитель счетчиков имеет свой взгляд на процедуру обмена данными с внешним миром. Причем не только имеет этот самый взгляд, но что более важно и реализацию в софте и «железе». Эти реализации затрагивают и интеграторов, которые вынуждены поддерживать все прихоти разработчиков по «низу». В совокупности это немалые затраты и ни одна из сторон без крайней нужды на революционные переделки не пойдет. Если обратится к опыту «запада», то и там по сути единого подхода так же нет. Имеются крупные финансовые группы, которые продвигают те или иные стандарты. Какая из них возьмет верх трудно сказать. Не факт, что победит в этой схватке оптимальный в техническом плане подход.
Но можно посмотреть на эти (по сути экономические) процессы философски. Как бы не встали звезды с «протокольной» политикой над ними все равно будет довлеть TCP IP. Конечно, новый IP V6 (да и V4) не целесообразно (в ряде случаев и невозможно) использовать на «тихоходных» каналах, таких, как например PLC. Поэтому «внизу» на наш взгляд, можно оставить и «фирменный» канал, потребовав WEB сервер над «фирменным» концентратором. WEB сервер без труда при наличии интерфейсного крейта (например, как опцию) можно разместить и в счетчике предлагаемой конструкции. Этот «надплатформенный» интерфейс даст необходимую широту для «технического» маневра как производителям счетчиков, так и интеграторам.
Вывод: в «переходный» период к единому протоколу «разрешить» фирменные протоколы и использовать WEB сервер как средство по унификации обмена данными между счетчиками и «верхним» уровнем.

Первоначальный вариант
Скрытый текст

Промежуточный вариант
Скрытый текст
Открываем коробочку
Скрытый текст
Прототип SmartOn'а с 3D принтера
Скрытый текст
Начинка SmartOn'а
Скрытый текст
 
Ежедневно, по мере разработки проекта, прходится решать массу мелких и серьезных задач." Внутренние" проблемы, такие как интерфейсы , взаимодействие систем, служб, в Smarton"е решаются по мере их возникновения рабочими группами. "Внешние" задачи, такие, как интерфейсы пользователя, навигация, внешние интерфейсы, полезно обсуждать с широкой аудиторией. Предлагается обсудить несложный на первый взгляд вопрос: сколько кнопок навигации целесообразно предусмотреть и не пора ли перейти на "немеханические" кнопки? Буду очень признателен, если кто-то поделится своими соображениями.
 
Гораздо более актуальным вопросом, чем вопрос о количестве и типе кнопок является проблема внешнего интерфейса. Всвязи с "угрозой" введения единого для пост- МРСК структур документа: "ТИПОВОЙ СТАНДАРТ о технической политике по учету электроэнергии в распределительном электросетевомкомплексе дочерних и зависимых обществ ОАО «Россети»,осуществляющих деятельность по распределению и передаче электрической энергии (ДЗО) " и указанием сроков (до 27.05.13) подачи соображений на эту тему она (эта тема) приобретает разряд "горящей".
Мы готовим свои предложения по этому вопросу. Я же позволю себе немного " пофилософствовать" на эту тему. Припоминаются в этой связи 60 - е годы, когда всерьез обсуждался язык международного общения - эсперанто. Во многих странах были сподвижники этого направления, организованы молодежные лагеря по продвижению этого языка, но что из этого получилось мы знаем. Эсперанто так и не ожил, его место фактически занял английский в разных подмножествах: технический, туристический... Нечто подобное мы наблюдаем и в области "протоколостроения". Разработать "универсальный" протокол дело очень ответственное, хлопотное и под силу не просто крупным структурам, но и обладающими научной школой в этом направлении. Это, к сожалению, мы утеряли. Поэтому реальный выход - это примкнуть к серьезному сообществу, где вопросы с интерфейсом уже решены. Наивно думать, что все проблемы сразу решатся. Они только начнутся. Взять хотя бы вопрос о лигитимности использования этого протокола (предлагается IEC 62056 (DLMS/COSEM). За его использование предлагается изрядно раскошелиться. Не все на это готовы. Поэтому говорить, как это указано в "ТИПОВОМ СТАНДАРТЕ": Приборы учета и ИВКдолжны иметь открытые стандартные протоколы обмена данными по всем своим цифровым интерфейсам, соответствующие стандарту IEC 62056 (DLMS/COSEM). Они должны быть полными и непротиворечивыми, позволяющими специалистам реализовать эти протоколы, с текстовым описанием на русском языке противоречит самому духу коммерческого стандарта. На мой взгляд необходимо разработать "упрощенную" версию стандарта, опубликовать его на сайте, а дальше по мере роста взаимопонимания его "доводить" и "углублять". И ни в коем случае не "запрещать" локальные протоколы. Поскольку они реальны, а DLMS/COSEM - для "продвинутых" типа эсперанто.
Надеюсь на активное обсуждение этой проблемы со стороны заинтересованных лиц.
И. Кашманов
 
На мой взгляд, протоколы приборов учета должны отвечать следующим пожеланиям:

1. В пакетах должны быть начальные и конечные ограничители. Использование в качестве ограничителей пакетов временных интервалов (как в ModBus RTU) не всегда приемлимо, т.к., эти временные интервалы могут искажаться коммуникационным оборудованием (например, при связи через GSM SCD), и , как следствие, на приемной стороне возможно ложное обнаружение начала/конца пакета . Если байты в теле пакета совпадают с ограничителями, то можно использовать байт-стаффинг.
2. В запросах и ответах должен быть идентификатор пакета (при запросе генерируется путем последовательного инкрементирования или случайным образом, в ответе копируется из запроса). Наличие идентификатора запроса позволит избежать ошибок интерпретации принятых данных при повторах запросов. Особенно это актуально при использовании самоорганизующихся сетей, где время ответа на запрос заранее неизвестно.
3. Желательно в запросах управлять длиной ответа, например, передавать маску считываемых параметров. Протоколы, предусматривающие для чтения каждого параметра отдельный запрос, неудобны на низкоскоростных каналах связи. Если в ответе на запрос передается длинный массив параметров, то будут ограничения по использованию коммуникационного оборудования с малым объемом буферной памяти.
4. Для работы на низкоскоростных каналах связи протокол прибора учета должен быть по возможности лаконичным: данные должны представляться в компактных форматах без указания названий параметров и единиц измерения. Нежелательно представление данных в виде ASCII-строк.
5. При чтении архивных данных из приборов учета протокол прибора учета должен предусматривать возможность чтения как отдельной записи из архива, так и группы смежных записей.
6. При работе с архивами приборов учета должна быть предусмотрена возможность чтения индексов (номеров в базе) записей архивов самой ранней и самой поздней по времени без выполнения операций поиска по базе архивов. Альтернативный вариант организации архивов приборов учета – самая поздняя по времени запись архива имеет фиксированный индекс (например, 0). Во избежании неопределенности в интерпретации данных, в теле ответа желательно указывать временные параметры запроса.
7. Для связи с приборами учета нежелательно использовать протоколы обмена, имеющие следующие особенности:
- различные значения стартовой и рабочей скорости обмена (из-за сложностей с применением для связи с прибором модемов различных типов);
- однократная за сеанс связи с прибором передача сетевого идентификатора прибора при открытии канала связи (сетевой адрес прибора должен передаваться в каждом запросе/ответе);
- передача пароля прибора в открытом виде.
8. В приборе учета должна быть команда фиксации текущих значений параметров качества энергии и возможность чтения зафиксированных значений.

К сожалению, известные мне стандартные протоколы передачи данных не отвечают приведенным пожеланиям, и, наверное, с учетом разнообразия типов используемых каналов связи, ресурсов контроллера в приборе учета, особенностей организации данных в приборе и других факторов, использование нестандартных протоколов для связи с приборами учета неизбежно.
Изменено: Олег Лушин - 20.05.2013 22:09:25
 
Выскажу свои соображения по поводу протокола обмена.

1. Конкретно в моих приборах - счетчиках ГАММА - структура баз данных прибора довольно прочно привязана к протоколу обмена - ГАММА И2(И3). При смене протокола потребуется переделка как минимум 30% программного обеспечения. И так как современный счетчик ГАММА-И3 имеет лостаточно обширную базу данных как по емкости, так и по функционалу, то тестирование и выявление ощибок - длительный процесс.
2. Идеального протокола действительно быть не может - из-за многообразия каналов данных.
3. Маркер начала и конца - дело хорошее. Но в каналах с большой вероятностью ошибок он даст ложные срабатывания. Мы это проходили на протоколе ГРАНИТ. Для борьбы с делением и склеиванием кадров при передаче мы даем возможность гибко менять таймауты (в версии протокола И3). Еще одна возможность - приняв заголовок кадра можно точно определить число байт в кадре. Все это разумеется не идеал.

Итоги:
Конечно, очень хотелось бы иметь универсальный протокол обмена. Плюсы несомненны. Реализовал протокол в своем счетчике - и ты вхож во все системы сбора. Не надо ломать голову над изобретением новых команд. Но разработка такого протокола - действительно дело долгое и хлопотное, боюсь непосильное для производителей счетчиков. Тем более каждый производитель будет тянуть одеяло на себя.
Эту задачу могли бы (и должны по сути) взять на себя федеральные организации. Ну по крайней мере собрав производителей и поставив перед ними такую задачу.
Пока же мы попробуем сами найти общий язык с некоторыми производителями.
 
Разработка универсального протокола обмена для приборов учета тема интересная и Инкотекс присоединяется к обсуждениям в этом форуме и даже готов предоставить для обсуждения свое решение, еще не реализованное в серийной продукции. Вместе с этим хотелось бы выслушать мнения о существующих стандартах продвигаемых ассоциацией DLMS и производителем сетевого оборудования CISCO.
 
Было бы интересно ознакомиться с основными решениями Инкотекс по новому протоколу приборов учета. Каковы основные отличия нового протокола от протокола серийно выпускаемых счетчиков Меркурий-20x/23x?
 
Наш ответ РосСетям:

Предложение Арго по техполитике
 
Глас вопиющего в пустыне

На заре перестройки я смеялся над рекламой; "Молодежь выбирает пепси".
Сейчас не смеюсь - после промывания мозгов молодежь в самои деле активно потребляет эту отраву.
Я далек от политики и на выборы не ходил. Сначала выбирать из одного было глупо, Сейчас держут за лохов - пипл схавает.
Сейчас заставлю себя идти.
Мы превратились в стадо баранов, простите, общество потребителей. За нас кукловоды решают как нам жить, а мы бурчим по своим норам.
Но вкрнемся к нашим баранам. За нас решают каким быть интерфейсам (читай- кого допустить к торгам), а мы молчим сложа руки.
Люди! Откликнитесь! Ал-р Лазaревич! Скажи свое веское непечатное слово.
 
Унификация протоколов обмена приборов учета- звучит заманчиво, а практическая польза, увы, минимальная.Приборы различных производителей, декларирующих соответствие каким-либо стандартным протоколам, все равно требуют собственного "фирменного" софта. Казалось бы, стандарт МЭК-61107 определяет и конструкцию оптопорта, и логику информационного обмена, и вот- сделай все по стандарту и должна быть совместимость и со своими программами, и с программами сторонних разработчиков. На практике же даже оптопорты разных производителей не взаимозаменяемы, какие-то работают с другими счетчиками, какие-то почему-то нет (но все по стандарту). А уж с программным обеспечением и вовсе никакой взаимозаменяемости. Но у всех реализовано по МЭК-61107, но только то контрольная сумма считается по-разному, то массивы данных передаются разными способами, то есть нюансы, связанные с передачей паролей, чтением данных, организацией архивов прибора. И какова практическая польза от такой унификации? Только в том, что мы априорно представляем, как должен выглядеть запрос в счетчик? Но логика работы с каждым счетчиком и способы интерпретации данных все равно уникальны.
Изменено: Олег Лушин - 08.07.2013 07:30:55
Страницы: 1 2 След.
Читают тему