4 Эталонные модели (Reference models)

4.1 Модель системы (System model)

Для целей IEC 61499 система измерения и управления промышленным процессом (IPMCS, Industrial Process Measurement and Control System) моделируется, как показано на рисунке 1, в виде набора устройств (devices), соединённых между собой и взаимодействующих посредством коммуникационной сети (communication network), состоящей из сегментов (segments) и линий связи (links). Устройства подключаются к сегментам сети через линии связи.

note

Управляемый процесс (controlled process) не является частью системы измерения и управления.

Рисунок 1 -- Модель системы

Функция (function), выполняемая IPMCS, моделируется как приложение (application), которое может размещаться на одном устройстве, например приложение C на рисунке 1, или может быть распределено между несколькими устройствами, как приложения A и B на рисунке 1. Например, приложение может состоять из одного или нескольких контуров управления, в которых опрос входных сигналов выполняется на одном устройстве, обработка алгоритма управления -- на другом, а формирование выходных сигналов -- на третьем.

4.2 Модель устройства (Device model)

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

Примечание 1

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

Примечание 2

Устройство, не содержащее ресурсов, функционально эквивалентно ресурсу, как определено в пункте 4.3.

Интерфейс процесса (process interface) обеспечивает отображение (mapping) между физическим процессом (аналоговые измерения, дискретный ввод-вывод и т. д.) и ресурсами. Информация, получаемая от физического процесса, представляется ресурсу в виде данных (data) или событий (events), или того и другого.

Коммуникационные интерфейсы (communication interfaces) обеспечивают отображение между ресурсами и информацией, передаваемой по коммуникационной сети. Услуги, предоставляемые коммуникационными интерфейсами, могут включать:

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

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

note

Данный рисунок показывает возможную внутреннюю структуру устройства 2 (Device 2) с рисунка 1.

Рисунок 2 -- Модель устройства

4.3 Модель ресурса (Resource model)

Для целей IEC 61499 ресурс (resource) рассматривается как функциональный модуль (functional unit), который обладает независимым управлением своей работой и содержится в устройстве. Он может быть создан, сконфигурирован, параметрирован, запущен, удалён и т. д. без влияния на другие ресурсы.

Примечание 1

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

Примечание 2

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

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

Примечание 3

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

Примечание 4

Рассмотрение иных возможных аспектов ресурсов выходит за рамки настоящего стандарта.

Как показано на рисунке 3, ресурс моделируется следующими составляющими:

• Одно или несколько «локальных приложений» (или локальных частей распределённых приложений). Переменные (variables) и события, обрабатываемые в этой части, являются входными и выходными переменными и событиями на входах событий (event inputs) и выходах событий (event outputs) функциональных блоков (function blocks), выполняющих операции (operations), необходимые приложению.

• Часть «отображения процесса» (process mapping), функция которой состоит в выполнении отображения данных и событий между приложениями и интерфейсами процесса. Как показано на рисунке 3, это отображение может моделироваться функциональными блоками сервисного интерфейса (service interface function blocks), специализированными для данной цели.

• Часть «коммуникационного отображения» (communication mapping), функция которой состоит в выполнении отображения данных и событий между приложениями и коммуникационными интерфейсами. Как показано на рисунке 3, это отображение может моделироваться функциональными блоками сервисного интерфейса, специализированными для данной цели.

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

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

Примечание 1

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

Примечание 2

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

Рисунок 3 -- Модель ресурса

4.4 Модель приложения (Application model)

Для целей настоящего документа приложение (application) состоит из сети функциональных блоков (function block network), узлами которой являются функциональные блоки или подприложения (subapplications) и их параметры (parameters), а ветвями -- соединения данных (data connections) и соединения событий (event connections).

Подприложения являются экземплярами (instances) типов подприложений (subapplication types), которые, подобно приложениям, состоят из сетей функциональных блоков. Имена приложений, подприложений и имена экземпляров функциональных блоков (instance names) могут использоваться для создания иерархии идентификаторов (identifiers), позволяющей однозначно идентифицировать каждый экземпляр функционального блока в системе.

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

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

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

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

Примечание 1

Символ «*» обозначает экземпляры функциональных блоков или подприложений.

Примечание 2

Данный рисунок носит иллюстративный характер. Графическое представление не является нормативным.

Рисунок 4 -- Модель приложения

4.5 Модель функционального блока (Function block model)

4.5.1 Характеристики экземпляров функциональных блоков (Characteristics of function block instances)

Функциональный блок (function block instance) -- это функциональный модуль программного обеспечения (software), представляющий собой индивидуальную именованную копию структуры данных, определённой типом функционального блока (function block type), которая сохраняется от одного вызова (invocation) функционального блока до следующего. Характеристики экземпляров функциональных блоков описаны в пункте 4.5.1, а спецификации типов функциональных блоков -- в пункте 4.5.2.

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

• имя типа (type name) и имя экземпляра (instance name);
• набор входов событий (event inputs), каждый из которых может принимать события от соединения событий и влиять на выполнение одного или нескольких алгоритмов;
• набор выходов событий (event outputs), каждый из которых может передавать события в соединение событий в зависимости от выполнения алгоритмов или иной функциональной возможности ресурса, в котором размещён функциональный блок;
• набор входов данных (data inputs), которые могут отображаться на соответствующие входные переменные (input variables);
• набор выходов данных (data outputs), которые могут отображаться на соответствующие выходные переменные (output variables);
• внутренние данные (internal data), которые могут отображаться на набор внутренних переменных (internal variables);
• функциональные характеристики, определяемые комбинацией внутренних данных или информации о состоянии, или того и другого, с набором алгоритмов, функциональными возможностями ассоциированного ресурса, или тем и другим. Эти функциональные характеристики задаются в спецификации типа функционального блока.

note

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

note

Данный рисунок носит иллюстративный характер. Графическое представление не является нормативным.

Рисунок 5 -- Характеристики функциональных блоков

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

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

Средства для задания причинно-следственных связей между входами событий, выходами событий и выполнением алгоритмов определены в разделах 5 и 6.

4.5.2 Спецификации типов функциональных блоков (Function block type specifications)

Тип функционального блока (function block type) -- это программный элемент, задающий характеристики всех экземпляров данного типа, включая:

• имя типа;
• количество, имена, имена типов и порядок входов и выходов событий;
• количество, имена, типы данных (data types) и порядок входных, выходных и внутренних переменных.

Механизмы объявления (declaration) этих характеристик определены в пункте 5.2.1.

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

• Для базовых типов функциональных блоков (basic function block types) в пункте 5.2.1.3 предусмотрены механизмы объявления алгоритмов, которые оперируют значениями входных, выходных и внутренних переменных для получения новых значений выходных и внутренних переменных. Связи между вызовом алгоритмов и возникновением событий на входах и выходах событий выражаются в виде диаграммы управления выполнением (Execution Control Chart, ECC) с использованием механизмов объявления, определённых в пункте 5.2.1.4.

• Функциональность экземпляра составного типа функционального блока (composite function block type) или типа подприложения (subapplication type) объявляется с использованием механизмов, определённых в пунктах 5.3.1 и 5.4.1 соответственно, в виде соединений данных и соединений событий между составными функциональными блоками (component function blocks) или подприложениями и входами/выходами событий и данных составного функционального блока или подприложения.

• Функциональность экземпляра типа функционального блока сервисного интерфейса (service interface function block type) описывается отображением (mapping) сервисных примитивов (service primitives) на входы событий, выходы событий, входы данных и выходы данных с использованием механизмов объявления, определённых в пункте 6.1.

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

4.5.3 Модель выполнения для базовых функциональных блоков (Execution model for basic function blocks)

Как показано на рисунке 6, выполнение алгоритмов для базовых функциональных блоков (basic function blocks) инициируется частью управления выполнением (execution control) экземпляра функционального блока в ответ на события на входах событий. Этот вызов (invocation) принимает форму запроса к функции планирования (scheduling function) ассоциированного ресурса на планирование выполнения операций алгоритма. По завершении выполнения алгоритма управление выполнением генерирует ноль или более событий на выходах событий.

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

Примечание 1

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

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

• t₁: значения соответствующих входных переменных (т. е. связанных с входом событий квалификатором WITH, определённым в 5.2.1.2) становятся доступными;
• t₂: происходит событие на входе событий;
• t₃: функция управления выполнением уведомляет функцию планирования ресурса о необходимости поставить алгоритм в очередь на выполнение;
• t₄: начинается выполнение алгоритма;
• t₅: алгоритм завершает установку значений выходных переменных, связанных с выходом событий квалификатором WITH (определённым в 5.2.1.2);
• t₆: функция планирования ресурса получает уведомление о завершении выполнения алгоритма;
• t₇: функция планирования вызывает функцию управления выполнением;
• t₈: функция управления выполнением сигнализирует о событии на выходе событий.

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

T_setup = t₂ - t₁

T_start = t₄ - t₂ (время от события на входе до начала выполнения алгоритма)

T_alg = t₆ - t₄ (время выполнения алгоритма)

T_finish = t₈ - t₆ (время от завершения выполнения алгоритма до события на выходе)

note

Данный рисунок носит иллюстративный характер. Графическое представление не является нормативным.

Рисунок 6 -- Модель выполнения

note

Метки на оси 1, 2, ... на приведённом выше рисунке соответствуют моментам времени t₁, t₂, ... на рисунке 6.

Рисунок 7 -- Временная диаграмма выполнения

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

Примечание 2

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

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

Примечание 3

Ресурсам может потребоваться планировать выполнение алгоритмов в режиме многозадачности (multitasking). Спецификация атрибутов для поддержки такого планирования описана в Приложении G.

4.6 Модель распределения (Distribution model)

Как показано на рисунке 8a, приложение или подприложение может быть распределено путём размещения его экземпляров функциональных блоков (function block instances) в различных ресурсах на одном или нескольких устройствах. Поскольку внутренние детали функционального блока скрыты от любого приложения или подприложения, использующего его, функциональный блок является атомарной единицей распределения. Это означает, что все элементы, содержащиеся в данном экземпляре функционального блока, должны размещаться в одном ресурсе.

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

При распределении приложений или подприложений между несколькими ресурсами применяются следующие положения:

• Раздел 6 определяет требования к коммуникационным сервисам для поддержки распределения приложений или подприложений между несколькими устройствами;
• Раздел 7 определяет требования для случая, когда множественные приложения или подприложения распределены между несколькими ресурсами и устройствами.

Рисунок 8a -- Модель распределения

4.7 Модель управления (Management model)

На рисунках 8b и 8c представлено схематическое изображение управления ресурсами и устройствами. На рисунке 8b показан случай, в котором управляющий ресурс (management resource) предоставляет общие средства для управления другими ресурсами в пределах устройства; на рисунке 8c показано распределение сервисов управления между ресурсами внутри устройства. Приложения управления (management applications) могут моделироваться с использованием зависящих от реализации (implementation-dependent) функциональных блоков сервисного интерфейса и коммуникационных функциональных блоков (communication function blocks).

Примечание 1

Пункт 6.3 определяет типы функциональных блоков сервисного интерфейса для управления приложениями, а IEC 61499-2 предоставляет примеры их использования.

Примечание 2

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

Рисунок 8b -- Модель общего управления

Рисунок 8c -- Модель распределённого управления

Рисунок 8 -- Модели распределения и управления

4.8 Модель рабочих состояний (Operational state models)

Любая система (system) должна быть спроектирована, введена в эксплуатацию, эксплуатироваться и обслуживаться. Это моделируется через концепцию «жизненного цикла» (life cycle) системы. В свою очередь, система состоит из нескольких функциональных модулей, таких как устройства, ресурсы и приложения, каждый из которых имеет свой собственный жизненный цикл.

На различных этапах жизненного цикла могут потребоваться различные действия для поддержки функциональных модулей. Для характеристики того, какие действия могут быть выполнены и для обеспечения целостности функциональных модулей, должны быть определены «рабочие состояния» (operational states), например OPERATIONAL, CONFIGURABLE, LOADED, STOPPED и т. д.

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

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

Примеры использования рабочих состояний:

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

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

note

Данный рисунок носит иллюстративный характер. Графическое представление не является нормативным.

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