Модель абстрактных функциональных блоков

Тип работы:
Реферат
Предмет:
ТЕХНИЧЕСКИЕ НАУКИ


Узнать стоимость новой

Детальная информация о работе

Выдержка из работы

МОДЕЛЬ АБСТРАКТНЫХ ФУНКЦИОНАЛЬНЫХ БЛОКОВ
И. В. Елькин, П.В. Кустарев
Рассмотрены существующие и перспективные методики проектирования распределенных информационно-управляющих систем (РИУС) в части создания архитектурных моделей. Описанные подходы являются в достаточной степени формализованными, закреплены в интернациональных стандартах и рассматриваются в качестве объединяющей платформы для сообщества разработчиков РИУС.
Современные подходы к проектированию РИУС
Проектирование информационно-управляющих систем, в том числе и распределенных (РИУС), построенных на основе цифровых сетей — это сложный процесс, включающий в себя последовательность фаз и этапов, ведущих от прикладной задачи к реализации системы. Перечислим основные шаги при проектировании.
1. Фаза 1- создание и анализ абстрактного описания прикладной задачи, решение которой возлагается на систему:
a. формулирование требований к системе в формальном или неформальном виде-
b. разработка высокоуровневой архитектуры системы.
2. Фаза 2 — разработка по данному описанию реализации системы: протоколов, топологий, аппаратуры, программных функций и др. :
a. разработка аппаратной части системы-
b. разработка программного обеспечения системы.
Типовые подходы к этапам первой фазы — использование модели программируемых логических контроллеров (ПЛК, PLC) с централизованным управлением (стандарт IEC 61 131) или использование модели распределенного управляющего приложения на базе функциональных блоков (ФБ) с элементарными функциями (стандарт IEC 61 804). Рассмотрим подробнее каждый из этих подходов.
Проектирование на основе PLC
При проектировании РИУС на основе программируемых логических контроллеров идеологически алгоритм управления является централизованным и сосредоточен в одном или нескольких контроллерах большой вычислительной мощности, которые связаны с сетью распределенных датчиков и исполнительных устройств.
Программирование PLC осуществляется на специальных языках в рамках специальной программной модели — виртуальной машины, которая изолирует разработчика от реальной аппаратуры и определяет структуру вычислительного процесса, правила исполнения и взаимодействия задач, типы данных, порядок взаимодействия PLC и УСО.
Стандартом, определяющим архитектуру, параметры аппаратных средств, организацию коммуникационной подсистемы PLC, является IEC-61 131. В разделе IEC 61 131−3 этого стандарта приводится описание синтаксиса и семантики нескольких языков программирования PLC — как текстовых, так и графических (SFC, LD, FBD, ST, IL). Используя многообразие языковых средств, пользователь может выбирать наиболее удобные для него языковые конструкции для описания логики.
К достоинствам модели на основе PLC можно отнести возможность формального описания прикладной задачи на аппаратно-независимом языке, возможность перепрограммирования и конфигурирования функциональности системы конечным пользователем, набор различных языков для решения разных задач и хорошую
структурированность получаемого управляющего ПО, что облегчает дальнейшее усовершенствование системы, а также допускает повторное использование кода. Существуют инструментальные средства, охватывающие весь жизненный цикл разработки системы.
Основным недостатком подхода является то, что получаемое решение является централизованным, т. е. алгоритм управления сосредоточен в пределах одного промышленного контроллера, что приводит к ограничениям масштабирования системы производительностью PLC, неэффективности построения распределенных приложений, потенциальному снижению надежности. Кроме того, стоимость PLC достаточно высока.
Системы с распределенным управлением
Системы с распределенным управлением (Distributed Control Systems — DCS) основаны на принципе децентрализованного управления. При этом прикладной алгоритм реализуется в виде распределенного приложения, отдельные модули которого исполняются параллельно на множестве взаимосвязанных интеллектуальных контроллеров. Данная архитектура определена в стандарте IEC 61 804, обобщающем аналогичные решения, разработанные в рамках различных технологий РИУС, таких как Foundation Fieldbus, Profibus-PA и ряда других.
Распределенные приложения собираются из функциональных блоков, которые можно гибко использовать и конфигурировать без традиционного программирования. Функциональные блоки (ФБ) являются стандартизированными пакетами функций управления — например, блок аналогового входного сигнала, аналогового выходного сигнала и ПИД-регулирования. Другими стандартными функциональными блоками управления являются дискретный вход, дискретный выход, селектор сигналов, ручной ввод, регулятор смещения/усиления сигнала и регулятор соотношения.
Основное достоинство данного подхода состоит в том, что получаемое решение является распределенным. Это позволяет использовать множество относительно маломощных и недорогих контроллеров для создания распределенного алгоритма управления, соответственно, возрастает масштабируемость системы. Функциональные блоки допускают динамическое конфигурирование в соответствии с конкретными условиями эксплуатации.
Недостаток же состоит в том, что функциональные блоки представляют собой достаточно примитивные пакеты функций управления (например, дискретные, аналоговые вводы/выводы), имеющие минимальные возможности их реконфигурирования, вследствие чего остается необходимость в низкоуровневом программировании при создании программной составляющей системы.
Рассмотренные подходы также имеют ряд общих недостатков, таких как отсутствие формальной методики проектирования и вытекающие отсюда несовместимость инструментальных средств от различных производителей, а также сложность интеграции различных программных решений, полученных с помощью этого инструментария.
Развитие идеи ФБ — абстрактные ФБ IEC 61 499
Решение проблем, указанных для обоих подходов, возлагается на обновленную модель описания, названную моделью & quot-абстрактных функциональных блоков& quot- и разрабатываемую в рамках проекта стандарта IEC 61 499 (рис. 1). Понятие & quot-абстрактные"- отличает их от ФБ стандарта IEC 61 804, являющихся примитивами, жестко связанными со своей реализацией и ограниченными ее возможностями.
& quot-Абстрактные ФБ& quot- совмещают лучшее, что есть в ранних моделях: они могут представлять сколь угодно высокоуровневые элементы алгоритма, как в языке БББ стандарта 1ЕС-61 131−3, сохраняя ориентацию на распределенную реализацию, как в модели 1ЕС 61 804.
Централ изован ность П рограмм ируемость Конфигурируемость
гибкость
распределенность
конфигурируемость
программируемость
Распределенность Конфигурируемость
Рис. 1. Развитие стандартов проектирования РИУС
Функциональные блоки служат основой для построения управляющих приложений, распределенных между отдельными узлами управляющей сети. Распределенное управляющее приложение представляет собой совокупность функциональных блоков, связанных управляющими и информационными связями. Каждый блок отвечает за выполнение какой-либо части управляющего алгоритма (например, управление клапаном или некоторой промышленной установкой), инкапсулируя в себе алгоритм управления и предоставляя внешний интерфейс. Таким образом, здесь имеет место объектно-ориентированный подход к созданию приложений.
Существует возможность создания своих блоков и их последующего использования при проектировании, а также расширения функциональности существующих блоков.
Основные принципы построения систем на основе абстрактных функциональных блоков
Рассмотрим основные принципы построения систем на основе абстрактных функциональных блоков.
Управляющие приложения, построенные в соответствии со стандартом, имеют распределенный характер, базирующийся на декомпозиции функции управления на несколько ФБ, закрепленных за разными физическими устройствами (рис. 2). При этом сохраняются абстрактные блоки, не связанные с реализацией. Приложение состоит из одного или нескольких экземпляров таких блоков, соединенных связями по данным и событиям.
Рис. 2. Структура распределенного приложения на основе ФБ
Все функциональные блоки относятся к тому или иному заранее определенному типу и имеют четкие интерфейсы данных и событий между ФБ (рис. 3). Стандарт предоставляет как текстовые, так и графические средства объявления интерфейсов типов ФБ, а также связи входов и выходов разных блоков между собой. На практике для описания типов данных используются языковые средства IEC 61 131−3 или XML.
Входы событий Выходы событий
I

Поток событий -ф
Поток данных
-Q-

ф- Поток событий
-еэ-в ¦e-
I
Связи
События/Данные Входы данных
е-

е-
Поток данных
е-
i
Выходы данных
Рис. 3. Интерфейс функционального блока
Функционирование приложения основано на модели управления событиями как на уровне внутреннего алгоритма отдельного ФБ, так и на уровне распределенной системы в целом. По сути дела, приложение представляет собой управляемый событиями конечный автомат. Простые Ф Б описываются объявлением внешнего интерфейса, диаграммы управления исполнением (конечный автомат) и алгоритмами, выполняемыми в соответствии с этой диаграммой. Алгоритмы могут быть написаны на
языках IEC 61 131−3 или других языках структурного программирования (например, C++, Java). Алгоритмы используют значения входов ФБ и внутренних переменных для вычисления выходных значений.
Стандарт определяет также служебные интерфейсы. Особый тип ФБ — сервисные интерфейсные ФБ (СИФБ). Они предоставляют стандартные интерфейсы для коммуникационных служб, служб ввода/вывода и службы операционной среды, таких как службы времени и синхронизации, функции инициализации приложений, создания экземпляров ФБ, их удаления, связывания и активации. Такие службы приобретают особенное значение в условиях увеличивающихся требований к гибкости системы.
Стандарт предоставляет возможности инкапсуляции и повторного использования алгоритмов-программ функционирования ФБ, создаваемых на языках IEC 61 131−3 или ряде других. Кроме того, с помощью так называемых составных ФБ и подсистем приложений поддерживается инкапсуляция сетей ФБ (рис. 4). Таким образом, распределенное приложение может строиться из набора повторно используемых компонентов с четко определенным интерфейсом и функциональностью.
Входные
I
Выходные
I
Диаграмма управления исполнением
Идентификатор типа
Алгоритмы
(IEC 1131−3)
& quot-Ж

Локальные переменные
Входные
Выходные
I
I
!

г
Управление исполнением
ш
Идентификатор ти
па

f? j=
С
5
?
i i i I
Входные Выходные Входные Выходные
Рис. 4. Механизмы инкапсуляции
Также обеспечивается переносимость алгоритмов-программ. Данная особенность предполагает возможности использования разнородных сред разработки и оборудования от различных поставщиков. С этой целью во второй части стандарта IEC 61 499−2 приведены схемы описания языка XML для стандартизованного обмена всеми библиотечными элементами IEC 61 499, включая типы данных, типы ФБ, подсистем, устройств, ресурсов и конфигураций, что обеспечивает их переносимость, повторное использование и распространение
Проектирование на базе абстрактных ФБ
Рассмотрим теперь особенности процесса проектирования управляющих систем на основе стандарта IEC 61 499.
Проектирование системы состоит в логическом описании прикладного алгоритма, заложенного в требованиях, как совокупности функциональных блоков, связанных между собой, независимо от конкретных аппаратных средств. На конечной стадии
проектирования осуществляется отображение отдельных блоков приложения на вычислительные узлы управляющей сети — построение распределенного решения.
В стандарте зафиксированы ключевые аспекты проектирования: унифицированы требования к функциональности инструментальных средств, правила их взаимодействия. Специальные профили соответствия описывают то, каким образом следует реализовывать модели стандарта, чтобы добиться возможности взаимодействия (interoperability) устройств от различных поставщиков, переносимости ПО (portability of software) между инструментальными средствами от различных поставщиков и конфигурируемости (configurability) устройств от различных поставщиков с помощью различных инструментальных средств.
Также унифицирован цикл проектирования и зафиксирована методология. В общем виде проектирование любой системы можно представить в виде итеративного спирального процесса, направленного на постепенное улучшение проектируемой системы. Каждая итерация состоит из следующих этапов:
1. оценивание (Evaluate),
2. улучшение (Improve),
3. эксплуатация (Operate).
Обобщенная методология, которая применяется в пределах одной итерации, включает следующие шаги.
1. Разработка и тестирование централизованной версии приложения с использованием одиночного устройства. На данном шаге разрабатываются функциональные блоки приложения (простые и составные), их интерфейсы и алгоритмы. На основе этих блоков создается простое (централизованное) приложение, состоящее только из блоков, реализующих требуемую функциональность управляющей системы, диктуемую процессом.
2. Разработка и тестирование распределенной конфигурации системы с использованием симулятора распределенных устройств. На данном шаге создается описание ресурсов и устройств, содержащих вспомогательные функциональные блоки (сервисные — коммуникационные и управляющие), необходимые для работы приложения в распределенной конфигурации. Создается конфигурация распределенного приложения.
3. Разработка и тестирование распределенной конфигурации системы на реальных устройствах. На данном шаге распределенное приложение загружается в реальные устройства и осуществляется удаленное конфигурирование системы через инструментальные средства (для тех устройств, которые поддерживают конфигурирование) либо загрузка сгенерированного промежуточного ПО (& quot-firmware"-) в не конфигурируемые пользователем устройства.
Данный переход от централизованной конфигурации к реальной системе обеспечивается моделью абстрактных ФБ. На всех этапах разработка сопровождается тестированием функциональности системы с использованием инструментальных средств (симуляция).
Стандарт определяет правила использования предлагаемых методик и дает рекомендации для достижения максимальной эффективности проектирования в различных типовых применениях, а также предлагает & quot-образцы проектирования& quot- -формализованные решения по организации проектирования для типовых задач. Применение & quot-образцов проектирования& quot- позволит упростить знакомство с концепциями стандарта, непривычными для специалистов в области проектирование систем управления, таких как принципы распределенного приложения, управление исполнением алгоритмов на основе событий и использование сервисных интерфейсных ФБ.
Кроме того, предлагается методология, основанная на идее визуального проектирования. Функционирование управляемой машины или процесса, а также соответствующих алгоритмов управления должно визуализироваться на всех этапах разработки — проектирования, симуляции, тестирования, внедрения и эксплуатации системы.
Выводы
Рассмотренный стандарт IEC 61 499 показывает общие тенденции развития методов проектирования сложных промышленных управляющих систем на базе цифровой техники. Можно сделать вывод о том, что имеет место постепенный переход к более высокоуровневым подходам при разработке систем, которые должны обеспечить сокращение цикла разработки на основе применения объектно-ориентированного подхода, повторного использования имеющихся наработок, переносимости получаемого решения и упрощения интеграции решений различных поставщиков за счет стандартизации и унификации. Также постоянно растут требования к гибкости получаемых решений. Промышленные системы в будущем должны обладать способностью к изменениям конфигурации системы в связи с изменениями в технологическом процессе и для быстрого восстановления системы после сбоев. В дальнейшем ожидается, что управляющие системы будут представлять собой совокупность автономных интеллектуальных модулей, способных самоконфигурироваться в соответствии с изменяющимися требованиями.

ПоказатьСвернуть
Заполнить форму текущей работой