С этим диапазоном можно описать 8 разных устройств. В таком случае устройство называется как Multiple Device Modules (устройство с несколькими модулями). Multiple Device Modules составлены из сегментов профиля устройства, которых может быть до 8 штук. С помощью этой функции можно построить устройства с многочисленной функциональностью. Отличающиеся профили устройства сдвинуты по индексу друг относительно друга на 800h. Таким образом, диапазон индексов для Multiple Device Modules распределен следующим образом:

Распространение PDO должно использоваться для каждого сегмента Multiple Device Module со смещением 64, например первый PDO второго сегмента получит номер 65. Таким способом поддерживается система максимум с 8 сегментами.

Эта модель задает различные объекты коммуникации и службы, и доступные режимы для срабатывания передачи сообщения. Модели задают способ, которым объекты обмениваются информацией.

Коммуникационная модель поддерживает передачу синхронных и асинхронных сообщений. Методом передачи синхронного сообщения становится возможным осуществление координированного по всей сети запуска сбора и обработки. Синхронная передача сообщений поддерживается заранее определенными в стандарте коммуникационными объектами: сообщение синхронизации (SYNC), сообщение метки времени (time stamp). Синхронные сообщения передается по заранее определенному сообщению синхронизации, асинхронное сообщение может быть передано в любой момент времени.

Из-за событийного характера нижележащего механизма коммуникации можно определить времена запрета коммуникации (inhibit time). Необходимость в таком времени понятна - если события в устройствах будут происходить слишком часто, то возможно "забитие" полосы сети слишком часто появляющимися сообщениями. Интервал запрета гарантирует, что забитие сети данными низкого приоритета не произойдет, для этого элементам данных может быть назначено время запрета (inhibit time). Время inhibit для объекта данных определяет минимальное время, которое должно пройти между двумя следующими друг за другом запусками службы передачи сообщения.

Времена запрета могут быть назначены приложением в зависимости от его функциональности. Из-за этого различают 3 типа взаимоотношений коммуникации:

• Master/Slave (взаимоотношение между главным и подчиненным устройством, рис. 4 и 5).
• Client/Server (взаимоотношение клиент-сервер, рис. 6).
• Producer/Consumer (взаимоотношение продюсер - потребитель, рис. 7 и 8).

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

Рис. 4. Обмен данными Master - Slave без подтверждения (Unconfirmed Communication).

Рис. 5. Обмен данными Master - Slave с подтверждением (Confirmed Communication).

Взаимодействие Master/Slave применяется в протоколе NMT, где в сети присутствует один главный узел (Master), и остальные устройства являются подчиненными (Slave). Мастер сети управляет состоянием подчиненных устройств (описание протокола NMT см. далее).

6.3.2. Взаимодействие Client/Server. Это взаимосвязь между одиночным клиентом и одиночным сервером. Клиент выдает запрос выгрузки или загрузки (upload/download), что вызывает срабатывание сервера для выполнения определенной задачи. После завершения этой задачи сервер отвечает подтверждением на запрос.

Рис. 6. Обмен типа клиент - сервер.

Взаимодействие Client/Server применяется в протоколе SDO, через который мастер сети может прочитать словарь (OD) подчиненного узла сети и/или изменить его (если это предусмотрено словарем узла).

6.3.3. Взаимодействие Producer/Consumer - модель Pull/Push. Это взаимосвязь типа генератор/потребитель, что вовлекает один генератор (продюсер) и потребителей, которых может 0 или больше. Модель push (проталкивание) характеризуется не подтверждаемой службой, которая запрашивается продюсером. Модель pull (выборка) характеризуется подтверждаемой службой, запрашиваемой потребителем.

Рис. 7. Модель Push.

Рис. 8. Модель Pull.

Взаимодействие Producer/Consumer применяется при синхронизации узлов сети (передача объектов SYNC) и при обмене прикладными данными (объекты PDO).

Физический носитель данных для устройств представляет собой дифференциальную двухпроводную линию связи с общим проводом, соответствующую высокоскоростной спецификации передачи данных ISO 11898.

7.1. Трансивер. Используется высокоскоростной трансивер по стандарту ISO 11898, с уровнями VCAN_H и VCAN_L +16V. Гальваническая изоляция для узлов сети является опциональной. Рекомендуется использовать трансивер, которые может выдерживать неправильное подключение (или ошибочное отключение) любого из проводов шины, включая превышение напряжений V+ до 30V.

7.2. Скорость следования бит (bit rate) и интервалы времени. Рекомендуется использовать скорости и интервалы(4), перечисленные в таблице 2. Устройство CANopen должно поддерживать как минимум один вариант скорости из этой таблицы.

Таблица 2. Рекомендуемые скорости передачи данных и параметры времени бита.

Здесь:

t_p номинальное время бита.
t_q количество квантов времени, приходящихся на бит.
L_tq длина кванта времени.
S_p место точки выборки (sample point).

Значения в таблице базируются на следующих предположениях:

Тактовая частота генератора 16 МГц ±0.1% (1000 ppm).
Режим анализа уровней сигнала (Sampling mode): одиночная выборка, SAM = 0.
Режим синхронизации: только по перепадам уровня от recessive к dominant, SYNC = 0.
Ширина интервала синхронизации (Synchronisation jump width): 1 * t_q, SJW = 0.
Phase Segment 2: 2 * t_q, TSEG2 = 1.

Примечания:

(1) Округленная оценка длины шины (худший случай) на основе задержки распространения 5 нс/м и общей эффективности работы устройства:

0.8 .. 1 мегабит/сек: 210 нс.
250 .. 500 килобит/сек: 300 нс (включая задержку 2*40 нс для схем оптической развязки).
125 килобит/сек: 450 нс (включая задержку 2*100 нс для схем оптической развязки).
10 .. 50 килобит/сек: 1.5 t_q; эффективная задержка = задержка ((recessive -> dominant) + (dominant -> recessive)) / 2.

(2) Для шины длиной больше примерно 200 м рекомендуется использовать оптоизоляторы. Если оптоизоляторы размещаются между контроллером CAN и трансивером, то это влияет на максимальную длину шины - в зависимости от задержки распространения узлов оптической развязки. Например, отнимается 4 м от длины шины на 10 нс вводимой опторазвязкой задержки.

(3) Для шины, длина которой больше примерно 1 км, может потребоваться мост или репитер сигнала.

(4) Интервалы бит в таблице вычислены на базе тактовой частоты генератора 16 МГц. Если используется другой генератор, то количество квантов времени (t_q) может быть другим. Тем не менее, расположение точки выборки сигнала (sample point) должно быть как можно ближе к рекомендуемой.

9.1.1. Общее описание типов данных и кодирования. Чтобы можно было обмениваться значимыми данными по сети CAN, формат этих данных и их значение должны быть известны продюсеру данных и потребителю (потребителям) данных. Спецификация CANopen моделирует эту концепцию типами данных.

Правила кодирования определяют представление значений типов данных и синтаксис переноса данных по сети CAN для этих представлений. Значения представлены как последовательности бит. Последовательности бит передаются по сети как последовательности октетов бит (байтов). Для цифровых типов данных принят стиль кодирования little endian, как показано на рис. 9.

Рис. 9. Синтаксис передачи и последовательность бит.

Приложения частот требуют типы данных, основанные на базовых типах. С использованием механизма составного типа данных (compound data type mechanism) список доступных типов данных может быть расширен. Например, некоторые общие расширенные типы данных определены как "Visible String" (видимая строка) или "Time of Day" (время дня) (см. 9.1.6.2 и 9.1.6.4). Составные типы данных являются средством реализовать определяемые пользователем типы "DEFTYPES" в терминологии этой спецификации, и не "DEFSTRUCTS" (см. таблицу 37: Object Dictionary Object Definitions).

[9.1.2. Определения типа данных]

Тип данных определяет взаимосвязь между значениями и кодированием данных для этого типа. Типам данных назначаются имена в их определениях типа. Используется следующий синтаксис данных и определений типа данных (см. EN 61131-3):

Рекурсивные определения не разрешены. Тип данных определяется type_definition называется базовым, когда конструктор basic_constructor. Для составного типа соответственно используется compound_constructor или array_constructor, для структуры structure_constructor.

[9.1.3. Последовательности бит]

9.1.3.1. Определение последовательностей бит. Бит может принимать значения 0 или 1. Последовательность бит b это упорядоченный набор из 0 или большего количества бит. Если последовательность бит b содержит больше 0 бит, то она обозначается как bj, где j > 0. Предположим b0, ..., bn-1 будут битами, где n положительное число. Тогда

b = b₀ b₁ ... b_n-1

называется последовательностью бит длиной |b| = n. Пустая последовательность бит длиной 0 обозначается буквой ε. Примеры последовательностей бит: 10110100, 1, 101.

Оператор инверсии (¬) на последовательности бит b = b₀ b₁ ... b_n-1 дает последовательность бит

¬b = ¬b₀ ¬b₁ ... ¬b_n-1

Здесь для бит ¬0 = 1 и ¬1 = 0.

Базовая операция на последовательностях бит - конкатенация (склеивание).

Предположим, у нас есть последовательности бит a = a₀ ... a_m-1 и b = b₀ ... b_n-1. Тогда конкатенация a и b обозначается ab и будет равна

ab = a₀ ... a_m-1 b₀ ... b_n-1

Пример: (10)(111) = 10111 является конкатенацией 10 и 111. Выполняется следующее равенство для произвольных последовательностей бит a и b:

|ab| = |a| + |b|

и

εa = aε = a

9.1.3.2. Синтаксис передачи последовательностей бит. Для передачи через сеть CAN последовательность бит реорганизуется в последовательность октетов. Для октетов используется шестнадцатеричная нотация. Предположим, b = b₀ ... b_n-1 будет последовательностью бит, где n ≤ 64. Обозначим k не отрицательного целого числа как 8(k - 1) < n < 8k. Тогда b преобразуется в k октетов, собранных как показано на рис. 9. Биты b_i, где i ≥ n самых старших октетов содержат ничего не значащие биты. Октет 1 передается первым, и k передается последним. Таким образом, последовательность бит передается по сети CAN следующим образом:

b₇, b₆, ..., b₀, b₁₅, ..., b₈, ...

Пример:

бит 9   ...     бит 0
       |                    |
    10  0001 1100
    2h   1h   Ch
              = 21Ch

Последовательность бит b = b₀ .. b₉ = 0011 1000 01 представляет число UNSIGNED10 со значением 21Ch, и оно передается в 2 октетах: сначала 1Ch, и затем 02h.

[9.1.4. Базовые типы данных]

Для базовых типов данных "type_name" равно строке связанного конструктора (наподобие символического имени), например:

BOOLEAN BOOLEAN

это определение типа для типа данных BOOLEAN.

9.1.4.1. NIL. Данные базового типа NIL представлены буквой ?.

9.1.4.2. Boolean. Данные базового типа BOOLEAN получают значения TRUE (истина, 1) или FALSE (ложь, 0). Значения представлены последовательностями бит длиной 1.

9.1.4.3. Void. Базовый тип VOIDn представлен последовательностями бит длиной n. Значение типа данных VOIDn не определено. Биты в последовательности данных VOIDn должны быть либо явно указаны, либо помечены "do not care" (не имеет значения). Тип данных VOIDn полезен для зарезервированных полей и для выравнивания компонентов составных значений по границам октетов.

9.1.4.4. Unsigned Integer (целое число без знака). Базовый тип данных UNSIGNEDn принимает не отрицательные значения целых чисел. Диапазон значений 0, ..., 2ⁿ-1. Данные представлены последовательностями бит длиной n. Последовательность бит

b = b₀ ...b_n-1

назначается значению

UNSIGNEDn(b) = b_n-1*2^n-1+ ...+ b₁*2¹ + b₀*2⁰

Обратите внимание, что последовательность бит начинается слева самым младшим значащим байтом. Например, значение 266 = 10Ah с типом данных UNSIGNED16 передается по шине двумя октетами, при этом сначала передается 0Ah, и затем 01h.

Различные типы UNSIGNEDn передаются следующим образом:

Рис. 10. Примеры синтаксиса передачи типа данных UNSIGNEDn.

9.1.4.5. Signed Integer (целое число со знаком). Данные базового типа INTEGERn принимает целые значения, положительные и отрицательные, и 0. Диапазон значений составляет -2^n-1, ..., 2^n-1-1. Данные передается в последовательности бит длиной n. Последовательность бит

b = b₀ .. b_n-1

назначается значению

INTEGERn(b) = b_n-2 * 2^n-2 + ...+ b₁ * 2¹ + b₀ * 2⁰ если b_n-1 = 0 (положительное целое число), и с помощью арифметики дополнения до двух (two's complement arithmetic),

INTEGERn(b) = - INTEGERn(^b) - 1 если b_n-1 = 1 (отрицательное целое число).

Обратите внимание, что последовательность бит начинается слева самым младшим значащим байтом. Например, значение -266 = FEF6h с типом данных INTEGER16 передается по шине двумя октетами, при этом сначала передается F6h, и затем FEh.

Различные типы INTEGERn передаются следующим образом:

Рис. 11. Примеры синтаксиса передачи типа данных INTEGERn.

9.1.4.6. Числа с плавающей точкой. Данные базовых типов данных REAL32 и REAL64 получают значения реальных чисел. Тип данных REAL32 представлен последовательностью из 32 бит. Кодирование значений REAL32 соответствует стандарту IEEE 754-1985 для чисел с плавающей точкой одинарной точности (single precision floating-point). Тип данных REAL64 представлен последовательностью 64 бит. Кодирование REAL64 соответствует стандарту IEEE 754-1985 Standard для чисел с плавающей точкой двойной точности (double precision floating-point).

Последовательность бит длиной 32 имеет либо конкретное значение (конечное ненулевое реальное число, ±0, ±_) или NaN (not-a-number, не число). Последовательность бит

b = b₀ ... b₃₁

назначает значение (конечное ненулевое реальное число)

REAL32(b) = (-1)^S * 2^E-127 * (1 + F)

Здесь:

S = b₃₁ это знак числа.
E = b₃₀ * 2⁷ + … + b₂₃ * 2⁰, 0 < E < 255 это не смещенная экспонента числа (un-biased exponent).
F = 2^-23 (b₂₂ * 2²² + … + b₁ * 2¹ + b₀ * 2⁰) это дробная часть числа.

E = 0 используется для представления is used to represent ±0. E=255 используется для представления бесконечности и NaN.

Обратите внимание, что последовательность бит начинается слева самым младшим значащим битом.

Пример числа 6.25 в типа REAL32:

6.25 = 2^E-127 (1 + F)

здесь

E =129 =2⁷ +2⁰ и

F= 2^-1 +2^-4 = 2^-23 (2²²+2¹⁹), так что число представлено следующим образом:

6.25 = b₀ .. b₃₁ = 0000 0000 0000 0000 0001 0011 0000 0010

Это число будет передано в следующем порядке:

Рис. 12. Синтаксис передачи данных типа REAL32.

[9.1.5. Составные типы данных (Compound Data Types)]

Определения составных типов данных расширяются до уникального списка определений типа, включающих только основные типы данных. Соответственно составной тип данных 'type_name' это упорядоченный список компонентов данных, поименованных 'component_name_i' базового типа 'basic_type_i'.

Конструкторами составного типа данных являются ARRAY и STRUCT OF. Синтаксис:

STRUCT OF
   basic_type_1 component_name_1,
   basic_type_2 component_name_2,
   ...          ...
   basic_type_N component_name_N
type_name

ARRAY [ длина ] OF basic_type type_name

Последовательность бит, представляющая данные составного типа, получается конкатенацией последовательностей бит отдельных компонентов данных. Предположим, что компоненты 'component_name_i' представлены последовательностями бит b(i) для i = 1, ..., N. Тогда составной тип данных представлен склеенной последовательностью

b₀(1) .. b_n-1(1) .. b_n-1(N).

Пример:

Рассмотрим тип данных

STRUCT OF
   INTEGER10 x,
   UNSIGNED5 u
NewData

Предположим, что x = -423 = 259h, и u = 30 = 1Eh. Пусть b(x) и b(u) обозначают последовательности бит, представляющие значения x и u. Тогда:

b(x) = b₀(x) .. b₉(x) = 1001101001
b(u) = b₀(u) .. b₄(u) = 01111
b(xu) = b(x) b(u) = b₀(xu) .. b₁₄(xu) = 1001101001 01111

Значение этой структуры будет передано в 2 октетах, сначала 59h, и затем 7Ah.

[9.1.6. Расширенные типы данных (Extended Data Types)]

Эти типы состоят и данных базовых типов и составных типов данных, определенных в следующих подсекциях.

9.1.6.1. Строка октетов (Octet String). Тип данных OCTET_STRINGlength определен ниже; здесь length это длина строки октетов.

ARRAY [ length ] OF UNSIGNED8 OCTET_STRINGlength

9.1.6.2. Видимая строка (Visible String). Тип данных VISIBLE_STRINGlength определен ниже. Допустимые значения типа данных VISIBLE_CHAR: 0h и диапазон от 20h до 7Eh (7-битный код ASCII для видимых символов). Данные представлены по стандарту ISO 646-1973(E) как символы, кодируемые 7 битами. Здесь length это длина видимой строки.

UNSIGNED8                            VISIBLE_CHAR
ARRAY [ length ] OF VISIBLE_CHAR     VISIBLE_STRINGlength

Символ 0h необходим для завершения строки.

9.1.6.3. Строка Unicode (Unicode String). Тип данных UNICODE_STRINGlength определен ниже; здесь length это длина строки unicode.

ARRAY [ length ] OF UNSIGNED16 UNICODE_STRINGlength

9.1.6.4. Время дня (Time of Day). Тип данных TIME_OF_DAY представляет абсолютное время. Он следует правилам определения и кодирования TIME_OF_DAY таким образом, что представляется последовательностью бит длиной 48.

Компонент ms это время в миллисекундах после полуночи. Компонент days это количество дней, начиная от даты 1 января 1984 года.

STRUCT OF
   UNSIGNED28 ms,
   VOID4 reserved,
   UNSIGNED16 days
TIME_OF_DAY

9.1.6.5. Time Difference (разница по времени). Тип данных TIME_DIFFERENCE представляет разницу (интервал) во времени. Он следует правилам кодирования таким образом, что TIME_DIFFERENCE представлен последовательностью бит длиной 48.

Разницы времени это суммы количества дней и миллисекунд. Компонент ms это количество миллисекунд. Компонент days это количество дней.

STRUCT OF
   UNSIGNED28 ms,
   VOID4 reserved,
   UNSIGNED16 days
TIME_DIFFERENCE

Обратите внимание, что компонент VOID4 reserved применен для выравнивания полей бит по границе байта. Это сделано для удобства доступа к значениям данных, чтобы не нужно было делать лишние сдвиги и маскирования последовательностей бит.

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

Служба для запроса записи PDO является не подтверждаемой (unconfirmed). Продюсер PDO посылает данные процесса (process data) по сети в рамках PDO. Может быть 0..n потребителей PDO (consumers). На потребителе (потребителях) PDO будет показан прием допустимого PDO. На рис. 14 показан протокол Write PDO.

Рис. 14: Протокол Write PDO.

Process-Data: может быть до L байт данных приложения, в соответствии с отображением PDO. Если L превысит количество байт 'n', определенное реальной длиной отображения PDO, то только первые n байт будут использованы потребителем. Если L меньше n, то данные, принятые PDO, не обрабатываются, и будет выпущено сообщение аварии (Emergency message) с кодом ошибки 8210h, если поддерживается функционал Emergency.

Служба запроса чтения PDO является подтверждаемой (confirmed). Один или большее количество потребителей PDO передают фрейм remote (RTR) по сети. На приеме фрейма RTR продюсер PDO для запрашиваемого PDO передает этот PDO. Для всех потребителей PDO для этого PDO будет показан прием. Может быть 0..n потребителей PDO. Служба чтения является опциональной, и зависит от возможностей аппаратуры. Рис. 15 показывает протокол чтения PDO.

Рис. 15: Протокол Read PDO.

Process-Data: может быть до L байт данных приложения, в соответствии с отображением PDO. Если L превысит количество байт 'n', определенное реальной длиной отображения PDO, то только первые n байт будут использованы потребителем. Если L меньше n, то данные, принятые PDO, не обрабатываются, и будет выпущено сообщение аварии (Emergency message) с кодом ошибки 8210h, если поддерживается функционал Emergency.

С помощью сервисных объектов данных (SDO) предоставляется запись в OD устройства. Так как эти данные могут содержать данные произвольного размера, и тип данных SDO может быть использован для передачи нескольких наборов данных (каждый из которых может содержать произвольно большой блок данных) от клиента к серверу, и наоборот. Клиент может управлять через мультиплексор (индекс и sub-индекс словаря OD), какой набор данных должен передаваться. Содержимое набора данных определяется в OD.

Обычно SDO передается как последовательность сегментов. Перед передачей сегментов присутствует фаза инициализации, где клиент и сервер подготавливают самих себя к передаче сегментов. Для SDO также можно передавать набор данных до 4 байт включительно сразу на фазе инициализации. Этот механизм называется ускоренной передачей (expedited transfer).

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

Возможна выгрузка блока SDO (SDO Block Upload), с которой размер набора данных не выровнен по передаче блока, потому что подразумевается дополнительная нагрузка на протокол. В этих случаях на фазе инициализации может быть реализована поддержка отступа для сегментированной или ускоренной передачи. Поскольку предположение о минимальном размере набора данных, для которого блочная передача выигрывает по сравнению с другими типами передачи, зависит от различных параметров, клиент на фазе инициализации показывает это пороговое значение в байтах для сервера. Для блочной передачи используется схема Go-Back-n ARQ (Automatic Repeat Request, автоматический запрос повтора) для подтверждения каждого блока.

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

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

Для всех типов передач инициатива передачи находится на стороне клиента. Владельцем OD, к которому осуществляется доступ, является сервер SDO. Обе стороны - и клиент, и сервер могут взять инициативу по обрыву передачи SDO (abort).

С помощью SDO между устройствами устанавливается канал связи точка-точка (peer-to-peer). Устройство может поддерживать больше чем один объект SDO. В случае по умолчанию поддерживается один Server-SDO (SSDO), так называемый SDO по умолчанию (Default SDO).

Объекты SDO описываются записью параметра коммуникации SDO (SDO communication parameter record, 22h). Структура этого типа данных объясняется в 9.5.4. SDO communication parameter описывает возможности коммуникации для объектов Server-SDO и Client-SDOs (CSDO). Индексы соответствующих записей OD вычисляются по следующим формулам:

• SSDO communication parameter index = 1200h + номер_SSDO - 1
• CSDO communication parameter index = 1280h + номер_CSDO - 1

Для каждого SDO являются обязательными параметры коммуникации. Если существует только один SSDO, то параметры коммуникации могут быть опущены. Вышеописанные записи описаны в 9.5 (Object Dictionary).

9.2.2.1. Службы SDO. Для коммуникации SDO применяется модель клиент/сервер.

Атрибуты:

- SDO number: номер SDO [1..128] для каждого пользовательского типа локального устройства.
- user type: один из типов {client, server}.
- mux мультиплексор типа данных, содержащий индекс и sub-индекс типа: STRUCTURE OF UNSIGNED (16), UNSIGNED (8), с индексом, указывающим на запись в OD устройства, и sub-индексом, указывающим на компонент записи OD.
- transfer type: зависит от длины данных для передачи: expedited (ускоренная передача) для количества данных до 4 байт, и segmented (сегментированная) или block (блочная) для количества байт данных больше 4.
- data type: тип данных в соответствии со ссылающимся индексом и sub-индексом.

Следующие службы могут быть применены к SDO, в зависимости от требований приложения:

• SDO Download, что может быть разделено на
   - Initiate SDO Download (инициация загрузки SDO)
   - Download SDO Segment (загрузка сегмента SDO)
• SDO Upload, что может быть разделено на
   - Initiate SDO Upload (инициация выгрузки SDO)
   - Upload SDO Segment (выгрузка сегмента SDO)
• Abort SDO Transfer (обрыв передачи SDO)

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

Должна поддерживаться ускоренная передача (expedited transfer). Должна поддерживаться сегментированная передача, если поддерживаются объекты размером больше 4 байт. Опционально могут быть реализованы следующие службы SDO для выполнения блочной передачи с более рациональным использованием полосы шины для больших наборов данных:

• SDO Block Download (блочная загрузка SDO), что может быть разделено на
   - Initiate Block Download (инициация загрузки блока)
   - Download Block (загрузка блока)
   - End Block Download (окончание загрузки блока)
• SDO Block Upload (блочная выгрузка SDO), что может быть разделено на
   - Initiate Block Upload (инициация выгрузки блока)
   - Upload Block (выгрузка блока)
   - End Block Upload (окончание выгрузки блока)

Когда используются службы загрузки или выгрузки блока SDO, коммуникационное программное обеспечение будет отвечать за передачу данных в виде последовательности блоков.

В протоколе SDO Block Upload может быть реализована поддержка для переключения в протокол SDO Upload в 'Initiate SDO Block Upload', чтобы увеличить эффективность передачи для данных, размер которых не выравнивает использование нагрузки на протокол для протокола 'SDO Block Upload'.

Для обрыва блочной передачи SDO используется служба Abort SDO Transfer.

9.2.2.1.1. SDO Download. С помощью этой службы клиент SDO загружает данные на сервер (владелец OD). Для сервера показываются данные, мультиплексор (индекс и sub-индекс) набора данных, который загружается, и его размер (опционально только для сегментированной передачи).

Эта служба является подтверждаемой (confirmed). Параметр remote result будет показывать успех или ошибку запроса. В случае ошибки опционально подтверждается причина отказа.

Загрузка SDO состоит как минимум из службы Initiate SDO Download, и опционально службы Download SDO Segment (при длине данных > 4 байт).

Таблица 5. SDO Download.

9.2.2.1.2 Initiate SDO Download. Через эту службу клиент SDO запрашивает у сервера загрузку данных на сервер. Опционально серверу показывается размер данных для загрузки.

Серверу показывается мультиплексор набора данных, для которого инициируется загрузка, и тип передачи. В случает ускоренной загрузки (expedited download), данные набора идентифицируются по мультиплексору и размеру, которые показываются серверу.

Таблица 6. Initiate SDO Download.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха ускоренной (expedited) загрузки мультиплексированного DOMAIN, эта служба завершает загрузку набора данных, идентифицированного мультиплексором.

9.2.2.1.3. Download SDO Segment. Через эту службу клиент SDO предоставляет серверу данные следующего сегмента. Серверу показывается сегмент данных и опционально его размер. Параметр продолжения (continue parameter) показывает, будут ли еще загружены сегменты, или это был последний загруженный сегмент.

Таблица 7. Download SDO Segment.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха сервер принимает сегмент данных и готов принять следующий сегмент. Может быть самое большее одна служба Download SDO Segment, предназначенная для передачи SDO.

Перед этой службой должна быть успешно выполнена служба Initiate SDO Download с типом сегментированной передачи.

9.2.2.1.4. SDO Upload. Через эту службу клиент SDO выгружает данные из сервера. Серверу должен быть показан мультиплексор (индекс и sub-индекс) набора данных.

SDO upload состоит как минимум из службы Initiate SDO Upload и опционально из службы Upload SDO Segment (когда длина данных > 4 байт).

Таблица 8. SDO Upload.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность или отказ запроса. В случае отказа опционально подтверждается причина ошибки. В случае успеха подтверждаются данные и их размер (опционально для сегментированной передачи).

9.2.2.1.5. Initiate SDO Upload. Через эту службу клиент SDO запрашивает у сервера подготовиться к выгрузке данных для клиента. Серверу показывается мультиплексор (индекс и sub-индекс) набора данных, выгрузка которых инициируется.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха (опционально для сегментированной передачи) подтверждается размер выгруженных данных. В случае успешной ускоренной (expedited) выгрузки эта служба завершает выгрузку набора данных, обозначенных мультиплексором, и соответствующие данные подтверждаются.

Таблица 9. Initiate SDO Upload.

9.2.2.1.6. Upload SDO Segment. Через эту службу клиент SDO запрашивает сервер предоставить данные следующего сегмента. Параметром продолжения (continue parameter) клиент показывает, должны ли быть еще выгружены данные, или это был последний выгруженный сегмент. Может быть самое большее одна служба Upload SDO Segment, предоставленная для SDO.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха подтверждается сегмент данных и опционально подтверждается его размер.

Перед этой службой должна успешно выполниться служба Initiate SDO Upload с типом сегментированной передачи.

Таблица 10. Upload SDO Segment.

9.2.2.1.7. Abort SDO Transfer. Эта служба обрывает выгрузку или загрузку SDO, выбранную ссылкой на её номер. Опционально показывается причина обрыва. Эта служба является не подтверждаемой (unconfirmed). Служба может быть выполнена в любой момент времени обеими сторонами обмена, и клиентом, и сервером SDO. Если у клиента есть не не выполненная, подтвержденная служба SDO, для подтверждения этой службы показывается abort.

Таблица 11. Abort SDO Transfer.

9.2.2.1.8. SDO Block Download. Через эту службу клиент SDO загружает данные на сервер SDO (владелец OD), используя протокол блочной передачи. Серверу показываются данные, мультиплексор (индекс и sub-индекс) набора данных, который загружается, и опционально их размер.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность или отказ запроса. В случае отказа опционально подтверждается причина ошибки.

Таблица 12. SDO Block Download.

9.2.2.1.9. Initiate SDO Block Download. Через эту службу клиент SDO запрашивает сервер SDO (владельца OD) подготовиться к загрузке данных на сервер. Серверу показывается мультиплексор набора данных, для которых выполняется инициация, и опционально размер загружаемых данных в байтах.

Клиент, как и сервер, показывают свою возможность и/или требование проверить целостность передачи с помощью контрольной суммы в момент окончания загрузки блока (End SDO Block Download).

Таблица 13. Initiate SDO Block Download.

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса, количество сегментов в блоке, которое сервер SDO в состоянии принять, и свою возможность и/или требование проверить целостность данных с помощью контрольной суммы. В случае отказа должен быть выполнен запрос Abort SDO Transfer.

9.2.2.1.10. Download SDO Block. С помощью этой службы клиент SDO предоставляет данные следующего блока для сервера SDO. Для сервера показываются данные блока с помощью последовательности сегментов. Каждый сегмент состоит из данных и последовательного номера, начиная с 1, который увеличивается на 1 с каждым сегментом, вплоть до blksize. Параметр blksize оговаривается между сервером и клиентом в протоколе 'Initiate Block Download', и он может быть изменен сервером на каждом подтверждении передачи блока. Параметр продолжения (continue parameter) показывает, должен ли сервер оставаться на фазе 'Download Block', или должен перейти к фазе 'End Download Block'.

Таблица 14. Download SDO Block.

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса. В случае успеха параметр ackseq покажет последовательный номер последнего сегмента, который успешно принял сервер. Если этот номер не соответствует последовательному номеру последнего сегмента, отправленного клиентом во время передачи этого блока, то клиент должен повторно передать все сегменты, отброшенные сервером в момент передачи следующего блока. В случае фатального отказа, должен быть выполнен запрос Abort SDO Transfer. В случае успеха сервер должен подтвердить все принятые данные сегментов и быть готовым к поступлению следующего блока. Для передачи SDO может быть самое большее одна служба Download SDO Block.

Перед этой службой должна быть успешно выполнена служба 'Initiate SDO Block Download'.

9.2.2.1.11. End SDO Block Download. Через эту службу завершается загрузка блока SDO (SDO Block Download). Серверу показывается количество байт, не содержащих допустимые данные в последних переданных сегментах.

Если сервер, как и клиент, показал свою возможность (или запросил её) проверки целостности данных контрольной суммой на фазе 'Initiate SDO Block Download' то клиент показывает серверу эту контрольную сумму. Сервер также должен сгенерировать контрольную сумму для сравнения с контрольной суммой, сгенерированной клиентом.

Таблица 15. End SDO Block Download.

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса (с совпадением контрольных сумм, если о её проверке договорились клиент и сервер), и загрузка набора данных завершается. В случае отказа должен быть выполнен запрос Abort SDO Transfer.

9.2.2.1.12. SDO Block Upload. Через эту службу клиент SDO выгружает данные с сервера SDO (владельца OD) с помощью протокола выгрузки блока SDO (SDO block upload). Серверу показываются данные, мультиплексор (индекс и sub-индекс) набора данных, которые выгружаются на сервер, и опционально серверу показывается их размер.

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность или отказ запроса. В случае отказа опционально подтверждается причина ошибки. В случае успеха подтверждаются данные и опционально их размер.

Таблица 16. SDO Block Upload.

9.2.2.1.13. Initiate SDO Block Upload. Через эту службу клиент SDO запрашивает сервер SDO (владелец OD) подготовиться к выгрузке данных для клиента. Серверу показывается мультиплексор данных, для которых инициируется выгрузка, и количество сегментов, которое клиент SDO может принять.

Серверу показывается значение порога переключения протокола (protocol switch threshold). Если количество байт, которое должно быть выгружено, меньше или равно этому значению, то сервер может опционально завершить эту передачу данных c 'SDO Upload Protocol', как это описано в 9.2.2.1.4.

Клиент, как и сервер, показывает свою возможность и/или запрашивает необходимость проверки целостности данных с помощью контрольной суммы на фазе 'End SDO Block Upload'.

Опционально для клиента показывается размер выгружаемых данных в байтах.

Таблица 17. Initiate SDO Block Upload.

Эта служба подтверждаемая (confirmed). В случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха клиенту опционально показывается размер выгруженных данных в байтах. Если размер данных, которые выгружаются, меньше или равно порогу, то сервер может продолжить работу по протоколу SDO block upload. В этом случае параметр Remote Result и будущий протокол работают в соответствии с описанием в 9.2.2.2.14.

9.2.2.1.14. Upload SDO Block. Через эту службу клиент SDO выгружает данные следующего блока с сервера SDO. Клиенту показывается блок данных с помощью следующих друг за другом сегментов. Каждый сегмент состоит из данных сегмента и последовательного номера, начинающегося с 1, и увеличивающегося на 1 с каждым сегментом, вплоть до blksize. Параметр blksize оговаривается между сервером и клиентом в протоколе 'Initiate Block Upload', и он может быть изменен клиентом с каждым подтверждением передачи блока. Параметр continue показывает клиенту, должен ли он оставаться на фазе 'Upload Block', или следует перейти к фазе 'End Upload Block'.

Таблица 18. Upload SDO Block.

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса. В случае успеха параметр ackseq покажет последовательный номер последнего сегмента, который успешно принял клиент. Если этот номер не соответствует последовательному номеру последнего сегмента, отправленного сервером во время передачи этого блока, то сервер должен повторно передать все сегменты, отброшенные клиентом в момент передачи следующего блока. В случае фатального отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха клиент должен подтвердить все принятые данные сегментов, и быть готовым к поступлению следующего блока. Для передачи SDO может быть самое большее одна служба Download SDO Block.

Перед этой службой должна быть успешно выполнена служба 'Initiate SDO Block Upload'.

9.2.2.1.15. End SDO Block Upload. Через эту службу завершается выгрузка блока (SDO Block Upload). Клиенту показывается количество байт, не содержащих допустимые данные в последних переданных сегментах.

Если сервер, как и клиент, показал свою возможность (или запросил её) проверки целостности данных контрольной суммой на фазе 'Initiate SDO Block Upload' то сервер показывает клиенту эту контрольную сумму. Клиент также должен сгенерировать эту контрольную сумму для сравнения с контрольной суммой, сгенерированной сервером.

Таблица 19. End SDO Block Upload.

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса (с совпадением контрольных сумм клиента и сервера, если это запрашивалось), и загрузка набора данных завершается. В случае отказа должен быть выполнен запрос Abort SDO Transfer.

Рис. 16. Протокол Download SDO.

Этот протокол используется для реализации службы SDO Download. Объекты SDO загружаются как последовательность 0 или большего количества служб Download SDO Segment, перед которым была служба Initiate SDO Download. Эта последовательность завершается через:

• Запросом/индикацией Initiate SDO Download с e-битом, установленным 1, за которым идет ответ/подтверждение Initiate SDO Download, показывающее успешное завершение ускоренной (expedited) последовательности загрузки.
• Запросом/подтверждением Download SDO Segment с c-битом, установленным в 1, показывающим успешное завершение обычной (не ускоренной) последовательности загрузки.
• Запросом/индикацией Abort SDO Transfer, показывающим не успешное завершение последовательности загрузки.
• Новым запросом/индикацией Initiate Domain Download, показывающим завершение по ошибке последовательности загрузки и запуск новой последовательности загрузки.

Если при загрузке следующих друг за другом сегментов бит toggle не изменился, то содержимое последнего сегмента игнорируется. Если о такой ошибке сообщено приложению, то приложение может принять решение оборвать загрузку (abort).

Этот протокол используется при реализации службы Initiate SDO Download для объектов SDO.

Рис. 17. Протокол Initiate SDO Download.

• ccs: client command specifier (команда клиента)
1: initiate download request (инициировать запрос загрузки)

• scs: server command specifier (команда сервера)
3: initiate download response (инициировать ответ на загрузку)

• n: допустимо только если e = 1 и s = 1, иначе 0. Если допустимо, то это показывает количество байт в d, которое не содержит данных. Байты [8-n, 7] не содержат данных.

• e: тип передачи
0: normal transfer (нормальная передача)
1: expedited transfer (ускоренная передача)

• s: индикатор размера
0: размер набора данных не показан
1: указан размер набора данных

• m: multiplexor. Он представляет индекс/sub-индекс данных для передачи объектом SDO.

• d: data (данные)
e = 0, s = 0: d зарезервирован для будущего использования.
e = 0, s = 1: d содержит количество байт для загрузки. Байт 4 содержит младшие биты, и байт 7 содержит старшие биты.
e = 1, s = 1: d содержит данные для загрузки, длина которых равна 4-n. Кодирование данных зависит от типа данных. К данным ссылаются по индексу и sub-индексу.
e = 1, s = 0: d содержит не указанное количество байт для загрузки.

• X: не используется, всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

Этот протокол используется для реализации службы Download SDO Segment (загрузка сегмента SDO).

Рис. 18. Протокол Download SDO Segment.

• ccs: client command specifier (команда клиента)
0: download segment request (запрос на загрузку сегмента)

• scs: server command specifier (команда сервера)
1: download segment response (ответ на загрузку сегмента)

• seg-data: здесь могут быть максимум 7 байт данных сегмента для загрузки. Кодирование этих байт зависит от данных, которые были запрошены индексом и sub-индексом.

• n: показывает количество байт в seg-data, которые не содержат данных сегмента. Байты [8-n, 7] не содержат данных сегмента. n = 0, если не показан размер сегмента.

• c: показывает, должны ли быть ещё сегменты для загрузки.
0: будут еще сегменты для загрузки
1: больше не будет сегментов для загрузки

• t: бит toggle. Этот бит должен переключаться с каждым последующим загружаемым сегментом. В первом сегменте бит toggle устанавливается в 0. Бит toggle будет совпадать для сообщения запроса и для сообщения ответа.

• X: не используется, здесь всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

Рис. 19. Протокол Upload SDO.

Этот протокол используется для реализации службы SDO Upload (выгрузка SDO). SDO выгружается как последовательность 0 или большего количества служб Upload SDO Segment, перед которыми предшествовала служба Initiate SDO Upload. Последовательность выгрузки прерывается следующим:

• Ответ/подтверждение на Initiate SDO Upload, где бит e установлен в 1, что показывает успешное завершение ускоренной (expedited) последовательности выгрузки.
• Ответ/подтверждение на Upload SDO Segment, где бит c установлен в 1, показывая тем самым успешное завершение обычной (не ускоренной) последовательности выгрузки.
• Запрос/индикация Abort SDO Transfer, что показывает не успешное завершение последовательности выгрузки.
• Новый запрос/индикация Initiate SDO Upload, что показывает не успешное завершение текущей последовательности выгрузки и запуск новой последовательности.

Если при выгрузке следующих друг за другом сегментов бит toggle не поменялся, то содержимое последнего сегмента игнорируется. Если такая ошибка сообщена приложению, то приложение может принять решение прервать (abort) выгрузку.

Этот протокол используется для реализации службы Initiate SDO Upload (инициировать выгрузку SDO).

Рис. 20: Протокол Initiate SDO Upload.

• ccs: client command specifier (команда клиента)
2: initiate upload request (запрос инициации выгрузки)

• scs: server command specifier (команда сервера)
2: initiate upload response (ответ на команду инициировать выгрузку)

• n: допустимо только если e = 1 и s = 1, иначе 0. Если допустимо, то показывает количество байт, которое не содержит данные. Байты [8-n, 7] не содержат данные сегмента.

• e: тип передачи
0: normal transfer (обычная передача)
1: expedited transfer (ускоренная передача)

• s: индикатор размера
0: размер набора данных не показан
1: показан размер набора данных

• m: multiplexor. Он представляет индекс / sub-индекс данных для передачи объектом SDO.

• d: data (данные)
e = 0, s = 0: d зарезервировано для использования в будущем.
e = 0, s = 1: d содержит количество байт для выгрузки. Байт 4 содержит младшие биты, и байт 7 старшие биты.
e = 1, s = 1: d содержит длину данных 4-n для выгрузки кодирование зависит от типа данных, к которым было обращение по индексу и sub-индексу.
e = 1, s = 0: d содержит не указанное количество байт для выгрузки.

• X: не используется, здесь всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

Этот протокол используется для реализации службы Upload SDO Segment (выгрузка сегмента SDO).

Рис. 21: Протокол Upload SDO Segment.

• ccs: client command specifier (команда клиента)
3: download segment request (запрос на выгрузку сегмента)

• scs: server command specifier (команда сервера)
3: download segment response (ответ на выгрузку сегмента)

• t: бит toggle. Этот бит должен переключаться с каждым последующим выгружаемым сегментом. В первом сегменте бит toggle устанавливается в 0. Бит toggle будет совпадать для сообщения запроса и для сообщения ответа.

• c: показывает, должны ли быть ещё сегменты для выгрузки.
0: будут еще сегменты для выгрузки
1: больше не будет сегментов для выгрузки

• seg-data: здесь могут быть максимум 7 байт данных сегмента для выгрузки. Кодирование этих байт зависит от данных, которые были запрошены индексом и sub-индексом.

• n: показывает количество байт в seg-data, которые не содержат данных сегмента. Байты [8-n, 7] не содержат данных сегмента. n = 0, если не показан размер сегмента.

• X: не используется, здесь всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

Этот протокол используется для реализации службы Abort SDO Transfer (обрыв передачи SDO).

Рис. 22. Протокол Abort SDO Transfer.

• cs: спецификатор команды
4: abort transfer request (оборвать запрос передачи)

• X: не используется, всегда 0

• m: multiplexor. Он представляет индекс и sub-индекс SDO.

• d: содержит 4 байта кода обрыва (abort code), которые сообщают о причине.

Код abort закодирован как значение UNSIGNED32.

Таблица 20. Коды SDO abort.

Не перечисленные коды abort зарезервированы.

Рис. 23. Протокол SDO Block Download.

Этот протокол используется для реализации службы SDO Block Download. Объекты SDO загружаются как последовательность служб Download SDO Block, перед которой запускается служба Initiate SDO Block Download. Последовательность SDO Download Block завершается:

• загруженным сегментом, где c-бит установлен в 1, показывая этим завершение последовательности загрузки блока, или

• запросом/индикацией Abort SDO Transfer, показывающими не успешное завершение последовательности загрузки.

Вся служба SDO Block Download завершается службой End SDO Block Download. Если клиент, как и сервер, показал возможность генерировать CRC во время службы Initiate SDO Block Download, то сервер сгенерировал CRC на принятых данных. Если эта CRC отличается от CRC, которую сгенерировал клиент, то сервер покажет это индикацией Abort SDO Transfer.

Этот протокол используется для реализации службы Initiate SDO Block Download.

Рис. 24. Протокол Initiate SDO Block Download.

• ccs: спецификатор команды клиента
6: загрузка блока

• scs: спецификатор команды сервера
5: загрузка блока

• s: индикатор размера
0: размер набора данных не показан
1: указан размер набора данных

• cs: sub-команда клиента
0: initiate download request (запрос на инициацию загрузки)

• ss: sub-команда сервера
0: initiate download response (ответ на инициацию загрузки)

• cc: поддержка CRC клиентом
cc = 0: клиент не поддерживает генерацию CRC по данным
cc = 1: клиент поддерживает генерацию CRC по данным

• sc: поддержка CRC сервером
sc = 0: сервер не поддерживает генерацию CRC по данным
sc = 1: сервер поддерживает генерацию CRC по данным

• m: multiplexor. Он представляет индекс/sub-индекс данных для передачи объектом SDO.

• size: загружаемый размер в байтах
s = 0: size резервируется для использования в будущем, всегда 0
s = 1: size содержит количество байт для загрузки. Байт 4 содержит младший байт, и байт 7 старший байт.

• blksize: количество сегментов на блок, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы Block Download (загрузка блока).

Рис. 25. Протокол Download SDO Block Segment.

• scs: server command specifier (команда сервера)
5: block download (загрузка блока)

• ss: server subcommand (sub-команда сервера)
2: block download response (ответ на загрузку блока)

• c: показывает, есть ли еще сегменты для загрузки
0: есть еще сегменты для загрузки
1: больше нет сегментов для загрузки, вход в фазу загрузки End SDO block download (окончание загрузки блока)

• seqno: последовательный номер сегмента, 0 < seqno < 128.

• seg-data: как минимум 7 байт данных загружаемого сегмента.

• ackseq: последовательный номер последнего сегмента, который был принят во время последней загрузки блока. Если ackseq установлен в 0, то сервер показывает клиенту, что сегмент с последовательным номером 1 не был корректно принят, и все сегменты должны быть повторно переданы клиентом.

• blksize: количество сегментов на блок, которое должен использовать клиент при последующей загрузке блока, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы End SDO Block Download.

Рис. 26. Протокол End SDO Block Download.

• ccs: client command specifier (команда клиента)
6: загрузка блока

• scs: server command specifier (команда сервера)
5: загрузка блока

• cs: client subcommand (sub-команда клиента)
1: запрос окончания загрузки блока

• ss: server subcommand (sub-команда сервера)
1: ответ на окончание загрузки блока

• n: показывает количество байт в последнем сегменте последнего блока, которое не содержит данных. Байты [8-n, 7] не содержат данные сегмента.

• crc: 16-битная контрольная сумма (Cyclic Redundancy Checksum, CRC) для всего набора данных. Алгоритм генерации CRC описан в 9.2.2.2.16. CRC допустима только если в протоколе Initiate Block Download поля cc и sc установлены в 1, иначе CRC должна быть установлена в 0.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Рис. 27. Протокол Upload SDO Block.

Этот протокол используется для реализации службы SDO Block Upload, которая начинается со службы Initiate SDO Block Upload. Клиент может показать пороговое значение для сервера, которое минимальное значение в байтах для увеличения производительности передачи с помощью использования протокола SDO Block Upload вместо протокола SDO Upload. Если размер набора данных меньше или равен этому значению, то сервер может продолжить с нормальной или ускоренной (expedited) передачей протокол SDO Block Upload.

Иначе объекты SDOs выгружаются как последовательность Upload SDO Block служб. Последовательность SDO Upload Block завершается:

• выгруженным сегментом в блоке с c-битом, установленным в 1, показывая тем самым завершение последовательности выгрузки блока.

• запросом/индикацией Abort SDO Transfer, которые показывают не успешное завершение последовательности выгрузки.

Вся служба SDO Block Upload завершается службой End SDO Block Upload. Если клиент, как и сервер, показал возможность генерировать CRC во время службы Initiate SDO Block Upload, то клиент сгенерировал CRC на принятых данных. Если эта CRC отличается от CRC, которую сгенерировал сервер, то клиент покажет это индикацией Abort SDO Transfer.

Этот протокол используется для реализации службы Initiate SDO Block Upload. Если значение параметра порога переключения протокола (Protocol Switch Threshold), показанный клиентом в первом запросе, оказался меньше или равным размеру набора данных для выгрузки, то сервер может продолжить выгрузку с протоколом SDO Upload, как это описано в 9.2.2.2.4.

Рис. 28. Протокол Initiate SDO Block Upload.

• ccs: client command specifier (команда клиента)
5: block upload (выгрузка блока)

• scs: server command specifier (команда сервера)
6: block upload (выгрузка блока)

• cs: client subcommand (sub-команда клиента)
0: запрос инициации выгрузки
3: старт выгрузки

• ss: server subcommand (sub-команда сервера)
0: ответ на инициацию выгрузки

• m: multiplexor. Он представляет индекс/sub-индекс данных для передачи объектом SDO.

• cc: поддержка CRC клиентом
cc = 0: клиент не поддерживает генерацию CRC по данным
cc = 1: клиент поддерживает генерацию CRC по данным

• sc: поддержка CRC сервером
sc = 0: сервер не поддерживает генерацию CRC по данным
sc = 1: сервер поддерживает генерацию CRC по данным

• pst: Protocol Switch Threshold (порог переключения протокола) в байтах, чтобы поменять протокол передачи SDO.
pst = 0: изменение протокола не разрешено.
pst > 0: если размер данных в байтах для выгрузки меньше или равно pst, то сервер может опционально переключиться на протокол SDO Upload путем передачи сервером ответа 'SDO Upload Protocol', как это описано в 9.2.2.2.4.

• s: индикатор размера
0: размер набора данных не показан
1: показан размер набора данных

• size: выгружаемый размер в байтах
s = 0: size резервирован для будущего использования, всегда 0
s = 1: size содержит количество байт для выгрузки. Байт 4 содержит младший байт, байт 7 содержит старший байт.

• blksize: количество сегментов на блок, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы SDO Block Upload.

Рис. 29. Протокол Upload SDO Block Segment.

• ccs: client command specifier (команда клиента)
5: block upload (выгрузка блока)

• cs: client subcommand (sub-команда клиента)
2: block upload response (ответ на выгрузку блока)

• c: показывает, есть ли еще сегменты для выгрузки
0: есть еще сегменты для выгрузки
1: больше нет сегментов для выгрузки, вход в фазу End block upload

• seqno: последовательный номер сегмента, 0 < seqno < 128.

• seg-data: самое большее 7 байт данных сегмента для выгрузки.

• ackseq: последовательный номер последнего сегмента, который был успешно принят во время последней выгрузки блока. Если ackseq установлен в 0, то клиент показывает серверу, что сегмент с последовательным номером 1 не было принят корректно, и все сегменты должны быть повторно переданы сервером.

• blksize: количество сегментов на блок, которое должно использоваться сервером для следующей выгрузке блока, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы End SDO Block Upload.

Рис. 30: Протокол End SDO Block Upload.

• ccs: client command specifier (команда клиента)
5: block upload (выгрузка блока)

• scs: server command specifier (команда сервера)
6: block upload (выгрузка блока)

• cs: client subcommand (sub-команда клиента)
1: запрос окончания выгрузки блока

• ss: server subcommand (sub-команда сервера)
1: ответ на окончание выгрузки блока

• n: показывает количество байт в последнем сегменте, последнего блока, которое не содержит данных. Байты [8-n, 7] не содержат данные сегмента.

• crc: 16-битная контрольная сумма (Cyclic Redundancy Checksum, CRC) всего набора данных. Алгоритм для генерации CRC описан в 9.2.2.2.16. CRC допустима только если в службе Initiate Block Upload поля cc и sc установлены в 1, иначе CRC должна быть установлена в 0.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Чтобы проверить корректность выгрузки/загрузки блока SDO, клиент и сервер вычисляют контрольную сумму (CRC) значением которой обмениваются в протоколе End SDO Block Download/End SDO Block Upload. Накопление CRC происходит по полиному x^16 + x^12 + x^5 + 1, с начальным значением 0.

9.2.5.1. Использование объекта EMCY. Объекты Emergency (авария) срабатывают при возникновении ошибки, обнаруженной устройством, и они передаются продюсером аварии (emergency producer) устройства. Объекты аварии подходят для оповещений об ошибках наподобие прерываний. Объект EMCY передается только один раз на событие ошибки (error event). Больше не должны передаваться объекты EMCY, пока не появятся новые ошибки устройства. Объект EMCY может быть не принят никем, либо одним или большим количеством потребителей. Реакция потребителя (потребителей) EMCY не задана, и не попадает в область рассмотрения этого документа. Заданы смысловые значения кодов ошибки аварии (таблица 21) и регистр ошибки (error register, таблица 48). Дополнительная специфическая информация устройства и условия возникновения аварии не попадают в область рассмотрения этой спецификации.

Таблица 21. Emergency Error Codes (коды ошибок аварии).

Объект аварии не обязателен. Если устройство поддерживает объект аварии, то оно должно поддерживать как минимум 2 кода ошибки 00xx и 10xx. Все другие коды ошибки являются необязательными.

Устройство может иметь одно из двух состояний аварии (emergency states, рис. 33). В зависимости от переходов между состояниями будут отправляться объекты аварии. Связи между машиной состояний ошибок и машиной состояний NMT определена в профилях устройства.

0. После инициализации устройство входит в состояние без ошибки, если не было определено ни одной ошибки. Не будет отправлено сообщение об ошибке.

1. Устройство определило внутреннюю ошибку, которая показывается в первых 3 байтах сообщения аварии (error code и error register). Устройство входит в состояние ошибки (error state). Передается объект аварии с соответствующим кодом ошибки (error code) и регистром ошибки (error register). Код ошибки заполняется в объект 1003H (заранее определенное поле ошибки).

2. Одна, но не все причины ошибки были переданы. Может быть отправлено сообщение ошибки, содержащее код ошибки 0000 (Error reset) вместе с оставшимися ошибками в регистре ошибки и в специфическом для производителя поле ошибки.

3. Произошла новая ошибка на устройстве. Устройство остается в состоянии ошибки, и передает объект аварии с соответствующим кодом новой ошибки. Код новой ошибки заполняется на вершине массива кодов ошибок (1003H). Это дает гарантию, что коды ошибки будут сортированы по времени возникновения (самая старая ошибка получит самый большой sub-индекс, см. Object 1003H).

4. Все ошибки исправлены. Устройство входит в состояние без ошибок, и передает объект аварии с кодом ошибки (reset error / no error).

Рис. 33. Диаграмма перехода между состояниями аварии.

9.2.5.2. Emergency Object Data. Телеграмма аварии состоит из 8 байтов с данными, показанными на рис. 34.

Рис. 34. Emergency Object Data (данные объекта аварии).

9.2.5.3. Emergency Object Services. Передача объекта аварии следует push-модели nbgf "producer – consumer", как описано в 6.3.3. Для объекта аварии заданы следующие атрибуты:

user type:    notifying device: producer
              receiving devices: consumer

data type:    STRUCTURE OF
              UNSIGNED(16) emergency_error_code,
              UNSIGNED(8) error_register,
              ARRAY (5) of UNSIGNED(8) manufacturer_specific_error_field

inhibit time: Application specific

9.2.5.4. Emergency Object Protocol. Определена одна не подтверждаемая служба (Write EMCY).

Рис. 35: Протокол Emergency Object.

Не допускается запрашивать объект аварии через запрос RTR.

Система управления сетью (Network Management, NMT) ориентирована на узлы сети, и следует модели master-slave. Объекты NMT используются для запуска служб NMT. Через службы NMT узлы инициализируются, запускаются, мониторятся, сбрасываются или останавливаются. Все узлы по отношению к NMT считаются подчиненными. NMT Slave уникально идентифицируется в сети по своему Node-ID (значение в диапазоне 1..127).

NMT требует, чтобы одно из устройств в сети выполняло функцию NMT.

9.2.6.1. Службы NMT

9.2.6.1.1. Module Control Services. С помощью службы управления модулями NMT master управляет состоянием устройств NMT slave. Атрибут состояния может быть одним из значений {STOPPED, PRE-OPERATIONAL, OPERATIONAL, INITIALISING}. Module Control Services могут быть выполнены над одним определенным узлом или над всеми узлами сети одновременно. NMT master управляет своей собственной машиной состояний NMT через локальные службы, зависящие от реализации. Module Control Services, кроме службы Start Remote Node, могут быть инициированы локальным приложением.

Start Remote Node

Через эту службу NMT Master устанавливает состояние выбранных узлов NMT Slaves в состояние OPERATIONAL.

Таблица 22. Start Remote Node (запуск дальнего узла).

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет OPERATIONAL.

Stop Remote Node

Через эту службу NMT Master устанавливает состояние выбранных узлов NMT Slaves в состояние STOPPED.

Таблица 23. Stop Remote Node (остановка дальнего узла).

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет STOPPED.

Enter Pre-Operational

Через эту службу NMT устанавливает состояние выбранного узла NMT Slave (или узлов) в состояние PREOPERATIONAL.

Таблица 24. Enter Pre-Operational (вход в предварительное рабочее состояние).

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет PRE-OPERATIONAL.

Reset Node

Через эту службу NMT переводит состояние выбранного узла NMT Slave (или узлов) из любого состояния в промежуточное состояние "сброс приложения".

Таблица 25. Reset Node (сброс узла).

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет RESET APPLICATION.

Reset Communication

Через эту службу NMT переводит состояние выбранного узла NMT Slave (или узлов) из любого состояния в промежуточное состояние "сброс обмена данными". После завершения этой службы выбранные узлы сети будут в состоянии RESET COMMUNICATION.

Таблица 26. Reset Communication (сброс обмена данными).

Эта служба не подтверждаемая, и её наличие обязательно для всех устройств.

9.2.6.1.2. Error Control Services. Через службы контроля ошибок NMT определяет отказы в сети CAN. Локальные ошибки на узле могут, например, приводить к сбросу или изменению состояния узла. Определение локальных ошибок не попадает в область рассмотрения этой спецификации.

Службы Error Control реализованы по принципу периодической отправки сообщений устройством. Имеется 2 варианта выполнения Error Control.

Так называемая защита (guarding) достигается передачей запросов guarding (протокол Node guarding) от устройства NMT Master. Если устройство NMT Slave не отвечает в определенный интервал времени (node life time, время жизни узла), или если неожиданно поменялся статус коммуникации NMT Slave, то NMT Master информирует свое приложение об этом событии.

Если поддерживается Life guarding (устройство NMT slave защищает устройство NMT master), то slave-устройство использует время защиты (guard time) и множитель времени жизни (lifetime factor) из своего OD, чтобы определить время жизни узла. Если NMT Slave оказался не защищен за это время жизни, то NMT Slave оповещает свое локальное приложение об этом событии. Если параметры guard time и life time factor равны 0 (значения по умолчанию), то NMT Slave не защищает NMT Master.

Защита запускается для slave, когда принят первый запрос на передачу для его guarding-идентификатора. Это может произойти на фазе загрузки (boot-up) или позже.

Механизм heartbeat устанавливается через циклическую передачу сообщения от heartbeat-продюсера. Одно или большее количество устройств в сети знают об этом сообщении подтверждения работоспособности. Если цикл heartbeat был нарушен для heartbeat-продюсера, то локальное приложение heartbeat-потребителя будет оповещено об этом событии.

Реализация либо системы guarding, либо heartbeat является обязательной.

Node Guarding Event. Через эту службу провайдер службы NMT показывает, что произошла ошибка сетевого узла, ли она была разрешена для узла, идентифицированного по Node-ID.

Таблица 27. Node Guarding Event (событие защиты узла).

Эта служба инициируется провайдером и является опциональной.

Life Guarding Event. Через эту службу провайдер службы NMT на устройстве NMT Slave показывает, что произошла ошибка сетевого узла, или она была исправлена.

Таблица 28. Life Guarding Event (событие охраны жизнеспособности узла).

Эта служба инициируется провайдером и является опциональной.

Heartbeat Event. Через эту службу потребитель Heartbeat показывает, что произошла ошибка heartbeat, или эта ошибка была исправлена на узле, идентифицированном по Node-ID.

Таблица 29. Heartbeat Event (событие сердцебиения).

Эта служба инициируется провайдером и является опциональной.

9.2.6.1.3. Bootup Service

Bootup Event. Через эту службу устройство NMT показывает, что его локальное состояние перешло из INITIALISING в состояние PRE-OPERATIONAL.

Таблица 30. Bootup Event (событие загрузки узла).

Эта служба инициируется провайдером и является обязательной.

9.2.6.2. Протоколы NMT

9.2.6.2.1. Протоколы Module Control

Протокол Start Remote Node. Этот протокол используется для реализации службы Start Remote Node.

Рис. 36. Протокол Start Remote Node.

• cs: NMT command specifier (команда NMT)
1: start

Протокол Stop Remote Node. Этот протокол используется для реализации службы Stop Remote Node.

Рис. 37. Протокол Stop Remote Node.

• cs: NMT command specifier (команда NMT)
2: stop

Протокол Enter Pre-Operational. Этот протокол используется для реализации службы Enter Pre-Operational.

Рис. 38. Протокол Enter Pre-Operational.

• cs: NMT command specifier (команда NMT)
128: войти в состояние PRE-OPERATIONAL

Протокол Reset Node. Этот протокол используется для реализации службы Reset Node.

Рис. 39. Протокол Reset Node.

cs: NMT command specifier (команда NMT)
129: Reset Node (сброс узла)

Протокол Reset Communication. Этот протокол используется для реализации службы Reset Communication.

Рис. 40. Протокол Reset Communication.

cs: NMT command specifier (команда NMT)
130: Reset Communication (сброс обмена данными)

9.2.6.2.2. Протоколы Error Control

Протокол Node Guarding. Этот протокол используется для определения сетевых ошибок (remote errors). Каждое устройство NMT Slave использует один remote COB-ID для протокола Node Guarding. Этот протокол реализует инициируемые провайдером службы Error Control.

Рис. 41. Протокол Node Guarding.

Примечание *: если произошла ошибка защиты (guarding error).

s: состояние NMT
   4: STOPPED
   5: OPERATIONAL
   127: PRE-OPERATIONAL

t: toggle bit. Значение этого бита должно каждый раз меняться между двумя соседними ответами от NMT Slave. Значение бита toggle первого ответа после активизации протокола Guarding будет равно 0. Toggle Bit в протоколе guarding сбрасывается в 0 только когда передан reset_communication (никакие другие переходы между состояниями узла не сбрасывают бит toggle). Если принят ответ с тем же самым значением бита toggle, как и в предыдущем ответе, то тогда новый ответ обрабатывается как пропуск сообщения ответа.

NMT Master опрашивает каждый узел NMT Slave с регулярными интервалами времени. Этот интервал называется guard time, и он может отличаться для каждого NMT Slave. Ответ от NMT Slave содержит его состояние. Параметр времени жизни (node life time) узла дается как guard time, умноженное на life time factor. Время жизни узла может отличаться для каждого NMT Slave. Если NMT Slave не был опрошен в свой интервал времени life time, будет показана ошибка дальнего узла (remote node error) через службу Life Guarding Event. Ошибка remote node error показывается через службу Node guarding event, если:

• Запрос RTR не был подтвержден за время node life time.
• Состояние, сообщенное NMT slave, не соответствует ожидаемому.

Если была индикация, что произошла ошибка remote error, и ошибки в протоколе guarding исчезли, то это будет показано как исправление remote error с помощью служб Node Guarding Event и Life Guarding Event.

Для интервала guard time и для life time factor имеются значения по умолчанию, заданные в соответствующих элементах OD.

Протокол Heartbeat. Этот протокол определяет службу контроля ошибок (Error Control Service) без необходимости посылать фреймы RTR. Продюсер Heartbeat циклически передает сообщение Heartbeat. Один или большее количество потребителей Heartbeat принимают эту индикацию. Взаимодействие между продюсером и потребителем конфигурируется через OD. Потребитель Heartbeat защищает прием Heartbeat в пределах интервала Heartbeat Consumer Time. Если сообщение Heartbeat не было принято в этом интервале, то генерируется Heartbeat Event, сообщающее об ошибке.

Рис. 42. Протокол Heartbeat.

r: зарезервировано (всегда 0)

s: состояние продюсера Heartbeat
   0: BOOTUP
   4: STOPPED
   5: OPERATIONAL
   127: PRE-OPERATIONAL

Если Heartbeat Producer Time сконфигурировано на устройстве, то протокол Heartbeat немедленно начинает работу. Если устройство запускается со значением для Heartbeat Producer Time, не равным 0, то протокол Heartbeat запускается в момент перехода из состояния INITIALISING в состояние PRE-OPERATIONAL. В этом случае сообщение Bootup считается как первое сообщение heartbeat. Не разрешено для одного устройства использовать оба механизма защиты одновременно, Guarding Protocol и Heartbeat Protocol. Если интервал Heartbeat Producer Time не равен 0, то для защиты используется протокол Heartbeat.

9.2.6.2.3. Протокол Bootup. Этот протокол используется для сигнала о том, что устройство NMT slave вошло в состояние узла PRE-OPERATIONAL перед тем, как оно было в состоянии INITIALISING. Протокол использует тот же идентификатор, что и протоколы контроля ошибок.

Рис. 43. Протокол Bootup.

Передается 1 байт данных со значением 0.

Состояние "Инициализация" делится на три sub-состояния (см. рис. 49), чтобы позволить выполнить полный или частичный сброс узла.

1. Initialising: это первое sub-состояние устройство, в которое оно входит после включения питания или аппаратного сброса. После завершения базовой инициализации узла устройство само входит в состояние Reset_Application.

2. Reset_Application: в этом состоянии устанавливаются в свое состояние "после включения питания" параметры (power-on values), относящиеся либо к специальному профилю устройства производителя, либо к стандартизованному профилю устройства. После установки этих настроек устройство автоматически входит в состояние Reset_Communication.

3. Reset_Communication: в этом состоянии устанавливаются в параметры профиля коммуникации в свои значения "после включения питания" (power-on values). После этого состояние Инициализации завершается, и устройство запускает службу "write boot-up" (короче говоря, выдает в сеть NMT-сообщение boot-up) и входит в состояние PRE-OPERATIONAL.

Значения "после включения питания" это значения настроек, которые были сохранены последний раз (если устройство имеет энергонезависимую память для хранения настроек), или настройки, установленные перемычками. Если сохранение не поддерживается, или не было выполнено, или если сбросу предшествовала команда restore_default (объект OD 1011H), то the power-on values будут соответствовать настройкам по умолчанию в соответствии со спецификациями коммуникации и профиля устройства.

Рис. 49. Структура состояния инициализации.

В состоянии PRE-OPERATIONAL возможен обмен данными через объекты SDO. Объекты PDO не существуют, поэтому обмен PDO не разрешен. Конфигурирующим приложением (обычно это мастер сети CANopen) может быть выполнено конфигурирование объектов PDO, параметров устройства и также выделение в нем объектов приложения (отображение переменных приложения на объекты PDO, так называемое PDO-mapping). Узел сети устройства может быть переключен по NMT-команде в состояние Operational (запрос мастера сети Start Remote Node).

В состоянии OPERATIONAL активны все коммуникационные объекты устройства (SDO, PDO, TIME, SYNC). Переход в OPERATIONAL создает все объекты PDO; конструктор использует параметры, как это описано в OD. Возможен доступ к OD через SDO. Однако аспекты реализации машины состояний приложения могут потребовать ограничить доступ к определенным объектам во время рабочего состояния, потому что объект может содержать программу приложения, и его нельзя изменять во время выполнения.

После переключения устройства в состояние Stopped оно принудительно останавливает весь свой обмен (кроме протоколов защиты сети node guarding или heartbeat, в зависимости от того, что из этого активно). Кроме того, это состояние может использоваться для достижения определенного поведения приложения. Определение этого поведения попадает в область действия спецификации профилей устройства.

Содержит информацию о типе устройства. Объект с индексом 1000h описывает тип устройства и его функциональность. Он составлен из 16-битного поля, которое описывает используемый профиль устройства, и второго 16-битного поля, которое дает дополнительную информацию о функциональности устройства. Параметр Additional Information (дополнительная информация) зависит от профиля устройства. Её спецификация не попадает в рамки рассмотрения этого документа, она определена в стандарте соответствующего профиля устройства. Значение 0000h показывает, что устройство не следует стандартизированному профилю устройства. Для устройств с несколькими модулями (multiple device modules) параметр Additional Information содержит FFFFh, и номер профиля устройства, на который ссылается объект 1000h, это профиль устройства для первого из устройств в OD. Все другие устройства для многомодульных устройств идентифицируют свои профили в объектах 67FFh + x * 800h, где x = внутреннему номеру устройства (0 – 7). Эти элементы описывают тип устройства предшествующего устройства.

MSB                                                                                           LSB

Рис. 52. Структура параметра Device Type.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Этот объект является регистром ошибки для устройства. В этом байте устройство может отобразить внутренние ошибки. Этот элемент OD обязателен для всех устройств. Он является частью объекта аварии (Emergency object).

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Таблица 48. Структура Error Register (M = Mandatory, O = Optional).

Если установлен в лог. 1 определенный бит, то произошла соответствующая ошибка. Есть только один обязательный вид ошибки - общая ошибка (generic error), о ней можно сигнализировать в любой ошибочной ситуации.

Этот объект является общим регистром состояния, используемый для целей производителя устройства. В этом документе определены только размер и место расположения этого объекта.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Этот объект содержит ошибки, которые случились с устройством, и о которых сигнализирует объект аварии (Emergency Object). При этом обеспечивается история ошибок.

1. Элемент по индексу 0 содержит количество реальных ошибок, которые записаны в массиве, начиная с sub-индекса 1.

2. Каждая новая ошибка сохраняется по sub-индексу 1, и более старые смещаются вниз по списку.

3. Запись 0 в sub-индекс 0 удаляет всю историю ошибок (очищает массив). Нельзя записывать значения больше 0. Это должно привести к сообщению аварийного завершения (abort message, error code: 0609 0030h).

4. Номера ошибки имеют тип UNSIGNED32 (см. таблицу Таблица 7-18), и они составлены из 16-битного кода ошибки и 16-битного информационного поля, специфичного для производителя. Код ошибки содержится в младших 2 байтах (LSB), и дополнительная информация заключена в старших 2 байтах (MSB). Если этот объект поддерживается, то он должен состоять как минимум из 2 элементов: элемент длины по sub-индексу 0h и как минимум один элемент ошибки по sub-индексу 1h.

MSB                                                                                           LSB

Рис. 53. Структура предопределенного поля ошибки.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Индекс 1005h определяет COB-ID объекта синхронизации (Synchronisation Object, SYNC). Кроме того, он определяет, генерирует ли устройство сообщения SYNC. Структура этого объекта показана на рис. 54 и в таблице 49.

                              MSB                                                                                   LSB

Рис. 54. Структура элемента SYNC COB-ID.

Таблица 49. Описание элемента SYNC COB-ID.

Биты 29, 30 могут быть статическими (не изменяемыми). Если устройство не может генерировать сообщения SYNC, то в ответ на попытку установить бит 30 будет выдан ответ сообщением abort (abort code: 0609 0030h). Устройства, поддерживающие только стандартный фрейм CAN, либо игнорируют попытки изменить бит 29, или отвечают сообщением abort message (abort code: 0609 0030h). Первая передача объекта SYNC начинается с 1 цикла синхронизации после установки бита 30 в 1. Не разрешено менять биты 0-29, в то время как объекты существуют (бит 30=1).

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Этот объект определяет период цикла коммуникации в микросекундах. Этот период определяет интервал SYNC. Он равен 0, если не используется. Если период цикла коммуникации был изменен на новое значение, не равное 0, то передача объекта синхронизации возобновится в пределах 1 цикла синхронизации с новым значением.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Содержит длину окна времени для синхронных PDO в микросекундах. Равен 0, если не используется.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Содержит имя производителя устройства.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Содержит описание версии аппаратуры производителя.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Содержит описание версии программного обеспечения производителя.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Объекты с индексами 100Ch и 100Dh включают в себя защитное время (guard time) в миллисекундах, и множитель времени жизни (life time factor). Множитель времени жизни, умноженный на защитное время, дает время жизни (life time) для протокола Life Guarding. Этот параметр равен 0, если не используется.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Множитель времени жизни (Life Time Factor), умноженный на защитное время (Guard Time, см. объект 100Ch), дает время жизни (life time) для протокола Life Guarding. Этот параметр равен 0, если не используется.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Этот объект поддерживает сохранение параметров в энергонезависимой памяти. Путем доступа на чтение устройство предоставляет информацию по его возможностям сохранения. Разделяют несколько групп параметров:

Sub-индекс 0 содержит самый большой поддерживаемый sub-индекс.
Sub-индекс 1 относится ко всем параметрам, которые можно сохранить в устройстве.
Sub-индекс 2 относится к параметрам, которые связаны с обменом данными (диапазон индексов 1000h - 1FFFh параметров коммуникации, специфических для производителя).
Sub-индекс 3 относится к параметрам, связанным с приложением (индексы 6000h - 9FFFh параметров, специфичных для приложения производителя).
По sub-индексам 4 - 127 производители могут сохранять свой собственный индивидуальный выбор параметров.
Sub-индексы 128 - 254 зарезервированы для будущего использования.

Чтобы избежать ошибки распознания параметров хранения, сохранение запускается только тогда, когда специальная сигнатура записана по соответствующему sub-индексу. Такой сигнатурой является слово "save".

                             MSB                 LSB

Рис. 55. Сигнатура доступа на запись хранилища.

При приеме корректной сигнатуры в соответствующем sub-индексе устройство сохраняет параметр и подтверждает передачу SDO (инициирует ответ на загрузку). Если сохранение было неудачным, то устройство ответит сообщением Abort SDO Transfer (код abort: 0606 0000h).

Если записана ошибочная сигнатура, то устройство отклонит сохранение и ответит Abort SDO Transfer (код abort: 0800 002xh).

При доступе на чтение по соответствующему sub-индексу устройство предоставит информацию о своем функционале хранилища в следующем формате:

          MSB                                        LSB

Рис. 56. Сигнатура доступа на чтение хранилища.

Таблица 50. Структура доступа на чтение.

Автономное сохранение означает, что устройство запишет сохраняемые параметры энергонезависимым способом без запроса пользователя.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

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

Sub-индекс 0 содержит самый большой поддерживаемый sub-индекс.
Sub-индекс 1 относится ко всем параметрам, которые можно восстановить.
Sub-индекс 2 относится к параметрам, которые связаны с обменом данными (диапазон индексов 1000h - 1FFFh параметров коммуникации, специфических для производителя).
Sub-индекс 3 относится к параметрам, связанным с приложением (индексы 6000h - 9FFFh параметров, специфичных для приложения производителя).
По sub-индексам 4 - 127 производители могут восстанавливать свой собственный индивидуальный выбор параметров.
Sub-индексы 128 - 254 зарезервированы для будущего использования.

Чтобы избежать ошибки восстановления параметров по умолчанию, восстановление выполняется только когда специфическая сигнатура записывается по соответствующему индексу. Этой сигнатурой является слово "load".

                             MSB                  LSB

Рис. 57. Записываемая сигнатура восстановления параметров.

При приеме корректной сигнатуры в соответствующем sub-индексе устройство восстановит свои параметры по умолчанию и подтвердит передачу SDO (инициирует ответ на загрузку). Если восстановление прошло неудачно, устройство ответит Abort SDO Transfer (код abort: 0606 0000h). Если записана ошибочная сигнатура, устройство отклонит восстановление параметров по умолчанию и ответит Abort SDO Transfer (код abort: 0800 002xh).

Значения по умолчанию станут достоверными после сброса устройства(сброс узла для sub-индексов 1h – 7Fh, сброс коммуникации для sub-индекса 2h), или после выключения и последующего включения питания.

Рис. 58. Процедура восстановления.

При доступе на чтение по соответствующему sub-индексу устройство предоставит информацию по своей возможности восстановления параметров в следующем формате:

           MSB                                LSB

Рис. 59. Структура доступа на чтение восстановления значений по умолчанию.

Таблица 51. Структура доступа на чтение восстановления.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Индекс 1012h определяет COB-ID объекта метки времени (Time-Stamp Object, TIME). Кроме того, это определяет, является ли устройство потребителем TIME, или оно генерирует TIME. Структура этого объекта показана на рис. 60 и в таблице 52.

                              MSB                                                                                    LSB

Рис. 60. Структура элемента TIME COB-ID.

Таблица 52. Описание элемента TIME COB-ID.

Биты 29, 30 могут быть статическими (не изменяемыми). Если устройство не может генерировать сообщения TIME, то попытка установить бит 30 вызовет в ответ сообщение abort (код abort: 0609 0030h). Устройства, поддерживающие только стандартный тип фрейма CAN, в ответ на попытку установить бит 29 отвечают сообщением abort message (abort code: 0609 0030h). Не разрешено менять биты 0-29, хотя объект существует (бит 30=1).

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Этот объект содержит метку времени с разрешающей способностью 1 мкс (см. 9.3.2). Она может быть отображена на PDO, чтобы определить сообщение метки времени высокого разрешение (обратите внимание, тип данных стандартного сообщения метки времени TIME фиксирован). Для метки времени высокой точности должно быть специальное применение.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Индекс 1014h задает COB-ID Emergency Object (EMCY, объект аварии). Структура этого объекта показана на рис. 61.

                              MSB                                                                                    LSB

Рис. 61. Структура элемента идентификатора EMCY.

Таблица 53. Description of EMCY COB-ID entry.

Устройства, поддерживающие только стандартный тип фрейма CAN, при попытке установить бит 29 ответят сообщением abort (abort code: 0609 0030h). Если объект EMCY существует (когда бит 31==0), не разрешается менять биты 0-29.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

С помощью этого элемента можно настроить время запрета/подавления (inhibit time) для сообщения EMCY. Если этот элемент существует в OD, то он должен быть записываемым. Время задается в единицах 100 мкс.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Этот параметр определяет ожидаемое время цикла сердцебиения для потребителя (Heartbeat Time), поэтому оно должно быть больше, чем соответствующее время сердцебиения продюсера, который генерирует этот heartbeat. Мониторинг запускается после приема первого heartbeat. Если consumer heartbeat == 0, то соответствующий элемент не используется. Время должно быть числом, кратным 1 мс.

                              MSB                                                                     LSB

Рис. 62. Структура элемента Consumer Heartbeat Time.

При попытке сконфигурировать несколько времен consumer heartbeat, не равных 0 для одного и того же Node-ID, устройство оборвет загрузку SDO с выдачей abort code 0604 0043h.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Этот параметр определяет время цикла сердцебиения. Heartbeat time равно 0, если это не используется. Время должно быть указано значением, кратным 1 мс.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Объект с индексом 1018h содержит общую информацию об устройстве. Vendor ID (sub-индекс 1h) содержит уникальное значение, выделенное каждому производителю. Код продукта Product code (sub-индекс 2h), зависящий от производителя, идентифицирует определенную версию устройства. Номер ревизии Revision number (sub-индекс 3h), зависящий от производителя, состоит из major-номера ревизии и minor-номера ревизии. Номер major идентифицирует определенное поведение в CANopen. Если функциональность CANopen расширена, то major revision инкрементируется. Номер minor revision идентифицирует разные версии с одинаковым поведением CANopen.

MSB                                                                                                                                         LSB

Рис. 63. Структура Revision number.

Серийный номер Serial number (sub-индекс 4h), зависящий от производителя, идентифицирует определенное устройство.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Чтобы описать используемые в устройстве объекты SDO, введен тип данных параметра SDO. Этот тип данных имеет индекс 22h в OD. Его структура описана в 9.5.4.

Примечание переводчика: обычно сервер SDO присутствует в подчиненных узлах CANopen (slave), чтобы можно было читать/записывать любые элементы OD. Таким образом, чаще всего сервер SDO используется в slave-устройствах для их конфигурирования, однако иногда SDO применяют для передачи прикладных данных или перепрошивки firmware устройства. В этой спецификации указано, что наличие сервера на подчиненном устройстве является обязательным, однако мне попадались устройства, у которых не было вообще поддержки сервера SDO. Логически это выглядит допустимым для простейших устройств CANopen, которые не позволяют менять свою конфигурацию и читать её. В таком случае для мастера сети CANopen должно быть предоставлено полное описание этого подчиненного устройства в виде соответствующего файла *.eds. Если выкинуть объекты SDO, то код устройства CANopen можно кардинально упростить.

Количество поддерживаемых элементов в записи объекта SDO указано по sub-индексу 0h. Значения по sub-индексам 1h и 2h задают COB-ID для этого SDO. Sub-индекс 3h предоставляет сервер SDO в случае, если запись описывает SDO для которого это устройство клиент, и дает клиенту SDO, если запись описывает SDO, для которого это устройство сервер.

                              MSB                                                                                    LSB

Рис. 64: Структура элемента SDO COB-ID.

Таблица 54. Описание SDO COB-ID.

SDO допустим, только если оба бита SDO-valid равны 0. Устройства, поддерживающие только стандартный тип фрейма, при попытке установить бит 29 ответят сообщением abort message (abort code: 0609 0030h). Эти объекты содержат параметры для объектов SDO, для которых это устройство является сервером. Если устройство поддерживает больше одного сервера SDO, то объект SDO по умолчанию должен находиться по индексу 1200h как первый сервер SDO. Этот элемент имеет доступ только для чтения². Все дополнительные объекты сервера SDO по умолчанию недопустимы (invalid bit - см. таблицу 54), описание находится в последующих индексах. Не разрешено менять COB-ID, когда SDO существует.

Описание клиента SDO (sub-индекс 3h) является необязательным. Это не доступно для SDO по умолчанию (нет sub-индекса 3h по индексу 1200h), поскольку этот элемент только для чтения.

Примечание 2: должно гарантироваться, что идентификаторы COB-ID для SDO не могут быть изменены записью в OD.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Эти объекты содержат параметры для объектов SDO, для которых это устройство является клиентом. Если этот элемент поддерживается, то должны быть в наличии и все sub-индексы. Элементы начинаются с индекса 1280h. Эти элементы описаны в описании Server SDO Parameter. Все объекты клиента SDO по умолчанию недопустимы (invalid bit – см. таблицу 54).

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Здесь содержаться коммуникационные параметры для объектов PDO, которые устройство может принимать. Тип коммуникационного параметра PDO (PDO communication parameter, 20h) описан в 9.5.4. Sub-индекс 0h содержит количество достоверных элементов в записи коммуникации. Это значение равно как минимум 2. Если поддерживается время запрета (inhibit time), то значение будет 3. По sub-индексу 1h размещается COB-ID для PDO. Этот элемент должен быть определен как UNSIGNED32, чтобы обслужить как 11-битные идентификаторы CAN (CAN 2.0A), так и 29-битные идентификаторы CAN (CAN 2.0B). Элемент должен быть интерпретирован, как определено на рис. 65 и в таблице 55.

                              MSB                                                                                 LSB

Рис. 65. Структура элемента PDO COB-ID.

Таблица 55. Описание записи PDO COB-ID.

Бит PDO valid/not valid (допустим/не допустим) позволяет выбрать, какие PDOs используются в рабочем состоянии (operational). Могут быть объекты PDO, полностью сконфигурированные (например по умолчанию), но не используемые, и тогда они устанавливаются в состояние "not valid" (удалены). Эта функция нужна для устройств, которые поддерживают больше чем 4 RPDO или 4 TPDO, потому что каждое устройство имеет только идентификаторы по умолчанию для первых четырех RPDO/TPDO. Устройства, поддерживающие только стандартный тип фрейма CAN, или которые не поддерживают фреймы Remote, при попытке установить бит 29 в 1 или бит 30 в 0 отвечает сообщением abort (abort code: 0609 0030h).

Не разрешено менять биты 0-29, в то время как PDO существует (бит 31=0). Тип передачи (sub-индекс 2) определяет характер передачи/приема PDO (см. 9.2.1.1). Таблица 56 описывает использование этой записи. При попытке поменять значение типа передачи на значение, которое не поддерживается устройством, будет сгенерировано сообщение abort (abort code: 0609 0030h).

Таблица 56. Описание типа передачи.

Синхронный тип (Synchronous, типы передач 0-240 и 252) означает, что передача PDO должна быть связана с объектом SYNC, как это описано в 9.3. Преимущественно устройства используют SYNC как триггер для вывода или активации на базе предыдущего синхронного RPDO, соответственно для обновления данных, передаваемых при следующем синхронном TPDO. Подробности этого механизма зависят от типа устройства, что определено в профиле устройства, если это применимо.

Асинхронный тип (Asynchronous) означает, что передача PDO не связана с объектом SYNC. Тип передачи 0 означает, что сообщение должно передаваться синхронно с объектом SYNC, но не периодически.

Значение между 1 и 240 означает, что PDO передается синхронно и циклически. Тип передачи показывает количество появлений SYNC, которое нужно для срабатывания передач PDO. RPDO всегда срабатывают по следующему SYNC при приема данных, независимо от типов передачи 0 - 240.

Типы передачи 252 и 253 означают, что PDO передается только в ответ на RTR (remote transmission request, запрос передачи от другого узла сети). При типе передачи 252 данные обновляются (но не отправляются) немедленно после приема объекта SYNC. При типе передачи 253 данные обновляются в момент приема RTR (могут накладываться аппаратные и программные ограничения). Эти значения допустимы только для объектов TPDO. Тип передачи 254 для объектов TPDO означает, что событие приложения зависит от производителя (той части OD, которая зависит от производителя устройства). Тип передачи 255 означает, что событие приложения определено в профиле устройства. Объекты RPDO с таким типом выполняют срабатывание обновления отображенных данных в момент приема. Sub-индекс 3h содержит время запрета inhibit (этот элемент может отсутствовать). Это время задает минимальный интервал между передачами PDO. Значение задается в единицах 100 мкс. Не разрешено менять это значение, когда PDO существует (бит 31 у sub-индекса 1 равен 0).

Sub-индекс 4h зарезервирован. Он не должен быть реализован, в этом случае доступы на чтение или запись приведут к выдаче Abort SDO Transfer (abort code: 0609 0011h).

В режиме 254/255 дополнительно может использоваться время события (event time) для TPDO. Если существует таймер события (event timer) для TPDO (значение не равно 0), то истечение таймера считается событием. Таймер события истекает на интервалах, нацело делящихся на 1 мс, как это определено в элементе по sub-индексуindex 5h для TPDO. Это событие будет приводить к передаче этого TPDO в дополнение к событиям, определенным другим способом. Момент наступления события устанавливает таймер. Независимый от типа передачи таймер события RPDO используется для распознавания истечения RPDO.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Содержит отображение для объектов PDO, которые устройство может принять. Тип параметра отображения PDO (PDO mapping parameter, 21h) описан в 9.5.4. Как обычно, sub-index 0h содержит количество допустимых элементов записи отображения. Это количество также равно количеству переменных приложения, которые должны быть переданы/приняты вместе с соответствующим PDO. The sub-indices from 1h to number of entries contain the information about the mapped application variables. Эти элементы описывают содержимое PDO их индексом, sub-индексом и длиной (рис. 66). Все 3 значения кодируются шестнадцатеричным числом. Элемент длины (length) содержит длину объекта в битах (1..40h). Этот параметр может использоваться для проверку общей длины отображения, он обязателен.

Структура элементов по sub-индексам 1h – 40h следующая:

MSB                                                                                                                       LSB

Рис. 66. Структура элемента PDO Mapping.

Если изменение PDO не может быть выполнено (например длина PDO превышена или клиент SDO попытался отобразить объект, который не может быть отображен), то устройство отвечает службой Abort SDO Transfer.

Sub-индекс 0 определяет допустимое количество объектов, которые имеют отображение. Для изменения отображения PDO сначала PDO должен быть удален, sub-индекс 0 должен быть установлен в 0 (отображение деактивировано). Затем объекты могут быть отображены заново. Когда отображается новый объект путем записи sub-индекса между 1 и 64, устройство может проверить, существует ли объект, указанный по индексу / sub-индексу. Если объект не существует, или объект не может быть отображен, то передача SDO должна быть оборвана службой Abort SDO Transfer с одним из кодов abort 0602 0000h или 0604 0041h.

После того, как все объекты отображены, sub-индекс 0 устанавливается в достоверное число отображенных объектов. В завершении будет создан PDO путем записи его коммуникационного параметра (communication parameter COB-ID). Когда sub-индекс 0 устанавливается в значение >0, устройство может проверить на допустимость новое отображение PDO перед тем, как передать ответ службе SDO. Если была определена ошибка, то устройство должно передать службу Abort SDO Transfer с одним из кодов abort 0602 0000h, 0604 0041h или 0604 0042h.

Когда читается sub-индекс 0, то будет возвращено актуальное количество отображенных объектов.

Если отображены типы данных (индексы 1h-7h), то они служат "фиктивными записями" (dummy entries). Соответствующие данные в PDO не оцениваются в устройстве. Эта опциональная функция полезна например для передачи данных для некоторых устройств, использующих один и тот же PDO, когда на каждом устройстве задействована своя часть от этого PDO. Невозможно создавать dummy mapping для TPDO.

Устройство, которое поддерживает динамическое отображение объектов PDO (dynamic mapping PDO), должно поддерживать это в состоянии PRE-OPERATIONAL. Если поддерживается динамическое отображение во время состояния OPERATIONAL, то клиент SDO отвечает за целостность данных.

Рис. 67. Принцип отображения PDO.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Содержит параметры коммуникации для объектов PDO, которые устройство может передать. Тип коммуникационного параметра PDO (PDO communication parameter, 20h) описан в 9.5.4. Подробное описание элементов сделано в секции для Receive PDO Communication Parameter (1400h – 15FFh).

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Содержит отображение для объектов PDO, которые устройство может передать. Тип параметра отображения PDO (PDO mapping parameter, 21h) описан в 9.5.4. Подробное описание элементов сделано в секции для Receive PDO Mapping Parameter (1600h – 17FFh).

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Если устройство поддерживает сохранение параметров в энергонезависимой памяти, инструментарий конфигурирования сети или CANopen manager могут проверить (verify) конфигурацию после сброса устройств и определить, требуется ли повторное конфигурирование. Утилита конфигурации должна сохранить дату и время в этом объекте, и должна сохранить те же значения в DCF. Теперь утилита конфигурации позволит устройству сохранить свою конфигурацию путем записи по индексу 1010h и sub-индексу 1h сигнатуры "save". После сброса устройство должно восстановить последнюю конфигурацию и сигнатуру - автоматически или по запросу. Если любая другая команда изменит значения конфигурации загрузки (boot-up configuration values), устройство должно сбросить объект Verify Configuration в 0.

Configuration Manager сравнивает сигнатуру и конфигурацию со значением из DCF, и принимает решение - нужно или нет повторно конфигурировать устройство.

ОПИСАНИЕ ОБЪЕКТА

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Значение Configuration date должно содержать количество дней от 1 января 1984 года. Configuration time должно содержать количество миллисекунд после полуночи.

Совет по применению: использование этого объекта позволяет значительно ускорить boot-up process. Если он используется, системный интегратор должен полагать, что пользователь мог поменять значение конфигурации и впоследствии активировать конфигурацию команды сохранения 1010h без изменения значения 1020h. Таким образом, системный интегратор должен гарантировать 100%-е последовательное использование этой функции.