CC BY
45
Доклады БГУИР
2015 № 2 (88)
УДК 621.039.4
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА СКВОЗНОГО ПРОЕКТИРОВАНИЯ СИСТЕМ КОНТРОЛЯ И УПРАВЛЕНИЯ НА БАЗЕ ТПТС
М.А. БЕЛОНОСОВ, Ю.С. ГАЛИЦЫН, Ю.В. КРАЮШКИН*, И М. ЖУКОВ*, С.Ю. ГРИЦЕНКО
Всероссийский научно-исследовательский институт автоматики им. Н. Л. Духова Сущевская, 22, Москва, 127055, Россия
*НИЯУ «Московский инженерно-физический институт» Каширское шоссе, 31, Москва, 115409, Россия
Поступила в редакцию 2 февраля 2015
Одним из важных факторов, определяющих качество и оптимальность сложных систем контроля и управления, является уровень используемой САПР. В статье рассматриваются технические решения и принципы, положенные в основу инструментальных средств нового поколения, применяемых для разработки программно-технических комплексов систем контроля и управления на базе ТПТС.
Активное строительство новых АЭС в России и за рубежом привело к росту потребности в развитых системах контроля и управления (СКУ), основанных на цифровых программно-технических комплексах (ПТК). Программно-технические средства ТПТС-51 стали первой цифровой микроконтроллерной техникой, производство которой было полностью освоено российским институтом автоматики (ВНИИА). Как сами средства ТПТС, так и среда проектирования GET-R (Graphic Engineering Tool - Russia) являются развитием техники Teleperm ME и САПР GET-TM фирмы Siemens, которая передала ВНИИА свои технологии по лицензионному договору.
Первым российским атомным энергоблоком, в котором применена цифровая СКУ на средствах ТПТС-51, стал третий энергоблок Калининской АЭС, пуск которого состоялся 16 декабря 2004 года. В процессе создания ПТК СКУ этого энергоблока специалисты ВНИИА, ВНИИАЭС, Атомэнергопроект и ряда других организаций освоили инструментальные средства проектирования GET и адаптировали к российским реалиям технологию проектирования СКУ, унаследованную от Siemens.
Оказалось, что освоенная технология и инструментальные средства не покрывают все проектные задачи, возникающие при создании ПТК СКУ. Были выявлены следующие недостатки:
— ряд документов, выпускаемых на различных этапах проектирования, необходимо отдельно создавать с помощью офисного программного обеспечения, не связанного с электронным проектом СКУ;
— связи между различными частями проекта СКУ не отслеживаются инструментальной средой, что повышает вероятность возникновения проектных ошибок;
— алгоритмы управления создаются в таком виде, который требует от специалистов различного профиля знаний специфики программно-технических средств ТПТС;
— инструментальные средства не приспособлены для создания разных частей проекта разными организациями, т.к. не предусмотрена поэтапная работа над проектом.
Работа над устранением этих недостатков продолжается до сих пор. Однако уже сейчас можно говорить о принципиально новом уровне проектирования, достигнутом благодаря совместным усилиям ВНИИА и ряда других организаций.
Одной из главных причин пересмотра подходов к проектированию стала разработка новых поколений аппаратуры ТПТС и работы по созданию новой системы проектирования ОЕТ-Я1. В результате появилась концепция технологии проектирования, которая покрывает все основные этапы проектирования СКУ и приспособлена к российским условиям.
Подход к проектированию
В разработке системы контроля и управления всегда участвуют две ключевые фигуры: специалист-технолог, понимающий технологические процессы АЭС, которыми нужно управлять; и специалист-системщик, знающий принципы управления, особенности взаимодействия частей системы и технику, на которой построены ПТК.
В случае небольших систем управления, например, систем типа «умный дом», технолог и системщик - это, как правило, одно и тоже лицо. Используя понимание технологического процесса и знание технических средств, такой специалист легко может самостоятельно создать простую систему управления.
Более сложные промышленные СКУ, например, в тепловой энергетике, обычно создаются разными специалистами; однако за систему управления в целом несет ответственность одна организация.
В случае СКУ АЭС проектирование выполняется большими коллективами разных организаций, которые поэтапно создают одну большую систему управления. В этой ситуации необходимо четкое разделение ответственности за части проекта СКУ, а также подход и инструментарий, которые позволят специалистам разного профиля вести проектирование, используя только свои знания. Задача контроля соответствия различных частей проекта ложится на средства проектирования и автоматизируется. Автоматизируется также часть работ по преобразованию данных между различными этапами. Как следствие, все организации, участвующие в разработке, должны пользоваться одной системой проектирования, или интегрированными средами, как в случае САПР низовой автоматики и САПР верхнего уровня. Разделение ответственности показано на рис. 1.
Генпроектировщик
Изготовитель ПТК СВБУ
Изготовитель ПТК низовой автоматики
Рис. 1. Части проекта СКУ АЭС, взаимосвязи и разделение ответственности
В создании системы управления атомного энергоблока принимают участие следующие организации:
— проектная организация (генпроектировщик);
— организация - изготовитель ПТК нижнего уровня;
— организация - изготовитель ПТК верхнего уровня (СВБУ);
— организация - изготовитель блочного щита управления (БЩУ).
Инструментальные средства нового поколения
Вышеописанный подход реализован специалистами ВНИИА и МИФИ в САПР нового поколения ОЕТ-Я1. Поскольку разработка основных частей проекта разделена во времени и выполняется разными организациями, система реализована таким образом, чтобы была возможность последовательно разрабатывать и хранить все основные части проекта СКУ (рис. 2).
Помимо поэтапной разработки проекта, система управления энергоблоком имеет функциональное деление на подсистемы, которое задается проектной организацией. Проект СКУ энергоблока создается по частям, имеющим общее функциональное назначение (например, система управления пожаротушением или система управления химводоочисткой). Таким образом, имеется горизонтальное и вертикальное деление проекта СКУ. На рис. 2 показана реализация такого многоуровневого разделения.
Рис. 2. Этапы и функциональное деление проекта СКУ
Разработка типовых алгоритмов, базы данных технологического оборудования на первом этапе и технологических алгоритмов СКУ на втором этапе выполняется проектной организацией. Проект на этих этапах не зависит от технических средств автоматики. Проектная организация выполняет также проектирование и третьего этапа, на котором определяются виды и набор технических средств СКУ. Совокупно документация этапов 1, 2 и 3 является основанием для запуска производства ПТК.
Алгоритмы управления на этапе 4 создаются автоматизированно на основе документации первого и второго этапов. Однако на этом этапе проектной организации необходимы специалисты-системщики, знающие принципы управления и знакомые со спецификой выбранных технических средств. Этап 5 выполняется разработчиком верхнего уровня совместно с проектной организацией. Этап 6 выполняется производителем выбранных технических средств и завершается функциональными испытаниями ПТК.
Разработанные инструментальные средства ОЕТ-Ю полностью покрывают работы по созданию алгоритмов управления и документации по подключениям. Верхний уровень создается производителем верхнего уровня с помощью специфического программного обеспечения. Определен формат данных на этапе 4, на основе которого проект верхнего уровня может быть создан любым производителем.
При разработке данного подхода учтен международный опыт проектных организаций (АО «Атомэнергопроект», АО «Атомпроект») по созданию АСУ для энергоблоков АЭС Бушер, Куданкулам и Тяньвань, а также опыт проектирования СКУ российских энергоблоков.
Верификация и автоматизированное преобразование
Особое внимание при разработке описываемого подхода уделено вопросам хранения данных, преобразования данных между этапами и верификации данных. Этапы 2, 4 и 6 (см. рис. 2) являются последовательным развитием одного проекта. Алгоритм технолога на этапе 2, алгоритм управления на этапе 4 и код ТПТС на этапе 6 - один и тот же объект, вклад в разработку которого вносят разные специалисты в разное время. Однако состояние этого
объекта на каждом этапе хранится отдельно. Переход от технологического алгоритма на этапе 2 к алгоритму управления на этапе 4 выполняется автоматизированно с помощью специальной процедуры преобразования. Переход от алгоритма управления к коду прикладной программы ТПТС выполняется автоматически с помощью процедуры генерации кода.
На этапах 4 и 6 введены процедуры автоматической верификации, которые позволяют убедиться в том, что при конвертации и последующей доработке не было сбоев, а также выявить ошибки, допущенные проектировщиком. Цель процедуры верификации алгоритмов управления - выявить несоответствия алгоритмов управления технологическим алгоритмам, если их допустил специалист-системщик. Верификация выполняется путем анализа и сравнения последовательностей функциональных блоков в алгоритмах обоих этапов.
Процедура верификации кода также решает задачу формального подтверждения корректности процедуры генерации. Верификация кода (рис. 3) производится путем обратного восстановления структуры проектных данных по коду и последующего сравнения полученной структуры с данными проекта. Идентичность проектных и восстановленных данных является доказательством соответствия кода и алгоритмов управления.
Установка значений параметров ФБ
Сравнение полученных и исходных параметров ФБ
Подтверждение идентичности ППО и проекта
-»( Выход )
Рис. 3. Алгоритм верификации кода прикладных программ ТПТС
Автоматизация графического проектирования
Часто существует необходимость проведения многочисленных изменений в проекте. Для этого необходимо проделать большое количество однотипных операций, что повышает вероятность допущения ошибки. Для этих задач был разработан специальный проблемно-ориентированный скриптовый язык САПР. Возможности скриптового языка позволяют оперировать всеми функциями проектирования с помощью специального набора команд. В скриптовый язык заложена полная поддержка набора команд предыдущих версий САПР. Базовая концепция синтаксиса языка и набор конструкций программирования похожи на скриптовый язык, встроенный в пакет математического моделирования МайаЬ. Встроенная в САПР среда с подсветкой синтаксиса позволяет осуществлять разработку и отладку скриптовых программ.
Рис. 4. Интерфейс и пример программы на скриптовом языке программирования САПР
Моделирование
Возможность компьютерного моделирования встроена в САПР ОЕТ-Я1 и используется как на этапе разработки технологических алгоритмов, так и при создании прикладного ПО СКУ.
Цель моделирования на этапе технологических алгоритмов - выявление ошибок алгоритма на ранних стадиях. Назначение моделирования конечного проекта прикладного ПО СКУ - статическое тестирование алгоритмов управления и выполнение дополнительных автоматических проверок сгенерированных кодов ТПТС.
При помощи модели проектировщик может проверить, так ли работает алгоритм, как он рассчитывал. Кроме того, он может проверить взаимодействие различных алгоритмов. В процессе генерации модели также происходит автоматическая проверка алгоритмов.
Компьютерное моделирование обеспечивает полную повторяемость результата эксперимента при повторении исходных воздействий на алгоритм. Для ускорения работы предусмотрена возможность повторить эксперимент не с самого начала, а с произвольного момента времени. Это достигается за счет запоминания состояния модели в определенный пользователем момент времени.
Заключение
Результатом проведенной работы является технология сквозного проектирования сложных систем управления для атомных энергоблоков.
Разработанная технология проектирования заложена в инструментальные средства нового поколения ОЕТ-Я1. Инструментальные средства прошли апробацию при разработке проекта системы управления Ленинградской АЭС-2 и используются при проектировании СКУ Белорусской АЭС.
Можно утверждать, что предлагаемый подход позволяет значительно повысить эффективность при создании сложных систем управления, когда в разработку вовлечены большие коллективы разных организаций и необходимо разделить ответственность между ними, одновременно обеспечив прозрачность процесса проектирования и однородность проектных данных.
