CC BY
97
ЛапшинВ. И.
, СиневМ.П. , ЛёвинД.А., Пинский М.М.
АВТОМАТИЗАЦИЯ УПРАВЛЕНИЯ ПРОЦЕССОМ ЗАПРАВКИ
Одними из самых технологически-сложных процессов являются процессы заправки и слива. Автоматизация управления данными процессами представляет большой практический интерес. В настоящее время широкое применение получили управляющие системы на основе микроконтроллеров, главным достоинствомкоторых является простота внесения измененийв алгоритм работы.
Рассмотрим более подробно процесс заправки (рисунок 1)
Насос
И - Датчик 0§d- Клапан
Рисунок 1 - Структура системы заправки
Система состоит из нескольких автозаправочных цистерн, заправочной станции, пульта управления и заправляемых емкостей. Заправочная станция перегоняет насосами топливо из автозаправочных цистерн в заправляемые емкости. При этом клапанами регулируется направление потока топлива в магистралях заправки. Управление клапанами и насосами реализовано через управляющие реле. О состоянии всей системы можно судить по показаниям датчиков (реле уровня, реле давления, положения клапанов). Датчики и управляющие реле подключены к контроллерам ввода-вывода (КВВ), которые взаимодействуют по интерфейсу К8-485с контроллером пульта управления (КПУ) в режиме slave.Показаниям датчиков выводятся на табло, расположенное на КПУ, и, руководствуясь ими, оператор КПУ в ручном режиме или прошивка контроллера в автоматическом режиме должны предпринимать определенные действия.Согласно технологическому процессу - весь процесс заправки/слива разбивается на ряд автономных подзадач (операций).
Стандартно, состояние элемента системы в КВВ можно представить совокупностью флагов. При этом флаги доступные только для чтения служат для сбора информации - это могут быть флаги датчиков (где значение 1 означает, что он сработал, 0 - не сработал), флаги внутренней логики контроллера (например, флаг состояния готовности к работе) и т. д. Управление же может осуществляться через флаги доступные для записи, например, установив 1 в данный флаг, можно включить насос, 0 - выключить.
Задача управления таким распределенными системами является очень сложной. При этом разработчик наталкивается на ряд вопросов. Количество возможных ситуаций для анализа растет лавинообразно с ростом числа анализируемых флагов. Но время на анализ жестко лимитировано, так как система управления является системой реального времени. Кроме того, поскольку сама аппаратная часть так же находится в разработке, необходимо разработать такую систему управления, которая легко могла бы масштабироваться. Определенным ограничением возможностей разработчика является элементная база - а именно используемые контроллеры. Необходимо не только выдержать быстродействие, но и уложится в рамки доступной памяти.
Программирование на уровне флагов является довольно трудоемким, поэтому необходимо попытаться выделить все компоненты системы и операции, которые над ними производятся, а так же все их возможные состояния. Это легко представить на диаграмме классов (рисунок 2).
КПУ
проверкаГ отовности()
Регистры внутренней логики КПУ
проверкаКодаПроводимогоПроцесса()
проверкаРежимаРаботыСистемы()
проверкаТекущейОперации()
проверкаТипаЗаправляемогоКомпонента()
проверкаТекущегоСостоянияОперации()
установитьТекущееСостояниеОперации()
Сухой контакт
флаг сухого контакта
проверкаКонтактЗамкнут()
проверкаКонтактРазомкнут()
проверкаКнопкаВключена()
проверкаКнопкаВыключена()
флаг управляющего реле флаг контакта обратной связи кнопка ручного включения
проверкаНасосВключен() проверкаНасосВыключен() включитьНасос() выключитьН асос()
Рисунок 2 - Диаграмма классов компонентов системы
Кроме того, применение объектно-ориентированной парадигмы позволяет легко изменять описатель компонента: вводить новые методы и состояния [1] . А так же при появлении нового объекта (клапана, реле и т.п.) мы уже будем иметь полный набор методов по работе с ним.
Таким образом, весь процесс управления можно охарактеризовать как изменение состояния того или иного объекта, в ответ на изменение состояния другого объекта (рисунок 3).
Управляющий
механизм
Рисунок 3 -Процесс управления системой заправки
Управляющий механизм должен состоять из 2-х частей: жесткого ядра - планировщика задач описания объектов и процессов.
Функцией жесткого ядра является анализ изменения состояния системы и выполнение задач. Под задачей будем понимать описатель последовательности управляющих воздействий и реакций на изменение состояния объектов системы. В один момент времени возможно выполнение нескольких задач, причем каждая задача отвечает за конкретный параллельный процесс. Задачи могут порождать и завершать другие зада-
чи. Задача - есть лишь описание алгоритма. За выполнение этого алгоритма ответственен дескриптор задачи, который содержит следующую информацию: указатель на описание алгоритма; текущий шаг алгоритма;
параметр задачи (поскольку одни и те же алгоритмы могут выполняться с разными объектами); показание таймеров (каждая задача имеет в своем распоряжении 3 таймера, значение которых она может устанавливать);
перечень событий, которые отслеживает в данный момент задача (например, срабатывание реле, открытие клапана, срабатывание таймера задачи и т.д.). Каждое событие имеет свой приоритет - это сделано для исключения коллизий при одновременном появлении 2-х или более событий.
Все дескрипторы помещены в двусвязанную очередь задач. При этом порядок дескриптора в очереди задается приоритетом задачи, например, задачи анализа возможности аварийных ситуаций имеют высший приоритет, а задачи управления индикацией - низший.
Рассмотрим работу одного такта планировщика (рисунок 4).
И
S
О Ш
I го к ш О 0J
Блок анализа изменения флагов системы (
0
Предыдущее состояние системы
Рисунок 4 -Работа планировщика за один такт
Со связных модулей, функцией которых является обмен с подчиненными контроллерами, поступает новое состояние системы (1). В блоке происходит сравнение по исключающему ИЛИ нового состояния с предыдущим. Данный блок знает, какому параметру объекта системы соответствует определенный флаг. В случае изменения флага, данный объект посылает сигнал о соответствующем изменении своего состояния (2) . Завершив анализ всех флагов, блок копирует новое состояние системы в предыдущее. Каждая задача имеет перечень отслеживаемых в текущий момент времени сигналов и шагов обработки (3). При обработке сигналов происходит изменение управляющихфлагов, которое сохраняется в предыдущем состоянии системы (4). Отработав, задача может либо «уснуть» до возникновения новых сигналов, либо завершиться. После того как каждая задача отработает свой такт - предыдущее состояние системы будет отправлено на связные модули (5).
Для описания объектов и процессов была разработана специальная программа (рисунок 5) . Описание происходит на высоком уровне абстракции. По данному описанию строится прошивка для выполнения жест-
ким ядром.
Рисунок 5 - Программа описания технологического процесса
Таким образом, в статье предложен способ автоматизации управления процессом заправки. Отличительным достоинством данного способа являются его легкая масштабируемость, высокая производительность обработки и простота применения.
ЛИТЕРАТУРА
Буч Г. Объектно-ориентированное проектирование с примерами применения. Пер. с англ. - М.: Кон-
корд, 1992 .
