Отправлено: 30.05.08 18:05. Заголовок: MBAGZU: Разработка стандарта обмена данными с АГЗУ по Modbus

Животрепещущий вопрос... На данный момент нет ни одного хорошо документированного, продуманного и способного к развитию стандарта, описывающего обмен данными с станцией управления АГЗУ, карты адресов, типы переменных, алгоритмы управления процессом измерения, выкачивания архивов по замерам, аварийным ситуациям и т.п. Полагаю, что все, кто поработал в данной области, рано или поздно устают изобретать велосипед ( или осваивать технику езды на уродце) каждый раз для каждой вновь разработанной станции управления ( появившейся потом в НГДУ). Так почему бы не попытаться разработать стандарт де-факто, который позволит прекратить чехарду в этом вопросе? В качестве примера успешного подхода - сам стандарт Modbus, который стал стандартом "де факто" в силу всего нескольких факторов:

- простого и ясного, а главное подробно документированного описания команд и идеологии применения;
- сознательного абстрагирования от частных целей применения;
- открытости, и заложенной изначально возможности доработки.

Предлагаю начать обсуждение для того, чтобы:

1) определить цели, стоящие перед системой телемеханики при работе с АГЗУ;
2) определить ограничения, накладываемые на Modbus обмен реалиями удаленной связи;
3) определить критерии правильного построения:
- карты адресов обмена, набора и типов переменных;
- способов управления исполнительными механизмами и процессом измерения параметров дебита;
- необходимого набора наблюдаемых данных для мониторинга и диагностирования состояния;
- необходимого набора функций управления АГЗУ;

говоря проще, на первом этапе требуется сформулировать набор правил, руководствуясь которыми можно приступить к разработке универсального стандарта интеграции АГЗУ в системы телемеханики. Не обязательно по Modbus, т.к. это только транспортный уровень.

Никаких требований к связности мыслей для участников обсуждения... Систематизацию и выводы мы берем на себя, но все-таки это будет происходить коллегиально - варианты будут выкладываться здесь и приниматься после обсуждения преимуществ и недостатков решения. Со своей стороны обещаем претворение в жизнь этого стандарта в станциях управления наших АГЗУ, и если это получится, то и разработку некоего SDK - набора тестовых и отладочных утилит, библиотек под наиболее распространенные языки программирования и набора документации, описывающего стандарт. В общем, всего, что нужно разработчику станции управления АГЗУ с одной стороны, так и разработчику системы телемеханики, интегрирующему АГЗУ в АСУТП предприятия.

Для начала обсуждения выкладываю вот эту пробу пера - начато пару лет назад, многое уже видится по другому, но тем не менее - надо же с чего-то начинать? Так почему бы не с этого? Выкладывайте все, что у вас есть, будем обсуждать, и, надеюсь, ни одна здравая мысль не пропадет, если будет высказана здесь, а не "здравая" путем обсуждения будет вылечена и опять таки послужит хорошему делу.

Для тех, кто предпочитает личное общение, в моем профиле указаны e-mail и ICQ UIN. C благодарностью приму любые замечания, предложения, дополнения и указания на ошибочное понимание предмета - как здесь, на форуме, так и по другим средствам связи.

 Отправлено: 30.05.08 20:37. Заголовок: Итак, цели, стоящие ..

Итак, цели, стоящие перед системой телемеханики при работе с контроллером АГЗУ:

1. Мониторинг состояния КИПиА АГЗУ, в том числе:

1.1 Технологического оборудования, такого как:

- датчики дискретные;
- датчики аналоговые;
- счетчики числоимпульсные;
- интеллектуальные датчики и счетчики (Modbus,Hart,Profibus);
- переключатель скважин ПСМ или другое распределительное устройство;
- неуправляемые регуляторы расхода или перепада давления (оборудованные датчиками положения);
- управляемые краны, клапана и другие регулирующие устройства;

1.2 Оборудования системы обеспечения безопасности, в том числе:

- газоанализаторы и определители концентрации взрывоопасных газов\паров;
- датчики пожара\детекторы дыма;
- датчики доступа в помещения и шкафы;
- датчики температуры в помещениях;
- датчики контроля безопасных границ технологических параметров
(избыточного давления в установке, температуры измеряемой среды и т.п.)
- звуковая и световая сигнализация оповещения об аварии;
- система принудительного вентилирования помещений;
- система аварийного обесточивания установки;

1.3 Состояния контроллера станции управления, в том числе:

- целостность и правильность функционирования ПО контроллера;
- целостность метрологических коэффициентов и настроек оборудования;
- целостность технологических и прочих коэффициентов и настроек;

2. Мониторинг состояния процесса измерения АГЗУ, в том числе:

- текущее состояние(фаза) процесса измерения;
- текущие значения технологических параметров;
- интегральные значения технологических параметров с начала измерения;
- средние значения технологических параметров с начала измерения;

3. Синхронизация технологических и прочих коэффициентов и настроек, как при изменении их на верхнем уровне АСУТП, так и при изменении их локально, на местной консоли станции управления, т.е. в одном случае запись изменений сверху, в другом - определение наличия изменений и вычитывание значений из контроллера при их изменении внизу;

4. Считывание результатов измерения, как сразу после окончания, так и в случае долгого
отсутствия связи - т.е. глубокий архив результатов;

5. Считывание журнала событий, как сразу после их появления, так и в случае долгого
отсутствия связи - т.е. глубокий архив журнала событий. События включают в себя отказы оборудования, датчиков, срабатывания датчиков системы обеспечения безопасности, случаи выхода технологических параметров за установленные пороги и т.п.;

6. Управление процессом измерения и станцией управления, в том числе
- управление пропусками\окончаниями фаз измерения;
- управление ПСМ (поиск заданного отвода, блокировка на отводе);
- синхронизация времени\календаря контроллера с верхним уровнем;
- полный перезапуск ПО контроллера по запросу;

7. Удаленное тестирование технологического оборудования, в том числе:
- организация прямого доступа к интеллектуальным датчикам (шлюз к подчиненным Modbus устройствам АГЗУ);
- специальный диагностический режим эксплуатации, позволяющий не допускать проведения измерений при удаленной настройке и диагностике КИПиА АГЗУ;

8. Удаленное обновление и дополнение ПО контроллера.

---

как много букв! попробуем упростить:

пассивные функции:

хочется
1) узнать, что за установка, что за ПО стоит, какая версия стандарта обмена поддерживается, кто производитель, кто и когда аттестовал и поверил, кто пусконаладчик и на каком объекте установлена.
2) смотреть, что происходит с технологией;
3) смотреть, что там с безопасностью эксплуатации;
4) смотреть, что там с контроллером, ПО и метрологическими константами;
5) смотреть, что там с настройками измерения и отводов;
6) смотреть текущее состояние измерения;
7) читать журнал событий – отказы КИПиА, события безопасности, смена фаз измерения и т.п. на случай отсутствия связи;
6) читать архив измерений - последнего, последних по отводам, в глубину на месяц;

активные функции:

нужно
1) синхронизировать настройки с верхним уровнем, как сверху-вниз, так и снизу-вверх;
2) управлять измерением (поиск отвода, пропуск фаз замера, пуск-стоп измерения, давать задания на последовательность замеров);
3) иметь прямой доступ к интеллектуальным КИПиА АГЗУ и куста ( для диагностики, мониторинга и настройки) через шлюз протокола Modbus линий интерфейса RS232, RS485, Ethernet;
8) синхронизировать время на контроллере с верхним уровнем;
9) удаленно обновлять и дополнять ПО контроллера;
10) удаленно аппаратно перезапускать контроллер на случай зависания;

прошу критиковать, дополнять, опровергать заблуждения, расставлять приоритеты, уточнять практическую ценность этих домыслов и т.п. Ибо "спасение утопающих - дело рук самих утопающих" (с) народ . А не то наворочу, что в голову придет, и распространю, вам же потом мучиться, писать поддержку и ругать, что все криво и опять вас никто не спросил. Так что объявляю девиз разработки - "!Только ленивый не пнет MBAGZU!", а за одного битого, как известно, двух небитых дают.

 Отправлено: 01.06.08 21:35. Заголовок: Теперь ограничения....

Теперь ограничения...

существует несколько подходов к организации обмена данными верхнего уровня телемеханики и контроллера АГЗУ:

1. Кустовой контроллер служит простым шлюзом между радиоканалом и контроллером АГЗУ - приходящие сверху запросы Modbus (часто вложенные в пакеты радиосвязи иного формата) пересылаются контроллеру АГЗУ, и, если тот отвечает, то ответ пересылается обратно (при необходимости запаковывается в формат пакетов радиосвязи). Т.е. кустовой контроллер не вносит никаких преобразований и не анализирует передаваемые данные, работая ретранслятором, а по сути происходящего выполняя роль радиомодема (имеется в виду взаимоотношения с контроллером АГЗУ, по отношению к остальному оборудованию куста функции могут быть очень даже интеллектуальными);

2. Кустовой контроллер локально, по заложенной в него программе периодически опрашивает определенные регистры контроллера АГЗУ, сохраняя значения в своей памяти, реагируя на некоторые изменения в содержимом читаемых регистров опросами дополнительных областей. Получаемые при этом данные преобразуются и группируются, верхний уровень обменивается данными с кустовым контроллером, забирая и присылая данные в его формате;

3. Сочетание вариантов 1 и 2, локальный опрос и управление, дополненный механизмом сквозного обращения с верхнего уровня ТМ к станции управления АГЗУ;

Специфика недостаточности описания стандарта Modbus и использование радиоканала накладывает следующие ограничения:

- размер пакета радиосвязи ограничивает размер данных, передаваемых за один сеанс обмена. И если в Modbus это ограничение 125 регистров, то требования радиосвязи к пакету, зачастую включающему в себя дополнительные служебные поля, уменьшает это значение;

- количество сеансов обмена Modbus в цикле опроса должно быть минимальным: значит структура данных должна быть компактной, и, по возможности, непрерывной; данные желательно располагать в одной области Modbus - т.е. inputs, coils, input registers однозначно проигрывают в универсальности применения области holding registers, тем более что начальный уровень соответствия Conformance class 0 протокола Modbus ограничивается всего двумя командами, работающими именно с ней - read multiple registers (команда 3) и write multiple registers (команда 16);

- кустовые контроллеры и программы верхнего уровня, несмотря на то, что в описании протокола Modbus явно указан допустимый диапазон адресов запроса 0...65535 (соответственно номеров 1...65536) нередко не поддерживают адресацию вне диапазона 0...9998 (1...9999). Значит, данные следует располагать именно в этом общеупотребительном диапазоне адресов;

- cуществует насущная необходимость передачи многорегистровых переменных ( int32, uint32, float32 и т.п.), реализация которой в контроллерах выполнена по разному. Самой существенной проблемой при этом является различие порядка байтов в таких переменных. Стандарт Modbus только косвенно декларирует, что для адресов и элементов данных (data items) используется модель "big-endian", тогда как data items в понимании протокола ограничиваются битом (single bit) и 16-разрядным словом (16-bit word). Этот просчет в описании протокола обернулся рядом проблем, самая главная из которых - то, что 32-разрядные числа с плавающей запятой теперь передаются как в "big-endian" (порядок байт 3-2-1-0), так и в "middle-endian" (порядок байт 1-0-3-2). Формально выполняя требования стандарта Modbus по порядку байтов внутри 16-разрядных слов, разработчики реализаций протокола принимают, как правило, компромиссное решение относительно порядка слов в многорегистровых типах данных - если процессор контроллера имеет "little-endian" адресацию памяти, то гораздо проще реализовать "middle-endian" в пакетах Modbus, нежели настоящий "big-endian". Но, поскольку возможно любое сочетание контроллеров в качестве кустового и станции АГЗУ, то следует или однозначно определиться с выбором варианта, или обеспечить поддержку обоих вариантов передачи двухрегистровых переменных со стороны подчиненного устройства;

 Отправлено: 02.06.08 07:23. Заголовок: Радик пишет: вот э..

Радик пишет:

цитата:

вот эту пробу пера

Сюда наш прокси почему-то не пускает ...

цитата:

3) иметь прямой доступ к интеллектуальным КИПиА АГЗУ и куста ( для диагностики, мониторинга и настройки) через шлюз протокола Modbus;

Радик, Ethernet Вы по какой причине не рассматриваете. У нас сейчас внедряются широкополосные каналы до кустовых площадок.

Владимир, РН-Юганскнефтегаз.

 Отправлено: 02.06.08 09:55. Заголовок: Vlad_UA9JKW Ок, Eth..

Добрый день,Владимир
Ок, Ethernet`ом дополню. Из наших контроллеров его пока поддерживает только SCADAPack32, и, возможно, DL205\260 с доп.модулем. Заполните поле e-mail в профиле участника форума, вышлю документ почтой. Прокси ваш закрывает, видимо, потому что это бесплатное хранилище файлов. У нас пока тестовый период эксплуатации форума, так что документы храним там.

 Отправлено: 02.06.08 10:04. Заголовок: Vlad_UA9JKW, интерес..

Vlad_UA9JKW, интересно, почему такой ник? радиолюбитель коротковолновик, и это ваш позывной? Запоминать не трудно?

 Отправлено: 02.06.08 10:12. Заголовок: Радик пишет: Т.е. к..

Радик пишет:

цитата:

Т.е. кустовой контроллер не вносит никаких преобразований и не анализирует передаваемые данные, работая ретранслятором, а по сути происходящего выполняя роль радиомодема;

По отношению к контроллеру АГЗУ функции кустового контроллера во многом сводятся к запросу и трансляции данных.
Но на кустовой площадке, кроме АГЗУ, много других устройств:ЭЦН(ШГН),НОТ,УДХ,БВГ,КТП и РУ,устьевая запорная арматура и пр., управление которыми организует кустовой контроллер. Замер дебита-длительный процесс, тут кустовой контроллер,по-моему, существееных ограничений контроллеру АГЗУ не внесет. Кустовому контроллеру важнее мгновенно передать на пульт цеха добычи информацию об остановке(запуске) скважины или текущие данные с его станции управления. Так же быстро нужно передать команды на переключение устьевой арматуры и других устройств, нежели информацию о замерах. Большой беды нет, если замеры придут с опозданием на в несколько минут - в замерах имеется синхронизированное время.

Я несколько раз писал в ТУ на АГЗУ о необходимости внесения в ПО контроллера АГЗУ с ПСМ пересчет суточных замеров скважин, работающих в периодическом режиме. Сейчас что-то у Вас делается по этому вопросу? При таком дорогостоящем контроллере уже нет смысла складывать подручными средствами отдельные куски замеров периодических скважин в суточный отчет ...

 Отправлено: 02.06.08 10:22. Заголовок: Радик пишет: и это ..

Радик пишет:

цитата:

и это ваш позывной

Позывной уникален, на всем земном шаре друго такого(UA9JKW) нет, поэтому он идентифицирует меня и мое местоположение
однозначно ...

 Отправлено: 02.06.08 10:44. Заголовок: Радик пишет: Заполн..

Радик пишет:

цитата:

Заполните поле e-mail в профиле участника форума, вышлю документ почтой

Заполнил, высылайте.

 Отправлено: 02.06.08 12:40. Заголовок: Vlad_UA9JKW пишет: ..

Vlad_UA9JKW пишет:

цитата:

Я несколько раз писал в ТУ на АГЗУ о необходимости внесения в ПО контроллера АГЗУ с ПСМ пересчет суточных замеров скважин, работающих в периодическом режиме. Сейчас что-то у Вас делается по этому вопросу?

Сейчас отрабатывается идеология работы с периодическими скважинами, причем требования к реализации у заказчиков разнятся (далее описывается специфика работы со скважинами, помеченными в реквизитах как периодические):

1. Периодические скважины исключаются из круга автоматического измерения, ставятся на замер по команде с диспетчерского пункта. Обсчет и приведение к суткам выполняет система верхнего уровня. Иногда фиксируется время на замере - строго 24 часа.

2. В контроллер АГЗУ заводятся данные о ТСС скважинного оборудования (включена подача или нет), дискретными входами или словом состояния, которое по Modbus поддерживает в актуальном состоянии контроллер куста. Контроллер АГЗУ по TCC определяет периодичность включения, набирает статистику по отработанному времени за сутки, после 2-3 включений прогнозирует период и составляет отдельный круг обхода. Потом прогнозирует время включения, встает заранее на отвод и выполняет замер, ожидая сначала подачи ТСС, а затем снятия ТСС. Если прогнозируемое включение не происходит, то после таймаута ожидания продолжается работа с основным кругом обхода или с следующим периодическим отводом. Вычисление суточных параметров подачи осуществляется именно с учетом статистики работы отвода по ТСС. Данные этапа замера "коррекция" используются для расчета суммарной массы, но показания по разделению фаз (нефть \ вода) для этого этапа принимаются равными средним за этап "измерение".

вариант 1 уже реализован в последней версии ПО ОЗНА-МАССОМЕР на SCADAPack32, введен в ТНК-ВР Нягань, поддержка сверху пока только пишется.

вариант 2 на этапе отладки и тестирования, к концу лета ожидаем ввод в действие в СургутНефтегазе.

 Отправлено: 02.06.08 12:47. Заголовок: Vlad_UA9JKW пишет: ..

Vlad_UA9JKW пишет:

цитата:

Большой беды нет, если замеры придут с опозданием на в несколько минут - в замерах имеется синхронизированное время.

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

 Отправлено: 02.06.08 14:11. Заголовок: Радик пишет: Прокси..

Радик пишет:

цитата:

Прокси ваш закрывает, видимо, потому что это бесплатное хранилище файлов.

Может разместите основные прежние тезисы здесь или вышлете по почте?

 Отправлено: 02.06.08 14:23. Заголовок: Файл объемный, так ч..

Файл объемный, так что у кого есть проблемы с доступом на ifolder.ru обращайтесь ко мне на e-mail запросом с темой "MBAGZU.PDF", вышлю.
Vlad_UA9JKW , Вам уже выслал.

 Отправлено: 07.06.08 13:56. Заголовок: Расположение данных в зоне Modbus

Для нас, разработчиков систем сбора , обработки и отображения информации, самый главный вопрос - расположение данных в зоне Modbus. Основные данные по ГЗУ это замеряемый отвод, наличие аварии, фаза замера (замер, переключение, останов) должны лежать для различных версий ПО ГЗУ в одних и тех же адресах. Основные команды управления тоже должны лежать в одних и теже ячейках. Архив замеров тоже желательно чтобы не менялся от версии к версии. Формат основных данных тоже не должен изменяться.

 Отправлено: 24.06.08 18:19. Заголовок: Для нас, разработчик..

цитата:

Для нас, разработчиков систем сбора , обработки и отображения информации, самый главный вопрос - расположение данных в зоне Modbus. Основные данные по ГЗУ это замеряемый отвод, наличие аварии, фаза замера (замер, переключение, останов) должны лежать для различных версий ПО ГЗУ в одних и тех же адресах. Основные команды управления тоже должны лежать в одних и теже ячейках. Архив замеров тоже желательно чтобы не менялся от версии к версии. Формат основных данных тоже не должен изменяться.

+1 Внесу свои 5 копеек.

1. Все регистры должны быть фиксированы в том плане, что в "пробе пера" была мысль выставлять в заголовке смещение для начала какой-то группы параметров. Лично наша утилита, отвечающая за опрос по Modbus протоколу не сумеет для каждой отдельной ГЗУ на лету вычислять смещение для чтения того или иного параметра.

2. На последнем этапе составления этого стандарта его следует оптимизировать. Дело в том, что для меня (программиста верхнего уровня) головной болью является скорость опроса по Modbus протоколу. Если я не ошибаюсь, то быстрее отослать 1 запрос на чтение массива из 3 регистров нежели 2 запроса на чтение 1 регистра каждый. Соответственно на финальном этапе, с учетом зарезервированного на будущее места и прочих факторов, смещения должны быть отсортированы так чтобы всю группу можно было бы прочитать как можно меньшим количеством запросов. В первую очередь это получается сортировка по логической принадлежности (уставки, текущие параметры, архив и т.д.). Во вторую очередь это сортировка по используемым функциям чтения и записи (именно чтения и записи, то есть все регистры группы должны и читаться и писаться доной функцией чтения и одной функцией записи).
В третью очередь это должна быть сортировка по вероятному использованию.

3. В текущей версии используются несколько битовых масок (3 для управления отводами, 1 для флагов текущих ошибок, 1 для управляющих флагов). Насчет "Насос скважины работает/не работает" или "Отвод измеряется/не измеряется" - это ладно, так и по количеству отводов это достаточно удобно в битовую маску запихать. Насчет флагов ошибок - это тем более так и должно быть, но вот насчет управляющих флагов (бит телезагрузки, пропуск стабилизации и так далее) - это все однозначно выносить в отдельные регистры. Пусть это будет неэффективно в плане хранения/передачи, но это однозначно должно быть раскидано по отдельным регистрам как минимум потому что в Modbus протоколе вроде бы нет команды на запись одного бита в отдельности.

4. Как должны быть реализованы архивы. В принципе, как и сейчас (для каждого отвода есть свои адреса, по которым можно прочитать последний архив). Если реализовать историю, то следующим образом: первый регистр группы - Index, доступен как для чтения так и для записи. Если Index = 0, то мы можем прочитать самый последний (в смысле свежий) архив. Хотим предидущий архив? Записываем Index = 1, как только нам по Modbus пришел ответ об успешной записи, по этим же самым смещениям мы можем читать предидущий архив. Хотим еще более древний архив? Выставляем Index = глубине этого архива и читаем по тем же самым смещениям. С каждым новым архивом на отводе Index автоматически пересчитывается. Таким образом, если нам надо тупо читать и высвечивать последние архивные данные, то мы просто держим Index = 0. Если нас вдруг заинтересовала история - просто изменяем Index и тут же читаем что было до этого. Очень просто и безгемморойно реализуется на скриптовой системе верхнего уровня которую мы используем.

5. В текущих параметрах, помимо текущего кода ПСМ обязательно должны присутствовать некий ID последней архивной записи и номер отвода на котором она была сделана, которые бы автоматически обновлялись. Это опять таки надо для того, чтобы не ломать голову над тем, как отследить появление новой архвиной записи и прочитать ее с наименьшими затратами.

 Отправлено: 26.06.08 22:48. Заголовок: Dogmeat пишет: 3. В..

Dogmeat пишет:

цитата:

3. В текущей версии используются несколько битовых масок (3 для управления отводами, 1 для флагов текущих ошибок, 1 для управляющих флагов). Насчет "Насос скважины работает/не работает" или "Отвод измеряется/не измеряется" - это ладно, так и по количеству отводов это достаточно удобно в битовую маску запихать. Насчет флагов ошибок - это тем более так и должно быть, но вот насчет управляющих флагов (бит телезагрузки, пропуск стабилизации и так далее) - это все однозначно выносить в отдельные регистры. Пусть это будет неэффективно в плане хранения/передачи, но это однозначно должно быть раскидано по отдельным регистрам как минимум потому что в Modbus протоколе вроде бы нет команды на запись одного бита в отдельности.

такая команда есть, но не все её реализуют (FC 22 (16 Hex) Mask Write 4X Register), да и не входит она в нулевой уровень соответствия протокола. Тут я согласен - недопустимо манипулировать битами, это должны быть варианты управления, т.е. варианты подачи команды в регистр.

цитата:

4. Как должны быть реализованы архивы. В принципе, как и сейчас (для каждого отвода есть свои адреса, по которым можно прочитать последний архив). Если реализовать историю, то следующим образом: первый регистр группы - Index, доступен как для чтения так и для записи. Если Index = 0, то мы можем прочитать самый последний (в смысле свежий) архив. Хотим предидущий архив? Записываем Index = 1, как только нам по Modbus пришел ответ об успешной записи, по этим же самым смещениям мы можем читать предидущий архив. Хотим еще более древний архив? Выставляем Index = глубине этого архива и читаем по тем же самым смещениям. С каждым новым архивом на отводе Index автоматически пересчитывается. Таким образом, если нам надо тупо читать и высвечивать последние архивные данные, то мы просто держим Index = 0. Если нас вдруг заинтересовала история - просто изменяем Index и тут же читаем что было до этого. Очень просто и безгемморойно реализуется на скриптовой системе верхнего уровня которую мы используем.

упоминаемый механизм был мной разработан для собственных утилит выкачивания архива и оптимизирован для выкачивания накопившихся новых записей из большого имеющегося объема. Нулевое значение индекса - хорошая идея, я уже однажды реализовал её на передвижной установке. Попробуем совместить - положительные значения - старый механизм считывания по ID, нулевой - результаты текущего измерения, отрицательные - относительный откат по истории (-1 последний, -2 предпоследний и т.п.). Но, надо понимать - в любой момент в архив может добавится запись, и все относительное сдвинется, тогда как реализованный сейчас механизм устойчив к пополнению архива.

цитата:

5. В текущих параметрах, помимо текущего кода ПСМ обязательно должны присутствовать некий ID последней архивной записи и номер отвода на котором она была сделана, которые бы автоматически обновлялись. Это опять таки надо для того, чтобы не ломать голову над тем, как отследить появление новой архвиной записи и прочитать ее с наименьшими затратами.

Отличное замечание! Вот ради таких идей и заведено это обсуждение. Спасибо.

цитата:

1. Все регистры должны быть фиксированы в том плане, что в "пробе пера" была мысль выставлять в заголовке смещение для начала какой-то группы параметров. Лично наша утилита, отвечающая за опрос по Modbus протоколу не сумеет для каждой отдельной ГЗУ на лету вычислять смещение для чтения того или иного параметра.

смещения и информация о них - это не исходные данные для какой-либо настройки в run-time. Основное назначение - помочь сориентироваться при столкновении с новым типом контроллера АГЗУ, проверить эту информацию, настроить универсальные утилиты и т.п. В конце концов - нельзя гарантировать, что взятая статично область адресов будет доступна и свободна на контроллере АГЗУ - возможность сместить её должна быть заложена, также как возможность найти её с минимальным количеством усилий. Это помощь при настройке, а не постоянно изменяемая и эксплуатируемая при обмене информация.

 Отправлено: 26.06.08 23:00. Заголовок: Dogmeat пишет: 2. Н..

Dogmeat пишет:

цитата:

2. На последнем этапе составления этого стандарта его следует оптимизировать. Дело в том, что для меня (программиста верхнего уровня) головной болью является скорость опроса по Modbus протоколу. Если я не ошибаюсь, то быстрее отослать 1 запрос на чтение массива из 3 регистров нежели 2 запроса на чтение 1 регистра каждый. Соответственно на финальном этапе, с учетом зарезервированного на будущее места и прочих факторов, смещения должны быть отсортированы так чтобы всю группу можно было бы прочитать как можно меньшим количеством запросов. В первую очередь это получается сортировка по логической принадлежности (уставки, текущие параметры, архив и т.д.). Во вторую очередь это сортировка по используемым функциям чтения и записи (именно чтения и записи, то есть все регистры группы должны и читаться и писаться одной функцией чтения и одной функцией записи). В третью очередь это должна быть сортировка по вероятному использованию.

А вот это вообще серьезный вопрос. Оптимальным решением было бы использование команд типа FC20 (14 Hex) Read General Reference \ FC21 (15 Hex) Write general reference, которые умеют читать\писать несмежные области памяти - но это слишком экзотичные команды, как и FC23 (17 Hex) Read/Write 4X Registers с одновременной записью-чтением разных групп регистров за сеанс. Но, с целью простоты реализации, придется отказаться от экзотики. Абсолютно согласен, сортировка должна быть. Более того, основополагающая идея стандарта - постоянно мониторить одну смежную область, и по изменениям в ней принимать решение об необходимости работы с остальными областями. Т.е. все неосновные области данных дают знать о своем изменении в основную область путем смены CRC или других флагов наличия изменений.

 Отправлено: 26.06.08 23:16. Заголовок: Чем дальше обдумывае..

Чем дальше обдумывается вопрос стандарта обмена, тем более крепнет уверенность, что следующим шагом будет портирование с Modbus на DNP3, а также опасение, что DNP3 может появится даже раньше. Дело в том, что DNP3 решает очень многие пробелы в вопросе телемеханического обмена данными, которые Modbus игнорирует - такие как сопровождение событий метками времени, гарантия доставки, буферизация данных во время обрыва и доставка после восстановления связи, разделение данных на классы приоритетов, инициализация доставки по инициативе подчиненного узла и т.п.. Но DNP3 пока экзотика и мало кем поддерживается. Тем не менее - DNP3 хороший пример для подражания, и, как я считаю, очень перспективный протокол.

 Отправлено: 22.11.08 22:45. Заголовок: Dogmeat пишет: 3. В..

Dogmeat пишет:

цитата:

3. В текущей версии используются несколько битовых масок (3 для управления отводами, 1 для флагов текущих ошибок, 1 для управляющих флагов). Насчет "Насос скважины работает/не работает" или "Отвод измеряется/не измеряется" - это ладно, так и по количеству отводов это достаточно удобно в битовую маску запихать. Насчет флагов ошибок - это тем более так и должно быть, но вот насчет управляющих флагов (бит телезагрузки, пропуск стабилизации и так далее) - это все однозначно выносить в отдельные регистры. Пусть это будет неэффективно в плане хранения/передачи, но это однозначно должно быть раскидано по отдельным регистрам как минимум потому что в Modbus протоколе вроде бы нет команды на запись одного бита в отдельности.

команда такая есть, это 22 (16Hex) Mask Write 4X Register, передаются AND и OR маски для одного регистра. Команда описана давно, по крайней мере в Modicon Modbus Protocol Reference Guide PI–MBUS–300 Rev. J от June 1996 уже присутствует. Но мало кто её реализует, хотя она очень проста. Абсолютно согласен с неудобностью использования регистра режима управления.

 Отправлено: 22.11.08 23:07. Заголовок: пришло время определ..

пришло время определится со списком команд управления по функциональности,
на данный момент есть практика использования следующих команд и режимов:

- переключить на следующий отвод ( на следующий по кругу без указания кода );
- переключить на указанный отвод;

- начать стабилизацию;
- пропустить стабилизацию \ начать измерение;
- пропустить \ закончить измерение;
- сбросить накопительные суммы встроенных счетчиков в ноль;

- внеочередной замер (текущий прерывается, выполняется переход на указанный отвод );
- отложенный замер (текущий заканчивается, потом выполняется переход на указанный отвод );
- непрерывный замер (по окончанию текущего замера отвод не меняется, замер выполняется циклически на одном отводе );

- блокировать ПСМ ( по сути - запрет контроллеру АГЗУ управлять ПСМ ),
замеры выполняются циклически на текущем отводе;
- разблокировать ПСМ ( разрешить контроллеру АГЗУ выполнять
автоматический обход отводов с выполнением измерений);

- сбросить аварийное состояние контроллера АГЗУ для выхода из состояния аварии;
- сохранить изменения настроек в ЭНОЗУ контроллера АГЗУ;
- установить часы\календарь контроллера АГЗУ;
- выполнить принудительный рестарт контроллера;

прошу дополнять и высказывать свои соображения в плане минимизации набора команд.

 Отправлено: 22.11.08 23:19. Заголовок: Vlad_UA9JKW пишет: ..

Vlad_UA9JKW пишет:

цитата:

Радик, Ethernet Вы по какой причине не рассматриваете. У нас сейчас внедряются широкополосные каналы до кустовых площадок.

кстати, Ethernet хорошо вписывается, вместо Modbus RTU\ASCII можно использовать Modbus TCP. На мой взгляд RadioEthernet технологии сейчас самое перспективное решение проблемы с низкоскоростными радиоканалами и большим временем цикла опроса.