ГОСТ Р ИСО 15745-2-2010 Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 2. Эталонное описание систем управления на основе стандарта ИСО 11898

ГОСТ Р ИСО 15745-2-2010

Группа Т58

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

Системы промышленной автоматизации и интеграция

ПРИКЛАДНАЯ ИНТЕГРАЦИОННАЯ СРЕДА ОТКРЫТЫХ СИСТЕМ

Часть 2

Эталонное описание систем управления на основе стандарта ИСО 11898

Industrial automation systems and integration. Open systems application integration framework. Part 2. Reference description for ISO 11898-based control system

ОКС 25.040.40

Дата введения 2011-09-01

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004* "Стандартизация в Российской Федерации. Основные положения"

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

1 ПОДГОТОВЛЕН Научно-техническим центром ИНТЕК на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"

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

4 Настоящий стандарт идентичен международному стандарту ИСО 15745-2:2003* "Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 2. Эталонное описание систем управления на основе стандарта ИСО 11898" (ISO 15745-2:2003 "Industrial automation systems and integration - Open systems application integration framework - Part 2: Reference description for ISO 11898-based control system").

________________

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

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

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

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

Введение

Прикладная интеграционная среда (AIF) определяет элементы и правила, облегчающие:

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

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

ИСО 15745-1 устанавливает общие элементы и правила описания интеграционных моделей и AIP вместе с их профилями компонент - профили процессов, профили обмена информацией и профили ресурсов. Содержание комплекса стандартов ИСО 15745 и структурный вид составных частей AIP показан на рисунке 1 ИСО 15745-1:2003.

Настоящий стандарт расширяет общую AIF, описанную в ИСО 15745-1, путем определения технологических специальных элементов и правил описания как профилей коммуникационных сетей, так и коммуникационных аспектов профилей устройств (приборов), относящихся к системам управления на основе ИСО 11898 (DeviceNet, CANopen).

_______________

DeviceNet - торговая марка Open DeviceNet Vendor Association Inc. Эта информация приведена для удобства пользователей ИСО 15745 и не означает одобрения со стороны ИСО владельца торговой марки или любых его продуктов. Соответствие настоящему стандарту не требует использования торговой марки DeviceNet. Использование торговой марки DeviceNet требует разрешения Open DeviceNet Vendor Association Inc.

CANopen - торговая марка, используемая для описания EH 50325-4. Эта информация приведена для удобства пользователей ИСО 15745 и не означает одобрения со стороны ИСО владельца торговой марки или любых его продуктов. Соответствие настоящему стандарту не требует использования торговой марки CANopen.

В частности, в настоящем стандарте описаны шаблоны технологического специального профиля для профиля устройств (приборов) и профиля коммуникационной сети. В рамках AIP экземпляр профиля устройств (приборов) или экземпляр профиля коммуникационной сети является частью профиля ресурсов, определенного в ИСО 15745-1. Файлы экземпляров XML профиля устройств (приборов) и профиля коммуникационной сети включаются в экземпляр XML профиля ресурсов с использованием файла Profile-Handle_DataType, как установлено в ИСО 15745-1:2003, пункт 7.2.5.

AIF, использующие элементы и правила ИСО 15745-1, могут быть легко интегрированы с профилями компонент, определенными с использованием элементов и правил, установленных в настоящем стандарте.

Настоящий стандарт разработан техническим комитетом ИСО/ТК 184 "Системы промышленной автоматизации и интеграция", подкомитетом ПК 5 "Архитектура, системы связи и интегрированные среды".

Комплекс стандартов ИСО 15745 имеет общее название "Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем" и включает в себя следующие части:

- часть 1. Общее эталонное описание;

- часть 2. Эталонное описание систем управления на основе стандарта ИСО 11898;

- часть 3. Эталонное описание систем управления на основе стандарта МЭК 61158;

- часть 4. Эталонное описание систем управления на основе стандарта Ethernet.

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

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

Примечание - Общие элементы и правила описания интеграционных моделей и профилей интероперабельности прикладных систем с профилями их компонент (профили процессов, профили обмена информации и профили ресурсов) установлены в ИСО 15745-1.

Настоящий стандарт следует использовать вместе с ИСО 15745-1.

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

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

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

ИСО 639-1:2002 Коды для представления названий языков. Часть 1. Двухбуквенный код (ISO 639-1:2002, Codes for the representation of names of languages - Part 1: Alpha-2 code)

ИСО 639-2:1998 Коды для представления названий языков. Часть 2. Трехбуквенный код (ISO 639-2:1998, Codes for the representation of names of languages - Part 2: Alpha-3 code)

ИСО 3166-1:1997 Коды для представления названий стран и единиц их административно-территориального деления. Часть 1. Коды стран (ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions - Part 1: Country code)

ИСО/МЭК 10646-1:2000 Информационные технологии. Универсальный многооктетный кодированный набор символов (UCS). Часть 1. Архитектура и базовая многоязычная плоскость (ISO/IEC 10646-1:2000, Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane)

ИСО 11898:1993 Дорожные транспортные средства. Обмен цифровой информацией. Сеть контроллеров (CAN) для высокоскоростной связи (ISO 11898:1993, Road Vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication)

ИСО 15745-1:2003 Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 1. Общее эталонное описание (ISO 15745-1:2003, Industrial automation and systems integration - Open systems application integration framework - Part 1: Generic reference description)

МЭК 61158 (все части) Передача цифровых данных для измерения и управления. Полевая шина для систем автоматического регулирования и управления технологическими процессами (IEC 61158 (all parts), Digital data communications for measurement and control - Fieldbus for use in industrial control systems)

МЭК 61784-1:2003 Цифровые передачи данных для измерения и управления. Часть 1. Профильные наборы для непрерывного и раздельного производства полевых шин для систем автоматического регулирования и управления технологическими процессами (IEC 61784-1:2003, Digital data communications for measurement and control - Part 1: Profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems)

МЭК 62026-3:2000 Устройства распределительные комплектные низковольтные. Интерфейсы между контроллером и прибором (CDIs). Часть 3. DeviceNETTM (IEC 62026-3:2000, Low-voltage switchgear and controlgear - Controller-device interfaces (CDIs) - Part 3: DeviceNetTM)

EH 50325-4:2002 Подсистема промышленной коммуникации на основе ИСО 11898 (CAN) для интерфейсов контроллер-прибор. Часть 4. CANopen (EN 50325-4:2002, Industrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces - Part 4: CANopen)

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

REC-xml-20001006 Расширяемый язык разметки (XML) 1.0 Второе издание - Рекомендация W3C от 6 октября 2000 г. (REC-xml-20001006, Extensible Markup Language (XML) 1.0 Second Edition - W3C Recommendation 6 October 2000)

REC-xmlschema-1-20010502 Схема XML, Часть 1. Структуры - Рекомедация W3C от 2 мая 2001 (REC-xmlschema-1-20010502, XML Schema. Part 1: Structures - W3C Recommendation 02 May 2001)

REC-xmlschema-2-20010502 Схема XML, Часть 2. Типы данных - Рекомедация W3C от 2 мая 2001 (REC-xmlschema-2-20010502, XML Schema. Part 2: Datatypes - W3C Recommendation 02 May 2001)

RFC 1738:1994 Единый указатель ресурсов (URL) - Целевая группа инженерной поддержки Интернета (IETF), Запрос на комментарий (RFC) (RFC 1738:1994, Uniform Resource Locators (URL) - Internet Engineering Task Force (IETF), Request for Comments (RFC))

RFC 1759:1995 Принтер MIB - Целевая группа инженерной поддержки Интернета (IETF), Запрос на комментарий (RFC) (RFC 1759:1995, Printer MIB - Internet Engineering Task Force (IETF), Request for Comments (RFC))

UML V1.4 OMG - Спецификация для Унифицированного Языка Моделирования (Версия 1.4, сентябрь 2001) (UML V1.4, OMG - Unified Modeling Language Specification (Version 1.4, September 2001))

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

В настоящем стандарте использованы термины и определения по ИСО 15745-1 (приложение А).

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

5 Технологические специальные элементы и правила

5.1 Интеграционные модели и интерфейсы IAS

Разработчик AIP должен создать интеграционную модель с использованием правил, описанных в ИСО 15745-1, а также должен обеспечить, чтобы профили устройства (приборов) и коммуникационных сетей на основе ИСО 11898 (независимо от того, представляют ли они требования к интерфейсам или требования, выводимые из существующих приборов/коммуникационных сетей) включали в себя необходимые интерфейсы IAS. Интерфейсы IAS, включенные в профиль, должны быть идентифицированы в разделе заголовка (см. ИСО 15745-1:2003, пункт 7.2.2).

Примечание - Интерфейсы IAS описаны в ИСО 15745-1:2003 (приложение В).

5.2 Шаблоны профилей

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

Шаблоны технологических специальных профилей на основе ИСО 11898 выводятся из общих шаблонов профилей, установленных в ИСО 15745-1 (раздел 7).

5.2.2 Содержимое и синтаксис

Комплекс стандартов ИСО 15745 устанавливает шаблоны профилей, которые являются XML схемами (REC-xmlschema-1-20010502 и REC-xmlschema-2-20010502) и используют общую основную структуру. Профили устройств (приборов) и коммуникационных сетей, основанные на этих шаблонах, как правило, содержат:

- информацию, необходимую для идентификации подсоединенного прибора;

- описание данных об устройстве (приборе), которые могут быть оценены через сеть;

- описание коммуникационных возможностей, поддерживаемых устройством (прибором);

- дополнительную информацию от продавца.

Однако некоторые технологии, основанные на ИСО 11898, используют специальный унаследованный синтаксис ASCII. Поэтому обратная совместимость, определения шаблонов любой технологии (приложения А, В) включают в себя все или соответствующие поднаборы, а именно:

- шаблоны профилей коммуникационных сетей и устройств (приборов), установленные в ИСО 15745-1;

- шаблон ИСО 15745, инкапсулирующий файлы с унаследованным синтаксисом ASCII ("упаковщик");

- унаследованный синтаксис ASCII.

5.2.3 Заголовок

Заголовок шаблона профилей, установленный в ИСО 15745-1:2003 (пункт 7.2.2), используют для шаблонов технологических специальных профилей ИСО 11898. Каждая технология использует одно или несколько имен для идентификации технологии или ее отдельную компоненту (отдельные компоненты) (см. таблицу 1). Выбранное имя должно храниться в атрибуте ProfileTechnology в разделе заголовка.

Таблица 1 - Имена атрибута ProfileTechnology

5.3 Технологические специальные профили

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

- DeviceNet (см. 6.1);

- CANopen (см. 6.2).

Определения связанных шаблонов профилей даны в приложениях А и В.

6 Профили устройств и коммуникационных сетей для систем управления на основе ИСО 11898

6.1 Протокол DeviceNet

6.1.1 Профиль устройств

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

На рисунке 1 показана диаграмма классов профилей устройств DeviceNet.

Рисунок 1 - Диаграмма классов профилей устройств DeviceNet

Доступные форматы для профилей устройств DeviceNet описаны в А.2 (приложение А).

XML схема, представляющая шаблон профилей устройств DeviceNet, определена в А.2.1.3.3 (приложение А). Имя XML файла этой схемы должно быть "CIP_Device_Profile.xsd".

Примечание - Диаграмма классов профилей устройств DeviceNet, представленная на рисунке 1, определяет основные классы. Эти классы разбиваются на составные части; подробное описание дано в приложении А.

XML схема, представляющая инкапсуляцию унаследованного DeviceNet EDS в шаблон профилей приборов на основе ИСО 15745, определена в А.2.2.2 (приложение А). Имя XML файла этой схемы должно быть "EDS_Device_Profile_wrapper.xsd". Сам унаследованный синтаксис EDS ASCII описан в А.4 (приложение А).

6.1.1.2 Идентичность устройств

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

Эти атрибуты обеспечивают, в частности:

- идентификацию изготовителя (название и идентификационный код);

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

- классификацию устройств;

- место хранения дополнительной информации (например, иконки).

6.1.1.3 Управление устройствами

Класс Управление устройствами (DeviceManager) содержит атрибуты и поддерживает сервисы, используемые для мониторинга и конфигурирования приборов.

Эти атрибуты обеспечивают, в частности:

- модификацию объекта Идентичность DeviceNet;

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

Сервисы позволяют:

- отключить устройство;

- осуществлять поиск атрибутов DeviceManager.

6.1.1.4 Функция устройств

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

Пример - Примерами объектов DeviceFunction являются объекты перегрузки, распознавания присутствия объекта, аналоговых входных данных и дискретных выходных данных.

Примечание - Определение специального класса DeviceFunction в ИСО 15745-2 не установлено.

6.1.1.5 Прикладной процесс

На рисунке 2 показана структура класса Прикладной процесс (ApplicationProcess).

Рисунок 2 - Диаграмма класса ApplicationProcess DeviceNet

Класс Компоновка (Assembly) собирает несколько элементов данных прикладного процесса в один блок для оптимизации коммуникаций. Класс Параметр (Parameter) обеспечивает стандартизованный интерфейс для оценивания отдельных элементов данных прикладного процесса. Класс Группа Параметров (ParameterGroup) устанавливает группы связанных параметров для определенной цели (например, конфигурирование, мониторинг). Класс Компоновка и класс Параметр поддерживают атрибуты и сервисы как на уровне класса, так и на уровне экземпляра.

Классы Assem (Компоновка), Param (Параметр) и Group (Группа) определяют отдельные экземпляры основных классов.

Примечание - Класс Компоновка и класс Параметр соответствуют объектам Компоновка DeviceNet и Параметр. Объект Компоновка полностью определен в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2).

6.1.2 Профиль коммуникационных сетей

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

На рисунке 3 показана структура классов профилей коммуникационных сетей DeviceNet.

Рисунок 3 - Диаграмма классов профилей коммуникационных сетей DeviceNet

Доступные форматы для профилей коммуникационных сетей DeviceNet описаны в А.3 (приложение А).

XML схема, представляющая шаблон профилей коммуникационных сетей DeviceNet, определена в А.3.1.3 (приложение А). Имя XML файла этой схемы должно быть "DNet_CommNet_Profile.xsd".

XML схема, представляющая инкапсуляцию унаследованного DeviceNet EDS в шаблон профилей коммуникационных сетей на основе ИСО 15745, определена в А.3.2.2 (приложение А). Имя XML файла этой схемы должно быть "EDS_CommNet_Profile_wrapper.xsd". Сам унаследованный синтаксис EDS ASCII описан в А.4 (приложение А).

6.1.2.2 Прикладные уровни

Класс Прикладные уровни (ApplicationLayers) DeviceNet представляет составные профили для трех верхних уровней интегрированной OSI модели коммуникационных сетей DeviceNet.

Далее он разбивается на несколько классов, как показано на рисунке 3:

- объект Соединение (ConnectionObject) определяет характеристики, связанные с соединениями, и управление соединениями;

- объект Маршрутизатор сообщений (MessageRouter) определяет характеристики, связанные с внутренней маршрутизацией сообщений в устройстве.

Примечание - Соответствующие объект Соединение и объект Маршрутизатор Сообщений полностью определены в МЭК 62026-3.

6.1.2.3 Транспортные уровни

Класс Транспортные уровни (TransportLayer) DeviceNet представляет составные профили для четырех нижних уровней интегрированной OSI модели коммуникационных сетей DeviceNet.

Далее он разбивается на несколько классов, как показано на рисунке 3:

- физический Уровень DN (DNPhysicalLayer) идентифицирует характеристики физического уровня (например, соединитель, скорость передачи данных в бодах, электрические характеристики);

- канальный Уровень DN (DNLinkLayer) и объект DeviceNet (DeviceNetObject) определяют характеристики, связанные с конфигурированием канального уровня передачи данных и мониторингом;

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

Примечание - Соответствующий объект DeviceNet полностью определен в МЭК 62026-3:2000.

6.1.2.4 Управление сетями

Класс Управление сетями (NetworkManagement) DeviceNet представляет конфигурирование сети и возможности настройки характеристик интеграционной модели коммуникационной сети DeviceNet.

Далее он разбивается на несколько классов, как показано на рисунке 3:

- объект NM-DeviceNet (NM-DeviceNetObject), объект NM-Соединение (NM-ConnectionObject) и Маршрутизатор NM-сообщений (NM-MessageRouter) определяют характеристики, связанные с управлением классов соответствующих объектов.

6.2 Протокол CANopen

6.2.1 Профиль устройств

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

На рисунке 4 показана структура классов профилей устройств CANopen.

Рисунок 4 - Диаграмма классов профилей устройств CANopen

Требуемый формат профилей устройств CANopen описан в В.1 (приложение В). XML схема, представляющая шаблон профилей устройств CANopen, определена в В.1.5.1 (приложение В). Имя XML файла схемы должно быть 'COFDCML.xsd'.

Примечание 1 - Для лучшей читаемости диаграмма классов профилей устройств (DeviceProfile) CANopen разбита на пять диаграмм классов.

Примечание 2 - Все эти классы отображаются в той же ХМL схеме, определенной в В.1.5.1 (приложение В).

Примечание 3 - Диаграммы классов профилей устройств CANopen, показанные на рисунках 4-10, определяют основные классы. Далее некоторые классы разбиваются на составные части; подробное описание дано в приложении В.

6.2.1.2 Идентичность устройств

Класс Идентичность устройств (Deviceldentity) определен на рисунке 5.

Рисунок 5 - Диаграмма класса Идентичность устройств (Deviceldentity)

Класс Deviceldentity должен состоять из дочерних классов, показанных на рисунке 5 и установленных в таблице 2.

Таблица 2 - Разбиение класса объекта Идентичность устройств

6.2.1.3 Управление устройством

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

На рисунке 6 показано представление CANopen класса Управление устройством (DeviсеManager).

Рисунок 6 - Диаграмма класса Управление устройством (DeviceManager)

6.2.1.3.2 Объекты localDataDescriptionList (Список описаний локальных данных), localDataDescription (Описание локальных данных)

Объект localDataDescriptionList должен быть набором объектов localDataDescription. Объект localDataDescription должен описывать объекты данных, используемых только в контексте устройства.

6.2.1.3.3 Объект deviceStructure

6.2.1.3.3.1 Общее представление

Объект deviceStructure должен быть контейнером всех физических объектов устройства. Такой объект может быть каналом (физической или логической точкой ввода/вывода), MAU (Устройством подключения к среде), слотом для подключения дополнительных модулей (как часть устройства) или LED (светоизлучающим диодом).

6.2.1.3.3.2 Объекты channelList (Список каналов), channel (канал)

Объект channelList должен быть набором объектов channel. Эти объекты должны описывать физические или логические точки ввода/вывода устройства.

6.2.1.3.3.3 Объекты MAUList (Список устройств подключения к среде), MAU (Устройство подключения к среде)

Объект MAUList должен быть набором объектов MAU. Эти объекты должны описывать точки доступа к сетевым средам.

6.2.1.3.3.4 Объекты slotList (Список слотов), slot (слот)

Объект slotList должен быть набором объектов slot. Объект slot должен содержать ссылку на описание внешнего обмена профилями устройства CANopen.

Примечание - Слоты используют для описания модульных устройств или отдельных комбинаций устройств.

6.2.1.3.3.5 Объекты indicatorList (Список индикаторов), LEDList (Список светоизлучающих диодов), LED (светоизлучающий диод)

Объект LEDList должен быть набором объектов LED. Этот объект должен описывать LED устройства.

Примечание - Класс indicatorList может быть расширен в последующих изданиях ИСО 15745-2.

6.2.1.3.4 Класс communicationEntity (Коммуникационная сущность)

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

На рисунке 7 дано определение класса communicationEntity.

Рисунок 7 - Диаграмма класса communicationEntity

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

6.2.1.3.4.2 cfgltemList (Список элементов конфигурации)

cfgltemList должен состоять из объектов CANopenDedicatedCfgltem.

6.2.1.3.4.3 CANopenDedicatedCfgltem (специализированный элемент конфигурации CANopen)

CANopenDedicatedCfgltem должен быть набором элементов конфигурации.

Примечание - Определение дополнительных классов элементов конфигурации в ИСО 15745-2 не рассмотрено.

6.2.1.3.4.4 Класс CANopenIdentity (идентичность CANopen)

Класс CANopenIdentity состоит из нескольких объектов, необходимых для идентификации устройства в сети CANopen. Он включает в себя объекты для CANopenVendorlD (идентификатор продавца CANopen), CANopenProductCode (код продуктов CANopen), CANopenRevisionNumber (номер модификации CANopen) и CANopenSerialNumber (серийный номер CANopen), а также CANopenManufacturerDeviceName (название прибора изготовителя CANopen), CANopenManufacturerHardwareVersion (версия аппаратных средств изготовителя CANopen) и CANopenManufacturerSoftwareVersion (версия программных средств изготовителя CANopen).

Примечание - Соответствующий объект идентичности определен в ЕН 50325-4.

6.2.1.3.4.5 CANopenCommunicationFunctionList (Список коммуникационных функций CANopen), function (функция)

CANopenCommunicationFunctionList должен быть набором объектов function (функция). Каждый такой объект описывает функциональные возможности CANopen, связанные с коммуникационной областью CANopen, путем использования CANopenCommunicationParameterList (Список коммуникационных параметров CANopen).

6.2.1.3.4.6 CANopenCommunicationParameterList (Список коммуникационных параметров CANopen), parameters (параметры)

CANopenCommunicationParameterList должен быть набором объектов Параметр. Каждый такой объект описывает параметр, связанный с коммуникационной областью CANopen.

6.2.1.3.4.7 CANopenObjectAccessList (Список доступа к объектам CANopen), CANopenObject (объект CANopen)

CANopenObjectAccessList должен быть набором объектов CANopenObject. Что касается словаря объектов CANopen, каждый такой объект описывает параметр из вида DeviceFunction или из CANopenCommunicationParameterList.

Примечание - CANopenObjectAccessList соответствует словарю объектов CANopen в ЕН 50325-4.

6.2.1.3.5 Класс processingEntity (обрабатываемая Сущность)

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

На рисунке 8 показано определение класса processingEntity.

Рисунок 8 - Диаграмма класса processingEntity

Класс processingEntity должен описывать любое устройство, не являющееся коммуникационным объектом.

Пример - Ресурс, способный выполнять программы.

6.2.1.3.5.2 Классы additionalltemList (Список дополнительных элементов), additionalltem (дополнительный Элемент)

Класс additionalltemList должен быть набором объектов дополнительных элементов, определяемых пользователем. Объект additionalltem может быть использован для описания характеристик приборов, кроме характеристик конфигурации или коммуникационных объектов.

Примечание - Определение additionalltemType дополнительных элементов в настоящем стандарте не рассмотрено.

Пример - Документация по прибору.

6.2.1.3.5.3 Классы logicalConnectionPointList (Список логических точек соединений), logicalConnectionPoint (логическая точка соединения)

Класс logicalConnectionPointList должен быть набором объектов логических точек соединений. Этот объект описывает соединение.

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

6.2.1.3.5.4 Классы logicalConnectionPointAssemblyList (Список наборов логических точек соединений), logicalConnectionPointAssembly (набор логических точек соединений)

Класс logicalConnectionPointAssemblyList должен быть набором объектов logicalConnectionPointAssembly. Этот набор должен быть описанием группы объектов logicalConnectionPoint.

6.2.1.3.5.5 Классы internalConnectionPointList (Список внутренних точек соединений), internalConnectionPoint (внутренняя точка соединения)

Класс internalConnectionPointList должен быть набором объектов internalConnectionPoint, определяющим внутренние соединения между различными объектами communicationEntity и/или объектами resourceEntity в одном и том же устройстве.

6.2.1.3.5.6 Класс cfgltemList (Список элементов конфигурации)

Класс cfgltemList может состоять из объектов dedicatedCfgltem и объектов uncomittedCfgltem.

6.2.1.3.5.7 Элемент dedicatedCfgltem (Специализированный элемент конфигурации)

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

6.2.1.3.5.8 Элемент uncommittedCfgltem (нескоммутированный элемент конфигурации)

uncommittedCfgltem должен быть элементом конфигурации с атрибутом dedicatedCfgltemType. Такой элемент следует использовать для определения характеристик конфигурации, которые не могут быть описаны dedicatedCfgltem.

Примечание - Определение некоммутированных элементов конфигурации в настоящем стандарте не рассмотрено.

Пример - Описание DIP - переключателей, изменяющих код идентификатора прибора.

6.2.1.4 Функция прибора

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

На рисунке 9 приведена диаграмма классов DeviceFunction.

Рисунок 9 - Диаграмма классов DeviceFunction (Функция устройства)

В случае различных представлений функции устройства для описания DeviceFunction используют дополнительную XML схему. Имя XML файла схемы должно быть "FDCMLISO15745DeviceFunction.xsd". XML схема DeviceFunction определена в приложении В.

Примечание - Определение дополнительных XML схем, описывающих классы DeviceFunction, в настоящем стандарте не рассмотрено.

6.2.1.4.2 parameterList (Список параметров), parameter (параметр)

parameterList должен быть набором объектов Параметр. Такой объект описывает параметры устройства на основе функциональной перспективы. Он соединяется с коммуникационным объектом в communicationEntity.

6.2.1.4.3 functionList (Список функций), function (функция), inputsList (Список вводов), outputsList (Список выводов)

functionList должен быть набором объектов function (функция). Такой объект должен состоять из inputsList и outputsList. Эти списки должны содержать список ссылок на объекты Параметр.

6.2.1.5 Прикладной процесс

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

Объект ApplicationProcess (Прикладной процесс) может быть представлен одной или несколькими соответствующими XML схемами.

Примечание - Определение этих XML схем в настоящем стандарте не установлено.

6.2.1.5.2 textualDescription (Текстовое описание)

Объект textualDescription объясняет функцию устройства в читаемом текстовом виде.

6.2.2 Профиль коммуникационных сетей

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

На рисунке 10 показана диаграмма классов профиля коммуникационной сети CANopen.

Рисунок 10 - Диаграмма классов профиля коммуникационной сети CANopen

XML схема, представляющая профиль коммуникационной сети CANopen, определена в приложении В. Имя файла XML схемы должно быть "COCommNetworkProfile.xsd".

6.2.2.2 communicationProfile (Коммуникационный профиль)

communication Profile должен устанавливать подходящие идентификаторы коммуникационных профилей. Эти профили и их идентификаторы определены в МЭК 61784-1 (раздел 10.1). Разработчик AIP может установить дополнительные коммуникационные профили; идентификаторы для таких новых коммуникационных профилей должны быть трехразрядным числом, лежащим между 680 и 699.

6.2.2.3 Транспортные уровни

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

Объект TransportLayers (Транспортные уровни) должен представлять комбинированные профили для четырех нижних уровней интегрированной OSI модели коммуникационных сетей. Этот объект должен включать в себя объект cfgltemList (Список элементов конфигурации).

6.2.2.3.2 Объекты cfgltemList (Список элементов конфигурации), CANopenDedicatedCfgCategory (Специализированная категория конфигураций CANopen)

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

Примечание - CANopenDedicatedCfgCategory описывает поддерживаемые услуги по передаче данных (например, объектов данных технологического процесса или объектов сервисных данных), а также поддерживаемые скорости передачи информации в бодах, как определено в ЕН 60325-4.

6.2.2.4 Прикладные уровни

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

Объект ApplicationLayers (Прикладные уровни) должен представлять комбинированные профили для трех уровней интегрированной OSI модели коммуникационных сетей. Объект ApplicationLayers должен содержать объект cfgltemList.

6.2.2.4.2 Объекты cfgltemList (Список элементов конфигурации), CANopenDedicatedCfgCategory (Специализированная категория конфигурации CANopen)

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

6.2.2.5 Управление сетями

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

Объект NetworkManagement (Управление сетями) должен представлять функциональные возможности управления сетями. Этот объект должен содержать объект cfgltemList.

6.2.2.5.2 Объекты cfgltemList (Список элементов конфигурации), CANopenDedicatedCfgCategory (Специализированная категория конфигураций CANopen)

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

Примечание - Объект CANopenDedicatedCfgCategory определяет поддерживаемые сервисы управления сетями, как установлено в ЕН 50325-4.

Приложение А
(обязательное)

Шаблоны профилей DeviceNet

А.1 Общие положения

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

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

- информацию по приборам, сохраняемую в печатном или электронном формате;

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

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

- комбинации методов, перечисленных выше.

Средства конфигурирования, доступные в настоящее время для устройств на основе CIP, используют специально отформатированный файл ASCII, называемый Электронная Информационная Таблица (EDS), который предоставляет:

- информацию, необходимую для идентификации подключенного устройства;

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

- описание коммуникационных возможностей, поддерживаемых устройством (например, соединения);

- дополнительную информацию от продавца.

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

Информация EDS во многом аналогична информации, необходимой как для профиля коммуникационной сети, так и для профиля устройств, поэтому следующие подклассы устанавливают формат для:

- шаблонов профилей коммуникационной сети и приборов, как определено в ИСО 15745-1;

- инкапсуляции унаследованных файлов EDS в шаблоны ИСО 15745 ("упаковщики");

- унаследованной Электронной Информационной Таблицы (EDS), включая общую семантическую информацию.

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

А.2 Описание шаблонов профилей устройств

А.2.1 Описание шаблонов профилей устройств на основе XML

А.2.1.1 Общие положения

Файлы XML профилей приборов должны соответствовать XML схеме профилей устройств, как установлено в А.2.1.3.3.

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

А.2.1.2 Семантика элементов XML схемы

А.2.1.2.1 ProfileBody (Тело профиля)

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

Семантика этих атрибутов установлена в А.4.1.4.2.

А.2.1.2.2 Deviceldentity (Идентичность устройств)

Данный элемент определяет поддерживаемые атрибуты экземпляра и операции объекта Идентичность (см. МЭК 62026-3), а также дополнительную информацию для полной идентификации устройств. В случае необходимости этот элемент также указывает истинные значения атрибутов экземпляра.

Семантика подэлементов Deviceldentity_lnstanceAttributes элемента Deviceldentity установлена в таблице А.1.

Таблица А.1 - Элементы Deviceldentity_InstanceAttributes

А.2.1.2.3 DeviceManager (Управление устройствами)

Данный элемент определяет поддерживаемые атрибуты классов и операции объекта Identity (Идентичность) (см. МЭК 62026-3), а также дополнительную информацию для управления устройствами. В случае необходимости этот элемент также указывает истинные значения атрибутов экземпляра.

Семантика модульных подэлементов элемента DeviceManager установлена в А.4.1.5.2.

А.2.1.2.4 DeviceFunction (Функция устройств)

В настоящем стандарте содержимое этого элемента не детализировано.

А.2.1.2.5 ApplicationProcess (Прикладной процесс)

А.2.1.2.5.1 Assembly (Компоновка)

Данный элемент устанавливает поддерживаемые атрибуты классов и экземпляров объекта Assembly [см. МЭК 61158-5 и МЭК 61158-6 (тип 2)], а также описание отдельных экземпляров.

Семантика подэлементов Assem, ProxyAssem and ProxiedAssem элемента DeviceManager установлена в А.4.1.4.8 и А.4.1.5.3.2.

А.2.1.2.5.2 Parameter (Параметр)

Данный элемент устанавливает поддерживаемые атрибуты классов и экземпляров и операции объекта Parameter Object, а также описание отдельных экземпляров.

Семантика подэлемента Parameter_ClassAttributes элемента Parameter установлена в А.4.1.4.5.

Семантика подэлементов Param, ProxyParam and ProxiedParam элемента Parameter установлена в А.4.1.4.6 и А.4.1.5.3.1.

А.2.1.2.5.3 ParameterGroup (Группа Параметров)

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

Семантика подэлемента Group элемента ParameterGroup установлена в А.4.1.4.7.

А.2.1.3 XML схемы

А.2.1.3.1 Файл MasterTemplateTypes.xsd

Примечание - XML схема содержит все стили, определенные как часть основного шаблона в ИСО 15745-1.

<?xml version="1.0" encoding="UTF-8" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!- - Target namespaces are not specified in this master template - ->

<xsd:annotation>

<xsd:documentation>* HEADER DATA TYPES *</xsd:documentation>

</xsd:annotation>

<xsd:simpleType name="ProfileClasslD_DataType">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="AIP" />

<xsd:enumeration value="Process" />

<xsd:enumeration value="lnformationExchange" />

<xsd:enumeration value="Resource" />

<xsd:enumeration value="Device" />

<xsd:enumeration value="CommunicationNetwork" />

<xsd:enumeration value="Equipment" />

<xsd:enumeration value="Human" />

<xsd:enumeration value="Material" />

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="ISO15745Reference_DataType">

<xsd:sequence>

<xsd:element name="ISO15745Part" type="xsd:positivelnteger" />

<xsd:element name="ISO15745Edition" type="xsd:positivelnteger" />

<xsd:element name="ProfileTechnology" type="xsd:string" />

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="IASInterface_DataType">

<xsd:union>

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="CSI" />

<xsd:enumeration value="HCI" />

<xsd:enumeration value="ISI" />

<xsd:enumeration value="API" />

<xsd:enumeration value="CMI" />

<xsd:enumeration value="ESI" />

<xsd:enumeration value="FSI" />

<xsd:enumeration value="MTI" />

<xsd:enumeration value="SEI" />

<xsd:enumeration value="USI" />

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:length value="4" />

</xsd:restriction>

</xsd:simpleType>

</xsd:union>

</xsd:simpleType>

<xsd:annotation>

<xsd:documentation>* ISO 15745 DEFINED DATA TYPES *</xsd:documentation>

</xsd:annotation>

<xsd:complexType name="ProfileHandle_DataType">

<xsd:sequence>

<xsd:element name="Profileldentification" type="xsd:string" />

<xsd:element name="ProfileRevision" type="xsd:string" />

<xsd:element name="ProfileLocation" type="xsd:anyURI" minOccurs="0" maxOccurs="1" />

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

A.2.1.3.2 Файл CIPDataTypes.xsd

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

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!- - Target namespaces are not specified in this master template - ->

<xsd:annotation>

<xsd:documentation>* CIP DATA TYPES *</xsd:documentation>

</xsd:annotation>

<xsd:simpleType name="dt_USINT">

<xsd:restriction base="xsd:unsignedByte"/>

</xsd:simpleType>

<xsd:simpleType name="dt_UINT">

<xsd:restriction base="xsd:unsignedShort"/>

</xsd:simpleType>

<xsd:simpleType name="dt_UDINT">

<xsd:restriction base="xsd:unsignedlnt"/>

</xsd:simpleType>

<xsd:simpleType name="dt_ULINT">

<xsd:restriction base="xsd:unsignedLong"/>

</xsd:simpleType>

<xsd:simpleType name="dt_SINT">

<xsd:restriction base="xsd:byte"/>

</xsd:simpleType>

<xsd:simpleType name="dt_INT">

<xsd:restriction base="xsd:short"/>

</xsd:simpleType>

<xsd:simpleType name="dt_DINT">

<xsd:restriction base="xsd:int"/>

</xsd:simpleType>

<xsd:simpleType name="dt_LINT">

<xsd:restriction base="xsd:long"/>

</xsd:simpleType>

<xsd:simpleType name="dt_BYTE">

<xsd restriction base="xsd:hexBinary">

<xsd:maxLength value="1"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="dt_WORD">

<xsd:restriction base="xsd:hexBinary">

<xsd:maxLength value="2"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="dt_DWORD">

<xsd:restriction base="xsd:hexBinary">

<xsd:maxLength value="4"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="dt_LWORD">

<xsd:restriction base="xsd:hexBinary">

<xsd:maxLength value="8"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="dt_REAL">

<xsd:restriction base="xsd:float"/>

</xsd:simpleType>

<xsd:simpleType name="dt_LREAL">

<xsd:restriction base="xsd:double"/>

</xsd:simpleType>

<xsd:simpleType name="dt_EDS_Char_Array">

<xsd:restriction base="xsd:string"/>

</xsd:simpleType>

<xsd:simpleType name="dt_EPATH">

<xsd:list itemType="et_EPATH_item"/>

</xsd:simpleType>

<xsd:simpleType name="dt_STRINGI">

<xsd:restriction base="xsd:string"/>

</xsd:simpleType>

<xsd:simpleType name="dt_EDS_Date">

<xsd:restriction base="xsd:date"/>

</xsd:simpleType>

<xsd:simpleType name="dt_EDS_Time_Of_Day">

<xsd:restriction base="xsd:time"/>

</xsd:simpleType>

<xsd:simpleType name="dt_EDS_Revision">

<xsd:restriction base="xsd:string">

<xsd:pattern value="[0-9]\.[1-9]|[1-9]\.[0-9]|[1-9]\.[1-9]"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="dt_EDS_URL">

<xsd:restriction base="xsd:anyURI">

<xsd:pattern value="http://.*"/>

<xsd:pattern value="ftp://.*"/>

<xsd:pattern value=".*"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="at_AccessType_OptionalGet">

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="None"/>

<xsd:enumeration value="Get"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="at_AccessType_OptionalSet">

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="None"/>

<xsd:enumeration value="Get"/>

<xsd:enumeration value="Set"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="at_AccessType_Mandatory">

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="Get"/>

<xsd:enumeration value="Set"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="et_VendorSpecificKeyword">

<xsd:restriction base="xsd:string">

<xsd:pattern value="[1-9][0-9]{0,4}_([A-Z]|[a-z]|[0-9])([A-Z]|[a-z]|[0-9][_])*"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="et_EPATH_item">

<xsd:union>

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:pattern value="([0-9]|[a-f]|[A-F]){2}"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="SLOT"/>

<xsd:enumeration value="SLOT_MINUS_ONE"/>

<xsd:enumeration value="SYMBOL_ANSI"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:pattem value="Param[1-9][0-9]{0,4}"/>

<xsd:pattern value="\[Param[1-9][0-9]{0,4}\]"/>

<xsd:pattern value="ProxyParam[1-9][0-9]{0,4}"/>

<xsd:pattern value="\[ProxyParam[1-9][0-9]{0,4}\]"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:union>

</xsd:simpleType>

<xsd:simpleType name="et_ParamReference">

<xsd:restriction base="xsd:NMTOKEN">

<xsd:pattern value="Param[1-9][0-9]{0,4}([:][0-9]{1,2})*"/>

<xsd:pattern value="ProxyParam[1-9][0-9]{0,4}([:][0-9]{1,2})*"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="et_AssemReference">

<xsd:restriction base="xsd:NMTOKEN">

<xsd:pattern value="Assem[1-9][0-9]{0,4}"/>

<xsd:pattem value="ProxyAssem[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:attributeGroup name="ag_FileDescription">

<xsd:attribute name="DescText" type="dt_EDS_Char_Array" use="required"/>

<xsd:attribute name="CreateDate" type="dt_EDS_Date" use="required"/>

<xsd:attribute name="CreateTime" type="dt_EDS_Time_Of_Day" use="required"/>

<xsd:attribute name="ModDate" type="dt_EDS_Date" use="optional"/>

<xsd:attribute name="ModTime" type="dt_EDS_Time_Of_Day" use="optional"/>

<xsd:attribute name="Revision" type="dt_EDS_Revision" use="required"/>

<xsd:attribute name="HomeURL" type="dt_EDS_URL" use="optional"/>

<xsd:attribute name="SpecificationConformance" type="dt_EDS_Char_Array" use="required"/>

</xsd:attributeGroup>

</xsd:schema>

A.2.1.3.3 Файл CIP_Device_.Profile.xsd

Примечание - XML схема включает в себя файлы "Master Template Types.xsd" (см. А.2.1.3.1) и "CIPDataTypes.xsd" (см. А.2.1.3.2).

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<!- - Target namespaces are not specified in this master template - ->

<xsd:redefine schemaLocation="MasterTemplateTypes.xsd">

<xsd:complexType name="ISO15745Reference_DataType">

<xsd:complexContent>

<xsd:restriction base="ISO15745Reference_DataType">

<xsd:sequence>

<xsd:element name="ISO15745Part" type="xsd:positivelnteger"/>

<xsd:element name="ISO15745Edition" type="xsd:positivelnteger"/>

<xsd:element name="ProfileTechnology" type="xsd:string" fixed="CIP"/>

</xsd:sequence>

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

</xsd:redefine>

<xsd:include schemaLocation="CIPDataTypes.xsd"/>

<xsd:element name="ISO15745Profile">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="ProfileHeader"/>

<xsd:element ref="ProfileBody"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* HEADER SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileHeader">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Profileldentification" type="xsd:string"/>

<xsd:element name="ProfileRevision" type="xsd:string"/>

<xsd:element name="ProfileName" type="xsd:string"/>

<xsd:element name="ProfileSource" type="xsd:string"/>

<xsd:element name="ProfileClasslD" type="ProfileClasslD_DataType" fixed="Device"/>

<xsd:element name="ProfileDate" type="xsd:date" minOccurs="0"/>

<xsd:element name="Additionallnformation" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="ISO15745Reference" type="ISO15745Reference_DataType"/>

<xsd:element name="IASInterfaceType" type="IASInterface_DataType" minOccurs="0"

maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* BODY SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileBody">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="Deviceldentity"/>

<xsd:element ref="DeviceManager" minOccurs="0"/>

<xsd:element ref="DeviceFunction" maxOccurs="unbounded"/>

<xsd:element ref="ApplicationProcess" minOccurs="0"/>

<xsd:element name="ExternalProfileHandle" type="ProfileHandle_DataType" minOccurs="0/>

</xsd:sequence>

<xsd:attributeGroup ref="ag_FileDescription"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Deviceldentity">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Deviceldentity_lnstanceAttributes">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="VendCode">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_UINT">

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="VendName">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_EDS_Char_Array"/>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="SpecificationConformance" type="dt_EDS_Char_Array"

minOccurs="0"/>

<xsd:element name="ProdType">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_UINT">

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProdTypeStr">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_EDS_Char_Array"/>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProdCode">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_UINT">

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProdRevision">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MajRev" type="dt_USINT"/>

<xsd:element name="MinRev" type="dt_USINT"/>

</xsd:sequence>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Status" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="SerialNumber" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProdName">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="State" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConfigurationConsistencyValue" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Heartbeatlnterval" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalSet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Catalog" type="xsd:string" minOccurs="0"/>

<xsd:element name="lcon" type="xsd:string" minOccurs="0"/>

<xsd:element name="ExcludeFromAdapterRackConnection" type="xsd:string"

minOccurs="0"/>

<xsd:element name="DeviceClassification" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Class" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MainClass">

<xsd:simpleType>

<xsd:union>

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="ControlNet"/>

<xsd:enumeration value="DeviceNet"/>

<xsd:enumeration value="EtherNetlP"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType>

<xsd:restriction base="et_VendorSpecificKeyword"/>

</xsd:simpleType>

</xsd:union>

</xsd:simpleType>

</xsd:element>

<xsd:element name="SubClass" type="xsd:NMTOKEN" minOccurs="0"

maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="Class[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Deviceldentity_lnstanceOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_All">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Reset">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DeviceManager">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Deviceldentity_ClassAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ObjectRevision">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Maxlnstance">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MaxlDCIassAttributes">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="MaxlDlnstanceAttributes">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Deviceldentity_ClassOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_All">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Reset">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Find_Next_Object_lnstance">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Modular" minOccurs="0">

<xsd:complexType>

<xsd:choice>

<xsd:element name="Chassis">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="DefineSlotslnRack" type="dt_UINT"/>

<xsd:element name="SlotDisplayRule" type="et_ParamReference"

minOccurs="0"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Module">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Width" type="dt_UINT"/>

<xsd:element name="Rack" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="VendCode" type="dt_UINT"/>

<xsd:element name="ProdType" type="dt_UINT"/>

<xsd:element name="ProdCode" type="dt_UINT"/>

<xsd:element name="MajRev" type="dt_USINT"/>

<xsd:element name="MinRev" type="dt_USINT"/>

<xsd:element name="LegalSlot" type="dt_UINT"

maxOccurs="unbounded"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="Rack[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

<xsd:element name="ExtemallD" type="dt_EPATH" minOccurs="0"/>

<xsd:element name="GenericlD" type="dt_EPATH" minOccurs="0"/>

<xsd:element name="ExternlDExactMatch" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="Yes"/>

<xsd:enumeration value="No"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="Query" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Path" type="dt_EPATH"/>

<xsd:element name="Service" type="dt_USINT"/>

<xsd:element name="Size">

<xsd:simpleType>

<xsd:restriction base="dt_USINT">

<xsd:minlnclusive value="1"/>

<xsd:maxlnclusive value="16"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="ExternallD" type="dt_EPATH"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DeviceFunction">

<xsd:complexType>

<xsd:sequence>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ApplicationProcess">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Parameter" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Parameter_Class" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Parameter_ClassAttributes">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ObjectRevision" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Maxlnstance">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ParameterClassDescriptor">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Get"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConfigurationAssemblylnstance">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Get"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="NativeLanguage" minOccurs="0">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalSet" use="required"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Parameter_ClassOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_All">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Reset">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Set_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Restore">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Save">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Parameter_lnstance" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Parameter_lnstanceAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ParameterValue">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="LinkPathSize">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="LinkPath">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ParamDescriptor">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="DataType">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="DataSize">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ParameterName">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="UnitsString">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="HelpString">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MinimumValue">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MaximumValue">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="DefaultValue">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ScalingMultiplier">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ScalingDivider">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ScalingBase">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ScalingOffset">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MultiplierLink">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="DivisorLink">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="BaseLink">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="OffsetLink">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="DecimalPrecision">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Parameter_lnstanceOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_All">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Set_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Enum_String">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Param" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_ParamType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattem value="Param[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProxyParam" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_ProxyParamType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="ProxyParam[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProxiedParam" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_ParamType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="ProxiedParam[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Assembly" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Assembly_Class" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Assembly_ClassAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ObjectRevision">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Maxlnstance">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Assembly_ClassOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Create">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Delete">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Assembly_lnstance" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Assembly_lnstanceAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="NumberOfMembers">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalGet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="AssemblyMemberList">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_OptionalSet" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="AssemblyData">

<xsd:complexType>

<xsd:attribute name="Access_Rule"

type="at_AccessType_Mandatory" use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Assembly_lnstanceOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Delete">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Set_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Member">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Set_Member">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="lnsert_Member">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Remove_Member">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Assem" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_AssemType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="Assem[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProxyAssem" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_AssemType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="ProxyAssem[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProxiedAssem" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_AssemType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="ProxiedAssem[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ParameterGroup" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Group" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="NameString" type="dt_EDS_Char_Array"/>

<xsd:element name="NumberOfMembers" type="dt_UINT"/>

<xsd:choice maxOccurs="unbounded">

<xsd:element name="ParameterRef" type="dt_UINT"/>

<xsd:element name="VariantRef" type="xsd:NMTOKEN"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:choice>

</xsd:sequence>

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:ID">

<xsd:pattem value="Group[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:attribute name="SupportedService" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:boolean">

<xsd:pattem value="true|false"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

<xsd:complexType name="et_ParamType">

<xsd:sequence>

<xsd:element name="LinkPathSize" type="dt_USINT" minOccurs="0"/>

<xsd:element name="LinkPath" type="dt_EPATH" minOccurs="0"/>

<xsd:element name="ParamDescriptor" type="dt_WORD"/>

<xsd:element name="DataType">

<xsd:simpleType>

<xsd:union memberTypes="dt_USINT dt_EPATH7>

</xsd:simpleType>

</xsd:element>

<xsd:element name="DataSize" type="dt_USINT"/>

<xsd:element name="ParameterName" type="dt_EDS_Char_Array"/>

<xsd:element name="UnitsString" type="dt_EDS_Char_Array"/>

<xsd:element name="HelpString" type="dt_EDS_Char_Array"/>

<xsd:element name="MinimumValue" minOccurs="0"/>

<xsd:element name="MaximumValue" minOccurs="0"/>

<xsd:element name="DefaultValue" minOccurs="0"/>

<xsd:element name="ScalingMultiplier" type="dt_UINT" minOccurs="0"/>

<xsd:element name="ScalingDivider" type="dt_UINT" minOccurs="0"/>

<xsd:element name="ScalingBase" type="dt_UINT" minOccurs="0"/>

<xsd:element name="ScalingOffset" type="dt_INT" minOccurs="0"/>

<xsd:element name="MultiplierLink" type="dt_UINT" minOccurs="0"/>

<xsd:element name="DivisorLink" type="dt_UINT" minOccurs="0"/>

<xsd:element name="BaseLink" type="dt_UINT" minOccurs="0"/>

<xsd:element name="OffsetLink" type="dtJNT" minOccurs="0"/>

<xsd:element name="DecimalPrecision" type="dt_USINT" minOccurs="0/>

<xsd:element name="lnternationalParameterName" type="dt_EDS_Char_Array" minOccurs="0"/>
<xsd:element name="lntemationalEngineeringUnits" type="dt_EDS_Char_Array" minOccurs="0"/>
<xsd:element name="lntemationalHelpString" type="dt_EDS_Char_Array" minOccurs="0"/>

<xsd:element name="Enum" minOccurs="0">

<xsd:complexType>

<xsd:sequence maxOccurs="unbounded">

<xsd:element name="EnumValue" type="dt_LINT"/>

<xsd:element name="EnumName" type="dt_EDS_Char_Array"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="et_ProxyParamType">

<xsd:complexContent>

<xsd:extension base="et_ParamType">

<xsd:sequence>

<xsd:element name="ProxyParamSizeAdder" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MinimumValue"/>

<xsd:element name="MaximumValue"/>

<xsd:element name="DefaultValue"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="et_AssemType">

<xsd:sequence>

<xsd:element name="AssemblyName" type="dt_EDS_Char_Array" minOccurs="0"/>

<xsd:element name="AssemblyPath" type="dt_EPATH" minOccurs="0"/>

<xsd:element name="AssemblyDataSize" type="dt_UINT" minOccurs="0"/>

<xsd:element name="AssemblyDescriptor" type="dt_WORD" minOccurs="0"/>

<xsd:element name="AssemblyMember" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:choice>

<xsd:element name="MemberSize" type="dt_UINT"/>

<xsd:element name="MemberReference" type="et_MemberReferenceType"/>

<xsd:element name="VariantReference">

<xsd:complexType/>

</xsd:element>

<xsd:choice>

<xsd:sequence>

<xsd:element name="MemberSize" type="dt_UINT"/>

<xsd:element name="MemberReference" type="et_MemberReferenceType"/>

</xsd:sequence>

<xsd:sequence>

<xsd:element name="MemberSize" type="dt_UINT"/>

<xsd:element name="VariantReference">

<xsd:complexType/>

</xsd:element>

</xsd:sequence>

</xsd:choice>

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="et_MemberReferenceType">

<xsd:union memberTypes="et_AssemReference et_ParamReference dt_UDINT dt_EPATH

xsd:NMTOKEN"/>

</xsd:simpleType>

</xsd:schema>

A.2.2 Описание шаблонов профилей устройств - инкапсуляция XML файлов EDS

А.2.2.1 Общие положения

Файлы XML профилей устройств, используемые для инкапсуляции файлов EDS, должны соответствовать XML схеме профилей устройств, как установлено в А.2.2.2.

Семантика подэлементов элемента ExternalProfileHandle, используемого для обращения к имеющемуся файлу EDS, установлена в таблице А.2. В зависимости от значения атрибута WrapperReference к файлу EDS можно обратиться, используя элементы идентификации либо из самого файла EDS, либо из продукта, описанного этой EDS.

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

Таблица А.2 - Элементы ExternalProfileHandle (Внешний Идентификатор Профиля)

Элементы Deviceldentity (Идентичность устройств), DeviceManager (Управление устройствами), DeviceFunction (Функция устройств) и ApplicationProcess (Прикладной процесс) должны быть совместимы с форматами, установленными в А.2.1.3.3.

Примечание 2 - Они могут быть использованы в течение перехода от унаследованного формата EDS к полному формату XML.

А.2.2.2 XML схема: файл EDS_Device_Profile_wrapper.xsd

Примечание - XML схема включает в себя файл "MasterTemplateTypes.xsd" (см. А.2.1.3.1).

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!- - Target namespaces are not specified in this master template - ->

<xsd:redefine schemaLocation="MasterTemplateTypes.xsd">

<xsd:complexType name="ISO15745Reference_DataType">

<xsd:complexContent>

<xsd:restriction base="ISO15745Reference_DataType">

<xsd:sequence>

<xsd:element name="ISO15745Part" type="xsd:positivelnteger"/>

<xsd:element name="ISO15745Edition" type="xsd:positivelnteger"/>

<xsd:element name="ProfileTechnology" type="xsd:string" fixed="EDS"/>

</xsd:sequence>

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

</xsd:redefine>

<xsd:element name="ISO15745Profile">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="ProfileHeader"/>

<xsd:element ref="ProfileBody"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* HEADER SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileHeader">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Profileldentification" type="xsd:string"/>

<xsd:element name="ProfileRevision" type="xsd:string"/>

<xsd:element name="ProfileName" type="xsd:string"/>

<xsd:element name="ProfileSource" type="xsd:string"/>

<xsd:element name="ProfileClasslD" type="ProfileClasslD_DataType" fixed="Device"/>

<xsd:element name="ProfileDate" type="xsd:date" minOccurs="0"/>

<xsd:element name="Additionallnformation" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="ISO15745Reference" type="ISO15745Reference_DataType"/>

<xsd:element name="IASInterfaceType" type="IASInterface_DataType" minOccurs="0"

maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* BODY SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileBody">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Deviceldentity" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:any namespace="##any"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DeviceManager" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:any namespace="##any"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DeviceFunction" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:any namespace="##any"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ApplicationProcess" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:any namespace="##any"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ExternalProfileHandle">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="ProfileHandle_DataType">

<xsd:attribute name="WrapperReference" use="optional" default="FILEINFO">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="FILEINFO"/>

<xsd:enumeration value="DEVICEINFO"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

A.3 Описание шаблонов профилей коммуникационных сетей

А.3.1 Описание шаблонов профилей коммуникационных сетей на основе XML

А.3.1.1 Общие положения

Файлы XML профилей коммуникационных сетей должны соответствовать XML схеме профилей коммуникационных сетей, как установлено в А.3.1.3.

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

А.3.1.2 Семантика элементов XML схемы

А.3.1.2.1 ProfileBody (Тело профиля)

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

Семантика этих атрибутов установлена в А.4.1.4.2.

А.3.1.2.2 ApplicationLayers (Прикладные уровни)

А.3.1.2.2.1 ConnectionObject (Объект соединения)

Данный элемент устанавливает поддерживаемые атрибуты экземпляров и операции Объекта соединения (см. МЭК 62026-3), а также описание отдельных экземпляров соединений и характеристики ввода/вывода.

Элемент ConnectionDescriptions (Описание соединений) идентифицирует экземпляры Объекта Соединения, которые осуществляются в устройстве. Семантика подэлемента Connection (Соединение) установлена в таблице А.3.

Таблица А.3 - Элементы соединений

Семантика элемента IO_Characteristics установлена в А.4.2.4.2.

А.3.1.2.2.2 MessageRouter (Маршрутизатор сообщений)

Данный элемент устанавливает поддерживаемые атрибуты экземпляров и операции Объекта Message Router (Маршрутизатор сообщений) (см. МЭК 62026-3).

А.3.1.2.3 TransportLayers (Транспортные уровни)

А.3.1.2.3.1 DNPhysicalLayer (Физический уровень DN)

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

Семантика его подэлементов установлена в таблице А.4.

Таблица А.4 - Элементы DNPhysicalLayer

А.3.1.2.3.2 DNLinkLayer (Канальный уровень DN)

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

Семантика его подэлементов установлена в таблице А.5.

Таблица А.5 - Элементы DNLinkLayer

А.3.1.2.3.3 Элемент DeviceNetObject

Данный элемент устанавливает поддерживаемые атрибуты экземпляров и операции Объекта DeviceNet (см. МЭК 62026-3).

А.3.1.2.3.4 Порты (Ports)

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

Семантика подэлемента Port элемента Ports установлена в А.4.1.4.10 и А.4.2.2.2.

А.3.1.2.4.1 NetworkManagement (Управление сетями)

Данный элемент устанавливает поддерживаемые атрибуты классов и операции Объекта DeviceNet (см. МЭК 62026-3).

А.3.1.2.4.2 Элемент NM-ConnectionObject (Объект NM-соединения)

Данный элемент устанавливает поддерживаемые атрибуты классов и операции объекта Connection (Соединение) (см. МЭК 62026-3).

А.3.1.2.4.3 Элемент NM-MessageRouter (Маршрутизатор NM-сообщений)

Данный элемент устанавливает поддерживаемые атрибуты классов и операции Объекта Message Router (Маршрутизатор сообщений) (см. МЭК 62026-3).

А.3.1.3 XML схема: файл DNet_CommNet_Profile.xsd

Примечание - XML схема включает в себя файлы "MasterTemplateTypes.xsd" (см. А.2.1.3.1) и "CIPDataTypes.xsd" (см. А.2.1.3.2).

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<!- - Target namespaces are not specified in this master template - ->

<xsd:redefine schemaLocation="MasterTemplateTypes.xsd">

<xsd:complexType name="ISO15745Reference_DataType">

<xsd:complexContent>

<xsd:restriction base="ISO15745Reference_DataType">

<xsd:sequence>

<xsd:element name="ISO15745Part" type="xsd:positivelnteger" fixed="2"/>

<xsd:element name="ISO15745Edition" type="xsd:positivelnteger" fixed="1"/>

<xsd:element name="ProfileTechnology" type="xsd:string" fixed="DeviceNet"/>

</xsd:sequence>

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

</xsd:redefine>

<xsd:include schemaLocation="CIPDataTypes.xsd"/>

<xsd:element name="ISO15745Profile">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="ProfileHeader"/>

<xsd:element ref="ProfileBody"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* HEADER SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileHeader">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Profileldentification" type="xsd:string"/>

<xsd:element name="ProfileRevision" type="xsd:string"/>

<xsd:element name="ProfileName" type="xsd:string"/>

<xsd:element name="ProfileSource" type="xsd:string"/>

<xsd:element name="ProfileClasslD" type="ProfileClasslD_DataType"

fixed="CommunicationNetwork"/>

<xsd:element name="ProfileDate" type="xsd:date" minOccurs="0"/>

<xsd:element name="Additionallnformation" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="ISO15745Reference" type="ISO15745Reference_DataType"/>

<xsd:element name="IASInterfaceType" type="IASInterface_DataType" fixed="CSI"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* BODY SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileBody">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="ApplicationLayers"/>

<xsd:element ref="TransportLayers"/>

<xsd:element ref="NetworkManagement" minOccurs="0"/>

</xsd:sequence>

<xsd:attributeGroup ref="ag_FileDescription"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ApplicationLayers">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="ConnectionObject"/>

<xsd:element ref="MessageRouter"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="TransportLayers">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="DNPhysicalLayer"/>

<xsd:element ref="DNLinkLayer"/>

<xsd:element ref="DeviceNetObject"/>

<xsd:element ref="Ports" minOccurs="0"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="NetworkManagement">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="NM-DeviceNetObject"/>

<xsd:element ref="NM-ConnectionObject" minOccurs="0"/>

<xsd:element ref="NM-MessageRouter" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConnectionObject">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ConnectionObject_lnstanceAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="State">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="lnstanceType">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="TransportClassTrigger">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProducedConnectionlD">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConsumedConnectionlD">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="lnitialCommCharacteristics">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProducedConnectionSize">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConsumedConnectionSize">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ExpectedPacketRate">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="WatchdogTimeoutAction">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProducedConnectionPathLength">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProducedConnectionPath">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConsumedConnectionPathLength">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConsumedConnectionPath">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory"

use="required" fixed="Set"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ProductionlnhibitTime">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalSet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConnectionObject_lnstanceOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Reset">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Delete">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Apply_Attributes">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService" fixed="true"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Set_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element ref="ConnectionDescriptions" minOccurs="0"/>

<xsd:element name="IO_Characteristics" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="IO_lnfo" type="et_IOInfoType"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConnectionDescriptions">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Connection" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="lnstanceType">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="ExplicitMessage"/>

<xsd:enumeration value="PolledlO"/>

<xsd:enumeration value="BitStrobedlO"/>

<xsd:enumeration value="DynamiclO"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="ProductionTrigger">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="Cyclic"/>

<xsd:enumeration value="ChangeOfState"/>

<xsd:enumeration value="ApplicationTriggered"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="TransportType">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="Server"/>

<xsd:enumeration value="Client"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="TransportClass">

<xsd:simpleType>

<xsd:restriction base="dt_SINT">

<xsd:enumeration value="0"/>

<xsd:enumeration value="2"/>

<xsd:enumeration value="3"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="ProducedConnectionSize" type="dt_UINT"/>

<xsd:element name="ConsumedConnectionSize" type="dt_UINT"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="MessageRouter">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MessageRouter_lnstanceAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Object_List">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="MaximumConnectionSupported">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_UINT">

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="NumberActiveConnections">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_UINT">

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="ActiveConnectionList">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="dt_UINT">

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="MessageRouter_lnstanceOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_All">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DNPhysicalLayer">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Connectors" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="ConnectorType">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="OpenHardWired"/>

<xsd:enumeration value="OpenPluggable"/>

<xsd:enumeration value="SealedMini"/>

<xsd:enumeration value="SealedMicro"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

<xsd:element name="LEDs" minOccurs="0">

<xsd:complexType>

<xsd:attribute name="Module" type="xsd:NMTOKEN"/>

<xsd:attribute name="Network" type="xsd:NMTOKEN"/>

<xsd:attribute name="Combo_ModNet" type="xsd:NMTOKEN"/>

<xsd:attribute name="IO" type="xsd:NMTOKEN"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Baud_Rate_Setting" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="BR_125Kbits" minOccurs="0">

<xsd:complexType>

<xsd:attribute ref="Supported"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="BR_250Kbits" minOccurs="0">

<xsd:complexType>

<xsd:attribute ref="Supported"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="BR_500Kbits" minOccurs="0">

<xsd:complexType>

<xsd:attribute ref="Supported"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="SwitchType" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="DipSwitch"/>

<xsd:enumeration value="Other"/>

<xsd:enumeration value="SoftwareOnly"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

<xsd:attribute name="SoftwareSettable" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:boolean">

<xsd:pattern value="true"/>

<xsd:pattern value="false"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

<xsd:element name="ElectricalCharacteristics" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MaxNetworkPowerConsumption" type="dt_REAL"/>

</xsd:sequence>

<xsd:attribute name="lsolatedPhysicalLayer">

<xsd:simpleType>

<xsd:restriction base="xsd:boolean">

<xsd:pattern value="true"/>

<xsd:pattern value="false"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

<xsd:element name="Other" type="xsd:string" minOccurs="0"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DNLinkLayer">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MAC-IDSetting" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="DefaultMAC-ID" type="et_MAC-IDRange" minOccurs="0"/>

</xsd:sequence>

<xsd:attribute name="SwitchType" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="DipSwitch"/>

<xsd:enumeration value="Other"/>

<xsd:enumeration value="SoftwareOnly"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

<xsd:attribute name="SoftwareSettable" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:boolean">

<xsd: pattern value="true"/>

<xsd:pattem value="false"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

<xsd:element name="PredefinedMasterSlaveConnectionSet" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="NotSupported"/>

<xsd:enumeration value="Group2Client"/>

<xsd:enumeration value="Group2Server"/>

<xsd:enumeration value="Group2ClientServer"/>

<xsd:enumeration value="GroupOnly2Client"/>

<xsd:enumeration value="GroupOnly2Server"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="DynamicConnectionSupport" minOccurs="0">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="NotSupported"/>

<xsd:enumeration value="Group1 "/>

<xsd:enumeration value="Group2"/>

<xsd:enumeration value="Group3"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="FragmentedExplicitMessaging" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="TransmissionTimeout" type="dt_UINT" minOccurs="0"/>

<xsd:element name="TypicalTargetAddress" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Class" type="dt_USINT" minOccurs="0"/>

<xsd:element name="lnstance" type="dt_USINT" minOccurs="0"/>

<xsd:element name="Attribute" type="dt_USINT" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute ref="Supported"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DeviceNetObject">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="DeviceNetObject_lnstanceAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MAC_ID">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalSet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Baud_Rate">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalSet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="BOI">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalSet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Bus_Off_Counter">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalSet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Allocation_lnformation">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MAC_ID_Switch_Changed">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Baud_Rate_Switch_Changed">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MAC_ID_Switch_Value">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Baud_Rate_Switch_Value">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DeviceNetObject_lnstanceOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Set_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Allocate_MS_Connection_Set">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Release_Group2_ldentifier_Set">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Ports">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Port" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="PortTypeName">

<xsd:simpleType>

<xsd:union>

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="ControlNet"/>

<xsd:enumeration value="ControlNet_Redundant"/>

<xsd:enumeration value="TCP"/>

<xsd:enumeration value="DeviceNet"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType>

<xsd:restriction base="et_VendorSpecificKeyword"/>

</xsd:simpleType>

</xsd:union>

</xsd:simpleType>

</xsd:element>

<xsd:element name="PortName" type="dt_EDS_Char_Array" minOccurs="0"/>

<xsd:element name="PortObject" type="dt_EPATH" minOccurs="0"/>

<xsd:element name="PortNumber" type="dt_UINT"/>

<xsd:element name="PortSpecific">

<xsd:complexType>

<xsd:sequence>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="Port[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="NM-DeviceNetObject">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="DeviceNetObject_ClassAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ObjectRevision">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_Mandatory" fixed="Get"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="DeviceNetObject_ClassOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="NM-ConnectionObject">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ConnectionObject_ClassAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ObjectRevision">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ConnectionObject_ClassOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Reset">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Create">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Delete">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Find_Next_Object_lnstance">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="NM-MessageRouter">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MessageRouter_ClassAttributes" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ObjectRevision">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="OptionalAttributeList">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="OptionalServiceList">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MaxlDCIassAttributes">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MaxlDlnstanceAttributes">

<xsd:complexType>

<xsd:attribute name="Access_Rule" type="at_AccessType_OptionalGet"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="MessageRouter_ClassOperations" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Get_Attribute_All">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Get_Attribute_Single">

<xsd:complexType>

<xsd:attribute ref="SupportedService"/>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:attribute name="SupportedService" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:boolean">

<xsd: pattern value="true|false"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

<xsd:attribute name="Supported" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:boolean">

<xsd: pattern value="true|false"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

<xsd:simpleType name="et_MAC-IDRange">

<xsd:restriction base="xsd:nonNegativelnteger">

<xsd:maxlnclusive value="63"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="et_SpecificlOlnfoType">

<xsd:sequence>

<xsd:element name="CompatiblelOTypeMask" type="dt_WORD"/>

<xsd:element name="DefaultProducingConnection" type="dt_UINT"/>

<xsd:element name="DefaultConsumingConnection" type="dt_UINT"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="et_GenericlOlnfoType">

<xsd:sequence>

<xsd:element name="Size" type="dt_UINT"/>

<xsd:element name="NumberSignificantBits" type="dt_UINT"/>

<xsd:element name="CompatiblelOTypeMask" type="dt_WORD"/>

<xsd:element name="Name_String" type="dt_EDS_Char_Array"/>

<xsd:element name="ConnectionPathSize" type="dt_UINT"/>

<xsd:element name="Path" type="dt_EPATH"/>

<xsd:element name="Help_String" type="dt_EDS_Char_Array"/>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="et_IOInfoType">

<xsd:sequence>

<xsd:element name="Default">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="DefaultlOTypeMask" type="dt_WORD"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="Polllnfo" type="et_SpecificlOlnfoType" minOccurs="0"/>

<xsd:element name="Strobelnfo" type="et_SpecificlOlnfoType" minOccurs="0"/>

<xsd:element name="MulticastPolllnfo" type="et_SpecificlOlnfoType" minOccurs="0"/>

<xsd:element name="COSInfo" type="et_SpecificlOlnfoType" minOccurs="0"/>

<xsd:element name="Cycliclnfo" type="et_SpecificlOlnfoType" minOccurs="0"/>

<xsd:element name="lnput" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_GenericlOlnfoType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd: restriction base="xsd:ID">

<xsd:pattern value="lnput[1-9][0-9]{0,4}"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="Output" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="et_GenericlOlnfoType">

<xsd:attribute name="id" use="required">

<xsd:simpleType>

<xsd:restriction base="xsd:ID">

<xsd:pattem value="Output[1-9][0-9]{0,4}7>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

A.3.2 Описание шаблонов профилей коммуникационных сетей. XML инкапсуляция файлов EDS

А.3.2.1 Общие положения

Файлы XML профилей коммуникационных сетей, используемые для инкапсуляции файлов EDS, должны соответствовать XML схеме профилей коммуникационных сетей, как установлено в А.3.2.2.

Семантика подэлементов элемента ExternalProfileHandle, используемого для обращения к имеющемуся файлу EDS, установлена в таблице А.2. В зависимости от значения атрибута WrapperReference к файлу EDS можно обратиться, используя элементы идентификации либо из самого файла EDS, либо из продукта, описанного этой EDS.

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

А.3.2.2 XML схема: файл EDS_CommNet_Profile_wrapper.xsd (см. А.2.1.3.1)

Примечание - XML схема включает в себя файл "MasterTemplateTypes.xsd" (см. А.2.1.3.1).

<?xml version-"1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!- - Target namespaces are not specified in this master template - ->

<xsd:redefine schemaLocation="MasterTemplateTypes.xsd">

<xsd:complexType name="ISO15745Reference_DataType">

<xsd:complexContent>

<xsd:restriction base="ISO15745Reference_DataType">

<xsd:sequence>

<xsd:element name="ISO15745Part" type="xsd:positivelnteger"/>

<xsd:element name="ISO15745Edition" type="xsd:positivelnteger"/>

<xsd:element name="ProfileTechnology" type="xsd:string" fixed="EDS"/>

</xsd:sequence>

</xsd:restriction>

</xsd:complexContent>

</xsd:complexType>

</xsd:redefine>

<xsd:element name="ISO15745Profile">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="ProfileHeader"/>

<xsd:element ref="ProfileBody"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* HEADER SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileHeader">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Profileldentification" type="xsd:string"/>

<xsd:element name="ProfileRevision" type="xsd:string"/>

<xsd:element name="ProfileName" type="xsd:string"/>

<xsd:element name="ProfileSource" type="xsd:string"/>

<xsd:element name="ProfileClasslD" type="ProfileClasslD_DataType"

fixed="CommunicationNetwork"/>

<xsd:element name="ProfileDate" type="xsd:date" minOccurs="0"/>

<xsd:element name="Additionallnformation" type="xsd:anyURI" minOccurs="0"/>

<xsd:element name="ISO15745Reference" type="ISO15745Reference_DataType"/>

<xsd:element name="IASInterfaceType" type="IASInterface_DataType" fixed="CSI"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:annotation>

<xsd:documentation>* BODY SECTION *</xsd:documentation>

</xsd:annotation>

<xsd:element name="ProfileBody">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ExtemalProfileHandle">

<xsd:complexType>

<xsd:complexContent>

<xsd:extension base="ProfileHandle_DataType">

<xsd:attribute name="WrapperReference" use="optional" default="FILEINFO">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="FILEINFO"/>

<xsd:enumeration value="DEVICEINFO"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

A.4 Электронная информационная таблица EDS

A.4.1 Общие требования к EDS на основе CIP

А.4.1.1 Общие положения

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

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

Файл EDS определяется как файл ASCII, который включает представление ASCII объектов в устройстве, которые могут быть оценены из сети [например, Parameter (Параметр) и Assembly (Компоновка)], и дополнительную информацию, необходимую для поддержки адресации объектов.

А.4.1.2 Содержимое EDS

А.4.1.2.1 Структура EDS

Один файл должен содержать всю EDS. EDS должна состоять из разделов. Таблица А.6 описывает структуру разделов, которые являются общими для нескольких сетей на основе CIP, соответствующие разрешенные разделители разделов и порядок следования этих разделов в EDS.

Таблица А.6 - Структура файла EDS CIP

Содержимое электронной информационной таблицы (EDS) должно быть организовано следующим образом:

- все файлы EDS должны содержать раздел Описание файла, который должен быть первым разделом файла EDS и должен использовать разрешенный разделитель [File];

- все файлы EDS должны содержать раздел Описание устройства, который должен сразу же следовать за разделом Описание файла и должен использовать разрешенный разделитель [Device];

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

- дополнительный раздел (дополнительные разделы), относящийся (относящиеся) к продавцу, должен (должны) использовать разрешенный разделитель (разрешенные разделители) [VendorlD_vendorspecifickeyword], установленный (установленные) в А.4.1.2.2.11, и должен (должны) быть расположен (расположены) после всех разделов, установленных в данной спецификации.

А.4.1.2.2 Правила форматирования EDS

А.4.1.2.2.1 Общие положения

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

А.4.1.2.2.2 Пробелы в EDS

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

Интерпретатор EDS должен рассматривать нижеприведенные символы как символы пробелов. Эти символы, считываемые интерпретатором, но не кодированные как символы, читаемые человеком, указывают на наличие в файле пробела:

- знак пробела;

- новая строка;

- возврат каретки;

- перевод строки;

- табуляция, вертикальная и горизонтальная;

- перевод страницы;

- метка конца файла;

- комментарии.

А.4.1.2.2.3 Символы ключевых слов

Все ключевые слова в файле EDS должны состоять из символов ASCII из следующего списка:

- прописные буквы А-Z;

- строчные буквы а-z;

- цифры 0-9;

- специальный символ подчеркивания "_";

- символ пробела.

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

А.4.1.2.2.4 Разделы

Файл EDS должен разделяться на обязательные и дополнительные разделы.

А.4.1.2.2.5 Разделители разделов

Каждый раздел в EDS должен быть надлежащим образом разделен ключевым словом раздела в квадратных скобках (Legal Delimiter). Допустимые разрешенные разделители разделов должны соответствовать разделителям, установленным в таблице А.6.

А.4.1.2.2.6 Ключевые слова разделов

Каждое ключевое слово раздела определяется текстом между началом разделителя ключевого слова раздела "[" и конечным разделителем "]". Символы, используемые в ключевых словах раздела, определены в А.4.1.2.2.3. Имеются два типа ключевых слов раздела, общедоступные ключевые слова и ключевые слова продавца.

А.4.1.2.2.7 Последовательность разделов

Каждый обязательный раздел должен располагаться в требуемом порядке, как установлено в А.4.1.2. Дополнительные разделы могут целиком пропускаться или включаться с пустыми символами - заменителями данных. За исключением раздела (разделов), относящегося (относящихся) к продавцу, дополнительные разделы могут располагаться в любом порядке. Раздел (разделы), относящийся (относящиеся) к продавцу, должен (должны) быть последним (последними) в файле EDS.

А.4.1.2.2.8 Ввод

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

А.4.1.2.2.9 Ключевые слова ввода

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

А.4.1.2.2.10 Общедоступное ключевое слово

Общедоступное ключевое слово должно всегда определяться в спецификации CIP ответственными ассоциациями продавцов. Общедоступное ключевое слово никогда не должно начинаться с цифры.

А.4.1.2.2.11 Ключевые слова продавца

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

А.4.1.2.2.12 Поля вводов

Каждый ввод должен содержать одно или несколько полей. Разделители в виде запятой должны разделять все поля. Значение поля (полей) должно зависеть от контекста раздела. Поля ввода являются либо обязательными, либо дополнительными, как установлено в этой спецификации. Пробелы и пустоты между запятыми должны быть использованы для непредставленных дополнительных полей. Точка с запятой может быть использована для указания отсутствия замыкающих дополнительных полей. Термин "номер поля" должен указывать положение поля ввода. Поля следует нумеровать слева направо (или сверху вниз), начиная с номера 1.

А.4.1.2.2.13 Ключевые слова полей

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

А.4.1.2.2.14 Составные поля данных

Некоторые поля ввода следует устанавливать с использованием данных, которые не могут быть определены одним значением между разделителями в виде запятой. Возможность дополнительного разделения всего поля определяют путем использования одного или нескольких наборов символов в виде парных фигурных скобок "{" и "}". Содержимое между этими символами следует рассматривать как один элемент или ввод. Содержимое может быть сгруппировано в множестве фигурных скобок.

А.4.1.2.2.15 Комментарии

Комментарии должны разделяться символом в виде знака доллара ($) и символом новой строки. Интерпретатор EDS должен рассматривать все символы между разделителями комментариев как пробелы. Разделитель комментария $, обнаруживаемый внутри поля или набора символов в виде двойных кавычек, не должен рассматриваться как разделитель комментариев.

Пример - Ниже приводятся примеры некоторых комментариев:

A.4.1.2.2.16 Пример структуры форматирования EDS

Примеры на рисунке А.1 показывают структуру электронной информационной таблицы.

Рисунок А.1 - Пример структуры форматирования EDS (информативный)

А.4.1.2.3 Требования к имени файла

Соглашения по присвоению имени файлам не принимаются для дисковых файлов EDS, за исключением файлов в среде DOS/Windows: эти файлы должны иметь суффикс ".EDS", приписываемый к имени файла.

А.4.1.3 Требования к кодированию данных EDS

А.4.1.3.1 Общие положения

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

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

Элементарные типы данных, установленные в спецификации CIP, также используются для других элементов EDS, однако значение изменяется, как описано в последующих подразделах (см. А.4.1.3.3-А.4.1.3.10).

Некоторые типы данных используются только в файлах EDS (см. А.4.1.3.11-А.4.1.3.14).

А.4.1.3.2 Соглашение по файлу символов ASCII

Все данные в EDS должны кодироваться с использованием 8-битных символов ASCII, где все ссылки на символы ASCII означают 8-битный формат символов ASCII (как установлено в таблицах 1 и 2, строка 00 ИСО/МЭК 10646-1). Символы, которые не могут быть воспроизведены на терминале ANSI, не должны использоваться в именах идентификатора или в представлениях данных. Правильные значения символов ASCII должны включать в себя новую строку, табуляцию и значения от 32 до 126 в десятичной системе счисления.

А.4.1.3.3 Соглашение по строке символов - EDS_Char_Array

А.4.1.3.3.1 Общие положения

Все строковые данные в файле EDS должны быть строками символов фиксированной длины без символа конца строки и должны заключаться в двойные кавычки (EDS_Char_Array data type).

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

Пример 1 - "Это результат в строке, состоящей из 8-битных символов".

Пример 2 - L "Строка символов UNICODE, включающая греческий символ Pi\u03C0".

Примечание - Текст \u03C0 определяет одиночный 16-битный символ со значением 03С0. В наборе символов UNICODE это соответствует таблице 9, строка 3, Basic Greek - символ нижнего регистра. Описания управляющей последовательности символов даны в А.4.1.3.3.5.

А.4.1.3.3.2 Действия в случае недостаточного количества символов в поле строки

Интерпретатор EDS должен использовать выравнивание символов в поле по правому знаку и заполнить неустановленные символы пробелами в начале строки текста (ASCII 0x20) для остающейся длины строки.

Пример - Если параметр имеет максимальную длину строки 8 и вмещает строку "123АВ", строка интерпретируется как "~~~123АВ", где символы тильда (~) представляют пробелы.

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

Если заданное поле строки содержит слишком много символов, интерпретатор EDS должен отсечь символы слева направо.

Пример - Если параметр имеет максимальную длину строки 8 и вмещает строку "I23ABCDEFG", строка отсекается и интерпретируется как "I23ABCDE".

А.4.1.3.3.4 Конкатенация строки

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

Строки также могут находиться на отдельных строках текста.

Пример 2 -

Следующие строки:

также интерпретируются как: "ABC123XYZ"

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

Пример 3 - L "ABC" "123" "XYZ" - то же самое, что и L "ABC123XYZ".

А.4.1.3.3.5 Управляющие последовательности строк

Интерпретатор EDS должен опознавать все управляющие последовательности, перечисленные в таблице А.7. Интерпретация зависит от приложения.

Таблица А.7 - Управляющие последовательности строк

Если встречаются с последовательностью, не указанной выше, интерпретирующее устройство должно отвергнуть целую строку и указать ошибку. Файлы EDS должны содержать только управляющие последовательности, установленные в таблице А.7.

А.4.1.3.4 Соглашение по строкам ASCII (STRING, SHORT_STRING, STRING2)

Все типы строковых данных (STRING, SHORT_STRING, STRING2), используемые в атрибутах объектов, должны преобразовываться в файл EDS EDS_Char_Array.

А.4.1.3.5 STRINGI

Тип данных Международной строки (STRINGI) CIP кодируется в файле EDS как представление сложного типа данных. Все содержимое ввода STRINGI должно заключаться в пару фигурных скобок. После числа языковых элементов, установленных как USINT, должны следовать определения языковых элементов, причем каждый такой элемент заключается в пару фигурных скобок и разделяется запятой. Каждый языковой элемент ввода STRINGI должен определяться в виде четырех полей. Первое поле (выбор языка) должно представлять собой точно три символьные строки фиксированной длины, заключенные в двойные кавычки, - код языка, установленный в ИСО 639-2/Т. Тип строковых данных должен быть представлен с использованием кода типа данных, как установлено в спецификации CIP для STRING, STRING2, STRINGN или SHORT_STRING. Выбор набора символов должен быть представлен как UINT, как установлено в Кодах принтера IANA MIB (RFC 1759). Часть содержимого строки языкового элемента должна быть представлена как строка или длинная строка.

Пример - Ниже представлен ввод STRINGI на трех языках:

A.4.1.3.6 Маршрут CIP (EPATH)

Тип данных CIP (EPATH), используемый, в частности, для определения строк маршрута CIP, должен кодироваться в файлах EDS с использованием базового формата, установленного в настоящем стандарте для файла EDS_Char_Array. Кроме того, содержимое строки для маршрута CIP или других данных ЕРАТН должно состоять из групп двух соседних шестнадцатеричных символов, разделенных пробелами. Могут быть использованы как верхний регистр, так и нижний регистр.

Пример 1 - "20 04 24 01"

Пример 2 - "20 05 24 02 30 04"

А.4.1.3.7 Соглашение по целым числам без знака ASCII (USINT, UINT, UDINT, ULINT)

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

В десятичной системе счисления не следует использовать впередиидущие нули, но они могут быть использованы в шестнадцатеричной системе счисления. В шестнадцатеричной системе счисления могут быть использованы как верхний регистр, так и нижний регистр, а общее число символов для типа ULINT должно ограничиваться числом 10 (0х плюс еще 8) или 18 (0х плюс еще 16).

Пример - Десятичное значение UINT 254 может быть представлено как 254 (в десятичной системе счисления) или как 0xFE (в шестнадцатеричной системе счисления), а 0254 (десятичная система счисления) и 0x0000000FE (шестнадцатеричная система счисления) являются недопустимыми.

А.4.1.3.8 Соглашение по целым числам со знаком ASCII (SINT, INT, DINT, LINT)

Типы данных SINT, INT, DINT и LINT представляют значения целочисленных данных со знаком. Целочисленные данные со знаком следует вводить либо в десятичной системе счисления, либо в шестнадцатеричной системе счисления с пробелами или запятыми между символами. Если для представления целочисленных символов со знаком используют шестнадцатеричную систему счисления, последовательность двух символов 0х без пробела должна предшествовать целочисленной последовательности символов.

- диапазон разрешенных данных LINT:

- десятичная система счисления

- 9223372036854775808-9223372036854775807

- шестнадцатеричная система счисления

0x8000000000000000-0x7FFFFFFFFFFFFFFF

В десятичной системе счисления не следует использовать впередиидущие нули, но они могут быть использованы в шестнадцатеричной системе счисления. В шестнадцатеричной системе счисления могут быть использованы как верхний регистр, так и нижний регистр, а общее число символов для типа LINT должно ограничиваться числом 10 (0х плюс еще 8) или 18 (0х плюс еще 16).

Пример - Десятичное значение INT254 может быть представлено как 254 (в десятичной системе счисления) или как -0xFE (в шестнадцатеричной системе счисления) или как 0x000000FE (в шестнадцатеричной системе счисления), а 0254 (десятичная система счисления) и 0x0000000FE (шестнадцатеричная система счисления) являются недопустимыми.

А.4.1.3.9 Соглашение по словам ASCII (BYTE, WORD, DWORD, LWORD)

Типы данных BYTE, WORD, DWORD и LWORD представляют значения с побитовой адресацией. Эти значения считают дискретными значениями позиции двоичного разряда, и они не предназначены для представления целочисленных значений со знаком или без знака. Однако для удобства эти значения должны быть введены в десятичной, шестнадцатеричной или двоичной системе счисления без пробелов или запятых между символами. Если для представления целочисленных символов используют шестнадцатеричную (соответственно двоичную) систему счисления, последовательность двух символов 0х (соответственно 0b) без пробела должна предшествовать символам значений.

диапазон разрешенных данных BYTE:

0b0000000000000000000000000000000000000000000000000000000000000000-
0b11111111111111111111111111111111111111111111111111111111111111111

В десятичной системе счисления не следует использовать впередиидущие нули, но они могут быть использованы в шестнадцатеричной и двоичной системах счисления. В шестнадцатеричной системе счисления могут быть использованы как верхний регистр, так и нижний регистр, а общее число символов для типа LWORD должно ограничиваться числом 10 (0х плюс еще 8) или 18 (0х плюс еще 16).

Пример - Десятичное значение WORD 254 может быть представлено как 254 (в десятичной системе счисления) или как 0xFE (в шестнадцатеричной системе счисления), или как 0x000000FE (в шестнадцатеричной системе счисления), а 0254 (в десятичной системе счисления) и 0x0000000FE (в шестнадцатеричной системе счисления) являются недопустимыми.

А.4.1.3.10 Соглашение по плавающей точке ASCII (REAL, LREAL)

Типы данных REAL и LREAL представляют двоичные значения с плавающей точкой. Внутреннее представление форматов этих данных описано в IEEE 754. В этом же стандарте описаны как численные значения, так и последовательности битов, которые интерпретируются как символьные значения NaN ("не число"), а также как плюс и минус бесконечности. Значения с плавающей точкой могут быть введены либо как целые значения, значения, основанные на десятичном представлении плавающей точки, либо как значения, вводимые в "экспоненциальном" представлении. Целые значения являются теми же, что и значения, приведенные для типов данных INT, DINT или LINT. Эти значения не могут быть использованы для представления дробных значений. Десятичные значения с плавающей точкой являются значениями, которые имеют как целую часть, так и дробную компоненту. Целое значение и дробные компоненты разделяются десятичной точкой "." или символом периода. Форма значений в "экспоненциальном" представлении является такой же, как и представление дробных значений с добавлением экспоненциальной компоненты (показателя степени). Этот показатель степени всегда является целым числом со знаком до 10, в которое возводится значение основания системы счисления.

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

Диапазон разрешенных данных REAL (32-битный формат IEEE с ординарной точностью) устанавливают по формуле

,

где - значение знакового бита;

- 8-битный показатель степени. Допустимые значения этого показателя лежат в диапазоне от -126 до +127;

- нормализованная 24-битная мантисса (23 бита внутренней памяти плюс один скрытый бит). Допустимые значения мантиссы лежат в диапазоне между 0 и 16777215.

Комбинирование и позволяет установить диапазон приближенных абсолютных значений 0-3,4028.

EDS использует для данных REAL следующие представления значений с плавающей точкой:

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

"Экспоненциальное" представление: 0.0 - ±nn.nnnnnnnnnE±xxxx,

где общее число разрядов в мантиссе не должно превышать 11 (помимо символа десятичной точки и символа знака), а число разрядов в показателе степени не должно превышать 4 (помимо символа "Е" и символа знака). Десятичная точка может располагаться в мантиссе где угодно. Как символ десятичной точки, так и символ знака в мантиссе могут быть опущены (знак "+" подразумевается, если символ знака опущен).

Диапазон разрешенных данных LREAL (64-битный формат IEEE с двойной точностью) определяют по формуле

,

где - значение знакового бита;

- 11-битный показатель степени. Допустимые значения этого показателя лежат в диапазоне от -1022 до +1023;

- нормализованная 53-битная мантисса (52 бита внутренней памяти плюс один скрытый бит). Допустимые значения мантиссы лежат в диапазоне между 0 и 9007199254740991.

Комбинирование и позволяет установить диапазон приближенных абсолютных значений 0-1,7976.

EDS использует для данных LREAL следующие представления значений с плавающей точкой:

- представление в виде целых чисел (фиксированных):

- от 9007199254740991 до + 9007199254740991;

- десятичная система счисления (с плавающей точкой):

0.0-±9999999999999999,

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

"Экспоненциальное" представление:

0.0-±nnnn.nnnnnnnnnnnnE±xxxx,

где общее число разрядов в мантиссе не должно превышать 16 (помимо символа десятичной точки и символа знака), а число разрядов в показателе степени не должно превышать 4 (помимо символа "Е" и символа знака). Десятичная точка может располагаться в мантиссе где угодно. Как символ десятичной точки, так и символ знака в мантиссе могут быть опущены (знак "+" подразумевается, если символ знака опущен).

В дополнение к вводимым значениям, указанным выше, представление плавающей точки учитывает два стиля вводов и два типа бесконечностей. Существуют два типа Nan ("не число"), а именно сигнализация Nan и "тихое" NaN (Quiet NaN). Кроме того, формат устанавливает представления значений плюс и минус бесконечностей. В этих случаях резервируются следующие специальные слова, которые должны использоваться для представления ввода ассоциированного символа плавающей точки:

А.4.1.3.11 EDS_Date

Тип данных EDS_Date должен иметь формат mm-dd-yyyy, где mm - месяц, dd - день, уууу - год. Правильные значения месяца, дня и года mm-dd-yyyy должны быть следующими:

Представление года двумя символами может быть использовано в случае, если тип данных EDS_Date имеет формат mm-dd-yy, где mm - месяц, dd - день месяца, а уу - год. В этом случае две первые цифры года имеют предполагаемое значение 19, так что уу=96 должно означать год 1996. Правильные значения месяца, дня и года параметров mm-dd-yy должны быть следующими:

Примечание - Представление года двумя цифрами не рекомендуется.

A.4.1.3.12 EDS_Time_Of_Day

Тип данных EDS_Time_Of_Day должен иметь формат hh.mm.ss, где hh - часы, mm - минуты и ss - секунды. Правильные значения часов, минут и секунд должны быть следующими:

А.4.1.3.13 EDSRevision

Тип данных EDS_Revision должен иметь формат Major_Revision.Minor_Revision с правильными значениями:

Значение EDS_Revision 0.0 следует рассматривать как ошибочное.

Пример - EDS_Revision 1.4 соответствует старшей версии 1 и младшей версии 4.

А.4.1.3.14 Универсальный указатель ресурсов EDS_URL

Все ссылки на EDS_URL в требованиях к EDS предназначены для получения формализованной информации, необходимой для определения местоположения ресурсов и доступа к ним через Интернет. EDS_URL должен кодироваться в файлах EDS с использованием базового формата, установленного в ИСО 15745-2 для EDS_Char_Array. Кроме того, содержимое строки для EDS_URL должно иметь формат, установленный Сетевой рабочей группой RFC 1738 "Универсальный указатель ресурсов (URL)" Интернета. Что касается спецификаций в файле EDS, EDS_URL должен ограничиваться любой из следующих форм:

http;

ftp;

file (файл).

А.4.1.4 Основные требования к файлу EDS

А.4.1.4.1 Обзор

В данном подразделе описаны основные разделы EDS, являющиеся общими для нескольких сетей на основе CIP, и установлены соответствующие требования к применению. В таблице А.8 указано местоположение подразделов определений этих разделов.

Таблица А.8 - Определение основных разделов

А.4.1.4.2 Раздел описания файла

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

Таблица А.9 - Формат описания файла

Вводимые в раздел описания файла данные должны предоставлять информацию, как показано в таблице А.10.

Таблица А.10 - Вводимые (входные) данные описания файла

На рисунке А.2 приведен пример, представляющий типичный раздел [File].

Рисунок А.2 - Пример раздела [File] (информативный)

A.4.1.4.3 Раздел описания устройств

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

Таблица А.11 - Формат описания устройств

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

Средства конфигурирования должны использовать требуемые входные данные в разделе описания устройств для согласования EDS с конфигурируемым устройством. Входные данные должны предоставлять информацию, установленную в таблице А.12.

Таблица А.12 - Входные данные для описания устройств

На рисунке А.3 приводится пример, представляющий типичный раздел устройств [Device].

Рисунок А.3 - Пример раздела устройств (информативный)

А.4.1.4.4 Раздел классификации устройств

Раздел классификации устройств должен классифицировать устройство, описываемое EDS, как принадлежащее одному или нескольким категориям устройств. Ключевое слово ввода для всех классификаций должно состоять из набора символов "Class", объединенных с десятичным числом. Числа должны начинаться с 1 для первого класса и должны увеличиваться для каждого дополнительного класса.

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

- ControlNet;

- DeviceNet;

- EtherNetIP;

- ключевое слово поля со стороны продавца.

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

А.4.1.4.5 Раздел классов параметров

Раздел классов параметров должен идентифицировать общие атрибуты параметров конфигурации, описываемые EDS, которые соответствуют поднабору атрибутов класса Parameter Object и установлены в Библиотеке Объектов CIP.

Раздел классов параметров должен содержать вводимые данные, установленные в таблице А.13.

Таблица А.13 - Формат классов параметров

Вводимые в раздел классов параметров данные должны предоставлять информацию, как показано в таблице А.14.

Таблица А.14 - Вводимые данные (вводы) классов параметров

Ввод дескриптора классов параметров должен содержать биты, которые описывают характеристики параметров, как установлено в таблице А.15. Биты, не установленные в таблице А.15, не должны использоваться и им должны быть присвоены нулевые значения (0).

Таблица А.15 - Значения битов дескриптора классов параметров

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

Рисунок А.4 - Пример раздела класса параметров [ParamClass] (информативный)

А.4.1.4.6 Раздел параметров

Раздел параметров должен идентифицировать параметры конфигурации в устройстве. Ключевое слово ввода должно быть одним из следующих наборов символов: "Param", "ProxyParam", "ProxiedParam", объединенным с числом (десятичным) экземпляров параметров для устройства, например "Param1". Фактический экземпляр объекта параметров может быть (но необязательно) реализован в устройстве. Наоборот, не требуется, чтобы все экземпляры объекта параметров имели соответствующий ввод "ParamN" в EDS. Однако если экземпляр объекта параметров существует в узле и если этот параметр также описывается в EDS, тогда значение "N" в "ParamN" должно соответствовать экземпляру объекта параметра.

Каждый ввод должен содержать форматированные поля, представленные в таблице А.16. Ключевые слова "ProxyParam" и "ProxiedParam" определяются далее в А.4.1.5.3.1 как часть требований EDS к модулям.

Таблица А.16 - Формат параметров

Вводимые данные раздела параметров должны содержать информацию, установленную в таблицах А.17 и А.21.

Поля параметров, перечисленные в таблице А.17, являются общими для всех параметров.

Таблица А.17 - Общие поля параметров

Биты поля дескриптора должны быть такими, как установлено в таблице А.18

Таблица А.18 - Определения битов поля дескриптора

Старые версии файлов EDS могут использовать идентификаторы типов данных, как установлено в таблице А.19.

Таблица А.19 - Идентификаторы типов данных (устаревшие)

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

Таблица А.20 - Семантика для вводов минимальных и максимальных значений

Поля параметров, перечисленные в таблице А.21, являются дополнительными и значимыми только в случае, если используются со следующими типами данных: SINT, INT, DINT, LINT, USINT, UINT, UDINT, ULINT, REAL и LREAL. Спецификация этих полей с любым другим типом данных запрещается.

Таблица А.21 - Поля параметров, зарезервированные для типов числовых данных

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

Примечание - Если расширенное масштабирование не поддерживается, то эта формула должна использоваться с DecimalPrecision=0.

Рисунок А.5 - Формула масштабирования параметра

В разделе [Params] может также быть второе ключевое слово. Это ключевое слово должно использоваться для предоставления нумерованного списка выборов параметров, представляемых пользователю. Ключевое слово ввода для всех нумерованных параметров должно состоять из набора символов, "Enum", объединенных с десятичным числом из соответствующего ввода Param. Каждый ввод "Enum" должен состоять из пар целых чисел и строк.

На рисунке А.6 приведен пример типичного раздела Parameter.

Рисунок А.6 - Пример раздела [Params]

А.4.1.4.7 Раздел групп параметров

Раздел групп параметров должен идентифицировать все группы параметров в устройстве. Каждая группа параметров должна содержать список параметров в группе. Ключевое слово ввода для каждой группы должно состоять из комбинации набора символов, "Group", и номера группы параметров (десятичного), например "Group1". Десятичные номера должны начинаться с единицы и увеличиваться на единицу.

Фактический экземпляр объекта группы параметров может быть (но необязательно) реализован в устройстве. Наоборот, не требуется, чтобы все экземпляры объекта группы параметров имели соответствующий ввод "GroupN" в EDS. Однако если экземпляр объекта группы параметров существует в узле и если эта группа параметров также описывается в EDS, тогда значение "N" в "Group N" должно соответствовать экземпляру объекта группы параметров.

Поля в каждом вводе должны содержать название группы, число элементов в группе и номера экземпляров параметров в группе. Раздел группы параметров должен содержать поля, показанные в таблице А.22.

Таблица А.22 - Формат группы параметров

На рисунке А.7 представлен пример, показывающий раздел типичных групп параметров.

Рисунок А.7 - Пример раздела [Groups]

А.4.1.4.8 Раздел компоновки

Раздел компоновки описывает структуру блока данных. Часто такой блок представляет собой атрибут данных объекта Компоновка; однако данный раздел EDS может быть использован для описания любой сложной структуры. Описание этого блока данных соответствует описанию механизма, используемого объектом Компоновка для описания списка своих членов.

Ключевое слово ввода "Revision" имеет поле 16-битных целых чисел, которое должно быть версией (атрибут класса 1) объекта Компоновка в приборе. Если этот дополнительный ввод опущен, версия объекта Компоновка должна быть версией 2.

Ключевое слово ввода для всех компоновок должно состоять из одного из следующих наборов символов: "Assem", "ProxyAssem", "ProxiedAssem", объединенных с номером (десятичным) экземпляра объекта Компоновка для прибора, например "Assem1". Если отдельный экземпляр объекта Компоновка адресуется из канала связи, должно быть взаимно однозначное соответствие между номером Assem в файле EDS и номером экземпляра компоновки в устройстве. Ключевые слова "ProxyAssem" and "ProxiedAssem" определены далее в А.4.1.5.3.2 как часть требований EDS к модулям.

Каждый ввод должен содержать форматированные поля, показанные в таблице А.23.

Таблица А.23 - Формат ключевых слов AssemN

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

Второе поле "Маршрут" должно быть строкой, устанавливающей логическую цепь. Этот маршрут должен идентифицировать адрес блока данных в устройстве. Если блок, описываемый этим вводом AssemN, не непосредственно адресуется из канала связи, то это поле должно быть пустым. Если это поле является пустой строкой, "", блок данных должен адресоваться как атрибут данных (атрибут экземпляра 3) N-го экземпляра объекта Компоновка.

Третье поле "Размер" должно устанавливать размер блока данных в байтах. Если ни это поле, ни поля "Member Size"/"Member Reference" не представлены, размер блока данных должен быть равен 0. Однако оба этих поля могут быть представлены, поскольку они оба устанавливают размер блока, размеры, устанавливаемые обоими способами, должны быть согласованы.

Четвертое поле "Дескриптор" должно быть битовым полем, описывающим некоторые характеристики Компоновки. Биты этого поля должны интерпретироваться, как установлено в таблице А.24.

Таблица А.24 - Определение битов поля дескриптора Компоновки

Поля 5 и 6 должны быть зарезервированы и должны быть пустыми.

Остающиеся поля должны быть спаренными так, чтобы поле "Member Size (Размер элемента)" спаривалось с полем "Member Reference (Элементная Ссылка)", делая полное число полей четным. Число пар полей в таком вводе должно быть переменным. Пары должны соответствовать списку элементов объекта Компоновка.

Разрешенные значения поля "Member Reference" должны быть одним из следующих значений:

- ссылка ParamN или ProxyParamN из раздела [Params];

- ссылка AssemN или ProxyAssemN из раздела [Assembly];

- строка, представляющая маршрут (ЕРАТН);

- константа UDINT;

- пустое поле;

- дополнительные значения, установленные для модульной EDS в А.4.1.5.3.2.

Если поле "Member Reference" является пустым, число битов, установленных полем "Member Size", должно использоваться как дополнение в объекте Компоновка. Поле "Member Reference", содержащее пустую строку, следует рассматривать так, как если бы поле было пустым. Поле "Member Reference" и его соответствующее поле "Member Size" не должны быть одновременно пустыми. Если поле "Member Reference" устанавливает ЕРАТН, то этот маршрут должен состоять либо из Логических сегментов (маршрут к объекту в приборе), либо из Сегментов данных.

Поле "Member Size" должно измеряться в битах. Если поле "Member Size" является пустым, должен использоваться установленный размер поля "Member Reference". Установленный размер ввода Param должен быть таким, как определено в его 6-м поле (размер). Установленный размер ввода Assem должен быть таким, как определено в его 3-м поле (размер).

Элементы должны размещаться в первом младшем бите блока данных, так же как и в объекте Компоновка. Если размер поля "Member Size" меньше установленного размера соответствующего поля "Member Reference", должны использоваться младшие биты соответствующего поля "Member Reference". Если размер поля "Member Size" больше установленного размера соответствующего поля "Member Reference", после всего элемента должны следовать дополняющие нули, позволяющие увеличить размер элемента до "Member Size". Размер представленного блока данных должен быть целым числом байтов. Размер всех элементов должен соответствовать размеру поля "AssemN Size" (когда выражается в битах).

На рисунке А.8 представлен пример, показывающий типичный раздел Компоновка. В этом примере длина Assem5 составляет 1 байт, а его значение по умолчанию определяется как 0x21.

Рисунок А.8 - Пример раздела [Assembly]

Примечание - Ключевое слов Variant, объединенное с десятичным числом (например, "Variant1"), резервируется для определения в дальнейшем новых типов вводов в разделе Компоновка.

А.4.1.4.9 Раздел управления соединениями

Настоящий раздел CIP не используется в файлах EDS DeviceNet, поэтому он не рассмотрен в настоящем стандарте.

А.4.1.4.10 Раздел портов

В настоящем разделе должны описываться маршрутизируемые порты CIP, имеющиеся в приборе. Каждый маршрутизируемый порт CIP, рассматриваемый в настоящем разделе, должен иметь соответствующий ввод. Ключевое слово ввода для всех портов должно состоять из набора символов "Port", объединенных с десятичным числом, соответствующим экземпляру объекта Порт. Например, Port1 соответствует экземпляру 1 объекта Порт.

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

Каждый ввод должен содержать форматированные поля, установленные в таблице А.25.

Таблица А.25 - Формат ввода Порта

Первое поле "Название типа порта" (Port Type Name) должно быть одним из следующих ключевых слов:

- ControlNet;

- ControlNet_Redundant;

- TCP (указывает порт TCP EtherNet/IP);

- DeviceNet;

- Ключевое слово поля продавца, начинающееся с Идентификатора продавца и символа подчеркивания ('65535_').

Дополнительное поле "Название порта" (Port Name) должно быть строкой, устанавливающей название порта, и может быть использовано интерфейсом пользователя. Поле "Объект порта" (Port Object) должно иметь маршрут (ЕРАТН), который идентифицирует объект связи, относящийся к сети, ассоциированный с портом.

Номер порта 1 должен соответствовать "порту" задней панели. Устройства с задней панелью, которые не могут маршрутизировать сообщения CIP, не должны иметь порт номер 1.

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

Рисунок А.9 - Пример раздела [Port]

А.4.1.5 Требования к файлу EDS модульных устройств

А.4.1.5.1 Общие положения

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

А.4.1.5.2 Раздел модульных устройств Modular section

А.4.1.5.2.1 Содержимое

Раздел Modular section должен описывать систему на основе стойки. Должны быть использованы два типа модульных устройств:

- стойку;

- модуль.

А.4.1.5.2.2 Устройство на основе стоек

Раздел Modular section, описывающий стойку, должен содержать установленное ключевое слово "DefineSlotslnRack". Единственное поле этого ввода должно содержать 16-битовое целое число без знака (UINT), устанавливающее число слотов в стойке. Даже если для стойки устанавливается электронный ключ, он необязательно должен адресовываться из канала связи. Ключевое слово SLOT (Слот), используемое в определениях маршрута в разделе Connection Manager, должно находиться в диапазоне от 0 до числа слотов минус 1.

Ключевое слово "SlotDisplayRule" является дополнительным. Единственное поле этого ввода должно быть параметром из раздела {Params} (только ParamN), определяющим трансляцию между внутренними и внешними слотами.

На рисунке А.10 представлен пример, показывающий EDS для устройств на основе стойки, включая раздел модулей.

Рисунок А.10 - Раздел [Modular], описывающий стойку

А.4.1.5.2.3 Модульное устройство (основные вводы)

Раздел [Modular], описывающий модуль, должен содержать вводы "Width (Ширина)" и "Rack (стойка)".

Требуемый ввод с ключевым словом "Width" должен иметь единственное поле, которое устанавливает, сколько слотов в стойке используется модулем. Поле должно содержать 16 битное целое число без знака (UINT).

Ключевое слово ввода для всех стоек, в которых может быть размещен модуль, должно состоять из набора символов "Rack", объединенного с десятичным числом. Числа должны начинаться с 1 для первой стойки и должны увеличиваться на 1 для каждой дополнительной стойки. Поля для вводов "Rack" должны быть такими, как показано в таблице А.26.

Таблица А.26 - Формат ввода Rack (стойка)

Поля "Vendor ID", "Product Type", "Product Code" "Major Revision" и "Minor Revision" должны идентифицировать электронный ключ стойки, в которую может быть вставлен модуль. Зарезервированное поле должно быть пустым. Поля "Legal Slot" должны идентифицировать слоты, в которые может быть вставлен модуль. EDS для модуля должен содержать один ввод "Rack" для каждой стойки, в которой может быть размещен модуль.

Рисунок А.11 представляет пример, показывающий типичный раздел Modular.

Рисунок А.11 - Пример раздела [Modular]

А.4.1.5.2.4 Модульный прибор (дополнительные вводы)

Общее представление

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

С этой целью модульные устройства обычно разделяют на две категории:

- модули, имеющие подключения канала связи CIP, соответствующий объект Идентичность, адресуемый из канала связи, и размещаемые в слоте 0 (например, коммуникационные адаптеры);

- модули, не имеющие подключения канала связи CIP или адресуемого объекта Идентичность, не могут быть размещены в слоте 0 (например, модули ввода/вывода).

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

Вводы для модуля, не имеющего адресуемого объекта Идентичность канала связи

Раздел Modular, описывающий модуль, не имеющий адресуемого объекта Идентичность канала связи, может содержать ключевое слово ввода "ExternallD". Ключевое слово должно иметь единственное поле. Это поле должно быть байтовой строкой, идентифицирующей модуль. Байтовая строка должна кодироваться с использованием того же формата, как и для ERATH.

На рисунке А.12 представлен пример, показывающий типичный раздел [Modular], который описывает модуль без адресуемого объекта Идентичность канала связи.

Рисунок А.12 - Пример раздела Modular (модуль без адресуемого объекта Идентичность канала связи)

Вводы для модуля, имеющего подключение канала связи и размещенного в слоте 0

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

Ключевое слово "GenericID" должно иметь единственное поле. Это поле должно быть байтовой строкой, которая должна включаться в сегмент данных для соединения модуля вместо ExtemallD, если кодирование модуля не требуется. Эта байтовая строка должна кодироваться с использованием того же формата, который был установлен для ЕРАТН.

Ключевое слово "ExternlDExactMatch"* должно иметь единственное поле со значением Yes (Да) или No (Нет). Значение Yes должно указывать, что ExternallD устанавливает одно конкретное устройство. Значение No должно указывать, что ExternallD устанавливает один из наборов совместимых устройств. Если ключевое слово "ExternlDExactMatch"* пропущено, по умолчанию ExternallD должно устанавливать одно конкретное устройство.

_______________

* Текст документа соответствует оригиналу. - .

Ключевое слово "Query (Запрос)" должно иметь четыре поля. Первое слово должно быть маршрутом, идентифицирующим адресуемый атрибут канала связи, который содержит набор внешних идентификаторов, по одному для каждого слота в стойке, за исключением слота 0. Второе поле должно быть сервисом для использования с маршрутом запроса (т.е. 1 - получить все атрибуты или 14 - получить один атрибут). Третье поле должно быть целым числом, определяющим число байтов, используемых для идентификации каждого модуля, и должно находиться в диапазоне 1-16. Если двойной модуль слота находится в стойке, внешний идентификатор модуля должен появляться дважды в наборе, возвращенном из запроса. Запрос должен быть адресован только модулю в слоте 0. Четвертое поле ExternallD должно быть возвращаемым, когда имеется пустой слот, кодируемый с использованием того же формата, который был установлен для ЕРАТН.

На рисунке А.13 представлен пример, показывающий типичный раздел [Modular], описывающий модуль с подключением канала связи, размещенный в слоте 0.

Рисунок А.13 - Пример раздела [Modular] (модуль с подключением канала связи в слоте 0)

А.4.1.5.3 Добавление модулей в основные разделы EDS

А.4.1.5.3.1 Добавления в раздел Параметр

Ключевые слова "ProxyParam" и "ProxiedParam" должны быть использованы для описания параметров, замещаемых адаптерным устройством DeviceNet в другом приборе, который не поддерживает протокол CIP. Примером такого устройства является адаптерный модуль DeviceNet (устройство, замещающее соединение) в многослотной стойке ввода/вывода с аналоговым модулем ввода/вывода (устройство, замещающее соединение).

Ключевое слово "ProxyParam" должно быть в EDS для устройства, выполняющего роль "заместителя".

Ключевое слово "ProxiedParam" должно быть в EDS для устройства, выполняющего роль "заместителя".

Информация в разделе Modular должна быть использована для ассоциации файлов EDS, содержащих ключевые слова "ProxyParam", с файлами EDS, содержащими ключевые слова "ProxiedParam". Эта ассоциация должна существовать, если оба файла EDS устанавливают согласованный ввод для стойки (Rack).

Десятичное число (объединяемое с "ProxyParam" и "ProxiedParam") должно быть использовано для согласования "ProxyParam" с "ProxiedParam". Значения поля согласованной пары "ProxyParam" и "ProxiedParam" должны быть объединены для составления такой же информации по значению поля, которая существует в единственном вводе "Param". Это объединение должно быть выполнено с использованием значения поля из "ProxyParam", если только значение этого поля не определяется ключевым словом "Module". Если значение поля, установленное в "ProxyParam", определяется ключевым словом "Module", должно быть использовано значение поля, установленное в "ProxiedParam". Разрешается устанавливать значения поля для вводов "ProxiedParam", соответствующее значение поля которых в "ProxyParam" не определяется ключевым полем "Module", однако эти значения поля не должны быть использованы, они должны существовать только для документации.

В разделе Param также может существовать другое ключевое слово. Это ключевое слово должно быть использовано для предоставления минимального, максимального значений и значения по умолчанию, добавляемых к минимальному, максимальному значениям и к значению по умолчанию "ProxyParam". Это ключевое слово ввода должно иметь вид "ProxyParamSizeAdder" и должно быть объединено с десятичным числом из соответствующего ввода "ProxyParam". Определение этих полей согласовывается с определениями "Param". Ключевое слово "ProxyParamSizeAdder" предоставляет средства для адаптера на соединении модуля (например, "ProxyConnect"), добавляя данные по адаптеру в данные по модулю и возвращая объединенные данные по соединению.

В разделе [Param] также может существовать другое ключевое слово, соответствующее "ProxyParam", "ProxyEnum". "ProxyEnum" определяется так же, как и "Enum", за исключением того, что оно ассоциируется с "ProxyParam", а не с "Param". В разделе [Param] также может существовать второе ключевое слово, соответствующее "ProxiedParam", "ProxiedEnum". "ProxiedEnum" определяется так же, как и "Enum", за исключением того, что оно ассоциируется с "ProxiedParam", а не с "Param".

А.4.1.5.3.2 Добавления в раздел Компоновка

Дополнительные ключевые слова ввода

Ключевые слова "ProxyAssem" и "ProxiedAssem" должны быть использованы для описания компоновок замещаемым адаптерным устройством CIP в другом устройстве, которое не поддерживает протокол CIP. Примером такого устройства является адаптерный модуль DeviceNet (устройство, замещающее соединение) в многослотной стойке ввода/вывода с аналоговым модулем ввода/вывода (прибор, замещающий соединение).

Ключевое слово "ProxyAssem" должно существовать в EDS для устройства, выполняющего роль "заместителя".

Информация в разделе Modular должна быть использована для ассоциации файлов EDS, содержащих ключевые слова "ProxyAssem", с файлами EDS, содержащими ключевые слова "ProxiedAssem". Эта ассоциация должна существовать, если оба файла EDS устанавливают согласованный ввод для стойки (Rack).

Десятичное число (объединяемое с "ProxyAssem" и "ProxiedAssem") должно быть использовано для согласования "ProxyAssem" с "ProxiedAssem". Значения поля согласованной пары "ProxyAssem" и "ProxiedAssem" должны быть объединены для составления такой же информации по значению поля, которая существует в единственном вводе "Assem". Это объединение должно быть выполнено с использованием значения поля из "ProxyAssem", если только значение этого поля не определяется одним из ключевых слов "Module" или "ModuleMemberList". Если значение поля, установленное в "ProxyAssem", определяется ключевым словом "Module", должно быть использовано значение поля, установленное в "ProxiedAssem". Значение поля "Module" не должно быть использовано для полей "Member Size" или "Member Reference". "ModuleMemberList" должно быть использовано только вместо пары полей "Member Size" и "Member Reference". Если значение поля, установленное в "ProxyAssem", определяется как "ModuleMemberList", должны быть использованы все поля "Member Size" и "Member Reference", установленные в "ProxiedAssem". Разрешается устанавливать значения поля для вводов "ProxiedAssem", соответствующее значение поля которых в "ProxyAssem" не определяется ключевым полем "Module", однако эти значения поля не должны быть использованы, они должны существовать только для документации.

Дополнительные ключевые слова полей

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

Следующие ключевые слова являются дополнительными значениями, учитывающими поле "Member Reference" в разделе Компоновка, которое определяет специальное назначение данных, установленных элементом компоновки:

- ExternallD;

- InputSlotMask0 или InputSlotMask1;

- OutputSlotMask0 или OutputSlotMask1;

- ConfigSlotMask0 или ConfigSlotMask1.

Ключевое слово "ExternallD" устанавливает, что этот элемент компоновки должен содержать либо значение "ExtemallD" модульного устройства, если кодирование необходимо, либо значение "GenericID", устанавливаемое в EDS адаптера, если кодирование модуля не требуется.

Ключевое слово "ExternallD", объединенное с десятичным числом (например, ExternallD2), должно быть использовано для кодирования отдельного устройства для адаптерных соединений стойки. Десятичное (положительное) число N в "ExternallDN" определяет слот N в стойке. Ключевое слово "ExternallDN" устанавливает, что данный элемент компоновки должен содержать либо значение "ExternallD" модульного устройства для слота N, если кодирование устройства для этого слота необходимо, либо значение "GenericID", устанавливаемое в EDS адаптера, если кодирование модуля для этого слота не требуется.

Примечание - Кодирование недоступно для слота 0.

Ключевое слово "InputSlotMask0" или "InputSlotMask1" должно указывать местоположение входной щелевой маски в компоновке. Входная щелевая маска является набором битов, которые представляют включение или исключение исполнителя модуля в (из) данные (данных) инициатора в адаптерном соединении стойки. Если используется ключевое слово "InputSlotMask0", то бит 0 в этом наборе представляет слот 0, бит 1 представляет слот 1 и т.д. Если используется ключевое слово "InputSlotMask1", то бит 0 в этом наборе представляет слот 1, бит 1 представляет слот 2 и т.д. Ключевые слова "InputSlotMask0" и "InputSlotMask1" не должны быть использованы одновременно в одной и той же компоновке. Предшествующее поле "Member size" должно быть обязательным.

Ключевое слово "OutputSlotMask0" или "OutputSlotMask1" должно указывать местоположение выходной щелевой маски в компоновке. Выходная щелевая маска является набором битов, которые представляют включение или исключение исполнителя модуля в данные (из данных) инициатора в адаптерном соединении стойки. Если используется ключевое слово "OutputSlotMask0", то бит 0 в этом наборе представляет слот 0, бит 1 представляет слот 1 и т.д. Если используется ключевое слово "OutputSlotMask1", то бит 0 в этом наборе представляет слот 1, бит 1 представляет слот 2 и т.д. Ключевые слова "OutputSlotMask0" и "OutputSlotMask1" не должны быть использованы одновременно в одной и той же компоновке. Предшествующее поле "Member size" должно быть обязательным.

Ключевое слово "ConfigSlotMask0" или "ConfigSlotMask1" должно указывать местоположение щелевой маски конфигурации в компоновке. Щелевая маска конфигурации является набором битов, которые представляют включение или исключение данных по конфигурации модуля в сервис установления адаптерного соединения стойки. Если используется ключевое слово "ConfigSlotMask0", то бит 0 в этом наборе представляет слот 0, бит 1 представляет слот 1 и т.д. Если используется ключевое слово "ConfigSlotMask1", то бит 0 в этом наборе представляет слот 1, бит 1 представляет слот 2 и т.д. Ключевые слова "ConfigSlotMask0" и "ConfigSlotMask1" не должны быть использованы одновременно в одной и той же компоновке. Предшествующее поле "Member size" должно быть обязательным.

А.4.1.5.3.3 Добавления в раздел Управление соединениями

Данный раздел CIP не используется в файлах EDS DeviceNet, поэтому в настоящем стандарте он не рассмотрен.

А.4.1.5.3.4 Примеры расширенного раздела EDS (информативные)

На рисунках А.14 и А.15 представлены примеры, показывающие использование модульных расширений EDS для разделов Параметр и Компоновка.

Рисунок А.14 - Пример вводов ProxyParam и ProxyAssem

Рисунок А.15 - Пример согласованных вводов ProxiedParam и ProxiedAssem

А.4.2 Требования к EDS для DeviceNet

А.4.2.1 Содержание ES для DeviceNet

Настоящий подраздел устанавливает требования к кодированию файлов Электронной Информационной Таблицы (EDS) для сетей на основе DeviceNet.

Таблица А.27 описывает структуру разделов, которые могут быть представлены в DeviceNet EDS, соответствующие разрешенные разграничители разделов и порядок этих разделов в EDS. Некоторые из этих разделов являются общими для нескольких сетей на основе CIP, их конкретное использование для DeviceNet установлено в А.4.2.2, если это необходимо. Другие разделы являются специфическими для DeviceNet и установлены в А.4.2.4.

Таблица А.27 - Структура файлов DeviceNet EDS

Содержимое DeviceNet EDS должно быть организовано следующим образом:

- все файлы EDS DeviceNet, включающие в себя модульный раздел, должны также содержать раздел Классификация приборов, который должен использовать разрешенный разграничитель [Device Classification], и могут быть размещены где угодно после раздела Описание файлов;

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

А.4.2.2 Реализация общих требований CIP

А.4.2.2.1 Раздел классификации устройств

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

А.4.2.2.2 Раздел Порт

В разделе Порт EDS ввод PortN, соответствующий совместимому порту DeviceNet, должен устанавливаться следующим образом:

- поле "Port Type Name (Название типа порта)" должно иметь значение "DeviceNet";

- дополнительное поле "Port Object (объект Порт") должно быть установлено на маршруте объекта DeviceNet для этого порта;

- в полях "Port Name (Название порта)" и "Port Number (Число портов)" не размещаются никакие дополнительные требования, кроме требований, установленных в общем подразделе CIP (см. А.4.1.4.10).

А.4.2.3 Дополнительные требования к кодированию данных

Для файлов DeviceNet EDS дополнительные требования к кодированию данных не устанавливают.

А.4.2.4 Дополнительные требования к файлам

А.4.2.4.1 Раздел нумерованных строк параметров

Настоящий раздел предоставляет нумерованный список параметров, выбираемых пользователем. Ключевое слово ввода для всех нумерованных строк параметров должно состоять из набора символов "Param", объединенного с номером (десятичным) экземпляра параметров для прибора. Каждый параметр, поддерживающий нумерованные строки и не имеющий соответствующего ввода Enum в разделе Параметры, должен иметь ввод в этом разделе. Вводы должны быть расположены в возрастающем порядке.

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

Каждый ввод в разделе Нумерованные строки параметров должен содержать форматированные поля, показанные в таблице А.28.

Таблица А.28 - Формат нумерованных строк параметров

На рисунке А.16 представлен пример, показывающий типичный раздел нумерованных строк параметров.

Рисунок А.16 - Пример раздела [EnumPar]

А.4.2.4.2 Раздел характеристик ввода/вывода

А.4.2.4.2.1 Содержимое

Раздел характеристик ввода/вывода должен содержать информацию о возможностях ввода/вывода заранее определенного набора основных/подчиненных соединений прибора (см. МЭК 62026-3:2000). Этот раздел является обязательным, если прибор реализует соединение ввода/вывода, характеристики которого могут быть полностью представлены одним или несколькими вводами в этом разделе.

В данном разделе должны быть описаны следующие характеристики ввода/вывода прибора:

- тип триггера ввода/вывода (Опрос, Строб, Изменение состояния, Циклический);

- размер сообщения ввода/вывода (число байтов);

- заранее установленные маршруты соединений ввода/вывода.

Раздел характеристик ввода/вывода должен содержать вводы, установленные в таблице А.29.

Таблица А.29 - Формат характеристик ввода/вывода

Вводы в разделе характеристик ввода/вывода должны предоставлять информацию, как показано в таблице А.30.

Таблица А.30 - Вводы характеристик ввода/вывода

А.4.2.4.2.2 Ввод информации ввода/вывода по умолчанию

Ввод информации ввода/вывода по умолчанию должен определять информацию ввода/вывода прибора по умолчанию.

Ввод информации ввода/вывода по умолчанию должен содержать форматированные поля, представленные в таблице А.31.

Таблица А.31 - Формат информации ввода/вывода по умолчанию

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

Таблица А.32 - Присвоение битов маски типа ввода/вывода по умолчанию

А.4.2.4.2.3 Ввод информации по опросам

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

Если данный ввод не представлен, тогда:

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

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

Ввод информации по опросам должен содержать форматированные поля, показанные в таблице А.33.

Таблица А.33 - Формат информации по опросам

Ввод информации по опросам должен предоставлять информацию, как показано в таблице А.34.

Таблица А.34 - Поля информации по опросам

А.4.2.4.2.4 Ввод информации по стробам

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

Если данный ввод не представлен, тогда:

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

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

Ввод информации по стробам должен содержать форматированные поля, показанные в таблице А.35.

Таблица А.35 - Формат информации по стробам

Ввод информации по стробам должен предоставлять информацию, как показано в таблице А.36.

Таблица А.36 - Поля информации по стробам

А.4.2.4.2.5 Ввод информации по изменению состояния

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

Если данный ввод не представлен, тогда:

- соединение Изменение Состояния в приборе не поддерживается;

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

Ввод информации по изменению состояния должен содержать форматированные поля, показанные в таблице А.37.

Таблица А.37 - Формат информации по изменению состояния

Ввод информации по изменению состояния должен предоставлять информацию, как показано в таблице А.38.

Таблица А.38 - Поля информации по изменению состояния

А.4.2.4.2.6 Ввод информации по циклам

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

Если данный ввод не представлен, тогда:

- циклическое соединение в устройстве не поддерживается;

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

Ввод информации по циклам должен содержать форматированные поля, показанные в таблице А.39.

Таблица А.39 - Формат информации по циклам

Ввод информации по циклам должен предоставлять информацию, как показано в таблице А.40.

Таблица А.40 - Поля информации по циклам

А.4.2.4.2.7 Ввод информации по многоадресным опросам

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

Если данный ввод не представлен, тогда:

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

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

Ввод информации по многоадресным опросам должен содержать форматированные поля, показанные в таблице А.41.

Таблица А.41 - Формат информации по многоадресным опросам

Ввод информации по многоадресным опросам должен представлять информацию, как показано в таблице А.42.

Таблица А.42 - Поля информации по многоадресным опросам

А.4.2.4.2.8 Вводимые данные соединений выходов устройства

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

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

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

- он может быть описан в файле EDS.

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

Ключевое слово для вводов соединений выхода должно состоять из комбинации набора символов "input", объединенных с десятичным числом, например "input1". Десятичное число должно начинаться с единицы и увеличиваться на единицу.

Каждый ввод соединения выхода должен содержать форматированные поля, как показано в таблице А.43.

Таблица А.43 - Формат соединения выхода

Ввод соединения выхода должен предоставлять информацию, показанную в таблице А.44.

Таблица А.44 - Поля соединений выхода

А.4.2.4.2.9 Вводимые данные соединений входов устройства

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

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

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

- он может быть описан в файле EDS.

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

Ключевое слово для вводов соединений входов должно состоять из комбинации набора символов "Output", объединенных с десятичным числом, например "Output1". Десятичное число должно начинаться с единицы и увеличиваться на единицу.

Каждый ввод соединения входа должен содержать форматированные поля, как показано в таблице А.45.

Таблица А.45 - Формат соединения входа

Ввод соединения входа должен предоставлять информацию, представленную в таблице А.46.

Таблица А.46 - Поля соединений входа

А.4.2.4.2.10 Примеры

Настоящий подраздел содержит примеры разделов файлов EDS, устанавливающие характеристики ввода/вывода устройств.

Рисунок А.17 представляет пример, показывающий типичный раздел характеристик ввода/вывода для прибора с возможностями опросов и стробов (Опрос по умолчанию).

Рисунок А.17 - Пример характеристик ввода/вывода. Устройство с возможностями опросов и стробов. Опрос по умолчанию

Рисунок А.18 представляет пример, показывающий типичный раздел характеристик ввода/вывода для устройства Strobe Only (только один вход и один выход).

Рисунок А.18 - Пример характеристик ввода/вывода для устройства Strobe Only, только один вход и один выход

Рисунок А.19 представляет пример, показывающий типичный раздел характеристик ввода/вывода для устройства с возможностями опросов и изменения состояния (Опросы и изменение состояния по умолчанию).

Рисунок А.19 - Пример характеристик ввода/вывода. Устройство с возможностями опросов и изменения состояния. Опросы и изменение состояния по умолчанию

Приложение В
(обязательное)

Шаблоны профилей CANopen

В.1 Описание шаблонов профилей устройств

В.1.1 Общие положения

XML схемы шаблонов профилей устройств, определенные в В.1.5, содержат отображения диаграмм классов профилей устройств, представленных в 6.2.1. Помимо классов и атрибутов отображения они содержат дополнительные элементы с атрибутами XML или без них, облегчающие однозначное описание профилей устройств и устройств XML. Для повторного использования некоторых определений элементов и гибкого расширения описаний профиля устройств и устройств с использованием моделей, используемых здесь, классы были отражены в нескольких XML схемах. В таблице В.1 перечислены все XML схемы описания обмена шаблонами профилей устройств CANopen.

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

Таблица В.1 - Обзор XML схем

В.1.2 Основы

В.1.2.1 Элементы типов данных

Профиль устройств использует типы данных МЭК 61158. Для введения дополнительных атрибутов информация по типам данных моделируется с использованием объявлений типов элементов XML. Альтернативные имена типов данных МЭК 61131-3 и CANopen предоставляются как постоянные атрибуты. Эти элементы типов данных определяются с именем "FDCMLdt.xsd" в XML схеме, которая определяется в В.1.5.2.

В.1.2.2 Сборная модель

Профиль устройств использует модель сборных элементов. Эти элементы фигурируют в форме списка сборных элементов (пример: proccessDataDescriptionList/processDataDescription).

В.1.2.3 Описательный текст для элементов

В.1.2.3.1 Общие положения

Профиль устройств предлагает три разные возможности предоставления описательного текста для элементов. Должны быть использованы только В.1.2.3.2 и В.1.2.3.3. В.1.2.3.4 может быть использован вместе с В.1.2.3.2 или В.1.2.3.3.

В.1.2.3.2 Текст, вставленный в профиль устройств

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

ISO 639 code for name of language ["-" ISO 3166-1-Alpha-2 code]

Пример - xml:lang='en-us' устанавливает текст на английском языке в американской редакции.

В.1.2.3.3 Текст, предоставляемый файлами текстовых ресурсов

Элементы labelRef и helpRef должны предоставлять указатель текстового ресурса, хранящегося в файле внешнего тестового ресурса. AIF должна заменять эти ресурсы посредством теста, предусмотренного файлом текстовых ресурсов. Файлы текстовых ресурсов, используемые профилем приборов, должны быть определены в элементе dictionary.

Формат файла тестовых ресурсов должен быть установлен в XML схеме "FDCMLTextResource.xsd", которая определена в В.1.5.4.

В.1.2.3.4 Указатель внешней документации

Дополнительно может быть предоставлен указатель внешней документации. Элемент hlpRefFile должен указывать положение в файле, определяемое элементом helpFile.

Пример - Примерами внешней документации являются файлы *.hlp, *.html, или *.pdf.

В.1.2.4 Допустимое значение элемента

Если элемент профиля устройств имеет значение, то должно использоваться одно из следующих описаний значения:

В.1.2.5 Моделирование обусловленного поведения устройств

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

Каждый возможный запрещаемый или разрешаемый целевой объект имеет в XML схеме разрешаемый атрибут.

В.1.2.6 Внутренние обращения элементов

Маршрут, установленный в атрибуте ref, должен быть допустимым маршрутом Xpath (см. [8]).

В.1.2.7 Однозначная идентификация элементов

Элементы, которые требуют идентификации, имеют атрибут uniquelD. Значение этого однозначного идентификатора должно состоять из:

token_index [ [_subindex]...], индекса типа unsigned16 и субиндекса типа unsigned8.

В.1.2.8 Компоновки

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

В.1.2.9 Категории со стороны продавца

Разработчик AIP может добавить элементы категорий в сборные элементы.

Пример - Разработчик AIP добавляет processDataCategory для входных сигналов и processDataCategory для выходных сигналов.

В.1.3 Объект DeviceManager

В.1.3.1 Объекты datatypeTemplateList, datatypeTemplate

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

В.1.3.2 Атрибут объекта communicationEntity

Таблица В.2 описывает атрибуты объекта communicationEntity, определенные в 6.2.1.3.4.

Таблица В.2 - Атрибут объекта communicationEntity

В.1.3.3 Атрибуты объекта channel1

Таблица В.3 описывает атрибуты объекта channel1, определенного в 6.2.1.3.3.2.

Таблица В.3 - Атрибуты объекта channel1

В.1.3.4 Атрибуты объектов MAU

Таблица В.4 описывает атрибуты объектов MAU, определенные в 6.2.1.3.3.3.

Таблица В.4 - Атрибуты объектов MAU

B.1.3.5 Атрибуты объектов slot (слот)

Таблица В.5 описывает атрибуты объектов slot, определенные в 6.2.1.3.3.4.

Таблица В.5 - Атрибуты объектов slot

В.1.3.6 Атрибуты объектов LED и LEDState

Таблица В.6 описывает атрибуты объекта LED, определенные в 6.2.1.3.3.5. Дочерний объект LEDState описывает разные состояния. Атрибуты LEDState описаны в таблице В.7.

Таблица В.6 - Атрибуты объекта LED

Таблица В.7 - Атрибуты объекта LEDState

B.1.4 Описания дополнительных элементов

В.1.4.1 Объект accessPath

Объект accessPath должен описывать маршрут относительно объекта communicationEntity для получения доступа к объекту localDataDescription. Формат объекта:

- для объекта localDataDescription: не определен.

Примечание - Формат для объекта localDataDescription в настоящем стандарте не рассмотрен.

На рисунке В.1 показаны порядок и нумерация смещений в байтах и битах.

Рисунок В.1 - Смещения в байтах и битах в канале обрабатываемых данных

В.1.4.2 Объект datatype

Объект datatype должен определять тип данных родительского элемента.

В.1.4.3 Объект file

Объект file содержит ссылку XLink [7] на внешний файл.

B.1.4.4 Элементы gain, offset, maxVal, minVal, default, stepVal, on

Для уточнения элемента range должны быть использованы следующие элементы:

Все значения относятся к .

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

В.1.4.5 Объекты picture, hotspotList, hotspot

Объект picture должен содержать ссылку на графическое представление элемента. Атрибуты элемента picture установлены в таблице В.8.

Таблица В.8 - Атрибуты элемента picture

Объект hotspotList является набором элементов hotspot. Элементы hotspot определяют положение объектов channel, LED или MAU в графическом представлении. Атрибуты объекта hotspot установлены в таблице В.9. Значения атрибутов xPos и yPos определяют относительное положение (см. рисунок В.2). Элемент hotElement является маршрутом Xpath к объектам channel, LED или MAU.

Таблица В.9 - Атрибуты элемента hotspot

Рисунок В.2 - Положения hotspot точек соединения

В.1.4.6 Объект specificProperty

Элемент specificProperty резервируется для расширений, выполняемых разработчиком AIP.

Примечание - Использование элемента specificProperty в настоящем стандарте не рассмотрено.

В.1.4.7 Объект tool

Объект tool определяет специальную сервисную программу родительского элемента. Таблица В.10 описывает атрибуты элемента tool.

Таблица В.10 - Атрибуты элемента tool

В.1.4.8 Объект uses

Элемент uses определяет ассоциацию "uses", как определено на рисунках 7 и 9.

В.1.5 XML схемы шаблонов профилей устройств

B.1.5.1 COFDCML.xsd

<?xml version = "1.0" encoding = "UTF-8"?>

<xsd:schema xmlns = "http://www.can-cia.org/xml/canopen"

targetNamespace = "http://www.can-cia.org/xml/canopen"

xmlns:xlink = "http://www.w3.org/1999/xlink"

xmlns:xsd = "http://www.w3.org/2001/XMLSchema"

version = "1.0"