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

МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ (МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION

(ISC)

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ГОСТ

IEC 62026-3—

2015

Аппаратура распределения и управления низковольтная. Интерфейсы между контроллерами и приборами (CDI)

Часть 3

СИСТЕМА СВЯЗИ DEVICENET

(IEC 62026-3:2008, IDT)

Издание официальное

Москва Российский институт стандартизации 2024

ГОСТ IEC 62026-3—2015

Предисловие

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

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

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

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

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

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

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 17В Технического комитета по стандартизации IEC/TC 17 «Низковольтная аппаратура распределения и управления» Международной электротехнической комиссии (IEC).

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

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

II

ГОСТ IEC 62026-3—2015

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

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

© IEC, 2008

© Оформление. ФГБУ «Институт стандартизации», 2024

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

III

ГОСТ IEC 62026-3—2015

Содержание

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

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

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

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

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

6 Информация об изделии..............................................................65

7 Нормальные условия эксплуатации, установки и транспортирования.........................65

8 Требования к конструкции и работоспособности..........................................66

9 Испытания.........................................................................89

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов межгосударственным стандартам..........................................98

Библиография.......................................................................100

IV

ГОСТ IEC 62026-3—2015

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Аппаратура распределения и управления низковольтная. Интерфейсы между контроллерами и приборами (CDI)

Часть 3

СИСТЕМА СВЯЗИ DEVICENET

Low-voltage switchgear and controlgear. Controller-device interfaces (CDIs).

Part 3. DeviceNet

Дата введения — 2025—01—01 с правом досрочного применения

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

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

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

- требования к интерфейсам между контроллерами и коммутирующими элементами;

- нормальные условия эксплуатации устройств;

- конструктивные требования и требования к функционированию;

- испытания для подтверждения соответствия требованиям.

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

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

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

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

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

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

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

Издание официальное

1

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2

ГОСТ IEC 62026-3—2015

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

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

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

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): Логическое связывание между двумя или более прикладными объектами.

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

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

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

3

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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, который гарантирует отсутствие двух узлов на одном и том же канале связи, принадлежащих одному и тому же идентификатору МАС.

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): Устройство, в котором некоторые компоненты не относятся к В- физического уровня, см. неизолированные устройства (3.1.36).

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

4

ГОСТ IEC 62026-3—2015

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): Устройство, в котором все компоненты связаны с В-физического уровня, см. изолированное устройство (3.1.31).

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

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

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

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

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

(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 идентификатор МАС источника (source MAC ID): Идентификатор МАС узла, который передает сообщение.

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).

5

ГОСТ IEC 62026-3—2015

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 — идентификатор соединения

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

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).

6

ГОСТ IEC 62026-3—2015

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

Основная схема соединения 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 используют сокращенную версию общего промышленного протокола (CIP™ ¹)) и служб, определенных в IEC 61158.

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

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

7

ГОСТ IEC 62026-3—2015

Уровни эталонной модели OSI

Уровни протокола DeviceNet

Уровень 7

Уровень 6

Уровень 5

Уровень 4

Уровень 3

Уровень 2

УВРВ®Ц^Ь 1

«Уровень О»

Спецификация DeviceNet/CIP

Пустое значение (Ноль)

Пустое значение (Ноль)

Пустое значение (Ноль)

Пустое значение (Ноль)

Протокол CAN

Спецификация DeviceNet

Рисунок 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, поле идентификатора CAN в DeviceNet содержит следующее:

- ID сообщения: идентифицирует сообщение в группе сообщений внутри конкретного узла. Когда соединение установлено, узлы используют идентификатор сообщения в сочетании с ID МАС для генерирования CID. Полученный CID указывается в поле идентификатора CAN, связанном с соответствующими транзакциями;

- ID МАС источника: группы 1 и 3 требуют спецификации ID МАС источника в поле идентификатора CAN;

- ID МАС: сообщение группы 2 позволяет указать источник или идентификатор получателя в пределах части «ID МАС» поля идентификатора CAN.

8

ГОСТ IEC 62026-3—2015

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

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

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

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

- ID 7 сообщения группы 2 используется для обнаружения узлов, которым были присвоены идентичные идентификаторы МАС (см. 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 устанавливаются динамически путем генерации интерфейса с учетом класса соединения через ранее установленное соединение для явных сообщений. Экземпляр соединения должен быть сгенерирован и сконфигурирован на каждом узле.

9

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

- заголовок сообщения;

- все тело сообщения в полном объеме.

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

- заголовок сообщения;

- протокол фрагментации (см. 5.2.3.2);

- фрагмент основных данных сообщения.

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

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

Контент

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

10

ГОСТ IEC 62026-3—2015

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

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

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

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

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

- МАС ID: содержит либо источник, либо идентификатор МАС-адреса получателя.

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

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

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

Первый аргумент, указанный в теле сообщения, является служебным полем, которое идентифицирует конкретный передаваемый запрос или отклик. На рисунке 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) обеспечивает динамическое установление соединения явных сообщений. В этом подразделе представлено подробное описание аргументов в зависимости от службы, связанных с открытым соединением явных сообщений и службами

11

ГОСТ IEC 62026-3—2015

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

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

- открытое соединение для передачи явных сообщений: код службы = 4В_Нех. Используется в целях установления соединения для передачи явных сообщений;

- отключение соединения: код службы = 4С_Нех. Используется для удаления объекта соединения и уничтожения всех связанных ресурсов.

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

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

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

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

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

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

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

- frag (0) transaction ID/МАС ID: см. 5.2.1.2. Идентификатор МАС-адреса получателя всегда указывается в заголовке сообщения, связанном с запросом/откликом на открытое соединение явных сообщений;

- R/R бит (0): показывает, что это — сообщение-запрос;

- код службы (4В_Нех): Определяет данное сообщение в качестве службы открытого соединения явных сообщений;

- резервные биты: Эти биты должны игнорироваться ресивером и устанавливаться трансмиттером на ноль;

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

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

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

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

12

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

ГОСТ IEC 62026-3—2015

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

Таблица 2 — Значения выбора группы

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

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

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

13

ГОСТ IEC 62026-3—2015

Окончание таблицы 3

^а) Клиент размещает это значение в рамках компонента сообщения ID группы 1 или 3.

^ь) Соединения явных сообщений, установленные через сообщения группы 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/МАС ID: см. 5.2.1.2. Идентификатор МАС-адреса получателя всегда указывается в заголовке сообщения, связанном с запросом/откликом на открытое соединение явных сообщений;

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

- код службы (4В_Нех): определяет данное сообщение в качестве службы открытого соединения явных сообщений;

- резервные биты: эти биты должны устанавливаться трансмиттером на ноль;

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

- ID целевого сообщения: использование данного поля зависит от сообщения группы, в которой имеет место соединение (как показано в таблице 4);

14

ГОСТ IEC 62026-3—2015

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

- ID источника сообщения: значение ID сообщения, которое назначил сервер. Сервер назначает ID сообщения из накопителя ID сообщений группы 1, 2 или 3, который используется в сочетании с ID MAC (ID источника МАС), чтобы создать ID соединения, которое указывается при передаче сообщения по этому соединению;

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

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

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

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

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

- frag (0)/transaction ID/МАС ID: См. 5.2.1.2;

- R/R бит (0): показывает, что это — запрашиваемое сообщение;

- код службы (4С_Нех): определяет, что это — служба отключения соединения;

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

Контент

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

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

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

- frag (0)/transaction ID/МАС ID: См. 5.2.1.2;

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

- Код службы (4С_Нех): определяет данное сообщение как службу отключения соединения;

15

ГОСТ IEC 62026-3—2015

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

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

Таблица 5 — Коды/условия сбоя (ошибки) UCMM

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

- служба не открыта или закрыта: Служба, получаемая через порт UCMM, является не открытого или закрытого типа, и поэтому не поддерживается UCMM;

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

- выбор группы вне диапазона: поле выбора группы содержит неверное значение;

- отсутствует соединение с сервером: уже было достигнуто максимальное количество соединений, поддерживаемое этим сервером;

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

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

- Неверный ID экземпляра соединения: ID экземпляра соединения, полученный с запросом на отключение соединения, не существует.

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

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

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

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

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

16

ГОСТ IEC 62026-3—2015

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

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

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

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

- frag (0)/transaction ID/МАС ID: См. 5.2.1.2;

- R/R бит (0): показывает, что это — сообщение-запрос;

- Код службы (4С_Нех): определяет запрашиваемую службу;

- ID класса: определяет класс объекта, в отношении которого направляется этот запрос. ID класса указывается в пределах 8-битного или 16-битного целочисленного поля, основанного на значении формата тела фактического сообщения, выдаваемого в отклике открытого соединения пересылки явного сообщения;

- ID экземпляра: определяет конкретный экземпляр в классе объекта, в отношении которого направляется запрос. ID экземпляра указывается в пределах 8-битного или 16-битного целочисленного поля, основанного на значении формата тела фактического сообщения, выдаваемого в отклике открытого соединения пересылки явного сообщения. DeviceNet использует нулевое значение, чтобы указать, что запрос направляется скорее в отношении самого класса, чем на конкретный экземпляр в пределах этого класса;

- служебные данные: содержат данные конкретного запроса. Форматы общих служб DeviceNet представлены в 61158-6-2 (пункт 4.1.8). Определения служб, характерных для класса и объекта, включают формат данного поля.

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

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

17

ГОСТ IEC 62026-3—2015

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

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

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

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

- frag (0)/transaction ID/МАС ID: См. 5.2.1.2;

- R/R бит (0): показывает, что это — сообщение-запрос;

- код службы (4С_Нех): определяет запрашиваемую службу;

- длина маршрута: это 8-битовое целое значение (USINT) обеспечивает маршрут сообщения-запроса;

- маршрут: определяет маршрут сообщения-запроса (пакетированный ЕРАТН);

- служебные данные: содержат данные конкретного запроса. Форматы общих служб DeviceNet представлены в 61158-6-2 (пункт 4.1.8). Определения служб, характерных для класса и объекта, включают формат данного поля.

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

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

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

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

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

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

- frag (0)/transaction ID/МАС ID: См. 5.2.1.2;

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

- код службы (4С_Нех): транслирует данные в зависимости от запроса.

18

ГОСТ IEC 62026-3—2015

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

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

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

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

- frag (O)Ztransaction ID/МАС ID: См. 5.2.1.2;

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

- код службы (4С_Нех): определяет данное сообщение как сообщение-отклик об ошибке;

- код ошибки общего характера: идентифицирует обнаруживаемую ошибку. Информация о кодах ошибок общего характера приведена в IEC 61158-5-2 (пункт 6.2.1.3.3) и IEC 61158-2 (пункт 4.1.111);

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

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

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

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

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

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

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

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

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

19

ГОСТ IEC 62026-3—2015

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

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

- подтвержденная: выполняется при фрагментировании явного сообщения;

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

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

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

Контент

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

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

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

Таблица 6 — Значения бита типа фрагмента

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

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

20

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

21

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22

ГОСТ IEC 62026-3—2015

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

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

Таблица 7 — Значения бита статуса подтверждения

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

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

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

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

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

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

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

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

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

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

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

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

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

23

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

25

ГОСТ IEC 62026-3—2015

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

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

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

26

ГОСТ IEC 62026-3—2015

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

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

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

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

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

Рисунок 24 — Протокол сообщения-отклика на офлайновое монопольное использование

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

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

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

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

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

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

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

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

27

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

Значение AND (логически AND’d с его MAC ID) равно своему адресу MAC ID;

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

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

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

Таблица 9 — Подтверждение (создание отчета) адресов на основании маски

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

28

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используется, когда клиент обнаружил конкретный узел нарушенной связи и есть необходимость изменить свой адрес 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. Клиент генерирует это сообщение тогда, когда он предпринимает попытку идентифицировать наличие каких-либо узлов в состоянии сбоя связи.

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

29

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

30

ГОСТ IEC 62026-3—2015

Клиент должен всегда устанавливать «совпадение» (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 2С сообщения группы 4 и

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

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

31

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

Контент

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

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

Целью этого сообщения является модификация MAC ID узла в состоянии сбоя связи. Это сообще-

32

ГОСТ IEC 62026-3—2015

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

IF используемый узел:

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,

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

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

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

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

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

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

33

ГОСТ IEC 62026-3—2015

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.

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

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

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

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

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

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

34

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

35

ГОСТ IEC 62026-3—2015

Рисунок 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 управляют и обеспечивают обмен сообщениями.

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

36

ГОСТ IEC 62026-3—2015

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

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

Основные коммуникационные объекты, используемые 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 класса: 01 _Нех)

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

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

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

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

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

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

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

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

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

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

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 необходимо соблюдать следующие правила:

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

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

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

37

ГОСТ IEC 62026-3—2015

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

Важно! Для соединения, использующего класс транспортировки 0, или соединения, атрибут expected_ pack-et_rate которого был установлен на 0 (ноль), правило Ь) не может быть выполнено на основании одного данного объекта соединения. Для данных типов соединений задачи, которые в результате приведут к высвобождению и возможному повторному использованию идентификаторов соответствующего сообщения, должны выполняться с предосторожностью (т. е. генерирование конфигурации атрибута 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 приведен общий вид машины состояния доступа к соединению.

38

Потеря

Несуществующий

Возврат в исходное состояние

Включение питания устройства

1. Ручное вмешательство

2. Сообщение-запрос о сбое связи Полученное сообщение об изменении ID МАС

Изменение ID МАС на Новый ID МАС

3. Восстановленное энергоснабжение сета

7 num_retries=0

Отправка сообщения-запроса о проверке дубликата ID МАС

1. Сообщение-запрос/сообщение-отклик о проверке дубликата ID МАС получено

2. Обнаружено отключение шины CAN

3. Отсутствует питание сети

Сообщение-запрос/сообщение-отклик о проверке дубликата ID МАС не получено (время таймера истекло) и num_retries=O; Увеличьте на единицу num_retries=0

ГОСТ IEC 62026-3—2015

ОПЦИЯ: Получено сообщение-запрос о сбое связи: Отклик

Сбой связи

Потеря мощности сета

Успешная передача

Ожидание сообщения о проверке дубликата ID МАС

1. Сообщение-

запрос/сообщение-отклик о проверке дубликата ID МАС получено

2. Обнаружено отключение шины CAN

Успешная передача и включение быстрого соединения

Получено другое сообщение, кроме сообщения-запроса о проверке дубликата ID МАС Игнорируйте сообщение

Сообщение-запрос/сообщение-отклик о проверке дубликата ID МАС не получено (время таймера истекло) и num_retrles=O

Обнаружено отключение шины

CAN и ВО1-атрибута объекта DeviceNet = устанавливается вновь (01)

Режим онлайн

1. Получено сообщение-отклик о проверке дубликата ID МАС

2. Обнаружено отключение шины CAN и BOI-атрибута объекта DeviceNet = устанавливается вновь (00)

1. Получен отклик о проверке дубликата ID МАС: Передача сообщения-отклика о проверке дубликата ID МАС

2. Включено быстрое соединение и отклик о проверке дубликата ID МАС не получен (время таймера истекло) и num_retries=0; Увеличьте на единицу num retries и отошлите сообщение-запрос о проверке дубликата ID МАС

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

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

доступа к соединению.

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

39

ГОСТ IEC 62026-3—2015

Продолжение таблицы 12

40

Окончание таблицы 12

ГОСТ IEC 62026-3—2015

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

5.4.3 Обнаружение дубликата ID МАС

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

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

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

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

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

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

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

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

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

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

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

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

41

ГОСТ IEC 62026-3—2015

- устройство с функцией UCMM: устройство, поддерживающее UCMM;

- устройство без функции UCMM: устройство, не поддерживающее UCMM;

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

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

- ведущее устройство DeviceNet: относится к типу приложения, называемому «ведущее/ведомое устройство». Ведущее устройство DeviceNet — это устройство, которое собирает и распределяет данные I/O для контроллера процесса. Ведущее устройство сканирует свои ведомые устройства на основании списка сканирования, который в нем содержится. По отношению к сети, ведущее устройство является клиентом группы 2 или клиентом исключительно второй группы;

- ведомое устройство DeviceNet: относится к типу приложения, называемому «ведущее/ведомое устройство». Ведомое устройство возвращает данные I/O к ведущему устройству после его сканирования. По отношению к сети ведомое устройство является клиентом второй группы или сервером исключительно второй группы;

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

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

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

Таблица 13 — Поля предопределенного назначения идентификаторов соединения ведущего и ведомого устройств

42

Окончание таблицы 13

ГОСТ IEC 62026-3—2015

Следующие типы сообщений включены в таблицу 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 МАС: см. 5.2.7.

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

5.5.3.1 ALLOCATE_MASTER/SLAVE_CONNECTION_SET (Код службы: 4В_Нех)

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), либо соединения для передачи явных сообщений.

Служба allocate_master/slave_connection_set обеспечивает следующее:

- создает объект соединения;

- конфигурирует объект соединения.

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

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

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

43

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

- frag (0) transaction ID/МАС ID: как определено в 5.2.1.2;

- R/R бит (0): показывает, что это — сообщение-запрос;

- код службы (4В_Нех): идентифицирует это сообщение как службу allocate_master/slave_connec-tion_set;

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

- ID экземпляра: определяет конкретный экземпляр класса объекта, которому направлен этот запрос. Когда это сообщение передается через порт передачи явных сообщений-запросов набора со-44

ГОСТ IEC 62026-3—2015

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

- выбор назначения: определяется байтом, идущим за полем ID экземпляра;

- ID МАС устройства назначения: определяется байтом, идущим за полем выбора назначения.

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

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

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

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

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

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

- frag (0) transaction ID/МАС ID: как установлено в 5.2.1.2;

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

- код службы (4В_Нех): идентифицирует это сообщение как службу allocate_master/slave_connec-tion_set;

- резервные биты: эти биты не используются ресивером сообщения-отклика и должны быть установлены на 0 трансмиттером сообщения-отклика;

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

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

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

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

45

ГОСТ IEC 62026-3—2015

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

- если предопределенный набор соединений ведущего и ведомого устройств назначен и этот запрос исходит не от текущего ведущего устройства, то тогда ведомое устройство возвращает ошибку. Общий код ошибки в сообщении должен быть установлен на 0С_Нех с дополнительным кодом ошибки, установленным на конкретное значение объекта 01;

- если предопределенный набор соединений ведущего и ведомого устройств не назначен, то тогда ведомое устройство проверяет параметр выбора назначения, как указано в перечислении d);

- если предопределенный набор соединений ведущего и ведомого устройств назначен, и этот запрос исходит от текущего ведущего устройства, то тогда ведомое устройство проверяет параметр выбора назначения, как указано в перечислении d);

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

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

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

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

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

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

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

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

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

46

ГОСТ IEC 62026-3—2015

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

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

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

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

Запрос allocate_master/slave_connection_set получен

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

Нет

Соединение явного сообщения предопределенного назначения идентификаторов «мастара»/«спайва» остается родительским

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

с функцией UCMM)?

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

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

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

- если объект соединения явного родительского сообщения не находится в установленном состоянии.

5.5.3.3 Release_master/slave_connection_set (Код службы: 4С_Нех)

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

Данная служба используется для выгрузки из ведомого устройства предопределенного набора соединений ведущего/ведомого устройств. Общие коды ошибок определены в IEC 61158-5-2

47

ГОСТ IEC 62026-3—2015

(пункт 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

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

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

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

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

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

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

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

- frag (O)Ztransaction ID/МАС ID: см. 5.2.1.2;

- R/R бит (0): показывает, что это — сообщение-запрос;

- код службы (4С_Нех): идентифицирует сообщение как службу release_master/slave_connection_set;

- ID класса: определяет класс объекта, которому направлен запрос. Когда это сообщение передается через порт набора соединений ведущего и ведомого устройств для передачи явного сообщения без соединения (см. 5.5.2), то значение ID класса указывается в поле целочисленного бита 8. ID класса должно быть установлено на 03;

48

ГОСТ IEC 62026-3—2015

- 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 (O)Ztransaction ID/МАС ID: cm. 5.2.1.2;

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

- код службы (4С_Нех): идентифицирует сообщение как службу release_master/slave_connection_ set.

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

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

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

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

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

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

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

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

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

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

49

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

- многоадресное соединение по запросу: отвечающее за получение многоадресной команды запроса ведущего устройства и возвращающее отклик многоадресного запроса.

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

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

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

Таблица 18 — Идентификаторы экземпляра соединения для предопределенных соединений ведущих/ведомых устройств

50

Окончание таблицы 18

ГОСТ IEC 62026-3—2015

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

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

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

Set_attribute_single

(expected_packet_rate attribute)

1______

Get_attribute/Set_attribute

Установленное

Назначение

Переход, заданный через внутренний или внешний запрос

Сброс (поддержка необязательна)

Время ожидания истекло (режим «таймаут)

Отправить/полученные данные

Таймер неакгивности функцирует до первого использования I/O, затем «таймаут» = значение из expected_packet_rate_attribute

Время истечения ожидания при неактивности/контроле схеме и watchdog_tlme-out_actlon = переход на режим «таймаут»

Get_attribute/Set_attribute (Получить_атрибут/Установить_атрибут) Любые значения атрибута, измененные при истекшем времени ожидания, сбрасываются в начальное состояние, если «назначение» или «выгрузка» используются для выхода из состояния истекшего времени ожидания

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

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

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

51

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

ГОСТ IEC 62026-3—2015

Окончание таблицы 19

ГОСТ IEC 62026-3—2015

ГОСТ IEC 62026-3—2015

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

Выгрузка/удаление

Удаленный дочерний экземпляр и переходы в состояние «таймаут» и отсутствуют другие дочерние экземпляры в установленном состоянии

Нулевое

Назначение

Истечение времени ожидания при неактивности/контрольной схемы watchdogtime-out_actlon = deferred delete и, по крайней мере, один дочерний экземпляр в установленном состоянии

Выгрузка/удаление

Истечение времени ожидания при неактивности/контрольной схемы watchdog_time-out_action = auto delete и отсутствуют дочерние экземпляры в установленном состоянии

1 Get_attribute ^J Set_attribute

Получение данных/сброс

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

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

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

54

Окончание таблицы 20

ГОСТ IEC 62026-3—2015

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 ведущего и ведомого устройств

55

ГОСТ IEC 62026-3—2015

Окончание таблицы 21

^а> Атрибут transportclass_trigger объекта предопределенного набора соединений I/O ведущего и ведомого устройств в ведомом устройстве должен изменяться до одного из следующих значений: 82_Нех — класс сервера/ передачи 2, 83_Нех — класс сервера/передачи 3.

^ь> Атрибут produced_connection_size битстробового соединения I/O не должен устанавливаться на значение более 8.

^с) Данный атрибут должен иметь доступ Get/set многоадресного соединения по запросу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 байтов выходных данных (нефрагментированнных или фрагментированных) назначенному ведомому устройству.

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

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

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

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

56

ГОСТ IEC 62026-3—2015

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

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

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 байт данных между ведущим и ведомым устройством при использовании изменения активаторов производства состояния или цикла. Производство данных может быть распознано или не распознано.

57

ГОСТ IEC 62026-3—2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

58

ГОСТ IEC 62026-3—2015

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

5.6 DeviceNet Safety™ ¹) (безопасность)

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

DeviceNet Safety использует выделенный коммуникационный уровень безопасности над прикладным уровнем базового протокола DeviceNet: DeviceNet использует базовые коммуникационные объекты и службы DeviceNet вместе с конкретными объектами и службами, связанными с безопасностью, и включенными в функциональный коммуникационный профиль безопасности CIP Safety™¹). Безопасность CIP (общего промышленного протокола) полностью описана в IEC 61784-3-2, включая специальные адаптации к 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 — Общие характеристики физического уровня

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

59

ГОСТ IEC 62026-3—2015

Окончание таблицы 22

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

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

60

ГОСТ IEC 62026-3—2015

5.7.2 Трансивер

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

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

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

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

Таблица 23 — Характеристики трансмиттера

Таблица 24 — Характеристики ресивера

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

61

ГОСТ IEC 62026-3—2015

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

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

5.7.3 Заземление

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

5.7.4 Изоляция

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

Различают изолированные и неизолированные устройства.

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

5.7.4.2 Неизолированные устройства

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

Соединение экрана DeviceNet должно быть реализовано через параллельную RC-цепь (резистивно-емкостную цепь; сопротивление = 1 мОм, С = 0,01 мкФ (500 В)) к корпусу устройства.

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

Рисунок 48 — Устройство, содержащее неизолированный физический уровень

62

ГОСТ IEC 62026-3—2015

5.7.4.3 Изолированное устройство

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

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

Внутри изолированного устройства компоненты, заземленные как В-, могут подключаться к другим внешним устройствам через последовательные порты, параллельные порты и соединения I/O. Такие внешние устройства должны быть изолированы от земли, а данное требование указано в документации изготовителя.

Локальная линия питания

Рисунок 49 — Устройство, содержащее изолированный физический уровень

Экранированное соединение канала связи должно проходить через параллельную RC-цепь к корпусу устройства.

5.7.5 Передающая среда

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

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

63

ГОСТ IEC 62026-3—2015

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

5.7.6 Топология (общая схема соединений)

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

У среды DeviceNet должна быть линейная топология (см. рисунок 50). Отводные линии, если они используются, должны давать возможность присоединить один или несколько узлов. Разветвленная конструкция допускается только на отводной линии.

Оконечные резисторы должны быть подключены на каждом конце магистральной линии.

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

Отводная линия нулевой линии Короткие отводные линии (6 м/20 чт)

Рисунок 50 — Топология среды DeciceNet

5.7.6.2 Магистральные линии

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

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

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

5.7.6.3 Отводные линии

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

64

ГОСТ IEC 62026-3—2015

5.7.7 Питание линии связи

5.7.7.1 Конфигурация питания

Питание линии связи должно подаваться источником номинального 24 В постоянного тока и выдерживать напряжение до 8 А на любом отрезке магистральной линии из толстого кабеля или до 3 А на любом отрезке магистральной линии из тонкого кабеля. Можно использовать несколько источников питания.

5.7.7.2 Пределы нагрузки

Максимальный ток сети связи определяют по данным, приведенным в таблице 25 (спецификации на испытания см. в 9.2.2).

Таблица 25 — Пределы нагрузки

Максимальный ток отводной линии также можно вычислить по формуле:

/ = 4,5//,

где / — максимально допустимый ток отводной линии (А);

/— максимальная длина отвода (м).

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 А в случае других разъемов, если не указано иное.

65

ГОСТ IEC 62026-3—2015

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 (приложение А). В данном случае применяются общие и специальные требования к CDI, вариант (3).

Для устройств DeviceNet Safety есть дополнительные требования, см. IEC 61784-3-2.

8.2 Кабель DeviceNet

8.2.1 Общий обзор

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

- толстый кабель;

- тонкий кабель;

- плоский кабель.

8.2.2 Шаблон профиля кабеля

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

Таблица 26 — Профиль кабеля: спецификации на пару для передачи данных

66

Окончание таблицы 26

ГОСТ IEC 62026-3—2015

Таблица 27 — Профиль кабеля: спецификации на пару питания постоянным током

Таблица 28 — Профиль кабеля: общие спецификации

67

ГОСТ IEC 62026-3—2015

Окончание таблицы 28

Таблица 29 — Профиль кабеля: топология сети

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

8.2.3 Профиль толстого кабеля

В настоящем подразделе приведены следующие спецификации (технические описания) для тонкого кабеля:

- спецификации на пары для передачи данных, см. таблицу 30;

- спецификации на пары питания постоянным током, см. таблицу 31;

- общие спецификации, см. таблицу 32;

- топология сети, см. таблицу 33;

- физическая конфигурация, см. рисунок 51;

- предусмотренный ток шины, см. таблицу 34 и рисунок 52.

Таблица 30 — Толстый кабель: спецификации на пару для передачи данных

68

Таблица 31 — Толстый кабель: спецификации на пару питания постоянным током

ГОСТ IEC 62026-3—2015

Таблица 32 — Толстый кабель: общие спецификации

69

ГОСТ IEC 62026-3—2015

Таблица 33 — Толстый кабель: топология сети

Оболочка

Оплетка

Изоляция данных цвет: белый

Экран AL/MY

Изоляция данных цвет: белый

Изоляция источника питания постоянным током цвет: черный

AUMY экран

Провод

Изоляция источника питания постоянным током

Рисунок 51 —Толстый кабель: физическая конфигурация

Таблица 34 — Толстый кабель: максимально допустимый ток (А) с учетом протяженности сети

Длина сети (м) (фт)

Рисунок 52 — Толстый кабель: максимально допустимый ток (А) на силовой шине DeviceNet

Значения, приведенные в таблице 34 и рисунке 52, рассчитывают по формуле:

/ = 4,65 В/((кабель DCR х длину сети) + (контакт DCR х количество контактов)),

где кабель DCR = 0146 Ом/м,

контакт DCR = 0,001 Ом, и

количество контактов = 128 (т. к. у каждого ответвителя по два контакта, соединенных последовательно).

Кабель DCR определяют по температуре окружающей среды 80 °C и температурному коэффициенту 0,003 93 на °C.

70

ГОСТ IEC 62026-3—2015

8.2.4 Профиль тонкого кабеля

В данный раздел включены следующие спецификации для тонкого кабеля:

- спецификации на пары передачи данных, см. таблицу 35;

- спецификации пары питания постоянным током, см. таблицу 36;

- общие спецификации, см. таблицу 37;

- топология сети, см. таблицу 38;

- физическая конфигурация, см. рис.53;

- предусмотренный ток шины, см. таблицу 34 и рисунок 52.

Таблица 35 — Тонкий кабель: спецификации на пары для передачи данных

Таблица 36 — Тонкий кабель: спецификации на пару питания постоянным током

71

ГОСТ IEC 62026-3—2015

Таблица 37 — Тонкий кабель: общие спецификации

Таблица 38 — Толстый кабель: топология сети

72

ГОСТ IEC 62026-3—2015

током

Рисунок 53 — Тонкий кабель: физическая конфигурация

Таблица 39 — Тонкий кабель: максимально допустимый ток (А) с учетом длины сети

Рисунок 54 — Толстый кабель: максимально допустимый ток (А) на силовой шине DeviceNet

Таблица 39 и рисунок 54 рассчитываются по формуле:

/ =4,65 В/((кабель DCR х длину сети) + (контакт DCR х количество контактов)),

где кабель DCR = 0,070 9 Ом/м;

контакт DCR = 0,001 Ом; и

количество контактов = 128 (т. к. у каждого ответвителя по два контакта, соединенных последовательно).

Кабель DCR определяют по температуре окружающей среды 80 °C и температурному коэффициенту 0,003 93 на градус цельсия.

8.2.5 Профиль плоского кабеля

В данный раздел включены следующие спецификации для плоского кабеля:

- спецификации на пары передачи данных, см. таблицу 40;

- спецификации на пары питания постоянным током, см. таблицу 41;

- общие спецификации, см. таблицу 42;

- топология сети, см. таблицу 43;

- физическая конфигурация, см. рисунок 55;

- предусмотренный ток шины, см. таблицу 44 и рисунок 56.

73

ГОСТ IEC 62026-3—2015

Таблица 40 — Плоский кабель: спецификации на пары для передачи данных

Таблица 41 — Плоский кабель: спецификации на пару питания постоянным током

Таблица 42 — Плоский кабель: общие спецификации

74

Окончание таблицы 42

ГОСТ IEC 62026-3—2015

Таблица 43 — Толстый кабель: топология сети

5,33

0,10 RCF

НИЖНИЙ ДОПУСТИМЫЙ ПРЕДЕЛ

0,10 RCF

ВЕРХНИЙ ДОПУСТИМЫЙ ПРЕДЕЛ

1,52

---1,42

ТИП: все проводники

REF: 2,67

От того же центра, что и черный провод

4,70

4,70

R 2,67 ВНУТРЕННИЙ 2 PL КАСАТЕЛЬНО K.105R

КРАСНЫЙ

БЕЛЫЙ ГОЛУБОЙ ЧЕРНЫЙ

-А-

1,40

1,52

1,42

5,33 RCF

ТИП БЕЛЫЕ И ГОЛУБЫЕ

19 30 ^{ПР0В0ДНИКИ}

-В-

R0,51 4PL

т 100 1

(ПРОФИЛЬ ОБОЛОЧКИ)

------ 1,52

1,42____________

ТИП КРАСНЫЕ и ЧЕРНЫЕ ПРОВОДНИКИ

Рисунок 55 — Плоский кабель: физическая конфигурация

75

ГОСТ IEC 62026-3—2015

Таблица 44 — Плоский кабель: максимально допустимый ток (А) с учетом длины сети

Длина сети (м) (фт)

Рисунок 56 — Плоский кабель: допустимый ток на силовой шине DeviceNet

Таблица 44 и рис.56 рассчитывают по формуле:

/ = 4,65 В/((кабель DCR х длину сети) + (контакт DCR х количество контактов)),

где кабель 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.

76

Таблица 45 — Шаблон профиля разъема

ГОСТ IEC 62026-3—2015

8.4.3 Профиль открытого разъема

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

77

ГОСТ IEC 62026-3—2015

Таблица 46 — Открытый разъем

78

ГОСТ IEC 62026-3—2015

Рисунок 57 — Разводка контактов сетевого разъема

8.4.4 Профиль герметичного мини-разъема

В таблице 47 приведен профиль открытого разъема, а разводка контактов показана на рисунке 59.

79

ГОСТ IEC 62026-3—2015

Таблица 47 — Герметичный мини-разъем

80

ГОСТ IEC 62026-3—2015

Розеточная часть (контактные гнезда)

неизолирован ный

красный

черный

белый

голубой

Рисунок 59 — Разводка контактов герметичного мини-разъема

8.4.5 Профиль герметичного микроразъема

В таблице 48 описан профиль открытого разъема, а разводка контактов показана на рисунке 60.

Таблица 48 — Герметичный микроразъем

81

ГОСТ IEC 62026-3—2015

Окончание таблицы 48

Вилочная часть (контакты)

Розеточная часть

2) V+

3 ) V-

4 ) CAN_H

неизолированный красный черный белый голубой

Рисунок 60 — Разводка контактов микроразъема

8.4.6 Профиль плоского разъема магистральной линии

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

82

Таблица 49 — Плоский разъем магистральной линии

ГОСТ IEC 62026-3—2015

83

ГОСТ IEC 62026-3—2015

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

84

Рисунок 61 — Схема плоского разъема магистральной линии — разводка контактов

ГОСТ IEC 62026-3—2015

Рисунок 62 — Схема плоского разъема магистральной линии — геометрия

8.5 Ответвители устройств и силовые ответвители

8.5.1 Ответвители устройств

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

Ответвители устройств должны иметь рабочее напряжение в 25 В при постоянном токе и должны соответствовать спецификациям, приведенным в таблицах 50 и 51.

85

ГОСТ IEC 62026-3—2015

Таблица 50 — Спецификации на внутренний транзитный проводник

Таблица 51 — Спецификации на внутренний ответвительный проводник

8.5.2 Силовые ответвители

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

Силовой ответвитель может также обеспечивать следующее:

- защиту от избыточного тока в каждом направлении от ответвителя;

- защиту источника питания при использовании нескольких источников питания;

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

Силовые ответвители DeviceNet должны иметь минимальное номинальное напряжение 25 В постоянного тока и должны соответствовать спецификациям, указанным в таблицах 52 и 53.

Таблица 52 — Спецификации на внутренний транзитный проводник

Таблица 53 — Спецификации на внутренний ответвительный силовой проводник

86

ГОСТ IEC 62026-3—2015

Силовые ответвительные разъемы (кроме разъема источника питания) должны отвечать требованиям, указанным в 8.4.

8.6 Устройства, питаемые от канала связи

Устройства могут питаться от канала связи. Такие устройства должны использовать регулятор напряжения с входным напряжением в диапазоне от 11 В до 25 В постоянного тока и иметь встроенную защиту и фильтры.

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

Таблица 54 — Спецификации на регулятор напряжения

8.7 Защита от неправильной схемы разводки пар в кабеле

Устройства должны быть способны выдерживать неправильное соединение, не подвергаясь повреждению, при следующих условиях:

- перепутанное соединение проводников В+ с В-;

- соединение заземляющего провода с любым другим проводником;

- подключение CAN_H и/или CAN_L к напряжению, не превышающему диапазон от минус 25 В постоянного тока до плюс 18 В постоянного тока.

Спецификации см. в 9.2.4 и 9.2.5.

8.8 Источники питания

Питание, получаемое от сети, должно соответствовать спецификациям, указанным в таблице 55 (см. 9.2.1).

Таблица 55 — Спецификации на источник питания DeviceNet

87

ГОСТ IEC 62026-3—2015

Окончание таблицы 55

8.9 Электромагнитная совместимость (ЭМС)

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

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

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

8.9.2 Помехоустойчивость

8.9.2.1 Функциональные критерии

Результаты испытания определяются с использованием следующих функциональных критериев:

- критерий А: Прибор должен продолжать работать надлежащим образом во время и после испытания. Любая потеря функциональности, как приведено в таблице 56, должна означать сбой в работе;

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

Таблица 56 — Функциональные критерии помехоустойчивости

88

ГОСТ IEC 62026-3—2015

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, классу А.

8.9.3.2 Кондуктивное излучение

Должны соответствовать CISPR 11, группе 1, классу А.

8.10 Дополнительные требования к функциональной безопасности, связанной с ЭМС

DeviceNet Safety CDI должен соответствовать дополнительным требованиям, приведенным в IEC 61784-3-2.

9 Испытания

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

В настоящем разделе определены испытания типа для электрических и логических требований. Испытания разделены на две части:

- электрические испытания и испытания ЭМС;

- логические испытания (режим работы устройства на DeviceNet).

Примечание — Если спецификации 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) для гарантии того, что подача питания осуществляется на номинальном токе.

89

ГОСТ IEC 62026-3—2015

Рисунок 63 — Испытательная цепь нарастания напряжения питания по времени

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.

Рисунок 64 — Испытательная цепь потребления тока

9.2.2.2 Процедура испытания

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

Испытания должны проводиться на верхний и нижний пределы диапазона напряжений, указанные в 5.7.7.2.

9.2.2.3 Критерии соответствия

Определить приемлемый предельный ток путем проверки устройства и/или изучения документации изготовителя. Полученные показания тока должны соответствовать 5.7.7.2 и должны быть меньше чем или равны 8 А.

90

ГОСТ IEC 62026-3—2015

9.2.3 Режим работы устройства при включении питания

9.2.3.1 Цель испытания

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

- когда добавляется к существующему Интерфейсу контроллера устройства (CDI);

- когда мощность является цикличной на CDI.

9.2.3.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, изображенной на рисунке 65.

Рисунок 65 — Испытательная цепь включения питания

9.2.3.3 Процедура испытания

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

9.2.3.4 Критерии соответствия

Первый передаваемый сигнал должен быть действительным дубликатом ID МАС запроса.

9.2.4 Обратное соединение

9.2.4.1 Цель испытания

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

9.2.4.2 Испытательная цепь

Испытательная цепь изображена на рисунке 66.

Рисунок 66 — Испытательная цепь для изменения полярности В+ и В-, а также прерывания подачи питания В-

9.2.4.3 Процедура испытания

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

9.2.4.4 Критерии соответствия

Должно быть подтверждено, что сигналы CAN_H и CAN_L остаются в пределах, указанных в таблицах 23 и 24.

9.2.5 Разъединение В-

9.2.5.1 Цель испытания

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

9.2.5.2 Испытательная цепь

Испытательная цепь должна соответствовать приведенной на рисунке 66.

91

ГОСТ IEC 62026-3—2015

9.2.5.3 Процедура испытания

Соединение В- на испытываемом оборудовании должно быть отсоединено.

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 в отношении В- в наихудших смоделированных условиях полного сопротивления, в указанных пределах, как часть требований к физическому уровню.

9.2.7.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, изображенной на рисунке 68.

Толстый или тонкий кабель длиной 3 м (макс.) __________I ИО

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

9.2.7.3 Процедура испытания

Для проведения этого испытания ИО должно быть передающим. При отсутствии какого-либо иного устройства в сети связи, ИО автоматически начинает пересылать сообщения-запросы дубликата ID МАС по завершении своей последовательности включения питания. На осциллографе следует наблюдать содержание фактического сообщения от ИО. Необходимо записывать следующие значения (см. рисунок 69):

- ниспадающее напряжение CAN_L с учетом В-;

- ниспадающее напряжение CAN_H с учетом В-;

92

ГОСТ IEC 62026-3—2015

- восходящее напряжение CAN_L с учетом В-;

- восходящее напряжение CAN_H с учетом В-;

- уровень дифференциального выходного напряжения.

Рисунок 69 — Уровни передачи

9.2.7.4 Критерии соответствия

Значения должны соответствовать критериям, приведенным в таблице 23.

9.2.8 Задержка подтверждения

9.2.8.1 Цель испытания

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

9.2.8.2 Испытательная цепь

Испытательная цепь должна быть в соответствии с приведенной на рисунке 70.

Терминатор 121 Ом

Терминатор 127 Ом ± 1 % параллельно с 100 пФ ± 2 %

Рисунок 70 — Схема испытания временной выдержки

9.2.8.3 Процедура испытания

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

«4--- Информация, посланная главной системой

Бит подтверждения, посланный испытываемым устройством

Время отклика подтверждения 8 мкс, 4 мкс или 2 мкс

Рисунок 71 — Временная выдержка

93

ГОСТ IEC 62026-3—2015

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 А);

- силовая нагрузка в сети связи в наихудшем случае должна подключаться рядом с ИО. Эта нагрузка может привести к падению напряжения на В-линии значением 5 В +0,0/-0,1 В от источника питания к ИО;

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

Терминатор 121 Ом Терминатор 121 Ом

Рисунок 72 — Схема проведения испытания CDI

9.2.9.3 Процедура испытания

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

9.2.9.4 Критерии соответствия

Зарегистрированные отсутствующие биты подтверждения и условия отключения шины должны соответствовать приведенным изготовителем ИО.

94

ГОСТ IEC 62026-3—2015

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, классом А и 8.9.3.1.

Длина магистральной линии должна быть максимально допустимой (см. 5.7.6.2). ИО должно быть соединено непосредственно с магистральной линией с использованием отводной линии максимально допустимой длины (см. 5.7.6.3).

9.2.10.3.2 Кондуктивные излучения

Настоящее испытание проводят в соответствии CISPR 11, группой 1, классом А и 8.9.3.2.

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

9.3 Логические испытания

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

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

95

ГОСТ IEC 62026-3—2015

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

- посылает сообщения DeviceNet;

- получает и оценивает сообщения DeviceNet;

- регистрирует и помечает время трафика на CDI.

9.3.2 Испытание проверки дубликата ID МАС

9.3.2.1 Цель испытания

Целью настоящего испытания является подтверждение того, что ИО отвечает требованиям, касающимся механизмов обработки ID МАС.

9.3.2.2 Испытательная цепь

Испытательная цепь должна соответствовать цепи, показанной на рисунке 73.

Терминатор 121 Ом Терминатор 121 Ом

Рисунок 73 — Испытательная цепь для логических испытаний

9.3.2.3 Процедура испытания

9.3.2.3.1 Успешная проверка дубликата ID МАС

ID МАС ИО должен быть установлен на 0. К ИО можно применять любое необходимое внешнее питание. Для этого ИО должно быть физически соединено с сетью. Испытательная установка затем должна быть соединена с сетью и должна записывать коммуникационный трафик.

9.3.2.3.2 Неспешная проверка дубликата ID МАС

ID МАС ИО должен быть установлен на 0. К ИО можно применять любое необходимое внешнее питание. Для этого ИО должно быть физически соединено с сетью. Испытательная установка должна отвечать на первое сообщение-запрос проверки дубликата ID МАС с сообщением-откликом проверки дубликата ID МАС.

9.3.2.4 Критерии соответствия

9.3.2.4.1 Успешная проверка дубликата ID МАС

Следует подтвердить, что:

- ИО передает сообщение-запрос проверки дубликата ID МАС;

- ИО передает второй запрос о проверке дубликата ID МАС спустя 0,9 с — 1,5 с;

- ИО воспринимает состояние онлайн не раньше, чем за 0,9 с после передачи второго сообщения-запроса о дубликате ID МАС;

- ИО не передает каких-либо других сообщений перед принятием состояния онлайн.

9.3.2.4.2 Неуспешная проверка дубликата ID МАС

ИО должно воспринимать состояние сбоя связи (см. таблицу 12) после получения сообщения-отклика о проверке дубликата ID МАС.

9.3.3 Менеджер сообщений без установления соединения (UCMM)

9.3.3.1 Цель испытания

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

9.3.3.2 Испытательная цепь

Испытательная цепь должна соответствовать той цепи, которая изображена на рисунке 73.

9.3.3.3 Процедура испытания

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

ГОСТ IEC 62026-3—2015

даваться через это соединение. Испытательная установка должна передавать закрытое сообщение-запрос 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 передается и принимается так, как определено в предопределенном наборе соединений ведущего и ведомого устройств;

- ИО не передает ответ на второе сообщение I/O.

9.3.6 Логические испытания средств безопасности

Дополнительные требования к логическим испытаниям средств безопасности указаны в IEC 61784-3-2.

97

ГОСТ IEC 62026-3—2015

Приложение ДА (справочное)

Сведения о соответствии ссылочных международных стандартов межгосударственным стандартам

Таблица ДА.1

¹ > Действует ГОСТ IEC 60947-5-2—2012 «Аппаратура распределения и управления низковольтная. Часть 5-2. Аппараты и коммутационные элементы цепей управления. Бесконтактные датчики», идентичный IEC 60947-5-2:2007.

²) Действует ГОСТ IEC 61508-3—2018 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению», идентичный IEC 61508-3:2010.

³) В Российской Федерации действует ГОСТ Р ИСО/МЭК 7498-1—99 «Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель».

⁴) В Российской Федерации действует ГОСТ Р ИСО 11898-1—2015 «Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 1. Канальный уровень и передача сигналов».

⁵) В Российской Федерации действует ГОСТ Р ИСО 11898-2—2015 «Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 2. Устройство доступа к высокоскоростной среде».

98

Окончание таблицы ДА. 1

ГОСТ IEC 62026-3—2015

¹ > Действует ГОСТ CISPR 11—2017 «Электромагнитная совместимость. Оборудование промышленное, научное и медицинское. Характеристики радиочастотных помех. Нормы и методы испытаний», идентичный CISPR 11:2015.

99

ГОСТ IEC 62026-3—2015

100

ГОСТ IEC 62026-3—2015

УДК 004.31-181.48:621,39(083.74)(476)

МКС 29.130.20

IDT

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

101

Технический редактор В.Н. Прусакова Корректор О.В. Лазарева Компьютерная верстка И.А. Налейкиной

Сдано в набор 31.01.2024. Подписано в печать 20.02.2024. Формат 60x847s. Гарнитура Ариал.

Усл. печ. л. 12,09. Уч.-изд. л. 10,80.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «Институт стандартизации» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.