IEC 61375-2-1 ® Редакция 1.0 2012-06 МЕЖДУНАРОДНЫЙ СТАНДАРТ цвет внутри IEC 61375-2-1:2012 Оборудование электронное железнодорожное. Сеть поездной связи (TCN). Часть 2-1: Проводная шина поезда (WTB) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 ДАННАЯ ПУБЛИКАЦИЯ ЗАЩИЩЕНА АВТОРСКИМ ПРАВОМ Copyright © 2010 IEC, Geneva, Switzerland Все права защищены Если не указано иное, никакая часть данной публикации не может быть воспроизведена или использована в любой форме и с помощью любых средств, электронных или механических, включая фотокопирование и микрофильмирование, без письменного разрешения либо МЭК, либо национального комитета-члена МЭК в стране заявителя. При возникновении каких-либо вопросов в отношении авторского права МЭК или приобретения дополнительных прав на эту публикацию, следует обратиться по указанному ниже адресу или связаться с местным национальным комитетом-членом МЭК для получения дополнительной информации. IEC Central Office 3, rue de Varembé CH-1211 Geneva 20 Switzerland Тел.: +41 22 919 02 11 Факс: +41 22 919 03 00 [email protected] www.iec.ch О МЭК Международная электротехническая комиссия (МЭК) является ведущей всемирной организацией, которая разрабатывает и издает международные стандарты в области электротехники, электроники и смежных технологий. О публикациях МЭК Техническое содержание публикаций МЭК постоянно пересматривается. Просим удостовериться, что это последнее издание, возможно, уже были опубликованы исправления или поправки. Полезные ссылки: Каталог публикаций МЭК - www.iec.ch/searchpub Электропедия - www.electropedia.org Расширенный поиск позволяет находить публикации МЭК по различным критериям (номер, текст, технический комитет и т.д.). В каталоге также представлена информация о проектах, замененных и отмененных публикациях. Ведущий международный онлайн словарь терминов в области электроники и электротехники, содержащий более 30 000 терминов и определений на английском и французском языках, с эквивалентными терминами на других языках. Также известен как Международный электротехнический онлайн словарь (IEV). Недавно изданные публикации webstore.iec.ch/justpublished МЭК - Позволяет отслеживать недавно изданные публикации МЭК. В разделе «Недавно изданные» представлена информация обо всех недавно изданных новых публикациях. Информация также доступна в режиме онлайн и раз в месяц по электронной почте. Центр обслуживания клиентов - webstore.iec.ch/csc Для того, чтобы отправить отзыв, касающийся данной публикации, или в случае необходимости получения дополнительной помощи, просим обращаться в Центр обслуживания клиентов: [email protected]. [email protected]. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 IEC 61375-2-1 ® Редакция 1.0 2012-06 МЕЖДУНАРОДНЫЙ СТАНДАРТ colour inside Оборудование электронное железнодорожное. Сеть поездной связи (TCN). Часть 2-1: Проводная шина поезда (WTB) МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОМИССИЯ КОД ЦЕНЫ XH ICS 45.060 ISBN 978-2-88912-067-3 Предупреждение! Следует убедиться, что данная публикация приобретена у официального дистрибьютора. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 –2– 61375-2-1 IEC:2012 СОДЕРЖАНИЕ ПРЕДИСЛОВИЕ ................................................................................................................................... 11 ВВЕДЕНИЕ ........................................................................................................................................... 13 1 Область применения .................................................................................................................... 15 2 Нормативные ссылки ....................................................................................................................15 3 Термины и определения, сокращения, обозначения .................................................................16 Термины и определения .....................................................................................................16 Сокращения .........................................................................................................................32 Обозначения ........................................................................................................................34 3.3.1 Основные числовые значения ..............................................................................34 3.3.2 Обозначения наименований .................................................................................34 3.3.3 Обозначения наименований для времени ..........................................................34 3.3.4 Обозначения процедурного интерфейса .............................................................35 3.3.5 Спецификация передаваемых данных ................................................................37 3.3.6 Обозначения диаграммы состояния ....................................................................39 3.4 Общие положения ...............................................................................................................40 3.4.1 Интерфейс между оборудованием.......................................................................40 3.4.2 Интерфейс между железнодорожными подвижными составами ......................40 3.4.3 Протоколы реального времени.............................................................................40 3.4.4 Сетевое управление ..............................................................................................41 3.4.5 Конфигурация .........................................................................................................41 3.4.6 Структура стандартного устройства ....................................................................42 3.5 Проверка соответствия .......................................................................................................45 Физический уровень ..................................................................................................................... 46 3.1 3.2 3.3 4 4.1 4.2 4.3 4.4 4.5 Топология .............................................................................................................................46 4.1.1 Секции шины ..........................................................................................................46 4.1.2 Разветвители ..........................................................................................................46 4.1.3 Узлы ........................................................................................................................46 4.1.4 Ориентация железнодорожного подвижного состава ........................................46 4.1.5 Технические характеристики железнодорожного подвижного состава (для справки) ..................................................................................................................47 Спецификация среды .........................................................................................................48 4.2.1 Топология ...............................................................................................................48 4.2.2 Дублирующая среда (дополнительно) .................................................................48 4.2.3 Правила конфигурирования шины .......................................................................49 4.2.4 Спецификация кабеля ...........................................................................................50 4.2.5 Концепция экранирования ....................................................................................51 4.2.6 Терминатор.............................................................................................................52 Подключение к среде ..........................................................................................................53 4.3.1 Идентификация точек соединения узлов ............................................................53 4.3.2 Прямое подключение узла ....................................................................................53 4.3.3 Непрямое подключение узла ................................................................................54 4.3.4 Соединитель(дополнительно) ..............................................................................54 Характеристики узлов .........................................................................................................55 4.4.1 Элементы узла .......................................................................................................55 4.4.2 Настройки узла и переключателя.........................................................................57 4.4.3 Дублируемые линейные блоки (дополнительно) ................................................57 Характеристики линейного блока ......................................................................................58 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5 –3– 4.5.1 Гальваническая развязка ............................................................................................ 58 4.5.2 Вносимые потери в линейном блоке ......................................................................... 58 4.5.3 Характеристики переключателей ............................................................................... 59 4.5.4 Соединение экрана с линейным блоком ................................................................... 59 4.5.5 Сплавление (дополнительно) ..................................................................................... 60 4.6 Характеристики приемопередатчика ....................................................................................... 61 4.6.1 Соглашения .................................................................................................................. 61 4.6.2 Передатчик ................................................................................................................... 61 4.6.3 Характеристики приемника ......................................................................................... 64 4.7 Передача сигналов, зависящая от среды передачи данных ................................................. 66 4.7.1 Кодирование и декодирование кадра ........................................................................ 66 4.7.2 Обслуживание дублируемой линии (дополнительно) .............................................. 69 4.7.3 Интерфейс линейного блока ...................................................................................... 71 Управление канальным уровнем ........................................................................................................ 72 5.1 5.2 Адресация .................................................................................................................................. 72 Кадры и телеграммы ................................................................................................................. 73 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.3 5.4 5.5 5.6 Формат Frame_Data (Данные_кадра)......................................................................... 73 Синхронизация телеграммы ....................................................................................... 74 Элементы кадра HDLC. ...............................................................................................76 Поле Link Control (Управление каналом) ................................................................... 77 Обслуживание битов «Attention» («Внимание»), «Change» («Изменение») и «Inhibit» («Запрет») ...................................................................................................... 80 5.2.6 Ошибки размера, контрольной последовательность кадров (FCS) и протокола... 80 Форматы телеграмм и протоколы ............................................................................................ 80 5.3.1 Поле Link Data (Данные канала)................................................................................. 80 5.3.2 Данные процесса (Process Data) ................................................................................ 81 5.3.3 Данные сообщения (Message Data) ........................................................................... 83 5.3.4 Контрольные данные (Supervisory Data).................................................................... 84 5.3.5 Телеграмма обнаружения ........................................................................................... 85 5.3.6 Телеграмма присутствия ............................................................................................ 87 5.3.7 Телеграмма состояния ................................................................................................ 88 5.3.8 Телеграмма установки промежуточного положения ................................................ 90 5.3.9 Телеграмма о наименовании...................................................................................... 91 5.3.10 Телеграмма об удалении имени ................................................................................ 93 5.3.11 Телеграмма установки конечной настройки .............................................................. 93 5.3.12 Телеграмма топографии ............................................................................................. 95 Распределение среды передачи данных ................................................................................ 97 5.4.1 Организация ................................................................................................................. 97 5.4.2 Периодическая фаза ................................................................................................... 98 5.4.3 Спорадическая фаза ................................................................................................... 99 Открытие эксплуатации ............................................................................................................ 99 5.5.1 Общие положения ....................................................................................................... 99 5.5.2 Дескрипторы ..............................................................................................................101 5.5.3 Обнаружение других составов (для справки)......................................................... 105 5.5.4 Диаграммы состояния для открытия эксплуатации ................................................108 Интерфейс канального уровня ...............................................................................................148 5.6.1 Структура канального уровня ...................................................................................148 5.6.2 Канальный интерфейс данных процесса ( Link Process_Data_Interface) ............. 149 5.6.3 Канальный интерфейс данных сообщения (Link Message_Data_Interface) ..........150 5.6.4 Интерфейс управления каналом ..............................................................................150 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 –4– 6 61375-2-1 IEC:2012 Протоколы реального времени ................................................................................................. 161 Общие положения ............................................................................................................ 161 6.1.1 Содержание данного раздела ........................................................................... 161 6.1.2 Структура данного раздела ............................................................................... 162 6.2 Службы и протоколы переменных .................................................................................. 163 6.2.1 Общие положения ............................................................................................... 163 6.2.2 Интерфейс канального уровня для данных процесса ..................................... 163 6.2.3 Интерфейс приложения для переменных процесса ....................................... 169 6.3 Службы и протоколы сообщений .................................................................................... 184 6.3.1 Общие положения ............................................................................................... 184 6.3.2 Опорная станция ................................................................................................. 184 6.3.3 Обработка пакетов сообщения .......................................................................... 187 6.3.4 Канальный уровень сообщений ......................................................................... 189 6.3.5 Сетевой уровень сообщений ............................................................................. 199 6.3.6 Транспортный уровень сообщений ................................................................... 211 6.3.7 Протокол многоадресной передачи (дополнительно) ..................................... 242 6.3.8 Сеансовый уровень сообщений ........................................................................ 258 6.3.9 Уровень представления для сообщений .......................................................... 260 6.3.10 Прикладной уровень сообщений ....................................................................... 260 6.4 Представление и кодирование передаваемых и хранящихся данных ....................... 281 6.4.1 Цель ..................................................................................................................... 281 6.4.2 Порядок следования данных ............................................................................. 282 6.4.3 Нотация для примитивных типов ...................................................................... 283 6.4.4 Структурированные типы ................................................................................... 290 6.4.5 Выравнивание ..................................................................................................... 299 6.4.6 Нотация для специальных типов ....................................................................... 299 Прикладной уровень................................................................................................................... 301 6.1 7 Упорядочение данных процесса ..................................................................................... 301 7.1.1 Типы упорядочения ............................................................................................ 301 7.1.2 Режимы упорядочения ....................................................................................... 301 7.1.3 Пути передачи данных в системе упорядочения данных процесса (PDM) ... 7.1.4 Использование функции PDM ........................................................................... 303 7.1.5 Функции PDM ....................................................................................................... 304 7.2 Обнаружение места неисправности линии проводной шины поезда ......................... 306 7.2.1 Архитектура ......................................................................................................... 307 7.2.2 Обзор протокола ................................................................................................. 308 7.2.3 Последовательность LFLD................................................................................. 309 7.2.4 Автомат состояния конечного узла (испытательный узел) ............................. 311 7.2.5 Автомат состояния промежуточного узла (узел сегментации) ....................... 311 7.2.6 Выбор поврежденной линии .............................................................................. 311 7.2.7 Обнаружение места ............................................................................................ 311 Управление поездной сетью ..................................................................................................... 313 7.1 8 8.1 8.2 Общие положения ............................................................................................................ 313 8.1.1 Содержание данного раздела ........................................................................... 313 8.1.2 Структура данного раздела ............................................................................... 314 Администратор, агенты и интерфейсы .......................................................................... 314 8.2.1 Администратор и агент ....................................................................................... 314 8.2.2 Протокол административных сообщений ......................................................... 314 8.2.3 Интерфейсы ........................................................................................................ 315 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 –5– Управляемые объекты ..................................................................................................... 317 8.3.1 Атрибуты объектов ............................................................................................. 317 8.3.2 Объекты станции ................................................................................................ 317 8.3.3 Объекты каналов проводной шины поезда ...................................................... 320 8.3.4 Объекты переменных ......................................................................................... 321 8.3.5 Объекты мессенджера ....................................................................................... 323 8.3.6 Объекты домена ................................................................................................. 324 8.3.7 Объекты задач .................................................................................................... 324 8.3.8 Объект Clock (Часы) ........................................................................................... 325 8.3.9 Объекты журнал .................................................................................................. 325 8.3.10 Объект оборудования ......................................................................................... 326 8.4 Служебные и административные сообщения ............................................................... 326 8.4.1 Нотация для всех административных сообщений ........................................... 326 8.4.2 Службы станции .................................................................................................. 331 8.4.3 Службы каналов проводной шины поезда ....................................................... 338 8.4.4 Службы переменных .......................................................................................... 350 8.4.5 Службы сообщений ............................................................................................ 360 8.4.6 Службы домена ................................................................................................... 369 8.4.7 Службы задач ...................................................................................................... 374 8.4.8 Службы часов ...................................................................................................... 376 8.4.9 Службы журнал ................................................................................................... 377 8.4.10 Служба информации об оборудовании ............................................................ 379 8.5 Процедуры интерфейса................................................................................................... 380 8.5.1 Интерфейс администратора (MGI) .................................................................... 380 8.5.2 Интерфейс агента (AGI) ..................................................................................... 381 Список литературы ............................................................................................................................ 384 8.3 Рисунок 1 - Проводная шина поезда.................................................................................................. 13 Рисунок 2 - Уровни сети поездной связи ........................................................................................... 14 Рисунок 3 – Пример перехода состояния .......................................................................................... 39 Рисунок 4 – Интерфейс между оборудованием .................................................................................40 Рисунок 5 – Интерфейс между железнодорожными подвижными составами ................................40 Рисунок 6 - Шина поезда и сеть железнодорожного подвижного состава ......................................41 Рисунок 7 - Конфигурация сети поездной связи (TCN) .................................................................... 42 Рисунок 8 – Варианты конфигурации устройства проводной шины поезда (WTB) сети поездной связи (TCN) ........................................................................................................................................... 43 Рисунок 9 – Состав поезда (показано два промежуточных узла) ................................................... 46 Рисунок 10 – Измерение транспортного средства ............................................................................47 Рисунок 11 – Соединительные узлы при нормальной работе ........................................................ 48 Рисунок 12 – Подключение двухпроводной линии ............................................................................49 Рисунок 13 - Концепция заземленного экрана ...................................................................................52 Рисунок 14 - Концепция плавающего экрана .....................................................................................52 Рисунок 15 -Терминатор ..................................................................................................................... 53 Рисунок 16 - Прямое подключение узла (дополнительная вторая линия) Рисунок 17 – Непрямое подключение ................................................................................................ 54 Рисунок 18 - Соединитель проводной шины поезда, вид спереди ..................................................55 Рисунок 19 – Пример структуры блока доступа к среде передачи данных .....................................56 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 –6– 61375-2-1 IEC:2012 Рисунок 20 - Узел с резервными линейными блоками ..................................................................... 58 Рисунок 21 – Измерение затухания ................................................................................................... 59 Рисунок 22 - Заземление экрана в линейном блоке ........................................................................ 60 Рисунок 23 - Источник сплавления и нагрузка .................................................................................. 60 Рисунок 24 - Крепление передатчика ................................................................................................ 62 Рисунок 25 – Форма импульсной волны на передатчике ................................................................. 63 Рисунок 26 – Сигнал и пауза передатчика ........................................................................................ 64 Рисунок 27 - Огибающая сигнала приемника .................................................................................... 65 Рисунок 28 - Искажение фронта сигнала приемника ....................................................................... 66 Рисунок 29 - Идеализированный кадр на линии (показана 16-битная преамбула) ....................... 67 Рисунок 30 - Кодирование битов. ....................................................................................................... 67 Рисунок 31 -Преамбула ....................................................................................................................... 67 Рисунок 32 - Конечный ограничитель ................................................................................................ 68 Рисунок 33 - Допустимый кадр, сигналы RxS, CS и SQE ................................................................. 69 Рисунок 34 - Искаженный кадр, сигналы RxS, CS и SQE ................................................................. 69 Рисунок 35 - Резервные линии (как отображается на приемнике) .................................................. 70 Рисунок 36 - Сигналы Line_Disturbance (Линия повреждена) .......................................................... 71 Рисунок 37 - Структура кадра HDLC .................................................................................................. 73 Рисунок 38 - Синхронизация телеграммы ......................................................................................... 74 Рисунок 39 – Пример межкадрового интервала ............................................................................... 75 Рисунок 40 - Интервал между кадрами, измеренный на стороне управляющего устройства ..... 76 Рисунок 41 - Интервал между кадрами на стороне подчиненного устройства .............................. 76 Рисунок 42 - Формат данных HDLC .................................................................................................... 77 Рисунок 43 - Формат данных HDLC .................................................................................................... 77 Рисунок 44 - Телеграмма данных процесса ...................................................................................... 81 Рисунок 45 - Формат запроса данных процесса (Process Data Request) ........................................ 82 Рисунок 46 - Формат ответа по данным процесса (Process Data Response) ................................. 83 Рисунок 47 - Телеграмма данных сообщения ................................................................................... 83 Рисунок 48 - Формат запроса данных сообщения (Message Data Request) ................................... 83 Рисунок 49 - Формат ответа по данным сообщения (Message Data Response) ............................ 84 Рисунок 50 - Телеграмма контрольных данных ................................................................................ 84 Рисунок 51 - Телеграмма обнаружения ............................................................................................. 85 Рисунок 52 - Формат запроса на обнаружение (Detect Request) ..................................................... 86 Рисунок 53 - Формат ответа на обнаружение (Detect Response) .................................................... 86 Рисунок 54 - Телеграмма присутствия ............................................................................................... 87 Рисунок 55 - Формат запроса о присутствии (Presence Request).................................................... 87 Рисунок 56 - Формат ответа о присутствии (Presence Request) ...................................................... 88 Рисунок 57 - Телеграмма состояния .................................................................................................. 88 Рисунок 58 - Формат запроса о состоянии (Status Request) ............................................................ 89 Рисунок 59 - Формат ответа о состоянии (Status Response) ........................................................... 90 Рисунок 60 - Телеграмма установки промежуточного положения .................................................. 90 Рисунок 61 - Формат запроса на установку промежуточного положения (SetInt Request) ........... 90 Рисунок 62 - Формат ответа об установке промежуточного положения (SetInt Response) .......... 91 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 –7– Рисунок 63 - Телеграмма о наименовании ...................................................................................................... 91 Рисунок 64 - Формат запроса о наименовании (Naming Request) .................................................................... 92 Рисунок 65 - Формат ответа о наименовании (Naming Response) ................................................................... 92 Рисунок 66 - Телеграмма об удалении имени ................................................................................................... 93 Рисунок 67 - Формат запроса на удаление имени (Unname Request) ............................................................. 93 Рисунок 68 - Телеграмма установки конечной настройки................................................................................. 93 Рисунок 69 - Формат запроса конечной настройки (SetEnd Request) .............................................................. 94 Рисунок 70 - Формат ответа о конечной настройке (SetEnd Response)........................................................... 94 Рисунок 71 - Телеграмма топографии ................................................................................................................ 95 Рисунок 72 - Формат запроса топографии (Topography Request) .................................................................... 95 Рисунок 73 - Формат ответа о топографии (Topography Response) ................................................................. 96 Рисунок 74 - Структура основного периода ....................................................................................................... 97 Рисунок 75 - Нумерация положения узлов ...................................................................................................... 100 Рисунок 76 - Формат дескриптора узла ............................................................................................................ 101 Рисунок 77 - Формат отчета узла ..................................................................................................................... 102 Рисунок 78 - Формат отчета пользователя ...................................................................................................... 102 Рисунок 79 - Формат мощности состава .......................................................................................................... 103 Рисунок 80 -Отчет управляющего устройства ................................................................................................. 104 Рисунок 81 - Формат топографического счетчика ........................................................................................... 104 Рисунок 82 - Формат топографического счетчика управляющего устройства .............................................. 105 Рисунок 83 - Диаграмма синхронизации протокола обнаружения .................................................................107 Рисунок 84 - Основные состояния узлов и настройки приложения ............................................................... 108 Рисунок 85 - Процессы узла (конечная настройка) ......................................................................................... 109 Рисунок 86 - Состояния AUXILIARY_PROCESS (ВСПОМОГАТЕЛЬНОГО ПРОЦЕССА).............................. 115 Рисунок 87 - Макрос NAMING_RESPONSE (ЗАПРОС О НАИМЕНОВАНИИ) ................................................ 116 Рисунок 88 - Состояния ОСНОВНЫХ ПРОЦЕССОВ ....................................................................................... 117 Рисунок 89 - Макрос «START_NODE» («ЗАПУСК УЗЛА») .............................................................................. 120 Рисунок 90 - Процедура REQUEST_RESPONSE (ЗАПРОС_ОТВЕТ) ............................................................ 122 Рисунок 91 - Процедуры «SET_TO_END» («УСТАНОВКА КОНЦА») И «SET_TO_INT» («УСТАНОВКА ПРОМЕЖУТОЧНОГО СОСТОЯНИЯ») .............................................................................................................123 Рисунок 92 - Макрос «INIT_MASTER» («ИНИЦИАЛИЗАЦИЯ УПРАВЛЯЮЩЕГО УСТРОЙСТВА») ............. 124 Рисунок 93 - Макрос «NAMING_MASTER» («ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») ............... 125 Рисунок 94 - Макрос «ASK_END» («ЗАПРОС КОНЕЧНОГО УЗЛА») ............................................................. 126 Рисунок 95 - Процедура NAME_ONE («ИМЕНОВАТЬ ОДИН») ...................................................................... 129 Рисунок 96 - Макрос «TEACHING_MASTER» («ОБУЧАЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») ............ 131 Рисунок 97 - Макрос «UNNAMING_MASTER» («УДАЛЕНИЕ ИМЕН УПРАВЛЯЮЩИМ УСТРОЙСТВОМ») 132 Рисунок 98 - Макрос «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») ............................................................................................................................................ 134 Рисунок 99 - Макрос «CHECK_DESC» («ПРОВЕРКА ДЕСКРИПТОРА») ....................................................... 135 Рисунок 100 - Макрос «PERIODIC_POLL» («ПЕРИОДИЧЕСКИЙ ОПРОС») .................................................. 137 Рисунок 101 - Макрос «MESSAGE_POLL» («ОПРОС СООБЩЕНИЙ») ......................................................... 138 Рисунок 102 - Состояния «UNNAMED_SLAVE» («АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») ......... 140 Рисунок 103 - Состояния «NAMED_SLAVE» («ИМЕНОВАННОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») ......... 142 Рисунок 104 - Макрос «LEARNING_SLAVE» («ОБУЧАЕМОЕ ПОДЧИНЕНОЕ УСТРОЙСТВО»). .................144 Рисунок 105 - Макрос «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ»). ...........................................................................................................................................146 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 –8– 61375-2-1 IEC:2012 Рисунок 106 - Структура канального уровня ................................................................................... 148 Рисунок 107 - Структура сети поездной связи ................................................................................ 161 Рисунок 108 - Структура протоколов реального времени.............................................................. 161 Рисунок 109 - Обмен примитивами LPI ........................................................................................... 166 Рисунок 110 -Контрольная переменная ........................................................................................... 171 Рисунок 111 - Доступ к отдельным переменным ............................................................................ 175 Рисунок 112 - Доступ к набору переменных .................................................................................... 179 Рисунок 113 - Доступ к кластеру переменных ................................................................................. 182 Рисунок 114 - Конечная станция ...................................................................................................... 184 Рисунок 115 - Станция-маршрутизатор между WTB и MVB .......................................................... 185 Рисунок 116 - Станция-шлюз между WTB и сетью подвижного состава ...................................... 186 Рисунок 117 - Формат пакета ............................................................................................................ 188 Рисунок 118 - Передача данных канального уровня ...................................................................... 190 Рисунок 119 - Интерфейс данных сообщения канального уровня (LMI) ...................................... 191 Рисунок 120 – Пример кадра данных сообщения многофункциональное поездной шины ........ 192 Рисунок 121 – Пример кадра данных сообщения проводной шины поезда ................................ 193 Рисунок 122 - Примитивы LPI ........................................................................................................... 194 Рисунок 123 – Сетевой уровень узла ............................................................................................... 200 Рисунок 124 - Кодирование сетевого адреса .................................................................................. 203 Рисунок 125 - Построение адресов в исходящем пакете .............................................................. 205 Рисунок 126 - Кодирование сетевого адреса на шине поезда ...................................................... 206 Рисунок 127 - Обмен передаваемыми пакетами ............................................................................ 213 Рисунок 128 - Форматы пакетов (тело транспортного уровня) ...................................................... 215 Рисунок 129 - Диаграмма перехода состояния протокола передачи сообщений ....................... 224 Рисунок 130 - Тайм-аут SEND_TMO ................................................................................................ 227 Рисунок 131 - Тайм-аут ALIVE_TMO ................................................................................................ 228 Рисунок 132 - Транспортный интерфейс ......................................................................................... 236 Рисунок 133 - Многоадресное сообщение без повторной передачи ............................................ 243 Рисунок 134 - Короткое многоадресное сообщение без пакетов BD и без потерь ..................... 244 Рисунок 135 - Обмен с потерянными пакетами .............................................................................. 245 Рисунок 136 - Формат пакета ............................................................................................................ 247 Рисунок 137 - Состояния автомата протокола ................................................................................ 248 Рисунок 138 - Передача на сеансовом уровне ............................................................................... 259 Рисунок 139 - Заголовок сессии в сообщении вызова (тип Am_Result) ....................................... 260 Рисунок 140 -Интерфейс прикладных сообщений .......................................................................... 261 Рисунок 141 - Кодирование AM_ADDRESS. .................................................................................... 265 Рисунок 142 - Упорядочение данных процесса ............................................................................. 301 Рисунок 143 - Пути передачи данных функции PDM ...................................................................... 302 Рисунок 144 - Использование функции PDM .................................................................................. 304 Рисунок 145 - Недопустимая переменная PDM или результат функции ..................................... 304 Рисунок 146 - Использование функции PDM .................................................................................. 306 Рисунок 147 - Проверка допустимости функции PDM .................................................................... 306 Рисунок 148 - Архитектура LFLD ..................................................................................................... 307 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 –9– Рисунок 149 - Последовательность LFLD ....................................................................................... 309 Рисунок 150 - Автомат состояния конечного узла .......................................................................... 311 Рисунок 151 - Процесс обнаружения неисправности линии (LFLD), узел сегментации на узле 63 ............................................................................................................................................................. 312 Рисунок 152 - Процесс обнаружения неисправности линии (LFLD), узел сегментации на узле 1 ............................................................................................................................................................. 312 Рисунок 153 - Процесс обнаружения неисправности линии (LFLD), узел сегментации на узле 1, присоединенном в направлении 1 ................................................................................................... 313 Рисунок 154 - Административные сообщения ................................................................................ 315 Рисунок 155 - Интерфейс агента на станции (шлюзе) ................................................................... 316 Рисунок 156 - Состояние станции .................................................................................................... 318 Таблица 1 – Шаблон спецификации процедуры интерфейса ......................................................... 36 Таблица 2 – Пример структуры сообщения ...................................................................................... 37 Таблица 3 – Пример сообщения в текстовой форме (в соответствии с Таблицей 2) ................... 38 Таблица 4 – Таблица перехода состояния ....................................................................................... 39 Таблица 5 - Проверка возможности взаимодействия ...................................................................... 45 Таблица 6 - Разводка контактов соединителя проводной шины поезда .........................................55 Таблица 7 - Сигналы интерфейса линейного блока .........................................................................72 Таблица 8 - Кодирование поля Link Control (Управление каналом) ................................................78 Таблица 9 - Структура данных NodeControl (Управление узлом) ..................................................110 Таблица 10 - Структура данных MyStatus (Собственное состояние) ............................................111 Таблица 11 - Общие переменные в узле .........................................................................................112 Таблица 12 - Переменные основного процесса ..............................................................................112 Таблица 13 - Список основных процессов .......................................................................................113 Таблица 14 - «START_NODE» («ЗАПУСК УЗЛА») ...........................................................................118 Таблица 15 - «MASTER STATES» («СОСТОЯНИЯ УПРАВЛЯЮЩЕГО УСТРОЙСТВА») ............118 Таблица 16 - «SLAVE STATES» («СОСТОЯНИЯ ПОДЧИНЕННОГО УСТРОЙСТВА») ................119 Таблица 17 - Значения постоянных времени ...................................................................................147 Таблица 18 - Примитивы LPI ............................................................................................................ 166 Таблица 19 - Кодирование Var_Size (Размер переменной) и Var_Type (Тип переменной) в PV_Name .............................................................................................................................................173 Таблица 20 - Примитивы LPI ............................................................................................................ 195 Таблица 21 - Ситуации маршрутизации .......................................................................................... 207 Таблица 22 - Маршрутизация пакетов, поступающих с транспортного уровня ........................... 209 Таблица 23 - Маршрутизация пакетов, поступающих от сети подвижного состава .................... 210 Таблица 24 - Маршрутизация пакетов, поступающих от шины поезда .........................................211 Таблица 25 - Кодирование контроля передачи сообщений .......................................................... 216 Таблица 26 - Connect_Request (Запрос на соединение) .................................................................219 Таблица 27 - Connect_Confirm (Подтверждение соединения) ........................................................219 Таблица 28 - Disconnect_Request (Запрос на отключение) ............................................................220 Таблица 29 - Disconnect_Confirm (Подтверждение отключения) ...................................................220 Таблица 30 - Data_Packet (Пакет данных) ...................................................................................... 220 Таблица 31 - Ack_Packet ................................................................................................................... 221 Таблица 32 - Nak_Packet................................................................................................................... 221 Таблица 33 - Broadcast_Connect (Широковещательное соединение) (BC1, BC2, BC3) .............. 221 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 10 – 61375-2-1 IEC:2012 Таблица 34 - Broadcast_Data (Широковещательные данные) ........................................................222 Таблица 35 - Broadcast_Repeat (Повтор широковещательной передачи) ................................... 222 Таблица 36 - Broadcast_Stop (Прекращение широковещательной передачи) (BSC, BSO) ........ 223 Таблица 37 - Состояния протокола передачи сообщений ............................................................. 223 Таблица 38 - Входящие события протокола передачи сообщений .............................................. 225 Таблица 39 - Исходящие события протокола передачи сообщений ............................................ 225 Таблица 40 - Параметры управления протокола передачи сообщений ...................................... 226 Таблица 41 - Вспомогательные переменные протокола передачи сообщений .......................... 226 Таблица 42 - Тайм-ауты протокола передачи сообщения (наихудший случай) .......................... 228 Таблица 43 - Неявные действия ...................................................................................................... 228 Таблица 44 - Комплексные действия ............................................................................................... 229 Таблица 45- Состояния поставщика и переходы ........................................................................... 230 Таблица 46- Состояния потребителя и переходы .......................................................................... 233 Таблица 47 - Примитивы TMI ........................................................................................................... 237 Таблица 48 - Состояния автомата протокола многоадресной передачи ..................................... 248 Таблица 49 - Входящие события ...................................................................................................... 249 Таблица 50 - Исходящие события .................................................................................................... 249 Таблица 51 - Поля управления в пакетах........................................................................................ 250 Таблица 52 - Вспомогательные переменные.................................................................................. 251 Таблица 53 - Постоянные протокола многоадресной передачи ................................................... 252 Таблица 54 - Тайм-ауты протокола многоадресной передачи ...................................................... 252 Таблица 55 - Комплексные действия протокола многоадресной передачи ................................ 253 Таблица 56 - Фильтрация пакетов BR ............................................................................................. 254 Таблица 57 - Таблица состояний и событий поставщика протокола многоадресной передачи 255 Таблица 58 - Таблица состояний и событий потребителя протокола многоадресной передачи 257 Таблица 59 - Примитивы AMI ........................................................................................................... 262 Таблица 60 - Постоянные адреса .................................................................................................... 264 Таблица 61 - Адрес системы и адрес пользователя ...................................................................... 267 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 11 – МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОМИССИЯ ОБОРУДОВАНИЕ ЭЛЕКТРОННОЕ ЖЕЛЕЗНОДОРОЖНОЕ. СЕТЬ ПОЕЗДНОЙ СВЯЗИ (TCN). Часть 2-1: Проводная шина поезда (WTB) ПРЕДИСЛОВИЕ 1) Международная электротехническая комиссия (МЭК) — международная организация по стандартизации, состоящая из совокупности всех национальных электротехнических комитетов (Национальные комитеты МЭК). Цель МЭК заключается в том, чтобы содействовать международному сотрудничеству по всем вопросам, касающимся стандартизации в области электротехники и электроники. Кроме того, и в дополнение к другим видам деятельности МЭК публикует международные стандарты, технические условия, технические отчеты, общедоступные технические условия и руководства (далее «публикации МЭК»). Их подготовка поручена техническим комитетам; любой национальный комитет МЭК, заинтересованный в теме, о которой идет речь, может принять участие в подготовительной работе. Международные, правительственные и неправительственные организации, связанные с МЭК, также участвуют в этой подготовке. МЭК тесно сотрудничает с Международной организацией по стандартизации (ИСО) в соответствии с условиями, определенными в соглашении, заключенном между этими двумя организациями. 2) Официальные решения или соглашения МЭК по техническим вопросам отражают, насколько это возможно, международную точку зрения по соответствующим вопросам, поскольку в каждый технический комитет представляет интересы всех заинтересованных национальных комитетов МЭК. 3) Публикации МЭК носят рекомендательную форму для международного использования и в таком качестве принимаются национальными комитетами МЭК. Несмотря на то, что для обеспечения точности технического содержания публикаций МЭК прилагаются все обоснованные усилия, МЭЕ не может нести ответственности за их использование или за любое неправильное толкование публикаций любым конечным пользователем. 4) В целях содействия международной унификации национальные комитеты МЭК обязуются наиболее понятно использовать публикации МЭК в своих национальных и региональных публикациях. Любое расхождение между какой-либо из публикаций МЭК и соответствующей национальной или региональной публикацией должно быть четко указано в последней. 5) МЭК не предоставляет каких-либо подтверждений соответствия. Услуги по оценке соответствия и, в некоторых случаях, доступ к знакам соответствия МЭК предоставляют независимые органы по сертификации. МЭК не несет ответственности за какие-либо услуги, оказываемые независимыми органами по сертификации. 6) Все пользователи должны убедиться, что имеющаяся у них версия данной публикации является последней. 7) МЭК или ее директора, сотрудники, служащие или агенты, включая отдельных экспертов и членов ее технических комитетов и национальных комитетов МЭК, не несут никакой ответственности за любые травмы, материальный ущерб или ущерб любого характера, прямой или косвенный, или за расходы (включая судебные издержки) и издержки, возникающие в связи с публикацией, использованием или доверия к данной публикации МЭК или любым другим публикациям МЭК. 8) Следует обратить внимание на нормативные ссылки, приведенные в настоящей публикации. Использование публикаций, на которые даны ссылки, необходимо для правильного применения настоящей публикации. 9) Следует обратить внимание на то, что некоторые элементы настоящей публикации МЭК могут быть объектом патентных прав. МЭК не несет ответственности за выявление каких-либо патентных прав частично или полностью. Международный стандарт IEC 61375 был подготовлен техническим комитетом 9 МЭК: Электрическое оборудование и системы для железных дорог. Текст настоящего стандарта основан на следующих документах: Финальный проект международного стандарта (ФПМС) Отчет о голосовании 9/1642/ФПМС 9/1666/ПЕРЕСМОТ РЕННЫЙ Полную информацию о голосовании по утверждению настоящего стандарта можно найти в отчете о голосовании, указанном в приведенной выше таблице. Настоящая публикация подготовлена в соответствии с Директивами ISO/IEC, Часть 2. Список всех частей серии IEC 61375 под общим названием Оборудование электронное железнодорожное. Сеть поездной связи (СПС (TCN)) можно найти на веб-сайте МЭК. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 12 – 61375-2-1 IEC:2012 Комитет решил, что содержание этой публикации останется неизменным до даты стабилизации, указанной на веб-сайте МЭК в разделе «http://webstore.iec.ch», в данных, относящихся к конкретной публикации. На данный момент публикация будет • • • • подтверждена, отменена, заменена исправленным изданием или откорректирована. Данное первое издание отменяет положения второго издания IEC 61375-1, опубликованного в 2007 г., относительно технических условий проводной шины поезда (WTB) и представляет собой технический пересмотр. Документ был подготовлен с учетом третьего издания IEC 61375-1. ВАЖНО - Логотип «цвет внутри» на обложке данного документа указывает на то, что он содержит цвета, которые считаются полезными для правильного понимания его содержания. Поэтому пользователям следует распечатать этот документ на цветном принтере/ Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 13 – ВВЕДЕНИЕ Эта часть стандарта EC 61375 распространяется на однокомпонентную сеть поездной связи, проводную шину поезда (WTB), шину последовательной передачи данных, предназначенную в первую очередь, но не исключительно, для передачи данных между компонентами подвижного состава, рассчитанные на частое сцепление и расцепление, как в случае подвижных составов международного сообщения Международного союза железных дорог. На Рисунке 1 показано применение проводной шины поезда. Узел Узел Узел Рисунок 1 - Проводная шина поезда Настоящий стандарт определяет эти интерфейсы как соединения с сетью передачи данных, называемой сетью поездной связи (TCN). Сеть поездной связи имеет иерархическую структуру с двумя уровнями сетей: поездная магистральная линия связи и сеть железнодорожного состава: a) для передачи данных между компонентами открытых поездов (см. определение), таких как подвижные составы международного сообщения Международного союза железных дорог, в этом стандарте определяется шина поезда, называемая проводной шиной поезда (WTB); b) для подключения стандартного бортового оборудования может использоваться сеть железнодорожного состава, например, многофункциональная поездная шина (MVB). В архитектуре сети поездной связи проводная шина поезда использует протоколы реального времени, которые предлагают две службы связи: c) Переменные процесса - распределенная база данных в режиме реального времени, периодически обновляемая посредством широковещательной передачи; d) сообщения, передаваемые по запросу либо как: одноадресные сообщения (двухточечные) и/или многоадресные сообщения. Проводная шина поезда в сети поездной связи предлагает общее сетевое управление, которое позволяет выполнять отладку, ввод в эксплуатацию и обслуживание по сети. Многофункциональная шина сети железнодорожного состава использует протоколы реального времени и сетевое управление совместно с проводной шиной поезда. Другие варианты применения сетей подвижного состава требуют адаптации протоколов реального времени и сетевого управления, осуществляемого проводной шиной. Структура сети поездной связи аналогична определенной в ISO/IEC 7498-1 (см. Рисунок 2). модели взаимосвязи открытых систем, Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 14 – 7 Прикладной уровень Сетевое управление 8 Интерфейс прикладного уровня (ALI) Пол ьзов ател ь 6 Протоколы реального времени Представление Переменные процесса Сообщения Сеансы Транспортн ая сеть Интерфейс канального уровня (LLI) 4 Проводная шина поезда 5 Сеть подвижного состава, определенная в IEC 61375-3-x Общие нормативные элементы ПРИМЕЧАНИЕ Физ. ски йканал 3 Цифры в кружках относятся к разделам настоящего стандарта. Рисунок 2 - Уровни сети поездной связи По редакционным причинам стандарт разделен на восемь разделов: Раздел 1 – Область применения; Раздел 2 – Нормативные ссылки ; Раздел 3 – Термины и определения, сокращения, обозначения; Раздел 4 и 5: Проводная шина поезда – уровень и Управление канальным уровнем; Раздел 6: Протоколы реального времени – Переменные: Интерфейс канального уровня и интерфейс прикладного уровня; – Сообщения: Интерфейс канального уровня, протоколы, интерфейс прикладного уровня; – Представление данных; Раздел 7: Прикладной уровень – Упорядочение данных процесса – Обнаружение места неисправности линии проводной шиной поезда Раздел 8: Управление поездной сетью – Конфигурирование, контроль и управление сетью. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 15 – ОБОРУДОВАНИЕ ЭЛЕКТРОННОЕ ЖЕЛЕЗНОДОРОЖНОЕ. СЕТЬ ПОЕЗДНОЙ СВЯЗИ (TCN). Часть 2-1: Проводная шина поезда (WTB) 1 Область применения Эта часть IEC 61375 относится к передаче данных в открытых поездах, т.е. она охватывает передачу данных между подвижными составами указанных открытых поездов и передачу данных внутри подвижных составов указанных открытых поездов. Применимость настоящего стандарта к шине передачи данных (проводной шине) обеспечивает возможность взаимодействия между отдельными подвижными составами в открытых поездов при международном сообщении. Шина передачи данных внутри состава (например, многофункциональная поездная шина) представлена в качестве рекомендованного решения для удовлетворения требований указанной сети поездной связи. В любом случае поставщик должен будет предоставить подтверждение совместимости между проводной шиной поезда и предлагаемой сетью состава. Настоящий стандарт может дополнительно применяться к закрытым поездам и мотор-вагонным поездам, если это согласовано между покупателем и поставщиком. ПРИМЕЧАНИЕ 1 Определения открытых поездов, мотор-вагонных поездов и закрытых представлены в пункте 3. ПРИМЕЧАНИЕ 2 Дорожные транспортные средства, такие как автобусы и троллейбусы, не рассматриваются в настоящем стандарте. 2 Нормативные ссылки Следующие документы, полностью или частично, являются нормативными ссылками в настоящем документе и необходимы для его применения. Датированные ссылки относятся только к указанному изданию. Недатированные ссылки относятся к последнему изданию документа, на который дается ссылка (включая любые поправки). IEC 60571, Оборудование электронное, применяемое на рельсовом транспорте IEC 60807 (все части), Соединители прямоугольные для частот ниже 3 МГц IEC 61375-1, Оборудование электронное железнодорожное. Сеть поездной связи (TCN). Часть 1: Общая архитектура IIEC 61375-2-2:2012, Оборудование электронное железнодорожное. Сеть поездной связи (TCN). Часть 2-2: Испытание поездной шины на соответствие требованиям по проводимости IEC 61375-1, Оборудование электронное железнодорожное. Сеть поездной связи (TCN). Часть 3-1: Многофункциональная поездная шина (MVB) ISO/IEC 8802-2, Информационные технологии. Телекоммуникации и обмен информацией между системами. Локальные и общегородские сети. Специальные требования. Часть 2. Управление логическим каналом ISO/IEC 8824 (все части), Информационные технологии. Абстрактно синтаксическая нотация один (АСН.1). ISO/IEC 8825 (все части), Информационные технологии. Правила кодирования ACH.1. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 16 – 61375-2-1 IEC:2012 ISO/IEC 8859-1, Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 1. Латинский алфавит № 1 ISO/IEC 9646 (все части), Информационные технологии. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. ISO/IEC 10646, Информационные технологии. Универсальный многооктетный набор кодированных символов (UCS) ISO/IEC 13239, Информационные технологии. Телекоммуникации и обмен информацией между системами. Высокоуровневые протоколы управления каналом передачи данных Рекомендации ITU-T V24, Перечень определений для каналов обмена между оконечным оборудованием данных (DTE) и оконечным оборудованием каналов передачи данных (DCE) Рекомендации ITU-T Z.100, Язык спецификаций и описания (SDL) IEEE 754, Стандарт двоичной арифметики с плавающей точкой СТАНДАРТ UIC 556, Передача информации в поезде (автомотрисе) СТАНДАРТ UIC 557, Диагностика пассажирского подвижного состава 3 3.1 Термины и определения, сокращения, обозначения Термины и определения Применительно к настоящему документу используются следующие термины и определения. ПРИМЕЧАНИЕ Каждое слово в ключевых словах или словосочетаниях в этом стандарте пишется с заглавной буквы, и, если ключевые слова или словосочетания состоят из двух или нескольких слов, они соединяются символом подчеркивания. Данное обозначение позволяет отслеживать ключевые слова в документах. 3.1.1 адрес (address) идентификатор партнера по связи, которые могут быть нескольких типов, в зависимости от уровня 3.1.2 агент (agent) прикладной процесс на станции, который обеспечивает доступ к локальным управляемым объектам от имени администратора 3.1.3 Апериодические данные (Aperiodic Data) передача данных процесса по запросу. Данная служба не используется 3.1.4 Прикладной уровень (Application Layer) верхний уровень в модели OSI, взаимодействующий непосредственно с приложением 3.1.5 Интерфейс прикладного уровня (Application Layer Interface) определение служб, представляемых прикладным уровнем 3.1.6 Адаптер прикладных сообщений (Application Messages Adapter) код, непосредственно вызываемый приложением, реализующим службы передачи сообщений Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 17 – 3.1.7 Интерфейс прикладных сообщений (Application Messages Interface) определение службы передачи сообщений 3.1.8 Прикладной процесс (Application Process) элемент передачи информации, задействованный, в частности, на уровне выполнения задачи 3.1.9 Прикладной процессор (Application Processor) Процессор, запускающий прикладной процесс передачи информации 3.1.10 Интерфейс прикладного контроля (Application Supervision Interface) определение служб контроля, доступных, в частности, агенту 3.1.11 Адаптер переменных приложения (Application Variables Adapter) код, непосредственно вызываемый приложением, реализующим службы переменных 3.1.12 Интерфейс переменных приложения (Application Variables Interface) определение службы переменных 3.1.13 арбитр (arbiter) устройство или общий протокол, выполняемый несколькими устройствами, выбирающий одно из нескольких устройств, конкурирующих за назначение управляющим устройством 3.1.14 Дополнительный канал (Auxiliary Channel) канал, используемый для обнаружения дополнительных узлов 3.1.15 Основной период (Basic Period) активность шины делится на периоды. Самым коротким является основной период, который состоит из периодической фазы (для периодических данных) и спорадической фазы (для данных сообщения и контрольных данных) 3.1.16 от старшего к младшему (big-endian) порядок следования для хранения или передачи данных, при котором наиболее значащая часть данных, состоящих из нескольких октетов, хранится по младшему адресу октета и передается первой 3.1.17 положительное выравнивание (вставка битов) (bit-stuffing) метод, представленный в ISO/IEC 13239 для предотвращения неверной интерпретации данных кадра в качестве флага, который заключается во вставке дополнительного символа «0» после каждой строки из пяти символов «1» и удалении этого «0» при приеме 3.1.18 мост (bridge) устройство для хранения и передачи кадров данных с одной шины на другую на основе их адресов канального уровня Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 18 – 61375-2-1 IEC:2012 3.1.19 широковещательная передача (broadcast) практически одновременная пересылка одинаковой информации нескольким адресатам. Широковещательная передача в сети поездной связи считается ненадежной, т.е одни адресаты могут проучить информацию, а другие нет 3.1.20 шина (bus) среда передачи данных, передающая одинаковую информацию всем подключенным участникам практически одновременно, позволяя всем устройствам получить одинаковый обзор их состояния, по крайней мере с целью разрешения конфликтов 3.1.21 Контроллер шины (Bus Controller) процессор или интегральная схема, отвечающая за канальный уровень связи 3.1.22 Шинный переключатель (Bus Switch) переключатель или реле в узле проводной шины поезда, который электрически соединяет участки кабеля двух направлений 3.1.23 Вызывающий абонент (Caller) Прикладной процесс, который инициализирует обмен сообщениями 3.1.24 Контрольная последовательность (Check Sequence) метод обнаружения ошибок, основанный на добавлении к передаваемым полезным данным контрольной суммы или циклической проверки избыточности (CRC), рассчитанной на основе полезных данных 3.1.25 Контрольная переменная (Check Variable) Переменная процесса типа антивалентная булева, защищающая другую переменную процесса 3.1.26 Контрольный сдвиг (Check Offset) Битовый сдвиг контрольной переменной в наборе данных 3.1.27 Закрытый поезд (Closed Train) Поезд, состоящий из одного или нескольких подвижных составов, состав которого не меняется в процессе эксплуатации в обычных условиях, например, метро, пригородный поезд или высокоскоростные мотор-вагонные секции 3.1.28 состав (composition) количество и характеристики транспортных средств, формирующих поезд 3.1.29 конфигурация (configuration) определение топологии шины, подключенных к ней устройств, их возможностей и производимого ими трафика; а также, процесса загрузки устройств информацией о конфигурации до перехода в режим плановой эксплуатации 3.1.30 Подтверждение соединения (Connect Confirm) Ответ потребителя на запрос на установление соединения поставщика Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 19 – 3.1.31 Запрос на установление соединения (Connect Request) первый пакет сообщения, отправленный от поставщика потребителю 3.1.32 Железнодорожный подвижной состав (Consist) Одно или группа транспортных средств, которые не разделяются в процессе эксплуатации в обычном режиме. Железнодорожный подвижный состав может содержать одну или несколько сетей железнодорожного подвижного состава. 3.1.33 Сеть железнодорожного подвижного состава (Consist network) Шинное соединительное оборудование в пределах железнодорожного подвижного состава, например, многофункциональная поездная шина, которое соответствует или адаптируется к протоколам реального времени сети поездной связи в соответствии с указанным в настоящем документе 3.1.34 согласованность (consistency) Набор данных, состоящий из нескольких элементов, является согласованным, если все элементы читаются или записываются в ходе одной неделимой операции 3.1.35 Потребитель (Consumer) Получатель сообщения на транспортном уровне (см. поставщик) 3.1.36 непрерывный железнодорожный подвижной состав (continuity consist) железнодорожный подвижной состав без действующего узла шины поезда, но несущий секцию шины для пассивного соединения шины поезда с соседним железнодорожным подвижным составом. 3.1.37 сеанс связи (conversation) обмен данными на прикладном уровне, состоящий из сообщения о вызове и ответного сообщения (последнее отсутствует в многоадресном протоколе). Сеанс связи начинается с первого кадра запроса на установление соединения и прекращается после получения последнего подтверждения приема ответного сообщения или, когда подтверждение больше не ожидается 3.1.38 дейтаграмма (datagram) кадр, содержащий всю информацию, необходимую для пересылки его конечному адресату, без знания содержимого предыдущего кадра. Дейтаграммы не используют предварительное установление соединения и не подтверждаются на канальном уровне 3.1.39 Набор данных (Dataset) Все переменные процесса, передаваемые в одном кадре данных процесса 3.1.40 ограничитель (delimiter) последовательность сигналов, включающая символы нарушения кода (ни «1», ни «0»), которые используются для разграничения начала (начальный ограничитель) и конца (конечный ограничитель) кадра, как определено, например, в IEC 61158-2. 3.1.41 Устройство-адресат (Destination Device) получатель кадра на канальном уровне (см. устройство-источник) 3.1.42 устройство (device) элемент, подсоединенный к одной или более шинам Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 20 – 61375-2-1 IEC:2012 3.1.43 Адрес устройства (Device Address) Адрес устройства обеспечивает идентификацию устройства на шине; В проводной шине поезда адрес устройства имеет 8 бит, младшие 6 бит - адрес узла; Устройство, подключенное к нескольким шинам, может иметь разные адреса устройств для каждой шины. Специальные устройства, такие как повторители, участвуют только на физическом уровне и не имеют адреса устройства 3.1.44 Направление 1 (Direction 1) одно направление узла проводной шины поезда 3.1.45 Направление 2 (Direction 2) другое направление узла проводной шины поезда 3.1.46 Конечный ограничитель (End Delimiter) последовательность, которая завершает кадр до того, как среда данных вернется в режим ожидания 3.1.47 Конечный узел (End Node) Узел, который ограничивает два соединенных с ним сегмента шины, но не обеспечивает непрерывности между ними 3.1.48 Цикл событий (Event Round) последовательность опросов, в которой считываются все события, ожидающие на старте 3.1.49 удлинительная коробка (extension box) монтажная коробка, в которой магистральный кабель прерывается и пассивно удлиняется с помощью удлинительного кабеля для подключения устройства 3.1.50 удлинительный кабель (extension cable) кабель, предназначенный для включения узла в магистральный кабель, состоящий из двух отдельных витых пар на линию, возможно, меньшего поперечного сечения, чем сам магистральный кабель 3.1.51 полевое устройство (field device) устройство, предназначенное для крепления простых датчиков и исполнительных элементов к шине за пределами стойки 3.1.52 конечный (final) получатель пакета (данные или подтверждение) на сетевом уровне. Когда на одной шине взаимодействуют два устройства, конечный получатель находится в устройстве-адресате (см.: устройство-источник). 3.1.53 Флаг (Flag) последовательность символов «1» и «0», которая служит для разграничения начала или конца кадра. Флаги, которые должны появиться в передаваемых данных, изменяются путем положительного выравнивания, как определено, например, в ISO/IEC 13239 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 21 – 3.1.54 кадр (frame) последовательность идущих подряд символов, отправляемых передатчиком за один временной интервал между двумя интервалами, когда линия свободна 3.1.55 Контрольная последовательность кадров (Frame Check Sequence) 16-битная контрольная последовательность кадров, представленная в ISO/IEC 13239 3.1.56 Данные кадра (Frame Data) данные, передаваемые между преамбулой и конечным ограничителем (на проводной шине поезда) 3.1.57 сплавление (fritting) электрическая очистка окисленных контактов путем подачи на контакт пробивного напряжения 3.1.58 Функция (Function) Прикладной процесс, обменивающийся сообщениями с другим прикладным процессом 3.1.59 Каталог функций (Function Directory) каталог, который преобразовывает идентификатор функции в идентификатор станции и наоборот 3.1.60 Идентификатор функции (Function Identifier) 8-битный идентификатор функции 3.1.61 Код функции (F code) в главном кадре, указывает запрос и ожидаемый ответ о размере подчиненного кадра 3.1.62 шлюз (gateway) соединение между различными шинами на прикладном уровне, требующее анализа данных в зависимости от приложения и преобразования протокола 3.1.63 Групповой адрес (Group Address) Адрес группы многоадресной передачи к которой принадлежит узел 3.1.64 Каталог группы (Group Directory) каталог, который указывает узлу, к какой группе многоадресной передачи он принадлежит 3.1.65 расстояние Хэминга (hamming distance) минимальное количество битов заданной правильной битовой последовательности, которые при инвертировании создают ложную битовую последовательность, неотличимую от правильной 3.1.66 HDLC Высокоуровневое управление каналом передачи данных, набор стандартизированных протоколов, включая ISO/IEC 13239 для передачи данных Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 22 – 61375-2-1 IEC:2012 3.1.67 Данные HDLC (HDLC Data) данные, передаваемые в HDLC-кадре 3.1.68 Открытие эксплуатации (Inauguration) Процесс, выполняемый в случае изменения состава, присваивающий всем узлам проводной шины поезда адреса в отношении управляющего устройства, ориентацию и информацию обо всех именованных узлах на одной шине 3.1.69 Отдельный период (Individual Period) интервал между двумя последовательными передачами одних и тех же данных процесса из одного и того же источника. Отдельный период равен основному периоду, возведенному в степень 2. 3.1.70 экземпляр (instance) a) один из нескольких объектов, которые имеют одно и то же определение (экземпляр объекта) b) Один из нескольких (одновременных или нет) запусков одной и той же программы (экземпляра процесса) 3.1.71 целостность (integrity) Свойство системы, позволяющее ей распознавать и отклонять неверные данные в случае нарушения функционирования ее частей 3.1.72 Промежуточный узел (Intermediate Node) Узел, который устанавливает непрерывность связи между двумя соединенными с ним сегментами шины, но не ограничивая их 3.1.73 соединительный кабель (jumper cable) Кабель, соединяющий магистральные кабели двух последовательно расположенных железнодорожных подвижных составов, возможно имеющий более поперечное сечение по сравнению с магистральным кабелем, и подключенный вручную в случае с UIC-кабелем. Обычно между железнодорожными подвижными составами подключают два соединительных кабеля 3.1.74 Линия (Line) нерезервированная шина. Двухпоточная шина, состоящая из двух линий 3.1.75 Линейный блок (Line Unit) все цепи, обеспечивающие электрическое подключение к линии 3.1.76 Адрес канала (Link Address) адрес, предоставляемый канальному уровню для идентификации шины и адреса устройства, на которое отправляется или где принимается пакет данных 3.1.77 Управление каналом (Link Control) поле в HDLC-кадре, которое указывает тип кадра 3.1.78 Данные канала (Link Data) данные, передаваемые на канальном уровне, но не относящиеся к нему Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 23 – 3.1.79 Заголовок канала (Link Header) часть кадра данных сообщения, относящаяся к канальному уровню 3.1.80 Канальный уровень (Link Layer) Уровень в модели OSI, устанавливающий двухточечные и широковещательные соединения между устройствами, подключенными к одной и той же шине 3.1.81 Интерфейс канального уровня (Link Layer Interface) интерфейс между канальным уровнем и более высокими уровнями связи 3.1.82 Управление канальным уровнем (Link Layer Management) интерфейс, управляющий канальным уровнем 3.1.83 От младшего к старшему (little-endian) порядок следования для хранения или передачи данных, при котором наименее значащая часть данных, состоящих из нескольких октетов, хранится по младшему адресу октета и передается первой 3.1.84 Локальная вычислительная сеть (local area network) часть сети, характеризуемая общим доступом к среде передачи данных и адресным пространством 3.1.85 Управление логическим каналом (logical link control) протоколы и связанные с ними форматы кадров, которые служат для управления канальным уровнем 3.1.86 Логический адрес (Logical Address) адрес, который не привязан к конкретному устройству (например, адрес данных процесса) 3.1.87 Логический порт (Logical Port) порты устройства, используемые для трафика данных процесса и с адресацией по логическому адресу 3.1.88 Макроцикл (Macro Cycle) количество основных периодов, соответствующих макропериоду 3.1.89 Макропериод (Macro Period) самый длинный отдельный период, после которого периодический трафик возвращается к тому же шаблону, измеряемый в миллисекундах 3.1.90 Основной канал (Main Channel) канал, по которому принимается основной трафик шины 3.1.91 Административное сообщение (Management Message) сообщение, которым обмениваются администратор и агент для осуществления сетевого управления Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 24 – 61375-2-1 IEC:2012 3.1.92 Администратор (Manager) Функция на станции, предназначенной для сетевого управления и отправляющая управляющие сообщения о вызове через системные адреса 3.1.93 Упорядочение (marshalling) распределение адресов или имен приложений для переменных процесса набора данных, которые в проводной шине поезда зависят от типа и версии узла 3.1.94 Управляющее устройство (Master) устройство, которое спонтанно отправляет информацию по шине нескольким подчиненным устройствам. Это дает подчиненному устройству право передавать только один подчиненный кадр в течение ограниченного периода времени 3.1.95 Главный кадр (Master Frame) Кадр, отправляемый управляющим устройством 3.1.96 Начальный ограничитель управляющего устройства (Master Start Delimiter) Начальный ограничитель главного кадра 3.1.97 Управление доступом к среде передачи данных (medium access control) Подуровень канального уровня, управляющий доступом к среде передачи данных (разрешение конфликтов, передача статуса управляющего устройства, опрос устройств) 3.1.98 Интерфейс, зависящий от среды передачи данных (medium dependent interface) механический и электрический интерфейс между средой передачи и блоком доступа к среде передачи данных 3.1.99 Среда передачи данных (medium) Физический носитель сигнала: электрические провода, оптоволокно и т.д. 3.1.100 Блок доступа к среде передачи данных (Medium Attachment Unit) устройство, используемое в качестве соединителя со средой передачи данных 3.1.101 Сообщение (message) элемент данных, переданный в одном или нескольких пакетах 3.1.102 Сообщения (Messages) Служба передачи данных сети поездной связи 3.1.103 Данные сообщения (Message Data) данные, периодически передаваемые на канальном уровне в связи с передачей сообщений; соответствующая служба канального уровня Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 25 – 3.1.104 Приложение для обмена сообщениями (мессенджер) (messenger) стек связи, обеспечивающий сквозную передачу сообщений и взаимодействие с приложением 3.1.105 Многоадресная передача (multicast) передача одного и того же сообщения группе ответчиков, идентифицированных их групповым адресом Определение «многоадресная передача» используется, даже если группа включает всех ответчиков 3.1.106 Многофункциональная поездная шина (MVB) (Multifunction Vehicle Bus MVB) Сеть железнодорожного подвижного состава, которая будет использоваться для подключения программируемых станций и простых датчиков/акторов. 3.1.107 Мотор-вагонный поезд (Multiple Unit Train) Поезд, состоящий из группы закрытых поездов, где состав данной группы может меняться в ходе эксплуатации в обычном режиме 3.1.108 Сеть (network) Совокупность возможных отличающихся систем, обменивающихся информацией согласованным способом 3.1.109 Сетевой адрес (Network Address) Адрес, определяющий функцию или станцию в сети. Это может быть адрес пользователя или системный адрес 3.1.110 Сетевой заголовок (Network Header) часть кадра данных сообщения, относящаяся к сетевому уровню 3.1.111 Сетевой уровень (Network Layer) уровень в модели OSI, отвечающий за маршрутизацию между различными шинами 3.1.112 Сетевое управление (Network Management) процессы, необходимые для удаленного конфигурирования, мониторинга, диагностики и обслуживания сети 3.1.113 Узел (Node) Устройство на проводной шине поезда, которое может выступать в качестве шлюза между шиной поезда и сетью железнодорожного подвижного состава 3.1.114 Адрес узла (Node Address) Адрес узла на шине поезда (6 бит) Он равен младшим 6 битам 8-битного адреса устройства на проводной шине поезда 3.1.115 Дескриптор узлов (Node Descriptor) 24-битная структура данных, которая задает для узла период узла и его ключ узла Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 26 – 61375-2-1 IEC:2012 3.1.116 Каталог узла (Node Directory) каталог, который преобразовывает адрес узла в адрес устройства (взаимно-однозначное преобразование в проводной шине поезда) 3.1.117 Ключ узла (Node Key) 16-битный идентификатор, выбранный приложением для определения типа и версии узла. Управляющее устройство распределяет его по всем остальным узлам после каждого изменения состава и перед обменом данными 3.1.118 Период узла (Node Period) На проводной шине поезда, желаемый отдельный период узла (идентичный отдельному периоду, за исключением случаев перегрузки) 3.1.119 Октет (octet) 8-битное слово, сохраненное в памяти или переданное как единица * 3.1.120 Открытый поезд (Open Train) Поезд, состоящий из группы железнодорожных составов, конфигурация которого может изменяться в ходе нормальной эксплуатации, например, подвижные составы международного сообщения Международного союза железных дорог 3.1.121 Источник (origin) отправитель пакета (данные или подтверждение) на сетевом уровне. Когда на одной шине взаимодействуют два устройства, источник находится в устройстве-адресате (см.: устройствоадресат). 3.1.122 Пакет (packet) единица сообщения (информация, подтверждение или управление), передаваемая ровно в одном кадре данных сообщения 3.1.123 Период (period) интервал времени, после которой повторяется периодический шаблон 3.1.124 Периодические данные (Periodic Data) Данные процесса передаются периодически, с интервалом, который является отдельным периодом 3.1.125 Периодический список (Periodic List) список узлов, адресов или устройств, которые будут опрашиваться в каждом периоде макроцикла 3.1.126 Периодическая фаза (Periodic Phase) фаза, во время которой управляющее устройство делает опрос на получение периодических данных в соответствии со своим периодическим списком 3.1.127 Физический адрес (Physical Address) Адрес узла на проводной шине поезда, который идентифицирует устройства связи на той же шине * * IEC предписывает «октет» вместо «байт» Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 27 – 3.1.128 Физический порт (Physical Port) Порт, используемый для трафика данных сообщений или контрольных данных с адресацией по адресу устройства 3.1.129 Шаг (pitch) расстояние между соседними устройствами на одной и той же электрической шине, необходимое для предотвращения концентрации нагрузки на шину 3.1.130 Опрос (polling) отправка главного кадра для получения подчиненного кадра 3.1.131 Порт (Port) структура памяти, которая содержит данные для передачи или приема и в которой новое значение перезаписывает прежнее значение (буфер, а не очередь). Порт предоставляет средства для одновременного доступа шины и приложений 3.1.132 Таблица индексов портов (Port Index Table) справочная таблица, которая выводит адрес памяти порта из логического адреса данных процесса 3.1.133 Преамбула (Preamble) последовательность сигналов в начале кадра с целью синхронизации приемника, используемого на проводной шине поезда 3.1.134 Уровень представления (Presentation Layer) уровень в модели OSI, отвечающий за представление данных и преобразование 3.1.135 Данные процесса (Process Data) данные с адресацией источника, периодически передаваемые на канальном уровне в связи с передачей переменных процесса; соответствующая служба канального уровня 3.1.136 Переменная процесса (Process Variable) переменная, выражающая состояние процесса (например, скорость, команда торможения) 3.1.137 Поставщик (Producer) отправитель сообщения на транспортном уровне (см. потребитель) 3.1.138 Публикатор (Publisher) Источник набора данных для широковещательной передачи (см. абонент) 3.1.139 Имя переменной процесса (PV Name) Идентификатор переменной процесса Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 28 – 61375-2-1 IEC:2012 3.1.140 Набор переменных процесса (PV Set) набор переменных процесса, принадлежащих одному и тому же набору данных 3.1.141 Очередь (queue) память, хранящая упорядоченный набор кадров в порядке «первым пришел-первым ушел» 3.1.142 Стойка (rack) оборудование, содержащее одно или несколько устройств, подключенных к одному сегменту 3.1.143 Повторная сборка (reassembly) действие по восстановлению длинного сообщения из нескольких пакетов, сгенерированных путем сегментации 3.1.144 Приемник (receiver) Электронное устройство, которое может получать сигналы из физической среды передачи данных 3.1.145 Очередь приема (Receive Queue) очередь на прием данных сообщения в устройстве 3.1.146 Плановая эксплуатация (regular operation) Нормальная работа шины в отличие от открытия эксплуатации (проводной шины поезда) 3.1.147 Повторитель (repeater) соединение на физическом уровне между сегментами шины, обеспечивающее распространение шины за пределы, установленные пассивными средствами. Соединенные сегменты работают на одной скорости и с одинаковым протоколом. Задержка, вносимая повторителем, примерно равна продолжительности одного бита 3.1.148 Ответчик (Replier) Прикладной процесс, который был запрошен вызывающим абонентом для получения сообщения о вызове и отправки ответа ответным сообщением 3.1.149 Коэффициент необнаруженных ошибок (residual error rate) Вероятность нарушения целостности (нераспознанный ошибочный бит) на каждый переданный бит 3.1.150 Маршрутизатор (router) Соединение между двумя шинами на сетевом уровне, передающее дейтаграммы от одной шины к другой на основании их сетевого адреса 3.1.151 Сканирование (scan) опрос устройств в определенной последовательности в целях контроля 3.1.152 Секция (section) часть сегмента, который пассивно соединен с другой секцией без терминатора между ними Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 29 – 3.1.153 Сегмент (segment) отрезок кабеля, к которому подключены устройства, ограниченный с обоих концов характеристическим полным сопротивлением. Сегменты могут состоять из нескольких секций (не ограниченных), соединенных разъемами 3.1.154 Сегментация (segmentation) разделение длинного сообщения на несколько более коротких кадров для передачи 3.1.155 Очередь отправки (Send Queue) очередь на отправку данных сообщения в устройстве 3.1.156 Служба (service) Возможности и характерные особенности подсистемы (например, коммуникационного уровня), предоставляемые пользователю 3.1.157 Заголовок сеанса (Session Header) часть кадра данных сообщения, относящаяся к сеансовому уровню 3.1.158 Сеансовый уровень (Session Layer) Уровень OSI, отвечающий за установление и завершение связи 3.1.159 Сторона А (Side A) одна сторона железнодорожного подвижного состава по отношению к узлу проводной шины поезда 3.1.160 Сторона В (Side B) другая сторона железнодорожного подвижного состава по отношению к узлу проводной шины поезда 3.1.161 Подчиненное устройство (Slave) устройство, которое получает информацию от шины или отправляет информацию по шине в ответ на запрос (также называемый опросом), полученный от управляющего устройства 3.1.162 Подчиненный кадр (Slave Frame) Кадр, отправляемый подчиненным устройством 3.1.163 Устройство-источник (Source Device) отправитель кадра на канальном уровне (см. устройство-адресат) 3.1.164 Спорадическая передача (sporadic transmission) передача, которая выполняется по запросу, когда этого требует событие, внешнее по отношению к сети (также называемая апериодической, управляемой событиями, управляемой запросом передачей) 3.1.165 Спорадические данные (Sporadic Data) Кадры данных, передаваемые по запросу передачи данных сообщения или контрольных данных Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 30 – 61375-2-1 IEC:2012 3.1.166 Спорадическая фаза (Sporadic Phase) вторая половина базового периода, отвечающая за управляемую запросом передачу сообщений и данных управления шиной 3.1.167 Звездообразный разветвитель (star coupler) устройство, которое принимает свет от оптического волокна и перераспределяет его по нескольким другим волокнам 3.1.168 Станция (Station) устройство, способное передавать сообщения, в отличие от простых устройств, и поддерживающее функцию агента 3.1.169 Каталог станции (Station Directory) каталог, который преобразовывает идентификатор станции в адрес канала и наоборот 3.1.170 Идентификатор станции (Station Identifier) 8-битный идентификатор станции 3.1.171 Слово состояния станции (Station Status Word) 16-битный дескриптор состояния и возможностей станции 3.1.172 Управляющее устройство с большой логической силой (Strong Master) Узел с большой логической силой, в настоящее время являющийся управляющим устройством и не отказывающийся от статуса управляющего устройства до тех, пока не будет понижен до состояния узла с малой логической силой 3.1.173 Узел с большой логической силой (Strong Node) Узел выбранный приложением в качестве управляющего устройства с большой логической силой. На сегменте шины может быть только одно управляющее устройство с большой логической силой 3.1.174 Шлейф (stub) Т-образное ответвление от линии электрической шины (на отводе), подключающее устройство к линии 3.1.175 Абонент (Subscriber) Один из получателей транслируемого набора данных (см. Публикатор) 3.1.176 Контрольные данные (Supervisory Data) данные, передаваемые в пределах одной шины только с целью контроля канального уровня (например, открытие эксплуатации на проводной шине поезда) 3.1.177 Системный адрес (System Address) Сетевой адрес административного сообщения, которым обмениваются администратор и агент, состоит из адреса узла и идентификатора станции 3.1.178 Отвод (tap) Место разветвления сегмента. Отвод представляет собой трехполюсную электрическую вилку Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 31 – 3.1.179 Телеграмма (Telegram) Главный кадр и соответствующий подчиенный кадр, рассматриваемые как единое целое 3.1.180 Терминатор (terminator) цепь, замыкающая линию электропередачи, в идеале по характеристическому полному сопротивлению 3.1.181 Переключатель терминатора (Terminator Switch) переключатель, который устанавливает терминатор в конце сегмента на проводной шине поезда 3.1.182 Топография (Topography) Структура данных, описывающая узлы, подключенные к шине поезда, включая адрес, ориентацию, положение и дискриптор узлов 3.1.183 Топология (topology) Возможная кабельная взаимосвязь и количество устройств, поддерживаемых данной сетью 3.1.184 Топографический счетчик (Topography Counter) Счетчик в узле, который увеличивает значение при каждом новом открытии эксплуатации 3.1.185 Хранилище трафика (Traffic Store) общая память, доступная как сети, так и пользователю, которая содержит порт данных процесса 3.1.186 Сеть поездной связи (Train Communication Network) сеть передачи данных для соединения программируемого электронного оборудования на борту рельсовых транспортных средств 3.1.187 Шина поезда, поездная магистральная линия связи (Train Bus, Train Backbone) Шина, соединяющая подвижные составы поезда, в частности, проводная шина поезда, соответствующая протоколам сети поездной связи (TCN) 3.1.188 Управление поездной сетью (Train Network Management) Службы управления сетью для сети поездной связи 3.1.189 Приемопередатчик (transceiver) Комбинация передатчика и приемника 3.1.190 Передатчик (transmitter) Электронное устройство, которое может передавать сигналы физической среде передачи данных 3.1.191 Передаваемые данные (Transport Data) данные, переносимые на транспортном уровне, но не относящиеся к нему Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 32 – 61375-2-1 IEC:2012 3.1.192 Транспортный заголовок (Transport Header) часть кадра данных сообщения, относящаяся к транспортному уровню 3.1.193 Транспортный уровень (Transport Layer) уровень модели OSI, отвечающий за сквозное управление потоком данных и устранение ошибок 3.1.194 Магистральный кабель (trunk cable) кабель, проходящий вдоль железнодорожного подвижного состава, в отличие от удлинительного кабеля или соединительного кабеля 3.1.195 Адрес пользователя (User Address) Сетевой адрес пользовательского сообщения, которым обмениваются функции, состоящий из адреса узла (или группового адреса) и идентификатора функции 3.1.196 Пользовательское сообщение (User Message) сообщения, которыми обмениваются пользовательские функции 3.1.197 Переменные (Variables) служба передачи данных сети поездной связи 3.1.198 Сдвиг переменной (Var_Offset) Битовый сдвиг переменной процесса в наборе данных 3.1.199 Дескриптор транспортного средства (Vehicle Descriptor) информация, зависящая от приложения, о конкретном транспортном средстве, такая как длина и вес 3.1.200 Управляющее устройство с малой логической силой (Weak Master) Узел с малой логической силой, в настоящее время являющийся управляющим устройством, который откажется от статуса управляющего устройства, если будет обнаружено другое управляющее устройство с большей логической силой 3.1.201 Узел с малой логической силой (Weak Node) Узел, который может спонтанно принять на себя статус управляющего устройства шины, но откажется от него, если будет обнаружен узел с большей логической силой 3.1.202 Проводная шина поезда (WTB) (Wire Train Bus (WTB)) Шина поезда для частого сцепления и расцепления подвижных составов, таких как подвижные составы международного сообщения Международного союза железных дорог 3.2 Сокращения ALI Интерфейс прикладного уровня, определение семантики всех сетевых служб, используемых приложением (набор примитивов, выраженных в виде процедур, констант и типов данных) AMA Адаптер прикладных сообщений, код, напрямую вызываемый приложением, которое реализует службу передачи сообщений AMI Интерфейс прикладных сообщений, определение службы передачи сообщений ANSI Американский национальный институт стандартов, орган по стандартизации в США. ASI Интерфейс прикладного контроля, определение служб управления Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 33 – ASN.1 Абстрактно синтаксическая нотация один (АСН 1) в представлении данных (ISO/IEC 8824) AVA Адаптер переменных приложения, код, напрямую вызываемый приложением, которое реализует службу переменных процесса AVI Интерфейс переменных приложения, определение переменных процесса BER Основные правила кодирования, синтаксис передачи для типов данных ASN.1 (ISO/IEC 8825) BR Скорость передачи цифрового потока данных, пропускная способность канала передачи данных, выраженная в битах в секунду (бит/с) или в герцах (Гц), по мере необходимости BT Время передачи бита, длительность передачи одного бита, выраженная в с ITU Международный союз электросвязи, международный орган по стандартизации телекоммуникаций, базирующийся в Женеве CRC Циклическая проверка избыточности, проверка целостности данных на основе полиномиального разделения DIN EIA Deutsches Institut für Normung, Германский национальный орган по стандартизации Ассоциация предприятий электронной промышленности, орган по стандартизации в США EP Трос электропневматического тормоза в соответствии с указанным в брошюре UIC 648 ERRI Европейский научно-исследовательский институт железнодорожного транспорта, лаборатория в Утрехте, Нидерланды FCS Контрольная последовательность кадров, код обнаружения ошибок, добавляемый к передаваемым данным в соответствии с указанным в ISO/IEC 13239 HDLC Высокоуровневое управление каналом передачи данных, протокол канального уровня, формат кадра которого определен в ISO/IEC 13239 IEC Международная электротехническая комиссия, Женева IEEE Институт инженеров по электротехнике и электронике, Нью-Йорк ISO Международная организация по стандартизации, Женева LFLD Обнаружение места неисправности линии LLC Управление логическим каналом, подуровень в пределах канального уровня обмена данными LME Субъект уровневого управления, отвечающий за контроль уровня от имени сетевого управления LMI Интерфейс управления уровнем, услуги, предоставляемые субъектом уровневого управления MAC Управление доступом к среде передачи данных, подуровень в канальном уровне, определяющий устройство, назначенное для отправки на шину MAU Блок доступа к среде передачи данных, часть узла, электрически взаимодействующая с шиной и подающая/принимающая двоичные логические сигналы MIB Информационная база управления, набор всех объектов, к которым обращается сетевое управление MVB Многофункциональная поездная шина, сеть железнодорожного подвижного состава NRZ Без возврата к нулю, простейшая схема кодирования, в которой один бит представлен одним уровнем для «1», а другим уровнем для «0» или наоборот, с отдельной синхронизацией ORE Office de Recherches et d’Essais, лаборатория UIC, базирующая в г. Утрехте, Нидерланды OSI Взаимосвязь открытых систем, универсальная модель связи, определенная в ISO/IEC 7498 PDM Упорядочение данных процесса PICS Свидетельство о соответствии реализации протокола, определенное в ISO/IEC 9646 PTA Адаптер данных процесса для хранилища трафика, компонент, который обращается к одному из хранилищ трафика RIC Правила взаимного использования купейных вагонов и грузовых вагонов в международном сообщении, изданные UIC RTP Протоколы реального времени, общие протоколы связи, представленные в разделе 6 настоящего стандарта Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 34 – 61375-2-1 IEC:2012 SDL Язык спецификаций и описания, язык спецификаций, определенный Приложением D ITUT Z100 для протоколов связи TCN Сеть поездной связи, набор сетей связи железнодорожного подвижного состава и поездных магистральных линий связи TNM Управление поездной сетью UIC Международный союз железных дорог, международная ассоциация операторов железных дорог WTB 3.3 3.3.1 Проводная шина поезда Обозначения Основные числовыезначения Числовые значения, представленные в настоящем стандарте, записаны в десятичной системе счисления, за исключением случаев, когда указано иное. Аналоговые и дробные величины содержат запятую. ПРИМЕР 1 Напряжение 20,0 В. Бинарные и шестнадцатеричные значения представлены в соответствии с ASN.1 (ISO/IEC 8824). ПРИМЕР 2 Десятичному числу 20 соответствует 8-битное число = ‘0001 0100’B = ‘14’H. 3.3.2 Обозначения наименований Ключевые слова в спецификациях сети поездной связи пишутся с заглавной начальной буквы. Если наименование составное, то различные части наименования соединяют через пробел. Когда структура данных связана с ключевым словом, ее тип состоит из тех же основных слов, разделенных символом подчеркивания. Когда значение, соответствующее ключевому слову, передается в сообщении, соответствующее поле имеет то же имя, что и тип, но пишется со строчной буквы. Когда значение передается как параметр, параметр имеет то же имя, что и поле в сообщении. На SDL-диаграммах соответствующая переменная имеет то же имя, что и тип, но без подчеркивания. ПРИМЕРЫ Топографический счетчик является счетчиком канального уровня; Это тип Topo_Counter (Топографический_Счетчик), который является UNSIGNED6 (БЕЗЗНАКОВЫЙ6) Когда его значение передается в сообщении, соответствующее поле называется «topo_counter» (топографический_счетчик). Когда его значение передается через процедурный интерфейс, параметр называется «topo_counter» , его C-тип - Type_Topo_Counter. На SDL-диаграммах переменная, представляющая счетчик, называется TopoCounter. 3.3.3 Обозначения наименований для времени Значения времени, начинающиеся со строчной буквы (например, t mm), являются измеримыми временными интервалами. Значения времени, начинающиеся с заглавной буквы (например, T ответ), являются параметрами или значениями тайм-аута. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 3.3.4 – 35 – Обозначения процедурного интерфейса Процедурный интерфейс определяется набором примитивов услуг, которые представляют собой абстрактное, независимое от реализации взаимодействие между пользователем услуги и поставщиком услуги. Эти примитивы выражены в этом стандарте как процедуры в синтаксисе ANSI C с типизированными параметрами. Их следует рассматривать только как семантическое описание, не подразумевающее конкретную реализацию или язык. Допускается использование любого интерфейса, обеспечивающего подобную семантику. Соответствие синтаксису этого интерфейса не может быть заявлено. В ходе реализации могут свободно изменяться имена процедур или параметров, добавляться параметры или разделяться процедуры до тех пор, пока предоставляется указанная услуга. Процедуры интерфейса определены в синтаксисе ANSI C с использованием шрифта Courier. Имена процедур, переменные и параметры отображаются в нижнем регистре. ПРИМЕР 1 lm_send_request Константы и определения типов отображаются в верхнем регистре. ПРИМЕР 2 UNSIGNED32 Имя процедуры или типа имеет префикс: для службы переменных lp_ Канальный уровень ap_ или AP_ Прикладной уровень Для службы передачи сообщений MD_ lm_ nm_ tm_ sm_ am_ или LP_ ил и ил и ил и ил и ил и LM_ сообщения в целом Канальный уровень NM_ Сетевой уровень TM_ SM_ Транспортный уровень Сеансовый уровень AM_ Прикладной уровень В Таблице 1 показан шаблон, используемый для процедур и типов. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 36 – Таблица 1 – Шаблон спецификации процедуры интерфейса Определение Здесь указывается тип службы или данных. В случае процедуры индикации здесь указывается событие, которое инициирует вызов, начиная с «When» («Когда»). Здесь определяются имя и параметры сервисной процедуры. В случае процедуры индикации указывается тип процедуры. Параметры ввода, параметры вывода и параметры возврата различаются Синтаксис MD_RESULT unsigned, UNSIGNED8 MD_PACKET * ENUM8 * Параметр ввода lm_send_request ( /* example */ destination, link_control, p_packet status ) Параметры ввода передаются процедуре, которая не может их изменять destination (адресат) Тип данных «unsigned» («беззнаковый») зависит от компилятора link_control (управление каналом) параметр, передаваемый по ссылке, не изменяемый процедурой. Тип данных — 8-битное слово. p_packet «*» обозначает указатель на структуру данных p_packet, которая имеет тип MD_PACKET, определенный в другом месте этого стандарта. Параметр вывода Ожидается, что параметры вывода будут изменены вызовом Результат Параметр Результат является необязательным параметром вывода, который выражает успех или неудачу вызова, но не обязательно услуги status (статус) MD_RESULT Тип ENUM8 — это 8-битный тип перечисления Тип параметра Результат: AM_RESULT для интерфейса прикладных сообщений (AMI), MD_RESULT для интерфейса управления уровнем (LMI), LP_RESULT для интерфейса канального уровня (LPI), AP_RESULT для интерфейса переменных приложения (AVI), В шаблоне указаны коды ошибок, ожидаемые для каждой процедуры в отдельности. Параметр Результат не описывается явно, если ожидаются только два значения: xx_OK = 0 успешное завершение; xx_FAILURE > 0 есть проблема. Результат также может быть возвращен в качестве параметра вывода в список параметров, в зависимости от реализации Использован Правила, перечисленные после шаблона процедуры, поясняют, как следует использовать процедуру. Хотя правила использования не являются обязательными, их несоблюдение ие приводит к непредсказуемым результатам. ПРИМЕЧАНИЕ Структуры данных, представленные в этой таблице, являются спецификациями интерфейса, которые не следует путать с форматами тех же структур данных при передаче по шине, см. 3.3.5. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 37 – Спецификация передаваемых данных 3.3.5 Формат передаваемых данных, как отдельных кадров, так и целых сообщений, может быть представлен в двух формах: a) графическая форма, которая не является нормативной, но наглядно показывает структуру сообщения; b) текстовая форма, основанная на ASN.1, с правилами кодирования, указанными в 6.3. ПРИМЕР 1 Графическая форма сообщения представлена в Таблице 2, соответствующая текстовая форма - в Таблице 3. Таблица 2 – Пример структуры сообщения первый передаваемый октет бит-> 0 2 15 14 snu gni 4 6 13 12 11 10 следующий передаваемый октет 9 8 7 6 5 node_id next_station_id 4 3 2 1 0 station_id rsv1 Tvd topo_counter tnm_key sif_code (= 3) parameter 1 8 parameter 2 parameter 3 par4 параметр 5: ARRAY [n] OF (repeat following field (n) times) parameter 5.1 parameter 5.2 parameter 5.3: STRING32 CHARACTER8 последний символ или 0 *октет Нумерация битов соответствует представлению степени числа два в байте или слове. Нумерация битов не указывает на последовательность передачи по шине, которая может быть разной: самый старший бит или самый младший бит. В графической форме для каждого слова из 16 бит используется одна строка, но в Разделе 5 (управление канальным уровнем проводной шины поезда)используются 8-битовые строки. Массиву параметров предшествует повторяющийся кадр, находящийся сверху и слева от него. Повторы могут быть вложенными (см. параметр 5.3 в Таблице 2). Если размер параметра может быть длиннее трех слов, для него отводится три строки, а средняя из них имеет затененные границы. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 38 – 61375-2-1 IEC:2012 Таблица 3 – Пример сообщения в текстовой форме (в соответствии с Таблицей 2) Call_Mgt_Message::= RECORD (ЗАПИСЬ) { snu BOOLEAN1 (=1) gni BOOLEAN1 (=0) node_id station_id UNSIGNED6 UNSIGNED8 next_station_id UNSIGNED8 rsv1 tvd BOOLEAN1 (=0) BOOLEAN1 topo_counter счетчик counter tnm_key UNSIGNED6 UNSIGNED8, sif_code UNSIGNED8, parameter1 INTEGER16, parameter2 INTEGER8, parameter3 UNSIGNED6, par4 бита parameter5 ANTIVALENT2 ARRAY [n] OF { parameter5.1 INTEGER16 parameter5.2 UNIPOLAR4.16 parameter5.3 STRING32 -- «1» означает, что сообщение использует системную адресацию -- «0» означает, что адресат является отдельным устройством -- 6-битный адрес узла адреса -- 8-битный идентификатор станции -- 8-битный идентификатор следующей станции -- данный бит всегда равен 0 -- этот бит указывает, действителен ли топографический счетчик -- 6-битный топографический -- оповещает о сообщении о вызове сетевого управления. -- для каждого административного сообщения существует свой SIF_код -- 16-битное значение. Если параметр имеет менее 16 бит, значение выравнивается по правому знаку и дополняется знаком (например, один октет передается как второй октет). -- это значение передается в самой значимой части слова. -- это значение передается в самом младшем октете, но два младших бита этого октета зарезервированы для параметра 4. -- параметр 4 включает два -- параметр 5 представляет собой структурированные данные, -- повторяемые раз, n содержащий: -- первый параметр повторяемого поля -- второй параметр повторяемого поля -- третий параметр - строка (массив до 32 8-битных символов); - строка закрывается символом «0» или двумя такими символами «0» для выравнивания по границе 16битного слова; - пустая строка состоит из З2 символов «0»; - фактический размер строки выводится из количества значащих символов, расположенных до нуля. }, } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 39 – Имена полей начинаются со строчной буквы, их тип начинается с прописной буквы. Иногда, если один и тот же тип используется в качестве формата передачи, то в этом случае верхний регистр используется только для первой буквы, если в качестве C-типа, то в этом случае верхний регистр используется для написания всего типа. ПРИМЕР 2 Am_Result (формат передачи) и AM_RESULT (C-тип процедуры интерфейса). 3.3.6 Обозначения диаграммы состояния Конечный автомат транспортного протокола представлен в ISO/IEC 8802-2 (уровень логической связи) в форме таблицы, которая определяет переходы между возможными состояниями, в которых может находиться конечный автомат. Переходы между состояниями регулируются событиями, поступающими с сетевого уровня (входящие пакеты), с сеансового уровня (команды) или в результате тайм-аутов. Действие, зависящее от события, выполняется перед выходом из состояния. Это действие определяет следующее состояние. На Рисунке 3 показана диаграмма перехода состояния. SETUP DISC SEND_ CANC SEND Рисунок 3 – Пример перехода состояния Из «SETUP» («УСТАНОВКА») аппарат может перейти в три разных состояния: DISC (ОТКЛЮЧЕНИЕ), SEND (ОТПРАВКА) или SEND_CANC (ОТМЕНА_ОТПРАВКИ). Переход между этими состояниями регулируется, как показано в Таблице 4. Таблица 4 – Таблица перехода состояния Текущее состояние Событие rcv_DR SETUP (УСТАНОВК rcv_CC AND А) (conn_ref = CC_conn_ref) Действие (я) close_send (DR_reason); Следующее состояние (если > текущее) DISC (ОТКЛЮЧЕНИЕ) IF (eot) THEN close_send (AM_OK); DISC ELSE credit:= CC_credit; (ОТКЛЮЧЕНИЕ) send_not_yet:= credit; send_data_or_cancel; END; SEND (ОТПРАВКА) или TMO AND close_send (AM_CONN_TMO_ERR); SEND_CANC (ОТМЕНА_ОТПРАВКИ) DISC (РАЗМЫКАНИЕ) (rep_cnt = MAX_REP_CNT) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 40 – Согласно Таблице 4 существует три события, которые вызывают переход из состояния SETUP (УСТАНОВКА) в состояние DISC (ОТКЛЮЧЕНИЕ): a) rcv_DR (получен Disconnect_Request (Запрос на_отключение), сетевое событие). Соответствующее действие состоит в замыкании соединения (close_send) перед переходом в состояние DISC (ОТКЛЮЧЕНИЕ); b) другое сетевое событие (получено Connect_Confirm (Подтверждение_Соединения) с правильной ссылкой), приводящее к состоянию DISC (ОТКЛЮЧЕНИЕ), SEND (ОТПРАВКА) или SEND_CANC (ОТМЕНА_ОТПРАВКИ), в зависимости от результата процедуры send_data (отправка_данных) или отмены; c) Тайм-аут, обусловленный предикатом (rep_cnt = MAX_REP_CNT), который также приводит к замыканию соединения. 3.4 3.4.1 Общие положения Интерфейс между оборудованием Настоящий стандарт определяет интерфейс передачи данных оборудования, расположенного в железнодорожном подвижном составе, в качестве подключения устройств к сети железнодорожного подвижного состава, как показано на рисунке 4. (Шина поезда) Рисунок 4 – Интерфейс между оборудованием Сеть железнодорожного подвижного состава предназначена в первую очередь, но не исключительно, для соединения оборудования, когда требуется взаимодействие и взаимозаменяемость. 3.4.2 Интерфейс между железнодорожными подвижными составами Настоящий стандарт определяет интерфейс передачи данных между подвижными составами как соединение узлов, расположенных в подвижных составах, с шиной поезда, как показано на Рисунке 5. Шина_поезда Узел Узел Узел Рисунок 5 – Интерфейс между железнодорожными подвижными составами В качестве шины поезда в настоящем стандарте определена проводная шина поезда (WTB), шина последовательной передачи данных, предназначенная в первую очередь, но не исключительно, для соединения, состоящего из открытых поездов. ПРИМЕЧАНИЕ Определение открытого поезда см. в Разделе 3. 3.4.3 Протоколы реального времени Настоящий стандарт определяет архитектуру сети поездной связи (TCN) как иерархию, состоящую из двух уровней: шины поезда и сети железнодорожного подвижного состава, как показано на Рисунке 6. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 41 – Шина поезда Узел Узел Узел Сеть подвижного состава Сетьо подвижного состава Сеть подвижного состава устройства устройства устройства Рисунок 6 - Шина поезда и сеть железнодорожного подвижного состава В качестве протоколов связи в Разделе 6 этого стандарта определены протоколы реального времени (RTP), используемые всеми узлами на проводной шине поезда. Устройства в сети железнодорожного подвижного состава могут использовать один и тот же протокол реального времени (например, многофункциональную поездную шину) или адаптировать протокол сети железнодорожного подвижного к протоколу реального времени узлов проводной шины поезда. Протокол реального времени определяет прикладной интерфейс, предоставляемый сетью поездной связи, включающий две основные услуги: Переменные и Сообщения. Протокол реального времени определяет протоколы передачи, которые обрабатывают, в частности, маршрутизацию, управление потоком и устранение ошибок. Протокол реального времени определяет интерфейс, который шины должны предоставлять для протоколов передачи, и, в частности, две основные услуги: a) циклическая широковещательная передача данных процесса с адресацией источника; и b) спорадическая передача данных сообщений без установления соединения. 3.4.4 Сетевое управление Касательно сетевого управления, Раздел 8 этого стандарта определяет сетевое управление для сети поездной связи (TNM) как набор сообщений, которыми обмениваются администратор и агент для предоставления основных услуг. 3.4.5 Конфигурация Настоящий стандарт может использоваться частично или целиком. Например, можно использовать: a) Проводную шину поезда без сети железнодорожного подвижного состава или с другой сетью железнодорожного подвижного состава, отличной от многофункциональной поездной шины; b) Протокол реального времени (RTP) с другими шинами, кроме проводной шины поезда (WTB) или многофункциональной поездной шины (MVB). На Рисунке 7 показаны три конфигурации, соответствующие трем прикладным областям: c) Конфигурация открытых поездов показывает открытый поезд, такой как поезд международного сообщения Международного союза железных дорог, для которого требуется автоматическая конфигурация. Проводная шина поезда используется в качестве стандартной шины поезда, поддерживающей до 32 узлов. В подвижном составе может быть 0, 1 или более узлов. К каждому узлу может быть подключено до 15 сетей железнодорожного подвижного состава (многофункциональная поездная шина (MVB) или другие); d) конфигурация мотор-вагонного поезда показывает два сцепленных закрытых поезда. Когда эти закрытые поезда часто сцепляются и расцепляются, проводную шину поезда можно использовать в качестве стандартной Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 42 – 61375-2-1 © IEC:2012 шины поезда, но когда возможна конфигурирование с помощью других средств, то вместо нее можно использовать другие шины, такие как многофункциональная поездная шина (MVB). Сеть железнодорожного подвижного состава может включать несколько транспортных средств; e) Конфигурация закрытых поездов показывает закрытый поезд, в котором сеть железнодорожного подвижного состава (например, многофункциональная поездная шина (MVB)) может использоваться и в качестве шины поезда, и в качестве сети железнодорожного подвижного состава. Открытые поезда WTB MVB проводящее транспортное средство (ТС) 0 шина ТС MVB 1 шина ТС MVB 2 шины ТС Мотор-вагонные поезда MVB MVB WTB MVB, другие 1 шина ТС Закрытые поезда MVB MVB 1 шина ТС xxx xxx MVB, другие 0 шин ТС Рисунок 7 - Конфигурация сети поездной связи (TCN) Во всех трех конфигурациях на Рисунке 7 многофункциональная поездная шина сети железнодорожного подвижного состава используется для подключения бортового оборудования, но в качестве сети железнодорожного подвижного состава могут использоваться и другие шины. 3.4.6 Структура стандартного устройства В этом подразделе определяются разрешенные опции в устройстве сети поездной связи (TCN). Варианты описаны в соответствующих разделах и обобщены на Рисунке 8. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 43 – TCN WTB плавающий экран заземленный экран стандартный соединитель резервная среда сплавление Данные_Процесса в Главных_Кадрах RTP возможнос ть маршрутиз атора каталог станции возможность многоадресно й передачи TNM возможность администрато ра Рисунок 8 – Варианты конфигурации устройства проводной шины поезда (WTB) сети поездной связи (TCN) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 44 – 3.4.6.1 61375-2-1 IEC:2012 Устройство сети поездной связи (TCN) Устройство проводной шины поезда, совместимое с сетью поездной связи, должно реализовать по крайней мере одну шину блока доступа к сети передачи данных (MAU) для проводной шины поезда. 3.4.6.2 Варианты проводной шины поезда Блок доступа к сети передачи данных проводной шины поезда должен быть сконфигурирован либо для плавающего экрана, либо для заземленного экрана. Блок доступа к сети передачи данных проводной шины поезда может использовать соединитель, как указано в настоящем стандарте. Блок доступа к сети передачи данных проводной шины поезда может использовать резервную среду, как указано в настоящем стандарте. Для блока доступа к сети передачи данных проводной шины поезда можно реализовать сплавление, как указано в настоящем стандарте. Блок доступа к сети передачи данных проводной шины поезда может передавать данные процессе в главных кадрах, как указано в настоящем стандарте. 3.4.6.3 Варианты протокола реального времени Устройство сети поездной связи должно реализовывать службы передачи переменных. Устройство сети поездной связи, за исключением устройства многофункциональной поездной шины Класса 1, должно реализовывать службы передачи сообщений. Устройство сети поездной связи может реализовывать функцию маршрутизатора, если оно имеет более одного блока доступа к сети передачи данных. Узел сети поездной связи может реализовать каталог узла. Устройство сети поездной связи может реализовать каталог станции. Устройство сети поездной связи должно реализовывать многоадресный протокол. 3.4.6.4 Варианты управления поездной сетью Устройство сети поездной связи должно реализовывать функцию агента. Устройство сети поездной связи должно реализовывать функцию администратора. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 3.5 – 45 – Проверка соответствия При заявлении о соответствии стандарту сети поездной связи (TCN), устройства должны пройти ряд испытаний. Для обеспечения взаимодействия в соответствии с Таблицей 5, настоящий стандарт включает набор руководств по проверке соответствия, которые перечислены в IEC 61375-2-2. Таблица 5 - Проверка возможности взаимодействия РАСПРОСТРАНЯЕТСЯ IEC 61375 Уровень 1 Интерфейс между подвижными составами (ШИНА поезда) Уровень 2 Интерфейс между оборудованием (сеть железнодорожного подвижного состава) ПРОТОКОЛ ФИЗИЧЕСКИЙ/ЭЛЕКТ РИЧЕСКИЙ Конечный ПОЛЬЗОВАТЕЛЬ ПОЛЬЗ. СООБЩЕНИЯ Характеристики соединительного кабеля узла (Z: затухание) МЕХАНИЧЕСКИЙ (соединители/кабели) ПРОТОКОЛ ФИЗИЧЕСКИЙ/ЭЛЕКТ РИЧЕСКИЙ ПОЛЬЗОВАТЕЛЬСКИЕ СООБЩЕНИЯ МЕХАНИЧЕСКИЙ (соединители/кабели) Уровень 3 Интерфейс между панелями и внутренними компонентами Не распространяется Не распространяется Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 46 – 4 61375-2-1 © IEC:2012 Физический уровень В этом разделе физическая среда проводной шины поезда определяется как экранированная шина с витой парой, работающая на скорости 1,0 Мбит/с. Этот стандарт предполагает, что различные секции, узлы и соединители обеспечивают максимально однородную электрическую среду в отношении распространения сигнала. Топология 4.1 4.1.1 Секции шины Проводная шина поезда должна состоять из узлов, соединенных между собой секциями шин следующих типов: a) магистральные кабели, проходящие вдоль подвижного состава (непрерывность связи между транспортными средствами обеспечивает только магистральный кабель); b) соединительные кабели, соединяющие магистральные кабели разных подвижных составов; c) удлинительные кабели, предназначенные для удлинения магистрального кабеля для достижения узла. 4.1.2 Разветвители Соединители и распределительные коробки могут использоваться для сборки узлов и кабельных секций. Каждый подвижной состав переносит часть шины и несколько узлов. 4.1.3 Узлы В ходе плановой эксплуатации каждый узел должен быть вставлен в магистральный кабель и подключен к двум секциям шины: a) узлы, расположенные на концах шины, или конечные узлы, должны электрически ограничивать две присоединенные к ним секции шины; b) узлы, расположенные в середине шины, или промежуточные узлы, должны электрически соединять две присоединенные к ним секции шины. Две секции кабеля, присоединенные к узлу, должны называться Направление_1 и Направление_2. Может быть один узел на состав или несколько узлов на одно транспортное средство в поезде, как показано на рисунке 9. соединительный кабель узел магистральный кабель и соединитель соединители конеч ный узел промежуточны удлинительные магистральный кабель терминаторы конечн ый узел узел й конечное трансп.средство промежуточное транспортное средство кабели конечное трансп.средство Рисунок 9 – Состав поезда (показано два промежуточных узла) 4.1.4 Ориентация железнодорожного подвижного состава Если ориентация узлов критична для распознавания слева направо, должны соблюдаться следующие соглашения: a) один конец подвижного состава определяется как крайняя точка 1, другой - как крайняя точка 2; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 47 – c) если направление_1 указывает на север, сторона подвижного состава, указывающая на запад, называется стороной A, сторона, указывающая на восток, называется стороной B; d) для узла используется те же обозначения для A и B, что и для подвижного состава, в котором он расположен. ПРИМЕЧАНИЕ 1 Направление_1 одного узла может указывать либо на направление_1, либо на направление_2 другого узла, за исключением случаев, когда оба узла находятся в одном подвижном составе, поскольку ориентация подвижных составов относительно друг друга непредсказуема. ПРМЕЧАНИЕ 2 Крайняя точка 1 подвижного состава представляет собой конец состава, противоположный местоположению стояночного тормоза. Характеристики железнодорожного подвижного состава (для справки) 4.1.5 Поскольку изготовитель может поставлять отдельные подвижные составы или узлы, а не весь поезд, технические характеристики на шину, подвижной состав и узлы рассматриваются отдельно. В настоящем стандарте определены характеристики всей шины и каждого узла. Для конкретного приложения из них извлекаются характеристики подвижного состава. При этом соответствие поезда стандарту соблюдается при условии, что количество транспортных средств, подвижных составов или узлов не превышено. Следующие расчеты применяются к железнодорожному транспорту, как указано в СТАНДАРТЕ UIC 556. Для других вариантов применения, таких как общественный транспорт, могут использоваться аналогичные расчеты. Состав эталонного поезда в СТАНДАРТЕ UIC 556 включает в себя 22 транспортных средства, что обеспечивает длину кабеля 860,0 м без использования повторителей. Обычно в подвижной состав входит только один узел, но до 10 подвижных составов, состоящих из одного транспортного средства (например, головного вагона), могут поддерживать второй узел, всего 32 узла. Согласно п. 4.5.2 узел ослабляет сигнал менее чем на 0,3 дБ (при номинальной частоте), суммарное затухание на узлах не будет превышать 32 0,3 дБ = 9,6 дБ. Согласно п. 4.6.3 приемники могут обрабатывать динамический диапазон 20,0 дБ, остаточное затухание по всему поезду для кабеля, соединителей и других элементов не должно превышать 20,0 – 9,6 = 10,4 дБ. Таким образом, максимальное ослабление, отведенное для транспортного средства, составляет 10,4 дБ/22 = 0,5 дБ. Это значение измеряется при демонтаже узла (узлов) и замыкании их соединений накоротко. Соединительный кабель учитывается при измерении, как показано на Рисунке 10. соединительный кабель и соединитель B 1A 2 измерительный прибор источник сигнала 1 1 узел 2 соединители показаны как прямо подключенные 2 Рисунок 10 – Измерение транспортного средства Вследствие изгибов и удлинительных кабелей длина кабеля на транспортное средство составляет около 150 % от длины транспортного средства. Предполагается, что при длине транспортного средства 26,0 м среда должна охватывать расстояние, превышающее 860 м (22 26,0 1,5 = 858,0 м). Для выполнения этих требований затухание среды должно составлять не более 10,4 дБ/860,0 м или 12,0 дБ/км. Поскольку соединительные кабели, соединители и сращивания могут привести к более высокому затуханию, рекомендуется использовать магистральный кабель с затуханием не более 10,0 дБ/км (4.2.4). Тот же принцип применим и к другим параметрам искажения. Схема измерения поясняется в п. 4.5.2.1 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 48 – Когда состав оборудован резервной линией_A и линией_B, испытания проводится для каждой линии по отдельности. 4.2 4.2.1 Спецификация среды Топология Узлы должны быть вставлены в кабель проводной шины поезда, каждый узел прикреплен к двум секциям шины, как показано на Рисунке 11. конечное транспортное конец средство распределительная коробка 0..30 промежуточные транспортные средства магистральный кабель конец сегмент шины удлинительный кабель вставленные терминаторы конечное транспортное средство соединительный кабель и соединитель вставленные направление_1 1 2 направление_2 контроллер шины контроллер шины Конечный_узел Промежуточный_узел снятые терминаторы терминаторы 2 1 терминаторы контроллер шины Конечный_узел Рисунок 11 – Соединительные узлы в ходе плановой эксплуатации Узел должен иметь возможность: a) устанавливать электрическую непрерывность между двумя секциями шины, подключенными к нему, чтобы функционировать в качестве промежуточного узла, либо b) электрически ограничивать присоединенные к нему секции шины посредством терминатора (сеть адаптации полного сопротивления), чтобы функционировать в качестве конечного узла. Конечные узлы должны иметь возможность отправлять и получать данные через обе секции шины независимо друг от друга, в то время как промежуточные узлы должны быть оснащены только одним из своих приемопередатчиков. 4.2.2 Дублирующая среда (дополнительно) В настоящем стандарте определена схема резервирования, в которой каждый узел подключен к двум линиям через независимые линейные блоки, как показано на Рисунке 12. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 49 – B A 2 Направление_1 1 Направление_2 Линейны й_ блок B A 2 Линейны й_ блок А Узел Линейны й_ блок A Линейны й блок В 1 2 _ Узел _ 2 A Направление_1 1 Линейны й_ блок А Линейны й блок В 2 B Узел 1 B Рисунок 12 – Подключение двухпроводной линии В случае использования данного варианта применяются следующие характеристики: a) линии должны быть идентифицированы как линия_A и линия_B; b) данная идентификация должна быть согласованной для всех узлов в пределах одного подвижного состава; c) кабели, принадлежащие к разным линиям, должны иметь четкую маркировку; d) Линия_A и линия_B должны иметь одинаковую конфигурацию по отношению к направлению_1 и направлению_2. ПРИМЕЧАНИЕ 1 Для транспортных средств Международного союза железных дорог использование двухпроводной линии является обязательным, поскольку невозможно соединить транспортные средства только одной линией. ПРИМЕЧАНИЕ 2 Линия_A связана со стороной A подвижного состава, а линия_B связана со стороной B. ПРИМЕЧАНИЕ 3 Поскольку ориентация составов непредсказуема, линия_A одного подвижного состава может быть соединена с линией_B другого подвижного состава, как показано на Рисунке 12. 4.2.3 Правила конфигурирования шины Настоящие характеристики применяются к шине, работающей в максимально возможной степени. Если не указано иное, все электрические величины должны измеряться посредством синусоидального сигнала с частотой 1,0 МГц ± 0,01 % с амплитудой дифференциального сигнала ± 4,0 В (8,0 В пик). 4.2.3.1 Скорость передачи сигналов Все сегменты шины должны работать с одинаковой скоростью 1,0 Мбит/с ± 0,01 %, что, благодаря манчестерскому кодированию, соответствует сигнальной частоте 1,0 МГц (BT = 1,0 мкс, BR = 1,0 МГц). 4.2.3.2 Задержка в результате воздействия узлов и кабелей T_pd, задержка сквозного прохождения по шине не должна превышать 60,0 мкс между любыми двумя узлами. ПРИМЕЧАНИЕ 1 Задержка прохождения для данного приложения может быть оценена как T_pd = (L × 6,0 + R × T_rd) где L - длина кабеля (магистрального, удлинительного и соединительного кабеля) в метрах; 6,0 нс/м приблизительно соответствует задержке прохождения по нагруженной линии передачи; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 50 – 61375-2-1 IEC:2012 R - число повторителей; и T_rd -задержка прохождения повторителя. ПРИМЕЧАНИЕ 2 Проводная шина поезда может образовать соединение длиной 860,0 м без повторителя, но повторители могут быть полезны в некоторых вариантах применения. ПРИМЕЧАНИЕ 3 Данная спецификация соответствует допустимой задержке, указанной в пп. 5.2.2.2 и 4.7.2.2. 4.2.3.3 Затухание в результате воздействия узлов и кабелей Суммарное затухание напряжения между любыми двумя узлами, расположенными на одном сегменте, не должно превышать 20,0 дБ при измерении синусоидального сигнала на частоте от 0,5 BR до 2,0 BR. ПРИМЕЧАНИЕ 1 Затухание пропорционально количеству узлов и общей длине кабеля. ПРИМЕЧАНИЕ 2 Настоящая спецификация соответствует динамическому диапазону приемника, указанному в п. 4.6.3. 4.2.3.4 Искажение в результате воздействия узлов и кабелей Ограниченный сегмент при его максимальной протяженности и поддержке максимального количества узлов должен добавлять не более 0,1 BT искажения фронта по отношению к идеализированному переходу через нуль. Условия испытания: линия подключена к источнику дифференциального сигнала с амплитудой 4,0 В пик 10 %, с центром на 0,0 В, через полное сопротивление источника 22,0 10 %; управляющий сигнал представляет собой псевдослучайную последовательность символов манчестерского кодирования «0» и «1» с периодом повторения не менее 511 бит. ПРИМЕЧАНИЕ 1 Помехи и отражения в результате несоответствия полного сопротивления между секциями, шлейфами, соединителями или кластером нагрузки могут привести к искажению во время перехода через нуль. ПРИМЕЧАНИЕ 2 4.2.3.5 Настоящая спецификация, взятая из ISO/IEC 8802-3, соответствует допустимому искажению, указанному в 4.6.3. Сдвиг между резервными линиями (дополнительно) Максимальная разница в задержке похождения сигнала между линией_A и линией_B не должна превышать T_skew = 30,0 с между любыми двумя узлами. ПРИМЕЧАНИЕ Настоящая спецификация соответствует допускаемому сдвигу приемника, указанному в п. 4.7.2.4.1. 4.2.4 4.2.4.1 Характеристики кабеля Механические характеристики Все секции кабеля должны представлять собой двухжильный, витой экранированный кабель с защитной оболочкой. Пара должна иметь не менее 12 витков на метр. Рекомендуемое поперечное сечение проводов магистрального кабеля составляет 0,75 мм2 (AWG 18). Рекомендуемое поперечное сечение проводов соединительного кабеля составляет 1,34 мм 2 (AWG 16). При использовании непрямого крепления через Sub-D-соединители, как показано в п. 4.3.4, то поперечное сечение каждого провода удлинительного кабеля должно составлять не более 0,56 мм 2 (AWG 20). 4.2.4.2 Маркировка Отдельные провода витой пары обозначаются буквами X и Y, экран – буквой S. Отдельные жилы кабеля должны быть четко промаркированы. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 51 – Маркировка должна сохраняться на всех местах соединения и сращивания. 4.2.4.3 Характеристическое полное сопротивление Дифференциальное характеристическое полное сопротивление для всех секции шин, измеренное синусоидальным сигналом на частоте от 0,5 до 2,0 BR, должно составлять Zw = 120,0 (10 %). 4.2.4.4 Затухание в кабеле Рекомендуется, чтобы затухание синусоидального сигнала в кабеле составляло не более 10,0 дБ/км при 1,0 BR и не более 14,0 дБ/км при 2,0 BR. 4.2.4.5 Распределенная емкость Дифференциальная (междупроводная) распределенная емкость кабеля не должна превышать 65 пФ/м при 1,0 BR. 4.2.4.6 Емкостная асимметрия на экран Емкостная асимметрия на экран не должна превышать 1,5 пФ/м при 1,0 BR. 4.2.4.7 Подавление перекрестных помех При прокладке двух пар проводов в одном удлинительном кабеле подавление сигнала от одной пары к другой должно составлять не менее 55,0 дБ при скорости передачи цифрового потока данных в диапазоне от 0,5 BR до 2,0 BR. 4.2.4.8 Качество экрана Переходное полное сопротивление кабеля на частоте 20,0 МГц должно составлять не менее 20,0 м/м, измеренное в соответствии с п. 5.1.5.1.2. IEC 61375-2-2. Дифференциальное переходное полное сопротивление кабеля на частоте 20,0 МГц должно составлять не менее 20,0 м/м, измеренное в соответствии с п. 5.1.5.1.2. IEC 61375-2-2. 4.2.4.9 Качество соединителя ПРИМЕЧАНИЕ Настоящие требования не распространяются на соединители между транспортными средствами. Все кабельные соединения должны обеспечивать непрерывность проводов и экрана с сопротивлением не более 10,0 м. Переходное полное сопротивление соединителя, измеренное на частоте 20,0 МГц, должно быть не более 20,0 м между одним контактом и экраном, соответственно 2,0 м между двумя контактами, измеренное в соответствии с методом, указанным в п. 5.1.5.1.2 IEC 61375-2-2. 4.2.5 Концепция экранирования Для удовлетворения различных вариантов применения определены две концепции экранирования: концепция заземленного экрана (предпочтительный метод) и концепция плавающего экрана. 4.2.5.1 Концепция заземленного экрана При применении концепции заземленного экрана: экраны должны быть подключены непосредственно к заземлению узла в каждом узле; соединительные кабели не должны обеспечивать непрерывность экрана между транспортными средствами, как показано на Рисунке 13. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 52 – 61375-2-1 © IEC:2012 ПРИМЕЧАНИЕ 1 Экраны, по возможности, должны быть заземлены, например, на концах транспортного средства, на границе шкафа и т.д. с тем, чтобы закольцевать индуцированные токи на коротких путях и предотвратить создание помех ЭМС через экран. Для этого требуется надлежащая проводимость корпуса транспортного средства для предотвращения больших блуждающих токов тягового подвижного состава. Конечный_узел терминаторы заземление транспортного средства соедини тельная Промежуточный_узел соединит ельная Конечный_узел перемычка перемычка полное сопротивлени е внутри транспортного средства полное сопротивление внутри транспортного средства заземление транспортного средства заземление транспортного средства Рисунок 13 - Концепция заземленного экрана ПРИМЕЧАНИЕ 2 Концепция заземленного экрана описана в брошюре UIC 558. 4.2.5.2 Концепция плавающего экрана При применении концепции плавающего экрана: экран должен быть изолирован от земли, когда он не подключен к узлу; на каждом узле экран должен быть соединен с заземлением узла резистивно-емкостной цепью, состоящей из резистора номиналом Rs = 47,0 кОм ± 5 % параллельно с конденсатором Cs = 100,0 нФ ± 10 %, 750,0 В, как показано на Рисунке 14. Конечный_узел Промежуточный _узел (ы) соединительный кабель и соединитель терминаторы Rs Rs Cs 4.2.6 Конечный_узел полное полное Cs сопротивл сопротивл ение ение внутри внутри заземление узла транспорт транспорт Рисунок 14 - Концепция плавающего экрана ного ного средства средства Rs Cs Терминатор Конечные узлы должны электрически ограничивать два сегмента шины, к которым они подключены, с помощью терминатора. Терминатор должен представлять собой неполяризованный резистор со значением Zw ± 5 % и фазовым углом не более 0,087 рад в диапазоне частот от 0,5 BR до 2,0 BR. Терминатор должен быть изолирован от кабельного экрана. Терминатор должен иметь сопротивление 2,4 кОм пост. тока, приложенного между X и Y, способного рассеивать не менее 1,0 Вт постоянной мощности (даже в случае применения, не требующего сплавления). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 53 – ПРИМЕР Рекомендованная цепь показана на Рисунке 15. X Rt Rf Cf Y Компоненты Тип Значение Rt резистор 130,0 Ом Rf резистор 2,4 Ом Cf конденсатор 47,0 нФ Рисунок 15 -Терминатор Подключение к среде 4.3 Следующие подпункты определяют два метода подключения узла: узлы прямого подключения соединяются непосредственно с магистральным кабелем без соединителя; узлы напрямого подключения подключаются к магистральному кабелю через соединители. 4.3.1 Идентификация точек соединения узлов Узел должен идентифицировать две секции шины, присоединенные к нему, как «направление_1» и «направление_2», относящиеся только к этому узлу. Узел должен идентифицировать две линии, присоединенные к нему, как «линия_A» и «линия_B». Если используется только одна линия, это должна быть линия_А. Места присоединения кабеля к линейному блоку должны быть названы: a) A1X, A1Y и A1S для линии_A1 (линия_A в направлении_1) и b) A2X, A2Y и A2S для линии_A2 (линия_A в направлении_2), соответственно c) B1X, B1Y и B1S для линии_В1 (линия_В в направлении_1) и d) B2X, B2Y и B2S для линии_В2 (линия_В в направлении_2). 4.3.2 Прямое подключение узла Узел прямого подключения должен быть вставлен в кабель и закреплен винтами или другими креплениями, отвечающими электрическим и механическим требованиям, как показано на Рисунке 16: Направление_1 Направление_2 A1X A1Y Линия_A1 Линейный блок A A1S A2X A2Y A2S Линия_A2 Узел B1X B1Y (резерв) Линия_B1 B1S Линейный_блок B (резерв) B2X B2Y B2S (резерв) Линия_B2 Рисунок 16 - Прямое подключение узла (дополнительная вторая линия) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 54 – 61375-2-1 © IEC:2012 Должна существовать возможность демонтировать узел и соединить кабели двух направлений вместе для обеспечения непрерывности кабеля и экрана. 4.3.3 Непрямое подключение узла Узлы непрямого подключения должны использовать два соединителя в однопроводном подключении или четыре в двухпроводном подключении, как показано на Рисунке 17. A1X A1Y A1S A2X A2Y A2S Кабель A1 Кабель A2 для подключения резервной линии 12 XY 12 XY Линейный_блок A соединитель А1 (штекерный на линейном блоке) 12 12 XY XY Линейный_блок B соединитель А2 соединитель В1 (гнездовой на линейном блоке) (штекерный на линейном блоке) соединитель B2 (гнездовой на линейном блоке) Рисунок 17 – Непрямое подключение 4.3.4 Соединитель(дополнительно) Если требуется взаимозаменяемость, узлы непрямого подключения должны быть присоединены к кабелю следующим образом: a) в качестве соединителя следует использовать сверхминиатюрный D-соединитель (IEC 60807); b) соединитель должен иметь экранированный токопроводящий корпус, чтобы: для обеспечения концепции заземленного экрана этот корпус был соединен с экраном кабеля и имел электрический контакт с розеткой при креплении; для обеспечения концепции плавающего экрана корпус можно было изолировать от экрана кабеля; c) винты соединителя должны иметь метрическую резьбу; d) соединитель должен иметь следующую полярность и конструкцию: Для направления_1 следует использовать штекерный соединитель на линейном блоке и гнездовой соединитель на кабеле; для направления_2 следует использовать гнездовой соединитель на линейном блоке и штекерный соединитель на кабеле; когда соединители одной линии расположены вертикально, направление_1 должно быть связано с верхним соединителем, направление_2 — с нижним соединителем, линия_А — с верхней парой; когда соединители одной линии расположены горизонтально, направление_1 должно быть связано с левым соединителем, направление_2 — с правым соединителем, линия_А — с передней парой; e) должна существовать возможность соединения и скрепления кабельных соединителей двух направлений вместе для обеспечения непрерывности кабеля и экрана. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 55 – соединитель (штекер или гнездо) должен иметь разводку контактов в соответствии с указанным в Таблице 6, как показано на Рисунке 18. f) Таблица 6 - Разводка контактов соединителя проводной шины поезда 1 X положительный провод 6 резервный 2 Y отрицательный провод 7 резервный 3 зарезервирован для экрана 8 резервный 4 резервный 9 резервный 5 резервный 1 X резервный 6 2 Y резервный 7 3 резервный резервный 8 4 резервный резервный 9 5 резервный Рисунок 18 - Соединитель проводной шины поезда, вид спереди ПРИМЕЧАНИЕ узла. 4.4 4.4.1 Для концепции плавающего экрана предпочтительно, чтобы розетка была электрически разделена с корпусом Характеристики узлов Элементы узла Узел должен быть присоединен к среде передачи данных с помощью блока доступа к среде передачи данных (MAU). Блок доступа к среде передачи данных при однопроводном подключении должен включать: a) Линейный блок; b) Коммутатор направления; c) Основной канал и дополнительный канал. ПРИМЕР А Блок доступа к среде передачи данных с переключателями промежуточной настройки показан на Рисунке 19. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 56 – 61375-2-1 © IEC:2012 Направление_1 Направление_2 Kb шинный переключатель переключатель терминатора Zt1 Kt2 Kt1 X Y Zt2 X Y приемопередат TxS TxE кодер Линейный блок А1 RxS декодер TxS TxE кодер RxS декодер Линейный блок А2 Линейный_ блок А2 канал 2 канал 1 Коммутатор_направления Основной_канал Дополнительный_канал Рисунок 19 – Пример структуры блока доступа к среде передачи данных 4.4.1.1 Элементы линейного блока Линейный блок должен включать a) шинный переключатель (Kb), предназначенный для соединения и отключения двух направлений; b) переключатель терминатора для каждого направления (Kt1, Kt2), предназначенный для вставки терминатора (Zt1, Zt2) в узел при конечной настройке или его демонтажа из узла при промежуточной настройке; c) две цепи приемопередатчика (передатчика/приемника), по одной на каждое направление. Каждый передатчик управляется двоичными сигналами TxS (сигнал) и TxE (разрешение). Выход приемника RxS (цифровой или аналоговый сигнал). Приемопередатчики гальванически изолированы от линии соответствующими средствами, например, трансформатором; d) два кодера/декодера для манчестерского кодирования, по одному на каждый приемопередатчик, которые могут быть интегрированы в соответствующие передатчики или приемники. Выход и вход кодера/декодера для манчестерского кодирования определяются как интерфейс модема; e) цепи защиты от перенапряжения/короткого замыкания, подключенные к разъединителям (на Рисунке 19 не показаны). ПРИМЕЧАНИЕ 1 Узел, подключенный к резервной среде, имеет два линейных блока ПРИМЕЧАНИЕ 2 Переключатели Kb и Kt1 или Kt2 могут быть контактами одного и того же механического реле, если такие реле используются. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 4.4.1.2 – 57 – Основной канал и дополнительный канал Как основной канал, так и дополнительный канал должны быть способны отправлять и получать HDLC-кадры и управляющие сигналы, направленные к линейным блокам и от них. ПРИМЕЧАНИЕ Поскольку вспомогательный канал принимает и отправляет кадры только для обнаружения дополнительных узлов и для получения их адреса, его работу можно упростить по сравнению с основным каналом. 4.4.1.3 Коммутатор направления Коммутатор направления должен соединять основной канал с направлением_1, а дополнительный канал с направлением_2 или наоборот. ПРИМЕЧАНИЕ Коммутатор направления не обязательно является физическим элементом, он может быть реализован в логике или программном обеспечении. 4.4.2 Настройки узла и переключателя В этом подпункте представлены характеристики узла для двух настроек: Промежуточной настройки и конечной настройки. 4.4.2.1 Промежуточная настройка При промежуточной настройке узел должен: a) устанавливать непрерывность между двумя сегментами линии (Kb закрыт); b) удалить оба терминатора Zt1 и Zt2 (Kt1 и Kt2 открыты); c) подключить основной канал к линии через приемопередатчик 1 или приемопередатчик 2; d) отключить дополнительный канал и неиспользуемый приемопередатчик. ПРИМЕЧАНИЕ Промежуточная настройка используется неработающим (отключенным или обесточенным) узлом и узлами, не расположенными в конце шины. 4.4.2.2 Конечная настройка При конечной настройке узел должен: a) изолировать оба сегмента (Kb размокнут); b) вставить оба терминатора (Kt1 и Kt2 закрыты); c) подключить дополнительный канал в одном направлении, а основной канал в другом направлении. ПРИМЕЧАНИЕ Конечная настройка принимается анонимным узлом, узлом в конце шины (в частности, управляющим без подчиненного) или узлом в спящем режиме. 4.4.3 Дублируемые линейные блоки (дополнительно) В случае использования данного варианта применяются следующие характеристики: Блоки доступа к среде передачи данных, предназначенные для дублирования подключения, должны быть присоединены к линии_A и линии_B через отдельные линейные блоки; настройки узла (конечная настройка или промежуточная настройка) должны одинаково применяться к обоим линейным блокам; должна быть предусмотрена возможность удаления одной линии при сохранении работоспособности другой линии. ПРИМЕР Блок доступа к среде передачи данных для резервной линии показан на Рисунке 20. Логика переключения позволяет получать сигналы либо от линии_A, либо от лнии_B. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 58 – Линия_A Линия_В Направление_1 A1 A2 B1 B2 Направление_2 приемопередатчики Линейный_блокA E/D Линейный_блок B E/D E/D E/D кодеры/декодеры коммутатор направления и логика переключения Основной_канал Дополнительный_ канал Рисунок 20 - Узел с резервными линейными блоками 4.5 Характеристики линейного блока Хотя упоминается только линейный блок A, эти характеристики также применимы к линейному блоку B, если используется дублирующая среда. 4.5.1 Гальваническая развязка Напряжение изоляции и сопротивление изоляции между корпусом узла и любой из точек: A1X, A1Y, A2X или A2Y должны превышать значения, указанные в IEC 60571. ПРИМЕЧАНИЕ Эти значения, указанные в текущей редакции, составляют 0,50 кВ среднеквадратичного значения и 1,0 М. 4.5.2 4.5.2.1 Вносимые потери в линейном блоке Измерение затухания Для измерения вносимых потерь синусоидальный сигнал генератора (с внутренним полным сопротивлением = Zt) подается по кабелю длиной 20,0 м к точкам A1X и A1Y и измеряется вольтметром (подключенным параллельно с полным сопротивлением Zt) на конце других 20,0 м кабеля, присоединенного к точкам A2X и A2Y или наоборот, как показано на Рисунке 21. Затухание определяется как отношение, выраженное в дБ, двух разных напряжений: a) первое напряжение устанавливается равным 4,0 В пик, когда узел демонтирован и присоединен кабельный соединитель; b) второе напряжение измеряется, когда узел вставлен (в ходе конечной или промежуточной настройки, в зависимости от испытания). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 Zt = 120 – 59 – 120 , 20м 120, 20м Zt=120 В f = 0,5 BT f = 2,0 BT A1X A1Y Испытание 1: Узел демонтирован, а соединители подключены напрямую A2X A2Y Узел Испытание 2: Узел вставлен Рисунок 21 – Измерение затухания Узел при конечной настройке 4.5.2.2 Линейный блок при конечной настройке (Kb открыт, Kt1 и Kt2 закрыты) должен представлять для сигнала 1,0 BR, приложенного между A1X и A1Y или между A2X и A2Y, полное сопротивление, соответствующий терминатору, указанному в 4.2.6. Линейный блок при конечной настройке должен ослаблять сигнал, подаваемый между A1X и A1Y и измеренный между A2X и A2Y, или наоборот, более чем на 55,0 дБ. Узел при промежуточной настройке 4.5.2.3 Линейный блок при промежуточной настройке (Kb открыт, Kt1 и Kt2 закрыты), либо: a) с приемником в нормальном режиме и с передатчиком в состоянии высокого полного сопротивления, или b) при отсутствии подачи питания на приемник или передатчик, должен ослаблять синусоидальный сигнал: не более, чем на 0,3 дБ между при скорости передачи цифрового потока данных 0,5 BR и 1,0 BR; и не более, чем на 0,4 дБ при скорости передачи цифрового потока данных до 2,0 BR. Узел должен иметь сопротивление не менее 1 МОм при положительном или отрицательном напряжении постоянного тока 48,0 В, приложенном между A1X и A1Y или между A2X и A2Y. 4.5.3 Характеристики переключателей Все переключатели, подключенные к линии шины (Kb, Kt, и т.д.): a) должны обеспечивать изоляцию не менее 500,0 В среднеквадратичного значения в открытом состоянии; b) должны обеспечивать начальное сопротивление контактов не более 0,050 Ом в закрытом положении; c) должны обеспечивать сопротивление контактов не более 0,100 Ом в закрытом положении после 107 циклов; d) должны переключаться с одной настройки на другую менее чем за 10,0 мс, включая время дребезга контактов. ПРИМЕЧАНИЕ Реле может быть твердотельным или механическим. 4.5.4 Соединение экрана с линейным блоком В каждом узле экраны кабелей в направлении_1 и направлении_2 должны быть соединены вместе через розетки с контактным сопротивлением не более 0,010 Ом. Линейный блок должен обеспечивать средства для подключения экранов к корпусу узла как: a) непосредственно через низкий импеданс, как указано в п.4.2.5.1 (заземленный экран); так и b) через резистивно-емкостную цепь, указанную в п. 4.2.5.2 (плавающий экран). ПРИМЕР Принцип крепления экрана в узле показан на Рисунке 22. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 60 – 61375-2-1 © IEC:2012 Направление_2 Направление_7 A1X A1Y Cs A2X A2Y Rs Узел корпус Рисунок 22 - Заземление экрана в линейном блоке 4.5.5 Сплавление (дополнительно) Для предотвращения окисления контактов в реле и соединителях в узле может использоваться сплавление, заключающееся в подаче постоянного напряжения между проводами X и Y в любом направлении. При использовании варианта сплавления, применяются условия, указанные в настоящем подразделе. ПРИМЕЧАНИЕ 1 Использование сплавления не указано для нерезервированной среды. ПРИМЕЧАНИЕ 2 Узлы, в которых не используется сплавление, и узлы, в которых используется сплавление, могут одновременно присутствовать на одной и той же шине. 4.5.5.1 Источник сплавления и нагрузка Узел, поддерживающий сплавление, должен обеспечивать источник напряжения сплавления и нагрузку напряжения сплавления для каждого направления. В случае резервной физической среды узел должен обеспечивать два независимых источника напряжения сплавления, по одному для каждого направления, и должен обеспечивать нагрузки для напряжения сплавления другого узла, как показано на Рисунке 23. Линия_A1 A1X A2X Линейныйблок A A1Y B1X Линия_B1 B1Y A2 A2Y нагрузка сплавления источник сплавления Узел Направление_2 источник сплавления нагрузка сплавления Направление_1 Конечный узел Линия_ Линейный_бло к B (резерв) B2X B2Y Конечный узел Линия_ Конечный узел B2 Рисунок 23 - Источник сплавления и нагрузка Положительный полюс источника сплавления должен быть подключен к A2X и соответственно к B1X. Отрицательный полюс источника сплавления должен быть подключен к A2Y и соответственно к B1Y. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 61 – Источник сплавления должен подавать постоянное напряжение 48,0 В +20 %/–10 %, измеренное в точках соединения (A2X/A2Y и соответственно B1X/B1Y), когда соответствующая линия со вставленным терминатором подключена к терминатору, указанному в п. 4.2.6, или оставлен открытым. Пульсации источника сплавления должны быть ниже 0,100 Впик при скорости передачи цифрового потока в диапазоне от 0,5 BR до 2,0 BR. Ток, подаваемый источником сплавления, не должен превышать 80,0 мА постоянного тока. Источник сплавления должен иметь изоляцию на входе и выходе в соответствии с IEC 60571. Источник сплавления должен быть отделен от линии, например, катушкой индуктивности 0,10 Гн или любым другим устройством, которое компенсирует вносимые потери узла. Постоянная времени включения источника должна быть в диапазоне от 0,5 мс до 5,0 мс. Постоянная времени выключения источника должна быть в диапазоне от 0,5 мс до 5,0 мс. Затухание между двумя источниками напряжения сплавления в одном узле должно составлять не менее 50,0 дБ при скорости передачи цифрового потока в диапазоне от 0,5 BR до 2,0 BR. Применение сплавления 4.5.5.2 Конечный узел должен включить источник через через свой активный дополнительный канал (анонимный узел имеет оба направления в качестве активных дополнительных каналов, узел в спящем режиме не имеет активного дополнительного канала). ПРИМЕЧАНИЕ 1 Узел может генерировать импульсы своим источником сплавления, например, для уменьшения потребления. ПРИМЕЧАНИЕ 2 Переключение источника сплавления по основному каналу разрешено, если это соответствует уровню электромагнитных помех. Характеристики приемопередатчика 4.6 Блок доступа к среде передачи данных, подключенный к резервной шине, имеет четыре приемопередатчика с именами A1, A2, B1 и B2. В нерезервированной схеме используются только приемопередатчики A1 и A2. Следующие условия относятся к ним. 4.6.1 Соглашения Если не указано иное, по умолчанию действуют следующие условия измерения: a) характеристики приемопередатчика измеряются в точках X и Y, где секции кабеля присоединяются к узлу; b) все напряжения измеряются как дифференциальное напряжение между X и Y (Ux-Uy); c) при измерении передатчика цепь приемника находится в нормальном состоянии приема. При измерении приемника цепь передатчика находится в состоянии с высоким значением полного сопротивления; d) все значения резисторов составляют 1 %, все значения конденсаторов составляют 10 %. 4.6.2 4.6.2.1 Передатчик Нагрузка передатчика Для определения характеристик передатчика определены четыре испытательные цепи для имитации кабелей и узлов: a) испытательная цепь с малой нагрузкой имитирует открытую линию (как в узле при конечной настройке). Суммарная резистивная нагрузка равна нагрузке терминатора; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 62 – 61375-2-1 © IEC:2012 b) Испытательная цепь с большой нагрузкой имитирует полностью нагруженную шину. Величина полной резистивной нагрузки равна 0,42 нагрузки терминатора; c) испытательная холостая цепь имитирует кабель длиной 860,0 м без резистивных нагрузок. Номинальное значение для каждого конденсатора составляет 1,3 нФ ± 10 %, номинальное значение для каждого резистора составляет 27,0 Ом ± 1 %; d) короткозамкнутая испытательная цепь имитирует отказ линии. Она состоит только из цепи измерения тока; Данные цепи показаны на следующем рисунке. испытательная цепь с малой нагрузкой испытываемый передатчик TxS терминат ор Rt Kt Ux испытательная цепь с большой нагрузкой 0,75 0,42 Rt Rt TxE замкнутый переключате ль Uy 27 испытат холостая цепь Rt 1,3 нФ 1,3 1,3 нФ Короткоз.испыт. цепь A Рисунок 24 - Крепление передатчика e) измерение выполняется при конечной настройке узла (Kb открыт, Kt закрыт); f) терминатор линейного блока учитывается в спецификации испытательной схемы. 4.6.2.2 Выходной сигнал передатчика ПРИМЕЧАНИЕ Вследствие используемого кодирования данных передатчик генерирует импульсы длиной либо один бит (1,0 BT), либо полубит (0,5 BT) между преамбулой и конечным ограничителем. Эти условия применимы как к импульсам 0,5 BT, так и к импульсам 1,0 BT, положительным или отрицательным. Передатчик должен являться дифференциальным драйвером. Выходным сигналом является дифференциальное напряжение (Ux-Uy) в точке подключения узла. При подключении либо к испытательной цепи с большой нагрузкой, либо к испытательной цепи с малой нагрузкой, определенной в п. 4.6.2.1, передатчик должен соответствовать следующим условиям, как показано на Рисунке 25: a) выходной сигнал должен быть поочередно положительным и отрицательным; b) амплитуда выходного сигнала должна быть не менее ±3,0 В для испытательной цепи с большой нагрузкой и не более ±7,0 В для испытательной цепи с малой нагрузкой; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 63 – c) пиковая амплитуда определяется как максимальная амплитуда выходного сигнала. Сигнал не должен понижаться более чем на 20 % от указанной пиковой амплитуды до истечения 0,100 мкс от следующего ожидаемого перехода через нуль. Затухание амплитуды за это время по отношению к среднему падению напряжения не должно превышать 5 % пикового значения; d) скорость нарастания выходного сигнала должна быть не более 0,20 В/нс в любой момент времени и не менее 0,03 В/нс в течение 100,0 нс перехода через нуль; e) выброс выходного сигнала, определяемый как отношение максимальной установившейся амплитуде, не должен превышать 10 % установившейся амплитуды; f) искажение фронта выходного сигнала, определяемое как разница во времени между идеализированным и фактическим переходом через нуль, не должно превышать ±2 % времени передачи бита. Ux-Uy [В] 25 нс (200 мВ/нс) амплитуды к 25 нс +5,0 падение < 20% пик. значения + 3,0 пик. знач ение 6В пик затухание < 5% пик. значения ± 20 нс ± 20 нс 100 нс вре мя 100 нс 0,5 или 1,0 BT номинал - 3,0 200 мВ/нс - 5,0 0,5 BT или 1,0 BT Рисунок 25 – Форма импульсной волны на передатчике ПРИМЕЧАНИЕ Ожидается, что падение напряжения произойдет вследствие сплавления конденсатора, включенного в цепь последовательно с трансформатором. 4.6.2.3 Шум передатчика Любой шум, создаваемый передатчиком, который не участвует в передаче сигнала, не должен превышать 5,0 мВ среднеквадратичного значения в диапазоне частот от 1,0 кГц до 4,0 кГц. 4.6.2.4 Конец кадра передатчика Конец кадра, создаваемого передатчиком, должен быть испытан при следующих условиях: a) передатчик передает максимально длинный кадр; b) биты данных_кадра представляют собой псевдослучайную последовательность символов «1» и «0»; c) кадр закрывается символом конечного ограничителя, как указано в п. 4.7.1.4; d) передатчик запускает испытательную холостую цепь согласно 4.6.2.1; e) средняя амплитуда дифференциального сигнала превышает 4,5 В до отключения передатчика. В этих условиях выходной сигнал должен оставаться в следующих пределах, как показано на Рисунке 26: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 64 – 61375-2-1 © IEC:2012 1) через 100,0 нс после последнего перехода с отрицательного на положительное значение и в течение 2,0 BT ± 100 нс выходной сигнал должен оставаться выше 0,300 В; 2) в течение 3,0 ВТ после последнего перехода с отрицательного на положительное значение, напряжение выходного сигнала должно упасть ниже 1100 В; 3) в течение 20,0 мкс, начиная с первого достижения выходным сигналом значения 1,100 В, амплитуда выходного сигнала не должна превышать 0,100 В; 4) в течение 64,0 мкс, начиная с первого достижения выходным сигналом значения 1,100 В, амплитуда выходного сигнала не должна превышать 0,025 В; Ux-Uy [В] < 3,0 BT 64 мкс 3000 1100 100 25 - 25 - 100 вре мя BT > 2,0 BT -4000 20 мкс Рисунок 26 – Сигнал и пауза передатчика ПРИМЕЧАНИЕ Затухание в линии после паузы передатчика можно свести к минимуму путем выравнивания сигнала в каждой битовой ячейке. Дальнейшее снижение может быть достигнуто за счет выравнивания конечного ограничителя, как указано в п. 4.7.1.4. Отказоустойчивость передатчика 4.6.2.5 Передатчик, включенный или выключенный, должен быть устойчивым к применению короткозамкнутой испытательной цепи (4.6.2.1) в точке соединения до тех пор, пока не будет достигнута тепловая стойкость, и должен возобновлять нормальную работу после демонтажа короткозамкнутой испытательной цепи. Ток короткого замыкания не должен превышать 1,0 А. ПРИМЕЧАНИЕ Для проверки соответствия считается, что тепловая стойкость достигается через 1 ч. Ограничение использования протокола XMPP (jabber) для передатчика 4.6.2.6 Каждый передатчик должен содержать независимую схему для отключения передатчика от линии шины, если продолжительность передачи превышает значение T_jabber, равное продолжительности максимально возможного кадра (включая преамбулу, конечный ограничитель и положительное выравнивание) + 20 %. 4.6.3 Характеристики приемника 4.6.3.1 Характеристики сигнала приемника Приемник должен декодировать сигнал следующей формы, как показано на Рисунке 27, который применяется в точке соединения: a) при амплитуде принимаемого сигнала на более 0,100 В крутизна принятого сигнала превышает 2,0 мВ/нс; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 65 – b) когда принимаемый сигнал остается выше 0,300 В в течение периода времени, который начинается через 100,0 нс после предыдущего перехода через нуль и длится не менее (0,5 BT – 350,0 нс), соответственно (1,0 BT – 0,350 мкс), его пиковая амплитуда будет варьироваться от 0,330 В до 5,00 В; Ux - Uy [мВ] 5000 330 300 50 нс 100 врем 2 мВ/нс я 50 нс 250 нс > (BT - 350 нс) или BT/2 - 350 нс BT или BT/2 Рисунок 27 - Огибающая сигнала приемника Ошибка кадра определяется как отсутствующий или недопустимый кадр (см. п.4.7.1.5.3), неправильный размер кадра или неправильные биты данных_кадра (ошибка контрольной последовательности кадров (FCS)). 4.6.3.2 Полярность приемника ВЫСОКИЙ уровень на TxS должен соответствовать положительному дифференциальному напряжению (Ux – Uy), которое, в свою очередь, должно соответствовать ВЫСОКОМУ уровню сигнала RxS приемника. ВЫСОКИЙ уровень на TxS должен соответствовать положительному дифференциальному напряжению (Ux – Uy), которое, в свою очередь, должно соответствовать ВЫСОКОМУ уровню сигнала RxS приемника. Состояние RxS является неопределенным, когда линия свободна. 4.6.3.3 Чувствительность приемника Приемник, принимающий кадры, содержащие 64 случайных бита данных, со скоростью 1000 кадров в секунду, должен обнаруживать не более трех ошибок кадров в 3 × 3 × 10+6 кадрах, когда амплитуда принятого сигнала, определенная в п.4.6.3.1, изменяется между его минимальным и максимальным значением. ПРИМЕЧАНИЕ Согласно Рисунку 27 приемник способен работать в диапазоне напряжений от 0,500 В до 0,330 В, что составляет около 23,6 дБ. Это оставляет запас по шуму около 4,0 дБ, учитывая, что среднее затухание, указанное в п.4.2.3.3, составляет менее 20,0 дБ. 4.6.3.4 Нечувствительность приемника Приемник не должен декодировать допустимый кадр (см. п.4.7.1.5.3), если принимаемый сигнал (п.4.6.3.1) меньше 0,100 В. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 66 – 4.6.3.5 61375-2-1 © IEC:2012 Искажение фронта сигнала приемника Приемник, принимающий кадры, содержащие 64 случайных бита данных, со скоростью 1000 кадров в секунду, должен обнаруживать не более трех ошибок кадров в 3 × 3 × 10+6 кадрах, когда фронты тестового сигнала случайно пересекают линию нулевого напряжения в пределах ±10 % от 1,0 BT вокруг ожидаемого пересечения, как показано на Рисунке 28. Ux - Uy 0,5 BT 1,0 BT высокий уровень 0,1 BT 0,1 BT время низкий уровень 1 бит.ячейка «0» 1 бит.ячейка «1» Рисунок 28 - Искажение фронта сигнала приемника 4.6.3.6 Подавление шума приемника Приемник, принимающий кадры, содержащие 64 случайных бита данных, со скоростью 1000 кадров в секунду и с амплитудой сигнала 0,700 В (размах сигнала 1400 В), должен обнаруживать не более 3 ошибок кадра 3 × 10+6 кадров во время работы: в присутствии синфазного синусоидального сигнала, приложенного между корпусом и обоими проводными каналами данных с амплитудой 4000 В среднеквадратичного значения в диапазоне частот от 65,0 Гц до 1,5 МГц; или в присутствии аддитивного квазибелого гауссова шума (приложенного между X и Y), распределенного в полосе частот от 1,0 кГц до 4,0 МГц при амплитуде 0,140 В среднеквадратичного значения 4.7 4.7.1 4.7.1.1 Передача сигналов, зависящая от среды передачи данных Кодирование и декодированиекадра Соглашения Кодирование и декодирование предполагает, что отправленный или полученный сигнал является двоичным, без смещенного уровня. Уровень полученного сигнала является неопределенным, когда линия свободна. RxS представляет собой идеализированный (аналоговый) сигнал, полученный от линии. Кадр должен передаваться как последовательность положительных и отрицательных уровней, начиная с преамбулы и заканчивая конечным ограничителем, прежде чем он вернется в состояние режима ожидания, как показано на Рисунке 29 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 67 – RxS «S» «0» положительный «1» «1» «0 «1» «0 «1 «1 » » » «1 «1 «0 » » » режим ожидания » режим ожидания время отрицательный 1 старт 2 3 4 14 15 16 Преамбула Данные_кадра Начало и конец данных с последовательностью флага '01111110'B кадры начинаются с последовательности '1010101...1011'B конец Конечный ограничи тель Рисунок 29 - Идеализированный кадр на линии (показана 16-битная преамбула) Кодирование битов 4.7.1.2 Биты преамбулы и данных_кадра должны быть закодированы посредством манчестерского кода, как показано на Рисунке 30: бит «1» должен быть закодирован на отрицательный уровень на протяжении первой половины битовой ячейки с переходом к положительному уровню в середине ячейки; бит «0» должен быть закодирован на положительный уровень на протяжении первой половины битовой ячейки с переходом к отрицательному уровню в середине ячейки. «1» 1,0 BT TxS «0» 1,0 BT 1,0 BT = время передачи одного положительный бита 0,5 BT = время передачи отрицательный половины бита 0,5 BT 0,5 BT Рисунок 30 - Кодирование битов Расстояние до фронта должно должно составлять либо время передачи полного бита («0» следует за «1» или «1» следует за «0»), либо время передачи половины бита (последовательность «0» или последовательность «1») до тех пор, пока не будет достигнут конечный ограничитель кадра. Кодирование преамбулы 4.7.1.3 Кадр должен начинаться с преамбулы, состоящей из последовательности битов, начинающейся с начального бита S, передаваемого как бит «1», за которым следуют пары битов («0», «1») и замыкающийся битом «1», как показано на Рисунке 31. повтор .. .. RxS 1 2 3 4 5 14 15 16 положительный режим ожидания отрицательный время «S» «0» «1» «0» «1» «0» «1» «1» Преамбула (показано 16 бит) «0» «1» «1» «1» «1» Данные_кадра (начало с флага 01111110) Рисунок 31 -Преамбула Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 68 – 61375-2-1 © IEC:2012 Между начальным битом и замыкающим «1» должно быть не менее семи и не более 15 пар («0», «1»). Декодер может проверить полярность RxS путем декодирования преамбулы, но он не должен автоматически инвертировать сигнал, если X и Y случайно поменялись местами. ПРИМЕЧАНИЕ В дальнейшем будет рассматриваться только 16-битная преамбула. Конечный ограничитель 4.7.1.4 Кадр должен быть замыкаться конечным ограничителем, который поддерживает линию на положительном уровне в течение 2,0 BT. Отрицательный уровень 2,0 BT с продолжительностью 2,0 BT может быть добавлен после положительного уровня для компенсации ассиметрии, как показано на Рисунке 32. RxS положительный режим ожидания отрицательный время допустимо «1» «1» «1» «1» «0 » Конечный Данные_кадра конец _ (конец с флагом 0111110) ограничитель Рисунок 32 - Конечный ограничитель ПРИМЕЧАНИЕ 1 Конечный ограничитель при отсутствии отрицательного уровня вызывает асимметрию, в результате чего происходит затухание сигнала на линии (см.п. 4.6.2.4). Корректирующий импульс настоятельно рекомендуется, но не обязателен, для получения разрешения на использование генерирующих его коммерческих цепей. ПРИМЕЧАНИЕ 2 Вследствие флага HDLC (см. П.5.2.1), последним битом кадра является «0». 4.7.1.5 Контроль качества сигнала В следующих спецификациях предполагается, что декодер генерирует два сигнала, называемых «Carrier_Sense» («Контроль_несущей») (CS) и «Signal_Quality_Error» («Ошибка_качества_сигнала») (SQE), для контроля качества сигнала и переключения на резерв. 4.7.1.5.1 Carrier_Sense (Контроль_несущей) Декодер должен установить контроль несущей (CS) в течение 0,5 BT после того, как он обнаружит последний принятый бит преамбулы в соответствии с п. 4.7.1.3. Декодер должен отменить контроль несущей (CS) в течение 0,5 BT после того, как он обнаружит конечный ограничитель или обнаружит биты, которые не являются ни «0», ни «1», ни конечным ограничителем. 4.7.1.5.2 Signal_Quality_Error (Ошибка_качества_сигнала) Декодер должен отменить ошибку качества сигнала (SQE) в течение 0,5 BT после того, как он обнаружит последний принятый бит преамбулы в соответствии с п. 4.7.1.3. Декодер должен подтвердить ошибку качества сигнала (SQE) в течение 0,5 BT, если обнаружит биты, которые не являются ни «0», ни «1», ни конечным ограничителем, когда контроль несущей (CS) будет подтвержден. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 69 – Допустимый кадр 4.7.1.5.3 Кадр должен быть определен как допустимый, если он состоит из преамбулы, ряда битов «0» и «1» и конечного ограничителя. ПРИМЕР Допустимый кадр и соответствующие сигналы контроль несущей (CS) и ошибки качества сигнала (SQE) показаны на Рисунке 33. Преамбула «S» «0» «1» RxS 1 2 Конечны й_ ограничит ель Данные_кадра «0» «1» «1» 3 4 14 15 16 «1» «0» «ED» 0 < t < 0,5 BT CS 0 < t < 0,5 BT подтвержд 0 < t < 0,5 BT (если предыдущий кадр искажен) (если предыдущий кадр верен) SQE отменен Рисунок 33 - Допустимый кадр, сигналы RxS, CS и SQE В целях управления резервированием допустимый кадр должен состоять из преамбулы, за которой следует последовательность не менее восьми битов данных. Недопустимый кадр 4.7.1.5.4 Кадр должен быть определен как недопустимый, если ошибка качества сигнала (SQE) подтверждена в течение времени, превышающего 0,5 BT, когда будет подтвержден контроль несущей (CS). ПРИМЕР Синхронизация сигналов при приеме искаженного кадра показана на Рисунке 34. Преамбула Конечн ый_ ограничи тель Данные_кадра искаженный RxS «S «0 «1» » » 3 1 «0» «1 «1 «0 «1 » » » » 4 «1 «0 » » «ED » время 14 2 15 16 0 < t < 0,5 BT подтвержден CS 0 < t < 0,5 BT SQE (если предыдущий кадр искажен) (если предыдущий кадр верен) подтвержден Рисунок 34 - Искаженный кадр, сигналы RxS, CS и SQE Если ошибка качества сигнала (SQE) становится активной, декодер должен игнорировать все данные до тех пор, пока не будет получена следующая преамбула. 4.7.2 Обслуживание дублируемой линии (дополнительно) Настоящая спецификация определяет дополнительную схему резервирования. В случае использования этой опции следующие спецификации применяются как к направлению_1, так и к направлению_2, а также к линии_A и линии_B. 4.7.2.1 Принцип Узел одновременно передает одни и те же данные по линии_A и линии_B, и узел принимает данные из одной линии, называемой доверенной линией, в то время как он контролирует другую линию, называемую наблюдаемой линией. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 70 – Каждый узел выбирает свою доверенную линию и наблюдаемую линию на основании сигналов, генерируемых на его собственном физическом уровне, или по запросу его канального уровня, независимо от других узлов. Чтобы оставаться независимым от среды, выбор доверенной линии зависит от сигналов, генерируемых линейным блоком в соответствии с тем, как они определены в интерфейсе линейного блока. 4.7.2.2 Сдвиг Поскольку сигналы на лниии_A и лниии_B имеют разную задержку, их сдвиг (разница во времени) различается на передатчике, на приемнике или в любом месте на линии, как показано на Рисунке 35. RxS.A RxS.B время Преамбула t_skew Данные_кадра 1010 .................1011 01111 110 01 1 1 1 1 1 0HH Рисунок 35 - Резервные линии (как отображается на приемнике) 4.7.2.3 Передача посредством резервных устройств Блок доступа к среде передачи данных с резервными линейными модулями должен передавать один и тот же сигнал по линии_A и линии_B (линии_A1 и лниии_B1 или линии_A2 и линии_B2). Разница во времени между сигналом, измеренным на выходе линейных блоков между линией_А и линией_В в одном направлении, не должна превышать время сдвига передачи T_skew_t = 1,0 с. 4.7.2.4 4.7.2.4.1 Прием посредством резервных устройств Сдвиг на приеме Приемник должен допускать максимальный сдвиг на приемнике, время сдвига приема T_skew_r составляет 32,0 с. 4.7.2.4.2 Line_Disturbance (Линия повреждена) Для каждой из секций шины, подключенных к узлу, должен быть предусмотрен сигнал «Line_Disturbance» («Линия_повреждена»), называемый DA1 и DA2 для линии_A и dB1 и dB2 для линии_B. Сигнал «Line_Disturbance» («Линия_повреждена») линии должен быть подтвержден, если: декодер подтверждает «Signal_Quality_Error» («Ошибка_качества_сигнала») в этой линии; или декодер не генерирует «Carrier_Sense» («Контроль_несущей») в пределах T_skew_r после того, как линейный блок избыточной линии подтвердит сигнал «Carrier_Sense» (отсутствующий кадр). Сигнал «Line_Disturbance» («Линия_повреждена») должен быть отменен: когда декодер получает допустимый кадр согласно п. 4.7.1.5.3. В нерезервированном режиме неиспользуемая линия считается постоянно повержденной. ПРИМЕР Случай, когда все кадры на линии_A1 являются допустимыми, но линия_B1 повреждена, показан на Рисунке 36. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 71 – RxS.A1 CS.A1 Преамбула SQE.A1 DA1 RxS.B1 допус искаженн тим ый ый отсутств искажен допуст имый >T_skew.r = 32 мкс CS.B1 отсутств >T_skew.r = 32 мкс SQE.B1 DB1 как минимум преамбула + 8 допустимых битов данных переключение (если линия В является доверенной) <T_switchover = 64 мкс Рисунок 36 - сигналы Line_Disturbance (Линия повреждена) 4.7.2.5 Переключение Направление_1 и направление_2 (конечного) узла могут доверять разным линиям (например, линии_A1 и линии_B2). Блок переключения должен поменять местами доверенную линию и наблюдаемую линию в течение времени переключения T_switchover = 64,0 мкс: a) если сигнал Line_Disturbance (Линия_повреждена) доверенной линии подтвержден, в то время как сигнал Line_Disturbance (Линия_повреждена) наблюдаемой линии не подтвержден; b) При запросе данного сигнала канальным уровнем (особенно если возникает ошибка размера, контрольной последовательности кадров (FCS) или протокола). 4.7.2.6 Отчет блока доступа к среде передачи данных Блок доступа к среде передачи данных должен предоставлять отчет для управления канальным уровнем: a) по какой линии им был получен кадр; b) о каждом подтверждении сигнала Line_Disturbance (Линия_повреждена) на любой линии и в любом направлении; c) о состоянии четырех сигналов Line_Disturbance (Линия_повреждена) (DA1, DA2, dB1, dB2) для отчета об узле (см. п. 5.5.2.2). ПРИМЕЧАНИЕ Если линия полностью отключена (или не подключена), сигнал Line_Disturbance (Линия_повреждена) переключится один раз после возникновения повреждения. Однако, если линия прерывается, сигнал Line_Disturbance (Линия_повреждена) может переключаться почти после каждого кадра в зависимости от места прерывания. 4.7.3 Интерфейс линейного блока Интерфейс линейного блока определяет сигналы, входящие и исходящие из линейного блока. Данный интерфейс может оставаться внутренним для узла, но рекомендуется сделать его доступным для тестирования. Данный интерфейс не подлежит проверке соответствия. Следующая спецификация упрощает взаимодействие посредством интерфейса и определяет сигналы, используемые в других подразделах настоящего стандарта. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 72 – В случае использования интерфейс линейного блока должен включать в себя сигналы модема, в соответствии с указанным в Рекомендации ITU-T V24, для каждого приемопередатчика по отдельности, и дополнительные управляющие сигналы, кв соответствии с указанным в Таблице 7. Таблица 7 - Сигналы интерфейса линейного блока Имя Назначение Раздел Направление Значение Рекоменда ции ITU-T V.24 GND Сигнальная земля 102 - общий минус TxD Данные передатчика 103 к линейному блоку Данные_кадра без преамбулы или конечного ограничителя, отправляемые в качестве сигнала NRZ (без возврата к нулю), синхронизированные по TxC. RxD Данные приемника 104 от линейного блока Последовательность NRZ (без возврата к нулю), включая преамбулу и конечный ограничитель, с синхронизацией по RxC. RTS Запрос на передачу 105 к линейному блоку команды для отправки преамбулы; сброс этого сигнала управляет генерацией конечного ограничителя. CTS Готовность к передаче 106 от линейного блока сообщает о том, что преамбула была передана, и запрашивает данные, которые следуют за ней. TxC Тактовый генератор передатчика 114 от линейного блока генерируется приемопередатчиком для синхронизации данных TxD для отправки. RxC Тактовый генератор приемника 115 от линейного блока генерируется декодером для синхронизации полученных данных RxD. SQE Signal_Quality_Error (Ошибка_качества_сигнала ) Carrier_Sense (Контроль_несущей) Сигналы управления переключением отсутствует от линейного блока в V.24 согласно 4.7.1.5.2 отсутствует от линейного блока в V.24 отсутствует к линейному блоку в V24 согласно 4.7.1.5.1 CS Kx Определяют как минимум две основные настройки переключателя: Конечная настройка и Промежуточная настройка для обеих линий. Кроме того, сигналы управления переключением могут изолировать приемопередатчик от линии или подключить его к линии. 5 5.1 Управление канальным уровнем Адресация Канальный уровень должен использовать 8-битный идентификатор как для исходного, так и для целевого Device_Address (Адреса_устройства). Адресация основного канала узла должна соответствовать адресу устройства в диапазоне от 1 ('00000001'B) до 63 ('00111111'B), как было указано в ходе процедуры открытия эксплуатации. Основной канал управляющего устройства должен получить адрес 1 «управляющего устройства» (‘00000001’B). Адрес устройства 0 (‘00000000’B) должен быть «собственным» адресом и не должен передаваться. Адреса устройств с 64 по 126 и со 128 по 254 зарезервированы для использования в будущем. Адрес 255 (‘1111 1111’B) должен быть широковещательным адресом, который прослушивают все узлы. Анонимный узел должен отвечать на адрес 127 ('01111111'B) по обоим своим каналам. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 73 – Дополнительный канал узла должен отвечать на «анонимный» адрес. Адрес «узла» является адресом именованного подчиненного или управляющего устройства. 5.2 5.2.1 Кадры и телеграммы Формат Frame_Data (Данные_кадра) Формат Frame_Data (Данные_кадра) должен соответствовать формату HDLC, определенному в ISO/IEC 13239, как показано на Рисунке 37. Данные_кадра a Данные_HDLC (16 ) Преамбула 32..1056aбит (+ вставленные биты) 8 Флаг DD 1 6 FCS-16 8 (2) Флаг ED время Рисунок 37 - Структура кадра HDLC Кадр должен начинаться с одного флага, состоящего из одного бита «0», за которым следуют шесть смежных битов «1» и закрывается одним битом «0», как указано в ISO/IEC 13239. За открывающим флагом должны следовать данные HDLC, состоящие не менее чем из 32 битов и не более чем из 1056 битов (не считая вставленных битов, предусмотренных ISO/IEC 13239). Данные HDLC должны иметь (в качестве ограничения ISO/IEC 13239) целое число октетов. Первым октетом данных HDLC должно быть 8-битное устройство-адресат, указанное в п. 5.1. Второй октет данных HDLC не должен быть интерпретирован как поле управления ISO/IEC 13239. За данными HDLC должен следовать код обнаружения ошибок, который должен представлять собой 16-битную контрольную последовательность кадров (FCS), построенную в соответствии с требованиями ISO/IEC 13239. Кадр должен закрываться одним закрывающим флагом, идентичным открывающему флагу. Закрывающий флаг не может использоваться в качестве открывающего флага для следующего кадра. Передатчик не должен передавать последовательности «ожидание» или «отмена» согласно ISO/IEC 13239. Кадр рассматривается как последовательность октетов. Младший бит каждого октета должен передаваться первым, как указано в ISO/IEC 13239. ПРИМЕЧАНИЕ 1 Соглашение о порядке следования битов является уникальным для порядка передачи битов в пределах октета. Два октета контрольной последовательность кадров (FCS) отправляются со старшим битом первыми в результате исключения, указанного в ISO/IEC 13239. ПРИМЕЧЕНИЕ 2 Вставка битов HDLC предотвращает появление последовательностей флагов в данных между флагами: передатчик вставляет «0» после каждой группы из 5 последовательных «1» в данных. Приемник удаляет «0», который следует за группой из пяти «1». Вставленные биты невидимы для канального уровня, но они могут увеличить размер кадра на целых 20 %. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 74 – Синхронизация телеграммы 5.2.2 Соглашения 5.2.2.1 Сегмент шины должен контролироваться одним узлом, называемым управляющим, который может осуществлять передачу по шине в своем собственном темпе. Остальные узлы являются подчиненными и могут передавать данные только по запросу управляющего узла. Конечный узел считается управляющим узлом дополнительного канала. Управляющая и подчиненная функции внутри узла различаются. Трафик шины должен состоять из парных кадров, называемых телеграммой, включающей главный кадр, отправленный управляющим устройством, в ответ на который подчиненное устройство в течение определенного времени отправляет подчиненный кадр. Межкадровый интервал должен измеряться от последнего перехода конечного ограничителя до среднего перехода начального бита преамбулы. ПРИМЕР Синхронизация телеграммы показана на Рисунке 38. t_mm интервал главного кадра Главный кадр (запрос) Преамбула Подчиненный кадр (ответ) E D Данные_кад ра Преамбула t_m =длительность главного кадра t_ms подчиненного кадра Данные_кадр а следующ ий опрос E D t_s = длительной интервал между главным и подчиненным кадром t_sm Преамбул а вре мя интервал между подчиненным и главным кадром Рисунок 38 - Синхронизация телеграммы 5.2.2.2 Расчет задержки ответа Задержка ответа T_reply для данной шины представляет собой максимальную задержку, которая может появиться между концом главного кадра и началом подчиненного кадра, отправленного в ответ на него, измеренную на управляющем устройстве. Задержка ответа состоит из суммы задержек прохождения сигнала, задержки декодирования и задержки доступа. T_reply является параметром конфигурации, который сообщает управляющему устройству, как долго оно должно ждать перед отправкой следующего главного кадра, если подчиненный кадр не был получен. ПРИМЕР Композиция с 17 узлами (16 секций), при условии, что управляющий узел находится на одном конце шины, показана на Рисунке 39. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 75 – наиболее удаленный источник данных управляющее устройст во шины t_m задержка прохождения (6 мкс/км) задержка декодирования и доступа t_ms < T_reply t_pd t_source t_mm t_s t_sm > T_sm_min время время Рисунок 39 – Пример межкадрового интервала Задержка ответа в наихудшем случае для данного применения, T_reply, рассчитывается следующим образом: T_reply [ с] = 2 × T_pd + T_source_max T_source_max учитывает декодирование главного кадра и ответ источника (см. п. 5.2.2.4.2); T_pd представляет собой наихудший случай задержки прохождения кадра между конечными узлами для данного применения (см. п. 4.2.3). Тайм-аут для кадра рассчитывается следующим образом: Время передачи бита биты данных приложения заголовок циклическая проверка избыточности общее количество бит положительное выравнивание (наихудший случай × 1,2) 2 × флаг конечный ограничитель максимальный размер преамбулы Общее количество бит длительность при 1,0 Мбит/с 2 × задержка прохождения время отверта подчиненного узла Всего Основной канал Дополнительный канал 1 024 бита 32 бита 16 бит 1 072 бита 16 бит 32 бита 16 бит 64 бита 1 286 бит 77 бит 16 бит 2 бита 32 бита 127 бит 16 бит 2 бита 32 бита 1 286 бит 1 336,0 мкс 120,0 мкс 300,0 мкс 1 756,0 мкс 127,0 мкс 120,0 мкс 800,0 мкс 1 047,0 мкс Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 76 – 61375-2-1 © IEC:2012 Коллизия 5.2.2.3 Коллизия возникает, когда одновременно активно несколько передатчиков. Подобная ситуация обычно возникает только между конечными узлами разных сегментов шины, осуществляющими одновременную передачу. Коллизии не отличаются от радиомолчания или недопустимых кадров. Интервал между передаваемыми кадрами 5.2.2.4 Сторона управляющего устройства 5.2.2.4.1 На основном канале управляющее устройство должно ожидать получения подчиненного кадра полностью в ответ на свой главный кадр в течение тайм-аута T_main_max = 1756 мс с момента завершения переданного им главного кадра, и может начать передачу следующего главного кадра T_sm_min = 0,064 мс после завершения полученного подчиненного кадра или по истечении тайм-аута (1,756 мс + 0,064 мс = 1,820 мс), как показано на Рисунке 40: На дополнительном канале конечный узел должно ожидать получения подчиненного кадра полностью в ответ на свой главный кадр в течение тайм-аута T_aux_max = 1,047 мс с момента завершения переданного им главного кадра, и может начать передачу следующего главного кадра T_sm_min = 0,064 мс после завершения полученного ответа на обнаружение или по истечении тайм-аута (1,047 мс + 0,064 мс = 1,111 мс). t_sm > T_ms_min (= 64,0 мкс) t_ms+t_s T_main_max = 1,756 мс Преамбула кадра отправле нный Данные E D Преамбула полученный подчиненный кадр Управл устройство кадр T_slave_min t_ Данные кадра t_s T_s_max = 1,336 ms T_slave_max + 2 × T_pd E D Преамбула кадра Е следующ ий кадр Данные D управляющее устройство вре мя Рисунок 40 - Интервал между кадрами, измеренный на стороне управляющего устройства Сторона подчиненного устройства 5.2.2.4.2 Подчиненное устройство с адресацией должно начать передачу своего кадра, как показано на Рисунке 41: не ранее, чем через T_source_min = 64,0 мкс после получения конца главного кадра; и не позднее, чем через T_source_max = 0,300 мс после получения конца главного кадра, за исключением ответа на обнаружение, для которого это время увеличивается до 0,600 мс во время открытия эксплуатации и до 0,800 мс во время плановой эксплуатации. ответ подчиненного устройства в течение T_slave_min < t_slave < T_slave_max > 64 с Преамбула Данные_кадра полученный главный кадр < 300с (600 с, 800 с) Преамбула Данные_кадра отправленный подчиненный кадр Преамбула Данные_кадр а следующий главный кадр время Рисунок 41 - Интервал между кадрами на стороне подчиненного устройства 5.2.3 Элементы кадра HDLC Данные HDLC включают в себя данные, находящиеся между начальным флагом и контрольной последовательностью, за исключением вставленных битов, как показано на Рисунке 42: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 77 – Данные_кадра Данные_HDLC данные_канала (16..32) 8 8 Преамбула Флаг DD 8 8 8 LC SD SZ 16 8 (2) FCS-16 Флаг E D 0..1024 бит время устройство_адресат управление_каналом устройство_источник размер_данных_кана ла (вставленные биты не учитываются) Рисунок 42 - Формат данных HDLC Данные HDLC должны состоять из следующих полей, показанных на Рисунке 43: HDLC_Data::= RECORD { destination_device UNSIGNED8 link_control source_device Link_Control UNSIGNED8 link_data_size UNSIGNED8 link_data Link_Data -- 8-битный адрес узла адресата или «широковещательный» адрес; в ответном кадре является по умолчанию адресом «управляющего устройства». -- Управление 8-битным каналом -- 8-битный адрес узла источника, который посылает кадр; в кадре запроса является по умолчанию адресом «управляющего устройства». -- 8-битный размер данных канала, который следует за полем размера, выраженный целым числом октетов; должен быть равен нулю, если поле данных канала пусто; -- МАССИВ [link_data_size] (размер_данных_канала) из WORD8 (8-битного слова). между 0 и 1 024 битами данных; см. п. 5.3.1. } 0 1 2 3 4 5 6 7 destination_device (устройство-адресат) (DD) link_control (управление_каналом) (LC) source_device (устройство_источник) (SD) link_data_size (размер_данных_канала) (SZ) link_data (данные_канала) между 0 и 1 024 битами ПРИМЕЧАНИЕ Обозначения DD, LC, SD, SZ используются на рисунках для экономии места. Рисунок 43 - Формат данных HDLC 5.2.4 Поле Link Control (Управление каналом) Поле управления каналом различает: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 78 – a) Запросы (главные кадры) b) Ответы (подчиненные кадры). Поле Link Control (Управление каналом) различает три типа телеграмм: c) Телеграммы данных процесса (Process Data), используемые для обновления распределенной базы данных процесса; d) Телеграммы данных сообщения (Message Data), используемые для передачи сообщения; e) Телеграммы контрольных данных (Supervisory Data), используемые для контроля и открытия эксплуатации шины. Поле Link Control (Управление каналом) позволяет опрашиваемым узлам сигнализировать о спорадических желаниях передачи, изменениях статуса или условиях открытия эксплуатации с посредством четырех битов: f) «A_bit»: (бит Attention (Внимание)) требуется передача данных сообщения; g) «C_bit»: (бит Change (Изменение)) изменение состояния узла; h) «I_bit»: (бит Inhibit (Запрет)) открытие эксплуатации запрещено; i) «RI_bit»: (бит Remote Inhibit (удаленный запрет)) удаленное открытие эксплуатации запрещено. Поле Link Control (Управление каналом) должно быть закодировано в 8 бит, как указано в Таблице 8. Таблица 8 - Кодирование поля Link Control (Управление каналом) Кодирование Тип кадра 7 6 5 4 3 2 1 0 Process_Data_Request/Proces s_Data_Response M 0 A С I 0 0 0 Message_Data_Request/Mess age_Data_Response M 0 A С 0 1 1 1 Detect_Request/ Detect_Response M 1 0 0 0 0 0 0 Status_Request/ Status_Response M 1 0 RI 0 0 0 1 SetInt_Request/ SetInt_Response M 1 0 0 0 0 1 0 SetEnd_Request/ Контрольные SetEnd_Response данные (Supervisory Data) Unname_Request M 1 0 0 0 0 1 1 M 1 0 0 0 1 0 0 Naming_Request/ Naming_Response M 1 0 0 0 1 0 1 Topography_Request/ Topography_Response M 1 0 0 0 1 1 0 Presence_Request/ Presence_Response M 1 0 RI I 1 1 1 Данные процесса (Process Data) и Данные сообщения (Message Data) Комбинации битов, не указанные в Таблице 8, зарезервированы и должны быть проигнорированы. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 79 – Тип управления каналом в текстовой форме может быть представлен следующим образом: Link_Control::= RECORD { mq { SR MQ } ENUM1 (0), (1) sup { PM SP }, ONE_OF [sup] [PM] { a_bit -- самый старший бит -- «0» в ответе подчиненного устройства -- «1» в ответе управляющего устройства ENUM1 (0), (1) -- данные процесса или сообщение -- контрольные данные RECORD BOOLEAN1, c_bit BOOLEAN1, i_bit BOOLEAN1, pom { PROCESS_DATA ENUM3 (0), MESSAGE_DATA (7) } }, [SP] -- «1», если A_bit задан в Process_Data_Response (Ответ по_данным_процесса) или Message_Data_Response (Ответ по_данным_сообщения) -- «1», если C_bit задан в Process_Data_Response (Ответ по_данным_процесса) или Message_Data_Response (Ответ по_данным_сообщения) -- «1», если I_bit задан в Process_Data_Request (Запрос_данных_процесса) или Message_Data_Response (Ответ по_данным_сообщения) -- Process_Data_Request (Запрос_данных_процесса) или Process_Data_Response (Ответ по_данным_процесса) -- UMessage_Data_Request (Запрос_данных_сообщения) или Message_Data_Response (Ответ по_данным_сообщения) RECORD -- Supervisory_Data_Request (Запрос_контрольных_данных) или Supervisory_Data_Response (Ответ по_контрольным данным) { res0 rem_inh WORD1 (0), BOOLEAN1 i_bit BOOLEAN1, supervisory_type { ENUM3 -- резервный, = 0 -- «1», если RI_bit задан в Status_Response (Ответ о_состоянии) и Presence_Response (Ответ о_присутствии) -- «1», если I_bit задан в Presence_Request (Запрос о_присуствии) и Presence_Response (Ответ о_присутствии) -- различает контрольные данные DETECT (0), STATUS SETINT SETEND UNNAME NAMING (1), (2), (3), (4), (5), TOPOGRAPHY (6), PRESENCE (7) -- Detect_Request/Detect_Response (Запрос на_обнаружение/Ответ на_обнаружение) -- Status_Request/Status_Response (Запрос_состояния/Ответ о_состоянии) -- SetInt_Request/SetInt_Response (Запрос_SetInt /Ответ_SetInt) -- SetEnd_Request/SetEnd_Response (Запрос_SetEnd/Ответ_SetEnd) -- Unname_Request (Запрос_на удаление имени) -- Naming_Request/Naming_Response (Запрос_о наименовании/Ответ_о наименовании) -- Topography_Request (Запрос_топографии) или Topography_Response (Ответ по_топографии) -- Presence_Request (Запрос о_присутствии) или Presence_Response (Ответ о_присутствии) } } } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 80 – 5.2.5 61375-2-1 IEC:2012 Обслуживание битов «Attention» («Внимание»), «Change» («Изменение») и «Inhibit» («Запрет») Типы Process_Data_Responses (Ответ по_данным_процесса) и Message_Data_Responses (Ответ по_данным_сообщения) должны задавать следующие биты в «1» для оповещения об асинхронных событиях. a) A_bit (Attention (Внимание)) должен быть установлен до тех пор, пока очередь отправки данных сообщения содержит кадры для передачи; b) C_bit (Change (Изменение)) должен быть установлен для оповещения об изменении состояния узла, и сбрасываться, когда узел получает запрос о состоянии; c) I_bit (Inhibit (Запрет)) должен быть установлен следующим образом для запрета открытия эксплуатации: пока приложение на узле запрещает открытие эксплуатации, узел должен установить бит I_bit во всех данных процесса и контрольных данных (типы Message_Data_Response не должны устанавливать этот бит); Управляющее устройство должно скопировать комбинацию OR (ИЛИ) бита I_bit в ответе по данным процесса (Process Data Response), полученном от каждого названного им узла, в бит I_bit всех запросов о присутствии (Presence_Requests), которые были им получены; Конечный узел должен скопировать I_bit, полученный в запросе о присутствии (Presence_Request ) в бит I_bit своих запросов на обнаружение (Detect Requests) и ответов на обнаружение (Detect Responses) и в бит I_bit своих ответов о присутствии (Presence_Responses); d) RI_bit должен быть установлен следующим образом для запрета открытия эксплуатации: 5.2.6 конечный узел должен вставить бит I_bit, который он считывает из ответа на обнаружение (Detect Response) удаленного состава, в бит RI_bit своих ответов о присутствии (Presence_Responses) и ответов о состоянии (Status Responses). Ошибки размера, контрольной последовательность кадров (FCS) и протокола Следующее относится только к кадрам, которые были получены через собственный адрес или через широковещательный адрес: приемник должен игнорировать кадр и оценивать линию, по которой был принят проигнорированный кадр, как поврежденную линию: a) если его контрольная последовательность кадра ошибочна; b) если его длина не соответствует длине, указанной в поле «link_data_size» («размер_данных_линии»); c) если тип подчиненного кадра (данные процесса, данные сообщения, контрольные данные) отличается от типа предшествующего ему главного кадра. Дополнительный канал должен проигнорировать кадр и сообщать об ошибке протокола, если он не относится к: Запросу на обнаружение, ответу на обнаружение или запросу о наименовании. Основной канал должен проигнорировать кадр, если он является запросом на обнаружение (Detect Request) или ответом на обнаружение (Detect Response). Управляющее устройство должно проигнорировать второй подчиненный кадр, поступающий в ответ на главный кадр (коллизия без поверждения). 5.3 5.3.1 Форматы телеграмм и протоколы Поле Link Data (Данные канала) Управление канальным уровнем различает данные процесса (Process Data), данные сообщений (Message Data) и контрольные данные (Supervisory Data). Чтобы учесть ограничения адресации, определение данных HDLC включает заголовок канала: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 81 – HDLC_Data::= RECORD { ONE_OF [link_control.sup] -(управления_каналом) { PM] ONE_OF [link_control.pom] -{ [PROCESS_DATA] ONE_OF [link_control.mq] -{ [MQ] Process_Data_Request, [SR] Process_Data_Response } [MESSAGE_DATA] ONE_OF [link_control.mq] -{ [MQ] Message_Data_Request, [SR] Message_Data_Response } }, [SP] Supervisory Data } } зависит от link_control Данные процесса или данные сообщения Запрос или ответ Запрос или ответ Первые четыре октета данных канала формируют заголовок канала и имеют одинаковый формат и значение во всех кадрах. Данные процесса 5.3.2 5.3.2.1 Действие Управляющее устройство должно запросить передачу данных процесса от другого узла (или от себя) или (дополнительно) отправить данные процесса одному узлу, отправив запрос данных процесса (Process Data Request), на который соответствующий узел должен предоставить ответ по данным процесса (Process Data Response), разослав его на все остальные узлы. Телеграмма данных процесса состоит из запроса данных процесса, за которым следует ответ по данным процесса, как показано на Рисунке 44. Ответ_по данным_процесса (широковещательная передача подчиненого_кадра) Запрос_данных_процесса (Главный_кадр) адрес подчине нного устройст ва DD LC адрес до 1024 бит управля (дополнительных) ющего данных_процесса устройст ва SD SZ =01 NT NV широковеща тельный адрес адрес источни ка DD LC SD =FF до 1024 бит данных_процесса SZ NT NV время Рисунок 44 - Телеграмма данных процесса Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 82 – 5.3.2.2 Запрос данных процесса (Process Data Request) Запрос данных процесса должен иметь следующий формат, как показано на Рисунке 45: Process_Data_Request::= RECORD { destination_device UNSIGNED8 -- адрес узла или адрес «управляющего устройства» для самоопроса link_control Link_Control -- Запрос данных процесса source_device UNSIGNED8 -- адрес «управляющего устройства» link_data_size UNSIGNED8 -- = 0 или (размер_данных_линии) ARRAY [link_data_size] OF WORD8 } 7 6 5 -- Данные процесса (дополнительно) -- содержимое определяется применением 4 3 2 1 0 destination_device (устройство-адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) ARRAY [link_data_size] (МАССИВ [размер_данных_канала]) из WORD8 (8-битного слова). Рисунок 45 - Формат запроса данных процесса (Process Data Request) 5.3.2.3 Ответ по данным процесса (Process Data Response) Ответ по данным процесса должен иметь следующий формат, как показано на Рисунке 46: Process_Data_Response::= RECORD { destination_device UNSIGNED8 -- устройство_адресат = широковещательная -- ответ по данным передача link_control Link_Control процесса source_device UNSIGNED8 -- адрес ущла или «управляющего устройства» link_data_size UNSIGNED8 -- (0 link_data_size (размер_данных_канала) 128) ARRAY [link_data_size] OF WORD8 -- содержимое определяется применением; рекомендуется, чтобы два первых октета являлись «Node_Key» («Ключом_узла»), и чтобы приложение проверяло, соответствуют ли они ключу того узла, который он получил в топографии. } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 83 – 7 6 5 4 3 2 1 0 destination_device (устройство-адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) ARRAY [link_data_size] (МАССИВ [размер_данных_канала]) из WORD8 Рисунок 46 - Формат ответа по данным процесса (Process Data Response) 5.3.3 Данные сообщения Действие 5.3.3.1 Управляющее устройство должно направить другому узлу (или себе) запрос на передачу данных сообщения с помощью запроса данных сообщения (Message_Data_Request), на который соответствующий узел должен предоставить ответ по данным сообщения (Message_Data_Response), адресованный одному узлу или посредством широковещательной рассылки, как показано на Рисунке 47. Запрос_данных_сообщения (Главный_кадр) адрес подчиненного устройства Ответ по_данным_сообщения (одноадресная или многоадресная передача подчиненного_кадра) источник (управляю щее устройство) DD LC SD =01 адрес адрес адресата подчиненно го устройства SZ DD LC SD 0..1024 бит данных_сообщения SZ время Рисунок 47 - Телеграмма данных сообщения ПРИМЕЧАНИЕ Структура данных сообщения представлена в разделе 6. 5.3.3.2 Запрос данных сообщения (Message Data Request) Запрос данных сообщения должен иметь следующий формат, как показано на Рисунке 48: Message_Data_Request::= RECORD { destination_device UNSIGNED8 -- адрес узла или адрес «управляющего устройства» для самоопроса -- Запрос данных -- адрес «управляющего UNSIGNED8 -- = 0 или -- пустое поле link_control (= MESSAGE_DATA) сообщения source_device UNSIGNED8 устройства» link_data_size } 7 6 5 4 3 2 1 0 destination_device (устройствоадресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) Рисунок 48 - Формат запроса данных сообщения (Message Data Request) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 84 – 61375-2-1 © IEC:2012 Ответ по данным сообщения (Message Data Response) 5.3.3.3 Ответ по данным сообщения должен иметь следующий формат, как показано на Рисунке 49: Message_Data_Response::= RECORD { destination_device UNSIGNED8 -- адрес узла или широковещательный адрес -- Ответ по данным сообщения -- адрес узла link_data_size -- (0 link_data_size link_control source_device Link_Control UNSIGNED8 UNSIGNED8 (размер_данных_канала) 128) ARRAY [link_data_size] OF WORD8 -- содержимое данных сообщения определено в Разделе 6 } 7 6 5 4 3 2 1 0 destination_device (устройствоадресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) ARRAY [link_data_size] (МАССИВ [размер_данных_канала]) из WORD8 Рисунок 49 - Формат ответа по данным сообщения (Message Data Response) Контрольные данные (Supervisory Data) 5.3.4 5.3.4.1 Действие Управляющее устройство должно запросить контрольные данные от узла или должно отправить контрольные данные узлу с помощью запроса контрольных данных (Supervisory Data Request), на который соответствующий источник должен предоставить ответ по контрольным данным (Supervisory Data Response), как показано на Рисунке 50. подчиненный, анонимный Запрос_контрольных_данн ых (Главный_кадр) или управляющ широковещательн ее или ый анонимное устройство DD LC SD SZ 0..1024 бит контрольных_данных Ответ по_контрольным_данным (Подчиненный_кадр) управляющее устройство, широковещат ельный или анонимный адрес подчине нного устройст ва 0..1024 бит контрольных_данных DD LC SD SZ время Рисунок 50 - Телеграмма контрольных данных В дополнительном канале конечный узел может исполнять роль управляющего устройства. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 5.3.4.2 – 85 – Форматы телеграмм контрольных данных Контрольные кадры должны иметь следующий формат: Supervisory_Data::= ONE_OF [link_control.mq] { [MQ] Supervisory_Data_Request, [SR] Supervisory_Data_Response } Supervisory_Data_Request::= ONE_OF [link_control.supervisory_type] { [DETECT] Detect_Request, [PRESENCE] Presence_Request, [STATUS] Status_Request, [NAMING] Naming_Request, [SETINT] SetInt_Request, [SETEND] SetEnd_Request, [TOPOGRAPHY] Topography_Request, [UNNAME] Unname_Request, } Supervisory_Data_Response::= ONE_OF [link_control.supervisory_type] { [DETECT] Detect_Response, [PRESENCE] Presence_Response, [STATUS] Status_Response, [NAMING] Naming_Response, [SETINT] SetInt_Response, [SETEND] SetEnd_Response, [TOPOGRAPHY] Topography_Response } 5.3.5 5.3.5.1 Телеграмма обнаружения Действие Конечный узел должен оповестить о своем существовании другой узел через запрос на обнаружение (Detect Request), на который другой узел (если он существует и может ответить) должен предоставить ответ на обнаружение (Detect Response). Телеграмма обнаружения показана на Рисунке 51. Запрос на обнаружение (Вспомогательный канал) Запрос на обнаружение Количество узлов Управляющее устройство большой логической силы настаивание = 1 В запросе на обнаружение Рисунок 51 - Телеграмма обнаружения Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 86 – 5.3.5.2 Запрос на обнаружение (Detect_Request) Запрос на обнаружение должен иметь следующий формат, как показано на Рисунке 52: Detect_Request::= RECORD { destination_device UNSIGNED8 link_control Link_Control обнаружение source_device «анонимный» адрес link_data_size master_report Master_Report local_strength Composition_Strength (местная мощность) -- «анонимный» адрес -- Запрос на UNSIGNED8 -UNSIGNED8 -- =2 -- см. 5.5.2.5 -- копия LocStr запрашивающего узла ( 5.5.2.4) -- «ins» установлено на «1». } 7 6 5 4 3 2 1 0 destination_device (устройствоадресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) master_report (отчет_управляющего устройства) mas nns ins Рисунок 52 - Формат запроса на обнаружение (Detect Request) 5.3.5.3 Ответ на обнаружение (Detect Response) Ответ на обнаружение должен иметь следующий формат, как показано на Рисунке 53: Detect_Response::= RECORD { destination_device адрес link_control source_device link_data_size master_report (Detect_Request) remote_strength отвечающего узла UNSIGNED8 Link_Control UNSIGNED8 UNSIGNED8 Master_Report, ------ «широковещательный» Ответ на обнаружение «анонимный» адрес =2 тоже что и в запросе на обнаружение (Для другого состава) -- удаленная мощность (RemStr) Composition_Strength Для удаленного узла установлено «ins», если настаивается на этом составе ( 5.5.2.4) } 7 6 5 4 3 2 1 0 destination_device (устройство-адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) master_report (отчет_управляющего устройства) mas nns ins Рисунок 53 - Формат ответа на обнаружение (Detect Response) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 5.3.6 5.3.6.1 – 87 – Телеграмма присутствия Действие Управляющее устройство должно запросить у конечного узла оповещение о своем присутствии и возможном присутствии другого состава посредством запроса о присутствии (Presence Request), на который конечный узел должен предоставить ответ о присутствии (Presence Response), как показано на Рисунке 54. Запрос о присутствии Запрос о присутствии Количество именованных узлов Рисунок 54 - Телеграмма присутствия 5.3.6.2 Запрос о присутствии (Presence Request) Запрос о присутствии должен иметь следующий формат, как показано на Рисунке 55: Presence_Request::= RECORD { destination_device UNSIGNED8 link_control Link_Control (Presence_Reques)t source_device «управляющего устройства» link_data_size master_report Master_Report local_strength Composition_Strength управляющего устройства, reserved1 master_topo } «ins» равен «0». -- резервный, =0 -- см. 5.5.2.7 WORD4 (=0) Master_Topo 7 6 5 -- адрес конечного узла -- зжапрос о присутствии UNSIGNED8 -- адрес UNSIGNED8 -- = 4 -- см. 5.5.2.5 -- копия LocStr (местная мощность) 4 3 2 1 0 destination_device (устройство-адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) master_report (отчет_управляющего устройства) mas nns ins reserved1 (резерв1) master_topo (топографический счетчик_управляющего устройства) Рисунок 55 - Формат запроса о присутствии (Presence Request) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 88 – 61375-2-1 © IEC:2012 Ответ о присутствии (Presence Response) 5.3.6.3 Ответ о присутствии должен иметь следующий формат, как показано на Рисунке 56: Presence_Response::= RECORD { destination_device UNSIGNED8 адрес link_control Link_Control (Presence_Response) source_device конечного узла link_data_size node_report Node_Report Composition_Strength мощность) конечного узла -- «широковещательный» -- Ответ о присутствии UNSIGNED8 -- адрес UNSIGNED8 -- =2 -- см. 5.5.2.2 remote_strength -- копия RemStr (удаленная «ins» = «1» указывает на то, что настаивается на другом составе. } 7 6 5 4 3 2 1 0 destination_device (устройство-адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) node_report (отчет_узла) mas nns ins Рисунок 56 - Формат ответа о присутствии (Presence Request) Телеграмма состояния 5.3.7 Действие 5.3.7.1 Управляющее устройство должно запросить о состоянии узла с помощью запроса о состоянии (Status Request), на который подчиненное устройство должно предоставить ответ о состоянии (Status Response), как показано на Рисунке 57. Запрос_состояния DD LC SD SZ Ответ о_состоянии MR LS DD LC SD SZ NR RS RS 7 6 5 4 3 2 1 0 0 nns = число именованных узлов local_strength (местная_мощность) '01'H или 'FF'H управляющее устройство с большой логической силой = 1 node_report (отчет_узла) res UR NF NP NT NV node_descriptor (дескриптор узла) user_report (отчет_пользователя) remote _strength (удаленная_мощность) Рисунок 57 - Телеграмма состояния 5.3.7.2 Запрос о состоянии (Status Request) Запрос о состоянии должен иметь следующий формат, как показано на Рисунке 58: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 89 – Status_Request::= RECORD { destination_device UNSIGNED8 -Link_Control -source_device UNSIGNED8 -link_data_size UNSIGNED8 -master_report Master_Report -local_strength Composition_Strength управляющего устройства, «ins» адрес узла link_control Запрос о состоянии (Status_Request) адерс «управляющего устройства» = 2 см. 5.5.2.5 -- LocStr (локальная мощность) равен 0 } 7 6 5 4 3 2 1 0 destination_device (устройствоадресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) mas master_report (отчет_управляющего устройства) nns ins Рисунок 58 - Формат запроса о состоянии (Status Request) 5.3.7.3 Ответ о состоянии (Status Response) Ответ о состоянии должен иметь следующий формат, как показано на Рисунке 59: Status_Response::= RECORD { destination_device UNSIGNED8 -«широковещательный» адрес link_control Link_Control -source_device UNSIGNED8 -link_data_size UNSIGNED8 -node_report Node_Report -Composition_Strength в конечном узле, 0 в промежуточном узле. reserved1 WORD8 (=0) -=0 user_report User_Report -node_descriptor Node_Descriptor -} адрес «управляющего устройства» или Ответ о состоянии (Status_Response) адрес узла = 8 см. 5.5.2.2 remote_strength -- мощность удаленного состава резервный, см. 5.5.2.3 см. 5.5.2.1 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 90 – 7 6 5 4 3 2 1 0 destination_device (устройство-адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) node_report (отчет_узла) mas nns ins reserved1 (резерв1) user_report (отчет_пользователя) node_frame_size (размер_кадра_узла) reserved1 (резерв1) node_period (период_узла) node_type (тип_узла) node_version (версия_узла) Рисунок 59 - Формат ответа о состоянии (Status Response) 5.3.8 5.3.8.1 Телеграмма установки промежуточного положения Действие Управляющее устройство должно запросить подчиненное устройство об установке его переключателей в промежуточное положение, отправив запрос на установку промежуточного положения (SetInt Request), который подчиненное устройство должно подтвердить ответом об установке промежуточного положения (SetInt Response), как показано на Рисунке 60. Запрос_SetInt DD LC SD =01 Ответ_SetInt SZ =0 DD =01 LC SD SZ =0 Рисунок 60 - Телеграмма установки промежуточного положения 5.3.8.2 Запрос на установку промежуточного положения (SetInt Request) Запрос на установку промежуточного положения должен иметь следующий формат, как показано на Рисунке 61: SetInt_Request::= RECORD { destination_device link_control UNSIGNED8 Link_Control source_device UNSIGNED8 link_data_size } UNSIGNED8 7 6 5 -- адрес узла -- Запрос на установку промежуточного положения (SetInt_Request) -- адрес «управляющего устройства» -- =0 4 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) Рисунок 61 - Формат запроса на установку промежуточного положения (SetInt Request) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 5.3.8.3 – 91 – Ответ об установке промежуточного положения (SetInt Response) Ответ об установке промежуточного положения должен иметь следующий формат, как показано на Рисунке 62: SetInt_Response::= RECORD { destination_device UNSIGNED8 link_control Link_Control source_device link_data_size } UNSIGNED8 UNSIGNED8 7 6 5 4 -- адрес «управляющего устройства» -- Ответ об установке промежуточного положения (SetInt_Response ) -- адрес узла -- =0 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_ данных_канала) Рисунок 62 - Формат ответа об установке промежуточного положения (SetInt Response) Телеграмма о наименовании 5.3.9 5.3.9.1 Действие Управляющее устройство должно сообщить свой выделенный адрес и мощность подчиненному устройству посредством запроса о наименовании (Naming Request), которое подчиненное устройство должно подтвердить с помощью ответа о наименовании (Naming Response), как показано на Рисунке 63. Запрос о наименовании Запрос о наименовании 7F’H (анонимный) или адрес узла 7F’H (анонимный) или адрес узла Собственный адрес Собственная мощность Собственный адрес в порядке убывания = 1 nns = количество именованнх узлов Управляющее устройство с большой логической силой = 1 Рисунок 63 - Телеграмма о наименовании Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 92 – 5.3.9.2 Запрос о наименовании (Naming Request) Запрос о наименовании должен иметь следующий формат, как показано на Рисунке 64: Naming_Request::= RECORD { destination_device UNSIGNED8 link_control (Naming_Request) source_device link_data_size ir1 Link_Control rsv1 WORD1 UNSIGNED6 -- адрес узла или «анонимный» адрес -- Запрос о наименовании UNSIGNED8 UNSIGNED8 BOOLEAN1 -- адрес «управляющего устройства» -- = 2 -- «1» если наименование в порядке возрастания -- резерв, =0 your_address -- по назначению управляющего устройства your_strength Composition_Strength управляющего устройства -- по назначению «ins» = 0 } 7 6 5 4 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_ данных_канала) dir1 rsv1 your_address (ваш_адрес) nns mas ins Рисунок 64 - Формат запроса о наименовании (Naming Request) 5.3.9.3 Ответ о наименовании (Naming Response) Ответ о наименовании должен иметь следующий формат, как показано на Рисунке 65: Naming_Response::= RECORD { destination_device UNSIGNED8 link_control Link_Control source_device UNSIGNED8 link_data_size UNSIGNED8 -- адрес «управляющего устройства» или «анонимный» адрес -- Запрос о наименовании (Naming_Request) -- адрес «узла» или «анонимный» адрес (5.3.9) -- =0 } 7 6 5 4 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_ канала) Рисунок 65 - Формат ответа о наименовании (Naming Response) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.3.10 5.3.10.1 – 93 – Телеграмма об удалении имени Действие Управляющее устройство должно запросить все подчиненные устройства об удалении имени путем широковещательной рассылки запроса на удаление имени (Unname Request), на которую подчиненные устройства не должны отвечать, как показано на Рисунке 66 (ответ об удалении имени (Unname Response) отсутствует). Запрос_на удаление имени DD =FF LC SD =01 SZ Рисунок 66 - Телеграмма об удалении имени 5.3.10.2 Запрос на удаление имени (Unname Request) Запрос на удаление имени должен иметь следующий формат, как показано на Рисунке 67: Unname_Request::= RECORD { destination_device UNSIGNED8 link_control Link_Control source_device UNSIGNED8 link_data_size } UNSIGNED8 7 6 5 -- «широковещательный» адрес -- Unname_Request (Запрос_на удаление имени) -- адрес «управляющего устройства» -- =0 4 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) Рисунок 67 - Формат запроса на удаление имени (Unname Request) 5.3.11 5.3.11.1 Телеграмма установкиконечной настройки Действие Управляющее устройство должно запросить подчиненное устройство о переключении на конечную настройку и принятии новой мощности состава посредством запроса конечной настройки (SetEnd Request), на который подчиненное устройство должно предоставить ответ о конечной настройке (SetEnd Response), как показано на Рисунке 68. Запрос_конечной настройки DD LC SD SZ =01 res =0 LS Ответ о_конечной настройке DD LC =01 SD SZ Рисунок 68 - Телеграмма установки конечной настройки Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 94 – 5.3.11.2 Запрос конечной настройки (SetEnd Request) Запрос конечной настройки должен иметь следующий формат, как показано на Рисунке 69: SetEnd_Request::= RECORD { destination_device UNSIGNED8 -Link_Control -(SetEnd_Request) source_device UNSIGNED8 -link_data_size UNSIGNED8 -reserved1 WORD8 (=0) -local_strength Composition_Strength устройством адрес узла link_control Запрос конечной настройки адрес «управляющего устройства» = 2 = 0 -- LocStr как указано управляющим (5.5.2.4) } 7 6 5 4 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) reserved1 (резерв1) mas nns ins Рисунок 69 - Формат запроса конечной настройки (SetEnd Request) 5.3.11.3 Ответ о конечной настройке (SetEnd Response) Ответ о конечной настройке должен иметь следующий формат, как показано на Рисунке 70: SetEnd_Response::= RECORD { destination_device UNSIGNED8 link_control Link_Control source_device link_data_size } UNSIGNED8 UNSIGNED8 7 6 5 4 -- адрес «управляющего устройства» -- Ответ о конечной настройке (SetEnd_Response ) -- адрес узла -- = 0 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) Рисунок 70 - Формат ответа о конечной настройке (SetEnd Response) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 5.3.12 5.3.12.1 – 95 – Телеграмма топографии Действие Управляющее устройство должно сообщить свою топографию подчиненному устройству посредством запроса топографии (Topography Request), которое подчиненное устройство должно подтвердить с помощью ответа о топографии (Topography Response), как показано на Рисунке 71. Запрос_топографии DD LC SD =1 SZ Ответ о_топографии BN LS YP MT DD LC SD SZ NT NV NA IS данные_открытия эксплуатации (IS x 8 бит) (дополнительно) BN = нижний_узел LS = местная_мощность YP = собственный_период MT = топография_управляющего устройства Рисунок 71 - Телеграмма топографии 5.3.12.2 Запрос топографии (Topography Request) Запрос топографии должен иметь следующий формат, как показано на Рисунке 72: Topography_Request::= RECORD { destination_device UNSIGNED8 управляющее устройство) link_control (Topography_Request) source_device «управляющего устройства» link_data_size bottom_node UNSIGNED8 -- адрес узла (может быть Link_Control -- Запрос топографии UNSIGNED8 -- адрес UNSIGNED8 -- = 4 -- адрес конечного узла в направлении_1 от управляющего Composition_Strength -- устройства local_strength мощность состава как указано your_period период UNSIGNED4 управляющим устройством (local_strength.ins = 0). -- назначенный индивидуальный master_topo Master_Topo (5.5.2.1 и 5.4.2) -- см. 5.5.2.7 } 7 6 5 4 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) bottom_node (нижний_узел) mas nns ins your_period (ваш_период) master_topo (топографический счетчик_управляющего устройства) Рисунок 72 - Формат запроса топографии (Topography Request) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 96 – 5.3.12.3 Ответ о топографии (Topography Response) Ответ о топографии должен иметь следующий формат, как показано на Рисунке 73: Topography_Response::= RECORD { destination_device UNSIGNED8 link_control Link_Control (Topography_Response) source_device UNSIGNED8 быть управляющее устройство) link_data_size UNSIGNED8 128 node_type Node_Type (Node_Key) node_version Node_Version (Node_Key) sam BOOLEAN1 направлении с управляющим устройством rsv1 WORD1 node_address UNSIGNED6 при inaug_data_size -- «широковещательный» адрес -- Ответ о топографии -- адрес узла источника (может -- 0 «размер_данный_канала» -- первая часть ключа узла -- вторая часть ключа узла -- «1» если в одном -- reserved, =0 -- адрес узла, полученный открытии эксплуатации -- 0 UNSIGNED8 124 октета) ARRAY [inaug_data_size] OF WORD8 определяемые приложением данные открытия эксплуатации inauguration_data } 7 6 5 4 3 2 1 0 destination_device (устройство_адресат) link_control (управление_каналом) source_device (устройство_источник) link_data_size (размер_данных_канала) node_type (тип_узла) node_version (версия_узла) sam rsv1 node_address (адрес_узла) Inaug_data_size (размер_данных_открытия эксплуатации) ARRAY [inaug_data_size] (МАССИВ [размер_данных_открытия эксплуатации]) из WORD8 (8-битное слово) Рисунок 73 - Формат ответа о топографии (Topography Response) ПРИМЕЧАНИЕ Избыточность «inaug_data_size» (размер_данных_открытия эксплуатации) с «link_data_size» (размер_данных_канала) является преднамеренной и используется для проверки правдоподобия. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 97 – Распределение среды передачи данных 5.4 Организация 5.4.1 Следующие спецификации относятся к плановой эксплуатации, когда установлено только одно управляющее устройство, и шина может передавать данные приложений. Плановая эксплуатация начинается после завершения открытия эксплуатации и прекращается, когда происходит изменение состава. ПРИМЕЧАНИЕ Выбор управляющего узла из нескольких узлов определен в п. 5.5. Выбор управляющего узла не является частью распределения среды передачи данных, представленного здесь. 5.4.1.1 5.4.1.1.1 Основной период Структура основного периода Управляющее устройство должно разделить работу шины на фиксированные периоды, называемые «основными периодами». Основной период должен быть разделен на две фазы, как показано на Рисунке 74: a) Периодическая фаза, используемая для передачи периодических данных, и b) Спорадическая фаза, используемая для передачи: Контрольных данных; и/или Данных сообщения. Основной_период (T_bp) периодическая фаза опрос по данным процесса 1 2 3 4 Основной_период T_bp спорадическая фаза контро льная фаза 5 6 7 SD фаза сообще ния MD MD периодическая фаза опрос по данным процесса 8 MD 1 2 спорадическая фаза контро льная фаза 9 SD фаза сообще ния MD t 12 время Рисунок 74 - Структура основного периода 5.4.1.1.2 Длительность основного периода Длительность основного периода должна составлять T_bp = 25,0 мс ± 1,0 мс. Управляющее устройство не может выдавать запрос данных сообщения или запрос контрольных данных после начала основного периода, пока не завершена периодическая фаза. ПРИМЕЧАНИЕ Это означает, что начало периодической фазы может быть задержано на время t, необходимое для передачи кадра данных сообщения или контрольных данных, включая опрос, максимально возможной длительности, которая составляет около 2,0 мс. Ожидается, что следующий основной период начнется в запланированное время при отсутствии других спорадических данных. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 98 – 5.4.2 5.4.2.1 61375-2-1 IEC:2012 Периодическая фаза Отдельный период (Individual Period) Интервал между двумя последующими опросами одного и того же узла называется отдельным периодом, T_ip. Индивидуальный период должен быть кратен основному периоду T_bp, таким образом T_ip = (2n T_bp). ПРИМЕЧАНИЕ Отдельный период определяется применением каждого узла. Каждый узел оповещает о желаемом отдельном периоде (node_period (период_узла)) и размере подчиненного кадра (node_frame_size (размер_кадра_узла)) в своем дескрипторе узла (см. 5.5.2.1) во время открытия эксплуатации. Самый длинный отдельный период любого узла на шине определяет макропериод. 5.4.2.2 Периодический список Периодический список представляет собой список всех узлов, которые опрашиваются в течение каждого основного периода макропериода. Он также определяет время, оставшееся до спорадической фазы в каждом основном периоде. Управляющее устройство должно сконфигурировать периодический список на основании отдельного периода, запрашиваемого каждым узлом (node_period), и размера данных процесса (node_frame_size), полученных от каждого узла во время открытия эксплуатации. Управляющее устройство должно равномерно распределить опросы по основным периодам, чтобы оставить 40 % каждого основного периода для спорадической фазы. Если периодическая фаза занимает более 60 % основного периода, отдельные периоды узлов с самым длинным периодом должны удваиваться до тех пор, пока периодическая фаза не займет менее 60 % основного периода, усредненного по макропериоду. Если этого действия недостаточно, то период узлов со вторым по длине периодом узла должен быть удвоен, и так далее, пока не будет удвоен период узлов с самым коротким периодом, если это необходимо. Отдельный период, выбранный для каждого узла, должен быть сообщен в запросе топографии каждому узлу как собственный период (your_period). 5.4.2.3 Опрос конечных узлов Управляющее устройство должно опрашивать один конечный узел в течение основного периода и другой конечный узел в течение следующего периода, отправляя кадр запроса о присутствии (Presence Reques), на который конечный узел должен отправить ответ о присутствии (Presence Response) посредством широковещательной передачи. ПРИМЕЧАНИЕ Телеграмма присутствия позволяет всем узлам контролировать целостность шины, а управляющему устройству обнаруживать присутствие другого состава. 5.4.2.4 Условия возникновения ошибок и обработка Управляющее устройство не должно удалять из своего периодического списка узел, который перестает отвечать, а должно продолжать опрашивать его до следующего открытия эксплуатации или до тех пор, пока узел повторно не интегрируется с шиной. ПРИМЕЧАНИЕ 1 эксплуатации. Отказавшие узлы могут быть удалены из состава только посредством нового открытия Узел должен иметь возможность оповестить свое приложение об исчезновении узла, на получение данных процесса которого он подписан, который перестал отвечать на три последовательных опроса, и сигнализировать о его повторной интеграции в случае его восстановления. ПРИМЕЧАНИЕ 2 Контроль времени приемника для получения данных процесса обеспечивает контроль отсутствующих узлов. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 99 – Поведение узла в ходе плановой эксплуатации, который перестает отслеживать ожидаемый трафик (например, отсутствие конечных узлов, отсутствие управляющего узла, отсутствие опроса), должно соответствовать указанному в 5.5.4.9.3. 5.4.3 5.4.3.1 Спорадическая фаза Извещение о событии Узел должен запрашивать спорадическую передачу, устанавливая «A_bit» или «C_bit» в своем ответе по данным процесса (Process_Data_Response) или в ответе по данным сообщения (Message Data Response). Если несколько узлов извещают о спорадической передаче во время периодической фазы, управляющее устройство должно обрабатывать эти запросы циклически таким образом, чтобы все остальные запросы обрабатывались до того, как тот же самый узел будет снова введен в эксплуатацию. Все запросы контрольных данных (C_bit) должны обрабатываться до того, как будут обработаны запросы данных сообщения (A_bit). 5.4.3.2 Список сообщений Управляющее устройство должно вставить в свой список сообщений адреса узлов, которые установили бит A_bit в одном из предыдущих кадров данных процесса или данных сообщения. Управляющее устройство должно опросить узел, который оповещает об изменении посредством запроса данных сообщения, и удалить узел из списка сообщений, когда он опрашивает узел на наличие данных сообщения, за исключением случаев, когда в ответе по данным сообщения также установлен бит A_bit. 5.4.3.3 Контрольный список Управляющее устройство должно вставить в свой контрольный список адреса узлов, которые установили бит C_bit в одном из предыдущих кадров данных процесса или данных сообщения. Управляющее устройство должно опросить узел, который оповещает об изменении с помощью запроса о состоянии, и удалить его адрес из контрольного списка после получения ответа о состоянии. ПРИМЕЧАНИЕ Данный список обычно пуст. Он содержит адрес конечного узла в случае удлинения шины и адреса узлов, которые изменяют свой дескриптор или объявляют об изменении запроса на спящий режим (переходят в спящий режим или отменяют спящий режим). 5.4.3.4 Фоновая проверка (дополнительно) Управляющее устройство может опрашивать узлы данных сообщения или состояния, которые не включены в его список сообщений или контрольный список. ПРИМЕЧАНИЕ Узел, который не отправляет данные процесса, но может отправлять данные сообщения, опрашивается в ходе фоновой проверки. Открытие эксплуатации 5.5 5.5.1 5.5.1.1 Общие положения Распределение адресов Процедура открытия эксплуатации должна присвоить каждому узлу адрес, как показано на Рисунке 75: узлы в направлении_1 от управляющего устройства последовательно нумеруются в порядке убывания, начиная с 63, причем последний именованный узел является нижним узлом; узлы в направлении_2 от управляющего устройства последовательно нумеруются в порядке возрастания, начиная с 02, причем последний именованный узел является верхним узлом; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 100 – 61375-2-1 © IEC:2012 S убывание нижний 2 управляющий возрастание 1 1 1 2 2 P 1 1 2 B 1 01 2 1 1 2 B A 63 1 21 вер хн 2 B 62 2 02 03 1 21 A 04 1 ий 2 2 A 05 06 07 Рисунок 75 Нумерация положения узлов 5.5.1.2 Ранжирование узлов Приложение может реализовывать различные стратегии назначения управляющего устройства, классифицируя узел как узел с большой логической силой, узел с малой логической силой или подчиненный узел. 5.5.1.3 Узел с большой логической силой Приложение помогает узлу с большой логической силой стать управляющим устройством. Узел с большой логической силой, принимающий статус управляющего устройства, называется управляющим устройством с большой логической силой. Узел с большой логической силой может быть понижен приложением до узла с малой логической силой. Если узел являлся устройством с большой логической силой, он сообщит о своем понижении всем узлам и останется управлять шиной в качестве управляющего устройства с малой логической силой до тех пор, пока не будет назначен узел с большой логической силой. ПРИМЕЧАНИЕ 1 Как правило приложение продвигает только один узел в составе в качестве узла с большой логической силой. Если шина включает более одного узла с большой логической силой, то процедура открытия эксплуатации приведет к фрагментации шины на столько независимых сегментов, сколько существует узлов с большой логической силой, поскольку на сегмент может быть только одно управляющее устройство. ПРИМЕЧАНИЕ 2 Узел с большой логической силой позволяет привязать статус управляющего устройства к определенным функциям приложения, например, к ведущему транспортному средству. Такая привязка требуется для включения данных процесса в кадры запроса данных процесса (Process_Data_Request) (5.3.1). 5.5.1.3.1 Узел с малой логической силой Узел с малой логической силой представляет собой узел, которому приложение может позволить стать управляющим устройством. Узел с малой логической силой, принимающий статус управляющего устройства, называется управляющим устройством с малой логической силой. Как правило приложение назначает несколько или все узлы в составе узлами с малой логической силой. В составе, в котором отсутствует узел с большой логической силой, разрешение конфликтов, которое одинаково относится ко всем узлам, гарантирует, что один и только один из узлов с малой логической силой станет управляющим устройством с малой логической силой, а все остальные узлы станут подчиненными. Если управляющее устройство с малой логической силой обнаружит наличие узла с большой логической силой или другого управляющего устройства с малой логической силой, контролирующего большое количество подчиненных устройств, оно будет понижено в статусе и станет подчиненным устройством для другого управляющего устройства. Узел с малой логической силой, повышенный приложением до узла с большой логической силой, становится управляющим устройством с большой логической силой и запускает шину, если он еще не является управляющим устройством. ПРИМЕНЧАНИЕ Узлам с малой логической силой разрешается управлять шиной без явной команды приложения. Узлы с малой логической силой могут преодолеть сбой управляющего устройства путем открытия эксплуатации и назначения другого узла (с малой логической силой) в качестве управляющего устройства. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.1.3.2 – 101 – Подчиненный узел Подчиненный узел представляет собой узел, которому приложение не может позволить стать управляющим устройством в любой момент времени. ПРИМЕЧАНИЕ Поэтому подчиненные узлы не могут участвовать в восстановлении. Этот режим полезен для при проведении испытания или в сочетании с узлами с большой логической силой. 5.5.2 Дескрипторы Следующие структуры данных используются в кадрах контрольных данных и в сообщениях управления шиной, для чего они определены в нотации передачи. Для интерфейса канального уровня соответствующие типы данных С указаны в 5.6.4. 5.5.2.1 Дескриптор узла Каждый узел должен реализовать дескриптор узла для идентификации его характеристик. Дескриптор узла должен быть представлен следующей структурой данных, как показано на Рисунке 76: Node_Descriptor::= RECORD { node_frame_size UNSIGNED8, ответа по данным процесса reserved1 node_period -- «link_data_size» (размер_данных_канала) WORD5 (=0) UNSIGNED3 --- node_type UNSIGNED8 (Node_Key) node_version UNSIGNED8 (Node_Key). } 7 6 5 --- 4 3 (Process_Data_Response) этого узла резерв, =0 запрос отдельного периода узлом, выраженного как кратное 2n основному периоду T_bp, n = (1 .. 128): 0: 1 T_bp (25,0 мс) 1: 2 T_bp (50,0 мс) 2: 4 T_bp (100,0 мс) 3: 8 T_bp (200,0 мс) 4: 16 T_bp (400,0 мс) 5: 32 T_bp (800,0 мс) 6: 64 T_bp (1,6 с) 7: 128 T_bp (3,2 с) первая часть ключа узла вторая часть ключа узла 2 1 0 node_frame_size (размер_кадра_узла) reserved1 (резерв1) node_period (период_узла) node_type (тип_узла) node_version (версия_узла) Рисунок 76 - Формат дескриптора узла ПРИМЕЧАНИЕ 1 Дескрипторы узлов согласовываются между изготовителями и пользователями для конкретного применения. ПРИМЕЧАНИЕ 2 Дескриптор узла используется в ответах о наименовании, ответах о состоянии и ответах о топографии, а также в качестве внутренней переменной. ПРИМЕЧАНИЕ 3 Дескриптор узла UIC для международных вагонов указан в стандарте UIC 556. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 102 – ПРИМЕЧАНИЕ 4 Приложение может вставлять ключ узла в качестве первых двух байтов каждого кадра данных процесса для обеспечения большей защиты от фальсификации (5.6.2.2). 5.5.2.2 Отчет узла Каждый узел должен формировать отчет узла для сообщения о повреждении на линии и изменениях в составе. Отчет узла должен быть представлен следующей структурой данных, как показано на Рисунке 77: Node_Report::= { da1 BITSET8 (0) da2 (1) dB1 (2) dB2 (3) int (4) dsc (5) slp (6) sam (7) -- Повреждение на линии_A1, копии 4.7.2.4 -- Повреждение на линии_A2, копии 4.7.2.4 -- Повреждение на линии_В1, копии 4.7.2.4 -- Повреждение на линии_В2, копии 4.7.2.4 -- устанавливается, если узел в промежуточной настройке, сбрасывается, если в конечной настройке. -- устанавливается, если дескриптор узла был изменен, сбрасывается, если узел получает новую топографию. -- устанавливается, если узел переходит в режим низкого энергопотребления, сбрасывается, если запрос на спящий режим отменен. -- устанавливается, если узел имеет ту же самую ориентацию, что и управляющее устройство сбрасывается, если узел в противоположном направлении. DA1 DA2 dB1 dB2 } 7 6 5 4 3 2 1 0 da1 da2 db1 db2 int dsc slp sam Рисунок 77 - Формат отчета узла 5.5.2.3 Отчет пользователя Каждый узел должен формировать отчет пользователя для передачи характерного для данного приложения октета другим приложениям, например, для сообщения о повреждении, характерных для данного приложения. Отчет пользователя должен быть представлен одним октетом, как показано на Рисунке 78: User_Report::= WORD8 -- характерное для приложения 7 6 5 4 3 2 1 0 ur7 ur6 ur5 ur4 ur3 ur2 ur1 ur0 Рисунок 78 - Формат отчета пользователя ПРИЛОЖЕНИЕ Приложение может устанавливать отдельные биты отчета пользователя через службы канального уровня. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.2.4 – 103 – Мощность состава Каждый узел должен реализовать переменную мощность местного состава (LocStr), чтобы указать, сколько узлов присутствует в составе и используется ли управляющее устройство с большой или малой логической силой. Каждый узел должен реализовать переменную мощности уделенного состава RemStr (1) и RemStr (2) для каждого дополнительного канала, чтобы указать мощность удаленного состава, которую была им обнаружена в направлени_1 или направлении_2. ПРИМЕЧАНИЕ Эти переменные используются только тогда, когда соответствующий канал активен. Для промежуточного узла они не требуются. Мощность состава должна быть представлен следующей структурой, как показано на Рисунке 79: Composition_Strength::= RECORD { mas BOOLEAN1, nns UNSIGNED6, ins BOOLEAN1, -- устанавливается, если для данного состава используется управляющее устройство с большой логической силой Сбрасывается, если используется устройство с малой логической силой. -- количество именованных узлов в составе -- устанавливается, если состав настаивает на конфликте, сбрасывается, если состав уступает } 7 6 5 mas 4 3 2 1 nns 0 ins Рисунок 79 - Формат мощности состава Чтобы упростить сравнение мощности, местная или удаленная мощность состава должна рассчитываться как беззнаковый октет со значением: RemStr или LocStr = (mas 128) + 2 nns + ins; ПРИМЕРЫ RemStr = 0 больше узлов не обнаружено; RemStr = 1 обнаружен анонимный узел; RemStr = 2 согласие на единственное управляющее устройство с малой логической силой; RemStr = 3 настаивание на единственном управляющем устройстве с малой логической силой; RemStr = 4 согласие на управляющее устройство с малой логической силой с одним узлом; RemStr = 13 настаивание на управляющем устройстве с малой логической силой с шестью узлами; RemStr > 128 состав, именованный управляющим устройством с большой логической силой. 5.5.2.5 Отчет управляющего устройства Каждый узел должен реализовать отчет управляющего устройства (Master_Report)с целью сообщения о нарушениях резервирования и идентификации направления помех. Отчет управляющего устройства должен быть представлен следующей структурой, как показано на Рисунке 80: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 104 – Master_Report::= { rsv1 (=0) rsv2 (=0) rsv3 (=0) rsv4 (=0) inh BITSET8 ------ резерв, установлено на 0 резерв, установлено на 0 резерв, установлено на 0 резерв, установлено на 0 устанавливается, если узел данного состава запрещает открытие эксплуатации -- устанавливается, если данный кадр c12 посылается в направлении_2 относительно данного узла -- устанавливается, в случае повреждения на dmb линии_B основного канала (копии dB1 или dB2 бит) -- устанавливается, в случае повреждения на dma линии_А основного канала (копии DA1 или DA2 бит) } 7 6 5 4 3 2 1 0 rsv1 rsv2 rsv3 rsv4 inh c12 dmb dma Рисунок 80 -Отчет управляющего устройства 5.5.2.6 Топографический счетчик Каждый узел должен реализовать топографический счетчик, который представляет собой счетчик по модулю 64, увеличивающийся на 1 или 2 для каждой последующей топографии, полученной узлом. Данный счетчик не должен принимать значение 0, а должен переходить непосредственно от 63 к 1. Топографический счетчик должен быть представлен следующей структурой, как показано на Рисунке 81: Topo_Counter::= -- 0 = не используется UNSIGNED6 7 6 x x 5 4 3 2 1 0 topo_counter (топографический_счетчик) Рисунок 81 - Формат топографического счетчика ПРИМЕЧАНИЕ 1 Топографический счетчик используется протоколами реального времени для обеспечения согласованности сообщений, передаваемыми по шине поезда, в процессе открытия эксплуатации. После временного отключения питания узел должен обеспечить изменение топографического счетчика по сравнению со значением до отключения питания. ПРИМЕЧАНИЕ 2 Топографический счетчик может храниться в энергонезависимой памяти (поскольку он используется для быстрого восстановления). После восстановления питания узел может получить доступ к прежнему топографическому счетчику и внести в него изменения. После переключения на резерв новый активный узел должен обеспечить изменение топографического счетчика по сравнению со значением ранее активного узла. ПРИМЕЧАНИЕ 3 Один узел может использовать топографический счетчик с четным номером, а другой узел может использовать топографический счетчик с нечетным номером. Топографический счетчик увеличивается на 2 для каждой последующей топографии, полученной узлом. Этот метод гарантирует, что топографический счетчик останется четным и нечетным соответственно. В случае переключения на резерв счетчик топографической съемки меняется с четного на нечетный или наоборот. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.2.7 – 105 – Топографический счетчик управляющего устройства Каждый узел должен реализовать топографический счетчик управляющего устройства (Master Topo), который представляет собой счетчик по модулю 64, увеличивающийся на 1 или 2 для каждой последующей топографии, полученной управляющим устройством. Топографический счетчик управляющего устройства должен быть представлен следующей структурой, как показано на Рисунке 82: Master_Topo::= 11 UNSIGNED12 10 9 8 7 6 5 4 3 2 1 0 master_topo (топографический счетчик_управляющего устройства) Рисунок 82 - Формат топографического счетчика управляющего устройства Когда узел становится управляющим в первый раз, 12-битный топографический счетчик управляющего устройства должен быть инициализирован случайным образом. Управляющее устройство должно увеличивать топографический счетчик управляющего устройства на единицу каждый раз при распространении топографии. ПРИМЕЧАНИЕ Этот счетчик позволяет временно отключенным узлам проверить, способны ли они повторно интегрировать правильный состав. 5.5.2.8 Счетчик открытия эксплуатации Каждый узел должен реализовать 16-битный счетчик открытия эксплуатации (Inauguration_Counter) для регистрации того, сколько раз он прошел процедуру открытия эксплуатации, проходя через состояние анонимного узла. ПРИМЕЧАНИЕ Данный счетчик используется для диагностики. 5.5.3 5.5.3.1 Обнаружение других составов (для справки) Протокол обнаружения Конечные узлы: обнаруживают присутствие дополнительного узла, подключенного к их открытому концу (-ам); и сообщают о своем присутствии этому дополнительному узлу. С этой целью конечный узел отправляет запрос на обнаружение, содержащий переменную мощности местного состава (LocStr), по направлению своего открытого конца (или открытых концов в случае одиночного управляющего устройства). Этот запрос на обнаружение путем установки своего бита «insist» («настаивать») первоначально указывает, что на этот состав будет настоятельно рекомендоваться в случае конфликта. Во всех случаях конечный узел (именованный или анонимный) отвечает на полученный запрос на обнаружение ответом на обнаружение (или другим запросом на обнаружение) в пределах интервала времени между кадрами (5.2.2.4). Получающий конечный узел сравнивает мощность удаленного состава (RemStr) со своей собственной мощностью (LocStr): если другой состав слабее собственного, узел оставляет установленным бит «insist» («настаивать»); если другой состав сильнее или аналогичен собственному, узел сбрасывает бит «insist» («настаивать») и уступает; если оба состава именованы управляющим устройством с большой логической силой, бит бит «insist» («настаивать») остается установленным. Узел, который получает запрос о присутствии, принимает мощность, указанную в ответе о присутствии. Конечный узел сообщает в каждом последующем ответе о присутствии: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 106 – 61375-2-1 IEC:2012 a) о присутствии другого узла; b) о мощности удаленного состава; c) о местном решении уступить или настаивать в случае одинаковой мощности. 5.5.3.2 Правила предотвращения коллизий Поскольку конечные узлы двух отдельных составов отправляют запрос на обнаружение асинхронно, узел может получить искаженный кадр или другой запрос на обнаружение, когда он ожидает ответа на обнаружение. Следующие пять правил уменьшают конфликт: a) Конечный узел, еще не задействованный в плановой эксплуатации, должен отправить запрос на обнаружение по своему дополнительному каналу не позднее, чем через 400,0 с после получения запроса о наименовании или запроса о состоянии по своему основному каналу; b) Конечный узел, задействованный в плановой эксплуатации, должен отправить запрос на обнаружение по своему дополнительному каналу не позднее, чем через 400,0 с после получения запроса о присутствии по своему основному каналу, для предотвращения повторных коллизий с вероятностью 50 %; c) единственное управляющее устройство должно отправлять запрос на обнаружение по обоим своим дополнительным каналам не реже одного раза каждые 29,0 мс, но не чаще одного раза каждые 21,0 мс с произвольной отправкой в диапазоне 25,0 мс 4,0 мс для предотвращения повторных коллизий; d) конечный узел после отправки запроса на обнаружение должен игнорировать кадры, которые не являются ни ответом на обнаружение, ни запросом на обнаружение, полученные в течение периода T_detecting_response = 1047 мс, и должен игнорировать кадры, которые не являются ни запросом на обнаружение, ни запросами на имя, полученными после этого периода; e) управляющее устройство не должно вызывать отправку запроса на обнаружение со скоростью, которая выше скорости срабатывания конечного узла. Это обеспечивается протоколом запроса о состоянии, запроса о присутствии и запроса о именовании. ПРИМЕЧАНИЕ 1 Управляющее устройство, которое одновременно является конечным узлом, отправляет запрос о присутствии самому себе. ПРИМЕЧАНИЕ 1 Управляющее устройство, которое одновременно является конечным узлом, отправляет запрос о состоянии самому себе. ПРИМЕР На Рисунке 83 представлена диаграмма синхронизации типового процесса обнаружения. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 107 – Управляющее устройство < 1756 с Конечный узел Запрос о присутствии Ответ о присутствии Конечный узел < 300 с < 400 с нет ответа в течение 1047 с Управляющее устройство конечные узлы еще не подключены Запрос на обнаружение (отправлен с вероятностью 50%) конечные узлы подключены Запрос о присутствии < 1756 с Ответ о присутствии < 300 с < 400 с прием ответа на обнаружение или запроса на обнаружение в течение 1047 с Запрос на обнаружение (отправлен с вероятностью 50%) < 800 с Ответ на обнаружение (всегда отправляется) Запрос о присутствии < 300 с Ответ о присутствии < 400 с < 800 с Запрос о присутствии Ответ о присутствии Запрос на обнаружение (отправлен с вероятностью 50%) прием ответа на обнаружение или запроса на обнаружение в течение 1047 с Ответ на обнаружение (всегда отправляется) < 300 с < 400 с прием ответа на обнаружение или запроса на обнаружение в течение 1047 с Запрос на обнаружение (отправлен с вероятностью 50%) Запрос об удалении имени Запрос об удалении имени Рисунок 83 - Диаграмма синхронизации протокола обнаружения Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 108 – 5.5.4 5.5.4.1 61375-2-1 © IEC:2012 Диаграммы состояния для открытия эксплуатации Структура узла Узел должен находиться в одном из основных состояний, показанных на Рисунке 84. Эти основные состояния подразделяются на второстепенные состояния, которые определяются в следующих подразделах. Линия_A1 Линия_A2 кадры шины Линия_B2 Линия_B1 Узел отключен Узел в спящем режиме Узел в активном состоянии состояние аппаратного обеспечения Собственное включение ПУСК Управление узлом АНОНИМНОЕ_ПО ДЧИНЕННОЕ УСТРОЙСТВО ИМЕНУЮЩЕЕ_УП РАВЛЯЮЩЕЕ УСТРОЙСТВО ОБУЧАЮЩЕЕ УПРАВЛЯЮЩЕЕ ОБУЧАЕМОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО УПРАВЛЯЮЩЕЕ УСТРОЙСТВО_ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ Собственное состояние УСТРОЙСТВО состояние ПО ПОДЧИНЕННОЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ Рисунок 84 - Основные состояния узлов и настройки приложения Узел может находиться в режиме сна с низким энергопотреблением для экономии энергии. Поскольку в спящем режиме узел не полностью включен, некоторые состояния и их переходы должны быть реализованы в аппаратном обеспечении блока доступа к среде передачи данных. Они считаются состояниями аппаратного обеспечения, а переменные управления и состояния обозначаются элементами аппаратного обеспечения. Остальные состояния считаются состояниями программного обеспечения. 5.5.4.2 Структура процесса открытия эксплуатации По существу и для целей данной спецификации действие узла разделено на три процесса, как показано на Рисунке 85: Основной процесс, который активен на всех именованных узлах. На именованном подчиненном устройстве этот процесс привязан к указанию управляющего устройства. На управляющем устройстве этот процесс привязан к первому подчиненному устройству, указанному управляющим устройством; два идентичных вспомогательных процесса, каждый из которых связан с одним направлением. Они действуют только в конечных узлах в направлении открытого конца шины. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 109 – Линия_A1 Линия_A Направление_2 2 Направление_1 Линия_B1 Линия_B 2 канал 2 канал 1 ВЫКЛ ВЫКЛ Вспомогательный_ процесс 1 Основной_ процесс Обнаружен(1) общие переменные Собственная ориентация Собственная мощность Собственный адрес Найден(1) Потерян(1) Удаленная мощность(1) Входящий Пропущен(1) Отключение узла Активация узла Пропущен(2) Вспомогательный_ процесс 2 Обнаружен(2) Найден(2) настаивает Потерян(2) Уделенная мощность(2) Направление Выходящий наименования Собственное Статистика узла состояние Обновлен Ошибки Опрос узла TC YP Тип узла LS BN MT данные открытия эксплуатации Версия узла Мощность узла Спящ. режим узла Собствен ная топограф ия Собственная ориентация Собственный адрес Собственная мощность Собственный отчет Собственная статистка Собственная топография Список сообщений Контрольный список Периодический список Собственное состояние Управление узлом Рисунок 85 - Процессы узла (конечная настройка) Для целей данной спецификации предполагается, что основной процесс и вспомогательные процессы являются циклическими процессами, т.е. они запускаются с заранее заданными интервалами (по умолчанию каждый основной период) и самостоятельно останавливаются до окончания интервала. Основной процесс и вспомогательный процесс одного узла выполняются параллельно с процессами других узлов. Процессы контролируют друг друга (и самих себя): a) посредством отправки кадров по шине; b) посредством запуска тайм-аутов; c) посредством общих (опрашиваемых) переменных. Переходы внутри процесса запускаются: d) переменными управления; e) кадрами, полученными по шине; f) истечением тайм-аутов. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 110 – 61375-2-1 IEC:2012 Переходы обусловлены общими (опрашиваемыми) переменными того же или других процессов. Состояние узла отображается через структуру «MyStatus» («Собственное состояние»). 5.5.4.3 Язык спецификации Процедура открытия эксплуатации представлена на языке спецификаций и описания/графического представления [ITU-T Z.100]. Для упрощения диаграмм применяются следующие соглашения: a) в качестве ограничения языка спецификаций и описания: отсутствует очередность событий, т.е. узел в заданном состоянии рассматривает только те события, которые происходят, пока процесс находится в этом состоянии; b) для упрощения диаграмм включены операторы выбора «IF/ELSE». Булевы переменные нейтрально принимают значения YES/NO (ДА/НЕТ) или «1»/«0» или «TRUE»/«FALSE» («ИСТИННО»/ «ЛОЖНО»); c) имена состояний или макросов пишутся прописными буквами. Когда макрос имеет только одно состояние, это состояние имеет то же имя, что и макрос, но существует только одна точка входа в макрос; d) к каждому состоянию может быть привязан таймер, который имеет то же имя, что и состояние (например, T_named_slave для состояния NAMED_SLAVE (ИМЕНОВАННОЕ УСТРОЙСТВО)), и который перезапускается каждый раз при входе в состояние; ПОДЧЕНЕННОЕ e) операция возвращается в состояние, из которого она была запущена, если не указано следующее состояние. 5.5.4.4 5.5.4.4.1 Переменные узла NodeControl (Управление узлом) Управление узлом должно осуществляться структурой данных NodeControl, представленной в Таблице 9. Таблица 9 - Структура данных NodeControl (Управление узлом) Переменная Тип Значен ие NodeAwake BOOLEAN1 (БУЛЕВА1) пробуждает узел из спящего состояния и позволяет ему участвовать (Активация узла) в открытии эксплуатации при условии, что переменные NodeSleep (Узел в спящем режиме) и NodeInhibit (Узел запрещен) отменены. Отключение узла BOOLEAN1 (БУЛЕВА1) переключает узел в пассивное состояние при промежуточной настройке; отменяется силовой цепью; обычно подтверждается при недостаточном питании, например, менее 70 % от номинального значения; этот сигнал также может быть подтвержден, когда в узле обнаруживается невосстановимое повреждение NodeSetUp (Установка узла) RECORD (ЗАПИСЬ) команда, которая сообщает узлу данные его конфигурации, и в особенности: NodeDescriptor (Дескриптор узла) и NodeStrength (Мощность узла) (подчиненный/с малой логической силой/с большой логической силой) NodeInhibit (Узел BOOLEAN1 (БУЛЕВА1) предотвращает открытие эксплуатации узла, за исключением запрещен) восстановления после сбоя NodeSleep (Узел в спящем режиме) BOOLEAN1 (БУЛЕВА1) переводит узел в состояние сна с низким энергопотреблением в режиме конечной настройки, но не предотвращает пробуждение узла при обнаружении им активности. обычно подтверждается, когда шина должна быть отключена, например, когда зарядка аккумулятора прекратилась более чем на 45 минут. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.4.4.2 – 111 – MyStatus (Собственное состояние) Узел должен сделать свое состояние доступным для приложения посредством структуры данных MyStatus (Собственное состояние), указанной в Таблице 10. Таблица 10 - Структура данных MyStatus (Собственное состояние) Переменная Тип Значение MyTopo (Собственная топография) RECORD (ЗАПИСЬ) MyOrient (Собственная ориентация) ANTIVALENT2 (АНТИВАЛЕНТНЫЙ2) MyDir (Собственное направление) MyAdr (Собственный адрес) BOOLEAN1 (БУЛЕВА1) UNSIGNED6 (БЕЗЗНАКОВЫЙ6) как получено по запросу о наименовании (your_address), или «анонимный» адрес для анонимного узла или «основной» адрес для управляющего устройства MyReport (Собственный отчет) MyStrength (Собственная мощность) NodeReport (Отчет узла) Отчет узла в формате, который узел отправляет управляющему устройству в кадре ответа о состоянии (5.3.7) Composition_Strength (Мощность_состава) Местная мощность данного узла, полученная путем запроса о именовании по дополнительному каналу или путем запроса о конечной настройке запроса о состоянии или запроса топографии по основному каналу MySwitchOn (Собственное включение) MyStatistics (Собственная статистка) BOOLEAN1 (БУЛЕВА1) «1», если узел должен быть включен «0», выключение узла при низком энергопотреблении RECORD (ЗАПИСЬ) статистика отправленных и полученных кадров и количество ошибок 5.5.4.4.3 текущая версия топографии, полученная при последнем распределении топографии; данная переменная является копией топографии (которая может быть несовместимой, пока все узлы не получат одинаковые версии) Указывает, располагаются ли точки узла в том же или в противоположном направлении от своего управляющего устройства. ‘00’B: ошибка, ‘01’B: прямое, ‘10’B: противоположное, ‘11’B неопределенное TRUE (ИСТИНА), если узел имеет то же направление, что и управляющее устройство, в соответствии с полученным по запросу о именовании Shared variables (Общие переменные) Основной процесс и вспомогательные процессы обмениваются информацией через общие переменные. Предполагается, что эти переменные опрашиваются соответствующими процессами, т.е. между главным процессом и вспомогательными процессами отсутствуют асинхронные сигналы. Поскольку доступ к переменным может осуществляться одновременно несколькими процессами, переменные могут быть заблокированы и разблокированы с помощью функций LOCK (БЛОКИРОВАТЬ) и UNLOCK (РАЗБЛОКИРОВАТЬ) для их бесперебойного считывания и изменения (например, чтобы избежать одновременного именования анонимного узла в обоих направлениях). Переменные с индексом (1,2) относятся к каждому вспомогательному процессу. Все переменные в структуре данных MyStatus (Собственное состояние) считаются общими переменными. Другие общие переменные представлены в Таблице 11. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 112 – Таблица 11 - Общие переменные в узле Переменная Тип Значение BOOLEAN1 (БУЛЕВА1) «1», если обнаружение происходит в направлении_1 BOOLEAN1 (БУЛЕВА1) Detect (2) (Обнаружен(2)) Found (1) (Найден BOOLEAN1 (БУЛЕВА1) (1)) BOOLEAN1 (БУЛЕВА1) Found(2) (Найден (2)) «0», если обнаружение происходит в направлении_2 Detect (1) (Обнаружен(1)) подтверждено: - вспомогательным процессом, который обнаружил другой узел или - ответом о присутствии со значением RemStr (Удаленная мощность), отличным от 0. отменено: - когда узел именован в этом направлении; - когда узел установлен в промежуточное положение или - когда узел становится анонимным INTEGER8 (ЦЕЛОЕ8) Lost(1) (Потерян(1)) счетчики, обнаруживающие потерю уже обнаруженного, но еще анонимного узла INTEGER8 (ЦЕЛОЕ8) Lost(2) (Потерян(2)) Insist (Настаивает) BOOLEAN1 (БУЛЕВА1) LocStr (Местная мощность) RemStr(1) (Удаленная мощность (1)) RemStr(2) (Удаленная мощность (2)) 5.5.4.4.4 «1», если конечный узел настаивает в обоих направлениях «0», если в любом направлении обнаруживается более сильный состав Composition_Strength мощность состава, к которому принадлежит узел (Мощность_состава) Composition_Strength (Мощность мощность другого состава, либо обнаруженная собственным вспомогательным процессом, либо полученная в поле состава) Composition_Strength remote_strength (удаленная мощность) контрольного кадра (Мощность состава) Переменные основного процесса Переменные, перечисленные в Таблице 12, используются в основном процессе. Другие местные переменные появляются на SDLдиаграммах соответствующих макросов или процедур. Таблица 12 - Переменные основного процесса Переменная Topo (Топография) Тип RECORD (ЗАПИСЬ) Значение Топография, с одним входом на именованный узел TopoCounter (Топографический Topo_Counter счетчик) MasterTopo (Топографический Master_Topo счетчик управляющего устройства) Inward (Входящий) ANTIVALENT2 (АНТИВАЛЕНТНЫЙ2) Outward (Выходящий) ANTIVALENT2 (АНТИВАЛЕНТНЫЙ2) NamingDir (Каталог ANTIVALENT2 наименований) (АНТИВАЛЕНТНЫЙ2) см. 5.5.2.6 Missed(1) (Пропущен(1)) UNSIGNED8 (ЦЕЛОЕ8) Обнаруживает потерю конечного узла в каждом направлении Missed(2) (Пропущен(2)) UNSIGNED8 (ЦЕЛОЕ8) Errors (Ошибки) UNSIGNED8 (ЦЕЛОЕ8) Счетчик ошибок, увеличивающийся при неблагоприятном обнаружении и сбрасываемый при благоприятном исходе того же самого обнаружения, поэтому неявно персонализированный для каждого типа обнаружения C_bit BOOLEAN1 (БУЛЕВА1) пока этот бит установлен, все ответы по данным процесса (Process_Data_Responses) или ответы по данным сообщения (Message Data Responses) будут содержать установленный C_bit см. 5.5.2.7 Направление управляющего устройства (для именованных подчиненных узлов) Направление, противоположное управляющему устройству (для именованных подчиненных узлов) Направление именования (0 = нет, 1 = нижний, 2 = верхний) для управляющего устройства Работа управляющего устройства зависит от списков, указанных в Таблице 13. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Переменная – 113 – Таблица 13 - Список основных процессов Тип Periodic_List [n] (Периодический список [n]) RECORD (ЗАПИСЬ) Message_List (Список сообщений) RECORD (ЗАПИСЬ) Supervisory_List (Контрольный список) RECORD (ЗАПИСЬ) 5.5.4.5 Значение Список адресов, которые должны быть опрошены для данных процесса в течение конкретного основного периода, где n является позицией основного периода в макропериоде Список узлов, которые должны быть опрошены для данных сообщения, расположенных в порядке, в котором были обнаружены запросы на передачу (оповещение битом A_bit) Список узлов, которые должны быть опрошены для контрольных данных, расположенных в порядке, в котором были обнаружены запросы на передачу (оповещение битом C_bit) Auxiliary_Process (Вспомогательный процесс) 5.5.4.5.1 Процесс Как показано на Рисунке 86, вспомогательный процесс (Auxiliary_Process) обнаруживает наличие узлов, не принадлежащих составу. Он выполняется узлами только при конечной настройке. Одиночные узлы имеют два активных вспомогательных процесса (Auxiliary_Processes). Обмен кадрами происходит по вспомогательному каналу. Вспомогательный процесс состоит из двух состояний: состояния DETECTING_RESPONSE (ОТВЕТ НА ОБНАРУЖЕНИЕ), которое запускается только в том случае, если узел именован и не уступает, и состояния DETECTING_REQUESTS (ЗАПРОСЫ НА ОБНАРУЖЕНИЕ), которое запускается до тех пор, пока активен вспомогательный процесс (Auxiliary_Process). 5.5.4.5.2 Состояние «DETECTING_RESPONSE» («ОТВЕТ НА ОБНАРУЖЕНИЕ») Именованный узел, который не уступает, должен отправить запрос на обнаружение и ожидать ответ на обнаружение или запрос на обнаружение в состоянии DETECTING_RESPONSE (ОТВЕТ НА ОБНАРУЖЕНИЕ). В состоянии DETECTING_RESPONSE (ОТВЕТ НА ОБНАРУЖЕНИЕ) узел должен ожидать следующее: a) ответ на обнаружение тайм-аута в течение периода T_detecting_response и перейти к DETECTING_REQUESTS (ЗАПРОСАМ НА ОБНАРУЖЕНИЕ) b) Ответ на обнаружение или запрос на обнаружение: зарегистрировать присутствие и мощность удаленного состава (Found (this_dir)= ‘1’; Lost = 0), сравнить соответствующие силы и, возможно, уступить, если состав имеет большую мощность, «insist» («настаивать») = «0» и и перейти к DETECTING_REQUESTS (ЗАПРОСАМ НА ОБНАРУЖЕНИЕ); c) другой тип: игнорировать и перейти к DETECTING_REQUESTS (ЗАПРОСАМ НА ОБНАРУЖЕНИЕ). ПРИМЕЧАНИЕ 1 Запрос на обнаружение является единственным главным кадром, отправленным подчиненным устройством. ПРИМЕЧАНИЕ 2 Некоторые ситуации могут привести к безусловному отключению узла. 5.5.4.5.3 Состояние «DETECTING_REQUESTS» («ЗАПРОСЫ НА ОБНАРУЖЕНИЕ») Вспомогательный процесс (Auxiliary_Process) в состоянии DETECTING_REQUESTS (ЗАПРОСЫ НА ОБНАРУЖЕНИЕ) должен ожидать: a) обнаружение тайм-аута в течение периода T_detecting: если узел не получил кадра в период обнаружения T_detecting, он должен увеличить счетчик «Lost» («Потерян») в этом направлении и перейти в состояние «DETECTING_RESPONSE» («ОТВЕТ НА ОБНАРУЖЕНИЕ»); Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 114 – 61375-2-1 IEC:2012 если узел не получил кадров в течение последовательных периодов обнаружения MAXLOST, он должен сбросить переменную «Found» («Найден») и установить «RemStr (this_dir)» на ноль и перейти в состояние «DETECTING_RESPONSE» («ОТВЕТ НА ОБНАРУЖЕНИЕ»); b) Запрос на обнаружение: зарегистрировать присутствия другого узла (Found(this_dir)= ‘1’, Lost = 0); сравнить соответствующие мощности и, если запрашивающее устройства мощнее или имеет равную мощность, уступить в случае недостаточной мощности, установив «insist» («настаивать») на «0», и отправить ответ на обнаружение; c) Запрос о наименовании: если узел ранее не получал запрос на обнаружение более мощного состава (‘Found(1)’ , соответственно ‘Found(2)’ =‘0’), он должен объявить линию, по которой был получен этот кадр, как поврежденную линию и доверять другой линии, даже если другая линия уже повреждена; в противном случае узел должен выполнить макрос NAMING_RESPONSE (ЗАПРОС О НАИМЕНОВАНИИ), который в случае успеха завершает вспомогательный процесс (Auxiliary_Process); d) другой типа кадра: объявить линию, по которой был получен этот кадр, как поврежденную и доверять другой линии, даже если другая линия уже повреждена, и перейти к DETECTING_REQUEST (ЗАПРОСУ О НАИМЕНОВАНИИ) без сброса периода T_detecting. ПРИМЕЧАНИЕ 1 Запрос на обнаружение и запрос о именовании представляют собой единственные типы кадров, которые узел ожидает получить по своему дополнительному каналу. Если узел получает запрос о наименовании, не получив ранее запрос на обнаружение, то это будет интерпретировано как ошибка протокола. ПРИМЕЧАНИЕ 2 Поскольку запрос на обнаружение мог быть искажен вследствие коллизии, период T_detecting располагается произвольно вокруг медианного значения, чтобы избежать повторных коллизий. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 115 – AUXILIARY_PROCESS (this_dir) this_dir (1,2) направление данного канала Lost (this_dir):=0; Found(this_dir):=0; нет (MyStr > 2) И Insist И Detect(this_dir)? да Detect_Req (MyStr) DETECTING _RESPONSE T_detecting_response кадр Detect_Resp(RS) Lost(this_dir):= Lost(this_dir)+1 нет Lost(this_dir) > MAXLOST не т или Detect_Req(RS) нет да (MyStr < RS) И (MyStr < 128) да RemStr(this_dir):= 0; Found(this_dir):= 0; Insist := 0 Found(this_dir):= ДА; Lost(this_dir) := 0; RemStr(this_dir):= RS перезапустить T_detecting DETECTING _REQUESTS не перезапускать T_detecting кадр T_detecting Detect_Req(RS) ? Lost(this_dir):= Lost(this_dir)+1 нет нет Lost(this_dir) > MAXLOST да (MyStr Š RS) не т Naming_Req ? не т (YA,YS) И (MyStr < 128) да да RemStr(this_dir):= 0; Found(this_dir):= 0; Insist := 0 Detect_Resp (MyStr) Found(this_dir):= ДА; Lost(this_dir) := 0; RemStr(this_dir):= RS NAMING_RESPONSE отклонить принять к основному процес су Named_By(this_dir) Рисунок 86 - Состояния AUXILIARY_PROCESS (ВСПОМОГАТЕЛЬНОГО ПРОЦЕССА) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 116 – 5.5.4.5.4 Макрос «NAMING_RESPONSE» («ЗАПРОС О НАИМЕНОВАНИИ») Как показано на рисунке 87, макрос «NAMING_RESPONSE» («ЗАПРОС О НАИМЕНОВАНИИ») присваивает адрес узлу: если узел уже именован, он должен игнорировать запрос о наименовании. Эта ситуация должна возникать только в том случае, если узел был именован на другом канале; в случае анонимного узла, узел должен предоставить ответ о наименовании. макрос должен прекратить обнаружение в этом направлении и выделить канал узлу в качестве основного канала. ПРИМЕЧАНИЕ Для проверки того, что узел является анонимным, требуется операция исключающего считывания имени MyAdr, поскольку другой вспомогательный процесс также может получить к нему доступ. NAMING_ RESPONSE LOCK (MyAdr) (Уже именован) MyAdr = UNNAMED ? не т unlock (MyAdr) да MyAdr := YA; MyStr := YS; UNLOCK (MyAdr); Detect(this_dir) := NO; Found(this_dir) := ДА; Inward := this_dir; IF (this_dir = 1) THEN Outward := 2 ELSE Outward := 1 END; IF MyDir = 0 THEN MyOrient := Inward ELSE MyOrient:= Outward END; SA:= MyAdr DA := 01; Naming_Response отклонить Переключить Main_Channel (основной канал) в this_dir (этом принять направлении). Рисунок 87 - макрос NAMING_RESPONSE (ЗАПРОС О НАИМЕНОВАНИИ) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 5.5.4.6 – 117 – Основные состояния основного процесса Как показано на Рисунке 88, основной процесс разделен на основные состояния. Эти состояния подразделяются на несколько состояний, представленных макросом (который появляется только один раз) или процедурой (которая может появляться несколько раз), как представлено в следующих подразделах. питание ЗАПУСК_УЗ ЛА установить_ управляюще е устройство ИМЕНУЮ ЩЕЕ _УПРАВ ЛЯЮЩЕРасформ. переименован Е ное УСТРОЙ обуча СТВО ющее ОБУЧАЮЩЕ Е _УПРАВЛЯ ЮЩЕЕ все_обучены ошибка_ра УСТРОЙС спределен ТВО ия УПРАВЛ ЯЮЩЕЕ УСТРОЙ обучающ СТВО переим ее _ДЛЯ енован ПЛАНОВ спящее ное ОЙ ЭКСПЛУ понижен ное АТАЦИИ установить _спящий режим установить _подчинен ное устройство повышенн ое АНОНИМ НОЕ _ПОДЧИ НЕННОЕспящее УСТРОЙ СТВОименован ное ИМЕН ОВАН НОЕ _ПОДЧ повышен ИНЕНН анонимн ый ОЕ обучаем УСТРО ЙСТВО ОБУЧАЕ МОЕ _ПОДЧИ повышенн НЕННОЕанонимный для плановой УСТРОЙ ое эксплуатации СТВО ПОДЧИН ЕННОЕ УСТРОЙ СТВО без имени обучаем понижен _ДЛЯ повышенное ПЛАНО ВОЙ MASTER_STATES SLAVE_STATES Состояние управляющего устройства Состояние подчиненного ЭКСПЛ устройства (СОСТОЯНИЯ (СОСТОЯНИЯ УАТАЦ УПРАВЛЯЮЩЕ ПОДЧИНЕННО ГО ГО ИИ УСТРОЙСТВА) Рисунок 88 - Состояния ОСНОВНЫХ ПРОЦЕССОВ УСТРОЙСТВА ) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 118 – 61375-2-1 IEC:2012 Состояние START_NODE (ЗАПУСК УЗЛА) представлено в Таблице 14. Таблица 14 - «START_NODE» («ЗАПУСК УЗЛА») «START_NODE» («ЗАПУСК_УЗЛА») Узел переходит в состояние «START_NODE» («ЗАПУСК УЗЛА») после сбоя, сброса или включения питания. Оно запускается либо в обесточенном состоянии, в котором узел пассивен, либо из состояния с низким энергопотреблением, в котором узел ожидает сигнала шины или приложения для восстановления полной мощности. Затем приложение конфигурирует узел с помощью команды NodeSetUp (Установка узла). Если узел имеет конфигурацию узла с большой логической силой, он немедленно переходит в состояние NAMING_MASTER (ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО). узел имеет конфигурацию узла с малой логической силой или Состояния, в которых узел работает вЕсли качестве управляющего устройства, перечислены в Таблице 15. подчиненного узла, то он переходит в состояние UNNAMED_SLAVE Таблица 15 - «MASTER STATES» («СОСТОЯНИЯ УПРАВЛЯЮЩЕГО УСТРОЙСТВА») (АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО) Инициализирует узел в качестве одиночного управляющего устройства. Устанавливает «NAMING_MASTER» или включает узел в конечной настройке с двумя активными каналами обнаружения. («ИМЕНУЮЩЕЕ_УПРАВЛЯЮЩ Запускает отправку кадров обнаружения в обоих направлениях для поиска других ЕЕ УСТРОЙСТВО») узлов. Когда управляющее устройство обнаруживает узел, оно присваивает узлу имя и обновляет списки состояния узла. Когда оно больше не находит именуемых узлов в любом направлении, управляющее устройство закрывает присвоение имен и переходит в состояние «TEACHING_MASTER» («ОБУЧАЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО»). Если управляющее устройство с малой логической силой находит более сильный состав, оно понижается в статусе и возвращается в состояние «UNNAMED_SLAVE» («АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО»). Оно должно предварительно удалить имя узлов, которые были им именованы (расформирование). Если управляющее устройство обнаруживает неисправимую ошибку, оно перезапускает процедуру, возвращаясь к самому себе. «TEACHING_MASTER» («ОБУЧАЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») В этом состоянии нет ограничения по времени, поскольку это может быть допустимой ситуацией (одиночный состав). Обучающее управляющее устройство распределяет топографию, последовательно запрашивая каждый узел с тем, чтобы передать его дескриптор и данные его открытия эксплуатации всем остальным узлам. Если распределение прошло успешно, управляющее устройство переходит в состояние «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ»). Если распределение не удается, управляющее устройство расформировывается и возвращается в состояние «NAMING_MASTER» («ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО»). Управляющее устройство опрашивает узлы в ходе плановой эксплуатации. «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ Управляющее устройство обрабатывает следующие исключительные ситуации: УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») - изменение дескриптора или состояния любого узла; - изменение мощности управляющего устройства. Управляющее устройство выходит из состояния «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») в случае - укорочения шины (конечный узел больше не обнаруживается); - удлинения шины (именование дополнительных узлов) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 119 – Состояния, в которых узел работает в качестве подчиненного (SLAVE) устройства, перечислены в Таблице 16. Таблица 16 - «SLAVE STATES» («СОСТОЯНИЯ ПОДЧИНЕННОГО УСТРОЙСТВА») «UNNAMED_SLAVE» («АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») «NAMED_SLAVE» («ИМЕНОВАННОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») «UNNAMED_SLAVE» («АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») для конечной настройки; с двумя перечисленными вспомогательными процессами (но без передачи). Устройство выходит из этого состояния при получении кадра именования от управляющего устройства или при повышении до узла с большой или малой логической силой посредством приложения Запрос о наименовании заставляет узел переключать свой основной канал на управляющее устройство. Вспомогательный процесс в другом направлении остается активным. Управляющее устройство регулярно отправляет запрос о состоянии, чтобы проверить наличие дополнительных узлов на своем открытом конце. При обнаружении еще одного анонимного узла управляющее устройство переключает узел на промежуточную настройку, которая отключает вспомогательный процесс. Узел выходит из этого состояния при получении запроса топографии или ответа о топографии, которые сигнализируют об окончании фазы присвоения имени. «LEARNING_SLAVE» («ОБУЧАЕМОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») «REGULAR_SLAVE» («ПОДЧИНЕННОЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») Именованное подчиненное устройство получает данные открытия эксплуатации от всех остальных узлов и рассылает свои собственные данные открытия эксплуатации всем остальным узлам. Оно увеличивает счетчик открытия эксплуатации на единицу. Узел выходит из этого состояния при получении запроса о присутствии, посредством которого управляющее устройство сигнализирует о переходе к плановой эксплуатации, или любого кадра, указывающего на плановую эксплуатацию. В этом состоянии узел считается обновленным с полной топографией. Если узел является конечным узлом, его активный вспомогательный процесс проверяет удлинение шины, о чем сообщает управляющему устройству посредством ответа о присутствии Все узлы контролируют присутствие обоих конечных узлов; узел возвращается в состояние «UNNAMED_SLAVE» («АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО»), если он перестает распознавать конечные узлы в течение трех последовательных ответов о присутствии. Если он был обновлен, то узел ожидает регулярного опроса своих данных процесса и получения данных процесса от других узлов. Он возвращается в состояние «LEARNING_SLAVE» («ОБУЧАЕМОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») при получении ответа о топографии или запроса о топографии для себя, посредством которых управляющее устройство оповещает об изменении состава без изменения адреса Во всех состояниях подчиненное устройство может быть повышено до статуса управляющего устройство с большой логической силой и напрямую перейти в состояние «NAMING_MASTER» («ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО»). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 120 – 61375-2-1 © IEC:2012 Макрос «START_NODE» («ЗАПУСК УЗЛА») 5.5.4.7 Как показано на Рисунке 89, этот макрос определяет аппаратно-управляемое и программно-управляемое состояние, через которые проходит узел, прежде чем он станет управляющим или подчиненным устройством. Отключение узла Узел в спящем режиме аппаратно-управляемый ЗАПУСК_УЗ ЛА промежуточная настройка ОТКЛЮЧЕННЫЙ_УЗЕЛ УЗЕЛ В СПЯЩЕМ РЕЖИМЕ Отключение узла активность любой шины Конечная настройка Активация узла включение питания узла НЕСКОНФИГУРИРОВАННЫЙ _УЗЕЛ получение дескриптора узла (от приложения) Установка узла нет да сильный? задать управляющее устройство задать подчиненное устройство Рисунок 89 - Макрос «START_NODE» («ЗАПУСК УЗЛА») 5.5.4.7.1 Состояние «DISCONNECTED_NODE» («ОТКЛЮЧЕННЫЙ УЗЕЛ») Узел должен безусловно войти в это состояние, когда приложение активирует NodeDisc (Отключение узла), сигнализируя о скором отключении питания или серьезном сбое в узле. Это начальное состояние обесточенного узла. Узел в состоянии «DISCONNECTED_NODE» («ОТКЛЮЧЕННЫЙ УЗЕЛ») должен находиться в режиме промежуточной настройки. Узел должен выйти из этого состояния, когда приложение подает питание на узел и сбрасывает сигнал NodeDisc (Отключение узла). Затем он должен перейти в состояние «UNCONFIGURED_NODE» («НЕСКОНФИГУРИРОВАННЫЙ УЗЕЛ») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.4.7.2 – 121 – Состояние «SLEEPING_NODE» («УЗЕЛ В СПЯЩЕМ РЕЖИМЕ») Узел должен войти в это состояние после подтверждения команды NodeSleep (Узел в спящем режиме) и отмене сигнала NodeDisc (Отключение узла). Узел должен находиться в режиме конечной настройки, в состоянии низкого энергопотребления. Узел должен выйти из этого состояния: a) когда приложение подтверждает команду «NodeAwake» («Активация узла») или b) при обнаружении активности шины. Когда узел выходит из спящего режима, он должен подтвердить «MySwitchOn» («Собственное включение»), чтобы полностью включить узел и перейти в состояние «UNCONFIGURED_NODE» («НЕСКОНФИГУРИРОВАННЫЙ УЗЕЛ»). Сигнал MySwitchOn (Собственное включение) должен устанавливаться аппаратым обеспечением для всех состояний, кроме «DISCONNECTED_NODE» («ОТКЛЮЧЕННЫЙ УЗЕЛ») и «SLEEPING_NODE» («УЗЕЛ В СПЯЩЕМ РЕЖИМЕ») ПРИМЕЧАНИЕ 1 Вход в это состояние приводт к обрыву на шине. Узел будет снова активирован при наличии активности на шине. Следовательно, приложение должно поддерживать сигнал «NodeSleep» («Узел в спящем режиме») достаточно долго, чтобы избежать повторной активации узла другим узлом. ПРИМЕЧАНИЕ 2 Шинный переключатель находится под напряжением, поскольку полная потеря электропитания обеспечит переход узла в режим промежуточной настройки. ПРИМЕЧАНИЕ 3 Любая активность шины определяется Carrier_Sense (Контролем несущей) без сигнала ошибки качества сигнала (см. 4.7.1.5) или любых других средств, указывающих на то, что правильно сформированный кадр был принят по любому из каналов. 5.5.4.7.3 Состояние «UNCONFIGURED_NODE» («НЕСКОНФИГУРИРОВАННЫЙ УЗЕЛ») Узел должен находиться в режиме промежуточной настройки и ожидать своего дескриптора узла и данных открытия эксплуатации. Узел должен выйти из состояния UNCONFIGURED_NODE (НЕСКОНФИГУРИРОВАННЫЙ УЗЕЛ) после получения команды NodeSetUp (Установка узла) с допустимым дескриптором узла. Он должен перейти к макросу NAMING_MASTER (ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО), если это узел с большой логической силой, или к макросу UNNAMED_SLAVE (АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО), если это узел с малой логической силой или подчиненный узел. 5.5.4.8 5.5.4.8.1 Состояния управляющего устройства Процедура REQUEST_RESPONSE (ЗАПРОС_ОТВЕТ) Как показано на Рисунке 90, данная процедура отправляет запрос и ожидает соответствующего ответа. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 122 – 61375-2-1 © IEC:2012 ЗАПРОС_ОТВЕТ (RR,DD,RQ,SD,RP) послать запрос(DD, RR, RQ) ОЖИДАНИЕ_ ОТВЕТА получить ответ (SD, RR, RP) тип RQ = тип RP ? T_reply нет ответа нет да норма (SD, RP) Неправильный тип не норма (пусто) Рисунок 90 - Процедура REQUEST_RESPONSE (ЗАПРОС_ОТВЕТ) Параметры: a) RR: Тип запроса/ответа, один из: {Присутствие, состояние, наименование, топография}; b) DD Устройство адресат; c) SD: Устройство источник; d) RP: Параметры ответа (зависят от типа запроса/ответа в соответствии с определением кадра); e) RQ: Параметры запроса (зависят от типа запроса/ответа в соответствии с определением кадра); Выход из процедуры: при ответе от подчиненного устройства или По истечении периода тайм-аута T_reply. 5.5.4.8.2 Процедуры «SET_TO_END» («УСТАНОВКА КОНЕЧНОЙ НАСТРОЙКИ») И «SET_TO_INT» («УСТАНОВКА ПРОМЕЖУТОЧНОГО СОСТОЯНИЯ») Как показано на Рисунке 91, эти две процедуры устанавливают узел в режим конечной настройки (End Setting) или, соответственно, в режим промежуточной настройки (Intermediate Setting), если он еще не находится в этом состоянии. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 123 – SET_TO_INT SET_TO_END MySetting ? кон ечн ая Промежуточная SetEnd_Response (01); Промежуточная MySetting ? Установить узел в режим End_Setting END_ SWITCH T_switch Detect(outward) := 1 конечная Detect(outward):= 0 Detect(1):= NO; Found(1):= NO; Detect(2):= NO; Found(2):= NO; установить узел в режим промежуточной настройкиINT_ SWITCH T_switch MySetting := End выполнено MySetting := Int выполнено Рисунок 91 - Процедуры «SET_TO_END» («УСТАНОВКА КОНЕЧНОЙ НАСТРОЙКИ») И «SET_TO_INT» («УСТАНОВКА ПРОМЕЖУТОЧНОГО СОСТОЯНИЯ») Переменные Detect(1) (Обнаружен (1)) и Detect(2) (Обнаружен (2)) управляют запуском и остановом процесса «AUXILIARY_PROCESS» («ВСПОМОГАТЕЛЬНЫЙ ПРОЦЕСС»), соответственно. Если узел, для которого необходимо установки конечную настройку, сам является управляющим устройством, или если узел является анонимным, оба параметра Detect(1) и Detect(2) становятся равными «1». 5.5.4.8.3 Макрос «INIT_MASTER» («ИНИЦИАЛИЗАЦИЯ УПРАВЛЯЮЩЕГО УСТРОЙСТВА») Как показано на Рисунке. 92, этот макрос вводится для настройки узла в качестве управляющего устройства либо в результате повышения подчиненного устройства до управляющего устройства с большой логической силой, либо в результате того, что анонимное подчиненное устройство становится управляющим устройство в следствие отсутствия активности на шине. Узел сначала инициализирует себя в конечной настройке (End Setting) (если это еще не сделано), устанавливает свой адрес и мощность, устанавливает пустую топографию и включает оба канала обнаружения, которые начинают отправлять запросы на обнаружение. В этой конфигурации управляющее устройство действует так, как если бы оно опрашивало само себя. После завершения установки управляющее устройство готово называть другие узлы, которые сможет найти. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 124 – 61375-2-1 © IEC:2012 INIT_MASTER SET_TO_END инициализация переменных и структур данных, в частности топографии. MyStr := 2 + Strong x 128; MyAdr := 01; MyBottom := 00; Bottom_Adr := 00; Top_Adr := 01; Supervisory_List:= {пусто}; Message_List:= {пусто}; Found(1) := NO; Detect(1) := YES; Found(2) := NO; Detect(2) := YES; C_bit := NO Рисунок 92 - Макрос «INIT_MASTER» («ИНИЦИАЛИЗАЦИЯ УПРАВЛЯЮЩЕГО УСТРОЙСТВА») 5.5.4.8.4 Макрос «NAMING_MASTER» («ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») Как показано на Рисунке 93, этот макрос содержит состояния, в которых управляющее устройство присваивает имена другим узлам. Управляющее устройство входит в это состояние, выполняя макрос INIT_MASTER, который инициализирует его. Управляющее устройство должно ожидать в состоянии «AWAIT_PERIOD» («ПЕРИОД ОЖИДАНИЯ») начала периода присвоения имен управляющим устройством T_naming_master. Если задержка периода T_naming_master уже истекла, управляющее устройство продолжает работу немедленно. Управляющее устройство должно выполнить макрос ASK_END (ЗАПРОС КОНЕЧНОГО УЗЛА), который опрашивает конечный узел, обнаружил ли он другой состав, и действовать в зависимости от результата выполнения этого макроса: a) если обнаруженный состав имеет большую логическую силу, управляющее устройство расформировывает состав, переходя к макросу UNNAMING_MASTER (УДАЛЕНИЕ ИМЕН УПРАВЛЯЮЩИМ УСТРОЙСТВОМ); b) если обнаруженный состав имеет меньшую или равную логическую силу с текущим составом, управляющее устройство должно дождаться расформирования другого состава (что занимает неопределенное время); c) если конечный узел не отвечает, управляющее устройство должно зарегистрировать ошибку и повторить попытку позже. Три последовательные ошибки в одном и том же направлении должны привести к его расформированию путем выполнения макроса UNNAMING_MASTER; d) если конечный узел сообщает о анонимном узле, управляющее устройство должен назвать этот узел новым конечным узлом; e) если управляющее устройство не обнаруживает ни одного именуемого узла после трех последовательных опросов в одном и том же направлении, оно должно перейти в состояние TEACHING_MASTER (ОБУЧАЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО). ПРИМЕЧАНИЕ 1 Управляющее устройство присваивает имя одному узлу в течение периода T_naming_master. ПРИМЕЧАНИЕ 2 В состоянии NAMING_MASTER открытие эксплуатации всегда разрешено. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 125 – NAMING_MASTER Lost(1) := 0; Lost(2) := 0; NAMING_MASTER T_naming_master IF NamingDir = 1 THEN NamingDir := 2 ELSE NamingDir := 1 END в противном случае проверка обоих концов ASK_END найден более сильный нет ответа не найдено именуемых найден анонимный Missed(NamingDir) :=0; Lost(NamingDir) := Lost(NamingDir) + 1; Missed(NamingDir):=0; Lost(NamingDir):=0; Missed(NamingDir) := Missed(NamingDir)+1 Missed(NamingDir) > 3 ? NNS > 61 ? не т да нет Lost(1) >3 И Lost(2) := 3; да нет да NAME_ONE новое имя найден неименуемый ошибка наименования Errors := 0 Errors := Errors + 1 Errors > 3 ? не т обучение да расформирование Рисунок 93 - Макрос «NAMING_MASTER» («ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 126 – 5.5.4.8.5 61375-2-1 © IEC:2012 Макрос «ASK_END» («ЗАПРОС КОНЕЧНОГО УЗЛА») Как показано на Рисунке 94, этот макрос проверяет наличие конечного узла в направлении «NamingDir» («Направление наименования») и запрашивает у него отчет о возможном удаленном составе. Он неявно включает случай, когда управляющее устройство само является конечным узлом. В зависимости от обнаруженной удаленной мощности управляющее устройство различает три случая: a) не найден именуемый узел (либо узел отсутствует, либо уже именован); b) найден анонимный узел (удаленный узел должен принять имя) c) найден более сильный (дистанционный узел принадлежит к составу с большей логической силой) ASK_END (NamingDir) =1 NamingDir end_node:=Bottom_Adr =2 end_node:=Top_Adr end_node = 00 end_node = 01 end_node другие RS := RemStr(1); RemStr(1) := 0; Change(1):= NO; RS := RemStr(2); RemStr(2) := 0; Change(2):= НЕТ; REQUEST_RESPONSE (Presence end_node, MyStr SD,NS,RS) ND = ND[end_node] ? да нет ND[end_node]:= ND Topo.Modif := YES в ином случае compare RS unnamed нет ответа не найдено именуемых считывание присутствия также сбрасывает RemStr (Удаленная мощность) в конечном узле в случае, если конечный узел объявляет об изменении дескриптора. (RS > MyStr) И MyStr < 128 (RS=1) найден анонимный найден более сильный Рисунок 94 - Макрос «ASK_END» («ЗАПРОС КОНЕЧНОГО УЗЛА») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.4.8.6 – 127 – Процедура «NAME_ONE» («ИМЕНОВАТЬ ОДИН») Как показано на Рисунке 95, эта процедура макроса «NAMING_MASTER» («ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») вызывается, когда конечный узел сообщает о наличии анонимного узла. Данная процедура включает в себя параметр направления именования. Если управляющее устройство само является конечным узлом, и оно уже назвало узлы на другой стороне, оно должен перейти к промежуточной настройке без отправки команды по шине. В противном случае управляющее устройство должно оставаться в состоянии конечной настройки и отправлять запрос на установку промежуточного положения (SetInt Request) на конечный узел в направлении именования. При отсутствии ответа об установке промежуточного положения (SetInt Response), управляющее устройство должно дождаться истечения периода T_switch и повторить запрос SetInt Request. Если оно не получает ответ об установке промежуточного положения (SetInt Response) после трех попыток, управляющее устройство должно выйти из этой процедуры с «naming error» («ошибкой именования»). В противном случае, после получения ответа об установке промежуточного положения (SetInt Response), управляющее устройство должно дождаться окончания задержки T_switch, а затем отправить анонимному узлу запрос о наименовании, включая адрес узла как «your_address» и мощность его состава как «your_strength», со следующим протоколом: a) управляющее устройство должно отправить запрос о наименовании, при этом для первой попытки принимается Destination_Device (Устройство-адресат) = «unnamed» («анонимное»); b) при отсутствии ответа о наименовании после первой попытки, управляющее устройство должно дождаться окончания периода времени T_aux_main и снова отправить запрос о наименовании, при этом для Destination_Device (Устройства-адресата) должен быть назначен адрес узла; c) при отсутствии ответа о наименовании после второй попытки, управляющее устройство должно снова отправить запрос о наименовании, при этом Destination_Device (Устройство-адресата) должно иметь анонимный («unnamed») адрес; d) при отсутствии ответа о наименовании после третьей попытки, управляющее устройство должно дождаться окончания периода времени T_aux_main и снова отправить запрос о наименовании, при этом для Destination_Device (Устройства-адресата) должен быть назначен адрес узла; e) при отсутствии ответа о наименовании после четвертой попытки с периодом времени T_reply, управляющее устройство должно снова отправить запрос о наименовании, Destination_Device (Устройство-адресата) должно иметь анонимный («unnamed») адрес; f) при этом при отсутствии ответа о наименовании после пятой попытки, управляющее устройство должно дождаться окончания периода времени T_aux_main и снова отправить запрос о наименовании, при этом для Destination_Device (Устройства-адресата) должен быть назначен адрес; g) при отсутствии ответа после шестой попытки, управляющее устройство должно восстановить прежний конечный узел в конечной настройке, отправив запрос конечной настройки (SetEnd Request), а затем дождаться T_switch до размыкания переключателя, прежде чем выйти из процедуры NAME_ONE со статусом «unnameable_found» («найден неименуемый»). В противном случае, если присвоение имени прошло успешно, управляющее устройство должно обновить топографию, адреса конечных узлов и мощность состава и должен дождаться T_aux_main и отправить запрос о состояния узлу с новым именем. Если управляющее устройство получает ответ о состоянии только на доверенной линии, а наблюдаемая линия повреждена, управляющее устройство должно выждать 1,2 мс, прежде чем повторить запрос о состоянии (и дождаться ответа о состоянии), повторив запрос о состоянии в общей сложности три раза, чтобы оценить качество линии и сообщить результат в своем следующем отчете управляющего устройства (Master_Report). Если оно не получает ответа после тех попыток отправки запроса о состоянии, управляющее устройство должно выйти из процедуры со статусом «unnameable_found» («найден неименуемый»). В противном случае, если оно получает ответ о состоянии, и должно актуализировать топографию, адреса конечных узлов и мощность состава и выйти со статусом «new_named» («вновь именованный»). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 128 – 61375-2-1 IEC:2012 ПРИМЕЧАНИЕ 1 Ожидается, что анонимный узел получит запрос о наименовании и отправит ответ о наименовании по своему дополнительному каналу. ПРИМЕЧАНИЕ 2 Задержка T_aux_main позволяет переключаться с дополнительного канала на основной канал. В это время трафик шины остановлен. ПРИМЕНЧАНИЕ 3 Вновь именованный узел принимает имя, отправляя ответ о наименовании, или отказывается от наименования, не отправляя ответ. ПРИМЕЧАНИЕ 4 Если узел был именован, но ответ был потерян, попытки с «анонимным» устройством-адресатом будут неудачными. И наоборот, если присвоение имени не имело места, попытки с устройством-адресатом, являющимся выделенным адресом узла, будут неудачными. ПРИМЕЧАНИЕ 5 Именованный узел возвращает ответ о состоянии с дескриптором узла и удаленной мощностью других узлов, которые он мог обнаружить. ПРИМЕЧАНИЕ 6 Трехкратное повторение запроса о состоянии в случае возникновения помех позволяет управляющему устройству различать потерю кадра и потерю одной избыточной линии между ним и конечным узлом. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 129 – Переменн ая end_node NAME_ONE IF (NamingDir=2) THEN end_node := Top_Adr; YA := Top_Adr + 1 ELSE end_node := Bottom_Adr; YA := Bottom_Adr -1 + 128; END YS := MyStr + 2; Тип INT8 Значение адрес конечного узла в любом направлении YA включает направление наименования в качестве самого старшего бита (возрастание. убывание) SET_TO_INT (end_node) (ok) нет ответа ЗАМЫКАНИЕ ШИННОГО _ПЕРЕКЛЮЧАТЕЛЯ T_switch REQUEST_RESPONSE (Именование 7F, YA, YS, SD) нет ответа КАНАЛ ПЕРЕКЛЮЧЕНИЯ T_aux_main REQUEST_RESPONSE (Состояние 7F, YA, MR, YS, SD,NR,RS,res,UR,NF,NP,NT,NV) нет ответа обновить топорграфию MyStr := MyStr+2; IF (NamingDir=2) THEN Top_Adr := Top_Adr+1 end_node := Bottom_Adr ELSE Bottom_Adr := Bottom_Adr-1; end_node := Top_Adr END SET_TO_END end_node, MyStr, ok) РАЗМЫКАНИЕ ШИННОГО _ПЕРЕКЛЮЧАТЕЛЯ T_switch найден вновь именованный неименуемый ошибка наименован ия Рисунок 95 - Процедура NAME_ONE («ИМЕНОВАТЬ ОДИН») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 130 – 5.5.4.8.7 61375-2-1 IEC:2012 Макрос «TEACHING_MASTER» («ОБУЧАЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») Как показано на Рисунке 96, управляющее устройство распределяет информацию о топографии по всем именованным узлам, когда оно не обнаруживает больше узлов для присвоения имени или, когда оно обнаруживает узел, оповещающий об изменении его дескриптора узла. Для этого необходимо увеличивать значения топографического топографического счетчика управляющего устройства (MasterTopo). счетчика (TopoCounter) Узел должен последовательно отправить запрос топографии три раза всем именованным узлам, начиная с нижнего узла и заканчивая верхним узлом, включая себя (самоопрос), в порядке возрастания адресов. Узел должен выйти из этого состояния: когда он не получает ответа о топографии после трехкратной отправки запроса топографии, и в этом случае он должен перейти к макросу UNNAMING_MASTER; когда он получил от всех узлов ответ о топографии, и в этом случае он должен перейти к макросу REGULAR_MASTER. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 и 61375-2-1 © IEC:2012 – 131 – Переменная TEACHING_MASTER adr Topo_Counter:=Topo_Counter+1; Master_Topo:= Master_Topo+1 adr := Bottom_Adr да succes Тип Значение INTEGER8 адрес узла, который получил запрос на передачу ответа о топографии INTEGER8 указывает количество успешных распределений adr = 0 нет success = 0 REQUEST_RESPONSE Топография подтверждени е не норма success = success+1 REQUEST_RESPONSE Топография не норма подтверждени е success = success+1 REQUEST_RESPONSE Топография подтверждени е не норма success = success+1 success > 0 ? нет да adr = Top_Adr нет да UNNAMING_MASTER adr := adr + 1 все_обучены ошибка_распред еления Рисунок 96 - Макрос «TEACHING_MASTER» («ОБУЧАЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 132 – 5.5.4.8.8 61375-2-1 © IEC:2012 Макрос «UNNAMING_MASTER» («УДАЛЕНИЕ ИМЕН УПРАВЛЯЮЩИМ УСТРОЙСТВОМ») Как показано на Рисунке 97 управляющее устройство расформировывает данный состав путем удаления имен всех узлов. Для этого оно должно последовательно передать три запроса на удаление имени (Unname Requests) в течение 1,0 мс, а затем, в случае узла с большой логической силой, перейти к макросу NAMING_MASTER (ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО) или, в противном случае, перейти к макросу UNNAMED_SLAVE (АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО). ПРИМЕЧАНИЕ Задержка необходима для того, чтобы гарантировать, что все узлы получат запрос на удаление имени, а подчиненное устройство будет выдерживать тот же самый период задержки перед переходом к конечной настройке. UNNAMING _MASTER REQUEST_RESPONSE (Удаление имени, широковещательная передача, пусто пусто, пусто) REQUEST_RESPONSE (Удаление имени, широковещательная передача, пусто пусто, пусто) REQUEST_RESPONSE (Удаление имени, широковещательная передача, пусто пусто, пусто) удаление имени управляющим устройством Рисунок 97 - Макрос «UNNAMING_MASTER» («УДАЛЕНИЕ ИМЕН УПРАВЛЯЮЩИМ УСТРОЙСТВОМ») 5.5.4.8.9 Макрос «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») Как показано на Рисунке 98 управляющее устройство используется в плановой эксплуатации. Макрос «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») разделен на три блока: a) «PERIODIC_POLL» («ПЕРИОДИЧЕСКИЙ ОПРОС») Управляющее устройство опрашивает узлы из периодического списка для получения данных процесса. Данная фаза представлена в 5.5.4.8.11; b) «SUPERVISORY_POLL» («КОНТРОЛЬНЫЙ ОПРОС») управляющее устройство должно отправить запрос о присутствии одному конечному узлу в течение каждого основного периода; интервал между любыми четырьмя последовательными запросами о присутствии в одном и том же направлении должен составлять не более 6,5 × T_bp. Удобным способом добиться этого является оправление запроса о присутствии в течение фиксированного процента основного периода, например, в начале каждого основного периода управляющее устройство проверяет состояние узлов, которые увеличили бит С. Эта проверка должна выполняться после периодической фазы; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 133 – Управляющее устройство должно выйти из макроса REGULAR_MASTER в следующих случаях: d) если оно перестает распознавать присутствие конечного узла в течение трех последовательных опросов, то должно расформировать состав и перейти к макросу NAMING_MASTER; e) если оно обнаружит наличие другого именуемого состава и, что открытие эксплуатации включено, то должно выполнить макрос UNNAMING_MASTER, чтобы расформировать состав, а затем перейти к макросу NAMING_MASTER; f) если оно обнаружит изменение состава, то должно перейти к макросу TEACHING_MASTER; g) если оно обнаружит состав с большей логической силой, чем его собственный с включенным открытием эксплуатации, то должно расформировать свой состав перед переходом к макросу UNNAMED_SLAVE; h) если оно было переведено в спящий режим или было отключено командой приложения, то должно перейти к макросу UNNAMED_SLAVE. ПРИМЕНЧАНИЕ Макрос UNNAMED_SLAVE переводит узел в спящий режим, когда все остальные узлы также находятся в этом состоянии. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 134 – 61375-2-1 © IEC:2012 REGULAR_ MASTER Missed(1):= 0; Missed(2):= 0; AWAIT _PERIOD T_bp PERIODIC _POLL IF NamingDir = 1 THEN NamingDir := 2 ELSE NamingDir := 1 END контроль конечных узлов ASK_END (NamingDir) найден более сильный найден анонимный нет ответа Missed(NamingDir):= Missed(NamingDir)+1 Missed(NamingDir) > 3 не найдено именуемых Missed(NamingDir) := 0; не т да открытие эксплуатации разрешено? да не т не т CHECK_DESC (ПРОВЕРКА ДЕСКРИПТ ОРА) изменен проверен открытие эксплуатации разрешено? да установлен спящий режим MESSAGE _POLL удлинение укорочение обучение установлен понижен спящий режим Рисунок 98 - Макрос «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 5.5.4.8.10 – 135 – Макрос «CHECK_DESC» («ПРОВЕРКА ДЕСКРИПТОРА») Как показано на Рисунке 99, этот макрос проверяет любые промежуточные узлы, которые запросили изменение дескриптора или перевод в спящий режим. Случай конечных узлов рассматривается отдельно, поскольку конечный узел может дополнительно сигнализировать об удлинении шины. CHECK_DESC удалено из списка SP да Список SP пуст ? нет REQUEST_RESPONSE Состояние, DD, MyStr, SD,NS,RS,ND) нет ответа да запрос на спящий режим? регистрация запроса на спящий режим запрос на спящий режим от всех узлов не т не т да изменение дескриптора? да проверен обучение установлен спящий режим Рисунок 99 - Макрос «CHECK_DESC» («ПРОВЕРКА ДЕСКРИПТОРА») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 136 – 5.5.4.8.11 61375-2-1 IEC:2012 Макрос «PERIODIC_POLL» («ПЕРИОДИЧЕСКИЙ ОПРОС») Как показано на Рисунке 100, управляющее устройство сканирует узлы в соответствии с периодическим листом, в котором перечислены адреса, которые должны быть опрошены в течение этого периода. При опросе узлов для получения данных процесса управляющее устройство должно: a) регистрировать наличие и данные процесса опрашиваемого узла; b) регистрировать изменения состава (C_bit) с узлов, которые изменили свой дескриптор узла; c) зарегистрировать узлы, которым требуется передача данных сообщения, путем увеличения их бита A_bit; d) зарегистрировать узлы, которые запретили открытие эксплуатации посредством бита I_bit. управляющее устройство не должно повторять запрос данных процесса (Process_Data_Request) в течение того же основного периода, если он не получает ответ о данных процесса (Process_Data_Response) Когда управляющее устройство опрашивает себя, оно должно отправить себе запрос данных процесса (Process_Data_Request) перед отправкой ответа о данных процесса (Process_Data_Response). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 137 – PERIODIC _POLL выбрать следующий узел из периодического списка (Periodic_List) получить (DD) периодического списка (Periodic_List) Периодический список (Periodic_List) пуст? да нет REQUEST_RESPONSE (PD_poll, DD, (PD) SD, PD) но рм а IF (PD <> {пуст}) хранить PD в порту[SD] C_bit = 1 ? нет ответа да включить SD в контрольный лист (Supervisory_List) Distribute_topo = 1 не т A_bit = 1 ? да включить SD в контрольный лист (Supervisory_List) не т I_bit = 1 ? нет да Запрет[SD] := «1» Запрет[SD] := «0» конец периодического опроса Рисунок 100 - Макрос «PERIODIC_POLL» («ПЕРИОДИЧЕСКИЙ ОПРОС») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 138 – 5.5.4.8.12 61375-2-1 © IEC:2012 Макрос «MESSAGE_POLL» («ОПРОС СООБЩЕНИЙ») Как показано на Рисунке 101, управляющее устройство должно отправить данные сообщения, если до следующей периодической фазы осталось достаточно времени. Управляющее устройство не должно повторять запрос данных сообщения (Message Data Request) в течение того же основного периода, если оно не получило ответа по данным сообщения (Message Data Response). Когда управляющее устройство опрашивает себя, оно должно отправить себе запрос данных сообщения перед отправкой ответа о данных сообщения. Узел должен выйти из этого состояния, если до начала следующей периодической фазы не осталось времени для отправки полного кадра. Затем он должен вернуться в состояние «AWAIT_PERIOD» («ПЕРИОД ОЖИДАНИЯ») MESSAGE _POLL достаточность защитного временного интервала? нет да удалить адрес узла из списка сообщений список сообщений пуст? да нет POLL_MD (адрес узла) (данные сообщения) нет установлен A_bit? да вставить адрес узла в список сообщений? нет установлен C_bit? да вставить адрес узла в контрольный список? выполн о Рисунок 101 - Макрос «MESSAGE_POLL» («ОПРОС СООБЩЕНИЙ») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.4.9 5.5.4.9.1 – 139 – Состояние подчиненного устройства Макрос «UNNAMED_SLAVE» («АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») Как показано на Рисунке 102, узел должен перевести себя в состояние конечной настройки (End Setting), при этом оба его дополнительных канала прослушиваются, и ждать присвоения имени в состоянии AWAIT_NAMING (ОЖИДАНИЕ НАИМЕНОВАНИЯ). При переходе в состояние AWAIT_NAMING (ОЖИДАНИЕ НАИМЕНОВАНИЯ) узел должен сбросить таймер T_await_naming и ожидать: a) срабатывания таймера T_await_naming если он получил команду NodeSleep (Узел в спящем режиме) от приложения, то узел должен переключиться на промежуточную настройку и перейти в состояние низкого энергопотребления NODE_SLEEP (УЗЕЛ В СПЯЩЕМ РЕЖИМЕ), если он сконфигурирован как узел с малой логической силой, то узел должен перейти к макросу NAMING_MASTER (ИМЕНУЮЩЕЕ УПРАВЛЯЮЩЕЕ УСТРОЙСТВО), или в противном случае узел должен вернуться к макросу UNNAMED_SLAVE (АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО); b) сигнала «NamedBy» («Именовано») по дополнительному каналу, узел блокирует свой основной канал в направлении именования, узел переходит состояние NAMED_SLAVE (ИМЕНОВАННОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 140 – 61375-2-1 © IEC:2012 UNNAMED_SLAVE MySetting ? конец промежуточный настроить конечную установку РАЗМЫКАНИЕ ШИННОГО _ПЕРЕКЛЮЧАТЕЛЯ T_switch MyAdr := UNNAMED Detect(1) := «1»; Detect(2) := «1»; MyComp.CS := {пусто}; AWAIT _NAMING T_await_naming Named_By (1) (сброс T_await_naming) Named_By (2) да NodeSleep (Узел в спящем режиме) не т разрешено нет да повышенное в спящем режиме именованное Рисунок 102 - Состояния «UNNAMED_SLAVE» («АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.4.9.2 – 141 – Макрос «NAMED_SLAVE» («ИМЕНОВАННОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») Как показано на Рисунке 103, узел в этом состоянии был именован и может изменить режим конечной настройки на промежуточную настройку или наоборот в этом состоянии в ответ на запросы управляющего устройства. При переходе в состояние NAMED_SLAVE (ИМЕНОВАННОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО) узел должен сбросить таймер T_await_naming и ожидать: a) изменения дескриптора узла: если он был повышен до узла с большой логической силой, то должен перейти в состояние NAMING_MASTER, или в противном случае, увеличить C_bit или вернуться к макросу NAMED_SLAVE; b) тайм-аута T_named_slave: перейти в состояние UNNAMED_SLAVE; c) Запроса о наименовании (Naming Request): отправить ответ о именовании управляющему устройству; d) Запроса на установку промежуточного положения (SetInt Request): отправить управляющему устройству ответ об установке промежуточного положения (SetInt Response), перейти к промежуточной настройке, если узел еще не перешел к этой настройке; e) Запроса конечной настройки (SetEnd Request): отправить управляющему устройству ответ о конечной настройке (SetEnd Response), перейти к промежуточной настройке, если узел еще не находится в этой настройке; f) Запроса о состоянии (Status Request): выполнить широковещательную передачу ответа о состоянии; g) Ответа о состоянии (Status Response): зарегистрировать состояние для проверки резервирования линии; h) Запроса на удаление имени (Unname Request): ожидать T_aux_main (чтобы все узлы могли получить один из трех запросов на удаление имени), установить максимальное пороговое значение для таймера T_await_naming, и перейти в состояние NAMED_SLAVE (ИМЕНОВАННОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО); i) Запроса топографии (Topography Request), ответа о топографии (Topography Response): ответить, как в состоянии LEARNING_SLAVE (ОБУЧАЕМОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО) и перейти в состояние LEARNING_SLAVE (ОБУЧАЕМОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО); j) ничего из вышеуказанного: увеличить счетчик ошибок. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 142 – 61375-2-1 © IEC:2012 NAMED_SLAVE Missed(1) := 0; Missed(2) := 0; (перезапустить T_named_slave) NAMED SLAVE (MySetting) T_named_slave кадр к данному узлу NodeSetUp да Naming_Request ? да если тот же узел отправляет Naming_Response нет IF (ND ° MyND) THEN Изменение = YES; END; SetInt_Request да SET_TO_INT не т SetEnd_Request (YS,res) не т да да Конечная настройка И НЕ настаивает не т SET_TO_END нет Status_Request ? да отправить Status_Response нет Status_Response ? нет Unname_Request ? да да проверить состояние линии ожидание T_aux_main нет Topography_Request да нет Topography_Response да сильное? не т нет MyErrors := MyErrors+1 ответ как в состоянии LEARNING_SLAVE да повышенное обучаемое анонимн Рисунок 103 - Состояния «NAMED_SLAVE» («ИМЕНОВАННОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО») ПРИМЕЧАНИЕ1 На этапе именования контроль шины осуществляется с помощью ответов о состоянии при игнорировании конечных узлов. ПРИМЕЧАНИЕ 2 Узел игнорирует запросы данных сообщения, ответы по данным сообщения, запросы данных процесса и ответы по данным сообщения, запросы о присутствии и ответы о присутствии в этом состоянии. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.4.9.3 – 143 – Макрос «LEARNING_SLAVE» («ОБУЧАЕМОЕ ПОДЧИНЕНОЕ УСТРОЙСТВО») Как показано на Рисунке 104, узел получает информацию о топографии от всех других узлов, контролируя шину. Узел не меняет ни своих настроек, ни своего имени. При переходе в состояние LEARNING_SLAVE (ОБУЧАЕМОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО) узел должен сбросить таймер T_learning_slave и ожидать: a) изменения дескриптора узла: если он был повышен до узла с большой логической силой, то должен перейти в состояние NAMING_MASTER, или в противном случае, он должен увеличить свой C_bit; b) тайм-аута T_named_slave: перейти в состояние UNNAMED_SLAVE без изменения значения таймера T_await_naming; c) Запроса на удаление имени (Unname Request): ожидать T_aux_main (чтобы все узлы могли получить один из трех запросов на удаление имени), установить максимальное пороговое значение для таймера T_await_max, и перейти в состояние UNNAMED_SLAVE (АНОНИМНОЕ ПОДЧИНЕННОЕ УСТРОЙСТВО); d) Запроса о состоянии (Status Request): отправить ответ о состоянии управляющему устройству; e) Ответа о состоянии (Status Response): зарегистрировать состояние; f) Запроса топографии (Topography Request): выполнить широковещательную передачу ответа о топографии (Topography Response); g) Ответа о топографии (Topography Response): обновить топографию, проверить наличие полной топографии, все ли ответы о топографии были получены одним и тем же топографическим счетчиком управляющего устройства (Master_Topo), и если да, установить Updated:= TRUE (ИСТИНА); h) Запроса о присутствии (Presence Response), ответа о присутствии (Presence Response), запроса о данных процесса (Process_Data_Request), ответа по данным процесса (Process_Data_Response), запроса данных сообщения (Message_Data_Request), ответа по данным сообщения (Message_Data_Response): ответить как в состоянии REGULAR_SLAVE (ПОДЧИНЕННОЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ) и перейти в состояние REGULAR_SLAVE (ПОДЧИНЕННОЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ); i) ничего из вышеуказанного: увеличить счетчик ошибок. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 144 – 61375-2-1 © IEC:2012 LEARNING_SLAVE Updated:= FALSE LEARNING SLAVE (MySetting) NodeSetUp кадр к данному узлу Unname_Request ? T_learning_slave да нет Status_Request ? да нет ожидание T_aux_main _Response отправить Status Status_Response ? да нет IF (ND ° MyND) THEN Change = YES; END Topography_Request да зарегистрировать состояние узла нет Topography_Response да нет hy_Response отправить Topograp Зарегистрировать дескрипторы и данные открытия эксплуатации Process_Data_Request ИЛИ Process_Data_Response нет все дескрипторы получены ? не т да Updated:= Message_Data_Request ИЛИ Message_Data_Response YES нет Presence_Response да нет Presence_Request нет да ответить как в состоянии REGULAR_SLAVE MyErrors := MyErrors+1 нет сильное? да повышенное для плановой эксплуатации анонимный Рисунок 104 - Макрос «LEARNING_SLAVE» («ОБУЧАЕМОЕ ПОДЧИНЕНОЕ УСТРОЙСТВО») ПРИМЕЧАНИЕ На этапе обучения контроль шины осуществляется с помощью ответов о топографии при игнорировании конечных узлов. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 145 – Макрос «REGULAR_SLAVE» («ПОДЧИНЕННОЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») 5.5.4.9.4 Как показано на Рисунке 105, обычное эксплуатационное состояние узла, в котором он отправляет и получает данные процесса и данные сообщения, а также оповещает о событиях, устанавливая биты индикации в своих ответах. Узел контролирует активность конечных узлов с помощью двух таймеров. В состоянии REGULAR_SLAVE (ПОДЧИНЕННОЕ УСТРОЙСТВО ДЛЯ ПЛАВНОВОЙ ЭКСПЛУАТАЦИИ) узел должен ожидать: a) изменения дескриптора узла: если он был повышен до узла с большой логической силой, то должен перейти в состояние NAMING_MASTER, или в противном случае, увеличить бит C_bit; b) тайм-аута T_bus_check для каждого контролируемого конечного узла: перейти в состояние UNNAMED_SLAVE, сохраняя начальное значение T_await_naming; c) Запроса о присутствии (Presence Request): выполнить широковещательную передачу ответа о присутствии (Presence Response) (узел должен игнорировать запрос о присутствии, если он не является конечным узлом); d) Ответа о присутствии (Presence Response): перезапустить соответствующий таймер T_bus_check; e) Запроса о состоянии (Status Request): отправить ответ о состоянии управляющему устройству; f) Запроса на удаление имени (Unname Request): ожидать T_aux_main (чтобы все узлы могли получить один из трех запросов на удаление имени), установить максимальное пороговое значение для таймера T_await_naming, и перейти в состояние UNNAMED_SLAVE; g) Запроса данных процесса (Process_Data_Request) без данных процесса: если узел обновлен, то отправить ответ о данных процесса (Process_Data_Response), считывая данные из порта-источника, в противном случае, отправить пустой ответ о данных процесса (Process_Data_Response); h) (дополнительно) запроса данных процесса (Process_Data_Request) с данными процесса: если параметр Updated (Обновлен) имеет значение TRUE (ИСТИНА), то необходимо записать эти данные в порт приемника, предназначенный для получения данных от управляющего устройства, и отправить ответ о данных процесса (Process_Data_Response), считывая данные из порта-источника, в противном случае, проигнорировать данные и отправить пустой ответ о данных процесса; i) Ответа о данных процесса (Process_Data_Response): если параметр Updated (Обновлен) имеет значение TRUE (ИСТИНА), записать эти данные в порт приемника, соответствующий адресу источника, в противном случае, проигнорировать данные; j) Запроса данных сообщения (Message Data Request): если очередь отправки пуста, отправить пустой ответ по данным сообщения (Message Data Response) (link_data_size = 0), адресованный управляющему устройству, или, в проитвном случае отправить ответ по данным сообщения (Message Data Response) с пакетом данных сообщения, извлеченным из его очереди отправки; k) Ответа по данным сообщения (Message Data Response): сохранить входящие данные сообщения в очереди приема, при наличии места, в противном случае игнорировать их (см. 5.6.3); l) Запроса о топографии (Topography Request) или ответа о топографии (Topography_Response): установить для параметра Updated значение FALSE (ЛОЖНО), ответить как в состоянии LEARNING_SLAVE и перейти в данное состояние; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 146 – 61375-2-1 © IEC:2012 m) ничего из вышеуказанного: увеличить счетчик ошибок и вернуться в состояние LEARNING_SLAVE. ПРИМЕНЧАНИЕ 1 Таймер T_bus_check также может быть реализован с одним таймером и счетчиками. ПРИМЕЧАНИЕ 2 С состоянием REGULAR_SLAVE не связан таймер, который перезапускается каждый раз при входе в это состояние, поскольку эта функция выполняется таймером T_bus_check. ПРИМЕЧАНИЕ 3 Контроль конечных узлов также может осуществляться с помощью таймера T_bus_check индивидуально для каждого конечного узла. REGULAR_SLAVE Missed(1):= YES; Missed(2):= YES; сбросить T_bus_check REGULAR SLAVE Обновлен (MySetting) правильный кадр NodeSetUp не т T_bus_check Presence_Response да Missed(1) := 2; IF (SD = BottomAdr) THEN Missed(1):= NO; END; IF (SD = TopAdr) THEN Missed(2):= NO; END; не т Status_Request не т Process_Data_Request ИЛИ Process_Data_Response Message_Data_Request не ИЛИ т Message_Data_Response не т Unname_Request не т Topography_Response не т Topography_Request сильное? да не т повышенное не т MyError s := MyErrors+1 да нет отправить Presence_Response Presence_Request IF (ND <> MyND) THEN Change = YES; END не перезапускать T_bus_check да Status_Response (01,NodeStatus,RS, ND) да ЕСЛИ обновлен ТО сохранить / отправить данные в/из буфера да сохранить / отправить данные сообщения в/из буфера да ожидание T_aux_main T_await_naming := 32 x T_bp да да Updated := FALSE; ответить как в состоянии LEARNING_SLAVE обучаемое анонимн Рисунок 105 - Макрос «REGULAR_MASTER» («УПРАВЛЯЮЩЕЕ УСТРОЙСТВО ДЛЯ ПЛАНОВОЙ ЭКСПЛУАТАЦИИ») Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.5.4.10 – 147 – Тайм-ауты Рекомендованные значения тайм-аутов (20 %) перечислены в Таблице 17. Таблица 17 - Значения постоянных времени Имя постоянной времени Значение Использование 1) T_await_min = 1,0 мс + T_switch Переименование состава управляющим устройством 2) ((63 – MyAdr) + 0,5) T_bp Узлы в направлении 1 управляющего устройства 3) (MyAdr-1) T_bp Узлы в направлении 2 управляющего устройства 4) T_await_max = 32 T_bp Инициализированные или явно анонимный узлы T_aux_main 1,0 мс T_await_response 1,756 мс Задержка переключения с дополнительного на основной канал (или наоборот) Время, в течение которого управляющее устройство ожидает подчиненного кадра. Это время соответствует самому длинному кадру, поскольку HDLC-контроллеры могут сигнализировать только о конце кадра T_bp 25,0 мс Основной период (плановая эксплуатация) T_naming_master 15,0 мс T_named_slave 15,0 мс T_learning_slave 15,0 мс T_bus_check (1) 6,5 T_bp период именования (открытия эксплуатации) контроль, осуществляемый управляющим устройством в течение фазы именования контроль, осуществляемый управляющим устройством в течение фазы обучения Контроль конечных узлов во время плановой эксплуатации T_await_naming T_bus_check(2) T_detecting 2 T_naming_master Интервал между запросами на обнаружение (Detect_Requests) (при наличии) в процессе открытия эксплуатации 2 T_bp Интервал между запросами на присутствие (Presence Requests)/запросами на обнаружение (Detect_Requests) (при наличии) в течение плановой эксплуатации Время, в течение которого конечный узел ожидает ответа об обнаружении T_detecting_response 1,047 мс T_new_inaug n T_bp Минимальное время между двумя последовательными открытиями эксплуатации. n задается приложением MAXLOST 50 T_switch 10,0 мс T_detecting MAXLOST - это время, после которого конечный узел предполагает, что другой состав больше не присутствует Задержка по умолчанию для замыкания или размыкания реле Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 148 – 5.6 61375-2-1 © IEC:2012 Интерфейс канального уровня 5.6.1 Структура канального уровня Интерфейс канального уровня предоставляет три службы, как показано на Рисунке 106: a) Интерфейс данных процесса канального уровня (Link Process_Data_Interface) (LPI), который используется службой переменных, представлен в разделе 6 (Протоколы реального времени). В этом стандарте указаны только параметры, характерные для проводной шины поезда. b) Интерфейс данных сообщения канального уровня (Link Message_Data_Interface) (LMI), который используется службой сообщений, представлен в разделе 6 (Протоколы реального времени). В этом стандарте указаны только параметры, характерные для проводной шины поезда. c) Интерфейс контроля канала (Link Supervision_Interface) (LSI), который позволяет сконфигурировать канальный уровень и контролировать шину, относится к проводной шине поезда и определяется в этом стандарте. Переменные Сообщения Контроль Интерфейс канального уровня Верхний канальный LPI LMI LSI Данные процесс а Данные сообщен ия Контрольн ые данные уровень общая память Нижний канальный уровень Функции подчиненного устройства обработка данных и телеграмм кодер/де кодер Функции управляющего устройства кодер/де кодер Физический уровень Рисунок 106 - Структура канального уровня Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.6.2 5.6.2.1 – 149 – Канальный интерфейс данных процесса (Link Process_Data_Interface) Общие положения Интерфейсом для данных процесса между канальным уровнем и более высокими уровнями является общая память, называемая Traffic_Store (Хранилище трафика), к которой может одновременно обращаться шина и приложение. Traffic_Store (Хранилище трафика) структурировано как несколько портов, которые содержат ровно один кадр, готовый для передачи или приема данных процесса. Каждый порт идентифицируется внутри узла с помощью идентификатора Traffic_Store и 12-битного адреса порта. Реализация портов не является частью стандартизации. Раздел 6 «Протоколы реального времени» определяет доступ к порту. 5.6.2.2 Данные, характерные для проводной шины поезда Хранилище трафика (Traffic_Store) проводной шины поезда должно содержать до 64 портов, каждый из которых включает максимум 1024 бита. Во всех случаях: каждый узел должен включать в себя один порт-источник для широковещательной передачи данных процесса, причем шесть старших битов равны ‘000000’B, а шесть младших битов адреса порта являются адресом данного узла; каждый узел должен включать в себя один порт-приемник для получения данных процесса от каждого возможного узла на шине, причем шесть старших битов равны ‘000000’B, а шесть младших битов адреса порта являются адресом узла источника. В приложениях, где управляющее устройство включает данные процесса в свой запрос данных процесса (Process_Data_Request), предназначенный только для опрашиваемого подчиненного устройства: управляющее устройство должно включать в себя один порт-источник для отправки данных процесса каждому подчиненному устройству, причем старших биты равны ‘000010’B, а шесть младших битов адреса порта являются адресом узла-адресата; каждое подчиненное устройство должно включать в себя один порт-приемник для приема данных процесса управляющего устройства, причем старшие биты равны ‘000010’B, и как минимум шесть младших битов адреса порта являются адресом узла; Узел не должен принимать данные процесса от узла, который не был включен в полученную топографию или чей дескриптор, полученный им в топографии, он не может интерпретировать. Узел может принимать данные процесса от другого узла, чей тип (Node_Type) ему известен, но чья версия (Node_Version) отличается от той, которая ему известна, но он должен декодировать данные в соответствии с меньшей из обеих версий узла (Node_Version). Узел не может изменить формат своего ответа о данных процесса (Process_Data_Response), не получив топографию, содержащую его новый ключ узла (Node_Key). Рекомендуется зарезервировать первые два октета данных процесса для идентификации типа кадра (тип узла + версия узла = ключ узла) в качестве дополнительной защиты. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 150 – 5.6.3 5.6.3.1 61375-2-1 IEC:2012 Канальный интерфейс данных сообщения (Link Message_Data_Interface) Общие положения Интерфейс данных сообщения канального уровня (Link Message_Data_Interface) (LMI), указанный в разделе 6 «Протоколы реального времени», предоставляет услуги для отправки кадров данных сообщения и услуги для извлечения полученных кадров данных сообщения. Кроме того, поддерживает предоставление услуг подтверждения отправки и индикации приема. Канальный интерфейс данных сообщения предоставляет основную услугу, на которой основаны все высокоуровневые протоколы: a) сетевой уровень обеспечивает маршрутизацию через сеть и функции каталога; b) транспортный протокол обеспечивает полудуплексное сквозное управление сообщениями; c) сеансовый уровень объединяет сообщения для обеспечения удаленного вызова процедур; d) уровень представления унифицирует представление данных; e) прикладной интерфейс обеспечивает клиентский и серверный интерфейсы. 5.6.3.2 Размер пакета Поле «link_data_size» («размер даных канала») в пустом пакете должно быть равно нулю. Поле «link_data_size» («размер даных канала») не должно превышать 128. 5.6.3.3 Тип протокола Тип протокола (Protocol_Type) для протоколов реального времени должен быть указан в поле link_control (управление каналом), установленном на ‘00xxx111’B (Message Data Response). 5.6.3.4 Протокол передачи сообщений Узел проводной шины поезда не должен объявлять размер пакета больше 124 октетов в запросе на установление соединения (Connect_Request). Отвечая на запрос на установление соединения (Connect_Request) узел должен указать в своем ответе на установление соединения (Connect_Response) размер пакета, равный 124 октетам, или предлагаемый размер пакета, в зависимости от того, что меньше. 5.6.4 5.6.4.1 Интерфейс управления каналом Общие положения Интерфейс управления каналом является характерным для проводной шины поезда. Он предоставляет общие услуги для конфигурования и проверки канального уровня и составления отчетов о событиях. Следующие подразделы не подразумевают конкретную реализацию. использование любого интерфейса, обеспечивающего подобную семантику. Допускается Формат параметров следующих процедур интерфейса не регламентируется. Однако стандарт управления поездной сетью (раздел 6) предлагает формат сообщения, который рекомендуется в качестве формата параметра. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 151 – Процедуры интерфейса 5.6.4.2 Процедуры этого интерфейса имеют префикс ls_t (контроль канала, проводная шина поезда). Тип LS_T_RESULT 5.6.4.2.1 Процедура использует тип LS_T_RESULT: Постоянная Код Значение L_OK 0 успешно L_BUSY 1 повторить попытку позже L_CALLING_SEQUENCE 2 неправильная последовательность команд L_MISSING_UDF 3 определяемая пользователем функция неизвестна L_CONFIGURATION_INVALID 4 Недопустимая топография или список узлов Постоянные LS_T_STATE 5.6.4.2.2 Следующие постоянные указывают основное состояние узла, в котором он находится в данный момент: Постоянная Код Значение узел в состоянии UNCONFIGURED (НЕСКОНФИГУРИРОВАННЫЙ) LS_INITIALIZED 0 LS_CONFIGURED 1 LS_READY_TO_NAME 2 LS_READY_TO_BE_NAMED 3 открытие эксплуатации узла 4 узел в состоянии REGULAR_MASTER (сильный) или TEACHING_MASTER 5 узел в состоянии REGULAR_SLAVE или TEACHING_MASTER узел в 6 состоянии REGULAR_MASTER (слабый) или TEACHING_MASTER LS_INHIBITED LS_REGULAR_STRONG LS_REGULAR_SLAVE LS_REGULAR_WEAK 7 узел в состоянии CONFIGURED (СКОНФИГУРИРОВАННЫЙ) узел в состоянии NAMING_MASTER узел в состоянии UNNAMED_SLAVE запрет на ПРИМЕЧАНИЕ Узел не может сообщить, что он находится в спящем состоянии 5.6.4.3 Отчет 5.6.4.3.1 Процедура ls_t_Report Действие Сообщает пользователю об изменении на канальном уровне. Данная процедура вызывается канальным уровнем и должна иметь предварительную подписку (см.: ls_t_Configure). Синтаксис Typedef LS_T_RESULT (* ls_t_Report) (ls_report) Параметр ввода ls_report один из кодов отчетов LR_REPORT. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 152 – Постоянные LR_REPORT 5.6.4.3.2 Ниже представлены значения кодов отчета: Постоянная Код Значение LR_CONFIGURED 16 канальный уровень сконфигурирован LR_STRONG 17 узел является действующим управляющим устройством LR_SLAVE 18 узел является действующим подчиненным устройством LR_PROMOTED 19 LR_NAMING_SUCCESSFUL 20 узел изменился с управляющего устройства с малой логической силой на управляющее устройство с большой логической силой управляющее устройство указывает конец открытия эксплуатации LR_NAMED 21 узел является именованным подчиненным устройством LR_WEAK 22 LR_REMOVED 23 управляющее устройство изменилось на управляющее устройство с малой логической силой узел удален из конфигурации LR_DEMOTED 24 LR_DISCONNEXION 25 управляющее устройство с малой логической силой обнаружило управляющее устройство с большой логической силой узел отключен LR_INHIBITED 26 запрет открытия эксплуатации LR_INCLUDED 27 включено в состав LR_LENGTHENING 28 управляющее устройство обнаружило удлинение поезда LR_DISRUPTION 29 узел обнаружил потерю конечного узла LR_MASTER_CONFLICT 30 LR_NAMING_FAILED 31 управляющее устройство с большой логической силой обнаружило еще одно управляющее устройство с большой логической силой ошибка при наименовании LR_NEW_TOPOGRAPHY 32 прием новой топографии LR_NODE_STATUS 33 состояние узла изменилось LR_POLL_LIST_OVF 34 частично действующий LR_ALLOWED 35 открытие эксплуатации разрешено 5.6.4.4 Услуга инициализации 5.6.4.4.1 Процедура ls_t_Init Действие Осуществляет инициализацию канального уровня и задает переменным предопределенные значения. После вызова канальный уровень должен быть готов к приему команд. Эта процедура должна вызываться только один раз после сброса аппаратного обеспечения. Эта процедура зависит от реализации. Синтаксис 5.6.4.5 LS_T_RESULT ls_t_Init (void); Услуга сброса 5.6.4.5.1 Процедура ls_t_Reset Действие Сбрасывает канальный уровень до предопределенных значений. После вызова канальный уровень должен находится в состоянии режима ожидания, готовым к приему команд. Синтаксис LS_T_RESULT ls_t_Reset (void); Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 153 – Услуга конфигурирования 5.6.4.6 5.6.4.6.1 Процедура ls_t_Configure Действие Конфигурирование канального уровня. После вызова узел должен быть готов установить связь. Синтаксис LS_T_RESULT ls_t_Configure ( Type_Configuration * ); p_configuration Указывает на следующую структуру данных конфигурации. Параметр ввода p_configuration 5.6.4.6.2 Type_NodeKey (Тип ключа узла) Структура данных Type_NodeKey (Тип ключа узла) должна включать следующие элементы: Атрибут Тип Значени е node_type UNSIGNED8 тип узла задается приложением node_version UNSIGNED8 версия узла задается приложением ПРИМЕЧЕНИЕ Type_NodeKey представляет собой C-тип, соответствующий структуре Node_Key (Ключ узла) (см. 5.5.2.1). Type_NodeDescriptor (Тип дескриптора узла) 5.6.4.6.3 Структура данных Type_NodeDescriptor (Тип дескриптора узла) должна включать следующие элементы: Атрибут Тип Значени е node_frame_size UNSIGNED8 размер кадра данных процесса в октетах. node_period UNSIGNED8 node_key Type_NodeKey значение периода узла (Node_Period), в 2n кратное основному периоду (период узла равен значению n) см. тип данных. ПРИМЕЧЕНИЕ Type_NodeDescriptor представляет собой C-тип, соответствующий структуре Node_Descriptor (Дескриптор узла) (см. 5.5.2.1). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 154 – 61375-2-1 IEC:2012 Type_Configuration (Тип конфигурация) 5.6.4.6.4 Структура данных Configuration (Конфигурация) должна включать следующие элементы: Атрибут Тип Значение transmission_rate UNSIGNED16 скорость передачи в кбит/с, по умолчанию: 1000 кбит/с basic_period UNSIGNED16 Основной период в миллисекундах, по умолчанию: 25,0 мс fritting_disabled UNSIGNED16 = 1 если сплавление отключено, по умолчанию: 0 node_descriptor Type_NodeDescriptor см. 5.6.4.6.3 poll_md_when_idle UNSIGNED8 =1 если фоновая проверка включена, по умолчанию: 0 (см. 5.4.3.4). 0 (see 5.4.3.4). UNSIGNED16 Максимальное количество портов-приемников, по умолчанию: 22 source_port_count UNSIGNED16 Максимальное количество портов-источников, по умолчанию: 1 port_size UNSIGNED8 Максимальная длина порта в октетах, по умолчанию: 128 p_traffic_store WORD32 Указатель на хранилище трафика, по умолчанию: NULL (НУЛЬ) ls_t_report WORD32 max_number_nodes UNSIGNED8 inaug_data_max_size UNSIGNED8 (124) s_inaug_data_size UNSIGNED8 (124) p_inaug_data_list WORD32 Функция обратного вызова для отчетов, по умолчанию: NULL (НУЛЬ) Максимальное количество узлов, данные открытия эксплуатации которых должны храниться, по умолчанию: 0 Максимальное количество октетов данных открытия эксплуатации, определяемых приложением для отправки, по умолчанию: 0 Фактическое количество октетов данных открытия эксплуатации, определяемых приложением для для отправки, по умолчанию: 0 Указатель на область данных, откуда следует копировать данные открытия эксплуатации, по умолчанию: NULL (НУЛЬ) Type_Inauguration_Data (Тип данных об открытии эксплуатации) 5.6.4.6.5 Структура данных Type_Inauguration_Data (Тип данных об открытии эксплуатации) должна включать следующие элементы: Атрибут Тип Значение inaug_data_max_size UNSIGNED8 (124) максимальное количество октетов данных открытия эксплуатации, определяемых приложением для хранения, по умолчанию: 0 nr_descriptors UNSIGNED8 количество узлов, данные открытия эксплуатации которых должны храниться, по умолчанию: 0 = invalid (недопустимо) node_descriptions ARRAY [nr_descriptors] OF node_type WORD8 список данных открытия эксплуатации, определяемых приложением для каждого узла проводной шины поезда, состоящий из: первая часть Node_Key (Ключа узла) node_version WORD8 вторая часть Node_Key (Ключа узла) sam BOOLEAN1 rsv1 WORD1 (=0) «1», если ориентация совпадает с ориентацией управляющего устройства резервный, = 0 node_address UNSIGNED6 адрес узла, от которого получены данные открытия эксплуатации. inauguration_data_siz e UNSIGNED8 размер Inauguration_Data (Данные открытия эксплуатации) ( 124 октета) inauguration_data ARRAY[inaug_data_len ] OF WORD8 данные открытия эксплуатации, определяемые приложением Дескрипторы узла («node_descriptions») должны быть инициализированы до начала открытия эксплуатации. В конце открытия эксплуатации таблица «node_descriptions» («дескрипторы узла») содержит строки «nr_descriptors», по одной для каждого узла Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.6.4.7 – 155 – Служба установки подчиненного устройства 5.6.4.7.1 Процедура ls_t_SetSlave Действие Предотвращает присвоение узлу статуса управляющего устройства. Синтаксис LS_T_RESULT ls_t_SetSlave (void); 5.6.4.8 Служба установки устройства с малой логической силой 5.6.4.8.1 Процедура ls_t_SetWeak Действие Позволяет узлу стать управляющим устройством с малой логической силой. Синтаксис LS_T_RESULT ls_t_SetWeak (void); 5.6.4.9 Служба установки устройства с большой логической силой 5.6.4.9.1 Процедура ls_t_SetStrong Действие Подает команду узлу стать управляющим устройством с большой логической силой. Синтаксис LS_T_RESULT ls_t_SetStrong (void); ПРИМЕЧАНИЕ Данная команда вызывает открытие эксплуатации. 5.6.4.10 Служба StartNaming (Начать именование) 5.6.4.10.1 Процедура ls_t_StartNaming Действие Подает команду узлу начать открытие эксплуатации. Синтаксис LS_T_RESULT ls_t_StartNaming (void); 5.6.4.11 Служба удаления 5.6.4.11.1 Процедура ls_t_Remove Действие Подает команду узлу удалить себя из конфигурации и перейти в пассивное состояние. Синтаксис LS_T_RESULT ls_t_Remove (void); 5.6.4.12 Служба запрета 5.6.4.12.1 Процедура ls_t_Inhibit Действие Предотвращает удлинение шины при обнаружении дополнительных узлов. Синтаксис LS_T_RESULT ls_t_Inhibit (void); Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 156 – 61375-2-1 IEC:2012 Служба разрешения 5.6.4.13 5.6.4.13.1 Процедура ls_t_Allow Действие Разрешает удлинение шины при обнаружении дополнительных узлов. Синтаксис LS_T_RESULT ls_t_Allow (void); Служба SetSleep (Установить спящий режим) 5.6.4.14 5.6.4.14.1 Процедура ls_t_SetSleep Действие Заставляет узел оповещать о запросе на спящий режим. Синтаксис LS_T_RESULT ls_t_SetSleep (void); Служба CancelSleep (Отменить спящий режим) 5.6.4.15 5.6.4.15.1 Процедура ls_t_CancelSleep Действие Заставляет узел отменить запрос на спящий режим. Синтаксис LS_T_RESULT ls_t_CancelSleep (void); Служба GetStatus (Получить информацию о состоянии) 5.6.4.16 5.6.4.16.1 Процедура ls_t_GetStatus Действие Получает информацию о состоянии физического и канального уровня. Синтаксис LS_T_RESULT ls_t_GetStatus ( p_status ); Type_WTBStatus* указывает на место, куда следует поместить структуру данных WTB_Status (Состояние проводной шины поезда). Параметр ввода p_status 5.6.4.16.2 Type_Node_Status (Тип_состояние узла) Атрибут Тип Значение node_repor BITSET8 ‘C’ объявление соответствует Node_Report (Отчету узла) (5.5.2.2) user_report BITSET8 ‘C’ объявление соответствует Node_Report (Отчету узла) (5.5.2.3) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 157 – Type_WTBStatus (Тип_состояние проводной шины) 5.6.4.16.3 Атрибут Тип Значение wtb_hardware_id UNSIGNED8 идентификация аппаратного обеспечения wtb_software_id UNSIGNED8 идентификация версии ПО канального уровня hardware_state ENUM8 0: LS_OK правильная работа 1: LS_FAIL, отказ аппаратного обеспечения link_layer_state LS_T_STATE см. определение типа net_inhibit ENUM8 node_address UNSIGNED8 node_orient UNSIGNED8 1: запрет открытия эксплуатации некоторыми узлами адрес узла, назначенный в ходе открытия эксплуатации ориентация узла относительно управляющего устройства: 0: L_UNKNOWN 1: L_SAME 2: L_INVERSE node_strength UNSIGNED8 мощность узла 0: L_UNDEFINED 1 L_SLAVE 2: L_STRONG 3: L_WEAK node_descriptor Type_NodeDescriptor см. определение типа node_status Type_Node_Status см. определение типа Служба получения узлов проводной шины поезда 5.6.4.17 5.6.4.17.1 Type_NodeList (Тип_список узлов) Структура данных Type_NodeList (Тип_список узлов) должна включать следующие элементы: Атрибут Тип Значение nr_nodes UNSIGNED8 количество узлов в составе bottom_node UNSIGNED8 адрес конечного узла в направлении_1 от управляющего устройства. Два старших бита данного октета равны 0. top_node UNSIGNED8 адрес конечного узла в направлении_2 от управляющего устройства. Два старших бита данного октета равны 0. node_status_list ARRAY [MAX_NODES] OF список состояний узлов, начиная с нижнего узла, в порядке расположения узлов, и заканчивая верхним узлом, включая: Type_Node_Status см. определение типа node_status Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 158 – 5.6.4.17.2 Процедура ls_t_GetWTBNodes Действие Считывает список отчетов узлов и отчетов пользователя для всех узлов топографии. Синтаксис LS_T_RESULT Type_NodeList * Параметр ввода 5.6.4.18 ls_t_GetWTBNodes ( p_nodes ); указывает место, куда следует поместить список узлов. p_nodes Служба получения топографии 5.6.4.18.1 Процедура ls_t_GetTopography Действие Позволяет приложению считывать распределенную топографию перед началом плановой эксплуатации. Синтаксис LS_T_RESULT Type_Topography * ls_t_GetTopography ( p_topography ); указывает на место, куда следует поместить топографию. Параметр ввода Результат p_topography 5.6.4.18.2 Type_Topography (Тип_топография) возвращает функцию L_CONFIGURATION_INVALID, если топография недопустима. Структура данных топографии должна включать следующие элементы: Атрибут node_address Тип UNSIGNED8 Значение Два старших бита данного октета равны 0. 6 младших бита этого октета являются адресом узла, к которому подключена эта станция. node_orient UNSIGNED8 Ориентация узла относительно управляющего устройства: 0: L_UNKNOWN 1: L_SAME 2: L_INVERSE topo_counter UNSIGNED8 Шесть младших битов копируют шесть бит топографического счетчика узла, два старших бита этого октета равны 0. individual_period UNSIGNED8 Период, выделенный узлу управляющим устройством, равный основному периоду в степени два, в мс. is_strong UNSIGNED8 1: управление шиной управляющим устройством с большой логической силой, 0: управление шиной управляющим устройством с малой логической силой, number_of_nodes UNSIGNED8 количество узлов в соответствии с результатом открытия эксплуатации bottom_address UNSIGNED8 Адрес конечного узла в направлении_1 от управляющего устройства, два старших бита этого октета равны 0. top_address UNSIGNED8 Адрес конечного узла в направлении_2 от управляющего устройства, два старших бита этого октета равны 0. inauguration_data Type_Inauguratio n_Dat a см. определение типа Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 5.6.4.19 – 159 – Служба изменения дескриптора узла 5.6.4.19.1 Процедура ls_t_ChgNodeDesc Действие Предоставляет новый дескриптор для канального уровня. Вызов этой процедуры во время плановой эксплуатации приводит к нарушению трафика и новому распределению топографии. Синтаксис LS_T_RESULT Type_NodeDescriptor * Параметр ввода 5.6.4.20 node_descriptor ls_t_ChgNodeDesc ( node_descriptor ); указывает на структуру данных дескриптора узла (Node_Descriptor) Служба изменения отчета пользователя 5.6.4.20.1 Процедура ls_t_ChgUserReport Действие Позволяет приложению изменить отчет пользователя. Синтаксис LS_T_RESULT UNSIGNED8 UNSIGNED8 Параметр ввода set_mask clear_mask 5.6.4.21 ls_t_ChgUserReport ( set_mask clear_mask ); устанавливает в отчете пользователя биты, для которых в маске задано 1. удаляет в отчете пользователя биты, для которых в маске задано 1. Служба изменения данных открытия эксплуатации 5.6.4.21.1 Процедура ls_t_ChgInauguration_Data Действие Разрешает приложению изменить данные открытия эксплуатации узла Синтаксис LS_T_RESULT UNSIGNED8 oid* Параметр ввода ls_t_ChgInauguration_ Data ( inaug_data_size p_inauguration ); Iinaug_data_size Размер октета данных открытия эксплуатации (≤ 124) p_inauguration данные открытия эксплуатации, определяемые пользователем Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 160 – 61375-2-1 IEC:2012 Служба получения статистки 5.6.4.22 5.6.4.22.1 Процедура ls_t_GetStatistics Действие Предоставляет статистическую информацию об использовании и ошибках Синтаксис LS_T_RESULT Параметр ввода p_statistic_data 5.6.4.22.2 Type_LineStatus (Тип_состояние линии) ls_t_GetStatistics ( Type_LLStatisticData * p_statistic_data ); указывает структуру статистических данных (см. 5.6.4.22.3) Структура данных Type_LineStatus (Тип_состояние линии) должна включать следующие элементы: Атрибут Тип Значение transmitted_count UNSIGNED32 Количество кадров, передаваемых этим узлом received_count UNSIGNED32 errors_count UNSIGNED16 Количество кадров, полученных узлом без ошибок в данном узле Количество полученных ошибочных кадров timeouts_count UNSIGNED16 Количество истекших тайм-аутов в процессе ожидания ответа ПРИМЕЧАНИЕ Эти счетчики зацикливаются при достижении максимального значения, их начальное значение не указано. 5.6.4.22.3 Type_LLStatisticData (Тип_статистические данные логического канала) Структура данных Type_LLStatisticData (Тип_статистические данные логического канала) должна включать следующие элементы: Атрибут Тип Значение basic_period_count UNSIGNED32 увеличивается для каждого основного периода inauguration_count UNSIGNED16 topography_count UNSIGNED16 увеличивается для каждого нового открытия эксплуатации увеличивается для каждой новой топографии transmitted_md_count UNSIGNED32 received_md_count UNSIGNED32 line_status_a1 Type_LineStatus См. тип line_status_a2 Type_LineStatus См. тип line_status_b1 Type_LineStatus См. тип line_status_b2 Type_LineStatus См. тип line_switch_count UNSIGNED32 увеличивается при каждом переключении на резервную линию. увеличивается при каждом оправленном ответе по данным сообщения увеличивается при каждом полученном ответе по данным сообщения ПРИМЕЧАНИЕ Эти счетчики зацикливаются при достижении максимального значения, их начальное значение не указано. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 161 – Служба получения данных открытия эксплуатации 5.6.4.23 Действие Возврат указателя на данные открытия эксплуатации Синтаксис LS_T_RESULT ls_t_GetInaugData ( p_inaug_data_list ); void * * Параметр вывода 6 указывает на данные открытия эксплуатации всех именованных узлов p_inaug_data_list Протоколы реального времени Данный раздел применяется к сети поездной связи, использующей проводную шину поезда и/или многофункциональную поездную шину и/или любую другую шину, которая подчиняется тем же принципам работы. Общие положения 6.1 6.1.1 Содержание данного раздела В данном разделе представлен один компонент сети поездной связи, протоколы реального времени, которые обеспечивают связь между приложениями внутри составов и между составами, как показано на Рисунке 107. шина поезда Шина ТС узел сеть ж/д состава монтажная шина сеть ж/д состава Рисунок 107 - Структура сети поездной связи Данный раздел включает информацию о двух основных службах связи для приложения: a) Переменные: передача коротких пакетов данных с детерминированной задержкой доставки, в том числе Интерфейс данных процесса канального уровня (LPI); Интерфейс прикладного уровня для переменных (AVI); b) Сообщения: передача максимально длинных, но редко встречающихся элементов данных, разделенных при необходимости на небольшие пакеты и передаваемых по запросу, включая: Интерфейс данных сообщения канального уровня (LMI); Маршрутизация сетевого уровня, используемая для маршрутизации пакетов в сети; Транспортный уровень, который обеспечивает управление потоком и устранение ошибок, – для двухточечных или – для многоадресных сообщений (дополнительно), сеансовый уровень, который объединяет Call_Message (Сообщение вызова) и Reply_Message (Ответное сообщение); Интерфейс прикладного уровня для сообщений (AMI); Данный раздел также включает информацию о представлении данных (для переменных и сообщений). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 162 – 6.1.2 61375-2-1 © IEC:2012 Структура данного раздела Структура данного раздела аналогична модели связи OSI, как показано на Рисунке 108. Переменные AVI Сообщения интерфейс прикладного уровня AMI Адаптер переменных приложения (AVA) Адаптер прикладных сообщений (AMA) одноадресный Прикладной уровень многоадресный Протоколы реального времени (представление) сеанс Интерфейс транспортного уровня пусто транспорт LPI интерфейс канального Данные процесса уровня (LPA) LMI Данные сообщения Порты (LMA) Очереди физический Канальный уровень характерно для каждой шины сеть Рисунок 108 - Структура протоколов реального времени Подраздел 6.1 Общие положения Нормативные требования и определения Подраздел 6.2 Службы и протоколы переменных Объекты Process_Variable (Переменные процесса) Интерфейс набора данных Прикладной интерфейс для доступа к отдельным переменным, наборам переменных и кластерам переменных Подраздел 6.3 Службы и протоколы сообщений Архитектура Интерфейс канального уровня Сетевой уровень Транспортный уровень Сеансовый уровень Прикладной интерфейс Подраздел 6.4 Представление и кодирование передаваемых и хранящихся данных Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 163 – Службы и протоколы переменных 6.2 Общие положения 6.2.1 Службы и протоколы разделены на нижний интерфейс и верхний интерфейс: a) нижний интерфейс канального уровня, который определяет услуги, ожидаемые от шины; а также b) интерфейс прикладного уровня определяет услуги, предоставляемые приложению. 6.2.2 6.2.2.1 Интерфейс канального уровня для данных процесса Цель Интерфейс данных процесса канального уровня (LPI) определяет услуги данных процесса, предоставляемые шиной для высокоуровневых протоколов. Интерфейс данных процесса канального уровня (LPI) определяет инициализацию портов, включение в порты и удаление целых наборов данных, а также примитивы синхронизации, связанные с передачей целых наборов данных. Приложение обычно не обращается к интерфейсу данных процесса канального уровня (LPI) напрямую, за исключением синхронизации (для получения информации о приеме или передаче наборов данных). Базовая связь не определяется этим интерфейсом. Передача между портами, включая стратегию опроса управляющего устройства шины, реализуется канальным уровнем и физическим уровнем. ПРИМЕЧАНИЕ Отдельные переменные процесса не отображаются на уровне LPI. 6.2.2.2 6.2.2.2.1 Набор данных Порты и хранилище трафика Канальный уровень должен предоставить несколько портов для передачи данных процесса. Порт представляет собой структуру общей памяти, доступ к которой может осуществляться одновременно приложением и сетью. Порт представляет собой структуру данных без очереди, это означает, что его содержимое перезаписывается новым записанным значением и не затрагивается операцией считывания. Канальный уровень, а также приложение должны иметь возможность бесперебойного доступа к порту, т.е. записи или считывания всех его данных за одну неделимую операцию. Порты, принадлежащие одному и тому же канальному уровню, принадлежат одному и тому же хранилищу трафика. Идентификация порта в хранилище трафика должна осуществляться по адресу его порта. Идентификация хранилища трафика в устройстве должна осуществляться по идентификатору хранилища трафика (Traffic_Store_Id). 6.2.2.2.2 Согласованность набора данных Каждый пори должен содержать ровно один набор данных. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 164 – 61375-2-1 IEC:2012 Набор данных должен создаваться только одним приложением Publisher (Публикатор). На шине должен быть только один порт-источник с данным адреса порта, но может быть неопределенное количество портов-приемников. Канальные уровни различных устройств в течение ограниченного времени должны передавать содержимое порта-источника на порты-приемники, подписанные на один и тот же адрес порта, и обеспечивать согласованность передаваемых наборов данных. ПРИМЕЧАНИЕ Предполагается, что шина не гарантирует, что различные наборы данных могут передаваться или извлекаться в качестве согласованного набора. 6.2.2.2.3 Обработка ошибок Неопределенные поля в наборе данных должны быть перезаписаны со значением «1». Если канальный уровень не может гарантировать согласованность набора данных, например, если он обнаруживает, что произошла ошибка передачи или что его приложение Publisher (Публикатор) не может предоставить правильные или своевременные данные, канальный уровень должен перезаписать весь порт со значением «0». ПРИМЕЧАНИЕ Поскольку перезапись значения переменной процесса со всеми «0» или «1» может выдать допустимое значение, контрольная переменная того же набора данных используется в качестве индикатора достоверности в том случае, когда это может являться проблемой. 6.2.2.2.4 Контроль новизны Каждый порт приемника и, следовательно, каждый набор данных с подпиской должен иметь связанный с ним таймер новизны (Freshness_Timer), который указывает время, прошедшее с момента записи шиной нового значения в этот порт. Этот таймер новизны (Freshness_Timer) должен быть извлечен в неделимой операции вместе с содержимым набора данных. Разрешение таймера новизны (Freshness_Timer) должно составлять не более 16 мс. Его диапазон должен составлять не менее 4 с, и он должен останавливаться при достижении конца диапазона. ПРИМЕЧАНИЕ 1 Таймер Freshness_Timer не учитывает, когда приложение Publisher (Публикатор) вставляет переменную процесса в порт. Контроль времени источника является проблемой приложения, которую можно решить с помощью контрольных переменных. ПРИМЕЧАНИЕ 2 Таймер Freshness_Timer не зависит от возможной принудительной установки переменных. 6.2.2.2.5 Набор данных для синхронизации Широковещательная передача заданных наборов данных может использоваться для синхронизации приложений. 6.2.2.2.6 Опрос наборов данных Процедуры, относящиеся к опросу набора данных, являются частью канального уровня сети состава и поездной шины соответственно. В настоящем стандарте они не представлены. 6.2.2.2.7 6.2.2.2.7.1 Идентификатор набора данных (DS_Name) Набор данных, порт и логический адрес Внутри устройства идентификация набора данных должна осуществляться посредством его хранилища трафика и адресом порта хранилища трафика, в котором хранится набор данных. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 165 – При передаче по шине идентификация набора данных должна осуществляться посредством логического адреса его кадра данных процесса на этой шине. Логический адрес кадра данных процесса должен быть идентичен адресу порта хранилища трафика, где хранится набор данных. Формат DS_Name (Имя набора данных) 6.2.2.2.7.2 Идентификация набора данных в устройстве должна осуществляться по имени набора данных (DS_Name). Тип набора данных Определение Синтаксис typedef struct /* представление от старшего к младшему */ { unsigned traffic_store_id:4, /* первая часть DS_NAME */ адрес порта баз знака :12, /* вторая часть DS_NAME */ } DS_NAME; Имя набора данных (DS_Name) может быть представлено 16-битным словом следующим образом: 15 14 13 12 11 10 Traffic_store_id (Идентификатор хранилища трафика) 6.2.2.2.7.3 9 8 7 6 5 4 3 2 1 0 port_address (адрес порта) Идентификатор хранилища трафика Идентификатор хранилища трафика (Traffic_Store_Id) должен выбрать одно хранилище трафика в устройстве. Максимальное количестве поддерживаемых хранилищ трафика должно составлять шестнадцать. ПРИМЕЧАНИЕ 1 Идентификатор хранилища трафика не указывает, к какому типу шины (многофункциональной поездной шине, проводной шине поезда или другой) осуществляется доступ, но в этом случае реализация может быть упрощена (например, хранилище трафика проводной шины поезда всегда может быть равно «1»). ПРИМЕЧАНИЕ 2 Идентификатор хранилища трафика может быть идентичен идентификатору соответствующей шины (Bus_Id). Однако могут существовать хранилища трафика без подключенной шины, например, для межзадачной коммуникации. 6.2.2.2.8 Адрес порта Адрес порта должен идентифицировать один из 4096 портов в хранилище трафика, выбранных с помощью идентификатора хранилища трафика (Traffic_Store_Id). ПРИМЕЧАНИЕ Фактическое возможное количество портов зависит от типа подключенной шины. ПРИМЕР На многофункциональной поездной шине может быть до 4096 портов размером до 256 бит каждый на устройство. 6.2.2.3 6.2.2.3.1 Примитивы интерфейса данных процесса канального уровня Общие положения Интерфейс данных процесса канального уровня (LPI) должен предоставлять примитивы для доступа к набору данных, представленные на Рисунке 109 и перечисленные в Таблице 18, как указано в следующих подразделах. Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 166 – Публикатор Канальный уровень Канальный уровень Абонент Передача набора данных Рисунок 109 - Обмен примитивами LPI Таблица 18 - Примитивы LPI Имя Значение lp_init Инициализирует хранилища трафика lp_put_dataset, Вставляет набор данных для отправки lp_get_dataset. получает принятый набор данных ds_subscribe, ap_event Предоставляет подписку на набор данных для синхронизации Синхронизация при передаче или приеме ds_desubscribe, Аннулирует подписку на набор данных для синхронизации ПРИМЕЧАНИЕ 1 Приложение может напрямую обращаться к структурам хранилища трафика, а не использовать эти примитивы для ускорения доступа. ПРИМЕЧАНИЕ 2 Процессор связи может использовать те же примитивы для доступа к хранилищу трафика со стороны шины. ПРИМЕЧАНИЕ 3 Эти примитивы не запускают немедленную связь по шине, а имеют доступ только к хранилищу трафика. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.2.2.3.2 – 167 – Тип «LP_RESULT» Определение Процедура интерфейса данных процесса канального уровня (LPI), которая возвращает значение типа LP_RESULT, должна кодировать его следующим образом: Синтаксис typedef enum { LP_OK = 0, /* правильное завершение */ LP_PRT_PASSIVE = 1, /* предупреждение: Набор данных не активен */ LP_ERROR = 2, /* неустановленная ошибка */ LP_CONFIG = 3, /* ошибки конфигурации */ LP_MEMORY = 4, /* Не достаточно памяти */ LP_UNKNOWN_TS = 5, /* неизвестное хранилище трафика */ LP_RANGE = 6, /* ошибка адреса памяти */ LP_DATA_TYPE = 7 /* неподдерживаемый тип данных */ } LP_RESULT; 6.2.2.3.3 Процедура «lp_init» Определение Создает хранилище трафика, задает список подписок, создает порты источника и приемника и инициализирует их посредством определенного значения. Синтаксис LP_RESULT ENUM8 void * Параметр ввода ts_id p_descriptor Любое значение LP_RESULT Возврат 6.2.2.3.4 Определение lp _init ( ts_id p_descriptor ); Идентификатор хранилища трафика (Traffic_Store_Id) (0..15) Структура данных, зависящая от реализации. Процедура «lp_put_dataset» Копирует набор данных из приложения в порт в хранилища данных. Синтаксис LP_RESULT DS_NAME * void * Параметр ввода dataset p_value Возврат lp_put_dat aset ( dataset; p_value ); Имя набора данных (DS_Name) должно быть опубликовано указывает на область памяти приложения, из которой копируется значение набора данных. Любое значение LP_RESULT Использован Предыдущее значение набора данных в в хранилище трафика перезаписывается. ие Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 168 – 6.2.2.3.5 61375-2-1 IEC:2012 Процедура «lp_get_dataset» Определен Копирует набор данных и его таймер Freshness_Timer из порта в приложение. ие Синтаксис LP_RESULT lp_get_dataset ( DS_NAME * dataset; void * p_value; void * p_fresh ); Имя набора данных (DS_Name) должно быть получено. Параметр ввода Возврат dataset Параметр вывода p_value Указывает на адрес памяти приложения, в которую копируется значение набора данных. p_fresh Указывает на адрес памяти приложения, в которую копируется таймер Freshness_Timer. 6.2.2.3.6 Определение Любое значение LP_RESULT Процедура «ds_subscribe» Предоставляет подписку на набор данных для передачи или приема и указывает, какая процедура индикации вызывается в случае передачи или приема указанного набора данных. Синтаксис LP_RESULT DS_NAME * DS_EVENT UNSIGNED16 Параметр ввода dataset Возврат Ds_sub scribe ( dataset; event_cnf; instance ); Имя набора данных (DS_Name) должно быть включено в подписку. event_cnf Процедура подписки instance 16-битный ссылочный номер, который предназначен для идентификации подписывающего экземпляра приложения и будет возвращен в процедуру ds_event. Любое значение LP_RESULT Использование 1 - Эта процедура может быть вызвана несколько раз до ограничений, установленных в ходе реализации для разных наборов данных и процедур подписки. 2 - Подписка на один и тот же набор данных может быть сделана один раз. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 169 – Тип «DS_EVENT» 6.2.2.3.7 Определение Синтаксис Когда набор данных отправлен или получен, канальный уровень должен вызвать процедуру, подписанную на этот набор данных и имеющую тип «DS_EVENT». typedef void ( * DS_EVENT) ( instance ); UNSIGNED16 Параметр ввода instance 16-битный ссылочный номер, который предназначен для идентификации экземпляра приложения с подпиской на данное событие. Использовани 1 - Подписка на данную процедуру должна быть сделана заранее посредством е «ds_subscribe». 2 - Набор данных, вызвавший событие, не идентифицируется, но для этой цели можно использовать параметр экземпляра. Процедура «ds_desubscribe» 6.2.2.3.8 Определение Синтаксис Удаляет набор данных из подписки. LP_RESULT Ds_desubscribe ( dataset; ); DS_NAME * Параметр ввода dataset Любое значение LP_RESULT Возврат 6.2.3 6.2.3.1 Имя набора данных (DS_Name) должно быть удалено из подписки Интерфейс приложения для переменных процесса Цель Интерфейс переменных приложения предлагаемые приложению. (AVI) определяет услуги передачи переменных, Примитивы этого интерфейса имеют доступ только к портам в хранилищах трафика и не запускают связь по шине. Предполагается, что включение переменной в порт публикатором через ограниченное время приведет к включению той же переменной в соответствующий порт абонента(-ов). 6.2.3.2 6.2.3.2.1 Переменные процесса Передача и хранение переменных процесса Переменные процесса передаются как часть набора данных. Все переменные процесса, принадлежащие набору данных, должны передаваться и храниться как согласованный набор. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 170 – 6.2.3.2.2 61375-2-1 IEC:2012 Контроль новизны Переменная процесса должна быть извлечена с помощью таймера Freshness_Timer своего набора данных в ходе неделимой операции. 6.2.3.2.3 Синхронизация Приложение может быть синхронизировано путем передачи набора данных через интерфейс данных процесса канального уровня (LPI). 6.2.3.2.4 Контрольная переменная Чтобы оценить ее достоверность, каждая переменная может быть связана с другой переменной, относящейся к тому же набору данных, которая называется контрольная переменная. Хранение и извлечение контрольной переменной и переменной процесса должно осуществляться в ходе неделимой операции. Одна и та же контрольная переменная может применяться к нескольким переменным процесса. Контрольная переменная может находиться в любом месте набора данных и может перекрывать переменную процесса. Check_Variable, если она используется, должна иметь формат ANTIVALENT2 (АНИТВАЛЕНТНЫЙ2) и принимать следующие значения: a) 00’B: защищенные переменные ошибочны или подозрительны; b) 01’B: защищенные переменные считаются правильными; c) 10’B: защищенным переменным были принудительно заданы значения; d) 11’B: защищенные переменные не определены ПРИМЕЧАНИЕ 1 Слово «Переменная» будет использоваться, если не указано, является ли она переменной процесса или контрольной переменной. ПРИМЕЧАНИЕ 2 приложения. Распределение переменных процесса и контрольных переменных в наборе данных является проблемой ПРИМЕЧАНИЕ 3 Ожидается, что шина или публикатор перезапишут подозрительные поля в наборе данных с использованием значения «0». При этом для двух битов контрольной переменной будет установлено ‘00’B, позволяя приложению обнаружить ошибку. ПРИМЕЧАНИЕ 4 Поле, зарезервированное для будущего расширения, должно быть перезаписано с использованием значения «1». При этом для контрольных переменных, которые поле когда-либо будет содержать, будет установлено ‘11’B, что позволяет более новым устройствам не принимать за ошибку значение «1» в случае допустимых данных, при получении их от более старых устройств. ПРИМЕЧАНИЕ 5 Ожидается, что приложение будет обрабатывать две ситуации, которые могут возникнуть в результате проблем со связью (все «0») или в результате того, что данные недопустимы (все «1»). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 171 – ПРИМЕР На Рисунке 110 представлена переменная процесса и связанная с ней контрольная переменная в одном и том же наборе данных. Переменная процесса ошибка Контрольная переменная xxxxxxxx 00 правильно 0 1 0 1 1 1 0 0 0 1 принудительно 1 0 0 0 1 1 0 1 1 0 не определено x x x x x x xx 11 Набор данных Рисунок 110 -Контрольная переменная 6.2.3.2.5 Идентификатор переменной процесса (PV_Name) 6.2.3.2.5.1 Идентификатор переменной и набора данных Внутри устройства переменная процесса должна быть идентифицирована своим набором данных (DS_Name) и своим сдвигом в битах в этом наборе данных (Var_Offset). При передаче по шине переменная процесса должна быть идентифицирована своим логическим адресом и сдвигом в битах в пределах передаваемого набора данных (Var_Offset). 6.2.3.2.5.2 Формат PV_Name (Имя переменной процесса) Внутри устройства каждая переменная процесса должна быть идентифицирована уникальным идентификатором, называемым имененм переменной процесса (PV_Name), состоящим из следующих элементов: a) b) c) d) e) f) Traffic_store_id (Идентификатор хранилища трафика); Port_Address (Адрес порта); Var_Offset (Сдвиг переменной); Var_Size (Размер переменной); Var_Type (Тип переменной); Chk_Offset (Сдвиг контрольной переменной). ПРИМЕЧАНИЕ Имя переменной процесса (PV_Name) для одной и той же переменной на одной и той же шине может отличаться своим идентификатором хранилища трафика (Traffic_Store_Id) от устройства к устройству, поскольку идентификатор Traffic_Store Identifier может отличаться. 6.2.3.2.5.3 Идентификатор хранилища трафика Идентификатор хранилища трафика (Traffic_Store_Id) должен идентифицировать одно из 16 хранилищ трафика в устройстве. 6.2.3.2.5.4 Адрес порта Адрес порта (Port_Address) должен идентифицировать один из 4096 портов в хранилище трафика . Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 172 – 6.2.3.2.5.5 61375-2-1 IEC:2012 Сдвиг переменной (Var_Offset) Если бы набор данных будет содержать целое беззнаковое число, его старший бит должен быть со сдвигом 0. Сдвиг переменной (Var_Offset) должен определять сдвиг в битах с начала набора данных, начала поля, занятого значением переменной процесса. Переменная процесса должна располагаться в сдвиге переменной, который кратен ее размеру. ПРИМЕЧАНИЕ Выравнивание является разрешенным отклонение для компиляторов, которые не могут получить доступ к структурам данных, выходящим за границу слова. 6.2.3.2.5.6 Тип переменной (Var_Type) и размер переменной (Var_Size) Тип переменной (Var_Type) и размер переменной (Var_Size) должны однозначно идентифицировать формат переменной процесса, «Var_Type» указывает тип, как указано в 6.4, а «Var_Size» размер. Кодировка «Var_Size» и «Var_Type» должна быть выполнена в соответствии с представленным в Таблице 19. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 173 – Таблица 19 - Кодирование Var_Size (Размер переменной) и Var_Type (Тип переменной) в PV_Name Var_Size Тип данных Var_Type 0 1 0 BOOLEAN1 1 ANTIVALENT2 2 BCD4 или ENUM4 3 резервный 4 BITSET8 5 UNSIGNED8 A1Y ENUM8 6 INTEGER8 7 CHARACTER8 (ARRAY [0..0] OF WORD8) 4 BITSET16 5 UNSIGNED16 или ENUM16 6 INTEGER16 8 BIPOLAR2.16 (200 %) 9 UNIPOLAR2.16 (+400 %) 10 BIPOLAR4.16(800 %) 2 3 REAL32 4 BITSET32 5 UNSIGNED32 или ENUM32 6 INTEGER32 3 2 TIMEDATE48 4 4 BITSET64 5 UNSIGNED64 6 INTEGER64 7 ARRAY OF WORD8 (нечетное число октетов) n-1 15 ARRAY OF WORD8 (четное число октетов) 13 ARRAY OF UNSIGNED16 (n = размер массива в WORD16) 14 ARRAY OF INTEGER16 11 ARRAY OF UNSIGNED32 (n = размер массива в WORD16) 12 ARRAY OF INTEGER32 «Var_Size» («Размер переменной») интерпретируется по-разному в структурированных и примитивных типах: в примитивных типах «Var_Size» указывает количество используемых 16-битных слов; в структурированных типах «Var_Size» указывает количество 16-битных слов минус 1; ПРИМЕЧАНИЕ 1 В примитивных типах Var_Size = 0 меньше одного WORD16 (16-битное слово), Var_Size = 1 означает одно WORD16 (16-битное слово). ПРИМЕЧАНИЕ 2 В структурированных типах Var_Size = 0 означает одно WORD16 (16-битное слово). ПРИМЕЧАНИЕ 3 Множитель «n» представляет собой WORD16. Таким образом, максимальный размер переменной составляет 128 октетов (64 16 = 1024 бита), при этом Var_Size равен '3F'H. ПРИМЕЧАНИЕ 4 Коды, не указанные в Таблице 19, зарезервированы. ПРИМЕЧАНИЕ 5 Хотя триплет значений {Traffic_Store (Хранилище трафика), Port_Address (Адрес порта), Var_Offset (Сдвиг переменной)} однозначно идентифицирует перменную процесса, имя PV_Name включает информацию о типе/размере для быстрого преобразования между типами данных сети и приложения. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 174 – 61375-2-1 IEC:2012 Сдвиг контрольной переменной (Chk_Offset). 6.2.3.2.5.7 Сдвиг контрольной переменной (Chk_Offset) должен определять положение контрольной переменной, связанной с переменной процесса, по отношению к началу набора данных. Сдвиг контрольной переменной (Chk_Offset) , соответствующий крайней правой позиции в наборе данных ('0FFF'H), должен использоваться, когда переменная процесса не имеет связанной с ней контрольной переменной. 6.2.3.3 Примитивы интерфейса переменных приложения 6.2.3.3.1 Общие положения Примитивы интерфейса переменных процесса (AVI) делятся на три группы: a) Доступ к отдельным переменным; b) Доступ к набору переменных; c) Доступ к кластеру переменных; Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. 6.2.3.3.2 Тип «AP_RESULT» Процедура интерфейса переменных приложения (AVI), которая возвращает значение, должна кодировать его следующим образом: Определение Синтаксис Typedef enum { AP_OK = 0, /* правильное завершение AP_PRT_PASSIVE = 1, /* предупреждение: Набор данных не активен AP_ERROR = 2, /* общая ошибка AP_CONFIG = 3, /* произошла ошибка конфигурации AP_MEMORY = 4, /* недостаточно памяти для завершения AP_UNKNOWN_TS = 5, /* неизвестное хранилище трафика AP_RANGE = 6, /* ошибка адреса памяти AP_DATA_TYPE = 7 /* неподдерживаемый тип данных } AP_RESULT; ПРИМЕЧАНИЕ Кодирование этих постоянных идентично постоянным LPI с аналогичным названием. 6.2.3.3.3 Параметры конфигурации AP_TS_ID_MAX 6.2.3.3.4 0..15 Максимальное количество хранилищ трафика, поддерживаемое в ходе реализации = AP_TS_ID_MAX + 1 Инициализация переменных Инициализация переменных процесса выполняется механизмом инициализации набора данных для всех наборов данных, который зависит от приложения. ПРИМЕЧАНИЕ Ожидается, что канальный уровень по умолчанию инициализирует все наборы данных со значением «0». 6.2.3.3.5 Примитивы доступа к отдельным переменным Интерфейс прикладного уровня для переменных (AVI) должен предоставлять для доступа к отдельным переменным следующие примитивы, представленные на Рисунке 111 и указанные в следующих подразделах: a) ap_put_variable, Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 b) ap_get_variable, c) ap_force_variable, d) ap_unforce_variable, e) ap_unforce_all. – 175 – Приложение публикатора Приложение абонента местный замещающий экземпляр ap_put lp_init Местный экземпляр ap_force Замещающий экземпляр таймер freshness_timer ap_force ap_get lp_init ap_unforce ap_unforce портприемн ик портисточн ик Хранилище трафика Хранилище трафика передача Рисунок 111 - Доступ к отдельным переменным 6.2.3.3.5.1 Тип PV_NAME (Имя переменной процесса) Для доступа к отдельным переменным Var_Offset (Сдвиг переменной) и Chk_Offset (Сдвиг контрольной переменной) должны состоять из двух полей: Var_Octet_Offset (Сдвиг октета переменной) и Var_Bit_Number (Количество битов переменной). Var_Octet_Offset представляет сбой сдвиг октета по отношению к началу набора данных, причем первый переданный или сохраненный октет равен октету 0. В переменных, состоящих из нескольких октетов, Var_Bit_Number всегда равен 0. В переменных меньше одного октета Var_Bit_Number представляет собой количество битов, на которое переменная должна быть сдвинута вправо для выравнивания по правому знаку в октете. Var_Bit_Number не совпадает со сдвигом битов в пределах октета. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 176 – Тип индивидуальных переменных процесса Определение Синтаксис typedef struct /* представление от старшего к младшему */ { unsigned traffic_store_id:4, /* первая часть DS_NAME */ unsigned port_address :12, /* вторая часть DS_NAME */ unsigned va */ unsigned var_bit_number :3, /* отсчет справа */ unsigned port_address :12, /* unsigned var_size :6, /* как представлена в Таблице 19 */ unsigned chk_octet_offset:7, /* первый октет имеет сдвиг 0 */ unsigned chk_bit_number :3, /* отсчет справа */ } PV_NAME; Имя переменной процесса (PV_Name) может быть закодировано следующим образом: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 port_address (адрес порта) Traffic_store_id (Идентификатор хранилища трафика) var_size (размер переменной) var_octet_offset (сдвиг октета переменной) var_type (тип переменной) chk_octet_offset (сдвиг октета контрольной переменной) var_bit_number (число битов переменной) chk_bit_number (число битов контрольной переменной) ПРИМЕЧАНИЕ Определение Var_Bit_Number (Число битов переменной) было введено для ускорения доступа к отдельным переменным и, в частности, для предотвращения добавления или вычитания восьми, чтобы воспользоваться преимуществами команды сдвига в процессорах. Данная декомпозиция возможна только в том случае, если все типы данных выровнены, например, тип ANTIVALENT2 не может иметь нечетный сдвиг. ПРИМЕР Следующий дамп памяти представляет имя PV_Name: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 1 1 0 0 0 1 1 0 1 1 1 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 0 0 Данное имя PV_Name идентифицирует переменную процесса, которая: находится в хранилище трафика 3, по адресу порта 'BA'H (= 442), с битовым сдвигом '0F8'H (31 8 = 248) бит он имеет тип INTEGER8 (var_size = 0 WORD16, var_type = 6); связанная с ней 2-битовая контрольная переменная расположена по сдвигу октета 0, номер бита 4, т.е. она расположена в 3-м и 4-м битах набора данных (битый сдвиг 2 и 3). Если бы это число будет нечетным, то оно не будет связанно контрольной переменной. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.2.3.3.5.2 – 177 – Процедура ap_put_variable Копирует отдельную переменную процесса и связанную с ней контрольную переменную из пространства Application Memory_Address (Адрес памяти приложения) в хранилище данных. Определение Синтаксис AP_RESULT PV_NAME* void * void * Параметр ввода ap_put_variable ( ts_variable, p_value, p_check ); ts_variable Имя PV_Name переменной процесса p_value указывает на область памяти приложения, из которой копируется публикуемое значение. p_check указывает на область памяти приложения, из которой копируется контрольная переменная. Любое значение AP_RESULT Возврат Использование 1 – Если переменная процесса была принудительно задана, переменная ap_put_variable не оказывает влияния. 2 – Прежнее значение переменной процесса переписывается. 3 – Другие данные того же набора данных не затрагиваются, но согласованность с ними не гарантируется. 6.2.3.3.5.3 Процедура ap_get_variable Определение Копирует переменную процесса, ее таймер Freshness_Timer и контрольные переменные из хранилища трафика в приложение. Синтаксис AP_RESULT PV_NAME* void * void * void * Параметр ввода Возврат Использование ap_get_ variable ( ts_variable, p_value, p_check, p_fresh ); ts_variable Имя PV_Name переменной процесса p_value указывает на область памяти приложения, куда помещается полученное значение. p_check указывает на область памяти приложения, куда помещается соответствующая контрольная переменная p_fresh указывает на область памяти приложения, куда помещается соответствующий таймер Freshness_Timer. Любое значение AP_RESULT 1 – Этот примитив можно использовать с портом-источником или приемником, чтобы позволить абонентам находиться на одном устройстве с публикатором. 2 – Если переменная процесса была принудительно задана, извлекается принудительно присвоенное значение. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 178 – 6.2.3.3.5.4 61375-2-1 IEC:2012 Процедура ap_force_variable Определен Принудительно присваивает заданное значение отдельной переменной процесса для порта; присваивает соответствующей контрольной переменной ие значение ‘10’B. Синтаксис AP_RESULT ap_force_variable ( PV_NAME * ts_variable, void * p_value ); Параметр ввода ts_variable Имя PV_Name переменной процесса p_value указывает на область памяти приложения, из которой копируется принудительно присвоенное значение. Любое значение AP_RESULT Возврат Использова Ожидается, что замещающее значение будет иметь тип, совместимый с типом имени PV_NAME. ние 6.2.3.3.5.5 Процедура ap_unforce_variable Определен Прекращает принудительное присвоение переменной и восстанавливает нормальный доступ к ней через шину; не изменяет соответствующую ие контрольную переменную. Синтаксис AP_RESULT ap_unforce_variable ( PV_NAME * ts_variable ); Параметр ввода Возврат 6.2.3.3.5.6 ts_variable Имя PV_Name переменной процесса Любое значение AP_RESULT Процедура ap_unforce_all Определен Прекращает замещение всех переменных хранилища данных, не изменяет соответствующие контрольные переменных. ие Синтаксис AP_RESULT ENUM8 ap_unforce_all ( ts_id ); Идентификатор хранилища трафика (Traffic_Store_Id) (0..15) Параметр ввода Возврат ts_id 6.2.3.3.6 Процедуры доступа к набору переменных 6.2.3.3.6.1 Режим доступа к набору переменных Любое значение AP_RESULT Набор представляет собой группу переменных (переменные процесса (Process_Variables) и контрольных переменных (Check_Variables)), принадлежащих одному и тому же набору данных и обрабатываемых как единое целое для сохранения согласованности и новизны информации. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 179 – Интерфейс прикладного уровня для переменных (AVI) должен предоставлять для доступа к набору переменным следующие примитивы, представленные на Рисунке 112 и указанные в следующих подразделах: a) ap_put_set, b) ap_get_set. набор перем. процесса публикатора PV Приложение публикатора Приложение абонента набор перем. процесса абонента adr PV adr таймер freshness_timer ap_put_set ap_get_set AVA AVA портисточник портприемн ик Хранилище трафика Хранилище трафика передача Рисунок 112 - Доступ к набору переменных ПРИМЕЧАНИЕ Доступ к набору переменных является согласованным, т.е. все переменные копируются и ни одна не используется в неделимой операции. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 180 – 6.2.3.3.6.2 Определение Синтаксис Тип PV_SET PV_Set определяет набор переменных, принадлежащих к одному и тому же набору данных, включая адрес памяти для каждой переменной, куда (или откуда) она должна быть скопирована, и включая для всего набора данных значение Freshness_Timer ( Таймер новизны). typedef struct void* UNSIGNED8 UNSIGNED8 UNSIGNED8 UNSIGNED8 typedef struct PV_LIST* UNSIGNED16 UNSIGNED16 * DS_NAME Элементы 61375-2-1 IEC:2012 PV_LIST { p_variable derived_type; array_count; octet_offset; bit_number; ); PV_SET { p_pv_list; c_pv_list; p_freshtime; dataset; ); p_variable Адрес памяти переменной derived_type array_count обобщенный тип данных, производный от Var_Type (Тип переменной) и Var_Size (Размер переменной), зависящий от реализации число элементов в массиве. octet_offset сдвиг в количестве октетов в переменной bit_number p_pv_list номер бита переменной процесса меньше одного октета или контрольной переменной (см. Определение переменной PV_Name) Указатель на список переменных процесса (PV_List) c_pv_list число переменных элементов в списке переменных процесса p_freshtime Адрес памяти переменной таймера новизны (Freshness_Timer). (не используется для ap_put_set) dataset Использование Тип DS_Name (сохраняется для всего набора) 1 - Обработка переменных процесса и контрольных переменных идентична, поскольку все переменные набора переменных процесса являются согласованными. Следовательно, между сдвигом переменной (Var_Offset) и сдвигом контрольной переменной (Chk_Offset) нет различия. 2 - Сдвиг переменной (Var_Offset) (или сдвиг контрольной переменной (Chk_Offset) делится на сдвиг октетов и сдвиг битов для более быстрой обработки. По той же причине тип и размер занимают один октет, вместо шести битов, используемых в типе PV_NAME. 3 - Один и тот же формат используется для набора абонентов и для набора публикатора, хотя счетчик новизны не используется в наборе публикатора. 4 - Для повышения эффективности доступа набор переменных процесса (PV_Set) может также содержать прямые ссылки на внутренние структуры данных хранилища трафика. ПРИМЕЧАНИЕ По соображениям эффективности набор переменных процесса (PV_SET) не включает полное имя PV_NAME каждой переменной. В частности, контрольная переменная отображается в обычном формате ANTIVALENT2, поскольку одна и та же контрольная может защищать несколько переменных. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 181 – 6.2.3.3.6.3 Процедура ap_put_set Определение Копирует список переменных, принадлежащих одному и тому же набору, из пространства Application Memory_Address (Адрес памяти приложения) в порт в ходе неделимой операции. Синтаксис AP_RESULT ap_p ut_set ( pv_set ); PV_SET * Указатель на список переменных процесса (PV_List) Параметр ввода Возврат pv_set 6.2.3.3.6.4 Процедура ap_get_set Определение Копирует список переменных, принадлежащих одному и тому же набору, из пространства Application Memory_Address (Адрес памяти приложения) в порт в ходе неделимой операции. Любое значение AP_RESULT Синтаксис AP_RESULT PV_SET * Параметр ввода Возврат pv_set ap_g et_set ( pv_set ); Указатель на список переменных процесса (PV_List) Любое значение AP_RESULT Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 182 – 61375-2-1 © IEC:2012 6.2.3.3.7 Процедуры доступа к кластеру переменных 6.2.3.3.7.1 Режим доступа к кластеру переменных Кластеры представляют собой группы переменных, рассеянных по нескольким наборам данных и по нескольким хранилищам трафика. Интерфейс прикладного уровня для переменных (AVI) должен предоставлять для доступа к кластерам переменных следующие примитивы, представленные на Рисунке 113 и указанные в следующих подразделах: ap_put_cluster, ap_get_cluster. PV кластер перем. процесса абонента Приложение публикатора publisher PV_cluster adr PV ap_put_cluster , Приложение абонента adr ap_get_cluster . AVA AVA порт-источник порт-приемник Хранилище трафика Хранилище трафика передача Рисунок 113 - Доступ к кластеру переменных ПРИМЕЧАНИЕ 1 Доступ к кластеру переменных не гарантирует согласованности всего кластера, а только отдельных наборов переменных процесса в кластере. ПРИМЕЧАНИЕ 2 Согласованность между переменными одного и того же набора данных, которые появляются в разных наборах переменных процесса, не гарантируется. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.2.3.3.7.2 – 183 – Тип PV_CLUSTER (Кластер переменных процесса) Кластер переменных процесса (PV_Cluster) определяет группу наборов переменных процесса, упорядоченных хранилищем трафика. Определение Синтаксис Тип PV_Cluster (Кластер переменных процесса) typedef struct PV_CLUSTER { ts_id; c_pv_set; p_pv_set [c_pv_set] } UNSIGNED8 UNSIGNED8 struct PV_SET * Элементы ts_id c_pv_set p_pv_set Использование Traffic_store_id (Идентификатор хранилища трафика) (0..15) для одного хранилища трафика число наборов переменных процесса в кластере МАССИВ [0..c_pv_set-1] ИЗ указателей набора переменных процесса 1 – Существует список кластеров для каждого хранилища трафика. 2 - Один и тот же формат используется для списка кластеров абонентов и для списка кластеров публикатора, хотя счетчик новизны не используется в списке кластеров публикатора. 3 - Для повышения эффективности доступа кластер переменных процесса (PV_Cluster) может также содержать прямые ссылки на внутренние структуры данных хранилища трафика. 6.2.3.3.7.3 Процедура Определение Копирует кластер переменных из приложения в хранилище трафика. Переменные, принадлежащие одному и тому же набору переменных процесса, копируются бесперебойно. Синтаксис AP_RESULT ap_put_cluster ( pv_cluster ); PV_CLUSTER* Параметр ввода pv_cluster указывает на список кластеров публикатора Возврат Любое значение AP_RESULT 6.2.3.3.7.4 Процедура ap_get_cluster Определение Копирует кластер переменных процесса из хранилища трафика в местные экземпляры абонента. Переменные, принадлежащие одному и тому же набору переменных процесса, копируются бесперебойно. Синтаксис AP_RESULT PV_CLUSTER* ap_get_cluster ( pv_cluster ); Параметр ввода pv_cluster указывает на список кластеров абонента Возврат Любое значение AP_RESULT Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 184 – 61375-2-1 © IEC:2012 Службы и протоколы сообщений 6.3 Общие положения 6.3.1 Службы и протоколы сообщений разделены на нижний интерфейс и верхний интерфейс: a) нижний интерфейс канального уровня, который определяет услуги, ожидаемые от шины; а также b) службы верхнего прикладного уровня, предлагаемые для данного приложения. Опорная станция 6.3.2 Станция сети поездной связи, предоставляющая услуги обмена сообщениями, должна включать следующие элементы: a) как минимум одно шинное соединение, доступное через интерфейс данных канального уровня (LPI) и реализующее процесс канального уровня; b) Автомат протокола, называемый мессенджером, реализующий сетевой, транспортный, сеансовый, прикладной уровень и уровень представления; c) один или несколько прикладных процессов, один из которых является агентом сетевого управления. Станция администратора должна обеспечить прикладной процесс администратора. ПРИМЕЧАНИЕ Минимальный набор услуг, которые, как ожидается, будет предоставлять Агент, представлен в разделе 8 (Управление поездной сетью) 6.3.2.1 Конечная станция Станции, подключенные только к одной шине, или конечные станции должны иметь только один канальный уровень. ПРИМЕР Структура опорной конечной станции показана на Рисунке 114. Администратор Пользовательс кие приложения Прикладные процессы Агент Интерфейс прикладного уровня Мессенджер Уровень представления Сеансовый уровень Транспортный уровень Каталог функций Сетевой уровень Каталог станции каталоги маршрутизации Адаптер данных сообщений канального уровня (LMA) Канальны й уровень Процесс канального уровня физическая среда Рисунок 114 - Конечная станция ПРИМЕЧАНИЕ Сетевой уровень конечных станций имеет доступ только к собственному транспортному уровню и канальному уровню. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 6.3.2.2 – 185 – Станция-маршрутизатор Станция, подключенная к нескольким шинам, или станция-маршрутизатор должна иметь один канальный уровень для каждой шины. Обе шины используют одни и те же протоколы реального времени. ПРИМЕР На Рисунке 115 показана станция-маршрутизатор, подключенная к канальному уровню многофункциональной поездной шины (MVB) и проводной шины поезда (WTB). Прикладные процессы Администрат ор Пользовател ьские приложения Агент Интерфейс прикладного уровня Уровень представления Мессенджер Сеансовый уровень Каталог функций Транспортный уровень маршрутизатор Каталог станции Сетевой уровень LMA WTB Канальный уровень LMA MVB Канальный уровень Адаптер данных сообщений канального уровня Процессы канального уровня Физическая среда WTB физическая среда MVB Рисунок 115 - Станция-маршрутизатор между WTB и MVB ПРИМЕЧАНИЕ Сетевой уровень конечной станции может передавать пакеты от шины к шине. 6.3.2.3 Станция-шлюз Станция, подключенная к нескольким шинам, или станция-шлюз должна иметь один канальный уровень для каждой шины. Сеть подвижного состава использует другой протокол, отличный от протоколов реального времени проводной шины поезда. Станция-шлюз должна адаптировать протоколы сети подвижного состава с протоколами реального времени проводной шины поезда. ПРИМЕР На Рисунке 116 показана станция-шлюз, подключенная к канальному уровню сети подвижного состава и проводной шины поезда (WTB). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 186 – 61375-2-1 © IEC:2012 Администрато р Пользовате льские приложения Интерфейс прикладного уровня Каталог функций Катало г станции Прикладные процессы шлюз Агент Интерф. прикл. уровня Уровень представления Уровень предст. Сеансовый уровень Сеансовый уровень Транспортный уровень Транспортный уровень Сетевой уровень Сетевой уровень LMA LMA Адаптер данных сообщений канального уровня Канальный уровень сети подвижного состава WTB Канальный уровень Физическая среда WTB Мессенджер Процессы канального уровня физическая среда сети подвижного состава Рисунок 116 - Станция-шлюз между WTB и сетью подвижного состава 6.3.2.4 Идентификатор станции Идентификация станции должна осуществляться посредством Station_Id (Идентификатора станции). Поскольку на каждой станции может быть только один агент и один мессенджер, идентификатор станции также используется для идентификации агента. ПРИМЕЧАНИЕ Идентификатор станции не обязательно идентичен адресу устройства. Станция-маршрутизатор имеет один адрес устройства на шину, к которой она прикреплена, но только один идентификатор станции. Идентификатор станции может быть изменен сетевым управлением, в то время как адрес устройства часто является встроенным. 6.3.2.5 Идентификатор шины Станция должна идентифицировать каждый канальный уровень, т.е. каждую шину (сеть подвижного состава или поездную шину), к которой она подключена, посредством идентификатора шины (Bus_Id). Максимальное количество шин, подключенных к станции, составляет 16. ПРИМЕЧАНИЕ Идентификатор шины (Bus_Id) не указывает, какой тип шины подключен, но может быть полезным всегда задавать Bus_Id = 1 для шины поезда. 6.3.2.6 Адрес канала Станция должна идентифицировать каждое устройство, к которому она может получить доступ по одной из своих шин, посредством адреса канала. Адрес канала должен состоять из конкатенации идентификатора шины и адреса устройства. ПРИМЕЧАНИЕ Размер адреса устройства зависит от шины. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.3 – 187 – Обработка пакетов сообщения Обработка пакетов в стеке протоколов связи является проблемой реализации. Процедуры интерфейса в службах сообщений определяют пакет сообщения посредством указателя. В ходе реализации следует использовать этот указатель для передачи содержимого пакета по ссылке или путем его копирования. Сама структура пакета не регламентируется. Для облегчения переносимости и объяснения некоторых процедур интерфейса в этом подразделе указаны определенные процедуры обработки пакетов. Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. Этот интерфейс не нужно раскрывать, и он не подлежит проверке соответствия. 6.3.3.1 Пулы пакетов Для обеспечения бесперебойного доступа внутри станции все пакеты, используемые транспортным уровнем, сетевым уровнем и канальным уровнем, имеют одинаковый формат. Чтобы передавать пакеты по ссылке, а не копировать их, необходимо динамическое управление памятью пакетов в виде пулов пакетов. Первоначально создается пул пакетов с несколькими пустыми пакетами. Пользователь может запрашивать пакеты из пула и возвращать их в пул после использования. Чистый поток пакетов в пул и из пула в долгосрочной перспективе должен быть равен нулю. Существует несколько пулов пакетов, обычно по паре для каждого канального уровня. Пул, к которому принадлежит пакет, является его владельцем. 6.3.3.2 Тип «MD_PACKET» Пакеты идентифицируются дескриптором пакета, который указывает на данные пакета для отправки, а также на некоторые другие поля, которые используются для управления пакетами. На пакет ссылается указатель пакета, уникальный для этого пакета и указывающий на дескриптор пакета, имеющий тип MD_PACKET. Определение Данный тип определяет формат пакета. Синтаксис typedef void* MD_PACKET; Использование Формат MD_PACKET не регламентируется. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 188 – 61375-2-1 © IEC:2012 ПРИМЕР Пример MD_PACKET показана на Рисунке 117. Данные кадра Данные канала ссылка пакета владелец Заголовок канала DD MVB указатель указатель 8 8 режи м WTB DD LC PT следующий управ ление пакет ом состо яние пакет а данные сети SD SD 32 Заголовок сети MTC Передаваемые данные SZ WTB: 984 бит SZ MVB: 176 бит 8 32 8 Рисунок 117 - Формат пакета Пример пакета на Рисунке 117 начинается со следующих полей: – «следующий» («next»): Первое поле в пакете зарезервировано для указателя на другой пакет. Это позволяет объединять пакеты в списки или очереди. – «владелец» («owner»): Второе поле идентифицирует владельца (пул) пакета. Это поле используется для удаления использованного пакета. – «управление пакетом» (packet control) содержит управляющую информацию, которую канальный уровень может считывать, но не может изменять. – «состояние пакета» («packet status») может быть изменено канальным уровнем и может считываться другими уровнями. Оставшаяся часть пакета содержит кадр, фактически отправленный или полученный по шине: – Заголовок канала (Link_Header) имеет различный формат в зависимости от шины (многофункциональной поездной шины, проводной шины поезда или другой). Он содержит адрес устройства-источника и адрес устройства-адресата, а также другую управляющую информацию, относящуюся к шине; – Заголовок канала представляет интерес только для канального уровня, он не анализируется сетевым уровнем, который получает данную информацию по параметрам; – Поле «размер» («size») применяется к данным канала (Link_Data), за исключением размера самого поля. Пакет может иметь следующие состояния: MD_PENDING этот пакет помечен для отправки; MD_FLUSHED этот пакет удален из очереди; MD_SENT этот пакет был отправлен и может быть повторно использован. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 189 – Тип процедуры «MD_GET_PACKET» 6.3.3.3 Определение получает новый пакет из пула, устанавливает в поле владельца пакета значение «pool» («пул»). Синтаксис typedef void ( * MD_GET_PACKET ) ( void * * MD_PACKET * * pool, packet ); Параметр ввода pool Идентифицирует пул, из которого взят пакет Параметр вывода Использование packet Указывает на структуру данных, в которой хранится пакет. Этот тип процедуры совместим с типом процедуры LM_GET_PACK, которую можно вызывать напрямую. Тип процедуры «MD_PUT_PACKET» 6.3.3.4 Определение возвращает один пакет, который больше не используется, в пул, указанный в поле владельца пакета. Синтаксис typedef void MD_PACKET * ( * MD_PUT_PACKET ) ( packet ); Указывает на структуру данных, в которой находится пакет. Пул владельца отмечен в пакете. Параметр ввода packet Использование Этот тип процедуры совместим с типом процедуры LM_GET_PACK, которую можно вызывать напрямую. 6.3.4 6.3.4.1 Канальный уровень сообщений Цель Службы сообщений предоставляются на разных шинах: проводной шине поезда, многофункциональной поездной шине или других, включая параллельные шины, последовательные каналы связи, почтовые ящики памяти или шины датчиков. С этой целью ожидается, что канальный уровень любой из этих шин будет предоставлять набор основных услуг, которые указаны в этом подразделе. Как правило, канальный уровень одного устройства взаимодействует с канальным уровнем другого устройства для обмена пакетами между устройством-источником и устройствомадресатом, расположенными на одной шине, как показано на Рисунке 118. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 190 – 61375-2-1 © IEC:2012 устройство A Пользовател ьские процессы Верх Прикладной уровень Верхние уровни Прикладной уровень (Уровень представления) (Уровень представления) Сеансовый уровень Сеансовый уровень Транспортный уровень Сетевой уровень Интерфейс данных сообщения канального уровня (LMI) nm_send_confirm Транспортный уровень Сетевой уровень nm_receive_indicate nm_send_confirm nm_receive_ind lm_send_request lm_send_request lm_receive_poll очередь приема очередь отправки Канальный уровень шины Агент Верх Интерфейс прикладных сообщений (AMI) кадр устройство B Агент lm_receive_poll очередь приема очередь отправки Источник Адресат Адресат B Источник A Тип протокол Разм ер а Данные канала Рисунок 118 - Передача данных канального уровня Процесс канального уровня выполняет фактическую передачу по шине. Он может работать независимо от приложений и от мессенджера. Реализация канального уровня не указана. Поэтому службы канального уровня задаются в общей форме, которая, как ожидается, будет присутствовать в каждой шине, подключенной к мессенджеру. 6.3.4.2 Структура канального уровня Канальный уровень должен обеспечивать пару очередей: очередь отправки (Send_Queue), в которую сетевой уровень помещает пакеты для отправки, и очередь приема (Receive_Queu)e, из которой сетевой уровень извлекает пакеты, полученные от шины. Станция (маршрутизатор) может иметь несколько канальных уровней, по одному на каждую подключенную шину, как показано на Рисунке 119. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 191 – Верх Администрат ор Агент Прикладной уровень (Уровень представления) Сеансовый уровень Мессенджер Транспортный уровень Сетевой уровень Интерфейс данных сообщения канального уровня (LMI) LMA (M) LMA (S) Адаптер данных сообщений канального уровня Канальный уровень Шина 1 Шина2 Шина3 Рисунок 119 - Интерфейс данных сообщения канального уровня (LMI) Различия в реализации канальных уровней скрыты в адаптере данных сообщений канального уровня (LMA). ПРИМЕЧАНИЕ Адаптер данных сообщений канального уровня (LMA) может поддерживать только одну единственную шину (тип S) или несколько шин (тип M). 6.3.4.3 6.3.4.3.1 Характеристики канального уровня Адрес устройства Каждое устройство должно быть однозначно идентифицировано на шине посредством адреса устройства. Адрес устройства 0 должен идентифицировать местный канальный уровень и не должен присваиваться конкретному устройству. Самый старший адрес устройства (например, ‘11111111’B для 8-битного адерса устройства) должен указывать на широковещательную рассылку всем устройствам на шине и не должен быть присвоен конкретному устройству. Канальный уровень должен включать свой собственный адрес устройства как адрес устройства-источника во все отправляемые им пакеты, но он не должен использовать широковещательный адрес, характерный для шины, в качестве адреса устройства-источника. Канальный уровень должен включать адрес удаленного устройства или широковещательный адрес, характерный для шины, в качестве адреса устройства-адресата во все отправляемые им пакеты. ПРИМЕЧАНИЕ 1 Формат адреса устройства зависит от шины (проводная шина поезда, многофункциональная поездная шина или другая). ПРИМЕЧАНИЕ 2 Устройство-маршрутизатор имеет один адрес устройства для каждой подключенной к нему шины. 6.3.4.3.2 Тип протокола Канальный уровень для сообщений должен должен включать в себя пару очередей (расходуемых буферов). Если другие протоколы поддерживаются одним и тем же устройством, тип протокола (PT) в каждом кадре должен выбирать очереди отправки (Send_Queues) и очереди приема (Receive_Queues), используемые для протоколов реального времени. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 192 – 61375-2-1 © IEC:2012 ПРИМЕНЧАНИЕ Тип протокола играет роль, аналогичную точке доступа к каналу передачи данных в ISO/IEC 7498. Приоритеты 6.3.4.3.3 Приоритеты не различаются на канальном уровне. Сброс 6.3.4.3.4 Канальный уровень узла должен включать возможность сброса всех пакетов. ПРИМЕЧАНИЕ Сброс необходим в случае, если узел получает новую топографию. Время существования пакета 6.3.4.3.5 Канальный уровень должен включать возможность ограничения времени существования пакетов в его очереди приема (Receive_Queues) или очереди отправки (Send_Queues) значением PACK_LIFE_TIME (ВРЕМЯ СУЩЕСТВОВАНИЯ ПАКЕТА). PACK_LIFE_TIME должно составлять 5,0 с. ПРИМЕЧАНИЕ Ограничение времени существования может быть достигнуто за счет тайм-аута очереди (сброс очереди) или недопустимости отдельного пакета в очереди. Протокол канального уровня 6.3.4.3.6 Протокол канального уровня должен являться протоколом без установления соединения, т.е. работать только с дейтаграммами. Канальный уровень не должен автоматически повторять потерянные кадры. Канальный уровень должен регистрировать ошибки передачи для сетевого управления. Канальный уровень сети железнодорожного подвижного состава, например, многофункциональная поездная шина (MVB) 6.3.4.4 Сеть железнодорожного подвижного состава может быть реализована различными шинами, например, многофункциональной поездной шиной (MVB) (см. IEC 61375-3-1), которая служит в качестве эталона. Адрес устройства сетевого устройства железнодорожного подвижного состава не должен изменяться в ходе плановой эксплуатации. Если многофункциональная поездная шина используется в качестве сети железнодорожного подвижного состава, применяются следующие дополнительные условия: 12-битный адрес устройства должен идентифицировать устройство-источник и устройство-адресат; поле Mode (Режим) необходимо указывать одноадресную передачу как ‘0001’B или широковещательную передачу как ‘1111’B. Во втором случае адрес устройства является «don't care» («безразличным»); если указан самый старший адрес устройства ('111111111111'B), то должен быть выбран широковещательный режим передачи; 4-битный тип протокола ‘1000’B должен идентифицировать протоколы реального времени сети поездной связи. ПРИМЕР Формат кадра данных сообщения, передаваемый по многофункциональной поездной шине, показан на Рисунке 120. DD 4 12 PT режи м Заголовок канала SD SZ 4 12 8 Заголовок сети источник конечный 32 MTC 8 ДАН НЫЕ 176 бит Передаваемые данные Рисунок 120 – Пример кадра данных сообщения многофункциональное поездной шины Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 193 – Канальный уровень шины поезда 6.3.4.5 Шина поезда может быть реализована посредством различных шин, в частности проводной шиной поезда, которая служит в качестве эталона. Различают шины поезда с переменным составом (например, проводная шина поезда) и шины поезда с фиксированным составом (например, многофункциональная поездная шина). Шина поезда с переменным составом 6.3.4.5.1 В шине поезда с переменным составом, в котором адреса узлов могут динамически изменяться, канальный уровень должен уведомлять свой сетевой уровень об изменении и предоставлять ему топографический счетчик, 6-битный счетчик, который увеличивается (по модулю 64) каждый раз при изменении состава. ПРИМЕЧАНИЕ 1 Шина поезда может предоставлять дополнительную информацию, такую как топография, через службы управления канального уровня, указанные в проводной шине поезда. Хотя службы сообщений учитывают только топографический счетчик, приложению требуется топография для выбора правильных адресов узлов в зависимости от типа подвижного состава. Преобразование подвижного состава в адреса узлов является проблемой приложения. ПРИМЕЧЕНИЕ 2 Поскольку возможно, что приложение не знает, что была распределена новая топография, поскольку им была считана старая топография, для уточнения информации о топографии используется счетчик топографии. Если в качестве шины поезда используется проводная шина поезда, то применяются следующие дополнительные условия: – Узлы проводной шины поезда обращаются к узлам через 8-битный адрес узла, назначенный при открытии эксплуатации. – Проводная шина поезда использует в качестве широковещательного адреса устройства-адресата Destination_Device = ‘11111111’B. – Тип протокола канального уровня для протоколов реального времени идентифицируется управлением канала Link_Control = ‘x0xxx111’B (данные сообщения). ПРИМЕР На Рисунке 121 показан формат кадра проводной шины поезда. Заголовок канала DD LC SD 8 Устройствоадресат 8 8 SZ 8 Заголовок сети конечный 16 источник MTC 16 8 Передаваемые данные (до 984 бит) Устройство- '00xxx111'B источник Рисунок 121 – Пример кадра данных сообщения проводной шины поезда 6.3.4.6 Интерфейс данных сообщения канального уровня (LMI) Интерфейс данных сообщения канального уровня (LMI) определяет услуги, которые канальный уровень предлагает сетевому уровню. Данный интерфейс не подлежит проверке соответствия. Это указано в следующих подпунктах для облегчения переноса. Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. 6.3.4.6.1 Примитивы LMI Интерфейс данных сообщения канального уровня должен предоставлять примитивы, представленные на Рисунке 122, перечисленные в Таблице 20 и указанные в следующих подразделах. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 194 – Сетевой уровень Сетевой уровень 61375-2-1 © IEC:2012 Канальный уровень Сетевой уровень lm_init lm_init lm_get_dev_address lm_get_dev_address Физический уровень nm_status_indicate nm_status_indicate (Тип LM_STATUS_INDICATE) (Тип LM_STATUS_INDICATE) m_get_status m_get_status lm_send_queue_flush nm_get_pack lm_send_request (Тип LM_GET_PACK) пустой пакет полный пакет отправлен ный пакет nm_receive_indicate (Тип LM_RECEIVE_INDICATE) nm_send_confirm lm_receive_poll (Тип LM_SEND_CONFIRM) полученный пакет lm_send_request время nm_get_pack Рисунок 122 - Примитивы LPI ПРИМЕЧАНИЕ Процедуры LMI имеют префикс lm_, типы канального уровня имеют префикс LM_, а примитивы сетевого уровня имеют префикс nm_. Канальный уровень вызывает процедуры индикации сетевого уровня (с префиксом nm_), на которые ранее была сделана подписка, и которые имеют тип, определенный канальным уровнем (с префиксом LM_). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 195 – Таблица 20 - Примитивы LPI Имя Значение MD_RESULT Результат процедуры lm_send_request Запрос на отправку пакета LM_SEND_CONFIRM Индикация отправки пакета LM_GET_PACK Получение пустого пакета LM_RECEIVE_INDICATE Указывает, что пакет был получен lm_receive_poll Опросы полученных пакетов LM_STATUS_INDICATE, Указывает изменение состояния m_get_status Получение состояния канального уровня lm_send_queue_flush, Сбрасывает очередь отправки lm_init Инициализация канального уровня lm_get_dev_address. Считывание адреса устройства 6.3.4.6.2 Тип «MD_RESULT» Процедура интерфейса данных сообщения канального уровня (LMI), возвращающая значение, должна кодировать его следующим образом: Определение Синтаксис 6.3.4.6.3 typedef enum { MD_OK MD_READY MD_REJECT MD_INAUGURATION 2 несогласованность } MD_RESULT; 0 /* правильное выполнение 0 /* готовность 1 /* не принято (полная или пустая очередь) /* открытие эксплуатации – возможная Процедура «lm_send_request» Определение Добавляет заголовок канала в пакет и вставляет его в очередь отправки. Если канальный уровень принимает пакет для передачи, он задает его статус в MD_PENDING. Синтаксис MD_RESULT ENUM8 UNSIGNED32 UNSIGNED32 lm_send_request ( bus_id source, n, MD_PACKET * Параметр ввода bus_id source destinatio packet; ) Выбирает один из 16 различных канальных уровней. Адрес устройства-источника. Если «source» («источник») равен нулю, канальный уровень включает в пакет свой собственный адрес устройства. Возврат destination Адрес устройства-адресата или широковещательный адрес, если указан самый старший адрес устройства. packet Указывает на структуру данных, которая содержит пакет. Размер и состояние пакета содержатся в самом пакете. Любое значение MD_RESULT Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 196 – 6.3.4.6.4 61375-2-1 IEC:2012 Тип процедуры «LM_SEND_CONFIRM» Процедура этого типа вызывается канальным уровнем для возврата пакета в пул, когда он был передан или больше не требуется. Определение Синтаксис typedef void MD_PACKET * ( * LM_SEND_CONFIRM ) ( packet ); Указывает на структуру данных, которая содержит отправленный или удаленный пакет. Размер или состояние пакета содержится в самом пакете. Параметр ввода packet Использование 1 - Фактическая процедура «nm_get_pack» (тип LM_GET_PACK) имеет предварительную подписку в процедуре «lm_init». 2 - Ожидается, что канальный уровень установит состояние пакета либо в MD_SENT (успешная отправка), либо в MD_FLUSHED (очередь сброшена) перед вызовом «nm_send_confirm». 6.3.4.6.5 Тип процедуры «LM_GET_PACK» Определение Процедура этого типа вызывается для запроса свободного пакета из пула. Данная процедура, в случае успеха, предоставляет один пакет с полем владельца, в котором установлено значение параметра владельца. Синтаксис typedef void ( * LM_GET_PACK ) ( void * * owner, MD_PACKET * * packet ); Параметр ввода Использование owner Идентифицирует пул, из которого взят пакет. packet Указывает на структуру данных, в которой хранится пакет. 1 - Фактическая процедура «nm_get_pack» (тип LM_GET_PACK) имеет предварительную подписку в процедуре «lm_init». 2 - Канальный уровень должен указывать в качестве владельца только тот пул, который был назначен ему во время инициализации. 6.3.4.6.6 Тип процедуры «LM_RECEIVE_INDICATE» Определение Синтаксис Когда пакет получен, канальный уровень должен вызвать процедуру этого типа. typedef void ENUM8 ( * LM_RECEIVE_INDICATE ) ( bus_id ); Идентификатор шины Bus_Id (0..15) Параметр ввода bus_id Использование 1 - Фактическая процедура «nm_receive_indicate» (тип LM_RECEIVE_INDICATE) имеет предварительную подписку в процедуре «lm_init». 2 - Эта процедура может иметь значение NULL (НУЛЬ), если используется опрос ("lm_receive_poll"). 3 - Эта процедура индикации вызывается из программы обработки прерывания, но ей разрешено выполнять вызовы ядра. Она предназначен для активации мессенджера. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.4.6.7 – 197 – Процедура «lm_receive_poll» Определение Считывает один полученный пакет из очереди приема и передает ссылку на пакет на сетевой уровень. Синтаксис MD_RESULT ENUM8 unsigned * unsigned * MD_PACKET * * Параметр ввода bus_id lm_receive_poll ( bus_id, source, destination, packet ); Идентификатор шины Bus_Id (0..15) канального уровня Любое значение MD_RESULT Возврат Параметр вывода source Адрес устройства-источника destination Адрес устройства-адресата или широковещательный адрес. Указывает на структуру данных, которая содержит полученный пакет, или может иметь значение NULL (НУЛЬ), если очередь пуста. Размер пакета содержится в самом пакете. 1 - Дескриптор пакета можно повторно использовать после вызова этой процедуры. packet Использование 2 - Если результатом этой процедуры является MD_OK, очередь приема очищается на одну позицию, а остальные аргументы этой процедуры становятся значимыми. 3 - Если эта процедура вызывается, когда очередь приема аннулирована, она возвращает MD_REJECT в качестве результата и значение NULL (НУЛЬ) в качестве «пакета». 6.3.4.6.8 Тип процедуры «LM_STATUS_INDICATE» Определение В случае исключения, канальный уровень должен вызвать процедуру этого типа для оповещения об этом факте. Синтаксис typedef void ENUM8 MD_RESULT Параметр ввода Использование ( * LM_STATUS_INDICATE ) ( bus_id, status ); bus_id Идентификатор шины Bus_Id (0..15) status MD_OK (плановая эксплуатация) MD_REJECT (шина недоступна) MD_INAUGURATION (шина поезда в процессе открытия эксплуатации) 1 - Фактическая процедура «nm_status_indicate» (тип LM_STATUS_INDICATE) имеет предварительную подписку в процедуре «lm_init». 2 - Состояние типа MD_RESULT’ является параметром ввода. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 198 – 6.3.4.6.9 Процедура «lm_get_status» Определение Извлекает подробную информацию о канальном уровне. Синтаксис MD_RESULT ENUM8 BITSET8 BITSET8 BITSET8 * Параметр ввода lm_get_status ( bus_id, selector, reset, status ); bus_id Идентификатор шины Bus_Id (0..15) selector выбирает в состоянии интересующие возвращенные биты Каждая часть информации представлена одним битом, который устанавливается канальным уровнем и сбрасывается пользователем службы. Определены следующие три бита MD_RECEIVE_ACTIVE = 1 устанавливается всякий раз, когда от шины получен правильный кадр. MD_SEND_ACTIVE = 2 кадр был передан. устанавливается, если MD_RECEIVE_OVERFLOW = 4 устанавливается, когда полученный кадр потерян в результате отсутствия свободного пакета. выбирает биты, которые впоследствии должны быть очищены. Любое значение MD_RESULT reset Возврат status возвращает значение выбранных битов состояния. Параметр вывода Использовани Ожидается, что сетевой уровень будет сбрасывать бит MD_SEND_ACTIVE при считывании состояния канального уровня сети подвижного состава. е 6.3.4.6.10 Процедура «lm_send_queue_flush» Определение Сбрасывает очередь отправки на канальном уровне и устанавливает для состояния пакета MD_FLUSHED. Вызывает nm_send_confirm один раз для каждого пакета, вставленного процедурой lm_send_request и еще не отправленного. Синтаксис MD_RESULT ENUM8 Параметр ввода Возврат bus_id lm_send_queue_ flush ( bus_id /* optional */ ); Идентификатор шины Bus_Id (0..15) Любое значение MD_RESULT Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 199 – Процедура «lm_init» 6.3.4.6.11 Инициализирует канальный уровень, сбрасывает очередь отправки и осуществляет подписку на процедуры индикации с сетевого уровня. Определение Синтаксис MD_RESULT lm_init ( ENUM8 bus_id, LM_RECEIVE_INDICATE nm_receive_indicate, LM_GET_PACK nm_get_pack, void * * owner, LM_SEND_CONFIRM nm_send_confirm, LM_STATUS_INDICATE nm_status_indicate ); Параметр ввода bus_id Идентификатор шины Bus_Id (0..15) nm_receive_indicate процедура сетевого уровня, которую канальный уровень вызывает каждый раз, когда получает пакет. get_packet процедура пула пакетов, которую канальный уровень вызывает каждый раз, когда ему требуется пустой пакет. owner пул пакетов, который канальный уровень использует для получения пакетов. процедура пула пакетов, которую канальный уровень вызывает для удаления пакета. put_pack nm_status_indicate Возврат процедура сетевого уровня, которую канальный уровень вызывает для оповещения об исключении (например, открытии эксплуатации). Любое значение MD_RESULT Процедура «lm_get_dev_address» 6.3.4.6.12 Определение Синтаксис считывает собственный адрес устройства, соответствующий указанному канальному уровню. MD_RESULT ENUM8 * lm_get_dev_address ( bus_id, UNSIGNED device_address ); Параметр ввода bus_id Идентификатор шины Bus_Id (0..15) Возврат Любое значение MD_RESULT device_address Адрес устройства на этом канальном уровне Параметр вывода Использование На канальном уровне шины поезда извлекается адрес устройства, из которого может быть выведен адрес узла. 6.3.5 6.3.5.1 Сетевой уровень сообщений Цель Сетевой уровень ретранслирует пакеты, как показано на Рисунке 123: с транспортного уровня своей станции на канальный уровень (исходящие пакеты),или с одного из своих канальных уровней на транспортный уровень (входящие пакеты), или с одного канального уровня на другой канальный уровень в узле маршрутизатора (транзитные пакеты). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 200 – Интерфейс прикладных сообщений быстрый вызов сеансовый уровень транспортный уровень интерфейс сетевого уровня входящие исходящие Каталог функций Каталог группы Групповой адрес 02 03 45 Функция сетевой уровень 01 02 03 251 Конечная станция 123 123 123 222 транзит Каталог станций Каталог узлов Конечная станция Адрес устройства Узел 02 03 04 02 03 04 данный узел LMI 01 02 123 222 Следующа я станция 01 123 123 222 Шина Адрес устройства 01 02 02 00 0121 1540 1540 1522 данная станция данная топография Шина поезда Сеть подвижного состава Рисунок 123 – Сетевой уровень узла Сетевой уровень направляет пакеты от начальной станции к конечной станции. С этой целью сетевой уровень использует преобразование, предоставляемое несколькими каталогами: a) каталог станции, b) каталог функций, c) каталог группы, и d) каталог узлов. Сетевой уровень является уровнем без установления соединения. 6.3.5.2 6.3.5.2.1 Каталоги Каталог станции (дополнительно) Сетевой уровень должен преобразовывать идентификатор станции в адрес канального уровня этой станции и наоборот. На конечной станции данное преобразование может быть получено путем расширения идентификатора станции (Station_Id) фиксированным начальным полем для получения адреса устройства (простое сопоставление). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 201 – На станции-маршрутизаторе преобразование должно быть реализовано посредством каталога станций, структурированного следующим образом: Station_Id Идентификатор станции (ключ к каталогу станции) Next_Station_Id Bus_Id Идентификатор следующей станции, посредством которого можно связаться со станцией. Канальный уровень, посредством которого можно связаться со следующей станцией Device_Address Адрес устройства на шине, по которому можно связаться со следующей станцией ПРИМЕЧАНИЕ 1 Каталог станции позволяет создавать заголовок канала (Link_Header) исходящего пакета, но также используется для идентификации адреса канального уровня источника входящего пакета. Причина состоит в том, что транспортный уровень не должен обрабатывать характерные для шины адреса произвольного размера, а только идентификаторы станций. ПРИМЕЧАНИЕ 2 Идентификаторы станции и следующей станции будут идентичны, если со станцией можно связаться напрямую, и будут различаться, когда отправка пакетов осуществляется между двумя сетями подвижных составов или между сетью подвижного состава и шиной датчиков. ПРИМЕЧАНИЕ 3 Примитивы доступа к каталогу станций определены в интерфейсе прикладного уровня (ALI). 6.3.5.2.2 Каталог функций Сетевой уровень должен реализовать каталог функций, который преобразовывает идентификатор функции (Function_Id) в идентификатор станции (Station_Id), структурированный следующим образом: Function_Id Идентификатор функции (ключ к каталогу функции) Station_Id Идентификатор станции (ключ к каталогу станции) ПРИМЕЧАНИЕ 1 Каталог функций принадлежит сетевому уровню, но к нему могут получить доступ все уровни, кроме канального уровня. ПРИМЕЧАНИЕ 2 Примитивы доступа к каталогу функций определены в интерфейсе прикладного уровня (ALI). 6.3.5.2.3 Каталог группы Сетевой уровень станции, участвующей в многоадресной рассылке, должен указывать, к какой Список групп Membership группе принадлежит эта станция, посредством каталога группы, структурированного следующим образом: ПРИМЕЧАНИЕ Примитивы доступа к каталогу группы определены в интерфейсе прикладного уровня (ALI). 6.3.5.2.4 Каталог узлов (дополнительно) Сетевой уровень узла должен преобразовывать адрес узла в адрес устройства на шине поезда. Если в качестве шины поезда используется проводная шина поезда, то следует использовать простое преобразование, полученное путем добавления двух начальных «0» к 6-битному адресу узла в качестве префикса для формирования 8-битного адреса устройства проводной шины поезда. Каталог узла доступен только для чтения, поскольку его содержимое определяется открытием эксплуатации. В фиксированных составах поездов, где простого преобразования недостаточно, адрес узла должен быть преобразован в адрес устройства с использованием каталога узлов, структурированного следующим образом: Node_Address Адрес узла (ключ к каталогу узлов) Bus_Id Канальный уровень, соответствующий шине поезда Device_Address Адрес устройства, зависящий от шины ПРИМЕЧАНИЕ Примитивы доступа к каталогу узлов определены в интерфейсе прикладного уровня (ALI). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 202 – Постоянные и переменные сетевого уровня 6.3.5.3 Различные переменные идентификатора станции (Station_Id) или следующей станции (Next_Station): Значение Station_Id = AM_SAME_STATION AM_UNKNOWN this_station 0 (постоянная) 255 (постоянная) final_station 8-битный идентификатор данной станции Если станция не имеет выделенного идентификатора, this_station = AM_UNKNOWN. origin_station станция, указанная в сетевом адресе конечной next_station станции станция, указанная в сетевом адресе начальной станции. станция, через которую сетевой уровень отправляет пакет или от которой он его получил. Различные значения узла (Node) (все эти значения являются UNSIGNED6): Значение Node = AM_SAME_NODE 0 (постоянная) this_node 6-битный адрес узла для данного узла 0 AM_ANY_TOPO (постоянная) любое значение счетчика origin_node final_node топографии this_topo my_topo 6-битный адрес узла в начальном сетевом адресе 6-битный адрес узла в конечном сетевом адресе packet_topo значение топографического счетчика на этой станции, зарегистрированное am_set_current_tc. значение топографического счетчика, указанное приложением для этого сеанса связи значение топографического счетчика, передаваемое в пакете Вспомогательные процедуры: multicast возвращает значение true (истина) при использовании групповой адресации member (group) fundi () возвращает значение true (истина), если узел принадлежит группе и используется многоадресная рассылка возвращает идентификатор станции (Station_Id) указанный каталоге функций stadi () Возвращает адрес канала (Link_Address), указанный каталоге станций. 6.3.5.4 6.3.5.4.1 Сетевой адрес Формат Сетевой уровень с каждым пакетом получает от своего транспортного уровня или от одного из канальных уровней конечный сетевой адрес (Final Network_Address). Сетевой уровень использует данный конечный сетевой адрес (Final Network_Address) для создания заголовка канала (Link_Header) и заголовка сети (Network_Header) для пересылаемого пакета. Сетевой уровень считывает заголовок канала (Link_Header) и заголовок сети (Network_Header) входящего пакета и преобразует их в начальный сетевой адрес для транспортного уровня. Удобная кодировка конечного и начального сетевого адреса показана на Рисунке 124 . Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 203 – 7 6 fsu fgi 5 4 3 2 1 0 конечный_узел_или_группа конечная_функция_или_станция следующая_станция frv собственная_топография ftv Конечный сетевовой адрес 7 6 osu ogi 5 4 3 2 1 0 начальный_узел начальная_функция_или_станция данная_станция orv данная топография otv Начальный сетевой адрес ПРИМЕЧАНИЕ На рисунке представлен не формат передачи, а формат интерфейса. Рисунок 124 - Кодирование сетевого адреса 6.3.5.4.2 Система или пользователь (fsu/osu) Значение старшего бита первого октета сетевого адреса, «fsu» или «osu», если он равен: 1: Системный адрес: октет идентифицирует станцию, 0: Адрес пользователя: следующий октет идентифицирует функцию. Бит «osu» в начальном адресе должен иметь то же значение, что и бит «fsu» в конечном адресе. 6.3.5.4.3 Групповой или отдельный (fgi/ogi) Значение второго по старшинству бита первого октета конечного сетевого адреса, «fsu» или «osu», если он равен: 1: групповой адрес, 0: отдельный адрес Биты «fgi» и «ogi» должны быть одинаковыми в начальном и в конечном адресе. 6.3.5.4.4 Узел или группа Шесть битов «origin_node» («начального адреса») представляют один Node_Address (Адрес узла) для начального узла. Шесть битов «final_node_or_group» («конечного адреса или группы») представляют: Group_Address (Адрес группы), если бит «fgi» указывает на группу, в противном случае Node_Address (Адерс узла). 6.3.5.4.5 Функция или станция Второй октет сетевого адреса содержит: идентификатор станции, если «fsu/osu» означает «System» (Система); идентификатор функции, если «fsu/osu» означает «User» (Пользователь); Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 204 – 6.3.5.4.6 61375-2-1 IEC:2012 Адрес канала Третий октет, next_station (следующая станция), идентифицирует станцию, присоединенную к тому же узлу, на который должен быть отправлен пакет или от которого пакет был получен (не обязательно является начальной или конечной станцией). Сетевой уровень получает соответствующий адрес канала (идентификатор шины и адрес устройства) из своего каталога станций, или для входящего пакета может вывести идентификатор станции для следующей станции из адреса устройства и идентификатора шины. «next_station» («следующая станция») может также указывать на собственную станцию (AM_SAME_STATION) или на неизвестную станцию (AM_UNKNOWN). Узел, осуществляющей отправку по шине поезда, не имеет определенной next_station (следующей станции) (AM_UNKNOWN), но если узел использует каталог узла, Next_Station записана в этом каталоге. 6.3.5.4.7 Топографический счетчик Четвертый октет конечного и начального сетевого адреса содержит топографический счетчик (Topo_Counter). Старший бит данного октета, «frv» соответствует «orv», составляет «0». Второй по старшинству бит («ftv» соответствует «otv») указывает, что шесть младших значащих битов содержат допустимое значение счетчика (за исключением случаев, когда используется групповой адрес). 6.3.5.5 6.3.5.5.1 Кодирование сетевого заголовка Исходящие и входящие пакеты Конечный сетевой адрес и начальный сетевой адрес исходящего пакета используются для построения полей заголовка канала (Link_Header) и заголовка сети (Network_Header) для многофункциональной поездной шины (топографический счетчик не используется), как показано на Рисунке 125. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 205 – транспортный уровень исходящий пакет конечный сетевой адрес fsu fgi начальный сетевой адрес конечный_узел_или osu ogi начальный_узел _группа конечная_фукнция_или_станция начальная_функция_или_станция следующая_станция 0 ftv топографический _счетчик 4 0 otv топографический_счетчик StaDi DD proto режи м StaDi MVB данная_станция 12 4 SD 12 Заголовок канала SZ 8 конечный 16 начальный 16 MTC передаваемые данные 8 Заголовок сети Рисунок 125 - Построение адресов в исходящем пакете 6.3.5.5.2 Кодирование сетевого заголовка на шине поезда Заголовок сети на шине поезда должен быть закодирован в соответствии со следующей спецификацией, показанной на Рисунке 126 для проводной шины поезда: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 206 – Network_Header::= RECORD { fsu ENUM1 { USER (0) SYSTEM -- используется адрес пользователя (функция) -- используется адрес системы (станция) (1) }, fgi UNSIGNED1, отдельный параметр ONE_OF [fgi] { [0] final_node UNSIGNED6, [1] final_group UNSIGNED6 }, ONE_OF [fsu] { [USER] final_function, [SYSTEM] final_station } osu ENUM1, ogi UNSIGNED1, origin_node UNSIGNED6, 61375-2-1 © IEC:2012 -- 1 если группа, 0 если UNSIGNED8, UNSIGNED8 -- то же, что и ‘fsu’, если отличается: резерв -- то же, что и fgi ( 1 = многоадресная рассылка) -- начальный узел всегда одиночный узел ONE_OF [snu] { [USER] origin_function, UNSIGNED8, -- если это адрес пользователя [SYSTEM] origin_station UNSIGNED8 -- если это адрес системы } } Заголовок канала WTB DD 8 LC SD SZ конечный 8 8 8 Заголовок сети начальный 16 16 MTC передаваемые данные 8 Система/пользователь (должно быть одинаково) fsu 1) osu 0 конечный_узел конечная_фукнция_или_станция 0 начальный_узел начальная_функция_или_станция 1 начальный_узел начальная_функция_или_станция пакеты от станции до другой станции пакеты от станции для многоадресной передачи 2) 1 конечная_группа начальная_функция_или_станция Группа/отдельный узел (оба = 1: многоадресная передача) Рисунок 126 - Кодирование сетевого адреса на шине поезда Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 207 – Начальный адрес и конечный адрес (или группа) должны быть определены (> AM_UNKNOWN). И конечный и начальный адрес должны использовать один и тот же тип адресации (системная или пользовательская), для битов «snu» должны быть установлены одни и те же значения. Начальный адрес должен быть отдельным адресом узла. Если конечный адрес указывает группу (многоадресную передачу), биты «fgi» и «ogi» должны быть равны «1». 6.3.5.6 6.3.5.6.1 Маршрутизация на сетевом уровне Ситуации Девять ситуаций, перечисленных в Таблице 21, определяют поведение полноценного сетевого уровня, подключенного к транспортному уровню; Один или несколько канальных уровней сети подвижного состава; канальный уровень шины поезда. Таблица 21 - Ситуации маршрутизации Ситуация Откуда Куда Примечания 1 данный транспортный уровень данный транспортный уровень быстрый вызов внутри одного устройства 2 данный транспортный уровень любая сеть подвижного ж/д состава может быть несколько сетей подвижного ж/д состава 3 данный транспортный уровень шина поезда станция -узел 4 любая сеть подвижного ж/д состава данный транспортный уровень может быть несколько сетей подвижного ж/д состава 5 любая сеть подвижного ж/д состава другая сеть подвижного ж/д состава функция маршрутизатора 6 любая сеть подвижного ж/д состава шина поезда функция маршрутизатора 7 шина поезда данный транспортный уровень станция -узел 8 шина поезда любая сеть подвижного ж/д состава функция маршрутизатора 9 шина поезда шина поезда не предусмотрено Конечная станция, подключенная к сети подвижного состава, сталкивается только с ситуациями 1, 2 и 4. Конечная станция, подключенная к шине поезда, сталкивается только с ситуациями 1, 3 и 7. Станция-маршрутизатор, подключенная к двум сетям подвижного состава, сталкивается только с ситуациями 1, 2, 4 и 5. 6.3.5.6.2 Проверка обратного канала Сетевой уровень должен гарантировать, что все пакеты, принадлежащие сообщению вызова и соответствующему ему ответному сообщению, проходят по одному и тому же маршруту. Для каждого полученного пакета сетевой уровень должен проверять возможность его отправки обратно на начальный адрес, в противном случае сетевой уровень не должен пересылать пакет. Проверка осуществляется при условии, что получен пакет, для которого начальный адрес меняется на конечный адрес, а адрес источника меняется на адрес адресата, а также посредством проверки того, что в этом случае следующая станция является определенной. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 208 – 61375-2-1 IEC:2012 Во время инициализации «next_station» (следующая станция) может быть не определена, в частности, когда вызывающая станция не записана в каталоге станций. Если системное сообщение получено от станции, не включенной в ее каталог станций, сетевой уровень должен предположить, что начальная станция, указанная в начальном адресе, имеет адрес канала, соответствующий устройству-источнику, и записать его в каталог станций. В этих условиях сообщение пользователя будет отклонено. ПРИМЕЧАНИЕ Эта неявная запись может быть впоследствии исправлена, в случае необходимости, с помощью административных сообщений. 6.3.5.6.3 Согласованность топографии Для защиты от изменений конфигурации шины поезда во время передачи сообщения, пакеты, отправляемые узлу или от него по сети подвижного состава, включают в себя счетчик топографии. Сетевой уровень должен хранить самое последнее значение счетчика топографии в своей переменной «this_topo» («данная топография»). ПРИМЕЧАНИЕ 1 Значение «this_topo» передается на сетевой уровень службой am_set_current_tc интерфейса прикладных сообщений (AMI). ПРИМЕЧАНИЕ 2 Если станция является узлом, this_topo увеличивается при открытии эксплуатации. ПРИМЕЧАНИЕ 3 При выполнении вызова приложение указывает значение «my_topo» («собственная топография»). Если приложение не знает топографию или не заботится о согласованности, оно устанавливает my_topo = AM_ANY_TOPO. Транспортный уровень передает «my_topo» сетевому уровню как часть сетевого адреса. Сетевой уровень на узле должен сравнить «this_topo» со значением, найденным во входящих пакетах, называемым «packet_topo» («топография пакета»). Когда узел получает пакет из своей сети подвижного состава со значением package_topo в начальном адресе, равном его значению this_topo или AM_ANY_TOPO, то узел должен вставить свой собственный адрес узла (this_node) в начальный адрес и переслать пакет по шине поезда; значением packet_topo в начальном адресе, отличающемся от значения this_topo, а также от AM_ANY_TOPO, то узел должен отменить передачу в соответствии с указанным в 6.3.5.6.4. Когда узел получает пакет от другого узла по шине поезда: пакет, направленный для одной из его станций или функций, он должен вставить значение «this_topo» в конечный адрес в качестве значения packet_topo; конечная станция проверит, что значение package_topo, отправленное узлом, идентично значению this_topo, в противном случае конечная станция должна отменить передачу в соответствии с указанным в 6.3.5.6.4. 6.3.5.6.4 Отмена Чтобы отменить передачу, сетевой уровень должен переслать нарушающий пакет на свой транспортный уровень, который отправит источнику пакета запрос на отключение (Disconnect_Request) с причиной AM_INAUG_ERR. В процессе открытия эксплуатации узел должен отвечать на любой пакет, поступающий от сети подвижного состава и адресованный другому подвижному составу, посредством запроса на отключение (Disconnect_Request) с причиной AM_INAUG_ERR. Когда устройство получает запрос на отключение с причиной AM_INAUG_ERR, оно должно отменить все свои текущие соединения по шине поезда. ПРИМЕЧАНИЕ Сетевой уровень без установления соединения не должен воздействовать на протокол, поэтому он делегирует эту задачу транспортному уровню. Единственная ситуация, в которой это происходит, связана с ошибкой открытия эксплуатации . Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.5.6.5 – 209 – Алгоритмы маршрутизации Маршрутизатор должен пересылать пакет, как указано: для исходящих пакетов в Таблице 22, для входящих и транзитных пакетов сети от подвижного состава в Таблице 23, и для входящих и транзитных пакетов, поступающих от шины поезда Таблице 24, и Таблица 22 - Маршрутизация пакетов, поступающих с транспортного уровня Откуда Данный Куда Любая транспортный уровень Условие Транспортный уровень передает значения next_station и топографический счетчик на сетевой уровень в сетевом адресе. Транспортный уровень не проверяет топографический счетчик исходящих пакетов. (1) Транспортный уровень (2) Канальный уровень сети подвижного состава (3) При одноадресной передаче: невозможно, поскольку сеансовый уровень обеспечивает быстрый вызов по сети, когда партнер находится на той же станции. При многоадресной передаче: широковещательный пакет, передаваемый этой станцией, может быть адресован функции, находящейся на этой станции, в результате закольцовывания с канального уровня, когда: (member И (fundi(function_id) = this_station) (final_node = (next_station (next_station (Link_Address AM_SAME_NODE) AND > AM_SAME_STATION) AND > this_station) AND of next_station = defined) шина поезда канальный уровень (next_station = AM_SAME_STATION) OR ((next_station = this_station) AND (final_node > AM_SAME_NODE)) Данная ситуация существует только на узле. Транспортный уровень указывает пересылку данного пакета по шине поезда, указав: (next_station = AM_SAME_STATION). Предполагается, что транспортный уровень проверяет наличие соединения с шиной поезда (например, отсутствие открытия эксплуатации). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 210 – 61375-2-1 IEC:2012 Таблица 23 - Маршрутизация пакетов, поступающих от сети подвижного состава Откуда Куда Сеть подвижного Любая состава 4 транспортный уровень Условие Для всех пакетов сетевой уровень определяет значение next_station, анализируя конечный сетевой адрес: IF (final_node > AM_SAME_NODE) THEN next_station = fundi(AM_ROUTER_FCT) ELSE IF User THEN next_station = fundi(function_id) ELSE next_station = final_station END next_station = stadi (station_id) Все случаи, не охватываемые другими условиями. Пакет не отправляется на шину поезда и не будет получен ни одной станцией. Сетевой уровень передает адрес канала устройстваисточника на транспортный уровень следующей станции. 5 другая сеть подвижного состава 6 шина поезда Ожидается, что транспортный уровень отправит запрос на отключение, если партнер не существует ( (final_node = AM_SAME_NODE) OR (final_node = this_node) ) AND ( (packet_topo = this_topo) OR (packet_topo = AM_ANY_TOPO)) AND ( (final_station > this_station) AND (final_station > AM_SAME_NODE) AND (final_station > AM_UNKNOWN)) Даже если пакет не будет отправлен по шине поезда, его топография будет проверена, если (final_node > AM_SAME_NODE). ((final_node > this_node) AND (final_node > AM_SAME_NODE) AND ((packet_topo = this_topo) OR (packet_topo = AM_ANY_TOPO))) OR member. Пакет отправляется по шине поезда только в том случае, если его значение package_topo является правильным или если используется многоадресная передача. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 211 – Таблица 24 - Маршрутизация пакетов, поступающих от шины поезда Откуда Куда Шина поезда 7 Условие Основное отличие пакетов, поступающих от сети подвижного состава, заключается в обработке топографического счетчика. транспортный уровень В пакеты, поступающих с шины поезда, узел вставляет значение this_topo вместо final_node, чтобы конечная станция могла его проверить. ((final_node = this_node) OR (member)) AND ((final_station = this_station) OR (final_station = AM_SAME_STATION) OR (final_station = AM_UNKNOWN)) Пакет предназначен для данная узла, и никакая другая станция его не примет. 8 сеть подвижного состава Транспортный уровень решает, существует ли партнер. ((final_node = this_node) OR (member)) AND ((final_station > this_station) AND (final_station > AM_SAME_STATION) AND (final_station > AM_UNKNOWN)) К этому узлу подключена станция, которая примет пакет. 9 шина поезда 6.3.5.7 Данная ситуация не предусмотрена. Интерфейс сетевого уровня Интерфейс сетевого уровня к транспортному уровню не указан и не открыт. Приложение может создавать каталоги, которые, по существу, являются частью сетевого уровня, и обращаться к ним посредством интерфейса прикладных сообщений. Транспортный уровень сообщений 6.3.6 6.3.6.1 Цель В данном подразделе представлено два транспортных протокола: Протокол передачи сообщений (MTP), используемый для двухточечной связи; (дополнительный) многоадресный протокол (MCP), используемый для многоадресной передачи. 6.3.6.2 Протокол передачи сообщений Транспортный уровень передает сообщение от поставщика к одному потребителю и предоставляет следующие услуги: a) сегментация длинных сообщений на пакеты фиксированного размера для передачи; b) управление потоком и устранение ошибок от начала до конца посредством протокола скользящего окна; c) отмена. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 212 – 61375-2-1 IEC:2012 Протокол передачи сообщений (MTP) размыкает соединение на время одного сообщения и только в одном направлении. Протокол передачи сообщений (MTP) поддерживает одновременную передачу нескольких сообщений между любыми двумя процессами приложений. Протокол передачи сообщений (MTP) поддерживает одновременную передачу нескольких сообщений одним приложением Каждое соединение отличается ссылочным параметром сеансового уровня «session_ref». Однако протокол передачи сообщений (MTP) поддерживает только одно соединение за один раз и в одном направлении между одними и теми же двумя поставщиками и потребителями. ПРИМЕЧАНИЕ Термины «поставщик» и «потребитель» относятся к отправителю и получателю сообщения на транспортном уровне. Термины «начальный» и «конечный» относятся к конечным партнерам в сети. Термины «источник» и «адресат» относятся к адресу устройства партнеров на одной и той же шине. Протоколы выполняются на каждой станции мессенджером, который, по существу, работает параллельно с приложениями как отдельный процесс. Вызывающий абонент отправляет сообщение вызова в мессенджер через интерфейс прикладных сообщений. Сеансовый уровень мессенджера размыкает соединение (и затем замыкает его). Транспортный уровень делит сообщение на последовательность пакетов данных, достаточно небольшого размера, чтобы поместиться в кадры шины, и отправляет их на сетевой уровень. Сетевой уровень обращается к своим каталогам функций и станций для преобразования адресов пакетов и пересылает пакеты на канальный уровень. Удаленный мессенджер оповещает о прибытии полного сообщения на ответчик, который затем может отправить ответное сообщение в обратном направлении. Протокол передачи сообщений, выполняемый транспортным уровнем поставщика и потребителя, осуществляет управление потоком и восстановление после ошибок для предотвращения потерь или дублирования пакетов. Если оба приложения находятся на одной и той же станции, сеансовые уровень обеспечивает быстрый вызов по сети и позволяет избежать сегментации. Например, пользовательские приложения могут запрашивать услуги местного агента, отправляя ему сообщение без доступа к сети. Мессенджер на каждой станции выполняет протокол передачи. Мессенджер на стороне поставщика делит сообщение на пакеты данных, которые мессенджер на стороне потребителя подтверждает с помощью контрольных пакетов. 6.3.6.3 Обмен пакетами Передача сообщения должна быть разделена на три этапа: a) установление соединения; b) подтвержденная передача данных; c) отсоединение. ПРИМЕР На Рисунке 127 показан простой обмен пакетами с размером окна 1. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 Сеансовый уровень (поставщик ) – 213 – Транспортный уровень Транспортный уровень Сеансовый уровень (потребитель) Соединени е sc_send_msg_requ Запрос на установление соединения таймаут отправк и sc_connect_msg_indicator подтверждение соединения тайм-аут активного состояния Передача DaTa тайм-аут отправки AcK (1) DaTa (1) тайм-аут активного состояния AcK (2) DaTa (2, последнее) sc_send_msg_conf AcK (3) sc_rcv_msg_ind ALIVE_TMO[0] Отсоединение Рисунок 127 - Обмен передаваемыми пакетами 6.3.6.3.1 Установление соединения Поставщик направляет запрос потребителю принять сообщение, отправляя пакет с запросом на установление соединения. Этот пакет содержит общую длину сообщения, размер пакетов, размер окна и ссылку на соединение, предоставленную транспортным уровнем, что однозначно идентифицирует запрос на установление соединения на случай, если его необходимо повторить. Потребитель отвечает на пакет с запросом на установление соединения либо через подтверждение соединения, если он принимает сообщение, либо через пакет с запросом на отключение, если он отклоняет его. Размер окна согласовывается во время установления соединения: поставщик предлагает кредит, а потребитель отвечает приятным кредита, который не может быть выше предложенного кредита. То же самое относится и к размеру пакета. Пакет с запросом на установление соединения имеет наименьший возможный размер в сети, составляющий 256 бит, который может передать многофункциональная поездная шина. Кредит и размер пакета, которые возвращает потребитель, сохраняются для всех последующих пакетов того же сообщения. Поставщик может вставить до 14 октетов данных в пакет с запросом на установление соединения. Сообщение, меньшее или равное 14 октетам, может быть полностью доставлено потребителю без пакетов DATA. Затем пакет с подтверждением соединения подтверждает прием всего сообщения. Если запрос на установление соединения не подтвержден или не отменен, процедура перед отключением должна предпринять попытку повторной передачи до трех раз. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 214 – 6.3.6.3.2 Подтвержденная передача данных Поставщик отправляет отдельные пакеты данных сообщения потребителю. Он может отправлять большинство пакетов AcpCredit (Принятый кредит), не получая для них подтверждения. Потребитель должен положительно подтвердить пакеты данных пакетом с подтверждением, указывающим номер следующего пакета, который он ожидает. Сторона потребителя может объединять подтверждения, т.е. подтверждать несколько пакетов одновременно, подтверждая только пакет с наивысшим порядковым номером. Поставщик должен иметь возможность обрабатывать объединенные подтверждения. Когда пакеты перестают быть подтверждены, транспортный уровень должен повторно передать их максимум три раза перед отключением. Потребитель может сообщить поставщику, что он получил пакет вне очереди. В этом случае он должен отправить пакет с отрицательным подтверждением (Negative_Acknowledgement), указывающий, из какого пакета требуется осуществить повторную передачу. 6.3.6.3.3 Отсоединение Отключение является неявным, если передача не была отменена явным образом. Однако соединение не будет разорвано немедленно, поскольку поздние пакеты все еще могут приходить после потери подтверждения. Отключение является явным, когда поставщик или потребитель отправляет пакет с запросом на отключение. Любая сторона, получившая запрос на отключение (за исключением ответа на запрос на установление соединения или запрос на отключение с причиной AM_REM_CANC), отвечает пакетом с подтверждением отключения. В качестве исключения из этого правила станция-маршрутизатор может отправить запрос на отключение, если она не может должным образом пересылать пакеты, например, вследствие изменения состава. ПРИМЕЧАНИЕ Поскольку сетевой уровень не должен воздействовать на протокол, этот пакет перенаправляется на транспортный уровень маршрутизатора, который отправляет запрос на отключение. 6.3.6.4 Ссылка на соединение Каждый запрос на установление соединения Connection_Reference (ссылка на соединение). должен быть идентифицирован параметром Ссылка на соединение должна представлять собой 16-битное число, инициализированным произвольным значением при запуске (например, взятым из часов реального времени). Транспортный уровень должен увеличивать параметр Connection_Reference (ссылка на соединение) на 1 для каждого нового исходящего соединения на этой станции. Ссылка на соединение должна использоваться приложением вызывающего абонента для пары вызовответ. ПРИМЕЧАНИЕ Ссылка на соединение различает повторный запрос на установление соединения (если произошла ошибка передачи) и новый запрос. ПРИМЕЧАНИЕ 2 В таблицах перехода состояний ссылка на соединение называется conn_ref. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 6.3.6.5 6.3.6.5.1 – 215 – Пакеты транспортного уровня Типы пакетов Транспортный уровень должен работать с семью типами пакетов, показанными на Рисунке 128 и указанными в следующих подразделах. Контроль передачи сообщений сетевой заголовок cr_credit CR cr_conn_ref 8 16 биты; cr_session_header cr_pack_size cr_msg_size 32 cr_data 4 4 8 до 112 бит cc_credit cc_pack_size сетевой CC заголовок cc_conn_ref 8 бит сетевой заголовок сетевой заголовок 16 DR dr_reason 8 8 DC dc_reason 4 4 8 сетевой заголовок DT dt_data 4 13 dt_e сетевой заголовок до 176 бит в MVB, 984 бит в WTB dt_seq_nr AK ak_seq_nr 413 сетевой заголовок NK nk_seq_nr 413 Рисунок 128 - Форматы пакетов (тело транспортного уровня) ПРИМЕЧАНИЕ 1 Сетевой заголовок указан в спецификации сетевого уровня. ПРИМЕЧАНИЕ 2 Заголовок канала указывается в спецификации уровня канала (зависит от шины). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 216 – 6.3.6.5.2 Кодирование контроля передачи сообщений Поле контроля передачи сообщений должно быть закодировано в соответствии с указанным в Таблице 25. Таблице 25 - Кодирование контроля передачи сообщений Тип пакетов Пакет Сокра щение Кодирование Connect_Request (Запрос на установление соединения) (Connect_Confirm) (Подтверждение соединения) Disconnect_Request (Запрос на отключение) Disconnect_Confirm (Подтверждение отключения) CR cl 0 0 0 0 0 0 0 CC cl 1 0 0 0 0 0 1 DR cl co 0 0 0 0 1 0 DC cl co 0 0 0 0 1 1 Broadcast_Connect (Широковещательное соединение) (многоадресная Broadcast_Data (Широковещательные данные) передача) Broadcast_Repeat (Повтор широковещательной передачи) Broadcast_Stop (Прекращение широковещательной передачи) BC 1 0 0 0 1 0 bc_rept BD 1 0 0 0 1 1 0 0 BR 1 1 0 0 1 1 0 1 BS 1 co 0 0 1 1 1 0 Data (Данные) DT cl 0 0 1 dt_e dt_seq_nr Acknowledgement (Подтверждение) AK cl 1 1 0 ak_e ak_seq_nr Negative Acknowledgement (Отрицательное подтверждение) NK cl 1 1 1 nk_e nk_seq_nr Управление (одноадресная передача) Информация Первый бит в поле управления (cl) должен отличать дейтаграмму вызова (1) от дейтаграммы ответа (0). Второй бит (co) должен различать является ли источник потребителем (1) или поставщиком (0). Для бита «dt_e» (конец передачи) должно быть установлено значение «1» в последнем пакете сообщения. Неопределенные комбинации зарезервированы. ПРИМЕЧАНИЕ «CL» по существу является частью сеансового уровня, но также используется для транспортного уровня. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.6.5.3 – 217 – Кодирование Am_Result Результат передачи кодируется в пакете полем типа Am_Result: Am_Result::= { AM_OK AM_FAILURE AM_BUS_ERR AM_REM_CONN_OVF AM_CONN_TMO_ERR AM_SEND_TMO_ERR AM_REPLY_TMO_ERR AM_ALIVE_TMO_ERR AM_NO_LOC_MEM_ERR AM_NO_REM_MEM_ERR ENUM8 (0) (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) AM_ADDR_FMT_ERR (12) AM_NO_REPLY_EXP_ERR (13) AM_NR_OF_CALLS_OVF (14) AM_REPLY_LEN_OVF (15) AM_DUPL_LINK_ERR (16) AM_MY_DEV_UNKNOWN_ERR устройство AM_NO_READY_INST_ERR AM_NR_OF_INST_OVF (19) ответчика AM_CALL_LEN_OVF (20) AM_UNKNOWN_DEST_ERR (21) AM_INAUG_ERR (22) поезда AM_TRY_LATER_ERR (23) AM_FIN_NOT_REG_ERR (24) AM_GW_FIN_NOT_REG_ERR AM_GW_ORI_REG_ERR AM_MAX_ERR } (26) (31) ------ успешное завершение неустановленный сбой передача по шине невозможна слишком много входящих соединений не получено ответа на запрос на установление соединения -- тайм-аут SEND_TMO истек -- ответ не получен -- тайм-аут ALIVE_TMO истек -- недостаточно памяти или времени -- недостаточно памяти или времени партнера AM_REM_CANC_ERR -- отменено партнером AM_ALREADY_USED -- некоторые операции уже выполнены -- ошибка формата адреса -- такой ответ не ожидается -- запрошено слишком много вызовов -- слишком длинное ответное сообщение -- ошибка дублирования сеанса связи (17) -- неизвестно собственное (18) -- не готов экземпляр ответчика -- слишком много экземпляров -- слишком длинное сообщение вызова -- неизвестное устройство партнера -- произошло открытие эксплуатации -- (только внутреннее использование) -- конечный адрес не зарегистрирован (25) -- конечный адрес на зарегистрирован в маршрутизаторе -- начальный адрес не зарегистрирован в маршрутизаторе -наивысший системный код. -коды пользователей выше 31 ПРИМЕЧАНИЕ Перечисленный тип Am_Result соответствует параметру AM_RESULT, возврат которого осуществляется процедурами прикладного уровня, а также процедурами сеансового уровня и транспортного уровня. AM_RESULT является типом параметра в синтаксисе языка «C», а Am_Result определяет кодирование этого типа для передачи. 6.3.6.5.4 Кодирование пакета (см. Таблицы 26 - 36) Пакеты должны быть отформатированы следующим образом: Message_Packet::= RECORD { call_not_reply { REPLY_MSG (0), CALL_MSG (1) consumer_not_producer ENUM1 -- первый бит отличает вызов от ответа -- ответное сообщение -- сообщение вызова ENUM1 -- второй бит отличает потребителя от поставщика { Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 218 – CONSUMER (0), PRODUCER (1) }, packet_kind { CONTROL (0) DATA (1) ACK (2) NAK (3) ONE_OF [packet_type] { [SP] [DATA] [ACK] [NAK] } } Control_Packet::= RECORD { command::== { CR (0), CR (1), CR (2), CR (3), BC1 (8) BC2 (9) BC3 (10) BS (12) (дополнительно) BS (13) (дополнительно) BS (14) (дополнительно) }, ONE_OF [command] { [CR] CC] [DR] [DC] [BC1] [BC2] [BC3] [BC1] 6.3.7.5 [BC1] 6.3.7.5 [BC1] } } -- подтверждение подтверждение от поставщика -- от потребителя ENUM2 -- 3-й и 4-й отличают ----- биты packet_kind управляющее сообщение передача данных положительное подтверждение отрицательное подтверждение Control_Packet Data_Packet, Ack_Packet, Nak_Packet ----- управление передача данных положительное подтверждение отрицательное подтверждение ENUM4 -- последние четыре бита октета МТС указывают на команду ------ запрос на установление соединения подтверждение соединения запрос на отключение подтверждение отключения первая попытка запроса на широковещательную передачу (дополнительно) -- вторая попытка запроса на широковещательную передачу (дополнительно) -- третья попытка запроса на широковещательную передачу (дополнительно) -- прекращение широковещательной передачи -- повтор широковещательной передачи -- данные широковещательной передачи -- в зависимости от MTC Connect_Request (Запрос на соединение), Connect_Confirm (Подтверждение соединения), Disconnect_Request (Запрос на отключение), Disconnect_Confirm (Подтверждение отключения), Broadcast_Connect (Широковещательное соединение), -- см. Broadcast_Connect (Широковещательное соединение), -- см. Broadcast_Connect (Широковещательное соединение), -- см. Broadcast_Repeat (Повтор широковещательной передачи), 6.3.7.5 6.3.7.5 6.3.7.5 -- см. Broadcast_Stop (Прекращение широковещательной передачи), -- см. Broadcast_Data (Широковещательные данные), -- см. 6.3.7.5 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 219 – Таблица 26 - Connect_Request (Запрос на соединение) 7 6 5 4 3 2 1 0 cl 0 0 0 0 0 0 0 cr_conn_ref cr_msg_size cr_credit cr_pack_size cr_session_header cr_data (до 14 октетов) Connect_Request::= RECORD { cr_conn_ref UNSIGNED16 соединение cr_msg_size сообщения в cr_credit UNSIGNED4 cr_pack_size { MVB_PACKET (0), ENUM4 -- 16-битная ссылка на UNSIGNED32 -- общий размер октетах, макс. 4 Гб -- предлагаемый кредит: ‘0000’B = 0 (прекращение связи)‘0111’B = 7 (максимум) -- предлагаемый размер пакета, -- передаваемые данные = 22 октета/пакет (MVB) -- передаваемые данные = 123 октета/пакет (WTB) остальные значение зарезервированы. WTB_PACKET (1) }, cr_session_header Am_Result -- AM_OK в вызове, запрашивающем ответ ARRAY [14] OF WORD8 -- до 14 октетов передаваемых данных cr_data } Таблица 27 - Connect_Confirm (Подтверждение соединения) 7 6 5 4 3 2 1 0 cl 1 0 0 0 0 0 1 cc_conn_ref cc_credit Connect_Confirm::= RECORD { cc_conn_ref UNSIGNED16 в запросе не соединение. cc_credit UNSIGNED4 cc_pack_size -- то же значение, которое было получено -- принятый кредит: ‘0000’B = 0 (прекращение Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 220 – cr_pack_size { MVB_PACKET (0), связи)‘0111’B = 7 (максимум) -- принятый размер пакета ENUM4 -- размер передаваемых данных = 22 октета/пакет (MVB) -- размер передаваемых данных = 123 октета/пакет (MVB) -- остальные значение зарезервированы. MVB_PACKET (1), } } Таблица 28 - Disconnect_Request (Запрос на отключение) 7 6 5 4 3 2 1 0 cl co 0 0 0 0 1 0 dr_reason Disconnect_Request::= RECORD { dr_reason Am_Result } -- причина отключения Таблица 29 - Disconnect_Confirm (Подтверждение отключения) 7 6 5 4 3 2 1 0 cl co 0 0 0 0 1 1 dc_reason Disconnect_Confirm::= RECORD { dc_reason Am_Result -- причиной является AM_OK, если отключение прошло успешно } Таблица 30 - Data_Packet (Пакет данных) 7 6 5 4 3 cl 0 0 1 dt_e 2 1 0 dt_seq_nr dt_data (до размера передачи данных в октетах) Data_Packet::= RECORD { dt_e dt_seq_nr dt_data } -- начинается с последних четырех битов октета МТС BOOLEAN1 -- 1 = конец сообщения (не сеанса) UNSIGNED3 -- порядковый номер этого пакета, как его видит поставщик. ARRAY [transport_data_size] OF WORD8 -- за исключением, возможно, последнего сообщения. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 221 – Таблица 31 - Ack_Packet 7 6 5 4 3 cl 1 1 0 ak_e Data_Packet::= RECORD { ak_e (0) ak_seq_nr пакетов, 2 1 0 ak_seq_nr -- последние четыре бита октета МТС ENUM1 (=0) UNSIGNED3 -- всегда FALSE (ЛОЖНО) -- число следующих ожидаемых потребителем. } Таблица 32 - Nak_Packet 7 6 5 4 3 2 CL 1 1 1 nk_e Nak_Packet::= RECORD { nk_eot nk_seq_nr 1 0 nk_seq_nr -- последние четыре бита октета МТС -- всегда FALSE (ЛОЖНО) (0) -- число следующих пакетов, ожидаемых потребителем BOOLEAN1 UNSIGNED3 } Следующие пакеты используются только в сочетании с многоадресной передачей (опция): Таблица 33 - Broadcast_Connect (Широковещательное соединение) (BC1, BC2, BC3) 7 6 1 0 0 5 0 4 1 3 0 2 1 0 bc_rept bc_run_nr bc_msg_size bc_data (до 18 октетов) Broadcast_Connect::= RECORD { bc_run_nr bc_msg_size bc_data -- указано здесь для 6.3.7.5 -- BC1, BC2 и BC3 различаются bc_rept UNSIGNED16 -- ссылка на соединение, идентифицирующая данное сообщение UNSIGNED16 -- общий размер сообщения в октетах ARRAY [18] OF WORD8 -- до 18 октетов пользовательских данных } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 222 – Таблица 34 - Broadcast_Data (Широковещательные данные) 7 6 5 4 3 2 1 0 1 0 0 0 1 1 0 0 bd_run_nr bd_offset bd_data Broadcast_Data::= RECORD { bd_run_nr UNSIGNED16 сообщение bd_offset bd_data -- указано здесь для 6.3.7.5 -- Ссылка на соединение, идентифицирующая данное UNSIGNED16 -- сдвиг bd_data в октетах внутри сообщения ARRAY [18] OF WORD8 -- до 18 октетов пользовательских данных } Таблица 35 - Broadcast_Repeat (Повтор широковещательной передачи) 7 6 5 4 3 2 1 0 1 1 0 0 1 1 0 1 br_run_nr br_offset Broadcast_Repeat::= RECORD { br_run_nr UNSIGNED16 сообщение br_offset октетах, пропущенных bd_data } -- указано здесь для 6.3.7.5 -- Ссылка на соединение, идентифицирующая данное UNSIGNED16 -- сдвиг bd_data в Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 223 – Таблица 36 - Broadcast_Stop (Прекращение широковещательной передачи) (BSC, BSO) 7 6 5 4 3 2 1 0 1 co 0 0 1 1 1 0 br_run_nr Broadcast_Stop::= RECORD { bs_run_nr UNSIGNED16 -- указано здесь для 6.3.7.5 -- Ссылка на соединение, идентифицирующая данное сообщение } 6.3.6.6 Диаграммы перехода состояния 6.3.6.6.1 Состояния Протокол передачи сообщений должен реализовать для каждого поставщика или потребителя автомат протокола передачи сообщений с состояниями, перечисленными в Таблице 37. Таблица 37 - Состояния протокола передачи сообщений Имя состояния DISC Место возникновения Поставщик Краткое описание отключено Потребитель SETUP Поставщик Ожидание пакета CC SEND Поставщик открыто для отправки сообщения SEND_CANC Поставщик пакет DR отправлен, ожидание пакета DC CLOSED Поставщик или DR пакет DR получен LISTEN Потребитель ожидание подтверждение пакета CC пакет RCV_CANC Потребитель DR отправлен, ожидание пакета DC или DR RECEIVE Потребитель открыто для получения сообщения и всех подтвержденных полученных пакетов PEND_ACK Потребитель открыто для получения сообщения и всех подтвержденных неполученных пакетов FROZEN Потребитель полное сообщение с полученным пакетом DT (EOT) LISTEN_FROZEN Потребитель полное сообщение с полученным пакетом CR Состояния и переходы экземпляра транспортного уровня (поставщик или потребитель) показаны на Рисунке 129 и указаны в следующих подразделах. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 224 – 61375-2-1 © IEC:2012 Состояния поставщика SETUP SEND SEND_ CANC Переходы CLOSED состояния: нормальное LISTEN_ FROZEN DISC при тайм-ауте при отмене (tm_cancel_msg) Состояние потребителя LISTEN FROZEN RECEIVE RCV_ CANC PEND_ ACK Рисунок 129 - Диаграмма перехода состояния протокола передачи сообщений 6.3.6.6.2 Входящие события Входящие события, перечисленные в Таблице 38, генерируемые сетью, пользователем или тайм-аутами, могут вызывать переходы из одного состояния протокола передачи сообщений в другое. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 225 – Таблица 38 - Входящие события протокола передачи сообщений Имя события Интерфейс от пользователя tm_send_req Краткое описание события запрос на отправку сообщения, пользователь отправляет мессенджеру буфер сообщений от пользователя tm_cancel_req отменяет передачу входящего или исходящего сообщения, мессенджер возвращает буфер сообщений пользователю, если операция отмены прошла успешно rcv_CR от сети получен пакет CR rcv_CC от сети получен пакет CC rcv_DT от сети получен пакет DT rcv_AK от сети получен пакет AK rcv_NK от сети получен пакет NK получен пакет DR rcv_DR от сети rcv_DC от сети TMO внутреннее 6.3.6.6.3 получен пакет DC истек тайм-аут (одновременно работает только один) Исходящие события Исходящие события, перечисленные в Таблице 39, генерируемые автоматом протокола передачи сообщений, могут вызывать переходы из одного состояния протокола передачи сообщений в другое на другом автомате протокола передачи сообщений. Таблица 39 - Исходящие события протокола передачи сообщений Имя события tm_connect_ind tm_receive_ind tm_send_cnf Интерфейс Индикация для пользователя Индикация для пользователя Подтверждение для пользователя Краткое описание события пользователь должен принять или отклонить входящий запрос на соединение; пользователь отправляет мессенджеру буфер сообщений, если пользователь принимает сообщение получено полное сообщение или ошибка сообщения, мессенджер возвращает пользователю буфер сообщений отправлено полное сообщение или ошибка отправки, мессенджер возвращает пользователю send_CR send_CC для сети для сети передача пакета CR send_DT для сети передача пакета DT send_AK для сети передача пакета AK send_NK для сети send_DR для сети send_DC для сети буфер сообщений передача пакета CC передача пакета NK передача пакета DR передача пакета DC Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 226 – Параметры управления в пакетах 6.3.6.6.4 Обмениваемые пакеты должны содержать параметры управления, перечисленные в Таблице 40. Таблица 40 - Параметры управления протокола передачи сообщений Собы тие send_CR (поля) Поле Краткое описание поля CR_conn_ref, ссылка на соединение rcv_CR (поля) CR_credit, предлагаемый кредит CR_pack_size код размера предлагаемого пакета send_CC (поля) CC_conn_ref, ссылка на соединение rcv_CC (поля) CC_credit, принятый кредит CC_pack_size код размера принимаемого пакета send_DT (поля) DT_seq_nr, номер пакета rcv_DT (поля) DT_eot флаг передачи конца сообщения send_NK (поля) NK_seq_nr номер следующего ожидаемого пакета AK_seq_nr номер следующего ожидаемого пакета DR_reason причина отключения, код ошибки Am_Result rcv_NK (поля) send_AK (поля) rcv_AK (поля) send_DR (поля) rcv_DR (поля) Для событий отправки (send_xx) фактические параметры указываются в полях управления, а для событий приема (rcv_xx) формальные имена поле указываются в действиях. 6.3.6.6.5 Вспомогательные переменные Диаграмма перехода состояний опирается на вспомогательные переменные, перечисленные в Таблице 41, для уменьшения количества состояний. Некоторые переменные существуют только у поставщика или только у потребителя и принадлежат соединению, в то время как глобальные переменные используются для всех соединений совместно. Таблица 41 - Вспомогательные переменные протокола передачи сообщений Имя переменной Контекст Краткое описание переменной my_credi Глобальная собственный максимальный принятый кредит t run_nr Глобальная следующая свободная ссылка на соединение my_pack_size Глобальная код размера собственного максимального принятого пакета отмененный Поставщик, Потребитель данное сообщение было отменено пользователем принятый кредит Поставщик, Потребитель кредит для данного соединения ожидаемый Поставщик, Потребитель нижний фронт отправки (поставщик) или получения conn_ref Поставщик, Потребитель (потребитель) Ссылка на соединение для данного соединения rep_cnt Поставщик, Потребитель new_cnt Потребитель количество повторений количество неприятных пакетов next_send Поставщик номер следующего пакета для передачи send_not_yet Поставщик верхний фронт окна отправки eot Поставщик передано полное сообщение размер Поставщик размер принятого пакета для данного соединения ошибка Поставщик код ошибки AM_xxx для отчета с подтверждением отправки Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 6.3.6.6.6 – 227 – Действия и тайм-ауты Каждое соединение должно иметь собственный таймер для контроля тайм-аута. Управление таймером должно осуществляться посредством действий «restart_tmo» и «reset_tmo», а также таймер должен генерировать внутреннее событие TMO по истечении тайм-аута. Переходы между состояниями регулируются тремя тайм-аутами: SEND_TMO, тайм-аут отправки на поставщике, ACK_TMO, тайм-аут подтверждения на потребителе, и ALIVE_TMO, тайм-аут активного состояния на потребителе. Если поставщик не получает пакет с подтверждением для пакета, отправленного в рамках тайм-аута SEND_TMO, поставщик должен отправить этот же пакет еще раз. Если поставщик не получает пакет с подтверждением для пакета, отправленного после количества неудачных попыток, равных MAX_REP_CNT, поставщик должен отключиться. Максимальное значение количества повторений MAX_REP_CNT должно быть равно трем. Потребитель должен подтверждать пакеты немедленно, когда кредит исчерпан или, когда сообщение полностью получено. Максимальное значение кредита AM_MAX_CREDIT должно быть равно семи. В противном случае потребитель должен задержать подтверждение на тайм-аут подтверждения ACK_TMO, чтобы подтвердить несколько пакетов одним подтверждением. Значение тайм-аута отправки SEND_TMO является параметром конфигурации. Тайм-аут отправки SEND_TMO должен более чем в два раза превышать сумму задержки передачи сети в наихудшем случае (NET_DELAY), плюс время обработки пакета на станции (PROC_DELAY), плюс таймаут подтверждения ACK_TMO, как показано на Рисунке 130. NET_DELAY DT PROC_DELAY SEND_TMO ACK_TMO PROC_DELAY AK NET_DELAY SEND_TMO = 2 (NET_DELAY + PROC_DELAY) + Рисунок 130 - Тайм-аут SEND_TMO Потребитель пакета должен ожидать следующий пакет (с тем же или другим порядковым номером) в пределах тайм-аута ALIVE_TMO. Если в течение этого времени он не получает пакетов, он должен отключить сеанс связи. Значение тайм-аута активного состояния ALIVE_TMO является параметром конфигурации. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 228 – 61375-2-1 © IEC:2012 Значение тайм-аута активного состояния ALIVE_TMO должно быть, как минимум в MAX_REP_CNT больше значения тайм-аута отправки SEND_TMO, плюс время существования пакетов PACK_LIFE_TIME в очередях связи, как показано на Рисунке 131. DT(n-1) < SEND_TMO AK PROC_DELAY DT(n) SEND_TMO PROC_DELAY ALIVE_TMO DT(n) SEND_TMO PROC_DELAY DT(n) PACK_LIFE_TIME ALIVE_TMO = MAX_REP_CNT (SEND_TMO + PROC_DELAY) + Рисунок 131 - Тайм-аут ALIVE_TMO Значения по умолчанию для наихудшего случая приведены в Таблице 42. Таблица 42 - Тайм-ауты протокола передачи сообщения (наихудший случай) NET_ DELAY PROC_ DELAY PACK_LIFE_ TIME ACK_ TMO SEND_ TMO ALIVE_ TMO та же шина 0,5 с 64 мс 5,0 с 0,25 с 1,4 с 9,5 с сеть подвижного состава для сети подвижного состава на шине поезда 9,6 с 64 мс 5,0 с 2,5 с 21,0 с 71,0 с ПРИМЕЧАНИЕ PACK_LIFE_TIME указан на соответствующем канальном уровне. 6.3.6.6.7 Неявные действия Описания действий в следующих переходах состояний могут содержать неявные действия, указанные в Таблице 43. Таблица 43 - Неявные действия Ссылка Неявное действие (1) Состояние AM_BUS_ERR отображается, если по шине не удалось отправить пакет CR (2) операции с номерами пакетов по модулю 8, сравнения режимов обратной ретрансляции (3) В этом случае отмена всегда будет TRUE (ИСТИНА). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.6.6.8 – 229 – Комплексные действия Действия, перечисленные в Таблице 44, выполняются при нескольких переходах состояний. Таблица 44 - Комплексные действия Имя действия Краткое описание действия reset_tmo останавливает таймер и запускает его с тайм-аутом xxx_TMO; останавливает таймер; close_send (error) IF (NOT cancelled) THEN restart_tmo (xxx_TMO) Следующее состояние - tm_send_cnf (error); END; reset_tmo DISC close_rcv (error) IF (NOT cancelled) THEN tm_send_cnf (error); END; IF (error > AM_OK) THEN reset_tmo; ELSE restart_tmo (ALIVE_TMO); END; DISC update (eot) eot:= сообщение завершается следующим пакетом; send_data_or_cancel IF cancelled THEN send_DR (AM_REM_CANC_ERR); rep_cnt:= 0; restart_tmo (SEND_TMO); SEND_CANC ELSE REPEAT update (eot) send_DT (next_send, eot); next_send:= next_send + 1; (2) UNTIL (eot OR (next_send = send_not_yet)); rep_cnt:= 0; restart_tmo (SEND_TMO); END; SEND Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 230 – 6.3.6.6.9 Таблица состояний и событий поставщика Поставщик в текущем состоянии при возникновении события должен перейти в следующее состояние и выполнить действие, указанное в Таблице 45. Таблица 45- Состояния поставщика и переходы Текущее состояние Событие Действие(я) (любое) tm_cancel_req cancelled:= TRUE; DISC tm_send_req update (eot) Следующее состояние (если>текущее) end_CR ( run_nr, AM_MAX_CREDIT, my_pack_size); conn_ref:= run_nr; run_nr:= run_nr +1; restart_tmo (SEND_TMO); expected:= 0; rep_cnt:= 0; cancelled:= FALSE; SETUP SETUP rcv_DR close_send (DR_reason); DISC rcv_CC AND (conn_ref = CC_conn_ref) IF (eot) THEN close_send (AM_OK); ELSE DISC credit:= CC_credit; size:= decode (CC_pack_size); next_send:= 0; send_not_yet:= credit; send_data_or_cancel; END; SEND или SEND_CANC TMO AND (rep_cnt = MAX_REP_CNT) close_send (AM_CONN_TMO_ERR); (1) DISC TMO AND (rep_cnt MAX_REP_CNT) end_CR ( conn_ref, AM_MAX_CREDIT, my_pack_size); rep_cnt:= rep_cnt + 1; restart_tmo (SEND_TMO); Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 231 – Таблица 45 (продолжение) Текущее состояние SEND Событие rcv_DR Действие( я) Следующее состояние (если>текущее) send_DC; error:= DR_reason; restart_tmo (ALIVE_TMO); rcv_AK AND expected:= AK_seq_nr; (expectedAK_seq_nr= send_not_yet) (2) send_not_yet:= expected + credit; (2) IF (NOT eot) THEN send_data_or_cancel; CLOSED SEND или SEND_CANC ELSIF (expected = next_send) THEN close_send (AM_OK); DISC ELSE REPEAT send_DT(expected, eot); expected := expected + 1; (2) UNTIL (expected = next_send); restart_tmo (SEND_TMO); rep_cnt := rep_cnt + 1; SEND END; TMO AND местная (rep_cnt MAX_REP_CNT) переменная: seq_nr; seq_nr:= expected; WHILE (seq_nr (next_send-1)) DO (2) send_DT (seq_nr, FALSE); END; send_DT (next_send-1, eot); (2) rep_cnt:= rep_cnt + 1; TMO AND restart_tmo (SEND_TMO); close_send (AM_SEND_TMO_ERR); (rep_cnt = MAX_REP_CNT) DISC rcv_NK AND expected:= NK_seq_nr; (expectedNK_seq_nr= send_not_yet) (2) send_not_yet:= expected + credit; (2) IF (NOT eot) THEN IF cancelled THEN send_DR (AM_REM_CANC_ERR); restart_tmo (SEND_TMO); SEND_CANC ELSE Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 232 – Таблица 45 (продолжение) Текущее состояние Событие Действие(я) Следующее состояние (если>текущее) REPEAT update (eot) send_DT (next_send, eot); (2) next_send:= next_send + 1; UNTIL (eot OR (next_send = send_not_yet)); restart_tmo (SEND_TMO); END; SEND_CANC rcv_DC close_send; (3) DISC rcv_DR restart_tmo (ALIVE_TMO); (3) CLOSED TMO AND close_send; (3) DISC (rep_cnt = MAX_REP_CNT) TMO AND send_DR (AM_REM_CANC_ERR); (rep_cnt MAX_REP_CNT) rep_cnt:= rep_cnt + 1; restart_tmo (SEND_TMO); CLOSED TMO close_send (error); DISC Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.6.6.10 – 233 – Таблица состояний и событий потребителя Потребитель в текущем состоянии при возникновении события должен перейти в следующее состояние и выполнить действие, указанное в Таблице 46. Таблица 46- Состояния потребителя и переходы Текущее состояние Событие Действие(я) (любое) tm_cancel_req cancelled:= TRUE; DISC rcv_DR send_DC (dc_reason); DISC или rcv_CR cancelled:= FALSE; FROZEN Следующее состояние (если>текущее) new_cnt:= 0; expected:= 0; tm_connect_ind (VAR err); IF (err = AM_OK) THEN conn_ref:= CR_conn_ref; credit:= min (my_credit, CR_credit); send_CC (conn_ref, credit, min (CR_pack_size, my_pack_size); LISTEN_ FROZEN rcv_CR AND IF (eot) THEN (CR_conn_ref > conn_ref) close_rcv (AM_OK); LISTEN_ FROZEN ELSE restart_tmo (ALIVE_TMO); END; LISTEN ELSE send_DR (err); END; LISTEN_ FROZEN rcv_CR AND (CR_conn_ref = conn_ref) DISC send_CC ( conn_ref, credit, min (CR_pack_size, my_pack_size); FROZEN ИЛИ TMO LISTEN_ FROZEN DISC Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 234 – Таблица 46 (продолжение) Текущее состояние LISTEN Событие rcv_CR AND (CR_conn_ref = conn_ref) rcv_CR AND Действие(я) send_CC ( conn_ref, credit, min (CR_pack_size, my_pack_size); restart_tmo (ALIVE_TMO); close_rcv (AM_FAILURE); (CR_conn_ref > conn_ref) TMO Следующее состояние (если>текущее) DISC close_rcv (AM_ALIVE_TMO_ERR); DISC LISTEN или rcv_DR RECEIVE или send_DC(dc_reason); close_rcv (DR_reason); PEND_ACK DISC rcv_DT AND cancelled send_DR (AM_REM_CANC_ERR); rep_cnt:= 0; restart_tmo (SEND_TMO); RCV_CANC rcv_DT AND NOT cancelled AND expected:= expected + 1; (2) (DT_seq_nr = expected) IF (DT_eom) THEN new_cnt:= new_cnt + 1; send_AK (expected); close_rcv (AM_OK); FROZEN ELSIF (new_cnt = credit) THEN send_AK (expected); new_cnt:= 0; restart_tmo (ALIVE_TMO); RECEIVE ELSIF (state = RECEIVE) OR (state = LISTEN) THEN restart_tmo (ACK_TMO); END; PEND_ACK rcv_DT AND NOT cancelled AND (DT_seq_nr > expected) send_NK (expected); new_cnt:= 0; restart_tmo (ALIVE_TMO); RECEIVE RECEIVE TMO close_rcv (AM_ALIVE_TMO_ERR); DISC Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 235 – Таблица 46 (продолжение) Текущее состояние PEND_ACK Событие TMO Действие(я) Следующее состояние (если>текущее) send_AK (expected); new_cnt:= 0; restart_tmo (ALIVE_TMO); RECEIVE FROZEN rcv_DT send_AK (expected); RCV_CANC TMO AND send_DR (AM_REM_CANC_ERR); (rep_cnt MAX_REP_CNT) restart_tmo (SEND_TMO); rep_cnt:= rep_cnt + 1; TMO AND close_rcv (AM_FAILURE); (3) (rep_cnt = MAX_REP_CNT) rcv_DR OR rcv_DC DISC close_rcv (AM_FAILURE); (3) DISC 6.3.6.7 Интерфейс передачи сообщений Интерфейс передачи сообщений (Transport_Message_Interface) транспортного уровня сеансовому уровню. предоставляет услуги Этот интерфейс может оставаться внутренним для устройства. Данный интерфейс не подлежит проверке соответствия. Следующие спецификации включены для улучшения переносимости. Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. 6.3.6.7.1 Обмен данными на транспортном уровне На Рисунке 132 показано взаимодействие между транспортным уровнем и сеансовым уровнем. Маркеры указывают, в каком направлении передаются параметры. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 236 – Сеанс (поставщик) Транспорт Сеть 61375-2-1 © IEC:2012 Сеанс (потребитель) Транспорт tm_send_req session_ref sm_connect_ind msg_buf cancel_ref cancel_ref session_ref msg_buf tm_cancel_req tm_cancel_req cancel_ref cancel_ref msg_buf msg_buf sm_receive_ind msg_buf session_ref session_ref msg_buf время sm_send_cnf Рисунок 132 - Транспортный интерфейс Поставщик отправляет сообщение, содержащееся в msg_buf, путем вызова tm_send_req, идентифицируя соединение с помощью ссылки на сеанс «session_ref». После завершения передачи (успешно или нет), транспортный уровень вызывает параметр sm_send_cnf (с той же ссылкой session_ref), который затем освобождает буфер сообщений. На стороне потребителя транспортный уровень вызывает параметр sm_connect_ind для уведомления сеансового уровня о запросе на соединение. Если сеансовый уровень принимает запрос на соединение, он предоставляет буфер msg_buf для транспортного уровня для размещения сообщения. Транспортный уровень вызывает sm_received_ind, когда сообщение полностью получено (или было отменено другой стороной). Данный вызов содержит «session_ref». Любая сторона может отменить передачу сообщения, вызвав tm_cancel_req. Примитивы интерфейса передачи сообщений (TMI) имеют префикс tm_. Транспортный уровень вызывает процедуры сеансового уровня (с префиксом sm_), на которые ранее была сделана подписка, и которые имеют тип, определенный транспортным уровнем (с префиксом TM_). Интерфейс TMI определяется постоянными, типами и процедурами, перечисленными в Таблице 47 и указанными в следующих подразделах. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 237 – Таблица 47 - Примитивы TMI Имя Значение Постоянные TM_CALLER_USER пользователь является вызывающим абонентом TM_REPLIER_USER пользователь является ответчиком Типы TM_MSG_DESCR дескриптор сообщения TM_CONV_ID идентификатор сеанса связи Процедура инициализации оповещает пользователя tm_define_user Процедуры поставщика tm_send_req отправляет сообщение TM_SEND_CNF подтверждает отправку, процедура индикации, типа sm_send_cnf sm_send_cnf вызывается, когда сообщение получено (или было отменено) Процедуры потребителя TM_CONNECT_IND тип sm_connect_ind sm_connect_ind указывает на поступление запроса на соединение TM_RECEIVE_IND тип sm_receive_ind sm_receive_ind вызывается, когда сообщение было полностью получено Процедуры потребителя и поставщика отменяет сообщение tm_cancel_req 6.3.6.7.2 Тип «TM_MSG_DESCR» Определение Тип сообщения Синтаксис typedef struct Использование 6.3.6.7.3 {} TM_MSG_DESCR; скрытая структура, используемая в качестве дескриптора для очистки заблокированных структур данных. Тип «TM_CONV_ID» Определение Тип Conversation_Id (идентификатора сеанса связи) Синтаксис typedef struct UNSIGNED8 UNSIGNED8 UNSIGNED8 UNSIGNED8 str_conv_id { my_fct_or_station; node; function_or_station; next_station } TM_CONV_ID; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 238 – 6.3.6.7.4 61375-2-1 IEC:2012 Процедура «tm_define_user» Определение Предоставляет подписку на процедуры индикации для пользователя, идентифицированного как вызывающий абонент или ответчик. Синтаксис AM_RESULT tm_define_user ( UNSIGNED who, TM_CONNECT_IND sm_connect_ind, TM_RECEIVE_IND sm_receive_ind, TM_SEND_CNF sm_send_cnf ); Параметр ввода Who пользователь транспортного уровня, либо TM_CALLER_USER, либо TM_REPLIER_USER sm_connect_ind Процедура потребителя, вызываемая при поступлении пакета с запросом на соединение. См. определение типа TM_CONNECT_IND. sm_receive_ind процедура потребителя, которая вызывается, когда сообщение было полностью получено или отменено поставщиком, или в случае ошибки. См. определение типа TM_RECEIVE_IND. sm_send_cnf процедура поставщика, которая вызывается, когда сообщение было полностью получено потребителем или отменено потребителем, или в случае ошибки. См. определение типа TM_SEND_CNF. Возврат Любое значение AM_RESULT Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.6.7.5 – 239 – Процедура «tm_send_req» Определение Запрашивает передачу сообщения Синтаксис AM_RESULT UNSIGNED TM_CONV_ID * void * UNSIGNED32 void * UNSIGNED void * Параметр ввода session _ref, TM_MSG_DESCR * * cancel_ ref, UNSIGNED8 my_topo ); session_user Либо TM_CALLER_USER (сообщение вызова) или TM_REPLIER_USER (ответное сообщение) Conversation Идентификатор сеанса связи (конкатенация адресов вызывающего абонента и ответчика) msg_addr указывает на тело сообщения msg_len общий размер тела сообщения hdr_addr указывает на заголовок сеанса (Session_Header) hdr_len Общий размер заголовка сеанса (Session_Header) session_ref ссылка на сеанс, связывающая «tm_send_req» с соответствующим «sm_send_cnf». my_topo значение счетчика топографии, предоставленное приложением, или 0, если оно неизвестно (= пропуск всех) Любое значение AM_RESULT Возврат Параметр вывода Использование tm_send_req ( session_user, conversation, msg_addr, msg_len, hdr_addr hdr_len, дескриптор заблокированных структур данных транспортного уровня. 1 -Буфер для отправляемого сообщения и буфер для размещения его заголовка сеанса являются отдельными. cancel_ref 2 - «session_ref» предоставляется пользователем транспортного уровня и возвращается транспортным уровнем при вызове «sm_send_cnf». 3 - «cancel_ref» позволяет освободить заблокированные структуры данных. «cancel_ref» больше не допустимо после успешной операции отмены или после возврата «sm_send_cnf». Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 240 – 6.3.6.7.6 61375-2-1 IEC:2012 Тип «TM_SEND_CNF» Определение Когда сообщение было полностью получено или отменено потребителем, или для сообщения об ошибке, транспортный уровень должен вызвать процедуру сеансового уровня sm_send_cnf, которая относится к этому типу. Синтаксис typedef void void * UNSIGNED8 MD_RESULT Параметр ввода ( * TM_SEND_CNF ) ( /* session_ref */ /* my_topo */ status ); session_ref ссылка на сеанс, которая связывает «sm_send_cnf» с предыдущей процедурой «tm_send_req». my_topo если результат AM_OK, топографический счетчик в настоящее время действителен в узле . AM_OK, если сообщение было подтверждено потребителем, в противном случае выдается код ошибки. Status Использование 1 - Для каждого значения tm_send_req транспортный уровень вызывает процедуру сеансового уровня sm_send_cnf, имеющую тип TM_SEND_CNF, чтобы сообщить поставщику о том, что его сообщение было получено или отменено потребителем, или сообщить об ошибке. 2 - sm_send_cnf не вызывается, если соединение было успешно отменено поставщиком. 3 - состояние является входным параметром. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.6.7.7 – 241 – Тип «TM_CONNECT_IND» Определение Получив пакет с запросом на соединение, транспортный уровень на стороне потребителя должен вызвать процедуру sm_connect_ind типа TM_CONNECT_IND. Если sm_connect_ind принимает сообщение, ожидается, что данный вернет результат AM_OK и предоставит буфер для сообщения. Если «sm_connect_ind» возвращает результат, отличный от AM_OK, транспортный уровень должен отклонить соединение и отправить запрос на отключение, используя в качестве параметра «reason» («причина») результат «sm_connect_ind». Синтаксис typedef void const TM_CONV_ID*, void * *, UNSIGNED32, void * *, UNSIGNED *, TM_MSG_DESCR *, UNSIGNED8, AM_RESULT Параметр ввода */ void * *, /* in: my_topo Conversation Идентификатор сеанса связи (конкатенация адресов вызывающего абонента и ответчика) msg_len размер буфера сообщений, предоставляемого сеансовым уровнем дескриптор заблокированных структур данных транспортного уровня. Счетчик топографии узла во время получения запроса на соединение. cancel_ref my_topo Параметр вывода (* TM_CONNECT_IND ) ( /* in: conversation */ /* out: msg_addr */ /* in: msg_len */ /* out hdr_addr */ /* out: hdr_len */ /* in: cancel_ref */ /* out: session_ref /* out: status */ ); hdr_addr указывает на тело сообщения, предоставленное сеансовым уровнем. Указывает на заголовок сеанса (Session_Header) сообщения. hdr_len Общий размер заголовка сеанса (Session_Header) session_ref предоставляется сеансовым уровнем для идентификации заблокированных структур данных на сеансовом уровне. Связывает sm_connect_ind с соответствующим типом sm_receive_ind. AM_OK, если сеансовый уровень принимает соединение, в противном случае причина отклонения (AM_RESULT). msg_addr Status Использование Ожидается, что сеансовый уровень подпишется на процедуру sm_connect_ind типа TM_CONNECT_IND в процедуре tm_define_user. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 242 – 61375-2-1 IEC:2012 Тип «TM_RECEIVE_IND» 6.3.6.7.8 Определение После получения входящего сообщения полностью транспортный уровень должен вызвать процедуру sm_receive_ind типа TM_RECEIVE_IND. Синтаксис typedef void ( * TM_RECEIVE_IND ) ( /* session_ref */ /* status */ ); void *, AM_RESULT Параметр ввода session_ref ссылка на сеанс, которая связывает sm_receive_ind с предыдущей процедурой sm_connect_ind. Status AM_OK, когда сообщение успешно получено и помещено в буфер, в противном случае другой код ошибки AM_RESULT. Использовани 1 - Ожидается, что сеансовый уровень предоставит процедуру «sm_receive_ind» типа TM_RECEIVE_IND в процедуре «tm_define_user». е 2 - Ожидается, что «sm_receive_ind» вернет сеансовому уровню буферы, которые сеансовый уровень предоставил в своей процедуре «sm_connect_ind». Процедура «tm_cancel_req» 6.3.6.7.9 Определение Отменяет соединение при вызове либо поставщиком, либо потребителем. Синтаксис AM_RESULT tm_cancel_req ( cancel_ref ); TM_MSG_DESCR * Параметр ввода Возврат cancel_ref дескриптор заблокированных структур данных транспортного уровня. AM_OK, если текущее сообщение отменяется, в противном случае — AM_FAILURE. Использование 1 - Если результатом будет AM_OK, транспортный уровень отправит пакет с запросом на отключение и процедура sm_send_cnf или sm_receive_ind не будет вызвана. 2 - Если сообщение уже полностью отправлено и подтверждено, эта процедура не действует. 3 - «cancel_ref» позволяет освободить заблокированные структуры данных, и после успешной операции отмены больше не определяется. Протокол многоадресной передачи (дополнительно) 6.3.7 6.3.7.1 Обмен пакетами многоадресной передачи Многоадресная передача должна быть разделена на три этапа: a) установление соединения; b) подтвержденная передача данных; c) отсоединение. Простой обмен пакетами без потери пакетов показан на Рисунке 133. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 243 – mc_send_msg_requ BC1 mc_invoke_msg_ind CONN_TMO accept = TRUE BC2 CONN_TMO QUIET_TMO[2 ] SEND_TMO BC3 SEND_TMO BD SEND_TMO BD BD LISTEN_TMO X QUIET_TMO[0 X] QUIET_TMO[0 X ] mc_rcv_msg_ind mc_send_msg_conf Рисунок 133 - Многоадресное сообщение без повторной передачи 6.3.7.1.1 Установление соединения Первый пакет сообщения представляет собой пакет широковещательного соединения (Broadcast_Connect) (BC), который указывает общий размер сообщения и содержит первый сегмент данных. Когда поступает пакет широковещательного соединения (BC), потребитель проверяет наличие приложения, готового принять сообщение. Если оно отсутствует, пакет отбрасывается. В противном случае соединение размыкается, и первый сегмент данных копируется в буфер сообщений приложения. Поставщик всегда трижды повторяет пакет BC с большой задержкой (CONN_TMO) между повторными передачами. Потребителям достаточно получить одну из этих трех копий. Пакет BC также содержит результат обратного отсчета повторной передачи, который позволяет потребителям регулировать тайм-аут. Потребители не могут запрашивать повторение пакета BC. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 244 – Если сообщение достаточно короткое, чтобы уместиться в пакете BC, возникает ситуация, показанная на Рисунке 134: мессенджер поставщика подтверждает завершение передачи сразу после отправки последнего пакета BC; Мессенджер потребителя уведомляет приложение и запускает тайм-аут (ALIVE_TMO []), чтобы запретить дублирование сообщений вследствие повторяющихся пакетов BC. Этот тайм-аут зависит от количества повторений пакетов BC. Прием последнего пакета BC останавливает тайм-аут и закрывает соединение. mc_send_msg_requ BC1 mc_invoke_msg_ind CONN_TMO mc_rcv_msg_ind BC2 CONN_TMO ALIVE_TMO[2 ] mc_send_msg_conf BC3 X {сброс соединения} Рисунок 134 - Короткое многоадресное сообщение без пакетов BD и без потерь 6.3.7.1.2 Передача данных Если сообщение еще не завершено пакетом BC, поставщик начинает передачу пакетов с широковещательными данными (Broadcast_Data) (BD) с интервалом SEND_TMO, который короче, чем CONN_TMO. Пакеты BD содержат 16-битный сдвиг, который указывает положение сегмента данных во всем сообщении. Потребитель, ожидающий данных, запускает тайм-аут QUIET_TMO для контроля активности. Если этот тайм-аут истекает или если потребитель обнаруживает пакет с большим сдвигом, чем ожидалось, потребитель предполагает, что некоторые пакеты BD потеряны, и поэтому выдает пакет повтора широковещательной передачи (Broadcast_Repeat) (BR) для запроса повторной передачи. Пакеты BR содержат 16-битный сдвиг, при котором запрашивается повторная передача. При отправке пакетов BD поставщик фильтрует входящие пакеты BR и запускает повторную передачу после добавления паузы передачи (PAUSE_TMO в дополнение к обычному тайм-ауту SEND_TMO). При отправке пакета BR потребитель запускает тайм-аут REPEAT_TMO для контроля действия пакета BR. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 245 – Потребитель может отправить пакет BR только в том случае, если тайм-аут REPEAT_TMO в этот момент еще не запущен, иначе тайм-аут REPEAT_TMO может истечь и вызвать повторную передачу пакета BR, а при втором тайм-ауте сообщение будет отброшено и соединение будет закрыто (в этом случае будет утеряно три пакета). При получении ожидаемого или более старого пакета BD перезапускается тайм-аут QUIET_TMO [0]. ПРИМЕР Ситуация, когда пакеты теряются, показана на Рисунке 135. BD[1] BD[2] BD[3] SEND_TMO « " " BD[4] X BD[2] QUIET_TMO[0 ] QUIET_TMO[0 X] X BD[5] " PAUSE_TM O SEND_TMO REPEAT_TM O BD[2] BD[3] " BD[4] " " BD[5] BD[6] (посл едни й) LISTEN_TMO X X QUIET_TMO[0 X ] X QUIET_TMO[0 QUIET_TMO[0 X ]] QUIET_TMO[0] BD[6] X PAUSE_TMO LISTEN_TMO BD[6] (посл едни й) REPEAT_TM O X mc_rcv_msg_ind mc_send_msg_conf Рисунок 135 - Обмен с потерянными пакетами 6.3.7.1.3 Отсоединение После передачи последнего пакета BD сообщение передается в приложение потребителя, и соединение закрывается. После передачи последнего пакета BD поставщик ожидает передачи пакетов повтора широковещательной передачи (Broadcast_Repeat) (BR) во время тайм-аута LISTEN_TMO, прежде чем закрыть и подтвердить завершение передачи. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 246 – 6.3.7.1.4 61375-2-1 IEC:2012 Отмена передачи Если потребитель отменяет запрос, входящее сообщение просто отбрасывается, и на шине ничего не отображается. Но если поставщик отменяет многоадресную передачу сообщения, то стоит передать специальный пакет прекращения широковещательной передачи (Broadcast_Stop, BS), чтобы запретить тайм-ауты всем потребителям и сгенерировать большое количество даже повторяющихся пакетов BR. 6.3.7.1.5 Алгоритм повторной передачи Один и тот же пакет BR может быть выпущен более чем одним потребителем, но эти пакеты будут поступать к поставщику с разной задержкой. Также возможно, что поступающие пакеты BR не указывают на возрастающий сдвиг отсутствия (как в случае двухточечной передачи). Проблему нельзя решить, добавив длительную задержку перед началом повторной передачи, поскольку тайм-ауты на обеих сторонах зависят друг от друга. Поэтому для поставщика необходимо предусмотреть определенный механизм фильтрации BR. Используемый фильтр можно описать следующим образом: после принятия пакета BR другой входящий пакет BR с тем же сдвигом повторной передачи отбрасывается в течение тайм-аута SKIP_TMO; только ограниченное число REP_LIMIT пакетов BR с разными сдвигами повторной передачи гарантированно будет принято в пределах скользящего окна сдвига фиксированного размера REP_RANGE; дополнительные пакеты BR, которые превышают этот предел для любого окна, могут быть отброшены или не отброшены. Входящие пакеты BR обрабатываются в соответствии со следующим алгоритмом: поставщик ведет таблицу регистрации запрошенных повторных передач для каждого сообщения. Таблица регистрации состоит из записей REP_LIMIT, которые при запуске передачи являются пустыми. Занятая запись содержит сдвиг повторной передачи (в качестве ключа) и собственный таймер, который загружается с помощью SKIP_TMO в случае приема соответствующего пакета BR. При входящем пакете BR таблица регистрации проверяется с тем, чтобы выяснить, зарегистрирован ли уже запрошенный сдвиг для повторной передачи. Если такая запись с таким же сдвигом существует, то пакет BR отбрасывается всякий раз, если работает таймер этой записи в противном случае он принимается. Если запрошенный сдвиг еще не зарегистрирован, то пакет BR принимается, и новая запись вставляется до тех пор, пока таблица не заполнится. Когда таблица заполнена, принятие пакета BR зависит от наличия записи, которую можно очистить для повторного использования. Запись с наименьшим сдвигом перезаписывается, если сдвиг нового пакета BR или сдвиг одной из других записей выходит за пределы окна, нижний край которого находится на наименьшем зарегистрированном сдвиге. В противном случае пакет BR отбрасывается, поскольку запросы REP_LIMIT BR в пределах того же окна уже приняты. Если таблица регистрации заполнена, она остается заполненной навсегда (пока соединение не будет закрыто). При таком алгоритме и только с одним потребителем сообщения все пакеты BR, которые превышают лимит REP_LIMIT для любого окна, отбрасываются (если потребителей больше одного, то прием такого пакета BR все еще возможен). 6.3.7.1.6 Согласованность сообщений в рамках открытия эксплуатации Потребитель согласованного сообщения сохраняет конечный узел, который находится в сетевом заголовке входящего пакета BC. После открытия соединения приема последующие пакеты принимаются только в том случае, если они адресованы одному и тому же конечному узлу, иначе соединение закрывается с ошибкой. Узел маршрутизации гарантирует, что поле Final_Node (конечный узел) в пакетах, пересылаемых по шине поезда, изменяется при каждом открытии эксплуатации (поле Final_Node содержит счетчик открытия эксплуатации). Это предотвращает объединение пакетов, исходящих от разных узлов, в недопустимое смешанное сообщение (адрес одного узла может быть назначен другому узлу при открытии эксплуатации, и оба узла могут случайно использовать одну и ту же ссылку на соединение). Если поставщик согласованного сообщения находится на конечном устройстве шины поезда, он не знает о промежуточном открытии эксплуатации и продолжает отправлять пакеты BD до тех пор, пока не будет передано полное сообщение. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 6.3.7.2 – 247 – Идентификация соединения Для каждого входящего пакета извлекается соединение, которому принадлежит пакет. На принимающей стороне соединение идентифицируется 32-битной структурой, состоящей из собственной конечной функции, начальной функции, начального узла и начальной станции. На передающей стороне соединение идентифицируется только двумя участвующими функциями, поскольку входящие пакеты BR могут содержать любой начальный узел (есть несколько потребителей). Сообщения с одинаковым идентификатором соединения передаются последовательно. 6.3.7.3 Ссылка на соединение Каждый пакет содержит 16-битовую ссылку на соединение в качестве идентификатора сообщения, которая присваивается поставщиком последовательно каждому исходящему сообщению и инициализируется случайным образом. 6.3.7.4 Кодирование контроля передачи многоадресных сообщений Протокол многоадресной рассылки использует тот же сетевой уровень, что и протокол передачи сообщений, поэтому пакеты имеют одинаковый заголовок канала и сетевой заголовок. Два протокола различаются контролем передачи сообщений, информация о котором указана в 6.3.6.5.2, «Кодирование контроля передачи сообщений» 6.3.7.5 Кодирование пакетов многоадресной передачи Протокол многоадресной передачи различает следующие пакеты, как показано на Рисунке 136. bc_rep_cnt сетевой заголовок BC 6 сетевой заголовок Сетевой заголовок Сетевой заголовок BD 2 bc_run_nr bc_msg_size 16 бит 16 бит до 144 бит bd_offset bd_data до 144 бит bd_run_nr 8 бит 16 бит 16 бит BR br_run_nr br_offset 16 бит 16 бит 8 бит BS 8 бит bc_data bs_run_nr 16 бит Рисунок 136 - Форматы пакетов Пакеты многоадресной передачи должны быть закодированы в 6.3.6.5.4. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 248 – 6.3.7.6 Определение протокола многоадресной передачи Этот протокол многоадресной передачи работает в ненадежной сети без установления соединения, которая поддерживает последовательность пакетов и ограничивает время существования пакетов значением PACK_LIFE_TIME. Соединение устанавливается для каждой передачи сообщения. Поставщик сообщения называется поставщиком, а принимающий партнер называется потребителем. Один таймер необходим для каждого соединения потребителя, в то время как поставщику нужен дополнительный таймер для каждой записи в таблице регистрации для реализации SKIP_TMO. 6.3.7.6.1 Состояния и диаграмма перехода состояния Автомат протокола многоадресной передачи, как показано на Рисунке 137, должна находиться в состояниях, перечисленных в Таблице 48. Таблица 48 - Состояния автомата протокола многоадресной передачи Имя состояния Место возникновения Краткое описание состояния отключено IDLE Поставщик, Потребитель SETUP SEND Поставщик LISTEN Поставщик периодическая отправка пакетов BC INSERT_PAUSE PAUSE Поставщик полное сообщение отправлено, ожидание пакетов BR RECEIVE FROZEN Поставщик запрошена дополнительная задержка перед отправкой Поставщик следующего пакета BD используется дополнительная задержка отправка пакетов BC Потребитель Получен пакет BC и ожидается пакет BD Потребитель некоторые, но не последние пакеты BC получены, и пакеты BD не ожидаются FROZEN RECEIVE IDLE SETUP INSERT_ PAUSE SEND PAUSE LISTEN {только с отменой} Рисунок 137 - Состояния автомата протокола Переходы между этими состояниями зависят от входящих событий, определенных в Таблице 49, и вызывают исходящие события, определенные в Таблице 50. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 249 – Таблица 49 - Входящие события Имя события mc_send_msg_requ Место возникновения Поставщик Интерфейс Краткое описание события от пользователя запрос на отправку сообщения, пользователь отправляет мессенджеру буфер сообщений mc_cancel_msg Поставщик, Потребитель от пользователя отменяет передачу входящего или исходящего сообщения, rcv_BC Потребитель от сети мессенджер возвращает буфер сообщений пользователю, если операция отмены прошла успешно rcv_BD Потребитель от сети получен пакет BC rcv_BS Потребитель от сети получен пакет BC rcv_BR Поставщик от сети получен пакет BC skipped (reg_entry) Поставщик внутренний получен пакет BC TMO Поставщик, Потребитель внутренний Истек тайм-аут SKIP_TMO для записи в таблице регистрации 'reg_entry' истек любой другой тайм-аут Таблица 50 - Исходящие события Имя события mc_invoke_msg_ind mc_rcv_msg_ind Место возникновения Потребитель Потребитель Интерфейс для пользователя для пользователя Краткое описание события входящий запрос на соединение должен быть принят или отклонен пользователем, пользователь передает буфер сообщения в мессенджер, если пользователь принимает сообщение получено полное сообщение или ошибка получения, mc_send_msg_conf Поставщик для пользователя мессенджер возвращает буфер сообщений пользователю полное сообщение отправлено или send_BC Поставщик для сети ошибка отправки, мессенджер send_BD Поставщик для сети возвращает буфер сообщения send_BS Поставщик для сети пользователю send_BR Потребитель для сети передача пакета BC передача пакета BD передача пакета BS передача пакета BR Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 250 – 6.3.7.6.2 Поля управления в пакете данных Обмениваемые пакеты должны содержать поля управления, перечисленные в Таблице 51. Таблица 51 - Поля управления в пакетах Имя события xxx_BC ( xxx_BD ( Имена полей BC_run_nr, Ссылка на соединение BC_rep_cnt, количество ожидающих повторных передач BC BC_msg_size общий размер сообщения ) BD_run_nr, Ссылка на соединение сдвиг сегмента данных в сообщении BD_offset) xxx_BS ( xxx_BR ( Краткое описание поля BS_run_nr) BR_run_nr, BR_offset) Ссылка на соединение Ссылка на соединение сдвиг отсутствия ПРИМЕЧАНИЕ Аббревиатура xxx устанавливается для «send» или «rcv». Для событий xxx = send фактические параметры указываются для управляющих полей, тогда как для событий xxx = rcv в действиях указываются формальные имена полей. 6.3.7.6.3 Вспомогательные переменные Диаграмма перехода состояний опирается на вспомогательные переменные для уменьшения количества состояний. Некоторые переменные существуют только у поставщика или потребителя и относятся к соединению, в то время как другие переменные являются глобальными, это означает, что они используются для всех соединений станции в целом. Должны быть реализованы вспомогательные переменные, перечисленные в Таблице 52. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 251 – Таблица 52 - Вспомогательные переменные Имя переменной Контекст Краткое описание переменной run_nr глобальная следующая свободная ссылка на соединение отменено Поставщик, это сообщение было отменено Потребитель таймер Поставщик, пользовательским таймером для всех тайм- Потребитель Поставщик, msg_size аутов, кроме SKIP_TMO Потребитель сдвиг Поставщик, общий размер сообщения Потребитель Поставщик, conn_run_nr сдвиг следующего сегмента данных Потребитель Поставщик rep_cnt Ссылка на соединение для данного Потребитель my_node Потребитель reg_table[REP_LIMIT]. Поставщик offset reg_table[REP_LIMIT]. Поставщик соединения число повторений (BR или BC) Конечный узел данного соединения таблица регистрации, сдвиг повторной передачи таблица регистрации, тайм-ауты SKIP_TMO reg_table[REP_LIMIT]. timer_running Поставщик таблица регистрации, булева переменная: «skip_timer» работает. table_is_full Поставщик булева переменная: таблица регистрации полная. window_is_full Поставщик next_entry Поставщик skip_timer булева переменная: все зарегистрированные сдвиги находятся в одном окне размером REP_RANGE. следующая свободная запись (индекс) в таблице регистрации или запись с наименьшим сдвигом, если «table_is_full» (таблица полная) ПРИМЕЧАНИЕ Таймер можно только запустить или остановить (не переназначить), и он генерирует событие по истечении тайм-аута. 6.3.7.6.4 Постоянные В Таблице 53 перечислены постоянные, используемые в автомате протокола многоадресной передачи. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 252 – Таблица 53 - Постоянные протокола многоадресной передачи Имя постоянной Значение постоянной Краткое описание постоянной REP_LIMIT 6 размер таблицы регистрации (количество записей) MAX_TRIALS 3 количество попыток (переданных пакетов BC), допускается потеря одного пакета BD_DATA_SIZE 18 (для кадра MVB) количество октетов данных в пакете BD PROC_DELAY 1 64 [мс] время обработки событий (период опроса) NET_DELAY 8 64 [мс] ожидаемая задержка передачи (сквозной) REP_RANGE LISTEN_TMO / SEND_TMO BD_DATA_SIZE ПРИМЕЧАНИЕ Диапазон сдвига, в пределах которого возможна повторная передача, определяет размер окна REP_RANGE. Тайм-ауты должны соответствовать указанному в Таблице 54. Таблица 54 - Тайм-ауты протокола многоадресной передачи Имя тайм-аута Значение тайм-аута Сторона поставщика CONN_TMO 4 64 [мс] SEND_TMO 1 64 [мс] PAUSE_TMO 1 64 [мс] SEND_MAX_TMO SEND_TMO + PROC_DELAY + PAUSE_TMO SKIP_TMO REPEAT_TMO – NET_DELAY – PROC_DELAY LISTEN_TMO (QUIET_TMO[0] + PROC_DELAY) + (MAX_TRIALS -2) (REPEAT_TMO + PROC_DELAY) + 2 NET_DELAY + PROC_DELAY – SEND_TMO Сторона потребителя QUIET_TMO [MAX_TRIALS] SEND_MAX_TMO + PROC_DELAY + NET_DELAY + ix (CONN_TMO + PROC_DELAY) ALIVE_TMO [MAX_TRIALS] NET_DELAY + PACK_LIFE_TIME + ix (CONN_TMO + PROC_DELAY) REPEAT_TMO SEND_MAX_TMO + 2 NET_DELAY + PROC_DELAY ПРИМЕЧАНИЕ 1 Все тайм-ауты и другие индикаторы времени указываются в миллисекундах. Для тех тайм-аутов, которые могут быть выбраны свободно, указывается выбранное число, а для зависимых тайм-аутов дается формула для минимального значения. ПРИМЕЧАНИЕ 2 Нотация «ix» означает «индекс массива 0 .. MAX_TRIALS – 1)’. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.7.6.5 – 253 – Комплексные действия Комплексные действия, перечисленные в Таблице 55, используются в автомате протокола многоадресной передачи несколько раз. Каждое соединение имеет собственный таймер для контроля тайм-аута. Таймер управляется действиями «restart_tmo» и «reset_tmo» и генерирует внутреннее событие «TMO» по истечении срока действия. На стороне поставщика для каждого SKIP_TMO используется дополнительный таймер, управление которым осуществляется с помощью «restart_skip» или «reset_skip», и который генерирует внутреннее событие «skiped (reg_entry)» по истечении срока действия. Все таймеры, относящиеся к соединению, сбрасываются при отключении. Таблица 55 - Комплексные действия протокола многоадресной передачи Имя действия restart_tmo (xxx_TMO) reset_tmo restart_skip (reg_entry) reset_skip (reg_entry) close_send close_rcv (error) accept_BC Краткое описание действия Следующее состояние останавливает «timer» («таймер») и запускает его с тайм-аутом xxx_TMO; останавливает «timer» («таймер»); Запускает «skip_timer» с SKIP_TMO и устанавливает «timer_running» = TRUE (ИСТИНА) для «reg_table[reg_entry]»; останавливает 'skip_timer» и устанавливает «timer_running» = FALSE (ЛОЖНО) для «reg_table[reg_entry]»; IF (NOT cancelled) THEN mc_send_msg_conf; END; reset_tmo; FOR ix:= 0 TO (REP_LIMIT – 1) DO reset_skip (ix); END; IF (NOT cancelled) THEN mc_rcv_msg_ind (error); END; reset_tmo; cancelled:= FALSE; my_node:= final_node; offset:= 0; mc_invoke_msg_ind (VAR err); IF (err = AM_OK) THEN conn_run_nr:= BC_run_nr; msg_size:= BC_msg_size; update (offset); IF (offset = msg_size) THEN IF (NOT cancelled) THEN mc_rcv_msg_ind (AM_OK); END; IF (BC_rep_cnt = 0) THEN ELSE restart_tmo (ALIVE_TMO [BC_rep_cnt]); END; ELSE rep_cnt:= 0; restart_tmo (QUIET_TMO [BC_rep_cnt]); END; END; IDLE IDLE IDLE FROZEN RECEIVE Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 254 – 61375-2-1 IEC:2012 Фильтрация пакетов BR выполняется функцией check_BR, которая возвращает булеву переменную, указывающую, принят ли BR или нет. Все вспомогательные переменные, которые появляются только в поставщике, доступны только для функции check_BR, за исключением инициализации, которая выполняется init_BR_filter. Фильтрация представлена в Таблице 56. Таблица 56 - Фильтрация пакетов BR Имя действия Спецификация действия init_BR_filter table_is_full:= FALSE; cancelled:= FALSE; new_cnt:= 0; FOR ix:= 0 TO (REP_LIMIT – 1) DO reg_table [ix].timer_running:= FALSE; END; check_BR (VAR accept) временные переменные: ix, max_offset; accept:= FALSE; IF ((BR_run_nr > conn_run_nr) OR (BR_offset >= offset)) THEN RETURN; END; IF ( any entry ix registered with reg_table[ix].offset = BR_offset) THEN IF (NOT (reg_table[ix].timer_running)) THEN accept:= TRUE; END; ELSIF (NOT (table_is_full)) THEN ix:= next_entry; INC (next_entry); IF (next_entry = REP_LIMIT) THEN table_is_full:= TRUE; END; accept = TRUE; ELSIF ( (BR_offset – reg_table[next_entry].offset >= REP_RANGE) OR (NOT (window_is_full))) THEN ix:= next_entry; accept:= TRUE; END; IIF (accept) THEN offset:= BR_offset; restart_skip (ix); IF (table_is_full) THEN (* update next_entry as entry with lowest registered offset; *) (* update window_is_full; *) next_entry:= 0; max_offset:= reg_table[0].offset; FOR ix:= 1 TO (REP_LIMIT-1) DO IF (reg_table[ix].offset reg_table[next_entry].offset) THEN next_entry:= ix; ELSIF (reg_table[ix].offset > max_offset) THEN max_offset:= reg_table[ix].offset; END; END; window_is_full:= (max_offset – reg_table[next_entry].offset) REP_RANGE; END; END; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.7.6.6 – 255 – Таблица состояний и событий поставщика В Таблице 57 показано поведение поставщика. Таблица 57 - Таблица состояний и событий поставщика протокола многоадресной передачи Текущее состояние (любое) IDLE Событие Действие(я) mc_cancel_msg cancelled:= TRUE; skipped (reg_entry) reg_table[reg_entry].timer_running:= FALSE; mc_send_msg_requ conn_run_nr:= run_nr; Следующее состояние SETUP INC (run_nr); cancelled:= FALSE; offset:= 0; msg_size:= requ_msg_size; rep_cnt:= MAX_TRIALS – 1; init_BR_filter; send_BC (conn_run_nr, rep_cnt, msg_size); update (offset); restart_tmo (CONN_TMO); SETUP TMO IF (cancelled) THEN send_BS (conn_run_nr); close_send; IDLE ELSE DEC (rep_cnt); send_BC (conn_run_nr, rep_cnt, msg_size); IF (rep_cnt > 0) THEN restart_tmo (CONN_TMO); ELSIF (offset = msg_size) THEN close_send; ELSE IDLE restart_tmo (ACK_TMO); END; END; SEND rcv_BR SEND check_BR (VAR accept); IF (accept) THEN TMO AND cancelled END; INSERT_ PAUSE restart_tmo (PAUSE_TMO); PAUSE Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 256 – Таблица 57 (продолжение) Текущее состояние SEND ИЛИ Событие TMO AND NOT cancelled PAUSE Действие(я) Следующее состояние send_BD (conn_run_nr, offset); update (offset); IF (offset = msg_size) THEN estart_tmo (LISTEN_TMO); LISTEN ELSE restart_tmo (SEND_TMO); SEND END; PAUSE TMO AND cancelled send_BS (conn_run_nr); close_send; PAUSE ИЛИ IDLE rcv_BR check_BR (VAR accept) TMO restart_tmo (PAUSE_TMO); PAUSE TMO close_send; IDLE rcv_BR check_BR (VAR accept) INSERT_ PAUSE INSERT_ PAUSE LISTEN IIF (accept) THEN restart_tmo (PAUSE_TMO); PAUSE END; 6.3.7.6.7 Таблица состояний и событий потребителя Потребитель в текущем состоянии при возникновении события должен перейти в следующее состояние и выполнить действие, указанное в Таблице 58. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 257 – Таблица 58 - Таблица состояний и событий потребителя протокола многоадресной передачи Текущее состояние Событие Действие(я) (любое) mc_cancel_msg cancelled:= TRUE; IDLE rcv_BC accept_BC; Следующее состояние IDLE ИЛИ FROZEN ИЛИ RECEIVE RECEIVE rcv_BD AND (BD_run_nr = conn_run_nr) AND (my_node = final_node) IF (cancelled) THEN reset_tmo; IDLE ELSIF (BD_offset = offset) THEN update (offset); IF (offset = msg_size) THEN close_rcv (AM_OK); IDLE ELSE rep_cnt:= 0; restart_tmo (QUIET_TMO[0]); END; ELSIF (BD_offset > offset) THEN IF (rep_cnt = 0) THEN send_BR (conn_run_nr, offset); INC (rep_cnt); restart_tmo (REPEAT_TMO); END; ELSE rep_cnt:= 0; restart_tmo (QUIET_TMO[0]); END; TMO AND (rep_cnt (MAX_TRIALS – 1)) IF (cancelled) THEN reset_tmo; IDLE ELSE send_BR (conn_run_nr, offset); INC (rep_cnt); restart_tmo (REPEAT_TMO); END; TMO AND (rep_cnt = (MAX_TRIALS – 1)) close_rcv (AM_REPEAT_TMO_ERR); rcv_BC AND (BC_run_nr = conn_run_nr) AND (my_node = final_node) (* no action *) IDLE Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 258 – Таблица 58 (продолжение) Текущее состояние Событие RECEIVE (rcv_BS OR rcv_BD) AND Действие(я) Следующее состояние close_rcv (AM_FAILURE); IDLE rcv_BC AND close_rcv (AM_FAILURE); IDLE ((BC_run_nr > conn_run_nr) accept_BC; IDLE ИЛИ (продолжени ((BD_run_nr > е) conn_run_nr) OR (my_node > final_node)) FROZEN ИЛИ OR (my_node > final_node)) rcv_BS AND RECEIVE close_rcv (AM_REM_CANC_ERR); IDLE reset_tmo; IDLE (BC_run_nr = conn_run_nr) AND (my_node = final_node) FROZEN TMO OR rcv_BS rcv_BC AND (BC_run_nr = conn_run_nr) AND IF (BC_rep_cnt = 0) THEN reset_tmo; IDLE END; (my_node = final_node) rcv_BC AND reset_tmo; IDLE ((BC_run_nr > conn_run_nr) accept_BC; IDLE ИЛИ OR (my_node > final_node)) 6.3.8 6.3.8.1 FROZEN ИЛИ RECEIVE Сеансовый уровень сообщений Цель Сеансовый уровень объединяет два сообщения: Call_Message (сообщение вызова) и Reply_Message (ответное сообщение). Сообщение вызова отправляется вызывающим абонентом ответчику, ответное сообщение отправляется ответчиком вызывающему абоненту. Эта пара сообщений позволяет реализовать удаленный вызов процедуры, как показано на Рисунке 138. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 Вызывающий абонент – 259 – Сеанс Транспорт Сеанс Ответчик am_call_request сообщение вызова receive_confirm тайм-аут ответчика am_reply_request ответное сообщение call_confirm время Рисунок 138 - Передача на сеансовом уровне Сеансовый уровень использует услуги транспортного уровня для каждой передачи сообщения. 6.3.8.2 Идентификатор сеанса связи Сеансовый уровень должен однозначно идентифицировать партнеров по связи через идентификатор сеанса связи (Conversation_Id), который включает конкатенацию Сетевого адреса удаленного приложения; идентификатора функции местного приложения. Сеансовый уровень должен отклонять запрос на связь с использованием данного идентификатор сеанса связи до тех пор, пока выполняется другой сеанс с тем же самым идентификатор сеанса связи. Сеансовый уровень должен хранить полный адрес вызывающего абонента для пересылки соответствующего ответного сообщения. ПРИМЕЧАНИЕ Идентификатор сеанса связи содержит всю информацию, необходимую для пересылки пакета на сетевой уровень и для идентификации пакетов, когда они поступают с сетевого уровня. 6.3.8.3 Быстрый вызов Сеансовый уровень должен обеспечить быстрый вызов по сети, когда партнер находится на той же станции, т.е. пересылать сообщение напрямую, без участия транспортного уровня. 6.3.8.4 Проверка топографического счетчика Сеансовый уровень должен проверять согласованность между my_topo (предоставляется приложением) и this_topo (значение топографического счетчика, сохраняемое сетевым уровнем) в соответствии со следующим алгоритмом: IF (my_topo = AM_ANY_TOPO) THEN my_topo = this_topo ELSE IF (this_topo = AM_ANY_TOPO) THEN this_topo = my_topo ELSE IF (my_topo > this_topo) THEN reject the call. Сеансовый уровень должен использовать значение топографического счетчика на время этого сеанса связи. ПРИМЕЧАНИЕ Сеанс связи будет гарантированного отменен, если между сообщением вызова и ответным сообщение происходит открытие эксплуатации. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 260 – 6.3.8.5 Кодирование заголовка сеанса В запросе на соединение сообщения вызова заголовок сеанса состоит из одного октета, заполненного «0». Все остальные комбинации зарезервированы, как показано на Рисунке 139. В запросе на соединение ответного сообщения заголовок сеанса состоит из одного октета, содержащего статус ответа, предоставленный приложением ответчика. 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 Рисунок 139 - Заголовок сессии в сообщении вызова (тип Am_Result) 6.3.8.6 Управление буфером Сеансовый уровень должен обеспечивать управление двумя типами буферов: a) статические буферы, которые выделяются и освобождаются приложением, и b) динамические буферы, которые выделяются и освобождаются сессией. 6.3.8.7 Интерфейс сеансового уровня Интерфейс сеансового уровня идентичен интерфейсу прикладного уровня, поскольку уровень представления не имеет протоколов. 6.3.9 Уровень представления для сообщений Уровень представления для сообщений не имеет протоколов. Сообщения должны передаваться как массивы 8-битных слов (ARRAY OF WORD8) по адресам памяти в порядке возрастания. Заголовки и параметры сообщения должны соответствовать тем же правилам представления данных, что и для переменных процесса (например, все данные передаются первым старшим октетом). Типы данных, которые должны использоваться в протоколах и которые рекомендуются для применения, перечислены в 6.4. 6.3.10 6.3.10.1 Прикладной уровень сообщений Цель Интерфейс прикладных сообщений (AMI) позволяет приложению отправлять и получать сообщения по сети. Интерфейс прикладных сообщений (AMI) предлагает услугу вызова/ответа, а также инициализацию и управление буфером, а также услугу многоадресной рассылки. Интерфейс прикладных сообщений (AMI) определяется как набор процедур, которые напрямую обращаются к сеансовому уровню (уровень представления и прикладной уровень не имеют протоколов). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 – 261 – Интерфейс прикладных сообщений 6.3.10.2 6.3.10.2.1 Примитивы AMI Интерфейс прикладного уровня должен реализовать примитивы, представленные на Рисунке 140, перечисленные в Таблице 59 и указанные в следующих подразделах. Сеанс Вызывающий абонент Транспорт Сеанс Ответчик am_bind_replier (replier_function) am_call_request (caller_instance replier, out_buffer, replier_timeout) am_receive_request (replier_instance, in_buffer) receive_confirm (replier_instance, caller, in_buffer, ) am_reply_request (replier_instance, out_buffer ) reply_confirm (replier_instance) call_confirm (caller_instance, replier, in_buffer, status) am_receive_request (replier_instance, in_buffer) время Рисунок 140 - Интерфейс прикладных сообщений ПРИЛОЖЕНИЕ 1 Объекты интерфейсы прикладных сообщений (AMI) имеют префикс am_ или AM_ (для сообщений приложения), объекты, принадлежащие экземпляру вызывающего абонента или ответчика, не имеют префикса. ПРИМЕЧАНИЕ 2 В этих имена используются следующие аббревиатуры: REM - удаленный, сбой, о котором сообщило устройство партнера; LOC - местный, сбой, о котором сообщило собственное устройство; OVF - переполнение; TMO - тайм-аут. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 262 – Таблица 59 - Примитивы AMI Имя Значение Постоянные и типы AM_RESULT результат процедуры, то же определение, что и Am_Result. AM_ADDRESS Сетевой адрес удаленного объекта Инициализация am_init инициализация мессенджер am_announce_device конфигурация устройства am_show_busses перечисляет идентификаторы шины подключенных канальных уровней am_set_current_tc сообщает мессенджеру текущий топографический счетчик Интерфейс каталога станции AM_STADI_ENTRY запись каталога станции am_stadi_write записывает каталог станций am_stadi_read считывает каталог станций Интерфейс каталога функций AM_DIR_ENTRY запись каталога функций am_clear_dir инициализация каталога функций am_insert_dir_entries записывает идентификатор станции из списка функций am_remove_dir_entries удаляет список функций am_get_dir_entry извлекает идентификатор станции данной функции Интерфейс каталога группы AM_GROUP определение группы am_clear_groups очищает каталог группы am_insert_member включает узел в каталог группы am_remove_member удаляет узел из каталога группы am_member членство в каталоге группы Интерфейс вызывающего абонента am_call_request Вызывающий абонент отправляет целое сообщение AM_CALL_CONFIRM тип процедуры, вызываемой при получении ответа am_call_cancel отменить сеанс связи и удалить ответное сообщение Интерфейс ответчика am_bind_replier оповещает экземпляр ответчика на сеансовом уровне am_unbind_replier отмена указанного выше оповещения am_receive_request экземпляр оповещения готов к следующему вызову AM_RECEIVE_CONFIRM тип процедуры, вызываемой после завершения вызова am_reply_request AM_REPLY_CONFIRM вызывается экземпляром ответчика для отправки обратно ответного сообщения тип процедуры, вызываемой при отправке ответа am_receive_cancel отменяет готовый или задействованный экземпляр ответчика Обработка буфера am_buffer_free сбрасывает динамический буфер сообщений ПРИМЕЧАНИЕ Процедуры интерфейса не блокируются, и планирование задач не ограничено. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.10.2.2 Определение Синтаксис – 263 – Определение AM_RESULT Процедура, которая возвращает значение типа LP_RESULT, должна кодировать его следующим образом: typedef enum { AM_OK AM_FAILURE =0, =1, =2, =3, /* /* /* /* успешное завершение неустановленный сбой AM_BUS_ERR передача по шине невозможна слишком много входящих AM_REM_CONN_OVF соединений AM_CONN_TMO_ERR =4, /* не получено ответа на запрос на установление соединения AM_SEND_TMO_ERR =5, /* тайм-аут отправки (соединение выполнено) AM_REPLY_TMO_ERR =6, /* ответ не получен AM_ALIVE_TMO_ERR =7, /* не получено полного сообщения AM_NO_LOC_MEM_ERR =8, /* недостаточно памяти или времени AM_NO_REM_MEM_ERR =9, /* недостаточно памяти или времени (партнера) AM_REM_CANC_ERR =10,/* отменено партнером AM_ALREADY_USED =11,/* некоторые операции уже выполнены AM_ADDR_FMT_ERR =12,/* ошибка формата адреса AM_NO_REPLY_EXP_ERR =13,/* такой ответ не ожидается AM_NR_OF_CALLS_OVF =14,/* запрошено слишком много вызовов AM_REPLY_LEN_OVF =15,/* слишком длинное ответное сообщение AM_DUPL_LINK_ERR =16,/* ошибка дублирования сеанса связи AM_MY_DEV_UNKNOWN_ERR =17, /* неизвестно собственное устройство или допустимое AM_NO_READY_INST_ERR =18,/* не готов экземпляр ответчика AM_NR_OF_INST_OVF =19, /* слишком много экземпляров ответчика AM_CALL_LEN_OVF =20,/* слишком длинное сообщение вызова AM_UNKNOWN_DEST_ERR =21,/* неизвестное устройство партнера AM_INAUG_ERR =22,/* произошло открытие эксплуатации поезда AM_TRY_LATER_ERR =23,/* (только внутреннее использование) AM_FIN_NOT_REG_ERR =24,/* конечный адрес не зарегистрирован AM_GW_FIN_NOT_REG_ERR =25, /* конечный адрес на маршрутизаторе AM_GW_ORI_REG_ERR =26, /* источник не зарегистрирован на маршрутизаторе AM_MAX_ERR =31 /* наивысший системный код. /* коды пользователя выше 31 } AM_RESULT; Если в результате процедура интерфейса прикладных сообщений (AMI) возвращает код пользователя, зависящий от приложения, он должен быть больше AM_MAX_ERR и меньше 256. ПРИЛОЖЕНИЕ AM_RESULT использует ту же кодировку, что и поле Am_Result, передаваемое в пакетах. 6.3.10.2.3 Постоянные адреса Постоянные, перечисленные в Таблице 60, являются зарезервированными идентификаторами. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 264 – Таблица 60 - Постоянные адреса Постоянная AM_SAME_STATION Код Значение 0 данная станция, не зависимо от идентификатора станции 255 неизвестный идентификатор станции AM_UNKNOWN AM_MAX_BUSSES 1..16 максимальное количество канальных уровней, поддерживаемых в ходе реализации. AM_ROUTER_FCT 251 Идентификатор функции маршрутизатора AM_AGENT_FCT 253 Агент функции маршрутизатора AM_MANAGER_FCT 254 Администратор функции маршрутизатора 0 связь в рамках того же узла, не переходя через шину поезда. AM_SAME_NODE AM_SYSTEM_ADDR 0 Неизвестный топографический счетчик. AM_ANY_TOPO 6.3.10.2.4 128 бит 0 адреса узла указывает адрес системы. Тип «AM_ADDRESS» Вызывающий абонент или ответчик должен идентифицировать другую сторону по адресу ее приложения, который имеет тип AM_ADDRESS. Определение Синтаксис Тип адреса приложения (вызвающий абонент или ответчик). typedef struct unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned Элементы snu gni node_or_group AM_ADDRESS - представление от { snu :1 /* бит gni:1 /* бит 1 node_or_group :6 func_or_stat 8 next_station 8 topo_rsv :1 /* бит topo_valid :1 /* бит topo_counter 6 } AM_ADDRESS; старшего к младшему 0 0 1 (системный, а не пользовательский) бит 0 = 0 указывает на адрес пользователя, бит 0 = 1 указывает на системный адрес. (групповой, а не отдельный) бит 1 = 0, указывает отдельный адрес (узла), бит 1 = 1, указывает адрес группы Gni = 0, бит 2..7 указывает адрес узла gni = 1, бит 2..7 указывает адрес группы func_or_stat бит 0 для snu = 0 определяет идентификатор функции, бит 0 для snu = 1 определяет идентификатор станции next_station Идентификатор следующей станции res резервный, всегда 0 tpv (topo valid) указывает, действителен ли следующий топографический счетчик Топографический счетчик или AM_ANY_TOPO. topo_counter ПРИМЕЧАНИЕ Значение полей отличается на стороне вызывающего абонента и стороне ответчика, как указано ниже. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 265 – Удобная кодировка адреса приложения показана на Рисунке 141. 7 6 snu gni 5 4 3 2 1 0 node_or_group func_or_stat next_station trv tpv topo_counter Рисунок 141 - Кодирование AM_ADDRESS ПРИМЕЧЕНИЕ AM_ADDRESS представляет собой формат интерфейса, Am_Address представляет собой формат передачи. 6.3.10.3 6.3.10.3.1 Сторона вызывающего абонента Собственная идентификация Вызывающий абонент должен идентифицировать себя по своему идентификатору функции (Function_Id). ПРИМЕЧАНИЕ Вызывающий абонент идентифицирует себя в процедуре «am_call_request». 6.3.10.3.2 Экземпляры взывающего абонента Поскольку вызывающий абонент может установить несколько вызовов, прежде чем получит ответ, переменная «caller_ref» должна связать процедуру «am_call_request» с соответствующим подтверждение вызова «call_confirm». 6.3.10.3.3 Система или пользователь (snu) Если какая-либо другая функция, кроме администратора, выполняет вызов с адреса системы, вызов не должен выполняться, и в подтверждении адреса «call_confirm» будет сообщено об ошибке адреса. ПРИМЕЧАНИЕ Любая функция может вызывать функцию агента или функцию администратора через свой адрес пользователя, указав следующую станцию (next_station), но только если связь не проходит через шину поезда (узел = AM_SAME_NODE). 6.3.10.3.4 Группа или отдельная переменная (gni) Если вызывающий абонент устанавливает для бита «gni» значение «0», должен использоваться одноадресный протокол, а следующие шесть битов должны интерпретироваться как адрес узла. Если вызывающий абонент устанавливает для бита «gni» значение «1», должен использоваться многоадресный протокол, а следующие шесть битов должны интерпретироваться как адрес группы. ПРИМЕЧАНИЕ Протокол многоадресной передачи использует тот же формат адреса. 6.3.10.3.5 Узел или группа (node_or_group) Если вызывающий абонент указывает (Node_Address > AM_SAME_NODE), вызов должен быть переадресован на узел шины поезда. ПРИМЕЧАНИЕ Даже если адрес узла ответчика идентичен адресу узла вызывающего абонента, сообщение будет переадресовано узлу, который проверяет топографический счетчик и отражает сообщение обратно по сети подвижного состава. 6.3.10.3.6 Станция или функция (func_or_stat) Идентификатор функции может использоваться вместе с адресом пользователя. Администратор может указать (Station_Id = AM_UNKNOWN) в адресе системы, однако вызов не должен быть выполнен, и об ошибке адреса должно быть сообщено в подтверждении вызова «call_confirm», если для следующей станции установлено значение «AM_UNKNOWN». Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 266 – ПРИМЕЧАНИЕ 1 инициализации. 61375-2-1 IEC:2012 Это позволяет администратору получить доступ к станции с неизвестным идентификатором станции в ходе ПРИМЕЧАНИЕ 2 Когда вызов отправляется по шине поезда, идентификатор станции Station_Id = 0 или 255 обращается к удаленному узлу, независимо от его идентификатора станции. Следующая станция (Next_Station) 6.3.10.3.7 Параметр Next_Station (следующая станция) указывает адрес канала, на который сообщение должно быть направлено следующим. Next_Station также может указывать конечную станцию или станциюмаршрутизатор. Если расчет выполняется следующим образом: > AM_UNKNOWN), адрес канала должен быть взят из каталога станции с использованием идентификатора следующей станции в качестве ввода; a) если указан Next_Station (Next_Station_Id b) если Next_Station не указан (Next_Station_Id > AM_UNKNOWN), адрес канала должен быть взят из каталога станции с использованием в качестве ввода следующего значения по умолчанию; если сообщение отправлено на шину поезда (Node_Address > AM_SAME_NODE) или (многоадресная передача), идентификатор следующей станции должен быть взят из каталога функций с использованием функции маршрутизатора (AM_ROUTER_FCT) в качестве ввода, если сообщение не отправляется по шине поезда (Node_Address = AM_SAME_NODE): – В случае адреса системы: Идентификатор следующей станции (Next_Station_Id) должен быть установлен равным идентификатору станции (Station_Id); – В случае адреса пользователя: Идентификатор следующей станции (Next_Station_Id) должен быть получен из каталога функций с использованием в качестве идентификатора функции в качестве ввода; c) если (Next_Station_Id = AM_SAME_STATION) или (Next_Station_Id = this_station), мессенджер должен перенаправить сообщение вызова местному ответчику, если такой существует. Ошибка адреса должна возникать, если в каталоге станций нет записи для адреса канала, соответствующего идентификатору следующей станции. ПРИМЕЧАНИЕ 6.3.10.3.8 Если вызывающий абонент находится на узле, следующая станция будет AM_SAME_STATION. Топографический счетчик (Topo_Counter) Бит 7 (старший) данного октета должен равняться 0. Бит 6 данного октета должен равняться 0. Биты с 0 по 5 должны содержать действительный топографический счетчик в диапазоне от 1 до 63. В противном случае все биты этого октета должны быть равны 0 (AM_ANY_TOPO). Ошибка адреса должна возникнуть, если приложение указывает значение AM_ANY_TOPO для любых вызовов, для которых (узел > AM_SAME_NODE). ПРИМЕЧАНИЕ Вызывающий абонент не может отправлять двухточечное сообщение по шине поезда, если он игнорирует топографию. Ожидается, что сначала будет получена топография от узла или из промежуточного приложения. В случае фиксированной конфигурации шины поезда допускается любое значение топографического счетчика. 6.3.10.3.9 Использование сетевого адреса вызывающего абонента Режимы System_Address (адрес системы) и User_Address (адрес пользователя) приведены в Таблице 61. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 267 – Таблица 61 - Адрес системы и адрес пользователя System_Address (адрес системы) Next_Station (следующая станция) = Station_Id (идентификатор станции) = AM_SAME_STATION тот же узел Link_Address (адрес канала) = другой узел Link_Address (адрес канала) = быстрый вызов собственной станции AM_SAME_STATION Node_Address > AM_SAME_STATION и ошибка (ошибка, если this_station не является узлом) > AM_UNKNOWN AM_UNKNOWN быстрый вызов собственной станции AM_SAME_STATION > stadi (next_station) (агент > AM_SAME_STATION и >AM_UNKNOWN AM_SAME_STATION и stadi (next_station) не является удаленной станцией) > AM_UNKNOWN AM_UNKNOWN AM_SAME_STATION AM_UNKNOWN быстрый вызов собственной станции stadi (fundi( AM_ROUTER_FCT)) (агент на удаленном узле) stadi(fundi( > AM_SAME_STATION и stadi (Station_Id) (агент на удаленной станции) > AM_UNKNOWN AM_UNKNOWN AM_ROUTER_FCT)) ошибка stadi(fundi( AM_ROUTER_FCT)) (агент на удаленном узле) User_Address (адрес пользователя) Next_Station (следующая станция) AM_SAME_STATION Function_Id (идентификатор функции) любой тот же узел Link_Address (адрес канала) = быстрый вызов собственной станции другой узел Link_Address (адрес канала) = шина поезда, Node_Address (ошибка, если станция не является узлом) любой > AM_SAME_STATION и stadi(fundi( stadi (next_station) AM_ROUTER_FCT)) > AM_UNKNOWN AM_UNKNOWN любой stadi (fundi(Function_Id )) stadi(fundi( (ошибка, если функция не зарегистрирована) (шина поезда, Node_Address) AM_ROUTER_FCT)) или Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 268 – 6.3.10.4 6.3.10.4.1 61375-2-1 IEC:2012 Сторона ответчика Экземпляры ответчика Процессы ответчика представляют собой процессы приложения. Несколько экземпляров ответчика могут обслуживать одну и ту же функцию параллельно. Вызывающий абонент может не указывать, какой экземпляр обслуживает вызов. Каждая функция ответчика должна быть привязана до того, как эта функция сможет вызвать процедуру «am_receive_request» для получения входящего вызова и процедуру «am_reply_request» для ответа на полученный вызов. Процессы ответчика не блокируются при ожидании сообщения вызова или во время передачи ответного сообщения, вместо этого они получают уведомление, когда сообщение вызова получено или, когда передача ответного сообщения завершена. Процедуры подтверждения, которые должны быть вызваны для уведомления, указываются в привязке и, таким образом, являются одинаковыми для всех экземпляров одной и той же функции ответчика. Экземпляр ответчика должен ответить или отменить каждый полученный вызов, прежде чем он сможет выдать следующий запрос «am_receive_request». Каждый запрос, который еще не подтвержден, также может быть отменен. Запрос, который был успешно отменен, не будет подтвержден. 6.3.10.4.2 Идентификация ответчика Поскольку в выполнении функции может участвовать экземпляров, переменная «replier_ref» должна связать «am_receive_request» с соответствующими параметрами «receive_confirm», «am_reply_request» и «reply_confirm». Идентификация экземпляра ответчика должна осуществляться посредством его идентификатора функции (Function_Id) и его внешней ссылки (External_Reference). ПРИМЕЧАНИЕ Сеансовый уровень сохраняет полный адрес ответчика, полученный в сообщении вызова для ответного сообщения. Сеансовый уровень сохраняет внешнюю ссылку как часть. идентификатора сеанса связи. 6.3.10.4.3 Система или пользователь (snu) Бит «snu» должен быть равен «1», если сообщение было получено с адреса системы, и в этом случае должна быть вызвана функция агента, при этом вызывающий абонент неявно является администратором. Бит «snu» должен равен «0», если сообщение было получено с адреса пользователя. ПРИМЕЧАНИЕ Через адрес пользователя агенту может быть направлена любая другая функция, но только со станций, подключенных к тому же узлу. 6.3.10.4.4 Группа или отдельная переменная (gni) Бит «gni» должен быть равен 1, чтобы указать, что сообщение было получено по адресу многоадресной передачи, и равен 0, если оно было получено по адресу для одноадресной передачи. ПРИМЕЧАНИЕ Это позволяет осуществлять нейтральный вызов ответчика по одноадресному или многоадресному протоколу. 6.3.10.4.5 Узел или группа Независимо от того, используется ли отдельный адрес или адрес группы, следующие шесть битов должны указывать адрес узла вызывающего абонента или AM_SAME_NODE, если вызывающим абонентом в адресе ответчика был указан AM_SAME_NODE. ПРИМЕЧАНИЕ Если вызывающий абонент указывает адрес узла, этот адрес доставляется ответчику, даже если сообщение не передается по шине поезда. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.10.4.6 – 269 – Следующая станция (Next_Station) Параметр Next_Station (следующая станция) должен представлять собой идентификатор станции, через которую был получен вызов, или, если конечной станцией является сам узел, Next_Station должен быть равен AM_SAME_STATION. 6.3.10.4.7 Топографический счетчик (Topo_Counter) Ответчик должен получить топографический счетчик узла, к которому он присоединен, если сообщение было перенаправлено через узел, в противном случае в этом поле установлено значение AM_ANY_TOPO. ПРИМЕЧАНИЕ Ответчик отвечает за проверку того, что значение топографического счетчика в сообщении вызова соответствует значению my_topo. 6.3.10.5 Инициализация Служба сообщений инициализируется на разных уровнях посредством следующих процедур. Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. 6.3.10.5.1 Процедура «am_init» Определение Инициализирует мессенджер и вызывает am_clear_dir для инициализации каталога. Синтаксис AM_RESULT Результат AM_RESULT am_init (void); AM_OK, AM_FAILURE Использование Эта процедура должна быть вызвана при инициализации системы перед вызовом любой другой процедуры am_xxx. 6.3.10.5.2 Процедура «am_announce_device» Определение Объявляет конфигурацию устройства. Синтаксис AM_RESULT am_announce_ device ( max_call_number, max_inst_number, UNSIGNED16 UNSIGNED16 UNSIGNED16 default_reply_timeo my_credit ); количество одновременных вызовов на этом устройстве. ut, UNSIGNED8 Параметр ввода Возврат max_call_number max_inst_number количество одновременно существующих экземпляров любого ответчика на этом устройстве (по умолчанию три). default_reply_tmo тайм-аут ответа по умолчанию для запросов вызова. my_credit максимальный (принятый) кредит для всех подключений, заканчивающихся на этом устройстве, который сокращается до AM_MAX_CREDIT. Любое значение AM_RESULT Использование Эта процедура получает адрес узла непосредственно от канального уровня. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 270 – 6.3.10.5.3 61375-2-1 IEC:2012 Процедура «am_show_busses» Определен Получает количество канальных уровней (шин), подключенных к этой станции, и перечисляет их идентификаторы шин. ие Синтаксис AM_RESULT UNSIGNED8 * UNSIGNED8 Любое значение AM_RESULT Возврат Параметр вывода 6.3.10.5.4 am_show_busses ( nr_of_busses, link_id_list [AM_MAX_BUSSES] ); nr_of_busses количество подключенных канальных уровней (также количество элементов в списке link_id_list) link_id_list список канальных уровней, по крайней мере, с идентификатором шины для каждого. Процедура «am_set_current_tc» Определен Устанавливает текущее значение топографического счетчкиа «this_topo» для сетевого уровня. ие Синтаксис AM_RESULT am_set_current_tc ( UNSIGNED8 this_topo ); Параметр ввода Возврат this_topo Счетчик топографии или AM_ANY_TOPO, если счетчик топографии неизвестен. AM_OK, если (AM_ANY_TOPO this_topo 63), в противном случае AM_FAILURE. Использов 1 - Ожидается, что приложение (вызывающий абонент или ответчик) получит текущее значение ание топографического счетчика и скопирует его в свою переменную «my_topo». Это значение обычно отличается от приложения к приложению, даже в пределах одного и того же узла, поскольку открытие эксплуатации может произойти в любое время, и не ожидается, что приложения получат уведомления о каждом изменении. 2 - Способ, которым приложение получает значение топографического счетчика, не указывается: это может осуществляться через административные сообщения, посредством прямого доступа к канальному уровню на узле, через периодическую переменную и т.д. 3 - Если значение this_topo не равно AM_ANY_TOPO, мессенджер отклонит последующие вызовы, сделанные со значением топографического счетчика, не равным данному значению или не равным AM_ANY_TOPO, с результатом AM_INAUG_ERR в подтверждении вызова call_confirm. 4 - Значение this_topo изначально равно AM_ANY_TOPO. 6.3.10.6 Интерфейс каталога станции Каталог станции является необязательным. Простые системы могут выполнять преобразование определенным образом. Если используется каталог станций, доступ к нему можно получить с помощью следующих процедур. Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.10.6.1 – 271 – Тип «AM_STADI_ENTRY» Определение Тип записи каталога станций Синтаксис typedef struct UNSIGNED8 UNSIGNED8 ENUM8 UNSIGNED64 Элементы station next_station { station; next_station; bus_id; device_adr; } AM_STADI_ENTRY; Идентификатор станции (Station_Id) (ключ к для вызова next_station) Next_Station (следующая станция) Для станции с непосредственным доступом Next_Station равно идентификатору станции (Station_Id) 6.3.10.6.2 bus_id Bus_Id device_adr Адрес станции (независимо от шины) Процедура «am_stadi_write» Определение Вставляет ряд записей в каталог станции, каждая запись проверяется на достоверность и согласованность и может быть отклонена Синтаксис AM_RESULT am_stadi_write ( entries[], const AM_STADI_ENTRY nr_of_entri ); es UNSIGNED8 Параметр ввода entries список записей каталога новой станций nr_of_entries количество элементов в записи AM_OK: все записи успешно внесены в каталог станции. Возврат AM_FAILURE: ни одна запись в списке не прошла проверку. В этом случае отклоняются только эти записи. 6.3.10.6.3 Процедура «am_stadi_read» Определение Считывает ряд записей из каталога станций. Синтаксис AM_RESULT AM_STADI_ENTRY UNSIGNED8 Параметр ввода entries[].station записи для считывания. nr_of_entries количество записей. Возврат Параметр вывода am_stadi_read ( entries[], nr_of_entries ); AM_OK, AM_FAILURE entries[]. next_station поля entry[].next_station включают в себя выводимую информацию. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 272 – 6.3.10.7 61375-2-1 IEC:2012 Интерфейс каталога функций Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. 6.3.10.7.1 Тип «AM_DIR_ENTRY» Тип записи каталога функций. Определение Синтаксис typedef struct UNSIGNED8 UNSIGNED8 6.3.10.7.2 Процедура «am_clear_dir» Устанавливает для идентификатора станции для всех функций в каталоге значение AM_UNKNOWN. Определение Синтаксис AM_RESULT Параметр вывода 6.3.10.7.3 Процедура «am_insert_dir_entries» Вставляет идентификатор станции для каждого идентификатора функции, указанного в первых элементах «number_of_entries» списка функций function_list. Синтаксис AM_RESULT am_insert_dir_entries ( AM_DIR_ENTRY * function_list, unsigned number_of_entries ); Параметр ввода function_list number_of_entries Возврат список каталога функций число элементов в этом списке AM_OK, AM_FAILURE Процедура «am_remove_dir_entries» Определение Синтаксис Параметр ввода Возврат am_clear_dir (void); AM_OK, AM_FAILURE Определение 6.3.10.7.4 AM_DIR_ENTRY { function; station; } AM_DIR_ENTRY; Вставляет идентификатор станции для каждого идентификатора функции, указанного в первых элементах «number_of_entries» списка функций function_list. AM_RESULT am_remove_dir_entries ( AM_DIR_ENTRY * function_list, unsigned number_of_entrie s ); function_list список каталога функций number_of_entries число элементов в этом списке AM_OK, AM_FAILURE Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.10.7.5 – 273 – Процедура «am_get_dir_entry» Определен Считывает идентификатор станции для заданного идентификатора функции из каталога функций. ие Синтаксис AM_RESULT am_get_dir_entry ( UNSIGNED8 function, UNSIGNED8 * station ); Параметр ввода Параметр вывода function Идентификатор фукнции (ключ) station Идентификатор станции, на которой выполняется функция, или AM_UNKNOWN, если для функция не назначена станция. Возврат 6.3.10.8 AM_OK, AM_FAILURE Интерфейс каталога группы Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. 6.3.10.8.1 Тип AM_GROUP Определен Тип записи в каталоге группы ие Синтаксис typedef UNSIGNED8 AM_GROUP; Использова Группы идентифицируются 6-битным адресом, представленным одним октетом, причем два старших бита игнорируются. ние 6.3.10.8.2 Процедура «am_clear_groups» Определен Очищает все записи в каталоге группы. ие Синтаксис AM_RESULT am_clear_groups (void); Возврат 6.3.10.8.3 AM_OK, AM_FAILURE Процедура «am_insert_member» Определен Регистрирует данный идентификатор станции в качестве члена в каталоге группы. ие Синтаксис AM_RESULT am_insert_member ( AM_GROUP group ); Параметр ввода Возврат group Группа, к которой относится эта станция AM_OK, AM_FAILURE Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 274 – 6.3.10.8.4 61375-2-1 IEC:2012 Процедура «am_remove_member» Определен Удаляет данный идентификатор станции, как члена группы. ие Синтаксис AM_RESULT am_remove_member ( AM_GROUP group ); Группа, из которой данная станция должна быть удалена. Параметр ввода Возврат group 6.3.10.8.5 Процедура «am_member» AM_OK, AM_FAILURE Определен Проверяет, является ли указанный идентификатор станции членом группы. ие Синтаксис AM_RESULT am_member ( AM_GROUP group ); Параметр ввода Возврат group Группа, к которой относится данный идентификатор станции. AM_OK, если идентификатор станции членом группы. В противном случае AM_FAILURE. 6.3.10.9 Интерфейс приложения вызывающего абонента Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.10.9.1 – 275 – Процедура «am_call_request» Определение Синтаксис Запрашивает отправку сообщения вызова, устанавливает структуры данных для получения ответного сообщения и предоставляет подписку на процедуры индикации. void am_call_request ( UNSIGNED8 , const AM_ADDRESS * void * UNSIGNED32 void * UNSIGNED32 UNSIGNED16 Параметр ввода , AM_CALL_CONFIRM void * caller_function caller_function replier, out_msg_adr, out_msg_size, in_msg_adr, in_msg_size, reply_timeout, call_confirm caller_ref ); Идентификатор функции вызывающего абонента. AM_MANAGER_FCT должен использоваться, если адресом ответчика является адрес системы replier Адрес приложения функции ответчика или станции. out_msg_adr указатель на сообщение вызова для передачи. out_msg_size общая длина сообщения вызова в октетах. in_msg_adr указывает буфер, куда следует поместить ответное сообщение. in_msg_size максимальная общая длина ответного сообщения в октетах. reply_timeout значение тайм-аута, кратное 64 мс, для ответа после передачи сообщения вызова. call_confirm указывает на процедуру подтверждения вызова. параметр «call_confirm» будет вызван, если «am_call_request» не будет успешно отменен с помощью am_call_cancel. caller_ref Внешняя ссылка вызова должна быть возвращена параметром «call_confirm». Вызывающий абонент может использовать его любым способом. Эта процедура не возвращает никакого значения, поскольку результат будет предоставлен параметром «call_confirm». Возврат Использование 1 - Перед вызовом «am_call_request» должны быть вызваны процедуры am_init и am_announce_device. 2 - Если in_msg_adr имеет значение NULL (НУЛЬ), мессенджер выделяет буфер для ответного сообщения. Вызывающий абонент затем отвечает за возврат этого буфера после использования путем вызова процедуры am_buffer_free. 3 - Вызов отклоняется, если уже установлен сеанс связи с тем же адресом вызывающего абонента и ответчика (и в том же направлении). 4 - Запись каталога функций для функции ответчика должна быть определена, если идентификатор ответчика равен AM_UNKNOWN. 5 - Связь по шине не осуществляется, если вызывающий агент и ответчик находятся в пределах одной и той же станции. 6 - Вызов с адресом системы отклоняется, если идентификатор функции отличается от 254 (Администратор). 7 - Вызывающий абонент не может изменять буферы сообщений, пока не будет вызвано подтверждение вызова call_confirm. 8 - Тайм-аут ответа по умолчанию, указанный посредством am_announce_device, ожидается, если время ожидания ответа равно 0. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 276 – 6.3.10.9.2 61375-2-1 IEC:2012 Тип «AM_CALL_CONFIRM» Когда запрошенный вызов завершается, возвращая либо статус ошибки, либо полученное ответное сообщение, сеансовый уровень должен вызвать процедуру вызывающего абонента «call_confirm», которая относится к этому типу. Определение Синтаксис typedef void ( * AM_CALL_CONFIRM ) ( caller_function, UNSIGNED8 void * f, const AM_ADDRESS * void * UNSIGNED32 AM_RESULT Параметр ввода caller_function Идентификатор функции вызывающего абонента replier Адрес приложения функции ответчика или станции. am_caller_ref возвращаемое значение, указанное в связанной процедуре «am_call_request» in_msg_adr указывает на буфер, который содержит полученное Ответное сообщение Имеет значение NULL (НУЛЬ), если вызывающий абонент не предоставил буфер для ответного сообщения и если одновременно с этим in_msg_size равно 0. общая длина ответного сообщения в октетах. Значение равно 0, если произошла ошибка или если ответ приложения ответчика включает информацию о состоянии. in_msg_size status Использование am_caller_re replier, in_msg_adr, in_msg_size, status ); выдает код ошибки AM_MAX_ERR или, в случае успеха, состояние, предоставляемое ответчиком. 1 - Подписка на процедуру «call_confirm» должна быть предварительно сделана через «am_call_request» 2 - AM_MANAGER_FCT возвращается, если адресом ответчика является адрес системы. 3 - Подтверждение вызова неявно возвращает буфер сообщения вызова вызывающему абоненту. 4 - Буфер ответного сообщения, который был выделен мессенджером, после использования должен быть возвращен посредством процедуры am_buffer_free. 6.3.10.9.3 Процедура «am_call_cancel» Определение Синтаксис Отменяет запрос вызова, который еще не подтвержден. AM_RESULT am_call_cancel ( UNSIGNED8 , const AM_ADDRESS * Параметр ввода Возврат Использование caller_function replier ); caller_function Идентификатор функции вызывающего абонента replier Адрес приложения вызываемой функции или станции. AM_OK отмена прошла успешно, AM_FAILURE любая ошибка Процедура подтверждения вызова не будет вызвана, если возвращаемое значение равно AM_OK. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.10.10 – 277 – Интерфейс приложения ответчика Следующие подразделы не подразумевают конкретную реализацию. Допускается использование любого интерфейса, обеспечивающего подобную семантику. 6.3.10.10.1 Процедура «am_bind_replier» Определение Определяет ответчик для мессенджера и подключает его процедуры. Синтаксис AM_RESULT am_bind_replier ( UNSIGNED8 replier_function , AM_RECEIVE_CONFIR receive_confirm, M reply_confirm AM_REPLY_CONFIRM ); Параметр ввода replier_function Идентификатор функции ответчика для привязки. receive_confirm процедура подтверждения получения, которая будет вызвана после завершения запроса на получение. reply_confirm процедура подтверждения ответа, которая будет вызвана после завершения ответа. AM_OK = 0 привязка выполнена успешно, в противном случае am_bind_replier не выполняет никаких действий. Возврат AM_ALREADY_USED означает, что данная функция ответчика уже привязана, процедуры подтверждения не изменены. AM_NO_LOC_MEM_ERR, означает, что отсутствует память для таблицы привязки, ни одна функция ответчика не может быть привязана. AM_FAILURE - таблица привязка заполнена. Размер таблицы привязки определяется процедурой am_announce_device. Использование 1 - процедуры «am_init» и «am_announce_device» должны вызваны перед «am_bind_replier». 2 - Каждый ответчик должен быть связан до того, как он сможет выдать любой запрос «am_receive_request». 6.3.10.10.2 Процедура «am_unbind_replier» Определение Отменяет все экземпляры указанного ответчика и удаляет привязку. Синтаксис AM_RESULT UNSIGNED8 Параметр ввода Возврат replier_function am_unbind_replier ( replier_function ); Идентификатор функции ответчика, который должен быть отвязан. AM_OK, AM_FAILURE Использование Вызовы, которые были получены до вызова am_unbind_replier, но на которые еще не был получен ответ, отменяются. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 278 – 6.3.10.10.3 61375-2-1 IEC:2012 Процедура «am_receive_request» Определение Сообщает, что ответчик готов принять входящий вызов. Синтаксис AM_RESULT UNSIGNED8 void * UNSIGNED32 void * Параметр ввода replier_function in_msg_adr in_msg_size replier_ref Возврат am_receive_request ( replier_function, in_msg_adr, in_msg_size, replier_ref ); Идентификатор функции ответчика, ожидающего вызов. Идентификатор функции Function_Id = 253 подразумевает алрес системы. Указывает на буфер для входящего сообщения вызова. Мессенджер выделяет буфер для сообщения вызова, если in_msg_adr имеет значение NULL (НУЛЬ). Этот буфер не может быть изменен до тех пор, пока процедура «am_receive_request» не будет подтверждена или отменена. Максимальный общий размер сообщения вызова в октетах, который может быть принят. Внешняя ссылка, возвращенная соответствующей процедурой receive_confirm. В то же время он является экземпляр ссылается и различает экземпляры ответчика, которые обслуживают один и тот же ответчик. AM_OK связанная процедура подтверждения приема будет вызвана для пропускания принятого вызова, если запрос не отменен. AM_ALREADY_USED тот же экземпляр ответчика уже выдал запрос на получение, который еще не подтвержден, не отменен и на него еще не получен ответ. AM_FAILURE Ответчик не привязан; AM_NO_LOC_MEM_ERR недостаточно памяти для принятия процедуры «am_receive_request»; AM_NR_OF_INST_OVF было отправлено больше одновременных запросов «am_receive_request», чем было ограничено параметром «max_inst_number» для процедуры «am_announce_device». Использование Эта процедура требует, чтобы предварительно была вызвана процедура «am_bind_replier» для того же ответчика. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.3.10.10.4 – 279 – Тип «AM_RECEIVE_CONFIRM» Определение Когда сеансовый уровень получает сообщение вызова, он должен вызвать процедуру подтверждения приема receive_confirm, относящуюся к этому типу. Синтаксис typedef void ( * AM_RECEIVE_CONFIRM ) ( UNSIGNED8 replier_functi on, const AM_ADDRESS caller, * in_msg_adr , void * in_msg_size, UNSIGNED32 replier_ref void * ); Параметр ввода replier_function Идентификатор функции ответчика, как указано в соответствующей процедуре «am_receive_request». caller Адрес вызывающего абонента in_msg_adr Указывает на буфер, который содержит сообщение вызова. in_msg_size Общая длина полученного сообщения вызова в октетах. replier_ref Внешняя ссылка, как указано в соответствующей процедуре «am_receive_request». Использование 1 - Подписка на процедуру подтверждения получения «receive_confirm» ранее была сделана процедурой «am_bind_replier». 2 - Если экземпляр ответчика не предоставил буфер в ходе процедуры «am_receive_request», буфер ответа предоставляется мессенджером, и ответчик должен вернуть его после использования посредством процедуры «am_buffer_free». Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 280 – 6.3.10.10.5 61375-2-1 IEC:2012 Процедура «am_reply_request» Запросы на отправку ответного сообщения в ответ на ранее полученное сообщение вызова Определение Синтаксис AM_RESULT UNSIGNED8 void * UNSIGNED32 void * AM_RESULT Параметр ввода replier_function Идентификатор функции ответчика, как указано в соответствующей процедуре «am_receive_request». replier_ref Внешняя ссылка, как указано в соответствующей процедуре «am_receive_request» out_msg_adr указывает на буфер ответного сообщения. Этот буфер не должен изменяться до тех пор, пока ответный запрос не будет подтвержден. Если out_msg_adr имеет значение NULL (НУЛЬ), вызывающему абоненту передается только состояние (status). общая длина ответного сообщения в октетах. out_msg_size status Возврат Использование am_reply_request ( replier_function, out_msg_adr, out_msg_size, replier_ref status); результат выполнения вызова, предоставленный ответчиком, переданный вызывающей стороне в дополнение к самому ответному сообщению. AM_OK, AM_FAILURE 1 На каждый полученный вызов следует ответить посредством процедуры «am_reply_request» или отменить с помощью «am_receive_cancel». 2 - Эта процедура возвращается до передачи ответного сообщения. 3 - Мессенджер передает это ответное сообщение вместе с указанным состоянием обратно вызывающему абоненту. 4 - Адрес вызывающего абонента извлекается из экземпляра ответчика. 6.3.10.10.6 Тип «AM_REPLY_CONFIRM» Определение Синтаксис Когда сообщение Reply_Message полностью отправлено и подтверждено вызывающим абонентом, или когда произошла какая-либо ошибка, сеансовый уровень вызывает процедуру подтверждения ответа «reply_confirm», которая относится к этому типу. typedef void UNSIGNED8 void * Параметр ввода Использование ( * AM_REPLY_CONFIRM ) ( replier_function, replier_ref ); replier_function Идентификатор функции ответчика, как указано в соответствующей процедуре «am_receive_request». replier_ref Внешняя ссылка, как указано в соответствующей процедуре «am_receive_request» 1 - подписка на «reply_confirm» была предварительно сделана посредством процедуры «am_bind_replier.» 2 - Эта процедура возвращает буфер ответного сообщения обратно в экземпляр ответчика. 3 - Подтверждение ответа разрешает еще одну процедуру «am_receive_request» для того же экземпляра ответчика. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 281 – Процедура «am_receive_cancel» 6.3.10.10.7 Определение Синтаксис Отменяет процедуру «am_receive_request» или «am_reply_request», которые еще не подтверждены, или выдает оповещение, что на полученный вызов не будет ответа. AM_RESULT UNSIGNED8 void * Параметр ввода replier_function replier_ref Возврат am_receive_cancel ( replier_function, replier_ref ); Идентификатор функции ответчика, как указано в соответствующей процедуре «am_receive_request». Внешняя ссылка, как указано в соответствующей процедуре «am_receive_request» AM_OK, AM_FAILURE Использование 1 - Процедура подтверждения успешно отмененного запроса на ответ «reply request» больше не будет вызываться. 2 - Пользователь должен определить, завершен ли запрос на получение (т.е. сообщение вызова все еще остается полученным) или нет, и освободить динамические буферы для сообщений вызова. Процедура «am_buffer_free» 6.3.10.11 Определение Синтаксис Освобождает буфер сообщений, ранее выделенный сеансовым уровнем, после его использования. AM_RESULT void * UNSIGNED32 Параметр ввода Возврат in_msg_adr указывает на освобожденный буфер. size общая длина данного буфера в октетах. AM_OK, AM_FAILURE Использование 6.3.10.12 am_buffer_free ( in_msg_adr, size ); Распределение буфера не зависит от управления пулом пакетов. Интерфейс приложения многоадресной передачи Интерфейс приложения для многоадресных сообщений должен быть идентичен интерфейсу для одноадресных сообщений. Ожидается, что ответчик не отправит обратно ответное сообщение, но ожидается, что он вызовет процедуру «am_reply_request» для освобождения динамического буфера, если таковой используется. Однако в этом случае не должно генерироваться ответное сообщение. 6.4 6.4.1 Представление и кодирование передаваемых и хранящихся данных Цель В этом подпункте определяются типы данных и абстрактная синтаксическая нотация для выражения этих типов данных, а также правила кодирования, используемые для передачи или хранения. Эта нотация основана на ASN.1 (ISO/IEC 8824), но включает дополнительные конструкции, подходящие для связи в реальном времени. Напротив, кодирование внутренних интерфейсов устройства выполнено на на языке «C», который менее точен. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 282 – 61375-2-1 IEC:2012 Порядок следования данных 6.4.2 6.4.2.1 Формат передачи Этот стандарт предписывает порядок, в котором биты и слова передаются по сети поездной связи. С этой целью в стандарте определен ряд примитивных типов и структурированных типов. Значение данных выходит за область применения настоящего стандарта. 6.4.2.2 Формат хранилища трафика (Traffic_Store) Данный стандарт рекомендует хранить данные в хранилище трафика (Traffic_Store) в том же формате, в котором они передаются по шине, обрабатывая их как массив октетов. 6.4.2.3 Формат данных приложения Этот стандарт не определяет формат данных приложения. Ожидается, что процедуры интерфейса будут преобразовывать форматы данных приложения в форматы, используемые для хранения или передачи, и наоборот. 6.4.2.4 Основные правила a) Структуры данных нумеруются слева направо и сверху вниз в порядке чтения английского текста. Первый элемент сверху и слева имеет нулевой сдвиг. b) Память должна рассматриваться как массив октетов и передаваться в порядке возрастания адреса, независимо от размера передаваемых единиц (октетами, 32-битными словами и т.д.). Первый октет имеет нулевой сдвиг октета. c) Биты в структуре данных должны быть идентифицированы по их сдвигу относительно начала структуры. Если структура содержит целое беззнаковое число, младший бит этого целого числа будет иметь нулевой сдвиг. Этот бит считается «самым правым» при чтении структуры данных. d) Для повышения доступности восприятия нумерация битов в следующих разделах 6.4.3.x приведена в соответствие с представлением программиста о структуре данных хранилища трафика. Таким образом, битовый сдвиг x можно интерпретировать как xый в степени два 2x. xый бит в наборе битов можно вычислить как сдвиг октета и сдвиг бита следующим образом: сдвиг октета = х, деленный на 8 с округлением в меньшую сторону, сдвиг бита (внутри октета) = х по модулю 8. e) Все данные должны передаваться старшим октетом (от старшего к младшему) f) Порядок передачи битов внутри октета считается вопросом шины, невидимым для программиста. Например, в протоколах HDLC, используемых в проводной шине поезда, сначала передается младший бит октета (сдвиг 7), а в многофункциональной поездной шине он передается последним. g) Информация о типе данных не отправляется вместе с данными. Ожидается, что типы будут определены и согласованы заранее между пользователями сети поездной связи в конкретном приложении. h) Элементы структурированного типа (запись, последовательность) должны передаваться в порядке их объявления. i) Массивы должны передаваться в порядке возрастания индекса. Многомерные массивы передаются в том порядке, в котором перечислены их индексы (например, МАССИВ (ARRAY OF) [строка, столбец] передается построчно). j) Для облегчения реализации переменная должна храниться по адресу смещения, кратному ее размеру (выравнивание). k) Данные переменной длины (открытые массивы, записи, наборы и т.д.) не должны использоваться в качестве переменных процесса, но могут передаваться в сообщениях. 6.4.2.5 Взаимосвязь с ASN.1 SO/IEC 8824 определяет абстрактную синтаксическую нотацию один (ASN.1) для выражения структур данных в машиночитаемой форме. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 283 – Хотя ASN.1 не навязывает синтаксис передачи, нотация не может выразить правила компактного кодирования, часто используемые программистами в условиях ограниченной пропускной способности или времени. Кроме того, нотация не может выражать уже существующие кодировки, которые не подчиняются ее методу структурирования. Таким образом, в настоящем стандарте определен абстрактный синтаксис, основанный на ASN.1, который одновременно выражает кодировку данных и побитовое содержание данных. Следующие ключевые слова были добавлены в ASN.1: ALIGN ANTIVALENT2 ARRAY BCD4 BIPOLAR2.16 BIPOLAR4.16 BITSET# BITSET_L# BOOLEAN1 BOOLEAN8 ENUM# INDIRECT INTEGER# INTEGER_L# ONE_OF REAL32 REAL64 RECORD SOME_OF STOP STRING# TIME64 TIMEDATE48 UNICODE16 UNIPOLAR2.16 UNSIGNED# UNSIGNED_L# WORD# В этой нотации используются правила компактного кодирования: предполагается, что все определяемые пользователем типы распознаются адресатом; нотация использует примитивные типы фиксированного размера (в ASN.1 целое число может быть любого размера); размер элементов вносится явно в специальное поле, где это необходимо; нотация вводит собственные ключевые слова, чтобы избежать путаницы с ASN.1, где семантика аналогична, но отличается (например, ONE_OF вместо CHOICE, SOME_OF вместо SET); неявная маркировка типов не используется, за исключением типов ONE_OF и SOME_OF, где маркировка явно выполняется посредством выделенного поля; отсутствуют дополнительные поля (кроме SOME_OF); выравнивание отсутствует, хотя выравнивание можно указать. Для нотации используются следующие правила: ключевые слова, включая основные типы, и постоянные идентификаторы записываются полностью в верхнем регистре; идентификаторы типов начинаются с заглавной буквы; идентификаторы полей начинаются со строчной буквы. 6.4.3 6.4.3.1 6.4.3.1.1 Нотация для примитивных типов Нотация для булева типа Определение Примитивный тип с двумя различающимися значениями: TRUE (ИСТИНА) и FALSE (ЛОЖЬ). ПРИМЕЧАНИЕ 1 Определение «BooleanType» («Булева типа») см. в ASN.1. ПРИМЕЧАНИЕ 2 Этот тип используется для представления двоичных входов и выходов (реле, светодиод, микропереключатель и т.д.) 6.4.3.1.2 Синтаксис BooleanType::= BOOLEAN1 6.4.3.1.3 Кодирование Переменная булева типа должна быть закодирована как один бит: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 284 – 1ый 61375-2-1 IEC:2012 интерпретация 0 FALSE (ЛОЖЬ) 1 TRUE (ИСТИНА) Нотация для антивалентного типа 6.4.3.2 Определение 6.4.3.2.1 Примитивный тип с четырьмя выделенными значениями. ПРИМЕЧАНИЕ 1 Не является типом ASN.1. ПРИМЕЧАНИЕ 2 Переменные этого типа используются в качестве контрольных переменных для других переменных или для критических булевых. Синтаксис 6.4.3.2.2 AntivalentType::= ANTIVALENT2 Кодирование 6.4.3.2.3 Переменная антивалентного типа должна передаваться как 2 бита, первый из которых соответствует логическому значению переменной, а второй — обратному. Она может принимать одно из четырех состояний: 1 0 2+1 20 0 0 0 1 1 0 1 1 интерпретация ERROR (ОШИБКА) FALSE (ЛОЖЬ) TRUE (ИСТИНА) UNDEFINED (НЕОПРЕДЕЛЕННОЕ) ПРИМЕЧАНИЕ Состояния ERROR (ОШИБКА) и UNDEFINED (НЕОПРЕДЕЛЕННОЕ) могут быть интерпретированы приложением как допустимые состояния. 6.4.3.3 6.4.3.3.1 Нотация для типов целых беззнаковых чисел Определение Примитивный тип с выделенными значениями, представляющими собой положительные целые числа, включая ноль (как одно значение), имеющий фиксированный размер в битах, определяемый постфиксом #. ПРИМЕЧАНИЕ Это является «IntegerType» ASN.1, ограниченный фиксированным размером # и неотрицательными значениями. 6.4.3.3.2 Синтаксис UnsignedType::= UNSIGNED#, (# = any unsigned integer). 6.4.3.3.3 Кодирование Целое число без знака должно передаваться в двоичном представлении, с первым старшим битом. Когда переносимое значение имеет меньший размер, чем тип UNSIGNED#, оно должно быть выровнено по правому знаку и дополнено нулями с левой стороны. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 285 – Кодирование UNSIGNED8 6.4.3.3.3.1 7 6 5 4 3 2 1 0 27 26 25 24 23 22 21 20 Диапазон: 0..255 Кодирование UNSIGNED16 6.4.3.3.3.2 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Диапазон: 0..65535 Кодирование UNSIGNED32 6.4.3.3.3.3 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 31 15 30 14 29 13 28 12 27 11 26 10 25 9 24 8 23 7 22 6 21 5 20 4 19 3 18 2 17 1 16 0 Диапазон: 0..+232–1 Нотация для целочисленного типа 6.4.3.4 Определение 6.4.3.4.1 Примитивный тип с выделенными значениями, представляющими собой положительные и отрицательные целые числа, включая ноль (как одно значение), имеющий фиксированный размер в битах, определяемый постфиксом #. ПРИМЕЧАНИЕ Это «целочисленный тип» («integer type») ASN.1, ограниченный фиксированным размером #. Синтаксис 6.4.3.4.2 IntegerType::= INTEGER#, (# = any unsigned integer). Кодирование 6.4.3.4.3 Значение должно быть представлено в двоичном дополнении до 2, причем первый переданный бит является битом знака. Когда переносимое значение имеет меньший размер, чем тип INTEGER#, оно должно быть выровнено по правому знаку и дополнено знаком с левой стороны (если оно отрицательное, то «1», в противном случае «0»). Кодирование INTEGER8 6.4.3.4.3.1 7 6 5 4 3 2 1 0 знак 2 2 2 2 2 2 2 6 5 4 3 2 1 0 Диапазон: –128 .. +127 ПРИМЕР ‘1111 1110’B = – 2 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 286 – Кодирование INTEGER16 6.4.3.4.3.2 15 знак 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Диапазон: –215.. 215 – 1 Кодирование INTEGER32 6.4.3.4.3.3 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 знак 2 2 30 2 2 28 2 2 2 2 2 2 2 2 2 2 2 2 2 14 2 2 12 2 2 10 2 9 2 8 2 2 6 2 5 2 2 2 2 2 2 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 29 13 27 11 26 25 24 23 7 22 21 20 4 19 3 18 17 1 16 0 Диапазон: –231..+231 – 1 6.4.3.5 6.4.3.5.1 Нотация для перечислимого типа Определение Примитивный тип, значениям которого присваиваются отдельные идентификаторы как части нотации типа, имеющий фиксированный размер в битах, определяемый постфиксом #. ПРИМЕЧАНИЕ Это ПЕРИЧИСЛЯЕМЫЙ (ENUMERATED) тип ASN.1, ограниченный фиксированным размером #. 6.4.3.5.2 Синтаксис EnumeratedType::= ENUM#{Enumeration} с (# = any unsigned integer) Enumeration::= NamedNumber | Enumeration, NamedNumber и NamedNumber::= identifier (UnsignedNumber) | identifier (DefinedValue) Значения могут быть перечислены в любом порядке. ПРИМЕР Day_Of_Week_Type::= ENUM4 { monday (1), tuesday (2), wednesday (3), thursday (4), friday (5), saturday (6), sunday (7), undefined (0) } Значение «2» означает «TUESDAY» («ВТОРНИК»). 6.4.3.5.3 Кодирование Значения ENUM# должны быть представлены целым беззнаковым числом, занимающим то же место. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 287 – Кодирование ENUM4 6.4.3.5.3.1 3 2 1 0 23 22 21 20 Диапазон: 0..15 ПРИМЕР В приведенном выше примере ‘0001’B означает «Monday» («Понедельник»). Кодирование ENUM8 6.4.3.5.3.2 7 6 5 4 3 2 1 0 27 26 25 24 23 22 21 20 Диапазон: 0..255 ПРИМЕР В приведенном выше примере ‘0001’B означает «Monday» («Понедельник») (учитывая, что это ENUM8, а не ENUM4). Нотация для типа двоично-десятичного кода 6.4.3.6 Определение 6.4.3.6.1 4-битное целое беззнаковое число, выражающее десятичную цифру от 0 до 9. ПРИМЕЧАНИЕ Данный тип не существует в ASN.1. Синтаксис 6.4.3.6.2 BinaryCodedDecimalType::= BCD4 Кодирование 6.4.3.6.3 BCD4 должно быть закодировано как целое беззнаковое число, занимающее то же место. 3 2 1 0 23 22 21 20 Диапазон: 0..9 (другие значения не определены) ПРИМЕР ‘0111’B = 7. ПРИМЕЧАНИЕ Могут использоваться некоторые неопределенные значения, например, для обозначения знака или другого арифметического оператора. 6.4.3.7 6.4.3.7.1 Нотация для однополярных типов Определение Примитивные типы с выделенными неотрицательными целыми числами, разделенными на фиксированную степень два, выражающие значение в процентах от диапазона. ПРИМЕЧАНИЕ Эти типы не существуют в ASN.1, они выражены в IEC 870 как «беззнаковое число с фиксированной точкой». 6.4.3.7.2 Синтаксис UnipolarType::= UNIPOLAR2.16 ПРИМЕЧАНИЕ 1 Число перед запятой дает число в степени 2, образующее целую часть. ПРИМЕЧАНИЕ 2 Эпсилон-переход равен значению наименьшей степени двойки в слове (двойном байте). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 288 – Кодирование 6.4.3.7.3 Переменная однополярного типа должна должна передаваться как целое беззнаковое число. Кодирование UNIPOLAR2.16 6.4.3.7.3.1 15 14 13 12 11 10 2 2 2 2 2 2 1 0 -1 -2 -3 -4 9 2 -5 целая часть 8 2 -6 7 2 -7 6 2 -8 5 2 -9 4 2 -10 3 2 -11 2 2 -12 1 2 -13 0 2 -14 дробная часть Диапазон: 0 .. 400 % – эпсилон Нотация для биполярных типов 6.4.3.8 Определение 6.4.3.8.1 Примитивные типы с выделенными положительным или отрицательными целыми числами, разделенными на фиксированную степень два, выражающие значение в процентах от диапазона. ПРИМЕЧАНИЕ Эти типы не существуют в ASN.1, они выражены в IEC 60870-5-1 как «знаковое число с фиксированной точкой». Синтаксис 6.4.3.8.2 BipolarType::= BIPOLAR2.16 | BIPOLAR4.16 ПРИМЕЧАНИЕ 1 Число перед точкой дает число в степени 2, образующее целую часть. ПРИМЕЧАНИЕ 2 Эпсилон-переход равен значению наименьшей степени двойки в слове (двойном байте). Кодирование 6.4.3.8.3 Кодирование BIPOLAR2.16 6.4.3.8.3.1 15 14 13 12 11 10 знак 2 2 2 2 2 0 -1 -2 -3 -4 9 2 -5 8 2 целая часть -6 7 2 -7 6 2 -8 5 2 -9 4 2 -10 3 2 -11 2 2 -12 1 2 -13 0 2 -14 дробная часть Диапазон: –200 %..+200 %-эпсилон Кодирование BIPOLAR4.16 6.4.3.8.3.2 15 14 13 12 11 10 знак 2 2 2 2 2 2 1 0 -1 -2 9 2 -3 8 2 -4 целая часть 7 2 -5 6 2 -6 5 2 -7 4 2 -8 3 2 -9 2 2 -10 1 2 -11 0 2 -12 дробная часть Диапазон: -800 %..+800 %-эпсилон 6.4.3.9 6.4.3.9.1 Нотация для вещественного типа Определение Примитивный тип, отличительные значения которого являются членами множества вещественных чисел. 6.4.3.9.2 Синтаксис RealType::= REAL32 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 289 – Кодирование 6.4.3.9.3 Этот тип должен быть закодирован в соответствии с требованиями стандарта IEEE 754 для короткого вещественного числа (32 бита). ПРИМЕЧАНИЕ Представляет собой вещественный тип («RealType») ASN.1, ограниченный форматом короткого вещественного числа IEEE 754. ПРИМЕЧАНИЕ 2 64-битное число с плавающей точкой стандарта IEEE 754 (REAL64) в этом контексте не считается полезным. 31 30 знак 2 27 15 14 29 28 27 26 25 24 смещенный порядок 23 22 2 2 0 21 20 19 18 17 мантисса -1 2 7 мантисса -8 13 12 11 10 9 8 7 16 2 -23 6 5 4 3 2 1 0 Диапазон: 3,37 10+38 Нотация для символьного типа 6.4.3.10 6.4.3.10.1 Определение Примитивный тип, отличительные значения которого являются членами набора символов, определенного в ISO/IEC 8859-1. 6.4.3.10.2 Синтаксис CharacterType::= CHARACTER8 6.4.3.10.3 Кодирование Символы должны передаваться одним октетом без бита четности. 7 6 5 4 3 2 1 0 2 2 2 2 2 2 2 2 7 6 5 4 3 2 1 0 ПРИМЕР ‘01100001’B = символ «а» согласно ISO/IEC 8859-1. Нотация для типа символа Unicode 6.4.3.11 6.4.3.11.1 Определение Примитивный тип, отличительные значения которого являются членами набора символов, определенного в ISO/IEC 10646. 6.4.3.11.2 Синтаксис UnicodeType::= UNICODE16 6.4.3.11.3 Кодирование Символы Unicode должны передаваться в двух октетах. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 290 – Нотация для свободных типов 6.4.3.12 6.4.3.12.1 Определение Свободный тип неопределенного содержимого, но фиксированного размера. 6.4.3.12.2 Синтаксис AnyType::= WORD#, (# = any unsigned integer) 6.4.3.12.3 Кодирование Переменная свободного типа не имеет предписанной кодировки. Биты должны быть названы в соответствии с переменной типа UNSIGNED# в степени два, которая будет занимать это место. ПРИМЕЧАНИЕ Наименование осуществляется в обратном направлении, как сдвиг внутри того же слова. Кодирование WORD8 6.4.3.12.3.1 7 6 5 4 3 2 1 0 27 26 25 24 23 22 21 20 Кодирование WORD16 6.4.3.12.3.2 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 215 214 213 212 211 210 29 28 27 26 25 24 23 22 21 20 Структурированные типы 6.4.4 6.4.4.1 Общие положения Определено пять различных структурированных типов: a) RECORD (переменная длина), b) ARRAY (фиксированная длина или переменная длина), c) BITSET# (фиксированная длина), d) ONE_OF (переменная длина) e) SOME_OF (переменная длина). 6.4.4.2 6.4.4.2.1 Нотация для типов записей Определение Структурированный тип, определяемый ссылкой на фиксированный упорядоченный список типов; каждое значение нового типа представляет собой упорядоченный список значений, по одному из каждого типа компонентов. ПРИМЕЧАНИЕ 1 Этот тип представляет собой «тип последовательности» («Sequence Type») ASN1 без опциональных типов. ПРИМЕЧАНИЕ 2 При определении RECORD (ЗАПИСЬ) рекомендуется соблюдать выравнивание, т.е. все элементы должны располагаться со сдвигом относительно начала записи, кратным их размеру. 6.4.4.2.2 Синтаксис RecordType::= RECORD { ElementTypeList } с Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 291 – ElementTypeList::= ElementType | ElementTypeList, ElementType и ElementType::= identifier Type | Type Элементы RECORD (ЗАПИСЬ) должны быть идентифицированы идентификатором поля RECORD, за которым следует точка и идентификатор субполя, который сам может быть структурированного типа. ПРИМЕР: file.date.day 6.4.4.2.3 Кодирование Элементы RECORD должны передаваться в порядке их объявления. ПРИМЕР Значение типа Date32 представлено следующим образом: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 year (год) dummy (фиктивный параметр) month (месяц) day (день) Date32::= RECORD { year INTEGER16, dummy WORD4, month UNSIGNED4, day UNSIGNED8 } «dummy» («фиктивный параметр») был введен для выравнивания переменной «day» («день») по границе 16-битного слова. 6.4.4.3 6.4.4.3.1 Нотация для наборов битов Определение МАССИВ ARRAY [#] of BOOLEAN1, имеющий фиксированный размер в битах, определяемый постфиксом #. ПРИМЕЧАНИЕ Данный тип соответствует BITSTRING в ASN.1. 6.4.4.3.2 Синтаксис BitsetType::= BITSET# {NamedBitList} с NamedBitList::= NamedBit | NamedBitList, NamedBit и NamedBit::= identifier (number) | identifier (DefinedValue) a) Значение каждого «числа» или «DefinedValue», появляющегося в «NamedBitList», должно отличаться и является сдвигом выделенного бита в значении набора битов. b) Каждый идентификатор, появляющийся в «NamedBitList» должен отличаться. c) Все элементы неявно имеют тип BOOLEAN1. Идентификатор DefinedValue может быть только TRUE (1) (ИСТИНА) или FALSE (0) (ЛОЖЬ). d) Элементы должны быть объявлены в порядке увеличения сдвига. e) Если все элементы BITSET (НАБОРА БИТОВ) заявлены, «число» можно опустить. Это должно быть нормальным случаем. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 292 – Кодирование 6.4.4.3.3 Элементы набора битов должны передаваться в порядке их объявления. Кодирование BITSET8 6.4.4.3.3.1 7 8 6 5 4 3 2 1 0 1ый ой Диапазон: 8-Битный набор булевых ПРИМЕР AccessType8::= BITSET8 { system (0), -- first bit of the bitset (LSB) owner (1), group (2), world (3), } эквивалентно AccessType8::= BITSET8 { system, -- first bit of the bitset (LSB) owner, group, world, reserved4 reserved5 reserved6 reserved7 -- 8th or last bit of the bitset (MSB) } UNSIGNED8, занимающий это пространство со значением ‘01’H, означает, что «система» является единственным членом набора. 6.4.4.3.3.2 8 Кодирование BITSET16 1ый 16 ой ый 9 ый ПРИМЕР AccessType::= BITSET16 { system (0), owner (1), group (2), world (3)} Значение ‘0000 0000 0000 0110’B означает, что «owner» («владелец») и «group» («группа») являются членами набора. 6.4.4.3.3.3 8 ый 24 ый Кодирование BITSET32 1ый 16 9 17 32ой 25 ый ый ый ый Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.4.4.3.3.4 – 293 – Кодирование BITSET64 8ый 1ый 16ый 9ый 24ый 40ый 17ый 33ий 32ой 48ый 25ый 41ый 56ый 49ый 64ый 57ый 6.4.4.4 6.4.4.4.1 Нотация для типа массива Определение Структурированный тип, определяемый ссылкой на один существующий тип; каждое значение нового типа представляет собой упорядоченный список из нуля, одного или нескольких значений существующего типа. Положение каждого значения определяется индексом. Количество значений указывается либо постоянной, либо полем встраиваемой структуры. Количество значений может быть опущено, если указан стоповый элемент. ПРИМЕЧАНИЕ ARRAY (МАССИВ) представляет собой последовательность типов («SequenceOf Type») ASN 1, количество элементов которой указвыается постоянной, специальной переменной или вообще не указывается (стоповый элемент). 6.4.4.4.2 Синтаксис ArrayType::= ARRAY [IndexList] OF Type IndexList::= Index | IndexList, Index Index::= number | DefinedValue | identifier | identifier UnsignedType | UnsignedType | STOP = Value Число, DefinedValue (определенное значение) или идентификатор определяют размер массива в количестве элементов (0 для пустого массива). Его тип должен быть целым беззнаковым числом. Если указан беззнаковый тип с определенным идентификатором, это объявляет соответствующее поле. Если идентификатор называет поле, объявленное вне массива, это поле должно быть расположено в структуре встраиваемых данных на том же уровне вложенности или быть субполем поля, расположенного на том же уровне вложенности, и в этом случае должно быть указано имя полного пути. Если стоповое значение определено для закрытия открытого массива, это значение должно быть того же типа, что и элемент массива. Размер может быть задан арифметическим выражением. 6.4.4.4.3 Кодирование Массивы должны передаваться в порядке возрастания индекса. Многомерные массивы должны передаваться в порядке перечисления их индексов. ПРИМЕЧАНИЕ МАССИВ (ARRAY OF) [строка, столбец] передается построчно. Массивы октетов (свободное содержимое, например, дамп памяти) должны передаваться по возрастанию адреса (или индекса) памяти приложения. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 294 – Передаются все элементы массива, даже те, которые не являются значимыми. ПРИМЕР 1 Передача дампа памяти октета: DumpOctetType::= ARRAY [octet_count UNSIGNED16] OF WORD8. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 счетчик октетов (octet_count) октет по адресу М октет по адресу М+1 октеты октет по адресу (M + счетчик октетов-2) октет по адресу (M + счетчик октетов-1) ПРИМЕР 2 Передача того же дампа памяти 16-битными словами, где «word_count» (счетчик слов) имеет половину значения «octet_count» (счетчик октетов) из предыдущего примера: DumpWordType::= ARRAY [word_count UNSIGNED16] OF WORD16. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 счетчик слов (word_count) слово по адресу М слово по адресу (M + счетчик слов 2 – 2) ПРИМЕР 3 Количество элементов, заданных полем в структуре данных вложенности (при неопределенном сдвиге): DumpOctetType::= ARRAY [array_count] OF WORD8. ПРИМЕР 4 Количество элементов, заданных полем структурированного значения во вложенной структуре: HeaderType::= RECORD { name bodysize ... } FrameType::= RECORD { header body } ARRAY [32] OF CHARACTER8 UNSIGNED16, HeaderType ARRAY [ header.bodysize ] OF CHARACTER8 ПРИМЕР 5 Строки символов, в которых стоповые символы является «пробелом»: ProfibusString::= ARRAY [STOP = ‘20’H] OF CHARACTER8. 6.4.4.5 6.4.4.5.1 Нотация для типа выбора Определение Структурированный тип, определяемый ссылкой на фиксированный неупорядоченный список различных типов; каждое значение нового типа является значением (точным) одного из типов компонентов. ПРИМЕЧАНИЕ Этот тип соответствует «ChoiceType» («выбору типа») в ASN1, но имеет специальный тег. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 6.4.4.5.2 – 295 – Синтаксис OneOfType::= ONE_OF [identifier | identifier EnumeratedType] {AlternativeTypeList} с AlternativeTypeList::= ElementType | ElementTypeList, ElementType и ElementType::= identifier [tag] Type | [tag] Type и tag::= UnsignedNumber | DefinedValue | identifier Если в качестве тега используется именованная переменная, эта переменная должна находиться в структуре, в которой находится элемент. Если переменная тега расположена на том же уровне вложенности, что и выбор, должно быть включено только имя переменной. Если переменная находится на другом уровне вложенности, должен быть включен путь к тому же уровню вложенности. ПРИМЕР 1 Тег представляет собой число (не рекомендуется, поскольку это число должно быть определено в разных местах): Commands::= ONE_OF [choice_var ENUM8] { [3] OpenSequence, [2] CloseSequence, [5] StandbySequence } ПРИМЕР 2 Тег представляет собой перечисляемый тип, расположенный в 16 битах перед выбором: CommandType::= { OPEN CLOSE STANDBY } ENUM16 (3), (2), (5) Commands::= ONE_OF [choice_var CommandType] { [OPEN] OpenSequence, [CLOSE] CloseSequence, [STANDBY] StandbySequence } ПРИМЕР 3 Тег определяется на том же уровне вложенности во встраиваемой структуре: Commands::= ONE_OF [choice_var] { [OPEN] OpenSequence, [CLOSE] CloseSequence, [STANDBY] StandbySequence } Command_Frame::== RECORD { choice_var CommandType, ... Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 296 – command Commands; ... } ПРИМЕР 4 Тег определяется в субполе поля, расположенного на том же уровне вложенности: Commands::= ONE_OF [Command_Frame.header.choice_var] { [OPEN] OpenSequence, [CLOSE] CloseSequence, [STANDBY] StandbySequence } Command_Frame::== RECORD { header { ....addresses choice_var .... } commands } RECORD ... CommandType Commands ПРИМЕЧАНИЕ Относительные пути (например, -/-/header) не рекомендуется использовать. 6.4.4.5.3 Кодирование Команда ONE_OF должна быть закодирована путем передачи перед значением поля тега, указывающего, какой выбор был сделан. Размер передаваемого значения является либо неявным, либо указывается в самом типе. ПРИМЕЧАНИЕ ONE_OF является SOME_OF только с одним элементом. ПРИМЕР Конкретное значение вышеуказанного выбора команд будет передано как: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 choice_var (= 5) (переменная выбора) первый октет (StandbySequence) (резервная последовательность) последний октет (StandbySequence) (резервная последовательность) или фиктивный параметр 6.4.4.6 6.4.4.6.1 Нотация для типов набора Определение Структурированный тип, определяемый ссылкой на фиксированный, неупорядоченный список различных типов, некоторые из которых могут быть объявлены как опциональные; каждое значение нового типа представляет собой неупорядоченный список значений, по одному для каждого из типов передаваемых компонентов. ПРИМЕЧАНИЕ Этот тип соответствует «SetType» («тип набора») в ASN1, но имеет явный тег. 6.4.4.6.2 Синтаксис SetType::= SOME_OF { ElementTypeList} с Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 297 – ElementTypeList::= ElementType | ElementTypeList, ElementType и ElementType::= [tag] NamedType и tag::= identifier | identifier ElementType | ElementType Если тег является именованной переменной, соответствующая переменная должна принадлежать структуре данных того же уровня вложенности или принадлежать субполю поля того же уровня вложенности, и в этом случае идентификация переменной осуществляется ее полным путем. Если количество членов типа набора фиксировано, ссылочное имя может быть опущено для каждого члена, назначение которого является очевидным, исходя из его типа. Если селектор является перечислимым типом, постоянные перечисления, используемые для выбора элементов набора, должны быть заключены в скобки. Если переменная набора битов используется в качестве селектора, эта переменная должна быть определена ранее в структуре встраиваемых данных или принадлежать субполю поля на том же уровне вложенности, и в этом случае она должна быть идентифицирована своим полным именем пути. ПРИМЕР 1 Тег как целое беззнаковое число в поле, предшествующем заданному значению. MemberType::= SOME_OF [UNSIGNED8] { OPENSEQ [3] CLOSESEQ [2] STANDBY [5] } Type_OpenSequence, Type_CloseSequence, Type_StandbySequence ПРИМЕР 2 Пропуск ссылочного имени MemberType::= SOME_OF [UNSIGNED8] { [3] Type_OpenSequence, [2] Type_CloseSequence, [5] Type_StandbySequence } ПРИМЕР 3 Перечисляемый тип в качестве тега (рекомендуемая практика) MemberType { OPENSEQ CLOSESEQ STANDBY } .. CommandsType::= { [OPENSEQ] [CLOSESEQ] [STANDBY] } ENUM8 (3), (2), (5) SOME_OF [MemberType] Type_OpenSequence, Type_CloseSequence, Type_StandbySequence Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 298 – ПРИМЕР 4 Использование набора битов в качестве тега MembersType { OPENSEQ CLOSESEQ STANDBY } ... CommandsType::= { [OPENSEQ] [CLOSESEQ] [STANDBY] } BITSET8 (3), (2), (5) SOME_OF [members] Type_OpenSequence, Type_CloseSequence, Type_StandbySequence Commands_Frame::= RECORD { ... members MembersType, ... commands CommandsType ... } 6.4.4.6.3 Кодирование Набор должен быть закодирован путем передачи каждого выбранного значения. Если тег включен, он должен предшествовать каждому выбранному значению, конкретное значение тега ‘FF’H (все единицы) закрывает передаваемый набор. Если тег заменяется набором битов, набор битов должен передаваться перед набором, а различные элементы набора должны передаваться последовательно. ПРИМЕР 1 Конкретное значение вышеуказанного набора MemberType (Тип члена) будет передано как: 15 14 13 12 11 10 9 8 7 член = ‘02’H 6 5 4 3 2 1 0 закрытая последовательность .. закрытая последовательность .. закрытая последовательность (конец) член = ‘05’H .. резервная последовательность .. резервная последовательность член = ‘FF’H Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 299 – ПРИМЕР 2 Если тег заменить набором битов, кодировка будет: 15 14 13 12 11 10 9 8 7 6 0 0 1 0 0 1 0 0 0 0 5 4 3 2 1 0 0 0 0 0 0 0 .. закрытая последовательность .. .. резервная последовательность .. резервная последовательность 6.4.5 не определено Выравнивание Для любого типа может потребоваться добавить биты заполнения, чтобы выровнять следующее поле по 16- или 32-битной границе (или любой другой границе). С тем, чтобы выразить это, после типа используется квалификатор ALIGN (ВЫРОВНЯТЬ). Биты заполнения не определены (по умолчанию они равны 0). ПРИМЕР Следующее определяет массив символов, который выровнен по 32-битной границе, независимо от значения «count» («счет»). AlignedString::= ARRAY ALIGN 32 [count] OF CHARACTER8. 6.4.6 Нотация для специальных типов Некоторые структурированные типы имеют специальный указатель типа. 6.4.6.1 Нотация для строкового типа STRING# (СТОРКА) представляет собой ARRAY [] OF CHARACTER8 (МАССИВ ИЗ 8-БИТНЫХ СИМВОЛОВ), в котором конечным элементом должен быть символ ‘00’H, фактический размер строки выводится из количества значащих символов, хотя количество передаваемых символов может быть больше ПРИМЕР Текстовая строка типа STRING32 представлена массивом ARRAY [32 STOP=‘00’H] OF CHARACTER8. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1ый символ или ‘00’H 1 0 2ой символ или ‘00’H символы... последний символ или ‘00’H 6.4.6.2 6.4.6.2.1 32ой символ или ‘00’H Нотация для типа TIMEDATE48 Определение Структурированный тип, выражающий абсолютное время в секундах с момента 00:00:00, 1 января 1970 г. (формат Unix и ANSI-C) по всемирному координированному времени (UTC). ПРИМЕЧАНИЕ Этот тип используется для распределения фактического времени, маркировки событий, синхронизации. 6.4.6.2.2 Синтаксис TimeDate48::= RECORD { seconds ticks SIGNED32, UNSIGNED16 -- истекло с 1970 г., 1 января, 00:00 -- доли секунд (1 импульс = 1/65536с) } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 300 – 6.4.6.2.3 15 14 Кодирование 13 12 11 10 9 8 7 6 5 4 3 2 1 0 секунды (старшие биты) секунды (младшие биты) импульсы = 1/65536 с Время может быть представлено с точностью до 15,3 с (= 1/65536 с). Диапазон составляет 68 лет. Точность дробной части должна быть не менее 10 бит. Для неиспользуемых младших битов должно быть установлено значение ноль. ПРИМЕЧАНИЕ Переменная TimeDate48 будет зациклена на 2038 г., 19 января, 3:14:07 UTC. Это зацикливание следует учитывать при тестировании программного обеспечения. Нотация для типа TIME64 6.4.6.3 6.4.6.3.1 Определение Структурированный тип, выражающий абсолютное время (UTC) в секундах с 00:00, 1 января, 1900 г. Это время не компенсируется дополнительными секундами. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 секунды (старшие биты) секунды (младшие биты) импульсы = 1/65536 с щелчок = 0,232 с ПРИМЕЧАНИЕ 1 Это определение времени взято из Интернет протокола RFC1305, который определяет протокол синхронизации для распределенных систем тактовой синхронизации. Оно отличается от времени UNIX, которое основано на 1970 г. ПРИМЕЧАНИЕ 2 Переменная Time64 будет зациклена на 2036 г. Это зацикливание следует учитывать при тестировании программного обеспечения. Таким образом, это определение времени также можно рассматривать как определение времени, оставшегося до января 2036 г. 6.4.6.4 6.4.6.4.1 Нотация для типа boolean8 ASN.1 Определение Примитивный тип с двумя различающимися значениями: TRUE (ИСТИНА) и FALSE (ЛОЖЬ). ПРИМЕЧАНИЕ 1 Предсталяет собой «BooleanType» («Булев тип») по ASN.1. 6.4.6.4.2 Синтаксис Boolean8Type::= BOOLEAN8 6.4.6.4.3 Кодирование Булева переменная типа 8 должна быть закодирована 8 битами, при этом ‘00000000’B интерпретируется как FALSE (ЛОЖЬ), а любое другое значение - как TRUE (ИСТИНА). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 301 – 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 7 FALSE (ЛОЖЬ) TRUE (ИСТИНА) Прикладной уровень Упорядочение данных процесса 7.1 7.1.1 Типы упорядочения Функция упорядочения данных процесса (PDM) копирует переменные процесса из одного хранилища трафика в другое хранилище трафика: WTB PDM Экспо рт Импо рт Хранилище трафика шины поезда Хранилище трафика сети подвижного состава Сеть подвижного состава Рисунок 142 - Упорядочение данных процесса Определено два типа упорядочения: – Упорядочение экспорта – Упорядочение импорта 7.1.1.1 Упорядочение экспорта Упорядочение экспорта означает копирование переменных из одного или нескольких хранилищ трафика подвижной сети в порт-источник хранилища трафика проводной шины поезда. Записывается весь порт проводной шины поезда, поэтому неиспользуемое пространство порта должно быть заполнено значениями по умолчанию. Упорядочение экспорта может выполнять некоторую обработку переменных процесса. Упорядочение экспорта определяет длину экспортируемого кадра в зависимости от типа кадра. 7.1.1.2 Упорядочение импорта Упорядочение импорта означает копирования переменных из хранилища трафика проводной шины поезда в статически сконфигурированное хранилище трафика сети подвижного состава. Упорядочение импорта может выполнять некоторую обработку переменных процесса. 7.1.2 Режимы упорядочения Состав может использовать различные динамические режимы работы. В соответствии с этими режимами работы функция упорядочения данных процесса (PDM) предлагает режимы упорядочения. Каждый режим упорядочения может иметь различную конфигурацию. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 302 – 61375-2-1 © IEC:2012 ПРИМЕР Тяговый состав, как и локомотив, может быть ведущим транспортным средством тяги поезда, ведомым транспортным средством тяги поезда или вообще не поддерживать тяги. В каждом случае будут импортированы и экспортированы разные данные. Режим по умолчанию всегда должен присутствовать, если для функции упорядочения данных процесса (PDM) не используется специальный режим. Если режим работы состава изменяется, то можно изменить конфигурацию функцию упорядочения данных процесса (PDM) с тем, чтобы принять новый режим упорядочения. 7.1.3 Пути передачи данных в функции упорядочения данных процесса (PDM) Этот подраздел предназначен только для информационных целей и не является нормативным, поскольку каждый поставщик шлюза может реализовать его по-разному. Функция PDM упорядочивает данные процесса от источника к адресату. Адресатом всегда является хранилище трафика. Источником является хранилище трафика, буфер значений по умолчанию или буфер неопределенных значений. Хранилище трафика Буфер неопределенного значения Буфер значения по умолчанию Замена в зависимости от характеристик подвижного состава База данных характеристик подвижного состава Функция PDM Хранилище трафика Рисунок 143 - Пути передачи данных функции PDM Могут быть сконфигурированы следующие пути передачи данных: из хранилища трафика в хранилище трафика напрямую или через функцию упорядочения данных процесса (PDM). Это является основной задачей функции упорядочения данных процесса (PDM). Переменная процесса может быть обработана функцией до того, как она будет записана в целевое хранилище трафика. из буфера значений по умолчанию до хранилища трафика значения по умолчанию используются, когда значение должно быть записано в порт, но в любом случае переменная процесса, которая может передать это значение, отсутствует. Значения по умолчанию не предназначены для замены недопустимых или слишком старых (не новых) переменных процесса. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 303 – Переменная процесса, зависящая от функций состава, от хранилища трафика в хранилище трафика напрямую или через функцию упорядочения данных процесса (PDM). Переменные процесса можно комбинировать со статическими и динамическими функциями состава. Упорядочение будет выполняться только при наличии функции состава. В противном случае функция упорядочения данных процесса (PDM) заменяет переменную процесса на неопределенное значение или значение соответствующего типа данных, определяемое приложением по умолчанию. Неопределенное значение представлено контрольной переменной, для которой установлено значение 11b, или значением переменной, для которого установлены все значения «1». Что соответствует стандарту IEC 61375 для сети поездной связи. Для переменных процесса, зависящих от состава, следует рассмотреть три случая: Одна переменная с одной контрольной переменной: Функция PDM может заменить неопределенное значение, путем установки контрольной переменной на 11b. Несколько переменный с одной контрольной переменной: Если не все переменные поддерживаются, функция PDM может заменить неопределенные значения, установив для проверочной переменной значение 11b. Несколько переменный с одной контрольной переменной: Если не поддерживаются только некоторые переменные, функция PDM должна заменить значения по умолчанию, определенные приложением. Переменная процесса может быть обработана функцией до того, как она будет записана в целевое хранилище трафика. Если переменная процесса заменена неопределенным значением, ее можно игнорировать как аргумент функции. 7.1.4 Использование функции PDM Функция PDM активируется настраиваемым таймером или событием (например, получение данных проводной шины поезда). После активации функция PDM копирует все переменные, настроенные для активированного типа упорядочения. Процесс копирования включает в себя четыре этапа: a) Считываются все переменные, один набор данных за другим. b) Для каждой переменной с настроенным контролем новизны проверяется актуальность. Слишком старые переменные становятся недопустимыми (см. ниже). c) Затем все настроенные функции (см. 7.1.5 Функции упорядочения данных процесса (PDM)) применяются к переменным. d) Наконец, функция PDM копирует переменные, результаты функций и значения по умолчанию в порты адресата и хранилища трафика. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 304 – для всех наборов данных, из которых поступают переменные считывание всех переменных набора данных если (упорядочение импорта и поле типа кадра в порядке) или отсутствует упорядочение импорта то или все установленные переменные набора данных недопустимы для всех переменных набора данных если проверка новизны, данные слишком старые то или установленная переменная недопустима если упорядочение импорта и любое поле типа кадра не в порядке то или все установленные переменные хранилища трафика проводной шины поезда недопустимы для всех функций PDM выполнить функцию PDM для всех наборов данных, в которые поступают переменные запись всех переменных набора данных (переменные данных процесса, результаты функции, значения по умолчанию) Рисунок 144 - Использование функции PDM Переменная или результат функции (см. главу 7.1.5) становятся недопустимыми по следующему алгоритму: если переменная или результат функции включают контрольную переменную то или установить для контрольной переменной значение 00b установить для значения переменной все «0» Рисунок 145 - Недопустимая переменная PDM или результат функции Если переменная или результат функции включают контрольную переменную, только для контрольной переменной устанавливается значение 00b. Для значения переменной не устанавливаются все «0», поскольку переменная не может быть абсолютно недопустимой. Если переменная или результат функции не включают контрольную переменную, то для значения переменной будут установлены все «0». Что соответствует данному стандарту. ПРИМЕЧАНИЕ Поскольку перезапись значения переменной процесса со всеми «0» или «1» может выдать допустимое значение, контрольная переменная того же набора данных используется в качестве индикатора достоверности в том случае, когда это может являться проблемой. (см. 6.2.2.2.3). 7.1.5 7.1.5.1 Функции упорядочения данных процесса (PDM) Общие положения В дополнение к простому копированию переменных система PDM поддерживает обработку переменных процесса с помощью функций. Обработка функций поддерживается для всех типов упорядочения. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 305 – ПРИМЕР Предположим, приложению необходимо знать, все ли двери поезда закрыты. Поскольку поезд включать себя 1-20 составов с дверями, приложение должно быть способно обработать широкий спектр входных данных. Использование функции упорядочения данных процесса (PDM), которая считывает все состояния дверей и предоставляет одну переменную, сообщающую о том, что «все двери закрыты», значительно упрощает программирование приложений. Функции, предлагаемые системой PDM, обычно имеют форму y = f(x1, x2, ... xn); xi , i = 1 .. где n, входной аргумент, y - результат функции Может быть любое количество (больше нуля) аргументов и один результат. Аргументы функции могут поступать от разных портов и хранилищ трафика. Описание аргументов и результата содержится в типах PV_Name. Система PDM предлагает следующие стандартные функции обработки: логические функции: AND, AND_IGNORE_INVALID OR, OR_IGNORE_INVALID XOR, XOR_IGNORE_INVALID числовые функции: MIN, MIN_IGNORE_INVALID MAX, MAX_IGNORE_INVALID SUM, SUM_IGNORE_INVALID 7.1.5.2 Обработка функций Все аргументы функции проверяются на достоверность. Слишком старые переменные становятся недопустимыми уже на втором этапе процесса копирования. Аргументы могут включать контрольную переменную или нет. Оба варианта можно смешивать, если функция имеет более одного аргумента. Если аргумент недопустим или не определен, его можно игнорировать (функции XXX_IGNORE_INVALID). Если недопустимый или неопределенный аргумент не игнорируется, он устанавливает недопустимый результат функции. Обрабатываются только допустимые аргументы. Если все аргументы недопустимы или не определены, результат устанавливается как недопустимый. При необходимости тип аргументов преобразуется в тип, пригодный для обработки. Тип обработки является конфигурируемым. Если во время оценки функции возникает ошибка, результат становится недопустимым. После обработки всех аргументов вычисленный результат преобразуется в желаемый результат функции, описываемый типом PV_Name. Результат функции может включать или не включать контрольную переменную, независимо от аргументов. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 306 – для всех аргументов функции если переменная допустима то или привести тип аргументов к вычислительному типу если IGNORE_INVALID применить функцию к аргументу и вычислить результат функции то или игнорировать аргумент установлен недопустимый результат функции возврат результата функции если все переменные недопустимы то или установлен недопустимый результат функции возврат результата функции привести тип аргументов к типу результата если результат функции включает контрольную переменную то или установить для контрольной переменной значение 01b возврат результата функции Рисунок 146 - Использование функции PDM Допустимость переменной проверяется по следующему алгоритму: если переменная включает контрольною переменную то или если контрольная переменная = 10b или контрольная переменная = 01b если для значения переменной установлены все «0» или «1» то или то или переменная допустима переменная недопустима переменная недопустима переменная допустима Рисунок 147 - Проверка допустимости функции PDM 7.1.5.3 Логические функции: AND, OR и XOR Для этих функций аргументы имеют тип BOOLEAN, ANTIVALENT или тип BITSET. Если аргумент имеет тип BITSET, необходимо также указать позицию бита в наборе битов. Типы аргументов могут быть смешаны в пределах одного вызова функции. Значение результата этой функции имеет тип BOOLEAN или ANTIVALENT. Кроме того, можно указать, используется ли переменная напрямую или переменная инвертируется перед использованием. 7.1.5.4 Числовые функции: MIN, MAX, SUM Для этих функций аргументы имеют тип INTEGER, UNSIGNED, REAL и FRACTIONAL с максимальным размером 32 бита. INTEGER и UNSIGNED разных размеров могут быть смешаны в одном вызове функции. После обработки тип результата преобразуется (посредством приведения) в тип переменной адресата. Проверка диапазона не проводится, необходимо проявлять осторожность в отношении переполнения. 7.2 Обнаружение места неисправности линии проводной шины поезда Диагностический компьютер может контролировать биты повреждения линии проводной шины поезда в слове состояния узла шлюза. Если диагностический компьютер обнаруживает постоянное повреждение на линии, он может запросить обнаружение Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 307 – места неисправности линии (LFLD) у сетевого управления сетью поездной связи. Управление сетью поездной связи взаимодействует с управлением канальным уровнем проводной шины поезда для определения места неисправности. После завершения процесса обнаружения места неисправности (LFLD) диагностический компьютер может считать результат в сети поездной связи. Неисправность на линии, нарушающая правильное окончание линии, может вызвать отражение сигнала, что может повлиять на связь нескольких узлов на этой линии. Таким образом, процесс обнаружения места неисправности (LFLD) размыкает реле прерывания поврежденной линии на промежуточных узлах. В результате будут созданы завершенные сегменты проводной шины поезда, которые можно проверить. 7.2.1 Архитектура Агент сетевого управления (IEC 61375-2-1) Доступ к LFLD Диагностичес кий компьютер TCN RTP (IEC61375-2-1) Канальный уровень сети подвижного состава (IEC61375-3-x) Управление каналом Канальный уровень WTB (IEC61375-2-1) LFLD Сеть подвижного состава WTB LFLD = Обнаружение места неисправности линии Рисунок 148 - Архитектура LFLD Обнаружение места неисправности линии (LFLD) проводной шины поезда является функцией канального уровня проводной шины поезда, которая реализована в управлении каналом. Для управления каналом связи используется управление сетью поездной связи для связи с другими узлами проводной шины поезда во время процесса обнаружения места неисправности линии (LFLD). Управление сетью поездной связи предлагает новую службу обнаружения места неисправности линии (LFLD) в рамках услуг связи проводной шины поезда (IEC 61375-1, 8.4.3.6) и поддерживает подкоманды для диагностического компьютера и управления каналом связи проводной шины поезда. Диагностический компьютер может получить доступ к службе обнаружения места неисправности линии управления сетью поездной связи с помощью данных сообщения сети поездной связи, отправленных через многофункциональную шину поезда для: Запуска процесса обнаружения неисправности линии (LFLD) на конечном узле проводной шины поезда. Получения результатов обнаружения неисправности линии (LFLD) Отмены обнаружения неисправности линии (LFLD) Администратор канала проводной шины поезда получает доступ к службе обнаружения места неисправности линии управления сетью поездной связи с помощью данных сообщения сети поездной связи, отправленных через проводную шину поезда для: Запуска и остановки процесса обнаружения неисправности линии (LFLD) на другом конечном узле проводной шины поезда Запуска и остановка процесса обнаружения неисправности линии (LFLD) на промежуточных узлах проводной шины поезда Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 308 – 7.2.2 Обзор протокола Этап 1 Диагностический компьютер запрашивает обнаружение неисправности линии на конечном узле и делает его испытательным узлом (TN). Управление каналом испытательного узла проводной шины поезда запускает процесс обнаружения Испытательный узел Прерывание отражение отражение A B B Этап 2 Испытательный узел запрашивает следующий узел (= Узел сегментации (SN)) о размыкании переключателя линии. Если испытательный узел не регистрирует неисправности линии для кадров, полученных от узла сегментации в течение времени T2, считается, что этот сегмент линии работает правильно. Затем испытательный узел запрашивает узел снова замкнуть переключатель линии и продолжает работу с одним следующим узлом. Этот процесс продолжается до тех пор, пока испытательный узел не зарегистрирует отказ на линии для кадров, поступающих от узла сегментации. Испытательный узел Прерывание отражение отражение A B B Испытательный узел Прерывание отражение отражение A B B Испытательный узел Прерывание отражение отражение A B B Испытательный узел Прерывание отражение отражение A B B Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 309 – Этап 3 Теперь испытательный узел больше не получает сообщений от узла сегментации при отсутствии неисправности на линии. Это указывает на то, что в последнем проверенном сегменте должна присутствовать какая-либо неисправность на линии. Испытательный узел Прерывание отражение отражение A B B 7.2.3 Последовательность LFLD На Рисунке 149 показана последовательность процесса обнаружения неисправности линии. Диагностичес кий компьютер WTB Испыта. конечные узлы WTB промежут. узлы сегментации WTB Промежут. узлы сегментации WTB Противоп. конечный узел Диагностиче ский компьютер запрос на запуск LFLD подтвержд ение запуска LFLD запрос на запуск LFLD (противоположн. узла) подтверждение запуска LFLD (противоположн. узла) Диагностика сегмента линии запрос на запуск LFLD отриц. подтвержд ение запуска LFLD (занят) запрос на останов LFLD (узла сегментации) подтверждение останова LFLD (узла сегментации) подтверждение запуска LFLD (узла сегментации) Диагностика сегмента линии запрос на запуск LFLD (узла сегментации) Диагностика сегмента линии запрос результат а LFLD отриц. подтвержде ние результата LFLD (занят) подтверждение запуска LFLD (узла сегментации) Диагностика сегмента линии запрос на запуск LFLD (узла сегментации) 11 12 1 10 2 9 3 8 4 7 6 5 запрос на останов LFLD (узла сегментации) 11 12 1 10 2 9 3 8 4 7 65 подтверждение останова LFLD (узла сегментации) Вычислить окончате льный результа т запрос на останов LFLD (противоположн. узла) подтверждение останова LFLD (противоположн. узла) подтвержде ние результат а LFLD (результат) подтвержде ние результата LFLD Рисунок 149 - Последовательность LFLD Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 310 – 61375-2-1 IEC:2012 Диагностический компьютер запускает процесс обнаружения неисправности линии (LFLD) с помощью сообщения управления сетью поездной связи. Испытательный узел (TN) информирует противоположный конечный узел (OE) посредством сообщения управления сетью поездной связи о том, что процесс обнаружения неисправности линии (LFLD) запущен. Это предотвращает запуск процесса LFLD противоположным конечным узлом. Когда испытательный узел получает ответное сообщение от противоположного конечного узла, он выбирает первый узел сегментации (SN). Испытательный узел запрашивает узел сегментации выполнить сегментацию шины (разомкнуть реле прерывания) и запустить диагностику линии. Когда испытательный узел получает ответное сообщение от узла сегментации, он контролирует сегмент от испытательного узла до узла сегментации, если он может получить кадр ответа с данными процесса (PD) от узла сегментации или предыдущего узла, кроме одного узла, без повреждения линии. Узел сегментации контролирует сегмент от узла сегментации до противоположного конечного узла, чтобы получить кадр ответа с данными процесса от противоположного конечного узла без помех. По истечении максимально возможного отдельного периода (128 * 25 мс) испытательный узел запрашивает сегментации прекратить сегментации шины (замкнуть реле прерывания) и сообщить, может ли узел сегментации принять кадр от противоположного конечного узла без помех. Испытательный узел выбирает следующий узел сегментации и повторяет этапы с 4 по 7 до тех пор, пока не будет обнаружено место неисправности или не будет достигнут противоположный конечный узел. После достижения противоположного конечного узла, испытательный узел информирует противоположный конечный узел о завершении процесса LFLD. Диагностический компьютер может получить результат обнаружения неисправности линии (LFLD) от испытательного узла. Если процесс обнаружения неисправности линии (LFLD) все еще выполняется, испытательный узел отклоняет запрос с сообщением об ошибке. Диагностический компьютер должен опрашивать испытательный узел до тех пор, пока не будет получен результат. Если диагностический компьютер запрашивает обнаружение неисправности линии (LFLD) в противоположном конечном узле во время процесса обнаружения неисправности линии (LFLD), противоположный конечный узел отклоняет запрос с сообщением об ошибке. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 7.2.4 – 311 – Автомат состояния конечного узла (испытательный узел) Ответ: Не доступно результатов Останов TNM дляLFLD противоп. узла Сброс LFLD Запуск LFLD TNM промежуточного узла Ответ: Отсутствие LFLD конечного узла Сброс LFLD Запуск LFLD TNM конечного узла Нач. испытательный узел Запуск TNM для противоп. и конечного узла Ответ: Идет процесс LFLD на противоположном конечном узле Запуск LFLD TNM LFLD в реж име ожи дан ия Запрос результата TNM LFLD Открытие эксплуатаци и запрос результата LFLD TNM Ответ: результат LFLD сброс LFLD Сброс LFLD Открытие эксплуатаци и Открытие эксплуатаци и Ответ: диагностика занята Идет процесс LFLD противоположног о узла запрос результата LFLD TNM запрос результата LFLD TNM Процес с LFLD неисправность обнаружена || достигнут противоположный конечный узел Ответ: Идет процесс LFLD на противоположном конечном узле Процес с LFLD заверш ен Рисунок 150 - Автомат состояния конечного узла 7.2.5 Автомат состояния промежуточного узла (узел сегментации) Реализация узла сегментации не имеет состояния. 7.2.6 Выбор поврежденной линии Поврежденная линия A или B зависит от ориентации каждого узла. Испытательный узел получает информацию о местной поврежденной линию. Испытательный узел, в зависимости от собственной ориентации, выводит поврежденную линию управляющего устройства проводной шины поезда на управляющее устройство проводной шины поезда и использует ее как нормализованную линию с прерыванием связи. Когда испытательный узел запускает и останавливает узел сегментации, испытательный узел запрашивает открытие и закрытие нормализованной линии с прерыванием связи. Узел сегментации, исходя из информации нормализованной линии с прерыванием связи и ее ориентации, выводит на управляющее устройство местное линейное реле, которое подлежит размыканию или замыканию. 7.2.7 Обнаружение места Испытательный узел инициализирует эту пару узлов для испытательного узла и непосредственного соседа испытательного узла. Процесс обнаружения неисправности линии (LFLD) переходит от узла к узлу. ПРИМЕР Процесс обнаружения неисправности линии (LFLD) достиг узла сегментации (SN) 63, и неисправность возникла между узлами 63 и 1. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 312 – TN 61 SN 62 63 1 2 3 Рисунок 151 - Процесс обнаружения неисправности линии (LFLD), узел сегментации на узле 63 На Рисунке 151 узел сегментации 63 недоступен для испытательного узла (TN), поскольку реле подключения замкнуто на дальней стороне. Испытательный узел может видеть только положительный ответ от предыдущего узла. Таким образом, испытательный узел не может различить неисправность между узлами 62 и 63 или между узлами 63 и 1. Таким образом, узел сегментации также контролирует сегмент проводной шины поезда на другой стороне реле прерывания, в этом примере от узла 63 до узла 3. Узел сегментации сообщает о качестве сегмента испытательному узлу, когда испытательный узел запрашивает о замыкании реле прерывания. В этом примере узел 63 определяет, что сегмент неисправен, и испытательный узел может предположить, что сегмент от узла 61 до узла 63 исправен, даже если испытательный узел не может получить ответ от узла 63. Таким образом, испытательный узел (TN) продолжает взаимодействие со следующим узлом сегментации (SN) (узел 1). TN 61 SN 62 63 1 2 3 Рисунок 152 - Процесс обнаружения неисправности линии (LFLD), узел сегментации на узле 1 Узел сегментации (теперь узел 1) отслеживает сегмент от узла 1 до узла 3, определяет его как исправный и сообщает об этом испытательному узлу. Испытательный узел может определить, что неисправность должна быть непосредственно перед узлом сегментации, т.е. между узлами 63 и 1. Когда испытательный узел получает отчет от узла сегментации, он решает: если узел сегментации сообщает, что на противоположном конечном узле отсутствуют помехи, остановить процесс обнаружения неисправности линии (LFLD), и пара узлов состоит из узла сегментации и узла, расположенного непосредственно перед узлом сегментации. если испытательный узел получает информацию о том, что в узле сегментации или узле, расположенном непосредственно перед ним, отсутствуют помехи, установить пару узлов для полученного узла и следующего узла. Это решение принимается после каждой остановки узла сегментации. Когда испытательный узел останавливает диагностику или достигает противоположного конечного узла, он должен проверить, должен ли он перейти к следующему случаю: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 313 – TN 61 SN 62 63 1 2 3 Рисунок 153 - Процесс обнаружения неисправности линии (LFLD), узел сегментации на узле 1, присоединенном в направлении 1 Испытательный узел не может достигнуть ни узла 63, ни узла 1, а узел сегментации не может достигнуть узла 3. Но испытательный узел может определить, что неисправность должна быть между узлами 63 и 1, поскольку в противном случае испытательный узел должен был определить сегмент от узла 61 до узла 1 как исправный. Испытательный узел решает: если парой узлов являются узлы (63, 1), а испытательный узел находится по адресу нижнего узла и реле управляющего устройства проводной шины поезда подключено в направлении 2, то парой узлов необходимо выбрать узлы (1, 2) если парой узлов являются узлы (1, 2), а испытательный узел находится по адресу верхнего узла и реле управляющего устройства проводной шины поезда подключено в направлении 1, то парой узлов необходимо выбрать узлы (63, 1) Конечным результатом процесса обнаружения неисправности линии (LFLD) является пара узлов, которые ограничивают место неисправности. Результат сохраняется в системе управления поездной сетью для извлечения диагностическим компьютером. 8 Управление поездной сетью 8.1 8.1.1 Общие положения Содержание данного раздела Управление поездной сетью определяет ряд услуг, оказывающих помощь при вводе в эксплуатацию, тестировании, эксплуатации и обслуживании сеть поездной связи, например: a) идентификация и управление станицей; b) управление канальными уровнями шины поезда и сети подвижного состава; c) распределение маршрутизации и топографии; d) удаленное считывание и принудительное присвоение переменных; e) загрузка и выгрузка. Все услуги могут быть запрошены удаленно посредством процесса администратора. Эти услуги выполняются каждой станцией через процесс агента. В этом разделе указываются местные управляемые объекты и способ взаимодействия агента с ними. В этом разделе определены административные сообщения, которыми обмениваются администратор и агент с целью управления сетью. Кроме того, в этом разделе указано, как определяемые пользователем службы могут быть связаны с агентом. ПРИМЕЧАНИЕ 1 Управление поездной сетью не определяет сообщения для конкретных приложений (такие как диагностика поезда в соответствии со стандартом UIC 557 или идентификация состава в соответствии со стандартом UIC 556). Однако пользовательские приложения могут использовать службы управления во время плановой эксплуатации. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 314 – 61375-2-1 IEC:2012 ПРИМЕЧАНИЕ 2 Управление поездной сетью не рассматривает службы управления, непосредственно связанные с приложением. В частности, описание виртуального устройства, которое относится к фактической роли оборудования (например, кондиционирование воздуха), не является частью этого раздела. Структура данного раздела 8.1.2 Данный раздел имеет следующую структуру: Подраздел 8.1 Общие положения Подраздел 8.2 Администратор, агенты и интерфейсы Подраздел 8.3 Управляемые объекты Для каждого объекта должно быть указано следующее: описание объекта доступ услуги, предлагаемые данным объектом. Подраздел 8.4 Услуги и административные сообщения Для каждой услуги должно быть указано следующее: описание; Сообщение вызова и параметры; Ответное сообщение и параметры. Подраздел 8.5 Процедуры интерфейса Для каждого интерфейса определены процедуры доступа и местного управления агентом. 8.2 8.2.1 Администратор, агенты и интерфейсы Администратор и агент Услуги управления сетью предоставляются на каждой станции агентом. Агент должен быть идентифицирован по идентификатору станции (Station_Id), на которой он находится. Услуги управления сетью должны быть запрошены администратором. 8.2.2 Протокол административных сообщений В целях управления сетью администратор и агенты взаимодействуют по сети посредством обмена сообщениями управления, используя службы сообщений сети поездной связи, как показано на Рисунке 154. Администратор должен действовать в качестве вызывающего абонента, а агент в качестве ответчика. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 © IEC:2012 Интерфейс администратора Пользо ватель – 315 – Пользователь MGI Администра тор Пользователь Интерфейс AGI агента AGI Агент Агент (то же устройство, что и администратор) интерфейс объекта (AVI+AMI+ASI) Вызов управляемые объекты Ответ MIB Вызов Ответ передача сообщения передача сообщения Сеть Административные сообщения Рисунок 154 - Административные сообщения Администратор запрашивает доступ к удаленному объекту в два этапа: a) Администратор посылает административное сообщение вызова; b) Агент декодирует сообщение, получает доступ к реальному объекту и отправляет обратно административное ответное сообщение с результатом обслуживания. Доступ к агенту должен быть получен как через системный адрес, так и через пользовательский адрес, поскольку идентификатор функции Function_Id = 253. Доступ к администратору должен быть получен как через системный адрес, так и через пользовательский адрес, поскольку идентификатор функции Function_Id = 254. Формат административных сообщений должен быть таким, как определено в следующих подразделах. Интерфейсы 8.2.3 8.2.3.1 Интерфейс объекта Объекты связи взаимодействуют с сетевой связью, а объекты, не являющиеся объектами связи, взаимодействуют с другими свойствами станции. ПРИМЕР 1 Конфигурация администратора шины является объектом связи. ПРИМЕР 2 Области памяти или домены, планировщик, часы, конфигурация станции и дескрипторы не являются объектами связи. Агент должен осуществлять доступ к объектам связи через интерфейсы, определенные для общего доступа в настоящем стандарте, и, в частности, через: a) AVI (интерфейс переменных процесса) для переменных; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 316 – b) AMI (интерфейс прикладных сообщений) для сообщений; c) ASI (интерфейс прикладного контроля) для объектов, недоступных для пользовательских процессов. Интерфейс прикладного контроля (ASI) обеспечивает доступ к объектам, расположенным на разных уровнях связи. Агент получает доступ к этим объектам через интерфейс управления уровнем того уровня, на котором они находятся (рис. 155). Определение этого интерфейса включено в разделы, которые определяют соответствующий уровень: Раздел 6 (Протокол реального времени), IEC 61375-3-1 (Многофункциональная шина поезда) и этот документ (Проводная шина поезда). ПРИМЕЧАНИЕ Субъект, который эффективно осуществляет доступ к объектам на каждом уровне, называется субъектом уровневого управления или LME. Агент также должен иметь возможность доступа к объектам, не являющимся объектами связи. Соответствующий интерфейс не указан. Административные сообщения Верх AGI Пользовательские процессы (задачи) домены памяти домены ASI памяти Агент Верх Верх х AMI AVI Переменные Сеть подвижного состава Канальный уровень LME LME Сообщения LME WTB Канальный LME уровень часы Субъекты уровневого управления WTB Сеть подвижного состава = управляемые объекты Рисунок 155 - Интерфейс агента на станции (шлюзе) 8.2.3.2 Интерфейс администратора Администратор должен предлагать набор процедур для доступа к удаленным объектам, которые формируют интерфейс администратора или MGI (см. Рисунок 154). Каждой услуге интерфейса администратора (MGI) должно соответствовать административное сообщение вызова, отправленное администратором, на которое агент должен отправить административное ответное сообщение. Процедуры интерфейса администратора (MGI) не определены отдельно, но определены две общие процедуры, которые предоставляют все услуги. Формат административного сообщения также должен использоваться для параметров процедуры службы управления. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.2.3.3 – 317 – Интерфейс агента (AGI) Некоторым управляемым объектам требуется доступ к агенту. Это относится к задачам, которым необходимо запросить состояние агента для синхронизации или для сообщения об изменениях состояния. С этой целью агент должен предоставить интерфейс, называемый интерфейсом агента (AGI), который позволяет местным пользователям напрямую считывать и изменять некоторые управляемые объекты, как указано в 8.5.2. ПРИМЕЧАНИЕ Сетевые сообщения, связанных с интерфейсом агента, отсутствуют. Управляемые объекты 8.3 Атрибутыобъектов 8.3.1 Каждый управляемый объект должен включать в себя четыре атрибута: a) идентификатор объекта, текстовая строка длиной до 31 символа, идентифицирующая объект; b) статус (только для чтения), указывающий на состояние объекта; c) элемент управления (только для записи), который воздействует на объект; d) часть параметра (для чтения или записи), которая содержит изменяемые части объекта, если они еще не содержатся в состоянии или элементе управления. Атрибуты объекта должны обрабатываться службами, определенными в этом разделе, или службами, определяемыми пользователем. Каждая служба, определенная для объекта, должна быть описана текстовой информацией, называемой дескриптором службы. Текстовая информация для стандартных служб может содержать ссылку на этот стандарт. Текстовая информация для служб, определяемых пользователей, не указывается. 8.3.2 8.3.2.1 Объекты станции Объект Station_Status (Состояние станции) Каждая станция должна реализовать объект Station_Status (состояние станции), указывающий общие характеристики станции и некоторые динамические параметры. Когда к станции подключена только одна сеть подвижного состава и не одной шины поезда, объект Station_Status (Состояние станции) должен быть копией Device_Status (Состояние устройства) сети подвижного состава. В противном случае состояние различных уровней канала должен быть объединено оператором OR (ИЛИ) для формирования Station_Status (Состояния станции). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 318 – Station_Status (Состояние станции) должно иметь следующий формат, как показано на Рисунке 156: Station_Status::= { station_capabilities { sp ba RECORD BITSET4 -- основные возможности станции -- специальное устройство -- Администратор многофункциональной шина поезда -- шлюз узла шины поезда -- возможности сообщений (0), (1), gw (2), md (3) }, class_specific common_flags { (0), lat WORD4, BITSET8 -- всегда 0 -- не используется, = 0 неисправный канало Некоторая неисправность системы в контролируемом процессе (например, потеря мощности) Некоторая неисправность устройства: неправильная работа устройства (например, ошибка в контрольной сумме) Некоторая неисправность связи: устанавливается, когда срабатывает контроль времени приемника любого порта в любом хранилище трафика этого устройства, сбрасывается, когда все настроенные порты работают нормально. lnd ssd (1), (2), --- sdd (3), -- scd (4), -- frc (5), -- snr (6), -- ser (7) -- Принудительно заданная станция: порт данного устройства задан принудительно Станция не готова: т.е. Станция не инициализирована Станция зарезервирована Администратором. } } 0 1 2 3 sp ba gw md station_capabilities (возможности станции) 4 5 6 7 8 9 10 11 12 13 14 15 lat lnd ssd Sdd scd frc snr ser class_specific (характерно для класса) Common_flags (Общие флаги) Рисунок 156 - Состояние станции 8.3.2.2 Объект Station_Control (Управление станцией) Каждая станция должна реализовать объект Station_Control (Управление станцией) с двумя связанными службами: a) запуск станции и назначение параметров конфигурации, таких как имя станции; b) перезапуск станции, т.е. остановка всех задач, очистка всех таблиц, закрыть всех сеансов связи и перезапуск только мессенджера и агента. Если только должны быть запущены или остановлены только прикладные задачи, объект задачи должен разрешать перезапуск части системы. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.3.2.3 – 319 – Объект Station Inventory (Инвентарный список станции) Каждая станция должна реализовать доступный только для чтения объект инвентаризации, описывающий статические характеристики станции, включающий a) идентификацию: изготовитель, серийный номер, Идентификатор станции и имя; b) возможности станции: версия ПО, поддерживаемые службы, список канальных уровней. Список уровней связи представлен Link_Set (набором каналов), 16-битным набором битов, имеющим по одному биту для каждого канального уровня. С каждым канальным уровнем связано хранилище трафика. Link_Set (Набор каналов) определяется следующим образом: Link_Set::= { link_layer15 link_layer14 link_layer13 link_layer12 link_layer11 link_layer10 link_layer9 link_layer8 link_layer7 link_layer6 link_layer5 link_layer4 link_layer3 link_layer2 link_layer1 link_layer0 } 8.3.2.4 BITSET16 (15), (14), (13), (12), (11), (10), (9), (8), (7), (6), (5), (4), (3), (2), (1), (0) -- первый передаваемый бит Объект Station Reservation (Резервирование станции) Каждая Станция должна реализовать объект резервирования, позволяющий администратору зарезервировать эту станцию для ее исключительного использования. Объект резервирования должен представлять собой семафор с тайм-аутом, который обеспечивает эксклюзивный доступ к изменяемым объектам. Состояние данного семафора должно отражаться в бите «ser» в поле Station_Status (Состояние станции) («1» = зарезервировано, «0» = не зарезервировано). Службы на объекте резервирования представляют собой «reserve» («зарезервировать») и «release» («освободить»). Администратор должен зарезервировать станцию, прежде чем ему будет разрешено изменять управляемые объекты. Администратор, намеревающийся зарезервировать станцию, должен отправить агенту запрос на резервирование. Агент, который принимает резервирование, должен установить объект резервирования и идентифицировать администратора. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 320 – 61375-2-1 IEC:2012 Владелец объекта резервирования идентифицируется по 24-битному адресу вызывающего абонента, полученному агентом. Кроме того, вызов резервирования предоставляет 32-битное слово для более точной идентификации администратора (или лица, которое управляет сетью) для конкретных приложений. Если администратор резервирует несколько станций, он должен резервировать станции в порядке возрастания адреса приложения, чтобы предотвратить взаимные блокировки с другим администратором. Агент должен отклонять любые изменяющие сервисные вызовы, если они не зарезервированы (бит «ser» очищен) или если запрос выдан другим незарегистрированным администратором. Тайм-аут гарантирует, что станция не останется в зависшем состоянии, если администратор будет отключен, не освободив станцию. Тайм-аут семафора должен сбрасываться каждый раз при получении агентом административного сообщения вызова от своего зарегистрированного администратора. Семафор резервирования очищается: a) при открытии эксплуатации шины поезда; b) при сбросе станции; c) сообщением резервирования «override» («переопределить»). ПРИМЕЧАНИЕ 1 Неизменяющие службы (чтение) не подлежат резервированию. Они могут быть вызваны любым администратором или любой другой функцией. Только зарегистрированный администратор может выдавать запросы на изменение (запись). ПРИМЕЧАНИЕ 2 Открытие эксплуатации может повлиять на идентификацию как администратора, так и агента. ПРИМЕЧАНИЕ 3 Сообщение «override» («переопределить») представляет собой исключительный метод резервирования станции, которая по какой-то причине остается в зарезервированном состоянии. Следует использовать с осторожностью. ПРИМЕЧАНИЕ 4 Резервирование не обеспечивает безопасности доступа. Может защитить только от определенных неудач. Если необходим безопасный доступ, рекомендуется использовать пароли на уровне рабочей станции. Объекты каналов проводной шины поезда 8.3.3 8.3.3.1 Объект WTB Status (Состояние проводной шины поезда) Каждый узел, подключенный к поездной шине, должен реализовать доступный только для чтения объект WTB_Status (Состояние проводной шины поезда), который указан в стандарте («Проводная шина поезда»). Объект WTB_Status (Состояние проводной шины поезда) идентифицирует версию аппаратного и программного обеспечения, определяет динамические и статические параметры, раскрывает ошибки и статистику канального уровня проводной шины поезда и содержит слово состояния узла, соответствующее этому соединению проводной шины поезда Агент получает доступ к этому объекту через контрольный интерфейс канального уровня проводной шины поезда, ls_t_xxx. Объект WTB_Status (Состояние проводной шины поезда) включает предоставленные местным приложением и определенные в этом стандарте: следующие структуры данных, a) Node_Descriptor (Дескриптор узла), структура, определяющая кадр данных процесса, (см. 5.5.2.1); b) Node_Report (Отчет узла), BITSET8 (8-БИТНЫЙ НАБОР ДАННЫХ), оповещающий о повреждении, (см. 5.5.2.2); c) User_Report (Отчет пользователя), WORD8 (8-БИТНОЕ СЛОВО), предоставляемое приложением (см. 5.5.2.3); d) Node_Key (Ключ узла), RECORD (ЗАПИСЬ), содержащая тип узла и версию узла (см. 5.5.2.4); e) Ls_T_State, ENUM8 (8-БИТНЫЙ ПЕРЕЧИСЛИМЫЙ ТИП), который указывает состояние, в котором находится узел (см. 5.6.4.2.2); f) Node_Strength (Мощность узла), ENUM8 (8-БИТНЫЙ ПЕРЕЧИСЛИМЫЙ ТИП), выражающий мощность узла (см. 5.6.4.16.3). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.3.3.2 – 321 – Объект WTB Topography (Топография проводной шины поезда) Каждый узел, подключенный к поездной шине, должен реализовать доступный только для чтения объект WTB_Topography (Топография проводной шины поезда), который указан в стандарте («Проводная шина поезда»). Агент получает доступ к этому объекту через интерфейс управления каналом, ls_t_xxx. ПРИМЕЧАНИЕ 1 Топография проводной шины поезда описывает текущую конфигурацию шины поезда, перечисляет существующие узлы и их дескрипторы, а также сообщает о состоянии управляющего устройства. ПРИМЕЧАНИЕ 2 Доступ к объекту «Topography» («Топография») должен осуществляться всеми приложениями, отправляющими сообщения по шине поезда, поскольку топография обеспечивает согласованность адресации при изменении подвижного состава, как описано в 6.3. ПРИМЕЧАНИЕ 3 Топографию можно получить с любой станции. Однако текущую версию топографии может предоставить только станция, подключенная к шине поезда. ПРИМЕЧАНИЕ 4 Объект топографии состоит из обязательной части и предоставленных пользователем данных открытия эксплуатации. 8.3.4 8.3.4.1 Объекты переменных Объект Port Configuration (Конфигурация порта) Каждая станция с возможностью передачи данных процесса должна реализовать доступный только для чтения объект Ports_Configuration (Конфигурация портов), который указывает количество портов и их адреса. Порт может иметь фиксированную длину (сеть подвижного состава) или переменную длину (проводная шина поезда). Длина порта определяется кодом функции (F_code): F_Code::= { PD16 PD32 PD64 PD128 PD256 PD512 PD1024 PDW } ENUM4 (0), (1), (2), (3), (4), (5), (6), (7) --------- битный порт 1632- битный порт 64- битный порт 128-битный порт 256-битный порт 512-битный порт 1024-битный порт порт с переменным размером (проводная шина поезда) Порт определяется на шине своим 12-битным адресом порта. Для проводной шины поезда используются только младшие 6 бит. Код функции (F_code) и адрес порта объединяются в 16битную структуру, называемую FcodeAdr: FcodeAdr::= { f_code address } RECORD F_Code, UNSIGNED12 -- код функции (F_code), определяющий размер порта -- логический адрес Каждый порт характеризуется следующими атрибутами: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 322 – Port_Object::= RECORD { f_code port_address { src [0] snk [1] twc [2] frc [3] } port_size F_Code UNSIGNED12 -- код функции (F_code)порта -- адрес порта port_config BITSET4 -- порт включен как публикатор (источник) -- порт включен как абонент (приемник) -- порт, передающий кадры с контрольными суммами -- порт с принудительно присвоенным значением UNSIGNED8 -- максимальный размер порта в октетах, только для порта с переменным размером (порт проводной шины поезда) } 8.3.4.2 8.3.4.2.1 Объект Variables (Переменные) Объект Каждая станция с возможностью передачи данных процесса должна реализовать объект Variables (Переменные), указывающий значение, контрольную переменную и новизну переменной. ПРИМЕЧАНИЕ Отдельный период обновления порта контролируется объектом конфигурацией шины в сети подвижного состава или средством управления доступом к среде узла в шине поезда. Связь между портами, переменными и адресами шины является проблемой приложения. 8.3.4.2.2 Доступ Как и любой другой прикладной процесс, агент получает доступ к переменным через интерфейс прикладного уровня для переменных (AVI). Этот интерфейс позволяет считывать и принудительно изменять переменные в хранилище трафика либо по отдельности, либо по кластерам. 8.3.4.2.3 Службы Все удаленные службы для переменных выполняются в кластерах (несколько переменных), доступ к отдельным переменным является особым случаем. Следующие службы получают удаленный доступ к переменным: a) read (чтение): получение значения переменной, ее контрольной переменной и новизны; b) force (принудительное присвоение): принудительное присвоение переменной определенного значения Данное значение не может быть перезаписано приложением (источник) или шиной (приемник), пока переменная не будет отменена. Другие переменные того же набора данных могут быть присвоены принудительно или свободно: поскольку принудительная переменная не может быть перезаписана ее поставщиком, агент должен запросить у интерфейса агента (AGI) разрешение на ее изменение; если переменная находится в порту-источнике, то шина будет передавать ее значение всем приемникам, начиная со следующего периода; если переменная находится в порту-приемнике, принудительное значение будет видимым только для ее собственной станции. Запись шины в эту переменную запрещается, пока переменная принудительно используется, но местная новизна по-прежнему контролируется шиной; если какая-либо переменная на станции была присвоена принудительно, агент устанавливает бит «frc» в своем Station_Status (состоянии станции) и в Device_Status (состоянии устройства) сети подвижного состава, подключенной к принудительному хранилищу трафика; Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 323 – c) unforce (свободная): освобождает принудительную переменную, чтобы приложение могло снова изменить ее значение; d) unforce_all (освободить все): освобождает все переменные в хранилище трафика; e) read_bindings (считывание привязки): указывает, к какому порту привязана локальная переменная; f) write_bindings (запись привязки): привязывает локальную переменную к порту. ПРИМЕЧАНИЕ 1 Пользовательский процесс может получить доступ к переменной посредством запроса у своего местного агента выполнения read_variables (переменных чтения) или force_variables (принудительных переменных) в одном из своих собственных хранилищ трафика. Это, однако, занимает гораздо больше времени, чем прямой доступ. ПРИМЕЧАНИЕ 2 Приложение потребителя, которому необходимо отличать принудительную переменную от добровольной, может установить контрольную переменную в качестве принудительной переменной равной ‘10’B. ПРИМЕЧАНИЕ 3 Unforce_all (освободить все) следует вызывать один раз для каждого хранилища трафика, пока бит FRC в Station_Status (Состояние станции) не будет сброшен. 8.3.4.3 Port_Attach (Присоединение порта) Каждое устройство многофункциональной шина поезда класса 2 должно реализовывать объект Port_Attach (Присоединение порта), который определяет упорядочение между портами и точками ввода/вывода. Этот объект может быть записан только удаленно. Объекты мессенджера 8.3.5 8.3.5.1 Messenger status (Состояние мессенджера) Каждая станция, предоставляющая службу сообщений, должна реализовать доступный только для чтения объект Messenger status (Состояние мессенджера), который сообщает о версии программного обеспечения, конфигурации и статистике использования двух протоколов: a) протокола одноадресной передачи, и b) (дополнительного) протокола многоадресной передачи. Агент обращается к этому объекту через интерфейс прикладного контроля (ASI) мессенджера. 8.3.5.2 Messenger control (Управление мессенджером) Каждая станция, предоставляющая службу сообщений, должна реализовать объект Messenger control (Управления мессенджером), который позволяет удаленно сконфигурировать параметры передачи сообщений. 8.3.5.3 Объекты каталога Каждая станция, предоставляющая службу сообщений, должна реализовать Function_Directory (Каталог функций), который указывает для каждой функции, какая станция ее выполняет. Каждая станция с возможностью обмена сообщениями, но не использующая простую маршрутизацию, должна реализовать Station_Directory (Каталог станции), который преобразовывает Station_Identifier (идентификатор станции) для следующей станции и ее физический адрес (Bus_Id (Идентификатор шины) и Device_Address (Адрес устройства)). Каждая конечная станция, поддерживающая протокол многоадресной передачи, и каждая станциямаршрутизатор должны реализовать объект Group_Directory (Каталог группы), который указывает станции, к какой группе она принадлежит. Каждый узел шины поезда фиксированной конфигурации с возможностью передачи сообщений, но не использующий простую маршрутизацию, должен реализовать Node_Directory (Каталог узла), который указывает, какой адрес устройства соответствует данному адресу узла. Для каждого каталога должно существовать две службы: a) read_xxx_directory, которая считывает каталог полностью; b) write_xxx_directory, которая записывает каталог полностью (с предварительной очисткой или без нее). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 324 – 61375-2-1 IEC:2012 ПРИМЕЧАНИЕ 1 Station_Directory (Каталог станции) может быть заменен простой маршрутизацией на конечных станциях, и в этом случае объект Station_Directory (Каталог станций) не предоставляется. ПРИМЕЧАНИЕ 2 Агент получает доступ к каталогам через интерфейс прикладных сообщений (AMI), как и в любом другом приложении. Объекты домена 8.3.6 8.3.6.1 Объекты Каждая станция с возможностью загрузки или выгрузки областей памяти должна реализовать объект Domains (Домены). Количество доменов на станцию не указано. По технологическим причинам домен должен полностью содержаться в одном и том же типе памяти. В особых случаях администратор может получить доступ к областям физической памяти домена. ПРИМЕЧАНИЕ 1 Домены являются областями памяти, содержащими код или данные. Домены могут быть расположены в памяти различной технологии, RAM, EEPROM или Flash-EPROM. ПРИМЕЧАНИЕ 2 Агент получает доступ к доменам с помощью процедур, характерных для реализации, которые обеспечивают считывание/запись областей памяти с использованием различных технологий, возможно, защищенных правами доступа или управлением памятью. ПРИМЕЧАНИЕ 3 Доступ к доменам требует точного знания конфигурации станции. 8.3.6.2 Службы Службы объектов домена должны включать: a) загрузку установки (подготовительную загрузки, проверку, загрузку); b) сегмент загрузки; c) считывание памяти; d) запись памяти. ПРИМЕЧАНИЕ 1 Загрузка домена может перезаписать существующие области или даже программное обеспечение связи и самого агента. ПРИМЕЧАНИЕ 2 Перед загрузкой домена администратору безопаснее сначала выполнить вызов «reset_station». В этом случае администратор должен еще раз зарезервировать станцию, чтобы загрузить ее. 8.3.7 8.3.7.1 Объекты задач Объекты Каждая станция, способная управлять пользовательскими задачами, должна реализовать объект Task (Задачи) только для записи. Количество задач на станцию не указано. Задачи рассматриваются как единое целое в целях управления. Объект управления задачами управляет выполнением всех задач. 8.3.7.2 Доступ Предполагается, что агент получает доступ к планировщику для запуска и остановки задач. Доступ к задачам зависит от реализации. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.3.7.3 – 325 – Службы Указаны три службы задач: a) start (запуск), которая запускает все задачи; b) stop (останов), которая останавливает выполнение всех задач; c) tasks_list (список задач), который считывает список задач, установленных на станции, и их состояние. Перед остановкой задачи агент должен получить разрешение задачи через интерфейс агента (AGI) (см. 8.2.3.3), за исключением случаев, когда указан доступ «override» («переопределить»). Объект Clock (Часы) 8.3.8 8.3.8.1 Объекты Каждая станция с удаленным доступом к часам должна реализовать объект Clock (Часы). Точность часов не регламентируется. ПРИМЕЧАНИЕ 1 Установка или считывание часов с помощью сообщения административного сообщения может привести к непредсказуемым задержкам. В частности, нельзя указать верхний предел доставки сообщения, поскольку он зависит от наличия других сообщений в очереди этой и других станций. ПРИМЕЧАНИЕ 2 Более точную настройку часов можно получить, разрешив Bus_Administrator (Администратору шины) отправлять переменную синхронизации в определенное время. Является вопросом реализации. 8.3.8.2 Службы Указаны две службы часов: a) read_clock (считывание часов), которая считывает текущее значение времени; b) set_clock (установка времени), которая устанавливает значение часов. 8.3.9 8.3.9.1 Объект журнал Объект Станция может реализовать объект journal (журнал) в целях отладки. Журнал включает в себя список определяемых пользователем записей с порядковым номером и отметкой времени. Ожидается, что журнал будет реализован в виде циклического буфера, в котором регистрируются последние «j» записей, а более старые отбрасываются. Журнал могут читать несколько администраторов, чтение не является длительным действием. Запись журнала может осуществляться параллельно с высокой скоростью приложениями узла чтобы избежать буферизации, схема индексирования позволяет выбрать допустимую часть журнала. Каждая задача может вносить события в журнал через интерфейс агента (AGI). 8.3.9.2 Службы Указана одна служба журнала: – read_journal (считывание журнала), которая считывает последние записи журнала. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 326 – Объект оборудования 8.3.10 8.3.10.1 Объект Станция может реализовать дескриптор оборудования, описывающий поддерживаемое оборудование. 8.3.10.2 Службы Указана одна служба: – read_equipment_descriptor, который извлекает указатель на место в памяти, где находится дескриптор оборудования. 8.4 8.4.1 8.4.1.1 Служебные и административные сообщения Нотация для всех административных сообщений Структура сообщения Каждая услуга должна быть вызвана посредством обмена административными сообщениями вызова/ответными сообщениями в следующем формате: Management_Message::= RECORD { tnm_key ENUM8 { CALL (‘02’H), REPLY (‘82’H) }, ONE_OF [tnm_key] m essage ответ { [CALL] Call_Mgt_Message, [REPLY] Reply_Mgt_Message } } -- первый октет -- вызов (запрос) -- Ответ (запрос) -- выбрать вызов или -- представлено ниже -- представлено ниже Старший бит «tnm_key» должен указывать, является ли это сообщением вызова или ответным сообщением. Для управления частной сетью значения «tnm_key» должны находиться в диапазоне ‘40’H-’7F’H (вызов) или ‘C0’H – ‘FF’H (ответ). Другие значения зарезервированы для использования в будущем. Для распределения tnm_keys по умолчанию код компании UIC может быть добавлен к ‘40’H для формирования tnm_key. ПРИМЕЧАНИЕ Поля в административных сообщениях выровнены по 32-битной границе для ускорения работы с 32битными процессорами. Это выравнивание предполагает, что первое поле «tnm_key» расположено по адресу, кратному четырем. Служба сообщений должна соблюдать это соглашение как при отправке, так и при получении. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.4.1.2 – 327 – Нотация SIF_code (SIF_кода) SIF_code (SIF_код) обозначает запрошенную службу. Младший бит указывает - служба считывания это или служба записи (изменения). Службы считывания могут пользоваться без предварительного резервирования. Следующие SIF-коды определены для пары tnm_key по умолчанию (‘02’H / ‘82’H). Sif_Code::= ENUM8 -выбор службы { READ_STATION_STATUS (00), WRITE_STATION_CONTROL (01), READ_STATION_INVENTORY (02), WRITE_RESERVATION (03), READ_SERVICE_DESCRIPTOR (04), READ_LINKS_DESCRIPTOR (06), WRITE_LINKS_DESCRIPTOR (07), READ_MVB_STATUS (10), WRITE_MVB_CONTROL (11), READ_MVB_DEVICES (12), WRITE_MVB_ADMINISTRATOR (13), READ_WTB_STATUS (20), WRITE_WTB_CONTROL (21), READ_WTB_NODES (22), READ_WTB_TOPOGRAPHY (24), WRITE_WTB_USER_REPORTport (25), LINE_FAULT_LOCATION_DETECTION (26), WRITE_ATTACH_PORT (29), READ_PORTS_CONFIGURATION (30), WRITE_PORTS_CONFIGURATION (31), READ_VARIABLES (32), WRITE_FORCE_VARIABLES (33), WRITE_UNFORCE_VARIABLES (35), WRITE_UNFORCE_ALL (37), READ_VARIABLE_BINDINGS (38), WRITE_VARIABLE_BINDINGS (39), READ_MESSENGER_STATUS (40), WRITE_MESSENGER_CONTROL (41), READ_FUNCTION_DIRECTORY (42), WRITE_FUNCTION_DIRECTORY (43), READ_STATION_DIRECTORY (44), WRITE_STATION_DIRECTORY (45), READ_GROUP_DIRECTORY (46), WRITE_GROUP_DIRECTORY (47), READ_NODE_DIRECTORY (48), WRITE_NODE_DIRECTORY (49), READ_MEMORY (50), WRITE_MEMORY (51), WRITE_DOWNLOAD_SETUP (53), WRITE_DOWNLOAD_SEGMENT (55), READ_TASKS_STATUS (60), WRITE_TASKS_CONTROL (61), READ_CLOCK (70), WRITE_CLOCK (71), READ_JOURNAL (80), READ_EQUIPMENT (82), USER_SERVICE_0 (128), USER_SERVICE_127 (255) -- (128..255) зарезервировано для пользовательских служб. } ПРИМЕЧАНИЕ SIF-коды для служб многофункциональной шина поезда включены для полноты. Описание служб многофункциональной шина поезда см. в IEC 61375-3-1. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 328 – 8.4.1.3 Нотация для административных сообщений вызова Call_Mgt_Message::= { sif_code RECORD Sif_Code, -- второй октет является SIF-кодом message_body ONE_OF [sif_code] { [READ_STATION_STATUS] Call_Read_Station_Status, [WRITE_STATION_CONTROL] Call_Write_Station_Control, [READ_STATION_INVENTORY] Call_Read_Station_Inventory, [WRITE_RESERVATION] Call_Write_Reservation, [READ_SERVICE_DESCRIPTOR] Call_Read_Service_Descriptor, [READ_LINKS_DESCRIPTOR] Call_Read_Links_Descriptor, [WRITE_LINKS_DESCRIPTOR] Call_Write_Links_Descriptor, [READ_MVB_STATUS] Call_Read_Mvb_Status, [WRITE_MVB_CONTROL] Call_Write_Mvb_Control, [READ_MVB_DEVICES] Call_Read_Mvb_Devices, [WRITE_MVB_ADMINISTRATOR] Call_Write_Mvb_Administrator, [READ_WTB_STATUS] Call_Read_Wtb_Status, [WRITE_WTB_CONTROL] Call_Write_Wtb_Control, [READ_WTB_NODES] Call_Read_Wtb_Nodes, [READ_WTB_TOPOGRAPHY] Call_Read_Wtb_Topography, [WRITE_ATTACH_PORT] Call_Write_Attach_Port, [READ_PORTS_CONFIGURATION] Call_Read_Ports_Configuration, [WRITE_PORTS_CONFIGURATION] Call_Write_Ports_Configuration, [READ_VARIABLES] Call_Read_Variables, [WRITE_FORCE_VARIABLES] Call_Write_Force_Variables, [WRITE_UNFORCE_VARIABLES] Call_Write_Unforce_Variables, [WRITE_UNFORCE_ALL] Call_Write_Unforce_All, [READ_VARIABLE_BINDINGS] Call_Read_Variable_Bindings, [WRITE_VARIABLE_BINDINGS] Call_Write_Variable_Bindings, [READ_MESSENGER_STATUS] Call_Read_Messenger_Status, [WRITE_MESSENGER_CONTROL] Call_Write_Messenger_Control, [READ_FUNCTION_DIRECTORY] Call_Read_Function_Directory, [WRITE_FUNCTION_DIRECTORY] Call_Write_Function_Directory, [READ_STATION_DIRECTORY] Call_Read_Station_Directory, [WRITE_STATION_DIRECTORY] Call_Write_Station_Directory, [READ_GROUP_DIRECTORY] Call_Read_Group_Directory, [WRITE_GROUP_DIRECTORY] Call_Write_Group_Directory, [READ_NODE_DIRECTORY] Call_Read_Node_Directory, [WRITE_NODE_DIRECTORY] Call_Write_Node_Directory, [READ_MEMORY] Call_Read_Memory [WRITE_MEMORY] Call_Write_Memory [WRITE_DOWNLOAD_SETUP] Call_Write_Download_Setup, [WRITE_DOWNLOAD_SEGMENT] Call_Write_Download_Segment , [READ_TASKS_STATUS] Call_Read_Tasks_Status, [WRITE_TASKS_CONTROL] Call_Write_Tasks_Control, [READ_CLOCK] Call_Read_Clock, [WRITE_CLOCK] Call_Write_Clock, [READ_JOURNAL] Call_Read_Journal, [READ_EQUIPMENT] Call_Read_Equipment, } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.4.1.4 – 329 – Нотация для административных ответных сообщений Reply_Mgt_Message::= RECORD { sif_code Sif_Code, -- второй октет является SIF-кодом message_body ONE_OF [sif_code] { [READ_STATION_STATUS] Reply_Read_Station_Status, [WRITE_STATION_CONTROL] Reply_Write_Station_Control, [READ_STATION_INVENTORY] Reply_Read_Station_Inventory, [WRITE_RESERVATION] Reply_Write_Reservation, [READ_SERVICE_DESCRIPTOR] Reply_Read_Service_Descriptor, [READ_LINKS_DESCRIPTOR] Reply_Read_Links_Descriptor, [WRITE_LINKS_DESCRIPTOR] Reply_Write_Links_Descriptor, [READ_MVB_STATUS] Reply_Read_Mvb_Status, [WRITE_MVB_CONTROL] Reply_Write_Mvb_Control, [READ_MVB_DEVICES] Reply_Read_Mvb_Devices, [WRITE_MVB_ADMINISTRATOR] Reply_Write_Mvb_Administrator, [READ_WTB_STATUS] Reply_Read_Wtb_Status, [WRITE_WTB_CONTROL] Reply_Write_Wtb_Control, [READ_WTB_NODES] Reply_Read_Wtb_Nodes, [READ_WTB_TOPOGRAPHY] Reply_Read_Wtb_Topography, [WRITE_ATTACH_PORT] Reply_Write_Attach_Port, [READ_PORTS_CONFIGURATION] Reply_Read_Ports_Configuration, [WRITE_PORTS_CONFIGURATION] Reply_Write_Ports_Configuration, [READ_VARIABLES] Reply_Read_Variables, [WRITE_FORCE_VARIABLES] Reply_Write_Force_Variables, [WRITE_UNFORCE_VARIABLES] Reply_Write_Unforce_Variables, [WRITE_UNFORCE_ALL] Reply_Write_Unforce_All, [READ_VARIABLE_BINDINGS] Reply_Read_Variable_Bindings, [WRITE_VARIABLE_BINDINGS] Reply_Write_Variable_Bindings, [READ_MESSENGER_STATUS] Reply_Read_Messenger_Status, [WRITE_MESSENGER_CONTROL] Reply_Write_Messenger_Control, [READ_FUNCTION_DIRECTORY] Reply_Read_Function_Directory, [WRITE_FUNCTION_DIRECTORY] Reply_Write_Function_Directory, [READ_STATION_DIRECTORY] Reply_Read_Station_Directory, [WRITE_STATION_DIRECTORY] Reply_Write_Station_Directory, [READ_GROUP_DIRECTORY] Reply_Read_Group_Directory, [WRITE_GROUP_DIRECTORY] Reply_Write_Group_Directory, [READ_NODE_DIRECTORY] Reply_Read_Node_Directory, [WRITE_NODE_DIRECTORY] Reply_Write_Node_Directory, [READ_MEMORY] Reply_Read_Memory [WRITE_MEMORY] Reply_Write_Memory [WRITE_DOWNLOAD_SETUP] Reply_Write_Download_Setup, [WRITE_DOWNLOAD_SEGMENT] Reply_Write_Download_Segment, [READ_TASKS_STATUS] Reply_Read_Tasks_Status, [WRITE_TASKS_CONTROL] Reply_Write_Tasks_Control, [READ_CLOCK] Reply_Read_Clock, [WRITE_CLOCK] Reply_Write_Clock, [READ_JOURNAL] Reply_Read_Journal, [READ_EQUIPMENT] Replay_Read_Equipment } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 330 – 8.4.1.5 61375-2-1 IEC:2012 Отчет о состоянии и ошибках Агент должен сообщить об успехе или неудаче через свое состояние ответчика, которое не передается в теле ответного сообщения, а передается как отдельный параметр в заголовке сессии. Результат, установленный агентом, может быть изменен сетью в случае возникновения ошибки связи. В этом случае сеть возвращает ошибку связи, заменяя код Агента собственным кодом Am_Result. Состояние ответчика должен быть возвращен администратору в качестве параметра «mm_service_conf». Отчет о состоянии и ошибке должен объединять результаты агента и сети, как указано типом Mm_Result: Mm_Result::= ENUM8 { MM_OK (0) -- успешное завершение AM_FAILURE (1) -- неустановленный сбой AM_BUS_ERR (2) -- передача по шине невозможна AM_REM_CONN_OVF (3) -- слишком много входящих соединений AM_CONN_TMO_ERR (4) -- не получено ответа на запрос на установление соединения AM_SEND_TMO_ERR (5) -- тайм-аут SEND_TMO истек AM_REPLY_TMO_ERR (6) -- ответ не получен AM_ALIVE_TMO_ERR (7) -- тайм-аут ALIVE_TMO истек AM_NO_LOC_MEM_ERR (8) -- недостаточно памяти или времени AM_NO_REM_MEM_ERR (9) -- недостаточно памяти или времени партнера AM_REM_CANC_ERR (10) -- отменено партнером AM_ALREADY_USED (11) -- некоторые операции уже выполнены AM_ADDR_FMT_ERR (12) -- ошибка формата адреса AM_NO_REPLY_EXP_ERR (13) -- такой ответ не ожидается AM_NR_OF_CALLS_OVF (14) -- запрошено слишком много вызовов AM_REPLY_LEN_OVF (15) -- слишком длинное ответное сообщение AM_DUPL_LINK_ERR (16) -- ошибка дублирования сеанса связи AM_MY_DEV_UNKNOWN_ERR (17) -- неизвестное собственное устройство AM_NO_READY_INST_ERR (18) -- не готов экземпляр ответчика AM_NR_OF_INST_OVF (19) -- слишком много экземпляров ответчика AM_CALL_LEN_OVF (20) -- слишком длинное сообщение вызова AM_UNKNOWN_DEST_ERR (21) -- неизвестное устройство партнера AM_INAUG_ERR (22) -- произошло открытие эксплуатации поезда AM_TRY_LATER_ERR (23) -- (только внутреннее использование) AM_FIN_NOT_REG_ERR (24) -- конечный адрес не зарегистрирован AM_GW_FIN_NOT_REG_ERR (25) -- конечный адрес не зарегистрирован в маршрутизаторе AM_GW_ORI_REG_ERR (26) -- начальный адрес не зарегистрирован в маршрутизаторе MM_SIF_NOT_SUPPORTED MM_RDONLY_ACCESS чтения MM_CMD_NOT_EXECUTED MM_DNLD_NO_FLASH (36) -- в (33) (34) (35) этом месте MM_DNLD_FLASH_HW_ERR (37) время загрузки MM_BAD_CHECKSUM сумма MM_INT_ERROR домена (39) MM_ER_VERS (40) MM_BUS_HW_BAD (41) MM_BUS_HW_NO_CONFIG (42) обеспечение MM_LP_ERROR (43) MM_VERSION_CONFLICT (44) } -- SIF-код не поддерживается -- разрешен доступ только для -- отказ службы нет энергонезависимой памяти -- ошибка аппаратного обеспечения во (38) -- неправильная контрольная -- внутренняя ошибка -- ошибочная версия -- канал поврежден -- не настроенное аппаратное -- сбой доступа к хранилищу трафика -- конфилкт версий Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 331 – Нумерация битов и кодирование данных 8.4.1.6 Понятие административных сообщений структурировано в 16-битные блоки. Один 16-битный блок может содержать два 8-битных типа, один 16-битный тип или часть 32-битного типа. Следующие преобразования показывают нумерацию битов в зависимости от типов. 0 1 7 8 UNSIGNED8, BITSET8, ENUM8, WORD8 2 2 2 2 2 2 2 2 UNSIGNED8, BITSET8, ENUM8, WORD8 2 2 2 2 2 2 2 2 0 7 8 7 2 15 2 6 1 2 14 3 5 2 2 13 4 4 3 3 2 12 5 4 2 11 6 2 5 1 6 10 9 1 2 3 4 5 6 2 2 2 2 2 2 2 0 1 2 3 4 5 6 2 2 2 2 28 2 2 2 2 2 2 2 12 2 2 2 31 15 6 30 14 5 29 13 4 3 27 11 7 10 6 9 2 26 10 1 25 9 8 7 7 9 BITSET16 2 2 0 7 15 8 2 14 9 UNSIGNED32 2 2 2 24 2 8 23 2 7 22 2 6 12 13 14 15 4 3 2 1 10 11 12 13 14 15 2 2 2 2 2 10 11 12 13 14 15 2 2 2 2 2 2 10 11 12 13 14 15 2 2 2 2 2 2 6 8 11 5 UNSIGNED16, ENUM16, WORD16 2 2 2 2 2 2 0 7 0 9 5 13 21 2 5 4 12 20 2 4 3 11 2 19 2 3 10 18 1 9 17 0 0 8 16 2 2 2 13 14 15 2 1 0 Первым должен быть передан байт с меньшей нумерацией битов. 8.4.2 Службы станции Read_Station_Status (Считывание состояния станции) 8.4.2.1 Описание 8.4.2.1.1 Эта служба удаленно считывает объект Station_Status (Состояние станции). Call_Read_Station_Status (Вызов_Считывание состояния станции) 8.4.2.1.2 0 1 2 3 4 5 6 tnm_key Call_Read_Station_Status::= RECORD {} -- 7 8 9 10 11 12 sif_code = 0 параметры отсутствуют Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 332 – Reply_Read_Station_Status (Ответ_Считывание состояния станции) 8.4.2.1.3 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 0 bus_id reserved1 13 14 15 device_address station_status Reply_Read_Station_Status::= RECORD { bus_id UNSIGNED8 (0..15), reserved1 device_address WORD8 (=0), WORD16, station_status } Station_Status -- идентификатор канала (например, MVB1, WTB), по которому агент получил вызов. Этот канал может не меняться в течение всего сенаса управления. -- резервный -- адрес устройства шины, по которой агент получает вызов -- см. определение ПРИМЕЧАНИЕ Администратор может получить доступ к неизвестной станции, обратившись к ней через ее адрес устройства. Write_Station_Control (Запись управления станцией) 8.4.2.2 Описание 8.4.2.2.1 Эта служба сбрасывает станцию и присваивает ей имя станции и идентификатор станции. Call_Write_Station_Control (Вызов_Запись управления станцией) 8.4.2.2.2 0 1 2 3 4 5 6 7 8 9 tnm_key command 10 11 12 13 14 15 sif_code = 1 RST station_id station_name: STRING32 CHARACTER8 CHARACTER8 или ‘00’H Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 333 – Call_Write_Station_Control::=RECORD { command BITSET8 { rst (7) }, station_id UNSIGNED8, station_name STRING32 -- если 1: сброс станции, очистка всех таблиц и семафора резервирования и запускь только мессенджера и агента. если 0: назначение только нового имени и идентификатора станции. -- 8-битный идентификатор станции, назначенный станции. If идентификатор станции station_id = 0, идентификатор станции не изменяется. -- имя, присвоенное этой станции. Если размер имени станции равен 0, имя станции не изменяется. } Reply_Write_Station_Control (Ответ_Запись управления станцией) 8.4.2.2.3 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 1 bus_id reserved1 13 14 15 device_address Reply_Write_Station_Control::= RECORD { bus_id UNSIGNED8 (0..15), reserved1 device_address -- sif_code = 1 -- канал, по которому агент получил сообщение вызова -- резервный -- адрес, по которому агент получил сообщение вызова WORD8 (=0), WORD16 } Read_Station_Inventory (Считывание инвентарного списка станции) 8.4.2.3 Описание 8.4.2.3.1 Эта служба считывает объект inventory (инвентарный список). Call_Read_Station_Inventory (Вызов_Считывание инвентарного списка станции) 8.4.2.3.2 0 1 2 3 4 5 6 7 tnm_key Call_Read_Station_Inventory::= RECORD {} -- 8 9 10 11 12 13 14 15 sif_code = 2 параметры отсутствуют Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 334 – Reply_Read_Station_Inventory (Ответ_Считывание инвентарного списка станции) 8.4.2.3.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 2 reserved1 agent_version: STRING32 CHARACTER8 или ‘00’H CHARACTER8 manufacturer_name: STRING32 CHARACTER8 или ‘00’H CHARACTER8 device_type: STRING32 CHARACTER8 или ‘00’H CHARACTER8 service_set: BITSET256 SV255 SV0 LL0 link_set reserved2 LL15 station_id station_name: STRING32 CHARACTER8 или ‘00’H (CHARACTER8) station_status Call_Read_Station_Inventory::= RECORD { reserved1 WORD16 (=0) agent_version STRING32 manufacturer_name STRING32 device_type: STRING32 service_set: BITSET256 link_set Link_Set reserved2 station_id WORD8 (=0), UNSIGNED station_name STRING32 station_status } Station_Status -- используется для выравнивания -- версия агента (т.е.ссылка на данный раздел). -- наименование изготовителя устройства -- имя устройства и серийный номер. -- один бит для каждой службы (первый бит, для которого задано 1, означает, что устройство поддерживает службу Read_Station_Status) -- один бит для каждого поддерживаемого хранилища трафика или канального уровня, каждый уровень канала соответствует хранилищу трафика, первый бит соответствует хранилищу трафика 0. -- резервный -- идентификатор данной станции (0 или ‘FF’H если не определено) -- имя, Присвоенное станции (изначально пусто) -- Слово состояния станции ПРИМЕЧАНИЕ Администратор может получить доступ к неизвестной станции, обратившись к ней через ее адрес устройства. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 335 – Write_Station_Reservation (Запись резервирования станции) 8.4.2.4 8.4.2.4.1 Описание Эта служба обращается к объекту резервирования, резервирует или освобождает станцию. Вызов резервирования указывает администратора (через свой адрес приложения), тайм-аут резервирования и права доступа. Он включает 32-битный идентификатор администратора, использование которого зависит от приложения. Станция должна отклонить запрос на резервирование, если она уже зарезервировано и администратор отличается от текущего. Зарезервированная станция должна установить бит «ser» в своем Station_Status (Состоянии станции) и в Device_Status (Состоянии устройства) каждой подключенной к ней многофункциональной шине поезда. Тайм-аут резервирования должен ответственного администратора. возобновляться при приеме любого служебного вызова от Станция снимает резервирование и очищает биты «ser»: a) при получении вызова «release» («освободить») без возможности перезапуска (обычный случай); b) по истечении тайм-аута резервирования; c) при открытии эксплуатации поезда, а администратор находится на другом узле; d) при получении «reset» («сбросить»); e) при получении «override» («переопределить»); В последних двух случаях станция должна выполнить процедуру, подписанную приложением как «station_restart» («перезапуск станции») (см. 8.5.2.4). 8.4.2.4.2 0 Call_Write_Station_Reservation (Вызов_Запись резервирования станции) 1 2 3 4 5 6 7 8 9 tnm_key 10 11 12 13 14 15 sif_code = 3 command access_type reservation_time_out manager_id Call_Write_Reservation::= RECORD { command ENUM16 { RESERVE, (1), Резервирование -- резервиро устройства устройства для данного для вание данного администратора KEEPREL (2), Изменениеи освобождения -- изменен Сохранения STARTREL (3) -- освобож и перезапуск. Освобождение и дение перезапуск }, access_type { WRITEREQ OVERRIDE и сохранения ENUM16 (0), (1) -- запрос доступа к записи -- переопределить зарезервированный доступ. }, Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 336 – reservation_time_out UNSIGNED16, manager_id -- время в течение которого станция остается зарезервированной, кратной 1 с, но не более 3600 с. -- идентифицирует администратора (использование этого идентификатора зависит от реализации). UNSIGNED32 } Reply_Write_Station_Reservation (Ответ_Запись резервирования станции) 8.4.2.4.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 3 reserved1 manager_id Call_Write_Reservation::= RECORD { reserved1 WORD16 manager_id UNSIGNED32 -- для выравнивания -- идентифицирует администратора (использование этого идентификатора зависит от реализации). } Read_Service_Descriptor (Считывание дескриптора службы) 8.4.2.5 Описание 8.4.2.5.1 Эта служба считывает Service_Descriptor (Дескриптор службы), текст описания, определяющий службу или объект, к которому обращается эта служба. Обычно используется только для служб, определяемых пользователем. Call_Read_Service_Descriptor (Вызов_Считывание дескриптора службы) 8.4.2.5.2 0 1 2 3 4 5 6 7 8 10 11 12 tnm_key sif_code = 4 reserved1 get_sif_code Call_Read_Service_Descriptor::= RECORD { reserved1 WORD8 (=0), get_sif_code Sif_Code } 13 14 15 -- резерв -- служба, требующая описания Reply_Read_Service_Descriptor (Ответ_Считывание дескриптора службы) 8.4.2.5.3 0 9 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 4 reserved1 get_sif_code 13 14 15 reserved2 string_size service_description: ARRAY ALIGN16 [string_size] OF (CHARACTER8) CHARACTER8 или ‘00’H Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 337 – Reply_Read_Service_Descriptor::= RECORD { reserved1 WORD8 (=0), -- резерв get_sif_code Sif_Code, -- служба, требующая описания reserved2 WORD16 (=0), -- резерв string_size UNSIGNED16, -- до 65535 символов service_description ARRAY ALIGN16 [string_size] OF CHARACTER8 -- строка, определяемая пользователем } Read_Links_Descriptor (Считывание дескриптора канала) 8.4.2.6 Описание 8.4.2.6.1 Эта служба считывает Links_Descriptor (Дескриптор канала), текст описания, который должен описывать каждый канальный уровень, присутствующий в Station_Inventory (Инвентарный список станции). Call_Read_Links_Descriptor (Вызов_Считывание дескриптора канала) 8.4.2.6.2 0 1 2 3 4 5 6 7 8 9 10 11 tnm_key 13 14 15 sif_code = 6 Call_Read_Links_Descriptor::= RECORD {} -- параметры отсутствуют Reply_Read_Links_Descriptor (Ответ_Считывание дескриптора канала) 8.4.2.6.3 0 12 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 6 nr_links links_descriptor: ARRAY [nr_descriptors] OF bus_id link_type link_name: STRING32 CHARACTER8 или ‘00’H Reply_Read_Links_Descriptor::= RECORD { nr_links UNSIGNED16 (0..15), -- количество поддерживаемых каналов links_descriptor ARRAY [nr_links] OF { -- список существующих каналов, включающий для каждого: bus_id UNSIGNED8 (0..15), -- идентификатор канала link_type ENUM8 { LINK_UNKNOWN (0), -- неизвестный LINK_MVB (1), -- многофункциональная шина поезда LINK_WTB (2), -- проводная шина поезда LINK_MBX (3), -- почтовые ящики памяти LINK_SER (4) -- последовательный канал -- другие зарезервированы }, link_name STRING32 -- имя канала в качестве строки символов } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 338 – Write_Links_Descriptor (Запись дескриптора каналов) 8.4.2.7 Описание 8.4.2.7.1 Эта служба записывает Links_Descriptor (Дескриптор канала), текст описания, который должен описывать каждый канальный уровень, присутствующий в Station_Inventory (Инвентарный список станции). Call_Write_Links_Descriptor (Вызов_Запись дескриптора канала) 8.4.2.7.2 0 1 2 3 4 5 6 7 8 9 10 11 tnm_key 12 13 14 15 sif_code = 7 nr_links links_descriptor: ARRAY [nr_descriptors] OF bus_id link_type link_name: STRING32 CHARACTER8 или ‘00’H Call_Read_Links_Descriptor::= RECORD { nr_links UNSIGNED16 (0..15), -- количество поддерживаемых каналов links_descriptor ARRAY [nr_descriptors] OF { -- список существующих каналов, включающий для каждого: bus_id UNSIGNED8 (0..15), -- идентификатор канала link_type ENUM8 { LINK_UNKNOWN (0), -- неизвестный LINK_MVB (1), -- многофункциональная шина поезда LINK_WTB (2), -- проводная шина поезда LINK_MBX (3), -- почтовые ящики памяти LINK_SER (4), -- последовательный канал LINK_CAN (5), -- шина CAN LINK_ETH (6) -- Ethernet -- другие зарезервированы }, link_name STRING32 -- имя канала } } Reply_Write_Links_Descriptor (Ответ_Запись дескриптора канала) 8.4.2.7.3 0 1 2 3 4 5 6 7 tnm_key Reply_Write_Links_Descriptor::= RECORD {} 8.4.3 8.4.3.1 8.4.3.1.1 8 9 10 11 12 13 14 15 sif_code = 7 -- параметры отсутствуют Службы каналов проводной шины поезда Read_Wtb_Status (Считывание состояния проводной шины поезда) Описание Служба считывает состояние канального уровня узла проводной шины поезда. Если эта станция не оборудована шиной поезда, она возвращает ошибку, а ответное сообщение состоит только из заголовка. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 339 – Возвращенные данные соответствуют структурам данных Type_WTBStatus и Type_LLStatisticData, представленных в 5.6.4.16.3 и 5.6.4.22.3. ПРИМЕЧАНИЕ В случае несоответствия определения параметров, представленные в 5.6.4.16.3 и 5.6.4.22.3, остаются в силе. Call_Read_Wtb_Status (Вызов_Считывание состояния проводной шины поезда) 8.4.3.1.2 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 20 bus_id reserved1 Call_Read_Wtb_Status::= RECORD { bus_id UNSIGNED8 (0..15) reserved1 WORD8 (=0) } 13 14 15 -- идентификатор канала -- резерв Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 340 – Reply_Read_Wtb_Status (Ответ_Считывание состояния проводной шины поезда) 8.4.3.1.3 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key bus_id sif_code = 20 node_address wtb_hardware_id wtb_software_id hardware_state link_layer_state net_inhibit node_address node_orient node_strength node_frame_size node_period node_type node_version node_repor user_report 13 14 15 basic_period_count inauguration_count topography_count transmitted_md_count received_md_count line_status_a1 (transmitted_count) (received_count) (errors_count) (timeouts_count) line_status_a2 line_status_b1 line_status_b2 line_switch_count Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Line_Status::= RECORD { transmitted_count – 341 – UNSIGNED32, UNSIGNED32, -- увеличивается для каждого отправленного кадра received_count -- увеличивается для каждого frame_errors_count UNSIGNED16, frame_timeouts_count UNSIGNED16, кадра тайм-аута } Reply_Read_Wtb_Status::= RECORD { bus_id UNSIGNED8 (0..15) node_address WORD8 wtb_hardware_id UNSIGNED8 wtb_software_id UNSIGNED8 hardware_state { LS_OK ENUM8 LS_FAIL (0), (1) }, link_layer_state Ls_T_State, net_inhibit ENUM8 node_address node_orient UNSIGNED8 ENUM8 { L_UNKNOWN L_SAME L_INVERSE }, node_strength { L_UNDEFINED L_SLAVE отправленного кадра -- увеличивается для каждого ошибочного кадра -- увеличивается для каждого -- идентификатор канала -- Адрес узла (127, если анонимный) -- идентификатор аппаратного обеспечения -- идентификатор версии ПО канального уровня -- WTB_LS_OK правильная работа -- WTB_LS_FAIL отказ аппаратного обеспечения -- основное состояние, в котором узел находится в данный момент -- 1: запрет открытия эксплуатации некоторыми узлами -- присвоенный адрес узла -- ориентация узла относительно главного узла (0), (1), (2) -- WTB_LS_UNKNOWN -- WTB_LS_SAME -- WTB_LS_INVERSE ENUM8 -- мощность узла (0) (1) -- мощность узла не определена -- узел является только подчиненным устройством -- узел является управляющим устройством с большой логической силой -- узел является управляющим устройством с малой логической силой L_STRONG (2) L_WEAK (3) }, node_frame_size UNSIGNED8, node_period UNSIGNED8, node_type UNSIGNED8, node_version UNSIGNED8, node_repor Node_Report, -- размер кадра данных процесса, отправленного узлом. -- требуемый отдельный период, кратный T_bp -- дескриптор возможност ей узла (часть Ключа узла) -- дескриптор возможност ей узла (часть Ключа узла) -- 8-битный отчет узла, как указано в запросе состояния Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 342 – user_report User_Report, basic_period_count UNSIGNED32 inauguration_count UNSIGNED16 topography_count UNSIGNED16 -- 8-битный отчет пользователя, как указано в запросе состояния -- следующее соответствует Type_LLStatisticData -- увеличивается для каждого Основного периода -- увеличивается для каждого открытия эксплуатации -- увеличивается для каждой новой топографии -- увеличивается для каждого transmitted_md_count UNSIGNED32, отправленного received_md_count UNSIGNED32, line_status_a1 Type_LineStatus, line_status_a2 Type_LineStatus, line_status_b1 Type_LineStatus, line_status_b2 Type_LineStatus, line_switch_count переключателя линии UNSIGNED32 Запроса данных сообщения -- увеличивается для каждого полученного запроса данных сообщения -- статистика для A1, см. Определение типа -- статистика для A2, см. Определение типа -- статистика для B1, см. Определение типа -- статистика для B2, см. Определение типа -- увеличивается для каждого } Write_Wtb_Control (Запись управления проводной шиной поезда) Описание 8.4.3.2 8.4.3.2.1 Задает параметры в узле шины поезда. Call_Write_Wtb_Control (Вызов_Запись управления проводной шиной поезда) 8.4.3.2.2 0 rsv1 1 rsv2 2 rsv3 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 21 bus_id reserved1 rsv4 rsv5 csl slp alw Call_Write_Wtb_Control::= RECORD { bus_id UNSIGNED8 (0..15), reserved1 WORD8 (=0) command BITSET16 { rsv1 rsv2 rsv3 rsv4 rsv5 csl slp alw inh rmv snm stm (0), (1), (2), (3), (4), (5), (6), (7), (8), (9), (10), (11), wkm (12), inh rmv --- snm stm wkm 13 14 15 slv cnf rst идентификатор резервного канала ------------- резервный резервный резервный резервный резервный отмена спящего режима установка спящего режима разрешение запрет удаление начало именования установка основного устройства с большой логической силой -- установка основного устройства с малой логической силой Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 343 – slv (13), cnf rst } (14), (15) -- установка подчиненного устройства -- конфигурация -- сброс узла } Reply_Write_Wtb_Control (Ответ_Запись управления проводной шиной поезда) 8.4.3.2.3 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 21 bus_id reserved1 13 14 15 Reply_Write_Wtb_Control::= RECORD { bus_id UNSIGNED8 (0..15), -- идентификатор канала reserved1 WORD8 (=0) -- резерв } Read_Wtb_Nodes (Считывание узлов проводной шины поезда) 8.4.3.3 Описание 8.4.3.3.1 Получает список узлов, обнаруженных управляющим устройством на шине, вместе с их Node Status Word (Словом состояния узла) (эта команда всегда отправляется узлу 01). Call_Read_Wtb_Nodes (Вызов_Считывание узлов проводной шины поезда) 8.4.3.3.2 0 1 2 3 4 5 6 7 8 10 11 12 tnm_key sif_code = 22 bus_id reserved1 = 0 Call_Read_Wtb_Nodes::= RECORD { bus_id UNSIGNED8 (0..15) reserved1 WORD8 (=0) } 13 14 15 -- идентификатор канала -- резерв Reply_Read_Wtb_Nodes (Ответ_Считывание узлов проводной шины поезда) 8.4.3.3.3 0 9 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 22 bus_id node_address reserved1 nr_nodes bottom_node top_node 13 14 15 node_status_list: ARRAY [MAX_NODES] OF node_repor user_report Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 344 – Reply_Read_Wtb_Nodes::= RECORD { bus_id UNSIGNED8 (0..15), -- идентификатор канала node_address UNSIGNED8, -- адрес данного узла (127, если анонимный) reserved1 WORD8 (=0), -- резерв nr_nodes UNSIGNED8, -- количество узлов в подвижном составе. bottom_node UNSIGNED8, -- Адрес узла для узла наименьшим адресом. top_node UNSIGNED8, -- Адрес узла для узла с наибольшим адресом. node_status_list ARRAY[MAX_NODES] OF { -- список состояний узла, начиная с нижнего узла, в порядке расположения узлов и заканчивая верхним узлом, состоящим из: node_report Node_Report -- отчет узла для различных узлов user_report User_Report -- отчет пользователя для различных узлов } } Read_Wtb_Topography (Считывание топографии проводной шины поезда) 8.4.3.4 Описание 8.4.3.4.1 Считывает топографию. Формат топографии указывается в списке параметров, поскольку существуют небольшие различия между информацией о топографии, передаваемой через проводную шину поезда, доступной на интерфейсе управления проводной шиной поезда и доступной посредством сетевого управления. Call_Read_Wtb_Topography (Вызов_Считывание топографии проводной шины поезда) 8.4.3.4.2 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 24 bus_id reserved1 13 14 15 Call_Read_Wtb_Topography::= RECORD { bus_id UNSIGNED8 (0..15), -- идентификатор канала reserved1 WORD8 (=0) -- резерв } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Reply_Read_Wtb_Topography (Ответ_Считывание топографии проводной шины поезда) 8.4.3.4.3 0 – 345 – 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 24 bus_id node_address node_orient rsv1 rsv2 13 14 15 topo_counter individual_period is_strong number_of_nodes bottom_address top_address reserved1 inaug_data_max_size nr_descriptors node_descriptions ARRAY [nr_descriptors] OF node_type sam rsv1 node_address node_version inauguration_data_size inauguration_data ARRAY ALIGNED16 [inauguration_data_size] OF WORD8 Reply_Read_Wtb_Topography::= RECORD { bus_id UNSIGNED8 (0..15), node_address UNSIGNED8, node_orient ENUM8, rsv1 rsv2 topo_counter WORD1 (=0) WORD1 (=0), UNSIGNED6, individual_period UNSIGNED8, is_strong ENUM8, number_of_nodes UNSIGNED8 (0..63), bottom_address UNSIGNED8, top_address UNSIGNED8, inaug_data_max_size UNSIGNED8 nr_descriptors UNSIGNED8 WORD8 -- идентификатор канала -- Адрес узла, к которому подключена данная станция -- ориентация данного узла по отношению к управляющему устройству: 0 = неизвестный, 1 = тот же самый, 2 = обратный -- резервный, = 0 -- резервный, = 0 -- шесть бит счетчика топографии в этом узле. -- 8-битное целое число, представляющее отдельный период, выделенный управляющим устройством как основной период в мс в степени два. -- is_strong = 1: управление шиной управляющим устройством с большой логической силой, is_strong = 0: управление шиной управляющим устройством с малой логической силой -- количество узлов в подвижном составе -- Адрес узла для узла с наибольшим адресом -- Адрес узла для узла с наибольшим адресом -- копия максимального размера данных открытия эксплуатации -- В условиях без ошибок, равное количество узлов Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 346 – node_descriptions ARRAY[nr_descriptors] OF { node_type node_version -- список описаний, начиная с нижнего узла, по адресам узла в порядке возрастания, состоящий из -- первая часть ключа узла -- вторая часть ключа узла sam -- то же направление, что и UNSIGNED8, UNSIGNED8, BOOLEAN1 управляющее устройство rsv1 WORD1 -node_address UNSIGNED6 -inauguration_data_size UNSIGNED8 -inauguration_data ARRAY [inauguration_data_size] WORD8 -- резерв, =0 адрес узла размер следующих данных OF данные открытия эксплуатации, струткруа. Предоставленная пользователем. } } Write_Wtb_User_Report (Запись отчета пользователя по проводной шине пользователя) 8.4.3.5 Описание 8.4.3.5.1 Задает параметры в узле шины поезда. Call_Write_Wtb_User_Report (Вызов_Запись отчета пользователя по проводной шине пользователя) 8.4.3.5.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key ur7 Call_Write_Wtb_User_Report::= RECORD { bus_id UNSIGNED8 (0..15), command BITSET8 { (0), ur6 (1), ur5 (2), ur4 (3), ur3 (4), ur2 (5), ur1 (6), ur0 (7), 12 13 14 15 ur2 ur1 ur0 sif_code = 25 bus_id ur7 11 - ur6 ur5 ur4 ur3 идентификатор канала отчет пользователя бит 7 отчет пользователя бит 6 отчет пользователя бит 5 отчет пользователя бит 4 отчет пользователя бит 3 отчет пользователя бит 2 отчет пользователя бит 1 отчет пользователя бит 0 } } Reply_Write_Wtb_User_Report (Ответ_Запись отчета пользователя по проводной шине пользователя) 8.4.3.5.3 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 25 bus_id reserved1 13 14 15 Reply_Write_Wtb_User_Report::= RECORD { bus_id UNSIGNED8 (0..15), -- идентификатор канала reserved1 WORD8 (=0) -- резерв } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 347 – Line_Fault_Location_Detection 8.4.3.6 LFLD (Обнаружение неисправности линии) Описание 8.4.3.6.1 Служба обнаруживает отказ поврежденной линии между двумя узлами. Если эта станция не оборудована шиной поезда, она возвращает ошибку, а ответное сообщение состоит только из заголовка. Служба включает несколько подкоманд. Для приложения сетевого управления предусмотрены следующие подкоманды: Запуск обнаружения неисправности линии (LFLD) Получение результата обнаружения неисправности линии (LFLD) Отмена обнаружения неисправности линии (LFLD) Для внутреннего использования предусмотрены следующие подкоманды: Указать начало процедуры обнаружения неисправности линии (LFLD) до противоположного конечного узла Указать окончание процедуры обнаружения неисправности линии (LFLD) до противоположного конечного узла Узел сегментации начала процедуры обнаружения неисправности линии (LFLD) (промежуточный узел) Узел сегментации окончания процедуры обнаружения неисправности линии (LFLD) (промежуточный узел) Для использования службы Line_Fault_Location_Detection (Обнаружение неисправности линии) необходимо применить многоэтапный процесс. Диагностическое приложение должно отслеживать биты состояния линии, чтобы обнаруживать повреждение линии. Если обнаружено постоянное повреждение линии, диагностическое приложение должно отправить подкоманду Line_Fault_Location_Detection 0 на конечный узел, чтобы запустить процесс обнаружения неисправности линии (LFLD). Затем диагностическое приложение должно запрашивать результат обнаружения неисправности линии (LFLD) с помощью подкоманды 1 до тех пор, пока результат не укажет на доступность результата. Результат обнаружения неисправности линии (LFLD) можно получить только один раз. Чтобы получить новый результат обнаружения неисправности линии (LFLD) данный процесс необходимо запустить снова. Для отмены запущенного процесса обнаружения неисправности линии (LFLD), диагностическое приложение должно передать подкоманду Line_Fault_Location_Detection 2 конечному узлу, на котором процесс обнаружения неисправности линии (LFLD) был запущен с помощью подкоманды 0. ПРИМЕЧАНИЕ 1 При наличии нескольких отказов на поврежденной линии может быть обнаружен только один. ПРИМЕЧАНИЕ 2 Если есть узлы, которые не поддерживают службу Line_Fault_Location_Detection, место неисправности может располагаться только между несколькими узлами. ПРИМЕЧАНИЕ 3 Если произойдет открытие эксплуатации, процесс обнаружения неисправности линии (LFLD) будет прерван. Call_Line_Fault_Location_Detection (Вызов_Обнаружение неисправности линии) 8.4.3.6.2 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 26 bus_id sub_command par1 par2 Call_Line_Fault_Location_Detection ::= RECORD { bus_id UNSIGNED8 (0..15) sub_command WORD8 (0..6) par1 WORD8 par2 WORD8 } ----- 13 14 15 идентификатор канала подкоманда параметр 1 подкоманды LFLD параметр 2 подкоманды LFLD Определены следующие подкоманды Line_Fault_Location_Detection: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 348 – Подкоманда = 0: Запуск процесса обнаружения неисправности линии (LFLD). Данная подкоманда может быть отправлена только на конечный узел. параметр par1 = 0, параметр par2 = 0: Не используется. Подкоманда = 1: Получение результата обнаружения неисправности линии (LFLD). Данная подкоманда может быть отправлена только на конечный узел. Параметр par1 = 0, параметр par2 = 0: Не используется. Подкоманда = 2: Отмена процесса обнаружения неисправности линии (LFLD). Данная подкоманда может быть отправлена только на конечный узел. параметр par1 = 0, параметр par2 = 0: Не используется. Подкоманда = 3: Указывает начало процедуры обнаружения неисправности линии (LFLD) до противоположного конечного узла. Параметр par1 = 0, параметр par2 = 0: Не используется. Подкоманда = 4: Указывает окончание процедуры обнаружения неисправности линии (LFLD) до противоположного конечного узла. Параметр par1 = 0, параметр par2 = 0: Не используется. Подкоманда = 5: Узел сегментации начала процедуры обнаружения неисправности линии (LFLD) (промежуточный узел). Параметр par1 = line (линия) Нормализованная линия с прерыванием связи, используемая управляющим устройством проводной шины поезда (line = 0 означает линию A, line = 1 означает линию B) Параметр par2 = oe адрес противоположного конечного узла oe Подкоманда = 6: Узел сегментации окончания процедуры обнаружения неисправности линии (LFLD) (промежуточный узел). Параметр par1 = line (линия) Нормализованная линия с прерыванием связи, используемая управляющим устройством проводной шины поезда (line = 0 означает линию A, line = 1 означает линию B) параметр par2 = 0 Reply_Line_Fault_Location_Detection (Ответ_Обнаружение неисправности линии) 8.4.3.6.3 0 не используется 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key bus_id sif_code = 26 sub-command result ret1 ret2 reserved 13 14 15 Reply_Line_Fault_Location_Detection ::= RECORD { bus_id UNSIGNED8 (0..15) -- идентификатор канала sub_command WORD8 (0..6) -- подкоманда result WORD8 -- результат выполнения ret1 WORD8 -- возвращаемое значение 1 подкоманды LFLD ret2 WORD8 -- возвращаемое значение 2 подкоманды LFLD reserved1 WORD8 (=0) -- резерв } Определены следующие ответы подкоманды Line_Fault_Location_Detection: Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 349 – Подкоманда = 0 Запуск процесса обнаружения неисправности линии (LFLD). результат = 0 процесс LFLD запущен =1 процесс LFLD уже идет =4 команда отправлена на промежуточный узел: Процесс LFLD не запущен =5 отсутствует поврежденная линия: Процесс LFLD не запущен =6 обе линии (временно) повреждены: Процесс LFLD не может запуститься, параметры ret1, ret2 = 0 не используются Подкоманда = 1 результат = 0 процесс LFLD не запущен, но результат доступен результат = 1 =2 получение результата LFLD. процесс LFLD только что запущен, но результат доступен результат LFLD доступен ret1 = n1 адрес одного узла n1, разграничивающего неисправность линии ret2 = n2 адрес другого узла n2, разграничивающего неисправность линии Подкоманда = 2 результат = 0 =1 отмена процесса LFLD. процесс LFLD не запущен на конечном узле процесс LFLD отменен, параметры ret1, ret2 = 0 не используется Подкоманда = 3: Указывает начало процедуры LFLD до противоположного конечного узла. результат = 0: Процесс LFLD запущен на противоположном конечном узле Параметры ret1, ret2 = 0 не используется. Подкоманда = 4: Указывает окончание процедуры LFLD до противоположного конечного узла. результат = 0: Процесс LFLD завершен на противоположном конечном узле Параметры ret1, ret2 = 0 не используется. Подкоманда = 5: Узел сегментации начала процедуры LFLD, результат = 0: Узел сегментации процедуры LFLD запущен Параметры ret1, ret2 = 0 не используется Подкоманда = 6: Узел сегментации окончания процедуры LFLD, результат = 0 ret1= oe Узел сегментации процедуры LFLD остановлен адрес противоположного конечного узла oe, если кадр успешно получен Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 350 – 127, если ни один кадр не был успешно получен от противоположного конечного узла ret2 = 0 Реле подключения в направлении 1 замкнуто Реле подключения в направлении 2 замкнуто =1 Службы переменных 8.4.4 Read_Ports_Configuration (Считывание конфигурации портов) 8.4.4.1 Описание 8.4.4.1.1 Получает список настроенных портов с кодом функции (F_code) (который подразумевает размер) и атрибутами. Call_Read_Ports_Configuration (Вызов_Считывание конфигурации портов) 8.4.4.1.2 0 1 2 3 4 5 6 7 8 10 11 12 tnm_key sif_code = 30 bus_id reserved1 = 0 Call_Read_Ports_Configuration::= RECORD { bus_id UNSIGNED8, reserved1 WORD8 (=0) } 13 14 15 -- (0..15) -- резерв Reply_Read_Ports_Configuration (Ответ_Считывание конфигурации портов) 8.4.4.1.3 0 9 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 30 nr_ports ports_list: ARRAY [ nr_ports ] OF bus_id f_code port_address (адрес порта) src snk twc frc Reply_Read_Ports_Configuration::= RECORD { nr_ports UNSIGNED16, ports_list { bus_id port_address порта port_config { src snk twc frc }, port_size port_size -- количество портов в этом хранилище трафика (до 4096) ARRAY [nr_ports] OF WORD4, UNSIGNED12, F_Code, -- хранилище трафика -- адрес порта f_code -- код функции (F_code) BITSET4 ----UNSIGNED8 порт публикатора (источник) порт абонента (приемник) передача с контрольной суммой порт с принудительно присвоенным значением -- максимальный размер порта в октетах (только для проводной шины поезда) } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 351 – Write_Ports_Configuration (Запись конфигурации портов) 8.4.4.2 Описание 8.4.4.2.1 Включает и выключает порты. Call_Write_Ports_Configuration (Вызов_Запись конфигурации портов) 8.4.4.2.2 0 1 2 3 4 5 6 7 8 9 10 11 tnm_key 12 13 14 15 sif_code = 31 nr_ports ports_list: ARRAY [ nr_ports ] OF bus_id port address f_code src snk twc frc port_size Call_Write_Ports_Configuration::= RECORD { nr_ports UNSIGNED16, ports_list { bus_id определенный -- количество портов в этом хранилище трафика (до 4096) ARRAY [nr_ports] OF UNSIGNED8 (0..15), -- идентификатор хранилища трафика, port_address станцией -- адрес порта f_code -- код функции UNSIGNED12, F_Code, (F_code) (см.объект Port Configuration (Конфигуарция порта)) port_config { src BITSET4 -- включает порт публикатора (источник) -- включает порт абонента (приемник) -- включает передачу с контрольной суммой -- принудительное присвоение порту snk twc frc значения по умолчанию }, port_size UNSIGNED8 -- максимальный размер порта в октетах (только для проводной шины поезда) } } Reply_Write_Ports_Configuration (Ответ_Запись конфигурации портов) 8.4.4.2.3 0 1 2 3 4 5 6 7 9 10 11 12 tnm_key sif_code = 31 bus_id reserved1 Reply_Write_Ports_Configuration::= RECORD { bus_id UNSIGNED8 (0..15) reserved1 } 8 WORD8 (=0) 13 14 15 -- идентификатор хранилища трафика, определенный станцией -- резерв Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 352 – Read_Variables (Считывание переменных) 8.4.4.3 Описание 8.4.4.3.1 Считывает значение, контрольную переменную и новизну кластера переменных. Каждая переменная идентифицируется по ее положению и положению ее контрольной переменной в хранилище трафика, а также по ее типу и размеру. Переменные могут извлекаться по отдельности, наборами PV_Set или кластерами PV_Cluster. Если последовательные переменные принадлежат одному и тому же набору данных, доступ должен быть согласованным (через PV_Set). Агент должен ответить списком значений в том же порядке, в котором переменные были перечислены в сообщении вызова. Значения переменных должны передаваться в административных сообщениях в том же формате, в котором они будут передаваться как данные процесса по проводной шине поезда, т.е. в формате от старшего к младшему. Каждое значение переменной должно начинаться с границы нового слова. Переменные, которые не заполняют 16-битное слово, должны быть выровнены по правому знаку и, если они знаковые, то дополнены знаком. Переменные размером более 16 бит, но размер которых не кратен 16 битам, должны быть выровнены по правому знаку и дополнены «0» до границы следующего 16-битного слова. ПРИМЕР 8-битное целое число со значением ‘0111 1111’B (+127) передается как ‘0000 0000 0111 1111’B. ПРИМЕР 2 8-битное целое число со значением ‘1111 1111’B (-1) передается как ‘1111 1111 1111 1111’B. Call_Read_Variables (Вызов_Считывание переменных) 8.4.4.3.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 32 nr_vars variables_list: ARRAY [ nr_vars ] OF bus_id port_address var_size var_type var_offset chk_offset Call_Read_Variables::= RECORD { nr_vars UNSIGNED16, variables_list { -- количество переменных в списке. ARRAY [nr_vars] OF bus_id port_address UNSIGNED4, WORD12, var_size UNSIGNED8, -- список с одной записью для каждой переменной. -- идентификатор хранилища трафика -- адрес порта в хранилище трафика -- (Простые типы: размер в битах или структурированные типы: количество элементов в соответствии с 6.2 (Протокол реального времени) Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 353 – var_type UNSIGNED8, var_offset UNSIGNED16, UNSIGNED16 -- тип переменной в соответствии с 6.2 (RTP) -- сдвиг переменной chk_offset -- сдвиг контрольной переменной (‘FFFF’H если не используется). } } Reply_Read_Variables (Ответ_Считывание переменных) 8.4.4.3.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 32 nr_vars values_list: ARRAY [ nr_vars ] OF: значение (выровнено по правому знаку, если меньше 16 бит) счетчик новизны check_var Reply_Read_Variables::= RECORD { nr_vars UNSIGNED16, values_list { -- количество переменных в списке. ARRAY [nr_vars] OF value ANY, check_var ANTIVALENT2, freshness UNSIGNED14 -- для каждой переменной в списке и в том же порядке): -- значение с форматом, заданным размером и типом PV_NAME, выровненным по границе 16битного слова. CHARACTER8 является исключением, поскольку он интерпретируется как особый случай массива ARRAY [0..0] OF CHARACTER8: символ занимает старший октет, а младший октет занимает ‘00’h. -- связанная контрольная переменная или ‘11’B, если ничего не указано. . -- значение новизны переменной в миллисекундах (максимум: 4096 мс). } } ПРИМЕЧЕНИЕ Контрольная переменная также может передаваться как любая другая (ANTIVALENT2) переменная. 8.4.4.4 8.4.4.4.1 Write_Force_Variables (Запись принудительных переменных) Описание Принудительно присваивает кластеру переменных определенное значение. Принудительное присвоение переменной должно установить бит «frc» в Device_Status (Состоянии устройства) соответствующего хранилища трафика многофункциональной шины поезда и в Station_Status (Состоянии станции). Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 354 – В контрольном поле должно быть установлено значение, указанное контрольной переменной. Каждое значение переменной должно начинаться с границы нового слова. Переменные, которые не заполняют 16-битное слово, должны быть выровнены по правому знаку и, если они знаковые, то дополнены знаком. Переменные размером более 16 бит, но размер которых не кратен 16 битам, должны быть выровнены по правому знаку и дополнены «0» до границы следующего 16-битного слова. ПРИМЕЧАНИЕ В состоянии шины поезда отсутствует бит «frc», но эту информацию можно вывести из Station_Status (Состояния станции). Call_Write_Force_Variables (Вызов_Запись принудительных переменных) 8.4.4.4.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 33 nr_vars variables_list: ARRAY [ nr_vars ] OF bus_id port_address var_size var_type var_offset chk_offset values_list: ARRAY ALIGN16 [ nr_vars ] OF forced_value Call_Write_Force_Variables::= RECORD { nr_vars UNSIGNED16, variables_list -- количество переменных в списке ARRAY [ nr_vars ] OF -- одна запись на каждую переменную { bus_id UNSIGNED4, трафика port_address WORD12, var_size UNSIGNED8, var_type UNSIGNED8, var_offset UNSIGNED16, UNSIGNED16 -- идентификатор хранилища -- адрес порта в хранилище трафика -- размер в битах (простые типы) или элементы (структурированные типы) в соответствии с 6.2 (Протокол реального времени) -- тип переменной в соответствии с 6.2 (RTP) -- сдвиг переменной chk_offset -- сдвиг контрольной переменной (‘FFFF’H если не используется). }, values_list { задаваемых в ARRAY ALIGN16 [nr_vars] OF -- список переменных, принудительно forced_value ANY том же порядке, как указано в списке переменных. (применяются те же правила, что и для считываемых переменных) -- значение переменной в формате, заданном типом PV_Name, поскольку оно должно быть отправлено на шину в качестве данных процесса. } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Reply_Write_Force_Variables (Ответ_Запись принудительных переменных) 8.4.4.4.3 0 – 355 – 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 33 Reply_Write_Force_Variables::= RECORD {} -- параметры отсутствуют Write_Unforce_Variables (Запись свободных переменных) 8.4.4.5 Описание 8.4.4.5.1 Свободными являются все переменные списка. Эта служба, в случае успеха, должна сбросить бит «frc» в состоянии соответствующего канального уровня и сбросить бит «frc» в Station_Status (Состоянии станции), если все переменные этой станции были установлены свободно. Call_Write_Unforce_Variables (Вызов_Запись свободных переменных) 8.4.4.5.2 0 1 2 3 4 5 6 7 8 9 10 11 tnm_key 12 13 14 15 sif_code = 35 nr_vars variables_list: ARRAY[ nr_vars ] OF bus_id port_address var_size var_type var_offset chk_offset Call_Write_Unforce_Variables::= RECORD { nr_vars UNSIGNED8, variables_list OF -- количество переменных в списке. ARRAY [ nr_vars] -- одна запись на каждую свободную переменную { bus_id UNSIGNED4, трафика port_address хранилище var_size -- идентификатор хранилища WORD12, -- адрес порта в трафика -- размер в битах (простые типы) или количество элементов (структурированные типы) в соответствии с 6.2 (Протокол реального времени) -- тип переменной в соответствии с 6.2 (RTP) -- сдвиг переменной chk_offset -- сдвиг контрольной переменной (‘FFFF’H если не используется). UNSIGNED8, var_type UNSIGNED8, var_offset UNSIGNED16, UNSIGNED16 } } Reply_Write_Unforce_Variables (Ответ_Запись свободных переменных) 8.4.4.5.3 0 1 2 3 4 tnm_key 5 6 7 8 9 10 11 12 13 14 15 sif_code = 35 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 356 – Reply_Write_Unforce_Variables::= RECORD {} -- параметры отсутствуют Write_Unforce_All (Запись освободить все) 8.4.4.6 Описание 8.4.4.6.1 Освобождает все переменные в определенном хранилище трафика. Эта служба, в случае успеха, очищает бит «frc» в Device_Status (Состоянии устройства), соответствующем этому хранилищу трафика, и в Station_Status (Состоянии станции), как только все хранилища трафика перестанут быть принудительно установленными. Call_Write_Unforce_All (Вызов_запись освободить все) 8.4.4.6.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 12 13 14 link_set Call_Write_Unforce_All::= RECORD { link_set Link_Set } 8.4.4.6.3 15 sif_code = 37 ts0 0 11 ts15 -- набор битов, указывающий, что хранилище трафика не должно быть принудительно установлено, Traffic_Store 0 представлено битом со сдвигом 0. Reply_Write_Unforce_All (Ответ_запись освободить все) 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 37 Reply_Write_Unforce_All::= RECORD {} -- параметры отсутствуют Read_Variable_Bindings (Считывание привязки переменной) 8.4.4.7 Описание 8.4.4.7.1 Считывает привязку всех переменных, поддерживаемых станцией. Порядок произвольный. ПРИМЕЧАНИЕ Данная служба поддерживает сортировку внутренних переменных устройства с сетевыми переменными. Call_Read_Variable_Bindings (Вызов_Считывание привязки переменной) 8.4.4.7.2 0 1 2 3 4 5 6 7 tnm_key 8 9 10 11 12 13 14 15 sif_code = 38 Call_Read_Variable_Bindings::= RECORD { } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Reply_Read_Variable_Bindings (Ответ_Считывание привязки переменной) 8.4.4.7.3 0 – 357 – 1 2 3 4 5 6 7 8 9 10 11 tnm_key 12 13 14 15 sif_code = 38 nr_vars variables_list: ARRAY[ nr_vars ] OF variable_name: STRING32 (CHARACTER8) CHARACTER8 или ‘00’H var_properties individual_period standard_type bus_id port_address var_ size var_type var_offset chk_offset Reply_Read_Variable_Bindings::= RECORD { nr_vars UNSIGNED16, variables_list ARRAY [ nr_vars] OF { variable_name var_properties { bnd (0) phi (1), reg (6), imp (7) STRING32, BITSET8 -- количество переменных в списке. -- одна запись на каждую указанную переменную -- местное имя переменной -- 1 переменная для привязки 0 отсутствие действий -- 1 физический адрес (память) 0 логический адрес (порт) -- 1 обычная переменная, 0 переменная обслуживания -- 1 импортируемая переменная 0 экспортируемая переменная individual period UNSIGNED8 standard _type ENUM16, bus id UNSIGNED4, port address WORD12, var size UNSIGNED8, var type UNSIGNED8, var offset UNSIGNED16, chk offset UNSIGNED16 -- отдельный период переменной во 2 степени в мс (например, 4 = 16 мс). -- тип стандарта, определяемый приложением. -- хранилище траффика, к которому привязана переменная -- адрес порта, к которому привязана переменная -- размер в битах (простые типы) или количество элементов (структурированные типы) в соответствии с 6.2 (Протокол реального времени) -- код типа переменной в соответствии с 6.2 (Протокол реального времени) -- сдвиг переменной в наборе данных -- сдвиг контрольной переменной (‘FFFF’H если не используется). } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 358 – Write_Variable_Bindings (Запись привязки переменной) 8.4.4.8 Описание 8.4.4.8.1 Привязывает ряд переменных к определенному хранилищу трафика и адресу порта или отвязывает от него. ПРИМЕЧАНИЕ Данная служба поддерживает конфигурацию ROSIN. 8.4.4.8.2 Call_Write_Variable_Bindings (Вызов_Запись привязки переменной) 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 39 nr_vars variables_list: ARRAY[ nr_vars ] OF variable_name: STRING32 CHARACTER8 или ‘00’H var_properties standard_type individual_period bus_id port_address var_size var_type var_offset chk_offset Call_Write_Variable_Bindings::= RECORD { nr_vars UNSIGNED16, variables_list { ARRAY [ nr_vars] OF variable_name STRING32 var_properties { bnd (0) BITSET8 reg phl (1), reg (6), ENUM8, individual_period UNSIGNED16 standard_type которому привязана -- массив с одной записью для каждой связанной переменной -- местное имя переменной, которая может быть привязана или отвязана -- 1 переменная для привязки 0 отсутствие действий -- 1 физический адрес (память) 0 логический адрес (порт) -- 1 обычная переменная, 0 переменная обслуживания -- 1 импортируемая переменная, 0 экспортируемая переменная (7), }, standard_type -- количество переменных, которые должны быть связаны. ENUM8, UNSIGNED4, -- тип стандарта, определяемый приложением -- отдельный период переменной в миллисекундах. -- прикладной код типа bus_id -- хранилище трафика, к port_address WORD12, -- равен 0) var_size UNSIGNED8, -- var_type var_offset UNSIGNED8, UNSIGNED16, UNSIGNED16 ---- переменная, или от которого она отвязана. порт, к которому привязана переменная (отвязана, если порт размер в битах (простые типы) или количество элементов (структурированные типы) в соответствии с 6.2. в соответствии с 6.2 (RTP) сдвиг переменной chk_offset сдвиг контрольной переменной (‘FFFF’H если не используется). } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 359 – } Reply_Write_Variable_Bindings (Ответ_Запись привязки переменной) 8.4.4.8.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 39 Reply_Write_Variable_Bindings::= RECORD { } Write_Attach_Port (Запись присоединения порта) 8.4.4.9 Описание 8.4.4.9.1 Присоединение портов хранилища трафика к определенным входам или выходам (станции класса 2). Call_Write_Attach_Port (Вызов_Запись присоединения порта) 8.4.4.9.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 29 nr_ports port_point_list: ARRAY[ nr_vars ] OF bus_id port_address point filter gain offset Call_Write_Attach_Port::= RECORD { nr_ports UNSIGNED16, портов port_point_list { ds_name { bus_id трафика) = (0 -- количество рассматриваемых ARRAY [nr_ports] OF -- перечень портов и точек содержится в каждом элементе RECORD UNSIGNED4 (0..15), -- bus_id (идентификатор шины)(хранилище port_address WORD12 по умолчанию) -- 12-битный адрес порта (делится на 2) } point_descriptor RECORD -- дескриптор точки, содержащий: { point UNSIGNED16, filter UNSIGNED16, gain UNSIGNED16, offset INTEGER16 -- 16-битный идентификатор точки ввода/вывода -- постоянная времени фильтра, кратная 10 мс (или 0, если не используется) -- значение усиления аналогового значения -- значение сдвига аналогового значения } } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 360 – Reply_Write_Attach_Port (Ответ_Запись присоединения порта) 8.4.4.9.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 12 13 14 15 sif_code = 39 Reply_Write_Attach_Port::= RECORD {} 8.4.5 11 -- параметры отсутствуют Службы сообщений Read_Messenger_Status (Считывание состояния мессенджера) 8.4.5.1 Описание 8.4.5.1.1 Получает состояние мессенджера и его счетчики статистики. Call_Read_Messenger_Status (Вызов_Считывание состояния мессенджера) 8.4.5.1.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 12 13 14 15 sif_code = 40 Call_Read_Messenger_Status::= RECORD {} -- параметры отсутствуют Reply_Read_Messenger_Status (Ответ_Считывание состояния мессенджера) 8.4.5.1.3 0 11 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 40 reserved1 messenger_name: STRING32 CHARACTER8 или ‘00’H send_time_out alive_time_out ack_time_out credit reserved2 packet_size instances multicast_window messages_sent messages_received packets_sent packet_retries multicast_retries Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 361 – Reply_Read_Messenger_Status::= RECORD { reserved1 WORD16 (=0), messenger_name STRING32, send_time_out UNSIGNED8, alive_time_out UNSIGNED8, ack_time_out UNSIGNED8, credit UNSIGNED8, reserved2 packet_size instances WORD8 (=0), UNSIGNED8, UNSIGNED8, multicast_window UNSIGNED8, messages_sent UNSIGNED32, messages_received UNSIGNED32, packets_sent UNSIGNED32, packet_retries UNSIGNED32, multicast_retries UNSIGNED32 -- резерв -- версия ПО мессенджера, предпочтительно в формате: xxxx-Vz.z-дд.мм.гг -- тайм-аут после которого поставщик попытку, кратный 64 мс -- тайм-аут, после которого потребитель отключается, в секундах -- тайм-аут после которого ответчик подтверждает все полученные пакеты данных, кратный 64 мс -- количество пакетов данных, которые поставщик может отправить, прежде чем он получит подтверждение для любого из них -- резерв -- размер пакета в октетах -- количество поддерживаемых экземпляров для каждого ответчика. -- размер окна для механизма многоадресной передачи. Если 0, многоадресная передача не поддерживается. -- счетчик (с зацикливанием) подсчет количества сообщений, отправленных этой станцией -- счетчик (с зацикливанием) подсчет количества сообщений, полученных этой станцией -- счетчик (с зацикливанием) подсчет количества пакетов, отправленных этой станцией -- счетчик (с зацикливанием) подсчет количества повторных пакетов в одноадресном протоколе -- счетчик (с зацикливанием) подсчет количества повторных пакетов в многоадресном протоколе } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 362 – Write_Messenger_Control (Запись управления мессенджером) 8.4.5.2 Описание 8.4.5.2.1 Задает параметры в мессенджере. Call_Write_Messenger_Control (Вызов_Запись управления мессенджером) 8.4.5.2.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 41 reserved1 messenger_name: STRING32 CHARACTER8 CHARACTER8 или ‘00’H send_time_out alive_time_out ack_time_out credit reserved2 rsv1 rsv2 rsv3 mcr pkr packet_size pks mgr mgs Call_Write_Messenger_Control::= RECORD { reserved1 WORD16 (=0), messenger_name STRING32, send_time_out UNSIGNED8, alive_time_out UNSIGNED8, ack_time_out UNSIGNED8, credit UNSIGNED8, reserved2 packet_size WORD8 (=0), UNSIGNED8, clear_counter BITSET8 { rsv1, rsv2, rsv3, mcr, рассылки pkr, pks, mgr, mgr, }, multicast_window } UNSIGNED8 multicast_window -- резерв -- версия ПО мессенджера, предпочтительно в формате: xxxx-Vz.z-дд.мм.гг -- тайм-аут, после которого поставщик повторяет попытку, кратный 64 мс -- тайм-аут, после которого потребитель отключается, в секундах -- тайм-аут после которого ответчик подтверждает все полученные пакеты данных, кратный 64 мс -- количество пакетов данных, которые могут быть отправлены до получения подтверждения -- резерв -- размер пакета, в октетах -- очищает следующие счетчики: ----- резерв резерв резерв счетчик повторов многоадресной ----- счетчик счетчик счетчик счетчик повторов пакетов отправленных пакетов полученных сообщений отправленных сообщений -- размер окна для механизма многоадресной передачи. -- Если 0, многоадресная передача не поддерживается. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Reply_Write_Messenger_Control (Ответ_Запись управления мессенджером) 8.4.5.2.3 0 – 363 – 1 2 3 4 5 6 7 8 tnm_key 9 10 11 12 13 14 15 14 15 sif_code = 41 Reply_Write_Messenger_Control::= RECORD {} -- параметры отсутствуют Read_Function_Directory (Считывание каталога функций) 8.4.5.3 Описание 8.4.5.3.1 Считывает Function_Directory (Каталог функций) на станции. Call_Read_Function_Directory (Вызов_Считывание каталога функций) 8.4.5.3.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 12 13 sif_code = 42 Call_Read_Function_Directory::= RECORD {} -- параметры отсутствуют Reply_Read_Function_Directory (Ответ_Считывание каталога функций) 8.4.5.3.3 0 11 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 42 reserved1 nr_functions 13 14 15 function_list: ARRAY[nr_functions] OF function_id Reply_Read_Function_Directory::= RECORD { reserved1 WORD8 (=0) nr_functions UNSIGNED8, function_list { function_id station_id station_id -- reserved -- количество записей в списке ARRAY[nr_functions] OF -- массив функций и пары станций, каждая включает: UNSIGNED8, -- Иденртификатор функции UNSIGNED8 -- соответствующий Идентификатор станции } } 8.4.5.4 8.4.5.4.1 Write_Function_Directory (Запись каталога функций) Описание Записывает Function_Directory (Каталог функций) на станции. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 364 – Call_Write_Function_Directory (Вызов_Запись каталога функций) 8.4.5.4.2 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 43 clear_directory nr_functions 13 14 15 function_list: ARRAY [nr_functions] OF function_id station_id Call_Write_Function_Directory::= RECORD { clear_directory ENUM8 { REPLACE (0), -- не очищать, просто заменить записи -- очистить каталог перед вставкой CLEARFIRST (1) }, nr_functions -- количество записей в спис ке function_list ARRAY [nr_functions] OF { -- массив функций и пар станций, каждая включает: function_id UNSIGNED8, -- идентификатор функции station_id UNSIGNED8 -- соответствующий Идентификатор станции } } Reply_Write_Function_Directory (Ответ_Запись каталога функций) 8.4.5.4.3 0 UNSIGNED8, 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 14 15 sif_code = 43 Reply_Write_Function_Directory::= RECORD {} -- параметры отсутствуют Read_Station_Directory (Считывание каталога станций) 8.4.5.5 Описание 8.4.5.5.1 Считывает Station_Directory (Каталог станций) на станции. Call_Read_Station_Directory (Вызов_Считывание каталога станций) 8.4.5.5.2 0 1 2 3 4 5 6 7 tnm_key Call_Read_Station_Directory::= RECORD {} 8 9 10 11 12 13 sif_code = 44 -- параметры отсутствуют Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Reply_Read_Station_Directory (Ответ_Считывание каталога станций) 8.4.5.5.3 0 – 365 – 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 44 reserved1 nr_stations 13 14 15 station_list: ARRAY [nr_stations] OF station_id next_station_id bus_id reserved2 device_address Reply_Read_Station_Directory::= RECORD { reserved1 WORD8 (=0), nr_stations UNSIGNED8, station_list { station_id next_station_id для -- резерв -- количество станций в списке ARRAY [nr_stations] OF -- список станций с соответствующей следующей станцией, включая: UNSIGNED8, -- идентификатор станции UNSIGNED8, -- идентификатор станции следующей станции UNSIGNED8 (0..15), -- идентификатор канала, где находится следующая станция WORD8 (=0), -- резерв UNSIGNED16 -- адрес устройства, которое несет следующую станцию bus_id reserved2 device_address } } Write_Station_Directory (Запись каталога станций) 8.4.5.6 Описание 8.4.5.6.1 Записывает Station_Directory (Каталог станций) на станции (если существует). Call_Write_Station_Directory (Вызов_Запись каталога станций) 8.4.5.6.2 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 45 clear_directory nr_stations 13 14 15 station_list: ARRAY[nr_stations] OF station_id next_station_id bus_id reserved1 device_address Call_Write_Station_Directory::= RECORD { clear_directory ENUM8 { REPLACE (0), CLEARFIRST (1) -- не очищать, просто заменитьзаписи -- очистить каталог перед вставкой }, Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 366 – nr_stations UNSIGNED8, -- число станций в этом списке station_list { ARRAY [nr_stations] OF -- список станций с соответствующей следующей станцией, включая: station_id next_station_id UNSIGNED8, UNSIGNED8, bus_id UNSIGNED8 (0..15), -- Идентификатор станции -- Идентификатор следующей станции -- идентификатор канала, где находится следующая станция reserved1 device_address WORD8 (=0), UNSIGNED16 -- reserved -- адрес устройства, которое несет следующую станцию } } Reply_Write_Station_Directory (Ответ_Запись каталога станций) 8.4.5.6.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 13 14 15 13 14 15 g10 g9 g8 sif_code = 45 Reply_Write_Station_Directory::= RECORD {} -- параметры отсутствуют Read_Group_Directory (Считывание каталога группы) 8.4.5.7 Описание 8.4.5.7.1 Считывает Group_Directory (Каталог группы) на станции (если существует). Call_Read_Group_Directory (Вызов_Считывание каталога группы) 8.4.5.7.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key -- параметры отсутствуют Reply_Read_Group_Directory (Ответ_Считывание каталога группы) 8.4.5.7.3 1 2 3 4 5 6 7 8 9 10 tnm_key g7 12 sif_code = 46 Call_Read_Group_Directory::= RECORD {} 0 11 g6 g5 g4 g3 11 12 sif_code = 46 g2 g1 g0 g15 g14 g13 g12 g11 g23 g24 g39 g40 g55 Reply_Read_Group_Directory::= RECORD { group_list BITSET64 g63 g56 -- один бит, установленный для каждой из возможных 64 групп, к которым может принадлежать станция, сдвиг 0 соответствует группе 0. } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 367 – Write_Group_Directory (Запись каталога группы) 8.4.5.8 Описание 8.4.5.8.1 Записывает Group_Directory (Каталог группы) на станции (если существует). Call_Write_Group_Directory (Вызов_ Запись каталога группы) 8.4.5.8.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key g7 g6 g5 g4 g3 11 12 13 14 15 g10 g9 g8 sif_code = 47 g2 g1 g0 g15 g14 g13 g12 g11 g23 g24 g39 g40 g55 g63 Call_Write_Group_Directory::= RECORD { group_list BITSET64 g56 -- один бит для каждой из возможных 64 групп, к которым может принадлежать станция, бит 0 идентифицирует группу 0. } Reply_Write_Group_Directory (Ответ_Запись каталога группы) 8.4.5.8.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 14 15 sif_code = 47 Reply_Write_Group_Directory::= RECORD {} -- параметры отсутствуют Read_Node_Directory (Считывание каталога узла) 8.4.5.9 Описание 8.4.5.9.1 Считывает Node_Directory (Каталог узла) на узле (если существует). Call_Read_Node_Directory (Вызов_Считывание каталога узла) 8.4.5.9.2 0 1 2 3 4 5 6 tnm_key Call_Read_Node_Directory::= RECORD {} 7 8 9 10 11 12 13 sif_code = 48 -- параметры отсутствуют Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 368 – Reply_Read_Node_Directory (Ответ_Считывание каталога узла) 8.4.5.9.3 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 48 reserved1 nr_nodes 13 14 15 14 15 nodes_list: ARRAY [nr_nodes] OF node_address reserved2 device_address Reply_Read_Node_Directory::= RECORD { reserved1 WORD8 (=0), -- резерв nr_nodes UNSIGNED8, -- количество узлов в списке nodes_list ARRAY [nr_nodes] OF { -- список узлов с соответствующим адресом устройства, включая: node_address UNSIGNED8, -- 8-битный адрес узла reserved2 WORD8 (=0), -- reserved device_address UNSIGNED16 -- Адрес устройства узлов } } 8.4.5.10 Write_Node_Directory (Запись каталога узла) Описание 8.4.5.10.1 Записывает Node_Directory (Каталог узла) на узле (если существует). Call_Write_Node_Directory (Вызов_Запись каталога узла) 8.4.5.10.2 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 49 clear_directory nr_nodes 13 nodes_list: ARRAY [nr_nodes] OF node_address reserved1 device_address Call_Write_Node_Directory::= RECORD { clear_directory ENUM8 { REPLACE (0), CLEARFIRST (1) }, nr_nodes nodes_list { node_address узла reserved1 device_address } -- не очищать, просто заменить записи -- очистить каталог перед вставкой UNSIGNED8, -- количество узлов в списке ARRAY [nr_nodes] OF -- список узлов с соответствующим адресом устройства, включая: UNSIGNED8, -- 8-битный адрес WORD8 (=0), -- резерв UNSIGNED16 -- адрес устройства узлов } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Reply_Write_Node_Directory (Ответ_Запись каталога узла) 8.4.5.10.3 0 – 369 – 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 49 Reply_Write_Node_Directory::= RECORD {} -- параметры отсутствуют Службы домена 8.4.6 Read_Memory (Считывание памяти) 8.4.6.1 Описание 8.4.6.1.1 Данная служба за одну операцию считывает несколько областей памяти, каждая из которых состоит из ряда идентичных последовательных элементов, размер которых является целым числом, кратным одному октету, причем каждый октет имеет адрес. Необходимо учитывать выравнивание: если размер элемента равен 1, область памяти может начинаться с нечетного или четного адреса; если размер элемента равен 2, область памяти должна начинаться с четного адреса; если размер элемента равен 4, область памяти должна начинаться с адреса, кратного 4. Call_Read_Memory (Вызов_Считывание памяти) 8.4.6.1.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 50 reserved1 nr_regions region_list ARRAY [nr_regions] base_address nr_items reserved2 Call_Read_Memory::= RECORD { reserved1 WORD8 (=0), nr_regions UNSIGNED8, region_list { item_size -- количество отдельных считываемых областей ARRAY[nr_regions] OF nr_items UNSIGNED32, UNSIGNED16, reserved2 item_size WORD8 (=0), UNSIGNED8 -- список областей, каждая область включает base_address -- основной адрес области -- размер области, кратный размеру элемента -- резерв -- размер каждого элемента в октетах допустимые значения: 1,2,4. } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 370 – Reply_Read_Memory (Ответ_Считывание памяти) 8.4.6.1.3 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 50 reserved1 nr_regions 13 14 15 region_values: ARRAY[nr_regions] OF nr_octets item_value_list: ARRAY ALIGN16 [nr_octets] OF WORD8 первый октет четного адреса (или ‘00’H, если второй первый октет, если начало нечетное начало нечетное) item_value последний октет (если начало нечетное, а размер области четный или начало четное, а размер области нечетный) Reply_Read_Memory::= { reserved1 nr_regions region_values { nr_octets values_list { item_value } } последний октет (or ‘00’H, если начало нечетное, а размер области четный или начало четное, а размер области нечетный) RECORD WORD8 (=0), UNSIGNED8, -- резерв -- Количество отдельных, фактически считываемых областей ARRAY [nr_regions] OF -- Массив значений областей, каждое из которых включает: UNSIGNED16, -- количество октетов в передаваемом поле, включая заполняющие октеты. ARRAY ALIGN16 [nr_vars] OF -- массив значений [nr_octets], каждый из которых включает: WORD8 -- значения элементов, передаваемые в непрерывном порядке. -- первый октет должен быть заполняющим октетом, если -- область начинается с нечетного адреса. } ПРИМЕЧАНИЕ Октеты, расположенные по четному адресу памяти, всегда передаются в сообщении с четным сдвигом октетов. Если область памяти начинается с нечетного адреса, первый переданный элемент не имеет смысла. И наоборот, если область памяти начинается с четного адреса и количество октетов нечетное, последний октет не имеет смысла. Если основной адрес нечетный, а количество октетов четное, первый и последний октет не имеют смысла. Поле «nr_octets» содержит эффективно передаваемое количество октетов, оно идентично размеру области только при четном начальном октете и четном количестве октетов. 8.4.6.2 8.4.6.2.1 Write_Memory (Запись памяти) Описание Данная служба за одну операцию записывает несколько областей памяти, каждая из которых состоит из некоторого количества одинаковых элементов заданного размера. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Call_Write_Memory (Вызов_Запись памяти) 8.4.6.2.2 0 – 371 – 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 51 reserved1 nr_regions 13 14 15 region_list: ARRAY [nr_regions] OF base address nr_items reserved2 item_size region_value_list: ARRAY [nr_regions] OF item_value_list: ARRAY [nr_items] OF первый октет, если четное количество октетов, или не имеет смысла четные октеты первый октет, если нечетное количество октетов последний октет (если количество октетов нечетное) последний октет (or ‘00’H, если количество октетов нечетное) Call_Write_Memory::= RECORD { reserved1 WORD8 (=0), nr_regions UNSIGNED8, region_list { UNSIGNED32, nr_items UNSIGNED16, reserved2 item_size WORD8 (=0), UNSIGNED8 item_value_list { октетов), 2: 4: } -- список областей, для каждой области: -- основной адрес области (может быть нечетным). -- размер области кратен размеру элемента -- резерв -- размер в октетах каждого элемента, допустимые значения: 1,2,4. ARRAY [nr_regions] OF -- массив значений областей, каждое из включает: ARRAY ALIGN16 [nr_items] OF -- массив значений nr_items (номеров каждый из которых включает: -- передаются в непрерывном порядке. ONE_OF [item_size] { 1: -- резерв -- количество записываемых областей ARRAY[nr_regions) OF base_address }, region_value_list { которых нечетные октеты WORD8, WORD16, WORD32 -- октеты по четным адресам передаются первыми -- запись последовательных дуплетов -- запись последовательных квадлетов } } } ПРИМЕЧАНИЕ Октеты, расположенные по четному адресу памяти, всегда передаются в сообщении с четным сдвигом октетов. Если область памяти начинается с нечетного адреса, первый переданный элемент не имеет смысла. И наоборот, если область памяти начинается с четного адреса и количество октетов нечетное, последний октет не имеет смысла. Если основной адрес нечетный, а количество октетов четное, первый и последний октет не имеют смысла. Поле «nr_octets» содержит эффективно передаваемое количество октетов, оно идентично размеру области только при четном начальном октете и четном количестве октетов. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 372 – Reply_Write_Memory (Ответ_Запись памяти) 8.4.6.2.3 0 1 2 3 4 5 6 7 8 9 10 11 tnm_key 12 13 14 15 sif_code = 51 Reply_Write_Memory::= RECORD {} -- параметры отсутствуют Download_Setup (Настройка загрузки) 8.4.6.3 Описание 8.4.6.3.1 Настройка загрузки подготавливает загрузку домена, которая осуществляется в разных сегментах. Если между последовательной загрузкой двух сегментов проходит период времени более 16 с, агент должен выполнить сброс станции. Call_Write_Download_Setup (Вызов_ Запись настройки загрузки) 8.4.6.3.2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 tnm_key sif_code = 53 reserved1 download_command reserved2 download_time_out reserved3 nr_domains 14 15 domain_list: ARRAY [nr_domains] OF base address domain_size Call_Write_Download_Setup::= RECORD { reserved1 WORD8 (=0), download_command ENUM8, { DNLD_PREPARE (0), DNLD_CHECK_ONLY, (1) DNLD_START_ERASE (2), DNLD_START_NOERASE (3), DNLD_TERMINATE_BOOT (4), -- обеспечивает запуск станцией программы загрузки. Другие параметры игнорируются. -- проверка допустимости параметров загрузки (согласно банку, основному адресу, размеру и разделу), но не затрагивая станцию. -- если параметры допустимы, признание доменов недопустимыми, очистка памяти и подготовка памяти для загрузки. -- если параметры допустимы, признание доменов недопустимыми, и подготовка памяти для загрузки. -- окончание загрузки и перезапуск Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 373 – DNLD_TERMINATE_BOOT DNLD_VERIFY (5), -- окончание загрузки и прерывание счетчика тайм-аута. ожидание дальнейших служебных вызовов. -- вызов процедуры проверки для данного домена. (6) }, reserved2 download_time_out WORD8 (=0), UNSIGNED8, -- допустимое время между загрузкой двух сегментов в секундах (максимум 16 с) reserved3 WORD8 (=0), nr_domains UNSIGNED8, -- количество доменов для установки domain_list ARRAY [nr_domains] OF { base_address WORD32, -- базовый адрес домена в адресном пространстве агента. item_size WORD32 -- размер каждого домена в октетах. } } Reply_Write_Download_Setup (Ответ_Вызов_ Запись настройки загрузки) 8.4.6.3.3 0 1 2 3 4 5 6 7 8 9 tnm_key 10 11 12 13 14 15 sif_code = 53 max_segment_size reserved1 nr_domains setup_result_list ARRAY [nr_domains] OF ENUM8 первый результат настройки setup_result последний результат настройки setup_result, если (nr_domains) количество доменов нечетное Reply_Write_Download_Setup::= RECORD { max_segment_size UNSIGNED32, reserved1 WORD8 (=0), nr_domains UNSIGNED8, вызовах Call setup_result_list setup_result ENUM8 { DOMAIN_OK (0), DOMAIN_BAD_BASE_ADDR (1), домена DOMAIN_BAD_SIZE домена DOMAIN_ERASE_ERR (3), DOMAIN_ERASE_ERR (4), DOMAIN_BAD_CHECKSUM (5) } } второй результат настройки setup_result последний результат настройки setup_result, если (nr_domains) количество доменов четное, или ‘00’H -- максимальный размер буфера загрузки/разгрузки -- копии количества доменов в ARRAY [nr_domains] OF -- домен успешно установлен -- неверный базовый адрес (2), -- неверный размер -- домен не может быть стерт -- домен не может быть записан -- неправильная контрольная сумма Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 374 – Download_Segment (Сегмент загрузки) 8.4.6.4 Описание 8.4.6.4.1 Эта служба передает сегмент определенного размера в домен, открытый службой Write_Download_Setup. Call_Write_Download_Segment (Вызов_Запись сегмента загрузки) 8.4.6.4.2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 tnm_key sif_code = 55 reserved1 domain_id 14 15 segment_base_address segment_size segment_values: ARRAY [segment_size] OF первый октет по четному адресу или ‘00’H второй октет или первый октет по нечетному адресу octet_element последний или второй последний октет последний октет или ‘00’H Call_Write_Download_Segment::= RECORD { reserved1 WORD8 (=0), domain_id UNSIGNED8, -- заполнение -- идентифицирует домен (индекс массива домена в списке доменов последнего вызова Call_Write_Download_Setup) segment_base_address UNSIGNED32, -- основной адрес сегмента (может быть нечетным) segment_size UNSIGNED32, -- размер сегмента октетах segment_values ARRAY [segment_size] OF { octet_element WORD8 -- список октетов } } Reply_Write_Download_Segment (Ответ_Запись сегмента загрузки) 8.4.6.4.3 0 1 2 3 4 5 6 7 8 9 tnm_key Reply_Write_Download_Segment::= RECORD {} 8.4.7 8.4.7.1 8.4.7.1.1 10 11 12 13 14 15 sif_code = 55 -- параметры отсутствуют Службы задач Read_Tasks_Status (Считывание состояния задач) Описание Эта служба получает имя и состояние задач, установленных на станции. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Call_Read_Tasks_Status (Вызов_Считывание состояния задач) 8.4.7.1.2 0 – 375 – 1 2 3 4 5 6 7 8 9 10 tnm_key 12 13 14 15 sif_code = 60 Call_Read_Tasks_Status::= RECORD {} -- параметры отсутствуют Reply_Read_Tasks_Status (Ответ_Считывание состояния задач) 8.4.7.1.3 0 11 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 60 reserved1 nr_tasks 13 14 15 tasks_list: ARRAY [nr_tasks] OF task_name: STRING16 CHARACTER8 или ‘00’H priority status cpu_load stack_margin task_comment: STRING26 CHARACTER8 или ‘00’H Reply_Read_Tasks_Status::= RECORD { reserved1 WORD8 (=0), nr_tasks UNSIGNED8, tasks_list { task_name priority -- заполнение -- количество возвращаемых задач описание состояния ARRAY [nr_tasks] OF STRING16, UNSIGNED8, status ENUM8 { READY (ГОТОВО) (0), SUSPENDED (ПРИОСТАНОВЛЕНО) (1), PENDING (ОЖИДАНИЕ) (2), RUNNING (РАБОТАЕТ) (3), FAULTY (НЕИСПРАВНО) (4) }, cpu_load UNSIGNED16, stack_margin UNSIGNED16, task_comment } STRING26 -- имя задачи или номер задачи в качестве строки -- приоритет задачи (0 = высокий приоритет) -- состояние задачи -- Загрузка ЦП этой задачей в % (0..100 %); другие значения означают, что измерение загрузки ЦП не поддерживается) -- граница стека этой задачи (‘FFFF’H = служба не поддерживается) } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 376 – Write_Tasks_Control (Запись управления задачами) 8.4.7.2 Описание 8.4.7.2.1 Останов или запуск всех задач. Бит «dnr» (Устройство не готово) должен быть установлен в Station_Status (Состоянии станции) и в Device_Status (Состоянии устройства) всех канальных уровней многофункциональной шины поезда, когда запрашивается останов, и осуществляется очистка после успешного запуска. Call_Write_Tasks_Control (Вызов_Запись управления задачами) 8.4.7.2.2 0 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 61 command task_id Call_Write_Tasks_Control::= RECORD { command ENUM8 { STOP_TASK (0) START_TASK (1) } task_id UNSIGNED8 13 14 15 -- остановить все задачи -- запустить все задачи -- идентифицирует задачу (индекс массива задачи в списке задач Reply_Read_Tasks_Status) для запуска или остановки, 'FF'H запускает/останавливает все задачи } Reply_Write_Tasks_Control (Ответ_Запись управления задачами) 8.4.7.2.3 0 1 2 3 4 5 6 7 8 9 10 tnm_key 12 13 14 15 14 15 sif_code = 61 Reply_Write_Tasks_Control::= RECORD {} 8.4.8 11 -- параметры отсутствуют Службы часов Read_Clock (Считывание значения часов) 8.4.8.1 Описание 8.4.8.1.1 Считывает значение часов на выбранной станции. Call_Read_Clock (Вызов_Считывание значения часов) 8.4.8.1.2 0 1 2 3 4 tnm_key Call_Read_Clock::= RECORD {} 5 6 7 8 9 10 11 12 13 sif_code = 70 -- параметры отсутствуют Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 Reply_Read_Clock (Ответ_Считывание значения часов) 8.4.8.1.3 0 – 377 – 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 70 reserved1 time_date (секунды) time_date (импульсы) Reply_Read_Clock::= RECORD { reserved WORD16 (=0) time_date TIMEDATE48 -- для выравнивания --значение времени в секундах и импульсах } Write_Clock (Запись значения часов) 8.4.8.2 Описание 8.4.8.2.1 Устанавливает значение часов на выбранной станции. Call_Write_Clock (Вызов_Запись значения часов) 8.4.8.2.2 0 1 2 3 4 5 6 7 8 9 10 tnm_key 11 12 13 14 15 sif_code = 71 reserved1 time_date (секунды) time_date (импульсы) Call_Write_Clock::= RECORD { reserved1 WORD16 (=0) time_date TIMEDATE48 секундах -- для выравнивания -- значение времени, устанавливаемое в и импульсах } Reply_Write_Clock (Ответ_Запись значения часов) 8.4.8.2.3 0 1 2 3 4 5 6 7 tnm_key Reply_Write_Clock::= RECORD {} 8.4.9 8.4.9.1 8.4.9.1.1 8 9 10 11 12 13 14 15 sif_code = 71 -- параметры отсутствуют Служба журнала Read_Journal (Считывание журнала) Описание Данная служба считывает последние записи «j» журнала. Значение записей зависит от приложения. Обработка номера индекса объясняется в описании объекта. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 – 378 – Call_Read_Journal (Вызов_Считывание журнала) 8.4.9.1.2 0 1 2 3 4 5 6 7 8 10 11 12 13 tnm_key sif_code = 80 reserved1 number_entries Call_Read_Journal::= RECORD { reserved1 WORD8 (=0), number_entries UNSIGNED8 } 14 15 -- резерв -- до 255 записей. Reply_Read_Journal (Ответ_Считывание журнала) 8.4.9.1.3 0 9 1 2 3 4 5 6 7 8 9 10 11 12 tnm_key sif_code = 80 reserved1 number_entries 13 14 15 event_list ARRAY [number_entries] OF time_stamp: TIMEDATE48 file_name: STRING16 ‘00’H (CHARACTER8) line_number reserved2 event_type event_description: STRING78 (CHARACTER8) ‘00’H Reply_Read_Journal::= RECORD { reserved1 WORD8 (=0), number_entries UNSIGNED8, -- количество возвращенных записей event_list ARRAY [number_entries] OF { time_stamp TIMEDATE48, -- метка времени, когда произошло событие file_name STRING16, -- как указано в ФАЙЛЕ в ANSI 'C' (строка с завершающим нулем) line_number UNSIGNED16, -- как указано в СТРОКЕ В ANSI ’C’ reserved2 WORD8 (=0), event_type ENUM8 -- тип события { INFO (ИНФОРМАЦИЯ) (0), WARNING (ПРЕДУПРЕЖДЕНИЕ) (1), ERROR (ОШИБКА) (2) }, event_description STRING78 -- описание события (строка с нулевым завершением) } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.4.10 – 379 – Служба информации об оборудовании Read_Equipment (Считывание информации об оборудовании) 8.4.10.1 Описание 8.4.10.1.1 Данная служба извлекает указатель на домен памяти, где находится полное описание поддерживаемого оборудования. Формат структуры данных выходит за область применения настоящего стандарта. Call_Read_Equipment (Вызов_Считывание информации об оборудовании) 8.4.10.1.2 0 1 2 3 4 5 6 7 8 9 11 12 tnm_key sif_code = 82 reserved1 reserved2 Call_Read_Equipment::= RECORD { reserved1 WORD8 (=0), reserved2 WORD8 (=0), } 13 14 15 -- резерв -- резерв Reply_Read_Equipment (Ответ_Считывание информации об оборудовании) 8.4.10.1.3 0 10 1 2 3 4 5 6 7 8 9 10 11 12 13 tnm_key sif_code = 82 reserved1 number_entries 14 15 equipment_list ARRAY [number_entries] OF equipment_name: STRING32 ‘00’H (CHARACTER8) equipment_root equipment_size Reply_Read_Equipment::= RECORD { reserved1 WORD8 (=0), number_entries UNSIGNED8, equipment_list { equipment_name: equipment_root equipment_size -- количество возвращенных записей ARRAY [number_entries] OF STRING32, UNSIGNED32 UNSIGNED32 -- идентификация оборудования -- основной адрес домена -- размер дескриптора оборудования } } Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 380 – 8.5 61375-2-1 IEC:2012 Процедуры интерфейса Процедуры интерфейса разделены на интерфейс администратора и интерфейс агента. 8.5.1 Интерфейс администратора (MGI) Все службы интерфейса администратора предоставляются двумя общими процедурами: процедура запроса на обслуживание mm_service_req, и процедура подтверждения обслуживания mm_service_conf. Процедуры интерфейса администратора имеют префикс mm_xxx. Описание Вызовы удаленной службы. Синтаксис MM_RESULT UNSIGNED8 const AM_ADDRESS* struct MM_CALL * Параметр ввода mm_service_req ( station_id; agent_adr; mm_call ); station_id идентификатор данной станции agent_adr Сетевой адрес агента mm_call mm_call идентичен формату тела административного сообщения вызова. (Формат этой структуры зависит от (SIF-кода) SIF_code. ) результатом вызова является код ошибки MM_RESULT, определенный в 8.4.1.5. Результат Описание Синтаксис Параметр вывода Результат Процедура подтверждения службы mm_service_conf возвращает результат вызова службы администратору. Эта процедура может быть процедурой опроса или процедурой индикации. MM_RESULT mm_service_conf ( UNSIGNED8 station_id; AM_ADDRESS * agent_adr; struct MM_REPLY * mm_reply ); station_id идентификатор данной станции agent_adr Сетевой адрес агента mm_reply в случае, если MM_RESULT в норме, эта структура возвращает тело ответного сообщения, в противном случае оно не определено. (Формат этой структуры зависит от (SIF-кода) SIF_code. ) результатом вызова является код ошибки MM_RESULT, определенный в 8.4.1.5. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.5.2 – 381 – Интерфейс агента 8.5.2.1 Описание Однако процедуры интерфейса агента определяют интерфейс не между агентом и сетью, а между агентом и другими процессами станции. Интерфейс агента предоставляет пользователю доступ к агенту для опроса двух условий: изменение (разрешены ли в настоящее время модификации станции?); остановка (можно ли останавливать станцию?). Агенту может потребоваться доступ к ядру реального времени для координации выполнения задачи пользователя. Процедуры интерфейса администратора имеют префикс ma_xxx. 8.5.2.2 Процедуры управления агентом 8.5.2.2.1 Описание Процедура ma_ask_permission Позволяет пользователю опросить, какие существуют административные запросы. Приложение, использующее эту функцию, ответит ma_permit. Синтаксис MA_PERMISSION UNSIGNED8 Параметр ввода task_id ma_ask_permission ( task_id ); задача вызова (определяется индексом массива в списке задач Reply_Read_Tasks_Status) Параметр вывода Возврат 8.5.2.2.2 Описание MA_PERMISSION 0: MA_CHANGE_REQU, запрошены изменения 1: MA_CHANGE_REQU, изменения не запрошены 2: MA_STOP_REQU, запрос останова 3: MA_STOP_REQU, запрос останова отсутствует Процедура ma_give_permission Приложение отвечает на запрос изменения с помощью этой процедуры, указывая, разрешено изменение или нет. Синтаксис void ENUM8 Параметр ввода decision ma_give_permission ( decision ); 0: MA_CHANGE_ALLOWED, изменение разрешено 1: MA_CHANGE_DENIED, изменения не разрешены 2: MA_STOP_ALLOWED, задача может быть остановлена 3: MA_STOP_DENIED остановлена Параметр вывода задача не может быть - Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 382 – 8.5.2.3 8.5.2.3.1 Описание 61375-2-1 IEC:2012 Подписка на службы пользователя Тип MA_SERVICE_CALL Объявление процедуры, которая должна быть вызвана в результате данного вызова службы, которая возвращает параметры, необходимые для ответного сообщения. Синтаксис typedef void AM_ADDRESS * void * UNSIGNED32 void * * UNSIGNED32 * MM_RESULT * Параметр ввода manager_address call_msg_adr 8.5.2.3.2 Описание ( * MA_SERVICE_CALL ) ( manager_address, call_msg_adr, call_msg_size, reply_msg_adr, reply_msg_size agent_status ); указывает на полный сетевой адрес вызывающего администратора. указывает на начало служебного сообщения вызова, подлежащего обработке (поле tnm_key)) call_msg_size размер сообщения вызова в октетах reply_msg_adr указывает на начало служебного ответного сообщения, подлежащего возврату (поле tnm_key)) reply_msg_size размер сообщения вызова в октетах agent_status результат должен быть сообщен администратору, как статус агента. Тип MA_SERVICE_CLOSE Объявление типа вызываемой процедуры для закрытия службы. Синтаксис Параметр ввода typedef void ( * MA_SERVICE_CLOSE ) (void); undefined определяется пользователем Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 61375-2-1 IEC:2012 8.5.2.3.3 Описание – 383 – Процедура ma_subscribe Указывает, какую процедуру пользователя вызывать при получении вызова службы, определяемой пользователем. Ранее назначенный SIF-код перезаписывается без предупреждения. Синтаксис MM_RESULT ENUM16 ENUM8 MA_SERVICE_CALL MA_SERVICE_CLOSE void * Параметр ввода command 8.5.2.4 8.5.2.4.1 Описание 0: подписка 1: отказ от подписки sif_code SIF-код пользователя ( 128) service_call переменная процедуры типа MA_SERVICE_CALL, которая будет выполнять службу при вызове. service_close процедура, которую агент вызовет, когда сообщение ответное сообщение будет полностью отправлено (например, для освобождения буфера). дескриптор услуги в виде видимой строки, оканчивающейся символом ‘00’H. service_desc Возврат ma_subscribe ( command; sif_code; service_call; service_close service_desc ); MM_RESULT Подписка на процедуру перезапуска Тип MA_STATION_RESTART Объявление типа процедуры, которая должна быть вызвана для перезапуска станции по истечении тайм-аута или команды перезапуска. Данная процедура, вероятно, не будет возвратной. Синтаксис typedef void 8.5.2.4.2 Описание ( * MA_STATION_RESTART ) ( ); Процедура ma_subscribe_restart Указывает, какая процедура пользователя должна быть вызвана при перезагрузке станции или тайм-ауте резервирования. Синтаксис MM_RESULT ma_subscribe_restart ( MA_STATION_RESTART station_restart ); Параметр ввода station_restart Возврат MM_RESULT процедура, которую агент будет вызывать по истечении таймаута резервирования или при получении команды сброса. Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 – 384 – 61375-2-1 IEC:2012 Список литературы IEC 60870-5-1, Обобщающий стандарт по основным функциям телемеханики. Часть 5. Протоколы передачи. Раздел один. Форматы кадра передачи ISO/IEC 8482, Информационные технологии. Телекоммуникации и обмен информацией между системами. Многопунктовые соединения на витых парах Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11 МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОМИССИЯ 3, rue de Varembé PO Box 131 CH-1211 Geneva 20 Switzerland (Швейцария) Тел.: + 41 22 919 02 11 Факс: + 41 22 919 03 00 [email protected] www.iec.ch Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг» Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте: [email protected] - Тел.: +41 22 919 02 11
