Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

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


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

Доступные файлы (1):

n1.doc774kb.14.01.2004 20:26скачать

Загрузка...

n1.doc

  1   2   3   4   5   6   7   8   9   10
Реклама MarketGid:
Загрузка...


Российское открытое акционерное общество энергетики и
электрификации «ЕЭС России» (ОАО РАО «ЕЭС России»)

Открытое акционерное общество «Научно-исследовательский
институт электроэнергетики» (ОАО «ВНИИЭ»)


УТВЕРЖДАЮ
Заместитель исполнительного
директора ОАО «ВНИИЭ»
Ю. И. Моржин

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


Москва – 2004

Содержание

Введение 3

1. Общие положения 3

1.1. Разделение протокольных уровней и основные правила реализации 3

1.2. Определение таймаутов 5

2. Физический уровень 5

3. Канальный уровень 6

3.1. Функциональные коды FC 6

3.2. Запрос статуса канального уровня и сброс канального уровня 7

3.3. Адресация станций 8

3.4. Процедуры обмена канального уровня 8

3.4.1. Аппаратно-программные варианты реализации приемопередатчиков 8

3.4.2. Обозначения 9

3.4.3. Обмен информацией при отсутствии искажений 10

3.4.4. Повторение передачи при искажении кадра 10

3.4.5. Переключение на резерв и переход в симплексный режим 13

4. Прикладной уровень 14

4.1. Избыточные посылки и ускоренные процедуры 14

4.2. Форматы передачи ТС 15

4.3. Использование метки времени и использование двукратной передачи событий 15

5. Процедуры реализации основных прикладных функций 16

5.1. Инициализация станций 16

5.1.1. Удаленная инициализация КП 16

5.1.2. Локальная инициализация КП 18

5.1.3. Локальная инициализация ПУ 19

5.2. Синхронизация времени 19

5.3. Сбор данных при помощи опроса 21

5.4. Запрос полного объема или группы 22

5.5. Опрос счетчиков 23

5.6. Передача команд 23

5.6.1. Телеуправление 23

5.6.2. Передача уставок 24

5.7. Команда чтения 25

5.8. Загрузка параметров 25

5.9. Периодическая передача данных и фоновое сканирование 26

5.10. Тестовая процедура 27

5.11. Передача однотипных данных ЦБИ 27

5.12. Передача срезов 28

5.13. Передача файлов 29


Введение


Настоящий документ является приложением к Общим Техническим Требованиям (ОТТ) «Унифицированные протоколы информационного обмена» и содержит разъяснение ряда положений ОТТ, а также подробное описание процедур обмена информацией на канальном и прикладном уровнях.

Отраслевые «Унифицированные протоколы информационного обмена» базируются на стандарте ГОСТ Р МЭК 870-5-101. При этом учитывается текст второго издания стандарта, подготавливаемого в настоящее время к выпуску. ОТТ не противоречат стандарту. Если в стандарте есть явные запреты или ограничения, они соблюдаются. В ОТТ введены некоторые отраслевые дополнения, которые не нарушают общие правила. Их использование должно быть отражено в «Формуляре совместимости».

Протокол, регламентируемый стандартом МЭК 870-5-101, значительно более универсален, чем большинство протоколов, применяемых в АСДУ в российской энергетике. Это достигается путем расширения форматов передаваемых данных, введения ряда дополнительных полей и специальных служебных посылок. Одновременно этим обусловлена определенная потеря эффективности использования канала связи, что особенно заметно при низких скоростях передачи 100-200 Бод.

Областями применения унифицированных отраслевых протоколов являются:

    • межуровневый обмен,

    • телемеханизация объектов системного значения,

    • телемеханизация объектов ПЭС,

    • локальные связи на КП и ПУ.

В межуровневом обмене есть явная тенденция к переходу на скорость 1200 Бод и более, особенно для каналов ОДУ – ЦДУ. Здесь, как и для локальных связей, практически не нужна никакая отраслевая специфика. При использовании цифровых каналов должна меняться структура резервирования каналов, а симплексный режим теряет смысл.

На других уровнях можно прогнозировать преобладание каналов 100-200 Бод в течение ближайших 5-10 лет. Для внедрения «Унифицированных отраслевых протоколов» на этих каналах необходимо иметь такой набор опций, при котором новый протокол мало проигрывает существующим. В частности, передача меток времени и показателей качества информации должна использоваться только при реальном эффекте. Должен поддерживаться однобайтный формат ТИТ, который обеспечивает вполне приемлемую погрешность дискретизации, если использовать АЦП большей разрядности для «растяжки» реального диапазона на 250 квантов.

Представляется, что при разумном подходе можно получить ухудшение временных характеристик по сравнению с существующими протоколами не более 20-30 %, а по каким-то характеристикам и выиграть.

1.Общие положения

1.1.Разделение протокольных уровней и основные правила реализации


При определении и реализации процедур обмена информацией необходимо строго соблюдать разделение функций протокольных уровней в соответствии с моделью EPA (см. раздел 2 ОТТ).

Функциями канального уровня являются:

  • обеспечение соединения станций по некоммутируемым каналам при структуре канала «точка-точка» и «многоточечной» структуре;

  • получение от прикладного уровня информационных блоков (ASDU) и формирование кадров (фреймов) в соответствии с правилами канального протокола FT1.2 (ГОСТ Р МЭК 870-5-1, ГОСТ Р МЭК 870-5-2);

  • обмен кадрами со станциями-корреспондентами;

  • декодирование принимаемых кадров и передача прикладному уровню информационных блоков;

  • контроль правильности доставки кадров, повторение передачи в случае обнаружения искажений, защита от потери и дублирования кадров;

  • реконфигурация при устойчивом нарушении работы канала – переключение на резервный канал или переход в симплексный режим.

Функциями прикладного уровня являются:

  • формирование информационных блоков для передачи канальному уровню и разборка информационных блоков, полученных от канального уровня;

  • обмен информацией с пользовательскими задачами (процессами);

  • выполнение процедур обмена информационными блоками с прикладным уровнем станции-корреспондента для реализации предусмотренных пользовательских (прикладных) функций.

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

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

  • балансный и небалансный режимы обмена информацией между станциями отличаются только канальными процедурами, а прикладной уровень совершенно не зависит от режима канального уровня;

  • стандарт МЭК 870-5-104 на прикладном уровне практически полностью совпадает с МЭК 870-5-101, а на канальном (транспортном) уровне использует стандартный протокольный стек TCP/IP.

Основные правила реализации процедур обмена информацией:

  • Допустимое число неподтвержденных сообщений (размер окна) – 1. Это означает, что первичная станция, послав сообщение (запрос), обязана дождаться ответа от вторичной станции или окончания таймаута, прежде чем посылать следующее сообщение.

  • При небалансном режиме первичной является всегда управляющая станция (ПУ), вторичной – управляемая станция (КП).

  • При балансном режиме обе станции, как управляющая, так и управляемая, реализуют функции первичной и вторичной станции.

  • При небалансном режиме управляющая станция использует сервис класса S2 SEND/CONFIRM для передачи информации в направлении управления. Для получения информации от КП используется сервис класса S3 REQUEST/RESPOND.

  • При балансном режиме обе станции используют сервис S2 SEND/CONFIRM для передачи информации, а сервис S3 REQUEST/RESPOND только для служебной функции запроса статуса канального уровня.

  • Посылки CONFIRM и REQUEST являются служебными, формируются канальным уровнем, являются кадрами фиксированной длины (старт-байт – 0x10) и не содержат прикладного информационного блока ASDU.

  • Посылки SEND и RESPOND в основном используются для передачи прикладных информационных блоков ASDU и являются кадрами переменной длины L, передаваемой в заголовке кадра со старт-байтом 0x68.

  • Кадр SEND или RESPOND может содержать только один информационный блок ASDU, механизмы фрагментации и дефрагментации кадров и информационных блоков протоколом не предусматриваются. Поэтому длина ASDU не может быть больше 254 байт в балансном режиме и 253 байт (252 при двухбайтном адресе КП) в небалансном режиме.

  • Когда кадр, передаваемый от первичной станции, содержит ASDU с каким-либо запросом прикладного уровня, он с точки зрения канального уровня является посылкой SEND. При этом вначале канальный уровень вторичной станции должен передать ответный кадр CONFIRM, а лишь потом кадр SEND (или RESPOND в ответ на REQUEST), содержащий ASDU с запрошенной информацией, поскольку кадр SEND не выполняет функции CONFIRM.

  • Встречные пары кадров SEND/CONFIRM и REQUEST/RESPOND,составляющие одну процедуру реализации какой-либо прикладной функции, не обязательно следуют непосредственно друг за другом. При наличии на той или другой станции информации с более высоким приоритетом соответствующие кадры могут перемежаться с кадрами, принадлежащими незаконченной процедуре.

В данной версии «Спецификаций» процедуры канального уровня рассматриваются только для небалансного режима обмена информацией
  1   2   3   4   5   6   7   8   9   10



Скачать файл (100.7 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации