ГОСТ IEC 62026-3-2015. Межгосударственный стандарт. Аппаратура распределения и управления низковольтная. Интерфейсы между контроллерами и приборами (CDI). Часть 3. Система связи DeviceNet

(введен в действие Приказом Росстандарта от 26.01.2024 № 105-ст)

МКС 29.130.20

1 января 2025 года с правом досрочного применения

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 ПОДГОТОВЛЕН Научно-производственным республиканским унитарным предприятием «Белорусский государственный институт стандартизации и сертификации» (БелГИСС) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 5

2 ВНЕСЕН Государственным комитетом по стандартизации Республики Беларусь

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 27 февраля 2015 г. № 75-П)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97	Код страны по МК (ИСО 3166) 004-97	Сокращенное наименование национального органа по стандартизации
Армения	AM	ЗАО «Национальный орган по стандартизации и метрологии» Республики Армения
Беларусь	BY	Госстандарт Республики Беларусь
Казахстан	KZ	Госстандарт Республики Казахстан
Киргизия	KG	Кыргызстандарт
Молдова	MD	Институт стандартизации Молдовы
Россия	RU	Росстандарт
Таджикистан	TJ	Таджикстандарт
Узбекистан	UZ	Узстандарт
Украина	UA	Минэкономразвития Украины

4 Приказом Федерального агентства по техническому регулированию и метрологии от 26 января 2024 г. № 105-ст межгосударственный стандарт ГОСТ IEC 62026-3-2015 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2025 г. с правом досрочного применения.

5 Настоящий стандарт идентичен международному стандарту IEC 62026-3:2008 «Аппаратура распределения и управления низковольтная. Интерфейсы между контроллерами и приборами (CDI). Часть 3. Система связи DeviceNet» («Low-voltage switchgear and controlgear — Controller-device interfaces (CDIs) — Part 3: DeviceNet», IDT).

Международный стандарт разработан Подкомитетом SC 17B Технического комитета по стандартизации IEC/TC 17 «Низковольтная аппаратура распределения и управления» Международной электротехнической комиссии (IEC).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА

6 ВВЕДЕН ВПЕРВЫЕ

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

В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге «Межгосударственные стандарты»

1 Область применения

Настоящий стандарт устанавливает требования к системе интерфейсов между единичными или многочисленными контроллерами и аппаратами цепи управления или коммутирующими элементами (далее — DeviceNet). Система интерфейсов использует две витых экранированных пары проводников в одном кабеле. Одна пара проводников поддерживает дифференциальную среду передачи (данных), а другая обеспечивают поддержку питания. Стандарт также определяет возможность замены компонентов, которые имеют схожие интерфейсы.

Настоящий стандарт определяет следующие специальные требования для системы связи DeviceNet:

• требования к интерфейсам между контроллерами и коммутирующими элементами;
• нормальные условия эксплуатации устройств;
• конструктивные требования и требования к функционированию;
• испытания для подтверждения соответствия требованиям.

Данные требования применяют в дополнение к общим требованиям, установленным в IEC 62026-1.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты [для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных — последнее издание (включая все изменения)]:

IEC 60529:2013 Degrees of protection provided by enclosures (IP Code) — (Степени защиты, обеспечиваемые оболочками (код IP))

IEC 60947-5-2:2012 <1> Low-voltage switchgear and controlgear — Part 5-2: Control circuit devices and switching elements — Proximity switches (Аппаратура распределения и управления низковольтная. Часть 5-2. Аппараты и коммутационные элементы цепей управления. Бесконтактные датчики)

---

<1> Заменен на IEC 60947-5-2:2019. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

IEC 61000-4-2:2008 Electromagnetic compatibility (EMC) — Part 4-2: Testing and measurement techniques — Electrostatic discharge immunity test (Электромагнитная совместимость (EMC). Часть 4-2. Методы испытаний и измерений. Испытание на устойчивость к электростатическому разряду)

IEC 61000-4-3:2010 <1> Electromagnetic compatibility (EMC) — Part 4-3: Testing and measurement techniques — Radiated, radiofrequency, electromagnetic field immunity test (Электромагнитная совместимость (EMC). Часть 4-3. Методы испытаний и измерений. Испытание на устойчивость к излучаемому радиочастотному электромагнитному полю)

---

<1> Заменен на IEC 61000-4-3:2020. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

IEC 61000-4-4:2012 Electromagnetic compatibility (EMC) — Part 4-4: Testing and measurement techniques — Electrical fast transient/burst immunity test (Электромагнитная совместимость (EMC). Часть 4-4. Методы испытаний и измерений. Испытание на устойчивость к электрическим быстрым переходным процессам/пачкам импульсов)

IEC 61000-4-5:2014 Electromagnetic compatibility (EMC) — Part 4-5: Testing and measurement techniques — Surge immunity test (Электромагнитная совместимость (EMC). Часть 4-5. Методы испытаний и измерений. Испытание на устойчивость к импульсам перенапряжения)

IEC 61000-4-6:2013 <2> Electromagnetic compatibility (EMC) — Part 4-6: Testing and measurement techniques — Immunity to conducted disturbances, induced by radio-frequency fields (Электромагнитная совместимость (EMC). Часть 4-6. Методы испытаний и измерений. Устойчивость к кондуктивным помехам, наведенным радиочастотными полями)

---

<2> Заменен на IEC 61000-4-6:2023. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

IEC 61158 (все части), Digital data communications for measurement and control — Fieldbus for use in industrial control systems (Сети связи промышленные. Спецификация полевой шины)

IEC 61158-4-2:2014 <3> Industrial communication networks — Fieldbus specifications — Part 4-2: Data-link layer protocol specification — Type 2 elements (Сети связи промышленные. Спецификация полевой шины. Часть 4-2. Спецификация протокола прикладного уровня. Элементы типа 2)

---

<3> Заменен на IEC 61158-4-2:2023. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

IEC 61158-5-2:2014 <4> Industrial communication networks — Fieldbus specifications — Part 5-2: Application layer service definition — Type 2 elements (Сети связи промышленные. Спецификация полевой шины. Часть 5-2. Описание служб прикладного уровня. Элементы типа 2)

---

<4> Заменен на IEC 61158-5-2:2023. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

IEC 61158-6-2:2014 <5> Industrial communication networks — Fieldbus specifications — Part 6-2: Application layer protocol specification — Type 2 elements (Сети связи промышленные. Спецификация полевой шины. Часть 6-2. Спецификация протокола прикладного уровня. Элементы типа 2)

---

<5> Заменен на IEC 61158-6-2:2023. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

IEC 61508 (все части), Functional safety of electrical/electronic/programmable electronic safety-related systems (Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью)

IEC 61784-3-2:2010 <6> Industrial communication networks — Profiles — Part 3-2: Functional safety field-buses — Additional specifications for CPF 2 (Сети связи промышленные. Профили. Часть 3-2. Полевые шины для обеспечения функциональной безопасности. Дополнительные спецификации для CPF 2)

---

<6> Заменен на IEC 61784-3-2:2021. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

IEC 62026-1:2007 <7> Low-voltage switchgear and controlgear — Controller-device interfaces (CDIs) — Part 1: General rules (Аппаратура распределения и управления низковольтная. Интерфейсы между контроллерами и приборами (CDI). Часть 1. Общие правила)

---

<7> Заменен на IEC 62026-1:2019. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

ISO/IEC 7498-1:1994 Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model (Информационные технологии. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель)

ISO 11898-1:2003 <1> Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signaling (Транспорт дорожный. Локальная сеть контроллеров (CAN). Часть 1. Уровень передачи данных и физическая передача сигналов)

---

<1> Заменен на ISO 11898-1:2015. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

ISO 11898-2-2003 <2> Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit (Транспорт дорожный. Локальная сеть контроллеров (CAN). Часть 2. Высокоскоростной модуль промежуточного доступа)

---

<2> Заменен на ISO 11898-2:2016. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

CISPR 11:2009 <3> Industrial, scientific and medical (ISM) radio-frequency equipment — Electromagnetic disturbance characteristics — Limits and methods of measurement (Оборудование высокочастотное промышленное, научное и медицинское (ISM). Характеристики электромагнитных помех. Нормы и методы измерения)

---

<3> Заменен на CISPR 11:2015. Однако для однозначного соблюдения требования настоящего стандарта, выраженного в датированной ссылке, рекомендуется использовать только указанное в этой ссылке издание.

3 Термины и определения

Для целей настоящего стандарта используются следующие термины, определения, символы и сокращения дополнительно к тем, которые установлены в IEC 62026-1.

3.1 Термины и определения

3.1.1 подтвержденная фрагментация (acknowledged fragmentation): Фрагментация, выполняемая в явном сообщении, в котором передача фрагмента от передающего объекта сопровождается передачей подтверждения принимающим объектом.

Примечание — Прием каждого фрагмента подтверждается принимающим объектом.

3.1.2 статус подтверждения (ack status): Поле в рамках формата сообщения подтверждения/отклика, которое показывает, обнаружил ли ресивер фрагментированного сообщения ошибку или нет.

Примечание — Относится главным образом к протоколу фрагментации DeviceNet.

3.1.3 прикладные объекты (application objects): Совокупность классов и экземпляров объекта, имеющихся в узле.

Примечание — Эти объекты управляют и обеспечивают обмен данными и сообщениями через интерфейсы между устройствами и контролерами DeviceNet (CDIs) и в соответствующем узле DeviceNet.

3.1.4 атрибут (attribute): Внешне доступная характеристика или свойства объекта.

Примечание — Атрибуты обычно предоставляют информацию о статусе или управляют работой объекта.

3.1.5 битстробирование (bit-strobe): Передача данных с использованием стробирования.

3.1.6 пересылка сообщений (broadcast): Передача данных от одного узла к другим.

3.1.7 сеть контроллера (CAN) (Controller Area Network): Спецификация ISO, определяющая общий физический уровень и протокол доступа к каналу передачи данных и основанная на ненарушаемой поразрядной организации доступа (см. ISO 11898-1 и ISO 11898-2).

3.1.8 CAN_H (CAN_H): Положительный вывод дифференциального физического сигнала CAN.

3.1.9 CAN_L (CAN_L): Отрицательный вывод дифференциального физического сигнала CAN.

3.1.10 клиент (client): (1) Объект, который пользуется службами другого (сервера) объекта, для выполнения задачи, см. сервер (3.1.43); (2) инициатор сообщения, на которое реагирует сервер.

3.1.11 общая служба (common service): Служба CIP, используемая объектами DeviceNet (см. IEC 61158-5-2, пункт 6.2.1.3 и IEC 61158-6-2, пункт 4.1.8).

3.1.12 коммуникационные объекты (communication objects): Объекты, которые управляют и обеспечивают обмен сообщениями в DeviceNet в течение периода выполнения.

3.1.13 соединение (connection): Логическое связывание между двумя или более прикладными объектами.

Примечание — Эти прикладные объекты могут быть расположены в одном и том же узле или в различных узлах.

3.1.14 идентификатор соединения (connection ID (CID)): Идентификатор соединения, предназначенный для любой передачи сигнала, которая связана с конкретным соединением между несколькими узлами.

3.1.15 объект соединения (connection object): Управляет аспектами, характерными для передачи данных, при установлении соединений между узлами.

3.1.16 потребитель (consumer): Конечная точка соединения, ответственная за получение данных.

3.1.17 идентификатор MAC-адреса получателя (destination MAC ID): ID MAC узла, который должен получить сообщение.

3.1.18 ответвитель устройства (device tap): Физическая точка отсоединения от устройства DeviceNet на магистральный кабель или кабель заземления.

3.1.19 тип устройства (device type): Идентификация сбора информации применительно к устройству. Информация описывает приемлемое сочетание опций (параметров), выбранных для всех уровней в коммуникационном стеке.

3.1.20 восходящий (dominant): Один из двух дополнительных логических уровней на физическом сигнале.

Примечание — Восходящий уровень — это логический «0».

3.1.21 идентификатор обнаружения дубликата MAC (duplicate MAC ID detection): Протокол, определяемый DeviceNet, который гарантирует отсутствие двух узлов на одном и том же канале связи, принадлежащих одному и тому же идентификатору MAC.

3.1.22 передача явных сообщений (explicit messaging): Каждое явное сообщение управляет выполнением конкретной задачи и возвратом результатов ее выполнения инициатору запроса.

3.1.23 фрагментация (fragmentation): Протокол DeviceNet, обеспечиваемый объектом соединения, который определяет способ, которым могут передаваться данные свыше восьми (8) байтов.

3.1.24 клиент второй группы (group 2 client): Устройство, способное управлять сообщениями без соединения (UCMM), которое получило право монопольного использования набором предопределенных соединений ведущего и ведомого устройств на сервере, благодаря чему может выступать клиентом в этих соединениях.

3.1.25 клиент исключительно второй группы (group 2 only client): Устройство, действующее в качестве клиента второй группы для сервера исключительно второй группы.

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

3.1.26 сервер второй группы (group 2 server): Устройство, способное управлять сообщениями без соединения (UCMM), сконфигурированное действовать в качестве сервера для предопределенных соединений ведущего и ведомого устройств через идентификаторы.

3.1.27 сервер исключительно второй группы (group 2 only server): Ведомое устройство, не поддерживающее UCMM, которое использует предопределенный набор соединений ведущего и ведомого устройств для передачи данных.

Примечание — Устройство исключительно второй группы может передавать и получать только те идентификаторы, которые установлены предопределенным набором соединений ведущего и ведомого устройств.

3.1.28 соединение I/O (ввода/вывода) (I/O connection): Соединение между поставщиком и одним или несколькими потребителями с целью обмена индивидуальными для приложения данными ввода/вывода, ограниченными по времени.

3.1.29 данные I/O (ввода/вывода) (I/O data): Информация, передаваемая между точками ввода/вывода и контроллерами, которые используют и устанавливают величины.

3.1.30 передача входных/выходных сообщений (I/O messaging): Обмен данными в предопределенном формате.

3.1.31 изолированное устройство (isolated device): Устройство, в котором некоторые компоненты не относятся к B-физического уровня, см. неизолированные устройства (3.1.36).

3.1.32 ведущее устройство; «мастер» (master): Узел, который накапливает и распределяет сигналы I/O с помощью предопределенного набора соединений ведущего и ведомого устройств.

3.1.33 идентификатор управления доступом к среде (Medium Access Control (MAC) ID): Адрес связи узла DeviceNet.

3.1.34 многоадресное соединение (multicast connection): Логическое соединение от одного объекта к нескольким другим объектам.

Примечание — Многоадресное соединение позволяет передавать данные в единичной транзакции от поставщика к нескольким потребителям с использованием общего соединения.

3.1.35 узел (node): Объект DeviceNet, который идентифицирован на уровне канала передачи данных с помощью единого MAC ID.

Примечание — В одном устройстве могут использоваться несколько узлов DeviceNet, но на канале DeviceNet они являются логически дискретными узлами.

3.1.36 неизолированное устройство (non-isolated device): Устройство, в котором все компоненты связаны с B-физического уровня, см. изолированное устройство (3.1.31).

3.1.37 объект (object): (1) Абстрактное представление возможностей устройства.

Примечание — Объекты могут включать в себя какие-либо следующие или все без исключения компоненты:

a) данные (информация, которая изменяется со временем);

b) конфигурация (параметры режима работы);

c) процедуры (действия, которые могут осуществляться с помощью данных и конфигурации).

(2) Совокупность соответствующих данных (в виде переменных) и процедур функционирования на основе этих данных.

3.1.38 двухточечная связь (point-to-point connection): Соединение, которое возможно только между двумя объектами.

Примечание — Соединения для передачи явных сообщений всегда являются двухточечными. Соединения I/O могут быть либо двухточечными, либо многоадресными, см. многоадресное соединение (3.1.34).

3.1.39 Предопределенный набор соединений ведущего и ведомого устройств (predefined master/slave connection set): Использование соединения для передачи явных сообщений с целью генерации и конфигурирования объектов соединения в каждой конечной точке соединения.

Примечание — Используют общие правила в качестве основы для определения набора соединений, которые обеспечивают передачу данных, характерных для связи ведущего и ведомого устройств.

3.1.40 поставщик (producer): Конечная точка соединения, которая отвечает за отправку данных.

3.1.41 нисходящий (recessive): Один из двух дополнительных логических уровней физического сигнала.

Примечание — Нисходящим уровнем является логическая «1».

3.1.42 серийный номер (serial number): Уникальное 32-разрядное целое число (номер), присвоенное соответствующим изготовителем каждому устройству DeviceNet.

Примечание — Номер сохраняется в устройстве как атрибут идентификации объекта и является уникальным по отношению к изготовителю.

3.1.43 сервер (server): Объект, предоставляющий службы другому (клиенту) объекту, см. клиент (3.1.10).

3.1.44 служба (service): Операция или функция, которую выполняет объект по запросу другого объекта.

3.1.45 ведомое устройство «слейв» (slave) — Узел, который возвращает данные своему ведущему устройству, используя предопределенный набор соединений ведущего и ведомого устройств и способа передачи, установленного ведущим устройством.

3.1.46 идентификатор MAC источника (source MAC ID): Идентификатор MAC узла, который передает сообщение.

3.1.47 активатор (trigger): Служба, используемая приложением для начала генерации данных.

3.1.48 устройство с функцией UCMM (UCMM capable device): Устройство, которое поддерживает UCMM (см. 3.1.51).

3.1.49 устройство без функции UCMM (UCMM incapable device): Устройство, которое не поддерживает UCMM (см. 3.1.51).

3.1.50 явное сообщение без установления соединения (unconnected explicit message): Явное сообщение между узлами, которые еще не установили соединение между собой.

3.1.51 менеджер сообщений без установления соединения (UCMM) (Unconnected Message Manager (UCMM)): Функция в рамках узла, который получает и обрабатывает явные сообщения без установления соединения.

3.1.52 беззнаковое короткое целое число (Unsigned Short Integer (USINT)): 8-битовое целое число.

3.1.53 беззнаковое целое число (Unsigned Integer (UINT)): 16-битовое целое число.

3.2 Символы и сокращения

CAN — сеть контроллеров

CDI — интерфейс между контроллером и устройством

CID — идентификатор соединения

CIPTM — общий промышленный протокол

CRC — циклический контроль избыточности

DCR — сопротивление постоянному току

EUT — испытуемое оборудование (далее — ИО)

MAC ID — идентификатор уровня доступа к носителям данных

UCMM — менеджер сообщений без установления соединения

4 Классификация

4.1 Общие положения

Устройства контроля в интерфейсах DeviceNet применяют для управления аппаратами цепи управления или коммутирующими элементами (исполнительными устройствами). В DeviceNet используется две витых экранированных пары проводников в одном кабеле. Одна пара проводников поддерживает дифференциальную среду передачи (данных), а другая обеспечивают поддержку питания устройств. Максимальный поддерживаемый ток составляет 8 А при 24 В постоянного тока. Данные передаются со скоростью 125 кбит/с, 250 кбит/с или 500 кбит/с при максимальной длине кабеля 500 м, 250 м и 100 м, соответственно. Максимально передаваемый объем данных без фрагментации составляет 8 байт. А максимальное количество подключаемых узлов (64 узла) может обеспечиваться благодаря линейной топологии, включающей магистральную линию и отводные линии (см. рисунок 1). DeviceNet поддерживает передачу I/O данных, диагностику, передачу сообщений и программирование/конфигурирование. Обмен данными может быть с управлением по событиям (изменение состояния), циклическим, по запросу или многоадресным.

Рисунок 1 — Типовые интерфейсы DeviceNet между контроллерами и устройствами

В настоящем стандарте определена основная схема соединений для обеспечения передачи данных всех приложений. Соединение DeviceNet обеспечивает канал передачи данных между несколькими конечными точками. Конечные точки соединения являются приложениями, которые должны совместно использовать данные. Транзакциям, связанным с конкретным соединением, присваивается идентификационное значение после установления соединения. Это идентификационное значение называется идентификатор соединения (CID).

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

Основная схема соединения DeviceNet определяет динамические средства, посредством которых могут быть установлены два следующих типа соединений:

• Соединения I/O: обеспечивают специальные выделенные каналы передачи данных между генерирующим приложением и одним или несколькими пользовательскими приложениями. Данные I/O, характерные для конкретного приложения, передаются через эти каналы.

Обмен сообщениями I/O происходит через соединения I/O. Сообщение I/O состоит из CID и соответствующих данных I/O. Конечные точки соединения должны содержать информацию о предполагаемом использовании или значении сообщения I/O.

Настоящая часть IEC 62026 не устанавливает какое-либо определенное применение сообщений I/O. Существуют различные функции, которые могут быть выполнены с использованием сообщений I/O. Значение и/или предполагаемое применение всех сообщений I/O должно быть идентифицировано системой либо посредством конкретного типа изделия, передающего сообщения I/O, либо на основе конфигурации, осуществляемой с помощью явных сообщений.

• Соединения для передачи явных сообщений: обеспечивают общие, универсальные каналы передачи данных между двумя устройствами. Явные сообщения предусматривают установление связей, ориентированные на запрос/отклик.

Обмен явными сообщениями происходит через соединения, установленные для передачи явных сообщений. Явные сообщения используются для управления выполнением конкретной задачи и записи результатов выполнения задачи.

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

Руководящие указания, определяющие динамическое установление данных соединений, используются в качестве основы для установления предопределенного набора соединений.

4.2 Модель передачи данных DeviceNet

Абстрактная, объектно-ориентированная модель передачи данных узла DeviceNet включает в себя следующее:

• Менеджер сообщений без установления соединений (UCMM): обрабатывает явные сообщения DeviceNet без установления соединения;
• Идентификация объекта: определяет и предоставляет общую информацию об устройстве;
• Класс соединения: назначает и управляет внутренними ресурсами, связанными как с соединениями I/O, так и с обменом явными сообщениями;
• Объект соединения: управляет характерными особенностями связи, установленными для определенной функциональной взаимосвязи «от приложения к приложению»;
• Объект DeviceNet: поддерживает конфигурацию и состояние физического CDI DeviceNet;
• Маршрутизатор сообщений: адресует явное сообщение-запрос к соответствующему объекту;
• Прикладные объекты: реализуют назначение изделия.

4.3 DeviceNet, CAN и CIP

Низшие уровни DeviceNet используют технологию «Сеть контроллеров (CAN)» и установлены в ISO 11898-1 и ISO 11898-2. Высшие уровни DeviceNet используют сокращенную версию общего промышленного протокола (CIPTM <1>) и служб, определенных в IEC 61158.

---

<1> CIPTM является торговой маркой Открытой Ассоциации поставщиков DeviceNet, Inc. Эта информация предоставляется для удобства пользователей настоящего стандарта и не является рекламой IEC держателя торговой марки или любого из его изделий. Соответствие данному стандарту не требует использования фирменного наименования DeviceNetTM. Для использования фирменного наименования DeviceNetTM требуется разрешение Открытой Ассоциации поставщиков DeviceNet, Inc.

Функциональная взаимосвязь DeviceNet, CAN, CIP и эталонной модели OSI (ISO/IEC 7498-1) показана на рисунке 2.

Рисунок 2 — Архитектура протокола DeviceNet по сравнению с эталонной моделью OSI

5 Характеристики

5.1 Соединения DeviceNet

5.1.1 Общие положения

DeviceNet представляет собой интерфейс между контроллером и устройством на основе соединений. Соединения DeviceNet используются для обеспечения логических путей между несколькими приложениями. Когда соединение установлено, транзакциям, связанным с этим соединением, присваивается идентификатор соединения (CID). Если соединение включает в себя двунаправленный обмен, в этом случае соединению должны быть присвоены два значения CID.

DeviceNet использует поле идентификатора CAN и определяет шаги динамической генерации соединений I/O и соединений для передачи явных сообщений.

5.1.2 Использование в DeviceNet поля идентификатора CAN

Примечание — DeviceNet использует 11-битовое поле идентификатора CAN.

11 битов идентификатора CAN, доступные в DeviceNet, подразделяются на четыре отдельных группы сообщения: группа 1, группа 2, группа 3 и группа 4.

В случае соединения на основе сообщений, CID размещается в поле идентификатора CAN. На рисунке 3 также показаны компоненты CID DeviceNet.

Рисунок 3 — Использование в DeviceNet поля идентификатора CAN

Как показано на рисунке 3, поле идентификатора CAN в DeviceNet содержит следующее:

• ID сообщения: идентифицирует сообщение в группе сообщений внутри конкретного узла. Когда соединение установлено, узлы используют идентификатор сообщения в сочетании с ID MAC для генерирования CID. Полученный CID указывается в поле идентификатора CAN, связанном с соответствующими транзакциями;
• ID MAC источника: группы 1 и 3 требуют спецификации ID MAC источника в поле идентификатора CAN;
• ID MAC: сообщение группы 2 позволяет указать источник или идентификатор получателя в пределах части «ID MAC» поля идентификатора CAN.

Соединения для передачи явных сообщений и I/O могут быть установлены в группах сообщений 1, 2 и 3.

Значения 6 и 7 ID сообщения группы 2 используются следующим образом:

• ID 6 сообщения группы 2 используется для конфигурации используемых каналов передачи данных в приложении «ведущее/ведомое устройство» (см. 5.5);
• ID 7 сообщения группы 2 используется для обнаружения узлов, которым были присвоены идентичные идентификаторы MAC (см. 5.3.6).

Значения 5, 6 и 7 ID сообщения группы 3 используются следующим образом:

• ID 5 сообщения группы 3 используется при отправке откликов, связанных с запросами на передачу явных сообщений без установления соединения, а также сообщений о такте состояний устройства и сообщений об отключении устройства;
• ID 6 сообщения группы 3 используется при отправке запросов на передачу явных сообщений без установления соединения;
• ID 7 сообщения группы 3 является недействительным и не должен использоваться. Группа 4 зарезервирована для использования в дальнейшем.

5.1.3 Установление соединения

5.1.3.1 Соединения для передачи явных сообщений и UCMM

Группа 3 сообщений определяет коды идентификаторов для поддержки передачи явных сообщений. Явные сообщения без соединения устанавливают и управляют передачей явных сообщений. Сообщения-запросы без установления соединения определяются по сообщению группы 3, компонент ID которого устанавливается на 6. Единственными допустимыми службами, которые могут передаваться в качестве явных сообщений-запросов без установления соединения, являются:

• запрос на открытое соединение для передачи явных сообщений;
• запрос на отключение соединения.

Сообщения, указанные выше, никогда не передаются в виде сообщений на основе соединения (см. передачу явных сообщений на основе соединения в 5.2.1.6).

Отклики на явные запросы без установления соединения передаются в виде сообщений-откликов без установления соединения. Сообщения-отклики без установления соединения определяются при передаче сообщения группы 3, компонент ID которого устанавливается на 5. Единственными допустимыми службами, которые могут быть переданы в качестве явных сообщений-откликов без установления соединения, являются следующие:

• отклик: открытое соединение для передачи явных сообщений;
• отклик: отключение соединения;
• отклик об ошибке;
• сообщение о такте состояния устройства;
• сообщение о завершении работы устройства.

5.1.3.2 Соединения I/O

Соединения I/O устанавливаются динамически путем генерации интерфейса с учетом класса соединения через ранее установленное соединение для явных сообщений. Экземпляр соединения должен быть сгенерирован и сконфигурирован на каждом узле.

5.2 Протокол передачи сообщений DeviceNet

5.2.1 Передача явных сообщений

5.2.1.1 Общие положения

В настоящем подразделе описывается протокол передачи явных сообщений и представлена подробная информация, связанная с динамическим установлением соединений для передачи явных сообщений (см. рисунок 4).

Рисунок 4 — Использование поля данных явного сообщения CAN

На рисунке 5 показан формат поля данных CAN, связанный с явными сообщениями:

Рисунок 5 — Формат поля данных явного сообщения

Поле данных транзакции, содержащее полное явное сообщение, включает в себя:

• заголовок сообщения;
• все тело сообщения в полном объеме.

Если явное сообщение по длине больше восьми байтов, то оно должно передаваться фрагментами. Функция фрагментации/восстановления обеспечивается объектом соединения. Часть фрагментированного явного сообщения включает в себя:

• заголовок сообщения;
• протокол фрагментации (см. 5.2.3.2);
• фрагмент основных данных сообщения.

5.2.1.2 Заголовок сообщения

Заголовок сообщения помещается в байтовом нулевом смещении в поле данных CAN явного сообщения и должен быть отформатирован так, как приведено на рисунке 6.

Рисунок 6 — Формат заголовка явного сообщения

Заголовок сообщения содержит:

• frag (бит фрагмента): показывает, является ли эта транзакция частью фрагментированного явного сообщения или нет.

0 = нефрагментированное

1 = фрагментированное

• XID (идентификатор транзакции): это поле используется приложением для верификации соответствия отклика на определенный запрос. Это поле просто повторяется сервером в сообщении-отклике. Модуль сервера не использует это поле для создания логической схемы обнаружения дублирующего сообщения любого типа;
• MAC ID: содержит либо источник, либо идентификатор МАС-адреса получателя.

Когда получено явное сообщение, проверяется поле MAC ID в заголовке сообщения. Если идентификатор MAC-адреса получателя указан в CID, то исходный MAC-идентификатор других конечных точек должен быть указан в заголовке сообщения. Если MAC ID источника указан в CID, то MAC ID принимающего модуля должен быть указан в заголовке сообщения. Если ни одно из этих условий не действительно, то сообщение не должно учитываться.

5.2.1.3 Тело сообщения

Тело сообщения содержит поле и аргументы, характерные для службы.

Первый аргумент, указанный в теле сообщения, является служебным полем, которое идентифицирует конкретный передаваемый запрос или отклик. На рисунке 7 показан формат служебного поля.

Рисунок 7 — Формат поля службы

Контент поля службы:

• код службы: значение, определяемое в пределах наименее значимых 7 битов байта служебного поля, которое указывает тип передаваемой службы;
• R/R: наиболее значимый бит в служебном поле. Его значение определяет, является ли сообщение запросом или откликом.

0 = запрос

1 = отклик

DeviceNet определяет набор общих служб. Общие службы DeviceNet являются открытым множеством, параметры и необходимые действия которого определены в IEC 61158-5-2 (пункт 6.2.1.3) и IEC 61158-6-2 (пункт 4.1.8).

Информация, следующая за служебным полем, характерна для конкретного типа передаваемой службы.

5.2.1.4 Протокол фрагментации

Если транзакция представляет собой часть явного фрагментированного сообщения, то поле данных должно содержать заголовок сообщения, протокол фрагментации и фрагмент тела сообщения. Протокол фрагментации облегчает фрагментацию и восстановление явных сообщений, которые имеют тело сообщения более 8 байт (см. 5.2.3).

5.2.1.5 Службы UCMM

5.2.1.5.1 Общие положения

Менеджер сообщений без установления соединения (UCMM) обеспечивает динамическое установление соединения явных сообщений. В этом подразделе представлено подробное описание аргументов в зависимости от службы, связанных с открытым соединением явных сообщений и службами отключенного соединения, предоставляемыми UCMM. Для получения информации о спецификации испытания, касающегося установления соединений явных сообщений, см. 9.3.3.

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

• открытое соединение для передачи явных сообщений: код службы = 4BHex. Используется в целях установления соединения для передачи явных сообщений;
• отключение соединения: код службы = 4CHex. Используется для удаления объекта соединения и уничтожения всех связанных ресурсов.

Эти службы доступны при использовании явного запроса без установления соединения и полей CAN-идентификатора отклика, показанных на рисунке 3. При обработке явного запроса без установления соединения UCMM, возможно, потребуется возврат индикации ошибки запрашивающему устройству. Таким образом, отклик об ошибке может быть передан с помощью CAN-идентификатора явного отклика без установления соединения.

5.2.1.5.2 Запрос на открытое соединение для передачи явных сообщений

Данная служба запрашивает установление логического соединения между двумя узлами, через которые будут передаваться явные сообщения. Эта служба передается в качестве сообщения-запроса без установления соединения (сообщение группы 3, сообщение ID 6) (см. рисунок 8).

Рисунок 8 — Формат запроса на открытое соединение для передачи явных сообщений

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

• frag (0) transaction ID/MAC ID: см. 5.2.1.2. Идентификатор MAC-адреса получателя всегда указывается в заголовке сообщения, связанном с запросом/откликом на открытое соединение явных сообщений;
• R/R бит (0): показывает, что это — сообщение-запрос;
• код службы (4BHex): определяет данное сообщение в качестве службы открытого соединения явных сообщений;
• резервные биты: эти биты должны игнорироваться ресивером и устанавливаться трансмиттером на ноль;
• формат тела запрашиваемого сообщения: поле, используемое клиентом для запроса формата тела конкретного сообщения для последующих явных сообщений, передаваемых через это соединение. Сервер должен поддерживать, по крайней мере, один из форматов тела сообщения DeviceNet (элементы 0 — 3).

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

• отклонять запрос и возвращать значение поддерживаемого формата в отклике на открытое соединение явного сообщения; возвращенный формат должен быть одним из форматов тела сообщения DeviceNet (элемент 0 — 3);
• принимать этот запрос путем отображения значения этого же формата в отклике открытого соединения на передачу явного сообщения.

Таблица 1

Значения формата тела сообщения

Значение	Разъяснение значения
0	DeviceNet (8/8). Класс ID = целочисленный бит 8, ID экземпляра = целочисленный бит 8
1	DeviceNet (8/16). Класс ID = целочисленный бит 8, ID экземпляра = целочисленный бит 16
2	DeviceNet (16/16). Класс ID = целочисленный бит 16, ID экземпляра = целочисленный бит 16
3	DeviceNet (16/8). Класс ID = целочисленный бит 16, ID экземпляра = целочисленный бит 8
4	Маршрут CIP. Размер адресации является различным и предоставляется в виде пакетированного EPATH по каждому запросу a
5 — FHex	Резервное
Примечание — Сообщения, передаваемые через это соединение, форматированы так, как указано в 5.2.1.6. -------------------------------- a Путь CIP установлен как длина маршрута 8 бит (USINT), за которым следует маршрут (пакетированный EPATH). Информация о EPATH приведена в IEC 61158-6-2 (пункт 4.1.9). Сервер должен поддерживать, как минимум, наиболее эффективную кодировку для любого логического сегмента в EPATH (например, кодировку класса 8 бит для кода класса 0 x 01).

• выбор группы: поле, которое показывает группу сообщения, через которую должен проходить обмен сообщениями, связанными с этим соединением. В таблице 2 указаны следующие значения:

Таблица 2

Значения выбора группы

Значения	Разъяснение значения
0	Сообщение группы 1
1	Сообщения группы 2 a
2	Резервное
3	Сообщения группы 3
4 — FHex	Резервное
5	Резервное
a Идентификатор сообщений группы 2 запрашивает либо спецификацию (описание) источника, либо идентификатор MAC-адреса получателя. В отношении соединений явных сообщений, устанавливаемых через группу 2 сообщений, клиент помещает MAC ID сервера в соединение ID при передаче сообщений через это сообщение. Сервер помещает свой собственный ID MAC в соединение ID при передаче сообщений через это соединение. Этот процесс требует от сервера размещения ID двух отдельных сообщений из своего накопителя этой группы 2.

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

• ID источника сообщения: использование этого поля зависит от элемента в рамках поля выбора группы (см. таблицу 3):

Таблица 3

ID источника сообщения в запросе на открытое соединение для передачи явных сообщений

Выбор группы:	ID источника сообщения:
0 или 3	Устанавливает ID сообщения, который клиент назначил из ID накопителя сообщений своей группы 1 или 3. Клиент должен использовать этот ID сообщения в сочетании со своим собственным MAC ID для генерации указанного ID соединения при передаче сообщения через это соединение a
1	Игнорируется/устанавливается на нулевое значение (0) b
a Клиент размещает это значение в рамках компонента сообщения ID группы 1 или 3. b Соединения явных сообщений, установленные через сообщения группы 2, требуют от сервера размещать IDs сообщения группы 2 и возвращает их в сообщении-отклике открытого соединения явных сообщений. Клиент должен использовать одно из этих ID сообщений для генерации ID соединения, которое он указывает при передаче сообщения через это соединение. Другие должны использоваться сервером для генерации ID соединения, которое он указывает при передаче сообщения через это соединение.

UCMM в сервере проверяет аргументы запроса на открытое соединение явного сообщения. Если они валидные, то UCMM инициирует службу генерации класса соединения для получения экземпляра объекта соединения (см. IEC 61158-5-2, пункт 6.2.3). Полученный в результате объект соединения автоматически конфигурируется, чтобы стать объектом соединения явного сообщения.

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

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

5.2.1.5.3 Отклик об успешном выполнении открытого соединения для передачи явных сообщений

Эта служба используется для отклика на запрос об успешном выполнении открытого соединения для явного сообщения (см. рисунок 9).

Рисунок 9 — Формат отклика на открытое соединение для передачи явных сообщений

Контент отклика на открытое соединение для передачи явных сообщений содержит следующее:

• frag (0) transaction ID/MAC ID: см. 5.2.1.2. Идентификатор MAC-адреса получателя всегда указывается в заголовке сообщения, связанном с запросом/откликом на открытое соединение явных сообщений;
• R/R bit (1): показывает, что это — сообщение-отклик;
• код службы (4BHex): определяет данное сообщение в качестве службы открытого соединения явных сообщений;
• резервные биты: эти биты должны устанавливаться трансмиттером на ноль;
• формат фактического тела сообщения: поле, используемое сервером, для определения формата тела сообщения, связанного с последующим явным сообщением, передаваемым по этому соединению (как показано в таблице 1);
• ID целевого сообщения: использование данного поля зависит от сообщения группы, в которой имеет место соединение (как показано в таблице 4);
• ID источника сообщения: значение ID сообщения, которое назначил сервер. Сервер назначает ID сообщения из накопителя ID сообщений группы 1, 2 или 3, который используется в сочетании с ID MAC (ID источника MAC), чтобы создать ID соединения, которое указывается при передаче сообщения по этому соединению;
• ID экземпляра соединения: сервер создает объект соединения явного сообщения, когда он успешно обработал открытый запрос. В этом поле удерживается значение ID экземпляра соединения (16-битное целочисленное поле), назначенное этому объекту соединения явного сообщения.

Таблица 4

ID целевого сообщения в отклике на соединение для передачи явных сообщений

Выбор группы:	ID целевого сообщения открытого отклика:
0 или 3	Игнорируется и должно устанавливаться на нулевое значение (0)
1	Используется клиентом в сочетании с ID MAC, чтобы создать ID соединения, которое он указывает при передаче через это соединение

5.2.1.5.4 Запрос на отключение соединения

Эта служба используется для завершения соединения (либо ввода/вывода или передачу сообщения) в рамках одного из конечных пунктов. Прием UCMM сообщения с запросом на отключение соединения приводит к вызову службы удаления класса соединения (IEC 61158-5-2, пункт 6.2.3). Сообщение-запрос на отключение соединения передается в виде запроса без непосредственного установления соединения.

Устройство отклика проверяет, существует ли экземпляр указанного соединения. Если экземпляр соединения существует и он может быть удален, то он должен быть удален. Все ресурсы, связанные с экземпляром соединения, выгружаются. В случае если запрос успешно обработан, возвращается отклик на отключение соединения. Если запрос не проведен, должно быть возвращено сообщение об ошибке.

Запрос на отключение соединения содержит следующее (см. рисунок 10):

• frag (0)/transaction ID/MAC ID: см. 5.2.1.2;
• R/R бит (0): показывает, что это — запрашиваемое сообщение;
• код службы (4CHex): определяет, что это — служба отключения соединения;
• ID экземпляра соединения: поле, указывающее на то, что экземпляр соединения должен быть удален. Формат для ID экземпляра соединения в рамках этого сообщения всегда устанавливается в виде целого числа 16 бит.

Рисунок 10 — Формат запроса на отключение соединения

5.2.1.5.5 Отклик на отключение соединения

Данная служба используется для отклика на сообщение-запрос отключенного соединения.

Формат отклика на отключение соединения включает следующее (см. рисунок 11):

• frag (0)/transaction ID/MAC ID: см. 5.2.1.2;
• R/R бит (0): показывает, что это — сообщение-отклик;
• Код службы (4CHex): определяет данное сообщение как службу отключения соединения.

Рисунок 11 — Формат отклика на отключение соединения

5.2.1.5.6 Сообщение об ошибке

В таблице 5 показаны стандартный набор условий сбоя и информация о коде ошибки (как коде ошибки общего характера, так и дополнительном коде ошибки), используемых в соответствующем сообщении-отклике об ошибке. Формат сообщения-отклика об ошибке описан в 5.2.1.6.5.

Таблица 5

Коды/условия сбоя (ошибки) UCMM

Ситуации сбоя	Наименование общей ошибки	Код общей ошибки (hex)	Дополнительный код ошибки (hex)
Код службы не открытый или закрытый	Служба не поддерживается	08	FF
Ошибка ресурса выбора группы	Ресурс недоступен	02	01
Выбор группы вне диапазона	Неверный параметр	20	01
Соединение с сервером отсутствует	Ресурс недоступен	02	02
IDs сообщения сервера отсутствуют	Ресурс недоступен	02	03
ID сообщения источника клиента неверный	Неверный параметр	20	02
ID дубликата сообщения источника клиента	Ресурс недоступен	02	04
Неверный ID экземпляра соединения	Объект не существует	16	FF

Описание условий сбоя:

• служба не открыта или закрыта: служба, получаемая через порт UCMM, является не открытого или закрытого типа, и поэтому не поддерживается UCMM;
• ошибка ресурса выбора группы: аргумент выбора группы указывает на использование группы сообщения, которая не поддерживается устройством;
• выбор группы вне диапазона: поле выбора группы содержит неверное значение;
• отсутствует соединение с сервером: уже было достигнуто максимальное количество соединений, поддерживаемое этим сервером;
• IDs сообщения сервера отсутствуют: сервер назначил все идентификаторы (IDs) сообщения в пределах группы сообщения, запрошенных клиентом;
• ID дубликата сообщения источника клиента: ID первичного сообщения и ID источника MAC, полученный в рамках запроса на открытое соединение явного сообщения, уже используются для соединения явного сообщения группы 1 или группы 3;
• Неверный ID экземпляра соединения: ID экземпляра соединения, полученный с запросом на отключение соединения, не существует.

5.2.1.6 Передача явных сообщений на основе соединения

5.2.1.6.1 Общие положения

Явное сообщение на основе соединения — это сообщение, передаваемое по соединению пересылки явного сообщения.

5.2.1.6.2 Контент явного сообщения по запросу (значения формата поля сообщения 0 — 3)

На рисунке 12 приведен формат сообщения, связанный с запросом явного нефрагментированного сообщения для значений 0 — 3 формата тела сообщения.

Рисунок 12 — Формат явного нефрагментированного сообщения-запроса, значения 0 — 3

Формат явного нефрагментированного сообщения-запроса включает следующее:

• R/R бит (0): показывает, что это — сообщение-запрос;
• Код службы (4CHex): определяет запрашиваемую службу;
• ID класса: определяет класс объекта, в отношении которого направляется этот запрос. ID класса указывается в пределах 8-битного или 16-битного целочисленного поля, основанного на значении формата тела фактического сообщения, выдаваемого в отклике открытого соединения пересылки явного сообщения;
• ID экземпляра: определяет конкретный экземпляр в классе объекта, в отношении которого направляется запрос. ID экземпляра указывается в пределах 8-битного или 16-битного целочисленного поля, основанного на значении формата тела фактического сообщения, выдаваемого в отклике открытого соединения пересылки явного сообщения. DeviceNet использует нулевое значение, чтобы указать, что запрос направляется скорее в отношении самого класса, чем на конкретный экземпляр в пределах этого класса;
• служебные данные: содержат данные конкретного запроса. Форматы общих служб DeviceNet представлены в 61158-6-2 (пункт 4.1.8). Определения служб, характерных для класса и объекта, включают формат данного поля.

5.2.1.6.3 Контент явного сообщения-запроса (значение 4 формата тела сообщения)

На рисунке 13 изображен формат сообщения, связанного с нефрагментированным явным запросом значения 4 формата тела сообщения:

Рисунок 13 — Формат явного нефрагментированного сообщения-запроса, значение 4

Явное нефрагментированное сообщение-запрос содержит следующее:

• frag (0)/transaction ID/MAC ID: см. 5.2.1.2;
• R/R бит (0): показывает, что это — сообщение-запрос;
• код службы (4CHex): определяет запрашиваемую службу;
• длина маршрута: это 8-битовое целое значение (USINT) обеспечивает маршрут сообщения-запроса;
• маршрут: определяет маршрут сообщения-запроса (пакетированный EPATH);
• служебные данные: содержат данные конкретного запроса. Форматы общих служб DeviceNet представлены в 61158-6-2 (пункт 4.1.8). Определения служб, характерных для класса и объекта, включают формат данного поля.

5.2.1.6.4 Явное сообщение-отклик об успешном выполнении

На рисунке 14 приведен формат сообщения, связанного с нефрагментированным откликом об успешном выполнении:

Рисунок 14 — Формат нефрагментированного сообщения-отклика об успешном выполнении

Нефрагментированное сообщение-отклик об успешном выполнении содержит следующее:

• frag (0)/transaction ID/MAC ID: см. 5.2.1.2;
• R/R бит (1): показывает, что это — сообщение-запрос;

5.2.1.6.5 Сообщение-отклик об ошибке

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

На рисунке 15 приведен формат сообщения-отклика об ошибке.

Рисунок 15 — Сообщение-отклик об ошибке

Сообщение-отклик об ошибке содержит следующее:

• frag (0)/transaction ID/MAC ID: см. 5.2.1.2;
• R/R бит (1): показывает, что это — сообщение-отклик;
• код службы (4CHex): определяет данное сообщение как сообщение-отклик об ошибке;
• код ошибки общего характера: идентифицирует обнаруживаемую ошибку. Информация о кодах ошибок общего характера приведена в IEC 61158-5-2 (пункт 6.2.1.3.3) и IEC 61158-2 (пункт 4.1.111);
• дополнительный код: содержит значение, характерное для объекта или для службы, которое далее описывает ситуацию сбоя. Если откликающийся объект не имеет дополнительной информации для определения, то значение FFHex должно размещаться в этом поле.

5.2.2 Передача сообщений I/O

DeviceNet определяет протокол фрагментации для передачи I/O сообщения длиной более восьми байтов. Данная информация протокола является единственной, которая переносится в пределах поля данных I/O сообщения (см. рисунок 16).

Рисунок 16 — Поле данных сообщения I/O

5.2.3 Фрагментация/восстановление данных

5.2.3.1 Общие положения

В настоящем подразделе определяются средства, с помощью которых сообщение, длина которого превышает восемь байтов, фрагментируется и восстанавливается. Функция фрагментации/восстановления обеспечивается объектом соединения DeviceNet.

Логический узел, который активирует фрагментированную передачу, является:

• экземпляром объекта соединения явного сообщения, проверяющим длину каждого передаваемого сообщения. Если сообщение превышает восемь байтов, то следует использовать протокол фрагментации;
• экземпляром объекта I/O соединения проверяет атрибут produced_connection_size объекта соединения (см. 5.3.2). Если атрибут produced_connection_size превышает восемь, то должен использоваться протокол фрагментации.

Определяют два типа фрагментации:

• подтвержденная: выполняется при фрагментировании явного сообщения;
• неподтвержденная: выполняется при фрагментировании I/O сообщения.

5.2.3.2 Протокол фрагментации

Протокол фрагментации размещается в единичном байте в поле данных CAN и форматируется так, как показано на рисунке 17:

Рисунок 17 — Формат протокола фрагментации DeviceNet

Протокол фрагментации содержит:

• тип фрагментации: определяет, является ли это первым фрагментом, одним из промежуточных фрагментов или последним фрагментом (см. таблицу 6).

Таблица 6

Значения бита типа фрагмента

Значение	Разъяснение значения
0	Первый фрагмент. Поле импульса счета фрагментов должно содержать элемент 0 или 3F a
1	Промежуточный фрагмент b
2	Последний фрагмент c
3	Подтверждение фрагмента d
a Если одиночный импульс счета фрагментов содержит нулевое значение (0), то оно является первым в серии фрагментов. Если поле одиночного импульса счета фрагментов содержит элемент 3F, то это также последняя передача в серии. b Данный фрагмент не является ни первым, ни последним фрагментом в серии. c Отмечает это как последний фрагмент. d Элемент, который использует ресивер фрагментируемого сообщения для подтверждения получения фрагмента.

- одиночный импульс счета фрагмента: маркирует каждый отдельный фрагмент так, что ресивер может определять, пропущен ли фрагмент или нет. Если тип фрагмента является первым фрагментом, то тогда это поле принимает специальное значение (как указано в таблице 6). Одиночный импульс счета фрагмента увеличивается на единицу для каждого последующего фрагмента в серии и устанавливается на нуль при выходе за пределы (фрагментация = (fragmentcount+1) mod 64).

Что касается фрагментации I/O сообщения, то информация о протоколе фрагментации размещается в пределах байтового смещения 0 (см. рисунок 18).

Рисунок 18 — Формат фрагмента сообщения I/O

Что касается фрагментации явного сообщения, то информация о протоколе фрагментации размещается в пределах байтового смещения 1 (см. рисунок 19).

Рисунок 19 — Формат фрагмента явного сообщения

Бит фрагментации в заголовке сообщения на рисунке 19 установлен на 1, чтобы показать, что это — часть явного сообщения, а не полное сообщение. Значение 1 здесь также показывает, что следующий байт содержит протокол фрагментации.

Ресивер фрагментированных серий транзакций проводит анализ фрагментированного сообщения, как определено в настоящем подразделе. Процедура применяется как к фрагментации I/O сообщения, так и явного сообщения.

Если первая транзакция ожидается соединением, и тип фрагмента аналогичен первому фрагменту:

- если одиночный импульс счета фрагмента составляет 3FHex, то тогда он является единственной транзакцией в серии, и соединение обрабатывает сообщение и ожидает начала новой серии;

- если одиночный импульс счета фрагмента составляет 0, то тогда он является первым в серии транзакций и соединение запоминает фрагмент и сохраняет одиночный импульс счета фрагмента.

Если первая транзакция ожидается соединением, и либо тип фрагмента не аналогичен первому фрагменту, либо одиночный импульс счета фрагмента не равен 0 или 3FHex, соединение сбрасывает транзакцию и ожидает начала нового сообщения.

Если первая транзакция не ожидается соединением, то соединение проверяет:

- не является ли тип фрагмента первым фрагментом, а также

- одиночный импульс счета фрагмента составляет единицу (1) — больше предыдущего полученного значения.

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

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

Если фрагментируется явное сообщение, то после получения каждого фрагмента ресивер должен генерировать и передавать подтверждение.

Если обнаруживается ошибка, то должно происходить устранение неисправности в зависимости от того, является ли это фрагментированным I/O сообщением или явным сообщением.

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

5.2.3.3 Неподтвержденная фрагментация

Фрагментация I/O сообщения осуществляется неподтвержденным образом. Неподтвержденная фрагментация состоит из каскадной передачи фрагментов от передающего модуля. Принимающий(е) модуль(и) подтверждений не выдает(ют).

Когда активируется служба send_message I/O соединения, то проверяется атрибут connection_size, для определения передается ли фрагментированная серия, или нет. Если атрибут connection_size больше 8 байт, то протокол фрагментации размещается в I/O.

Если атрибут connection_size меньше или равен восьми байтам, то тогда необработанные данные передаются без наличия протокола фрагментации.

Если приложение запрашивает передачу части данных, длина которых больше атрибута connection_size, то обнаруживается внутренняя ошибка и передача не происходит. Если принимающий объект I/O соединения обнаруживает пропущенный фрагмент путем определения того, что импульс счета полученного фрагмента не равен импульсу счета ранее полученного фрагмента плюс единица (1), то тогда осуществляются следующие действия по устранению неисправности:

- все последующие фрагменты в данной серии сбрасываются, а приложению не поступает сигнал о получении I/O сообщения;

- объект соединения приступает к мониторингу начала новой фрагментированной серии транзакций и сбрасывает оставшиеся фрагменты в данной серии.

5.2.3.4 Подтвержденная фрагментация

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

На рисунке 20 приведен формат сообщения подтверждения, передаваемого ресивером после получения каждого фрагмента явного сообщения.

Рисунок 20 — Формат сообщения подтверждения

Сообщение подтверждения содержит следующее:

- тип фрагмента: показывает, что это — подтверждение фрагмента. Значение 3 размещается внутри этого поля;

- одиночный импульс счета фрагмента: повторяет полученное значение последнего одиночного импульса подсчета;

- статус подтверждения: показывает, обнаружил ли ресивер ошибку фрагментированного сообщения, или нет. Значения бита статуса подтверждения показаны в таблице 7.

Таблица 7

Значения бита статуса подтверждения

Значение	Разъяснение значения
0	Успешно. Каких-либо ошибок не обнаружено и фрагментированная передача будет продолжена
1	Слишком много данных. Максимальное количество данных, которое ресивер может получить через это соединение, было превышено
2 — 255	Резервное

Передающий узел функционирует следующим образом:

- объект соединения формулирует заголовок сообщения, устанавливая бит Frag на единицу (1), поле XID (идентификатор транзакции) на значение, определенное приложением, и инициализирует поле MAC ID таким же образом, как и для нефрагментированного явного сообщения. Заголовки сообщений, связанные с каждым отдельным фрагментом, являются идентичными;

- объект соединения далее размещает информацию о соответствующем протоколе фрагментации в сообщении. Объект соединения сохраняет одиночный импульс счета фрагмента, который был вставлен в сообщение;

- объект соединения далее приступает к обработке следующей части тела сообщения и размещает ее в сообщении;

- сообщение передается и начинается ожидание счетчика подтверждения. Период времени ожидания зависит от приложения;

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

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

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

- если заголовок сообщения указывает, что это — фрагментированная часть явного сообщения, тогда объект соединения проверяет протокол фрагментации, чтобы определить его достоверность. Если соединение должно еще получить первую транзакцию из серии (в исходном состоянии) и поле типа фрагмента не аналогично первому фрагменту, тогда фрагмент опускается и никакого подтверждения не выдается;

- если тип фрагмента указывает, что это — первый фрагмент, тогда одиночный импульс счета фрагмента должен быть равен нулю (0). Если данное имеет место, то фрагмент сообщения сохраняется и выдается подтверждение. Если тип фрагмента указывает на первый фрагмент и одиночный импульс счета фрагмента не равен нулю (0), тогда фрагмент удаляется и вызывается подтверждение;

- если одиночный импульс счета фрагмента на единицу (1) превышает ранее полученный импульс счета и тип фрагмента не указывает на то, что это — первый фрагмент, в этом случае был получен следующий фрагмент. Фрагмент добавляется к ранее полученному(ым) фрагменту(ам) и выдается подтверждение. Одиночный импульс счета, связанный с этим фрагментом, сохраняется;

- если одиночный импульс счета фрагмента не превышает на единицу (1), не равен ранее полученному импульсу счета фрагмента, то фрагмент сбрасывается и выдается подтверждение. Ресивер возвращается в исходное состояние;

- когда получен последний фрагмент и выдается подтверждение, объект соединения продолжает обработку сообщения, как если бы он был нефрагментированным.

5.2.4 Установление офлайнового соединения

5.2.4.1 Общие положения

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

a) визуально идентифицировать нарушенный(е) узел(лы), с которым(и) оно устанавливает связь, путем мерцания светодиода;

b) посылать сообщения об устранении неисправности поврежденного узла и по возможности:

c) восстанавливать поврежденный узел без отключения его от подсети.

В любой момент времени только один (1) узел клиента должен быть связан с узлами, подключенными к единичной подсети, при поврежденном состоянии связи. Хостинг узлами связи со сбоями обеспечивается посредством взаимодействия между клиентскими инструментальными средствами через хостинг офлайновыми сообщениями запросов/откликов.

Таблица 8 показывает идентификаторы группы 4, связанные с установлением офлайнового соединения.

Таблица 8

Набор офлайновых соединений

Биты идентификации (ID соединения)											Использование идентификаторов
ID группы					ID сообщения
10	9	8	7	6	5	4	3	2	1	0	Сообщения группы 4
1	1	1	1	1	2C						Сообщение-отклик сбоя связи
1	1	1	1	1	2D						Сообщение-запрос сбоя связи
1	1	1	1	1	2E						Сообщение-отклик офлайнового хостинга
1	1	1	1	1	2F						Сообщение-запрос офлайнового хостинга

Только клиенты, которым необходимо поддержать установление офлайнового соединения, должны генерировать сообщения с использованием ID 2F сообщения группы 4, занимая место сообщения-отклика ID 2E группы 4. После достижения хостинга клиент должен генерировать все сообщения, предназначенные для узлов со сбоем связи, используя ID 2D сообщения 4.

Примечание — Клиент может не создавать «сообщение-запрос о сбое связи» до тех пор, пока не достигнет хостинга «установления соединения в режиме офлайн».

Как только клиентское инструментальное средство осуществит хостинг офлайновым соединением, оно способно передавать «сообщения-запросы о сбое связи» с ID 2D сообщения группы 4 и получать «сообщения-отклики о сбое связи» с ID 2C сообщения группы 4.

Во время состояния сбоя связи узел, подвергшийся сбою, необходим исключительно для использования идентификатора (ID) единичного соединения; ID 2D сообщения группы 4. Узел со сбоем связи должен генерировать свои «сообщения-отклики о сбое связи» на ID 2C сообщение группы 4.

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

5.2.4.2 Офлайновое монопольное использование

На рисунках 21 и 22 приведены шаги, предпринимаемые клиентом (инструментальным средством) для получения права монопольного использования набора офлайновых соединений.

Рисунок 21 — Установление офлайнового монопольного использования

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

Примечание — Лишь одно клиентское инструментальное средство должно иметь право монопольного пользования набора офлайновых соединений в любой момент времени.

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

Ожидающий клиент не должен пытаться послать сообщение-запрос на офлайновое соединение в течение не менее двух секунд после получения сообщения-отклика об офлайновом соединении.

5.2.4.3 Сообщения на офлайновое монопольное использование

5.2.4.3.1 Общие положения

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

5.2.4.3.2 Сообщение-запрос на офлайновое монопольное использование (только клиент)

Для установления офлайнового монопольного использования инструментальное средство клиента должно сгенерировать сообщение-запрос на такое соединение с ID 2F сообщения группы 4, см. рисунок 23.

Рисунок 23 — Сообщение-запрос на офлайновое монопольное использование

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

После того, как клиент становится монопольным пользователем набора офлайновых соединений, и если он получает сообщение-запрос на монопольное пользование в режиме офлайн, то он должен создать сообщение-отклик на запрос о монопольном пользовании в режиме офлайн в течение 1 с.

Если клиент ожидает, чтобы стать монопольным пользователем набора офлайновых соединений, он не должен генерировать сообщение-запрос на монопольное пользование в режиме офлайн с более высокой частотой, чем один раз в течение 2 с. Эта задержка в 2 с будет устранена при получении любого сообщения с запросом на офлайновое монопольное пользование или ID отклика соединения.

5.2.4.3.3 Сообщение-отклик на офлайновое монопольное использование

Формат сообщения-отклика на офлайновое монопольное использование является таким же, как и формат сообщения-запроса на офлайновое монопольное использование, за исключением того, что оно создается при ID 2E сообщения группы 4, см. рисунок 24, и бит R/R устанавливается на (1).

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

5.2.4.4 Сообщения о сбое связи

5.2.4.4.1 Общие положения

Все узлы в состоянии сбоя связи, которые поддерживают механизм восстановления нарушенной связи, должны получать сообщение-запрос о сбое связи, создаваемое при ID 2D сообщения группы 4. Если требуется, узлы нарушенной связи должны создавать сообщение-отклик о нарушенной связи при ID 2C сообщения группы 4.

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

5.2.4.4.2 Протоколы сообщения о сбое связи

Для поддержки протоколов сообщения о сбое связи узел должен поддерживать возможность светодиодной индикации «Состояние сети» или «Состояние комбинации модуля/сети», или использовать в зависимости от устройства подходящий способ внешней индикации состояния сети и модуля (такой, как экран дисплея или текстовое считывание данных). Он также должен иметь настраиваемый MAC ID сети.

Протокол всех сообщений-запросов о сбое связи бывает двух видов: протокол многоадресной передачи (см. рисунок 25) и протокол двухточечной связи (см. рисунок 26).

Рисунок 25 — Сообщение-запрос о сбое связи — протокол многоадресной передачи

Протокол многоадресной передачи используется клиентом для генерации запросов всех узлов нарушенной связи, чтобы запросить их серийный(е) номер(а) и ID(s) изготовителя. Если такая информация клиенту известна, то можно использовать двухточечный протокол.

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

Протокол многоадресной передачи совпадения

IF разряд совпадения установлен (1);

Значение AND равно своему MAC ID;

AND длина сообщения составляет два (2) байта;

THEN прием и обработка сообщения-запроса о сбое связи.

Протокол многоадресной передачи маски

THEN прием и обработка сообщения-запроса о сбое связи.

Протокол многоадресной передачи маски (логический AND) используется для диалогов, в которых семейство идентификаторов MAC запрашивается для отклика. В таблице 9 приведены большинство (но не все) из 64 возможных значений маски.

Таблица 9

Подтверждение (создание отчета) адресов на основании маски

5	4	3	2	1	0	Узлы в состоянии отказа с
1	1	1	1	1	1	MAC ID < 64
0	1	1	1	1	1	MAC ID < 32
0	0	1	1	1	1	MAC ID < 16
0	0	0	1	1	1	MAC ID < 8
0	0	0	0	1	1	MAC ID < 4
0	0	0	0	0	1	MAC ID < 2

Протокол многоадресной передачи маски используется для уменьшения количества сообщений, которые должны отсылаться на подсеть для определения, содержатся ли ID MAC в узле нарушенной связи, и какие.

Двухточечный протокол:

Рисунок 26 — Сообщение-запрос о сбое связи - двухточечный протокол

Когда узел нарушенной связи получает двухточечное сообщение-запрос о сбое связи, он должен выполнить следующие проверки для установления, должно ли сообщение быть принято и обработано.

Двухточечный протокол совпадения

IF длина сообщения составляет восемь (8) байтов;

Совпадает ли серийный номер AND и ID изготовителя с его собственными;

THEN прием и обработка сообщения-запроса о сбое связи.

Для сообщений-запросов о сбое связи в настоящее время определены следующие службы:

Идентификация сообщения-запроса о сбое связи — протокол многоадресной передачи:

Используется, когда клиент пытается идентифицировать присутствие каких-либо узлов нарушенной связи, которые поддерживают службу установления офлайнового соединения в подсети.

Идентификация сообщения-запроса о сбое связи — двухточечный протокол:

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

Who-сообщения-запроса о сбое связи:

Используется, когда клиент обнаружил узел(лы) нарушенной связи в подсети и есть необходимость узнать их серийный номер и ID изготовителя.

Change MAC ID сообщения-запроса о сбое связи:

Используется, когда клиент обнаружил конкретный узел нарушенной связи и есть необходимость изменить свой адрес MAC ID, и предпринимаются действия к переходу в режим онлайн на конкретном MAC ID.

Устройство, которое реализует протоколы сообщения о сбое связи, должно осуществлять поддержку всех четырех вышеуказанных протоколов сообщения о сбое связи.

5.2.4.5 Идентификация сообщений о сбое связи

5.2.4.5.1 Общие положения

Клиент может потребовать идентификацию сообщения-отклика о сбое связи от:

1) ВСЕХ узлов нарушенной связи; или

2) узлов нарушенной связи на одном или нескольких соответствующих MAC IDs; или

3) узла нарушенной связи с конкретным ID изготовителя и серийным номером.

5.2.4.5.2 Сообщение-запрос об идентификации сбоя связи — протокол многоадресной передачи

Сообщение-запрос об идентификации сбоя связи (протокол многоадресной передачи) должно генерироваться на ID 2D сообщения группы 4, см. рисунок 27. Клиент генерирует это сообщение тогда, когда он предпринимает попытку идентифицировать наличие каких-либо узлов в состоянии сбоя связи.

Рисунок 27 — Сообщение-запрос об идентификации сбоя связи — протокол многоадресной передачи

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

5.2.4.5.3 Сообщение-отклик об идентификации — протокол многоадресной передачи

Формат сообщения-отклика об идентификации сбоя связи является таким же, как и формат принятого сообщения-запроса об идентификации сбоя связи (с такой же информацией о совпадении и параметрах, как и информация в принятом запросе), за исключением того, что оно создано на ID 2C сообщения группы 4, см. рисунок 28 и бит R/R, установленный на (1). Сообщение-отклик должно инициироваться в пределах 100 мс после получения сообщения-запроса.

Рисунок 28 — Сообщение-отклик об идентификации сбоя связи

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

5.2.4.5.4 Сообщение-запрос об идентификации — двухточечный протокол

Сообщение-запрос об идентификации сбоя связи (двухточечный протокол) должно генерироваться с ID 2D сообщением группы 4, см. рисунок 29. Если клиент (инструментальное средство) обнаруживает узел(лы) со сбоем связи в подсети, а пользователь желает визуально идентифицировать узел нарушенной связи на конкретном ID VAC, то клиент (инструментальное средство) должен генерировать сообщение-запрос об идентификации сбоя в сети — двухточечный протокол.

Рисунок 29 — Сообщение-запрос об идентификации сбоя связи — двухточечный протокол

Клиент должен всегда устанавливать «совпадение» (match) на 0 и «значение» (value) на 3F. Сервер может игнорировать контент байта 0 (проверяя ID изготовителя, и серийный номер, которых достаточно для определения уникальности элементов).

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

1. Должен мерцать двухцветный светодиодный индикатор состояния сети или состояния комбинации модуль/сеть. Частота мерцания должна чередоваться с красным в течение 250 мс (в состоянии «включено»), затем с зеленым в течение 250 мс (в состоянии «выключено»). Если устройство не имеет двухцветного светодиодного индикатора состояния сети или состояния комбинации модуль/сеть, то оно должно оснащаться соответствующей внешне видимой индикацией (например, экран дисплея) для отображения того, что сообщение идентификации было принято.

2. Генерировать сообщение-отклик идентификации сбоя связи в течение 100 мс. Если узел принял сообщение-запрос идентификации сбоя связи (двухточечный протокол) и (AND) его светодиодный индикатор мерцает, он должен остановить мерцание этого светодиодного индикатора при следующих обстоятельствах. Аналогично, если устройство не оснащено двухцветным светодиодным индикатором состояния сети или состояния комбинации модуль/сеть и включена индикация конкретного устройства, используемая для показания того, что сообщение идентификации было принято, тогда данная индикация должна быть отключена при этих условиях:

1. Другое сообщение-запрос идентификации сбоя связи (двухточечный протокол) не принимается в течение 500 мс.

2. Другое сообщение-запрос идентификации сбоя связи (двухточечный протокол) получено, но не принято (и другой серийный номер или ID изготовителя).

Если узел использует светодиодный индикатор состояния сети или состояния комбинации модуль/сеть для индикации сообщения идентификации, тогда после прекращения мерцания светодиодного индикатора узел должен его отключить, как минимум, в течение 500 мс, но не более чем 1 с, прежде чем вернуться к обычному режиму работы.

5.2.4.5.5 Сообщение-отклик об идентификации — двухточечный протокол

Сообщение-отклик об идентификации сбоя сети (двухточечный протокол) является таким же, как и сообщение-отклик об идентификации сбоя в сети — сообщение-отклик протокола многоадресной передачи.

5.2.4.5.6 Сообщение-запрос о сбое связи

Сообщение-запрос о сбое связи должно генерироваться на ID 2D сообщения группы 4, см. рисунок 30. Сообщение-запрос о сбое связи используется для запроса серийного номера и ID изготовителя узла нарушенной связи.

Рисунок 30 — Сообщение-запрос о сбое связи

IF принимающий узел:

1. находится в состоянии сбоя связи; и

2. обнаруживает сообщение-запрос о сбое связи; и

3. отвечает критериям совпадения и значения.

THEN узел нарушенной связи:

1. должен ожидать в течение периода времени, зависящего от байтового смещения времени задержки;

2. генерировать единичное сообщение-отклик Who (Кто) на ID 2C сообщения группы 4 и

3. оставаться в состоянии сбоя связи.

Клиент должен использовать сообщение-отклик дубликата MAC ID, генерируемое на ID 2C сообщения группы 4, запрашивая тем самым серийный номер и ID изготовителя узла нарушенной связи.

Точность периода ожидания должна зависеть от разрешения внутреннего таймера в узле нарушенной связи.

Интервал ожидания нарушенного узла до отклика определяют следующим образом:

1. получают значение при байтовом смещении задержки времени в рамках сообщения-запроса о сбое связи who (0 — 6 действительные значения);

2. используют это значение как временной интервал (смещение) в сообщении-отклике who, приведенном на рисунке 31, затем

3. умножают значение байта при данном смещении на время 50 мс и

4. задерживают отклик на данный период времени.

Рисунок 31 — Сообщение-отклик

5.2.4.5.7 Сообщение-отклик

Сообщение-отклик, производящее далее соответствующую задержку, является тем же самым протоколом, что и сообщение-запрос дубликата MAC ID, за исключением того, что оно генерируется на ID 2C сообщения группы 4, см. рисунок 31.

5.2.4.5.8 Сообщение-запрос о сбое связи с изменением MAC ID

Целью этого сообщения является модификация MAC ID узла в состоянии сбоя связи. Это сообщение должно генерироваться с использованием ID 2D сообщения группы 4, см. рисунок 32.

Рисунок 32 — Сообщение-запрос о сбое связи с изменением MAC ID

Узлы, поддерживающие службу сообщения-запроса о сбое связи с изменением MAC ID, не должны приводить к сообщению-отклику о сбое в сети.

1. в состоянии сбоя в сети; AND

2. обнаруживает сообщение-запрос о сбое в сети с изменением MAC ID; AND

3. подтверждает, что серийный номер и ID изготовителя совпадает с его собственными.

THEN нарушенный узел:

1. изменяет свой MAC ID на новый MAC ID; AND

2. вводит состояние отсылаемого MAC ID.

Если с новым MAC ID узел не выполняет проверку дубликата MAC ID, узел должен запомнить новый MAC ID и повторно ввести состояние сбоя.

Узел в состоянии сбоя игнорирует контент нулевого байта (0), биты 6 и 7. Генерация значения, отличного от нуля в этом месте, является ошибкой клиента, указывающей несоответствие.

5.2.5 Тактовый импульс устройства

5.2.5.1 Общие положения

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

Сообщение тактового импульса устройства является произвольным.

5.2.5.2 Сообщение тактового импульса

Данное сообщение показывает текущее состояние устройства. Это сообщение передается устройством с функцией UCMM в качестве сообщения-отклика без соединения (сообщение группы 3, ID 5 сообщения) и сервером только группы 2 в качестве сообщения-отклика без соединения (сообщение группы 2, ID 3 сообщения). Формат сообщения такта состояния приведен на рисунке 33.

Рисунок 33 — Сообщение тактового импульса устройства

5.2.5.3 Контент блока данных, сообщение тактового импульса

Frag (0)/ID/MAC ID — сообщение тактового импульса является незапрашиваемым многоадресным сообщением; идентификатор MAC-адреса получателя отсутствует. Источник MAC ID указывается в заголовке сообщения. Данное является исключением из общего правила, что заголовок сообщения не должен содержать такой же MAC ID, как и поле идентификации CAN.

R/R бит (1) — показывает, что это — сообщение-отклик.

Код службы (4DHex) — показывает, что это — сообщение тактового импульса устройства.

Именование ID экземпляра объекта — именование ID экземпляра объекта, генерирующее сообщение тактового импульса. Длина этого поля должна быть 2 байта.

Состояние устройства — Атрибут 8 соответствующего именования экземпляра объекта. Если атрибут 8 не поддерживается, состояние устройства должно быть 3 (функционирующего устройства).

EV — флаг события, должно быть применено использование. Этот бит игнорируется ресивером и должен быть установлен трансмиттером на ноль.

SF — ошибка системы — ошибка в устройстве, вызванная интеракцией шины (например, время ожидания подключения). Данный флаг устанавливается при наличии отказа системы.

UF — ошибка пользователя — ошибка в устройстве, вызванная интеракцией пользователя. Данный флаг устанавливается при наличии ошибки пользователя. Условия, при которых он устанавливается, зависят от изготовителя.

DF — ошибка устройства — внутренняя ошибка в устройстве, не вызванная интеракцией пользователя или шины (например, аппаратная ошибка). Данный флаг устанавливается при наличии ошибки устройства.

Резервные биты — должно быть применено использование. Этот бит игнорируется ресивером и должен быть установлен трансмиттером на ноль.

Значение целостности конфигурации — атрибут 9 соответствующего именования экземпляра объекта. Если атрибут 9 не поддерживается, то значение целостности конфигурации должно быть нулевым.

5.2.6 Сообщение об отключении устройства

5.2.6.1 Общие положения

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

Сообщение об отключении устройства является необязательным.

5.2.6.2 Сообщение об отключении устройства

Данное сообщение показывает переход устройства в офлайновое или несуществующее состояние. Это сообщение передается устройством с функцией UCMM в качестве сообщения-отклика без соединения (группы 3 сообщения, ID 5 сообщения) и только сервером группы 2 в качестве сообщения-отклика без соединения (группы 2 сообщения, ID 3 сообщения). Формат сообщения об отключении устройства приведен на рисунке 34.

Рисунок 34 — Сообщение об отключении устройства

5.2.6.3 Содержание блока данных, сообщение об отключении устройства

Frag (0)/Transmission ID/MAC ID — сообщение об отключении является незапрашиваемым многоадресным сообщением; идентификатор MAC-адреса получателя отсутствует. Источник MAC ID указывается в заголовке сообщения. Это является исключением из общего правила, что заголовок сообщения не должен содержать такой же MAC ID, как и поле идентификации CAN.

R/R бит (1) — показывает, что это — сообщение-отклик.

Код службы (4DHex) — показывает, что это — сообщение об отключении устройства.

ID класса/ID экземпляра — данные два значения идентифицируют класс объекта/экземпляра, отвечающего за переход устройства в состояние офлайн. Если отключение не вызвано специальным классом, то ID класса должно быть 0. Эти поля должны быть длиной 2 байта каждое.

Код отключения — Это значение, показывающее причину перехода устройства в состояние офлайн, отображено в таблицах 10 и 11.

Таблица 10

Диапазоны кода сообщения об отключении устройства

Значение	Разъяснение значения
0Hex — 1FFHex	Открытый
200Hex — 2FFHex	В зависимости от конкретного поставщика
300Hex — 4FFHex	Конкретный класс объекта
500Hex — FFFFHex	Зарезервирован устройством DeviceNet для будущего использования

Таблица 11

Коды «открытого» сообщения об отключении устройства

Значение	Разъяснение значения
0	Резервное
1	Отключением оператором
2	Сброс оператором
3	Дистанционное отключение
4	Дистанционный сброс
5	Внутренняя диагностическая ошибка
6	Ошибка назначения ресурса
7Hex — 1FFHex	Резервное

5.2.7 Протокол обнаружения дубликата MAC ID

Каждому узлу DeviceNet должен быть присвоен ID MAC и запрашиваться для организации алгоритма обнаружения дубликата ID MAC, как определено в 5.4.

Значение ID специального сообщения определяется в пределах группы 2, чтобы выявить сообщение дубликат для проверки MAC ID (см. рисунок 35).

Рисунок 35 — Поле идентификатора CAN для проверки дубликата MAC ID

Поле данных, связанное с сообщением проверки дубликата MAC ID, имеет формат, как это приведено на рисунке 36.

Рисунок 36 — Формат поля данных сообщения о проверке дубликата MAC ID

Содержание поля данных сообщения проверки дубликата MAC ID:

R/R бит: Бит запроса и отклика. Значение в данном поле показывает, является ли это запросом проверки дубликата MAC ID или ответным сообщением.

0 = Запрос

1 = Отклик

- количество физических портов: Элемент идентификации, внутренне присущий каждому физическому порту устройства DeviceNet. Устройства, которые имеют один порт, должны указывать значение 0 (ноль) в пределах данного поля.

- ID изготовителя: 16-битовое целочисленное поле (UINT), содержащее идентификационный код, присвоенный изготовителю устройства, которое передает сообщение.

- серийный номер: См. 3.1.42.

5.2.8 Быстрое соединение

Свойство быстрого соединения — опция, запускаемая посредством метода «от узла к узлу». После запуска устройство переходит в состояние онлайн, параллельно отсылая первое сообщение-запрос дубликата MAC ID. Устройству по-прежнему необходимо выполнить STD сети, в том числе вхождение в режим офлайн в любое время, когда получено сообщение-отклик о дубликате MAC ID.

Важно: несмотря на то, что эта опция позволяет устройству активизировать сетевой обмен, это ведет к задержке в алгоритме обнаружения дубликата узла. Гарантирование того, что узлов с одинаковым MAC ID нет, и что не более чем одно клиентское устройство настроено на доступ к тому же самому устройству путем предопределенного набора соединений ведущего и ведомого устройств, остается прерогативой пользователя. Ошибки в шине могут возникать, если присутствует одно из этих условий.

Эта опция доступна в устройстве через энергонезависимый атрибут в объекте DeviceNet. Данная опция в устройстве должна быть отключена (атрибут установлен на «0») при заводской настройке по умолчанию.

5.3 Класс коммуникационного объекта DeviceNet

5.3.1 Общие положения

Система связи DeviceNet в узле моделируется как набор объектов: коммуникационные объекты DeviceNet управляют и обеспечивают обмен сообщениями.

Объект обеспечивает абстрактное представление структуры данных в узле. Класс объекта — это набор объектов, представляющих один и тот же тип объекта. Экземпляр объекта — это фактическое представление конкретного объекта в пределах класса. Каждый экземпляр класса имеет один и тот же набор атрибутов, но имеет свой собственный набор значений атрибутов.

Экземпляр объекта и/или класс объекта имеют атрибуты, поддерживают службы и реализуют режим работы.

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

Основные коммуникационные объекты, используемые DeviceNet, перечислены в подразделах (см. 5.3.2 - 5.3.6).

Коды класса объекта и их наименования установлены в IEC 61158-6-2 (пункт 4.1.10.2.1). Спецификация типа данных и кодировка определены в IEC 61158-5-2 (раздел 5) и IEC 61158-6-2 (пункт 4.2 и раздел 5).

5.3.2 Определение именования класса объекта (Код ID класса: 01Hex)

Именование объекта определяет и предоставляет общую информацию об узле.

Именование объекта в полной мере представлено в IEC 61158-5-2 (пункт 6.2.1.2.2) и IEC 61158-6-2 (пункт 4.1.8.2).

5.3.3 Определение класса объекта маршрутизатора сообщения (Код ID класса: 02Hex)

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

Объект маршрутизатора сообщения полностью описан в IEC 61158-5-2 (пункт 6.2.1.2.4) и IEC 61158-6-2 (пункт 4.1.8.3).

5.3.4 Определение класса объекта DeviceNet (Код ID класса: 03Hex)

Объект DeviceNet обеспечивает конфигурирование и состояние аппаратного интерфейса DeviceNet (порт DeviceNet). Устройство должно поддерживать один объект DeviceNet в каждой физической линии связи.

Объект DeviceNet описан в IEC 61158-4-2 (пункт 7.7). Он включает в себя атрибуты и общие службы для класса и экземпляров объекта DeviceNet.

Службы, характерные для класса объекта DeviceNet, которые используются для назначения и выгрузки предопределенного набора соединений ведущего и ведомого устройств, определены в 5.5.3.

5.3.5 Определение класса объекта соединения (Код ID класса: 05Hex)

5.3.5.1 Общие положения

Класс соединения определяет размещение и управляет внутренними ресурсами, связанными с I/O соединением и явными сообщениями. Конкретный экземпляр, созданный классом соединения, рассматривается как экземпляр соединения или объект соединения.

Класс соединения в полной мере представлен в IEC 61158-5-2, IEC 61158-6-2 и IEC 61784-3-2. Он включает:

- атрибуты и службы для класса и экземпляров объекта соединения (см. IEC 61158-5-2, пункт 6.2.3 и IEC 61158-6-2, пункт 4.1.8.8);

- специальные службы для функциональной безопасности (см. IEC 61784-3-2);

- время соединения (см. IEC 61158-5-2, пункт 6.2.3);

- режим работы экземпляров соединения (см. IEC 61158-6-2, подраздел 7.2).

5.3.5.2 Динамическое управление идентификаторами сообщений

Динамически устанавливаемые соединения I/O сообщений и явных сообщений требуют, чтобы все конечные точки выполняли внутренние процедуры назначения ID. Эти процедуры должны также помечать ранее назначенный ID сообщения как доступный, в случае если данный ID больше не используется.

Для снижения вероятности ошибок CID необходимо соблюдать следующие правила:

a) процесс назначения CID должен нести гарантию того, что ни один из двух узлов устройства DeviceNet не имеет конфигураций, позволяющих передавать идентичную битовую комбинацию в пределах поля идентификатора соединения;

b) процесс высвобождения CID должен нести гарантию того, что для всех конечных точек соединения истекло время ожидания до повторного использования ID:

- если ID сообщения связан с соединением, которое активирует неактивный/контрольный таймер, то тогда активируется новый неактивный/контрольный таймер. По истечении действия этого таймера идентификатор сообщения помечается как доступный;

- если ID сообщения связан с соединением, которое не активирует неактивный/контрольный таймер, то тогда ID сообщения может незамедлительно помечаться как доступный (предполагается, что это имеет место при установлении соединения).

Важно! Для соединения, использующего класс транспортировки 0, или соединения, атрибут expected_packet_rate которого был установлен на 0 (ноль), правило b) не может быть выполнено на основании одного данного объекта соединения. Для данных типов соединений задачи, которые в результате приведут к высвобождению и возможному повторному использованию идентификаторов соответствующего сообщения, должны выполняться с предосторожностью (т.е. генерирование конфигурации атрибута watchdog_timeout_action для автоматического удаления, удаления вручную объекта соединения через вызов службы удаления).

Пример 1 — Если в конечной точке сервера транспортного соединения класса 0 включен режим неактивный/контрольный таймаут, то сервер не может знать состояние клиента, основываясь только на этом соединении. Клиент может пропустить своевременную передачу сообщения и по-прежнему думать, что связь работает нормально.

Пример 2 — Если по какой-то причине была удалена конечная точка клиента соединения, атрибут expected_packet_rate которого был установлен на ноль (0), то конечная(ые) точка(и) сервера может быть по-прежнему активной.

5.3.6 Определение класса объекта устройства для подтверждения обработки запросов

Объект устройства обработки запросов управляет получением подтверждения сообщений.

Объект устройства для подтверждения обработки запросов полностью описан в IEC 61158-5-2 (пункт 6.2.1) и IEC 61158-6-2 (пункт 4.1.8.5).

5.4 Машина состояния доступа к соединению

5.4.1 Общие положения

В настоящем подразделе установлены требования к машине состояния доступа к соединению, которую каждый узел DeviceNet должен выполнять. Машина состояния доступа к соединению описывается следующим образом:

- задачи, которые должны быть выполнены, до отправки сообщения через CDI;

- линия передачи информации о событиях, которая влияет на способность узла передавать сообщение через CDI.

5.4.2 Схема передачи состояния и матрица событий

На рисунке 37 приведен общий вид машины состояния доступа к соединению.

Рисунок 37 — Схема передачи состояния доступа к каналу связи

В таблице 12 представлена подробная матрица состояния и события для машины состояния доступа к соединению.

Таблица 12

Матрица событий состояния доступа к каналу связи

Событие	Состояние
	Отсылка сообщения-запроса о проверке дубликата ID MAC	Ожидание сообщения о проверке дубликата ID MAC	Онлайн	Сбой связи
Успешная передача сообщения-запроса о проверке дубликата ID MAC	Активируйте таймер a в течение 1 с. Если произойдет быстрое соединение, перейдите в режим онлайн, иначе перейдете в режим ожидания сообщения о проверке дубликата ID MAC	Не применяется	Не применяется	Не применяется
Выявлено отключение шины	Трансивер удерживается в режиме сброса. Переход к состоянию сбоя связи	Трансивер удерживается в режиме сброса. Переход к состоянию сбоя связи	Доступ к BOI-атрибуту объекта DeviceNet Если BOI-атрибут показывает, что трансивер будет удерживаться в режиме возврата в исходное положение, тогда перейдите к режиму сбоя связи Если BOI-атрибут показывает, что MAC и трансивер автоматически перейдут в состояние возврата в исходное положение, тогда: 1. Возвратитесь в исходное положение; 2. Запросите передачу сообщения-запроса о проверке дубликата ID MAC и 3. Перейдите к отсылке состояния запроса о проверке дубликата ID MAC	Не применяется
Сообщение-отклик о проверке дубликата ID MAC получено	Дубликат ID MAC обнаружен Переход к состоянию сбоя связи	Дубликат ID MAC обнаружен Переход к состоянию сбоя связи	Дубликат ID MAC обнаружен Переход к состоянию сбоя связи	Выгрузите сообщение
Время таймера 1 с сообщения о проверке дубликата ID MAC истекло	Не применяется	Если это первое истечение времени ожидания, то запросите передачу сообщения запроса о проверке дубликата ID MAC снова и перейдите к отсылке запроса о проверке дубликата ID MAC. Если это второе последовательное истечение времени ожидания, то перейдите в режим онлайн	Если включается быстрое соединение, то снова запросите передачу сообщения-запроса о проверке дубликата ID MAC	Не применяется
Запрос на передачу внутреннего сообщения	Возврат внутренней ошибки	Верните внутреннюю ошибку	Передайте сообщение	Верните внутреннюю ошибку
Сообщение, отличное от запроса/отклика дубликата о проверке ID MAC	Сброс сообщения	Выгрузите сообщение	Обработайте полученное сообщение должным образом	Выгрузите сообщение
Сообщение-запрос о сбое связи получено	Выгрузите сообщение	Выгрузите сообщение	Выгрузите сообщение	Обработайте полученное сообщение должным образом
a Допустимый диапазон таймера: 0,9 — 1,5 с.

Машина состояния локализации сбоя CAN предусматривает возможность, чтобы во время запуска/таймерного включения системы, был бы только один узел в соединении. Если этот узел передает сообщение, он должен определять ошибку подтверждения приема и автоматически повторять сообщение. В данной ситуации узел перейдет к пассивной ошибке, но не к отключению шины. По этой причине единственным событием, которое означает неуспешную передачу сообщения о проверке дубликата ID MAC (запрос или отклик), является событие отключения шины. Если получено обозначение пассивной ошибки или ошибки предупреждения, во время передачи сообщения о проверке дубликата ID MAC, то его следует игнорировать, т.к. это не влияет на машину состояния проверки дубликата ID MAC.

5.4.3 Обнаружение дубликата ID MAC

Основным шагом, предусмотренным в машине состояния доступа к соединению, является выполнение алгоритма обнаружения дубликата ID MAC. Каждому узлу в DeviceNet присвоен уникальный ID MAC и в целях защиты от ошибок все узлы DeviceNet должны участвовать в алгоритме обнаружения дубликата ID MAC.

Примечание — Протокол, связанный с алгоритмом обнаружения дубликата ID MAC, описан в 5.2.7.

В соответствии с 5.2.7 для реализации обнаружения дубликата ID MAC определяется специальное сообщение группы 2.

Узел DeviceNet должен получать и обрабатывать любое сообщение о проверке дубликата ID MAC, которое содержит свой ID MAC в поле идентификации сообщения группы 2.

После передачи сообщения-запроса о проверке дубликата ID MAC модуль должен подождать 1 с до истечения времени и выполнения соответствующего действия, определяемого машиной состояния доступа к соединению.

Сообщение-запрос о проверке дубликата ID MAC должно передаваться дважды без получения соответствующего запроса о проверке дубликата ID MAC или сообщения-отклика перед переходом к режиму онлайн.

Спецификации тестов, касающиеся особенностей подачи питания и обработки механизмов дубликата, см. 9.2.3 и 9.3.2.

5.5 Предопределенный набор соединений ведущего и ведомого устройств

5.5.1 Общие положения

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

• сервер второй группы: устройство, способное управлять сообщениями без установления соединения (UCMM), которое было конфигурировано, чтобы функционировать в качестве сервера для предопределенного набора соединений ведущего и ведомого устройств;
• клиент второй группы: устройство с функцией UCMM, которое получило право монопольного использования предопределенного набора соединений ведущего и ведомого устройств в сервере, благодаря чему он может действовать в качестве клиента в этих соединениях;
• устройство с функцией UCMM: устройство, поддерживающее UCMM;
• устройство без функции UCMM: устройство, не поддерживающее UCMM;
• сервер исключительно второй группы: ведомое устройство, которое не поддерживает UCMM и использует предопределенный набор соединений ведущего и ведомого устройств для установления связей. Устройство исключительно второй группы может передавать и получать только те идентификаторы, которые установлены предопределенным набором соединений ведущего и ведомого устройств;
• клиент исключительно второй группы: устройство, которое действует как клиент только второй группы в отношении сервера исключительно второй группы. Клиент исключительно второй группы поддерживает функционирование UCMM для серверов исключительно второй группы, для которых он предназначен;
• ведущее устройство DeviceNet: относится к типу приложения, называемому «ведущее/ведомое устройство». Ведущее устройство DeviceNet — это устройство, которое собирает и распределяет данные I/O для контроллера процесса. Ведущее устройство сканирует свои ведомые устройства на основании списка сканирования, который в нем содержится. По отношению к сети, ведущее устройство является клиентом группы 2 или клиентом исключительно второй группы;
• ведомое устройство DeviceNet: относится к типу приложения, называемому «ведущее/ведомое устройство». Ведомое устройство возвращает данные I/O к ведущему устройству после его сканирования. По отношению к сети ведомое устройство является клиентом второй группы или сервером исключительно второй группы;
• предопределенный набор соединений ведущего и ведомого устройств: набор соединений, которые способствуют удобству передачи данных, обычно реализуемые во взаимосвязи ведущего и ведомого устройств. Многие из шагов, задействованных в генерации и конфигурировании соединения «приложение к приложению», были исключены из определения «предопределенный набор соединений ведущего и ведомого устройств». Это, в свою очередь, представляет средство, с помощью которого можно создавать систему связи при использовании меньшего количества ресурсов устройств и сети.

5.5.2 Сообщения предопределенного набора соединений ведущего и ведомого устройств

Поля идентификатора CAN, связанные с предопределенным набором соединений ведущего и ведомого устройств, приведены в таблице 13 вместе с идентификаторами, которые должны использоваться со всем соединением на основании передачи сообщений, используемых в предопределенном наборе соединений ведущего и ведомого устройств.

Биты идентификации											Использование	Диапазон
10	9	8	7	6	5	4	3	2	1	0
0	ID сообщения группы 1				ID источника MAC						Сообщения группы 1
0	1	1	0	1	ID источника MAC						I/O сообщение об изменении состояния или цикличное сообщение ведомого устройства
0	1	1	1	0	ID источника MAC						Битстробовое I/O сообщение-отклик ведомого устройства
0	1	1	1	1	ID источника MAC						I/O сообщение-отклик по запросу или сообщение о подтверждении изменения состояния/цикличного сообщения ведомого устройства
1	0	ID MAC						ID сообщение группы 2			Сообщения группы 2
1	0	ID источника MAC						0	0	0	I/O битстробовая команда опроса ведущего устройства
1	0	ID источника MAC						0	0	1	Резервное
1	0	идентификатор MAC-адреса получателя						0	1	0	Сообщение о состоянии ведущего устройства или цикличное сообщение подтверждения
1	0	ID источника MAC						0	1	1	Явное сообщение-отклик ведомого устройства
1	0	идентификатор MAC-адреса получателя						1	0	0	Явное сообщение-отклик ведущего устройства
1	0	идентификатор MAC-адреса получателя						1	1	0	I/O сообщение-отклик по запросу или сообщение подтверждения изменения состояния/цикличного сообщения ведущего устройства
1	0	идентификатор MAC-адреса получателя						1	1	1	Явные сообщения-запросы без соединения исключительно второй группы
1	0	идентификатор MAC-адреса получателя						1	1	1	Сообщения проверки дубликата ID MAC

Следующие типы сообщений включены в таблицу 13:

• сообщения битстробовой команды/отклика I/O: битстробовая команда является сообщением I/O, которое передается ведущим устройством. Сразу несколько ведомых устройств могут получать и реагировать на ту же самую битстробовую команду. Битстробовый отклик — это сообщение I/O, которое ведомое устройство передает обратно ведущему устройству после получения битстробовой команды;
• команды опроса/сообщения-отклика I/O по запросу: команда по запросу представляет собой сообщение I/O, которое передается ведущим устройством. Команда по запросу направляется определенному ведомому устройству. Отклик по запросу представляет собой сообщение I/O, которое ведомое устройство передает обратно ведущему устройству после получения команды по запросу;
• изменение сообщений I/O о состоянии/циклических сообщений I/O: изменение сообщения состояния/циклического сообщения передается либо ведущим, либо ведомым устройством. Изменение сообщения о состоянии/циклического сообщения направляется на определенный узел. Сообщение о подтверждении должно вернуться в качестве отклика на данное сообщение, если конфигурация не включает в себя блокировку сообщений о подтверждении;
• явные сообщения-запросы/сообщения-отклики: см. 5.2.1.6;
• явные сообщения-запросы без соединения исключительно второй группы: порт явного запроса исключительно второй группы без соединения используется для назначения/выгрузки предопределенного набора соединений ведущего и ведомого устройств;
• явные сообщения-отклики без соединения исключительно второй группы: порт явного отклика только второй группы без соединения используется для отклика на явные сообщения запроса без соединения и для передачи сообщений о тактовом импульсе устройства/отключении устройства. Эти сообщения передаются с использованием одного и того же идентификатора (ID сообщения группы 2 = 3) в качестве сообщений-откликов;
• сообщение проверки дубликата ID MAC: см. 5.2.7.

5.5.3 Специальные службы класса объекта DeviceNet для набора соединений ведущего и ведомого устройств

5.5.3.1 ALLOCATE_MASTER/SLAVE_CONNECTION_SET (Код службы: 4BHex)

5.5.3.1.1 Общие положения

Данная служба назначает предопределенный набор соединений ведущего и ведомого устройств. Общие коды ошибок определены в IEC 61158-5-2 (пункт 6.2.1.3.3) и IEC 61158-6-2 (пункт 4.1.11). Значения дополнительных кодов специфических ошибок объекта DeviceNet определены в 5.5.3.5. Эта служба должна передаваться посредством либо установления соединения явного сообщения-запроса в наборе соединений ведущего и ведомого устройств (см. 5.5.2), либо соединения для передачи явных сообщений.

• создает объект соединения;
• конфигурирует объект соединения.

В 9.3.4 и 9.3.5 приведены технические требования к испытаниям, касающимся назначения соединений ведущего и ведомого устройств для передачи явных сообщений, так и I/O сообщений.

5.5.3.1.2 Служба запроса параметров поля данных

В таблице 14 приведены параметры службы данных поля запроса allocate_master/slave_connection_set.

Таблица 14

Служба запроса параметров поля данных allocate_master/slave_connection_set

Наименование	Тип данных	Описание параметра
Выбор назначения	BYTE	Показывает, какие соединения из предопределенного набора соединений ведущего и ведомого устройств должны быть назначены/конфигурированы для использования ведущим устройством
ID MAC устройства назначения	USINT	Содержит ID MAC, связанный с узлом, который запрашивает назначение

Параметр назначения определяется внутри одного байта (см. рисунок 38). Каждый бит обозначает явное сообщение и/или соединение(я) I/O из предопределенного набора соединений ведущего и ведомого устройств, которое должно быть назначено, или в случае блокировки подтверждения — команду. Если бит установлен на 1, тогда создается запрос на назначение соответствующего соединения. Если бит установлен на 0, тогда инициатор запроса не желает назначать соответствующее соединение.

Рисунок 38 — Назначение контента байта

Биты 3 и 7 должны быть установлены на 0, и ведомое устройство должно подтвердить это требование при получении запроса allocate_master/slave_connection_set.

На рисунке 39 показан формат этого явного сообщения.

Рисунок 39 — Сообщение-запрос allocate_master/slave_connection_set

Контент сообщения-запроса allocate_master/slave_connection_set:

• код службы (4BHex): идентифицирует это сообщение как службу allocate_master/slave_connection_set;
• ID класса: определяет класс объекта, которому направлен запрос. Когда это сообщение передается через порт передачи явных сообщений-запросов без установления соединения набора соединений ведущего и ведомого устройств (см. 5.5.2), значение ID класса определяется в поле целочисленного бита 8. ID класса должен быть установлен на 3;
• ID экземпляра: определяет конкретный экземпляр класса объекта, которому направлен этот запрос. Когда это сообщение передается через порт передачи явных сообщений-запросов набора соединений ведущего и ведомого устройств (см. 5.5.2), значение ID экземпляра определяется в поле целочисленного бита 8. ID класса должен быть установлен на 1;
• выбор назначения: определяется байтом, идущим за полем ID экземпляра;
• ID MAC устройства назначения: определяется байтом, идущим за полем выбора назначения.

5.5.3.1.3 Служба отклика параметров поля данных об успешном выполнении

Информация, содержащаяся в поле данных службы отклика об успешном выполнении allocate_master/slave_connection_set, представлена в таблице 15.

Таблица 15

Параметры сообщения-отклика allocate_master/slave_connection_set

Наименование	Тип данных	Описание параметра
Формат тела сообщения	Определен ниже	Данное является семантически эквивалентным параметру формата поля фактического сообщения, возвращенному с сообщением-откликом открытого соединения явного сообщения (как указано в 5.2.1.6). Этот аргумент важен, когда отклик allocate_master/slave_connection_set был получен через порт несвязанного явного сообщения-запроса набора соединений ведущего и ведомого устройств (см. 5.5.2). Он определяет формат тела сообщения, связанного с последующими сообщениями, передаваемыми через соединение явного сообщения в пределах предопределенного набора соединений ведущего и ведомого устройств. Если запрос allocate_master/slave_connection_set был получен через соединение явного сообщения в рамках устройства с функцией UCMM, то тогда этот параметр устанавливают на формат тела фактического сообщения с этим соединением явного сообщения

На рисунке 40 представлен формат отклика об успешном выполнении запроса allocate_master/slave_connection_set.

Рисунок 40 — Отклик об успешном выполнении запроса allocate_master/slave_connection_set

Контент отклика об успешном выполнении запроса allocate_master/slave_connection_set:

• код службы (4BHex): идентифицирует это сообщение как службу allocate_master/slave_connection_set;
• резервные биты: эти биты не используются ресивером сообщения-отклика и должны быть установлены на 0 трансмиттером сообщения-отклика;

5.5.3.2 Режим работы сервера allocate_master/slave_connection_set

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

b) Если ведомое устройство не поддерживает предопределенный набор соединений ведущего и ведомого устройств, то возвращается сообщение об ошибке. Общий код ошибки в сообщении должен быть установлен на 08, чтобы показать, что служба не поддерживается.

c) Ведомое устройство проверяет параметр ID MAC назначения в рамках запроса следующим образом:

• если предопределенный набор соединений ведущего и ведомого устройств назначен и этот запрос исходит не от текущего ведущего устройства, то тогда ведомое устройство возвращает ошибку. Общий код ошибки в сообщении должен быть установлен на 0CHex с дополнительным кодом ошибки, установленным на конкретное значение объекта 01;
• если предопределенный набор соединений ведущего и ведомого устройств не назначен, то тогда ведомое устройство проверяет параметр выбора назначения, как указано в перечислении d);
• если предопределенный набор соединений ведущего и ведомого устройств назначен, и этот запрос исходит от текущего ведущего устройства, то тогда ведомое устройство проверяет параметр выбора назначения, как указано в перечислении d).

d) Ведомое устройство должно проверять параметр выбора назначения в запросе. Если ведомое устройство не поддерживает одно из соединений, указанных в аргументе выбора назначения, тогда должно быть возвращено сообщение об ошибке. Общий код ошибки в сообщении-отклике должен быть установлен на 02, с дополнительным кодом ошибки, установленным на конкретное значение объекта 02.

Если какое(ие)-либо соединение(я) поддерживается(ются) данным ведомым устройством и было(и) уже назначено(ы) в ведущем устройстве, обозначенные аргументом ID MAC назначения, то ведомое устройство должно возвращать сообщение-отклик об ошибке с кодом ошибки общего характера, установленным на 0BHex, с дополнительным кодом ошибки, установленным на конкретное значение объекта 02. Если запрашиваемое I/O соединение находится в состоянии истечения времени ожидания, то ведомое устройство должно переназначить соединение I/O, установив его в состояние генерации конфигурации.

Если байт выбора назначения не имеет установленных битов, то ведомое устройство должно возвращать сообщение-отклик об ошибке с общим кодом ошибки, установленным на 09, с дополнительным кодом ошибки, установленным на конкретное значение объекта 02.

Если ресурс, требуемый для использования запрашиваемыми соединениями, недоступен, тогда отклик об ошибке должен возвращаться с кодом ошибки общего характера, установленным на 02, а дополнительный код ошибки должен быть установлен на конкретное значение объекта 04.

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

Если ведущее устройство назначило набор соединений для передачи сообщения об изменении состояния/цикличного сообщения, и последующий запрос назначения получен с установленным битом по запросу, должна возвращаться ошибка. Общий код ошибки в отклике должен быть установлен на 02, чтобы показать, что ресурс недоступен. Если байт выбора назначения имеет блокировку подтверждения, то ни бит изменения состояния, ни циклический бит не устанавливаются, и должно возвратиться сообщение-отклик об ошибке. Общий код ошибки должен быть установлен на 09, а дополнительный код ошибки — на 02.

e) Ведомое устройство указывает на тот факт, что предопределенный набор соединений ведущего и ведомого устройств был размещен на ID MAC в пределах поля ID MAC путем обновления атрибута назначения объекта DeviceNet. При необходимости, атрибуты produced_connection_id и/или consumed_connection_id объекта(ов) соединения могут быть теперь активированы.

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

f) Любое(ые) размещенное(ые) I/O сообщение(я) переходит к состоянию генерации конфигурации. С учетом объектов предопределенного набора соединений ведущего и ведомого устройств подразумеваемая служба apply_attributes сопровождает set_attribute_single атрибута expected_packet_rate, когда соединение находится в состоянии генерации конфигурации. А set_attribute_single атрибута expected_packet_rate запускает выполнение действий, совершаемых службой apply_attributes, и побуждает объект предопределенного набора соединений I/O ведущего и ведомого устройств переходить к установленному состоянию. При обнаружении ошибки во время выполнения части apply_attributes атрибут expected_packet_rate должен быть возвращен к своему первоначальному значению, и ошибка должна быть возвращена к коду, установленному на 09, и дополнительному коду ошибки, установленному на ID атрибута объекта нарушенного соединения.

g) Если процесс назначения завершен, транзакции сообщений в явной форме переходят к установленному состоянию. Запускается неактивный/контрольный таймер с использованием исходного значения, указанного в IEC 61158-5-2 (пункт 6.2.3.2.1.7).

Устройства с функцией UCMM, которые поддерживают предопределенный набор соединений ведущего и ведомого устройств, должны поддерживать назначение и использование предопределенного набора соединений ведущего/ведомого устройств явных сообщений.

h) Как предопределенный набор соединений ведущего и ведомого устройств для явных сообщений, так и динамически установленное соединение явных сообщений, действуют как родительский элемент назначенного(ых) I/O сообщения(й) до тех пор, пока I/O сообщение(я) находятся в установленном состоянии. Термин «родительский элемент» используется для того, чтобы показать, что если соединение явного сообщения выгружается, и ни одно из назначенных I/O сообщений не находится в установленном состоянии, то предопределенный набор соединений ведущего и ведомого устройств автоматически выгружается ведомым устройством («слейвом»). На рисунке 41 представлена схема описания, какое соединение явного сообщения должно активироваться как «родительский элемент».

Рисунок 41 — Логическое описание соединения для передачи явных сообщений родительского элемента

Ведомое устройство («слейв») должно автоматически выгрузить предопределенный набор соединений ведущего и ведомого устройств и все соединения должны вернуться к нулевому состоянию, если каждое из следующих условий является истинным:

• если ни один из объектов соединения, связанный с предопределенным набором соединений ведущего и ведомого устройств, не находится в установленном состоянии;
• если объект соединения явного родительского сообщения не находится в установленном состоянии.

5.5.3.3 Release_master/slave_connection_set (Код службы: 4CHex)

5.5.3.3.1 Общие положения

Данная служба используется для выгрузки из ведомого устройства предопределенного набора соединений ведущего/ведомого устройств. Общие коды ошибок определены в IEC 61158-5-2 (пункт 6.2.1.3.3) и IEC 61158-6-2 (пункт 4.1.11). Значения дополнительного кода конкретных ошибок объекта DeviceNet определены в 5.5.3.5. Данная служба может передаваться через порт явного сообщения ведущего и ведомого устройств (5.5.2), а также соединение явного сообщения.

5.5.3.3.2 Служба запроса параметров поля данных

Информация, приведенная в таблице 16, представляет службу запроса параметров поля данных release_master/slave_connection_set.

Таблица 16

Служба запроса параметров поля данных release_master/slave_connection_set

Наименование	Тип данных	Описание параметра
Выбор выгрузки	BYTE	Показывает, какой предопределенный набор соединений ведущего и ведомого устройств должен быть выгружен

Параметр выбора выгрузки указывается в одном байте (см. рисунок 42). Каждый бит обозначает явное сообщение и/или I/O соединение(я), которое необходимо выгрузить. Если бит установлен на 1, тогда генерируют запрос для выгрузки соответствующих соединений. Если бит установлен на 0, тогда запрашивающему не требуется выгружать соответствующее соединение.

Рисунок 42 — Выгрузка контента байта

Биты 3 и 7 должны быть установлены на 0 и ведомое устройство должно проконтролировать это требование при получении запроса release_master/slave_connection_set.

Значение 00 является некорректным.

На рисунке 43 показан формат этого явного сообщения.

Рисунок 43 — Сообщение-запрос

• код службы (4CHex): идентифицирует сообщение как службу release_master/slave_connection_set;
• ID класса: определяет класс объекта, которому направлен запрос. Когда это сообщение передается через порт набора соединений ведущего и ведомого устройств для передачи явного сообщения без соединения (см. 5.5.2), то значение ID класса указывается в поле целочисленного бита 8. ID класса должно быть установлено на 03;
• ID экземпляра: определяет класс объекта, которому направлен запрос. Когда это сообщение передается через порт набора соединений ведущего и ведомого устройств для передачи явного сообщения без соединения (см. 5.5.2), то значение ID экземпляра указывается в поле целочисленного бита 8. ID экземпляра должен быть установлен на 1;
• выбор выгрузки: указывается в байте, следующем за ID поля экземпляра.

5.5.3.3.3 Сообщение-отклик об успешном выполнении запроса

На рисунке 44 показан формат сообщения-отклика об успешном выполнении запроса release_master/slave_connection_set request.

Рисунок 44 — Сообщение-отклик об успешном выполнении запроса release_master/slave_connection_set

Содержание сообщения-отклика об успешном выполнении запроса release_master/slave_connection_set request:

• frag (0)/transaction ID/MAC ID: см. 5.2.1.2;
• R/R бит (0): показывает, что это — сообщение-отклик;
• код службы (4CHex): идентифицирует сообщение как службу release_master/slave_connection_set.

5.5.3.4 Режим работы сервера release_master/slave_connection_set

Если обнаруживается ошибка, то не происходит выгрузки ни одного из указанных соединений. В случае если данный запрос не может быть выполнен полностью, ни одна из запрашиваемых выгрузок не будет обработана.

Если ведомое устройство не поддерживает предопределенный набор соединений ведущего и ведомого устройств, то должно быть возвращено сообщение-отклик об ошибке. Общий код ошибки должен быть установлен на 08.

Ведомое устройство («слейв») должно проверять параметр выбора выгрузки запроса. Если ведомое устройство не поддерживает одно из соединений, указанных в аргументе выбора выгрузки, то должно быть возвращено сообщение-отклик об ошибке. Общий код ошибки должен быть установлен на 02, а дополнительный код ошибки — на конкретное значение 02 объекта.

Если байт выбора выгрузки не имеет установленных битов (все биты 0), ведомое устройство должно вернуть сообщение об ошибке с общим кодом ошибки, установленным на 09 (значение неправильного атрибута), и дополнительным кодом ошибки, установленным на конкретное значение 02 объекта.

Если одно из указанных соединений находится в нулевом состоянии, то тогда должно быть возвращено сообщение-отклик об ошибке. Код ошибки общего характера в сообщении-отклике об ошибке должен быть установлен на 0BHex.

Ведомое устройство должно проверить, что оно находится в состоянии, которое позволяет ему прервать использование указанного(ых) соединения(й). Если это не так, то сообщение об ошибке должно быть возвращено. Общий код ошибки в сообщении-отклике должен быть установлен на 0CHex.

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

Ведомое устройство не должно отслеживать, что запрос о выгрузке поступил от ведущего устройства.

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

5.5.3.5 Коды ошибок, характерные для объекта DeviceNet

В таблице 17 приводятся коды ошибок, характерные для объекта DeviceNet.

Таблица 17

Дополнительные коды ошибок, характерные для объекта DeviceNet

Значение	Разъяснение значения
01	Конфликт назначения предопределенного набора соединений ведущего и ведомого устройств. Происходит возврат, когда получен запрос allocate_master/slave_connection_set, и ведомое устройство уже назначило предопределенный набор соединений ведущего и ведомого устройств на другом ведущем устройстве
02	Неправильный параметр выбора назначения/выгрузки. Происходит возврат при получении запроса allocate_master/slave_connection_set и: 1) ведомое устройство не поддерживает выбор, указанный в параметре выбора; 2) ведомому устройству был дан запрос о назначении/выгрузке соединений, которые уже были назначены/выгружены; 3) байт выбора места назначения/выгрузки, содержащий все нули, неправильная комбинация битов или не содержащий выбор назначения явного сообщения, когда требуется
03	Сервер, который не поддерживает UCMM, получивший сообщение, которое не было назначено или выгружено в порте предопределенного набора соединений ведущего и ведомого устройств для передачи явного сообщения без соединения (см. 5.5.2)
04	Не доступен ресурс, необходимый для использования с предопределенным набором соединений ведущего и ведомого устройств

5.5.4 Характеристики объекта соединения ведомого устройства («слейва»)

5.5.4.1 Общие положения

В настоящем разделе представлены явно выраженные характеристики объектов соединения, связанных с предопределенным набором соединений ведущего и ведомого устройств, описанных для ведомых устройств, а именно:

• битстробовое соединение: отвечающее за получение битстробовой команды ведущего устройства и возвращающее соответствующее битстробовое сообщение-отклик;
• соединение по запросу: отвечающее за получение команды по запросу ведущего устройства и возвращающее соответствующее сообщение-отклик по запросу;
• соединение для передачи явных сообщений: отвечающее за получение явных запросов и возвращающее соответствующие сообщения-отклики;
• соединение в целях изменения состояния/цикличного изменения: отвечающее за отправку сообщения (при отсутствии блокировки) об изменении состояния/цикличном изменении и получение подтверждающего отклика;
• многоадресное соединение по запросу: отвечающее за получение многоадресной команды запроса ведущего устройства и возвращающее отклик многоадресного запроса.

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

5.5.4.2 ID экземпляра соединения

У любого существующего объекта соединения существует ID экземпляра соединения, который идентифицирует объект соединения в рамках класса соединения. ID экземпляра соединения, которые используются ведомым устройством для идентификации объектов предопределенного соединения ведущего и ведомого устройств, представлены в таблице 18.

Идентификатор соединения с экземпляром	Описание
1	Обозначает соединение в целях передачи явных сообщений на сервер
2	Обозначает соединение I/O по запросу
3	Обозначает соединение I/O по стробу
4	Обозначает изменение состояния ведомого устройства или циклическое соединение I/O
5	Обозначает соединение I/O по многоадресному запросу

Ведомое устройство должно резервировать идентификаторы экземпляра, указанные в таблице 18 для предопределенных соединений ведущих/ведомых устройств, которые оно поддерживает. Например, если устройство поддерживает соединение I/O по запросу, оно должно резервировать/использовать идентификатор ID # 2 для идентификации объекта соединения I/O по запросу. Если устройство не поддерживает соединение по запросу, тогда оно может назначить идентификатор ID # 2 соединения для идентификации некоторого другого объекта соединения.

5.5.4.3 Режим работы экземпляра предопределенного соединения ведущего и ведомого устройств

На рисунке 45 изображена схема передачи состояния объекта соединения I/O для предопределенной передачи информации о ведущих и ведомых устройствах.

Рисунок 45 — Схема передачи состояния предопределенного соединения I/O ведущего и ведомого устройств

В случае модификации атрибута предопределенные соединения I/O должны поддерживать хотя бы модификацию атрибута expected_packet_rate attribute.

Матрица событий и состояний, представленная в таблице 19, предоставляет формальное определение режима работы соединений I/O в предопределенном назначении идентификаторов ведущих и ведомых устройств. Данная матрица событий и состояний основана на и/или заменяет действия, представленные в матрице событий и состояния соединения I/O в 5.3.

Таблица 19

Матрица событий состояния предопределенного соединения I/O ведущего и ведомого устройств

Событие	Состояние объекта соединения I/O
	Нулевое	Выбор конфигурации	Установленное	Таймаут
Объект DeviceNet получает запрос на установление выделенного соединения ведущего и ведомого устройств, который проходит все проверки на наличие ошибок, указанные в 5.5.3.2. Данный запрос задает одно из предопределенных соединений I/O ведущего и ведомого устройств	Создают объект соединения для каждого запрошенного соединения I/O и устанавливают атрибуты на значения по умолчанию, приведенные в 5.5.3.1. Переход к состоянию конфигурирования	Ошибка. См. 5.5.3.2	Ошибка. См. 5.5.3.2	Устанавливают атрибуты до значений по умолчанию, приведенных в 5.5.3.1. Переход в состояние выбор конфигурации
Класс соединения получает удаленный запрос или UCMM получает закрытый запрос и запрос задает предварительно определенный объект соединения I/O ведущего и ведомого устройств	Как установлено в таблице 193 IEC 61158-6-2, 7.2.1	Высвобождение всех соответствующих ресурсов. Переход к нулевому состоянию a	Высвобождение всех соответствующих ресурсов. Переход к нулевому состоянию a	Высвобождение всех соответствующих ресурсов. Переход к нулевому состоянию a
Объект DeviceNet получает запрос на установление выделенного соединения ведущего и ведомого устройств, который проходит все проверки на наличие ошибок, указанные в 5.5.3.2. Данный запрос задает одно из предопределенных соединений I/O ведущего и ведомого устройств	Ошибка. См. 5.5.3.2	Высвобождение всех соответствующих ресурсов. Переход к нулевому состоянию a	Высвобождение всех соответствующих ресурсов. Переход к нулевому состоянию a	Высвобождение всех соответствующих ресурсов. Переход к нулевому состоянию a
Set_attribute_single	Как установлено в IEC 61158-6-2, 7.2.1	Проверяют/обрабатывают запрос в соответствии с правилами доступа, установленными в 5.5.4.4.	Проверяют/обрабатывают запрос в соответствии с правилами доступа, установленными в 5.5.4.4.	Проверяют/обрабатывают запрос в соответствии с правилами доступа, установленными в 5.5.4.4.
		Если это валидный запрос для установления атрибута expected_packet_rate attribute, тогда выполняют шаги, указанные в IEC 61158-6-2, 7.2.1 при событии apply_attributes в состоянии выбора конфигурации и переходе на установленное. Возвращают соответствующий отклик	Возвращают соответствующий отклик	Возвращают соответствующий отклик
Get_attribute_single	Как установлено в IEC 61158-6-2, 7.2.1	Проверяют/обрабатывают запрос в соответствии с правилами доступа, установленными в 5.5.4.4. Возвращают соответствующий отклик	Проверяют/обрабатывают запрос в соответствии с правилами доступа, установленными в 5.5.4.4. Возвращают соответствующий отклик	Проверяют/обрабатывают запрос в соответствии с правилами доступа, установленными в 5.5.4.4. Возвращают соответствующий отклик
Сброс	Как установлено в IEC 61158-6-2, 7.2.1	Как установлено в IEC 61158-6-2, 7.2.1	Как установлено в IEC 61158-6-2, 7.2.1	Как установлено в IEC 61158-6-2, 7.2.1
Apply_attributes		Как установлено в IEC 61158-6-2, 7.2.1
Receive_data
Send_message		Как описано в IEC 61158-6-2, 7.2.1
Окончание функционирования неактивного/контрольного таймера схемы
a Всякий раз, когда объект предопределенного набора соединения ведущего/ведомого устройств переходит из установленного состояния, может потребоваться автоматическое высвобождение всего набора предопределенного соединения ведущего/ведомого устройств. Когда выполнено высвобождение набора предопределенного соединения ведущего/ведомого устройств, все соответствующие объекты соединения возвращаются в нулевое состояние. Детальную информацию по автоматическому высвобождению набора предопределенного соединения ведущего/ведомого устройств см. в 5.5.3.3. b Поскольку скрытые прикладные атрибуты сопровождают set_attribute_single атрибута expected_packet_rate объекта предопределенного соединения I/O ведущего и ведомого устройств в состоянии выбора конфигурации, запрос, основанный на явных сообщениях и прикладных атрибутах, будет успешен только тогда, когда expected_packet_rate будет успешно модифицирован через запрос set_attribute_single и, следовательно, еще будет содержать значение по умолчанию 0.

На схеме передачи состояния (см. рис. 46) приведен режим работы предопределенного соединения ведущих и ведомых устройств с целью передачи явных сообщений.

Рисунок 46 — Схема передачи состояния предопределенного соединения ведущего и ведомого устройства для передачи явных сообщений

В таблице 20 представлена подробная матрица событий предопределенного объекта соединения ведущего и ведомого устройств в целях передачи явных сообщений. Данная матрица событий состояния наследует и/или имеет приоритет перед действиями, представленными в матрице событий состояния объекта соединения I/O (см. 5.3).

Таблица 20

Матрица событий состояния предопределенного соединения ведущего и ведомого устройств в целях передачи явных сообщений

Событие	Состояние объекта соединения для передачи явных сообщений
	Нулевое	Установленное
Объект DeviceNet получает запрос на установление выделенного соединения ведущего и ведомого устройств, который проходит все проверки на наличие ошибок, указанные в 5.5.3.2. Данный запрос задает предопределенное соединение на основе передачи явных сообщений	Создается объект предопределенного соединения ведущего и ведомого устройств в целях передачи явных сообщений для каждого запрошенного соединения I/O и устанавливают атрибуты на значения по умолчанию (см. 5.5.3.1). Переход к установленному состоянию	Ошибка. См. 5.5.3.2
UCMM получает закрытый запрос или класс соединения получает удаленный запрос и запрос задает предопределенный объект соединения на основе передачи явных сообщений ведущего и ведомого устройств	Как установлено в IEC 61158-6-2 (пункт 7.2.3)	Как установлено в IEC 61158-6-2 (пункт 7.2.3)
Объект DeviceNet получает запрос на установление высвобождение соединения ведущего и ведомого устройств, который проходит все проверки на наличие ошибок, указанные в 5.5.3.2. Данный запрос задает предопределенное соединение на основе передачи явных сообщений	Ошибка. См. 5.5.3.2	Высвобождение всех соответствующих ресурсов. Переход к нулевому состоянию a
Set_attribute_single	Как установлено в IEC 61158-6-2 (пункт 7.2.3)	Как установлено в IEC 61158-6-2 (пункт 7.2.3)
Get_attribute_single
Сброс
Apply_attributes
Receive_data
Send_message
Окончание функционирования неактивного/контрольного таймера схемы
a Всякий раз, когда объект предопределенного набора соединения ведущего/ведомого устройств переходит из установленного состояния, может потребоваться автоматическое высвобождение всего набора предопределенного соединения ведущего/ведомого устройств. Когда выполнено высвобождение набора предопределенного соединения ведущего/ведомого устройств, все соответствующие объекты соединения возвращаются в нулевое состояние. Детальную информацию по автоматическому высвобождению набора предопределенного соединения ведущего/ведомого устройств см. в 5.5.3.3.

5.5.4.4 Правила доступа к атрибутам экземпляра соединения

В IEC 61158-5-2 (пункт 6.2.3.2.1.4) приведено общее описание правил доступа, связанных с объектами соединения. В таблице 21 представлены правила доступа для объектов соединения I/O ведущего и ведомого устройств, наследованные и/или которые имеют приоритет над правилами, установленными в IEC 61158-5-2 (пункт 6.2.3.2.1.4).

Таблица 21

Доступ к атрибуту объекта предопределенного соединения I/O ведущего и ведомого устройств

Атрибут	Состояние соединения I/O
	Нулевое	Выбор конфигурации	Установленное	Таймаут (истечение времени ожидания)
State	Как установлено в IEC 61158-6-2, 6.2.3.2.1.4	Как установлено в IEC 61158-6-2 (пункт 6.2.3.2.1.4)	Как установлено в IEC 61158-6-2 (пункт 6.2.3.2.1.4)	Как установлено в IEC 61158-6-2 (пункт 6.2.3.2.1.4)
Instance_type
Transportclass_trigger		Get/set a
Produced_connection_id		Только Get	Только Get	Только Get
Consumed_connection_id		Только Get c	Только Get c	Только Get c
initial_comm_characteristics		Только Get	Только Get	Только Get
Produced_connection_size		Get/set b	Как установлено в IEC 61158-6-2 (6.2.3.2.1.4)	Как установлено в IEC 61158-6-2 (6.2.3.2.1.4)
Consumed_connection_size		Get/set b
Expected_packet_rate		Как установлено в IEC 61158-6-2 (пункт 6.2.3.2.1.4)
Watchdog_timeout_action
Produced_connection_path_length
Produced_connection_path
Consumed_connection_path_length
Consumed_connection_path
a Атрибут transportclass_trigger объекта предопределенного набора соединений I/O ведущего и ведомого устройств в ведомом устройстве должен изменяться до одного из следующих значений: 82Hex — класс сервера/передачи 2, 83Hex — класс сервера/передачи 3. b Атрибут produced_connection_size битстробового соединения I/O не должен устанавливаться на значение более 8. c Данный атрибут должен иметь доступ Get/set многоадресного соединения по запросу.

5.5.5 Характеристики объекта соединения ведущего устройства

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

5.5.6 Битстробовые команды опроса/сообщения-отклики

5.5.6.1 Общие положения

Битстробовые команды опроса и сообщения-отклики транслируют небольшие пакеты данных I/O между ведущим устройством и его битстробовыми ведомыми устройствами.

5.5.6.2 Битстробовая команда опроса

Битстробовая команда направляет один бит выходных данных каждому ведомому устройству.

Битстробовая команда опроса содержит строку из 64 бит (8 байтов) выходных данных, один выходной бит для каждого возможного MAC ID по адресу связи.

Ведомое устройство может быть предназначено для совершения одного или всех нижеперечисленных действий:

- игнорирование битстробовой команды;

- принятие битстробовой команды и ее выходных данных;

- принятие битстробовой команды в качестве активатора и игнорирование выходных данных.

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

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

5.5.6.3 Битстробовое сообщение-отклик

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

Пустое битстробовое сообщение-отклик, конфигурированное на содержание данных, распознается ведущим устройством как событие без действительных битстробовых данных. Режим работы ведущего устройства после выявления данного события зависит от области применения.

5.5.6.4 Характеристики битстробового сообщения

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

Ведомое устройство обеспечивает единое соединение серверного класса передачи 2 или 3 для получения битстробовой команды и отправки соответствующего отклика.

5.5.7 Команды опроса/сообщения-отклики по запросу

5.5.7.1 Общие положения

Команды опроса и сообщения-отклики по запросу передают данные I/O между ведущим устройством и опрашиваемыми ведомыми устройствами.

5.5.7.2 Сообщение команды опроса

Команда по запросу передает до 65 535 байтов выходных данных (нефрагментированных или фрагментированных) назначенному ведомому устройству.

Допускается, чтобы ведомое устройство выполнило одно или все из нижеперечисленных действий:

- игнорирование команды опроса, если не назначено соединение;

- принятие команды опроса и ее выходных данных;

- принятие команды опроса в качестве активатора и игнорирование выходных данных.

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

Пустое сообщение команды опроса, переданное в поле данных CAN, интерпретируется прикладным объектом как событие receive_idle. Сообщение команды опроса, которое содержит данные, интерпретируется прикладным объектом как рабочее событие. Режим работы прикладного объекта после выявления события receive_idle или рабочего события зависит от характерных особенностей прикладного объекта.

5.5.7.3 Отклик на запрос

Отклик на запрос возвращает до 65535 байтов (нефрагментированных или фрагментированных) входных данных в ведущее устройство из ведомого устройства.

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

5.5.8 Изменение соединения состояния/циклического соединения

5.5.8.1 Общие положения

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

Изменение установленных соединений состояния или циклических соединений использует экземпляр соединения 2 для распознавания передачи данных от ведущего устройства ведомому и от ведомого ведущему. Экземпляр соединения 4 используется для распознания передачи данных от ведомого устройства ведущему и от ведущего ведомому. Если устройство не поддерживает запрос и не имеет поддержки выходных данных, в этом случае нет необходимости в генерации экземпляра соединения 2.

Для того чтобы режим работы системы был стабильным, режим работы ведомого устройства «изменение соединения состояния/циклического соединения» (экземпляр соединения 4) должен иметь установленный принятый путь для распознавания объекта обработки, а экземпляр распознаваемого объекта обработки должен быть 1.

Вследствие того, что изменение или запрос установленных соединений состояния/циклических соединений в совокупности используют экземпляр соединения 2, то ведомое устройство должно выполнить определенные процедуры, основанные на запросе размещения для обеспечения правильного режима работы. В соответствии с вышеописанным, если имеет место лишь изменение бита размещения данных состояния/циклических данных, то генерируются экземпляры соединения 2 и 4. Экземпляр соединения 4 является источником пути входных данных по умолчанию и принимает подтверждения для экземпляра обработки подтверждений. Если запрос на размещение содержит только бит назначения по запросу, то экземпляр соединения 2 принимает путь выходных данных по умолчанию и является источником пути входных данных по умолчанию.

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

Для того чтобы получить генерацию нераспознанных данных, бит блокировки распознавания формируется за счет изменения бита состояния или циклического бита в байте выбора назначения. Экземпляр соединения 2 конфигурируется как соединение транспортного класса 0 для генерации данных при соединении ведомого и ведущего устройств. Экземпляр соединения 4 конфигурируется как соединение транспортного класса 0 для генерации данных при соединении ведомого и ведущего устройств. Когда бит запроса устанавливается в том же выборе назначения, тогда экземпляр соединения 2 будет конфигурироваться как запрос, в то время как экземпляр соединения будет продолжать конфигурироваться как нераспознанное изменение состояния или циклическое соединение.

5.5.8.2 Изменение подтверждения приема сообщений состояния активатора или циклических сообщений

5.5.8.2.1 Общие положения

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

В нижеприведенных подразделах описано:

- изменение сообщения состояния/циклического сообщения (подтвержденный прием);

- изменение сообщения состояния/циклического сообщения (неподтвержденный прием);

- изменение характеристик сообщения состояния/циклического сообщения;

- изменение прикладных экземпляров состояния/цикла.

5.5.8.2.2 Изменение ведущим устройством сообщения состояния/циклического сообщения

Изменение ведущим устройством состояния/цикла передает до 65535 байтов данных (нефрагментированных или фрагментированных) на ведомое устройство назначения. Производство данных активируется за счет либо изменения состояния, либо передачи об истечении времени активатора.

Изменение сообщения состояния/циклического сообщения, переданного без данных в поле данных CAN, интерпретируется прикладным объектом как событие receive_idle event (получено событие «нерабочее состояние»). Изменение сообщения состояния/циклического сообщения, которое содержит данные, интерпретируется прикладным объектом как текущее событие «run event». Режим работы прикладного объекта при обнаружении текущего события зависит от характера прикладного объекта.

5.5.8.2.3 Изменение ведомым устройством сообщения состояния/циклического сообщения подтверждения приема

При изменении ведомым устройством сообщения состояния/подтверждения приема, на ведущее устройство от ведомого возвращается до 65535 байт данных (фрагментированных или нефрагментированных). По умолчанию сообщение подтверждения приема является сообщением нулевой длины.

5.5.8.2.4 Изменение ведомым устройством сообщения состояния/циклического сообщения

При изменении ведомым устройством сообщения состояния/циклического сообщения на ведущее устройство от ведомого отправляется 65535 байт данных (фрагментированных или нефрагментированных). Производство данных активируется за счет либо изменения состояния, либо передачи об истечении времени активатора.

Изменение сообщения состояния/циклического сообщения, которое не содержит данных и конфигурируется на содержание данных, указывает ведомому устройству на отсутствие текущего изменения события данных состояния/циклических данных. Режим работы ведущего устройства при обнаружении данного события от характера ввода в работу.

5.5.8.2.5 Изменение ведомым устройством сообщения состояния/циклического подтверждения приема

При изменении ведущим устройством сообщения состояния/циклического подтверждения приема от ведущего устройства на ведомое устройство возвращается до 65535 байтов (фрагментированных или нефрагментированных) данных. По умолчанию, сообщение подтверждения приема является сообщением нулевой длины.

5.5.9 Устройства исключительно второй группы

Для того чтобы установить связь с устройством только второй группы, клиент должен разместить предопределенное соединение ведущего и ведомого устройств. Запрос на размещение устройства только второй группы передается как явный запрос только второй группы без установления соединения. Вместо использования UCMM для установления соединений в целях передачи явных сообщений, устройство только второй группы получает и обрабатывает сообщения явного запроса только второй группы без установления соединения.

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

- allocate_master/slave_connection_set message,

- release_master/slave_connection_set message.

Данные службы описаны в 5.5.3.

Отклики на явные запросы только второй группы без установления соединения возвращаются посредством передачи сообщения только второй группы, компонент MAC ID (идентификатора) которого устанавливается для реагирования на MAC ID устройства (источник MAC ID) и сообщение ID которого устанавливается на 3.

Устройства только второй группы должны использовать поле идентификатора явного сообщения реагирования ведомого устройства исключительно для передачи сообщений-откликов только второй группы и сообщений-откликов на предопределенное соединение в целях передачи явных сообщений.

Отклики на явные запросы только второй группы без установления соединения возвращаются посредством передачи сообщения только второй группы, компонент MAC ID которого установлен на отклик MAC ID устройства (источник MAC ID), а сообщение ID (идентификатора) установлено на 3.

Устройства только второй группы должны использовать поле идентификатора явного сообщения отклика ведомого устройства только для передачи сообщений-откликов без установления соединения и сообщений-откликов при предопределенном соединении ведущего и ведомого устройств для передачи явных сообщений. Если сервер только второй группы получает сообщение запроса только второй группы без установления соединения, которое не является запросом allocate_master/slave_connection_set или release_master/slave_connection_set, тогда отклик об ошибке, код ошибки общего характера которого устанавливается на 02, а дополнительный код ошибки устанавливается на значение 03, характерное для объекта DeviceNet, должен быть возвращен.

5.6 DeviceNet SafetyTM <1> (безопасность)

5.6.1 Общие положения

DeviceNet Safety использует выделенный коммуникационный уровень безопасности над прикладным уровнем базового протокола DeviceNet: DeviceNet использует базовые коммуникационные объекты и службы DeviceNet вместе с конкретными объектами и службами, связанными с безопасностью, и включенными в функциональный коммуникационный профиль безопасности CIP SafetyTM <1>. Безопасность CIP (общего промышленного протокола) полностью описана в IEC 61784-3-2, включая специальные адаптации к DeviceNet.

---

<1> DeviceNet SafetyTM и CIP SafetyTM является торговой маркой Открытой Ассоциации поставщиков DeviceNet. Эта информация предоставляется для удобства пользователей настоящего стандарта и не является рекламой IEC держателя торговой марки или любого из его изделий. Соответствие данному стандарту не требует использования фирменного наименования DeviceNet SafetyTM и CIP SafetyTM. Соответствие настоящему стандарту не требует использования фирменного наименования DeviceNet SafetyTM или CIP SafetyTM, требуется разрешение Открытой Ассоциации поставщиков DeviceNet.

При внедрении в составе системы безопасности, соответствующей IEC 61508, DeviceNet Safety обеспечивает необходимую надежность в процессе передачи информации между двумя или более CDI (интерфейсами контролера устройства), или надежность безопасного режима работы в случае неисправности CDI. Данную систему можно использовать в таких областях, где требуется функциональная безопасность вплоть до уровня полноты безопасности (SIL), описанного в IEC 61784-3-2.

Примечание — В результате требование системы уровня полноты безопасности SIL зависит от выбранного коммуникационного профиля функциональной безопасности внутри системы — внедрение коммуникационного профиля функциональной безопасности, соответствующего данной части стандарта, в стандартное устройство, не достаточно, чтобы определить его как устройство обеспечения безопасности.

5.6.2 Использование идентификаторов CAN

Назначение идентификаторов CAN для DeviceNet Safety установлено в IEC 61784-3-2. Назначение представлено так, что оно никоим образом не противоречит предопределенному применению стандартного идентификатора.

5.7 Физический уровень

5.7.1 Общие положения

В таблице 22 приведены общие спецификации на физический уровень, которые должны быть выполнены в системах DeviceNet Safety (спецификация на испытания см. в 9.2.6).

Таблица 22

Общие характеристики физического уровня

Характеристика	Спецификация
Скорость передачи информации в битах	125 кбит/с, 250 кбит/с, 500 кбит/с
Максимальная общая длина магистральной линии и максимальная длина кабеля между любыми двумя устройствами	500 м при 125 кбит/с 250 м при 250 кбит/с 100 м при 500 кбит/с
Количество узлов, поддерживаемых трансивером	Минимум 64
Передача сигнала	В соответствии с ISO 11898
Модуляция	Групповая
Кодирование	«Без возврата к нулю» вместе с заполнением битами
Связь с передающей средой	Дифференциальные передача/прием, связанные по постоянному току
Изоляция (между электронной схемой трансивера и чипом CAN)	500 В постоянного тока. Применяется только к изолированным устройствам
Типичное дифференциальное входное полное сопротивление (нисходящее состояние)	Шунт C = 5 pF Шунт R = 25 кОм (при включенном питании)
Минимальное дифференциальное входное полное сопротивление (нисходящее состояние)	Шунт C = 24 pF Шунт R = 20 кОм (при включенном питании)
Напряжение на силовых кабелях	11 В постоянного тока — 25 В постоянного тока
Диапазон значений максимального напряжения сигнала	-25 В постоянного тока до +18 В постоянного тока (CAN_H, CAN_L) a
a Напряжения на CAN_H, CAN_L должны быть характерны для заземления трансивера. Потенциал заземления трансивера может быть выше, чем у вывода B-, за счет значения, равного перепаду напряжения на диоде Шоттки или аналогичном оборудовании. Данное напряжение должно составлять максимум 0,6 В применительно к выводу B-.

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

Рисунок 47 — Блок-схема физического слоя

5.7.2 Трансивер

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

Для того чтобы выводы CAN_H и CAN_L трансивера были совместимы с конструкцией системы, они должны поддерживать минимальный общий рабочий режим +/- 5 В, т.е. трансивер должен выдерживать колебания в заземлении +/- 5 В.

Трансивер должен непрерывно питаться от канала связи.

Требуемые характеристики трансмиттера и ресивера указаны в таблице 23 и таблице 24 (Спецификации на испытания см. в 9.2.7).

Таблица 23

Характеристики трансмиттера

Характеристика трансмиттера	Спецификация
Дифференциальный уровень выхода (номинальный)	Размах колебаний («от пика к пику») 2,0 В
Дифференциальный уровень выхода (минимальный) (измеренный на проводнике, нагрузка 50 кОм)	Размах колебаний 1,5 В
Минимальное восходящее напряжение шины на CAN_H	2,75 В a
Максимальное восходящее напряжение шины на CAN_H	4,5 В a
Минимальное восходящее напряжение шины на CAN_L	0,5 В a
Максимальное восходящее напряжение шины на CAN_L	2,0 В a
Минимальное нисходящее напряжение шины на CAN_H и CAN_L	2,0 В a
Максимальное нисходящее напряжение шины на CAN_H и CAN_L	3,0 В a
Максимальный период задержки трансмиттера (включая изоляцию)	120 нс
Защита от короткого замыкания выхода	Изнутри ограниченная
a Напряжения на CAN_H, CAN_L должны быть характерны для заземления трансивера. Потенциал заземления трансивера может быть выше, чем у вывода B-, за счет значения, равного перепаду напряжения на диоде Шоттки или аналогичном оборудовании. Данное напряжение должно составлять максимум 0,6 В применительно к выводу B-.

Таблица 24

Характеристики ресивера

Характеристики ресивера	Спецификация
Дифференциальное восходящее напряжение входа	0,9 В минимум
Дифференциальное нисходящее напряжение входа	0,9 В максимум
Гистерезис	150 мВ типовой
Максимальный период задержки ресивера (включая изоляцию)	130 нс
Диапазон значений рабочего напряжения (CAN_H и CAN_L)	От минус 5 В до плюс 10 В a
a Напряжения на CAN_H, CAN_L должны быть характерны для заземления трансивера. Потенциал заземления трансивера может быть выше, чем у вывода B-, за счет значения, равного перепаду напряжения на диоде Шоттки или аналогичном оборудовании. Данное напряжение должно составлять максимум 0,6 В применительно к выводу B-.

Период задержки подтверждения устройства должен быть менее 302 нс или равен данному значению. Задержка подтверждения включает задержки прохождения у трансмиттера, ресивера и контроллера CAN. Допускается любое сочетание таких задержек при условии, что общее время составляет менее 302 нс или равно данному значению, а максимальные периоды задержки трансмиттера и ресивера, соответственно, не превышают значений, приведенных в таблицах 23 и 24.

Примечание — Максимальное время задержки по таблице 23 составляет 120 нс, а максимальное время задержки ресивера по таблице 24 составляет 130 нс. Благодаря максимальному времени задержки контроллера CAN в 53 с период задержки подтверждения не превышает 302 нс.

Спецификации на испытания см. в 9.2.8.

5.7.3 Заземление

Для того чтобы не было петель заземления, канал связи должен быть размещен только в одном месте, желательно у источника питания. Схемное решение физического слоя во всех устройствах должно быть B-. Устройство не должно вызывать протекания тока между B- и землей.

5.7.4 Изоляция

5.7.4.1 Общие положения

Различают изолированные и неизолированные устройства.

Примечание — Изолированные устройства и неизолированные устройства могут сосуществовать и обмениваться данными через CDI.

5.7.4.2 Неизолированные устройства

Внутри устройства, которое содержит неизолированный физический уровень, заземленные B- компоненты могут подключаться к другим внешним устройствам (см. рисунок 48). Данные внешние устройства должны быть изолированы от земли, а данное требование указано в документации изготовителя.

Рисунок 48 — Устройство, содержащее неизолированный физический уровень

Соединение экрана DeviceNet должно быть реализовано через параллельную RC-цепь (резистивно-емкостную цепь; сопротивление = 1 мОм, C = 0,01 мкФ (500 В)) к корпусу устройства.

Примечание — Наилучшую электромагнитную совместимость можно обеспечить, если проводник остается очень коротким на протяжении данного пути, а корпус закрытой конструкции изготовлен из электропроводного материала. Если у устройства нет такого корпуса, то вывод экрана разъема можно оставить неприсоединенным.

5.7.4.3 Изолированное устройство

Данные устройства должны получать питание от канала, выделенного для схемы трансивера и изоляции (см. рисунок 49). Питание от выделенного канала может использоваться для другого схемного решения, при условии что схема, питаемая от выделенного канала, заземлена как B- или другим способом.

Рисунок 49 — Устройство, содержащее изолированный физический уровень

В случае изолированного устройства контроллер CAN может оставаться в рабочем состоянии, в то время как линия питания отключена.

Внутри изолированного устройства компоненты, заземленные как B-, могут подключаться к другим внешним устройствам через последовательные порты, параллельные порты и соединения I/O. Такие внешние устройства должны быть изолированы от земли, а данное требование указано в документации изготовителя.

Экранированное соединение канала связи должно проходить через параллельную RC-цепь к корпусу устройства.

5.7.5 Передающая среда

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

В DeviceNet предусмотрено два основных типа кабеля: круглый экранированный (например, толстый и тонкий кабели) и плоский неэкранированный (например, плоский кабель). Тяжелые кабели обеспечивают магистральные линии большей протяженностью и более прочные магистральные линии с более высокой допустимой нагрузкой по току. Благодаря тонким кабелям обеспечивается более легкая маршрутизация и оконечная заделка как магистральных, так и промежуточных линий. И толстые и тонкие кабели могут использоваться в магистральных и/или промежуточных линиях в любом сочетании. Плоские кабели используют только в магистральных линиях.

5.7.6 Топология (общая схема соединений)

5.7.6.1 Общие положения

У среды DeviceNet должна быть линейная топология (см. рисунок 50). Отводные линии, если они используются, должны давать возможность присоединить один или несколько узлов. Разветвленная конструкция допускается только на отводной линии.

Рисунок 50 — Топология среды DeciceNet

Оконечные резисторы должны быть подключены на каждом конце магистральной линии.

Расстояние кабеля между двумя точками в системе кабелей не должно превышать максимально допустимое расстояние кабеля для скорости передачи в битах. Расстояние кабеля между двумя точками включает длину кабеля магистральной линии и длину кабеля отводной линии, которые существуют между двумя точками.

5.7.6.2 Магистральные линии

Общая длина магистральной линии, допустимая в сети, зависит от битовой скорости и типа используемого кабеля.

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

DeciceNet позволяет сочетание различных типов кабелей в магистральной системе. В 8.2 указаны профили кабелей для соответствующих типов кабелей и их аналогов, используемых при сочетании различных типов кабелей в магистральных линиях.

5.7.6.3 Отводные линии

Длина отводной линии представляет собой самое длинное расстояние кабеля, измеренного от ответвителя на магистральной линии до каждого трансивера узлов на отводной линии. Данное расстояние включает любой кабель отводной линии, который постоянно присоединен к устройству, и не должно превышать 6 м. Общая длина отводной линии, допустимой на канале связи, зависит от битовой скорости и не должна превышать значений соответствующих профилей кабелей, указанных в 8.2.

5.7.7 Питание линии связи

5.7.7.1 Конфигурация питания

Питание линии связи должно подаваться источником номинального 24 В постоянного тока и выдерживать напряжение до 8 А на любом отрезке магистральной линии из толстого кабеля или до 3 А на любом отрезке магистральной линии из тонкого кабеля. Можно использовать несколько источников питания.

5.7.7.2 Пределы нагрузки

Максимальный ток сети связи определяют по данным, приведенным в таблице 25 (спецификации на испытания см. в 9.2.2).

Таблица 25

Пределы нагрузки

Характеристика	Спецификация
Максимальный спад напряжения на B- и B+	На каждом 5 В
Максимальный ток магистральной линии из толстого кабеля	8 А
Максимальный ток магистральной линии из тонкого кабеля	3 А
Диапазон значений максимального тока отводной линии	0,75 А — 3,0 А a
Диапазон значений напряжения на каждом узле	11 В — 25 В
Рабочий ток каждого элемента b	Устанавливает изготовитель
a Максимальный ток отводной линии зависит от длины отвода (см. ниже). b Представляет собой среднее значение тока линии связи. Указывают пиковое значение рабочего тока, если он превышает среднее значение тока на более чем 10%.

Максимальный ток отводной линии также можно вычислить по формуле:

i = 4,5/l,

где i — максимально допустимый ток отводной линии (А);

l — максимальная длина отвода (м).

6 Информация об изделии

В соответствии с IEC 62026-1.

7 Нормальные условия эксплуатации, установки и транспортирования

7.1 Нормальные условия эксплуатации

7.1.1 Общие положения

Компоненты DeviceNet CDI должны работать при следующих условиях:

Примечание — Если условия работы отличаются от условий, указанных в настоящей части, пользователю следует указать отклонения от стандартных условий и проконсультироваться с изготовителем по вопросу пригодности для использования в таких условиях.

7.1.2 Температура окружающей среды

7.1.2.1 Толстый кабель

Кабель должен нормально работать при температурах окружающей среды от минус 20 °C до плюс 60 °C во время переноса тока в 8 А. Такую токовую нагрузку снижают линейно до нуля при 80 °C.

7.1.2.2 Тонкий кабель

Кабель должен нормально работать при температурах окружающей среды от минус 20 °C до плюс 70 °C во время переноса тока в 1,5 А. Такую токовую нагрузку снижают линейно до нуля при 80 °C.

7.1.2.3 Плоский кабель

Кабель должен нормально работать при температурах окружающей среды от минус 25 °C до плюс 75 °C во время переноса тока в 1,5 А. Такую токовую нагрузку снижают линейно до нуля при 80 °C.

7.1.2.4 Ответвители устройств

Ответвители устройств должны нормально работать при температурах окружающей среды от минус 40 °C до плюс 70 °C во время переноса полного тока. Такую токовую нагрузку снижают линейно до нуля при 80 °C. Максимальный непрерывный ток на силовых проводах составляет 3 А в случае микроразъемов и 8 А в случае других разъемов, если не указано иное.

7.1.2.5 Ответвители источника питания

Ответвители питания должны нормально работать при температурах окружающей среды от минус 40 °C до плюс 70 °C во время переноса полного тока. Такую токовую нагрузку снижают линейно до нуля при 80 °C.

7.1.2.6 Другие компоненты CDI

Все другие компоненты DeviceNet CDI должны нормально работать при температурах окружающей среды от минус 25 °C до плюс 70 °C, если не установлены иные пределы, например в сочетании со специальным активатором или компоненты типа датчиков. Рабочие характеристики должны поддерживаться в соответствии с допустимыми температурами окружающей среды.

7.1.3 Высота

Компоненты DeviceNet должны работать на высоте согласно IEC 62026-1.

7.1.4 Климатические условия

7.1.4.1 Влажность

Компоненты DeviceNet должны работать при 40 °C и относительной влажности воздуха не более 95%.

7.1.4.2 Степень загрязнения

Компоненты DeviceNet должны работать при условиях степени загрязнения по IEC 62026-1.

7.2 Условия транспортирования и хранения

Потребитель и изготовитель должны прийти к соглашению, если условия транспортирования и хранения отличаются от приведенных ниже:

- влажность: относительная влажность воздуха не более 95% при 40 °C;

- температура: от минус 40 °C до плюс 85 °C.

7.3 Монтаж

Компоненты DeviceNet монтируют в соответствии с IEC 62026-1.

8 Требования к конструкции и работоспособности

8.1 Индикаторы и переключатели конфигурации

Индикаторы и переключатели конфигурации для DeviceNet приведены в IEC 61158-4-2 (приложение A). В данном случае применяются общие и специальные требования к CDI, вариант (3).

Для устройств DeviceNet Safety есть дополнительные требования, см. IEC 61784-3-2.

8.2 Кабель DeviceNet

8.2.1 Общий обзор

В настоящем подразделе приведены спецификации (технические описания) на следующие профили кабелей:

- толстый кабель;

- тонкий кабель;

- плоский кабель.

8.2.2 Шаблон профиля кабеля

Профиль кабеля определяют по спецификациям пар для передачи данных, спецификациям пар источников питания постоянным током, топологии и физической конфигурации кабеля. Расположение и пары данных по мощности являются требованием спецификации. В таблицах 26, 27, 28 и 29 установлены минимальные поля, которые обуславливают профиль кабеля DeviceNet.

Таблица 26

Профиль кабеля: спецификации на пару для передачи данных

Физическая характеристика	Спецификация
Размер пары проводника	Размер/материал жил
Диаметр по изоляции	Размер
Цвета — (CAN_H, CAN_L)
Витая пара	Расстояние
Поясной экран вокруг пары	Материал
Электрическая характеристика	Спецификация
Помеха	120 Ом +/- 10% (при 500 кГц)
Задержка распространения	<#> нс/м (макс.)
Емкость между проводниками	<#> пФ/м при <#> кГц (макс.)
Емкость между одним проводником и другим проводником, присоединенным к экрану	<#> пФ/м при <#> кГц (макс.)
Емкостная асимметрия	<#> пФ/м при <#> кГц (макс.); ASTM D4566-94
DCR — 20 °C	<#> Ом/1000 м (макс.)
Коэффициент ослабления:	<#> дБ/100 м — 125 кГц (макс.) <#> дБ/100 м — 250 кГц (макс.) <#> дБ/100 м — 500 кГц (макс.)

Таблица 27

Профиль кабеля: спецификации на пару питания постоянным током

Физическая характеристика	Спецификация
Размер пары проводов	Размер/материал жил
Диаметр по изоляции	<#>
Цвета — (B+, B-)
Витая пара	<#>/расстояние
Пара с экраном из металлической ленты	материал
Электрическая характеристика	Спецификация
DCR — 20 °C	<#> Ом/1000 м (макс.)

Таблица 28

Профиль кабеля: общие спецификации

Физическая характеристика	Спецификация
Геометрия
Общий экран в виде оплетки	<#> % покрытие, <#> материал
Провод заземления	Материал жил
Внешний диаметр	Мин. размер — макс., размер
Округлость	Радиус схемы соединения <#> % внешнего диаметра
Маркировка защитной оболочки проводника	Наименование изготовителя, часть <#> и дополнительные маркировки
Электрическая характеристика	Спецификация
DCR — (оплетка + лента + заземление) 20 °C	<#> Ом/1000 м (макс.)
Подходящая характеристика окружающей среды	Спецификация
Сертификация, проводимая специализированным органом
Изгиб	<#> циклов при радиусе изгиба, <#> степеней, <#>, <#> усилие отрыва, <#> циклов/мин, метод
Рабочая температура окружающей среды	<#> °C — <#> °C
Температура хранения	<#> °C — <#> °C
Усилие отрыва	<#> кг
Совместимость разъемов	Открытый, мини, микро, ..., ...
Совместимость соединений	Магистральные, отводные ...
Уникальная характеристика	Специализированное применение

Таблица 29

Профиль кабеля: топология сети

Скорость передачи данных	Минимальное расстояние кабелей	Замена магистральной линии (толстый кабель)	Накапливающий отвод	Максимальный отвод
125 кбит/с	<#> м	<#>	<#> м	<#> м
250 кбит/с	<#> м	<#>	<#> м	<#> м
500 кбит/с	<#> м	<#>	<#> м	<#> м

Важное замечание: мин. и макс. длины могут зависеть от разъема DCR, поэтому при определении макс. и мин. длин нового кабеля учитывают разъем DCR.

8.2.3 Профиль толстого кабеля

В настоящем подразделе приведены следующие спецификации (технические описания) для тонкого кабеля:

- спецификации на пары для передачи данных, см. таблицу 30;

- спецификации на пары питания постоянным током, см. таблицу 31;

- общие спецификации, см. таблицу 32;

- топология сети, см. таблицу 33;

- физическая конфигурация, см. рисунок 51;

- предусмотренный ток шины, см. таблицу 34 и рисунок 52.

Таблица 30

Толстый кабель: спецификации на пару для передачи данных

Физическая характеристика	Спецификация
Размер пары проводника	0,823 мм2, медные (по отдельности луженные)
Диаметр по изоляции	3,81 мм (номинальный)
Цвета	Светло-голубой, белый
Витая пара/м	10 (приблиз.)
Поясной экран вокруг пары	0,05 мм/0,025 мм, Al/майлар Боковина AL с перекрывающим сгибом (применяется натягивание)
Помеха	120 Ом +/- 10% (при 1 МГц)
Задержка распространения	4,46 нс/м (макс.)
Емкость между проводниками	39 пФ/м при 1 кГц (номинальный)
Емкость между одним и другим проводником, присоединенным к экрану	79 пФ/м при 1 кГц
Емкостная асимметрия	3,9 пФ/м при 1 кГц
DCR — 20 °C	Номинальный 18 Ом/1000 м Максимальный 23 Ом/1000 м
Коэффициент ослабления:	0,43 дБ/100 м при 125 кГц 0,82 дБ/100 м при 500 кГц 1,31 дБ/100 м при 1 кГц

Таблица 31

Толстый кабель: спецификации на пару питания постоянным током

Физическая характеристика	Спецификация
Размер пары проводов	1,65 мм2, медные (по отдельности луженные)
Диаметр по изоляции	2,49 мм (номинальный)
Цвета	Красный, черный
Витая пара/м	\approx 10
Пара с экраном из металлической ленты	0,025 мм/0,025 мм, Al/майлар Боковина AL с перекрывающим сгибом (применяется натягивание)
Электрическая характеристика	Спецификация
DCR — 20 °C	Максимум 12 Ом/1000 м

Таблица 32

Толстый кабель: общие спецификации

Физическая характеристика	Спецификация
Геометрия	Две экранированные пары, одна ось с шиной заземления в центре
Общий экран в виде оплетки	65% покрытие, 0,126 мм, 0,126 мм оплетки из меди (по отдельности луженные)
Провод заземления	0,823 мм2 медные (по отдельности луженные)
Внешний диаметр	10,41 мм (мин.) — 12,45 (макс.)
Округлость	Радиус дельта-соединения в пределах 15% от внешнего диаметра
Маркировка защитной оболочки проводника	Наименование изготовителя, часть <#> и дополнительные маркировки
Электрическая характеристика	Спецификация
DCR — (оплетка + лента + заземление)	5,74 Ом/км (ном. 20 °C)
Характеристика: Подходящие условия окружающей среды	Спецификация
Сертификация, проводимая специальным органом (США и Канады)	тип NEC (UL), CL2/CL3 (мин.)
Изгиб	2000 циклов при радиусе изгиба, 90°, 0,91 кг. Усилие отрыва, 15 циклов в минуту, метод Tic Toc или метод C track
Радиус сгиба	20 x диаметр (установка)/7 x диаметр (в зафиксированном положении)
Рабочая температура окружающей среды	От минус 20 °C до плюс 60 °C, 8 А; сниженный номинальный ток
Линейно до нуля — 80 °C
Температура хранения	От минус 40 °C до плюс 85 °C
Усилие отрыва	86 кг, макс.
Совместимость разъемов	Мини, открытый
Совместимость соединений	Магистральная, отводная

Таблица 33

Толстый кабель: топология сети

Скорость передачи данных	Минимальное расстояние кабелей	Замена магистральной линии (толстый кабель)	Накапливающий отвод	Максимальный отвод
125 кбит/с	500 м	1,0	156 м	6 м
250 кбит/с	250 м	1,0	78 м	6 м
500 кбит/с	100 м	1,0	39 м	6 м

Рисунок 51 — Толстый кабель: физическая конфигурация

Таблица 34

Толстый кабель: максимально допустимый ток (А) с учетом протяженности сети

Длина сети, м	0	25	50	100	150	200	250	300	350	400	450	500
Максимальный ток, А	8,00	8,00	5,42	2,93	2,01	1,53	1,23	1,03	0,89	0,78	0,69	0,63

Рисунок 52 — Толстый кабель: максимально допустимый ток (А) на силовой шине DeviceNet

Значения, приведенные в таблице 34 и рисунке 52, рассчитывают по формуле:

I = 4,65 В/((кабель DCR x длину сети) + (контакт DCR x x количество контактов)),

где кабель DCR = 0,146 Ом/м,

контакт DCR = 0,001 Ом, и

количество контактов = 128 (т.к. у каждого ответвителя по два контакта, соединенных последовательно).

Кабель DCR определяют по температуре окружающей среды 80 °C и температурному коэффициенту 0,003 93 на °C.

8.2.4 Профиль тонкого кабеля

В данный раздел включены следующие спецификации для тонкого кабеля:

- спецификации на пары передачи данных, см. таблицу 35;

- спецификации пары питания постоянным током, см. таблицу 36;

- общие спецификации, см. таблицу 37;

- топология сети, см. таблицу 38;

- физическая конфигурация, см. рис. 53;

- предусмотренный ток шины, см. таблицу 34 и рисунок 52.

Таблица 35

Тонкий кабель: спецификации на пары для передачи данных

Физическая характеристика	Спецификация
Размер пары проводника	0,205 мм2, медные; не менее 19 жил (по отдельности луженных)
Диаметр по изоляции	1,96 мм (номинальный)
Цвета	Светло-голубой, белый
Витая пара/м	16 (приблиз.)
Поясной экран вокруг пары	0,025 мм/0,025 мм, Al/майлар
Боковина AL с перекрывающим сгибом (применяется натягивание)
Электрическая характеристика	Спецификация
Помеха	120 Ом +/- 10% (при 1 МГц)
Задержка распространения	4,46 нс/м (макс.)
Емкость между проводниками	39 пФ/м при 1 кГц (номинальный)
Емкость между одним проводником и другим проводником, присоединенным к экрану	79 пФ/м при 1 кГц
Емкостная асимметрия	3,9 пФ/м при 1 кГц
DCR — 20 °C	Номинальный 69 Ом/1000 м Максимальный 92 Ом/1000 м
Коэффициент ослабления:	0,95 дБ/100 м при 125 кГц 1,6 дБ/100 м при 500 кГц 2,3 дБ/100 м при 1 кГц

Таблица 36

Тонкий кабель: спецификации на пару питания постоянным током

Физическая характеристика	Спецификация
Размер пары проводника	0,326 мм2, медные; минимум 19 жил (по отдельности луженных)
Диаметр по изоляции	1,4 мм (номинальный)
Цвета	Красный, черный
Витая пара/м	\approx 16
Пара с экраном из металлической ленты	0,025 мм/0,025 мм, Al/майлар Боковина AL с перекрывающим сгибом (применяется натягивание)
Электрическая характеристика	Спецификация
DCR — 20 °C	57,4 Ом/км

Таблица 37

Тонкий кабель: общие спецификации

Физическая характеристика	Спецификация
Геометрия	Две экранированные пары, одна ось с проводом заземления в центре
Общий экран в виде оплетки	Покрытие 65%, мин. 0,12 мм, луженая медная (Cu) оплетка (по отдельности луженные)
Провод заземления	0,326 мм2, мин. 19 жил (по отдельности луженные)
Внешний диаметр	6,1 мм (мин.) — 7,1 (макс.)
Округлость	Радиус дельта-соединения в пределах 25% от 0,5 внешнего диаметра
Маркировка оболочки	Наименование изготовителя, часть <#> и дополнительные маркировки
Электрическая характеристика	Спецификация
DCR — (оплетка + лента + заземление)	10,5 Ом/1000 м (ном. 20 °C)
Характеристика: Достаточные условия окружающей среды	Спецификация
Сертификация, проводимая специальным органом (США и Канады)	NEC (UL), тип CL2 (мин.)
Изгиб	2000 циклов при радиусе изгиба, 90°, 0,91 кг, 15 циклов в мин., метод Tic Toc или метод C track
Радиус сгиба	20 x диаметр (установка)/7 x диаметр (в зафиксированном положении)
Рабочая температура окружающей среды	От минус 20 °C до плюс 70 °C, 1,5 А; сниженный линейно номинальный ток до нуля при 80 °C
Температура хранения	От минус 40 °C до плюс 85 °C
Усилие отрыва	29,5 кг макс.
Совместимость разъемов	Мини, макро, открытый
Совместимость соединений	Магистральная, отводная

Таблица 38

Толстый кабель: топология сети

Скорость передачи данных	Минимальное расстояние кабелей	Замена магистральной линии (толстый кабель)	Накапливающий отвод	Максимальный отвод
125 кбит/с	100 м	5,0	156 м	6 м
250 кбит/с	100 м	2,5	78 м	6 м
500 кбит/с	100 м	1,0	39 м	6 м

Рисунок 53 — Тонкий кабель: физическая конфигурация

Таблица 39

Тонкий кабель: максимально допустимый ток (А) с учетом длины сети

Длина сети, м	0	10	20	30	40	50	60	70	80	90	100
Максимальный ток, А	3,00	3,00	3,00	2,06	1,57	1,26	1,06	0,91	0,80	0,71	0,64

Рисунок 54 — Толстый кабель: максимально допустимый ток (А) на силовой шине DeviceNet

Таблица 39 и рисунок 54 рассчитываются по формуле:

I = 4,65 В/((кабель DCR x длину сети) +

• (контакт DCR x количество контактов)),

где кабель DCR = 0,070 9 Ом/м;

контакт DCR = 0,001 Ом; и

количество контактов = 128 (т.к. у каждого ответвителя по два контакта, соединенных последовательно).

Кабель DCR определяют по температуре окружающей среды 80 °C и температурному коэффициенту 0,003 93 на градус Цельсия.

8.2.5 Профиль плоского кабеля

В данный раздел включены следующие спецификации для плоского кабеля:

• спецификации на пары передачи данных, см. таблицу 40;
• спецификации на пары питания постоянным током, см. таблицу 41;
• общие спецификации, см. таблицу 42;
• топология сети, см. таблицу 43;
• физическая конфигурация, см. рисунок 55;
• предусмотренный ток шины, см. таблицу 44 и рисунок 56.

Таблица 40

Плоский кабель: спецификации на пары для передачи данных

Физическая характеристика	Спецификация
Размер пары проводника	1,31 мм2, медные (мин.); 19 мин. жил (по отдельности луженных)
Диаметр по изоляции	2,79 мм (номинальный)
Цвета	Светло-голубой, белый
Витая пара/м	Не применяется
Поясной экран вокруг пары	Не применяется
Электрическая характеристика	Спецификация
Помеха	120 Ом +/- 10% (при 500 МГц)
Задержка распространения	5,25 нс/м (макс.)
Емкость между проводниками	48,2 пФ/м при 500 кГц (макс.)
Емкость между одним проводником и другим проводником, присоединенным к экрану	Не применяется
Емкостная асимметрия	3,9 пФ/м при 500 кГц (макс.), ASTM D4566-94
DCR — 20 °C	16,1 Ом/км (макс.)
Коэффициент ослабления:	0,43 дБ/100 м при 125 кГц 0,82 дБ/100 м при 250 кГц 1,31 дБ/100 м при 500 кГц

Таблица 41

Плоский кабель: спецификации на пару питания постоянным током

Физическая характеристика	Спецификация
Размер пары проводника	1,31 мм2 (мин.); 19 мин. жил (по отдельности луженных)
Диаметр по изоляции	2,8 мм (номинальный)
Цвета	Красный, черный
Витая пара/м	Не применяется
Поясной экран вокруг пары	Не применяется
Электрическая характеристика	Спецификация
DCR — 20 °C	16,1 Ом/км (макс.)

Таблица 42

Плоский кабель: общие спецификации

Физическая характеристика	Спецификация
Геометрия	Не применяется
Общий экран в виде оплетки	Не применяется
Провод заземления	Не применяется
Внешний диаметр	См. рисунок 55
Округлость	Не применяется
Маркировка оболочки	Наименование изготовителя, часть <#> и дополнительные маркировки
Электрическая характеристика	Спецификация
DCR — (оплетка + лента + заземление)	Не применяется
Характеристика: Подходящие условия окружающей среды	Спецификация
Сертификация, проводимая специальным органом (США и Канады)	NEC (UL), тип CL2 (мин.)
Изгиб	1,0 М циклов при радиусе сгиба, 90 °, 0,91 кг, 15 циклов в минуту, метод Tic Toc или метод C track
Радиус сгиба	20 x диаметр (установка)/7 x диаметр (в зафиксированном положении)
Рабочая температура окружающей среды	От минус 20 °C до плюс 70 °C, 1,5 А; сниженный линейно номинальный ток до нуля при 80 °C
Температура хранения	От минус 40 °C до плюс 85 °C
Усилие отрыва	29,5 кг макс.
Совместимость разъемов	Мини, макро, открытый
Совместимость соединений	Магистральная, отводная

Таблица 43

Толстый кабель: топология сети

Скорость передачи данных	Минимальное расстояние кабелей	Замена магистральной линии (толстый кабель)	Накапливающий отвод	Максимальный отвод
125 кбит/с	100 м	5,0	156 м	6 м
250 кбит/с	100 м	2,5	78 м	6 м
500 кбит/с	100 м	1,0	39 м	6 м

Рисунок 55 — Плоский кабель: физическая конфигурация

Таблица 44

Плоский кабель: максимально допустимый ток (А) с учетом длины сети

Длина сети, м	0	12,5	25	50	100	150	200	250	300	350	400	420
Максимальный ток, А	8,00	8,00	8,00	5,65	2,86	1,91	1,44	1,15	0,96	0,82	0,72	0,69

Рисунок 56 — Плоский кабель: допустимый ток на силовой шине DeviceNet

Таблицу 44 и рис. 56 рассчитывают по формуле:

I = 4,65 В/((кабель DCR x длину сети) +

• (контакт DCR x количество контактов)),

где кабель DCR = 0,016 1 Ом/м;

контакт DCR = 0,010 Ом; и

количество контактов = 2 (т.к. в комплексе ответвителей плоской среды не предусмотрено последовательное соединение контактов DCR).

Кабель DCR определяют по температуре окружающей среды 20 °C.

8.3 Оконечные резисторы

Металлопленочный резистор (121 Ом, 1%, 0,25 Вт) должен быть подключен на обоих концах магистральной линии.

Оконечные резисторы не должны быть встроены в элементы.

8.4 Разъемы

8.4.1 У всех разъемов должно быть пять выводов: сигнальная пара, силовая пара и экран. Разъемы должны быть либо открытого, либо герметичного типа.

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

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

Любой разъем DeviceNet должен отвечать следующим минимальным требованиям:

• все скользящие контакты должны быть позолоченными;
• минимальное рабочее напряжение в 25 В;
• номинальное сопротивление контактов не менее чем 1 мОм и не менее 5 мОм в течение срока службы.

8.4.2 Шаблон профиля разъема

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

Таблица 45

Шаблон профиля разъема

Общая характеристика вилочной части	Спецификация
Количество контактов	<#>
Стяжная гайка	<Вилочная часть/розеточная часть/отсутствует>
Резьба стяжной гайки
Вращение	<Требуется/не обязателен>
Стандарт
Разводка контактов	Отвод: Контакт #, B+: Контакт #, B-: Контакт #, CAN_H: Контакт #, CAN_L: Контакт #
Общая характеристика розеточной части	Спецификация
Количество контактных гнезд	<#>
Стяжная гайка	<Вилочная часть/розеточная часть/отсутствует>
Резьба стяжной гайки
Угол поворота	<Требуется/не обязателен>
Стандарт
Разводка контактов	Заземление: Контакт #, B+: Контакт #, B-: Контакт #, CAN_H: Контакт #, CAN_L: Контакт #
Физическая характеристика	Спецификация
Скользящий контакт Требования к покрытию
Срок службы скользящего контакта	Кол-во <#> вставок и извлечений
Характеристика по электротехнической части	Спецификация
Рабочее напряжение	Мин. <#> В
Допустимая мощность на контактах	Мин. <#> А
Сопротивление контакта	Номинальное: менее <#> мОм Макс.: <#> мОм в течение срока службы
Характеристика с учетом окружающей среды	Спецификация
Водостойкость	IPXX (по IEC 60529) и NEMA <#>
Маслостойкость
Рабочая температура окружающей среды	<#> °C — <#> °C
Температура хранения	<#> °C — <#> °C

8.4.3 Профиль открытого разъема

В таблице 46 представлен профиль открытого разъема, а разводка и схема размещения контактов представлены на рисунке 57 и рисунке 58.

Таблица 46

Открытый разъем

Общая характеристика вилочной части	Спецификация
Количество контактов	5
Стяжная гайка	Отсутствует
Резьба стяжной гайки	Отсутствует
Угол поворота	Отсутствует
Стандарт	Схему интерфейса см. рис. 57
Разводка контактов	B-: Контакт 1, CAN_L: Контакт 2, заземление: Контакт 3, CAN_H: Контакт 4, B+: Контакт 5
Общая характеристика розеточной части	Спецификация
Количество контактных гнезд	5
Стяжная гайка	Отсутствует
Резьба стяжной гайки	Отсутствует
Вращение	Отсутствует
Стандарт	Схему интерфейса см. рис. 58
Разводка контактов	B-: Контакт 1, CAN_L: Контакт 2, заземление: Контакт 3, CAN_H: Контакт 4, B+: Контакт 5
Физическая характеристика	Спецификация
Скользящий контакт Требования к покрытию	Мин. 0,76 мкм золота на мин. 1,3 мкм никеля или мин. 0,13 мкм золота на мин. 0,51 мкм палладия-никеля, мин. на 1,3 мкм. Золото — 24 карата
Срок службы скользящего контакта	100 вставок и извлечений
Характеристика по электротехнической части	Спецификация
Рабочее напряжение	Мин. 25 V
Допустимая мощность на контактах	Мин. 8 А
Сопротивление контакта	Номинальное: менее 1 мОм Макс.: 5 мОм в течение срока службы
Характеристика с учетом окружающей среды	Спецификация
Водостойкость	Отсутствует
Маслостойкость	Отсутствует
Рабочая температура окружающей среды	От минус 40 °C до плюс 70 °C на полной мощности при линейном снижении до 0 А при 80 °C
Температура хранения	От минус 40 °C до плюс 85 °C

Рисунок 57 — Разводка контактов сетевого разъема

Рисунок 58 — Геометрия открытого разъема

8.4.4 Профиль герметичного мини-разъема

В таблице 47 приведен профиль открытого разъема, а разводка контактов показана на рисунке 59.

Таблица 47

Герметичный мини-разъем

Общая характеристика вилочной части	Спецификация
Количество контактов	5
Стяжная гайка	Штепсельная часть
Резьба стяжной гайки	7/8-16 UN-2A THD
Вращение	Не обязательно
Стандарт	Соответствие стандарту ANSI/B93.55M-1981
Разводка контактов	Заземление: Контакт 1, B+: Контакт 2, B-: Контакт 3, CAN_H: Контакт 4, CAN_L: Контакт 5
Общая характеристика розеточной части	Спецификация
Количество контактных гнезд	5
Стяжная гайка	Гнездовая часть
Резьба стяжной гайки	7/8-16 UN-2B THD
Вращение	Требуется
Стандарт	Соответствие стандарту ANSI/B93.55M-1981
Разводка контактов	Заземление: Контакт 1, B+: Контакт 2, B-: Контакт 3, CAN_H: Контакт 4, CAN_L: Контакт 5
Физическая характеристика	Спецификация
Скользящий контакт Требования к покрытию	Мин. 0,76 мкм золота на мин. 1,3 мкм никеля или мин. 0,13 мкм золота на мин. 0,51 мкм палладия-никеля, мин. на 1,3 мкм никеля. Золото — 24 карата
Срок службы скользящего контакта	1000 вставок и извлечений
Характеристика по электротехнической части	Спецификация
Рабочее напряжение	Мин. 25 В
Допустимая мощность на контактах	Мин. 8 А
Сопротивление контакта	Номинальное: менее 1 мОм Макс.: 5 мОм в течение срока службы
Характеристика с учетом окружающей среды	Спецификация
Водостойкость	IP67 (по IEC 60529) и NEMA 4, 6, 6P, 13
Маслостойкость	UL-1277, OIL RES II
Рабочая температура окружающей среды	От минус 40 °C до плюс 70 °C на полной мощности при линейном снижении до 0 А при 80 °C
Температура хранения	От минус 40 °C до плюс 85 °C

Рисунок 59 — Разводка контактов герметичного мини-разъема

8.4.5 Профиль герметичного микроразъема

В таблице 48 описан профиль открытого разъема, а разводка контактов показана на рисунке 60.

Таблица 48

Герметичный микроразъем

Общая характеристика вилочной части	Спецификация
Количество контактов	5
Стяжная гайка	Вилочная часть
Резьба стяжной гайки	М12 x 1 6G fit
Вращение	Требуется
Стандарт	Соответствие стандарту IEC 60947-5-2 (рисунок D.2)
Разводка контактов	Заземление: Контакт 1, B+: Контакт 2, B-: Контакт 3, CAN_H: Контакт 4, CAN_L: Контакт 5
Общая характеристика розеточной части	Спецификация
Количество контактных гнезд	5
Стяжная гайка	Розеточная часть
Резьба стяжной гайки	М12 x 1 6G fit
Вращение	Не обязательно
Стандарт	Соответствие стандарту IEC 60947-5-2 (рисунок D.2)
Разводка контактов	Заземление: Контакт 1, B+: Контакт 2, B-: Контакт 3, CAN_H: Контакт 4, CAN_L: Контакт 5
Скользящий контакт Требования к покрытию	Мин. 0,76 мкм золота на мин. 1,3 мкм никеля или мин. 0,13 мкм золота на мин. 0,51 мкм палладия-никеля, мин. на 1,3 мкм никеля. Золото — 24 карата
Срок службы скользящего контакта	1000 вставок и извлечений
Характеристика по электротехнической части	Спецификация
Рабочее напряжение	Мин. 25 В
Допустимая мощность на контактах	Мин. 8 А
Сопротивление контакта	Номинальное: менее 1 мОм Макс.: 5 мОм в течение срока службы
Характеристика с учетом окружающей среды	Спецификация
Водостойкость	IP67 (по IEC 60529) и NEMA 4, 6, 6P, 13
Маслостойкость	UL-1277, OIL RES II
Рабочая температура окружающей среды	От минус 40 °C до плюс 70 °C на полной мощности при линейном снижении до 0 А при 80 °C
Температура хранения	От минус 40 °C до плюс 85 °C

Рисунок 60 — Разводка контактов микроразъема

8.4.6 Профиль плоского разъема магистральной линии

В таблице 49 описан профиль плоского разъема магистральной линии, а разводка и схема размещения контактов показаны на рисунке 61 и рисунке 62.

Таблица 49

Плоский разъем магистральной линии

Общая характеристика вилочной части	Спецификация
Количество контактов	4
Стяжная гайка	(не обязательно: удержание при помощи болта с резьбой \#8 \times 1 \frac{3}{4} )
Резьба стяжной гайки	(UNC 32)
Вращение	Отсутствует
Стандарт	См. рисунок 61
Разводка контактов	CAN_L: Контакт 1, CAN_H: Контакт 2, B+: Контакт 3, B-: Контакт 4
Общая характеристика розеточной части	Спецификация
Количество контактных гнезд	4
Стяжная гайка	(не обязательно: удержание при помощи вставки или гайки \#8 \times 1 \frac{3}{4} )
Резьба стяжной гайки	(UNC 32)
Вращение	Отсутствует
Стандарт	См. рис. 61
Разводка контактов	CAN_L: Контакт 1, CAN_H: Контакт 2, B+: Контакт 3, B-: Контакт 4
Физическая характеристика	Спецификация
Скользящий контакт Требования к покрытию	Минимум 0,20 мкм золотого покрытия на минимум 1,27 мкм никеля. Золото — 24 карата
Срок службы скользящего контакта	100 вставок и извлечений
Характеристика по электротехнической части	Спецификация
Рабочее напряжение	Мин. 25 В
Допустимая мощность на контактах	Мин. 3 А
Сопротивление контакта	Номинальное: менее 1 мОм Макс.: 5 мОм в течение срока службы
Характеристика с учетом окружающей среды	Спецификация
Водостойкость	IP67 (по IEC 60529) и NEMA 4, 6, 6P, 13
Маслостойкость	UL-1277, OIL RES II
Рабочая температура окружающей среды	От минус 40 °C до плюс 70 °C на полной мощности при линейном снижении до 0 А при 80 °C
Температура хранения	От минус 40 °C до плюс 85 °C

Рисунок 61 — Схема плоского разъема магистральной линии — разводка контактов

Рисунок 62 — Схема плоского разъема магистральной линии — геометрия

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

8.5 Ответвители устройств и силовые ответвители

8.5.1 Ответвители устройств

Ответвители устройств обеспечивают точки присоединения на магистральную линию. Устройства могут быть подключены к каналу связи, либо напрямую к ответвителю устройства или через отводную линию. Ответвители устройств должны также позволять снимать устройство, не мешая при этом работе CDI.

Ответвители устройств должны иметь рабочее напряжение в 25 В при постоянном токе и должны соответствовать спецификациям, приведенным в таблицах 50 и 51.

Таблица 50

Спецификации на внутренний транзитный проводник

Описание проводника	Спецификация
Проводник с заземляющим проводом	Максимальная длина проводника 100 мм. Максимальное сопротивление 2,3 Ом
Силовой провод B+ и B-	Максимальная длина проводника 100 мм. Максимальное сопротивление 1,2 Ом. Номинальный ток 8 А
Проводник сигналов CAN_H и CAN_L	Максимальная длина проводника 100 мм. Максимальное сопротивление 2,3 Ом

Таблица 51

Спецификации на внутренний ответвительный проводник

Описание проводника	Спецификация
Проводник с заземляющим проводом	Максимальная длина проводника 180 мм и максимальное сопротивление 10 мОм, оба измеренные между ответвительным проводником магистральной линии и любым портом соединения
Силовой провод B+ и B-	Максимальная длина проводника 180 мм, измеренная между ответвительным проводником магистральной линии и любым портом соединения. Максимальное сопротивление 10 мОм для проводников ном. значением до 3 А, 4 мОм. В противном случае оба измеренные между ответвительным проводником магистральной линии и любым портом соединения
Проводник сигналов CAN_H и CAN_L	Максимальная длина проводника 180 мм максимальное сопротивление 10 мОм, оба измеренные между ответвительным проводником магистральной линии и любым портом соединения

8.5.2 Силовые ответвители

Силовой ответвитель соединяет источник питания с магистральной линией. При соединении с сетью силовой ответвитель должен обеспечивать непрерывное соединение сигнальных, заземляющих и B- проводов.

Силовой ответвитель может также обеспечивать следующее:

• защиту от избыточного тока в каждом направлении от ответвителя;
• защиту источника питания при использовании нескольких источников питания;
• соединение с экранированным/заземляющим проводом для заземления линии связи.

Силовые ответвители DeviceNet должны иметь минимальное номинальное напряжение 25 В постоянного тока и должны соответствовать спецификациям, указанным в таблицах 52 и 53.

Таблица 52

Спецификации на внутренний транзитный проводник

Описание проводника	Спецификация
Проводник с заземляющим проводом	Максимальная длина проводника 180 мм. Максимальное сопротивление 4,1 Ом
Силовой провод B-	Максимальная длина проводника 180 мм. Максимальное сопротивление 2,1 Ом. Номинальный ток 8 А
Проводник сигналов CAN_H и CAN_L	Максимальная длина проводника 180 мм. Максимальное сопротивление 4,1 Ом

Таблица 53

Спецификации на внутренний ответвительный силовой проводник

Описание проводника	Спецификация
Проводник с заземляющим проводом для заземляющего вывода	Максимальная длина проводника 180 мм и максимальное сопротивление 2,1 мОм, оба измеренные между любым ответвительным разъемом и заземляющим выводом
Силовые проводники B+ и B-	Максимальная длина проводника 300 мм и максимальное сопротивление 3,6 мОм, оба измеренные между любым ответвительным разъемом и портом соединения источника питания. Провода должны быть способны нести рабочий ток

Силовые ответвительные разъемы (кроме разъема источника питания) должны отвечать требованиям, указанным в 8.4.

8.6 Устройства, питаемые от канала связи

Устройства могут питаться от канала связи. Такие устройства должны использовать регулятор напряжения с входным напряжением в диапазоне от 11 В до 25 В постоянного тока и иметь встроенную защиту и фильтры.

Регулятор напряжения должен соответствовать спецификациям, указанным в таблице 54.

Таблица 54

Спецификации на регулятор напряжения

Спецификация	Параметр
Диапазон входного напряжения	11 В пост. тока — 25 В пост. тока
Изоляция (если требуется)	500 В
Задержка включения питания	Линейные регуляторы: отсутствуют Регуляторы переключения режима: < 100 мА 2 мс — 10 мс 0,1 А — 0,5 А 5 мс — 15 мс 0,5 А — 1 А 10 мс — 20 мс 1 — 2 А 15 мс — 30 мс > 2 А 20 мс — 40 мс
Защита от выходного КЗ	Предельный ток
Защита от обратной полярности	Выпрямитель в нулевом проводнике a
a Если выпрямитель используется для питания трансивера, он должен иметь прямое напряжение не более 0,6 В.

8.7 Защита от неправильной схемы разводки пар в кабеле

Устройства должны быть способны выдерживать неправильное соединение, не подвергаясь повреждению, при следующих условиях:

• перепутанное соединение проводников B+ с B-;
• соединение заземляющего провода с любым другим проводником;
• подключение CAN_H и/или CAN_L к напряжению, не превышающему диапазон от минус 25 В постоянного тока до плюс 18 В постоянного тока.

Спецификации см. в 9.2.4 и 9.2.5.

8.8 Источники питания

Питание, получаемое от сети, должно соответствовать спецификациям, указанным в таблице 55 (см. 9.2.1).

Таблица 55

Спецификации на источник питания DeviceNet

Спецификация	Параметр
Номинальное напряжение при 20 °C	24 В постоянного тока +/- 1% или корректируется до 0,2%
Стабилизация выходного напряжения в сети	0,3% макс. свыше диапазона, указанного изготовителем
Регулирование нагрузки	0,3% макс.
Температурный коэффициент	0,03% на К макс.
Пульсация выходного сигнала	250 мВ полный размах сигнала
Нагрузочная способность	7000 мкФ макс.
Защита от чрезмерного тока	100% — 125% номинального тока
Время нарастания выходного напряжения (с полной нагрузкой)	250 мс макс. до 95% конечного значения 0
Выброс напряжения при включении	0,2% макс.
Стабильность	нагрузка 0% — 100% (все условия)
Изоляция	Мощность, изолированная от входного напряжения и массы при заземлении

8.9 Электромагнитная совместимость (ЭМС)

8.9.1 Общие положения

Все испытания на помехоустойчивость и излучение являются испытаниями типа и должны проводиться в специальных условиях, как эксплуатационных, так и условиях окружающей среды, с использованием установленных способов электромонтажа и включая все оборудование, необходимое для соединения и передачи данных на кабеле DeviceNet (см. 9.2.10 для испытательных спецификаций).

Это требование должно соблюдаться при использовании двух устройств с непрерывным I/O соединением и одним источником питания.

8.9.2 Помехоустойчивость

8.9.2.1 Функциональные критерии

Результаты испытания определяются с использованием следующих функциональных критериев:

• критерий A: Прибор должен продолжать работать надлежащим образом во время и после испытания. Любая потеря функциональности, как приведено в таблице 56, должна означать сбой в работе;
• критерий B: Во время испытания не допускается никакого изменения фактического рабочего состояния или запоминаемых данных, любая потеря функциональности, как показано в таблице 56, должна означать сбой в работе. Прибор должен продолжать работать надлежащим образом после испытания.

Таблица 56

Функциональные критерии помехоустойчивости

Тип функционирования	Критерий A	Критерий B
Ведущие устройства (процессоры и адаптеры)	Сбой программы	Сбой программы
	Отказ памяти	Отказ памяти
	I/O переустановка	I/O переустановка
	Искажение табличных данных	Искажение табличных данных
Любой модуль	Непреднамеренная операция	Непреднамеренная операция
	Блокировка	Блокировка
	Вмешательство оператора	Вмешательство оператора
	Поломка	Поломка
Внешние коммуникации	Офлайн-узел	Офлайн-узел
Внутренние коммуникации
- излучаемые, кондуктивные	> 1 набора битов ошибки/10 передач (кадров)
- кратковременные электрический бросок		> 1 набора битов ошибки/10 передач (кадров)
- ESD (Устойчивость к электростатическому разряду)		Блокировка
- Выброс напряжения в сети		Блокировка

8.9.2.2 Устойчивость к электростатическому разряду

SDIs DeviceNet должны соответствовать требованиям, указанным в IEC 62026-1 (пункт 8.2.1).

8.9.2.3 Устойчивость к излучаемому радиочастотному полю

SDIs DeviceNet должны соответствовать требованиям, указанным в IEC 62026-1 (пункт 8.2.1).

8.9.2.4 Устойчивость к кратковременному выбросу напряжения/пачкам импульсов

SDIs DeviceNet должны соответствовать требованиям, указанным в IEC 62026-1 (пункт 8.2.1), за исключением DC I/O портов, которые должны испытываться при +/- 1 кВ.

8.9.2.5 Устойчивость к выбросу напряжения в сети

SDIs DeviceNet должны соответствовать требованиям, указанным в IEC 62026-1 (пункт 8.2.1).

8.9.2.6 Устойчивость к радиочастотным помехам

SDIs DeviceNet должны соответствовать требованиям, указанным в IEC 62026-1 (пункт 8.2.1).

8.9.2.7 Падения напряжения и прерывания питания

Соответствие питания пределам, приведенным в таблице 55, снимает необходимость в проведении каких-либо дальнейших испытаний.

8.9.3 Излучения

8.9.3.1 Обычные излучения

Должны соответствовать CISPR 11, группе 1, классу A.

8.9.3.2 Кондуктивное излучение

Должны соответствовать CISPR 11, группе 1, классу A.

8.10 Дополнительные требования к функциональной безопасности, связанной с ЭМС

DeviceNet Safety CDI должен соответствовать дополнительным требованиям, приведенным в IEC 61784-3-2.

9 Испытания

9.1 Общие положения

В настоящем разделе определены испытания типа для электрических и логических требований. Испытания разделены на две части:

• электрические испытания и испытания ЭМС;

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

9.2 Электрические испытания и испытания ЭМС

9.2.1 Испытание питания DeviceNet

9.2.1.1 Цель испытания

Следующие испытания подтверждают соответствие требованиям к питанию, являющиеся специфическими для DeviceNet.

9.2.1.2 Время нарастания сигнала выходного напряжения питающего тока

9.2.1.2.1 Испытательная цепь

Используют испытательную цепь, изображенную на рисунке 63. Выбирают балластный резистор (R) для гарантии того, что подача питания осуществляется на номинальном токе.

9.2.1.2.2 Процедура испытания

Осциллограф, подключенный через балластный резистор, должен быть установлен на 24 В, полную шкалу 500 мс. ИО должно быть включено и время нарастания сигнала от начала нарастания напряжения до 95% конечного напряжения подачи питания пуска должно быть записано.

9.2.1.2.3 Критерии соответствия

Время нарастания сигнала должно быть меньше чем или равно 250 мс (см. таблицу 55).

9.2.1.3 Пульсация питающего тока

9.2.1.3.1 Испытательная цепь

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

9.2.1.3.2 Процедура испытания

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

9.2.1.3.3 Критерии соответствия

Чтобы соответствовать требованиям питающего тока, размах напряжения пульсаций должен быть меньше чем или равным 250 мВ (см. таблицу 55).

9.2.2 Потребление пикового тока устройством

9.2.2.1 Испытательная цепь

Испытательная цепь должна соответствовать цепи, изображенной на рисунке 64.

9.2.2.2 Процедура испытания

9.2.2.3 Критерии соответствия

9.2.3 Режим работы устройства при включении питания

9.2.3.1 Цель испытания

9.2.3.2 Испытательная цепь

9.2.3.3 Процедура испытания

9.2.3.4 Критерии соответствия

9.2.4 Обратное соединение

9.2.4.1 Цель испытания

9.2.4.2 Испытательная цепь

9.2.4.3 Процедура испытания

Вывод B+ испытываемого оборудования должен быть соединен с B- источника питания и линией связи, а вывод B- испытываемого оборудования должен быть соединен с B+ источника питания и линией связи. Необходимо наблюдать за CAN_H и CAN_L.

9.2.4.4 Критерии соответствия

Должно быть подтверждено, что сигналы CAN_H и CAN_L остаются в пределах, указанных в таблицах 23 и 24.

9.2.5 Разъединение B-

9.2.5.1 Цель испытания

Целью настоящего испытания является подтверждение соответствия требованиям к защите от неправильной проводки.

9.2.5.2 Испытательная цепь

Испытательная цепь должна соответствовать приведенной на рисунке 66.

9.2.5.3 Процедура испытания

Соединение B- на испытываемом оборудовании должно быть отсоединено.

9.2.5.4 Критерии соответствия

Должно быть подтверждено, что сигналы CAN_H и CAN_L остаются в пределах, указанных в таблицах 23 и 24.

9.2.6 Испытание на дифференциальное входное полное сопротивление

9.2.6.1 Цель испытания

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

9.2.6.2 Испытательная цепь

Испытательная цепь должна быть такой, как изображена на рисунке 67.

Рисунок 67 — Испытательная цепь полного

9.2.6.3 Процедура испытания

ИО должно быть включено в сеть. Трансивер ИО должен отключаться таким образом, чтобы это не влияло на полное сопротивление. Входное полное сопротивление ИО между CAN_H и CAN_L следует измерять на частоте 100 кГц +/- 1 лГц.

9.2.6.4 Критерии соответствия

Полное сопротивление ИО между CAN_H и CAN_L не должно превышать значений, указанных в таблице 22.

9.2.7 Уровни передачи

9.2.7.1 Цель испытания

Целью настоящего испытания является определение того, находятся ли значения CAN_H и CAN_L в отношении B- в наихудших смоделированных условиях полного сопротивления, в указанных пределах, как часть требований к физическому уровню.

9.2.7.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, изображенной на рисунке 68.

9.2.7.3 Процедура испытания

9.2.7.4 Критерии соответствия

9.2.8 Задержка подтверждения

9.2.8.1 Цель испытания

9.2.8.2 Испытательная цепь

9.2.8.3 Процедура испытания

9.2.8.4 Критерии соответствия

В зависимости от используемой скорости бита следующие значения необходимо вычесть из измеренного времени отклика:

• 125 кбит/с 8 мкс;
• 250 кбит/с 4 мкс;
• 500 кбит/с 2 мкс.

Получившееся в результате значение времени подтверждения должно быть меньше чем или равно значению, указанному в 5.7.2.

9.2.9 Испытания CDI

9.2.9.1 Цель испытания

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

9.2.9.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, изображенной на рисунке 72, с указанием следующих пунктов:

• система должна работать на максимальной битовой скорости, поддерживаемой ИО;
• кабельная система должна иметь максимальную длину магистральной линии толстого кабеля, подходящего для этой битовой скорости;
• максимальная кумулятивная линия должна быть из тонкого кабеля, длина которого подходит для этой битовой скорости;
• 62 элемента или 62 аналога элементов должны использоваться для загрузки CDI рядом с ИО.

Примечание — Аналог элемента — это минимальное дифференциальное входное полное сопротивление, как показано в таблице 22;

• должно использоваться такое питание, которое отвечает спецификациям, описанным в таблице 55 (минимальная допустимая токовая нагрузка 4 А);
• силовая нагрузка в сети связи в наихудшем случае должна подключаться рядом с ИО. Эта нагрузка может привести к падению напряжения на B-линии значением 5 В +0,0/-0,1 В от источника питания к ИО;
• испытательная установка должна быть такой, чтобы она была способна как обеспечивать действующий коммуникационный трафик к ИО, так и осуществлять мониторинг всего коммуникационного трафика.

Рисунок 72 — Схема проведения испытания CDI

9.2.9.3 Процедура испытания

Должно быть установлено соединение между испытательной установкой и ИО. Должны быть зарегистрированы любое отсутствие битов подтверждения или условия отключения шины.

9.2.9.4 Критерии соответствия

Зарегистрированные отсутствующие биты подтверждения и условия отключения шины должны соответствовать приведенным изготовителем ИО.

9.2.10 Испытание на электромагнитную совместимость

9.2.10.1 Общие положения

Испытательная цепь должна соответствовать той цепи, которая показана на рисунке 72, с учетом следующих пунктов:

• система должна работать на максимальной битовой скорости, поддерживаемой ИО;
• магистральная линия должна быть изготовлена из толстого кабеля;
• должно использоваться такое питание, которое отвечает спецификациям, описанным в таблице 55 (минимальная допустимая токовая нагрузка 4 А);
• испытательная установка должна быть такой, чтобы она была способна как обеспечивать действующий коммуникационный трафик к ИО, так и осуществлять мониторинг всего коммуникационного трафика.

Если не указано иное, испытания следует проводить при температуре окружающей среды от плюс 23 °C до +/- 5 °C.

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

9.2.10.2 Помехоустойчивость

9.2.10.2.1 Помехоустойчивость к электростатическому разряду (ЭСР)

Настоящее испытание должно проводиться в соответствии с IEC 61000-4-2 и 8.9.2.2.

Длина магистральной линии должна быть как можно короче. ИО должно быть напрямую подключено к магистральной линии, но если это невозможно, то тогда отводная линия не должна превышать 1 м.

9.2.10.2.2 Помехоустойчивость к излучаемому радиочастотному электромагнитному полю

Настоящее испытание должно проводиться в соответствии с IEC 61000-4-2 и 8.9.2.3.

Длина магистральной линии должна быть максимально допустимой (см. 5.7.6.2). ИО должно быть подключено к магистральной линии с использованием отводной линии максимально допустимой длины (см. 5.7.6.3).

9.2.10.2.3 Помехоустойчивость к кратковременному выбросу напряжения/пачкам импульсов

Настоящее испытание проводят в соответствии с IEC 61000-4-4 и 8.9.2.4.

Длина магистральной линии должна быть максимально допустимой (см. пункт 5.7.6.2). ИО должно быть соединено непосредственно с магистральной линией. Если это невозможно, то тогда отводная линия не должна превышать 1 м.

9.2.10.2.4 Устойчивость к броскам тока

Настоящее испытание проводят в соответствии с IEC 61000-4-5 и 8.9.2.5.

Длина магистральной линии должна быть максимально допустимой (см. пункт 5.7.6.2). ИО должно быть соединено непосредственно с магистральной линией. Если это невозможно, то тогда отводная линия не должна превышать 1 м.

9.2.10.2.5 Устойчивость к кондуктивным радиочастотным помехам

Настоящее испытание проводят в соответствии с IEC 61000-4-5 и 8.9.2.6.

Длина магистральной линии должна быть максимально допустимой (см. 5.7.6.2). ИО должно быть соединено непосредственно с магистральной линией. Если это невозможно, то тогда отводная линия не должна превышать 1 м.

9.2.10.3 Излучения

9.2.10.3.1 Радиационные излучения

Настоящее испытание проводят в соответствии с CISPR 11, группой 1, классом A и 8.9.3.1.

Длина магистральной линии должна быть максимально допустимой (см. 5.7.6.2). ИО должно быть соединено непосредственно с магистральной линией с использованием отводной линии максимально допустимой длины (см. 5.7.6.3).

9.2.10.3.2 Кондуктивные излучения

Настоящее испытание проводят в соответствии с CISPR 11, группой 1, классом A и 8.9.3.2.

Длина магистральной линии должна быть минимальной для испытательной установки и не должна превышать максимальной длины, указанной в 5.7.6.2. ИО должно быть соединено непосредственно с магистральной линией с использованием отводной линии максимально допустимой длины (см. 5.7.6.3).

9.3 Логические испытания

9.3.1 Общие положения

Испытания должны проводиться только на узлах, которые поддерживают конкретную испытываемую функциональность.

Логические испытания требуют наличия испытательной установки на интерфейсе между контроллером и прибором, которая:

• посылает сообщения DeviceNet;
• получает и оценивает сообщения DeviceNet;
• регистрирует и помечает время трафика на CDI.

9.3.2 Испытание проверки дубликата ID MAC

9.3.2.1 Цель испытания

Целью настоящего испытания является подтверждение того, что ИО отвечает требованиям, касающимся механизмов обработки ID MAC.

9.3.2.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, показанной на рисунке 73.

Рисунок 73 — Испытательная цепь для логических испытаний

9.3.2.3 Процедура испытания

9.3.2.3.1 Успешная проверка дубликата ID MAC

ID MAC ИО должен быть установлен на 0. К ИО можно применять любое необходимое внешнее питание. Для этого ИО должно быть физически соединено с сетью. Испытательная установка затем должна быть соединена с сетью и должна записывать коммуникационный трафик.

9.3.2.3.2 Неспешная проверка дубликата ID MAC

ID MAC ИО должен быть установлен на 0. К ИО можно применять любое необходимое внешнее питание. Для этого ИО должно быть физически соединено с сетью. Испытательная установка должна отвечать на первое сообщение-запрос проверки дубликата ID MAC с сообщением-откликом проверки дубликата ID MAC.

9.3.2.4 Критерии соответствия

9.3.2.4.1 Успешная проверка дубликата ID MAC

• ИО передает второй запрос о проверке дубликата ID MAC спустя 0,9 с — 1,5 с;
• ИО воспринимает состояние онлайн не раньше, чем за 0,9 с после передачи второго сообщения-запроса о дубликате ID MAC;
• ИО не передает каких-либо других сообщений перед принятием состояния онлайн.

9.3.2.4.2 Неуспешная проверка дубликата ID MAC

ИО должно воспринимать состояние сбоя связи (см. таблицу 12) после получения сообщения-отклика о проверке дубликата ID MAC.

9.3.3 Менеджер сообщений без установления соединения (UCMM)

9.3.3.1 Цель испытания

Целью настоящего испытания является определение соответствия узла, поддерживающего UCMM, требованиям, связанным с генерацией соединений явных сообщений.

9.3.3.2 Испытательная цепь

Испытательная цепь должна соответствовать той цепи, которая изображена на рисунке 73.

9.3.3.3 Процедура испытания

Испытательная установка должна передавать открытое сообщение-запрос с использованием группы 1 сообщений. После открытия этого соединения сообщений явное сообщение должно передаваться через это соединение. Испытательная установка должна передавать закрытое сообщение-запрос UCMM. Испытательная установка должна передавать второе явное сообщение и ожидать отклика в течение 10 с.

Вышеуказанную процедуру необходимо повторять для групп 2 и 3 сообщений.

9.3.3.4 Критерии соответствия

Следует подтвердить, что:

• первое явное сообщение передается и принимается успешно, по крайне мере, в одной группе сообщений;

9.3.4 Размещение предопределенного набора соединений ведущего и ведомого устройств — Соединение для передачи явных сообщений

9.3.4.1 Цель испытания

Целью настоящего испытания является определение соответствия ИО требованиям, связанным с размещением предопределенного набора соединений ведущего и ведомого устройств для соединения в целях передачи явных сообщений.

9.3.4.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, показанной на рисунке 73.

9.3.4.3 Процедура испытания

Испытательная установка должна посылать запрос по размещению предопределенного набора соединений ведущего и ведомого устройств (выбор места размещения = 1). После размещения соединения этого сообщения явное сообщение должно передаваться через это соединение. Испытательная установка должна отменить предопределенный набор соединений ведущего и ведомого устройств (выбор места размещения = 1). Испытательная установка должна передавать второе явное сообщение и ожидать отклика в течение 10 с.

9.3.4.4 Критерии соответствия

• первое явное сообщение передается и принимается так, как определено в предопределенном наборе соединений ведущего и ведомого устройств;
• ИО не передает ответ на второе явное сообщение.

9.3.5 Размещение предопределенного набора соединений ведущего и ведомого устройств — Соединение для передачи сообщений I/O

9.3.5.1 Цель испытания

Целью настоящего испытания является определение соответствия ИО требованиям, связанным с размещением предопределенного набора соединений ведущего и ведомого устройств для соединения в целях передачи сообщений I/O.

9.3.5.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, показанной на рисунке 73.

9.3.5.3 Процедура испытания

Испытательная установка должна посылать запрос по размещению предопределенного набора соединений ведущего и ведомого устройств. После размещения данного соединения для передачи сообщений, сообщение I/O должно передаваться через это соединение. Испытательная установка должна отменить предопределенный набор соединений ведущего и ведомого устройств. Испытательная установка должна передавать второе явное сообщение и ожидать отклика в течение 10 с.

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

9.3.5.4 Критерии соответствия

• первое сообщение I/O передается и принимается так, как определено в предопределенном наборе соединений ведущего и ведомого устройств;

9.3.6 Логические испытания средств безопасности

Дополнительные требования к логическим испытаниям средств безопасности указаны в IEC 61784-3-2.

Приложение ДА (справочное)

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего межгосударственного стандарта
IEC 60529:2013	MOD	ГОСТ 14254-2015 (IEC 60529:2013) «Степени защиты, обеспечиваемые оболочками (Код IP)»
IEC 60947-5-2:2019	-	<*>, <1>
IEC 61000-4-2:2008	MOD	ГОСТ 30804.4.2-2013 (IEC 61000-4-2:2008) «Совместимость технических средств электромагнитная. Устойчивость к электростатическим разрядам. Требования и методы испытаний»
IEC 61000-4-3:2010	IDT	ГОСТ IEC 61000-4-3-2016 «Электромагнитная совместимость (ЭМС). Часть 4-3. Методы испытаний и измерений. Испытание на устойчивость к излучаемому радиочастотному электромагнитному полю»
IEC 61000-4-4:2012	IDT	ГОСТ IEC 61000-4-4-2016 «Электромагнитная совместимость (ЭМС). Часть 4-4. Методы испытаний и измерений. Испытание на устойчивость к электрическим быстрым переходным процессам (пачкам)»
IEC 61000-4-5:2014	IDT	ГОСТ IEC 61000-4-5-2017 «Электромагнитная совместимость (ЭМС). Часть 4-5. Методы испытаний и измерений. Испытание на устойчивость к выбросу напряжения»
IEC 61000-4-6:2013	-	<*>
IEC 61158 (все части)	-	<*>
IEC 61158-4-2:2014	-	<*>
IEC 61158-5-2:2014	-	<*>
IEC 61158-6-2:2014	-	<*>
IEC 61508 (все части)	-	<*>, <2>
IEC 61784-3-2:2010	-	<*>
IEC 62026-1:2007	-	<*>
ISO/IEC 7498-1:1994	-	<*>, <3>
ISO 11898-1:2003	-	<*>, <4>
ISO 11898-2-2003	-	<*>, <5>

---

<1> Действует ГОСТ IEC 60947-5-2-2012 «Аппаратура распределения и управления низковольтная. Часть 5-2. Аппараты и коммутационные элементы цепей управления. Бесконтактные датчики», идентичный IEC 60947-5-2:2007.

<2> Действует ГОСТ IEC 61508-3-2018 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению», идентичный IEC 61508-3:2010.

<3> В Российской Федерации действует ГОСТ Р ИСО/МЭК 7498-1-99 «Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель».

<4> В Российской Федерации действует ГОСТ Р ИСО 11898-1-2015 «Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 1. Канальный уровень и передача сигналов».

<5> В Российской Федерации действует ГОСТ Р ИСО 11898-2-2015 «Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 2. Устройство доступа к высокоскоростной среде».

Окончание таблицы ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего межгосударственного стандарта
CISPR 11:2009	-	<*>, <1>
<*> Соответствующий межгосударственный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта. Примечание — В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов: - IDT — идентичные стандарты; - MOD — модифицированные стандарты.

---

<1> Действует ГОСТ CISPR 11-2017 «Электромагнитная совместимость. Оборудование промышленное, научное и медицинское. Характеристики радиочастотных помех. Нормы и методы испытаний», идентичный CISPR 11:2015.

БИБЛИОГРАФИЯ

[1]	IEC 61131-3:2013	Programmable controllers — Part 3: Programming languages (Контроллеры программируемые. Языки программирования)
[2]	IEC 61784-1:2014	Industrial communication networks — Profiles — Part 1: Fieldbus profiles (Сети связи промышленные. Профили. Часть 1. Профили полевой шины)
[3]	IEC 61784-5-2:2013	Industrial communication networks — Profiles — Part 5-2: Installation of fieldbuses — Installation profiles for CPF 2 (Сети связи промышленные. Профили. Часть 5-2. Установка полевых шин. Профили установки для CPF 2)
[4]	ASTM D 4566-94	Standard Test Methods for Electrical Performance Properties of Insulations and Jackets for Telecommunication Wire and Cable (Стандартные методы испытания электрических эксплуатационных свойств установок и кожухов для телекоммуникационных проводов и кабелей)

УДК 004.31-181.48:621.39(083.74)(476)	МКС 29.130.20	IDT
Ключевые слова: система связи, электромагнитная совместимость, излучение, помехоустойчивость, внутренняя помехоустойчивость, внешняя помехоустойчивость, активное оборудование

---