б. Программное обеспечение систем управления

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ

5.5. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РЕАЛЬНОГО ВРЕМЕНИ ОТ ФИРМЫ ON TIME INFORMATIK GmbH

RTKernel 4.5

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

5.5.1. Общие сведения

RTKcrnel представляет собой мощную многозадачную систему реального времени, предназначенную для разработки программного обеспечения, исполняющегося на IBM PC совместимых контроллерах с открытой архитектурой в среде MS-DOS.

RTKerncI является библиотекой или модулем, который может быть скомпонован с прикладной программой. В состав RTKernel входят многочисленные функции и процедуры управления задачами, семафорами и прерываниями, а также средства обмена данными между задачами. Запуск на исполнение задач RTKcrnel производится из единственной программы, которая содержит ядро, необходимые драйверы и все задачи. Данная программа может выполняться из любой вычислительной системе, содержащей операционную систему MS-DOS. Хотя программа, в которой используется RTKemel, и обладает свойствами, характерными для мультизадачных систем реального времени, она по-прежнему остается приложением DOS.

5.5.2. Основные характеристики

Рекомендуемые материалы

· Количество задач, выполняемых под управлением RTKernel, ограничивается общим объемом оперативной памяти. Для каждой задачи RTKernel дополнительно требуется около 1 кбайт памяти.

· Время переключения задачи не зависит от количества задач и составляет около 6 мкс (80486/33 МГц).

· Количество приоритетов задач - 64.

· Виды планирования: коллективное (Cooperative), с вытеснением (Preemptive), с выделением квантов времени (Time-Slicing).

· Переключение задач по событию или прерыванию.

· Возможность |активизации задачи при возникновении аппаратного прерывания.

· Возможность изменения периода поступления прерываний от таймера в диапазоне 0,1 ...55,0 мс.

· Возможность измерения временных интервалов с разрешением 1 мкс.

· Поддержка арифметического сопроцессора и его программной эмуляции.

· Семафоры: двоичные, счетные, ресурсов.

· Обмен данными между задачами с использованием очередей сообщений.

· Непосредственный обмен данными между задачами с использованием механизма передачи сообщений.

· Коммуникационный драйвер обслуживания последовательных портов в количестве до 36 с использованием прерываний.

· Поддержка аппаратного буфера универсальных асинхронных приемопередатчиков (УАПП) семейства 16С550.

· Драйверы для работы с таймером, видеоподсистемой, клавиатурой, принтером и локальными вычислительными сетями (ЛВС) Novell с протоколом IPX.

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

· Отсутствие проблем повторной входимости, свойственных MS-DOS.

· Возможность создания приложений RTKernel в виде резидентных программ.

· Возможность запуска других DOS-программ, в том числе Windows 3.0/3.1, из приложения RTKernel.

· Удобство отладки приложений путем использования встроенной возможности компиляции с добавлением отладочной информации, необходимой для Turbo Debugger или CodeView.

· Возможность создания приложений, загружаемых из ПЗУ.

· Возможность поставки версии с полным комплектом исходных текстов ядра.

· Отсутствие ограничений на количество разрабатываемых приложений.

5.5.3. Структура и принцип функционирования. Задачи RTKernel

Задачи RTKernel являются обычными Pascal-процедурами или Си-функциями без параметров, методы создания которых ничем не отличаются от традиционных. При старте программы на исполнение запускается только одна функция main. Несмотря на то, что в состав программы входит мультизадачная система реального времени, ее выполнение происходит последовательно, как в традиционных приложениях DOS.

Каждой задаче присваивается приоритет, значение которого может быть установлено в диапазоне от 1 до 64, а также выделяется собственная область стека. Самый высокий приоритет соответствует значению 64. Самый низкий -1. Все локальные переменные (за исключением статических), объявленные в пределах преобразованных в задачи функций (процедур), помещаются в собственные области стека каждой задачи. Это же относится и к функциям, вызываемым из задач RTKernel. Поскольку для каждой задачи формируется собственный стек, имеется возможность одновременного выполнения разными задачами одних и тех же участков кода. Структура приложения RTKernel показана на рис. 5.5.

Рисунок 5.5. Структура приложения RTKernel

5.5.4. Взаимодействие задач

Термин «взаимодействие задач» относится ко всем способам обмена информацией между задачами и методам синхронизации. RTKernel представляет три различных механизма взаимодействия.

5.5.5. Семафоры

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

5.5.6. Очереди сообщений

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

5.5.7. Передача сообщений

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

5.5.8. Планировщик

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

Любая задача RTKernel всегда пребывает в одном из следующих состояний (рис. 5.6).

Рисунок 5.6. Состояния задачи RTKernel

5.5.9. Current (состояние исполнения)

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

 

5.5.10. Ready (состояние готовности)

Все задачи, готовые к исполнению, находятся в состоянии Ready. В текущий момент времени одна из данных задач переходит в состояние Current (состояние исполнения). Задачи в состоянии Ready имеют одинаковый или более низкий приоритет по сравнению с текущей активной задачей.

5.5.11. Suspended (состояние приостановки)

Задачи, исполнение которых явно приостановлено обращением к ядру посредством вызова RTKSuspend. Данные задачи могут быть переведены в состояние Ready только с помощью вызова функции RTKResume.

5.5.12. Blocked (состояние блокировки)

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

5.5.13. Delaying (состояние задержки)

Задачи в данном состоянии блокируют себя на определенный интервал времени. По истечении заданного интервала обработчиком прерывания RTKernel по системному таймеру производится перевод указанных задач в состояние Ready.

5.5.14. Timed

 (состояние ожидания события с синхронизацией).

Состояние ожидания задачей события в течение заданного интервала времени. Перевод задачи в состояние Ready производится по истечении установленного интервала либо при наступлении ожидаемого события.

При инициализации RTKernel создаются две задачи: основная (Main Task) и «пустая» (Idle Task). Пустая задача, имеющая нулевой (самый низкий) приоритет, необходима для функционирования планировщика, поскольку условием его работы является наличие хотя бы одной задачи, находящейся в состоянии Ready.

Планирование в RTKernel происходит согласно следующим правилам.

1.Из всех задач, находящихся в состоянии Ready, в активное состояние переводится задача с наивысшим приоритетом.

2. Если в состоянии Ready пребывают несколько задач, имеющих одинаковый приоритет, в активное состояние переводится задача, не исполнявшаяся в течение наиболее длительного интервала времени.

3. Если несколько задач находятся в состоянии ожидания события, порядок их активизации при наступлении события осуществляется в соответствии с порядком убывания их приоритетов.

4. За исключением планирования исполнения задач с выделением каждой заданного кванта времени (Time-Slicing Task Switches), переключение задачи производится только в том случае, когда возникают предпосылки нарушения правила 1, что позволяет минимизировать количество переключении задач. Поскольку планировщик RTKernel реализован в строгом соответствии с данными правилами, исполнение задач, составляющих приложение RTKernel, всегда предсказуемо и абсолютно управляемо.

5.5.15. Прерывания

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

5.5.16. RTKernel, DOS и Windows

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

Рисунок 5.7. Взаимодействие Windows и RTKernel

Программа RTKernel может быть загружена в качестве резидентной (TSR -terminate and stay resident), после чего имеется возможность запуска на исполнение Windows 3.0/3.1 или приложения под управлением DOS-расширителя. В дальнейшем Windows и все приложения, запущенные под управлением Windows, рассматриваются RTKernel как одна задача. Другие задачи, входящие в состав RTKernel-приложения, продолжают выполняться в соответствии с требованиями, предъявляемыми к системам реального времени, и с возможностью неограниченного использования функций дискового ввода-вывода, а также взаимодействия с приложениями Windows посредством программных прерываний или специального модуля IPC (Inter-Process Communication - модуль межпроцессного взаимодействия). Таким образом, имеется способ создания сложных приложений реального времени, использующих интерфейс Windows (рис. 5.7). Вся работа в режиме реального времени выполняется под управлением RTKernel, тогда как интерфейс пользователя реализуется средствами Windows.

5.5.17. Драйверы устройств

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

Timer

Позволяет осуществлять измерение любого количества независимых временных интервалов с разрешением около 0,8 мкс. Длительность интервала может составлять до 3,7 лет. Кроме того, данный модуль предоставляет возможность изменения частоты системного таймера, которая обычно равна 18,2 ГЦ

RTKeybrd

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

KillKey

Дает возможность избежать нежелательных последствий, к которым может привести нажатие клавиш <Pause>, <PrintScreen> и т. п. во время исполнения приложения реального времени.

RTTextIO

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

Spooler

Обеспечивает возможность вывода файлов на печатающее устройство (параллельный принтер) в фоновом режиме.

CPUMoni

Позволяет критичным по времени исполнения приложениям реального времени контролировать степень загруженности процессора.

RTCom

Содержит полную реализацию взаимодействия с последовательными портами. Прием и передача данных через последовательные порты СОМ1-СОМ4 может осуществляться как в режиме опроса, так и по прерыванию.

RTIPX

Содержит полную реализацию протокола IPX фирмы Novell. Может использоваться на любой рабочей станции сети, в программной среде которой установлен стандартный драйвер IPX. Длина пакета передаваемых данных может составлять до 64 кбайт. В отличие от протокола Novell IPX обеспечивает гарантированную выдачу ответа на принятое сообщение. Обработка тайм-аутов и формирование запросов повторной передачи при обнаружении коммуникационных ошибок осуществляются непосредственно из приложения.

IPC

Облегчает реализацию взаимодействия между разными DOS-приложениями путем использования мультиплексного прерывания DOS. В основном это относится к резидентным программам, передающим данные основному исполняемому приложению. Кроме того, посредством IPC может быть организован обмен данными между приложением Windows и резидентной программой DOS.

RTKerneI-32

Многозадачное ядро реального времени для З2-разрядных встраиваемых систем

RTKerneI-32 представляет собой мощную мультизадачную систему реального времени, предназначенную для разработки встраиваемых приложений, использующих 32-разрядное линейное адресное пространство памятиRTKernel-32 является библиотекой или модулем, который может быть скомпонован с прикладной программой. В состав RTKemel-32 входят многочисленные функции и процедуры управления задачами, семафорами и прерываниями, а также средства обмена между задачами. Запуск на исполнение задач RTKernel-32 производится из единственной программы, которая содержит ядро, необходимые драйверы и все задачи. Исполняемый модуль приложения для запуска в составе встраиваемой системы, оснащенной процессором любого типа, поддерживающим Intel совместимый 32-разрядный защищенный режим, может быть подготовлен с помощью кросс-системы, подобной RTTarget-32, поставляемой фирмой On Time.

· Количество задач, выполняемых под управлением RTKernel-32, ограничивается общим объемом оперативной памяти. Для каждой задачи RTKemel дополнительно требуется около 1 кбайт памяти.

· Время переключения задачи не зависит от количества задач и составляет около 5 мкс (80486 33 МГц).

· Количество приоритетов задач 16.

· Виды планирования: коллективное (Cooperative), с вытеснением (Preemptive), с выделением квантов времени (Time-Slicing).

· Переключение задач по событию или прерыванию.

· Возможность активизации задачи при возникновении аппаратного прерывания.

· Возможность измерения временных интервалов с высоким разрешением.

· Поддержка арифметического сопроцессора и его программной эмуляции.

· Пять типов семафорных примитивов.

· Обмен данными между задачами с использованием очередей сообщений.

· Непосредственный обмен данными между задачами с использованием механизма передачи сообщений.

· Управление памятью в режиме реального времени (пулы памяти).

· Коммуникационный драйвер обслуживания последовательных портов в количестве до 36 с использованием прерываний.

· Совместимость с RTKernel-C для DOS.

· Совместимость с Win32 API

· Поддержка RTTarget-32 и других кросс-средств.

· Возможность запуска в составе целевых систем на базе процессоров, совместимых с i386.

· Возможность создания приложений, загружаемых из ПЗУ

· Возможность поставки версии с полным комплектом исходных текстов ядра.

· Отсутствие ограничений на количество разрабатываемых приложений. Структура приложения RTKernel-32 показана на рис. 5.8.

Рисунок 5.8. Структура приложения RTKernel-32

Для обеспечения возможности переноса в среду RTKernel-32 существующих многозадачных приложений, созданных для функционирования под управлением Windows NT или Windows 95, в ее состав включен практически полный набор функций, образующих интерфейс Win32.

1. 5.6. Программные комплексы для АСУ ТП

 

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

Типичным примером является компания Intellution - лидер в выпуске ПО АСУТП диспетчерского уровня (по английской терминологии - SCADA - или MMI - программ) на платформах Windows’95 и Windows NT фирмы Microsoft. Список программных продуктов Intellution и их краткое назначение приведены в таблице.

2. 5.6.1. Paradym-31

Пакет программ Paradym-31 является реализацией направления SoftLogic в области АСУ ТП. Суть этого подхода состоит в том, чтобы использовать в качестве контролера персональный компьютер (ПК) с открытой операционной системой (ОС). Благодаря этому существенно облегчаются и удешевляются разработка и сопровождение программ, предназначенных для управления в реальном времени (РВ). Современные промышленные компьютеры обладают достаточными для производственных процессов надежностью и быстродействием для применения, и эти их качества быстро прогрессируют. Особенно удобно их применение для сосредоточенных объектов. В этих случаях один ПК может выполнять функции и контролера, и рабочего места оператора. Например, достаточно широко используются для управления в РВ ПК фирм Octagon и Advantech.

В 1996 г. фирма Intellution приобрела компанию Wizdom Controls (США), которая являлась разработчиком одного из ведущих на американском рынке продуктов SoftLogic - пакета Paradym-31. Интегрировав этот пакет со своими продуктами, Intellution предложила потребителям Paradym-31 в одном ряду с FIX.

Пакет Paradym-31 позволяет программировать на трех графических языках стандарта МЭК 1131-3: SFC, LDD и FBD. После преобразования программы получается код на языке С++. Полученный С-код компилируется в ЕХЕ-файл. В целевой компьютер (контроллер) загружаются ЕХЕ-файл, драйверы связи с объектом  и ядро РВ для ОС. Сейчас поставляются диспетчеры для  МС-DOS и Windows NT. Кроме того, для ОС Windows NT разработано дополнение, превращающее ее в систему с жестким РВ с периодичностью такта 100±5 мкс.

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

Paradym-31 выпускается в трех конфигурациях: basic, standart и professional. Конфигурация basic поддерживает мониторинг выполнения программы  на контроллере; в конфигурации standart можно дополнительно использовать ПК как рабочее место с функциями узла View пакета FIX; наконец, конфигурация professional превращает узел Paradym-31 в SCADA-сервер FIX. Все узлы имеют модификации Development (этап разработки) и  Runtime (этап выполнения). Как обычно, в модификации Runtime в отличие от Development нельзя оперативно изменять проект (программу, базу данных и графические экранные формы).

Для связи с FIX используется специальный драйвер FastLink. Через DDE-протокол Paradym-31 может обмениваться и с другими приложениями, например, с Exel или Word.

Конфигурация системы с Paradym-31 Professional  и узлом FIX представлена на рис.5.9.

5.6.2. Пакет VisualBatch и  batch-процессы

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

Рисунок.5.9. Примеры сети с использованием Paradym-31

Возможна различная классификация технологических процессов. В США принято разделение на дискретные, непрерывные и batch-процессы. К дискретным относятся, например, сборочные производства и электроника. В таких процессах основное внимание обращается на переходы между отдельными состояниями обрабатываемого продукта.

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

Промежуточное положение занимают процессы смешанного типа , в которых есть дискретные и непрерывные этапы, а также периодические непрерывные процессы. По западной терминологии они называются batch-процессами. Такие процессы ориентированны на выпуск товаров партиями (по-английски - batch).

 Batch-процессы обычно объединяют несколько периодических процессов, протекающих в агрегатах, соединяемых параллельно-последовательно. Параметры этих процессов определяются технологическим регламентом, который зависит от выбранного оборудования, размера партии, состава сырья и других факторов. Такие процессы, как правило, являются периодическими и выпускают серийную продукцию, т.е. достаточно большой ассортимент при среднем объеме. Кроме того, в условиях быстро меняющегося рынка приходится достаточно часто перестраивать производство и технологические регламенты.

Обычно в SCADA-пакетах есть опция RECIPE (регламенты), которая позволяет разрабатывать систему уставок для управляющего технологического оборудования и загружать их в контроллеры. В частности, эту опцию имеет и FIX. Но так можно хранить сравнительно небольшое число регламентов. Функция RECIPE не решает задачи оперативной перестройки технологического процесса со сменой оборудования, слежения за выпуском партии продукта по этапам, тестирования разработки регламента и другие проблемы.

Чтобы облегчить автоматизацию batch-процессов, американское общество The Instrument Society of America (ISA) в 1990 г. начало работу по составлению стандарта, который бы регламентировал терминологию, набор понятий и моделей для этого типа процессов. В создании стандарта принимали участие как разработчики систем автоматизации ( в том числе и Intellution), так и ведущие американские компании, применяющие эти процессы - от Dow Chemical до Unilever.

В апреле 1996 г. названный стандарт был официально принят под  № S88.01. Предполагается, что он должен использоваться разработчиками систем автоматизации и облегчить им общение с заказчиками, а также гарантировать правильную постановку задачи разработки АСУ.

Согласно стандарту № S88.01 batch-производство представляется тремя типами моделей: физической, процедурной и технологической моделями процесса. Физическая модель состоит из описания производственного участка (process cell), установок (unit), технологических модулей установок (equipment module) и элементов автоматизации управления установками (control module), т.е. датчиков и контроллеров.

Процедурная модель (procedure, или recipe) делится на процедуру или регламент процесса в целом (procedure), процедуру отдельной установки ( unit procedure), операцию (operation) и фазу (phase). Фазы - это наименьшие единицы процесса, “кирпичики”, из которых строятся процедуры.

Технологическая модель процесса (process model) представляет собой объединение процедурной и физической моделей в производственном цикле (рис.5.10).

Процесс (process) - это реализация определенной технологической процедуры на производственном участке. При этом выполнение процедуры на установке образует стадию процесса (process stage); операция процесса (process operation) - это выполнение на установке отдельной операции, а под действием процесса (process action) понимается осуществление определенной последовательности технологических операций (фаз) на установке при помощи конкретного управляющего оборудования.

В соответствии с типами моделей стандарта  № S88.01 пакет VisualBatch содержит две главные подсистемы: редакторы оборудования и регламентов. Оба редактора графические. Это означает, что разработчик манипулирует мнемосхемами оборудования и алгоритмами процедур (регламентов) на графическом языке. Установки и их подсистемы изображаются специальными пиктограммами, которые можно взять из заготовленной библиотеки или нарисовать самому. Алгоритмы регламентов процесса в целом, отдельных операций и фаз строятся на графическом языке последовательных функциональных схем (SFC) по стандарту МЭК 1131-3.

Рисунок.5.10. Модели batch-процесса по стандарту № S88.01

Регламенты делятся на главные (master) и управляющие (control). Главные регламенты заранее разрабатываются компетентным инженерным персоналом. Разработчик оперирует отдельными фазами процесса. Он устанавливает последовательность и условия запуска фаз, а также значения уставок. Поскольку таких регламентов на все возможные ситуации бывает достаточно много, то для их  хранения могут использоваться реляционные базы данных, например Access и Oracle. В ходе разработки регламент можно проверить путем имитации его исполнения.

Управляющие регламенты выбираются из базы главных регламентов в соответствии с конкретными производственными условиями и исполняются при выпуске продукта на реальных технологических линиях. Оператор может запустить регламент, следить за его выполнением, приостановить, перевести на ручное управление и запустить заново. В VisualBatch ведется журнал выпуска партии продукта; с помощью специальных драйверов информация о выпуске продукта может передаваться на финансово-хозяйственный уровень производства типа SAR R/3, Oracle Application или Baan. Возможно параллельное управление несколькими технологическими процессами сразу.

Источником данных для VisualBatch служат DDE- или OPC-серверы. Протокол DDE- это стандартный протокол Microsoft для обмена данными между офисными приложениями. Информация о протоколе OPC приведена далее. Если VisualBatch работает совместно с пакетом FIX, то можно одним щелчком мыши перейти к отображению параметров установки в стиле рисунков FIX.

Узлы VisualBatch делятся на VB-серверы и VB-клиенты. Серверы поддерживают базу данных PB по выпуску партии продукта. Клиенты являются рабочими местами диспетчерского персонала. Пример архитектуры узлов VisualBatch приведен на рис.5.11.

Здесь на первом узле установлен программный пакет FIX SCADA и VP-сервер, а на втором - пакеты FIX View и VisualBatch-клиент.

Рисунок 5.11. Конфигурация узлов FIX и VisualBatch

5.6.3. Internet пакеты FIX WEB Server и FIX Broadcast Network

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

Здесь может помочь сеть Internet, которая радикально изменила общение людей. Широкие возможности она предоставляет и для подключения к производственным процессам. Для реализации этих возможностей Intellution предлагает два новых Internet-пакета: FIX WEB Server и FIX Broadcast Network.

Пакет FIX WEB Server позволяет наблюдать производственный процесс по Internet как по локальной компьютерной сети. При этом, однако, управлять процессом. Практически, чтобы получить доступ по Internet к производственной информации, достаточно установить в локальной сети рядом с узлом FIX SCADA Server дополнительный узел - FIX WEB Server. Этот узел должен иметь выход как в локальную производственную сеть, так и в Internet или Intranet (рис.5.12). На клиентском компьютере достаточно иметь стандартное ПО для доступа в Internet. Наблюдение за процессом в этом случае аналогично использованию узла FIX PlantTV.

Пакет FIX Broadcast Network автоматизирует функцию рассылки отчетов. Он реализует puch-технологию для получения периодических отчетов по Internet. Узлам-клиентам нужно иметь стандартное ПО для Internet и программу PointCast. Информационный отдел предприятия помещает отчеты о производстве на FIX Broadcast Network сервер, который  может собирать данные из FIX, реляционных баз данных (Access, Oracle) или финансово-хозяйственных пакетов (SAP R/3). Архитектура системы с узлом FIX Broadcast Network аналогична архитектуре, представленной на рис.5.12.

     

                                                 

Рисунок 5.12. Узел FIX WEB Server в сети

5.6.4. Интерфейсы OLE и OPC для SCADA-программ

Одна из главных проблем, с которой сталкиваются разработчики ПО управляющих систем РВ, состоит в стыковке между собой различных подсистем, в первую очередь контролеров и SCADA-программ верхнего уровня. В настоящее время существуют сотни различных типов контролеров с разнообразными протоколами. Их число постоянно пополняется, и в дальнейшем, несомненно, будут появляться все новые типы контролеров и протоколов. Проблема совместимости ПО может стать серьезной преградой для модернизации оборудования.

За ее решение в 1995 г. взялись пять ведущих американских компаний в области АСУТП: Intellution, Opto-22, Fisher-Rosemount, Rockwell Software и Intuitive Technology. При содействии специалистов из Microsoft они образовали комитет по подготовке универсального протокола обмена данными РВ. Деятельность комитета широко освещалась на семинарах и выставках, к его работе привлекались и другие компании. Всего в обсуждении этого протокола приняли участие около 90 компаний по всему миру. Первая версия спецификации была выпущена в 1996 г. В ней предложен программный интерфейс для обмена данными в РВ. Этот протокол основан на стандартах OLE/COM и регламентирует интерфейсы программных объектов. Разработчики постарались сделать его максимально гибким в определении формата передаваемой информации, адресации в контроле, организации данных (индексной, теговой, последовательной или иерархической), произвольной группировки информации. Допускаются различные дисциплины сканирования (опрос или по изменениям). Для передачи по сети данные могут произвольно группироваться. В соответствии с объектным подходом OLE/COM возможно расширение интерфейса.

Этот новый интерфейс назван OPC (OLE for process control). После выпуска спецификации был создан фонд разработки и внедрения OPC. Протокол OPC можно использовать не только для связи между устройствами ввода/вывода, но и как основу при обмене между приложениями РВ. Фирма Intellution применила данный протокол в целях связи между своими узлами SCADA и VisualBatch.

Для реализации названного интерфейса в серверах ввода/вывода Intellution предлагает специальный пакет OPC Toolkit. Код, полученный с помощью этого пакета, может поддерживать интерфейсы TAPI, DCOM и OLE-автоматизацию. Он снабжен средствами документирования разработки, имеет встроенную справочную систему и обучающий курс. Если требуется, интерфейс OPC может быть добавлен к результирующему коду автоматически. Пакет OPC Toolkit содержит обычный для Windows-приложенный графический интерфейс, который облегчает конфигурирование, диагностику и отладку. Генерируемый код поддерживает многопоточность, очередь сообщений и обработку по изменениям. Построенный с помощью этого пакета сервер ввода/вывода открыт для приложений на Visual Basic. Он поддерживает разделение портов (коммуникационных каналов) между серверами, диагностику и конфигурирование по сети.

Дополнительную информацию об OPC-протоколе и образцы кода можно получить на WEB-сервере Intellution и комитета OPC Foundation (www. opcfoundation.org).

5.6.5. FIX Dynamics - компонентное построение SCADA-программ

К рассмотренным здесь наиболее актуальным направлениям развития ПО автоматизации относится и компонентное программирование, суть которого в следующем: программа строится из модулей с универсальным открытым интерфейсом. Этот подход аналогичен методике “plug-and-play” подключения аппаратуры. Такая система позволяет достаточно просто вставлять независимо разработанные программные модули.

В качестве компонентного решения SCADA-программ Intellution предлагает пакет FIX Dynamics, в котором реализован принципиально новый подход. В существующих пакетах все подсистемы: база данных (БД), подсистема рисования и просмотра, история, тревоги и др. - неразрывно связаны. Нельзя взять одну из этих подсистем у одного разработчика, а другую - у другого. В то же время если программы поддерживают стандартный интерфейс, то их можно достаточно просто объединять. Система становится открытой и наращиваемой. Многократно увеличивается рынок программных продуктов, которыми потребитель может воспользоваться.

Кроме того, меняется и методика разработки проектов. Сегодня разработка проводится по принципу  “снизу вверх”. Например, сначала нужно построить основу - БД РВ. Следующий этап - создание рисунков для анимации информации из БД. Затем требуется детальная привязка рисунков к тегам БД.

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

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

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

Рис.Рис.5 Компонентное построение SCADA-пакета

Такая компонентная архитектура принята в новом продукте FIX Dynamics. Ядром системы служит программа I-Core, к которой по интерфейсу COM или OPC подключаются другие модули (рис.5). Программа I-Core состоит из шести разных компонент: интегрированной оболочки Intellution Workspace, поддержки  сети, службы тревог, защиты доступа, системы  конфигурирования и поддержки VBA и OPC.

 Intellution Workspace является  интегрированной средой разработчика. Ее интерфейс содержит две панели. В левой  в виде дерева представлен проект, в правой ведется графическая разработка проекта. Дерево  проекта  наращивается по  мере  добавления  новых компонент. Поддерживается  возможность  редактирования методом “drag-and-drop”.

Узлы FIX Dynamics могут быть объединены по сети с существующими узлами FIX 6,15, что позволяет безболезненно масштабировать систему автоматизации. Предусмотрена специальная защита от сбоев вставляемых элементов ActiveX Control. В качестве языка скриптов в новом пакете можно использовать Visaul Basic for Application, что многократно расширяет возможности построения пользовательского интерфейса.   

5.7. ПРОЕКТИРОВАНИЕ АСУ ТП НА БАЗЕ SCADA-СИСТЕМЫ

5.7.1. Что должна уметь система SCADA

Не вызывает сомнений, что АСУ ТП в большинстве случаев являются системами организационно-техническими, что означает наличие функций, выполняемых человеком (оператором).

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

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

До сих пор нет однозначного ответа на вопрос: нужно ли применять специализированное программное обеспечение класса SCADA? Следует отметить, что даже у тех, кто применяет такое программное обеспечение в своих проектах, нет единого мнения по поводу того, как должна выглядеть и каким требованиям должна отвечать «идеальная» SCADA-систсма. Однозначного ответа на данные вопросы не существует, так же как не существует единственно правильного подхода к проектированию систем промышленной автоматизации.

Необходимо различать программное обеспечение SCADA, функционирующее в составе АСУ ТП конкретного объекта, и набор инструментальных программных средств, предназначенный для разработки такого программного обеспечения, соответственно и критерии оценки средств разработки SCADA-систем и их пригодности для реализации той или иной прикладной задачи должны лежать в плоскости, несколько отличной от требований к прикладному программному обеспечению верхнего уровня АСУ ТП. Тем не менее обе разновидности ПО весьма тесно связаны (например run-time компоненты инструментальной системы непосредственно используются в объектовом ПО), поэтому мы будем называть их системами SCADA.

Для начала остановимся на основных функциях, которые возлагаются на любую SCADA-систему, независимо оттого, является она широко тиражируемым продуктом известной компании или создана специалистами отдела АСУТП предприятия для своих конкретных нужд.

· Не боясь быть банальными, еще раз переведем на русский язык понятие "SCADA-система" (Supervisory Control And Data Acquisition System) - система сбора данных и оперативного диспетчерского управления. Хотелось бы подчеркнуть, что в названии присутствуют две основные функции, возлагаемые на SCADA-систему:

· сбор данных о контролируемом технологическом процессе,

· управление технологическим процессом, реализуемое ответственными лицами на основе собранных данных и правил (критериев), выполнение которых обеспечивает наибольшую эффективность и безопасность технологического процесса.

Согласно традиционной структуре аппаратных средств АСУ 'I'П, SCADA-системы в иерархии программного обеспечения систем промышленной автоматизации обеспечивают выполнение следующих основных функций.

1. Прием информации о контролируемых технологических параметрах от контроллеров нижних уровней и датчиков.

2. Сохранение принятой информации в архивах.

3. Вторичная обработка принятой информации.

4. Графическое представление хода технологического процесса, а также принятой и архивной информации в удобной для восприятия форме.

5. Прием команд оператора и передача их в адрес контроллеров нижних уровней и исполнительных механизмов.

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

7. Оповещение эксплуатационного и обслуживающего персонала об обнаруженных аварийных событиях, связанных с контролируемым технологическим процессом и функционированием программно-аппаратных средств АСУТП с регистрацией действий персонала в аварийных ситуациях.

8. Формирование сводок и других отчетных документов на основе архивной информации.

9. Обмен информацией с автоматизированной системой управления предприятием (или, как ее принято называть сейчас, комплексной информационной системой).

10.Непосредственное автоматическое управление технологическим про- цессом в соответствии с заданными алгоритмами.

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

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

Более того, само наличие некоторых функций и объем их реализации сильно варьируются от системы к системе. Часто программное обеспечение с ярко выраженным упором на функции взаимодействия с оператором (визуализация и т.п.) называют пакетами MMI (Man Machine Interface), или HMI (Human Machine Interface).

На такой функции, как автоматическое управление, стоит задержать наше внимание. Хотя практически все известные инструментальные SCADA-системы обеспечивают возможность непосредственного автоматического управления технологическим процессом, разработчику АСУ ТП следует на этапе проектирования тщательно продумать целесообразность совмещения функций автоматического управления и операторского интерфейса на одном компьютере. Хотя такое совмещение позволяет экономить на аппаратных средствах, оно может иметь и ряд негативных последствий.

Во-первых, может оказаться, что операционная система операторской станции (в настоящее время наиболее популярна Windows) не обеспечивает необходимую для конкретного технологического процесса скорость и/или детерминированность реакции SCADA-системы.

Во-вторых, неумелые действия оператора или запуск им несанкционированного программного обеспечения может вызвать полный "крах" и "зависание" операторской станции. Хотя некоторые расширения реального времени для Windows NT декларируют защиту от подобного рода неприятностей, это справедливо только до тех пор, пока "крахом" не задета система управления памятыо. Но даже при "мягком зависании" повторный «горячий» рестарт компьютера весьма проблематичен, а рука оператора при виде "голубого экрана" Windows инстинктивно тянется к кнопке Reset, против которой любые расширения реального времени бессильны.

Разумеется, существует довольно большой класс инерционных систем (типа системы управления температурой воздуха в теплице), где несколько минут, потраченных на перезапуск управляющего компьютера, не приводят к сколько-нибудь заметным негативным последствиям. Для такого рода систем решение типа "все в одном компьютере" при надлежащей страховке сторожевым таймером может оказаться вполне допустимым.

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

При решении вопроса о том, писать программное обеспечение самостоятельно или использовать для этого инструментальную SCADA-систему. следует предварительно ответить на следующие вопросы.

1. Насколько велик проект?

2. Каковы сроки исполнения?

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

4. Какова перспектива дальнейшего развития системы (в частности, по информационной емкости, по модернизации имеющихся рабочих мест оператора и добавлению новых)?

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

Механические свойства костной ткани 3 - лекция, которая пользуется популярностью у тех, кто читал эту лекцию.

В принципе, ответы на эти вопросы и оценка затрат по пунктам 3,4,5 в большинстве случаев позволяют сказать, на чем писать математику для верхнего уровня АСУ ТП. Хотелось бы подчеркнуть, что SCADA-системы являются прежде всего инструментом для эффективной разработки программного обеспечения верхнего уровня АСУ ТП. Так что не следует верить поставщикам SCADA-пакетов, которые утверждают, что после покупки их продукта пользователю совершенно не придется привлекать квалифицированных специалистов в области программирования.

В тоже время в большинстве случаев SCADA-системы действительно позволяют значительно ускорить процесс создания ПО верхнего уровня АСУ ТП, не требуя при этом от разработчика знаний современных процедурных языков программирования общего назначения. Не секрет, что в тонкостях автоматизируемого технологического процесса разбирается только технолог или другой представитель технологического персонала, как правило, не обладающий навыками программирования. SCADA-система должна быть доступной не только для разработчика, но и для конечного пользователя создаваемой АСУ ТП, поскольку облик системы определяется и может подвергаться изменениям как разработчиком, так и пользователем.

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

Есть еще один неприятный момент, когда поддержка аппаратуры встроена в SCADA-систему. Речь идет о том, что производители SCADA-системы, которым приходится самостоятельно писать драйверы для различных типов аппаратуры, весьма редко могут качественно разработать драйвер, который бы поддерживал все функциональные возможности обслуживаемых технических средств. Кроме того, в подобных драйверах, в силу отсутствия возможности углубленного тестирования, встречаются досадные ошибки, которые выявляются на этапе разработки проекта или, что еще хуже, в процессе эксплуатации системы заказчиком. В результате огромные усилия тратятся на исправление ошибок и разработку новых драйверов, тогда как по-настоящему эффективный и практически свободный от ошибок драйвер может быть написан только самим производителем аппаратуры. Очевидно, что производитель SCADA-пакета должен в первую очередь своевременно устранять ошибки и улучшать функциональность самого SCADA-пакета.

Умеренная ценя н эффективное использование вложенных средств - стоимость системы, затраты на освоение и стоимость работ по созданию, сопровождению и развитию АСУ ТП должны быть минимальными. При прочих равных условиях данное требование является наиболее существенным и, пожалуй, решающим при выборе SCADA-снстемы. Разработчики SCADA-систем всегда стараются извлечь максимальную выгоду из продаж своего продукта (что вполне понятно), строя свой бизнес на продажах систем исполнения (run-time) и множества различных функционально завершенных компонентов, платном обучении. платных обновлениях и платном сопровождении. При этом задача менеджера фирмы-системного интегратора или группы АСУ TTI предприятия, отвечающего за выбор способа и инструментов разработки программного обеспечения, состоит в оценке предположительных временных и финансовых затрат на разработку, сопровождение и последующее развитие создаваемой АСУ ТП при использовании различных инструментов разработки.

Следует обратить внимание еще на один момент. В приведенных ранее рассуждениях отсутствуют какие-либо упоминания об операционных системах, под управлением которых может выполняться программное обеспечение сбора данных и оперативного диспетчерского управления. Уже несколько лет в различных изданиях, посвященных автоматизации промышленности, обсуждение тех или иных SCADA-систем сводится к рассуждениям о том, насколько плоха операционная система DOS, ненадежна Windows, хороша QNX или OS-9. Хотелось бы отметить, что требования к параметрам операционной системы должны определяться прикладной задачей. В случае программного обеспечения верхнего уровня АСУ ТП также следует учитывать то, что неотъемлемой частью системы здесь является человек, время реакции которого на события недетерминировано и зачастую достаточно велико. Кроме того нельзя не учитывать тенденции развития мирового рынка программного обеспечения.