СТ РК IEC 61375-3-3_____ НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН Транспорт железнодорожный

СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Изображение государственного Герба Республики Казахстан
НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН
Транспорт железнодорожный
ЭЛЕКТРОННОЕ ОБОРУДОВАНИЕ ДЛЯ ПОДВИЖНОГО СОСТАВА
ЖЕЛЕЗНЫХ ДОРОГ.
СЕТИ ПОЕЗДНОЙ СВЯЗИ (TCN).
Часть 3-3: Сеть CANopen (CCN)
СТ РК IEC 61375-3-3_____
Electronic railway equipment – Train communication network (TCN) –
Part 3-3: CANopen Consist Network (CCN)
Настоящий проект стандарта
не подлежит применению до его утверждения
«Настоящий национальный стандарт является идентичным осуществлением
международного стандарта IEC 61375-3-3 и принят с разрешения СЕН, по
адресу: В-1000 Брюссель, пр. Марникс 17»
Комитет технического регулирования и метрологии
Министерства по инвестициям и развитию
Республики Казахстан
(Госстандарт)
Астана
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Предисловие
1 ПОДГОТОВЛЕН И ВНЕСЕН Акционерным обществом «Казахская
академия транспорта и коммуникаций им. М.Тынышпаева».
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Председателя Комитета
технического регулирования и метрологии Министерства по инвестициям и развитию
Республики Казахстан от ________ № ______
3 Настоящий стандарт идентичен международному стандарту IEC 61375-3-1
Electronic railway equipment – Train communication network (TCN) – Part 3-3: CANopen
Consist Network (CCN) (Электронное оборудование для подвижного состава железных
дорог. Сети поездной связи (TCN). Часть 3-3. Сеть CANopen (CCN).
Международный стандарт IEC 61375-3-3 разработан Европейским техническим
комитетом по стандартизации CEN/TC 256 «Railway applications» (Приспособления,
применяемые на железной дороге).
Перевод с английского языка (en).
Официальные экземпляры международных стандартов, на основе которых
разработан настоящий стандарт, и на которые даны ссылки, имеются в Единном
Государственном фонде нормативно – технических документов.
Степень соответствия - идентичная (IDT).
4 В настоящем стандарте реализованы положения Закона Республики Казахстан
«О техническом регулировании» от 9 ноября 2004 года № 603-II и Закона Республики
Казахстан «О железнодорожном транспорте» от 8 декабря 2001 года № 266-II. (с
изменениями и дополнениями по состоянию на 24.12.2012 г.),
5 СРОК ПЕРВОЙ ПРОВЕРКИ
ПЕРИОДИЧНОСТЬ ПРОВЕРКИ
20____ год
5 лет
6 ВВЕДЕН ВПЕРВЫЕ
Информация об изменениях к настоящему стандарту публикуется в ежегодно
издаваемом информационном указателе «Нормативные документы по
стандартизации», а текст изменений и поправок – в ежемесячно издаваемых
информационных указателях «Национальные стандарты». В случае пересмотра
(замены) или отмены настоящего стандарта соответствующее уведомление будет
опубликовано в ежемесячно издаваемом информационном указателе «Национальные
стандарты».
Настоящий стандарт не может быть полностью или частично воспроизведен,
тиражирован и распространен в качестве официального издания без разрешения
Комитета технического регулирования и метрологии Министерства по инвестициям
и развитию Республики Казахстан.
ii
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
СОДЕРЖАНИЕ
Предисловие ....................................................................................................... 10
ВВЕДЕНИЕ......................................................................................................... 12
1 Область применения ...................................................................................... 13
2 Нормативные ссылки ................................................................................... 13
3 Термины, определения и аббревиатуры ..................................................... 14
3.1 Термины и определения ...................................................................... 14
3.2 Аббревиатуры ...................................................................................... 15
3.3 Условные обозначения ......................................................................... 15
4 Структура ...................................................................................................... 15
4.1 Содержание .......................................................................................... 15
4.2 Логическая сеть на базе CANopen ....................................................... 15
4.3 Топология сети...................................................................................... 16
4.4 Адресация.............................................................................................. 16
4.5 Классы данных ...................................................................................... 17
5 Физический уровень..................................................................................... 17
5.1 Содержание ........................................................................................... 17
5.2 Укладка кабеля ...................................................................................... 17
5.3 Соединитель ......................................................................................... 17
5.4 Присоединение к физической среде ................................................... 19
5.5 Физическая передача сигнала.............................................................. 19
6 Канал передачи данных ............................................................................... 19
6.1 Содержание .......................................................................................... 19
6.2 Уровень канала связи CANopen .......................................................... 20
7 уровень приложения CANopen ................................................................... 20
7.1 Содержание ........................................................................................... 20
7.2 Ссылочная модель ............................................................................... 20
7.3 Модель периферйиного устройства .................................................... 20
7.4 Коммуникационные объекты CANopen ............................................. 22
7.5 Словарь объектов CANopen ................................................................ 22
7.6 Предопределенные коммуникационные объектыCANopen ............ 24
7.6.1 Содержание ............................................................................... 24
7.6.2 Объект1000h: Тип устройства ................................................... 24
7.6.3 Объект1001 h: Регистратор ошибок ........................................... 24
7.6.4 Объект1014h: COB-ID Аварийный объект ................................ 24
7.6.5 Объект1017h: производитель Heartbeat .................................... 24
7.6.6 Объект1018h: Идентификационный объект ............................. 24
7.6.7 Объект1029h: Свойство ошибки ............................................... 24
7.6.8 Объект67FFh: Тип устройства ................................................... 25
7.6.9 Объекты сервисных данных (SDOs) ........................................ 25
7.6.10Объекты процесса данных (PDOs) ........................................... 25
8 Данные о приложении ................................................................................. 25
8.1 Содержание ........................................................................................... 25
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
8.2 Представление данных о приложениях CANopen ............................. 25
8.3 Рекомендуемый принцип представления о прикладных данных ..... 25
8.3.1 Содержание ............................................................................... 25
Прикладные данные для контроля двери .......................................... 25
8.3.2 Потребляемые прикладные данные по контролю двери ........ 26
8.3.3 Производимые прикладные данные по контролю двери ....... 27
9 Управление сетью CANopen ....................................................................... 29
9.1 Содержание ........................................................................................... 29
9.2 Функциональность подчиненного CANopen NMT ........................... 30
9.3 Функциональность по управлениюCANopen .................................... 30
9.3.1 Общая информация ................................................................... 30
9.3.2 Использование словаря объектов............................................. 31
9.3.3 Избыточная сеть......................................................................... 31
9.4 Запуск CANopen NMT ......................................................................... 32
9.4.1 NMT запуск ................................................................................ 32
9.4.2 NMT простой запуск .................................................................. 35
9.4.3 Запуск процесса загрузки подчиненного NMT ....................... 36
9.5 Загрузка подчиненного NMT ............................................................... 37
9.5.1 Проверочная конфигурация ...................................................... 42
9.5.2 Проверка состояния NMT ......................................................... 43
9.5.3 Запуск бегущего механизма NMT ............................................ 43
9.5.4 Статус ошибки ........................................................................... 44
9.6 Контроль ошибки ................................................................................. 45
9.6.1 Старт контроля ошибки ............................................................ 45
9.6.2 Обработчик ошибки .................................................................. 46
9.6.3 Обработчик загрузки ................................................................. 47
9.7 Дополнительные мастер сервисы и протокола NMT ...................... 47
9.8 Словарь вводных объектов.................................................................. 47
9.8.1 Объект 1020h: Подтверждение конфигурации ........................ 47
9.8.2 Объект 102Ah: NMT время адаптации ...................................... 48
9.8.3 Объект 1F20h: хранение DCF .................................................... 49
9.8.4 Объект 1F22h: Сжимание DCF ................................................... 50
9.8.5 Объект 1F26h: Ожидаемая конфигурационная дата ................ 52
9.8.6 Объект 1F27h: Ожидаемое конфигурационное время ............. 53
9.8.7 Объект 1F80h: NMT запуск ........................................................ 54
9.8.8 Объект 1F81h: NMT назначение подчиненного ........................ 56
9.8.9 Объект 1F82h: Запрос NMT ........................................................ 58
9.8.10Объект 1F83h: Защита запроса узла .......................................... 61
9.8.11 Объект 1F84h: Идентификация типа устройства .................... 63
9.8.12Объект 1F85h: Идентификация поставщика ............................ 64
9.8.13Объект 1F86h: Код продукта...................................................... 65
9.8.14Объект 1F87h: Ревизионный номер .......................................... 66
9.8.15Объект 1F88h: Серийный номер ............................................... 67
iv
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
9.8.16Объект 1F89h: Время перезагрузки ........................................... 68
9.8.17Объект 1F8Ah: Конфигурация восстановления ........................ 69
9.8.18Объект 1F91h: Параметры времени самостоятельно запускающийся
узлов rs .................................................................................................. 70
10 Функции шлюза ............................................................................................ 71
10.1 Содержание ........................................................................................... 71
10.2 Структура шлюза ................................................................................. 72
10.3 Общие принципы и сервисы ............................................................... 73
10.3.1 Содержание ................................................................................ 73
10.3.2 Определение класса шлюза .................................................... 73
10.3.3 Описание сервисных примитивов ............................................... 73
10.4 Сервисные спецификации доступа к сети......................................... 73
10.4.1 сервисы доступа SDO ................................................................ 73
10.4.2сервисы доступаPDO ............................................................... 75
10.4.3CANopen NMT сервисы ............................................................. 78
10.4.4Сервисы управления неполадками в устройстве
10.4.5Сервисы интерфейсных конфигурации ................................... 82
10.4.6Сервисы управления шлюзами ................................................. 84
10.4.7Специальные сервисы производителей ................................... 85
10.5 ASCII сервисы контроля доступа к сети ............................................ 85
10.5.1 Содержание ................................................................................ 85
10.5.2Определения ............................................................................... 86
10.5.3Команда спецификации доступа к сети .................................... 89
11 Управление поездной сетью ........................................................................ 97
11.1 Содержание ........................................................................................... 97
11.2 Менеджер, Агенты и интерфейсы (для информации) ....................... 98
11.3 Управление протоколом сообщений (для информации) ................... 98
11.4 Объект интерфейсов(для информации) .............................................. 98
11.5 CANopen-специальные сервисы управления ...................................... 98
11.5.1Общая информация ................................................................... 98
11.5.2Интерфейс агентов на Станции, соединенной с сетью CANopen 98
11.5.3Структура управления сообщением для сети CANopen ........ 99
11.5.4Обозначение CANopen специальных SIF_кодов .................... 99
11.5.5Обозначение вызова управления сообщениями CANopen .. 100
11.5.6Обозначение для ответа управления сообщениями CANopen
100
11.5.7Обозначение для сервисов командных кодов TNM CANopen
100
11.6 TNM CANopen сервисы ..................................................................... 101
11.6.1 Содержание .............................................................................. 101
11.6.2вызов_Write_CANopen_Command (с сохранением) ............... 101
11.6.3ответ_Write_CANopen_Command (с сохранением) ............... 102
11.6.4вызов_Read_CANopen_Command (без сохранения)............... 102
11.6.5ответ_Read_CANopen_Command (без сохранения)................ 103
12 Передача данных для управления сообщениями CANopen .................. 103
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
12.1 Общая информация ............................................................................ 103
12.2 Формат данных сообщения ............................................................... 105
12.3 Требования для сообщений коммуникации данными
в пределах сети CANopen ......................................................................... 105
12.4 Объект 1F78h: CANopen получение данные сообщения ................... 106
13 Тест на соответствие ................................................................................... 107
Список использованной литературы .............................................................. 108
Рисунок 1 - Logical network architecture of the consist network ...................... 16
Рисунок 2 – Топология сети на базе CANopen ................................................ 16
Рисунок 3 - 9-ти контактный вспомогательный соединитель D- .................. 18
Рисунок 4-5-ти контактный микро соединитель .................................. 18
Рисунок 5 – Модель периферийного устройства............................................ 20
Рисунок 6 – Минимальное периферийное устройство ................................... 21
Рисунок 7 – структура устройства CANopen ................................................... 22
Рисунок 8 – Структура устройства по типу объекта ...................................... 24
Рисунок 9 – Структура объекта ....................................................................... 26
Рисунок 10 - Структура объекта ...................................................................... 27
Рисунок 11 - Структура объекта ...................................................................... 28
Рисунок 12 - NMT запуск, часть 1 ................................................................... 32
Рисунок 13 - NMT запуск, часть 2 ................................................................... 34
Рисунок 14 - NMT простой запуск ................................................................... 35
Рисунок 15 – Старт загрузки процесса подчиненногоNMT .......................... 36
Рисунок 16 – загрузка подчиненного NMT, часть 1 ....................................... 37
Рисунок 17 – загрузка подчиненного NMT, часть 2 ....................................... 39
Рисунок 18 - загрузка подчиненного NMT, часть 3 ........................................ 40
Рисунок 19 – Проверка конфигурации ............................................................ 42
Рисунок 20 – Проверка статуса NMT .............................................................. 43
Рисунок 21 – Старт контроля ошибки ............................................................. 45
Рисунок 22 – Обработчик ошибки ................................................................... 46
Рисунок 23 – Обработчик загрузки .................................................................. 47
Рисунок 24 – Описание потока данных в сжатом DCF.................................. 51
Рисунок 25 – Структура объекта ..................................................................... 54
Рисунок 26 – Битовая структура конфигурационного значения................... 54
Рисунок 27 – Структура значения объекта ..................................................... 56
Рисунок 28 - Битовая структура конфигурационного значения ................... 57
Рисунок 29 – Шлюз между Train backbone и сети на базе CANopen ............ 72
Рисунок 30 – Управление сообщениями (для информации) .......................... 97
Рисунок 31 – Агентовый интерфейс на базе CANopen (шлюз) ..................... 99
Рисунок 32 – Команда вызова_Write_CANopen_ .......................................... 102
Рисунок 33 – Команда ответа_Write_CANopen_............................................ 102
Рисунок 34 - Команда вызова _Read_CANopen_Command (без сохранения)
Рисунок 35 - Команда ответа _CANopen_command (без сохранения) ......... 103
Рисунок 36 - CANopen устройство, способное передать TNMсообщений.. 104
vi
103
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 37 – Сравнение формата данных сообщений .................................. 105
Таблица 1 – Соединения для 9-ти конт. Вспом. соединителя ....................... 18
Таблица 2 – соединение 5-ти контактного микро соединителя ................... 19
Таблица 3 – Побитовая синхронизация........................................................... 19
Таблица 4 – Структура словаря Объектов CANopen ..................................... 23
Таблица 5 – Описание значения....................................................................... 26
Таблица 6 - Описание объекта ......................................................................... 26
Таблица 7 - Описание ввода ............................................................................. 27
Таблица 8 - Описание значения ....................................................................... 27
Таблица 9 - Описание объекта ......................................................................... 27
Таблица 10 - Описание ввода ........................................................................... 28
Таблица 11 - Описание значения ..................................................................... 29
Таблица 12 - Описание объекта ....................................................................... 29
Таблица 13 - Описание ввода ........................................................................... 29
Таблица 14 – Статус ошибки............................................................................ 44
Таблица 15 - Описание объекта ....................................................................... 48
Таблица 16 - Описание ввода ........................................................................... 48
Таблица 17 - Описание объекта ....................................................................... 49
Таблица 18 - Описание ввода ........................................................................... 49
Таблица 19 - Описание объекта ....................................................................... 49
Таблица 20 - Описание ввода ........................................................................... 50
Таблица 21 - Описание объекта ....................................................................... 51
Таблица 22 - Описание ввода ........................................................................... 52
Таблица 23 - Описание объекта ....................................................................... 52
Таблица 24 - Описание ввода ........................................................................... 53
Таблица 25 - Описание объекта ....................................................................... 53
Таблица 26 - Описание ввода ........................................................................... 54
Таблица 27 – Значение мастера NMT master (бит: 0)..................................... 55
Таблица 28 –Значение старта всех узлов (бит: 1)......................................... 55
Таблица 29 - Значение NMT мастер старта (бит: 2) ....................................... 55
Таблица 30 –Значение стартового узла (бит: 3) ............................................ 55
Таблица 31 – Переустановка всех узлов (бит: 4) ........................................... 55
Таблица 32 – Бегающий механизм (бит: 5) .................................................... 55
Таблица 33 – Остановка всех узлов (бит: 6) .................................................. 55
Таблица 34 – Исключения для NMT запуска устройств ................................ 56
Таблица 35 - Описание объекта ....................................................................... 56
Таблица 36 - Описание ввода ........................................................................... 56
Таблица 37 - NMT подчиненный (бит: 0) ....................................................... 57
Таблица 38- NMT загрузка подчиненного (бит: 2)........................................ 57
Таблица 39 - Обязательный (бит: 3) ................................................................ 57
Таблица 40 – Перезагрузка коммуникации (бит: 4) ....................................... 57
Таблица 41 – Версия программного обеспечения (бит: 5)........................... 57
Таблица 42 – Обновление программного обеспечения (бит: 6) .................. 57
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 43 - Восстановление(бит: 7) ............................................................. 58
Таблица 44 - Описание объекта ....................................................................... 58
Таблица 45 - Описание ввода ........................................................................... 58
Таблица 46 - Описание значения ..................................................................... 60
Таблица 47 - Описание объекта ....................................................................... 60
Таблица 48 - Описание ввода ........................................................................... 61
Таблица 49 - Описание значения ..................................................................... 62
Таблица 50 - Описание объекта ....................................................................... 62
Таблица 51 - Описание ввода ........................................................................... 63
Таблица 52 - Описание объекта ....................................................................... 64
Таблица 53 - Описание ввода ........................................................................... 64
Таблица 54 - Описание объекта ....................................................................... 65
Таблица 55 - Описание ввода ........................................................................... 65
Таблица 56 - Описание объекта ....................................................................... 66
Таблица 57 - Описание ввода ........................................................................... 66
Таблица 58 - Описание объекта ....................................................................... 67
Таблица 59 - Описание ввода ........................................................................... 67
Таблица 60 - Описание объекта ....................................................................... 68
Таблица 61 - Описание ввода ........................................................................... 68
Таблица 62 - Описание объекта ....................................................................... 69
Таблица 63 - Описание ввода ........................................................................... 69
Таблица 64 - Описание объекта ....................................................................... 69
Таблица 65 - Описание ввода ........................................................................... 70
Таблица 66 - Описание объекта ....................................................................... 70
Таблица 67 - Описание ввода ........................................................................... 71
Таблица 68 – Выгрузка сервисов SDO ........................................................... 74
Таблица 69 – Загрузка параметров SDO.......................................................... 75
Таблица 70 – Конфигурация временных параметров SDO ............................. 75
Таблица 71 – Конфигурация RPDO сервисных параметров ........................... 76
Таблица 72 - Конфигурация TPDO сервисных параметров ............................ 77
Таблица 73 – Чтение сервисных параметров данных PDO ........................... 77
Таблица 74 – Написание сервисных параметров данных PDO..................... 78
Таблица 75 - RPDO полученные сервисные параметры ................................. 78
Таблица 76 – Старт сервисных параметров узла............................................. 78
Таблица 77 - Остановка сервисных параметров узла ..................................... 79
Таблица 78 – Установка предварительных сервисных параметров узла .... 79
Таблица 79 – Переустановка сервисных параметров узла .............................. 79
Таблица 80 - Переустановка сервисных параметров коммуникации ............. 80
Таблица 81 – Активация сервисных параметров защиты узла ....................... 80
Таблица 82 - Отключение сервисных параметров защиты узла ..................... 80
Таблица 83 – Старт heartbeat сервисные параметры ....................................... 81
Таблица 84 – Отключение heartbeat сервисные параметры ........................... 81
Таблица 85 – Полученные параметры контроля ошибок ............................... 81
viii
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 86 – Сервисные параметры чтения ошибки устройства ................. 82
Таблица 87 – Сервисные параметры аварийных событий .............................. 82
Таблица 88 – Инициализация сервисных параметров шлюза ....................... 82
Таблица 89 – Сохранение конфигурации сервисных параметров................. 83
Таблица 90 – Восстановление конфигурации сервисных параметров .......... 83
Таблица 91 - Установка сервисных параметров heartbeat .............................. 83
Таблица 92 – Установка сервисных параметров идентификатора узла ....... 84
Таблица 93 - Старт аварийных сервисных параметров ................................... 84
Таблица 94 – Остановка аварийных сервисных параметров .......................... 84
Таблица 95 – Установка сервисных параметров сети по умолчанию ........... 85
Таблица 96 – Сервисные параметры старта идентификатора узла по умолчанию
............................................................................................................................. 85
Таблица 97 – Параметры сервиса получения версий...................................... 85
Таблица 98 – Синтаксис и типы данных CANopen ........................................ 86
Таблица 99 – Обозначение команд BNF........................................................... 87
Таблица 100 – Обозначение ответа................................................................... 88
Таблица 101 – Код внутренней ошибки (InEC) .............................................. 88
Таблица 102 – Обозначение событийных сообщений ................................... 88
Таблица 103 – Синтаксис для загружемых SDO команд................................ 89
Таблица 104 – Образцы загрузки команд SDO ............................................... 89
Таблица 105 – Синтаксис для загрузки команды для SDO.............................. 89
Таблица 106 – Примеры для загрузки команды SDO ...................................... 89
Таблица 107 – Синтаксис для конфигурации SDO временной команды ....... 89
Таблица 108 - RPDO команды ........................................................................... 90
Таблица 109 – Примеры для конфигурации RPDO команды ......................... 90
Таблица 110 - Синтаксис для конфигурации TPDO команды ........................ 90
Таблица 111 – Примеры для конфигурации TPDO команды .......................... 90
Таблица 112 – Синтаксис для чтения PDO данные команды ......................... 91
Таблица 113 – Ответ синтаксиса для чтения PDO данные команды .............. 91
Таблица 114 - Синтаксис для написания PDO данные команды .................... 91
Таблица 115 - Синтаксис для получения команды RPDO ............................... 91
Таблица 116 – Примеры для получения RPDO команды ............................... 91
Таблица 117 - Синтаксис для старта команды узла ....................................... 91
Таблица 118 - Синтаксис для остановки команды узла ................................. 92
Таблица 119 - Синтаксис установки узла для подготовительной команды... 92
Таблица 120 - Синтаксис переустановки команды узла ................................ 92
Таблица 121 - Синтаксис переустановки коммуникации узла ....................... 92
Таблица 122 - Синтаксис включения команды защиты узла ......................... 92
Таблица 123 - Синтаксис отключения команды защиты узла ........................ 93
Таблица 124 - Синтаксис старта heartbeat команды ........................................ 93
Таблица 125 - Синтаксис отключения heartbeat команды ............................... 93
Таблица 126 - Синтаксис команды события контроля ошибки ..................... 93
Таблица 127 - Синтаксис команды чтения ошибки ......................................... 94
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 128 - Синтаксис команды аварийного сообщения ............................ 94
Таблица 129 - Синтаксис для инициализации шлюзной команды ................ 94
Таблица 130 – Индекс диапазона бита ............................................................ 94
Таблица 131 - Синтаксис сохранения команды конфигурации ...................... 95
Таблица 132 – Определитель хранения........................................................... 95
Таблица 133 - Синтаксис команды восстановления конфигурации............... 95
Таблица 134 - Синтаксис установки команды heartbeat .................................. 95
Таблица 135 - Синтаксис установки команды идентификатора узла............. 95
Таблица 136 - Синтаксис установки команды сети по умолчанию................ 96
Таблица 137 - Синтаксис установки команды идентификатора узла по умолчанию
............................................................................................................................. 96
Таблица 138 - Синтаксис получения версии команды .................................... 96
Таблица 139 – ответ Синтаксис получения версии команды ........................ 96
Таблица 140 – Пример получения версии ответа ............................................ 97
Таблица 141 – Структура управления сообщениями ...................................... 99
Таблица 142 - CANopen специальные SIF_коды .......................................... 100
Таблица 143 - Обозначения для ответа CANopen управления сообщениями
100
Таблица 144 – Обозначения для ответа CANopen управления сообщениями
100
Таблица 145 - TNM CANopen сервисные командные коды (требуется сохранение)
........................................................................................................................... 101
Таблица 146 - TNM CANopen сервисные командные коды (не требуется сохранение)
........................................................................................................................... 101
Таблица 147 - Описание значения для Call_Write_CANopen_Command.... 102
Таблица 148 - Описание значения для Reply_Write_CANopen_Command . 102
Таблица 149 - Описание значения для Call_Read_CANopen_Command (без
сохранения) ...................................................................................................... 103
Таблица 150 – Описание значения для Reply_Read_CANopen_Command
(без сохранения) 103
Таблица 151 - Описание объекта ................................................................... 106
Таблица 152 - Описание ввода ....................................................................... 106
x
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Предисловие
1) Международная электротехническая комиссия (МЭК) является всемирной
организацией по стандартизации, в состав которой входят все национальные
электротехнические комитеты (Национальные комитеты МЭК). Цель МЭК
заключается в продвижении международного сотрудничества по всем вопросам,
касающимся стандартизации в области электроники и электричества. В этой связи и
в дополнении к другим функциям, МЭК разрабатывает Международные стандарты,
Технические спецификаций, Технические отчеты, Общедоступные технические
условия (ОТУ) и Руководства (именуемые далее как «Пособия МЭК» ). Подготовка
данных публикаций возложена на технические комитеты; в случае, если один из
Национальных комитетов МЭК проявит интерес для участия в рассмотрении вопроса,
то могут принять участие в подготовительной работе. Международные,
государственные и негосударственные организаций, поддерживающие связь с МЭК
также могут принять участие в их подготовке. МЭК тесно сотрудничает с
Международной организацией по стандартизации (ИСО) согласно условиям,
определенным соглашением между данными двумя организациями.
2) Официальные решения или соглашения МЭК по техническим вопросам
выражает, можно сказать, международный консенсус по актуальным вопросам, так
как в каждом техническом комитете имеются представители из всех
заинтересованных Национальных комитетов МЭК.
3) Пособия МЭК разработаны в форме рекомендаций для всемирного
применения и признаны Национальными комитетами МЭК в таком же смысле.
Принимая во внимание, что приняты все разумные меры для обеспечения
достоверности технического содержания пособий МЭК, Международная
электротехническая комиссия не может нести ответственность за метод их
применения или за неправильное толкование содержания конечным пользователем.
4) В целях совершенствования единообразие на международном уровне,
Национальные комитеты МЭК приняли на себя ответственность применять пособий
МЭК максимально прозрачно в публикациях, издаваемых в их государствах и
регионах. Любое расхождение между пособием МЭК и соответствующим
национальным или региональным пособием должно быть четко изложено в
последнем.
5) МЭК самостоятельно не проводит никакие аттестации на соответствие.
Независимые сертификационные органы оказывают услугу по аттестации на
соответствие, и в некоторых случаях, оценивают согласно меркам соответствия МЭК.
МЭК не несет ответственность за услуги, оказываемые независимым
сертификационными органами.
6) Все пользователи должны удостовериться, что имеют обновленное издание
пособия.
7) Ни МЭК и ни ее директора, работники, служащие или агенты, включая
индивидуальных экспертов и членов технических комитетов, также членов
национальных комитетов МЭК не могут быть привлечены к ответственности за
ущерб здоровью личности, порчу имущества или за нанесение вреда любого
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
характера, нанесенного напрямую или косвенно, или за издержки (включая
вознаграждения за юридические услуги) и расходы, возникшие в связи с
применением или на основе данного Пособия МЭК или любого другого пособия
МЭК.
8) Основное внимание уделяется нормативным ссылкам, указанным в данном
пособии. Применение указанных пособий необходимо для правильного
использования данного пособия.
9) Обращая внимание на возможность, того, что некоторые элементы
настоящего пособия МЭК могут подлежать патентному праву. МЭК не несет
ответственности для идентификации какого- либо патентного права.
Международный стандарт IEC 61375-3-3 был разработан 9-м техническим
комитетом МЭК: Электрическое оборудование или системы для железных дорог.
Текст данного стандарта основан на следующих документах:
Окончательная
Отчет
по
версия
голосованию
9/1646/FDIS
9/1670/RVD
международного
Полная информация по голосованию для утверждения данного стандарта
стандарта FDIS
доступна в отчете по голосованию,
указанном в таблице.
Данное пособие спроектировано согласно с Директивами ISO/IEC, Часть 2.
Список всех глав серии 61375 МЭК, под общим названием «Электронное
оборудование для железных дорог- Сеть поездной связи» доступен на сайте МЭК.
12
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
ВВЕДЕНИЕ
TCN (сеть поездной связи) - Международный стандарт, нацеленный на
определение интерфейсов, чтобы достигнуть совместимости программного
расширения:
a) между оборудованием, расположенным в различных транспортных средствах
или, входящим в их состав, и
b) между оборудованием и устройствами, расположенными в пределах того же
самого транспортного средства или, входящим в их состав.
Один из ключевых факторов успеха для эксплуатации любой технологии
является стандартизация и обеспечение совместимости между различными
оснащениями. В целях упрощения совместимости необходимо провести тест на
соответствие.
В этой части IEC 61375 TCN касается:
включает сеть, основанная на CANopen.
Кроме того, рассматривается шлюз между магистрали поезда и сетью,
основанной на CANopen.
Настоящий стандарт состоит из 13 пунктов.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН
Транспорт железнодорожный
ЭЛЕКТРОННОЕ ОБОРУДОВАНИЕ ДЛЯ ПОДВИЖНОГО СОСТАВА
ЖЕЛЕЗНЫХ ДОРОГ.
СЕТИ ПОЕЗДНОЙ СВЯЗИ (TCN).
Часть 3-3: Сеть CANopen (CCN)
Дата введения
1 Область применения
Данная глава МЭК 61375 определяет данные по устройству управления
передачей данных между подсистемами с процессорной коммутацией, которое
основано на CANopen. CANopen был разработан для применения внутри
промышленных автоматических устройств, но не ограничено только этим. Данные
устройства могут включать приборы такие как, модули входа/ выхода, контроллера
управления движением, человеко- машинный интерфейсы, сенсоры
В прикладной области CANopen железнодорожных транспортных средств сети
используются вместе с сетевыми подсистемами, например, система управления
тормозом, система управления дизельного двигателя и система управления
наружного освещения или внутреннее освещение. Кроме того, CANopen
используется, как сеть, позволяющая обмен данными между различными
подсистемами в пределах одного единственного железнодорожного транспортного
средства или группы железнодорожных транспортных средств, подключенных к
одной сети.
Данный раздель IEC 61375 распространяется ко всему оборудованию, и
устройствам, управляемым сетью CANopen, в пределах структуры TCN, согласно IEC
61375-1.Применимость этого стандарта к внедрению TCN, позволяет осуществить
проверку на соответствие самого внедрения и является предпосылкой для
дальнейшей проверки совместимости между различными внедрениями TCN. В
любом случае доказательство совместимости между Train Backbone и Сетью должно
быть получено от поставщика.
Настоящая часть IEC 61375 относится к структуре систем связи в Открытых
поездах. Кроме того, это может быть применимо к закрытым поездам и
многосоставным поездам, когда имеется согласованность между покупателем и
поставщиком.
2
Нормативные ссылки
В данном документе указаны ссылки на полное содержание или на какую – либо
часть следующих нормативных документов и они являются необходимыми для
применения данного документа. Датированные ссылки используются только
14
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
относительно данного пособия. Недатированные ссылки используются для последних
изданий указанных документов (включая любые дополнения).
IEC 61131 (все главы): Программируемое устройство управления
IEC 61375-1, ed3, Электронное оборудование для железных дорог – Сеть
поездной связи (TCN) -Часть 1: Общая архитектура
IEC 61375-2-1, Электронное оборудование для железных дорог – Сеть
поездной связи (TCN) –Часть 2-1: Проводная шина поезда (WTB)
IEC 61375-2-2, Электронное оборудование для железных дорог – Сеть
поездной связи (TCN) -Часть 2-2: WTB – Проведение теста на соответствие
проводной шины поезда ISO/IEC 646:1991 Информационная технология - ISO 7битовые кодовые знаки, установленные для обмена информациями
ISO/IEC 9899:1999, Язык программирования - C
ISO 11898-1:2003, Автодорожные транспорты – Локальная сеть
контроллеров (CAN) - Часть 1: Уровень передачи данных и физический сигнал
ISO 11898-2:2003, Автодорожные транспорты – Локальная сеть
контроллеров (CAN) - Часть 2: Высокосоростной
блок доступа к среде передачи данных
EN 50325-4:2002, Промышленные коммуникационные подсистемы основаные
на ISO 11898 (CAN) для котроллеров интерфейсных приборов - Часть 4: CANopen
3 Термины, определения и аббревиатуры
3.1 Термины и определения
В целях настоящего документа, термины и определения, указанные в SO
11898-1,
ISO 11898-2, IEC 61375-1, IEC 61375-2-1 and EN 50325-4, также
применяются.
3.1.1 ASCII
7-битовые кодовые знаки, установленные согласно ISO/IEC 646
3.1.2 Прибор CANopen
Конечное устройство, соединенное с сетью, основанной на базе CANopen
3.1.3 Периферийное устройство
Независимый
физический
объект
автоматизированной
системы,
присоединенный к сети, который может выполнять специфические функций в
определенных контекстах и ограничен интефейсами
3.1.4 Логическая сеть
Способ передачи данных через сеть, без учета физического соединения
конечных устройств
3.1.5 Логическое устройство
Представление периферийного устройства относительно их объектов и свойств
соответственно модели периферийных устройств, который определяет данные и
свойства, рассматриваемые через сеть
3.1.6 Сервисы настройки уровней
Сервисы для урегулирования скорости передачи бита и Идентификатор узла
через коммуникационные интерфейсы устройства CANopen
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
3.1.7 Идентификатор узла
a) Общесетевой уникальный идентификатор для каждого устройства CANopen
b) 7-битовый кодовые адреса устройств в сетях на базе CANopen
3.1.8 объект
Объект с четко определенными границами и идентичность, которая включает
свойства и состояние
3.1.9 Виртуальное устройство
Объект программного обеспечения, выполняющий функциональный элемент
периферийного устройства
3.2 Аббревиатуры
В целях настоящего документа, аббревиатуры, указанные в ISO
11898-1, ISO 11898-2, IEC 61375-1, IEC 61375-2-1 и EN 50325-4, также
применяются.
ASCII Американский стандартный код обмена информации
BNF нормальная форма Бэкуса-Наура
CAN Сеть контроллера
CPU Центральный процессор
CR Возврат каретки
CRLF Возврат каретки и загрузка линии связи
DCF Конфигурационный файл устройства
FSA Конечный автомат
ID
Идентификатор
LF
Загрузка лини связи
LSS Сервисы настройки уровней
NMT Управление сетью
OSI Взаимодействие открытых систем
PAS сервис доступа к цифровой транкинговой системе
PDO Объект обработки данных
SAS система доступа к частотному спектру
SRD устройство запроса объектов сервисных данных
3.3
Условные обозначения
Условные обозначения, содержащиеся в IEC 61375-1 будут применены.
4 Структура
4.1
Content
Данная глава посвящена описанию структуры сетей на база CANopen.
4.2
Логическая сеть на базе CANopen
Общая логическая сеть на базе CANopen соединяющая несколько
Виртуальных устройств иллюстрирована в рисунке 1. consist network,
connecting several Virtual Devices, is illustrated in Рисунок 1. Логическая сеть
на базе CANopen соединяет между собой несколько Виртуальных устройств,
такие как, система эксплуатации (TOS), Система мониторинга и безопасности
16
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
(MSS), Вспомогательная операционная система (AUX), система питания (PDS),
Система ходовой части (RGS), система контроля тормоза (BCS),
вспомогательная операционная система (ANC), система соединения
автотранспорта (VLS), система наружного освещения (ELS), система
внутреннего освещения (ILS), Система контроля двери (DCS), система
вентиляции и кондиционирования (HS), Система оповещения пассажиров (PIS),
Диагностическая система (DS), или коммуникационная система поезда (TCS).
Логическая сеть на базе CANopen связана с основной системой связи
поезда через шлюз. Шлюз управляет обменом информации также как и
обработкой данных между основной системой связи поезда и сетью.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 1 – логическая сетевая структура основной сети
4.3 Топология сети
Топология сети должна быть максимально аналогична со структурой
единственной линии, имеющая оконечные резисторы с обеих сторон сети, как
установлено в ISO11898-2. Общая длина сети не должна превышать 450 м, если
используемая скорость передачи составляет 125 кбит/с.
Общая длина шлейфа не должна превышать 110м, а The accumulated stub
length shall not exceed 110 м, и длина согласующего шлейфа не должна превышать
м, если используемая скорость передачи составляет 125 кбит/с. Рекомендуется
поддерживать максимально короткую длину шлейфа. It is recommended to keep the
stub lengths as short as possible. Чипы трансивера CAN не должны быть
гальванически развязанными. Оптосоединители установлены между котроллером
CAN и трансивером CAN. Это влияет на максимальную длину шлейфа в
зависимости от задержки распростронения оптосоединителей. Оконечные
резисторы с обеих сторон линии шлейфа не должны превышать 120 Q .
Топология сети иллюстрирована в Рисунке 2.
i
CAN GND
i
Рисунок 2 – топология сети на базе CANopen
4.4 Адресация
Любое конечное устройство, соединенное с сетью на базе CANopen требует
уникальный идентификатор узла в масштабе от 01 h до 7Fh. Идентификатор узла
CANopen регулируется через выключатели комплектующего или через программное
обеспечение. В случае, если идентификатор узла CANopen регулируется через
коммуникационный интерфейс устройства, то будут использованы сервисы
настройки уровней CANopen.
Идентификатор узла на базе CANopen настраивается через словарь объектов
соответствующего устройства.
Определение сервисы настройки уровней (LSS )не входит в область
18
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
рассмотрения данного стандарта.
Примечание - LSS указаны в документе CiA 305.
4.5 Классы данных
Для обмена содержательной информацией через сеть на базе CANopen,
необходимо чтобы формат данных и их содержание было известно производителю и
потребителю(-лям). Данная спецификация определяет посредством концепта -based
Consist Network, it is necessary that the format of this data and its meaning is known by the
producer and the consumer(s). This specification models this by the concept of data types.
Правила кодирования определяют представления значений типов данных и
трансформируют синтаксис для представления. Значения представлены как битовая
комбинация. Битовая комбинация переданы в комбинациях октетов (байтов). Для
цифровых типов данных кодирование производится в порядке следования байтов.
Приложениями часто требуются типы данных вне зависимости от типа исходных
данных. Используя составной механизм типа данных, имеется возможнось расширить
список доступных типов данных. Некоторые общие расширенные типы данных
определены как "Видимая Последовательность" или "Время суток". Составные типы
данных являются средствами для определения пользователем "DEFTYPES" , а не
"DEFSTRUCTS" в терминологии EN 50325-4. Необходимо применять правила
кодирования, указанные в EN 50325-4.
5 Физический уровень
5.1
Содержание
Данная глава содержит определения для физического уровня для сети на основе
CANopen.
5.2
Укладка кабеля
Главная магистральная линия связи должна быть, по крайней мере,
единственной витой парой номинального характеристическим импедансом, как
определено в ISO 11898-2. Кроме того, необходимо применить линию
CAN_Ground в качестве точного уровня отчета для CAN_H и уровня напряжения
CAN_L.
Согласно рекомендации, те устройства, которые соединены с сетью на
CANopen поддерживают 9-ти контактный вспомогательный соединитель D или 5-ти
контактный микро соединитель (M12). Соединители иллюстрированы в Рисунке 3 и
Рисунке 4. 9-ти контактный вспомогательный соединитель D поддерживает
соединение как указано таблице №1. 5-ти контактный микро соединитель (М12)
поддерживает соединение как указано в таблице 2. Так как устройства CANopen
должны быть гальванически развязанными, дополнительно можно применить линию
V+ только для подачи питания для блока приемопередатчика и оптосоединителя
CAN.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 3 - 9-ти контактный вспомогательный соединитель D
Таблица 1 – Соединение для 9-ти контактного вспомогательного соединителя D
кон
так
1
2т
3
4
5
6
7
8
9
сигнал
Описание
Зарезервирован
шлейф CAN_L (доминирующий низкий)
CAN ground
Зарезервирован
Дополнительная защита CAN
Дополнительная площадь
шлейф CAN_H (доминирующий высокий)
Зарезервирован
Дополнительная CAN внешняя положительная подача
питания(предназначенная для подачи питания
приемопередатчика и оптосоединителей для
гальваническим образом изолированных шлейфов)
Примечание - строго рекомендуется не соединять CAN_GND и GND.
CAN_L
CAN_GND
(CAN_SHLD
)(GND)
CAN_H
(CAN_V+)
В случае, если потребуется защита, рекомендуется соединить щит через
металлический корпус используемого соединителя. Дополнительно может быть
использован штырь CAN_SHLD.
Рисунок 4 - 5-ти контактный микро соединитель
Таблица 2 - Соединение 5-ти контактного микро соединителя
20
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
кон
сигнал
Описание
так
1 (CAN_SHLD) Дополнительная защита CAN
Дополнительная CAN внешняя положительная подача
2т (CAN_V+)
питания(предназначенная для подачи питания
приемопередатчика и оптосоединителей для
гальваническим образом изолированных шлейфов)
Ground / 0V / V3 CAN_GND
CAN_H шлейф (доминантный высокий)
4 CAN_H
CAN_L шлейф (доминантный низкий)
5 CAN_L
5.4 Подсоединение к физической среде
Физическая среда для устройства, связанного с сетью на базе CANopen, должна
быть дифференцированно управляемым двухпроводным шлейфом с обратным
проводом согласно высокоскоростной спецификации передачи в ISO 11898-2.
Используя высокоскростной приемопередатчик согласно ISO 11898-2
максимальные показатели для VCAN H и VCAN L должны составить +16 В.
Гальваническая изоляция между устройствами CANopen является дополнительной.
Рекомендуется использовать приемопередатчик CAN, который способен поддержать
неправильное соединение любых проводов соединителя, включая, дополнительные V +
с напряжением до 30 В.
5.5 Физическая передача сигналов
Кодирование/расшифровка и синхронизация бита должны соотвествовать
требованиям, определенным в ISO 11898-1.
Побитовая синхронизация должна соответствовать требованиям, определенным в ISO
11898-1 и определениям, указанным в Таблице 3. Рекомендуемое местоположение
выборочных точек максимально близко к 87,5% соответствующей побитовой
синхронизации.
Таблица 3 – Побитовая синхронизация
Скорость
передачи
1 Mбит/с
800 kбит/с
500 kбит/с
250 kбит/с
125 kбит/с
50 kбит/с
20 kбит/с
10 kбит/с
Номинальны
Допустимый
й интервал
диапазон для
передачи
местоположения
бита
выборочной
75 до 90точки
1 tb
US
1,25
75 %
до 90
85 до 90
2
85 до 90
4
85 до 90
8
85 до 90
20
85 до 90
50
85 до 90
100
Устройства, соединенные с сетью на базе CANopen должны поддерживать
скорость передачи 125 кбит/с. Дополнительно приемлемые скорости передачи указаны
в таблице 3.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
6 Уровень канала передачи данных
6.1 содержание
Данный раздел содержит определения для уровня передачи данных на основе
CANopen .
6.2 Уровень канала передачи данных CANopen
Вышеупомянутая сеть на базе CANopen должна быть основана на уровне канала
связи и его подуровнях согласно ISO 11898-1.
Эта спецификация основана на формате структуры CAN с 11-битным CAN ИДЕНТИФИКАТОРОМ. Поэтому, не требуется поддерживать расширенный формат
структуры CAN с 29-битным CAN -ИДЕНТИФИКАТОРОМ.
Примечание - Поскольку определенные приложения требуют, чтобы при использовании
расширенных форматов CAN, сеть может управляться в таком же режиме также, при условии, что все
соединенные устройства CANopen поддерживают данный формат.
7 уровень приложения CANopen
7.1 содержание
Данный раздел содержит определения, связанные с базовыми моделями
высокого уровня ISO OSI сетями на базе CANopen.
7.2 Базовые модели
Устройства соединенные с сетью на базе CANopen, соответствующие данной
спецификации должны использовать базовую модель, как указано в EN 50325-4.
7.3 Модель периферийного устройства
Устройства, соединенные с сетью на базе CANopenдолжны соответствовать
модели периферийного устройства как указано в Рисунке 5.
22
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 5 – модель периферийного устройства
Периферийное устройство, как иллюстрировано в рисунке 5 должно снабжать по
крайней мере одно устройство CANopen. Каждое устройство CANopen в пределах
периферийного устройства должно снабжать, как минимум, один подсоединенный
сетевой интерфейс, включающий протокол уровня канала связи (см. Пункт 6),
физический уровень (см. Пункт 5), одного ID узла CANopen и как минимум, одну
коммуникацию FSA. Первая коммуникация FSA содержит подчиненный механизм
NMT, как определено в EN 50325-4. Дополнительные коммуникационные FSAs
содержат механизм для аварийного режима (см. EN 50325-4), и другие. Устройство
CANopen должно поддерживать, по крайней мере, один и в то же время, должно иметь
возможность поддержать до восьми логических устройств. Каждое логическое
устройство может содержать много виртуальных устройств и дополнительно может
содержать логическое устройство FSA. Виртуальное устройство содержит
виртуальное устройство FSA и не распространяется по нескольким логическим
устройствам. Минимальное периферийное устройство указано в рисунке 6.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 6 – Минимальное периферийное устройство
Устройство CANopen устроено как указано в Рисунке 7:
• Коммуникация - данная функция обеспечивает коммуникационные объекты и
соответствующую функциональность для передачи элементов данных через
основную сетевую структуру.
• Словарь объекта - словарь объекта - коллекция всех элементов данных, которые
имеют влияние на свойства прикладных объектов, коммуникационные объекты и на
механизм состояний, используемый на данном устройстве.
Приложение - приложение включает функциональность устройства относительно взаимодействия
с окружающей средой процесса.
Рисунок 7 – структура устройства CANopen
24
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
7.4 коммуникационные объекты CANopen
Устройства, соединенные с сетью на базе CANopen должны поддерживать все
обязательные коммуникационные объекты, такие как механизм состояний CANopen
как указано в EN 50325-4.
Чтобы уменьшить влияние конфигурации на простых сетей CANopen,
определена схема распределения CAN-ID. Эти CAN-ID должны быть доступными в
Предпусковом состоянииNMT, непосредственно после того, как NMT настроится на
Инициализацию (если другие модификации не были сохранены). Объекты укажут
SYNC, TIME, EMCY и PDO может быть удален и воссоздан с новыми SYNC, TIME,
CAN -ID посредством динамического распределения. Устройство CANopen должно
предоставить соответствующие CAN-ID только для поддерживающих
коммуникационных объектов. Схема распределения МОЧЬ-ID определена в EN
50325-4.
7.5 словарь объектов CANopen
Словарь объекта CANopen, как определено в EN 50325-4, содержит максимум
65536 объектов, которые адресуются посредством 16-битного индекса и до 256
субиндексов за объект, которые адресуются посредством 8-битного субиндекса.
Статические типы данных в индексах от 0001 h до 001 Fh содержат определения
относительно стандартных типов данных как BOOLEAN, INTEGER, UNSIGNED,
плавающая запятая, последовательность, и т.д.
Сложные типы данных в индексах от 0020h to 003Fh являются предопределенными
структурами, которые состоят из стандартных типов данных и характерны для всех
устройств CANopen.
Определенные для изготовителя сложные типы данных в 0040h до 005Fh - структуры,
составленные из стандартных типов данных, но определенные для особого
устройства CANopen.
Профили устройства CANopen могут определить дополнительные типы
данных, определенные для их типа устройства. Статические типы данных и сложные
типы данных, определенные профилем устройства CANopen, перечислены в
индексах от 0060h до 025Fh.
Устройство
CANopen
дополнительно
обеспечивает
структуру
поддерживаемых сложных типов данных (индексы от 0020h до 005Fh и от 0060h до
025Fh) в читаемом доступе к соответствующему индексу. Субиндекс 00h затем
предоставляет самый высокий подиндекс, в пределах данного индекса, и следующие
подиндексы содержащие тип данных, зашифрованные как UNSIGNED16 согласно
EN 50325-4.
Коммуникационная область профиля в индексах от 1000h до 1FFFh определенные
параметры коммуникации. Данные объекты характерны для всех устройств
CANopen.
Стандартизированная область профиля в индексах от 6000h до 9FFFh содержит
все объекты данных, характерные для класса устройств CANopen, которые могут
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
быть прочитаны или написаны посредством сети. Устройство CANopen представляет
объекты использования от 6000h to 9FFFh, чтобы описать параметры и
функциональность.
Принцип словаря объекта выполнение дополнительных функций, что означает,
что изготовитель может не обеспечивать определенную расширенную
функциональность на своих устройствах CANopen, но если он хочет сделать так, то
он должен сделать это предопределенным способом. Для этого оставляют
пространство в словаре объекта в индексах от 2000h до 5FFFh, предназначенное для
создания определенной функциональности для изготовителя.
Сетевые переменные в индексах от A000h до AFFFh содержат входные
переменные и выходные переменные, которые являются частью программируемого
устройства CANopen.
Системные переменные в индексах от B000h до BFFFh содержат входные
переменные и выходные переменные, которые являются частью основной сети
CANopen в иерархическом смысле.
Общая структура словаря объекта CANopen иллюстрирована в Таблице 4.
Таблица 4 – структура словаря объектов CANopen
индекс
0000h
0001 h
0020h
0040h
-001F h
- 003Fh
- 005Fh
Объект
Не используется
Статические типы данных
Комплексные типы данных
Определенные комплексные данные для производителя
0060h
- 025Fh
Определённые типы данных соответственно профилю устройства
0260h
0400h
1000h
2000h
6000h
6800h
7000h
7800h
8000h
8800h
-03FF h
-0FFF h
-1FFF h
-5FFF h
-67FF h
-6FFF h
-77FF h
-7FFF h
-87FF h
-8FFF h
Зарезервирован
Зарезервирован
Коммуникационный профиль
Специальный профиль для производителя
Стандартный профиль 1-го Логического устройства
Стандартный профиль 2-го логического устройства
Стандартный профиль 3-го логического устройства
Стандартный профиль 4-го логического устройства
9000h
-97FF h
Стандартный профиль 6-го логического устройства
9800h
A000h
B000h
C000h
-9FFF h
-AFFF h
-BFFF h
-FFFF h
Стандартный профиль 7-го логического устройства
Стандартная Регулируемая площадь
Стандартная Регулируемая площадь
Зарезервирован
26
Стандартный профиль 5-го логического устройства
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
7.6 Предопределенные коммуникационные объекты CANopen
7.6.1 содержание
Данный раздел содержит информацию относительно коммуникационных
возможностей CANopen относительно устройств CANopen, которые принимают
участие в сети на базе CANopen согласно спецификации.
7.6.2 Объект 1000h: тип устройства
Этот объект представляет тип устройства и его функциональности. Значение
0000h относительно числа профиля устройства указывает на логическое устройство,
которое не соответствует стандартизированной профили. В этом случае
дополнительная информация 0000h (если никакое другое логическое устройство не
разработано), или FFFFh (если разработано логическое устройство уствновлено).
Для многократных логических модулей устройства параметр дополнительной
информации - FFFFh, и число профиля устройства, на которое ссылается 1000h объект,
является профилем первого логического устройства в словаре объекта. Все другие
профили многократного логического модуля устройства определяют свои профили в
объектах 67FFh + x * 800h ,где = внутреннее число логического устройства (от 1 до 8)
минус 1. Данные объекты описывают тип устройства предыдущего логического
устройства, имея то же самое определение значения как объект1000h.
Рисунок 8 иллюстрирует структуру объекта. Определение значения, описание
объекта и описание входа определены в EN 50325-4.
31
24 23
16 15
Дополнительная
Номер профиля
информация
устройства
MSB
Рисунок 8 – структура объекта устройства
0
LSB
Примечание - Устройства, связанные с сетью на базе CANopen, могут соответствовать с
профилем приложения CANopen для сетей CiA 421для контроля за транспортным
средством поезда. Этот прикладной профиль CANopen определяет данные приложения,
основанные на UIC 556, который обмениваются в сети CANopen.
7.6.3 Объект 1001h: Реестр ошибок
Этот объект предоставляет информацию об ошибке. Устройство CANopen
вносит внутренние ошибки на этот объект. Информация об ошибке публикуется как
часть чрезвычайного сообщения. Определение значения, описание объекта и описание
входа определены в EN 50325-4.
7.6.4 Объект 1014h: COB-ID чрезвычайный объект
Данный объект должен быть разработан. Он указан EN 50325-4. CAN-ID,
который является частью данного объекта, не будет изменена.
7.6.5 Объект 1017h: производитель Heartbeat
Все устройства CANopen, соединенные с сеть на базе CANopen-должны
выполнить данный объект. Об этом прописано в EN 50325-4.
Устройство должно поддержать передачу heartbeat сообщения от 100 ms до 1 000
ms.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
7.6.6 ОБъект 1018h: Идентификационный объект
Данный объект предоставляет общую информацию по устройствам как указано
в 50325-4.
7.6.7 Объект1029h: Свойство ошибок
Данный объект определяет на какое состояние настроено устройство, в случае
коммуникационной ошибки или ошибки внутри устройства, определяет ошибки.
Данное указано в EN 50325-4.
28
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
7.6.8 Объект 67FFh: тип устройства
Данный объект описывает первое логическое
многочисленного устройства согласно EN 50325-4.
устройство
в
модуле
7.6.9 Сервисный объект данных (SDOs)
Любое устройство CANopen поддерживает первый канал сервера SDO.
Устройства CANopen, связанные с сетью CANopen, могут поддержать
дополнительный сервер SDO или каналы клиента.
В случае, если дополнительный канал SDO поддерживается, то связанный
набор параметра SDO поддерживается в словаре объекта CANopen, как определено в
EN 50325-4.
Не имеются больше каналов SDO, предопределенные данной спецификацией.
7.6.10 Процессные данные объекта (PDOs)
Устройства CANopen, работающие в сети CANopen могут поддержать
передачу и прием до 512 PDO.
Если устройство CANopen поддерживает PDO, то связанные коммуникационные
параметры PDO и элементы отображения поддерживаются в объекте словарей
CANopen как укзано в EN 50325-4.
Предопределенных PDOs не имеются.
8 Данные приложения
8.1 содержание
Данный раздел содержит представление данных приложений, которые
передаются между сетью на базе CANopen- Train Backbone посредством шлейфа.
Примечание -1 Данные о приложении указаны в профиле приложения TCN.
В общих данных приложении объектов CANopen индексы достигают 2000h до
5FFFh и 6000h до 9FFFh. Специфическое свойство устройства производителя
контролируется посредством объектов в пределах индексов от 2000h до 5FFFh.
Стандартное устройство CANopen контролируются объектами в пределах индексов
от 6000h до 9FFFh.
Примечание - 2 Объект словарей в пределах индексов от 6000h до 9FFFh указаны в устройстве
CANopen и профили приложении доступны в CAN Automation.
8.2 приложение и представление CANopen
Так как данные приложения TCN до сих пор не определены, представление
приложения TCN в стандартном словаре объектов предел индексов не определен.
8.3 Рекомендуемое представление принципа данных приложении
8.3.1 Содержание
В этом разделе принцип представления данных приложения указан для
представления данных приложения в сети CANopen. Поэтому имеется возможность
контроля процесса объектов данных CANopen (PDOs) для передачи данных процесса.
8.3.2 Данные приложения для контроля двери
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Данный раздел содержит представление принципа посредством информации
контроля двери, которое переходит между сетью CANopen и train Backbone с
помощью шлейфа.
Представленные обрабатанные данные также доступны в сети CANopen и
может быть сообщен через коммуникационные объекты CANopen.
Тип доступа предоставлен для интерфейса устройства шлюза, находящегося
в сети CANopen. Другие устройства такие как, например, системы управления
дверями или дверные единицы, которые связаны с данными в сети CANopen, как
определено в этом пункте в данном индексе словаря объекта CANopen. Тип доступа
объекта может быть изменен на соответствующий тип доступа, как определено в
EN 50325-4.
Примечание - иллюстрированные данные приложения получены на основании документа UIC
556 и даны в представлении прикладного профиля CANopen CIA 421 сеть контроля за
транспортным средством поезда.
8.3.3 Потребляемые прикладные объекты по контролю двери
8.3.3.1
Объект 6007h: Словесное изложение Статуса внешней двери
Данный объект показывает статус внешних дверей местного
железнодорожного транспорта. Через шлюз Train Backbone, данная информация
доступна в TCN. Рисунок 9 показывает объекты структы и таблица 5 определяет
значения. Таблица 6 описывает объекты и Таблица 7 показывает входное описание.
Примечание - Объект должен соответствовать R3-телеграмному октету 20, который указан в UIC
556.
7
Bit 7
6
сохране
н
5
4
Bit 5
Bit 4
3
0
сохранен
MSB
LSB
Рисунок 9 – Структура объекта
Таблица 5 – Описание значения
Бит
Бит4
Бит 5
Бит7
сохранен
30
значени
0е
1
0
1
0
1
Описание значения
только одна левая дверь открыта
Все левые двери закрыты
только одна правая дверь открыта
Все правые двери закрыты
Селективная блокировка боковых дверей не
действует блокировка боковых дверей
Селективная
действует
резервирован
(игнорируется)
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 6 – Описание объекта
Описание
Индекс
Название
Код объекта
Тип данных
Категория
Значение
6007h
Словесное изложение статуса внешних
дверей
изменчивый
UNSIGNED8
Выборочный
Таблица 7 – Описание входа
Описание
Субиндекс
доступ
PDO контроль
Диапазон показателей
Значение по умолчанию
Значение
ººh
rw
Дополнительно
См описание значений
Специально для
производителя
8.3.4 Производные прикладные объекты контроля двери 8.3.4.1
Объект6006h: Словесное выражение статуса внешних дверей
Данный объект должен обеспечить статус внешних дверей других
железнодорожных транспортных средств. Каждый субиндекс должен обеспечить
дверной статус того транспортного средства, которое соответствует номеру
транспортного средства UIC. Поэтому внешний дверной статус других транспортных
средств доступен в пределах сети CANopen. Полный дверной статус всех
транспортных средств обеспечен в субиндексе 21 h. Рисунок 10 определяет структуру
объекта, и Таблица 8 определяет значение стоимости. Таблица 9 определяет описание
объекта, и Таблица 10 определяет значение входа.
Примечание, что объект должен соответствовать R3-телеграммы октету 20, который
определен в UIC 556.
7
6
5
4
3
0
Bit 7
reserved
Bit 5
Bit 4
reserved
MSB
LSB
Рисунок 10 – объект структуры
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 8 – Определение значения
Бит
Бит4
значени
0е
1
0
1
0
1
Бит 5
Бит7
сохранен
Описание значения
только одна левая дверь открыта
Все левые двери закрыты
только одна правая дверь открыта
Все правые двери закрыты
Селективная блокировка боковых дверей не
действует блокировка боковых дверей
Селективная
действует
резервирован
(игнорируется)
Таблица9 – описание объекта
Attribute
INDEX
Name
Object code
Data type
Category
Value
6006h
External doors status word import
ARRAY
UNSIGNED8
Дополнительный
Таблица 10 – Описание входа
Описание
Субиндекс
Описание
Входная категория
Доступ
PDO контрол
Диапазон значений
Значение по умолчанию
Субиндекс
Описание
Входная категория
00h
Поддерживается самый высокий индекс
Обязательный
ro
нет
01hдо 21h
нет
01 h
Статус двери UIC транспорта 1
Дополнительно
Доступ
PDO контроль
Диапазон значений
Значение по умолчанию
ro
Дополнительно
См Таблица 46
нет
to
Субиндекс
20h
32
Значение
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Описание
Входная категория
Доступ
PDO контроль
Диапазон значений
Значение по умолчанию
Субиндекс
Описание
Входная категория
Доступ
PDO контрол
Диапазон значений
Значение по умолчанию
Статус двери UIC транспорта 32
Дополнительно
ro
нет
Дополнительно
нет
21 h
Статус двери поезда
Дополнительно
ro
нет
Дополнительно
нет
8.3.4.2 Объект 6001 h: Команда внешних дверей
Данный объект управляет словесным контролем внешних дверей. рисунок 11
определяет объект и таблица 11 описывает значения. Таблица 12 описывает объект
и таблица 13 определяет входные данные.
Примечание, что объект должен соответствовать R3-телеграммы октету 20, который определен в UIC
556.
7
6
Reserved
Bit6
b
4
Reserved
3
2
1
0
Bit 3
Bit 2
Bit1
Bit0
MSB
LSB
Рисунок 11 – структура объекта
Таблица 11 –определение значения
бит
Бит 0
Бит 1
Бит 2
Бит 3
Бит 6
сохранен
значен
ие
0
1
0
1
0
1
0
1
0
1
Описание значения
неактивный
Все двери закрыты
неактивный
Помеха при закрывании дверей
Освободить все левые двери
Закрыть все левые двери
Освободить все правые двери
Закрыть все правые двери
Не растягивать ступень
Растянуть ступень
сохранен (игнорируется)
Таблица 12 – описание объекта
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Описание
индекс
Название
Код объекта
Тип данных
категория
значение
6001 h
Команда для внешних дверей 1
изменчив
UNSIGNED8
дополнительно
Таблица 13 – Вводное описание
Описание
индекс
Название
Код объекта
Тип данных
категория
значение
00h
ro
Дополнительно
См описание значений
нет
9 Управление сетью CANopen
9.1 содержание
Данный пункт содержит информацию относительно сетевого управления для
сети на базе CANopen. Определение сетевого управления включает определение
сетевого свойства при запуске, а также определения, которые связаны с сетями,
которые работают без NMT, сетей с одним устройством CANopen, имеющие свойства
основного способа NMT. Данные определения предназначены для дополнения
прикладного уровню CANopen и коммуникационного профиля, определенного в EN
50325-4.
CANopen сеть, имеющая более чем одно устройство CANopen, также имеющая
возможность выполнения основного режима NMT не входит в данную спецификацию.
Однако, такие сети не исключены.
Примечание - Относительно увеличенной доступности, сети CANopen могут охватить, несколько
устройств CANopen с основной функциональностью NMT. Как в определенное время, разрешается
применение только одного активного NMT, требуются механизмы, которые позволяют настигнуть
основной функциональности NMT от одного устройства CANopen до другого. Эти услуги - часть
CANopen основная функциональность, которая описана в ЦРУ 302.
9.2 подчиненная функциональность CANopen NMT
Устройства, управляемые в сети CANopen, должны обеспечить NMTподчиненную функциональность CANopen и должна выполнить все обязательные
коммуникационные услуги и протоколы, а также все обязательные объекты, как
определено в EN 50325-4. Минимальные коммуникационные объекты определены в 7.6.
Дополнительно возможно поддержать дальнейшие коммуникационные объекты. Кроме
того, можно подключить управляемую функциональность CANopen.
9.3
управляющая функциональность CANopen
9.3.1
Общая информация
Данный подпункт содержит определение управляющие функциональности сети
CANopen для сетей CANopen.
Помимо прикладного процесса несколько различных дополнительных
функциональностей существуют в сети CANopen. Эти функциональности упомянуты
34
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
различными условиями. Данный подпункт предназначен для разъяснения этих
условий.
В пределах распределенной системы прикладной процесс разделен на
несколько частей, действующих на различных устройствах CANopen. С прикладной
точки зрения обычно одно устройство CANopen ответственно за контролем системы.
Данное устройство CANopen называют прикладным мастером.
С точки зрения сети есть несколько дополнительных функциональностей,
которые непосредственно имеют дело с применением, но обеспечивают
поддерживающие применение функции. Эти дополнительные функциональности
основаны
на
мастере/подчиненного,
клиент-сервер
или
отношения
производителя/потребителя.Поскольку распространено объединение нескольких из
дополнительных функциональности в одном устройстве CANopen, то необходимо
ознакомить с термином Менеджер CANopen .
Устройство CANopen упоминается как менеджер по CANopen, если оно
обеспечивает основную функциональность NMT и по крайней мере одну из
функциональности менеджера по SDO или Менеджера конфигурации.
9.3.1.1NMT мастер
Сетевое управление (NMT) предоставляет услуги для управления свойствами
сетевых устройств CANopen, как определено в EN 50325-4. Все устройства CANopen,
которые имеются в сети CANopen, называются подчиненными рабами NMT,
управляют услугами, предоставленные мастером NMT. Обычно основное применение
NMT - также часть прикладного мастера.
Устройство, в котором имеется основная функциональность NMT, полностью
является устройством CANopen. В дополнение к основной функциональности NMT
поддерживаются все функции и объекты, которые обозначены как обязательные в EN
50325-4.
9.3.1.2
Бегущий основной механизм
Бегущий основной механизм предоставляет услуги для срочного резервного
мастера NMT в пределах сети CANopen. Бегущий основной механизм дополнительная функциональность в пределах устройства CANopen. Устройство
CANopen, осуществляющее функции бегущего основного механизма, выполняет
основную функциональность NMT. Определение обязанностей, функциональностей
и услуг бегущего механизма не входит в область рассмотрения данного документа.
Примечание, что Определения
предоставлены в Cia 302.
для
бегущего
основного
механизма функциональности
9.3.1.3
SDO менеджер
Менеджер SDO - дополнительная функциональность, ответственная за
обработку динамического установления связей SDO. Если менеджер SDO
присутствует в сети CANopen, она функционирует вместе с мастер NMT на том же
самом устройстве CANopen.
Примечание - что Определения для функциональности менеджера SDO предоставлены в CiA 302.
9.3.1.4
Менеджер конфигурации
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Менеджер конфигурации - дополнительная функциональность, которая
обеспечивает механизмы для конфигурации устройств CANopen в сети CANopen во
время начальной загрузки. Механизмы называют Управлением конфигурацией
(CMT). Если Менеджер конфигурации присутствует в сети CANopen, он
функционирует вместе с мастером NMT на том же самом устройстве CANopen.
Примечание - что Определения для функциональности менеджера конфигурации предоставлены в
CiA 302.
9.3.1.5
Синхронизирующий производитель
Синхронизирующий производитель - дополнительная функциональность,
которая ответственна за передачу синхронизирующего объекта. Он может
функционировать на любом устройстве CANopen в находящемся в сети CANopen.
Соответствующие словарные статьи объекта CANopen определены в EN 503254.SYNC производитель
9.3.1.6
Производитель ВРЕМЕНИ
Производитель ВРЕМЕНИ - дополнительная функциональность, которая
ответственна за передачу объекта ОТМЕТКИ ВРЕМЕНИ. Он может
функционировать на любом устройстве CANopen в находящемся в сети CANopen.
Объект отметки времени определен в EN 50325-4.TIME producer
9.3.1.7
LSS мастер
Услуги по урегулированию уровня (LSS) предоставляют услуги для
формирования слоя 2 (тактовая синхронизация) и NMT (ID узла CANopen) через CAN.
Владелец LSS формирует подчиненных LSS, выполняя услуги LSS. Определение услуг
по урегулированию уровня не входит в область рассмотрения данного документа.
Примечание - определения для уровня, устанавливающего услуг указаны в CiA 305.
9.3.2 Использование словарь объектов
Несколько объектов, касающихся конфигурации и проверки устройств
CANopen, имеют ARRAY типа объекта. Субиндекс записей ARRAY соответствует ID
узла CANopen устройства CANopen. Те объекты может быть меньше чем 127 записей.
В этом случае у всех этих объектов должен быть тот же самый набор поддерживаемых
записей. Субиндекс 00h должен обеспечить самый высокий субиндекс,
поддерживаемый в этом индексе. Соответственное описание объекта в Пункте 9
именуется как условие SupportedNodeID.
Примечание - чтобы сделать универсально применимыми менеджера CANopen, рекомендуется
поддерживать полный ряд субиндексов 01hto7Fh.
9.3.3 Избыточные сети
Избыточные сети требуются для приложений высокой доступности.
Избыточные сети состоят крайней мере из двух, CAN линии. Это позволяет
уствноваить связь между устройствами CANopen, в случае единственной неудачи в
пределах физического соединения между устройствами CANopen. Определение
обязанностей, функциональностей и услуг для избыточных сетей не входит в
область рассмотрения данного документа.
Примечание - Определения для подготовки избыточных сетей CANopen предоставлены в CiA 302.
36
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
9.4 CANopen NMT запуск
9.4.1 NMT запуск
CANopen менеджеры действуют согласно подчиненным машинам NMT как
определено в EN 50325-4. До перехода из преопреационной стадии NMT до NMT
Операционной стадии CANopen менеджер, все назначенные NMT подчиненные
механизмы будут приостановлены. Основная схема
процедуры указана в Рисунке 12 и Рисунке 13. Самая простая схема запуска показана
в Рисунке 14.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 12 - NMT запуск, часть 1
38
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Процесс запуск NMT как показано в рисунке 12 состоит из выполнения
основных шагов:
Примечание -1, процесс функционирования мастера LSS, не входит в область рассмотрения данного
стандарта.
a) Бит 0 из 1F80 h объекта (см. пункт 9.8.7) используется для решения применения устройства
CANopen в качетсве мастера NMT. Если устройство CANopen будет мастером NMT, то процесс
должен продолжиться. Если устройство CANopen будет формироваться как самостартовое
устройство, то необходимо включить в НМТ, Готовится к эксплуатации автоматически. В случае,
если устройство CANopen не становится мастером NMTпроцесс должен закончиться.
b) Бит 5 из 1F80 h объекта (см. пункт 9.8.7) используется, чтобы решить будет ли применяться
устройство CANopen в сервисе коммуникации вместе бегущим механизмом NMT. Если устройство
CANopen будет применяться для устройства NMT, устройство CANopen не должно становиться
мастером NMT.
Определение сервиса по коммуникации вместе бегущим механизмом NMT не входит в рамки
данного документа.
Примечание - 2 коммуникации вместе бегущим механизмом NMT указаны в ЦРУ 302.
c) Если LSS требуется, чтобы устанавливать ID узла CANopen и битрейт других устройств CANopen
в пределах сети, то мастера NMT должен выполнить основные функции LSS. LSS в любое время
может выполнить основные услуги. Точное определение сервиса мастера LSS не входит в рамки
данного документа.
Примечание - 3, описание услуг по урегулированию слоя предоставлено в ЦРУ 305.
d) Бит 4 из всех записей объекта 1F81 ч (см. пункт 9.8.8) используется, чтобы решить ли NMT
владелец должен выполнить сервис NMT связь Сброса с набором ID узла CANopen к0 или функция
NMT коммуникации Сброса должна быть выполнена для каждого устройства CANopen в сети. Если,
по крайней мере, для одного входа объекта 1F81 ч 4, установлен в 1 b и соответствующее устройство
CANopen находится в NMT, то означает готовность к эксплуатации, мастер NMT не должен быть в
сервисе NMT связь Сброса с набором ID узла CANopen к 0. В этом случае каждое устройство
CANopen должно быть перезагружено индивидуально. Это должно также включать весь CANopenID
узла, которые не являются частью списка подчиненных механизмов1F81 h.
Примечание - 4, данное явление оказывает потенциальное влияние на существующие устройства
CANopen, которые не формируются в списке подчиненных механизмов, чтобы передать сообщение
начальной загрузки. Данным менеджер CANopen признает неформируемые устройства CANopen
через укладчика начальной загрузки (рисунок 23). сервис NMT коммуникация Сброса не должно
непосредственно обращаться к мастеру NMT.
Если после того, как шаг d) сервис NMT коммуникация Сброса будет необходим по какой-либо
причине, то обслуживание NMT коммуникация Сброса должно быть выполнено с ID узла CANopen
этого подчиненного механизма NMT. необходимо применить независимо от конфигурации для этого
подчиненного механизма NMT в 1F81 h объекта. Процесс запуска NMT возобновляется в рисунке
13.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 13 - NMT запуск, часть 2
40
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
e) мастер NMT должен начать процесса подчиненных механизмов NMT для всех подчиненных
механизмов NMT
f) как показано в рисунке 15. Для всех подчиненных механизмов NMT, которые отмечены как
обязательные (бит 0 и бит 3
g) 1F81 ч; см. 9.8.8), начала процесса, который должен закончить процесс подчиненных
механизмов NMT успешно.
f) Если ошибка обнаружена во время функционирования подчиненного механизма NMT, которые
отмечены как обязательный процесс запуск NMT, то процесс должен быть остановлен.
g) Бит 2 из объекта, который 1 F80h (см. 9.8.7) используется, чтобы решить, должен ли мастер NMT
включен в НМТ, Готовых к эксплуатации автоматически отдельно или, действовать по требованию
h) применение, на том же самом устройстве CANopen.
При следующих условиях
- Бит 3 из 1F80 h объекта установлен в 0b,
- Бит 1 из объекта 1 F80h установлен в 1 b,
- и все рабы NMT, перечисленные в 1F81 ч, загружены успешно
обслуживание NMT в начале отдаленный узел должно быть выполнено с набором ID узла CANopen
к 0. При следующих условиях
- Бит 3 из 1F80 h объекта установлен в 0b,
- Бит 1 из объекта 1 F80h установлен в 1 b,
- и не все рабы NMT, перечисленные в 1F81 ч, загруженный успешно
обслуживание NMT Начало отдаленного узла должно быть выполнено для каждого подчиненного
механизма NMT индивидуально.
i) Процесс, запуск которого NMT закончился успешно и владелец NMT, должен возобновить
нормальное функционирование.
i) Возникновение и обнаружение подчиненного механизма NMT, не перечисленных в 1F81 ч,
попадают в ответственность приложения.
9.4.2 Запуск простого NMT
Так как почти все объекты и свойства, являются дополнительными, есть
возможность осуществить основного мастера NMT, который может иметь смысл для
некоторых приложений. Удаление всех дополнительных частей в определениях
выше результатов в процессе запуска NMT, простого как показано в рисунке 14.
Даже простой мастер NMT может поддерживать все обязательные объекты, которые
определены в EN 50325-4 и которые определены в данном стандарте.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 14 – простой запуск NMT
42
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
9.4.3 Старт процесса загрузки подчиненного ммеханизма NMT
9.4.3
NMT
Старт процесса загрузки подчиненного ммеханизма
Рисунок 15 - Старт процесса загрузки подчиненного ммеханизма NMT
Старт процесса загрузки подчиненного ммеханизма NMT, как показано, в рисунке
15 должен включать следующие шаги:
a) Начните параллельный процесс загрузки подчиненного механизма NMT.
b) Обязательные подчиненные механизмы NMT: ждать завершения раба загрузки
процесса NMT.
Дополнительные рабы NMT: ждать сигнала о том, что загрузка процесса
подчиненного механизма NMT была выполнена.
Параллельно выполнить следующее:
c) Выполните загрузку процесса подчиненного механизма NMT (см. 9.5).
d) Создайте сигнал для каждой попытки загрузки подчиненного механизма процесса
NMT.
Если загрузка подчиненного механизма NMT завершился со статусом ОК,
процесс, должен закончиться. Этот процесс должен продолжаться до тех пор, пока
дополнительные подчиненные механизмы NMT, пока запуск процесса подчиненного
механизма NMT не закончится со статусом ОК.
Примечание - рекомендуемое время цикла составляет 1 с для бита выше, чем 125 кбит/с.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Если загрузка процесса, который подчиненный механизм NMT возвращается с
ошибочным статусом B для обязательных подчиненных механизмов NMT и тогда
затраченное время, будет больше, чем значение объекта 1 F89h, то сообщение
поступает в приложение и подпроцесс завершается.
Подпроцесс загрузки подчиненного механизма NMT должен происходит
асинхронно к другим процессам.
44
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
9.5 Загрузка подчиненного механизма NMT
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 16 - Загрузка NMT подчиненного механизма, часть1
46
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Процесс подчиненного NMT как показано в Рисунок 16 состоит из следующих
шагов:
a) Бит 0 из объекта 1F81 ч используется, для определения подлежит ли подчиненный
механизм NMT обработке или закончится ли процесс с ошибочным статусом.
b) Бит 2 из объекта 1F81 ч используется, для определения подлежит ли подчиненный
механизм NMT конфигурации.
c) Объект закачки, 1000-й от подчиненного NMT. В случае, если ответ не получен, то
процесс завершится с ошибочным статусом.
d) В случае, если значение 1F84 h объекта для подчиненного механизма NMT неравна
0, необходимо проверить значение . В случае, если обе значения отличаются, процесс
завершится с ошибочным статусом.
e) В случае, если значения 1F85 h объектов к 1F88 h неравны 0, особые значения
объекта будут проверены на соответствие значениям объекта, 1018-го от NMT. В
случае, если одна из значений 1F85 h объекта и 1F88 h отличается от значения объекта,
1018-го подчиненного механизма NMT, то процесс завершится с ошибочным
статусом.
Если поддерживать часть устройства CANopen, то владелец NMT не должен
выпускать услуги NMT узла, Сброса и коммуникация Сброса для данного устройства
CANopen.
Примечание - что такая ситуация может произойти, в случае, если владелец NMT сталкивается с
неудачей с последующим перезапуском.
Контроль за вариантами программного обеспечения может использоваться в
системах, где версия прикладного программного обеспечения, применяемого на
устройстве CANopen, проверена на правильность. Проверка процесса и версия
программного обеспечения могут проверяться, для автоматической загрузки
актуальнейшей версии приложения программного обеспечения. Устройства
CANopen, которые обнаруживают ошибку в их прикладном программном
обеспечении, например, вычисляя контрольную сумму во время запуска, могут
вызвать загрузку актуальнейшего прикладного программного обеспечения, ответив
неправильной информацией о версии.
Оба или только одна из двух особенностей могут быть осуществлены.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 17 – загрузка подчиненного механизма NMT, часть2
f) Бит 4 из объекта 1F81 ч используется для проверки совместимости.В случае, если
совместимы владелец NMT должен просить текущее состояние подчиненного NMT
NMT, для которого загрузка выполняется посредством NMT. В случае, если
обнаруживается несоответствие NMT , то процесс должен закончиться с ошибочным
статусом. В случае, если текущее состояние NMT Готово к эксплуатации, процесс
должен продолжиться D. В случае, если текущее состояние NMT не соответствует
NMT Готовое к эксплуатации, NMT должен выполнить обслуживание NMT сброс
для NMT.
Проверка процесса состояния NMT определена в 9.5.2.
g) Бит 5 из объекта 1F81 ч используется для решения проведение проверки
48
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
приложения программного обеспечения.
В случае, если проверку прикладного программного обеспечения требуют,
проверка процесса и обновление версий программного обеспечения должны быть
выполнены.
В случае, если версия программного обеспечения остается неправильной при
загрузке процесса, NMT должен закончиться ошибочным статусом.
Загрузка процесса NMT продолжается в части 3 (см. Рисунок 18).
.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 18 - Загрузка NMT подчиненной части, часть 3
50
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
h) проверочная конфигурация процесса (см. 9.5.1) должна быть выполнена.
i) В случае, если проверочная конфигурация процесса закончилась неудачно, то
загрузка процесса подчиненного механизма NMT должен закончиться ошибочным
статусом.
j) Ошибочный контроль за началом процесса (см. 9.6.1) должен быть выполнен.
k) В случае, если ошибочный контроль за началом процесса закончился неудачно
закончилась неудачно, то загрузка процесса подчиненного механизма NMT должен
закончиться ошибочным статусом.
l) В случае, если NMT находится в NMT, означающий о готовности к эксплуатации
процесса, который NMT должен закончить успешно.
m) Бит, который 3 из 1F80 h объекта используются, чтобы решить, должен ли владелец
NMT выполнить обслуживание NMT.
n) В случае, если владелец NMT не должен выполнять обслуживание NMT старт
отдаленного узла процесса, NMT должен закончить с успешным статусом.
o) Бит, который 1 из 1F80 h объекта используется, чтобы решить то, должен ли мастер
NMT выполнить обслуживание NMT
p) В случае, если владелец NMT должен выполнить обслуживание NMT Начало,
отдаленный узел с набором ID узла CANopen к 0 и владелец NMT не находится в
NMT, заявляют о готовности эксплуатации загрузки процесса, который NMT должен
закончить успешно со статусом хорошо.
примечание 3, Если владелец NMT находится в NMT, заявляют о готовности
эксплуатации, он расценен как признак, что начальный запуск NMT был закончен до
запуска этого раба NMT.
q) В случае, если владелец NMT выполняет обслуживание NMT. В
начадередоставлется отдаленный узел для каждого раба NMT в сети индивидуально
или в случае, если владелец NMT выполняет обслуживание NMT, отдаленный узел с
набором ID узла CANopen к 0 и владелец NMT находится в NMT, заявляют Готовый
к эксплуатации, владелец NMT должен выполнить обслуживание NMT Начало
отдаленный узел с набором ID узла CANopen к соответствующей стоимости.
r) загрузка процесса раб NMT должен закончиться успешно со статусом.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
9.5.1 Конфигурация проверки
Рисунок 19 – конфигурация проверки
Процесс подчиненного NMT как показано в Рисунок 16 состоит из следующих
шагов:
a) Бит 0 из объекта 1F81 ч используется, для определения подлежит ли подчиненный
механизм NMT обработке или закончится ли процесс с ошибочным статусом.
b) Бит 2 из объекта 1F81 ч используется, для определения подлежит ли подчиненный
механизм NMT конфигурации.
c) Объект закачки, 1000-й от подчиненного NMT. В случае, если ответ не получен, то
процесс завершится с ошибочным статусом.
d) В случае, если значение 1F84 h объекта для подчиненного механизма NMT неравна
0, необходимо проверить значение . В случае, если обе значения отличаются, процесс
завершится с ошибочным статусом.
e) В случае, если значения 1F85 h объектов к 1F88 h неравны 0, особые значения
объекта будут проверены на соответствие значениям объекта, 1018-го от NMT. В
случае, если одна из значений 1F85 h объекта и 1F88 h отличается от значения объекта,
1018-го подчиненного механизма NMT, то процесс завершится с ошибочным
статусом.
Если поддерживать часть устройства CANopen, то владелец NMT не должен
52
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
выпускать услуги NMT узла, Сброса и коммуникация Сброса для данного устройства
CANopen.
Примечание, что такая ситуация может произойти, в случае, если владелец NMT сталкивается с
неудачей с последующим перезапуском.
Контроль за вариантами программного обеспечения может использоваться в
системах, где версия прикладного программного обеспечения, применяемого на
устройстве CANopen, проверена на правильность. Проверка процесса и версия
программного обеспечения могут проверяться, для автоматической загрузки
актуальнейшей версии приложения программного обеспечения. Устройства
CANopen, которые обнаруживают ошибку в их прикладном программном
обеспечении, например, вычисляя контрольную сумму во время запуска, могут
вызвать загрузку актуальнейшего прикладного программного обеспечения, ответив
неправильной информацией о версии.
Оба или только одна из двух особенностей могут быть осуществлены.
9.5.2 Проверка состоянияNMT
Рисунок 20 – проверка NMT состояние1
Проверка состояния NMT как указано в Рисунке 20 охватывает следующие шаги:
a) Объект 1016h (смEN 50325-4) будет использован для определения
выбора heartbeat
b) В случае, если устройство CANopen настроено для heartbeat, владелец
NMT должен проверить если это полученный признак heartbeat, вовремя
(потребительское время сердцебиения не истекает). Если признак heartbeat
не получен вовремя, процесс должен закончиться ошибочным статусом.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Если признак heartbeat, получен, процесс должен закончиться фактическим
состоянием NMT
Устройство CANopen проверено.
c) В случае, если устройство CANopen, которое проверено, не настроено
для heartbeat, CANopen настроено для охраны устройства CANopen. В этом
случае владелец NMT устройства CANopen, которое проверено,
NMTобслуживание охрана устройства CANopen должно использоваться. В
случае, если никакое подтверждение не получено и больше чем 100 мс
истекают, процесс должен закончиться ошибочным статусом. В случае,
если a подтверждение получено, процесс должен быть и с фактическим
состоянием NMT CANopen устройство, которое проверено.
9.5.3 NMT бегущий механизм
Определение мастера NMT не входит в область рассмотрения этого
стандарта.
Примечание - Определения функциональности мастера NMT обеспечена в ЦРУ 302.
Необходимо, если бит 4 из объекта 1 F81 h установлен
(поддерживается).
9.5.4 Статус ошибки
Ошибки указанные в Таблице 14 сигнализируется в пределах NMT master во
время загрузки.
Таблица 14 – Статус ошибки
Статус
ошибки
A
B
C
D
E
L
J
_
G
H
I
J
K
L
M
54
Описание
Устройство CANopen не включено в объекте 1 F81 h.
запроса закачки 1000-го объекта.
значение объекта, 1000-го от устройства CANopen, отличается, чтобы
оценить в 1F84 h объекта (Тип устройства).
значение объекта 1018 подындексов 01 от устройства CANopen
отличается, чтобы оценить в 1F85 h объекта (удостоверение личности
Событие
heartbeat. Никакое сообщение heartbeat не получено от
Продавца).
устройства CANopen.
Событие охраны узла. Никакое подтверждение для охраны запроса не
получено от устройства CANopen.
объект 1 F53h или объект 1 F54h не адаптирован для этого устройство
CANopen.
Значения объекта 1 F52h от этого устройство CANopen отличается от
значения объекта 1 F53h или значение объекта 1 F54hh и бит 6 из
Значения
F52h от этого устройство CANopen отличается от
объекта, 1объекта
F81 h не1 установлен.
Значения объекта 1 F53h или Значения 1F54 h объекта и подведенный.
Загрузка конфигурации потерпела неудачу.
Событие heartbeat во время ошибочной контрольной службы а.
Никакое сообщение с heartbeat не получено от устройства CANopen во
Раб
NMT
был первоначально
готов
к эксплуатации.
(Менеджер по
время
ошибочной
контрольной
службы
начала.
CANopen может возобновить операцию с другими устройствами
Значение
CANopen),объекта 1018-й подындекс 02h от устройства CANopen
отличается, чтобы оценить в объекте (код изделия) 1F86 h.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
N
0
Значение ь объекта 1018-й подындекс 03h от устройства CANopen
отличается, чтобы оценить в 1F87 h объекта (Число пересмотра).
Значение объекта 1018-й подындекс 04h от устройства CANopen
отличается, чтобы оценить в объекте (регистрационный номер) 1F88 h.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
9.6 Контроль ошибки
Рисунок 21 – Старт контроля ошибки
Процесс старта контроля ошибок, как на Рисунок 21 состоит из следующих
частей:
a) Объект 1016-й (см. EN 50325-4), будет проверен, чтобы решить ли устройство
CANopen настроен для hertbeat.
b) В случае, если устройство CANopen настроено для hertbeat, и никакой признак
hertbeat не получен вовремя процесс должен закончиться ошибочным статусом.
Таймер для проверки перерыва должен быть начатый немедленно с самого процесса.
c) В случае, если устройство CANopen настроено для hertbeat, и признак
сердцебиения получен вовремя процесс должен закончиться успешно.
d) В случае, если устройство CANopen не настроено для hertbeat бита 0 из объекта
1F81, ч привык к решите, должно ли устройство CANopen охраняться.
e) В случае, если устройство CANopen не находится в списке сети, процесс должен
закончиться успешно.
f) В случае, если устройство CANopen находится в списке сети стоимость байта 2 и 3
из объекта 1F81 используется, чтобы решить, должно ли устройство CANopen
охраняться.
g) В случае, если стоимость больше, чем 0 охраны должна быть начата для этого
устройство CANopen и процесс должен закончиться успешно.
56
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
h) В случае, если значение равняется 0, процесс должен закончиться успешно.
9.6.2 Обработчик ошибок
Рисунок 22 – Обработчик ошибки
Процесс обработки ошибки как указано в Рисунке 22 должо иницироваться
любое время.
9.6.3 Загрузка обработчика
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 23 - Bootup handler
Укладчик программы начального пуска процесса, как определено в Рисунок 23
должен быть начат любое время, которое имеет место событие программы начального
пуска (см. EN 50325-4).
9.7 Дополнительные основные услуги NMT и протоколы
Определение дополнительных основных услуг NMT и протоколы не в пределах
этой спецификации.
Примечание - Дополнительные основные услуги NMT и протоколы, такие как переговоры владельца
NMT, или основные услуги обнаружения NMT предоставлены в ЦРУ 302.
9.8 Словарные статьи объекта
9.8.1 1020-й объект: Проверьте конфигурацию
Этот объект должен указать на загруженную дату конфигурации и время. Если
устройство CANopen поддерживает экономию параметров в энергонезависимой
памяти, инструмент конфигурации сети или менеджер CANopen используют этот
объект проверить конфигурацию после того, как устройство CANopen перезагрузило
и проверять, необходима ли реконфигурация. Инструмент конфигурации хранит дату
и время в том объекте и хранит те же самые значения в DCF. Теперь инструмент
конфигурации позволяет устройству CANopen спасти свою конфигурацию, сочиняя,
чтобы внести в указатель 1010-й подындекс 01 h, который "экономит" подпись. После
сброса устройство CANopen должно восстановить последнюю конфигурацию и
подпись автоматически или по запросу. Если какие-либо другие ценности
конфигурации начальной загрузки изменений команды, устройство CANopen должно
перезагрузить объект, Проверяют Конфигурацию к 0.
Менеджер конфигурации сравнивает подпись и конфигурацию со стоимостью от
DCF и решает, необходима ли реконфигурация или нет.
примечание, что использование этого объекта позволяет значительное ускорение
процесса начальной загрузки. Если это используется, системный интегратор полагает,
что пользователь изменяет знчение конфигурации, и впоследствии активируйте
конфигурацию магазина команды, 1010-ю, не изменяя значение1020-х. Таким образом,
системный интегратор гарантирует 100%-е последовательное использование этой
особенности.
Подындекс 01 h (дата конфигурации) должен содержать число дней с 1 января 1984.
Подындекс 02h (время конфигурации) должен быть числом ms после полуночи.
Таблица 15 и Таблица 16 предоставляют описание объекта и описание входа
58
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 15 – описание объекта
Описани
е
индекс
Название
Код объекта
Тип данных
Категория
Значение
1020h
Подтверждение конфигурации
ARRAY
UNSIGNED32
Дополнительный
Таблица 16 – Описание ввода
Описани
Значение
Субиндекс
е
ººh
Описание Самый высокий субиндекс
Вводная
Обязательный
доступ
категория Постоянный
PDO
No
контроль
Диапазон
02h
По
02h
значений
умолчанию
Субиндекс 01 h
Описание Дата конфигурации
Вводная
Обязательный
доступ
категория rw
PDO
No
Диапазон
UNSIGNED32
контроль
значений
По
Для производителя
to
умолчанию
Субиндекс 02h
Описание Время конфигурации
Вводная
Обязательный
категория rw
доступ
PDO
No
Диапазон
UNSIGNED32
контроль
По
Для производителя
значений
умолчанию
9.8.2 Объект102Ah: NMT время торможения
Данный объект должен указать время запрещения конфигурации между двумя
последующими сообщениями NMT. Актуальные сервисы NMT должны стояться в
очереди и должны быть выпущены в порядке их возникновения для уважения время
запрещения конфигурации. Таблица 17 и Таблица 18 определяют описание объекта и
описание входа.
Стоимость должна быть дана в сети магазинов 100 u, s. Стоимость 0 должна
отключить время запрещения.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 17 – описание объекта
Описани
е
индекс
Название
Код объекта
Тип данных
Категория
Значение
1
0
N
2
M
V
A
T
A
U
h
вN
R
О
р
S
б
Таблица
1 8 - Описание ввода
еI
я
м
з
Описание G
Значение
яN
а
индекс
0тE
т0
Название
rо
D
е
р
Код объекта hw
N
1
л
Тип данных oм
U
ь6
о
N
Категория
0н
ж
S
ы
еI
й
н
9.8.3 Объект1F20h: Хранение
DCF
G
и
N
яE
Этот объект должен использоваться,
для сохранения текущую конфигурацию
D
для определенного устройства CANopen в сети. Таблица 19 определяет описание
1
объекта, и Таблица 20 определяет
описание входа.
6
субиндекс входа должен соответствовать ID узла CANopen устройства CANopen в
сети. субиндекс входа, соответствующего его собственному ID узла CANopen,
должен использоваться для самоконфигурации. Если никакой DCF не будет спасен
ранее, то доступ нужно ответить с сообщением аварийного прекращения работы SDO
(код ошибки: 0800 0024-х или 0800 0000-х). Определение формата DCF не в пределах
этой спецификации.
Примечание - что формат DCF обеспечен в ЦРУ 302.
Таблица 19 – описание объекта
Описание
индекс
Название
Код объекта
Тип данных
Категория
1F20h
Store DCF
ARRAY
DOMAIN
Дополнительный
Таблица 20 – писание ввода
Описание
Субиндекс
ººh
60
Значение
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
значений
По
умолчанию
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
значений
По
умолчанию
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
значений
По
умолчанию
Количество входов
Обязательный
const
No
7Fh
7Fh
01 h
CANopen Node-ID 1
Обязательный
rw
No
См описание значения
Специально для производителч
7Fh
CANopen Node-ID 127
Обязательный
rw
No
См описание значения
Manufacturer-specific
9.8.4 Объект1F22h: сжатие DCF
Данный объект должен использоваться, чтобы сохранить текущую
конфигурацию для определенного устройства CANopen в сети. Таблица 21
определяет описание объекта, и Таблица 22 определяет описание входа.
Субиндекс входа должен соответствовать ID узла CANopen устройства CANopen в
сети. Субиндекс входа, соответствующего его собственному ID узла CANopen,
должен использоваться для самоконфигурации. Формат Device Configuration File
(DCF) должен быть как определен в Рисунок 24. Если никакой DCF не был спасен
ранее, число записей должно быть 0. Если DCF для определенного входа должен быть
удален, номер записей должен быть определен к 0.
Количество входов
индекс
Ввод 1 Субиндекс
размер(m) данных байтов
Данные байты 1
Данные байты 2
Данные байты m
Ввод 2 индекс
Субиндекс
размер(m) данных байтов
UNSIGNED32
UNSIGNED16
UNSIGNED8
UNSIGNED32
UNSIGNED8
UNSIGNED8
UNSIGNED8
UNSIGNED16
UNSIGNED8
UNSIGNED32
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Данные байты 1
Данные байты 2
Данные байты m
Ввод n индекс
Субиндекс
размер(m) данных байтов
Данные байты 1
Данные байты 2
Данные байты m
UNSIGNED8
UNSIGNED8
UNSIGNED8
UNSIGNED16
UNSIGNED8
UNSIGNED32
UNSIGNED8
UNSIGNED8
UNSIGNED8
Рисунок 24 – Определение данных DCF
Таблица 21 – описание объекта
наименование
Индекс
Название
Код объекта
Тип данных
Категория
62
Значение
1F22h
Concise DCF
ARRAY
DOMAIN
Дополнительный
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 22 – Вводное описание
определение
Субиндекс
Описание
Вводная категория
ººh
Количество входов
Обязательно
доступ
PDO контроль
Диапазон значений
Постоянный
No
7Fh
По умолчанию
7Fh
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон значений
По умолчанию
to
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон значений
По умолчанию
01
Значение
h
CANopen Node-ID 1
Обязательно
rw
нет
См определение
Специально для производителя
7Fh
CANopen узел-ID 127
Обязательно
rw
нет
См описание
Специально для производителя
9.8.5 Объект 1F26h: Ожидаемая конфигурационная дата
Данный объект используется для подтверждения конфигурационной даты
устройств и сети CANopen.
Конфигурационная дата (см9.8.1 объект1020h субиндекс 01 h) устройств CANopen
в сети соответствует со значениями объекта, когда значение не равно 0. В случае если
значение объекта рано 0 устройство CANopen конфигурируется.
Субиндекс ввода должно соответствовать в сети с идентификатором CANopen
устройств CANopen.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 23 – описание объекта
определе
ние
Индекс
Название
Код
Тип
объекта
Категория
данных
Значение
1F26h
Ожидаемая конфигурационная дата
ARRAY
UNSIGNED32
дополнительно
Таблица 24 – Вводное описание
определение
Субиндекс
Описание
Вводная
категория
доступ
PDO контроль
Диапазон
По умолчанию
значений
Субиндекс
Описание
Вводная
доступ
категория
PDO контроль
Диапазон
По умолчанию
значений
to
Субиндекс
Описание
Вводная
доступ
категория
PDO контроль
Диапазон
значений
По умолчанию
Значение
ººh
Количество входов
обязательный
постоянный
No
7Fh
7Fh
01 h
CANopen идентификатор узла 1
обязательный
rw
нет
См описание
Для производителя
7F
h
CANopen идентификатор узла 127
обязательный
rw
No
См описание
Для производителя
9.8.6 Объект 1F27h: Ожидаемая конфигурация времени
Данный объект используется для подтверждения конфигурации времени
устройств CANopen в сети.Время конфигурации устройств CANopen (объект 1020h
субиндекс 02h) в сети должно соответствовать значению данного объекта, в случае
если, значение равно 0. В случае, если значение объекта равно 0 устройство CANopen
64
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
должно конфигурироваться.
Субиндекс ввода соответствует идентификатору узла и устройства CANopen в сети.
Примечание - описание объекта и описание ввода индекса 1020h субиндекса 02h указаны в
поздних версиях CANopen ; документ CiA301.
Таблица 25 – описание объекта
Описание
Индекс
Название
Код объекта
Тип данных
Категория
Обозначение
1F27h
Ожидаемая конфигурационная дата
ARRAY
UNSIGNED32
Дополнительно
Таблица 26 – Описание ввода
Описание
Субиндекс
Описание
Вводная
доступ
категория
PDO контроль
Диапазон
По умолчанию
значений
Субиндекс
Описание
Вводная
доступ
категория
PDO контроль
Диапазон
По умолчанию
значений
to
Субиндекс
Описание
Вводная
доступ
категория
PDO контроль
Диапазон
значений
По умолчанию
Обозначение
ººh
Количество входов
Обязательный
const
No
7Fh
7Fh
01 h
CANopen идентификатор узла 1
обязательный
rw
No
См описание значения
Для производителя
7F
h
CANopen Node-ID 127
Обязательный
rw
No
См описание значения
Для производителя
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
9.8.7 Объект 1F80h: NMT запуск
Этот объект должен формировать свойства запуска устройства CANopen.
Переходы внутреннего состояния не должны изменять значение данного объекта.
Попытка изменить что-то вроде функциональности, которая не поддерживается
устройством CANopen будет приостановлена сообщением аварийного
прекращения работы (кодекс аварийного прекращения работы: 0800 0000h or 0609
0030h). Рисунок 25 и рисунок 26 определяют ориентированную на бит структуру
стоимости. Таблица 27, Таблица 28, Таблица 29, Таблица 30, Таблица 31, Таблица
32 и Таблица 33 определяют позволенные значения. Таблица 34 определяет
исключения устройства способные производить запуска. Таблица 35 и Таблица 36
определяют описание объекта и описание входа.
31
24 23
Сохранен 0000 00h
16 15
8 7
0
конфигурация
MSB
LSB
Рисунок 25 – Структура объекта
7
6 5
4
3
2
1
0
сохран Остан Бегу Переза Старто NMT Запус NMT
ен
овка
щий грузка вый
масте к всех масте
0b
всех
меха всех
узел LSBр
узлов р
MSB
узлов
низм узлов
старт
Рисунок 26
– Структура
бита конфигурационного
значения
Таблица 27 – значение мастера NMT (бит: 0)
значен
Описание
ие
Устройство CANopen не является мастером
0b
NMT Входы объекта 1 F81 h игнорируется. Все
другие биты объекта 1F80h игнорируется
ожиданиями указанными в таблице 34.
Устройство CANopen является мастером NMT
1b
Таблица 28 – Значение запуска всех узлов (бит: 1)
значен
Описание
ие
Сервис запуска удаленным узлом NMT CANopen
0b
Идентификатор узла
Сервис запуска удаленным узлом NMT
1b
Идентификатор узла -ID = 0
Таблица 29 - значение NMT мастера старта (бит: 2)
значен
ие
66
Описание
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Необходимо включить NMT в процессе запуска
NMT в статусе «Действующий» (см Рисунок 13)
Не включается NMT в статусе «Действующий»
1b
самостоятельно.
Таблица 30 – Значение запуска узла (бит: 3)
0b
значен
Описание
ие
мастер NMT должен запустить подчиненные
0b
механизмы NMT.
Мастер NMT не запускает подчиненные NMT и
1b
приложение может запустить подчиненные NMT.
Сохранен (дляNMT устройств с функциями
1b
бегущего механизма)
Таблица 31 – Перезапуск всех узлов (бит: 4)
значен
Описание
ие
В случае контроля ошибок устройства CANopen
0b
установлено как обязательное (см объект 1F81h)
сервис
NMT
по перезагрузке
узла CANopen
NodeВ случае
контроля
ошибки устройства
CANopen
1b
ID
устройства
CANopen
, которыйобъект
может1F81
бытьh)
определены
как
обязательные(см
причиной
ошибки
.
сервис NMT
Node-ID
= 0 (бит:
по 5)
Таблица
32
– CANopen
Бегущий
механизм
перезагрузке узла может быть выполнена
значен
Описание
Устройства CANopen не участвуют в процессе
ие
0b
Сохранен
(дляNMT устройств
с функциями
1b
бегущего механизма
NMT
бегущего механизма)
Примечание - ОПИСАНИЕ функций БЕГУЩЕГО механизма NMT не входит в данный стандарт.
Определения представлены в CiA 302.
Таблица 33 – остановка всех узлов (бит: 6)
значен
Описание
ие
В случае контроля ошибок устройства CANopen
0b
установлено как обязательное (см объект 1F81h)
В
случае контроля
ошибки
устройства
1b
действие
определеное
посредством
битCANopen
4 будет
определены
выполнено как обязательные(см объект 1F81h)
сервис NMT удаленной остановки с
идентификатором ID = 0 будет выполнен. бит4
должен игнорироваться.
Таблица 34 – Ожидания
для NMT запуска потенциального устройства
Value
Description
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
00000000 00000000
00000000 00001000b
00000000 00000000
00000000 00000010b
Необходимо включить NMT в
процессе запуска NMT в статусе
«Действующий» (см Рисунок 13)
Не включается NMT в статусе
«Действующий» самостоятельно.
Таблица 35 – описание объекта
Описан
Индекс
ие
Название
Код
объекта
Тип
Категория
данных
Значение
1F80h
NMT запуск
VAR
UNSIGNED32
условно;
обязательно если устройство является
менеджером CANopen или запуском
устройства CANopen.
Таблица 36 – вводное описание
Описан
Значение
Субиндекс
ие
ººh
Описание rw
Вводная
нет
доступ
категория См описание
PDO
Для производителя
контроль
9.8.8 Object 1F81h: NMT slave assignment
Данный объект должен определять устройства CANopen менеджера CANopen,
устройство, которые должны выполнять данный объект. Каждый субндекс этого
объекта должен соответствовать ID узла CANopen связанного с устройством CANopen
в сети. субиндекс, соответствующий его собственному ID узла CANopen, должен быть
проигнорирован. Попытка изменить что-то вроде функциональности, которая не
поддерживается устройством CANopen, нужно прекратить с сообщением аварийного
прекращения работы (кодекс аварийного прекращения работы: 0800 0000-х или 0609
0030-х). Рисунок 27 и рисунок 28 определяют ориентированную на бит структуру
значения. Таблица 37, Таблица 38, Таблица 39, Таблица 40, Таблица 41, Таблица 42 и
Таблица 43 определяют содержание значения. Таблица 44 и Таблица 45 определяют
описание объекта и описание входа.
Значение для фактора повторной попытки указывает на число повторений,
которые мастер NMT должен выпустить в случае угрозы для узла. Значение 0 должна
отключить блокировку узла для устройства CANopen.
Значение в течение времени блокировки должна указать на время цикла для
68
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
блокировки узла устройства CANopen. Значение должно быть обозначено в сети ms.
Значение 0 должна отключить блокировку узла для устройства CANopen.
Примечание, В СЛУЧАЕ если значение потребительского объекта heartbeat неравной 0, то у
механизма heartbeat будет приоритет над блокировкой узла.
31
MSB
24 23 16 15
8 7
0
Время блокировки
Фактор
Конфигура
повторной
ция
LSB
попытки
Рисунок 27 – объект
структуры значения
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
7
6
5
4
3
2
1
0
Восстан Обнов Верси коммуника обязател NMT сохране NM
овление ление
я
ция
ьный загрузк
н
T
програ програ
а
0b
под
MSB
LSB
м.Рисунок
м. 28 – структура бита конфигурации значения
чине
обеспе
нны
ченияТаблица 37 - NMT подчиненный механизм (бит: 0)
й
значен
описание
ие
NMT мастер или не доступна в сети
0b
NMT подчинённый механизм и не доступен в сети
1b
Таблица 38 - NMT загрузка подчиненного механизма (бит: 2)
значен
описание
ие
Конфигурация и обслуживание NMT запуск
0b
отдаленного узла не должны быть позволен в случае
ошибочного события контроля или обслуживания
NMT Программа начального запуска
Конфигурация
и приложение
обслуживание
NMT запускзаотдаленного
1b
примечание, что
ответственно
запуск
узла
должны быть
выполнены
подчиненного
механизма
NMT.в случае ошибочного
события контроля или обслуживания NMT Программа
Таблица
начального
пуска39 - Обязательное (bit: 3)
значен
описание
ие
Устройство CANopen может присутствовать до запуска
0b
сети (устройство CANopen дополнителен)
Устройство CANopen может присутствовать до запуска
1b
сети (устройство CANopen дополнителен)
Таблица 40 – Перезагрузка коммуникацию (bit: 4)
значен
описание
ие
NMT перезагрузка коммуникации может быть выполнена
0b
на устройстве CANopen в любое время
NMT перезагрузка коммуникации не может быть
1b
выполнена на устройстве CANopen NMT в случае если
NMT
Таблица
41в–статусе
Версия«Действующий»
программного обеспечения (бит: 5)
значен
описание
ие
Подтверждение версии програ. Обесп. Не может быть
0b
выполнена для устройства CANopen
Подтверждение версии програ. Обесп. ожет быть
1b
выполнена для устройства CANopen
70
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 42 – обновление программного обеспечения (бит: 6)
значен
описание
Обновление версии програ. Обесп. Не может быть
ие
0b
Обновление
версии
програ.CANopen
Обесп. может быть
1b
выполнена для
устройства
выполнена
для 43
устройства
CANopen (бит: 7)
Таблица
- восстановление
значен
описание
ие
0b Устройство CANopen может быть использовано без
предварительной перезагрузки
1b CANopen device shall be reset to factory defaults by issuing
a restore to defaults (object 1011 h)
Таблица 44 - Object description
Описани
Индекс
е
Название
Код
объекта
Тип
Категория
данных
Описани
Субиндекс
е
Описание
Вводная
доступ
категория
PDO
Диапазон
контроль
значений
По
Субиндекс
умолчанию
Описание
Вводная
доступ
категория
PDO
Диапазон
контроль
значений
Значение
1F81h
NMT установка подчиненного механизма
ARRAY
UNSIGNED32
условно; обязательно, если устройство
CANopen является менеджером CANopen
Таблица 45 – Вводное описание
Значение
ººh
Количество входов
Обязательно
постоянно
No
7F
h
7Fh
01 h
CANopen идентификатор узла 1
обязательный
rw
No
см Рисунок 27, Рисунок 28, Рисунок 37, Рисунок
38, Таблицу 39, Таблицу 40, Таблицу 41,
Таблицу 42, и Таблицу 43
По
0000 0000h
умолчанию
to
Субиндекс 7Fh
Описание CANopen идентификатор узла 127
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Вводная
доступ
категория
PDO
Диапазон
контроль
значений
Обязательный
rw
Нет
см Рисунок 27, Рисунок 28, Рисунок 37, Рисунок
38, Таблицу 39, Таблицу 40, Таблицу 41,
Таблицу 42, и Таблицу 43
0000 0000h
По
умолчанию
9.8.9 Объект 1F82h: запрос NMT
Данный объект должен направить запрос на определенный сервис NMT для
уникального устройства CANopen в сети или для всех устройств CANopen в сети в
случае, если устройство CANopen, содержащий данный
объект находится в основном режиме NMT. Обычно, запрос направленный другим
устройством CANopen (например, инструмент конфигурации) в сети или
приложением, на том же самом устройстве CANopen (например, в окружающей среде
IEC 61131).
субиндекс должен соответствовать ID узла устройств CANopen в сети CANopen. Эти
запросы могут быть применены для мастера NMT самостоятельно. Таблица 46
определяет содержание значение. Таблица 47 и Таблица 48 определяют описание
объекта и описание входа.
Значение от 84h to 8Fh требуют знания ID узла CANopen запрашиваемого
устройства CANopen. Если ID узла CANopen будет неизвестен, то действие должно
быть прервано (кодекс аварийного прекращения работы: 0800 0000-х или 0609 0030х).
Попытка загрузить значение, которое зарезервировано, нужно прекратить с
сообщением аварийного прекращения работы SDO (кодекс аварийного прекращения
работы: 0800 0000-х или 0609 0030-х).
Примечание - ЗНАЧЕНИЯ от 00h до 7Fh должны быть применены тщательно
относительно преднамеренного влияния мастера NMT или требуемого устройства
CANopen.
Таблица 46 – описание значения
значен
ие
00h
01 h
02h
03h
04h
05h
06h
72
выгрузка
(чтение)
NMT
неизвестное
состояние
Отсутствие
устройства CANopen
Описание
По загрузке (письменно)
сохранено
сохранено
сохранено
сохранено
NMT Остановлено NMT сервис удаленный стоп узла
NMT Опреационный NMT сервис старт удаленного узла
сохранено
NMT сервис перезагрузка узла
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
07h
сохранено
08h
7Eh
7Fh
80h
83h
84h
сохранено
сохранено
NMT state Preoperational
сохранено
сохранено
NMT state Stopped
85h
NMT state
Operational
86h
сохранено
87h
сохранено
88h
8Eh
8Fh
сохранено
сохранено
NMT
Преоперационный
90h
FFh
сохранено
сохранено
Attribut
e
Индекс
Название
Код
Тип
объекта
Категория
данных
NMT сервис загрузка коммуникации
NMT service Enter pre-operational
NMT сервис стор удаленного узла (за
исключением NMT мастера и запроса
устройства CANopen)
NMT сервис Старт удаленного узла (за
исключением NMT мастера и запроса
устройства CANopen)
NMT сервис перезагрузка узла (за
исключением NMT мастера и запроса
устройства CANopen)
NMT сервис Перезагрузка
коммуникации (за исключением NMT
мастера и запроса устройства CANopen)
NMT сервис Ввод предоперационный
(за исключением NMT мастера и запроса
устройства CANopen)
Таблица 47 – Описание объекта
Value
1F82h
запрос NMT
ARRAY
UNSIGNED8
Дополнительный
Таблица 48 – Описание ввода
Описание
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Субиндекс
Значение
00h
Количество входов
Обязательный
const
No
80h
80h
01
h
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
to
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Идентификатор узла CANopen 1
Обязательный
rw
No
см Таблицу 46
00h
7Fh
Идентификатор узла CANopen 127
обязательный
rw
No
см Таблицу 46
00h
80h
Все узлы
Обязательный
wo
No
см Таблицу 46
00h
9.8.10 Объект 1F83h: запрос защиты узла
Данный объект должен направить запрос на защиту узла для уникального
устройства CANopen в сети или для всех устройств CANopen в сети в случае, если
устройство CANopen, осуществляющее этот объект, находится в основном режиме
NMT, то защита узла разрешается. Обычно, запрос выпущен другим устройством
CANopen (например, инструмент конфигурации) в сети или применением на том же
самом устройстве CANopen (например, в окружающей среде IEC 61131).
Субиндекс должен соответствовать ID узла CANopen устройств CANopen в сети.
субиндекс, соответствующий его собственному ID узла CANopen, должен быть
проигнорирован. Таблица 49 определяет содержание значение. Таблица 50 и Таблица
51 определяют описание объекта и описание входа.
Попытка загрузить значение, которое сохранено, прекращается сообщением
аварийного прекращения работы (кодекс аварийного прекращения работы: : 0800 0000h
или 0609 0030h).
Примечание - что потребитель Heartbeat пользуется объектом1016-м объектом (см. CiA301).
Таблица 49 – описание значения
74
Значен
ие
загрузка
ººh
Остановка
блокировки
узла
Описа Description
ние
(пись
в
мо)
ы
гр
Остановка
уз
блокировк
и узла к
а
(чтение)
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
01
h
02h
FFh
Запуск
блокировки
узла
сохранено
Сохранено
Старт
блокировк
и узла
Таблица 50 – описание объекта
свойство
индекс
Название
Код объекта
Тип данных
Категория
Значение
1F83h
Запрос защиты узла
ARRAY
UNSIGNED8
Дополнительный
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 51 - Entry description
Описание
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Значение
00h
Количество вводов
Обязательный
Постоянный
No
80h
80h
01 h
Идентификатор узла CANopen 1
Обязательный
rw
No
см Таблицу 49
00h
7F
h
Идентификатор узла CANopen 127
Обязательный
rw
No
см Таблицу 49
00h
80h
Все узлы
Обязательный
wo
No
см Таблицу 49
00h
9.8.11 объект 1F84h: идентификация типа устройства
Данный объект используется для проверки типа устройства в сети CANopen.
Тип устройства (1000-й объект - см EN 50325-4) устройства CANopen в сети
должен быть подобран согласно значениям данного объекта в случае, если значение
неравна 0. Ошибка может произойти в функции, если значения будут не совпадать. В
случае, если значение этого объекта равно 0, тип устройства CANopen в сети не может
быть проверен. Таблица 52 и Таблица 53 определяют описание объекта и описание
входа.
Субиндекс должен соответствовать ID узла CANopen устройства в сети.
Субиндекс, соответствующий его собственному ID узла CANopen, должен быть
76
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
проигнорирован. -
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
свойств
о
индекс
Название
Код
Тип
объекта
Категория
данных
Таблица 52 – описание объекта
Значение
1F84h
Запрос защиты узла
ARRAY
UNSIGNED8
Дополнительный
Таблица 53 – Описание ввода
свойство
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
to
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
Значение
00h
Количество вводов
Обязательный
Постоянный
нет
7Fh
7F
h
01 h
Идентификатор узла CANopen 1
Обязательный
rw
нет
См описание значения объекта 1000 h - EN
0000
0000h
50325-4
7Fh
Идентификатор узла CANopen 127
Обязательный
rw
нет
См описание значения EN 50325-4 объекта
1000 h
0000 0000h
9.8.12 Объект 1F85h: Идентификация поставщика
Данный объект должен использоваться для проверки идентификацию
поставщика устройств CANopen в сети.
Удостоверение личности Поставщика (объект 1018-му субиндекс 01 h - см, EN
50325-4) устройства CANopen в сети будет не соответствовать значению данного
объекта в случае, если значение неравна 0. Ошибка произойдет, если значения будут
78
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
не сочетаться. В случае, если значение этого объекта 0, идентификатор Поставщика
устройства CANopen в сети не может быть проверен. Таблица 54 и Таблица 55
определяют описание объекта и описание входа.
субиндекс должен соответствовать ID узла CANopen устройств CANopen в сети.
субиндекс, соответствующий его собственному ID узла CANopen, должен быть
проигнорирован.
Таблица 54 – Объект описания
Описан
ие
Индекс
Название
Код
Тип
объекта
Категория
данных
Значение
1F85h
Идентификация поставщика
ARRAY
UNSIGNED32
Дополнительный
Таблица 55 – Описание ввода
Описан
Значение
Субиндекс
ие
00h
Описание Количество вводов
Вводная
Обязательный
доступ
категория Постоянный
PDO
No
контроль
Диапазон
7Fh
По
показателей 7Fh
Субиндекс
умолчанию 01 h
Описание Идентификатор узла CANopen 1
Вводная
Обязательный
доступ
категория rw
PDO
No
Диапазон
См значение описания in EN 50325-4
контроль
показателей 0000
object0000
1018
По
h h субиндекс 01 h
to
умолчанию
Субиндекс 7Fh
Описание Идентификатор узла CANopen 127
Вводная
Обязательный
категория rw
доступ
PDO
No
Диапазон
См описание значения EN 50325-4
контроль
показателей
объект
1018
субиндекс 01 h
По
0000 0000
h h
умолчанию
9.8.13 Объект 1F86h: код продукта
Данный объект должен использоваться для проверки кода изделия устройств
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
CANopen в сети.
Код изделия (объект 1018-му субиндекс 02h - см, EN 50325-4) устройства
CANopen в сети будет не соответствовать значению данного объекта в случае, если
значение неравна 0. Ошибка произойдет, если значения будут не сочетаться. В
случае, если значение этого объекта 0, идентификатор Поставщика устройства
CANopen в сети не может быть проверен. Таблица 56 и Таблица 55 определяют
описание объекта и описание входа.
Субиндекс должен соответствовать ID узла CANopen устройств CANopen в сети.
Субиндекс, соответствующий его собственному ID узла CANopen, должен быть
проигнорирован.
Таблица 56 – Описание объекта
Описан
Значение
ие
Индекс
1F86h
Название
Идентификация поставщика
Код
ARRAY
Тип
UNSIGNED32
объекта
Категория
Дополнительный
данных
Таблица 57 - Entry description
Описан
Субиндекс
ие
Описание
Вводная
доступ
категория
PDO
контроль
Диапазон
По
показателей
Субиндекс
умолчанию
Описание
Вводная
доступ
категория
PDO
Диапазон
контроль
показателей
По
to
умолчанию
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
80
Значение
00h
Количество вводов
Обязательный
Постоянный
No
7Fh
7F
h
01
h
CANopen идентификатор узла 1
Обязательный
rw
No
См описание значения of EN 50325-4
object0000
1018
0000
h h субиндекс 02h
7F
h
CANopen идентификатор узла 127
Обязательный
rw
No
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Диапазон См описание значения EN 50325-4
По
0000
показателей 0000
объект
1018
h h субиндекс 02h
умолчанию
9.8.14 Объект 1F87h: ревизионный номер
Данный объект должен использоваться для проверки ревизионного номера
устройств CANopen в сети.
Ревизионный номер (объект 1018-му субиндекс 03h - см EN 50325-4) устройства
CANopen в сети будет не соответствовать значению данного объекта в случае, если
значение неравна 0.
Несоответствие определено как:
• главное число ревизии неравно ожидаемому главному числу ревизии, или
• незначительное число ревизии - меньше, чем ожидаемое незначительное число
пересмотра,
Ошибка произойдет, если значения будут не сочетаться. Таблица 58 и Таблица
59 определяют описание объекта и описание входа.
Субиндекс должен соответствовать с идентификатором узла CANopen в сети.
Субиндекс, соответствующий с идентификатором узла CANopen игнорируется.
Описан
ие
Индекс
Название
Код
Тип
объекта
Категория
данных
Описани
е
Субиндекс
Описание
Вводная
доступ
категория
PDO
Диапазон
контроль
По
показателей
умолчанию
Субиндекс
Описание
Вводная
доступ
категория
PDO
контроль
Диапазон
По
показателей
умолчанию
Таблица 58 – описание объекта
Значение
1F86h
Идентификация поставщика
ARRAY
UNSIGNED32
Дополнительный
Таблица 59 – описание ввода
Значение
ººh
Количество вводов
Обязательное
Постоянный
нет
7F
h
7F
h
01 h
Идентификатор узлаCANopen 1
Обязательный
rw
No
См значение описания 1018 h субиндекс
0000
03 h - 0000
EN 50325-4
h
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
to
Субиндекс
Описание
Вводная
доступ
категория
PDO
Диапазон
контроль
показателей
По
умолчанию
7F
h
Идентификатор узлаCANopen 127
Обязательный
rw
Нет
См значение описания 1018 h субиндекс
03 h00
- EN0000
50325-4
h
9.8.15 Объект 1F88h: серийный номер
Данный объект должен использоваться для проверки серийного номера
устройств CANopen в сети.
Код изделия (объект 1018-му субиндекс 04h - см, EN 50325-4) устройства
CANopen в сети будет не соответствовать значению данного объекта в случае, если
значение неравна 0. Ошибка произойдет, если значения будут не сочетаться. В
случае, если значение этого объекта 0, серийный номер устройства CANopen в сети
не может быть проверен. Таблица 61 и Таблица 60 определяют описание объекта и
описание входа.
Таблица 60 – описание объекта
Описание
Индекс
Название
Код объекта
Тип данных
Категория
Значение
1F88h
Идентификация поставщика
ARRAY
UNSIGNED32
Дополнительный
Таблица 59 – описание ввода
Описание
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
показателей
По
умолчанию
Субиндекс
Описание
Вводная
категория
доступ
82
Значение
ººh
Количество вводов
Обязательное
Постоянный
нет
7Fh
7Fh
01 h
Идентификатор узлаCANopen 1
Обязательный
rw
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
PDO
контроль
Диапазон
показателей
По
умолчанию
to
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
показателей
По
умолчанию
No
См значение описания 1018 h субиндекс 03 h - EN
50325-4
0000
0000h
7Fh
Идентификатор узлаCANopen 127
Обязательный
rw
Нет
См значение описания 1018 h субиндекс 03 h - EN
50325-4
0000
0000h
9.8.16 Объект 1F89h: Время загрузки
Объект определяет время между началом загрузки процесса Начала процесса
NMT и передачей сигналов успешной загрузки обязательных подчиненных NMT.
Детали определены в 9.4.3.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Значение должна быть дана в сети ms. При значении 0 необходимо отключить
таймер. Таблица 62 предоставляет описание объекта и Таблица 63 описание входа
Таблица 62 – Описание объекта
Описан
Значение
ие
Индекс
1F89h
Название
Время загрузки
Код
ARRAY
Тип
UNSIGNED32
объекта
Категория
Дополнительный
данных
Таблица 63 – Описание ввода
Описан
Значение
Субиндекс
ие
ººh
Описание rw
Вводная
нет
доступ
категория UNSIGNED32
PDO
0000 0000h
контроль
9.8.17 Объект 1F8Ah: Восстановление конфигурации
Данный объект используется, чтобы определить разрешенную процедуру
восстановления устройства CANopen во время запуска.
Процедура восстановления, формируемая в этом объекте, должна
использоваться, чтобы восстановить, во время запуска, каждое устройство CANopen
в сети (объект 1011 ч – см EN 50325-4) согласно записям объекта. Таблица 64 и
Таблица 65 определяют описание объекта и описание входа.
Субиндекс должен соответствовать ID узла CANopen устройств CANopen в
сети. Субиндекс, соответствующий его собственному ID узла CANopen, должен быть
проигнорирован.
Таблица 64 – Описание объекта
Описан
ие
Индекс
Название
Код
Тип
объекта
Категория
данных
84
Значение
1F8Ah
Конфигурация восстановления
ARRAY
UNSIGNED8
Дополнительно
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 65 – описание ввода
Описание
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
показателей
По
умолчанию
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
показателей
По
умолчанию
to
Субиндекс
Описание
Вводная
категория
доступ
PDO
контроль
Диапазон
показателей
По
умолчанию
Значение
ººh
Количество вводов
Обязательный
постоянный
No
7Fh
7Fh
01
h
CANopen идентификатор узла 1
Обязательный
rw
No
01 h to7F h
01
h
7Fh
CANopen Node-ID 127
Обязательный
rw
Нет
01 h to7F h
01
h
9.8.18 Объект 1F91h: Параметры самостоятельно запускающихся узлов
Данный объект определяет параметры, которые должны формироваться, чтобы
применить свойства для самостоятельного старта устройств CANopen. Таблица 66 и
Таблица 67 определяют описание объекта и описание входа.
Основной перерыв обнаружения NMT, время задержки запроса владельца NMT
и время узла должны быть в сети ms.
Таблица 66 – объект описания
Названи
е
Индекс
Название
Код
Тип
объекта
данных
Значение
1F91h
Параметры самостоятельно запускающихся
ARRAY
узлов
UNSIGNED16
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Категория
Дополнительный; Обязательный
для устройств CANopen
поддерживающие
самостоятельный запуск
Таблица 67 – Описание ввода
Название
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
00h
Количество вводов
обязательный
постоянный
нет
03h
03h
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
01
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
02
Субиндекс
Описание
Вводная категория
доступ
PDO контроль
Диапазон показателей
По умолчанию
03h
Время слота узла
Обязательный
rw
нет
UNSIGNED 16
15
Значени
е
h
NMT определения времени
Обязательный
rw
No
UNSIGNED16
100
h
NMT master request delay
Обязательный
time
rw
нет
UNSIGNED16
500
10 Функции шлюза
10.1 Содержание
Данный пункт содержит информацию о функциях шлюза
86
между Train
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Backbone, и сетью CANopen.
Сетевые службы доступа определены, чтобы позволить доступ к находящемуся
в CANopen, сети. Кроме того, определены этих служб доступа CANopen к протоколу
ASCII. Чтобы вписаться в структуру TCN, отображение этого протокола к
управленческим сообщениям определено в Пункте 11.
10.2 структура шлюза
Структура шлюза между Train backbone и сетью CANopen содержится в
Рисунке 29. В иллюстрации Train backbone указан как WTB.
Рисунок 29 - Шлюз между Train backbone и сетью CANopen
Шлюз соединяет Основой Поезд и сеть CANopen. Он передает данные о
процессе через применение шлюза и гарантирует правильное окончательное
представления данных с обеих сторон шлюза.
Примечание - что схема заказа передачи данных в CANopen является небольшим
в отличие от WTB, который использует конечный стиль.
Посредством управленческих сообщений TNM услуги TNM можно направлять
запросы обеим сторон шлюза. В дополнение к услугам, определенным в IEC
61375-2-1, далее определены услуги TNM (см. пункт 11.5), которые позволяют
полный контроль над дополнительными уровнями CANopen (см. сетевые службы
доступа, как определено в 10.4). Сетевые службы доступа, обеспеченные шлюзами
- между Основым Поездом и и сетью CANopen - дает один Узел, который связан с
Основным Поездом, доступ, чтобы выполнить функции на Устройствах на базе
CANopen.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Поскольку
отображение
управленческих
сообщений
TNM
к
коммуникационных объектов CANopen (ГЛЫБЫ) определено, также
управленческие услуги TNM доступны в пределах сети CANopen.
Как показано в рисунке 29, функциональность менеджера, а также
функциональность Агента находится на уровне приложения, как определено в IEC
61375-2-1. Кроме того, определенные для изготовителя пользовательские
заявления, а также стандартизированные заявления согласно профилям CANopen
(приложения профиля) могут находиться на этом уровне.
88
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
10.3 Общие принципы и сервисы
10.3.1 Содержание
Данный подкласс обеспечивает сетевые службы доступа, имеющие
устройством ворот, которое позволяет к доступу от Основы Поезда до сети CANopen.
10.3.2 Определения класса шлюза
Устройство CANopen, в котором функционирует шлюз Основы Поезда, может
поддержать один или больше следующих классов:
Класс 0: ворота - устройство, действует как сетевой подчиненный (рабская
функциональность NMT) в пределах сети CANopen. Устройство поддерживает
только способность передачи данных процесса. Шлюз этого класса не способны
сообщить TNM managment сообщения через сеть CANopen.
Класс 1: шлюз - устройство, действует как сетевой подчиненный (рабская
функциональность NMT) в пределах сети CANopen. Устройство должно обеспечить,
в дополнение к функциональности, определенной для шлюза Класса 0,
функциональности клиента SDO.
Класс 2: шлюз - устройство, осуществляющее функциональность устройства
Класса 1, который дополнительно осуществляет функциональность SDO согласно
требованиям устройства (SRD).
Класс 3: шлюз - устройство в пределах сети CANopen, действующей как
CANopen менеджер. Функциональность менеджера CANopen должна быть
достигнута, поддерживая основную функциональность NMT, а также
функциональность менеджера SDO.
Примечание - что Только устройства шлюза класса 1, 2 или 3 способны, чтобы сообщить управление
TNM сообщения в пределах сети CANopen.
10.3.3 Сервисные примитивы
Через сервисные примитивы используются услуги, которым взаимодействуют
применение шлюза и сетевой прикладной уровень. Сервисные примитивы
определены в IEC 61375-1.
10.4 Сервисная спецификация доступа к сети
10.4.1 SDO сервисы доступа
10.4.1.1
содержание
Услуги, определенные в этом пункте, используются, чтобы начать и
формировать услуги SDO, получающие доступ к любому объекту в словаре
объекта любого узла в любой из сетей CANopen, связанных с устройством шлюза.
10.4.1.2
загрузка SDO
Данный сервис инициирует SDO загрузку. Параметры сервиса указаны в
Таблице 68.
Таблица 68 – загрузка сервиса SDO
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Параметр
Аргумент
Network
Обязате
льно
дополнительно
Node-ID
дополнительно
Multiplexor
Mandato
ry
дополнительно
Data type
BOOLEAN
90
Индикация
Выбор
UNSIGNED8
Выбор
UNSIGNED16
Выбор
UNSIGNED24
Выбор
UNSIGNED32
Выбор
UNSIGNED40
Выбор
UNSIGNED48
Выбор
UNSIGNED56
Выбор
UNSIGNED64
Выбор
INTEGER8
Выбор
INTEGER16
Выбор
INTEGER24
Выбор
INTEGER32
Выбор
INTEGER40
Выбор
INTEGER48
Выбор
Ответ
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
INTEGER56
Выбор
INTEGER64
Выбор
REAL32
Выбор
REAL64
Выбор
TIME OF DAY
Выбор
TIME
DIFFERENCE
OCTET STRING
Выбор
VISIBLE
STRING
UNICODE
STRING
DOMAIN
Выбор
Выбор
Выбор
Выбор
Offset
дополнительно
Length
дополнительно
Remote result
Обязательно
Success
Выбор
Data
обязательно
Length
дополнительно
Failure
Reason
выбор
Обязательно
10.4.1.3 Загрузка SDO
Данный сервис инициирует загрузку SDO. Параметры сервиса указаны в
Таблице 69.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 69 – Загрузка параметров SDO
параметр
Network
индикац
ияя
Обязате
льно
дополнительно
Node-ID
дополнительно
Multiplexor
Mandato
ry
дополнительно
Argument
Data type
BOOLEAN
92
Выбор
UNSIGNED8
Выбор
UNSIGNED16
Выбор
UNSIGNED24
Выбор
UNSIGNED32
Выбор
UNSIGNED40
Выбор
UNSIGNED48
Выбор
UNSIGNED56
Выбор
UNSIGNED64
Выбор
INTEGER8
Выбор
INTEGER16
Выбор
INTEGER24
Выбор
INTEGER32
Выбор
Ответ
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
INTEGER40
Выбор
INTEGER48
Выбор
INTEGER56
Выбор
INTEGER64
Выбор
REAL32
Выбор
REAL64
Выбор
TIME OF DAY
Выбор
TIME
DIFFERENCE
OCTET STRING
Выбор
VISIBLE
STRING
UNICODE
STRING
DOMAIN
Выбор
Выбор
Выбор
Выбор
Offset
дополнительно
Length
дополнительно
Data
Обязате
льно
Remote result
Mandatory
Success
Selection
Failure
Selection
Reason
Mandatory
10.4.1.4 Конфигурация задержки SDO
Данный сервис конфигурирует задержку для Клиента -SDOs на устройстве
шлюза. Параметры для сервиса установлены в Таблице 70.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 70 – Конфигурация параметров задержки SDO
Параметр
аргумент
сеть SDO
задержка
Результат
Индикация
Обязательный
Дополни
тельный
Обязате
льный
Ответ
Обязательный
Выбор
Выбор
Обязател
ьный
удаленного
доступа
Success
Failure
10.4.2 PDO
сервисы доступа
причина
10.4.2.1 Содержание
Услуги, определенные в этом пункте, используются, чтобы формировать и
начать услуги PDO в устройстве ворот. Они включают:
• Формируйте получение PDO
• Формируйте передачу PDO
• чтение PDO
• Просьба PDO
• Укажите на полученный PDO
Две услуги конфигурации PDO предназначены, чтобы создать PDOs в
устройстве шлюза. Если устройство шлюза осуществит словарь объекта, то записи
параметра коммуникации и отображения PDO должны быть установлены
соответственно. Две услуги по запросу PDO предназначены, чтобы управлять PDOs
в соответствии с формируемым типом передачи PDO. Типы данных
VISIBLE_STRING, OCTET_STRING, и UNICODE_STRING, а также ОБЛАСТЬ не
должны использоваться в качестве параметра типа данных ПЕРВЕНСТВА.
ОТМЕТЬТЕ, что услуги ПЕРВЕНСТВА не предназначены для формирования
записи коммуникации и отображения PDO словаря объекта отдаленных узлов.
Доступ к узлам CANopen индивидуально посредством услуг SAS может
реализовать конфигурацию PDO.
10.4.2.2 Формируйте RPDO
Данное обслуживание должно создать RPDO в устройстве шлюз. Таблица 71
определяет параметры для этого обслуживания.
Таблица 71 - конфигурация RPDO сервисные параметры
параметр
94
индикаци
я
ответ
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Argument
Network PDO
number COB-ID
TxType
Nbr_objects 1st
mapped object
Data type
Multiplexor 2nd
mapped object
Data type
Multiplexor
64th mapped
object Data type
Multiplexor
Remote result
Success
Failure
Reason
Обязательный
Дополнительный
Обязательный
Обязательный
Обязательный
Обязательный
Обязательный
Выбор Выбор
Дополнительный
Выбор Выбор
Дополнит
ельный
Выбор
Выбор
Обязательный
Выбор Выбор
Обязательный
10.4.2.3 Конфигурация TPDO
Данный сервис TPDO шлюзовое устройство. Таблица 72 определяет функций.
Таблица 72 - конфигурация TPDO сервисные параметры
Parameter
Argument
Network PDO number
COB-ID TxType
Nbr_objects 1st mapped
object Data type
Multiplexor 2nd mapped
object Data type
Multiplexor
64th mapped object
Data type
Multiplexor
Indication
Response
Обязательный
Дополнительный
Обязательный
Обязательный
Обязательный
Обязательный
Обязательный Выбор
Выбор Дополнительный
Выбор Выбор
Дополнительный Выбор
Выбор
Remote result
Success Failure
Reason
Обязательный
Выбор
Выбор Обязательный
10.4.2.4 Чтение PDO данные
Данный сервис должно читать данные, полученные RPDO. Если RPDO будет
формироваться с типом 252 или 253 передачи, то устройства шлюза должны
вызвать его посредством RTR.
Примечание - что не рекомендуется использовать RTR.
Полученные данные должны быть переданы в отдаленном результате. Таблица 73
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
определяет параметры для этого сервиса.
Таблица 73 - чтение PDO данные параметров сервисов
параметр
Argument
Network
PDO number
Remote result
Success
Network PDO
number
Nbr_objects
Data 1st object
Data 64th object
Failure Reason
индикация
Обязательный
Дополнительный
Обязательный
ответ
Обязательный
Выбор
Дополнительный
Обязательный
Обязательный
Conditional
Conditional Выбор
Обязательный
10.4.2.5 Запись данных PDO
Данный сервис поддерживает транмиссию PDO. Фактическая трансмиссия
PDO поддерживается согласно указанному типу трансмиссии PDO.
Параметры данного сервиса указаны в таблице 74.
Таблица 74 – написание данные по сервисным параметрам PDO
Параметр
Argument
Network PDO
number Nbr
objects Data 1st
object
Data 64th object
Индикация ответ
Обязательный
Дополнительный
Обязательный
Обязательный
Conditional
Conditional
Обязательный
Выбор Выбор
Обязательный
Remote result
Success Failure Reason
10.4.2.6 Полученное RPDO
Данный сервис подает сигнал при получении новых данных PDO и передает
полученные данные.
Параметры данных приведены в Таблице 75.
Таблица 75 – полученные сервисные параметры RPDO
параметр
96
запрос
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Argument
Network PDO number
Nbr_objects 1st
object value
64th object value
Обязательный
Дополнительный
Обязательный
Обязательный
Conditional
Conditional
10.4.3 CANopen NMT сервисы
10.4.3.1 Содержание
Сервисы, определенные в данном пункте используются для контролю
устройства CANopen или сети CANopen также ассоциированных сервисов по
контролю ошибок.
10.4.3.2 Стартовый узел
Данный сервис должен установить узлы CANopen в статус ГОТОВЫЙ К
ЭКСПЛУАТАЦИИ NMT. Для устройств Класса 1 и Класса 2 данный сервис должен
направить Запрос CANopen NMT. Для устройств Класса 3 сервис должен направить
Старт удаленного сервисного Узла. Для устройств Класса 0 данный сервис определяет
уведомление о неудаче как отдаленный результат. Таблица 76 определяет параметры
для этого сервиса.
Таблица 76 – Сервисные параметры стартового узла
Параметр
Argument
Network Node-ID All
Remote result
Success Failure Reason
Индикац
ия
Обязательный
Дополнительный
Выбор Выбор
ответ
Обязательный
Выбор Выбор
Обязательный
10.4.3.3 Останавливающий узел
Данный сервис должен установить узлы CANopen в статус ОСТАНОВКИ NMT. Для
устройств Класса 1 и Класса 2 данный сервис должен направить Запрос CANopen
NMT. Для устройств Класса 3 сервис должен направить Старт удаленного сервисного
Узла. Для устройств Класса 0 данный сервис определяет уведомление о неудаче как
отдаленный результат. Таблица 76 определяет параметры для этого сервиса.
примечание, что отдаленный результат для устройств класса 1 и 2 - только
подтверждение запроса SDO; для устройств класса 3 отдаленный результат основан
на ошибочных контрольных сервисах, как определено в EN 50325-4.
Таблица 77 – Сервисные параметры останавливающего узла
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Параметр
Индика
ответ
Argument
Обязате
ция
Network
льный
Node-ID
Дополни
Remote
result
Обязательный
All
тельный
Success
Выбор
Выбор
Failure
Выбор
Выбор
Reason
Обязател
10.4.3.3.1 Настройка узла на «ПРЕДПУСКОВОЕ»
ьный
Это обслуживание должно установить узлы CANopen в статус
ПРЕДПУСКОВОЕ NMT. Для устройств Класса 1 и Класса 2 данный сервис должен
направить Запрос CANopen NMT. Для устройств Класса 3 сервис должен направить
Старт удаленного сервисного Узла. Для устройств Класса 0 данный сервис определяет
уведомление о неудаче как отдаленный результат. Таблица 76 определяет параметры
для этого сервиса.
Таблица 78 – Сервисные параметры настройки на «ПРЕДПУСКОВОЕ»
Параметр
Argument
Network Node-ID All
Индикац
Обязательный
ия
Дополнительный
Выбор Выбор
Remote result
Success Failure Reason
ответ
Обязательный
Выбор Выбор
Обязательный
10.4.3.4 Перезагрузка узла
Данный сервис перезагружает узлы CANopen в NMT путем RESET
APPLICATION. Для устройств Класса 1 и Класса 2 данный сервис должен направить
Запрос CANopen NMT. Для устройств Класса 3 сервис должен направить Старт
удаленного сервисного Узла. Для устройств Класса 0 данный сервис определяет
уведомление о неудаче как отдаленный результат. Таблица 79 определяет параметры
для этого сервиса.
Таблица 79 – Сервисные параметры для перезагрузки узла
Параметр
Индикация
Ответ
Argument
Network Node-ID All
Обязательный
Дополнительный
Выбор Выбор
Remote result
Success Failure
Reason
10.4.3.5
98
Переустановка коммуникации
Обязательный
Выбор Выбор
Обязательный
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Данный сервис переустанавливает узлы CANopen в NMT state RESET
COMMUNICATION. Для устройств Класса 1 и Класса 2 данный сервис должен
направить Запрос CANopen NMT. Для устройств Класса 3 сервис должен направить
Старт удаленного сервисного Узла. Для устройств Класса 0 данный сервис определяет
уведомление о неудаче как отдаленный результат. Таблица 79 определяет параметры
для этого сервиса.
Таблица 80 – Сервисные параметры для перезагрузки коммуникации
Параметр
Argument
Network Node-ID All
Индикация
Обязательный
Дополнительный
Выбор Выбор
Ответ
Обязательный
Выбор Выбор Обязательный
Remote result
Success Failure Reason
10.4.3.6 Включение блокировки узла
Данный сервис доступна для устройства класса 3. Данный сервис должен
начать блокировку узла для устройства, определенного ID узла CANopen с
параметрами, данными GuardTime и LifeTimeFactor. Если heartbeat будет уже
активировано на обращенном узле, то запрос на сервис должен быть отклонен.
Таблица 81 определяет параметры для этого сервис.
Таблица 81 – Сервисные параметры подключение блокировки
Параметр
Argument
Network Node-ID
GuardTime
LifeTimefactor
индикация
ответ
Обязательный
Дополнительный
Обязательный
Обязательный
Обязательный
Обязательный
Выбор Выбор
Обязательный
Remote result
Success Failure
Reason
10.4.3.7 Отключение блокировки узла
Данный сервис доступен только для устройств класса3. Он прекратит
блокировку узла для устройства, указанного в CANopen Node-ID. Таблица 82
определяет параметры данного сервиса.
Таблица 82 – Отключение сервисных параметров блокировки узла
Параметр
Индикация
Ответ
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Argument
Network NodeID
Обязательный
Дополнительный
Обязательный
Обязательный
Выбор Выбор
Обязательный
Remote result
Success Failure
Reason
10.4.3.8 Старт потребителя heartbeat
Данный сервис начинает потребление сообщений heartbeat переданных
устройством CANopen указанный в CANopen Node-ID. Таблица 83 defines parameters
for this service.
Таблица 83 - Start heartbeat consumer service parameters
Parameter
Argument
Network Node-ID
HeartbeatConsumerTime
Indication
Response
Обязательный
Дополнительный
Обязательный Обязательный
Обязательный
Выбор Выбор
Обязательный
Remote result
Success Failure
Reason
10.4.3.9 Disable heartbeat consumer
This service shall stop the consumption of heartbeat messages transmitted by a
CANopen device specified by CANopen Node-ID. Таблица 84 определяет параметры
данного сервиса.
Таблица 84 – отключение сервисных параметров потребителя heartbeat
Параметр
Argument
Network Node-ID
Индикация
Обязательный
Дополнительный
Обязательный
ответ
Обязательный
Выбор Выбор
Обязательный
Remote result
Success Failure
Reason
10.4.3.10 Получение уведомления об ошибке
Данный сервис должен сигнализировать о статусе NMT или ошибочных
событиях контроля, полученных от узла CANopen, определенного ID узла CANopen.
Таблица 85 определяет параметры для этого сервиса.
Таблица 85 – Параметры получения уведомления об ошибке
Параметр
100
просьба
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Argument
Network Node-ID Status Error Code
Обязательный
Дополнительный Обязательный
Выбор Выбор
10.4.4 Сервис управления поломками устройства
10.4.4.1
Общая информация
Услуги, определенные в этом пункте, используются, чтобы управлять неудачами
в пределах устройства шлюза или в пределах любого другого устройства CANopen.
10.4.4.2
Чтение ошибки устройства
Данный сервис должен прочитать информацию о сообщении EMCY,
полученную от устройства CANopen, определенного параметром ID узла CANopen.
Таблица 86 определяет параметры для этого сервиса.
Таблица 86 – Сервисные Параметры устройства чтения ошибок
параметр
Argument
Network
Node-ID
Индикация
Обязательный
Дополнительный
Дополнительный
Ответ
Обязательный
Выбор
Дополнительны
й Обязательный
Выбор
Обязательный
Дополнительны
й Выбор
Обязательный
Дополнительны
10.4.4.3 Получение уведомления о чрезвычайной
ситуации
й
Данный сервис должен сигнализировать о приеме чрезвычайного сообщения в
Дополнительны
устройстве шлюза, переданном устройством CANopen,
определенным ID узла
й
Выбор
CANopen. Таблица 87 определяет параметры для этого сервиса.
Обязательный
Таблица 87 – Сервисные параметры уведомления
о чрезвычайной ситуации
Remote result
Success Network NodeID Error Error Msg
number Error Msg text
Emergency Emergency
code Error register
Manufacturer error
Failure Reason
Параметр
запрос
Argument
Network
Node-ID
Emergency code
Error register
Manufacturer error
Обязательный
Дополнительный
Обязательный
Обязательный
Обязательный
Дополнительный
10.4.5 Интерфейсные конфигурационные сервисы CANopen
10.4.5.1
общая информация
Сервисы, описанные в данном разделе используются для конфигурации и
параметиризации интерфейс шлюзного устройства.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
10.4.5.2
инициализация шлюза
Данный сервис должен начать инициализацию CANopen устройства шлюза. Это
должно выполнить сбросе интерфейса CANopen. Данный сервис используется, чтобы
инициализировать параметры тактовой синхронизации. Таблица 88 определяет
параметры для данного сервиса.
Таблица 88 – Сервисные параметры инициализации шлюза
Параметр
Индикация
Argument
Network CAN bit
timing
Обязательный
Дополнительный
Дополнительный
Ответ
Обязательный
Выбор Выбор
Обязательный
Remote result
Success Failure
Reason
10.4.5.3 Конфигурация хранения
Данный сервис передает команду шлюзному устройству для сохранения
интерфейсной конфигурации CANopen. Таблица 89 определяет сервисные параметры
данного сервиса.
Таблица 89 – Сервисные параметры конфигурации хранения
Параметр
Argument
Network Storage
specifier
Remote result
Success Failure
Reason
Индикация
Обязательный
Дополнительный
Дополнительный
Ответ
Обязательный
Выбор Выбор
Обязательный
10.4.5.4 Конфигурация пересохранения
Данный сервис передает команду шлюзному устройству для сохранения
интерфейсной конфигурации CANopen. Таблица 90 определяет сервисные параметры
данного сервиса.
Параметр
Индикация
Argument
Обязательный
Network Storage specifier Дополнительный
Дополнительный
Remote result
Success Failure Reason
102
Ответ
Обязательный
Выбор Выбор
Обязательный
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
10.4.5.5 Настройка производителя heartbeat
Данный сервис настраивает heartbeat шлюзному устройству для сохранения
интерфейсной конфигурации CANopen. Таблица 90 определяет сервисные параметры
данного сервиса.
Таблица 91 – сервисные параметры по настройке производителя heartbeat
Ответ
Параметр
Индикация
Argument
Обязательный
Network Node-ID Heart Дополнительный
beat Prod ucerTi me
Обязательный
Обязательный
Remote result
Обязательный
Success Failure
Выбор Выбор
Reason
Обязательный
10.4.5.6 Настройка узла идентификатора-ID
Данный сервис должен настраивать идентификатор узла CANopen в шлюзном
устройстве для сети CANopen, установленное в параметрах сети. Таблица 92
определяет параметры данного сервиса.
Таблица 92 – Сервисные параметры настройки идентификатора узла
Параметр
Argument
Network Node-ID
Индикация
Обязательный
Дополнительный
Обязательный
Remote result
Success Failure
Reason
Ответ
Обязательный
Выбор Выбор
Обязательный
10.4.5.7 Старт получения аварийных сообщений
Данный сервис должен начать получение аварийных сообщений. Отношение
между ID узла CANopen, производящим чрезвычайное сообщение и ID, должно быть
четко ясным. Таблица 93 определяет параметры для этого сервиса.
Таблица 93 – Сервисные параметры получения аварийных сообщений
Параметр
Argument
Network NodeID COB-ID
Индикация
Обязательный
Дополнительный
Обязательный
Обязательный
Ответ
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Обязательный
Выбор Выбор
Обязательный
Remote result
Success Failure
Reason
10.4.5.8 Остановка аварийных сообщений
Данный сервис должен прекратить получение аварийных сообщений.
Отношение между ID узла CANopen, производящим чрезвычайное сообщение и ID,
должно быть четко ясным. Таблица 94 определяет параметры для этого сервиса.
Таблица 94 – Сервисные параметры остановки аварийных сообщений
Параметр
Argument
Network
Node-ID
COB-ID
Remote result
Success Failure
Reason
Индикация
Обязательный
Дополнительный
Обязательный
Обязательный
Ответ
Обязательный
Выбор Выбор
Обязательный
10.4.6 10.4.6.1Сервисы управления шлюзом Общая информация Сервисы,
определенные в настоящем разделе, предназначены для управления шлюзным
устройством
10.4.6.2 Настройка сети по умолчанию
Данный сервис установит номера сети по умолчанию. Таблица 95
определяет параметры сервиса
Таблица 95 – Сервисные параметры настройки сети по умолчанию
Параметр
Argument
DefaultNetwork
Remote result
Success Failure Reason
Индикация
Обязательный
Обязательный
Ответ
Обязательный
Выбор Выбор
Обязательный
10.4.6.3 Настройка по умолчанию идентификатора узла
Данный сервис должен установить настройку для идентификатора узла
CANopen Node-ID, который используется для всех услугг. Таблица 96 определяет
параметры для данного сервиса.
Таблица 96 – Сервисные параметры старта идентификатора узла по умолчанию
104
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Параметр
Индикация
Argument
Default node-ID
Remote result
Success Failure Reason
Ответ
Обязательный
Обязательный
Обязательный
Выбор Выбор
Обязательный
10.4.6.4 Получение
Данный сервис получает информацию на шлюзное устройство и на интерфейс
CANopen. Таблица 97 определяет параметры данного сервиса.
Таблица 97 – сервисные параметры получения
Параметр
Argument
Network
Remote Result
Success Vendor-ID Product
code Revision number Serial
number Gateway class
Protocol version
Implementation class Failure
Reason
Индикация
Обязательный
Дополнительный
Ответ
Обязательный
Выбор
Обязательный
Обязательный
Обязательный
Обязательный
Обязательный
Обязательный
Обязательный
Выбор
Обязательный
10.4.7 Специальные сервисы для производителя
Производитель шлюзного устройства может определить дополнительные
сервисы.
10.5 ASCII контроль доступа к сети
10.5.1 содержание
Данный раздел определяет контроль сервисов доступа к коммуникационным
синтаксисам на базе ASCII-для шлюзных устройств CANopen. Данный протокол
контролируется данными сообщения TCN.
10.5.2 Определения
10.5.2.1
Команда
Команда управляет шлюзами и взаимодействует с устройствами CANopen. У
этого сервиса могут быть полная форма и краткая форма. Краткая форма – одна или
две аббревиатуры письма в длинной форме. Полная форма получается путем
концентрации краткой формы, и приложения в скобках скобках" [", "]".
Примечание - В данных примерах, предполагается, что сетевой адрес и адрес узла заданы заранее.
10.5.2.2 Синтаксис типа данных
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Обязательные типы данных, указанные в Таблица 98, должны поддерживаться.
Таблица 98 – синтаксис и типы данных CANopen
Синтаксис
b
u8
u16
u24
u32
u40
u48
u56
u64
i8
i16
i24
i32
i40
i48
i56
i64
r32
r64
t
td
vs
CANopen тип
Boolean
UNSIGNED8
UNSIGNED16
UNSIGNED24
UNSIGNED32
UNSIGNED40
UNSIGNED48
UNSIGNED56
UNSIGNED64
INTEGER8
INTEGER16
INTEGER24
INTEGER32
INTEGER40
INTEGER48
INTEGER56
INTEGER64
REAL32
REAL64
Time of day (with two arguments:
day
Timems)
difference
Visible string
OS
us
d
Octet string
Unicode string
Domain
Категория
Обязательн
ый
Обязательн
ый
Обязательн
ый
Дополнител
ьный
Обязательн
ый
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Обязательн
ый
Обязательн
ый
Дополнител
ьный
Обязательн
ый
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Дополнител
ьный
Примечание - ЗНАЧЕНИЕ типа данных, последовательности октета, и последовательность
unicode ЗАШТРИХОВАН в 64, как описано в 2045 RFC.
Все сокращенные CRLF должны быть расшифрованы, чтобы иметь одну
длинную последовательность.
10.5.2.3
Свободное пространство
Свободные пространства, как определено в ISO/IEC 9899 кроме CR и LF.
Примечание - что видимая последовательность со свободным пространством приложена к
двойным кавычкам, чтобы обозначить его как единственный аргумент команды. Если
двойная цитата используется в последовательности, кавычек нужно избегать, например,
"Привет ""Мир"", CANopen ".
10.5.2.4
Структура команды
10.5.2.4.1 Общая информация
106
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Принципиальная коммуникация основана на последовательностях
ASCII с учетом регистра согласно ISO/IEC 646 вместо структуры и
центрального
процессора/компилятора,
зависящего
от
двойной
структуры. Из-за этого, никакое приложение не применяется в отношении
размеров данных и выравнивание байта. Во всех случаях, где числа
используются, типичное представление определено в ISO/IEC 9899.
100 - десятичное число, начинающееся с числа
0x64 - шестнадцатеричный, начинающийся с последовательности 0x
1.22 – плавающая точка
.22e10 - плавающая точка
22e3 - плавающая точка
10.5.2.4.2 Запрос
Шлюзами CANopen управляют команды. Команда составлена из
символов, которые отделены любым числом свободного пространства, и
закрыт с CRLF.
Все команды подтверждены. Команды начинаются с порядкового
номера, который приложен квадратными скобками []. Порядковый номер 4-байтовое значение. Это не используется для вызванных событием
сообщений. Согласно принципу обращения, сетевое число и число узла
следуют за порядковым номером. Сетевое число и число узла дополнительный, когда шлюз CANopen только одну сеть основного поезда
CANopen или когда клиент задает их. Команды, которые затрагивают только
сервер не отдаленный узел, а сеть и узел, даны, и узел игнорируются. В
примечании BNF примечание команды предоставлено в Таблице 99:
Таблица 99 – Изображение команды в BNF
Чистые числа начинаются с 1. Числа узла начинаются с 1. значение 0
для чистого или узла используется для адресации ко всем сетям или всем
узлам.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Символ «value»; определяет значение возможных типов данных CANopen.
В рамках описания команд порядковый номер опущен по причинам
удобочитаемости.
10.5.2.4.3 Ответ
Шлюз CANopen должны ответить тем же самым порядковым номером в
первом положении, как дано запросом. Это число должно быть дано в
десятичном формате. Должен быть только один ответ на запрос. Примечание
ответа предоставлено в Таблица 100.
Таблица 100 - Обозначение ответа
коды sdo-abort- (SAC) определены в EN 50325-4. Разрешенные коды
внутренних ошибок (InEC) указаны в Таблице 101:
Таблица 101 – код внутренней ошибки (InEC)
InEC
100
101
102
103
Текст сообщения
запрос, не поддержанный
Синтаксическая ошибка
Запрос, не обработанный из-за
внутреннего
Перерыв (гдесостояния
применимый)
200
201
202
203
205
Потерянное сообщение
Потерянная связь
heartbeat началось
heartbeat
Начальная загрузка
300
301
303
304
305
400
401
Пассивная ошибка
Удаление шлейфа
CAN буферизовать переполнение
CAN init
CAN активный (в init или запуске)
PDO использован
PDO удлиненная длина
Примечание ПОСЛЕ УДАЛЕНИЯ шлейфа, необходимо использовать команду init для
перезагрузки CAN контроллера.
10.5.2.4.4 Событийно управляемое сообщение
Сообщения из-за ошибок в сети CANopen или возникновении
коммуникационных объектов, используя принцип производителя-потребителя
не должны использовать порядковый номер. Примечание для вызванных
событием сообщений предоставлено в Таблица 102.
Таблица 102 – Обознаяение событийно управлляемых сообщений
108
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
<event-trigged-message>::= [[net] node] <event-specifier> <parameter>
<event-specifier>::= "EMCY" | "ERROR" | "PDO" | "SYNC" | "USER"
Содержание вызванных событием сообщений описано в рамках описания
команды, которое позволяет определенное обслуживание.
10.5.3 Командная спецификация сети спецификация команды доступа
10.5.3.1 SDO команды доступа
10.5.3.1.1 Общая информация
Следующие определения команды должны использоваться, чтобы
осуществить службы доступа SDO, как определено в 10.4.
Службы доступа SDO обращаются к конкретной цели в сервере SDO через
индекс и подындекс и типа данных передачи.
10.5.3.1.2 загрузка команды SDO
Индикационный синтаксис указан в Таблице 103.
Таблица 103 – Синтаксис для выгрузки команды SDO
[[net] node] r[ead] <multiplexor> <datatype>
примеры приведены в Таблице 104.
Таблица 104 - примеры для выгрузки команды SDO
[21] r 0x1000 0 u32
[4096] read 0x1008 0 vs _____________________________________________
Синтаксис ответа:
см.10.5.2.4.3.
10.5.3.1.3 Загрузка команды SDO
Индикационный синтаксис указан в Таблице 105.
Таблица 105 – Синтаксис для загрузки команды SDO
[[net] node] w[rite] <multiplexor> <datatype> <value>
примеры приведены в Таблице 106.
Таблица 106 - Примеры для загрузки команды SDO
[20] 1 23 w 0x1016 0 u16 100
[23] write 0x1016 0 u16 0x64 _________________________________________
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.1.4 ConРисунок SDO timeout command Время задержки перерыва для
кода ошибки аварийного прекращения работы 'протокол SDO, рассчитанный',
используемый клиентом шлюзаSDO, может быть установлено. Индикационный
синтаксис указан в Таблице 107.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 107 – Синтаксис для конфигурации времени команды SDO
[net] set sdo timeout <ms>
Ответный синтаксис:
См раздел 10.5.2.4.3.
10.5.3.2 PDO команды доступа
10.5.3.2.1 Общая информация
Следующие определения команды должны использоваться для выполнения
функции сервиса доступа PDO, как определено в 10.4. Обычно PDO сначала
формируется перед передачей и приемом.
PDO замечен по представлению о шлюзах. RPDO поэтому получает данные от сети
CANopen, и TPDO посылает данные в сеть CANopen.
примечание, для удаления шлюза PDO, бит 31 в ID используется. Поскольку детали
относятся к EN 50325-4.
10.5.3.2.2 Конфигурация команды RPDO
Индикационный синтаксис указан в Таблице 108.
Таблица 108 – синтаксис конфигурации комнады RPDO
[[net] node] set rpdo <nr> <COB> <tx-type> <nr-of-data> <map-obj1>
[. .<map-obj 64>]
<tx-type>::= "rtr" | "event" | "sync<0..240>"
Примечание - In case a <map-obj> is given in form of index and sub-index, e.g.
<multiplexor>, they are counted as 1 in the <nr-of-data>. The <nr> is an offset; it starts
with 1.
Примеры приведены Таблица 109.
Таблица 109 - Examples for conРисунок RPDO command
[12] set rpdo 1 0x180 event 3 u8 u8 u16
[24] 2 set rpdo 1 0x180 event 3 u8 u8 i16 _________________________________
Response Синтаксис:
см. 10.5.2.4.3.
10.5.3.2.3 ConРисунок TPDO command
Индикационный Синтаксис is provided in Таблица 110.
Таблица 110 - Синтаксис for conРисунок TPDO command
[[net] node] set tpdo <nr> <COB> <tx-type> <nr-of-data> <map-obj1> [. .<map-obj 64>]
Примечание - В случае, если <карта-obj> дан в форме индекса и подындекса, т.е.
<мультиплексора>, они посчитаны как 1 в <номер данных>. <Номер>
погашение; это начинается с 1.примеры приведены в Таблице 111.
110
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 111 - Examples for configue TPDO command
[13] set tpdo 1 0x201 rtr 4 u8 u16 u16 u8
ответный синтаксис:
см 10.5.2.4.3.
Примечание - не рекомендуется поддержать RTR. Поэтому рекомендуется установить
бит 30 из ID соответственно. Поскольку детали видят EN 50325-4.
10.5.3.2.4 Чтение PDO командные данные
Индикационный синтаксис указан в Таблице 108.
Таблица 112- Синтаксис для чтение данных PDO
[net] r[ead] p[do] <nr>
NIf тип передачи отличается, чем RTR, ответы ворот с значениями нанесенных на
карту объектов.Ответные синтаксисы приведены в Таблице 113.
Таблица 113 – Ответный синтаксис чтение данных команд PDO
[net] pdo <nr> <nr-of-data> <value1>[..<value64>]
10.5.3.2.5 письмо PDO данные команды
Индикационный синтаксис указан в Таблице 114.
Таблица 114 - Ответный синтаксис написания данных команд PDO
[net] w[rite] p[do] <nr> <nr-of-data> <value1>[..<value64>]
ответный синтаксис:
см 10.5.2.4.3.
10.5.3.2.6 RPDO полученная команда
Индикационный синтаксис указан в Таблице 115.
Таблица 115 – Синтаксис для получение команды RPDO
[net] pdo <nr> <nr-of-data> <value1>[..<value64>]
примеры приведены в таблице 116.
Таблица 116 - примеры RPDO полученной команды
1 pdo 1 2 123 4
;# gateway with more than one network
;# received RPDO1 at net 1 with two objects ;# mapped
pdo 2 1 1234
;# RPDO2 with one object mapped
pdo 2 3 100 2 4
;# three objects mapped
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
10.5.3.3 CANopen NMT commands
10.5.3.3.1 общая информация
Следующие определения команды должны использоваться, чтобы осуществить
CANopen NMT услуги, как определено в 10.4. Поддерживаемые услуги зависят от
класса шлюз.
10.5.3.3.2 Start node command
Индикационный синтаксис указан в таблице 117.
[[net]
Таблица 117 – синтаксис для команды старта узла
node] start
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.3 команда остановки узла
Индикационный синтаксис указан в таблице 118.
Таблица 118 – синтаксис для остановки узла
[[net] node] stop
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.4 Настройка узла для предзапусковой команды
Индикационный синтаксис указан в таблице 119.
Таблица 119 - Настройка узла для предзапусковой команды
[[net] node] preop[erational]
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.5 Reset node command
Индикационный синтаксис указан в таблице 120.
Таблица 120 – синтаксис команды переустановки узла
[[net] node] reset node
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.6 Переустановка команды коммуникации
Индикационный синтаксис указан в таблице 121.
Таблица 121 – синтаксис переустановки команды коммуникации
[[net] node] reset comm[unication]
112
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.7 Enable node guarding command
Активация блокирующей функциональности узла позволяет получение
собитийного сообщение в качестве ответа клиентам шлюза. Только в случае, если
один из проверенных узлов CANopen нарушает протокол охраны, то сообщение
событий нужно послать клиентам. Индикационный синтаксис указан в таблице 122.
Таблица 122 – Синтаксис, активирующий команду защиты узла
[[net] node] enable guarding <guardingtime>
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.8 Отключение команды блокировки узла
Индикационный синтаксис указан в таблице 123.
Таблица 123 – синтаксис Отключения команды блокировки узла
[[net] node] disable guarding
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.9 Старт команды потребителя heartbeat
Активация потребителя heartbeat позволяет получение собитийного сообщение
в качестве ответа клиентам шлюза. Только в случае, если один из проверенных узлов
CANopen нарушает протокол охраны, то сообщение событий нужно послать
клиентам.Индикационный синтаксис указан в таблице 124.
Таблица 124 – синтаксис Старт команды потребителя heartbeat
[[net] node] enable heartbeat <heartbeattime>
Ответный синтаксис:
см. 10.5.2.4.3.
10.5.3.3.10 Отключение команды потребителя heartbeat
Индикационный синтаксис указан в таблице 125.
Таблица 125 – синтаксис Отключения команды потребителя heartbeat
[[net] node] disable heartbeat
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.3.11 Получение команды события контроля ошибки
Ответный синтаксис определен в Таблица 126.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Таблица 126 - синтаксис Получения команды события контроля ошибки
[[net] node] ERROR <internal-error-code>
10.5.3.4 Устройства провала управления командами
10.5.3.4.1 общая информация
Следующие определение команды будут использованы для применения
Устройства провала управления командами как указано в 10.4.4.
10.5.3.4.2 Чтение команды ошибки в устройстве
Индикационный синтаксис указан в таблице 127.
Таблица 127 – синтаксис Чтения команды ошибки в устройстве
[[net] node] r[ead] error
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.4.3 Получение аварийных команд
Ответный синтаксис определен в Таблице 128.
Таблица 128 – синтаксис получения аварийных команд
[[net] node] EMCY <emcy-code> <error-register> <m-error-code>
(Изготовитель) - ошибочный кодекс должен быть возвращен в качестве пяти
десятичных значений, соответствующих определенному для изготовителя коду
ошибки в сообщении EMCY.
10.5.3.5 CANopen интерфейсные конфигурационные команды
10.5.3.5.1 общая информация
Следующие определения команды должны использоваться для выполнения
услуг конфигурации интерфейса CANopen, как определено в 10.4.5. Параметры
настройки действительны для сети по умолчанию, если никакой сетевой адрес не
предоставлен. Адрес узла должен быть опущен, в случае, если он предоставлен.
10.5.3.5.2 Инициализация команды шлюза
Индикационный синтаксис указан в таблице 129.
Таблица 129 – синтаксис инициализации команды шлюза
[net]
init <bitrate>
диапазон бита приведен в таблице индекса стандартов. Диапазон битов CANopen
определены в Таблице 130.
Таблица 130 – индекс диапазона бита
Индекс
Диапазон бита
1 мбит/с
0
800 кбит/с
1
114
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
2
3
4
5
6
7
8
9
500 кбит/с
250 кбит/с
125 кбит/с
сохранен
50 кбит/с
20 кбит/с
10 кбит/с
Автоматическое
определение бита
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
10.5.3.5.3 Сохранение конфигурации магазина
Все параметры настройки могут быть сохранены. Хранение параметров
настройки может быть отборным к спецслужбе. Если не будет аргументов, то все
параметры настройки должны быть сохранены.
Индикационный синтаксис указан в таблице 131. Идентификатор сохранения
определен в таблице 132.
Таблица 131 – синтаксис для сохранения конфигурационных команд
[net] store <storage-specifier>
Таблица 132 – Определитель сохранения
Определител
Описание
ь сохранения d, bitrate, узел по умолчанию
CFG
PDO-число, тип передачи, число отображения,
PDO
перерыв
sdo
SDO
отображения
- защита узла: узел, время, пожизненный фактор
NMT
- heartbeat: узел, время heartbeat
- Время heartbeat сервера
Ответный синтаксис:
cv 10.5.2.4.3.
10.5.3.5.4 Восстановление конфигурационных команд
Indication Синтаксис is defined in Таблица 133.
Таблица 133 - Синтаксис restore configuration command
[net] restore <storage-specifier>Ответный синтаксис:
See chapter 10.5.2.4.3.
10.5.3.5.5 Установка команды производителя heartbeat
Индикационный синтаксис указан в таблице 134.
Таблица 134 – синтаксис Установки команды производителя heartbeat
[net] set heartbeat <ms>
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.5.6 установка команды настройки узла
Индикационный синтаксис указан в таблице 135.
Таблица 135 – синтаксис установки команды идентификатора узла
[net] set id <value>
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.5.7 Старт команды аварийного потребителя
Данная команда не определена
116
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
10.5.3.5.8 Остановка команды аварийного потребителя
Данная команда не определена
10.5.3.6 Команды управления шлюзами
10.5.3.6.1 общая информация
Следующие командные определения используются для выполнения шлюза
управления сервисами как указано в 10.4.6.
10.5.3.6.2 Установка команды сети по умолчанию
Индикационный синтаксис указан в таблице 136.
Таблица 136 – Синтаксис установки команды сети по умолчанию
[net] set network <value>
Ответный синтаксис:
см 10.5.2.4.3.
10.5.3.6.3 Установка команды идентификатора узла по умолчанию
Индикационный синтаксис указан в таблице 137.
Таблица 137 – Синтаксис Установки команды идентификатора узла по
умолчанию
[net] set node <value>
Ответный синтаксис:
См раздел 10.5.2.4.3.
10.5.3.6.4 получение команды версии
Индикационный синтаксис указан в таблице 138.
Таблица 138 – синтаксис получения команды версии
info version
Ответ на команду - информация о текущей версии шлюза как свободное
пространство – составление отделенного списка. Первые элементы списка значения, обычно содержавшиеся в словаре объекта шлюз в объекте 1018-м.
Следующие перечисленные элементы содержат информацию о классе шлюза,
поскольку комбинация возможных классов и номер версии осуществленного
протокола соответствовали
10.4.6.4.Ответный синтаксис определен Таблица 139.
Таблица 139 - Ответный синтаксис для получения команды версии
<version-string>: : = <vendor-id> <product-code>
<version-high>.<vers ion-low> <serial-number> <gatewayclass> <protocol-version> implementation-class>
примеры результатов приведены в таблице 140.
Таблица 140 – примеры для получения команды
[1234] 52 100 1.01 1234567 128 0.85 0.10
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
10.5.3.7 Команды для производителя
Следующие определения команды должны использоваться для
выполнения определенных услуг для изготовителя. Изготовитель шлюз может
добавить команды к их шлюзам, чтобы обеспечить дальнейшие особенности.
Чтобы избежать синтаксических ошибок из-за неизвестной команды, все
определенные для пользователя команды должны быть предварительно
рассмотрены с подчеркиванием "_".
Если будет потребность в событийных сообщениях, не определенных в этой
части спецификации, то спецификатор событий "ПОЛЬЗОВАТЕЛЬ" должен
использоваться.
11 Управлений Сетью железных дорог
11.1 Содержание
Этот пункт расширяет набор услуг управления сетью железных дорог
(TNM) для Узла WTB, определенного в IEC 61375-2-1. Управление сетью
железных дорог определяет услуги помощи при вводе в действие,
тестировании, операции и обслуживании TCN. Эти услуги включают
станционную идентификацию и контроль, распределение направления,
отдаленных чтениях, загрузки и загрузки и управления сетью железных дорог,
а также уровнями связи в сети. Процесс управления требует данные сервисы
удаленно, и каждая станция посредством процесса Агента выполняет их.
По информативным причинам обработка управленческих сообщений
иллюстрирована в рисунке 30, как определено в IEC 61375-2-1.
Рисунок 30 – Сообщения по управлению (информативное)
118
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Дополнительные услуги определенные для Станций, связанных с сетью
CANopen. Менеджер должен запрашивать данные сервисы посредство отправки
Call_Massage Агенту в целевую Станцию. Агент должен выполнить сервис и
должен ответить посредством Reply_Message с результатом сервиса. CANopenсвязанные услуги, которые можно требовать у Агента, определены в 10.4.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
11.2 Менеджер, Агент и интерфес (для информации)
Как определено в IEC 61375-2-1 управленческие услуги Сети железных
дорог предоставлены в каждой Станции Агентом. Station_Id Станции, на
которой имеется Агент. Менеджер запрашивает управленческие услуги Сети
железных дорог.
11.3 Управленческий (информативный) протокол сообщения
В целях управления Сетью железных дорог менеджер и Агенты общаются
по сети, обменивая управленческими сообщения, используя Messages Services
Коммуникационной сети Поезда, как иллюстрировано в рисунке 30 и
определенный в IEC 61375-2-1. Менеджер действует как Посетитель и Агент
как Ответчик.
Менеджер получает доступ к отдаленному объекту двумя функциями;
менеджер посылает управление, Call_Message и Агент расшифровывают
сообщение, получают доступ к фактическому объекту и отсылают сообщение
назад Reply_Message с результатом сервиса.
11.4 (Информативные) интерфейсы объекта
Согласно IEC 61375-2-1, Коммуникационные объекты TCN связаны с
сетевой коммуникацией, в то время как объекты несоответствия TCN связаны
с другими свойствами Станции.
Примеры NOTE1 определены в IEC 61375-2-1.
Коммуникация доступов Агента объекта через интерфейсы, определенные для
общего доступа в этом стандарте, и в особенности через:
a) AVI (Application_Variables_Interface) для переменных;
b) AMI (Application_Messages_Interface) для сообщений;
c) ASI (Application_Supervisory_Interface) для объектов, не доступных
пользовательскими процессами.
ASI обеспечивает доступ к объектам, расположенным в различных
коммуникационных уровнях. Агент получает доступ к этим объектам через
управленческий Интерфейс уровня, в котором они находятся.
Примечание - 2 предприятие, которое эффективно получает доступ к объектам в каждом
уровне, назван управленческим Предприятием уровня или ЛБМ.
Агент должен также быть в состоянии получить доступ к объектам
взаимного несоответствия.
11.5 CANopen-определенные управленческие услуги
11.5.1 Общий
CANopen-определенные управленческие сообщения определяют сервисы
двумя идентификаторами, SIF_code и Command_code. SIF_code определяет
одну из двух групп услуг - услуги, которые выполнены с и без резервирования
менеджером по его исключительному использованию. Command_code
выбирает особое обслуживание группы. Полезная часть сообщения требования
120
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
- запрос об обслуживании, зашифрованном как последовательность ASCII,
полезная часть сообщения ответа - ответ, зашифрованы таким же образом.
Кодирование ASCII определено в 10.5.
11.5.2 Интерфейсы агента на Станции, связанной с сетью CANopen
Определения для интерфейсов Агента, указанных
IEC 61375-2-1,
направляют запрос на устройства CANopen, которые сообщают данные о
сообщении TCN, также. Интерфейсы Агента иллюстрированы в рисунке 31 для
шлюз между основой Поезда, и находящийся в сети CANopen. В рисунке 31
Основа Поезда обозначена как WTB.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Рисунок 31 - Интерфейс Agent на CANopen (шлюза) станция для данных о
сообщении
На станции CANopen не используется AVI. Данные приложения
непосредственно представлены в специальных объектах в изготовителе specifc, а также
в стандартизированном ряду индексов словаря объекта CANopen, как описано в 8.2.
11.5.3 Управленческая структура сообщения для CANopen
Каждый сервис должен быть призвано управленческим обменом сообщения
Требования/Ответа с форматом, определенным в Таблице 141.
Таблица 141 - управленческая структура сообщения
Management Message Can::=
RECORD— first octet
tnm key ENUM8
CALL rsl'4]'
-Call (request)
REPL
Repl (response)
message
ONE
OF
[tnm
key]
-selects
call or reply
Y
y
[CALL] Call Mgt Message Can, -see 11.5.5
[REPLY Reply Mgt Message Can
see 11.5.6
]
Самая значительная часть 'tnm_key' должна указать, является ли это
Требование или сообщение Ответа.
122
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
11.5.4 Примечание для определенного SIF_codes CANopen
В управленческих службах сообщений SIF_code содержат запрашиваемые
сервисы. В случае CANopen, SIF_code означает группу требуемого обслуживания
CANopen. Как определено в Таблице 142, наименее значительный бит указывает,
является ли это прочитанной или написанной (изменение) группой услуг.
Таблица 142 – специальные SIF_ коды CANopen
Sif Code Can::= ENUM8 -WRITE
COMMAN
CANOPEN
D
READ
COMMAN
CANOPEN
D
choice of the group of services
(91) ,
(90)
11.5.5 Условные знаки для команды управления сообщением CANopen
Условные знаки для команды управления сообщением CANopen определены в
Таблице 143.
Таблица 143 - Условные знаки для команды управления сообщением CANopen
Call Mgt Message Can::=
sif code Sif Code Can, sif
message code body ONE
OF [sif
[WRIT
E
[REA
D
CANOPEN
COMMAND]
CANOPEN
COMMAND]
RECORD
the code]
secon octet is the
d
Call Write CANope Command,
Call Read n
Command
CANope
n
11.5.6 Условные знаки для ответа управления сообщением CANopen
Условные знаки для ответа управления сообщением CANopen определены в
Таблице144.
Таблица 144 - Условные знаки для ответа управления сообщением CANopen
Reply_Mgt_Message_Can::= RECORD { sif_code Sif_Code_Can, -- the second octet is
the
sif code message body ONE OF [sif code]
{
[WRITE_CANOPEN_COMMAND]
Reply_Write_CANopen_Command,
[READ_CANOPEN_COMMAND]
Reply_Read_CANopen_Command
11.5.7 Условные знаки для сервисов командных кодов TNM CANopen
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Командный код определяет некоторые сервисы из группы сервисов путем
применения кода SIF_ . Таблица 145 и Таблица 146 определяют командные коды TNM
CANopen для сервисов, для опредления требуется ли сохранение.
Таблица 145 – командные коды TNM CANopen (требуется сохранение)
Cmd Code R::= ENUM8 -- выбор усchoice
r
t
UPLOAD SDO
(
DOWNLOAD SDO
(
CONРИСУНОК SDO TIMEOUT
(
CONРИСУНОК RPDO
(
CONРИСУНОК TPDO
(
WRITE PDO DATA
(
START NODE
(
STOP NODE
(
RESET NODE
(
RESET COMMUNICATION
(
ENABLE NODE GUARDING
(
DISABLE NODE GUARDING
(
START HEARTBEAT CONSUMER (
DISABLE HEARTBEAT CONSUMER (
INITIALIZE GATEWAY
(
STORE CONFIGURATION
(
RESTORE CONFIGURATION
(
SET HEARTBEAT PRODUCER
(
SET NODE ID
(
SET DEFAULT NETWORK
(
SET DEFAULT NODE
(}
Услуги, необходимые для
сохранения reservation
1),
2) ,
3),
4),
5),
6),
7),
8) ,
9),
10) ,
11) ,
12) ,
13) ,
14) ,
15) ,
16) ,
17) ,
18) ,
19) ,
20) ,
21)
Примечание - Не рассматриваются услуги уведомления, так как они не могут быть выполнены
(запрос, ответ)
Таблица 146 – сервисы командных кодоа TNM CANopen (не требует
сохраненияя)
Cmd Code NR: := ENUM8 — choice of the service that does not need
124
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
reservation
{
READ_PDO_DATA
READ_DEVICE_ERROR
GET_VERSION
(30),
(31),
(32)
11.6 сервисы TNM CANopen
11.6.1 содержание
Данный подпункт определяет сообщения, идентифицируемые командным кодом
и определяемые сервисной командой передаются сообщением согласно типу
запрашиваемого и ответного сервиса TNM CANopen .
11.6.2 Call_Write_CANopen_Command (сохранение)
Данным сообщением сервис группы "с сохранением" (см. Таблицу 145)
определенный кодексом команды и определенный сервисной командной строкой,
переданной в самом сообщении. Рисунок 32 показывает структуру команды, и
Таблица 147 предоставляет определение стоимости.
15
10
14
13
12 11
tnm_key
reserved 1
9
8
7
6
5
4
3 2
sif_code =
91cmd_code
1
0
reserved2
string_siz
comman ARRAY
[string_size] OF
e
(CHARACTER8)
CHARACTER8 00'H
d:
ALIGN16
or
Рисунок 32 - Call_Write_CANopen_Command
Таблица 147 – определение значение
Call_Write_CANopen_Command
Call_Write_CANopen_Command::= RECORD
{
reserved1WORD8 (=0), -- сохранен
cmd_code Cmd_Code_R, -- командный код услуги reserved2WORD16
(=0), -- сохранен
string_size UNSIGNED16,-- до 65535 знаков
ARRAY ALIGN16 [string_size] OF CHARACTER8 – командная строка
сервиса
11.6.3 Reply_Write_CANopen_Command (с сохранением)
Данным сообщением команда Call_Write_CANopen группы "с
сохранением" (см11.6.2) идентифицируется командным кодом и определяется
командной строкой сервиса, переносится на структуру ответного сообщения.
Рисунок 33 показывает структуру команды и Таблица 148 содержит опредление
значения.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
15
10
14
13
12 11
tnm_key
reserved1
9
8
7
6
5
4
3 2
sif_code =
91
get_sif_cod
e
1
0
reserved2
Размер
полосы
ответ: ARRAY
[string_size] OF
(CHARACTER8) ALIGN16
CHARACTER8 00'H
or
Рисунок 33 – Таблица Ответа_Write_CANopen_Command
148 –Определение значения Reply_Write_CANopen_Command
Reply_Write_CANopen_Command::=
RECORD {
reserved1WORD8 (=0), -- сохранен
cmd_code Cmd_Code_R, -- командный код услуги
reserved2WORD16 (=0), -- сохранен
string_size UNSIGNED16,-- до 65535 знаков response ARRAY ALIGN16 [
string_size] OF CHARACTER8 -- командная строка
11.6.4 Call_Read_CANopen_Command (без сохранения)
Данным сообщением команда Call_Write_CANopen группы "без
сохранения" (см11.6.2) идентифицируется командным кодом и определяется
командной строкой сервиса, переносится на структуру ответного сообщения.
Рисунок 34 показывает структуру команды и Таблица 149 содержит опредление
значения.
15
10
14
13
12
11
tnm_key
reserved 1
9
8
7
6
5
4
3 2
sif_code =
90cmd_code
1
0
reserved2
string_siz
команда: ARRAY
[размер полосы] OF
e
(CHARACTER8) ALIGN16
CHARACTER8 00'H
или
Рисунок34 - Call_Read_CANopen_Command (без сохранения)
Таблица 149 – Определение значения for Call_Read_CANopen_Command (без
сохранения)
Call_Read_CANopen_Command::= RECORD
reserved1WORD8 (=0), -reserved
cmd_code Cmd_Code_NR, -command code of the service
reserved2WORD16 (=0), -reserved
string_size UNSIGNED16,-up to 65535 characters
command ARRAY ALIGN16 [ string_size] OF CHARACTER8 -- service
126
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
command string }
11.6.5 Reply_Read_CANopen_Command (без сохранения)
Данным сообщением команда Call_Write_CANopen группы "с
сохранением" (см11.6.4) идентифицируется командным кодом и определяется
командной строкой сервиса, переносится на структуру ответного сообщения.
Рисунок 35 показывает структуру команды и Таблица 150 содержит опредление
значения.
15
14
13
12
11 9
8 7
6
5
4
3 2
1
0
tnm_key
sif_code =
10
90
reserved1
get_sif_cod
reserved2
e
Размер
ответ: ARRAY
полосы [string_size] OF
(CHARACTER8) ALIGN16
CHARACTER8 00'H
or
Рисунок 35 - Reply_Read_CANopen_command
(без сохранения)
Таблица 150 – Определение значения для Reply_Read_CANopen_Command
(без сохранения)
Reply_Read_CANopen_Command::= RECORD
{
reserved1WORD8 (=0), -- сохранен
cmd_code Cmd_Code_NR, -- командный код услуги
reserved2WORD16 (=0), -- сохранен
string_size UNSIGNED16, -- up to 65535 characters response ARRAY ALIGN16 [
string_size ] OF CHARACTER8 -- service response string
12 Передача данных сообщения по управлению CANopen
12.1 Общая информация
Сообщения по управлению CANopen также могут передаваться между
устройствами CANopen в перделах сети на базе CANopen. Рисунок 36
показывает устрйоство CANopen, имеющее свойство передавать данные
сообщения через сеть на базе CANopen.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
CAN физический уровень
Рисунок 36 – устройство CANopen, имеющее возможность передавать сообщения
по управлению TNM
В дополнении к профильным специфическим приложениям CANopen,
предназначенным для пользователей имеются приложения для Менеджеров и
Агентов в устройстве CANopen. Кроме того, Функция - и Станционный
справочник поддерживается в пределах применения устройства CANopen. Для
передачи и приема данных о сообщении, устройство CANopen, как показано в
рисунке 36, поддерживается сервер SDO и каналы клиента и словарь объектов
1F78 h CANopen.
Как изложено и определено в IEC 61375-2-1, Данные о сообщении
передаются в качестве дейтаграммы. Дейтаграмма подобна письму: каждая
дейтаграмма содержит все адреса, необходимые для маршрута от одного до
другого конца (и передает подтверждение обратно). Эта схема выгодна, когда
несколько шлейфов связаны между собой, так как маршрутизаторам не будет
необходимо сохранять информауию о предыдущих сообщениях.
Каждая структура Данных о сообщении несет два типа адресов: источник и
Адреса Устройства назначения для коммуникации в пределах одного шлейфа
(Адреса Устройства) и адреса источника происхождения и заключительного места
назначения (Сетевые Адреса).
Источник и Адреса Устройства назначения применяются только в пределах
того же самого шлейфа. Когда Данные о сообщении посылают другой сети,
устройством назначением является - Узел в Основе Поезда, которая действует как
шлюз. Когда Узел получает Данные о сообщении от другого транспортного
средства, вставляется свой Адрес Устройства как исходное устройство.
Данные о сообщении содержат два типа адресов:
128
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
• адрес источника и адрес получателя, которые определяют тип устройства
Для подобного шлейфа или для специального шлейфа. Эти адреса
определенные для Связи уровней;
• Адрес Происхождения и Заключительный Адрес, которые определяют
Станции, связывающиеся внутри сети и которые известны в сети. Адрес
Происхождения и Финальный Адрес идентифицирует Производителя и
Потребителя, и в свою очередь Посетителя и Отвечающего.Эти адреса принадлежат
Сетевому уровню.
12.2 Формат данных сообщения
Согласно определению в IEC 61375-2-1, относительно данных сообщения, формат
WTB, MVB, CANopen или любых других магистральных систем варьируется
только в отношении Заголовка канала данных, как указано в рисунке 37.
Рисунок 37 – Сравнение формата данных сообщения
Относительно CANopen, Заголовок канала данных включает идентификатор
CAN. Так как данные сообщения могут передаваться через SDO – утвержденной
точечной коммуникации – назначением является адрес источника устройства,
которая определяется путем выбора коммуникационного канала SDO. Каждый SDO
коммуникационный канал, посредством настройки параметров SDO, уникального
идентификатора CAN отвечают командам.
12.3 Требования для данных сообщения в пределах коммуникации внутри
сети CANopen
Любое устройство CANopen, связанное с сетью на базе CANopen, которое
должно
вести
коммуникацию
Данными
сообщения,
поддерживает
функциональность сервера SDO и клиента SDO.
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Каждое устройство CANopen, пользующиеся сервисами другого устройства
в пределах CANopen, поддерживает канал клиента SDO, чтобы пользоваться
сервисом. Посредством SDO получают доступ к объекту 1F78 h (см. пункт 12.4),
через канал сервера SDO "запроса устройство CANopen", устройство CANopen,
которое выполняет и отвечает на полученные данные о сообщении, должно
передать ответ.
Каждое устройство CANopen, которое должно получить запрос о сервисе от
другого устройства CANopen в пределах сети CANopen , поддерживает канал
сервера SDO, чтобы получать запрос о сервисах. Посредством SDO пишется
доступ через его канал клиента SDO, это устройство CANopen должно передать
ответ на "запрос устройство CANopen".
Примечание - рекомендуется поддержать такое же количество клиент SDO и – серверные каналы
в устройстве CANopen, столько же устройство находится в сети CANopen, способные сообщать
о данных сообщении. К каждому из этих устройств предварительно сконфигурирована пара
каналов клиент-сервер.
Данные о сообщении могут быть переданы или через SDO сегментированной
передачи или блочной пересылкой SDO, как определено в EN 50325-4. Данные о
сообщении должны быть получены в пределах соответствующего субиндекса 1F78
h словаря объекта CANopen (см. 12.4). Поскольку каждый субиндекс этого объекта
связан с одним каналом сервера SDO, субиндекс, который будет написан, должен
быть равен числу используемого канала сервера SDO.
12.4 Объект 1F78h: получение данные сообщения CANopen
Данные о сообщении TCN необходимо получать через доступ с правом записи
SDO относительно данному объекту, как определено в 12.3. каждый субиндекс
данного объекта должно иметь отношение к поддерживаемому серверному каналу
SDO.
Данные, записанные к настоящему объекту является доминирующим типом
и должно истолковываться как определено в IEC 61375-2-1 о данных сообщения
TCN.
Объект и вводные описания указаны в Таблице 151 и 152.
Таблица 151 – описание объекта
определение
индекс
Название
Код объекта
Тип данных
Категория
Значение
1F78h
CANopen message data reception
ARRAY
DOMAIN
условная; обязательная, в случае, если коммуникационные
данные сообщения поддерживаются
Таблица 152 – Описание ввода
Определе ние
Субиндекс
описание
Входная категория
Доступ
130
Значение
00h
Количество вводов
Обязательная
постоянный
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
PDO контроль
Диапазон значений
Значение по
умолчанию
нет
01 h до 80 h
Спецмаотнре устройство
Субиндекс
описание
01
Входная категория
Доступ
PDO контроль
Диапазон значений
Значение по
умолчанию
h
TCN сообщение полученное через серверный 1канал SDO
определен индексом 1200h
Обязательный
wo
Нет
См раздел 11 и IEC 61375-2-1
Специально для производителя
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
определение
Субиндекс
описание
Значение
02h
TCN сообщение полученное через серверный 2 канал SDO
определен индексом 1201 h
Входная категория условная; обязательная, в случае, если коммуникационные
данные сообщения поддерживаются сервером2 канала SDO
Доступ
wo
PDO контроль
Нет
Диапазон значений См Раздел 11 и IEC 61375-2-1
Значение по
умолчанию
Для
Субиндекс
описание
Специально для производителя
80h
TCN сообщение полученное через серверный 128 канал SDO
определен индексом 127Fh
Входная категория условная; обязательная, в случае, если коммуникационные
данные сообщения поддерживаются сервером 128 канала SDO
Доступ
wo
PDO контроль
нет
Диапазон значений См Раздел 11 и IEC 61375-2-1
Значение по
Специально для производителя
умолчанию
13 Тест на соответствие
Соответствующие стандарты интерфейса контролирующего устройства
должны определить тип испытаний, требуемые для проверки соответствия
конструкции
устройства с настоящим стандартом. Оборудование, подлежащее
испытанию, должно включать
- электропитание,
- сетевое устройство,
- регулятор,
- коммуникационную среду,
- электромеханизм.
Данные испытания должны охватывать электрические испытания, испытания
на электромагнитную совместимость и логические испытания. Касательно
шлейфовых устройств между Train Backbone и сети на базе CANopen, необходимо
проверка всех коммуникационных интерфейсов.
Испытательный план соответствия относительно WTB предоставлен в IEC 61375-22. Испытательный план соответствия относительно устройств CANopen не входит в
область рассмотрения данного стандарта.
Примечание -1, испытательный план соответствия CANopen определен в документе ЦРУ 310.
Примечание -2 информации об услугах по тестированию на соответствие предлагается в CAN
АВТОМАТИЗАЦИЯ (CiA) GmbH.
132
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
Библиография
[1] IEC 61375-2-4,
Электронное оборудование для железной дороги Сеть
коммуникации поезда (TCN) -Часть 2-4: Профиль приложения
[2] CiA 301, уровень приложения и коммуникационный профиль CANopen. CAN
автоматизация e.V., Nuremberg
[3] CiA 302, Функций дополнительного уровня приложения CANopen
CAN
Автоматизация e.V., Nuremberg
[4] CiA 305, CANopen сервисы установки уровней (LSS) и протоколов. CAN in
автоматизация e.V., Nuremberg
[5] CiA 303-1, дополнительная спецификация CANopen - Part 1: укладка кабеля и
установка соединительного контакта. CAN автоматизация e.V., Nuremberg
[6] CiA 310, CANopen тестовый план соответствия. CAN автоматизация e.V.,
Nuremberg
[7] CiA 421, CANopen профиль приложения для котрольной сети поездов. CAN in
автоматизация e.V., Nuremberg
[8] RFC 2045; RFC 2045 Возможности многофункционального интернета. www.rfc.net
[9] UIC 556, Передача информации в поездах (проводная шина поезда).
Международный союз железных дорог (UIC), Брюссель
УДК 629.4.027.11(430)
МКС 45.040
Ключевые слова: поездные сети связи, информационные технологии, электронное железнодорожное
оборудование
СТ РК IEC 61375-3-3_____
(проект, редакция 1)
РАЗРАБОТЧИК
АО «Казахская академия транспорта и коммуникаций им. М.Тынышпаева»
Старший научный сотрудник,
к.т.н., доцент
А.Алижан
Старший научный сотрудник
И.Жайсан
134