ГОСТ Р ИСО 19440-2010. Национальный стандарт Российской Федерации. Интеграция предприятия. Конструкции для моделирования предприятий

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

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. № 895-ст

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

ИНТЕГРАЦИЯ ПРЕДПРИЯТИЯ

КОНСТРУКЦИИ ДЛЯ МОДЕЛИРОВАНИЯ ПРЕДПРИЯТИЙ

Enterprise integration. Constructs for enterprise modelling

ОКС 25.040.40

Дата введения 1 сентября 2011 года

Предисловие

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

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

3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. № 895-ст.

4. Настоящий стандарт идентичен международному стандарту ИСО 19440:2007 «Интеграция предприятия. Конструкции для моделирования предприятий» (ISO 19440:2007 «Enterprise integration — Constructs for enterprise modelling»).

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

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

Введение

0.1 Основные сведения

Настоящий стандарт определяет общие концепции, необходимые для обеспечения возможности создания моделей предприятия в промышленном бизнесе и оказания поддержки при использовании общей схемы промышленными предприятиями. Настоящий стандарт разработан на основе ИСО 19439 путем определения и детализации набора совместимых, ориентированных на пользователя конструкций языка моделирования, которые представляют общую семантику и позволяют унифицировать модели, разработанные заинтересованными сторонами на разных этапах разработки модели предприятия. Целью таких моделей является создание основы, обеспечивающей оперативное принятие решений и возможность использования этих моделей для управления хозяйственной деятельностью и контроля.

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

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

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

Пример, приведенный в Приложении E, демонстрирует использование конструкций языка моделирования.

В Приложении B приведено обоснование целесообразности моделирования предприятий на базе конструкций, изложены основные сведения, а также указаны области моделей предприятия, в рамках которых функционирует настоящий стандарт (см. ИСО 19349). Описания трех измерений этой схемы приведены в 0.2, 0.3 и 0.4.

В настоящем стандарте использованы результаты работ целевой группы IFAC/IFIP по интегрированию предприятий, консорциума CIMOSA и научно-исследовательского проекта ATHENA.

0.2 Измерение представлений модели предприятия

0.3 Измерение фазы модели предприятия

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

0.4 Измерение универсальности

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

Настоящий стандарт устанавливает требования к характеристикам основных (ключевых) конструкций, необходимых для компьютерного моделирования предприятий в соответствии с ИСО 19439.

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

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

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

---

ИСО 19439:2006 Интеграция предприятия. Основы моделирования предприятия (ISO 19439:2006, Entreprise integration — Framework for enterprise modelling).

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

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

3.1.1. агрегирование (aggregation): Процесс или результат объединения конструкций языка моделирования и других компонентов модели в единое целое.

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

Примечание 2. Атрибут «Часть (чего-либо)» и атрибут «Состоит_из» используют во взаимосвязях агрегации, описанных в разделе 5.

[ИСО 19439:2006]

3.1.2. атрибут (attribute): Единица информации, обозначающая свойство объекта.

[ИСО 15704:2000]

3.1.3. поведенческое правило (behavioural rule): Описание логически последовательных связей между составляющими деятельности, используемых в характеристике поведения бизнес-процесса.

3.1.4. бизнес-процесс (business process): Конструкция, представляющая собой частично упорядоченный набор бизнес-процессов и/или видов деятельности предприятия, которые могут быть осуществлены для реализации одной или более задач предприятия с целью достижения желаемого конечного результата.

3.1.5. способность (capability): Качество, характеризующее способность осуществлять данный вид деятельности.

[ИСО 15531-1:2004]

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

Примечание. Возможности могут быть агрегированы.

3.1.7. класс (class): Абстракция, представляющая и инкапсулирующая свойства, взаимосвязи и поведение, которые выделяют набор однородных явлений.

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

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

3.1.9. компонент (component): Общая сущность, являющаяся или способная стать частью большего целого.

[ИСО 19439:2006]

3.1.10. компонент (component): Сущность системы с дискретной структурой в рамках системы, взаимодействующей с другими компонентами системы, дополняя тем самым систему свойствами и характеристиками.

[ИСО/МЭК 15288:2002]

3.1.11. определение концепции (concept definition): Фаза модели предприятия, определяющая бизнес-концепции домена предприятия, который следует использовать для решения бизнес-задач предприятия и его функционирования, включая необходимый ввод и вывод домена предприятия.

[ИСО 19439:2006]

3.1.12. ограничение (constraint): Препятствие, предельное ограничение или условие, накладываемое на систему, которое возникает внутри или вне рассматриваемой системы.

3.1.15. шаблон конструкции (construct template): Общая структура, обеспечивающая возможность идентификации и описания конкретных конструкций языка моделирования и установления обозначения их свойств.

3.1.16. декларативное правило (declarative rule): Набор задач и ограничений в комбинации с невычислительным набором условий.

Примечание. Декларативные правила могут быть установлены в доменах бизнес-процессов.

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

Примечание. Терминология, используемая для описания аспектов Центра принятия решений, установлена в ИСО 15704:2000/дополнение 1:2005, приложение C, в котором понятие временной горизонт определено как «часть будущего, учтенного при принятии решения, например горизонт составляет шесть месяцев, когда принимают решение о временном интервале в шесть месяцев», а плановый период — как «время с момента принятия решения до момента его пересмотра».

3.1.18. определение прекращения использования (decommission definition): Фаза модели предприятия, определяющая конечное состояние вышедшей из употребления системы, всех ее компонентов для конкретного домена предприятия и процессов, использованных для проведения ликвидации, обеспечивая тем самым повторное применение или реализацию этих компонентов.

[ИСО 19439:2006]

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

3.1.20. проектировочная спецификация схемы (design specification): Фаза модели предприятия, устанавливающая бизнес-процессы, возможности и правила, которые следует соблюдать для выполнения требований.

[ИСО 19439:2006]

3.1.21. домен (domain): Конструкция, представляющая часть моделируемого предприятия, обеспечивающая идентификацию соответствующей информации.

3.1.22. идентификация домена (domain identification): Фаза модели предприятия, идентифицирующая домен предприятия, моделируемый в отношении его бизнес-задач, входов и выходов домена предприятия, включая их соответствующие происхождения и назначения.

[ИСО 19439:2006]

3.1.23. операция в домене (domain operation): Фаза модели предприятия, охватывающая практическое применение модели домена.

[ИСО 19439:2006]

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

[ИСО 19439:2006]

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

3.1.26. домен предприятия (enterprise domain): Часть предприятия, соответствующая определенному набору бизнес-задач и ограничений, при которых должна быть создана модель предприятия.

Примечание. В настоящем стандарте вместо термина «домен предприятия» используется термин «домен» в тех случаях, когда он используется в качестве уточнения таких терминов, как «фаза идентификации домена» и «модель домена». Другие случаи применения термина «домен» соответствуют его словарному значению.

3.1.27. модель предприятия (enterprise model): Абстракция, отображающая объекты предприятия, их взаимосвязи, декомпозицию и детализацию до степени, необходимой для передачи информации о том, что предприятие намерено осуществить и как оно функционирует.

[ИСО 19439:2006]

3.1.28. фаза модели предприятия (enterprise model phase): Фаза жизненного цикла в модели предприятия.

[ИСО 19439:2006]

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

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

[ИСО 19439:2006]

3.1.31. представление объекта предприятия (enterprise object view): Конструкция, отображающая совокупность атрибутов объекта предприятия для некоторой конкретной цели.

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

3.1.32. сущность (entity): Что-либо конкретное или абстрактное в рассматриваемом домене.

[ИСО 19439:2006]

3.1.33. событие (event): Конструкция, отображающая ожидаемый или неожиданный факт, указывающий на изменение состояния предприятия или его окружения.

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

3.1.34. функциональное представление (function view): Представление модели предприятия, которое обеспечивает возможность отображения и модификации процессов предприятия, их функциональных возможностей, поведения, входов и выходов.

3.1.36. функциональная категория (functional category): Группировка сущностей, обеспечивающих выражение общей цели или возможностей.

3.1.37. функциональная операция (functional operation): Базовая единица работы и нижний уровень неоднородности в представлении функции.

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

3.1.38. обобщение (generalization): Особое понятие, измененное для получения чего-либо более общего, использования или цели, либо действие по изменению деталей или исключения их из особого понятия для получения его обобщения.

Примечание. Понятия обобщение и специализация имеют противоположный смысл.

[ИСО 19439:2006]

3.1.39. базовый уровень (generic level): Совокупность базовых (родовых) конструкций языка моделирования, предназначенная для выражения описаний, используемых для генерирования моделей на частном и конкретном уровне.

[ИСО 19439:2006]

3.1.40. описание исполнения (implementation description): Фаза модели предприятия, обеспечивающая описание конечного набора процессов, ресурсов и правил, выполняемых для достижения требуемых эксплуатационных характеристик, необходимых для выполнения Бизнес-процессов и Видов деятельности предприятия, указанных на фазе проектирования схемы.

[ИСО 19439:2006]

3.1.41. компонент информационных технологий (information technology component): Компонент, необходимый для выполнения одной или нескольких операций по сбору, обработке, распространению, хранению или проверке данных для конструкций Деятельность предприятия.

[ИСО 19439:2006]

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

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

[ИСО 19439:2006]

3.1.44. интеграция (integration): Обеспечение взаимодействия между объектами предприятия, необходимое для достижения определенной цели в определенной ограниченной среде.

Примечание. Интеграция является результатом использования этого метода интегрирования <*>.

---

<*> В оригинале ИСО 19440 использован термин «INTEGRATE» (интегрировать) вместо «integration».

3.1.45. правило целостности (integrity rule): Утверждение на фазе определения требований, касающееся ограничений информации для обеспечения соответствия реальной действительности.

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

3.1.46. жизненный цикл (life cycle): Совокупность различимых фаз и шагов в рамках фаз, через которые проходит объект с момента его создания до момента прекращения существования.

[ИСО 19439:2006]

3.1.47. фаза жизненного цикла (life cycle phase): Этап разработки жизненного цикла объекта.

[ИСО 19439:2006]

3.1.48. компонент технологии производства (manufacturing technology component): Компонент, необходимый для выполнения одной или нескольких операций по управлению, перегруппировке, транспортированию, хранению или проверке сырьевых материалов, деталей, узлов, сборочных узлов и конечных продуктов.

[ИСО 19439:2006]

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

[ИСО 19439:2006]

3.1.50. конструкция языка моделирования (modelling language construct): Текстовая или графическая часть языка моделирования, созданная для упорядоченного представления различной информации об общих свойствах и элементах совокупности объектов предприятия.

[ИСО 19439:2006]

3.1.51. цель (objective): Заявление о предпочтении в отношении возможных и разрешимых в будущем ситуаций, которое влияет на выбор в рамках какого-либо поведения.

[ИСО 19439:2006]

3.1.52. наступление события (occurrence): Единственная фактическая реализация конструкции языка моделирования, представляющая конкретную сущность реального мира в момент обработки модели.

3.1.53. операционная роль (operational role): Конструкция, отображающая соответствующие умения людей и обязанности, необходимые для выполнения операционных задач, закрепленных за конкретной операционной ролью.

3.1.54. заказ (order): Конструкции языка моделирования, являющиеся специализацией конструкции Объект предприятия, представляющей информацию для планирования и контроля бизнес-процессов на предприятии.

Примечание. Заказ может быть отображен объектным представлением, связанным с событием.

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

3.1.56. организационная единица (organizational unit): Конструкция, отображающая объект организационной структуры предприятия, описанный с помощью атрибутов организации и ссылок на организационные сущности как нижнего, так и высшего уровня.

Примечание. Примерами Организационной единицы являются отдел и отделение.

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

[ИСО 19439:2006]

3.1.58. частичный уровень (partial level): Совокупность частичных моделей.

[ИСО 19439:2006]

3.1.59. частичная модель (partial model): Модель, используемая в качестве эталонной в конкретном типе сегмента промышленности или промышленной деятельности.

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

[ИСО 19439:2006]

3.1.60. конкретный уровень (particular level): Уровень, на котором модель описывают для конкретного специфического домена предприятия.

[ИСО 19439:2006]

3.1.61. детализация (particularization): Процесс специализации и конкретизации, с помощью которого конкретные компоненты модели могут быть получены из более общих.

[ИСО 19439:2006]

3.1.62. показатель результатов деятельности (performance indicator): Мера или критерий, с помощью которых оценивают достижение цели.

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

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

3.1.64. обрабатываемая модель (processable model): Модель, имеющая характерный синтаксис и семантику, которая может быть обработана на компьютере (анализ, моделирование или выполнение программы).

3.1.65. продукт (product): Конструкция, являющаяся специализацией конструкции Объект предприятия, которая отображает желаемый выход (результат) или побочный продукт Бизнес-процессов предприятия.

3.1.66. взаимосвязь (relationship): Связь между двумя или более объектами, имеющая важное значение для достижения конкретной цели.

3.1.67. определение требований (requirements definition): Фаза модели предприятия, устанавливающая операции, необходимые для решения задач предприятия и условия, обеспечивающие возможность проведения этих операций без ссылок на альтернативные реализации или решения в части реализации.

[ИСО 19439:2006]

3.1.68. ресурсы (resource): Объект предприятия, обеспечивающий некоторые или все возможности, необходимые для осуществления деятельности предприятия.

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

[ИСО 19439:2006]

3.1.69. ресурсы (resource): Конструкция, являющаяся специализацией конструкции Объект предприятия, представляющая возможности предприятия, обеспечивающие осуществление Деятельности предприятия.

Примечание. Конструкция Ресурсы не включает в себя людские ресурсы.

3.1.70. представление ресурсов (resource view): Представление модели предприятия, обеспечивающее возможность отображения и модификации ресурсов предприятия и персонала.

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

[ИСО 19439:2006]

3.1.71. специализация (specialization): Общее понятие, измененное для получения чего-то более определенного для конкретного использования или цели, либо акт добавления или изменения деталей общего понятия для получения его специализации.

Примечание 1. Понятия Специализация и Обобщение имеют противоположный смысл.

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

[ИСО 19439:2006]

3.1.72. система (system): Совокупность объектов реального мира, организованная с определенной целью.

[ИСО 19439:2006]

3.1.73. предметная область (universe of discourse): Совокупность сущностей, которые неизменно были или всегда будут в выбранной части реального мира или гипотетического изучаемого мира, описываемого с помощью моделей.

3.2 Сокращения

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

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

CIM — компьютеризированное производство;

GRAI — графы взаимосвязанных результатов и действий;

IFAC — Международная федерация по автоматическому управлению;

IFIP — Международная федерация по обработке информации;

ODP — открытая распределенная обработка данных;

POP — Процесс — Организация — Продукт;

PSL — язык спецификации процессов;

XML — расширяемый язык разметки.

4. Общие характеристики конструкций языка моделирования

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

Примечание 1. Конструкции, определенные в настоящем стандарте, приведены в разделе 6. Каждая конструкция представляет собой элемент языка моделирования, синтаксис и семантика которого как можно более точно определены для проверки на соответствие согласно разделу 7.

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

Настоящий стандарт распространяется на моделирование предприятия, ориентированное на бизнес-процесс, поэтому отображаемые объекты предприятия должны быть Бизнес-процессами, имеющими свои динамику (алгоритм управления/поведение процесса), функциональные возможности (работы, входные/выходные параметры, контроль, ресурсы) и организационные аспекты. Эти объекты отображают на разных фазах модели и описывают с соответствующим уровнем детализации. Кроме того, отображение агрегирования поддерживается не только для отношения Бизнес-процесс/Деятельность предприятия, но также и для объектов предприятия, которые подвергаются воздействию этих Бизнес-процессов. Для создания фундамента моделирования, ориентированного на пользователя, используют функциональные, информационные, ресурсные и организационные представления модели. Эти представления модели обеспечивают возможность идентификации иерархий соответствующего объекта и взаимосвязей между разными классами и подклассами.

Примечание 2. EXPRESS по [1], PSL по [9] и сети Петри по [8] являются языками, имеющими одно представление, в то время как Язык предприятия ODP по [4], ATHENA POP по [10] и настоящий стандарт охватывают многопроекционную систему моделирования предприятия. Сети Петри используют в качестве объекта общее моделирование дискретных систем событий, включая системы производства. PSL является нейтральным языком для определения информации о процессе производства. EXPRESS — это абстрактный язык (с синтаксисом и семантикой) для моделирования совокупности объектов и их атрибутов данных. Сети Петри, PSL и EXPRESS являются формальными языками, исполняемыми на компьютере, в то время как Язык предприятия ODP и конструкции настоящего стандарта таковыми не являются. ODP по [4], POP по [10] и настоящий стандарт не имеют одинаковых представлений (в настоящем стандарте — представлений модели) и охвата. В POP и настоящем стандарте применяется подход более акцентированного процессно-ориентированного моделирования, нацеленный на мониторинг операционного процесса и использование модели управления. В противоположность этому, ODP имеет больший охват с пятью представлениями (Предприятие, Информация, Вычисление, Инжиниринг и Технология). Представление Предприятие в ODP больше всего подходит для целей настоящего стандарта, поэтому основное внимание уделяется таким концепциям на уровне предприятия, как цель, область применения и стратегия системы.

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

• на фазе идентификации домена — содержание домена, его входы и выходы представляют таким образом, чтобы модель идентификации домена могла быть использована в качестве исходной точки при выводе определения модели исходя из непротиворечивой концепции;
• на фазе определения концепции — определения основополагающих миссий, стратегии и т.д. представляют таким образом, чтобы модель определения концепции могла быть использована в качестве исходной точки при выводе определения исходя из непротиворечивых требований;
• на фазе определения требований — описания Бизнес-процессов в домене с точки зрения бизнеса представляют таким образом, чтобы показать, что этого достаточно для использования в качестве исходной точки для вывода непротиворечивой модели спецификации схемы, поэтому модель описания требований должна допускать обработку;
• на фазе спецификации схемы — определения Бизнес-процессов и всех их компонентов как с точки зрения бизнеса, так и с точки зрения информационно-коммуникационных технологий (ИКТ) представляют таким образом, чтобы показать достаточность использования модели спецификации схемы в качестве исходной точки для непротиворечивого вывода модели описания исполнения, поэтому модель спецификации схемы должна допускать обработку. На фазе спецификации схемы конструкции представляют с помощью вышеуказанных требований фазы определения путем добавления к ним атрибутов, представляющих все ресурсы и общие ИКТ интерфейсы;
• на фазе описания исполнения — описание Бизнес-процессов, включая все их компоненты, представляют так, как они выполняются в реальной системе (с точки зрения как бизнеса, так и ИКТ) таким образом, чтобы показать, что модели описания достаточно для использования в работе предприятия для поддержки принятия решений, мониторинга и контроля Бизнес-процессов. Модель исполнения должна также допускать обработку. На этом этапе конструкции должны представлять собой аппаратурную/программную платформу или выбранную технологию при условии совместимости с конструкциями спецификации схемы;
• на фазе операций в домене — путем использования разрешенной модели для операционных целей, таких как поддержка принятия решений, мониторинг и контроль;
• на фазе описания прекращения использования — путем указания применения компонентов Бизнес-процесса в будущем таким образом, чтобы модель описания прекращения использования при необходимости могла использоваться в качестве исходной точки при повторном применении на любой фазе модели.

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

Примечание 3. Примеры применения языка моделирования на основе ODP и работы ATHENA по POP приведены в Приложении D.

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

5.1 Диапазон отображения

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

---

<2> Настоящий стандарт не распространяется на машиночитаемость, которая должна быть обеспечена с помощью инструмента моделирования.

<3> Настоящий стандарт не распространяется на отображение конструкций языка моделирования с помощью графики.

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

• отображение с помощью общей структуры конструкций, описанных в 5.2;
• отображение взаимосвязей между вышеуказанными конструкциями языка моделирования (см. Приложение C <4>);

---

<4> В Приложении C приведена поясняющая метамодель UML (унифицированного языка моделирования).

• отображение с помощью шаблонов с целью включения атрибутов в общий формат (см. раздел 6);
• отображение динамического поведения по поведенческим правилам (см. 6.3.5 и Приложение A).

5.2 Общая структура и шаблон для конструкций языка моделирования

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

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

Описание шаблона приводят в неформальном виде по заранее составленной схеме. Шаблон конструкции должен включать в себя:

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

1. метка конструкции (текстовая строка, обозначающая тип конструкции);

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

3. имя (наименование экземпляра конструкции языка моделирования);

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

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

b) Часть «Содержание» с конкретными атрибутами, являющимися специальными для каждой конструкции и описание которых следует из определения конкретной конструкции языка моделирования. Затем раздел «Содержание» преобразуют в два новых раздела следующим образом:

1. дескриптивы, содержащие описательные атрибуты и охватывающие:

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

2. взаимосвязи (см. 5.4), содержащие атрибуты взаимосвязей и включающие в себя:

• операционные взаимосвязи, которые несут ответственность и имеют полномочия в отношении операции модели (идентификаторы Организационной роли и Организационной единицы, отвечающие за операционное использование данной конструкции или имеющие полномочия на изменение его применения),
• специализацию взаимосвязей, отображающих взаимосвязи между специализацией и ее обобщением,
• взаимосвязи «Часть чего-либо», отображающие взаимосвязи между данным экземпляром конструкции и комплексом в целом, интегрированным из таких экземпляров,
• взаимосвязи «Состоит из», отображающие взаимосвязи между этим экземпляром конструкции и его составляющими <5>, и

---

<5> Считают, что «Часть чего-либо» (Part_of) и «Состоит из» (Consists_of) являются дополнительными взаимосвязями, которые в зависимости от целей разработчика могут использоваться как самостоятельно, так и совместно.

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

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

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

---

<6> Контроль версии существенным образом влияет на конструкцию и работу моделей.

Примечание 1. В моделях, приведенных в Приложении C, взаимосвязи «Часть_(чего-либо)» и «Состоит_из» показаны однозначно, а не как агрегации UML. Ассоциации UML используют с целью показать Операционные и Ассоциативные взаимосвязи, а обобщения UML применяют для того, чтобы показать взаимосвязи «Специализация_(чего-либо)».

Примечание 2. Обеспечение совместимости взаимосвязей «Часть_(чего-либо)» и «Состоит_из» при их одновременном использовании и дескриптивов Ограничения и Целостность обуславливается разработкой программного обеспечения для средств технической поддержки.

5.3 Отображение атрибутов

Каждый атрибут определяется именем и предопределенным типом данных (номерами, литералами, строками и т.д.).

Примечание 1. Типу данных может соответствовать диапазон допустимых или фактических значений, таких как единичный идентификатор (id = 4711), диапазон значений [диаметр (10 +/- 0,05) мм] или список значений (желтый, красный или зеленый цвет).

Примечание 2. В качестве средства отображения атрибутов и связанных с ними определений типов данных, выражений и заявлений в конструкциях могут быть использованы схемы XML по [13], [14], [15] или EXPRESS по [1].

5.4 Отображение взаимосвязей

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

Пример 1 — Взаимосвязями между сущностями могут быть взаимосвязи между деталью и станком, который применяется для ее изготовления, или между рабочим и заказом, выполнение которого ему поручено, например «Изготовлено с помощью» (Produced_by) (деталь, машина), «Работает_в» (Works_at) (рабочий, заказ). Такие взаимосвязи отображают с помощью заданий в виде входов и выходов Видов деятельности предприятия.

Пример 2 — Примерами взаимосвязей между конструкциями являются взаимосвязи между Доменом и его Бизнес-процессами или между Бизнес-процессом и его подпроцессами и видами деятельности.

Концепция взаимосвязи, определенной пользователем, зависит от концепции Объекта Предприятие, приведенной в 6.6, и от сущностей модели, полученных из Объекта предприятия. Определенную пользователем взаимосвязь используют для описания взаимосвязей, зависящих от домена, в том виде, в котором ее воспринимают и определяют пользователи, и, следовательно, для описания того, как данные взаимосвязи группируют структурные поведенческие конструкции с точки зрения их использования на предприятии. Определяемые пользователем взаимосвязи могут быть представлены списками «Связанные с» (Related_to) для Объектов предприятия, Продуктов, Заказов и Представлений Объекта в экземплярах Объекта предприятия или дополнительными атрибутами.

5.5 Специализации

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

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

Затем каждая конструкция может быть специализирована в конструкции того же типа; например, Объект предприятия может быть специализирован в конкретные типы Объекта предприятия, Ресурсы — в другие типы Ресурсов и т.д. Взаимосвязь «Специализация (чего-либо)» (Specialization_of) используют для сохранения таких взаимосвязей специализации.

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

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

5.6 Роли

В Оксфордском словаре английского языка по [16] приведено определение роли как «типичной или характерной функции, выполняемой кем-либо или чем-либо». Одна и та же сущность может играть разные роли в разных контекстах (которые могут совпадать во времени и по месту) и в разные моменты в пределах ее жизненного цикла. Такое разнообразие роли особенно справедливо для следующих примеров сущностей:

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

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

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

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

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

d) продуктивную роль оборудования представляет конструкция Объект предприятия, которая позволяет выбирать из Продукта атрибуты, необходимые для описания входных и выходных параметров деятельности, которая должна быть осуществлена для изменения состояния продукта.

5.7 Дополнительные концепции

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

• поведенческое правило (см. 6.3.5);
• ограничение;
• декларативное правило;
• функциональная операция (см. 6.4.5);
• правило целостности;
• задача и
• показатель результативности.

В разделе 6 данные концепции (за исключением случаев, когда они используются в шаблонах) выделены курсивом. Случаи их применения в каждом из шаблонов конструкции (обычно более чем в одном) приведены в разделе E.3 Приложения E, где они также выделены курсивом.

6. Конструкции языка моделирования

6.1 Краткий обзор конструкций

6.1.1 Конструкции языка моделирования и области их применения

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

• связанные с функцией и процессом: Домен, Бизнес-процесс, Деятельность предприятия, Событие;
• связанные с информацией: Объект предприятия, Представление объекта предприятия, Заказ, Продукт;
• связанные с ресурсами: Возможности, Операционная роль, Ресурсы, Функциональная сущность и
• связанные с организацией: Персональный профиль, Организационная роль, Организационная единица и Центр принятия решений.

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

Примечание 2. Примеры применения конструкций на основе концепций моделирования на языке UML приведены в Приложении C, отношения к метамодели моделирования концепций по ИСО/МЭК 15414 и разработанным в Европейском проекте ATHENA приведены в Приложении Д.

6.1.2 Цель и применимость

Настоящий пункт распространяется на определение, описание и создание шаблонов, предназначенных для базовых конструкций языка моделирования, формирующих язык моделирования, с помощью которого может быть создан широкий спектр моделей предприятия на базе Бизнес-процессов. Каждый шаблон включает в себя атрибуты, установленные в настоящем стандарте. Для удовлетворения конкретных потребностей пользователя с помощью соответствующих расширений для шаблона допускается также применять и другие атрибуты (см. 5.2 и 5.5). В разделе E.4 Приложения E приведен пример обработки заказа и продемонстрирован способ использования шаблонов при разработке модели предприятия.

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

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

• начать с Домена (диапазон и граница модели);
• добавить функциональные возможности с точки зрения Бизнес-процессов, Видов деятельности предприятия и Событий;
• добавить отображение информации с точки зрения Объекта предприятия и Объектного представления и специализации Продукта и Заказа;
• предусмотреть обеспечение Ресурсами, Возможностями и наличие Функциональной сущности;
• рассмотреть организационные и ролевые вопросы, связанные с Организационной единицей, Центром принятия решений, Персональным профилем, Операционной ролью и Организационной ролью.

6.1.3 Нотация, применяемая для описания содержания шаблона

Атрибуты описывают в комбинации с обозначениями и текстовыми описаниями.

Нотация, используемая для целей данного раздела, заключается в том, что обозначения заключают в угловые скобки и они либо не требуют объяснений (например, ), либо разъяснения приводят в сопроводительном тексте (например, , где элемент является...). Литералы верхнего регистра обозначают как DM, BP, EV, NIL, PHYSICAL (физический) и т.д. Литеральные символы :, /, (and) обозначают «:», «/», «(„and“)» соответственно. Если для обозначения может быть использовано более одного выбора, каждая комбинация должна быть отделена от другой символом | (читать как или), например ^a | ^b | ^c. Квадратные скобки [and] используют в качестве контейнера для группировки одного или более элементов, как в [ ] для атрибута DURATION (продолжительность) Деятельности предприятия.

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

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

Примечание. Более формальный синтаксис <7> для списков должен иметь следующий вид:

---

<7> Описание используемой нотации синтаксиса приведено в разделе A.2 Приложения A.

• список = непустой список | возможно пустой список;
• непустой список = элемент данных | элемент данных, разделитель, непустой список; (* для удобства используют сокращенный вариант (или сокращенную запись) []+ *);
• разделитель = «;»; (* вместо точки с запятой можно использовать любой эквивалентный знак разделения записей *);
• возможно пустой список = NIL (нуль) | непустой список; (* для удобства применяют сокращенную запись []· *).

Пример - Для шаблона Домена Уполномоченный проектировщик со значениями Организационной роли и, возможно, также Организационной единицы допускается использовать выражение [[ «/» ] [NIL | «:» «/» ]].

Для шаблона Возможности запись data_store; id_1006453 является правильной для нотации «[]+, где является одной из записей | экземпляров Возможностей» (NIL в этом случае не используют).

Для шаблона Деятельность предприятия запись NIL или max_load (макс_нагрузка) = 10 кг; max_temp (макс_темп) = 100 C является правильной для записи ограничения «[]·, накладываемого на экземпляр Деятельности предприятия».

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

EO: Характер Объекта ФИЗИЧЕСКИЙ \ ИНФОРМАЦИОННЫЙ

CA: Возможности и атрибуты возможности

CA: Включенные Возможности []·

CA: Относящиеся к функции []·

CA: Относящиеся к Сущности []·

DM: Задачи	[]+ стратегические и операционные бизнес-задачи экземпляра Домена
EV: Объектного представления	[ «:» «/» ]· экземпляра Объектного представления, определяющего информацию, которая ассоциируется со случаями этого экземпляра События
EV: Генерировано посредством	[ «:» «/» ]+ источника этого экземпляра События
BP: Входы Представления Объекта	[ «:» «/» ]+ экземпляров Объектного представления, реализации которых могут быть получены с реализациями экземпляра Бизнес-процесса
EA: Конечные статусы	[ ]+ значения состояния окончания, полученные при реализации этого экземпляра Деятельности предприятия, и их значимость, где - обязательный предикат 0-параметра, а  - целое число в диапазоне <min, max>, где min и max являются целыми числами, представляющими наименьшие и наивысшие приоритеты соответственно. По умолчанию приоритет является высшим
PR: Относящиеся к	[ «/» ]·, определяющие экземпляры Объекта предприятия, которые относятся к экземпляру Продукта, квалифицированному множественностью, являющейся одной из следующих: [0..*] (только на ранних этапах моделирования) или [1..1], или [1..n], или [m..n]

6.2 Домен

6.2.1 Цель

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

6.2.2 Описание

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

6.2.3 Применение

Конструкцию Домен используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять его в форме, понятной как для людей, так и для компьютера.

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

6.2.4 Шаблон конструкции Домена

Заголовок
Метка конструкции	DM
Идентификатор	<model-unique string>
Имя	[<noun> | <noun>] — имя Домена, где <noun> указывает функциональность или цель, а по выбору указывает область применения
Уполномоченный проектировщик	[[NIL | «:» <identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Краткое текстовое описание Домена
Описания Бизнес-процессов	[<name> | <name> <short textual description>]+, имя и, при необходимости, краткое описание основной функциональности, необходимой для преобразования вводов Домена в Выходы Домена Бизнес-процессами, идентифицированными для конструкции Домена являются те, которые необходимы для решения задач Домена
Задачи <8>	[<objective>]+ — стратегические и операционные бизнес-задачи экземпляра Домен
Ограничения	[<constraint>]· — ограничение, накладываемое на экземпляр Домен
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
Характеристики Домена	Краткое текстовое описание миссии, подхода и значений домена
Операция в Домене	Краткое текстовое описание стратегий, политики, операционных концепций, бизнес-планов домена
Полномочия принятия решений
Функция решений	[<verb> <noun> | <noun>]· — имя функции решения или функций, которые принадлежат Домену. Функция решения — это набор действий при принятии решения или в центрах принятия решений, имеющих ту же самую категорию обрабатываемых объектов, таких как «управлять ресурсами», «управлять продуктами» и «планировать производство»
Уровень решения	[<horizon> <period>]·, где <horizon> и <period> указывают в днях, неделях или годах; <horizon> устанавливает временной интервал, в течение которого принятое решение имеет силу, а <period> устанавливает частоту пересмотра, в конце которого принятое решение должно быть изменено
A2.2. Применение на этапе определения требований и следующих фазах
Показатели результативности	[<metric> | <measure>]· — ограничение или текстовая строка, определяющая метод. Показатели результативности определяют путем установления необходимого значения или метода, с помощью которого можно оценить выполнение задач
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Входы/Выходы Входы
Представления объекта	<origin [<9>> «:» <identifier> «/» <name>]+ — для Объектного представления, экземпляры которого используют для появления экземпляра Домена
Входы События	[<origin> «:» <identifier> «/» <name>]+ — все События <10>, экземпляры которых могут быть получены с появлением экземпляра Домена
Выходы
Представления объекта	<identifier> «/» <name> «:» <destination [<11>>]+ — для Объектного представления, экземпляры которого образуются с появлением экземпляра Домена
Выходы События	<identifier> «/» <name> «:» <destination>]+ — События, экземпляры которых могут быть генерированы появлениями экземпляра Домена
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и последующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
Бизнес-процессы	[[NIL | <domain> «:»] <identifier> «/» <name>]+ — для Бизнес-процессов, имеющих место в экземпляре этого или назначенного Домена <12>
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, ответственных за операции этого экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, ответственных за операции этого экземпляра

---

<8> Установленные цели определены в Бизнес-процессах, Видах деятельности предприятия, а также в Центрах принятия решений; при этом должна быть гарантирована согласованность (последовательность).

<9> Здесь и в следующих шаблонах обозначает Домен, Бизнес-процесс или Деятельность Предприятия, то есть источник входного параметра. В случае, когда является внешним Доменом, указывают только имя домена, а его содержание не определяют.

<10> Обеспечение совместимости Событий, указанных в списке как входные и выходные параметры, с атрибутами События «Generated_by» обуславливается разработкой модели с помощью средств технической поддержки и сопровождения.

<11> Здесь и в следующих шаблонах обозначает Домен, Бизнес-процесс или Деятельность Предприятия, означающие получение выходных данных.

<12> Обеспечение совместимости указанных Бизнес-процессов с атрибутом Бизнес-процесса «Where_used» обуславливается разработкой модели с помощью средств технической поддержки и сопровождением.

6.3 Бизнес-процесс

6.3.1 Цель

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

6.3.2 Описание

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

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

Результат Бизнес-процесса должен обеспечивать его наблюдение или количественное определение <13>. Результатом могут быть материальные объекты (например, промышленные изделия) или информационные объекты (например, заказы, документы или данные) или вновь разработанные процессы. Также он может быть определен как решение одной или более поставленных задач.

---

<13> В отличие от Деятельности предприятия шаблон для Бизнес-процесса не имеет статуса окончания. О завершении процесса сигнализирует действие FINISH поведенческого правила и возможное исключение.

6.3.3 Применение

Конструкцию Бизнес-процесс используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

a) фиксировать всю связанную с процессом информацию, основанную на модели планирования и поддержки принятия решения и мониторинга и управления операционными процессами, а также

b) представлять ее в форме, понятной как для людей, так и для компьютера.

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

6.3.4 Шаблон конструкции для Бизнес-процесса

Заголовок
Метка конструкции	BP
Идентификатор	<model-unique string>
Имя	[<noun> | <noun>] — имя экземпляра Бизнес-процесса, где <noun> указывает область применения Бизнес-процесса, а по выбору уточняет экземпляр Бизнес-процесса
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание этого конкретного экземпляра
Содержание
A1. Дескриптивы, релевантные для всех фаз модели предприятия
Описание Задачи	Текстовое описание функциональных возможностей и желаемого результата [<objective>]+ — стратегические и операционные бизнес-задачи, которые должны быть выполнены экземпляром Бизнес-процесса
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Ограничения	[<constraint>]· — ограничение, накладываемое на экземпляр Бизнес-процесса
Показатели результативности	[<metric> | <measure>]· — показатели, с помощью которых может быть оценено достижение целей; [<rule>]·, декларативные правила, применимые к экземпляру Бизнес-процесса
Декларативные правила	[<behavioural rule>]+ — выражены с использованием синтаксиса согласно 6.3.5 и Приложению A
Набор поведенческих правил
A2.3. Применение на фазе спецификации схемы и следующих фазах
Приоритет <14>	<integer> в диапазоне <min, max>, где min и max являются целыми числами, представляющими наименьший и наивысший приоритеты соответственно
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Где использовано	[<identifier> «/» <name>]· — для Домена, использующего экземпляр этого Бизнес-процесса
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на этапе определения требований и следующих фазах
Часть (чего-либо)	[<identifier> «/» <name>]· — для экземпляров Бизнес-процесса, с которыми данный конкретный экземпляр участвует в агрегации. Имя определяемого экземпляра Бизнес-процесса не может быть использовано в списке
Состоит из	[<identifier> «/» <name>]+ — для экземпляров всех Бизнес-процессов и Деятельностей предприятия, агрегатом которых является данный экземпляр Бизнес-процесса
Входы/Выходы
Входы Объектного представления	[<origin> «:» <identifier> «/» <name>]+ — для Представлений объекта, экземпляры которых имеются для появлений экземпляра Бизнес-процесса
Входы События	[<origin> «:» <identifier> «/» <name>]+ — для Событий <15>, экземпляры которых могут быть получены в результате появления экземпляров Бизнес-процесса
Выходы Объектного представления	[<identifier> «/» <name> «:» <destination>]+ — для всех Представлений объекта, экземпляры которых могут быть получены в результате появления экземпляров Бизнес-процесса [<identifier> «/»
Выходы События	[<name> «:» <destination>]+ — для всех Событий, экземпляры которых могут быть получены в результате появления Бизнес-процесса
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, ответственных за операцию этого экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на операцию этого экземпляра

---

<14> Атрибуты Приоритета используют при запуске процесса, чтобы определить, какой из Бизнес-процессов следует выполнять первым в случае активирования более одного Бизнес-процесса с помощью набора Поведенческих правил. Их используют также для управления распределением Ресурсов для Деятельности предприятия.

<15> Обеспечение совместимости Событий, указанных в перечне как Входы и Выходы, с атрибутами События «Generated_by» обуславливается разработкой модели с помощью средств технической поддержки и сопровождения.

6.3.5 Поведенческие правила

6.3.5.1 Цель

Цель поведенческих правил заключается в том, чтобы

6.3.5.2 Описание

Поведение Бизнес-процесса следует описывать с помощью атрибутов набора поведенческих правил, которые управляют последовательностью составляющих Бизнес-процессов и Деятельностей предприятия. Подробное описание и синтаксис этих правил приведены в Приложении A.

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

Логическое упорядочение может быть более или менее детерминированным и соответствовать:

• хорошо структурированным процессам, т.е. процессам, для которых ожидаемый результат известен и последовательность составляющих Бизнес-процессов и/или Деятельностей предприятия полностью определена (и при необходимости детерминирована);
• полуструктурированным процессам, т.е. процессам, для которых ожидаемый результат известен, а последовательность составляющих Бизнес-процессов и/или Деятельностей предприятия будет известна только во время выполнения (детерминирована наполовину), и
• плохо структурированным процессам, т.е. процессам, для которых ни результат, ни последовательность составляющих Бизнес-процессов и/или Деятельностей предприятия полностью не известны (не детерминированы).

6.3.5.3 Применение

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

a) фиксирования всех условий, которые контролируют упорядочение и динамическое поведение Бизнес-процессов, и

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

6.4 Деятельность предприятия

6.4.1 Цель

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

6.4.2 Описание

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

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

6.4.3 Применение

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

a) реализации установленных функциональных возможностей и

b) планировании на базе модели и поддержке на базе модели решения, мониторинга и управления операционными процессами.

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

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

6.4.4 Шаблон конструкции для Деятельности предприятия

Заголовок
Метка конструкции	EA
Идентификатор	<model-unique string>
Имя	[<verb> <noun> | <verb> <noun> | <verb>] — имя Вида деятельности предприятия, где <verb> характеризует процесс выполнения Деятельности предприятия, а и <noun> являются соответственно дополнительным квалификатором и указателем области применения Деятельности предприятия
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование или поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Описание	Текстовое описание
Поведение деятельности	Текстовое описание алгоритма <16>, устанавливающего поток управления функциональными операциями, из которых состоит данная Деятельность предприятия (см. 6.4.5)
Задачи	[<objective>]+ — операционные бизнес-задачи, выполняемые экземпляром Деятельности предприятия
Ограничения	[<constraint>]· — ограничения, накладываемые на экземпляр Деятельности предприятия
Показатели результативности	[<metric> | <measure>]· — показатели, с помощью которых может быть оценено достижение целей
A2.3. Применение на фазе спецификации схемы и следующих фазах
Состоит из	[<functional operation> | functional operation> «(„[<param>]+“)»]+ — экземпляров, в которых экземпляр Деятельности предприятия является агрегатом <17>. Каждая функциональная операция идентифицируется с помощью имени функциональной операции и ее входных и выходных параметров, которое должно быть уникальным в рамках области применения, в которой оно определяется и используется
Входы/Выходы
Конечные статусы	[<value> <priority>]+ — значения конечного статуса, создаваемые появлениями данного экземпляра Деятельности предприятия, где <value> является обязательным предикатом 0-параметра, <priority> <18> является целым числом в диапазоне <min, max>, где min и max — целые числа, представляющие наименьший и наивысший приоритеты соответственно. По умолчанию приоритет считают наивысшим
Продолжительность	[<duration> <qual>]· — пары атрибутов, определяющих продолжительность появлений экземпляра Деятельности предприятия, где <qual> является кодом, представляющим одну из следующих записей: 'средний', 'минимальный', 'максимальный', 'фактический'
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
Где использовано	[<identifier> «/» <name>]+ — для Бизнес-процесса, использующего данную Деятельность предприятия
Входы/Выходы
Функциональные входы	[<origin> «:» <identifier> «/» <name>]+ — для экземпляров Объектного представления, описывающих входную информацию, которая должна быть обработана данным экземпляром Деятельности предприятия
Управляющие входы	[<origin> «:» <identifier> «/» <name>]+ — для экземпляров Объектного представления, описывающих входную информацию, обеспечивающую поступление данных во время выполнения операции, используемых, но не изменяемых появлениями данного экземпляра Деятельности предприятия
Требуемые Операционные роли	[<identifier> «/» <name>]+ — для Операционных ролей, определяющих требуемые операционные возможности появлений данного экземпляра Деятельности предприятия. Входы Операционной роли устанавливают требуемые профессиональные навыки, которые должны быть обеспечены Персональными профилями (см. 6.15)
Требуемые Способности	[<identifier> «/» <name>]+ — для Способностей, определяющих требуемые способности появлений данной Деятельности предприятия
Функциональные выходы	[<identifier> «/» <name> «:» <destination>]+ — для экземпляров Объектного представления, описывающих выходную информацию, которая создается при появлении экземпляра Деятельности предприятия. Функциональные выходы содержат статусную информацию по выполнению задач и подзадач в том виде, в котором они связаны с деятельностью и ассоциированными ресурсами
Входные События	[<origin> «:» <identifier> «/» <name>]+ — для всех Событий <19>, экземпляры которых могут быть получены появлениями экземпляра Деятельности предприятия
Выходные События	[<identifier> «/» <name> «:» <destination>]· — для всех Событий, экземпляры которых могут генерироваться появлениями экземпляра Деятельности предприятия
B2.3. Применение на фазе спецификации схемы и следующих фазах
Входы/Выходы
Выходы
Операционной роли	[<identifier> «/» <name> «:» <destination>]· — для экземпляров Объектного представления, описывающих релевантную информацию для Операционных ролей после выполнения появлений этого экземпляра Деятельности предприятия
Управляющие входы	[<identifier> «/» <name> «:» <destination>]· — для экземпляров Объектного представления, статусная информация Видов деятельности предприятия после выполнения появлений экземпляра Деятельности предприятия
Ресурсные входы	[<origin> «:» <identifier> «/» <name>]+ — для экземпляров Ресурсов, требуемых появлениями этого экземпляра Деятельности предприятия <20>. Входы Ресурсов устанавливают обеспеченные возможности (см. 6.10 и 6.11)
Ресурсные выходы	[<identifier> «/» <name> «:» <destination>]· — для экземпляров Объектного представления, статусная информация о Ресурсах в результате появления экземпляра Деятельности предприятия
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, ответственных за операцию этого экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на операцию этого экземпляра

---

<16> Поток управления этими подзадачами, называемый поведением деятельности, может быть определен в алгоритме, который описывает входные/выходные условия для последовательного управления Функциональными сущностями, связанными с осуществлением Деятельности предприятия. Разработку спецификаций для алгоритма рассматривают как аспект внедрения, входящий в область применения настоящего стандарта.

<17> Способ, которым функциональные операции, требуемые Деятельностью предприятия, согласуются с Функциональными сущностями, которые могут их выполнять, является вопросом внедрения, не входящим в область применения настоящего стандарта.

<18> Для Бизнес-процессов приоритет используется во время их выполнения, чтобы выбрать, какой Бизнес-процесс или Деятельность предприятия инициировать первым, когда промежутки времени завершения для двух Деятельностей предприятия выполнены в пределах одного интервала исследуемого времени.

<19> Совместимость Событий, указанных в перечне как Входы и Выходы, с атрибутами События «Generated_by» («Генерировано посредством») обеспечивается разработкой модели с помощью средств технической поддержки и сопровождения.

<20> Ответственность за то, что эти Ресурсы включают в себя по крайней мере те, которые способны обеспечить требуемые возможности, лежит на разработчике, имеющем средства технической поддержки.

6.4.5 Функциональная операция

6.4.5.1 Цель

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

6.4.5.2 Описание

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

6.4.5.3 Применение

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

Примечание 1. Поток управления подзадачами, называемый поведением деятельности, может быть определен в алгоритме <21>, который описывает входные/выходные условия для последовательного управления Функциональными сущностями, связанными с осуществлением Деятельности предприятия. Настоящий стандарт не устанавливает требований к данному алгоритму.

---

<21> В отличие от Бизнес-процессов, поведение которых устанавливается поведенческими правилами согласно 6.3.3.

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

6.5 Событие

6.5.1 Цель

Целью конструкции Событие является фиксирование причины, происхождения и назначения события.

6.5.2 Описание

Событие представляет начало изменения состояния на предприятии или его окружения, используемого для инициации выполнения одного или более процессов, активирует Бизнес-процессы и/или Деятельности предприятия путем обработки набора поведенческих правил, ассоциированных с Бизнес-процессом (см. также 6.3.5).

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

6.5.3 Применение

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

Примечание. Некоторые События могут сигнализировать о том, что что-то произошло, в то время как другие несут в себе ассоциированную информацию, которая будет передана Объектным представлением, например отображающим Заказ (см. пример в E.4.2.5 Приложения E).

Пример - Событие: поступление заказа клиента (информация о заказе).

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

6.5.4 Шаблон конструкции для События

Заголовок
Метка конструкции	EV
Идентификатор	<model-unique string>
Имя	[<noun> | <noun>] — имя экземпляра События, где <noun> указывает сущность, вызывающую Событие, а является дополнительным уточняющим атрибутом
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание этого конкретного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Текстовое описание
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
A2.3. Применение на фазе спецификации схемы и следующих фазах
Отметка времени	<yy.mm.dd:hh.mm.ss:mmm> — тип данных, определяющих дату и время, которые должны быть установлены на момент появления (совершения) события. Отметка времени имеет фиксированное значение, являющееся типом данных по дате и времени, которое не может быть изменено, потому что оно известно системе
Приоритет <22>	<integer> в диапазоне <min>, <max>, где min и max являются целыми числами, представляющими наименьший и наивысший приоритеты соответственно. По умолчанию приоритет считают наивысшим
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Объектное представление	[NIL | <origin> «:» <identifier> «/» <name>]· — для экземпляра Объектного представления, определяющего информацию, ассоциируемую с появлениями экземпляра этого События
Генерировано посредством	[<origin> «:» <identifier> «/» <name>]+ — источник экземпляра данного экземпляра События
Инициирует	[<identifier> «/» <name> «:» <destination>]+ — для назначения, которое может получить этот экземпляр События <23>
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, отвечающим за операцию этого экземпляра
Полномочия на операцию	[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на операцию этого экземпляра

---

<22> В отношении Бизнес-процессов Приоритет используют во время запуска с целью выбора, какой Бизнес-процесс или Деятельность предприятия инициировать в первую очередь, когда происходят почти одновременные События.

<23> Совместимость атрибутов генерировано посредством Домена для События Происхождение/Назначение и Вход/Выход для Бизнес-процессов и Деятельности предприятия должно быть обеспечено в процессе разработки модели с помощью средств технической поддержки и сопровождения.

6.6 Объект предприятия

6.6.1 Цель

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

6.6.2 Описание

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

6.6.3 Применение

Конструкцию Объект предприятия используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Запись «Природа Объекта» используют для выражения основной характеристики Объекта предприятия, которая определяет, как легко его можно переносить, имитировать и т.д. Это понятие следует применять для того, чтобы отделить информационный поток от физического в Деятельности предприятия.

6.6.4 Шаблон конструкции для Объекта предприятия

Заголовок
Метка конструкции	EO
Идентификатор	<model-unique string>
Имя	Имя экземпляра Объекта предприятия
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного конкретного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Краткое текстовое описание
Природа объекта	ФИЗИЧЕСКИЙ | ИНФОРМАЦИОННЫЙ
Свойства	[<property_name> = <property_value>]+ — элементы, представляющие свойства и их значения для сущности, представленной экземпляром Объекта предприятия
Ограничения	[<constraint>]· — ограничения, налагаемые на отобранные поименованные атрибуты экземпляра Объекта предприятия <24>
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Правила целостности	[<integrity rule>]· — применимо к атрибутам экземпляра Объекта предприятия на этапе определения требований
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Взаимосвязи Класса — Список взаимосвязей Объекта предприятия в виде:
Специализация	[<identifier> «/» <name>]· — для Объектов предприятия, являющихся обобщениями данного конкретного экземпляра <25>. Имя определяемого экземпляра Объекта предприятия не допускается использовать в списке
Часть (чего-либо)	[<identifier> «/» <name>]· — для экземпляров Объекта предприятия, в котором данный конкретный экземпляр участвует в агрегации. Имя определяемого экземпляра Объекта предприятия не допускается использовать в списке
Состоит из	[<identifier> «/» <name>]· — для всех экземпляров Объекта предприятия, в котором этот экземпляр Объекта предприятия является агрегатом. Имя определяемого экземпляра Объекта предприятия не допускается использовать в списке <26>
Относится к	[<identifier> «/» <name > <multiplicity>]· — определяющие экземпляры Объекта предприятия, которые относятся к этому экземпляру Объекта предприятия и множественность которых определяется одной из [0..*] (только для ранних фаз моделирования), или [1..1], или [1..*], или [m..n]
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, ответственных за операцию данного экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного конкретного экземпляра

---

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

<25> Данный Объект предприятия наследует все дескриптивы и взаимосвязи обобщения(ий).

<26> В других конструкциях, в которых используют записи как «Часть (чего-либо)», так и «Состоит из», принято считать, что эти взаимосвязи являются двоякими; в зависимости от целей, которые ставит перед собой разработчик модели, может использоваться одна из них или обе. В последнем случае обеспечение совместимости выбранных атрибутов обеспечивается путем моделирования.

6.7 Представление объекта предприятия (объектное представление)

6.7.1 Цель

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

6.7.2 Описание

Объект предприятия представляет поднабор описательных атрибутов (включая ассоциативные ограничения и правила целостности <27>) Объекта предприятия. Представление объекта используют также для передачи любой информации, которая может быть связана с Событием, включая списки с обозначением Объектов предприятия, по которым Организационные единицы несут ответственность и/или имеют полномочия и на которые влияют решения, принимаемые Центрами принятия решений.

---

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

6.7.3 Применение

Конструкцию Представление объекта используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Примечание. Вместо термина «Представление объекта предприятия» обычно используют «Представление объекта» или «Объектное представление» (при работе с автоматизированными средствами моделирования).

6.7.4 Шаблон конструкции Представление объекта

Заголовок
Метка конструкции	OV
Идентификатор	<model-unique string>
Имя	Имя экземпляра Объектного представления
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание этого конкретного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Краткое текстовое описание
Свойства	[<property_name> <property_value>]+ — элементы, представляющие свойства и их значения для экземпляра Объектного представления (набор атрибутов экземпляра Объекта предприятия, к которым применяется экземпляр Объектного представления)
Ограничения	[<constraint>]· — ограничения, устанавливаемые к отобранным атрибутам экземпляра Объекта предприятия, из которого получается экземпляр Объектного представления
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Правила целостности	[integrity rule]· — применяют для отобранных атрибутов экземпляра Объекта предприятия, из которого получают экземпляр Объектного представления
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Объект предприятия	[<identifier> «/» <name>] — для Объекта предприятия, из которого получают экземпляр Объектного представления
События	[<identifier> «/» <name>]· — для экземпляра События, ассоциированного с данным экземпляром Объектного представления
B2. Взаимосвязи, существенные для разных фаз моделирования предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, ответственных за операцию этого экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, имеющих полномочия на операцию этого экземпляра

6.8 Продукт

6.8.1 Цель

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

6.8.2 Описание

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

С помощью конкретизации и специализации атрибутов определяют подклассы Продукта для выполнения специфических требований определенной отрасли промышленности или конкретного предприятия. Сложные структуры продукта представляют взаимосвязями «Часть чего-либо» (Part-of) между четко различимыми подклассами Продукта.

6.8.3 Применение

Конструкцию Продукт используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

a) фиксировать всю относящуюся к продукту информацию, существенную для стратегического планирования и поддержки решения, мониторинга и управления операционными процессами, и

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

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

6.8.4 Шаблон конструкции Продукт

Заголовок
Метка конструкции	PR
Идентификатор	<model-unique string>
Имя	Имя экземпляра Продукта
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного конкретного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Краткое текстовое описание
Характер объекта	ФИЗИЧЕСКИЙ | ИНФОРМАЦИОННЫЙ
Свойства	[<property_name> <property_value>]+ — элементы, представляющие свойства и их значения для экземпляра Продукта как для Объекта предприятия
Ограничения	[<constraint>]· — ограничения, устанавливаемые к отобранным атрибутам экземпляра Продукта
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Правила целостности	[<integrity rule>]· — применяют к атрибутам экземпляра Продукт <28>.
B1. Взаимосвязи, релевантные для всех фаз модели предприятия
Взаимосвязи Класса — Перечень взаимосвязей Продукта в виде:
Специализация	[<identifier> «/» <name>]· — для классов Продукта, являющихся обобщением конкретного экземпляра. Имя определяемого экземпляра Продукта не допускается использовать в перечне
Часть (чего-либо)	[<identifier> «/» <name>]· — для экземпляров Продукта, в которых данный экземпляр включен в агрегирование. Имя определяемого экземпляра Продукта не допускается использовать в перечне
Состоит из	[<identifier> «/» <name>]· — для всех экземпляров Продукта, в которых данный экземпляр Продукта является агрегатом
Относится к	[<identifier> «/» <name> <multiplicity>]· — определяющие экземпляры Объекта предприятия, относящиеся к данному экземпляру Продукта, квалифицированного множеством, которым является одно из [0..*] (только для ранних фаз моделирования), или [1..1], или [1..n], или [m..n]
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, ответственных за операцию этого экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, имеющих полномочия на выполнение операции этого экземпляра

---

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

6.9 Заказ

6.9.1 Цель

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

6.9.2 Описание

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

6.9.3 Применение

Конструкцию Заказ используют на всех фазах моделирования. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

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

Существуют различные способы описания того, что должно быть выполнено и как этого достичь, такие как направление Заказа Организационной единице, отвечающей за правильное выполнение Бизнес-процессов. На предприятии могут применяться разнообразные формы Заказов, содержащие различную ассоциированную информацию (например, заказ клиента, производственное задание и т.д.).

Примечание. Ассоциация Заказа с Событием отображается Представлением объекта согласно E.4.2.1 и E.4.2.5 Приложения E.

6.9.4 Шаблон конструкции Заказ

Заголовок
Метка конструкции	OR
Идентификатор	<model-unique string>
Имя	Имя экземпляра Заказа
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного конкретного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Краткое текстовое описание
Характер Объекта	ФИЗИЧЕСКИЙ | ИНФОРМАЦИОННЫЙ
Свойства	[<property_name> <property_value>]+ — элементы, представляющие свойства и их значения для экземпляра Заказа как для Объекта предприятия
Ограничения	[<constraint>]· — ограничения, устанавливаемые к атрибутам экземпляра Заказа
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Правила целостности	[integrity rule>]· — применяют к атрибутам экземпляра Заказа <29>.
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Взаимосвязи Класса — Перечень взаимосвязей Продукта в виде:
Специализация	[<identifier> «/» <name>]· — для классов Заказа, являющихся обобщением данного конкретного экземпляра. Имя определяемого экземпляра Заказа не допускается использовать в перечне
Часть (чего-либо)	[<identifier> «/» <name>]· — для экземпляров Заказа, в агрегировании которых участвует данный конкретный экземпляр. Имя определяемого экземпляра Заказа не допускается использовать в перечне
Состоит из	[<identifier> «/» <name>]· — для экземпляров Заказа, в котором данный экземпляр Заказа является агрегатом. Имя определяемого экземпляра Заказа не допускается использовать в перечне
Относится к	[<identifier> «/» <name> <multiplicity>]· — определяющие экземпляры Объекта предприятия, относящиеся к данному экземпляру Заказа (например такого, как Продукт), уточненному множеством, которым является одно из [0..*] (только на начальных этапах моделирования), или [1..1], или [1..n], или [m..n]
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, ответственных за операцию этого экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, имеющих полномочия на выполнение операции этого экземпляра

---

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

6.10 Ресурсы

6.10.1 Цель

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

6.10.2 Описание

Ресурсы отображают некоторые возможности, предусмотренные для Деятельности предприятия, в соответствии с требуемыми возможностями, если этими возможностями являются возможности любых приборов, инструментов или средств <30>, имеющихся в распоряжении предприятия для выпуска продукции или оказания услуг. Ресурсы являются специализацией Объекта предприятия, который специализирует свойства атрибутов и добавляет следующие атрибуты:

---

<30> В данном контексте понятие средства включает в себя программное обеспечение и набор данных, таких как файл STEP, не включает в себя людские ресурсы, которые вместо этого представлены Личностными профилями и их специализациями.

• предусмотренные операционные роли и
• предусмотренные возможности.

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

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

6.10.3 Применение

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

a) фиксировать всю относящуюся к ресурсам информацию, существенную для планирования и поддержки решения, мониторинга и управления операционными процессами, и

b) представлять в форме, понятной как для людей, так и для компьютера.

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

6.10.4 Шаблон конструкции Ресурсы

Заголовок
Метка конструкции	RE
Идентификатор	<model-unique string>
Имя	<name> экземпляра Ресурсов
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия и отвечающих за проектирование и поддерживание данного конкретного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
A2.3. Применение на фазе спецификации схемы и следующих фазах
Описание	Краткое текстовое описание
Характер Объекта	ФИЗИЧЕСКИЙ | ИНФОРМАЦИОННЫЙ
Свойства	[<property_name><property_value>]+ — элементы, представляющие приоритеты и их значения для экземпляра Ресурсов. Эти свойства определяют необходимые описательные характеристики, кроме связанных с задачей <31>; примером «свойства имени» могут быть расположение, а после установки — остаточная стоимость
Ограничения	[<constraint>]· — ограничения, устанавливаемые к вышеуказанным атрибутам экземпляра Ресурсов
Правила целостности	[integrity rule>]· — применяют к вышеуказанным атрибутам экземпляра Ресурсов
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Обеспеченные Операционные роли	[NIL | <identifier> «/» <name>]· — для обеспеченных Ролей, предоставляющих способности человека работать с этим экземпляром Ресурсов
Обеспеченные способности	[<identifier> «/» <name>] — для Способности, определяющей обеспеченные возможности данного экземпляра Ресурсов. Ресурсы (не относящиеся к Функциональной сущности указаны в 6.12) обеспечивают только единичную способность
Взаимосвязи Класса — перечень взаимосвязей Ресурсов в виде:
Специализация (чего-либо)	[<identifier> «/» <name>]· — для классов Ресурсов, являющихся обобщением данного конкретного экземпляра. Имя определяемого экземпляра Ресурсов не допускается использовать в перечне
Часть (чего-либо)	[<identifier> «/» <name>]· — для экземпляров Функциональной сущности, в которых данные Ресурсы участвуют в агрегировании. Имя определяемого экземпляра Ресурсов не допускается использовать в перечне
Состоит из	[<identifier> «/» <name>]· — экземпляров Ресурсов и экземпляров Функциональной сущности, в которых данный экземпляр Ресурсов является агрегатом. Имя определяемого экземпляра Ресурсов не допускается использовать в перечне
Относится к	[<identifier> «/» <name > <multiplicity>]· — определяющие экземпляры Объекта предприятия, относящиеся к данному экземпляру Ресурсов, квалифицированному множеством, которым является одно из [0..*] (только на начальных фазах моделирования), или [1..1], или [1..n], или [m..n]
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, ответственных за операцию данного экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли или Организационной единицы соответственно, имеющих полномочия на выполнение операции этого экземпляра

---

<31> Атрибуты, относящиеся к задаче, находятся в пределах ассоциированных Возможностей.

6.11 Способность

6.11.1 Цель

Способность представляет элементы как способностей, требуемых Деятельностью предприятия (см. 6.4), так и предусмотренных Ресурсами (см. 6.10).

6.11.2 Описание

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

Атрибуты Способности определяют с точки зрения зависящего от ресурсов атрибута и значения, набора значений или допустимого диапазона значений для этого атрибута.

Пример - Максимальные/минимальные размеры детали, которые можно обрабатывать, степень точности или повторяемость и т.д.

6.11.3 Применение

Конструкцию Способность используют на фазе определения требований и следующих фазах. Шаблон данной конструкции позволяет:

a) фиксировать всю относящуюся к Деятельности предприятия и Ресурсам информацию, существенную для планирования и поддержки решения, мониторинга и управления операционными процессами, и

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Способность, необходимая для Деятельности предприятия, фиксируется с помощью предусмотренной Способности ресурсов.

6.11.4 Шаблон конструкции Способность

Заголовок
Метка конструкции	CA
Идентификатор	<model-unique string>
Имя	Имя данной Способности
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование или поддержание данного конкретного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Описание	Краткое текстовое описание
Атрибуты, относящиеся к функции	[<capability attribute>]· — устанавливающие и ограничивающие атрибуты, относящиеся к Деятельности предприятия, требуемые одним экземпляром Ресурсов или более. Данные экземпляры Ресурсов перечислены в атрибуте «Где требуется» (Where_required), приведенном ниже
Ограничения	[<constraint>]· — ограничения, устанавливаемые к относящимся к задаче атрибутам одного или нескольких Ресурсов
Правила целостности	[<integrity rule>]· — применяют к относящимся к задаче атрибутам одного или более экземпляров Ресурсов
A2.3. Применение на фазе спецификации схемы и следующих фазах
Атрибуты, относящиеся к работе	[<capability attribute>]· — атрибуты, устанавливающие и ограничивающие, относящиеся к работе одного или более экземпляров Ресурсов
Атрибуты, относящиеся к операции	[<capability attribute>]· — атрибуты, устанавливающие и ограничивающие, относящиеся к Деятельности предприятия одного или более экземпляров Ресурсов
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
Включенные Способности	[<Capability instance>]· — имена экземпляров включенной Способности
Где требуется	[<identifier> «/» <name>]+ — для Видов деятельности предприятия, для которых требуется экземпляр данной Способности
Где обеспечено	[<identifier> «/» <name>]+ — для Ресурсов, обеспечивающих экземпляры данной Способности
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, ответственных за этот экземпляр
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, отвечающих за данный экземпляр

6.12 Функциональная сущность

6.12.1 Цель

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

6.12.2 Описание

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

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

6.12.3 Применение

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

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

b) представлять в форме, понятной как для людей, так и для компьютера.

6.12.4 Шаблон для конструкции Функциональная сущность

Заголовок
Метка конструкции	FE
Идентификатор	<model-unique string>
Имя	<name> экземпляра Функциональной сущности
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
A2.3. Применение на фазе спецификации схемы и следующих фазах
Описание	Краткое текстовое описание
Характер Объекта	ФИЗИЧЕСКИЙ | ИНФОРМАЦИОННЫЙ
Свойства	[<property_name><property_value>]+ — элементы, отображающие свойства и их значение для экземпляра Функциональной сущности. Данные элементы определяют необходимые описательные характеристики, такие как мощность, расположение, заработная плата водителей, статус
Набор операций	[<functional operations>]+ — набор операций, выполняемых экземпляром Функциональной сущности. Каждая функциональная операция идентифицируется именем функциональной операции и ее входными и выходными параметрами; имя должно быть уникальным в пределах области, в которой оно определяется и используется
Ограничения	[<constraint>]· — ограничения, устанавливаемые к отобранным поименованным атрибутам экземпляра Функциональной сущности
Правила целостности	[<integrity rule>]· — применяют к атрибутам экземпляра Функциональной сущности
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Обеспеченная Операционная роль	[NIL | <identifier> «/» <name>]· — для операционных ролей, предусматривающих способность человека оперировать данным экземпляром Функциональной сущности
Обеспеченные способности	[<identifier> «/» <name>]· — для экземпляров Способности, совокупность которых определяет обеспеченные способности данного экземпляра Функциональной сущности. Включает в себя способность обрабатывать информацию для отправления, получения, обработки и (по выбору) хранения информации. Функциональная сущность, в отличие от Ресурсов, может предусматривать множество способностей
Взаимосвязи Класса — Перечень взаимосвязей Функциональной сущности в виде:
Специализация	[<identifier> «/» <name>]· — для классов Функциональной сущности, которые являются обобщением данного экземпляра. В перечне не допускается использовать имя определяемого экземпляра Функциональной сущности
Часть (чего-либо)	[<identifier> «/» <name>]· — для экземпляров Ресурсов и Функциональной сущности, частью которых является данная Функциональная сущность. В перечне не допускается использовать имя определяемого экземпляра Функциональной сущности
Состоит из	[<identifier> «/» <name>]· — для экземпляров Функциональных сущностей, агрегатом которых являются экземпляры данной Функциональной сущности. В перечне не допускается использовать имя определяемого экземпляра Функциональной сущности
Относится к квалифицированному	[<identifier> «/» <name > <multiplicity>]· — определяют экземпляры Объекта предприятия, которые относятся к данному экземпляру Функциональной сущности, уточненному множеством, являющимся одним из [0..*] (только на начальных этапах моделирования), или [1..1], или [1..n], или [m..n]
Операционные взаимосвязи
Ответственность за операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы, ответственных за операцию этого экземпляра
Полномочия на операцию	[[<identifier> «/» <name>] [«:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы, имеющих полномочия на операцию этого экземпляра

6.13 Организационная единица

6.13.1 Цель

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

6.13.2 Описание

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

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

6.13.3 Применение

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

Примечание 1. Организационные области, представляемые Организационной единицей, могут иметь разные размеры (например, целое предприятие, отдел, отделение или бригада).

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

6.13.4 Шаблон конструкции Организационная единица

Заголовок
Метка конструкции	OU
Идентификатор	<model-unique string>
Имя	[<noun>] — имя Организационной единицы, в которой определяет Организационную единицу, а <noun> относится к области ее действия
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Текстовое описание цели Организационной единицы
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
A2.3. Применение на фазе спецификации схемы и следующих фазах
Уровень Организации	Текстовое описание уровня данной Организационной единицы относительно иерархии организации <32>
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные полномочия и обязанности <33>
Связанные с процессом полномочия/обязанности	[<identifier> «/» <name>]· — указывают Домены, Бизнес-процессы, Виды деятельности предприятия и События, на которые распространяются полномочия и за которые несет ответственность данная Организационная единица
Связанные с информацией полномочия/обязанности	[<identifier> «/» <name>]· — указывают Объекты Предприятия, Объектного представления, Продукты и Заказы, на которые распространяются полномочия и/или ответственность данной Организационной единицы
Связанные с ресурсами полномочия/обязанности	[<identifier> «/» <name>]· — указывают Личностные профили, Ресурсы, Способности и Функциональные категории, на которые распространяются полномочия и/или ответственность данной Организационной единицы
Закрепления
Закрепленные Организационные роли/единицы	[<identifier> «/» <name>]+ — указывают Организационные роли и/или Организационные единицы, которые закреплены за данной Организационной единицей
Закреплено за Организационными единицами	[<identifier> «/» <name>]· — указывают Организационные единицы, на которые распространяются полномочия и ответственность данной Организационной единицы

---

<32> Правильность использования уровня Организации в рамках Организационной единицы и Центра принятия решений обеспечивается инструментом внедрения.

<33> Совместимость обязанностей и соответствующих атрибутов поименованных конструкций обеспечивается инструментом внедрения.

6.14 Центр принятия решений

6.14.1 Цель

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

6.14.2 Описание

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

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

Примечание. Подробный контекст (содержание) Центра принятия решений приведен в ИСО 15704:2000 / дополнение 1:2005, приложение C.

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

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

6.14.3 Применение

Конструкцию Центр принятия решений используют на фазе определения концепции и следующих фазах. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную конструкцию в форме, понятной как для людей, так и для компьютера.

6.14.4 Шаблон конструкции Центр принятия решений

Заголовок
Метка конструкции	DC
Идентификатор	<model-unique string>
Имя	[<verb> <noun> | <verb> <noun> | <noun>] — имя Центра принятия решений, где <verb> определяет указывающий на выполнение конкретного действия характер Центра принятия решений, а и <noun> являются дополнительными уточнениями и указателями компетенции Центра принятия решений
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование или поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
Описание	Текстовое описание цели Центра принятия решений
Фрейм решений (определяющий контекст решений, который должен быть выполнен экземпляром Центра принятия решений)
Задачи	[<item>]+, где элементы устанавливают решаемые задачи
Переменные	[<item>]+, где элементы устанавливают соответствующие переменные
Ограничения	[<item>]+, где элементы устанавливают ограничения, которые должны быть выполнены
Категория решения	[<verb> <noun>] — имя функции принятия решения, к которой относится Центр принятия решений, описывающий функцию принятия решения. Функция принятия решения — это набор действий в отношении решений или Центров принятия решений, имеющих одинаковую категорию обрабатываемых объектов, таких как «управлять ресурсами», «управлять продуктами», «планировать производство»
Уровень решения	[<horizon> <period>], где <horizon> и <period> указывают в днях, неделях или годах; <horizon> устанавливает временной интервал, в течение которого принятое решение действует, а <period> — периодичность проведения проверки, по результатам которой принятое решение должно быть пересмотрено
A2.2. Применение на фазе определения требований и следующих фазах
	Применение аналогично указанному в A2.1
A2.3. Применение на фазе спецификации схемы и следующих фазах
Уровень организации	Текстовое описание уровня данного Центра принятия решений относительно иерархии организации
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционная применяемость
Применяемость процесса	[<identifier> «/» <name>]· — указывают, к каким Доменам, Бизнес-процессам, Видам деятельности предприятия относятся решения, принятые данным Центром принятия решений
Применяемость информации	[<identifier> «/» <name>]· — указывают, к каким Объектам предприятия, Представлениям объекта, Продуктам и Заказам относятся решения, принятые данным Центром принятия решений
Применяемость ресурсов	[<identifier> «/» <name>]· — указывают, к каким Личностным профилям, Ресурсам, Способностям и/или Функциональным категориям относятся решения, принятые данным Центром принятия решений
Закрепления
Закрепленные Центры принятия решений	[<identifier> «/» <name>]· — указывают Центры принятия решений, контролируемые данным Центром принятия решений
Закреплено за Центром принятия решений	[<identifier> «/» <name>]· — устанавливают Центр принятия решений, который несет ответственность и имеет полномочия по данному Центру принятия решений
Закреплено за Организационной ролью	[<identifier> «/» <name>] — для Организационной роли, ответственной за Центр принятия решений.
Закреплено за Организационной единицей	[<identifier> «/» <name>]+ — указывают Организационную единицу, за которой закреплен данный Центр принятия решений

6.15 Личностный профиль

6.15.1 Цель

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

6.15.2 Описание

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

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

6.15.3 Применение

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

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

6.15.4 Шаблон конструкции Личностный профиль

Заголовок
Метка конструкции	PPR
Идентификатор	<model-unique string>
Имя	[<noun> | <noun>] — имя Личностного профиля, где дополнительно уточняет Личностный профиль, а <noun> относится к области действия Личностного профиля
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование или поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
A2.3. Применение на фазе спецификации схемы и следующих фазах
Профиль работника, существенный для приема на работу по найму на предприятие
Относящиеся к организации навыки <34>	[<skill>]· — навыки, экземпляры которых должны быть обеспечены для организационных задач, задач принятия решений и решения проблем
Относящиеся к операции навыки	[<skill>]· — навыки, экземпляры которых должны быть обеспечены для текстового описания операционных задач в части организационных задач, задач принятия решений и решения проблем
Описания рабочего задания и роли	Текстовое описание организационных задач, предназначенных для принятия решения и направленных на решение текущих или операционных проблем
Провайдер навыков	[<identifier> «/» <name>]·, где <identifier> и <name> устанавливает лицо (лиц), обеспечивающее (их) квалификацию
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
	Не применяют
B2.3. Применение на фазе спецификации схемы и следующих фазах
Закрепления
Закреплено за Организационной единицей	[<identifier> «/» <name>]· — для Организационной единицы, которая несет ответственность и имеет полномочия по данному Личностному профилю
Закреплено за Организационной ролью	[<identifier> «/» <name>]· — для Организационных ролей, за которыми закреплен данный Личностный профиль
Закреплено за Операционной ролью	[<identifier> «/» <name>]· — для Организационных ролей, для которых данный Личностный профиль обеспечивает необходимые навыки

---

<34> Должна быть по крайней мере одна способность, которая является организаторской или относящейся к операции.

6.16 Организационная роль

6.16.1 Цель

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

6.16.2 Описание

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

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

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

6.16.3 Применение

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

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Шаблон идентифицирует все Организационные единицы, для которых требуется Организационная роль.

6.16.4 Шаблон конструкции Организационная роль

Заголовок
Метка конструкции	ORR
Идентификатор	<model-unique string>
Имя	[<noun>] — имя Организационной роли, где уточняет Организационную роль, а <noun> относится к области ее деятельности
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование или поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для всех фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Организационные навыки	[<skill>]+ — сущности, экземпляры которых требуются для выполнения обязанностей, относящихся к организационным задачам, задачам принятия решений и разрешения проблем
Обязанности	[<responsibility>]· — обязанность, возложенная на данную Организационную роль. Это текстовое описание обязанностей, относящихся к организационным задачам, задачам принятия решений и решения проблем
Полномочия	[]· — полномочия, возложенные на данную Организационную роль
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
Специализация	[<identifier> «/» <name>]· — для Организационной роли, которая является обобщением данного экземпляра. В списке не допускается использовать имя определяемого экземпляра Организационной роли
B2.3. Применение на этапе спецификации схемы и следующих этапах
Закрепления
Ответственная Организационная единица	[<identifier> «/» <name>] — для Организационной единицы, несущей ответственность и имеющей полномочия на выполнение Организационной роли
Закрепленный Центр принятия решений	[<identifier> «/» <name>]· — для Центра принятия решений, закрепленного за данной Организационной ролью

6.17 Операционная роль

6.17.1 Цель

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

6.17.2 Описание

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

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

6.17.3 Применение

Конструкцию Операционная роль используют на этапе определения требований и следующих фазах. Шаблон данной конструкции позволяет:

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

b) представлять вышеуказанную информацию в форме, понятной как для людей, так и для компьютера.

Шаблон устанавливает все Действия предприятия, для которых требуется эта Операционная роль.

6.17.4 Шаблон конструкции Операционная роль

Заголовок
Метка конструкции	OPR
Идентификатор	<model-unique string>
Имя	[<noun> | <noun>] — имя Операционной роли, где квалифицирует Операционную роль, а <noun> относится к области действия Операционной роли
Уполномоченный проектировщик	[[<identifier> «/» <name>] [NIL | «:» <identifier> «/» <name>]] — для Организационной роли и Организационной единицы соответственно, имеющих полномочия на проектирование и поддерживание данного экземпляра
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
A2.2. Применение на фазе определения требований и следующих фазах
Должностная инструкция роли	Текстовое описание операционных задач
Операционные навыки	[<skill>]+ — навыки, экземпляры которых необходимы для выполнения операционных задач
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.1. Применение на фазе определения концепции и следующих фазах
	Не применяют
B2.2. Применение на фазе определения требований и следующих фазах
Специализация	[<identifier> «/» <name>]· — для Операционной роли, которая является обобщением данного экземпляра. В перечне не допускается использовать имя определяемого экземпляра Операционной роли
B2.3. Применение на фазе спецификации схемы и следующих фазах
Закрепления
Закреплено за Организационной единицей	[<identifier> «/» <name>] — Организационная единица, которая несет ответственность и имеет полномочия на выполнение данной Операционной роли
Закреплено за Видами деятельности предприятия	[<identifier> «/» <name>]+ — экземпляры Видов деятельности предприятия, для которых предназначена данная Операционная роль

7. Принципы соответствия

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

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

Модель соответствует требованиям настоящего стандарта, если она является:

a) действующей конструкцией языка моделирования, который соответствует требованиям настоящего стандарта, или

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

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

Приложение A (обязательное)

ПОВЕДЕНЧЕСКИЕ ПРАВИЛА. ПОДРОБНОЕ ОПИСАНИЕ И СИНТАКСИС

A.1. Текстовое описание

A.1.1. Краткий обзор

В настоящем Приложении приведены примеры поведенческих правил, указанных в 6.3.5. Формальный синтаксис, используемый для поведенческих правил, приведен в A.2. Слова и словосочетания, выделенные курсивом, являются обозначениями, объяснения которых приведены в тексте. Служебные слова выделены прописными буквами <35>.

---

<35> Служебными ключевыми словами в этом Приложении являются AND, ANY, ASYNCHRONOUS, DO, ES, EXCEPTION, FINISH, FROM, GENERATE, OR, REPEAT, RUN-TIME CHOICE, SELECT, START, SYNCHRONOUS, TIMES, UNTIL, UNORDERED, WHEN и XOR. Они могут быть заменены любыми эквивалентными терминами при условии, что они будут понятны читающему документ человеку.

Поведенческие правила определяют в общем виде следующим образом: WHEN condition DO action, где:

a) знак «;» обозначает окончание поведенческого правила;

b) condition (условие) представляет собой одно или более из следующих условий:

1. осуществление одного или более назначенных событий согласно A.1.2.1, которые включают в себя нормальные события, отображенные экземплярами События, события START для Бизнес-процессов и исключения;

2. окончание одного или более Бизнес-процессов или одного или более Видов деятельности предприятия (каждый из которых должен иметь конечный статус <36>) или определенной их комбинации, которая была предварительно инициирована как следствие действия поведенческих правил Бизнес-процесса, содержащего эти правила (см. A.1.2.2);

---

<36> Бизнес-процесс не имеет конечного статуса.

3. многокомпонентное условие, состоящее:

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

ii) из двух или более условий, разделенных служебным словом OR (или); в этом случае многокомпонентное условие определяют как наступившее, если выполняется любое из условий.

В случае, когда в одном многокомпонентном условии используются оба разделителя AND и OR, при группировании условий используют круглые скобки «(„и“)» или эквивалентные группирующие символы для устранения многозначности.

Пример - Условие START AND (EV1 OR EV2) наступает, если происходит START и либо наступает событие EV1, либо EV2, в то время как условие (START AND EV1) OR EV2 наступает, если наступают START и EV1 или наступает EV2;

c) action (действие) — представляет собой одно или более из следующих альтернатив:

1. инициировать один или более Бизнес-процессов и/или Видов деятельности предприятия (см. A.1.3.1) <37>;

---

<37> Синтаксис не препятствует описанию бесконечных циклов как в Бизнес-процессе BP-A, который включает в себя поведенческое правило WHEN START DO BP-A или WHEN START DO BP-B, в то время как BP-B (или другой Бизнес-процесс, вызванный прямо или косвенно с помощью BP-B) также содержит правило WHEN START DO BP-A. Реализации могут устанавливать ограничения, например такие, при которых ни один Бизнес-процесс не может инициировать себя или Бизнес-процесс, который инициирует этот же Бизнес-процесс прямо или косвенно. Настоящий стандарт не распространяется на данные ограничения.

2. завершить Бизнес-процесс с или без инициирования особой ситуации (см. A.1.3.2);

3. генерировать Событие (см. A.1.3.3) <38>;

---

<38> В отношении инициации Бизнес-процесса реализации могут устанавливать ограничения с целью избежать бесконечных циклов, например таких, при которых Бизнес-процесс не должен реагировать (через условие в поведенческом правиле) на Событие, которое он вызвал, но такие ограничения являются вопросами внедрения, которые находятся вне области применения настоящего стандарта.

4. повторить конкретное действие (цикл) (см. A.1.3.4);

5. multi-part action (многокомпонентное действие), описание которого приведено далее.

Многокомпонентное действие представлено в виде перечня действий, разделенных запятыми, которому, при необходимости инициации более одного Бизнес-процесса или Деятельности предприятия, предшествует служебное слово (указывающее либо на наличие модальности «и» [см. A.1.3.1, перечисление b)], либо на наличие модальности «или» [см. A.1.3.1, перечисление c)]), обозначающее ограничения их параллельного инициирования (см. A.1.3.1). Запятые могут быть заменены семантически эквивалентными служебными словами AND (для модальности «и») или XOR (для модальности «или»).

В настоящем Приложении Бизнес-процессы (BP) и Виды деятельности предприятия (EA) имеют общее обозначение BPEA с экземплярами BPEA1, BPEA2 и т.д.

Примечание 1. Поскольку Поведенческие правила встроены в Бизнес-процесс как атрибут набора поведенческих правил, они не имеют ассоциативного идентификатора.

Примечание 2. Два типа условий и четыре типа действий вместе с уточняющими «и» и «или» могут быть использованы в определенных комбинациях для представления различных схем упорядочивающих взаимосвязей между Бизнес-процессами или Видами деятельности предприятия, либо их комбинаций (синхронный/асинхронный, коэффициент разветвления по выходу/коэффициент объединения по входу и т.д.). Примеры схем и комбинаций и соответствующие условия и действия для них приведены в таблице A.1. Допускается использовать другие типы схем и комбинаций, условий или действий.

Таблица A.1

Примеры схем поведенческих правил с соответствующими условиями и действиями

Типовые схемы (рекомендуемые)	Условие	Возможные действия и сочетание «и» и «или» [см. A.1.3]
Инициация процесса «запуск» — безусловная инициация одного или более BPEA при инициации Бизнес-процесса	START (см. A.1.2.1, b)	Действие «инициировать»
Инициация События — инициация одного или более BPEA сразу после наступления намеченного события	Событие (см. A.1.2.1, a)	Действие «инициировать»
Условная (вызывает условную инициацию BPEA преемника, зависящую от конечного статуса его предшественника)	Статус действия — завершение (см. A.1.2.2, a)	Действие «инициировать»
Вынужденная (вызывает инициацию BPEA преемника, независимо от конечного статуса предшественника)	Действие по окончании (см. A.1.2.2, b)	Действие «инициировать»
Параллельное ветвление (вызывает совпадающую параллельную инициацию двух или более BPEA преемников)	Любое условие	Действие «инициировать»: AND-переход (синхронный, асинхронный)
Неупорядоченный набор (где набор BPEA должен быть выполнен полностью, но порядок выполнения заранее не известен и должен быть определен во время выполнения)	Любое условие	Действие «инициировать»: AND-переход (неупорядоченный)
Встреча (синхронизирует завершение «размноженных» BPEA)	Действие AND — завершение (см. A.1.2.2, c))	Любое действие
Выбор во время выполнения (эксклюзивный выбор из нескольких возможных преемников BPEA)	Любое условие	Действие «инициировать»: XOR-переход (отобрать, выбор времени выполнения)
Поочередное завершение по завершении любого из группы Бизнес-процессов или Видов деятельности предприятия	Действие OR — завершение (см. A.1.2.2, d))	Любое действие, кроме многократного повторения
Цикл (повторяет инициацию преемника BPEA до тех пор, пока не закончится данное условие, или для определенного числа итераций)	Действие «завершить» цикл: REPEAT (UNTIL, TIMES)	Действие «инициировать» цикл
Завершение Бизнес-процесса, указывающее конец выполнения набора поведенческих правил и прекращение Бизнес-процесса	Завершение действия: установление конечного статуса	Завершить/прекратить Бизнес-процесс: FINISH

A.1.2. Условия

A.1.2.1. Event (событие)

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

a) normal events: нормальные события, генерируемые во время нормальной операции Бизнес-процесса или Деятельности предприятия и отображаемые конструкцией Событие;

b) start: начало (пуск), инициация Бизнес-процесса, обозначаемая служебным словом START. Данное условие используют, например, для запуска и подготовительных действий в рамках каждого Бизнес-процесса. Если набор поведенческих правил содержит более одного поведенческого правила, то сначала оценивают правила, содержащие условие START, в порядке их определения, а затем все другие правила в порядке их определения.

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

c) exceptions: особые ситуации, сгенерированные в результате прекращения (аномального завершения) ранее инициированного Бизнес-процесса или Деятельности предприятия либо с помощью специального внешнего механизма, например контрольного таймера, имеющего обозначение в соответствии с именем особой ситуации, которые бывают следующих видов:

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

Примечание. Служебное слово EXCEPTION является необязательным;

2. значение по умолчанию (default), если генерируется особая ситуация любого типа, которая не была обозначена иным способом и представлена с помощью EXCEPTION ANY.

A.1.2.2. Action completion (завершение действия)

Action completion является одним из двух видов условий, используемых в поведенческих правилах. Его появление означает завершение одного или более назначенных Бизнес-процессов и/или Видов деятельности предприятия (каждый из последних имеет соответствующий конечный статус). В тех случаях, когда Бизнес-процесс или Деятельность предприятия были инициированы несколько раз с помощью действия «цикл» согласно A.1.3.4, только последнее завершение следует считать завершением действия. Завершение действия имеет четыре формы:

a) on-status condition (условие «в состоянии»): инициирование действия, зависящего от сравнения конечного статуса Деятельности предприятия с указанным значением и представляемого с помощью одного из следующих вариантов:

ES(EAx) = status value (значение состояния)

ES(EAx) < status value

ES(EAx) > status value

ES(EAx) <> status value,

где EAx — указанная Деятельность предприятия, ES(EAx) — конечный статус EAx; status value (значение состояния) — любая постоянная или выражение, которое можно оценить и проверить на такие условия, как равно, меньше чем, больше чем или не равно конечному статусу.

b) on-completion condition (условие «по завершении»): инициируемое действие после того, как завершен Бизнес-процесс или Деятельность предприятия (для последнего случая — независимо от предусмотренного конечного статуса отсутствует сравнение on-status, которое имеет истинное значение), представленное в виде:

FINISH(BPx) or ES(EAx) = ANY

c) AND-completion condition: условие «И, конъюнкция — завершение» — все Бизнес-процессы и/или Виды деятельности предприятия из списка завершены и представлены в виде:

completion condition BPEA1 AND completion condition BPEA2... AND completion condition BPEAn,

где каждая запись completion condition BPEAi является либо условием «on-status» либо условием «on-completion» согласно перечислениям a) и b).

d) OR-completion condition: условие «ИЛИ, дизъюнкция — завершение» — по крайней мере один Бизнес-процесс и/или Вид деятельности предприятия из списка завершен и представлен в виде:

completion condition BPEA1 OR completion condition BPEA2... OR completion condition BPEAn,

где каждая запись completion condition BPEAi является либо условием «on-status», либо условием «on-completion» согласно перечислениям a) и b).

A.1.3. Действия

A.1.3.1. Initiate action (действие «инициировать»)

Действие «инициировать» означает, что один или более Бизнес-процессов и/или Видов деятельности предприятия должны быть инициированы при возникновении условия в соответствии с A.1.2. Действие «инициировать» моделирует тот факт, что Бизнес-процесс или Деятельность предприятия могут быть инициированы только по завершении предшествующего действия (см. A.1.2.2), или при возникновении события «начало» (start event) (см. A.1.2.1, перечисление b) для Бизнес-процессов), или при возникновении нормального события (см. A.1.2.1, перечисление a)), или особой ситуации (см. A.1.2.1, перечисление c)).

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

Действие «инициировать» (Initiate action) имеет три формы:

a) single action (одиночное действие): одиночный указанный Бизнес-процесс (или Деятельность предприятия) инициирован и представлен своим именем как в поведенческом правиле

WHEN START DO prepare_Workstation;

b) AND-branching (AND-ветвление) — разрешение на активацию Бизнес-процесса и/или Вида деятельности одного составного последователя (преемника) одним предшественником или более. Очередность активации преемника определяется записью с использованием «и», которая может быть синхронной (все начинается в то же самое время), асинхронной (активируется параллельно, но, возможно, происходит в разные моменты времени) или неупорядоченной (очередность активации неизвестна и будет определена во время выполнения и, возможно, подвергаться временным ограничениям). Действие для AND process-branching (AND процесс-ветвление) представляют в виде:

and modality BPEA1, BPEA2, ..., BPEAn,

где and modality (модальность «и») — одно из следующих:

SYNCHRONOUS (синхронный), или

ASYNCHRONOUS (асинхронный), или

UNORDERED (неупорядоченный).

Запятые в перечне BPEA могут быть заменены служебным словом AND.

c) XOR-branching (XOR-ветвление): позволяет одному или более предшественникам осуществлять активацию Бизнес-процесса или Вида деятельности одного преемника (последователя). Выбор активации преемника определяется записью exclusive or modality (эксклюзив или модальность), что может осуществляться ситуационно (индексировано или определено по значению времени выполнения для некоторых переменных) или может быть выбрано во время выполнения (определяться по решению, принятому во время выполнения). Действие XOR-процесс-ветвление (XOR-process-branching) представляют в виде:

эксклюзив или модальность BPEM, BPEA2, ..., BPEAn,

где эксклюзив или модальность:

SELECT jth item FROM (используют для выбора BPEAi с помощью значения времени выполнения для j) или

RUN-TIME CHOICE (используют для выбора решения о времени выполнения).

Запятые в перечне BPEA могут быть заменены служебным словом XOR.

A.1.3.2. Complete action (действие «завершить»)

Действие «завершить» запускается с помощью любого условия в соответствии с A.1.2 и завершает Бизнес-процесс. Данное действие имеет следующие формы:

a) нормальное завершение (normal completion): Бизнес-процесс завершается как обычно, что отображается ключевым словом FINISH (конец);

b) особое прекращение (exception termination): Бизнес-процесс генерирует особую ситуацию (обычно в результате назначенного условия или условия особой ситуации по умолчанию), после чего прекращается. Это отображается следующим образом:

GENERATE exception name (имя особой ситуации) AND FINISH.

A.1.3.3. Generate event action (действие «генерировать событие»)

Действие «генерировать событие» позволяет Бизнес-процессу генерировать экземпляр События, что представляют следующим образом:

GENERATE event name.

A.1.3.4. Loop action (действие «цикл»)

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

a) повторить условно (repeat conditionally) — проверяемое условие оценивают после каждого повторения действия. Если условие истинное, действие повторяют, затем условие проверяют снова. Условное выполнение цикла может быть представлено следующим образом:

REPEAT action UNTIL test condition,

где действие является либо действием «инициировать» (единичным действием, AND-ветвлением или XOR-ветвлением), либо действием последующего цикла, а проверяемое условие (test condition) представляет собой завершение действия согласно A.1.2.2.

Примечание. Выражение REPEAT EAx UNTIL ES (EAx) = ANY семантически эквивалентно «EAx»;

b) повторить итеративно (repeat iteratively) — данный цикл обеспечивает фиксированное число повторений данного действия и представляется посредством

REPEAT action loop count TIMES,

где действие является либо действием «инициировать» (единичным действием, AND-ветвлением или XOR-ветвлением), либо действием последующего цикла, а счетчик цикла (loop count) является выражением, которое проводит оценку до положительного целого, которое определяет число повторений, или, если такую оценку не проводят, действие не инициируется.

A.2. Формальный синтаксис в eBNF

В следующем синтаксисе используется нотация eBNF согласно ИСО/МЭК 14977. Обычный символ, представляющий каждый оператор из Extended BNF и его подразумеваемый приоритет (высший приоритет наверху), имеет следующий вид:

• (repetition-symbol) — символ повторения;

• (except-symbol) — символ исключения;

, (concatenate-symbol) — символ объединения;

| (definition-separator-symbol) — символ разделения определения;

= (defining-symbol) — определяющий символ;

; (terminator-symbol) — символ завершения.

Обычная последовательность (приоритет) представляется следующими парами:

' first-quote-symbol	first-quote-symbol '
« second-quote-symbol»	second-quote-symbol «»
(* start-comment-symbol	end-comment-symbol *)
( start-group-symbol	end-group-symbol )
[ start-option-symbol	end-option-symbol ]
{ start-repeat-symbol	end-repeat-symbol }
? special-sequence-symbol	special-sequence-symbol ?

Примечание. Знак пробела, заключенный в кавычки, означает, что требуется литеральный пробел, в противном случае пробелы и концы строк (так называемое «белое место») не имеют значения. Мета-идентификатор может быть расположен в правиле как слева, так и справа, позволяя тем самым выполнять рекурсию.

Пример - list = item | item AND list;

(* использует рекурсию для генерации непустой последовательности элемента item, item AND item, item AND item AND item, etc. *)

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

ненулевое целое число = '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9';

десятичная цифра = '0' | ненулевое целое число;

положительное целое число = ненулевое;

целое число {десятичная цифра}; (используется в XOR-модальности и цикле);

прописная буква = 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z';

строчная буква = 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z';

буква = прописная буква | строчная буква;

символ строки = буква | десятичная цифра |'_'|'-'|'/'|»;	(* обратите внимание, что символ строки может быть пробелом *);
имя = буква, {символ строки};	(Имя поведенческого правила является идентифицирующей меткой или переменной. Оно должно начинаться с буквы, содержать пробелы и т.д.);
bp = имя;	(* идентифицировать Бизнес-процесс по его имени *);
ea = имя;	(* идентифицировать Деятельность предприятия по его имени *);
bpea = bp | ea	(* см. A.1.1 *);
ev = имя;	(* идентифицировать конструкцию Событие по ее имени *);
status constant = имя;	(* литеральная константа, которую можно сравнивать с Конечным статусом *);

(* Следующие записи устанавливают служебные слова для поведенческих правил: *)

(* Служебные слова в поведенческих правилах разграничиваются пробелом или пунктуацией *)

AND = ? логический и ?;

ANY = ? эквивалент символа шаблона, состояние, которое сравнивает ANY с любым значением, которое всегда присутствует ?;

ASYNCHRONOUS = ? активируется параллельно, возможно, начинается в разные моменты времени ?;

DO = ? инициировать действие, если наступает управляющее условие ?;

ES = ? Конечный статус Деятельности предприятия ?; (* ES(ea) нужно оценить до предиката 0-параметра *)

EXCEPTION = ? сигнализировать об аномальном поведении ?;

FINISH = ? сигнализировать о завершении Бизнес-процесса ?;

FROM = ? выбрать идентифицированный элемент из списка ?;

GENERATE = ? вызвать наступление экземпляра или особой ситуации ?;

OR = ? логический или ?;

REPEAT = ? итерировать ?;

RUN-TIME CHOICE = ? выбрать элемент из списка в момент, когда требуется принять решение ?;

SELECT = ? установить, какой элемент из списка должен быть выбран ?;

START = ? состояние, которое наступает, когда инициируется Бизнес-процесс ?;

SYNCHRONOUS = ? все (состояния/события), начинающиеся в одно и то же время ?;

XOR = ? логический эксклюзив или ?;

	(* Предварительная информация: заканчивается здесь *)
(* Определить набор поведенческих правил для конструкций Бизнес-процесса: *) набор поведенческих правил = поведенческое правило {поведенческое правило} (* см. 6.3.5 *); поведенческое правило = WHEN условие DO действие «;» ; (* см. A.1.1 *); условие = термин условия | термин условия {AND термин условия} | термин условия {OR термин условия}; (* см. A.1.1 b) 3) *); термин условия = единичное условие | (условие); (см. A.1.1 b) 3) *); единичное условие = наступление события | завершение действия; (* см. A.1.1 b) 1) и A.1.1 b) 2) *); наступление события = событие | начало | особая ситуация; (* см. A.1.2.1 *);
событие = ev;	(* см. A.1.2.1 a) имеющее имя Событие необходимо включить в список Бизнес-процесса с Входами События *);
начало = START; (* см. A.1.2.1 b) *); особая ситуация = указанная ситуация | значение по умолчанию (*см. A.1.2.1 c) *); указанная ситуация = [EXCEPTION] имя особой ситуации (* см. A.1.2.1 c) 1) *); особая ситуация = имя; значение по умолчанию = EXCEPTION ANY (* см. A.1.2.1 c) 2) *); завершение действия = по завершении | и завершение | или завершение (* см. A.1.2.2 *); по завершении = по состоянию; | FINISH (bp) (* см. A.1.2.2 и A.1.2.2 b) *); по состоянию = ES (ea), compare, значение состояния (* см. A.1.2.2 a) *); сравнить = «=» | «<» | «>» | «<>»; (* см. A.1.2.2 a) *); значение состояния = постоянная состояния | имя
| ANY;	(* см. A.1.2.2 a); значение состояния является постоянной величиной или выражением, которое дает оценку по имени; такая грамматика отражает неоднозначность языка в этом отношении — постоянная состояния и имя используют разную семантику, но оба являются чередованием символов строки; ES (ea) compare (сравнить) ANY всегда является истинным, если ea завершено *)
и завершение = (по завершении {AND по завершении})	(* см. A.1.2.2 c) *);
или завершение = (по завершении {OR по завершении})	(* см. A.1.2.2 d) *);
действие = инициировать | завершить | генерировать | создать цикл (* см. A.1.3 *); инициировать = единичное действие | и ветвление | xor ветвление (* см. A.1.3.1 *); единичное действие = bpea (* см. A.1.3.1 a) *); и ветвление = и модальность, и набор действий (* см. A.1.3.1 b) *); и модальность = SYNCHRONOUS | ASYCHRONOUS | UNORDERED (* см. A.1.3.1 b) *); и набор действий = единичное действие {«,'' единичное действие} | единичное действие {AND единичное действие} (* см. A.1.3.1 b) *); xor переход = xor модальность, xor набор действий (* см. A.1.3.1 c) *); xor модальность = RUN-TIME CHOICE | SELECT nth действие FROM; (* см. A.1.3.1 c) *); xor набор действий = единичное действие {»,» единичное действие} | единичное действие {XOR единичное действие}; (* см. A.1.3.1 b) *)
	nth действие = положительное целое число; (* см. A.1.3.1 c); nth действие является выражением, которое должно оценить до положительного целого числа <= число элементов данных в наборе действий xor, в противном случае возбуждается особая ситуация*);
завершить = [возбудить особую ситуацию] обычный (* см. A.1.3.2 *); возбудить особую ситуацию = GENERATE имя особой ситуации AND (* см. A.1.3.2 b) *); обычный = FINISH (* см. A.1.3.2 a) *); генерировать = GENERATE событие (* см. A.1.3.3 *); цикл = условное повторение | итеративное повторение; (* см. A.1.3.4 *); условное повторение = REPEAT действие UNTIL завершение действия; (* см. A.1.3.4 a) *); итеративное повторение = REPEAT действие, счетчик цикла TIMES (* см. A.1.3.4 b) *);
счетчик цикла = положительное целое число;	(* см. A.1.3.4 b); счет цикла должен быть выражением, с помощью которого оценивают положительное целое число или нуль (в этом случае действие не выполняется), или, если это не так, наступает особая ситуация *);
(* Определения набора поведенческих правил заканчиваются здесь *).

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

ОБОСНОВАНИЕ

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

B.3. Подход к моделированию предприятия

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

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

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

Современный подход к моделированию предприятия заключается в рассмотрении предприятия с двух точек зрения:

a) как открытого набора согласованных Бизнес-процессов, направленных на достижение целей и решение задач предприятия, и

b) как интеграции Функциональных сущностей (компьютера, персонала и применений), в которых Объекты предприятия используются для выполнения технологических операций Бизнес-процессов.

Данный подход соответствует структуре, приведенной в ИСО 19439, в котором:

• функциональное представление отображает Бизнес-процессы, соответствующие Виды деятельности предприятия и необходимые инициирующие События;
• функциональное представление отображает Объекты предприятия в соответствии с функциональным представлением;
• ресурсное представление отображает Функциональные сущности как активные Ресурсы, Возможности, Личностные (персональные) профили и ассоциативные Роли;
• организационное представление рассматривает Бизнес-процессы, Объекты предприятия и Функциональные сущности через призму ответственности и полномочий, определенных как Организационные единицы и Организационные роли.

B.4. Как конструкции поддерживают данный поход

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

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

---

<39> В ИСО 19439 данные структуры определены как частичные (частные) модели.

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

Конструкции для моделирования предприятия приведены в пункте 3.1 и разделах 4, 5 и 6 настоящего стандарта.

B.5. Преимущества использования конструкций

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

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

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

---

d) документоведов систем;

e) ИКТ вендоров;

f) разработчиков модели (инженеров-системотехников, инженеров-консультантов, специалистов по комплексным системам);

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

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

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

КРАТКИЙ ОБЗОР КОНСТРУКЦИЙ ЯЗЫКА МОДЕЛИРОВАНИЯ И ВЗАИМОСВЯЗЕЙ

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

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

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

f) диаграмма, представляющая конструкции и взаимосвязи, используемые при моделировании бизнес-организации.

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

Рисунки C.3, C.4, C.5 и C.6 подготовлены на основе шаблонов конструкции, приведенных в разделе 6 настоящего стандарта, и иллюстрируют взаимосвязи между рассматриваемыми концепциями <41>. Следует подчеркнуть, что эти диаграммы являются иллюстративными — сами шаблоны представляют собой окончательный (и нормативный) текст. Шаблоны генерируют путем размещения концепций, расположенных в центре относительно представления, в середине диаграммы (например, Бизнес-процесс, Деятельность предприятия и Функциональная сущность для функционального представления, Объект предприятия для информационного представления и т.д.). Затем добавляют конструкции, имеющие отношения к прямой ассоциации или специализации, в качестве дополнительных концепций <42> (например, ограничения, правила целостности) и сами взаимосвязи. Затем к каждой конструкции добавляют атрибуты, если только эти атрибуты не соответствуют ассоциации (в этом случае ассоциацию помечают соответствующим образом) либо обобщению или специализации. Ассоциации, помеченные стрелкой, должны читаться в направлении стрелки. Метки в конце некоторых ассоциаций указывают на роль, которую играют соответствующие конструкции в конкретной ассоциации.

---

<41> В противоположность этому, в Приложении E приведены случаи разработки модели на примере ИСО 19439.

<42> Некоторые ассоциации унаследованы через специализацию, например в разделе C.4 Продукт как специализация Объекта предприятия наследует ассоциацию с дополнительной концепцией ограничение и может быть отображен Объектными представлениями.

Примечание. В зависимости от целей моделирования конструкции часто применяют для некоторых представлений модели и аспектных моделей, представленных в перечислениях c) - f), и примерами, приведенными в Приложении E. Для любой конкретной модели предприятия разработчик должен решить заранее, какие конструкции должны присутствовать в каком представлении модели предприятия.

Эти диаграммы содержат абстрактные классы (помеченные <>), которые введены исключительно для этой метамодели UML и не используются в других пунктах.

C.2. Шаблон для конструкций языка моделирования

Рисунок C.1. Составляющие шаблона конструкции

Полный комплект конструкций языка моделирования (без ассоциаций) подробно определен в разделе 6 и показан на рисунке C.2.

Рисунок C.2. Набор конструкций (ассоциации не указаны)

Рисунок C.3. Функциональные аспекты

C.4. Метамодель информационных аспектов со специализациями

Согласно рисунку C.2 конструкции используют для моделирования бизнес-информации со специализациями Объекта предприятия в виде конструкций Продукта, Заказа и Ресурсов. Данный рисунок также поясняет ключевую роль Объектного представления при отображении селективного Объектного представления предприятия. Объектные представления используют как Входы и Выходы Доменов, Бизнес-процессов и Видов деятельности предприятия (см. раздел C.3), а также для передачи факультативной информации, сопутствующей некоторым Событиям.

Рисунок C.4. Информационные аспекты

C.5. Метамодель ресурсных аспектов

Согласно рисунку C.5 различные ресурсы обеспечивают поддержку Видов деятельности предприятия и функциональных операций. Рисунок поясняет парадигму моделирования CIMOSA. Личностный профиль устанавливается для Операционной роли, которая в этом случае имеет ассоциацию «обеспечивает людские ресурсы» с Ресурсами (и, как следствие, также с Функциональной сущностью) на фазе определения требований и следующих этапах.

Примечание. Каждая Функциональная сущность выполняет Функциональную операцию.

Рисунок C.5. Ресурсные аспекты

Рисунок C.6. Организационные/решенческие аспекты

ВОЗМОЖНОСТЬ ПРИМЕНЕНИЯ НАСТОЯЩЕГО СТАНДАРТА В ДРУГИХ ПРОЕКТАХ

D.1. Введение

Настоящее Приложение распространяется на область применения настоящего стандарта путем отнесения модельных конструкций, установленных в настоящем стандарте, к двум видам работ — в области стандартизации и в области научных исследований в Европе. В разделе D.2 приведено сравнение с приведенным в ИСО/МЭК 15414 [4] языком для открытой распределенной обработки данных ODP для предприятия, а в разделе D.3 настоящего стандарта — с первыми опубликованными результатами осуществляемого в настоящее время европейского научно-исследовательского проекта ATHENA, относящегося к языку POP* [10].

D.2. Метамодель конструкций, связанных с ИСО/МЭК 15414

D.2.1. Введение в ODP и сравнение

В дополнение к метамодели, приведенной в Приложении C, в настоящем разделе приведено сравнение конструкций языка моделирования, описанных в разделе 6 настоящего стандарта, с работой ИСО/МЭК JTC1/SC7/WG19 по языку предприятия «Открытая распределенная обработка данных (ODP)» согласно [4]. Эта работа раскрывает пять представлений (предприятие, информация, вычисления, инжиниринг, технология) и соответствующие ИСО/МЭК 10746 языки с целью:

• усовершенствовать и расширить язык предприятия, определенный в ИСО/МЭК 10746, с целью подробного изложения представлений предприятия в системе ODP;
• пояснить соответствие спецификаций представлений предприятия в системе ODP с другими спецификациями представлений этой системы и
• гарантировать, что язык предприятия при его использовании вместе с другими языками представлений подходит для подробного описания конкретной архитектуры приложений для удовлетворения специфических потребностей бизнеса.

«Язык предприятия ODP вводит усовершенствования... [концепций в других стандартах]... дополнительные специфические концепции представлений и директивные правила структурирования для спецификаций предприятия... [создавая таким образом]... общий язык (набор терминов и правил структурирования), который следует использовать при подготовке спецификации предприятия, фиксирующей цель, область применения и политику для ODP системы <43>».

---

<43> Эти задачи и текст см. ИСО/МЭК 15414:2006, раздел 0.2.

Вышеприведенная цитата соотносит конструкции языка моделирования, представленные в настоящем стандарте, с метамоделью системных концепций, определенных в ИСО/МЭК 15414, путем сравнения терминов, используемых в этих стандартах. Соответствующие <44> термины и определения, применяемые в данных стандартах, приведены в таблице соответствия D.1. В таблицу включены также некоторые используемые в данном сравнении термины, определения которых приведены в том или другом стандарте.

---

<44> В настоящем Приложении понятие «соответствующие» означает некоторую степень эквивалентности в предполагаемом применении или практическом использовании термина в рамках подобного контекста. Это не означает, что термины являются семантически взаимозаменяемыми. В некоторых случаях один термин в большей или меньшей степени специализирован, чем другой. Кроме того, для некоторых определений не приведены уточняющие примечания и пояснения.

Рисунок D.1. Метамодель семейства ODP и концепции поведения

D.2.3. Связанная с ODP метамодель для настоящего стандарта

Рисунок D.2 практически аналогичен рисунку D.1 кроме того, что некоторые системные принципы ODP переименованы с использованием соответствующих терминов, определенных в настоящем стандарте. Соответствие использования концепций языка ODP настоящему стандарту указано в надписях на рисунке. Девять концепций языка ODP используют в метамодели конструкций языка моделирования и дополнительных концепциях. В трех из них использован тот же термин, а в шести остальных концепциях имена изменены с использованием терминов, определенных в настоящем стандарте. Шесть системных концепций в соответствующей метамодели конструкций языка моделирования по настоящему стандарту напрямую не используются, хотя позже термин Роль будет интерпретирован как применимый к людям.

Две концепции на рисунке D.3 (Цель и Поведенческое правило) определены не как конструкции моделирования, а как атрибуты нескольких конструкций и как дополнительные концепции соответственно.

Рисунок D.2. Метамодель семейства ODP и поведенческие концепции, соответствующие настоящему стандарту

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

Рисунок D.3 аналогичен рисунку D.2, но адаптирован так, чтобы в большей степени соответствовать метамодели конструкции языка моделирования (см. Приложение C), и представляет, как Роль интерпретируется для выражения связи Человека с Деятельностью предприятия и Организационной единицей, а также как Функциональная категория преобразуется в специализированную поддержку Ресурсов для Деятельности предприятия.

Таблица D.1

Список конструкций по настоящему стандарту и соответствующих концепций языка предприятия ODP

Концепты ODP по ИСО/МЭК 15414	Конструкции по настоящему стандарту	Примечание
Действие: то, что случается (ИСО/МЭК 10746-2) Любое заслуживающее внимания действие для целей моделирования ассоциируется по крайней мере с одним объектом	Событие: конструкция, представляющая запрашиваемый или незапрашиваемый факт, указывающий на изменение состояния предприятия или его окружения. Функциональная сущность: конструкция, являющаяся специализацией конструкции Ресурсы, представляющей агрегирование Ресурсов, способных выполнять самостоятельно функциональную операцию (класс функциональных операций), требуемых Видом деятельности предприятия или его частью, и осуществлять связь с соответствующим управлением	По настоящему стандарту Событие является триггером, который инициирует или генерируется Бизнес-процессом или Видом деятельности предприятия. Конструкция Функциональная сущность является специализацией Ресурсов, способных выполнить действие; поэтому она ассоциируется с действием ODP как ресурсы (действующее лицо)
Действующее лицо (по отношению к действию): Роль, в которой объект предприятия, выполняющий роль, участвует в действии. Такой объект называют действующим лицом. Примечание. Допускается указывать действующее лицо, инициирующее это действие	Личностный (персональный) Профиль: конструкция, представляющая набор личных способностей, навыков и обязанностей, которые требует Организационная единица и/или Деятельность предприятия и которыми обладает человек	В настоящем стандарте точно указана роль действующего лица ODP по отношению к характеристикам Личностного (персонального) профиля человека (атрибуты, соответствующие требованиям Организационной единицы или Деятельности предприятия)
Артефакт (по отношению к действию): Роль, в которой объект предприятия, исполняющий роль, соотносится с действием. Этот объект может быть назван артефактом. Примечание. Объект предприятия, являющийся артефактом в одном действии, может быть действующим лицом в другом действии	Продукт: конструкция, являющаяся специализацией конструкции Объект предприятия, которая отображает требуемый продукт на выходе или побочный продукт процессов предприятия	Как и в случае персоны (и Ресурсов), Продукт в настоящем стандарте соответствует объекту предприятия, исполняющему роль, но сам не является ролью
Способность: не определена	Способность: конструкция, отображающая совокупность характеристик способности, выраженных как атрибуты способности, либо Ресурсов (обеспеченная Способность), либо Деятельности предприятия (требуемая Способность)
Сообщество: Сообщество — это конфигурация объектов предприятия, представляющая совокупность сущностей (например, людей, систем обработки информации, разного рода ресурсов и их совокупностей), сформированных с целью обеспечения выполнения цели. Данные сущности подвержены соглашениям, управляющим их групповым поведением	Организационная единица: конструкция, представляющая сущность организационной структуры предприятия, описываемой атрибутами, представляющими свойства организации и ссылки на низкоуровневые организационные сущности	Концепция сообщества ODP моделирует поведение сущности, а также ее структуру в терминах объектов предприятия, которые соответствуют набору Организационных единиц, используемых в настоящем стандарте для представления организации предприятия
Центр принятия решений: не определен	Центр принятия решений: конструкция, представляющая набор действий, связанных с принятием решений, характеризующихся одинаковым временным горизонтом и периодом планирования и принадлежащих к одному типу функциональной категории	В ODP Центр принятия решений может быть смоделирован как часть поведения сообщества
Объект предприятия: Объект предприятия ODP является объектом в спецификации предприятия. Объект: Модель сущности. Объект характеризуется поведением и двойственностью состояния. Объект отличается от любого другого объекта. Объект инкапсулирован, т.е. любое изменение его состояния может происходить только в результате внутреннего действия или взаимодействия с окружением. Объект взаимодействует с окружением в точках взаимодействия	Объект предприятия: конструкция, представляющая единицу информации в домене предприятия, описывающая обобщенную, реальную или абстрактную сущность, которая может быть концептуализирована как целое	В настоящем стандарте Объект предприятия в качестве концепции используется только для представления информации
Представление Объекта предприятия: не определено	Представление Объекта предприятия (Объектное представление): конструкция, представляющая совокупность атрибутов Объекта предприятия для некоторой конкретной цели	В настоящем стандарте объектное представление является представлением соответствующих атрибутов в отличие от роли в ODP (объекта в сообществе), которое включает в себя его поведение
Область применения (спецификации): свойства, окружения для специфицирования системы	Домен: конструкция, представляющая моделируемую часть предприятия и предусматривающая идентификацию соответствующей информации	В настоящем стандарте Домен определяет как свое содержание, так и связь со своим окружением
Заказ: не определен	Заказ: конструкция, являющаяся специализацией конструкции Объект предприятия, представляющей информацию для планирования и управления Бизнес-процессами на предприятии	В ODP эта информация может быть смоделирована как один или более объектов предприятия, но эта концепция не является фундаментальной концепцией моделирования
Человек: не определен. Участник: объект предприятия, моделирующий человека или любую другую сущность, которая рассматривается как имеющая некоторые права, возможности и обязанности человека	Личностный профиль: представляет набор личных способностей, навыков и обязанностей, которые (i) требуются Организационной единицей и/или Видом деятельности предприятия и (ii) предоставляются человеком	В настоящем стандарте Человек (в ODP — Участник) представляет собой описание сущности рассматриваемой области, которая моделируется, а не является конструкцией языка моделирования. При прямом моделировании она соответствует объекту предприятия, исполняющему роль, но сама не является ролью
Процесс: совокупность шагов, выполняемых установленным способом для достижения цели Примечание 1. Процесс может иметь многочисленные точки начала и окончания. Примечание 2. Установленный метод может быть частично упорядоченной последовательностью. Примечание 3. Спецификация процесса может быть спецификацией потока работ	Бизнес-процесс: конструкция, отображающая частично упорядоченный набор Бизнес-процессов и/или Видов деятельности предприятия, которые могут выполняться для реализации одной или более поставленных целей предприятия или части предприятия для достижения определенного желаемого конечного результата	В ODP шаг является усовершенствованием Действия, которое соответствует Деятельности предприятия по настоящему стандарту, в то время как предписанный способ в ODP соответствует набору правил, являющемуся частью Бизнес-процесса по настоящему стандарту. Примечания 1 и 2 относятся также к настоящему стандарту, в то время как спецификация Процесса в настоящем стандарте включает в себя спецификацию потока работ, но, как правило, представлена более детально по сравнению со спецификацией потока работ (примечание 3)
Ресурсы: роль, в которой объект предприятия, играющий конкретную роль, является необходимой для действия и требует выделения или может отсутствовать. Этот объект можно назвать ресурсом	Ресурсы: конструкция, являющаяся специализацией конструкции Объект предприятия, представляющей предоставленные возможности, необходимые для осуществления Деятельности предприятия	В отношении Человека и Продукта в настоящем стандарте конструкция Ресурсы относится не к ODP концепции роли (в действии), а к сущности предприятия, исполняющего роль
Роль: Роль обозначает абстракцию поведения сообщества, все действия которой ассоциируются с тем же самым объектом предприятия в сообществе. Каждое действие сообщества является либо поведением единичной роли, либо взаимодействием, представляющим собой часть поведения более чем одной роли. Каждую из этих абстракций обозначают как роль	Организационная роль: конструкция, представляющая набор организаторских способностей, навыков и обязанностей, которых требует Организационная единица и которые могут быть обеспечены человеком. Операционная роль: конструкция, отображающая набор операционных способностей, навыков и обязанностей, требуемых Деятельностью предприятия, которые должны быть обеспечены человеком	В настоящем стандарте см. также Личностный профиль, с которым ассоциируются Организационная роль и Операционная роль. В ODP проводится различие между двумя типами роли: роль сообщества, которая является Ролью, и роль действия (роль в действии), представляющая собой то, в чем заключаются роль действующего лица, роль артефакта и роль ресурсов
Шаг: Абстрактное действие, используемое в процессе, которое может соответствовать неустановленным объектам, участвующим в данном действии	Деятельность предприятия: конструкция, представляющая определенную часть функциональности предприятия и идентифицирующая Входы, необходимые для ее выполнения, и создаваемые в результате Выходы	В настоящем стандарте шаг представляет собой Деятельность предприятия, которая является частью процесса

D.3. Метамодель конструкций, относящихся к языку моделирования ATHENA-POP*

D.3.1. ATHENA — Ведение и сравнение

---

Окончательный вариант методологии ATHENA POP*, обеспечивающей создание набора базовых конструкций моделирования для поддержки обмена моделями между сотрудничающими предприятиями, приведен в [10]. Этой работе в значительной мере способствуют уже существующие инициативы и стандарты, из которых основными являются процессно-ориентированные BPDM, UEML 1.0 и ИСО 19440. Хотя присутствует некоторое дублирование мотивировки и области применения между POP* и упомянутыми инициативами, цель ATHENA заключается в том, чтобы в POP* использовался комплексный подход, охватывающий все соответствующие аспекты (сотрудничающих) предприятий, даже если в нем выделяются процессно-ориентированные аспекты. Кроме того, язык POP* должен быть частью большего целого, создавая методологии и платформы для поддержки моделирования, создания, управления и функционирования сотрудничающих предприятий.

В настоящем разделе, как и в разделе D.2, конструкции языка моделирования, представленные в настоящем стандарте, связаны с метамоделью концепций, определенных для POP* в проекте ATHENA, а термины, используемые в данных работах, соотносятся друг с другом. ATHENA определяет для своего языка POP* многочисленную мета-архитектуру согласно ODP На рисунке D.4 указано, что POP* измерения моделирования, такие как Процесс или Продукт, заимствованы из ядра POP*, которое определяет общие типы объектов на основе архитектуры знаний предприятия (EKA), представляющего эту метамодель.

Рисунок D.4. Архитектура ATHENA POP*

Для сравнения рассмотрены пять релевантных частичных метамоделей (Процесс, Продукт, Организация, Решение, Системы). Соответствующие термины, установленные в вышеуказанных работах, а также их определения приведены в таблице D.3. Перечень конструкций включает в себя также многие концептуальные элементы, которые прямо или косвенно определены в обоих стандартах.

D.3.2. Метамодель ATHENA POP*

Метамодель измерения процесса приведена на рисунке D.5. Стереотипы с префиксом eka, такие как «eka Object», заимствованы из архитектуры знаний предприятия POP*.

Примечание. Рисунки D.5, D.6, D.7, D.8 и D.9 созданы на основе проекта ATHENA, а терминология и использование прописных букв соответствуют целям (данного) проекта (например, Организационная единица вместо Организационная Единица).

Рисунок D.5. Метамодель POP*: измерение процесса

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

Таблица D.2

Атрибуты процесса

Наименование свойства	Тип значения	Примечание
Тип процесса	{Действие выполнения | Действие принятия решения}	Действие выполнения: Это детерминистическое действие, которое обеспечивает аналогичное значение результата для того же значения конвергирующих сущностей (триггера и поддержки). Действие принятия решения: Этот тип действия может давать несколько значений результата для одного и того же значения конвергирующих сущностей (триггера и поддержки) в зависимости от фрейма решения и особенно от переменной решения
Тип сотрудничества	{Частный процесс | Процесс представления | Совместный бизнес-процесс}	Частные процессы (PP): PP относятся к специфической организации и являются типом процессов, которые обычно называют потоковыми процессами. Процесс представления (VP): VP объединяет один или более PP до абстрактного уровня, что позволяет компаниям скрывать наиболее важную информацию от неуполномоченных партнеров. Межорганизационные бизнес-процессы (CBP): CBP определяет взаимодействия между двумя или более бизнес-категориями. Такие взаимодействия существуют между двумя или более компаниями и определяются как адекватные последовательности сообщений и/или материальные обмены на входе/выходе
Время пуска	Дата	Время начала процесса
Время окончания	Дата	Время окончания процесса
Состояние	Ключевое слово	[Запланированный, ожидающий, продолжающийся, приостановленный, законченный, прекращенный]

На рисунках D.6, D.7, D.8 и D.9 приведены примеры других измерений, которые были учтены при разработке консолидированной частичной метамодели POP* (см. рисунок D.10).

Рисунок D.6. Метамодель POP*: измерение организации

Рисунок D.7. Метамодель POP*: измерение продукта

Рисунок D.9. Метамодель POP*: измерение системы

На рисунке D.10 представлена консолидированная метамодель, построенная на основе пяти метамоделей, соответствующих измерениям: Процесс, Продукт, Организация, Решение и Системы.

D.3.3. Связанная с POP* метамодель, соответствующая настоящему стандарту

На рисунке D.11 рисунки D.6 - D.10 представлены в таком виде, чтобы, насколько это возможно, заменить эквивалентные конструкции на конструкции, описанные в настоящем стандарте, с изменениями, где это необходимо. Использование концепций POP* в настоящем стандарте указано в наименованиях на этом рисунке. В этой метамодели использованы двенадцать концепций POP*, четыре из которых переименованы. Настоящий стандарт не распространяется на восемь концепций POP* в соответствующей метамодели для конструкций языка моделирования.

Четыре концепции на рисунке D.5 (Человек, Поведенческое правило, Ввод, Вывод) определены не как конструкции моделирования, а как базовая концепция, дополнительная концепция и атрибуты нескольких конструкций соответственно.

Восемь конструкций языка моделирования по настоящему стандарту не определены напрямую в частичной метамодели POP*, изображенной на рисунке D.11. Две конструкции (Продукт, Заказ) являются типами Объекта предприятия, Функциональная сущность представляет собой специализацию Ресурсов, а Деятельность предприятия — тип Бизнес-процесса. Конструкция Объектного представления в значительной степени эквивалентна вводам и выводам процесса POP*. Домен — это концепция, которую в селективных метамоделях POP* не используют. Остальные две конструкции (Личностный профиль, Операционная роль) рассматривают как специализацию Роли POP* и Роли ресурсов.

На рисунке D.12 приведен рисунок D.11, адаптированный в целях большего согласования с метамоделью конструкции языка моделирования по настоящему стандарту. В частности, конструкция Операционная роль отображает поддержку (со стороны человека) Деятельности предприятия, и в настоящем стандарте, то как человек более тесно ассоциирован с Личностным профилем и, следовательно, с Организационной и Операционной ролями.

Рисунок D.12. Частичная метамодель по настоящему стандарту, адаптированная к метамодели ATHENA POP*

D.3.4. Сравнение определений

В таблицах D.3 - D.6 приведены термины, применяемые в ATHENA POP* и настоящем стандарте, которые организованы по четырем рассматриваемым измерениям POP*. Термины, соответствующие более чем одному измерению, приведены один раз.

Таблица D.3

Перечень конструкций по настоящему стандарту и соответствующих им терминов на основе измерений общей концепции POP*, имеющих отношение к настоящему стандарту

ATHENA POP*	Конструкции по настоящему стандарту	Примечание
Способность: Способность является типом Объекта Предприятия и используется для обозначения качества, свидетельствующего о возможности что-то сделать, такого как компетентность, мастерство и отношение к работе	Способность: конструкция, представляющая совокупность характеристик способности (выраженных в виде атрибутов способности), либо Ресурсов (их обеспеченной Способности), либо Деятельности предприятия (ее требуемой Способности)	В настоящем стандарте Способностью обозначены нелюдские ресурсы. Навыки людей и их компетентность моделируют с помощью Личностного профиля, Организационной роли и Операционной роли. В POP* Способность используется для представления качеств любого объекта на предприятии
Объект Предприятия: Объект Предприятия может представлять любую вещь или любого человека, которые выполняют работу, делают то, чтобы что-то происходило, или просто являются частью какой-либо работы на предприятии. Эта концепция включает в себя людей, роли, нечто ощутимое (как, например, физические предметы) и любую другую сущность (например, информацию и знания). Объект предприятия участвует в работе предприятия, играя роли (экземпляра Роли, Организационной Роли или Процессной роли). Объекты предприятия могут иметь определенные возможности и расположение	Объект предприятия: конструкция, представляющая единицу информации в домене предприятия, которая описывает обобщенную, реальную или абстрактную сущность, которая может быть осмыслена как целое	В настоящем стандарте Объект предприятия используют как понятие для отображения только информации. Продукт, Заказ и Ресурсы являются специализациями Объектов предприятия, а POP* использует Объект внедрения для представления любого объекта предприятия
Расположение: Расположение используется для обозначения географического расположения, места	Расположение: не является конструкцией	В настоящем стандарте расположение может быть идентифицировано как атрибут конструкции ресурсов (оборудование, технологическая линия, установка и т.д.). В POP* расположение является конструкцией, чтобы ее можно было повторно использовать для нескольких объектов
Роль: концепция Роли означает роль, которую играет некий объект. В большинстве случаев роль указывают либо в контексте процесса (Процессная Роль), либо в контексте организационной единицы (Организационная Роль), но роль может быть определена также в других контекстах. Роли могут рассматриваться как заполнители для объектов и вводятся для облегчения представления важных и принципиальных характеристик процесса или организации, не являющихся при этом специфическими в отношении конкретных рассматриваемых объектов (лиц, отделов и т.д.)	Организационная Роль: конструкция, отображающая набор операционных способностей, навыков и обязанностей, которые требуются Организационной единицей и которые должны быть обеспечены человеком. Операционная роль: конструкция, представляющая набор операционных способностей, навыков и обязанностей, которые требуются Деятельностью предприятия и должны быть обеспечены человеком	В настоящем стандарте роли, которые играет человек, моделируются Организационной ролью и Операционной ролью; для фиксирования способностей, которые имеет человек, используется также Личностный профиль. В противоположность этому, роль, которая отводится ресурсам (не людским), моделируется конструкциями Ресурсы и Способность

Таблица D.4

Перечень конструкций по настоящему стандарту и соответствующих им терминов на основе измерений процесса POP*, имеющих отношение к настоящему стандарту

ATHENA POP*	Конструкции по настоящему стандарту	Примечание
Управление: Контроль является подтипом Процессной Роли. Управление осуществляется одним процессом	Управление: не используется	Управление: конструкция эквивалентна набору Поведенческих правил, соответствующих настоящему стандарту. Управление осуществляет один конкретный процесс
Событие: представление чего-либо, что происходит в конкретный момент времени. Событие должно быть специализацией Состояния с дополнительным требованием, в соответствии с которым действие происходит в конкретный момент времени и не имеет продолжительности	Событие: конструкция, представляющая запрашиваемый или непредусмотренный факт, указывающий на изменение состояния предприятия или его окружения	В настоящем стандарте Событие является конструкцией. Это триггер, который инициирует или генерируется Бизнес-процессом или Деятельностью предприятия
Поток: Поток является связью между двумя точками принятия решения: ролями процесса (Ввод, Вывод, Управление или Ресурсы) или шлюзами в процессе. Кроме того, поскольку точки принятия решения являются частями некоторых процессов, поток косвенным путем выражает взаимосвязь между процессами, содержащими соединенные точки принятия решения. По умолчанию поток рассматривают как поток управления. Поток управления используют двумя разными способами, чтобы указать временное упорядочение между процессами, т.е. последовательность, в которой следует выполнять процессы, указать запуск/начало принимающего процесса	Поток: не используется	В настоящем стандарте поток управления моделируется не с помощью конструкций моделирования предприятия, а с помощью набора поведенческих правил, который может быть использован для графического представления потока управления. Материальный поток может быть получен из взаимосвязей между входными и выходными параметрами Бизнес-процессов и Видов деятельности предприятия
Ввод: Ввод является подтипом Процессной роли процесса. Ввод принадлежит процессу. Как подтип роли, ввод может представлять то, что вводится в процесс. Как подтип Точки Принятия Решения, ввод представляет условие начала его «родительского» процесса	Ввод: не конструкция	В настоящем стандарте моделируется путем Объектного представления на вводе и используется в Бизнес-процессах и Видах деятельности предприятия
Вывод: вывод является подтипом Роли процесса. Выводом обладает процесс. Как подтип Роли, вывод может отображать то, что выносится из процесса (например, результат). Как подтип Точки Принятия Решения, вывод отображает условие продолжения после «родительского» процесса	Вывод: не является конструкцией	Моделируется в настоящем стандарте путем представления Объекта на выходе и используется в Бизнес-процессах и Видах деятельности предприятия
Процесс: Процесс используют для представления процессов, задач и любых видов деятельности. Процесс может иметь или быть частью структуры процесса (например, пооперационного перечня работ) через свои взаимосвязи. Кроме того, с помощью потоков и Точек принятия решения процессы могут быть скомбинированы в последовательности	Бизнес-процесс: конструкция, представляющая частично упорядоченный набор Бизнес-процессов и/или Видов деятельности предприятия, которые могут быть выполнены для реализации одной или более задач предприятия или его части с целью достижения определенного конечного результата	В настоящем стандарте Бизнес-процесс отображает только бизнес-процессы; это означает, что он имеет Виды деятельности предприятия только на нижнем уровне декомпозиции
Процессная Роль: Процессная Роль является как подтипом Роли, так и подтипом Точки Принятия Решения. Этот факт указывает на двойственный характер этой концепции. Любая Процессная Роль может иметь закрепленные за ней объекты предприятия через взаимосвязь «играет роль». Как Точка Принятия Решения, она отображает условие продолжения процесса, в который включена Процессная Роль. Процессная Роль специализируется в один из четырех подтипов: Ввод, Вывод, Управление или Ресурсы	Процессная роль: не используется.
Ресурсы: Ресурсы являются подтипом Процессной Роли. Ресурсы принадлежат процессу. В большинстве случаев ресурсы используются для индикации ролей, а не Точек Принятия Решения (хотя последнее тоже возможно). Как подтип Роли, ресурсы применяются как заменители для различных объектов, использованных или созданных в процессе. Примерами являются Секретарь проекта (представляющий собой реального человека, выполняющего эту роль), Окончательный отчет (представляющий собой реальный документ), Заказчик (отображающий реального человека или организацию, ожидающую результата процесса)	Ресурсы: конструкция, являющаяся специализацией конструкции Объект предприятия, который отображает предоставленные возможности, требуемые для выполнения Деятельности предприятия. Функциональная сущность: конструкция, являющаяся специализацией конструкции Ресурсы, которая отображает агрегирование Ресурсов, способных самостоятельно выполнять функциональную операцию (класс функциональных операций), требуемую Деятельностью предприятия или его частью, и осуществлять связь со связанным управлением	В настоящем стандарте Ресурсы ограничены любыми нелюдскими средствами, обеспечивающими Способности, необходимые для выполнения Видов деятельности предприятия. Потребности идентифицированы в требуемых Способностях. Конструкция Функциональной сущности — это Ресурсы, обеспечивающие возможность выполнения действия

Таблица D.5

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

ATHENA POP*	Конструкции по настоящему стандарту	Примечание
Организационная Роль: Роль Организации — это подтип Роли, который определяется в контексте организации. Примерами являются Генеральный директор, Секретарь приемной, Руководитель отдела, Президент и т.д. Теоретически Организационную роль может играть любой тип объекта, хотя типичными примерами являются организационные роли, которые играют люди или организационные единицы	Организационная роль: конструкция, отображающая набор организационных способностей, навыков и обязанностей, которые требуются Организационной единицей и должны обеспечиваться человеком	Разница заключается в том, что настоящий стандарт определяет способности человека, а POP* устанавливает роль человека. Основная концепция POP* охватывает Способности для всех объектов предприятия
Организационная единица: Организационная единица — это вид Объекта предприятия, используемый для отображения организации или частей организации любого типа. Как формальная организационная единица, так и неформальные, специальные группы и команды могут быть отображены организационными единицами	Организационная единица: конструкция, отображающая сущность организационной структуры предприятия, которая описывается атрибутами, отображающими свойства организации и ссылки на низкоуровневые организационные категории	Настоящий стандарт допускает также представление неформальных Организационных единиц, таких как команды и группы
Человек: Человек означает отдельного индивидуума	Человек: не является конструкцией	В настоящем стандарте Личностные Профили используются для способностей, которыми обладает отдельный человек

Таблица D.6

ATHENA POP*	Конструкции по настоящему стандарту	Примечание
Центр принятия решений: Центр принятия решений — это абстрактное понятие, определяемое как набор решений, принятых на одном уровне и принадлежащих одной функции решения. Центры принятия решений являются «местами», где решения принимаются в соответствии с задачами и в условиях ограничений. Набор задач, ограничений и переменных, которые устанавливают пределы для свободы принятия решений и вместе взятые называются Фреймом решения. Центр Принятия Решений соответствует одной или более организационным единицам (экземплярам Организационной Единицы). С другой стороны, организационная единица может охватывать более одного центра принятия решений	Центр принятия решений: конструкция, которая отображает набор действий по принятию решений, характеризующихся тем, что они имеют один и тот же временной период и период планирования, и принадлежащих к одному виду функциональной категории	Настоящий стандарт также требует связи с подразделением Организации, поэтому оба определения являются эквивалентными
Фрейм решения: Фрейм решения определяется как решенческое звено между двумя центрами принятия решений. Структурный фрейм решений описывает для Центра принятия решений фрейм, в рамках которого он может принять решение. Во избежание противоречий Центр принятия решений находится под влиянием только одного структурного фрейма решения	Фрейм решения: не является конструкцией, хотя три атрибута Центра принятия решений вместе называются Фреймом решения

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

Типичными случаями применения конструкций, идентификация которых зависит от этапов моделирования, являются следующие:

• идентификация домена:
• Домен, Бизнес-процесс (идентификация основной функциональности, необходимой для преобразования вводов Домена в Выходы Домена), Объект предприятия и Представление объекта (идентификация входов и выходов Домена), События, Организационная роль и, возможно, Организационная единица (две последние — для идентификации уполномоченного проектировщика);

---

<46> Для идентификации домена на этой фазе идентификации концепции требуется только идентификация домена.

---

<47> На этом этапе определения требований дополнительная информация не требуется.

---

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

E.3. Дополнительные концепции и их применение

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

Поведенческие правила используют для установления логического упорядочения Бизнес-процесса с точки зрения составляющих видов деятельности, инициируемых событий и характеристик активности. Данные правила указаны в 6.3.5 и Приложении A. В разделе 6 поведенческие правила указаны в шаблонах в рамках Бизнес-процесса (набора поведенческих правил). Поведенческие правила не имеют ассоциированного идентификатора.

Ограничения являются частью текста или предикатами первого порядка, указывающими на ограничение, предел или условие, устанавливаемое для большинства конструкций. Ограничения используют в следующих шаблонах: Домен, Бизнес-процесс, Деятельность предприятия, Объект предприятия, Представление объекта, Продукт, Заказ, Ресурсы, Способность, Функциональная сущность и Центр принятия решений, а также в рамках декларативных правил, определенных правилами целостности применительно к Объектам предприятия. Ограничения определяются правилами, относящимися к взаимосвязям, в случае их применения для взаимосвязей и транзакций (см. 5.5). Ограничения могут иметь ассоциативный идентификатор.

Декларативные правила используют в Бизнес-процессе и содержат набор задач и ограничений. Каждое декларативное правило имеет ассоциативное имя и/или идентификатор.

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

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

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

Показатели результативности являются частями текста, в которых установлены критерии или исходные параметры, предназначенные для оценки выполнения задач. Данные показатели используют в Домене, Бизнес-процессе и Деятельности предприятия.

E.4. Использование шаблонов при разработке модели

E.4.1. Пример

Следующий пример обработки заказа на производственном предприятии приведен в ИСО 19439:2006, приложение B, раздел B.3. В настоящем стандарте пример дополнен с целью демонстрации использования шаблонов при моделировании предприятия.

Данный пример представлен на рисунке E.1, показывающем сущности предприятия в виде диаграммы «сущность — связь», соответствующей концепции представления для четырех представлений, определенных в настоящем стандарте: представление функции, информации, ресурсов и организации (дополнительная информация об отдельных представлениях приведена на рисунках E.2 - E.5).

Рисунок E.1. Представление модели для обработки заказа

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

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

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

E.4.2. Представление функции

E.4.2.1. Разработка представления функции

На рисунке E.2 подробно показано представление функции, указанной в примере, приведенном выше. Два из трех идентифицированных доменов (Заказчик и Поставщик) имеют Входы (Заказчик/Заказ, Поставщик/Детали) и Выходы (Заказчик/Продукт и Счет-фактура, Поставщик/Заказ и Оплата) в/из собственного предприятия домена, который состоит из двух процессов (Администрация и Производство), идентифицированных в представлении функции на рисунке E.2. Обработку домена начинает событие EV-1 Поступление заказа от клиента, которое ассоциировало сам заказ в форме Объектного представления OV-1 и которое начинает BP-1/Администрация (см. Шаблон события далее).

Рисунок E.2. Представление функции для обработки заказа

Декомпозиция BP-2 Производство приводит к образованию сети четырех видов деятельности предприятия, показанных на рисунке E.2 в центре. В нижней части рисунка E.2 указаны связи в направлении объектов представления информации и ресурсов, которые идентифицируют входы и выходы деятельности предприятия EA4. Не показаны связи в направлении представления организации через обязанности или идентификацию организационных аспектов (цеха, рассматриваемого как комбинацию Отделения и Центра принятия решений). В следующих примерах шаблонов отражены четыре конструкции: Домен, Бизнес-процесс, Деятельность предприятия и Событие, которые являются релевантными для представления функции.

E.4.2.2. Пример шаблона конструкции Домен

Заголовок
Метка конструкции	DM
Идентификатор	DM-1
Имя	Обработка производственного задания (собственный домен предприятия)
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Идентифицирует все Входы/Выходы домена и внутренние функциональные возможности, необходимые для обработки заказа, начиная с получения заказа от клиента и заканчивая получением платежа от заказчика
Описание Бизнес-процесса	BP-1/Администрация: обрабатывает все необходимые заказы, счета-фактуры и платежи. BP-2/Производство: ведет всю необходимую обработку материалов и занимается транспортными средствами
Следующие пять дескриптивов описаны на уровне детализации, соответствующей фазе модели предприятия
Задачи <49>	Стратегические: добиться удовлетворенности заказчика, увеличить долю на рынке и т.д. Операционные: удовлетворить потребительский спрос и т.д.
Ограничения	Наличие ресурсов, нормативы рабочего времени и окружающей среды
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применяют на фазе определения концепции и следующих фазах
Характеристики	Миссия: специальное оборудование — изготовление на заказ.
Домена	Подход: увеличить долю на рынке путем сотрудничества. Ценности: честное, справедливое и заслуживающее доверия поведение по отношению к заказчикам, персоналу и сообществу
Операция в Домене	Стратегии: расширить номенклатуру изделий за счет сотрудничества с x, y, z. Политика: повысить собственную компетентность в ключевых вопросах за счет найма рабочей силы. Операционные концепции: переналадить производственные линии с целью повышения гибкости. Бизнес-планы: ввести новые возможности продукции
Полномочия принятия решений
Функция решений	DC-1 / Плановое производство
Уровень решения	TBD <50>
A2.2. Применяют на фазе определения требований следующих фазах
Показатели результативности	Своевременная доставка; количество и содержание претензий потребителя
B1. Взаимосвязи, значимые для всех фаз моделей предприятия
Входы/Выходы
Входы Объектного представления	DM-X/Заказчик:	OV-1/Заказ клиента;
	DM-X/Заказчик:	OV-2/Платеж от заказчика;
	DM-Y/Поставщик:	OV-3/Покупные детали;
	DM-Y/Поставщик:	OV-4/Счет-фактура
Входы События	DM-X/Заказчик:	EV-1/Поступление заказа от клиента;
	DM-X/Заказчик:	EV-2/Поступление платежа от заказчика;
	DM-Y/Поставщик:	EV-3/Поступление покупных деталей;
	DM-Y/Поставщик:	EV-4/Поступление счета-фактуры
Выходы Объектного представления	OV-5/Продукта:	DM-X/Заказчик;
	OV-6/Счет-фактура:	DM-X / Заказчик;
	OV-7/Заказ на закупку:	DM-Y/Поставщик;
	OV-8/Платеж:	DM-Y/Поставщик;
	OV-11/Продукт b:	DM-X/Заказчик
Выходы События	EV-5/Продукт к отправке:	DM-X/Заказчик;
	EV-6/Направление счета-фактуры:	DM-X/Заказчик;
	EV-7/Направление заказа:	DM-Y/Поставщик;
	EV-8/Направление платежа:	DM-Y/Поставщик
B2.2. Применяют на фазе определения требований и следующих фазах
Бизнес-процессы	BP-1 /Администрация; BP-2/Производство
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	OU-1/Работа предприятия
Полномочия на операцию	OU-1/Работа предприятия

---

<49> Задачи существуют также в Бизнес-процессах, при этом должна быть гарантирована их непротиворечивость.

<50> Здесь и далее в тексте TBD означает, что требуется дополнительная информация, которая не приведена в примере.

E.4.2.3. Пример шаблона конструкции Бизнес-процесс

Заголовок
Метка конструкции	BP
Идентификатор	BP-2
Имя	Производство
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Определяет все производственные мероприятия, необходимые для обращения с материалами, обработки и транспортирования
Задачи	Стратегические: повысить рентабельность; операционные: повысить гибкость по последовательности выполнения технологических операций на производственной линии за счет использования рабочей силы и применения новой технологии
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Ограничения	Объем заказа, наличие ресурсов, нормативы рабочего времени и окружающей среды
Показатели результативности	TBD
Декларативные правила	TBD
Набор поведенческих правил	WHEN (START AND EV-9) DO EA1;
	WHEN (ES(EA-1) <51> = OK) DO EA-2;
	WHEN (ES(EA-1) <> OK) DO EXCEPTION e-1;
	WHEN (ES(EA2) = m) DO FINISH AND EV-11;
	WHEN (ES(EA2) = n) AND (ES (EA-3) = OK) DO EA-4;
	WHEN (ES(EA2) <> n) DO EXCEPTION e-2;
	WHEN (ES(EA-3) <> OK) DO EXCEPTION e-2;
	WHEN (START AND EV-3) AND (EV-10) DO EA3;
	WHEN (ES(EA-3) = OK) AND (ES (EA2) = n) DO EA-4;
	WHEN (ES(EA-3) = OK) AND (ES (EA2) <> n) DO EXCEPTION e-3;
	WHEN (ES(EA4) = OK) DO FINISH AND EV-5
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Приоритет	TBD
B1. Взаимосвязи, значимые для всех фаз модели предприятия
Где использовано	DM-1/Обработка производственного задания (Собственный домен предприятия)
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.2. Применяют на фазе определения требований и следующих фазах
Часть (чего-либо)	NIL
Состоит из	EA-1/обработать на станке; EA-2/покрасить; EA-3/ складировать; EA-4/собрать
Входы/Выходы	Происхождение/Представление объекта	Представление/ Назначение объекта
Входы Объектного представления	DM-Y/Поставщик:	OV-3/Покупные детали;
	BP-1/Администрация:	OV-9/Задание цеху a;
	BP-1/Администрация:	OV-10/Задание цеху b
Входы События	DM-Y/Поставщик:	EV-3/Поступление покупных деталей;
	BP-1/Администрация:	EV-9/Задание цеху a;
	BP-1/Администрация:	EV-10/Задание цеху b
Выходы Объектного представления	OV-5/Продукт a:	DM-X/Заказчик;
	OV-11/Продукт b:	DM-X/Заказчик
Выходы События	EV-5/Продукция к отправке:	DM-X/Заказчик, BP-1/Администрация
	EV-11/Завершение Продукт a:	BP-1/Администрация
B2.3. Применяют на фазе спецификации схемы и на следующей фазе
Операционные взаимосвязи
Ответственность за операцию	OU-3/Цех
Полномочия на проведение операции	OU-3/Цех

---

<51> ES является сокращенным обозначением Конечного Статуса/Ending Status.

E.4.2.4. Пример шаблона конструкции Деятельность предприятия

Заголовок
Метка конструкции	EA
Идентификатор	EA-4
Имя	Собрать изделие
Уполномоченный проектировщик	OU-2 / Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Описание	Идентифицирует все Входы и Выходы, необходимые для решения задачи сборки изделия, начиная с обращения с деталью и заканчивая завершением всех процедур
Поведение Деятельности	TBD
Задачи	Стратегические: улучшить операцию сборки (относится к повышению рентабельности); операционные: перепроектировать операцию сборки, мотивировать оператора (относится к повышению операционной гибкости производственной операции путем обучения рабочих и внедрения новых технологий)
Ограничения	Наличие ресурсов, нормативы рабочего времени и условий окружающей среды
Показатели результативности	Межремонтный срок службы; незавершенное производство, себестоимость продукции
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Состоит из	FO-1/переместить деталь (деталь/изделие); FO-2/разместить деталь; FO-3/зафиксировать деталь; FO-4/испытать изделие
Входы/Выходы	Происхождение/Представление объекта /	Представление объекта/Назначение
Конечные статусы	ES(EA-4) <OK>; ES(EA-4) <EXCEPTION4>
Продолжительность	TBD
B1. Взаимосвязи, существенные для всех фаз модели
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.2. Применяют на фазе определения требований и следующих фазах
Где использовано	BP-2 / Производство
Входы/Выходы	Происхождение/Представление объекта	Представление объекта/Назначение
Входы функции	PR-1.1/Деталь:	OV-12/окрашенная Деталь;
	PR-1.1/Деталь:	OV-13/покупная Деталь
Входы контроля	BP-1/Администрация:	OV-10/Задание цеху b
Требуемая Операционная роль	OPR2/Оператор:	PPR-2/Оператор
Требуемые Способности	CA-1/Сборка технического изделия:	EA 4/собрать Изделие
Выходы функции	OV-5/Продукт b:	DM-X/Заказчик
События на вводе	NIL
События на выводе	EV-5/Продукт b готов к отправке: Администрация	DM-X / Заказчик, BP-1 /
	EV-12/Особая ситуация 4:	Обработка особой ситуации (TBD)
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Входы/Выходы	Происхождение/Представление объекта	Представление объекта/Назначение
Выходы Операционной роли	OV-13 /Информация о сборке (OPR-3):	EO-6 Отчет
Выходы контроля	OV-14/Информация о статусе (EA-4):	EO-4/Отчет и EO-5/Статус Деятельности
Входы Ресурсов	RE-1.4/Pecypcы сборки:	CA-2/Сборочная станция для технического изделия;
	PPR-2/Оператор:	OPR-2/Оператор А. Смит
Выходы Ресурсов	OV-15/Информация о Ресурсах (EA-4):	EO-2 Отчет и EO-4 Статус Ресурсов
Операционные взаимосвязи
Ответственность за операцию	OU-3 / Цех
Полномочия на операцию	OU-3 / Цех

E.4.2.5. Пример шаблона конструкции Событие

Заголовок
Метка конструкции	EV
Идентификатор	EV-1
Имя	Поступление Заказа от клиента
Уполномоченный проектировщик	OU-2 / Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Инициирует BP-1/Администрация, ведущий к генерированию Заданий цеху и Заказа на закупку
A2. Дескриптивы, существенные на разных этапах моделирования предприятия
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Приоритет Отметки времени	TBD
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Объектное представление	OV-1/Заказ клиента
Генерировано посредством	DM-X/Заказчик
Инициирует	BP-1 /Администрация
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	OU-1/Работа предприятия
Полномочия на операцию	OU-1/Работа предприятия

E.4.3. Представление информации

E.4.3.1. Разработка информационного представления

На рисунке E.3 указаны связи между информационным и функциональным представлением для сборочных работ только с учетом связи для входов (Детали и Покупные детали) и выходов (Продукт) функции.

Рисунок E.3. Представление информации для обработки заказа

Вся информация, которая используется и выдается Деятельностью предприятия как Объектного представления, является или становится частью родственных Объектов предприятия. Детали и Продукт (изделие) указаны в информационном представлении как объекты. Для функционального представления использованы только проекции этих объектов, называемые Представлениями объекта (CIMOSA [11]), которые отбирают ограниченный набор информации об объекте. В соответствии с рисунком E.1 Объект предприятия Часть является частью Объекта предприятия Продукт. Для остальной части информационного представления на рисунке E.3 указаны только составные объекты и их связи.

Концепция Объектного представления требует многократного использования информации, как указано в двух Представлениях объекта, полученных из Объекта предприятия Часть (в обоих Представлениях объекта использованы атрибуты 1 и 2, а также дополнительные атрибуты). Однако все Объектные представления имеют временный характер. Это означает, что они существуют только вместе с экземпляром Деятельности предприятия, а избыток информации не влияет на целостность общей модели информации, отображенной в информационном представлении.

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

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

b) Объектные представления отбирают из заранее определенных Объектов предприятия.

Опция b) является предпочтительным способом обеспечения согласованности модели предприятия и базы знаний предприятия.

E.4.3.2. Пример шаблона конструкции Объект предприятия

Заголовок
Метка конструкции	EO
Идентификатор	EO-1.1
Имя	Заказчик
Уполномоченный проектировщик	OU-2 / Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Содержит всю информацию о заказчике
Характер Объекта	ИНФОРМАЦИОННЫЙ
Свойства	Информация о Заказчике
Ограничения	NIL
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Правила целостности	NIL
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Взаимосвязи Класса — Перечень взаимосвязей Объекта предприятия в виде:
Специализация	NIL
Часть (чего-либо)	NIL
Состоит из
Относящийся к	EO-1.1.1/Платеж Заказчика [1..n]; EO-1.1.2/Счет-фактура Заказчика [1..n]
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	OU-4/Отдел ИКТ
Полномочия на операцию	OU-1/Работа предприятия

E.4.3.3. Пример шаблона конструкции Представление объекта

Заголовок
Метка конструкции	OV
Идентификатор	OV-13
Имя	Покупная Деталь
Уполномоченный проектировщик	OU-2 / Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Содержит всю информацию о деталях, необходимую для операции сборки
Свойства	Деталь — идентификация id = ABC123; геометрия детали = TBD; материал детали = сталь = ST 123
Ограничения	NIL
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Правила целостности	NIL
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Объект предприятия	PR-1.1/Деталь [1..n]
События	NIL
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	OU-4/Отдел ИКТ
Полномочия на операцию	OU-3/Работа предприятия

E.4.3.4. Пример шаблона конструкции Продукт

Заголовок
Метка конструкции	PR
Идентификатор	PR-1
Имя	Продукт
Уполномоченный проектировщик	OU-2 / Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Содержит всю информацию по продукту
Характер Объекта	ФИЗИЧЕСКИЙ
Свойства	Информация о продукте
Ограничения	NIL
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Правила целостности	NIL
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Взаимосвязи Класса — Перечень взаимосвязей Продукта в виде:
Специализация (чего-либо)	NIL
Часть (чего-либо)	PR-1.1/Деталь [1..n]; PR-1.2/Чертеж [1..n]; PR-1.3/BOM
Состоит из	[1..n]
Относящийся к	EO-1.1/Заказчик [1..n]; OR-1.1/Заказ клиента [1..n]
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	OU-4/Отдел ИКТ
Полномочия на операцию	OU-3/Работа предприятия

E.4.3.5. Пример шаблона конструкции Заказ

Заголовок
Метка конструкции	OR
Идентификатор	OR-1
Имя	Заказ
Уполномоченный проектировщик	OU-2 / Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Содержит всю информацию о заказах
Характер Объекта	ИНФОРМАЦИОННЫЙ
Свойства	Оформление Заказа
Ограничения	NIL
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Правила целостности	NIL
B1. Взаимосвязи, существенные для всех фаз модели предприятия
Взаимосвязи класса — Перечень взаимосвязей Заказа в виде:
Специализация	NIL
Часть (чего-либо)	NIL
Состоит из	OR 1.1/Заказ клиента [1..n]; OR 1.2/Заказ на закупку [1..n]; OR-1.3/Задание цеху [1..n]
Относящийся к	EO-1.1 / Заказчик [1..n]; EO-1.2/Поставщик[1..n]; PR-1 / Продукт [1..n];
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	OU-4 / Отдел ИКТ
Полномочия на операцию	OU-3 / Работа предприятия

E.4.4. Представление ресурсов

E.4.4.1. Разработка ресурсного представления

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

Рисунок E.4. Представление ресурсов для обработки заказа

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

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

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

b) Проекции объекта отбирают из предопределенных Объектов предприятия.

Опция b) является предпочтительным способом обеспечения согласованности модели предприятия и базы знаний предприятия.

E.4.4.2. Пример шаблона конструкции Ресурс

Заголовок
Метка конструкции	RE
Идентификатор	RE-1.4
Имя	Ресурсы сборки
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
	Не применяют
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Описание	Содержит всю информацию по ресурсам сборки, необходимым для того, чтобы собрать технические изделия
Характер Объекта	ФИЗИЧЕСКИЙ
Свойства	Расположение — здание 123, установлено — июль 2003 г., балансовая стоимость — 20,000 (евро)
Ограничения	MTF > 1500 ч, MTR < 4 ч
Правила целостности	NIL
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Обеспеченные Операционные роли	OPR-3/Оператор линии сборки
Обеспеченная Способность	CA-2/Станция механической сборки изделия
Взаимосвязи Класса — Перечень взаимосвязей Ресурсов в виде:
Специализация Части (чего-либо)	NIL
Состоит из	RE-1 Цех RE-1.4.1/Робот; RE-1.4.2/Испытательная станция; RE-1.4.3/Приспособление для сборки
Относящийся к	RE-1.4.4/Сборочный инструмент PR-1 / Продукт [1..n]
Операционные взаимосвязи
Ответственность за операцию	OU-3 / Цех
Полномочия на операцию	OU-3 / Цех

E.4.4.3. Пример шаблона конструкции Возможность

Заголовок
Метка конструкции	CA
Идентификатор	CA-2
Имя	Станция механической сборки изделия
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Описание	Содержит всю информацию, необходимую для описания станции для сборки технических изделий
Относящиеся к функции атрибуты	Обращение с деталью и изделием: от поддона до сборочной станции, от сборочной станции до испытательной станции, от испытательной станции до поддона с продукцией (расстояние до 1 м); установка в положение для обработки: детали в приспособление для сборки, изделия в испытательную станцию, изделия на поддон (погрешность +/- 0,1 мм); габариты изделия (2 м3); масса изделия (до 20 кг). Производительность сборки < 20/ч; производительность испытания < 20/ч
Ограничение	Возможность получения > 99,9%
Правила целостности	NIL
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Атрибуты, относящиеся к Рабочим характеристикам	20 изделий
Атрибуты, относящиеся к Операции	Работа в 2 смены
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.2. Применяют на фазе определения требований и следующих фазах
Способности включенные	CA-2.2/Робот
Где требуется	EA-4/собрать Изделие
Где обеспечено	TBD
B2.3. Применение на фазе спецификации схемы и следующих фазах
Операционные взаимосвязи
Ответственность за операцию	OU-3/Цех
Полномочия на операцию	OU-3/Цех

E.4.4.4. Пример шаблона конструкции Функциональная категория

Заголовок
Метка конструкции	FE
Идентификатор	FE-1
Имя	Обращение
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Описание	Содержит всю релевантную информацию о Функциональной сущности
Характер Объекта	ФИЗИЧЕСКИЙ
Свойства	Возможности ИКТ — контролируемый с помощью ПК (PC) LAN
Набор операций	Функциональная операция: (FO)-1 переместить Деталь (поддон с деталями к приспособлению); FO-2 переместить Изделие (приспособление к испытательной станции, от испытательной станции к поддону с изделиями); FO-3: установить Деталь в приспособлении; FO-4 установить Изделие (на испытательной станции на поддон с изделиями)
Ограничения	MTF/MTR, диапазон перемещения < 1,2 м; погрешность установки +/- 0,1 мм; полезная нагрузка < 25 кг; Стоимость эксплуатации ~ 100 (евро)/ч;
Правила целостности	NIL
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Обеспеченная Операционная роль	OPR-123/Оператор станции загрузки — разгрузки
Обеспеченные Способности	CA-2.2/Робот;
Взаимосвязи Класса — Перечень взаимосвязей Функциональной категории в виде:
Специализация (чего-либо)	NIL
Часть (чего-либо)	RE-1.4/Ресурсы сборки
Состоит из	NIL
Относящийся к	PR-1/Продукт [1..n]
Операционные взаимосвязи
Ответственность за операцию	OU-3/Цех
Полномочия на операцию	OU-3/Цех

E.4.5. Представление организации

E.4.5.1. Разработка организационного представления

На рисунке E.5 представлены организационные и решенческие аспекты примера обработки заказа. Начиная с общей концепции, приведенной в нижнем левом углу рисунка E.1, обязанности разных отделений организации и их членов указаны для объектов или Представлений объекта в других представлениях (функции, информации и ресурсов).

Рисунок E.5. Представление организации для обработки заказа

В нижнем правом углу рисунка E.5 GRAI используется для отображения связей между разными центрами принятия решений (указаны стрелками). Центры принятия решений расположены в определенном порядке в сетке в соответствии с длительностью горизонтов планирования и связанными с ними сроками пересмотра решений.

E.4.5.2. Пример шаблона конструкции Организационная единица

Заголовок
Метка конструкции	OU
Идентификатор	OU-3
Имя	Цех
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
Описание	Отвечает за работу цеха
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Организационный уровень	Отделение первого уровня
B1. Взаимосвязи, существенные на всех фазах модели предприятия
	Не применяют
B2. Взаимосвязи, существенные на разных фазах модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционные полномочия и обязанности
Полномочия/обязанности, относящиеся к Процессу	BP-2/Производство
Полномочия/обязанности, относящиеся к Информации	NIL
Полномочия/обязанности, относящиеся к Ресурсам	RE-1/Ресурсы цеха
Закрепления
Закрепленные Организационные роли/единицы	ORR-1/Супервайзер — Цех;
Закреплено Организационными единицами	OU-1/Работа предприятия

E.4.5.3. Пример шаблона конструкции Центр принятия решений

Заголовок
Метка конструкции	DC
Идентификатор	DC-1
Имя	Выравнивание перегрузки производства
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.1. Применение на фазе определения концепции и следующих фазах
Описание	Краткосрочная технологическая подготовка производства с целью выравнивания перегрузки
Фрейм решения (определяющий контекст решения, который должен быть удовлетворен с помощью экземпляра Центра принятия решений)
Задачи	Минимизировать заключение внешних субподрядных контрактов
Переменные	экстра часы; работы по субподрядам часы
Ограничения	50 < экстра часы < 100; 100 < субподряд часы < 500
Категория решения	Плановое производство
Уровень решения	H = 2 недели, P = 1 неделя
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Значимые	Второй уровень
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Операционная применяемость
Применяемость Процесса	BP-2/Производство
Применяемость Информации	EO-1/Рынок; EO-2/Отчет; EO-3/Статус; OR-1/Заказ; PR-1/Продукт
Применяемость Ресурсов	RE-1
Закрепления
Закрепленные Центры принятия Решений	NIL
Закреплено за Центром принятия решений	NIL
Закреплено за Организационной ролью	ORR-1/Супервайзер — Цех
Закреплено за Организационной единицей	OU-3/Цех

E.4.5.4. Пример шаблона конструкции Личностной профиль

Заголовок
Метка конструкции	PPR
Идентификатор	PPR-1
Имя	Джон Смит
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Профиль работника, релевантный для работы по найму на предприятии
Навыки, относящиеся к организации	Качества лидера; опыт оперативного планирования; составление сметы расходов отдела
Навыки, относящиеся к операции	Опыт в производстве технических изделий
Должностная инструкция Роли	Начальник цеха
Кто предоставляет навыки	ID1234/Джон Смит
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Закрепления
Закреплено за Организационной единицей	OU-3/Цех
Закреплено за Организационной ролью	ORR-1 7 Супервайзер
Закреплено за Операционной ролью	NIL

E.4.5.5. Пример шаблона конструкции Организационная роль

Заголовок
Метка конструкции	ORR
Идентификатор	ORR-1
Имя	Супервайзер — Цех
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.3. Применяют на фазе определения требований и следующих фазах
Организационные навыки	Лидерство; Оперативное планирование; Составление сметы расходов отдела
Обязанности	BP-2/Производство; Работа цеха
Полномочия	Внутренняя организация участка цеха; Распределение объема работ
B1. Взаимосвязи, существенные для всех фаз модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.2. Применяют на фазе определения требований и следующих фазах
Специализация (чего-либо)	NIL
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Закрепления
Закреплено за Организационной единицей	OU-3/Цех
Закреплено за Центром принятия решений	NIL

E.4.5.6. Пример шаблона конструкции Операционная роль

Заголовок
Метка конструкции	OPR
Идентификатор	OPR-2
Имя	Оператор
Уполномоченный проектировщик	OU-2/Технологическая подготовка производства
Содержание
A1. Дескриптивы, существенные для всех фаз модели предприятия
	Не применяют
A2. Дескриптивы, существенные для разных фаз модели предприятия
A2.2. Применяют на фазе определения требований и следующих фазах
Должностная инструкция Роли	Обслуживание и поддерживание работы сборочной станции
Операционные навыки	Обращение с деталью и изделием; ПК и операционные знания робота
A2.3. Применяют на фазе спецификации схемы и следующих фазах
Должностная инструкция Роли	Оператор сборочной станции
Операционный профиль	Сборка технического изделия, наладка и демонтаж сборочной станции, работа робота, работа ПК, визуальный контроль и проведение испытаний
B1. Взаимосвязи, существенные на всех фазах модели предприятия
	Не применяют
B2. Взаимосвязи, существенные для разных фаз модели предприятия
B2.2. Применяют на фазе определения требований и следующих фазах
Специализация (чего-либо)	NIL
B2.3. Применяют на фазе спецификации схемы и следующих фазах
Закрепления
Закреплено за организационной единицей	OU-3/Цех
Закреплено за Деятельностью предприятия	EA-4/собрать

E.5. Использование шаблона. Пример краткого изложения содержания

В таблице E.1 приведено применение конструкций языка моделирования в процессе моделирования предприятия на примере обработки заказа (см. рисунок E.1). Для каждой фазы модели идентифицируют наиболее важные этапы процесса моделирования и родственные конструкции языков моделирования. Такая идентификация начинается с конструкции домена в идентификации домена, что делает возможным определение границ домена (входов и выходов Домена с указанием их происхождения и назначения) и обеспечение функциональных возможностей, необходимых для преобразования вводов в Выходы соответственно. На следующих этапах в дополнительной информации указывают миссии домена и т.д. (фаза Определение концепции) и дополнительную информацию о вводах/выводах и функциональных возможностях. Конструкции Бизнес-процесс, Объект предприятия, Объектное представление, Событие и Организационная единица дополняют конструкцию Домен, обеспечивая релевантную идентификацию функциональных возможностей домена, его входов и выходов, а также полномочий по проектированию модели.

Таблица E.1

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

Фаза модели	Отношение к рисункам E.1 - E.5 и шаблонам		Конструкция
	Рисунок E.2: Представление функции
1. Идентификация домена	Домен: DM-1 Обработка Заказа на изготовление (свое предприятие)		Домен:
	Границы Домена: Входы Домена: OV-1/Заказ клиента, OV-13/Покупные детали Выходы Домена: OV-11/Продукт, OV-8/Заказ поставщика		Объект предприятия Представление объекта
	Происхождение и назначение вводов/выводов (I/O): DM-X/Заказчик; DM-Y/Поставщик		Событие
	Функциональные категории (Процессы): BP-1/Администрация, BP-2/Производство		Бизнес-процесс
	Уполномоченный проектировщик модели: OU-2/Планирование производства		Организационная единица
2. Определение концепции	DM-1/миссия домена, подход и значения Оперативная политика		Домен
	Функция решения и уровень		Центр принятия решений
3. Определение требования	Процессы: административный BP1/производственный BP2		Бизнес-процесс
	Действия: EA-1/обработать на станке; EA-2/окрасить; EA-3/складировать; EA-4/собрать		Деятельность предприятия
	События: задание цеху a; задание цеху b		Событие
	Входы действия (EA4): Функция: детали; покупные детали; Контроль: задание цеху Способность: сборка	Выходы действия (EA4): Функция: Продукт b Контроль: не используют	Представление объекта
		Способность: не используют	Способность: Операционная роль
	Рисунок E.3: Представление информации
	Объекты: деталь, продукт, рынок, заказ, отчет		Объект предприятия
	Представления: деталь, покупная деталь, продукт (изделие)		Представление объекта
	Рисунок E.5: Представление организации
	Категории: предприятие, отдел		Организационная единица: Центр принятия решений
4. Спецификация схемы	Рисунок E.2: Представления функции
	Процессы: административный процесс BP-1; производство BP-2		Бизнес-процесс
	События: задание цеху a; задание цеху b		Событие
	Входы Деятельности (EA4):	Выходы Деятельности (EA4)	Представление объекта
	Функция: детали; покупные детали	Функция: Продукт b
	Контроль: задание цеху	Контроль: статус Деятельности
	Ресурсы: ресурсы сборки	Ресурсы: статус Ресурсов
	Рисунок E.3: Представление информации
	Объекты: деталь, продукт (изделие), рынок, заказ, отчет		Объект предприятия
	Представления: деталь, покупная деталь, изделие		Представление объекта
	Рисунок E.4: Представление Ресурсов
	Лица: супервайзер, оператор		Личностный Профиль: Организационная роль
	Объекты: цех, сборочная станция, запасной резерв		Ресурсы
	Объекты: центр механической обработки		Функциональная категория
	Представления: сборочная станция, статус сборочной станции		Представление Объекта
	Рисунок E.5: Представление Организации
	Категории: предприятие, отделы: цех, отделы проектирования, планирования производства, закупок, продаж		Организационная единица
	Члены: Супервайзер		Организационная роль
	Временной период: месяц, неделя, день		Центр принятия решений
5. Описание внедрения	Модель спецификации схемы, измененная в соответствии с отклонениями по внедрению от спецификации схемы (на рисунках E.2 - E.5 не приведена)		Все вышеуказанное
6. Операции в домене	Операционное использование модели домена (разрешенная модель описания внедрения на рисунках E.2 - E.5 не приведена)
7. Определение прекращения использования	Модель домена, смоделированная заново для определения состояния окончания срока действия компонентов Домена (на рисунках E.2 - E.5 не приведена)		Все вышеуказанное

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

Таблица E.2

Примеры использования конструкций языка моделирования с множественными экземплярами Полученных Событий

Полученные события

Происхождение	ID	Имя
DM Заказчик	EV-1	Поступление заказа клиента
DM Заказчик	EV-2	Поступление платежа от Заказчика
DM Поставщик	EV-3	Поступление покупных деталей
DM Поставщик	EV-4	Поступление счета-фактуры
BP-1 Администрация	EV-9	Задание цеху a
BP-1 Администрация	EV-10	Задание цеху b

Направленные события

ID	Имя	Назначение
EV-5	Изделие для отправки	DM Заказчик
EV-6	Направление счета-фактуры	DM Заказчик
EV-7	Направление заказа на закупку	DM Поставщик
EV-8	Направление платежа	DM Поставщик
EV-11	Завершающее изделие a	BP-1 /Администрация
EV-12	Исключительная ситуация 4	Обработка исключительных ситуаций (TBD)

Объекты предприятия

ID	Имя
EO-1:	Рынок
EO-1.1	Заказчик
EO-1.1.1	C-Платеж
EO-1.1.2	C-Счет-фактура
EO-1.2	Поставщик
EO-1.2.1	S-Платеж
EO-1.2.2	S-Счет-фактура
EO-2	Отчет
EO-3:	Статус
EO-3.1	Статус Деятельность
EO-3.2	Статус Оператор
EO-3.3	Статус Ресурсы
OR-1:	Заказ
OR-1.1	Заказ клиента
OR-1.2	Заказ на закупку
OR-1.3	Задание цеху
PR-1:	Продукт
PR-1.1	Деталь
PR-1.2	Чертеж
PR-1.3	Ведомость материалов/BOM
PR-1.3.1	Материал
PR-1.3.2	Производственный план

Полученные объектные представления

Происхождение	ID	Имя
DM-Заказчик	OV-1	C-Заказ
DM-Заказчик	OV-2	C-Платеж
DM-Поставщик	OV-3	Покупная деталь
DM-Поставщик	OV-4	Счет-фактура
BP-1 Администрация	OV-9	Задание цеху a
BP-1 Администрация	OV-10	Задание цеху b
PR-1.1 Деталь	OV-12	Окрашенная деталь
PR-1.1 Деталь	OV-13	Покупная деталь

Направленные объектные представления

ID	Имя	Назначение
OV-5	Продукт a	DM Заказчик
OV-6	Счет-фактура	DM Заказчик
OV-7	P-Заказ	DM Поставщик
OV-8	S-Платеж	DM Поставщик
OV-11	Продукт b	DM Заказчик
OV-14	Информация о деятельности	EO-5 Статус деятельности
OV-15	Информация о ресурсах	EO-6 Статус ресурсов

Организационные единицы

ID	Имя
OU-1	Работа предприятия
OU-2	Технологическая подготовка производства
OU-3	Цех
OU-4	Отдел ИКТ

Члены Организации

ID	Имя
PPR-1	Супервайзер <Фамилия>
PPR-2	Оператор <Фамилия>

Центры принятия решений

ID	Имя
DC-1	Плановое производство

Объекты Ресурсов

ID	Имя
RE-1:	Цех
RE-1.1	Супервайзер
RE-1.2	Оператор
RE-1.3	Компьютер
RE-1.3.1	Терминал
RE-1.4	Ресурсы сборки
RE-1.4.1	Робот
RE-1.4.1.1	Программа управления роботом
RE-1.4.2	Испытательная станция
RE-1.4.2.1	Программа управления испытаниями
RE-1.4.3	Приспособление для сборки
RE-1.4.4	Сборочный инструмент
RE-1.5	Металлообрабатывающий станок
RE-1.6	Резервный запас
FE-1	Обращение

Возможности

ID	Имя
CA-1:	Механическая сборка изделия
CA-1.1	Наладка станции и отказ
CA-1.2	Обращение
CA-1.3	Установка в определенном положении
CA-1.4	Сборка
CA-2:	Рабочее место механической сборки изделия
CA-2.2	Робот
ORR-1	Надзор в цехе
OPR-2	Работа сборочной станции (Оператор с опытом практической работы)

Организационная роль

ID	Имя
ORR-1	Супервайзер

Операционная роль

ID	Имя
OPR-2	Оператор
OPR-3	Оператор сборки

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

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

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ИСО/МЭК 14977		<*>
ИСО 19439:2006	IDT	ГОСТ Р ИСО 19439-2008 «Интеграция предприятия. Основа моделирования предприятия»
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. Примечание. В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичный стандарт.

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

[1]	ИСО 10303-11	Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 11. Методы описания. Справочное руководство по языку EXPRESS
	(ISO 10303-11)	(Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual)
[2]	ИСО/МЭК 10746	Информационные технологии. Открытая распределенная обработка
	(ISO/IEC 10746)	(Information technology — Open Distributed Processing)
[3]	ИСО/МЭК 15288	Системотехника. Процессы жизненного цикла системы
	(ISO/IEC 15288)	(Systems engineering — System life cycle processes)
[4]	ИСО/МЭК 15414	Информационные технологии. Открытая распределенная обработка. Эталонная модель. Корпоративный язык
	(ISO/IEC 15414)	(Information technology — Open distributed processing — Reference model — Enterprise language)
[5]	ИСО 15531-1:2004	Системы промышленной автоматизации и интеграция. Управляющая информация промышленным производством. Часть 1. Общий обзор
	(ISO 15531-1:2004)	(Industrial automation systems and integration — Industrial manufacturing management data — Part 1: General overview)
[6]	ИСО 15704	Системы промышленной автоматизации. Требования к архитектуре эталонных предприятий и методологии
	(ISO 15704)	(Industrial automation systems — Requirements for enterprise-reference architectures and methodologies)
[7]	ИСО 15704:2000/дополнение 1:2005	Системы промышленной автоматизации. Требования к архитектуре эталонных предприятий и методологии. Изменение 1. Дополнительные представления с точки зрения пользователя
	(ISO 15704:2000/Amd. 1:2005)	(Industrial automation systems — Requirements for enterprise-reference architectures and methodologies — Amendment 1: Additional views for user concerns)
[8]	ИСО/МЭК 15909-1	Разработка программного обеспечения и систем. Сети Петри высокого уровня. Часть 1. Понятия, определения и графические обозначения
	(ISO/IEC 15909-1)	(Software and system engineering — High-level Petri nets — Part 1: Concepts, definitions and graphical notation)
[9]	ИСО 18629	Системы промышленной автоматизации и интеграция. Язык спецификаций процесса
	(ISO 18629)	(Industrial automation systems and integration — Process specification language)
[10]	ATHENA project FP6 507849 Deliverable DA1.3.1, Report on Methodology description and guidelines definition, Public, Version 0.95, March 2005
[11]	CIMOSA ASSOCIATION CIMOSA — Open System Architecture for CIM: Technical Baseline. Version 3.2, 1996 <52>
[12]	Doumeingts, G., Vallespir, B. and Chen, D. GRAI Grid Decision Modelling in: Peter Bernus, Kai Mertins, Gunter Schmidt, (eds), Handbook on Architecture for Information Systems. (Springer) pp. 313 — 337, 1998
[13]	REC XML 2000 2006 1006 eXtensible Markup Language (XML), 1.0, 2^{nd} edition, W3C Recommendation October 6, 2000
[14]	REC-xmlschema-1-20010502 Schema XML Part 1: Structures — recommendation W3C May 02, 2001
[15]	REC-xmlschema-2-20010502 Schema XML Part 2: Datatype — recommendation W3C May 02, 2001
[16]	Oxford English Dictionary, Oxford University Press 1999

---

<52> Документ приведен в сети Интернет по адресу: www.cimosa.de.

---