Содержание к диссертации
Введение
1 Обобщение опыта. формулировка проблемы 11
1.1 Тренажеры первого поколения 11
1.2 Новые факторы при создании тренажеров последних поколений АЭС 13
1.3 Проблемы моделирования (на примере пмттяньваньской аэс) 15
1.4 Проблемы проектирования (на примере пмт аэс куданкулам) 22
1.5 Обзор средств разраготки асу тп и моделирования алгоритмов автоматики 27
2 Методика создания средств моделирования и проектирования алгоритмов цифровых асу тп по проектным данным технологических систем 33
2.1 Методические требования 33
2.2 База алгоритмов асу тп 35
2.3 Компоненты комплекса 36
3 Структура базы алгоритмов АСУ ТП 39
3.1 Свойства функциональных блоков 39
3.2 Алгоритмы и параметризация 44
3.3 Связи с проектными таблицами и генерация типовых алгоритмов 48
3.4 Проектные данные технологических систем 50
3.5 Служебные таблицы 51
4 Программный комплекс SKUGEN 53
4.1 Общее описание 53
4.2 Проектные данные асу тп энергоблока. преобразователь алгоритмов 56
4.3 Список алгоритмов и работа с ним 60
4.4 Графический редактор и библиотека функциональных блоков 62
4.5 Параметризация блоков 66
4.6 Другие функции интерфейса пользователя 71
4.7 Менеджер проектных таблиц 73
4.8 Генерация типовых алгоритмов 75
4.9 Информация использования блоков 77
4.10 Генератор модели алгоритмов 79
4.11 Работа комплекса в составе тренажера. Оценка достижения поставленной цели 82
5 Система разработки и эксплуатации моделирующих программных комплексов WINMOD 86
5.1 Структура комплекса 89
5.2 База обмена hardware 91
5.3 База карты ввода/вывода и менеджер «юмар» 92
5.4 Элементы отображения и управления 96
5.5 Создание графических приложений 98
5.6 Утилита «linkdb» и библиотека «io.dll» 100
5.7 Связь графических приложений с исполнительной системой 101
5.8 Внедрение системы WINMOD 102
Заключение 105
Литература 107
Приложение
- Новые факторы при создании тренажеров последних поколений АЭС
- Связи с проектными таблицами и генерация типовых алгоритмов
- Проектные данные асу тп энергоблока. преобразователь алгоритмов
- Связь графических приложений с исполнительной системой
Введение к работе
В настоящий момент в нашей стране и во всем мире возрождается интерес к ядерной энергетике. Для этого имеется несколько основных причин. Первая - мировой рост энергопотребления, причем в Российской Федерации рост больше прогнозных показателей: за 8 месяцев 2006 года в целом по стране рост энергопотребления составил 5,5% вместо 2%, предсказанных прогнозом [1].
Вторая основная причина - истощение запасов углеводородного топлива, «Время дешевых энергоресурсов в стране закончилось. Газовая пауза завершилась» - ставиться диагноз аналитиками [2].
Новые технологии производства электроэнергии приходят позже, чем ожидалось. Все это способствовало взглянуть на ядерную энергетику новыми глазами, тем более что «чернобыльский синдром» за давностью лет постепенно теряет свою силу.
Развитие атомного энергопромышленного комплекса постепенно становится для страны приоритетной задачей. Это отражено в Послании президента Российской Федерации Федеральному Собранию РФ. 15 июля 2006 г. правительством РФ была утверждена Концепция федеральной целевой программы "Развитие атомного энергопромышленного комплекса России на 2007-2010 годы и на перспективу до 2015 года". Предусматриваются внесения изменений в нормативно-правовые документы, в том числе - проект нового закона по атомной промышленности, который должен поступить в Государственную Думу [3].
Перед отраслью ставятся грандиозные задачи, по масштабу сопоставимые с национальным проектом. Если в 2006 году строительство энергоблоков ведется на двух площадках, то в 2007 году строительство уже развернется на 4-х площадках, в 2008 году - на 6-ти площадках, а в 2009 году - будет уже 9-таких площадок. Количество
специалистов, занятых в строительстве, должно возрасти с нынешних 5,5 тыс. до почти 55 тыс. человек. Планируется строительство от двух до четырех блоков в год [4]. Кроме того, предполагается модернизация работающих энергоблоков с целью продления их ресурса.
Такой масштаб работ предполагает, в том числе, наличие и использование современных средств проектирования. Учитывая, что некоторые системы АЭС, в первую очередь АСУ ТП, системы контроля и управления блоком будут разрабатываться на основе цифровых программно-технических средств нового поколения, к средствам проектирования сегодня предъявляются особые требования.
Последнее десятилетие проектирование энергоблоков проводилось в «штучном» исполнении, что позволяло, хотя и с большими трудностями, использовать старые методы проектирования. Однако опыт строительства первых АЭС с цифровой системой АСУ ТП (Тяньваньская АЭС, АЭС Куданкулам, Калинин-3) показал, что проектирование системы контроля и управления АЭС "ручным" способом, применявшимся для разработки проектов аналоговых АСУ ТП, оказался крайне неэффективен для проектирования новых систем на базе программируемых программно-технических средств (ПТС) ввиду их гораздо большей сложности.
Эти обстоятельства затронули и создателей тренажеров АЭС, которые одними из первых столкнулись с новыми трудностями. Тренажеростроение оказалось в новых условия - стало необходимо создавать тренажеры для блоков, которых еще нет (только проектные материалы) и создавать модели цифровых АСУ ТП и имитаторы системы верхнего блочного уровня (СВБУ).
В результате тренажеростроение оказалось рядом с несвойственной для нее областью - проектированием, что привело к необходимости «на ходу», в процессе работ над проектами полномасштабных тренажеров (ГТМТ), решать новые задачи, создавать
новые программные инструменты, менять классические технологии. Можно сказать, что некоторые созданные решения могут быть применимы не только для строительства тренажеров, но и для проектных организаций, которые уже проявили интерес к развитию идей и инструментов, описанных в данной работе. Кроме того, растет понимание необходимости внедрении технологии разработки симуляторов как подсистемы CALS1 технологии непосредственно в процесс проектирования АЭС. Иными словами, параллельно проектированию создавать с помощью компьютерных кодов «виртуальную АЭС», на которой проверять все спроектированное оборудование и технические решения в комплексе и в различных режимах для исправления ошибок проектирования и поиска оптимальных решений. То есть тренажер сегодня - в свете программы развития атомной энергетики - необходимо рассматривать не только как инструмент подготовки персонала (классическая задача), но и как «информационно-цифровую модель будущих станций» [5].
Кроме того, рост производительности доступной персональной вычислительной техники стимулировал разработку отечественных систем интегрирования сложных моделирующих комплексов с современным аппаратом визуализации для создания аналитических симуляторов и расчетных комплексов широкого применения (обучение, ВУЗы, инженерные задачи и др.).
В данной работе описываются методика создания программных средств для моделирования и проектирования алгоритмов АСУ ТП на базе проектных данных технологических систем и программный комплекс SKUGEN, разработанный на основе этих методов, а также созданная с участием автора система разработки и эксплуатации
CALS - Continuous Acquisition and Life cycle Support - непрерывный сбор и информационная поддержка жизненного цикла продукции
6 моделирующих программных комплексов WinMod. Описанный программный комплекс SKUGEN стал штатным средством создания и отладки моделей алгоритмов АСУ ТП нижнего уровня полномасштабного тренажера АЭС Куданкулам (ОАО «ДЖЭТ»). Система WinMod использовалась в ОАО «ДЖЭТ» при создании двух аналитических симуляторов для блоков с реакторами РБМК-1000 (прототип - 4-й блок Курской АЭС) и ВВЭР-1000 (проект В-320), в настоящий момент идет создание аналитического тренажера Ростовской АЭС и расчетного интерактивного комплекса JOKER для БН-600.
Содержание работы изложено в 5 главах.
В главе 1 обобщается опыт строительства тренажеров для
существующих станций и анализируются проблемы, возникшие при создании тренажеров строящихся АЭС нового поколения. Проводится обзор сегодняшних средств проектирования и моделирования АСУ ТП.
Во 2-ой главе формулируется методика создания комплекса моделирования и проектирования алгоритмов АСУ ТП по проектным данным. Она состоит из методических требований к функциям создаваемого комплекса в целом, правил организации данных и отношений различных данных между собой, определения необходимых компонент комплекса и их основных функций. Обосновывается эффективность использования СУБД для хранения всей информации проекта АСУ ТП.
В главе 3 описана структура базы алгоритмов АСУ ТП, назначение таблиц и полей.
В главе 4 описывается программный комплекс моделирования и проектирования алгоритмов АСУ ТП SKUGEN, его компоненты, программные механизмы, интерфейс пользователя, работа в составе тренажера.
Новые факторы при создании тренажеров последних поколений АЭС
Начиная с 2000 года, в тренажеростроении появились проекты, создание которых происходит при наличии двух новых факторов использование АСУ ТП нового, цифрового, поколения и окончание разработки тренажера до пуска энергоблока в эксплуатацию. Эти обстоятельства в корне меняют сам принцип создания тренажеров по классической схеме.
Реализация цифровых АСУ ТП нового поколения сегодня представлена двумя программно-техническими комплексами (ПТК) -«TELEPERM XP/XS» (Сименс, Германия) [10] на Тяньваньской АЭС (Китай) и ТПТС-51 («TELEPERM МБ») [11][41] на АЭС Куданкулам (Индия) и Калинин-3. Основным отличием новых АСУ ТП являются возрастающая роль автоматики и уменьшение количества операций персоналом по управлению конкретным оборудованием. Управление оборудованием заменяется управлением процессами (с помощью группового и подгруппового управления). Это выливается в существенное увеличение количества алгоритмов и их сложности. Алгоритмы представляют собой совокупность отдельных логических схем (функциональные планы, ФП), собранных из различных логических (функциональных) блоков (ФБ). Связь между функциональными планами, а также с функциональными блоками управления оборудованием осуществляется через аналоговые и бинарные сигналы. Количество планов достигает несколько тысяч (для АСУ ТП Тяньваньскои АЭС - 25 тысяч), многие планы занимают несколько страниц (до 50 в алгоритмах подгруппового управления). Большинство функциональных блоков содержат параметры (параметризация блока), которые определяют функции данного блока или значение выходных сигналов. У сложных блоков количество таких параметров может достигать нескольких десятков. Понятно, что такой объем логики и данных не является наглядным для анализа. Кроме того, внедрение новых средств и идеологии управления обуславливает необходимость использования новых алгоритмических подходов, которые ранее не применялись, что требует их серьезной последующей проверки и настройки.
Также меняется сам принцип управления. Панели и пульты с приборами остаются только для дополнительного или резервного управления. Штатное управление переводится на мониторы компьютеров. Ключи, кнопки и лампы заменяются трекболом и видеокадрами. Количество видеокадров исчисляется несколькими сотнями.
Ясно, что для создания модели таких АСУ ТП необходимы новые средства разработки. Причем эти средства должны, прежде всего, автоматизировать процесс создания модели по проектным данным АСУ ТП, т.к. ручное «рисование» алгоритмов в редакторе и тем более ручное кодирование не возможно не только из-за большого объема такой работы, но и из-за опасности внесения новых, дополнительных ошибок. Другой новый фактор - изготовление тренажера до пуска энергоблока. Например, для АЭС Куданкулам эта разница в сроках составляет 1 год, для Тяньваньской АЭС - 2 года. Это означает, что создание тренажера осуществляется по проектным и рабочим данным. Такие данные имеют три принципиальных недостатка - они содержат большое количество различных ошибок (проектные, случайные и др.), они не полные (проектирование не закончено) и они не являются окончательными (вносятся изменения проектировщиком). Это принципиально противоречит «классической концепции» создания тренажера, когда к моделированию приступают после практически полного сбора данных об объекте. С этим на практике столкнулись разработчики полномасштабных тренажеров ОАО «ДЖЭТ» Тяньваньской АЭС [32] и АЭС Куданкулам [33], в ходе работ над которыми автор возглавлял группу по созданию модели АСУ ТП. Новые обстоятельства заставили менять тренажерную технологию и создавать новые средства разработки. Модель АСУ ТП полномасштабного тренажера Тяньваньской АЭС поставляет фирма Сименс - разработчик АСУ ТП для станции. Данная АСУ ТП имеет следующие основные подсистемы: «AS-620» -автоматика режимов нормальной эксплуатации, «ОМ-690» - система верхнего блочного уровня (СВБУ), «ES-680» - инженерная станция для создания и изменения данных в «AS» и «ОМ». Ввод в эксплуатацию тренажера предполагался на два года раньше станции. По причине многочисленных ошибок различных типов в модели логики и видеокадрах СВБУ тренажер будет официально принят в эксплуатацию после вывода энергоблока на мощность с уже отлаженной «на объекте» АСУ ТП.
Связи с проектными таблицами и генерация типовых алгоритмов
Данная группа определяет таблицы, участвующие в параметризации блоков по ссылке. В них также находится информация о проектных таблицах технологических систем энергоблока и их связи с таблицами подобъектов. Описываются запросы для работы менеджера проектных таблиц и имена алгоритмов типовых решений. В группу входят таблицы: OBJECT_BAZA - головная таблица со списком таблиц, описывающие объекты, в том числе проектные. С ней связаны таблицы OBJECT_BAZA_SQL и OBJECT_BAZA_G (Таблица 3.12). OBJECT_BAZA_G - таблица типов оборудования, связанные с объектом. Так же здесь определяются имена типовых решений для каждого типа оборудования (Таблица 3.13). OBJECTBAZA SQL - таблица SQL запросов использования проектных данных в алгоритмах для менеджера проектных данных (Таблица 3.14). Состав и структура проектных данных технологических систем энергоблока могут быть произвольными и определяются проектантом АЭС. Каждый тип объекта (оборудования) проектных данных должен иметь свою таблицу. Каждый подобъект должен также иметь свою таблицу, связанную с таблицей объектов. Обычно структура таких таблиц представляет собой список оборудования и его характеристики. Для обеспечения связи проектных таблиц с программным комплексом необходимо выполнение следующих требований:
В таблице объекта должно быть ключевое поле "nomer" с типом «счетчик». Для подобъектов должна быть отдельная таблица, которая связанна с таблицей объекта по полю "nomer" и имеет ключевое поле "пот" с типом «счетчик». В таблице объекта должно быть поле "KKS" с именами KKS (система уникальных идентификаторов составных частей объекта). В таблице объекта должно быть поле "gen" - признак необходимости генерации типового алгоритма. В таблице объекта должно быть поле "type" для кода шаблона типового алгоритма. Для данных ПМТ АЭС Куданкулам использовались следующие таблицы: 0_МОТ - таблица моторов и нагревателей. 0_VLV - таблица задвижек, 0_REG - таблица регуляторов. С ней связана таблица OJREGCON -таблица контролеров. 0_SENSOR - таблица точек контроля. С ней связана таблица 0_SENSOR_UST - таблица уставок. OJKEY - таблица ключей оператора. С ней связана таблица OKEYPOS - таблица позиций ключей. Таблица SYS_GEN предназначена для отслеживания необходимости перегенерации модели в объеме трехбуквенной технологической системы KKS. Ее структура показана в Таблица 3.15. Таблица SKU_TYPE определяет список «программно-аппаратной» реализаций логики (тип проекта). Полностью функционирует проект «Алгоритмы АЭП» (название проекта LOGICOD). В настоящий момент идет создание проекта для работы с логикой ТПТС. Структура таблицы показана в Таблица 3.16. Существуют также служебные таблицы для конвертации алгоритмов из формата программы LOGICOD в проектную базу АСУ ТП. Это головная таблица LG для преобразования блоков LOGICOD в блоки SKUGEN, и связанные с ней таблицы: LG_PORT - для преобразования портов блоков и LG PROP - для преобразования параметризации. Создание программного комплекса SKUGEN осуществлялось на основе методики, описанной в главе 2. Программный комплекс является прообразом единого автоматизированного средства проектирования алгоритмов энергоблока и разработки их моделей на любом этапе проектирования с целью расчетного тестирования и обоснования проектных решений, выявления и устранения ошибок и создания тренажеров АЭС.
Основное назначение программного комплекса SKUGEN [39]: Проектирование логики в представлениях «алгоритмы АЭП» (с возможностью расширения для ПТК ТПТС, УКТС, Teleperm ХР) с привязкой к проектным данным технологических систем Обеспечение информационной поддержки для анализа логики Генерация модели алгоритмов для тестирования алгоритмов и создания тренажеров Получение информации о связи проектных данных с алгоритмами Организация работы в многопользовательском режиме с единым источником данных. Новизной комплекса также является решение организации интерфейса пользователя (проектировщика) функций информационного обеспечения для проведения анализа логики и «выборного» интерфейса параметризации в «пространстве проектных данных». Кроме того, предложено решение задачи организации интерфейса доступа к алгоритмам, хранящимся, как описано выше, не в отдельных файлах (общепринятый подход), а в единой базе данных. (В связи с этим, описание механизмов и функций программного комплекса сопровождается иллюстрациями интерфейса и его кратким описанием.)
Проектные данные асу тп энергоблока. преобразователь алгоритмов
Для разработки проекта логики АСУ ТП необходимы два типа данных - база данных технологических систем энергоблока и алгоритмы.
База технологических данных заполняется проектантами (технологами) АЭС и представляет собой набор таблиц со списком оборудования и их характеристиками. Комплекс SKUGEN позволяет работать как с копией базы проектанта, содержащей только необходимые поля в таблицах для модели алгоритмов АСУ ТП, так и непосредственно с самой базой (методическое требование №3, п.2.1).
Первый вариант более удобен при разработке тренажера. В этом случае может использоваться так называемая база с данными предварительной проектной спецификации (PDS) тренажера. Она заполняется разработчиками технологических моделей по проектным данным с учет объема моделирования ПМТ В этом случае все изменения, которые вносят разработчики моделей (отслеживая изменения в проектных данных), будут автоматически корректироваться в проекте АСУ ТП.
Второй вариант возможен для проектных организаций. Заполняемые технологом данные по оборудованию в проектную базу будут сразу доступны программному комплексу для работы. Все последующие изменения в проекте будут также автоматически учтены.
Основным оборудованием (объектами), используемым в модели алгоритмов АСУ ТП энергоблока являются задвижки, моторы (и нагреватели), регуляторы, точки контроля, ключи управления и др. В дальнейшем, как показал опыт, удобнее также рассматривать и другие «объекты» (например, АВР - аварийный ввод резерва), что увеличит степень автоматизации проектирования.
Объект может иметь характерные параметры, которые самостоятельно используются в алгоритмах (будем называть подобъекты). Например, таковыми являются уставки точек контроля, контроллеры регуляторов, позиции ключей управления и др.
Для каждого объекта в базе существует своя отдельная таблица со специфическим набором полей. Для работы комплекса SKUGEN с базой проектных данных имеются определенные требования к структуре таблиц, описанные в п. 3.4.
Данные-алгоритмы при проектировании должны прорисовываться в графическом редакторе. В готовом виде они поставляются от проектных организаций при создании тренажера. В этом случае оптимальным вариантом является разработка Преобразователя -программы, конвертирующей алгоритмы из формата проектантов в базу алгоритмов АСУ ТП.
Как уже было выше описано, на первом этапе работ создания ПМТ АЭС Куданкулам разработка модели СКУ НУ велась с помощью программы LOGICOD. Поставка алгоритмов ТЗБ (технологических защит и блокировок) осуществлялась в формате документов MS WORD (70-80% объема) и АВТОКАД (20-30%). Для заполнения первой версии алгоритмов был разработан Конвертор для формата MS WORD. Формат АВТОКАД вводился вручную. На момент готовности комплекса SKUGEN подавляющая часть алгоритмов уже имелась в LOGICOD.
В связи с этим встала задача разработать алгоритм преобразования формата LOGICOD в базу алгоритмов АСУ ТП. Правила преобразования блоков описаны в таблице LG, портов блоков - в таблице LGPORT, свойств блоков (параметры) - LGJPROP.
Входами алгоритмов ТЗБ (на 99%) являются сигналы с точек контроля, с других алгоритмов и сигналы состояния оборудования. Для сохранения связности алгоритмов процесс импорта был разбит на четыре этапа. В начале была произведена генерация типового алгоритма для всех исполнительных механизмов (моторы (нагреватели), задвижки, регуляторы). Эти алгоритмы представляли собой соответствующие блоки управления и два выхода - состояния закрыто/выключено (В02) и открыто/включено (В01) (см. Рисунок 4.2).
Вторым этапом преобразования было создание новых (пустых) функциональных планов в базе алгоритмов АСУ ТП, считывание по всем файлам алгоритмов LOGICOD только выходных блоков и их запись в соответствующие ФП в базе. Т.к. точки контроля находятся в проектной таблице и известны, все входные сигналы для любого алгоритма теперь имелись в базе. Третьим этапом стало чтение непосредственно топологии алгоритмов ТЗБ: по таблицам преобразования проводилась конвертация блоков, их графического местоположения с учетом координат, соединений и параметров.
Четвертым этапом стал ввод входных сигналов для алгоритмов управления, расставляемых на плане по определенному графическому правилу (в LOGICOD эти алгоритмы не имели графического представления) и соединяемых по ИЛИ (если больше двух на один вход).
В ходе выполнения этих этапов было обнаружено и исправлено около 180 ошибок связности алгоритмов из около 2000 алгоритмов.
Алгоритм импорта (преобразования) информации из программного средства LOGICOD, подробно описанный выше, является универсальным для данных любого другого программного средства моделирования алгоритмов, не имеющего механизма связности алгоритмов и параметризации.
Связь графических приложений с исполнительной системой
Связь графических приложений (панели) с исполнительной системой WmMod осуществляется посредством базы HARDWARE. База находится на компьютере с исполнительной системой. Панели могут находиться как на этом же компьютере, так и на других, соединенных локальной сетью. В последнем случае база должна быть доступным сетевым ресурсом. Выбор механизма обмена посредством базы был обусловлен следующими преимуществами: Скорость обмена. Для задач этого типа данный механизм обеспечивает обмен с достаточным запасом. Актуальность состояния. В базе всегда находятся актуальные (соответствующие модельным переменным) значения не текущий момент времени. Потеря данных при асинхронном чтении графическими приложениями не критична для обслуживаемых WinMod-ом задач.
На современных ПЭВМ потеря данных практически отсутствует. Относительная простота реализации обмена (необходимые механизмы уже созданы разработчиками СУБД). При запуске панель инициирует таймер и с частотой 5 раз в секунду производит чтение значений переменных, местоположение которых в базе характеризуется именем таблицы, номером записи, именем поля и номером бита (для логических переменных). Запись в базу переменных управления происходит по факту события (например, нажатии мышкой на элемент управления). Частота чтения и записи интерфейсных переменных исполнительной системой по умолчанию также 5 раз в секунду, но может быть изменена в интервале 1-Ю Гц. С использованием системы WinMod в ОАО «ДЖЭТ» были разработаны два аналитических симулятора: «ТОМАС-1» для АЭС с реактором ВВЭР-1000 [25], [26] и «ТОМАС-2» [27] для АЭС с реактором РБМК-1000. Программный комплекс "ТОМАС-1" (Тренажер Оперативного Моделирования Аварийных Ситуаций) позволяет моделировать нормальные, переходные и аварийные режимы работы АЭС с ВВЭР-1000 (проект В-320). Программный комплекс имеет следующие структурные составляющие [40]: - математическую модель энергоблока, описывающую нейгронно-физические, теплогидравлические, электрические и логические процессы в оборудовании и системах управления АЭС; - математическую модель для анализа тяжелых аварий, описывающую процессы разогрева, плавления и разрушения активной зоны и корпуса реактора и взаимодействие расплава с бетоном. Математические модели симулятора частично разработаны с использованием системы WinMod, частично - использованы модели технологических систем, разработанные для аналогичных полномасштабных тренажеров. Нейтронно-физическая модель активной зоны представляет собой 3-мерный 2-групповой квазистатический конечно-разностный расчет поля нейтронов. Модель первого контура реакторной установки и его вспомогательных систем разработана на основе кода RETACT. В программе реализована двухскоростная, термодинамически неравновесная модель одномерного пароводяного потока, содержащего неконденсируемые газы, бор и радиоактивные примеси. Модель турбоустановки и питательного тракта разработана на основе кода CMS для моделирования теплогидравлической сети с двухфазной средой. Система герметичных помещений - контайнмент также моделируется в рамках кода CMS с учетом работы спринклерной системы.
В программном комплексе моделируются также все системы безопасности и система электроснабжения собственных нужд. Для моделирования работы всех регуляторов реакторной установки была разработана библиотека программ, описывающих алгоритмы работы регуляторов, их блокировки и изменения уставки.
