База ГОСТовallgosts.ru » 25. МАШИНОСТРОЕНИЕ » 25.040. Промышленные автоматизированные системы

ГОСТ Р ИСО 16100-2-2010 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования

Обозначение: ГОСТ Р ИСО 16100-2-2010
Наименование: Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования
Статус: Действует
Дата введения: 09/01/2011
Дата отмены: -
Заменен на: -
Код ОКС: 25.040.01
Скачать PDF: ГОСТ Р ИСО 16100-2-2010 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования.pdf
Скачать Word:ГОСТ Р ИСО 16100-2-2010 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования.doc

Текст ГОСТ Р ИСО 16100-2-2010 Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования



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


ГОСТРИСО

16100-2—

2010


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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Системы промышленной автоматизации

и интеграция

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

Часть 2

Методология профилирования

ISO 16100-2:2003

Industrial automation systems and integration —

Manufacturing software capability profiling for interoperability —

Part 2: Profiling methodology (IDT)

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

Москва

Стакдартинформ

2014


Предисловие

1    ПОДГОТОВЛЕН Научно-техническим центром ИНТЕК на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

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

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

4    Настоящий стандарт идентичен международному стандарту ИСО 16100-2:2003 «Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств. Часть 2. Методология профилирования» (ISO 16100-2:2003 «Industrial automation systems and integration — Manufacturing software capability profiling for interoperability — Part 2: Profiling methodology»).

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

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0—2012 (раздел В). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок—в ежемесячном информационном указателе «Национальные стан• дарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.nj)

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

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

Содержание

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

Введение

Разработка комплекса стандартов ИС016100 обусловлена необходимостью решения следующих проблем, связанных с:

a)    постоянно увеличивающейся базой решений, зависящих от поставщиков.

b)    трудностями, возникающими у пользователей при применении стандартов:

c)    необходимостью перехода к модульным наборам инструментальных средств интеграции системы;

d)    признанием того, что прикладное программное обеспечение и практический опыт его применения являются интеллектуальным капиталом предприятия.

Комплекс стандартов ИС016100 определяет формат профиля возможностей программного обеспечения. интерпретируемого компьютером в электронно-цифровой форме и не вызывающего трудностей при его чтении человеком, а также устанавливает метод, отражающий основные возможности программного обеспечения на производстве в соответствии с ролями, определенными жизненным циклом производственного приложения, независимо от архитектуры определенной системы или платформы реализации.

Настоящий стандарт разработан Техническим комитетом ИСО/ТК 184 «Системы промышленной автоматизации и интеграция». Подкомитетом ПК 5 «Архитектура, коммуникации и структуры интеграции».

Комплекс стандартов ИСО 16100 имеет общее наименование «Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств» и включает в себя следующие части:

- часть 1. Структура;

•    часть 2. Методология профилирования:

•    часть 3. Службы интерфейса, протоколы и шаблоны возможностей;

•    часть 4. Методы аттестационных испытаний, критерии и отчеты;

•    часть 5. Методология согласования конфигураций профилей с помощью многоцелевых структур классов.

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

Системы промышленной автоматизации и интеграция

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

ПРОГРАММНЫХ СРЕДСТВ Часть 2

Методология профилирования

Industrial automation systems and integration.

Manufactunng software capabifcty profiling for interoperability.

Part 2. Profiling methodology

Дета введения — 2011—09—01

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

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

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

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

ИСО 16100 (все части) Системы промышленной автоматизации и интеграция. Профилирование возможности интероперабельности промышленных программных средств (ISO 16100 (all parts). Industrial automation systems and intention — Manufacturing software capability profiting for interoperability)

REC-xmlschema-1-20010502 Схема языка XML. Часть 1. Структура. Рекомендации W3C от 2 мая 2001 г. (REC-xmlschema-1-20010502. XML Schema Part 1: Structures — W3C Recommendation 02 May 2001)

REC-xmlschema-2-20010502 Схема языка XML. Часть 2. Типы данных. Рекомендации W3C от 2 мая 2001 г. (REC-xmischema-2-20010502. XML Schema Part 2: Datatypes — W3C Recommendation 02 May 2001)

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

8 настоящем стандарте применены термины по ИС016100-1. а также следующие термины с соответствующими определениями:

3.1    ассоциация (association): Семантическое взаимоотношение между двумя или более классификаторами. определяющими связи между их экземплярами.

(ИСО/МЭК19501-1]

3.2    основная спецификация (base specification): Основной стандарт или широко применяемая и доступная спецификация.

3.3    класс возможности (capability class): Элемент метода профилирования возможности, представляющий функциональность и поведение единицы программного обеспечения в отношении программного обеспечения для производственной деятельности.

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

3.4    интеграция профиля возможности (capability profile integration): Процесс, е котором две или более единицы программного обеспечения взаимодействуют с помощью эквивалентных интерфейсов, конфигурируемых в совместимом виде, на что указывают их профили возможностей.

3.5    классификатор (classifier): Механизм, характеризующий поведенческие и структурные свойства.

[ИСО/МЭК 19501-1)

Примечание — Классификатор включает в себя интерфейсы, классы, типы данных и компоненты.

3.6    элемент (element): Элементарная составляющая модели.

[ИСО/МЭК 19501-1)

3.7    сущность (entity): Любая конкретная или абстрактная вещь, представляющая интерес.

[ИСО/МЭК 10746-2)

3.8    интерфейс (interface): Абстракция поведения объекта, состоящего из подмножества взаимодействий этого объекта, с учетом накладываемых ограничений при их возможном появлении.

[ИСО/МЭК 10746-2)

3.9    объект (object): Модель сущности.

[ИСО/МЭК 10746-2)

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

3.10    профиль (profile): Совокупность одной или более основных спецификаций и/или подпрофилей. и в приемлемых случаях идентификация выбранных классов, согласующихся подмножеств, опций и параметров основных спецификаций или лодпрофилей, необходимых для выполнения конкретной функции, деятельности или взаимосвязи.

Примечание — Определение данного термина см. ИСО/МЭК ТО 10000-1.

3.11    роль (role): Специфическое поведение сущности, указанное в определенном контексте и имеющее имя.

(ИСО/МЭК 19501-1)

Примечание — Роль может быть статической (нвпример. конец соединения) или динамической (например. коллективная роль).

3.12    таксономия (taxonomy): Схема классификации профилей ссылок или набора профилей.

[ИСО/МЭК ТО 10000-11

4    Сокращения

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

CORBA — технология построения распределенных объектных предложений (Common Object Request Broker Architecture);

IDL — язык описания интерфейсов (Interface Definition Language):

OMG — рабочая группа по развитию стандартов объектного программирования (Object Management Group);

PSL — язык спецификации процесса (Process Specification Language);

UML — унифицированный язык моделирования (Unified Modeling Language);

XML — язык (расширяемый) гипертекстовой разметки (extensible Markup Language).

5    Метод профилирования возможности

5.1 Концепция профилирования возможности

Основной целью разработки комплекса стандартов ИСО 16100 является обеспечение возможности интероперабельности производственных программных средств разных поставщиков. Концепция профиля возможности для интеграции интероперабельного программного обеспечения изображена на рисунке 1.

TfrrfTi >ш im прогрей ь*от> ебвтМММ{ПО) ГфШИОЯОТМ

информвутииы* погос

•и тр»* - вямиоотнсимник ытю яацм говгьмдаи элементами

Рисунок 1 — Концепция профиля возможности интероперабельности программного обеспечения

Интероперабельность программных продуктов разных поставщиков описывают с точки зрения их возможностей, которые ассоциированы с аспектами функциональности, интерфейса и структуры. Эти аспекты на основе структуры модели системы специфического применения домена, приведенной в ИСО 16100*1. определены в разделах 5 и 6 настоящего стандарта, а подробное описание приведено в ИСО 16100-3.

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

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

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

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

э

Определение профиля возможностей единиц программного обеспечения должно быть зарегистрировано в соответствующей базе данных после проведения аттестационного испытания в соответствии с методом его проведения с использованием абстрактных испытательных комплектов, указанных в ИСО 16100-4.

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

5.2 Процесс профилирования возможности

Часть концепции профиля возможности интероперабельности программного обеспечения (см. рисунок 1), имеющая отношение к процессу профилирования возможности, представлена на рисунке 2.

Единицу программного обеспечения, подлежащую профилированию, анализируют в рамках возможных поддерживаемых вариантов структуры класса возможностей. Описание концепции этой структуры приведено в 6.2.1 настоящего стандарта, а сама структура определена в ИС016100-3.

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

йхяветолрцоЕЯйОя)

лутъЗДтмаа

Профи»

ЯЙМвЮЮОТН

Рисунок 2 — Процесс профилирования возможности интероперабельности


5.3 Процесс анализа требований программного обеспечения

Часть концепции профиля возможности интероперабельности программного обеспечения (см. рисунок 1). имеющая отношение к процессу анализа требований программного обеспечения, представлена на рисунке 3.

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

Нвобадишв

1ЖШ

Рисунок 3 — Процесс анализе требований программного обеспечения


5.4 Выбор и проверка единицы программного обеспечения или процесс ее создания Часть интеграции профиля возможности (см. рисунок 1), имеющая отношение к выбору и проверке (верификации) единицы программного обеспечения или к процессу ее создания, представлена на рисунке 4.

Прпгрг— пвобистро—з мазшооссги

Рисунок 4 — Процесс выбора, проверки или создания единицы программного обеспечения


«моде»-петое аршгахлроцксе;

••■■■■р». -петое, шкурциА тдогого процесса япи)яадш|ий в другой процессе ремах концепции гфофигшроаяния ааякииоет мларслерюльиовп* (си. ридок 1)

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

a)    разработать новую единицу программного обеспечения, соответствующую требованиям профиля:

b)    разложить требуемый профиль на комбинацию нескольких профилей:

c)    пересмотреть требования, предъявляемые к существующим профилям.

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

6 Элементы и правила профилирования возможности

6.1    Таксономия

Ключевым аспектом таксономии профилей возможностей является их способность идентифицировать содержание, которое составляет определение класса возможности. Таксономия должна обеспечивать необходимые средства для взаимного обмена информацией о возможности.

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

6.2    Классы возможностей и их содержание

6.2.1 Содержание класса возможности единицы программного обеспечения

Возможность единицы производственного программного обеспечения должна быть выражена в показателях классов возможностей. Эти классы являются производными от производственных действий. указанных в ИСО 16100-1, рисунок 4. Классы определяют производственную функцию, ресурс и информацию, обрабатываемую единицей производственного программного обеспечения в соответствии с требованиями производственного процесса.

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

a)    тип производственного домена;

b)    тип производственной деятельности, являющейся частью процесса, ресурсы, необходимые для осуществления этой деятельности, и типы информации, которой обмениваются на протяжении деятельности;

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

d)    тип сервисов, протокол и типы данных, необходимые для запуска программного обеспечения:

e)    наименование поставщика, версию программы и историю ее изменений;

f)    выполнение контрольных задач;

д) индексы надежности;

h)    сервисную и поддерживающую политику:

i)    пользовательское соглашение и ценовую политику.

Описание дополнительных требований к содержанию класса возможностей приведено в ИСО 16100-3.

Концептуальная структура класса возможностей приведена на рисунке 5.

Имя класса Атрибуты:

Тил производственного домена Тил производственной деятельности Список типов ресурсов Список типов информации Список дополнительных возможностей Тил функции

Методы

Список поддерживаемых сервисов (см. ИСО 16100-3)


Рисунок S — Концептуальная структура класса возможностей

6.2.2 Домен применения на производстве

6.2.2.1 Модель деятельности по внедрению в производство

В модели деятельности по внедрению в производство специфического домена и трех ее ассоциативных моделях информации, процессов и ресурсов, приведенных на рисунке 4 ИСО 16100-1, учтены общепринятые требования и структура интероперабельности программ для всех единиц программного обеспечения, предложенных в качестве примера основных эксплуатационных характеристик и возможной структуры.

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

Пример — Пример соответствует приведенному в ИСО 16100-1, приложение В:

(А) Производственная деятельность

(АА) Разработка изделия

(АА1) Проектирование изделия

(АА11) Разработка концептуального проекта

(АА111) Определение функции и ограничений изделия

(АА112) Описание поведения изделия

(АА113) Разбиение на части ограничаний функции и поведения

(АА114) Задание конфигурации изделия

(АА12) Разработка рабочего проекта

(АА121) Проектирование системы/компонента

(АА122) /Анализ системы/компонента

(АА123) Оценка проекта системы/компонента

(АА124) Оптимизация проекта

(АА125) Завершение проекта системы/компонента

(АА126) Разработка сборочных чертежей

(АА2) Технологический процесс

(АА21) Разработка концептуального плана процесса

(АА211) Выбор производственного процесса

(АА212) Выбор производственных ресурсов

(АА2121) Выбор станков

(АА2122) Выбор инструментов/зажимных приспособлений (АА2123) Выбор квалифицированных рабочих (АА213) Оценка производственных расходов/времени (АА22) Разработка подробного плана технологического процесса (АА221) Формирование последовательности процесса (АА222) Создание операции

(АА2221) Определение возможности промежуточной механической обработки (АА2222) Спецификация установки компонентов изделия и ресурсов механической обра~ ботки

(АА2223) Вычисление допуска промежуточной механической обработки

(АА2224) Разработка инструкции по механической обработке

(АА223) Определение параметров производства

(АА224) Создание программы управления

(АА2241) Создание траектории перемещения инструментов

(АА2242) Задание параметров управления процессом

(АА2243) Создание программы управления станком

(АА225) Создание маршрута перемещения в цехе

(AA22S1) Определение конфигурации цеха

(АА2252) Определение средств транспортирования

(АА2253) Определение согласованности по времени

(ААЗ) Планирование ресурсов предприятия

(АА4) Закупка ресурсов

(AAS) выполнение производственных заказов

(АА51) Разработка последовательности операций и подробного графика

(АА52) Отправка изделий производства

(АА53) Прокладка маршрута изделий производства и ресурсов

(АА54) Руководство данными/документами цеха

(АА6) Управление оборудованием и технологическим процессом

6.2.2.2    Модель производственного процесса и ее профиль

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

8 модели деятельности с помощью языка моделирования, например IOEFO. описывают требования и поток данных прикладной системы.

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

Каждая модель ресурсов должна быть представлена в виде соответствующего профиля.

6.2.2.3    Модель производственных ресурсов и ее профиль

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

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

Каждая модель ресурсов должна быть представлена в виде соответствующего профиля.

6.2.2.4 Информационная модель производства и ее профиль

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

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

Каждая модель ресурсов должна быть представлена в виде соответствующего профиля.

6.2.3 Вычислительная модель и ее ассоциативный класс

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

6.2.3.1    Представление класса единицы программного обеспечения

6.2.3.1.1    Имя класса

Информационная модель должна иметь наименование и метку в соответствии с зарегистрированной таксономией, номером последовательности и уровнем связанных (целевых) моделей деятельности.

6.2.3.1.2    Атрибуты класса

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

6.2.3.1.3    Операции класса

Операции класса должны быть указаны с сигнатурой и возможностью внешнего сервиса.

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

6.2.3.2 Архитектура программного обеспечения, используемый класс шаблонов программного обеспечения для проектирования

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

Образцы проектирования архитектуры и примеры0 их структуры и ролей:

a)    Архитектура иерархического представления

Пример — Структур»: прикладные программы. которые могут быть разделены не еруппы подзадач, а которых каждая ерулле находится на определенном уровне абстракции. Роль: логический объект на уровне N. предоставляющий услуау для логического объекта на уровне N*1.

b)    Посредническая архитектура

Пример — Структура: распределенные системы программного обеспечения с несвязанными компонентами. которые взаимодействуют путем вызова удвленново сервиса. Роль: клиенты, серверы. брокеры, мосты, проераммы — посредники на стороне клиента, лроереммы — посредники на стороне сервере.

c)    Архитектура «Модель — представление — контроллер»

Пример — Структура: модель содержит функциональные возможности ядра операционной системы и данные, контролирует информацию, выводимую на дисплей для пользователя, улрввляет вводом абстрактного идентификатора попьзователя. Роль: модель, наблюдатель. представление, контроллер.

d)    Схема «Master — Slave»

Пример — Структура: главный компонент распределяет работу между идентичными подчиненными компонентами и вычисляет конечный результат по результатам, возвращаемым зтими подчиненными. Роль: клиент, главный. 1-й подчиненный. 2-й подчиненный.....п-й подчиненный.

e)    Программа-посредник «Proxy»

Пример - Структур»: позволяет клиентом компонента лоддерживвть связь с представителем, а не с самим компонентом. Роль: клиент, посредник, оригинал.

') F. Buschmann et al «Ранет Oriented Software Architecture». John Wiley & Sons. June 2000.

0 Издатель — подписчик

Притер — Структура: один издатель уведоиляет любое число подписчиков об изменениях еао состояния. Роль: издатель, подписчик.

6.2.3.3 Класс сервиса или протокола

Интерфейсы единицы программного обеспечения должны иметь описание, представленное в качестве сервиса {например, в архитектуре иерархического представления логический объект на уровне N должен обслуживать объект на уровне N + 1) или в виде протокола с указанием его типа данных (например. в архитектуре «Клиент — сервер» должны быть указаны интерфейсы клиентов со специальным протоколом доступа к серверу).

6.2.4 Нефункциональные свойства единицы программного обеспечения

6 настоящем пункте приведены свойства единицы программного обеспечения нефункционального представления программы, не соответствующие требованиям 6.2.2 и 6.2.3.

6.2.4.1    Поставщик, версия и история программного продукта

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

6.2.4.2    Вычислительные средства, планируемые для применения

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

a)    процессор — тип процессора является важной характеристикой, но также следует принимать во внимание его производительность, так как слабая производительность может серьезно препятствовать эффективной и своевременной работе программного обеспечения:

b)    операционная система и требуемые опции — подходящая операционная система и необходимая рабочая версия для работы программной части (компонента). Любое свойство, обеспечивающее поддерживание совместимости снизу вверх, может быть включено в эту информацию:

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

d)    память для запуска программы — тип и объем памяти, необходимые для работы программной части вместе с любой другой поддержкой запуска программы:

e)    пространство на диске — тип и объем информационных средств, необходимых дпя хранения форм — источников исполняемой программной части. Эта информация должна включать в себя хранение данных, например запоминающее устройство на диске, необходимое для операционных переменных. результатов обработки и механизмов восстановления после повреждений:

0 многопользовательская поддержка — способность программного обеспечения одновременно взаимодействовать со многими пользователями, клиентами или абонентами;

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

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

6.2.4.3    Измеренная рабочая характеристика программного изделия

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

a)    время работы (время выполнения) с особыми входными данными и ограничения к ним (основные данные функционирования);

b)    число специальных транзакций в единицу времени (объединенные данные функционирования).

6.2.4.4    Данные надежности программного изделия

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

6.2.4 5 Компетенция

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

6.2.4.6 Данные о цене

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

6.3 Шаблоны возможностей и правила

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

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

Пример концептуальной структуры шаблона приведен на рисунке 6. Концептуальная структура шаблона должна состоять из части, общей для всех шаблонов, и части, специфичной для класса возможностей. Формальная структура шаблона определена в ИСО 16100-3.

Common pan Template ID Capability Class Name Software Unit ID Vendor Name Version Number & History Computing Facilities Required Processor

OperatargSystem & Options

Language

Runtime Memory

Disk Space MultiUserSupport RemoteAccess AddUns&Pluglns

Measured Performance of the Unit EiapsedTlme

NumberOfTransectionsPerUnitTime Reliability Data of the Unit UsageHlstory NumberOfShipments intendedSafetyintegntyLevel Certification Body Support Policy Price Data

Reference Dictionary Name NumberOfMethods

Part Specific to Capability Class


Общая часть Идентификация шаблона Имя класса возможностей Идентификация единицы ПО Наименование поставщика Номер версии и история Требуемые вычислительные средства Процессор

Операционные системы и опции Язык

Запоминающее устройство времени прогона программы

Пространство на диске Многопользовательская поддержка Дистанционная выборка Дополнения и сменные платы Измеренная характеристика единицы ПО время работы (истекшее время)

Число транзакций а единицу времени Данные о надежности единицы ПО История применения Число поставок

Планируемый безопасный уровень целостности Орган по сертификации Политика поддержки Данные о цене

Название словаря-справочника Число методов

Часть, специальная для класса возможностей


Рисунок 6—Пример структуры шаблоне

В общую часть должны быть включены следующие элементы:

a)    идентификация шаблона — опознаеатель шаблона объекта;

b)    идентификация единицы программного обеспечения — опознаеатель единицы производственного программного обеспечения, обеспечивающей выполнение производственной функции;

c)    имя справочного словаря — название словаря, содержащего определения классов возможностей;

d)    имя класса возможностей — название класса эталонных возможностей;

e)    число атрибутов профилей — число атрибутов, унаследованных из соответствующего класса возможностей;

f)    число методов — число атрибутов, предусмотренных соответствующим классом возможностей;

д)    количество ресурсов — количество ресурсов, необходимых для программной среды:

h)    число ограничений — число условий, необходимых для выполнения единицы программного обеспечения;

i)    число расширений — число аспектов других единиц программного обеспечения, предоставленных поставщиком;

j)    число нижних уровней —число уровней вложенной структуры или самый нижний уровень иерархии структуры класса эталонных возможностей;

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

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

a)    атрибутов;

b)    методов:

c)    ресурсов, например тип операционной системы;

в) ограничений, например тип архитектуры, образец проекта;

е)    расширений:

f) нижних уровней;

д) субшаблонов.

Шаблоны способностей должны быть указаны с использованием условных обозначений XML для создания схем XML (см. REC-xmlschema-1 -20010502 и REC-xmlschema-2-20010502). Взаимоотношения между шаблонами возможностей должны быть указаны с помощью условных обозначений на языке XML для трансформации схем XML и файлов XML. Если класс возможностей указан в шаблоне и на его основе будут создаваться экземпляры, то созданный экземпляр класса представляет собой объект. Два шаблона возможностей являются идентичными, если их соответствующие атрибуты и операции идентичны. Если атрибуты одного шаблона являются подмножеством атрибутов другого шаблона и операции одного шаблона являются подмножеством операций другого шаблона, то два шаблона возможностей считают совместимыми и совпадающими.

6.4    Профили возможностей и правила

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

Профили возможностей взаимодействий должны быть определены с помощью условных обозначений на языке XML для создания файлов на языке XML. Взаимоотношения между профилями возможностей должны быть обозначены с использованием условных обозначений на языке XML для трансформации файлов на языке XML. Если на шаблон возможности есть ссылки в профиле возможности и данный шаблон заполнен, то заполненный шаблон представляет собой объект профиля.

6.5    База данных профиля единицы программного обеспечения

8 базах данных хранятся следующие элементы, отличающиеся словарными именами и описанные в 6.1—6.4:

a)    таксономии;

b)    классы возможностей;

c)    шаблоны возможностей;

d)    профили возможностей.

Базы данных могут быть структурированы в качестве свободной комбинации четырех вышеуказанных элементов для предоставления необходимых сервисов.

Таксономия должна быть уникальной в таксономическом словаре. Класс возможностей должен быть уникальным в словаре классов. Шаблон возможности должен быть уникальным в словаре шаблонов. Профиль возможности должен быть уникальным в словаре профилей.

6.6    Правила приведения профилей в соответствие

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

a)    анализ единицы программного обеспечения в процессе профилирования возможности (рисунок 2):

b)    декомпозиция требований в процессе анализа требований программного обеспечения (рисунок 3);

c)    поиск базы данных для каждого профиля е процессе выбора и верификации или создания единицы программного обеспечения (рисунок 4).

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

6.7    Критерии интероперабельности

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

7 Соответствие

Требования к соответствию установлены в ИСО 16100-4.

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

Методы ссылок

А.1 Язык XML

Язык расширенной (гипертекстовой) разметки XML обладает свойствами, которые могут быть использованы прямо или косвенно при профилировании возможности программного обеспечения. Язык XML является языком, используемым для выражения лексических элементов документа, представляемого в виде ориентированного графа, в частности, для размещения на web-узле. Лексические элементы могут быть определены пользователем. Язык XML является практическим подмножеством стандартного обобщенного языка разметки SGML (Standard Generalized Markup Language) и обеспечивает разметку страницы тегами подобно языку HTML. Любой документ на языке XML может быть также верифицирован на достоверность XML. Для использования языка XML в профилировании возможности программного обеспечения следует отметить, что XML имеет пространство присваиваемых имен (XML Namespaces) для согласования или регистрации пространства имен.

А.2 Словари, определения и форматы обмене для комплектов программного обеспечения: описание

открытого программного обеспечения и формата определения канала

Описание открытого программного обеспечения7' (OSD) представляет собой словарь, созданный на основе языка XML для описания комплектов программного обеспечения и их зависимости друг от друга. OSD используют в окружающих средах распределения программного обеспечения либо путем скачивания, инициированного пользователем. либо методом автоматической рассылки. OSD может использоваться для распределения программного обеспечения на Web-узле в одном из двух вышеуказанных методов.

Распределение программного обеспечения методом скачиввния требует участия пользователя для нахождения. загрузки и обновления программного обеспечения. Несмотря на то что OSO облегчает автоматизацию загрузки и инсталляции требуемых компонентов программного обеспечения, пользователи Web-узлв должны просматривать страницу HTML, которая инициирует процесс инсталляции программного обеспечения. Ter «08JECT» из спецификации HTML 4.0 используется для рекламы нового программного обеспечения в Web. При обнаружении тега объекта 08JECT в ресурсе OSO агент пользователя, осведомленный об OSD. может автоматически загружать и обновлять необходимые компоненты программного обеспечения.

Формат определения канала CDF также создан не основе языка XML и предоставляет словарь метаданных, необходимых для описания взаимоотношений между страницами HTML и другими web-ресурсами. Клиенты, осведомленные о CDF. могут использовать методы интеллектуального опроса (smart-pull) для автоматической загрузки web-содержания (контента), а серверы, осведомленные о CDF. могут реализовать механизмы web-вещания (true— push) для автоматической передачи содержания (контента) от клиента к серверу. Таким образом. COF предоставляет язык передачи содержания (push), тем самым обеспечивая идеальное средство для приведения в действие принудительной рассылки (push) или автоматического распределения программного обеспечения. Для того чтобы COF активировал программное обеспечение (push), файл COF должен содержать ссылки на комплекты программного обеспечения на основе OSD.

О SO включает в себя обширный словарь, с помощью которого приводят описания элементов программного обеспечения. Это описание включает в себя следующее:

SOFTPKG:    определяет общий пакет программного обеспечения.

IMPLEMENTATION: используется для описания реализации пакета программного обеспечения:

DEPENDANCY. указывает зависимости между распределениями программного обеспечения или его

TITLE.


ABSTRACT:


LICENSE:


CODEBASE:

OS.


OSVERSION:

PROCESSOR:

LANGUAGE:


компонентов:

представляет заголовок или интуитивно понятное «дружественное» имя пакета программ.

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

определяет местоположение лицензионного соглашения или уведомления об авторском праве:

определяет местоположение архива распространения программного обеспечения: указывает требуемую операционную систему: определяет необходимую версию операционной системы: определяет необходимый естественный язык пользовательского интерфейса: представляет заголовок или интуитивно понятное «дружественное» имя пакета программного обеспечения:


*| Van Hoff и др.. 1997.

определяет требуемую виртуальную вычислительную машину; определяет необходимый объем памяти времени прогоне программы; определяет необходимый объем пространства на диске: определяет тип реализации.

VM:


MEMSIZE:

DISKSIZE;

IMPLTYPE;


А.З Сервисы распространений программного обеспечения: распределенная обработка в открытой

системе и технология построения распределенных объектных приложений

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

Рабочая группа по развитию стандартов объектного программирования (OMG) является некоммерческим консорциумом поставщиков программных изделий, раэработчиков-прогрвммистов и конечных пользователей. Консорциум был образован в мае 1969 г. Его работа направлена на поиск архитектурной структуры для распределенных. ориентированных на объект приложений на основе широкодоступных спецификаций интерфейсов, например тех. которые предоставлены OOP. Архитектуре объектного программирования (ОМА) является основой деятельности рабочей группы OMG и состоит из эталонной модели (опубликованной в 1992 г.), которая идентифицирует и характеризует компоненты, интерфейсы и протоколы, составляющие ОМА. но не предоставляет подробных деталей.

Технология построения распределенных объектных приложений CORBA. разработанная рабочей группой ОМО. является архитектурой и протоколом для динамически связанных распределенных объектов. Эта связь является только синтаксической и лексической с ограниченными возможностями языка описания интерфейсов (IDL).

Эталонная модель включает в себя пять компонентов:

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

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

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

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

е) экземпляры не являются частью деятельности OMG в области стандартизации, но в OMG признают, что эти вопросы являются очень важными для разработки успешных приложений.

Методы OMG определяют интерфейсы для распределенных объектов с помощью языка описания интерфейсов (IOL). Рабочая группа OMG выявила необходимость использования семантически богатого описательного языка. В результате этого планируется создание запросов на предложения (RFP). которые охватывают деловой объектный домен и. в частности, обращают внимание на необходимость использования семантически обогащенного языка. Рабочая группа OMG начала стандартизацию ряда деловых объектов, например, в области валютных операций, что в перспективе может вывести на поставщиков, создающих программное обеспечение с использованием некоторых основных стандартизованных объектов, и облегчить возможную интероперабельность программных изделий разных поставщиков.

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

Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Таблица ДА.1

Обозначение ссылочного международною

Степень

Обозначение и наименование соответствующего

стандарта

соответствия

национальною стандарта

ИСО 16100-1:2009

ИСО 16100-2:2003

ИСО 16100-3:2005

ИСО 16100-4:2006

ИСО 16100-5:2009

ИСО 16100-6:2011

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

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

(1)    ИСО/МЭК ТО 10000-1:1698 (IS ОЛЕ С TR 10000-1:1998)

(2)    ИСО/МЭК 10748-2:1996 (ISO/IEC 10746-2:1996)

(3)    ИСО 16629-1 (ISO 18629-1}

(4)    ИСО/МЭК 19801-1


Информационные технологии. Структура и таксономия международных стандартизованных профилей. Часть 1. Общие принципы и структура документации (information technology — Framework and taxonomy of international Standardized Profllee — Part 1: General principles and documentation framework) Информационные технологии. Распределенная обработке в открытой системе. Эталонная модель. Принципы

(information technology — Open Distributed Processing — Reference Model. Foundations)

Системы промышленной автоматизации и интеграция. Язык спецификации процесса. Часть 1. Обзор и основные принципы

(industrial automation systems and integration — Process specification language — Part 1: Overview and basic principles)

Информационные технологии. Унифицированный язык моделирования (UML).

Часть 1. Спецификация

(iSOriEC 19501-1)    (information technology — Unified Modeling Language (UML) — Part 1: Specification)

[5]    ИИЭР 1320-1:1998    Стандарт языка функционального моделирования. Синтаксис и семантика IDEFO

(IEEE 1320-1:1996)    (Standard for Functional Modeling Language — Syntax end Semantics for IDEFO)

(6)    REC-xml-20001006 Расширяемая спецификация языка XML 1.0. второе издание — W3C рекомендации от 6 октября 2000 г.

(REC-xml-20001006. Extensible Markup Language (XML) 1.0 Second Edition —W3C Recommendation 6 October 2000)

УДК 658.52.011.56:006.354    ОКС 25.040.01    Т58

Ключевые слова: автоматизированные промышленные системы, интеграция, жизненный цикл систем, управление производством

Редактор Т.А Леонова Технический редактор вИ Прусак ом Корректор в.И. Варенцоеа Коыпьютерпая еерсткэ В И. Грищенко

Сдано в набор 20.02.2014. Подписано а печать 27.03.2014. Формат 60x84V*. Гарнитура Ариап. Уел. печ. п. 2.32.

Уч.-иад. л. 2.0в Тираж 76 аса. За». 380.

И давно и отпечатано во ФГУП «СТАМДЛР ТИН ФОРМ ». 123995 Москва, Гранатный пер., 4. info^goslinfo.iu