ГОСТ Р ИСО 15745-4-2010. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 4. Эталонное описание систем управления на основе стандарта Ethernet
(утв. и введен в действие Приказом Росстандарта от 21.12.2010 № 863-ст)
Внимание
Документ утратил силу с 1 января 2014 года в связи с изданием Приказа Росстандарта от 29.11.2012 № 1708-ст. Взамен введен в действие ГОСТ Р ИСО 15745-4-2012. Документ утратил силу с 1 января 2014 года в связи с изданием Приказа Росстандарта от 29.11.2012 № 1708-ст. Взамен введен в действие ГОСТ Р ИСО 15745-4-2012. Документ введен в действие с 1 сентября 2011 года.
ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ
flowchart LR n0["ГОСТ Р ИСО 15745-4-2010"]:::rst click n0 "https://bukva.ai/docs/gost-r-iso-15745-4-2010" "ГОСТ Р ИСО 15745-4-2010. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 4... (у" classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000; classDef doc fill:#EBFFEB,stroke:#006400,color:#000; classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 21 декабря 2010 г. № 863-ст
СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ
ПРИКЛАДНАЯ ИНТЕГРАЦИОННАЯ СРЕДА ОТКРЫТЫХ СИСТЕМ
ЭТАЛОННОЕ ОПИСАНИЕ СИСТЕМ УПРАВЛЕНИЯ НА ОСНОВЕ СТАНДАРТА ETHERNET
Industrial automation systems and integration. Open systems application integration framework. Part 4: Reference description for Ethernet-based control systems
ISO 15745-4:2003 Industrial automation systems and integration. Open systems application integration framework. Part 4. Reference description for Ethernet-based control systems (IDT)
Дата введения 1 сентября 2011 года
Предисловие
Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения».
Сведения о стандарте
1. Подготовлен Научно-техническим центром ИНТЕК на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4.
2. Внесен Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент».
3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. № 863-ст.
4. Настоящий стандарт идентичен международному стандарту ИСО 15745-4:2003 «Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 4. Эталонное описание систем управления на основе стандарта Ethernet» (ISO 15745-4:2003 «Industrial automation systems and integration — Open systems application integration framework. Part 4: Reference description for Ethernet-based control systems»).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном Приложении ДА.
Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячно издаваемом информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет.
Введение
Прикладная интеграционная среда (AIF) определяет элементы и правила, облегчающие:
- систематическую организацию и представление требований к интеграции прикладных систем с помощью моделей интеграции;
- разработку спецификаций интерфейсов в форме профилей интероперабельности прикладных систем (AIP), что позволяет выбрать как соответствующие ресурсы, так и документацию «встроенных» прикладных систем.
ИСО 15745-1 устанавливает общие элементы и правила описания интегрированных моделей и AIP вместе с их профилями компонент — профили процессов, профили обмена информацией и профили ресурсов. Содержание комплекса стандартов ИСО 15745 и структурный вид составных частей AIP показаны на рисунке 1 ИСО 15745-1:2003.
Настоящий стандарт расширяет исходную AIF, описанную в ИСО 15745-1, путем определения специальных технологических элементов и правил описания как профилей сетей коммуникаций, так и связанных с коммуникациями аспектов профилей устройств, специфичных для систем управления, основанных на Ethernet <1>, ADS-net <2>, FL - net^{®} <3> и EtherNet/IP^{\text{ТМ}} <4>. Технология EtherNet/IP^{\text{ТМ}} использует профиль МЭК 61158, который описан в МЭК 61784-1.
<1> Ethernet использован в данном документе в качестве синонима ИСО/МЭК 8803-3.
<2> ADS-net является торговой маркой, используемой для описания JIS-TR B0012 (сеть Автономной Децентрализованной Системы). Эта информация предоставлена для удобства пользователей ИСО 15745 и не означает одобрения со стороны ИСО торговой марки или какой-либо продукции. Для соответствия настоящему стандарту не требуется использования торговой марки ADS-net.
<3> FL - net^{®} является торговой маркой для описания JEM 1479. Эта информация предоставлена для удобства пользователей ИСО 15745 и не означает одобрения со стороны ИСО торговой марки или какой-либо продукции. Для соответствия настоящему стандарту не требуется использования торговой марки FL - net^{®} .
<4> EtherNet/IP^{\text{ТМ}} является торговой маркой ControlNet International, Ltd и Ассоциации поставщиков открытой DeviceNet. Эта информация предоставлена для удобства пользователей ИСО 15745 и не означает одобрения со стороны ИСО торговой марки или какой-либо продукции. Для соответствия настоящему стандарту не требуется использование торговой марки ControlNet/IP^{\text{ТМ}} . Применение торговой марки ControlNet/IP^{\text{ТМ}} требует разрешения либо ControlNet International, Ltd, или Ассоциации поставщиков открытой DeviceNet.
В частности, настоящий стандарт описывает специфические для технологии шаблоны профилей для профилей устройств и профилей сетей коммуникаций. В рамках AIP вариант профиля устройства или вариант профиля сети коммуникаций является частью профиля ресурсов, определенного в ИСО 15745-1. Варианты файлов XML профиля устройства и профиля сети коммуникаций включены в вариант XML профиля ресурсов с использованием ProfileHandle_DataType согласно определениям в ИСО 15745-1:2003, пункт 7.2.5.
Установленные среды (AIF-ы), использующие элементы и правила стандарта ИСО 15745-1, могут быть легко интегрированы с профилями компонент, определенных с использованием элементов и правил, установленных в настоящем стандарте.
Стандарт ИСО 15745-4 был подготовлен техническим комитетом ИСО/ТК 184 «Системы промышленной автоматизации и интеграция», подкомитетом ПК 5 «Архитектура, коммуникации и структуры интеграции».
Стандарт ИСО 15745 состоит из следующих частей, под общим названием «Системы промышленной автоматизации и интеграция. Прикладная среда интегрирования открытых систем»:
- часть 2. Эталонное описание систем управления на основе стандарта ИСО 11898;
- часть 3. Эталонное описание систем управления на основе стандарта МЭК 61158;
- часть 4. Эталонное описание систем управления на основе стандарта Ethernet.
Следует обратить внимание на возможность того, что некоторые элементы настоящего документа могут быть объектом патентных прав. ИСО не несет ответственности за определение патентных прав.
1. Область применения
Настоящий стандарт устанавливает описание технологических спецификаций для элементов и правил как профилей коммуникационной сети, так и связанных с коммуникациями аспектов профилей устройств, относящихся к системам управления на основе Ethernet.
Примечание. Общие элементы и правила описания моделей интеграции и профилей интероперабельности приложений с профилями их компонент (профили процессов, профили обмена информацией и профили ресурсов) установлены в ИСО 15745-1.
При описании среды интеграции приложений настоящий стандарт следует использовать совместно с ИСО 15745-1.
2. Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты, которые необходимо учитывать при использовании настоящего стандарта. В случае ссылок на документы, у которых указана дата утверждения, необходимо пользоваться только указанной редакцией. В случае, когда дата утверждения не приведена, следует пользоваться последней редакцией ссылочных документов, включая любые поправки и изменения к ним:
ИСО 639-2:1998. Коды для представления названий языков. Часть 2. Трехбуквенный код (ISO 639-2:1998. Codes for the representation of names of languages — Part 2: Alpha-3 code)
ИСО 15745-1:2003. Системы промышленной автоматизации и интеграция. Прикладная среда интегрирования открытых систем. Часть 1. Общее эталонное описание (ISO 15745-1:2003. Industrial automation systems and integration — Open systems application integration framework — Part 1: Generic reference description)
ИСО/МЭК 7984-4:1989. Системы обработки информации. Взаимодействие открытых систем. Базовая эталонная модель. Часть 4. Структура управления (ISO/IEC 7498-4:1989. Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 4: Management framework)
ИСО/МЭК 8802-3:2000. Информационные технологии. Телекоммуникации и информационный обмен между системами. Локальные и общегородские сети. Специальные требования. Часть 3. Метод доступа (CSMA/CD) с обнаружением столкновений и спецификации физического уровня (ISO/IEC 8802-3:2000. Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications)
ИСО/МЭК 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)
МЭК 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)
IEEE Std 754-1985 (R1990). IEEE Standard for Binary Floating Point Arithmetic
JEM 1479:2002. Protocol specification — Factory automation control Link Network (FL-net)
REC-xml-20001006. Extensible Markup Language (XML) 1.0. Second Edition — W3C Recommendation 6 October 2000
REC-xmlschema-1-20010502. XML Schema. Part 1: Structures — W3C Recommendation 02 May 2001
REC-xmlschema-2-20010502. XML Schema. Part 2: Datatypes — W3C Recommendation 02 May 2001
RFC 768:1980. User Diagram Protocol — Internet Engineering Task Force (IETF), request for Comments (RFC)
RFC 791:1981. Internet Protocol — Internet Engineering Task Force (IETF), request for Comments (RFC)
RFC 793:1981. Transmission Control Protocol — Internet Engineering Task Force (IETF), request for Comments (RFC)
RFC 894:1984. A standard for the Transmission of IP Datagrams over Ethernet Network — Internet Engineering Task Force (IETF), request for Comments (RFC)
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)
ИСО 639-1:2002. Коды для представления названий языков. Часть 1. Двухбуквенный код (ISO 639-1:2002. Codes for the representation of names of languages — Part 1: Alpha-2 code)
ИСО 15745-3:2003. Системы промышленной автоматизации и интеграция. Прикладная среда интегрирования открытых систем. Часть 3. Эталонное описание систем управления на основе стандарта МЭК 61158 (ISO 15745-3:2003. Industrial automation systems and integration — Open systems application integration framework — Part 3: Reference description for IEC 61158-based control systems)
ИСО/МЭК 11578:1996. Информационные технологии. Взаимосвязь открытых систем. Вызов удаленных процедур (ISO/IEC 11578:1996. Information technology — Open Systems Interconnection — Remote Procedure Call (RPC))
REC-svg-20030114. Scalable Vector Graphics (SVG) 1.1. Specification — W3C Recommendation 14 January 2003, available at <http://www.w3.org/TR/S VG/>
REC-xpath-1999111. XML Path Language (XPath). Version 1.0 — W3C Recommendation 16 November 1999
RFC 1101:1989. DNS encoding of network names and other types — Internet Engineering Task Force (IETF), Request for Comments (RFC)
RFC 2131:1997. Dynamic Host Configuration Protocol — Internet Engineering Task Force (IETF), Request for Comments (RFC)
UML V1.4, OMG — Unified Modeling Language Specification (Version 1.4, September 2001).
3. Термины и определения
В настоящем стандарте применены термины по ИСО 15745-1.
Примечание. Терминология UML и обозначения, использованные в настоящем стандарте, описаны в ИСО 15745-1:2003 (приложение A).
4. Сокращения и обозначения
AIF — среда интеграции приложений (Application Integration Framework);
AIP — профиль интероперабельности приложений (Application Interoperability Profile);
ASCII — Американский стандартный код для обмена информацией (American Standard Code for Information Interchange);
ASE — элемент сервиса приложения (Common Industrial Protocol);
CIP^{TM} <5> - общий промышленный протокол (Common Industrial Protocol);
EDS — электронный бланк данных (Electronic Data Sheet);
IAS — системы промышленной автоматизации (Industrial Automation Systems);
ID — идентификатор (Identifier);
IP — Интернет-Протокол (см. RFC 791 и RFC 894) (Internet Protocol);
MAC — контроль доступа к носителю информации (Media Access Control);
MCG — группа многоадресной передачи (Multicast Group);
OSI — взаимодействие открытых систем (Open System Interconnection);
TCP — протокол контроля передачи (см. RFC 793) (Transmission Control Protocol);
UDP — протокол датаграммы пользователя (см. RFC 768) (User Datagram Protocol);
UML — унифицированный язык моделирования (см. UML V1.4) (Unified Modeling Language);
XML — расширяемый язык разметки (см. REC-xml-20001006) (eXtensible Markup Language);
DNS — система имен доменов (Domain Name System (см. RFC 1101));
GSD — общее описание станции (Generic Station Description);
GSDML — язык разметки для общего описания станции (Generic Station Description Markup Language);
ID — идентификация (Identification);
IO — ввод/вывод (Input/Output);
PDU — блок данных протокола (Protocol Data Unit);
SVG — масштабируемая векторная графика (Scalable Vector Graphics (см. REC-svg-20030114));
URL — унифицированный указатель ресурса (Uniform Resource Locator);
UUID — универсальный уникальный идентификатор (Universally Unique Identifier (см. ISO/IEC 11578));
W3C — Консорциум всемирной сети (World Wide Web Consortium).
<5> CIP^{TM} является торговой маркой ControlNet International, Ltd. и Open DeviceNet Vendor Association, Inc. Эта информация предоставлена для удобства пользователей ИСО 15745 и не означает подтверждения со стороны ИСО держателя торговой марки или какой-либо из его продукции. Для соответствия настоящему стандарту не требуется использование торговой марки CIP^{TM} . Применение торговой марки CIP^{TM} требует разрешения ControlNet International, Ltd. и Open DeviceNet Vendor Association, Inc.
5. Специфические для технологии элементы и правила
5.1. Модели интеграции и интерфейсы IAS
Разработчик AIP должен подготовить модель интеграции, использующую описанные в ИСО 15745-1 правила, а также гарантировать, что основанные на Ethernet профили устройств и сетей коммуникаций (как соответствующие требованиям интерфейса, так и полученные на основе существующих устройств/сетей коммуникаций) включают в себя необходимые интерфейсы IAS. Интерфейсы IAS, включенные в профиль, должны быть указаны в разделе заголовков (см. ИСО 15745-1:2003, пункт 7.2.2).
Примечание. Интерфейсы IAS описаны в ИСО 15745-1:2003 (приложение B).
5.2. Шаблоны профилей
5.2.1 Общие положения
Специфические для основанной на Ethernet технологии шаблоны профилей разрабатывают исходя из общих шаблонов профилей, установленных в ИСО 15745-1:2003 (раздел 7).
5.2.2 Содержание и синтаксис
Комплекс стандартов ИСО 15745 устанавливает шаблоны профилей, представляющие собой XML схемы (REC-xmlschema-1-20010502 и REC-xmlschema-2-20010502) и использующие общую родовую структуру. Профили устройств и сетей коммуникаций, основанные на этих шаблонах, как правило, включают следующее:
- информацию, необходимую для идентификации соединяемого устройства;
- описание данных устройства, которые могут быть доступны по сети;
- описание коммуникационных возможностей, поддерживаемых устройством;
- дополнительную относящуюся к поставщику информацию.
Однако в некоторых технологиях на основе Ethernet используют специальный ранее принятый синтаксис ASCII. В связи с этим для достижения обратной совместимости определений шаблонов в любых технологиях (см. Приложения) включают все или необходимые следующие подмножества:
- шаблонов профилей сетей коммуникаций и устройств согласно определениям в ИСО 15745-1;
- шаблона ИСО 15745 для инкапсуляции файлов, содержащих ранее принятый синтаксис ASCII («оболочку»);
- ранее принятого синтаксиса ASCII.
5.2.3 Заголовок
Заголовок шаблона профиля, определенный в ИСО 15745-1:2003 (пункт 7.2.2), используют для специфических для технологии Ethernet шаблонов профилей. Каждая технология использует одно имя или более для идентификации технологии или ее частных компонент (см. таблицу 1). Выбранное имя должно сохраняться в атрибуте ProfileTechnology в разделе заголовка.
| Имя ProfileTechnology | Технология |
|---|---|
| ADS-Net | ADS-Net |
| FL-net | FL-net |
| EtherNet/IP | EtherNet/IP |
| CIP | EtherNet/IP |
| EDS | EtherNet/IP |
| GSDML | PROFINET |
5.3. Специфические для технологии профили
Структура специфического для технологии профиля сети коммуникаций и коммуникационные аспекты структуры профиля устройства, основанные на технологиях Ethernet, описаны в разделе 6. Рассматриваемые технологии включают в себя:
Соответствующие определения шаблона профиля приведены в Приложениях A - D.
6. Профили устройств и сетей коммуникаций в системах управления, основанных на Ethernet
6.1. ADS-net
6.1.1. Профиль устройства
6.1.1.1 Общие положения
На рисунке 1 показана диаграмма класса профилей устройства ADS-net.
| DeviceProfile |
|---|
<>
Рисунок 1. Диаграмма класса профилей устройства ADS-net
Имеющиеся форматы профилей устройств ADS-net описаны в A.2 (Приложение A).
XML схема, представляющая шаблон профиля устройства ADS-net, определена в A.2.3 (Приложение A). Имя файла этой XML схемы должно быть «ADS-net_Device_Profile.xsd».
Примечание. Диаграмма класса профиль устройства ADS-net, показанная на рисунке 1, определяет основные классы. Эти классы далее развертываются; подробности приведены в Приложении A.
XML схема, представляющая шаблон профиля устройства ADS-net, определена в A.2 (Приложение A).
6.1.1.2 DeviceIdentity (идентификация устройства)
Класс DeviceIdentity содержит атрибуты, которые уникальным образом идентифицируют устройство, и поддерживает сервисы, позволяющие извлечь эту информацию из устройства.
6.1.1.3 DeviceManager (менеджер устройства)
Класс менеджер устройства содержит атрибуты и поддерживает сервисы, используемые для контроля и конфигурирования устройства.
Эти атрибуты предоставляют следующую информацию:
6.1.1.4 DeviceFunction (функция устройства)
Класс DeviceFunction содержит атрибуты и поддерживает сервисы, позволяющие управлять функциями устройства, например его конфигурацией.
Эти атрибуты предоставляют следующую информацию:
6.1.1.5 ApplicationProcess (прикладной процесс)
Класс ApplicationProcess содержит атрибуты и поддерживает сервисы, позволяющие осуществлять контроль коммуникаций между программами приложений, выполняемых в ADS-net.
Эти атрибуты предоставляют следующую информацию:
- список TCD производителей (Producer-TCD-List);
- список TCD потребителей (Consumer-TCD-List);
- приоритет (Priority).
6.1.2. Профиль сети коммуникаций
6.1.2.1 Общие положения
На рисунке 2 показана диаграмма класса профилей коммуникационной сети ADS-net.
| CommNetworkProfile |
|---|
<>
Рисунок 2. Диаграмма класса профилей сети коммуникаций ADS-net
Существующие форматы профилей сети коммуникаций ADS-net описаны в A.3 (Приложение A).
XML схема, представляющая шаблон профиля сети коммуникаций ADS-net, определена в A.3.3 (Приложение A). Имя файла этой XML схемы должно быть «ADS-net_CommNet_Profile.xsd».
6.1.2.2 ApplicationLayers (прикладные уровни)
6.1.2.2.1 Общие положения
Класс ApplicationLayers ADS-net представляет комбинированные профили трех верхних уровней OSI модели интеграции сети коммуникаций ADS-net. Он устанавливает поддерживаемые элементы сервиса приложения и их ассоциированные сервисы.
На рисунке 3 показано определение класса ApplicationLayers ADS-net.
| ApplicationLayers |
|---|
<>
<pre class="legal-pre"> ┌──────────────────┐ 1..* │ 1..* ┌────────────────────┐
│ DataField ├─────────────┴─────────────┤ MessageSelection │
├──────────────────┤ ├────────────────────┤
│ DFNO │ │Producer-TCD-List │
│ NETADDR │ │Consumer-TCD-List │
│ BCADDR │ │Producer-MCG-List │
│ NETMASK │ │Consumer-MCG-List │
│ MCG-Table │ │ │
└──────────────────┘ └────────────────────┘</pre>
<>
| 1 | 0..1 | |||
| AliveNotification | ErrorNotification | |||
| ND-Name | CNT-Mode-Alive | |||
| OS-Name | Mode-Alive-List | |||
| TM-Out | CNT-Error | |||
| Chg-Time | ERR-Name | |||
| IRADDR | ERR-List Mod-NO ERR-NO CNT-Option Option-List | |||
6.1.2.2.2 DataField (поле данных)
6.1.2.2.2.1 Общие положения
ADS-net определяет домен под именем «Data Field», в котором подсистемы разделяют информацию при пересылке сообщений между равноправными узлами. Каждый узловой компьютер передает сообщения на многоадресной основе в поле данных, к которому он относится, и другие узловые компьютеры, принадлежащие к тому же полю данных, могут получать эти данные автономно. Многие компьютеры, относящиеся к некоторому полю данных, посылают или принимают данные. Многоадресная группа (MCG), т.е. группа узловых компьютеров, относящихся к определенному полю данных, также вводится в целях локализации многоадресной передачи.
DataField определяет характеристики, используемые для контроля поля данных. Атрибуты DataField предоставляют, в частности, следующую информацию:
6.1.2.2.2.2 AliveNotification (уведомление о рабочем состоянии)
На поле данных периодически передается сообщение «keep alive» («в рабочем состоянии») для уведомления других узловых компьютеров о статусе узлового компьютера-отправителя.
AliveNotification определяет параметры, используемые для проверки статуса узловых компьютеров. Атрибуты AliveNotification предоставляют, в частности, следующую информацию:
6.1.2.2.2.3 ErrorNotification (уведомление об ошибке)
Когда на узловом компьютере произошел отказ, информация об отказе включается в сообщение «keep alive», передаваемое на поле данных во время цикла передачи сообщения «keep alive». Любой узловой компьютер, относящийся к тому же полю данных, может обнаружить состояние отказа (ошибки).
ErrorNotification определяет параметры, описывающие информацию об отказе. Атрибуты ErrorNotification предоставляют, в частности, следующую информацию:
6.1.2.2.3 MessageSelection (выбор сообщения)
Код транзакции TCD представляет собой идентификатор сообщения, определенный уникальным образом в поле данных. Передающее устройство посылает сообщение с присвоенным TCD на указанное поле данных на многоадресной основе, а каждый узловой компьютер, относящийся к этому полю данных, автономно выбирает только подходящие сообщения на основе TCD.
MessageSelection определяет параметры, используемые для обмена сообщениями. Атрибуты MessageSelection предоставляют, в частности, следующую информацию:
- список TCD производителей (Producer-TCD-List);
- список TCD потребителей (Consumer-TCD-List);
- список MCG производителей (Producer-MCG-List);
- список MCG потребителей (Consumer-MCG-List).
6.1.2.3 TransportLayers (транспортные уровни)
6.1.2.3.1 Общие положения
Класс ADS-net TransportLayers представляет комбинированные профили для низших четырех уровней OSI модели интеграции сети коммуникаций. Класс TransportLayers подразделяется на один или более основанных на Ethernet объектов и объект UDP/IP.
6.1.2.3.2 EthernetObject (объект Ethernet)
EthernetObject определяет параметры Ethernet, используемые для реализации ADS-net. Атрибуты EthernetObject предоставляют следующую информацию:
- тип носителя информации (MediaType);
- скорость коммуникаций (CommRate);
- индикаторы (Indicators);
- адрес MAC (MACAddress);
- журнал ошибок (ErrorLog).
6.1.2.3.3 Объект UDP-IP (UDP-IPObject)
UDP-IPObject определяет параметры UDP/IP, используемые для реализации ADS-net. Атрибуты UDP-IPObject предоставляют следующую информацию:
- адрес IP (IPADDR);
- информацию о многоадресной группе (UDP-IP-MCGs);
- имя хоста (HostName);
- журнал ошибок (ErrorLog).
6.1.2.4 NetworkManagement (управление сетью)
6.1.2.4.1 Общие положения
Класс ADS-net NetworkManagement представляет конфигурацию сети и возможности регулировки характеристик модели интеграции коммуникационной сети ADS-net.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 2.
6.1.2.4.2 Nm-Configuration (Nm-Конфигурация)
6.1.2.4.2.1 Общие положения
Nm-Configuration определяет параметры конфигурации сети, относящейся к ADS-net. Атрибуты Nm-Configuration предоставляют, в частности, следующую информацию:
- список номеров активных полей данных (ActiveDataFieldNoList);
- список номеров активных узлов (ActiveNodeNoList);
- список номеров активных многоадресных групп (ActiveMulticastGroupNoList).
6.1.2.4.2.2 Nm-MessageSelection (Выбор Nm-сообщения)
Nm-MessageSelection определяет параметры, используемые для управления выбором сообщений. Атрибуты Nm-MessageSelection предоставляют, в частности, следующую информацию:
- поддерживаемый список TCD активных производителей (ActiveProducerTCDSupportedList);
- поддерживаемый список TCD активных потребителей (ActiveConsumerTCDSupportedList).
6.1.2.4.2.3 Nm-Performance (Nm-Характеристики)
Nm-Performance определяет параметры, используемые для мониторинга характеристик. Атрибуты Nm-Performance предоставляют следующую информацию:
6.1.2.4.3 Nm-Fault (Nm-Отказ)
Nm-Fault определяет параметры, используемые для мониторинга отказов. Атрибуты Nm-Fault предоставляют, в частности, следующую информацию:
6.2. FL-net
6.2.1. Профиль устройства
6.2.1.1 Общие положения
На рисунке 4 показана диаграмма класса профилей устройства FL-net.
| DeviceProfile |
|---|
<>
<pre class="legal-pre"> ┌───────────────────┐ 1 │ 0..* ┌────────────────────┐
│ DeviceIdentity ├──────────┼─────────┤ ApplicationProcess │
└───────────────────┘ │ └────────────────────┘
┌───────────────────┐ 1 │
│ DeviceManager ├──────────┤
└───────────────────┘ │
┌───────────────────┐ 1..* │
│ DeviceFunction ├──────────┘</pre>
└───────────────────┘
Рисунок 4. Диаграмма класса профиля устройства FL-net
Существующие форматы профилей устройства FL-net описаны в B.1 (Приложение B).
XML схема, представляющая шаблон профиля устройства FL-net, определена в B.1.5 (Приложение B). Имя файла этой XML схемы должно быть «FL-net_Device_Profile.xsd».
Примечание 1. Диаграмма класса профиля устройства FL-net, показанная на рисунке 4, определяет основные классы. Некоторые классы далее развертываются; подробности приведены в Приложении B.
Примечание 2. Все эти классы отображены в одной XML схеме, определенной в B.1.5 (Приложение B).
6.2.1.2 DeviceIdentity (идентификация устройства)
Класс DeviceIdentity определен на рисунке 5, а подклассы описаны в таблице 2.
| DeviceIdentity |
|---|
<>
Рисунок 5. Диаграмма класса FL-net DeviceIdentity
Элементы объекта DeviceIdentity
| Элементы класса | Описание |
|---|---|
| VendorCode (Код продавца) | Код изготовителя или продавца устройства |
| ProductName (Имя продукта) | Специальное имя продукта продавца |
| ProductCode (Код продукта) | Уникальный идентификатор ID, идентифицирующий продукт. Формат определяется продавцом |
| ProductRevision (Версия продукта) | Номер версии продукта продавца |
| DeviceType (Тип продукта) | Конкретный тип устройства FL-net (см. Приложение B, таблица B.1) |
6.2.1.3 DeviceManager (менеджер устройства)
6.2.1.3.1 Общие положения
| DeviceManager |
|---|
<>
Рисунок 6. Диаграмма класса FL-net DeviceManager
6.2.1.3.2 DeviceIDSpecRev (версия спецификации идентификатора устройства)
Объект DeviceIDSpecRev должен описывать версию объекта идентификатора FL-net.
6.2.1.3.3 CommuServiceManager (менеджер коммуникационных услуг)
Объект CommuServiceManager должен описывать сервис коммуникаций, который несет ответственность за мониторинг и конфигурацию.
6.2.1.3.4 DeviceState (состояние устройства)
Объект DeviceState должен описывать состояния устройства.
6.2.1.4 DeviceFunction (функция устройства)
Объект DeviceFunction содержит атрибуты и поддерживает сервисы, обеспечивающие менеджмент (например, конфигурацию) функций устройства.
Примечание. Класс функций устройства в ИСО 15745-4 не определен.
6.2.1.5 ApplicationProcess (прикладной процесс)
Объект ApplicationProcess содержит атрибуты и поддерживает сервисы, соответствующие требованиям приложения.
Эти атрибуты предоставляют, в частности, следующую информацию:
Для создания конкретного представления процесса приложения могут быть определены дополнительные подклассы и дополнительные атрибуты, описывающие процесс приложения.
6.2.2. Профиль сети коммуникаций
6.2.2.1 Общие положения
| CommNetworkProfile |
|---|
<><br>
│
<pre class="legal-pre"> ┌──────────────────────┐ 1 │ 1 ┌──────────────────────┐
│ ApplicationLayers ├────┼────┤ NetworkManagement │
└──────────────────────┘ │ └──────────────────────┘</pre>
<> │ <>
<pre class="legal-pre"> ┌────────────────────┐1..*│ │ │ 1..* ┌───────────────────┐
│ ComMemoryInterface ├────┤ │ ├──────┤ Configuration │
└────────────────────┘ │ │ │ └───────────────────┘
┌────────────────────┐1..*│ │ │ 1..* ┌───────────────────┐
│ MessageService ├────┤ │ ├──────┤ ServiceSelection │
└────────────────────┘ │ │ │ └───────────────────┘
┌────────────────────┐0..1│ │ │ 1..* ┌───────────────────┐
│ ErrorNotification ├────┘ │ ├──────┤PerformanceManager │
└────────────────────┘ │ │ └───────────────────┘
┌──────────────────┐ 1 │ │ 1..* ┌───────────────────┐
│ TransportLayers ├───┘ └──────┤ FaultManager │
└──────────────────┘ └───────────────────┘</pre>
<>
Рисунок 7. Диаграмма класса профилей коммуникационной сети FL-net
Существующие форматы профилей коммуникационной сети FL-net описаны в B.2 (Приложение B).
XML схема, представляющая шаблон профилей коммуникационной сети FL-net, определена в B.2.4.5 (Приложение B). Имя файла этой XML схемы должно быть «FL-net_CommNet_Profile.xsd».
6.2.2.2 ApplicationLayers (прикладные уровни)
6.2.2.2.1 Общие положения
Класс FL-net ApplicationLayers представляет комбинированные профили верхних трех уровней OSI модели интеграции сети коммуникаций FL-net. Он устанавливает поддерживаемые элементы сервиса приложения и ассоциированные с ними сервисы.
Далее этот класс делится на несколько классов, как показано на рисунке 7.
Примечание. Объект ApplicationLayers полностью определен в JEM 1479:2002.
6.2.2.2.2 ComMemoryInterface (интерфейс коммуникативной памяти)
Объект ComMemoryInterface определяет характеристики, связанные с общим интерфейсом памяти. Элементы объекта ComMemoryInterface определены в B.2.2.1 (Приложение B).
6.2.2.2.3 MessageService (сервис сообщений)
Объект MessageService определяет характеристики, ассоциированные с сервисами сообщений устройства. Элементы объекта MessageService определены в B.2.2.2 (Приложение B).
6.2.2.2.4 ErrorNotification (уведомление об ошибке)
Объект ErrorNotification определяет характеристики, ассоциированные с видами ошибок, относящимися к сети и устройству. Элементы объекта ErrorNotification определены в B.2.2.3 (Приложение B).
6.2.2.3 TransportLayers (транспортные уровни)
6.2.2.3.1 Общие положения
Класс FL-net TransportLayers представляет комбинированные профили четырех нижних уровней OSI модели интеграции сети коммуникаций FL-net.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 7.
6.2.2.3.2 EthernetBasedObject (объект на основе Ethernet)
Объект EthernetBasedObject определяет характеристики, связанные с физическим уровнем FL-net. Элементы объекта EthernetBasedObject определены в B.2.3.1 (Приложение B).
6.2.2.3.3 UDP-IPObject (объект UDP-IP)
Объект UDP-IPObject определяет характеристики, связанные с конфигурацией и мониторингом канала передачи данных. Элементы объекта UDP-IPObject определены в B.2.3.2 (Приложение B).
6.2.2.4 NetworkManagement (управление сетью)
6.2.2.4.1 Общие положения
Класс FL-net NetworkManagement представляет средства наладки характеристик и конфигурации сети в модели интеграции сети коммуникаций FL-net.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 7.
Примечание. Объект NetworkManagement полностью определен в JEM 1479:2002.
6.2.2.4.2 Configuration (конфигурация)
Объект Configuration определяет характеристики, связанные с первоначальной установкой и модификацией конфигурации. Элементы объекта Configuration определены в B.2.4.1 (Приложение B).
6.2.2.4.3 ServiceSelection (выбор сервиса)
Объект ServiceSelection определяет характеристики, связанные с сервисами сети коммуникаций. Элементы объекта ServiceSelection определены в B.2.4.2 (Приложение B).
6.2.2.4.4 PerformanceManager (менеджер исполнения)
Объект PerformanceManager определяет параметры, связанные с характеристиками обмена данными в сети. Элементы объекта PerformanceManager определены в B.2.4.3 (Приложение B).
6.2.2.4.5 FaultManager (менеджер отказов)
Объект FaultManager определяет характеристики, связанные с возможностями отказов в FL-net. Элементы объекта FaultManager определены в B.2.4.4 (Приложение B).
6.3. EtherNet/IP
6.3.1. Профиль устройства
6.3.1.1 Общие положения
На рисунке 8 показана диаграмма класса профиль устройства EtherNet/IP.
| DeviceProfile |
|---|
<>
<pre class="legal-pre"> ┌──────────────────┐ │
│ DeviceIdentity ├───────────┤
└──────────────────┘ 1 │ ┌────────────────────┐</pre>
├─────┤ ApplicationProcess │
<pre class="legal-pre"> ┌──────────────────┐ │0..* └────────────────────┘
│ DeviceManager ├───────────┤ <>
└──────────────────┘ 0..1 │ │ ┌───────────────┐
│ ├────┤ Assembly │
┌──────────────────┐ │ │0..*└───────────────┘
│ DeviceFunction ├───────────┘ │
└──────────────────┘ 1..* │ ┌───────────────┐
├────┤ Parameter │</pre>
│0..*└───────────────┘
│ ┌───────────────┐
└────┤ParameterGroup │
0..*└───────────────┘
Рисунок 8. Диаграмма класса профиля устройства EtherNet/IP
Существующие форматы профиля устройства EtherNet/IP описаны в C.1 (Приложение C).
XML схема, представляющая шаблон профиля устройства EtherNet/IP, определена в C.2.1.3.3 (Приложение C). Имя файла этой схемы XML должно быть «2CIP_Device_Profile.xsd».
Примечание. Диаграмма класса профиля устройства EtherNet/IP, показанная на рисунке 8, определяет основные классы. Некоторые классы далее развертываются; подробности приведены в Приложении C.
XML схема, представляющая инкапсуляцию ранее принятого EtherNet/IP EDS в шаблон профиля устройства ИСО 15745, определена в C.2.2.2 (Приложение C). Имя файла этой XML схемы должно быть «EDS_Device_Profile_wrapper.xsd». Синтаксис ASCII ранее принятого EDS описан в C.4 (Приложение C).
6.3.1.2 Device identity (идентификация устройства)
Класс DeviceIdentity содержит атрибуты, которые уникальным образом идентифицируют устройство, и поддерживает сервисы, которые позволяют извлекать эту информацию из устройства.
Эти атрибуты предоставляют, в частности, следующую информацию:
- идентификация изготовителя (имя и код идентификации);
- идентификация устройства (тип устройства, имя продукта, версия, серийный номер);
- классификация устройства.
6.3.1.3 Device manager (менеджер устройства)
Класс DeviceManager содержит атрибуты и поддерживает сервисы, используемые для мониторинга и конфигурации устройства.
Эти атрибуты предоставляют, в частности, следующую информацию:
- версию объекта идентичности EtherNet/IP;
- информацию о структуре устройства (для устройств, интегрированных в модульную систему).
6.3.1.4 Device function (функция устройства)
Класс DeviceFunction содержит атрибуты и поддерживает сервисы, позволяющие осуществлять управление функциями устройства (например, конфигурацией).
Пример - Примерами объектов DeviceFunction являются Overload (перегрузка), Presence Sensing (обнаружение присутствия), Analogue Input (аналоговый ввод), Discrete Output (дискретный вывод).
Примечание. Класс DeviceFunction не определен в ИСО 15745-4.
6.3.1.5 Application process (прикладной процесс)
На рисунке 9 показана структура класса ApplicationProcess.
| ApplicationProcess |
|---|
<>
│ 0..1
0..1 ┌───────────────────────┼─────────────────────────┐ 0..1
<pre class="legal-pre"> ┌────────┴───────┐ ┌───────┴───────┐ ┌───────┴───────┐
│ Assembly │ │ Parameter │ │ParameterGroup │
└────────────────┘ └───────────────┘ └───────────────┘</pre>
<> <> <>
<pre class="legal-pre"> │ │ │
│┌─────────────────┐ │ ┌─────────────────┐ │┌──────┐
├┤ AssemblyClass │ ├────┤ ParameterClass │ └┤Group │
0..1 │└─────────────────┘ 0..1│ └─────────────────┘ 0..*└──────┘
│┌─────────────────┐ │ ┌─────────────────┐
├┤AssemblyInstance │ ├────┤ParameterInstance│
0..1 │└─────────────────┘ 0..1│ └─────────────────┘
│┌─────────────────┐ │ ┌─────────────────┐
└┤ Assem │ └────┤ Param │
0..* └─────────────────┘ 0..* └─────────────────┘</pre>
Класс Assembly объединяет несколько элементов данных процесса приложения в один блок в целях оптимизации коммуникаций. Класс Parameter предоставляет стандартный интерфейс для доступа к отдельным элементам данных процесса приложения. Класс ParameterGroup определяет группы связанных параметров для специальных целей (например, конфигурации, мониторинга).
Класс Assembly и класс Parameter поддерживают атрибуты и сервисы на уровнях как класса, так и варианта.
Классы Assem, Param и Group определяют отдельные варианты основных классов.
Примечание. Класс Assembly и класс Parameter соответствуют объекту EtherNet/IP Assembly и объектам Parameter. Объект Assembly полностью определен в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2).
6.3.2. Профиль коммуникационной сети
6.3.2.1 Общие положения
На рисунке 10 показана диаграмма класса профилей сети коммуникаций EtherNet/IP.
| CommNetworkProfile |
|---|
<>
│
┌─────────────────────┼─────────────────────────┐
<pre class="legal-pre"> │1 │1 │0..1
┌──────────┴────────┐ ┌────┴─────────────┐ ┌─────────┴─────────┐
│ ApplicationLayers │ │ TransportLayers │ │ NetworkManagement │
└───────────────────┘ └──────────────────┘ └───────────────────┘</pre>
<> <> <>
<pre class="legal-pre"> ┌─────────────────┐ 1│ ┌────────────────────┐0..1│ │0..1┌───────────────────────┐
│ConnectionManager├──┤ │ ENPhysicalLayer ├────┤ ├────┤NM-EtherNetIPLinkObject│
└─────────────────┘ │ └────────────────────┘ │ │ └───────────────────────┘
┌─────────────────┐ 1│ ┌────────────────────┐0..1│ │0..1┌───────────────────────┐
│ MessageRouter ├──┘ │EtherNetIPLinkObject├────┤ ├────┤NM-TCPIPInterfaceObject│
└─────────────────┘ └────────────────────┘ │ │ └───────────────────────┘
┌────────────────────┐0..1│ │0..1┌───────────────────────┐
│TCPIPInterfaceObject├────┤ ├────┤ NM-ConnectionManager │
└────────────────────┘ │ │ └───────────────────────┘
┌─────────────────────┐0..1│ │0..1┌───────────────────────┐
│EncapsulationProtocol├────┤ └────┤ NM-MessageRouter │
└─────────────────────┘ │ └───────────────────────┘</pre>
┌────────────────────┐0..1│
│ Ports ├────┘
└────────────────────┘
Рисунок 10. Диаграмма класса профилей коммуникационной сети EtherNet/IP
Существующие форматы профилей коммуникационной сети EtherNet/IP описаны в C.3 (Приложение C).
XML схема, представляющая шаблон профиля коммуникационной сети EtherNet/IP, определена в C.3.1.3 (Приложение C). Имя файла этой XML схемы должно быть «ENet_CommNet_Profile.xsd».
XML схема, представляющая инкапсуляцию ранее принятого EtherNet/IP EDS в шаблон профиля коммуникационной сети ИСО 15745, определена в C.3.2.2 (Приложение C). Имя файла этой XML схемы должно быть «EDS_CommNet_Profile_wrapper.xsd». Синтаксис ASCII ранее принятого EDS описан в C.4 (Приложение C).
6.3.2.2 Application Layers (прикладные уровни)
Класс EtherNet/IP ApplicationLayers представляет комбинированные профили трех верхних уровней OSI модели интеграции сети коммуникаций EtherNet/IP.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 10:
- ConnectionManager (менеджер связи) определяет характеристики, относящиеся к соединениям и управлению соединениями;
- MessageRouter (маршрутизатор сообщений) определяет характеристики, связанные с маршрутизацией внутренних сообщений в устройстве.
Примечание. Соответствующий объект Connection Manager и объект Message Router полностью определены в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2).
6.3.2.3 Transport Layers (транспортные уровни)
Класс EtherNet/IP TransportLayers представляет комбинированные профили для низших четырех уровней OSI модели интеграции сети коммуникаций EtherNet/IP.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 10:
- ENPhysicalLayer (физический уровень EN) определяет характеристики физического уровня;
- EtherNetIPLinkObject определяет характеристики, связанные с конфигурацией и мониторингом канала передачи данных;
- EncapsulationProtocol (протокол инкапсуляции) определяет характеристики, связанные с инкапсуляцией сообщений приложения в TCP/IP;
- порты определяют порты устройства, которые могут направлять сообщения из одной связи на другую связь.
Примечание. Соответствующий EtherNet Link объект связи и TCP/IP объект интерфейса полностью описаны в МЭК 61158-4:2003 (тип 2), опции Encapsulation Protocol (протокол инкапсуляции) подробно изложены в МЭК 61158-6:2003 (тип 2).
6.3.2.4 Network management (управление сетью)
Класс EtherNet/IP NetworkManagement представляет средства наладки конфигурации и характеристик сети в модели интеграции сети коммуникаций EtherNet/IP.
Этот класс далее подразделяется на несколько классов, как показано на рисунке 10:
- NM-EtherNetIPLinkObject, NM-TCPIPInterfaceObject, NM-ConnectionManager и NM-MessageRouter определяют характеристики, связанные с менеджментом класса соответствующих объектов.
6.4. PROFINET
6.4.1. Общие положения
Примечание. Дополнительно к терминологии и нотации UML в ИСО 15745-1:2003 (приложение A) используют нотацию кратности (UML V1.4). Кратность атрибута выражается в квадратных скобках.
6.4.2. Профиль устройства
6.4.2.1 Общие положения
На рисунке 11 показана диаграмма класса профилей устройства GSDML.
| DeviceProfile |
|---|
<>
Рисунок 11. Диаграмма класса профилей устройства GSDML
XML схема, представляющая шаблон профиля устройства GSDML, определена в D.5.2 (Приложение D). Заголовок профиля для профиля устройства GSDML должен иметь следующее содержание:
<ProfileClassID>Device</ProfileClassID><br>
<ISO15745Reference><br>
<ISO15745Part>4</ISO15745Part>
<ISO15745Edition>1</ISO15745Edition>
<ProfileTechnology>GSDML</ProfileTechnology>
</ISO15745Reference>
6.4.2.2 Device Identity (идентификация устройства)
На рисунке 12 показана диаграмма класса DeviceIdentity (идентификация устройства).
┌──────────────────┐
│ DeviceIdentity │
├──────────────────┤
<pre class="legal-pre"> │VendorID │
│DeviceID │</pre>
└──────────────────┘
<>
│
┌────────┴────────┐
<pre class="legal-pre"> 1 │ 1 │
┌─────┴─────┐ ┌─────┴─────┐
│ InfoText │ │ VendorName│
├───────────┤ ├───────────┤
│TextId[1] │ │Value[1] │
└───────────┘ └───────────┘</pre>
Рисунок 12. Диаграмма класса DeviceIdentity
Атрибуты и семантика классов определены в D.4.2 (Приложение D).
6.4.2.3 Device Function (функция устройства)
На рисунке 13 показана диаграмма класса DeviceFunction (функция устройства).
| Device Function |
|---|
<>
1│
| Family | |
| MainFamily[1] ProductFamily[0..1] |
Рисунок 13. Диаграмма класса DeviceFunction
Атрибуты и семантика классов определены в D.4.3.
6.4.2.4 Application Process (прикладной процесс)
6.4.2.4.1 Общие положения
На рисунке 14 приведено описание структуры элемента ApplicationProcess. Классы UML без поля атрибутов подробно определены на отдельной диаграмме. Атрибуты и семантика классов определены в D.4.4 (Приложение D).
a Подробные сведения см. в субдиаграммах.
6.4.2.4.2 DeviceAccessPointItem (точечный элемент доступа к устройству)
На рисунке 15 приведено описание структуры элемента DeviceAccessPointItem. Классы UML без поля атрибута подробно поясняются на отдельной диаграмме. Атрибуты и семантика классов определены в D.4.5 (Приложение D).
┌─────────────────────────────────────────┐
<pre class="legal-pre">│ DeviceAccessPointItem │ <sup>a</sup>
├─────────────────────────────────────────┤ ┌───────────┐
│ID[1] │<>─┬───┤ModuleInfo │
│PhysicalSlots[1] │ │ 1 └───────────┘
│ModuleIdentNumber[1] │ │ ┌───────────────────┐
│MinDeviceInterval[1] │ │ │IOConfigData │
│DNS_CompatibleName[1] │ │ ├───────────────────┤
│AllowedInSlots[0..1] │ ├───┤MaxInputLength[1] │
│FixedInSlots[1] │ │ 1 │MaxOutputLength[1] │
│ObjectUUID_LocalIndex[1] │ │ │MaxDataLength[0..1]│
│ImplementationType[0..1] │ │ └───────────────────┘
│ExtendedAddressAssignmentSupported[0..1] │ │ ┌──────────────┐ ┌────────────────────┐
└─────────────────────────────────────────┘ │ │UseableModules│ │ModuleItemRef │</pre>
├───┼──────────────┤<>────┼────────────────────┤
<pre class="legal-pre"> │ 1 │ │ 1..*│ModuleItemTarget[1] │
│ └──────────────┘ │AllowedInSlots[0..1]│
│ │UsedInSlots[0..1] │
│ │FixedInSlots[0..1] │
│ └────────────────────┘
│ ┌────────────────────┐ <sup>a</sup>
│ │VirtualSubmoduleList│ ┌────────────────────┐</pre>
├───┼────────────────────┤<>──┤VirtualSubmoduleItem│
<pre class="legal-pre"> │ 1 │ │ 1 └────────────────────┘
│ └────────────────────┘
│ ┌──────────┐ ┌────────────────────┐
│ │ Graphics │ │ GraphicItemRef │</pre>
├───┼──────────┤<>─────┼────────────────────┤
<pre class="legal-pre"> │ │ │ │Type[1] │
│ └──────────┘ │GraphicItemTarget[1]│
│0..1 1..* └────────────────────┘
│ ┌────────────────────────────┐
│ │ ApplicationRelations │ ┌────────────────────┐
│ ├────────────────────────────┤ │TimingProperties │
└───┤AR_BlockVersion[1] │<>────┼────────────────────┤
0..1 │IOCR_BlockVersion[1] │ 0..1│SendClock[0..1] │
│AlarmCR_BlockVersion[1] │ │ReductionRatio[0..1]│
│SubmoduleDataBlockVersion[1]│ └────────────────────┘</pre>
└────────────────────────────┘
Рисунок 15. Диаграмма класса DeviceAccessPointItem
6.4.2.4.3. VirtualSubmoduleItem (виртуальный элемент подмодуля)
На рисунке 16 приведено описание элемента VirtualSubmoduleItem. Классы UML без поля атрибута подробно поясняются на отдельной диаграмме. Атрибуты и семантика этих классов определены в D.4.6 (Приложение D).
┌───────────────┐
<pre class="legal-pre"> │ DataItem │
┌───────────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ├───────────────┤
│ VirtualSubmoduleItem │ │ IOData │ │ Input │ │DataType[1] │
├───────────────────────┤<>─┬────┼─────────────────┤<>─┬────┼─────────────────┤<>────┤Length[0..1] │
│ID[1] │ │ 1 │IOPS_Length[0..1]│ │0..1│Consistency[0..1]│ 1..*│UseAsBits[0..1]│
│SubmoduleIdentNumber[1]│ │ │IOCS_Length[0..1]│ │ └─────────────────┘ │TextId[1] │
└───────────────────────┘ │ └─────────────────┘ │ └───────────────┘
│ │ ┌───────────────┐
│ │ │ DataItem │
│ │ ┌─────────────────┐ ├───────────────┤
│ │ │ Output │ │DataType[1] │
│ └───┼─────────────────┤<>────┤Length[0..1] │
│ 0..1│Consistency[0..1]│ 1..*│UseAsBits[0..1]│
│ <sup>a</sup> └─────────────────┘ │TextId[1] │
│ ┌─────────────────┐ └───────────────┘
├────┤ RecordDataList │</pre>
│0..1└─────────────────┘
<pre class="legal-pre"> │ <sup>a</sup>
│ ┌─────────────────┐
├────┤ ModuleInfo │ ┌────────────────────┐
│0..1└─────────────────┘ │ GraphicItemRef │
│ ┌─────────────────┐ ├────────────────────┤
│ │ Graphics │ │Type[1] │</pre>
└────┼─────────────────┤<>────┤GraphicItemTarget[1]│
0..1│ │ 1..*└────────────────────┘
└─────────────────┘
Рисунок 16. Диаграмма класса PROFINET VirtualSubmoduleItem
6.4.2.4.4. RecordDataList (список записи данных)
На рисунке 17 дано описание диаграммы элемента RecordDataList. Атрибуты и семантика классов определены в D.4.7 (Приложение D).
<pre class="legal-pre"> ┌────────────────┐ ┌───────────┐
│ RecordDataList │ │ Name │
├────────────────┤ ┌────────┼───────────┤
│ │ │ 1 │ TextId[1] │
└────────────────┘ │ └───────────┘</pre>
<> │ ┌────────────────┐
<pre class="legal-pre"> 0..* │ │ │ Const │
┌───────────┴───────────┐ ├────────┼────────────────┤
│ParameterRecordDataItem│ │ 0..*│ByteOffset[0..1]│
├───────────────────────┤ │ │Data[1] │
│Index[1] │<>─────────┤ └────────────────┘
│Length[1] │ │ ┌──────────────────────┐
│TransferSequence[0..1] │ │ │ Ref │
└───────────────────────┘ │ ├──────────────────────┤
│ │ValueItemTarget[0..1] │
│ │ByteOffset[1] │
│ │BitOffset[0..1] │
└────────┤BitLength[0..1] │
0..*│DataType[1] │
│DefaultValue[1] │
│AllowedValues[0..1] │
│Changeable[0..1] │
│Visible[0..1] │
│TextId[1] │</pre>
└──────────────────────┘
Рисунок 17. Диаграмма класса PROFINET RecordDataList
6.4.2.4.5. ModuleInfo (информационный модуль)
На рисунке 18 дано описание диаграммы элемента ModuleInfo. Атрибуты и семантика этих классов определены в D.4.8 (Приложение D).
┌─────────────────────┐
│ ModuleInfo │
├─────────────────────┤
│CategoryRef[0..1] │
│SubCategory1Ref[0..1]│
└─────────────────────┘
<>
| Name | |
| 1 | TextId[1] |
| InfoText | |
| 1 | TextId[1] |
| VendorName | |
| 0..1 | Value[1] |
| OrderNumber | |
| 0..1 | Value[1] |
| HardwareRelease | |
| 0..1 | Value[1] |
| SoftwareRelease | |
| 0..1 | Value[1] |
| Family | |
| 0..1 | MainFamily[1] ProductFamily[0..1 |
Рисунок 18. Диаграмма класса PROFINET ModuleInfo
6.4.3. Профиль сети коммуникаций
На рисунке 19 показана диаграмма класса профилей коммуникационной сети GSDML.
| CommNetworkProfile |
|---|
<>
| ApplicationLayers | |
| 1 | |
| TransportLayers | |
| 1 | |
Рисунок 19. Диаграмма класса профилей коммуникационной сети PROFINET
Примечание. В GSDML классы профилей коммуникационной сети пустые. Причина этого состоит в том, что варианты характеристик коммуникаций устройства PROFINET не предоставлены.
XML схема, представляющая шаблон профиля коммуникационной сети GSDML, определена в D.5.3 (Приложение D).
(обязательное)
A.1. Общие положения
Верхние уровни ADS-net основаны на сети Автономной децентрализованной системы (ADS-net). Этот протокол моделирует все коммуникации и обмен сообщениями, имеющими место при взаимосвязях производитель-потребитель.
ADS-net предоставляет доступ ко всем данным конфигурации, информации о статусе и параметрам рабочего цикла узла и/или системы.
A.2. Описание шаблона профиля устройства ADS-net
A.2.1. Общие положения
Файлы XML профиля устройства должны соответствовать XML схеме профиля устройства, установленной в A.2.3.
Содержание этой XML схемы выведено исходя из диаграмм класса профиля устройства, показанных в 6.1.1, и расширено дополнительными элементами, позволяющими дать полное описание требований и возможностей сети коммуникаций.
A.2.2. Семантика элементов схемы XML
A.2.2.1. DeviceIdentity (идентичность устройства)
Семантика элемента DeviceIdentity определена в таблице A.1. Эти элементы используются в среде рабочего цикла ADS-net в целях предоставления информации для полной идентификации устройства.
Более подробные данные о семантике каждого атрибута содержатся в [4].
A.2.2.2. DeviceManager (менеджер устройства)
Семантика субэлементов DeviceManager-Attributes элемента DeviceManager определена в таблице A.2. Эти субэлементы используются в среде рабочего цикла ADS-net.
Элементы DeviceManager-Attributes
| Элементы | Описание и семантика |
|---|---|
| DeviceState (устройство состояние) | Состояние устройства |
A.2.2.3. DeviceFunction (функция устройства)
Семантика субэлементов DeviceFunction-Attributes элемента DeviceFunction определена в таблице A.3. Эти субэлементы используются в среде рабочего цикла ADS-net.
Элементы DeviceFunction-Attributes
Более подробные сведения о семантике каждого атрибута см. в [4].
A.2.2.4. ApplicationProcess (прикладной процесс)
Семантика субэлементов DeviceProcess-Attributes элемента DeviceProcess определена в таблице A.4.
Элементы DeviceProcess-Attributes
Более подробные сведения о семантике каждого атрибута см. в [4].
A.2.3. ADS-net_Device_Profile.xsd
A.3. Описание шаблона профиля коммуникационной сети ADS-net
Файлы XML профиля коммуникационной сети должны соответствовать XML схеме профиля коммуникационной сети, установленной в A.3.3.
Содержание XML схемы выводится из диаграмм класса профиля сети коммуникаций, показанных в 6.1.2, расширенного дополнительными элементами, позволяющими дать полное описание требований или возможностей коммуникационной сети.
A.3.2. Семантика элементов XML схемы
A.3.2.1. ApplicationLayers (прикладные уровни)
A.3.2.1.1. DataField (поле данных)
Данный элемент устанавливает поддерживаемые атрибуты варианта, используемые для контроля поля данных.
DataField соответствует домену, где подсистемы (т.е. узловые компьютеры или программы приложения) совместно используют информацию путем обмена сообщениями между равноправными устройствами. Эти сообщения имеют уникальную идентификацию в поле данных. Узловые компьютеры могут совместно использовать информацию с помощью указания номера поля данных в виде части идентификатора сообщения. Одно поле данных создается для адреса сети или подсети для коммуникаций между узловыми компьютерами или создается в памяти для коммуникаций между программами приложения в узловом компьютере.
Поле данных имеет уникальную идентификацию с помощью относящегося к нему Номера Поля Данных (Data Field Number — DFNO). Уникальное значение DFNO присвоено всем полям данных в системе в диапазоне от 1 до 255. DFNO, равное 0, зарезервировано для коммуникаций внутри текущего узла.
Семантика субэлементов DataField-Attributes элемента DataField определена в таблице A.5.
Более подробные сведения о семантике каждого атрибута см. в [4].
A.3.2.1.1.2. AliveNotification (уведомление о существовании)
Данный элемент устанавливает атрибуты, используемые для проверки нормального состояния узлового компьютера.
Более подробные сведения о семантике каждого атрибута см. в [4].
A.3.2.1.1.3. ErrorNotification (уведомление об ошибке)
Данный элемент устанавливает атрибуты, используемые для проверки ошибок узлового компьютера.
Семантика элемента ErrorNotification определена в таблице A.7.
Более подробные сведения о семантике каждого атрибута см. в [4].
A.3.2.1.2. MessageSelection (выбор сообщений)
Данный элемент устанавливает атрибуты, используемые при обмене сообщениями в ADS-net.
Сообщение идентифицируется уникальным образом Кодом Транзакции (TCD). Передатчик посылает сообщение, ассоциированное с некоторым TCD, используя многоадресную передачу на группу, принимающую передачу и имеющую установленное поле данных. Узлы в указанной группе приема широковещательной передачи принимают только сообщения, имеющие определенный TCD.
Семантика субэлементов MessageSelection-Attributes элемента MessageSelection определена в таблице A.8.
Элементы MessageSelection-Attributes
Более подробные сведения о семантике каждого описания см. в [4].
A.3.2.2. TransportLayers (транспортные уровни)
A.3.2.2.1. EthernetObject (объект Ethernet)
Данный элемент устанавливает атрибуты Ethernet, используемые в ADS-net.
EthernetObject определяет атрибуты, связанные с конфигурацией и мониторингом канала передачи данных.
Семантика субэлементов EthernetObject-Attributes элемента EthernetObject определена в таблице A.9.
Элементы EthernetObject-Attributes
Данный элемент устанавливает атрибуты UDP/IP, используемые в ADS-net.
Семантика субэлементов UDP-IPObject-Attributes элемента UDP-IPObject определена в таблице A.10.
Элементы UDP-IPObject-Attributes
| Элементы | Описание и семантика |
|---|---|
| IPADDR | IP адрес, описанный в стандартном формате Internet с точкой |
| UDP-IP-MCGs | Семантика этого элемента установлена в таблице A.11 |
| HostName | Имя хоста устройства, соответствующее адресу IP |
| ErrorLog | Список ошибок, возникших на транспортном уровне |
| Элементы | Описание и семантика |
|---|---|
| MegNumber | Номер идентификации многоадресной группы (Десятичная нотация: 0 — 255) |
| PortNumber | Номер порта, используемого многоадресной группой |
Более подробные сведения о семантике каждого атрибута см. в [4].
A.3.2.3. NetworkManagement (управление сетью)
Данный элемент устанавливает атрибуты, используемые для конфигурации сети.
Семантика субэлементов Nm-Configuration-Attributes элемента Nm-Configuration определена в таблице A.12.
Элементы Nm-Configuration-Attributes
Более подробные сведения о семантике каждого описания см. в [4].
A.3.2.3.2. Nm-MessageSelection (выбор Nm-Сообщений)
Данный элемент устанавливает атрибуты, используемые при выборе сообщений.
Семантика субэлементов Nm-MessageSelection-Attributes элемента Nm-MessageSelection определена в таблице A.13.
Элементы Nm-MessageSelection-Attributes
Более подробные сведения о семантике каждого описания см. в [4].
Данный элемент устанавливает атрибуты, используемые для мониторинга характеристик.
Семантика субэлементов Nm-Performance-Attributes элемента Nm-Performance определена в таблице A.14.
Элементы Nm-Performance-Attributes
| Элементы | Описание и семантика |
|---|---|
| MessageTransaction | Число сообщений, посланных и полученных устройством |
Данный элемент определяет атрибуты, используемые для мониторинга отказов.
Семантика субэлементов Nm-Fault-Attributes элемента Nm-Fault определена в таблице A.15.
Более подробные сведения о семантике каждого описания см. в [4].
A.3.3. ADS-net CommNet Profile.xsd
B.1. Описание шаблона профиля устройства
B.1.1. Общие положения
XML схема шаблона профиля устройства, определенная в B.1.5, содержит отображение диаграмм класса профиля устройства, показанных в 6.2.1. Помимо отображенных классов и атрибутов эта схема включает в себя дополнительные элементы, позволяющие дать более полное описание требований и возможностей устройств.
B.1.2. DeviceIdentity (идентичность устройства)
Данный элемент определяет атрибуты и операции объекта DeviceIdentity совместно с дополнительной информацией для полной идентификации устройства.
В таблице B.1 дано описание элементов объекта DeviceType (устройство тип).
B.1.3. DeviceManager (менеджер устройства)
Данный элемент определяет атрибуты и операции объекта DeviceManager совместно с дополнительной информацией по управлению устройством.
B.1.3.2. Объект DeviceIDSpecRev (версия спецификации идентификатора устройства)
В таблице B.2 дано описание элементов объекта DeviceIDSpecRev согласно определению в 6.2.1.3.2.
Элементы объекта DeviceIDSpecRev
| Элементы | Описание и семантика |
|---|---|
| COMVER | Версия DeviceIdentity |
| Дата | Дата определения идентичности |
В таблице B.3 дано описание элементов объекта CommuServiceManager согласно определению в 6.2.1.3.3.
Элементы объекта CommuServiceManager
B.1.3.4. Объект DeviceState (состояние устройства)
В таблице B.4 дано описание элементов объекта DeviceState согласно определению в 6.2.1.3.4.
B.1.4. ApplicationProcess (прикладной процесс)
Данный элемент устанавливает атрибуты и операции объекта ApplicationProcess совместно с дополнительными элементами.
В таблице B.5 дано описание элементов объекта PlantName согласно определению в 6.2.1.5.
| Элементы | Описание и семантика |
|---|---|
| PlantName (УстановкаИмя) | Имя установки или процесса |
B.1.5. Схемы XML шаблона профиля устройства FL-net
B.2. Описание шаблона профиля коммуникационной сети FL-net
B.2.1. Общие положения
XML схема шаблона профиля коммуникационной сети, определенная в B.2.4.5, содержит отображение диаграмм класса профиля коммуникационной сети, показанных на рисунке 7. Помимо отображенных классов и атрибутов она содержит дополнительные элементы, позволяющие дать полное описание требований и возможностей коммуникационной сети.
B.2.2. ApplicationLayers (интерфейс коммуникационной памяти)
B.2.2.1. Объект ComMemoryInterface
В таблице B.6 дано описание элементов объекта ComMemoryInterface согласно определениям в 6.2.2.2.2. Субэлементы ComMemory1AllocationList и ComMemory2AllocationList предоставляют информацию о распределении памяти. Их атрибуты описаны в таблице B.7.
Атрибуты ComMemoryAllocationList
| Элементы | Описание и семантика |
|---|---|
| Размер | Размер данных |
| FieldNumber | Номер поля данных в общей памяти |
B.2.2.2. Объект MessageService (сервис сообщений)
В таблице B.8 дано описание элементов объекта MessageService согласно определению в 6.2.2.2.3.
| Элементы | Описание и семантика |
|---|---|
| NodeNumberList | Список номеров узлов |
| TCDList | Список TCD |
B.2.2.3. Объект ErrorNotification (уведомление об ошибке)
В таблице B.9 дано описание элементов объекта ErrorNotification согласно определению в 6.2.2.2.4.
| Элементы | Описание и семантика |
|---|---|
| ActiveNodeNumberList | Список номеров активных узлов |
| NodeStatus | Статус узла |
B.2.3. TransportLayers (объект на основе Ethernet)
B.2.3.1. Объект EthernetBasedObject
В таблице B.10 дано описание элементов объекта EthernetBasedObject согласно определению в 6.2.2.3.2.
Элементы объекта EthernetBasedObject
В таблице B.11 дано описание элементов объекта UDP-IPObject согласно определению в 6.2.2.3.3.
B.2.4. NetworkManagement (управление сетью)
B.2.4.1. Объект Configuration (конфигурация)
В таблице B.12 дано описание элементов объекта Configuration согласно определению в 6.2.2.4.2.
Элементы объекта Configuration
B.2.4.2. Объект ServiceSelection (выбор сервиса)
В таблице B.13 дано описание элементов объекта ServiceSelection согласно определению в 6.2.2.4.3.
Элементы объекта ServiceSelection
| Элементы | Описание и семантика |
|---|---|
| NM-MessageTypeList | Список типов сообщений |
| NM-TCDList | Список TCD для посылаемых сообщений |
| NM-VendorCodeList | Список кодов продавца |
B.2.4.3. Объект PerformanceManager (менеджер исполнения)
В таблице B.14 дано описание элементов объекта PerformanceManager согласно определению в 6.2.2.4.4.
Элементы объекта PerformanceManager
B.2.4.4. Объект FaultManager (менеджер ошибок)
В таблице B.15 дано описание элементов объекта FaultManager согласно определению в 6.2.2.4.5.
B.2.4.5. Схема XML:FL-net_CommNet_Profile.xsd
C.1. Общие положения
Верхние уровни сети EtherNet/IP основаны на общем промышленном протоколе CIP. Этот протокол моделирует все сущности коммуникаций и приложений в виде объектов. Специальные сервисы CIP по запросу сообщений должны выполняться на соответствующих экземплярах объектов (или их атрибутах). Эта схема предоставляет явный доступ ко всем данным параметров конфигурации, состояния и рабочего цикла в узле. В то же время соединения ввода/вывода допускают прямой обмен с базой данных ввода/вывода без промежуточной обработки. В обоих случаях все ссылки на данные внутри устройства указываются с помощью путей CIP, т.е. потока октетной строки, которая определяет экземпляр объекта приложения, атрибут и/или конечную точку соединения.
Для дистанционной конфигурации устройства доступны многие опции с помощью интерфейса коммуникаций CIP, включая следующее:
- сохраненную информацию об устройстве в печатном или электронном формате;
- выделенные объекты параметров (Parameter Objects), которые предоставляют известный общедоступный интерфейс для индивидуальных значений данных конфигурации/параметров и могут также вводить дополнительную информацию о конфигурации, например дескриптивный текст, тип данных, предельные значения данных и значения по умолчанию;
- выделенное объединение конфигураций (Configuration Assembly), что допускает групповое сохранение и загрузку данных конфигурации путем объединения в группы отдельных значений данных по конфигурации/параметрам;
Инструменты конфигурации, имеющиеся в настоящее время в основанных на CIP устройствах, используют специально форматированный файл ASCII, называемый электронным бланком данных (EDS), который предоставляет следующее:
- описание данных устройства, которые могут быть доступны через сеть (например, конфигурируемые параметры);
EDS допускает применение инструмента конфигурации, автоматически выполняющего процесс конфигурации устройства. Требования EDS обеспечивают открытый, последовательный и совместимый подход к выполнению конфигурации устройства в среде CIP.
Информация EDS в высокой степени аналогична информации, требующейся в профилях как устройств, так и сетей коммуникаций, в связи с чем в следующих подразделах определяется формат для:
- шаблонов профиля сети коммуникаций и устройства согласно определению в ИСО 15745-1;
- инкапсуляции ранее принятых файлов EDS в шаблоны комплекса стандартов ИСО 15745 («оболочки»);
- ранее принятого EDS, включая общую семантическую информацию.
Примечание. EtherNet/IP EDS некоторого устройства может быть получен из содержания соответствующих файлов XML профиля устройства и коммуникационной сети путем использования бланков подходящего стиля.
C.2. Описание шаблона профиля устройства
C.2.1. Описание шаблона профиля устройства на основе XML
Файлы XML профиля устройства должны соответствовать XML схеме профиля устройства, установленной в C.2.1.3.3.
Содержание этой XML схемы выводится из диаграмм класса профиля устройства, показанных в 6.3.1, расширенного с помощью дополнительных элементов, что позволяет дать полное описание требований и возможностей устройства.
Этот основной элемент ассоциируется с набором атрибутов, которые предоставляют дополнительную информацию относительно файла профиля.
Семантика этих атрибутов установлена в C.4.1.4.2.
C.2.1.2.2. DeviceIdentity (идентичность устройства)
Этот элемент устанавливает поддерживаемые атрибуты и операции сущности Identity Object [см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)] совместно с дополнительной информацией для полной идентификации устройства. Когда это целесообразно, он также показывает фактические значения атрибутов сущности.
Семантика субэлементов DeviceIdentity_InstanceAttributes элемента DeviceIdentity определена в таблице C.1.
Элементы DeviceIdentity_InstanceAttributes
| Элементы XML схемы | Атрибуты объекта | Семантика |
|---|---|---|
| SpecificationConformance | Нет | Строка, определяющая ссылочную версию спецификаций EtherNet/IP |
| VendCode, ProdType, ProdCode, ProdRevision | Да | См. C.4.1.4.3 |
| VendName, ProdTypeStr, ProdName, Catalog, Icon, ExcludeFromAdapterRackConnection | Нет | См. C.4.1.4.3 |
| Status, SerialNumber | Да | Не применяется |
| State, ConfigurationConsistencyValue, HeartbeatInterval | Да | Не применяется |
| DeviceClassification | Нет | См. C.4.1.4.4 и C.4.2.2.1 |
C.2.1.2.3. DeviceManager (менеджер устройства)
Данный элемент определяет поддерживаемые атрибуты и операции класса объекта Identity Object [см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)] совместно с дополнительной информацией по управлению устройством. Когда это целесообразно, он также показывает фактические значения атрибутов сущности.
Семантика Модульного (Modular) субэлемента элемента DeviceManager установлена в C.4.1.5.2.
Содержание этого элемента в данном документе подробно не рассматривается.
Данный элемент определяет поддерживаемые атрибуты и операции класса и варианта объекта Assembly Object [см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)] совместно с описанием отдельных вариантов.
Семантика субэлементов Assem, ProxyAssem и ProxiedAssem элемента Assembly определена в C.4.1.4.8 и C.4.1.5.3.2.
C.2.1.2.5.2. Parameter (параметр)
Данный элемент устанавливает поддерживаемые атрибуты и операции класса и варианта объекта Parameter Object совместно с описанием отдельных вариантов.
Семантика субэлемента Parameter_ClassAttributes элемента Parameter определена в C.4.1.4.5.
Семантика субэлементов Param, ProxyParam и ProxiedParam элемента Parameter определена в C.4.1.4.6 и C.4.1.5.3.1.
C.2.1.2.5.3. ParameterGroup (группа параметров)
Данный элемент устанавливает группы связанных параметров для специальных целей.
Семантика субэлемента Group элемента ParameterGroup определена в C.4.1.4.7.
C.2.1.3.1. MasterTemplateTypes.xsd
Примечание. Данная XML схема содержит все стили, определенные как часть шаблона ведущего устройства в ИСО 15745-1:2003.
Примечание. Данная XML схема определяет пункты XML схемы (например, типы данных, типы элементов, группы атрибутов), используемые в других XML схемах.
C.2.1.3.3. CIP_Device_Profile.xsd
Примечание. Данная XML схема включает файлы «MasterTemplateTypes.xsd» (см. C.2.1.3.1) и «CIPDataTypes.xsd» (см. C.2.1.3.2).
C.2.2. Описание шаблона профиля устройства — инкапсуляция XML файлов EDS
Файлы XML профиля устройства, используемые для инкапсуляции файлов EDS, должны соответствовать XML схеме профиля устройства, определенной в C.2.2.2.
Семантика субэлементов элемента ExternalProfileHandle, использованных для ссылки на существующий файл EDS, определена в таблице C.2. В зависимости от значения атрибута WrapperReference ссылка на файл EDS будет осуществляться с использованием элементов идентификации либо в самом файле EDS, либо в продукте, описанном этим EDS.
Примечание 1. Выбор необходимых элементов идентификации будет зависеть от ожидаемого использования файла оболочки.
Элементы ExternalProfileHandle
| Элементы XML схемы | WrapperReference = FILEINFO | WrapperReference = DEVICEINFO |
| ProfileIdentification | Текст описания файла EDS a | ID Поставщика, Тип Устройства, Код Продукта b |
| ProfileRevision | Версия EDS a | Версия Продукта b |
| ProfileLocation | EDS HomeURL a | Имя Файла в виде иконки b |
| a Более подробно см. в C.4.1.4.2. | ||
| b Более подробно см. в C.4.1.4.3. | ||
Если они присутствуют, элементы DeviceIdentity, DeviceManager, DeviceFunction и ApplicationProcess должны быть совместимы с форматами, определенными в C.2.1.3.3.
Примечание 2. Это может быть использовано на этапе перехода от ранее принятого формата EDS к полному формату XML.
C.2.2.2. Схема XML: EDS_Device_Profile_wrapper.xsd
Примечание. Эта XML схема включает в себя файл «MasterTemplateTypes.xsd» (см. C.2.1.3.1).
C.3. Описание шаблона профиля коммуникационной сети
C.3.1. Описание шаблона профиля коммуникационной сети — на основе XML
Файлы XML профиля коммуникационной сети должны соответствовать XML схеме профиля коммуникационной сети, установленной в C.3.1.2.
Содержание этой XML схемы выводится из диаграмм класса профилей коммуникационной сети, показанных в 6.3.2, расширенного с помощью дополнительных элементов, что позволяет дать полное описание требований и возможностей сети коммуникаций.
C.3.1.2. Семантика элементов XML схемы
C.3.1.2.1. ProfileBody (тело профиля)
Этот основной элемент ассоциируется с набором атрибутов, которые предоставляют дополнительную информацию относительно файла профиля.
Семантика этих атрибутов установлена в C.4.1.4.2.
C.3.1.2.2. ApplicationLayers (прикладные уровни)
C.3.1.2.2.1. ConnectionManager (менеджер соединений)
Данный элемент устанавливает поддерживаемые атрибуты и операции сущности объекта Connection Manager Object [см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)] совместно с описанием отдельных вариантов соединения.
Семантика субэлементов Connection, ProxyConnect и ProxiedConnect элемента ConnectionDescriptions определена в C.4.1.4.9 и C.4.1.5.3.3.
C.3.1.2.2.2. MessageRouter (маршрутизатор сообщений)
Данный элемент устанавливает поддерживаемые атрибуты и операции сущности объекта Message Router Object [см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)].
C.3.1.2.3. TransportLayers (транспортные уровни)
C.3.1.2.3.1. ENPhysicalLayer (EN физический уровень)
Данный элемент идентифицирует физический уровень. Содержание этого элемента в настоящем стандарте подробно не рассмотрено.
C.3.1.2.3.2. EtherNetIPLinkObject
Данный элемент определяет поддерживаемые атрибуты и операции сущности объекта EtherNet/IP Link Object [см. МЭК 61158-4:2003 (тип 2)].
C.3.1.2.3.3. TCPIPInterfaceObject
Данный элемент определяет поддерживаемые атрибуты и операции сущности объекта TCP/IP Interface Object [см. МЭК 61158-4:2003 (тип 2)].
C.3.1.2.3.4. EncapsulationProtocol (протокол инкапсуляции)
Данный элемент определяет поддерживаемые атрибуты и операции, ассоциированные с инкапсуляцией сообщений приложения в TCP/IP [см. МЭК 61158-6:2003 (тип 2)].
Данный элемент идентифицирует порты устройства, позволяющие направлять сообщения из одного канала связи в другой канал связи.
Семантика субэлемента Port элемента Ports определена в C.4.1.4.10 и C.4.2.2.2.
C.3.1.2.4. NetworkManagement (управление сетью)
C.3.1.2.4.1. NM-EtherNetIPLinkObject
Данный элемент определяет поддерживаемые атрибуты и операции класса объекта EtherNet/IP Link Object [см. МЭК 61158-4:2003 (тип 2)].
C.3.1.2.4.2. NM-TCPIPInterfaceObject
Данный элемент определяет поддерживаемые атрибуты и операции класса объекта TCP/IP Interface Object [см. МЭК 61158-4:2003 (тип 2)].
C.3.1.2.4.3. NM-ConnectionManager (NM-Менеджер соединений)
Данный элемент определяет поддерживаемые атрибуты и операции класса объекта Connection Manager Object [см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)].
C.3.1.2.4.4. NM-MessageRouter (NM-Маршрутизатор сообщений)
Данный элемент определяет поддерживаемые атрибуты и операции класса объекта Message Router Object [см. МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2)].
C.3.1.3. Схема XML: ENet_CommNet_Profile.xsd
Примечание. Данная XML схема включает в себя файлы «MasterTemplateTypes.xsd» (см. C.2.1.3.1) и «CIPDataTypes.xsd» (см. C.2.1.3.2).
Файлы XML профиля коммуникационной сети, используемые для инкапсуляции файлов EDS, должны соответствовать XML схеме профиля коммуникационной сети, определенной в C.3.2.2.
Семантика субэлементов элемента ExternalProfileHandle, используемых для ссылки на существующий файл EDS, определена в таблице C.2. В зависимости от значения атрибута WrapperReference ссылка на файл EDS будет осуществляться с использованием элементов идентификации либо в самом файле EDS, либо в продукте, описанном этим EDS.
Примечание. Выбор необходимых элементов идентификации будет зависеть от ожидаемого использования файла оболочки.
Примечание. Эта XML схема включает в себя файл «MasterTemplateTypes.xsd» (см. C.2.1.3.1).
C.4. Электронная информационная таблица (EDS)
C.4.1. Общие требования к CIP EDS
C.4.1.1. Общие положения
Настоящий подраздел устанавливает требования к кодировке файла EDS, которые являются общими для всех сетей, основанных на CIP. Требования к кодировке EDS определяют стандартный формат кодировки файла для применения в продуктах CIP независимо от платформы хоста инструмента конфигурации или файловой системы.
В настоящем подразделе термин «файл» относится ко всем распознаваемым форматам файлов, ассоциированным с файловой системой инструмента конфигурации, независимо от среды хранения файлов.
Файл EDS определяется как файл ASCII, который включает в себя представление ASCII объектов в устройстве, к которым имеется доступ из сети (например, Parameter и Assembly), и некоторую дополнительную информацию, требующуюся для поддержки адресации объекта.
C.4.1.2. Содержание EDS
Один файл должен содержать полный EDS. EDS должен состоять из секций. В таблице C.3 представлена сводка данных о структуре секций, которые являются общими для нескольких основанных на CIP сетей, соответствующие принятые разграничители секций и порядок этих секций в EDS.
| Имя секции | Принятый разграничитель | Размещение | Требуемый/Опциональный |
| Описание файла | [File] | 1 | Требуемый |
| Описание устройства | [Device] | 2 | Требуемый |
| Классификация устройства | [Device Classification] | a | Опциональный |
| Класс параметра | [ParamClass] | a | Опциональный |
| Параметры | [Params] | a | Опциональный |
| Группы параметров | [Groups] | a | Опциональный |
| Объединение | [Assembly] | a | Опциональный |
| Характеристики соединения | [Connection Manager] | a | Опциональный |
| Порт | [Port] | a | Опциональный |
| Модульный | [Modular] | a | Опциональный |
| Определяется продавцом | [VendorID_vendorspecifickeyword] | Последний | Опциональный |
| a Размещение этих опциональных групп должно быть только после требуемых групп. | |||
Содержание EDS должно быть организовано следующим образом:
- все файлы EDS должны включать в себя раздел «Описание файла», который должен быть первой секцией файла EDS и должен использовать принятый разграничитель [File];
- все файлы EDS должны включать в себя секцию Описание Устройства, которая должна быть расположена после секции Описание Файла и должна использовать принятый разграничитель [Device];
- опциональные секции, описанные в данной спецификации, могут быть представлены в любом порядке при условии, что в файле EDS отсутствуют ссылки вперед;
- опциональная(ые) секция(и), определяемая(ые) продавцом, должна(ы) использовать принятые разграничители [VendorID_vendorspecifickeyword (ключевое слово поставщика)] согласно C.4.1.2.2.11 и должна(ы) быть помещена(ы) после всех секций, определенных в данной спецификации.
C.4.1.2.2. Правила форматирования EDS
Файл EDS должен состоять из секций, входов, полей, комментариев и пустых пробелов. Настоящий подраздел определяет правила, которые должны выполняться при определении EDS.
C.4.1.2.2.2. Пустой пробел в EDS
Пустой пробел может быть использован в файле EDS, но должен быть проигнорирован всеми интерпретаторами EDS, когда он располагается вне полей и наборов символов в двойных кавычках.
Интерпретатор EDS должен рассматривать указанные ниже символы как символы пустых пробелов. Эти символы, прочитанные интерпретатором, но не кодированные как читаемые человеком символы, означают присутствие в файле пустых пробелов:
- символ пробела;
- новая строка;
- возврат каретки;
- переход на новую строку;
- табуляция, вертикальная или горизонтальная;
- подача страницы;
- маркер конца файла;
- комментарии.
C.4.1.2.2.3. Символы ключевых слов
Все ключевые слова в файле EDS должны состоять из символов ASCII, входящих в следующий список:
- прописные буквы от A до Z;
- строчные буквы от a до z;
- цифры от 0 до 9;
- специальный символ подчеркивания «_»;
- символ пробела.
Пробел должен использоваться только в ключевых словах секций. Пробел может располагаться только внутри имени секции, а множественные пробелы являются ошибкой.
Файл EDS должен быть разделен на требуемые и опциональные секции.
C.4.1.2.2.5. Разграничители секций
Каждая секция EDS должна быть правильно ограничена ключевыми словами в квадратных скобках (принятыми ограничителями). Правильные принятые разграничители должны соответствовать указанным в таблице C.3.
C.4.1.2.2.6. Ключевые слова секций
Ключевое слово секции определяется как текст между начальным ограничителем ключевого слова «[» и конечным ограничителем «]». Символы, предназначенные для использования в ключевых словах секций, определены в C.4.1.2.2.3. Существуют два типа ключевых слов секций — общие и специальные для поставщиков.
Каждая требуемая секция должна быть помещена в требуемом порядке согласно условиям в C.4.1.2. Опциональные секции могут быть пропущены или включены в виде символа-заполнителя без данных. Кроме относящихся к поставщику секций, опциональные секции могут быть помещены в любом порядке. Относящиеся к поставщику секции должны быть в файле EDS на последнем месте.
Каждая секция EDS должна включать в себя один или более входов, начинающихся с ключевого слова входа, за которым следует знак равенства. Значение ключевого слова входа должно иметь общее значение, допуская использование ключевых слов, определенных в одних секциях, в других секциях. Каждый вход должен быть ограничен точкой с запятой. Вход может распространяться на несколько строк, если поля правильно разграничены запятыми.
C.4.1.2.2.9. Ключевые слова входа
Ключевое слово входа должно состоять из уникальной последовательности символов ключевого слова согласно определениям в C.4.1.2.2.3. Существуют два типа ключевых слов входа — общие и относящиеся к поставщику.
C.4.1.2.2.10. Общее ключевое слово
Общее ключевое слово должно быть всегда определено в спецификации CIP ответственными ассоциациями поставщиков. Общее ключевое слово никогда не должно начинаться с цифрового разряда.
C.4.1.2.2.11. Относящиеся к поставщику ключевые слова
Ключевые слова могут относиться к поставщику. Эти ключевые слова должны начинаться с идентификатора поставщика (Vendor ID) компании с последующим дополнением после символа подчеркивания (VendorID_VendorSpecificKeyword). VendorID должен быть представлен в виде десятичных цифр, без нулей на первых позициях. Каждый поставщик несет ответственность за поддержание и документальное оформление относящихся к поставщику ключевых слов.
Каждый вход должен включать в себя одно или более полей. Все поля должны быть разграничены запятыми. Значение поля (полей) должно зависеть от контекста секции. Поля входа либо обязательны, либо опциональны в соответствии с определениями в данной спецификации. Пустой пробел или отсутствие символа между запятыми должны использоваться для непредоставленных опциональных полей. Точка с запятой может быть использована для указания отсутствия последующих опциональных полей. Элемент «Номер Поля» должен указывать положение поля во входе. Поля должны быть пронумерованы слева направо (или сверху вниз), начиная с номера 1.
C.4.1.2.2.13. Ключевые слова поля
Ключевое слово поля должно состоять из уникальной последовательности символов ключевого слова согласно определениям в C.4.1.2.2.3. Существуют два типа ключевых слов поля — общие и относящиеся к поставщику.
C.4.1.2.2.14. Составные поля данных
Некоторые поля входа должны быть определены с помощью данных, которые не могут быть установлены одним значением между разграничителями в виде запятых. Возможность дальнейшего разграничения поля входа определяется путем использования одного или более набора соответствующих символов скобок «{» и «}». Содержание между символами скобок должно рассматриваться как один объект или вход. Содержание может быть сгруппировано с помощью нескольких скобок.
Комментарии должны быть разграничены с помощью символа доллара ($) и символа новой строки. Интерпретатор EDS должен рассматривать все символы между разграничителями комментария как пустой пробел. Разграничитель комментария $, появляющийся внутри поля или набора символов в двойных кавычках, не должен рассматриваться как разграничитель комментария.
Пример - Некоторые примеры комментариев приведены ниже:
\$ Это правильная строка комментария1, 2, 3; \$ Это правильный комментарий
$ Комментарий не может распространяться
C.4.1.2.2.16. Пример структуры форматирования EDS
На рисунке C.1 приведен пример, поясняющий структуру EDS.
| [имя секции] | |
| \$ Комментарий — распространяется | |
| до конца строки | |
| Entry1=Field1, Field2, Field3; | \$ Весь вход на одной строке |
| Entry2=Field1, Field2, Field3, | \$ Весь вход на одной строке |
| Field4; | |
| Entry3= | \$ Вход на нескольких строках |
| Field1, | \$ Поле 1 |
| Field2, | \$ Поле 2 |
| Field3; | \$ Поле 3 |
| Entry4= | \$ Комбинация |
| Field1, Field2, | \$ Поля 1 и 2 на одной строке |
| Field3, | \$ Поле 3 |
| Field4; | \$ Поле 4 |
| Entry5= 1, | \$ Поле 1 устанавливает значение 1 |
| {1,2,3}; | \$ Поле 2 устанавливает набор или \$ структуру с тремя значениями |
| Entry6= {44, {22,33,11}}; | \$ Вход 6 устанавливает одно поле \$ Поле содержит два набора данных \$ Первый набор соответствует одному |
| значению 44 | |
| \$ Второй набор содержит три значения | |
| 65535_Entry= | \$ Относящийся к поставщику вход для |
| Field1, Field2; | \$ Vendor_ID 65535 с двумя полями |
Никаких соглашений по наименованию файлов EDS на дисках не существует, за исключением файлов в среде DOS/Windows: эти файлы должны иметь суффикс «.EDS», добавляемый к имени файла.
C.4.1.3. Требования к кодировке данных EDS
Настоящий подраздел устанавливает требования по кодировке данных в файлах EDS.
Информация, содержащаяся в файле EDS, может представлять собой атрибуты сущностей объектов в подлежащем конфигурации устройстве. Все данные в файле EDS должны быть текстом ASCII, тогда как класс объекта и атрибуты экземпляров объекта необязательно должны быть в виде ASCII (существующие типы данных определены в спецификации CIP). В связи с этим может быть необходимо преобразование данных в файле EDS и атрибутах объекта, это преобразование установлено в следующих подразделах.
Простейшие типы данных, установленные в спецификации CIP, используются также для других элементов EDS, однако значение преобразуется согласно описанию в следующих разделах (см. C.4.1.3.3 - C.4.1.3.10).
Некоторые типы данных используются только в файлах EDS (см. C.4.1.3.11 - C.4.1.3.14).
C.4.1.3.2. Соглашение о файлах с символами ASCII
Все данные в EDS должны быть кодированы с использованием 8-битных символов ASCII, где все ссылки на «символы ASCII» означают 8-битный формат символов ASCII (согласно определению в таблицах 1 и 2, ряд 00, ИСО/МЭК 10646-1:2000). Символы, которые не могут быть представлены на терминале ANSI, не должны использоваться в именах идентификаторов или в представлении данных. Действующие значения символов ASCII должны включать в себя новую строку, табуляцию и десятичные цифры от 32 до 126.
C.4.1.3.3. Соглашение о строке символов — EDS_Char_Array
Все строковые данные в файле EDS должны быть строками символов фиксированной длины, без символов конца строки, и должны быть заключены в двойные кавычки (тип данных EDS_Char_Array).
Существуют две формы преобразования строковых данных. Символы, содержащиеся между двойными кавычками, должны преобразовываться в 8-битные символы ASCII. Символы, содержащиеся между двойными кавычками, которым предшествует прописная буква L, должны преобразовываться в символы UNICODE (16-битные).
Пример 1 — «Эти результаты в строке составлены из 8-битных символов».
Пример 2 — L «Строка символов UNICODE, включая греческий символ Pi\u03C0».
Примечание. Текст \u03C0 определяет единичный 16-битный символ, значение которого — 03C0. В наборе символов UNICODE он расположен в таблице 9, ряд 3, основной греческий — символ для строчного «Pi». Описание последовательностей переключения кода символов дано в C.4.1.3.3.5.
C.4.1.3.3.2. Обработка недостаточных символов в поле строки
Интерпретатор EDS должен использовать выравнивание по правому знаку или разряду символов в поле и заполнять все неуказанные символы начальными пробелами (ASCII 0x20) на всю оставшуюся длину строки.
Пример - Если параметр имеет максимальную длину строки 8 и получает строку «123AB», эта строка интерпретируется как «~~~123AB», где символы тильды (~) представляют пробелы.
C.4.1.3.3.3. Обработка избыточных символов в поле строки
Если данное поле строки содержит слишком много символов, интерпретатор EDS должен обрезать символы слева направо.
Пример - Если параметр имеет максимальную длину строки 8 и получает строку «123ABCDEFG», строка обрезается и интерпретируется как «123ABCDE».
Множественные строки, не содержащие запятых, должны быть сцеплены (соединены).
Строка: "ABC" "123" "XYZ" интерпретируется как: "ABC123XYZ"
Строки могут также быть представлены в виде отдельных строк.
«ABC» $ это комментарий «123» «XYZ» Интерпретируются как: «ABC123XYZ»
В случае строки UNICODE (длинная строка) только перед первым знаком двойных кавычек должна быть прописная буква L.
Пример 3 — L «ABC» «123» «XYZ» то же самое, что и L «ABC123XYZ».
C.4.1.3.3.5. Управляющие последовательности строки
Интерпретатор EDS должен распознавать все управляющие последовательности, перечисленные в таблице C.4. Интерпретация зависит от приложения.
Управляющие последовательности строки
Если встречаются последовательности, не перечисленные выше, интерпретирующее устройство должно отбраковать всю строку и показать ошибку. Файлы EDS должны содержать только управляющие последовательности, определенные в таблице C.4.
C.4.1.3.4. Соглашение о строке ASCII (STRING, SHORT_STRING, STRING2)
Все типы строковых данных (STRING, SHORT_STRING, STRING2), используемые в атрибутах объектов, должны быть преобразованы в EDS_Char_Array в файле EDS.
Тип данных CIP International String (STRINGI) кодируется в файле EDS как сложное представление данных. Полное содержание входа STRINGI должно быть заключено в две скобки. За рядом элементов языка, определенных как USINT, должны следовать определения элементов языка, каждое из которых заключено в пару скобок и отделено запятой. Каждый элемент языка входа STRINGI должен быть задан в виде четырех полей. Первое поле (выбор языка) должно быть выражено в виде строки фиксированной длины из точно трех символов, заключенных в маркеры двойных кавычек — код языка согласно определению в ИСО 639-2/Т. Тип строковых данных должен быть выражен с использованием кода типа данных согласно определению в спецификации CIP для STRING, STRING2, STRINGN или SHORT_STRING. Выбор набора символов должен быть выражен в виде UINT согласно определению в IANA MIB Принтерных Кодах (RFC 1759). Часть содержания строки, относящаяся к элементу языка, должна быть выражена в виде строки или длинной строки.
Далее представлен вход STRINGI с тремя языками:
Field1={3, {«eng», 0xD0, 4, «Это строка ASCII на английском языке»}, {«spa», 0xD5, 1000, L « Espaсoles palabras»}, $ «Испанские слова» $ использующие UNICODE {«deu», 0xD0, 4, «Spanische Wörter auf Deutsch»} $ «Испанские слова на немецком» };
Тип данных CIP EPATH, используемый, в частности, для определения строк путей CIP, должен быть кодирован в файлах EDS с использованием базового формата, определенного в ИСО 15745-4 для EDS_Char_Array. Кроме того, содержание строк для путей CIP или других данных EPATH должно состоять из групп, состоящих из двух прилегающих шестнадцатеричных символов, разделенных пробелами. Могут быть использованы символы как верхнего, так и нижнего регистра.
Пример 2 — «20 05 24 02 30 04»
C.4.1.3.7. Соглашение о беззнаковых целых числах ASCII (USINT, UINT, UDINT, ULINT)
Типы данных беззнаковых целых чисел представляют значения положительных целых чисел. Данные беззнаковых целых чисел должны вводиться либо в десятичной, либо в шестнадцатеричной нотации при отсутствии пробелов или запятых между символами. Если шестнадцатеричная нотация используется для представления символов беззнаковых целых чисел, перед символами беззнаковых целых чисел должна быть поставлена последовательность из двух символов 0x без пустых пробелов.
Диапазон принятых данных USINT указан ниже:
Десятичная нотация: 0 до 255 Шестнадцатеричная нотация: 0x0 до 0xFF
Диапазон принятых данных UINT указан ниже:
Десятичная нотация: 0 до 65535 Шестнадцатеричная нотация: 0x0 до 0xFFFF
Диапазон принятых данных UDINT указан ниже:
Десятичная нотация: 0 до 4294967295 Шестнадцатеричная нотация: 0x0 до 0xFFFFFFFF
Диапазон принятых данных ULINT указан ниже:
Десятичная нотация: 0 до 18446744073709551615
Шестнадцатеричная нотация: 0x0 до 0xFFFFFFFFFFFFFFFF
Ведущие нули использовать в десятичной нотации нельзя, но их можно использовать в шестнадцатеричной нотации. В шестнадцатеричной нотации допускается использование как прописных, так и строчных символов, и полное число символов должно быть ограничено 10 (0x плюс 8) или 18 (0x плюс 16) в случае типа ULINT.
Пример - Десятичное значение UINT 254 может быть представлено как 254 (десятичное), или как 0xFE (шестнадцатеричное) или как 0x000000FE (шестнадцатеричное), но 0254 (десятичное) и 0x0000000FE (шестнадцатеричное) являются неправильными.
C.4.1.3.8. Соглашение о целых числах ASCII со знаком (SINT, INT, DINT, LINT)
Типы данных SINT, INT, DINT и LINT представляют значения целых чисел со знаком. Данные целых чисел со знаком должны вводиться либо в десятичной, либо в шестнадцатеричной нотации при отсутствии пустых пробелов или запятых между символами. Если шестнадцатеричная нотация используется для представления символов целых чисел со знаком, перед символами целых значений должна быть поставлена последовательность двух символов 0x при отсутствии пустых пробелов.
Диапазон принятых данных SINT указан ниже:
Десятичная нотация: -128 до 127 Шестнадцатеричная нотация: 0x80 до 0x7F
Диапазон принятых данных INT указан ниже:
Десятичная нотация: -32768 до 32767 Шестнадцатеричная нотация: 0x80 до 0x7FFF
Диапазон принятых данных DINT указан ниже:
Десятичная нотация: -2147483648 до 2147483647 Шестнадцатеричная нотация: 0x80000000 до 0x7FFFFFFF
Диапазон принятых данных LINT указан ниже:
Десятичная нотация: -9223372036854775808 до 9223372036854775807
Шестнадцатеричная нотация: 0x8000000000000000 до 0x7FFFFFFFFFFFFFFF
Ведущие нули использовать в десятичной нотации нельзя, но их можно использовать в шестнадцатеричной нотации. В шестнадцатеричной нотации допускается использование как прописных, так и строчных символов, и полное число символов должно быть ограничено 10 (0x плюс 8) или 18 (0x плюс 16) в случае типа LINT.
Пример - Десятичное значение INT 254 может быть представлено как 254 (десятичное), или как 0xFE (шестнадцатеричное), или как 0x000000FE (шестнадцатеричное), но 0254 (десятичное) и 0x0000000FE (шестнадцатеричное) являются неправильными.
C.4.1.3.9. Соглашение о словах ASCII (BYTE, WORD, DWORD, LWORD)
Типы данных BYTE, WORD, DWORD и LWORD представляют величины с побитовой адресацией. Эти величины считаются дискретными значениями позиции двоичного разряда и не предназначены для представления целых величин со знаком или без знака. Однако эти величины должны для удобства вводиться либо в десятичной, либо в шестнадцатеричной, либо в двоичной нотации без пустых пробелов или запятых между символами. Если для представления символов величин используется шестнадцатеричная (соответственно двоичная) нотация, перед символами значения должна быть поставлена последовательность из двух символов 0x (соответственно 0b) при отсутствии пробелов.
Диапазон принятых данных BYTE указан ниже:
Десятичная нотация: 0 до 255 Шестнадцатеричная нотация: 0x0 до 0xFF Двоичная нотация: 0b00000000 до 0b11111111
Диапазон принятых данных WORD указан ниже:
Десятичная нотация: 0 до 65535 Шестнадцатеричная нотация: 0x0 до 0xFFFF Двоичная нотация: 0b0000000000000000 до 0b1111111111111111
Диапазон принятых данных DWORD указан ниже:
Десятичная нотация: 0 до 4294967295 Шестнадцатеричная нотация: 0x0 до 0xFFFFFFFF Двоичная нотация: 0b00000000000000000000000000000000 до
0b11111111111111111111111111111111
Диапазон принятых данных LWORD указан ниже:
Десятичная нотация: 0 до 18446744073709551615 Шестнадцатеричная нотация: 0x0 до 0xFFFFFFFFFFFFFFFF
Двоичная нотация: 0b0000000000000000000000000000000000000000000000000000000000000000 до 0b1111111111111111111111111111111111111111111111111111111111111111
Ведущие нули использовать в десятичной нотации нельзя, но их можно использовать в шестнадцатеричной и двоичной нотации. В шестнадцатеричной нотации допускается использование как прописных, так и строчных символов, и полное число символов должно быть ограничено 10 (0x плюс 8) или 18 (0x плюс 16) в случае типа LWORD.
Пример - Десятичное значение WORD 254 может быть представлено как 254 (десятичное), или как 0xFE (шестнадцатеричное), или как 0x000000FE (шестнадцатеричное), но 0254 (десятичное) и 0x0000000FE (шестнадцатеричное) являются неправильными.
C.4.1.3.10. Соглашение по ASCII с плавающей точкой (REAL, LREAL)
Типы данных REAL и LREAL представляют двоичные величины с плавающей точкой. Внутреннее представление этих форматов данных описано в стандарте IEEE 754. Этот стандарт описывает как числовые величины, так и двоичные последовательности, которые интерпретируются как «нечисловые» (NaN) символьные величины и положительная и отрицательная бесконечность. Величины с плавающей запятой могут вводиться либо как значения целых чисел, либо как величины, основанные на десятичном представлении с плавающей точкой, или величины, вводимые в «научной» нотации с использованием базовой величины и сдвига в экспоненциальной форме. Значения целых чисел те же самые, что и в типах данных INT, DINT или LINT. Эти значения не могут быть использованы для представления дробных величин. Десятичные с плавающей точкой величины те же, что и величины, включающие в себя целую и дробную компоненту. Целочисленная величина и дробные компоненты разделяются десятичной точкой «.» или знаком точкой-разделителем. Экспоненциальная (научная) форма нотации величины — то же самое, что и представление дробной величины, но с добавлением экспоненциальной компоненты. Экспонента всегда представляет собой целую со знаком десять в степени, умноженную на базовую величину.
Примечание. Максимальная точность величины с плавающей точкой определяется возможностями внутреннего двоичного формата, т.е. числом двоичных разрядов, применяемых для кодирования мантиссы. Следовательно, использование большого числа десятичных разрядов в десятичной нотации (или составляющей мантиссу части научной нотации) величины с плавающей точкой предназначено больше для удобства, чем для повышения точности. EDS определяет произвольные пределы числа десятичных разрядов.
\text{величина} = ( - 1)^{s} \cdot (2)^{e - 127} \cdot (m) ,
e — 8-битная экспонента. Эта экспонента допускает диапазон экспоненты от минус 126 до плюс 127;
m — нормализованная 24-битная мантисса (23 внутренних для хранения плюс один скрытый бит). Это допускает диапазон значений мантиссы от 0 до 16777215.
Комбинация e и m допускает приближенный абсолютный диапазон значений от 0 до 3,4028e^{38} .
EDS использует для данных REAL следующие нотации величин с плавающей точкой:
целочисленная (фиксированная) нотация: -16777215 до 16777215 десятичная (с плавающей точкой) нотация: 0.0 до +/- 9999999999999999
Полное число разрядов не должно превышать 16 дополнительно к символам десятичной точки и знака. Как символ десятичной точки, так и символ знака могут быть пропущены (подразумевается знак «+», если символ знака пропущен).
Научная нотация: 0.0 до +/- nn.nnnnnnnnnE +/- xxxx:
Полное число разрядов мантиссы не превышает 11 (дополнительно к символу десятичной точки и символу знака), а число разрядов экспоненты не должно превышать 4 (дополнительно к символу «E» и символу знака). Десятичная точка может быть помещена в мантиссе где угодно. Как символ десятичной точки, так и символ знака могут быть опущены в мантиссе (знак «+» подразумевается, если символ знака опущен).
Диапазон допустимых данных LREAL (двойной IEEE, 64-битный формат) основан на формуле
\text{величина} = ( - 1)^{s} \cdot (2)^{e - 1023} \cdot (m) ,
e — 11-битная экспонента. Эта экспонента допускает диапазон между -1022 и +1023;
m — нормализованная 53-битная мантисса (52 внутренних в памяти плюс один скрытый бит). Это допускает диапазон значений мантиссы между 0 и 9007199254740991.
Комбинация e и m допускает приближенную абсолютную величину диапазона от 0 до 1,7976e^{308} .
EDS использует для данных LREAL следующие нотации величин с плавающей точкой:
- целая (фиксированная) нотация: -9007199254740991 до 9007199254740991,
- десятичная (с плавающей точкой) нотация: 0.0 до +/- 9999999999999999.
Полное число разрядов не превышает 16 в дополнение к символам десятичной точки и знака. Как символ десятичной точки, так и символ знака могут быть опущены (знак «+» подразумевается, если символ знака опущен).
Научная нотация: 0.0 до +/- nnnn.nnnnnnnnnnnnE +/- xxxx.
Полное число разрядов мантиссы не превышает 16 (дополнительно к символу десятичной точки и символу знака), а число разрядов экспоненты не должно превышать 4 (дополнительно к символу «E» и символу знака). Десятичная точка может быть помещена в мантиссе где угодно. Как символ десятичной точки, так и символ знака могут быть опущены в мантиссе (знак «+» подразумевается, если символ знака опущен).
Дополнительно к указанным выше величинам ввода представление с плавающей запятой допускает два вида «нечислового» или NaN символического ввода и две формы бесконечности. Существуют два типа NaN: сигнальный (Signaling) NaN и тихий (Quiet) NaN. Формат также допускает представление величин положительной и отрицательной бесконечности. Для этих случаев зарезервированы специальные указанные ниже слова, которые должны использоваться для представления ввода соответствующих символов с плавающей запятой: - тихий нечисловой: QUIET-NAN - сигнальный нечисловой: SIGNAL-NAN - положительная бесконечность: INFINITY (или +INFINITY) - отрицательная бесконечность: -INFINITY
Тип данных EDS_Date должен иметь формат mm-dd-yyyy, где mm — месяц, dd — день месяца и yyyy — год. Правильные значения частей месяц, день и год в mm-dd-yyyy должны быть следующими:
Может быть использовано двузначное представление года, в этом случае тип данных EDS_Date должен иметь формат mm-dd-yy, где mm — месяц, dd — день месяца и yy — год. Две цифры года подразумевают впереди 19, так что yy = 96 будет соответствовать 1996 году. Правильные значения месяца, дня и года в mm-dd-yy должны быть следующими:
- mm — от 01 до 12;
- dd — от 01 до 31 (в зависимости от месяца и года);
- yy — от 96 до 99 (подразумевается 19 впереди).
Примечание. Использование двузначного представления года не рекомендуется.
Тип данных EDS_Time_Of_Day должен иметь формат hh:mm:ss, где hh — часы, mm — минуты и ss — секунды. Правильные значения часов, минут и секунд должны быть следующими:
Тип данных EDS_Revision должен иметь формат Major_Revision. Minor_Revision со следующими правильными значениями:
EDS_Revision со значением 0.0 неправильна.
Пример - EDS_Revision со значением 1.4 соответствует большой проверке со значением 1 и малой проверке со значением 4.
C.4.1.3.14. Унифицированный указатель информационного ресурса EDS_URL
Все ссылки на EDS_URL в рамках требований EDS предназначены для получения формализованной информации, необходимой для поиска и получения ресурсов путем использования Интернета. EDS_URL должен быть закодирован в файлах EDS с использованием базового формата, определенного в ИСО 15745-4 для EDS_Char_Array. Кроме того, содержание строки для EDS_URL должно быть в формате, определенном Рабочей Группой по сети Интернет RFC 1738 «Унифицированный указатель информационного ресурса (URL)». В спецификациях файла EDS EDS_URL должно быть ограничено одной из следующих форм:
C.4.1.4. Основные требования к файлу EDS
В настоящем подразделе описаны основные секции EDS, которые являются общими для ряда основанных на CIP сетей, и установлены соответствующие требования при использовании.
В таблице C.5 приведено расположение подразделов, содержащих определения этих секций.
| Секции EDS | Определение |
|---|---|
| Секция описания файлов | C.4.1.4.2 |
| Секция описания устройств | C.4.1.4.3 |
| Секция классификации устройств | C.4.1.4.4 |
| Секция классов параметров | C.4.1.4.5 |
| Секция параметров | C.4.1.4.6 |
| Секция групп параметров | C.4.1.4.7 |
| Секция объединений | C.4.1.4.8 |
| Секция менеджера соединения | C.4.1.4.9 |
| Секция порта | C.4.1.4.10 |
| Секция модулей | C.4.1.5.2 |
C.4.1.4.2. Секция описания файлов
Секция описания файлов должна содержать административную информацию о файле EDS. Инструмент конфигурации должен считывать эту информацию, форматировать ее и показывать пользователю. Пользователь может также получить доступ в эту секцию для просмотра текста файла и показа неформатированной информации. Эта секция не требует выполнения модификации, если только пользователь не выполняет модификацию файла вручную. Секция описания файла должна содержать входы, показанные в таблице C.6.
Входы в секции описания файла должны предоставлять информацию, указанную в таблице C.7.
На рисунке C.2 приведен пример, показывающий типичную секцию [File].
[File] DescText = «Smart Widget EDS File»; CreateDate = 04-03-94; $ создан CreateTime = 17:51:44; ModDate = 04-06-94; $ последнее изменение ModTime = 22:07:30; Revision = 2.1; $ Проверка EDS HomeURL = http://www.odva.org/EDS/example.eds;
C.4.1.4.3. Секция описания устройства
Секция описания устройства должна содержать информацию изготовителя относительно устройства, включая некоторые из таких величин, как Identity Object устройства. Секция описания устройства должна включать входы, указанные в таблице C.8.
| Имя входа | Ключевое слово входа | Номер поля | Тип данных | Требуемое/Опциональное |
| Vendor Id (идентификатор продавца) a, b | VendCode | 1 | UINT | Требуемое |
| Vendor Name (имя продавца) | VendName | 1 | EDS_Char_Array | Требуемое |
| Device Type (тип устройства) a, b | ProdType | 1 | UINT | Требуемое |
| Device Type String (строка типа устройства) | ProdTypeStr | 1 | EDS_Char_Array | Требуемое |
| Product Code (код продукта) a, b | ProdCode | 1 | UINT | Требуемое |
| Major Revision (большая проверка) a, b | MajRev | 1 | USINT | Требуемое |
| Minor Revision (малая проверка) a | MinRev | 1 | USINT | Требуемое |
| Product Name (имя продукта) c | ProdName | 1 | EDS_Char_Array | Требуемое |
| Catalog Number (номер каталога) | Catalog | 1 | EDS_Char_Array | Опциональное |
| Exclude from Adapter Rack Connection (исключить из адаптера соединения стенда) | ExcludeFromAdapterRackConnection | 1 | EDS_Char_Array | Опциональное |
| Icon File Name (имя файла иконки) | Icon | 1 | EDS_Char_Array | Опциональное |
| a Данный вход представляет атрибут Identity Object (объект идентичности). | ||||
| b Данный вход используется для согласования EDS с конкретным продуктом/версией. | ||||
| c Данный вход представляет атрибут Identity Object (объект идентичности), хотя тип данных может незначительно отличаться. | ||||
Имя входа для поля описания устройства описывает уникальный номер строки ввода данных.
Инструмент конфигурации должен использовать требуемые входы в секции описания устройства для согласования EDS с конфигурируемым устройством. Входы секции описания устройства должны предоставлять информацию, показанную в таблице C.9.
VendCode = 65535;<br>
VendName = "Widget-Works, Inc.";<br>
ProdType = 0;<br>
ProdTypeStr = "Generic";<br>
ProdCode = 42;<br>
MajRev = 1; \$ Большая проверка устройства
MinRev = 1; \$ Малая проверка устройства
ProdName = "Smart-Widget";<br>
Catalog = "1499-DVG";<br>
Icon = "example.ico".
Рисунок C.3. Пример секции
[Device — Устройство] (информативный)
C.4.1.4.4. Секция Device Classification (классификация устройства)
Секция классификации устройств должна производить классификацию устройств, описанных в EDS, по одной или более категориям устройств. Ключевое слово всех классов должно состоять из набора символов «Class» («класс»), скомбинированных с десятичным числом. Числа должны начинаться с 1 для первого класса и увеличиваться для каждого следующего класса.
Число полей каждого входа классификации должно быть переменным для создания возможности древовидной структуры классификации, аналогичной структуре файловой системы каталога. Должны быть зарезервированы подклассы общей классификации. Классификация поставщика может иметь подклассы по его выбору. Первое поле должно представлять наиболее высокий уровень в древовидной структуре и должно быть одним из следующих ключевых слов поля:
Ключевое слово поля поставщика должно начинаться с идентификатора поставщика Vendor ID компании с дополнением через черту снизу специального поля поставщика VendorID_VendorSpecificField. Идентификатор поставщика VendorID должен быть выражен в виде десятичной цифры, не содержащей нулей на передних разрядах. Каждый поставщик несет ответственность за поддержание и документальное оформление ключевого слова для поля поставщика.
C.4.1.4.5. Секция Parameter Class (класс параметров)
Секция Класс Параметров должна определить общие атрибуты параметров конфигурации, описанных в EDS, соответствующие подмножеству атрибутов класса Parameter Object согласно описанию в библиотеке объектов CIP.
Секция Класс Параметров должна содержать входы, указанные в таблице C.10.
Входы секции Класс Параметров должны предоставлять информацию, указанную в таблице C.11.
Вход Parameter Class Descriptor должен содержать биты, предназначенные для описания характеристик параметров, согласно определению в таблице C.12. Биты, не определенные в таблице C.12, не должны использоваться и должны быть установлены на нуль (0).
| [ParamClass] |
|---|
| MaxInst = 3; |
| Descriptor = 0x0E; |
| CfgAssembly = 3. |
Секция параметров должна определять параметры конфигурации в устройстве. Ключевое слово входа должно быть одним из следующих наборов символов «Param», «ProxyParam», «ProxiedParam», скомбинированных с номером сущности параметра (десятичным) для устройства, например «Param1». Сущность объекта параметр может, но необязательно должна применяться в устройстве, но все сущности объекта параметр имеют соответствующий вход «ParamN» в EDS. Однако если сущность объекта параметр существует внутри узла и параметр описан в EDS, то значение «N» в «ParamN» должно быть равно сущности объекта параметр.
Каждый вход должен содержать форматированные поля, показанные в таблице C.13. Ключевые слова «ProxyParam» и «ProxiedParam» определены в C.4.1.5.3.1 в качестве части требований модульного EDS.
| Имя поля | Номер поля | Тип данных | Требуемое/Опциональное |
| Зарезервировано | 1 | USINT | Требуемое |
| Link Path Size (размер маршрута связи) | 2 | USINT | Опционально |
| Link Path (маршрут связи) | 3 | EPATH | Опционально |
| Descriptor (дескриптор) | 4 | WORD | Требуемое |
| Data Type (тип данных) | 5 | USINT/EPATH | Требуемое |
| Data Size (размер данных) | 6 | USINT | Требуемое |
| Parameter Name (имя параметра) | 7 | EDS_Char_Array | Требуемое |
| Units String (единичная строка) | 8 | EDS_Char_Array | Требуемое |
| Help String (вспомогательная строка) | 9 | EDS_Char_Array | Требуемое |
| Minimum Value (минимальное значение) | 10 | тип данных | Условно a |
| Maximum Value (максимальное значение) | 11 | тип данных | Условно a |
| Default Value (значение по умолчанию) | 12 | тип данных | Требуемое |
| Scaling Multiplier (множитель масштабирования) | 13 | UINT | Опционально |
| Scaling Divider (делитель масштабирования) | 14 | UINT | Опционально |
| Scaling Base (база масштабирования) | 15 | UINT | Опционально |
| Scaling Offset (сдвиг масштабирования) | 16 | INT | Опционально |
| Multiplier Link (множительная связь) | 17 | UINT | Опционально |
| Divisor Link (делительная связь) | 18 | UINT | Опционально |
| Base Link (базовая связь) | 19 | UINT | Опционально |
| Offset Link (связь со сдвигом) | 20 | UINT | Опционально |
| Decimal Precision (десятичная точность) | 21 | USINT | Опционально |
| International Parameter Name (международное имя параметра) | 22 | STRINGI | Опционально |
| International Engineering Units (международные технические единицы) | 23 | STRINGI | Опционально |
| International Help String (международная строка помощи) | 24 | STRINGI | Опционально |
| a Параметры указаны в таблице C.17. | |||
Входы в секции параметров должны предоставлять информацию, указанную в таблицах C.14 и C.18.
Поля параметров, перечисленные в таблице C.14, являются общими для всех параметров.
| Поле | Описание |
| Зарезервировано | Это первое поле должно содержать нуль |
| Link Path Size (размер маршрута связи) | Число байтов, используемых для представления пути. Если размер связи не согласуется с числом байтов в поле «Link Path», то «Link Path» должен быть проигнорирован. Если этот параметр не адресуется из связи, то это поле должно быть пустым. Если это поле пустое, «Link Size» должен быть равен числу байтов в поле «Link Path» |
| Link Path (маршрут связи) | Путь CIP к атрибуту объекта из места, где значение параметра извлечено. Путь должен вводиться как набор символов, используя нотацию пути, описанную в МЭК 61158-6:2003 (тип 2), и с форматом, указанным в A.4.1.3.6. Если параметр, описанный этим входом ParamN, не адресуемый прямо из сети, это поле должно быть пустым. Если это поле содержит нулевую строку, « », параметр, описанный этим входом ParamN, должен быть адресуем как атрибут данных (атрибут сущности 1) N-й сущности объекта Parameter (например, используя путь 20 0F 24 № 30 01) |
| Descriptor (дескриптор) | Параметр дескриптор. Содержит битовые флажки, описывающие поведение отдельных параметров (см. таблицу C.15) |
| Data Type (тип данных) | Идентификатор типа данных согласно определению в МЭК 61158-6:2003 (Тип 2: Data Type Reporting — Сообщение Типа Данных). Этот идентификатор должен быть кодирован либо как USINT, либо как EPATH Примечание. Старые версии файлов EDS могут использовать идентификаторы типа данных USINT согласно таблице C.16, но это в настоящее время устарело. Они предоставлены здесь по причинам совместимости. |
| Data Size (размер данных) | Числовая величина размера данных. Для строковых и EPATH типов данных это поле устанавливает число байтов на символ или вход. Следовательно, в случае типов данных STRING и EPATH эта величина должна быть установлена равной 1. В случае типа данных STRING2 она должна быть установлена равной 2. Для типа данных STRINGN она должна быть установлена равной «N» |
| Parameter Name (имя параметра) | Текстовое имя параметра. При необходимости должно быть выполнено обрезание извлеченного текста, если полный текст не помещается на максимальной длине набора текста |
| Units String (единичная строка) | Текстовое представление набора символов. При необходимости должно быть выполнено обрезание извлеченного текста, если полный текст не помещается на максимальной длине набора текста |
| Help String (вспомогательная строка) | Текстовый вспомогательный набор символов. При необходимости должно быть выполнено обрезание извлеченного текста, если полный текст не помещается на максимальной длине набора текста |
| Minimum Value (минимальное значение) | Значения и требования, основанные на типе данных параметров, см. в таблице C.17 |
| Maximum Value (максимальное значение) | Значения и требования, основанные на типе данных параметров, см. в таблице C.17 |
| Default Value (значение по умолчанию) | Числовые значения по умолчанию, присвоенные величине данных параметра |
| International Parameter Name (международное имя параметра) | Имя параметра, выраженное в нотации STRINGI |
| International Engineering Name (международное техническое наименование) | Технические единицы, выраженные в нотации STRINGI |
| International Help String (международная вспомогательная строка) | Вспомогательная строка, выраженная в нотации STRINGI |
Старые версии файлов EDS могут использовать идентификаторы типа данных, указанные в таблице C.16.
Идентификаторы типа данных (устаревшие)
В таблице C.17 установлены смысл и специальные требования для входов с минимальными и максимальными значениями на основании типов данных параметров.
| Тип данных | Описание и семантика | Семантика минимальных значений | Семантика максимальных значений | Требуемое/Опциональное/Недопустимое |
| BYTE | Битовая строка — длина 8 бит | Минимальные и максимальные значения этих типов данных не определены и не должны устанавливаться в файле EDS | Недопустимое | |
| WORD | Битовая строка — длина 16 бит | |||
| DWORD | Битовая строка — длина 32 бита | |||
| LWORD | Битовая строка — длина 64 бита | |||
| STRING a | Строка (индикатор длины 2 байта, 1 байт на символ) | Минимальная длина строки | Максимальная длина строки | Требуемое |
| STRING2 a | Строка (индикатор длины 2 байта, 2 байта на символ) | Минимальная длина строки | Максимальная длина строки | Требуемое |
| STRINGN a | Строка (индикатор длины 2 байта, № байт на символ) | Минимальная длина строки | Максимальная длина строки | Требуемое |
| SHORT_STRING a | Символьная строка (индикатор длины 1 байт, символы 1 байт) | Минимальная длина строки | Максимальная длина строки | Требуемое |
| EPATH a | Пронумерованный путь | Минимальная длина строки | Максимальная длина строки | Опциональное |
| Все другие типы данных | Минимальное числовое значение, которое может быть присвоено величине данных | Максимальное числовое значение, которое может быть присвоено величине данных | Опциональное b | |
| a Типы данных STRING, STRING2, STRINGN, SHORT_STRING и EPATH не имеют спецификации минимального или максимального значения. Поля минимального и максимального значений используются для представления минимальной и максимальной длины строки или пути. В этих случаях параметр Data Size используется для представления числа байтов, требующихся на символ или кодирование входа. | ||||
| b Если минимальное и/или максимальное значения не установлены, то минимальное и/или максимальное значения величины данных параметра определены в МЭК 61158-5:2003 (тип 2) исходя из типа данных параметра. | ||||
Поля параметра, перечисленные в таблице C.18, являются необязательными и значащими, только когда они используются со следующими типами данных: SINT, INT, DINT, LINT, USINT, UINT, UDINT, ULINT, REAL и LREAL. Спецификация этих полей с любым другим типом данных запрещена.
Поля параметров, зарезервированные для типов числовых данных
Масштабирование должно выполняться не устройством, содержащим параметр, а средствами дисплея. Если масштабирование поддерживается, средства дисплея должны использовать уравнение, показанное на рисунке C.5, для определения технического значения параметра (т.е. величины на дисплее) исходя из реального значения параметра. Если масштабирование не поддерживается, то значение параметра должно быть представлено на дисплее без изменений.
EngValue = \frac{(ActualValue + Offset)*Mult*Base}{Div*10^{\text{Десятичная точность}}}
a Если расширенное масштабирование не поддерживается, эта формула должна применяться при десятичной точности = 0.
Рисунок C.5. Формула масштабирования параметра
В секции [Params] возможно также наличие второго ключевого слова. Это ключевое слово должно быть использовано для предоставления списка нумерации вариантов параметра пользователю. Ключевое слово входа для всех пронумерованных параметров должно состоять из набора символов, «Enum», объединенного с десятичным числом из соответствующего входа Param. Каждый вход Enum должен состоять из пар целых чисел и строк.
Пример на рисунке C.6 показывает типичную секцию Parameter (Параметр).
[Params] Param1 = 0, 1,«20 02», 0x0E94, 1, 1,«Preset»,«V»,«User Manual p33», 0, 5, 1, 1, 1, 1, 0, 0, 0, 0, 0, 2;
Param2 = \$ parameter instance
0, \$ First field shall equal 0
6, "20 04 24 01 30 03 ", \$ path size, path
0x0A94, \$ descriptor - in hex format
1, \$ data type
1, \$ data size
"Trigger", \$ name
"Hz", \$ units
"User Manual p49", \$ help string
0, 2, 0, \$ min, max, default data values
1, 1, 1, 0, \$ mult, div, base, offset scaling
,,,, \$ mult, div, base, offset links not used
2; \$ decimal places
Param3 = \$ not addressable from link
0,,, 0x0082, 8, 1, "speed control", " ", " ", 3, 12, 3, ,,,,,,,,;
Enum3 = 3, "stop", 8, "slow", 12, "fast";
Рисунок C.6. Пример секции [Params]
Секция группы параметров должна определять все группы параметров в устройстве. Каждая группа параметров должна содержать список параметров в группе. Ключевое слово входа каждой группы должно состоять из комбинации набора символов, «Group» и номера группы параметров (десятичного), например «Group1». Десятичные номера должны начинаться с единицы и увеличиваться на единицу.
Фактический вариант объекта Parameter Group может, но необязательно, применяться в устройстве. Напротив, не требуется, чтобы все варианты объекта Parameter Group имели соответствующий вход «GroupN» в EDS. Однако если вариант объекта Parameter Group существует в узле и если эта Группа Параметров описана также в EDS, то значение «N» в «GroupN» должно быть равно варианту объекта Parameter Group.
Поля каждого входа должны содержать имя группы, число членов группы, а также номера вариантов параметров в этой группе. Секция группы параметров должна содержать поля, указанные в таблице C.19.
| Имя поля | Номер поля | Тип данных | Требуемое/Опциональное |
|---|---|---|---|
| Строка имени группы | 1 | EDS_Char_Array | Требуемое |
| Число членов | 2 | UINT | Требуемое |
| Параметр | 3 и более (число членов + 2) | UINT | Требуемое |
Group2 = "Monitor", 2, 2, 3; \$ group 2
Group3 = "Maintenance ", 2, 1, 3; \$ group 3
Рисунок C.7. Пример секции [Groups]
Секция Assembly описывает структуру блока данных. Часто этот блок представляет собой атрибут данных объекта Assembly; однако эта секция EDS может быть использована для описания любых сложных структур. Описание этого блока данных является параллельным механизму, который объект Assembly использует для описания списка своих членов.
Ключевое слово входа «Revision» должно иметь одно 16-битное поле целого числа, которое должно соответствовать версии (атрибут класса 1) объекта Assembly внутри устройства. Если этот опциональный вход пропущен, версия объекта Assembly должна быть 2.
Ключевое слово для всех объединений должно состоять из одного из следующих наборов символов: «Assem», «ProxyAssem», «ProxiedAssem», скомбинированных с номером варианта объекта Assembly (десятичным) для данного устройства, например «Assem1». Если конкретный вариант объекта Assembly адресуем из связи, то должна быть парность один к одному между номером Assem в файле EDS и номером варианта Assembly в устройстве. Ключевые слова «ProxyAssem» и «ProxiedAssem» определяются в C.4.1.5.3.2 как часть требований модульного EDS.
Каждый вход должен содержать форматированные поля, показанные в таблице C.20.
Первое поле «Name», должно быть строкой, придающей имя блоку данных. Это опциональное поле может быть использовано через интерфейс пользователя.
Второе поле «Path» должно быть строкой, определяющей логический путь. Этот путь должен указывать адрес блока данных в устройстве. Если блок, описанный этим входом AssemN, не адресуем прямо из связи, это поле должно быть пустым. Если это поле — нулевая строка, « », блок данных должен быть адресуемым как атрибут данных (атрибут варианта 3) N-го варианта объекта Assembly.
Третье поле «Size» должно представлять собой размер блока данных в байтах. Если ни это поле, ни поля «Member Size» / «Member Reference» не присутствуют, размер блока данных должен быть равен 0. Оба этих поля могут присутствовать, однако поскольку они оба устанавливают размер блока, установленные обоими способами размеры должны быть согласованы.
Четвертое поле «Descriptor» должно быть битовым полем, которое описывает некоторые характеристики Assembly. Биты этого поля следует интерпретировать согласно таблице C.21.
Определение бита поля дескриптора Assembly
Поля 5 и 6 должны быть зарезервированными и пустыми.
Остальные поля должны быть парными (например, поле "Member Size" составляет пару с полем "Member Reference"), что требует четное полное число полей. Число пар полей на каждом входе должно быть переменным. Эти пары должны соответствовать списку членов объекта Assembly.
Допустимые значения поля "Ссылка Элемента" должны быть одним из следующих:
- ссылка ParamN или ProxyParamN из секции [Params];
- ссылка AssemN или ProxyAssemN из секции [Assembly];
- строка, представляющая путь (EPATH);
- константа UDINT;
- пустое поле;
- дополнительные значения согласно определению для модульного EDS в C.4.1.5.3.2.
Если поле "Member Reference" пустое, число битов, установленное в поле "Member Size", должно быть использовано в качестве заполнителя незначащей информацией в Assembly. Поле "Member Reference", содержащее нулевую строку, должно рассматриваться как пустое поле. Поле "Member Reference" и ему соответствующее поле "Member Size" не должны быть оба пустыми. Если поле "Member Reference" указывает EPATH, этот путь должен состоять либо из логических сегментов (путь к объекту внутри устройства), либо из сегментов данных.
Поле "Member Size" должно иметь единицы битов. Если поле "Member Size" пустое, следует использовать заданный размер, соответствующий полю "Member Reference". Заданный размер входа "Param" должен быть приведен в его 6-м поле (размер). Заданный размер входа "Assem" должен быть приведен в его 3-м поле (размер).
Элементы должны быть помещены в блок данных, начиная с младшего бита, как это делается в объекте Assembly. Если поле "Member Size" меньше, чем заданный размер соответствующего поля "Member Reference", должны быть использованы младшие биты соответствующего поля "Member Reference". Если поле "Member Size" больше, чем заданный размер соответствующего поля "Member Reference", за полным элементом должно следовать заполнение нулями до расширения элемента на весь "Member Size". Представленный блок данных должен быть целым числом байтов. Сумма размеров всех элементов должна быть равна полю Размер AssemN (при выражении в битах).
На рисунке C.8 приведен пример, показывающий типичную секцию Assembly. В этом примере Assem5 имеет длину 1 байт и имеет значение по умолчанию 0x21.
0, \$ first field shall equal 0
6, "20 OF 24 01 30 01", \$ path size, path
0x0000, \$ descriptor
2, \$ data type: 16-bit WORD
2, \$ data size in bytes
"Idle state", \$ name
" ", \$ units
"User Manual p48", \$ help string
0, 2, 1, \$ min, max, default data values
0, 0, 0, 0, \$ mult, dev, base, offset scaling not used
0, 0, 0, 0, \$ mult, dev, base, offset link not used
0; \$ decimal places not used
Param2 =
0, 6, "20 OF 24 02 30 01", \$ path size, path
0x0000, 2, 2,
"Fault state", " ", "User Manual p49",
0, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0;
[Assembly]
Revision = 2;
Assem5 = "configuration", "20 04 24 05 30 03",1,,,,
4, Param1,
3, Param2,
1,;
Примечание. Ключевое слово «Variant», скомбинированное с десятичным числом (например, «Variant1»), зарезервировано для будущего определения новых типов входов в секции Assembly.
C.4.1.4.9. Раздел Connection Manager
Раздел менеджера соединений Connection Manager должен содержать информацию, касающуюся числа типов соединений приложений, которые поддерживают устройство. Этот раздел моделируется как Connection Manager Object. Многие использованные здесь термины описаны в МЭК 61158-5:2003 и МЭК 61158-6:2003 (тип 2). Ключевое слово каждого входа должно быть одним из следующего набора символов: «Connection», «ProxyConnect», «ProxiedConnect», объединенных с числом (десятичным), например «Connection1», «ProxyConnect1» или «ProxiedConnect1». Десятичные числа должны начинаться с 1 и увеличиваться для каждого дополнительного входа «ProxyConnect», «ProxiedConnect». Ключевые слова «ProxyConnect» и «ProxiedConnect» определены в C.4.1.5.3.3 в качестве части требований к модульному EDS.
Каждый вход должен содержать форматированные поля, указанные в таблице C.22.
C.4.1.4.9.2. Маска переключения и транспорта
Присвоение битов в маске переключения и транспорта должно соответствовать показанному в таблице C.23. Бит должен быть установлен на 1 (включено) для каждого режима переключения, который поддерживает соединение. Все другие биты должны быть установлены на 0 (выключено). Для бита клиент/сервер: 0=клиент, 1=сервер. Только один из типов транспорта должен быть установлен на 1 (включено).
Присвоение битов в маске переключения и транспорта
C.4.1.4.9.3. Параметры соединения
Присваивание битов для типа соединения и маски приоритетов должно соответствовать указанному в таблице C.24. Бит должен быть установлен на 1 (включено) для каждого типа соединения и приоритета, поддерживаемых соединением. Все другие биты должны быть установлены на 0 (выключено).
C.4.1.4.9.4. O=>T RPI (Requested Packet Interval)
O=>T RPI должно быть числом микросекунд интервала запрашиваемого пакета. O=>T RPI должно быть UDINT, или Param, или ProxyParam входом из секции [Params], который определяется в UDINT. Если это поле пустое, никакие ограничения не накладываются на O=>T RPI.
O=>T размер должен быть числом байтов, предоставляемых для целевого транспорта. Он не должен включать счет последовательности транспорта. O=>T размер должен быть UINT, или Param, или ProxyParam входом из секции [Params], который определяется в UINT. Если это поле пустое, заданный размер формата O=>T должен использоваться после добавления опционального размера заголовка прогона/холостого хода.
Формат входа O=>T должен определять структуру буфера потребителя для этого соединения. Правильные дескрипторы формата должны быть идентификаторами в файле EDS, включая следующее:
Это поле может быть пустым, показывая, что формат потребителя не установлен. Это поле не должно быть пустым, если поле O=>T размер пустое. Формат O=>T не должен включать в себя 32-битный заголовок, если он присутствует.
T=>O RPI должно быть числом микросекунд интервала запрашиваемого пакета. T=>O RPI должно быть UDINT, или Param, или ProxyParam входом из секции [Params], который определяется в UDINT. Если это поле пустое, никакие ограничения не накладываются на T=>O RPI.
T=>O размер должен быть числом байтов, предоставляемых для целевого транспорта. Он не должен включать в себя счет последовательности транспорта. T=>O размер должен быть UINT, или Param, или ProxyParam входом из секции [Params], который определяется в UINT. Если это поле пустое, заданный размер формата T=>O должен использоваться после добавления опционального заголовка прогона/холостого хода.
Формат входа T=>O должен определять структуру буфера потребителя для этого соединения. Правильные дескрипторы формата должны быть идентификаторами в файле EDS, включая следующее:
Это поле может быть пустым, показывая, что создаваемый формат не установлен. Это поле не должно быть пустым, если поле T=>O размер пустое. Формат должен включать в себя заголовок статуса, если он присутствует.
Размеры Config #1 и Config #2 должны устанавливать размер сегмента опциональных данных, которые присоединяются к пути ForwardOpen. Сегмент данных должен быть конкатенацией двух буферов в соответствии с форматами Config #1 и Config #2. Размеры должны измеряться определенным числом байтов и принадлежать входам UINT, или Param, или ProxyParam секции [Params], которые определяются в UINT. Если одно из полей Config пустое, должен быть использован по умолчанию размер формата соответствующего поля Config.
Действительные поля, устанавливающие формат конфигурации Config, должны иметь идентификаторами в файле EDS:
Эти поля могут быть пустыми, показывая, что формат конфигурации не установлен. Если оба поля конфигурации размера и конфигурации формата пустые, никакие сегменты данных не добавляются к пути Forward_Open.
C.4.1.4.9.11. Строка имени соединения
Инструмент может показывать строку имени соединения (набор символов). Строка имени соединения должна быть уникальной среди всех входов Соединения (Connection) в рамках EDS.
C.4.1.4.9.12. Вспомогательная строка
Инструмент может показывать текстовый вспомогательный набор символов. Если вспомогательная строка не должна быть предоставлена, необходимо использовать нулевую строку, определяемую парой двойных кавычек « » при отсутствии символов между метками.
Путь содержит ссылку на целевой объект. Путь должен вводиться как Путь CIP (EPATH) с использованием заполняющей путь нотации, описанной в МЭК 61158-6:2003 (тип 2), и в формате, установленном в C.4.1.3.6. Дополнительно к формату, установленному в C.4.1.3.6, поле пути может также содержать другие приведенные ниже ссылки:
- Param или ProxyParam входы из секции [Params];
- ключевое слово SLOT;
- ключевое слово SYMBOL_ANSI;
- ключевое слово SLOT_MINUS_ONE.
Входы Param/ProxyParam должны обозначаться согласно USINT, UINT или UDINT. Значение Param/ProxyParam должно использоваться с обратным порядком байтов для вставки в путь. Ссылки Param/ProxyParam в пути могут быть заключены в скобки, как показано на рисунке C.9. Если значение Param/ProxyParam заключено в скобки, оно используется локально для пути — тот же самый вход 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 = 0x91). Например, строка «CAB» должна определяться следующим расширенным символьным сегментом (заполненным): 0x91 0x03 0x43 0x41 0x42 0x00.
C.4.1.4.9.14. Пример секции Connection Manager (информативный)
На рисунке C.9 приведен пример, показывающий типичную секцию Connection Manager (Менеджер Соединения).
Param 1 = \$ specifies read buffer
0,,, \$ no path means not directly accessible
0x0004, \$ descriptor : support scaling
8, 1, \$ USINT, 1 byte
"Read", \$ name
" ", " ", \$ units & help string
64, 95, 64, \$ min, max, default data values
1, 1, 1, -63, \$ mult, div, base, offset scaling
0, 0, 0, 0, 0; \$ mult, div, base, offset link & decimal
\$ (not used)
Param2 = \$ specifies write buffer
0,,, \$ no path means not directly accessible
0x0004, \$ descriptor : support scaling
8, 1, \$ USINT, 1 byte
"Write", \$ name
" ", " ", \$ units & help string
160, 191, 160, \$ min, max, default data values
1, 1, 1, -159, \$ mult, div, base, offset scaling
0, 0, 0, 0, 0; \$ mult, div, base, offset link & decimal
\$ (not used)
[Connection Manager] Connection1 = 0x04010002, $ trigger & transport $ class 1, cyclic, exclusive-owner 0x44244401, $ point/multicast & priority & realtime format
\$ fixed, 32-bit headers, scheduled,<br>
\$ O=>T point-to-point, T=>O multicast
,16,, \$ O=>T RPI, size, format
,12,, \$ T=>O RPI, size, format
,, \$ config part 1 (not used)
,, \$ config part 2 (not used)
"read/write", \$ connection name
" ", \$ Help string
"20 04 24 01 2C [Param2] 2C [Param1]";
Секция Port должна описывать порты, имеющие маршруты CIP и доступные внутри устройства. Каждый имеющий CIP маршрутизацию порт должен иметь соответствующий вход в этой секции. Ключевое слово входа для всех портов должно состоять из набора символов «Port», скомбинированного с десятичным числом, соответствующим сущности объекта порт. Например, Port1 является сущностью 1 Port Object.
Примечание. Маршрутизируемый согласно CIP порт — это порт, способный обмениваться сообщениями CIP с другим портом CIP, соединенным с другой связью CIP.
Первое поле, называемое «Port Type Name», должно быть одним из следующих ключевых слов поля:
- ControlNet;
- ControlNet_Redundant;
- TCP (для указания имеющего возможности EtherNet/IP TCP порта);
- DeviceNet;
- зависящее от поставщика ключевое слово поля, начинающееся с идентификатора поставщика Vendor ID устройства и символа подчеркивания ('65535_').
Опциональное поле «Port Name» должно быть строкой, содержащей имя порта, и может быть использовано в интерфейсе пользователя. Поле «Port Object» должно быть путем EPATH, который указывает на определенный объект связи сети, ассоциированный с портом.
Порт номер 1 должен соответствовать порту объединительной панели. Устройства с объединительной панелью, которые не могут определять маршрут сообщений CIP, не должны иметь порт номер 1.
На рисунке C.10 приведен пример, показывающий типичную секцию Port.
Port1 = DeviceNet,
«Port A», $ name of port
"20 03 24 01", \$ instance one of the DeviceNet object
2; \$ port number 2
Port2 = 65535_Chassis,
"Chassis", \$ name of port
"20 9A 24 01", \$ vendor specific backplane object
1; \$ port number 1
Рисунок C.10. Пример секции [Port]
C.4.1.5. Требования к файлу модульного EDS
В настоящем подразделе дано описание концепции и содержания модульного EDS и установлены требования по применению.
[Modular] секция должна описывать систему на основе стойки. Должны существовать два типа модульных устройств:
Секция [Modular], описывающая стойку, должна содержать требуемое ключевое слово «DefineSlotsInRack». Единственное поле этого входа должно быть 16-битным беззнаковым целым числом (UINT), указывающим число слотов в стойке. Даже если электронный ключ определен для этой стойки, она необязательно будет адресуемой из связи. Ключевое слово SLOT, использованное в определениях пути в секции [Connection Manager], должно иметь диапазон от 0 до числа слотов минус 1.
Ключевое слово «SlotDisplayRule» необязательно. Единственное поле этого входа должно быть параметром из секции [Params] (только ParamN), которое определяет преобразование между внутренним и внешним номером слота.
На рисунке C.11 приведен пример, показывающий EDS для устройства стойки, включая секцию Modular.
C.4.1.5.2.3. Модульное устройство (основные входы)
[Modular] секция, описывающая модуль, должна содержать входы «Width (ширина)» и «Rack (блок)».
Требуемый вход с ключевым словом «Width» должен иметь одно поле, показывающее, сколько слотов стойки используется модулем. Это поле должно быть 16-битным беззнаковым целым числом (UINT).
Ключевое слово входа для всех стоек, в которые модуль может быть установлен, должно состоять из набора символов, «Rack», скомбинированного с десятичным числом. Числа должны начинаться с 1 для первой стойки и должны повышаться для каждой дополнительной стойки. Поля для входов «Rack» должны быть такими, как показано в таблице C.26.
Поля «Vendor ID», «Product Type», «Product Code», «Major Revision» и «Minor Revision» должны идентифицировать электронный ключ стойки, в которые может быть установлен модуль. Резервное поле должно быть пустым. Поля «Legal Slot» должны указывать слоты, в которые может быть установлен модуль. EDS для модуля должен содержать один вход «Rack» для каждой стойки, в которые данный модуль может быть установлен.
На рисунке C.12 приведен пример, показывающий типичную модульную секцию [Modular].
Rack1 = \$ this module can plug into
65535, 101, 1, 1, 1,,,, \$ slots 1, 2, 3 and 4 of
1, 2, 3, 4; \$ this five slot chassis
Рисунок C.12. Пример [Modular] секции
C.4.1.5.2.4. Модульное устройство (дополнительные входы)
В EDS определены дополнительные входы для создания возможности идентификации устройства и проверки ключа устройства в случае модулей в системе на основе стоек, не поддерживающих CIP.
Для этой цели модульные устройства обычно подразделяются на две категории:
- модули, имеющие соединение связи CIP, соответствующий адресуемый из связи объект идентификации, и помещаемые в слот 0 (например, связные адаптеры);
- модули, которые не имеют соединения связи CIP или адресуемого объекта идентификации и, следовательно, не могут быть помещены в слот 0 (например, модули ввода/вывода).
Примечание. CIP предоставляет другие механизмы идентификации устройства и коммутации устройства в случае модулей, поддерживающих объект идентичности, адресуемый в связи CIP.
Входы для модуля, не имеющего адресуемого из связи объекта идентичности
Секция [Modular], описывающая модуль, не имеющий адресуемого из связи объекта идентичности, может содержать ключевое слово «ExternalID (Внешняя идентичность)». Ключевое слово должно иметь одно поле. Это поле должно быть байтовой строкой, идентифицирующей модуль. Эта байтовая строка должна иметь кодировку с использованием такого же формата, который установлен для EPATH.
На рисунке C.13 приведен пример, показывающий типичную Модульную секцию [Modular], описывающую модуль, не имеющий адресуемый из связи объект идентичности.
[Modular]
Width = 1;
Rack1 = $ this module can plug into
65535, 101, 1, 1, 1,,,, $ slots 1, 2, 3 and 4 of
1, 2, 3, 4; \$ this five slot chassis
Rack2 =
65535, 101, 2, 1, 1,,,,
1, 2, 3, 4, 5, 6, 7;
ExternalID = "12 34";
Рисунок C.13. Пример модульной секции [Modular] (модуль, не имеющий адресуемый из связи объект идентичности)
Входы для модулей, имеющих соединение связи и помещаемых в слот 0
Модульная секция, описывающая модуль, имеющий соединение связи и помещаемый в слот 0, может содержать любое из указанных ниже ключевых слов входа или их комбинацию.
Ключевое слово «GenericID» должно иметь одно поле. Это поле должно быть байтовой строкой, которая должна быть включена в сегмент данных для соединения модуля вместо ExternalID, когда кодирование нежелательно. Эта байтовая строка должна иметь кодировку с использованием такого же формата, который установлен для EPATH.
Ключевое слово «ExternIDExactMatch» должно иметь одно поле со значением «Да» или «Нет». «Да» должно показывать, что ExternalID устанавливает одно конкретное устройство, «Нет» должно показывать, что ExternalID устанавливает одно из набора совместимых устройств. Если ключевое слово «ExternIDExactMatch» пропущено, то условие по умолчанию должно быть такое, что ExternalID устанавливает одно конкретное устройство.
Ключевое слово «Query» должно иметь четыре поля. Первое поле должно быть путем, указывающим адресуемый связью атрибут, содержащий набор внешних идентификаторов, по одному для каждого слота стойки, за исключением слота 0. Второе поле должно быть сервисом для использования путем запроса (т.е. 1 — получить все атрибуты или 14 — получить один атрибут). Третье поле должно быть целым числом, которое определяет число байтов, используемых для идентификации каждого модуля, и должно быть в диапазоне 1 — 16. Если модуль с двойными слотами имеется в стойке, внешний идентификатор для этого модуля должен появляться дважды в наборе, возвращаемом в ответе на запрос. Запрос должен адресоваться только на модуль в слоте 0. Четвертое поле должно быть ExternalID, возвращаемое, когда существует пустой слот, с кодировкой такого же формата, который установлен для EPATH.
На рисунке C.14 приведен пример, показывающий типичную [Modular] секцию, описывающую модуль, имеющий соединение связи, помещенный в слот 0.
Rack1 = \$ this module can only plug into
65535, 101, 1, 1, 1,,,, \$ slot 0 of this five slot chassis
0;
Rack2 = 65535, 101, 2, 1, 1,,,, 0;<br>
Query = "20 04 24 07 30 03",1,2,"FF FF";<br>
GenericID = "00 00";<br>
ExternalIDExactMatch = No;
Рисунок C.14. Пример модульной секции [Modular] (модуль с соединением связи в слоте 0)
C.4.1.5.3. Модульные дополнения к основным секциям EDS
C.4.1.5.3.1. Дополнения к секции Parameter
Для описания параметров, которые ретранслируются адаптерным устройством EtherNet/IP на другое устройство, которое не поддерживает протокол CIP, необходимо использовать ключевые слова «ProxyParam» и «ProxiedParam». Примером этого является адаптерный модуль EtherNet/IP (устройство, выполняющее функции доступа к соединению) в блоке с многими слотами ввода/вывода для модуля с аналоговыми вводом/выводом (устройство для которого реализуются функции 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».
C.4.1.5.3.2. Дополнения к секции Assembly
Дополнительные ключевые слова входа
Ключевые слова «ProxyAssem» и «ProxiedAssem» должны быть использованы для описания функциональных блоков, которые выполняют функцию proxy с помощью адаптерного устройства CIP для другого устройства, которое не поддерживает протокол CIP. Примером этого является адаптерный модуль EtherNet/IP (устройство для осуществления proxying соединения) в блоке с множественными слотами входа/выхода, соединяющий его с аналоговым модулем входа/выхода (устройство, на соединении с которым выполняется функция proxy).
Ключевое слово «ProxyAssem» должно существовать в EDS для устройства, выполняющего функцию proxy; ключевое слово «ProxiedAssem» должно существовать в EDS для устройства, для которого выполняется функция proxy.
Информация в Модульной секции [Modular] должна использоваться для создания ассоциации содержащих ключевые слова «ProxyAssem» файлов EDS с файлами 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, которые указывают специальные цели, предусмотренные при использовании данных, определенных элементом объединения:
- ExternalID;
- InputSlotMask0 или InputSlotMask1;
- OutputSlotMask0 или OutputSlotMask1;
- ConfigSlotMask0 или ConfigSlotMask1.
Ключевое слово «ExternalID» указывает, что этот член объединения должен содержать либо значение «ExternalID» модульного устройства, если желательно наличие ключа устройства, либо значение «GenericID», определенное в EDS адаптера, если ключ нежелателен.
Ключевое слово «ExternalID», скомбинированное с десятичным числом (например ExternalID2), должно использоваться для разрешения применения ключа отдельного устройства для соединений с адаптерным блоком. Десятичное (положительное) число № в «ExternalIDN» указывает слот № в блоке. Ключевое слово «ExternalIDN» указывает, что этот элемент объединения должен содержать либо значение «ExternalID» модульного устройства для слота 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 (Размер элемента)».
C.4.1.5.3.3. Дополнения к секции Connection Manager
Ключевые слова «ProxyConnect» и «ProxiedConnect» должны быть использованы для описания соединений, на которых выполняется функция proxy с помощью адаптерного устройства CIP, с другим устройством, которое не поддерживает протокол CIP. Примером этого является адаптерный модуль EtherNet/IP (устройство для осуществления proxy соединения) в блоке с множественными слотами входа/выхода, соединяющий его с аналоговым модулем входа/выхода (устройство, на соединении с которым выполняется функция proxy).
Ключевое слово «ProxyConnect» должно существовать в EDS для устройства, выполняющего функцию proxy. В примере выше этим устройством будет адаптерный модуль EtherNet/IP.
Ключевое слово «ProxiedConnect» должно существовать в EDS для устройства, для которого выполняется функция proxy. В примере выше этим устройством будет аналоговый модуль входа/выхода.
Информация в секции [Modular] должна использоваться для создания ассоциации содержащих ключевые слова «ProxyConnect» файлов EDS с файлами EDS, содержащими ключевые слова «ProxiedConnect». Такая ассоциация должна существовать, когда оба файла EDS указывают соответствующий вход Rack.
Десятичное число (которое комбинируется с «ProxyConnect» и «ProxiedConnect») должно быть использовано для указания соответствия между «ProxyConnect» и «ProxiedConnect». Значения поля соответствующих пар «ProxyConnect» и «ProxiedConnect» должны быть скомбинированы для составления такой же информации значения поля, которая существует в одном входе «Connection». Эта комбинация должна быть выполнена путем использования значений поля из «ProxyConnect», за исключением тех полей, где значение равно ключевому слову «Module». В этих случаях должно быть использовано значение поля, установленное в ассоциированном «ProxiedConnect». Следует обычно указывать значения поля для входов «ProxiedConnect», соответствующие которым значения поля в «ProxyConnect» не «Module», однако эти значения поля не должны использоваться, их следует отмечать только для документации. Значение поля для поля «ProxyConnect» «строка имени соединения» не должно быть «Module», «ProxyConnect» должен всегда указывать «строку имени соединения».
C.4.1.5.3.4. Примеры расширенной секции EDS (информативные)
На рисунках C.15 и C.16 приведены примеры, показывающие использование модульных расширений EDS для секций Parameter, Assembly и Connection Manager.
Рисунок C.16. Пример соответствующих
входов ProxiedParam и ProxiedAssem
C.4.2. Специальные требования к EDS в EtherNet/IP
C.4.2.1. Содержание EDS в EtherNet/IP
Данный подраздел устанавливает требования к кодировке в Электронном бланке данных (EDS) в сетях EtherNet/IP.
В таблице C.27 приведена в обобщенном виде структура секций, которые могут быть представлены в EtherNet/IP EDS, соответствующие принятые разграничители секций и порядок этих секций в EDS. Некоторые из этих секций являются общими для ряда основанных на CIP сетей, и их специальное применение в EtherNet/IP указано в C.4.2.2, если это необходимо. Другие секции, специфические для EtherNet/IP, рассмотрены в C.4.2.4.
Структура файла EDS в EtherNet/IP
| Имя секции | Принятый разграничитель | Размещение | Требуемый/Опциональный |
| File Description (описание файла) | [File] | 1 | Требуемый |
| Device Description (описание устройства) | [Device] | 2 | Требуемый |
| Device Classification (классификация устройства) | [Device Classification] | a | Требуемый |
| Parameter Class (класс параметра) | [ParamClass] | a | Опциональный |
| Parameters (параметры) | [Params] | a | Опциональный |
| Parameter Groups (группы параметров) | [Groups] | a | Опциональный |
| Assembly (объединение) | [Assembly] | a | Опциональный |
| Connection Characteristics (характеристики соединения) | [Connection Manager] | a | Условный b |
| Port (порт) | [Port] | a | Опциональный |
| Modular (модульный) | [Modular] | a | Опциональный |
| Vendor Specific (относящийся к поставщику) | [VendorID_vendorspecifickeyword] | Последний | Опциональный |
| a Размещение этих групп должно быть только после секций Описание устройства и Классификация устройства. | |||
| b Эти секции необходимы, если применяются соответствующие функциональные характеристики, иначе они могут быть пропущены. | |||
Содержание EtherNet/IP EDS должно быть далее организовано следующим образом:
- все файлы EtherNet/IP EDS должны включать в себя секцию Device Classification, в которой должен использоваться принятый разграничитель [Device Classification] и которая может быть помещена где-либо после секции File Description;
- опциональные и условные секции, описанные в данной спецификации, могут быть представлены в любом порядке при условии, что опережающие ссылки в файле EDS отсутствуют.
C.4.2.2. Выполнение общих требований CIP
C.4.2.2.1. Секция Device Classification
В случае любого соответствующего EtherNet/IP устройства секция классификации устройства в относящемся к нему файле EDS должна включать в себя хотя бы один вход с ключевым словом ClassN, где первое поле установлено на EtherNet/IP. Дальнейшая подклассификация классификации EtherNet/IP должна быть зарезервирована.
В секции Port файла EDS вход PortN, соответствующий применяемому в EtherNet/IP порту, должен быть установлен следующим образом:
- поле «Port Type Name» должно иметь значение «TCP»;
- опциональное поле «Port Object» должно быть установлено на путь объекта интерфейс TCP/IP для этого порта;
- никакие дополнительные требования, кроме указанных в общем подразделе CIP (см. C.4.1.4.10), не помещаются в поля «Port Name» и «Port Number».
Примечание. EDS для устройства EtherNet/IP не должно содержать прямую ссылку на объект связи для порта EtherNet/IP (например, объект Link EtherNet/IP), поскольку ссылка может осуществляться через объект TCP/IP Interface для этого порта.
C.4.2.3. Дополнительные требования к кодировке данных
Никакие дополнительные требования к кодировке данных файлов EtherNet/IP EDS не существуют.
C.4.2.4. Дополнительные требования к файлам
Никаких дополнительных требований к файлам для файлов EtherNet/IP EDS не существует.
D.1. Обзор
PROFINET представляет собой основанную на Ethernet сеть, соответствующую МЭК 61784-1 (издание 1) СР 3/3.
Сеть PROFINET использует описание профиля, основанное на ИСО 15745-1. Имя технологии профиля — GSDML (Generic Station Description Markup Language — Язык разметки для общего описания станции).
В цели формата GSDML не входит описание технологических функций или графического интерфейса пользователя в устройстве. Для этой цели уже установлены рекомендуемые концепции [например, Язык описания электронных устройств — Electronic Device Description Language (EDDL) в соответствии с МЭК 61804-2].
Путем использования GSDML создается файл GSD (Generic Station Description — Общее описание станции). В целях указания отличий от формата PROFIBUS <2> GSD, описанного в ИСО 15745-3:2003 (приложение В), в настоящем стандарте использован термин «основанный на GSDML файл».
<2> PROFIBUS — торговая марка PROFIBUS International (PI). Эта информация предоставлена для удобства пользователей комплекса стандартов ИСО 15745 и не означает подтверждения со стороны ИСО торговой марки или какой-либо продукции. Для соответствия настоящему профилю не требуется использование торговой марки PROFIBUS. Применение торговой марки PROFIBUS требует разрешения PROFIBUS International.
Основанный на GSDML файл может содержать более чем одну точку доступа в устройство — Device Access Points (DAP). DAP представляет собой специальный модуль, соединяющий устройство с сетью. Это позволяет построить один файл для семейства устройств, совместно использующих одни и те же модули (см. D.4.4.1 и D.4.5).
D.2. Типы данных
В таблице D.1 дано описание типов данных, используемых в GSDML. Используемые регулярные выражения определены в REC-xml-20001006.
| Имя | Схема определения | Описание |
| Булев | http://www.w3.org/2001/XMLСхема | См. REC-xmlschema-2-20010502 |
| Перечисление | GSDML-DeviceProfile-v1.0.xsd | Строка с определенным содержанием |
| IdT | GSDML-Примитив-v1.0.xsd | Используется для идентификации объекта. Список значений должен соответствовать следующему регулярному выражению: (\S(.)*\S)|\S |
| NormalizedString (нормализованная строка) | http://www.w3.org/2001/XMLSchema | См. REC-xmlschema-2-20010502 |
| Токен | http://www.w3.org/2001/XMLSchema | См. REC-xmlschema-2-20010502 |
| RefIdT | GSDML-Примитивы-v1.0.xsd | Используется для ссылки на объект |
| Unsigned8 | GSDML-Примитивы-v1.0.xsd | Беззнаковое целое число в диапазоне 0 .. 255 |
| Unsigned16 | GSDML-Примитивы-v1.0.xsd | Беззнаковое целое число в диапазоне 0 .. 65535 |
| Unsigned32 | GSDML-Примитивы-v1.0.xsd | Беззнаковое целое число в диапазоне 0 .. 4294967295 |
| ValueList (список значений) | GSDML-Примитивы-v1.0.xsd | Базовый тип для списка, включающего в себя диапазоны величин без знака. Список величин должен соответствовать следующему регулярному выражению: ((\-?\d+\.\.\-?\d+)|(\-?\d+))((\-?\d+\.\.\-?\d+)|(\-?\d+))* Если диапазон определен, значение слева из «..» должно быть меньше, чем значение справа из «..» (см. пример 1) |
| SignedValueList (список значений со знаком) | GSDML-Примитивы-v1.0.xsd | Базовый тип для списка, включающего в себя диапазоны величин со знаком. Список величин должен соответствовать следующему регулярному выражению: ((\-?\d+\.\.\-?\d+)|(\-?\d+))((\-?\d+\.\.\-?\d+)|(\-?\d+))* Если диапазон определен, значение слева из «..» должно быть меньше, чем значение справа из «..» (см. пример 2) |
| Пример 1 — Правильный ValueList содержит: 12 3 4 | ||
| 512211 | ||
| 0..6 | ||
| 5..12 | ||
| 0..34 36 38 | ||
| Пример 2 — Правильный SignedValueList содержит: | ||
| 12 3 4 | ||
| -12 5 12211 | ||
| 0..6 | ||
| -5..12 | ||
| 0..34 36 38 | ||
D.3. Общие правила
Если файл на основе GSDML уже выпущен, важно сохранять неизменной идентификацию объектов. Следовательно, содержание атрибутов, соответствующих указанным ниже выражениям для XPath (см. REC-xpath-19991116), нельзя изменять в новой версии основанного на GSDML файла:
Имя основанного на GSDML файла должно быть составлено из шести указанных ниже полей в следующем порядке:
- ID версии в формате Vx.y, где x и y — беззнаковые целые числа. ID версии относится к ID использованной схемы GSDML;
- имя поставщика;
- имя семейства устройств;
- дата выпуска основанного на GSDML файла в формате yyyymmdd;
- «.xml» (расширение файла).
В качестве разграничителей между полями должен использоваться символ тире «-„(ASCII 45 десятичное).“»
Пример - «GSDML-V1.0-Lieferant-ET200X-20030818.xml»
Уже выпущенные файлы нельзя изменять без изменения имени файла. При построении новой версии основанного на GSDML файла дата выпуска должна быть изменена.
В случае установки более чем одной версии основанного на GSDML файла техническая система может использовать дату выпуска для определения последней версии.
D.3.3. Расположение схемы в основанном на GSDML файле
Для системы проверки допустимости XML схемы необходима информация о расположении выбранного файла схемы. Следовательно, должен быть указан атрибут xsi:schemaLocation корневого элемента профиля ИСО 15745.
Для использования одного и того же расположения для всех основанных на GSDML файлов необходимо использовать для файлов схемы относительный путь «..\xsd».
Некоторые элементы GSDML схемы могут быть адресованы с помощью идентификатора. Этот идентификатор является атрибутом с именем «ID». По вопросу правильного диапазона этого атрибута см. D.3.2.
Идентификация объектов должна поддерживаться уникальной для всех элементов одной и той же категории согласно описанию в приведенной ниже таблице (например, вся идентификация объектов для объектов типа «ModuleItem» должна быть уникальной).
Уникальность идентификаторов ID по всему документу необязательна.
В таблице D.2 показаны адресуемые элементы. В правой графе указаны все те объекты, на которые ссылаются элементы в левой графе. Эти ссылки используют соответствующие идентификаторы ID в качестве средства адресации.
| Тип | Ссылочные элементы |
|---|---|
| DeviceAccessPointItem | Зарезервировано для будущего использования |
| ModuleItem | Атрибут ModuleItemTarget элемента UseableModules/ModuleItemRef (см. D.4.5.5) |
| VirtualSubmoduleItem | Зарезервировано для будущего использования |
| ValueItem | Атрибут ValueItemTarget всех элементов Ref |
| CategoryItem | Атрибуты CategoryRef и SubCategory1Ref элемента ModuleInfo (см. D.4.8.1) |
| GraphicItem | Производится ссылка из элемента Graphics/GraphicItemRef (см. D.4.8.10) |
Поддержка языка основана на концепциях XML. Зависящие от языка строки могут поддерживаться в основанных на GSDML файлах или выбранных строках в других файлах. Обе стратегии могут комбинироваться.
Другие строки помещаются внутри GSDML в виде словарей. Каждый зависящий от языка текст должен иметь атрибут «TextId», имеющий ссылку на вход в словаре.
< Text TextId="ID_COMM_ERROR" Value = "Communication error"/><br>
</PrimaryLanguage><br>
<Language xml:lang="de">
< Text TextId="ID_COMM_ERROR" Value = "Kommunikationsfehler"/>
</Language>
<Language xml:lang="fr">
<Text TextId="ID_COMM_ERROR" Value = "Erreur de communication"/><br>
</Language><br>
</ExternalTextList>
ExternalTextList должен иметь элемент PrimaryLanguage. Используются текстовые строки, определенные в элементе PrimaryLanguage, если текстовая строка в выбранном словаре утеряна. В основанных на GSDML файлах первичный язык должен быть английским.
Элементы Language в ExternalTextList должны иметь атрибут «xml:lang» для идентификации выбранного языка. Код для представления имени языка должен соответствовать ИСО 639-1:2002.
Кроме того, строки могут присутствовать во внешних файлах — никакие изменения не являются необходимыми в самих основанных на GSDML файлах для поддержки нового языка. Имя внешнего файла должно быть построено по имени соответствующего основанного на GSDML файла путем присоединения строки «-Text-» и соответствующего ИСО 639-1:2002 двухбуквенного кода.
Пример 2 — «GSDML-V1.0-Lieferant-ET200X-20030818-Text-fr.xml»
Внешние файлы должны располагаться по отношению к основанному на GSDML файлу в подкаталоге. Имя подкаталога должно быть построено из двухбуквенного кода языка внешнего файла (ИСО 639-1:2002).
Кодировка XML файла (например, UTF-8) не определяется в GSDML. Допускается любая кодировка, соответствующая правилам спецификации XML.
В расширениях GSDML схемы имена элементов и атрибутов должны быть составлены следующим образом:
- первый символ должен быть либо десятичным числом («0» — «9»), либо прописной буквой в диапазоне от «A» до «Z»;
- последующие символы должны быть из диапазонов от «0» до «9» или от «a» до «z». Прописные буквы в диапазоне от «A» до «Z» также могут быть использованы для улучшения читаемости;
- аббревиатуры должны использоваться в виде прописных букв, за которыми следует символ «_», когда следом идут один или несколько символов;
- первый символ после символа «_» должен быть или десятичным числом («0» — «9»), или прописной буквой в диапазоне от «A» до «Z».
Примечание. В GSD до версии 5 символ «_» часто использовался для разделения частей ключевых слов в целях приведения ключевых слов к более удобному для чтения виду. Иногда для той же цели использовались буквы верхнего и нижнего регистров.
D.4. Описание элемента
D.4.1. Общие положения
D.4.2. Относящиеся к идентичности устройства элементы
Содержит общую информацию об устройстве.
Атрибуты элемента DeviceIdentity
D.4.2.2. DeviceIdentity/InfoText
Содержит читаемую человеком дополнительную текстовую информацию об устройстве.
Каждый элемент должен включать в себя не менее чем один атрибут согласно таблице D.4.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| TextId | Токен | Требуемое | Содержит ID текста как ссылку на ExternalTextList (Внешний ТекстСписок) (см. D.4.4.24) |
D.4.2.3. DeviceIdentity/VendorName
Содержит имя поставщика устройства.
Каждый элемент должен содержать атрибут согласно таблице D.5.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| Value | Токен | Требуемое | Содержит имя поставщика устройства |
D.4.3. Относящиеся к функции устройства элементы
D.4.3.2. DeviceFunction/Family
Устройству должен быть присвоен класс функции. Помимо основного семейства устройству может быть присвоено зависящее от поставщика семейство продуктов.
D.4.4. Относящиеся к процессу приложения элементы
D.4.4.1. DeviceAccessPointList
GSDML должен содержать информацию относительно одной или более различных точек доступа в одном семействе. Этот элемент содержит список установленных DAP.
Данный список содержит все модули, описанные в основанном на GSDML файле.
D.4.4.3. ModuleList/ModuleItem
Данный элемент содержит субэлементы для описания характеристик модуля.
Каждый элемент должен содержать атрибуты согласно таблице D.7.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| ID | IdT | Требуемое | Содержит уникальный ID для ссылки из элемента UseableModules/ModuleItemRef (см. D.4.5.5). Должен быть совместимым вверх от GSD (см. ИСО 15745-3:2003, приложение B). Значение ID должно быть таким же, как параметр Module_Reference ключевого слова Module в GSD (см. ИСО 15745-3:2003, приложение B) |
| ModuleIdentNumber | NormalizedString | Требуемое | Содержит Номер Идентификации Модуля для Модуля. Значение должно соответствовать следующему регулярному выражению: 0x[0-9,a-f,A-F]{1,8} |
D.4.4.4. ModuleList/ModuleItem/ModuleInfo
См. D.4.7.
D.4.4.5. ModuleList/ModuleItem/VirtualSubmoduleList
См. D.4.6.
См. D.4.7.
Элемент ValueList содержит элементы для присваивания значений текстовым строкам.
Элемент ValueItem группирует все объекты значений, и на него может производиться ссылка из элемента «UserDataItem/Data».
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| ID | IdT | Требуемое | Содержит ID элемента ValueItem, на который производится ссылка из атрибута TextTarget элемента Ref |
Элемент Help содержит дополнительную вспомогательную информацию о параметре ValueItem.
Каждый элемент должен содержать не менее одного атрибута согласно таблице D.9.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
D.4.4.10. ValueList/ValueItem/Assignments
Данный элемент содержит неограниченное число элементов «Assign».
D.4.4.11. ValueList/ValueItem/Assignments/Assign
Элемент Assign содержит присваивание от содержания параметра до текстового представления.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| Content | NormalizedString | Требуемое | Содержит значение для присваивания текстовой ссылке. Значение должно соответствовать следующему регулярному выражению: -?[\d+]{1,20}. Внутри элемента Assignments атрибут Content всех дочерних элементов Assign должен быть уникальным |
| TextId | Токен | Требуемое | Содержит ID зависящего от языка текста в ExternalTextList (см. D.4.4.24). Внутри элемента Assignments атрибут TextId всех дочерних элементов Assign должен быть уникальным |
Устанавливает список специфических для канала — текстов ошибок.
Примечание. Используется для вспомогательной информации.
ChannelDiagItem содержит атрибуты для определения типа ошибок конкретного канала.
Каждый элемент должен содержать атрибуты согласно таблице D.11.
Атрибуты элемента ChannelDiagItem
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| ErrorType | Unsigned16 | Требуемое | Содержит тип ошибки, где могут быть присвоены определения диагностического текста |
D.4.4.14. ChannelDiagList/ChannelDiagItem/Name
Содержит зависящую от языка текстовую информацию.
Каждый элемент должен содержать атрибуты согласно таблице D.12.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
D.4.4.15. ChannelDiagList/ChannelDiagItem/Help
Содержит зависящую от языка вспомогательную информацию.
Каждый элемент должен содержать атрибуты согласно таблице D.13.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
UnitDiagTypeList присваивает диагностические значения специальным сообщениям изготовителя о статусе и ошибках.
Каждый элемент должен содержать атрибуты согласно таблице D.14.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| UserStructureIdentifier | Unsigned16 | Требуемое | Описывает UserStructureIdentifier блока запроса тревоги. UserStructureIdentifier должен быть в диапазоне от «0» до «32767». Внутри UnitDiagTypeList (см. D.4.4.16) UserStructureIdentifier должен быть уникальным |
D.4.4.18. UnitDiagTypeList/UnitDiagTypeItem/Ref
Элемент Ref содержит информацию об элементе диагностических данных в объекте данные тревоги.
Этот элемент должен иметь такие же атрибуты, как определенные в D.4.7.4.
Атрибут «ByteOffset» этого элемента ссылается на блок «additional alarm info» в PDU запроса тревоги — информация заголовка не включена.
Данный элемент содержит список GraphicItems (см. D.4.4.20).
GraphicItem содержит информацию по символическому представлению Устройства, Модуля или Субмодуля.
Каждый элемент должен содержать атрибуты согласно таблице D.15.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| ID | IdT | Требуемое | Содержит ID элемента GraphicItem, на который производится ссылка из элемента Graphics/GraphicItemRef (см. D.4.8.10) |
| GraphicFile | Строка | Требуемое | Содержит имя файла без расширения. Формат зависит от типа GraphicItem, который определяется атрибутом Type элемента GraphicItemRef |
D.4.4.21. GraphicsList/GraphicItem/Embedded
Данный элемент используется для описания графической информации внутри основанного на GSDML файла в формате SVG (см. REC-svg-20030114).
Примечание. Масштабируемая векторная графика (SVG) представляет собой язык для описания двумерной векторной и смешанной векторно/растровой графики в XML.
Данный элемент содержит список элементов CategoryItem (см. D.4.4.23).
Примечание 1. GSDML допускает построение категорий модулей и субмодулей. Эти категории могут быть использованы для группировки модулей и субмодулей внутри каталога инженерного инструмента. Например, все модули аналогового ввода могут быть помещены в одну секцию каталога. Это упрощает поиск требуемых модулей пользователем или инженерным инструментом.
Примечание 2. Присвоение категории модуля не влияет на характеристики времени выполнения модуля или субмодуля.
CategoryItem определяет информацию внутри одной категории.
Каждый элемент должен содержать атрибуты согласно таблице D.16.
Атрибуты элемента CategoryItem
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| ID | IdT | Требуемое | Содержит ID элемента CategoryItem, на который производится ссылка из атрибута CategoryRef или SubCategory1 Ref элемента ModuleInfo (см. D.4.8.1) |
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
ExternalTextList содержит зависящие от языка текстовые строки.
D.4.4.25. ExternalTextList/PrimaryLanguage
Элемент PrimaryLanguage содержит текстовые определения первичного языка, который должен использоваться, если текст на выбранном языке недоступен. В случае GSDML первичным языком является английский.
D.4.4.26. ExternalTextList/PrimaryLanguage/Text
Элемент Language содержит текстовое определение указанного языка.
Применение: один для каждого языка.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| xml:lang | xsd:language | Требуемое | Определяет язык текста в субэлементах Text/@Value |
Атрибуты: см. таблицу D.17.
D.4.5. Элементы, относящиеся к DeviceAccessPoint
D.4.5.1. DeviceAccessPointItem
Данный элемент описывает характеристики DAP.
Применение: один для каждого DAP.
Каждый элемент должен содержать атрибуты согласно таблице D.19.
Атрибуты элемента DeviceAccessPointItem
| Имя | Тип | Применение | Описание |
| ID | ID | Требуемое | Содержит ID элемента |
| PhysicalSlots | ValueList | Требуемое | Данный список описывает, какие слоты поддерживаются DAP. Слотномер DAP сам должен быть частью списка |
| ModuleIdentNumber | NormalizedString | Требуемое | Содержит Module Ident Number модуля. Его значение должно соответствовать следующему регулярному выражению: 0x[0-9,a-f,A-F]{1,8} |
| MinDeviceInterval | Unsigned16 | Требуемое | Данное время устанавливает минимальный интервал для посылки циклических данных ввода-вывода (IO). Базовый такт часов равен 31,25 микросекунды. Значение этого элемента содержит множитель базового такта часов (см. пример) |
| ImplementationType | NormalizedString | Опциональное | Содержит описание стандартного выполнения в DAP, например решения в виде стандартного программного обеспечения, контроллера или ASIC (Специальной интегральной схемы приложения) |
| DNS_CompatibleName | NormalizedString | Требуемое | Описывает имя по умолчанию устройства в соответствии с правилами для Системы имен доменов (DNS) согласно RFC 1101 (см. примечание) |
| ExtendedAddressAssignmentSupported | Boolean | Опциональное | Для PROFINET IO каждое устройство IO должно выполнять Discovery и Configuration protocol (DCP) при назначении адресов IP. Если DAP поддерживает другой способ назначения адресов IP типа Dynamic Host Configuration Protocol (Протокол динамической конфигурации хоста) (DHCP) согласно RFC 2131, этот атрибут должен быть установлен на «истина». По умолчанию: «ложь» |
| AllowedInSlots | ValueList | Опциональное | Определяет, на какие слоты DAP могут быть поставлены. Если не определено, DAP не может быть поставлено на другие слоты, кроме указанных в атрибуте «FixedInSlots» |
| FixedInSlots | ValueList | Требуемое | Определяет номер слота в DAP, когда устройство конфигурируется в инженерном инструменте. Для нерезервных DAP только один номер слота разрешается в списке. Рекомендуется использовать «0» как слотномер. Если атрибут «AllowedInSlots» используется, определенные в «FixedInSlots» слоты должны быть подмножеством слотов, определенных атрибутом «AllowedInSlots» |
| ObjectUUID_LocalIndex | Unsigned16 | Требуемое | Устанавливает поле Instance объекта UUID |
| Пример — MinDeviceInterval=32 означает, что устройство способно посылать/получать данные каждую миллисекунду. | |||
| Примечание. Атрибут DNS_CompatibleName может быть использован инженерной системой для построения уникального имени станции. | |||
См. D.4.8.1.
Данный элемент содержит информацию о количестве данных IO.
Каждый элемент должен содержать атрибуты согласно таблице D.20.
Атрибуты элемента IOConfigData
Элемент UseableModules содержит список модульных ссылок, ссылающихся на модули элемента ModuleList. Только модули из этого списка совместимы с DAP.
Инженерный инструмент не должен производить конфигурацию других модулей для данного DAP.
D.4.5.5. UseableModules/ModuleItemRef
Данный элемент ссылается на модуль в ModuleList, совместимый с DAP.
Каждый элемент должен содержать атрибуты согласно таблице D.21.
Атрибуты элемента ModuleItemRef
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| ModuleItemTarget | RefIdT | Требуемое | Ссылки на элемент ModuleList/ModuleItem (см. D.4.4.3) |
| AllowedInSlots | ValueList | Опциональное | Определяет, в какие слоты модуль может быть помещен. Если этот атрибут не определен, модуль может быть помещен в любой слот |
| UsedInSlots | ValueList | Опциональное | Определяет, в какие слоты модуль помещается по умолчанию. Эти встроенные модули могут быть удалены с помощью инженерного инструмента. Если используется атрибут AllowedInSlots, слоты, определенные в UsedInSlots, должны быть подмножеством слотов, определенных атрибутом AllowedInSlots |
| FixedInSlots | ValueList | Опциональное | Определяет, в какие слоты модуль помещается по умолчанию. Эти встроенные модули не могут быть удалены с помощью инженерного инструмента. Если используется атрибут AllowedInSlots, слоты, определенные в FixedInSlots, должны быть подмножеством слотов, определенных атрибутом AllowedInSlots |
Данный элемент содержит список элементов VirtualSubmoduleItem (см. D.4.6.1).
D.4.5.7. VirtualSubmoduleList/VirtualSubmoduleItem
См. D.4.6.1.
См. D.4.7.
D.4.5.9. Graphics/GraphicItemRef
См. D.4.7.
D.4.5.10. ApplicationRelations
Данный элемент содержит информацию относительно отношений приложений, выполняемых с помощью Устройства IO.
Атрибуты VersionInformation необходимы для проверки, соответствует или нет структура соединения PDU (iPNIO_D_Connect-REQ-PDU) функциональным характеристикам Устройства IO. Инженерный инструмент должен заполнить информацию о версии по соединению PDU с помощью этого атрибута.
Каждый элемент должен содержать атрибуты согласно таблице D.22.
Атрибуты элемента ApplicationRelations
D.4.5.11. ApplicationRelations/TimingProperties
Данный элемент описывает временное поведение при посылке циклических данных IO.
Атрибуты элементов TimingProperties
| Имя | Тип | Применение | Описание |
| SendClock | ValueList | Опциональное | Поддерживает список времени циклов, поддерживаемых DAP при посылке циклических данных. Базовый такт часов равен 31,25 микросекунды. Каждое значение этого элемента содержит множитель базового такта часов и может быть в диапазоне от «1» до «128» (см. пример). По умолчанию — «32» |
| ReductionRatio | ValueList | Опциональное | Интервал часов при посылке может быть уменьшен путем сжатия. Этот атрибут описывает поддерживаемые значения коэффициентов сжатия DAP. Каждое значение этого элемента должно быть в диапазоне от «1» до «16384» |
| Пример — SendClock= «16, 32, 64» означает, что DAP способен посылать циклические данные с интервалом 500 мкс, 1 мс или 2 мс. | |||
D.4.6. Элементы подмодулей
Данный элемент описывает характеристики подмодуля в качестве части модуля.
Каждый элемент должен содержать атрибуты согласно таблице D.24.
Атрибуты элемента VirtualSubmoduleItem
Каждый элемент должен содержать атрибуты согласно таблице D.25.
Определяет входные характеристики субмодуля. Если входные данные имеются, этот элемент имеет элементы DataItem (см. D.4.6.4).
Каждый элемент должен содержать атрибуты согласно таблице D.26.
D.4.6.4. VirtualSubmoduleItem/IOData/Input/DataItem
Элемент DataItem содержит информацию относительно одного DataItem.
Применение: один для каждого DataItem.
Каждый элемент должен содержать атрибуты согласно таблице D.27.
| Атрибуты элемента DataItem | Имя | Тип | |
| Применение | Описание | DataType | Enumeration Требуемое Определяет тип данных элемента данных. Разрешается одно из следующих значений: «Integer8» «Integer16» «Integer32» «Integer64» «Unsigned8» «Unsigned16» «Unsigned32» «Unsigned64» «Float32» «Float64» «Date» «TimeOfDay with date indication» «TimeOfDay without date indication» «TimeDifference with date indication» «TimeDifference without date indication» «NetworkTime» «NetworkTimeDifference» |
| «VisibleString» | «OctetString» | Length | Unsigned16 |
| Опциональное | |||
| Этот атрибут должен быть использован, если атрибут DataType установлен на «VisibleString» или «OctetString». | |||
| Этот атрибут устанавливает длину элемента DataItem в октетах. | Если этот атрибут использован для типов данных с заданием фиксированной длины, длина должна соответствовать определению в МЭК 61158-5 | UseAsBits | Булев Опциональное |
| Если атрибут установлен на «истина», инженерная система должна отобразить элемент данных в битовом представлении. | По умолчанию «ложь» | TextId | Токен |
| Требуемое Содержит ID текста в качестве ссылки на «ExternalTextList» (см. D.4.4.24) | |||
| a Это необходимо, поскольку эти типы данных имеют переменную длину. | |||
D.4.6.5. VirtualSubmoduleItem/IOData/Output
Элемент вывода устанавливают характеристики вывода подмодуля. Если данные вывода имеются, этот элемент содержит элементы DataItem (см. D.4.6.6).
Атрибуты: см. D.4.6.3.
D.4.6.6. VirtualSubmoduleItem/IOData/Output/DataItem
Элемент DataItem содержит информацию относительно одного DataItem.
Атрибуты: см. D.4.6.4.
D.4.6.7. VirtualSubmoduleItem/RecordDataList
Данный элемент содержит список ParameterRecordDataItem (см. D.4.7.1).
D.4.6.8. VirtualSubmoduleItem/ModuleInfo
См. D.4.8.1.
D.4.6.9. VirtualSubmoduleItem/Graphics
См. D.4.8.9.
D.4.7. Элементы, относящиеся к RecordDataList
D.4.7.1. ParameterRecordDataItem
Элемент ParameterRecordDataItem описывает структуру данных объекта данных регистрации параметра.
Примечание. Все параметры в ParameterRecordDataItems будут переданы в субмодуль в ходе процедуры запуска устройства IO.
Каждый элемент должен содержать атрибуты согласно таблице D.28.
Элемент Name дает объекту регистрации данных читаемое человеком имя.
Примечание. Это дает возможность инженерному инструменту выполнить группировку объектов данных объекта регистрации данных таким образом, чтобы, например, при диалоге можно было использовать это имя в качестве названия диалога.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
Элемент Const используется для инициализации содержания объекта данных регистрации. Если определение Const не описывает полное содержание объекта данных регистрации, неопределенные поля должны быть установлены на нуль.
Если элемент Const пропущен, объект данных регистрации инициализируется с помощью октетов, установленных на нуль.
Если определен более чем один элемент Const, перекрытие между определениями не допускается.
Каждый элемент должен содержать атрибуты согласно таблице D.30.
| Имя | Тип | Применение | Описание |
| ByteOffset | Unsigned32 | Опциональное | Содержит сдвиг в октетах объекта ссылочных данных от начала объекта данных регистрации. По умолчанию: «0». Длина определения Const должна быть меньше или равна атрибуту Length элемента RecordDataItem |
| Data | NormalizedString | Требуемое | Содержит контент данных объекта данных регистрации, начиная от «ByteOffset» (см. пример). Строка разделена на шестнадцатеричные лексемы и должна выполнять правила следующего регулярного выражения: (0x[0-9,a-f,A-F][0-9,a-f,A-F],?){1,} |
| Пример — 0x10,0xff, 0x4A | |||
D.4.7.4. VirtualSubmoduleItem/RecordDataList/RecordDataItem/Ref
Данный элемент ссылается на объект данных в блоке данные регистрации.
Так как этот элемент может описывать тот же самый объект, как элемент «const», может возникнуть перекрытие. В этом случае необходимо использовать определение «Ref».
Каждый элемент должен содержать атрибуты согласно таблице D.31.
| Имя | Тип | Применение | Описание |
| ValueItemTarget | RefIdT | Опциональное | Ссылки на элемент ValueDataItem, содержащий имя и диапазон значений объекта данные |
| ByteOffset | Unsigned32 | Требуемое | Содержит сдвиг в октетах ссылочного объекта данные от начала объекта данные регистрации |
| BitOffset | NormalizedString | Опциональное | Содержит сдвиг в битах ссылочного объекта данные от начала ссылочного октета. Правильный диапазон: 0..7. По умолчанию: 0. Может быть использован только в связи с типом данных «Bit» или «BitArea» |
| BitLength | Unsigned8 | Опциональное | Если тип этого объекта данных «BitArea», этот атрибут устанавливает длину этого поля. Атрибут игнорируется, если используется другой тип данных. По умолчанию: «1». BitLength должен быть в диапазоне от «1» до «15» |
| DataType | Enumeration | Требуемое | Устанавливает тип объекта данные. Используется одно из следующих значений: «Bit» «BitArea» (см. примечание) «Integer8» «Integer16» «Integer32» «Signed64» «Unsigned8» «Unsigned16» «Unsigned32» «Unsigned64» |
| DefaultValue | NormalizedString | Требуемое | Содержит значение по умолчанию для параметра. Это значение должно соответствовать следующему регулярному выражению: \-?[\d+]{1,20} |
| AllowedValues | SignedValueList | Опциональное | Устанавливает возможные значения этого параметра. Если этот атрибут не используется, должны применяться следующие правила: - если используется атрибут ValueItemTarget, диапазон значений параметра определяется атрибутом Content элемента Assignments ссылочного ValueItem; - если атрибут ValueItemTarget не используется или ссылочный ValueItem не содержит элементы Assignments, диапазон значений параметра определяется типом данных, определенным атрибутом DataType; - если атрибуты AllowedValues и ValueItemTarget используются оба, атрибут AllowedValues должен содержать только значения, определенные как атрибут Content элементов Assignments ссылочного ValueItem; - если ValueItem не содержит элементы Assignments, правильными являются все значения в диапазоне значений типа данных для AllowedValues |
| Changeable | Булев | Опциональное | Если данный атрибут установлен на «ложь», никакие изменения данного параметра не допускаются. По умолчанию = «истина» |
| Visible | Булев | Опциональное | Если данный атрибут установлен на «ложь», этот параметр не будет отображаться в инженерном инструменте. Установка «ложь» не имеет смысла в комбинации с «Changeable» = «истина». Схема не способна воспринимать это взаимное исключение. По умолчанию: «истина» |
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
| Примечание. Тип данных «BitArea» может быть использован для уменьшения размера объекта данные регистрации, поскольку он имеет переменную битовую длину. Например, если параметр может иметь только четыре различных значения, BitArea с длиной 2 бита достаточна. Параметр «BitArea» может содержать кодировки или отдельные биты. | |||
В следующем примере показано применение различных списков для описания модуля с объектом регистрации данных одного параметра и двух параметров:
D.4.8. Глобально используемые элементы
Каждый элемент должен содержать атрибуты согласно таблице D.32.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| CategoryRef | RefIdT | Опциональное | Содержит категорию модуля. Значение CategoryRef должно содержать ID элемента CategoryList/CategoryItem (см. D.4.4.23) |
| SubCategory1Ref | RefIdT | Опциональное | Внутри категории могут быть созданы субкатегории. Значение CategoryRef должно содержать элемент CategoryList/ CategoryItem (см. D.4.4.23) |
Каждый элемент должен содержать атрибуты согласно таблице D.33.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
Элемент InfoText содержит читаемую человеком текстовую информацию о модуле или субмодуле.
Каждый элемент должен содержать атрибуты согласно таблице D.34.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| TextId | Токен | Требуемое | Содержит ID текста в качестве ссылки на ExternalTextList (см. D.4.4.24) |
D.4.8.4. ModuleInfo/VendorName
Элемент VendorName содержит имя продавца устройства. Если этот элемент отсутствует, следует использовать имя поставщика в элементе «DeviceInfo/Vendorname».
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| Значение | Токен | Требуемое | Содержит имя продавца устройства |
Каждый элемент должен содержать атрибуты согласно таблице D.36.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| Значение | Токен | Требуемое | Содержит номер заказа модуля или субмодуля |
D.4.8.6. ModuleInfo/HardwareRelease
Элемент HardwareRelease содержит выпуск аппаратуры модуля или субмодуля.
Каждый элемент должен содержать атрибуты согласно таблице D.37.
Атрибуты элемента HardwareRelease
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| Значение | Токен | Требуемое | Содержит выпуск аппаратуры модуля или субмодуля |
D.4.8.7. ModuleInfo/SoftwareRelease
Содержит выпуск программного обеспечения модуля/субмодуля.
Каждый элемент должен содержать атрибуты согласно таблице D.38.
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| Значение | Токен | Требуемое | Содержит выпуск программного обеспечения модуля или субмодуля |
См. D.4.3.2.
Элемент Graphics содержит список GraphicItemRef (см. D.4.8.10).
D.4.8.10. Graphics/GraphicItemRef
Элемент GraphicItemRef дает ссылку на графическую информацию о модуле или субмодуле устройства.
Каждый элемент должен содержать атрибуты согласно таблице D.39.
Атрибуты элемента GraphicItemRef
| Имя | Тип | Применение | Описание |
|---|---|---|---|
| Тип | Нумерация | Требуемое | Описывает тип графического элемента. Может быть использовано одно из следующих значений: «DeviceSymbol»; «DeviceIcon». Внутри одного элемента «Graphics» должна использоваться только одна ссылка GraphicItemRef одного типа. Если используется тип «DeviceSymbol», присвоенный элемент GraphicItem должен быть растровым файлом в формате DIB [70 x 40 пикселей (ширина x высота), 16 цветов]. В случае DeviceAccessPointItem элемент GraphicItem должен представлять устройство. Для модулей и субмодулей элемент GraphicItem должен представлять модуль или субмодуль. Если используется тип «DeviceIcon», присвоенный элемент GraphicItem должен быть файлом в формате иконки |
| GraphicItemTarget | RefIdT | Требуемое | Ссылка на элемент GraphicsList/GraphicItem (см. D.4.4.20) |
D.5. Схемы GSDML шаблона профиля устройства
Примечание. Приведенные ниже определения схемы используют xml.xsd. Этот файл схемы предоставлен World Wide Web Consortium. W3C предлагает загрузить этот файл, используя идентификатор пространства имен в качестве URL.
D.5.2. Схема GSDML профиля устройства (GSDML-DeviceProfile-v1.0.xsd)
5.3 Схема GSDML профиля сети коммуникаций GSDML-CommNetwork-v1.0.xsd
D.5.4. Схема GSDML примитивов (GSDML-Primitives-v1.0.xsd)
СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ
ССЫЛОЧНЫМ НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ
| Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
| ИСО 639-1:2002 | <*> | |
| ИСО 639-2:1998 | <*> | |
| ИСО 15745-1:2003 | <*> | |
| ИСО/МЭК 7984-4:1989 | <*> | |
| ИСО/МЭК 8802-3:2000 | <*> | |
| ИСО/МЭК 10646-1:2000 | <*> | |
| МЭК 61158 (все части) | <*> | |
| ИСО 15745-3:2003 | <*> | |
| ИСО 3166-1:1997 | <*> | |
| ИСО 11898:1993 | <*> | |
| ИСО/МЭК 11578:1996 | <*> | |
| МЭК 61784-1:2003 | <*> | |
| МЭК 62026-3:2000 | <*> | |
| <*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. | ||
БИБЛИОГРАФИЯ
1. МЭК/ТО 13283:1998 Промышленная автоматизация. Критичные по времени архитектуры сообщений. Требования потребителей и сетевое управление для систем сообщений, критичных по времени
(ISO/TR 13283:1998) (Industrial automation. Time-critical communications architectures. User requirements and network management for time-critical communications systems)
2. МЭК/PAS 61499-1:2000 Блоки функциональные для систем измерения и управления производственными процессами. Часть 1. Архитектура
(IEC/PAS 61499-1:2000) (Function blocks for industrial-process measurement and control systems. Part 1: Architecture)
3. МЭК/ТС 61915:2003 Комплектные распределительные устройства низковольтные. Принципы разработки приборных профилей для сетевых промышленных устройств
(IEC/TS 61915:2003) (Function blocks for industrial-process measurement and control systems. Part 1: Architecture)
4. MSTC/JOP 1101:1999 Specification Autonimous Decentralised Protocol R3.0
5. ODVA/CI EtherNet/IP:2001 EtherNet/IP Specification (Release 1/0)
6. МЭК 61131-8:2003 Контроллеры программируемые. Часть 8. Руководящие указания по применению и реализации языков программирования
(IEC 61131-8:2003) (Programmable controllers — Part 8: Guidelines for the application and implementation of programming languages)
7. МЭК/PAS 61804-2:2002 Блоки функциональные (FB) для управления процессом. Часть 2. Спецификация концепции FB и языка описания электронного устройства (EDDL)
(IEC/PAS 61804-2:2002) [Function blocks (FB) for process control
- Part 2: Specification of FB concept and Electronic Device Description Language (EDDL)]
8. ИСО 2382 (все части) Информационные технологии — Словарь (ISO 2382 (all parts) (Information technology — Vocabulary)
9. ISO/AFNOR Dictionary of Computer Science (1997).
------------------------------------------------------------------
