5 Спецификация типов функциональных блоков, подприложений и адаптерных интерфейсов

5.1 Обзор

Как показано на рисунке 9, раздел 5 определяет средства спецификации типов для трёх видов блоков:

• Подраздел 5.2 определяет средства спецификации и определения поведения экземпляров базовых типов функциональных блоков (basic function block types), как показано на рисунке 9a. В этом типе функционального блока управление выполнением задаётся диаграммой управления выполнением (Execution Control Chart, ECC), а подлежащие выполнению алгоритмы (algorithms) объявляются в соответствии с совместимыми стандартами, определёнными в IEC 61499-4.

• Подраздел 5.3 определяет средства спецификации составных типов функциональных блоков (composite function block types), как показано на рисунке 9b. В этом типе функционального блока алгоритмы и управление их выполнением задаются через соединения событий и данных в одной или нескольких сетях функциональных блоков (function block networks).

• Подраздел 5.4 определяет средства спецификации типов подприложений (subapplication types), как показано на рисунке 9c. В этом типе блока алгоритмы и управление их выполнением задаются так же, как и для составных функциональных блоков, но со специфическим свойством: компонентные функциональные блоки (component function blocks) подприложений могут быть распределены между несколькими ресурсами (resources). Подприложения могут быть вложенными, так что тело подприложения может содержать компонентные подприложения (component subapplications).

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

Рисунок 9a -- Базовый функциональный блок (5.2)

Рисунок 9b -- Составной функциональный блок (5.3)

Рисунок 9c -- Подприложения (5.4)

Рисунок 9 -- Типы функциональных блоков и подприложений

5.2 Базовые функциональные блоки

5.2.1 Объявление типа

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

Базовый функциональный блок (basic function block) использует диаграмму управления выполнением (Execution Control Chart, ECC) для управления выполнением (execution) своих алгоритмов (algorithms).

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

a) имя типа (type name) функционального блока отображается вверху по центру нижней части блока;

b) имена и объявления типов входных переменных (input variables) и адаптеров-гнёзд (socket adapters) отображаются на левом краю нижней части блока;

c) имена и объявления типов выходных переменных (output variables) и адаптеров-штекеров (plug adapters) отображаются на правом краю нижней части блока;

d) интерфейс (interface) типа функционального блока к событиям (events) объявляется в верхней части блока, как указано в 5.2.1.2;

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

f) управление выполнением связанных алгоритмов объявляется как указано в 5.2.1.4.

Рисунок 10 -- Объявление типа базового функционального блока

5.2.1.2 Объявление интерфейса событий

Как показано на рисунке 10, интерфейс типа базового функционального блока к событиям может быть объявлен текстуально в соответствии с синтаксисом, приведённым в разделе B.2, или графически в соответствии со следующими правилами:

a) Интерфейсы событий (event interfaces) расположены в отдельной области в верхней части блока.

b) Имена входных событий (event inputs) отображаются на левой стороне верхней части блока.

c) Имена выходных событий (event outputs) отображаются на правой стороне верхней части блока.

d) Типы событий отображаются вне блока рядом с соответствующими входными или выходными событиями.

Примечания

1. Если тип события для входа или выхода не указан, он считается типом по умолчанию EVENT.
2. Выходное событие типа EVENT может быть соединено со входным событием любого типа, а входное событие типа EVENT может принимать события любого типа.
3. Выходное событие типа, отличного от EVENT, может быть соединено только со входным событием того же типа или типа EVENT.
4. Тип события неявно объявляется при его использовании в объявлении события.

Как показано на рисунке 10 и в Приложении F, квалификатор WITH или его графический эквивалент используется для задания ассоциации (association) между входными переменными (input variables) или выходными переменными (output variables) и событием на соответствующем входе события (event input) или выходе события (event output).

Каждая входная переменная и выходная переменная появляется в нуле или более конструкциях WITH или их графических эквивалентах.

Примечания

5. Эта информация может использоваться для определения необходимых коммуникационных сервисов (communication services) при конфигурировании (configuring) распределённого приложения, как описано в разделе 7.
6. Входная переменная, не появляющаяся ни в одной конструкции WITH, не может быть соединена с выходной переменной другого функционального блока. Значения таких переменных остаются на уровне объявленных начальных значений или устанавливаются командами управления, такими как WRITE, описанными в 6.3.2.
7. Выходная переменная, не появляющаяся ни в одной конструкции WITH, может быть соединена с входной переменной другого функционального блока или может быть «прочитана» командами управления, такими как READ, описанными в 6.3.2.
8. Применение квалификатора WITH к модели выполнения базового функционального блока см. в 4.5.3.

5.2.1.3 Объявление алгоритмов

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

Объявление алгоритма может включать объявление временных переменных (temporary variables), которые:

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

5.2.1.4 Объявление управления выполнением алгоритмов

Последовательность вызовов алгоритмов для типов базовых функциональных блоков может быть объявлена в спецификации типа функционального блока. Если алгоритмы типа базового функционального блока определены как указано в 5.2.1.3 (или иным образом идентифицированы), то последовательность вызовов алгоритмов для такого функционального блока может быть задана в форме диаграммы управления выполнением (Execution Control Chart, ECC), состоящей из состояний EC (EC states), переходов EC (EC transitions) и действий EC (EC actions). Эти элементы представляются и интерпретируются следующим образом:

a) ECC включается в секцию управления выполнением (execution control) объявления типа функционального блока, которая находится в верхней части блока;

b) ECC должна содержать ровно одно начальное состояние EC (EC initial state), представленное графически в виде фигуры с двойным контуром и связанным идентификатором (identifier). Начальное состояние EC не должно иметь связанных действий EC;

c) ECC должна содержать одно или более состояний EC (EC states), представленных графически в виде фигур с одинарным контуром, каждое со связанным идентификатором;

d) ECC может использовать, но не может изменять переменные, объявленные в спецификации типа функционального блока;

e) состояние EC может иметь ноль или более связанных действий EC (EC actions). Связь действий EC с состоянием EC может быть выражена в графической или текстовой форме;

f) алгоритм (если есть), связанный с действием EC, и событие (если есть), которое должно быть сгенерировано по завершении алгоритма, выражаются в графической или текстовой форме;

g) переход EC (EC transition) представляется графически или текстуально как направленная связь от одного состояния EC к другому (или к тому же самому состоянию);

h) каждый переход EC должен иметь связанное условие перехода (transition condition), содержащее ссылку на событие (event), условие-сторож (guard condition), или и то и другое, выраженное в синтаксисе, определённом для нетерминала ec_transition_condition в B.2.1.

На рисунке 11 показаны элементы ECC. Аналогичные текстовые объявления с использованием синтаксиса раздела B.2 даны в Приложении F.

Рисунок 11 -- Пример ECC

Примечания

1. Обозначение 1 (единица), показанное на рисунке 11, рассматривается как эквивалент [TRUE], представляющее условие перехода без связанного события и условие-сторож, которое всегда истинно.
2. В этой ограниченной области один и тот же символ (например, INIT) может быть использован для представления как состояния EC, так и имени алгоритма, поскольку назначение символа легко определяется по контексту использования.
3. Текст, выделенный курсивом, не является частью ECC.
4. Взаимно-однозначная ассоциация событий с алгоритмами, как показано на этом рисунке, встречается часто, но не является единственным возможным вариантом. Примеры других вариантов см. в таблице A.1: блок E_SPLIT показывает ассоциацию двух выходных событий с одним состоянием, но без алгоритмов; E_MERGE показывает ассоциацию одного выходного события, но без алгоритмов и с двумя входными событиями; E_DEMUX показывает ассоциацию любого из нескольких алгоритмов с одним входным событием; и т.д.

5.2.2 Поведение экземпляров

5.2.2.1 Инициализация

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

a) Значение каждой входной (input), выходной (output) и внутренней переменной (internal variable) должно быть инициализировано соответствующим начальным значением, указанным в спецификации типа функционального блока. Если такое начальное значение не определено, значение переменной инициализируется значением по умолчанию для данного типа данных.

b) Должны быть выполнены все дополнительные алгоритм-специфичные инициализации; например, все начальные шаги (initial steps) последовательных функциональных схем (Sequential Function Charts, SFCs) по IEC 61131-3 должны быть активированы, а все остальные шаги -- деактивированы.

c) Начальное состояние EC диаграммы управления выполнением (ECC) функционального блока должно быть активировано, все остальные состояния EC -- деактивированы, и конечный автомат операции ECC, определённый в 5.2.2.2, должен быть помещён в начальное состояние (s0).

note

Условия, при которых ресурс выполняет такую инициализацию, зависят от реализации (implementation-dependent).

Тип функционального блока может также задавать алгоритм инициализации, выполняемый при возникновении соответствующего события, например алгоритм INIT, показанный на рисунке 11. Приложение (application) может определить условия выполнения этого алгоритма, например, подключив выход экземпляра типа E_RESTART (определённого в Приложении A) ко входному событию, например входу INIT, показанному на рисунке 10.

5.2.2.2 Вызов алгоритмов

Выполнение (execution) алгоритма, связанного с экземпляром функционального блока (function block instance), вызывается (invoked) запросом к функции планирования (scheduling function) ресурса (resource) для планирования выполнения операций (operations) алгоритма.

Примечания

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

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

note

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

Рисунок 12 -- Конечный автомат операции ECC

Таблица 1 -- Состояния и переходы конечного автомата операции ECC

Состояние	Операции
s₀	--
s₁	оценить переходы (evaluate transitions)^c,e^
s₂	выполнить действия (perform actions)^d,e^

Переход	Условие	Операции
t₁	происходит входное событие (an input event occurs)^a^	Выборка входов (sample inputs)^b,e^
t₂	ни один переход не пересечён (no transition is crossed)
t₃	переход пересечён (a transition is crossed)
t₄	действия завершены (actions completed)

Пояснения к таблице

a. Ресурс должен обеспечить, чтобы не более одного входного события происходило в любой данный момент времени.

b. Эта операция состоит из выборки (sampling) (или её функционального эквивалента) входных переменных, связанных с текущим входным событием через объявление WITH, как описано в 5.2.1.2.

c. Эта операция состоит в оценке условий перехода на переходах EC, следующих за активным состоянием EC, и пересечении первого перехода EC (если таковой имеется), для которого условие guard_condition, определённое в B.2.1, является TRUE, в соответствии со следующими правилами:

1. «Пересечение перехода EC» заключается в деактивации его предшествующего состояния EC и активации его последующего состояния EC.
2. Порядок оценки условий перехода соответствует порядку объявления переходов, определённому в B.2.1, или эквивалентно в XML-синтаксисе, определённом в IEC 61499-2.
3. Условие guard_condition условия перехода, содержащее только event_input_name, имеет значение TRUE по умолчанию.
4. Если состояние s₁ было достигнуто через t₁, оцениваются только условия переходов, связанные с текущим входным событием через его event_input_name, определённый в B.2.1, или условия переходов без ассоциаций с событиями.
5. Если состояние s₁ было достигнуто через t₄, оцениваются только условия переходов без ассоциаций с событиями.

d. Эта операция состоит в выполнении для каждого действия EC (EC action), связанного с активным шагом EC (EC step): выполнения связанного алгоритма (если есть) и генерации события на связанном выходе события (если есть). Порядок выполнения действий соответствует порядку их графического отображения сверху вниз или порядку текстового объявления, определённому в B.2.1, или эквивалентно в XML-синтаксисе, определённом в IEC 61499-2.

e. Все операции, выполняемые от момента перехода t₁ до момента перехода t₂, должны быть реализованы как критическая секция (critical region) с блокировкой экземпляра функционального блока.

5.2.2.3 Объявление алгоритмов

Как показано в Приложении F, алгоритмы, связанные с типом базового функционального блока, могут быть включены в объявление типа функционального блока в соответствии с правилами объявления спецификации типа функционального блока, приведёнными в Приложении B. Другие средства также могут быть использованы для спецификации идентификаторов и тел алгоритмов; однако спецификация таких средств выходит за рамки данного стандарта.

Объявление алгоритма может включать объявление временных переменных (temporary variables), которые:

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

5.2.2.4 Объявление управления выполнением алгоритмов

Последовательность вызовов алгоритмов для типов базовых функциональных блоков может быть объявлена в спецификации типа функционального блока. Если алгоритмы типа базового функционального блока определены как указано в 5.2.1.3 (или иным образом идентифицированы), то последовательность вызовов алгоритмов может быть задана в форме диаграммы управления выполнением (ECC), состоящей из состояний EC, переходов EC и действий EC. Эти элементы представляются и интерпретируются в соответствии с правилами, описанными в 5.2.1.4.

5.2.2.5 Выполнение алгоритмов

Выполнение алгоритма (algorithm execution) в базовом функциональном блоке состоит из выполнения конечной последовательности операций, определяемых правилами, зависящими от реализации (implementation-dependent), соответствующими языку, на котором написан алгоритм, ресурсу, в котором он выполняется, и области, к которой он применяется. Выполнение алгоритма завершается после выполнения последней операции в этой последовательности.

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

5.3 Составные функциональные блоки

5.3.1 Спецификация типа

Объявление типов составных функциональных блоков (composite function block types) должно следовать правилам, приведённым в 5.2.1, с тем исключением, что входные события (event inputs) и выходные события (event outputs) компонентных функциональных блоков (component function blocks) могут быть соединены с входными и выходными событиями составного функционального блока для представления последовательности и причинно-следственных связей вызовов функциональных блоков. Следующие правила применяются к этому использованию:

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

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

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

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

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

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

Входные данные (data inputs) и выходные данные (data outputs) компонентных функциональных блоков могут быть соединены с входными и выходными данными составного функционального блока для представления потока данных внутри составного функционального блока. Следующие правила применяются к этому использованию:

• Каждый вход данных составного функционального блока может быть соединён с нулём или более входами данных нуля или более компонентных функциональных блоков, или с нулём или более выходами данных составного функционального блока, или с теми и другими.

• Каждый вход данных компонентного функционального блока может быть соединён не более чем с одним выходом данных ровно одного другого компонентного функционального блока или не более чем с одним входом данных составного функционального блока.

• Каждый выход данных компонентного функционального блока может быть соединён с нулём или более входами данных нуля или более компонентных функциональных блоков, или с нулём или более выходами данных составного функционального блока, или с теми и другими.

• Каждый выход данных составного функционального блока должен быть соединён ровно с одним выходом данных ровно одного компонентного функционального блока или ровно с одним входом данных составного функционального блока.

Примечания

1. Если элемент, объявленный в конструкции VAR_INPUT...END_VAR или VAR_OUTPUT...END_VAR, ассоциирован с входным или выходным событием соответственно через конструкцию WITH, это приведёт к созданию ассоциированной входной или выходной переменной, как в случае типов базовых функциональных блоков. Если такой элемент не ассоциирован с входным или выходным событием, то соответствующий поток данных передаётся напрямую к компонентным функциональным блокам или от них через описанные выше соединения.

2. Правила соединения событийных и переменных входов и выходов штекеров (plugs) и гнёзд (sockets) в теле составного функционального блока аналогичны правилам соединения входов и выходов компонентных функциональных блоков. Дополнительные требования к адаптерным интерфейсам см. в 5.5.

На рисунке 13 показано применение этих правил к примеру функционального блока PI_REAL. Рисунок 13a показывает графическое представление внешних интерфейсов, а рисунок 13b -- графическую конструкцию его тела. На рисунке 14 показаны интерфейсы и управление выполнением для типа функционального блока PID_CALC, используемого в теле примера PI_REAL.

Рисунок 13 — a) Внешний интерфейс, b) Графическое тело

Примечания

1. Полное текстовое объявление этого типа функционального блока приведено в Приложении F.
2. Этот пример является иллюстративным. Детали спецификации не являются нормативными.

Рисунок 13 -- Пример составного функционального блока PI_REAL

Рисунок 14 — a) Внешний интерфейс, b) Управление выполнением

note

Этот пример является иллюстративным. Детали спецификации не являются нормативными.

Рисунок 14 -- Пример базового функционального блока PID_CALC

5.3.2 Поведение экземпляров

Вызов (invocation) и выполнение (execution) компонентных функциональных блоков в составных функциональных блоках выполняются следующим образом:

a) Если вход события составного функционального блока соединён с выходом события блока, возникновение события на входе события вызывает генерацию события на ассоциированном выходе события.

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

c) Если выход события компонентного функционального блока соединён со входом события второго компонентного функционального блока, возникновение события на выходе события первого блока вызывает планирование вызова функции управления выполнением второго блока с возникновением события на ассоциированном входе события второго блока.

d) Если выход события компонентного функционального блока соединён с выходом события составного функционального блока, возникновение события на выходе события компонентного блока вызывает генерацию события на ассоциированном выходе события составного функционального блока.

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

5.4 Подприложения

5.4.1 Спецификация типа

Объявление типов подприложений (subapplication types) аналогично объявлению типов составных функциональных блоков, определённому в 5.3.1, с тем исключением, что ограничивающими ключевыми словами должны быть SUBAPPLICATION..END_SUBAPPLICATION. Следующие правила применяются к этому использованию:

a) Квалификатор WITH не используется в объявлении входных и выходных событий типов подприложений.

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

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

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

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

Примечания

1. Компонентные функциональные блоки могут включать экземпляры блоков обработки событий, определённых в Приложении A, например, экземпляры блока E_SPLIT для «разделения» событий, экземпляры блока E_MERGE для «слияния» событий, или и то и другое с использованием эквивалентного графического сокращения.

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

• Каждый вход данных подприложения может быть соединён с нулём или более входами данных нуля или более компонентных функциональных блоков или компонентных подприложений, или с нулём или более выходами данных подприложения, или с теми и другими.

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

• Каждый выход данных компонентного функционального блока или компонентной подприложения может быть соединён с нулём или более входами данных нуля или более компонентных функциональных блоков или компонентных подприложений, или с нулём или более выходами данных подприложения, или с теми и другими.

• Каждый выход данных подприложения должен быть соединён ровно с одним выходом данных ровно одного компонентного функционального блока или компонентной подприложения, или ровно с одним входом данных подприложения.

Примечания

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

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

ПРИМЕР. На рисунке 15 показано применение этих правил к примеру подприложения PI_REAL_APPL. Рисунок 15a показывает графическое представление внешних интерфейсов, а рисунок 15b -- графическую конструкцию тела. Тело подприложения PI_REAL_APPL использует тип функционального блока PID_CALC из примера составного функционального блока в 5.3.1, показанного на рисунке 14.

Рисунок 15 — a) Внешний интерфейс, b) Графическое тело

Примечания

1. Полное текстовое объявление этого типа подприложения приведено в Приложении F.
2. Этот пример является иллюстративным. Детали спецификации не являются нормативными.

Рисунок 15 -- Пример подприложения PI_REAL_APPL

5.4.2 Поведение экземпляров

Вызов (invocation) операций (operations) компонентных функциональных блоков или компонентных подприложений в подприложениях выполняется следующим образом:

a) Если вход события подприложения соединён с выходом события блока, возникновение события на входе события вызывает генерацию события на ассоциированном выходе события.

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

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

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

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

5.5 Адаптерные интерфейсы

5.5.1 Общие принципы

Адаптерные интерфейсы (adapter interfaces) могут использоваться для компактного представления заданного набора потоков событий и данных. Как показано на рисунке 16, тип адаптерного интерфейса (adapter interface type) предоставляет средства определения подмножества (называемого штекерный адаптер, plug adapter) входов (inputs) и выходов (outputs) функционального блока-поставщика (provider), которое может быть вставлено в соответствующее подмножество выходов и входов (называемое гнездовой адаптер, socket adapter) функционального блока-приёмника (acceptor). Таким образом, адаптерный интерфейс представляет пути событий и данных, по которым поставщик предоставляет сервис (service) приёмнику, или наоборот, в зависимости от паттернов взаимодействия поставщик/приёмник, которые могут быть представлены последовательностями примитивов сервиса (service primitives), как описано в 6.1.3.

note

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

Рисунок 16 -- Адаптерные интерфейсы -- Концептуальная модель

ПРИМЕР. Адаптерный интерфейс, показанный на рисунке 17, представляет операцию передачи заготовки от «расположенного выше» (upstream) оборудования, представленного поставщиком штекерного адаптера, к «расположенному ниже» (downstream) оборудованию, представленному приёмником с соответствующим гнездовым адаптером. Как показано на рисунке 17b, типичное взаимодействие состоит из следующей последовательности:

a) Событие в вышестоящем оборудовании, например, прибытие заготовки на позицию выгрузки, вызывает событие LD, обычно интерпретируемое как команда «загрузить», для передачи нижестоящему оборудованию. С этим событием ассоциировано значение датчика WO, указывающее, действительно ли заготовка присутствует для передачи, а также некоторое измеренное свойство или набор свойств заготовки, в данном случае -- её цвет.

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

c) Затем событие CNF, обычно интерпретируемое как подтверждение отпускания заготовки, передаётся от вышестоящего к нижестоящему оборудованию для завершения операции. В этот момент выход WO обычно имеет значение FALSE, а значение выхода WKPC не имеет значения.

Рисунок 17a -- Интерфейс

Рисунок 17b -- Последовательность сервисов

Примечания

1. Полное текстовое объявление этого типа адаптера приведено в Приложении F.
2. Этот пример является иллюстративным. Детали спецификации не являются нормативными.
3. Пояснение последовательностей сервисов см. в 6.1.2.

Рисунок 17 -- Объявление типа адаптера -- графический пример

5.5.2 Спецификация типа

Объявление типа адаптерного интерфейса (adapter interface type) должно определять только имя типа интерфейса (interface type name) и содержащиеся в нём интерфейсы событий (event interfaces) и интерфейсы данных (data interfaces). Они определяются графически или текстуально так же, как имя типа, интерфейсы событий и интерфейсы данных типа базового функционального блока, определённые в 5.2.1.1 и 5.2.1.2, за исключением того, что ключевыми словами для начала и окончания текстового объявления типа являются ADAPTER...END_ADAPTER. Текстовый синтаксис объявления адаптерных интерфейсов приведён в разделе B.7.

5.5.3 Использование

Использование типов адаптерных интерфейсов (adapter interface types) и экземпляров (instances) должно соответствовать следующим правилам:

a) Экземпляры адаптерных интерфейсов, используемые как штекеры (plugs) в экземплярах типа функционального блока, должны быть объявлены в объявлении типа в блоке PLUGS...END_PLUGS с указанием имени экземпляра (instance name) и типа адаптерного интерфейса (adapter interface type) каждого штекера. В графическом представлении типов и экземпляров функциональных блоков штекеры отображаются как выходные переменные со специальным текстовым или графическим обозначением, указывающим, что они не являются обычными выходными переменными.

b) Экземпляры адаптерных интерфейсов, используемые как гнёзда (sockets) в экземплярах типа функционального блока, должны быть объявлены в объявлении типа в блоке SOCKETS...END_SOCKETS с указанием имени экземпляра и типа адаптерного интерфейса каждого гнезда. В графическом представлении типов и экземпляров функциональных блоков гнёзда отображаются как входные переменные со специальным текстовым или графическим обозначением, указывающим, что они не являются обычными входными переменными.

c) Входы (inputs) и выходы (outputs) штекера (plug) используются в объявлении типа функционального блока так же, как входы и выходы функционального блока.

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

e) Вставка штекеров в гнёзда задаётся в блоке ADAPTER_CONNECTIONS...END_CONNECTIONS в объявлении приложения (application), подприложения (subapplication), типа ресурса (resource type), экземпляра ресурса (resource instance) или типа составного функционального блока (composite function block type), содержащем соответствующие экземпляры поставщика и приёмника.

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

g) Вставка штекеров в гнёзда подчиняется следующим ограничениям:

1. штекер может быть вставлен только в гнездо того же типа адаптерного интерфейса;
2. штекер может быть вставлен в ноль или одно гнездо одновременно;
3. гнездо может принимать ноль или один штекер одновременно;
4. штекер может быть вставлен в гнездо только если оба находятся в одном и том же составном функциональном блоке, ресурсе, приложении или подприложении.

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

Функциональные блоки управления (management function blocks), описанные в 6.3, могут предоставлять средства для динамического создания, удаления и запроса адаптерных соединений.

ПРИМЕР 1. Экземпляр типа XBAR_MVCA, показанного на рисунке 18, выступает одновременно как поставщик штекерного интерфейса (LDU_PLG) и как приёмник гнездового интерфейса (LDU_SKT). Тем самым он абстрагирует и инкапсулирует взаимодействия экземпляра типа XBAR_MVC с «вышестоящими» и «нижестоящими» функциональными единицами.

Рисунок 18 — a) Интерфейс, b) Тело

Примечания

1. Полное текстовое объявление этого примера приведено в Приложении F.
2. Этот пример является иллюстративным. Детали спецификации не являются нормативными.
3. Хотя этот пример представляет только составной тип, типы функциональных блоков поставщик и приёмник могут быть как базовыми, так и составными.

Рисунок 18 -- Иллюстрация объявлений типов функциональных блоков поставщика и приёмника

ПРИМЕР 2. На рисунке 19 показана конфигурация ресурса, содержащая два экземпляра типа XBAR_MVCA, показанного на рисунке 18. Экземпляр SUPPLY выступает как приёмник («нижестоящий блок») для блока HMI и поставщик («вышестоящий блок») для блока BORE, а экземпляр TAKEOFF выполняет соответствующие роли для блоков BORE и UNLOAD.

Примечания

1. Этот пример является иллюстративным. Детали спецификации не являются нормативными.
2. Соединения параметров (parameter) опущены на этой диаграмме для наглядности.
3. Объявления типов блоков, кроме типа XBAR_MVCA, не приводятся в Приложении F.

Рисунок 19 -- Иллюстрация адаптерных соединений

5.6 Обработка исключений и отказов

Дополнительные средства для предотвращения, распознавания и обработки исключений (exceptions) и отказов (faults) могут быть предоставлены ресурсами (resources). Такие возможности могут быть смоделированы как функциональные блоки сервисного интерфейса (service interface function blocks). Определение конкретных типов функциональных блоков для предотвращения, распознавания и обработки исключений и отказов выходит за рамки данного стандарта. Однако выходы INIT-, CNF- и IND- функциональных блоков сервисного интерфейса и ассоциированные значения STATUS могут использоваться для индикации возникновения и типа исключений и отказов, как указано в 6.1.3.