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

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

Группа Т58

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

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

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

Часть 3

Эталонное описание систем управления на основе стандарта МЭК 61158

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

ОКС 25.040.40

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

Предисловие

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

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

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. N 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, PROFIBUS, WorldFIP, ControlNet и INTERBUS). Эти технологии используют профили, установленные в МЭК 61158, которые описаны в МЭК 61784-1. Профили для систем управления, представленных в ИСО/МЭК 8802-3, не входят в область применения данного стандарта и установлены в ИСО 15745-4.

_______________

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

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

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

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

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

В частности, настоящий стандарт описывает специфические технологические шаблоны профилей для профилей устройств или экземпляров профилей коммуникационной сети, являются частью профиля ресурсов, определенного в ИСО 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) (IEC 61804-2 Function blocks (FB) for process control - Part 2: Specification of FB concept and electronic device description language (EDDL))

_______________

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

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-xm1-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, Приложение А.

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

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

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

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

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

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

СIР - общий промышленный протокол;

_______________

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

СР - профиль коммуникации;

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

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

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

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

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

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

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

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

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

HMI - интерфейс "человек - машина";

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

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

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

kbit/s - 1024 бит/с;

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

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

Mbit/s - 1024x1024 бит/с;

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, Приложение В.

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. В связи с этим для достижения обратной совместимости определения шаблонов в любых технологиях (приложения А-Е) включают все или необходимые подмножества:

- шаблонов профилей коммуникационных сетей и устройств, согласно определениям в ИСО 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).

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

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

6.1 ControlNet

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

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

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

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

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

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

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

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

6.1.1.2 Device identity

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

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

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

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

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

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

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 описаны в А.3.

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

XML-схема, представляющая инкапсуляцию ранее принятого ControlNet EDS в шаблон профиля коммуникационной сети, описанного в ИСО 15745, определяется в А.3.2.2. Имя файла данной схемы должно быть "EDS_CommNet_Profile_wrapper.xsd". Ранее принятый синтаксис ASCII EDS описывается в А.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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.2.2.2 Application layers

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

6.2.2.3 Transport layers

Класс TransportLayers коммуникационной сети PROFIBUS представляет комбинированные профили для четырех низших уровней OSI - модели интеграции коммуникационной сети PROFIBUS (см. МЭК 61784-1:2003 СР3/1 и СР3/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 и Deviceldentity. Данные характеристики могут быть отображены в объектах ApplicationProcess и доступны в сети с помощью Application Protocol Data Unit (APDU), установленного в классе P-NET ApplicationLayers (см. 6.3.2.2).

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

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

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

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

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

XML-схема, представляющая профиль коммуникационной сети P-Net, определяется в С.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, 19200 и 38400 бит/с. Для RS485 правильное значение скорости двоичной передачи в бодах только 76800 бит/с.

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

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

Рисунок 10 - Диаграмма класса Deviceldentity

Таблица 2 - Декомпозиция класса Deviceldentity

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 описан в Е.1. XML-схема, представляющая шаблон профиля устройства INTERBUS, определена в Е.1.6.1. Имя файла данной схемы должно быть "FDCML.XSD".

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

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

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

6.5.1.2 Device identity

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

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

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

Таблица 3 - Декомпозиция класса Deviceldentity

6.5.1.3 Device manager

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

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

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

6.5.1.3.2 LocalDataDescriptionltemList, localDataltemlocalDataDescription

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

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 AdditionalltemList, additionalltem

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

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

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

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 описывает конечную точку соединения (возможные атрибуты см. в Е.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 CfgltemList

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

6.5.1.3.4.14 DedicatedCfgltem

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

6.5.1.3.4.15 UncommittedCfgltem

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

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

Пример - Описание 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ИCO15745DeviceFunction.XSD". XML-схема DeviceFunction определена в Е.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, определена в Е.2. Имя файла данной схемы должно быть "INTERBUSCommNetworkProfile.XSD".

6.5.2.2 Transport layers

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

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

6.5.2.2.2 PhysicalLayerlnterface

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

6.5.2.2.3 DataLinkLayerlnterface

6.5.2.2.3.1 ProcessDataChannel

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

6.5.2.2.3.2 Parameter Channel

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

6.5.2.3 Application layers

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

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

- applicationProcess;

- applicationRelationship;

- objectManagement;

- functionlnvocation;

- другие.

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

6.5.2.4 Network management

6.5.2.4.1 NetworkAccessType, AssignedlDCode

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

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

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

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

6.5.2.4.2 CommunicationProfile

Объект communicationProffle должен установить идентификаторы готовых к использованию коммуникационных профилей (см. 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.

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

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

А.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-файлов профилей устройств и коммуникационной сети, используя соответствующие таблицы стилей.

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

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

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

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

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

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

A.2.1.2.1 ProfileBody

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

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

А.2.1.2.2 Deviceldentity

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

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

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

А.2.1.2.3 DeviceManager

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

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

А.2.1.2.4 DeviceFunction

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

А.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 определена в А.4.1.4.8 и А.4.1.5.3.2.

А.2.1.2.5.2 Parameter

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

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

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

А.2.1.2.5.3 ParameterGroup

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

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

А.2.1.3 XML-схемы

А.2.1.3.1 MasterTemplateTypes.xsd

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

A.2.1.3.2 CIPDataTypes.xsd

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

A.2.1.3.3 CIP_Device_Profile.xsd

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

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

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

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

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

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

Таблица А.2 - Элементы ExternalProfileHandle

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

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

А.2.2.2 XML-схема: EDS_Device_Profile_wrapper.xsd

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

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

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

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

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

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

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

А.3.1.2.1 ProfileBody

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

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

А.3.1.2.2 Application layers

А.3.1.2.2.1 ConnectionManager

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

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

А.3.1.2.2.2 MessageRouter

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

А.3.1.2.3 TransportLayers

А.3.1.2.3.1 CNPhysicalLayer

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

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

Таблица А.3 - Элементы CNPhysicalLayer

А.3.1.2.3.2 CNLinkLayer

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

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

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

А.3.1.2.3.3 ControlNetObject

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

А.3.1.2.3.4 Ports

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

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

А.3.1.2.4 NetworkManagement

А.3.1.2.4.1 NM-ControlNetObject

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

А.3.1.2.4.2 NM-ConnectionManager

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

А.3.1.2.4.3 NM-MessageRouter

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

А.3.1.2.4.4 Keeper

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

А.3.1.2.4.5 ControlNetScheduling

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица А.5 - Структура файлов CIP EDS

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

- все файлы EDS должны включать раздел File Description, являющийся первой секцией файла EDS и использующий установленный ограничитель [File];

- все файлы EDS должны включать раздел Device Description, располагающийся сразу после раздела File Description и использующий установленный ограничитель [Device];

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

- относящиеся к поставщику опциональные разделы должны использовать установленные ограничители [VendorlD_vendorspecifickeyword], согласно А.4.1.2.2.11, и размещаться после всех разделов, определенных в настоящей спецификации.

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

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

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

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

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

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

- символ пробела;

- новая строка;

- возврат каретки;

- переход на одну строку;

- символы табуляции вертикальные и горизонтальные;

- переход на новую страницу;

- разметка окончания файла;

- комментарии.

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

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

- буквы верхнего регистра от А до Z;

- буквы нижнего регистра от а до z;

- цифры от 0 до 9;

- специальный символ нижнего тире "_";

- символ пробела.

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

А.4.1.2.2.4 Разделы

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

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

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

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

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

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

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

А.4.1.2.2.8 Вход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример - Если в параметрах обозначена максимальная длина строки - 8 знаков, а полученная строка, например, "I23ABCDEFG", она обрезается и интерпретируется как "I23ABCDE".

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

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

Пример 1 -

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

Пример 2 -

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

Пример 3 - L "ABC" "123" "XYZ" - то же самое, что L "ABC123XYZ".

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

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

Таблица А.6 - Последовательности переключения кода строки

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

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

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

А.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 или других данных ЕРАТН должно состоять из групп двух прилегающих шестнадцатиричных символов, разделенных пробелами. Могут использоваться знаки как верхнего, так и нижнего регистра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где:

- "s" - значение бита знака;

- "е" - 8-битная экспонента. Эта экспонента допускает диапазон от -126 до +127;

- "m" - нормализованная 24-битная мантисса (23 бита в памяти плюс один скрытый бит). Это допускает диапазон значений мантиссы от 0 до 16777215.

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

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

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

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

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

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

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

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

Где:

- "s" - значение бита знака;

- "е" - 8-битная экспонента. Эта экспонента допускает диапазон от -1022 до +1023;

- "m" - нормализованная 53-битная мантисса (52 внутренних в памяти плюс один скрытый бит). Это допускает диапазон значений мантиссы от 0 до 9007199254740991.

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

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

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

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

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

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

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

Дополнительно к указанным выше величинам ввода представление с плавающей запятой допускает два вида нечислового (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 - день месяца и уууу - год. Правильные значения частей "месяц", "день" и "год" в mm-dd-yyyy должны быть следующими:

- mm от 01 до 12;

- dd от 01 до 31 (в зависимости от месяца и года);

- уууу от 1996 до 9999.

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

- mm от 01 до 12;

- dd от 01 до 31 (в зависимости от месяца и года);

- уу от 96 до 99 (подразумевается 19 или 20 впереди).

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

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

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

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

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

А.4.1.4.1 Обзор

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

Таблица А.7 - Определение основных секций

A.4.1.4.2 Секция File Description

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

Таблица А.8 - Формат File Description

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

Таблица А.9 - Входы File Description

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

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

А.4.1.4.3 Секция Device Description

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

Таблица А.10 - Формат Device Description

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

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

Таблица А.11 - Входы Device Description

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

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

А.4.1.4.4 Секция Device Classification

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

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

- ControlNet;

- DeviceNet;

- EtherNetIP;

- ключевое слово поля поставщика.

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

А.4.1.4.5 Секция Parameter Class

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

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

Таблица А.12 - Формат Parameter Class

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

Таблица А.13 - Входы Parameter Class

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

Таблица А.14 - Значения битов дескриптора Parameter Class

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

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

А.4.1.4.6 Секция Parameter

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

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

Таблица А.15 - Формат parameters

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

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

Таблица А.16 - Общие поля parameters

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

Таблица А.17 - Определения битов полей descriptors

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

Таблица А.18 - Идентификаторы типов данных (устаревшие)

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

Таблица А.19 - Семантика входов с минимальным и максимальным значением

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

Таблица А.20 - Поля параметров, зарезервированные для типов числовых данных

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

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

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

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

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

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

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

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

Таблица А.21 - Формат группы параметров

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

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

А.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" определяются далее в А.4.1.5.3.2 как часть требований модульного EDS.

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

Таблица А.22 - Формат ключевого слова AssemN

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

Второе поле Path должно быть строкой, определяющей логический путь. Этот путь должен указывать адрес блока данных в устройстве. Если блок, описанный этим входом AssemN, не адресуем прямо из связи, это поле должно быть пустым. Если это поле - нулевая строка (""), блок данных должен быть адресуем как атрибут данных (атрибут экземпляра 3) N-го экземпляра объекта Assembly.

Третье поле Size представляет собой размер блока данных в байтах. Если ни это поле, ни поля Member Size и Member Reference не присутствуют, размер блока данных должен быть равен нулю. Оба эти поля могут присутствовать; однако поскольку они устанавливают размер блока, данные размеры должны быть согласованы.

Четвертое поле Descriptor - это битовое поле, которое описывает некоторые характеристики объекта Assembly. Биты этого поля следует интерпретировать согласно таблице А.23.

Таблица А.23 - Определение бита поля дескриптора Assembly

Поля 5 и 6 должны быть зарезервированы.

Остальные поля должны быть парными, например поле Member Size составляет пару с полем Member Reference, что требует четное полное число полей. Число пар полей на каждом входе должно быть переменным. Эти пары должны соответствовать списку членов объекта Assembly.

Допустимое значение поля Member Reference должно быть следующим:

- ссылка ParamN или ProxyParamN из секции [Params];

- ссылка AssemN или ProxyAssemN из секции [Assembly];

- строка, представляющая путь (ЕРАТН);

- константа UDINT;

- пустое поле;

- дополнительные значения согласно определению для модульного EDS в А.4.1.5.3.2.

Если поле Member Reference пустое, число битов, установленное в поле Member Size, должно быть использовано в качестве заполнителя незначащей информацией в объекте Assembly. Поле Member Reference, содержащее нулевую строку, должно рассматриваться как пустое поле. Поле Member Reference и соответствующее ему поле Member Size не должны быть пустыми. Если поле Member Reference указывает ЕРАТН, этот путь должен состоять либо из Logical Segments (путь к объекту внутри устройства), либо из Data Segments.

Поле Member Size должно иметь размер в битах. Если поле Member Size пустое, следует использовать заданный размер, соответствующий полю Member Reference. Заданный размер входа Param должен быть приведен в 6-м поле. Заданный размер входа Assem должен быть приведен в 3-м поле.

Элементы должны быть помещены в блок данных начиная со значащего бита, как это делается в объекте Assembly. Если поле Member Size меньше, чем заданный размер соответствующего поля Member Reference, должны быть использованы младшие биты соответствующего поля Member Reference. Если поле Member Size больше, чем заданный размер соответствующего поля Member Reference, за полным элементом должны следовать нули до расширения элемента до всего Member Size. Представленный блок данных должен быть целым числом байтов. Сумма размеров всех элементов должна быть равна полю AssemN Size (при выражении в битах).

На рисунке А.8 приведен пример, показывающий типичную секцию Assembly. В этом примере Assem5 имеет длину 1 байт и имеет значение по умолчанию 021.

Рисунок А.8 - Пример секции [Assembly]

Примечание - Ключевое слово "Variant", скомбинированное с десятичным числом (например, "Variant1"), зарезервировано для будущего определения новых типов входов в секции Assembly.

А.4.1.4.9 Раздел Connection Manager

А.4.1.4.9.1 Содержание

Раздел Connection Manager должен содержать информацию, касающуюся числа типов соединений приложений, которые поддерживает устройство. Этот раздел моделируется как Connection Manager Object. Многие использованные здесь термины описаны в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2). Ключевое слово каждого входа должно быть одним из следующего набора символов: "Connection", "ProxyConnect", "ProxiedConnect", объединенных с десятичным числом, например "Connection1", "ProxyConnect1" или "ProxiedConnect1". Десятичные числа должны начинаться с единицы и увеличиваться для каждого дополнительного входа "Connection". Для каждого дополнительного входа "ProxyConnect" или "ProxiedConnect" десятичное число не обязательно должно начинаться с единицы или повышаться. Ключевые слова "ProxyConnect" и "ProxiedConnect" определены далее в разделе А.4.1.5.3.3 в качестве части требований к модульному EDS.

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

Таблица А.24 - Формат Connection Manager

А.4.1.4.9.2 Trigger and transport mask

Присвоение битов в trigger and transport mask должно соответствовать представленному в таблице 25. Бит должен быть установлен на 1 (включено) для каждого режима переключения, который поддерживает соединение. Все другие биты должны быть установлены на 0 (выключено). Для бита клиент/сервер: 0 = клиент, 1 = сервер. Только один из типов протокола передачи данных должен быть установлен на 1 (включено).

Таблица А.25 - Присвоение битов в trigger and transport mask

А.4.1.4.9.3 Connection parameters

Присвоение битов для типа соединения и маски приоритетов должно соответствовать данным в таблице А.26. Бит должен быть установлен на 1 (включено) для каждого типа соединения и приоритета, поддерживаемых соединением. Все другие биты должны быть установлены на 0 (выключено).

Таблица А.26 - Присвоение битов connection parameters

A.4.1.4.9.4 O=>T RPI

O=>T RPI должно быть числом микросекунд интервала запрашиваемого пакета. O=>Т RPI должно быть UDINT, Param или ProxyParam - входом из секции [Params], который определяется в UDINT. Если это поле пустое, никакие ограничения не налагаются на O=>Т RPI.

А.4.1.4.9.5 O=>Т размер

O=>Т размер должен быть числом байтов, предоставляемых для целевого протокола передачи данных. Он не должен включать счет последовательности из протокола передачи данных. O=>Т размер должен быть UINT, Param или ProxyParam - входом из секции [Params], который определяется в UINT. Если это поле пустое, заданный размер формата O=>Т должен использоваться после добавления размера заголовка холостого хода.

А.4.1.4.9.6 O=>Т формат

Формат входа O=>Т должен определять структуру буфера потребителя для этого соединения. Правильные дескрипторы формата должны быть идентификаторами в файле EDS, включая следующее:

- Param или ProxyParam - вход из секции [Params];

- Assem или ProxyAssem - вход из секции [Assembly].

Это поле может быть пустым, то есть формат потребителя не установлен. Это поле не должно быть пустым, если поле O=>Т размер пустое. Формат O=>Т не должен включать 32-битный прогон/заголовок холостого хода, если он присутствует.

A.4.1.4.9.7 T=>O RPI

Т=>O RPI должно быть числом микросекунд интервала запрашиваемого пакета. Т=>O RPI должно быть UDINT, Param или ProxyParam - выходом из секции [Params], который определяется в UDINT. Если это поле пустое, никакие ограничения не налагаются на Т=>O RPI.

A.4.1.4.9.8 T=>O size

Т=>O size должен быть числом байтов, предоставляемых для целевого протокола передачи данных. Он не должен включать счет последовательности протокола передачи данных. Т=>O size должен быть UINT, Param или ProxyParam - выходом из секции [Params], который определяется в UINT. Если это поле пустое, заданный размер формата Т=>O должен использоваться после добавления размера заголовка холостого хода.

А.4.1.4.9.9 Т=>O format

Т=>O format должен определять структуру буфера потребителя для этого соединения. Правильные дескрипторы формата должны быть идентификаторами в файле EDS, включая следующее:

- Param или ProxyParam - вход из секции [Params];

- Assem или ProxyAssem - вход из секции [Assembly].

Это поле может быть пустым, то есть создаваемый формат не установлен. Это поле не должно быть пустым, если поле Т=>O size пустое. Формат должен включать заголовок статуса, если он присутствует.

А.4.1.4.9.10 Configuration

Config #1 size и config #2 size должны устанавливать размер сегмента опциональных данных, которые присоединяются к пути в Forward_Open. Сегмент данных должен быть конкатенацией двух буферов, описанных в config #1 format и config #2 format. Размеры должны быть числом байтов и должны быть UINT, Param или ProxyParam - входом из секции [Params], которые определяются в UINT. Если одно из полей пустое, должен быть использован естественный размер соответствующего поля формата config.

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

- Param или ProxyParam - вход из секции [Params];

- Assem или ProxyAssem - вход из секции [Assembly].

Эти поля формата config могут быть пустыми, то есть формат config не установлен. Если поля размера config и формата config пустые, никакие сегменты данных не добавляются к пути Forward_Open.

А.4.1.4.9.11 Connection name string

Экранный инструмент может показывать connection name string (набор символов). Connection name string должен быть уникальным среди всех входов Connection в рамках EDS.

А.4.1.4.9.12 Help string

Экранный инструмент может представлять help string (текстовый вспомогательный набор символов). Если help string не должен быть отображен, используется "нулевая" строка, которая определена в виде пар двойных кавычек ("") при отсутствии символов между ними.

A.4.1.4.9.13 Path

Path содержит ссылку на целевой объект. Он должен вводиться как CIP Path (EPATH) с использованием заполняющей нотации, описанной в МЭК 61158-6:2003 (тип 2), и в формате, установленном в А.4.1.3.6. Дополнительно к формату, установленному в А.4.1.3.6, поле path может также содержать приведенные ниже ссылки:

- Param или ProxyParam - входы из секции [Params];

- ключевое слово SLOT;

- ключевое слово SYMBOL_ANSI;

- ключевое слово SLOT_MINUS_ONE.

Входы Param/ProxyParam должны обозначаться согласно USINT, UINT или UDINT. Значение Param/ProxyParam должно использоваться с обратным порядком байтов для вставки в path. Ссылки Param/ProxyParam в path могут быть заключены в скобки, как показано на рисунке А.9. Если значение Param/ProxyParam заключено в скобки, оно используется локально для path - тот же самый вход Param/ProxyParam может иметь другое значение где-либо в EDS. Если Param/ProxyParam не заключено в скобки, значение должно быть одинаковым везде в EDS.

Ключевое слово SLOT должно всегда определяться в USINT. Значения, подставляемые в ключевое слово SLOT, должны соответствовать позиции модуля в панели.

Ключевое слово SLOT_MINUS_ONE должно всегда определяться в USINT. Значения, подставляемые в ключевое слово SLOT_MINUS_ONE, должны соответствовать позиции модуля в панели минус 1.

Ключевое слово SYMBOL_ANSI должно определяться согласно расширенному символьному сегменту (смотрите МЭК 61158-6:2003 (тип 2)), введенному через интерфейс пользователя. Расширенный символьный сегмент должен быть расширенным символом ANSI (тип CIP path =091). Например, строка "CAB" должна определяться следующим расширенным символьным сегментом (заполненным): 091 003 043 041 042 000.

А.4.1.4.9.14 Пример секции Connection Manager (информативный)

На рисунке А.9 приведен пример, показывающий типичную секцию Connection Manager.

Рисунок А.9 - Пример секции [Connection Manager]

А.4.1.4.10 Секция Port

Секция Port должна описывать имеющие маршруты CIP port, доступные внутри устройства. Каждый маршрутизируемый CIP port должен иметь соответствующий вход в этой секции. Ключевое слово входа для всех port должно состоять из набора символов "Port", скомбинированного с десятичным числом, соответствующим экземпляру объекта "port". Например, Port1 является экземпляром 1 Port Object.

Примечание - Маршрутизируемый согласно CIP port - это порт, способный обмениваться СIР-сообщениями с другим CIP port, соединенным СIР-связью.

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

Таблица А.27 - Формат входа в port

Первое поле, называемое "Port Type Name", должно быть заполнено одним из следующих ключевых слов:

- ControlNet;

- ControlNet_Redundant;

- TCP (для указания имеющего возможности EtherNet/IP TCP port);

- DeviceNet;

- зависящее от поставщика ключевое слово поля, начинающееся с идентификатора поставщика (Vendor ID) устройства и символа нижнего тире ("65535_").

Опциональное поле "Port Name" должно быть строкой, содержащей имя "port", и может быть использовано в интерфейсе пользователя. Поле "Port Object" должно быть путем (ЕРАТН), который указывает определенный объект связи сети, ассоциированный с портом.

Port номер 1 должен соответствовать "port" системной платы. Устройства с системной панелью, которые не могут определять маршрут сообщений CIP, не должны иметь port номер 1.

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

Рисунок А.10 - Пример секции [Port]

А.4.1.5 Требования к файлу модульного EDS

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

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

А.4.1.5.2 Секция modular

А.4.1.5.2.1 Содержание

Секция [Modular] должна описывать систему на основе блоков. Должны существовать два типа модульных устройств:

- блок;

- модуль.

А.4.1.5.2.2 Блочное устройство

Секция [Modular], описывающая блок, должна содержать требуемое ключевое слово DefineSlotsInRack. Единственное поле этого входа должно быть 16-битным беззнаковым целым числом (UINT), указывающим число слотов в блоке. Даже если электронный ключ определен для этого блока, он не обязательно будет адресуемым из связи. Ключевое слово SLOT, использованное в определениях пути в секции [Connection Manager], должно иметь диапазон от 0 до числа слотов минус 1.

Ключевое слово SlotDisplayRule не обязательно. Единственное поле этого входа должно быть параметром из секции [Params] (только ParamN), которое определяет преобразование между внутренним и внешним номером слота.

На рисунке А.11 приведен пример, показывающий EDS для блочного устройства, включая секцию [Modular].

Рисунок А.11 - Секция [Modular], описывающая блок

А.4.1.5.2.3 Модульное устройство (основные входы)

Секция [Modular], описывающая модуль, должна содержать входы "Width" и "Rack".

Требуемый вход с ключевым словом Width должен иметь одно поле, показывающее, сколько слотов блока используется модулем. Это поле должно быть 16-битным беззнаковым целым числом (UINT).

Ключевое слово входа для всех блоков, в которые модуль может быть установлен, должно состоять из набора символов "Rack", скомбинированного с десятичным числом. Числа должны начинаться с 1 для первого блока и увеличиваться для каждого дополнительного блока. Поля для входов Rack должны быть такими, как показано в таблице А.28.

Таблица А.28 - Формат входа Rack

Поля Vendor ID, Product Type, Product Code, Major Revision and Minor Revision должны идентифицировать электронный ключ блока, в который может быть установлен модуль. Резервное поле должно быть пустым. Поля Legal Slot должны указывать слоты, в которые может быть установлен модуль. EDS для модуля должен содержать один вход "Rack" для каждого блока, в которые данный модуль может быть установлен.

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

Рисунок А.12 - Пример секции [Modular]

А.4.1.5.2.4 Модульное устройство (дополнительные входы)

Обзор

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

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

- модули, имеющие соединение по CIP-связи и соответствующий адресуемый идентичный объект, которые помещаются в слот 0 (например, коммуникационные адаптеры);

- модули, не имеющие соединения по CIP-связи или адресуемого идентичного объекта, которые не могут быть помещены в слот 0 (например, модули ввода/вывода).

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

Входы для модуля, не имеющего адресуемого идентичного объекта

Секция [Modular], описывающая модуль, не имеющий адресуемого идентичного объекта, может содержать ключевое слово ExternallD. Ключевое слово должно иметь одно поле. Это поле должно быть байтовой строкой, идентифицирующей модуль. Эта байтовая строка должна иметь кодировку с использованием формата, который установлен для ЕРАТН.

На рисунке А.13 приведен пример, показывающий типичную секцию [Modular], описывающую модуль, не имеющий адресуемого из связи ID объекта.

Рисунок А.13 - Пример секции [Modular] (модуль, не имеющий адресуемого из связи ID-объекта)

Входы для модулей, имеющих соединение связи и помещаемых в слот 0

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

Ключевое слово GenericID должно иметь одно поле. Это поле должно быть байтовой строкой, которая включается в сегмент данных для соединения модуля вместо ExternallD, когда кодирование нежелательно. Эта байтовая строка должна иметь кодировку с использованием того же формата, который установлен для ЕРАТН.

Ключевое слово ExternlDExactMatch должно иметь одно поле со значением "да" или "нет". Положительное значение подразумевает, что ExternallD определяет одно конкретное устройство, отрицательное значение подразумевает, что ExternallD устанавливает только одно устройство из набора совместимых устройств. Если ключевое слово ExternlDExactMatch пропущено, то условие по умолчанию должно быть таким, чтобы ExternalID устанавливал одно конкретное устройство.

Ключевое слово Query должно иметь четыре поля. Первое поле должно быть путем, указывающим на адресуемый по связи атрибут, содержащий набор внешних идентификаторов, по одному для каждого слота блока за исключением слота 0. Второе поле должно обеспечивать использование путем запроса (то есть 1 - получить все атрибуты или 14 - получить один атрибут). Третье поле должно быть целым числом, которое определяет число байтов, используемых для идентификации каждого модуля, и иметь диапазон 1-16. Если в блоке имеется модуль с двойными слотами, внешний идентификатор для этого модуля должен появляться дважды в наборе, возвращаемом в ответе на запрос. Запрос должен адресоваться только на модуль в слоте 0. Четвертое поле должно быть ExternallD, возвращаемым, когда существует пустой слот, с кодировкой в формате, установленном для ЕРАТН.

На рисунке А.14 приведен пример, показывающий типичную секцию [Modular], описывающую модуль, имеющий соединение связи, помещенный в слот 0.

Рисунок А.14 - Пример секции [Modular] (модуль с соединением связи в слоте 0)

А.4.1.5.3 Модульные дополнения к основным секциям EDS

А.4.1.5.3.1 Дополнения к секции Parameter

Для описания параметров, которые ретранслируются адаптерным устройством ControlNet на другое устройство, не поддерживающее протокол CIP, необходимо использовать ключевые слова ProxyParam и ProxiedParam. Примером является адаптерный модуль ControlNet (устройство, выполняющее функции доступа к соединению) в блоке с многими слотами ввода/вывода для модуля с аналоговыми вводом/выводом (устройство, для которого реализуются функции proxy).

ProxyParam в EDS предназначено для устройства, которое выполняет функции proxy.

Ключевое слово ProxiedParam в EDS предназначено для устройства, для которого выполняются функции proxy.

Информация в секции [Modular] должна быть использована для создания ассоциируемых файлов EDS, содержащих ключевые слова ProxyParam и сопоставимых с файлами EDS, содержащими ключевые слова ProxiedParam. Данное сопоставление актуально, когда оба файла EDS указывают соответствующие входы "Rack".

Десятичное число (которое комбинируется с ProxyParam и ProxiedParam) должно быть использовано для указания соответствия между ProxyParam и ProxiedParam. Значения поля соответствующих пар ProxyParam и ProxiedParam должны быть скомбинированы для составления такой же информации значения поля, которая существует в одном входе "Param". Эта комбинация должна быть выполнена путем использования значения поля из ProxyParam, если только это значение поля не является ключевым словом Module. Когда значение поля, указанное в ProxyParam, - Module, следует использовать значение поля, указанное в ProxiedParam. Обычно указывают значения поля для входов "ProxiedParam", которым соответствуют значения поля в ProxyParam, не являющиеся Module, однако эти значения поля не должны использоваться, их следует отмечать только для документации.

В секции [Params] может также существовать другое ключевое слово. Это ключевое слово должно быть использовано для предоставления минимального и максимального значений, а также значения, установленного по умолчанию, которые следует добавлять к минимальным, максимальным и установленным по умолчанию значениям ProxyParam. Это ключевое слово входа должно быть ProxyParamSizeAdder, скомбинированное с десятичным числом из соответствующего входа ProxyParam. Каждый вход "ProxyParam" должен состоять из полей Minimum Value, Maximum Value и Default Value. Определение этих полей соответствует определениям Param. Ключевое слово ProxyParamSizeAdder предоставляет средства для адаптера соединения модуля (например, ProxyConnect), позволяющие добавлять данные адаптера к данным модуля и возвращать комбинированные данные по соединению.

В секции [Param] может также существовать другое ключевое слово, которое соответствует ProxyParam - ProxyEnum. ProxyEnum имеет такое же определение, как Enum, за исключением того, что оно ассоциировано с ProxyParam вместо Param. В секции [Param] может также существовать второе ключевое слово, которое соответствует ProxiedParam - ProxiedEnum. ProxiedEnum имеет такое же определение, как Enum, за исключением того, что оно ассоциировано с ProxiedParam вместо Param.

А.4.1.5.3.2 Дополнения к секции Assembly

Дополнительные ключевые слова входа

Ключевые слова ProxyAssem и ProxiedAssem должны быть использованы для описания функциональных блоков, которые выполняют функцию proxy с помощью адаптерного устройства CIP для другого устройства, которое не поддерживает CIP. Примером этого является адаптерный модуль ControlNet (устройство для осуществления proxying-соединения) в блоке с множественными слотами входа/выхода, соединяющий его с аналоговым модулем входа/выхода (устройство, на соединении с которым выполняется функция proxy).

Ключевое слово ProxyAssem в EDS предназначено для устройства, выполняющего функцию proxy; ключевое слово ProxiedAssem в EDS предназначено для устройства, для которого выполняется функция proxy.

Информация в секции [Modular] должна использоваться для создания файлов EDS, содержащих ключевые слова ProxyAssem, сопоставимых с файлами EDS, содержащими ключевые слова ProxiedAssem. Данное сопоставление актуально, когда оба файла EDS указывают соответствующий вход Rack.

Десятичное число (которое комбинируется с ProxyAssem и ProxiedAssem) должно быть использовано для указания соответствия между ProxyAssem и ProxiedAssem. Значения поля соответствующих пар ProxyAssem и ProxiedAssem должны быть скомбинированы для отображения такой же информации значения поля, которая существует в одном входе Assem. Комбинирование должно быть выполнено путем использования значения поля из ProxyAssem, если только это значение поля не является одним из ключевых слов Module или ModuleMemberList. Когда значение поля, указанное в ProxyAssem, - Module, следует использовать значение поля, указанное в ProxiedAssem. Значение поля Module не должно использоваться для полей Member Size или Member Reference. ModuleMemberList должен использоваться только вместо пары полей Member Size и Member Reference. Когда значение поля, установленное в ProxyAssem, - ModuleMemberList, должны быть использованы все поля Member Size и Member Reference, указанные в ProxiedAssem. Обычно указывают значения поля для входов ProxiedAssem, которым соответствуют значения поля в ProxyAssem, не являющиеся Module, однако эти значения поля не должны использоваться, их следует отмечать только для документации.

Дополнительные ключевые слова поля

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

Приведенные далее ключевые слова являются дополнительными значениями, разрешенными для поля Member Reference в секции Assembly, которые указывают специальные цели, предусмотренные при использовании данных, определенных элементом объединения:

- ExternallD;

- InputSlotMask0 или InputSlotMask1;

- OutputSlotMask0 или OutputSlotMask1;

- ConfigSlotMask0 или ConfigSlotMask1.

Ключевое слово ExternallD указывает, что этот член сборки должен содержать либо значение ExternallD модульного устройства, если желательно наличие ключа устройства, либо значение GenericID, определенное в EDS адаптера, если ключ нежелателен.

Ключевое слово ExternallD, скомбинированное с десятичным числом (например, ExternalID2), должно использоваться для разрешения применения ключа отдельного устройства для соединений с адаптерным блоком. Десятичное (положительное) число N в ExternallDN указывает слот N в блоке. Ключевое слово ExternallDN указывает, что этот элемент сборки должен содержать либо значение ExternallD модульного устройства для слота N, если желательно применение ключа устройства на данном слоте, либо значение GenericID, определенное в EDS адаптера, если применение ключа модуля на данном слоте нежелательно.

Примечание - Ключ для слота 0 отсутствует.

Ключевые слова InputSlotMask0 или InputSlotMask1 должны показывать расположение входной маски слота в сборке. Входная маска слота - набор битов, представляющих включение или исключение целевых данных создателем модуля в адаптерном соединении стойки. Если используется ключевое слово InputSlotMask0, бит 0 в этом наборе представляет слот 0, бит 1 представляет слот 1 и т.д. Если используется ключевое слово InputSlotMask1, бит 0 в этом наборе представляет слот 1, бит 1 представляет слот 2 и т.д. InputSlotMask0 и InputSlotMask1 не должны быть оба использованы в одной и той же сборке. Должно использоваться предшествующее поле Member Size.

Ключевые слова OutputSlotMask0 или OutputSlotMask1 должны указывать расположение маски слота выхода в сборке. Выходная маска слота является набором битов, представляющих включение или исключение целевых данных создателем модуля в соединении адаптерной стойки. Если используется ключевое слово OutputSlotMask0, бит 0 в этом наборе представляет слот 0, бит 1 представляет слот 1 и т.д. Если используется ключевое слово OutputSlotMask1, бит 0 в этом наборе представляет слот 1, бит 1 представляет слот 2 и т.д. OutputSlotMask0 и OutputSlotMask1 не должны быть оба использованы в одной и той же сборке. В данном случае должно использоваться предшествующее поле Member Size.

Ключевые слова ConfigSlotMask0 или ConfigSlotMask1 должны указывать расположение маски слота конфигурации в сборке. Маска слота конфигурации представляет собой набор битов, представляющих включение или исключение данных конфигурации модуля при определении сервиса соединения с помощью адаптерного блока. Если используется ключевое слово ConfigSlotMask0, бит 0 в этом наборе представляет слот 0, бит 1 представляет слот 1 и т.д. Если используется ключевое слово ConfigSlotMask1, бит 0 в этом наборе представляет слот 1, бит 1 представляет слот 2 и т.д. ConfigSlotMask0 и ConfigSlotMask1 не должны быть оба использованы в одной и той же сборке. Должно использоваться предшествующее поле Member Size.

А.4.1.5.3.3 Дополнения к секции Connection Manager

Ключевые слова ProxyConnect и ProxiedConnect должны быть использованы для описания соединений, для которых выполняется функция proxy с помощью адаптерного устройства CIP, с другим устройством, которое не поддерживает протокол CIP. Примером этого является адаптерный модуль ControlNet (устройство для осуществления proxying-соединения) в блоке с множественными слотами входа/выхода, соединяющий его с аналоговым модулем входа/выхода (устройство, в соединении с которым выполняется функция proxy).

Ключевое слово ProxyConnect в EDS предназначено для устройства, выполняющего функцию proxy. В приведенном выше примере этим устройством будет адаптерный модуль ControlNet.

Ключевое слово ProxiedConnect в EDS предназначено для устройства, для которого выполняется функция proxy. В приведенном выше примере этим устройством является аналоговый модуль входа/выхода.

Информация в секции [Modular] должна использоваться для создания файлов EDS, содержащих ключевые слова ProxyConnect и сопоставимых с файлами EDS, содержащими ключевые слова ProxiedConnect. Данное сопоставление актуально, когда оба файла EDS указывают соответствующий вход Rack.

Десятичное число (которое комбинируется с ProxyConnect и ProxiedConnect) должно быть использовано для указания соответствия между ProxyConnect и ProxiedConnect. Значения поля соответствующих пар ProxyConnect и ProxiedConnect должны быть скомбинированы для отображения такой же информации для значения поля, которая существует в одном входе Connection. Эта комбинация должна быть составлена путем использования значений поля из ProxyConnect за исключением тех полей, для которых значение равно ключевому слову Module. В этих случаях должно быть использовано значение поля, установленное в ассоциированном ProxiedConnect. Обычно указывают значения поля для входов ProxiedConnect, которым соответствуют значения поля в ProxyConnect, не являющиеся Module, однако эти значения поля не должны использоваться, их следует отмечать только для документации. Значение поля в ProxyConnect для поля "строка имени соединения" не должно быть Module. ProxyConnect должен всегда указывать строку имени соединения.

А.4.1.5.3.4 Примеры расширенной секции EDS (информативные)

На рисунках А.15 и А.16 приведены примеры, демонстрирующие использование модульных расширений EDS для секций Parameter, Assembly и Connection Manager.

Рисунок А.15 - Пример входов ProxyParam и ProxyAssem

Рисунок А.16 - Пример соответствующих входов ProxiedParam и ProxiedAssem

А.4.2 Специальные требования к EDS в ControlNet

А.4.2.1 Содержание EDS в ControlNet

Данный подраздел устанавливает требования к кодировке в EDS в сетях ControlNet.

В таблице А.29 в обобщенном виде приводится структура секций, которые могут быть представлены в ControlNet EDS, соответствующие принятые разграничители секций и порядок этих секций в EDS. Некоторые из этих секций являются общими для ряда основанных на CIP сетей, и их специальное применение в ControlNet указано далее в А.4.2.2. Другие секции, специфические для ControlNet, рассмотрены в А.4.2.4.

Таблица А.29 - Структура файла EDS в ControlNet

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

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

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

А.4.2.2 Выполнение общих требований CIP

А.4.2.2.1 Секция Device Classification

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

А.4.2.2.2 Секция Port

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

- поле Port Type Name должно иметь значение ControlNet;

- опциональное поле Port Object должно быть установлено для пути объекта ControlNet для этого порта;

- никакие дополнительные требования, кроме указанных в общем подразделе CIP (см. А.4.1.4.10), не устанавливаются в поля Port Name и Port Number.

А.4.2.3 Дополнительные требования к кодировке данных

Никаких дополнительных требований к кодировке файлов ControlNet EDS не существует.

А.4.2.4 Дополнительные требования к файлам

А.4.2.4.1 Секция ControlNet Physical Layer

Секция ControlNet Physical Layer должна описывать временную задержку в таких компонентах физического уровня ControlNet, как повторитель или коаксиальный кабель RG-6. Эта секция должна быть включена в EDS, только если вход ProdType из секции Device Description равен 50. Один вход, Delay 1, должен содержать форматированные поля, показанные в таблице А.30.

Таблица А.30 - Формат физического уровня ControlNet

Первое поле, называемое Units, должно быть ссылкой на вход из секции [Params], описывающей параметр типа USINT. Поля Min Delay Per Unit и Max Delay Per Unit при умножении на масштабированную величину параметра USINT должны определять диапазон возможной задержки, создаваемой для каждого фрейма, проходящего через устройство. Результирующая задержка должна быть выражена в единицах пикосекунд.

Примечание - Расчет времени распространения по ширине канала связи используется для расчета временного параметра слота пакета модератора (см. МЭК 61158-4:2003 (тип 2)). Параметр USINT сохраняется в атрибуте варианта 00103 объекта Keeper (см. МЭК 61158-4:2003 (тип 2)).

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

Рисунок А.17 - Пример EDS для устройства физического уровня

А.4.2.4.2 Секция Keeper

Секция Keeper должна описывать объект Keeper в устройстве. Ключевое слово входа Revision должно иметь одно поле UINT, которое должно быть проверкой (атрибут класса 1) объекта Keeper, как показано на рисунке А.18.

Рисунок А.18 - Пример секции [Keeper]

А.4.2.4.3 Секция Scheduling

Секция Scheduling должна описывать объект Scheduling в устройстве. Ключевое слово входа Revision должно иметь одно поле UINT, которое должно быть проверкой (атрибут класса 1) объекта Scheduling устройства, как показано на рисунке А.19.

Рисунок А.19 - Пример секции [Scheduling]

А.4.2.4.4 Секция Capacity

Секция Capacity должна содержать информацию относительно емкости канального уровня устройства.

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

Если MaxReceiveLPacketsPerNUT (соответственно MaxTransmitLPacketsPerNUT) не установлено, это устройство поддерживает неограниченное число получаемых (соответственно передаваемых) LPackets при всех значениях NUT.

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

Таблица A.31 - Формат MaxReceiveLPacketsPerNUT и MaxTransmitLPacketsPerNUT

Поля 1-4 должны быть зарезервированы и быть пустыми.

Оставшиеся поля должны быть парными, то есть полю LPackets должно соответствовать поле NUT, и полное число полей должно быть четным. Число пар полей в каждом входе должно быть переменным.

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

Таблица А.32 - Формат MaxReceiveLPacketsPerNUT/MaxTransmitLPacketsPerNUT

На рисунке А.20 приведен пример типичной секции [Capacity].

Рисунок А.20 - Пример секции [Capacity]

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

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

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

Средства (инструменты) конфигурации, имеющиеся в настоящее время в устройствах PROFIBUS и соответствующие МЭК 61784-1:2003 СР3/1 и СР3/2, используют специальные форматированные файлы ASCII, называемые Generic Station Description (GSD) и Electronic Device Description (EDD), которые содержат, например, следующую информацию об устройстве:

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

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

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

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

Объекты, синтаксис и семантика GSD описаны в разделах В.4 и В.5. EDD должен соответствовать стандарту МЭК 61804-2 (изд.1, F.2) (профиль для PROFIBUS).

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

Все устройства, обладающие коммуникационным интерфейсом, соответствующим МЭК 61784-1:2003 СР3/1 и СР3/2, должны иметь файл GSD. Основное назначение файла GSD состоит в предоставлении информации для коммуникационной сети PROFIBUS. В Приложении В имя PROFIBUS DP и акроним DP используются в протоколах и сервисах устройств, которые соответствуют МЭК 61784-1:2003 СР3/1 и СР3/2.

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

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

- инкапсуляции принятых файлов GSD и EDD в шаблоны ("оболочки"), представленные в ИСО 15745;

- принятых GSD, включающих общую семантическую информацию.

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

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

XML-файлы профиля устройства, используемые для инкапсуляции файлов GSD или EDD, должны соответствовать XML-профилю устройства, установленному в В.2.2.

В случае простых устройств файл GSD содержит информацию о профиле устройства и элемент ProfileTechnology оболочки профиля устройства в В.2.2 должен быть установлен в GSD. Если существует EDD, то он является единственным необходимым профилем устройства и элемент ProfileTechnology оболочки профиля устройства в В.2.2 должен быть установлен в EDDL.

Таблица В.1 определяет эквиваленты XML-заголовков устройства содержанию файлов GSD или EDD.

Таблица B.1 - Элементы ExternalProfileHandle

В.2.2 XML-схема: GSD_Device_Profile_wrapper.xsd или EDD_Device_Profile_wrapper.xsd

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

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

Файлы XML-профиля коммуникаций должны соответствовать XML-схеме профиля коммуникационной сети, описанной далее. Этот профиль должен иметь ссылку на оболочку XML-профиля коммуникационной сети, указывающую на файл Generic Station Data (GSD) согласно В.4 и В.5.

В таблице В.2 определены эквиваленты XML-заголовков устройства содержанию файла GSD.

Таблица В.2 - Элементы ExternalProfileHandle

В.3.2 XML-схема: GSD_CommNet_Profile_wrapper.xsd

В.4 Generic Station Description (GSD)

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

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

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

Файлы GSD характеризуют технические и эксплуатационные параметры устройств PROFIBUS.

Каждый поставщик DP-Master или DP-Slave (класс 1) должен предоставить пользователю характеристики устройства в виде спецификации и файла GSD. Использование этой информации позволит пользователю выполнить проверку всех данных на этапе конфигурации системы PROFIBUS и избежать ошибок на раннем этапе. Исходя из определенного в разделах В.4.2, В.5 и В.6 формата файлов, возможно реализовать независимые от поставщика средства конфигурации систем PROFIBUS. Средства конфигурации используют файлы GSD для проверки данных. Эти данные вводятся при соблюдении пределов и достоверности характеристик индивидуальных устройств.

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

В случае устройства, поддерживающего протокол PROFIBUS DP и другой протокол (например, PROFIBUS FMS, см. [10]), другая специальная базовая информация об устройстве должна быть помещена в начале файла GSD.

Примечание - В ИСО 15745-3 описаны GSD только для PROFIBUS DP.

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

GSD выполняет требования профиля коммуникационной сети.

Формат файла GSD указан в В.4.2. Объекты, синтаксис и семантика GSD определены в В.5 и В.6.

В.4.2 Синтаксис и формат файлов GSD

Файл GSD должен быть файлом ASCII и может быть создан в любом применимом для ASCII текстовом редакторе. Относящаяся к DP часть должна начинаться с идентификатора "#Profibus_DP". База данных устройства должна быть указана как параметр ключевого слова. При оценке ключевых слов вид букв (заглавных или строчных) не имеет значения.

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

Формат файла должен быть линейным. Каждая строка должна содержать утверждение точно для одного параметра. Если при обработке строки обнаружена точка с запятой, то принимается, что остальная часть строки является комментарием. Максимальное число символов в строке установлено равным 80. Если невозможно описать информацию в одной строке, то допускается использовать строки продолжения. Символ "\" в конце строки указывает, что следующая строка является ее продолжением. Проводится различие между числовыми параметрами и текстовыми параметрами. Никакие специальные признаки окончания не определены. Однако должно быть гарантировано, что файл заканчивается после полной строки. Параметры, которые не используются в DP-Master или DP-Slave, должны быть опущены.

Примечание 2 - PROFIBUS-Master и PROFIBUS-Slave означает устройства, которые соответствуют МЭК 61784-1:2003 СР 3/1 или 3/2, см. МЭК 61784-1:2003, 7.2.2.1.2ff.

Файл GSD должен быть создан и предоставлен пользователю на соответствующем языке. Должна быть создана версия, принимаемая по умолчанию, на английском языке (GSD). В зависимости от языка файлы могут различаться только в параметрах типа Visible String и Slave_Family. Зависящие от языка файлы описания устройства различаются по последней букве расширения (*.gs?):

Общие спецификации

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

Спецификации, относящиеся к ведущему устройству

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

Спецификации, относящиеся к ведомому устройству

Данный раздел файла GSD должен содержать все спецификации, относящиеся к ведомому компьютеру, например число и тип каналов ввода/вывода, спецификации диагностических текстов и информацию о существующих модулях в модульных устройствах. В отдельных разделах параметры разделяются ключевыми словами. Проводится различие между обязательными параметрами (например, Vendor_Name) и опциональными параметрами (например, Sync_Mode_supp). Определение групп параметров допускает выбор опций. Кроме того, могут быть вставлены файлы побитового [двоичного] отображения с символами устройств. Формат GSD разработан с учетом гибкости. Он содержит как перечни (например, значения скорости двоичной передачи данных, поддерживаемых устройством), так и места для описания модулей, имеющихся в модульном устройстве. Для диагностических сообщений может также использоваться читаемый текст. Этот раздел для ведущих устройств не предназначен.

В.5 Семантика GSD

В.5.1 Соглашения

Установленные далее атрибуты должны указывать технические и эксплуатационные характеристики устройств PROFIBUS, соответствующих МЭК 61784-1:2003 СР 3/1 или 3/2. В качестве синонимов этих устройств PROFIBUS в данном Приложении В используются термины PROFIBUS DP или просто DP/

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

- обязательные (М): абсолютно необходимые;

- опциональные (О): возможные дополнительные;

- по умолчанию (D): опциональные при значении, по умолчанию равном 0, если таковые не присутствуют;

- групповые (G): требуется по крайней мере одно ключевое слово группы.

Расширения выпущенных спецификаций GSD (например, новые ключевые слова) представлены в настоящем стандарте в виде версии ID (GSD_Revision), которая указывает версию, в которой добавлено расширение. Ключевые слова без указания версии ID относятся к оригинальной версии.

Ключевые слова классифицируются следующим образом:

- общие спецификации, см. В.5.2;

- спецификации, относящиеся к ведущему устройству, см. В.5.3;

- спецификации, относящиеся к ведомому устройству, см. В.5.4.

В.5.2 Общие спецификации

В.5.2.1 Общие ключевые слова DP

GSD_Revision: (M начинается с GSD_Revision 1)

Версия ID-формата файла GSD.

Тип: Unsigned 8

Vendor_Name: (M)

Имя изготовителя.

Тип: Visible-String (32)

Model_Name: (M)

Обозначение изготовителя устройства (Controller Type).

Тип: Visible-String (32)

Revision: (M)

Версия пересмотра устройства.

Тип: Visible-String (32)

Revision_Number: (О начинается с GSD_Revision 1)

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

Тип: Unsigned 8 (1-63)

Ident_Number: (М)

Тип устройства для устройства.

Ident_Number присваивается организацией PROFIBUS Nutzer Organisation e.V. (PNO) каждому типу устройства. Изготовители устройств должны обращаться в PNO для получения Ident_Number.

Тип: Unsigned 16

Protocol_Ident: (M)

ID протокола устройства.

Тип: Unsigned 8

0: PROFIBUS DP

16-255: в зависимости от изготовителя

Station_Type: (M)

Тип устройства DP.

Тип: Unsigned 8

0: DP-Slave

1: DP-Master (класс 1)

FMS_supp: (D)

Данное устройство является смешанным устройством FMS/DP.

Тип: Boolean (1: истинно)

Hardware_Release: (M)

Выпуск аппаратного оборудования устройства.

Тип: Visible-String (32)

Software_Release (M)

Выпуск программного оборудования устройства.

Тип: Visible-String (32)

9.6_supp: (G)

Устройство поддерживает скорость двоичной передачи 9,6 кбит/с.

Тип: Boolean (1: истинно)

19.2_supp: (G)

Устройство поддерживает скорость двоичной передачи 19,2 кбит/с.

Тип: Boolean (1: истинно)

31.25_supp: (G начинается с GSD_Revision 2)

Устройство поддерживает скорость двоичной передачи 31,25 кбит/с.

Тип: Boolean (1: истинно)

45.45_supp: (G начинается с GSD_Revision 2)

Устройство поддерживает скорость двоичной передачи 45,45 кбит/с.

Тип: Boolean (1: истинно)

93.75_supp: (G)

Устройство поддерживает скорость двоичной передачи 93,75 кбит/с.

Тип: Boolean (1: истинно)

187.5_supp: (G)

Устройство поддерживает скорость двоичной передачи 187,5 кбит/с.

Тип: Boolean (1: истинно)

500_supp: (G)

Устройство поддерживает скорость двоичной передачи 500 кбит/с.

Тип: Boolean (1: истинно)

1.5M_supp: (G)

Устройство поддерживает скорость двоичной передачи 1,5 Мбит/с.

Тип: Boolean (1: истинно)

3M_supp: (G начинается с GSD_Revision 1)

Устройство поддерживает скорость двоичной передачи 3 Мбит/с.

Тип: Boolean (1: истинно)

6M_supp: (G начинается с GSD_Revision 1)

Устройство поддерживает скорость двоичной передачи 6 Мбит/с.

Тип: Boolean (1: истинно)

12M_supp: (G начинается с GSD_Revision 1)

Устройство поддерживает скорость двоичной передачи 12 Мбит/с.

Тип: Boolean (1: истинно)

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

MaxTsdr_9.6: (G)

Это максимальное время, которое необходимо респонденту (отвечающему) при скорости двоичной передачи 9,6 кбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_19.2: (G)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 19,2 кбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_31.25: (G начинается с GSD_Revision 2)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 31,25 кбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_45.45: (G начинается с GSD_Revision 2)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 45,45 кбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_93.75: (G)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 93,75 кбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_187.5: (G)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 187,5 кбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_500: (G)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 500 кбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_1.5M: (G)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 1,5 Мбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_3M: (G начинается с GSD_Revision 1)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 3 Мбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_6M: (G начинается с GSD_Revision 1)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 6 Мбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

MaxTsdr_12M: (G начинается с GSD_Revision 1)

Это максимальное время, которое необходимо респонденту при скорости двоичной передачи 12 Мбит/с для отклика на сообщение с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Redundancy: (D)

Это значение устанавливает, поддерживает или нет устройство технические средства избыточной передачи.

Тип: Boolean

0: нет

1: избыточность поддерживается

Repeater_Ctrl_Sig: (D)

Здесь устанавливается уровень сигнала CNTR-P панели шинных соединителей.

Тип: Unsigned 8

0: соединения нет

1: RS485,2:TTL

24V_Pins: (D)

Здесь устанавливается значение сигнала M24V и P24V панели блочных соединителей.

Тип: Unsigned 8

0: соединения нет

1: ввод

2: вывод

Implementation_Type: (О начинается с GSD_Revision 1)

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

Тип: Visible-String (32)

Bitmap_Device: (О начинается с GSD_Revision 1)

Здесь в DIB-формате установлено имя файла (*.DIB) побитового [двоичного] отображения (7040 пикселей (ширинавысота), 16 цветов), который содержит символическое представление устройства в стандартных случаях.

Тип: Visible-String (8)

Bitmap_Diag: (О начинается с GSD_Revision 1)

Здесь в DIB-формате установлено имя файла (*.DIB) побитового [двоичного] отображения (7040 пикселей (ширинавысота), 16 цветов), который содержит символическое представление устройства для целей диагностики.

Тип: Visible-String (8)

Bitmap_SF: (О начинается с GSD_Revision 1)

Здесь в DIB-формате установлено имя файла (*.DIB) побитового [двоичного] отображения (7040 пикселей (ширинавысота), 16 цветов), который содержит символическое представление устройства в специальных рабочих режимах. Значение зависит от изготовителя.

Тип: Visible-String (8)

В.5.2.2 Дополнительные ключевые слова для различных физических интерфейсов

Physical_lnterface: (О начинается с GSD_Revision 3)

Это значение определяет выполнение физических уровней PROFIBUS. С этим параметром возможно иметь устройства с более чем одним физическим интерфейсом или интерфейсами, отличными от RS485. Если это ключевое слово не используется, то стандартный RS485 является единственным поддерживаемым физическим интерфейсом. Между ключевыми словами Physical_lnterface и End_Physical_lnterface указаны Transmission_Delays и Reaction_Delay ведомого устройства, относящиеся к физическому интерфейсу, используемому в данном устройстве. Transmission_Delay определяет время задержки для сигнала, который должен передаваться через устройство. Reaction_Delay определяет задержку сигналов, обрабатываемых устройством.

Рисунок В.1 - Пример Physical_lnterface

Пример - Значение Transmission_Delay с RS485 равно 0, значение Reaction_Delay также равно 0, так как задержка в задающем устройстве меньше, чем время прохождения 1 бита, см. рисунок В.1.

Эти параметры особенно необходимы для расчета временных параметров шины в случае оптических интерфейсов. Как Transmission_Delay, так и Reaction_Delay должны быть определены для каждого поддерживаемого значения скорости двоичной передачи данных. Иначе скорость двоичной передачи данных не будет корректной для данного физического уровня.

Кодировка интерфейсов:

Тип: Unsigned 8

0: RS 485 (ANSI TIA/EIA RS-485-A); в качестве опции версия с внутренней безопасностью RS 485 (см. [11])

1: манчестерский код и питание от шины (МВР); в качестве опции IS (MBP-IS) и пониженная мощность (MBP-LP)

2: пластмассовый светопровод

3: стеклянное многомодовое стекловолокно или стеклянное одномодовое стекловолокно

4: стекловолокно с полимерной оболочкой (PCF)

5-127: зарезервировано

128-255: зависит от изготовителя

Использованные параметры:

Transmission_Delay_9.6: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_19.2: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_31.25: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_45.45: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_93.75: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_187.5: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_500: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_1.5M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_3M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_6M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Transmission_Delay_12M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_9.6: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_19.2: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_31.25: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_45.45: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_93.75: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_187.5: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_500: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_1.5M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_3M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_6M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

Reaction_Delay_12M: (G начинается с GSD_Revision 3)

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

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

В.5.3 Спецификации, относящиеся к ведущему устройству

В.5.3.1 Ключевые слова, относящиеся к DP-Master (класс 1)

Master_Freeze_Mode_supp: (D начинается с GSD_Revision 3)

Данное устройство поддерживает режим Freeze.

Тип: Boolean (1: истинно)

Master_Sync_Mode_supp: (D начинается с GSD_Revision 3)

Данное устройство поддерживает режим Sync.

Тип: Boolean (1: истинно)

Master_Fail_Safe_supp: (D начинается с GSD_Revision 3)

Данное устройство поддерживает безаварийный режим Fail Safe.

Тип: Boolean (1: истинно)

Download_supp: (D)

Данное устройство поддерживает Download, Start_seq и End_seq.

Тип: Boolean (1: истинно)

Upload_supp: (D)

Данное устройство поддерживает функции Upload, Start_seq и End_seq.

Тип: Boolean (1: истинно)

Act_Para_Brct_supp: (D)

Данное устройство поддерживает функцию Act_Para_Brct.

Тип: Boolean (1: истинно)

Act_Param_supp: (D)

Данное устройство поддерживает функцию Act_Param.

Тип: Boolean (1: истинно)

Max_MPS_Length: (M)

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

Тип: Unsigned 32

Max_Lsdu_MS: (M)

Здесь определена максимальная длина L_sdu для коммуникационных связей master - slave.

Тип: Unsigned 8

Max_Lsdu_MM: (M)

Здесь определена максимальная длина L_sdu для коммуникационных связей master - master.

Тип: Unsigned 8

Min_Poll_Timeout: (M)

Данная величина определяет максимальный промежуток времени, требующийся DP-Master (класс 1) для обработки функции master - master.

Тип: Unsigned 16

Масштаб по оси времени: 10 мс.

Trdy_9.6: (G)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 9,6 кбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_19.2: (G)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 19,2 кбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_31.25: (G начинается с GSD_Revision 2)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 31,25 кбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_45.45: (G начинается с GSD_Revision 2)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 45,45 кбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_93.75: (G)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 93,75 кбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_187.5: (G)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 187,5 кбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_500: (G)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 500 кбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_1.5M: (G)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 1,5 Мбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_3M: (G начинается с GSD_Revision 1)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 3 Мбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_6M: (G начинается с GSD_Revision 1)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 6 Мбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Trdy_12M: (G начинается с GSD_Revision 1)

Данная величина определяет, насколько быстро DP-Master (класс 1) при скорости двоичной передачи 12 Мбит/с готов получать данные после отправления сообщения с запросом (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_9.6: (G)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 9,6 кбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_19.2: (G)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 19,2 кбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_31.25: (G начинается с GSD_Revision 2)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 31,25 кбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_45.45: (G начинается с GSD_Revision 2)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 45,45 кбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_93.75: (G)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 93,75 кбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_187.5: (G)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 187,5 кбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_500: (G)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 500 кбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_1.5M: (G)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 1,5 Мбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_3M: (G начинается с GSD_Revision 1)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 3 Мбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_6M: (G начинается с GSD_Revision 1)

Данная величина определяет время затухания модулятора (Tqui) (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 6 Мбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tqui_12M: (G начинается с GSD_Revision 1)

Данная величина определяет время затухания модулятора (Tqui), (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 12 Мбит/с.

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_9.6: (G)

Данная величина определяет время запуска при скорости двоичной передачи 9,6 кбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_19.2: (G)

Данная величина определяет время запуска, при скорости двоичной передачи 19,2 кбит/с, по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_31.25: (G начинается с GSD_Revision 2)

Данная величина определяет время запуска при скорости двоичной передачи 31,25 кбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_45.45: (G начинается с GSD_Revision 2)

Данная величина определяет время запуска при скорости двоичной передачи 45,45 кбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_93.75: (G)

Данная величина определяет время запуска при скорости двоичной передачи 93,75 кбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_187.5: (G)

Данная величина определяет время запуска при скорости двоичной передачи 187,5 кбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_500: (G)

Данная величина определяет время запуска при скорости двоичной передачи 500 кбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_1.5M: (G)

Данная величина определяет время запуска при скорости двоичной передачи 1,5 Мбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_3M: (G начинается с GSD_Revision 1)

Данная величина определяет время запуска при скорости двоичной передачи 3 Мбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_6M: (G начинается с GSD_Revision 1)

Данная величина определяет время запуска при скорости двоичной передачи 6 Мбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

Tset_12M: (G начинается с GSD_Revision 1)

Данная величина определяет время запуска при скорости двоичной передачи 12 Мбит/с по отношению к Layer2 (время подготовки к работе) от получения сообщения до соответствующего отклика (см. МЭК 61158-4:2003, Приложение Е).

Тип: Unsigned 8

Масштаб по оси времени: интервал передачи бита.

LAS_Len: (M)

Данная величина определяет, сколькими входами рассматриваемое устройство может управлять в списке активных станций (LAS).

Тип: Unsigned 8

Tsdi_9.6: (G)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 9,6 кбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_19.2: (G)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 19,2 кбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_31.25: (G начинается с GSD_Revision 2)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 31,25 кбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_45.45: (G начинается с GSD_Revision 2)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 45,45 кбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_93.75: (G)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 93,75 кбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_187.5: (G)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 187,5 кбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_500: (G)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 500 кбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_1.5M: (G)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 1,5 Мбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_3M: (G начинается с GSD_Revision 1)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 3 Мбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_6M: (G начинается с GSD_Revision 1)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 6 Мбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Tsdi_12M: (G начинается с GSD_Revision 1)

Данная величина определяет время задержки станции (Tsdi) инициатора (см. МЭК 61158-4:2003, Приложение Е) при скорости двоичной передачи 12 Мбит/с.

Тип: Unsigned 16

Масштаб по оси времени: интервал передачи бита.

Max_Slaves_supp: (M)

Данная величина определяет, сколькими станциями DP-slave может управлять DP-master (класс 1).

Тип: Unsigned 8

Max_Master_lnput_Len: (О начинается с GSD_Revision 1)

Здесь определена максимальная длина входных данных на DP-slave, которую поддерживает DP-master.

Тип: Unsigned 8

Max_Master_Output_Len: (О начинается с GSD_Revision 1)

Здесь определена максимальная длина выходных данных на DP-slave, которую поддерживает DP-master.

Тип: Unsigned 8

Max_Master_Data_Len: (О начинается с GSD_Revision 1)

Здесь определена сумма значений длины выходных и входных данных на DP slave, которую поддерживает DP-master. Если это ключевое слово не предоставлено, максимальной длиной будет сумма значений длины входных и выходных данных.

Тип: Unsigned 16

В.5.3.2 Дополнительные ключевые слова для расширений DP, относящиеся к ведущему компьютеру

DPV1_Master: (D начинается с GSD_Revision 3)

DP-master поддерживает DP-V1-расширения протокола DP

Тип: Boolean (1: истинно)

DPV1_Conformance_Class: (M, если DPV1_Master, начинается с GSD_Revision 3)

Эта величина определяет Conformance Class DP-Master (класс 1). Установлены следующие Conformance Class для DP-Master (класс 1):

Тип: Unsigned 8

1: Conformance Class A

2: Conformance Class В

3-255: зарезервировано

C1_Master_Read_Write_supp: (D начинается с GSD_Revision 3)

DP-Master (класс 1) поддерживает сервисы Read и Write в C1 - коммуникационной связи.

Тип: Boolean (1: истинно)

Master_DPV1_Alarm_supp: (D начинается с GSD_Revision 3)

DP-Master (класс 1) поддерживает сигналы тревоги.

Тип: Boolean (1: истинно)

Master_Diagnostic_Alarm_supp: (G, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

Устройство поддерживает Diagnostic_Alarm, сигнализирующий о событии на слоте, например о перегревании, коротком замыкании и т.п.

Тип: Boolean (1: истинно)

Master_Process_Alarm_supp: (G, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

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

Тип: Boolean (1: истинно)

Master_Pull_Plug_Alarm_supp: (G, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

Устройство поддерживает Pull_Alarm, сигнализирующий об изъятии модуля из слота.

Тип: Boolean (1: истинно)

Master_Status_Alarm_supp: (G, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

Устройство поддерживает Status_Alarm, сигнализирующий об изменении состояния модуля, например о работе, остановке или готовности.

Тип: Boolean (1: истинно)

Master_Update_Alarm_supp: (G, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

Устройство поддерживает Update_Alarm, сигнализирующий об изменении параметров на слоте, например при локальной операции или удаленном доступе.

Тип: Boolean (1: истинно)

Master_Manufacturer_Specific_Alarm_supp: (G, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

Устройство поддерживает Manufacturer_Specific_Alarm, сигнализирующий о событии, инициированном изготовителем.

Тип: Boolean (1: истинно)

Master_Extra_Alarm_SAP_supp: (D, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

Дополнительно к SAP51 возможно обрабатывать MSAL_Alarm_Ack через SAP 50, если Bit SI_Flag. Extra_Alarm_SAP установлен в наборе параметров соответствующего ведомого устройства. В этом случае могут существовать более высокие характеристики, поскольку SAP 50 используется исключительно для сервиса MSAL_Alarm_Ack и этот сервис не может быть задержан вследствие работы сервиса MSAC1_Write или MSAC1_Read.

Тип: Boolean (1: истинно)

Master_Alarm_Sequence_Mode: (M, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

Ведущий DP поддерживает Alarm_Sequence_Mode с установленным числом сигналов тревоги при их обработке. Sequence Mode - опция параллельной обработки сигналов тревоги. Несколько сигналов тревоги (2-32) одного или различных типов могут быть активны одновременно (фиксируется сервисом DDLM_Set_Prm).

Тип: Unsigned 8

0 - Sequence_Mode не поддерживается

1 - всего 2 сигнала

2 - всего 4 сигнала

3 - всего 8 сигналов

4 - всего 12 сигналов

5 - всего 16 сигналов

6 - всего 24 сигнала

7 - всего 32 сигнала

Master_Alarm_Type_Mode_supp: (M, если Master_DPV1_Alarm_supp начинается с GSD_Revision 3)

DP-Master поддерживает Alarm Type Mode. Type Mode является обязательным, если DP-master поддерживает параллельную обработку сигналов тревоги. Один сигнал тревоги каждого типа может быть активным однократно (фиксируется сервисом DDLM_Set_Prm).

Тип: Boolean (должно быть всегда установлено на 1: истинно)

В.5.3.3 Дополнительные относящиеся к ведущему устройству ключевые слова для DP-V2

Isochron_Mode_Synchronised (D начинается с GSD_Revision 4)

Данный параметр показывает, может или нет ведущее устройство работать в режиме Isochron_Mode и какую модель оно при этом поддерживает. В связи с этим допускаются 4 значения:

Тип: Unsigned 8

0: ведущее устройство не поддерживает режим Isochron_Mode

1: ведущее устройство поддерживает только синхронизированный в буфере режим Isochron_Mode

2: ведущее устройство поддерживает только усиленно синхронизированный режим Isochron_Mode

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

Примечание - Более подробная информация о функциональных характеристиках режима Isochron_Mode содержится в [15].

DXB_Master_supp: (D начинается с GSD_Revision 4)

DP-Master поддерживает сервис Data Exchange с Broadcast.

Тип: Boolean (1: истинно)

X_Master_Prm_SAP_supp: (D начинается с GSD_Revision 4)

Показывает, может или нет X_Prm_SAP ведомого устройства быть адресован ведущим устройством. Истинно, если DPV1_Master = 1 и если ведущее устройство поддерживает структурированные данные параметризации.

Тип: Boolean (1: истинно)

В.5.4 Спецификации, относящиеся к ведомому устройству

В.5.4.1 Основные ключевые слова, относящиеся к DP-slave

Freeze_Mode_supp: (D)

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

Тип: Boolean (1: истинно)

Sync_Mode_supp: (D)

Устройство DP поддерживает Sync mode.

Тип: Boolean (1: истинно)

Auto_Baud_supp: (D)

Устройство DP поддерживает автоматическое распознавание скорости двоичной передачи данных.

Тип: Boolean (1: истинно)

Set_Slave_Add_supp: (D)

Устройство DP поддерживает функцию Set_Slave_Add.

Тип: Boolean (1: истинно)

User_Prm_Data_Len: (D)

Здесь установлена длина User_Prm_Data. Количество данных в User_Prm_Data должно быть согласовано с этим параметром.

Тип: Unsigned 8

User_Prm_Data: (О)

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

Тип: Octet-String

Min_Slave_lntervall: (M)

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

Тип: Unsigned 16

Масштаб по оси времени: 100 мкс.

Modular_Station: (D)

Здесь определено, является или нет устройство DP модульной станцией. Настоятельно рекомендуется моделировать ведомые устройства следующим образом: компактное устройство имеет только один модуль при всех идентификаторах конфигурации. Модульное устройство имеет только один идентификатор конфигурации в каждом определении модуля. Когда ведомое устройство принимает только один идентификатор конфигурации, выбранный из ряда возможных конфигураций, ведомое устройство должно стать модульной станцией с Max_Module = 1.

Тип: Boolean

0: компактное устройство

1: модульное устройство

Max_Module: (M, если Modular_Station)

Здесь установлено максимальное число модулей в модульной станции.

Тип: Unsigned 8

Max_Input_Len: (M, если Modular_Station)

Здесь установлена максимальная длина входных данных в байтах модульной станции.

Тип: Unsigned 8

Max_Output_Len: (М, если Modular_Station)

Здесь установлена максимальная длина выходных данных в байтах модульной станции.

Тип: Unsigned 8

Max_Data_Len: (О, только если Modular_Station)

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

Тип: Unsigned 16

Пример 1 -

Max_Input_Len = 24 Max_Output_Len = 30

Max_Data_Len = 30 (минимум).

Пример 2 -

Max_Input_Len = 120 Max_Output_Len = 120 Max_Data_Len =200.

Пример 3 -

Max_Input_Len = 240 Max_Output_Len = 240

Max_Data_Len = 480 (максимум).

(X_)Unit_Diag_Bit: (О, Х_начинается с GSD_Revision 4)

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

Используемые параметры:

Бит

Тип: Unsigned 16

Значение: позиция бита в относящемся к устройству диагностическом поле (LSB в первом байте - бит 0).

Diag_Text:

Тип: Visible-String (32)

(X_)Unit_Diag_Bit_Help: (О начинается с GSD_Revision 5)

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

Используемые параметры:

Бит

Тип: Unsigned 16

Значение: позиция бита в относящемся к устройству диагностическом поле (LSB в первом байте - бит 0).

Help_Text:

Тип: Visible-String (256)

(X_)Unit_Diag_Not_Bit: (О начинается с GSD_Revision 4)

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

Используемые параметры:

Бит

Тип: Unsigned 16

Значение: позиция бита в относящемся к устройству диагностическом поле (LSB в первом байте - бит 0).

Diag_Text:

Тип: Visible-String (32)

(X_)Unit_Diag_Not_Bit_Help: (О начинается с GSD_Revision 5)

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

Используемые параметры:

Бит

Тип: Unsigned 16

Значение: позиция бита в относящемся к устройству диагностическом поле (LSB в первом байте - бит 0).

Help_Text:

Тип: Visible-String (256)

(X_)Unit_Diag_Area: (О, X начинается с GSD_Revision 4)

Между ключевыми словами (X_)Unit_Diag_Area и (X_)Unit_Diag_Area_End установлено присвоение значений битового поля в относящемся к устройству диагностическом поле текстам (Diag_Text).

Используемые параметры:

First_Bit:

Тип: Unsigned 16

Значение: первая позиция бита в битовом поле (LSB в первом байте - бит 0)

Last_Bit:

Тип: Unsigned 16

Значение: последняя позиция бита в битовом поле. Битовое поле может иметь ширину максимум 16 бит.

(X_) Value: (Х_начинается с GSD_Revision 4)

Тип: Unsigned 16

Значение: значение в битовом поле

Diag_Text:

Тип: Visible-String (32)

(X_)Value_Help: (О начинается с GSD_Revision 5)

Тип: Unsigned 16

Значение: значение в битовом поле

Help_Text:

Тип: Visible-String (256)

UnitDiagType: (О начинается с GSD_Revision 4)

Между ключевыми словами UnitDiagType и EndUnitDiagType могут быть описаны различные структуры внутри Unit-Diag. Это имеет значение особенно для ведомых устройств DP-V1. Допускаются только ключевые слова, начинающиеся с "X_". Счет начинается с октет 2, первого бита типа, см. рисунок В.2. Первый определяемый бит - бит 24, первый бит Diagnosis_User_Data в октет 5, см. также рисунок В.3. Описание Diagnosis_User_Data см. в МЭК 61158-6:2003, таблица 396, в строке Device_Related_Diagnosis.

Рисунок В.2 - Счет UnitDiagType

Используемые параметры:

Diag_Type_Number:

Тип: Unsigned 8

Значение: определяет, описан или нет alarm block (0-127) или status block (128-255).

Пример 4 -

Рисунок В.3 иллюстрирует кодировку типа диагностики Alarm, которая может быть описана с помощью UnitDiagType

Рисунок В.3 - Кодировка типа диагностики Alarm

Определены следующие типы Alarm:

0: зарезервировано;

1: Diagnostic_Alarm;

2: Process_Alarm;

3: Pull_Alarm;

4: Plug_Alarm;

5: Status_Alarm;

6: Update_Alarm;

7-31: зарезервировано;

32-126: установлено изготовителем;

127: зарезервировано.

Рисунок В.4 иллюстрирует кодировку диагностики типа Status, которая также может быть описана с помощью UnitDiagType.

Рисунок В.4 - Кодировка диагностики типа Status

Определены следующие типы статуса:

0: зарезервировано;

1: Status_Message;

2: Module_Status;

3: DXB_Link_Status;

4-29: зарезервировано;

30: PrmCmdAck;

31: Red_State;

32-126: установлено изготовителем;

127: зарезервировано.

Module: (M)

Между ключевыми словами Module и EndModule определены идентификаторы компактных устройств DP или идентификаторы всех возможных модулей модульных ведомых устройств, указанные изготовителем типы ошибок в относящемся к каналу диагностическом поле и описаны User_Prm_Data. Если в случае модульных ведомых устройств пустые слоты должны быть определены как пустой модуль (ID/s 000), он должен быть обозначен. Иначе пустые слоты не могут появиться в данных конфигурации.

Если ключевое слово Channel_Diag используется вне ключевых слов Module и EndModule, одинаковый установленный изготовителем тип ошибки указывается в относящемся к каналу диагностическом поле для всех модулей. Определения Channel_Diag для указанного изготовителем типа ошибки внутри модуля перепишут определение этого типа ошибки, данное для устройства. Channel_Diag внутри модуля не влияет на другие модули. Если ключевые слова Ext_User_Prm_Data_Ref или Ext_User_Prm_Data_Const (X_Ext_User_Prm_Data_Ref или X_Ext_User_Prm_Data_Const) используются вне ключевых слов Module и EndModule, ассоциированная область User_Prm_Data относится ко всему устройству, а данные по сдвигу параметров - ко всем User_Prm_Data. Область User_Prm_Data должна быть в начале User_Prm_Data. Относящиеся к модулю данные User_Prm_Data прямо присоединены к относящимся к устройству данным User_Prm_Data в последовательности, в которой сконфигурированы ассоциированные модули. Если ключевые слова Ext_User_Prm_Data_Ref или Ext_User_Prm_Data_Const (X_Ext_User_Prm_Data_Ref или X_Ext_User_Prm_Data_Const / F_Ext_User_Prm_Data_Ref или F_Ext_User_Prm_Data_Const) используются в рамках ключевых слов Module и EndModule, данные по смещению параметра относятся только к началу области User_Prm_Data, которая присвоена данному модулю.

Используемые параметры:

Mod_Name:

Тип: Visible-String (32)

Значение: имя некоторого модуля, используемого в модульной станции DP, или имя устройства в компактном DP-slave.

Config:

Тип: Octet-String (17)

Тип: Octet-String (244) (О начинается с GSD_Revision 1)

Значение: здесь определены идентификатор или идентификаторы модуля модульного DP-slave, или compact DP.

Module_Reference: (О начинается с GSD__Revision 1,

М начинается с GSD__Revision 3)

Тип: Unsigned 16

Значение: здесь определена ссылка описания модуля. Эта ссылка должна быть уникальной для конкретного устройства (одинаковый Ident_Number). Такая ссылка полезна в целях создания возможности независимого от языка конфигурирования в зависящих от языка системах или для распознавания модулей.

Ext_Module_Prm_Data_Len: (О начинается с GSD_Revision 1)

Тип: Unsigned 8

Значение: здесь определена длина ассоциированных User_Prm_Data.

X_Ext_Module_Prm_Data_Len: (О начинается с GSD_Revision 4)

Тип: Unsigned 8 (1-244)

Значение: здесь определена длина ассоциированных User_Prm_Data для X_Prm_SAP.

F_Ext_Module_Prm_Data_Len: (О начинается с GSD_Revision 4)

Тип: Unsigned 8 (1-237)

Значение: здесь определена длина ExtUserPrmData для F-модуля.

Data_Area: (О начинается с GSD_Revision 5)

Значение: между ключевыми словами Data_Area_Beg и Data_Area_End определена область выходных данных модуля. Описание всегда начинается с первой области (слота) и повышается без промежутков.

Area_Name: (О начинается с GSD_Revision 5)

Тип: Visible-String (32)

Значение: имя описываемой области.

Данный параметр обязателен между Data_Area.

Related_CFG_Identifier: (О начинается с GSD_Revision 5)

Тип: Unsigned 8

Значение: индекс байта с идентификатором CFG начинается с 1, даже если существует только один идентификатор CFG.

Данный параметр обязателен между Data_Area.

Length: (О начинается с GSD_Revision 5)

Тип: Unsigned 8 (1-244)

Значение: длина Data_Area в байтах.

Данный параметр обязателен между Data_Area.

Consistency: (О начинается с GSD_Revision 5)

Тип: Unsigned 8

0: Совместимость только данных Data_Types в Data_Area

1: Совместимость всех Data_Area

Значение: требуется совместимость либо данного Data_Type или всей Data_Area. Идентификатор CFG должен иметь тот же уровень совместимости или на один уровень выше. Данный параметр обязателен между Data_Area.

Publisher_allowed: (О начинается с GSD_Revision 5)

Тип: Boolean (1: истинно)

Значение: сервер публикаций разрешен. Данный параметр обязателен между Data_Area.

DP_Master_allowed: (О начинается с GSD_Revision 5)

Тип: Boolean (1: истинно)

Значение: данный параметр обязателен между Data_Area.

Data_Type: (M внутри Data_Area, начинается с GSD_Revision 5)

Тип: Unsigned 8

Значение: устанавливает Data_Type. Эта величина соответствует спецификации стандартного типа данных в МЭК 61158-6. Возможны один или несколько типов данных, например U8 или Float (Idx. 5,8) в РА. Данный параметр обязателен между Data_Area.

Пример 5 - (Привод)

Пример 6 - (PROFIBUS РА устройство)

Channel_Diag: (О)

При ключевом слове Channel_Diag устанавливается присвоение указанных изготовителем типов ошибок (Error_Type) тексту (Diag_Text) в относящемся к каналу диагностическом поле.

Используемые параметры:

Error_Type:

Тип: Unsigned 8 (16 <= Error_Type <= 31)

Diag_Text:

Тип: Visible-String (32)

Channel_Diag_Help: (О начинается с GSD_Revision 5)

Здесь определена дополнительная информация об относящейся к каналу диагностике. Инструмент конфигурации может предлагать эту информацию пользователю дополнительно к соответствующему Diag_Text в Channel_Diag типу ошибки.

Используемые параметры:

Error_Type:

Тип: Unsigned 8 (16 <= Error_Type <= 31)

Help_Text:

Тип: Visible-String (256)

Fail_Safe: (D начинается с GSD_Revision 1)

Здесь определено, принимает или нет DP-slave сообщение с данными без данных вместо сообщения данных с данными, равными 0, в режиме CLEAR ведущего DP-master (класс 1).

Тип: Boolean (1: истинно)

Max_Diag_Data_Len: (M начинается с GSD_Revision 1)

Здесь установлена максимальная длина диагностической информации (Diag_Data).

Тип: Unsigned 8 (6-244)

Modul_Offset: (D начинается с GSD_Revision 1)

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

Тип: Unsigned 8

Slave_Family: (M начинается с GSD_Revision 1)

Здесь DP-slave присваивается функциональный класс. Имя семейства имеет иерархическую структуру. Кроме основного семейства могут быть созданы подсемейства, к которым соответственно добавлены "@". Могут быть определены максимум три подсемейства.

Пример 7 - Slave_Family=3@Digital@24V

Тип: Unsigned 8

Определены следующие основные семейства:

0: общее (не может быть присвоено категориям, представленным далее);

1: приводы;

2: переключающие устройства;

3: ввод/вывод;

4: вентили;

5: контроллеры;

6: HMI (интерфейс управления концентратором);

7: кодирующие устройства;

8: NC/RC (сетевые компьютеры/дистанционное управление);

9: межсетевой интерфейс;

10: программируемые логические контроллеры (PLC);

11: системы опознавания;

12: профиль PROFIBUS РА (независимый от используемого физического уровня);

13-255: зарезервировано.

Diag_Update_Delay: (D начинается с GSD_Revision 3)

Данный параметр используется для счета числа DDLM_Slave_Diag.con, в то время как все еще установлено Diag_Data.Prm_Req (для ведомых устройств с пониженными характеристиками). Значение Diag_Update_Delay относится к Min_Slave_lntervall of Slave.

Тип: Unsigned 8

Delay = Diag_Upd_Delay * Min_Slave_lntervall

Fail_Safe_required: (D начинается с GSD_Revision 3)

Данное ключевое слово соответствует ключевому слову Fail_Safe в GSD_Revision 1.

Данная информация отображена в бите "Fail_Safe" в DPV1_Status_1 сервиса DDLM_Set_Prm.

Комбинация Fail_Safe = 0 и Fail_Safe_required = 1 для устройства или какого-либо модуля невозможна.

Тип: Boolean (1: истинно)

Истинно: устройство или модуль требуют режим Fail_Safe для безопасной работы, что не является опциональным.

Ложно: использование режима Fail_Safe является опциональным.

Info_Text: (О начинается с GSD_Revision 3)

Здесь может быть описана дополнительная информация об устройстве или модуле. Инструмент конфигурации может предложить эту информацию пользователю дополнительно к видимой строке в Model_Name или Module.

Тип: Visible-String (256)

Max_User_Prm_Data_Len: (О начинается с GSD_Revision 1; M начинается с GSD_Revision 5)

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

Определение этого ключевого слова исключает оценку User_Prm_Data_Len и User_Prm_Data.

Тип: Unsigned 8 (0-237)

Ext_User_Prm_Data_Ref: (О начинается с GSD_Revision 1)

Здесь определена ссылка на описание данных параметризации пользователя. Определение этого ключевого слова исключает оценку User_Prm_Data и User_Prm_Data_Len. Если области перекрываются при описании данных параметризации, определенная последней область в файле GSD является приоритетной.

Используемые параметры:

Reference_Offset:

Тип: Unsigned 8

Значение: здесь определен сдвиг внутри ассоциированной части User_Prm_Data.

Reference_Number:

Тип: Unsigned 16

Значение: данный номер ссылки должен быть тем же самым, что и номер ссылки, определенный в описании User_Prm_Data.

Ext_User_Prm_Data_Const: (О начинается с GSD_Revision 1)

Здесь определена постоянная часть данных параметризации пользователя. Определение этого ключевого слова исключает оценку User_Prm_Data и User_Prm_Data_Len. Если области перекрываются при описании данных параметризации, определенная последней область в файле GSD является приоритетной.

Используемые параметры:

Const_Offset:

Тип: Unsigned 8

Значение: здесь определен сдвиг внутри ассоциированной части данных параметризации.

Const_Prm_Data:

Тип: Oktet-String

Значение: здесь определены константы или выбранные по умолчанию величины в данных параметризации.

ExtUserPrmData: (О начинается с GSD_Revision 1)

Между ключевыми словами ExtUserPrmData и EndExtUserPrmData описан параметр данных параметризации пользователя. Определение этого ключевого слова исключает оценку User_Prm_Data.

Используемые параметры:

Reference_Number:

Тип: Unsigned 16

Значение: здесь определена ссылка описания данных параметризации. Ссылка должна быть уникальной.

Ext_User_Prm_Data_Name:

Тип: Visible-String (32) или "[SlotNumber]"

Значение: ясное текстовое описание параметров. Здесь номер слота может быть введен автоматически.

[SlotNumber]: (О начинается с GSD_Revision 5)

Если Visible-String Ext_User_Prm_Data_Name - "[SlotNumber]", фактический номер слота будет введен автоматически инструментом конфигурации.

Пример 8 -

ExtUserPrmData =17 "[SlotNumber]"

Unsigned 8 1 1-11

EndExtUserPrmData

Data_Type_Name:

Тип: Visible-String (32)

Значение: значение по умолчанию описываемого параметра.

Default_Value:

Тип: Data_Type (должен соответствовать Data_Type_Name)

Значение: значение по умолчанию описываемого параметра.

Min_Value:

Тип: Data_Type (должен соответствовать Data_Type_Name)

Значение: минимальное значение описываемого параметра.

Max_Value:

Тип: Data_Type (должен соответствовать Data_Type_Name)

Значение: максимальное значение описываемого параметра.

Allowed_Values:

Тип: Data_Type_Array (16) (должен соответствовать Data_Type_Name)

Значение: допустимые значения описываемого параметра.

Prm_Text_Ref:

Тип: Unsigned 16

Значение: данный номер ссылки должен быть таким же, как номер ссылки, определенный в описании PrmText.

Изменяемый: (О начинается с GSD_Revision 4).

Тип: Boolean (1: истинно, по умолчанию равно 1)

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

Видимый: (О начинается с GSD_Revision 4).

Тип: Boolean (1: истинно, по умолчанию равно 1)

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

PrmText:

Между ключевыми словами PrmText и EndPrmText описаны возможные значения параметров. Этим значениям также присвоены тексты.

Используемые параметры:

Reference_Number:

Тип: Unsigned 16

Значение: здесь определена ссылка на описание PrmText. Эта ссылка должна быть уникальной.

Text_ltem:

Используемые параметры:

Prm_Data_Type:

Тип: Data_Type (должен соответствовать Data_Type_Name в описании параметра).

Значение: здесь определено значение параметра, который должен быть описан.

Text:

Тип: Visible-String (32)

Значение: описание значения параметра.

Prm_Block_Structure_supp: (О начинается с GSD_Revision 4)

Здесь ведомое устройство показывает, что структура блока расширенной параметризации поддерживается в рамках данных параметризации пользователя. Если Prm_Block_Structure_supp = 1, данные параметризации должны быть структурированы. Бит Prm_Structure (DPV1_Status_3) будет установлен инструментом конфигурации.

Если Prm_Block_Structure_supp = 0, данные параметризации не должны быть структурированы, но могут показывать форму Block-Structure. Бит Prm_Structure не будет установлен инструментом конфигурации.

- Prm_Structure необходим для следующих блоков:

PrmCmd(Structure_Type=2), DXB-Linktable(3), IsoM-Parameter(4), DXB-Subscribertable(7), Time AR Parameter(8), зависящие от изготовителя блоки (З2...128).

- Следующие блоки не должны быть определены в файле GSD: PrmCmd(Structure_Type=2), DXB-Linktable(3), IsoM-Parameter(4), DXB-Subscribertable(7), Time AR Parameter(8).

Для этих блоков инструмент конфигурации автоматически вставит соответствующий Prm_Block в послание с данными параметризации с учетом ключевых слов и установок инструментов после фиксированных блоков. Первый фиксированный блок содержит 3 DPV1-Status-Bytes.

- F_Parameter-Block(5) является фиксированным блоком и должен быть описан относящимися к ведомому устройству ключевыми словами для PROFIsafe Profile.

- User_Prm_Data(129) и установленные изготовителем блоки (32...128) должны быть описаны в (X_)Ext_User_Prm_Dat_Ref или в (X_)Ext_User_Prm_Dat_Const. Эти блоки должны быть фиксированными и определенными в файле GSD. Фиксированные блоки будут вставляться всегда в начале данных параметризации.

Истинно, если DPV1_Slave = 1.

Тип: Boolean (1: истинно)

Prm_Block_Structure_req: (О начинается с GSD_Revision 4)

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

Тип: Boolean (1: истинно)

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

Ложно: использование Prm_Block_Structure является опциональным.

Jokerblock_supp: (О начинается с GSD_Revision 5)

Показывает, поддерживает или нет ведомый DP Jokerblock в соответствии с блочной структурой расширенной параметризации в UserPrmData. Должны выполняться следующие правила:

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

- длина Jokerblock - 255;

- Jokerblock не должен быть использован для PrmCmd, DXB-Linktable, IsoM_Parameter, DXB-Subscribertable, Time AR parameter, F_Parameter;

- Jokerblock может быть послан на любой слот;

- Jokerblock может быть использован также в X_Prm_SAP как последний блок послания с данными расширенной параметризации.

Тип: Boolean (1: истинно)

Jokerblock_Type: (О начинается с GSD_Revision 5)

Между параметром Jokerblock_Type и End_Jokerblock_Type будет описан каждый единичный блок данных параметризации в Jokerblock.

Этот параметр показывает, что Structure_Type описан внутри блока. Обязателен, если Jokerblock_supp = 1.

Тип: Unsigned 8

0-31: зарезервировано

32-128: данные изготовителя

129: User_Prm_Data

130-255: зарезервировано

Jokerblock_Slot: (О начинается с GSD_Revision 5)

Этот параметр показывает ссылочный Slot_Number. Обязателен, если Jokerblock_supp = 1.

Тип: Unsigned 8

Jokerblock_Location: (D начинается с GSD_Revision 5)

Этот параметр показывает, какой тип SAP поддерживается в Jokerblock.

Тип: Unsigned 8

0: Prm-Telegram

1: Prm-Telegram или Ext-Prm-Telegram; допускается в том случае, если X_Prm_SAP_supp = 1.

2: Ext-Prm-Telegram; допускается в том случае, если X_Prm_SAP_supp = 1.

PrmCmd_supp: (О начинается с GSD_Revision 5)

Показывает, поддерживает или нет DP-ведомый PrmCmd.

Тип: Boolean (1: истинно)

Max_Switch_Over_Time: (О начинается с GSD_Revision 5)

Время, необходимое для DP-Slave от получения PrmCmd до обновления диагностики с помощью расчетного Red_State.

Тип: Unsigned 16

Масштаб по оси времени: 100 мс.

Slave_Redundancy_supp: (О начинается с GSD_Revision 5)

Показывает, поддерживает или нет DP-Slave избыточность ведомого устройства согласно [11].

Тип: Unsigned 8

0: не поддерживается

1-7: зарезервировано

8: версия 1.0 избыточности DP-Slave

9-255: зарезервировано

Ident_Maintenance_supp: (О начинается с GSD_Revision 5)

Устройство или модуль поддерживают функции идентификации и технического обслуживания согласно [16].

Тип: Boolean (1: истинно)

Time_Sync_supp: (О начинается с GSD_Revision 5)

Устройство поддерживает синхронизацию часов согласно МЭК 61784-1:2003, 7.2.3.2.5.10, где имеется ссылка на МЭК 61158-5:2003, 8.2.9 Time ASE и оттуда - на МЭК 61158-3:2003, 14.4.5 и др.

Тип: Boolean (1: истинно)

В.5.4.2 Дополнительные ключевые слова для назначения модуля

SlotDefinition: (О только если Modular_Station, начинается с GSD_Revision 3)

Между ключевыми SlotDefinition и EndSlotDefinition описаны возможности использования модулей в слотах. Ссылки на модули содержатся в Module_Reference. Имена слотов обязательны. Модуль по умолчанию должен быть интегрирован в конфигурацию автоматически (послание). Этот модуль может быть заменен одним из разрешенных модулей из списка.

Модули могут быть учтены, используя допустимые значения (8, 9, 13...) или используя полный диапазон (17-22).

Slot: (О начинается с GSD_Revision 3)

Значение: этот параметр устанавливает модули, которые могут быть использованы в указанном слоте.

Slot_Number:

Тип: Unsigned 8

Значение: здесь определен номер слота в устройстве. Этот номер слота должен начинаться с 1 и увеличиваться без пропусков. Если используется SlotDefinition, то настоятельно рекомендуется, чтобы Modul_Offset также был равен 1. Не каждый слот устройства должен быть описан в этом определении слота. Дополнительные модули могут появиться после наибольшего определенного Slot_Number.

Slot_Name:

Тип: Visible-String (32)

Значение: текстовое описание слота (означает применение имени функции).

Default_Value:

Тип: Unsigned 16

Значение: значение по умолчанию Module_Reference модуля, использованного в данном слоте.

Min_Value:

Тип: Unsigned 16

Значение: минимальная величина Module_Reference среди модулей, которые могут быть использованы в данном слоте.

Max_Value:

Тип: Unsigned 16

Значение: максимальная величина Module_Reference среди модулей, которые могут быть использованы в данном слоте.

Allowed_Values:

Тип: Data_Type_Array (256) из Unsigned 16

Значение: допустимые значения, список Module_Reference модулей, которые могут быть использованы в данном слоте.

В.5.4.3 Ключевые слова для расширений DP, относящиеся к ведомому устройству

Расширения PROFIBUS обозначают характеристики DP-V1 (см. МЭК 61784-1:2003 A3.1) и список опций (см. МЭК 61784-1:2003 А3.1 и 7.2.3.2.5) по сравнению с DP-V0.

Таблица В.3 иллюстрирует зависимость ключевых слов GSD от расширений PROFIBUS DP. Некоторые ключевые слова становятся действительными, только когда другие ключевые слова (основные селекторы протокольных функций DP-V1) установлены как истинные. Правая колонка таблицы - возникающие в результате характеризации и поведения устройства, описанные в определениях GSD в двух левых колонках.

В этом описании GSD - ациклический канал между ведущим устройством класса 1 и ведомым устройством имеет имя MS1, а между ведущим устройством класса 2 и ведомым устройством имеет имя MS2.

Примечание - Соответствующие имена в предыдущих документах - MSAC_C1 и MSAC_C2.

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

Таблица В.3 - Ключевые слова GSD

DPV1_Slave (D начинается с GSD_Revision 3)

Истинно, если устройство использует функциональные характеристики DP-V1. Данное ключевое слово является расширением "Station_Type" и показывает что, ведомое устройство действует как стандартное DP или DP-Slave с расширенными функциональными характеристиками.

Поддержка нескольких типов функциональных характеристик DP-V1 определяется следующими относящимися к функциям ключевыми словами.

Тип: Boolean (1: истинно)

C1_Read_Write_supp (D начинается с GSD_Revision 3)

DP-Slave или Slave Module с расширенными функциональными характеристиками поддерживают сервисы Read и Write в коммуникационных связях С1.

Тип: Boolean (1: истинно)

C2_Read_Write_supp (D начинается с GSD_Revision 3)

DP-Slave с расширенными функциональными характеристиками поддерживает сервисы Read и Write в коммуникационных связях С2.

Тип: Boolean (1: истинно)

C1_Max_Data_Len: (D начинается с GSD_Revision 3)

Данный параметр определяет максимальную длину данных пользователя за исключением Function_Num, Slot_Number, Index, Length, передаваемых по каналу коммуникаций MSAC_1. Этот параметр обязателен, если C1_read_write_supp = 1.

Тип: Unsigned 8 (0-240)

C2_Max_Data_Len: (D начинается с GSD_Revision 3)

Данный параметр определяет максимальную длину данных пользователя за исключением Function_Num, Slot_Number, Index, Length, передаваемых по коммуникационному каналу MSAC_2. Этот параметр обязателен, если C2_read_write_supp = 1.

Тип: Unsigned 8 (0,48-240)

C1_Response_Timeout: (О начинается с GSD_Revision 3)

Параметр C1_Response_Timeout представляет эффективность DP-Slave с расширенными функциональными характеристиками. Каждый DP-Slave с расширенными функциональными характеристиками должен гарантировать, что параметр C1_Response_Timeout достигает наименьшего возможного значения. С помощью этого параметра DP-Slave с расширенными функциональными характеристиками показывает максимальное время обработки ациклического сервиса (read, write, alarm_ack) в C1 - коммуникационной связи. Этот параметр обязателен, если C1_read_write_supp = 1.

Тип: Unsigned 16 (1-65535)

Масштаб по оси времени: 10 мс.

C2_Response_Timeout: (О начинается с GSD_Revision 3)

Параметр C2_Response_Timeout представляет эффективность DP-Slave с расширенными функциональными характеристиками. Каждый DP-Slave с расширенными функциональными характеристиками должен гарантировать, что параметр C2_Response_Timeout достигает наименьшего возможного значения. С помощью этого параметра DP-Slave с расширенными функциональными характеристиками показывает максимальное время обработки ациклического сервиса (read, write, Data_Transport) в коммуникационной связи С2. Этот параметр обязателен, если C2_read_write_supp = 1.

Тип: Unsigned 16 (1-65535)

Масштаб по оси времени: 10 мс.

C1_Read_Write_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступ к сервисам C1_Read_Write.

Тип: Boolean (1: истинно)

C2_Read_Write_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступ к сервисам C2_Read_Write.

Тип: Boolean (1: истинно)

C2_Max_Count_Channels: (D начинается с GSD_Revision 3)

Данный параметр определяет максимальное количество активных каналов С2 для DP-V1 Slave. Этот параметр обязателен, если C2_read_write_supp = 1.

Тип: Unsigned 8 (0-49)

Max_Initiate_PDU_Length: (D начинается с GSD_Revision 3)

Данный параметр определяет максимальную длину Initiate Request PDU, включая Function_Num для Resource Manager. Этот параметр обязателен, если C2_read_write_supp = 1.

Тип: Unsigned 8 (0,52-244)

Diagnostic_Alarm_supp (D начинается с GSD_Revision 3)

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

Тип: Boolean (1: истинно)

Process_Alarm_supp (D начинается с GSD_Revision 3)

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

Тип: Boolean (1: истинно)

Pull_Plug_Alarm_supp (D начинается с GSD_Revision 3)

Устройство поддерживает Pull_Plug_Alarm, сигнализирующий об удалении модуля из слота.

Тип: Boolean (1: истинно)

Status_Alarm_supp (D начинается с GSD_Revision 3)

Устройство поддерживает Status_Alarm, сигнализирующий об изменении состояния модуля, например работе, остановке или готовности.

Тип: Boolean (1: истинно)

Update_Alarm_supp: (D начинается с GSD_Revision 3)

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

Тип: Boolean (1: истинно)

Manufacturer_Specific_Alarm_supp: (D начинается с GSD_Revision 3)

Устройство поддерживает Manufacturer_Specific_Alarm, сигнализирующий о событии, инициированном изготовителем.

Тип: Boolean (1: истинно)

Extra_Alarm_SAP_supp (D начинается с GSD_Revision 3)

Дополнительно к SAP51 возможна обработка MSAL_Alarm_Ack через SAP 50, если бит Sl_Flag.Extra_Alarm_SAP в соответствующем наборе параметров ведомого устройства установлен. В этом случае могут демонстрироваться более высокие характеристики, так как SAP 50 используется исключительно для сервиса MSAL_Alarm_Ack и этот сервис не может тормозиться вследствие работы сервиса MSAC1_Write или MSAC1_Read.

Тип: Boolean (1: истинно)

Alarm_Sequence_Mode_Count: (D начинается с GSD_Revision 3)

DP-Slave поддерживает Alarm_Sequence_Mode для обработки сигналов тревоги, когда этот параметр не равен 0. Если этот параметр установлен на 0, только Type Mode поддерживается ведомым устройством.

Sequence Mode является опцией параллельной обработки сигналов тревоги.

Несколько сигналов тревоги (от 2 до 32) одинаковых или различных типов могут быть активными (нераспознанными) одновременно (фиксируется сервисом DDLM_Set_Prm) на DP-V1.

Тип: Unsigned 8 (0, 2-32)

Alarm_Type_Mode_supp: (D начинается с GSD_Revision 3;

М, если DP-Slave поддерживает сигналы тревоги, начинается с GSD_Revision 4)

DP-Slave поддерживает Type Mode при обработке сигналов тревоги. Type Mode обязателен, если DP-Slave поддерживает сигналы тревоги. Только один сигнал тревоги специального Alarm_Type может быть активен единовременно (это фиксируется сервисом DDLM_Set_Prm).

Тип: Boolean (должен всегда быть установлен на 1: истинно)

Diagnostic_Alarm_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступа к обработке сигналов тревоги.

Тип: Boolean (1: истинно)

Process_Alarm_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступа к обработке сигналов тревоги.

Тип: Boolean (1: истинно)

Pull_Plug_Alarm_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступа к обработке сигналов тревоги.

Тип: Boolean (1: истинно)

Status_Alarm_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступа к обработке сигналов тревоги.

Тип: Boolean (1: истинно)

Update_Alarm_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступа к обработке сигналов тревоги.

Тип: Boolean (1: истинно)

Manufacturer_Specific_Alarm_required: (D начинается с GSD_Revision 3)

DP-Slave или Slave Module требуют доступа к обработке сигналов тревоги.

Тип: Boolean (1: истинно)

DPV1_Data_Types: (О начинается с GSD_Revision 3)

DP-Slave использует специальные данные поставщика по расширенному формату идентификатора для всех модулей с расширенным форматом идентификатора для кодировки типов данных.

Тип: Boolean (1: истинно)

WD_Base_1ms_supp: (D начинается с GSD_Revision 3)

DP-Slave поддерживает масштаб оси времени 1 мс для схемы обеспечения безопасности.

Тип: Boolean (1: истинно)

Check_Cfg_Mode: (D начинается с GSD_Revision 3)

С помощью этого параметра ведомое устройство предоставляет различным пользователям специальные способы проверки Cfg-Data. Этот режим включается с помощью "Check_Cfg_Mode" в DPV1_Status_2 в данных Prm.

Тип: Boolean (1: истинно)

В.5.4.4 Ключевые слова для Data Exchange с Broadcast

Publisher_supp: (D начинается с GSD_Revision 3)

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

Тип: Boolean (1: истинно)

Subscriber_supp: (D начинается с GSD_Revision 4)

DP-Slave поддерживает функциональные характеристики абонента по обмену данными с многоадресной передачей (Subscriber), если Subscriber_supp=1, DPV1_Slave должно быть 1.

Тип: Boolean (1: истинно)

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

DXB_Max_Link_Count: (О начинается с GSD_Revision 4)

Максимальное число поддерживаемых связей с различными серверами публикаций должно быть не равно 0, если Subscriber_supp = 1.

Тип: Unsigned 8 (0-125)

DXB_Max_Data_Length: (О начинается с GSD_Revision 4)

Максимальная длина данных (в одном отрезке) для поддерживаемых связей с одним сервером публикаций должно быть не равно 0, если Subscriber_supp = 1.

Тип: Unsigned 8 (1-244)

DXB-Subscribertable_Block_Location: (D начинается с GSD_Revision 5)

Данный параметр показывает, какой тип SAP поддерживается с помощью DXB-Subscribertable.

Тип: Unsigned 8

0: Prm-Telegram

1: Prm-Telegram или Ext-Prm-Telegram.

Разрешается, только если X_Prm_SAP_supp = 1

2: Ext-Prm-Telegram.

Разрешается, только если X_Prm_SAP_supp = 1

Пример -

; Slave related keywords for DXB - Start

Publisher_supp = 1;

Subscriber_supp = 1;

DXB_Max_Link_Count = 10;

DXB_Max_Data_Length = 32;

; Slave related keywords for DXB - End

В.5.4.5 Ключевые слова для режима Isochronous Mode, относящиеся к ведомому устройству Isochron_Mode_supp: (D начинается с GSD_Revision 4)

Этот параметр показывает, поддерживает или нет ведомое устройство режим Isochron_Mode. Если этот параметр установлен на FALSE, все другие изохронные параметры не имеют значения.

Тип: Boolean (1: истинно)

Isochron_Mode_required: (D начинается с GSD_Revision 4)

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

Тип: Boolean (1: истинно)

TBASE_DP: (О начинается с GSD_Revision 4)

Масштаб по оси времени , время цикла DP, TDP_MIN и TDP_MAX, в единицах 1/12 мкс. Должна быть заявлена наименьшая величина. Этот параметр обязателен, если Isochron_Mode_supp = 1.

Тип: Unsigned 32 (допустимые значения - 375; 750; 1500; 3000; 6000; 12000, что соответствует 31,25; 62,5; 125; 250; 500; 1000 мкс)

Примечание 1 - Инструмент конфигурации будет рассчитывать наименьшие общие значения для TDP, TI и ТО для всех соответствующих ведомых устройств на шине.

TDP_MIN: (О начинается с GSD_Revision 4)

Минимальное значение , времени цикла DP на основании TBASE_DP. Значения этого параметра для более высоких величин масштаба по времени должны быть рассчитаны исходя из этой величины. Этот параметр обязателен, если Isochron_Mode_supp = 1.

Тип: Unsigned 16, в диапазоне от 1 до 2 - 1

TDP_MAX: (О начинается с GSD_Revision 4)

Максимальное значение времени цикла DP, поддерживаемое устройством DP в режиме Isochron mode, исходя из TBASE_DP. Значения этого параметра для увеличенных значений масштаба времени должны быть рассчитаны исходя из этого значения. TDP_MAX не должно превышать диапазон 32 мс. Этот параметр обязателен, если Isochron_Mode_supp = 1.

Тип: Unsigned 16, в диапазоне от 1 до 2 - 1

T_PLL_W_MAX: (О начинается с GSD_Revision 4)

Максимальная величина отклонения, приемлемая на входе устройства (RS485 приемник), исходя из 1/12 мкс. Этот параметр обязателен, если Isochron_Mode_supp = 1.

Тип: Unsigned 16, в диапазоне от 12 до 2 - 1

TBASE_IO: (О начинается с GSD_Revision 4)

Масштаб времени и , где представляет собой момент времени, когда входные величины собираются, а - момент времени, когда входные величины принимаются. Разрешенные значения масштаба времени равны определениям для TBASE_DP (см. выше). Наименьшее значение должно быть декларировано. Этот параметр обязателен, если Isochron_Mode_supp = 1.

Тип: Unsigned 32

TI_MIN: (О начинается с GSD_Revision 4)

Минимальное значение исходя из масштаба времени в TBASE_IO, которое необходимо для получения и обновления входных величин в отдельном DP-Slave. Значения этого параметра для увеличенных масштабов времени и должны быть рассчитаны исходя из этого значения. Этот параметр обязателен, если Isochron_Mode_supp = 1.

Тип: Unsigned 16, в диапазоне от 0 (специальный случай), 1 до 2 - 1

Примечание 2 - Значения TI_MIN = ТО_MIN = 0 должны привести к установке в ведущем устройстве значений TI = ТО = 0. При значениях TI = ТО = 0 "простой режим" ведомого устройства PROFIdrive регулируется согласно [15] V3.1.

TO_MIN: (О начинается с GSD_Revision 4)

Минимальное значение исходя из масштаба времени в TBASE_IO необходимо в конце циклической части цикла Isochron DP () для получения и вывода выходных величин, данных в единицах TBASE_IO отдельного DP-Slave. Значения этого параметра для увеличенных масштабов времени и должны быть рассчитаны исходя из этого значения. Этот параметр обязателен, если Isochron_Mode_supp = 1.

Тип: Unsigned 16

Пример -

Данный пример означает, что устройство поддерживает режим Isochron_Mode и может работать под управлением любого ведущего устройства независимо от того, поддерживает оно режим Isochron_Mode или нет. Кроме того, масштаб времени как для времени цикла DP, так и для значений TI/TO равен 1500, что соответствует 125 мкс. Следовательно, минимальное время цикла DP, необходимое для 3 Мбит/с, равно 16125 мкс, что равно 2 мс, для 6 Мбит/с равно 8125 мкс, что равно 1 мс, а максимальное время цикла, поддерживаемое устройством, равно 256125 мс, что равно 32 мс, TI и ТО могут быть рассчитаны исходя из 125 мкс каждый (ТО на 125 мс больше чем TDX), максимальная величина дрожания равна 121/12 мкс, что равно 1 мкс.

В.5.4.6 Ключевые слова для профиля PROFIsafe, относящиеся к ведомому устройству

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

Примечание - Дальнейшая информация по PROFIsafe содержится в [13].

F_ParamDescCRC (О начинается с GSD_Revision 4)

В целях безопасного прочтения описания параметров PROFIsafe в файле GSD необходимы 2 байта кода CRC. Код CRC должен быть рассчитан в соответствии с руководствами по PROFIsafe и сертифицирован органами регистрации (например, TUEV). Значение этого параметра не будет передано в ведомое устройство, но необходимо для исключения ошибок во время параметризации с помощью инструмента конфигурации.

Тип: Unsigned 16

F_Ext_User_Prm_Data_Ref: (О начинается с GSD_Revision 4)

Здесь определена ссылка на описание User_Prm_Data. Определение этого ключевого слова исключает оценку User_Prm_Data. Если при описании ExtUserPrmData области перекрываются, приоритет имеет область, определенная последней в блоке описания устройства.

Использованные параметры:

Reference_Offset:

Тип: Unsigned 8

Значение: здесь определено смещение внутри ассоциированной части ExtUserPrmData.

Reference_Number:

Тип: Unsigned 16

Значение: этот ссылочный номер должен быть тем же самым, что и ссылочный номер, определенный в описании ExtUserPrmData.

F_Ext_User_Prm_Data_Const: (О начинается с GSD_Revision 4)

Здесь определена постоянная часть ExtUserPrmData. Определение этого ключевого слова исключает оценку User_Prm_Data. Если при описании ExtUserPrmData области перекрываются, приоритет имеет область, определенная последней в файле GSD.

Использованные параметры:

Const_Offset:

Тип: Unsigned 8

Значение: здесь определено смещение внутри ассоциированной части UserPrmData.

Const_Prm_Data:

Тип: Octet-String

Значение: здесь определены константы или выбранные по умолчанию величины в ExtUserPrmData.

В.5.4.7 Ключевые слова для расширенной параметризации, относящиеся к ведомому устройству

X_Prm_SAP_supp: (D начинается с GSD_Revision 4)

Показывает, поддерживается или нет X_Prm_SAP ведомым устройством. Должно быть истинно, если DPV1_Slave = 1.

Тип: Boolean (1: истинно)

X_Max_User_Prm_Data_Len: (О начинается с GSD_Revision 4)

Здесь определена максимальная длина ExtUserPrmData. Использование этого ключевого слова разрешается, только если DPV1_Slave = 1 и если X_Prm_SAP_supp = 1. Обязательно, если X_Prm_SAP_supp = 1.

Тип: Unsigned 8 (5-244)

X_Max_Sum_Prm_Data_Len: (О начинается с GSD_Revision 5)

Здесь определено наибольшее значение суммы длин UserPrmData и ExtUserPrmData в байтах.

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

Тип: Unsigned 16 (0, 5-481)

X_Ext_Module_Prm_Data_Len: (О начинается с GSD_Revision 4)

Здесь определена длина ассоциированных данных ExtUserPrmData.

Использование этого ключевого слова разрешается, только если DPV1_Slave = 1 если X_Prm_SAP_supp = 1.

Тип: Unsigned 8 (1-244)

X_Ext_User_Prm_Data_Ref: (О начинается с GSD_Revision 4)

Здесь определена ссылка на описание ExtUserPrmData. Если области перекрываются при описании ExtUserPrmData, приоритет имеет область, определенная последней в файле GSD.

Использованные параметры:

Reference_Offset:

Тип: Unsigned 8

Значение: здесь определено смещение внутри ассоциированной части ExtUserPrmData.

Reference_Number:

Тип: Unsigned 16

Значение: этот ссылочный номер должен быть таким же, как ссылочный номер, определенный в описании ExtUserPrmData.

X_Ext_User_Prm_Data_Const: (О начинается с GSD_Revision 4)

Здесь определена постоянная часть ExtUserPrmData. Если области перекрываются при описании ExtUserPrmData, приоритет имеет область, определенная последней в файле GSD.

Использованные параметры:

Const_Offset:

Тип: Unsigned 8

Значение: здесь определено смещение внутри ассоциированной части ExtUserPrmData.

Const_Prm_Data:

Тип: Octet-String

Значение: здесь определены константы или выбранные по умолчанию величины в ExtUserPrmData.

X_Prm_Block_Structure_supp: (О начинается с GSD_Revision 4)

Ведомое устройство представляет, что структура блока расширенной параметризации поддерживается при использовании X_Prm_Service.

Должно быть истинно, если DPV1_Slave = 1.

Должно быть истинно, если X_Prm_SAP_supp = 1.

Тип: Boolean (1: истинно)

В.5.4.8 Ключевые слова для подсистем, относящиеся к ведомому устройству

Ведомое устройство PROFIBUS DP, которое имеет шлюз интерфейса с коммуникационной системой, называемой также подсистемой, может предоставить директорию, содержащую индексы DP внутренних буферов, представляющих адресуемые объекты Process Data. Пользователю необходима информация, где найти эту директорию в целях получения доступа к буферам данных, представляющим коммуникационную систему. Изготовитель устройства может предоставить одну директорию в слоте 0 (это имеет смысл для компактного ведомого устройства) или одну директорию на каждом слоте в случае модульного ведомого устройства.

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

Subsys_Dir_lndex: (О начинается с GSD_Revision 4)

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

Тип индекса: Unsigned 8

Тип подсистемы: Unsigned 8, значения соответствуют следующему:

1: характеристики шлюза соответствуют [13];

0, 2-127: зарезервировано;

128-255: зависит от пользователя.

Пример 1 -

Subsys_Dir_Index (1) = 15

Это означает, что устройство является шлюзом с ведущим устройством подсистемы согласно [13], где директория объекта - ведущее устройство подсистемы - может быть найдена в слоте 0 с индексом 15.

Subsys_Module_Dir_lndex: (О начинается с GSD_Revision 4)

Данное устройство имеет шлюз интерфейса с подсистемой. Индекс директории объектов подсистемы зависит от модуля и определяется этой величиной. Слот соответствует модулю.

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

Тип индекса: Unsigned 8

Тип подсистемы: Unsigned 8, значения соответствуют следующему:

1: характеристики шлюза соответствуют [13];

0, 2-127: зарезервировано;

128-255: зависит от пользователя.

Пример 2 -

Subsys_Module_Dir_Index (1) = 42

Это означает, что устройство является шлюзом с ведущим устройством подсистемы согласно [13]. Директория объекта - ведущее устройство подсистемы для модуля, в котором это определение появляется - может быть найдена в соответствующем слоте под индексом 42.

В.6 Формальное описание GSD

Таблица В.4 содержит формальное определение GSD. Все данные в скобках являются опциональными. Символ "|" означает логическую операцию "или". Номер перед каждым правилом является последовательным (S#), устанавливающим ссылку на правила.

Таблица В.4 - Формальное описание формата GSD

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

Шаблоны профиля P-NET

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

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

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

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

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

Шаблоны профиля WorldFIP

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

D.1.1 Обзор

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

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

Таблица D.1 - Основные характеристики классов соответствия устройств

D.1.2 DeviceConformityClass

D.1.2.1 Класс соответствия устройств 1, устройства plug and play

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

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

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

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

PhysicalNode

Устройство, относящееся к этим классам, должно иметь PhysicalNode, использующий SM_MPS со следующими характеристиками:

- параметр Presence Variable, для которого значение идентификатора WorldFIP равно 14XXh (XXh - адрес устройства);

- параметр Simple Identification Variable, для которого значение идентификатора WorldFIP равно 10XXh (XXh - адрес устройства).

LogicalNode

Устройство, относящееся к этим классам, должно иметь LogicalNode, единственно возможное состояние которого IN SERVICE.

FunctionBlock

Устройство, относящееся к этим классам, должно иметь FunctionBlock со следующими характеристиками:

- два видимых состояния сети: IN SERVICE (рабочее состояние), NOT IN SERVICE (нерабочее состояние);

- один используемый параметр контроля/конфигурации, для которого значение идентификатора WorldFIP DLL равно 03XXh (XXh - адрес устройства);

- один параметр приложения, для которого значение идентификатора WorldFIP DLL равно 05XXh (XXh - адрес устройства);

- один параметр создаваемого приложения, для которого значение идентификатора WorldFIP DLL равно 06XXh (XXh - адрес устройства).

ExchangeBlock

Устройство, относящееся к этим классам, не должно иметь ExchangeBlock.

D.1.2.2 Класс соответствия устройств 2, конфигурируемые и контролируемые простые устройства

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

Устройства класса соответствия 2 должны использовать коммуникационную сеть с классом соответствия 2.

PhysicalNode

Устройство, относящееся к этому классу, должно иметь PhysicalNode, использующий SM_MPS со следующими параметрами:

- параметр Presence Variable, для которого значение идентификатора WorldFIP DLL равно 14XXh (XXh - адрес устройства);

- параметр Identification Variable, для которого значение идентификатора WorldFIP DLL равно 10XXh (XXh - адрес устройства);

- параметр Report Variable, для которого значение идентификатора WorldFIP DLL равно 11XXh (XXh - адрес устройства);

- параметр Global Control Variable, для которого значение идентификатора WorldFIP DLL равно 12XXh (XXh - адрес устройства);

- параметр Configuration Unloading Variable, для которого значение идентификатора WorldFIP DLL равно 21XXh (XXh - адрес устройства);

- другие опциональные (переменные) параметры SM_MPS.

LogicalNode

Устройство, относящееся к этому классу, должно иметь от одного до восьми LogicalNode. Видимые состояния сети для LogicalNode - , и . Эти состояния являются подсостояниями блоков состояний общих правил интероперабельности Existent, Uncomplete Assignment и Complete Assignment соответственно. Состояния , , и не используются.

FunctionBlock

Устройство, относящееся к этому классу, должно иметь один или более FunctionBlock. Каждый FunctionBlock может иметь следующие характеристики:

- все параметры интерфейса доступны при использовании MPS или Micro-MMS, применяющих индекс;

- один потребляемый параметр контроля процесса приложения, для которого значение идентификатора WorldFIP DLL равно 05XXh (XXh - адрес устройства);

- один параметр статуса процесса создаваемого приложения, для которого значение идентификатора WorldFIP DLL равно 06XXh (XXh - адрес устройства);

- шесть параметров управления приложением и дополнительных параметров приложения.

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

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

ExchangeBlock

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

D.1.2.3 Класс соответствия устройств 3, конфигурируемые и контролируемые устройства

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

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

PhysicalNode

Устройство, относящееся к этому классу, должно иметь PhysicalNode, использующий SM_MPS со следующими характеристиками:

- параметр Presence Variable, для которого значение идентификатора WorldFIP DLL равно 14XXh (XXh - адрес устройства);

- параметр Identification Variable, значение идентификатора WorldFIP которого равно 10XXh (XXh - адрес устройства);

- параметр Report Variable, для которого значение идентификатора WorldFIP DLL равно 11XXh (XXh - адрес устройства).

LogicalNode

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

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

D.1.2.4 Класс соответствия устройств 4, сложные устройства

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

D.1.3 XML-схема шаблона профиля устройства

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

D.2.1 Обзор

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

Три класса соответствия коммуникационной сети используются для вывода классов соответствия MPS, MMS и Data Link Layer и наличия компонент MCS.

D.2.2 Прикладные уровни

D.2.2.1 Профили коммуникаций MPS

D.2.2.1.1 TypeConstructor

Primitive types, используемые для Simple, должны быть следующими: Boolean, Bit string, Integer, Unsigned, Octet string, Visible string, Generalised time, Floating point, Binary time, BCD.

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

Explicit типы конструкций допускают представление ассоциированных переменных с явным синтаксисом перехода в целях предоставления семантики типа с данными.

Predefined и explicit типы конструкций не могут быть использованы для формирования типов array и structure.

D.2.2.1.2 MPSConformityClass

В таблице D.2 представлены классы соответствия WorldFIP MPS. Класс 3 разделен на два подкласса 3.1 и 3.2. Номер класса соответствия MPS должен быть выведен из числа в атрибуте CommunicationNetworkConformityClass.

Таблица D.2 - Классы соответствия WorldFIP MPS

D.2.2.2 Профили коммуникаций MCS

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

D.2.2.3 Профили коммуникаций MMS

D.2.2.3.1 Определения Micro-MMS

Должны быть определены две подгруппы сервисов MMS.

Micro-MMS V1 представляет собой имя, присвоенное классу минимального соответствия SubMMS. Он должен включать сервисы трех переменных объектов: Read, Write и Information Report.

В таблице D.3 представлены сервисы переменного объекта WorldFIP Micro-MMS.

Таблица D.3 - Сервисы переменного объекта WorldFIP Micro-MMS V1

В таблице D.4 представлены сервисы объекта WorldFIP Micro-MMS V2.

Таблица D.4 - Определение подгруппы объектов WorldFIP Micro-MMS V2

D.2.2.3.2 Реализации MMS

В таблице D.5 представлены варианты реализации WorldFIP MMS для трех классов соответствия коммуникационной сети WorldFIP

Таблица D.5 - Определение профилей коммуникационной сети WorldFIP MMS

D.2.3 Транспортные уровни; DLConformityClass

В таблице D.6 представлены классы соответствия канального уровня WorldFIP согласно документированным данным в атрибуте DLConformityClass.

Таблица D.6 - Классы соответствия канального уровня WorldFIP

D.2.4 Управление сетью

D.2.4.1 Сервисы управления сетью

В таблицах D.7, D.8 и D.9 представлены минимальные сервисы WorldFIP SM_MPS.

Таблица D.7 - Сервисы исполнительного устройства WorldFIP SM_MPS

Таблица D.8 - Системные сервисы WorldFIP SM_MPS

Таблица D.9 - Минимальное подмножество WorldFIP SM MPS

D.2.4.2 NMConformityClass

В таблице D.10 определены классы соответствия управления сетью WorldFIP. Номер класса соответствия сети должен определяться числом в атрибуте DeviceConformityClass.

Таблица D.10 - Классы соответствия управления сетью WorldFIP

D.2.5 XML-схема шаблона профиля коммуникационной сети

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

Шаблоны профиля INTERBUS

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

Е.1.1 Обзор

XML-схемы шаблона профиля устройства, определенные в Е.1.6, содержат отображение диаграмм классов профиля устройства, представленных в разделе 6.5.1. Помимо изображенных классов и атрибутов они содержат дополнительные элементы, имеющие или не имеющие атрибуты XML, с целью облегчения создания не содержащих неопределенностей профилей устройств и описаний устройств на языке XML. Для создания возможности повторного использования определений некоторых элементов и гибкого расширения профилей и описаний устройств с помощью моделей, не предусмотренных в настоящем стандарте, классы были описаны в виде XML-схемы. Таблица Е.1 содержит список ХМL-схем, заменяющих описание шаблонов профилей устройств INTERBUS.

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

Таблица Е.1 - Обзор XML-схем

E.1.2 Основные положения

E.1.2.1 Элементы типов данных

Профиль устройства использует типы данных, определенные в МЭК 61158-5:2003, раздел 5. Для создания дополнительных атрибутов информация о типах данных моделируется с использованием декларирования элементов XML-типа. Типы данных, заимствованные из МЭК 61131-3 и VARIANT, совмещаются и представляются как фиксированные атрибуты. Эти элементы типов данных определены в XML-схеме, называемой FDCMLdt.xsd, которая определена в Е.1.6.2.

Е.1.2.2 Сборная структура

Профиль устройства использует Collection Element Pattern. Эти элементы появляются в форме списка собранных элементов (например, processDataDescriptionList/processDataDescription).

Е.1.2.3 Дескриптивный текст для элементов

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

Профиль устройства предлагает три различных варианта для предоставления дескриптивного текста для элементов. Представленные в Е.1.2.3.2 и Е.1.2.3.3 варианты должны использоваться раздельно. Возможность, представленная в Е.1.2.3.4, может использоваться совместно с возможностями, представленными в Е.1.2.3.2 или Е.1.2.3.3.

Е.1.2.3.2 Текст, вставленный в профиль устройства

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

ИСО 639 код для названия языка ["-" ISO 3166-1-Alpha-2 code].

Е.1.2.3.3 Текст, представленный файлами из внешнего текстового источника

Элементы labelRef и helpRef должны представить указатель источника текста, сохраненного в файле внешнего текстового источника. AIF должен заменить эти ссылки текстом, представленным в файле текстового источника. Файлы текстового источника, использованные в профиле устройства, должны быть определены в элементе словаря.

Формат файла текстового источника определен в XML-схеме FDCMLTextResource.xsd, которая определена в Е.1.6.4.

Е.1.2.3.4 Указатель внешней документации

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

Пример - Примеры внешней документации - *.hlp, *.htm или *.pdf файлы.

Е.1.2.4 Используемые значения элементов

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

Е.1.2.5 Моделирование условного поведения устройства

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

Каждая возможная цель запрета или разрешения имеет действующий атрибут в XML-схеме.

Е.1.2.6 Ссылка на элементы из Интернета

Путь, указанный в атрибуте ref, должен быть действительным XPath-путем (см. [8]).

Е.1.2.7 Уникальная идентификация элемента

Элементы, требующие идентификации, имеют атрибут uniquelD. Значение этого уникального идентификатора должно состоять из следующего:

token_index[ [ _subindex]...], index and subindex of type unsigned 16.

E.1.2.8 Assemblies

Все элементы Assembly разрешают группировку относящихся к ним соответствующих объектных элементов. Сборка содержит список указателей с XPath на входящие в сборку объекты.

Е.1.2.9 Категории, зависящие от поставщика

Разработчик AIP может добавить элементы категории в собрание элементов.

Пример - Разработчик AIP добавляет processDataCategory для входных сигналов и processDataCategory для выходных сигналов.