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

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

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. № 864-ст

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

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ

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

ЧАСТЬ 3

ЭТАЛОННОЕ ОПИСАНИЕ СИСТЕМ УПРАВЛЕНИЯ НА ОСНОВЕ СТАНДАРТА МЭК 61158

Industrial automation system and integration. Open systems application integration frameworks. Part 3: Reference description for IEC 61158-based control systems

ISO 15745-3:2003 Industrial automation system and integration — Open systems application integration frameworks — Part 3: Reference description for IEC 61158-based control systems (IDT)

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

Группа Т58

ОКС 25.040.40

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

Предисловие

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

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

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

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

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

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

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

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

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

Введение

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

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

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

Настоящий стандарт расширяет исходную AIF, описанную в ИСО 15745-1, путем определения специфических технологических элементов и правил описания как профилей коммуникационных сетей, так и связанных с коммуникациями аспектов профилей устройств, специфичных для систем управления, основанных на стандарте МЭК 61158 ( P - NET^{®} <1>, PROFIBUS <2>, WorldFIP^{®} <3>, ControlNetTM <4> и INTERBUS^{®} <5>). Эти технологии используют профили, установленные в МЭК 61158, которые описаны в МЭК 61784-1. Профили для систем управления, представленных в ИСО/МЭК 8802-3, не входят в область применения данного стандарта и установлены в ИСО 15745-4.

<1> P-NET является зарегистрированной торговой маркой Международной организации пользователей P-NET Aps (IPUO). Контроль использования торговой марки передан бесприбыльной организации IPUO. Эта информация предоставлена для удобства пользователей настоящего стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки P-NET. Применение торговой марки P-NET требует разрешения IPUO.

<2> PROFIBUS является торговой маркой PROFIBUS Nutzerorganisation e.V. (PNO). Контроль использования торговой марки передан бесприбыльной организации PNO. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки PROFIBUS. Применение торговой марки PROFIBUS требует разрешения PNO.

<3> WorldFIP^{®} является зарегистрированной торговой маркой Ассоциации WorldFIP. Контроль использования торговой марки передан бесприбыльной организации Ассоциация WorldFIP. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки WorldFIP. Применение торговой марки WorldFIP требует разрешения Ассоциации WorldFIP.

<4> ControlNetTM является торговой маркой ControlNet International, Ltd. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки ControlNetTM. Применение торговой марки ControlNetTM требует разрешения ControlNet International, Ltd.

<5> INTERBUS является торговой маркой Phoenix Contact GmbH & Co. KG, контроль использования торговой марки передан бесприбыльной организации INTERBUS Club. Эта информация предоставлена для удобства пользователей настоящего международного стандарта и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использования торговой марки INTERBUS. Применение торговой марки INTERBUS требует разрешения INTERBUSClub.

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

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

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

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

• Часть 1. Общее эталонное описание;
• Часть 2. Эталонное описание систем управления на основе стандарта ИСО 11898;
• Часть 3. Эталонное описание систем управления на основе стандарта МЭК 61158;
• Часть 4. Эталонное описание систем управления на основе стандарта Ethernet.

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

Настоящий стандарт распространяется на специфические технологические элементы и правила описания как профилей коммуникационной сети, так и связанных с коммуникациями аспектов профилей устройств, относящихся к системам управления, на основе МЭК 61158. Настоящий стандарт не распространяется на профили систем управления на основе ИСО/МЭК 8802-3.

Примечание - Общие элементы и правила для описания моделей интеграции и профилей интероперабельности приложений совместно с профилями их компонент (профилями процессов, профилями обмена информацией и профилями ресурсов) установлены в стандарте ИСО 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 codes)

ИСО 9506-1:2000 Системы промышленной автоматизации. Спецификация производственных сообщений. Часть 1. Определение услуг (ISO 9506-1:2000 Industrial automation systems — Manufacturing Message Specification — Part 1: Service definition)

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

ИСО/МЭК 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)

МЭК 61131-3:2003 Контроллеры программируемые. Часть 3. Языки программирования (IEC 61131-3:2003 Programmable controllers — Part 3: Programming languages)

МЭК 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)

МЭК 61804-2 Блоки функциональные (FB) для управления процессом. Часть 2. Спецификация концепции FB и языка описания электронного устройства (EDDL) <6> (IEC 61804-2 Function blocks (FB) for process control — Part 2: Specification of FB concept and electronic device description language (EDDL))

<6> Готовится к публикации первое издание.

ANSI TIA/EIA-232-F:1997 Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange

ANSI TIA/EIA-485-A:1998 Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems

EN 50170:1996 Volume 3 Part 7-3 General purpose field communication system — WorldFIP — Network Management

IEEE Std 754-1985 (R1990) IEEE Standard for Binary Floating Point Arithmetic

REC-xml-20001006 Extensible Markup Language (XML) 1.0 Second Edition — W3C Recommendation 6 October 2000

REC-xmlschema-1-20010502 XML Schema Part 1: Structures — W3C Recommendation 02 May 2001

REC-xmlschema-2-20010502 XML Schema Part 2: Datatypes — W3C Recommendation 02 May 2001

RFC 1738:1994 Uniform Resource Locators (URL) — Internet Engineering Task Force (IETF), Request for Comments (RFC)

RFC 1759:1995 Printer MIB — Internet Engineering Task Force (IETF), Request for Comments (RFC)

UML V1.4 OMG — Unified Modeling Language Specification (Version 1.4, September 2001)

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

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

Примечание - Термины UML и обозначения, использованные в настоящем документе, приведены в ИСО 15745-1:2003, Приложение A.

4. Обозначения терминов

AIF — интеграционная среда приложений;

AIP — профиль интероперабельности приложений;

AL — уровень приложения;

ASCII — американский стандартный код для обмена информацией;

ASE — элемент сервиса приложения;

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

<7> CIPTM является торговой маркой ControlNet International, Ltd. и Open DeviceNet Vendor Association, Inc. Эта информация предоставлена для удобства пользователей ISO 15745 и не означает поддержки со стороны ИСО держателя торговой марки или какой-либо его продукции. Для соответствия настоящему стандарту не требуется использование торговой марки CIPTM. Применение торговой марки CIPTM требует разрешения ControlNet International, Ltd и Open DeviceNet Vendor Association, Inc.

CP — профиль коммуникации;

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

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

DP — сервисы и протокол PROFIBUS;

EDD — описание электронного устройства;

EDDL — язык описания электронного устройства;

EDS — электронный бланк данных;

FDCML — язык разметки конфигурации полевого устройства;

FIP — полевой промышленный протокол;

GSD — общее описание терминала;

HMI — интерфейс «человек — машина»;

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

IAS — промышленная система автоматизации;

ID — идентификатор;

kbit/s — 1024 бит/с;

LSB — наименьший значащий бит;

MAU — блок передачи данных для подключения к среде;

Mbit/s — 1024 x 1024 бит/с;

MCS — общие сервисы сообщений;

MMS — спецификации производственных сообщений;

MPS — производственные периодические/апериодические сервисы;

MS1 — мастер класса 1;

MS2 — мастер класса 2;

NC — числовое программное управление;

NM — сетевое управление;

OSI — взаимодействие открытых систем;

PC — персональный компьютер;

PID — пропорционально-интегрально-дифференциальный контроллер;

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

RC — управление с помощью робота;

SM_MPS — периодическая спецификация промышленных систем менеджмента;

SMS — спецификация систем менеджмента;

SubMMS — подмножество MMS;

SWNo — номер беспроводной (гибкой) среды передачи данных;

UML — унифицированный язык моделирования;

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

XML — расширяемый язык разметки.

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

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

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

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

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

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

Специфические технологические шаблоны профилей согласно МЭК 61158 разрабатываются исходя из общих шаблонов профилей, установленных в ИСО 15745-1:2003, раздел 7.

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

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

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

Однако в некоторых технологиях, описанных в стандарте МЭК 61158, используется специальный ранее принятый синтаксис ASCII. В связи с этим для достижения обратной совместимости определения шаблонов в любых технологиях (приложения A - E) включают все или необходимые подмножества:

• шаблонов профилей коммуникационных сетей и устройств, согласно определениям в ИСО 15745-1;
• шаблона, описанного в ИСО 15745, для инкапсуляции файлов, содержащих ранее принятый синтаксис ASCII («оболочку»);
• ранее принятого синтаксиса ASCII.

5.2.3. Заголовок

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

Таблица 1

Имена ProfileTechnology

5.3. Специфические технологические профили

Структура специфического технологического профиля коммуникационной сети и структура аналогичного профиля связанных с коммуникациями аспектов устройства, основанные на технологиях полевой шины стандарта МЭК 61158, описаны в разделе 6. Рассматриваемые технологии включают:

• ControlNet (см. 6.1);
• PROFIBUS (см. 6.2);
• P-NET (см. 6.3);
• WorldFIP (см. 6.4);
• INTERBUS (см. 6.5).

Соответствующие определения шаблона профиля приведены в приложениях A - E.

6. Профили устройств и коммуникационных сетей в системах управления, основанные на МЭК 61158

6.1. ControlNet

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

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

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

Рисунок 1 — Диаграмма классов профиля устройства ControlNet

Имеющиеся форматы профилей устройств ControlNet описаны в A.2.

XML-схема, представляющая шаблон профиля устройства ControlNet, определена в разделе A.2.1.3.3. Имя файла данной схемы должно быть «CIP_Device_Profile.xsd».

Примечание — Диаграмма классов профиля устройства ControlNet, представленная на рисунке 1, определяет только основные классы. Далее эти классы рассматриваются более детально. Подробности приведены в Приложении A.

XML-схема, представляющая инкапсуляцию ранее принятого ControlNet EDS в шаблон профиля устройства, описанного в ИСО 15745, определена в A.2.2.2. Имя файла данной схемы должно быть «EDS_Device_Profile_wrapper.xsd». Синтаксис ASCII прежнего EDS описан в A.4.

6.1.1.2 Device identity

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

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

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

6.1.1.3 Device manager

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

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

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

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

• переустановку устройства в начальное состояние;
• извлечение атрибутов DeviceManager.

6.1.1.4 Device function

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

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

Примечание - Класс DeviceFunction не описан в ИСО 15745-3.

6.1.1.5 Application process

На рисунке 2 в виде диаграммы представлена структура класса ApplicationProcess.

Рисунок 2 — Диаграмма класса ApplicationProcess профиля устройства ControlNet

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

Классы Assembly и Parameter поддерживают атрибуты и сервисы на уровнях класса и экземпляра класса.

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

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

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

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

На рисунке 3 в виде диаграммы представлена структура классов профиля коммуникационной сети ControlNet.

Рисунок 3 — Диаграмма классов профиля коммуникационной сети ControlNet

Существующие форматы профилей коммуникационных сетей ControlNet описаны в A.3.

XML-схема, представляющая шаблон профиля коммуникационной сети ControlNet, определяется в A.3.1.3. Имя файла данной схемы должно быть «CNet_CommNet_Profile.xsd».

XML-схема, представляющая инкапсуляцию ранее принятого ControlNet EDS в шаблон профиля коммуникационной сети, описанного в ИСО 15745, определяется в A.3.2.2. Имя файла данной схемы должно быть «EDS_CommNet_Profile_wrapper.xsd». Ранее принятый синтаксис ASCII EDS описывается в A.4.

6.1.2.2 Application layers

Класс ApplicationLayers представляет комбинированные профили трех верхних уровней OSI — модели интеграции коммуникационной сети ControlNet.

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

• ConnectionManager определяет характеристики, связанные с соединениями и управлением соединениями;
• MessageRouter определяет характеристики, связанные с маршрутизацией внутренних сообщений в устройстве.

Примечание - Объекты Connection Manager и Message Router описаны в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2).

6.1.2.3 Transport layers

Класс TransportLayers представляет комбинированные профили для четырех низших уровней OSI — модели интеграции коммуникационной сети ControlNet.

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

• CNPhysicalLayer определяет характеристики физического уровня (например, провода, задержки);
• CNLinkLayer и ControlNetObject определяют характеристики, связанные с конфигурацией и мониторингом канала передачи данных;
• Port определяет порты устройства, предназначенные для направления сообщений с одного канала передачи данных на другой.

Примечание - Объект ControlNet описан в МЭК 61158-4:2003 (тип 2).

6.1.2.4 Network management

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

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

• ControlNetScheduling определяет характеристики, связанные с распределением запланированного времени передачи;
• Keeper определяет характеристики, связанные с управлением сетью;
• NM-MessageRouter, NM-ConnectionManager и NM-ControlNetObject определяют характеристики, связанные с управлением классами соответствующих объектов.

Примечание - Соответствующие объекты ControlNetScheduling и Keeper описаны в МЭК 61158-4:2003 (тип 2).

6.2. PROFIBUS

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

На рисунке 4 в виде диаграммы представлена структура классов профиля устройства PROFIBUS.

Рисунок 4 — Диаграмма классов профиля устройства PROFIBUS

Информация для классов DeviceIdentity, DeviceManager и ApplicationProcess приведена в ранее принятых форматах EDD и GSD профиля устройства.

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

Пример - Примерами объектов DeviceFunction являются объекты «аналоговый ввод» и «дискретный вывод».

Примечание - Класс DeviceFunction не определен в ИСО 15745-3.

Существующие форматы профилей устройств PROFIBUS описаны в B.2.

XML-схема, представляющая инкапсуляцию ранее принятых форматов EDD и GSD устройства PROFIBUS в шаблон профиля устройства, описанного в ИСО 15745, определена в B.2. Имя файла данной схемы должно быть «GSD_Device_Profile_wrapper.xsd» или «EDD_Device_Profile_wrapper.xsd». Синтаксис ASCII прежнего EDDL описан в МЭК 61804-2, используя профиль PROFIBUS МЭК 61804-2: изд. 1, F.2.

Простые устройства, в которых отсутствует необходимость иметь EDD, должны ссылаться на GSD.

Эквивалентность классов DeviceIdentity, DeviceManager и ApplicationProcess определена в МЭК 61804-2 или в случае ссылки на GSD — в B.4.

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

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

На рисунке 5 в виде диаграммы представлена структура классов профиля коммуникационной сети PROFIBUS.

Рисунок 5 — Диаграмма классов профиля коммуникационной сети PROFIBUS

Существующие форматы профилей коммуникационной сети PROFIBUS описаны в B.3.

Имя файла данной XML-схемы должно быть «GSD_CommNet_Profile.xsd».

XML-схема, представляющая инкапсуляцию ранее принятого GSD устройств в шаблон профиля коммуникационной сети PROFIBUS, описанной в ИСО 15745, определяется в B.3. Имя файла данной схемы должно быть «GSD_CommNet_Profile_wrapper.xsd». Синтаксис ASCII ранее принятого GSD представлен в B.4 и B.5.

6.2.2.2 Application layers

Класс ApplicationLayers коммуникационной сети PROFIBUS представляет комбинированные профили трех верхних уровней OSI — модели интеграции коммуникационной сети PROFIBUS (см. МЭК 61784-1:2003 CP3/1 и CP3/2, особенно подразделы для протокола AL и сервиса AL).

6.2.2.3 Transport layers

Класс TransportLayers коммуникационной сети PROFIBUS представляет комбинированные профили для четырех низших уровней OSI — модели интеграции коммуникационной сети PROFIBUS (см. МЭК 61784-1:2003 CP3/1 и CP3/2, особенно подразделы для протокола DL и сервиса DL).

6.2.2.4 Network management profile

Класс NetworkManagement profile коммуникационной сети PROFIBUS представляет конфигурирование сети и возможность регулировки характеристик модели интеграции коммуникационной сети PROFIBUS.

6.3. P-NET

6.3.1. Профиль устройства

Переменные в устройствах P-NET обычно организованы в каналы (channels). Channel представляет собой совокупность связанных переменных и функций для единичного сигнала процесса. Он может поддерживать до 16 регистров, каждый из которых имеет свой собственный номер SoftWire (SWNo). Содержание каждого регистра может включать любой тип данных, в том числе сложные структуры, например многомерные таблицы и базы данных.

В каждом устройстве P-NET должен быть представлен хотя бы один сервисный канал (serviceChannel). ServiceChannel содержит информацию, используемую для облегчения получения сервиса устройства, например глобальный уникальный идентификатор (GUID), информацию об ошибках и т.д. Все другие каналы, включенные в данное устройство, зависят от типа устройства. Устройство может включать ряд каналов одинакового типа и/или совокупность каналов различного типа.

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

Профиль устройства P-NET должен описывать все достижимые в сети переменные и каналы в устройстве в объекте ApplicationProcess. Профиль устройства включает также объекты для управления устройством и его идентификации (см. рисунок 6).

Рисунок 6 — Диаграмма классов профиля устройства P-NET

Пример 2 — Примеры Device Function — расходомер, контроллер, аналоговый ввод 4 — 20 мА, цифровой ввод/вывод.

Примечание — В P-NET не существует специальных сервисов для доступа к характеристикам объектов DeviceFunction, DeviceManager и DeviceIdentity. Данные характеристики могут быть отображены в объектах ApplicationProcess и доступны в сети с помощью Application Protocol Data Unit (APDU), установленного в классе P-NET ApplicationLayers (см. 6.3.2.2).

Атрибуты и подклассы классов профиля устройства подробно изложены в C.1, где установлены XML-схемы, требующиеся для профилей устройств. Имя файла данной схемы должно быть «P-NetDeviceProfile.XSD».

6.3.2. Профиль коммуникационной сети

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

На рисунке 7 в виде диаграммы представлена структура классов профиля коммуникационной сети P-NET.

Рисунок 7 — Диаграмма классов профиля коммуникационной сети P-NET

XML-схема, представляющая профиль коммуникационной сети P-Net, определяется в C.2. Имя файла данной схемы должно быть «P-NetCommNetworkProfile.XSD».

6.3.2.2 Application layers

Application layers коммуникационной сети P-NET должен всегда предоставлять сервисы и элементы протокола, необходимые для оценки переменных, определенных в профиле устройства P-NET. Сервисы и элементы протокола представлены в APDU.

6.3.2.3 Transport layers

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

Класс TransportLayers представляет комбинированные профили для четырех низших уровней OSI — модели интеграции коммуникационной сети. Объект TransportLayers состоит из одного или нескольких объектов PhysicalLayer (по одному на каждый физический порт) и объекта DataLinkLayer.

6.3.2.3.2 PhysicalLayer

Объект PhysicalLayer должен определять поддерживаемый электрический эталон и скорость двоичной передачи в бодах. Действующие электрические эталоны — RS232 и RS485. Правильные значения скорости двоичной передачи в бодах для RS232 — 1200, 2400, 4800, 9600, 19 200 и 38 400 бит/с. Для RS485 правильное значение скорости двоичной передачи в бодах только 76 800 бит/с.

6.3.2.3.3 DataLinkLayer

Уровень DataLinkLayer коммуникационной сети P-NET должен всегда предоставлять элементы протокола, необходимые, согласно классу устройства, установленному объектом NetworkManagement. Наиболее подходящие классы устройств — Master, Simple node или Slave.

Объект DataLinkLayer должен установить поддерживаемый метод обнаружения ошибок. Наиболее подходящие методы — Normal и Reduced.

6.3.2.4 NetworkManagement

Диаграмма класса NetworkManagement представлена на рисунке 8. Она состоит из нескольких объектов типа Master, Simple Node или Slave для каждой физической точки соединения, определенной в профиле OSI-U.

Рисунок 8 — Диаграмма класса NetworkManagement профиля коммуникационной сети P-NET

6.4. WorldFIP

6.4.1. Профиль устройства

6.4.1.1 Структура главного класса

На рисунке 9 в виде диаграммы представлена структура главного класса профиля устройства WorldFIP.

Рисунок 9 — Диаграмма класса профиля устройства WorldFIP

Требуемый формат профиля устройства WorldFIP описан в D.1. XML-схема, представляющая шаблон профиля устройства WorldFIP, определена в D.1.3. Имя файла данной схемы должно быть «WFIPDEVP.XSD».

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

Примечание 2 — Эти диаграммы отображены в одной и той же XML-схеме, определенной в D.1.3.

Примечание 3 — Диаграммы класса профиля устройства WorldFIP, показанные на рисунках 9 - 12, определяют главные классы. Некоторые классы подвергаются дальнейшей декомпозиции с учетом подробностей, определенных в D.1.

6.4.1.2 Device identity

Класс DeviceIdentity состоит из дочерних классов, показанных на рисунке 10 и описанных в таблице 2.

Рисунок 10 — Диаграмма класса DeviceIdentity

Таблица 2

Декомпозиция класса DeviceIdentity

6.4.1.3 Device Manager

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

На рисунке 11 в виде диаграммы представлен класс DeviceManager профиля WorldFIP.

Рисунок 11 — Диаграмма класса DeviceManager профиля WorldFIP

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

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

6.4.1.3.2 PhysicalNode

6.4.1.3.2.1 Identifier

Каждый физический узел имеет уникальный идентификатор.

6.4.1.3.2.2 ManagementVariable

Physical node управляются с помощью SM_MPS и используют две или несколько переменных управления, роль и идентификаторы которых зафиксированы, на основании значения DeviceConformityClass (см. D.1.2).

6.4.1.3.2.3 LogicalNode

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

Логический узел может быть сформирован из нескольких логических узлов.

Подробные сведения о логических узлах приведены в D.1.2.

6.4.1.3.2.4 FunctionBlock

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

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

Функциональный блок может состоять из нескольких функциональных блоков.

Подробные сведения о функциональных блоках приведены в D.1.2.

6.4.1.3.2.5 ExchangeBlock

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

6.4.1.4 Device function

На рисунке 12 в виде диаграммы представлен класс DeviceFunction профиля устройства WorldFIP.

Рисунок 12 — Диаграмма класса DeviceFunction профиля устройства WorldFIP

Примечание - Определение объекта DeviceDataSheet, относящегося к классу DeviceFunction, не рассматривается в данном стандарте.

6.4.1.5 Application process

Объект ApplicationProcess состоит из функциональных блоков и дополнительных блоков обмена, представленных в 6.4.1.3.2.4 и 6.4.1.3.2.5.

6.4.2. Профиль коммуникационной сети

6.4.2.1 Структура главного класса

Требуемый формат профиля коммуникационной сети WorldFIP описан в D.2. XML-схема, представляющая шаблон профиля коммуникационной сети WorldFIP, определена в D.2.5. Имя файла данной схемы должно быть «WFIPCOMP.XSD».

Примечание 1 — Для лучшей читаемости диаграмма класса профиля коммуникационной сети WorldFIP должна быть разделена на пять диаграмм класса.

Примечание 2 — Эти диаграммы отображены в одной и той же XML-схеме, определенной в D.2.5.

Примечание 3 — Диаграммы класса профиля коммуникационной сети WorldFIP, показанные на рисунках 13 - 18, определяют главные классы. Некоторые классы подвергаются дальнейшей декомпозиции с учетом подробностей, описанных в D.2.

На рисунке 13 в виде диаграммы представлена структура главного класса профиля коммуникационной сети WorldFIP.

Рисунок 13 — Диаграмма класса профиля коммуникационной сети WorldFIP

Семантика атрибута CommunicationNetworkConformityClass подробно изложена в D.2.

6.4.2.2 Application layers

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

Класс ApplicationLayers представляет комбинированные профили для трех верхних уровней OSI — модели интеграции коммуникационной сети. Он устанавливает поддерживаемые элементы сервиса приложения и ассоциированные с ними сервисы.

ASE (Application Service Elements), определенные для WorldFIP, могут быть установлены следующими объектами профиля:

• MPS (Manufacturing Periodic/aperiodic Services).

MPS представляет собой периодическое/апериодическое обновление распределенной базы данных. Эти сервисы присутствуют во всех профилях коммуникационной сети WorldFIP;

• MCS (Message Common Services).

MCS представляет собой дополнительный уровень интерфейса, поддерживающий сервисы сообщений;

• SubMMS.

SubMMS представляет собой дополнительное подмножество сервисов MMS (Manufacturing Messages Specifications).

6.4.2.2.2 MPS

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

На рисунке 14 представлен прикладной уровень MPS профиля коммуникационной сети WorldFIP.

Рисунок 14 — Прикладной уровень MPS профиля коммуникационной сети WorldFIP

Семантика атрибута MPSConformityClass подробно изложена в D.2.2.1.2.

6.4.2.2.2.2 IdentifiedVariable

MPS обеспечивает периодический и апериодический обмен переменными между одним производителем и одной или несколькими сущностями приложения. Все общие атрибуты переменных определены в классе IdentifiedVariable. Подробные сведения об идентифицированных переменных приведены в XML-схеме в D.2.5.

6.4.2.2.2.3 ProducedVariable

В пределах распределенного приложения одна уникальная сущность приложения декларируется как производитель значений переменных. Класс ProducedVariable объединяет все атрибуты, относящиеся к переменной внутри уровня приложения производителя. Подробные сведения о произведенных переменных приведены в XML-схеме в D.2.5.

6.4.2.2.2.4 ConsumedVariable

Одна или несколько сущностей приложения декларируются как потребители значений переменных. Класс ConsumedVariable объединяет все атрибуты, относящиеся к переменной внутри уровня приложения потребителя. Подробные сведения о потребленных переменных приведены в XML-схеме в D.2.5.

6.4.2.2.2.5 ThirdPartyVariable

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

6.4.2.2.2.6 IdentifiedVariableList

Уровень приложения MPS поддерживает определение и обработку списков переменных. Список переменных определен универсально, и переменным присвоены значения на уровне сущности приложения. Список состоит исключительно из потребленных переменных. Подробные сведения о списках переменных приведены в XML-схеме в D.2.5.

6.4.2.2.2.7 TypeConstructor

Тип переменной определяется классом TypeConstructor, на который переменная имеет ссылку. На рисунке 15 показана структура класса объекта TypeConstructor.

Рисунок 15 — Переменная TypeConstructor MPS профиля коммуникационной сети WorldFIP

Подробные сведения о TypeConstructor приведены в D.2.2.1.1.

6.4.2.2.2.8 VariableAccess

VariableAccess относится к переменным и указывает используемый режим доступа. Подробные сведения о доступе к переменным приведены в XML-схеме в D.2.5.

6.4.2.2.3 MCS

На рисунке 16 представлен прикладной уровень MCS профиля коммуникационной сети WorldFIP.

Рисунок 16 — Прикладной уровень MCS профиля коммуникационной сети WorldFIP

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

6.4.2.2.4 SubMMS

На рисунке 17 представлен прикладной уровень SubMMS профиля коммуникационной сети WorldFIP.

Рисунок 17 — Прикладной уровень SubMMS профиля коммуникационной сети WorldFIP

Семантика атрибута MMSConformityClass подробно изложена в D.2.2.3.

6.4.2.3 Transport layers

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

Объект TransportLayers представляет комбинированные профили для четырех нижних уровней OSI — модели интеграции коммуникационной сети. Объект TransportLayers должен быть разделен на один или несколько объектов PhysicalLayer и объект DataLinkLayer.

6.4.2.3.2 DataLinkLayer

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

На рисунке 18 представлен Data Link layer профиля коммуникационной сети WorldFIP.

Рисунок 18 — Data Link layer профиля коммуникационной сети WorldFIP

Семантика атрибута DLConformityClass подробно изложена в D.2.3.

6.4.2.3.2.2 DLVariable

Data Link layer профиля коммуникационной сети WorldFIP поддерживает циклический обмен переменными и запрос об обмене переменными.

Подробные сведения о переменных приведены в XML-схеме в D.2.5.

6.4.2.3.2.3 Message

Data Link layer профиля WorldFIP поддерживает циклическую передачу сообщений и апериодическую передачу сообщений.

Подробные сведения о сообщениях приведены в XML-схеме в D.2.5.

6.4.2.3.3 PhysicalLayer

Объект PhysicalLayer идентифицирует MAUType, тип интерфейса и поддерживаемую скорость двоичной передачи (в бодах) на физическом уровне.

6.4.2.4 NetworkManagement

Класс NetworkManagement должен определять функциональные возможности для определенной конфигурации конкретной сети WorldFIP. Управление сетью в данном случае определяется в EN 50170:1996, том 3, часть 7-3. В зависимости от класса соответствия управления сетью, документально оформленного в атрибуте NMConformityClass, WorldFIP использует SM_MPS и опционально SMS.

Функции управления сетью подразделяются на три категории:

• установка и модификации;
• проверка согласованности конфигурации;
• настройка работы в сети.

Семантика атрибута NMConformityClass подробно изложена в D.2.4.2.

6.5. INTERBUS

6.5.1. Профиль устройства

6.5.1.1 Структура главного класса

На рисунке 19 в виде диаграммы представлена структура главного класса профиля устройства INTERBUS.

Рисунок 19 — Диаграмма класса профиля устройства INTERBUS

Требуемый формат профилей устройства INTERBUS описан в E.1. XML-схема, представляющая шаблон профиля устройства INTERBUS, определена в E.1.6.1. Имя файла данной схемы должно быть «FDCML.XSD».

Примечание 1 — Для лучшей читаемости диаграмма класса профиля устройства INTERBUS разделена на шесть диаграмм класса.

Примечание 2 — Эти диаграммы отображены в одной и той же XML-схеме, определенной в E.1.6.1.

Примечание 3 — Диаграммы класса профиля устройства INTERBUS, показанные на рисунках 19 - 25, определяют главные классы. Некоторые классы подвергаются дальнейшей декомпозиции с учетом подробностей, определенных в Приложении E.

6.5.1.2 Device identity

Класс DeviceIdentity представлен на рисунке 20.

Рисунок 20 — Диаграмма класса DeviceIdentity профиля устройства INTERBUS

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

Таблица 3

Декомпозиция класса DeviceIdentity

6.5.1.3 Device manager

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

На рисунке 21 представлен класс DeviceManager профиля INTERBUS.

Рисунок 21 — Диаграмма класса DeviceManager профиля INTERBUS

6.5.1.3.2 LocalDataDescriptionItemList, localDataItemlocalDataDescription

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

6.5.1.3.3 DeviceStructure

6.5.1.3.3.1 Обзор

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

6.5.1.3.3.2 ChannelList

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

6.5.1.3.3.3 MAUList, MAU

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

6.5.1.3.3.4 SlotList, slot

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

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

6.5.1.3.3.5 IndicatorList, LEDList, LED

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

Примечание - Класс IndicatorList может быть расширен в будущих изданиях данного стандарта.

6.5.1.3.4 CommunicationEntity

6.5.1.3.4.1 Обзор

На рисунке 22 в виде диаграммы представлен класс CommunicationEntity.

Рисунок 22 — Диаграмма класса communicationEntity профиля INTERBUS

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

Пример - Примером устройства, включающего два объекта communicationEntity, является системное коммутационное устройство, в котором объединяются профили INTERBUS ведомого и ведущего устройств (см. рисунок 23).

Рисунок 23 — Пример устройства с двумя объектами communicationEntity

6.5.1.3.4.2 AdditionalItemList, additionalItem

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

Примечание - Определение объекта additionalItemType не входит в область данного стандарта.

Пример - Документация устройства.

6.5.1.3.4.3 ProcessDataDescriptionList, processDataDescription

Объект processDataDescriptionList представляет собой собрание объектов processDataDescription. Эти объекты представляют описания данных процесса. Объект processDataDescription может использоваться объектом channel.

6.5.1.3.4.4 ProcessDataAssemblyList, processDataAssembly

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

6.5.1.3.4.5 ParameterDecsriptionList, parameterDecscription

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

6.5.1.3.4.6 ParameterAssemblyList, ParameterAssembly

Объект parameterAssemblyList представляет собой собрание объектов parameterAssembly. Объекты parameterAssembly являются описаниями группы объектов parameterDescription. Объект parameterAssembly обеспечивает связи с объектами parameterDescription.

6.5.1.3.4.7 MethodDescriptionList, methodDescription

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

6.5.1.3.4.8 LogicalConnectionPointList, logicalConnectionPoint

Объект logicalConnectionPointList представляет собой собрание объектов logicalConnectionPoint. Объект logicalConnectionPoint описывает конечную точку соединения (возможные атрибуты см. в E.1.4.6).

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

6.5.1.3.4.9 LogicalConnectionPointAssemblyList, logicalConnectionPointAssembly

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

6.5.1.3.4.10 MAUUsageList, MAUUsage

Объект MAUUsageList представляет собой собрание объектов MAUUsage. Объекты MAUUsage должны определять, какие объекты MAU используются communicationEntity.

6.5.1.3.4.11 InternalConnectionPointList, internalConnectionPoint

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

6.5.1.3.4.12 SlotUsageList, slotUsage

Объект slotUsageList представляет собой собрание объектов slotUsage. Объекты slotUsage должны определять, какие слоты ассоциированы с данной communicationEntity.

6.5.1.3.4.13 CfgItemList

Объект cfgItemList может состоять из объектов dedicatedCfgItem и объектов uncomittedCfgItem.

6.5.1.3.4.14 DedicatedCfgItem

Объект dedicatedCfgItem должен представлять собой элемент конфигурации с атрибутом dedicatedCfgItemType согласно определениям в таблице E.4 и таблице E.5. Объект dedicatedCfgItem должен использоваться для установления соответствующих характеристик конфигурации.

6.5.1.3.4.15 UncommittedCfgItem

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

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

Пример - Описание DIP-переключателя, который изменяет код идентификации (ID) устройства.

6.5.1.3.5 ProcessingEntity

На рисунке 24 представлен класс processingEntity профиля устройства INTERBUS.

Рисунок 24 — Диаграмма класса processingEntity профиля устройства INTERBUS

ProcessingEntity описывает любую сущность устройства, которая не является communicationEntity.

Примечание — Описание дочерних объектов см. в 6.5.1.3.4.

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

6.5.1.4 DeviceFunction

6.5.1.4.1 Обзор

DeviceFunction в виде диаграммы представлен на рисунке 25.

Рисунок 25 — Диаграмма класса DeviceFunction профиля устройства INTERBUS

Для того чтобы создать множественные представления функций устройства, используется дополнительная XML-схема для описания DeviceFunction. Имя файла данной схемы должно быть «FDCMLИСО15745DeviceFunction.XSD». XML-схема DeviceFunction определена в E.1.6.3.

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

6.5.1.4.2 ParameterList, parameter

Объект parameterList представляет собой собрание объектов parameter. Объект parameter описывает параметры устройства с функциональной точки зрения. Этот объект соединяется с объектом коммуникаций в CommunicationEntity.

6.5.1.4.3 FunctionList, function, inputsList, outputsList

Объект functionList представляет собой собрание объектов function. Данный объект function должен состоять из inputsList и outputsList. Эти списки должны содержать перечень ссылок на объекты parameter.

6.5.1.5 Application process

Объект applicationProcess может быть представлен одной или несколькими подходящими XML-схемами.

Примечание - Эти схемы не определены в ИСО 15745-3.

6.5.2. Профиль коммуникационной сети

6.5.2.1 Структура классов

На рисунке 26 в виде диаграммы представлена структура классов профиля коммуникационной сети INTERBUS.

Рисунок 26 — Диаграмма классов профиля коммуникационной сети INTERBUS

XML-схема, представляющая профиль коммуникационной сети INTERBUS, определена в E.2. Имя файла данной схемы должно быть «INTERBUSCommNetworkProfile.XSD».

6.5.2.2 Transport layers

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

Объект TransportLayers должен представлять комбинированные профили четырех нижних уровней OSI — модели интеграции коммуникационной сети. Объект TransportLayers должен быть разделен на один или несколько объектов physicalLayerInterface и объект dataLinkLayerInterface.

6.5.2.2.2 PhysicalLayerInterface

Объект physicalLayerInterface идентифицирует MauType, тип интерфейса и поддерживаемую скорость двоичной передачи в бодах интерфейса физического уровня. Правильные типы интерфейса — localBus и remoteBus.

6.5.2.2.3 DataLinkLayerInterface

6.5.2.2.3.1 ProcessDataChannel

Объект processDataChannel должен устанавливать длину канала обработки данных в битах.

6.5.2.2.3.2 ParameterChannel

Класс parameterChannel должен устанавливать длину канала параметров в октетах.

6.5.2.3 Application layers

Класс ApplicationLayers должен представлять комбинированные профили трех верхних уровней OSI — модели интеграции коммуникационной сети. Он устанавливает поддерживаемые элементы сервиса приложений и ассоциированные с ними сервисы.

ASE (Application Service Elements), определенные в МЭК 61158-5:2003, 13.2, могут быть установлены следующими объектами профилей:

• applicationProcess;
• applicationRelationship;
• objectManagement;
• functionInvocation;
• другие.

Для переменных ASE выбираемые типы данных указаны на рисунке 26. Типы данных определены в МЭК 61158-5:2003, раздел 5.

6.5.2.4 Network management

6.5.2.4.1 NetworkAccessType, AssignedIDCode

Класс NetworkManagement должен определять функциональные возможности конфигурации конкретной сети профиля INTERBUS. Он включает коды идентификации (ID) — наименьший значащий октет кода профиля INTERBUS, присвоенный частному профилю коммуникационной сети, и объект networkAccessType, который включает следующее:

• либо основной профиль для основных функциональных характеристик профиля INTERBUS в терминах элементов (объект masterConfigurationElements), необходимых для конфигурирования ведущей части (master) INTERBUS;
• либо подчиненный профиль для подчиненных функциональных характеристик профиля INTERBUS в терминах элементов (объект slaveConfigurationElements), необходимых для конфигурирования подчиненной части профиля INTERBUS.

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

6.5.2.4.2 CommunicationProfile

Объект communicationProfile должен установить идентификаторы готовых к использованию коммуникационных профилей (см. 6.5.2.4.3).

6.5.2.4.3 Communication profile identifier

Communication profile identifiers определены в МЭК 61784-1:2003, подраздел 10.1. Разработчик AIP может установить дополнительные коммуникационные профили, а идентификаторами для новых коммуникационных профилей должны служить 3-значные номера от 680 до 699.

Приложение A (справочное)

ШАБЛОНЫ ПРОФИЛЕЙ CONTROLNET

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

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

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

• сохранение информации устройства в печатном или электронном виде;
• выделенные Parameter Objects, которые предоставляют открытый интерфейс со значениями данных индивидуальных конфигурации/параметра и могут также загружать дополнительную информацию по конфигурации, например дескриптивный текст, тип данных, пределы данных и величины по умолчанию;
• выделенные Configuration Assembly, которые допускают массовую загрузку и перекачку данных конфигурации путем группировки отдельных значений данных конфигурации/параметров;
• комбинации указанных выше методов.

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

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

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

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

• шаблонов профилей коммуникационных сетей и устройств согласно определениям в ИСО 15745-1;
• инкапсуляции файлов EDS в шаблоны ИСО 15745 («оболочки»);
• EDS, включая общую семантическую информацию.

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

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

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

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

XML-файлы профиля устройства должны соответствовать XML-схеме профиля устройства, приведенной в A.2.1.3.3.

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

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

A.2.1.2.1. ProfileBody

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

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

A.2.1.2.2. DeviceIdentity

Этот элемент устанавливает поддерживаемые атрибуты и операции сущности Identity Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с дополнительной информацией для полной идентификации устройства. Когда это целесообразно, он также указывает фактические значения атрибутов экземпляра.

Семантика субэлементов DeviceIdentity_InstanceAttributes установлена в таблице A.1.

Таблица A.1

Элементы DeviceIdentity_InstanceAttributes

A.2.1.2.3. DeviceManager

Данный элемент устанавливает поддерживаемые атрибуты класса и сущности Identity Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с дополнительной информацией по управлению устройством. Когда это целесообразно, он также указывает фактические значения атрибутов экземпляра.

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

A.2.1.2.4. DeviceFunction

Содержание данного элемента в настоящем стандарте подробно не рассматривается.

A.2.1.2.5. ApplicationProcess

A.2.1.2.5.1. Assembly

Этот элемент устанавливает поддерживаемые атрибуты и операции экземпляров Assembly Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с описанием отдельных экземпляров.

Семантика субэлементов Assem, ProxyAssem и ProxiedAssem элемента Assembly определена в A.4.1.4.8 и A.4.1.5.3.2.

A.2.1.2.5.2. Parameter

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

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

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

A.2.1.2.5.3. ParameterGroup

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

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

A.2.1.3. XML-схемы

A.2.1.3.1. MasterTemplateTypes.xsd

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

A.2.1.3.2. CIPDataTypes.xsd

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

A.2.1.3.3. CIP_Device_Profile.xsd

Примечание — Данная XML-схема включает файлы «MasterTemplateTypes.xsd» (см. A.2.1.3.1) и «CIPDataTypes.xsd» (см. A.2.1.3.2).

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

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

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

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

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

Таблица A.2

Элементы ExternalProfileHandle

Если элементы Deviceidentity, DeviceManager, DeviceFunction и ApplicationProcess присутствуют, они должны быть совместимы с форматами, установленными в A.2.1.3.3.

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

A.2.2.2. XML-схема: EDS Device Profile wrapper.xsd

Примечание — Данная XML-схема включает файл «MasterTemplateTypes.xsd» (см. A.2.1.3.1).

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

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

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

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

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

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

A.3.1.2.1. ProfileBody

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

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

A.3.1.2.2. Application layers

A.3.1.2.2.1. ConnectionManager

Данный элемент устанавливает атрибуты и операции поддерживаемого экземпляра Connection Manager Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)) совместно с описанием отдельных экземпляров соединений.

Семантика субэлементов Connection, ProxyConnect и ProxiedConnect элемента ConnectionDescriptions определена в A.4.1.4.9 и A.4.1.5.3.3.

A.3.1.2.2.2. MessageRouter

Данный элемент устанавливает атрибуты и операции поддерживаемого экземпляра Message Router Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)).

A.3.1.2.3. TransportLayers

A.3.1.2.3.1. CNPhysicalLayer

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

Семантика этих субэлементов установлена в таблице A.3.

Таблица A.3

Элементы CNPhysicalLayer

A.3.1.2.3.2. CNLinkLayer

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

Семантика относящихся к нему субэлементов установлена в таблице A.4.

Таблица A.4

Элементы CNLinkLayer

A.3.1.2.3.3. ControlNetObject

Этот элемент определяет атрибуты и операции поддерживаемого экземпляра ControlNet Object (см. МЭК 61158-4:2003 (тип 2)).

A.3.1.2.3.4. Ports

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

Семантика субэлемента Port элемента Ports указана в A.4.1.4.10 и A.4.2.2.2.

A.3.1.2.4. NetworkManagement

A.3.1.2.4.1. NM-ControlNetObject

Этот элемент устанавливает атрибуты и операции поддерживаемого класса ControlNet Object (см. МЭК 61158-4:2003 (тип 2)).

A.3.1.2.4.2. NM-ConnectionManager

Этот элемент устанавливает атрибуты и операции поддерживаемого класса Connection Manager Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)).

A.3.1.2.4.3. NM-MessageRouter

Этот элемент устанавливает атрибуты и операции поддерживаемого класса Message Router Object (см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)).

A.3.1.2.4.4. Keeper

Этот элемент устанавливает атрибуты и операции поддерживаемого класса и экземпляра Keeper Object (см. МЭК 61158-4:2003 (тип 2)).

A.3.1.2.4.5. ControlNetScheduling

Этот элемент устанавливает атрибуты и операции поддерживаемого класса и экземпляра ControlNet Scheduling Object (см. МЭК 61158-4:2003 (тип 2)).

A.3.1.3. XML-схема: CNet_CommNet_Profile.xsd

Примечание — Данная XML-схема включает файлы «MasterTemplateTypes.xsd» (см. A.2.1.3.1) и «CIPDataTypes.xsd» (см. A.2.1.3.2).

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

A.3.2.1. Общие положения

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

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

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

A.3.2.2. XML-схема: EDS_CommNet_Profile_wrapper.xsd

Примечание — Эта XML-схема включает файл «MasterTemplateTypes.xsd» (см. A.2.1.3.1).

A.4. Электронный бланк данных (EDS)

A.4.1. Общие требования CIP EDS

A.4.1.1. Общие положения

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

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

Файл EDS определяется как файл ASCII, включающий ASCII — представление объектов в устройстве, к которым имеется доступ из сети (например, Parameter и Assembly), и некоторую дополнительную информацию, необходимую для поддержки адресации объектов.

A.4.1.2. Содержание EDS

A.4.1.2.1. Структура EDS

Один файл должен включать полный EDS. EDS должен состоять из секций. В таблице A.5 содержатся обобщенные данные о структуре и секциях для нескольких основанных на CIP сетей, соответствующие ограничители ранее известных секций и порядок этих секций в EDS.

Таблица A.5

Структура файлов CIP EDS

Содержание EDS должно быть организовано следующим образом:

• все файлы EDS должны включать раздел File Description, являющийся первой секцией файла EDS и использующий установленный ограничитель [File];
• все файлы EDS должны включать раздел Device Description, располагающийся сразу после раздела File Description и использующий установленный ограничитель [Device];
• опциональные разделы, описанные в настоящей спецификации, могут быть представлены в любом порядке при условии, что внутри файла EDS отсутствуют упреждающие ссылки;
• относящиеся к поставщику опциональные разделы должны использовать установленные ограничители [VendorID_vendorspecifickeyword], согласно A.4.1.2.2.11, и размещаться после всех разделов, определенных в настоящей спецификации.

A.4.1.2.2. Правила форматирования EDS

A.4.1.2.2.1. Общие положения

Файл EDS должен состоять из разделов, вводов, полей, комментариев и пустых мест. Данный подраздел определяет правила, которые должны соблюдаться при определении EDS.

A.4.1.2.2.2. Пустое место в EDS

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

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

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

A.4.1.2.2.3. Символы дескриптора

Все дескрипторы внутри файла EDS должны состоять из символов ASCII, входящих в следующий список:

• буквы верхнего регистра от A до Z;
• буквы нижнего регистра от a до z;
• цифры от 0 до 9;
• специальный символ нижнего тире «_»;
• символ пробела.

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

A.4.1.2.2.4. Разделы

Файл EDS должен быть разделен на требуемые и необязательные разделы.

A.4.1.2.2.5. Ограничители разделов

Каждый раздел EDS должен быть ограничен ключевыми словами раздела в квадратных скобках (принятыми ограничителями). Принятые ограничители раздела указаны в таблице A.5.

A.4.1.2.2.6. Дескрипторы раздела

Дескриптор каждого раздела определяется как текст между ограничителем «[» дескриптора в начале раздела и конечным ограничителем «]». Символы, разрешенные для использования в дескрипторах раздела, определены в A.4.1.2.2.3. Существует два типа дескрипторов раздела — общий и относящийся к поставщику (продавцу).

A.4.1.2.2.7. Порядок разделов

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

A.4.1.2.2.8. Вход

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

A.4.1.2.2.9. Дескрипторы входа

Дескриптор входа должен состоять из уникальной последовательности символов дескриптора, определенных в A.4.1.2.2.3. Существует два типа дескрипторов входа — общий и относящийся к поставщику (продавцу).

A.4.1.2.2.10. Общий дескриптор

Общий дескриптор должен быть всегда определен в спецификации CIP ассоциациями ответственных поставщиков (продавцов). Общий дескриптор никогда не должен начинаться с цифрового символа.

A.4.1.2.2.11. Дескрипторы, относящиеся к поставщику

Дескрипторы могут относиться к поставщику (продавцу). Эти дескрипторы должны начинаться с идентификатора компании-поставщика (Vendor ID) с последующим дополнением через нижнее тире (VendorID_VendorSpecificKeyword). Идентификатор поставщика должен быть представлен в виде десятичной записи числа, не включающей нули на первых позициях. Каждый поставщик несет ответственность за поддержание и документальное оформление относящихся к нему дескрипторов.

A.4.1.2.2.12. Поля входа

Каждый вход должен включать одно или несколько полей. Все поля должны быть разделены ограничителями в виде запятых. Значение поля(ей) должно зависеть от контекста раздела. Поля ввода могут быть обязательными или необязательными, согласно определениям в данной спецификации. Пробелы или отсутствие данных между запятыми должны использоваться для непредоставленных необязательных полей. Точка с запятой может использоваться для обозначения отсутствия последующих необязательных полей. Термин «Номер поля» должен показывать положение поля на входе. Поля нумеруются слева направо (или сверху вниз) начиная с номера один.

A.4.1.2.2.13. Дескрипторы поля

Дескриптор поля должен состоять из уникальной последовательности символов дескриптора, указанных в A.4.1.2.2.3. Существует два типа дескрипторов поля — общий и относящийся к поставщику (продавцу).

A.4.1.2.2.14. Поля сложных данных

Некоторые поля входа должны быть установлены для данных, которые не могут быть заданы одним значением между ограничивающими запятыми. Возможность дополнительного разграничения поля входа определяется путем использования одного или нескольких наборов фигурных скобок «{» и «}». Контенты между знаками скобок следует рассматривать как единый элемент или ввод. Содержание может быть сгруппировано с помощью нескольких скобок.

A.4.1.2.2.15. Комментарии

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

Пример комментария приведен далее.

A.4.1.2.2.16. Пример структуры форматирования EDS

Примеры на рисунке A.1 поясняют структуру EDS.

Рисунок A.1 — Пример структуры форматирования EDS (информативный)

A.4.1.2.3. Требования к наименованию файла

Соглашения по наименованию файлов EDS на диске отсутствуют, кроме файлов в среде DOS/Windows: эти файлы должны иметь суффикс «.EDS», добавляемый к имени файла.

A.4.1.3. Требования к кодированию данных EDS

A.4.1.3.1. Общие положения

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

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

Типы элементарных данных, установленные в спецификации CIP, используются также в других элементах EDS, однако их значение преобразуется согласно описанию в следующих подразделах (см A.4.1.3.3 - A.4.1.3.10).

Некоторые типы данных используются только в файлах EDS (см. A.4.1.3.11 - A.4.1.3.14).

A.4.1.3.2. ASCII: соглашение относительно символов в файлах

Все данные в EDS должны быть кодированы с использованием 8-битных символов ASCII, в которых все ссылки на «ASCII-символы» означают 8-битный формат знаков ASCII (согласно определениям в таблицах 1 и 2, строка 00 ИСО/МЭК 10646-1:2000). Символы, которые не могут быть показаны на терминале ANSI, не должны использоваться в идентификаторах имен или в представлении данных. Правильные значения символа ASCII должны включать разделитель строк, табуляцию и десятичные знаки от 32 до 126.

A.4.1.3.3. Соглашение о символьной строке — EDS_Char_Array

A.4.1.3.3.1. Общие положения

Все строковые данные файла EDS должны быть символьными строками фиксированной длины, без символов конца строки и должны быть заключены в двойные кавычки (тип данных EDS_Char_Array).

Существует две формы преобразования строковых данных. Символы, находящиеся между двойными кавычками, должны быть преобразованы в 8-битные символы ASCII. Символы, находящиеся между двойными кавычками, перед которыми стоит прописная буква L, должны быть преобразованы в символы UNICODE (16-битные).

Пример - «Данные результаты представляют собой строку, состоящую из 8-битных символов».

Примечание — Текст\u03C0 определяет единичный 16-битный символ, значение которого 03C0. В наборе символов UNICODE — это таблица 9, ряд 3, греческий символ для строчной «Pi». Описания последовательности переключения кода символов приведены в A.4.1.3.3.5.

A.4.1.3.3.2. Обработка недостаточного количества символов в поле строки

Интерпретирующая программа EDS должна использовать выравнивание знаков в поле по правому знаку или разряду знаков в поле и заполнять все неуказанные символы пробелами (ASCII 0x20) впереди по всей оставшейся длине строки.

Пример - Если параметр имеет максимальную длину строки 8 и получает строку «123AB», эта строка интерпретируется как «~~~123AB», где знаки «тильда» (~) соответствуют пробелам.

A.4.1.3.3.3. Обработка избыточного числа символов в поле строки

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

Пример - Если в параметрах обозначена максимальная длина строки — 8 знаков, а полученная строка, например, «123ABCDEFG», она обрезается и интерпретируется как «123ABCDE».

A.4.1.3.3.4. Конкатенация строки

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

Пример 1 -

The line            :  "ABC"  "123"  "XYZ"
is interpreted as  :  "ABC123XYZ"

Строки могут быть также и на отдельных строчках.

Пример 2 -

The following lines:

«ABC» $this is a comment

«123»

«XYZ»

are also interpreted as: «ABC123XYZ»

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

Пример 3 — L «ABC» «123» «XYZ» — то же самое, что L «ABC123XYZ».

A.4.1.3.3.5. Последовательности переключения кода строки

Интерпретирующая программа EDS должна узнавать все последовательности переключения кода, указанные в таблице A.6. Интерпретация зависит от приложения.

Таблица A.6

Последовательности переключения кода строки

Если встречаются последовательности, не указанные выше, интерпретирующее устройство должно отбраковать всю строку и показать ошибку. Файлы EDS должны содержать только последовательности переключения кода строки, определенные в таблице A.6.

A.4.1.3.4. ASCII: соглашение по строке (STRING, SHORT_STRING, STRING2)

Все типы строковых данных (STRING, SHORT_STRING, STRING2), используемые в атрибутах объектов, должны конвертироваться в EDS_Char_Array в файле EDS.

A.4.1.3.5. STRINGI

Тип данных «Международная строка CIP (STRINGI)» кодируется в файле EDS как представление сложных данных. Полное содержание входа STRINGI должно быть заключено в двух скобках. После числа элементов языка, определенного как USINT, должны следовать определения элементов языка, каждое из которых заключается в две скобки и отделяется запятой. Каждый элемент языка входа STRINGI должен быть задан в виде четырех полей. Первое поле (выбор языка) должно быть выражено строкой фиксированной длины точно из трех знаков, заключенных в метки из двойных кавычек, и представлять код языка согласно определениям в ИСО 639-2/Т. Тип данных строки должен быть выражен с помощью кода типа данных, согласно определениям в спецификации CIP для STRING, STRING2, STRINGN или SHORT_STRING. Выбор набора символов должен быть выражен как UINT согласно определениям в IANA MIB кодов печати (RFC 1759). Часть содержания строки элемента языка должна быть выражена как строка или длинная строка.

Пример -

A.4.1.3.6. Путь CIP (EPATH)

Данные типа CIP EPATH, используемые, в частности, при определении строк пути CIP, должны быть кодированы в файлах EDS с использованием базового формата, определенного в ИСО 15745-3 для EDS_Char_Array. Кроме того, содержание строки для пути CIP или других данных EPATH должно состоять из групп двух прилегающих шестнадцатеричных символов, разделенных пробелами. Могут использоваться знаки как верхнего, так и нижнего регистра.

Пример 1 - "20 04 24 01".

Пример 2 - "20 05 24 02 30 04".

A.4.1.3.7. ASCII: соглашение относительно целых чисел без знака - (USINT, UINT, UDINT, ULINT)

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

Использовать нули в начале десятичной нотации нельзя, но они могут быть использованы в шестнадцатеричной нотации. В шестнадцатеричной нотации можно использовать как верхний, так и нижний регистр знаков, и полное число знаков должно быть ограничено 10 знаками (от 0x до 8) или 18 знаками (от 0x до 16) для типа ULINT.

Пример - Десятичная величина UINT 254 может быть представлена как 254 (десятичный код), или как 0xFE (шестнадцатеричный код), или как 0x000000FE (шестнадцатеричный код), но 0254 (десятичный код) и 0x0000000FE (шестнадцатеричный код) - неправильное представление.

A.4.1.3.8. ASCII: соглашение относительно целых чисел со знаком (SINT, INT, DINT, LINT)

Данные типа SINT, INT, DINT и LINT представляют данные значений целых чисел со знаком. Целые числа со знаком должны вводиться либо в десятичной, либо в шестнадцатеричной нотации, без пробелов или запятых между символами. Если для представления целых чисел со знаком используется шестнадцатеричная нотация, перед целым числом должна стоять последовательность из двух знаков 0x без пробела.

Начинать запись десятичной нотации с нулей нельзя, но они могут быть использованы в шестнадцатеричной нотации. Кроме того, в шестнадцатеричной нотации можно использовать как верхний, так и нижний регистр знаков, но полное число знаков должно быть ограничено 10 знаками (от 0x до 8) или 18 знаками (от 0x до 16) для типа LINT.

Пример - Десятичная величина INT 254 может быть представлена как 254 (десятичный код), или как 0xFE (шестнадцатеричный код), или как 0x000000FE (шестнадцатеричный код), но 0254 (десятичный код) и 0x0000000FE (шестнадцатеричный код) - неправильное представление.

A.4.1.3.9. Зарезервированные слова в кодировке ASCII (BYTE, WORD, DWORD, LWORD)

Типы данных BYTE, WORD, DWORD и LWORD представляют величины с побитовой адресацией. Эти величины считаются величинами с дискретной позицией двоичного разряда и не предназначены для представления имеющих или не имеющих знаки целых чисел. Однако эти величины вводятся для удобства в десятичную, шестнадцатеричную или двоичную нотацию без пробелов или запятых между символами. Если шестнадцатеричная (соответственно двоичная) нотация используется для представления знаков величин, последовательность двух знаков 0x (соответственно 0b) должна стоять без пробелов перед символами величины.

В десятичной нотации нули в начале не используются, но они могут быть использованы в начале шестнадцатеричной и двоичной нотаций. В шестнадцатеричной нотации можно использовать как верхний, так и нижний регистры знаков, но полное число знаков должно быть ограничено 10 знаками (от 0x до 8) или 18 знаками (от 0x до 16) для типа LWORD.

Пример - Десятичная величина INT 254 может быть представлена как 254 (десятичный код), или как 0xFE (шестнадцатеричный код), или как 0x000000FE (шестнадцатеричный код), но 0254 (десятичный код) и 0x0000000FE (шестнадцатеричный код) - неправильное представление.

A.4.1.3.10. ASCII: соглашение относительно плавающей запятой (REAL, LREAL)

Типы данных REAL и LREAL представляют двоичные значения с плавающей запятой. Внутреннее представление этих форматов данных описано в стандарте IEEE 754. Этот стандарт содержит описание как числовых величин, так и битовых последовательностей, которые интерпретируются как "нечисловые" (NaN) символьные величины, а также положительная и отрицательная бесконечности. Величины с плавающей запятой могут быть введены как целые значения или как значения, основанные на десятичном представлении с плавающей запятой, или как величины, вводимые в научной нотации, использующей базовое значение и сдвиг в экспоненциальной форме. Целые величины те же, что были указаны для типов INT, DINT или LINT. Эти величины не могут быть использованы для представления дробных значений. Десятичные величины с плавающей запятой - это величины, которые могут иметь как целую, так и дробную компоненту. Целая величина и дробные компоненты разделены запятой или десятичной точкой. Экспоненциальная (научная) форма нотации величины - это представление дробной величины с добавлением экспоненциальной компоненты. Эта экспонента всегда представляет собой десять в степени целой величины со знаком и умножается на базовое значение.

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

Диапазон допустимых данных REAL (одиночный IEEE, 32-битный формат) основан на формуле:

величина = (-1)s·(2)e-127·(m)

Где:

• "s" - значение бита знака;
• "e" - 8-битная экспонента. Эта экспонента допускает диапазон от -126 до +127;
• "m" - нормализованная 24-битная мантисса (23 бита в памяти плюс один скрытый бит). Это допускает диапазон значений мантиссы от 0 до 16777215.

Комбинация "e" и "m" допускает приближенную абсолютную величину диапазона от 0 до 3,4028e38. EDS использует для данных REAL следующие нотации величин с плавающей запятой:

целая (фиксированная) нотация: -16777215 до 16777215;

десятичная (с плавающей запятой) нотация: 0.0 до \pm 9999999999999999 .

В этом случае полное число разрядов не превышает 16 в дополнение к десятичной точке и символам знаков "+" и "-". Как символ десятичной точки, так и символ знака могут быть опущены (если символ знака опущен, подразумевается знак "+").

Научная нотация: 0.0 до \pm nn.nnnnnnnnnE \pm xxxx .

Для этого случая полное число разрядов мантиссы не превышает 11 (дополнительно к символу десятичной точки и символу знака), а число разрядов экспоненты не должно превышать 4 (дополнительно к символу "E" и символу знака). Десятичная точка может быть помещена в мантиссе где угодно. Как символ десятичной точки, так и символ знака могут быть опущены в мантиссе (знак "+" подразумевается, если символ знака опущен).

Диапазон допустимых данных LREAL (двойной IEEE, 64-битный формат) основан на формуле:

величина = (-1)s·(2)e-1023·(m)

Где:

• "s" - значение бита знака;
• "e" - 8-битная экспонента. Эта экспонента допускает диапазон от -1022 до +1023;
• "m" - нормализованная 53-битная мантисса (52 внутренних в памяти плюс один скрытый бит). Это допускает диапазон значений мантиссы от 0 до 9007199254740991.

Комбинация "e" и "m" допускает приближенную абсолютную величину диапазона от 0 до 1,7976e308.

EDS использует для данных LREAL следующие нотации величин с плавающей запятой:

целая (фиксированная) нотация: от -9007199254740991 до 9007199254740991;

десятичная (с плавающей запятой) нотация: от 0.0 до \pm 9999999999999999 .

Для этого случая полное число разрядов не превышает 16 в дополнение к десятичной точке и символам знака. Как символ десятичной точки, так и символ знака могут быть опущены (знак "+" подразумевается, если символ знака опущен).

Научная нотация: от 0.0 до \pm nnnn.nnnnnnnnnnnnE \pm xxxx .

Для этого случая полное число разрядов мантиссы не превышает 16 (дополнительно к символу десятичной точки и символу знака), а число разрядов экспоненты не должно превышать 4 (дополнительно к символу "E" и символу знака). Десятичная точка может быть помещена в мантиссе, где угодно. Как символ десятичной точки, так и символ знака могут быть опущены в мантиссе (знак "+" подразумевается, если символ знака опущен).

Дополнительно к указанным выше величинам ввода представление с плавающей запятой допускает два вида нечислового (NaN) символического ввода и две формы бесконечности. Существует два типа NaN: Signaling NaN и Quiet NaN. Формат также допускает представление величин положительной и отрицательной бесконечностей. Для этих случаев зарезервированы специальные указанные ниже слова, которые должны использоваться для представления ввода соответствующих символов с плавающей запятой:

• Quiet NaN - QUIET-NAN;
• Signaling NaN - SIGNAL-NAN;
• положительная бесконечность - INFINITY (или +INFINITY);
• отрицательная бесконечность - -INFINITY.

A.4.1.3.11. EDS_Date

Тип данных EDS_Date должен иметь формат mm-dd-yyyy, где mm - месяц, dd - день месяца и yyyy - год. Правильные значения частей "месяц", "день" и "год" в mm-dd-yyyy должны быть следующими:

• mm от 01 до 12;
• dd от 01 до 31 (в зависимости от месяца и года);
• yyyy от 1996 до 9999.

Может быть использовано двузначное представление года. В этом случае тип данных EDS_Date должен иметь формат mm-dd-yy, где mm - месяц, dd - день и yy - год. В этом случае две цифры года подразумевают впереди 19 (или 20), так что yy = 96 будет соответствовать 1996 г., а 11 - 2011 г. Правильные значения месяца, дня и года в mm-dd-yy должны быть следующими:

• mm от 01 до 12;
• dd от 01 до 31 (в зависимости от месяца и года);
• yy от 96 до 99 (подразумевается 19 или 20 впереди).

Примечание - Использование двузначного представления года не рекомендуется.

A.4.1.3.12. EDS_Time_Of_Day

Тип данных EDS_Time_Of_Day должен иметь формат hh:mm:ss, где hh - часы, mm - минуты и ss - секунды. Правильные значения часов, минут и секунд должны быть следующими:

• hh от 00 до 23;
• mm от 00 до 59;
• ss от 00 до 59.

A.4.1.3.13. EDS_Revision

Тип данных EDS_Revision должен иметь формат Major_Revision.Minor_Revision со следующими правильными значениями:

• Major_Revision - от 0 до 9;
• Minor_Revision - от 0 до 9.

EDS_Revision со значением 0.0 неправильна.

Пример - EDS_Revision со значением 1.4 соответствует Major_Revision со значением 1 и Minor_Revision со значением 4.

A.4.1.3.14. EDS_URL (унифицированный указатель информационного ресурса)

Все ссылки на EDS_URL в рамках требований EDS предназначены для получения формализованной информации, необходимой для поиска и получения ресурсов путем использования Интернета. EDS_URL должен быть закодирован в файлах EDS с использованием базового формата, определенного в ИСО 15745-3 для EDS_Char_Array. Кроме того, содержание строки для EDS_URL должно быть в формате, определенном Рабочей группой по Интернету RFC 1738 "Унифицированный указатель информационного ресурса (URL)". В спецификациях внутри файла EDS EDS_URL должно быть ограничено одной из следующих форм:

• http;
• ftp;
• file.

A.4.1.4. Основные требования к файлу EDS

A.4.1.4.1. Обзор

В данном подразделе описаны основные секции EDS, которые являются общими для ряда основанных на CIP сетей, и установлены соответствующие требования при использовании. В таблице A.7 приведено расположение подразделов, содержащих определения этих секций.

Таблица A.7

Определение основных секций

A.4.1.4.2. Секция File Description

Секция File Description должна содержать административную информацию о файле EDS. Инструмент конфигурации должен считывать эту информацию, форматировать ее и показывать пользователю. Пользователь может также получить доступ в эту секцию для просмотра текста файла и отображения неформатированной информации. Данная секция не требует выполнения модификации, если только пользователь не выполняет модификацию файла вручную. Секция File Description должна содержать входы, показанные в таблице A.8.

Таблица A.8

Формат File Description

Входы в секции File Description должны предоставлять информацию, указанную в таблице A.9.

Таблица A.9

Входы File Description

На рисунке A.2 приведен пример, показывающий типичную секцию [File].

Рисунок A.2 - Пример секции [File] (информативный)

A.4.1.4.3. Секция Device Description

Секция Device Description должна содержать информацию изготовителя, включающую некоторые из таких величин, как Identity Object. Данная секция должна включать входы, указанные в таблице A.10.

Таблица A.10

Формат Device Description

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

Средство для конфигурации должно использовать требуемые входы в секцию Device Description для согласования EDS с конфигурируемым устройством. Входы секции должны предоставлять информацию, показанную в таблице A.11.

Таблица A.11

Входы Device Description

На рисунке A.3 приведен пример типичной секции Device Description.

Рисунок A.3 - Пример секции [Device] (информативный)

A.4.1.4.4. Секция Device Classification

Секция Device Classification должна классифицировать устройства, описанные в EDS, по одной или нескольким категориям. Ключевое слово всех классов должно состоять из набора символов "Class", скомбинированных с десятичным числом. Числа должны начинаться с единицы для первого класса и увеличиваться для каждого последующего класса.

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

• ControlNet;
• DeviceNet;
• EtherNetIP;
• ключевое слово поля поставщика.

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

A.4.1.4.5. Секция Parameter Class

Секция Parameter Class должна определить общие атрибуты параметров конфигурации, описанных в EDS, соответствующие подмножеству атрибутов класса Parameter Object, согласно описанию в CIP Object Library (библиотеке объектов CIP).

Секция Parameter Class должна содержать входы, указанные в таблице A.12.

Таблица A.12

Формат Parameter Class

Входы секции Parameter Class должны предоставлять информацию, указанную в таблице A.13.

Таблица A.13

Входы Parameter Class

Вход Parameter Class Descriptor должен содержать биты, предназначенные для описания характеристик параметров, согласно определению в таблице A.14. Биты, не определенные в таблице A.14, не должны использоваться и должны быть установлены на ноль (0).

Таблица A.14

Значения битов дескриптора Parameter Class

На рисунке A.4 приведен пример типичной секции Parameter Class.

Рисунок A.4 - Пример секции Parameter Class

A.4.1.4.6. Секция Parameter

Секция Parameter должна определять конфигурацию параметров в устройстве. Ключевое слово входа должно быть одним из следующих наборов символов "Param", "ProxyParam", "ProxiedParam", скомбинированных с номером экземпляра параметра (десятичным) для устройства, например "Param1". Фактический экземпляр объекта параметра может (но не обязательно должен) применяться в устройстве. Не требуется, чтобы все экземпляры объекта параметра имели соответствующий вход "ParamN" в EDS. Однако когда экземпляр объекта параметра существует внутри узла, а данный параметр описан в EDS, то значение "N" в "ParamN" должно быть равно экземпляру объекта параметра.

Каждый вход должен содержать форматированные поля, представленные в таблице A.15. Ключевые слова "ProxyParam" и "ProxiedParam" определяются далее в A.4.1.5.3.1 в качестве части требований модульного EDS.

Таблица A.15

Формат parameters

Входы в секции Parameters должны предоставлять информацию, указанную в таблицах A.16 и A.20.

Поля параметров, перечисленные в таблице A.16, являются общими для всех параметров.

Таблица A.16

Общие поля parameters

Биты поля Descriptor должны соответствовать определениям в таблице A.17.

Таблица A.17

Определения битов полей descriptors

Старые версии файлов EDS могут использовать идентификаторы типа данных, указанные в таблице A.18.

Таблица A.18

Идентификаторы типов данных (устаревшие)

В таблице A.19 представлены смысловые и специальные требования для входов с минимальными и максимальными значениями на основании типов данных параметров.

Таблица A.19

Семантика входов с минимальным и максимальным значением

Поля параметра, перечисленные в таблице A.20, являются дополнительными и имеющими значение только в том случае, когда они используются со следующими типами данных: SINT, INT, DINT, LINT, USINT, UINT, UDINT, ULINT, REAL и LREAL. Спецификация этих полей с любым другим типом данных запрещена.

Таблица A.20

Поля параметров, зарезервированные для типов числовых данных

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

EngValue = \frac{(ActualValue + Offset)*Mult*Base}{Div*10^{DecimalPrecision}}

Примечание - Если расширенное масштабирование не поддерживается, эта формула должна применяться при Decimal Precision.

Рисунок A.5 - Формула масштабирования параметра

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

Пример на рисунке A.6 показывает типичную секцию Parameter.

Рисунок A.6 - Пример секции Parameter

A.4.1.4.7. Секция Parameter Groups

Секция Parameter Groups должна определять все группы параметров в устройстве. Каждая группа параметров должна содержать их список. Ключевое слово входа каждой группы должно состоять из комбинации набора символов "Group" и номера группы параметров (десятичного), например "Group1". Десятичные номера должны начинаться с 1 и увеличиваться на 1.

Фактический экземпляр объекта Parameter Group может, но не обязательно, применяться в устройстве. Не требуется, чтобы все экземпляры объекта Parameter Group имели соответствующий вход "GroupN" в EDS. Однако если экземпляр объекта Parameter Group существует в узле и если эта группа параметров описана также в EDS, то значение "N" в "GroupN" должно быть равно экземпляру объекта Parameter Group.

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

Таблица A.21

Формат группы параметров

На рисунке A.7 приведен пример типичной секции Parameter Group.

Рисунок A.7 - Пример секции Parameter Group

A.4.1.4.8. Секция Assembly

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

Ключевое слово входа "Revision" должно иметь одно 16-битное целочисленное поле, которое должно соответствовать проверке (атрибут 1 класса) объекта Assembly внутри устройства. Если этот опциональный вход пропущен, значение проверки объекта Assembly должно быть равно 2.

Ключевое слово для всех сборок должно состоять из одного из следующих наборов символов: "Assem", "ProxyAssem", "ProxiedAssem", скомбинированных с номером экземпляра объекта Assembly (десятичным) для данного устройства, например "Assem1". Если конкретный экземпляр объекта Assembly адресуем из связи, то должна соблюдаться парность один к одному между номером Assem в файле EDS и номером экземпляра Assembly в устройстве. Ключевые слова "ProxyAssem" и "ProxiedAssem" определяются далее в A.4.1.5.3.2 как часть требований модульного EDS.

Каждый вход должен содержать форматированные поля, представленные в таблице A.22.

Таблица A.22

Формат ключевого слова AssemN