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

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

от 29 сентября 2020 г. № 699-ст

ОКС 25.040.40

Дата введения

Предисловие

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-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.7 файл (языка) AutomationML (AutomationML file): Файлы в формате CAEX, соответствующие настоящему стандарту и имеющие расширение «.aml», за исключением ссылочных вспомогательных файлов.

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

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

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

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 CAEX (CAEX): Нейтральный формат данных, основанный на XML-языке.

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

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-7B44-A70000000000}».

Примечание 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): Моделирование структуры данных внешнего документа при использовании формата CAEX.

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

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

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

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

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

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

3.2 Сокращения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информация о геометрии и кинематике: требуемая информация о геометрии и кинематике хранится в формате данных COLLADATM <*>. Интерфейсы COLLADA, взаимосвязанные внутри формата верхнего уровня, должны быть опубликованы как внешние интерфейсы CAEX ExternalInterface.

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

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

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

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

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

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

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

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

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

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

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

• корневой элемент CAEX «CAEXFile» для каждого документа верхнего уровня языка AutomationML должен иметь дочерний элемент CAEX «AdditionalInformation»;
• указанный элемент дополнительной информации «AdditionalInformation» должен иметь атрибут «AutomationMLVersion»;
• значение указанного атрибута «AutomationMLVersion» должно храниться в XML-документе. В целях соответствия настоящему стандарту необходимо использовать версию «2.0»;
• каждый ссылочный документ CAEX должен соответствовать аналогичной версии языка AutomationML корневого документа. Смешивание документов с различными версиями AutomationML запрещено;
• каждый ссылочный внешний документ должен также соответствовать поименованным версиям схемы, определенным в вышеуказанной спецификации версии языка AutomationML. Смешивание внешних версий документа вне заданной спецификации версии AutomationML запрещено.

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

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

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

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

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

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

• CAEX, версия 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;
• в цепочке инструментальных средств обмена данных все принимающие участие инструментальные средства должны хранить данную информацию в документе CAEX аналогичным способом. Данный документ должен содержать информацию о нескольких инструментальных средствах рассматриваемой цепочки инструментальных средств обмена данными. Рассматриваемое инструментальное средство может удалить пользовательскую информацию о прочих инструментальных средствах. Это может затруднить итерационную процедуру обмена данными с прочими инструментальными средствами, в связи с чем удаление пользовательской информации о прочих инструментальных средствах не рекомендуется;
• данная информация должна храниться как часть дополнительной информации CAEX AdditionalInformation корневого объекта документа CAEX;
• блок дополнительной информации AdditionalInformation должен быть поименован как заголовок «WriterHeader»;
• метаинформация должна содержать следующие данные: - имя экспортирующего программного обеспечения, пользовательского инструментального средства; - идентификатор ID пользовательского инструментального средства (он должен остаться неизменным); - информацию о продавце пользовательского инструментального средства; - URL размещения пользовательского инструментального средства; - информацию о номере версии пользовательского инструментального средства; - информацию о выпуске пользовательского инструментального средства; - информацию о времени внесения последнего изменения пользователем; - название проекта источника; - идентификатор проекта источника;
• содержание метаинформации определяется пользовательским инструментальным средством. Тип записи — xs:string;
• необходимая информация должна храниться с помощью атрибутов, указанных в таблице 2.

Таблица 2 <*>

<*> Таблица 1 приведена в текстовом формате (см. 3.2).

Метаинформация об инструменте источника AutomationML

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

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

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

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

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

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

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

• в соответствии с МЭК 62424 (пункт A.2.2.1) классы языка AutomationML (ролевой класс RoleClass, класс интерфейсов InterfaceClass, класс системных единиц SystemUnitClass) идентифицируются тегом «Name (имя)» формата CAEX;
• данное имя должно быть уникальным внутри рассматриваемого уровня иерархии соответствующей библиотеки AutomationML в течение всего срока существования класса;
• в соответствии с МЭК 62424 (подраздел A.2.8) ссылка на классы производится с использованием полных путей доступа с помощью соответствующих сепараторов пути доступа;
• все экземпляры объекта AutomationML (внутренние элементы формата CAEX InternalElements, внешние интерфейсы формата CAEX ExternalInterface) идентифицируются соответствующими тегами «ID» формата CAEX. Данные идентификаторы должны быть UUID-идентификаторами в соответствии с ИСО/МЭК 9834-8.

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

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

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

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

• если рассматриваемый идентификатор создан, то полученный UUID не может изменяться в течение всего срока существования соответствующего объекта для всех используемых инструментальных средств;
• ссылочные экземпляры используют значение «ID»;
• ссылка на интерфейс CAEX оформляется с использованием идентификатора UUID родительского объекта интерфейса, строки сепаратора «:» и имени экземпляра интерфейса.

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

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

Пример 2 — «GUID.Colour».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• наследование между классами определяется в соответствии с МЭК 62424:2008 (подраздел A.2.7);
• если наследование необходимо, то родительский класс указывается с помощью тега CAEX «RefBaseClassPath», включающего полный путь доступа к базовому классу в соответствии с МЭК 62424 (подраздел A.2.7);
• если рассматриваемый родительский класс расположен одним уровнем иерархии выше указанного дочернего класса, то родительский класс указывается путем сохранения имени данного родительского класса в теге CAEX «RefBaseClassPath» без указания полного пути доступа.

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

В добавление к данному примеру тег CAEX «RefBaseClassPath» может относиться либо к «InheritanceExampleLib/Robot1234», либо к «Robot1234», так как родительские классы расположены на один уровень иерархии выше уровня класса «SpecialRobot1234».

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

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

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

• объект языка AutomationML моделируется в качестве сущности InternalElements в формате CAEX как часть иерархии CAEX InstanceHierarchy или класса SystemUnitClass;
• объект языка AutomationML может быть одиночным объектом без связи с классом SystemUnitClass.

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

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

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

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

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

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

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

• изменение класса источника должно вести к появлению новой версии класса с другим именем. Внутри нового класса полный путь доступа к старой версии класса должен храниться в теге CAEX «OldVersion».

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

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

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

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

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

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

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

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

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

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

• соотношения «экземпляр — экземпляр» хранятся в соответствии с МЭК 62424 (пункт A.2.5.3 и подраздел A.2.14) с помощью CAEX InternalLinks;
• CAEX InternalLinks хранится сущностью CAEX InternalElements, являющейся общим родителем самого нижнего уровня для соответствующих соединенных объектов CAEX;
• соотношения «экземпляр — экземпляр» определяют только между внешними интерфейсами CAEX ExternalInterface, принадлежащими соответствующим объектам AutomationML (см. МЭК 62424, пункт A.2.3.1);

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

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

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

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

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

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

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

«блок-схема» и «дерево объектов»

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

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

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

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

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

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 InterfaceClass. Они выводятся непосредственно или косвенно из стандартного класса интерфейсов ExternalDataConnector;

• стандартный класс интерфейсов «ExternalDataConnector» используется для типов документа, включенных в МЭК 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, приложения A и C). МЭК 62714 использует понятие интерфейса CAEX. Допускаются пользовательские расширения данной библиотеки AutomationML в соответствии с 7.3.

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

Таблица 3

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

Библиотека AutomationML InterfaceClass	Класс интерфейсов InterfaceClass	Описание
	AutomationMLBaseInterface	Абстрактный тип интерфейса
	Order	Интерфейс описания порядка
	PortConnector	Интерфейс описания портов
	PPRConnector	Коннектор для взаимосвязанных продуктов, ресурсов или процессов
	ExternalDataConnector	Характерный интерфейс коннектора внешних данных
	COLLADAInterface	Интерфейс документа COLLADA
	PLCopenXMLInterface	Интерфейс документа PLCopen XML
	Communication	Характерный коммуникационный интерфейс
	SignalInterface	Характерный интерфейс сигналов

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

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

AutomationML на языке XML

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

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

Таблица 4

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

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

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

Таблица 5

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

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

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

Таблица 6

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

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

Таблица 7

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

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

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

Таблица 8

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

AutomationMLBaseRoleClassLib

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

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

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

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

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

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

Таблица 14

Пример - AssociatedFacet = «PLCFacet»

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

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

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

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

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

Таблица 16

AutomationML Port

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

Таблица 17

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

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

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

Таблица 18

Интерфейс класса портов AutomationML Port

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

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

Ролевой класс RoleClass Resource

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

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

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

Таблица 20

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

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

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

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

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

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

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

Таблица 22

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

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

Таблица 23

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

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

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

Таблица 24

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

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

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

Таблица 25

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

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

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

Таблица 26

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

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

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

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

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

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

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

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

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

• атрибуты CAEX должны храниться на языке AutomationML в соответствии с определением атрибутов CAEX, приведенным в МЭК 62424 (подраздел A.2.4);
• если необходимы единицы измерения, то пользовательские атрибуты должны базироваться на уже имеющейся системе единиц. Системы единиц измерений в настоящем стандарте не рассматриваются.

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

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

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

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

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

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

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

Примечание - Классы интерфейсов AutomationML InterfaceClass и пользовательские классы интерфейсов InterfaceClass хранятся одинаково в формате CAEX InterfaceClass;

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

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

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

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

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

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

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

Примечание 1 — Ролевой класс AutomationML RoleClass и пользовательский ролевой класс RoleClass хранятся одинаково в формате CAEX RoleClass;

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

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

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

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

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

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

• пользовательские классы SystemUnitClass должны храниться на языке AutomationML в формате CAEX SystemUnitClass. Соответствующее определение приведено в МЭК 62424 (подраздел A.2.3);
• пользовательские классы SystemUnitClass должны непосредственно или косвенно быть назначены для ролевых классов AutomationML RoleClass. При необходимости они используют атрибуты AutomationML.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• порт AutomationML Port должен быть описан в формате внутренних элементов CAEX InternalElements в ассоциации с ролевым классом RoleClass «Port», описанным в 6.4.5;
• объект порта AutomationML моделируется как дочерний объект рассматриваемого объекта (класса) AutomationML;
• необходимый набор интерфейсов описывается в формате внешних интерфейсов CAEX ExternalInterface объекта порта;
• объект порта не должен содержать дочерних внутренних элементов CAEX InternalElements;
• все внешние интерфейсы CAEX ExternalInterface объектов порта должны непосредственно или косвенно выводиться из класса интерфейсов AutomationML, определенного в 6.3;
• порт AutomationML Port должен дополнительно иметь по крайней мере один внешний интерфейс CAEX ExternalInterface, полученный из класса интерфейсов 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). Краткое описание понятия фасета и соответствующие примеры приведены в подразделе A.2.3.

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

- объект фасет AutomationML Facet описывается в формате внутренних элементов CAEX InternalElements в ассоциации с ролевым классом RoleClass «Facet», описанным в 6.4.4;

• объект фасет AutomationML Facet моделируется как дочерний объект рассматриваемого объекта (класса) AutomationML;
• фасет должен иметь уникальное среди ближайших родственных элементов произвольное имя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• если экземпляр поддерживает несколько ролей, то каждая из них определяется с помощью элемента CAEX «SupportRoleClass» вместо использования атрибута CAEX для пути доступа к базовому ролевому классу «RefBaseRoleClassPath».

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

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

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

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

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

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

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

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

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

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

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

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

(справочное)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок A.3 — Ссылка из объекта CAEX на документ COLLADA

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

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

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

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

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

    - <a id="p100872"></a>соотношения "родитель - потомок" между объектами AutomationML;

    - <a id="p100873"></a>соотношения "родитель - потомок" между классами AutomationML;

• соотношения наследования (см. 5.6.4): - соотношения наследования между классами системных единиц SystemUnitClass;

    - <a id="p100876"></a>соотношения наследования между ролевыми классами RoleClass;

    -   <a id="p100877"></a>соотношения    наследования    между    классами    интерфейсов

InterfaceClass;<br>

    - <a id="p100879"></a>соотношения между классом SystemUnitClass и его экземпляром;
    - <a id="p100880"></a>соотношения между классом RoleClass и его экземпляром;
    - <a id="p100881"></a>соотношения между классом InterfaceClass и его экземпляром;

    - <a id="p100883"></a>соотношения между объектами AutomationML;

    - <a id="p100884"></a>соотношения между опубликованными данными, хранящимися вовне.<br>

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

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

Рисунок A.7 — Описание примера соотношений библиотеки

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

экземпляров InstanceHierarchy на языке XML

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

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

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

Таблица A.1

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

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

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

Рисунок A.10 содержит пример понятия порта AutomationML Port. Объект «Station» (станция) включает подобъекты «Conveyor1» и «Conveyor2». Оба подобъекта имеют один объект порта каждый. Объект порта содержит набор интерфейсов, а также стандартный интерфейс «Connection-Point» (точка соединения), полученный из класса интерфейсов AutomationML InterfaceClass «PortConnector». Данный стандартный интерфейс может соединяться с помощью внутренних связей CAEX InternalLinks. Рассматриваемое соотношение означает, что оба порта соединены друг с другом. Внутренние связи субинтерфейсов подробно не описаны в настоящем стандарте. Рассматривается соединение только абстрактных точек ConnectionPoints. Кроме данного понятия, язык AutomationML допускает хранение каждого индивидуального связующего элемента, расположенного между субинтерфейсами.

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

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

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

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

портов AutomationML «myPortClass»

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

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

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

A.2.3.2 Пример

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

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

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

на языке XML

A.2.4.1 Описание понятия

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

Путем определения атрибута группы «AssociatedFacet» (ассоциированный фасет) данная группа может быть ассоциирована с типом фасетов, характеризуемых уникальным именем. Это позволяет внешним инженерным алгоритмам автоматически идентифицировать рассматриваемые объекты (и их соответствующие фасеты), чтобы получить требуемую инженерную информацию. Кроме того, язык AutomationML определяет ролевой класс AutomationML RoleClass «Group» (см. 6.4.3). Нормативные положения приведены в 8.4.

Рисунок A.16a) описывает понятие группы с помощью структуры «Station», содержащей объекты «Conveyor1», «Conveyor2», «Robot1» и «PLC1». Объекты «Group1» и «Group2» описывают одинаковые данные в различных иерархиях. Объект «Group1» определяет структурное представление только для конвейеров. Объект «Group2» отображает только объекты, относящиеся к программируемому логическому контроллеру PLC. В соответствии с МЭК 62424 (подраздел A.2.14) формат CAEX обеспечивает хранение таких пересекающихся структур. Рисунок А.16b) содержит интерпретацию данного примера на языке AutomationML. Рисунок A.17 содержит соответствующее описание на языке XML.

b) Сетевое представление

Рисунок A.16 — Пример группы AutomationML Group

Рисунок A.17 — Пример описания группы AutomationML Group на языке XML

Пример возможной комбинации понятия группы и понятия фасета приведен на рисунке A.18. Показанная иерархия экземпляров InstanceHierarchy отображает объект языка AutomationML «Station», включающий объекты AutomationML «Conveyor1» и «Conveyor2». Указанные конвейеры имеют два атрибута и два интерфейса каждый.

Объект языка AutomationML «Group» представляет собой встроенные группы «Group1» и «Group2». Обе группы ссылаются на объекты конвейера, но имеют различные ассоциации фасетов.

Пример применения: алгоритм генерации кода управления может пройти по иерархии экземпляров InstanceHierarchy и идентифицировать все группы, ассоциированные с фасетом «PLCFacet», а затем сгенерировать код для оценки ссылочных объектов.

Рисунок A.19 содержит описание на языке XML, соответствующее примеру, приведенному на рисунке A.18.

A.2.4.4 Автоматическая генерация человеко-машинного интерфейса HMI с помощью понятия группы и понятия фасета

В данном примере принято, что атрибут «B» конвейера представляет собой шаблон интерфейса HMI, визуализирующий переменную «Y». Рисунок A.20 иллюстрирует характерный шаблон интерфейса HMI конвейера.

технологического процесса конвейера

Основанный на конкретном экземпляре конвейера, рассматриваемый инженерный алгоритм идентифицирует, что объект языка AutomationML «Group2» ассоциирован с фасетом HMI-интерфейса. Здесь он идентифицирует, что экземпляры «Conveyor1» и «Conveyor2» являются частью HMI-интерфейса. Данный алгоритм может извлекать информацию из интерфейса HMI о каждом из двух конвейеров. Он может идентифицировать соответствующий шаблон HMI, может ассоциировать корректные сигналы для последующей их визуализации. Рисунок A.21 представляет результирующий HMI-интерфейс.

Рисунок A.21 — Сгенерированный результирующий HMI-интерфейс «B», визуализирующий оба конвейера с индивидуальными переменными технологического процесса

A.2.5.1 Описание понятия

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

Объект отображения CAEX обеспечивает отображение собственных атрибутов объекта AutomationML с предварительно семантически определенными атрибутами набора свойств PropertySet. Это обеспечивает возможность импортеру программного обеспечения автоматически интерпретировать указанные атрибуты и отображать их на целевые специальные атрибуты инструментальных средств. Данная процедура упрощает автоматический обмен данных между различными инструментами.

Также существуют предварительно определенные библиотеки наборов свойств AutomationML. Нормативные положения приведены в 8.5.

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

Рисунок A.22 — Пример набора свойств PropertySet

Соответствующая модель AutomationML приведена на рисунке A.23. В левой части рисунка показана иерархия экземпляров, необходимая для моделирования трех площадок Станции 1. Каждая площадка имеет свой пользовательский набор атрибутов и ссылку на набор свойств PropertySet «Area». Соответствующее описание на языке XML приведено на рисунке A.24.

Рисунок A.23 — Пример набора свойств PropertySet

В правой части рисунка A.23 приведена библиотека набора свойств AutomationML PropertySet. Данная библиотека ролевых классов AutomationML RoleClass содержит класс RoleClass «GeometricData» (геометрические данные), полученный из базового ролевого класса Base-RoleClass «PropertySet». Ролевой класс RoleClass «GeometricData» сам имеет дополнительные производные, определяющие некоторые базовые геометрические свойства. Класс RoleClass с именем «Area» (площадка) определяет атрибуты «Length» (длина) и «Width» (ширина) как атрибуты типа «double (двойной)» и единицу измерения «m» (метр). На рисунке A.25 приведено описание на языке XML, определяющее рассматриваемые атрибуты набора свойств PropertySet.

Рисунок A.25 — Пример библиотеки AutomationML PropertySet в кодах на языке XML

С помощью набора свойств PropertySets экспортирующий инструмент может сохранять пользовательские объекты с пользовательскими атрибутами и объяснять семантику пользовательских атрибутов с помощью процедуры отображения. Данное утверждение поддерживает автоматическую интерпретацию рассматриваемых атрибутов. Таким образом, целевой инженерный инструмент может интерпретировать данные и выполнять преобразование единиц измерения, используемых атрибутами набора свойств PropertySet.

A.2.6 Понятие «Процесс — Продукт — Ресурс»

В процессе накопления практического опыта структурирования комплексных инженерных данных технологической установки установлено, что необходима трисекция данных на ресурсы, процессы и продукты. Рассматриваемое понятие используется в различных областях, например для цифровых производственных инструментальных средств (цифровая модель производства) в соответствии с МЭК 62264 на уровне системы организации производства (MES).

Ресурсы — это центральный компонент рассматриваемой модели. Они обеспечивают производство и обработку продукта. В языке AutomationML ресурс — это сущность, используемая для производства, включая установки, роботов, станки, их состояние, оборудование, возможные сообщения и т.д. Ресурсы могут быть как аппаратными компонентами производственной системы, так и программным обеспечением данной системы (например, система SCADA). В языке AutomationML ресурсы обычно моделируются в иерархии производственной установки, образуя ее топологию.

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

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

В каждом случае представления ресурсов, продуктов и процессов связаны друг с другом (см. рисунок A.26). Корректным назначением для процесса «transport» является ресурс «conveyor» (конвейер). Ресурс «press» (прессование) обеспечивает «scrap cubes» (спрессованные отходы). Процесс «welding» (сварка) обеспечивает «weld» (сварку) двух «metal» (металлических заготовок).

- процесс;

- ресурс;

- продукт;

Рисунок A.26 — Базовые элементы понятия

Для создания связей между указанными элементами требуется наличие интерфейса. Для этого язык AutomationML определяет стандартный класс интерфейсов PPRConnector (см. рисунок A.27). Положения, касающиеся коннектора PPRConnector, рассмотрены в 6.3.5. С помощью данного интерфейса могут быть установлены связи между элементами, включающие стандартные внутренние связи CAEX InternalLinks (см. 5.6.6). Таким образом, ресурсы могут быть связаны с продуктами, которыми можно манипулировать.

A.2.6.2 Пример

Следующий пример (см. рисунок A.28) иллюстрирует использование данного понятия в языке AutomationML. Оно включает два конвейера (C1 и C2), поворотную платформу (TT1) и робота (RB1). Это ресурсы производственной установки. Робот устанавливает колеса на автомобиль, колеса и автомобиль — продукты. Производственные процессы в рамках рассматриваемого примера: транспортирование, поворот платформы, сборка.

- выпуск продукта;

- источник продукта;

- ресурс;

- продукт;

- направление процесса

На языке AutomationML понятие «Процесс — Продукт — Ресурс» моделируется с помощью понятия роли CAEX [см. МЭК 62424 (подраздел A.2.9)] и соотношений между элементами (см. 5.6.6). Наборы элементов с назначенными ролями «Ресурс», «Продукт» или «Процесс» разбиваются на пары. Это означает, что ресурс не может быть и продуктом, и процессом одновременно. Соответствующие классы ролей являются частью библиотеки базового ролевого класса AutomationMLBaseRoleClassLib (см. рисунок A.29 и 6.4).

Рисунок A.29 — Роли AutomationML, необходимые для понятия «Процесс — Продукт — Ресурс»

В рассматриваемом примере (см. рисунок A.28) роль «Ресурс» назначена конвейеру, роботу и поворотной платформе. Автомобилям и колесам назначена роль «Продукт». Роль «Процесс» соответствует процессам транспортирования, поворота платформы и сборки. Все элементы хранятся на соответствующем поддереве (см. рисунок A.30). Порядок применения процессов, продуктов и ресурсов явно выражается связующими элементами, установленными между соответствующими интерфейсами типа «Order» (это не показано на рисунке, чтобы его не загромождать).

Рисунок A.30 — Элементы рассматриваемого примера

Каждый элемент (в рассматриваемом примере) имеет интерфейс коннектора PPRConnector. Полные представления связующих элементов представлены на рисунке A.31. Непрерывные линии — это связи ресурсов с процессами. Точечные линии — это связи процессов с продуктами. Штриховые линии — это связи ресурсов с продуктами. Схема представляется достаточно сложной, поэтому (для простоты) избыточные связи опущены.

- процесс (P1);

- ресурс (R);

- продукт (P2);

- PPRConnector;

- внутренняя связь (RP1);

- внутренняя связь (P1P2)

Рисунок A.31 — Связи, рассматриваемые в примере

На рисунке A.32 данный пример рассмотрен с точки зрения ресурса. Поэтому нужны только 12 связей из их общего количества, равного 19. Конвейер «C1» соединен с продуктом «Автомобиль без колес 1» (см. также поворотную платформу «TT1» и конвейер «C2»). Так же как робот устанавливает колеса на автомобиле на конвейере «C2», робот «RB1» соединен с продуктами «Автомобиль без колес 1», «Автомобиль с колесами 1» и «Колеса 1». Дополнительно конвейер «C2» связан с продуктом «Автомобиль с колесами 1». Процесс транспортирования «Транспорт 1» связан с конвейером «C1». Процессы транспортирования «Транспорт 2» и «Транспорт 3» связаны с конвейером «C2». Процесс «Сборка 1» связан с роботом «RB1». Процесс «Поворот 1» связан с поворотной платформой «TT1». Связи продуктов с процессами (точечные линии на рисунке A.31) могут быть получены из других существующих связей. Данную блок-схему можно произвольно поворачивать, продукты и процессы блок-схемы можно произвольно перемещать.

- процесс (P1);

- ресурс (R1);

- продукт (P2);

- PPRConnector;

- внутренняя связь (RP1);

- внутренняя связь (P1P2)

Рисунок A.32 — Рассмотрение примера с точки зрения ресурса

На рисунке A.33 приведено дерево рассматриваемого объекта AutomationML. Внутренняя связь InternalLink между конвейером «C1» и процессом «Транспорт 1» вынесена отдельно.

InstanceHierarchy на языке AutomationML

Соответствующая модель на языке XML приведена на рисунке A.34. На первом уровне примера приведены три базовых элемента («Ресурсы», «Процессы», «Продукты»), моделируемые как внутренние элементы в формате CAEX InternalElements.

InternalElements

Ниже объекта «Resource» расположены четыре компонента: два конвейера, поворотная платформа и робот. Они также имеют тип «InternalElements» (внутренний элемент). Данные компоненты имеют наружный интерфейс (коннектор) ExternalInterface PPRConnector. Они назначают ролевой класс «Resource». Процессы и продукты имеют интерфейс, их роли распределены. Для организации связей между элементами объекты InternalLinks обычно располагают на одном уровне как самые главные базовые элементы. Рассматриваемые связи показаны на языке XML на рисунке A.35.

InternalLinks

Полный обзор понятий в рамках рассматриваемого примера приведен на рисунке A.36.

InstanceHierarchy рассматриваемого примера

В добавление к МЭК 62424:2008 (подраздел A.2.9) язык AutomationML обеспечивает возможность поддержки сразу нескольких ролей для экземпляра одного объекта. Рассмотрение сразу нескольких ролей имеет смысл, если данный объект имеет несколько функциональных возможностей.

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

Рисунок A.37 содержит пример, в котором объект «MultiDevice01» имеет три атрибута: «Fax-BoudRate», «PrintSpeed (скорость печати)», «FaxSpeed» (скорость передачи сообщения) и два интерфейса: «PowerSupply» (питание) и «USB» (USB-интерфейс)». Объект «MultiDevice01» поддерживает три роли: «Printer» (принтер), «Fax» (факс), «Scanner» (сканер). Роль со ссылочным тегом «RefBaseRoleClassPath» (ссылочный путь доступа к базовому ролевому классу) для соответствующего элемента требований RoleRequirement является базовой. Соответствующий XML-код приведен на рисунке A.38.

Атрибуты и интерфейсы, принадлежащие объекту «MultiDevice01», должны отображаться на атрибуты и интерфейсы всех трех ассоциированных ролей. Это производится с помощью объекта отображения CAEX MappingObject в соответствии с МЭК 62424 (подраздел A.2.10), который дает информацию об атрибуте роли (интерфейсе), о порядке ассоциации рассматриваемого экземпляра атрибута (интерфейса). Чтобы различать атрибуты различных ролей (имеющих одинаковые имена), имя роли включается в определение отображения (за исключением базовой роли, указанной в пути доступа «RefBaseRoleClassPath»). Пример описания необходимых атрибутов и интерфейсов, а также порядка их отображения на экземпляры атрибутов и интерфейсов приведен на рисунке A.37.

Рисунок A.37 — Пример пользовательского экземпляра,

Представление рассматриваемой структуры на языке AutomationML приведено на рисунке A.38.

несколько ролей на языке AutomationML

Соответствующие библиотеки ролевых классов AutomationML и их представление на языке XML приведены на рисунках A.39 и A.40.

Рисунок A.39 — Библиотека ролевых классов

Рисунок A.40 — Код на языке XML для библиотеки ролевых классов AutomationML

(справочное)

B.2 Библиотека класса интерфейса AutomationMLInterfaceClassLib

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

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ НАЦИОНАЛЬНЫМ СТАНДАРТАМ

Таблица ДА.1

БИБЛИОГРАФИЯ