ПНСТ 177-2016 Формат обмена инженерными данными для использования в системах промышленной автоматизации. Стандартизированный формат обмена данными AutomationML. Часть 1. Архитектура и общие требования

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ПРЕДВАРИТЕЛЬНЫЙ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

пнет

177—

2016/

МЭК 62714-1— 2014

ФОРМАТ ОБМЕНА ИНЖЕНЕРНЫМИ ДАННЫМИ ДЛЯ ИСПОЛЬЗОВАНИЯ В СИСТЕМАХ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ

Стандартизированный формат обмена данными

AutomationML

Ч асть 1

Архитектура и общие требования

(IEC 62714-1:2014, ЮТ)

Издание официальное

СШ1ЛТТ№фП|М

2017

ПНСТ 177—2016

Предисловие

1 ПОДГОТОВЛЕН ООО «НИИ экономики связи и информатики «Интврэкомс» (ООО «НИИ «Интер* экомс») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

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

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

4 Настоящий стандарт идентичен международному стандарту (ЕС 62714*1:2014 «Формат обмена инженерными данными для использования в системах промышленной автоматизации. Стандартизированный формат обмена данными AutomationML. Часть 1. Архитектура и общие требования» (IEC 62714*1:2014 «Engineering data exchange format for use in industrial automation systems engineering — Automation markup language — Part 1: Architecture and general requirements». IDT).

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

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за девять месяцев до истечения срока его действия разработчику настоящего стандарта по адресу: 123423 Москва, ул. Народного Ополчения, д.32. и в Федеральное агентство по техническому регулированию и метрологии по адресу: 109074 Москва. Китайгородский проезд, д.7. стр. 1.

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

© Стандартинформ. 2017

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

II

ПНСТ 177—2016

Содержание

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

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

3 Термины, определения и сокращения.................................................. 2

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

3.2 Сокращения.................................................................... 3

4 Соответствие настоящему стандарту.................................................. 4

5 Спецификация архитектуры AutomationML.............................................. 4

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

5.2 Архитектура языка AutomationML.................................................. 4

5.3 Версии документов языка AutomationML............................................ 5

5.4 Метаинформация об инструментальных средствах источника AutomationML.............. 6

5.5 Идентификация объекта......................................................... 7

5.6 Спецификация отношений языка AutomationML...................................... 9

5.7 Спецификация ссылки на документ языка AutomationML...............................13

6 Базовые библиотеки языка AutomationML............................................... 15

6.1 Введение...................................................................... 15

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

6.3 Библиотека класса интерфейсов AutomationML — AutomationMUnterfaceClassLib..........15

6.4 Базовая библиотека ролевых классов AutomationML— AutomationMLBaseRoleClassLib.....19

7 Моделирование пользовательских данных..............................................25

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

7.2 Пользовательские атрибуты......................................................25

7.3 Пользовательский класс интерфейсов InterfaceCtass .................................26

7.4 Пользовательский ролевой класс RoteClass.........................................26

7.5 Пользовательский класс системных единиц SystemUnitClass...........................28

7.6 Пользовательские иерархии экземпляров InstanceHierarchies...........................28

8 Расширенные понятия языка AutomationML.............................................29

8.1 Общий положения..............................................................29

8.2 Объект порт AutomationML Port....................................................29

8.3 Объект фасет AutomationML Facet.................................................30

8.4 Объект группа AutomationML Group.................................................30

8.5 Набор свойств AutomationML PropertySet............................................31

8.6 Поддержка нескольких ролей.....................................................31

8.7 Разбиение данных AutomationML верхнего уровня на различные документы...............34

8.8 Интернационализация...........................................................34

8.9 Информация о версии объекта AutomationML........................................34

Приложение А (справочное) Введение в язык AutomationML..................................35

Приложение 8 (справочное) Представление библиотек AutomationML на языке XML.............64

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам..............................................66

Библиография....................................................................... 67

ПНСТ 177—2016

Введение

Комплекс стандартов МЭК 62714 определяет инженерное решение проблемы обмена данными для домена автоматизации производства.

Формат обмена данными, определенный в МЭК 62714 (язык разметки автоматизации Automa-UonML). — ато формат обмена данными, основанный на XML языке. Он разработан для поддержки обмена данными на неоднородном множестве инструментальных средств инженерии.

Цель языка AutomationML состоит в обеспечении взаимосвязи инструментальных средств инженерии в различных областях: проектирование механизированного оборудования, электротехническое проектирование, проектирование и управление производственными процессами, разработка человеко-машинного интерфейса (HMI), программирование логического контроллера (PLC), программирование роботов и т. д.

Язык AutomationML также предназначен для хранения инженерной информации в соответствии с объектно-ориентированной парадигмой, что позволяет моделировать физические и логические компоненты производственных объектов как объекты данных, инкапсулирующие различные аспекты. Указанные объекты могут состоять из вложенных объектов (подобъектов), которые сами могут являться частью композиции или агрегации. Типовые объекты автоматизированных установок включают в себя информацию о топологии, геометрии, кинематике и логике. При этом логика учитывает последователь-ность/упорядоченность. а также поведенческие и управленческие аспекты. Таким образом, целью обмена данными в инженерном домене является обмен объектно-ориентированными структурами данных топологии, геометрии, кинематики и логики.

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

Ядром языка AutomationML является формат данных верхнего уровня САЕХ. Он соединяет различные форматы данных. Таким образом, язык AutomationML имеет унаследованную распределенную архитектуру документов.

Рисунок 1 иллюстрирует базовую архитектуру языка AutomationML. а также распределение информации о топологии, геометрии, кинематике и логике.

Automation Markup Language — язык разметки автоматизации AulomalionML; Engineering data — инженерные данные; САЕХ IEC 62424 top level formal — формат верхнего уровня САЕХ е соответствии с МЭК 62424; Planl topology л formation — информация о топологии производственной установки. Plants — производственные установки; Cats — производственные ячейки. Components — компоненты. Attributes — атрибуты. Interfaces — интерфейсы; Relations — соотношения; Refeiences — ссылки: Object А — объект A; Geometry — геометрия. Kinematics — кинематика. Behaviour — поведение. Sequencing — последовательность: PLCopen XML — XML язык для открытого программируемого логическою контроллера: Further XML standard formal — прочие стандартные форматы языка XML. Further aspects of engineering information — прочие аспекты инженерной информации

Рисунок 1 — Обзор формата обмена инженерными данными — языка AutomationML

«V

ПНСТ 177—2016

Комплекс стандартов МЭК 62714 состоит из нескольких частей, распространяющихся на различные аспекты языка AutomationML:

• МЭК 62714-1: Архитектура и общие требования.

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

• МЭК 62714-2: библиотека ролевых классов.

Данный стандарт содержит описание дополнительных библиотек AutomationML.

- МЭК 62714-3: Геометрия и кинематика.

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

- МЭК 62714-4: Логика.

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

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

8 приложении А содержится справочная информация, рассматриваются примеры использования языка AutomationML.

8 приложении В представлены библиотеки на XML языке, определенные в настоящем стандарте.

V

ПНСТ 177—2016/ МЭК 62714-1—2014

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

ФОРМАТ ОБМЕНА ИНЖЕНЕРНЫМИ ДАННЫМИ ДЛЯ ИСПОЛЬЗОВАНИЯ В СИСТЕМАХ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ

Стандартизированный формат обмена данными AutomationML

Часть 1

Архитектура и общие требования

Engineering data exchange format for use in industrial automation systems engineering. Automation markup language.

Part 1. Architecture and general requirements

Срок действия предстандарта — с 2017—06—01

до 2010—06—01

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

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

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

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

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

IEC 62424:2008. Representation of process control engineering — Requests in P&l diagrams and data exchange between P&IO tools and PCE-CAE tools (Представление технологии управления процессами. Запросы в диаграммах P&I и обмен данными между средствами P&l D и средствами РСЕ-САЕ)

IEC 62714 (all parts). Engineering data exchange format for use in industrial automation systems engineering — Automation markup language (Формат обмена инженерными данными для использования в системах промышленной автоматизации. Стандартизированный формат обмена данными AutomationML (все части IEC 62714))

ISO/IEC 9834-8:2014, Information technology — Procedures for the operation of object identifier registration authorities — Part 8: Generation of universally unique identifiers (UUIDs) and their use in object identifiers (Информационные технологии. Процедуры для работы регистрационных органов идентификаторов объектов. Часть 8. Создание универсальных уникальных идентификаторов и их использование в идентификаторах объектов)

ISO/PAS 17506:2012. Industrial automation systems and integration — COLLADA digital asset schema specification for 3D visualization of industrial data (Системы промышленной автоматизации и интеграция. Спецификация цифровой схемы активов COLLADA для трехмерной визуализации промышленных данных)

COLLADA 1.4.1 :Март 2008. COLLADA — Схема цифрового актива. Выпуск 1.4.1 (см. htto://www. khronos.oro/d^n/collada soec 1 4,odfl.

Расширяемый язык разметки XML 1.0 1.0:2004. рекомендации W3C (см. REC-xml-20040204A.

Расширяемый язык разметки XML для открытого программируемого PLC контроллера open 2.0: Декабрь. №3 2008, а также PLCopen XML 2.0.1: Май №8 2009. Форматы расширяемого языка разметки XML для МЭК 61131-3 (см. htto://www olcooen oro/l.

Издание официальное

1

ПНСТ 177—2016

3 Термины, определения и сокращения

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

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

3.1.1 язык разметки автоматизации AutomationML (AutomationML): Формат обмена данными на основе языка XML для инженерных данных производственного объекта в соответствии с МЭК 62714.

3.1.2 объект автоматизации (automation object): Физическая или логическая сущность в автоматизированной системе.

Примечание — Примером объекта автоматизации может быть компонент автоматизации (клапан, сигнал).

3.1.3 объект (языка) AutomationML (AutomationML object): Представление данных объекта автоматизации в соответствии с ролевыми классами языка AutomationML.

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

3.1.4 класс (языка) AutomationML (AutomationML ciass): Предварительно определенный тип объекта языка AutomationML.

Примечание 1 — Классы язька AutomationML хранятся в библиотеках языка AutomationML.

Примечание 2 — Классы языка AutomationML определяют повторно применяемые инженерные решения. характеризуемые атрибутами, интерфейсами и агрегированными объектами.

Примечание 3 — Классы языка AutomationML могут быть использованы для множественного инстанцирования.

3.1.5 атрибут (языка) AutomationML (AutomationML attribute): Свойство, принадлежащее объекту языка AutomationML.

Примечание — Атрибуты языка AutomationML описаны в качестве элементов расширяемого языка разметки XML. соответствующие МЭК 62424:2006. раздел А.2.4.

3.1.6 документ (языка) AutomationML (AutomationML document): Документы в формате САЕХ. соответствующие МЭК 62714 и включающие все ссылочные вспомогательные документы.

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

3.1.7 файл (языка) AutomationML (AutomationML file): Файлы в формате САЕХ. соответствующие настоящему стандарту и имеющие расширение «.ami* за исключением ссылочных вспомогательных файлов.

3.1.8 интерфейс (языка) AutomationML (AutomationML interface): Отдельные точки соединения, принадлежащие объекту языка AutomationML и соединяемые с другим интерфейсом.

Примечание — Интерфейсы обеспечивают огмеание соотношений между объектами путем задания внутренних связующих элементов (внутренних ссылок) САЕХ.

Пример — Интерфейс сигналов, интерфейс устройства, интерфейс питания.

3.1.9 библиотека (языка) AutomationML (AutomationML library): Библиотека, содержащая классы языка AutomationML.

3.1.10 порт (языка) AutomationML (AutomationML Port): Объект языка AutomationML. представляющий собой контейнер для группы интерфейсов, характеризуемых дополнительными свойствами.

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

3.1.11 группа (языка) AutomationML (AutomationML Group): Объект языка AutomationML. определяющий общее для некоторой совокупности объектов языка AutomationML представление конкретных аспектов.

3.1.12 фасет (языка) AutomationML (AutomationML Facet): Объект языка AutomationML, определяющий общее для некоторой совокупности атрибутов (интерфейсов) языка AutomationML представление конкретных аспектов для одного объекта языка AutomationML.

2

ПНСТ 177—2016

3.1.13 САЕХ (САЕХ): Нейтральный формат данных, основанный на XML языке.

Примечание — САЕХ — Это нейтральный формат данных, установленный е МЭК 62424:2008 (раздал 7. приложения А и С).

3.1.14 соотношение «копии—экземпляры» (copy-instance-relation): Соотношение между экземпляром и соответствующим классом, экземпляр которого создается путем копирования структур данных рассматриваемого класса.

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

3.1.15 универсальный уникальный идентификатор (universal unique identifier; UUID): Уникальный идентификатор объектов языка AutomationML.

3.1.16 глобальный уникальный идентификатор (global unique identifier: GUIO): Практическая реализация UUID.

Примечание 1 — Конкретный пример идентификатора GUIO: «{AC76BA86-7AD7-1033-7B44-А70000000000}».

П р и м еча н и е 2 — В соответствии с МЭК 62714, идентификаторы GUID также представимы 8 краткой форме, например. «GUID1», «GUID2» и т. д. Это облегчает их читаемость и действует как конкретный GUID.

3.1.17 соотношение наследования (inheritance relation); Соотношение между двумя классами языка AutomationML.

Примечание — Производный класс наследует все атрибуты и особенности родительского класса.

3.1.18 экземпляр (instance): Представление данных индивидуального физического или логического элемента.

Примечание — Экземпляры могут быть расширены, например, с помощью агрегированных объектов или атрибутов.

3.1.19 набор свойств PropertySel (PropertySet): Класс стандартных ролей языка AutomationML. содержащий набор предварительно семантически определенных атрибутов.

3.1.20 топология (topology): Иерархическая структура системы, визуализируемая в виде древа объектов.

Примечание — Топология может включать несколько иерархий, пересеченных структур и сетей объектов.

3.1.21 топология производственной установки (plant topology): Иерархическая структура производственной установки, визуализируемая е виде древа объектов.

3.1.22 публиковать (publish): Моделирование структуры данных внешнего документа при использовании формата САЕХ.

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

3.1.23 соотношение (relation): Ассоциация между объектами формата САЕХ.

Примечание—Примерами соотношений являются соотношения кпотомок-родигвгъ» и «класс-экземпляр класса».

3.1.24связующий элемент (link): Обеспечивает связь между объектами типа САЕХ Externallnterface (внешний интерфейс).

Примечание — Связующий элемент моделируется с помощью сущностей САЕХ Inter nalLinks (внутренние связи).

3.1.25 ссылка (reference): Ассоциация между сущностью САЕХ InternalElements (внутренние элементы) и информацией, хранящейся во внешней среде.

3.2 Сокращения

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

AutomationML — язык разметки автоматизации (Automation Markup Language);

3

ПНСТ 177—2016

CAE — автоматизированное проектирование (Computer Aided Engineering);

CAEX — нейтральный формат обмена данными (Computer Aided Engineering exchange);

COLLADA— совместное проектирование (Collaborative design activity);

GUID — глобальный уникальный идентификатор (Global unique identifier):

HMI — человеко-машинный интерфейс (Human machine interface);

ID — идентификатор (Identifier):

MES — автоматизированная система управления производством (Manufacturing execution system);

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

URL — унифицированный указатель ресурса (Uniform resource locator);

URI — унифицированный идентификатор ресурса (Uniform resource identifier);

UUID — универсальный уникальный идентификатор (Universal unique identifier);

XML — расширяемый язык разметки (Extensible Markup Language).

4 Соответствие настоящему стандарту

Для обеспечения соответствия требованиям настоящего стандарта в части поддержания языка AutomationML необходимо выполнение требований, содержащихся в разделах 5. 6. 7 и 8 настоящего стандарта.

5 Спецификация архитектуры AutomationML

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

Ядром языка AutomationML является формат данных верхнего уровня САЕХ. Это нейтральный формат данных, соответствующий требованиям МЭК 62424 (см. раздел 7. приложения А и С). Он сое* диняет установленные форматы инженерных данных по топологии, геометрии, кинематике, поведению систем и упорядоченности (последовательности) рассмотрения информации. Таким образом, базовой характеристикой языка AutomationML является унаследованная распределенная архитектура документов. фокусирующаяся на вышеуказанных инженерных аспектах.

Рисунки имеют исключительно иллюстративный характер. Графические представления не нормированы.

5.2 Архитектура языка AutomationML

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

Информация о топологии производственной установки: топология производственной установки (далее — установки) применяется как структура данных верхнего уровня для инженерной информации об установке. Она моделируется с помощью формата данных САЕХ в соответствии с МЭК 62424 (раздел 7. приложения А и С). Семантические расширения формата САЕХ описаны отдельно. Множественные пересекающиеся иерархические структуры используются с помощью понятия зеркального объекта, определенного в МЭК 62424 (А.2.14). Зеркальные объекты не могут модифицироваться. Все изменения производятся на главном объекте (master object).

Примечание1 — В соответствии с МЭК 62424 (раздел А2.14). если один объект языка AutomationML называют «зеркальным объектом» по отношенюо ко второму объекту языка AutomationML. то указанный второй объект языка AutomationML называется «главным объектом*. Зеркальный объект считается идентичным главному объекту. Это обеспечивает возможность разместить экземпляр одного объекта в различных иерархиях установки и. таким образом, позволяет моделировать сложные сети объектов с пересекающимися структурами.

Примечание2 — МЭК 62714 не модифицирует синтаксически формат данных САЕХ. В МЭК 62424 (раздел А. 1.2 и приложение D) приведен справочный обзор и дополнительные примеры по топологии установки.

Информация о ссылках и соотношениях: ссылки и соотношения хранятся в соответствии с разделами 5.6 и 5.7. Соотношения между элементами внешней информации хранятся с помощью САЕХ-механизмов. При необходимости, соответствующие партнеры по соединению/свяэи публикуются а описании топологии установки (в формате САЕХ)с помощью внешних интерфейсов САЕХ Externallnterface. Они выводятся из классов стандартных интерфейсов языка AutomationML. указанных е разделе 6.3.

Примечание 3 — Ссылки отображают связи объектов САЕХ с информацией, хранящейся во внешней среде. В разделе А.1.5 приведен справочный обзор рассматриваемых соотношений. Ссылки и публикации интерфейсов описаны в дополнительных частях МЭК 62714.

4

ПНСТ 177—2016

Примечание 4 — Соотношения отображают ассоциации между объектами САЕХ.

Информация о геометрии и кинематике: требуемая информация о геометрии и кинематике хранится е формате данных COLLADA™¹. Интерфейсы COLLADA. взаимосвязанные внутри формата верхнего уровня, должны быть опубликованы как внешние интерфейсы САЕХ Extemallnterface.

Примечание 5 — МЭК 62714 не требует модификации синтаксиса формата данных COLLADA. Обзорный пример порядка выполнения ссылки COLLADA (см. раздел А1.3). Подробности приведены в МЭК 62714-3.

Примечание 6 — С помощью информации о геометрии различных объектов COLLADA. полное представление формируется автоматически. Указанные файлы могут быть ссылочными из формата САЕХ. Их взаимосвязь может быть обеспечена механизмами связи САЕХ.

Информация о логике: информация о логике должна храниться в формате данных PLCopen XML. Если элементы логики (переменные, сигналы) должны быть взаимосвязаны внутри формата верхнего уровня, то они публикуются как внешние интерфейсы САЕХ Extemallnterface. Все элементы языка PLCopen XML. опубликованные внутри формата верхнего уровня, должны иметь уникальный идентификатор внутри данною языка.

Примечание 7 — Информация о лотке описывает последовательности действий и внутреннее поведение объектов, включающее входные/выходные связи и логические переменные. МЭК 62714 не требует модификации формата PLCopen XML. Обзор установленного порядка оформления ссылок на информацию о логике приведен в разделе А1.4. Подробности см. МЭК 62714-4.

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

Формат данных языка AutomationML не обеспечивает проверку совместимости ограничений, значений атрибутов, соотношений, ссылок или семантической корректности рассматриваемых данных. За это отвечает инструментальное средство (целевой инструмент), соответствующее приложение имлор-та/экспорта. Яэык AutomationML содержит только синтаксическое подтверждение рассматриваемого документа в контексте с задействованными схемами.

5.3 Версии документов языка AutomationML

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

Примечание 1 — Нормативные положения в части информации о версии, относящейся к рассматриваемым экземплярам объектов языка AutomationML. оодвделены в разделе 8.9. Порядок хранения специфической инструментальной метаинформации определен в разделе 5.4.

Нижеследующие положения определяют:

• корневой элемент САЕХ «CAEXFile» для каждого документа верхнего уровня языка AutomationML должен иметь дочерний элемент САЕХ «Additionallnformation»;

• указанный элемент дополнительной информации «Additionallnformation» должен иметь атрибут «AutomationMLVersion»:

• значение указанного атрибута «AutomationMLVersion» должно храниться в XML документе. В целях соответствия настоящему стандарту необходимо использовать версию «2.0»;

- каждый ссылочный документ САЕХ должен соответствовать аналогичной версии языка AutomationML корневого документа. Смешивание документов с различными версиями AutomationML запрещено:

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

Рисунок 2 иллюстрирует текст расширяемого языка разметки XML. составленный для документа САЕХ в соответствии с версией языка AutomationML 2.0.

^,u1 COLLADA — это фирменный продукт группы Khronos. Данная информация дается для удобства пользователей настоящего стандарта. Она не является официальным согласованием указанного продукта стандартом МЭК. Эквивалентные продукты также могут быть использованы, если их применение дает аналогичные результаты.

5

ПНСТ 177—2016

«CAEXFie xirtns xsi-Tittp: /A*vww. w3 org/2001 /XMLSchema-instance* xsi ixWarre space SchemeLocation*"

C AEX.CiassModel .xstP F4eName-^HAutomationM.StandtfdUbrery2010>01-14_v1 99.arT SchemaVersor^.l5”»

«AckMionaMnformcrtion AUomaboriMLVersion^2ir>

Рисунок 2 — Информация о версии документа AutomationML

- каждая стандартная библиотека AutomationML (каждая пользовательская библиотека AutomationML) должна содержать номер версии, использующий элемент САЕХ «Version». Синтаксис значения номера версии в настоящем стандарте не определен;

• при необходимости, классы формата САЕХ должны определять номер версии, использую» щий элемент САЕХ «Version». Синтаксис и семантика номера версии классов внутри библиотеки AutomationML в настоящем стандарте не определены;

- одинаковые библиотеки различных версий не могут храниться в одном файле AutomationML;

Примечание 2 — Это гарантирует уникальность имени библиотеки AutomationML внутри файла AutomationML.

• разработчик документа AutomationML должен гарантировать, что ссылки производятся только на классы и внешние документы с совместимыми версиями.

МЭК 62714 основан на использовании нижеследующих форматов документов:

• САЕХ версия 2.15:

• PLCopen XML версии 2.0 и 2.0.1;

• COLLADA версия 1.5.0 (в соответствии с ИСО/ПАС 17506) и COLLADA версия 1.4.1:

• стандартные библиотеки языка AutomationML в соответствии настоящим стандартом и последующими частями МЭК 62714.

5.4 Метаинформация об инструментальных средствах источника AutomationML

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

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

- в цепочке инструментальных средств обмена данных все принимающие участие инструментальные средства должны хранить данную информацию в документе САЕХ аналогичным способом. Данный документ должен содержать информацию о нескольких инструментальных средствах рассматриваемой цепочки инструментальных средств обмена данными. Рассматриваемое инструментальное средство может удалить пользовательскую информацию о прочих инструментальных средствах. Это может затруднить итерационную процедуру обмена данными с прочими инструментальными средствами. в связи с чем. удаление пользовательской информации о прочих инструментальных средствах не рекомендуется;

- данная информация должна храниться как часть дополнительной информации САЕХ Additionallnformation корневого объекта документа САЕХ;

• блок дополнительной информации Additionallnformation должен быть поименован как заголовок •WriterHeader»;

- метаинформация должна содержать следующие данные;

- имя экспортирующего программного обеспечения, пользовательского инструментального

средства;

• идентификатор Ю пользовательского инструментального средства (он должен остаться неизменным);

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

• URL размещении пользовательского инструментального средства;

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

- информацию о выпуске пользовательского инструментального средства:

- информацию о времени внесения последнего изменения пользователем:

- название проекта источника;

> идентификатор проекта источника.

- содержание метаинформации определяется пользовательским инструментальным средством. Тип записи — xs:string;

6

ПНСТ 177—2016

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

Таблица 2 — Метаинформация об инструменте источника AutomatkmML

Для представления метаинформации на расширяемом языке разметки XML используются ниже* следующие положения:

• элемент «WriterHeader* должен быть дочкой XML элемента для элемента дополнительной информации САЕХ Additionallnformation корневого элемента САЕХ;

• каждая единица метаинформации, поименованная в таблице 2. должна быть описана как дочка XML элемента «WriterHeader»;

• запрещено использовать несколько блоков метаинформации с одним именем в одном элементе «WriterHeader»:

• порядок представления метаинформации соответствует таблице 2.

Рисунок 3 приводит пример соответствующего описания на расширяемом языке разметки XML.

«Additionallnformation^

<WnterHeader>

<WrtterName>TootX AML E xporrer</W riterName> <ToofWriterlD>ToolXToAML123</TootWriteflD>

<WriterVendor>ToolX Vendor</WriterVendor> <WriterVendorURL>http:^/Mwv.ToolX-Vendor.org</WriterVendorURL>

<W riterVera ion>0.1 </W nterVersion>

<WriterRetease>123 preaipha«/WriterRetea$e>

<LastWritingDateTime>2013-12-31T12:00:00</LastWritingDateTime>

<WnterProjecfTrtle>eCarproductton</WrtterProjectTit)e>

<WnterProjectlD>eCarprockicdon_ljneRLC.pr)</WnterProjectlD>

</WriterHeader>

«/Additionallnformation²'

Рисунок 3 — Описание информации об инструментальном средстве источника AutomationML на языке XML

5.5 Идентификация объекта

Язык AutomatkmML соответствует объектно-ориентированной парадигме. Вся инженерная информация моделируется в виде объектов (принадлежит объектам). Вместе с тем. из-за неоднородности множества инструментами инженерии для идентификации объектов используются различные понятия. Например, уникальное имя. уникальный идентификатор, уникальный путь доступа. Одни средства позволяют изменять идентификатор по истечении срока существования, другие — нет. МЭК 62714 предоставляет возможность обмена данными между различными инструментами инженерии с учетом индивидуальной идентификации объекта. 8 соответствии с описанными характеристиками, настоящий стандарт компенсирует существующее разнообразие идентификационных понятий и определяет одно обязательное понятие идентификации объекта.

7

ПНСТ 177—2016

Для идентификации объекта используются нижеследующие положения:

- в соответствии с МЭК 62424 (раздел А.2.2.1) Классы языка AutomationML (ролевой класс RoJeClass. класс интерфейсов InterfaceClass. класс системных единиц SystemUnitClass) идентифицируются тэгом «Name (имя)» формата САЕХ:

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

• в соответствии с МЭК 62424 (раздел А.2.8) ссылка на классы производится с использованием полных путей доступа с помощью соответствующих сепараторов пути доступа;

• все экземпляры объекта AutomationML (внутренние элементы формата САЕХ IntemalElements. внешние интерфейсы формата САЕХ Extemallnterface) идентифицируются соответствующими тэгами «Ю» формата САЕХ. Данные идентификаторы должны быть UUID идентификаторами в соответствии с ИСО/МЭК 9834-8.

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

Примечание 2 — В соответствии с МЭК 62424 (раздел АЗ.15). тэг «10» не является обязательным в отличие от настоящего стандарта.

Примечание 3 — В настоящем стандарте, идентификаторы UUID представляются также а краткой форме, например. «GUID1». «GUID2» и т. д.

Примечание 4 — Тэг «Name» формата САЕХ указывает имя. Он имеет справочный характер и может изменяться с течением времени или при смене инструментального средства.

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

- ссылочные экземпляры используют значение «Ю»:

- ссылка на интерфейс САЕХ оформляется с использованием идентификатора UUID родительского объекта интерфейса, строки сепаратора «:» и имени экземпляра интерфейса;

Пример 1 — *GUID:out».

- ссылка на атрибут САЕХ оформляется с помощью соответствующего идентификатора UUID родительского объекта атрибута, строки сепаратора «.» и имени атрибута. Если рассматриваемый атрибут является вложенным, то за строкой сепаратора указывается лодпуть доступа к атрибуту.

Пример 2— *GUID.Cohur*.

Пример 3— nGUID.Cohur.red».

Рисунок 4 содержит пример библиотеки системных единиц SystemUnitClassLib. содержащей класс SystemUnitClass «Robot1234». а также класс SystemUnitClass «SpecialRobot1234», являющийся производным классом класса *Robot1234».

«j SystemUMClMsUb

= Мжм£хмгс*ебу«селиг«з**«иб *j Sy*t«nUnltCU»»

J 8 Mime ftcMIZM

]Sy*t«mUnttClM«

* Hmim Spac*Rt*>oM234

«SystemUniOessUb Nomt»*ExampieSystemUniClessLb*» j «SystemUntdess Nane='Robott 2344»

j «SysteiTiUr*Cla^Nar*»^peci«Rcbd1234"RefBe*eCi*wPali>»*tx*ro*eSYSte*fOiKie$3LibjRcbcll2347»

«/Systanumciesslto»

Рисунок 4 — Пример идентифюсации объекта класса AutomationML

Рисунок 5 содержит пример иерархии экземпляров InstanceHierarchy с одним объектом «RB.100», имеющим уникальный идентификатор, представленный строкой «GUID1».

8

ПНСТ 177—2016

*| lnstMKeHler«chy

s I lame ExampteProjed 4 lntein*IEIement

l

= Uame RB_100 = ID QUd

«Instance* tec archy NameH'ExarrrpleProject"» j «ttemaClemer* Мв»пе»Т®_100‘ Eb'CLIWA «AnstanceHerarcfiy»

Рисунок 5 — Пример идентификации объекта экземпляра AutomationML

5.6 Спецификация отношений языка AutomationML

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

Рассмотрение указанных объектов необходимо для определения механизма обеспечения ассоциаций объектов друг с другом. В настоящем стандарте проводится различие между двумя механизмами хранения информации: ссылки и соотношения. Подраздел 5.6 акцентирует внимание на соотношениях, подраздел 5.7 на ссылках. Справочный обзор соотношений и ссылок приведен в разделе А.1.5.

5.6.2 Соотношения «родитель-потомок» между объектами языка AutomationML

Соотношения типа «родитель-потомок» между экземплярами объектов используются для представления иерархических объектов структуры и описания структуры соотношений.

Для соотношений «родитель-потомок» между объектами AutomationML. используются нижеследующие положения:

• иерархия хранится в соответствии с МЭК 62424 (приложение А. раздел А.2.11).

Примечание — Кроме простых иерархий имеются и пересекающиеся иерархии (сети объектов). Они хранятся в соответствии с МЭК 62424 (раздел А.2.14).

Рисунок 6 содержит пример иерархии объектов и порядка ее хранения.

Ob|ectA

ObJectAJ

ODjectA.2

l-H|Ob)ectA.2j1

* InstanceHletarchy

s Iteme Patert chMrelations exarete * Interne Element

s NameObjectA

= Ю CUOI

] hit ci naCtefnent

s liante Object* J s ID GUD2 Intern ME lemeot

= iunv« Object* _2

= to GUD3 «j IntMiuEleiMnt

= I lame _1

s Ю QU04

<XtutaaceHicr»reby N»me='Paren! child relation* example*:-«latenalElemenl Nira<-='Object*' !D=*OUroi">

<tot«o»iEleeeoc Ntme-'ObjectAj' id-"OU1D2"-> vtoicrealtlemcot Naee«-*objectA_2" 10-*0UI03">

vlntenulElement Mame=“ObjectA_2_l“ Ш="0Ш04*/>

<lntemal£lemcal>

<lBienialEUmeoi>

<-1n«taac«Htmrcby>

Object* — Объеат A: InstanceHieiacchy — Иерархии экэеыппярое, Name|Parent child relations example — Иыя: пример соотношений «родитель—потомок»: Name]ObjeclA — Имя: объект А: 10 | GUID1 — Идентификатор: GUID1. IntemalElemenl — Внутренний элемент

Рисунок 6 — Пример соотношения «родитель—потомок» между объектами AutomationML

9

ПНСТ 177—2016

5.6.3 Соотношения «родитель—потомок» между классами языка AutomationML

Для соотношений «родитель—потомок» между классами AutomationML используются нижеследующие положения:

* соотношение «родитель—потомок» между классами AutomationML описывает только их иерархическое соседство. Это позволяет дать определения любым пользовательским иерархическим структурам:

- данное соотношение не имеет последующей семантики.

Примечание — Соотношение «родитель—потомок» не подразумевает наличия соотношения наследования. Соотношение наследования моделируется явно е соответствии с разделом 5.6.4.

Рисунок 7 содержит пример соотношения «родитель—потомок» между классами «ParentClass» и «ChildClass». «ChiidClass» не обеспечивает соотношения наследования с родителем.

«SysternUrtfOassUb Mame=“MySysteiTiUn4CldSsUti‘>

| «SystemUnrtCtess Neme*“ParentCle$$^,l>

| j «SystemUnitClass Name«^HCMdOas5V> j «/SystemUnftClass»

«/SystemUnitClessL*»

SystemUnrtClassLib — Библиотека классов системных единиц; SystemUnrtCtass — Класс системных единиц Рисунок 7 — Пример соотношения «родитель—потомок» между классами

5.6.4 Соотношение наследования

Для соотношений наследования используются нижеследующие положения:

- наследование между классами определяется в соответствии с МЭК 62424:2008 (раздел А2.7);

- если наследование необходимо, то родительский класс указывается с помощью тэга САЕХ «RefBaseClassPath». включающего полный путь доступа к базовому классу в соответствии с МЭК 62424 (раздел А.2.7);

- если рассматриваемый родительский класс расположен одним уровнем иерархии выше указанною дочернего класса, то родительский класс указывается путем сохранения имени данного родительского класса в тэге САЕХ «RefBaseClassPath» без указания полного пути доступа.

Рисунок 8 содержит пример класса «Robot1234», а также класса «SpeciatRobot1234», наследующего класс «Robot1234».

* SystemUnitCiassLib s Name

InheritanceExampleLib M SystemUnitClass

= Name.Robot1234

SystemUnitClass

= Name

lSpecialRobot1234

! s RefBaseClass Path,IrhentanceExampleLii/Robotl 234

«SystemUnitCiassLib Name»"lnheritanceExampleLib"> «SystemUnitClass Name="Robot1234“>

«SystemUnitClass Name="SpecialRobot1234" RefBaseClassPath-’ lnhentanceExampleLib/Robot1234*/>

«/SystemUnitClass»

«/SystemUnitCiassLib»

SystemUnitCiassLib — библиотека классов системных единиц: Name | inheritanceExamploLib — Имя библиотека примеров наследования: SyslemUnrtCiass — Класс системных единиц: RefBaseClassPalh — Путь доступа я ссылочному базовому классу

Рисунок 6 — Пример соотношения наследования между двумя классами

10

ПНСТ 177—2016

В добавление к данному примеру, тэг САЕХ «RefBaseClassPath» может относиться либо к «lnheiitance-ExampleLib/Robot1234». либо к «Robot1234». так как родительские классы расположены на один уровень иерархии выше уровня класса «SpecialRobot1234».

5.6.5 Соотношение «класс — экземпляр класса»

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

Для соотношений «класс—экземпляр класса» используются нижеследующие положения:

• объект языка AutomationML моделируется в качестве сущности IntemalElements в формате САЕХ как часть иерархии САЕХ InstanceHierarchy или класса SystemUnitClass;

• объект языка АШотайопМЬможетбытьодиночмымобъектомбеэсвязисклассом SystemUnitClass.

Примечание 1 —Объект языка AutomationML связан со стандартным ролевым классом AutomationML.

Примечание 2 — Экземпляры могут не иметь связи с базовой ролью AutomationMLBaseRole. они являются пользовательскими объектами и не являются объектами AutomationML:

• если объект языка AutomationML соотносится как «класс—экземпляр класса» с классом SystemUnitClass. то он создается как копия данного класса SystemUnitClass, включая внутреннюю архитектуру класса и всю унаследованную информацию.

Примечание 3 — Класс SystemUnitClass используется как шаблон. Изменения в классе SystemUnitClass не переносятся автоматически на соответствующие объекты автоматизации. Болев того, объект автоматизации может переноситься без информации о классе. Он содержит внутри себя всю надлежащую информацию:

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

Примечание 4 — Класс источника может быть подходящей стартовой точкой для модели экземпляра:

• скопированный класс источника должен быть указан в тэге САЕХ «RefBaseSystemUnitPath» рассматриваемого экземпляра для последующего использования. Данный тэг должен указывать полный путь доступа и имя класса источника.

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

• изменение класса источника должно вести к появлению новой версии класса с другим именем. Внутри нового класса полный путь доступа к старой версии класса должен храниться в тэге САЕХ «Old Version».

Примечание б — Данное положение поддерживает отслеживание изменений по всем существующим версиям класса:

• наследование между классом SystemUnitClass и экземпляром объекта не допускается.

Примечание 7 — Рассматриваемый экземпляр может быть тогъко копией соответствующего класса. Наследование между классами и экземплярами может быть использовано при их расширении:

• соотношение между экземпляром и классом RoleClass указывается в соответствии с МЭК 62424 (раздел А.2.7), с помощью атрибута пути доступа «RefBaseRoleClassPath» для надлежащего требования к роли RoleRequirements. В отличие от МЭК 62424 (раздел А.2.7). наследование здесь не допускается. Все спецификации ролевых классов RoleClass копируются в соответствующие объекты AutomationML:

• соотношение между интерфейсом САЕХ Externallnterface и классом InterfaceClass указывается в соответствии с МЭК 62424 (раздел А.2.7). В отличие от МЭК 62424, наследование здесь не допускается. Все спецификации классов InterfaceClass копируются в соответствующие объекты AutomationML.

Рисунок 9 содержит пример соотношения «класс—экземпляр класса» между объектом «ObjectA» и пользовательским классом SystemUnitClass «generic_Valve».

В добавление к стандартным положениям соотношения «класс—экземпляр класса», нижеследующие специфические положения применяются в соответствии с зеркальным понятием САЕХ:

- тэг «RefBaseSystemUnitPath» может указывать на другой экземпляр объекта вместо класса SystemUnitClass в соответствии с зеркальным понятием (см. МЭК 62424, А.2.14).

5.6.6 Соотношение «экземпляр-экземпляр»

Соотношение «экземпляр—экземпляр» — это соотношение между двумя интерфейсами произвольных объектов AutomationML.

11

ПНСТ 177—2016

InstanceHie» аг chy

= Name OassInstartceReMion Exarrpte

Intet ru(Element s Name = D

ObjectA

GUD1

s RefDaeeSyetemUnltPath mySystemUnlClassljb/generic.Valve

«IrutanceHierwchy Nomc-'Oessfwtenceftdahon Example''»

| «Wernagemert Nerw-ObjectA" P^CUDI" RefBateSystemU^alM^,>tiySy»taiaUr<OattUl»anarie_Vaive'^,fr <*tslancerterarcJiY>

instanceHiersrcfty — Иерархия экземпляров: InternalElement — Внутренний элемент: ID — Идентификатор: Re(BaseSy»lemUnitPalh — Ссшпочимй путе доступа к базовым системным единицам

Рисунок 9 — Пример соотношения «класс—экземпляр класса»

Для соотношений «экземпляр—экземпляр» используются нижеследующие положения:

• соотношения «экземпляр—экземпляр» хранятся е соответствии с МЭК 62424 (разделы А.2.5.3 и А.2.14) с помощью САЕХ InternalLinks;

• САЕХ InternalLinks хранится сущностью САЕХ IntemalEiements, являющейся общим родителем самого нижнего уровня для соответствующих соединенных объектов САЕХ:

• соотношения «экземпляр—экземпляр» определяются только между внешними интерфейсами САЕХ Extemallnterface. принадлежащими соответствующим объектам AutomationML (см. МЭК 62424 (раздел А.2.3.1)):

• сущность Externallnterface выводится прямо или косвенно из одного из классов стандартных интерфейсов AutomationML;

Примечание 1 — Библиотека класса стандартных интерфейсов AutomationML рассмотрена в разделе 6.3. Класс интерфейсов определяет семантику интерфейса и. таким образом, семантику связующего элемента. Связующий элемент интерфейсов не имеет семантики, если нет ссылки на класс интерфейсов.

• документы COLLADA могут быть взаимосвязанными. Соответствующие интерфейсы COLLADA — это любые элементы, имеющие корректный идентификатор URI. Если рассматриваемые узлы должны быть взаимосвязанными в формате САЕХ. то они должны быть опубликованы в САЕХ путем добавления внешнего интерфейса САЕХ Externallnterface соответствующему объекту. Данный внешний интерфейс Extemallnterface выводится из класса стандартных интерфейсов AutomationML «COLLADAInterface» или из одного из его производных:

Примечание 2 — Стандартный класс интерфейсов «COLLADAInterface» рассмотрен 8 разделе 6.3.7. Подробности приведены в МЭК 62714-3.

- документы формата PLCopen XML могут быть взаимосвязаны путем использования соответствующих интерфейсов PLCopen XML. Если е формате САЕХ необходимо обеспечить взаимосвязь элементов PLCopen XML. то они должны быть опубликованы путем добавления сущности САЕХ Externallnterface в соответствующий объект. Данный внешний интерфейс Extemallnterface выводится из класса стандартных интерфейсов AutomationML «PLCopen-XMLInterface» или из одного из его производных.

Примечание 3 — Стандартный класс интерфейсов «PLCopenXMUnterface» рассмотрен в разделе 6.3.6. Подробности приведены в МЭК 62714-4.

Рисунок 10а) содержит пример, включающий робот «Rob1» и программируемый логический контроллер PLC «PLC1». Каждый имеет один интерфейс сигналов. Интерфейсы соединены. Рисунок 10Ь) отображает данный пример в виде иерархии объектов.

Рисунок 11 отображает представление данного примера на языке AutomationML. Ниже приведено описание на языке XML иерархии экземпляра InstanceHierarctiy для данного примера, включающего все объекты AutomationML типа «Station», «Rob1», «PLC1» и «BoardOb. а также их интерфейсы.

Примечание 4 — Строки пути доступа для данного примера для улучшения их '«иаемости сокращены (обозначение «/.../»).

12

ПНСТ 177—2016

a) Relation as a block diagram

3 ГПТ] UnkExampte efflstaben 0 IIEl Robl

Start

0 Щ*£1 \

aQE BoardOl \ •-О СНаппеЮ1

8 ГШ] UnkExampte В 1 IE I Station aQB R0bl

Start

GUBPLCi

в | IE I BoardOl

*o Channe+01 b) Relation as an object tree

InternalLtnk

InternalLink

\

Ю1 \

a) RelaUon as a block diagram — а) Соотношение о виде «блок—схема», b) Relation as an object tree — b) Соотношение a виде «древа объектов»: Station — Станция: Start — Старт. ChannetOt — Канал Ot; Board 01 — Панель 01; relation — Соотношение: LmkExample — Пример связующего элемента: InternaLink — Внутренняя связь

Рисунок 10— Пример соотношений видов «блок—схема» и «древо объектов»

5.7 Спецификация ссылки на документ языка AutomationML

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

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

5.7.2 Ссылка на документ COLLADA

Ссылки на документы COLLADA производятся с помощью класса стандартных интерфейсов AutomationML aCOLLADAInterface» или одного из его производных. Данный класс рассмотрен в разделе 6.3.7. Подробности приведены в МЭК 62714-3.

5.7.3 Ссылка на документ PLCopen XML

Ссылки на документы PLCopen XML производятся с помощью класса стандартных интерфейсов AutomationML «PLCopen-XMLInterface» или одного из его производных. Данный класс рассмотрен в разделе 6.3.8. Подробности приведены в МЭК 62714-4.

5.7.4 Ссылка на дополнительные документы

Будущие расширения МЭК 62714 могут установить дополнительные типы интерфейсов для ссылок на дополнительные типы документа. Они рассмотрены в отдельных частях МЭК 62714. В настоящем стандарте они не рассматриваются.

Для указанных расширений используются нижеследующие положения:

• если МЭК 62714 содержит дополнительные типы документа, то они моделируются с помощью дополнительных классов интерфейсов;

• указанные дополнительные интерфейсы моделируются как расширение библиотеки AutomationML InterfaceClass. Они выводятся непосредственно или косвенно из стандартного класса интерфейсов ExtemalDataConnector;

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

• стандартный класс интерфейсов «ExtematDataConnector» используется для типов документа, включенных в МЭК 62714.

13

ПНСТ 177—2016

<retanc*Hter«chy N*no»TJr*fe*ff|)i»’»

I «nemaBementManes'StttoiriCx-^UOi'b «ht»r>d6cn>ent mm»«TW O^GUM*»

j «ЕдетпеМстФсеНаюе^ятТ* Rat6a»eCtet>Faa»»^,AJe»wnof*l.lf<wiaccCtoMib/ /Senolrteffeee'»

; оцинл* Nooe-Typ*^--: i | «Vekjodglekivalue»

• «ЛЧИм4е>

: ыимьим шпг^ткмялл*»

: j *vetjc*r^vekje*

• • <шмм*е>

: «.erierneMer'ac*»

«Л"*мг*вет*пТ»

«КегиСстегя wmh«»*WX1*' C»’OUOT>

; «mneeienw^Nete-’Boerdoro-'Ouo*^

; *S>tejr>5»iertace >1агг*.^-От*пггв01 * Ре!ЕЯиЮм^да~“АикхгйСог*<.К«гг»сеС1м*СЫ' i SernThtef race“>

; >AltnbUe Newe-Tiee**

'■ j j J *VaMe>ci9ld<'V«k«»

; *.«*r*a*»

; I • «AsntUe Hr^s'Cteden*»

III! «УаЫеЮиНЛГАе»

; ! «ЛАВгЛОе»

. : <C>te>nNnerface>

: «AterndCIwntrt»

«*йе»лав*«пет*»

«WemeUr* f^fP»r*'SH^-4XC» Ol*cn*W • Re*P*^i«S<*^-0UO2-SWr1'/>

<*ts»nsBemectf»

xftrettrtceHNrwcfty*

<ln»tar>ceH*farchy Nane*'Unk£xample'>

<lntema(Elwnenl N*ne«"Stat>on" ID**GUIDr^>

<W*nalEl*mem Name='Robr tD='GUf02'>

<£xiemailnterfece Name^Surt* RefBaseClaisPatft-'AutonialionMIlnterfaceClaisLibi'. .'Signa(lnterfac*"/> </lnternaiE>emen(>

<Hema(Etement Name**PlCr ID«'GUID3'»

<1ntemaEJ«ment Nama-'BoardOV 10*'GUID4‘>

<ExlarnaUnterface Namw*'Ch»n*Kl1' RefBa6eCI*ssPeth»"AutomationMLInterfac»Clax8L*y /Signallnlvfa </lntemalEtemem>

<<1n»emalEtefnent>

<WemalL»* Narr««‘HjrdA»eLM(l' Reff>»1nefS«teA-"GUID4:Chanod0r RefP«merStd«e*^,GUI02:SUHV> <1ntemalElement>

</lnstanceHierarchy>

tnstanceHirarcJiy — Иерархия экземпляра: Name | LmkExample — Имя: пример связующего элемента, InteinatEiemenl — Внутренний элемент. Name | Station — Имя: станция: ID | GU1D1 — Иденгифихатор: GUID1: tnternalElemenl — внутренний элемент, Name — Имя: Ю — Идентификатор: ExternaJtnlerface — Внешний интерфейс: RefBaseClassPatn — Ссылочный путь доступа базового класса; tnlernalLink — Внутренняя связь: Extemallnlerface — Внешний интерфейс. HardwaroLinkl — Аппаратная связь: RefParlnorSiiSeA — Ссылочная сторона А партнера

Рисунок 11 — Пример соотношения между объектами «PLC1» и oRobl»

14

ПНСТ 177—2016

6 Базовые библиотеки языка AutomationML

6.1 Введение

Раздел 6 определяет существенные базовые библиотеки AutomationML. а также базовые классы языка AutomationML. необходимые для моделирования корневых понятий AutomationML. Все описан* ные атрибуты являются частью стандартной библиотеки AutomationML. При необходимости они могут быть удалены из иерархии экземпляров InstanceHierarchy.

Примечание —Зависящие от домена библиотеки рассматриваются в последующих частях МЭК 62714.

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

Для базовых библиотек AutomationML. используются нижеследующие положения:

• все объекты AutomationML ассоциируются непосредственно или косвенно с ролевым классом «AutomationMLBaseRole»:

• все интерфейсы непосредственно или косвенно ассоциируются с классом интерфейсов AutomationML;

• при необходимости можно использовать атрибуты AutomationML. они могут быть удалены из объектов AutomationML.

6.3 Библиотека класса интерфейсов AutomationML — AutomationMLInterfaceClassLIb

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

Библиотека AutomationMLInterfaceClassLib моделируется в соответствии с МЭК 62424 (раздел 7. приложения А и С). МЭК 62714 использует понятие интерфейса САЕХ. Допускаются пользовательские расширения данной библиотеки AutomationML в соответствии с разделом 7.3.

Каждый интерфейс выводится непосредственно или косвенно из класса нижеследующих стан* дартных библиотек AutomationMLInterfaceClassLib в соответствии с таблицей 3. Подразделы 6.3.2 — 6.3.10 описывают рассматриваемые классы интерфейсов в подробностях.

Таблица 3 — Библиотека класса интерфейсов AutomationMLInterfaceClassLib

Библиотека AutomaUonML IntortaceClass

S

Ft* AutomationMUn

_яяаашяя

3 *-o AutomationMLBaselnterface 9 -o Order

-ю PortConnector -o InieriockingConnector PPRConnector

3 «о ExternalDataConnector -o COLLADAlnterface -o PLCopenXMLInterface 3 -O Communication

•o Signallnterface

На рисунке 12 приведена таблица, а на рисунке 13 описание стандартной библиотеки AutomationML Interface-ClassLib на языке XML. Подразделы 6.3.2 — 6.3.10 содержат подробную информацию о рас* сматриваемых классах.

15

ПНСТ 177—2016

~ mterf»c«d***Lib _

s Мате AutornatenMunterlaceCisasLb

О Description Standard AutomsbonML Interface Gass Library <) Vara ton til

a interfaced#»»

: Name AutoaetonULBasentertac*

]'

InterfaceClasa

= Name 'Older

в RelB—cm aPitt AuieneoanMLDaaalbarfaee

Attribute

s кате fraction

z ММмМ0М1Ураж»М|

ItnterfaeeCU»»

s Name PertCmeder __

s RelB*»eCi»»»PWl>Aii>e«>aai>MlBMilatartaH «InterfaceCiass

s Name МеПеекпдСогмееюг

s RefBaseCI#»»PathAutemationMLBas«M*rface interfaced#»»

s Name PPRConnector

s RefBaseCtassPathAutomstonMlBaselnterface ej Interfaced»»»

s Name ExtemsOataConoecior

s RefBaseClatsPathAutomabenMLBaaentefface Attribute

z Name relUW

z AttributeOataTrpe xsanyliRJ

at InterfaceClasa (3)

1

z Name z iWBeteChuMi

I

1 COLLAOAMterface Exiemeoetacoiwector

2 PlCopenXMUnlefiace ErdemaOataCenneetor

4 interfaced»»»

z Name соттигнеаюл

s RefB#»eCt#ssPathAutom#t»nlA(.Ba»etnterface ; InterfaceCiass '

z Name = RefBe»eda*sPa№

1 Swiatoterface Comunceten

]'

InterfaceCiassLib — библиотека кпасса интерфейсов: Name — Имя; Oescnptton Standard AulomabonML Interface Class Library — Описание: Стандартная библиотека класса интерфейсов на ямке AutomalionML. Version — Версия. InterfaceCiass — Класс интерфейсов: RefBaseClassPalh — Ссылочный путь доступа к базовому классу: Attribute — Атрибут. Direction — Направление: AtlribuleDataType ~ Тип данных атрибута: Communication — Коммуникация: Sipnallnterfaco — Интерфейс сигнапов

Рисунок 12 — Библиотека классе базовых интерфейсов AutomalionML

«imtrtaceCiaMlb »r»'»-'Auom<r>crA*jreerf*»Ci*»sLb^-'

OMcnpcen>StandaM AutcmaOenWL irtedace suss UGrary«C«t<re6on>

«v*r»icrT»21 K'Verter.»

«МеИасеОам Ha-»—‘AmenetJCnULSascHlg-lapf'*

«MeriKeCta* Nanee'OrdW P«%o»eOastP«n**auieraeonMLBasel(Mrfaoe’>

«Anrbute Name«'OcecBon АвгелЮМаТтрен'хв.звпд’Тт -•veerteccCiass-*

-«MrtaceClass NeneoTortComaeier* ЗЫВам>С1м*Р«ь>'Аи1вта11елМ.8аи1пмгГаее^-<> •*t*rt**Ci«* ■чпе»'ке»Лх*1п?С<т*с»' RrfSa^iawPNTVAuia-nNicnNieaaelftiirfaceV' «а-ttrtaaaCU»* гчл-кг'РРЯСстесш* R<№aseCUBsPa>Tw>*auureuanMLBauMHrfaoe'» •МИагеОа» Nane^'EMnaDstaConMeter* R«fBas*CiM»Pae»'Auia^<na»erMLBaM<ra*rfae»'> 'AKrbute Name>V«(URr AtrbiMG«tgTwe^a'te:amCftP'>

«MartaceCUae N»me-*COlLAOAlM»rt>oe^- кевамСамРа(п-*ЕхМ1мЮШСопгмсеаг‘л-•heertaceClass '«ameH'PLCopenJB&Merface* Rrf3e»eCnes^t*t •'ErtemeCetaCamector''' <va*rtac«ciias>

«аеыШеОаи fswHe-*Ce»nwewen' Kent шс. HkAPM'i-*AiaenuMnMieasefca)rface'> •МивавеСЬм N»me*'SignelnlKrtet* RH8«e»C*»iPiier»^,C<rwe6«tion^-'* *»«Ht«ceCMa**

'Л-еикскСЦвв*

•itnfcrfsocCiaisLb-

16

Рисунок 13 — Описание базовой библиотеки кпасса интерфейсов AutomationML на языке XML

ПНСТ 177—2016

6.3.2 Класс интерфейсов InterfaceClass AutomationMLBaselnterface Таблица 4 содержит описание класса интерфейсов «AutomationMLBaselnterface».

Таблица 4 — Класс интерфейсов InterfaceClass AutomationMLBaselnterface

6.3.3 Класс интерфейсов InterfaceClass Order Таблица 5 содержит описание класса интерфейсов «Order« (порядок). Таблица 5 — Класс интерфейсов InterfaceClass Order

6.3.4 Класс интерфейсов InterfaceClass PortConnector

Таблица 6 содержит описание класса интерфейсов «PortConnector (коннектор порта)».

Таблица б — Класс интерфейсов InterfaceClass PortConnector

6.3.5 Класс интерфейсов InterfaceClass PPRConnector Таблица 7 содержит описание класса интерфейсов «PPRConnector».

Таблица 7 — Класс интерфейсов InterfaceClass PPRConnector

6.3.6 Класс интерфейсов InterfaceClass ExternalDataConnector

Таблица 8 содержит описание класса интерфейсов коннектора внешних данных « External DataConnector».

17

ПНСТ 177—2016

Таблица 8 — Класс интерфейсов InterfaceClass ExlemalDalaConnector

6.3.7 Класс интерфейсов InterfaceClass COLLADAInterface

Таблица 9 содержит описание класса интерфейсов «COLLADAInterface». Подробности приведены в МЭК 62714-3.

Таблица 9 — Класс интерфейсов InterfaceClass COLLADAInterface

6.3.8 Класс интерфейсов InterfaceClass PLCopenXMLInterface

Таблица 10 содержит описание класса интерфейсов «PLCopenXMLInterface». Подробности приведены в МЭК 62714-4.

Таблица 10— Класс интерфейсов InterfaceClass PLCopenXMLInterface

6.3.9 Класс интерфейсов InterfaceClass Communication Таблица 11 содержит описание класса интерфейсов «Communication».

Таблица 11 — Класс интерфейсов InterfaoeCfass Communication

18

ПНСТ 177—2016

6.3.10 Класс интерфейсов InterfaceClass Signailnterface

Таблица 12 содержит описание класса интерфейсов сигналов «Signailnterface».

Таблица 12 — Класс интерфейсов InterfaceClass Signailnterface

6.4 Базовая библиотека ролевых классов AutomationML— AutomationMLBaseRoleClassLIb

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

Подраздел 6.4 определяет базовую библиотеку AutomationML основных стандартных ролевых классов, необходимых для моделирования корневых понятий AutomationML. Роль — это класс, описывающий абстрактную функциональную возможность без определения основополагающей технической реализации. Примеры ролевых классов: «Resource». «Robot». Если ассоциировать ролевой класс с объектом AutomationML. то данный объект языка AutomationML приобретает семантику. Дополнительные расширенные библиотеки описаны в МЭК 62714-2. Все описанные атрибуты являются частью стандартной библиотеки AutomationML. Они могут быть удалены из иерархии экземпляров InstanceHierarchy, если в них нет необходимости.

Каждый объект языка AutomationML и каждый пользовательский ролевой класс должен прямо или косвенно ссылаться на одну из ролей указанной библиотеки AutomationML. Если рассматриваемая роль слишком специфична, то необходимо ссылаться на следующего родителя. На рисунках 14—16 представлен стандартный базовый ролевой класс RoteClass в виде древа объектов. XML таблицы. XML текста. Подробности по каждому ролевому классу приведены в разделах 6.4.2 — 6.4.13.

AutomationMI BaseRoleClasslib AutomationMLBaseRole Group Facet Port

ConnectionPoint Resource Product Process Structure

ProductStructure ProcessStnjcture ResourccStructurc Propertyset

Auto<n*b0nMl.eaioRotoCtss*J.ib — Базовая библиотека ролевых классов. AulomabonMLBasaRole — Базовая роль . Group — Группа; Role Lib — Библиотека ролей; Role — Роль. Facet — Фасет; Port — Порт. Connection Pont — Точка соединения; Resource — Ресурс; Product — Продукт. Process — Процесс; Structure — Структура. ProduclSlructure — Структура продукта; Process Structure — Структура процесса; ResourceStructure — Структура ресурса. PropertySel — Набор свойств

Рисунок 14 — Базовая библиотека ролевых классов AutomationML

19

ПНСТ 177—2016

- rcwo»«*l©

s Rame лц<«мыкдамАЯ*сь*м.в О Оамлдесп iiwnaBaiMt. but ttn Itouy О Vxtion i ! •

Rowe»»*

a Mow Aca»no>nuie«t«RoW «МаСЬа»

8 Mm* Cm*

s Ht«»»«(w**f«oiA>iMwio»Uke**«4(»

«Awnovw и

a Hama a AlliHMMOaaTtP*

J 1 tnaaitfioH lOitm*

bvlcOa»

s Name **c*i _

а П|8и«<амГ»а AaaiwMitmilMi RoWCb»*

B»rt

s iWQ»*«cw»»R*ia.Aunn»ioimeo»oRt» *i a«m>uw>3>

s Mart*

* Спаи

2 Сгтыату

3 c«eeoo

1 Eotm*ati*<t«ce

a АЯпЬНаОеиТгр*

aitni

х».м«р*к1ур«

n:wn»

Ссимяи^Уна

О ARnMlt*

- ABrbuW <2>

S «МП» S AI№bUl«0«t»Typc 1 MnOccw X» uni 3 MnOetar x* uni

8 Ham*

8 В*ИЬ»еа>*»РЯШ*1онЫИМД>ег»ас>»в*ифАИ»и*»*ЫА»«*Н»стС1*мдаАиья«Ы»ша***щ»ШсЫ ИалСсппаемг

]RoteClw*

s name nrtotret

s Re4»»«C>a*»Pte> AilcrtwVrtWl£a»*Rt«

ЩИаСЫь»

I 8 Mama Pndad

I a Re<e»cCi»»»f»«tiA»H<H*W»»Hiea»»«ta

aj RoWCI»*» _

a aama Гц««а»

J 8 ft*e***C»**P*biAHOTTuUllfe»*i>«e

KolaClui

s Name Severn

s AeAast<WtsP*i*i AriumAMMlfMeRrfe

ajAewOm

8 Ham* a Яегем«С1е(аНМ»

* Pittuctimx&i* A»e<wdaw»«**»»wsiniair«

3 PnctMStrvcbra AabnaUortUascAetoSlrvair*

3 fta»eirc»S>nic»H« AabnatPTMiBaMHaHiSlrvom

IRoWCba*

s name FnpcrrySal

s йа<е«**С«**«Р*ПАмлмюШ13ме8<«

RoteClassLfe — Библиотека ролевых классов: Name •— Имя. Description | AulomationML base role library — Описание: Базовая библиотека ролей: Version — версия, RoieClass — Ролевой класс: RefBaseClassPath — Ссылочный луга доступа к базовому классу. Attribute — Атрибут. AttribuleDataType — Тип данных атрибута: Direction — Направление: CardtnaMy — Мощность множества: Category — Категория. External interface — внешний интерфейс

Рисунок 15— Базовая библиотека ролевых классов AutomationMLBaseRoleClassLib

6.4.2 Ролевой класс RoieClass AutomationMLBaseRole

Таблица 13 содержит описание класса базовых ролей «AutomationMLBaseRole».

Т аблица 13—Ролевой класс RoieClass AutomationMLBaseRole

20

ПНСТ 177—2016

«RoteClasaL* Name «"AutomationMLBeseRoleClftssUb''»

<Deecnptooiv>Automat»onML base role tfcrary «/Description»

<Ver*ioo>2.1.1 «/Vernon»

<RoleCla»s Narr*-"Autom«borAILBeeeRc4e‘>

«RoleCtess Neme-’XJfoop* RsfBs*sClss*Petb»"Au»om*k>rilylLBsseRol#“>

«Attribute Neme«*AsaociatedFacef Attribute DetaType “"xs:string"/>

</RoleCto»»>

«RoiaCtes» Nama *Veeet" R*fBe*eCiMsPeth«"AutwnattonML8*seRoleV»

«RoleClass Name “’Port" RefBaseClassPatn*“Au»omeiionMLBeseRote*>

«Attribute Narre=*Direction" AttnouteDate Type ="xs:sBingV>

«Attribute Names*Cardnalrty^H AttribvteOataType*"»xomplexTypar>

«Attribute Name-TAnOccur* Attnbute Data Type «Attribute N*m*«"MaxOccur" AttnbuteDatafype*"x».-gnn>

</Attnbute>

«Attribute Neme«*Cet*9ory* Aaribu»DataType**xs:etriog"/>

«Extemeilnterface Name-’Connection Point" RefBaseCIsssPath*

'AutomeBonVLlnter'eceOassLib^AutomattonMLIfKer^ceClassUb/AulomelonMLBaeelnterfece/PoitConnectof**

</RoleCtase>

«RoieCtass Name ="Resource" Ref&aseClassPatriF’AulometjonMLBeseRole’V»

«RolaClaaa Name *’Product" Ref8a&eClabsPeth**AutomationMLBeeeRole"/>

«RoieCtass Name “’Process" RefBa6eClassPath*"AutomstionML8aetRoto'7>

«RoieCtass Name «"Structure" Ref8aseClassPa№«"Aulom8tionMLBaseRote''>

«RoieCtass Nsme«'Preduct$tructure" RefBaseC«ssPa№«"AutomattonMLBsseRote/Sbucture*/>

«RoieCtass Nome«"Proce»sStructure' RefBas#CiassPeth»"Automa6onMLBaeeRole/Stnicture'7>

«RoleClass Namea"ResourceSbuctire" Ret8eseClassPatb*"Automet»onMLBa9eRole/Stnjc1ure*/»

«/RoieCtass»

«RoieCtass Name «‘PropertySaT Re<Bas«CiassPattv«'AutomattonMLeeeaRole*^>/>

«/RoieCtass»

«/RofeClassLib»

Рисунок 16 — Текст на языке XML для базовой библиотеки ролей AutomationMLBaseRoleClassUb

6.4.3 Ролевой класс RoleCiass Group

Таблица 14 содержит описание ролевого класса «Group».

Таблица 14 — Ролевой класс RoleClass Group

6.4.4 Ролевой класс RoleClass Facet

Таблица 15 содержит описание ролевого класса «Facet».

Таблица 15 — Ролевой класс RoleClass Facet

21

ПНСТ 177—2016

6.4.5 Ролевой класс RoleClass Port

Таблица 16 содержит описание ролевого класса «Port».

Таблица 16 — Атрибуты «по выбору» для объектов ролевых классов AutomattonML Port

Атрибут «Cardinality» (мощность множества) имеет два второстепенных атрибута (субатрибуты), описанных в таблице 17.

Таблица 17 — Второстепенные атрибуты для атрибута «Cardinality»

22

ПНСТ 177—2016

Дополнительно данный объект порта AutomationML должен иметь внешний интерфейс САЕХ Externallnterface, полученный из класса интерфейсов AutomationML InterfaceClass «PortConnector» (см. таблицу 16).

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

Таблица 18 — Интерфейс класса портов AutomationML Pori

6.4.6 Ресурс ролевых классов RoleCiass Resource Таблица 19 содержит описание ролевого класса «Resource».

Таблица 19 — №левой класс RoleCiass Resource

Дополнительно, при необходимости, объекты ресурса AutomationML должны иметь внешний интерфейс САЕХ Externallnterface «PPRConnector» для создания соотношений с продуктами и процессами (см. раздел 6.3.5).

6.4.7 Ролевой класс RoleCiass Product

Таблица 20 содержит описание ролевого класса «Product».

Таблица 20 — Плевой класс RoleCiass Product

Дополнительно, при необходимости, объекты продукта AutomationML должны иметь внешний интерфейс САЕХ Externallnterface «PPRConnector» для создания соотношений с ресурсами и процессами (см. раздел 6.3.5).

6.4.8 Ролевой класс RoleCiass Process

Таблица 21 содержит описание ролевого класса «Process».

23

ПНСТ 177—2016

Таблица 21 — Ролевой класс RoleClass Process

Дополнительно, при необходимости, объекты процессов AutomationML должны иметь внешний им-терфейсСАЕХ Extemallnterface «PPRConnector» для создания соотношений с продуктами и ресурсами (см. раздел 6.3.5).

6.4.9 Ролевой класс RoleClass Structure

Таблица 22 содержит описание ролевого класса «Structure».

Таблица 22 — Ролевой класс RoleClass Structure

6.4.10 Ролевой класс RoleClass ProductStructure

Таблица 23 содержит описание ролевого класса «ProductStructure».

Таблица 23 — Ролевой класс RoleClass ProductStructure

6.4.11 Ролевой класс RoleClass ProcessStructure

Таблица 24 содержит описание ролевого класса «ProcessStructure».

Таблица 24 — Ролевой класс RoleClass ProcessStructure

24

ПНСТ 177—2016

6.4.12 Ролевой класс RoleClass ResourceStructure

Таблица 25 содержит описание ролевого класса «ResourceStructure».

Таблица 25 — Плевой класс RoleClass ResourceStructure

6.4.13 Ролевой класс RoleClass PropertySet

Таблица 26 содержит описание ролевого класса «PropertySet».

Таблица 26 — Rwieeovt класс RoleClass PropertySet

7 Моделирование пользовательских данных

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

Раздел 7 устанавливает порядок моделирования пользовательских данных в формате AutomationML. Моделирование специфических пользовательских данных —это основное понятие языка AutomationML. Пользовательские данные — это те атрибуты САЕХ. классы интерфейсов InterfaceClass и классы ролей RoleClass. которые не были предварительно определены МЭК 62714. Механизм моде-лирования пользовательских данных обусловлен форматом САЕХ для данных верхнего уровня языка AutomationML.

Для обмена пользовательскими данными, могут потребоваться специальные пользовательские соглашения и функциональные возможности, которые не рассматриваются в МЭК 62714. Специальная метаинформация об инженерных инструментальных средствах источника, описанная в разделе 5.4. поддерживает указанные функциональные возможности.

Язык AutomationML обеспечивает возможность определять соотношения между пользовательскими данными и стандартными данными с помощью понятия роли, понятия набора свойств PropertySet и стандартных отображений САЕХ. Указанные понятия облегчают автоматическую интерпретацию пользовательских классов и атрибутов.

7.2 Пользовательские атрибуты

8се атрибуты, определенные в МЭК 62714. называются атрибутами AutomationML. Все атрибуты, не определенные в МЭК 62714. называются пользовательскими атрибутами. Атрибуты AutomationML и пользовательские атрибуты хранятся одинаковым образом в качестве САЕХ атрибутов.

Для пользовательских атрибутов, используются нижеследующие положения:

• атрибуты САЕХ должны храниться на языке AutomationML в соответствии с определением атрибутов САЕХ. приведенным в МЭК 62424 (раздел А.2.4);

25

ПНСТ 177—2016

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

Предлагается использовать систему единиц СИ в соответствии с ИСО 80000-1. Для единиц информационных технологий предлагается использовать МЭК 60027.

Рисунок 17 содержит пример пользовательского объекта «ObjectOI» с пользовательским атрибутом «Length» (длина).

j « kxtVK«Wef «(Ьу

ж 1Ьлиимг0«те<МЫм4е«Есмгв1»

«mstancetterarchy Name-’UserOefinedAttrixleaExaffipte”»

! «WernaCiemart Мвте«ЛХ*есЮГ

j «Attribute Nerrte«"Length* ABrtout«OeteType»*xs:strinfl* Uri>'W>

; { «VeHue»i2«/Ve*je>

; «/Attrtoute»

| «Anterneflemefil»

InsUnceHierarchy — Иерархия экземпляров. Name — Имя; iniemalEiemenl — внутренний элемент. ID — Идентификатор; Attribute — Атрибут, AlInbuteDalaType — Тил данных атрибута; Unit — Единица измерения; Value — Значение

Рисунок 17 — Пример пользовательского атрибута

7.3 Пользовательский класс интерфейсов InterfaceClass

Все классы интерфейсов interfaceClass. определенные в МЭК 62714. называются классами интерфейсов AutomationML InterfaceClass. Все классы интерфейсов, не определенные в МЭК 62714. называются пользовательскими классами интерфейсов InterfaceClass.

Для пользовательских классов интерфейсов InterfaceClass. используются нижеследующие положения:

- все пользовательские классы интерфейсов InterfaceClass должны храниться в соответствии с определением САЕХ InterfaceClass. приведенным е МЭК 62424 (раздел А.2.5);

Примечание — Классы интерфейсов AutomationML InterfaceClass и пользовательские классы интерфейсов InterfaceClass хранятся одинаково в формате САЕХ InterfaceClass.

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

Рисунок 18 содержит пример пользовательского класса интерфейсов «MyOigitallnput (мой цифровой вход)», полученного из класса интерфейсов AutomationML InterfaceClass «Signallnterface». Соотношения наследования между классом интерфейсов «MyOigitallnput» и стандартным классом интерфейсов AutomationML InterfaceClass «Signallnterface» обеспечивают автоматическую идентификацию данного пользовательского класса как цифрового входного интерфейса. Пользовательские атрибуты заданы надлежащим образом. Пользовательские атрибуты, задействованные в данном примере, не являются предметом рассмотрения настоящего стандарта.

Примечание — В данном примере представление пути доступа сокращено для улучшения читаемости текста. В реальных приложениях пути доступа должны указываться полностью.

7.4 Пользовательский ролевой класс RoleClass

Все классы ролей RoleClass. определенные в МЭК 62714. называются ролевыми классами AutomationML RoleClass. Все классы ролей RoleClass, не определенные в МЭК 62714. называются пользовательскими ролевыми классами RoleClass.

Для пользовательских ролевых классов RoleClass. используются нижеследующие положения:

• классы ролей формата САЕХ RoleClass должны храниться в соответствии с требованиями формата САЕХ RoleClass. определенными в МЭК 62424 (раздел А.2.6):

Примечание 1 — Ролевой класс AutomationML RoleClass и пользовательский ролевой класс RoleClass хранятся одинаково 8 формате САЕХ RoteClass.

- чтобы гарантировать семантическую интерпретируемость пользовательских ролевых классов RoleClass. они должны быть получены из ролевых классов AutomationML RoleClass.

26

MtuuBtmtnl

ж НакиОЬвсЮ’ s D Cud • Attribute

Ж Шли

Ж ARi*H»»tl«14Ty!>« Ming

ж UnM m

(>v*w 13

ПНСТ 177—2016

Примечание 2 — Эго способствует алгоритмической интерпретируемости семантики класса.

Рисунок 19 содержит пример пользовательского класса «Fence» (ограждение), полученного из стандартного ролевых классов AutomationML RoleClass «Resource». Соотношение наследования меж* ду классами «Релсе» и «Resource» позволяет интерпретировать данный пользовательский класс в качестве ресурса.

InterfaceClaesLib

= llame UserOefmedClassLtb 4 InterfaceClass = Наше

= RefBaseClassPath Attribute (3)

MyOfgtalnput

Automat юпМ lint erfaceClassLIW. У SignaWerface

= Наше

= AttributeDataType () Value

< tnt erface Oasslfci Name»“Us«'C¹efinedClasslib’'»

<MerfaceOass Г4ате=’'My Digit вПпръГ RefB»seClessPath«*AidomationM.lnterfaceClassLib/ .7SignalWerface^,'> «Attribute Name»"Type* AflrtouteDataType*^Hxs:string~»

| <Vafee»Digeel«/Value>

«yAttribute»

«Attribute Nefne-T)irection^H AttrtotieOataType-’^,xs:stringⁿ» j «Value» ln</Value»

«/Attribute»

«Attribute Мате>*ЕпаЫесГ AttrfcUeDetaType»"xs:bootean’>

| «Valje»true</Value>

«yAttribute»

«AtertaceOass»

«/Inter f aceCtassbb»

InterfaceClasslib — Библиотека класса интерфейсов: Name — Имя. InterfaceClass — Класс интерфейсов. RefBaseClassPalh — Ссылочный путь доступа к базовому классу. Aoribule — Атрибут. AttributaDataType — Тип данных атрибута. Digilal — Цифровой: xs:slring — Строка: xs:booloan — Булевский: true — Истина

Рисунок 18 — Пример представления пользовательского класса интерфейсов InterfaceClass в пользовательской библиотеке InteriaceClassLib

RofeClaesLib

s Name «j RoleClass

UserDetmedRoleClassLt)

s Name Fence

= RefBaseClassPath Autom<*ioriMl8e$<RoleCla$slib/AurorT«tiotM.Basefiole/Resource

«RoleClasslto Name«UserDetine<3RoleOassLlD“»

j «RoteCktss Nome-Tence* RcfBaseCtessPath«"Automatioo№i9aseRoteaassLjh/AutomationMLBasgRc*B;RBSource7> <jRoleOa$$Lib»

RokeClassLib — Библиотека ролевых классов: Name — Имя: RoleClass — Ролевой класс: RefBaseCtassPalh — Ссылочный путь доступа к базовому классу

Рисунок 19 — Пример размещения пользовательского класса ролевых классов RoleClass в пользовательской библиотеке RoteClasslib

27

ПНСТ 177—2016

7.5 Пользовательский класс системных единиц SystemUnitClass

Все классы системных единиц SystemUnitClass являются пользовательскими. В МЭК 62714 классы SystemllnitClass не рассматриваются.

Для пользовательских классов SystemUnitClass. используются нижеследующие положения:

- пользовательские классы SystemUnitClass должны храниться на языке AutomationML в формате САЕХ SystemUnitClass. Соответствующее определение приведено в МЭК 62424 (раздел А.2.3);

- пользовательские классы SystemUnitClass должны непосредственно или косвенно быть назначены для ролевых классов AutomationML RoleClass. При необходимости, они используют атрибуты AutomationML;

Пример — На рисунке 20 приведено определение пользовательского класса системных единиц SystemUnitClass с помощью двух различных примеров.

• класс SystemUnitClass «Robot1234» отображает пользовательский класс, поддерживающий роль «Resource» стандартной библиотеки AutomationML RoleClassLib. Данный класс автоматически интерпретируется как «Resource» (ресурс);

• класс SystemUnitClass «SpecialRobotl 234» отображает новый пользовательский класс, полученный из предшествующего класса «Robotl 234». Таким образом, данный класс также является ресурсом.

«| Sy»temUnitCM*sUb

s lUme UserOetnMSystemUneOftSSlb •j SyttemUnKClM*

s lUme Robot 1234

SuppwtedRoleCbe*

J s RefRoleCUssPath Ai4<mMuyM.Be$eRoleCla»slto/AUOfnetiorMUfe$eR4ie/Resource

Sy*t«mUnMCMs«

= lUme SpeciaRobatl234

J = R«fBj8«CU9»P4th UserOefn«iSy8JwnUn*OastLibiRctc<l23^

<Systemunia«suti Nerne«*U$erDemedSYStemUntaa»tJ)“»

! <SystemUniOess Name-T?obct1234*»

j | <Support6dRo4eO*s$RefRoleCtessPe№-”AutorMtiorMJfcKeftoleaessUbJ(AutoiMttonMJtoseRoi6fie$ovce*/> i «/SystemUnitClass»

; «SystemUntCtoss Name»*SpeaoFobo<l 234" RefBoseOessPath»TJseff)efinedSysten>UniqessH)iRobotl 234-fa </SystemUniClas$Ub»

SystemUnrtCIsssLib — &н6пиоте«а класса системных единиц. Name — Ии*; SyslomUnilCtast — Класс систеимых единиц; SupportedRoteClass — Поддержмааомыи ролевой класс; RefRoleClassPath — Путь доступа к ссылочному ролевому классу

Рисунок 20 — Примеры для различных пользовательских классов системных единиц SystemUnitClass

7.6 Пользовательские иерархии экземпляров InstanceHierarchies

Формат иерархий САЕХ InstanceHierarchies обеспечивает хранение индивидуальной и проектно-технической информации. Данные иерархии формируют основу формата верхнего уровня языка AutomationML. Они содержат все индивидуальные объекты данных, включая свойства, интерфейсы, соотношения и ссылки.

Для пользовательских иерархий экземпляров InstanceHierarchy. используются нижеследующие положения:

• настоящий стандарт не ограничивает глубину уровней иерархии:

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

• настоящий стандарт не определяет конвенции именования рассматриваемых иерархий;

• каждый объект языка AutomationML внутри рассматриваемой иерархии экземпляров InstanceHierarchy должен непосредственно или косвенно закрепляться за ролевым классом AutomationML RoleClass для указания своего абстрактного типа.

Рисунок 21 содержит пример иерархии, включающей линию «L001» со станцией «S001», содержащей двух роботов «R0010_D» и «R0020JD». конвейер «RF010» и программируемый логический контроллер PLC «Р001».

28

ПНСТ 177—2016

Q ExampleHierarchy

Ei Q L001

e Щ sooi

R0010.D

R0020.D

RF010

P001

ExsmpteHierafchy — Иерархия примера

Рисунок 21 — Пример пользовательской иерархии экземпляров instanceHierarchy

На рисунке 22 приведено представление AutomationML для рассматриваемой структуры. В соответствии с МЭК 62424 (раздел А.2.9), каждый объект ассоциирован с ролевым классом RoteClass.

«trelanceHerarchv Ивггв--Ехотр*е1 ler«rchy*>

«rterneCIwnertMene-T.OOI'O-'OUDI*»

«Me>nae»m«t Nen«-*S001"

<MemeBemert Heme-ltOOlOJr 0-"0U03" Re^eSy«tecriUritP^Ttobc&Jbraryjftoeot .12ЭГ*

| *RcieR»e|i*wwft»Reree»eRo<eCie8sFe^*AulomeeonMU¹toleCle«U»tiU4cmellor*ldB«eRolwRe80urce^-/v «*tem«Qetnert>

<Wem«eemert Namcx’POOQO.p^ O-'0UD4' Re’a^SysterrOHPem-'TfotrtUbrary^obotJ »**>

| «KcteRetMremert* RgT&aseftc^eCW^sPgtn-'AUotnqBorM-ftoHQassLto/AUoKxeorMLBBgenote^tasoufc»*/»

«AnternaBeeiert»

«MemaClemert NwiwtifOKr D>*OUOS*>

| «PoWbquremerls RereescRMeOe$sPolh«'AUomeliof*tito*eClas8Lto/’AUc*>«*»xMLBeeeftotejRe80urce“fr <*terne€lemeft>

«ttemedemert М*т*.*М0Г D-*OUC>e*»

| «ftctoRequverMrt»Re?8»$eRo^»3sPeth-*ALtofNtorecC$ftoieCtossUMCortroCqMlpmnt£ortrot1«r*ff«r«ContnteA.C*rv

«МетавомФ

«Roteftequrements ReiBeseRoleOa$sP(Kri*Vkttcin4iorMJtoleC)es3L)bMUoiMtaiMLeMeftDlMtesourcaStnjcture^,,£ <Меггив*тап|»

«RoieRequremerts Ее^Э»сЯоиО«>Р|И>»УМ4ом<<спШ*о1вС1в»<иЫАи>оямВопМ.Вив8с*б1Рмосг'свЙ>ис>ме'> <*Kema©emert»

<Anstanc*Heterchy>

Рисунок 22 — Представление AutomationML для пользовательской иерархии экземпляров InstanceHierarchy

8 Расширенные понятия языка AutomationML

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

8 настоящем стандарте определены расширенные понятия для моделирования специальных инженерных аспектов. Справочный обзор и примеры приведены в А.2.

8.2 Объект порт AutomationML Port

Порт AutomationML Port — это объект языка AutomationML. группирующий нескопько интерфейсов. Справочный обзор понятий порта и примеры приведены вА.2.2.

Для портов AutomationML Pod. используются нижеследующие положения:

• порт AutomationML Port должен быть описан в формате внутренних элементов САЕХ IntemalElements в ассоциации с ролевым классом RoteClass «Port», описанным в разделе 6.4.5:

• объект порта AutomationML моделируется как дочерний объект рассматриваемого объекта (класса) AutomationML;

• необходимый набор интерфейсов описывается в формате внешних интерфейсов САЕХ Extemallnterface объекта порта:

29

ПНСТ 177—2016

• объект порта ие должен содержать дочерних внутренних элементов САЕХ InternalElements;

• все внешние интерфейсы САЕХ Extemailnterface объектов порта должны непосредственно или косвенно выводиться из класса интерфейсов AutomationML. определенного в разделе 6.3;

• порт AutomattonML Port должен дополнительно иметь, по крайней мере, один внешний интерфейс САЕХ Extemailnterface. полученный из класса интерфейсов AutomationML InterfaceClass «PortConnector», описанного в разделе 6.3.4.

Примечание — Дополнительные нормативные положения {в части атрибутов объекта порта) приведены в разделе 6.4.5.

8.3 Объект фасет AutomationML Facet

Фасет AutomationML Facet — это объект языка AutomationML. определяющий общее для некоторой совокупности атрибутов (интерфейсов) языка AutomationML представление одного родительского объекта языка AutomationML. Данное понятие облегчает хранение настроек различных конфигураций (например, параметров человеко-машинных интерфейсов HMI, параметров программируемых логических контроллеров PLC) и позволяет автоматизировать некоторые шаги технического управления. Например, настоящий стандарт определяет ролевой класс AutomationML RoleClass «Facet» (см. раздел 6.4.4). Справочный обзор понятия фасет и примеры приведены в разделе А.2.3.

Для фасета AutomationML Facet используются нижеследующие положения:

- объект фасет AutomationML Facet описывается в формате внутренних элементов САЕХ InternalElements в ассоциации с ролевым классом RoleCfass «Facet», описанным в разделе 6.4.4;

> объект фасет AutomationML Facet моделируется как дочерний объект рассматриваемого объекта (класса) AutomationML;

- фасет должен иметь уникальное среди ближайших родственных элементов произвольное имя;

Примечание — Имя фасета имеет важное значение для ассоциации с понятием Group. Отысания понятий и примеры приведены в разделе А.2.3.

- объект (класс) языка AutomationML может иметь произвольное количество объектов фасет;

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

- атрибут фасета должен относиться к существующему атрибуту родительского объекта AutomationML. Идентификатор должен совпадать с именем. Атрибуты фасета, не являющиеся частью родительского объекта, недопустимы;

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

• фасеты не должны содержать новых дочерних объектов, атрибутов, интерфейсов;

• объект фасет не должен быть встроенным;

- фасеты не должны модифицировать существующие атрибуты и интерфейсы.

8.4 Объект группа AutomationML Group

Понятие группы AutomationML Group позволяет отделить структурную информацию от информации об экземпляре. Справочный обзор понятия группы и примеры приведены в разделе А.2.4.

Для объектов группы AutomationML Group используются нижеследующие положения;

- объекты группы AutomationML Group описываются в формате САЕХ InternalElements в ассоциации с ролевым классом RoleClass «Group», определенным в разделе 6.4.3;

- объекты группы AutomationML Group моделируются в произвольной позиции иерархии экземпляров InstanceHierarchy или класса системных единиц SystemUnitClass;

- количество объектов группы AutomationML Group не ограничено;

- объект группы AutomationML Group должен содержать только зеркальные объекты и/или последующие объекты группы;

Примечание 1 — Таким образом, объекты группы могут быть встроенными.

Примечание 2 — Если экземпляр А ссылается на другой экземпляр А*, то А называется «зеркальным объектом», а А* — «главным объектом» (в соответствии с МЭК 62424:2008 (раздел А2.14)). Зеркальный объект ссылается на главный объект и все его данные. Таким образом, зеркальный объект работает как указагегъ главного объекта.

• группы AutomationML не должны использоваться для описания иерархии установки;

30

ПНСТ 177—2016

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

Примечание 3 — Указанные дополнительные атрибуты, порты и интерфейсы не идентичны атрибутам, портам или интерфейсам рассматриваемых зеркальных объектов.

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

• зеркальные объекты должны иметь свой собственный уникальный идентификатор Ю;

Примечание 4 — Зеркальный объект считается идентичным главному объекту. Идентификатор помогает отличить зеркальное представление от главного.

• если главный объект стирается, то все соответствующие зеркальные объекты также стираются во избежание неоднозначности;

Примечание 5 — Рассматриваемая функциональность инструментального средства в настоящем стандарте не рассматривается.

• если зеркальный объект стирается, то главный объект не должен быть поврежден;

• если используется атрибут ассоциированного фасета «Associated Facet», то его значение обеспечивает корректность имени существующего фасета.

8.5 Набор свойств AutomationML PropertySet

Набор свойств PropertySet — это ропввой класс, содержащий набор атрибутов с четким синтаксисом и семантикой. Данный набор моделируется как ролевой класс, полученный из стандартного ролевых классов «PropertySet». Концептуальный обзор приведен в разделе А.2.5.

Для понятия набор свойств PropertySet используются нижеследующие положения:

• класс PropertySet моделируется как ролевой класс. Он выводится непосредственно или косвенно из стандартного ролевых классов «PropertySet»:

• классы PropertySet могут собираться в одну или несколько библиотек ролевых классов;

- объекты AutomationML могут ассоциироваться с одним и более классом набора свойств:

• для каждого набора свойств PropertySet объекта AutomationML создаются отдельные дочерние внутренние элементы САЕХ IntemalElements объекта AutomationML. которые не определяют какие-либо атрибуты САЕХ. интерфейсы или внутренние элементы IntemalElements. за исключением имени и идентификатора Ю. Дочерний объект должен ассоциировать ролевой класс PropertySet с помощью элемента САЕХ «RoleRequirement»;

• отображения между атрибутами объекта AutomationML и ролью PropertySet моделируются с помощью элементов отображения САЕХ «MappingObject» и «AttributeNameMapping» внутри соответствующих дочерних внутренних элементов IntemalElements. Указанные отображения между рассматриваемым объектом AutomationML и ссылочным набором свойств PropertySet являются корректными. Отображенные атрибуты копируются в раздел RoleRequirement. Это копирование не является обязательным:

• атрибуты PropertySet могут быть вложенными;

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

Рисунок 23 иллюстрирует вышесказанное на примере. Объект Robot_1 имеет несколько пользовательских атрибутов. Дочерние внутренние элементы IntemalElements (IE) ассоциируются с геометрией набора свойств PropertySet «Geometry», определяющей соответствующие атрибуты. Объект отображения внутреннего элемента MappingObject 1Е содержит описание указанного отображения собственных и стандартных атрибутов.

8.6 Поддержка нескольких ролей

8 добавление к МЭК 62424 (раздел А.3.18), настоящий стандарт определяет порядок поддержки нескольких ролей для экземпляра объекта. Рассмотрение сразу нескольких ролей имеет смысл, если объект поддерживает несколько различных функциональных возможностей. Например, устройство, которое одновременно является сканером, принтером и факсом. Обзор и примеры приведены в разделе А.2.7.

31

ПНСТ 177—2016

[nstanceHierarchv

AML

Document

L| MyHieratchy~|

Considered

AML

Object «nth user defined attributes

RefBaseRoleClassPalh

Attr ibuleNomeMapping Lange = Length Breite = Width Hohe = Height

InstanceHierarchy — Иерархия экземпляров. Automation ML Document — Документ языка AutamabonML: MyHierarchy — Моя иерархия. Station — Станция. IE — Внутренний элемент. MappmgObfect — Объект отображения: AltnbutoNameMappin: Lange » Length. Breite ■ Width. Hohe * Height — Отображение имени атрибута: длина, ширина, высота. Considered AutomationML Object with user defined attributes — Рассматриваемый объект языка AutomabonML с пользовательскими атрибутами. RoleCtassLib — Библиотека ролевых классов; MyPropertySetRoleClassLib — Моя библиотека ролевых классов набора свойств: Geometry — Геометрия. Length. Width, Height — Длина, ширина, высота. Attribute Linge. В rede. H6he — Атрибуты длина, ширина, высота; RefBaseRoleClassPalh — Ссылочный путь доступа к базовому ролевому классу

Рисунок 23 — Пример, иллюстрирующий понятие набора свойств PropertySet

Для поддержки сразу нескольких ролей используются нижеследующие положения:

• если экземпляр поддерживает только одну роль, то она описывается с помощью атрибута САЕХ «RefBaseRoleClassPath», принадлежащего требованию RoleRequirement;

Примечание 1 — Вышесказанное соответствует МЭК 62424 (раздел А.3.18). в котором устанавливается единовременная поддержка только одной роли.

- если экземпляр поддерживает несколько ролей, то каждая из них определяется с помощью элемента САЕХ «SupportRoleClass» вместо использования атрибута САЕХ для пути доступа к базовому ролевому классу «RefBaseRoleClassPath»:

Примечание 2 — Атрибут «RefBaseRoteClassPath* может назначаться только один раз для элемента требования RoteRequirement. При этом элемент САЕХ «SupportRoleClass» можег быть определен несколько раз. Он является ключевым для назначения нескольких ролей. Однако, в соответствии с МЭК 62424. это слабое семантическое расширение. Оно не изменяет формат данных САЕХ.

• если экземпляр поддерживает несколько ролей, то требования к различным ролям должны храниться в самом экземпляре, это осуществляется с помощью элемента САЕХ «RoleRequirement». При этом соответствующие атрибуты и интерфейсы назначаются непосредственно, включая имя роли, строку сепаратора «.в и атрибут (имя интерфейса);

Примечание 3 — В соответствии с МЭК 62424 данное семантическое расширение является слабым. Оно не изменяет формат данных САЕХ. Отличие МЭК 62424 (раздел А3.1 В) заключается в том. что имя роли добавляется в определение атрибута (интерфейса). Пример см. в разделе А.2.7.

• если несколько поддерживаемых ролевых классов уже указаны и элемент САЕХ «RoleRequirement» одновременно ассоциирован с определенным путем доступа «RefBaseRoleClass Path», то ассоциированный ролевой класс является предпочтительной ролью. В данном случае определения атрибута и отображения атрибута (интерфейса) требования к роли RoleRequirement (без явного префикса имени роли) ассоциируются с данной предпочтительной ролью.

Примечание 4 — Указанная предпочтительная роль используется в соответствии с МЭК 62424 (приложение А) без семантического расширения.

32

ПНСТ 177—2016

* InifemlUifiRfw_

■ Name MyHwrareky

шмггшвепнш

s Name SUtfen

= io

lntomaO«<n«nt

GU01

KMJ

s to GWJ2 ± Attnbet# (?)_ a Name 1 IKM

2 Brett

3 1*Ф»

Inter ntKknncnl

s Name E

= Ю GUDJ л. nolenageirawnta

J a RcfBo»cfMeCla»aPalh Uy®iopwty3«lRoieC(o*»^*>'Oe«'nc»y MspCMogOCiect

*{ АМм(еаимМарр*агЭ^

gJWeAtlrlbiaf toina s Sy*t#mOrvtAttnbirt*N»ma

1 !A«W* tWM

2 WM№ Brett

3ie*fltn Un«e

- fteWCIaaalib

s mine My^opeaybawieUBsaLjt RotoCbn

S Name

Gaonefry

a WefBaacOaeaPttbAxtoataooaM^k^aftcieCb^.te'ANDattwaMLBaBaNaiattapartyBN

AltrDute<Jl _ _

— Name

1 HnoM

2 Wdtt

i Length _

<JnslanceHtererchy Nam9*'My4H»erarchy’‘>

<lntemefElement Name=*StaUon^N ID=*G0ID1*>

<lnt«nfittite<r>ent Name*'RoboM' ■>*GU102*>

<Annbuta Name=’Hche7>

<Atinbu»e Name«*8rerte"/>

<Anrv6ute Name«'L*ngeV>

«IntomedomerYi Nornc^lE* ID='<SUI03'‘>-

<RottReqwrwnent* Re<8weRoleCi*siPath=^KMyPropert)fSetR<ieCia$$UbrfGeomeby^,/>

«MappergObjeet*

<AttribuleName Mapping R6eAHrfcuteName=’Heighr Sy*t*mUn<AtHjuteName=*H6he’/>

<Attr4>uteN acne Mapping Roitt^trtuteNam««3WkNh’ Sy*tofTrtjnitAtti^,fcutaNarne«^,Bttrte’V>

«AttrtxfteName Mapping RateARrtxrteNiarne-’Length" SyetemUnitAttributeNeme*'Lange7>

</MappingObject >

<AnlemalEiement>

«/IntemaElement»

</lntemafEtemenl>

«дпзмгсеНигагспу»

<RcteCesslfc Name**MyPropertySetRoteCtessLib">

<RotoCl»« Names''Geo(netry* RglBa6eCtaesPath=*Automat*onMLBaeeRoleCtaesUb/AutomalionMLB»eR<MPropertySet*> «Attribute N ame**Heighr/>

«Attribute Names-WidlhT»

«Attribute N eme--L«ngth7>

</RcteCia$s>

«^RdeClassLib»

Рисунок 24 — Пример описания набора свойств PropertySet на языке XML

33

ПНСТ 177—2016

8.7 Разбиение данных AutomationML верхнего уровня на различные документы

В соответствии с МЭК 62424:2008 (раздел А.2.12). формат САЕХ явно поддерживает распределение инженерных данных между различными файлами и обеспечивает работу механизмов ссылок на внешние файлы САЕХ с помощью внешней ссылки САЕХ «ExtemalReference» и соответствующего понятия с косвенным доступом в формате САЕХ.

8.8 Интернационализация

Различные языки (для конкретных имен и описаний) могут храниться в языке AutomationML в соответствии со спецификациями языка XML и текстовым форматом UTF-8.

8.9 Информация о версии объекта AutomationML

Для хранения информации о версии и пересмотре индивидуальных объектов AutomationML (экземпляров объектов) используются стандартные версии и утвержденный порядок пересмотра в соответствии с МЭК 62424 (раздел А.2.2.2).

Для хранения информации о версии объектов AutomationML и информации о библиотечной версии AutomationML. см. раздел 5.3.

Хранение специальной метаинформации об инструменте — см. раздел 5.4.

34

ПНСТ 177—2016

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

введение в язык AutomationML

А.1 Общие понятия языка AutomationML

А.1.1 Архитектура языка AutomationML

Язык разметки автоматизации AutomationML — это схемный формат данных расширяемого языка разметки XML. разработанный для обеспечения независимого обмена (продавцом) инженерной информации о производственной установке. Цепью языка AutomationML является обеспечение взаимосвязи средств инженерии (на неоднородном множестве инструментальных средств инженерии) в различных дисциплинах: проектирование механизированного оборудования, электротехническое проектирование, проектирование производственных процессов, управление производственными процессами, разработка человеко-машинного интерфейса (HMI). программирование логического контроллера (PLC), программирование роботов и т. д.

Язык AutomationML накапливает инженерную информацию а соответствии с имеющейся объектно-ориентированной парадигмой. Он позволяет моделировать конкретные компоненты производственной установки как объекты данных, инкапсулирующие различные технические аспекты. Рассматриваемый объект может включать под-объекты. Он может сам быть частью большой композиции (агрегации). Данный объект может описывать: сигналы, контроллеры PLC, накопители, клапаны управления, роботы, производственные ячейки (с различным уровнем детализации), производственные площадки и производственные пинт. Типовые объекты автоматизации производственных установок включают информацию о топологии, геометрии, кинематике и логике. При этом логика включает последовагвпьностъ'утюрядоченносгъ. поведение и управление.

Язык AutomationML объединяет существующие промышленные форматы данных, разработанные для хранения и обмена инженерной информации по различным аспектам. Указанные форматы данных используются «как-есть» на основе их собственных спецификаций. Они не подстраиваются под требования языка AutomationML.

Ядром языка AutomationML является формат данных САЕХ верхнего уровня. Он соединяет различные форматы данных. Таким образом, язык AutomationML имеет унаследованную распределенную архитектуру документов.

Рисунок А.1 иллюстрирует базовую архитектуру AutomationML. а также распределение информации о топологии. геометрии, кинематике и логике.

Automation Markup Language

Engineering data

Automation Markup language —- Язык разметки автоматизации; Engineering data — Инженерные данные, САЕХ IEC 62424 Top level formal — Формат верхнего уровня САЕХ МЭК 62424; Plan! topology information — Информация о топологии производственной установки; Plants Установки, Celts — Ячейки. Components — Компоненты; Attributes — Атрибуты; interfaces — Интерфейсы. Relabons — Соотношения; References — Ссыпки: Object А — Объект A: COLLAOA — Формат COLLADA. Geometry — Геометрия. Kinematics — Кинематика: PLCopen XML — Формат PLCopen XML. Behavior — Поведение: Sequencing — Упорядоченность; Further XML Standard format — Прочие стандартные форматы XML: Further aspects of engineering information — Прочие аспекты инженерной информации

Рисунок А.1 — Общая архитектура языка AutomationML

35

ПНСТ 177—2016

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

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

• Информация о топологии установки: топология производственной установки описывает установку как иерархическую структуру, включающую индивидуальные объекты установки, представленные индивидуальными объектами данных. Структура данных объектов моделируется на определенном уровне детализации (например, робот целиком, механизм захвата целиком, но не отдельные его валы или соединительные элементы). Данные объекты включают свойства и соотношения с другими объектами в рамках рассматриваемой иерархической структуры. Топология установки работает как структура данных верхнего уровня. Информация хранится в формате данных САЕХ в соответствии с МЭК 62424 (раздел 7. приложения А и С). В расширенной версии МЭК 62424, язык AutomationML определяет ссылки из объектов САЕХ на информацию, хранящуюся во внешних документах (вне формата САЕХ). Подраздел А.1.2 содержит примеры моделирования информации о топологии установки на языке AutomationML.

• Информация о геометрии и кинематике: геометрия отдельного объекта установки включает его геометрическое представление. Информация о кинематике описывает физические соединения трехмерных твердых тел и зависимости между объектами. Информация о геометрии и кинематике хранится в файловом формате COLLADA. Дополнительно файл COLLADA включает определение информации о сопряжении геометрии и кинематики. Интерфейсы COLLADA могут быть опубшкованы как внешние интерфейсы САЕХ Externallnterface е формате верхнего уровня (для последующего установления взаимосвязей). Полное представление получается автоматически из информации о геометрии в формате COLLADA для различных объектов. На указанные файлы можно ссыпаться из формата САЕХ. Взаимосвязь указанных файлов обеспечивается с помощью связующих САЕХ-механизмов. Краткий пример имеется в подразделе А. 1.3 Подробности приведены в МЭК 62714-3.

• Информация о логике: информация о логике описывает последовательности действий и поведение объектов. соединения типа ВВОД/ВЫВОД и логические переменные. Данные последовательности описываются и хранятся во внешних документах языка PLCopen XML. Переменные и сигналы публикуются как внешние интерфейсы САЕХ Externallnterface. Указанные документы могут быть ссылочными из среды САЕХ. Они могут быть взаимосвязанными элементами внутри самой среды САЕХ. Подраздел А.1.4 содержит краткое введение е основные понятия. Подробности приведены в МЭК 62714-4.

• Информация о ссылках и соотношениях: язык AutomationML проводит различия между ссылками и соотношениями. Ссылки отображают связи объектов САЕХ с информацией, хранящейся вовне. Соотношения отображают ассоциации между объектам! САЕХ. Более того, для хранения ассоциаций между информацией, хранящейся во внешних документах, используется один и тот же механизм. Кроме того, необходимо опубликовать рассматриваемые связующие элементы с помощью внешнего интерфейса САЕХ Externallnterface в топологии установки САЕХ. Подробности выполнения ссылок на документы COLLADA и документы PLCopen XML см. в МЭК 62714-3 и МЭК 62714-4. Подраздел А.1.5 содержит справочный обэор методик моделирования ссылок и соотношений на языке AutomationML. Нормативные положения рассмотрены в подразделах 5.6 и 5.7.

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

Обмен инженерной информацией требует дополнительных расширенных понятий. Раздел А.2 разъясняет указанные понятия. Раздел в содержит нормативные положения.

Примечание — В настоящем стандарте пути доступа в ряде случаев приведены е сокращенной форме. Например, вместо пути доступа «AutomationMLtnterfaceClassLib/AutomationMLBaselnterface/Port» указан путь доступа «AutomationMLtnterfaceClassLib/..-/Port». Это облегчает чтение документа. В реальных документах XML все пути доступа указываются в соответствии с настоящим стандартом.

А.1.2 Моделирование информации о топологии установки

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

Для хранения иерархической структуры установки, язык AutomationML использует понятия в формате данных САЕХ верхнего уровня в соответствии с МЭК 62424 (раздел А.2.11). Рисунок А.2 содержит пример топологии промышленной установки производственной линии, содержащей несколько объектов на разлитых иерархических уровнях.

36

ПНСТ 177—2016

R

Project

in

Demo Cell

Sequence Une

Я [JP Sequence H 110_Geostation

т | |E | 100_Tran sport Entry

[Jtj H0_Working CeH T fitl 120_TransportExit а ПЕГ 130_Evacuation Unit

a

M

114!

114

Putte

-130TRR001

M30HER002

Cabinets

Fence

Socket.1000 Socket,1000_2

IH — Внутренняя иерархия: IE— Внутренний элемент; Project-‘-Проех^ОетоСвЯ—Демонстрационная ячейка: Sequence— Последовательность; Line — Пиния: Geostalion — Геостанция: Transport Entry — Транспортный вход. Working CeH — Рабочая ячейка; Transport Exit — Транспортный выход. Evacuation Unit — Эвакуационный блок; Puke — Пульт; Cabinets — Кабинеты; Fence — Ограждение; Socket — Разъем

Рисунок А.2 — Представление топологии установки на языке AutomationML

С помощью стандартных понятий САЕХ можно моделировать множественные иерархии, пересеченные структуры и сложные сети объектов. При этом ключом к повышению эффективности рассматриваемой объектно-ориентированной парадигмы является доступность библиотек, содержащих предварительно определенные и утвержденные инженерные решения. Кроме того, формат САЕХ реализует несколько различных типов библиотек AutomationML для интерфейсов, ролей, системных модулей и иерархий экземпляров, представляющих особую важность для объектов AutomationML.

• Классы интерфейсов InterfaceClass и библиотеки классов интерфейсов InterfaceClassLtb: интерфейсы способствуют определению соотношений между объектами AutomationML. Подраздел 6.3 содержит описание стандартной библиотеки AML-lnterfaceCtassLib на множестве абстрактных классов интерфейсов InterfaceClass. применяемых е общих системах автоматизации. Указанные классы включают их синтаксическое и семантическое определение. Они содержат спецификацию пользовательских интерфейсов объектов. Подраздел 7.3 содержит описание методики моделирования пользовательских ролевых клэооов.

• Классы ролей RoleClass и библиотеки ролевых классов RoleClassLib: классы ролей RoleClass обеспечивают определение абстрактных характеристик объектов САЕХ. Они обеспечивают автоматическую интерпретацию семантики пользовательских объектов AutomationML. Подраздел 6.4 содержит описание библиотеки ролевых классов AML-RoleClassLib с набором абстрактных ролевых классов RoleClass для общих систем автоматизации. Подраздел 7.4 содержит описание методики моделирования пользовательских ролевых классов. Он также содержит описание последующих библиотек ролей в соответствии с МЭК 62714-2.

• Системные единицы SystemUnits и библиотека класса системных единиц SystemUnitClassLib: библиотека класса системных единиц SystemUnitClassLib используется для хранения специальных классов AutomationML продавца. Подраздел 7.5 содержит описание архитектурных правил определения класса системных единиц SystemUmtClass. Язык AutomationML не устанавливает предварительных определений элементов библиотеки SystemUnitClassLib или класса SystemUnitClass.

• Экземпляры и иерархия экземпляров InstanceHierarchy: иерархии экземпляров хранят данные топологии текущих проектов и. таким образом, корневых объектов языка AutomationML. Данные иерархии включают экземпляры объектов AutomationML. Подраздел 7.6 содержит описание порядка хранения инженерной информации с помощью иерархии экземпляров типа InstanceHierarchy.

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

37

ПНСТ 177—2016

тификаторы 8 течение срока существования, другие — нет. Внутри одного инструмента это работает отлично. При этом обмен объектов между различными инструментами невозможен. Раздел 5.5 вводит понятие обязательной идентификации объекта. Данное понятие обеспечивает возможность обмениваться данными между различными средствами инженерии с помощью понятия индивидуальной идентификации объекта.

А.1.3 Ссылочная информация о геометрии и кинематике

Информация о геометрии и кинематике хранится в отдельных документах в формате данных COLLADA. Моделирование информации о геометрии и кинематике, таким образом, разбивается на две части. С одной стороны, соответствующий объект моделируется внутри формата САЕХ без учета какой-либо информации о геометрии и кинематике (в соответствии с настоящим стандартом). С другой стороны, документы COLLADA должны содержать информацию о геометрии и кинематике. Окончательно получается, что объект САЕХ содержит ссылку на документ COLLADA в соответствии с МЭК 62714-3.

Рисунок А.З содержит пример документа AutomationML. включающего объект «110RB_200*. Данный объект ссылается на внешний документ COLLADA. содержащий соответствующую информацию о геометрии и кинематике.

Ссылка моделируется с помощью интерфейса САЕХ. полученного из стандартного класса интерфейсов языка AutomationML «COLLADAInterface» (см. разделы 5.7 и 6.3.7). Подробности приведены в МЭК 62714-3.

А.1.4 Ссылочная информация о логике

Информация о логике хранится в отдельных документах в формате данных PLCopen XML. Моделирование информации о логике, таким образом, делится на две части. С одной стороны, соответствующие объекты моделируются внутри САЕХ без учета какой-либо информации о логике в соответствии с настоящим стандартом. С другой стороны, документ PLCopen XML должен содержать информацию о логике в соответствии с МЭК 62714-4. Окончательно получается, что объект САЕХ должен иметь ссылку на документ PLCopen XML. Рисунок А.4 содержит пример документа AutomationML. включающего объект «110_Workirtg Cell» (рабочая ячейка), имеющий ссылку на внешний документ PLCopen XML. содержащий соответствующую информацию о логике.

САЕХ document

ItO.WMfcmgC*» -1105АЕ011 -nOCSTOCO - 110ПГМ001 -110НШХИ -llORfl.MC

■ими. ICO

-IIOOBJttt-HMt -iiols.ooi

>11015 002

CAEX document — Документ САЕХ: COLLADA document — Документ COLLADA. Working Cel — Рабочая ячейка: E — Внутренний элемент

Рисунок А.З — Ссылка из объекта САЕХ на документ COLLADA

САЕХ document

Bill ItO-WertancCeH

• tlOWfOU -MOGSTOOO

в № -110ИТМ001 S Д] =П0НТИ»1

в№-ш«иво

в Щ -llORfl.lOO

»ll№0JOO+H2Ot

• UOLS.OOl

• HOLSOQ2

PLCopen XML document

CAEX document — Документ САЕХ: PLCopen XML document — Документ PLCopen XML: Working Cell — Рабочая ячейка: Step I — Шаг 1; End — Конец: Ind — Инициализация

Рисунок A.4 — Ссылка из объекта САЕХ на документ PLCopen XML

38

ПНСТ 177—2016

А.1.5 Моделирование соотношений

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

Соотношение выражает ассоциацию между двумя и более объектами. Данная зависимость может быть любой природы (физической или логической). Язык AulomationML поддерживает нижеследующие соотношения:

• соотношения «родитель-потомок» (см. разделы 5.6.2 и 5.6.3):

• соотношения «родитель-потомок» между объектами AutomationMU

• соотношения «родитель-потомок» между классами AutomationML:

• соотношения наследования (см. раздел 5.6.4):

• соотношения наследования между классами системных единиц SystemUnitClass:

• соотношения наследования между ролевыми классами RoteCtass:

• соотношения наследования между классами интерфейсов tnterfaceClass:

• соотношения «класс-экземпляр класса» (см. раздел 5.6.5):

• соотношения между классом SystemUnitClass и его экземпляром:

• соотношения между классом RoleClass и его экземпляром.

• соотношения между классом interfaceCtass и его экземпляром:

• соотношения «экземпляр-экземпляр» (см. раздел 5.6.6):

• соотношения между объектами AutomationML:

- соотношения между опубликованными данными, хранящимися вовне.

Рисунок А.5 содержит пример типов соотношений, поддерживаемых языком AutomationML.

Рисунок А.6 иллюстрирует модель AutomationML. соответствующую данному примеру, с помощью табличного представления. Отметим, что информация о пути доступа может сокращаться с помощью поля что улучшает читаемость. Рисунок А.7 содержит описание на языке XML. соответствующее рассматриваемой библиотеке AutomationML.

Рисунок А.8 содержит описание иерархии экземпляров InstanceHierarchy на языке XML.

AML

Document

-»| MySystemUmlLlb |

-Н C.Robot К L»| C_Robot_1

Inheritance

relatk)n

-*\ MyHierarchy

Ц.

Stabon

Class-

instance

relation

RoboM г

|

PLC_1 | tcMnnccipeJ

Instance-

instance

relation

Conveyor_

El

Parent-child

relation

Convey or_1_l|

AutomationML Document — Документ AutomationML: MySystemUnitLib — Моя библиотека системных единиц: C_Robot — Робот С; Inheritance relation — Соотношение наследования: MyHierarchy — Моя иерархия: Station — Станция: Class — instance relation — Соотношение «класс—экземпляр класса»: PLC_1 — Программируемый логический контроллер 1: Start — Старт; СИаппеЮ1 + — Канал 01+; Instance — Instance relation — Соотношение «экземпляр—экземпляр»; Conveyor_t — Конвейер 1: Parent — child relation — Соотношение «родитель—потомок»

Рисунок А.5 — Соотношения, поддерживаемые языком AutomationML

39

ПНСТ 177—2016

SystemUnrtClassLib — Библиотека класса системных единиц; Name — Ныв; SystemUnilCtass — Класс системных единиц: tnhereance relabon — Соотношение наследования; RefBaseClassPalh — Ссылочный путь доступа к баэоеому классу: InslanceHieraichy — Иерархия экземпляров. InternatEtemenl — внутренний элемент. Class-instance tetation — Соотношение • класс-экземпляр класса»; 1D — Идентификатор; RefBaseSyslomUnitPath — Ссылочный путь доступа к базовым системным единицам: Exlemallnterface — Внешний интерфейс: Parent-child relabon — Соотношение «родитель—потомок». InlernalLink — внутренняя связь, HardwareLinkl — Аппаратная связь 1. RefPartnerSideA — Ссылочная сторона Л партнера: Instance-instance relation by an InlernalLink — Соотношение «экземпляр—экземпляр», установленное внутренней связью

Рисунок А.6 — Пример описания соотношений на языке XML

«SystemUntClassUb Name-'MySystemUnaUb"» j «SystemUnflOass Name-^_RoboT/>

I «SyslemUnitClass №«ne*‘C_Robot_1 “ Ref0aseClassPath»7#ySyste»nUn*LWC_Robot^,,/> «/SyttemUntCleseLb*

Рисунок A.7 — Огмсание примера соотношений библиотеки класса системных вдинии SystemUrvtClassl* на

языке XML

40

ПНСТ 177—2016

<ln*ianc «Hierarchy N»T«s'R#ieiJon»Exampie'>

<htemalE!ement Nane=’Station' iD='GUID1*>

«InlemalEfement Name='Rob1“ I0=*GUI02* RefBaseSyslemUmtP3th=-MySystemUn«lLifcu"C_Robot_f> «Extemailnterface Name*“Starr Re<BaseClassPath«‘ AutomalionMLInterfaoeClassLibf.. /Signaltnterface'/> «/internals lement>

<WemalEiem«ntN»ne*’PLCr ID*'GUID3">

«IntemafElemertt Name«‘BoardOr IO*^HGUI04">

<Externalinlefface Name»"ChannelOr RelBeseCtassPath>‘AuiometicnMLIntafeceClassljb'.. /Signailnterface'V> <«1ntemalEJerr»ent>

</liVemalElement>

«IntemalEtement Name»*Conveyor_r ID»‘GUID5*>

OntemalElemertf Name="Mota" iD='GUID67>

</lntemalElement>

«IntemalLir* Name=*HardwareLlnkr RefPartnerSKteA=‘GUtD2:StaiT RefPaftner$kle8=''GUID4:ChanMl01'> </lntema!Etement>

Рисунок A.8 — Описание примера соотношений иерархии экземпляров InstanceHierarchy на языке XML

А.2 Расширенные понятия языка AutomationML и примеры А.2.1 Общий обзор

Язык AutomationML определяет расширенные понятия для моделирования специагъных инженерных аспектов. Например, понятие порта AutomationML Pori, понятие фасета AutomationML Facet, понятие группы AutomationML Group. В таблице А. 1 приведен обзор указанных расширенных понятий.

Таблица А.1 — Обзор основных расширенных понятий ямка AutomationML

А.2.2 Понятие порта AutomationML Port

А.2.2.1 Описание понятия порт

Порт AutomationML Port — это объект языка AutomationML. группирующий несколько интерфейсов (см. рисунок А.9). Объект порта принадлежит одному родительскому объекту языка AutomationML и описывает комплексные интерфейсы родитетъекого объекта. Порты соединяются друг с другом на более высоком уровне абстракции, чем просто связь с каждым отдельным интерфейсом. Понятие порта AutomationML Port может описывать «вилки», «розетки» и любые другие группы интерфейсов, непосредственно соединенные друг с другом. Кроме того, язык AutomationML определяет понятие AutomationML для ролевых классов RoleClass «Рог!» (см. раздел 6.4.5). Нормативные положения рассмотрены в разделе 8.2.

А.2.2.2 Пример

Рисунок А.10 содержит пример понятия порта AutomationML Port. Объект «Station» (станция) включает под-объекты «Конвейер1» и «Конвейер2». Оба под объекта имеют один объект порта каждый. Объект порта содержит набор интерфейсов, а также стандартный интерфейс «Connection-Point» (точка соединения), полученный из клас-

41

ПНСТ 177—2016

САЕХ IntemalLink

-PortConnector-

К

-Qmptfi

<)*wa

Inpiill Input3 ^ , Output l'^' Output2( '

O-*

Port

Conveyor2

CAEX IntemalLink — Внутренняя связь CAEX; Conveyed — Конвейер 1; Port — Порт; PortConnector — Коннектор порта; Oulputt — Выход f. Input2 — Вход 2

Рисунок А.9 — Понятие порта

Station — Станция: Conveyorl — Конвейер 1; Port — Порт; Attribute Category — Атрибут «категория*; Interface «ConnectionPoint» — Интерфейс «точка соединения»: Interface «Output 1* — Интерфейс «выход 1»; Interface «Inputl* — Интер* фейс «вход I»; Internal link — Внутренняя сеять

Рисунок А.10 — Пример описания понятия AutomationML Port

са интерфейсов AutomationML InterfaceClass «PortConnector». Данный стандартный интерфейс может соединяться с помощью внутренних связей CAEX Internal Links. Рассматриваемое соотношение означает, что оба порта соединены друг с другом. Внутренже связи субинтерфейсов не описаны здесь в подробностях. Рассматривается соединение только абстрактных точек ConnecbonPoints. Кроме данного понятия, язык AutomationML допускает хранение каждого индивидуального связующего элемента, расположенного между субингврфейсэми.

Рисунки А.11 и А.12 описывают практическую реализацию на языке AutomationML примера системы, приведенной на рисунке А.10.

А.2.2.3 Моделирование порта как пользовательского класса системных единиц AutomationML SystemUrvtClass

Рисунок А.13 содержит пример описания пользовательского класса системных единиц SystemUratClass «myPortCtass» на языке XML.

42

ПНСТ 177—2016

tnetunceAcurchy

= патетчхтесатря*

4' кмт>С1*'п*<<

s Нане Stefan = № OUW » nneuialtleiiteet

в H*nv« Conveyor! = Ю GO 02 +• kitetnaKlenKrit = lUme ю

Port

loura

el ExlMiulHtite e; Я

1

S Heme

I ComeetorAwt t CMpuil

3 CUpuK

4 imuii

5 lr«U2

: RetBaseClassPath

Ajternjtonwunfcr tecsOoc-cl. ti iWUnbt'eH^OejsL*-' Аасктипопмиглвпжвеиввиы AJornHtocMLMetfaoeOessib; AJcmtorMUrfcrfKeOeesLt/

S R*f3*««R<>loCla«aPdthA<<»T>*<ViUie«!*R<ACte$Sl.ti^

<N p.olef.eqiih eroent*

_ J s RefBaseRoleCI*s*R.rth AdomttorMLSaseRcteCtossLfe/ Лв*оисе_

* intiniiHmM

S Hen» СспуоуатЗ_

Is ID GOD4 Niter itatflemciit s Heme s ю

£ortCvre>a«

/Tipialrte'ece

ЗДре1гмг*аев

^iyietrter’ece

/SijyieWer'ece

yport

ил

Attrfcutc

txl« naltrterf ace CSj

1= Heme

s AttiiHMelMtalype <) Valeo

= lUme t Ccmederfort

г irpjti

3 lncU2

4 Out pull

5 OtiputS

string

= ReTBaeeCta»cP«li A^cminrrttUnterfnceOassLA/ AutOftiBiorA<unlei«KeOwL*/ •MornSonMUntertoceOessLW Аиюткюгмип1в1Гвс«авв«ш. Aii^brMUni»(acea»sLbJ.

» Roldlct^w cfikcnl»

]

I s RefiUscRoteCUtePatli Ajtcm«tonML8*s*RcteCI«sLb/

ei RoteReqiwenents

J _s ReffaaeRoleCUeePaihAUanSonMlBaseRaieQsssLb/. Atouce

MetnelLli* (!)

s Rente s RHRaitnetSMeA — RePatlnetSMeti

1 L1 OUOJConnectKfPofrt GUC*5Conneet>cnPc<rt

AsrtComedor

.CignoWo'oce

£krwktcracc

JSipHtkter'ace

/SgnaHerfnee

JM

InslenceHierarchy — Иерархи* экземпляров: Name — Имя: IntemalElement — Внутренний элемент: 10 — Идентификатор: Attribute — Атрибут. AtlrtouleDataType — Тип данных атрибута. Value — Значение. Externallnlerface — Внешний интерфейс, RetBaseCbssPath — Ссылошый пут» доступа к базовому классу. RoleRequirements — Требования роли: RetBaseRoleClassPath — Ссылочный пут» доступа я базовому ролевому классу: ConnoctionPomI — Точка соединения: RefPartnerSideA — Ссылочная сторона А партнера: IntemalLink — внутренняя связь

Рисунок А. 11 — Описание понятия порта AutomationML Port на языке XML

43

ПНСТ 177—2016

Описание на языке XML понятия порта AutomationML Port

v

5

путь доступа к ролеаоыу классу

Рисунок А.13 — Определение пользовательского класса портов AutomationML «myPortClass»

ПНСТ 177—2016

А.2.3 Понятие фасета AutomationML Facet

А.2.Э.1 Описание понятия

Фасет — это объект языка AutomationML. обеспечивающий представление атрибутов и интерфейсов родительского объекта AutomationML. Данное понятие облегчает хранение различных настроек конфигурации (например. настроек человеко-машинного интерфейса HMI, программируемого логического PLC контроллера и тд.) и способствует автоматизации некоторых шагов разработки системы управления производством. Кроме того, язык AutomationML определяет понятие ролевых классов AutomationML RoieOass «Facet» (см. раздел 6.4.4). Нормативные положения рассмотрены в разделе 6.3.

Описанная подгруппа атрибутов и интерфейсов относится к определенным инженерным аспектам. Она может хранить информацию о соответствующих инженерных решениях или шаблонах. Синтаксис и семантика указанных имен (значений) атрибутов в настоящем стандарте не рассматриваются. Они интерпретируются с помощью внешних средств инженерии, учитывающих синтаксис и семантику соответствующей информации. Таким образом, для работы указанных алгоритмов и выполнения задач автоматизированного проектирования нужна только информация о фасетах. Допустим, что атрибуты объекта включают имя шаблона кода программируемого логического PLC контроллера, а интерфейсы описывают входы/выходы данного шаблона. Получается, что алгоритм генерации кода PLC контроллера, учитывающий семантику рассматриваемых атрибутов и интерфейсов, может генерировать код PLC контроллера из имеющейся информации. То же самое происходит и с шаблоном человеко-машинного интерфейса HMI. Вышеупомянутые внешние алгоритмы, а также семантика соответствующих атрибутов (интерфейсов) в МЭК 62714 не рассматриваются. Выполнение задач автоматизированного проектирования осуществляется за счет совместного использования понятий AutomationML Group и AutomationML Facet.

А.2.3.2 Пример

Рисунок А.14 разъясняет понятие фасета AutomationML Facet на конкретном примере. Объект «Конвейер!» включает атрибуты «А» и «В», а также интерфейсы «X» и «V». Назначенный объект фасета «PLCFacet» ссылается

Instance Hierarchy — Иерархия экземпляров: Name — Имя: InternalElemenl — внутренний элемент: 10 — Идентификатор: Atabule — Атрибут. Extemallnterface — Внешний интерфейс: Role Requirements — Требования роли. RefBaseRoleCtassPalh — Ссылочный путь доступа к баэовому ролевому классу: RoieRequirements — Требования роли: FacetExample — Пример фасета. Conveyor t — Конвейер 1: Atlnbute А — Атрибут A; Interface X — Интерфейс X: PLCFacel — Фасет программируемого логического PLC контроллера. HMIFacet — Фасет человеко-машинного интерфейсе HMI

Рисунок А.14 — Пример фасета AutomationML

45

ПНСТ 177—2016

4nstencehfererchy Nene=*FacetExampte*>

«Wemefiement Name**Coftveyor1“ iD*^MGUDr>

«Attribute NefTie»“A"t»

«Attribute

<6 xternaflnt efface Name«“X"/v «ExternaBnlerface Name»"Y*fr «intemaElemert Name-"PLCfac6r KX'GUDr*

«Attrfeute Name*"A‘>

«ExternaRnterface Name=^,'X'7>

«RoleRequrrements Ref9aseRoteCtec£p«h**AutomationMLBeseRoteC)assUW.. jFaceO «AtternelSemerit>

«InternaElemert Мзтс-'ШГасеГ 0-"GUC*3“>

«Attribute N*iie-“A"fr «Attribute Name-’***

<£xterneKnterface Neme-'Y'A»

«RoleRequrementa Ref OascRoteCtess Path-’AiiomattonMLBaseRoteCtessLiW.. JFaceT^ «4ntemalSeinent>

«RcteRequiremente RefBaeeRoleOasgfWH"AUc»TiqHonMLDttoeRoteQaaoLi>/..jResoijrce'A* «itrteroalBeinent»

«Лг stance hierarchy»

Рисунок A.15— Пример огмеания фасета AutomationML на языке XML

на атрибут «А» и интерфейс «X». При этом назначенный объект фасета «HMIFacei» ссыпается на атрибуты «А» и «В» и интерфейс «У». Поэтому оба фасета обеспечивают фильтрованное представление для имеющейся инженерной информации, необходимой для выполнения задач автоматизированного проектирования.

Пример применения: атрибут «А» может быть «ориентированным-на-продавца» именем специального шаблона кода программируемого логического PLC контроллера, описывающего функциональные возможности объекта «Конвейер!». Интерфейс «X» может быть именем входного сигнала, используемого данным шаблоном кода. Атрибут «В» может быть именем специального шаблона человеко-машинного интерфейса HMI конвейера. Интерфейс «У» может быть сигналом, представляемым данным человеко-машинным интерфейсом HMi. С учетом данной информации, рассматриваемый программируемый логический контроллер PLC {человеко-машинный интерфейс HMIJспособен генерировать инженерные решения автоматически. См. примере разделе А.2.4.4.

А.2.4 Понятие группы AutomationML Group

А.2.4.1 Описание понятия

Понятие группы AutomationML Group позволяет отделить информацию о структуре от информации об экземпляре. Так как различные инженерные средства (на неоднородном множестве инструментальных средств инженерии) могут использовать различные представления на одни и те же данные, может оказаться полезным хранить данные представления раздельно. Это достигается за счет использования понятия AutomationML Group. Структурирование идентичных объектов возможно в различных иерархиях.

Путем определения атрибута группы «AssociatedFacet» (ассоциированный фасет), данная группа может быть ассоциирована с типом фасетов, характеризуемых уникальным именем. Это позволяет внешним инженерным алгоритмам автоматически идентифицировать рассматриваемые объекты (и их соответствующие фасеты), чтобы получить требуемую инженерную информацию. Кроме того, язык AutomationML определяет ролевой класс AutomationML RoleClass «Group» (см. раздел 6.4.3). Нормативные положения приведены в разделе 6.4.

А.2.4.2 Пример

Рисунок А. 16а) описывает понятие группы с помощью структуры «Station (Станция)», содержащей объекты «Конвейер!». «Конвейер2». «Robotl» и «PLC1». Объекты «Group!» и «6гоир2» описывают одинаковые данные в различных иерархиях. Объект «Group*!» определяет структурное представление тогъко для конвейеров. Объект «Group2» отображает только объекты, относящиеся к программируемому логическому контроллеру PLC. В соответствии с МЭК 62424 (раздел А.2.14), формат САЕХ обеспечивает хранение таких пересекающихся структур. Рисунок А.16Ь) содержит интерпретацию данного примера на языке AutomationML. Рисунок А.17 содержит соответствующее описание на языке XML.

А.2.4,3 Комбинация понятия группы и понятия фасета

Рисунок А. 18 содержит пример возможной комбинации понятия группы и понятия фасета. Показанная иерархия экземпляров InslanceHierarchy отображает объект языка AutomationML «Station», включающий объекты AutomationML «Конвейер!» и «Конвейер2». Указанные конвейеры имеют два атрибута и два интерфейса каждый.

46

ПНСТ 177—2016

• ln«Unt<№<iatfc/

a «пмСКиСЫмки

М Н«<гав1»т*1П

5 ft-fcr

■ г ou^tt

• НайОамМ<< .в iwm

a »

t с*■•>»*««

t Са-лФугжЗ 9 RwMI 4 И.С1

MHiMSMrtwnt

• ■But»**’

>» *JK00 _

a Иа n4(kiiw.a C*;

S IbMM t Ca’HVtV'

_ 2 C04«vti>J

«ГМИМгМмимв

s iw>m«wMro*>tfai>AJan«a диашж(»гя1а>М14яи«1»>1Ри»нав«Я1»р

*■ InmiMdaniairi

В lm i*0U»2

«S' ouoooo

• Иапмммк

's llm

• aei лх»

a Bt4e>ei|Hr »ra<

в н*п»»>и»ид w«r>«n л-юп»»ч>циеч»»о»мсь'.маиааг*И)1«к«К1гос

a) Hierarchy b) Grid view

a) Hierarchy — а) Иерархия, b) Grid v>ew — Ь) Сетевое представление, Ж — Иерархия экземпляров. GroupExample — Пример группы; IE — Внутренний элемент, Station — Станция: Conveyor 1 — Конвейер; PLC1 — Программируемый логический контроллер 1

Рисунок А. 16 — Пример группы AutomationML Group

«trctanceHerarchy лапе=’Огод£лв*е1в^,> <«crr>dEcncrrtNefTc-^,,SSetion' C^'OtJDlOO’'

nreeinaeemert Njne*'Conveyorr D»’GUOr> drtemaEemerl №ne«'^,Ccrtveya(^,T O«*0UB2*b •MemeCemcrt hbn>e-"RcboM‘ D-"OUDOV.»

etrrearwIEIewMTb

•iMcrr>«Ctncr<NorTc^04>1" D-'^UOMO** i <trtetneEemen(№ne«Xcnveyorl''Rei8aseSvst«MJMi^:>e№K‘G1Xn‘A j dntemeeement MM^es^ConveyorT* Rotea*eSyett««LMP*№(s^XK>(3'fr

i «ftofcfteqrteneiu RereeseRctectsssPatria'AuloncilcnMieesenoieCittsLiMKUomilorMLOeeeltaeOroup'A» <lrte nettle nen>

<ltornd&orientN«rTe>^>,Or»4>2^M D-'OtJlOGCO'* j «rtemaCemer* hBrwx-PLCr tefftaseSysjeninrPsma'GUO**/»

j 4toHfoqjirenent$ Ref8mRc(eO*s$M^Aijlan«lknMl8bssfloleClassLb0UioraflorMieaseltoeXtaM0'A

<Wto<noi6loTien>

«fnsuncerierarcry»

Рисунок A. 17 — Пример описания группы AutomationML Group на языке XML

Объект языка AutomationML «Group» представляет собой встроенные группы «Groupl» и «Group2*. Обе группы ссылаются на объекты конвейера, но имеют различные ассоциации фасетов.

Пример применения: Алгоритм генерации кода управления может пройти по иерархии экземпляров InstanceHierarchy и идентифицировать все группы, ассоциированные с фасетом «PLCFaceU. а затем сгенерировать код для оценки ссылочных объектов.

Рисунок А. 19 содержит описание на языке XML. соответствующее примеру, приведенному на рисунке А.18.

А.2.4.4 Автоматическая генерация человеко-машинного интерфейса HMI с помощью понятия группы и понятия фасета

В данной! примере принято, что атрибут «В» конвейера представляет собой шаблон интерфейса HMI. визуализирующий переменную «Y». Рисунок А.20 иллюстрирует характерный шаблон интерфейса HMI конвейера.

47

ПНСТ 177—2016

instance Hierarchy

-г

Station

■*j Conveyorl

♦ Attrtiute A

♦ Attribute В

♦ interface X

interface Y

♦ PLCFacet

interface Y

H Conveyor?

♦I Attribute A

•* Attribute В

*\ interface X

+\ interface Y

PLCFacet

В

Attribute A

Interface X

HMIFacet

В

Attribute В

interface Y

-H Group"

Assoc tatedFacet = .HMiFacer

Conveyorl

Conveyor2

InstanceHierarchy — Иерархия экземпляров: Station —• Станция: Conveyorl — Конвейер 1: Attribute A — Атрибут A: Interlace X — Интерфейс X. PLCFacet — Фасег про!раммируемого логического хонтроллера. HMFacet — Фасет человеко-машинного интерфейса; Group — Группа; AasocialedFacet — Ассоциированный фасет

Рисунок А.1 В — Комбинация понятия группы и понятия фасета

46

Рисунок А.20 — Характерный шаблон В для интерфейса HMI. визуализирующий переменную «Y*

технологического процесса конвейера

&

(О

о>

ПНСТ 177—2016

Основанный на конкретном экземпляре конвейера, рассматриваемый инженерный алгоритм идентифицирует. что объект языка AutomationML «Group2» ассоциирован с фасетом человеко-машинного интерфейса HMI. Здесь он идентифицирует, что экземпляры «Коквейер1» и «Конвейер2» являются частью интерфейса HMI. Данный алгоритм может извлекать информацию из интерфейса HMI о каждом из двух конвейеров. № может идентифицировать соответствующий шаблон интерфейса HMI. может ассоциировать корректные сигналы для последующей их визуализации. Рисунок А.21 представляет результирующий человеко-машинный интерфейс HMI.

HMI result

Conveyort.Y

Conveyor2.Y

□

□

Рисунок А.21 — Сгенерированный результирующий интерфейс HMI «В*, визуализирующий оба конвейера с индивидуальными переменными технологического процесса

А.2.5 Понятие набора свойств PropertySet

А.2.5.1 Описание понятия

Набор свойств PropertySet применяется как таксономия (структурированный словарь) атрибутов. Он моделируется как ролевой класс, содержащий предварительно определенные атрибуты, описывающие свойства рассматриваемой области применения и получен из стандартного ролевых классов «PropertySet» (см. раздел 6.4.13). Данный набор включает список синтаксически и семантически согласованных атрибутов. Наборы свойств собраны в библиотеки ролевых классов.

Объекты AutomationML могут быть ассоциированы с одним или несколькими наборами свойств. Для каждого набора свойств создается отдельный дочерний объект типа САЕХ IntemalElements. который назначается соответствующему классу PropertySet с помощью определений требования роли RoteRequirement. Несколько наборов свойств могут быть ассоциированы с помощью нескольких дочерних внутренних элементов IntemalElements соответствующего объекта AutomationML.

Объект отображения САЕХ обеспечивает отображение собственных атрибутов объекта AutomationML с пред-варигвгъно семантически определенными атрибутами набора свойств PropertySet. Это обеспечивает возможность импортеру программного обеспечения автоматически интерпретировать указанные атрибуты и отображать их на целевые специальные атрибуты инструментальных средств. Данная процедура упрощает автоматический обмен данных между различными инструментами.

Также существуют предварительно определенные библиотеки наборов свойств AutomationML. Нормативные положения приведены в разделе 6.5.

А.2.5.2 Пример

В качестве примера (на языке AutomationML) рассматривается процедура передачи схемы пинии сборки, содержащей станции сборки (см. рисунок А.22). Станция сборки оостоит их трех площадок. Одна — для транспортировки материала, вторая —для хранения материала, третья —для непосредственной сборки (см. ниже). Средства инженерии источника определяют данные площадки с помощью пользовательских атрибутов, назначенных объекту и представляющих рассматриваемую станцию.

Drtving lane — Полоса движения. Material zone — Зона хранения материала: Assembly area — Сборочная площадка Рисунок А.22 — Пример набора свойств PropertySet

50

ПНСТ 177—2016

Рисунок А.23 иллюстрирует соответствующую модель AutomationML. В левой части рисунка показана иерархия экземпляре», необходимая для моделирования трех площадок Станции 1. Каждая площадка имеет свой пользовательский набор атрибутов и ссылку на набор свойств PropertySet «Area». Соответствующее описание на языке XML приведено на рисунке А.24.

В правой части рисунка А.23 приведена библиотека набора свойств AutomationML PropertySet. Данная библиотека ролевых классов AutomationML RoleClass содержит класс RoleClass «GeometricOata» (геометрические данные), полученный из базового ролевых классов Base-RoteClass «PropertySet». Ролевой класс RoleClass «GeomethcData» сам имеет дополнительные производные, определяющие некоторые базовые геометрические свойства. Класс RoteCtass с именем «Агеа» (площадка) определяет атрибуты «Length» (длина) и «Width» (ширина) как атрибуты типа «double» (двойной) и единицу измерения «т» (метр). На рисунке А.25 приведено описание на языке XML. определяющее рассматриваемые атрибуты набора свойств PropertySet.

С помощью набора свойств PropertySets экспортирующий инструмент мажет сохранять пользовательские объекты с пользовательскими атрибутами и объяснять семантику пользовательских атрибутов с помощью процедуры отображения. Данное утверждение поддерживает автоматическую интерпретацию рассматриваемых атрибутов. Таким образом, целевой инженерный инструмент может интерпретировать данные и выполнять преобразование единиц измерения, используемых атрибутами набора свойств PropertySet.

Instance hierarchy

1_Ьжпр«е InTterceMerwchr

-ьшчЮмнМн

user defined Mtrbutes of Station 1

mattrialarea.length materiatarea. width transportarea. width transpooareajengih asseniply#(e*.vvicth4 ossemblyarca.krgtM

! ROM: Mtn

lAHontttyrea >Um | WMppinqObfrct

^~l AtrbutrNameMapping- паеп-ь^егаимвн 1*»rr Wywee.lmgih [Макг'Щаы (Cfaau RolwAo«)

1 MappnqOMw

”П ACributeNemeMaFpnf: meteaalarMjsrTgtt

I AtrbuitN«neM«fphr mateaalfttjaidh

1 Т-агзрсТатте :dw« ЯеккД***}

[UepongObjict

I AcrbgteHeneM*ppfof.l»*r*poftere*_wWth

I ДСПы«МяпаЫфр*ф wnportarwJvgtT

Mapping between user defined aertoute and standard attrbuce

PropertySet role library

UampleRoIcCtossliD

GeomrtkDat* | Claes; PropertySet) length (ClautGeometricData)

Point (Class: GeometrkDatal AnQie (Cle«:i5eome*lcDa*a) Deformatior ! Class; Geonw ixoata}

2 Strain (CUia: Deformation}

3 Detection (Class; Deformation^

Area (CliMtGcometricData)

ialDknenslon (CbseGeametricData)

Standardized attributes of the PropertySet 'area*

—►Length

b- Width

User defined allnbules of Station 1 — Пользовательские атрибуты станции t; malenalarea_length — Длина плошадки хранения материала. malenalarea_wtd№ — Ширина плошадки хранения материала. transportarea_width — Ширина плошадки транспортировки: transportarea Jenglh — Длина плошадки транспортировки: as*emblyarea_ width — Ширина сборной площадки: assembfyarea_ length — Длина сборной площадки: Inslanca hierarchy — Иерархия экземпляров. PropertySet role library — Библиотека ролей набора свойств PropertySet: Mapping between user defined attribute and standard attribule — Отображения между пользе-■ательскиыи атрибутами и стандартными атрибутами: Standardized allnbules of the PropertySel «Area» — Стандартные атрибуты набора данных PropoilySel «Area». Lenglh — Длина. Width — Ширина: Example InstanceHierarchy — Пример иерархии экземпляров. AssembtyLine {Class: Role) — Линия сборки (класс: роль): Stabon 1(Class Role) — Станция 1 (класс: роль:): Assemblyarea {Class: Role: Атеа) — Площадка сборки (класс роль: площадка): MappingObtecI — Объект отображения. Altnbu(eNameMapping: assembtyarea.width — Отображение иыеии атрибута ширина сборной площадки: Malerialarea (Class: Role. Area) — площадка хранения материала (класс, роль: площадка): Transportarea (Class: Role. Area) — Площадка транспортировки (класс: роль: площадка): ExampleRoleCtaasLib — Пример библиотеки ролевых классов. GeomatricOala (Class: ProperlySel) — Геометрические данные (класс: набор свойств): Lenglh (Class: GeomelricOata) — Длина (класс: геометрические данные): Point — Точка: Angie •— Угол. Deformation — Деформация. Strain — Напряжение: Detection — Отклонение: Area — Площадь. SpabalOintension — Пространственный размер: Role— Роль

Рисунок А.23 — Пример набора свойств PropertySet

51

ПНСТ 177—2016

<ln»tenc«Hi*rercfiy NamtB'Exarnpl* inetaflceHtBrarchy*»

«intematElement Name^AssemUyUne’ iD=*{8b2$l0t>4-7te5-4f54-9009*3l9ra062604}">

«'rrtemaiEI errant Nar-e="Stebor1' 1О'($4500138-с6а1-47<&-80с9-ЬевЗ$662563с}'>

«Attribute Name='matertalarea_length'»

«Attribute Name=*matertalarea_wktth*/>

«Attribute Namc=tranipc»t*rea_>vWth' t>

«Attribute J4»mo-*tran* porta гм Jen gth" AtW>uteD*taT>p*="x*:doublB’'/>

«Attribute Name=*asserritxysrea_v»ictrr AttnbutelMte' >pe^s"xs:oouble" о «Attribute Kamc^s*aMembtyaree_leogtt' Attn:xiteDateT/pe^s*>s:(louble' >

«intemaiEiemert Name^Assembiyarea’ К>**{вОв»Зе5-еЬОМ5с8-М2М714в24«ИОбс}*>

«RoleRequirerrenta RetBisoRoicClassPBtbg*ExmipleRoleClMsLib/Oeom«McPBte>Ar»B' /> <MapplngObject>

«AttnbuttNameMappmj S/stemUmtAttrtoutetr«nie>'e»MmblyarM_v40№' RoleAttrbuteNeme“’WWth' f> «AttnbuteNameMappnj System0ntAttrtrut9Name=*assembtyarM~l«ngth' RoteAtiibuteName=“Langth^- f> «.’WoppingCbjeet*-</№ternaiEiement>

«intemeiEiemert Nane-'Metenafaree” 1О'{66в360аМ10МЬ60-Ь»&3-44Ь262Ьс470еГ»

«RoleRequrerrents RefB»eRo<eCiassPen=^,,Exampf«ftoteCtassUb/Geom*trlcDeta'Area‘ > <MappingObj*ct>

«AttributeNameMapping Syst*mUr»tAttrt>utBN«me='materieiareeJanQlh* RoleAttributeNamesTenoth* t> <AttnbutBNameMapp<ng 3y3t*mUprtAttrtoutaName-'matariaiBrM_v«Wth' RoteAitnbuteName^’Wicflh* t> «.WapplngGbjeel»

</Ki5e'naiEJerrtent>

«IntemaJElemant SJame=Transportarae‘ iD^s‘'{1941896?<d7c-46«B-ad*a-eiaaS2l^l6b68S}^,,>

«RoleRequIremenb RefB»efto(eCia*»Pat^>i»’ExampteRoleCtftssLib/GeometitcDaiBrArea‘ !> «MappingObject»

«AttributeNameMapping SystbmUratAUrtoutirName-lrwisportarMjwfctttr RdeAtt-lbuteNaine-’YVWttr/» «AttrtbutaNameMapping S/st*mUr>tAttrtout»Name=transportarea_lei>gth“ RoteAftrtt>i/toNam«=T.ength“ f> «.Mapping CC(ecl>

</lnternaiBem»nt>

«/IntemalElement»

</lntama)Sement>

«'instance rterarcfry>

Рисунок A.24 — Описание на языке XML иерархии экземпляров

А.2.6 Понятие «Процесс-Продукт-Ресурс»

А.2.6.1 Описание понятия

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

• Ресурсы — это центральный компонент рассматриваемой модели. Они обеспечивают производство и обработку продукта. В языке AutomationML ресурс — эго сущность, используемая для производства, включая установки. роботов, станки, их состояние, оборудование, возможные сообщения и т. д. Ресурсы могут быть как аппаратными компонентами производственной системы, так и программным обеспечением данной системы (например, система SCAOA). В языке AutomationML ресурсы обычно моделируются в иерархии производственной установки, образуя ее топологию.

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

• Технологический процесс также является центральным элементом модели. Процесс на языке AutomationML представляет собой производственный процесс, включающий несколько подпроцессов. Параметры процесса, технологические цепочки, планирование процесса — неотъемлемые его части. Процессы модифицируют продукты. Язык AutomationML отражает получение конечного продукта из различных подпродуктов, отражает изменение веществ путем их химической обработки. Процессы связаны с ресурсами и наоборот.

В каждом случае, представления ресурсов, продуктов и процессов связаны друг с другом (см. рисунок А.26). Корректным назначением для процесса «transport» является ресурс «conveyor» (конвейер). Ресурс «press» (прессование) обеспечивает «scrap cubes» (спрессованные отходы). Процесс «weeding» (сварка) обеспечивает «wekJ» (сварку) двух «metal» (металлических заготовок).

52

ПНСТ 177—2016

«RoleClass Name-"GeometricData*

RefBaseClassPath-'AutomationMI BascRoIcClasslib/AuromationMI Base Role/Pro perry Sm

- «RoleClass Name-'l.ength”

RefBnseClossPoth-TxamplcRolcClasslib/GcofnctricData’>

«Attribute Name-TengthValue' Attrih u;eDataType-"xs:doubIe'

Unite'm" />

</RoleClass>

- «RoleClass Names 'Point'

Ref&aseClassPath=£xampleRoleCtassLib/GeometricData'>

«Attribute Name- xAxis¹ AttnbuteDataType»*xs:double" />

«Attribute Name- VAxis AttributeDataType="xs:double’ />

«Attribute Name= zAxis'' AttributeDetaType=''xs:double' />

</RoleClass>

- «RoleClass Name«'Angle'

RefBaseclassPath=txampleRoleclassLib/GeometricData’>

«Attribute Name-'angleVaiue ' AttributeDataType-’ xsrdouble*

Unlt='rad" />

</RoleClass>

- «RoleClass Name- Deformation''

Ref&aseClassPdUi=‘ExdmpleRoleCldssLib/GeometricData'>

«Description Deformation of the material is the change in geometry when stress is applied (in the form of force loading, gravitational field, acceleration, thermal expansion, etc.). Deformation is expressed by the displacement field of the matcrial</Description>

«Attribute Name- ’deformationValuc' AttrlbuteDataType-"xs:doubte" />

- «RoleClass Narne=‘Strain"

RefBaseCjdssPdth="ExanipleRoleClabsUb/GeometricDald/Deformation"> <Description>Strain is the deformation per unit length</Descnption>

</RoleClass>

«RoleClass Name-’Defleaioir

AefBaseClassPath^-FxampleRolcfJassI ih/GcomcrricData/Dcformarion*> <Descrlptlon>Deflectk>n is a term to describe the magnitude to which a structural element bends under a load «/Description>

</RoleClass>

</RoleClass>

- «RoleClass Name="Area^v

RefBaseClassPath- "ExampleRoleClassLib/GeometricData*>

«Attribute Name^Length" AttributeDataIype^'xsrdouble" unlt=’m*/>

«Attribute Name= 'Width" AttributeDataType=*xs:double Unit=*m' />

</RoleClas$>

- «RoleClass Name» SpatialDimcnston"

RefBaseClassPoth=txamplcRolcClassLib/GeometricData'>

«Attribute Name® "XAxis" AttrtbuteDataType® "xs:double'' Unit=^l'm'' />

«Attribute Name- 'VAxis* AttributeDataType- xs:double' Unit- 'm" />

«Attribute Name=*ZAxts‘ AttnbuteDataType=*xs:double" Unit="m’ />

</RoleClass>

«/RoleClass >

Рисунок A.25 — Пример библиотеки AutomationML PropertySet в кодах на языке XML

Для создания связей между указанными элементами требуется наличие интерфейса. Для этого язык Automaton ML определяет стандартный класс интерфейсов PPRConnector (см. рисунок А.27). Нормативные положения в части коннектора PPRCoooector рассмотрены а разделе 6.3.5. С помощью денного интерфейса могут быть установлены связи между элементами с помощью стандартных внутренних связей САЕХ IntemalUnks (см. раздел 5.6.6). Таким образом, ресурсы могут быть связаны с продуктами, которыми можно манипулировать.

А.2.6.2 Пример

Следующий пример (см. рисунок А.28) иллюстрирует использование данного понятия в языке AutomationML. Оно включает два конвейера (С1 и С2), поворотную платформу (ТТ1) и робота (RB1). Это ресурсы производственной установки. Робот устанавливает колеса на автомобиль. Колеса и автомобиль — продух гы. Производственные процессы в рамках рассматриваемо примера: транспортирование, поворот платформы, сборка.

53

ПНСТ 177—2016

Product components (car bodies, motors, drives, chassis)

Interface Link Process Resource

PRODUCT

Product (^) Process direction

PPRConnector

PPRConnector

//

# '“«x

W 4

д** Process executes in resource_V

•| [PPRConnector

PROCESS

Production process (assembly, welding, measurement, pouring)

Resource (plant, cell, worker, machine, robot)

Interface — Интерфейс: Link — Связующее заено: Process — Процесс: Resource — Ресурс: Product — Продукт: Process direction — Направление процесса: Product components (car bodies, motors, drives, chassis) — Компоненты продукта (автомобиля): куме, двигатель, привод, шасси. PPRConnector — Коннектор PPRConnector: Process to produce product — Процесс дпн производства продукта: Product is produced on resource — Продукт производится с помощью ресурса: Transport — Транспорт. Production process (assembly, welding, measurement, pouring) — Производственный процесс (сборка, сварка, измерение, запивка): Resource (planL сей. worker, machine, robot) — Ресурс (промышленная устаноеха. производственная ячейка, рабочий, станок, робот)

Рисунок А.26 — Базовые элементы понятия «Продукт—Процесс—Ресурс»

м AuUxnatoorrtlinterfdteUds&ijb

Ь ~о Aurryr,-tmMi i.xrfKfrfrifр {Class:}

Order { Class: AutomationMLBaselnterface} PortConnector {Class:AutomationMLBaselnterface} -£jnteMockjng£ofmeao^^|ass^uior^^

AutomabonMLInterfaceCtassLib — библиотека класса интерфейсов: AutomationMLBaselnterface (class:) — Базовый интерфейс (класс:); Order — Порядок: PortConnector — Коннектор порта. IntorlockingConnector — Взаимосвязанные коннекторы; PPRConnector — Коннектор PPRConnector

Рисунок А.27 — Интерфейс коннектора PPRConnector

На языке AutomationML понятие «Процесс—Продукт—Ресурс» моделируется с помощью понятия ролиСАЕХ (см. МЭК 62424 (раздел А.2.9)) и соотношений между элементами (см. раздел 5.6.6). Наборы элементов с назначенными ролями «Ресурс». «Продукт» или «Процесс» разбиваются на пары. Это означает, что ресурс не может быть и продуктом, и процессом одновременно. Соответствующие классы ролей являются частью библиотеки базового ролевых классов AutomabonMLBaseRoteClassLib (см. рисунок А.29 и раздел 6.4).

54

ПНСТ 177—2016

Product dr»n — Выпуск продукта. Product source — Источник продукта: Process — Процесс, Resource» Ресурс: Product» Продукт: Process direction — Направление процесса: Oran — Выпуск: Transport — Транспортирование: Assemble — Сборка. Тит — Поворот платформы

Рисунок А.28 — Пример понятия «Продукт—Процесс—Ресурс»

AutomationMlBaseRdeClasslib AutonvmonMiBaseRote * Group Facet

£3 ^Port

-о ConnectionPomi

Rpsoune Product Рггк pst

Structure

•ok ProductStructure »2 ProcessStructure *3 ResourcoStructure PropertySct

AutomationMlBaseRoleClassLib—- Библиотека базового ролевых классов. AulomalionMLBascRole — Базовая pone. Group — Группа: facet-— Фасет: Port —■ Порт: Rote Lib Библиотека ролей: Role — Рол*.ConnectiooPont — Точка соединения. Reeouice — Ресурс: Product — Продукт: Process — Процесс: Structure — Структура: PropedySet — Набор свойств

Рисунок А.29 — Pom AutomationML. необходимые для понятия «Процесс—Продукт—Ресурс»

В рассматриваемом примере (ом. рисунок А~28) роль «№сурс» назначена конвейеру, роботу и поворотной платформе. Автомобилям и колесам назначена роль «Продукт». Роль «Процесс» соответствует процеосам транспортировки, поворота платформы и сборки. Все элементы хранятся на соответствующем поддереве (см. рисунок А.30). Порздок применения процессов, продуктов и ресурсов явно выражается связующими элементами, установленными между соответствующими интерфейсами типа «Order» (это не показано на рисунке, чтобы его не загромождать).

Каждый элемент (в рассматриваемом примере) имеет интерфейс коннектора PPRConnector. Полные представления связующих элементов представлены на рисунке А.31. Непрерывные линии — это связи ресурсов с процессами. Точечные линии — это связи процессов с продуктами. Штриховые линии — эго связи ресурсе» с продуктами. Схема представляется достаточно сложной, поэтому (для простоты) избыточные связи опущены.

55

ПНСТ 177—2016

Resource — Ресурс. Process — Процесс: Product — Продукт. Transport): Process — Транспортирование 1: процесс. Car with wheels): Product — Автомобиле с колесами 1 продукт. Tivnt: Process — Поворот платформы 1: процесс: Car without wheels): Product — Автомобиль без колес 1: продукт, Wheatst: Product — Колеса 1: продукт. Assemble): Process — Сборка 1: процесс

Рисунок A.3Q — Элементы рассматриваемого примера

Transport): Process — Транспорт 1: процесс: Cl: Resource — С). ресурс: Tumi; Process — Поворот платформы 1: процесс: Car wrthoul wheels): Product — Автомобиль без колес 1. продукт: Assemble!: Process — Сборка ): процесс: Wheels): Product — Копеса I. продукт: Свт with wheelst: Product — Автомобиль с колесами 1: продукт. PPRConneclor — Коннектор: InlernalLinfcs •— Внутренняя связь

Рисунок А.31 — Связи, рассматриваемые в примере 56

ПНСТ 177—2016

На рисунке А.32 данный пример рассмотрен с точки зрения ресурса. Поэтому нужны только 12 связей из их общего количества, равного 19. Конвейер «С1» соединен с продуктом «Саг without wheels 1» (автомобиль без колес1) (см. таюке поворотную платформу «ТТ1» и конвейер «С2»}. Также как робот устанавливает колеса на автомобиле на конвейере «С2». робот «RB1» соединен с продуктами «Саг without wheelsl» (автомобиль безколес1). «Саг with wheetsl» (автомобиль с колесами 1} и «Wheelsl» (колвса1). Дополнительно конвейер «С2» связан с продуктом «Саг with wheelsl» (автомобиль с колесами1). Процесс транспортировки «Transport!» связан с конвейером «С1». Процессы транспортировки «Transport2» и «Transport3» связаны с конвейером «С2». Процесс «Assemble 1» связан с роботом «RB1». Процесс «Тит1» связан с поворотной платформой «ТТ1». Связи продуктов с процессами (точечные линии на рисунке А.31) могут быть получены из других существующих связей. Данную блок-схему можно произвольно поворачивать, продукты и процессы блок-схемы можно произвольно перемещать.

На рисунке А,33 приведено древо рассматриваемого объекта AutomationML. Внутренняя связь tntemalUnk между конвейером «С1» и процессом «Transport!» вынесена отдельно.

Соответствующая модель на языке XML приведена на рисунке А.34. На первом уровне примера приведены три базовых элемента («Ресурсы». «Процессы». «Продукты»), моделируемые как внутренние элементы в формате САЕХ InternalElements.

Ниже объекта «Resource» расположены четыре компонента: два конвейера, поворотная платформа и робот. Они также имеют тип «InternaJEtements* (внутренний элемент). Данные компоненты имеют наружный интерфейс

| Process (Р1) |

CTProduct (P2TZ>

PPRConnector

- IntemalLink (RP1)

*--IntemalLink (RP2)

—— IntemalLink (P1P2)

N

\

у»

Car with wheels!: Product

Transport!: Process — Транспорт l: процесс: C1; Resource — Cl: ресурс: Tumi. Process — Поворот платформы I: процесс; Car without wheels): Product — Автомобиле без колес 1. продукт: Assemble!' Process — Сборка !: процесс: Wheels!: Product — Колеса 1. продукт: Car with wheels): Product — Автомобиль с колесами !: продукт; PPRConnector — Коннектор PPRConnector; Internal).inks — Внутренняя связь

Рисунок А.32 — Рассмотрение примера с точки зрения ресурса

57

ПНСТ 177—2016

Г1ншр1е_|палпсеНг1ЛсЬу

Example_Pbnt (Class: Rolc:Cdl) Resources (Clast: Rote: Resowce)

Cl (Class: Role: Resource)

PPR (Class* PPRConnector} ••• 9 3E ^m (Class: Role: Resource)

PPR (Class*PPRConnector) эЗЕ RBI { Class: Rote: Resource)

■Ю PPR { Class: PPRConnectof)

Э jg] C2 (Class: Rote: Resource)

•g PPR (Class* PPRConnector)

В ПГ Processes (Class: Role*Process)

В I IE I Transportl (Class: Rote: Process) *G PPR (Class:PPRConnector)••• В JJJ Tumi (Class: Role: Process)

«О PPR (Class:PPRConnector) bJE Tran»port2 (Class: Rote:Process) -o PPR (Class*PPRConnector)

Я E Assemblel (Class: RolciProcess) <-0 PPR (Class*PPRConnector)

3 : IE I Transport3 (Class: Rote: Process)

*G PPR (Class:PPRConnector)

3 [|E Products (Class: Rote:Product)

Я .IEI Car witlioulwheelsl (Class: Rote:Product) ~o PPR (Class*PPRConnector)

3 | IE | Wheetel (Class: Role: Product)

-o PPR (Class*PPRConnector) id ПГТТаг with wheelsl { Class; Role: Product)*

-э PPR { Class: PPR'onne.rtrr)

Example_lnsisnceHierarchy — Иерархия экземпляров e примере; Exampte_Ptant (Class: Role: Cell) — Пример производственной установки (класс: рол»: производственная ячейка). IH — Иерархия экэемппярое. IE — Внутренний элемент. InlemalLmk — Внутренняя связь

Рисунок А.ЗЗ — Пример построения иерархии экземпляров InstanceHierarchy на языке AutomationML

(коннектор) Externallnterface PPRConnector. Они назначают ролевой класс «Resource». Процессы и продукты имеют интерфейс, их роли распределены. Для организации связей между элементами, объекты InternalLinks обычно располагают на одном уровне как самые главные базовые элементы. Рассматриваемые связи показаны на языке XML на рисунке А.35.

Полный обзор понятий в рамках рассматриваемого примера приведен на рисунке А.36.

А.2.7 Поддержка сразу нескольких ролей

В добавление к МЭК 62424:2008 (раздел А.2.9) язык AutomationML обеспечивает возможность поддержки срезу нескольких ролей для экземпляра одного объекта. Рассмотрение сразу нескольких ролей имеет смысл, если данный объект имеет несколько функциональных возможностей.

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

Рисунок А.37 содержит пример, е котором объект «MultiDevtceOI» имеет три атрибута «Fax-BoudRate». «PrintSpeed (скорость печати)». «FaxSpeed» (скорость передачи сообщения) и два интерфейса «PowerSupply» (питание) и «USB» (USB-интерфейс)». Объект «MiitiDevweOI» поддерживает три роли «Printer» (принтер). «Fax» (факс), «Scanner» (сканер). Роль со ссылочным тэгом «RefBaseRoleClassPath» (ссылочный путь доступа к базовому ролевому классу) для соответствующего элемента требований Role Requirement является базовой.

На рисунке А.38 приведен соответствующий код на языке.

Атрибуты и интерфейсы, принадлежащие объекту «MultiDevtceOI», должны отображаться на атрибуты и интерфейсы всех трех ассоциированных ролей. Это производится с помощью объекта отображения САЕХ

58

ПНСТ 177—2016

hiternafftement

= llame ExamfKe.Plant S ID GUD1 Inter naElement (3)

' s llame s Ю 1 Resources GUD2

2 Processes GUID7

3 Products 0UO13

О InttinilElemeiS

M InteinalElement (4)

«I InteinalElement (5)

InteinalElement

C3)

InlernaElemenl — Внутренний элемент: Name — Имя: 10 — Идентификатор: Example_Planl — Производственная установка примера

Рисунок А.34 — Пример формирования внутренних элементов IntemalElements

* Intel nafc_infc (12)

: Наше

1 С1_Т1

2 TT1_Tu1

3 RB1.A1

4 С2_Т2

5 С2.ТЗ

( C1_0*W1 7 ТТ1 _CWW1 < RBI.OeWI 9 R&1_W1 . It RB1_CW1

I 11 C2_CwW1

J 12 C2_CWI

= RefPartneiSkteA CUD3PPR GU04PPR CUDSPPR OUD6:PPR 0U06PPR <3UD3:PPR <3UD4:PPR GUDSPPR GUD5PPR GUDSPPR GUD6PPR OUDfcPPR

= RefPartneiSideB GUDG.PPR 0UD9PPR OUD11:PPR OUDIOPPR

OUD12PPR_

'0UD14:PPR

GUCH4PPR

GUW4PPR

GUD1S:PPR

GUD16.PPR_

OUD14:PPR

GUD16:PPR

Рисунок A.3S — Пример организации внутренних связей IntemalLinks

59

<£>

е

ь.

N.

О

X

ПНСТ 177—2016

MappingObject в соответствии с МЭК 62424 {раздел А2.10), который дает информацию об атрибуте роли (интерфейсе). о порядке ассоциации рассматриваемого экземпляра атрибута {интерфейса}. Чтобы различать атрибуты различных ролей (имеющих одинаковые имена}, имя роли включается в определение отображения (за исключением базовой роли, указанной в пути доступа «RefBaseRoieClassPalh»). Рисунок А.37 содержит пример описания необходимых атрибутов и интерфейсов, а также порядка их отображения на атрибуты и интерфейсы экземпляры.

Рисунок А.38 содержит представление рассматриваемой структуры на языке AutomationML.

Рисунки А.39 и А.40 содержат соответствующие библиотеки ролевых классов AutomationML и их представление на языке XML.

InstaoceHierarchy

s mmciiin^BiteieiSuppm

« Intemalftemcnt

= Name ^MutOeviceCt

= ip (GUD1

InterneKlemenl

= Name Pool : ID GUD2 A Attribute (3)

■ Nemo

1 FaxBotURate

2 PrtSpeed

3 SMnSpeed ExIernaBntorfaee (2) s Name 1 PswerSuppiy

2 U5B _

<| Supporre<tRoleOla«< (4)

= RetRoleClasaPatli

1 iteerdeflnedRoieQassiJb/Pnrter

2 У5ст4сПлс<ЗЯо1еС1а»иь*Тпд

3 LHerde fin edRoleCleaalrh/S farmer

Rolette quire monte

's RefBaseRoleClast Path *1 Attribute (3)

UsertefinedRol*CleailJbf№nter

= Name

1 Speed

2 Fax.$peed

3 Seornor.Spood

0 Value 20

S4

1

a MeppingOtyect

l

AttributeHameMapping (3)

s HoteAttnouteName : systemUiMAttnbuteName

1 Speed RrintSpeed

2 Fax Speee FaxBoudRae

3 Scarner.Speed ScanSpeed

штепасенате Mapping (1)

s RolelntertaceN«n# s Syt№rntlnltMerlM#Niime 1'Powtr FowwSupply

InstanceHierarchy — Иерархия экземпляров. SupporlodRoleCtass — Поддерживаемый ролевой класс: RefRoloCtassPath — Ссылочный путь лоступа к ролевому классу: UnderfinedRoieClassLi(KP>inler — Библиотека лольмаательското ролевых клас-соа/принтер. RoleRequirements — Требования к роли: RefBaseRoieClassPalh — Ссылочный путь доступа к баэоеому ролевому классу: MappmgObfecI — Объект отображения: AlInbuteNameMapping — Отображение имени атрибута. RoleAtlribuleName — Имя атрибута роли, InterfacaNameMappmg — Отображение имени интерфейса. RoloInterfaceName — Имя интерфейса роли. SyslemUmtlntertaceName — Имя интерфейса системной единицы: PowerSupply — Подача литания

Рисунок А.Э7 — Пример пользовательского экземпляра, поддерживающего несколько ролей

61

ПНСТ 177—2016

«tnetanceHierarchy Name»YmitipieRoiee$tipp<yr>

«Irtema&emenl Names'MJtlOeuceOr IDs-QUIDI"?

«IntomalElemont Nvm^DOOI* ID=*GUI02*»

«Attribute Name^*FaySoudRate*/>

«Attribute Name»*PrintSpeetf7>

«Attribute Narr4;-'ScanSpe«r/>

«Extarnailntertace Namee"PowerSuppty7>

«Externailnterface Marrve="LfSB*/>

«SupponeoRoeCase RefRotedaesP3irntj*er<leflnedRo»eClaesl.fb'Prlnt*r.'>

«SupporledRoieCess RefRo4eClsssP*ri*^,\J»erdefnedRc4eC least. ibFax'/>

«SupporteeRcteCasa Re«oieCia*sPaiti=4JierdeflnedRoiBCi!*sL»scs»rtrt«r*/>

«RoieRequuementa RefBeaeRcieClasaPatriOJeeidefiiTedRoieCleeabb/Printer'»

«Attribute Name=*SpeecT>

<Va(ue>20«/Vatue>

«/Attribute»

«Attribute Name=’Fax.Spee<r>

<Уа1иег*54<Л/81ие>

«/Attribute»

«Attribute Name*'Scanner.Speecr>

«Vatue>1</vaue>

«/Attribute»

«/RdeRequfements»

«MaxinoObioct»

«AitributeNameMapplng RoleAttrtxaeNamee'Spead* SvstemUnitAnributeNamas'PiintSpeed*/» «AttrtouteNemeMappinq RoteAmouteName^e*Fex.Speed" Sy3tetrUnttAttnbu:eWaroe*'FaxBoL<JRale7> «AttribuCe№«TwMapping RoteAn'toulaNtarrn*=*Scannt.Sp—tr SyriHm Uni tABritiuteNan>w=“ ScanS peerf'i'» «interfaoeNameMepptftg RcieWerlaceName-’Power" Sy»temUrutlntoiecoNamo^B*PowerSuppty/> «/MappingObjec^

«/intemeiEiement»

<itntemalElement>

Рисунок A.38 — XML текст представления, поддерживающего несколько ролей на языке AutomabonML

+ RoleCiasslib

s Kame IJMrdaflMdRotoaauLb

RoteClaas

s Name

Pnnler

s RefBaaeCtoasPatti AutometoflMLRoleClassLb'AutonvbonULBsseftoie Attribute (1)

— Name 1 Speed

Extemalnteriace (1-

= Name 1 Power

M RoteClaas

s Name

i]

i]

Fax

= RefBasectasaPattt AutomabonULRoieCiaeaLb/AutonietiOrii&BaaeRoie

«I Attribute (1)

[s Name tjSpeed

4 RoteClaas

a Name Scanner

=^-Ref8aaeCta*aPath AiriomacenuliteleCleaalfc/AulowaConKiBaaeRete Attribute (1)

1

‘a Name 1 Speed

RoieClassLib — Библиотека ролевых классов: RoloCtoss — Ролевом класс: RelBaseCtassPalh — Ссылочный путь доступа к базовому классу. Extern allinterface — внешний интерфейс

Рисунок А. 39— Библиотека ролевых классов AutomaUonML, соответствующая примеру с несколькими определениями ролей

62

ПНСТ 177—2016

«RoleClassljb Name"^,UserdefinedRoleC!assUbⁿ>

«RdeCtass Name=‘Printer* RefBaseClassPath^AutomatonMLRdeClassbWAutomalionMLBeseRde^ «Attribute Name='SpeeO"/> cgxtemallnterfaoe Name="Pov\er7>

</RoteCtass>

<RdeCtas3 Катерах" RetBaseC 33sPath="Automalk>nMLRoleClas3Lib.^;AuloaiaU)nML8a3eRote'’^> «Attribute Name='$peed7>

«/RoteC6ss>

«Rdeaass Narne="Scanrier RetBaseaassPatn='*AuiomatfcnMLAdeCiasslRyAutom3№xtMLBaseRde*> «Attribute Name=*Speeff7>

</RofcC&S$>

</RoteCtasslib>

Рисунок A.40 — Текст на языке XML для библиотеки ролевых классов AutomationML

63

ПНСТ 177—2016

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

Представление библиотек AutomationML на языке XML

В.1 Библиотека базового ролевых классов AutomationMLBaseRoleClassLib <?xml versions'1.0" encoding=*utf-8"?>

«CAEXFile xmlns:xsi="hUp://" xsi:noNamespBceSchemaLocebons'CAEX_ClassMode(_V2.15.xs<r FileName="AulomationMLBaseRoleClassLib.AutomationML' SchemaVersion=’2.15’> «AddiUonallnformabon AutomationMLVersion='2.0' />

<Adtftonallnforrnatk)n>

«WriterHeader»

<WriterName»lEC SC65E WG 9«/WriterName»

<WriterlD»IEC SC65E WG 9<TWriter1D>

«WriterVendor»lEC«/WriterVendor»

«WriterVendorURL»v»ww.iec.ch«/WnterVendortJRL»

«WriterVersio*i»1.0«A/VriterVersion>

«WriterRetaase»1.0.0«/WriterRetease»

«LastWritingDaleTime>2013-03-01«/LastWritingDateTime» «WriterProjectTibe»Automation Markup Language Standard Libraries«/WriterPfojectTitte>

«WriterProjectlD»Automation Markup Language Standard Libraries«/WriterProjectl D>

«/WriterHeader»

</Add<tionallnformation>

< External Reference Paths',./InteriaceOass

Libra ries/AutomationMLtnterfaoeClassLib.AutomationML* A)ias^s'AutomationMUnterfaceClassLib~ /»

«RotaClassLib Name^s*AutomationMLBaseRo>eClassLib*»

<Description>Automabon Markup Language base rota class ibrary«/Description>

«Vers*on»2.2.0</Version»

<RoleCtass Name='AutomationMLBaseRole“>

<RoleClass Name=*Group" RefBaseClassPaths'AutomationMLBaseRota''»

<Atthbute Name=’AssocialedFaoet’ AttributeDataType^s"xs:string* l>

</RoleClass>

<RoleClass Name^s'Facef RefBaseC(assPath^s~AutomationMLBaseRole' f> <RoleClass Name='Port* RefBaseClassPath=*AutomationMLBaseRole'>

«Attribute Names'Direction* AttributeDataType^s*xs:string* />

«Attribute Name^s*Cardinality'>

«Attribute Name^a"MinOccur* AttributeDataType^s*xs:unsignedlnt* t>

«Attribute Name^s~MaxOccur' AttributeDataType^s'xs:unsigned!nt' f>

«/Attribute»

«Attribute Name="Category" AttributeDataType=’xs:string' f>

«Extemallnterface Name=‘ConnectionPoinf ID='9942bd9c-c19d-44e4-a197-11b9edl264e7*

RefBaseClassPath='AutomationMLInlerfaceOassLib@Automat«onMLtnlerfaceC lassUb/AutomationMLBaselnterface/PortConnector' />

</RoleClass>

«RoleClass Name^s'Resource' RefBaseClassPath^s*AutomationMLBaseRota' /> «RoleClass Name^s'Product' RefBaseCiassPath^s*AutomabonMLBaseRole' /> «RoleClass Name=‘Process' RefBaseClassPaths'AutomationMLBaseRole' t> «RoleClass Name^s*Structure' RefBaseClassPath=‘Automat>onMLBaseRoie'> «RoleClass Name^s*ProductStructure~ RefBaseClassPath='Structure* l>

«RoleClass Name='ProcessStructure‘ RefBaseClassPath='Slructure' t> «RoleClass Name^s*ResourceStructure' Re(BaseClassPath^s'Structure' f> «/RoleClass»

«RoleClass Name^s'PropertySet" RefBaseClassPath='AulomatiooMLBaseRota' f> «/RoleClass»

</RoteClas9Lib»

«/CAEXFile»

64

ПНСТ 177—2016

В.2 Библиотека классов интерфейса AutomationMLInterfaceClaesUb <?xml version='1.0’ encodtng=*ulf-8’?>

<CAEXFile xmlns:xsi=* xsi :noNamespaceSchemaLocabon=*C AEX_ClassModel_V2.1 S.xsd" FileName^s*AutomationMUnterfaceClassLib.AulomationML* Schema Version=*2.15*> «Additionallnformation AutomationMLV6rsion=''2.0' f>

<Additionallnformation>

<WriterHeader>

<Writertlame>l EC SC65E WG 9</WriterName>

<WntertD>IEC SC65E WG 9</WriteflD>

<WriterVendor>IEC</Wi’itefVendor>

<WriterVendorURL>www.iec.ch</WriterVendorURL>

<WnlerVersion>1.0</WnlerVerskjn>

<WnterRelease>1.0.0</WrrterRelease> <LastWritjngDateTim6>2013-Q3-01</LastWrilingDaleTime>

<WnterProjectTitle> Automation Markup Language Standard bbrariesOWriterProjectTltle»

<WhterRrojectlO>Automation Markup Language Standard bbranes<A/VriterProjecUD>

</WnterHeader>

</Additionallnformation>

OnterfaceCiassLib Name^s*AutomabonMLInterfaceClassLib*>

<Description>Standard Automation Markup Language Interface Class UbraryODescription>

<Version>2.2.0</Ver5ion>

OnterfaceClass Name-'AutomationMLBaselnterface'>

OnterfaceClass Name=*Order' RefBaseClassPaths*AutomabonMLBaselnterface"> «Attribute Name=“Direction‘AtthbuteDataType="xs:string’ />

</lnterfaceClass>

OnterfaceClass Name=*PortConnector* RefBaseClassPath='AutomationMLBaseInteri3ce" l>

OnterfaceClass Name='lntertodoogConnector" RefBaseClassPath^s‘AutomationMLBase Interface" f>

OnterfaceClass Name=’PPRConnector" RefBaseCtassPatb^s*AutomationMLBaseInterface* />

OnterfaceClass Name=*ExtemalDataConnector" RefBaseClassPaths*AutomatK>nMLBase(nterface*>

«Attribute Names’refURr AttnbuteDataType^s*xs:anyURr f>

OnterfaceClass Name=’COLLADA1nterface* RefBaseClassPaths’ExtemalDataConnector' />

OnterfaceClass Name^s*PLCopenXMLInteriace* RefBaseCtassPath='ExlemaJDataConnector* l>

</lnterfaceClass>

OnterfaceClass Name="Communicabon’ RefBaseClassPath='AutomationMLBaselnterface‘>

OnterfaceClass Name=*Signallnterface* RefBaseClassPath^s*Communication* t>

</lnterfaceClass>

</lnterfaceClass>

</fnterfaceCtassbb>

OCAEXFik»

65

ПНСТ 177—2016

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

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДАЛ

66

ПНСТ 177—2016

Библиография

1 IEC 60027 (all parts) Letter symbols to be used in electrical technology

2 Обозначения буквенные, применяемые в электротехнике (асе части IEC 60027)

3 IEC 62264-1 Enterprise-control system integration — Part 1: Models and terminology (Интеграция систем управления предприятием. Часть 1. Модели и терминология)

4 IEC 62714-2 Engineering data exchange format for use in industrial automation systems engineering — Automation Markup Language — Part 2: Role class libraries (Формат обмена техническими данными, используемый при проектировании промышленных автоматизированных систем. Язык разметки автоматизации. Часть 2. Библиотеки ролевых классов)

5 ISO 80000-1 Quantities and units — Part 1: General (Величины и единицы. Часть 1. Общие положения)

67

ПНСТ 177—2016

УДК 658.52.011.56:006.354 ОКС 25.040.40, 35.060, 35.240.50

Ключевые слова: системы промышленной автоматизации, интеграция, формат обмена инженерными данными, стандартизованный формат обмена данными AutornationML

Редактор А.Е. Петросян Технический редактор В.Ю. Фотиева Корректор С. В. Смирнова Компьютерная верстка АЛ. Борониной

Слано в набор 12.12.2016. Подписано а печать 30.01.2017. Формат 60«64'/₈ Гарнитура Ариал Уел. печ. п. 6.37. Уч.-иад. л. 7,65. Тираж 28 эм. Зах. 246.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во , 12309S Москва. Гранатный пер.. 4.