Автоматизация создания АСУТП опасных производственных объектов

Для автоматизации проектирования объектов различного назначения в мире создано большое разнообразие пакетов прикладных программ (ППП) систем автоматизированного проектирования (САПР), которые предоставляют большую свободу программирования (AutoCAD, КОМПАС и т.д.).

Как правило, задачи автоматизации проектирования промышленных объектов решаются при следующих допущениях ^[1-3]:

1. Рассматривается размещение в заданном объеме.

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

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

4. Размещаемые объекты аппроксимируются параллелепипедами.

5. Размещаемые объекты имеют одинаковый набор параметров.

При постановке задачи определяют ^[4,5]:

- перечень размещаемого оборудования и его параметры,

- тип производственного помещения и его максимальные размеры,

- принципиальную технологическую схему,

- объемно-планировочное решение объекта,

- условия компоновки, включая критерий оптимальности получаемых вариантов решения.

Обобщенная структура такой математической модели, как правило, описывается N-ориентированным гиперграфом вида ^[6-9]:

G(X,U,UL) , (1)

где Х – множество вершин гиперграфа; U – множество гиперребер гиперграфа; U L = {ui= < xp1; xp2>i |l = 1,Ni} – множество ребер ориентированного подграфа

Gi (X,UL) , (2)

который задается в виде матрицы инцидентности L = {lp1,p2}, где

(3)

Для каждого объекта задается множество свойств SXi= {sj}1, описывающих его параметры (геометрические размеры, координаты базовой точки, масса, тип). Аналогично для каждой области размещения SUm= {sj}2, (геометрические размеры, параметры строительной ячейки, типоразмер строительных колонн, координаты базовой точки, номер этажа, тип) и для каждого технологического соединения SUlL= {sj}3. (координаты начала, конца и точек изменения направления трубопровода, диаметр, тип транспортировки веществ, стоимость единицы длины).

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

В итоге «на выходе САПР», помимо проектной документации, выдается схема (рис.1) технологического процесса ^[7].

Рис.1 – Технологическая схема обработки крахмалистого сырья (пример пожаровзрывоопасного технологического процесса)

Однако некоторые технологические процессы на предприятиях находятся под техническим контролем специальных надзорных органов, для обеспечения безопасного функционирования предприятий, которые квалифицируются, как опасные производственные объекты (ОПО). К таким объектам предъявляются требования безопасности, которые изложены в Технических регламентах (ТР) и Правилах безопасности (ПБ). Для разных технологических процессов созданы разные ПБ и выполнение требований ТР и ПБ обязательны для ОПО ^[7-9].

При создании проектов АСУТП для ОПО, функции выполнения требований ТР и ПБ возложены на проектную организацию, а качество их выполнения подтверждается государственной экспертизой проекта. Выполнение требований ТР и ПБ в управляющих программах АСУ ТП подтверждается только «Протоколом испытаний» между хозяйственными субъектами по программе и методике испытаний АСУ ТП, которую они сами же и составляют ^[10-13]!

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

Указанная задача была поставлена и решена, путем создания соответствующей математической модели и программно-технического комплекса, её реализующего.

Модель и основной алгоритм автоматизации создания АСУТП ОПО

В общем случае решение задач автоматизации любым технологическим процессом включает ^[1,11-15]:

- измерения параметров оборудования технологического процесса (температур, объемов, веса, токов, напряжений и т.д.);

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

- математическую обработку результатов измерений параметров и регистрации состояний;

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

- отладку режимов работы технологического оборудования (циклограмм, ПИД-регуляторов, аварийных уставок и т.д.).

Формализация описания технологического процесса, основана на предварительном составлении упорядоченных множеств: элементов системы L, команд F, состояний элементов системы AL, событий элементов системы C, состояний технологического процесса A ^[16-18].

Для реализации предложенного подхода использованы следующие определения и переменные ^[12,16]:

Состояние объекта автоматизации (ОА) – совокупность состояний технологического процесса.

Формально состояние ОА описывается совокупностью параметров

, (4)

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

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

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

(5)

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

Состояние элемента - значение булевой функции, определяющей условия участия элемента в технологическом процессе. для рабочего состояния, – для нерабочего состояния элемента ;

(6)

Команда – логическое воздействие на элемент технологического процесса ,

(7)

которое интерпретируется в специальный код соответствующего языка программирования, используемое для изменения состояния элемента , :

;

Множеству элементов технологического процесса соответствует множество команд:

(8)

Состояние технологического процесса – совокупность состояний всех его элементов при выполнении определенной функции АСУТП. Совокупность функциональных состояний технологического процесса образует множество:

(9)

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

Совокупность событий технологического процесса образует множество:

, (10)

где q – номер события.

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

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

(11)

где – число событий в состоянии , включая повторные события, а каждое число этого массива является индексом q, соответствующим номеру события в упорядоченном множестве событий (6).

Событие представляет собой реакцию на последовательность команд и задается в виде массива целых чисел :

(12)

где – число команд в событии , включая повторяющиеся команды, а каждое число этого массива является индексом r, соответствующим номеру команды в упорядоченном множестве команд.

При команда полностью определяет рабочее состояние элемента (2) и состояние технологического процесса (9) и текущее событие (10).

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

Функция задается в виде массива целых чисел

(13)

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

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

В связи с быстротекущими процессами в АСУТП, в отличие от АСУП и АСУТПП, основной характеристикой при алгоритмизации является временная характеристика алгоритма, которая определяет длительность решения и сложность, зависящие, как правило, от количества операций. И если охарактеризовать алгоритм функцией f(n), выражающей скорость роста объема вычислений при увеличении размерности задачи – n, то линейный или полиномиальный характер этой функции свидетельствует о «хорошем» алгоритме, а экспоненциальный – о «плохом». Так, например, при f(n)=2nувеличение производительности в 10 раз увеличивает размерность задачи, решаемой за то же время, всего на 15% ^[18].

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

Именно поэтому, при алгоритмизации был разработан метод описания динамических связей функционально-технологических моделей элементов объекта, оптимизирующий выполнение технологических процессов в управляющих контроллерах ^[11-13].

Основной алгоритм реализации математической модели представлен на рис. 2 (начало) и 3 (продолжение).

Рис. 2 – Начальная часть алгоритма

Рис. 3 - Завершающая часть алгоритма

Принимая во внимание, что разработчики АСУТП получают готовую технологическую схему (рис.1) объекта автоматизации (ТС ОА) и точные диапазоны условий (режимов, параметров и т.д.) технологического процесса в техническом задании (ТЗ), была синтезирована (рис. 4) следующая структура программно-технического комплекса (ПТК), реализующего разработанную математическую модель ^[12].

Рис.4 – Структурная схема ПТК

Таблица 1 - Классификация задач проектирования АСУТП

Все задачи, решаемые в процессе автоматизации проектирования математического и программного обеспечения, классифицированы (таб.1) по 3-м уровням описания структур (технологический, математический и физический) и 4-м классам (первичные средства ввода данных, физические устройства, технологическое оборудование и технологический процесс).

ПТК имеет удобный интерфейс для специалиста-технолога, который может не знать языки программирования, редактируя технологические объекты (рис.5), применение контроллеров (рис.6) и сетевое размещения (рис.7), получая в итоге программное обеспечение АСУТП.

Рис.5 – Страница конфигуратора

Рис.6 – Страница контроллера

Рис.7 – Страница WinCC

Мнемосхема АСУТП (рис.8) собирается из библиотеки, которая сформирована в соответствии с действующими стандартами.

Рис.8 – Мнемосхема ОА

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

Результаты и их обсуждение

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

Разработанный имитатор тестирования созданной АСУТП, без подключения реального объекта, позволяет исключить и исправить ошибки в программном обеспечении до пуско-наладки.

Разработанный ПТК дает возможность самостоятельной модификации АСУТП обслуживающему персоналу объекта автоматизации, т.е. без привлечения разработчиков системы.