IEC 61375-2-1
®
Редакция 1.0 2012-06
МЕЖДУНАРОДНЫЙ
СТАНДАРТ
цвет
внутри
IEC 61375-2-1:2012
Оборудование электронное железнодорожное. Сеть поездной
связи (TCN). Часть 2-1: Проводная шина поезда (WTB)
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК,
Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного
соглашения. Вопросы направлять по эл. почте: sales@iec.ch - Тел.: +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
info@iec.ch
www.iec.ch
О МЭК
Международная электротехническая комиссия (МЭК) является ведущей всемирной организацией, которая
разрабатывает и издает международные стандарты в области электротехники, электроники и смежных
технологий.
О публикациях МЭК
Техническое содержание публикаций МЭК постоянно пересматривается. Просим удостовериться, что это последнее
издание, возможно, уже были опубликованы исправления или поправки.
Полезные ссылки:
Каталог публикаций МЭК - www.iec.ch/searchpub
Электропедия - www.electropedia.org
Расширенный поиск позволяет находить публикации
МЭК по различным критериям (номер, текст,
технический комитет и т.д.).
В каталоге также представлена информация о
проектах, замененных и отмененных публикациях.
Ведущий международный онлайн словарь терминов в
области электроники и электротехники, содержащий
более 30 000 терминов и определений на английском и
французском языках, с эквивалентными терминами на
других языках. Также известен как Международный
электротехнический онлайн словарь (IEV).
Недавно
изданные
публикации
webstore.iec.ch/justpublished
МЭК
-
Позволяет отслеживать недавно изданные публикации
МЭК. В разделе «Недавно изданные» представлена
информация обо всех недавно изданных новых
публикациях. Информация также доступна в режиме
онлайн и раз в месяц по электронной почте.
Центр обслуживания клиентов - webstore.iec.ch/csc
Для того, чтобы отправить отзыв, касающийся данной
публикации, или в случае необходимости получения
дополнительной помощи, просим обращаться в Центр
обслуживания клиентов: csc@iec.ch.
csc@iec.ch.
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария. Все
права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте:
sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл. почте:
sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +41 22 919 02 11
61375-2-1 IEC:2012
– 43 –
TCN
WTB
плавающий экран
заземленный экран
стандартный
соединитель
резервная
среда
сплавление
Данные_Процесса в
Главных_Кадрах
RTP
возможнос
ть
маршрутиз
атора
каталог
станции
возможность
многоадресно
й передачи
TNM
возможность
администрато
ра
Рисунок 8 – Варианты конфигурации устройства проводной шины поезда (WTB)
сети поездной связи (TCN)
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +41 22 919 02 11
61375-2-1 © IEC:2012
5.5.4.6
– 117 –
Основные состояния основного процесса
Как показано на Рисунке 88, основной процесс разделен на основные состояния.
Эти состояния подразделяются на несколько состояний, представленных макросом (который
появляется только один раз) или процедурой (которая может появляться несколько раз), как
представлено в следующих подразделах.
питание
ЗАПУСК_УЗ
ЛА
установить_
управляюще
е
устройство
ИМЕНУЮ
ЩЕЕ
_УПРАВ
ЛЯЮЩЕРасформ.
переименован
Е
ное
УСТРОЙ
обуча
СТВО
ющее
ОБУЧАЮЩЕ
Е
_УПРАВЛЯ
ЮЩЕЕ
все_обучены
ошибка_ра
УСТРОЙС
спределен
ТВО
ия
УПРАВЛ
ЯЮЩЕЕ
УСТРОЙ
обучающ
СТВО
переим
ее
_ДЛЯ
енован
ПЛАНОВ спящее
ное
ОЙ
ЭКСПЛУ
понижен
ное АТАЦИИ
установить
_спящий
режим
установить
_подчинен
ное
устройство
повышенн
ое
АНОНИМ
НОЕ
_ПОДЧИ
НЕННОЕспящее
УСТРОЙ
СТВОименован
ное
ИМЕН
ОВАН
НОЕ
_ПОДЧ
повышен
ИНЕНН анонимн
ый
ОЕ обучаем
УСТРО
ЙСТВО
ОБУЧАЕ
МОЕ
_ПОДЧИ
повышенн НЕННОЕанонимный
для плановой
УСТРОЙ
ое
эксплуатации
СТВО
ПОДЧИН
ЕННОЕ
УСТРОЙ
СТВО без имени
обучаем
понижен
_ДЛЯ
повышенное
ПЛАНО
ВОЙ
MASTER_STATES
SLAVE_STATES
Состояние
управляющего устройства
Состояние
подчиненного
ЭКСПЛ устройства
(СОСТОЯНИЯ
(СОСТОЯНИЯ
УАТАЦ
УПРАВЛЯЮЩЕ
ПОДЧИНЕННО
ГО
ГО ИИ
УСТРОЙСТВА) Рисунок 88 - Состояния ОСНОВНЫХ ПРОЦЕССОВ
УСТРОЙСТВА
)
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +41 22 919 02 11
– 128 –
61375-2-1 IEC:2012
ПРИМЕЧАНИЕ 1 Ожидается, что анонимный узел получит запрос о наименовании и отправит ответ о наименовании по
своему дополнительному каналу.
ПРИМЕЧАНИЕ 2 Задержка T_aux_main позволяет переключаться с дополнительного канала на основной канал. В это
время трафик шины остановлен.
ПРИМЕНЧАНИЕ 3 Вновь именованный узел принимает имя, отправляя ответ о наименовании, или отказывается от
наименования, не отправляя ответ.
ПРИМЕЧАНИЕ 4 Если узел был именован, но ответ был потерян, попытки с «анонимным» устройством-адресатом
будут неудачными. И наоборот, если присвоение имени не имело места, попытки с устройством-адресатом,
являющимся выделенным адресом узла, будут неудачными.
ПРИМЕЧАНИЕ 5 Именованный узел возвращает ответ о состоянии с дескриптором узла и удаленной мощностью
других узлов, которые он мог обнаружить.
ПРИМЕЧАНИЕ 6 Трехкратное повторение запроса о состоянии в случае возникновения помех позволяет
управляющему устройству различать потерю кадра и потерю одной избыточной линии между ним и конечным узлом.
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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 - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +41 22 919 02 11
– 384 –
61375-2-1 IEC:2012
Список литературы
IEC 60870-5-1, Обобщающий стандарт по основным функциям телемеханики. Часть 5.
Протоколы передачи. Раздел один. Форматы кадра передачи
ISO/IEC 8482, Информационные технологии. Телекоммуникации и обмен информацией
между системами. Многопунктовые соединения на витых парах
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +41 22 919 02 11
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК, Женева, Швейцария.
Все права защищены Настоящий документ является предметом лицензионного соглашения. Вопросы направлять по эл.
почте: sales@iec.ch - Тел.: +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
info@iec.ch
www.iec.ch
Заказчик: Иванов Александр Владимирович - количество пользователей: 1 - Компания АО «Трансмашхолдинг»
Заказ №: Счет 375569 / IndigoSoft - ВАЖНО: Авторские права на настоящий документ принадлежат МЭК,
Женева, Швейцария. Все права защищены Настоящий документ является предметом лицензионного
соглашения. Вопросы направлять по эл. почте: sales@iec.ch - Тел.: +41 22 919 02 11
