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

(утв. и введен в действие Приказом Росстандарта от 14.09.2017 № 1124-ст)

ОКС 35.240.50

25.040.40

Дата введения 1 сентября 2018 года

Предисловие

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 ВВЕДЕН ВПЕРВЫЕ

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

Введение

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

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

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

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

Управление приводом в технологии SDCI (IO-LinkTM) <1> нуждается в таких доступных по цене датчиках и исполнительных устройствах для обмена диагностическими и конфигурационными данными с контроллером [программируемым контроллером (PC) или программируемым логическим контроллером (PLC)], применяя недорогую технологию цифровой связи при одновременном обеспечении обратной совместимости с токовыми сигналами ввода/вывода.

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

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

Любое Устройство, совместимое с 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 Патентная декларация

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

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

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

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

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

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

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

Настоящий стандарт устанавливает технологию одноточечного интерфейса цифровой связи SDCI для небольших датчиков и исполнительных устройств (более известных под названием IO-LinkTM), которая расширяет традиционные интерфейсы цифрового ввода и вывода, определенные в МЭК 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 [Электромагнитная совместимость (ЭМС). Часть 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. Круглые соединители. Детальные технические условия для соединителей M12 с контровыми устройствами)

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 <www.ietf.org> [Рабочая группа инженеров Интернета (IETF). Запрос комментария RFC 5905. Протокол сетевой синхронизации, версия 4. Протокол и спецификация алгоритмов; доступный по <www.ietf.org>]

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

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

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

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

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

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

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

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

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

3.1.7 COM1 (COM1): Режим связи SDCI со скоростью передачи данных 4,8 кбит/с.

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

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

3.1.10 COMx (COMx): Один из трех возможных режимов связи SDCI: COM1, COM2 или COM3.

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

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

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

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

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.1.21 ISDU (ISDU): Индексированный сервисный блок данных, используемый для ациклической передачи параметров с подтверждением, которые могут быть сегментированы в нескольких M-последовательностях.

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

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

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

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

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

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

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

3.1.28 сообщение (message): Последовательность фреймов 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, DI, 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.38 коммутирующий сигнал (switching signal): Двоичный сигнал от или к Устройству при нахождении в режиме SIO (в отличие от «кодовой коммутации» передачи данных SDCI).

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

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

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

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

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

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

\Delta f_{DTRM} — допустимое отклонение в скорости передачи данных (измеренное в %);

\Delta VS — пульсация питающего напряжения (измеренная в В);

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

BEP — вероятность битовой ошибки;

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

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

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

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

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

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

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

H/L — высокий/низкий сигнал на выходе приемника;

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

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

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

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

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

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

IQPK — максимальный ток драйвера в ненасыщенном рабочем состоянии ON (измеренный в А);

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

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

IQQ — ток в рабочей точке на входе C/Q в V0 с неактивными выходными драйверам (измеренный в А);

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

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

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

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

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

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

N24 — дополнительный источник питания 24 В (-);

nWU — счетчик повторных попыток пробуждения;

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

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

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

P24 — дополнительный источник питания 24 В (+);

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

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

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

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

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

r — время достижения устойчивого уровня относительно начала стартового бита (измеренный в TBIT);

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

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

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

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

SM — модуль управления системой;

t1 — задержка передачи фрейма UART на Ведущем узле (измеренная в TBIT);

t1 — задержка передачи фрейма UART на Устройстве (измеренная в TBIT);

tA — задержка ответа на Устройстве (измеренная в TBIT);

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

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

tDF — время спада (измеренное в с);

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

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

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

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

tM-sequence — продолжительность M-последовательности (измеренная в TBIT);

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

tH — время обнаружения для верхнего плеча (измеренное в с);

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

tND — время подавления шума (измеренное в с);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.5 Рисунки

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

• стрелка, имеющая только имя услуги, представляет как запрос, так и соответствующее подтверждение (запрос следует по направлению стрелки);
• запрос без подтверждения, а также все указания и ответы, помеченные как таковые (т.е. service.req, service.ind, service.rsp).

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

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

3.3.6 Порядок передачи октета

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

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

MSO — самый старший октет;

LSO — самый младший октет.

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

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

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

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

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

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

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

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

IEC 60947-5-2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1.2 Топология

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

Рисунок 10 — Топология SDCI

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

5.2.1 Обзор

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

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

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

Если порт находится в неактивном режиме, линия C/Q будет высокоимпедансной (слабонагруженной). В режиме SIO порт может применяться как стандартный входной или выходной интерфейс в соответствии с определениями МЭК 61131-2 или таблицей 6 соответственно. Уровни связи SDCI обходятся, как показано на рисунке 11; сигналы прямо обрабатываются в приложении Ведущего узла. В режиме SDCI услуга PL_WakeUp.req создает специальный сигнал-шаблон (импульс тока), который может обнаруживаться Устройством с SDCI, подключенным к этому порту (см. 5.3.3.3).

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

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

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

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

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

Таблица 1

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

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

5.2.2.1 Услуга PL_SetMode

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

Таблица 2

Услуга PL_SetMode

5.2.2.2 Услуга PL_WakeUp

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

Таблица 3

Услуга PL_WakeUp

5.2.2.3 Услуга PL_Transfer

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

Таблица 4

Услуга PL_Transfer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3.2.2 Приемник

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

Таблица 5

Электрические характеристики приемника

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

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

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

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

Таблица 6

Электрические характеристики порта Ведущего узла

5.3.2.4 Устройство

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

Таблица 7

Электрические характеристики Устройства

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

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

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

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

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

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

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

lsb — младший бит;

msb — старший бит.

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

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

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

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

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

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

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

Приемник будет обнаруживать биты, как сигнал допустимой формы в допустимом диапазоне глазковой диаграммы на соединении линии C/Q. Формы сигнала в областях «необнаружения» (ниже VTHLMAX или VTHHMIN и в пределах tND) не будут приводить к недопустимым битам.

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

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

Для каждого бита n в битовой последовательности (n = 1 ... 11) фрейма UART время (n — r)TBIT (см. таблицу 8 для значений r) определяет время, через которое будет достигаться правильный уровень в диапазонах высокого и низкого сигналов, как продемонстрировано в глазковой диаграмме на рисунке 19. Время (n — s) TBIT (см. таблицу 8 для значений s) описывает время, которое будет проходить до изменения уровня. Если возникают вопросы по характеристикам сигнала, всегда следует обращаться к глазковой диаграмме на рисунке 19.

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

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

Таблица 8

Динамические характеристики передачи данных

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

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

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

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

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

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

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

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

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

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

Таблица 9

Характеристики запроса пробуждения

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

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

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

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

Прикладная часть Устройства может получать питание одним из трех способов:

• через линии питания системы 3-проводного присоединения SDCI (порты класса A), применяя Питание 1;
• через дополнительные линии питания системы 5-проводного присоединения SDCI (порты класса B), применяя дополнительный источник питания в Ведущем узле (Питание 2);
• через локальный источник питания в Устройстве (зависит от конструкции).

Порт класса A допускает потребление тока до 200 мА, как указано в таблице 6. Максимальное потребление энергии в порте класса B зависит от выбранного метода. Соединение M12 позволяет увеличивать ток до 3,5 А.

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

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

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

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

Таблица 10

Регламент подачи питания

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

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

Назначение контактов Ведущего узла и Устройства основано на спецификациях, приведенных в МЭК 60947-5-2, с расширениями, определенными в разделах ниже. Порты класса A применяют соединители M5, M8 и M12 не более чем с четырьмя контактами. Порты класса B применяют только соединители M12 с пятью контактами. Соединители M12 имеют код «A» в соответствии с МЭК 61076-2-101.

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

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

Таблица 11

Схема назначений контактов

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

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

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

5.5.2 Кабель

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

Таблица 12

Характеристики кабеля

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

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

В таблице 13 приведены токоведущие жилы кабеля и назначенные им цветовые коды.

Таблица 13

Схема кабельного соединителя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 14

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

В подразделе 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

7.2.1.3 Услуга DL_WriteParam

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

Таблица 16

Услуга DL_WriteParam

7.2.1.4 Услуга DL_Read

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

Таблица 17

Услуга DL_Read

7.2.1.5 Услуга DL_Write

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

Таблица 18

Услуга DL_Write

7.2.1.6 Услуга DL_ISDUTransport

Услуга DL_ISDUTransport применяется для передачи ISDU. Данная услуга применяется Ведущим узлом для посылки запроса услуги из AL Ведущего узла в Устройство. Она также применяется Устройством для посылки ответа на запрос услуги из AL Устройства. Параметры сервисных примитивов приведены в таблице 19.

Таблица 19

Услуга DL_ISDUTransport

7.2.1.7 Услуга DL_ISDUAbort

Услуга DL_ISDUAbort прекращает текущую передачу ISDU. Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 20.

Таблица 20

Услуга DL_ISDUAbort

Услуга возвращает подтверждение после прекращения передачи ISDU.

7.2.1.8 Услуга DL_PDOutputUpdate

Прикладной слой Ведущего узла применяет услугу DL_PDOutputUpdate для модификации данных вывода (PD от Ведущего узла к Устройству) на DL. Параметры сервисных примитивов приведены в таблице 21.

Таблица 21

Услуга DL_PDOutputUpdate

7.2.1.9 Услуга DL_PDOutputTransport

DL на Устройстве применяет услугу DL_PDOutputTransport для передачи содержания выходных PD AL (от Ведущего узла к Устройству). Параметры сервисных примитивов приведены в таблице 22.

7.2.1.10 Услуга DL_PDInputUpdate

Прикладной слой Ведущего узла применяет услугу DL_PDInputUpdate для модификации входных данных (PD от Устройства к Ведущему узлу) на DL. Параметры сервисных примитивов приведены в таблице 23.

7.2.1.11 Услуга DL_PDInputTransport

DL на Устройстве применяет услугу DL_PDInputTransport для передачи содержания входных PD (от Устройства к Ведущему узлу) AL. Параметры сервисных примитивов приведены в таблице 24.

Таблица 24

Услуга DL_PDInputTransport

7.2.1.12 Услуга DL_PDCycle

DL применяет услугу DL_PDCycle для указания конца цикла PD AL.

Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 25.

Таблица 25

Услуга DL_PDCycle

7.2.1.13 Услуга DL_SetMode

Услуга DL_SetMode применяется управлением системой для создания конечной машины канального слоя и посылки характеристических значений, требуемых для работы на DL. Параметры сервисных примитивов приведены в таблице 26.

Таблица 26

Услуга DL_SetMode

7.2.1.14 Услуга DL_Mode

AL применяет услугу DL_Mode для уведомления SM о достижении определенного рабочего состояния. Параметры сервисных примитивов приведены в таблице 27.

Таблица 27

DL_Mode

7.2.1.15 Услуга DL_Event

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

Таблица 28

DL_Event

7.2.1.16 Услуга DL_EventConf

Услуга DL_EventConf подтверждает переданные События через обработчик Событий. Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 29.

7.2.1.17 Услуга DL_EventTrigger

Запрос DL_EventTrigger начинает сигнализацию События [см. Event flag (флаг События) на рисунке A.3] и «замораживает» память События на DL. Подтверждение возвращается после того, как обработаны активированные События. Дополнительные запросы услуги DL_EventTrigger игнорируются до подтверждения предыдущего события (см. 7.3.8, 8.3.3 и рисунок 64). Данная услуга не имеет параметров. Сервисные примитивы приведены в таблице 30.

Таблица 30

DL_EventTrigger

7.2.1.18 Услуга DL_Control

Ведущий узел применяет услугу DL_Control для передачи управляющей информации через механизм команд Ведущего узла соответствующему приложению Устройства, зависящему от используемой технологии, и получает управляющую информацию через механизм флага состояния PD (см. A.1.5) и услугу PDInStatus (см. 7.2.2.5). Параметры сервисных примитивов приведены в таблице 31.

Таблица 31

Услуга DL_Control

7.2.2 Услуги уровня DL-A

7.2.2.1 Обзор

В соответствии с подразделом 7.1 данные DL разделяются на верхний уровень DL-B и нижний уровень DL-A. Уровень DL-A включает обработчик сообщений, как показано на рисунках 26 и 27.

Обработчик событий Ведущего узла кодирует команды и данные в сообщения и посылает Данные сообщения в подключенное Устройство на PL. Он получает сообщения от Устройства на PL и переправляет их содержание соответствующим обработчикам в форме подтверждения. Если в событии Устройства установлен флаг События «Event flag» (см. A.1.5), обработчик сообщений Ведущего узла вызывает услугу EventFlag, чтобы проинструктировать обработчик Событий.

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

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

В таблице 32 приведены распределения Ведущего узла и Устройства по их ролям, как инициатора (I) или получателя (R) в контексте исполнения их конкретных услуг DL-A.

Таблица 32

Услуги уровня DL-A на Ведущем узле и Устройстве

7.2.2.2 Услуга OD

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

Таблица 33

Услуга OD

7.2.2.3 Услуга PD

Услуга PD применяется для подготовки PD, посылаемых по каналу связи процесса. Подтверждение услуги содержит данные от приемника. Параметры сервисных примитивов приведены в таблице 34.

Таблица 34

Услуга PD

7.2.2.4 Услуга EventFlag

Услуга EventFlag устанавливает или сообщает состояние флага События «Event flag» (см. A.1.5) во время циклической связи. Параметры сервисных примитивов приведены в таблице 35.

Таблица 35

Услуга EventFlag

7.2.2.5 Услуга PDInStatus

Услуга PDInStatus устанавливает и сообщает значение допустимости входных PD. Параметры сервисных примитивов приведены в таблице 36.

Таблица 36

PDInStatus

7.2.2.6 Услуга MHInfo

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

Таблица 37

Услуга MHInfo

7.2.2.7 Услуга ODTrig

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

Таблица 38

Услуга ODTrig

7.2.2.8 Услуга PDTrig

Услуга PDTrig доступна только на Ведущем узле. Услуга запускает обработчик PD для формирования PD для следующего сообщения Ведущего узла. Параметры сервисных примитивов приведены в таблице 39.

Таблица 39

Услуга PDTrig

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

7.3.1 Обзор

На рисунках 26 и 27 показаны структура DL и его компоненты; обработчик режима DL, обработчик сообщений, обработчик PD и обработчик OD для предоставления определенных услуг. В 7.3.2 - 7.3.8 устанавливается поведение (динамика Данных обработчиков) средствами конечных машин языка UML и таблиц переходов.

Обработчик OD поддерживает три независимых типа данных: ISDU, команда и Событие. Поэтому три дополнительные конечные машины работают вместе с конечной машиной обработчика OD, как показано на рисунке 28. Дополнительная последовательность или диаграммы деятельности демонстрируют некоторые сценарии использования. См. IEC/TR 62390 и ИСО/МЭК 19505.

Рисунок 28 — Конечные машины канального уровня

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

7.3.2 Обработчик канального уровня

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

Обработчик DL, показанный на рисунке 26, несет ответственность за установку связи SDCI, применяя услуги PL и внутренние административные вызовы, и контролирует обработчик сообщений, а также состояния других обработчиков.

Обработчик DL, показанный на рисунке 27, несет ответственность за обнаружение запроса пробуждения и установление связи. Он получает команды Ведущего узла для синхронизации с состояниями STARTUP, PREOPERATE и OPERATE обработчика DL Ведущего узла и управляет активацией и деактивацией обработчиков сообразно обстоятельствам.

7.3.2.2 Процедуры пробуждения и правила соответствия Устройства

Управление системой запускает следующие действия на DL с помощью услуги DL_SetMode (затребованный режим = STARTUP).

Обработчик DL Ведущего узла пытается установить связь через запрос пробуждения (PL_WakeUp.req) с M-последовательностью TYPE_0 (чтение «MinCycleTime») в соответствии с последовательностью, показанной на рисунке 29.

Рисунок 29 — Пример попытки установления связи

После запроса пробуждения (WURQ), определенного в 5.3.3.3, обработчик DL требует, чтобы обработчик сообщений послал первое тестовое сообщение через промежуток времени TREN (см. таблицу 9) и TDMT (см. таблицу 40). Установленные скорости передачи данных портов COM1, COM2 и COM3 применяются в нисходящем порядке, пока не будет получен ответ, как показано на рисунке 29:

Шаг (1): сообщение Ведущего узла со скоростью передачи данных порта COM3 (см. таблицу 8);

Шаг (2): сообщение Ведущего узла со скоростью передачи данных порта COM2 (см. таблицу 8);

Шаг (3): сообщение Ведущего узла со скоростью передачи данных порта COM1 (см. таблицу 8);

Шаг (4): ответное сообщение Устройства со скоростью передачи порта COM1.

Перед инициацией (нового) сообщения обработчик канального вывода ожидает по меньшей мере в течение периода времени TDMT. Значение TDMT устанавливается в таблице 40.

Таблица 40

Процедура пробуждения и характеристики повторной попытки

В отношении поддержки скоростей передачи данных для Устройства применяется следующее правило соответствия:

- Устройство будет поддерживать только одну из скоростей передачи для портов COM1, COM2 или COM3.

Если попытка установления связи не достигает успеха, обработчик DL Ведущего узла не будет начинать новую попытку процедуры пробуждения, пока не истечет период времени TDWU, как показано на рисунке 30 и установлено в таблице 40.

Рисунок 30 — Неудачная попытка установления связи

Ведущий узел будет выдавать до nWU+1 последовательных запросов пробуждения, как показано на рисунке 31. Если эта начальная последовательность повторных попыток пробуждения терпит неудачу, Устройство возвратит линию C/Q в режим SIO через промежуток времени TDSIO (TDSIO повторно запускается в Устройстве после каждого обнаруженного запроса пробуждения). Ведущий узел не будет запускать новую последовательность попыток пробуждения через промежуток времени TSD.

Рисунок 31 — Стратегия повторных попыток установления связи

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

Значения для согласования по времени процедур пробуждения и повторных попыток установлены в таблицах 9 и 40. Они определяются с точки зрения Ведущего узла.

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

7.3.2.3 Процедура возврата в исходный режим

SM вызывает следующие действия на DL с помощью услуги DL_SetMode (режим = INACTIVE):

- команда Ведущего узла Fallback (Возврат в исходное состояние, см. таблицу B.2) заставляет Устройство перейти в режим SIO;

- Устройство завершит переход в режим SIO через три времени цикла Ведущего узла MasterCycleTimes и/или не позднее, чем через 500 мс после команды Ведущего узла. Это делает возможными повторные попытки, если команда Ведущего узла закончилась неудачно из-за отрицательного ответа Устройства.

На рисунке 32 показаны процедура возврата в исходный режим, ее повторные попытки и временные ограничения.

Рисунок 32 — Процедура возврата в исходный режим

В таблице 41 устанавливаются временные характеристики возврата в исходный режим. Подробное описание приводится в A.2.6.

Таблица 41

Временные характеристики возврата в исходный режим

7.3.2.4 Конечная машина обработчика DL Ведущего узла

На рисунке 32 показана конечная машина обработчика DL Ведущего узла.

Рисунок 33 — Конечная машина обработчика канального уровня Ведущего узла

Примечание — Условные обозначения диаграмм языка UML определены в 3.3.7.

После получения услуги DL_SetMode_STARTUP из SM обработчик DL вначале создаст импульс тока пробуждения через услугу PL_WakeUp и затем установит связь. Данная процедура определена в функциональном узле 1 на рисунке 34.

Рисунок 34 — Функциональный узел 1 для установки связи

Цель состояния «Startup_2» — это проверка идентичности Устройства через данные страницы Непосредственных параметров (см. рисунок 5). В состоянии «PreOperate_3» Ведущий узел назначает параметры Устройству, применяя ISDU. Циклический обмен PD осуществляется в состоянии «Operate». В данном состоянии дополнительные OD, такие как ISDU, команды и События могут передаваться, применяя подходящие типы M-последовательностей (см. рисунок 37).

В состояниях «PreOperate_3» и «Operate_4» в Ведущем узле активируются различные наборы обработчиков.

В таблице 42 показаны таблицы перехода состояний обработчика DL на Ведущем узле.

Таблица 42

Таблицы перехода состояний обработчика DL на Ведущем узле

7.3.2.5 Конечная машина обработчика DL на Устройстве

На рисунке 35 показана конечная машина обработчика DL на Устройстве. В состояниях PreOperate_3 и Operate_4 в Устройстве активируются различные наборы обработчиков.

Рисунок 35 — Конечная машина обработчика канального уровня на Устройстве

Ведущий узел применяет команды Ведущего узла (см. таблицу 42) для изменения состояний SIO, STARTUP, PREOPERATE и OPERATE. При каждом обнаружении обработчиком сообщений неправильных (неожиданных) типов M-последовательности он будет заставлять обработчик DL менять состояние на STARTUP и указывать на данное состояние модулю управления системой (см. 9.3.3.2) в целях синхронизации Ведущего узла и Устройства.

В таблице 43 показаны таблицы перехода состояний обработчика DL на Устройстве.

Таблица 43

Таблицы перехода состояний обработчика DL на Устройстве

7.3.3 Обработчик сообщений

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

Роль обработчика сообщений установлена в подразделе 7.1 и 7.2.2.1. Структура и типы M-сообщений и поведение (динамика) обработчика сообщений установлены в 7.3.3.

7.3.3.2 M-последовательности

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

Рисунок 36 — Последовательности сообщений SDCI

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

Сообщение Ведущего узла начинается с октета «Управления M-последовательностью» (MC), далее следуют октет и необязательные октеты PD. Сообщение Устройства, в свою очередь, начинается с необязательных октетов PD, OD, за которыми следует октет «CHECK/STAT» (CKS).

Для удовлетворения конкретных требований исполнительного устройства или датчика (скорость сканирования, объем PD) могут выбираться различные типы M-последовательности. Длина сообщений Ведущего узла и Устройства может меняться в зависимости от типа сообщений и направления передачи данных (см. рисунок 36).

На рисунке 37 представлен обзор установленных типов M-последовательности. Части, отмеченные пунктиром, зависят от направления операции (чтение или запись) в управляющем октете M-последовательности.

Рисунок 37 — Обзор типов M-последовательностей

Фиксированные типы M-последовательности состоят из TYPE_0, TYPE_1_1, TYPE_1_2 и от TYPE_2_1 до TYPE_2_6. Переменные типы M-последовательности состоят из TYPE_1_V и TYPE_2_V.

Различные типы M-последовательностей удовлетворяют различным требованиям датчиков и исполнительных устройств относительно ширины их PD и соответствующих условий. Подробное описание типов M-последовательностей приводится в разделе A.2. В разделе A.3 описываются временные ограничения M-последовательностей.

7.3.3.3 Ограничения времени цикла Ведущего узла

В состояниях STARTUP и PREOPERATE устройство может осуществлять связь ациклически. Для обнаружения отключения Устройства рекомендуется, чтобы Ведущий узел поддерживал периодическую связь (сообщения контроля активности) через ациклические M-последовательности на DL. Минимальное время восстановления для ациклической связи, установленное в A.2.6, будет рассмотрено ниже.

После трех фаз циклическая связь PD может начинаться Ведущим узлом через услугу DL_SetMode (OPERATE). Типы M-последовательности для циклического обмена данными будут применяться на данной фазе связи для обмена PD и OD с Устройством (см. таблицы A.9 и A.10).

Ведущий узел будет применять для времени tCYC значение, указанное в параметре MasterCycleTime (см. таблицу B.1) с относительным допуском от 0% до плюс 10% (включая флуктуации синхронизации).

Если Устройство должно переключаться обратно в режим SIO после параметризации, Ведущий узел будет посылать команду Fallback возврата в исходный режим (см. таблицу B.2), за которой следует подтверждение от Устройства.

7.3.3.4 Конечная машина обработчика сообщений Ведущего узла

На рисунке 38 показана конечная машина обработчика DL Ведущего узла. Три функциональных узла, описывающих реакции на ошибки связи, показаны на рисунках 39, 40 и 41.

Рисунок 38 — Конечная машина обработчика сообщений Ведущего узла

Обработчик сообщений следит за соблюдением специальных требований к связи в состояниях «EstablishCom», «Startup», «PreOperate» и «Operate» обработчика DL.

Внутренний административный вызов MH_Conf_COMx в состоянии «Inactive_0» заставляет обработчик сообщений посылать тестовое сообщение с M-последовательностью типа TYPE_0 и скоростями передачи различных портов COM3, COM2 и COM1 во время последовательности установления связи.

В состоянии «Startup_2» предоставляются все средства связи для поддержки проверки идентичности SM с помощью услуг DL_Read и DL_Write. Обработчик сообщений ожидает появления данных услуг для посылки и получения сообщений (ациклическая связь).

Состояние «Preoperate_6» служит контрольной точкой для всех действий с OD, таких как ISDU, команды и События, с целью поддержки параметризации Устройства. Обработчик сообщений ожидает появления данных услуг, показанных на рисунке 38, для посылки и получения сообщений (ациклическая связь).

Состояние «Operate_12» является контрольной точкой для обмена циклическими PD. В зависимости от типа M-последовательности обработчик сообщений генерирует сообщения Ведущего узла с PD, полученными от обработчика прерываний PD через услугу PD, и при необходимости с OD, полученными от обработчика OD через услугу OD.

На рисунке 39 показан функциональный блок состояния «Response 3».

Рисунок 39 — Функциональный блок «Response 3» обработчика прерываний

На рисунке 40 показан функциональный блок состояния «Response 8».

Рисунок 40 — Функциональный блок «Response 8» обработчика прерываний

На рисунке 41 показан функциональный блок состояния «Response 15».

Рисунок 41 — Функциональный блок «Response 15» обработчика прерываний

В таблице 44 показаны таблицы перехода состояний обработчика DL на Ведущем узле.

Таблица 44

Таблицы перехода состояний обработчика сообщений на Ведущем узле

7.3.3.5 Конечная машина обработчика сообщений Устройства

На рисунке 42 показана конечная машина обработчика DL на Устройстве.

Рисунок 42 — Конечная машина обработчика сообщений Устройства

В таблице 45 показаны таблицы перехода состояний обработчика DL на Устройстве.

Таблица 45

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

7.3.4 Обработчик Данных процесса

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

Транспортировка выходных PD выполняется, применяя услугу DL_OutputUpdate, а транспортировка входных PD — применяя услугу DL_InputTransport (см. рисунок 26). Цикл PD завершен, когда весь набор PD передан между Ведущим узлом и Устройством в нужном направлении. Данный цикл может потребовать более одной M-последовательности.

Все PD передаются в одной M-последовательности при использовании M-последовательностей типа TYPE_2_x (см. рисунок 37). В данном случае время исполнения цикла PD равно времени цикла tCYC.

7.3.4.2 Режим расслоения

В данном случае все PD и OD передаются с несколькими перемежающимися M-последовательностями типов TYPE_1_1 (PD) и TYPE_1_2 (OD), как показано на рисунке 43. Это демонстрируется сообщениями Ведущего узла, записывающими выходные PD на Устройство. Параметр PDOutAddress услуги показывает расчленение выходных PD, подлежащих передаче (см. 7.2.2.3). Для входных PD параметр PDInAddress услуги соответственно указывает на расчленение входных PD. В цикле PD все входные PD будут считываться вначале с последующими выходными PD, подлежащими записи. Цикл PD включает все времена циклов, требуемых для передачи полных PD.

Рисунок 43 — Режим расслоения для сегментированной передачи PD

Режим расслоения применяется только для устаревших Устройств.

7.3.4.3 Конечная машина обработчика Данных процесса Ведущего узла

На рисунке 44 показана конечная машина обработчика PD Ведущего узла.

Рисунок 44 — Конечная машина обработчика PD Ведущего узла

В таблице 46 показаны таблицы перехода состояний обработчика PD на Ведущем узле.

Таблица 46

Таблицы перехода состояний обработчика PD на Ведущем узле

7.3.4.4 Конечная машина обработчика Данных процесса Устройства

На рисунке 45 показана конечная машина обработчика PD Устройства.

Рисунок 45 — Конечная машина обработчика PD Устройства

См. диаграмму последовательностей на рисунках 65 и 66.

В таблице 47 показаны таблицы перехода состояний обработчика PD на Устройстве.

Таблица 47

Таблицы перехода состояний обработчика PD на Устройстве

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 или обработчика Событий).

7.3.5.2 Конечная машина обработчика Данных запроса Устройства

На рисунке 46 показана конечная машина Ведущего узла обработчика OD.

Рисунок 46 — Конечная машина обработчика OD Ведущего узла

Обработчик OD перенаправляет сервисный примитив ODTrig.ind для содержания следующего сообщения к текущему активному подконтрольному обработчику (ISDU, команд или Событий). Это осуществляется вызовом одной из услуг: ISDUTrig, CommandTrig или EventTrig.

В таблице 48 показаны таблицы перехода состояний обработчика OD на Ведущем узле.

Таблица 48

Таблицы перехода состояний обработчика OD на Ведущем узле

7.3.5.3 Конечная машина обработчика Данных запроса Устройства

Обработчик OD на Устройстве получает информацию по каналу связи и параметр или адрес FlowCTRL через услугу OD.ind. Каналы связи совершенно независимы. В случае правильного доступа соответствующая конечная машина обработчика ISDU, обработчика команд или обработчика Событий адресуется через соответствующий канал связи.

Устройство будет отвечать на запросы чтения из нереализованных диапазонов адресов со значением «0». Оно будет игнорировать запросы записи в нереализованные диапазоны адресов.

На рисунке 47 показана конечная машина обработчика OD на Устройстве.

Рисунок 47 — Конечная машина обработчика OD на Устройстве

В случае доступа ISDU в Устройстве, не поддерживающем ISDU, Устройство будет отвечать «No Service» (Нет обслуживания) (см. таблицу A.12). Сообщение об ошибке не генерируется.

Примечание — Если нет OD, ожидающих передачи, то сообщением по умолчанию является OD.ind (R, ISDU, FlowCTRL = IDLE).

В таблице 49 показаны таблицы перехода состояний обработчика OD на Устройстве.

Таблица 49

Таблицы перехода состояний обработчика OD на Устройстве

7.3.6 Обработчик ISDU

7.3.6.1 Индексированный сервисный блок данных (ISDU)

Общая структура ISDU показана на рисунке 48 и подробно описана в подразделе A.5.

Последовательность элементов соответствует последовательности передачи. Элементы ISDU могут принимать различные формы в зависимости от типа I-Service (см. A.5.2 и таблицу A.12).

ISDU позволяет получать доступ к объектам данных (параметры и команды), подлежащим передаче (см. рисунок 5). Объекты данных адресуются с помощью индекса «Index».

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

7.3.6.2 Передача ISDU

ISDU передается по каналу связи ISDU (см рисунок 7 и A.1.2). Для выполнения такой передачи, как правило, требуется несколько сообщений (сегментация). Ведущий узел передает ISDU, посылая запрос I-Service (Read/Write) Устройству через канал связи ISDU. Затем по данному каналу он получает ответ Устройства.

В канале связи ISDU элемент адреса Address в управляющем октете M-последовательности размещает счетчик (= FlowCTRL). FlowCTRL контролирует поток сегментированных данных (см. A.1.2), подсчитывая элементы ISDU (по модулю 16) во время передачи.

Ведущий узел применяет элемент длины Length из ISDU и FlowCTRL для проверки завершения передачи.

В состоянии Idle_1 значения от 0x12 до 0x1F не будут приводить к ошибке связи.

7.3.6.3 Конечная машина обработчика ISDU на Ведущем узле

На рисунке 49 показана конечная машина обработчика ISDU на Ведущем узле.

Рисунок 49 — Конечная машина обработчика ISDU на Ведущем узле

В таблице 51 показаны таблицы перехода состояний обработчика ISDU на Ведущем узле.

Таблица 51

Таблицы перехода состояний обработчика ISDU на Ведущем узле

7.3.6.4 Конечная машина обработчика ISDU на Устройстве

На рисунке 50 показана конечная машина обработчика ISDU на Устройстве.

Рисунок 50 — Конечная машина обработчика ISDU на Устройстве

В таблице 52 показаны таблицы перехода состояний обработчика ISDU на Устройстве.

Таблица 52

Таблицы перехода состояний обработчика ISDU на Устройстве

7.3.7 Обработчик команд

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

Обработчик команд посылает управляющий код (PDOUTVALID или PDOUTINVALID), содержащийся в сервисном примитиве DL_Control.req, к циклически работающему обработчику сообщений через услугу OD.req и команды Ведущего узла. Обработчик сообщений применяет канал связи страниц.

Допустимые управляющие коды для выходных PD приведены в таблице 53.

Таблица 53

Управляющие коды