6 Сервисные интерфейсные функциональные блоки (Service interface function blocks)

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

6.1.1 Общие сведения

Сервисный интерфейсный функциональный блок (service interface function block, SIFB) предоставляет приложению один или несколько сервисов (services) на основе отображения (mapping) сервисных примитивов (service primitives) на входные события (event inputs), выходные события (event outputs), входные данные (data inputs) и выходные данные (data outputs) функционального блока.

Внешние интерфейсы типов SIFB имеют тот же общий вид, что и базовые типы функциональных блоков (basic function block types). Однако некоторые входы и выходы SIFB имеют специализированную семантику, а поведение экземпляров (instances) этих типов определяется через специальную графическую нотацию последовательностей сервисных примитивов.

note

Спецификация внутренних операций SIFB выходит за рамки данного стандарта.

6.1.2 Спецификация типов

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

Таблица 2 -- Стандартные входы и выходы SIFB

Элемент	Описание
Входные события
INIT	Отображается на примитив запроса (request primitive), инициирующий инициализацию сервиса, например локальную инициализацию коммуникационного соединения или модуля интерфейса процесса
REQ	Отображается на примитив запроса (request primitive) сервиса, предоставляемого экземпляром ФБ
RSP	Отображается на примитив ответа (response primitive) сервиса, предоставляемого экземпляром ФБ
Выходные события
INITO	Отображается на примитив подтверждения (confirm primitive), указывающий на завершение процедуры инициализации сервиса
CNF	Отображается на примитив подтверждения (confirm primitive) сервиса
IND	Отображается на примитив индикации (indication primitive) сервиса
Входные данные
QI: BOOL	Квалификатор сервисных примитивов, отображенных на входные события. Например, если QI = TRUE при событии INIT -- запрашивается инициализация; если FALSE -- завершение сервиса
PARAMS: ANY	Параметры, связанные с сервисом, обычно элементы экземпляра структурированного типа данных
SD_1, ..., SD_m: ANY	Данные, связанные с примитивами запроса и ответа
Выходные данные
QO: BOOL	Квалификатор сервисных примитивов, отображенных на выходные события. TRUE при INITO означает успешную инициализацию, FALSE -- неуспешную
STATUS: ANY	Статус сервиса при возникновении выходного события
RD_1, ..., RD_n: ANY	Данные, связанные с примитивами подтверждения и индикации

На Рис. 20 показаны примеры SIFB, в которых основное взаимодействие инициируется приложением (a) и ресурсом (b).

Рисунок 20 -- Примеры сервисных интерфейсных функциональных блоков: (a) взаимодействие, инициируемое приложением (REQUESTER); (b) взаимодействие, инициируемое ресурсом (RESPONDER)

note

REQUESTER и RESPONDER обозначают конкретные сервисы, предоставляемые экземплярами соответствующих типов ФБ.

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

Поведение экземпляров SIFB определяется в спецификации соответствующего типа ФБ с помощью диаграмм последовательности сервисов (service sequence diagrams) в соответствии со следующими правилами:

a) Применяется следующая семантика:

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

b) Если сервис представлен одним SIFB, диаграмма разделяется на два поля вертикальной линией:

1. Для взаимодействия, инициируемого приложением: приложение (application) слева, ресурс (resource) справа (Рис. 21a).
2. Для взаимодействия, инициируемого ресурсом: ресурс слева, приложение справа (Рис. 21b).

c) Для сервисов, представленных двумя или более SIFB, используется нотация из E.2.2 и E.2.3.

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

e) Суффикс "+" у имени входного события означает QI = TRUE, суффикс "-" означает QI = FALSE.

f) Суффикс "+" у имени выходного события означает QO = TRUE, суффикс "-" означает QO = FALSE.

g) Стандартная семантика утвержденных (+) и отрицательных (-) событий приведена в Таблице 3.

Таблица 3 -- Семантика сервисных примитивов

Примитив	Семантика
INIT+	Запрос на установление сервиса
INIT-	Запрос на завершение сервиса
INITO+	Индикация успешного установления сервиса
INITO-	Отклонение запроса на установление сервиса или индикация завершения
REQ+	Нормальный запрос сервиса
REQ-	Отключенный запрос сервиса
CNF+	Нормальное подтверждение сервиса
CNF-	Индикация аномального состояния сервиса
IND+	Индикация нормального поступления сервиса
IND-	Индикация аномального состояния сервиса
RSP+	Нормальный ответ приложения
RSP-	Аномальный ответ приложения

На Рис. 21 показаны нормальные последовательности инициализации сервиса, передачи данных и завершения сервиса.

Рисунок 21 -- Примеры диаграмм последовательности сервисов: (слева) взаимодействие, инициируемое приложением (запрос/подтверждение); (справа) взаимодействие, инициируемое ресурсом (индикация/ответ)

---

6.2 Коммуникационные функциональные блоки (Communication function blocks)

6.2.1 Спецификация типов

Коммуникационные функциональные блоки обеспечивают интерфейс (interface) между приложениями (applications) и функциями «коммуникационного отображения» (communication mapping) ресурсов, определенными в 4.3; таким образом, они являются сервисными интерфейсными функциональными блоками, описанными в 6.1.

Коммуникационный ФБ может быть как базового (basic), так и составного (composite) типа, при условии что его работа может быть представлена отображением сервисных примитивов на входные события, выходные события, входные и выходные данные.

Данный раздел определяет правила объявления типов коммуникационных ФБ. Раздел 6.2.2 определяет правила поведения экземпляров. Раздел E.2 определяет общие (generic) типы коммуникационных ФБ для однонаправленных (unidirectional) и двунаправленных (bidirectional) транзакций, а также правила их реализационно-зависимой настройки.

Объявление типов коммуникационных ФБ использует средства, определенные в 6.1, со специализированной семантикой переменных, приведенной в Таблице 4.

Таблица 4 -- Семантика переменных коммуникационных ФБ

Переменная	Семантика
PARAMS	Параметры коммуникационного соединения (communication connection), связанного с экземпляром ФБ. Включает идентификацию коммуникационного протокола и соединения, а также может включать ограничения по таймингу и другие параметры
SD_1, ..., SD_m	Данные для передачи по коммуникационному соединению, указанному в PARAMS, при возникновении примитива REQ+ или RSP+
STATUS	Статус коммуникационного соединения: нормальное завершение инициализации/передачи или причина аномалии
RD_1, ..., RD_n	Данные, полученные по коммуникационному соединению, указанному в PARAMS, при возникновении примитива IND+ или CNF+

note

Объявления типов коммуникационных ФБ могут определять ограничения между выходами RD_1,...,RD_n и входами SD_1,...,SD_m. Например, число и типы выходов RD могут быть ограничены соответствием числу и типам входов SD.

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

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

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

Таблица 5 -- Семантика сервисных примитивов для коммуникационных ФБ

Примитив	Семантика
INIT+	Запрос на установление коммуникационного соединения
INIT-	Запрос на разрыв коммуникационного соединения
INITO+	Индикация установления коммуникационного соединения
INITO-	Отклонение запроса на установление или индикация разрыва соединения
REQ+	Нормальный запрос на передачу данных
REQ-	Отключенный запрос на передачу данных
CNF+	Нормальное подтверждение передачи данных
CNF-	Индикация аномальной передачи данных
IND+	Индикация нормального поступления данных
IND-	Индикация аномального поступления данных
RSP+	Нормальный ответ приложения на поступление данных
RSP-	Аномальный ответ приложения на поступление данных

Однонаправленная коммуникация: PUBLISH / SUBSCRIBE

Однонаправленные транзакции (unidirectional transactions) используют пару типов ФБ:

• PUBLISH -- издатель (publisher), отправляющий данные. Содержит входные события INIT и REQ, выходные события INITO и CNF, входные данные QI, PARAMS, SD_1,...,SD_m и выходные данные QO, STATUS.
• SUBSCRIBE -- подписчик (subscriber), принимающий данные. Содержит входные события INIT и RSP, выходные события INITO и IND, входные данные QI, PARAMS и выходные данные QO, STATUS, RD_1,...,RD_n.

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

Двунаправленная коммуникация: CLIENT / SERVER

Двунаправленные транзакции (bidirectional transactions) используют пару типов ФБ:

• CLIENT -- клиент, инициирующий запрос. Содержит входные события INIT и REQ, выходные события INITO и CNF, входные данные QI, PARAMS, SD_1,...,SD_m и выходные данные QO, STATUS, RD_1,...,RD_n.
• SERVER -- сервер, отвечающий на запрос. Содержит входные события INIT и RSP, выходные события INITO и IND, входные данные QI, PARAMS, SD_1,...,SD_m и выходные данные QO, STATUS, RD_1,...,RD_n.

Клиент отправляет запрос (REQ+) с данными SD_1,...,SD_m, сервер получает индикацию (IND+) с данными в RD_1,...,RD_n, обрабатывает запрос и отвечает (RSP+) с данными SD_1,...,SD_m, после чего клиент получает подтверждение (CNF+) с данными в RD_1,...,RD_n.

---

6.3 Управляющие функциональные блоки (Management function blocks)

6.3.1 Требования

Расширение функциональных требований к «управлению приложениями» (application management) из ISO/IEC 7498-1:1994 на распределенную модель приложений данного стандарта предполагает, что сервисы управления ресурсами и приложениями в IPMCS должны обеспечивать следующие функции:

a) В ресурсе (resource) -- создание, инициализацию, запуск, остановку, удаление, запрос существования и атрибутов (attributes) и уведомление об изменениях для:

1. типов данных (data types);
2. типов и экземпляров функциональных блоков;
3. соединений (connections) между экземплярами ФБ.

b) В устройстве (device) -- создание, инициализацию, запуск, остановку, удаление, запрос существования и атрибутов и уведомление об изменениях доступности и статуса ресурсов.

Примечание 1

Положения данного стандарта не предназначены для выполнения требований системного управления (system management) из ISO/IEC 7498-4 и ISO/IEC 10040.

Примечание 2

Данный стандарт рассматривает только управление приложениями в ресурсах. Структура управления устройствами описана в IEC 61499-2.

6.3.2 Спецификация типов

На Рис. 22 показана общая форма типов управляющих функциональных блоков (management function block types), экземпляры которых удовлетворяют описанным выше требованиям.

Рисунок 22 -- Общий тип управляющего функционального блока (MANAGER)

Интерфейс типа MANAGER включает:

• Входные события: INIT, REQ
• Выходные события: INITO, CNF
• Входные данные: QI: BOOL, PARAMS: WSTRING, CMD: UINT, OBJECT: BYTE[512]
• Выходные данные: QO: BOOL, STATUS: UINT, RESULT: BYTE[512]

note

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

Поведение экземпляров управляющих ФБ следует правилам для SIFB с взаимодействием, инициируемым приложением, с дополнительными сценариями для неуспешной инициализации и ошибок команд, показанными на Рис. 23.

Рисунок 23 -- Последовательности сервисных примитивов при неуспешном обслуживании: (слева) неуспешное установление (unsuccessful_establishment); (справа) ошибка команды (command_error)

Команды управления (CMD)

Управляющая операция задается значением входа CMD в соответствии с Таблицей 6.

Таблица 6 -- Значения входа CMD и их семантика

Значение	Команда	Семантика
0	CREATE	Создать указанный объект
1	DELETE	Удалить указанный объект
2	START	Запустить указанный объект
3	STOP	Остановить указанный объект
4	READ	Прочитать данные параметра
5	WRITE	Записать данные параметра
6	KILL	Сделать указанный объект невосстанавливаемым
7	QUERY	Запросить информацию об указанном объекте
8	RESET	Сбросить указанный объект

Статус выполнения (STATUS)

Значения и семантика выхода STATUS определены в Таблице 7.

Таблица 7 -- Значения выхода STATUS и их семантика

Значение	Статус	Семантика
0	RDY	Нет ошибок
1	BAD_PARAMS	Некорректное значение входа PARAMS
2	LOCAL_TERMINATION	Завершение, инициированное приложением
3	SYSTEM_TERMINATION	Завершение, инициированное системой
4	NOT_READY	Менеджер не может обработать команду
5	UNSUPPORTED_CMD	Запрошенная команда не поддерживается
6	UNSUPPORTED_TYPE	Запрошенный тип объекта не поддерживается
7	NO_SUCH_OBJECT	Указанный объект не существует
8	INVALID_OBJECT	Некорректный синтаксис спецификации объекта
9	INVALID_OPERATION	Запрошенная операция недопустима для данного объекта
10	INVALID_STATE	Запрошенная операция недопустима для текущего состояния объекта
11	OVERFLOW	Предыдущая транзакция ещё выполняется

Синтаксис команд (OBJECT / RESULT)

Вход OBJECT задает объект, над которым выполняется операция согласно значению CMD, а выход RESULT содержит описание результата операции. Фактические длины OBJECT и RESULT зависят от реализации (implementation-dependent).

Таблица 8 -- Синтаксис команд

CMD	OBJECT	RESULT
CREATE	type_declaration	data_type_name
	fb_type_declaration	fb_type_name
	fb_instance_definition	fb_instance_reference
	connection_definition	connection_start_point
DELETE	data_type_name	data_type_name
	fb_type_name	fb_type_name
	fb_instance_reference	fb_instance_reference
	connection_definition	connection_definition
START	fb_instance_reference	fb_instance_reference
	application_name	application_name
STOP	fb_instance_reference	fb_instance_reference
	application_name	application_name
KILL	fb_instance_reference	fb_instance_reference
QUERY	all_data_types	data_type_list
	all_fb_types	fb_type_list
	data_type_name	type_declaration
	fb_type_name	fb_type_declaration
	fb_instance_reference	fb_status
	connection_start_point	connection_end_points
	application_name	fb_instance_list
READ	parameter_reference	parameter
WRITE	referenced_parameter	parameter_reference
RESET	fb_instance_reference	fb_status

Ошибки при CREATE:

• Будет ошибка (INVALID_OBJECT), если команда CREATE пытается создать ФБ с именем экземпляра, дублирующим существующий в том же ресурсе, дублирующее соединение, или множественные соединения к одному входу данных. Исключение: CREATE может заменить соединение параметра к входу данных новым параметрическим соединением.

Ошибки при DELETE:

• Будет ошибка (UNSUPPORTED_TYPE), если CREATE пытается создать экземпляр ФБ или параметр типа, неизвестного управляющему ФБ.
• Будет ошибка (INVALID_OPERATION), если DELETE пытается удалить тип ФБ, экземпляр ФБ, тип данных или соединение, определенные в спецификации типа управляемого ресурса.

Семантика START и STOP:

• START и STOP экземпляра ФБ определяются в 6.3.3.
• START и STOP приложения (application) эквивалентны START и STOP всех экземпляров ФБ приложения в управляемом ресурсе.
• STOP управляющего ФБ эквивалентен STOP всех экземпляров ФБ в управляемом ресурсе.
• START управляющего ФБ эквивалентен START всех экземпляров ФБ в управляемом ресурсе. Если ресурс был ранее остановлен, генерируется событие на выходе WARM каждого экземпляра E_RESTART (при предшествующей команде STOP) или на выходе COLD (в противном случае).

Семантика QUERY:

• Если OBJECT указывает на входное событие (event input), выходное событие (event output) или выход данных (data output), RESULT содержит ноль или более противоположных конечных точек.
• Если OBJECT указывает на вход данных (data input), RESULT содержит ноль или одну противоположную конечную точку.
• Если OBJECT указывает имя приложения, RESULT содержит имена всех ФБ этого приложения в управляемом ресурсе.

6.3.3 Поведение управляемых функциональных блоков

Функциональные блоки, находящиеся под управлением управляющего ФБ, демонстрируют операционное поведение, эквивалентное диаграмме переходов состояний на Рис. 24.

Рисунок 24 -- Операционная диаграмма состояний управляемого функционального блока

Состояния:

• IDLE (Ожидание) -- начальное состояние после создания; действие при входе: initialize (инициализация)
• RUNNING (Выполнение) -- ФБ работает; действие: runECC (выполнение автомата ECC)
• STOPPED (Остановлен) -- ФБ остановлен; действие при входе: completeAlgorithm (завершение текущего алгоритма)
• KILLED (Аварийно остановлен) -- ФБ принудительно остановлен; действие при входе: stopAlgorithm (немедленная остановка алгоритма)

Переходы:

• CREATE[type_defined] --> IDLE
• START --> RUNNING
• STOP --> STOPPED
• KILL --> KILLED
• RESET --> IDLE (из STOPPED или KILLED)
• DELETE[is_deletable] --> уничтожение (из IDLE, STOPPED или KILLED)

Правила переходов:

a) Заглавные условия переходов на Рис. 24 соответствуют значению входа CMD (Таблица 6) управляющего ФБ при возникновении сервисного примитива REQ+.

b) Последовательность command_error возникает при следующих условиях:

1. UNSUPPORTED_CMD -- на Рис. 24 нет состояния с таким условием перехода.
2. INVALID_STATE -- текущее активное состояние не имеет перехода для данного значения CMD.
3. UNSUPPORTED_TYPE -- CMD = CREATE, но экземпляр ФБ не существует и тип неизвестен менеджеру (условие type_defined = FALSE).
4. INVALID_OPERATION -- CMD = DELETE, но экземпляр ФБ находится в состоянии STOPPED или KILLED, и он объявлен в спецификации типа устройства или ресурса (условие is_deletable = FALSE).

c) Последовательность normal_command_sequence для типа MANAGER должна следовать за сервисным примитивом CMD+ при всех прочих условиях, с значением RDY для выхода STATUS (Таблица 7) и соответствующим значением выхода RESULT (Таблица 8).

d) Семантика действий на Рис. 24 для управляемых базовых и сервисных интерфейсных ФБ приведена в Таблице 9.

e) Действия, описанные в предыдущем правиле, применяются рекурсивно ко всем компонентным ФБ (component function blocks) управляемых составных ФБ (composite function blocks).

Таблица 9 -- Семантика действий на Рис. 24

Действие	Базовые ФБ	Сервисные интерфейсные ФБ
initialize	Инициализация всех переменных (5.2.2.1). Выполнение прочих операций инициализации.	Инициализация всех переменных (5.2.2.1). Перевод сервиса в состояние, корректное для ответа на примитив INIT+.
runECC	Разрешение работы автомата ECC (5.2.2.2).	Разрешение вызова сервисных примитивов по событиям на входах и генерации событий на выходах.
completeAlgorithm	Разрешение завершения текущего активного алгоритма (если есть) без дальнейшей генерации выходных событий.	Разрешение завершения текущего активного сервисного примитива.
stopAlgorithm	Немедленное прекращение операций текущего активного алгоритма (если есть).	Немедленное прекращение всех операций сервиса.

Примечание 1

Поведение ФБ, не находящихся под управлением управляющего ФБ, выходит за рамки данного стандарта.

Примечание 2

Спецификация поведения управляемых ФБ при потере и восстановлении питания выходит за рамки данного стандарта.

Примечание 3

Приложения могут использовать экземпляры блока E_RESTART (Приложение A) для генерации событий при потере и восстановлении питания.

Примечание 4

Управление выполнением в подприложениях (subapplications) полностью делегируется механизмам управления их компонентных ФБ и подприложений (5.4.2).

---

7 Конфигурация функциональных устройств и систем (Configuration)

7.1 Принципы конфигурации

Раздел 7 содержит правила конфигурации (configuration) промышленных систем измерения и управления процессами (IPMCS -- industrial-process measurement and control systems) в соответствии со следующей моделью:

a) IPMCS состоит из взаимосвязанных устройств (devices).

b) Устройство (device) является экземпляром (instance) соответствующего типа устройства (device type).

c) Функциональные возможности типа устройства описываются через связанные с ним ресурсы (resources).

d) Ресурс (resource) является экземпляром соответствующего типа ресурса (resource type).

e) Функциональные возможности типа ресурса описываются через типы функциональных блоков (function block types), которые могут быть инстанцированы, и конкретные экземпляры ФБ (function block instances), существующие во всех экземплярах данного типа ресурса.

Конфигурация IPMCS, таким образом, складывается из конфигурации связанных с ней устройств и приложений (applications), включая распределение экземпляров ФБ каждого приложения по ресурсам устройств. Раздел 7 определяет следующие наборы правил:

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

---

7.2 Функциональная спецификация типов ресурсов, устройств и сегментов

7.2.1 Функциональная спецификация типов ресурсов

Функциональная спецификация типа ресурса (resource type) включает:

• имя типа ресурса (type name);
• имя экземпляра (instance name), тип данных (data type) и инициализацию каждого из параметров (parameters) ресурса;
• объявление типов данных и типов функциональных блоков, которые каждый экземпляр данного типа ресурса способен инстанцировать;
• имена экземпляров, типы и начальные значения всех экземпляров ФБ, всегда присутствующих в каждом экземпляре данного типа ресурса;
• все соединения данных (data connections), адаптерные соединения (adapter connections) и соединения событий (event connections), всегда присутствующие в каждом экземпляре данного типа ресурса.

Примечание 1

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

Примечание 2

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

7.2.2 Функциональная спецификация типов устройств

Функциональная спецификация типа устройства (device type) включает:

a) имя типа устройства;

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

c) имя экземпляра, имя типа и инициализацию каждого экземпляра ФБ, всегда присутствующего в каждом экземпляре данного типа устройства;

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

e) объявления экземпляров ресурсов (resource instances), присутствующих в каждом экземпляре данного типа устройства. Каждое такое объявление содержит:

1. имя экземпляра ресурса и имя типа;
2. имя экземпляра, имя типа и инициализацию каждого экземпляра ФБ, всегда присутствующего в данном экземпляре ресурса в каждом экземпляре типа устройства;
3. все соединения данных, адаптерные соединения и соединения событий, всегда присутствующие в данном экземпляре ресурса в каждом экземпляре типа устройства.

Примечание 1

Пункты (2) и (3) дополняют соответствующие элементы, объявленные в спецификации типа ресурса (7.2.1).

Примечание 2

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

Примечание 3

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

7.2.3 Функциональная спецификация типов сегментов

Функциональная спецификация типа сегмента (segment type) включает:

• имя типа сегмента (type name);
• имя экземпляра, тип данных и инициализацию каждого из параметров (parameters) сегмента.

---

7.3 Требования к конфигурации

7.3.1 Конфигурация систем

Конфигурация системы (system) включает:

• имя (name) системы;
• спецификацию каждого приложения (application), как определено в 7.3.2;
• конфигурацию каждого устройства (device) и связанных с ним ресурсов, как определено в 7.3.3;
• конфигурацию каждого сетевого сегмента (network segment) и связанных с ним связей (links) к устройствам или ресурсам, как определено в 7.3.4.

7.3.2 Спецификация приложений

Спецификация приложения (application) включает:

• его имя в форме идентификатора (identifier);
• имя экземпляра (instance name), имя типа (type name), соединения данных (data connections), соединения событий (event connections) и адаптерные соединения (adapter connections) каждого функционального блока и подприложения (subapplication) в составе приложения.

Имя приложения должно быть уникальным в пределах системы (system); в противном случае -- ошибка.

7.3.3 Конфигурация устройств и ресурсов

Конфигурация устройства (device) включает:

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

note

Экземпляр устройства может содержать сеть ФБ только когда он рассматривается как состоящий из единственного (необъявленного) ресурса; в этом случае объявление экземпляра устройства не содержит объявлений экземпляров ресурсов.

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

Конфигурация ресурса (resource) включает:

a) имя экземпляра (instance name) и имя типа (type name) ресурса;

b) типы данных (data types) и типы функциональных блоков (function block types), поддерживаемые данным экземпляром ресурса;

c) имя экземпляра, имя типа и инициализацию каждого экземпляра ФБ, присутствующего в данном экземпляре ресурса;

d) все соединения данных (data connections), соединения событий (event connections) и адаптерные соединения (adapter connections), присутствующие в данном экземпляре ресурса.

Конфигурация ресурса подчиняется следующим правилам:

• Пункты b), c) и d) дополняют соответствующие элементы, объявленные в спецификациях типов устройства и ресурса (7.2.2, 7.2.1).
• Пункты c) и d) включают экземпляры ФБ, соединения данных, адаптерные соединения и соединения событий из тех частей приложений (applications), которые распределены на данный ресурс.
• Пункты c) и d) включают коммуникационные функциональные блоки (communication function blocks), соединения данных, соединения событий и адаптерные соединения, необходимые для установления и поддержания потоков данных и событий всех связанных приложений.
• Пункт c) может включать отображение (mapping) экземпляров ФБ приложения на экземпляры ФБ, существующие в ресурсе в силу определения типа (7.2.1).

Имя экземпляра ресурса должно быть уникальным в пределах содержащего его устройства, а каждый экземпляр ФБ приложения должен быть распределен ровно на один ресурс; в противном случае -- ошибка.

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

7.3.4 Конфигурация сетевых сегментов и связей

Конфигурация сетевого сегмента (network segment) включает:

• имя экземпляра (instance name) и имя типа (type name) сегмента;
• значения параметров (parameters), специфичные для данного сетевого сегмента.

Имя экземпляра каждого сетевого сегмента должно быть уникальным в пределах системы, а объявленные значения параметров сегмента должны быть совместимы с объявлением типа сегмента (7.2.3); в противном случае -- ошибка.

Конфигурация связи (link) включает:

• имя устройства или иерархическое имя «коммуникационного ресурса» (communication resource) внутри устройства, а также имя сетевого сегмента, к которому подключено данное устройство или ресурс;
• значения параметров, специфичные для данной связи.