«МОДЕЛИ, МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ РАСПРЕДЕЛЕННЫХ КОМПОНЕНТНО-БАЗИРОВАННЫХ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ ПРОМЫШЛЕННОЙ АВТОМАТИКИ ...»
ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
На правах рукописи
ДУБИНИН Виктор Николаевич
МОДЕЛИ, МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ
РАСПРЕДЕЛЕННЫХ КОМПОНЕНТНО-БАЗИРОВАННЫХ
ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ
ПРОМЫШЛЕННОЙ АВТОМАТИКИ
Специальность: 05.13.17 - Теоретические основы информатики 05.13.05 – Элементы и устройства вычислительной техники и систем управления Диссертация на соискание ученой степени доктора технических наук
Научный консультант:
доктор технических наук, профессор Вашкевич Николай Петрович Пенза
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ …………………………..………………………………………………..…………..…1. ОБЗОР И АНАЛИЗ МЕТОДОВ ПРОЕКТИРОВАНИЯ РАСПРЕДЕЛЕННЫХ
ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ ПРОМЫШЛЕННОЙ
АВТОМАТИКИ ………………………………………………………………………………….….. 1.1. Архитектурные особенности и тенденции развития современных систем промышленной автоматики …………………………………………...…………………..……… 1.1.1. Архитектура распределенных систем промышленной автоматики ……...………….... 1.1.2. Распределенные системы управления нового поколения на основе стандарта IEC 61499 …………………………………………...…………………...….…...…… 1.1.3. Обзор стандарта IEC 61499 …………………………...………………...……………….. 1.1.4. Модели выполнения функциональных блоков1.2. Обзор и анализ методов проектирования традиционных информационноуправляющих систем промышленной автоматики ………………………………………...…… 1.3. Обзор и анализ моделей и методов проектирования распределенных систем управления на основе стандарта IEC 61499 …………………………………..………………… 1.3.1. Обзор работ по формальным моделям функциональных блоков …………..……….... 1.3.2. Проблема определения формальной семантики функциональных блоков ……………………………………………………………..………… 1.3.3. Проблема анализа и верификации проектов IEC 61499 ……………………..……….... 1.3.4. Объектно-ориентированное проектирование ………………………………..…………. 1.3.5. Подход на основе управления моделями ……………………………………..…...……. 1.3.6. Описание, анализ и проектирование систем с использованием онтологий ……..….... 1.4. Элементы методологии проектирования распределенных компонентнобазированных информационно-управляющих систем промышленной автоматики на основе стандарта IEC 61499 ………………………………………………..…………………. 1.4.1. Функциональная модель методологии …………………………………..……….…….. 1.4.2. UML-FB - визуальный язык для моделирования систем управления промышленными процессами на основе стандарта IEC 61499 ………………………..…….. 1.4.3. Сетевой формализм для разработки имитационных моделей …………………..….…. 1.4.4. Иерархические модульные недетерминированные автоматы для аппаратной реализации локальных систем управления ……………………………………………..……... 1.4.5. Функционально-блочная реализация механизмов и средств синхронизации и взаимодействий процессов в архитектуре IEC 61499 ……………………………..………….. 1.5. Выводы ………………………………………………………………………...……..………..
2. ОПЕРАЦИОННАЯ СЕМАНТИКА ФУНКЦИОНАЛЬНЫХ БЛОКОВ
СТАНДАРТА IEC 61499 ……………………………………………………………………..…….. 2.1. Системная конфигурация ………………………………………………………..………..…. 2.2. Развертывание системной конфигурации ………………………………………..…………. 2.3. Буферирование данных ……………………………………………………………...……… 2.4. Переход от иерархических структур систем функциональных блоков к одноуровневым структурам …………………………………………..………………………… 2.5. Модульная формальная модель операционной семантики функциональных блоков …. 2.6. Функционально-структурная организация моделей систем функциональных блоков …. 2.7. Базовая модель базисного функционального блока …………………………………..….. 2.7.1. Преобразование алгоритмов базисных функциональных блоков ……………….….. 2.7.2. Определение схемы модели ……………………………………………………………. 2.7.3. Определение динамики модели ………………………………………...……………… 2.8. Модель составного функционального блока для циклической модели выполнения …... 2.8.1. Определение схемы модели ……………………………………………...…………….. 2.8.2. Определение динамики модели ……………………………………………….……….. 2.9. Модель диспетчера для циклической модели выполнения ……………………………… 2.10. Взаимосвязь модулей функциональных блоков ………………………………..……….. 2.11. Модель составного функционального блока для синхронной модели выполнения ….. 2.11.1. Определение схемы модели ……………………………………………..……………. 2.11.2. Определение динамики модели ………………………………………………………. 2.12. Модель диспетчера для синхронной модели выполнения ……………...………………. 2.13. Семантика модели выполнения, основанной на последовательной гипотезе ………… 2.14. Формальная модель системы функциональных блоков в виде системы переходов состояний ……………………………………………………………………………………...…. 2.15. Выводы ……………………………………………………………………..……………….3. СИНТЕЗ ФОРМАЛЬНЫХ МОДЕЛЕЙ СИСТЕМ ФУНКЦИОНАЛЬНЫХ БЛОКОВ
НА ОСНОВЕ ГРАФОТРАНСФОРМАЦИОННОГО ПОДХОДА …………………………...…. 3.1. Краткие сведения из области трансформации графов ……………………………….…… 3.2. Поток моделей в процессе синтеза …………………………………………...……………. 3.3. Моделирование систем функциональных блоков на основе арифметических NCES-сетей …………………………………………………...………………. 3.3.1. Формализм арифметических NCES-сетей …………………………………………….. 3.3.2. Методика моделирования систем функциональных блоков ……………………..….. 3.4. Метамодель систем функциональных блоков ……………………………………………. 3.5. Метамодель арифметических NCES-сетей …………………………...…………………… 3.6. Правила перехода от многоуровневой структуры систем функциональных блоков к одноуровневой структуре …………………………………………………….……………….. 3.7. Правила синтеза многоуровневых aNCES-сетей на основе одноуровневых систем функциональных блоков ………………………………………………………….…………….. 3.8. Пример. Синтез сетевой модели для функционального блока “RS-триггер” ……..….…. 3.9. Реализация системы синтеза формальных моделей функциональных блоков …….…… 3.10. Выводы ………………………………………………………….……………………….….4. ВЕРИФИКАЦИЯ РАСПРЕДЕЛЕННЫХ КОМПОНЕНТНО-БАЗИРОВАННЫХ
ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ ПРОМЫШЛЕННОЙ
АВТОМАТИКИ ……………………………………………………………………………………. 4.1. Проверка моделей систем функциональных блоков ………………….………………….. 4.1.1. Проверка моделей систем функциональных блоков, представленных в виде машин абстрактных состояний ……………………………………………..…………………………. 4.1.2. Проверка моделей систем функциональных блоков, представленных в виде системы переходов состояний ………...……………………………………………………… 4.2. Проверка моделей дискретных событийных систем, представленных в виде NCES-сетей …………………………………………………….…………………………. 4.2.1. Формализм асинхронной модели NCES-сетей ……………………………….……….. 4.2.2. Подход к моделированию NCES-сетей с использованием А-модели …………….…. 4.2.3. Правила преобразования NCES в А-модель ……………………………….……….….. 4.2.4. Валидация метода асинхронного моделирования NCES-сетей ……………...………. 4.2.5. Методика кодировки А-модели на входном языке верификатора SMV ……………... 4.2.6. Демонстрационные примеры ……………………………………..……………………. 4.3. Семантический анализ проектов IEC 61499 на основе Web-онтологий ………………… 4.3.1. Онтология функциональных блоков ……………………………………………….….. 4.3.2. Свойства, связанные с семантической корректностью описаний ………………..….. 4.3.3. Зависимости алгоритмов по данным и управлению в системах функциональных блоков ……………………………………………………………………...…………………… 4.3.4. Обнаружение циклов с использованием событийных графов ……………..………… 4.3.5.Система семантического анализа проектов IEC 61499 ………………..……………… 4.4. Выводы …………………………………………………………………………...…………..5. РЕФАКТОРИНГ И РЕШЕНИЕ ПРОБЛЕМЫ ПОРТАБЕЛЬНОСТИ СИСТЕМ
ФУНКЦИОНАЛЬНЫХ БЛОКОВ ………………………………………………..………………. 5.1. Рефакторинг диаграмм управления выполнением базисных функциональных блоков …………………………………………………………………………………………….. 5.1.1. Модель диаграммы ЕСС ………………………………………………………………... 5.1.2. Модели выполнения диаграмм ЕСС …………………………………………………... 5.1.3. Общий подход к рефакторингу и исправлению диаграмм ЕСС ……………..……… 5.1.4. Рефакторинг на основе графотрансформационного подхода …………….………..… 5.1.5. Примеры рефакторинга диаграмм ЕСС ……………………………….…………….… 5.1.6. Реализация рефакторинга в системе AGG ………………………….…………….…… 5.1.7. Оценка системы рефакторинга ………………………………………………………… 5.2. Шаблоны модельно-ориентированной реализации систем функциональных блоков стандарта IEC 61499 …………………………………………………………………………...… 5.2.1. Общее описание схемы трансформации …………………………………………….… 5.2.2. Трансформация базисных функциональных блоков ………………………….……… 5.2.3. Буферирование сигналов ………………………………………….……………….…… 5.2.4. Трансформация составных функциональных блоков ………………………………… 5.2.5. Шаблон “Циклическая модель выполнения” …………………………………….…… 5.2.6. Шаблон “Синхронная модель выполнения” ………………………….……………..… 5.2.7. Примеры применения шаблонов …………………………………………………….… 5.2.8. Оценка сложности ……………………………………………………………………… 5.3. Выводы ………………………………………………………………………………………6. РЕВЕРСИВНЫЕ sNCES-СЕТИ ДЛЯ СИНТЕЗА КОНТРОЛЛЕРОВ БЕЗОПАСНОСТИ
РАСПРЕДЕЛЕННЫХ СИСТЕМ УПРАВЛЕНИЯ ……………………………………………… 6.1. Основные понятия и определения реверсивных sNCES-сетей ………………..………… 6.2. Интерпретация реверсивных sNCES-сетей ………………………………………….…… 6.2.1. Вычисление минимального покрывающего множества маркировок …….………… 6.2.2. Вычисление допустимых шагов для триггерного перехода ………………………… 6.2.3. Вычисление минимальных запрещающих контекстных маркировок ……………… 6.2.4. Алгоритм построения графа обратной достижимости …………………….………… 6.3. Использование реверсивных sNCES-сетей в синтезе контроллеров безопасности для дискретных событийных систем …………………………………………….………………..… 6.3.1. Концепция подхода …………………………………………………….……………..… 6.3.2. Расширенные sNCES-сети для предотвращения переходов в запрещенные маркировки …………………………………………………………………………………..… 6.3.3. Разработка запрещающих продукционных правил ……………………………...…… 6.3.4. Пример. Система двух выталкивателей ………………………….……………….…… 6.3.5. Вопросы реализации супервизорного управления …………………………………… 6.4. Выводы …………………………………………………………………………………….… ЗАКЛЮЧЕНИЕ ………………………………………………………………………..……… СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ …………………………… СПИСОК ЛИТЕРАТУРЫ ……………………………………………………….……….…… ПРИЛОЖЕНИЯ ……………………………………………………………………….…………… Приложение А. Краткое описание языка UML-FB …………………………………….……… Приложение Б. Методика моделирования недетерминированных автоматов с использованием модульных NCES-сетей ……………………………………………..……… Приложение В. Методика моделирования недетерминированных автоматов с использованием диаграмм Ладдера ………………………………………………………...… Приложение Г. Операционная семантика функциональных блоков, функционирующих в соответствии с моделью выполнения на основе последовательной гипотезы …….……… Приложение Д. Демонстрационный пример проверки моделей системы функциональных блоков ……………………………………………………………………...… Приложение Е. Документы, подтверждающие внедрение и использование результатов диссертационной работы…………………………………………………………………………ВВЕДЕНИЕ
Современной тенденцией развития предприятий в настоящее время является их комплексная автоматизация. Предприятие рассматривается как единый объект автоматизации.
Верхние уровни интегрированной информационной системы управления предприятием представляют собой программные системы, технология разработки которых достаточно хорошо развита. Узким местом, требующим самого пристального внимания, в настоящее время являются нижние уровни (уровни программируемых логических контроллеров (ПЛК) и вводавывода). Назовем системы, охватывающие эти уровни, информационно-управляющими системами промышленной автоматики (ИУСПА). Современные ИУСПА (как правило, построенные на основе международного стандарта IEC 61131-3) являются централизованными системами с присущими им недостатками. К ним можно отнести низкую надежность и производительность, сложность настройки и поддержки, сложность модификаций (наращивания, удаления и изменения компонентов) и построения реконфигурируемых систем, проблемы с масштабируемостью, повторным использованием компонентов, а также дороговизной как самого процесса проектирования, так и всей (реальной) системы. В то же время все более жесткие условия, в которые рынок промышленных товаров ставит производителей, подталкивает их к переходу на новый технологический базис, позволяющий существенно сократить время проектирования и перепроектирования систем управления и иметь возможность их быстрой реконфигурации.
Принятый в 2005 г. новый международный стандарт IEC 61499, нацеленный на построение распределенных систем управления промышленными процессами, призван решить вызовы времени. По сути дела, стандарт IEC 61499 вводит класс систем управления нового поколения.
Это интеллектуальные реконфигурируемые распределенные компонентно-базированные системы. Работы в области функциональных блоков (ФБ) IEC 61499 интенсивно ведутся во всем мире. Большой вклад в разработку методов проектирования систем на основе стандарта IEC 61499 внесли Christensen J., Vyatkin V., Snder Ch., Zoitl А, Strasser T., Thramboulidis K., Hanisch H.-M., Ferrarini L., Veber C., Valentini А., Frey G., Martinez-Lastra J.L., Lueder А, Colla M., Brennan R., Cengic G. и др. Однако многие проблемы, связанные со стандартом, остались нерешенными. Например, до сих пор не разработана семантика ФБ и методы обеспечения портабельности управляющего программного обеспечения (ПО) на основе IEC 61499, отсутствует целостный подход к проектированию ИУСПА на основе IEC 61499. Существующие проекты нацелены на решение узкого круга задач, как правило, реализационного плана. В РФ и странах СНГ работы в области ФБ стандарта IEC 61499 практически отсутствуют.
Теоретической и методологической основой проектирования ИУСПА является научное направление, связанное с системами логического управления дискретными процессами, которое во многом базируется на теории конечных автоматов и сетей Петри. В данном направлении исследователями (среди которых отечественные ученые Амбарцумян А.А., Бандман О. Л., Варшавский В.И., Вашкевич Н.П., Гаврилов М.А., Горбатов В.А., Закревский А.Д., Зюбин В. Е., Кузнецов О.П., Лазарев В. Г., Шалыто А.А., Юдицкий С.А.) были получены существенные результаты. Приложения современной автоматизации, как правило, являются ответственными, поэтому они должны быть надежными и робастными. Ключевой теорией для проектирования надежных и робастных систем в рамках логического управления является теория супервизорного управления, развиваемая в основном зарубежными учеными Ramadge P.J., Wonham W.M., Giua А., Hanisch H.-M., Barbeau M. и др.
Современные ИУСПА в ближайшем будущем будут представлять собой распределенные системы, состоящие из множества контроллеров и промышленных компьютеров, взаимодействующих между собой и с окружающей средой через коммуникационные сети, со значительной долей вычислений и обработки данных, имеющих как программную, так и аппаратную реализационные части. Из этого вытекает междисциплинарный характер исследуемой области и тренд систем рассматриваемого класса к так называемым кибер-физическим системам.
Таким образом, актуальность научных исследований в области разработки методов и средств проектирования ИУСПА главным образом определяется появлением систем нового класса, обладающих существенно иными свойствами по сравнению с имеющимися, отсутствием комплексного подхода к их проектированию, невозможностью напрямую использовать существующие наработки.
Цели и задачи исследования. Целью работы является теоретическое обоснование и разработка методов и средств проектирования ответственных распределенных компонентнобазированных информационно-управляющих систем промышленной автоматики (РКБИУСПА).
Для достижения поставленной цели необходимо решить следующие основные задачи:
1) разработать методологию проектирования РКБИУСПА, определяющую этапы, модели, методы и средства проектирования, а также их взаимосвязь;
2) создать профайл UML для моделирования систем управления промышленными процессами на основе стандарта IEC 61499;
3) определить операционную семантику функциональных блоков (ФБ) стандарта IEC 61499, являющихся основными артефактами при построении интеллектуальных систем управления нового поколения, и необходимую при проектировании РКБИУСПА на основе ФБ;
4) формализовать и автоматизировать процесс построения формальных моделей систем ФБ, решив при этом задачу выбора средств описания как самих систем ФБ, так и процесса порождения моделей;
5) разработать методику верификации РКБИУСПА, позволяющую на основе анализа получить подтверждение выполнения определенных свойств, заданных в спецификациях системы;
6) разработать метод семантического анализа РКБИУСПА на основе технологий семантического Web для нахождения ошибок на ранних этапах проектирования;
7) разработать метод рефакторинга управляющих приложений IEC 61499, допускающий их эквивалентные преобразования для различных целей;
8) предложить метод синтеза моделей контроллеров безопасности для дискретных событийных систем, обеспечивающий существенное повышение надежности и робастности РКБИУСПА;
9) разработать средства обеспечения портабельности управляющих приложений IEC 61499 между различными платформами;
10) развить автоматный подход к описанию, проектированию и реализации локальных систем управления на основе недетерминированных автоматов.
Объектом исследования являются распределенные компонентно-базированные управляющие вычислительные системы промышленной автоматики (РКБИУСПА), построенные на основе новых международных стандартов.
Предметом исследования являются методы и средства проектирования ответственных РКБИУСПА, используемые на этапах формализованного описания, верификации, информационного и имитационного моделирования, реализации, рефакторинга и синтеза, а также методы организации программного кода для решения задач портабельности и реализации сложных взаимодействий.
Методы исследования. Для решения поставленных задач использовались методы теории множеств, сетей Петри, сетевых систем “условие-событие” (NCES-сетей), конечных автоматов, систем переходов состояний и машин абстрактных состояний, теории супервизорного управления, теории графов и графовых грамматик, математическая логика, методы искусственного интеллекта, методы верификации программно-аппаратных систем, методы объектноориентированного проектирования и технологии семантического Web.
Научная новизна Научная новизна диссертации определяется следующими результатами.
1. Разработана модельно-центрированная методология проектирования РКБИУСПА на основе международного стандарта IEC 61499, охватывающая фазы формализованного описания, верификации, оценки производительности, рефакторинга, генерации тестов, генерации кода, синтеза контроллеров безопасности, отличающая от известных использованием комплекса взаимосвязанных моделей и их трансформаций, позволяющая: а) строить РКБИУСПА, отвечающие функциональным и нефункциональным требованиям, на различных платформах; б) повысить качество проектных решений за счет автоматизации процесса проектирования, увеличения степени повторного использования разработанных артефактов проектирования.
2. Формально определена операционная семантика систем ФБ IEC 61499, отличающаяся учетом моделей их выполнения (циклической, синхронной и последовательной), универсальностью применяемого формального аппарата, гибкостью и ориентацией на реализацию, что позволяет, во-первых, избавиться от неопределенности описаний систем ФБ, допускаемых стандартом, во-вторых, производить адекватную формализацию систем управления на основе ФБ, в-третьих, осуществлять корректную реализацию систем моделирования и сред выполнения ФБ.
3. Построена система трансформации графов, определяющая процесс построения aNCESмоделей систем ФБ, отличающаяся от других подходов к описанию построения моделей формальностью, структурностью, наглядностью, простотой реализации, что позволяет избежать ошибок проектирования и автоматизировать трудно формализуемый этап разработки формальных моделей.
4. Предложена методика верификации дискретных событийных систем, представленных в виде NCES-сетей, на основе метода Model Checking, отличающаяся от известных использованием промежуточной А-модели для построения структуры Крипке, что позволяет в дальнейшем упростить использование современных промышленных верификаторов для проверки моделей.
5. Разработан метод семантического анализа описаний систем управления на основе стандарта IEC 61499 с использованием Web-онтологий, отличающийся от известных методов семантического анализа формальностью (основа – дескриптивная логика и логика хорновских дизъюнктов), ясностью, разрешимостью, гибкостью и расширяемостью, что позволяет избежать ошибок при разработке систем семантического анализа, уменьшить затраты на их разработку, модификацию и сопровождение, увеличить степень повторного использования проектных решений.
6. Разработан метод рефакторинга диаграмм управления выполнением (диаграмм ЕСС) базисного ФБ на основе трансформаций графов, отличающийся: а) целью - избавлением от условных дуг и потенциально-тупиковых (по условиям) состояний; б) формальным аппаратом – графовыми грамматиками, что позволяет: а) избавиться от ошибок на стадии исполнения управляющих приложений; б) избежать ошибок проектирования, уменьшить затраты на разработку, модификацию и сопровождение инструментальных средств рефакторинга.
7. Усовершенствован метод синтеза моделей контроллеров безопасности распределенных систем управления на основе sNCES-сетей, предложенный Ханишем Х.-М., в направлении его применимости. В отличие от базового метода в предложенном методе используются реверсивные частично-маркированные sNCES-сети (RsNCES-сетей), основанные на обратных срабатываниях шагов, и методы их интерпретации, что позволяет формально описать обратный поиск в пространстве состояний и генерировать запрещающие правила для предотвращения попадания системы в опасные состояния для замкнутых систем «управление-оборудование».
8. Предложены шаблоны модельно-ориентированной реализации систем функциональных блоков (ШМОРСФБ), отличающиеся введением в систему служебных ФБ, изменяющих порядок выполнения ФБ и способы межблочной передачи информации, что позволяет решить проблемы портабельности управляющих приложений на основе стандарта IEC 61499 путем обеспечения робастности (нечувствительности) ФБ к изменениям семантики выполнения.
9. Развита концепция недетерминированных автоматов (НДА) Вашкевича Н.П. и разработана формальная модель иерархических модульных недетерминированных автоматов (ИМНДА) для проектирования локальных систем управления, отличающаяся от базовой концепции НДА возможностью иерархической структуризации модели и учетом импульсных сигналов, что позволяет использовать структурный подход к проектированию, увеличивает описательную мощность автоматной модели и расширяет сферу применения автоматного подхода к проектированию дискретных событийных систем.
Практическая ценность работы связана с разработкой лингвистического, методического, алгоритмического и информационного обеспечения методологии проектирования РКБИУСПА, а также инструментальных средств поддержки этой методологии. Основные результаты в этом направлении представлены ниже.
1. Разработан язык UML-FB, основанный на расширении метамодели языка UML, а также программные средства поддержки, для моделирования систем управления промышленными процессами на основе стандарта IEC 61499, что позволяет использовать объектноориентированный подход в структурном проектировании систем управления данного класса.
2. Предложена функционально-блочная реализация ряда механизмов и средств синхронизации и взаимодействий, используемых в параллельном и распределенном программировании, в числе которых семафоры, задача синхронизации «производитель-потребитель», разделяемые данные, что позволяет на практике использовать разработанные библиотеки ФБ для построения распределенных систем со сложными видами взаимодействий.
3. С использованием языка UML-FB и программных конверторов разработана визуальная интерактивная имитационная модель производственной установки FESTO на основе функциональных блоков IEC 61499, в которой реализованы семафоры и задача синхронизации «производитель-потребитель». Данная имитационная модель использовалась как иллюстративный пример использования ряда предложенных в диссертации методов.
4. Предложена методика кодирования систем ФБ на языке SMV. Для поддержки предложенной методики разработан транслятор XML-описания ФБ IEC 61499 в код SMV, позволяющий автоматизировать процесс построения входных данных для промышленного верификатора.
5. Разработана система реструктуризации и преобразований функциональных блоков, позволяющая легко строить проблемно-ориентированные системы трансформации ФБ путем разработки на высокоуровневом визуальном языке в системе AGG специализированного набора правил графовых трансформаций (например, для рефакторинга или синтеза aNCES-моделей).
6. В рамках предложенной методики верификации дискретных событийных систем, представленных в виде NCES-сетей, на основе метода Model Checking, разработаны конвертор многоуровневых модульных NCES-сетей в одноуровневые NCES-сети и транслятор XML-описания NCES-сетей в код SMV.
7. Разработаны средства онтологического описания и анализа систем ФБ стандарта IEC 61499, в частности: а) Web-онтология стандарта IEC 61499. Данная онтология может считаться разделяемым ресурсом и быть размещена в сети Интернет для общего пользования; б) программная система семантического анализа проектов IEC 61499 на основе Web-онтологий.
8. Разработаны алгоритм системного порождения маркировок, которые необходимо изменить для предотвращения перехода в опасное состояние, а также процедура генерации для них запрещающих продукционных правил. Данный алгоритм реализован программно и может быть использован в синтезе контроллеров безопасности для дискретных событийных систем.
9. Разработаны следующие ШМОРСФБ: «Циклическая модель», «Синхронная модель», «Последовательная модель». Данные шаблоны могут быть использованы для переноса существующих приложений IEC 61499 на платформы с различными моделями выполнения ФБ.
10. Разработаны программные средства поддержки проектирования локальных управляющих систем на основе ИМНДА, включая этапы спецификации, верификации и реализации на языках ПЛК и VHDL.
1. Модельно-центрированная методология проектирования РКБИУСПА на основе международного стандарта IEC 61499, охватывающая этапы от формализованного описания до реализации, позволяющая: а) строить системы, отвечающие функциональным и нефункциональным требованиям; б) повысить качество проектных решений за счет автоматизации и увеличить степень повторного использования артефактов проектирования.
2. Абстрактный синтаксис и операционная семантика систем ФБ IEC 61499 с учетом моделей выполнения ФБ (циклической, синхронной и последовательной) на основе специальной нотации, базирующейся на аппарате машин абстрактных состояний, что позволяет формально определить язык ФБ, используемый во многих фазах проектирования РКБИУСПА;
3. Система трансформации графов, определяющая процесс порождения aNCES-моделей систем ФБ, позволяющая автоматизировать трудно формализуемый этап разработки формальных моделей.
4. Методика верификации дискретных событийных систем, представленных в виде NCESсетей, на основе метода Model Checking, позволяющая производить сертификацию РКБИУСПА с использованием современных промышленных верификаторов.
5. Метод семантического анализа описаний систем управления на основе стандарта IEC 61499 с использованием Web-онтологий, позволяющий выявить семантические ошибки в описании на ранних стадиях проектирования, что сокращает общее время проектирования системы.
6. Метод рефакторинга диаграмм управления выполнением (диаграмм ЕСС) базисного ФБ на основе трансформаций графов, позволяющий избавиться от условных дуг и потенциальнотупиковых (по условиям) состояний, что повышает качество проектных решений и предотвращает фатальные ошибки в функционировании системы управления.
7. Метод синтеза моделей контроллеров безопасности распределенных систем управления на основе RsNCES-сетей, позволяющий генерировать запрещающие правила для предотвращения попадания замкнутых систем «управление-оборудование» в опасные состояния.
8. Шаблоны модельно-ориентированной реализации систем функциональных блоков (ШМОРСФБ), предназначенные для решения проблемы портабельности управляющих приложений на основе стандарта IEC 61499, позволяющие достичь высокой степени независимости поведения управляющего приложения от модели выполнения ФБ, поддерживаемой runtimeсредой.
9. Язык UML-FB для моделирования систем управления промышленными процессами на основе стандарта IEC 61499, основанный на расширении метамодели языка UML, позволяющий сократить семантический разрыв между структурным и объектно-ориентированным подходами к проектированию систем управления и облегчить переход от системных требований к артефактам проектирования.
10. Формальная модель иерархических модульных недетерминированных автоматов (ИМНДА), позволяющая описывать и проектировать сложные иерархические локальные системы управления с параллельными процессами, а также реализовывать их на языках ПЛК и VHDL.
Соответствие диссертации паспортам научных специальностей Полученные в диссертационной работе результаты соответствуют следующим областям исследования, определенным в паспортах научных специальностей. В паспорте специальности 05.13.17 «Теоретические основы информатики»: п.4. «…разработка интегрированных средств представления знаний, средств представления знаний, отражающих динамику процессов, концептуальных и семиотических моделей предметных областей… »; п.10. «Разработка основ математической теории языков и грамматик, теории конечных автоматов и теории графов»; п.11.
«… разработка основ теории надежности и безопасности использования информационных технологий...»; п.12. «Разработка математических, логических, семиотических и лингвистических моделей и методов взаимодействия информационных процессов, в том числе на базе специализированных вычислительных систем»; п.14. «Разработка теоретических основ создания программных систем для новых информационных технологий». В паспорте специальности 05.13. «Элементы и устройства вычислительной техники и систем управления»:1 п.1. «Разработка научных основ создания и исследования общих свойств и принципов функционирования элементов, схем и устройств вычислительной техники и систем управления»; п.4. «Разработка научных подходов, методов, алгоритмов и программ, обеспечивающих надежность, контроль и диагностику функционирования элементов и устройств вычислительной техники и систем управления». Конкретная раскладка основных результатов, выносимых на защиту, по областям исследований следующая: 1) 05.13.17, п.14; 2) 05.13.05, п.1; 3) 05.13.17, п.4; 4) 05.13.05, п.4;
05.13.17, п.11; 5) 05.13.17, пп.4, 14; 6) 05.13.17, п.10; 7) 05.13.17, п.11; 05.13.05, п.4; 8) 05.13.17, п.12; 05.13.05, п.1; 9) 05.13.17, п.4; 10) 05.13.17, п.10.
Реализация и внедрение результатов диссертационной работы.
Диссертационная работа выполнена на кафедре "Вычислительная техника" Пензенского государственного университета (ПГУ) в рамках следующих проектов:
Под элементами, схемами и устройствами в диссертационной работе понимаются функциональные блоки и другие артефакты проектирования стандарта IEC «Разработка САПР ТП с элементами искусственного интеллекта и средств их проектирования на основе ЛВС» по единому заказ-наряду Министерства общего и профессионального образования РФ (№ гос. рег. 01.9.50001883) (1993-1997 г.г.);
«Разработка комплекса формальных моделей и их трансформаций для проектирования распределенных информационно-управляющих систем промышленной автоматики» аналитической ведомственной целевой программы “Развитие научного потенциала высшей школы (2009годы)” Министерства образования и науки РФ (№ гос. регистрации 01200952061);
«Разработка моделей и методов проектирования устройств аппаратной поддержки компонент управления процессами и ресурсами распределенных операционных систем» федеральной целевой программы «Научные и научно-педагогические кадры инновационной России» на 2009-2013 годы Министерства образования и науки РФ (№ гос. регистрации 01201278457);
грантов A/03/06030 (2003 г.), A/06/27337 (2006 г.), А/10/01033 (2010 г.) Германской службы академических обменов DAAD;
гранта “Breakthrough in Function Block Technology” (FRDF, 3625072/9573) Оклендского университета (Новая Зеландия), 2011 г.
На ряд программных продуктов, разработанных в ходе НИР, были получены свидетельства об официальной регистрации, ссылки на которые можно найти в конце автореферата в разделе «Свидетельства».
Научные и практические результаты работы включены в ряд лекционных курсов на кафедре “Вычислительная техника” ПГУ, использованы в лабораторных практикумах, курсовом и дипломном проектировании, а также в НИР студентов. Ряд рекомендаций, подготовленных в ходе выполнения диссертационной работы, были учтены при подготовке новой версии международного стандарта IEC 61499. Основные положения диссертационной работы внедрены в НПФ «КРУГ» (Пенза), университете Мартина Лютера (Германия), а также в Техническом университете Лулео (Швеция) при выполнении проекта Y6.F7 «Verification of FREEDM System Control Robustness» программы FREEDM (NFS, США), использование результатов подтверждено соответствующими актами о внедрении.
Апробация работы. Основные научные положения и результаты диссертационной работы докладывались и обсуждались на следующих отечественных и зарубежных научнотехнических конференциях и симпозиумах: Международной конференции "Информационные технологии и системы" (Воронеж, 1993), Международной конференции EAST-WEST "Information Technology in Design (EWITD)" (г. Москва, 1994, 1996), IEEE конференции “Robotics and Automation (ICRA’05)” (г. Барселона, Испания, 2005), 6-й Международной конференции “Компьютерное моделирование 2005” (г. Санкт-Петербург, 2005), 11-й конференции IEEE "Emerging Technologies and Factory Automation (ETFA’2006)" (г. Прага, Чехия, 2006), Международных научно-технических конференциях "Интеллектуальные системы (AIS)" (п. Дивноморское, 2004, 2005, 2007), Международной научно-практической конференции “Перспективные технологии искусственного интеллекта” (г. Пенза, 2008), Всероссийских научно-практических конференциях “Современные информационные технологии в науке, образовании и практике” (г. Оренбург, 2007, 2008, 2009), 13-м симпозиуме IFAC "Information Control Problems in Manufacturing (INCOM’09)" (г. Москва, 2009), 4-й, 5-й и 9-й конференциях IEEE "Industrial Informatics (INDIN)" (Сингапур, 2006; г. Вена, Австрия, 2007; г. Лиссабон, Португалия, 2011), 37-й ежегодной конференции сообщества по промышленной электронике IEEE IECON'2011 (г. Мельбурн, Австралия, 2011), Международной научно-практической конференции "Информационные ресурсы и системы в экономике, науке и образовании" (г. Пенза, 2011), Международных научнотехнических конференциях “Современные информационные технологии” (г. Пенза, 2005, 2008, 2010, 2011, 2012, 2013), Международных научно-методических конференциях “Университетское образование (МКУО)” (г. Пенза, 2005, 2006, 2007, 2008, 2012, 2013, 2014), Международных научно-технических конференциях “Новые информационные технологии и системы (НИТиС)” (г. Пенза, 1994, 1996, 2002, 2004, 2006, 2008, 2010, 2012), XI международной научнотехнической конференции "Оптико-электронные приборы и устройства в системах распознавания образов, обработки изображений и символьной информации" ('Распознавание-2013') (Курск, 2013), 1-й Международной научно-практической конференции "Современные проблемы компьютерных наук (СПКН-2013)" (Пенза, 2013), XIV Международной научно-технической конференции «Проблемы техники и технологий телекоммуникаций» (ПТиТТ-2013)» (Самара, 2013). Результаты работы также регулярно обсуждались на конференциях профессорскопреподавательского состава Пензенского государственного университета.
Публикации. По теме диссертации опубликовано 106 научных работ, в том числе 2 монографии, 85 статей в журналах, сборниках научных трудов и трудах конференций (из них 25 статей опубликовано в изданиях, рекомендованных ВАК РФ, и 6 статей в зарубежных журналах).
Получено 10 свидетельств о регистрации программ для ЭВМ. Все результаты, составляющие содержание диссертации, получены автором самостоятельно.
Структура и объем диссертационной работы.
Работа состоит из введения, шести глав, заключения, изложенных на 365 страницах, списка литературы из 398 наименований, 6 приложений и содержит 309 рисунков и 17 таблиц.
1 ОБЗОР И АНАЛИЗ МЕТОДОВ ПРОЕКТИРОВАНИЯ РАСПРЕДЕЛЕННЫХ
ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ ПРОМЫШЛЕННОЙ
АВТОМАТИКИ
1.1. Архитектурные особенности и тенденции развития современных систем 1.1.1. Архитектура распределенных систем промышленной автоматики Современной тенденцией развития предприятий в настоящее время является их комплексная автоматизация. Предприятие рассматривается как единый объект автоматизации.Комплексная автоматизация предприятия находит свое воплощение в интегрированной информационной системе управления предприятием (ИИСУП), которую можно представить в виде пирамиды, включающей следующие уровни (снизу вверх): 0 - уровень объектов управления (оборудование), 1 - уровень ввода-вывода, включающий устройства связи с объектом (датчики, исполнительные механизмы, регулирующие органы), 2 - уровень непосредственного управления с использованием программируемых логических контроллеров (ПЛК) и промышленных PC, 3 – уровень SCADA-систем, 4 – уровень MES-систем, 5 – уровень ERP-систем (рисунок 1.1)[109]. В прежние годы в России нижние уровни (0-3) относили к автоматизированным системам управления технологическими процессами (АСУ ТП).
Рисунок 1.1 Архитектура интегрированной информационной системы управления Верхние уровни ИИСУП представляют собой программные системы, технология разработки которых достаточно хорошо развита. Узким местом, требующим самого пристального внимания, в настоящее время являются нижние уровни (уровни управления и ввода-вывода).
Назовем системы, охватывающие эти уровни, информационно-управляющими системами промышленной автоматики (ИУСПА). ИУСПА образуют класс технических систем, в котором интегрированы программные, аппаратные и мехатронные компоненты, тесным образом взаимодействующие друг с другом, что увеличивает сложность исследуемой системы в целом и определяет междисциплинарный характер предмета. Управляющее программное обеспечение (ПО) является основной частью современных ИУСПА для обеспечения корректных и безопасных операций процессов автоматизации. В результате существующих тенденций ИУСПА в настоящее время превращаются в сложные распределенные программно-аппаратные комплексы, содержащие десятки и сотни программируемых логических контроллеров (ПЛК), программируемых контроллеров автоматизации (ПКА), промышленных компьютеров, встроенных систем управления, связанных друг с другом с помощью вычислительных и промышленных сетей, а также еще большее количество датчиков и исполнительных механизмов. В действительности сфера применения ИУСПА не ограничивается только сферой промышленного производства.
Это сфера применения всей промышленной автоматики – от транспортировки нефти и газа и электроэнергетики до сельского хозяйства, мобильных платформ и эксплуатации зданий и сооружений. Общие принципы построения управляющих вычислительных комплексов рассмотрены в [156].
На рисунке 1.2 представлена обобщенная структура аппаратных средств АСУ ТП, включающая аппаратные средства ИУСПА (последние обведены контуром). На рисунке 1.2 приняты следующие обозначения: PC – персональный компьютер или мэйнфрейм; PLC – программируемый логический контроллер (ПЛК); S – сенсор (датчик); А – актуатор (исполнительный механизм); Network – коммуникационная сеть. На PC реализуются программные системы типа SCADA, MES, ERP. Стрелками на рисунке показаны направления передачи данных в сетях.
Сеть Network 1 служит для связи ПЛК с сенсорами и актуаторами. Здесь могут использоваться сети типа ASI, DeviceNet и т.п. Сеть Network 2 – промышленная шина (Fieldbus) типа Profibus, Modbus и т.п. В качестве Network 3 используется офисная сеть, например, Gigabit Ethernet. Как видно из рисунка 1.2, основными артефактами проектирования распределенных ИУСПА являются управляющие узлы, датчики и коммуникационные сети.
Следует отметить, что существуют АСУ ТП с числом уровней, отличным от трех. Например, в [108] используются системы с уровнем не более 2, а в работе [137] рассмотрена четырехуровневая система, которая вследствие использования локальных контроллеров включает еще один так называемый «локальный уровень» (рисунок 1.3).
Рисунок 1.2 Обобщенная структура аппаратных средств АСУ ТП.
Рисунок 1.3 Четырехуровневая распределенная АСУ ТП из работы [137].
Использование систем управления с числом уровней большим четырех, по всей видимости, нецелесообразно, по крайне мере, на данном этапе развития производства. Несмотря на то, что приведенная на рисунках 1.2 и 1.3 структура по внешнему виду является распределенной, для большинства существующих АСУ ТП в полном смысле распределенной ее назвать нельзя.
Как правило, с логической точки зрения это иерархическая, зачастую просто централизованная система, предназначенная для взаимодействия контроллеров с датчиками и исполнительными механизмами. Взаимодействие одноуровневых контроллеров отсутствует или сведено к минимуму (ввиду ограниченности стандарта IEC 61131-3).
Стандарт IEC 61131-3 в настоящее время является основным при разработке ИУСПА и ориентирован на проектирование централизованных систем управления на основе ПЛК. Одной из основных целей стандарта IEC 61131-3 была унификация концепции программирования управляющих приложений. Международной электротехнической комиссии (МЭК или IEC) удалось свести все многообразие используемых языков к пяти языкам (LD, IL, ST, SFC, FBD) [273]. В настоящее время каждый производитель управляющих устройств поддерживает (хотя бы частично) данный стандарт. Этот стандарт вводит концепцию функционального блока (ФБ), инкапсулирующего определенную функциональность. ФБ может содержать один алгоритм, а также данные. Язык ФБ в определенной степени обладает свойствами объектноориентированных языков, что упрощает повторное использование компонентов, однако IEC 61131-3 не поддерживает такие свойства, как наследование и концепцию интерфейсов. Стандарт IEC 61131-3 имеет два недостатка в отношении повторности использования компонент: 1) использование глобальных данных; 2) невозможность прямого управления порядком выполнения ФБ. Следует также отметить, что стандарт IEC 61131-3 был принят сравнительно давно (1993 г.) и в нем не учтены новые технологии разработки ПО. Среди недостатков архитектур, основанных на ПЛК, можно также упомянуть их массогабаритные, стоимостные и эксплуатационные характеристики. Так, например, стоимость ПЛК серий S7-300 и S7-400 фирмы Siemens составляет 500 и 4000 евро соответственно [110]. Цикл выполнения программ ПЛК лежит в миллисекундной области.
Требования современного рынка к быстрой перенастройке производственных систем для выпуска новых видов изделий, увеличение сложности выпускаемых изделий и, соответственно, систем управления породили новые проблемы при использовании централизованных систем на основе IEC 61131-3. Оказалось, что отсутствие поддержки передовых методов проектирования ПО увеличивает временные и материальные затраты на разработку сложной системы управления и уменьшает ее надежность. Централизованная архитектура дорогостояща и сложна в настройке и сопровождении, она не поддерживает масштабируемость и реконфигурируемость (добавление, удаление и изменение компонентов) системы и приводит к деградации показателей производительности. Следует заметить, что термин «распределенная обработка» в условиях применения IEC 61131-3 относится только к съему данных с пространственно распределенных датчиков через промышленную сеть и обработки ее в ПЛК.
Ранее предпринимались попытки упростить интеграцию ПЛК в системы, взаимодействующие через коммуникационную сеть, с использованием интеграционных компонентных архитектур, таких как Modbus-IDA и PROFInet-CBA [370]. Однако эти решения оказались полумерами для построения действительно распределенных систем автоматики, где «интеллектуальность» с самого начала проектируется как функциональность, децентрализованная и встроенная в программные компоненты, свободно распределяемые по сетевым устройствам. Следует отметить, что распределенные системы характеризуются структурной и поведенческой сложностью.
Показательно, что проектирование распределенных систем относится к числу «больших вызовов» в области вычислений [265].
Следует также упомянуть о других тенденциях, платформах и архитектурах в проектировании систем управления и автоматизации. Это связано в первую очередь с развитием технологической базы и аппаратного обеспечения средств вычислительной техники, в том числе с появлением технологий «Система-на-кристалле» (SoC), «Сеть-на-кристалле»(NoC), многоядерных процессоров и других аппаратных технологий. В работе [110] приводится аппаратный способ построения быстродействующих ПЛК на основе использования FPSLIC интегральных схем и предлагается замена управляющих программ контроллеров аппаратной реализацией автоматов, построенных на базе программируемой логики. В работе [6] обсуждаются проблемы внедрения многоядерных процессоров в системы промышленной автоматики. Описаны преимущества многоядерных систем, в том числе сокращение потребляемой мощности и возможность выполнения разных задач на одном процессоре.
Альтернативой или скорее архитектурным дополнением к структуре, приведенной на рисунке 1.2, в системах промышленной автоматики могут стать встроенные системы (embedded systems). Их можно рассматривать как самый нижний контур в системе управления, располагаемый в самом мехатронном устройстве, или как средство интеллектуализации объекта управления (интеллектуальные датчики и исполнительные механизмы). Встроенные системы — это специализированные системы управления, которые встраиваются непосредственно в устройство, которым они управляют [3, 253]. Системы данного класса широко используются на летательных аппаратах, автомобилях, промышленных предприятиях и т.д. [3]. В работе [398] вводятся требования к проектированию, развертыванию и функционированию, налагаемые промышленной средой на встроенные системы, особенно в области управления и автоматизации.
Рассматриваются типичные полевые устройства, используемые в промышленной автоматике, а также архитектура связанных с ними встроенных узлов. Особое внимание обращено на сеть Ethernet реального времени и беспроводные сети датчиков.
1.1.2. Распределенные системы управления нового поколения С учетом существующих тенденций и достижений в сфере новых технологий разработки ПО и телекоммуникаций в 2005 г. Международной электротехнической комиссией был принят новый стандарт IEC 61499 [274]. Этот стандарт определяет путь для построения систем управления промышленными процессами нового поколения. Это интеллектуальные распределенные компонентно-базированные системы. Архитектура IEC 61499 строится на основе определений IEC 61131-3. Основной элемент архитектуры – снова ФБ, хорошо знакомый и широко используемый инженерами, но его концепция расширена в нескольких направлениях для того, чтобы отразить новые достижения в области проектирования современных программных систем. Одно из основных расширений ФБ – событийный интерфейс, который позволяет явно определить последовательности выполнения ФБ. Другое расширение ФБ связано с объектной и компонентной ориентацией. По аналогии с методами, инкапсулированными в объект, ФБ может содержать несколько алгоритмов. Однако эти алгоритмы являются невидимыми извне, и к ним нет прямого доступа. Кроме того, в ФБ нет глобальных данных. Все это повышает повторную используемость ФБ. ФБ IEC 61499 представляет собой независимую программную единицу, которая может быть реализована, протестирована и использована отдельно от других ФБ.
Инструментальные средства реализации систем управления на основе IEC 61499 делятся на две категории: 1) средства поддержки проектирования (workbench) и 2) среды выполнения (run-time environment). Примерами некоммерческих средств первого типа являются FBDK [237], 4DIAC-IDE [164], Corfu/Archimedes [350] и FBench [233], а второго – FBRT [237], FORTE [164], FUBER [191], CyclicRT [348]. Первым коммерческим продуктом, поддерживающим IEC 61499 и IEC 61131-3, явилась система ISaGRAF (фирма ICSTriplex) [271]. Вторая коммерческая система NxtStudio (фирма NxtControl, Австрия) [304] ориентирована исключительно на IEC 61499. Особенностью последней системы является интеграция распределенной системы управления с системой SCADA.
Большинство разработок систем на основе IEC 61499 носят исследовательский характер и не вышли из стен лабораторий. Следует, однако, отметить, что на основе стандарта IEC уже было выполнено несколько реальных промышленных проектов [370]. Первая система управления на основе IEC 61499 была внедрена в 2005 г. на мясоперерабатывающем заводе в Новой Зеландии. Австрийская фирма NxtContol разработала и внедрила распределенную систему управления зданиями на основе IEC 61499, включающую 2500 датчиков и исполнительных механизмов и 19 контроллеров. В Италии экспериментальная обувная фабрика была оснащена оборудованием, управляемым на основе IEC 61499. Нашел свое применение стандарт IEC 61499 и в авионике. На его основе создана система управления заправкой топливом летательных аппаратов.
И, наконец, на основе IEC 61499 построена система управления роботом Delta [370].
Интерес к стандарту непрерывно растет как в промышленности, так и в исследовательском секторе. В настоящее время в мире существует несколько компаний и университетов, активно занимающихся созданием соответствующей инфраструктуры для внедрения стандарта IEC 61499 в инженерную практику, к числу которых относятся фирма Holobloc Inc. и Мичиганский университет (США), Yamatake Corporation (Япония), Оклендский университет (Новая Зеландия), Венский технологический университет, фирмы PROFACTOR GmbH и nxtControl GmbH (Австрия), Патрасский университет (Греция), Миланский политехнический университет и Центр исследований и инновационных технологий (Италия), университеты Халле, Магдебурга, Кайзерcлаутерна и Ганновера (Германия), Тамперский технологический университет (Финляндия), технологический университет Chalmers (Швеция), университет прикладных наук Лугано (Швейцария), фирма ICSTriplex и университет Калгари (Канада), Софийский университет химических технологий и металлургии (Болгария), а также ряд других компаний и университетов.
Стандарт IEC 61499 был принят сообществом OOONEIDA [373], созданным по инициативе IMS [272].
С начала исследовательских работ в рамках IEC 61499 было опубликовано три книги, объясняющие идеи IEC 61499 [286, 371, 396]. Как показала практика, этого явно недостаточно.
Ситуация будет более контрастной, если взять в качестве образца число книг по объектноориентированному проектированию. Имеется ряд хороших обзорных статей по стандарту IEC 61499, в которых акцентируется внимание на его преимущества и недостатки, особенности и нерешенные проблемы [351, 370, 395, 397].
Основными преимуществами использования стандарта IEC 61499 являются: повторное использование компонентов, сокращение сроков проектирования, повышение качества и надежности ПО, легкость реконфигурации, наличие предпосылок к проектированию на основе управления моделями (model driven development) и архитектурно-центрированного подхода [395].
Особенности IEC 61499:1) дуальность ФБ типа 1, заключающаяся в том, что, с одной стороны, ФБ может быть представлен как процесс, а с другой – как часть кода; 2) дуальность ФБ типа 2, согласно которой ФБ представляет как модель, так и выполнимую спецификацию; 3) выполнение на основе управления событиями (event-driven execution); 4) строгая инкапсуляция данных; 5) возможность недетерминированного поведения; 6) открытость входного XML-кода [370]; 7) способность к реконфигурации сети ФБ; 8) способность к межузловым взаимодействиям через коммуникационную сеть; 9) дуальность ФБ типа 3: ФБ обладают как свойствами программного, так и аппаратного модуля.
Несмотря на очевидные преимущества стандарта IEC 61499 перед своим предшественником – стандартом IEC 61131-3, его внедрение в промышленную практику идет довольно медленно. Промышленные компании не спешат переходить на новую технологическую базу по ряду объективных причин. Практически во всех обзорах по вопросам, касающимся IEC 61499, отмечаются следующие проблемы стандарта IEC 61499, тормозящие его внедрение в производство [351, 370, 395, 397]: 1) неразрешенные семантические проблемы, включающие как неточности в тексте самого стандарта, так и неоднозначность ситуации с моделями выполнения; 2) отсутствие образцовых приложений, которые могли бы служить «примерами для подражания»;
3) отсутствие четких проработанных методологий проектирования; 4) недостаток учебного материала; 5) несовершенство сред разработки и выполнения промышленного масштаба; 6) отсутствие апробированных методов и средств поддержки перехода от проектов стандарта IEC 61131-3 к стандарту IEC 61499. Кроме того, в работе [351] были отмечены дополнительные проблемы: 1) низкоуровневые взаимодействия между ресурсами и устройствами с использованием сервисных интерфейсных функциональных блоков (СИФБ), что увеличивает степень «непрозрачности» между узлами распределенной системы в процессе проектирования; 2) проблема управления качеством обслуживания (QoS), что связано с выполнением ограничений реального времени и с надежной коммуникационной инфраструктурой; 3) недостаточность диаграмм (сети ФБ и ЕСС) для того, чтобы описать структуру и поведение управляющего приложения. Как было отмечено в [351], стандарт IEC 61499 не определяет ни пути выявления требований (requirements elicitation), ни пути трансформации этих требований в проектные решения. По идее, все это должно решаться использованием эффективного процесса разработки.
Управляющая система представляется совокупностью устройств, взаимодействующих друг с другом с помощью коммуникационной сети, состоящей из сегментов и линий связи (рисунок 1.4).
Функция, выполняемая системой управления, описывается с использованием приложения (application), которое может распределяться по одному или нескольким устройствам.
Устройство (device) представляет собой физическую сущность, способную выполнять одну или несколько специфицированных функций в определенном контексте и имеющую, по меньшей мере, один интерфейс, являющийся или интерфейсом управляемого процесса, или коммуникационным интерфейсом [274]. На практике в качестве устройства могут выступать программируемые логические контроллеры (ПЛК), программируемые контроллеры автоматизации (ПКА), промышленные компьютеры. Устройство состоит из одного или нескольких ресурсов.
Ресурс – это функциональная единица, которая имеет независимое управление своими операциями, включая планирование и выполнение алгоритмов [274]. Ресурс может быть создан, конфигурирован, запущен и удален без влияния на другие ресурсы. Функциями ресурса являются прием данных и событий из управляемого процесса или коммуникационной сети, их обработка и выдача данных и событий управляемому процессу или коммуникационной сети (как это определено приложениями, выполняемыми на ресурсе). Важнейшей функцией ресурса является функция планирования (диспетчирования), которая определяет порядок выполнения ФБ и передачу данных между ними. Ресурс упрощенно можно представить как небольшую операционную систему в совокупности с исполняемым фрагментом кода.
Приложение является программной функциональной единицей, предназначенной для решения определенной задачи в системе управления. Приложение представляется в виде сети связанных между собой ФБ и субприложений, которые могут выполняться на различных ресурсах и устройствах системы. Модель приложения представлена на рисунке 1.5.
На рисунке 1.6 приведен пример соотношения приложений, устройств, ресурсов и сегментов в архитектуре IEC 61499.
Основным артефактом проектирования в IEC 61499 является функциональный блок (ФБ), представляющий собой специфичный программный компонент, имеющий интерфейс.
Интерфейс специфицируется множеством событийных и информационных входов и выходов, через которые соответствующий элемент взаимодействует с окружением. Информационные входы (выходы) определяются в виде входных (выходных) переменных ФБ.
Экземпляры ФБ имеют интерфейсы, во многом сходные с интерфейсами соответствующих типов ФБ, но имеются и существенные отличия. Во-первых, интерфейс экземпляра может быть только подмножеством интерфейса соответствующего типа, некоторые событийные и информационные входы и выходы в интерфейсе экземпляра могут отсутствовать. Во-вторых, в интерфейсе типа ФБ между событийными и информационными входами/выходами возможны так называемые WITH-ассоциации, которые используются для съема данных. В интерфейсах WITH-ассоциация представляется в виде вертикального отрезка, связывающего событийный вход (выход) с теми информационными входами (выходами), по которым будет производиться съем (выдача) данных при приходе на событийный вход (выход) сигнала. ФБ управляются с помощью событий, при этом данные являются пассивными, а события (сигналы) – активными.
Существует три вида ФБ: базисный ФБ, составной ФБ и сервисный интерфейсный ФБ (СИФБ). Структуры первых двух типов ФБ приведены на рисунке 1.7. Функциональность базисного ФБ определяется машиной состояний (Execution Control Chart – ECC) типа автомата Мура (рисунок 1.9, справа). С состояниями ECC (ЕС-состояниями) могут быть связаны выходные события и алгоритмы, определенные на одном из языков программируемых контроллеров стандарта IEC 61131-3 [273]. При активизации базисного ФБ некоторым событием он переходит через ряд состояний, выполняя при этом алгоритмы и выдавая выходные сигналы.
Рисунок 1.7 Функциональные блоки стандарта IEC 61499 [274]:
Диаграмма ЕСС выполняется под управлением специальной машины состояний OSM (Operation State Machine) (рисунок 1.8) [274]. Состояние s0 OSM-машины можно интерпретировать как свободное состояние ФБ, состояние s1 – как состояние оценки переходов диаграммы ЕСС (ЕС-переходов), а состояние s2 – как состояние выполнения ЕС-акций, связанных с текущим ЕС-состоянием. Пример базисного ФБ приведен на рисунке 1.9 [274].
Функциональность составного ФБ определяется входящей в него сетью ФБ (рисунок 1.10, справа). С использованием составных ФБ и субприложений производится иерархическая структуризация систем ФБ. Приложение определяется как совокупность ФБ и субприложений, соединенных событийными и информационными связями. Пример составного ФБ представлен на рисунке 1.10 [274].
Рисунок 1.10 Составной ФБ «D-триггер», срабатывающий по переднему Сервисные интерфейсные функциональные блоки (СИФБ) предоставляют один или несколько сервисов приложению на основе отображения сервисных примитивов на входы и выходы ФБ. СИФБ работают как «обертка», абстрагируя лежащие ниже аппаратные средства. В этом они похожи на драйверы устройств. Сервис предоставляется в виде набора сервисных последовательностей, которые в свою очередь представляются последовательностью сервисных транзакций. Сервисная транзакция, как правило, состоит из входного сервисного примитива и нескольких выходных сервисных примитивов. Последовательность сервисных транзакций определяется в виде диаграмм временных последовательностей (time-sequence diagrams) стандарта ISO TR 8509. Время в таких диаграммах увеличивается по направлению вниз. Поэтому сервисные последовательности, а также сервисные транзакции упорядочены по времени, порядок задается их положением в тексте XML-описания последовательности. На рисунке 1.11 справа в качестве примера приведена диаграмма временных последовательностей, представляющая нормальную передачу данных в клиент-серверной архитектуре [274].
Адаптерная связь служит для компактного представления выбранного множества одинарных событийных и информационных связей. Ее можно представить как жгут, шину или кабель, а сами адаптеры играют роль разъемов в представлении сложных взаимосвязей между ФБ в системе [274]. Механизм адаптеров позволяет снизить перегруженность схемы соединительными линиями и таким образом масштабировать сложность представляемой схемы. Так же, как и электрические разъемы, различают адаптеры-штекеры (plug) и адаптеры-сокеты (socket). Графическое представление типа адаптера приведено на рисунке 1.12,а. По внешнему виду (имеется ввиду интерфейс) адаптер напоминает ФБ.
интерфейс клиента (слева), интерфейс сервера (в центре), диаграмма временной последовательности (справа).
а – интерфейс; б – временная последовательность работы.
Стандарт IEC 61499 определяет абстрактную модель ФБ, допускающую различные интерпретации. Подобная недетерминированность модели ФБ и неоднозначность толкования семантики ФБ могут привести к разработке сред выполнения, которые дают разные результаты при интерпретации одной и той же системы ФБ. Все это порождает проблему портабельности управляющего ПО, основанного на IEC 61499.
Для того чтобы поведение приложения (т.е. логической сети ФБ) было полностью определено, необходимо задать так называемую модель выполнения ФБ. Назовем моделью выполнения ФБ (execution model) набор правил, регламентирующих порядок выполнения сети ФБ на ресурсе и устройстве. Модель выполнения должна по максимуму перевести недетерминированную по своей природе модель ФБ в плоскость детерминизма.
В идеале модель выполнения ФБ должна обладать следующими (возможно противоречащими друг другу) качествами, а именно быть: 1) интуитивно понятной инженеру; 2) простой в реализации; 3) предсказуемой в поведении; 4) справедливой; 5) с хорошей реактивностью; 6) свободной от зацикливаний и оттеснений; 7) верифицируемой; 8) детерминированной; 9) независимой от средств ее реализации (в частности, систем программирования), а также от платформы. Очевидно также и то, что модель выполнения ФБ не должна противоречить модели ФБ, принятой в стандарте IEC 61499, и опираться на нее.
В настоящее время интенсивно ведутся разработки моделей выполнения ФБ. Было предложено несколько моделей выполнения ФБ, в числе которых «непрерываемый многопотоковый ресурс» (NPMTR-модель) [343], «прерываемый многопотоковый ресурс» (PMTR-модель), последовательные модели, в числе которых модель, основанная на последовательной гипотезе [367, 376], и циклическая модель выполнения [284], синхронные модели выполнения [390], а также модели, реализованные в средах выполнения Crons, FUBER [191] и CEC. Некоторые из предложенных моделей опираются на текст стандарта и доопределяют его только в тех вопросах, в которых обнаружены явные лакуны. Другие модели свободно интерпретируют текст стандарта с точки зрения удобства разработчика или ссылаясь на модели реализации. Кроме того, были предложены модели выполнения для некоторых элементов стандарта, а именно: для составных ФБ [342] и базисных ФБ [376]. В работе [99] предлагаются модели выполнения систем интерфейсов ФБ. Таким образом, к настоящему времени накоплен довольно большой объем теоретических и практических знаний в области моделей выполнения ФБ. Каждая из известных моделей выполнения имеет свои преимущества и недостатки и в той или иной мере удовлетворяет многочисленным, порой противоречивым требованиям, предъявляемым к модели выполнения со стороны разработчиков систем управления.
Пробелы в определении семантики ФБ призваны восполнить модели выполнения ФБ, работы по созданию и стандартизации которых были инициированы в 2006 г. сообществом OOONEIDA [305]. К настоящему времени разработан только рабочий проект профиля совместимости [306]. В данном документе предлагаются три основные модели выполнения ФБ: последовательная, циклическая и параллельная. Хороший обзор по существующим моделям выполнения можно найти в [377].
Классификацию моделей выполнения ФБ можно осуществить различными способами.
Например, в [235] модели выполнения были классифицированы по двум признакам: 1) порядок сканирования ФБ (FB Scan Order); 2) многозадачная реализация (Multitasking Implementation).
Как можно заметить, в данном случае модели выполнения связывались со средой выполнения (что не вполне правильно с точки зрения требований к моделям выполнения). На рисунке 1. предлагается классификация моделей выполнения ФБ по одному из основных классификационных признаков – по режиму выполнения [97]. Как видно из рисунка 1.13, все модели выполнения можно разделить на последовательные и параллельные. Последние в свою очередь делятся на синхронные, асинхронные и синхронно-асинхронные.
Следует отметить, что существуют и другие классификационные признаки, некоторые из них представлены в [97]. С точки зрения «фундаментальности» модели выполнения условно можно разделить на основные и реализационные. Основные модели выполнения имеют определенный фундаментальный признак, который выделяет их среди других моделей. Реализационные модели выполнения имеют ряд более мелких признаков, совокупность которых выделяет их среди прочих.
Как правило, реализационные модели определяются теми инструментальными системами, в которых они реализованы. К реализационным моделям отнесем также набор средств, с помощью которых может быть сконструирован самый широкий спектр моделей выполнения. Сама конкретная модель выполнения при этом будет определяться набором некоторых входных данных.
Суть циклической модели выполнения ФБ заключается в том, что ФБ выполняются циклически, последовательно друг за другом в заранее определенном порядке, например, fb1, fb4, fb2, fb3. Таким образом, существует некий список запуска ФБ. Существует несколько вариантов циклической модели, например, в зависимости от того, учитывается ли при запуске ФБ наличие сигналов на его входах. Более подробную информацию о циклической модели можно найти в [284, 377].
Синхронная модель выполнения ФБ предполагает наличие внешних часов. Выполнение гранул (ЕС-переходов или ФБ) производится в моменты дискретного времени …, t - 1, t, t + 1, … В один момент времени выполняются все гранулы (ЕС-переходы или ФБ), которые могут выполниться. Синхронная модель выполнения ФБ имеет ряд преимуществ, среди которых:
1) ясность и понятность для инженера; 2) справедливость метода, поскольку раньше выполняются те ФБ, которые получили входной сигнал раньше; 3) отсутствие зацикливаний и оттеснений, возможных в предыдущих моделях. К недостаткам рассмотренной синхронной модели можно отнести зависимость результата от последовательности выполнения ФБ во фронте. Это касается случая, когда во фронте существуют связанные ФБ. Упорядочение выполнения ФБ во фронте с использованием собственных приоритетов ФБ является в большой степени искусственным приемом, поскольку в общем случае трудно обосновать предпочтение одного ФБ перед другим. Сам стандарт не предусматривает наличия приоритетов у ФБ.
Чтобы избежать зависимости результата от порядка выполнения ФБ во фронте связанных блоков предлагается двухступенчатая схема выполнения ФБ с промежуточной буферизацией выходных сигналов [54]. На первой ступени выполняются все ФБ из фронта готовых ФБ, однако передача выходных сигналов ФБ-потребителям с событийных выходов ФБпроизводителей откладывается. Можно представить, что данные сигналы на время «замораживаются», т.е. записываются в некоторый промежуточный буфер. На второй ступени отложенные сигналы «оживают» и доставляются своим потребителям. При двухступенчатой схеме выполнения ФБ порядок выполнения ФБ во фронте становится несущественным за счет того, что при выполнении ФБ учитываются только те входные сигналы, которые были приняты от блоков предыдущего фронта.
Для синхронной модели можно предположить наличие некоторого генератора импульсов, представляющего дискретные часы (рисунок 1.14). Каждый импульс будет представлять определенный момент времени.
Рисунок 1.14 Дискретное время определяется генератором синхроимпульсов.
В случае синхронной одноступенчатой модели можно предположить, что все ФБ, входящие во фронт, выполняются по переднему фронту синхроимпульса. При двухступенчатой схеме по переднему фронту выполняются действия первой ступени, а по заднему – действия второй ступени. Более подробную информацию о синхронной модели выполнения можно найти в [74, 101, 377, 390].
Модель выполнения, основанная на последовательной гипотезе Данная модель выполнения ФБ определена аксиоматически и основана на следующих шести постулатах [367, 376]: 1) ФБ может быть активизирован только сигналом на его событийном входе; 2) выполнение ФБ не может быть прервано выполнением другого ФБ; 3) выполнение базисного ФБ должно быть «коротким»; 4) входной сигнал ФБ уничтожается после срабатывания одного ЕС-перехода независимо от того, использовался этот сигнал в оценке этого ЕС-перехода или нет; 5) выходные сигналы ФБ выводятся немедленно после того, как соответствующая ЕС-акция завершилась; 6) если ФБ выдает несколько выходных сигналов в одном ЕС-состоянии, то они выводятся последовательно.
При приеме и обработке входного сигнала ФБ выполняется как единое целое (single run) до тех пор, пока в нем имеются разрешенные ЕС-переходы. Выходные сигналы выводятся последовательно, по мере их возникновения (в хронологическом порядке). Первым будет выполняться тот ФБ, сигнал на который пришел первым, что обеспечивает «справедливость» модели.
Для реализации последовательной модели наиболее подходит структура данных типа «Очередь» (или FIFO-структура). При решении задач в программировании эта структура данных используется в алгоритмах обхода графа в ширину. Следует отметить, что убрав шестой постулат, можно получить параллельную модель выполнения [365].
В модели выполнения, основанной на методе «Прямой вызов» (в оригинале – Direct Call или Direct Function Call), генерация нового события реализуется путем вызова метода run, связанного с ФБ [235, 394]. Как отмечено в работе [235], недостатком данного метода является зависимость времени распространения сигнала от топологии сети ФБ, причем это время может быть значительным. На данном методе во многом основывается модель выполнения NPMTR [343], реализованная в FBDK/FBRT [237]. Отличительная особенность модели – использование вычислений вглубь на уровне ЕС-переходов. Гранулой выполнения является ЕС-акция.
В качестве реализационной модели выполнения ФБ предлагается интегрированная параметризованная модель выполнения (ИПМВ) ФБ, в рамках которой предполагается собрать основные полезные свойства и методы существующих моделей, а также добавить ряд новых [52, 83]. Параметризация должна позволить разработчику самому выбирать (конструировать) требуемую модель выполнения путем задания определенных значений параметров (иначе, путем установки режимов). Для разработки ИПМВ использовались морфологические методы. Основой предлагаемой параметризации моделей выполнения ФБ является грануляция вычислений, а также порядок вычисления гранул на основе использования графа гранул.
Ниже предлагается набор морфологических признаков для моделей выполнения ФБ, причем сначала приводится название параметра, а в круглых скобках – его возможные значения: P1 – гранула выполнения (P11 – функциональный блок; P12 – ЕС-состояние; P13 – ЕСакция); P2 – порядок вычислений (P21 – обход графа в глубину; P22 – обход графа в ширину, P – приоритетный; P24 – циклический); P3 – синхронность выполнения гранул (при P21 и P22)(P31 – последовательное выполнение; P32 – синхронное выполнение); P4 – синхронность передачи сигналов (по нескольким линиям) между парой ФБ (P41 – последовательный; P42 – синхронный); P5 – порядок выдачи сигналов через событийные выходы (при P41)(P51 –естественный, основанный на очередности выдачи выходных сигналов при выполнении инициирующей гранулы; P52 – приоритетный, с учетом приоритетов агрегирующих ФБ для гранул-последователей и приоритетов соответствующих событийных входов, P53 – приоритетный, с учетом приоритета событийного выхода ФБ, P54 – приоритетный, с учетом приоритета событийной связи, соединяющий гранулу-источник с гранулой-приемником); P6 – порядок передач сигналов через один и тот же событийный выход по разным линиям (при P41) (P61 – с учетом приоритетов агрегирующих ФБ и событийных входов для гранул-последователей, P62 – с учетом приоритета событийной связи, исходящей из событийного выхода); P7 – кратность выдаваемых выходных сигналов с событийного выхода (при P41) (P71 – выдается один выходной сигнал; P72 – выдается столько выходных сигналов, сколько их было сгенерировано при выполнении гранулы); P8 – порядок выбора ФБ-последователя (при P42)(P81 с учетом приоритетов ФБ-последователей; P82 – с учетом максимального приоритета дуги в группе дуг, связывающих ФБ-источник и ФБприемник); P9 – порядок выбора входных сигналов при их одновременном приходе на ФБ (при P42)(P91 – определяется приоритетом событийного входа; P92 – определяется приоритетом входной событийной дуги; P93 – определяется естественным порядком выдачи сигналов с ФБисточников); P10 – метод выполнения составных ФБ (P101 – как единой сущности; P102 – как контейнера); P11 – приоритетность базисных ФБ перед составными ФБ (при P101)(P111 – больше;
P112 – меньше, P113 – равноценны); P12 – степень интегрированности модели выполнения сети клапанов данных (КД) в модель выполнения системы ФБ (при P102) (P121 – сеть КД выполняется как единое целое отдельно от системы ФБ и взаимодействует с общей моделью, когда завершает свою работу; P122 – система ФБ и сеть КД выполняются совместно, как единое целое); P13 – приоритетность сети КД перед базисными ФБ (при P121)(P131 – больше; P132 – меньше, P133 – равноценны); P14 – метод выполнения сети КД (при P121)(P141 – последовательное выполнение;
P142 – синхронное выполнение; P143 – последовательно-синхронное выполнение); P15 – тип ЕСпереходов без событий в диаграмме ЕСС базисного ФБ (P151 – пассивные, P152 – активные); P – тип выполнения транзакции по обработке внешнего сигнала (P161 – непрерываемый, P162 – прерываемый, P163 – смешанный); P17 – способ диспетчеризации внешних сигналов (при P161)(P171 – естественный, с учетом времени прихода внешнего сигнала, с сохранением; P172 – приоритетный, с учетом приоритета внешнего сигнала, с сохранением; P173 – немедленное восприятие, с потерей). Следует отметить, что не все значения параметров совместимы между собой. Более подробную информацию о ИПМВ ФБ можно найти в [52, 83].
Реализационные модели выполнения данного класса строятся на основе механизма спусковых функций [97]. С его помощью можно однозначно задать порядок выполнения ФБ. Спусковые функции строятся с использованием предикатов и функций времени выполнения ФБ.
Строго говоря, модель выполнения, кроме порядка выполнения, включает правила обработки входных сигналов и выдачи выходных сигналов, правила передачи сигналов и данных между блоками, правила интерпретации диаграммы ЕСС, но среди данных аспектов порядок выполнения ФБ является определяющим.
Для пояснения модели предварительно введем ряд определений.
FB = {fb1, fb2, …, fbn} – множество ФБ, входящих в систему и подлежащих исполнению.
EIj = {ei1j, ei2j, …, eikj} – множество событийных входов блока fbj. В дальнейшем для простоты верхний индекс будет опускаться.
ZEI: EI{0,1} – функция значений входных событийных переменных. Если EI(eij) = 1, то входная событийная переменная eij установлена (иными словами, сигнал присутствует на входе), иначе – сброшена.
Предикат activeFB: FB{true, false} определяет ФБ, являющиеся активными в текущий момент модельного времени. Предикат задает так называемую функцию возбуждения (или спусковую функцию). Интерпретатором будет сделана попытка запуска активного ФБ. В дальнейшем для краткости предикаты будем определять только именем, без показа самого отображения. Пример определения вышеприведенного предиката: activeFB(fbi). Обозначим FBa = {fbFB | activeFB(fb)} – множество активных ФБ в текущий момент модельного времени.
Предикат activeFBPrev(fbj) определяет, являлся ли блок fbj активным в предыдущий момент модельного времени. Обозначим FBap= {fbFB | activeFBPrev(fb)} – множество ФБ, которые были активными непосредственно в прошлом.
Предикат enabled(fbj) = ei EI [ZEI(ei)= 1] определяет, является ли разрешенным в текущий момент модельного времени блок fbj. ФБ является разрешенным, если хотя бы на одном из его событийных входов находится сигнал. Определим FBe= {fbFB | enabled(fb)} – множество разрешенных ФБ.
Функция EOS(fbj) определяет линейно-упорядоченное мультимножество сигналов (последовательность), выданных блоком fbjFB при своем выполнении. В данном случае сигналы идентифицируются событийными выходами ФБ, на которых они находятся. Упорядоченность определяется порядком выдачи сигналов.
Функция EIS(fbj) определяет последовательность сигналов, которые появились на входах ФБ в результате выполнения блока fbj. Упорядоченность определяется порядком появления сигналов на входах.
Функция OF(fbj) определяет последовательность блоков - приемников сигналов, выданных с блока fbj при его выполнении. Упорядоченность определяется порядком получения соответствующими блоками входных сигналов.
Функция pr: FB EI N0 = {0, 1, 2, …} определяет приоритет блока или событийного входа.
Отношение предпочтения Pref FB FB служит для определения наиболее предпочтительных блоков для выполнения. Это отношение частичного порядка. Если (fbi,fbj) Pref, то выполнение блока fbi предпочтительнее выполнения блока fbj.
Отношение PoolOrder FB FB задает жесткий порядок выполнения ФБ в циклической модели. С помощью этого отношения все ФБ связаны в кольцо опроса.
Отношение EvConn FB FB определяет событийные связи между ФБ как целыми единицами. Обозначим prefb множество предшественников блока fb по отношению EvConn.
Предикат activeEI(eij) определяет, является ли событийный вход eij активным. Сигнал на активном входе подлежит обязательной обработке.
Функция j: EIj N {} определяет времена прибытия (порядковые номера) сигналов на событийных входах блока fbj. В дальнейшем для простоты верхний индекс будет опускаться.
Если (eik)=, то считается, что на событийной линии eik сигнал отсутствует. В каждый новый момент модельного времени локальные часы для регистрации входных сигналов в системе сбрасываются в ноль.
С помощью спусковых функций можно определить практически любую модель выполнения. Примеры определения «классических» моделей выполнения представлены ниже.
Циклическую модель выполнения можно определить следующей функцией возбуждения:
activeFB(fbj) = fbiFB[activeFBPrev(fbi) & (fbi,fbj) PoolOrder] Циклическая модель выполнения с пропуском неразрешенных ФБ определяется следующим образом:
activeFB(fbj) = enabled(fbj) & ( fbiFBap[s=(fbi,fbi+1,…,fbj) [k{i, i+1,…, j–1} [(fk,fk+1)PoolOrder] & |s|> m{i+1,…, j–1}[enabled(fbj)]] fbiFBap & fbiFBe[pr(fbi)>pr(fbj)]).
Модель выполнения на основе последовательной гипотезы может быть определена следующим образом:
activeFB(fbj) = fbiprefbj[fbjOF(fbi) & (fbkOF(fbi) [activeFBPrev(fbk) & fbj=next(fbk)] activeFBPrev(fbi) & first(OF(fbi), fbj) = true)].
В классической синхронной однотактной модели в каждый момент модельного времени выполняются все разрешенные ФБ:
activeFB(fbj) = enabled(fbj).
В синхронной модели с использованием частичного порядка срабатывания в каждый момент модельного времени активизируются только наиболее предпочтительные разрешенные ФБ:
activeFB(fbj) = enabled(fbj) & fbiFB[enabled(fbi) & (fbi,fbj)Pref].
Рассмотрим следующий пример. Пусть отношение предпочтения Pref задано в виде диаграммы Хассе на рисунке 1.15. Тогда, если допустить, что разрешены все ФБ fb1…fb8, будет активизирован только один блок fb1 как наиболее предпочтительный. Если же разрешены все ФБ, кроме fb1, то одновременно будут активизированы блоки fb2, fb3 и fb4.
Рисунок 1.15 Диаграмма Хассе, определяющая отношение предпочтения ФБ.
Синхронную модель с использованием приоритетных уровней можно считать модификацией предыдущей модели. В ней одновременно активизируются только наиболее приоритетные разрешенные ФБ:
activeFB(fbj) = enabled(fbj) & fbiFB[enabled(fbi) & pr(fbi)>pr(fbj)].
В качестве примера рассмотрим реализацию синхронной модели на основе частичного порядка с помощью логических выражений. В функцию возбуждения включается конъюнкция инверсных значений предикатов разрешенности тех ФБ, которые предпочтительнее данного ФБ. Для блока fb5, приведенного в примере, представленном на рисунке 1.15, можно определить следующую функцию возбуждения:
activeFB(fb5)=enabled(fb5) & enabled(fb1) & enabled(fb2) & enabled(fb4).
С использованием механизма спусковых функций можно задать «нетрадиционные» модели выполнения, например, основанные на групповых взаимодействиях. Синхронная модель выполнения с явным группированием предполагает разбиение ФБ на группы G1, G2, …, Gn и активизацию блоков целыми группами. Возможно вхождение одного ФБ в разные группы, т.е. возможно, что Gi Gj. В группе ФБ может выделяться один или несколько лидеров группы. Можно выделить следующие условия разрешенности группы: а) разрешены все члены группы; б) разрешен один из лидеров группы; в) разрешены все лидеры группы; г) условие в виде произвольного логического выражения. Одновременно может быть разрешено несколько групп, что определяет конфликтную ситуацию. Возможны следующие пути разрешения конфликтов: а) на основе приоритетов групп; б) на основе максимального числа разрешенных ФБ в группах; в) на основе максимального числа разрешенных ФБ-лидеров в группах и т.д.
Обработка входных сигналов (в базисных ФБ) является одним из самых дискуссионных аспектов в моделях выполнения ФБ. Это связано прежде всего с тем, что сам стандарт не определяет полно жизненный цикл входных сигналов, это особенно касается тех моментов, которые связаны с их удалением. Попробуем еще раз выделить типовые ситуации, возникающие на событийных входах базисных ФБ, а также пути их решения [97, 222].
«Хорошая» ситуация, однозначно интерпретируемая стандартом IEC 61499 и не вызывающая проблем в моделях выполнения ФБ, приведена на рисунке 1.16. Это случай, когда на один из событийных входов поступает сигнал, и при этом существует разрешенный переход в диаграмме ЕСС, помеченный этим сигналом.
Рисунок 1.16 Однозначная ситуация с входными сигналами.
Если предположить параллельное асинхронное функционирование ФБ, которое покрывает все возможные сценарии развития событий в системе ФБ, то, кроме «хорошей» ситуации, представленной на рисунке 1.16, возможны и другие ситуации, которые, однако, вызывают различные трактовки у разных исследователей. Назовем эти ситуации проблемными. Схематичное представление подобных ситуаций приведено на рисунке 1.17. На данном рисунке состояние операционного автомата (OSM) обозначено как State. Значение free («свободно») соответствует состоянию s0 автомата OSM, а состояние busy («занято») – состояниям s1 или s2 автомата OSM [274].
a – «Одновременный приход сигналов на входы ФБ» (ситуация 1);
в – «Приход сигнала на незанятый ФБ, когда его обработка Ситуация 1 (рисунок 1.17,а), когда на входы ФБ одновременно приходят несколько сигналов, является маловероятной, но возможной. Более вероятной является ситуация 2 (рисунок 1.17,б), когда в занятом состоянии на ФБ приходит сигнал. И чем больше реальная продолжительность выполнения алгоритмов, тем более вероятна данная ситуация. Ситуацию 3 можно считать типовой и она встречается на практике очень часто. Не рассматриваются отдельно ситуации 2 и 3 в случае прихода нескольких сигналов, поскольку это не меняет сути дела. Также особо не рассматривается ситуация, когда на один событийный вход приходит два (или более) сигнала с разных направлений, поскольку событийный вход с несколькими входящими событийными линиями можно заменить на эквивалентную конструкцию, содержащую стандартный ФБ E_MERGE. В этом случае данная ситуация трансформируется в ситуацию 1. Ситуация, когда на один и тот же событийный вход одновременно приходят два (или более) различных сигнала с одной и той же событийной линии, является логически бессмысленной. В этом случае «серия» из нескольких сигналов может быть представлена одним сигналом (хотя возможны другие варианты).
Для обеспечения детерминизма поведения системы ФБ модель выполнения призвана поддерживать только один из сценариев развития событий в системе. Исходя из фактора возможности проблемных ситуаций, приведенных выше, их следует рассматривать (а не игнорировать рассмотрение) в моделях выполнения ФБ, в которых они возникают. Следует, однако, заметить, что не все модели выполнения предполагают наличие всех перечисленных ситуаций.
Например, в модели выполнения на основе последовательной гипотезы в принципе невозможна ситуация 1.
Рассмотрим возможные пути решения проблемных ситуаций. По ситуации 1 имеются следующие варианты обработки входных событий ФБ:
1) по какому-либо правилу выбирается один (активный) входной сигнал, который будет в дальнейшем обрабатываться, а другие сигналы удаляются (правило DelEI1):
Здесь под eia обозначен событийный вход, на котором находится активный сигнал, а в фигурные скобки заключены исполняемые действия. Потерю сигналов можно считать недостатком этого правила, поскольку, по сути дела, теряется (возможно, важная) информация;
2) обрабатываются все входные сигналы, но по одному, в порядке предпочтительности.
Фаза активности ФБ включает обработку всех входных сигналов последовательно, один за другим (правило DelEI2);
3) обрабатывается один (активный) сигнал, выбираемый по определенному правилу, а остальные сохраняются. После обработки этого сигнала могут выполняться другие разрешенные ФБ. Фаза активности ФБ включает обработку одного сигнала (правило DelEI3).
Возможны следующие варианты выбора активного сигнала:
1) по приоритету входной событийной линии. При этом предикат выбора определяется как 2) по времени поступления сигнала:
IF a[i]>0 THEN SP:=SP+1;
Рисунок 3.3 – Доменно-ориентированные переходы: оператор присваивания (слева); оператор вычитания (в центре), оператор сравнения Другое важное расширение aNCES-сетей находится в области структуризации сетевых моделей. Известно, что обычные модульные NCES-сети не позволяют определить потоки меток между модулями [297]. Это затрудняет моделирование потоков данных между ФБ. Используемый в aNCES-сетях модуль представляет собой макроопределение (рисунок 3.4). В отличие от NCES-модулей между модулями этого типа возможна передача меток. Тип входа-выхода модуля определяется типом проходящей через границу модуля дуги. Тип дуги при этом определяется типом дуги по определению и парой “источник-приемник” дуги. На рисунке 3.4 используются следующие обозначения: e – событийная дуга, c – условная дуга, i – ингибиторная дуга, pa – арифметическая дуга типа “позиция-переход”, tp – простая дуга типа “переход-позиция” и т.д.
В дальнейшем все арифметические дуги будут помечаться символом a.
3.3.2. Методика моделирования систем функциональных блоков Методика построения полной многоуровневой aNCES-модели системы ФБ состоит из следующих шагов: 1) построение aNCES-моделей всех базисных ФБ; 2) построение aNCESмоделей всех составных ФБ, входящих в систему. Моделирование базисного ФБ на основе aNCES-сетей включает: моделирование управления выполнением операций, моделирование условий ЕС-переходов, моделирование алгоритмов, моделирование диаграммы ЕСС, моделирование приема и выдачи сигналов и данных. Моделирование составного ФБ сводится большей частью к моделированию сети клапанов данных.
Моделирование управления выполнением операций в базисном Для моделирования управления выполнением операций в базисном ФБ IEC 61499 используется NCES-модуль ControlECC. Модули этого типа создаются по одному на каждый экземпляр базисного ФБ. По сути, они представляют управляющую часть интерпретатора ЕСС (в терминах стандарта IEC 61499 - OSM-машину). Интерфейс NCES-модуля ControlECC приведен на рисунке 3.5, а его содержимое – на рисунке 3.6. Данная модель составлена в соответствии с разделом 2.2.3 части 1 стандарта IEC 61499 [274]. Позиция p1 представляет состояние s0 автоматной модели интерпретатора ЕСС, позиции p2 и p3 – состояние s1. Переходы t1 и t4 сетевой модели соответствуют одноименным переходам в автоматной модели интерпретатора ЕСС, а переход t3 представляет цепочку t2s2t3 автоматной модели.
Приведенная сетевая модель функционирует следующим образом. При наличии сигнала вызова ЕСС (вход invokeECC), который порождается приходом какого-либо входного события на ФБ, при нахождении интерпретатора ЕСС в начальном состоянии s0 (m(p1)=1) в операционную часть через выход sample выдается сигнал съема входных данных, и интерпретатор ЕСС переходит в состояние s1 (m(p2)=1). Следует заметить, что съем данных в модели производится в том же шаге, что и выдача сигнала съема. После этих действий в операционную часть интерпретатора ЕСС через выход eval_t модуля ControlECC выдается сигнал для оценки разрешенности ЕС-переходов в текущем состоянии. Операционная часть интерпретатора ЕСС выбирает разрешенный ЕС-переход, осуществляет смену состояний интерпретируемой диаграммы ЕСС и выполняет все ЕС-акции, связанные с целевым состоянием данного ЕС-перехода. После этого в управляющую часть интерпретатора ЕСС выдается сигнал о завершении выполнения всех этих ЕС-акций (вход acts_completed) и интерпретатор ЕСС переходит в состояние s1 (m(p2)=1). При этом цикл по оценке и выполнению ЕС-переходов будет продолжен в дальнейшем. Если же в результате оценки разрешенности ЕС-переходов выясняется, что в диаграмме ЕСС нет разрешенных переходов, то операционная часть интерпретатора ЕСС выдает в управляющую часть соответствующий сигнал (вход no_t_clears). В этом случае интерпретатор ЕСС вновь переходит в начальное состояние s0 (m(p1)=1). Следует также заметить, что при приходе сигнала вызова ЕСС в случае, когда интерпретатор не находится в начальном состоянии (m(p1)=0), никаких действий не производится и сигнал теряется. При этом считается, что ФБ занят.
Рисунок 3.5 – Интерфейс NCES-модуля Рисунок 3.6 – Содержимое NCES-модуля управления выполнением. управления выполнением.
Шаблон Cond-модуля для вычисления условий переходов в диаграмме ECC (ECпереходов) включает входы–выходы start, true и false, а также (возможно) условный вход ei и арифметические входы. По сигналу, поданному на событийный вход start, модуль начинает вычисления условия. По завершению вычислений сигнал подается на выход true, если условие истинно, и на выход false, если ложно. Необязательный условный вход ei используется, если в условии фигурирует событие. При этом данный вход связывается с внешней позицией, представляющей входную событийную переменную (EI-переменную). Арифметические входы используются, если в условии фигурируют переменные ФБ. С этими входами могут быть связаны внешние позиции, представляющие входные, выходные и внутренние переменные базисного ФБ.
На рисунках 3.7 и 3.8 в качестве примера изображен один из вариантов Cond-модуля, вычисляющего условие ЕС-перехода ei1&(di2>10) в диаграмме ЕСС, представленной на рисунке 3.11. Для разрешения конфликта между переходами t1 и t2 используется ингибиторная дуга.
Переход t6 реализует функцию сравнения “Больше”. Результат сравнения (0 или 1) записывается в позицию-переменную p3.
Рисунок 3.7 – Интерфейс Рисунок 3.8 – Содержимое Cond-модуля.
Cond-модуля.
Алгоритмы в модели базисного ФБ, также как и условия ЕС-переходов, представляются в виде модулей (называемых Alg-модулями). Шаблон Alg-модуля имеет один событийный вход start, событийный выход end, а также возможно несколько арифметических входов и выходов.
aNCES-сети позволяют представлять алгоритмы с использованием двух подходов: 1) с явным выделением управляющей и операционной частей для пошагового выполнения алгоритма; 2) с использованием принципа потока данных, в соответствии с которым выполнение операций определяется готовностью операндов.
На рисунках 3.9 и 3.10 приведен пример Alg-модуля для моделирования простейшего алгоритма: if (v1>5) then v2:=v2+1; else v3:=3 с использованием первого подхода.
Рисунок 3.9 – Интерфейс Alg- Рисунок 3.10 – Содержимое Alg-модуля.
модуля.