CC BY
358
Вычислительные технологии
Том 9, № 5, 2004
ИСПОЛЬЗОВАНИЕ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ ПРИ РАЗРАБОТКЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ СЕВЕРОМУЙСКОГО ТОННЕЛЯ*
В. В. Окольнишников КТИ вычислительной техники СО РАН, Новосибирск, Россия
e-mail: okoln@kti.nsc.ru
A methodology of usage of simulation at the different stages of life cycle of processes in a control system is described. An application of this methodology to a development of the control system of North-Muisk railway tunnel (Baykal-Amur Railroad) is considered. The development of control programs of the control system of North-Muisk railway tunnel has been accomplished with the help of the simulation system Mera.
Введение
Разработка автоматизированных систем управления технологическими процессами (АСУ ТП) является в настоящее время одной из наиболее трудоемких и наукоемких задач. АСУ ТП — это сложная, разнородная, иерархическая, распределенная программно-аппаратная система управления, работающая в реальном масштабе времени и включающая человека в контур управления.
Программное обеспечение АСУ ТП представляет собой совокупность взаимосвязанных подсистем [1]. Эти подсистемы можно разделить на три слоя. Первый слой составляют подсистемы, обеспечивающие жизнеспособность АСУ ТП. К ним относятся подсистема сбора и обработки входных сигналов, подсистема передачи сигналов, подсистемы, обеспечивающие интерфейс с пользователем и др. Подсистемы первого слоя образуют программное окружение, в рамках которого могут функционировать прикладные подсистемы, обеспечивающие выполнение функций АСУ ТП. Второй слой программного обеспечения АСУ ТП — подсистема управления. Третий слой составляют сервисные подсистемы, обеспечивающие различные дополнительные функции АСУ ТП. Ядром АСУ ТП является подсистема управления, обеспечивающая выполнение основной функции АСУ ТП — управление технологическими процессами.
* Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований (грант № 02-01-00688).
© Институт вычислительных технологий Сибирского отделения Российской академии наук, 2004.
1. Постановка задачи
Для того чтобы подсистема управления была способной к модификации и развитию, она должна быть открытой. Как правило, технологический объект управления (ТОУ) АСУ ТП представляет собой совокупность различных типов управляемого оборудования (объектов управления). Открытость подсистемы управления означает:
— возможность изменения числа управляемых объектов каждого типа и добавление объектов нового типа;
— возможность изменения и добавления программ управления, реализующих управление технологическим процессом в соответствии либо с четкой логикой управления, определяемой условиями протекания технологического процесса, либо с нечеткой логикой, позволяющей оптимизировать параметры технологического процесса в некоторых заданных пределах.
Реализация подсистемы управления имеет сложности:
— невозможность комплексной отладки и тестирования подсистемы управления в полном объеме на инструментальных средствах разработчика — отладочном Стенде ввиду невозможности подключения реального оборудования, управляемого АСУ ТП;
— невозможность комплексной отладки и тестирования системы в полном объеме и на реальном объекте ввиду нецелесообразности или небезопасности искусственного создания всевозможных (в том числе и нештатных) ситуаций.
Вместе с тем отказ или неправильное функционирование подсистемы управления может принести значительный экономический, экологический или моральный ущерб. Наиболее подходящим методом решения этой проблемы является имитационное моделирование. Потребность в имитационном моделировании возникает тогда, когда задачу невозможно решить математическими методами с помощью построения математических моделей, а эксперименты над реальной системой либо невозможны, либо слишком дороги [2].
Инструментом решения проблемы может быть комплекс имитационных моделей, интегрированных с АСУ ТП [3]. Под интегрированностью понимается использование в моделях интерфейсов других подсистем АСУ ТП и исполнение моделей как составных частей АСУ ТП.
Таким образом, отладочный стенд АСУ ТП можно заменить более дешевым программным имитационным стендом для отладки и тестирования как системы управления в целом, так и для разработки, отладки и тестирования программ автоматического управления, выполняющихся в рамках подсистемы управления.
Основными задачами работы являются: исследование возможностей использования имитационного моделирования при разработке АСУ ТП и разработка имитационного стенда для отладки, тестирования и сопровождения подсистемы управления АСУ ТП Северо-муйского железнодорожного тоннеля.
2. Имитационный стенд
В минимальном объеме имитационный стенд должен содержать следующие программные компоненты:
— набор основных подсистем АСУ ТП, обеспечивающих исполнение подсистемы управления;
— подсистему управления АСУ ТП;
— систему моделирования, обеспечивающую исполнение имитационных моделей в условном модельном времени;
— комплекс имитационных моделей.
Имитационный стенд может быть реализован как на одном компьютере, так и на локальной сети компьютеров, входящих в АСУ ТП. В случае локальной сети имитационные модели могут исполняться либо на специально выделенном для имитации компьютере, либо на одной из рабочих станций АСУ ТП, либо на нескольких станциях, если система моделирования поддерживает распределенное исполнение имитационных моделей.
Имитационные модели могут заменять некоторые неосновные подсистемы АСУ ТП и внешнюю среду АСУ ТП, включающую управляющий персонал и ТОУ. В зависимости от состава имитационных моделей имитационный стенд может использоваться на различных этапах жизненного цикла АСУ ТП и выполнять различные функции, рассмотренные ниже.
2.1. Инструментальная среда разработки, отладки и тестирования
Имитационный стенд может использоваться в качестве инструментальной среды для разработки, отладки и тестирования подсистемы управления и программ управления, а также других подсистем АСУ ТП. Технология использования имитационного стенда в этом качестве состоит в переносе отлаженных программ из имитационного стенда в реальную систему без изменений кода программ, так как любые изменения требуют дополнительных отладочных действий.
Все необходимые изменения сначала тестируются на имитационном стенде, и лишь после этого программы переносятся в реальную систему. Для того чтобы программы "не замечали" разницы в среде исполнения, имитационный стенд должен содержать следующие модели:
— пополняемую библиотеку моделей объектов оборудования;
— модель внешней среды;
— модель имитации значений входных сигналов АСУ ТП;
— модель диспетчера.
Модель объекта оборудования должна иметь одинаковый с реальным объектом набор входных и выходных сигналов, одинаково реагировать на изменения входных сигналов (команд управления) с воспроизведением (если требуется) задержки выполнения команды в модельном времени.
Использование модели объектов оборудования позволяет протестировать программы управления для всех ситуаций как с "исправным", так и с "неисправным" оборудованием, что не всегда возможно в реальной системе.
Для тестирования программ управления требуется обратная связь — влияние работающих объектов оборудования на контролируемые АСУ ТП параметры. Такую обратную связь может обеспечить модель внешней среды, включенная в имитационный стенд. Чем качественнее модель внешней среды, тем более качественные отладку и тестирование программ управления можно осуществить на имитационном стенде.
Модель имитации значений входных сигналов АСУ ТП задает значения входных параметров для модели внешней среды, которые не зависят от функционирования АСУ ТП.
Простая модель диспетчера (человека, осуществляющего контроль и управление АСУ ТП) также может упростить некоторые этапы тестирования, например последова-
тельный перебор каких-то простых действий диспетчера. Модель диспетчера не является обязательной частью имитационного стенда.
Хотя полную проверку АСУ ТП можно осуществить только на реальной системе, значительную часть работы по внедрению системы можно осуществить на имитационном стенде, который более доступен, чем реальная система.
2.2. Тренажер
Имитационный стенд может использоваться в качестве тренажера. Если в набор основных подсистем АСУ ТП для имитационного стенда включена подсистема визуализации, то все действия диспетчера, результаты работы автоматических программ управления и результаты работы моделей, включенных в имитационный стенд, будут визуализироваться на мониторе диспетчера точно так же, как и в реальной системе в определяемом моделями объеме.
Если имитационный стенд установлен на одном компьютере, то тренажер может быть использован для демонстрации работы системы и для обучения диспетчеров.
Демонстрация может осуществляться либо в форме запуска специальной программы — Демо-версии, либо в форме сеанса работы с системой, выполняемой подготовленным специалистом.
В обучение диспетчеров входит освоение следующих основных операций:
— изучение интерфейса автоматизированного рабочего места (АРМ) диспетчера;
— выполнение операций (включение, отключение и т. п.) с отдельными объектами оборудования и группами объектов;
— выполнение технологических операций, требующих выполнения последовательности действий в определенном порядке.
Возможны различные виды обучения:
— самоподготовка с использованием руководства пользователя;
— подготовка в учебном классе под руководством инструктора;
— выполнение контрольных работ по заданному сценарию;
— выполнение диспетчером поставленной задачи с автоматическим отслеживанием порядка действий диспетчера и оценкой качества его работы.
Если имитационный стенд установлен на локальной сети АСУ ТП, то появляются дополнительные возможности для обучения диспетчеров. Одна из них — возможность изучения диспетчером интерфейса со всеми подсистемами АСУ ТП, а не только с АРМ диспетчера. Другая — интерактивное взаимодействие с инструктором. Инструктор на отдельном рабочем месте может задавать значения параметров, имитируя различные ситуации, в том числе и аварийные, наблюдая за действиями диспетчера. Такая форма взаимодействия может использоваться как для обучения, так и для аттестации диспетчеров.
2.3. Подсистема АСУ ТП на этапах пусконаладки и опытной эксплуатации
Имитационный стенд может использоваться в качестве подсистемы АСУ ТП на этапах пусконаладки и опытной эксплуатации АСУ ТП. Процесс подключения реального оборудования ТОУ может быть растянутым во времени на этапах пусконаладки и опытной эксплуатации АСУ ТП. При этом готовую подсистему управления и программы управления
АСУ ТП приходится искусственно ограничивать объемом доступного в данный момент реального оборудования, а затем расширять по мере подключения нового оборудования.
Другим подходом является перенос полной версии подсистемы управления и программ управления с имитационного стенда на неполную конфигурацию подключенного реального оборудования. При этом часть объектов управления являются реальными, а часть неподключенных объектов управления заменяются модельными объектами.
Такой подход имеет следующие преимущества:
— устраняются промежуточные этапы по настройке программного обеспечения под конфигурацию реального оборудования;
— становится возможной проверка программ управления в полном объеме параллельно с процессом подключения реального оборудования;
— становится возможной проверка других подсистем АСУ ТП на полном множестве входных сигналов параллельно с процессом подключения реального оборудования;
— происходит адаптация диспетчера к полному интерфейсу с АСУ ТП на более ранних этапах.
Перечисленные действия сокращают общие сроки пуска АСУ ТП в эксплуатацию.
2.4. Подсистема АСУ ТП на этапе эксплуатации
Имитационный стенд может использоваться в качестве подсистемы АСУ ТП на этапе эксплуатации. На этапе эксплуатации АСУ ТП все модельные объекты управления заменены на реальные объекты. Наиболее перспективно использование на этом этапе модели внешней среды.
Модель внешней среды выполняется параллельно с работой АСУ ТП. Входными данными модели являются текущие значения наиболее важных параметров, контролируемых АСУ ТП, и текущее состояние объектов управления АСУ ТП. Целью выполнения модели является прогнозирование во времени состояния контролируемых параметров в зависимости от внешних событий и действий (или бездействия) диспетчера.
Для выполнения этой цели исполнение модели должно происходить в темпе, намного превышающем реальное время. Если выполнение модели требует значительных вычислительных ресурсов, то опережающее по сравнению с реальным временем исполнение модели может обеспечить распределенная имитация. Для этого система моделирования должна иметь средства поддержки параллельного и распределенного моделирования. При этом передача информации между подмоделями, выполняемыми на различных узлах сети АСУ ТП, может осуществляться в форме передачи сигналов и быть реализована с помощью подсистемы передачи сигналов АСУ ТП.
Если выполнение модели внешней среды может осуществляться на любой станции АСУ ТП, то визуализацию результатов моделирования целесообразно осуществлять на отдельном рабочем месте с тем, чтобы диспетчер имел возможность наблюдать как текущее, так и "будущее" состояние ТОУ.
Одной из обязательных подсистем АСУ ТП является подсистема архивирования. В архиве хранится "история" состояния ТОУ, в частности значения параметров, контролируемых АСУ ТП, в дискретные моменты времени или значения параметров, усредненные за некоторые промежутки времени. Модель также может сохранять свои результаты с временными отметками, "будущими" по сравнению с текущим значением реального времени, с помощью подсистемы архивирования АСУ ТП.
Поскольку недалекое "будущее" через некоторое время становится "историей", появляется возможность сравнения результатов моделирования с реальными значениями параметров. Ручное выборочное сравнение может оказаться полезным разработчику модели для обнаружения ошибок или улучшения качества моделирования.
Наиболее интересным является автоматическое сравнение результатов моделирования с реальными значениями контролируемых АСУ ТП параметров для продолжительных периодов времени с оценкой меры "близости" моделируемых и реальных значений параметров.
Численное значение меры "близости" может служить:
— средством аттестации модели, характеризовать качество моделирования;
— "обратной связью" для самой модели с целью самонастройки и, возможно, самообучения модели.
Часто параметры самой модели, например не измеряемые физические характеристики внешней среды или коэффициенты используемых распределений случайных величин, нельзя указать точно, а можно лишь определить диапазон их изменений. В этом случае обычно используются средние значения таких параметров.
Модель, пользуясь обратной связью, могла бы динамически изменять такие параметры в пределах заданного диапазона. Целевой функцией такого изменения может быть минимизация меры "близости". В качестве примера механизма реализации может служить хорошо изученная теория и практика программного автоматического регулирования. Реализация такой модели облегчается, если используемая система моделирования поддерживает интеллектуальное имитационное моделирование.
Разработка интегрированной с АСУ ТП модели внешней среды имеет следующие преимущества по сравнению с разработкой автономной модели:
— возможность использования других подсистем АСУ ТП;
— исключение разработки трудоемких, но второстепенных функций модели, таких как ввод входных данных, оперативная визуализация результатов моделирования, обработка и хранение полных результатов моделирования;
— возможность сосредоточить усилия на реализации первостепенных функций модели, таких как правильность и быстродействие имитации, интеллектуальных возможностях модели.
Использование интегрированной с АСУ ТП модели, включенной в оперативный контур управления, позволяет:
— квалифицировать действия диспетчера;
— предупреждать о нежелательном развитии технологического процесса, возникновении нештатных или аварийных ситуаций;
— выбирать наиболее оптимальный режим управления, связанный с экономией каких-либо ресурсов, например электроэнергии.
В идеале для крупномасштабных АСУ ТП любое управляющее действие диспетчера должно проходить предварительную проверку на модели.
2.5. Интеллектуальный эксперт
Имитационный стенд может использоваться в качестве интеллектуального "эксперта" для наполнения базы знаний. Выполнение модели в оперативном контуре управления АСУ ТП может ответить на вопрос: "Что произойдет?" Но модель не может ответить на вопрос: "Что делать диспетчеру?" Диспетчер в своей деятельности может руководствоваться:
— должностной инструкцией и другими нормативными документами;
— личным опытом и квалификацией;
— подсказками экспертной системы, разработанной для поддержки принятия решений при эксплуатации ТОУ.
Основой экспертной системы является база знаний по эксплуатации ТОУ. Классическим источником данных для базы знаний являются знания экспертов по эксплуатации ТОУ. Другим источником "знаний" могут стать результаты выполнения модели.
Для некоторого набора стандартных ситуаций нет необходимости каждый раз запускать выполнение модели в оперативном контуре управления. Выполнение модели может быть сделано предварительно, а статистически обработанные результаты моделирования могут быть включены в базу знаний.
Знания, полученные в результате моделирования, могут быть овеществлены либо в виде подсказок или рекомендаций диспетчеру при возникновении определенных ситуаций, требующих вмешательства диспетчера, либо в виде запуска программ автоматического управления в ситуациях, когда требуется быстрая реакция, на которую не способен человек.
3. Краткое описание объекта управления
Северомуйский железнодорожный тоннель Восточно-Сибирской железной дороги (СМТ) расположен на 1355-1370 км Байкало-Амурской магистрали и имеет длину 15 343 м. Он пересекает центральную часть Северомуйского хребта в районе Ангараканского седла (северо-восток Республики Бурятия). Это самый длинный в России железнодорожный тоннель, он входит в первую десятку самых длинных железнодорожных тоннелей в мире (см. таблицу).
Северомуйский тоннель находится в эксплуатации с декабря 2003 года. До этого времени движение по Байкало-Амурской магистрали происходило по сложной внешней объездной дороге. Эффективность пуска в эксплуатацию СМТ можно охарактеризовать следующими показателями: время проезда состава по тоннелю (15.3 км) равно 15 мин, а время проезда состава по внешней объездной дороге (54.3 км) — 2.5 ч. Таким образом, пуск СМТ увеличил пропускную способность Байкало-Амурской магистрали на порядок.
Северомуйский тоннель является сложным инженерным сооружением. Высота Северо-муйского хребта 1800 м над уровнем моря. Максимальная глубина тоннеля от поверхности
Самые протяженные тоннели мира
Название Место Длина, Число
тоннеля км путей
Сейкан Пролив Цугару (о. Хоккайдо — о. Хонсю), Япония 53.8 2
Евротоннель Пролив Ла-Манш, Англия — Франция 49.8 2
Дайсимидзу Токио — Ниигата, Япония 22.2 2
Симплон Альпы. Швейцария — Италия 19.8 1
Син-Каммон Пролив Каммон (о. Хонсю — о. Кюсю), Япония 18.7 2
Апеннинский Болонья — Флоренция, Италия 18.5 2
Рокко Осака — Кобе, Япония 16.2 2
Фурка Кур — Бриг, Швейцария 15.4 1
Северомуйский Нижнеангарск — Чара, Россия 15.3 1
около 1000 м. Среднее сечение тоннеля 18 м2. За время строительства тоннеля (с апреля 1977 года по декабрь 2004 года) пройдено 45 км выработки и вынуто 3 млн м3 грунта.
Тоннель имеет двускатный профиль с превышением Западного портала над Восточным на 49 м. Превышение наиболее высокой точки профиля тоннеля над Восточным порталом 65 м. К тоннелю примыкают четыре вертикальные вентиляционные шахты (стволы) с глубинами соответственно 316, 356, 166 и 200 м с разветвленной сетью околоствольных выработок. Параллельно и чуть ниже транспортного тоннеля проходит выработка меньшего сечения — транспортно-дренажная штольня, соединенная с основным тоннелем системой переходов (сбоек). Штольня используется для технического обслуживания транспортного тоннеля.
На эксплуатацию СМТ влияет ряд негативных факторов:
— воздействие сурового климата, приравненного по степени суровости к субарктическому;
— вечная мерзлота;
— высокая сейсмичность — до 10 баллов по 12-балльной шкале;
— большой приток подземных вод;
— выход термальных вод с температурой 60-70 °С;
— выделение радона.
Для поддержания параметров микроклимата в тоннеле в допустимых пределах на его порталах и стволах тоннеля установлено большое количество технологического оборудования: вентиляторов — 34 единицы, калориферов — 55 единиц, около 100 единиц запорного, осветительного и другого оборудования.
Масштаб технологического оборудования можно оценить по энергопотреблению тоннеля, мощность которого составляет 7 МВт, что соответствует электропотреблению города с населением 35 тыс. человек.
Технологическое оборудование используется для выполнения следующих функций:
— обеспечения безопасного движения железнодорожных составов внутри тоннеля;
— поддержания климатических параметров воздушной среды (обогрев тоннеля в целях предотвращения обмерзания обделки и образования наледей на железнодорожном пути в холодный период);
— проветривания тоннеля с целью поддержания нормируемых параметров состояния воздушной среды во всех подземных выработках и сооружениях в пределах ПДК;
— устранения нештатных ситуаций.
Эффективное управление таким сложным и уникальным объектом, как СМТ, невозможно без современной АСУ ТП.
4. Краткое описание АСУ ТП Северомуйского тоннеля
Для управления технологическими процессами в Северомуйском тоннеле в КТИ ВТ СО РАН разработана АСУ ТП СМТ [4].
АСУ ТП СМТ обрабатывает более 2500 входных и выходных сигналов. Основными задачами АСУ ТП являются:
— обеспечение безопасной и безаварийной эксплуатации СМТ;
— управление работой технологического оборудования;
— поддержание параметров микроклимата внутри СМТ в заданных пределах;
Верхний уровень
Локальная сеть
Нижний уровень
Рис. 1. Структура программно-технологического комплекса АСУ ТП СМТ (АРМ — автоматизированное рабочее место, ПК — программируемый контроллер).
— снижение эксплуатационных расходов, улучшение и облегчение условий работы обслуживающего персонала;
— обнаружение, предотвращение и скорейшее устранение нештатных ситуаций.
Программно-технический комплекс (ПТК) АСУ ТП СМТ представляет собой двухуровневый набор вычислительных средств. На верхнем уровне находятся рабочие станции Pentium Ш (Windows 2000) и Сервер — кластер на базе двух станций SUN (Solaris 2.8).
На нижнем уровне находятся 10 программируемых контроллеров (ПК) на базе семейства MicpoPC (Fastwel, Advantech) с операционной системой QNX-4.25 и устройства сопряжения с объектом (Advantech, Grayhill). Все вычислительные средства АСУ ТП СМТ объединены дублированной (оптоволокно и медь) локальной сетью. Структура ПТК АСУ ТП СМТ представлена на рис. 1.
АРМ диспетчера обеспечивает визуализацию состояния объектов оборудования и значений технологических параметров на мнемосхемах, прием команд управления диспетчера, отражение динамики изменения технологических параметров в виде графиков.
На экран сигнализации выводится список текстовых сообщений для диспетчера от программ управления и других подсистем АСУ ТП с указанием степени важности сообщения.
На Сервере хранятся базы данных АСУ ТП, архив истории изменения значений технологических параметров, протокол действий диспетчера. Кроме этого, Сервер обеспечивает целостность и отказоустойчивость системы в целом.
АРМ инженера предназначено для диагностики средств автоматизации и программного обеспечения, а также для сопровождения и развития АСУ ТП.
В программируемых контроллерах исполняются программы, обеспечивающие связь с устройствами сопряжения с объектом (УСО) и сетью, программы первичной обработки сигналов, программы управления.
5. Подсистема управления АСУ ТП Северомуйского тоннеля
В АСУ ТП СМТ реализованы три взаимно исключающих режима управления объектами оборудования:
— местное управление. Ручное управление "по месту" расположения объекта оборудования;
— диспетчерское управление. Дистанционное управление отдельными объектами оборудования диспетчером с АРМ диспетчера;
— автоматическое управление. Управление группой объектов оборудования программой автоматического управления.
При любом режиме управления состояния объектов управления отображаются на мнемосхемах АРМ диспетчера. При отсутствии местного управления объектом диспетчер может выбрать для объекта режим автоматического или диспетчерского управления.
При режиме автоматического управления команды управления объекту посылает одна из программ автоматического управления. При этом режиме диспетчер не может вмешаться в ход управления. Единственное, что может сделать диспетчер, это установить режим диспетчерского управления объектом, т. е. взять управление "на себя".
При режиме диспетчерского управления диспетчер с помощью программного микропульта управления объектом посылает команды управления ("включить"/"отключить", "открыть"/"закрыть" и т.п.). Команды управления от программ автоматического управления при этом режиме блокируются.
Понятия диспетчерского и автоматического управления объектом управления распространяются также на программы автоматического управления, т. е. программы автоматического управления рассматриваются как виртуальные интеллектуальные объекты управления.
Примером программы автоматического управления является программа, автоматически включающая группу объектов оборудования (вентиляторов, калориферов) в порядке, соответствующем технологическим требованиям, для обеспечения заданного температурного режима в зимний период эксплуатации тоннеля.
Если программа управления находится в диспетчерском режиме, то диспетчер может запустить ее на исполнение. Если программа управления находится в автоматическом режиме, то программа запускается на исполнение автоматически при истинном значении некоторого логического выражения (логической функции), называемого условием запуска программы автоматического управления. Условием запуска может быть, например, определенное соотношение температуры наружного воздуха и температуры воздуха внутри тоннеля.
Если дизъюнкция условий запуска некоторого множества программ автоматического управления тождественно истинна для диапазона реальных температур, то автоматический запуск программ управления обеспечивает дискретное автоматическое регулирование параметров воздушной среды в тоннеле путем включения/отключения дополнительных тепловентиляционных мощностей (вентиляторов, калориферов) при понижении/повышении температуры наружного воздуха.
Программы автоматического управления кроме поддержания температуры внутри тоннеля в заданных пределах обеспечивают:
— вентиляцию тоннеля в случае превышения количества радона и других вредных примесей выше предельно допустимых концентраций;
-> Команды автоматики
..........................> Сигналы
-------------> Команды диспетчера
Рис. 2. Структура подсистемы управления АСУ ТП СМТ.
— действия при прохождении железнодорожного состава по тоннелю;
— действия по предотвращению и ликвидации аварийных ситуаций, например пожара.
Наличие двухступенчатой системы автоматического управления существенно облегчает и улучшает качество управления технологическими процессами в СМТ. Структура реализованной в АСУ ТП СМТ подсистемы управления представлена на рис. 2.
В АСУ ТП СМТ реализовано более 20 программ автоматического управления. Кроме того, имеется система технологического программирования для разработки новых программ автоматического управления. Система технологического программирования, называемая конструктором программ управления (КПУ), предназначена для сопровождающего АСУ ТП СМТ персонала, специалистов технологов, не имеющих опыта программирования на алгоритмических языках программирования или универсальных системах технологического программирования (1ваОга£, UltraLogic и др.).
Конструктор программ управления имеет простой оконный интерфейс для разработки, редактирования и хранения программ управления. Программа управления представляет собой последовательность команд, выполняемых в определенном порядке. Для удобства пользования имеются дополнительные языковые конструкции — подпрограммы и комментарии.
Команда содержит стандартные поля:
— технологическое обозначение объекта управления, на который направлена команда (клапан, вентилятор, калорифер и т.п.);
— действие команды ("открыть", "закрыть", "включить", "отключить" и т.п.);
— обозначение следующей для выполнения команды в случае успешного завершения выполнения текущей команды;
— обозначение следующей для выполнения альтернативной команды в случае неуспешного завершения выполнения текущей команды.
Конструктор программ управления контролирует заполнение полей команды и исключает появление синтаксических ошибок. Для каждого поля предлагается список в виде меню его возможных значений для выбора пользователем при создании новой команды или редактировании существующей команды.
Для упрощения выбора объекта управления пользователю предоставляется трехуровневая система меню. На первом уровне пользователь выбирает местоположение объекта управления (западный портал, ствол 1, ствол 2, ствол 3, ствол 4, восточный портал). На втором уровне пользователь задает тип объекта управления (вентилятор, калорифер, насос, клапан). На третьем уровне пользователю открывается список технологических обозначений объектов управления заданного типа с заданным местоположением.
Для каждого объекта в подсистеме управления имеется соответствующий программный модуль, исполняемый на том ПК (см. рис. 1), к которому подключены входные и выходные сигналы этого объекта управления. Чтобы не было перекрестной передачи сигналов между ПК, программа управления должна либо целиком исполняться на верхнем уровне, либо быть разделена на части, каждая из которых исполняется на отдельном ПК.
К части программы управления, исполняемой на некотором ПК, относятся команды управления объектами оборудования, подключенными к этому ПК. Конструктор программ управления обеспечивает разработку программы управления как единого целого. Пользователь не заботится о распределении программы управления по ПК. Конструктор программ управления автоматически генерирует распределенную по ПК программу управления на языке С+—Н. Эта программа без дополнительной ручной редакции транслируется и загружается на соответствующие ПК, а подсистема управления обеспечивает ее распределенное исполнение.
Также имеется возможность генерации нераспределенных (общих) программ управления. Такие программы выполняются на одном компьютере в рамках имитационного стенда или тренажера.
Для ускорения выполнения программы управления, а также если позволяют технологические правила, пользователь может пометить последовательность команд (подпрограмму) как блок параллельных команд. В этом случае подсистема управления обеспечивает параллельное выполнение этих команд. То есть последовательность команд исполняется не последовательно, а параллельно, а следующая за параллельным блоком команда начнет исполняться лишь только после того, как успешно завершится выполнение каждой команды параллельного блока.
Кроме программы управления КПУ обеспечивает разработку условия запуска программы управления в виде логического выражения в форме, приближенной к математической записи. Конструктор программ управления автоматически генерирует программу условия запуска на языке С+—Н. Подсистема управления обеспечивает автоматический запуск на выполнение программы управления в случае, если программа управления находится в автоматическом управлении и условие запуска принимает значение "истина". В сложных случаях условие запуска может быть запрограммировано на С+—Н вручную в виде функции с соблюдением некоторых правил оформления программы.
Для готовой программы управления КПУ может сгенерировать текст программы на технологическом языке в виде файла Microsoft Word в табличной форме, принятой для отчетности в СМТ.
Конструктор программ управления содержит следующие компоненты:
— оконный пользовательский интерфейс для интерактивного построения программ управления и условий запуска;
Рис. 3. Структура конструктора программ управления.
— архив для хранения разработанных программ управления;
— генератор кода для автоматической генерации исполняемого кода корректной программы управления и условий запуска на языке С+—Н;
— генератор отчетов для автоматической генерации текста программ управления и условий запуска в табличной форме в формате документа Microsoft Word.
Структура КПУ представлена на рис. 3.
6. Использование имитационного моделирования при разработке и пусконаладке подсистемы управления АСУ ТП СМТ
Особенностью разработки подсистемы управления АСУ ТП СМТ является одновременная разработка подсистемы управления и интегрированных с ней моделей. Эта одновременная разработка началась с этапа проектирования. По мере развития подсистемы управления развивались и усложнялись модели. В настоящее время разработка АСУ ТП СМТ находится на этапе пусконаладки. Сдача системы в опытную эксплуатацию предполагается совместно с комплексом моделей, которые будут использоваться для имитации временно отсутствующего реального оборудования и некоторых, невозможных на момент испытаний внешних условий, например зимних температур в летний период.
Для разработки и отладки подсистемы управления и других подсистем АСУ ТП СМТ был реализован имитационный стенд в составе: АРМ диспетчера, экрана сигнализации, подсистемы передачи сигналов, подсистемы управления, модели ТОУ, модели для имитации внешних сигналов, модели внешней среды.
Имитационный стенд был реализован в двух вариантах. В первом варианте все перечисленные компоненты исполняются на одном компьютере. Этот вариант используется в качестве персональной инструментальной среды разработчиков АСУ ТП СМТ для разра-
ботки, отладки и тестирования подсистем АСУ ТП СМТ, в частности разработки, отладки и тестирования подсистемы управления. Этот вариант используется также для демонстрации возможностей системы, реализации портативных демо-версий, в качестве тренажера с неполным набором функций.
Во втором варианте имитационный стенд был реализован на локальной сети верхнего уровня АСУ ТП. Подсистема управления и модели могли исполняться на любой станции верхнего уровня, а результаты моделирования визуализировались на АРМ диспетчера. Этот вариант обеспечил следующие возможности:
— комплексное тестирование системы в целом;
— использование имитационного стенда в качестве тренажера, максимально приближенного к реальной системе;
— развитие имитационного стенда в сторону подключения отдельных элементов нижнего уровня АСУ ТП СМТ.
Развитие состояло в подключении к локальной сети АСУ ТП СМТ двух ПК, к ним были подключены входные и выходные сигналы нескольких технических устройств, которые на аппаратном уровне имитировали работу реальных объектов управления. Такое развитие позволило:
— перенести подсистему управления в другую среду программирования (с Windows 2000/C++ Builder 5 на QNX — 4 .25/Watcom C++);
— протестировать программы управления с подключенными аппаратными имитаторами реальных объектов;
— облегчить перенос подсистемы управления на реальную систему на этапе пускона-ладки.
6.1. Модель технологического объекта управления
Модель ТОУ является неотъемлемой частью подсистемы управления. Она состоит из множества моделей объектов, соответствующих реальным объектам управления, которые на программном уровне имитируют работу реальных объектов управления.
Модельные объекты имеют идентичные с реальными объектами наборы сигналов. Имитация заключается в том, что модельный объект, находясь в некотором состоянии (например, соответствующем выключенному вентилятору), получив некоторую команду от диспетчера или программы автоматического управления (например, команду "включить"), изменяет свое состояние и генерирует, возможно, с задержкой в модельном времени новые значения сигналов (например, соответствующие включенному вентилятору) точно так же, как это происходит при выполнении команды в реальном объекте управления.
Поскольку реальный и соответствующий модельный объекты имеют идентичный (по составу и значениям) набор сигналов и одинаковый интерфейс, подсистема управления и программы автоматического управления не обнаруживают разницы между реальным и модельным объектом управления. Это дает возможность переносить подсистему управления и программы управления с имитационного стенда на реальную систему и обратно без изменения кода программ, т. е. без дополнительной отладки.
Переход от модельного объекта к реальному и обратно осуществляется простой модификацией одного поля в конфигурационной таблице объектов в базе данных АСУ ТП СМТ.
На имитационном стенде, использующемся в качестве тренажера, все объекты управления — модельные. На реальной системе на этапе пусконаладки АСУ ТП СМТ работает
на "гибриде" реального и модельного оборудования. По мере физического подключения реального оборудования производится переход от соответствующих модельных объектов к реальным.
Наличие промежуточного (гибридного) состояния позволяет тестировать (проводить испытания) программы автоматического управления, подсистемы управления и другие подсистемы АСУ ТП СМТ, не дожидаясь подключения полной конфигурации реального оборудования, что сокращает общие сроки ввода АСУ ТП СМТ в эксплуатацию.
6.2. Модель для имитации внешних сигналов
Сигналы, поступающие в АСУ ТП СМТ, делятся на аналоговые и дискретные. Аналоговый сигнал — это значение какого-нибудь контролируемого АСУ ТП СМТ параметра (температура, скорость потока воздуха, содержание радона и т. п.). Значение аналогового сигнала — вещественное число в единицах измерения соответствующего параметра. Аналоговый сигнал — самодостаточная единица информации для АСУ ТП.
Дискретный сигнал — это значение какого-нибудь контролируемого АСУ ТП СМТ признака. Значение дискретного сигнала — целое число 0 или 1. Каждый реальный объект (контролируемый или управляемый) представлен в АСУ ТП СМТ группой дискретных сигналов. Например, вентилятор ВОМД-24А имеет 12 дискретных сигналов ("местное управление есть", "прямой ход включен", "шибер открыт" и т. д.). В отличие от аналогового сигнала рассматривать изолированно один дискретный сигнал не имеет смысла. Контролируемый объект — это объект, для которого не предусмотрена возможность управления средствами АСУ ТП СМТ, но состояние которого визуализируется на мнемосхеме.
Подсистема управления, получив значения группы дискретных сигналов, соответствующих некоторому объекту, определяет его состояние, которое визуализируется на мнемосхеме. Наличие несогласованных значений группы дискретных сигналов, соответствующих некоторому объекту, квалифицируется как неисправность этого объекта.
Источником аналоговых и дискретных сигналов является подсистема первичной обработки информации, которая формирует значения аналоговых и дискретных сигналов на основе данных от соответствующих датчиков, а затем с использованием определенного интерфейса и в определенном формате передает значения сигналов другим подсистемам АСУ ТП СМТ.
Модель для имитации внешних сигналов (модель ИВС) формирует значения аналоговых и дискретных сигналов, а затем передает их другим подсистемам АСУ ТП СМТ в том же формате и с использованием того же интерфейса, что и подсистема первичной обработки информации. Таким образом, подсистема управления и другие подсистемы АСУ ТП СМТ не различают реальные и модельные сигналы.
В АСУ ТП СМТ часть входных сигналов может быть реальными, а другая часть — модельными. Переход от реального сигнала к модельному и обратно осуществляется простой модификацией одного поля в конфигурационной таблице сигналов в базе данных АСУ ТП СМТ.
Модель ИВС формирует независимые значения каждого аналогового сигнала по индивидуальной для этого сигнала программе. В простейшем случае значение аналогового сигнала вычисляется по заданной функции через постоянные промежутки модельного времени.
Модель ИВС для аналоговых сигналов используется:
— при тестировании подсистем АСУ ТП СМТ, которые должны реагировать на критические значения аналоговых сигналов;
— в тренажере для создания эффекта реальности.
Модель ИВС формирует состояние ("включено", "отключено" и т.п.) для каждого контролируемого или управляемого объекта путем задания определенного набора значений для группы дискретных сигналов, связанных с этим объектом.
Модель ИВС для объектов используется:
— при тестировании подсистем АСУ ТП СМТ, которые должны реагировать на определенные состояния (в том числе и на неисправность) контролируемых и управляемых объектов;
— в тренажере для задания инициализации всех объектов. Сценарии инициализации могут быть разными, например, при инициализации все ворота и клапаны закрыты, а все вентиляторы и калориферы отключены.
Модель ИВС не учитывает влияние аналоговых сигналов и/или объектов друг на друга, но она является базой для разработки более сложных моделей, которые моделируют взаимосвязь аналоговых сигналов и/или объектов.
6.3. Модель микроклимата тоннеля
Основная задача АСУ ТП СМТ — поддержание параметров микроклимата внутри Севе-ромуйского тоннеля в заданных пределах. Технологическое оборудование тоннеля рассчитано на эксплуатацию в самых экстремальных условиях: температура наружного воздуха до минус 50 °С, уровень радиации — во много раз превосходящий ПДК, наличие пожара. Этот расчет основывался на результатах моделирования, проведенного с использованием данных проектирования [5].
В более благоприятных условиях при эксплуатации тоннеля возникает задача оптимального использования оборудования. Целевой функцией для решения этой оптимизационной задачи является минимизация расхода электроэнергии при выполнении необходимых технологических и санитарных условий внутри тоннеля.
Для решения этой задачи возникла потребность разработки новой модели микроклимата СМТ с учетом требований:
— реализация модели с использованием реальных данных о топологии, оборудовании и режимах эксплуатации тоннеля;
— возможность развития и сопровождения модели;
— интегрированность с АСУ ТП СМТ;
— оценка влияния природных и эксплуатационных факторов на параметры микроклимата тоннеля. К природным факторам относятся метеорологические условия на порталах тоннеля. К эксплуатационным — количество и производительность включенного технологического оборудования, движение железнодорожного состава внутри тоннеля;
— возможность проверки действия программ автоматического управления на параметры микроклимата тоннеля;
— определение оптимальных условий запуска программ автоматического управления;
— возможность исполнения модели в рамках тренажера и в оперативном контуре управления АСУ ТП СМТ.
В настоящее время реализована базовая версия модели микроклимата. Она основывается на моделях технологического объекта управления и ИВС. Было выполнено моделирование микроклимата тоннеля в течение одного зимнего месяца (февраля).
В модели микроклимата реализованы следующие три основных процесса.
Параметры наружного воздуха. В этом процессе имитируются значения параметров атмосферного воздуха: температуры, давления, скорости и направления ветра в точках выхода подземных коммуникаций тоннеля на поверхность (западный портал, восточный портал, ствол 2). В модели микроклимата используется значение угла между направлением ветра и осью тоннеля.
Значения параметров наружного воздуха на порталах тоннеля задавались таблично через каждый моделируемый час на основе средних значений, наблюдаемых за многолетний период. Кроме того, использовались значения параметров наружного воздуха, зафиксированные с 3 по 9 февраля 2004 года.
В варианте модели для тренажера некоторые параметры наружного воздуха пользователь может задавать самостоятельно. Все значения параметров визуализируются на мнемосхеме тоннеля.
Значения параметров наружного воздуха используются в процессе "Параметры воздуха в тоннеле". Порталы тоннеля выходят на разные склоны Северомуйского хребта с существенно отличающимися погодными условиями и разными высотами над уровнем моря. Эта разница создает эффект естественной тяги внутри тоннеля, который учитывает процесс "Параметры воздуха в тоннеле". Значения температур воздуха на порталах входят в качестве аргументов в условия запуска большинства программ автоматического управления.
Движение через тоннель. В этом процессе имитируется движение с соблюдением масштаба времени железнодорожного состава через тоннель (открытие/закрытие портальных ворот, положение железнодорожного состава на блок-участках тоннеля, состояние проходных и заградительных светофоров). Этот процесс визуализируется на мнемосхеме тоннеля в виде анимационного фильма.
Движение железнодорожных составов через тоннель имитируется по реальному расписанию, зафиксированному с 3 по 9 февраля 2004 года, или циклически со средним значением, вычисленным по реальному расписанию, — 9 пар (в восточном и западном направлениях) железнодорожных составов в сутки.
Движение железнодорожного состава через тоннель создает "поршневой" эффект, который учитывается в процессе "Параметры воздуха в тоннеле" как движущийся источник тяги. Кроме того, появление железнодорожного состава вызывает выполнение условий запуска некоторых программ автоматического управления.
Параметры воздуха в тоннеле. В этом процессе рассчитывается распределение потоков воздуха и температур в выработках тоннеля.
Тоннель представляет собой сложную гетерономную вентиляционную сеть. Расчет распределения потоков воздуха и депрессии для гетерономных вентиляционных сетей производится на основе полного квадратичного закона сопротивления [6]
где Q — поток воздуха, Н — депрессия, Я1 и Я2 — сопротивления.
Для практического расчета распределения потоков воздуха тоннель представлен в виде неориентированного графа, имеющего т узлов п вершин.
В вентиляционной сети с т узлами и п ветвями распределение потоков воздуха определяется системой алгебраических уравнений на основе первого и второго законов сетей:
н = я^2 + ад,
(1)
п
г= 1
Это уравнение неразрывности потоков воздуха относительно j-го узла сети, где Qг — величина потока воздуха в ветви г и
(+1, если по ветви г поток воздуха входит в узел j;
— 1, если по ветви г поток воздуха выходит из узла j;
0, если ветвь г не связана с узлом j.
Приведем уравнения для алгебраической суммы потерь депрессии в j-м независимом замкнутом контуре вентиляционной сети
п
^Фэ(гЖ^2 + г2^г — кг) = 0, j = 1, 2,..., п — т + 1, (3)
г=1
где Qг — величина потока воздуха в ветви г; кг — депрессия в ветви, развиваемая источником тяги (вентилятором, движущимся железнодорожным составом или естественной тягой).
Некоторое направление в контуре выбирается в качестве основного, и
+1, если движение воздуха по ветви г совпадает с основным направлением контура j; Фэ (г) = —1, если движение воздуха по ветви г противоположно основному направлению контура j; 0, если ветвь г не связана с контуром j.
Термодинамические параметры атмосферного воздуха, создающие естественную тягу, и работа вентиляторов рассматривались как источники постоянной депрессии отдельных ветвей вентиляционной сети. Поршневой эффект проходящего железнодорожного состава также рассматривался как источник постоянной депрессии, но перемещающийся с постоянной скоростью. Состояние заградительной арматуры так же влияет на величины депрессий отдельных ветвей, но не непосредственно, как, например, источники тяги, а опосредованно за счет изменения аэродинамических сопротивлений ветвей.
Северомуйский тоннель имеет сложную топологию (п = 47, т = 32). Вычисление потоков воздуха Q производилось с точностью 0.1 м3/с, что вполне достаточно для практического использования.
Температура в средних областях тоннеля имеет постоянное, не зависящее от времени года значение: +5-7 °С. Это обусловлено геотермическими условиями, в частности выходом горячих подземных вод. Поэтому значения температур вычисляются для частей тоннеля, прилегающих к портальным воротам. Температура в этих частях по технологическим условиям должна быть не ниже 2 °С. Аварийным значением температуры в при-портальных частях является температура 0 °С и ниже.
Результаты моделирования на реальных исходных данных показали, что в среднем температура в припортальных частях на 3-5 °С выше, чем требуется. Эти результаты согласуются и с реальными значениями температур. Следовательно, по сравнению с использованными режимами эксплуатации тепловентиляционного оборудования можно уменьшить количество вырабатываемого тепла, а значит, сэкономить электроэнергию. Полученные результаты стали основанием для уточнения условий запуска программ автоматического управления тепловентиляционным оборудованием.
В дальнейшем предполагается развитие и уточнение модели микроклимата, в частности значений аэродинамических сопротивлений. С использованием той же техники пред-
полагается разработка моделей для нештатных и аварийных ситуаций (повышенная радиоактивность, возникновение пожара).
6.4. Система имитационного моделирования МЕРА
Модель микроклимата реализована в рамках системы имитационного моделирования МЕРА [7], которая является самостоятельной разработкой и не входит в состав программного обеспечения АСУ ТП СМТ.
Входной язык системы МЕРА является процессно-ориентированным языком дискретного имитационного моделирования, реализованным как объектно-ориентированная библиотека на языке С++. Входной язык обеспечивает взаимодействие процессов с помощью механизма передачи сообщений, построение иерархических моделей, динамическое изменение структуры модели.
Особенностью системы моделирования МЕРА является то, что имеется семейство совместимых по входному языку реализаций для разных операционных сред: МЕРА-W — для Windows, МЕРА-D (Distributed) — для суперкомпьютеров Siemens EC RM-600 и МВС 1000/М. Модели могут быть перенесены из квазипараллельной реализации на Windows в распределенную или параллельную реализацию для сокращения времени моделирования без изменения программ процессов.
Кроме того, система моделирования МЕРА предоставляет возможность моделирования в реальном масштабе времени. Масштаб задается в качестве параметра модели. Моделирование происходит в условном модельном времени W. Время исполнения модели T — реальное время, которое связано с модельным временем простым соотношением
AT = SAW,
где AW — интервал модельного времени, S — масштаб, AT — интервал реального времени.
Если, например, единицей модельного времени является одна минута, а S равно 1/20, то моделирование одного часа (60 мин) займет 3 мин реального времени. Если масштаб не задан, то время моделирования одного часа зависит от сложности модели, загрузки процессора и т. п. и может составить миллисекунды.
Поэтому модель микроклимата тоннеля в исполнении для тренажера выполняется в реальном масштабе времени (с искусственной задержкой) для возможности наблюдения за процессом ее выполнения на мнемосхеме тоннеля. Та же самая модель в исполнении для оперативного контура управления АСУ ТП СМТ должна исполняться без задержки и даже быть распределенной по станциям верхнего уровня АСУ ТП СМТ в случае, если время выполнения модели неудовлетворительно.
В системе МЕРА имеется возможность задавать разные коэффициенты для разных периодов модельного времени. Например, в модели микроклимата тоннеля реализованы "замедление" моделирования при подходе железнодорожного состава к тоннелю и прохождении его через тоннель для удобства наблюдения за визуализацией модели и "ускорение" моделирования в период между движениями железнодорожных составов.
Использование имитационного моделирования при разработке подсистемы управления и программ автоматического управления АСУ ТП СМТ на всех этапах жизненного цикла АСУ ТП СМТ, начиная от проектирования, отладки на имитационном стенде, тестирования на реальной системе, на этапе пусконаладки показало хорошие результаты применения этого метода, позволило реализовать подсистему управления качественно и в срок. Опыт
применения имитационного моделирования может быть использован при разработке других сложных систем.
Список литературы
[1] Окольнишников В.В. Информационно-функциональная модель АСУ ТП // Системное моделирование: Сб. науч. тр. / РАН. Сиб. отд-ние. ИВМиМГ. 1998. Т. 5 (23). С. 123-139.
[2] Прицкер А. Введение в имитационное моделирование и язык СЛАМ-2. М.: Мир, 1987.
[3] Okol'nishnikoy V.V., Rüdometoy S.W. Distributed simulation system integrated into control system // Proc. of 13th Europ. Simulation Multiconference. Vol. 2. Warsaw, 1999. P. 510512.
[4] АСУ ТП Северомуйского тоннеля: Технический проект / Новосибирск: Конструкторско-технологический институт вычислительной техники СО РАН, 2001.
[5] Гендлер С.Г. Выполнение имитационного моделирования воздействия климатических и эксплуатационных факторов на вентиляционный режим Севермуйского тоннеля и оценка эффективности различных средств управления его параметрами. СПб.: Санкт-Петербург. гос. горный институт. Хоздоговор 20/2001, 2002.
[6] Вассерман А.Д. Проектные обоснования параметров вентиляции рудников и подземных сооружений. Л.: Наука, Ленингр. отд-ние, 1988.
[7] Окольнишников В.В. Система распределенного имитационного моделирования // Тр. Первой Всерос. науч. конф. "Методы и средства обработки информации". М.: МГУ им. М.В. Ломоносова, 2003. С. 468-473.
Поступила в редакцию 10 июня 2004 г., в переработанном виде — 9 июля 2004 г.
