ПНСТ 173-2016/PAS 19450:2015 Системы промышленной автоматизации и интеграция. Объектно-процессуальная методология

     8.2 Операционная семантика и поток команд управления исполнением

8.2.1 Механизм управления событиями, условиями, действиями

Парадигма Event-Condition-Action (события-условия-действия) должна обеспечивать операционную OPM-семантику и поток команд управления исполнением. В момент создания или возникновения объекта с системной точки зрения (или в момент перехода объекта в определенное состояние) должно происходить событие. Во время выполнения те объекты, которые являются источником связи с процессом, например, средство реализации процесса, возникновение события должно инициализировать оценку предварительных условий для каждого процесса, с которым объект связывается в качестве источника этой связи.

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

Начальные характеристики процесса имеют два предварительных условия/требования:

a) наличие инициализирующего события и

b) выполнение предварительных условий.

Таким образом, события и предварительные условия/требования совместно определяют OPM-поток команд управления исполнением процесса.

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

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

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

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

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

Примечание 1 - Взаимное пересечение указанных наборов объектов для одного и того же процесса включает в себя объекты типа enablers и affectees. Объекты типа consumees являются только элементами набора предварительно обработанных объектов, в то время как объекты типа resultees - только элементами набора апостериорно обработанных объектов.

Примечание 2 - Семантика операционных экземпляров объектов в имеющемся наборе объектов описана в 14.2.2.4.4.

8.2.3 Сравнение пропущенной семантики состояния с ожидаемой семантикой безусловных связей

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

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

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

Примечание 1 - Не существует результирующей событийной связи или результирующей условной связи, поскольку имеются исходящие процедурные связи, относящиеся к набору апостериорно обработанных объектов. После завершения процесса он создает набор этих объектов без дополнительного условия, так что нет условия относительно создания объектов типа resultees или изменения объектов типа affectees. Создание объекта (возможно, в определенном состоянии) в наборе апостериорно обработанных объектов может послужить в качестве события или условия для последующего процесса (процессов).

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