ГОСТ Р ИСО 18435-3-2016. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Интеграция приложений для диагностики, оценки возможностей и технического обслуживания. Часть 3. Метод описания интеграции приложений
Актуально на 02.11.2026.
Как цитировать: "ГОСТ Р ИСО 18435-3-2016. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Интеграция приложений для диагностики, оценки возможностей и технического обслуживания. Часть 3. Метод описания интеграции приложений". ГОСТ Р ИСО 18435-3-2016. https://bukva.ai/docs/standart-gost-r-iso-18435-3-2016
(утв. и введен в действие Приказом Росстандарта от 05.12.2016 № 1932-ст)
Примечание
Документ введен в действие с 01.06.2017.
Утвержден и введен в действие
Приказом Федерального агентства
по техническому регулированию
и метрологии
от 5 декабря 2016 г. № 1932-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ
ИНТЕГРАЦИЯ ПРИЛОЖЕНИЙ ДЛЯ ДИАГНОСТИКИ, ОЦЕНКИ ВОЗМОЖНОСТЕЙ
И ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ
МЕТОД ОПИСАНИЯ ИНТЕГРАЦИИ ПРИЛОЖЕНИЙ
Industrial automation systems and integration. Diagnostics,
capability assessment and maintenance applications
integration. Part 3. Applications integration
description method
1 июня 2017 года
1 ПОДГОТОВЛЕН ООО «НИИ экономики связи и информатики „Интерэкомс“ (ООО „НИИ „Интерэкомс“) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4»
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 5 декабря 2016 г. № 1932-ст
4 Настоящий стандарт идентичен международному стандарту ИСО 18435-3:2015 «Системы промышленной автоматизации и интеграция. Интеграция приложений для диагностики, оценки возможностей и технического обслуживания. Часть 3. Метод описания интеграции приложений» (ISO 18435-3:2015 «Industrial automation systems and integration — Diagnostics, capability assessment and maintenance applications integration — Part 3: Applications integration description method», IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте национального органа Российской Федерации по стандартизации в сети Интернет (www.gost.ru)
В комплексе стандартов ИСО 18435 определен набор методов интеграции приложений для диагностики, оценки возможностей и технического обслуживания при решении задач производства, контроля и выполнения технологических операций.
ИСО 18435-1 представляет общий обзор элементов (см. рисунок 1), правил и методов описания требований к автоматизации интеграционных приложений. Элементы включают основные аспекты по автоматизации интеграционных приложений и связи между ключевыми аспектами. В правилах описывается порядок информационного обмена для поддержания интероперабельности в рамках приложения и между приложениями. Особое внимание уделяется производственным операциям и операциям по технической поддержке домена, включая деятельность по оценке возможностей.
В ИСО 18435-2 приводятся детальные определения элементов матрицы обмена данными между приложениями (AIME) и структуры элементов матрицы домена приложения (ADME) и связи между ними. В частности, приводятся шаги для создания ADME-элементов, которые поддерживаются конкретной комбинацией AIME-элементов.
В настоящем стандарте описан рекомендуемый метод, основанный на использовании шаблонов и предназначенный для описания интероперабельности приложений в двух или более доменах автоматизации на предприятии, на всех функциональных и ресурсных иерархических уровнях предприятия. При этом основное внимание уделено производственным процессам и работам по техническому обслуживанию (включая ремонт).
Унифицированный язык моделирования (UML) используется для представления требований к обмену информацией, связанных с интероперабельностью и интеграцией производственных (цеховых) приложений (в частности, для диагностики, управления, технического обслуживания и производства).
Основной целью настоящего стандарта является определение способа выражения информационного обмена:
- затрагивающего процессы, оборудование, операторов, материалы и другие активы средств автоматизации;
- между системами управления и производственными системами и различными системами, используемыми для диагностики и технического обслуживания с целью обеспечения возможности управления активами.
Предполагаемые выгоды от применения данного способа выражения информационного обмена заключаются в:
- облегчении определения спецификаций и закупки открытых систем, которые поддерживают интероперабельность между приложениями для диагностики и технического обслуживания;
- сокращении сроков разработки технических решений по диагностике и техническому обслуживанию, которые непосредственно связаны с качественно определенными требованиями к интеграции;
- предоставлении средств классификации, предназначенных для реализации, верификации интероперабельности и интеграции различных приложений.
В настоящем стандарте определена методология профилирования, предназначенная для использования шаблонов интероперабельности (согласно ИСО 18435-2) и описывающая структуру и применение ADME- и AIMEs-элементов, а также открытого технического словаря (OTD), с целью поддержания процессов информационного обмена.
В частности, в настоящем стандарте приведены рекомендации по профилированию обмена информацией между двумя приложениями путем установления контекста, передачи (информации) и контента, определенных в ИСО 18435-2.
Настоящий стандарт предназначен для его применения совместно с ИСО 18435-1 и ИСО 18435-2.
В настоящем стандарте используются ссылки на следующие стандарты.
ISO 8000 (all parts), Data quality (Качество данных (все части ISO 8000))
ISO/IEC 10646:2014/Amd.1:2015, Information technology. Universal Coded Character Set (UCS) (Информационные технологии. Универсальный набор кодированных символов (UCS))
ISO/IEC 10646:2014, Information technology. Universal Coded Character Set (UCS). Amendment 1: Cherokee supplement and other characters (Информационная технология. Универсальный набор кодированных знаков. Изменение 1. Дополнение к языку чероки и другим знакам)
ISO 15745-1:2003, Industrial automation systems and integration. Open systems application integration framework. Part 1: Generic reference description (Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 1. Общее эталонное описание)
ISO 15745-1:2003/Amd.1:2007, Industrial automation systems and integration. Open systems application integration framework. Part 1: Generic reference description. Amendment 1 (Системы промышленной автоматизации и интеграция. Прикладная интеграционная среда открытых систем. Часть 1. Общее эталонное описание. Изменение 1)
ISO 18435-1:2009, Industrial automation systems and integration. Diagnostics, capability assessment and maintenance applications integration. Part 1: Overview and general requirements (Системы промышленной автоматизации и интеграция. Интеграция приложений для диагностики, оценки возможностей и технического обслуживания. Часть 1. Обзор и общие требования)
ISO 18435-2:2012, Industrial automation systems and integration. Diagnostics, capability assessment and maintenance applications integration. Part 2: Descriptions and definitions of application domain matrix elements (Системы промышленной автоматизации и интеграция. Интеграция приложений для диагностики, оценки возможностей и технического обслуживания. Часть 2. Описания и определения элементов матрицы домена приложения)
ISO/TS 29002 (all parts), Industrial automation systems and integration. Exchange of characteristic data (Промышленные автоматические системы и интеграция. Обмен характеристическими данными (все части ISO/TS 29002))
В настоящем стандарте используются термины и определения, установленные в ИСО 18435-1 и ИСО 18435-2, а также следующие термины с соответствующими определениями.
3.1 онтология (ontology): Определенно выраженный и согласованный перечень концепций (понятий) в предметной области не зависящий от области их конкретного применения.
[ИСО 13584-511:2006, определение 3.1.20]
ADME — элемент матрицы домена приложения (Application Domain Matrix Element);
AIME — элемент матрицы обмена данными между приложениями (Application Interaction Matrix Element);
CBM — техническое обслуживание и ремонт по состоянию (Condition-Based Maintenance);
OTD — открытый технический словарь (Open Technical Dictionary);
UML — унифицированный язык моделирования (Unified Modelling Language);
XML — расширяемый язык разметки (eXtensible Markup Language).
5 Методы описания интеграции приложений
5.1 Введение в концепцию интеграции приложений
5.1.1 Общие сведения
Требования клиента к интеграции приложений определяют профили обмена информацией, которые необходимы для выполнения требований к интероперабельности приложений. Для разработки требуемых приложений необходимо определить предметные области интересов существующих клиентов.
В разделе 5 установлен метод определения информации, содержащейся AIME- и ADME-элементах для формулирования требований к обмену информацией (с использованием шаблонов, введенных в ИСО 18435-2). Применение этого метода обеспечивает интероперабельность различных приложений в заданном контексте. Поскольку указанная методология используется для интеграции дополнительных приложений из различных областей, данный метод можно использовать для верификации интероперабельности профилей обмена информацией (с использованием AIME-структуры), как того требует пользователь. Рисунок 2 иллюстрирует итеративный процесс верификации (планируемой) интероперабельности для интеграции приложений.
Общая структура профилей информационного обмена между приложениями изображена на рисунке 3. Методы оценки совместимости AIME-профилей, поддерживающих обмен информацией, будут зависеть от контекста и соответствующих предметных областей.
Стратегическая цель диагностики и технического обслуживания зависит от целей интеграции различных доменов приложений (см. рисунок 4), а ее описание должно включать определение соответствующих активов, для которых эта цель определена, а домены приложений рассмотрены.
Метод описания профилей информационного обмена зависит от контекста, выбираемого в соответствии с обменом информацией внутри или между доменами. Профили потенциальных возможностей ресурсов по поддержанию обмена информацией должны описываться AIME-элементом.
Примечание - Обмен информацией между выделенными ресурсами и их определение могут быть описаны с помощью диаграммы последовательности операций (в соответствии с ИСО 18435-2 (5.2)).
Категории доменов приложений определены в ИСО 18435-1 (см. рисунок 4). В настоящем стандарте описаны шаблоны интероперабельности для требований к интеграции, как это установлено в ИСО 18435-1 для интероперабельности приложений.
В качестве иллюстрации методики с использованием шаблонов интероперабельности, на рисунке 4 приведено использование диагностических и управленческих (контрольных) доменов приложений.
5.1.2 Требования к интероперабельности различных приложений
Шаблоны интероперабельности, обеспечивающие интероперабельность различных междоменных приложений, должны иметь ссылки либо на соответствующий стандарт, либо на профиль соответствующего стандарта (в соответствии с ИСО 15745) с целью задания контекста интеграционной модели.
Пример 1 — Как показано на рисунке 5, приложение в домене управления может использовать модели МЭК 61512 для описания структуры модели, терминов и определений, используемых в шаблонах интероперабельности для ADME-элемента. Приложение в домене приложения для диагностики может использовать модель ИСО 13374-2 для описания соответствующего диагностического ADME-элемента.
Таким образом, при обмене информацией между различными доменами необходимо указывать контекст, а затем — описание контент-информации, обрабатываемой с помощью механизма передачи информации. Контекст, передача информации и ее контент включаются в ADME-элемент, используя профили технических параметров. Фактический контент при информационном обмене должен определяться этими профилями.
Пример 2 — Диагностическое информационное сообщение (формирование информационного сообщения) согласно ИСО 13374, отправляют в виде события из диагностического приложения в приложение управления серийным производством согласно ИСО 61512.
Термины и определения в информационных моделях должны иметь ссылки на соответствующие стандарты. Терминологию и модели стандартов необходимо определять с использованием понятий (и со ссылками), содержащихся в открытом техническом словаре (OTD). В настоящем стандарте информационные модели и терминология используют концепции открытого технического словаря, как это определено в ИСО/ТС 29002 (приложение A). Использование общего набора моделей и терминов для их применения в различных доменах устанавливают основу для информационного обмена.
Данная методология интеграции приложений позволяет отображать требования к междоменной интероперабельности на различные AIME-элементы для каждого рассматриваемого приложения, а также на ADME-элементы между приложениями.
5.1.3 Требования к внутридоменной интероперабельности
Шаблоны внутридоменной интероперабельности приложений должны использовать общий контекст модели обмена информацией между приложениями.
Пример — Как это показано на рисунке 6, при обмене информацией управляющие и диагностические приложения имеют одинаковый контекст, т.е. представления, термины и определения имеют одну и ту же структуру и значения. Разделы передачи и контента поддерживают синтаксис и семантику, принятые в МЭК 61512.
5.2 Концепция профилирования
5.2.1 Общие сведения
Концепция общего профилирования приведена на рисунке 7. В ИСО 18435-2 определены общие шаблоны для контекста, передачи данных и контента. Информация о шаблоне для профилей внутридоменного обмена информацией — это информация, непосредственно заимствуемая из стандартов на справочные домены (reference domain standards). Для открытых технических словарей (OTD) могут потребоваться ссылки на междоменные профили с целью обеспечения совместимости терминов и определений, связанных с информационным обменом. OTD-словари должны содержать информацию о профилировании справочных доменов с помощью методологии ИСО 15745-1; междоменный обмен информацией может потребовать отображения (мэппинга) концепций из двух технических словарей.
AIME-элемент определяет профиль потенциальных возможностей и предназначен для поддержки требований к обмену информацией относительно ADME-элемента. Профили возможностей для внутридоменных приложений по определению являются функционально совместимыми. Например, профиль устройства и коммуникационные профили соответствуют общему набору спецификаций.
Устройства можно выбирать, а их соответствующие свойства — идентифицировать и соотносить с используемым словарем компонентов (согласно МЭК 61360 [Словарь общих данных (CDD)]. Идентификационные коды классов устройств и идентификационные коды свойств можно использовать для ссылки на общие характеристики компонентов.
Примечание - Описание классов аппаратуры распределения и управления приведены в МЭК 62683, а описания технологического оборудования в МЭК 61987.
Профили потенциальных возможностей для междоменных приложений можно адаптировать к различным устройствам и коммуникационным профилям. Профиль обмена информацией о приложениях определяет предпочтительные профили для контекста и передачи данных в целях обеспечения поддержки этого обмена. Профили потенциальных возможностей, определенные в AIME-элементах, необходимо верифицировать на предмет их совместимости. Поскольку контекст определяется как профиль, ссылающийся на другой профиль, требуется проверка профиля на нескольких уровнях.
5.2.2 Совместимость при обмене внутридоменной информацией
При обмене внутридоменной информацией необходимо использовать те же профили контекста и передачи данных, что и показанные на рисунке 8, что позволит упростить процесс выбора профилей ресурсов.
5.2.3 Совместимость при обмене междоменной информацией
Обмен междоменной информацией требует дополнительной проверки на интероперабельность с целью выбора соответствующих профилей ресурсов для информационного обмена. Контексты должны различаться путем сопоставления этих доменов в соответствии с ИСО 18435-1, а сам контекст должен соотноситься с набором определений, указанных в открытом техническом словаре. Если контексты используют различные открытые технические словари, то необходимо выбрать соответствующие записи из каждого словаря и создать общий контекст.
Выбранные ресурсы в каждом домене следует проверять с целью обеспечения передачи данных с помощью ADME-элемента (см. рисунок 9). Каждый ресурс (например, устройство, средства связи, оборудование, программное обеспечение) должен предоставлять необходимые функциональные возможности, определенные в спецификации на передачу данных.
5.3 Основные требования к интероперабельности при обмене информацией
- определяться в соответствии с открытым техническим словарем;
- использовать понятия, содержащиеся в открытом техническом словаре, который должен соответствовать требованиям ИСО/ТС 29002;
Примечание 1 — В ИСО/ТС 29002 содержится базовый набор требований, предъявляемых к открытым техническим словарям. Путем использования ИСО/ТС 29002 возможно преобразование различных контекстов.
Пример — Категории доменов приведены на рисунке 4.
Примечание 2 — Информация может профилироваться с помощью информационной модели; т.е. характеристические данные при информационном обмене могут соотноситься с общедоступным стандартом.
Примечание 3 — Информационная модель должна указывать назначение и использование информационного обмена, например, предназначен ли информационный обмен для целей проектирования, выполнения операционной деятельности и/или технического обслуживания.
Примечание 4 — Информация, подлежащая обмену, должна иметь формальную спецификацию с синтаксисом, который с помощью компьютера можно проверять на ее соответствие основным заданным характеристикам.
Примечание 5 — В ИСО 8000-120 приведены требования к источнику данных и их регистрации, т.е. к предыстории данных и информации о владельце информации (например, о прослеживании по времени и расположении), которая может быть реализована посредством использования раздела передачи данных в ADME-элементе.
5.4 Процедура формирования AIME- и ADME-элементов
5.4.1 Общие сведения
Общая концепция и процедура формирования AIME- и ADME-элементов иллюстрируется примером, приведенным на рисунке 10. Порядок выполнения операций указан только в качестве наглядного примера.
Пример 1 — Процедура формирования AIME- и ADME-элементов приведена на рисунке 10.
Рисунок 10 — Диаграмма, иллюстрирующая процедуру формирования AIME- и ADME-элементов
Данная процедура должна содержать следующие операции:
- определение требований к интероперабельности приложений при информационном обмене;
- определение раздела контента для информационного обмена (с использованием единой информационной модели);
- определение потенциальных ресурсных возможностей и разделов передачи данных (с использованием правил для выбранной интеграционной среды приложений);
- определение идентификаторов для ссылок на AIME- и ADME-элементы (см. приложение A).
Примечание - Механизм передачи данных между приложением-источником и приложением-получателем должен использовать один и тот же коммуникационный сервис; например, если эти приложения имеют общую информационную модель для контента, но не для передачи данных, то одно из приложений должно быть адаптировано для передачи этих данных.
Пример 2 — В случае, если передача данных описана на WSDL и использует web-сервисы, то приложение-источник должно обеспечить обязательный набор функциональных возможностей для выполнения требований приложения-получателя. Альтернативным образом поставщик данных может предложить организовать информационный обмен, использовав стандарт на промышленную сеть связи fieldbus. Механизм передачи данных будет осуществляться с помощью одного из fieldbus-сервисов.
5.4.2 Требования к интероперабельности приложений
5.4.2.1 Общие сведения
Требования к интероперабельности в общем контексте определяют с точки зрения заинтересованности или потребности клиента/поставщика, например, с использованием конкретного стандарта на магистральную шину (см. МЭК 61784), конкретной модели устройства (см. ИСО 15745-3), конкретного стандарта на приложения (см. МЭК 61512) или конкретного интерфейса (см. ИСО 13374-2). Целью этого определения является применение единого набора заданной лексики.
Интероперабельность будет обеспечиваться по завершении выполнения операций, описанных в следующих подпунктах.
5.4.2.2 Определение потенциальных приложений и их доменов
Необходимо определить потенциальные приложения и закрепить их за доменами в соответствии с ИСО 18435-1 (5.4). Необходимо также определить домен (домены), участвующие в обмене информацией.
Пример - С помощью ИСО 18435-2 (приложение B) за приложением, связанным с робототехническим мониторингом (Robot Monitoring), закрепляется идентификатор категории домена D1.2, а за приложением, связанным с робототехническим управлением (Robot Control) — идентификатор D1.1.
Примечание - Идентификатор категории домена, например, D1.2 (см. ИСО 18435-1, 5.4.8) используют для формирования AIME-элемента.
5.4.2.3 Идентификация процессов
Необходимо определить профили AIME-процесса (см. ИСО 18435-2, 6.2.3) для потенциальных приложений.
Пример 1 — Используя ИСО 18435-2 (приложение B), приложение Robot Monitoring можно связать с процессом RobotConditionMonitoring, а приложение Robot Control — с процессом MotionControl.
Необходимо определить профиль общего AIME-ресурса (см. ИСО 18435-2, 6.2.3).
Пример 2 — Используя ИСО 18435-2 (приложение B), приложение Robot Monitoring можно связать с ресурсом PLC-контроллера, а приложение Robot Control — с ресурсами PLC-контроллера, сервопривода и устройства контроля вибраций.
5.4.2.4 Выбор/формирования информационных моделей
Термины и определения информационных моделей должны иметь ссылки на соответствующие стандарты. Использование общего набора моделей и терминов для применения в различных доменах создает основу для информационного обмена.
Пример - Используя ИСО 18435-2 (приложение B), приложение Robot Monitoring можно связать с конкретным отраслевым стандартом на мониторинг текущего состояния согласно ИСО 13374.
С помощью концепций из открытого технического словаря (OTD) необходимо идентифицировать и соотносить терминологию и модели стандартов. В настоящем стандарте следует использовать информационные модели и терминологию, содержащиеся в открытом техническом словаре согласно ИСО/ТС 29002 (приложение A).
5.4.2.5 Определение критериев интеграции
При обмене информацией следует указывать интеграционную среду приложений.
Примечание 1 — В ИСО 15745-1 определен набор правил и элементов, которые составляют основу для интеграции приложений. Набор элементов и правил формирования приложений, систем и компонентов следует согласовывать в среде приложений.
Пример - Используя ИСО 18435-2 (приложение B), выражение (элемент) MEidentification (например, ADME-элемент) вместе с MESource (ИСО) могут описывать интеграционную среду ссылочных приложений.
Если обмен информацией выполняется между приложениями, описанными с использованием различных способов интеграции приложений, то необходимо устанавливать набор правил и элементов, общих для обеих сред интеграции.
Примечание 2 — Разработка общего набора правил для обеих сред интеграции выходит за область рассмотрения настоящего стандарта.
5.4.3 Определение раздела контента
Контент ADME-элемента для информационного обмена необходимо определять с помощью единой информационной модели.
Пример 1 — Используя ИСО 18435-2 (приложение B), раздел контента будет описывать имя информационного обмена, параметры и осуществляющиеся взаимодействия в рамках этого обмена.
Пример 2 — В приложениях C и D приведены примеры использования контента для идентификатора категории домена (обмен D1.1 — D1.2).
5.4.4 Определение требований к ресурсам и передаче данных
Основываясь на требованиях к приложениям и ресурсным возможностям, необходимо определять разделы контекста и передачи данных, с использованием выбранной интеграционной среды приложений.
В разделе передачи данных AIME-элемента определен профиль ресурсов, который будет обеспечивать необходимые для данного приложения функциональные возможности.
Пример 1 — Используя ИСО 18435-2 (приложение B), раздел ресурсов обеспечивает профилирование этих ресурсов, необходимых для поддержки информационного обмена, например, PLC-контроллера.
В разделе передачи данных AIME-элемента определены конкретные коммуникационные требования, необходимые для данного приложения. Общее выражение informationType должно быть определено в обоих AIME-элементах. Набор выражений ChannelType, roleType и participantType необходимо определять в соответствии с ИСО 18435-2 (6.2.4).
Пример 2 — Используя ИСО 18435-2 (приложение B), раздел передачи данных обеспечивает профилирование типа канала, который поддерживается конкретной интеграционной средой приложений.
Примечание 1 — Раздел передачи данных способен профилировать различные типы каналов, которые поддерживаются конкретной интеграционной средой приложений. Если эта среда поддерживает различные типы каналов, то выражение informationType будет иметь общую семантику со всеми выражениями ChannelType(s).
Примечание 2 — Выражение roleType определяет сервисы для ресурса (например, описание сервиса на языке описаний Web-сервисов (WSDL)).
5.5 Требования к AIME-элементу
5.5.1 Общие сведения
AIME-элементы формируются в соответствии с требованиями к ресурсам, которые в свою очередь определяются требованиями к интероперабельности приложений. В диагностических приложениях, в которые включены оборудование/устройства/программное обеспечение, перед началом информационного обмена необходимо предпринять ряд мер.
5.5.2 Подробные требования к AIME-элементу
AIME-элемент должен поддерживать следующие аспекты:
- Выбор: первый этап заключается в выборе соответствующего оборудования/устройств/профилей программного обеспечения, которые необходимы для поддержки информационного обмена. Профили оборудования/устройств/программного обеспечения необходимо выбирать с учетом требований, зависящих от требований к ресурсам и передаче данных (см. 5.4.4). Типичные приложения, предназначенные для поддержки информационного обмена, требуют выбора соответствующих профилей.
Пример 1 — В Приложении D приведен пример профиля оборудования/устройств для формирования AIME-элемента, который отвечает требованиям 5.4.4.
Пример 2 — В ИСО 16100 описаны профили потенциальных производственных возможностей программного обеспечения.
- Конфигурирование: на этом этапе определяют конфигурационные параметры устройств/оборудования/программного обеспечения, удовлетворяющие требованиям, предъявляемым к информационному обмену. Конкретный набор операций по конфигурированию необходим для выполнения требований к передаче данных и контексту, установленных в 5.4.4.
- Деятельность: на этом этапе определяют сценарии эксплуатации процессов информационного обмена между приложениями. Оперативные сценарии определяют вид выражения informationType и взаимодействия, которые должны поддерживать интероперабельность приложений. Определение типа параметра устанавливается с помощью соответствующего технического словаря.
Пример 3 — В приложении B приведен пример оперативной информации, подлежащей обмену и отвечающей требованиям 5.4.4.
В приложении A рассмотрены требования к заданию типа параметра и к определениям экземпляров класса.
5.6 Формирование ADME-элемента
5.6.1 Общие сведения
Для описания взаимосвязей между приложениями ADME-элементы формируют с использованием AIME-элементов.
Каждому производственному ресурсу следует присваивать уникальные идентификационные номера (с помощью стандартного метода, например, описанного в ИСО/ТС 29002).
По завершении определения ADME- и AIME-элементов в соответствии с ИСО 18435-2 и критериями, указанными в ИСО 18435-1 (5.3), приложения будут считаться функционально совместимыми.
5.6.2 Выбор технического словаря
Технический словарь, используемый в каком-либо приложении, необходимо выбирать и определять в контексте ADME-элемента.
Пример — В приложении A приведен пример выбора технического словаря в разделе контента ADME-элемента.
5.6.3 Выбор среды приложения
Среда приложения, используемая в приложении, должна выбираться и указываться в разделе контента ADME-элемента.
Пример — В приложении A приведен пример выбора прикладной среды (в разделе контента ADME-элемента).
5.6.4 Раздел контента
Каждый элемент в данном разделе следует описывать в соответствии с A.6.
6 Соответствие настоящему стандарту
Любое приложение можно считать соответствующим настоящему стандарту, если документация на шаблоны контекста, передачи данных и контента, соответствует требованиям ИСО 18435-2, а также требованиям, указанным в настоящем стандарте.
Примечание — В настоящем стандарта содержатся рекомендации по использованию шаблонов, описанных в ИСО 18435-2, с использованием концепций открытого технического словаря (см. приложение A).
ОНТОЛОГИЯ В AIME/ADME-ЭЛЕМЕНТАХ
A.1 Общие концепты для открытого технического словаря (OTD)
Точное количество терминов необходимо определить в соответствии с ИСО 18435-2. Определения этих терминов могут вводиться в открытый технический словарь (OTD), использование которого позволяет связывать идентификаторы концептов с соответствующими терминами. Поскольку в любом конкретном домене может оказаться более предпочтительным собственный набор терминов (при неизменных концептах), возможно установление соответствия между доменами. Конкретный набор терминов и их использование в данном домене можно соотносить с онтологией данного домена. Использование «руководства по идентификации» способно обеспечить соответствие между OTD-словарем и конкретной онтологией домена.
Примечание - В ИСО/ТС 22745-30 описаны методы подготовки и представления руководств по идентификации (или требований к данным), а в ИСО/ТС 22745-40 — методы создания каталогов. Все требования можно определять для онтологии домена; конкретное приложение определяет (посредством описания каталога), поддержку конкретных требований к данным.
Термины, определенные в ИСО 18435-2, приведены в таблицах A.2 - A.5. Каждый термин может быть соотнесен с OTD-словарем согласно ИСО/ТС 29002-5.
A.2 Формат идентификатора концепта согласно ИСО/ТС 29002-5
Идентификаторы концептов необходимо определять согласно ИСО/ТС 29002-5 (раздел 7); справочная информация приведена в таблице A.1.
На рисунке A.1 приведен обобщенный формат идентификатора.
Рисунок A.1 — Форма идентификатора
В идентификаторе следует использовать только символы, приведенные в таблице A.1.
В настоящем стандарте термин «буква верхнего регистра» относится к заглавной букве или цифре.
В настоящем стандарте термин «защитный символ» относится к букве верхнего регистра, цифре, двоеточию, точке или символу подчеркивания.
A.2.3 Минимальная длина атрибутов
Если не оговорено иное, то минимальная длина каждого атрибута, определенного в настоящем стандарте, должна составлять 1.
A.2.4 Максимальная длина идентификатора
Максимальная длина идентификатора составляет 290 символов.
Элементы идентификатора определены в ИСО/ТС 29002-5 (раздел 8).
Синтаксис определен в ИСО/ТС 29002-5 (раздел 9).
Строка IRDI в стандартном идентификаторе должна содержать строки RAI, DI и VI, разделенные знаками «решетки» (#).
Строка RAI должна содержать строки ICD, OI, OPI, OPIS и AI, разделенные символами дефиса (-). Строки OPI, OPIS и AI являются необязательными; если они опущены, то последние три дефиса также необходимо опустить. Если опущены строки OPIS и AI, то необходимо опустить последние два дефиса. Если опущена строка AI, то необходимо опустить последний дефис.
Пример - Ниже приведены некоторые правильные и неправильные строки RAI.
Типами концептов, определенными в ИСО/ТС 29002-5 (раздел 6), являются следующие: класс, свойство, тип данных, документ и онтология.
Разделы заголовков для AIME- и ADME-элементов определены с помощью следующих наборов выражений (элементов) (см. таблица A.2).
Разделы контекста AIME- и ADME-элементов определены с помощью следующих наборов выражений (элементов) (см. таблица A.3).
A.5 Онтология «Передача данных»
AIME- и ADME-элементы передачи данных определены с помощью следующих наборов выражений (элементов), а пример использования онтологий для обмена информацией между доменами приведен в таблице A.4.
AIME-элементы для контентов определены с помощью следующих наборов выражений (элементов) (см. таблицу A.5):
ПРИМЕР ОБМЕНА ИНФОРМАЦИЕЙ ДЛЯ НАСОСА С ПРОГРАММНЫМ УПРАВЛЕНИЕМ
Для совершенствования существующего управляющего насосом приложения необходимо ввести в него новое диагностическое приложение, технические требования к которому могут разрабатываться на основе соответствующих диагностических показателей, получаемых при оценке процесса (см. рисунок B.1).
Рисунок B.1 — Диаграмма, характеризующая стратегию диагностики
B.2 Пример интеграции диагностического приложения насоса
Диаграмма последовательности операций (см. рисунок B.2) отражает простое взаимодействие типа «запрос/ответ» между управляющими и диагностическими приложениями для насоса. ADME-элемент поддерживает обмен информацией между приложениями, используя для этого функциональные возможности ресурсов, идентифицированные в AIME-элементе каждого из приложений. В данном сценарии управляющее приложение насоса запрашивает диагностическую информацию из соответствующего диагностического приложения, после чего первое из приложений может соответствующим образом корректировать режим работы насоса (который в данном примере не рассматривается).
Рисунок B.2 — Простой обмен информацией между приложениями
В B.3 и B.4 приведен пример набора из AIME-элементов для ресурсов управления и диагностики насоса, в B.5 приведен пример ADME-элемента для комплексного применения насоса с программным управлением, а в B.6 - пример описания веб-сервиса, предназначенного для обмена информацией.
B.3 AIME-элемент управления насосом
Ниже приведен пример AIME-элемента, предназначенного для управления насосом.
B.4 AIME-элемент диагностики состояния насоса
Ниже приведен пример AIME-элемента, предназначенного для диагностики состояния насоса.
B.5 ADME-элемент интегрированного приложения для насоса с программным управлением
Ниже приведен пример AIME-элемента для интегрированного приложения, предназначенного для насоса с программным управлением и содержащего управляющее и диагностическое приложения.
B.6 Описание веб-сервиса, предназначенного для обмена информацией
Ниже приведен пример описания веб-сервиса, предназначенного для обмена информации при диагностике состояния насоса и обеспечивающего его мониторинг.
<description xmlns=«http://www.w3.org/ns/wsdl» targetNamespace= «http://www.iso.org/2011/wsdl/pumpMonitorSvc» xmlns:tns= «http://www.iso.org/2011/wsdl/pumpMonitorSvc» xmlns:rms = «http://www.iso.org/2011/schemas/pumpMonitorSvc» xmlns:wsoap= «http://www.w3.org/ns/wsdl/soap» xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:wsdlx= «http://www.w3.org/ns/wsdl-extensions»> This document describes the sample pump monitor service <xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» targetNamespace=«http://www.iso.org/2011/schemas/pumpMonitorSvc» xmlns=«http://www.iso.org/2011/schemas/pumpMonitorSvc»> <xs:element name=«CavInfoRequest» type=«CavInfoRequestType»/> <xs:complexType name=«CavInfoRequestType»> xs:sequence <xs:element name=«pumpType» type=«xs:string»/> <xs:element name=«pumpLocation» type=«xs:string»/> <xs:element name=«checkTime» type=«xs:time»/> </xs:sequence> </xs:complexType> <xs:element name=«CavInfoResponse» type=«CavInfoResponseType»/> <xs:complexType name=«CavInfoResponseType»> xs:sequence |
|---|
| <xs:element name=«pumpType» type=«xs:string»/> <xs:element name=«cavitationDegree» type=«xs:integer»/> </xs:sequence> </xs:complexType> </xs:schema> <operation name=«getCavitationInfo» pattern=«http://www.w3.org/ns/wsdl/in-out» style=«http://www.w3.org/ns/wsdl/style/iri» wsdlx:safe = «true»> <input messageLabel=«In» element=«rms:CavInfoRequest» /> <output messageLabel=«Out» element=«rms:CavInfoResponse» /> <binding name=«pumpMonitorSOAPBinding» interface=«tns:pumpMonitorInterface» type=«http://www.w3.org/ns/wsdl/soap» wsoap:protocol=«http://www.w3.org/2003/05/soap/bindings/HTTP/»> <operation ref=«tns:opVibInfoRequest» wsoap:mep=«http://www.w3.org/2003/05/soap/mep/soap-response»/> <service name=«pumpMonitorService» interface=«tns:pumpMonitorInterface» > <endpoint name=«pumpMonitorEndpoint» binding=«tns:pumpMonitorSOAPBinding» address =«http://www.iso.org/2011/pumpMonitorService»/> |
ПРИМЕР ОПРЕДЕЛЕНИЯ ПЕРЕБОЕВ В РАБОТЕ НАСОСА
Ток в двигателе, превышающий номинальный (указанный на шильдике двигателя) может свидетельствовать о большой перегрузке или режиме торможения, например, при перегрузке конвейера или заклинивании передаточного механизма. Эти состояния могут приводить к перегреву двигателя и повреждению оборудования. В C.1 и C.2 приведен пример набора из AIME-элементов для ресурсов (средств) управления и диагностики состояния насоса. Пример AIME-элемента в C.1 демонстрирует функциональные возможности управления насосом, пример AIME-элементов в C.2 - функциональные возможности при определении перебоев в работе насоса, а пример ADME-элемента в C.3 - функциональные возможности при обмене информацией относительно этих перебоев между двумя приложениями (с использованием локальной сети EtherNet/IP). Рисунок C.1 иллюстрирует процедуру обмена информацией при определении сбоев в работе насоса.
Рисунок C.1 — Обмен информацией при определении перебоев в работе насоса
C.1 AIME-элемент управления насосом
Ниже приведен пример AIME-элемента, предназначенного для управления насосом.
<ISO_AIME xmlns=«http://www.iso.org/aime» xmlns:xsd=«http://www.w3.org/2001/XMLSchema- instance»> <Context_Section> PumpControl Pump_Control_Context |
||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
</Context_Section> <Conveyance_Section> description> |
||||||||||||||||||||||||||||||||||
Ниже приведен пример AIME-элемента, предназначенного для мониторинга состояния насоса. C.3 ADME-элемент определения перебоев в работе насоса Ниже приведен пример обмена информацией при определении перебоев в работе насоса. ОБМЕН ИНФОРМАЦИЕЙ ПО ЛОКАЛЬНОЙ СЕТИ ETHERNET/IP ДЛЯ OPC В D.1 и D.2 приведен пример набора из AIME-элементов для (ресурса) управления насосом и (ресурса) диагностики состояния насоса. Пример AIME-элемента в D.1 характеризует функциональные возможности управления насосом, пример AIME-элемента в D.2 - функциональные возможности при определении сбоев в работе насоса, а в D.3 приведен пример ADME-элемента, предназначенного для обмена информацией относительно этих сбоев с использованием локальной сети EtherNet/IP для OPC-канала. Рисунок D.1 иллюстрирует процесс обмена информацией о сбоях в работе насоса с помощью OPC. Рисунок D.1 — Обмен информацией при определении перебоев в работе насоса с помощью OPC D.1 AIME-элемент управления насосом D.2 AIME-элемент диагностики состояния насоса D.3 ADME-элемент обмена информацией с использованием устройства сопряжения локальной сети EtherNet/IP с OPC СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ
| ||||||||||||||||||||||||||||||||||
