ГОСТ Р 59979-2022. Национальный стандарт Российской Федерации. Единая энергетическая система и изолированно работающие энергосистемы. Релейная защита и автоматика. Автоматическое противоаварийное управление режимами энергосистем. Устройства локальной автоматики предотвращения нарушения устойчивости. Нормы и требования
Приложение В
(обязательное)
СТЕК ПРОТОКОЛОВ КОМПЛЕКСА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ПРОГРАММНО-ТЕХНИЧЕСКОГО КОМПЛЕКСА ВЕРХНЕГО УРОВНЯ
ЦЕНТРАЛИЗОВАННОЙ СИСТЕМЫ ПРОТИВОАВАРИЙНОЙ АВТОМАТИКИ
В.1 Схема организации информационного взаимодействия ПТК ВУ с универсальными устройствами ЛАПНУ
В.1.1 Для ПТК ВУ информационное взаимодействие с универсальными устройствами ЛАПНУ (устройствами ЛАПНУ) заключается в обмене информацией с соответствующим КС устройств ЛАПНУ или без КС напрямую с устройствами ЛАПНУ.
КС предназначен для согласования протоколов обмена данными ПТК ВУ и устройствами ЛАПНУ.
В.1.2 Организация информационного обмена между КС и КМ устройства ЛАПНУ реализуется разработчиком конкретного устройства ЛАПНУ.
В.1.3 Для каждого устройства ЛАПНУ на сервере ПТК ВУ должен присутствовать отдельный экземпляр КС.
В.1.4 Информационное взаимодействие ПТК ВУ с КС должно предусматривать обмен данными по инициативе ПТК ВУ и (или) по инициативе устройств ЛАПНУ.
На рисунке В.1 изображена схема информационного обмена между ПТК ВУ и устройством ЛАПНУ с использованием КС (для примера показано взаимодействие между КС и КМ по специальному протоколу PCP поверх UDP) с использованием специализированных протоколов связи (SLICP, TMDEP), а также пунктирной линией показана возможность взаимодействия между ПТК ВУ ЦСПА и устройством ЛАПНУ по стандартному протоколу МЭК-104 поверх TCP/IP напрямую без КС, если в ПТК ВУ ЦСПА и устройстве ЛАПНУ используется для обмена прикладной протокол МЭК-104.
Рисунок В.1 - Схема информационного взаимодействия
между ПТК ВУ ЦСПА и устройством ЛАПНУ
В.2 Протоколы комплекса
В.2.1 Основными протоколами комплекса программного обеспечения ПТК ВУ ЦСПА являются TCP/IP и специализированные протоколы SLICP и ALOP, TMDEP, описание которых приведены ниже, или стандартный протокол МЭК-104. Реализацию информационного обмена по протоколу МЭК-104 необходимо выполнять в соответствии с ГОСТ Р МЭК 60870-5-104.
В.2.2 Описание протокола ALOP:
а) признак начала пакета - последовательность символов ~$begin$~.
Примечание - Наличие поля обязательно;
б) код сервиса назначения - код сервиса, для обработки которым предназначены данные в пакете.
Примечание - Наличие поля обязательно;
в) код отправителя - код комплекса программного обеспечения, осуществляющего передачу пакета.
Примечание - Наличие поля обязательно;
г) код передаваемого данного/данных - код данного/массива данных, содержащегося в пакете. При передаче запроса это поле ДОЛЖНО СОДЕРЖАТЬ последовательность WAQ_пробел_номер (Waiting for Answer Query). При передаче данных по запросу это поле ДОЛЖНО СОДЕРЖАТЬ последовательность AOQ_пробел_номер (Answer On Query). Номер присваивается клиентской стороной и служит исключительно для нумерации запросов в рамках сессии обмена данными.
Примечание - Наличие поля обязательно;
д) за какую дату - к какой дате относится данное/массив в пакете;
е) формат даты: ДД.ММ.ГГГГ.
Примечание - Может быть пустым - указывается NULL (строка символов);
ж) за какое время/интервал - к какому интервалу времени относится данное/массив в пакете;
и) формат времени: ЧЧ:ММ:СС;
к) формат интервала: число.
Примечание - Может быть пустым - указывается NULL (строка символов);
л) данное/массив данных - данное или массив данных. Формат данных или запросов внутри этого поля определяется конкретной подсистемой оперативно-информационного комплекса и является произвольным (за исключением наличия ключевых слов, используемых в ALOP).
Примечание - Наличие поля обязательно;
м) номер фрейма в сеансе передачи пакета - массив данных может быть разделен на несколько частей и передаваться в нескольких пакетах. Для обеспечения правильной последовательности чтения данных необходимо каждый пакет снабжать порядковым номером, начинающимся с 1 в формате N/M, где N - порядковый номер фрейма, M - всего фреймов. Если же передача производится одним пакетом, то это поле должно содержать 0;
н) признак конца передачи - последовательность символов ~$end$~.
Примечание - Наличие поля обязательно.
Разделителем полей является последовательность символов ~$~
Пакет может содержать произвольное количество последовательностей символов CRLF (0x0d 0x0a).
Зарезервированные ключевые слова ALOP приведены в таблице В.1.
Таблица В.1
Зарезервированные ключевые слова ALOP
Слово | Назначение |
~$begin$~ | Признак начала пакета ALOP |
~$end$~ | Признак конца пакета ALOP |
~$~ | Разделитель полей пакета ALOP |
В.2.2.1 Примеры пакетов
Пример 1
~$begin$~
~$~service_01~$~kio3_01~$~ti512~$~18.07.1999~$~12:00:00
~$~456.4~$~0~$~
~$end$~
Данный пакет содержит информацию об измерении, которое предназначено для обработки модулем service_01, получено от отправителя с кодом kio_01, измерение с кодом ti512 на 12 ч 00 мин 00 с 18.07.1999, значение измерения 456.4, передача произведена в один пакет (признак 0).
Пример 2
~$begin$~
~$~service_02~$~kio_02~$~dg100~$~18.07.1999~$~NULL~$~
:232345:655567:23498.7:458721.54:0:0:0:1254:0:
~$~1/2~$~
~$end$~
~$begin$~
~$~service_02~$~kio_02~$~dg100~$~18.07.1999~$~NULL~$~
:13345:55675:3498.27:46721.5:45667:21111:0:1254.7:0:
~$~2/2~$~
~$end$~
Данный пакет содержит массив данных, которые предназначены для обработки модулем service_02, получены от отправителя с кодом kio_02, массив данных с кодом dg100 за 18.07.1999, номер интервала отсутствует (NULL).
Итоговый массив:
:232345:655567:23498.7:458721.54:0:0:0:1254:0:
:13345:55675:3498.27:46721.5:45667:21111:0:1254.7:0:,
передача произведена в два пакета (признак 1, 2).
Рассмотрим пакет, содержащий запрос на передачу данных в примере 2:
~$begin$~
~$~service_02~$~kio_02~$~WAQ1~$~18.07.1999~$~NULL
~$~: sut_01: sut_02: sut_03:
~$~0~$~
~$end$~
Поле N 4 содержит "WAQ1", что обозначает "Сервис kio_02 запрашивает (номер запроса 1) у сервиса service_02 данные (поле N 7): sut_01: sut_02: sut_03: за 18.07.1999".
Ответный пакет может иметь вид:
~$begin$~
~$~kio3_02~$~service_02~$~AOQ1~$~18.07.1999~$~NULL
~$~: sut_01=4587: sut_02=87445.5: sut_03=45884.64:
~$~0~$~
~$end$~
Поле N 4 содержит "AOQ1", что обозначает "Сервис service_02 отвечает на запрос номер 1 сервису kio_02 данными (поле N 7): sut_01=4587: sut_02=87445.5: sut_03=45884.64: за 18.07.1999".
Ответственность за нумерацию запросов лежит на клиентской стороне (посылающей запрос) и предназначена только для определения последовательности запросов-ответов в сессии обмена данными.
В.2.3 Описание протокола SLICP
В.2.3.1 SLICP [Session Layer Information Complex Protocol (v 1.0)] - протокол уровня приложения, регламентирующий ведение сессии обмена данными.
В.2.3.2 Командный процессор.
Командный процессор на стороне сервера должен подчиняться следующим правилам:
а) все сообщения сервера начинаются с маркера начала ~$SAB$~ и заканчиваются маркером конца ~$SAE$~. Если в ответе содержится дополнительная информация (кроме самого сообщения - например, набор строк on-line помощи), то ее ограничители никак не регламентируются;
б) последней строкой всегда должна быть комбинация ~$SAB$~_SERVER_MESSAGE_~$SAE$~CRLF;
в) при установлении соединения должно посылаться сообщение, начинающееся с кода 100;
г) при получении от клиента сообщения должен выполняться синтаксический анализ;
д) если сообщение содержит одну из регламентированных команд, выполняется ее предписание. Результат всегда сообщается клиенту в формате КОД_ПРОБЕЛ_ТЕКСТ;
е) если сообщение содержит признак начала передачи пакета ALOP, то сервер выполняет накопление в буфере принимаемых данных до обнаружения признака конца пакета ALOP;
ж) при получении от клиента команды QUIT производится закрытие сессии с освобождением всех задействованных ресурсов операционной системы, передача клиенту сообщения, начинающегося с кода 299, и разрыв соединения с клиентом;
и) поток данных между клиентом и сервером не должен содержать зарезервированных слов, за исключением их прямого назначения.
Команды SLICP приведены в таблице В.2.
Таблица В.2
Команды
Команда | Значение |
HELP | Запрос подсказки по командам сервера |
NOOP | Просьба подтвердить готовность к приему пакетов |
QUIT | Просьба завершить сессию |
Любая команда должна завершаться последовательностью символов CRLF (0x0d 0x0a).
В.2.3.3 Коды ответов
Коды ответов приведены в таблице В.3.
Таблица В.3
Коды ответов
Код | Значение |
Коды успешного выполнения | |
100 | Соединение установлено, сессия открыта |
210 | Ответ на команду NOOP - подтверждение готовности к приему пакетов |
299 | Сессия успешно завершена. Соединение сейчас будет разорвано |
320 | Пакет успешно обработан |
321 | Команда успешно выполнена |
322 | Ответ сформирован и передан |
Коды ошибок | |
520 | Неизвестная команда |
553 | Ошибочное количество байтов в пакете ALOP. Возможна потеря при передаче |
555 | Ошибка синтаксического анализа |
556 | Нет признака начала пакета ALOP |
557 | Нет признака конца пакета ALOP |
558 | Нет имени сервиса - обработчика пакета ALOP |
559 | Нет имени отправителя пакета ALOP |
560 | Нет кода данных пакета ALOP |
561 | Ошибочный формат даты данных пакета ALOP |
562 | Ошибка в формате времени или интервала времени данных пакета ALOP |
563 | Нет данных |
564 | Ошибочное значение в поле "фрейм/всего фреймов" пакета ALOP |
565 | Неправильное количество полей пакета ALOP |
566 | Сервис назначения пакета ALOP на данном узле не зарегистрирован |
567 | Сервис назначения пакета ALOP на данном узле не настроен на прием |
568 | Сервис назначения на данном узле не соответствует указанному в пакете ALOP (ошибка маршрутизации. Для устранения необходимо анализировать таблицы маршрутизации на BROKER'ах) |
573 | Синтаксическая ошибка или ошибочное значение в пакете ALOP |
575 | Синтаксическая ошибка или ошибочное значение в поле пакета ALOP |
580 | Недостаточно прав для выполнения операции |
600 | Ошибка при инициализации сокета (в транзитной сессии) |
610 | Ошибка сокета (в транзитной сессии) |
620 | Перегрузка сервиса. Сервис не может обслужить соединение по причине достижения порога максимальной загруженности другими соединениями |
710 | Нет связи между КС и устройством ЛАПНУ |
711 | Ошибка связи с 1 устройством (контроллером) ЛАПНУ |
712 | Ошибка связи со 2 устройством (контроллером) ЛАПНУ |
713 | ... |
714 | ... |
... резерв... | ... |
719 | ... |
720 | КС. ТУВ не принят. Некорректное содержимое ТУВ |
721 | Прием ТУВ заблокирован в течение тайм-аута после срабатывания ПО |
722 | Отказ ЛАПНУ, выполнение команд ПТК ВУ ЦСПА невозможно |
723 | Неизвестная ошибка при обработке ЛАПНУ команды ПТК ВУ ЦСПА |
725 | Невозможно передать ТУВ на устройство ЛАПНУ по причине превышения таймаута ожидания ответа от ЛАПНУ |
730 | Все доступные соединения между КС и ЛАПНУ заняты |
Зарезервированные ключевые слова SLICP+ALOP приведены в таблице В.4.
Таблица В.4
Зарезервированные ключевые слова SLICP+ALOP
Слово | Значение |
~$begin$~ | Признак начала пакета ALOP |
~$end$~ | Признак конца пакета ALOP |
~$~ | Разделитель полей пакета ALOP |
~$SAB$~ | Маркер начала сообщения сервера (Server Answer Begin) |
~$SAE$~ | Маркер конца сообщения сервера (Server Answer End) |
В.2.3.4 Сессия связи с использованием протокола SLICP
Сессия связи должна состоять из этапов, приведенных в таблице В.5.
Таблица В.5
Сессия связи и ее этапы
Сторона | Данные | Описание |
Клиент | Устанавливает соединение с определенным портом (например, 5280) сервера XXX.XXX.XXX.XXX | - |
Сервер | ~$SAB$~100 OK~$SAE$~CRLF <*> | Сессия открыта. Готов обслуживать запросы |
Клиент | ~$begin$~CRLF ~$~service_02~$~kio3_02~$~dg100~$~18.07.1999~$~NULL~$~CRLF :232345:655567:23498.7:458721.54:0:0:0:1254:0: CRLF ~$~0~$~CRLF ~$end$~CRLF | Передача запроса в формате ALOP |
Сервер | ~$SAB$~320 OK~$SAE$~CRLF | Запрос успешно обработан |
Клиент | ~$begin$~CRLF ~$~service_02~$~kio3_02~$~WAQ 1~$~18.07.1999~$~NULL~$~CRLF : sut_01: sut_02: sut_03: CRLF ~$~0~$~CRLF ~$end$~CRLF | Передача запроса N 1 в формате ALOP с ожиданием ответа |
Сервер | ~$begin$~CRLF ~$~kio3_02~$~service_02~$~AOQ 1~$~18.07.1999~$~NULL~$~CRLF : sut_01=12854: sut_02=2564.54: sut_03=44741.9: CRLF -$~0~$~CRLF ~$end$~CRLF ~$SAB$~322 OK~$SAE$~CRLF | Ответ на запрос N 1 передан |
Клиент | QuitCRLF | Завершить сессию |
Сервер | ~$SAB$~299 OK~$SAE$~CRLF | Сессия закрыта |
Сервер | Разрывает соединение | - |
<*> CRLF - возврат каретки. | ||
Сервер всегда отвечает кодом сообщения (три символа, каждый из которых лежит в диапазоне от нуля до девяти), отделенным справа минимум одним пробелом от текста сообщения.
Наличие каких-либо дополнительных символов слева от кода сообщения не допускается.
В.2.4 Описание протокола TMDEP
В.2.4.1 TMDEP [Telemetry Data Exchange Protocol (v 1.0)] - протокол обмена данными с удаленным устройством ЛАПНУ. Реализует сессию обмена сообщениями по технологии "клиент/сервер" через устанавливаемое TCP-соединение (TCP/IP - интерфейс сокетов).
В.2.4.1.1 Командный процессор
Командный процессор на стороне сервера должен подчиняться следующим правилам, представленным в описании протокола SLICP.
Команды протокола приведены в таблице Б.6.
Таблица В.6
Команды
Общие | |
SLICP-совместимые | Набор команд, стандартный для всех SLICP-совместимых модулей |
Каждый ответ заканчивается стандартным SLICP-блоком:
~$SAB$~_SERVER_MESSAGE_~$SAE$~CRLF
Любая команда должна завершаться последовательностью символов CRLF (0x0d 0x0a).
В.2.4.1.2 Коды ответов
Коды ответов должны соответствовать кодам, представленным в описании протокола SLICP.
В.2.4.1.3 Сессия
Реализация сессии должна соответствовать регламенту, представленному в описании протокола SLICP.
В.2.4.1.4 Вызов функций приема/передачи данных
Функции приема/передачи данных необходимо инкапсулировать в поле ДАННЫЕ пакета ALOP. Ответ также инкапсулируется в поле ДАННЫЕ пакета ALOP.
При передаче чисел с дробной частью в качестве разделителя целой и дробной части применяется ТОЧКА.
В.2.4.2 Типы пакетов информационного обмена
В.2.4.2.1 В рамках протокола TMDEP может производиться обмен пакетами в формате ALOP. Содержание информационной части пакетов может представлять собой несколько разновидностей:
а) данные;
б) команды.
В.2.4.2.2 Данными являются:
- ТУВ (таблица управляющих воздействий);
- протокол срабатываний устройства ЛАПНУ, передаваемый от ЛАПНУ (через КС) шлюзу ММО;
- протокол передачи ТУВ (передается шлюзу ММО) от КС к устройству ЛАПНУ;
- диагностические данные о состоянии КС;
- диагностические данные о состоянии устройства ЛАПНУ;
- диагностические данные о состоянии каналов связи;
- информация о режиме работы устройства ЛАПНУ;
- режимные параметры.
В.2.4.2.3 Командами являются:
- инициализация устройства ЛАПНУ (запрос на передачу ТУВ);
- запрос информации от шлюза ММО к устройству ЛАПНУ:
- о состоянии устройства ЛАПНУ;
- о состоянии каналов связи;
- о режиме работы устройства ЛАПНУ;
- запрос УВ из ТУВ ЛАПНУ/ТУВ ЦСПА;
- запрос режимных параметров;
- синхронизация времени.
В.2.4.2.4 Дублированные устройства нумеруют, начиная с 0.
В.2.4.3 Передача команд
В.2.4.3.1 Регистрация Login
Login (UserName, Password, NeedStat).
Идентифицироваться в БД ПТК верхнего уровня ЦСПА.
Параметры:
а) UserName - зарегистрированное название комплекса программного обеспечения, для взаимодействия с которым производится идентификация;
б) Password - пароль (в хешированном виде);
в) NeedStat - зарезервировано на будущее.
Ответ:
'OK'
Если регистрация не прошла, то ответ 'NO RIGHTS'.
Пример
Клиент:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~WAQ 1~$~NULL~$~NULL~$~
~$~Login(srv1, srv1pass, 0)~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~AOQ 1~$~NULL~$~NULL
~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.3.2 Запрос состояния дублированных устройств ЛАПНУ (опция)
Запрос состояния устройства 1 (У1) и устройства 2 (У2) ЛАПНУ по двум каналам ММО.
Запрос от шлюза ММО к КС.
Формат вызова:
GetCurMode_KPU
Ответ - структура:
4 байта (значения 1 или 0 - раб/не раб.): Канал1_У1 Канал2_У1 Канал1_У2 Канал2_У2
#9
1 байт (1 - АЗД, 0 - автономный)
#9
64 байта (битовая маска): сигнальная индикация. 64-й байт "Работа/Резерв" (1/0).
#9
1 байт (0 - "Не расчет", 1 - "Расчет"). ЛАПНУ не смогла сформировать ТУВ в автономном режиме работы (причиной могут быть: нерасчетные сечения, неизвестная схема сети, потеря связи с ССПИ и т.п.).
#9
2 байта (1 - рестарт, 0 - нормальная работа): У1 У2
#9
2 байта (1 - контроллер ЛАПНУ в работе, 0 - в отказе): У1 У2
#9
2 байта (1 - выходные цепи включены, 0 - отключены): У1 У2
#9
2 байта (1 - входные цепи включены, 0 - отключены): У1 У2
#9
2 байта (1 - нет сигнализации о неисправности в контроллере ЛАПНУ, 0 - в контроллере ЛАПНУ сформирована сигнализация о неисправности): У1 У2
#9
2 байта (1 - нет разночтений, 0 - есть разночтения): У1 У2
#9
2 байта (1 - наличие нерасчетных сечений, 0 - нерасчетных сечений нет)
#9
ДДММГГГГЧЧММССТТ (для У1)
#9
ДДММГГГГЧЧММССТТ (для У2)
#9
Примечание - Выражение "-1" обозначает неопределенное (недостоверное) значение.
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
GetCurMode_KPU
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
1111 #9 1 #9 0000000...1 #9 1 #9 00 #9 11 #9 11 #9 11 #9 11 #9 11 #9 00 #9 1411200515454500 #9 1411200515454600 #9
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.3.3 Передача нового времени для устройства ЛАПНУ
Данные от шлюза ММО для КС.
Формат вызова:
SetCurTime(Npk, TIME)
Npk - номер дублированного устройства ЛАПНУ.
TIME - изменение времени для устройства ЛАПНУ, с.
Данное изменение определяется на основании нескольких запросов GetCurTime, в результате которых определяется время задержки пакетов в сети передачи данных и реальное расхождение во времени на каждом из дублированных устройств ЛАПНУ и сервере ЦСПА.
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
SetCurTime(1, +4)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
Примечание - +4 представляет "прибавить на У1 4 секунды".
В.2.4.3.4 Передача команды на переключение устройства ЛАПНУ в автономный режим
Команда от шлюза ММО для КС.
Формат вызова (LM-Local Mode):
SwitchToLM(Author)
Author - 0: диспетчер, 1: ЦСПА.
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
SwitchToLM(0)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.3.5 Запрос ТУВ из устройств ЛАПНУ
Запрос данных от шлюза ММО для КС.
Формат вызова:
GetTUV(Mode)
Mode: 0 - запрос ТУВ ЛАПНУ
1 - запрос ТУВ ЦСПА
Ответ - структура:
N_ПОр_1 #9 N_ПОр_2 #9 Состояние #9 НБ #9 Устойчивость #9 ОГ #9 ОН #9 УЗС #9
Значение_УВ_1 #9 ... #9 Значение_УВ_64 #9 ДДММГГГГЧЧММССТТ #9 #13#10,
где N_Пор - номер пускового органа. Для простых пусковых органов ПО_2 должно быть 0.
Состояние - включено/отключено (0/1);
НБ - значение небаланса.
Устойчивость - 0 или 1. По данному ПОр обеспечивается необходимый объем управления по всем сечениям.
ОГ - отключаемая генерация (целое).
ОН - отключаемая нагрузка (целое).
УЗС - увеличение нагрузки станции.
Значение_УВ_N - значение 0 или 1 УВ. Передаются всегда все 64.
ДДММГГГГЧЧММССТТ - день, месяц, год, час, мин, с - точное время последнего обновления УВ по данному ПОр, ТТ - значение в мс ("??", если значение не известно);
#9 - символ ASCII [TAB];
#13#10 - символы ASCII [CRLF].
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
GetTUV
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
1 #9 0 #9 1 #9 0 #9 1 #9 200 #9 300 #9 1 #9...#9 1 #9 14112005122020?? #9
2 #9 0 #9 0 #9 0 #9 1 #9 250 #9 100 #9 1 #9...#9 0 #9 14112005122020?? #9
3 #9 0 #9 1 #9 0 #9 0 #9 400 #9 500 #9 0 #9...#9 1 #9 14112005122020?? #9
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.3.6 Запрос режимных параметров
Запрос данных от шлюза ММО для КС.
Формат вызова:
GetMP(N_PK),
где N_PK - номер дублированного устройства ЛАПНУ.
Ответ - структура:
ПК #9 СИ1...СИ64 #9 Р1...Р64 #9 Сечение1 #9 ... #9 Сечение16 #9
ДДММГГГГЧЧММССТТ #9 #13#10,
где ПК - номер устройства;
С - сигнальная индикация (может быть 0 или 1). Для каждого полукомплекта свой набор;
Р - ремонты (может быть 0 или 1), для обоих полукомплектов - одинаково;
Сечение - номер ступени (значения от 0 до 63), если больше или равно 64, то ремонтная схема в сечении нерасчетная. Для обоих полукомплектов - одинаково;
ДДММГГГГЧЧММССТТ - день, месяц, год, час, мин, с - точное время последнего обновления УВ по данному ПОр, ТТ - значение в мс ("??", если значение не известно);
#9 - символ ASCII [TAB];
#13#10 - символы ASCII [CRLF];
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
GetMP(0)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
0 #9 0... 1 #9 1...0 #9 10 #9 10 #9 ... #9 2 #9 14112005141122?? #9
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.3.7 Запрос текущего времени на устройстве ЛАПНУ
Запрос данных от шлюза ММО для КС.
Формат вызова:
GetCurTime(Npk, CPATIME)
Npk - номер устройства ЛАПНУ.
CPATIME - дата/время на сервере ЦСПА в текстовом формате: ДДММГГГГЧЧММСС.
Ответ:
Npk - номер устройства ЛАПНУ.
CPATIME - дата/время, полученные с сервера ЦСПА в текстовом формате: ДДММГГГГЧЧММСС. Завершается символом #9 (TAB).
KPUTIME - дата/время на устройстве ЛАПНУ в текстовом формате: ДДММГГГГЧЧММСС. Завершается символом #9 (TAB).
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
GetCurTime(1, 08062005101512)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
1 #9 08062005101512 #9 08062005101525 #9
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.3.8 Запрос ТУВ на ЛАПНУ (опция)
Запрос ТУВ от внешнего клиента для шлюза КС.
Формат вызова:
ExecGetTUV(KPU_ID, Mode)
KPU_ID - идентификатор устройства ЛАПНУ в базе данных (БД) ПТК ВУ ЦСПА.
MODE - 0: ТУВ ЛАПНУ, 1: ТУВ ЦСПА.
Ответ:
Идентификатор записанной в БД ТУВ ЦСПА.
Пример
Клиент:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~ODUURL_CONSOLE~$~WAQ 1~$~NULL~$~
NULL~$~
ExecGetTUV(1,1)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CONSOLE~$~ODUURL_CFRAS_RT01~$~AOQ1~$~NULL~$~
NULL~$~
234
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.3.9 Передача команды на переключение ЛПНУ в режим АЗД
Команда от шлюза КС для КС.
Формат вызова (SM - Slave Mode):
SwitchToSM(Author)
Author 0: диспетчер, 1: ЦСПА.
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
SwitchToSM(0)~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.4 Передача данных
В.2.4.4.1 Передача ТУВ после расчетного цикла
Данные от шлюза ММО для КС.
Формат вызова:
NewTUV(Struct)
Struct структура:
Код #9 N_ПОр_1 #9 N_ПОр_2 #9 Состояние #9 НБ #9 Значение_УВ_1 #9 ... #9
Значение_УВ_64 #9 ДДММГГГГЧЧММССТТ #9 #13#10,
где М - количество простых пусковых органов, которые составляют сложный пусковой орган;
N - количество ступеней УВ на низовом устройстве;
Код - код (количество обработанных аварий от данного устройства ЛАПНУ). Устройство ЛАПНУ принимает ТУВ и запоминает данный код. При срабатывании УВ (ПОр) ЛАПНУ передает через КС шлюзу КС протокол срабатывания. Сервер ЦСПА должен при получении данного протокола остановить текущий расчетный цикл и произвести расчет заново. После чего увеличить на 1 (или более) код. Новые ТУВ передаются с новым кодом. Если ЛАПНУ получает ТУВ со старым кодом, то это считается приемом ошибочной ТУВ;
N_ПОр - номер пускового органа. Состоит из одного или нескольких чисел ПО_1 ... ПО_М. Для простых пусковых органов все значения, кроме первого, должны быть 0. Количество ПО в строке УВ настраивается опционально для каждого контроллера;
Состояние - включено/отключено (0/1);
НБ - значение небаланса;
Значение_УВ_N - значение 0 или 1 УВ. Передаются всегда все 64;
#9 - символ ASCII [TAB];
#13#10 - символы ASCII [CRLF];
ДДММГГГГЧЧММССТТ - день, месяц, год, час, мин, с - точное время последнего обновления УВ по данному ПОр, ТТ - значение в мс ("??", если значение не известно).
Пример
Клиент:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
NewTUV(
888 #9 1 #9 0 #9 1 #9 0 #9 0 #9 1 #9... .#9 0 #9n120120041231007?? #9 #13#10
....................
888 #9 64 #9 21 #9 1 #9 0 #9 0 #9 1 #9... .#9 0 #9 12012004123100?? #9 #13#10)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ1~$~NULL~$~NULL~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.4.2 Передача протокола срабатываний ПОр
По этой команде ЦСПА увеличивает на 1 код ТУВ (количество обработанных аварий).
Данные от КС для шлюза ММО.
Формат вызова:
EmergencyPO(Struct)
Struct - структура:
ПК#9Ф1#9 Ф2#9 Ф2#9ПО_1#9 ... #9ПО_64#9О_ПО_1#9 ...
#9О_ПО_64#9ДДММГГГГЧЧММССТТ#9,
где ПК - номер устройства, с которого получено уведомление (0 - первый, 1 - второй);
Ф1 - если 1, то воздействия были выданы, если 0, то воздействия не были выданы;
Ф2 - если 1, то признак "ТУВ не готов", если 0, то "ТУВ готов";
Ф3 - если 1, то ТУВ ЦСПА, если 0, то ТУВ ЛАПНУ;
ПО - пришедшие аварийные сигналы, как номера ПО (64 шт. 1 или 0);
О_ПО - пришедшие отключенные аварийные сигналы, как номера ПО (значение 1 или 0; количество ПО может быть любым);
ДДММГГГГЧЧММССТТ - (день, месяц, год, час, мин, с - точное время).
Пример
Клиент:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~WAQ1~$~NULL~$~NULL~~
EmergencyPO(0 #9 0 #9 0 #9 1 #9 1 #9 0 #9 ... 0 #9 0207200412451100 #9)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~AOQ 1~$~NULL~$~NULL~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.4.3 Передача расширенного протокола срабатываний ПОр (опция)
Данные от КС для шлюза ММО.
Формат вызова:
EmergencyPO_Ext(Struct)
Struct структура:
MP#9#13#10
ПК#9Р1...Р64#9Сечение1#9...#9Сечение16#9ДДММГГГГЧЧММССТТ#9#13#10
POE#9#13#10
ПК_1#9Ф1#9#13#10
Ф2#9ПО_1#9ПО_2#9УВ_1...УВ_64#9ДДММГГГГЧЧММССТТ#9#13#10
...............
Ф2#9ПО_1#9ПО_2#9УВ_1...УВ_64#9 ДДММГГГГЧЧММССТТ#9#13#10,
где MP - Префикс, означающий начало блока РЕЖИМНЫХ параметров;
ПК - номер устройства (0 - первый, 1 - второй), с которого получена режимная информация;
Р - ремонты (может быть 0 или 1). Для обоих устройств - одинаково;
Сечение - номер ступени (значения от 0 до 15), если больше или равно 64 - ремонтная схема в сечении нерасчетная. Для обоих устройств - одинаково;
ДДММГГГГЧЧММССТТ - день, месяц, год, час, мин, с - точное время последнего обновления УВ по данному ПОр, ТТ - значение в мс или??;
POE - Префикс, означающий начало блока РАСШИРЕННОГО протокола;
ПК - номер устройства, с которого получено уведомление (0 - первый, 1 - второй);
Ф1 - если 1, то воздействия были выданы, если 0, то воздействия не были выданы;
Ф2 - признак, из какого ТУВ выдано воздействие (0 - из ТУВ ЛАПНУ, 1 - из ТУВ ЦСПА);
ПО - пришедшие аварийные сигналы, как номера ПОр;
УВ - выданные управляющие воздействия;
ДДММГГГГЧЧММССТТ - (день, месяц, год, час, мин, с - точное время).
Пример
Клиент:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~WAQ1~$~NULL~$~NULL~$~
EmergencyPO_Ext(MP #9 #13 #10
1 #9 1...0 #9 10 #9 ... #9 3 #9 14112005141122?? #9 #13 #10
POE #9 #13#10
1 #9 1 #9 #13 #10
1 #9 1 #9 0 #9 0001000...0 #9 0207200412451100 #9 #13 #10
0 #9 12 #9 14 #9 0100010...0 #9 0207200412451200 #9 #13 #10)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~AOQ 1~$~NULL~$~NULL~$-
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.4.4 Передача срабатываний УВ
Данные от КС для шлюза ММО.
Формат вызова:
EmergencyUV(Struct)
Struct структура:
ПК#9ФЛАГ#9УВ_1#9 ... #9 УВ_N #9 ДДММГГГГЧЧММССТТ #9,
где ПК - номер устройства, с которого получено уведомление (0 - первый, 1 - второй);
ФЛАГ - если 1, то воздействия были выданы, если 0, то воздействия не были выданы;
ДДММГГГГЧЧММССТТ - (день, месяц, год, час, мин, с - точное время).
Пример
Клиент:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~WAQ 1~$~NULL~$~NULL~$~
EmergencyUV(0 #9 0 #9 1 #9 0 #9 0 #9 0 #9 0 #9 0 #9 0 #9 1 #9 0 #9 0207200412451100 #9)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~AOQ 1~$~NULL~$~NULL~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.4.5 Передача информации о состоянии устройств ЛАПНУ
Данные от КС для шлюза ММО.
Формат вызова:
CurMode_KPU(Struct)
Struct структура:
4 байта (значения 1 или 0 - работа/не работа): Канал1_У1 Канал2_У1 Канал1_У2 Канал2_У2
#9
1 байт (1 - АЗД, 0 - автономный)
#9
64 байта: резерв
#9
1 байт (0 - "Не расчет", 1 - "Расчет")
#9
2 байта (1 - рестарт, 0 - нормальная работа): У1 У2
#9
2 байта (1 - У в работе, 0 - отказ У): У1 У2
#9
2 байта (1 - выходные цепи включены, 0 - отключены): У1 У2
#9
2 байта (1 - входные цепи включены, 0 - отключены): У1 У2
#9
2 байта (1 - нет неисправностей, 0 - есть неисправности): У1 У2
#9
2 байта (1 - нет разночтений, 0 - есть разночтения): У1 У2
#9
2 байт (1 - наличие нерасчетных сечений, 0 - нерасчетных сечений нет)
#9
ДДММГГГГЧЧММССТТ (для У1)
#9
ДДММГГГГЧЧММССТТ (для У2)
#9
Примечание - Выражение "-1" обозначает неопределенное (недостоверное) значение.
Пример
Клиент:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~WAQ 1~$~NULL~$~NULL~$~
CurMode_KPU(1111 #9 1 #90000000...1 #9 1 #9 00 #9 11 #9 11 #9 11 #9 11 #9 11 #9 00 #9
1411200515454500 #9 1411200515454600 #9)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~AOQ1~$~
NULL~$~NULL~$~OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
В.2.4.4.6 Передача режимных параметров
Передача данных от КС для шлюза ММО. Осуществляется периодически (настраиваемый параметр) и по факту изменения режимных параметров.
Формат вызова:
MP(Struct)
Struct структура:
ПК #9 СИ1...СИ64 #9 Р1...Р64 #9 Сечение1 #9... #9 Сечение16 #9
ДДММГГГГЧЧММССТТ #9,
где ПК - номер устройства;
СИ - сигнальная индикация (может быть 0 или 1). Для каждого полукомплекта - свой набор.
Р - ремонты (может быть 0 или 1). Для обоих полукомплектов - одинаково.
Сечение - номер ступени (значения от 0 до 15), если больше или равно 64 - ремонтная схема в сечении нерасчетная. Для обоих полукомплектов - одинаково;
#9 - символ ASCII [TAB];
#13#10 - символы ASCII [CRLF];
ДДММГГГГЧЧММССТТ - день, месяц, год, час, мин, с - точное время последнего обновления УВ по данному ПОр, ТТ - значение в мс ("??", если значение не известно).
Пример
Клиент:
~$BEGIN$~
~$~ODUURL_CFRAS_RT01~$~UJNAJA_KS_01~$~AOQ 1~$~NULL~$~NULL~$~
MP(1 #9 0... 1 #9 1...0 #9 10 #9 ... #9 3 #9 14112005141122?? #9)
~$~0~$~
~$END$~
Модуль:
~$BEGIN$~
~$~UJNAJA_KS_01~$~ODUURL_CFRAS_RT01~$~WAQ 1~$~NULL~$~NULL~$~
OK
~$~0~$~
~$END$~
~$SAB$~322 OK~$SAE$~
Подписаться на обновления