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

Вид материала

Автореферат

Содержание Общая характеристика работы Цели работы Научная новизна Практическая значимость Апробация работы и публикации. Структура и объем диссертации. Содержание работы Во второй главе В главе три В четвертой главе Глава 5 посвящена Основные результаты и выводы

Подобный материал:

• Iii международный симпозиум актуальные проблемы компьютерного моделирования конструкций, 77.34kb.
• С. Е. Власов оптимальное распределение ресурсов в задача, 114.88kb.
• Язык описания алгоритмов начертательной геометрии adgl, 70.57kb.
• Управления, 35.34kb.
• Лекция Информационно-справочные системы, асу и сапр, 186.98kb.
• Программа курса лекций, 41.58kb.
• К автоматизации моделирования распределенных систем с помощью Марковских процессов, 133.26kb.
• Город Заречный Свердловской области Вдоклад, 30.18kb.
• Разработка case-инструментов как Web-приложений, 90.06kb.
• Генераторы стратегий управления (гсу) программные средства, предназначенные для повышения, 7.48kb.

На правах рукописи


Айзатулин Амир Исмаилович


СРЕДСТВА МОДЕЛИРОВАНИЯ И ПРОЕКТИРОВАНИЯ АЛГОРИТМОВ

АСУ ТП ЭНЕРГОБЛОКА АЭС

И СИСТЕМА ВИЗУАЛИЗАЦИИ И УПРАВЛЕНИЯ ДЛЯ МОДЕЛИРУЮЩИХ ПРОГРАММНЫХ КОМПЛЕКСОВ


Специальность 05.14.03. – ядерные энергетические установки, включая проектирование, эксплуатацию и вывод из эксплуатации


АВТОРЕФЕРАТ


диссертации на соискание ученой степени

кандидата технических наук


Москва

2006

Работа выполнена в ОАО «Всероссийский научно-исследовательский институт по эксплуатации атомных электростанций» (ВНИИАЭС)


Научный руководитель доктор технических наук, с.н.с.

Селезнёв Евгений Федорович


Официальные оппоненты: доктор физико-математических наук

Зизин Михаил Николаевич

кандидат физико-математических наук

Кочанов Виктор Алексеевич


Ведущая организация: Обнинский государственный

технический университет атомной энергетики (ИАТЭ)


Защита диссертации состоится «20» декабря 2006 г. в 13 час. 00 мин. на заседании диссертационного совета К201.001.01 во Всероссийском научно-исследовательском институте по эксплуатации атомных электростанций по адресу: 109507, Москва, ул. Ферганская, д. 25, ауд. 614.


С диссертацией можно ознакомиться в библиотеке ВНИИАЭС.


Автореферат разослан «17» ноября 2006 г.


Ученый секретарь

диссертационного совета,

кандидат технических наук, с.н.с. Б.Я.Березин

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

Введение. Актуальность темы. В настоящий момент в нашей стране и во всем мире возрождается интерес к ядерной энергетике. Развитие атомного энергопромышленного комплекса постепенно становится для страны приоритетной задачей. Запланировано строительство большого числа новых энергоблоков.

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

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


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


Для достижения этих целей решены следующие задачи:

• Разработана структура базы данных алгоритмов АСУ ТП, содержащая топологию алгоритмов логики, параметризацию функциональных блоков¹ (ФБ) алгоритмов и связь параметров ФБ с проектными данными технологических систем, внутренние микропрограммы ФБ и др.
  
• Разработан механизм синхронизации изменений в проектных данных технологических систем и в алгоритмах путем автоматического внесения необходимых изменений в базу данных алгоритмов АСУ ТП.
  
• Создан прототип автоматизированной системы проектирования и моделирования АСУ ТП – программный комплекс SKUGEN, предназначенный для создания (проектирования) алгоритмов АСУ ТП с механизмом параметризации по проектным данным, создания модели алгоритмов для тестирования алгоритмов АСУ ТП и работы тренажеров, получения информации использования проектных данных в алгоритмах.
  
• Создана новая система разработки и эксплуатации больших моделирующих программных комплексов WinMod в операционной системе Windows, позволяющая разрабатывать аналитические тренажеры с использованием мультимедийных возможностей операционной системы.
  

Научная новизна выполненной работы заключается в следующем:

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

Практическая значимость работы заключается в том, что:

• созданный автором программный комплекс SKUGEN использован для создания, отладки и тестирования модели алгоритмов АСУ ТП полномасштабного тренажера АЭС Куданкулам (Индия) (ОАО «ДЖЭТ»).
  
• Разработанный автором метод создания программных средств для моделирования и проектирования алгоритмов АСУ ТП на основе проектных данных технологических систем энергоблока рассматривается в настоящий момент для дальнейшего развития программного комплекса SKUGEN для применения в проектных организациях (ФГУП Атомэнергопроект, Москва).
  
• система разработки и эксплуатации моделирующих комплексов WinMod позволяет создавать наглядный и удобный интерактивный графический интерфейс. Это делает возможным ее применение для разработки аналитических тренажеров любого назначения как для уже существующих АЭС, так и для строящихся, а также при создании моделирующих и расчетных комплексов для решения научно-исследовательских задач и задач обучения в системе высшего образования. Система WinMod использовалась при разработке двух аналитических тренажеров: «ТОМАС-1» для АЭС с реактором ВВЭР-1000 и «ТОМАС-2» для АЭС с реактором РБМК-1000. «ТОМАС-1» поставлен в УГТУ (Уральский Государственный Технический Университет) и в настоящее время внедрен в учебный процесс. Ведется разработка моделирующего комплекса JOKER для блока Белоярской АЭС с реактором БН-600, первая версия комплекса в декабре 2005 г. принята в опытною эксплуатацию. Ведется разработка аналитического тренажера Ростовской АЭС по полномасштабной модели.
  

Апробация работы и публикации. Материалы диссертационной работы докладывались на:

• семинаре секции динамики «Математические модели для исследования и обоснования характеристик оборудования и ЯЭУ в целом при их создании и эксплуатации» (г. Гатчина, 2000 г.),
  
• семинарах по алгоритмам и программам для нейтронно-физических расчетов ядерных реакторов («НЕЙТРОНИКА», г. Обнинск, 2005 г., 2006 г.),
  
• Четвертой и Пятой Международных научно-технических конференций «Безопасность, эффективность и экономика атомной энергетики». (г. Москва, 2004 г., 2006 г.)
  
• семинаре «Методики и программы полномасштабного моделирования динамики АЭС и ТЭС» (г. Москва, 2004 г.).
  
• семинаре «Информационные технологии в проектировании и управлении производством» (г. Москва, 2006 г.)
  

Основное содержание диссертации изложено в 8 печатных работах.


Структура и объем диссертации. Диссертация состоит из введения, пяти глав, заключения, списка литературы и двух приложений. Содержит 119 страниц, 20 рисунков, 18 таблиц. Список литературы включает 54 наименования.


СОДЕРЖАНИЕ РАБОТЫ


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


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

Эксплуатирующиеся сегодня более 30 полномасштабных и аналитических тренажеров разных типов реакторов для АЭС создавались для уже построенных энергоблоков на основе испытанной временем технологии «US3», которая предназначена для создания больших моделирующих комплексов. Данная технология (ее можно уже назвать «классической») предполагает наличие полной информации об объекте (энергоблоке) и его процессах на момент начала моделирования. Система контроля и управления (СКУ) существующих энергоблоков проектировалась и строилась на элементной базе «с жесткой логикой» и представляет собой в большинстве случаев достаточно простые алгоритмы, что позволяло создавать их математическую модель без использования средств автоматизации.

Начиная с 2000 года, в тренажеростроении появились проекты, создание которых происходит при наличии двух новых факторов. Первый из них – применение цифровых Автоматизированных Систем Управления Технологическими Процессами (АСУ ТП). Реализация цифровых АСУ ТП нового поколения сегодня представлена двумя аппаратно-программными комплексами – «TELEPERM XP/XS» (Сименс, Германия) на Тяньваньской АЭС (Китай) и ТПТС-51 на АЭС Куданкулам (Индия) и Калинин-3. Основным отличием этих АСУ ТП является возрастающая роль автоматики и уменьшение количества операций персоналом по управлению конкретным оборудованием. Управление оборудованием заменяется управлением процессами. Все это выливается в существенное увеличение количества алгоритмов (десятки тысяч) и их сложности. Алгоритмы представляют собой совокупность отдельных логических схем (функциональные планы), «собранных» из специальных логических (функциональных) блоков (ФБ), функционирование которых определяется заданными параметрами (параметризация блока, алгоритма).

Другой новый фактор – изготовление тренажера до пуска энергоблока. Например, для АЭС Куданкулам разница в сроках составляет 1 год, для Тяньваньской АЭС – 2 года. Это означает, что создание тренажера осуществляется по проектным и рабочим данным. Такие данные имеют три принципиальных недостатка - они содержат большое количество различных ошибок (проектные, случайные и др.), они не полные (что-то не до конца спроектировано) и они не являются окончательными (вносятся изменения проектантом). Это принципиально противоречит «классической концепции» создания тренажера, когда к моделированию приступают после практически полного сбора данных об объекте.

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

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

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

3. Ошибки, связанные непосредственно с алгоритмами, с логикой их реализации.

Также встречены методические проблемы моделирования и проектирования:

1. Отсутствие сквозной системы проектирования АСУ ТП энергоблока. В настоящий момент проектирование осуществляется в три этапа с использованием несовместимых по формату программных средств.
   

• технологи-проектанты создают техническое задание на алгоритмы в виде блок-схем (средствами редактора MS WORD) без учета специфики команд управления оборудованием в цифровых АСУ ТП.
  
• проектанты автоматики пересматривают эти данные, приводят их к специфике цифровых АСУ ТП и перерисовывают в АВТОКАДЕ в форматы-прообразы.
  
• разработчики проекта автоматики по прообразам создают непосредственно алгоритмы средствами АСУ ТП.
  
1. Отсутствие готового проекта АСУ ТП на момент создания модели не позволяет использовать средства автоматической генерации модели (технология ГЕНТА, ОАО «ДЖЭТ») по исполняемому коду аппаратных средств АСУ ТП.
   
2. Моделирование возможно только по проектным данным (имеющие описанные выше недостатки).
   
3. Невозможность применять разработанные ранее средства и методы моделирования по причинам:
   
   • Отсутствия в них поддержки специфики команд управления оборудованием цифровых АСУ ТП
     
   • Отсутствие механизма обеспечения целостности межалгоритмических переходов, что не позволяет автоматически находить (и не создавать) ошибки в названиях входных сигналов, определять выходные сигналы, которые нигде не используются, или входные сигналы, которые нигде не определены.
     
   • Отсутствует связь параметризации алгоритмов с технологическими данными, меняющимися во времени в процессе проектирования (это приводит к необходимости осуществлять изменения модели вручную).
     
   • Отсутствия информационной поддержки для анализа логики.
     

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

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

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

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

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

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

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

3. Должен быть инструмент импорта (или постоянная связь) данных из проектной базы технологических систем в проект/модель алгоритмов АСУ ТП с механизмом автоматического изменения проекта/модели в случае изменения какого-то объема проектных данных технологических систем.

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

5. Интерфейс ручной параметризации должен быть реализован как «выборный». Это означает, что в распоряжении пользователя в случае проектирования/редактирования алгоритма, его параметризации или изменения межалгоритмических связей, должна быть только возможность выбора из имеющейся в проектной базе технологических систем или в других алгоритмах информации без возможности «клавиатурного ввода» (работа в «пространстве проектных данных»).

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

Реализация этих требований возможна при создании механизма связанности большой по объему и разной по содержанию информации. Максимально простым способом это можно достигнуть, используя для хранения информации СУБД. База данных предназначена для структурирования различной информации, а механизмы запросов позволяют легко получить конкретные данные.

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

Разработка структуры базы и механизмов работы с ней должна быть основана на следующих принципах:

• Уникальность данных – информация не дублируется, используются только ссылки
  
• Связанность данных – информация иерархически распределена с механизмом защиты целостности данных
  
• Функциональное разделение данных – разделение графической информации, информации о функциональных блоках и их свойствах, об алгоритмах и их параметрах и т.д.
  
• Количество таблиц должно быть постоянно (не являться функцией от количества алгоритмов и их параметров)
  
• Необходимы механизмы, позволяющие осуществить связь с проектной базой данных любой структуры.
  

Основные компоненты программного комплекса показаны на рис. 1.

Для импорта в базу алгоритмов АСУ ТП уже имеющего проекта или его части, существующего в каком либо формате, служит преобразоватеError: Reference source not foundль, способный работать с соответствующим форматом представления алгоритмов.




Рис 1. Схема структуры программного комплекса


Для работы с данными, находящимися в базе алгоритмов АСУ ТП, должен быть разработан менеджер базы. В его задачи входит:

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

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

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


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

Структура базы и ее таблицы приведены на рис. 2.

Функциональное назначение таблиц базы алгоритмов АСУ ТП разделяется на несколько групп. В первой группе находятся таблицы свойств функциональных блоков (таблицы FB рис.2). В них описываются параметры блоков, списки входных/выходных портов и их свойства, возможные значения параметризации или источники данных (SQL-строки к соответствующим таблицам). Также определяются шаблоны микропрограмм функционирования блока и необходимых переменных для генератора модели и др.

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

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

Таблицы проектных данных входят в четвертую группу. Состав и структура проектных данных может быть произвольной и определяется проектной организацией. Каждый тип объекта (оборудования) проектных данных должен иметь свою таблицу. Каждый подобъект (набор свойств объекта, самостоятельно используемых в алгоритмах) должен также иметь свою таблицу,




Рис 2. Структура базы алгоритмов АСУ ТП.


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

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

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


В четвертой главе описывается программный комплекс моделирования и проектирования алгоритмов АСУ ТП SKUGEN, его компоненты, программные механизмы, интерфейс пользователя, работа в составе тренажера.

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

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

Интерфейс комплекса создан средствами MS Visual Basic (VB). В основе графического редактора лежит средство MS VISIO 2002. В проекте VB оно взаимодействует с приложением как специализированная компонента. Для работы с базами данных использовался объектный протокол ActiveX Data Object (ADO).

Для разработки проекта логики АСУ ТП и ее модели необходимы два типа данных – база данных технологических систем и алгоритмы. База технологических данных заполняется проектантами (технологами) АЭС и представляет собой набор таблиц со списком оборудования и их характеристиками. Комплекс SKUGEN позволяет работать как с копией базы проектанта, содержащей только необходимые поля в таблицах для модели АСУ ТП, так и непосредственно с самой базой. Первый вариант более удобен при разработке тренажера. Второй вариант возможен для проектных организаций. Заполняемые технологом данные по оборудованию в проектную базу будут сразу доступны программному комплексу для работы, все последующие изменения в проекте будут автоматически учтены. Данные–алгоритмы при проектировании должны «прорисовываться» в графическом редакторе. В готовом виде они поставляются от проектных организаций при создании тренажера.

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

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

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

Основная работа разработчика логики сводится к анализу алгоритмов и их связей между собой. Для удобства работы с набором определенных алгоритмов служит стек – список алгоритмов, формируемый пользователем из разных источников программного комплекса для оперативной работы. Имеется функция получения списка алгоритмов, в которых используется выбранный для анализа выходной сигнал. Механизм экспортирования измененных алгоритмов в форматы jpg и HTML осуществляет ведение архива изменений.

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

Удаление подобъекта возможно только при отсутствии на него ссылок в алгоритмах. Удаление объекта возможно только при отсутствии у него подобъектов, ссылок на этот объект в алгоритмах и отсутствия на него типового алгоритма.

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

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

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

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

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

Механизм отслеживает следующие изменения в базе алгоритмов АСУ ТП:

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

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

Генератор создает программы на языке фортран. Программы и файлы описания переменных совместимы с исполнительными системами US3 и WinMod.

Практическое использование работы комплекса осуществляется в составе полномасштабного тренажера АЭС Куданкулам (ОАО ДЖЭТ). Модель алгоритмов АСУ ТП ПМТ АЭС Куданкулам состоит из около 8000 алгоритмов. Из них более 1000 – алгоритмы управления моторами, около 3500 – задвижками, более 200 – регуляторов, около 3000 – алгоритмы защит и блокировок.

Комплекс оперативно решает следующие задачи:

• Прорисовка или импорт алгоритмов по данным технологов-проектантов.
  
• Параметризация алгоритмов по предварительной проектной спецификации тренажера (PDS - создается по данным проектных организаций, но с учетом объема и специфики моделирования технологических систем на тренажере).
  
• Генерация модели алгоритмов.
  
• Тестирование модели тренажера с целью нахождения ошибок в алгоритмах и параметрах и передачи обнаруженных ошибок в проектные организации.
  
• Исправление ошибок в модели алгоритмов по указанию тест-операторов тренажера или по новым или исправленным проектным данным.
  
• Генерация новой версии модели алгоритмов.
  

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


Глава 5 посвящена описанию созданной автором совместно с к.т.н. И.В.Федоровым системы разработки и эксплуатации моделирующих программных комплексов WinMod в операционной системы Windows. Описана постановка задачи, структура системы WinMod, технология создания графического интерфейса модели. Приведено краткое описание аналитических тренажеров, разработанных с помощью данной системы.

Структурно система состоит из двух подсистем – интеграция и управление моделью (исполнительная система), разработчиком которой является И.В.Федоров, и подсистема визуализации и имитационного управления, разработчик – автор диссертации.

Одна из основных технологий моделирования, названная US3, была разработана в США фирмой Singer Link-Miles Simulation Corporation (сейчас GSE Systems) в 80-е годы для операционной системы Unix, и поддерживаеться до настоящего времени фирмой-разработчиком и СП, а затем ОАО «ДЖЭТ». ОАО «ДЖЭТ» использовало эту систему для разработки тренажеров АЭС с реакторами различных типов, начиная с конца 80-х годов и до недавнего времени на базе многопроцессорных компьютеров Silicon Graphics. Эта система представляет собой программное обеспечение, позволяющее разрабатывать, отлаживать и эксплуатировать в режиме реального времени крупные моделирующие комплексы.

За последнее десятилетие произошли существенные изменения в вычислительной технике. Рост производительности ПЭВМ на 1-2 порядка позволил постепенно отказаться от больших и дорогих вычислительных комплексов и перейти на гораздо более доступную платформу фирмы Intel. Появилась новая ниша программного обеспечения, способная обеспечить доступное быстродействие средствами разработки больших моделирующих систем на новой платформе: операционная система MS Windows на процессорах Intel.

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

При создании системы WinMod ставились три ключевые задачи:

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

В результате была разработана система моделирования, структурно подобная US3 и совместимая с ней по основным форматам данных, работающая в операционной системе Windows на одно- или многопроцессорных компьютерах с процессорами Intel. Структура программного комплекса в части визуализации и имитационного управления показана на рис. 3.

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

Переменные ввода/вывода могут принадлежать к четырем типам обмена: логический ввод, аналоговый ввод, логический вывод и аналоговый вывод. Все четыре типа ввода/вывода имеют свою таблицу обмена между графическими приложениями визуализации и управления (панели) и исполнительной системой. Для передачи служебной информацией от исполнительной системы графическим панелям имеется дополнительная таблица. Все пять таблиц являются базами DBASE IV, связанными с базой MS Access HARDWARE.




Рис. 3. Структура подсистемы визуализации и управления WinMod.


При написании программы математической модели переменные ввода/вывода не отличаются от обычных переменных. Однако для системы разработки они являются специальными, и создание их идентификаторов должно подчинятся определенным правилам, которые определяют тип (таблицу) обмена. Такие правила имеются и в технологии US3. Для совместимости система WinMod их полностью поддерживает.

Для каждой переменной ввода/вывода необходимо знать ее местонахождение в базе обмена HARDWARE. Оно определяется именем таблицы (зависит от типа обмена), номером записи, именем поля в таблице и (для логических переменных) номером бита в ячейке. Эта информация находится в базе карты ввода/вывода IOMAP.

Для работы с базой ввода/вывода предназначена утилита Менеджер IOMAP. Она предназначена:

• Для ввода переменных и их параметров. Ввод возможен из файлов описания формата WinMod или US3 (в случае переноса проекта).
  
• Автоматического определения размещения новых переменных в базе обмена HARDWARE. Новая переменная анализируется по ее идентификатору, определяется ее тип, таблица обмена и присваиваются следующие по порядку номера бита, поля, записи.
  
• Генерации в базе обмена HARDWARE новых записей (при необходимости).
  
• Ведения лог-файла и вывод сообщений об ошибках и предупреждениях.
  

Элементы отображения и управления созданы на основе технологии MS ActiveX ControlError: Reference source not foundError: Reference source not foundError: Reference source not foundError: Reference source not foundError: Reference source not found. Они представляют собой внедряемые в приложение динамические библиотеки, основанные на модели компонентных объектов (СОМ). Преимуществами данной технологии являются: 1) осуществление на системном уровне поддержки и функционирования (режим разработки, установка в приложение-контейнер, безопасность данных и др.), 2) возможность создать сколь угодно сложное поведение элемента (вплоть до программирования некоторой физической модели). При разработке элемента ActiveX необходимо определить его свойства, доступные разработчику графических панелей, и описать функции действия на используемые события при работе пользователя с этим элементом. Свойствами могут выступать текст, который необходимо отобразить, имена внешних медиа-файлов (звуковые, фото и видео файлы), цвет и др. Событием может быть нажатие кнопки/кнопок мышки по элементу, ввод с клавиатуры, работа таймера и др.

Для системы WinMod создана достаточно богатая библиотека элементов. Большинство из них универсальны и могут использоваться для разных проектов и задач. Элементы могут быть разделены на два типа по способу параметризации. Первый тип элементов представляет ручной способ параметризации, когда задание свойств элемента сводится к изменению тех или иных значений параметров на диалоговом окне задания свойств. Второй тип элементов – с автоматической параметризацией, когда информация, характеризующая элемент, уже имеется. Отдельно можно выделить элементы, имитирующие некоторые физические процессы. Такой элемент содержит в себе модель визуализации, расчет которой зависит от множества переменных физической модели. Например, элемент процесса кипения использует такие параметры, как паросодержание, температура среды, скорость потока и его направление, уровень жидкости и др.

Создание графических приложений системы WinMod основано на технологии «разработки мастера приложений (AppWizard)» Visual Studio C++. Эта технология основана на генерации проектов приложения по уже разработанному эталонному проекту на C++. Эталонный проект является законченным проектом приложения с описанием всех механизмов, необходимых для взаимодействия с системой WinMod. В дальнейшем пользователь Visual Studio выбирает из списка создания нового проекта пункт «Генерация панели WinMod», задает имя будущей панели и получает готовый для разработки проект.

Разработка панели не нуждается в программировании и осуществляется методом визуального проектирования. Элементу, с помощью его индивидуального окна свойств, задаются необходимые параметры. Далее, средствами Visual Studio, производится присвоение свойству обмена имени интерфейсной переменной ввода/вывода. Вид и назначение графических приложений отражают решаемую задачу под управлением WinMod. Панели могут быть как достаточно простые, с отображением отдельных переменных и ключей управления (для задачи «исследовательский инструмент на рабочем столе инженера»), так и сложными, в виде мультимедийных приложений с визуализацией физических процессов для задач обучения.

Для создания описания связи приложения с исполнительной системой предназначена утилита LinkDB. Утилита просматривает файлы проекта панели с описанием интерфейсных переменных, находит их в базе IOMAP и создает include-файл с вызовами функций обмена для каждой переменной.

Функции обмена находятся в динамической библиотеке IO.dll. Ее вызов и описания функций уже находятся в проекте приложения (предусмотрено эталонным проектом).

Связь графических приложений (панелей) с исполнительной системой WinMod осуществляется посредством базы HARDWARE. База находится на компьютере с исполнительной системой. Панели могут находиться как на этом же компьютере, так и на других, соединенных локальной сетью. В последнем случае база должна быть доступным сетевым ресурсом.

Выбор механизма обмена посредством базы был обусловлен следующими преимуществами:

• Скорость обмена. Для задач этого типа данный механизм обеспечивает обмен с достаточным запасом.
  
• Актуальность состояния. В базе всегда находятся актуальные (соответствующие модельным переменным) значения на текущий момент времени. Потеря данных при асинхронном чтении графическими приложениями не критична для обслуживаемых WinMod-ом задач. На современных ПЭВМ потеря данных отсутствует.
  
• Относительная простота реализации механизма обмена (необходимые механизмы уже созданы разработчиками СУБД).
  

С использованием системы WinMod в ОАО «ДЖЭТ» были разработаны два аналитических тренажера: «ТОМАС-1» для АЭС с реактором ВВЭР-1000 и «ТОМАС-2» для АЭС с реактором РБМК-1000.

Программный комплекс “ТОМАС-1” (Тренажер Оперативного Моделирования Аварийных Ситуаций) позволяет моделировать нормальные, переходные и аварийные режимы работы АЭС с ВВЭР-1000 (проект В-320). Математические модели тренажера частично разработаны с использованием системы WinMod, частично – использованы модели технологических систем, разработанные для аналогичных полномасштабных тренажеров.

Комплекс ТОМАС-1 передан в УГТУ (Уральский Государственный Технический Университет) и в настоящее время внедрен в учебный процесс.

Программный комплекс ТОМАС-2 предназначен для моделирования нормальных, переходных и аварийных режимов работы АЭС с РБМК-1000. Прототипом тренажера является 4 блок Курской АЭС. Трехмерная двухгрупповая нейтронно-физическая модель, а также модель КМПЦ и его вспомогательных систем, построенная с помощью кодогенератора CMS, разработаны и отлажены в системе WinMod. Модели остальных технологических систем перенесены с полномасштабного тренажера Курской АЭС.

Панели графического интерфейса обоих комплексов разработаны полностью в WinMod.

В настоящее время ведется разработка моделирующего комплекса JOKER для блока Белоярской АЭС с реактором БН-600. Первая версия комплекса в декабре 2005 г. принята в опытную эксплуатацию.

Начата разработка аналитического тренажера Ростовской АЭС в объеме полномасштабной модели (ОАО «ДЖЭТ»).


ОСНОВНЫЕ РЕЗУЛЬТАТЫ И ВЫВОДЫ


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

• Разработана структура универсальной единой базы алгоритмов АСУ ТП, содержащей топологию алгоритмов, параметризацию функциональных блоков и внутренние алгоритмы блоков. Разработан механизм синхронизации изменений в проектных данных и в алгоритмах с автоматическим внесением необходимых изменений в базу алгоритмов АСУ ТП.
  
• Создан программный комплекс SKUGEN – прототип автоматизированной системы проектирования и моделирования алгоритмов АСУ ТП, предназначенный для создания (проектирования) алгоритмов с привязкой к проектным данным, создания модели алгоритмов для тестирования проекта алгоритмов АСУ ТП и работы тренажеров, получения информации о проектных данных с привязкой к алгоритмам. Комплекс использован для создания, отладки и тестирования модели алгоритмов АСУ ТП полномасштабного тренажера Куданкуламской АЭС.
  
• Разработанный метод создания программных средств для моделирования и проектирования алгоритмов АСУ ТП на основе проектных данных технологических систем энергоблока рассматривается в настоящий момент для дальнейшего развития программного комплекса SKUGEN для применения в проектных организациях (ФГУП Атомэнергопроект, Москва, проект АЭС-2006).
  
• Создана новая система разработки и эксплуатации больших моделирующих программных комплексов WinMod в операционной системы Windows, позволяющая разрабатывать аналитические тренажеры с использованием мультимедийных возможностей операционной системы.
  

Основные результаты диссертации опубликованы в следующих работах:

1. Айзатулин А.И., Жукавин А.П., Исламов В.Ю., Лысов Д.А. Тестирование алгоритмов АСУ ТП на полномасштабном тренажере Тяньваньской АЭС в Китае. Четвертая Международная Научно-техническая конференция «Безопасность, эффективность и экономика атомной энергетики». Пленарные и секционные доклады. Москва, ВНИИАЭС, 16-17 июня, 2004. с. 289-291.
   
2. Жукавин А.П., Айзатулин А.И. Проблемы и пути их решения при изготовлении тренажеров проектируемых АЭС (Тяньвань – КНР, Куданкулам – Индия). Пятая Международная Научно-техническая конференция «Безопасность, эффективность и экономика атомной энергетики». Программа и тезисы докладов. Москва, 19-21 апреля 2006 г. с. 150-151.
   
3. А.И.Айзатулин, К.Б.Будылин, О.А.Волощенко, А.П.Жукавин, А.О.Ковалевич, И.В.Фёдоров, Р.Л.Фукс. Программный комплекс ТОМАС для оперативного моделирования аварийных ситуаций на АЭС с ВВЭР-1000. Тез. докл. семинара секции динамики «Математические модели для исследования и обоснования характеристик оборудования и ЯЭУ в целом при их создании и эксплуатации», 18-22 сентября 2000 г.- Гатчина,2000, с.164-166.
   
4. Селезнев Е.Ф., Пряничников А.В., Фёдоров И.В., Айзатулин А.И., Белов А.А., Келарев Е.Ю. Комплекс программ JOKER – расчетного обоснования безопасной эксплуатации АЭС с РУ БН-600 в динамических режимах. Четвертая Международная Научно-техническая конференция «Безопасность, эффективность и экономика атомной энергетики». Программа и тезисы докладов. Москва, ВНИИАЭС, 16-17 июня, 2004. с. 82-86.
   
5. Селезнев Е.Ф., Айзатулин А.И., Белов А.А., Козлова Н.В., Федоров И.В. Расчетное обоснование загрузок на АЭС с реактором БН-600 в динамических режимах. Пятая Международная Научно-техническая конференция «Безопасность, эффективность и экономика атомной энергетики». Программа и тезисы докладов. Москва, 19-21 апреля 2006 г. с. 77-80.
   
6. Айзатулин А.И. Разработка программного обеспечения для создания, отладки и тестирования моделей цифровых СКУ АЭС нового поколения на основе проектных данных. ВАНТ, серия Физика ядерных реакторов, 2006 г., вып. 2, с. 21-27 [в печати]
   
7. И.В.Фёдоров, А.И.Айзатулин. Система разработки и эксплуатации программных моделирующих комплексов WinMod. Сб. докладов семинара «Нейтроника», Обнинск, 2001, с.33
   
8. Росляков М.В., Титов Г.П., Щеклеин С.Е., Айзатулин А.И., Селезнев Е.Ф., Федоров И.П. Опыт внедрения тренажера оперативного моделирования аварийных ситуаций “ТОМАС-1А” в учебно-методический процесс кафедры “атомная энергетика” УГТУ-УПИ. “Перспективные энергетические технологии. Экология. Экономика, безопасность и подготовка кадров.” Сборник научных трудов. Екатеринбург, 2006, с.150
   

ОАО «ВНИИАЭС», 2006г. Тираж 70 экз.