allgosts.ru35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ35.240. Применение информационных технологий

ГОСТ Р МЭК 61131-9-2017 Контролеры программируемые. Часть 9. Одноточечный интерфейс цифровой связи для небольших датчиков и исполнительных устройств

Обозначение:
ГОСТ Р МЭК 61131-9-2017
Наименование:
Контролеры программируемые. Часть 9. Одноточечный интерфейс цифровой связи для небольших датчиков и исполнительных устройств
Статус:
Действует
Дата введения:
09/01/2018
Дата отмены:
-
Заменен на:
-
Код ОКС:
35.240.50, 25.040.40

Текст ГОСТ Р МЭК 61131-9-2017 Контролеры программируемые. Часть 9. Одноточечный интерфейс цифровой связи для небольших датчиков и исполнительных устройств



ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

МЭК 61131-9— 2017

КОНТРОЛЛЕРЫ ПРОГРАММИРУЕМЫЕ

Часть 9

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

(IEC 61131-9:2013, ЮТ)

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

Москва

Стамдяртимформ

2017

ГОСТ Р МЭК 61131-9—2017

Предисловие

1    ПОДГОТОВЛЕН Негосударственным образовательным частным учреждением дополнительного профессионального образования «Новая инженерная школа» (НОЧУ «НИШ») на основе собственного перевода на русский язык англоязычной версии указанного в пункте 4 стандарта, который выполнен Российской комиссией экспертов МЭКГГК 65 и Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации» (ВНИИНМАШ)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 306 «Измерения и управление в промышленных процессах»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 14 сентября 2017 г. № 1124-ст

4    Настоящий стандарт идентичен международному стандарту МЭК 61131-9:2013 «Контроллеры программируемые. Часть 9. Одноточечный интерфейс цифровой связи для небольших датчиков и исполнительных устройств» [IEC 61131-9:2013 «Programmable controllers — Part 9: Single-drop digital communication interface for small sensors and actuators (SDCI)». IDT).

Международный стандарт разработан Техническим комитетом МЭК ТК 65 «Измерение, управление и автоматизация в промышленных процессах».

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

5    8ВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29июня 2015г. № 162-ФЗ «О стандартизации в Российской Федерации**. Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандартыа официальный текст изменений и поправок — е ежемесячном указателе ''Национальные стандарты-. В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано е ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты-. Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()

© Стандартинформ. 2017

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

II

ГОСТ Р МЭК 61131-9—2017

Содержание

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

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

3    Термины, определения, обозначения, сокращения и условные обозначения....................3

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

3.2    Обозначения и сокращения.........................................................5

3.3    Условные обозначения.............................................................7

4    Обзор одноточечного интерфейса цифровой связи SDCI (Ю-Link™)..........................9

4.1    Назначение технологии............................................................9

4.2    Позиционирование в иерархии средств автоматизации..................................9

4.3    Проводка, соединители и электропитание............................................10

4.4    Возможности связи SDCI..........................................................10

4.5    Роль Ведущего узла..............................................................12

4.6    Конфигурирование SDCI..........................................................13

4.7    Отображение на полевые шины....................................................13

4.8    Структура стандарта.............................................................14

5    Физический уровень (PL)..............................................................14

5.1    Общие положения...............................................................14

5.2    Услуги физического уровня........................................................15

5.3    Передатчик/приемник.............................................................18

5.4    Источник питания................................................................25

5.5    Среда передачи данных...........................................................26

6    Стандартный ввод и вывод (SIO).......................................................29

7    Канальный уровень (DL)..............................................................29

7.1    Общие положения...............................................................29

7.2    Услуги канального уровня.........................................................31

7.3    Протокол канального уровня.......................................................46

8    Прикладной уровень (AL).............................................................80

8.1    Общие положения...............................................................80

8.2    Услуги прикладного уровня........................................................81

8.3    Протокол прикладного уровня......................................................89

9    Модуль управления системой (SM).....................................................98

9.1    Общие положения...............................................................98

9.2    Модуль управления системой на Ведущем узле.......................................98

9.3    Модуль управления системой на Устройстве.........................................113

10    Устройство.......................................................................126

10.1    Обзор........................................................................126

10.2    Обмен Данными процесса (PDE).................................................127

10.3    Менеджер параметров (РМ).....................................................128

10.4    Хранилище данных (DS)........................................................135

10.5    Диспетчер Событий (ED)........................................................138

10.6    Характеристики Устройства......................................................138

10.7    Проектные нормы и ограничения Устройства.......................................140

10.8    Описание устройства ввода/выеода (IODD).........................................142

III

ГОСТ Р МЭК 61131-9—2017

10.9    Диагностика Устройства.........................................................142

10.10    Возможности подключения Устройства...........................................145

11 Ведущий узел.....................................................................145

11.1    Обзор........................................................................145

11.2    Менеджер конфигурации (СМ)....................................................148

11.3    Хранилище данных (DS)........................................................153

11.4    Обмен Данными запроса (ODE)..................................................160

11.5    Блок диагностики (DU)..........................................................161

11.6    Обмен Данными процесса (PDE)..................................................162

11.7    Инструмент конфигурирования порта и Устройства (PDCT)............................164

11.8    Приложение шлюза............................................................165

Приложение А (обязательное) Кодирование, временные ограничения и ошибки................169

Приложение В (обязательное) Параметры и команды......................................188

Приложение С (обязательное) Тилы ошибок (ошибки ISDU).................................204

Приложение D (обязательное) Коды ошибок (диагностическая информация)...................207

Приложение Е (обязательное) Типы данных..............................................211

Приложение F (обязательное) Структура объекта данных Хранилища данных..................221

Приложение G (обязательное) Соответствие Ведущего узла и Устройства.....................222

Приложение Н (справочное) Вероятности остаточных ошибок...............................227

Приложение I (справочное) Примерная последовательность передачи ISDU...................229

Приложение J (справочное) Рекомендуемые методы определения изменения параметров.......233

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

стандартов национальным стандартам Российской Федерации................234

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

IV

ГОСТ Р МЭК 61131-9—2017

Введение

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

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

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

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

Управление приводом в технологии SOCI (lO-Link™)** нуждается в таких доступных по цене датчиках и исполнительных устройствах для обмена диагностическими и конфигурационными данными с контроллером {программируемым контроллером (PC) или программируемым логическим контроллером (PLC)), применяя недорогую технологию цифровой связи при одновременном обеспечении обратной совместимости с токовыми сигналами ввода/вывода.

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

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

Фиэичесхое соединение производится из точки в точку от каждого Устройства к Ведущему узлу, применяя три провода длиной не более 20 м. Физический интерфейс SDCI имеет обратную совместимость с обычной сигнальной линией 24 В. установленной в МЭК 61131-2. Поддерживаются скорости передачи 4.8; 38.4 и 230,4 кбит/с.

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

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

Технология SDCI определяет три различных уровня диагностических возможностей: для немедленного реагирования автоматизированными средствами на этапе изготовления: для среднесрочного реагирования путем вмешательства оператора; для долговременного ввода в эксплуатацию и технического обслуживания с использованием расширенной диагностической информации.

Структура настоящего стандарта описана в подразделе 4.8.

Соответствие настоящему стандарту может подтверждаться только в том случае, если выполняются требования приложения G.

Общепринятые термины установлены в МЭК 61131-1 или в серии МЭК 60050. Конкретные термины устанавливаются в каждой части.

0.2 Патентная декларация

Международная электротехническая комиссия (МЭК) обращает внимание на то заявление, что соответствие настоящему стандарту может включать использование патентов, касающихся интерфейса

'I IО-Link™ является торговой маркой «Ю-Link Consortium». Данная информация приводится для удобства пользователей настоящим стандартом и не требует от МЭК подтверждения владельца торговой марки держателя или любого из его продуктов. Соответствие настоящему стандарту не требует использования зарегистрированных торговых знаков Ю-Link™. Использование зарегистрированных торговых знаков Ю-Link™ требует разрешения от «Ю-Link Consortium».

V

ГОСТ Р МЭК 61131-9—2017

двухточечной последовательной связи для небольших датчиков и исполнительных устройств в следующей редакции, где обозначение [хх] указывает на владельца патентного права:

DE 10030845В4 ЕР 1168271В1 US 6889282В2

(АВ)

Система коммутации полевых шин для исполнительных устройств и датчиков

ЕР 1203933 В1

РЕ]

Сенсорное устройство для измерения по меньшей мере одной переменной

DE 102004 035 831.1

[SI]

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

DE 102 119 39А1 US 2003/0200323 А1

(SK)

Соединительное устройство для присоединения устройств к системе шин

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

Владельцы настоящих патентных прав заверили МЭК. что они готовы в добровольном порядке переуступить лицензии либо бесплатно, либо на приемлемых и справедливых условиях заявителям по всему миру. В этом отношении заявления владельцев данных патентных прав зарегистрированы в МЭК.

Дополнительная информация доступна в следующих источниках:

[АВ]

ABBAG

Heidelberg Germany — Германия

IFE]

FestoAG

Esstingen Germany — Германия

[SI]

Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany — Германия

[SK]

Sick AG

Watdkirch Germany — Германия

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

ИСО () и МЭК () поддерживают оперативные базы данных патентов, имеющих отношение к их стандартам. Пользователям рекомендуется обращаться к базам данных для получения самой последней информации, относящейся к патентам.

VI

ГОСТ Р МЭК 61131-9—2017

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

КОНТРОЛЛЕРЫ ПРОГРАММИРУЕМЫЕ Часть 9

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

Programmable controllers. Part 9. Single-drop digital communication interface Гог smalt sensors and actuators (SDCI)

Дата введения — 2018—09—01

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

Настоящий стандарт устанавливает технологию одноточечного интерфейса цифровой связи SDCI для небольших датчиков и исполнительных устройств (более известных под названием lO-Link™), которая расширяет традиционные интерфейсы цифрового ввода и вывода, определенные в МЭК 61131-2. к двухточечной линии связи. Данная технология делает возможными передачу параметров Устройствам и доставку диагностических данных от Устройств к системе автоматизации.

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

Настоящий стандарт устанавливает услуги связи SDCI и протокол (физический уровень, канальный уровень и прикладной уровень в соответствии с эталонной моделью ISO/OSI) как для Ведущих узлов SDCI, так и для Устройств.

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

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

В настоящем стандарте использованы нормативные ссылки на следующие документы. Для датированных ссылок применяют только указанное издание ссылочного документа. Для недатированных ссылок применяют последнее издание ссылочного документа (включая все его изменения).

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

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

IEC 61000-4-3. Electromagnetic compatibility (EMC) — Part 4-3: Testing and measurement techniques — Radiated, radio-frequency, electromagnetic field immunity test (Электромагнитная совместимость

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

1

ГОСТ Р МЭК 61131-9—2017

(ЭМС). Часть 4-3. Методы испытаний и измерений. Испытания устойчивости к радиоактивному излучению. радиочастотам и электромагнитному полю]

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

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

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

IEC 61000-4-11. Electromagnetic compatibility (EMC) — Part 4-11: Testing and measurement techniques — Voltage dips, short interruptions and voltage variations immunity tests [Электромагнитная совместимость (ЭМС). Часть 4-11. Методы испытаний и измерений. Испытания устойчивости к кратковременным падениям напряжения, кратковременным прерываниям электроснабжения и перепадам напряжения]

IEC 61000-6-2, Electromagnetic compatibility (EMC) — Part 6-2: Generic standards — Immunity for industrial environments [Электромагнитная совместимость (ЭМС). Часть 6-2. Общие стандарты. Устойчивость к промышленным окружающим средам]

IEC 61000-6-4. Electromagnetic compatibility (EMC) — Part 6-4: Generic standards — Emission standard for industrial environments [Электромагнитная совместимость (ЭМС). Часть 6-4. Общие стандарты. Нормы выбросов в промышленных окружающих средах]

IEC 61076-2-101. Connectors for electronic equipment — Product requirements — Part 2-101: Circular connectors — Detail specification for M12 connectors with screw-locking (Соединители для электронного оборудования. Требования к изделию. Часть 2-101. Круглые соединители. Детальные технические условия для соединителей М12 с контровыми устройствами)

IEC 61131-1. Programmable controllers — Part 1: General information (Контроллеры программируемые. Часть 1. Общие положения)

IEC 61131-2, Programmable controllers — Part 2: Equipment requirements and tests (Контроллеры программируемые. Часть 2. Требования к оборудованию и испытания)

IEC/TR 62390. Common automation device — Profile guideline (Общие средства автоматики. Руководящие положения к описанию)

ISO/IEC 646:1991. Information technology — ISO 7-bit coded character set for information interchange (Информационные технологии. 7-битный набор кодированных символов ИСО для обмена информацией)

ISO/IEC 646:1991. Information technology — ISO 7-bit coded character set for information interchange (Информационные технологии. Структура кода символов и методы расширения)

ISO/IEC 10646. Information technology — Universal Multiple-Octet Coded Character Set (UCS) [Информационные технологии. Универсальный многооктетный набор кодированных символов (UCS)]

ISO/IEC 10731. Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services (Информационные технологии. Взаимодействие открытых систем. Базовая эталонная модель. Соглашения для определения служб OSI)

ISO/IEC 19505 (all parts). Information technology — Object Management Group Unified Modeling Language (OMG UML) (Информационные технологии. Унифицированный язык моделирования Рабочей группы по управлению объектами (OMG UML). (все части ISO/IEC 19505)]

ISO 1177, Information processing — Character structure for start/stop and synchronous character oriented transmission (Обработка информации. Структура символов для стартстопной и синхронной символьно-ориентированной передачи)

IEEE Std 754-2008. IEEE Standard for Floating-Point Arithmetic (Стандарт IEEE для арифметики с плавающей точкой)

Internet Engineering Task Force (IETF): RFC 5905 — Network Time Protocol Version 4: Protocol and Algorithms Specification; available at <> [Рабочая группа инженеров Интернета (IETF). Запрос комментария RFC 5905. Протокол сетевой синхронизации, версия 4. Протокол и спецификация алгоритмов; доступный по <>]

2

ГОСТ Р МЭК 61131*9—2017

3 Термины, определения, обозначения, сокращения и условные

обозначения

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

В настоящем стандарте применены термины по МЭК 61131-1 и МЭК 61131*2, а также следующие термины с соответствующими определениями:

3.1.1    адрес (address): Часть управления М-последоаательносгью е ссылочных данных для категорий данных канала связи.

3.1.2    прикладной уровень (application layer; AL): Дополнительная часть протокола <SDCI>. ответственная за передачу объектов Данных процесса и объектов Данных запроса.

3.1.3    параметр блока (block parameter): Согласованный доступ к параметрам через множественные индексы или субиндексы.

3.1 .4 контрольная сумма (checksum): Дополнительная часть совокупных мер интерфейса <SDCI> по непротиворечивости данных на канальном уровне в дополнение к биту четности UART.

3.1.5    CHKPOU (CHKPDU): Данные защиты передаваемой информации в канале связи индексированного сервисного блока данных (ISDU). сгенерированные путем сложения по модулю двух октетов запроса или ответа.

3.1.6    кодовая коммутация (coded switching): Связь SDCI. основанная на стандартных уровнях двоичного сигнала МЭК 61131-2.

3.1.7    СОМ1 (СОМ1): Режим связи SOCI со скоростью передачи данных 4.8 кбит/с.

3.1.8    COM2 (COM2): Режим связи SOCI со скоростью передачи данных 38.4 кбит/с.

3.1.9    COM3 (COM3): Режим связи SDCI со скоростью передачи данных 230.4 кбит/с.

3.1.10    СОМх (СОМх): Один из трех возможных режимов связи SOCI: СОМ1. COM2 или COM3.

3.1.11    канал связи (communication channel): Логическое соединение между Ведущим узлом и Устройством.

Примечание — Определены четыре канала связи: канал процесса, канал страницы, канал ISDU (для параметров) и канал диагностики.

3.1.12    ошибка связи (communication error): Непредвиденное нарушение в работе протокола передачи SDCI.

3.1.13    время цикла (cycle time): Время передачи М-последоеательности между Ведущим узлом и его Устройствами, включая последующее время простоя.

3.1.14    Устройство (Device): Отдельный пассивный узел сети относительно Ведущего узла, такой как датчик или исполнительное устройство.

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

3.1.15    непосредственные параметры (Direct Parameters): Параметры с прямой (страничной) адресацией, ациклически передаваемые через канал связи страниц без подтверждения.

3.1.16    динамический параметр (dynamic parameter): Часть набора параметров Устройства, определенная встроенными интерфейсами пользователя, такими как обучаемые кнопки или панели управления в дополнение к статическим параметрам.

3.1.17    Событие (Event): Экземпляр изменения условий в Устройстве.

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

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

3.1.18    возврат в исходный режим (allback): Переход порта из режима кодовой коммутации в режим коммутирующего сигнала.

3.1.19    уровень контроля (inspection level): Уровень проверки идентичности Устройства.

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

3

ГОСТ Р МЭК 61131-9—2017

3.1.21    ISDU (ISDU): Индексированный сервисный блок данных, используемый для ациклической передачи параметров с подтверждением, которые могут быть сегментированы в нескольких М-последовательностях.

3.1.22    устаревшее Устройство или Ведущий блок (legacy Device or Master): Устройство или Ведущий блок в соответствии с [8].

3.1.23    М-последовательность (M-sequence): Последовательность из двух сообщений, включающая сообщение ведущего узла и соответствующее ему сообщение Устройства.

3.1.24    управление M-последовательностью (M-sequence control): Первый октет в сообщении Ведущего узла, указывающий операцию чтения/записи. тип канала связи и адрес: например, смещение или управление потоками.

3.1.25    ошибка М-последовательности (M-sequence error): Непредвиденное или неправильное содержание сообщения или отсутствие ответа.

3.1.26    тип М-лоследовательности (M-sequence type): Отдельный особенный формат M-последовательности или набор специфических форматов М-лоследовательности.

3.1.27    Ведущий узел (Master): Активный одноранговый узел сети, присоединенный через порты к одному или более Устройствам (вплоть до п) и обеспечивающий интерфейс к шлюзу для систем связи более высокого уровня или PLC.

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

3.1.28    сообщение (message): Последовательность <SDCI> фреймов UART, передаваемая либо от ведущего узла к его Устройствам, либо в обратном направлении, в соответствии с правилами протокола SDCI.

3.1.29    Данные запроса (On-request Data: OD): Ациклически передаваемые данные по запросу от приложения Ведущего узла, состоящие из параметров или данных События.

3.1.30    физический уровень (physical layer; PL): Первый уровень эталонной модели взаимодействия открытых систем OSI. который предоставляет механические, электрические, функциональные или процедурные средства для активации, поддержки и деактивации физических соединений для передачи битов между объектами канального уровня.

Примечание — Физический уровень также предоставляет средства для процедур пробуждения и во> врата в исходное состояние.

[ИСТОЧНИК: ИСО/МЭК 7498-1:1994. 7.7.2. изменено — текст удален из статьи, добавлено примечание]

3.1.31    порт (port): Интерфейс среды передачи данных Ведущего узла к одному Устройству.

3.1.32    режим работы порта (port operating mode): Состояние порта Ведущего узла, которое может быть: INACTIVE. DO. Dl. FIXEDMODE или SCANMODE.

3.1.33    Данные процесса (Process Data): Входные или выходные значения от или к дискретному или непрерывному процессу автоматизации, циклически передаваемые с высоким приоритетом и е сконфигурированной последовательности после запуска Ведущего узла.

3.1.34    цикл Данных процесса (Process Data cycle): Законченная передача всех Данных процесса от или к отдельному Устройству, которая может включать несколько циклов в случае сегментации (расслоения).

3.1.35    отдельный параметр (single parameter): Доступ к независимому параметру через один отдельный Индекс или Субиндекс.

3.1.36    стандартный ввод/вывод; SIO (SIO): Режим работы порта в соответствии с цифровым вводом и выводом, определенным в МЭК 61131-2, который установлен после включения питания, возврата в исходное состояние или неудачных попыток передачи данных.

3.1.37    статический параметр (static parameter): Часть набора параметров Устройства, сохраняемая Ведущим узлом на случай замены без использования технических средств.

3.1.36 коммутирующий сигнал (switching signal): Двоичный сигнал от или к Устройству при нахождении в режиме SIO (в отличие от «кодовой коммутации» передачи данных SDCI).

3.1.39 модуль управления системой (system management; SM): Средства <SDCI> для управления и координации внутренних слоев связи и исключений внутри Ведущего узла и его портов и внутри каждого Устройства.

4

ГОСТ Р МЭК 61131-9—2017

3.1.40    фрейм UART (UART frame): Последовательность битое <SDCI>. начинающаяся со стартового бита, с последующими восемью битами, несущими октет данных следующим битом четности, и оканчивающаяся одним стоповым битом.

3.1.41    пробуждение (wake-up): Процедура, заставляющая Устройство изменить его режим с SIO на SDCI.

3.1.42    запрос пробуждения (wake-up request: WURQ): Услуга физического слоя, используемая Ведущим узлом для инициирования пробуждения Устройства и помещения его в состояние готовности приема.

3.2 Обозначения и сокращения

В настоящем стандарте применены следующие обозначения и сокращения: д/otru — допустимое отклонение в скорости передачи данных (измеренное в %):

ДУб — пульсация питающего напряжения (измеренная в В):

AL — прикладной уровень:

ВЕР — вероятность битовой ошибки:

СЮ — соединение для передачи данных (С) или коммутирующего сигнала SIO (Q);

CLe„ — эффективная общая емкость кабеля (измеренная в нФ);

СО — входная емкость соединения C/Q (измеренная е нФ);

DI — цифровой вход:

DL — канальный уровень:

DO — цифровой выход:

/DTR — скорость передачи данных (измеренная в бит/с):

НА. — еысокий/ниэкий сигнал на выходе приемника:

I/O — ввод/вывод;

ILL — ток входной нагрузки на входе СЮ в V0 (измеренный в А);

IODD — описание устройства ввода/вывода (см. 10.8):

кз — ток драйвера в насыщенном рабочем состоянии (измеренный в А):

ЮН — ток драйвера верхнего плеча в насыщенном рабочем состоянии ON (измеренный в А):

IQL — ток драйвера нижнего плеча в насыщенном рабочем состоянии ON (измеренный в А): ЮРК — максимальный ток драйвера в ненасыщенном рабочем состоянии ON (измеренный

в А):

ЮРКН — максимальный ток драйвера верхнего плеча в ненасыщенном рабочем состоянии ON (измеренный в А):

IQPKL — максимальный ток драйвера нижнего плеча в ненасыщенном рабочем состоянии ON (измеренный в А):

100 — ток в рабочей точке на входе СЮ в Уд с неактивными выходными драйверам (измеренный

в А):

IOwu — амплитуда тока запроса пробуждения ведущего узла (измеренный в А):

IS — питающий ток в У+ (измеренный в А);

ISIR —-допустимый импульс тока в V+ (измеренный в А):

LED — светоизлучающий диод;

L— источник питания (-):

L+ — источник питания (♦);

N24 — дополнительный источник питания 24 В (-); nW(J — счетчик повторных попыток пробуждения:

On/Off — сигнал переключения ON/OFF драйвера;

OD — данные запроса;

OVD — обнаружен избыточный сигнал;

Р24 — дополнительный источник питания 24 В {+):

PD — данные процесса:

PDCT — инструмент конфигурирования порта и устройства:

PL — физический уровень;

PLC — программируемый логический контроллер;

PS — напряжение источника питания (измеренное в В);

5

ГОСТ Р МЭК 61131-9—2017

г — время достижения устойчивого уровня относительно начала стартового бита {измеренный в 7в1тХ

RLell — сопротивление шлейфа кабеля (измеренное в Ом);

s — время выхода на устойчивый уровень относительно начала стартового бита (измеренный в Тв|Т);

SDCI — одноточечный интерфейс цифровой связи;

SIO — стандартный авод/еывод (режим цифровой коммутации) [IEC 61131-2] управление системой; SM — модуль управления системой;

/, — задержка передачи фрейма UART на Ведущем узле (измеренная в ГВ1Т);

/, — задержка передачи фрейма UART на Устройстве (измеренная в ГВ(Т);

/д — задержка ответа на Устройстве (измеренная в Гв|Т);

ГВ!Т — время передачи бита (измеренное в с);

tcYc — время цикла на уровне М-последовательности (измеренное в с); tDF — время слада (измеренное в с);

Томт — время задержки при установлении порта связи Ведущего узла (измеренное в Та/Г);

Тоя — время нарастания сигнала (измеренное в с);

Г08Ю — время задержки на устройстве для перехода в режим SIO после запроса пробуждения (измеренное в с);

70WU — задержка повторной попытки пробуждения (измеренная в с);

fM.sequence — продолжительность М-последовательности (измеренная в Гв,т);

/^1' — время простоя между Двумя М-последовательности (измеренное в с); tH — время обнаружения для верхнего плеча (измеренное в с); tL — время обнаружения для нижнего плеча (измеренное в с); tND — время подавления шума (измеренное в с);

TRDL — время готовности к пробуждению после включения питания (измеренное в с);

TREN — время подготовки к получению сигнала (измеренное в с);

7*so — время обнаружения устройства (измеренное в с);

Twu — длительность импульса запроса пробуждения (измеренная в с);

UART — универсальный асинхронный приемник-передатчик;

UML — универсальный язык моделирования UML (ИСО/МЭК 19505];

V+ — напряжение в L+;

V0 — напряжение в L-;

VD+l — перепад напряжения в линии между соединениями L+ на Ведущем узле и Устройстве (измеренный в В);

VD0l — перепад напряжения в линии между соединениями L- на ведущем узле и Устройстве (измеренный в В);

VDQl — перепад напряжения в линии между соединениями C/Q на Ведущем узле и Устройстве (измеренный в 8);

VHYS — гистерезис порогового напряжения приемника (измеренный в В);

VI — входное напряжение в соединении линии C/Q относительно V0 (измеренное в В);

VIH — диапазон входного напряжения в соединении C/Q для верхнего плеча (измеренный в В); VIL — диапазон входного напряжения в соединении C/Q для нижнего плеча (измеренный в 8); VRO — остаточное напряжение на драйвере в насыщенном рабочем состоянии ON (измеренное

в В);

VRQH — остаточное напряжение на драйвере верхнего плеча в насыщенном рабочем состоянии ON (измеренное в В);

VRQL — остаточное напряжение на драйвере нижнего плеча в насыщенном рабочем состоянии ON (измеренное в 8);

VTH — пороговое напряжение приемника относительно V0 (измеренное в В);

VTHH — пороговое напряжение приемника для безопасного обнаружения высокого сигнала (измеренное в В);

VTHL — пороговое напряжение приемника для безопасного обнаружения низкого сигнала (измеренное в В};

WURQ — запрос пробуждения.

6

ГОСТ Р МЭК 61131*9—2017

3.3 Условные обозначения

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

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

3.3.2    Параметры обслуживания

Сервисные примитивы применяются для представления взаимодействий провайдера услуг и их потребителя (ИСО/МЭК 10731). Сервисные примитивы передают параметры, которые указывают на информацию, имеющуюся при взаимодействии провайдера и потребителя. В конкретном интерфейсе нет необходимости явно формулировать все параметры.

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

1)    имя параметра.

2)    примитив запроса (.req);

3)    примитив индикации (.ind);

4)    примитив ответа (.rsp);

5)    примитив подтверждения (.cnf).

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

М — обязательный параметр для примитива;

U — параметр является возможностью пользователя: он может представляться или опускаться в зависимости от конкретного использования услуги пользователем. Если параметр не представлен, предполагается значение параметра по умолчанию:

С — параметр зависит от других параметров или от среды пользователя услуги:

--параметр никогда не применяется;

S — параметр является выделенным объектом.

Некоторые строки более детально классифицируются элементами в скобках. Такими элементами могут являться:

a)    специфическое ограничение параметра «(=)» указывает, что параметр семантически эквива* лентен значению параметра, указанному в сервисном примитиве;

b)    указание, что к строке таблицы применяется некоторое примечание «л», означает, что данное примечание «л» содержит дополнительную информацию, относящуюся к параметру и его испольэо* ванию.

3.3.3    Сервисные процедуры

Процедуры определяются в терминах:

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

•    взаимодействий между провайдером и потребителем услуг слоя связи в системе через вызов сервисных примитивов.

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

3.3.4    Атрибуты услуги

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

I — Инициатор услуги (по отношению к слою более высокого уровня).

R — Получатель (ответчик) услуги (из слоя более высокого уровня).

3.3.5    Рисунки

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

•    стрелка, имеющая только имя услуги, представляет как запрос, так и соответствующее подтверждение (запрос следует по направлению стрелки);

7

ГОСТ Р МЭК 61131-9—2017

. запрос без подтверждения, а также все указания и ответы, помеченные как таковые (т. е. seivice.req.

service.ind. service.rsp).

Пример услуги с подтверждением показан на рисунке 1.

Инициатор Ответчик

Service req

Service.cnf

Servicelnd

Service rsp

Рисунок 1 — Пример подтвержденного сообщения 3.3.6 Порядок передачи октета

На рисунке 2 показано, как типы данных, основанные на слове (WORD), передаются из памяти в среду передачи данных и наоборот (т. е. старший октет передается первым, см. 7.3.3.2 и 7.3.6.1).

Обратный порядок байтов в— в зависимости от архитектуры

используемого микроконтроллера

Прямой порядок бейтов

Адреса

памяти

п + 1

»

«

Адреса

памяти

о

время передами

Обозначения

MSO - семье ствршхй октет LSO — самый младший октет.

Рисунок 2 — Запоминающее устройство и порядок передачи для типов данных, основанных на слове (WORD)

3.3.7 Поведенческое описание

Для поведенческого описания применяется нотация языка UML 2 (ИСО/МЭК 19505) (например, понятия: состояние, последовательность, действие, временные диаграммы, сторожевые условия). Расположение соответствующих таблиц перехода состояний соответствует IEC/TR 62390.

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

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

8

ГОСТ Р МЭК 61131*9—2017

4 Обзор одноточечного интерфейса цифровой связи SDCI (Ю-Link™)

4.1 Назначение технологии

На рисунке 3 показана основная концепция технологии SDCI.

4.8/364/2304 «бит*

ЛЛЛЛГ

14ШМП

Си*»**

(И» мигни»

Спм*|»

1

С*

246

СС 61121-2

2

га

Н* подою-ен. 01 иго* 00

вС 61131-2

3

L-

ее

вс вил-г

4

о

«КотгТфроцяА аиип» DL

ОО(вЮ)

«С 61121-2

с

«Кодам* коииутятм» (СОМ!. COM2 COM3}

вС 61121-6

всбомде-г

Рисунок 3— Совместимость SOCI с МЭК 61131-2

Технология одноточечного интерфейса цифровой связи для небольших датчиков и исполнительных устройств SDCI (более известных под названием Ю-Link™) определяет направление перехода от существующих интерфейсов цифрового ввода и цифрового вывода для коммутационных 24-вольтоеых Устройств, как установлено в МЭК 61131-2. к каналам связи между двумя пунктами. Так. например, цифровые модули I/O в существующих периферийных устройствах полевой шины могут быть заменены модулями Ведущего узла SDCI. обеспечивая как классические интерфейсы цифрового I/O, так и SDCI. Технология аналоговой передачи может быть заменена SDCI. сочетая присущие SDCI устойчивость, параметризацию и диагностические возможности с сохранением возможностей цифро-аналогового и аналого-цифрового преобразования.

4.2 Позиционирование в иерархии средств автоматизации

На рисунке 4 показана область применения технологии SDCI в иерархии средств автоматизации.

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

Отправной точкой в проектировании SDCI является традиционный интерфейс 24 В DI и DO, определенный в МЭК 61131-2 и показанный в таблице 6. Таким образом, технология SDCI предлагает подключаемость классических датчиков 24 В («коммутирующих сигналов») в качестве операционного режима по умолчанию. Дополнительная подключаемость обеспечивается для исполнительных устройств, когда порт сконфигурирован в режиме одноточечного интерфейса цифровой связи.

В настоящее время многие датчики и исполнительные устройства уже оборудованы микроконтроллерами. предлагающими интерфейс UART. который может быть расширен добавлением нескольких аппаратных компонентов и программным обеспечением интерфейса для поддержки связи SDCI. Данный второй операционный режим применяет «кодовую коммутацию» линии сигналов I/O 24 В. После активации режим SDCI поддерживает параметризацию, циклический обмен данными, диагностическую отчетность, информацию по идентификации и технической поддержке и память внешних параметров для резервирования Устройств и быстрой перезагрузки замененных устройств. Датчики и исполнительные устройства с возможностями SDCI именуются в настоящем стандарте «Устройствами». Для улучшения запуска данные Устройства, как правило, предоставляют энергонезависимую память для параметров.

Примечание — Конфигурирование и параметризация Устройств поддерживается с помощью описания устройства на базе XML (см. [6]}. которое не является частью настоящего стандарта.

9

ГОСТ Р МЭК 61131-9—2017

ППК или ведущая машта

Контроллер полевой шины

I I

Сервер

параметров

Объединение

полевых шин

SDCI

ft J

Хреиипице Д»«<ых

Порт 1    Порт 2 Порт О

Интерфейс полевой щам

Межсетевое приложение

Ведущий дал

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

Устройство

Устройство

Устройство

Приложение

Приложение

Приложение

Описание

Устройстве

Рисунок 4 — Сфера применения технологии SOCI е иерархии средств автоматизации

4.3    Проводка, соединители и электропитание

Соединение по умолчанию (порт класса А) имеет четыре контакта (см. рисунок 3). Порт по умолчанию для порта класса А соответствует МЭК 60947-5-2 и применяет три провода для 24 В. 0 В и сигнальной линии. Четвертый провод может применяться для дополнительной сигнальной линии, соответствующей МЭК 61131-2.

Соединения с пятью контактами (порт класса В) устанавливаются для Устройств, требующих дополнительного питания от независимого источника питания 24 8.

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

Максимальная длина кабелей — 20 м. экранирование не требуется.

4.4    Возможности связи SDC!

Обобщенная модель Устройства показана на рисунке 5 и объясняется в следующих разделах.

Устройство может получать PD (вывод) для управления дискретным или непрерывным процессом автоматизации или посылать PD (ввод), представляющие текущее состояние или значения измерений. Как правило. Устройство предоставляет параметры, позволяющие пользователю конфигурировать функции Устройства для удовлетворения конкретных потребностей. Для поддержки этого определено большое пространство параметров с доступом через Индекс (0... 65535; с предварительно определенной организацией) и Субиндекс (0 ... 255).

Первые два значения индекса 0 и 1 зарезервированы для страниц 1 и 2 Непосредственных параметров с максимальной длиной 16 октетов каждая. Страница 1 параметров в основном предназначена для команд Ведущего узла, таких как запуск Устройства и его возврат в исходное состояние, извлечение специфической операционной и идентификационной информации Устройства. Страница 2 параметров предусматривает максимум 16 октетов специфических параметров Устройства.

10

ГОСТ Р МЭК 61131-9—2017

Данные процесса

бхорныа

o>wm о эг

вьхаамм ехгетыО 31

Параметры и команды

232    0

OxFFFF[-rr,~ .............~тттх

Память Событий {диагностика)

On*rw 0.32

1S    О

Рисунок 5 — Обобщенная модель Устройства для SDCI (с точки зрения Ведущего узла)

Другие индексы (2 ... 65 535) обеспечивают доступ к одной записи с максимальным размером 232 октета. Субиндекс 0 определяет передачу полной записи, адресуемой Индексом, другие субиндексы определяют передачи отобранных элементов из записи.

В пределах записи отдельные элементы данных могут начинаться с любого битового смещения, и их длина может быть в пределах от 1 бита до 232 октетов, но общее число элементов данных в записи не может превышать 255. Организация элементов данных в записи определяется в IODD.

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

Связь между Ведущим узлом и Устройством осуществляется из точки в точку и основывается на принципе, что сначала Ведущий узел посылает сообщение, а затем Устройство посылает ответное сообщение (см. рисунок 36). Оба сообщения вместе называются M-последовательностью. Определяется несколько типов М-последовательности для поддержания требований пользователя к передаче данных (см. рисунок 37).

Данные различных категорий передаются через различные каналы связи на DL. как показано на рисунке 6.

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

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

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

11

ГОСТ Р МЭК 61131-9—2017

Характер данных

On*C*UM

Категории дантх ема бн»ал Достсмрны».

Канал связи

Прсикс

Тип передачи

иислмисмй IK VUVNW««0)

Рисунок 6 — Отношения между характеристиками данных и типами передачи

Первый октет сообщения Ведущего узла определяет направление передачи данных (чтение или запись) и тип канала связи.

На рисунке 7 показано, что каждый порт Ведущего узла имеет свой собственный DL. обеспечивающий сопряжение с общим AL Ведущего блока. На AL услуги DL транслируются в действия с объектами PD (ввод/еывод). объектами 00 (чтение/запись) и Событиями. Приложения Ведущего узла включают в себя: Управление конфигурацией (СМ), механизм Хранилища данных (OS). Блок диагностики (DU). Обмен Данными запроса (ООЕ) и Обмен Данными процесса (PDE).

SM проверяет идентификацию подключенных Устройств и настраивает порты и Устройства, чтобы они соответствовали выбранной конфигурации и свойствам подключенных Устройств. Модуль контролирует состояние машин на AL и DL, например, при запуске.

4.5 Роль Ведущего узла

Ведущее устройство размещает от 1 до л портов и их соответствующих DL. Во время запуска оно изменяет состояние порта на режим, выбранный пользователем. Возможные состояния порта: INACTIVE (неактивное). DI. DO. FIXEDMODE (фиксированный режим) или SCANMODE (режим сканирования). Если затребована связь. Ведущий узел применяет специальный импульс тока пробуждения для инициации связи с Устройством. Затем Ведущий узел автоматически настраивает скорость передачи данных для портов СОМ1. COM2 или COM3 (см. таблицу 6) и проверяет «паспорт» каждого подключенного устройства, т. е. идентификатор изготовителя VendortD. идентификатор Устройства DevicelD и характеристики связи.

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

Допускается также запустить устройство в режиме DI, переключить на связь SDCI для конфигурирования и параметризации и затем применить команду «fallback» возврата в исходный режим (см. 11.8.5) для переключения назад в режим DI для нормального функционирования.

Координация портов также является задачей Ведущего блока, который пользователь может конфигурировать путем выбора режима цикла порта. В режиме «FreeRunning» («Автономный») каждый порт определяет собственный цикл, основываясь на свойствах подключенного Устройства. 8 режиме «MessageSync» («Синхронизация сообщений») сообщения, посланные на подключенные порты, активизируются одновременно или в определенном шахматном порядке. В режиме «FixedValue» («Фиксированное значение») каждый порт применяет определенное пользователем фиксированное время цикла (см. 11.2.2.2).

12

ГОСТ Р МЭК 61131-9—2017

Пртлшной уровень (AL)

Коиапьмый

УРС*ОМ>(00

*и>ич«с<мй

)Р0вИ% <Ы)

Аиммм*с<н« каммча с**}и ' (мпрм)

* -я

fcdl

ЦмЯИЧММА К4ИАП «ОМИ

(День— npmwo«)

Рисунок 7 — Передача объекта данных на AL

Ведущий узел ответственен за сборку и разборку всех данных от Устройств к Устройствам {см. раздел 11).

Ведущий узел предоставляет область DS размером не менее 2048 октетов на Устройство для резерв* ного копирования данных Устройства (см. 11.3). Ведущий узел может комбинировать эти данные Устройства с другими подходящими данными для собственных цепей, делать эти данные доступными для приложения более высокого уровня сцепью создания резервной копии или управления набором параметров (см. 11.8.3).

4.6    Конфигурирование SDCI

Инженерно-техническое обеспечение Ведущего узла, как правило, производится РОСТ. PDCT регулирует как свойства порта, так и свойства Устройства (см. параметры, показанные на рисунке 5). PDCT сочетает как интерпретатор IODD, так и конфигуратор (см. 11.7). IODD обеспечивает необходимые свойства для организации связи и необходимые параметры с их границами для достижения требуемой функции датчика или исполнительного устройства. РОСТ также поддерживает компиляцию PD для передачи на полевую шину и в обратном направлении.

4.7    Отображение на полевые шины

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

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

Интеграция РОСТ в инженерно-технические инструментальные средства конкретной полевой шины находится вне области применения настоящего стандарта.

13

ГОСТ Р МЭК 61131-9—2017

4.8 Структура стандарта

На рисунке б показана логическая структура Ведущего узла и Устройства. PL SDCI устанавливается в разделе 5. подробное описание режима SIO устанавливается в разделе 6. Услуги DL. протокол, пробуждение. М-последовательности и обработчики DL устанавливаются в разделе 7. Услуги и протокол AL устанавливаются в разделе 8. функциональные обязанности SM устанавливаются в разделе 9.

Вздутия ум»

Устройство

CM OS 006 DU РОЕ

SM

AL

DL

01

01

PL

PL

PL

РМ

06

ЕО

РОЕ

AL

SM

DL

а

♦    У

Срзд* пздздм донных

Рисунок В — Логическая структура Ведущего узла и Устройства

В разделе 10 устанавливаются приложения Устройства и его характерные особенности. Приложения включают в себя: PDE. PM, DS и Диспетчер событий (ЕО). Специфические технологические приложения не являются частью настоящего стандарта. Эти приложения могут описываться в профилях для конкретных семейств Устройств.

В разделе 11 устанавливаются приложения Ведущего узла и его характерные особенности. Приложения включают в себя: РОЕ. ODE. Управление конфигурацией CM. DS и DU.

В настоящий стандарт включено несколько обязательных и справочных приложений. В приложении А устанавливаются доступные типы М-последовательностей. 8 приложении В устанавливаются параметры страницы Непосредственных параметров и фиксированных параметров Устройства. В приложении С приведены типы ошибок при ациклических передачах, а в приложении D — коды Событий (диагностическая информация Устройств). В приложении Е приведены доступные базовые и составные типы данных. В приложении F приведена структура объектов DS. В приложении G описаны вопросы соответствия и электромагнитной совместимости, а в приложении Н приведены кривые вероятностей остаточных ошибок, подтверждающие уровень целостности данных SDCI. В приложении I дан пример последовательности ациклических передач данных. В приложении J объясняются два рекомендуемых метода для определения изменений параметров в контексте OS.

5 Физический уровень (PL)

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

5.1.1    Базовая комплектация

Система 3-лроводных присоединений SDCI основана на спецификациях, приведенных в МЭК 60947-5-2. Три линии применяются следующим образом: (L+) — для источника питания 24 В: (L-) — для линии заземления и (СЮ) — для коммутирующего сигнала (Q) или связи SDCI (С), как показано на рисунке 9.

Рисунок 9 — Система 3-проводного соединения

Примечание 1 —Двоичные датчики, соответствующие МЭК 60947-5-2. совместимы с системой 3-про-вод ного присоединения SDCI (в том числе с точки зрения энергопотребления).

14

ГОСТ Р МЭК 61131-9—2017

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

Порт класса А применяет четырехконтактный соединитель. Четвертый провод может применяться для дополнительной сигнальной линии в соответствии с МЭК 61131-2. Поддержка четвертого провода необязательна как в Ведущих узлах, так и в Устройствах.

Присоединения с пятью проводами (порт класса В) устанавливаются для Устройств, требующих дополнительного питания от независимого источника литания 24 В.

Примечание 2 — Устройство с портом класса А применяющее четвертый провод, несовместимо с Ведущим узлом с портом класса В.

5.1.2 Топология

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

5.2 Услуги физического уровня

5.2.1 Обзор

На рисунке 11 даются обзор PL Ведущего узла и его сервисные примитивы.

Модул» (прмпеиия е»*сг*мой

ООрвбОТчм портях

PL.3MMoM.req

Обрболм» шмип

Канальный уровень

од|в1<ячк стЯтмЛ

PL.WakeUp.wq

PL.Tranttar raq

810

01/00

PL.TwmMt Ind

а со

•vx

i < i <

. .1.j. i i

П|рвп««там> |мм

Нмктиамый

Пробужден»    Кадома коммутация

уромнь (порт)

X—tfTfy «пикетам»

По

мгоху

С рода гшеюзлл данные

Рисунок 11 — Физический уровень (Ведущий узел)

PL определяет операции линии C/Q на рисунке 3 и связанный драйвер линии (передатчик) и приемник конкретного порта. Ведущий узел управляет этой линией в трех основных режимах (см. рисунок 11): неактивном. «Коммутирующий сигнал» (OI/DO) или «Кодовая коммутация» (СОМх). Услуга PL.SetMode.req отвечает за переключение в один из данных трех режимов.

Если порт находится в неактивном режиме, линия C/Q будет высокоимпедансной (слабонагру-женной). В режиме SIO порт может применяться как стандартный входной или выходной интерфейс

15

ГОСТ Р МЭК 61131-9—2017

в соответствии с определениями МЭК 61131-2 или таблицей 6 соответственно. Уровни связи SOCI обходятся. как показано на рисунке 11; сигналы прямо обрабатываются в приложении Ведущего узла. В режиме SDCI услуга PL.WakeUp.req создает специальный сигнал-шаблон (импульс тока), который может обнаруживаться Устройством с SOCI. подключенным к этому порту (см. S.3.3.3).

На рисунке 12 даются обзор PL Устройства и его сервисные примитивы.

Модп» ртрвтмй системой

Обработчик ЛМИИИ СВЯЗИ

Канальный уровень

06p«60tv*M

канального уровня

VerpoActoa

ОФуСосмя ссойч»'«*>

ею

OI/DO

I

Pl.SetMode f*q

PL.WaHeUp.ntf

PL.TrantMr-M

PL .Trawler/eq

t

i

_ i _

• i

.1. J_

Паи

Пробукявии*    Кодовая коымутрт

Фиэичесмй уровень

КсамчглфроарМ «кмал

Ооея

I-

Среда переори датах

_I

Рисунок 12 — Физический уровень (Устройство)

PL Устройства в соответствии с рисунком 12 следует тем же принципам, за исключением того, что здесь нет неактивного состояния. По умолчанию при включении питания или восстановлении соединения кабеля Устройство будет работать в режиме SIO. как цифровой ввод. Устройство всегда будет способно определить импульс тока пробуждения (запрос пробуждения). Услуга PL_WakeUp.ind сообщает об успешном обнаружении запроса пробуждения (обычно прерывания микроконтроллера), который требуется Устройству для переключения в режим SDCI.

Специальная команда Ведущего узла (fallback), посланная через SOCI. заставляет Устройство переключиться обратно в режим SIO.

После этою определяются услуги, которые предоставляются PL SM и DL (полный обзор данных услуг приводится на рисунках 83 и 94). 8 таблице 1 приведены назначения Ведущего узла и Устройства как инициатора и приемника для отдельных услуг PL.

Таблица 1 — Назначение услуг Ведущего узла и Устройства

Имя услуги

ведущий у»ел

Устройство

PL.SetMode

R

R

PL.WakeUp

R

I

PL.Transfer

1/R

R/1

Обозначения (см. 3.3.4):

I — Инициатор услуги:

R — Приемник (Ответчик) услуги.

5.2.2 Услуги Физического уровня

5.2.2.1 Услуга PL.SetMode

Услуга PL.SetMode применяется для установки электрических характеристик и конфигураций PL. Параметры сервисных примитивов приведены в таблице 2.

Таблица 2 — Услуга PL.SetMode

Имя параметра

год

Argument

м

TargentMode

м

16

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Специфические для услуги параметры запроса услуги передаются е параметре Аргумент. TargetMode (ЦелевойРежим)

Данный параметр указывает затребованный операционный режим.

Допустимые значения:

-    INACTIVE (линия СЮ имеет высокий импеданс):

-    D! (линия СЮ находится в режиме цифрового ввода);

-    D (линия СЮ находится в режиме цифрового вывода);

•    СОМ1 (линия СЮ находится в режиме СОМ1);

•    COM2 (линия СЮ находится в режиме COM2);

•    COM3 (линия СЮ находится в режиме COM3).

S.2.2.2 Услуга PL_WakeUp

Услуга PL_WakeUp инициирует или указывает специальную последовательность, которая подготавливает PL к посылке и приему запросов связи (см. S.3.3.3). Данная неподтверждаемая услуга не имеет параметров. Ее успех может быть подтвержден только Ведущим узлом через попытку установления связи с Устройством. Сервисные примитивы приведены е таблице 3.

Таблица 3 — Услуга PL_WakeUp

Имя параметра

.req

md

«отсутствуют»

5.2.2.3 Услуга PL_Transfer

Услуга PL_Transfer применяется для обмена данными SDCI между DL и PL. Параметры сервисных примитивов приведены в таблице 4.

Таблица 4 — Услуга PL_Transfer

Имя параметра

,req

ind.

Argument

Data

M

M

Result (+)

S

Result (-)

S

Status

M

Argument (Аргумент)

Специфические для услуги параметры запроса услуги передаются е параметр Аргумент. Data (Данные)

Данный параметр содержит значения данных, которые переданы через интерфейс SDCI. Допустимые значения 0 ... 255.

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что запрос услуги был выполнен успешно.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что запрос услуги завершился неуспешно.

Status (Состояние)

Данный параметр содержит дополнительную информацию о состоянии передачи. Допустимые значения:

-    PARfTY_ERROR (UART обнаружил ошибку четности);

-    FRAMING_ERROR (недопустимый стоповый бит UART);

• OVERRUN (конфликт октетов в UART).

17

ГОСТ Р МЭК 61131-9—2017

5.3 Передатчик/приемник

5.3.1    Метод описания

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

5.3.2    Электрические требования

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

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

В рабочем состоянии ON описательными переменными являются остаточное напряжение VRO. номинальный ток драйвера Ю и пиковый ток ЮРК. Источник управляется сигналом включения/выклю-чения On/Off. Наличие тока перегрузки указывается на выходе «Перегрузка». Данная возможность может применяться для обнаружения импульса тока (пробуждения).

Приемник определяется эталонной схемой в соответствии с рисунком 14. Приемник выполняет функции компаратора и характеризуется порогом переключения VTH и гистерезисом VHYS между порогами переключения. Выход показывает логический уровень (Высокий или Низкий) на входе приемника.

пц>

ч»

/ум;

Рисунок 13 — Эталонная схема драйвера линии    Рисунок 14 — Эталонная схема приемника

На рисунке 15 показана эталонная схема взаимодействия Ведущего узла и Устройства для системы 3-проводного присоединения SDCI.

Устройство    Лшмясмии    Ведуний ухл

По выбору: драйвер нижнего плеча (только двухтактный).

Рисунок 15 — Эталонная схема системы 3-лроаодного присоединения SDCI

18

ГОСТ Р МЭК 61131-9—2017

Следующие рисунки и таблицы параметров относятся к определениям уровня напряжения, показанным на рисунке 16. Индексы параметра относятся к Ведущему узлу (М). Устройству (D) или линии (L). Перепады напряжения в линии VD+L, VDQ и VD\ неявно определяются в подразделе 5.5 через параметры кабеля.

'*’0

Устройство

|*0Мо

Пимяисеяэи

(X,

пу/.

»Тп

вмвес

Ввод

fWL

tZMfi

IV»

VkOi

м

ввод    Внеаа

Рисунок 16 — Определения уровня напряжения

гг..

5.3.2.2 Приемник

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

Таблица 5 — Электрические характеристики приемника

Свойство

Наине кование

Минимум

Норма

Максимум

единица измеряйия

Примечание

VTHHqjm

Входной порог высокого сигнала

10.5

Н/Д

13

в

См. примечание 1

^«О.И

Входной порог низкого сигнала

8

нГд

11.5

в

См.примечание 1

WYSom

Гистерезис между входными порогами высокого и низкого сигналов

0

нГд

нГд

в

Не должен быгь отрицательным.

См.примечание 2

W^O.M

Допустимый диапазон напряжений низкого сигнала

«Ь.м-VO

кГд

нГд

в

Относительно соответствующего отрицательного напряжения питания

V*k>M

Допустимый диапазон напряжений высокого сигнала

н/д

нГд

^о.м+1.0

в

Относительно соответствующего положительного напряжения питания

Примечание 1 — Пороги совместимы с определениями цифровых вводов типа 1 в соответствии с МЭК 61131-2.

Примечание 2 — Напряжение гистерезиса VHYS = VTHH- VTHL

19

ГОСТ Р МЭК 61131-9—2017

На рисунке 17 показаны пороги переключения для определения низкого и высокого сигналов.

УЬы

Г»

Диапазон налрптни*

•неодето сигнал»

ПННшж

l-THUux

Порог вмокого сигнала И'/Шгмн

Перо* низкого сиоола WHLum

ГО

Диэлозсн напртеки* косого сигнала

Рисунок 17 — Пороги переключения

5.3.2.3 Порт ведущего узла

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

Таблица 6 — Электрические характеристики порта Ведущего узла

Свойство

Наименование

Минимум

Норма

Максимум

Единица

измерения

Примечание

vsu

Напряжение питания для Устройств

20

24

30

в

См. рисунок 16

Ч.

Ток питания для Устройств

200

н/д

н/д

мА

Для токов свыше 200 мА требуется внешний источник питания

'Sift»

Возможности импульса тока для Устройств

400

н/д

н/д

мА

Возможность тока литания Ведущего узла для минимального периода 50 мс при 18 В после включения питания порта

'“м

Ток нагрузки или гок разряда для:

0 В < V1M < 5 В;

5 В < VIM < 15 В: 15 В < VIM < 30 В

0

5

5

н/д

н/д

н/д

15

15

15

мА

мА

мА

См. примечание 1

vroh,a

Остаточное напряжение высокого сигнала

и/д

«Щ

3

в

Перепад напряжения относительно V+u при максимальном токе драйвера

юн»

wkx«

Остаточное напряжение низкого сигнала

н/д

н/д

3

В

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

ЮЦл

10Н»

Ток драйвера постоянного тока высокого сигнала

100

н/д

н/д

мА

20

ГОСТ Р МЭК 61131-9—2017

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

Свойство

Минимум

Норма

Максимум

Единица

измерения

Примечание

ЮРКНм

Выходной пиковый ток высокого сигнала

500

Н/Д

н/д

мА

Абсолютная величина.

См.примечание 2

,0Ч*

Ток драйвера постоянного тока низкого сигнала

100

н/д

н/д

мА

ЮРК^

Выходной пиковый ток низкого сигнала

500

н/д

н/д

мА

Абсолютная величина.

См. примечание 2

СОи

Входная емкость

н/д

Н/д

1.0

нФ

/ = от 0 до 4 МГц

Примечание 1 — Токи совместимы с определениями цифровых вводов типа 1 в МЭК 61131-2. Тем не менее для диапазона 5 В < WM < 15 В минимальный ток равен 5 мА вместо 2 мА. чтобы достичь достаточно низких скоростей нарастания в Устройствах, снабженных только драйвером переключения питания.

Примечание 2 — Ток запроса пробуждения (см. 5.Э.З.З).

5.3.2.4 Устройство

Определения в таблице 7 действительны для электрических характеристик Устройства.

Таблица 7 — Электрические характеристики Устройства

Свойство

Минимум

Норма

Максимум

Единица

измерения

Примечание

1«Ь

Напряжение питания

18

24

30

В

См. рисунок 16

Пульсация

н/д

н/д

1.3

в

Границы полного размаха абсолютного знамения не должны быть превышены. (^.«до 100 кГц

VRQHq

Остаточное напряжение высокого сигнала

н/д

н/д

3

в

Перепад напряжения относительно 1/+0<МЭК 60947-5-2)

VRQLv

Остаточное напряжение низкого сигнала

н/д

н/д

3

в

Перепад напряжения относительно

юн0

Ток на выходе драйвера постоянного тока переключения питания (е состоянии On)

50

н/д

Минимум

(ЮЯМ.м)

мА

Минимальное значение из-за возврата к цифровому выводу в соответствии с МЭК 61131-2. тип 2

«*о

Ток на выходе драйвера постоянного тока пи-ташя (в состоянии On)

0

н/д

Минимум

{ЮРКН")

мА

Только для стадий двухтактного выхода

ЮОо

Ток в рабочей точке к VOq (состояние Off)

0

н/д

15

мА

Ток при понижающемся напряжении или остаточный ток при деактивированном драйвере

со0

Входная емкость

0

н/д

1.0

нФ

Эффективная емкость мведу C/Q и L+ или L- Устройства в состоянии приема

21

ГОСТ Р МЭК 61131-9—2017

Значение 1 нФ применимо для скорости передачи данных 230.4 кбит/с. Входная емкость СО0 может быть увеличена до 10 нФ в случае двухтактной конструкции при работе на меньших скоростях передачи данных при условии, что все требования к динамическим параметрам, установленные в 5.3.3.2. соблюдены.

5.3.3 Временные требования

5.3.3.1 Способ передачи данных

Для побитового кодирования применяется модуляция без возврата к нулю. Логическое значение «1» соответствует разности напряжений 0 8 между линиями СЮ и L-. Логическое значение «0» соответствует разности напряжений 24 В между пиниями C/Q и L-.

Уровень разомкнутой цепи на линии СЮ относительно линии L- равен 0 В. Стартовый бит имеет логическое значение «0». т. в. *24 В.

Для кодирования по октетам данных применяется фрейм UART. Формат фрейма UART в технологии SDCI — это строка битов, структурированная, как показано на рисунке 1в.

передаваемая nocnaoveaiWbHocib биго»

Весе битов информации

Стартовый бит (ST|

1-й

2 3

4 5 6 7 8 9

!sb

21

msb

I 0

J

DO М

Ь2 | ЬЗ | Ь4 | Ь5 | Ь6 | Ь7

Отт деы«»а

10

Р

11-й

Бит четности (дополнение до четного}-1

Один столовый бит (SP)-

Обозначения:

Isb — младший бит: msb — старший бит.

Рисунок 18 — Формат фрейма UART в технологии SOC1

Определение формата фрейма UART основано на ИСО 1177 и ИСО/МЭК 2022.

5.3.3.2 Характеристики передачи данных

Временные характеристики передачи данных демонстрируются в форме глазковой диаграммы с допустимыми диапазонами сигналов (см. рисунок 19). Данные диапазоны применимы для приемника как в Ведущем узле, так и в Устройстве.

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

Приемник будет обнаруживать биты, как сигнал допустимой формы в допустимом диапазоне глазковой диаграммы на соединении линии СЮ. Формы сигнала в областях «необнаружения» (ниже VTHLuax или VTHHMitl и в пределах /ы0) не будут приводить к недопустимым битам.

Для того чтобы фреймы UART правильно обнаруживались, на стороне приемника должны быть характеристики сигнала, показанные на рисунке 20. Должно учитываться время задержки сигнала между сигналом линии СЮ и фреймом UART. Время Тв,т всегда указывает на скорость передачи битов в приемнике.

Для каждого бита л в битовой последовательности (п*1 ... 11) фрейма UART время (п - O^bit (см. таблицу 8 для значений t) определяет время, через которое будет достигаться правильный уровень в диапазонах высокого и низкого сигналов, как продемонстрировано в глазковой диаграмме на рисунке 19. время (л - s) TBIT (см. таблицу 8 для значений s) описывает время, которое будет проходить до изменения уровня. Если возникают вопросы по характеристикам сигнала, всегда следует обращаться к глазковой диаграмме на рисунке 19.

22

ГОСТ Р МЭК 61131-9—2017

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

Динамические характеристики передачи данных приведены в таблице 8.

1) — не обнаружен низкий сигнал: 2} — не обнаружен высокий сигнал.

Рисунок 19 — Глазкоаая диаграмма для обнаружения высокого и низкого сигналов

BIT

(2-д) 7‘,

BIT

(3-д) 7,

в гг

(Ю ч>7,

BIT

8IT

Рисунок 20 — Глазковая диаграмма для правильного обнаружения фрейма UART

23

ГОСТ Р МЭК 61131-9—2017

Таблица 8 — Динамические характеристики передачи данных

Свойство

Нвиыемоевнив

Минимум

Норме

Максимум

Единица

измерения

Примечание

Ьтя

Скорость передачи

н/д

4.6

н/д

кбиг/с

СОМ1

данных

38,4

COM2

230,4

COM3

ГВ1Т

Время передачи бита

при 4.6 кбмг/с

208,33

МКС

при 38,4 кбит/с

26.04

МКС

при 230.4 кбит/с

4.34

МКС

^ОТРМ

Точность скорости пе-

Допуск скорости

редачи Ведущего узла

передачи Ведущего

при 4.8 кбиг/с

-0.1

н/д

+ 0.1

%

узла Д76{ТВ|Т

при 38,4 кбит/с

-0.1

н/д

+ 0.1

%

при 230.4 кбит/с

-0.1

н/д

+ 0.1

%

Г

Начало времени об-

В каждом случае

нэружения бита от-

вычисляется от

носительно переднего

0.65

н/д

н/д

конца бита при ин-

фронта стартового

тервале выборки

бита

UART. равном 8

S

Конец времени обнару-

В каждом случае

жения бита относитегъ-

вычисляется от

но переднего фронта

н/д

н/д

0.22

конца бита при ин-

стартового бита

тервале выборки UART. равном 8

Время нарастания

0

н/д

0.20

W

Относительно еди-

при 4.8 кбиг/с

0

н/д

41.7

МКС

ницы измерения

при 38,4 кбит/с

0

н/д

5.2

МКС

времени передачи

при 230.4 кбит/с

0

н/д

869

НС

бита

fDF

Время отката при не-

Относительно еди-

удаче

0

н/д

0.20

*вгт

ницы измерения

при 4.8 кбиг/с

0

н/д

41.7

МКС

времени передачи

при 38.4 кбит/с

0

н/д

5 2

МКС

бита

при 230,4 кбит/с

0

Н/д

869

нс

^0

Время подавления

н/д

Н/д

1/16

W

Допустимый период

шума

времени приемного сигнала еыше/ниже

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

обнаружения

Время обнаружения

1/16

н/д

н/д

ГВ(Т

Период времени

высокого сигнала

приемного сигнала над порогом обнаружения для высокого уровня

Время обнаружения

1/16

н/д

н/д

Период времени

низкого сигнала

приемного сигнала лад порогом обна-

ружения для низкого уровня

Параметры г и s применяются к соответствующей стороне приемника Ведущего узла или Устройства. Такое определение позволяет дать более гибкое определение точности генератора, деформации бита и скорости нарастания. Общая деформация ширины бита на последнем бите фрейма UART предоставляет правильную оценку уровня в диапазоне рисунка 20.

24

ГОСТ Р МЭК 61131-9—2017

5.3.3.3 Импульс тока пробуждения

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

Вызов услуги PL_WakeUp.req на DL инициирует процесс пробуждения (см. 5.2.2.2).

Запрос пробуждения (WURQ) начинается с импульсом тока, возбужденным Ведущим узлом (в порту), на период времени rwu. Запрос пробуждения включает в себя следующие фазы (см. рисунок 21):

a)    подача Ведущим узлом тока IQWU в зависимости от уровня в соединении линии C/Q. Для входного сигнала, соответствующего логической «1». это ток источника: для логического сигнала, соответствующего логическому «О», это токовый сток:

b)    время задержки на Устройстве до наступления готовности к приему.

WURO может быть обнаружен Устройством через изменение напряжения в линии C/Q или вычисление тока соответствующего элемента драйвера в период времени 7WU. На рисунке 21 показаны примеры Устройства с малой выходной мощностью.

Ткт

Рисунок 21 — Запрос пробуждения

В таблице 9 определены ток и временные характеристики, связанные с запросом пробуждения. Значения IQPKLи ЮРКНи приводятся в таблице 6.

Таблица 9 — Характеристики запроса пробуждения

Свойство

Наименование

Минимум

Норма

Максимум

Единица

измерений

Примечания

Avu

Амплитуда импульса тока пробуждения Ведущего узла

ЮРКЦд

или

ЮРКНм

нГд

нГд

мА

Импульс тока с последующим состоянием переключения Устройства

rwu

Длительность импульса тока пробуждения Ведущего узла

75

кГд

В5

МКС

Свойство Ведущего узла

Tren

Задержка готовности к приему

Hfa

нГд

500

МКС

Свойство Устройства

5.4 Источник питания

5.4.1 Опции источника питания

Система присоединения SOCI обеспечивает выделенные линии питания в дополнение к линии сигнала. Секция связи Устройства всегда будет питаться Ведущим узлом, применяя линии питания, определенные в системе 3-проводной связи (Источник литания 1).

25

ГОСТ Р МЭК 61131-9—2017

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

. через линии питания системы S-проводного присоединения SDCI (порты класса А), применяя Питание 1;

• через дополнительные линии питания системы 5-лроеодного присоединения SDCI (порты класса В), применяя дополнительный источник питания в Ведущем узле (Питание 2):

- через локальный источник питания в Устройстве (зависит от конструкции).

Порт класса А допускает потребление тока до 200 мА. как указано в таблице 6. Максимальное потребление энергии в порте класса В зависит от выбранного метода. Соединение М12 позволяет увеличивать ток до 3.5 А.

5.4.2 Требования к подаче питания

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

Рисунок 22 — Регламент подачи питания для источника Питания 1

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

Таблица 10 — Регламент подачи литания

Свойство

Наименование

Минимум

Норна

Максимум

Единица

измерения

Примечания

*RDl

Готовность к пробуждению после подачи питания

н/д

Н/д

300

мс

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

Примечание — Эквивалентно времени задержки до готовности в соответствии с МЭК 60947-5-2.

5.5 Среда передачи данных

5.5.1 Соединители

Назначение контактов Ведущего узла и Устройства основано на спецификациях, приведенных в МЭК 60947-5-2. с расширениями, определенными в разделах ниже. Порты класса А применяют соединители М5. Мб и М12 не более чем с четырьмя контактами. Порты класса В применяют

26

ГОСТ Р МЭК 61131-9—2017

только соединители М12 с пятью контактами. Соединители М12 имеют код «А» е соответствии с МЭК 61076-2-101.

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

Гнездовые соединители предназначены для Ведущего узла, а штекерные соединителя — для Устройства. 8 таблице 11 приведены назначения контактов и на рисунке 23 показано расположение и механическое кодирование для соединений М12. М8 и М5.

Таблица 11—Схема назначений контактов

Контакт

Сигнал

Наименование

Примечание

1

L+

Источник литания {+)

См. таблицу 7

2

I/QP24

NC/DI/DO (порт класса А) Р24 (порта класса В)

Опция 1: NC (не соединен).

Опция 2: Dt (цифровой ввод).

Опция 3: DI — сконфигурированный ОО.

Опция 4: Дополнительный источник питания для мощных Устройств (порт класса В)

3

L-

Источник питания {-)

См. таблицу 7

4

C/Q

SIO/SDCI

Режим SIO (DI/DO) или SDCI (электрические характеристики ОО см. в таблице 6)

5

NC

NC (порт класса А)

Опция 1: Не соединяется на стороне Ведущего узла (порт класса А).

N24

N24 (порт класса В)

Опция 2: Ссылка на дополнительный источник питания (порт класса В)

Примечание — Соединение М12 всегда исполняется в версии с пятью контактами на стороне Ведущего узла (гнездовое).

Класс А

Класс А    КлассВ

\

Соединители М12

> имеют trace А е соответствии с МЭК МОТб-2-lQf

М5    М8    М12-5    М12-5

Рисунок 23 — Расположение контактов (вид спереди)

27

ГОСТ Р МЭК 61131-9—2017

На рисунке 24 показано расположение двух классов портов — А и В. Порты класса В должны быть маркированы для их отличия от портов класса А. так как данные классы портов несовместимы.

2

1

4

3

$

Порт класса А (М12)

1МИ

ЦВИМ2

Олмв 1: мсн»м«'|>1

Огщ« t С>

Опцт кО. чив ОО

lew

мамаев

смен»**

lamt

МММ«

Dt: СОМх; ОО

Порт класса В (М12)

3 1

4 3

5

>' ' I Защита

Рисунок 24 — Определения портов классов А и В

5.5.2 Кабель

Среда передачи данных связи SDCI — многожильный кабель с тремя или более жилами. Определения в следующих разделах неявно охватывают определения статического напряжение, показанные в таблице 5 и на рисунке 16. Для обеспечения функциональной надежности свойства кабеля должны соответствовать таблице 12.

Таблица 12 — Характеристики кабеля

Свойство

Минимум

Норма

Максимум

Единица

измерения

Длина

0

Н/Д

20

м

Полное сопротивление шлейфа RL^f

К/Д

Н/Д

6.0

Ом

Эффективная емкость линии CL^

к/д

н/д

3.0

нФ (< 1 МГц)

Сопротивление шлейфа RLeff и эффективная емкость линии CLcff могут быть измерены, как показано на рисунке 25.

и*

С=5 С/0( L-

iv.................................:

—•

г :::::::::: :::...;.::*

U_1111_)

28

Рисунок 25 — Схема измерения эффективной емкости линии и сопротивления шлейфа

ГОСТ Р МЭК 61131*9—2017

В таблице 13 приведены токоведущие жилы кабеля и назначенные им цветовые коды. Таблица 13 — Схема кабельного соединителя

Си1нап

Наименование

Цвет

Примечание

L-

Источник питания {-)

Синий**

Систем 3-проводного соединения SDCI

CiQ

Сигнал связи

Черный*1

Систем 3-проводного соединения SDCI

L*

Источник питания {+)

Коричневый**

Систем 3-проводного соединения SDCI

I/O

Цифровой ввод или цифровой вывод

Белый**

Необязательный

Р24

Дополнительный источник питания (+}

Любой другой

Необязательный

N24

Дополнительный источник питания (-)

Любой другой

Необязательный

•> В соответствии с МЭК 60947-5-2.

6    Стандартный ввод и вывод (SIO)

На рисунках 83 и 94 показано, как режим SIO позволяет Устройству обходить уровни связи SDCI и отображать сигналы цифрового ввода D! или цифрового вывода DO прямо в сообщение обмена данными шины или системы более высокого уровня. Переход между режимами SDCI и SIO определя* ется конфигурацией пользователя или (неявно) услугами приложений Ведущего узла. SM следит за соответствующей инициализацией или деактивацией уровней связи SDCI и PL (переключатель режима). Характеристики интерфейсов сигналов DI и DO извлекаются из характеристик, установленных в МЭК 61131-2 для типа 1.

7    Канальный уровень (DL)

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

Канальные уровни SDCI обеспечивают доставку сообщений между Ведущим узлом и Устройством через физический канал. DL применяет несколько типов М-последовательностей («последовательностей сообщений») для различных категорий данных.

Набор услуг DL доступен AL для обмена PD и OD. Другой набор услуг DL доступен SM для поиска и выборки идентификационных параметров Устройства и установки конечных машин на DL. DL применяет успуги PL для управления PL и для обмена фреймами UART. DL следит за обнаружением ошибок в сообщениях (как внутренних, так сообщенных из PL) и предпринимает подходящие меры по их устранению.

DL структурируются по категории данных, в обработчике PD и OD. которые, в свою очередь, применяют обработчик сообщений для требуемой передачи сообщений. Специальные режимы портов Ведущего узла, такие как пробуждение. СОМх и SIO (деактивация связи), требуют выделенных обработчиков DL в DL Ведущего узла. Модуляция сигнала пробуждения требует обнаружения сигнала на стороне Устройства и. следовательно, обработчиков DL на стороне Устройства. Каждый обработчик включает собственную конечную машину.

DL подразделяется на секцию DL-Ac собственными внутренними услугами и секцию DL-В с внешними услугами.

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

На рисунке 26 показан обзор структуры и услуг DL Ведущего узла.

29

ГОСТ Р МЭК 61131-9—2017

Примечание —Используются условные обозначения пункта 3.3.5.

Рисунок 26 — Структура и услуга DL (Ведущий узел)

На рисунке 27 показан обзор структуры и услуг DL Устройства.

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

Рисунок 27 — Структура и услуги DL (Устройство)

30

ГОСТ Р МЭК 61131-9—2017

7.2 Услуги канального уровня

7.2.1    Услуги секции DL-В канального уровня

7.2.1.1    Обзор услуг в ведущем узле и Устройстве

В разделе 7 устанавливаются услуги DL. предоставляемые AL и SM через внешние интерфейсы OL. В таблице 14 приведены распределения Ведущею узла и Устройства их ролям инициатора и приемника для отдельных услуг DL. Пустые поля указывают, что данная услуга отсутствует на Ведущем узле или Устройстве.

Таблица 14 — Распределение услуг в Ведущем узле и Устройстве

Имя услу>и

Ведущий yien

Устройство

DL_ReadParam

R

1

DL_WriteParam

R

1

DLJSDUTransport

R

1

DLJSDUAbort

R

1

DL_PDOutput Update

R

DL_PDOutpu1Transport

1

DL_PDlnputUpdate

R

DL_PDtnputTransport

1

DL_PDCyc*e

1

1

DL_SetMode

R

DL.Mode

1

1

DL_Event

1

R

DL_EventConf

R

DL_EventTrigger

R

DL_Contrd

I/R

R/I

DL.Read

R

1

DL.Write

R

1

Обозначения (см. 3.3.4):

1 — Инициатор услуги;

R — Приемник (ответчик) услуги.

В подразделе 3.3 приводятся условные обозначения и объясняется, как читать описания услуг, приведенных в 7.2, 8.2.9.2.2 и 9.3.2.

7.2.1.2 Услуга DL_ReadParam

Услуга DL_ReadParam применяется AL для чтения значений параметров из Устройства через канал связи страниц. Параметры сервисных примитивов приведены е таблице 15.

Таблица 15 — Услуга Dl_ReadParam

Имя параметра

.roq

cnf

ind

Argument

M

M

Address

M

M

Result {-)

s

Value

M

Result {-)

s

Errodnfo

M

31

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

Address (Адрес)

Данный параметр содержит адрес параметра, затребованного Устройством, т. е. адреса параметров Устройства на канале связи страницы (см. таблицу В.1).

Допустимые значения 0 ... 31.

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Value (Значение)

Данный параметр содержит считанные значения параметров Устройства.

Result (-) (ОтрицателькыйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна).

7.2.1.3 Услуга DL_WriteParam

Услуга DL_WriteParam применяется AL для записи значения параметра в Устройства через канал связи страниц. Параметры сервисных примитивов приведены в таблице 16.

Таблица 16 — Услуга DL_WrHeParam

Имя параметра

.req

cnf

.ind

Argument

M

M

Address

M

M

Value

M

M

Result (-)

s

Result {-)

s

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

Address (Адрес)

Данный параметр содержит адрес параметра, затребованного Устройством, т. е. адреса параметров Устройства на канале связи страницы.

Допустимые значения от 16 до 31 е соответствии с правами доступа параметра Устройства. Value (Значение)

Данный параметр содержит подлежащее записи значение параметра Устройства.

32

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

ГОСТ Р МЭК 61131-9—2017

Result (-) {ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errolnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM {нет доступной связи):

STATE_CONFLICT {в текущем состоянии услуга недоступна).

7.2.1.4 Услуга DL_Read

Услуга DL_Read применяется SM для чтения значения параметра Устройства через канал связи страниц. Параметры сервисных примитивов приведены в таблице 17.

Таблица 17 — Услуга DL_Read

Имя параметра

.req

cnf

.ind

Argument

M

M

Address

M

M

Result (+)

s

Value

M

Result (-)

s

Errolnfo

M

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

Address (Адрес)

Данный параметр содержит адрес параметра, затребованного Устройством, т. е. адреса параметров Устройства на канале связи страницы (см. таблицу В.1).

Допустимые значения от 0 до 15 в соответствии с правами доступа параметра Устройства. Result (+) (ПоложительныйРвзультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Value (Значение)

Данный параметр содержит считанные значения параметров Устройства.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Errolnfor (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO__COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна).

7.2.1.5 Услуга DL_Write

Услуга DL_Write применяется SM для записи значения параметра в Устройство через канал связи страниц. Параметры сервисных примитивов приведены в таблице 16.

33

ГОСТ Р МЭК 61131-9—2017

Таблица 18 — Услуга DL_Write

Имя параметра

.re q

cnf

»nd

Argument

M

M

Address

M

M

Value

M

M

Result (+)

S

Result <-)

s

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

Address (Адрес)

Данный параметр содержит адрес параметра, затребованного Устройством, т. е. адреса параметров Устройства на канале связи страницы.

Допустимые значения от 0 до 15 в соответствии с правами доступа параметра Устройства. Value (Значение)

Данный параметр содержит подлежащее записи значение параметра Устройства.

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна).

7.2.1.6 Услуга DLJSDUTransport

Услуга DLJSDUTransport применяется для передачи ISDU. Данная услуга применяется Ведущим узлом для посылки запроса услуги из AL Ведущего узла в Устройство. Она также применяется Устройством для посылки ответа на запрос услуги из AL Устройства. Параметры сервисных примитивов приведены в таблице 19.

Таблица 19 — Услуга DLJSDUTransport

Имя параметра

.гея

.md

.Cflf

.res

Argument

M

M

ValueList

M

M

Result (+)

s

s

Data

c

c

Descriptor

M

M

Result (-)

s

s

ISDUTransportErrorlnfo

M

M

34

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

ValuoList (СписокЗначений)

Данный список содержит используемые рабочие параметры.

Тип параметра: Запись.

Index (Индекс)

Допустимые значения 2 ... 65 535 (ограничения описаны в В.2.1).

Subindex (Субиндекс)

Допустимые значения 0 ... 255.

Data (Данные)

Тип параметра: Строка октетов.

Direction (Направление)

Допустимые значения:

READ (операция Чтения);

WRITE (операция Записи).

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Data (Данные)

Тип параметра: Строка октетов.

Descrirtor (Описатель)

Допустимые значения: ответ на запрос I-Service Устройства в соответствии с таблицей А.12. Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

ISDUTransportErrorlnfo (ИнформацияОбОшибкеТранспорта130и)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна);

ISDU_TIMEOUT (время подтверждения ISDU истекло, см. таблицу 97); SDU_NOT_SUPPORTED (ISDU не реализован):

VALUE_OUT_OF_RANGE (значение параметра услуги нарушает границы диапазона).

7.2.1.7 Услуга DLJSDUAbort

Услуга DLJSDUAbort прекращает текущую передачу 1SDU. Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 20.

Таблица 20 — Услуга DLJSDUAbort

Имя параметра

тер

.Cflf

<отсутсг8уюг>

Услуга возвращает подтверждение после прекращения передачи ISDU.

35

ГОСТ Р МЭК 61131-9—2017

7.2.1.6 Услуга DL_PDOutpirtUpdate

Прикладной слой Ведущего узла применяет услугу DL_PDOutputUpdate для модификации данных вывода (PD от Ведущего узла к Устройству) на OL. Параметры сервисных примитивов приведены е таблице 21.

Таблица 21—Услуга DL_PDOutputUpdate

Имя параметра

rep

.cnt

Argument

M

OutputData

M

Result (+)

S

TransportStatus

M

Result (-)

S

Errortnfo

M

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

OutputData (ДанныеВывода)

Данный параметр содержит PD. предоставленные прикладным слоем.

Тип параметра: Строка октетов.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

TransportStatus (СостояниеТранспорта)

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

Допустимые значения:

VES (передача данных разрешена):

N0 (передача данных не разрешена).

Reslut (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfor (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна).

7.2.1.9 Услуга DL_PDOutputTranspoit

DL на Устройстве применяет услугу DL_PDOutputTransport для передачи содержания выходных PD AL (от Ведущего узла к Устройству). Параметры сервисных примитивов приведены в таблице 22.

Таблица 22 — Услуга DL_POOutputTranspoft

Имя параметра

ind

Argument

M

OutputData

M

36

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

OutputData (ДанныеВывода)

Данный параметр содержит PD. передаваемые прикладному слою.

Тип параметра: Строка октетов.

7.2.1.10 Услуга Dl_PDInputUpdate

Прикладной слой Ведущего узла применяет услугу DL_POInputUpdate для модификации входных данных (РО от Устройства к Ведущему узлу) на DL. Параметры сервисных примитивов приведены в таблице 23.

Таблица 23 — Услуга DL_PDInputUpdate

Имя параметра

rep

.Cflf

Argument

M

InputData

M

Result (+)

s

TransportStatus

M

Result (-)

s

Errortnfor

M

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

InputData (ДанныеВвода)

Данный параметр содержит PD. предоставленные прикладным слоем.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

TransportStatus (СостояниеТранспорта)

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

Допустимые значения:

YES (передача данные разрешена);

N0 (передача данные не разрешена).

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна).

7.2.1.11 Услуга DL_POInputTransport

DL на Устройстве применяет услугу DL_PDInputTransport для передачи содержания входных PD (от Устройства к Ведущему узлу) AL. Параметры сервисных примитивов приведены в таблице 24.

37

ГОСТ Р МЭК 61131-9—2017

Таблица 24 — Услуга DL_POInputTransport

Имя параметра

ind

Argument

М

InputData

м

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

InprtOata (ДанныеВвода)

Данный параметр содержит PD, передаваемые прикладному слою.

Тип параметра: Строка октетов.

7.2.1.12 Услуга DL_PDCycle

DL применяет услугу DL_PDCycle для указания конца цикла PD AL.

Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 25.

Таблице 25 — Услуга£>L_PDCycle

Имя параметра

ind

«отсутствуют»

7.2.1.13 Услуга DL_SetMode

Услуга DL_SetMode применяется управлением системой для создания конечной машины канального слоя и посылки характеристических значений, требуемых для работы на DL. Параметры сервисных примитивов приведены в таблице 26.

Таблица 26 — Услуга DL_SetMode

Имя параметра

.enf

Argument

M

Mode

M

ValueList

U

Result (+)

s

Result (-)

s

Errortnfro

M

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

Mode (Режим)

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

INACTIVE (обработчик изменяет состояние на INACTIVE);

STARTUP (обработчик изменяет состояние на STARTUP):

PREOPERATE (обработчик изменяет состояние на PREOPERATE);

OPERATE (обработчик изменяет состояние на OPERATE).

ValueList (СписокЗначений)

Данный список содержит используемые рабочие параметры.

Структура данных: Запись.

38

ГОСТ Р МЭК 61131-9—2017

M-SequenceTime (ДлительностьМ-лоследовательности): (для передачи обработчику сообщений).

M-SequenceType (ТипМ-последовательности): (для передачи обработчику сообщений).

Допустимые значения:

TYPE_0:

TYPE_1_1, TYPE_1_2, TYPE_1_V;

TYPE_2_1. TYPE_2_2. TYPE_2_3. TYPE_2_4. TYPE_2_5. TYPE_2_6, TYPE_2_V;

(TYPE_1_1 задает режим расслоения при передаче РО и 00. см. 7.3.4.2).

POInputLength (ДлинаВходныхДП): (для передачи обработчику сообщений). POOutputLength (ДлинаВыходныхДП): (для передачи обработчику сообщений). OnReqDataLengthPerMessage (ДлинаДЗНаСообщение): (для передачи обработчику сообщений).

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

STATE_CONFLICT (в текущем состоянии услуга недоступна):

PARAMETER_CONFLICT (нарушена корректность набора параметров).

7.2.1.14 Услуга DL_Mode

AL применяет услугу DL_Mode для уведомления SM о достижении определенного рабочего состояния. Параметры сервисных примитивов приведены в таблице 27.

Таблице 27 — DL.Mode

Имя параметра

md

Argument

М

RealMode

М

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре. RealMode (РеальныйРежим)

Данный параметр указывает на текущее состояние обработчика DL. Допустимые значения:

INACTIVE (обработчик изменяет состояние INACTIVE):

СОМ1 (установлен режим СОМ1);

COM2 (установлен режим COM2):

COM3 (установлен режим COM3):

COMLOST (связь потеряна);

ESTABCOM (обработчик изменил состояние на EstablishCom); STARTUP (обработчик изменил состояние на STARTUP): PREOPERATE (обработчик изменил состояние на PREOPERATE): OPERATE (обработчик изменил состояние на OPERATE).

39

ГОСТ Р МЭК 61131-9—2017

7.2.1.15 Услуга DL_Event

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

Таблица 28 — DL_Event

Имя параметра

rep

ind

Argument

M

M

Instance

M

M

Type

M

M

Mode

M

M

EventCode

M

M

EventsLeft

M

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

Instance (Экземпляр)

Данный параметр указывает источник События.

Допустимые значения: Приложение (см. таблицу А.17).

Туре (Тип)

Данный параметр указывает категорию События.

Допустимые значения ERROR. WARNING. NOTIFICATION (см. таблицу А19).

Mode (Режим)

Данный параметр указывает режим События.

Допустимые значения SINGLESHOT. APPEARS. DISAPPEARS (см. таблицу А.20).

EventCode (КодСобытия)

Данный параметр содержит код. идентифицирующий определенное Событие (см. таблицу D.1). Тип параметра: 16-битовое целое без знака.

EventsLeft (ОсталосьСобытий)

Данный параметр указывает число необработанных Событий.

7.2.1.16 Услуга DL_EventConf

Услуга DL_EventConf подтверждает переданные События через обработчик Событий. Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 29.

Таблица 29 — Услуга DL_EventConf

Имя параметра

rep

.Cflf

«отсутствуют»

7.2.1.17 Услуга DL_EventTrigger

Запрос DL.EventTrigger начинает сигнализацию События [см. Event flag (флаг События) на рисунке А.З] и «замораживает» память События на DL. Подтверждение возвращается после того, как

40

ГОСТ Р МЭК 61131-9—2017

обработаны активированные События. Дополнительные запросы услуги DL_EventTrigger игнорируются до подтверждения предыдущего события (см. 7.3.8. 8.3.3 и рисунок 84). Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 30.

Таблица 30 — DL_EventTrigger

Имя параметра

•'«Я

.cnf

<отсутсгвуюг>

7.2.1.18 Услуга Dl_Control

Ведущий узел применяет услугу DL_Conlrol для передачи управляющей информации через механизм команд Ведущего узла соответствующему приложению Устройства, зависящему от используемой технологии, и получает управляющую информацию через механизм флага состояния РО (см. А.1.5) и услугу PDInStatus (см. 7.2.2.5). Параметры сервисных примитивов приведены в таблице 31.

Таблица 31—УслугаOL_Control

Имя параметра

.cnf

Argument

М

м

ControlCode

М

М(=>

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

ControlCode (УпраеляющийКод)

Данный параметр указывает статус описателя PD.

Допустимые значения:

VALID (входные PD допустимы: см. 7.2.2.S, 8.2.2.12):

INVALID (входные PD недопустимы):

PDOUTVALID (выходные PD допустимы; см. 7.3.7.1);

PDOUTINVALID (выходные PD недопустимы или отсутствуют).

7.2.2 Услуги уровня DL-A

7.2.2.1 Обзор

В соответствии с подразделом 7.1 данные DL разделяются на верхний уровень DL-B и нижний уровень DL-A. Уровень DL-A включает обработчик сообщений, как показано на рисунках 26 и 27.

Обработчик событий Ведущего узла кодирует команды и данные в сообщения и посылает Данные сообщения в подключенное Устройство на PL. Он получает сообщения от Устройства на PL и переправляет их содержание соответствующим обработчикам в форме подтверждения. Если в событии Устройства установлен флаг События «Event flag» (см. А.1.5). обработчик сообщений ведущего узла вызывает услугу EventFlag. чтобы проинструктировать обработчик Событий.

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

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

В таблице 32 приведены распределения Ведущего узла и Устройства по их ролям, как инициатора (I) или получателя (R) в контексте исполнения их конкретных услуг DL-A.

41

ГОСТ Р МЭК 61131-9—2017

Таблица 32 — Услугу! уровня DL-Ана Ведущем узле и Устройстве

Имя услуги

Ведущим узел

Устройство

OD

R

I

PD

R

I

EvenlFlag

I

R

PDInStatus

I

R

MHInfo

I

I

ODTrig

I

PDTrig

I

7.2.2.2 Услуга OD

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

Таблица 33 — УслугаOD

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

RWDirection (НаправлениеЧЗ)

Данный параметр указывает на направление передачи: чтение или запись.

Допустимые значения:

READ (операция Чтения);

WRITE (операция Записи).

ComChannel (КаналСвяэи)

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

Допустимые значения: DIAGNOSIS. PAGE. ISDU (см. таблицу А.1).

AddressCtrll (АдресКоитроль)

Данный параметр содержит адрес или значение управления потоком (см. А.1.2). Допустимые значения от 0 до 31.

42

ГОСТ Р МЭК 61131-9—2017

Length (Длина)

Данный параметр содержит длину передаваемых данных.

Допустимые значения от 0 до 32.

Data (Данные)

Данный параметр содержит передаваемые данные.

Тип данных: Строка октетов.

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Data (Данные)

Данный параметр содержит значения прочитанных данных.

Length (Длина)

Данный параметр содержит длину полученного пакета данных.

Допустимые значения от 0 до 32.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfor (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна).

7.2.2.3 Услуга PD

Услуга PD применяется для подготовки PD. посылаемых по каналу связи процесса. Подтверждение услуги содержит данные от приемника. Параметры сервисных примитивов приведены в таблице 34.

Таблица 34 — Услуга PD

Имя параметра

гея

.*nd

-rap

xnf

Argument

M

M

PDInAddress

C

C<=)

PDInLength

C

C<=)

PDOut

C

C<=)

PDOutAddress

c

C<=)

PDOutLength

c

C(=)

Result (+)

S

s

PDIn

C

C<=)

Result (-)

S

s

Errortnfo

M

M(=>

43

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой данные передаются е данном параметре.

PDInAddress (ВхДанныеПроцессаАдрес)

Данный параметр содержит адрес затребованных входных PD (см. 7.3.4.2).

PDInLength (ВхДаниыеПроцессаДлина)

Данный параметр содержит адрес затребованных входных PD.

Допустимые значения от 0 до 32.

PDOut (ВыхДанныеПроцесса)

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

Тип данных: Строка октетов.

PDOutAddress (ВыхДанныеПроцесеаАдрес)

Данный параметр содержит адрес переданных выходных PD (см. 7.3.4.2).

PDOutLength (ВыхДанныеПроцессаДлина)

Данный параметр содержит длину переданных выходных РО.

Допустимые значения от 0 до 32.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

PDIn (ВхДаниыеПакета)

Данный параметр содержит PD. подлежащие передаче из Устройства к Ведущему узлу.

Тип данных: Строка октетов.

Result (-) (ОтрицателькыйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_COMM (нет доступной связи);

STATE_CONFLICT (в текущем состоянии услуга недоступна).

7.2.2.4 Услуга EventFlag

Услуга EventFlag устанавливает или сообщает состояние флага События «Event flag» (см. А.1.5) во время циклической связи. Параметры сервисных примитивов приведены в таблице 35.

Таблица 35 — Услуга EventFlag

Имя параметра

rep

.aid

Argument

Flag

М

м

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

44

Flag (Флаг)

Данный параметр содержит значение флага События «Event flag».

Допустимые значения: TRUE («Event flag» = 1); FALSE («Event flag» - 0).

ГОСТ P МЭК 61131-9—2017

7.2.2.S Услуга PDInStatus

Услуга POInStatus устанавливает и сообщает значение допустимости входных PD. Параметры сервисных примитивов приведены в таблице 36.

Таблица 36 — PDInStatus

Имя параметра

тер

.ind

Argument

Status

М

М

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

Status (Состояние)

Данный параметр содержит индикатор допустимости переданных входных РО.

Допустимые значения:

VALID (входные PD допустимы на основе флага состояния PD (см. А. 1.5); см. 7.2.1.18): INVALID (входные PD недопустимы).

7.2.2.6 Услуга MHInfo

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

Таблица 37 — УслугаМН1п(о

Имя параметра

ind

Argument

MHInfo

М

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

MHInfo (ИнформацияОбработчикаСообщений)

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

Допустимые значения:

COMLOST (связь потеряна);

ILLEGAL_MESSAGETYPE (обнаружена M-последовательность неожиданного типа); CHECKSUM_MISMATCH (обнаружена ошибка контрольной суммы).

7.2.27 Услуга ODTrig

Услуга ODTrig доступна только на ведущем узле. Услуга запускает обработчик OD. и затем обработчики ISDU. Команд и Событий несут ответственность за предоставление OD (через услугу OD) для следующего сообщения ведущего узла. Параметры сервисных примитивов приведены в таблице 38.

Таблица 38 — Услуга ODTrig

Имя параметра

ind

Argument

DataLength

М

45

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой данные передаются в данном параметре.

DataLength (ДлинаДанных)

Данный параметр содержит доступное пространство для OD на сообщение.

7.2.2.8 Услуга PDTrig

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

Таблица 39 — Услуге PDTrig

Имя параметра

.ind

Argument

м

DataLength

м

Argument (Аргумент)

Определяемые услугой данные передаются в аргументе.

DataLength (ДлинаДанных)

Данный параметр содержит доступное пространство для PD на сообщение.

7.3 Протокол канального уровня

7.3.1 Обзор

На рисунках 26 и 27 показаны структура DL и его компоненты; обработчик режима DL. обработчик сообщений, обработчик PD и обработчик OD для предоставления определенных услуг, в 7.3.2—7.3.6 устанавливается поведение (динамика Данных обработчиков) средствами конечных машин языка UML и таблиц переходов.

Обработчик OD поддерживает три независимых типа данных: ISDU. команда и Событие. Поэтому три дополнительные конечные машины работают вместе с конечной машиной обработчика OD. как показано на рисунке 28. Дополнительная последовательность или диаграммы деятельности демонстрируют некоторые сценарии использования. См. IEC/TR 62390 и ИСО/МЭК 19505.

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

Конечная машина Обработчик ИСБД

Конечная машина Обработчик команд

Коне 1»ал машина Обработчик Событий

Конечная машина Обработчик Данных процесса

Кокетая машина Обработчик Данных по запросу

Конечная машина Обработчик режима канального уровня

Комыыоя машина Обработчик сообщений

Рисунок 28 — Конечные машины канального уровня

46

ГОСТ Р МЭК 61131*9—2017

7.3.2 Обработчик канального уровня

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

Обработчик DL. показанный на рисунке 26. несет ответственность за установку связи SOCI. при* меняя услуги PL и внутренние административные вызовы, и контролирует обработчик сообщений, а также состояния других обработчиков.

Обработчик DL. показанный на рисунке 27. несет ответственность за обнаружение запроса пробуждения и установление связи. Он получает команды Ведущего узла для синхронизации с состояниями STARTUP. PREOPERATE и OPERATE обработчика DL Ведущего узла и управляет активацией и деактивацией обработчиков сообразно обстоятельствам.

7.3.2.2    Процедуры пробуждения и правила соответствия Устройства

Управление системой запускает следующие действия на DL с помощью услуги DL_SetMode (затребованный режим = STARTUP).

Обработчик DL Ведущего узла пытается установить связь через запрос пробуждения (PLJ/VakeUp. req) с M-последовательностью TYPE_0 (чтение «MinCydeTime») в соответствии с последовательностью. показанной на рисунке 29.

Устройство

Запуе*

Вкатинго ухла

СОМ1

Звпус

Устройства

Рисунок 29 — Пример попытки установления связи

После запроса пробуждения (WURO), определенного в 5.3.3.3, обработчик DL требует, чтобы обработчик сообщений послал первое тестовое сообщение через промежуток времени TREN (см. таблицу 9) и Гомт (см. таблицу 40). Установленные скорости передачи данных портов СОМ1. COM2 и COM3 применяются в нисходящем порядке, пока не будет получен ответ, как показано на рисунке 29:

Шаг (1): сообщение Ведущего узла со скоростью передачи данных порта COM3 (см. таблицу 8):

Шаг (2): сообщение Ведущего узла со скоростью передачи данных порта COM2 (см. таблицу 8);

Шаг (3): сообщение Ведущего узла со скоростью передачи данных порта СОМ1 (см. таблицу 8);

Шаг (4): ответное сообщение Устройства со скоростью передачи порта СОМ1.

Перед инициацией (нового) сообщения обработчик канального вывода ожидает по меньшей мере в течение периода времени 70МГ Значение Тоит устанавливается в таблице 40.

В отношении поддержки скоростей передачи данных для Устройства применяется следующее правило соответствия:

• Устройство будет поддерживать только одну из скоростей передачи для портов СОМ1. COM2 или COM3.

Если попытка установления связи не достигает успеха, обработчик DL Ведущего узла не будет начинать новую попытку процедуры пробуждения, пока не истечет период времени 70wu, как показано на рисунке 30 и установлено в таблице 40.

Ведущий узел будет выдавать до л^и+1 последовательных запросов пробуждения, как показано на рисунке 31. Если эта начальная последовательность повторных попыток пробуждения терпит неудачу. Устройство возвратит линию C7Q в режим SIO через промежуток времени Г0§юозю повторно запускается в Устройстве после каждого обнаруженного запроса пробуждения). Ведущий узел не будет запускать новую последовательность попыток пробуждения через промежуток времени TSD.

47

ГОСТ Р МЭК 61131-9—2017

WUR

Восущий увел

Устройство

>

1

1

1

>

1

1

1

1

COM3 COM2

СОМ1

*

1

*

4

4

810 ! 1

Нет ответа

4

4

4

1 *

Рисунок 30 — Неудачная попытка установления связи

Поспдоеятаяъмос’ь повторных попытос прэОуноення

К

I

I

%

I

SfO

ВМущий уэвл

Устройство

а

I

7мю

/в*»'

«

%

I

I

7о$ю

4

Г$о

Рисунок 31 — Стратегия повторных погыток установления связи

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

Значения для согласования по времени процедур пробуждения и повторных попыток установлены в таблицах 9 и 40. Они определяются с точки зрения Ведущего узла.

Таблица 40 — Процедура пробуждения и характеристики повторной попытки

Свойство

Наименование

Минимум

Норма

Максимум

Едииииа

измерения

Примечание

Г0МТ

Задержка сообщения Ведущего узла

27

Н/Д

37

ТВ(Т

Время прохождения бита повторной передачи данных

^OStO

Задержка SIO

60

н/д

300

МС

Через TDSlo Устройство возвращается в режим SIO (если он поддерживается)

Wu

Задержка повторной попытки пробуждения

30

н/д

50

мс

Через Тми Ведущий узел повторяет запрос пробуждения

48

ГОСТ Р МЭК 61131-9—2017

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

Свойство

Минимум

Норма

Максимум

Единица

измерения

Примечание

Счетчик повторных попыток пробуждения

2

2

2

Число повторных попыток запроса пробуждения

*50

Время обнаружения Устройства

0.5

нГд

1

с

Время между двумя последовательностями запроса пробуждения (см. примечание)

Примечание — Характеристика Ведущего узла.

DL Ведущего узла прекратит процедуру установлений связи, как только он найдет Устройство, поддерживающее связь, и сообщит в SM об обнаруженном режиме СОМх. применяя услугу DL. Если процедура закончится неудачно, о соответствующей ошибке будет сообщено с использованием той же услуги.

7.3.2.3 Процедура возврата в исходный режим

SM вызывает следующие действия на DL с помощью услуги DL_SetMode (режим = INACTIVE):

•    команда Ведущего узла Fallback (Возврат в исходное состояние, см. таблицу В.2) заставляет Устройство перейти в режим SIO:

•    Устройство завершит переход в режим SIO через три времени цикла ведущего узла MasterCycteTimes и/или не позднее, чем через 500 мс после команды Ведущего узла. Это делает возможными повторные попытки, если команда Ведущего узла закончилась неудачно из-за отрицательного ответа Устройства.

На рисунке 32 показаны процедура возврата в исходный режим, ее повторные попытки и временные ограничения.

Ведущий узел

Устройство

Квмекав Ведущего уме F«l№eck

(Всверете исходный р*>ии) ^ Всомсммые повторно поты»»

время цикла ведущего узле'

Рисунок 32 — Процедура возврата в исходный режим

В таблице 41 устанавливаются временные характеристики возврата в исходный режим. Подробное описание приводится в А.2.6.

Таблица 41 — Временные характеристики возврата в исходный режим

Свойство

Наименование

Минимум

Норма

Максимум

Единица

измерения

Примечание

Трво

Задержка возврата в исходный режим

Три времени цикла Ведущего узла (OPERATE) или

3 Tinrtcyc (PREOPE-RATE)

н/д

500

МС

Через время TpgQ Устройство будет переключено в режим SIO (см. рисунок 32)

49

ГОСТ Р МЭК 61131-9—2017

7.3.2.4 Конечная машина обработчика DL Ведущего узла

На рисунке 32 показана конечная машина обработчика DL Ведущего узла.

Рисунок 33 — Конечная машина обработчика канального уровня Ведущего узла Примечание — Условные обозначения диаграмм языка UML определены в 3.3.7.

После получения услуги DL_SetMode_STARTUP из SM обработчик DL вначале создаст импульс тока пробуждения через услугу PL_WakeUp и затем установит связь. Данная процедура определена в функциональном узле 1 на рисунке 34.

Цель состояния «Startup_2» — это проверка идентичности Устройства через данные страницы Непосредственных параметров (см. рисунок 5). В состоянии «PreOperate_3» Ведущий узел назначает параметры Устройству, применяя ISDU. Циклический обмен PD осуществляется в состоянии «Operate». В данном состоянии дополнительные 00. такие как ISOU. команды и События могут передаваться, применяя подходящие типы М-лоследоеательностей (см. рисунок 37).

В состояниях «PreOperate_3» и «Operate_4» в Ведущем узле активируются различные наборы обработчиков.

50

ГОСТ Р МЭК 61131-9—2017

Рисунок 34 — Функционатъный узел 1 для установки связи

В таблице 42 показаны таблицы перехода состояний обработчика OL на Ведущем узле.

Таблица 42 — Таблицы перехода состояний обработчика DL на Ведущем узле

Имя состояния

Описание состояния

klte_0

Ожидание запроса пробуждения от SM: DL_SetMode (STARTUP)

EstablishComm_1

Выполнить процедуру пробуждения (функциональный узел 1)

Startup _2

SM применяет состояние STARTUP для идентификации Устройства, проверки и конфигурирования связи (см. рисунок 69)

Preoperate_3

ODE (параметры, команды. События) без PD

Operate_4

PD и OD (параметры, команды. События)

51

ГОСТ Р МЭК 61131-9—2017

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

Имя состояния

Описание состояния

SM: WURQ_

5

Создать импульс тока пробуждения: Вызвать услугу PL.WakeUp (см. рисунок 11 и 5.3.3.3) и ожидать Тодт (см. таблицу 40)

SM:

Послать тестовое сообщение со скоростью передачи порта COM3 через об работ-

ComRequestCOM3_6

чик сообщений: Вызвать услугу MH_Conf_COMx (см. рисунок 38) и ожидать Tq^t (см.таблицу 40)

SM:

Послать тестовое сообщение со скоростью передачи порта COM2 через обработчик

ComRequestCOM2_7

сообщений: Вызвать MH_Conf_COMx (см. рисунок 38) и ожидать TDWT (см. таблицу 40)

SM:

Послать тестовое сообщение со скоростью передачи порта СОМ1 через обработчик

ComReq uestCOM 1 _B

сообщений: Вызвать MH.Conf.COMx (см. рисунок 38) и ожидать Гомт (см. таблицу 40)

SM: Retry_9

Проверить число повторных попыток

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Обнулить число попыток: Retry = 0

T2

1

2

Скорость передачи порта COM3 проверена успешно. Обработчик сообщений активирован и сконфигурирован на COM3 (см. рисунок 38. Переход Т2). Активировать обработчик команд (вызов CH.Conf.ACTIVE на рисунке 51). Вернуть Return DL Mode.ind (STARTUP) и DL Mode.ind (COM3)bSM

T3

1

2

Скорость передачи порта COM2 проверена успешно. Обработчик сообщений активирован и сконфигурирован на COM2 (см. рисунок 38. Переход Т2). Активировать обработчик команд (вызов CH.Conf.ACTIVE на рисунке 51). Вернуть Return DL Mode.ind (STARTUP) и DL Mode.ind (COM2) 8 SM

T4

1

2

Скорость передачи порта OOM1 проверена успешно. Обработчик сообщений активирован и сконфигурирован на СОМ1 (см. рисунок 38. Переход Т2). Активировать обработчик команд (вызов СН Conf ACTIVE на рисунке 51). Вернуть DL_Mode.ind (STARTUP) и DL.Mode.ind (СОМ1) в SM

T5

1

0

Вернуть DL.Mode.ind (INACTIVE) в SM

T6

2

3

SM затребовал режим OPERATE. Активировать обработчик OD (вызов OH.Conf.ACTIVE на рисунке 46). обработчик ISDU (вызов IH.Conf.ACTIVE на рисунке 49) и обработчик Событий (вызов EH.Conf.ACTIVE на рисунке 53). Изменить состояние обработчика сообщений на PREOPERATE (вызов МН Conf MPERATE на рисунке 38). Вернуть DL.Mode.ind (PREOPERATE) в SM ”

T7

3

2

SM затребовал режим STARTUP. Изменить состояние обработчика сообщений на STARTUP (вызов MH.Conf.STARTUP на рисунке 38). Деактивировать обработчик OD (вызов OH.Conf.lNACTIVE на рисунке 46). обработчик ISDU (вызов IH.ConfJNACTIVE на рисунке 49) и обработчик Событий (вызов EH Conf INACTIVE на рисунке 53). Вернуть DL.Mode.ind (STARTUP) в SM

T8

3

0

SM затребовал режим SIO. Деактивировать все обработчики (вызов xx.Conf.lNACTIVE). Вернуть DL.Mode.ind (INACTIVE) в SM

T9

3

0

Обработчик сообщений информирует о потерянной связи через услугу DL-A MHlnfo (COMLOST). Деактивировать все обработчики (вызов xx.Conf.lNACTIVE). Вернуть DL.Mode.ind (COMLOST) в SM

T10

3

4

SM затребовал режим OPERATE. Активировать обработчик PD (вызов PD.Conf.SlNGLE. если тип М-последоеатвпьности = TYPE.2.X. или вызов PD.Conf.INTERLEAVE. если тип М-последовательности = TYPE.1.1 на рисунке 44). Изменить состояние обработчика сообщений на OPERATE (вызов MH.Conf.OPERATE на рисунке 38). Вернуть DL.Mode.ind () в SM

52

ГОСТ Р МЭК 61131*9—2017

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

Переход

Исходное

состояние

Конечное

состояние

Действие

Т11

2

4

SM затребовал режим OPERATE. Активировать обработчик PD (вызов PD.Conf.SINGLE или вызов PD.Conf.INTERLEAVE на рисунке 44 в соответствии с конфигурацией порта Ведущего устройства). Активировать обработчик OD (вызов OH_Conf_ACTiVE на рисунке 46). обработчик ISDU (вызов IH.Conf.ACTIVE на рисунке 49) и обработчик Событий (вызов EH_Cont_ACTIVE на рисунке 53). Изменить состояние обработчика сообщений на OPERATE (вызов MH_Conf_OPERATE на рисунке 38). Вернуть DL_Mode.ind () в SM

Т12

4

2

SM затребовал режим STARTUP. Изменить состояние обработчика сообщений на STARTUP (вызов MH_Conf_STARTUP на рисунке 38). Деактивировать обработчики РО (вызов PD.Conf.lNACTIVE на рисунке 44), OD (вызов OH.ConfJNACTIVE на рисунке *48). обработчик ИСДБ (вызов IH Conf INACTIVE на рисунке 49) и обработчик Событий (вызов EH Conf Inactive на рисунке S3). Вернуть DL Mode.ind (STARTUP) в SM

Т13

4

0

SM затребовал состояние SIO. Деактивировать все обработчики (вызов xx.Conf.INACTIVE). Вернуть DL.Mode.ind (INACTIVE) в SM

Т14

4

0

Обработчик сообщений информирует о потерянной связи через услугу DL-A MHInfo (COMLOST). Деактивировать все обработчики (вызов xx_Conf_INACTIVE). Вернуть DL.Mode.md (COMLOST) в SM

Т15

5

6

Установить скорость передачи порта COM3

Т16

6

7

Установить скорость передачи порта COM2

Т17

7

8

Установить скорость передачи порта СОМ1

Т18

8

9

Увеличить счетчик попыток Retry

Т19

9

5

Внутренние элементы

Тип

Определение

MH_Conf_COMx

Вызов

Данный вызов заставляет обработчик сообщений послать сообщение с требуемой скоростью передачи порта СОМх и М-последовательностью типа TYPE.0 (см. таблицу 44)

MH_Conf_STARTUP

Вызов

Данный вызов заставляет обработчик сообщения переключиться в состояние STARTUP (см. рисунок 38)

МН Conf

Вызов

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

PREOPERATE

стояние PREOPERATE (см. рисунок 38)

MH_Conf_OPERATE

Вызов

Данный вызов заставляет обработчик сообщения переключиться в состояние OPERATE (см. рисунок 38)

xx_Conf_ACTIVE

Вызов

Данный вызов активирует соответствующий обработчик, хх заменяется на МН (обработчик сообщений). ОН (обработчик OD). IH (обработчик ISDU). СН (обработчик команд) и'или ЕН (обработчик событий)

xx_Conf_! NACTJVE

Вызов

Данный вызов деактивирует соответствующий обработчик, хх заменяется на МН (обработчик сообщений), ОН (обработчик OD). IH (обработчик ISDU). СН (обработчик команд) и/или ЕН (обработчик событий)

Retry

Перемен

ная

Число повторных попыток установления связи

7.3.2.5 Конечная машина обработчика DL на Устройстве

На рисунке 35 показана конечная машина обработчика DL на Устройстве, в состояниях PreOperate_3 и Operate_4 в Устройстве активируются различные наборы обработчиков.

53

ГОСТ Р МЭК 61131-9—2017

Рисунок 35 — Конечная машина обработчика канального уровня на Устройстве

Ведущий узел применяет команды ведущего узла (см. таблицу 42) для изменения состояний SIO. STARTUP. PREOPERATE и OPERATE. При каждом обнаружении обработчиком сообщений неправильных (неожиданных) типов М-последовательности он будет заставлять обработчик DL менять состояние на STARTUP и указывать на данное состояние модулю управления системой (см. 9.3.3.2) в целях синхронизации Ведущего узла и Устройства.

В таблице 43 показаны таблицы перехода состояний обработчика DL на Устройстве.

Таблица 43 — Таблицы перехода состояний обработчика DL на Устройстве

Имя состояния

Описание состояния

tdle.O

Ожидание обнаруженного импульса тока пробуждения (PL_WakeUp.ind)

EstabtishComm_1

Обработчик сообщений активирован и ожидает тестового сообщения СОМх (см. таблицу 42)

Slartup_2

Проверка совместимости (см. 9.2.3.3)

Preoperale_3

Обмен OD (параметры, команды. События) без PD

Operale_4

Обмен PD и OD (параметры, команды. События)

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Обнаружен импульс тока пробуждения. Активировать обработчик сообщений (вызов MH_Conf_ACTiVE на рисунке 42). Сообщить состояние через услугу DL_Mode.ind (ESTABCOM) в SM

T2

1

2

Установлена одна из трех скоростей передачи: для порта COM3. COM2 или СОМ1. Активировать обработчики ОО (вызов OH_Conf_ACTTVE на рисунке 47) и команд (вызов CH_Conf_ACTiVE на рисунке 52). Сообщить состояние через услугу DL_Mode.ind (СОМ1. COM2 или COM3) в SM

54

ГОСТ Р МЭК 61131*9—2017

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

Переход

Исходное

состояние

Конечное

состояние

Действие

ТЗ

2

3

Обработчик команд Устройства получил команду {MCmd_PREOPE RATE) Ведущего узла. Активировать обработчик ISOU (вызов IH_Conf_ACTIVE на рисунке 50) и обработчик Событий (вызов EH_Conf_ACTIVE на рисунке 54). Сообщить сосгожие через услугу OL Mode.ind (PREOPERATE) bSM

Т4

3

4

Обработчик команд Устройства получил команду (MCmd.OPERATE) Ведущего узла. Активировать обработчик РО (вызов MH_Conf_ACTIVE на рисунке 45). Сообщить состояние через услугу DL Mode.ind (OPERATE) aSM

Т5

2

4

Обработчик команд Устройства получил команду (MCmd_OPERATE) Ведущего узла. Активировать обработчик PD (вызов OH_Conf_ACTIVE на рисунке 45). обработчик ISDU (вызов IH_Conf_ACTIVE на рисунке 50) и обработчик Событий (вызов EH_Conf_ACTIVE на рисунке 54). Сообщить состояние через услугу DL Mode.ind (OPERATE) 8 SM

Тб

3

2

Обработчик команд Устройства получил команду {MCmd_STARTU Р) Ведущего узла. Деактивировать обработчик ISDU (вызов IH.ConfJNACTIVE на рисунке 50) и обработчик Событий (вызов EH_Conf_iNACTIVE на ри-суже 54). Сообщить состояние через услугу DL Mode.ind (STARTUP) eSM

Т7

4

2

Обработчик команд Устройства получил команду (MCmd_STARTUP) Ведущего узла. Деактивировать обработчик РО (вызов OH_Conf_INACTIVE на рисунке 45). обработчик ISDU (вызов IH_Conf_l NACTIVE на рисунке 50) и обработчик Событий (вызов EH_Conf_lNACTIVE на рисунке 54). Сообщить состояние через услугу DL_Mode.ind (STARTUP) в SM

Т8

3

0

Обработчик команд Устройства получил команду (MCmd_FALLBACK) Ведущего узла.

Ждать окончания промежутка времени ГрВ0 и затем отключить все обработчики (вызов xx_Coof_INACTIVE).

Сообщить состояние через услугу DL_Mode.ind (INACTIVE) в SM (см. рисунок 79 и таблицу 93)

T9

4

0

Обработчик команд Устройства получил команду (MCmd.FALLBACK) Ведущего узла.

Ждать окончания промежутка времени ТрВо и затем откгьочитъ все обработчики (вызов xx_Conf_INACTIVE).

Сообщить состояние через услугу DL_Mode.ind (INACTIVE) в SM (см. рисунок 79 и таблицу 93)

Т10

1

0

После неудачных процедур пробуждения (см. рисунок 30) Устройство устанавливает сконфигурированный режим SIO после прохождения периода времени Tosto ■ рисунок 31).

Деактивировать все обработчики (вызов xx_Conf_INACTIVE). Сообщить состояние через услугу DL.Mode.ind (INACTIVE) в SM

Т11

4

2

Обработчик сообщений обнаружил неправильный тип М-поспедо-ватепьности. Деактивировать обработчик PD (вызов OH_Conf_!NACTIVE на рисунке 45). обработчж ISDU (вызов 1 H.ConfJNACT1VE на рисунке 50) и обработчик Событий (вызов EH_Conf_INACTIVE на рисунке 54). Сообщить состояние через услугу DL.Mode.ind (INACTIVE) в SM (см. рисунок 79 и таблицу 93)

Т12

3

2

Обработчик сообщений обнаружил непрааигъный тип М-последо-вательности. Деактивировать обработчик ISDU (вызов IH_Conf_lNACTIVE на рисунке 50) и обработчик Событий (вызов EH_Coof_INACTIVE на рисунке 54). Сообщить состояние через услугу DL.Mode.ind (INACTIVE) в SM (см. рисунок 79 и таблицу 93)

55

ГОСТ Р МЭК 61131-9—2017

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

nwИсхоянов

состояние

Коночное

состояние

Действие

rFeo

Время

См. таблицу 41

TDSIO

Время

См. рисунок 31

MCrod.XXXXXXX

Вызов

Любая команда Ведущего узла, полученная обработчиком команд Устройства (см. таблицу 42 и рисунок 52. состояние «CommandHandler_2»)

7.3.3 Обработчик сообщений

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

Роль обработчика сообщений установлена в подразделе 7.1 и 7.2.2.1. Структура и типы М-сообщений и поведение (динамика) обработчика сообщений установлены в 7.3.3.

7.3.3.2    М-последоеательности

Ведущий узел и Устройства обмениваются данными посредством последовательности сообщений (М-последовательности). М-последовательностъ включает сообщение от Ведущего узла с последующим сообщением от Устройства, как показано на рисунке 36. Каждое сообщение состоит из фреймов UART.

«•—

Сообщение ведущего узле

Фрейм UART

Фрейм UART

...

ФреймUART

Сообщение Устройстве

Тип M-послвдовагапьности

/

*P©SmUART

...

Фрейм UART

Рисунок 36 — Последовательности сообщений SDCI

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

Сообщение Ведущего узла начинается с октета «Управления М-лоследовательностью» (МС). далее следуют октет и необязательные октеты PD. Сообщение Устройства, в свою очередь, начинается с необязательных октетов РО. OD. за которыми следует октет «СНЕСК/STAT» (CKS).

Для удовлетворения конкретных требований исполнительного устройства или датчика (скорость сканирования, объем РО) могут выбираться различные типы М-последоеательности. Длина сообщений Ведущего узла и Устройства может меняться в зависимости от типа сообщений и направления передачи данных (см. рисунок 36).

На рисунке 37 представлен обзор установленных типов М-поспедовательности. Части, отмеченные пунктиром, зависят от направления операции (чтение или запись) е управляющем октете М-последовательности.

Фиксированные типы М-последовательности состоят из TYPE_0. TYPE_1_1, TYPE_1_2 и от TYPE_2_1 до ТУРЕ_2_6. Переменные типы М-последоеательности состоят из TYPE_1_V и TYPE_2_V.

56

ГОСТ Р МЭК 61131-9—2017

Различные типы М-последовательн остей удовлетворяют различным требованиям датчиков и исполнительных устройств относительно ширины их РО и соответствующих условий. Подробное описание типов M-последовательностей приводится в разделе А.2. В разделе А.З описываются временные ограничения М-послвдовательностей.

TYPEJ) TYPE 1

TYPE 2 1

скт

сю

TYPE 2 2 ГмС| СКТ

оо

TYPE_2_3 И~|'д(ГД скт | РО

TYPE„2_4 Ди£Я СКТ | Р0а

РО f CKS

PPs I РР, I CKS

?

CKS

TYPE 2 5

СКТ I РО

00

РР ск$

TYPE_2_6 ГмсД скт ] рра |

оо

РО» | РР, | CKS

TYPE 2 V

СКТ

Р0а

00,

ОО..

РОз \........| РР„, | CKS I

Рисунок 37 — Обзор типов М-последовательносгей

7.3.3.3 Ограничения времени цикла Ведущего узла

В состояниях STARTUP и PREOPERATE устройство может осуществлять связь ациклически. Для обнаружения отключения Устройства рекомендуется, чтобы Ведущий узел поддерживал периодическую связь (сообщения контроля активности) через ациклические М-последовательности на OL. Минимальное время восстановления для ациклической связи, установленное в А.2.6, будет рассмотрено ниже.

После трех фаз циклическая связь PD может начинаться Ведущим узлом через услугу DL_SetMode (OPERATE). Типы М-последовательности для циклического обмена данными будут применяться на данной фазе связи для обмена РО и ОО с Устройством (см. таблицы А.9 и А.10).

Ведущий узел будет применять для времени ^ус значение, указанное в параметре MasterCycleTime {см. таблицу В.1) с относительным допуском от 0 % до плюс 10 % (включая флуктуации синхронизации).

Если Устройство должно переключаться обратно в режим SIO после параметризации. Ведущий узел будет посылать команду Fallback возврата в исходный режим (см. таблицу В.2). за которой следует подтверждение от Устройства.

57

ГОСТ Р МЭК 61131-9—2017

7.3.3.4 Конечная машина обработчика сообщений Ведущего узла

На рисунке 38 показана конечная машина обработчика DL Ведущего узла. Три функциональных узла, описывающих реакции на ошибки связи, показаны на рисунках 39. 40 и 41.

Обработчик сообщений следит за соблюдением специальных требований х связи в состояниях «EstablishCom*. «Startup», «PreOperate» и «Operate» обработчика DL.

Внутренний административный вызов MH_Conf_COMx в состоянии «Inactive.O» заставляет обработчик сообщений посылать тестовое сообщение с М-последовательностью типа TYPE_0 и скоростями передачи различных портов COM3. COM2 и СОМ1 во время последовательности установления связи.

Рисунок 38 — Конечная машина обработчика сообщений Ведущего узла

В состоянии «Startup^» предоставляются все средства связи для поддержки проверки идентичности SM с помощью услуг DL_Read и DL_Write. Обработчик сообщений ожидает появления данных услуг для посылки и получения сообщений (ациклическая связь).

Состояние «Preoperate_6» служит контрольной точкой для всех действий с OD. таких как ISDU, команды и События, с целью поддержки параметризации Устройства. Обработчик сообщений ожидает появления данных услуг, показанных на рисунке 38. для посылки и получения сообщений (ациклическая связь).

Состояние «Operate_12» является контрольной точкой для обмена циклическими PD. В зависимости от типа M-последовательности обработчик сообщений генерирует сообщения Ведущего узла с PD. полученными от обработчика прерываний PD через услугу PD. и при необходимости с OD. полученными от обработчика OD через услугу OD.

58

ГОСТ Р МЭК 61131-9—2017

На рисунке 39 показан функциональный блок состояния «Response 3».

Рисунок 39 — Функциональный блок «Response 3» обработчика прерываний На рисунке 40 показан функциональный блок состояния «Response 8».

Яв»оп«в„в

К

I

1(п|ТМ-вэи*пс«у

T19

A»»tR»pty_9

—№

6nwH«odiine_iO

•п«х 4

;Я»®апв* nel ОКУ

м

•пм_3

Т

imlTtf'iiCfCXRery « MatReuyp Т}1 (Йв-йвпв!

Рисунок 40 — Функциональный блок «Response в» обработчика прерываний

На рисунке 41 показан функциональный блок состояния «Response 15».

Respcr-*e_i5

<n*> в

I

t

AwSitReply IS

тэо

E<fOin«nOing_17

(ЯОф9ЛЯ»ПО( ОКУ

тя

•net S

e{Tcrc}(R«fry < МюЛЫгуУ 132 |R«4»nd)

V-    -    -J

Рисунок 41 —Функциональный блок «Response 15» обработчика прерываний В таблице 44 показаны таблицы перехода состояний обработчика OL на Ведущем узле. Таблица 44 — Таблицы перехода состояний обработчика сообщений на Ведущем узле

Имя состояния

Описание состояния

lnacbve_D

Ожидание по требованию тестового сообщения через вызов MH_Conf_COMx (см. рисунок 34 и таблицу 42) от обработчика DL

59

ГОСТ Р МЭК 61131-9—2017

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

Имя состояния

Описание состояния

AwaitRepty_1

Ожидание ответа Устройства на тестовое сообщение. Возврат в состояние tnactive_0 по истечении времени TM sequence без ответа от Устройства или когда ответ на тестовое сообщение не может быть дешифрован. 8 случав корректного ответа от Устройства обработчик сообщений изменяет состояние на Startup_2

Slartup_2

При входе через переход Т2 это состояние отвечает за управление обменом ациклическими 00 в соответствии с условиями, установленными в таблице А.7. Любая услуга DL.Write или DL_Read из SM вызывает такой переход

Response_3

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

SM: AwartRepty_4

Данное состояние следит за истечением промежутка времени и правильностью ответа

SM: ErrorHandling_5

В случае неправильного ответа обработчик сообщений повторно посылает сообщение через промежуток времени Т1ПЙС>,С.

После слишком большого числа повторных попыток обработчик сообщений перейдет в положение Inactive.O

Preoperate_6

При получении вызова MH_Conf_PREOPERATE обработчик сообщений переходит в данное состояние. Теперь обработчик сообщений несет ответственность за управление ациклическим обменом 00 в соответствии с условиями, определенными в таблице А.8. Любая из услуг DL_ReadParam. DL_WriteParam. DLJSOUTransport, DL_Write или EventFlag вызывает переход

GetOD_7

Обработчик сообщений использовал услугу ООТпд для получения OD из обработчика 00.

Обработчик сообщений ожидает, когда услуга пошлет сообщения через промежуток времени Tinite><

Response_6

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

SM: AwaitRepty_9

Данное состояние следит за истечением промежутка времени и правильностью ответа

SM: ErrorHandling_10

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

После слишком большого числа повторных попыток обработчик сообщений перейдет в положение lnactive_0

CheckHandler_11

Некоторые услуги требуют нескольких циклов получения OD при обмене 00. Всякий раз. когда задействованный обработчик OD. обработчик ISDU или обработчик События возвращается в состояние простоя, обработчик сообщений мсмсет выйти из цикла получения 00

Operate_12

При получении вызова MH_Conf_OPERATE обработчик сообщений переходит е данное состояние и через начальное время Т1П<еус он становится ответственным за контроль обмена циклическими РО и 00 в соответствии с условиями, установленными в таблицах А.9 и А. 10.

Обработчик сообщений повторно начинает новый цикл сообщений по истечении промежутка времени I^yc

GetPD_13

Обработчик сообщений использовал услуту PDThg для получения РО из обработчика PD. Обработчик сообщений ожидает услуги PD и затем переходит в состояние GetOD_14

GelOD_14

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

Response_15

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

60

ГОСТ Р МЭК 61131*9—2017

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

Имя состояния

Описание состояния

SM: AwartRepty_16

В данном состоянии проверяется истечение промежутка времени Тм.ик^9)се и правильность ответа

SM; ErrorHandling_17

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

Переход

Исходное

состояние

Конечно*

состояние

Действие

Т1

0

1

Посылает сообщение с требуемой скоростью передачи порта СОМх и М-последовательностью типа ТУРЕ_0: Считывает страницу 1 Непосредственных параметров, адрес 0x02 {MinCycleTime): компилирует команду Ведущего узла по адресу 0хА2 в М-последовательносгь (см. А. 1.2). Запускает таймер с установленным значением Тм.5вдовпе

Т2

1

2

Возвращает значение «MinCycleTime» через подтверждение услуги DL.Read

ТЗ

1

0

Сбрасывает таймер (Т*,.^^)

Т4

1

0

Сбрасывает таймер (Тиш9ваяпп)

Т5

2

3

Посыпает сообщение, применяя установленную скорость передачи, канал связи страницы и опцию доступа чтения (см. А.1.2). Запускает таймер с установленным значением TM s<Muence

Тб

2

3

Посыпает сообщение, применяя установленную скорость передачи, канал связи страницы и опцию доступа записи (см. А.1.2). Запускает таймер с установленным значением Тм.мдиепов

Т7

4

5

Сбрасывает таймер (Tm.^^.^)

те

4

5

Сбрасывает таймер (Тм.1вв|впев)

T9

5

4

Повторно посылает сообщение через промежуток времени Tiwteye. Повторно запускает таймер с установленным значением Тм.5Мислсе

Т10

3

2

Возвращает подтверждение услуги DL.Read или DL.Write соответственно в SM

Т11

3

0

Обработчик сообщений возвращает MHJnfo (COMLOST) обработчику DL

Т12

2

6

Т13

6

7

Обработок сообщений вызывает услугу ODTrig для обработчика Запроса (см. рисунок 46). который находится в состоянии «ISDIM». В данном состоянии он заставляет обработчик ISDU предоставить услугу ОО в соответствии с услугой DL_ReadParam (см. рисунок 49. Переход Т13)

Т14

6

7

Обработок сообщений вызывает услугу ODTrig для обработчика Запроса (см. рисунок 46). который находится а состоянии «ISDIM ». В данном состоянии он заставляет обработчик ISDU предоставить услугу ОО в соответствии с услугой DL_WriteParam (см. рисунок 49. Переход Т13)

Т15

6

7

Обработчик сообщений вызывает услугу ODTrig для обработчика Запроса (см. рисунок 46). который находится в состоянии «ISDU_1». В данном состоянии он заставляет обработчик 1SDU предоставить услугу OD в соответствии с услугой DLJSDUTransort (см. рисунок 49. Переход Т2). Обработчику сообщений может потребоваться несколько циклов, пока обработчик ISDU возвратится в состояние «простоя»

Т16

6

7

Обработчик сообщений вызывает услугу ODTrig для обработчика Запроса (см. рисунок 46). который находится в состоянии «Event_4». В данном состоянии он заставляет обрабогчж Событий предоставить услугу ОО в соответствии с услугой EventFlag (см. рисунок 53, Переход Т2). Обработчику сообщений может потребоваться несколько циклов. пока обработчик Событий возвратится в состояние «простоя»

61

ГОСТ Р МЭК 61131-9—2017

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

Переход

Исходное

состояние

Конечное

состояние

Действие

Т17

в

7

Обработчик сообщений вызывает услугу OOTrig для обработчика Запроса (си. рисунок 46). который находится в состоянии «1SDIM». В данном состоянии он заставляет обработчик 1SDU предоставить услугу ОО в соответствии с услугой DL_Write (см. рисунок 49. Переход Т13)

Т18

7

8

Посылает сообщение после истечения времени восстановления ТпНсус, вызванного услугой OD.req. Запускает таймер с установленным знзче-

нием Tht^eguence

Т19

9

10

Сбрасывает таймер (Тм-ведрепее)

Т20

9

10

Сбрасывает таймер (Тм.^^)

Т21

10

9

Повторно посылает сообщение через промежуток времени Tjn(cyc. Повторно запускает таймер с установленным значением TM.sequence

Т22

8

0

Обработчик сообщений изменяет состояние на Inactive 0 и возвращает MHJnfo (COMLOST) обработчику DL

Т23

8

11

Т24

11

7

Получает OD через вызов услуги ODTrig к обработчику OD. который, в свою очередь, запускает текущий дежурный обработчик через вызов ISDU или вызов EventTrig

Т25

11

6

Возвращает результат через сервисный примитив OO.cnf

Т26

6

12

Обработчик сообщений изменяет состояние на Operate_12

Т27

12

13

Запускает таймер с установленным значением Получает PD через вызов услуги PDTrig к обработчику PD (см. рисунок 44)

Т28

13

14

Получает ОО через вызов услуги OOTrig к обработчику OD (см. рисунок 46)

Т29

14

15

РО и ОО становятся готовыми через услугу PO.req из обработчика PD или через услугу OD.req обработчика OD. Обработчик сообщений посылает сообщение. Запускает таймер с установленным временем TMsequence

ТЗО

16

17

Сбрасывает таймер (TM-sequeoce)

Т31

16

17

Сбрасывает таймер (TM-sequence)

Т32

17

16

Повторно посылает сообщение через промежуток времени Повторно запускает таймер с установленным значением TM-sequence

ТЗЗ

15

0

Обработчик сообщений изменяет состояние на lnactive_0 и возвращает MHJnfo (COMLOST) обработчику DL

Т34

15

12

Ответное сообщение Устройства — правильное. Возвращает PD через услугу PD.cnf и через вызов PDTrig к обработчику PD (см. таблицу 46). Возвращает OD через услугу OD.cnf или через вызов ODTrig к обработчику OD. который перенаправляет их к соответствующему обработчику ISDU (см. таблицу 51). обработчику команд (см. таблицу 54) или обработчику Событий 57)

Т35

12

0

Обработчик сообщений изменяет состояние на Inactive 0 и возвращает MHJnfo (COMLOST) обработчику DL

Т36

6

0

Обработчик сообщений изменяет состояние на Inactive 0 и возвращает MHJnfo (COMLOST) обработчику DL

Т37

6

2

Т38

12

2

Т39

2

12

62

ГОСТ Р МЭК 61131-9—2017

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

Внутренние элементы

Тип

Определение

Retry

Перемен

ная

Счетчик повторных попыток

MaxRetry

Константа

MaxRetry = 2. см. таблицу 97

(М-sequence

Время

См. формулу (А.6)

f CYC

Время

Услуга DL_SetMode предоставляет это значение с параметром «М-sequenceTime». См. формулу (А.7)

/initcyc

Время

Сы.А.2.6

MH_Conf_xxx

Вызов

См. таблицу 42

7.3.3.5 Конечная машина обработчика сообщений Устройства На рисунке 42 показана конечная машина обработчика DL на Устройстве.

Рисунок 42 — Конечная машина обработчика сообщений Устройства

В таблице 45 показаны таблицы перехода состояний обработчика OL на Устройстве.

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

Имя состояния

Описание состояния

lnactrve_0

Ожидание активации обработчиком DL через услугу MH_Conf_ACTlVE (см. таблицу 43. Переход Т1)

Wte_1

Ожидание первого фрейма UART сообщения Ведущего узла через индикацию услуги PL.Transfer. Проверка времени истечения максимального времени цикла «MaxCycieTime»

GetMessage_2

Получение фрейма UART сообщения Ведущего узла. Проверка числа полученных фреймов UART (Устройство знает тип М-последовагвгъносги и. следовательно, число фреймов UART). Проверка времени истечения максимального времени фрейма UART «MaxUARTframeTtme»

CheckMessage_3

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

Create Message_4

Составление сообщения из услуг OD.rsp, PD.rsp. EventFlag и PDStatus

63

ГОСТ Р МЭК 61131-9—2017

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

Переход

Исходное

состояние

Конечное

состояние

Действие

Т1

0

1

Т2

1

2

Запустить отсчет максимального времени фрейма UART «MaxUARTframeTime* и максимального времени цикла «MaxCycleTime» при нахождении а состоянии OPERATE

ТЗ

2

2

Повторно запустить таймер максимального времени фрейма UART «MaxUARTframeTime*

Т4

2

3

Сбросить таймер максимального времени фрейма UART «MaxUARTframeTime*

Т5

3

4

Вызвать индикацию услуг OD.ind и PD.ind

Тб

4

1

Компилировать и вызвать ответ на услугу PL_Transfer.rsp {Устройство посылает ответное сообщение)

Т7

3

1

Сообщить об ошибке обработчику DL через MHInfo (CHECKSUM MiSMATCH)

Т8

3

1

Сообщить об ошибке обработчику DL через MHfnfo {ILLEGAL MESSAGETYPE)

T9

2

1

Сбросить оба таймера о MaxU ARTframeTrme» и «MaxCycleTime»

Т10

1

1

Сообщить об ошибке обработчику DL через MHInfo (COMLOST). Исполнительные устройства будут следить за этой информацией и предпринимать соответствующие действия {см. 10.2 и 10.7.3)

Т11

1

0

Обработчик сообщений Устройства изменяет состояние на lnaclive_0

Внутренние элементы

Тил

Определение

MaxU ART F rameTtme

Время

Время для передачи фрейма UART (11 TBIT) плюс максимум из f, (1 ТВ|Т)=11Тв.т

MaxCycleTime

Время

Проверить для таймера «MaxCydeTime*. не занял ли обмен циклическими PD слишком много времени и не был ли он прерван. MaxCycleTime должно быть больше, чем MasterCydeTime (см. А.3.7)

TypeError

Условие

Обнаружена одна из следующих ошибок: ILLEGAL MESSAGETYPE или COMLOST

ChecfcsumError

Условие

Обнаружена ошибка контрольной суммы сообщения

7.3.4 Обработчик Данных процесса

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

Транспортировка выходных РО выполняется, применяя услугу DL_OutputUpdate. а транспортировка входных PD — применяя услугу DLJnputTransport (см. рисунок 26). Цикл PD завершен, когда весь набор PD передан между Ведущим узлом и Устройством в нужном направлении. Данный цикл может потребовать более одной М-последовательности.

Все РО передаются в одной М-последовательности при использовании М-последовательностей типа ТУРЕ_2_х (см. рисунок 37). В данном случае время исполнения цикла PD равно времени цикла ^Yc-

7.3.4.2    Режим расслоения

В данном случае все РО и OD передаются с несколькими перемежающимися М-лоследо-вательностями типов TYPE_1_1 (PD) и TYPE_1_2 (ОО). как показано на рисунке 43. Это демонстрируется сообщениями Ведущего узла, записывающими выходные РО на Устройство. Параметр PDOutAddress услуги показывает расчленение выходных РО, подлежащих передаче (см. 7.2.2.3). Для входных PD параметр PDInAddress услуги соответственно указывает на расчленение входных РО. В цикле PD все входные РО будут считываться вначале с последующими выходными РО. подлежащими записи. Цикл PD включает все времена циклов, требуемых для передачи полных PD.

64

ГОСТ Р МЭК 61131-9—2017

Цикпломкда Даымх профоса

СКТ

РО,

СКТ

о

р

00,

СКТ

Р0Я

I РО,

СКТ

ODn

OD,

Гсус

PDOutAddress » О PDOulAddress = 2

Цпсл /»+ 1 вывода Двигая процесса

СКТ

РО.., PD,

СКТ

00.

OD,

СКТ

PDn

РО,

СКТ

0Dft

00,

Г (время)

PDOutAddress = х-1

Рисунок 43 — Режим расслоения для сегментированной передачи PD

Режим расслоения применяется только для устаревших Устройств.

7.3.4.3 Конечная машина обработчика Данных процесса Ведущего узла На рисунке 44 показана конечная машина обработчика PD Ведущего узла.

РОГов'    РОТА?    РОТо?

T9    T9    Т7

Рисунок 44 — Конечная машина обработчика PD Ведущего узла

В таблице 46 показаны таблицы перехода состояний обработчика PD на Ведущем узле.

Таблица 46 — Таблицы перехода состояний обработчика РО на Ведущем узле

Имя состояния

Описание состояния

inactivej)

Ожидание активации

PDSingle_t

Передача РО в одной-единственной М-последовательности

65

ГОСТ Р МЭК 61131-9—2017

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

Имя состояния

Описание состояния

PDInlnterieave_2

Передача входных PD в режиме расслоения

PDOuUnterieave_3

Передача выходных РО в режиме расслоения

Переход

Исходное

состояние

Конечное

состояние

Действие

Т1

0

0

Вызывает услугу PD.req без РО

Т2

0

1

Примечание — Обработчик DL сконфигурировал обработчик РО для передачи одной порции РО (см. таблицу 42. переходы Т10 или Т11)

тз

1

1

Берет данные из услуги DL_PDOutputUpdate и вызывает PD.req для передачи данных обработчику сообщений. Берет данные из PD.cnf и вызывает DL.PDlnputTranspoflind и DL_PDCycle.ind для передачи входных РО на AL

Т4

0

2

Примечание — Сконфигурировано для передачи РО с расслоением (см. таблицу 42. переходы Т10 или Т11)

Т5

2

2

Вызывает PD.req и применяет PD.cnf для подготовки DL_PDInput Transport, ind

Тб

2

3

Вызывает DL_PDlnputTransportind и DL_PDCycle.ind для передачи входных PD HaAL (см. 7.2.1.11)

Т7

3

3

Берет данные из услуги DL_PDOutputUpdate и вызывает PD.req для передачи данных обработчику сообщений

Т8

3

2

Вызывает DL_PDCycle.ind для указания конца цикла PD АЦсм. 7.2.1.12)

T9

1

0

Т10

2

0

Т11

3

0

Внутренние элементы

Тип

Определение

«отсутствуют»

7.3.4.4 Конечная машина обработчика Данных процесса Устройства На рисунке 45 показана конечная машина обработчика РО Устройства.

Рисунок 45 — Конечная машина обработчика РО Устройства

66

ГОСТ Р МЭК 61131-9—2017

См. диаграмму последовательностей на рисунках 65 и 66.

В таблице 47 показаны таблицы перехода состояний обработчика PD на Устройстве. Таблице 47 — Таблицы перехода состояний обработчика РО на Устройстве

Имя состояния

Описание состояния

lnacUve_0

Ожидание активации

PDAclive_1

Обработчик активен и ожидает следующего запроса обработчика сообщений через службу PD или службу DL_PDInputUpdate из AL

HandlePD_2

Проверка РО на полноту е режиме расслоения

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

0

Игнорирует PD

Т2

0

1

ТЗ

1

1

Подготавливает входные РО для PD.rsp для формирования следующего запроса обработчика сообщений

Т4

1

2

Обработчик сообщений запрашивает входные РО через услугу PD.ind и доставляет выходные РО или сегмент выходных РО. Вызывает PD.rsp с входными РО. когда находится не в режиме расслоения (см. 7.2.2.3)

Т5

2

1

Тб

2

1

Вызывает DL_PDOutpulTransport.ind (см. 7.2.1.9)

Т7

2

1

Вызывает DL_PDCyde.ind (см. 7.2.1.12)

Т8

1

0

Внутренние элементы

Тип

Определение

PD_ind

Метка

Вызов услуги PD.md, приходящий от обработчика сообщений

7.3.5 Обработчик Данных запроса

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

Обработчик OD Ведущего узла — это подчиненная конечная машина, активная в состояниях *Startup_2», «PreOperate_3» и «Operate_4» обработчика канального режима (см. рисунок 33). Конечная машина управляет тремя другими конечными машинами, так называемым обработчиком ISDU. обработчиком команд и обработчиком Событий. По умолчанию конечная машина всегда запускается в режиме обработчика ISDU.

При любом получении услуги EventFlag.ind конечная машина переходит в обработчик Событий. После окончания считывания информации о Событии конечная машина возвращается в состояние обработчика ISDU.

При любом получении от услуг DL_Control.req или PDInStatus.ind, когда машина находится в режиме обработчика ISDU или обработчика Событий, конечная машина переходит в режим обработчика команд. После того как команда обслужена, конечная машина возвращается в предыдущее активное состояние (обработчика ISDU или обработчика Событий).

67

ГОСТ Р МЭК 61131-9—2017

7.3.5.2 Конечная машина обработчика Данных запроса Устройства На рисунке 46 показана конечная машина ведущего узла обработчика OD.

ООТну    001 «у

те    ><о

Рисунок 46 — Конечная машина обработчика О0 Ведущего узла

Обработчик OD перенаправляет сервисный примитив ODTrig.ind для содержания следующего сообщения к текущему активному подконтрольному обработчику (ISDU. команд или Событий). Это осуществляется вызовом одной из услуг: ISDUTrig. Commanding или EventTrig.

В таблице 46 показаны таблицы перехода состояний обработчика OD на Ведущем узле.

Таблица 48 — Таблицы перехода состояний обработчика ОО на Ведущем узле

Имя состояния

Описание состояния

lnactrve_0

Ожидание активации

1SDU_1

Состояние по умолчанию — обработчик OD (низший приоритет)

Command_2

Состояние управления Устройством с помощью команд с высшим приоритетом

Event_3

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

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

T2

1

1

Обработчик OD передает услугу ODTrig.ind. называемую теперь ISDUTrig. обработчику ISDU (см. рисунок 49). В случае услуг DL_Read. DL_Write. DL_ReadParam или DL.WriteParam обработчик ISDU будет применять различные переходы (см. рисунок 49. переход Т13)

тз

1

2

Т4

2

1

Т5

1

3

EventActive = TRUE

Тб

3

1

EventActive = FALSE

Т7

3

2

Т8

2

3

T9

2

2

Обработчик OD передает услугу ODTrig.ind. называемую теперь CommandTrig. обработчику команд (см. рисунок 51)

Т10

3

3

Обработчик OD передает услугу ODTrig.ind. называемую теперь EventTrig. обработчику Событий {см. рисунок 53)

68

ГОСТ Р МЭК 61131-9—2017

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

Переход

Исходное

состояние

Конечное

состояние

Действие

Т11

2

0

Т12

3

0

Т13

1

0

Внутренние элемент»

Тип

Определение

EventActive

Bool

Флаг указания направления возврата после прерывания обработки События высокоприоритетным запросом команды

7.3.5.3 Конечная машина обработчика Данных запроса Устройства

Обработчик OD на Устройстве получает информацию по каналу связи и параметр или адрес FlowCTRL через услугу OD.ind. Каналы связи совершенно независимы. В случае правильного доступа соответствующая конечная машина обработчика ISDU. обработчика команд или обработчика Событий адресуется через соответствующий канал связи.

Устройство будет отвечать на запросы чтения из нереализованных диапазонов адресов со значением «О». Оно будет игнорировать запросы записи в нереализованные диапазоны адресов.

На рисунке 47 показана конечная машина обработчика 00 на Устройстве.

OD me Command!

гз"

ОО.тв.Рмт/

та

1_£

1

AnibelizaMn

И!е_т

ОН Corrt_ACT(VE/ TI

Inoeiive.Q

OH_CwV_ INACTIVE/ Тб

00 .ло 1800/

T4

ОО (ла Event* Тв

Рисунок 47 — Конечная машина обработчика OD на Устройстве

В случае доступа ISDU е Устройстве, не поддерживающем ISDU. Устройство будет отвечать «No Service» (Нет обслуживания) (см. таблицу А.12). Сообщение об ошибке не генерируется.

Примечание — Если нет 00. ожидающих передачи, то сообщением по умолчанию является OD.ind <R. ISDU. FlowCTRL = IDLE).

В таблице 49 показаны таблицы перехода состояний обработчика OD на Устройстве.

Таблица 49 — Таблицы перехода состояний обработчика OD на Устройстве

Имя состояния

Описание состояния

lnacUve_0

Ожидание активации

tdle_1

Ожидание сообщений с OD через индикацию услуги 00. Декомпозиция и анализ

Переход

Исходное

состояние

Конечное

состояние

Действие

Т1

0

1

Т2

1

1

Перенаправляет к обработчику ISDU (стрэнща Непосредственных параметров)

тз

1

1

Перенаправляет х обработчику команд

Т4

1

1

Перенаправляет к обработчику ISDU

Т5

1

1

Перенаправляет к обработчику Событий

Тб

1

0

69

ГОСТ Р МЭК 61131-9—2017

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

Внутренние элементы

Тип

Определение

OD_ind_Param

Услуга

Альтернативное имя услуги OO.ind (R/W. PAGE, or 16 до 31. Data) в случае DL_ReadParam или DL_WriteParam

OD_ind_Command

Услуга

Альтернативное имя для услуги OD.ind <W. PAGE, 0. MasterCommand)

OD_ind_ISDU

Услуга

Альтернативное имя для услуги OD.ind {R/W. ISDU. FlowCtrt. Data)

OD_ind_Event

Услуга

Альтернативное имя для услуги OD.ind {R/W. DIAGNOSIS, п. Data)

7.3.6 Обработчик ISDU

7.3.6.1 Индексированный сервисный блок данных (ISDU)

Общая структура ISDU показана на рисунке 48 и подробно описана в подразделе A.S.

Рисунок 46 — Структура ISDU

Последовательность элементов соответствует последовательности передачи. Элементы ISDU могут принимать различные формы в зависимости от типа l-Service (см. А.5.2 и таблицу А.12).

ISDU позволяет получать доступ к объектам данных (параметры и команды), подлежащим передаче (см. рисунок 5). Объекты данных адресуются с помощью индекса «Index».

Все многооктетные типы данных будут передаваться как последовательность с обратным порядком следования октетов, т. е. старший октет (MSO) будет посылаться первым, затем менее значащие октеты в убывающем порядке, и младший октет (LSO) будет послан последним, как показано на рисунке 2.

7.3.6.2 Передача ISDU

ISDU передается по каналу связи ISDU (см рисунок 7 и А.1.2). Для выполнения такой передачи, как правило, требуется несколько сообщений (сегментация). Ведущий узел передает ISDU. посылая запрос l-Service (Read/Write) Устройству через канал связи ISDU. Затем по данному каналу он получает ответ Устройства.

В канале связи ISDU элемент адреса Address в управляющем октете M-последовательности размещает счетчик (= FlowCTRL). FlowCTRL контролирует лоток сегментированных данных (см. А.1.2), подсчитывая элементы ISDU (по модулю 16) во время передачи.

Ведущий узел применяет элемент длины Length из ISDU и FlowCTRL для проверки завершения передачи.

Допустимые значения FlowCTRL приведены в таблице 50.

Таблица 50 — Определения FlowCTRL

FlowCTRL

Определение

0x00 to OxOF

COUNT

Счетчик элементов в ISDU. Увеличивается начиная с 1 после запуска ISDU ISDU START. Возвращается от 15 к 0 при Событии переполнения

70

ГОСТ Р МЭК 61131-9—2017

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

FtowCTRL

Определение

0x10

START

Запуск l-Service ISDU, т. е. запуск запроса или ответа.

При запуске запроса любые ранее незавершенные услуги могут быть отброшены.

При запуске запроса, связанного с ответом. Устройство будет посылать сообщение •No Service» (Нет обслуживания) до тех пор. пока приложение не возвратит данные для ответа (см. табгыцу А.12)

0x11

IDLE 1

Нет запроса на передачу 1SDU

0x12

IDLE 2: Зарезервировано для будущего использования Нет запроса на передачу ISDU

0x13 to 0x1 Е

Зарезервировано

0x1F

ABORT

Отменить обслуживание.

Ведущий узел отвечает отбрасыванием полученных данных ответа.

Устройство отвечает отбрасыванием полученных OD и может сгенерировать аварийное прекращение

В состоянии ldle_1 значения от 0x12 до 0x1F не будут приводить к ошибке связи.

7.3.6.3 Конечная машина обработчика ISOU на Ведущем узле

На рисунке 49 показана конечная машина обработчика ISDU на Ведущем узле.

Рисунок 49 — Конечная машина обработчика ISDU на Ведущем узле В таблице 51 показаны таблицы перехода состояний обработчика ISDU на Ведущем узле. Таблица 51 — Таблицы перехода состояний обработчика ISDU на Ведущем узле

Имя состояния

Описание состояния

InacUveJJ

Ожидание активации

Wle_1

Ожидание передачи следующих ОО

ISDURequest_2

Передача OD ISDU

71

ГОСТ Р МЭК 61131-9—2017

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

Имя состояния

Описание состояния

ISDUWat_3

Ожидание ответа от Устройства. Наблкщвние за временем ISDU ISDUTime

1SDUError_4

Обработка ошибки после ее обнаружения: Вызов отрицательного ответа DL_ISDU_ Transport с информацией об ошибке при передаче ISDU ISDUTransportErrorinfo

ISDUResponse_5

Получение ответа от Устройства

Переход

Исходное

состояние

Конечно*

состояние

Действие

T1

0

1

Т2

1

2

Вызывает OD.req с условием запуска записи ISDU: OO.req (W. ISDU. flowCtrl = START, данные)

ТЗ

2

2

Вызывает OD.req записью данных ISDU и FlowCTRL при условиях, приведенных в таблице 50

Т4

2

3

Запускает таймер ISDU (ISDUTime)

Т5

3

3

Вызывает OD.req с условием запуска чтения ISDU: OD.req (R. ISDU. flowCtrl = START)

Тб

3

5

Останавливает таймер (ISDUTime)

Т7

5

5

Вызывает OD.req с чтением данных ISDU и FlowCTRL при условиях, приведенных в таблице 50

Т8

5

1

Вызывает положительное подтверждение DL_ ISDUTransport

T9

3

4

Т10

5

4

Т11

4

1

Вызывает OD.req с прекращением ISDU: OD.req (R. ISDU. RowClrl = ABORT). Вызывает отрицательное подтверждение DL_ ISDUTransport

Т12

2

4

Т13

1

1

Вызывает OD.req с соответствующими данными.

Вызывает положительное подтверждение DL_ReadParam/DL_ WrileParam

Т14

1

1

Вызывает OD.req с сообщением о простое: OD.req (R. ISDU. flowCtrl = IDLE)

Т15

4

1

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

Т16

1

0

Т17

3

4

Т18

5

4

Т19

2

4

Внутренние элемент»

Тип

Определение

ISDUTime

Время

Измерение времени ответа Устройства (сторожевая схема, см. таблицу 97)

ResponseStart

Услуга

OD.cnf (данные, отличные от ISDU_BUSY)

Param Request

Услуга

DL_ReadParam или DL_WriteParam

Error

Перемен

ная

Любая определимая ошибка в передаче ISDU. или запросы DLJSOUAbort. или любые нарушения времени подтверждения ISDU (см. таблицу 97)

72

ГОСТ Р МЭК 61131-9—2017

7.3.6.4 Конечная машина обработчика ISDU на Устройстве

На рисунке 50 показана конечная машина обработчика ISDU на Устройстве.

ISOURmth    iSCKIRmiV

T7    TS

Рисунок 50 — Конечная машина обработчика ISOU на Устройстве В таблице 52 показаны таблицы перехода состояний обработчика ISDU на Устройстве.

Таблица 52 — Таблицы перехода состояний обработчика (SDU на Устройстве

Имя состояния

Описание состояния

lnactrve_0

Ожидание активации

И1е_1

Ожидание передачи следующего ISDU

ISDURequest_2

Прием запроса ISDU

ISDUWail_3

Ожидание данных для передачи изАЬ (см. DLJSOUTransporl)

ISDUResponse_4

Передача данных ответа ISDU

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Т2

1

2

Начинает получение OD ISDU

ТЗ

2

2

Получает OD ISDU

Т4

2

3

Вызывает DL_ ISDUTransportind к AL (см. 7.2.1.6)

Т5

3

3

Вызывает OD.rsp с индикацией «busy» («занято») (см. таблицу А. 14)

Тб

3

4

Т7

4

4

Вызывает OD.rsp с данными ответа ISDU

Т8

4

1

T9

2

1

Т10

3

1

Вызывает DL_ ISDUAbort

Т11

4

1

Вызывает DL_ ISDUAbort

Т12

1

0

Т13

2

1

Т14

1

1

Вызывает OD.rsp с индикацией «по service» («нег обслуживания») (см. табг*тцыА.12иА.14)

73

ГОСТ Р МЭК 61131-9—2017

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

Внутренние элементы

Тип

Определение

ISDUStart

Услуга

OD.ind(W. ISDU. Start. Data)

ISDUWnte

Услуга

OD.ind(W, ISDU. FtowCtrl. Data)

iSDURecComptete

Условие

Если получено OD.ind(R. ISDU. Start. ...)

ISDURespStart

Услуга

DL_ ISDUTransporLrspO

(SDURead

Услуга

OD.ind(R. ISDU. Start or FtowCW. ...)

ISDUSendComplete

Условие

Если получено OD.ind(R. ISDU. IDLE....)

ISDU Abort

Услуга

OD.ind(R/W. ISDU. Abort. ...)

ISDUError

Условие

Если структура ISDU неправильная

7.3.7 Обработчик команд

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

Обработчик команд посылает управляющий код (PDOUTVAUD или PDOUTINVAUD). содержащийся в сервисном примитиве DL_Control.req. к циклически работающему обработчику сообщений через услугу OD.req и команды Ведущего узла. Обработчик сообщений применяет канал связи страниц.

Допустимые управляющие коды для выходных РО приведены в таблице 53.

Таблица 53 — Управляющие коды

Управляющий код

Команда ведущею узла

Описание

PDOUTVAUD

ProcessDataOutputOperate

Допустимые выходные PD

PDOUTINVAUD

DeviceOperate

Недопустимые или отсутствующие выходные PD

Обработчик команд получает информацию о состоянии входных PD через услугу PDInStatus и распространяет ее в пределах сервисного примитива DL_Control.ind.

Кроме тою. обработчик команд транслирует запросы на изменение режима Устройства от SM в соответствующие команды Ведущего узла (см. таблицу 8.2).

7.3.7.2 Конечная машина обработчика команд Ведущего узла

На рисунке 51 показана конечная машина обработчика команд на Ведущем узле.

Т5

Рисунок 51 — Конечная машина обработчика команд на Ведущем узле

74

ГОСТ Р МЭК 61131-9—2017

В таблице 54 показаны таблицы перехода состояний обработчика команд на Ведущем узле.

Таблица 54 — Таблицы перехода состояний обработчика команд на Ведущем узле

Имя состояния

Описание состояния

lnacttve_0

Ожидание активации обработчиком OL

klle_1

Ожидание новой команды из AL: DL_Con(rol {состояние или выходные PD). или от SM: DL.Wnte (изменение режима Устройства, например, на режим OPERATE), или ожидание сервисного примитива PDInStatus.ind

MasterCommand_2

Подготовка данных для сервисного примитива OO.req. Ожидание запроса от обработчика OD (Commanding)

Переход

Исходное

состояние

Конечно*

состояние

Действие

T1

0

1

Т2

1

1

Если услуга PDInStatus.ind = VALID, вызывает DL_Control.ind (VALID) для сообщения AL о допустимых входных PD. Если услуга PDInStatus. ind = INVALID, вызывает DL_Control.ind (INVALID) для сообщения AL о недопустимых входных PD

ТЗ

1

1

Если услуга DL_Control.req = PDOUTVALID, вызывает OD.req (WRITE. PAGE. 0. 1. MasterCommand = 0x98).

Если услуга DL_Controt.req = PDOUTINVALID. вызывает OD.req (WRITE. PAGE. 0. 1. MasterCommand s 0x98). См. таблицу B.2

Т4

1

2

Услуги DL Write DEVICEMODE транслируют в:

INACTIVE:"OD.req (WRITE. PAGE. 0. 1. MasterCommand = 0x5A) STARTUP: OD.req (WRITE. PAGE. 0.1. MasterCommand = 0x97) REOPERATE: OO.req (WRITE. PAGE. 0. 1. MasterCommand = 0x9A) OPERATE: OD.req (WRITE. PAGE. 0. 1. MasterCommand = 0x99)

Т5

2

1

Вызов услуга Commanding из обработчика OD заставляет обработчик команд вызвать сервисный примитив OO.req и затем обработчик сообщений для посылки соответствующей команды Ведущего узла в Устройство

Тб

1

0

Внутренние элементы

Тип

Определение

DEVICEMOOE

Метка

Любой из следующих режимов Устройства: INACTIVE. STARTUP. PREOPERATE или OPERATE

PDOUT

Метка

Любой из двух выходных управляющих кодов: PDOUTVALID или PDOUTINVALID (см. таблицу S3)

7.3.7.3 Конечная машина обработчика команд на Устройстве

На рисунке 52 показана конечная машина обработчика команд на Устройстве. Как правило, она контролируется командами Ведущего узла из обработчика команд Ведущего узла для управления режимами Устройства и состоянием выходных PD. Она также контролирует состояние входных PD через услугу PDInStatus.

01_СвлКЫ_Р01М

тз

Рисунок 52— Конечная машина обработчика команд на Устройстве

75

ГОСТ Р МЭК 61131-9—2017

В таблице S5 показаны таблицы перехода состояний обработчика команд на Устройстве.

Таблица 55 — Таблицы перехода состояний обработчика команд на Устройстве

Имя состояния

Описание состояния

lnacUve_0

Ожидание активации

ldle_1

Ожидание следующей команды Ведущего узла

CommandHandler_2

Разложение команды Ведущего узла и вызов конкретных действий (см. В. 1.2): если команда Ведущего узла = 0х5А. то изменить состояние Устройства на INACTIVE. Если команда Ведущего узла = 0x97, то изменить состояние Устройства на STARTUP. Если команда Ведущего узла = ОхЭА. то изменить состояние Устройства на PREOPE-RATE. Если команда Ведущего узла = 0x99. то изменить состояние Устройства на OPERATE

Переход

Исходное

состояние

Конечно*

состояние

Действие

T1

0

1

Т2

1

1

Вызывает DL_Control.ind (PDOUTVALID). если полученная команда Ведущего узла = 0x98. Вызывает DL.Control.ind (PDOUTINVALIO). если полученная команда Ведущего узла = 0x99

тз

1

1

Если услуга DL_Control.req (VALID), то вызывает PDinSlatus.req (VALID). Если услуга DL_Contro!.req (INVALID), то вызывает PDinSlatus.req (INVALID). Обработчик сообщений применяет услугу PDInStatus для установки или сброса флага состояния PD (см. А. 1.5)

Т4

1

2

Т5

2

1

Тб

1

0

Внутренние элементы

Тип

Определение

«отсутствуют»

7.3.8 Обработчик Событий

7.3.8.1 События

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

Общая структура и кодирование Событий установлены в разделе А.6. Коды событий без деталей установлены в таблице А.16. Коды событий EventCodes с деталями установлены в приложении D. Структура памяти Событий для кодов событий с деталями установлена в таблице 56.

Таблица 56 — Память Событий

Адрес

Номер области памяти События

Имя параметра

Описание

0x00

StatusCode

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

0x01

1

EventQualifier 1

Тип. режим и источник События

0x02

EventCode 1

16-битовый кед События

0x03

0x04

2

EventQualifier 2

Тип. режим и источник События

0x05

EventCode 2

16-битовый кед События

0x06

76

ГОСТ Р МЭК 61131-9—2017

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

Адрес

Номер области памяти События

Имя параметра

Описание

0x10

6

EventQualifier 6

Тип. режим и источник События

0x11

EventCode 6

16-битовый код События

0x12

0x13to 0x1F

Зарезервировано для будущего использования

7.3.8.2    Обработка событий

AL Устройства записывает Событие в память Событий и затем устанавливает бит флага события Event flag, который посылается в Ведущий узел в следующем сообщении в пределах октета контроль* ной суммы CKS (см. 7.3.3.2 и А.1.5).

При получении ответного сообщения Устройства с битом флага События Event flag - 1 Ведущий узел переключится из режима обработчика ISDU в режим обработчика Событий. Обработчик Событий начинает чтение кода состояния StatusCode.

Если бит «Event Details» установлен (см. рисунок А.23), Ведущий узел будет читать подробную информацию о Событиях, указанную в коде состояния StatusCode из памяти Событий. После чтения деталей События он вызовет услугу DL_Evenlind. После получения услуги DL_EventConf Ведущий узел запишет произвольную информацию в код состояния StatusCode. чтобы сбросить бит флага события Event flag. Обработка События на ведущем узле будет завершена вне зависимости от содержания полученных данных события (EventQuatifier. EventCode).

Если бит деталей события Event Details не установлен (см. рисунок А.22), Ведущий узел сгенерирует стандартизованные События в соответствии с таблицей А.16. начиная со старшего бита в коде События EventCode.

Доступ на запись к коду состояния StatusCode указывает на конец обработки События для Устройства. Устройство будет игнорировать данные этого доступа Ведущего узла на запись. Затем устройство сбрасывает бит флага события Event flag и может теперь изменять содержание полей в памяти Событий.

7.3.8.3    Конечная машина обработчика Событий Ведущего узла

На рисунке S3 показана конечная машина обработчика Событий на Ведущем узле.

Рисунок S3 — Конечная машина обработчика Событий на Ведущем узле

77

ГОСТ Р МЭК 61131-9—2017

В таблице 57 показаны таблицы перехода состояний обработчика Событий на Ведущем узле.

Таблица 57 — Таблицы перехода состояний обработчика Событий на Ведущем узле

Имя состояния

Описания состояния

lnactrve_0

Ожидание активации

Wle_1

Ожидание следующей индикации События (услуга EventTrig через обработчик 00) или подтверждения События через услугу DL_EventConf из AL Ведущего узла

ReadEvent_2

Чтение набора данных События из сообщения Устройства с использованием адреса памяти Событий. Проверка кода состояния StatusCode на предмет числа активированных Событий (см. таблицу 56}

SignalEvent_3

Анализ данных События и вызов индикации DL_Event к AL Ведущего узла (см. 7.2.1.15} для каждого доступного События

Event Confirmation_4

Ожидание передачи подтверждения События через услугу OO.req 8 Устройство

Пер**од

Исходное

состояние

Конечное

состояние

Действия

T1

0

1

T2

1

2

Чтение октета кода состояния StatusCode через услугу OO.req (R. DIAGNOSIS. Event memory address = 0.1}

T3

2

2

Чтение октета из памяти Событий через услугу OO.req (R, DIAGNOSIS, увеличенный адрес памяти Событий. 1}

T4

2

3

T5

3

1

Тб

2

0

T7

1

4

T8

4

1

Вызывает OO.req (W. DIAGNOSIS. 0. 1. любые данные) с доступом на запись к коду состояния StatusCode (см. таблицу 56). чтобы подтвердить Устройству факт считывания События

T9

4

0

T10

1

0

внутренние элементы

Тип

Определения

«отсутствуют?

7S

ГОСТ Р МЭК 61131-9—2017

7.3.8.4 Конечная машина обработчика Событий на Устройстве

На рисунке 54 показана конечная машина обработчика событий на Устройстве.

Рисунок 54 — Конечная машина обработчика Событий на Устройстве В таблице 58 показаны таблицы перехода состояний обработчика Событий на Устройстве. Таблица 58 — Таблицы перехода состояний обработчика Событий на Устройстве

Имя состояния

Описание состояния

lnacUve_Q

Ожидание активации

И1е_1

Ожидание услуги DL_Event из AL предоставлявшей данные о Событии, и услуги DL_EventTrigger для установки бита флага события Event flag {см. А. 1.5)

FreezeEventMefnory_2

Ожидание чтения памяти Событий и подтверждение считывания памяти Событий через доступ на запись в код состояния StatusCode

Переход

Исходное

состояние

Конечное

состояние

Действие

Т1

0

1

Т2

1

1

Изменение входов памяти Событий новыми даншми События (см. таблицу 56)

тз

1

2

Вызывает услугу EventFlag.req (Rag = TRUE) для индикации Ведущему узлу активации События через бит флага события Event flag. Отметить все входы памяти Событий как неизменяемые

Т4

2

2

Ведущий узел требует данные памяти Событий через услугу EventRead (= OD.ind). Посылает данные События OD.rsp с данными из указанных адресов памяти Событий

Т5

2

1

Вызывает услугу EventFlag.req (Flag = FALSE) для индикации Ведущему узлу факта деактивации События через бит флага события «Event Падв. Отмечает все адреса в памяти Событий как недоступные 8 соответствии с А.6.3

Тб

1

1

Посыпает содержимое памяти Событий, вызывая услугу OO.rsp с данными События

Т7

1

0

те

2

0

Сбрасывает данные памяти Событий

Внутренние элементы

Тип

Определение

EventReed

Услуга

OD.ind (R. DIAGNOSIS, адрес памяти События, длина, данные)

EventConf

Услуга

OD.ind (W. DIAGNOSIS, address = 0. данные = безразлично какие)

79

ГОСТ Р МЭК 61131-9—2017

8 Прикладной уровень (AL)

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

На рисунке 55 приводятся структура и услуги AL Ведущего узла.

И^гагадочидтосту(iMwngi tnqmwtai |Пасп«|емтмьиэс1ьс-аобци«itlll

Прапааипня Baeyuiare уам

Рисунок 55 — Структура и услуги AL {Ведущий узел) На рисунке 56 приводятся структура и услуги AL Устройства.

Припаши чч yetpofMtM

Рисунок 56 — Структура и услуги AL (Устройство)

80

ГОСТ Р МЭК 61131-9—2017

8.2 Услуги прикладного уровня

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

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

Таблица 59 — Услуги AL на Ведущем узле и на Устройстве

Имя услуги

Ведущий узел

Устройство

AL_Read

R

1

AL_ Write

R

1

AL_Abort

R

1

AL_Getlnput

R

AL.NewInput

1

AL.Setlnput

R

AL.PDCyde

1

1

AL.GetOutput

R

AL_NewOutput

1

AL.SetOutput

R

AL_Event

I/R

R

AL.Control

I/R

I/R

Обозначения (см. 3.3.4):

1 — Инициатор услуги;

R — Приемник (Ответчик) услуги.

8.2.2 Услуги прикладного уровня

8.2.2.1 Услуга AL_Read

Услуга AL_Read применяется для чтения OD из Устройства, подключенного к конкретному порту. Параметры сервисных примитивов приведены в таблице 60.

Таблица 60 — AL_Read

Имя параметра

.req

Ю4

.rsp

.Cf><

Argument

M

M

Port

M

Index

M

M

Subindex

M

M

Result (+)

s

S(=)

Port

M

Data

M

M<=)

Result (-)

s

S(=)

Port

M

Errorinfo

M

M<=)

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре. Port (Порт)

Параметр содержит номер порта для считываемых OD.

Тип параметра: Unsigned8.

81

ГОСТ Р МЭК 61131-9—2017

Index (Индекс)

Данный параметр указывает адрес объектов OD. считываемых из Устройства. Индекс 0 вместе с Субиндексом 0 адресует весь набор Непосредственных параметров от 0 до 15 (см. страницу 1 Непосредственных параметров в таблице 8.1) или вместе с Субиндексами от 1 до 16 отдельные параметры от 0 до 15. Индекс 1 вместе с Субиндексом 0 адресует весь набор Непосредственных параметров с адресами от 16 до 31 (см. страницу 2 Непосредственных параметров в таблице В.1) или вместе с Субиндексами от 1 до 16 непосредственные параметры от 16 до 31. Он применяет канал связи страниц (см. рисунок 6) для обеих страниц и всегда возвращает положительный результат. Для всех других индексов (см. 8.2) применяется канал связи ISDU.

Допустимые значения от 0 до 65 535 (ограничения описаны в пункте В.2.1).

Subindex (Субиндекс)

Данный параметр указывает номер элемента в структурированном объекте OD. Значение О указывает на весь набор элементов.

Допустимые значения от 0 до 255.

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Port (Порт)

Данный параметр содержит номер порта затребованных OD.

Data (Данные)

Данный параметр содержит считанные значения OD.

Тип параметра: Строка октетов.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Port (Порт)

Данный параметр содержит номер порта для запрошенных OD.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения см. приложение С.

Примечание — AL отображает информацию об ошибке DL на свою собственную информацию об ошибке. применяя приложение С.

8.2.2.2 Услуга AL_Write

Услуга AL_Write применяется для записи OD на Устройство, подключенное к указанному порту. Параметры сервисных примитивов приведены в таблице 61.

Таблица 61—УслугаAL_Wrrte

Имя параметра

.req

md

.rap

.cnf

Argument

M

M

Port

M

Index

M

M

Subindex

M

M

Data

M{=)

Result (+)

S

S(=)

Port

M

Result (-)

s

S(=)

Port

M

Errortnfo

M

M<=)

82

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Port (Порт)

Параметр содержит номер порта для записываемых OD.

Тип параметра: llr>signed8.

Index (Индекс)

Данный параметр указывает адрес объектов OD. записываемых на Устройство. Индекс 0 всегда возвращает отрицательный результат. Индекс 1 вместе с Субиндексом 0 адресует весь набор Непосредственных параметров с адресами от 16 до 31 (см. страницу 2 Непосредственных параметров в таблице В.1) или вместе с Субиндексами от 1 до 16 отдельные параметры от 16 до 31. Он применяется для канала связи страниц (см. рисунок 6) в случае Индекса 1 и всегда возвращает отрицательный результат. Для всех других индексов (см. подраздел В.2) применяется какал связи ISDU.

Допустимые значения от 1 до 65 535 (см. таблицу 97).

Subindex (Субиндекс)

Данный параметр указывает номер элемента в структурированном объекте OD. Значение О указывает на весь набор элементов.

Допустимые значения от 0 до 255.

Data (Данные)

Данный параметр содержит значения OD.

Тип параметра: Строка октетов.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Port (Порт)

Данный параметр содержит номер порта OD.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Port (Порт)

Данный параметр содержит номер порта OD.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения см. приложение С.

8.2.2.3 Услуга AL_Abort

Услуга AL_Abort служит для прерывания услуг AL_Read или AL_Write на указанном порту. Вызов этой услуги отменяет ответ на услугу AL_Read или AL_Write. выполняемую на Ведущем узле. Параметры сервисных примитивов приведены в таблице 62.

Таблица 62—AL_Abori

Имя параметра

.roq

Argument

М

м

Port

М

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Port (Порт)

Данный параметр содержит номер порта прерываемой услуги.

83

ГОСТ Р МЭК 61131-9—2017

8.2.2.4 Услуга AL_Getlnput

Услуга AL_Getlnput считывает входные данные в PD. предоставленных DL Устройства, подклю ценного к указанному порту. Параметры сервисных примитивов приведены в таблице 63.

Таблица 63 — УслугаAL_Getlnput

Имя параметра

.req

cnf

Argument

M

Port

M

Result (+)

s

Port

M

InputData

M

Result (-)

s

Pori

M

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Port (Порт)

Параметр содержит номер порта для считываемых PD.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Port (Порт)

Данный параметр содержит номер порта РО.

InputData (ВходныеДанные)

Данный параметр содержит значения затребованных входных PD указанного порта.

Тип параметра: Строка октетов.

Result (-) (ОтрицательныйРвзультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Port (Порт)

Данный параметр содержит номер порта PD.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO.DATA (DL не предоставляет PD).

в.2.2.5 Услуга AL_Newlnput

Локальная услуга AL_New!nput указывает на получение обновленных входных данных в PD Устрой ства. подключенною к указанному порту. Параметры сервисных примитивов приведены в таблице 64.

Таблица 64 — УслугаAl_Newlnput

Имя параметра

.ind

Argument

M

Port

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

84

Port (Порт)

Данный параметр содержит номер порта OD.

ГОСТ Р МЭК 61131-9—2017

8.2.2.6 Услуга AL_Setlnput

Локальная услуга AL_Setlnput обновляет входные данные в РО Устройства. Параметры сервис

ных примитивов приведены в таблице 65.

Таблица 65 — Услуга AL_Setlnput

Имя параметра

.req

.cnf

Argument

M

InputData

M

Result (+)

s

Result (-}

s

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

InputData (ВходныеДанные)

Данный параметр содержит значения PD входных данных, подлежащих передаче.

Тип параметра: Строка октетов.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Result (-) (ОтрицательныйРезупьтат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

STATE_CONFLICT (в текущем состоянии услуга недоступна).

8.2.27 Услуга AL_PDCyde

Локальная услуга AL_PDCyde указывает на конец цикла PD. Приложение Устройства может применять эту услугу для передачи новых входных данных AL через услугу AL_Setlnput. Параметры сервисных примитивов приведены в таблице 86.

Таблица 66 — УслугаAl_PDCycle

Имя параметра

.ind

Argument

Port

0

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Port (Порт)

Данный параметр содержит номер порта полученных новых PD (только Ведущий узел).

8.2.2.8 Услуга AL_GetOutput

Услуга AL_GetOutput считывает выходные данные в РО. предоставленных DL Устройства. Параметры сервисных примитивов приведены в таблице 67.

85

ГОСТ Р МЭК 61131-9—2017

Таблица 67 — Услуга Al_GetOutput

Имя параметра

,req

cnf

Argument

M

Result {+)

s

InputData

M

Result (-)

s

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

InputData (ВыходныеДанныв)

Данный параметр содержит значения OD затребованных выходных данных.

Тип параметра: Строка октетов.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Errorlnfor (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

NO_DATA (DL не предоставляет PD).

8.2.2.9 Услуга AL_NewOutput

Локальная услуга AL_NewOutput указывает на получение обновленных выходных данных в PD Устройства. Данная услуга не имеет параметров. Сервисные примитивы показаны в таблице 68.

Таблица 68 — УслугаAL_NewOutpul

Имя параметра

.ind

«отсутствуют»

8.2.2.10 Услуга AL_SetOutput

Локальная услуга AL_SetOutput обновляет выходные данные в PD Ведущего узла. Параметры сервисных примитивов приведены в таблице 69.

Таблица 69 — Услуга Al_SetOutput

Имя параметра

.req

.cn(

Argument

M

Port

M

OutputData

M

Result (+)

s

Port

M

Result (-)

s

Port

M

Errorlnfo

M

86

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Port (Порт)

Параметр содержит номер порта для записываемых PD.

OutputData (ВыходныеДанные)

Данный параметр содержит выходные данные, записываемые в указанном порте.

Тип параметра: Строка октетов.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Port (Порт)

Данный параметр содержит номер порта PD.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Port (Порт)

Данный параметр содержит номер порта PD.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

STATE_CONFLICT (в текущем состоянии услуга недоступна).

8.2.2.11 Услуга AL_E vent

Услуга AL_Event указывает до шести промежуточных состояний или сообщений об ошибке. Источник одного События может быть локальным (Ведущий узел) или удаленным (Устройство). Событие может за* пускаться уровнем связи или приложением. Параметры сервисных примитивов приведены в таблице 70.

Таблица 70 — УслугаAL_Event

Имя параметра

.req

.md

-rsp

cnf

Argument

M

M

M

M

Port

M

M

M

EventCount

M

M

Event(1) Instance

M

M

Mode

M

M

Type

M

M

Origin

M

EventCode

M

M

Event(n) Instance

M

M

Mode

M

M

Type

M

M

Origin

M

EventCode

M

M

87

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Port (Порт)

Данный параметр содержит номер порта данных События.

EventCounter (СчетчикСобытий)

Данный параметр указывает число л (от 1 до 6) Событий в памяти Событий.

Event(x) [Событие(х)]

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

Instance (Экземпляр)

Данный параметр указывает источник События.

Допустимые значения: приложение (см. таблицу А.17).

Mode (Режим)

Данный параметр указывает режим События.

Допустимые значения: SINGLESHOT. APPEARS. DISAPPEARS (см. таблицу А.20).

Туре (Тип)

Данный параметр указывает категорию События.

Допустимые значения: ERROR. WARNING. NOTIFICATION (см. таблицу А.19).

Origin (Источник)

Данный параметр указывает, было ли Событие в локальной секции связи или это удаленное Событие (в Устройстве).

Допустимые значения: LOCAL. REMOTE.

EventCode (КодСобытия)

Данный параметр содержит код. идентифицирующий определенное Событие.

Допустимые значения см. приложение D.

8.2.2.12 Услуга AL_Control

Услуга AL_Control содержит информацию о состоянии определителя PD. передаваемую в приложение Устройства или из него. Параметры сервисных примитивов приведены в таблице 71.

Таблица 71 — УслугаAL_Contro<

Имя параметра

.req

tad

Argument

M

м

Port

С

с

ControlCode

М

м

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре. Port (Порт)

Данный параметр содержит номер соответствующего порта.

88

ControlCode (УправляющийКод)

Данный параметр указывает состояние описателя PD.

ГОСТ Р МЭК 61131-9—2017

Допустимые значения:

VALID (входные PD допустимы);

INVALID (входные PD недопустимы);

PDOUTVALID (выходные PD допустимы, см. таблицу 53);

PDOUTVALID (выходные PD недопустимы, см. таблицу 53).

8.3 Протокол прикладного уровня

8.3.1    Обзор

На рисунке 7 показано, что AL предлагает услуги для объектов данных, которые преобразуются в специальные каналы связи DL.

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

8.3.2    Передача Данных запроса

8.3.2.1 Конечная машина Данных запроса прикладного уровня Ведущего узла

На рисунке 57 показана конечная машина для обработки OD на AL Ведущего узла. Термин AL_Service означает любую услугу AL из таблицы 59. связанную с OD. Обозначение Portx указывает на конкретный номер порта.

Рисунок 57 — Конечная машина 00 AL Ведущего узла

89

ГОСТ Р МЭК 61131-9—2017

В таблице 72 показаны состояния и переходы конечной машины OD AL Ведущего узла. Таблица 72 — Состояния и переходы конечной машины OD AL Ведущего узла

Имя состояния

Описание состояния

OnReq_lc9e_0

В данном состоянии могут быть приняты вызовы услуг AL из приложений Ведущего узла или из обработчика порта х SM (см. таблицу 55)

ButW_DL_Service_1

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

Awail_DL_Param_cnf_2

В данном состоянии услуга AL преобразуется в последовательность требуемого числа вызовов услуг DL_ReadParam или DL_WriteParam {доступ к страницам Непосредственных параметров, см. канал связи страниц на рисуже 6). Все происходящие асинхронно вызовы услуг AL за истечением услуги AL_Abort. отвергаются (см. 3.3.7)

Await_DL_ISOU_c*if_3

В данном состоянии вызов услуги AL преобразуется е вызов услуги DLJSDUTransport (см. канал связи ISDU на рисунке 6). Все происходящие асинхронно вызовы услуг AL за исключением услуги AL_Abort отвергаются (см. 3.3.7)

BuikJ_AL_cnf_4

В данном состоянии создается подтверждение услуги AL в зависимости от ошибки аргумента, подтверждение услуги OL или вызов услуги AL_Abor1

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Запоминание номера порта «Portx»

T2

1

4

Подготовка отрицательного подтверждения услуги AL

T3

1

2

Подготовка вызова услуги DL_ReadParam для значения Индекса 0 или 1

T4

1

2

Подготовка вызова услуги DL_WriteParam для значения Индекса 1

T5

1

2

Подготовка вызова услуги DL_WnteParam для Индекса 2. если Устройство не поддерживает ISOU

T6

1

3

Подготовка вызова услуги DLJSDUTransport(read)

T7

1

3

Подготовка вызова услуги DLJSDUTransport(write)

T8

2

2

Возврат отрицательного подтверждения услуги AL для асинхронного вызова данной услуги

T9

2

4

Запрещены действия всех текущих услуг DL. и подготавливаются отрицательные подтверждения услуг AL

T10

2

2

Вызов следующей услуги DL_ReadParam или DL_WriteParam, есгы не все 00 переданы

T11

3

4

Запрещены действия всех текущих услуг DL. и подготавливаются отрицательные подтверждения услуг AL

T12

3

3

Возврат отрицательного подтверждения услуги AL для асинхронного вызова данной услуги

T13

2

4

Подготовка положительного подтверждения услуги AL

T14

2

4

Подготовка положительного подтверждения услуги AL

T15

3

4

Подготовка положительного подтверждения услуги AL

T16

4

0

Возврат положительного подтверждения услуги AL с номером порта «Poctx*

T17

0

0

Возврат отрицательного подтверждения услуги AL с номером порта «Portx»

внутренние элементы

Тип

Определение

Argument_Error

Bool

Недопустимые значения е тепе услуги, например. «Номер порта или Индекс вне допустимого диапазоне»

DL.RWParam

Метка

DL_RWParam: возможные значения DL_WriteParam_cnf или DL_ReadParam_cnf

Completed

Bool

Не осталось 00 для передачи

Oclets_teft

Bool

Имеются 00 для передачи

Porlx

Переменная

Переменная тепа услуги, указывающая номер порта

90

ГОСТ Р МЭК 61131-9—2017

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

внутренние элементы

Тип

Определение

ISDU_Flag

Bool

Устройство поддерживает tSDU

AL_Servk®

Метка

Термин AL Service означает любую услугу AL из таблицы 59. связанную cOD

8.3.2.2 Конечная машина Данных запроса прикладного уровня Устройства На рисунке 58 показана конечная машина для обработки OD AL на Устройстве.

Di ISDUTrenapwt tfto(DifWttey Тв"

Рисунок 58 — Конечная машина OD AL на Устройстве В таблице 73 показаны состояния и переходы конечной машины OD AL на Устройстве.

Таблица 73 — Состояния и переходы конечной машины ODAL на Устройстве

Имя состояния

Описание состояния

кЯе_0

AL Устройства ожидает подчиненные вызовы услуг DL. запущенных сообщениями Ведущего узла

Await_AL_Write_rsp_1

AL ожидает ответа от специальных технических приложений (доступ на запись к странице Непосредственных параметров)

Await_AL_Read_rsp_2

AL ожидает ответа от специальных технических приложений (доступ на чтение к странице Непосредственных параметров)

Await_AL_RW_rsp_3

AL ожидает ответа от специальных технических приложений (доступ на чтение или запись через ISDU)

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Вызов AL_Write

Т2

1

0

Вызов OL.WriteParam (номер параметра от 16 до 31)

тз

0

2

Вызов AL_Read

Т4

2

0

Вызов DL_ReadParam (номер параметра от 0 до 31)

Т5

0

3

Вызов AL_Read

Тб

0

3

Вызов AL.Write

Т7

3

0

Вызов DL_ ISDUTransportfread)

Т8

3

0

Вызов DL_ ISDUTranspotl(write)

T9

3

0

Текущие услуги AL_Read или AL.Wnte отменяются при этом асинхронном вызове услуги AL_Abor1. Возвращает отрицательный результат услуги DLJSDUTiansportfCM. 3.3.7)

Т10

3

0

Текущее ожидание AL_Read или AL_Write прекращается

Т11

0

0

Текущая услуга DL_ ISDUTransport прекращается. Все OD обнуляются

91

ГОСТ Р МЭК 61131-9—2017

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

Внутренние элементы

Тип

Определение

DtfRead

Bool

Направление доступа: Вызов DL_ ISDUTransport(read) приводит к вызову AL_Read

DifWrrte

Bool

Направление доступа: Вызов DL_ ISDUTransport(wrXe) приводит к вызову AL_Write

8.3.2.3 Диаграммы последовательностей для Данных запроса

На рисунках 59—61 продемонстрированы все взаимодействия между Ведущим узлом и Устройством для определенных сценариев использования обмена OD.

На рисунке 59 показаны два примера обмена OD. Для значений Индекса больше 1 обмены выполняются с помощью ISDU и соответствующих услуг DL (канал связи ISOU в соответствии с рисунком 6). Доступ к страницам 0 и 1 Непосредственных параметров применяет различные услуги DL (канал связи страниц в соответствии с рисунком 6).

Рисунок 59 —Диаграмма последовательностей при передаче OD

На рисунке 60 показано поведение обмена OD в случае ошибки, такой как недоступность затребованного Индекса (см. таблицу С.1).

Другая возможная ошибка происходит, когда приложение Ведущего узла (шлюз) пытается считать Индекс больший, чем 1 из Устройства, которое не поддерживает ISDU. AL Ведущего узла должен немедленно отреагировать сообщением отсутствия поддержки ISDU «NO_ISDU_SUPPORTED» (ISDU не поддерживается), поскольку характеристики Устройства собираются во время запуска страницы 1 Непосредственных параметров через параметр свойств М-лоспедовательности «М-sequence Capability» Свойства М-лоследовательности) (см. таблицу В.1).

92

ГОСТ Р МЭК 61131-9—2017

Рисунок 60 — Диаграмма последовательное гей для ОО в случав ошибок

На рисунке 61 показано поведение обмена ОО в случае превышения лимита времени ISDU (5500 мс). Устройство будет реагировать е течение промежутка «ISDU acknowledgement time» (Время подтверждения ISDU) (см. 10.7.5).

Примечание — См. таблицу 97 с параметрами системы, такими как ISOU acknowledgement time (Время подтверждения ISDU).

93

ГОСТ Р МЭК 61131-9—2017

8.3.3 Обработка Событий

8.3.3.1 Конечная машина Событий прикладного уровня Ведущего узла На рисунке 62 показана конечная машина Событий AL на Ведущем узле.

0l_E'»*1_tndl6'rtntejefl)i

та

Рисунок 62 — Конечная машина Событий AL на Ведущем узле В таблице 74 устанавливаются состояния и переходы конечной машины Событий AL Ведущего узла. Таблица 74 — Состояния и переходы конечной машины Событий AL на Ведущем узле

Имя состояния

Описание состояния

Evenl_inactive_0

Обработка Событий AL на Ведущем узле неактивна

Event_idle_l

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

Read_Event_Set_2

AL Ведущего узла получил услугу DL_Event _ind с диагностической информацией. После первой услуги DL_Event.ind AL собирает полный набор (от 1 до 6) событий DL OL.Events от текущего триггера событий EventTrigger (см. 11.5)

DU_Evenl_handting_3

AL Ведущего узла остается в этом положении до тех пор. пока Блок диагностики (см. 11.5) не подтвердит информацию о событиях AL AL_Eventind

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

T2

1

0

ТЗ

1

2

Т4

2

2

Т5

2

3

AL_Event.ind

Тб

3

1

DL_EventConf.req

Т7

1

1

AL_Event.ind

94

ГОСТ Р МЭК 61131-9—2017

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

Внутренние элементы

Тип

Определение

Diag_Po«1x

Bool

Набор событий содержит подробную диагностическую информацию

Events_dooe

Bool

Набор событий обработан

Eventsjeft

Bool

Набор событий еще не полом

8.3.3.2 Конечная машина Событий прикладного уровня на Устройстве На рисунке 63 показана конечная машина Событий AL на Устройстве.

Рисунок 63 — Конечная машина Событий прикладного уровня на Устройстве

В таблице 75 устанавливаются состояния и переходы конечной машины Событий AL на Устройстве. Таблица 75 — Состояния и переходы конечной машины Событий AL на Устройстве

Имя состояния

Описание состояния

Event_inactve_0

Обработка Событий AL на Устройстве неактивна

Event_idle_1

AL Устройства готов к приему Событий AL AL_Events {диагностической информации) от приложений специального технического Устройства для дальнейшей передачи на DL. В это время приложения Устройства могут создавать новые События

Awail_event_response_2

AL Устройства распространил События AL AL_Event с диагностической информацией и ожидает подтверждения триггера событий DL. AL Устройства не будет принимать никаких Событий ALAL_Event в Данный период времени

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Т2

1

0

ТЗ

1

2

Запрос События AL возбуждает Событие DL и вызывает соответствующую услугу DL_EvenlTrigger DL. Событие DL передает диагностическую информацию от AL на DL. Услуга DL_EventTrigger устанавливает флаг События во время циклического обмена данными (см. А. 1.5)

Т4

2

1

Подтверждение DL_EventTngger порождает подтверждение События AL

95

ГОСТ Р МЭК 61131-9—2017

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

Внутренние элементы

Тип

Определение

«отсутствуют»

8.3.3.3 График единичного События

На рисунка 64 показано, как обрабатывается единичное Событие из Устройства в соответствии с подходящими конечными машинами.

- Приложение Устройства создает запрос События (Шаг 1). который передается с AL на DL и буферизуется в памяти Событий (см. таблицу 56).

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

•    Затем Ведущий узел передает данное Событие приложению шлюза (Шаг 2) и ожидает подтверждения События.

•    После получения подтверждения о Событии (Шаг 3) Устройство оповещается об этом через запись в код состояния StatusCode (Шаг 4).

•    Устройство подтверждает первоначальный запрос События своему приложению (Шаг 5). которое может теперь инициировать новый запрос События.

Рисунок 64 — График одиночного События

96

ГОСТ Р МЭК 61131-9—2017

6.3.3.4    Передача множественных Событий (только устаревшие Устройства)

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

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

Один запрос AL_Event.req содержит до шести Событий, и один индикатор AL_Event.ind может содержать до шести ждущих Событий. Услуги AL_Event.rsp и AL_Event.cnf ссылаются на полный указанный набор Событий.

8.3.4    Циклы Данных процесса

На рисунках 65 и 66 показаны полные взаимодействия между Ведущим узлом и Устройством для сценариев использования выходных и входных PD.

На рисунке 65 показано, как услуги AL и DL Ведущего узла и Устройства вовлечены в циклический обмен выходными OD. Приложение Устройства может собирать текущие значения выходных РО. применяя услугу AL_GetOutput.

Рисунок 65 —Диаграмма последовательностей для выходных PD

На рисунке 66 показано, как услуги AL и DL Ведущего узла и Устройства вовлечены в циклический обмен входными OD. Приложение Ведущего узла может собирать текущие значения входных PD, применяя услугу AL_Getlnput.

97

ГОСТ Р МЭК 61131-9—2017

Рисунок 66 — Диаграмма последовательностей для входных PD

9 Модуль управления системой (SM)

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

SM SDCI несет ответственность за координированный запуск портов в Ведущем узле и соответствующие операции с подключенными Устройствами.

Разница между SM на Ведущем узле и на Устройстве более значительна, чем разница между другими уровнями. Поэтому структура раздела 9 различает услуги и протоколы ведущего узла и Устройства.

9.2 Модуль управления системой на Ведущем узле

9.2.1 Обзор

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

SM на Ведущем узле регулирует порты через:

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

-    проверку совместимости Устройства (характеристики реального Устройства должны соответствовать ожидаемым значениям);

98

ГОСТ Р МЭК 61131*9—2017

•    регулировки соответствующих типов ^^последовательностей Ведущего узла и времен цикла Be* дущего узла.

Для этого применяются услуги, показанные на рисунке 67:

•    услуга SM_SetPortConfig передает требуемые параметры Устройства (данные конфигурации) от СМ к SM. После этого порт запускается неявным образом;

•    услуга SM_PortMode сообщает положительные результаты о настройке порта обратно в СМ в случае правильной настройки и проверки порта. Она сообщает об отрицательных результатах об* ратно в СМ через соответствующие «ошибки» в случае несоответствия версий или несовместимых Устройств;

•    услуга SM_GetPortConfig считывает фактические и эффективные параметры;

•    услуга SM_Operate переключает порты в режим «OPERATE».

На рисунке 67 представлен обзор структуры и услуг управления системой на Ведущем узле.

SM на ведущем узле требует одной услуги AL (AL_Read) для сбора данных (идентификационных параметров) из специальных Индексов для проверки.

Прмложвмм« воду«мо угла

Рисунок 67 — Структура и услуги управления системой на Ведущем узле

На рисунке 68 показаны взаимодействия между уровнями приложения Ведущего узла (Master Арр). CM. SM. DL и AL для сценария запуска конкретного порта.

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

•    устройство для доступной конфигурации подключено, и проверка оказалась успешной:

•    устройство применяет правильную версию протокола в соответствии с настоящей спецификацией;

•    сконфигурированный уровень проверки InspectionLevei — «type compatible» (совместимый по типу) (заводской номер SerialNumber считан с устройства, но не проверялся).

Пунктирные стрелки на рисунке 68 представляют ответные сигналы услуг.

99

ГОСТ Р МЭК 61131-9—2017

iflQOr X)

OoMbneUMofixcowOCC)

OptvteO

(floor X}

*v*»V

SM,SMP»nConll9.r*qi)

(Сткоггаомгссв!

а*м

•    Г>—|ЦИ>1

rw«II*><

Тяклиммтмм

(«ЕСРбНАЯ)

•    Iftieve iPeECWRAIR

Огйгогя

flOCOMW^ ЛНЛЖ& •*}«* t

$м_Ро>!Моов.<»<1$омкело*)

SM.CelPeXCenAeLXMO

£

tOwe* «еенетрае i

$М Орммй

5M_Poitt»od*.ino>OP£R*Tei

О1.»«мооо_оад

<3*ysri

X.RoMI)

(HwoaxcCTwnw r-ipauerp i)

(X_SwWoOO.«wiPft60PEft*TE)

iCivmb

(X .UMJoflPREOPeftttf)

Roixti)

Зоомадй 'Сию)

Мпн>

Лаик _

ККМТЕ)

-Ор*«а<ши**«цч»№

га»Ю*ЕМТЕ>

OL.SolUodo.'tol)

(OPERATE Смшпйомотрое)

Ol.Mo4«..od<OPeRATE| ;

> Hwtvfl

4

J

I £»>•:-> wi«    ^

I »Mmr»pp»n 1 Н(АМрЦО»*Н«1

nicewew    I

/

|>1*Ч'Ч

•    ге»Ом|»ин

■0*mC'j—>'Ш «ор«х%

•    -> Стоим ЗТАЯПР

вмспм

-Саетаим»

PRECPfOATE

/

ЙИвтма

-СмтвмаОРСМте

1

Рисунок 68 — Схема последовательности сценария испотъзования «Настройка порта»

9.2.2 Услуги модуля управления системой на Ведущем узле

9.2.2.1 Обзор

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

100

ГОСТ Р МЭК 61131-9—2017

Таблица 76 — УслугиSMна Ведущем узле

Имя услуги

Ведущий узел

SM_SetPortConfig

R

SM_GetPortCon6g

R

SM.PortMode

I

SM_Operate

R

Обозначения (cu. 3.3.4):

I — Инициатор услуги:

R — Приемник (Ответчик) услуги.

9.2.2.2 Услуга SM_SetPortConfig

Услуга SM_SetPortConfig применяется для установки требуемой конфигурации Устройства. Параметры сервисных примитивов приведены в таблице 77.

Таблица 77 — УслугаSM_SetPortConfig

Имя параметра

.req

.cnf

Argument

M

ParameterList

M

Result (+)

s

PortNumber

M

Result (-)

s

PortNumber

M

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

ParameterList (СписокПараметров)

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

Тип параметра: Запись.

Элементы записи:

PortNumber (НомерПорта)

Данный параметр содержит номер порта.

ConfiguredCycleTime (СконфигурированновВремяЦикла)

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

Допустимые значения:

О (свободный ход):

Время (см. таблицу В.З).

TargetMode (ЦелевойРежим)

Данный параметр указывает требуемый рабочий режим порта.

Допустимые значения: INACTIVE. Dl. DO. CFGCOM. AUTOCOM (см. таблицу 79).

ConfiguredBaudrate (СконфигурированнаяСкоростьБод)

Данный параметр указывает требуемую скорость передачи данных в бодах.

101

ГОСТ Р МЭК 61131-9—2017

Допустимые значения:

AUTO (Ведущий узел принимает скорость передачи, обнаруженную во время установки связи ESTABLISHCOM);

СОМ1 (скорость передачи порта СОМ1);

COM2 (скорость передачи порта COM2);

COM3 (скорость передачи порта COM3).

ConfiguredRevisionID (СконфигурированныйИдРевизии) (CRID)

Длина данных: один октет для версии протокола (см. В.1.5).

InspectlonLevel (УровеньПроверки)

Допустимые значения; NO_CHECK. TYPE_COMP. IDENTICAL (см. таблицу 73).

ConfiguredVendorlD (СконфигурированныйИдИэготовителя) (CVID)

Длина данных: два октета.

Примечание — ИдИзготовитвля назначается консорциумом IO-Link.

ConfiguredDevicelD (СконфигурированныйИдУстройства) (СОЮ)

Длина данных: три октета.

ConfiguredFunctionID (СконфигурированныйИдФункции) (CFID)

Длина данных: два октета.

ConfiguredSerialNumber (СконфигурированныйЗаводскойНомер) (CSN)

Длина данных: до 16 октетов.

Result (+) (ПоложитвльныйРеэультат)

Данный параметр выбора указывает, что услуга была выполнена успешно.

PortNumber (НомерПорта)

Данный параметр содержит номер порта.

Result (-) (ОтрицательныйРвзультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

PortNumber (НомерПорта)

Данный параметр содержит номер порта.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

PARAMETER_CONFLICT (нарушена корректность набора параметров).

В таблице 78 установлено кодирование различных уровней проверки (значения параметра УровеньПроверки) (см. 9.2.3.2 и 11.8.5).

Таблица 78 — Определение параметра УровеньПроверки (IL)

Параметр

УровеньПроверки (IL)

NO.CHECK {нет проверки}

TYPE.COMP (сравнение типа)

IDENTICAL

(идентичный}

ID Устройства (DID) (совместимый)

Да (RDlD=CDID)

Да (RDIDCDID)

ID Изготовителя (VID)

Да (RDlDsCDID)

Да (RDID=CDID)

ЗаводскойНомер (SN)

Да (RSN = CSN)

102

ГОСТ Р МЭК 61131-9—2017

В таблице 79 установлено кодирование различных целевых режимов. Таблица 79 — Определения целевых режимов

Цепеаон режим

Определение

CFGCOM

Устройство, осуществляющее связь в режиме CFGCOM после успешной проверки

AUTOCOM

Устройство, осуществляющее связь в режиме AUTOCOM без проверки

INACTIVE

Связь отключена, нет цифрового ввода DI. нет цифрового вывода DO

01

Порт а режиме цифрового ввода DI (SIO)

DO

Порт а режиме цифрового вывода DO (SIO)

CFGCOM — целевой режим, основанный на конфигурации пользователя (например, с помощью IODD) и проверках совместимости RID. VID. DID.

AUTOCOM — целевой режим без конфигурации. Это означает отсутствие проверок CVID и CDID. CRID устанавливается в наивысшую редакцию, поддерживаемую Ведущим узлом. AUTOCOM должен выбираться только вместе с уровнем проверки «NO_CHECK» (см. таблицу 78).

9.2.2.3 Услуга SM_GetPortConftg

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

Таблица 80 — Услуга SM_GetPortConfig

Имя пераметра

.req

.cn(

Argument

M

PortNumber

M

Result (+)

S<=)

ParameterList

M

Result (-)

S<=)

PortNumber

M

Errorinfo

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

PortNumber (НомерПорта)

Данный параметр содержит номер порта.

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что запрос услуги был выполнен успешно.

ParameterList (СписокПараметров)

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

Тип параметра: Запись.

Элементы записи:

PortNumber (НомерПорта)

Данный параметр содержит номер порта.

TargetMode (ЦелевойРежим)

Данный параметр указывает режим работы.

103

ГОСТ Р МЭК 61131-9—2017

Допустимые значения: INACTIVE. Dl. DO. CFGCOM, AUTOCOM (см. таблицу 79). RealBaudrate (ФактСкоростьБод)

Данный параметр указывает фактическую скорость передачи данных в бодах.

Допустимые значения:

СОМ1 (скорость передачи порта СОМ1);

COM2 (скорость передачи порта COM2):

COM3 (скорость передачи порта COM3).

RealCycleTIme (ФактВремяЦикла)

Данный параметр содержит фактическое (действительное) время цикла.

RealRevIsion (ФактРедакция) (RRID)

Длина данных: один октет для версии протокола (см. В.1.5).

RealVendoriD (ФактИдИэготовителя) (RVID)

Длина данных: два октета.

Примечание — Идентификатор изготовителя назначается консорциумом lO-Link.

RealDevicelD (ФактИдУстройства) (RDID)

Длина данных: три октета.

RealFunctionlD (ФактИдФункции) (RFID)

Длина данных: два октета.

RealSerialNumber (ФактЗаводскойНомер) (RSN)

Длина данных: до 16 октетов.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

PortNumber (НомерПорта)

Данный параметр содержит номер порта.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

PARAMETER_CONFLICT (нарушена корректность набора параметров).

Если информация недоступна, все параметры будут установлены в «0».

Э.2.2.4 Услуга SM_PortMode

Услуга SM_PortMode применяется для указания изменений или отказов режима локальной связи. Об этом будет сообщено приложению Ведущего узла. Параметры сервисных примитивов приведены в таблице 81.

Таблица 81—УслугаSM_PortMode

Имя параметра

.ind

Argument

M

PortNumber

M

Mode

М

104

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

ГОСТ Р МЭК 61131-9—2017

PortNumber (НомерПорта)

Данный параметр содержит номер порта.

Mode (Режим)

Допустимые значения:

INACTIVE (связь отключена, нет цифрового ввода, нет цифрового вывода);

DI [порт в режиме цифрового ввода (SIO));

DO [порт в режиме цифрового вывода (SIO)];

COMREADV (связь установлена, и проверка прошла успешно):

SM_OPERATE (порт готов к обмену PD);

COMLOST (сбой связи, требуется новая процедура пробуждения);

REVIS(ON_FAULT (несовместимая версия протокола);

COMP_FAULT (несовместимое или устаревшее Устройство для уровня проверки): SERNUM_FAULT (заводской номер не соответствует уровню проверки).

92.2.5 SM_Operate

Услуга SM_Operate заставляет SM вычислить времена цикла Ведущего узла, когда они положительно подтверждаются параметром Result (+). Данная услуга эффективна для всех портов. Параметры сервисных примитивов приведены в таблице 82.

Таблица 82 — SM_Operate

Имя параметра

.req

.cnf

Result <+)

s

Result {-)

s

Errorlnfo

M

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

TIMING_CONFLICT (требуемая комбинация времен цикла невозможна для активированных портов).

9.2.3 Протокол управления системой на Ведущем узле

9.2.3.1    Обзор

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

Для функциональных блоков выполняются методы проверки полной совместимости. Данные методы указываются полями «метода действия» на графах состояний, см., например, рисунок 70.

Соответствующая логика принятия решения демонстрируется посредством диаграмм деятельности (см. рисунки 71, 72. 73 и 76).

9.2.3.2    Конечная машина модуля управления системой на Ведущем узле

На рисунке 69 показана основная конечная машина SM на ведущем узле. Два функциональных блока для проверки совместимости и заводского номера определены в 9.2.3.3 и 9.2.3.4. В случае нарушения связи SM информируется через услугу DL_Mode (COMLOST). Изменение конфигурации порта можно осуществить только через услугу SM_SetPortConfig. Услуга SM_Operate (доступная на всех портах) не действует ни в каких состояниях, кроме состояния «wait_4».

105

ГОСТ Р МЭК 61131-9—2017

Рисунок 69 — Структура и услуги SM на Ведущем узле

В таблице 83 показаны таблицы перехода состояний обработчика SM на Ведущем узле.

Таблица 83 — Таблицы перехода состояний SM на Ведущем узле

Имя состояния

Описание состояния

Portlnactive_0

Нет связи

СЬескСотра6ЬШ1у_1

Порт запускается, и проверяются версия и совместимость Устройства. См. рисунок 70

waitonDLPreoperale_2

Ожидается установка состояния PREOPERATE, и запускаются все обработчики OD. Порт готов к связи

106

ГОСТ Р МЭК 61131-9—2017

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

Имя состояния

Описание состояния

CheckSerNum_3

Заводской номер проверяется в зависимости от уровня проверки (IL). См. рисунок 75

wait_4

Порт готов к связи и оживает услугу SM_Operate из СМ

SM Operate.5

Порт находится в состоянии OPERATE и выполняет обмен циклическими РО

lnspecbonFault_6

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

waitonDLOperate_7

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

DlDO_8

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

JotnPseodoSlate_9

Данное псевдооостояние применяется вместо панели соединения универсального языка программирования UML. Оно разрешает вьполнекие индивидуальных услуг SM SetPortConfig в зависимости от состояния системы (INACTIVE. CFGCOM. AUTOCOM. DI или DO)

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

CompRetry = 0

T2

1

2

DL.SetMode.req {PREOPERATE. ValueList)

T3

1. 2. 3. 4, 5. 6.7

0

DL.SetMode.req (INACTIVE) и SM.Mode.ind (COMLOST) из-за отказа связи

T4

1

7

DL.SetMode.req (OPERATE. ValueList)

T5

1

6

SM.PortMode.ind (COMP_ FAULT). DL.SetMode.req (OPERATE. VfelueList)

T6

1

6

SM.PortMode.ind (REVISION,FAULT). DL.SetMode.req (PREOPERATE. ValueList)

T7

1

6

SM Port Mode, ind (COMP FAULT). DL SetMode.req (PREOPERATE. ValueList)

T8

2

3

T9

7

3

T10

3

4

SM.PortMode.ind (COMREADY)

T11

3

6

SM.PortMode.ind (SERNUM.FAULT)

T12

4

5

DL.SetMode.req (OPERATE. ValueList)

T13

5

5

T14

0. 4. 5.6. 8

0

SM.PortMode.ind (INACTIVE). DL.SetMode.req (INACTIVE)

T15

0. 4. 5.6. 8

0

OL.SetMode.req (STARTUP. ValueList). PL.SetMode.req (SDCI)

T16

0. 4. 5.6. 8

8

PL SetMode.req (SIO). SM Mode.ind (DI или OO). DL SetMode.req (INACTIVE)

Внутренние элемент»

Тип

Определение

CompOK

Bool

См. рисунок 73

CompFault

Bool

См. рисунок 73. переменная ошибки COMP.FAULT

RevisionFautl

Bool

См. рисунок 71. переменная ошибки REVISION.FAULT

SerNumFault

Bool

См. рисунок 76. переменная ошибки SERNUM.FAULT

107

ГОСТ Р МЭК 61131-9—2017

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

Внутренние элементы

Тип

Определение

SerNumOK

Bool

См. рисунок 76

VIOCompFault

Bool

См. рисунок 72. переменная ошибки COMP_FAULT

VIOCompOK

Bool

См. рисунок 72

INACTIVE

Перемен

ная

Целевой режим в услуге S M_SetPortGonf*g

CFGCOM. AUTOCOM

Перемен

ные

Целевые режимы в услуге SM_SetPortConfig

9.2.3.3 Функциональный блок checkCompatibility_1 модуля управления системой на Ведущем узле На рисунке 70 показан функциональный блок checkCompatibi1ity_1 на Ведущем узле.

«г*»_г    *п*х_Э    впох_5 вп**_6

Рисунок 70 — Функциональный блок CheckCompatibility_1 на Ведущем узле

В таблице 84 показаны таблицы перехода состояний функционального блока cbeckCompatibility_1 на Ведущем узле.

Таблица 84 — Таблицы перехода состояний функционального блока checkCompatibi1ity_1 на Ведущем узле

Имя состояния

Описание состояния

ReadComParameter_20

Получает параметры связи из страницы 1 Непосредственных параметров (от 0x02 до 0x06) через услугу DL_Read (см. таблицу В.1}

CheckCompV10_21

Получает параметры идентификации из страницы 1 Непосредственных параметров (от 0x07 до 0x0D) через услугу DL_Read (см. таблицу В.1}. Сконфигурированный уровень проверки (IL) определяет логику принятия решения последующей проверки совместимости «CheckCompVIO» с параметрами RV1D. ROID и RFID а соответствии с рисунком 72

108

ГОСТ Р МЭК 61131*9—2017

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

Имя состояния

Описеиие состояния

CheckVxy_22

Проверка устанавливает, соответствует ли сконфигурированная версия (CRID) реальной (фактической) версии (RR1D) в соответствии с рисунком 71

CheckComp_23

Получает параметры идентификации из страницы 1 Непосредственных параметров (от 0x07 до 0x00} через услугу DL_Read (см. таблицу В.1). Сконфигурированный уровень проверки (IL) определяет логику принятия решения последующей проверки совместимости CheckComp в соответствии с рисунком 73

Restart Device_24

Записывает параметры совместимости сконфигурированной версии протокола (CRID) и сконфигурированного идентификатора Устройства DevicelD (СОЮ) в Устройство в зависимости от целевого режима связи CFGCOM или AUTOCOM (см. таблицу 79) в соответствии с рисунком 74

J«nPseu(JoState_25

Данное псевдооостояние применяется вместо панели соединения универсального языка программирования UML Средства защиты не применяются

Переход

Исходное

состояние

Конечное

состояние

Действие

T20

20

21

T21

20

22

OL.Write (0x00. MCmd.MASTERIDENT). см. таблицу B.2

T22

22

23

T23

23

24

T24

24

20

T25

22

24

CompRetry = CompRetry +1

Внутренние элементы

Тил

Определение

CompOK

Bool

См. рисунок 73

Comp Fault

Bool

См. рисунок 73. переменная ошибки COMP_FAULT

RevisionFauit

Bool

См. рисунок 71. переменная ошибки REVlSION_FAULT

RevisionOK

Bool

См. рисунок 71

SerNumFault

Bool

См. рисунок 76. переменная ошибки SERNUM_FAULT

SerNumOK

Bool

См. рисунок 76

V10

Bool

Фактическая версия протокола подключенного Устройства — устаревшая версия (V1.0. см. В.1.5)

<>V10

Bool

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

VIOCompFautt

Bool

См. рисунок 72. переменная ошибки COMP_FAIAT

VIOCompOK

Bool

См. рисунок 72

RetrySlartup

Bool

См. рисунок 71 и рисунок 73

CompRetry

Перемен

ная

Внутренний счетчик

WrileDone

Bool

Полное завершение последовательности услуг повторного запуска

M C m d.XXXXXXX

Call

См. таблицу 43

Некоторые состояния содержат сложную логику для проверок совместимости и допустимости. Это демонстрируется на рисунках 71—74.

На рисунке 71 показана логика принятия решения для проверки версии протокола в состоянии CheckVxy. В случае сконфигурированных Устройств применяются следующие правила: если сконфигу* рироеанная версия (CRID) и фактическая версия (RRID) не совпадают, на Устройство будет передана версия CRIO. Если устройство не соглашается, то Ведущий узел возвращает индикацию через услугу SM_Mode с параметром REV_FAULT.

109

ГОСТ Р МЭК 61131-9—2017

В случае несхонфигурироеанных Устройств будет применяться режим AUTOCOM. Аббревиатуры имен параметров описываются в 9 2.2.2 и 9.2.2.3.

<D>> lRWD,CW|DI rfRMdoaCJKffaa» )

<z>

(RRfO О CRIO}

ICempRetry • 01

^ RotryStamip (Г2&) J

[CompRetry = 1]

ReviSQnfauH (T6) J

Рисунок 71 — Действия для состояния CheckVxy

На рисунке 72 показана логика принятия решения для проверки совместимости устаревшего Устройства в состоянии CheckVIO.

OfoxMHM К —    ntoetpM

(IL мО.СНЕСк)

»(У10Сот»вОК(Т«) )

JIL TY»e_COWPerHXNTlCAl|

(CVIO ■ RMO M COIO * НИ Cl

»(у1осо»>рокп‘*1 ]

lev® о йую of сою о яаа

>( viocwnpNmiTa))

Рисунок 72 — Действия для состояния CheckVIO

Ha рисунке 73 показана логика принятия решения для проверки совместимости в состоянии CheckComp.

Ж NCLCHCC*!

-»( СогоуОК гггГ j Запучж УогсоОопоа

(К TVPE.COMP or «6WTICAU

ICVlOoRViO)

ДОЮ • RVIO)

(Соврймгу <0<М COO«•-ЯОЮ|

>{C»»pT»ufl |Т7> j Н#ссп»«спп<«вг» -» Ошибки

Пера»*г>)*х имцройстоя

>    S    fV'V

Ы ft*KyS>»riup <Т}3) 1 епарлмчтраыо '    * ЯУО яоо

OfolMIMWMA

И.—Урсм«ъ промро*

{СолцЛМЧР ■ 1 *td СО*Оо ВС*И

_fr( Сддоиищтт» ) Несовместимо.» -» Ошибка

Рисунок 73 — Действия для состояния CheckComp

110

ГОСТ Р МЭК 61131-9—2017

На рисунке 74 показаны действия (запись параметра) е состоянии RestartDevice.

9.2.3.4 Функциональный блок проверки заводского номера «Check serial number» модуля управления системой на Ведущем узле

На рисунке 75 показан функциональный блок checkSerNum_3 SM на Ведущем узле. Данная проверка является обязательной.

В таблице 65 показаны таблицы перехода состояний функционального блока CheckSerNum_3 на Ведущем узле.

111

ГОСТ Р МЭК 61131-9—2017

Таблица 85 — Таблицы перехода состояний функционального блока CheckSerNum_3 на Ведущем узле

Имя состояния

Описание состояния

ReadSerNum_30

Получает заводской номер из Устройства через вызов услуги AL_Read.req (Index:0x0015). Положительный ответ (AL_Read(+)> приводит к SReadOK = true. Отрицательный ответ (AL_Read(+)) приводит к SRead = true

CheckSerNum_31

Сконфигурированный (CSN) и фактический (RSN) заводские номера проверяются в зависимости от уровня проводки (1L) в соответствии с рисунком 76

Переход

Исходим

состояние

Конечное

состояние

Действие

ТЗО

40

41

Т31

40

41

Внутренние моменты

Тип

Определение

SRead-

Boot

Отрицательный результат вызова услуги AL_Read (Index 0x0015}

SReadOK

Bool

Заводской номер считан правильно

SERNumOK

Bool

См. рисунок 76

SERNumFault

Bool

См. рисунок 76

На рисунке 76 показана логика принятий решения (действия) для состояния CheckSerNum_3.

Рисунок 76 — Действия (проверка заводского номера) для состояния CheckSerNum_3

9.2.3.5 Правила использования типов М-последовательностей

SM отвечает за установку правильных типов М-последовательностей. Это происходит после действий по проверке совместимости (переход в состояние PREOPERATE) и перед переходом е состояние OPERATE.

В разных рабочих состояниях будут применяться различные типы М-последовательностей (см.А.2.6). Например, при переключении в состояние OPERATE будет применяться тип M-последовательности, соответствующий циклической операции. Тип М-последовательности. который будет применяться в рабочем состоянии OPERATE, определяется размером входных и выходных

112

ГОСТ Р МЭК 61131-9—2017

PD. Доступные типы M-последовательностей в трех режимах STARTUP. PREOPERATE и OPERATE и соответствующее кодирование параметра M-sequence Capability устанавливаются в А.2.6. Форматы входных и выходных данных будут получаться из подключенного Устройства, чтобы подстраиваться к типу M-последовательности. Ведущий узел должен обязательно реализовывать все определенные типы M-последовательностей, установленные в А.2.6.

9.3 Модуль управления системой на Устройстве

9.3.1 Обзор

На рисунке 77 представлен обзор структуры и услуг SM на Устройстве.

Припсиамм Устройство

«Ьпичастчй )роим

Рисунок 77 — Структура и услуги SM на Устройстве

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

SM на Устройстве взаимодействует с PL для установки требуемых регулировок драйвера линии и приемника (см. рисунок 15). с DL для получения необходимой информации из Ведущего узла (пробуждение, скорости передачи и др.) и с приложениями Устройства для обеспечения идентичности Устройства и совместимости (параметров идентификации).

Переходы между состояниями обработчика (см. рисунок 79) инициируются действиями порта Ведущего узла (пробуждение и связь) и передаются через DL Устройства, применяя индикацию DL_Mode и запросы (команды) услуги DL_Write.

SM обеспечивает параметры идентификации Устройства через интерфейс приложений Устройства.

113

ГОСТ Р МЭК 61131-9—2017

В диаграмме последовательностей на рисунке 78 показана типовая последовательность от инициализации режима SIO по умолчанию и через запрос пробуждения до окончания передачи данных. Диаграмма последовательностей дополнена сценарием обработки ошибки связи, такой как истечение промежутка времени TDSIO, сбой связи или запрос от Ведущего узла, например, возврат в исходное состояние Fallback (вызванный Событием).

>W<*»

мсдо

now*

М

' (**•«*»

m

yq»«iem

pi_s*mm*:ikactive)

iMnno

PL.veieop.in»)

Dl_Med>|E3TA8COMl ^

Pl.SctMoeefCOMxi

(X_M«de{INACTME)

PU_S«Moa«(IHKCTlVt}

Pi 8мМо4Ж01 I 001 INACTIVE)

Pwa 8Ю mtw 4

T

SM_&atO«v<oMod«(lDtE| I

SM_ Dtv'ceMoee^iDlE i

SM_S«pB»iceCom(lB№al panmiMtrt

SM_Dwi«*too«(SlOl

AmuuSOwmMk

SM.OivicaModKESTABCOM)

• 0Си*а

SM_o«viceMo«»iiOLE)

SM.SfiOtvaCQMQnili» p»nwo>t)

S*LSHD»wC»4»*VHia- HHWW'i

SM_S*l0*4i«*Uoe«S^0l

ЗМ.ОеИоеМове^Ю)

9Ш&ПФШЫ

(OtMlOVUMiM

Рисунок 7в —Диаграмма последовательностей сценария использования «INACTIVE — SIO — SDCI — SIO*

Службы SM, показанные на рисунке 78. установлены в 9.3.2.

9.3.2 Услуги модуля управления системой на Устройстве 9.3.2.1 Обзор

В 9.3.2 описаны службы, которые SM на Устройстве предоставляет приложениям Устройства, как показано на рисунке 77.

В таблице 86 приведены средства Устройства в его роли инициатора или получателя для отдельных услуг SM.

114

ГОСТ Р МЭК 61131-9—2017

Таблица 86 — УслугиSMна Устройстве

Имя услуги

Устройство

SM.SetDeviceCom

R

SM.GetDeviceCom

R

SM.SetDeviceldent

R

SM.GetDeviceldent

R

SM.SetDeviceMode

R

SM_DeviceMode

1

Обозначения (см. 3.3.4):

I — Инициатор услуги:

R — Приемник (Ответчик) услуги.

9.3.2.2 Услуга SM_SetDeviceCom

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

Таблица 87 — Услуга SM.SetDeviceCom

Имя параметра

.req

.cnf

Argument

M

ParameterList

M

Result (+)

s

Result (-)

s

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

ParameterList (СписокПараметров)

Данный параметр содержит сконфигурированные параметры связи для Устройства.

Тип параметра: Запись.

Элементы записи:

SupportedSIOMode (ПоддерживаемыйРежимвЮ)

Данный параметр указывает, что режим SIO поддерживается Устройством.

Допустимые значения:

INACTIVE (высокий импеданс линии C/Q);

DI (линия C/Q находится е режиме цифрового ввода);

DO (линия C/Q находится в режиме цифрового вывода).

SupportedTranemissionrate (ПоддержиеаемаяСкоростьПередачи)

Данный параметр указывает скорости передачи данных, поддерживаемые Устройством.

Допустимые значения:

СОМ1 (скорость передачи порта СОМ1);

COM2 (скорость передачи порта COM2);

COM3 (скорость передачи порта COM3).

115

ГОСТ Р МЭК 61131-9—2017

MinCycleTime (МинВремяЦикла)

Данный параметр содержит минимальное время цикла, поддерживаемое Устройством (см. В.1.3).

M-sequenceCapability (СвойстваМ-Лоеледовательностей)

Данный параметр указывает свойства М-последовательностей, поддерживаемые Устройством (см. В.1.4):

- поддержка ISDU;

•    типы М-последовательностей в состоянии OPERATE;

•    типы М-последовательностей в состоянии PREOPERATE.

Revi8ionlD (ИдРедакции) (RID)

Данный параметр поддерживает редакцию протокола (см. В.1.5). поддерживаемую Устройством.

ProcessDataln (ВхДанкыеПроцесса)

Данный параметр содержит длину PD. подлежащих передаче в Ведущий узел (см. В.1.6). ProcessDalaOut (ВыхДанныеПроцесса)

Данный параметр содержит длину PD. подлежащих передаче из Ведущего узла (см. В.1.7). Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неуспешно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

PARAMETER_CONFLICT (нарушена корректность набора параметров).

9.3.2.3 Услуга SM_GetDeviceCom

Услуга SM_GetDeviceCom применяется для чтения текущих характеристик связи из SM. Параметры сервисных примитивов приведены в таблице 88.

Таблица 88 — Услуга SM_SetDeviceCom

Имя параметра

.req

.cnf

Argument

M

Result {+)

s

ParameterList

M

Result (-)

s

Errorlnfo

M

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

ParameterList (СписокПараметров)

Данный параметр содержит сконфигурированные параметры связи для Устройства. Тип параметра: Запись.

116

ГОСТ Р МЭК 61131-9—2017

Элементы записи:

CurrentMode (ТекущийРежим)

Данный параметр указывает режим SIO или режим связи Устройства.

Допустимые значения:

INACTIVE (линия СЮ имеет высокий импеданс);

DI (линия СЮ находится в режиме цифрового ввода);

DO (линия СЮ находится в режиме цифрового вывода);

СОМ1 (скорость передачи порта СОМ1);

COM2 (скорость передачи порта COM2);

COM3 (скорость передачи порта COM3).

MasterCycleTime (ВремяциклаВедущегоузла)

Данный параметр содержит время цикла Ведущего узла, которое будет установлено SM Ведущего узла (см. В. 1.3). Данный параметр действует только в состоянии SM_Operate.

M-sequenceCapabllity (Свойствам-Последовательности)

Данный параметр указывает на текущие свойства, сконфигурированные в модуле управления системой на Устройстве (см. В.1.4):

•    поддержка ISDU;

•    типы М-последовательностей в состоянии OPERATE;

•    типы М-последовательностей в состоянии PREOPERATE.

RevislonlD (ИдРедакции) (RID)

Данный параметр содержит текущую редакцию протокола (см. В.1.5) в модуле управления системой на Устройстве.

ProcessDataln (ВхДанныеПроцесса)

Данный параметр содержит длину PD. подлежащих передаче в Ведущий узел (см. В.1.6). ProcessDataOut (ВыхДанныеПроцесса)

Данный параметр содержит длину PD. подлежащих передаче из Ведущего узла (см. В.1.7). Result (-) (ОтрицательныйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Errorlnfo (ИнформацияОбОшибхе)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

STATE_CONFLICT (в текущем состоянии услуга недоступна).

9.3.2.4 Услуга SM_SetDeviceldent

Услуга SM_SetDeviceldent применяется для конфигурирования данных идентификации Устройства в модуле управления системой. Параметры сервисных примитивов приведены в таблице 89.

Таблице 89 — УслугаSM.SetDeviceldent

Имя параметра

.req

.cnf

Argument

M

ParameterUst

M

Result (+)

s

Result (-)

s

Errorlnfo

M

117

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

ParameterList (СписокПараметров)

Данный параметр содержит сконфигурированные параметры связи для Устройства.

Тип параметра: Запись.

Элементы записи:

VendorlD (ИдИзготовителя) (VID)

Данный параметр содержит идентификатор изготовителя VendorlD. назначенный Устройству (см. В.1.8).

Длина данных: два октета.

DevicelD (ИдУстройства) (DID)

Данный параметр содержит один из назначенных идентификаторов Устройства. DevicelD (см. В.1.9).

Длина данных: три октета.

FunctionID (ИдФункции) (FID)

Данный параметр содержит один из назначенных идентификаторов функции FunctionID (см. В.1.10).

Длина данных: два октета.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Result (-) (ОтрицателькыйРезультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

STATE_CONFLICT (в текущем состоянии услуга недоступна);

PARAMETER_CONFLICT (нарушена корректность набора параметров).

9.3.2.5 Услуга SM_GetDev>celdent

Услуга SM_GetDeviceldent применяется для чтения параметра идентификации Устройства из SM. Параметры сервисных примитивов приведены в таблице 90.

Таблица 90 — Услуга SM_GetDeviceldent

Имя параметра

,req

.cn(

Argument

M

Result (+)

S

RaramelerList

M

Result {-)

s

Errorlnfo

M

116

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Result (+) (ПоложительныйРеэультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

ParameterList (СписокПараметров)

Данный параметр содержит сконфигурированные параметры связи для Устройства.

Тип параметра: Запись.

Элементы записи:

VendorlD (ИдИзготовителя) (VID)

Данный параметр содержит фактический идентификатор изготовителя VendorlD. назначенный Устройству (см. В.1.8).

Длина данных: два октета.

DevicelD (ИдУстройства) (DID)

Данный параметр содержит фактический идентификатор Устройства DevicelD (см. 8.1.9).

Длина данных: три октета.

FunctionID (ИдФункции) (FID)

Данный параметр содержит фактический идентификатор функции FunctionID (см. 8.1.10). Длина данных: два октета.

Result (-) (Отрицательный Результат)

Данный параметр выбора указывает, что слуга завершилась неуспешно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

STATE_CONFLICT (в текущем состоянии услуга недоступна).

9.3.2.6 Услуга SM_SetDeviceMode

Услуга SM_SetDev»ceMode применяется для установки Устройства в определенное рабочее состояние при инициализации. Параметры сервисных примитивов приведены в таблице 91.

Таблица 91—Услуга SM.SetDeviceMode

Имя параметра

.req

.cnf

Argument

M

Mode

M

Result (+)

s

Result (-)

s

Errorlnfo

M

119

ГОСТ Р МЭК 61131-9—2017

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Mode (Режим)

Допустимые значения:

IDLE (устройство переходит в состояние ожидания конфигурирования):

SIO (устройство переходит в режим, определенный в услуге SM_SetDeviceCom).

Result (+) (ПоложительныйРезультат)

Данный параметр выбора указывает, что услуга выполнена успешно.

Result (-) (ОтрицательныйРеэультат)

Данный параметр выбора указывает, что услуга завершилась неудачно.

Errorlnfo (ИнформацияОбОшибке)

Данный параметр содержит информацию об ошибке.

Допустимые значения:

STATE_CONFLICT (в текущем состоянии услуга недоступна).

9.3.2.7 Услуга SM_DeviceMode

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

Таблице 92 — УслугаSM_DeviceMode

Имя параметра

.ind

Argument

М

Mode

М

Argument (Аргумент)

Определяемые услугой параметры передаются в данном параметре.

Mode (Режим)

Допустимые значения:

IDLE (устройство перешло в состояние ожидания конфигурирования);

SIO (устройство перешло в режим, определенный в услуге «SM_SetDeviceCom»);

ESTABCOM (устройство перешло в режим управления системой «SM_ComEstablish»);

СОМ1 (устройство перешло в режим СОМ1);

COM2 (устройство перешло в режим COM2);

COM3 (устройство перешло е режим COM3);

STARTUP (устройство перешло в режим STARTUP);

IDENT.STARTUP (устройство перешло в режим управления системой «SMJdentStartup»): IDENT_CHANGE (устройство перешло в режим управления системой «SMJdentCheck»); PREOPERATE (устройство перешло в режим PREOPERATE);

OPERATE (устройство перешло в режим OPERATE).

9.3.3 Протокол модуля управления системой на Устройстве

9.3.3.1    Обзор

Поведение Устройства в основном управляется сообщениями Ведущего узла.

9.3.3.2    Конечная машина модуля управления системой на Устройстве

На рисунке 79 показана конечная машина SM на Устройстве. Конечная машина запускается обработчиком канального режима и приложением Устройства. Конечная машина анализирует различные стадии связи во время запуска и управляет состоянием линии связи Устройства.

120

ГОСТ Р МЭК 61131-9—2017

Рисунок 79 — Конечная машина SM на Устройстве В таблице 93 установлены отдельные состояния и действия во время переходов. Таблица 93 — Таблицы перехода состояний SM на Устройстве

Имя состояния

Описание состояния

SMJdle.O

В состоянии SMJdle SM смсидает конфигурирования приложением Устройства и установки в режим SIO. Выход из данного состояния происходит при получении запроса SM_SetOeviceMode(SlO) из приложения Устройства.

Между припаже»мем Устройства и SM выполняется следующая последовательность услуг: вызов услуги SM_SelDeviceCom {список начальных параметров); вызов услуги SM_SetDeviceldent {VID. начальные DID. FID)

121

ГОСТ Р МЭК 61131-9—2017

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

Имя состояния

Описание состояния

SM_SlO_1

В состоянии SM_SIO обработчик линии связи управления системой остается в режиме по умолчанию SIO. PL устанавливается с характеристиками режима SIO, определенными приложением Устройства через услугу SetOeviceMode. Выход из данного состояния происходит при получении индикации DL_Mode(ESTABCOM)

SM_ComEstab»«sh_2

В состоянии SM_ComEstablish SM ожидает установления связи на DL. Выход из данного состояния происходит при получении индикации DL_Mode(INACTIVE) или DL Mode(COMx). где СОМх может быть любым из портов СОМ1. COM2 или COM3

SM_Com Start up_3

В состоянии SM_ComStartup параметр связи {страница 1 Непосредственных параметров. адреса от 0x02 по 0x06) считывается SM на Ведущем узле через запросы OL_Read. Выход из данного состояния происходит при получении одной из индикаций DL Mode(INACTIVE). DL Mode(OPERATE) (только для устаревшего Ведущего узла) или DL_Write(MCmd_MASTERIDENT)

SM_ldentStartup_4

В состоянии SMJdentStartup данные идентификации (V1D. DID. FID) считываются и проверяются Ведущим узлом. В случае несовместимостей SM на Ведущем узле записывает поддерживаемую редакцию SOCI (RID) и сконфигурированный идентификатор Устройства (DID) в Устройство. Выход из данного состояния происходит при получении индикаций DL_Mode(INACTIVE). DL_Mode(PREOPERATE) {проверка совместимости прошла успешно) или запроса DL_Wrile(MCmd_DEVICEIDENT) (запрос новой совместимости)

SM_ldentCheck_5

В состоянии SM_identCheck SM ожидает новой инициализации параметров связи или идентификации. Выход из данного состояния происходит при получении идентификации DL_Mode(INACTIVE) или запроса DL_Read {страница 1 Непосредственных параметров, адрес 0x02 = MinCydeTime).

В данном состоянии приложение Устройства будет проверять параметры RID и DID из SM и устанавливать эти данные в поддерживаемые значения.

Эго означает, что между приложением Устройства и SM выполняется следующая последовательность услуг:

вызов услуги SM_6etDeviceCom (сконфигурированный RID. список параметров); вызов услуги SM_GetDeviceldent (сконфигурированный DID. список параметров); вызов проверок из приложения Устройства и обеспечение совместимости функции и параметров:

вызов услуги SM_SetDeviceCom (новый поддерживаемый RID. новый список параметров);

вызов услуги SM.SetDeviceldent (новый поддерживаемый DID, список параметров)

SM_CompStartup_6

В состоянии SM_CompatStartup данные связи и идентификации считываются повторно и подтверждаются SM на Ведущем узле. Выход из данного состояния происходит при получении индикации DL Mode(iNACTIVE) или DL_Mode{ PREOPERATE)

SM_Preoperate_7

Во время пребывания в состоянии SM_Preoperate SM может считываться и проверяться заводской номер SerialNumber. а также может производиться параметризация DS и Устройства. Выход из данного состояния происходит при получении одного из сообщений DL Mode(INACTIVE). DL Mode(STARTUP) или DL.Mode(OPERATE)

SM_Operate_8

Во время пребывания в состоянии SM.Operale активны обмен циклическими PD и передача ациклических OD. Выход из данного состояния происходит при получении индикаций DL.Mode(INACTIVE) или DL_Mode(STARTUP)

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Устройство переключается в сконфигурированный режим SIO еди получении пускового сигнала SM SetDeviceMode.req(SIO).

Вызов услуги PL_SetMode(DI|DO|INACTIVE).

Вызов услуги SM_DeviceMode(SIO)

122

ГОСТ Р МЭК 61131-9—2017

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

Переход

Исходное

состояние

Конечное

состояние

Действие

Т2

1

2

Устройство переключается в режим связи при получении пускового сигнала Dt_Mode.md(ESTABCOM).

Вызов услуги PL_SelMode(COMx).

Вызов услуги SM_DeviceMode(ESTABCOM)

ТЗ

2, 3.4. 5. 6. 7.8

0

Устройство переключается в режим SM_ldle при получении пускового сигнала DL Mode.ind(lNACTtVE).

Вызов услуги PL_SetMode(INACTIVE).

Вызов услуги SM_DeviceMode(IOLE)

Т4

2

3

Приложение Устройства получает индикацию о скорости передачи 8 бодах. которая была установлена услугой DL_Mode.ind(COMx), запущенной на DL.

Вызов услуги SM_DeviceMode(COMx)

Т5

3

4

Происходит вход в фазу идентификации Устройства при получении пускового сигнала DL_Write.ind(MCmd_MASTERIDENT).

Вызов услуги SM_DeviceMode(1DENTSTARTUP)

те

4

5

Происходит вход в фазу проверки идентичности Устройства при получении пускового сигнала DL_Wnte.ind{MCmd_DEVlCEIDENT).

Вызов услуги SM_DeviceMode(tDENTCHANGE)

Т7

5

6

Вход в фазу проверки совместимости Устройства при получении пускового сигнала OL_Read.ind (страница 1 Непосредственных параметров, адрес 0x02 = MinCycleTtme)

Т8

6

7

Происходит вход в фазу предварительных операций Устройства при получении пускового сигнала DL_Mode.ind(PREOPERATE).

Вызов услуги SM_DeviceMode(PREOPERATE)

T9

7

8

Происходит вход в фазу операций Устройства при получении пускового сигнала DL_Mode.ind(OPERATE).

Вызов услуга SM_DeviceMode(OPERATE)

Т10

4

7

Происходит вход в фазу предварительных операций Устройства при получении пускового сигнала DL_Mode.ind(PREOPERATE).

Вызов услуга SM_DeviceMode(PREOPERATE)

Т11

3

8

Происходит вход в фазу операций Устройства при получении пускового сигнала DL_Mode.ind(OPERATE).

Вызов услуга SM_DeviceMode(OPERATE)

Т12

7

3

Происходит переход в фазу запуска связи Устройства при получении пускового сигнала DL_Mode.»nd(STARTUP).

Вызов услуга SM_DeviceMode(STARTUP)

Т13

8

3

Происходит переход е фазу запуска связи Устройства при получении пускового сигнала OL_Mode.ind(STARTUP).

Вызов услуга SM_DeviceMode(STARTUP)

Внутренние элемент»

Тип

Определение

СОМх

Перемен

ная

Скорость передачи любого из портов СОМ1. COM2 или COM3

DL_Write_MCmd_xxx

Услуга

Услуга DL записывает команды Ведущего узла {ххх = значения из таблицы В.2)

123

ГОСТ Р МЭК 61131-9—2017

На рисунке 80 показана типовая диаграмма последовательностей при запуске связи SM для установки соответствия конфигурации порта на Ведущем узле (нормальный запуск).

I

i

i

J.

Рисунок 60 — Диаграмма последовательностей нормального запуска Устройства

На рисунке 81 показана типовая диаграмма последовательностей при запуске связи SM для установки соответствия конфигурации порта на Ведущем узле (режим совместимости). В этом режиме Ведущий узел пытается перезаписать параметры идентификации Устройства для достижения совместимого и работоспособного режима.

Диаграмма последовательностей на рисунке 81 показывает только действия, предшествующие переходу в состояние PREOPERATE. Последующие действия до перехода в состояние OPERATE показаны на рисунке 80.

124

ГОСТ Р МЭК 61131-9—2017

•Опт*

№*»<Ь

мая*

yV8W

Шк

пмм*ь

ХМ

хлыст

т

I

I

I

I

X

Рисунок 81 — Диаграмма последовательностей запуска Устройства в режиме совместимости

На рисунке 82 показана типовая диаграмма последовательностей при запуске связи SM для установки соответствия конфигурации порта на Ведущем узле. SM на Ведущем узле пытается пере* конфигурировать Устройства с альтернативными параметрами идентификации Устройства (режим совместимости). В данном сценарии использования считается, что альтернативные параметры являются несовместимыми.

125

ГОСТ Р МЭК 61131-9—2017

ГИ'ШЪ

—Г~

><Ц|»КМ ш» ^вдиШ«ССЯР

(С«ИИ«ММММ

Фчгампя

гтг»»<— 00 м»* АО |щим<»ммиа

fli»ni и 8wnw fw • 3UWkU4(M «ей *• мпы

S

йиикттш Г>И—ЯС мо oo.no в«н»пм цицц

00 а*' Wowoni

»Ц»Я

I Моду».

I yvmrm-

C4CIWM

DL McOWCOM»)

OL Road(D«MP«wnoterMge ’)

(UinCychTime. иЬпСзраЬМу. «©. длине POin, длине PDout)

(X _W*ne<0»00 MOM MASIERICtNT^

DL Re*d(0tcea Pwamter page 1)

(VC.OO.FO)

(X WiMOxM. СЯ0)

Ol_W»WO*M ОЮВ СОЮ)

OL.VMteiOMdO. MCmd KVittlDCNT)

DK_RMdiOiieci Paomeier pega 1>

(UmCydeTme. M$ogCapaoM^. RIO. <V>ixa PDn длине POoul)

Ql.Wte<0»00 HCma.MASTEWOeNTj

Dt^ReoOtDiect Parameter page 1}

(VD.OD.rO

<ЧМ>М6-

Wi

iWM»

8M.Dav<o»Uoja(COM«)

S«_Oe>»ceM«de{IOeMT8T ART UP)

SM .Oe-rtceUodaiiOCNTCHANGE)

.SM_G«DeH«*ComKun*ni pareiMW)

Ski GatOexMloenUctmnt pan#naie<)

--SM_S»Ov<o>Co«"(4ppO'**K3 peraimeiert

^W.SelOaMicNdMtQippMtod DIO. PIP)

SU_Oewe»Moe»ffOCNTS1AHTUP)

•«ИШЧММПОО

Рисунок 82 — Диаграмма последовательностей запуска Устройства, когда не удается достичь совместимости

10 Устройство

10.1 Обзор

На рисунке 83 предоставлен обзор полной структуры и услуг Устройства.

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

-    РМ. имеющий дело с проверкой совместимости и правильности полного набора специальных технических (зависящих от изготовителя) и общих системных параметров (см. 10.3):

• 0S. который по запросу отправляет или скачивает параметры на ведущий узел (см. 10.4):

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

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

126

ГОСТ Р МЭК 61131-9—2017

Прилммм Уоройгтм

Рисунок 83 — Структура и услуги устройства

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

10.2 Обмен Данными процесса (РОЕ)

Устройство РОЕ циклически передает и получает PD без вмешательства OD (параметров, команд и Событий}.

Исполнительный механизм (выходные PD) наблюдает за циклическими передачами и переходит в подходящие состояния по умолчанию, например, сохраняет последнее значение, осуществляет остановку и отключение питания при любых прерываниях передачи данных (см. 7.3.3.5 и 10.7.3). Исполнительный механизм ожидает команды обработки выходных РО ProcessDataOutputOperate Ведущего узла (см. таблицу В.2. «допустимые» выходные РО) до возобновления нормального функционирования после рестарта в случае прерывания.

127

ГОСТ Р МЭК 61131-9—2017

Во время циклического обмена данными исполнительный механизм {выходные PD) получает команду Ведущего узла DeviceOperate (ОбработатьУстройство) всякий раз, когда выходные PD становятся недопустимыми, и команду обработки выходных PD ProcessOataOutputOperate Ведущего узла всякий раз. когда они снова становятся допустимыми (см. таблицу В.2).

Устройствам датчика (входным PD) нет необходимости отслеживать циклический обмен данными. Тем не менее, если Устройство не в состоянии гарантировать допустимые PD. состояние PL Process-Datainvalid (Недопустимые PD. см. А.1.5) будет уведомлять приложение Ведущего узла.

10.3 Менеджер параметров (РМ)

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

Устройство может быть параметризовано двумя основными методами: применяя Непосредственные параметры или применяя пространство памяти Индекса, доступное с помощью ISDU (см. рисунок 5).

Обязательными для всех Устройств являются так называемые Непосредственные параметры на странице 1. Данная страница содержит общие параметры связи и идентификации (см. В.1).

Страница 2 Непосредственных параметров дополнительно предлагает пространство для максимального числа в 16 октетов специальных технических (определяемых изготовителем) параметров для Устройств, требующих не более этого ограниченного числа параметров. Данная возможность применима для небольших систем, характеризующихся следующими свойствами: связь ISDU не реализована, возможна более легкая обработка полевой шины, но с меньшими удобствами. Доступ к странице 2 Непосредственных параметров осуществляется через услуги AL_Read и AL_Write (см. 10.7.5).

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

10.3.2    Конечная машина РМ

Устройство может быть параметризовано, применяя механизмы ISDU, если РМ активен. Основными функциями РМ является передача параметров Ведущему узлу [Upload (Отправить)). Устройству [Download (Скачать)] и проверка непротиворечивости и допустимости на Устройстве (ValkdityCheck (Про-веритьДопустимость)), как показано на рисунке 84.

РМ управляется сообщениями команд Ведущего узла (см. таблицу В.9). Например, сторожевое условие [Upload Start] (НачатьПодкачку) соответствует получению команды системы ParamUpioadStart (НачатьПодкачкуПараметров). сторожевое условие [UpioadEnd] (ЗавершитьПодкачку) — получению команды системы ParamUploadEnd (ЗавершитьПодкачкуЛараметров).

Примечание 1 — После прерывания связи SM на Ведущем узле применяет услугу SM_DevKeMode с переменной «INACTIVE» для прекращения процесса отправки и возврата в состояние «IDLE».

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

Примечание 2 — Пользовательская программа PLC и инструмент параметризации могут конфликтовать (множественный доступ), например, если во время ввода в эксплуатацию пользователь не блокировал доступы от программы PLC и изменяет параметры через инструмент.

Механизм РМ на устройстве всегда активен, и услуга DS_ParUpload.req в состоянии Т4 применяется для запуска механизма DS в 10.4.2.

128

ГОСТ Р МЭК 61131-9—2017

Рисунок 84 — Конечная машина РМ

В таблице 94 показаны таблицы перехода состояний конечной машины РМ. Таблица 94 — Таблицы перехода состояний конечной машины РМ

Имя состояния

Описание состояния

Wte_0

Ожидание передачи параметров

Va!idityCheck_1

Проверка непротиворечивости и допустимости текущего набора параметров

Downtoad_2

Активное скачивание параметров, локальная параметризация блокирована (например. настройка в режиме обучения)

Upload_3

Активная отправка параметров: параметризация глобально блокирована. Все доступы на запись для изменений параметров через инструменты будут отвергаться (Код ошибки ISOU «Service temporarily not available — Device control» (Услуга временно недоступна — Управление Устройством)]

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

T2

0

1

Устанавливает StoreRequest {= TRUE)

тз

0

1

Устанавливает StoreRequest (= TRUE)

Т4

1

0

Отметить набор параметров как допустимый: вызвать DS_ParUpload. req для DS: разрешить положительное подтверждение передачи, сбросить флаг StoreRequest (= FALSE)

Т5

1

0

Отметить набор параметров как допустимый: разрешить положительное подтверждение передачи

129

ГОСТ Р МЭК 61131-9—2017

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

П«рекод

Исходное

состояние

Конечное

состояние

Действие

Тб

1

0

Отметить набор параметров как недопустимый: разрешить отрицательное подтверждение передачи: сбросить флаг StoreRequest (= FALSE): сбросить буфер параметров

Т7

0

2

Блокировать доступ к локальным параметрам

Т8

2

0

Разблокировать доступ к локальным параметрам: сбросить буфер параметров

T9

2

0

Разблокировать доступ к локальным параметрам: сбросить буфер параметров

Т10

0

3

Блокировать доступ к локальным параметрам

Т11

3

0

Разблокировать доступ к локальным параметрам

Т12

3

0

Разблокировать доступ к локальным параметрам

Т13

2

1

Разблокировать доступ к локальным параметрам

Т14

2

1

Разблокировать доступ к локальным параметрам, установить флаг StoreRequest (= TRUE)

Т15

3

3

Блокировать доступ к локальным параметрам

Т16

2

2

Сбросить буфер параметров таким образом, чтобы возможный повторный запуск не был блокирован

Внутренние элемента!

Тип

Определение

DowntoadStore

Bool

Получена команда системы Param Down load Store (СохранитьСкачанные Параметры), см. таблицу В.9

DataVaiid

Bool

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

Datalnvalid

Bool

Отрицатегьньм результат проверки на непротиворе>-м80сть и допустимость

DowntoadStart

Bool

Получена команда системы ParamDownloadStart (НачатьСкачиеание-Парамегров), см. таблицу В.9

DownJoad8reak

Bool

Получена команда системы ParamBreak {ПрерватьПередачуПараме-трое) или ParamUploadStart (НачатьПодкэчкуПараметров)

Download End

Bool

Получена команда системы ParamDownloadEnd (ЗавершитьСхачивание Параметров), см. таблицу В.9

StoreRequest

Bool

Флаг для затребованной последовательности DS. т. е. получена команда системы ParamDownioadStore {СохрамттьСкачаннывПарамвтры) {= TRUE)

NotStore Request

Bool

Инвертированное значение запроса на сохранение StoreRequest

UploadStart

Bool

Получена команда системы ParamUploadStart {НачатьПодкачкуПара-метров). см. таблицу В.9

UploadEnd

Bool

Получена команда системы ParamUploadEnd (ЗавершитьПодкачкуПа-раметров), см. таблицу В.9

SingleParameter

Bool

В случае «одиночного параметра» — как определено в 10.3.4

LocaJParameler

Bool

В случае «локального параметра» — как определено в 10.3.3

РМ поддерживает обработку передачи «одиночного параметра» {Индекс и Субиндекс), а также передачу блочного параметра (полного набора параметров).

10.3.3 Динамический параметр

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

130

ГОСТ Р МЭК 61131-9—2017

Устройства. Данные изменения проходят такие же проверки допустимости, как и при доступе к одиночному параметру. Таким образом, в случае положительного результата OataValid (ДопустимыеДанные) на рисунке 64 флаг StoreRequest (ЗапросСохранения) будет применен, чтобы добиться непротиворечивости DS. В случае отрицательного результата InvaltdData (НедопустимыеДанные) будут восстановлены соответствующие параметры («откат»). Кроме того, рекомендуется применять специфическую для Устройства индикацию е человеко-машинном интерфейсе для положительной или отрицательной обратной связи с пользователем.

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

10.3.4 Одиночный параметр

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

_!_    1    L    _1_

Рисунок 8S — Положительный и отрицательный результаты проверки параметра

Если выполняется параметризация с одиночным параметром через объекты ISDU. Устройство проверяет доступ, структуру, непротиворечивость и допустимость (см. таблицу 95) переданных данных вместе с контекстом полного набора параметров и возвращает результат в подтверждении. Отрицательное подтверждение переносит индикации ошибки из таблицы С.2.

131

ГОСТ Р МЭК 61131-9—2017

Таблице 95 — Определение проверки параметров

Проверка параметра

Определение

Инликаиий ошибки

Доступ

Проверяет законность прав доступа для данного ИндексаЮубин-декса. независимо от содержания данных (Индекс^Субиндекс постоянно или временно недоступен, доступ на запись или Индекс только на чтение)

См. С.2.Э—С.2.В

Непротиворечивость

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

См. С.20.16 и С.20.17

Структура

Проверяет допустимость структуры данных (например, размер данных). Могут записываться только полные структуры данных, например два октета в тип данных Ulntegerl 6

См. С.2.12 иС.2.13

Допустимые

Проверяет допустимость содержания данных отдельных параметров. проводя тесты на пределы данных

См. С.2.9—С.2.11. С.2.14, С.2.15

10.3.5 Блочный параметр

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

Типовая диаграмма последовательностей допустимых изменений блочного параметра с необязательным запросом сохранения в DS показана на рисунке 86.

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

Команда ParamDownloadStart (НачатьСкачиваниеПараметров. см. таблицу В.9) указывает на начало передачи блочного параметра в направлении скачивания от приложения пользователя к Устройству. Команда системы ParamDownloadEnd (ЗавершитьСкачиваниеПараметров) или ParamDownloadStore (СохранитьСкачанныеПараметры) завершает данную последовательность. Обе функции похожи. Однако команда системы ParamDownloadStore (СохранитьСкачанныеПараметры) дополнительно заставляет механизм DS отправить набор параметров через Событие DS_UPLOAD_ REQ (см. 10.4.2).

Во время скачивания блочного параметра проверка непротиворечивости для одиночного передаваемого параметра запрещается и параметры не активируются. С командой ParamDownloadEnd (За-вершитьСкачиваниеПараметров) Устройство проверяет полный набор параметров и показывает результат инициатору передачи блочного параметра в подтверждение ISDU в ответ на команду.

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

В случае недопустимого набора параметров измененные параметры будут отброшены и будет выполнен откат к предыдущему набору параметров. Отрицательное подтверждение содержит одну из индикаций ошибок, приведенных в таблице С.2. При отрицательном подтверждении команды системы ParamDownloadStore (СохранитьСкачанныеПараметры) запрос на сохранение параметров в DS пропускается.

Команда ParamUpioadStart (НачагьПодкачкуПараметров. см. таблицу В.9) указывает на начало передачи блочного параметра в направлении от Устройства к приложению пользователя. Команда системы ParamUploadEnd (ЗаеершитьПсдкачкуПараметров) завершает данную последовательность и указывает на конец передачи.

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

132

ГОСТ Р МЭК 61131-9—2017

Л^ичйиеА

ТрОММк

МсроАегм

At_Whte_feq(SysCooimar>aj

(М*1*тьС**«Ж*У*П1р***<гро«)

AL WH6 СПЦ*)

AL_Wn le_req(P era/neter)

AL_Wh»_on((-»>

Aivmte recHSysCommand).

(Смр*чш1^вч»н**лЛ»рм«*т,¥)*4

AL VYHte_cnf(+)

SDCl_Mes6age()

SDCLMesaageO

SOCl.Messa^eO

SDCl.MemgeO

SDCLMesae^eO

SDCI_MeaageO

AL_Wnte lnd(Sy3Command)

(НпаггъСк&лманиоПарииожроа/

AL_Whte_re*+)

AL_Wite_ind{Pef8meler)

AL_V\*Me_fea(»)

T

AL_Wrte_ind<Sy3Comrnand)

(CGxpomjnviCf+ifmwentpeutmobi)

л AL_Wif_rea<+)_

D$_ParUpioad_req()

««MOW

niplu«lp« • OK

On oat ЗаФЭв МфМн*

«Лммчиде

aama

Рисунок 86 — Успешное скачивание блочного параметра с запросом сохранения е OS

133

ГОСТ Р МЭК 61131-9—2017

Рисунок 87 — Неудачное скачивание блочного параметра

10.3.6 Параллельный доступ к параметрам

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

134

ГОСТ Р МЭК 61131-9—2017

10.3.7 Обработка команд

Команды приложения, такие как настройка а режиме обучения или восстановление заводских установок, передаются в виде параметров. Команда приложения подтверждается положительным ответом услуги — AL_Write.res(+). Отрицательный ответ услуги — AL_Write.res(-) — указывает на неуспешное выполнение команды приложения. 8 обоих случаях должны учитываться ограничения на превышение лимита времени ISDU {см. таблицу 97).

10.4 Хранилище данных (DS)

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

Механизм DS обеспечивает согласованную и актуальную буферизацию параметров Устройства на верхних уровнях программ PLC или сервера параметров полевых шин. OS между Ведущими узлами и Устройствами устанавливается в настоящем стандарте, в то время как механизмы хранилищ памяти на соответствующих верхних уровнях зависят от конфетных полевых шин или систем. Устройство поддерживает стандартизованный набор объектов, предоставляющий информацию о параметрах для DS. таких как требования к объему памяти, управляющую информацию и информацию о состояниях механизма DS (см. таблицу В.10). Проверки параметров DS применяют Контрольную сумму параметров.

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

10.4.2    Конечная машина Хранилища данных

Любой измененный набор допустимых параметров должен отправляться в DS. Отправка инициализируется Устройством возбуждением События «DSJJPLOAD_RE Q » (см. таблицу D.2). Устройство сохраняет внутреннее состояние «Data Storage Upload» (Подкачка в DS в энергонезависимой памяти (см. таблицу В.10. Свойство состояния) до тех пор. пока оно не получит команду DS DS„UploadEnd (ЗавершитьПодкач-куВХранилищаДанных) или DS_DownloadEnd (ЗавершитъСкачиваниеИэХранилищаДанных).

Устройство генерирует Событие запроса подкачки в DS «DS_UPLOAD_REQ» (см. таблицу D.2). только если набор параметров допустимый и:

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

•    устройство получает команду системы ParamDownloadStore (СохранитьСкачанкыеПараметры).

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

Механизм DS на Устройстве определяется в конечной машине, приведенной на рисунке 88.

Рисунок 88 — Конечная машина DS

135

ГОСТ Р МЭК 61131-9—2017

В таблице 96 показаны таблицы перехода состояний конечной машины DS. Назначения Индекса DS подробно показаны в таблице 8.10.

Таблице 96 — Таблицы перехода состояний конечной машины DS

Имя состояния

Описание состояния

DSStateCheckJ)

Проверка состояния активации после инициализации

DSLocked_1

Ожидание разблокировки конечной машины DS

DSIdle_2

Ожидание действий DS

DSActivity_3

Предоставить набор параметров: локальная параметризация заблокирована

Переход

Исходное

состояние

Конечное

состояние

Действие

T1

0

1

Установить свойство состояния State_Property = «Data Storage access locked» {Доступ к DS заблокирован)

T2

1

1

Установить DS_UPLOAD_FLAG = TRUE

ТЗ

1

2

Установить State_Property = «Inactive*

Т4

1

2

Вызвать услугу AL_EVENT.req (EventCode: DS_UPLOAD_REQ): Установить State_Property = «Inactive»

Т5

2

1

Установить State.Property = «Data Storage access locked» (Доступ к DS заблокирован)

Тб

0

2

Установить State_Property = «Inactive*

Т7

2

2

Установить DS_UPLOAD_F LAG = TRUE

Вызвать услугу AL_EVENT.req {EventCode: DS_UPLOAD_REQ)

Т8

2

3

Блокировать доступ к локальным параметрам. Установить State.Property = «Upload» или «Download»

T9

3

2

Установить DS_UPLOAD_FLAG = FALSE, разблокировать доступ к локальным параметрам.

Установить State_Property = «Inactive*

Т10

3

2

Разблокировать доступ к локальным параметрам. Установить State_Property = «Inactive*

Внутренние элементы

Тип

Определение

Unlocked

Bool

DS разблокировано, см. В.2.4

Locked

Bool

DS заблокировано, см. В.2.4

DS_ParUpload.ind

Услуга

Внутренняя услуга Устройства между РМ и DS (см. рисунок 64)

XTransmission Start

Bool

Была вызвана команда DS DS.UptoadStart или DS_DownloadStart

TransmissionEnd

Bool

Была вызвана команда DS DS_Upk>adEnd нгы DS_DownloadEnd

TransmissionBreak

Bool

SM_MODE_INACTIVE или получена команда DS DS.Break

136

ГОСТ Р МЭК 61131-9—2017

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

Рисунок 89 — Последовательность сообщений запроса DS

10.4.3    Конфигурирование Хранилища данных

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

Это рекомендуется во время ввода в эксплуатацию или испытаний системы для предотвращения интенсивного обмена данными.

10.4.4    Пространство памяти Хранилища данных

Для обработки затребованного объема данных для DS при любых обстоятельствах количество сохраняемых индексов и требуемый общий объем памяти даются в параметре Size (Размер, см. таблицу В.10). Общая требуемая память (включая структурную информацию) не должка превышать 2048 октетов (см. приложение F). Механизм OS на ведущем узле в состоянии поддерживать такой объем памяти на каждый порт.

10.4.5    Список индексов Хранилища данных

Устройство является «владельцем» Списка индексов DS (см. таблицу В.10). Назначением Списка индексов является предоставление всей необходимой информации при замене Устройства. Список

137

ГОСТ Р МЭК 61131-9—2017

индексов DS фиксируется для каждого конкретного идентификатора устройства OevicelO. в противном случае нельзя гарантировать целостности данных между ведущим узлом и Устройством. Список индексов содержит маркер окончания (см. таблицу В.10), если Устройство не поддерживает DS (см. 10.4.1). В данном случае размер требуемой памяти равен 0.

10.4.6    Доступность параметров Хранилища данных

Все индексы, перечисленные в Списке индексов, доступны для чтения и записи командам системы DS_UploadStart. DS_DownJoadStart DSJJploadEnd и DS_DownloadEnd (см. таблицу 6.10). Если хотя бы один из индексов отвергается Устройством. DS на Ведущем узле данных прекращает подкачку или скачивание данных командой системы DS_Break. 8 данном случае не будет выполняться никаких повторных попыток последовательности DS.

10.4.7    Хранилище данных без ISDU

Поддержка передачи ISDU в Устройстве является непременным условием для DS-параметров. Параметры страницы 2 Непосредственных параметров не могут сохраняться и восстанавливаться механизмом DS.

10.4.8    Индикация изменения параметров Хранилища данных

Контрольная сумма параметров, определенная в таблице В.10. применяется как индикатор изменений в наборе параметров. Настоящий стандарт не требует специальных механизмов для определения изменений параметров. Набор рекомендованных методов представлен в справочном приложении J.

10.5    Диспетчер Событий (ED)

Любое приложение Устройства может генерировать предопределенную информацию о состоянии системы в случае отказа операций SDCI или специальную техническую информацию (диагностику) как результат применения специальных технических методов диагностики. ED преобразует данную информацию в Событие в соответствии с определениями из А.6. Событие состоит из описателя события EventOualifier. указывающего свойства особой ситуации, и идентификатора кода события EventCode ID. представляющего описание данной особой ситуации вместе с возможными восстановительными мерами. В таблице D.1 приводится список предопределенных идентификаторов и описаний для особых ситуаций на уровне приложения. Диапазоны идентификаторов зарезервированы для особых ситуаций, специфических для профиля и специфических для изготовителя. 8 таблице D.2 содержится список предопределенных идентификаторов для особых ситуаций, специфических для SDCI.

События разделены на Errors (Ошибки). Warnings (Предупреждения) и Notifications (Уведомления). Данная классификация описана в 10.9.2, а в 11.5 описывается, как Ведущий узел контролирует и обрабатывает данные События.

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

10.6    Характеристики Устройства

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

Следующие характеристики Устройства определяются с некоторой степенью детализации, чтобы достичь общего поведения. Они доступны через стандартизированные специфические для Устройства методы или параметры. Доступность данных характеристик определена в описании устройства I/O (lODD)flnfl Устройства.

10.6.2    Обратная совместимость Устройств

Данная характеристика позволяет Устройству выступать в роли предыдущей редакции Устройства. На стадии запуска SM на Ведущем узле перезаписывает идентификатор Устройства DevicelD (DID), затребованный прежним идентификатором устройства. Техническое приложение Устройства переключается к предыдущему набору функций или подмножеству, назначенному для данного DID. Обратная совместимость Устройства применяется по запросу.

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

138

ГОСТ Р МЭК 61131-9—2017

10.6.3    Совместимость редакций протокола

Данная характеристика позволяет Устройству регулировать уровни его протокола к предыдущей версии протокола SDCI. как. например, для версии устаревшего протокола Ведущего узла или в будущем от версии V(x) к версии V(x-n). На стадии запуска SM на Ведущем узле может перезаписать собственную редакцию протокола Устройства RevisionID (RID) в случае несоответствия с редакцией протокола, поддерживаемой Ведущим узлом. Устаревшее устройство не записывает команду Ведущего узла Masterldent (см. таблицу В.2). и. таким образом. Устройство может приспособиться к устаревшему протоколу (V1.0). Совместимость редакций протокола Устройства применяется по запросу.

10.6.4    Заводские установки

Данная характеристика позволяет Устройству восстанавливать первоначальное состояние поставки. Флаг DS и другие динамические параметры, такие как «Error Count» (Счетчик ошибок, см. В.2.17). «Device Status» (Состояние Устройства, см. В.2.18) и «Detailed Device Status» (Подробное состояние Устройства, см. В.2.19). возвращаются в исходное состояние, когда применяется эта возможность. Данная характеристика не включает параметры, специфические для изготовителя, например, счетчик рабочих часов.

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

Изготовитель обязан гарантировать правильное функционирование при любых обстоятельствах. Сброс в исходное состояние запускается принятием команды системы «Restore factory settings» (восстановить заводские установки, см. таблицу В.9). Возврат к заводским установкам для Устройства выполняется по запросу.

10.6.5    Возврат приложения в исходное состояние

Данная характеристика позволяет Устройству восстанавливать специальное техническое приложение. Это особенно полезно, когда специальное техническое приложение должно быть установлено в предопределенное рабочее состояние без прерывания связи и цикла закрытия. Сброс в исходное состояние запускается принятием команды системы «Application reset» (Возврат приложения в исходное состояние, см. таблицу В.9). Возврат специального технического приложения в исходное состояние выполняется для Устройства по запросу.

10.6.6    Сброс Устройства в исходное состояние

Данная характеристика позволяет Устройству выполнять горячий запуск. Данная возможность особенно полезна, когда необходимо сбросить Устройство в начальное состояние, например при включении питания. В данном случае связь будет прервана. Горячий запуск инициируется принятием команды системы «Device reset» (Сброс Устройства в исходное состояние, см. таблицу В.9). Горячий запуск выполняется для Устройства по запросу.

10.6.7    Визуальная индикация в интерфейсе SDCI

Данная характеристика показывает рабочее состояние Устройства в интерфейсе SDCI. Индикация в режиме SDCI устанавливается в 10.9.3. Индикация режима SIO определяется изготовителем и не охватывается этим определением. Функция запускается индикацией SM (во всех состояниях, исключая SM Jdfe и SM_SIO на рисунке 79). Индикация SDCI запускается для Устройства по запросу.

10.6.8    Блокировка доступа к параметрам

Данная возможность позволяет глобально блокировать или разблокировать доступ на запись ко всем записываемым параметрам Устройства, доступным через интерфейс SDCI (см. 8.2.4). Блокировка запускается принятием команды системы «Device Access Locks» (Блокировки доступа к Устройству, см. таблицу 8.8). Поддержка данных функций для Устройства производится по запросу.

10.6.9    Блокировка Хранилища данных

Установка такой блокировки вызывает переключение свойства состояния «State_Property» в таблице В.10 в состояние «Data Storage locked» (DS блокировано), и Устройство не может посылать Событие DS_UPLOAD_REQ запроса подкачки в DS. Поддержка этой функции является обязательной для Устройства, если реализован механизм DS.

10.6.10    Блокировка параметров Устройства

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

10.6.11    Блокировка интерфейса пользователя Устройства

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

139

ГОСТ Р МЭК 61131-9—2017

10.6.12 Время сдвига

Время сдвига roHse, — это параметр, конфигурируемый пользователем (см. В.2.22). Он определяет начало обработки технологических данных Устройства относительно начала цикла M-последовательности, что означает начало сообщения (порта) Ведущего узла.

Данный сдвиг позволяет:

•    синхронизировать обработку данных Устройства с циклом (порта) Ведущего узла в пределах определенных ограничений:

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

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

На рисунке 90 показано распределение сообщений во времени относительно обработки данных в Устройствах.

Icrc

1ш*тпяим

впаффмчис**

ДЛИ VtTpoMi**

Соседим

GooOuwmm

КгоаЬгтаз

Соьбщнме

**9

Рисунок 90 — Временная диаграмма цикла

Время сдвига определяет задержку относительно начала цикла М-последовательности. Поддержка этой функции для Устройства производится по запросу.

10.6.13    Концепция Хранилища данных

Механизм DS в Устройстве позволяет автоматически сохранять параметры на сервере DS Ведущего узла и восстанавливать их по уведомпению о Событии. Непротиворечивость данных проверяется е любом направлении на Ведущем узле и Устройстве. DS е основном фокусируется на параметрах конфигурирования настройки Устройства во время ввода в эксплуатацию (см. 10.4 и 11.3). Поддержка данных функций для Устройства производится по запросу.

10.6.14    блочный параметр

Возможность передачи блочного параметра а Устройство позволяет передавать наборы параметров из программы PLC без проверки целостности отдельных объектов данных. Проверка допустимости и непротиворечивости выполняется е конце передачи блочного параметра для всего набора параметров. Данная функция в основном сосредотачивается на том. чтобы обмен параметрами Устройства производился во время выполнения (см. 10.3). Поддержка данных функций для Устройства производится по запросу.

10.7 Проектные нормы и ограничения Устройства

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

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

10.7.2    Данные процесса

Канал связи процесса передает циклические PD без всяких помех со стороны каналов связи OD. PDE начинается автоматически после любого переключения Устройства е состояние OPERATE через сообщение из Ведущего узла.

140

ГОСТ Р МЭК 61131*9—2017

Формат передаваемых данных зависит от Устройства и изменяется от отсутствия октетов данных до 32 октетов в каждом направлении связи.

Рекомендации:

•    структуры данных должны подходить для использования приложениями PLC:

•    настоятельно рекомендуется следовать правилам, изложенным в Е.3.3 и в [6].

Подробная информация об индикации допустимых и недопустимых РО через флаг PDValid при циклическом обмене данными приводится в А. 1.5.

10.7.3    Потеря связи

Проектировщик Устройства обязан определить подходящее поведение Устройства в случае, когда связь с Ведущим узлом потеряна (переход Т10 на рисунке 42 обрабатывает обнаружение потери связи, а подраздел 10.2 определяет последующие действия Устройства).

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

10.7.4    Непосредственные параметры

Связь с использованием страниц Непосредственных параметров предоставляет механизм без подтверждения связи для обеспечения правильного получения или допустимости передаваемых параметров. К странице Непосредственных параметров можно получить доступ только октет за октетом (Субиндекс) или к целому объекту (16 октетов). Поэтому целостность параметров длиной более одного октета не может быть гарантирована в случае доступа октет за октетом.

Параметры из страницы Непосредственных параметров не могут сохраняться и восстанавливаться через механизм DS.

10.7.5    Канал связи ISDU

Канал связи ISDU предоставляет мощные средства для передачи параметров и команд (см. раздел В.2).

При использовании данного какала следует учитывать следующие правила (см. рисунок 6):

•    индекс 0 недоступен при связи через канал ISDU. Доступ перенаправляется Ведущим звеном к странице 1 Непосредственных параметров, применяя канал связи страниц;

•    индекс 1 недоступен при связи через канал ISDU. Доступ перенаправляется Ведущим эвеном к странице 2 Непосредственных параметров, применяя канал связи страниц;

•    индекс 3 недоступен для прикладной программы PLC. Доступ ограничен только для приложений Ведущего узла (DS);

•    после получения запроса ISDU из ведущего узла Устройство отвечает в течение 5000 мс (см. таблицу 97). Любое нарушение заставляет Ведущий блок снять текущее задание.

10.7.6    Правила для идентификатора Устройства DevicelD. связанные с модификациями Устройства

Устройства с определенными идентификаторами устройства DevicelD и изготовителя VendorlD не будут отвергаться при передаче данных и функциональной деятельности. Это применимо к датчикам и исполнительным устройствам. Данные Устройства могут, например, отличаться по:

-    длине кабеля;

-    материалам корпуса;

•    монтажным механизмам;

-    другим характеристикам и рабочим условиям.

10.7.7    Константы протокола

В таблице 97 приводится обзор основных констант протокола для Устройств.

Таблица 97 — Обзор констант протокола для Устройств

Переменная системы

Ссылки

Значения

Определение

Время подтверждения ISDU. например. после команды системы

В.2.2

5000 мс

Время от приема ISDU (например, команды системы) до начала ответного сообщения Устройства (см. рисунок 61)

Максимальное число входов в списке индексов InOexList

В.2.3

70

Каждый вход включает Индекс и Субиндекс. Все 70 входов занимают в общем 210 октетов памяти

141

ГОСТ Р МЭК 61131-9—2017

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

Переменная системы

Ссылки

Значения

Определение

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

Приложение В

0 (для чисел) 0x00

(для символов)

Технические средства устанавливают все неиспользуемые параметры в предустановленные значения

Процедура пробуждения

7.3.2.2

См. таблицы 40 и 41

Минимальная и максимальная длительность и число повторных попыток

Максимальное число повторений MaxRetry

7.3.3.3

2, см. таблицу 44

Максимальное число повторных попыток после ошибок связи

Минимальное время цикла MinCydeTime

А.3.7 и В.1.3

См. таблицы А.11 и В.З

Устройство определяет свое минимальное время цикла для сбора входных или выходных PD

Используемый диапазон Индекса

Раздел В.2

См. таблицу В.8

Данная версия стандарта резервирует некоторые области общим размером 65 535 Индексов

Ошибки и предупреждения

10.9.2

50 мс

Событие с режимом Event appears (Появилось Событие) сохраняется по меньшей мере в течение данного промежутка времени

Счетчик Событий EventCount

8.2.2.11

1

Ограничение для AL_Event.req

10.8    Описание устройства ввода/вывода (IODD)

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

Файл IODD является файлом, который формально описывает Устройство.

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

Файл IODD может применяться инженерными средствами для PLC и/или Ведущих узлов в целях идентификации, конфигурирования, описания структур данных для PDE. параметризации и расширов-ки диагностики конкретного Устройства.

Примечание — Подробное описание языка IODD для описания Устройства приводится в [6].

10.9    Диагностика Устройства

10.9.1 Концепции

В настоящем стандарте в подразделе D.2 представлены только наиболее общие коды событий EventCodes. Целью этой общей диагностической информации является предоставление оператору или специалисту по техническому обслуживанию возможности принятия быстрых мер по устранению отказа без глубокого знания технологии Устройства. Таким образом, текст, связанный с конкретным кодом События EventCode. вместе с диагностической информацией всегда содержит инструкции по исправлению.

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

Сжатая информация о «состоянии здоровья» Устройства может быть извлечена из параметра состояния устройства «Device Status» (см. В.2.18). В таблице 98 представлен обзор различных возможностей Устройства и показаны примеры потребителей данной информации.

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

Примечание — Специфические для профиля значения параметра DetaifedDeviceStatus приведены в [7].

142