Работаем по всей России
Часы работы: Пн-Пт, 10:00-22:00
+7 ()
Обратный звонок

ГОСТ Р МЭК 62714-1-2020 Формат обмена инженерными данными для использования в системах промышленной автоматизации. Стандартизированный формат обмена данными AutomationML. Часть 1. Архитектура и общие требования

Получить консультацию специалиста

Ошибка: Контактная форма не найдена.

Оставляя заявку, вы соглашаетесь с пользовательским соглашением

>

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

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

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

СТАНДАРТ РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

МЭК 62714-1 — 2020

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

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

Часть 1

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

(IEC 62714-1:2014, IDT)

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

‘Мосмм Ста*дарт**Ф»рм ЗОЙ

Предисловие

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

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

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

  • 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 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на I января текущего года) информационном указателе «Национальные стандарты». а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© IEC, 2014 — Все права сохраняются

© Стацдартинформ. оформление. 2020

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

Содержание

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

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

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

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

  • 3.2 Сокращения

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

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

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

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

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

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

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

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

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

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

  • 6.1 Введение

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

  • 6.3 Библиотека класса базовых интерфейсов AutomationML — AutomationMUnterfaceClassLib…. 14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

■ МЭК 627(4-2: Библиотека ролевых классов.

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

• МЭК 627(4-3: Геометрия и кинематика.

Данный стандарт устанавливает процедуру моделирования информации о геометрии и кинематике: •МЭК 627(4-4: Логика.

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

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

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

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

ж W

ж

,«Z

ГОСТ Р МЭК 62714-1—2020

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

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

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

Часть 1

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

Engineering data exchange format lor use in industrial automation systems engineering. Automation markup language. Part 1. Architecture and general requirements

Дата введения — 2021—01—01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание — Атрибуты языка AutomationML описаны в качестве элементов расширяемого языка разметки XML соответствующие МЭК 624242008. подраздел А.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.

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

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

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

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

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

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

Примечание 1 — Конкретный пример идентификатора GUID: «(AC76BA86-7AD7-1033-7В44-А70000000000)».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 Сокращения

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

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

САЕ — автоматизированное проектирование (Computer Aided Engineering):

САЕХ — нейтральный формат обмена данными (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—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. то указанный второй объект языка Aulomal*onML называется «главным объектом». Зеркальный объект считается идентичным главному объекту. Это обеспечивает возможность разместить экземпляр одного объекта в различных иерархиях установки и. таким образом, позволяет моделировать сложные сети объектов с пересекающимися структурами.

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

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

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

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

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

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

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

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

COLLADA — это фирменный продукт группы Khronos. Данная информация приведена для удобства пользователей настоящего стандарта. Она не является официальным согласованием указанного продукта стандартом МЭК. Эквивалентные продукты также могут быть использованы, если их применение дает аналогичное результаты. языка 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”;

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

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

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

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

«CAEXFile xmhs:xsi«,‘htfp:XM’Ww.w3.orgQ001/XX.SchemB1instance”xsirKN9mejpaceSchemaLocation1

CAEX.CteesModel xscT MeNeme»4 Automat ionM.StenderdLibrary2010-01 -14jH.99 ant’ SchemaVereon«”2.15″» «АйМЮпайгИогтпаОоп AutomatKknM.Verscns’^Xr^

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

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

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

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

Примечание 2 — Это гарантирует уникальность имени библиотеки AutomalxxrML внутри файла 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-:

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

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

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

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

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

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

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

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

  • ■ название проекта источника:

  • ■ идентификатор проекта источника:

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

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

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

Имя rera XML

Тип

Уровень

Пример

WriterName

xsstring

Обязательный

«TootX AML Exporter-

WnterlD

xs siring

Обязательный

«ToolXToAML123-

Writervendor

xsstnng

Обязательный

«ToolX Vendor»

WriterVendorURL

xsstnng

Обязательный

«httpy.’Www.ToolX-Vendor.org»

Wnter Version

xsslring

Обязательный

«0.2»

WriterRelease

xsslring

Обязательный

«123 prealpha»

LastWntingDateTime

xs:DateT<me

Обязательный

•20t 1-05-25709:30:47»

Окончание таблицы 2

Имя XML

Тип

Уровень

Пример

Writer ProjectTftte

xs string

■*По выбору»

-eCarproduclion-

Writer ProjectID

xs string

“По выбору»

“eCarproductionJJnePLC.prj»

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

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

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

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

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

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

^Addfoonallnfonnabon»

«WriterHeader»

<WnterName>TooiX AML Exporter^WnterName» <TodWntedD>TootXToAML123</ToolWriterlD> <Wri1erVendor>ToolX Vendor<.’WfttefVendor> <WriterVendorURL»http://www.ToolX*Vendor.org</WriterVendorllRL> <WmterVersion>0.1</WriterVers*on>

<WrrterRefease>123 prea*pha</WrrtecRetease> <LastWntingOateTime>2013*12-31T12:00:00<lastWritingDateTime> <WriterProjectTitle>eCarproduction<*’WnterProjectTrtle> <WnterProjectlD»eCarproductjon_Line₽LC.prj</WrrterProjectlD>

</WnterHeader>

«/Additionallnformation»

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

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

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

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

  • • в соответствии с МЭК 62424 (пункт А.2.2.1) классы языка AutomationML (ролевой класс RoleClass, класс интерфейсов Interfaceclass, класс системных единиц SystemUnitClass) идентифицируются тегом «Name (имя)» формата САЕХ;

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

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

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

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

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

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

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

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

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

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

Пример 1 — «GUID:out»;

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

Пример 2— “GUID.Coiour».

Пример 3— «GUID.Colour.red».

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

* ^vtemUnRO*» Ы.»

г Кмпе

«. $уи*п8>п*С1м«

□ в Nam* ЯСМ12М

» SyttemUMKiM* s Нмпе Srecaltabctl 2M

J 8 MAM«ClMePa*hEMH«ii«SyH*>MJr«aM»LbRc»X123«

♦SystwNjreCtessLto \Ars-‘Exa*rjteSystewiJntQessi.tb^

i <Sy«teffllhiiaM$Nra^itobcH234^

I «SystemUnUCiMS NNn?>*’SpeciaRctat1234′ RetbiweCias$>’atr>«‘ExampleSy^emUntClas8LtMRobott234’7> </SystewiJr>4ObsstJb»

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

Пример иерархии экземпляров InstanceHierarchy с одним объектом «RB_100». имеющим уникальный идентификатор, представленный строкой -GUIDI». приведен на рисунке 5.

«| InstmceffieiMchy

s Пате ЕхагпрИРгодо

4 int«< n^ltiement

= tUmeRDJQO

J s IP OMbl

«metOAcerteraf eh? Harz-‘ExempiePttfcd’-

| «HteineElement Ncne=1®_100*ibB*GUt>1″/»

«jfrtstanceHerflrchy»

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

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

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

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

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

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

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

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

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

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

*■ inetanceHieiarchy

= HanieParert спи regions exampte

A Inter natElemem

s Name Object A

= Ю GUDt A biter naKlement

s Нмпе ObjectAJ = ID GUD2

A biter naKlement

= llame <XjectA_2

= ID GUD3

A hiteiiMElement

s thme OfcfectA_2_1

= ID GUD4

dnstancclticrarehy Narnc-“Parent child relations example’*

dnternalElcmeni Name*”OhjcctA” llk-HGli|DI”>

dnternalElemeni Namc-‘ObjeciA Г HJs’Gl’KXT-‘*

dntcrnalElcmenl Namc“”ObjcclA_2″ ID-“Gt4l)3”>

<lntcrnalElemcni Name*”ObjectA 2. Г ID«“OUII>4“-,>

<Inlern»ll-‘.kmcn1>

<.’lntcrnaH.knicnl>

«^Instance! lietareh>>

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

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

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

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

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

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

Пример соотношения «родитель — потомок» между классами «Parentclass- и -ChildClass* приведен на рисунке 7. -ChildClass- не обеспечивает соотношения наследования с родителем.

A SystemUnaciassUb

s Name MySystemUntCtasUb

л| Sy*t»n>UniiCh**

s Name ParertCtess

SyetemUnKCU»* г Name

CNdOess

«SysiemUril Oats LA “lanes ’MySystemUHKlwsUbs

■ <SystemUf4Ges»N«r<c*’PwertClws’»

| | <$ytfefflLlrrtCte$s Name»*Chil(JCtas’r»

• </SydenUnMCIe$««

«’■’SyatemUntClasaLto»

Рисунок 7 — Пример соотношения “родитель — потомок» между классами

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

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

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

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

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

Пример класса «Robott234». а также класса -SpecialRobott234». наследующего класс -<Robot1234», приведен на рисунке 8.

И SystemUnitCtessLib s Kame ntiertancefxampteLt И SystemUnttClM»

= Ham* Robot1234 ‘ a. Sy»t«rr>UnhCla»»

I г Name Spec*Roboti2M

_ _ s RefBa»eCla»»P«th йЬег**псеЕхапф*1ДО0ОО11234

<Sy«temUmtCla*sLib Name>“lnhentancaExampl«Lib”>

<Sy»lemUniiClas» Name**Robo<1234*>

«SystemUmtCiess Nafne=’SpeciaiRobot1234″ RefBaseClassPath3* inheritances xamplelib/Robotl 234″»

</SystemunitCiats>

</SystemUnitClassLib>

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

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

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

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

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

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

  • ■ объект языка AutomationML может быть одиночным объектом без связи с классом SystemUnitClass.

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

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

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

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

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

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

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

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

  • ■ изменение класса источника должно вести к появлению новой версии класса с другим именем. Внутри нового класса полный путь доступа к старой версии класса должен храниться в теге САЕХ -OidVersion-’.

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

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

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

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

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

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

а| InetanceHieiarchy

s lUnie QassInstanceRetation Example internalElement

s llanie ObjectA

= ГО GUD1

J J = Re1BaseSyMemUnttPathmySysten<JnltCla$sLto$eneric_Vaive

‘InstenceMerercTiY ^yT<–‘Ctass*wt*nceRe*eiion Exatrpte’ *

! -drtematBwnert Hwnc«‘OtojectA” K-‘XXO1″ fi*i8o?cSyctor>lJnePeth^mySya*emUnltCle««L*Meenerto_Vetve”A-<m$t«nceH№r«rcbY»

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

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

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

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

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

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

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

■ САЕХ InternalLinks хранится сущностью САЕХ InternalElements. являющейся общим родителем самого нижнего уровня для соответствующих соединенных объектов САЕХ;

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

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

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

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

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

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

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

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

«о ChanneWl

а) Соотношение в виде «блок-схема»

b) Соотношение в виде «дерево объектов»

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

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

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

«hsIanceHararchy гмл>е>‘Ъг*Ехат0е’»

<MemaBem*nt MHw’Stetton” e-’GUOl “• «Иаггяватага Naw”Rob1 * C-XXIW» ( <xt«rmir№mc«htirrft**siarrяагеааКмааРШь’АаслмпогмтаггассСисаси/ /sgnairaafface’* ! t ‘AMrtoJte нал>е»’Т)ре*> • • i <v«ue->4gtebuvaaie» i I «MUrtote» : ! KARrtute MyrwaDfredforr» ! : } <Vaba»h’A/aiue>

■ «Cxtematrterface»

«.WemaClemert»

«HerreClemert flni»s**Fl.C1′ О»ХЭи0У>

crferna&mn rx-e=-BoerdCH ‘ Ck*GIJW>

i «ExlamaHertaca Narw*-‘OwnaDr RerGase’Vi^rM’^-AUoiMtttnMLlraerlacaaaatU» /SignaMarfaca*-I ■ «Aantxae Коле-Туре”» ! I | «Va*je»dlgta*«/v’aiuc* j | <Mrtute»

• j «Astute h*rye=”Deedkn”> I | <va*jtM>l«A’alu*> ! ! «M»b4e>

: <€xwnM*te>tace»

<*VamaCHmaN«

MraemaEteffiant*

-1rtnna<jr*>lsmc-H»dwareLr*1”RffP4nnCTS;<xA-“GU©4 CharvwKH”‘Reff,arir>№iaaB-*0UD2StorrA <«етаввпег1»

< *> йалсаНм arthy»

<instanceHiervchy Names”LinkExampie”>

<lnlecna!E{ement Name*’Station* ID»’GUID1‘>

‘IntemalElemeHt Name-’RobV ID-*GUIO2“’

«ExternalInterface Name»”Starf RefBaaeClasaPdh”*AutomationML!nterfaeeClMsLib/ JSignallnterface’/» ^IntemaEiement*

<lntemalEleen«nt Name«”PLC1 * ID»”GUIO3*>

«IntemaiElement Names’BoardOI’ ID“*GUID4′>

«Extemallnterface Name«”ChannelOr RefBaseCla&»Path«’Aukxnatk>riMLlnterfaceClassLjb’.. /Signailn’effa <1r»wm alEKnent*

</lntama€ lament»

«IntemalLtn*: Names’Kard<varaLinl(r RefPamefS«SeA=’GU©4 CI’>anneK)r RefPartnerS*dee<‘GUI02$tMr> </lnlemalEtem«nl>

</JnManceHierarehy>

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

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

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

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

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

Ссылки на документы COLLADA приводятся с помощью класса стандартных интерфейсов AutomationML -COLLADAInterface» или одного из его производных. Данный класс рассмотрен в 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 InterlaceClass. Они выводятся непосредственно или косвенно из стандартного класса интерфейсов ExtemalDataConnector:

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

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

  • 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 — Библиотека класса интерфейсов AulomationMLInterfaceClassLit)

Библиотека AulomaticnML InterfaceClass

AutomatxHiMUnterfaceClassUb

Automation MIBaselnterface

ю Order

-о PortConnector

-о InteriockingConnector

-o PPRConnector

ExternalDataConnector

-o COLLADAInterface

-o PLCopenXMUnterface

-o Communication Signalinterface

Класс интерфейсов kilerfaceClass

Описание

AutomationMLBaselnterlace

Абстрактный тип интерфейса

Order

Интерфейс описания порядка

PortConnector

Интерфейс описания портов

PPRConnector

Коннектор для взаимосвязан-шх продуктов, ресурсов или процессов

ExternalOataConneclor

Характерный интерфейс коннектора внешних данных

COLLADAInterface

Интерфейс документа COLLADA

PLCopenXMUnterface

Интерфейс документа PLCopen XML

Communication

Характерный коммуникационный интерфейс

Signallntertace

Характерный интерфейс сигналов

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

A interfaceCiaaaLib

‘ s Name

AutomebonUUnterfacaClaasLt)

О Description Standard AutomattonML Interface Clasa Library

<) Version 2.11

a Interfaced***

= Name AutomabonMLBaaeWerfaee

a Interfaceclass

s Name Order

s RefBa*eCla*sPath AutomabonMLBaselnlerface ai Attnbute

Name Direction

AttnbuteDataType «string

a interfaced»**

s Name

PortConnector

J = RefBaseClassPath AutomatenMLBaaetntcrfacc a Interfaced***

s Name MertockmjConnector

= RefBaseClassPath AutomationMLBasewerface

a interfaced**! _____________

= Name PPRConnectcr___________

J s RefBaseClaasPath AutomabonMLBaMtntertice a Interfaced***

s Name ExtemaDataConneaor

s RefBaaeCtataPath AutomatwnMLBaaeinterface

A Attribute

Name refUR)

AttnbuteDataType xsanyURI

a; interfaced*»* iT

= Name COllADA*»terfaca PLCepenXMLW enace

s RefBaseClassPath Exte ma DateConnect or ExtemaDataConnector

Communication

Interfaced*** s Name s RefBaseClassPath AutomatonMLBaaehterface a interfacedassl)

= Name

1 Signalnterfoce

= RefBaseClassPath

CommjnKaton

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

< InterfaceClassLib Nane=”AutomabonMLInterf aceClassUb*>

«Description>Standard AutomationML Interface Class Library«/Description>

<Version*2.1.1</Verston>

«InterfaceClass Name«”AutomationMLBaselnterface->

«InterfaceClass Name»”Order” RefBaseClassPath=*AutomationMLBaselnterface’>

«Attribute Name=”Direction’ AttributeDataType=”xs:string”>

«/InterfaceClass*

«InterfaceClass Name»”PortCcnnectcr” RefBaseClassPath»’AutomationMLBaselnterface”>

«InterfaceClass Name» InterlockingConnectcr” RefBaseClassPath«’’AutomationMLBaselnterface7>

«InterfaceClass Name=”PPRConnectoT RefBaseClassPath=”AutomationMLBaselnterface’‘ >

«InterfaceClass Name=’ExtemalDataConnector” RefBa$eClassPath=”AutomaticrMLBaselnterface”>

«Attribute Name»”refURr AttnbuteDataTypeeHxs:anyURr/>

«InterfaceClass Name=”COLLADAInterface” RefBaseClassPath=,*ExtemalDataCcnnector7>

«InterfaceClass Namea“PLCopenXMLInterface” RefBaseClassPath»’ExtemalOataConnector”/>

«/InterfaceClass*

«InterfaceClass Name»”CommunicationH RefBaseCla$sPath=”AutomationMLBaselnterface’*

«InterfaceClass Name~”Signallnterface’ RefBaseClassPath»’Communk:ation’>

«/InterfaceClass*

«/InterfaceClass*

«/Interfaced lassLib*

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

  • 6.3.2 Класс интерфейсов InterfaceClass AutomationMLBaselnterface

Описание класса интерфейсов ■’AutomationMLBaselnterface» приведено в таблице 4.

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

Имя класса

AulomationMLBaselnierface

Описание

Класс интерфейсов «AutomationMLBaselnterface” — это базовый абстрактный тип интерфейса. Используется как родитель для описания всех классов интерфейсов AutomationML

Родительский класс

Нет

Атрибут

Нет

  • 6.3.3 Класс интерфейсов InterfaceClass Order

Описание класса интерфейсов «Order» приведено в таблице 5.

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

Имя класса

Order

Описание

Класс жтерфейоов «Order» — это абстрактный класс, используемый для описания порядка следования элементов, например последующий или предшествующий

Родительский класс

AutomabonMLInterlaceClassLib/AutomationMLBaselnterface

Атрибут

Direction {тип = «xs:slring~)

Атрибут «Direction» используется для описания направления. Допустимые значения: «1п» (вход). «Out» (выход}. -InOut- (вход/выход)

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

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

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

Иыякласса

PortConnector

Описание

Класс интерфейсов «PortConnector» используется для обеспечения соотношений высокого уровня между портами. Обзор понятия «порт» см. в подразделе А.2.2

Родительский класс

AulomationMLInterfaceClassLjb/AutomationMLBaselnlerlace

Атрибут

Нет |

  • 6.3.5 Класс интерфейсов InterfaceClass PPRConnector

Описание класса интерфейсов «PPRConnector» приведено в таблице 7.

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

Иыя класса

PPRConnecior

Описание

Класс интерфейсов «PPRConnector» обеспечивает соотношение между ресурсами, продуктами и процессами. См. дополнитегъную информацию в подразделе А.2.6

Родительский класс

AutomationMLlnterfaceClassLib-‘AutomalionMLBasetnterlace

Атрибут

Нет |

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

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

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

Иыя класса

ExlernalDataConnector

Описание

Класс интерфейсов «ExternalDataConnector» — это базовый абстрактный тип интерфейса. Используется для описания интерфейсов коннектора, ссылающегося на внешние документы. Классы «COLLADAInterface» и -PLCopenXML Interface» выводятся из данного класса. Все существующие и будущие классы коннекторов должны выводиться непосредственно или косвенно из данного класса

Родительский класс

AutomationMLInterfaceClassUb/AutomationMLBase Interface

Атрибут

refURI (типа -xs:anyURI»)

Атрибут «retURI» используется для хранения пути доступа к ссылочному внешнему документу

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

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

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

Иыя класса

COLLADAinteriace

Описание

Класс интерфейсов -COLLADAinteriace» используется для ссылки на внешние документы COLLADA и для публикации интерфейсов, определенных внутри внешнего документа COLLADA. Подробности приведены в МЭК 62714-3

Родительский класс

AulomaticmMLlnterfaceClassbb-‘AutomationMLBaselnterface-ExtemalDataConnector

Атрибут

Нет

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

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

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

Имя класса

PLCopcnXMLinierface

Описание

Класс интерфейсов ■■PLCopenXMLInterface” используется для осыпки на внешние документы PLCopen XML или для публикации сигналов (переменных), определенных внутри описания логики формата PLCopen XML. Подробности приведены в МЭК 62714-4

Родительский класс

AutomationMLBaselnterface’ExtematDataConnector

Атрибут

Нет |

  • 6.3.9 Класс интерфейсов InterfaceClass Communication

Описание класса интерфейсов ‘«Communication” приведено в таблице 11.

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

Имя класса

Communication

Описание

Класс интерфейсов •■Communication” — это абстрактный тип интерфейса. Используется для описания интерфейсов, связанных с коммуникацией. Последующие классы. связанные с коммуникацией, выводятся из данного класса непосредственно или косвенно

Родительский класс

AutomationMLInterlaceClassLib’AulomationMLSaselnterface

Атрибут

Нет |

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

Описание класса интерфейсов сигналов “Signallnterface» приведено в таблице 12.

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

Имя класса

Signaltnierlace

Описание

Класс интерфейсов •’Signallnterface» используется для моделирования сигналов. Тип интерфейса — конфигурируемый. Он содержит описание цифровых и аналоговых входов и выходов, а также конфигурируемых входов’выходое. Пример приведен на рисунке 10

Родительский класс

AutomalionMLInterlaceClassLiti’AulomationMLBaselnterface’Communicalron

Атрибут

Нет |

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

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

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

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

ffP)AutomationMLBaseRoleClasslib /|пмы AutomationMLBaseRole

Group Facet Port -o CoonectionPoint

Resource Product Process Structure

Productstructure

Processstructure

Resourcestructure

PropertySet

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

В ВМЧ1

• А»1ЫНОМ»?ГМ

{Данном

г Омоет г ctrMtf

И«П|

• АВЛПиГВ

> С*Н»»^

ГМвпмМавгЫ*

> ВВП*

■StMBf

C«meta»»₽»«

В ВЫМ В АНлЫНОаНТум

* ЫОтг в*»м

. 2 ЩаОыакммв

«ReteCtossLibNanw «’AuMmabonMLSmRcrieCIsssbb”-

< Descnpbon>AutomeuonML Ь*м гой Horary </Ds*crtptron>

<V«rtiOA>21 1</V»roion>

«RcIsCtass Na*n« “‘AutomationULBssaRols*»

<Rol*Cla*» Name «”Group* Ref0a»aCleesPath«’Au»omet»rMLBa»aRoU »

«Anrtxrts Nme*A»*oci«rodF«K*C AmtbuteDs»Typ»»*x».»Mog’r>

</RoloClMS>

<RoteCl»s Name-Fac«r R«fBa»»Class?»!hs”AutomM>ooMLBa$eRoW >

<RoIoCIms Name=Tort’ R«f3a*eCl*$&Patb=’Au»mat>$<iMl8asaRoro’-

<A*ribute N»^ne=’Dk»ct>of’”AttnbuteD*MT^«-‘,x»»<ri<‘g’i’>

«Attribute Namo^ Cartinality” AonbutsDetaType-“xa comptexType’»

«Attribute Nema«’14inOecir**AlMbue»C«t»TypeB“x>ukrt’/>

«Attribute Namoe’lta>eOceir*Aeribut«DattTypteHx»uM”/>

«.’Attn but» >

«AOrtoute Nemo«”CMegor/’Attowt0Deta~)P*s“n.alring’/>

«&rt»man<n»rfees Nsme“Cor»nee6onPont’ RefBateCtostPetb»

*Auiomet>onf-‘Linierfoce089$LibQAutori«so^1LlK«rtKeCWs8Ub/AutomeborMLSeseirterfKer9oaC<yir«<tcr’ -«Ro>»Clm>

<RobClM»Nafne *R»»ourc»’ Ref8>»eOa«sPKtw’Autom»tionMLBMeRol»’T>

«RoIoCIm» Rama «’Product* RofBa wC!as»Reth«’Amomado<iMLBM»Re*»”>

<RoleClMa Name «’Process’ KcfB4saCiBS»₽acn=’ AutomabonMLBeaaRo*e’r>

<Roi»CimNen* « SbvaMf»”Re’BmCfc»p«ns*AutomnonMLBMbR9i»*>

<Ro»eCleasName=’ FroductStructore” Re’BsssC’assPathe’AutomeBonMt.BeaeRole/SUuctcre’fr

«RofeClMShamas*ProceseSTuebre’ RefBewClMsPetM’AutomenonMLBaMRola’Struciuro*/»

cRokClMtNs’nes’RetoureeStrueture’ R»t8as»Cia>«Pstn«’AulOfneBorM.BM»ReM>‘Structu<*”>

<RoteCfcM>

«RoleClass Name “”PropertySaf RofBaseCtossPath*”AutomationML6asoRcie”.’>

«ЯейСйаа»

«rRotsCtoMLib»

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

  • 6.4.2 Ролевой класс RoleClass AutomationMLBaseRole

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

Таблица 13 — Ролевой класс RoleClass Automation MLBaseRole

Имя шасса

AutomalionMLBaseRole

Описание

Ролевой класс «AutomationMLBaseRole» — это базовый абстрактный тип ролей и базовый класс для всех стандартных или пользовательских ролевых классов

Родительский класс

Нет

Атрибут

Нет |

  • 6.4.3 Ролевой класс RoleClass Group

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

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

Имя класса

Group

Описание

Ролевой класс «Group» — это тип ролей для объектов, группирующих зеркальные объекты, которые соответствуют друг другу по определенным инженерным критериям. Объект группы AutomationML должен ссылаться на данную роль. Подробности и примеры рассмотрены в разделе 8.4

Родительский класс

AutomationMLBaseRoleClassLit)’AutomationMLBaseRole

Атрибут

«AssociatedFacet» (тип = «xs:string»)

Атрибут «AssocialedFacet» испогъзуется для определения имени соответствующего фасета.

Пример—AssociatedFacet = «PLCFacel*

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

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

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

Имя класса

Facet

Описание

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

Родительский класс

AulomationMLBaseRoleCtassLib’AutomationMLBaseRoie

Атрибут

Нет

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

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

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

Имя класса

Рол

Описание

Ролевой класс «Pod» — это тип ролей для объектов, группирующих несколько интерфейсов и позволяющих описывать сложные интерфейсы в указанном смысле. Объект класса AutomationML Port должен ссылаться на данную роль. Подробности и примеры рассмотрены в 8.2

Родительский класс

AulomalionMLBaseRoieClassLib’AutomationMLBaseRoie

Атрибут

Direction (тип * «xs:string»)

Данный атрибут описывает направление класса Port. Значение атрибута выбирается из ряда: «1п» (вход). «Out» (выход), -InOut- (вход-выход). Порты с направлением «1п» могут соединяться только с портами с направлениями «Out- и -InOut-. Порты с направлением «Out» могут соединяться только с портами с направлениями -1п» и «InOut». Порты с направлением -InOut» могут соединяться с портами произвольного направления. Пример: Direction a «Out» (например, вилка) Direction = «1п» (например, розетка) Direction a «InOut».

Данная информация может быть использована, например. для валидации соединения.

Примечание — Валидация рассматриваемого соединения лежит вне области применения МЭК 62714, но относится к функциональности инструментального средства.

«Cardinality»

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

«Category» (тип x «xs:string»)

Данный атрибут описывает тип порта. Значение данного атрибута определяется пользователем. Соединять можно только порты с одинаковым значением атрибута Category.

Пример — Category = “MamepuanFlow*.

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

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

Атрибут

Тип

Описание

Пример

-MinOccur-

xs:uns»gnedlnt

Значение атрибута MinOccur указывает минимально возможное количество соединений, входящих в данный порт (исходящих из данного порта). Значение атрибута должно быть ■■больше чем или равно» 0

МпОссш = 1.

Это означает, что данный порт должен соединяться по крайней мере с одним портом

-МахОссиг-

xs:uns»gnedlnf

Значение атрибута МахОссиг указывает максимально возможное количество соединений, входящих в данный порт (исходящих из данного порта). Значение данного атрибута должно быть «больше чем или равно» значению атрибута MinOccur или равно 0. что означает неопределенность

МахОссиг а 3.

Это означает, что данный порт может быть соединен максимально с тремя другими портами

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

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

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

Интерфейс

Тил

Описание

Пример

Имя определяется пользователем. например -ConneclionPoint»

PortConnector

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

См. пункт А.2.2.2

  • 6.4.6 Ресурс ролевых классов RoleClass Resource

Описание ролевого класса «Resource» приведено в таблице 19.

Таблица 19 — Ролевой класс RoleClass Resource

Имя класса

Resource

Описание

Ролевой класс «Resource» — это базовый абстрактный тип ролей и базовый класс для всех ролей ресурсов AutomationML. Он описывает установки, оборудование и другие производственные ресурсы. Объекты ресурса AutomationML должны непосредственно или косвенно ссылаться на данную роль. Пример рассмотрен в подразделе А.2.6

Родительский класс

Automat>onMLBaseRoleClassLi&”AutomationMLBaseRole

Атрибут

Нет

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

  • 6.4.7 Ролевой класс RoleClass Product

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

Таблица 20 — Ролевой класс RoleClass Product

Инн класса

Product

Описание

Ролевой класс «Product» — это базовый абстрактный тип ролей и базовый класс для всех ролей продуктов AutomationML. Он описывает продукты, части продуктов и продукты, относящиеся к материалам, обработанным на описанной установке. Объекты продукта AutomationML должны непосредственно или косвенно ссылаться на данную роль. Пример рассмотрен в подразделе А.2.6

Родительский класс

AutomationMLBaseRoleClassLib’AulomalionMLBaseRole

Атрибут

Нет |

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

  • 6.4.8 Ролевой класс RoleClass Process

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

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

Иыя класса

Process

Описание

Ролевой класс «Process» — это базовый абстрактный тип ролей и базовый класс для всех ролей процессов AutomationML. Он описывает производственные процессы. Объекты процессов AutomationML должны непосредственно или косвенно ссылаться на данную роль. Пример рассмотрен в подразделе А.2.6

Родительский класс

AutomationMLBaseRoteClassLibAutomationMLBaseRole

Атрибут

Нет

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

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

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

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

Иыя класса

Structure

Описание

Ролевой класс «Structure» — это базовый абстрактный тип ролей для объектов, являющихся структурными элементами в иерархии установки. Например, фальцевальная машина, производственная площадаа. производственная линия. Объекты структуры AutomationML д олжны непосредственно или косвенно ссылаться на данную роль

Родительский класс

AulomationMLBaseRoteClassLib’AutomationMLBaseRole

Атрибут

Нет |

  • 6.4.10 Ролевой класс RoleClass Productstructure

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

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

Иыя класса

ProductSlruclure

Описание

Ролевой класс «ProductStructure» — это абстрактный тип ролей для продукт-ориентированной иерархии объектов. Объект структуры продукта AutomationML должен непосредственно или косвенно ссылаться на данную роль

Родительский класс

AutomationMLBaseRoieClassLibAulomalionMLBaseRole.SIructure

Атрибут

Нет |

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

Описание ролевого класса •■ProcessStructure» приведено в таблице 24.

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

Имя класса

ProcessStrudure

Описание

Ролевой класс “ProcessStructure» — это абстрактный тип ролей для процесс-ориентированной иерархии объектов. Объект структуры процесса AulomabonML должен непосредственно или косвенно ссылаться на данную роль

Родительский класс

Automa tionMLBaseRoleClassljb>’AutomationMLBaseRole’Struclure

Атрибут

Нет |

  • 6.4.12 Ролевой класс RoleClass Resourcestructure

Описание ролевого класса Resourcestructure- приведено в таблице 25.

Таблица 25 — Ролевой класс RoleClass Resourcestructure

Имя класса

RosourceSlrudure

Описание

Ролевой класс “ResourceStructure- — это абстрактный тип ролей для ресурс-ориентированной иерархии объектов. Объект структуры ресурса AutomationML должен непосредственно или косвенно ссылаться на данную роль

Родительский класс

Automal>onMLBaseRoleClassLjtVAutomationMLBaseRols>’StructurG

Атрибут

Нет |

  • 6.4.13 Ролевой класс RoleClass ProperlySet

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

Таблица 26 — Ролевой класс RoleClass PropertySel

Имя класса

PropenySet

Описание

Ролевой класс ■’PropertySet» — это абстрактный тип ролей, обеспечивающий определение наборов свойств, соответствующих определенному инженерному аспекту. Объект набора свойств AutomationML должен непосредственно или косвенно ссылаться на данную роль. Нормативные положения описаны в 8.5. Подробности и примеры приведены в подразделе А.2.5

Родительский класс

AutomationMLBaseRoleClassUb’AutomationMLBaseRole

Атрибут

Нет |

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

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

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

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

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

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

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

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

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

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

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

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

г »«■»« UtttOemwNMMMiExa’Ve » НенмОммп*

ж HmwOiwdM = № 0UD1 4АП|Ь*««

ж |Ьпи untfn

S Ml йм<»(МиТи>* SUM №

Ovmo* «

«InstanceHtorarchy Netne-’UeerOefinedAttrfculejExemple’»

; «mtemaElemert i«me=*OtjedOl * Cm’GUDI*»

| ’AeftOute45<re-’Lengpi’Ati4tMjteDet«iT’l-pe-“xs:string’Urfl-’W»

i I <Vate>l2<A/»»ue>

i c.<Attrt>ute>

; «ArtferndBeinerrt»

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

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

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

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

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

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

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

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

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

krter1ace€la»sL№

s Нате u$erDefr«dCia$$L*>

IntetfaceCUss

г Нате MyfrpteBnpii

s RefBaseClasePath AutornetionMUrtetfaceOassLib/. JS&reihterfdce

4 Attribute ГЗ)

s iMme

s АППЬигеО.МаТуре () value

1 Туре

xs string

Diglei

2 Direction

xs. string

In

3 Enabled

xsboolean

true

«kterfeceClassLib N«nt=’UserDeiineciClas3Li>“»

«tterfeceClass f’^r’’”’MyC*®tailnput’Ref0»se<les5#,atri*”AUomaticrA4JnierteceClessLjb/,/Slgoatrtertece’-«Attribute Name •‘Type” ArVtoJ’eDetaT’(pe«’xs:string”» | <Vduc>Digta<0V4iue> OAttnbute»

«Attribute N-5me-=’Drectjon” AttrbuteDetaType®*xs:string“’

} <V«iue»ln«JV#lue»

«AAttrtbute»

«Aftrfciie №г№>э*ЕмЬ1есГ AttnbU6tetaTy‘pe»*yt:boolMn**

| «Vaiu8>trije<yVatue>

«^Attribute»

«tntertaceciass’

«MeriBceCIsesUb»

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

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

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

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

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

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

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

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

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

RoleCUsslft s name H ReleCU»»

UserDefmecFoleaeBSLib

s Home Fence ___

□ RefltaseClassPMh AUixnetionMLBaseRoleClasslJbXAUotnationM-BsseflQlM^souict

«RoteCtessUb Narhc-‘UsefOefnecRoleOeesLib”

| «RcieCiess r4ar^=”Fer)ce* ReiBeseaaasPatr^AUnMionMLBeseRcrieaassLibMutomAofMBeseRoie^esource*^ «jfateCieesUb»

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

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

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

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

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

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

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

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

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

SystetnUn*CMaeLI>

8 Нате UberOefnedSysteeUniClMsijb

•*j Sy»t«mUnMCJa»«

3 Name R0b0t1234

at SuppoMedftotoCtM* _J з ReCRoteCtebaFMh AJomdiordiCBaeelWeCbeMJbXWamationMLBeeertoWteeot^ce

Sy»t»mVnftCU«« з Hante Sfceciatftobctl 234

з RefBaseCM«sPMhl^ert>&flr«fiYSlefMJr>tQessLM?oboH234

«SystemUnltClesstto Nftrrx^lJseiDefinedSystemLhtaesslJb^

i ^SyStttNJnitCless t4rtrr>»8’,Rob0t1234M»

i | ^Supportec^oi^iassRefRatev^ssPa^’AutomaticrtHl^esdtoteaeesLWAutixKetioriM-BeseRDto^eswrce’A rjSYSiemUniOess»

I =5ystemUnitCI»331 lane» ‘SpeceiRobctl 234” Re183seClassFatb’,Us8rDefnafi’y5temLlrtlOassLt>jR0tXJ!1234′ r» «/SystemLhtCfessLib»

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

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

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

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

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

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

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

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

Пример иерархии, включающей линию «L001» со станцией «S001». содержащей двух роботов «R0010.D» и «R0020.D». конвейер -RF010» и программируемый логический контроллер PLC -Р001». приведен на рисунке 2t.

£3 ExampleHietarchy

е Е looi е Е sooi

R0010_D

R0020_D RF010 РОСТ!

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

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

‘hslarcerterwchy sa-ni-‘Examftertsrerchf > <rtems£temnt D*’CUD1*>

«HerrwOemtri нпт»»*500ТЧ>«’01Ж>2*» «•KetneCertert Heme’’’R0010_Cr‘ O’WCG* R’8fBateSY5lercrrtPeet-*’RcbteJ5rsryffObOt_1234‘ j «Kctertequremenis RefBm^deCiM$FW**AuloiBetiorMJtoteC)assUM<Aul6H«tto<M£e»Rcte*te3(Mce’r» <*ilem4E)amen(» KWerMtBerwt Nsw’TWMjr O*”GUO4* RefBeseSvsleiwjr«P««r*f Rob«UftreryjRobotJ234’» j «rtc*^«n#en>erteKc’bo5eftc<cUi<;h>tt»»^*uto»ettorMJtotoClas4Lfc>AulomatKxM3e3eRcte<teMMce’/> «ttemSBemert» •wemeewwi o-‘OUDS’*

| -<ЯсйсА«яигепеч« ЯегВо$сЯ«1еСИзтР<йЬ«*Аи1о1мВогМЛо1»С1емиьХАи1амиопИЛ»иЯсйЖмоигсе’> «jMemaBemert» cntemsSerert hew*^001″ DAOUDS*» | 4tctefrqufrt>wts Re»Bn^de:i355pafr,^AiA»aiicrM.CSRciteaes^jbConfr<«qijpmenlKo*oHaiiMrarwCcnt>t>»e»₽LCft «Aniemaiee<nent» <ЯсИАсфж<я^зЯеГВл:еЯс<еСИ$гМь«*Аио1МЙагМ.ЯоЬС1ма1&ГАи(омвогМ1В«мШ«А»>оигс«£*гис1иг«*л «JWemedemert» «RcteRetMetrerts k?*i4i5e*c*e< ^ss^<«h«*AutonettorM1tDieClaB3Uh(AutoiMticrMJtee^toiBABsouce£tructure’/» «HerneBemert»

– AriftoneeHererchy»

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

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

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

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

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

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

Для портов AutomationML Port применяют следующие положения:

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

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

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

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

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

  • – порт AutomationML Port должен дополнительно иметь по крайней мере один внешний интерфейс САЕХ Extemallnterface, полученный из класса интерфейсов 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.Э.

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

  • ■ объект фасет AutomationML Facet описывается в формате внутренних элементов САЕХ IntemalElements в ассоциации с ролевым классом RoleClass «Facet», описанным в 6.4.4;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a toataneeMterarcriy

8 ttoroe Wytt«raro>y

• tmematcieinem s Hare Stolen

s Ю GUD1

* Intemaltlement

8 Kam«RoM_t s V GVO2

a Attrbuw

8 (tome

t HMM

  • 2 Brate

  • 3 Lm*e tntwnaEwcnani

ж Kame

= 10 GUC3

A ftotoAeqvvvmanto

J s RetBa*eR«eCto»»PathMy₽n>oe<tySe*o*Cia*«LbGA>®etry

* MappKifObjact

aj AttributeMamHIappinQ

HOhi BtoM

8 SotoAnrtovtoNanw 8 SystomUnHARributaltoma Неф! W4№ length

* RotvCtonslib

a №me tfyProoertySetftoteCbML*

A ItoteCtoaa

ж Name

Geometry

Attrrbvta

я MM

W40> Lan ph

«InalanceHerarchy Name*14yHiefarchy*>

«InternalEtemcnt Нггтс=*3ийоп’ tD^GUIDV*

«tntemsEJement Narrte^’Rcbo(_1″ IO=*GUID2*>

«Attribute Name=*H6he”/>

«Attribute NaWBrerttfV»

«Attribute Name=*Lflrtge*/>

«IntemetEloment Namee*IE* ID=’GUIO3‘>

«RcteRequkementB RefBaaeRdeCiesaPath ^MyPropertySetRoleClaeetJbriSeomeay/>

«Mapping Object»

«AttnbuteNameMappng Rc*MrtnbuieName=’Haght” SystemUraLAltnbuteName=”Hdbe’/>

«AttributeNameMappirig Rc*eAttritxrteName-“Width’ Syst4rt4Jn’lAKrit№te№rnerBreM7>

<Attnbute№meMapp<ng RoteAnnbuteNamfro’Length* SystemUrriAttnbuteNamee’Llnge*/^

<A1appingObject>

«.’intemalEkement»

«rinlemaiElement*

«/IniemalElement»

<rinstanceHierarchy>

«RoleClassUb Name«’MyPropertySetRaieClaesLfc*>

«RoleClass Names’GoomMr/ RefBaaeCiassPaths’AulomtftonMLBeseRateClassbbtAutoinattcnMLBaseRclefPropertySBt >

«Attribute Name=’Heignr>’>

«Attrtwte Namee*WMth,,>

«Atirfiute Name»*Lengih*/>

«/RoteCtaas»

«/RdeCtesUt»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Базовая архитектура Automal»onML, а также распределение информации о топологии, геометрии, кинематике и логике приведены на рисунке А.1.

Язык разметки автоматизации

Инженерные данные

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

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

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

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

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

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

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

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

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

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

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

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

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

S

Е В

по Сей

Sequence Line

Sequence

110_Geostation IF lOO.Transport Entry If HO.WorianqCell J 120_Transport Exit

13O_Evacuation Unit

IQ -130ТЙЙ001

If] -130MER002

Puke

ffi IE Pub

S If Cabinets

Fence

Sodcet.lOOO SotkeC1000_2

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

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

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

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

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

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

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

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

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

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

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

Документ САЕХ

й

а

в Е

Б

ilO.WVriongCdl помеои UOGSTDOO 1КХТМ001 11СКТИЮ1

цокало

11015.901 •110LS.CO2

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

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

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

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

Документ САЕХ

Документ PLCopen XML

I4 til

-U06MOU -llOOSTOOO

и

(4

•nCHTMWl

е

Г<

«П0МТКЮ1

G

i:i

в

(4

И1

Ii1 14

-U0Re_10Q • UCRB.tOOi «11Л5.001 •110LS.002

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

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

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

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

  • – соотношения -родитель — потомок- (см. 5.6.2 и 5.6.3):

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

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

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

■ соотношения наследования между классами системных единиц SystemUnitCiass;

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

– соотношения наследования между классами интерфейсов Interfaceclass;

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

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

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

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

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

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

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

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

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

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

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

$де«тиыкам«С» г я««*м£пмиг<1>

s eeftaeeSyatemUartPalh UySrtttnUNiLbiCJtoMJ

* ЕнетаамеПке

г Ямпе

Start

s Ktie«»Kto»tP»thAuto<4t0OWU<ttr1K«Ci»MlV..^|MM>rf8M

* MamalElemeM

8 Mama

= Ю

*MemaKiement

₽ICI __________________________________

GUO3 _ _ _

* MemaCieflwnt

s Name

s D

«IntamaKlenwM

1 name SavdOI ___2

= 10 QUO* ______ ______ _

]Uternakiterfac« ____________________________

8 Hanw СммеФТ

а 1НЯ4»еС1а*»₽е№Аа1мШмМтк»мС11МЬМ..«|М*>Мка

imernaiUftk(t> : Name

1 NettfwrelMi

s RefPartnerSideA s Яе*РапмтМе8

GUO2 Start GUOaCMMNOt

Соо»»оии*мв «хмыгаар —жнппар*. I vc»ar^ene»>-oe Nwwewwe* ceaaao

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

«SystenuMCfetsUb Nar.e=’MySystemUr*Lfc’>

I «SyslemUntQws hme-‘C_Robot*/>

I «SystemLhtOass №rnee*iC_RDbat_1 ’ RelBs$eClas$Psthn*MySysternlJn8LiUC_Rot)orA «/SystemUnSClassLfe*

Рисунок A.7 — Описание примера соотношений библиотеки класса системных единиц SystemUnilClassLib на языке XML

«Inatancemerarchy Name«Reia«naEMmpie>

<lrrtema®emerrt Name»’Statkn’ ID«’GUID1’>

<lntema£tam«nt Name-Rcbt” ID>*’GUID2′ R«®«*Sy»l»fnUnitP3t^=’MySystemUnrtLit’CwRcbo<w,r> «Extarnatintarlace Name-Start Ret8aseCias#Pech-“AuiomatiQnMLinterfaceCia9»LiO’ /Signainterface’ –

«intemalEtement*

«IntemeBement Name-‘PLCr ID-“GUID3“>

«IntemaiEtement Name=BoardOT ID-‘GUID4*>

«ExwnaiinMrtoce Nan*=’ChanneW1‘ R^Bae«Csas«Patha’AuumatjenMLlnt»rtaceCiassLib’..;S»gna)tnterface7> -Inter nafEtement»

c4ntema€rement>

«InlematEtement Namee“CcrweyDr_r IDa“GUIO5*>

«intemaiEiemant Name=’Moior’ IDS“GUIO6″‘>

«IntemaiElemenl*

«IntemdLrfc Name»”HardwareLW<r Ref₽erinerSideA-“GUtD2.Start” RefPartnerSideB”‘GUID4:Channel0r>

< •VitemalElamant-‘*

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

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

А.2.1 Общий обзор

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

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

Понятие

Описание

AutomationML Port

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

AutomabonML Facet

Фасеты AutomationML Facet позволяют хранить подмножества атрибутов и интерфейсов объекта AutomabonML. Они могут рассматриваться как представления конкретных аспектов инженерных данных

AutomationML Group

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

PropertySet

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

Process-Product-Resource

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

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

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

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

А.2.2.2 Пример

Рисунок А.10 содержит пример понятия порта AulomationML Port. Объект Station» (станция} включает подобъекты “Conveyorl» и “Conveyo<2”. Оба подобъекта имеют один объект порта каждый. Объект порта содержит набор интерфейсов, а также стандартный интерфейс «Connection-Point» (точка соединения), полученный из класса интерфейсов AulomationML InterfaceClass «PortConnector». Данный стандартный интерфейс может соединяться с помощью внутренних связей САЕХ InternalLinks. Рассматриваемое соотношение означает, что оба порта соединены друг с другом. Внутренние связи субиктерфейсов подробно не описаны е настоящем стандарте. Рассматривается соединение только абстрактных точек ConnectionPoints. Кроме данного понятия, язык AulomationML допускает хранение каждого индивидуального связующего элемента, расположенного между субинтерфейсами.

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

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

toatMxetBeidthy _________________

8 time PMExampte л intetnMftement

s lUme Stance

= D ОСИ

■* Inter гнВепмм

з Itomc Comeyotl _ з Ю 0UO2

e Met MlEtement

I 3 Name 3 IP A Attribute

Port 01ЮЗ

= IlMite

ж ЛПгЯмЖеОидГуре <) Value

Orecfcti «««trng OU

Externa* nterf*ce($>

s Name CcmectnrPoH OuttXtl 0U₽d2

  • 4 Inputt

  • 5 Input?

S RefBaeeClMsPdh

AUcensb^Mjrter bceCtossLbZ ^ortCorvwctor

Ааамкгмлегшвамвиу.. Slgneirtertece JUorMttcnMUrterleceCtoMLto/. eiyMrtertace AUortetKrWrteriecaasesLtoi’. j&grMriertace ОДгмМпММегШКШсеиь/. «igneMertece

* RoteRequk«ment«

рывамЕШесиееРлт Auo*Mtxr>k<aM4RcMa«*sLib/. **crt

  • * RotePeqrni ement s

J s Ret’BaeeAeteClMePathAutcrnetorirlBeecAoloCescljb/.jRemree

Met iHdement

ж Itome Corweyor?

s » GUM _________________

  • * Mernrinement

з Name s to d Att> Me

Port OUM

к iUme s АШЯиЯсОЯаГуре Ovdue

OMcflon

ХЛЯГТЧ to

Eider Mint ert *c*

z Пете СотлесйогРмгК rtputf hpU2

  • 4 OlKUI

  • 5 Output?

S RetVaeeClMePath AacmetKrMJrteHeceOstsLto/.^oriCcnnect» *aor»et>ori*jr*ert»MaM4Ub/. jste^Menact AUorae»or*RMwHceCto»aUW.. JSIpneMartece AUcnMcrMnertBceaM$U>E..j5ign«kteriK8 AUaMtKnMLHertaceCtouLb/. ЭДпаМеИам

RoleRequR entente

s IM8M«Roi0<^»aP«№AaomMcrMLB*MRoieCieseUbr. JPcrt

* ReteRequiiemeM*

J s RetB*eeR<4eClase₽iHh AiXcmctrrM_BiaeRoteQsMlJb? Жеимсс Met tMUnh i

s Name s RefPartneeSkleA

1 Li 0LO3C«V>»Ctty*QM

z RHPatneiSldeB OUDS Covwcum*om

Рисунок A.11 — Описание понятия порта AutomationML Port на языке XML

<»BtenceHierarchy /torr^TortExerrple’»

«irteneSemert Nsw”StMion” l>”GUD1’>

«InternaEtemert Ma^<?®*Conveyori” D»”GUD2*»

«ktemaEtonent t4we=Tcrr *>”GUD3’>

«Attribute Na-*e-Direction” АйгСяЛ0МаТудо«*Х8:«НтдГ>

| «УЛ»’-0и(<Л’аиб»

«’Aflrfcule»

■cExternemerrace Mane- ’ConnectlonPocit’ RetBaseC^tPatr»*’AutoHMUofMLHertaceaas$lJb/.. iPortConnector’/-«BdemeMetface H*r*=‘OUputi” Re’Ba^ias$p«r>=”AutotfiationMLJri(erlac*CtossL»5J.. /stgnerterface «BdernetntertacB t*wo-“0ujx42” Rer6«seCtessPatt>’,AUonwrticnM.MerfecBCIas3Li>/JSigneMrterfece”‘-<Де»гхЛИег1г«еМяпе=’1при(1’’ Rc!0a$eCtawRalh-’AUomAcnMLrterfeceC2a5SlJb/./Sgialrterf8ce’> «Esternalnterface ?ten>e-“hput2′ RerBaseClfts$₽attw*Automet>onMLHerteceaa&sLib/. JSEpeMerface’,-«RdeRequfremnts RerfMseRofeOetsPatbo-AtAorrteeonbt^eseRoieCiessLis/ Port’/»

»#itemneemert>

«RoteRe<jUrem«rtsRefBeceF’oleCia5$₽8lt-r*“Autom8tionMLBaeeRcfeCte8StJo/..Peeource‘’A

«Aiternei Berne rt>

«WemaEtemert I’lew’Conveyor?’ О»ч01Ю4,>

-•rtemaEiernent bMwTorr 0»”GUD5’*

«AUntMe Ыпп? ‘”Direction’ AttHtHteOetaType-’xsrsMV** | «vatua*ln<A/«iue> «.’Anrtoute*

«Extemabtertece Чэтг=”Сопг*сИопРапГ RefB«s<*CkasiPatn>”AutorMtic>fMLMertaceClassLjb/.. JPortConnoctof’v.

«BderneMerface чмпе- ‘Inputl” RcfDeje<Je54Path*’Au!onwtionMLt-twfaceQas5ljt3/../Sgna»rterfoce”‘> <Bdefnetntertece?lsme»”lnput2’RefBe$eCI»£ePaih«’AutometaonMLHerteceOa$sLib/../S9>aMerface”» «ExlemeMerfece Hame^OUpUf * RetBa$eCtes$PeCtw*AutO)nationMLIrrterlaceCia8sU>/…/SignMrtertece”> «Bdernabtertece Мяпе^ОириЗ* RetBeseClessPethv’AutornationMJnlerfeceCtessLJtf .jStgreThtertace “<> «RcleRetfjiremerite ReiSa%eRoteC)stsPatb«”A<lMNAonlrLBaseRoleCie8sU)/.. Port’/» <A4emaiBemert>

«RoteRecMremerts RetB«?eRoieCia$tP9th»HAulonMtiocMLBMeRdeClassLib/.jResource*>*

«Atrter гжвегоеп»

rtntemaLnk N«neH.1″ RetPMner£>5eA«*<XJK)%Cefyw<^riPoifr RetP^erSr^e»,OUD&Corw)KtionPart’^ ^WetneElemerit*

«dnsten cartersrchv>

Рисунок A.12 — Описание на языке XML понятия порта AulomationML Port

А.2.2.3 Моделирование порта как пользовательского класса системных единиц AutomabonML SystemllnitClass Пример описания логъзовательского класса системных единиц SystemllnitClass «myPortClass» на языке XML приведен на рисунке А.13.

* Зуаепкмси**

s Шлм mr₽ortCJ»M

«. АШКХМ -J)

з шт» (> van*

  • 1 D*«ct<on ПОЛ

  • 2 Ctte^ory WKerMfiew

    1И«гп>ам«(1ж*

Bvn* Comecror^oni

fteffacrCUtcPtth AUWMtorMUtelstcCeeSJW .PoKarnecko

<«ФГ1 wMJOiotiCUoo

foffloteCiMoPoth AixonMorMLBiMRoloa*o«LM..eoit

cSystemllniClBn t4arr«s”myPortG»sB’ > «Attribute №me>*Dir8d0ri> | «vaiue»inOU«iVelue> «/Attrttute»

«Attribute t’kw-Cetegory*»

| «vake»MalerWFlow«A/alue«

«/Anrtoute*

«Extemebitertece ^лпс-‘СолпесЙогРопГ’ RefBeseCtossPath-‘Atf orrMtorMJrtertecoClMslJtf…^ortCornector,A

i «SupportedRoteCtass RetRoteOassPams’AtiomakxttiitLBaseRcieCtosslibA Port’/* <>SystetflUnitOass*

Рисунок A.13 — Определение пользовательского класса портов AulomationML “tnyPortClass»

А.2.3 Понятие фасета AutomationML Facet

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

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

Описанная подгруппа атрибутов и интерфейсов относится к определенным инженерным аспектам. Она может хранить информацию о соответствующих инженерных решениях или шаблонах. Синтаксис и семантика указанных имен (значений) атрибутов в настоящем стандарте не рассматриваются. Они интерпретируются с помощью внешних приложений, учитывающих синтаксис и семантику соответствующей информации. Таким образом, для работы указанных алгоритмов и выполнения задач автоматизированного проектирования нужна только информация о фасетах. Допустим, что атрибуты объекта включают имя шаблона кода программируемого логического PLC-конгроллера. а интерфейсы описывают входы’выходы данного шаблона. Получается, что алгоритм генерации кода PLC-контроллера, учитывающий семантику рассматриваемых атрибутов и интерфейсов, может генерировать код PLC-контроллера из имеющейся информации. То же самое происходит и с HMI-шаблоном. Вышеупомянутые внешние алгоритмы, а также семантика соответствующих атрибутов (интерфейсов) в МЭК 62714 не рассматриваются. Выполнение задач автоматизированного проектирования осуществляется за счет совместного использования понятий AutomationML Group и AutomationML Facet.

А.2.Э.2 Пример

Рисунок А.14 разъясняет понятие фасета AutomationML Facet на конкретном примере. Объект «Conveyorl» включает атрибуты «А» и «В», а также интерфейсы «X» и «У». Назначенный объект фасета -PLCFacet- ссылается на атрибут «А» и интерфейс «X». При этом назначенный объект фасета «HMIFacet» ссылается на атрибуты «А» и «В» и интерфейс «У». Поэтому оба фасета обеспечивают фильтрованное представление для имеющейся инженерной информации, необходимой для выпотения задач автоматизированного проектирования.

Пример применения: атрибут »А» может быть ^ориентированным на продавца» именем специального шаблона кода программируемого логического контроллера PLC. описывающего функциональные возможности объекта «Conveyorl». Интерфейс «X» может быть именем входного сигнала, используемого данным шаблоном кода. Атрибут «В» может быть именем специального шаблона человеко-машинного интерфейса HMI конвейера. Интерфейс «У» может быть сигналом, представляемым данным человеко-машинным интерфейсом HMI. С учетом данной информации рассматриваемый программируемый логический контроллер PLC (человеко-машинный интерфейс HMI) способен генерировать инженерные решения автоматически. См. пример в пункте А.2.4.4.

г ВжиКаавлпа*

• UiwBnmi

s И—е<агкда1

s В «X» ___________________________

л Aaitiine ■ В _________________________________________

8 ВММ

1 А

г е ___________________________________

  • • СЖечч—|П«К . ________________________________

    Ч С*теуоП~|

г вам 11

  • • МапИНетмЩ

s Хам АСЯМ

IO CUCO

1 А—»м»| ]

«tMMMlUt I «Нам

I 1X

“ *•**•»*-Л-**»

  • • mmiuOhmm

= нам МГ«м

8 В очсо

•iMMHW

г Man*

1 А

I В

Iemwwwiiu

8 Bane

t V

* lk«itMa<*iaw»nl»

J а ммим*свм№аВ|Ша(вмип»мм*ам*и>’-г*м

a ItoMtqta «амнк 1 S Кнаи«ММ1м«Р«МА4оМаАКВш<М(а«««иЫ Лможе

Рисунок А.14 — Пример фасета AulomationML

MnstenceHetarctiy Unrre-TacetExample’»

«HernaBetnert Narr>e«Xonveyot1” ID=’*GUDI”»

«Attribute Meme«HA“/>

«Attribute Nere-’B’V»

«Cxtemetrtertace Neme*,HX”r>

«Cxtematrterface Name-

«tnterneEiemenl Neme»’PLCFaceT ID=’GUD2“»

■ «Attribute Name-’AT* j «EMernaMerieceNeme»’X”A> j «RoteRecMretnente RetBaseRofeCl&£s^Mha>AutC(nai>ofiMLBaseftoteC>BssL£J..jFacet”fr «Antetnei Bement» «interneBemert Name •‘HMFacet” C~”GUID3“» ‘ «Attribute Neme*”A7> ! «Attrfcute Nemea’Bf’fe

| «externaHettace Namea-Y^

j -RoleRecMrement» RefBaseRo^!atiPtf>-^AjjtometionMJJaseRoieCles8Lto/..jFftcet’V»

•sArtemeiEWerta

«RoleRequrernents RefBa£eRcteC!es$Peth»,AutaMt0M.Ba*eftoleClessLb/ .Же&ожсе*/» «jhterneEiemeri»

«AnstanceHfervchy»

Рисунок A.15 — Пример описания фасета AutomabonML на языке XML

А.2.4 Понятие группы AulomationML Group

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

Понятие группы AulomationML Group позволяет отделить информацию о структуре от информации об экземпляре. Так как различные жженеркые средства {приложения) могут использовать различные представления 46

одних и тех же данных, может оказаться полезным хранить данные представления раздельно. Это достигается за счет использования понятия AutomationML Group. Структурирование идентичных объектов возможно в различных иерархиях.

Путем определения атрибута группы «AssociatedFacet» (ассоциированный фасет) данная группа может быть ассоциирована с типом фасетов, характеризуемых унжальным именем. Это позволяет внешним инженерным алгоритмам автоматически идентифицировать рассматриваемые объекты (и их соответствующие фасеты), чтобы получить требуемую инженерную информацию. Кроме того, язык AutomationML определяет ролевой класс AutomationML RoleCtass «Group» (см. 6.4.3). Нормативные положения приведены в 8.4.

А.2.4.2 Пример

Рисунок А. 16а) описывает понятие группы с помощью структуры «Station», содержащей объекты «Conveyor!». «Conveyor2». “Robotl» и «PLC1». Объекты «Group!» и *<Group2~ описывают одинаковые данные в разлитых иерархиях. Объект «Group!» определяет структурное представление только для конвейеров. Объект «Group2» отображает только объекты, относящиеся к программируемому логическому контроллеру PLC. В соответствии с МЭК 62424 (подраздел А.2.14) формат САЕХ обеспечивает хранение таких пересекающихся структур. Рисунок А.!6Ь) содержит интерпретацию данного примера на языке AutomationML. Рисунок А.17 содержит соответствующее описание на языке XML.

HutaKcMaachy

S Man» Owtfevn*

S ГГЦ] GroupExample

1141

•141

Station

С] Conveyorl P Conveyor2 P Robotl

Epuci

Group1

Conveyorl i Conveyors

Group2

i PLCI

c Han* SHOT S О АЖЛОО 4 InUinKBwMtK >

I Comnvt

J 4KC1 HeiadnemeM

= ИсанОо<Н

» Ю ОЛМ

« kaeinaDemcM-S)

1

г a»««r«2

J ■ ьпм*м*скыгм kaeindDeniert

s ШаиОовТ

S D 0X00

»> bMn^hanenl >

l HXt

8 MBMelUteaMtPabXUCHMtnbtaaiefefcChaabUaMnrMBmiWOm*

а) Иерархия b) Сетевое представление

Рисунок A.!6— Пример группы AutomationML Group

-*а1«пмн«*сггу ‘мсп^х>«цСхаг0»*>

: «кггиеигел uw-steon’ c-oucnor*

: I <ПвггиВел«г1 г*ме.’Свп«ус«т С-‘OUWf»

1 «иггиеагмк (’•’GUCQ’b

: -МвлмвопеН Пэпе- ЯоЬоП ‘ C-’OUDJ”•

! ^г*еямеси«ЯНа*>е*-Р1Х1’С»’ОиО4’^

•ПеткВапал*

: -«етМЭжтел нмв»”0*М»1* iC-WWOtr*

: <Иетаеепелгм^1Сепу«уси,К8е*м$тяепим₽мг1»*оиси*№

‘ «ИелмВвпеЛ itoner’Cemeycr? ЭДВ»$«’й;1*<гимГа№**оиР2г/>

: <Ао>еАе9мес<г4в Я««9ог<КвЪ*7Ъ««Не~*Ди1амВопМЛ»«сМеОм*имМомамсее>1еКо*КОгс11«*** ■ -Малчгвелен-

; dM*<n«Ela>rw4’t»ne*’4ret«2’lC>.*QUC300′-

| I ilTUtlTioaf и ti ntin ijijtul:fn 1Гн111»‘А|ГаинИнй1 neHTijOtiil ПГйНп>11|гКГП1ОП0ЮГи]ии’

: ‘Мепиеммл*

Ufcel«nc«4v*chy>

Рисунок А.! 7 — Пример описания группы AutomationML Group на языке XML

А.2.4.3 Комбинация понятия группы и понятия фасета

Пример возможной комбинации понятия группы и понятия фасета приведен на рисунке А. 18. Показанная иерархия экземпляров InstanceHierarchy отображает объект языка AutomationML “Station», включающий объекты AutomationML «Conveyor!» и »Conveyor2». Указанные конвейеры имеют два атрибута и два интерфейса каждый.

Объект языка AutomationML «Group- представляет собой встроенные группы «Group!» и «Group2». Обе группы ссылаются на объекты конвейера, но имеют различные ассоциации фасетов.

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

Рисунок А.18 — Комбинация понятия группы и понятия фасета

Рисунок А.19 содержит описание на языке XML. соответствующее примеру, приведенному на рисунке А.!8.

•JnstanceHerarchy Нэгге* ГеювЮгофСотЫпаЬоп”*

«Irtemaeemert Nwte^ConveyorFC-‘GUM’’»

«Attribute Naree’A”/»

«Attribute Name®’®*/»

<E)dernoMerf«ce Name>*X*fr

«EderneMetface Neme»*Y”fr

«InternaEtertteri! MerweTLCFacet* lt«”GIJD2’>

; «Attribute Neme«HA’>

i «£xterndHertece Nwne*”X”A

• -RoieRectwrerTerts RetBewRdeQa^PMt»’”Aut«nwtenMLBeseR5leCtos&ijiWAuanat»nML0swRoieEecet”’ • <4ntema»Elemert>

«HerndEtement N’rrw’fMFeceT lO’OUDS*»

t «Attribute Names’Vjb

; «&derndirterf«ce Nams-‘VA

; «RoteRequremerte Rei0a$eRote(>$3₽a!h»”AuttimetlonML0aseRaeCia$$MVAUomatJonML08selWeEacet■••« «jWemeiElemert» «RcteRoqurernerteRefBeseRoleCbssPdh^’AutomBtiorMBeseRDtoClasstjto/AdoffiebonMLBeseRolsAesource’’*-<Ateme£lemert>

«IntenwIBemert N»ne*’’Corweyor2“ О ХЭ1М>4^»

«Attribute N8tnes”A”z»

«Attribute Name®’®*/»

«bdemetrterfaee Name=’X,/>

•Edemetrterface Nan>e–’f7»

«HerndBement l-k^-‘H-CFacet fO-’OUDS’»

! «Attribute Name®”A”>

  • ■ «Externalrterface Ыатев^СЛ

! «RcteRequremects RetBeseRdeCias$Path»”AutometiarMLBaseRdeC1ei$sljb/AulOffid)onMLBaseRdeiFacef’■’-«MemdElemeri»

«bternaE iement №-ne=*>MFecer iD=*GUO&’>

! «Attribute Name*’®’/»

< «fxterndHerface Name-VA

i «RoteRequremerts Rei®a3eRoicC>e»3₽atb«”AiicnieHoftMLB9seR3ieClassLi&/AutaretionMLBaseRote>Pacet’’‘-

«ЛК emel Element»

«RoieRequr everts RefBe$eRdeCi»$$Peth>,AutonMtio<M£a$eRoteCla$$ljb/AiAcrrietionMLBa$eRoteAtesource‘ «AtemefElemert»

«tntemsElement N^r^’Grotb’ D»“GtJDr»

«Interrmeement s»w=”Groi<i1 • o»‘iGUCe’»

! «Attribute N«re>”AccecfatedFacet”

  • ■ i <Vdue»₽l.a,aceUA’alue>

! ^Attrbute»

  • ■ «HerneBement Мат*=”Сопуеуог1” RefBaseSvsl6<4JnePeths’G(J©1H

; «MernaEtement 1′!атс“”Сопувуог7′ Re’BajeSYSter4Jn«Peth-‘GUD2’.,>

; ■‘RcieRecturanerts RetRaseRdeCU»sP«th«”AijtaMtionlLBMeR3leCI«iMl*/Autofnat>onMLBaseRo<eA>roup’

«4rrtemeiElemert«

«WernaEtement Name*’’Gra^2* £|=”CUD9’»

; <AttnbuteNaffe«”AccocietecFacot’»

I | «value »H<ea<«>vebe>

‘ «/Attrtoute»

j ‘dreernalBemert НаггА-”Сегмеуег1’ RetBaee£yatemlHePeth-‘G(X>1*’/>

| «HernaOemert Name-XonveyorZ RefBaseSydemU^eth^GUDZA

; «RoteRequirements RerBaeeRc^assPdtn’AutomatioriM^MRcteCleeaLbAutornettofiMLBMeRoie/Group*/»

«rtntemaHemert»

«RoteRequireinents RerBa&eRdeCiessPetha’AutoiiattoriMLBaeeRcteCiassLJb’AutoimttoftMLBMeRoie/droup’T1» «MemaEJetnent»

«JnstanceHerarchy»

Рисунок A.19 — Описание представления комбинации ‘фасет — группа- на языке XML

А.2.4.4 Автоматическая генерация человеко-машинного интерфейса HMI с помощью понятия группы и понятия фасета

В данном примере принято, что атрибут «В» конвейере представляет собой шаблон интерфейса HMI, визуализирующий переменную «У». Рисунок А.20 иллюстрирует характерный шаблон интерфейса HMI конвейера.

HMI template В

Рисунок А.20 — Характерный шаблон В для интерфейса HMI. визуализирующий переменную -Y» технологического процесса конвейера

Основанный на конкретном экземпляре конвейера, рассматриваемый инженерный алгоритм идентифицирует. что объект языка AutomationML ••Group2« ассоциирован с фасетом HMI-интерфейса. Здесь он идентифицирует, что экземпляры Conveyor! * и -Conveyor2<> являются частью HMI-интерфейса. Данный алгоритм может извлекать информацию из интерфейса HMI о каждом из двух конвейеров. Он может идентифицировать соответствующий шаблон HMI. может ассоциировать корректные сигналы для последующей их визуализации. Рисунок А.21 представляет результирующий HMI-интерфейс.

HMI result

Conveyor! .¥ Q

ConveyorZ.Y Q

Рисунок А.21 — Сгенерированный результирующий HMI-интерфейс -В”, визуализирующий оба конвейера с индивидуальными переменными технологического процесса

А.2.5 Понятие набора свойств PropertySet

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

Набор свойств PropertySet применяется как таксономия (структурированный словарь) атрибутов. Он моделируется как ролевой класс, содержащий предварительно определенные атрибуты, описывающие свойства рассматриваемой области применения, и получен из стандартного ролевого класса -PropertySet- (см. 6.4.13). Данный набор включает список синтаксически и семантически согласованных атрибутов. Наборы свойств собраны в библиотеки ролевых классов.

Объекты AutomationML могут быть ассоциированы с одним или несколькими наборами свойств. Для каждого набора свойств создается отдельный дочерний объект типа САЕХ IntemalEtements. который назначается соответствующему классу PropertySet с помощью определений требования роли RoteRequirement. Несколько наборов свойств могут быть ассоциированы с помощью нескольких дочерних внутренних элементов IntemalElements соответствующего объекта AutomationML.

Объект отображения САЕХ обеспечивает отображение собственных атрибутов объекта AutomationML с предварительно семантически определенными атрибутами набора свойств PropertySet. Это обеспечивает возможность импортеру программного обеспечения автоматически интерпретировать указанные атрибуты и отображать их на целевые специагьные атрибуты инструментальных средств. Данная процедура упрощает автоматический обмен данных между различными инструментами.

Также существуют предварительно определенные библиотеки наборов свойств AutomationML. Нормативные положения приведены в 8.5.

А.2.5.2 Пример

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

Рисунок А.22— Пример набора свойств PropertySet

Соответствующая модель AutomationML приведена на рисунке А.23. В левой части рисунка показана иерархия экземпляров, необходимая для моделирования трех площадок Станции 1. Каждая площадка имеет свой погь-зовательский набор атрибутов и осыпку на набор свойств PropertySet -Area-. Соответствующее описание на языке XML приведено на рисунке А.24.

User defined dtrfcutes of Station 1

Instance hierarchy

; facaMpteautancewieraeclry Аме^АМ** iCtaaai Мм

materiaforeajength mat^kaljrea.width tran*ponarea.width transportarea.length assembty*«ea.w>dth^ —

PropertySet role library

ДКее’Ыуегм {Claw ЫкМК

MappnpCbject

AttrBjhWmetiippiep asw<“b^*ee.«idtb

МпЬыШМтеМгррпр. мн«<Ыу«гм.1»*9*’ sWraan (Дам МмАы» Н MaSPwgCtftct

ЯП AsibuttttarwMsppnp’ iMiriMmJengtft В MtrtouMOTeVsppnp- та»пМп«.*№* T'<*«p<ztve» ;Да»мMaiA/ae) jHMappryObject

В АкФ^еЯмпеМарр^ vaneporierce.wUifi ял AKrbjMNwW4V’flf:ttMao<ui«<»«>gn

HcamrlrRok-CUtsi <1

GcometricDBU (CUeKPtopctySel) length (Oe»rG«*netn<Oan| Point [ChMtGeo’iifVkDjtai Angle (Claes: GeometikDaU) Deformation (ClMSsGeometrkData)

Strain | cInc: Deformation) Deflection (data: Deformation)

!ZZ

IE

■E

E

Si

ra ICImKGeorneVkDeU)

ion (CbMtGeotnetricDaia)

Mappine between user defined

Stand ardsed attributes of the PropertySet’Area

Рисунок A.23— Пример набора свойств PropertySet

«InstanceHiorarchy Namee‘Exampte ln»tancert*refchy”>

«IntemalElement Narre^’AssembtyUne’’ lD='(8b2510b4-7fcS4f54-9d09-a3197a062604)->

<1nternatEl«nent Names’StattonV ID=”{5450013S-e6a1-47c8-80c9-bee35662S63c}’>

«Attribute Names*meterialarea_length” />

«Attribute NamestneterialvMZwidth” t>

«Attribute Name=transporUrea_’*tdth’ />

«Attribute Name<*traneporiarea_iengtb’ AttnbuteDBtaType^xedoubif >

«Attribute Name>’assembtyarea_widtrr AtmtxiteDataTypea“xs:double’ />

«Attribute Name=’as9ambtyaree_tength’ AttributeDetaTypee”xe:double* f>

«IntemalElement Name^’AesemblyarM* iD=”(e08f53e5-eb0M5cB-b42M714e24dd05c}”>

«RoteRequirements Ref8aseRoieCiassPeth*’ExamplaftoleClassLlb/eeometricOata/Ar»a” i> <M>pp<ngObject>

«AttritxrieNameMapping SystemunitAttributeName»*aBsombtyaree_wtdth” RoleAnributeName**Wldth” t> «AttrtxjteNameMappmg SystemUnrtAttnbuteName=*essambtyBree_tef)gth’ Ro*eAnntxrteName=”Lenglh’ > «/Mappingobject»

<rintemalEle<nent>

«internetElement Nare»*Materialaree’ iO»*(66e360ef-d10Mb60-be63-cMb262bc470e}*>

«RoieRequirementa RefBaseRoieCiassPath=‘ExampieRoieCles3LityGeom«tncOat8/Area* t>

«Mapping Object»

«AttnbuteNameMappng SystemunitAttnOuteNa.Te=*mater1alefea_tength” RoieAttributeNames*Length” > «AttnbuteNameMappng Sy3temunitAttnbuteN«ne=’meterle4afea2*W*ft‘ RaeAttrt>uteNames‘Widm* t>

</MapplngObjeet>

«/interns IE lament»

«mtemaiEiement Nsmt^Transportarea” iDs‘*(t94i8967-cd7c-46oa-edee-eiaa52f6b685)’ >

«RoieRequiremente RefBa$eRcteCias$Path=’ExafnpieRoleCiassLWGeametrtcDat&/Area’’ l> <Mapp>ngObjeet>

<AttributeNameMapp<ng SystemunitAttnbuteName^iraneportafM.wfah’ Rol«ARributeNanie«*Wldth* > «AtMxjteNameMapp’ng SyslemUnitAttritxrteNafne=Transpoftarea_tength- RoieAttitbuteName=”Length* /> «/MappingObject»

</interna lEiement»

«■‘Internal Element»

«/intemaiEiement»

«/tnetenceHiofarchy»

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

В правой части рисунка А.23 приведена библиотека набора свойств AutomationML PropertySet. Данная бибгмотека ролевых классов AutomationML RofeClass содержит класс RoteClass «GeometricData* (геометрические данные), полученный из базового ролевого класса Base-RoleClass «PropertySet». Ролевой класс RoleClass «GeometricData» сам имеет дополнительные производные, определяющие некоторые базовые геометрические свойства. Класс RoleClass с именем «Агеа» (площадка) определяет атрибуты «Length» (длина) и «Width» (ширина) как атрибуты типа “double (двойной)» и единицу измерения «т» (метр). На рисунке А.25 приведено описание на языке XML. определяющее рассматриваемые атрибуты набора свойств PropertySet.

«RoleClass Name-‘GeometrkData’

RefBaseOassPatb-’AutomationMl Ba seRdeClasslib/AutomationMLBaseRole/ PropertySet

  • – «RoleClass Name-‘Leogth’

Ref BeseClassPdth>’ExampieRoleClassLib/Geometric Data*»

«Attribute Name=TengttiValue’ AttnCuteDataType^-xsTdouble” Unit=”m‘ f> «/RoleClass»

  • • «RoleClessName»’Poinf

RefBaseClassParh’-‘ExampieRoteCiBSSlib/GeometricData’» «Attribute Name=’xAxis” AttributeOataType=’x$:double* /> «Attribute Name-‘у Axis’ AltrlbuteDalaType-‘xs:doublc’ /> «Attribute Name-‘z Axis’ AttributeDataType- xs:doubte /> «/RoleClass»

  • – «RoleClass Name- ‘Angle’

RefBaseClassPath- “FxampleRoleClMsUb/GeometricData*

«Attribute Name*’angleValue” AttributeDataType=’xs:double’ Unit-’rad’ /> «/RoleClass»

  • • «RoleClass Name-‘Deformation”

RefBaseClassParh- *ExampleRoleClesslib/GeometrkDma*> <De$cription»Deformation of the material b the change In geometry when stress is op pied (in the form of force loading, gravitational field, acceleration, thermal expansion, etc.). Deformation is expressed by the displacement field of the mat«rial«/Descriptiw»> «Attribute Names’deformatkrnValue ‘ AttributeDataType ®*’xs:double* />

– «RoleClass Name-‘Strain’

RefBaseClassPath~”ExampleRoleCtesslib/GeometricOata/DeformaCion,‘> <Descrtption>Strain is the deformation per unit length«/Oescription>

</RoleCiass>

• «RoleClass Name-’Deflcction’

RefOaseClassPath-‘ExampleRoleClasslib/GeometricData/Deformation*> <Desonption>Deflection is a term to describe the magnitude to which a structural dement trends under о lood</Oescriptton> «/RoleClass»

«/RoleClass >

  • – «RoleClass Name®’Area*

RefBaseClassPaths” Example RoleClass Ub/GeometricOata’» «Attribute Name^’Length AttnbuteDataTyue^’xsidoubte’ Unlt«”m” /> «Attribute Name- Width AttributeOataType«’xs:double“ Unlt»”m’ /> «/RoleClass»

  • – «RoleClass Name-‘SpatialOimension”

RefBaseClassPath- ExampleRoleClassUb/GeometricDa<a*> «Attribute Name-‘XAxb’ AttributeDataType*-“xs:double” Unlt»’m /> «Attribute Name-’YAxfc” AttributeDataType-“xsrdoutrie’ Unft-’m’ /> «Attribute Name-‘ZAxis’ AttributeDataType-‘*xs:douNe’ Unlt-‘m’ /> «/RoleClass»

«/RoleClass»

Рисунок A.25 — Пример библиотеки AutomationML PropertySet в кодах на языке XML

С помощью набора свойств PropertySets экспортирующий инструмент может сохранять пользовательские объекты с погъзовательскими атрибутами и объяснять семантику пользовательских атрибутов с помощью процедуры отображения. Данное утверждение поддерживает автоматическую интерпретацию рассматриваемых атрибутов. Таким образом, целевой инженерный инструмент может интерпретировать данные и выполнять преобразование единиц измерения, используемых атрибутами набора свойств PropertySet.

А.2.6 Понятие «Процесс — Продукт — Ресурс»

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

В процессе накопления практического опыта структурирования комплексных инженерных данных технологической установки установлено, что необходима трисекция данных на ресурсы, процессы и продукты. Рассматриваемое понятие используется в различных областях, например для цифровых производственных инструментальных средств {цифровая модель производства) в соответствии с МЭК 62264 на уровне системы организации производства (MES).

Ресурсы — это цемтрагъный компонент рассматриваемой модели. Они обеспечивают производство и обработку продукта. В языке AutomationML ресурс—это сущность, используемая для производства, вкпочая установки, роботов, стамси. их состояние, оборудование, возможные сообщения и т. д. Ресурсы могут быть как аппаратными компонентами произведетBet-мой системы, так и программным обеспечением данной системы (например, система SCADA). В языке AutomationML ресурсы обычно моделируются а иерархии производственной установки, образуя ее топологию.

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

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

В каждом случае представления ресурсов, продуктов и процессов связаны друг с другом (см. рисунок А.26). Корректным назначением для процесса «transport» является ресурс -conveyor” (конвейер). Ресурс «press» (прессование) обеспечивает -scrap cubes» (спрессованные отходы). Процесс -welding» (сварка) обеспечивает «weld» (сварку) двух «metal» (металлических заготовок).

Компоненты продукта (автомобиля): кузов, двигатель.

привод, шасси

ячейка, рабочий, станок, робот)

— интерфейс;

— связующее звено;

— процесс;

—ресурс;

■<■4 — продукт,

— направление процесса

Рисунок А.26 — Базовые элементы понятия « Продукт — Процесс — Ресурс-

Для создания связей между указанными элементами требуется наличие интерфейса. Для этого язык AulomationML определяет стандартный класс интерфейсов PPRConnector (см. рисунок /L27). Положения, касающиеся коннектора PPRConnector. рассмотрены в 6.3.5. С помощью данного интерфейса могут быть установлены связи между элементами, включающие стандартные внутренние связи САЕХ Internal Unks (см. 5.6.6}. Таким образом. ресурсы могут быть связаны с продуктами, которыми можно манипулировать.

R1 AutofnatKjnMt InterfaceClassl ib

В -о AutomatiooNtBaselntertace {Class:}

—O Order ( Class: AutomatiotMLBaselnterface}

-ю PortConnector {Class:AutomationMLBasefnterface}

InterioctanoConnector {Class: AutomaoonMlBaselnterface’}

|-o PPRConnector ( Class: Atftomat»onMi8a$eInterface}j

Рисунок A.27 — Интерфейс коннектора PPRConnector

A.2.6.2 Пример

Следующий пример (см. рисунок А.28) иллюстрирует использование данного понятия в языке AulomationML Оно включает два конвейера (С1 и С2). поворотную платформу (ТТ1) и робота (RB1). Это ресурсы производственной установки. Робот устанавливает колеса на автомобиль, колеса и автомобиль — продукты. Производственные процессы в рамках рассматриваемого примера: транспортирование, поворот платформы, сборка.

Рисунок А.28 — Пример понятия «Продукт — Процесс — Ресурс

на языке AutomabonML понятие -Процесс — Продукт — Ресурс- моделируется с помощью понятия роли САЕХ (см. МЭК 62424 (подраздел А.2.9)) и соотношений между элементами (см. 5.6.6). Наборы элементов с назначенными ролями -Ресурс-, «Продукт» или -Процесс» разбиваются на пары. Это означает, что ресурс не может быть и продуктом, и процессом одновременно. Соответствующие классы ролей являются частью библиотеки базового ролевого класса AutomationMLBaseRoleClassLib (см. рисунок А.29 и 6.4).

AutomationMLBaseRoleClasslfc

AutomatiooMLBaseRote

Group Facet Port

•< ConnectionPoint

to* IM

IM

Resource

Product

Process

•«* Structure

Productstructure

Processstructure

ResourceStructure

Ио*ч ProoertvSet

Рисунок A.29 — Л>ли Automation ML необходимые для понятия «Процесс — Продукт — Ресурс-

В рассматриваемом примере (см. рисунок А.28) роль «Ресурс» назначена конвейеру, роботу и поворотной платформе. Автомобилям и колесам назначена роль «Продукт». Роль «Процесс» соответствует процессам транспортирования. поворота платформы и сборки. Все элементы хранятся на соответствующем поддереве (см. рисунок А.30). Порядок применения процессов, продуктов и ресурсов явно выражается связующими элементами, установленными между соответствующими интерфейсами типа «Order» (это не показано на рисунке, чтобы его не загромождать).

РисунокА.30 — Элементы рассматриваемого примера

Каждый элемент (в рассматриваемом примере) имеет интерфейс коннектора PPRConnectoc. Погаые представления связующих элементов представлены на рисунке А.31. Непрерывные линии — это связи ресурсов с процессами. Точечные гании — это связи процессов с продуктами. Штриховые линии — это связи ресурсов с продуктами. Схема представляется достаточно сложной, поэтому (для простоты) избыточные связи опущены.

внутренняя связь (Р1Р2)

Рисунок А.31 — Связи, рассматриваемые в примере

На рисунке А.32 данный пример рассмотрен с точки зрения ресурса. Поэтому нужны только 12 связей из их общего количества, равного 19. Конвейер «С1» соединен с продуктом -Автомобиль без колес 1» (см. также поворотную платформу «ТТ1« и конвейер -С2-). Так же как робот устанавливает колеса на автомобиле на конвейере «С2». робот -RB1» соединен с продуктами -Автомобиль без колес 1». -Автомобиль с колесами 1» и -Колеса 1». Дополнительно конвейер «С2» связан с продуктом -Автомобиль с колесами 1 -. Процесс транспортирования «Транспорт 1» связан с конвейером -С1-. Процессы транспортирования «Транспорт 2» и «Транспорт 3» связаны с конвейером -С2». Процесс -Сборка 1» связан с роботом -RB1». Процесс -Поворот 1» связан с поворотной платформой «ТТ1». Связи продуктов с процессами (точечные линии на рисунке А.31) могут быть получены из других существующих связей. Данную блок-схему можно произвольно поворачивать. продукты и процессы блок-схемы можно произвольно перемещать.

—■ PPRConnector;

  • — внутренняя связь (RP1);

  • — внутренняя связь {RP2),

  • — внутренняя связь (Р1Р2)

Рисунок А.32 — Рассмотрение примера с точки зрения ресурса

На рисунке А.ЗЗ приведено дерево рассматриваемого объекта AutomationML Внутренняя связь IntetnalLink между конвейером «С1 ■■ и процессом «Транспорт 1» вынесена отдельно.

IH

g Г|ц] Exampte.lnstanceHierarchy ВИЦExampte_Plant {Class; Role:Cell) H IKJ Resources { Gms: Role: Resource} ВПЕ1 Cl {Class: Role:Resource} -4 PPR {Gass: PPRConnector} -• E ПЕ1 TT1 {Class: Role:Resource) -o ppr {Class: PPRConnector} E I IE I RBI {Gass: Role: Resource) *4 PPR {Class: PPRConnector} eQE C2 { Gass: Role: Resource} •o PPR {Class: PPRConnector) В ПИ Processes {Class: Role:Process}

intemaiunk~|

БГ1Е1 Transport) {Gass: Role: Process) PPR {Class:PPRConnetror}—В HE 1 Tumi {Class: Role: Process} PPR {Class: PPRConnector} E |IE | Transport {Gass: Role: Process} -4 PPR {Class: PPRConnector} E ПИ Assembiel (Class: Role: Process} -o PPR {Class: PPRConnector} E ПГ Transport? {Gass: Role:Process} «4 PPR {Class: PPRConnector) В ПИ Products { Class: Role: Product)

ЕПЕ1 Car wchout wheelsl { Gass: Role: Product} •4 PPR {Class: PPRConnector) E ПГ1 Wheelsl {Gass: Role: Product} «4 PPR {Class: PPRConnector)

В [IE ] Car with wheelsl {Gass: Role: Product) -o ppr {class:PPRConnector)

Рисунок A.33 — Пример построения иерархии экземпляров InstanceHierarchy на языке AutomationML

Соответствующая модель на языке XML приведена на рисунке А.34. На первом уровне примера приведены три базовых элемента (’Ресурсы*. «Процессы*. «Продукты»), моделируемые как внутренние элементы в формате САЕХ InternalElements.

InteriMlBement з Наше = Ю

Example ____________________________________________

GUD1

inter naElement (3)

s lUme s K>

1 Resources GUd2

О tarternalHement

Intel nalQement (4)

з Нмпе

= Ю

1

C1

GUD3

2

TT1

GUM

3

RBI

QUIDS

4

C2

ouce

2 Processes GUO7

J Products GUD13

4 InteinalSemeiittS)

з Нмпе

  • 1 Transportl

  • 2 Turrrt

  • 3 Transport?

  • 4 Assemble!

$ Transports

= 0 omce__\

GUD9 GUD10 GUID11 GUID12

a’ Intel ivtlElement (3)

3 Iknte

= D

1 Cervrthout wrtieeisi

GUI DI 4

2 Meeisl

GUDIS

3 Car win wheeisi

GUD16

Рисунок A.34 — Пример формирования внутренних элементов IntemalEiemenls

Ниже объекта «Resource» расположены четыре компонента: два конвейера, поворотная платформа и робот. Они также имеют тип ■■InternalElements» (внутренний элемент). Данные компоненты имеют наружный интерфейс (коннектор) Externallnterface PPRConneclor. Они назначают ролевой класс ■’Resource». Процессы и продукты имеют интерфейс, их роли распределены. Для организации связей между элементами объекты IntemalLinks обычно располагают на одном уровне как самые главные базовые элементы. Рассматриваемые связи показаны на языке XML на рисунке А.35.

Inter па№пк (12) з 11,-мпе

  • 1 С1.Т1

  • 2 TH.Tul

  • 3 RB1.A1

  • 4 С2.Т2

  • 5 С2.ТЗ

« CljCwWI

7 TT1_C*W1

S RB1.CWW1

Э RB1.W1

IS F®1_CW1

  • 11 C2_CwWI

  • 12 C2.CW1

s ReTPMinetSMeA GUO3:PPR GUD4:₽PR GUD5:₽PR GUD6:PPR OUD6:PPR OUD3PPR GUD4PPR GUDSPPR GUD5.PPR GUO5.PPR GUCXPPR GUD6PPR

з RefPjftnerSkteB

GUD&PPR

GUDSPPR

GUD11 PPR

GUDIttPPR

GUD12PPR

GUD14:PPR

GUD14PPR

GUD14PPR

GUD15PPR

GUO16PPR

GUD14PPR

GUD16PPR

Рисунок A.35 — Пример организации внутренних связей IntemalLinks

Полный обзор понятий в рамках рассматриваемого примера приведен на рисунке А.36.

<кмтаЕ’«т*”1 Напг-Емлчйа.РИШ’ С-ЧИЛРГ’

‘*Мат»‘Юат»М ‘Q-nt-’R»»WC»«’ LU*’GUOe‘>

S>’GUO3‘>

! <£AemdW<rfxaM>mee-ppR’Рв1В»;всзиРк>’в*ЛишнШ*мимИ|С«С1*м1£/ ^РЯСмп«еш*>–

I C*6t«tBnbCtoiP*<r>-‘A«to<nakO(MB*MR<teC1«MljV jPmmkcV-

*КМш*Е1«пм1 МыпахТП’ i№*GUCH’>

! <g<le<nam*ff*c« HH”ff»’₽₽A’ Kv№Mti:«e4₽*t’>»*AutoM>0″MUm»iiK«Cl*e«lA’ Л’РАСвтасйГ -I <я»и»»|1И1«ли 4*E4»fAji«CMu»’>4nr€*Mcm«K<MSaMRtfeCiif4bV, «имиа*’> <Л«М»ае<вгег<>

«ишпаешпж Kimes W itfc’GUW-

| <£rtemsiW«if»e« Mw»rsPPR* R*IB3:eClaKPMWAiMMiaaMUffl»iiie«ClMa«/ ДОАСамасмг*-‘ I ‘•R>«i-S->kCs»<»f,’!»-‘AMonn*onMlB»»»W»CI»wLV *HooW’>

<>INa>naE4nwqi>

‘HumaEitmwa N«m»«’C2*<№’0UC6*>

1 ‘£<iemdN«ilKe Hm-c-‘PPR’ R4l&>s«t>atsPa$»*’Mtaawbo*MUmariK«CI»$elb/ ^PRCatnertar*/»

I <Я4НЯейаммаЯ«Ви«Я4К<ииРде*Адемш*<ВшЯеИСииЬаг

c’licamaE’Mw*’*

‘R«iaR*i|ui«ina<H А«4<»41>а*а*><г>м№’4Ш!амПмЫ1ВшШаС1ыаиь> ЛЬмсика’*’» <.Ъ|»<пЫЕ>><п«л4>

<H«tnMBam«nt 1<*п4-‘Рпс«мм’ >D=‘GUO?’>

TranaponV <С“-*виСв”‘

I <елатмн«|«каН»<«т-,РРА’R«№»ieUs!3Pat'<«’AiKBMmMUma'<»c«ClMMiV >PPRCa«aat»*’.-> 1 -RsitetviiiNNnuAieMtAtit’CMtPii^’AMMMWfMeeNRMCumjV-jPxmiv* <jl<e«maEterr«nt*

<W«in*&«enatt Mmas’TumT IfcGlIW’

i <ЕИеп>УНЖ«е»М>та*’РРй*|;\>1б«>«С»*^ааь>’А|М1м<1в>»Мит*й««ааа«Л/ ДОПСмпа’йг’А j <Я«1аАа*1<чт<М A«£ut<Ao>tCLM«P4*n^’ArtcmewiMLBa**RcleCi**aLA/ Pwca»»V>

>wiu ■ *Trwnpcfl?‘ <O‘GWW0″»

| ‘EnemtiNtrtactNmsrFR’RtiBaiaaat.Paf’SMKMataiionMUfflafeciClMKb’ jERRCatnac**^ I ‘flotsRewnwBtnt» SeBisrPaK k-njTjffT-‘AdcmatorMLBaseRtieClaselA/ *<acaa*7’ clrcamaEiKr»nt>

»;»m«“’A«aembM’ ©•ЧИЛИГ»

I <£<1»m»IWerf«c*»lini»”P₽R’ P-ilG«««CUMP«t«>z*AuMM«nMUiil«AK«ClaMLb/ ^PRCaanatWz> | *fe>KA««u(4«<»c<t* 0«6м«А«КСКН’(‘>”’-‘АистмоНМкВи»Йс«еС1<юЬЬ/ jPiecaat*’-«Лн*паЕ1*п*л<>

<hMm*Eicnt«M Mme**Trttnpo<t3’ib*’GUt>l2′>

I <&n«minirtirK«tiwM.s,RPR‘ ^fB^ec^uFiis-‘AuwewiKeMUmartKaCUwU/ ^рнсмпкйг > I ‘RoiaAawaawttaSaeHaftoMCutcC’jm^’AdcmalofMLBattRtfaClmLtf jFiecattV’ olrUmtEXment*

‘RtfeRaiufvmatii P«^»:«PnvO>::’iih-‘Autoawi>o«NlBasin»toC>MeUV JPiMt«sV>

■*l«n«Eilw<rt >

cfmeraOaewm >!»”>»-‘PwducH’ O»’GWM3‘>

<W«ma€WmM ’UmccWwahCU ММаГ i>=’GUIDI4′>

I <Edam*Mt<(K« Mina*’PPP*RaeaxCtoa«H№<>’Aulom«i0M(JnierficeOH8U^ /FPRCaanectM*1 ■ I «RottRa^irwiattaPrtteMRriaCiM^aiM’JUtwIniMlBaaaRtHaattaLtf jEndKiv» <1««naEKnwrt>

<W«n»£u<nau гм-<и«ЛМ*а1аГ O’GUCflS’»

| ‘ExwiMtaaftKt **»mr*’P₽R* РНВвмС»с«Р«1’*’Айо>мНо«ММ»<ЬсеС1исиЬ’ /₽PRCa»n»rts<‘ > ! ‘RoteRaauwmvtt F«fj4;«n«»c<MiPjtbs*AtMawliaitMlB*MRai»a«Mljb’ jPisa>av>

‘ ‘lH«maEl»<T>«t *

<H«<na£to<MM ’»>>-,»••’C«M<ih<<»»*hr t~’GUDl6”

I >ЕяамМ«хк« №<п^’РР1Г Явбэм ‘t»>x°4i’>s-A|ioflMi)Q«MlMeitic«ClaMLh/ /PPRCaMKtti*1* | <RotoRewmttia PaEenRtfaUai ;Я»и>» АиимШ>М18маР«йСЬмЬЫ JPitdicT’» <<lrtamaEI*n>M%

<Rde&O4iM»m«”l« P»(0Ma3*.ia:i»>sPM,>«’A«toinMioiMB»aeR*leCI*««bW. AMtcl’.”

«Zhia<MieiMMnl>

<t><Tw’a_T1′ r.wF.«r-i$.*M~’GUOa ₽₽R* Pa<Pari»««S4«d*-GUDePPR7> hanw»*rn_T«1 * Rt^<tn»«4a*>-XXJKM:PPir »»₽»*»»<$<«&’ismie PPQ’A

‘WHmfwrt ’нтг-‘АвГдг R«ff>«t»tri<dH»*9U06 W c4>«Vw<Sle»6‘’GU»11

<1М»тЫЬМ •*»п«^’С2_Т2’ R«*’«’t>>fSd^,GUC6.PPR’ Re6>ni>«iS4t6f‘GUCnOFPR*Z’ <:rterre||jr* Wiw’C2.T3′ ReFiane^ ea^’GUCfrPW Pe₽»rtre»C«e^GUD12₽PP’.’> 4|>|*нМиА Kam*>’C1_C«W1′ 0*Tlrto«^.t5»*»-OUC3W Р»?ыт»^<Нв**(ДОМЯР(Г.’>

Чат^ТП^СйИЛ’ S’t₽j’t-,ei$’ !rA’”GWW PPR” R*Pa*->»<$«}«fh‘GUOI4 ₽₽R7» OolcmNUrt V>n»s‘RBt.OMWt- R4<₽a<^ei3.i«A-‘GUC6PPP P»Fxiwr«<»Bs’GU0U ₽PR7> onlemiAjnk Kim^’ReiJM’ B«<₽nt«*S’t»*»*GUO5 PW R,»ff4a»>»9a»O,GU©t5 РИГА» «HtaiMlUM 44<r*»’RB1_CW1* P*F«tnt(3<MA-*©(XeRPR’H««>MnarS.(lte»’GUtne-PPR’^ OMemalLrt* <нп>»’С2_й#Л’ R^*iwSr»A*4M6PPR’^-en>*’3tt&s*0UD14PPR’S> <!nt»maiUM Kames~C2_CWr R«₽»iwSKMfe«:-GlM» PPR” Foffar^rSectt’GUOlB PPRV» <ftti4R*«j>«aa«t«aa£*t»Re»(”M<P>iiM’Aine<Mi>e<MlSttiRMta«MlJW Л^аЯ*г>

«freanaEknmrt’

</Ы1*к*Нелг<1>)Г>

Рисунок A.36 — Представление иерархии экземпляров InstanceHierarchy рассматриваемого примера на язьже XML

А.2.7 Поддержка сразу нескольких ролей

В добавление к МЭК 624242008 (подраздел А.2.9) язык AulomationML обеспечивает возможность поддержки сразу нескольких ролей для экземпляра одного объекта. Рассмотрение сразу нескольких ролей млеет смысл, если данный объект имеет несколько функциональных возможностей.

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

Рисунок А.Э7 содержит пример, в котором объект «MultiDeviceOl» имеет три атрибута: »Fax-BoudRate». «PrinlSpeed (скорость печати)». -FaxSpeed» (скорость передачи сообщения) и два интерфейса: -PowerSupply» (питание) и «USB» (USB-интерфейс)». Объект -Multi DeviceOl» поддерживает три роли: «Printer» (принтер). -Fax» (факс). -Scanner» (сканер). Роль со ссылочным тегом “RetBaseRoleClassPath» (ссылочный путь доступа к базовому ролевому классу) для соответствующего элемента требований RoleRequirement является базовой. Соответствующий XML-код приведем на рисунке А.38.

Атрибуты и интерфейсы, принадлежащие объекту «MultiDeviceOl». должны отображаться на атрибуты и интерфейсы всех трех ассоциированных ролей. Это производится с помощью объекта отображения САЕХ MappingObject в соответствии с МЭК 62424 (подраздел А.2.10), который дает информацию об атрибуте роли (интерфейсе), о порядке ассоциации рассматриваемого экземпляра атрибута (интерфейса). Чтобы различать атрибуты различных ролей (имеющих одинаковые имена), имя роли включается в определение отображения (за исключением базовой роли, указанной в пути доступа «RetBaseRoleClassPath»). Пример описания необходимых атрибутов и интерфейсов, а также порядка их отображения на экземпляры атрибутов и интерфейсов приведен на рисунке А.37.

« InataoceNierarchy

s Вате milpieRsteeSuMO’t

* internaiEtement

x Mama Uu»0ar<»01 s Q GUC1

3 Name ООО I

  • 3 Ю GUD2

  • 4 Attribute <3i

= Name t F*x8oudR*M

  • 2 PmtSpeed

  • 3 ScanSpead

м txtemadnterface ijp

s Meme t PowerSupply

2 USS

4 SupportedRoleCiaes 31

s RefftoteCiaeaPetb

  • 1 UaerdetoedRoteCieMUb’Prrter

  • 2 U*erdefcwdR«eCla*»l*’Fax

J 3 UterdeMedRMCMHL&Scaniw « RoteReoutremente

8 RetBaeeRoiaCiMeFath 4 Attribute d

uwr6afM0Ro*ci**K*>Pnntr

8 Мате Seeed Fax.Spaed Scanner seeed

<> Vatae 2S 54 1

MappangObftct

4 AttrKHiteMmaMapping <3>

8 RotaAttnbvtoMame t Speed

  • 2 Fax Speed

  • 3 Scanner Speed

kit«rfocatt*(n«Mapping

8 SyatemUniUttnbuteNMne*

PnstSpeed FaxBoudRate Sca®S₽eed

s RotekHerfaceflame s 9уШаяеяММег1к8Ямп^

< Power RewerSi*^

Рисунок A.37 — Пример погъзовэтельского экземпляра, поддерживающего несколько ролей

Представление рассматриваемой структуры на языке AutomalionML приведено на рисунке А.38.

«InstanceHiefarchy N^me^’miApteRotesSuppott*»

«IntemaiEtemem Name«’MuitiDeviceOr lD«’GUI0r>

<mtema£lemert Neme»’DOOr ID>’GU(O2*>

«Attribute Name=’FaxSoudRate”/>

«Attribute Names’PrinlSpeecT/»

«Attribute Name=’ScanSpeed7>

«Extemalintarface Name=’PowerSuppyf>

«Extemallrrterface Narrws*USB*/>

«SupponedRoteCtass ReraoteCiassPatb-TJserdefinedRoleClassLiWPriniefV»

«SuppcrtodRoteCtesa R«(RoleCins«Pattis*U*erdofinedRoleCla>*Lib/Fax*/»

«SupportedRdeQas» R«fRoieCte$sPalh®*UMrdefinedRoleCl8SBLib/Scanner7>

«RdeRequrements RefBasoRcAjCiassPa(h=*UsenWinedRc*eClaesLib/PrtrHer*>

«Artnoute Nanie=*SpM<r> <Vatue»20«/Vaiu©>

«/Attribute»

«Attrbute Name=’Fax.Speed”>

«Value» 54 «/Value»

«/Attribute»

«Attnbute Name«’ScannerSpeed*>

<Vatue>1<Atelue>

«/Attribute»

«/RoteRequrements»

«MappetgObject»

«ArtnbuteNameMappng Rc4eAttnbure№ne»*Speed” SystemUn<AttnbuteWame«’PrintSpeetr/> «AttrtouteNameMapptftg RcteAttributeName«*Fax. Speed* SystemUn/tAnnbutaNawe^’FaxBoudRale*/» «AttotxiteNameMappng Rc*6AttntxxtaName=*Scannef.Speetr Sy3t8murwtAttnbuteName“*ScanSpae<r/» «IrterfaceNameMapipmg RotelnterfaceName= “Power” SystemUnitlnterfaceName?*PowerSuppl//>

«/Mappingobject»

«/IntemalElement»

«/intemaiEJement»

Рисунок A.38 — XML-код представления, поддерживающего несколько ролей на языке AutomalionML

Соответствующие библиотеки ролевых классов AutomalionML и их представление на язьке XML приведены на рисунках А.39 и А.40.

RoreOmtib ___

8 MempLuterdPlHedRM»Qep>La________________________________

a ftoieCUM = Name ж Ае<вмрС1е»«РМЬ Auttf’MpnUUtobCbeU.fc’AvtemMienUUtMRM al Attribute lit

z Weme 1 Speed ExtemaBnterlace

s Name 1 Power

RoteCi»»» a Name Fax

s ПоГВмеСИааРет AutMMenULRobCiaaai.erAMoawtwiUl3ao«Po8 «AHnbuteri

s Name

1 Speed

RoieCtoaa

s Name

Scmmt

s ЯеПм»С1маРмп AutowaoonUiReitC»a*Lb/A«tomatw>UiaB>«Role

A Attnbute

2 Name 1 Speed

Рисунок A.39 — Библиотека ролевых классов AutomalionML. соответствующая примеру с несколькими определениями ролей

«RoteClassLib Name=’UserdefinedRoteClaBsLib,’>

<RoieClass Names’Pnmer RefSaseClassPaih^’AutomabonMLRoieCiassLib/AutomationMLBaseRote’»

«Attribute Narr>e=*Spe«r/>

«Exiemaltnt efface Names ’Power’/»

</RoteOass>

«RdeClass Nafne=MFax” RefBaseCtassPath=’AulcmattonMLKoleClassL<yAutomatioriMLBaseRc»e*>

«Attribute Name**Spee<r/>

</RoteOass>

«RdeClass Nam&s’Scanner* RefBaseClessPaths’AutomabonMLRoteCfassLtb/AutcmationMLBaseRoJe’

«Attribute Name=’Speed’/>

</RoieCiass>

«/RdeClassLib*

Рисунок A.40 — Код на языке XML для библиотеки ролевых классов AutomationML

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

Представление библиотек AutomationML на языке XML

В.1 Библиотека базового ролевого класса AutomationMLBaseRoleClassLib

«?xmt versions‘1 .0’ encodings *ut|.8″?>

«CAEXFile xmlnsjcsis*httpy/www.w3.org 2001 XMLSchema-mstance*

xsi:noNamespaceSchemaLocat>on-‘CAEX_C!assModei_V2.15.xsd“

FileNames’AutomalionMLBaseRo!eClassL»b.AutomalionML“ SchemaVers*on=’2.15’»

«Additionallnformalion Au1omat«nMLVersion=”Z0“ i>

«Additionallnformalion»

«WnterHeader»

«WriterName»IEC SC65E WG 9«/WriterName»

«WriterlD»IEC SC65E WG 9«WrrterlD>

«Writer Vendor»IEC«-WriterVendor»

«Writer VendorURL»www.»ec.ch<Write<VendortJRL»

«Writer Version» 1 .0«/WriterVersion>

«WriterRelease»1.0.0«>WritetRetease»

<LaslWritingDateTima»20l3-03-01«>’LastWriiingDaleTime» «WriterProjedTitloAutomabon Markup Language Standard Libraries«.’WriterPro}ectTitte>

<WriterProjectlD>Automation Markup Language Standard

Libraries«;WriterProjectlD»

«/WriterHeadec»

«/Additionallnformation»

«ExternalReterence Paths’..rtnterfaceClass

Libraries/AutomationMLInterfaceClassLib.AutomationML*

Aliass’AutomatronMLInteriaceClassbb” (>

«RoleClassLib Name=”AutomationMLBaseRoleClassUb”>

«Descript»on»Automalion Markup Language base role ciass

library«’Description»

«Version»2.2.0«*’Version»

«RoleClass Names’AulomationMLBaseRole*»

«RoleClass Names “Group* RelBaseClassPaths’AutomationMLBaseRole”»

«Attribute Names* AssodatedFacet” AltributeDataTypes*xs:slring’ /»

«.’RoleClass»

«RoleClass Names “Facet’ RefBaseClassPaths’AulomationMLBaseRole” /> «RoleClass Names “Pod” RelBaseClassPaih=“AutomalionMLBaseRole’» «Attribute Names’Direction* AttnbuteDataTypes*xs:string” (> «Attribute Names’Cardinakty*» «Attribute Names’MinOccur” AltribuleDataTypes’xsiunsignedlnt* />

«Attribute Names “MaxOccur* AttributeDataType=”xs:unsignedlnr /> «’Attribute»

«Attribute Names’Category’ AltribuleDataTypes“xs:string“ />

«Externallnterface Names’CcnnectionPomt’ ID=”9942bd9c-c19d-44e4-a197-

11b9edl264e7“

RefBaseClassPattis’AutomationMLlntertaceClassUb^AutomaiionMLlnterfaceC lassbb’AutomationMLBaselntertacwPortConnector*;»

«/RoleClass»

«RoleClass Names “Resource* RelBaseClassPalhs’AutomalionMLBaseRoie” /» «RoleClass Names “Product* RelBaseClassPaths’AutomationMLBaseRole” /> «RoleClass Names “Process* RelBaseClassPaths”AutomationMLBaseRole“ /> «RoleClass Names “Structure* RelBaseClassPaths*Automat»onMLBaseRole*» «RoleClass Names’ProductStructure’ RelBaseClassPaths’Structure* f> «RoleClass Names’ProcessStructure” RelBaseClassPath=”Structure“ f> «RoleClass Names*ResourceStructure* RelBaseClassPaths’Structure** /» «RoleClass»

«RoleClass Names “PropertySet* RefBaseClassPalhs’AutomationMLBaseRole” />

o’Rol eCiass»

«-RoleClasslab»

«/CAEXFile»

В.2 Библиотека класса интерфейса AutomalionMLIntedaceClassLib «?xml versions”! .0″ encodings”utf-8’?»

«CAEXFile xmlns:xsi=’Tittp?.’Www.w3.cxg.’2O<l1.’XMLSctiema-instanc0″ xsi:noNamespaceSchemaLocations’CAEX_ClassModel_V2.1S.xscr FiieNames’AiriomabonMLIntedaceClassUbAutomationML” ScbemaVersion=’2.15“> «Additionaltnformation AulomationMLVersiona”2.0’ /»

«Additional Information»

«WrilerHeader»

*WriterName»IEC SC65E WG 9<>WrilerName>

<WriterlD»IEC SC65E WG 9<WriterlD»

<WriterVendoolEC<‘WnterVendcx>

<WritecVendorURL»www.iec.ch<lWriterVendorURL»

«Writer Version» 1.0</WriterVersron>

«WriterRelease»i.O.O«.-WriterRelease»

<LastWritingDateTime»20i3-03-01</LastWritingDaleTim6»

«WriterProjectTille»Automation Markup Language Standard

Libraries*/Writer ProjectTitle»

«Write<Pro^ctlD»Automation Markup Language Standard

Libraries«/WritefProfectlD»

«/WnterHeader»

«/Additionallnformalion»

«InlerfaceClassLib Names’AutomattonMUnterfaceClassbb”»

<Descripbon»Standard Automation Markup Language Interlace Class Library«/Descnplion»

<Version»2.2.0«?Version»

«Interfaceclass Names’AulomationMLBaselnterface’»

«Interfaceclass Name=”Order’ RelBaseCiassPaths’AutomationMLBaselrrterface «Attribute Names’Direclion* AltributeDataTypes*xs:string* /»

«/InterfaceClass»

«Interfaceclass Nam&=”PortConnector”

RelBaseCiassPalhs’Automa bonMLBaselnterface*/»

«InterfaoeClass Names’lnterlockingConnector”

RefBaseClassPaths’AutomationMLBaselnierface* /»

«Interface Class Names”PPRConneclor’

RelBa seClassPath=’Automa tionMLBase Interface’/»

«Interfaceclass Names’ExtemalDataConnector*

RelBaseClassPalhs’Automa tionMLBase Interface*»

«Attribute Names’retURI’ AttributeDataTypes’xs^nyURr !>

«IrrterfaceCiass Names’COLLAOAIntertace* RetBaseClassPaths’ExtemaiDataConnector* /> «Interfaceclass Names*PLCopenXMLInterlace* RefBaseClassPaths’ExtemaiDataConnector* /> «/InterfaceClass»

«Interfaceclass Names’Communication*

RefBaseClassPaths’AutomationMLBase Interface’»

«InterfaceClass Names’Signallnterface’ RefBaseClassPathsXommunication* /»

«/InterfaceClass»

«/InterfaceClass»

«/InterlaceClassLib»

«/CAEXRIe»

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

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

IEC 62714-2

IDT

ГОСТ Р МЭК 62714-2—2020 «Формат обмена инженерными данными для использования в системах промышленной автоматизации. Стандартизированный формат обмена данными AutomationML. Часть 2. Библиотеки ролевых классов-

IEC 62714-3

* Соответствующий национальный стандарт отсутствует. До его пршятия рекомендуется использовать перевод на русский язык данного международного стандарта. Официальный перевод данного международного стандарта находится в Федеральном информационном фонде стандартов.

Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта;

– IDT — идентичный стандарт.

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

П)

  • [2]

  • [3]

W

15J

(6)

17]

  • (8]

  • [9]

110)

IEC 60027 (all parts)

IEC 62264-1

IEC 62714-2

ISO 80000-1 IEC 62424:2008

ISOflEC 9834-82014

ISO’PAS 175062012

Letter symbols to be used in electrical technology (Обозначения буквенные, применяемые в электротехнике (все части IEC 60027}]

Enterprise-control system integration — Part 1: Models and terminology (Интеграция систем управления предприятием. Часть 1. Модели и терминология)

Engineering data exchange format for use in industrial automation systems engineering — Automation Markup Language — Part 2: Role class libraries (Формат обмена техническими данными, используемый при проектировании промышленных автоматизированных систем. Язык разметки автоматизации. Часть 2. Библиотеки ролевых классе») Quantities and units — Part 1: General (Величиш и едигыцы. Часть 1. Общие положения) Representation ot process control engineering — Requests in P&l diagrams and data exchange between P&ID tools and PCE-CAE tools (Представление технологии управления процессами. Запросы в диаграммах P&I и обмен данными между средствами P&I О и средствами РСЕ-САЕ)

Information technology — Procedures lor the operation of object identifier registration authorities — Part 8: Generation ol universally unique identifiers (UUlDs) and their use in object dentifiers (Информационные технологии. Процедуры для работы регистрационных органов идентификаторов объектов. Часть 8. Создание универсальных уникальных идентификаторов и их использование а идентификаторах объектов) Industrial automation systems and integration — COLLADA digital asset schema specilcation lor 3D visualization ol industrial data (Системы промышленной автоматизации и интеграция. Спецификация цифровой схемы активов СОШКОАдля трехмерной визуализации промышленных данных)

COLLADA 1.4.1: Март 2008. COLLADA — Схема цифрового актива. Выпуск 1.4.1 (см. httpA’www.khronos.org*’ файл.’со11аСа_5рес_1 _4.pdf)

Расширяемый язык разметки XML 1.0 1.02004. рекомендации W3C (см. http:/Avww.w3.org’TR2004,REC-xml-200402041)

Расширяемый язык разметки XML для открытого программируемого PLC-контроллера 2.0: Декабрь. № 3. 2008. а также PLCopen XML 2.0.1: Май. Nt 8. 2009. Форматы расширяемого языка разметки XML для МЭК 61131-3 (см. http:A*www.plcopen.org>)

(111

[12]

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

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

УДК 658.52.011.56:006.354

ОКС 25.040.40 35.060 35.240.50

Ключевые слова: системы промышленной автоматизации, интеграция, формат обмена инженерными данными, стандартизованный формат обмена данными Automation ML

БЗ 11—202024

Редактор Л.В. Каретникова Технические редакторы В.Н. Прусакова. И.Е. Черепкова Корректор Е.М. Поляченко Компьютерная верстка Д.В. Карденовской

Сдано а набор ОТ .10 2020. Подписана в печать 20.10.2020. Формат 00 ■ 84’/^. Гарнитура Ариал.

Уел. леч. л. 8,37. Уч.-изд. п. 8.12.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

ИД -Юриспруденция». 115416. Москва, ул. Орджоникидзе. 11. www.juncizdai.tu у-Ьоокфтайги

Создано а единичном исполнении во ФГУП -СТАНДАРТИНФОРМ» . 117416 Москва. Нахимовский пр-т. д. 31. к. 2.

www.gosltnlo.ru inlo@goslinfo.ru

1

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

‘ Таблица 1 приведена в текстовом формате (см. 3.2).

Выполненные работы

Натуральные чаи «Чайные технологии»
Натуральные чаи «Чайные технологии»
О проекте

Производитель пищевой продукции «Чайные технологии» заключил контракт с федеральной розничной сетью «АЗБУКА ВКУСА» на поставку натуральных чаев.

Под требования заказчика был оформлен следующий комплект документов: технические условия с последующей регистрацией в ФБУ ЦСМ; технологическая инструкция; сертификат соответствия ГОСТ Р сроком на 3 года; декларация соответствия ТР ТС ЕАС сроком на 3 года с внесение в госреестр (Росаккредитация) с протоколами испытаний; Сертификат соответствия ISO 22 000; Разработан и внедрен на производство план ХАССП.

Выдали полный комплект документов, производитель успешно прошел приемку в «АЗБУКЕ ВКУСА». Срок реализации проекта составил 35 дней.

Что сертифицировали

Азбука Вкуса

Кто вёл проект
Дарья Луценко - Специалист по сертификации

Дарья Луценко

Специалист по сертификации

Оборудования для пожаротушения IFEX
Оборудования для пожаротушения IFEX
О проекте

Производитель оборудования для пожаротушения IFEX открыл представительство в России. Заключив договор на сертификацию продукции, организовали выезд экспертов на производство в Германию для выполнения АКТа анализа производства, часть оборудования провели испытания на месте в испытательной лаборатории на производстве, часть продукции доставили в Россию и совместно с МЧС РОССИИ провели полигонные испытания на соответствия требованиям заявленным производителем.

По требованию заказчика был оформлен сертификат соответствия пожарной безопасности сроком на 5 лет с внесением в госреестр (Росаккредитация) и протоколами испытаний, а также переведена и разработана нормативное документация в соответствии с ГОСТ 53291.

Выдали полный комплект документации, а производитель успешно реализовал Госконтракт на поставку оборудования. Срок реализации проекта составил 45 дней.

Что сертифицировали

Международный производитель оборудования
для пожаротушения IFEX

Кто вёл проект
Василий Орлов - Генеральный директор

Василий Орлов

Генеральный директор

Рассчитать стоимость оформления документации

Специалист свяжется с Вами в ближайшее время

Получить консультацию специалиста

Ошибка: Контактная форма не найдена.

Оставляя заявку, вы соглашаетесь с пользовательским соглашением