Что такое всру на аэс
Ядерный реактор для чайников: замыкание топливного цикла в двухкомпонентной ядерной энергетике
БН-800 на Белоярской АЭС — один из двух в мире действующих реакторов на быстрых нейтронах. Выведен на номинальную мощность в 2015 году
Под катом — рассказ про устройство классических ядерных реакторов на тепловых нейтронах, принцип работы ядерных реакторов на быстрых нейтронах (в мире их всего два, и оба в России) и замыкание ядерного топливного цикла.
Уверена, это будет интересно тем, кому пришелся по вкусу рассказ про международную стройку 500-мегаваттного термоядерного реактора ITER.
Наш рассказчик — Алексей Германович Горюнов, заведующий кафедрой и руководитель отделения ядерно-топливного цикла инженерной школы ядерных технологий из томского Политеха, который прочитал лекцию про двухкомпонентную энергетику в томской Точке кипения.
Сегодняшний рассказ — о новых технологиях мирного атома: замыкании ядерно-топливного цикла и двухкомпонентной ядерной энергетике.
Но начнем с того, как ядерно-топливный цикл функционирует сейчас.
Классический топливный цикл
В больших реакторах, преобладающих в ядерной энергетике, таких как водо-водяной ВВР-1000 или канальный РБМК-1000, отработанное топливо не перерабатывают. Его хранят в бассейнах выдержки реакторов, а потом перевозят на площадку долговременного хранения на базе горно-химического комбината.
Базовый процесс получения топлива дорогой, а сырье — исчерпаемый ресурс, поэтому человечество напряженно решает задачу по замыканию топливного цикла — это когда из ядерных отходов опять производят топливо. Сейчас эта схема существует лишь в небольшом сегменте ядерной энергетики — в транспортных и исследовательских реакторах.
Давайте теперь посмотрим на устройство современных реакторов.
Ядерные реакторы на тепловых нейтронах
Схематично атомную станцию с ядерным реактором на тепловых нейтронах можно представить так:
Далее мы будем говорить о так называемом ядерном острове, куда входит реакторная часть. Рассмотрим, какие реакторы используются в настоящее время, а какие могут быть запущены в ближайшем будущем.
Условная схема ядерной электростанции
Реактор — это устройство, в активной зоне которого осуществляется контролируемая самоподдерживающаяся цепная реакция деления ядер тяжелых элементов, в частности урана-235. Сегодня наиболее распространены водо-водяные энергетические блоки. На картинке — схема как раз такого реактора.
Условная схема электростанции с водо-водяным реактором
Реактор находится в защищенном корпусе и примыкает к отдельному зданию, где размещают традиционные энергетические узлы — турбинный зал и другие, которые есть в обычных теплоэнергетических станциях.
Обычно в реакторах используют четыре нити охлаждения для повышения надежности. Первый контур охлаждения реактора включает сам реактор, а также главные циркуляционные насосы. Их число соответствует количеству нитей охлаждения — четыре. На каждой из нитей охлаждения установлен парогенератор, который отделяет первый контур реактора от второго, содержащего теплоноситель, поступающий в традиционный остров.
Энергетическая установка с реактором ВВР
Общий вид самого реактора:
Стоит отметить, что это корпусной реактор, такая конструкция позволяет достичь высоких показателей по безопасности.
Ядерные реакторы на быстрых нейтронах
Сначала немного физики. Напомню, изотопы — это элементы, имеющие одинаковые атомные номера, но разный атомный вес. Самое интересное, что они имеют разные свойства. К примеру, уран-238 практически не делится в реакторах на тепловых нейтронах, а уран-235 — делится. Чтобы описать вероятность деления изотопа, в ядерной физике используют понятие «сечение деления».
Сечение реакции деления ядер изотопов урана, плутония и тория в зависимости от энергии нейтронов
Рисунок наглядно показывает, что для урана-235 и плутония-239 мы можем создать цепную реакцию, используя как тепловые, так и быстрые нейтроны. А уран-238 в левой части графика (где находятся тепловые нейтроны) делиться не будет. В природе же распространен в основном изотоп урана-238, который нельзя напрямую использовать в реакторе на тепловых нейтронах. Урана-235 в природе содержится очень мало, а для получения топлива необходимо проводить дорогостоящее обогащение.
Реактор на быстрых нейтронах позволяет уйти от процедуры обогащения по урану-235. Но технически все не так просто.
В реакторе на тепловых нейтронах, как и в целом во всех современных энергетических установках, в качестве теплоносителя используют воду. Именно она переносит тепловую энергию к турбинам. С ней понятно, как работать, какие использовать конструкционные материалы. Однако из ядерной физики мы знаем, что вода замедляет быстрые нейтроны, появляющиеся при делении ядер.
Поэтому в реакторе на быстрых нейтронах в качестве теплоносителя, как правило, используются жидкие металлы, что существенно усложняет конструкцию.
Здесь приходится решать целый пласт научных и опытно-конструкторских задач, в том числе — разрабатывать новые материалы.
Наиболее вероятная реакция в реакторе на быстрых нейтронах — поглощение нейтрона изотопом урана-238 — показана на схеме ниже.
Уран-235 и плутоний-239 схожи по своим свойствам. На базе этих ядер мы вполне можем получить цепную реакцию: поглощая как быстрые, так и медленные нейтроны, ядра будут делиться, испуская вторичные, третичные нейтроны и т.д.
Исторически сложилось, что наиболее проработанные на сегодняшний день реакторы на быстрых нейтронах — БН-600 и БН-800.
А Россия — единственная страна в мире, имеющая действующие промышленные ядерные реакторы на быстрых нейтронах.
Их устройство намного сложнее, чем у двухконтурного водо-водяного реактора на тепловых нейтронах, поскольку в качестве теплоносителя используют жидкий натрий с температурой плавления
Схема энергоблока с реактором на быстрых нейтронах
В реакторах с натриевым теплоносителем мы не можем использовать двухконтурную схему, где первый контур заполнен натрием, а второй — водой, поскольку случайное взаимодействие облученного натрия с водой приведет к особо тяжелым последствиям. В ходе реакции этих двух веществ выделяется взрывоопасный водород, и в случае взрыва нейтрализовать фонящий натрий будет крайне проблематично. Поэтому используют трехконтурную схему. Первый контур — натриевый (на рисунке он показан красным в центре реактора), потом теплообменник и еще один (промежуточный) натриевый контур (желтый цвет), позволяющий снизить степень облучения натрия, и только в третьем контуре используется вода, установлена турбина, тепловые части и остальное оборудование. Три контура усложняют как эксплуатацию реактора, так и управление им.
Следующий шаг — БРЕСТ
Энергокомплекс БРЕСТ-300 — следующий этап развития. Создается он в рамках росатомовского проекта «Прорыв». Вместо натрия в качестве теплоносителя используют свинец (tплав. 327℃). Это позволяет, как и в водо-водяных реакторах, использовать всего два контура, упрощает управление и повышает энергоэффективность.
Конструкция этого реактора обеспечивает так называемую естественную безопасность: на этом реакторе невозможна авария из-за неконтролируемого появления нейтронов, приводящего к цепным реакциям (разгона реактора по мощности).
На этот реактор возлагают большие надежды. В нем можно «сжигать» делящиеся элементы и нарабатывать плутоний, а потом использовать его для замыкания ядерно-топливного цикла.
Цель замыкания — постепенно исключить часть цепочки, связанную с добычей урана его обогащением, а также повторно использовать ядерные отходы.
Двухкомпонентная энергетика — это решение задачи по уменьшению количества обогащенного природного урана, необходимого для работы всех этих реакторов. Она еще не достигла пика своего развития — это то, чем будет заниматься поколение сегодняшних школьников.
В настоящее время в реакторах на быстрых нейтронах мы начинаем нарабатывать делящиеся элементы, которые впоследствии позволят загружать сюда топливо, не обогащенное по урану-235.
БН-600 и БН-800 уже работают на так называемом МОКС-топливе (MOX — Mixed-Oxide fuel) — смеси, включающей оксиды плутония-239 и урана. Причем реакторы могут работать как на топливе, обогащенном по урану-235 — и в этом случае нарабатывать плутоний-239, — так и на плутонии.
Частично замкнутый цикл использования ядерного топлива
На базе Опытно-демонстрационного центра в Северске, а в будущем и завода ФТ-2 в Железногорске, есть хранилище отработанного ядерного топлива. Сейчас на финальной стадии разработки находится технология, которая позволит переработать топливо после реактора ВВР и вернуть из него в цикл уран и плутоний. Задачу переработки решают весьма интересно: уран и плутоний не разделяют, а передают на производство в смешанном виде. В итоге мы получаем тепловыделяющие сборки для реакторов, содержащие регенерированный уран и плутоний, а также добавленный туда природный уран, обогащенный по изотопу-235.
Конечно, полного замыкания ядерно-топливного цикла здесь нет, но этот подход позволяет снизить затраты на обогащение.
Кроме того, делящиеся элементы, которые мы будем извлекать из отработанного в реакторах ВВР топлива, пойдут на топливные циклы быстрых реакторов.
Сейчас уже отработана схема загрузки в реактор БН-800 МОКС-топлива, содержащего плутоний-239 и уран-238, его путь на рисунке ниже показан красной линией.
Схема подразумевает использование отработанного ядерного топлива (ОЯТ) из реактора ВВЭР совместно с оксидным топливом с ураном-235 после реакторов БН. В ходе переработки мы выделяем смесь плутония и урана, которая идет на изготовление МОКС-топлива. А отработанное МОКС-топливо перерабатывают вместе с топливом после реактора РБМК.
Получается, что мы начинаем с обычной загрузки реакторов оксидным топливом на базе урана-235 и постепенно, нарабатывая плутоний-239 в быстром реакторе, вытесняем его МОКС-топливом.
Мы не сможем сразу перейти с традиционных реакторов на быстрые, потому что для каждого реактора на быстрых нейтронах придется построить инфраструктуру по переработке топлива, которая в первое время не будет загружена, ведь реакторы должны наработать топливо, которое впоследствии будет перерабатываться. А в схеме выше заложен плавный переход от существующих реакторов к быстрым. Эта схема подразумевает наработку плутония на реакторе БН-800. В перспективе должны появиться более мощные и более рентабельные установки — БН-1200, которые воплотят двухкомпонентность нашей ядерной энергетики на ближайшее десятилетие и стратегию того же Росатома.
Но интереснее то, что происходит в проекте БРЕСТ. Реактор такого типа с электрической мощностью 300 МВт уже начали возводить в Северске. Вокруг него построят комплекс, который позволит решать задачи регенерации топлива, т.е. все процессы в рамках замыкания топливного цикла будут сосредоточены в одном месте.
На начальном этапе будет нужна подпитка природным или обедненным ураном, как отмечено на картинке. Не имея нужного объема плутония, мы можем, как и в предыдущей схеме, стартовать, используя комбинированное топливо, и постепенно нарабатывать плутоний, переходя на замкнутый цикл.
На этот реактор возлагают большие надежды: упомянутый выше естественный контур защиты не позволяет разогнать его до тяжелых аварий. Но здесь придется столкнуться с рядом проблем. Задачи, связанные с наработкой плутония, уже в какой-то степени решали. А вот переработка ядерного топлива после быстрых реакторов — вопрос открытый. Здесь нужно обеспечить короткую выдержку топлива: оно горячее и с высоким радиационным фоном. Нужно создавать новые технологические процессы, отрабатывать их на стендах и внедрять.
Если задача по замыканию ядерного топливного цикла будет решена, то в масштабах жизни человека мы получим практически неисчерпаемый источник энергии.
Параллельно необходимо довести до конца решение задачи по выводу отходов из цикла без нарушения естественного радиационного баланса Земли. Проектируемый топливный цикл должен обеспечить возврат ровно того же количества радиации, которое мы извлекли. Теоретически эта задача просчитана и может быть решена. Дело за практикой.
Высоконагруженная распределенная система управления современной АЭС
Без электричества не будет высоконагруженных интернет-сервисов, которые мы так любим. Как ни странно, системы управления объектами генерации электричества, например атомными электростанциями, тоже бывают распределенные, тоже подвержены высоким нагрузкам, тоже требуют множества технологий. К тому же, доля атомной энергетики в мире будет расти, управление этими объектами и их безопасностью – очень важная тема.
Поэтому давайте разбираться, что там есть, как оно все устроено, где основные архитектурные сложности и где в АЭС можно применить модные технологии ML и VR.
Атомная электростанция это:
О спикере: Вадим Подольный (electrovenic) представляет Московский завод Физприбор. Это не просто завод — это прежде всего инжиниринговое бюро, в котором разрабатывается как аппаратное, так и программное обеспечение. Название является данью истории предприятия, которое существует с 1942 года. Это не очень модно, но очень надежно – вот что хотели им сказать.
IIoT на АЭС
Физприбор предприятие производит весь комплекс оборудования, который необходим для обеспечения сопряжения всего огромного количества подсистем – это датчики, контроллеры низовой автоматики, платформы для построения контроллеров низовой автоматики и пр.
В современном исполнении контроллер – это просто промышленный сервер, у которого расширенное количество портов ввода-вывода для сопряжения оборудования со специальных подсистем. Это огромные шкафы — такие же, как серверные, только в них располагаются специальные контроллеры, которые обеспечивают вычисления, сбор, обработку, управление.
Мы разрабатываем программное обеспечение, которое устанавливается на эти контроллеры, на шлюзовое оборудование. Дальше также, как и везде, у нас есть ЦОДы, локальное облако, в котором происходит обсчет, обработка, принятие решения, прогнозирование и все, что необходимо для того, чтобы функционировал объект управления.
Следует отметить, что в наш век оборудование уменьшается, становится умнее. На многих элементах оборудования уже есть микропроцессоры – маленькие компьютеры, которые обеспечивают предварительную обработку, как это сейчас модно называть – граничные вычисления, которые производятся, чтобы не нагружать общую систему. Поэтому можно сказать, что современная АСУ ТП АЭС – это уже что-то типа индустриального интернета вещей.
Платформа, которая этим управляет – это платформа IoT, про которые многие слышали. Их сейчас немалое количество, наша – очень жестко привязана к реальному времени.
Поверх этого всего строятся механизмы сквозной верификации и валидации, чтобы обеспечить проверку совместимости и надежности. Туда же входит нагрузочное тестирование, регрессионное тестирование, модульное тестирование – все, что вы знаете. Только это делается вместе с железом, которое нами спроектировано и разработано, и ПО, которое работает с этим железом. Решаются вопросы кибербезопасности ( secure by design и т.д.).
На рисунке изображены процессорные модули, которые управляют контроллерами. Это 6-юнитовая платформа с шасси для размещения материнских плат, на которые мы производим поверхностный монтаж необходимого нам оборудования, в том числе процессоров. Сейчас у нас волна импортозамещения, мы стараемся поддерживать отечественные процессоры. Кто-то говорит, что в результате безопасность индустриальных систем повысится. Это действительно так, чуть позже объясню, почему.
Система безопасности
Любая АСУ ТП на АЭС резервируется в виде системы безопасности. Энергоблок АЭС рассчитан на то, что на него может упасть самолет. Система безопасности должна обеспечить аварийное расхолаживание реактора, для того чтобы вследствие остаточного тепловыделения, которое возникает из-за бета-распада, он не расплавился, как это произошло на АЭС Фукусима. Там не было системы безопасности, волной смыло резервные дизель-генераторы, и случилось то, что случилось. На наших АЭС такое невозможно, потому что там стоят наши системы безопасности.
Основа систем безопасности – это жесткая логика.
Фактически мы отлаживаем один или несколько алгоритмов управления, которые могут объединяться в функционально-групповой алгоритм, и всю эту историю распаиваем прямо на плату без микропроцессора, то есть получаем жесткую логику. Если когда-нибудь какой-то элемент оборудования нужно будет заменить, у него изменятся уставки или параметры, и потребуется внести изменения в алгоритм его работы – да, придется вынуть плату, на которой распаян алгоритм, и поставить новую. Но зато это безопасно – дорого, но безопасно.
Ниже пример троированной системы диверсной защиты, на которой выполняется алгоритм решения одной задачи системы безопасности в варианте исполнения два из трех. Бывают три из четырёх – это как RAID.
Технологическое разнообразие
Во-первых, важно использовать различные процессоры. Если мы делаем кроссплатформенную систему и общую систему набираем из модулей, работающих на различных процессорах, то в случае, если внутрь системы на каком-то из этапов жизненного цикла (проектирования, разработки, планово-предупредительного ремонта) попадет вредоносное программное обеспечение, то оно не поразит сразу все диверсное разнообразие техники.
Также есть количественное разнообразие. Вид полей со спутника хорошо отражает модель, когда мы максимально с точки зрения бюджета, пространства, возможности понимания и эксплуатации выращиваем разнообразные культуры, то, есть реализуем избыточность (redundancy), максимально копируя системы.
Ниже примерный алгоритм выбора решения на основе троированной системы диверсной защиты. Алгоритм считается правильным на основе двух из трех ответов. Мы считаем, что, если один из шкафов выйдет из строя, мы, во-первых, об этом узнаем, во-вторых, два остальных будут нормально работать. Таких шкафов на АЭС целые поля.
Про железо поговорили, перейдем к тому, что всем интереснее – к софту.
Программное обеспечение. Вершок и Корешок
Так выглядит система мониторинга как раз этих шкафов.
Система верхнего уровня (после низовой автоматики) обеспечивает надежный сбор, обработку, доставку информации оператору и другим интересующимся службам. Она должна прежде всего решать главную задачу – в момент пиковых нагрузок уметь все разруливать, поэтому в режиме нормальной эксплуатации система может быть загружена на 5-10%. Остальные мощности фактически работают вхолостую и предназначены для того, чтобы в случае нештатной ситуации все перегрузки мы смогли бы балансировать, распределять, обрабатывать.
Самый характерный пример – турбина. Она дает больше всего информации, и если начинает работать нестабильно, фактически случается DDoS, потому что вся информационная система забивается диагностической информацией с этой турбины. В случае, если QoS плохо отработает, могут возникнуть серьезные проблемы: оператор просто не увидит часть важной информации.
На самом деле все не так страшно. Оператор может проработать на физическом реактиметре 2 часа, но потерять при этом какое-то оборудование. Для того, чтобы этого не происходило, мы разрабатываем нашу новую программную платформу. Предыдущая версия сейчас обслуживает 15 энергоблоков, которые построены в России и за рубежом.
Программная платформа – это кроссплатформенная микросервисная архитектура, которая состоит из нескольких слоев:
Облако нарезается на виртуальные машины, где-то запускаются контейнеры. В рамках контейнерной виртуализации запускаются различные типы узлов, которые по необходимости выполняют разные задачи. Например, можно раз в день запустить генератор отчетов, когда все необходимые отчетные материалы за день будут готовы, виртуальные машины будут выгружены, и система станет готова для решения других задач.
Свою систему мы назвали Вершок, а ядро системы Корешок – понятно, почему.
Имея достаточно мощные вычислительные ресурсы на шлюзовых контроллерах, мы подумали – а почему бы не использовать их мощности не только для предварительной обработки? Мы же можем превратить это облако и все пограничные узлы в туман, и нагружать эти мощности задачами, например, такими, как выявление погрешностей.
Иногда бывает так, что датчики приходится тарировать. Со временем показания плывут, мы знаем, по какому графику во времени они изменят свои показания, и вместо того, чтобы эти датчики менять, уточняем данные и делаем поправки – это называется тарировка датчиков.
Мы получили полноценную Fog-платформу. Да, она выполняет ограниченное количество задач в тумане, но мы будем потихонечку увеличивать их число и разгружать общее облако.
Кроме того, у нас есть вычислительное ядро. Мы подключаем язык сценариев, умеем работать с Lua, с Python (например, библиотекой PyPy), с JavaScript и TypeScript для решения задач с пользовательскими интерфейсами. Эти задачи мы можем одинаково хорошо выполнять как внутри облака, так и на граничных узлах. Каждый микросервис может запускаться на процессоре абсолютно любого объема памяти и любой мощности. Просто он будет обрабатывать тот объём информации, который возможно на текущих мощностях. Но система одинаково работает абсолютно на любом узле. Она же подходит для размещения на простых IoT устройствах.
Сейчас в эту платформу попадает информация из нескольких подсистем: уровня физической защиты, системы контроля управлением доступом, информация с видеокамер, данные пожарной безопасности, АСУ ТП, IT-инфраструктуры, события информационной безопасности.
На основе этих данных строится Behavior Analytics – поведенческая аналитика. Например, оператор не может быть залогинен, если камера не зафиксировала, что он прошел в операторскую. Или другой кейс: видим, что какой-то канал связи не работает, при этом фиксируем, что в этот момент времени изменилась температура стойки, была открыта дверца. Кто-то зашел, открыл дверцу, вытащил или задел кабель. Такого, конечно, быть не должно, но мониторить это все равно нужно. Необходимо описывать максимально большое количество кейсов, чтобы когда что-то вдруг случится, мы точно знали, что.
Выше примеры оборудования, на котором все это работает, и его параметры:
Наши сервисы работают в режиме Multi-Master, нет единой точки отказа, все это кроссплатформенное. Узлы самоопределяются, можно делать Hot Swap, за счет чего можно добавлять и менять оборудование, и нет зависимости от выхода из строя одного или нескольких элементов.
Есть такое понятие, как деградация системы. До определенной степени оператор не должен замечать, что с системой что-то происходит не так: сгорел процессорный модуль, или пропало питание на сервере и он отключился; канал связи перегрузился, потому что не справляется система. Эти и подобные проблемы решается за счет резервирования всех компонентов и сети. Сейчас у нас работают топология «двойная звезда» и mesh. Если какой-то узел выходит из строя, то топология системы позволяет продолжить нормальную работу.
Это сравнения параметров Supermicro (сверху) и нашего контроллера (внизу), которые мы получаем по апдейтам на базе данных реального времени. Цифры 4 и 8 – это количество реплик, то есть база данных поддерживает актуальное состояние всех узлов в реальном масштабе времени – это multicast и real-time. В тестовой конфигурации примерно 10 млн тэгов, то есть источников изменения сигналов.
Supermicro показывает в среднем 7 M/c или 5 М/с, при увеличении числа реплик. Мы боремся, чтобы не терять мощность системы, с ростом числа узлов. К сожалению, когда возникает необходимость обработки уставок и других параметров, мы теряем скорость с увеличением количества узлов, но чем больше узлов, тем потери меньше.
На нашем контроллере (на Atom) параметры на целый порядок меньше.
Пользователю для построения тренда выводится набор тэгов. Ниже touch-ориентированный интерфейс для оператора, в котором он может выбрать параметры. На каждом клиентском узле есть копия базы данных. Разработчик клиентского приложения работает с локальной памятью и не думает о синхронизации данных по сети, просто делает Get, Set через API.
Разработка клиентского интерфейса АСУ ТП не сложнее, чем разработка сайта. Раньше мы боролись за real-time на клиенте, использовали C++, Qt. Сейчас мы от этого отказались и сделали все на Angular. Современные процессоры позволяют поддерживать надежность работы таких приложений. Веб уже достаточно надежен, хотя память, конечно, плывет.
Задача обеспечить работу приложения в течение года без перезапуска уже не актуальна. Все это упаковывается в Electron и фактически дает платформенную независимость, то есть возможность запускать интерфейс на планшетах и панелях.
Тревога
Тревога – это единственный динамический объект, который появляется в системе. После того, как система запускается, все дерево объектов фиксируется, удалить оттуда ничего нельзя. То есть модель CRUD не работает, можно только сделать пометку «mark as deleted». Если необходимо удалить тэг, он просто помечается и прячется от всех, но не удаляется, потому что операция delete сложная и может повредить состояние системы, ее целостность.
Тревога – это некий объект, который появляется, когда параметр сигнала от того или иного оборудования выходит за пределы уставок. Уставки – это нижняя и верхняя предупредительные границы значений: аварийные, критические, закритические и т.д. При попадании параметра в то или иное значение шкалы появляется соответствующая тревога.
Первый вопрос, который возникает, когда случается тревога, кому показывать сообщение о ней. Показывать тревогу двум операторам? Но наша система универсальная, операторов может быть больше. На АЭС “чуть-чуть” отличаются базы данных у турбиниста и у реакторщика, потому что оборудование разное. Понятно, конечно, если уровень сигнала вышел за рамки в реакторном отделении, то это увидит ведущий инженер управления реактором, в турбинном – турбиной.
Но представим, что операторов много. Тогда тревогу всем показывать нельзя. Или если ее кто-то берет под квитирование, ее нужно немедленно блокировать для квитирования на всех остальных узлах. Это real-time операция, и когда два оператора возьмутся квитировать одну и ту же тревогу, они тут же начнут управлять оборудованием и алгоритмами. Все это связано с сетевым многопоточным программированием и может привести к серьезным системным конфликтам. Поэтому любой динамический объект нужно показывать, давать возможность им управлять и “гасить” тревогу только одному оператору.
Более того, все тревоги друг от друга зависят. Какое-нибудь оборудование начинает “глючить” – тысяча тревог выскакивает. На самом деле, чтобы их все погасить, нужно найти только одну из них, ее квитировать, и тогда пропадает “дерево” остальных тревог. Это отдельная наука и мы как раз работаем над тем, как такие тревоги представлять. Единого мнения пока нет: либо дерево, либо прятать как вложенное. Сейчас модуль тревоги выглядит так, с вложенными данными.
Привожу примеры видеокадров, которые видит оператор, для общего представления.
У нас на заводе сделан стенд. Примерно так выглядят дашборды на панели, у оператора примерно то же самое.
Конфигурация системы
Мы предоставляем достаточно универсальный режим работы с базой данных.
Редактор, который позволяет создавать объекты, удалять их, задавать параметры, которые передаются в базу данных реального времени и базу метаданных.
Видеокадры – это элементы пользовательских интерфейсов, с которыми больше всего проблем. Каждый производитель SCADA/HMI пытается сделать свой редактор, а потом, когда увольняются разработчики, концов не найдешь – появляются баги, все падает, этим невозможно управлять. Нам это надоело, поэтому мы решили: «Делайте, на чем хотите! Хоть на Illustrator, хоть в Sketch – в любой программе, которая выдаст канонический SVG». Мы даём возможность открыть SVG и прицепить его к тегам БДРВ. Если примитивы в редакторе правильно называть, то больше ничего не нужно и все будет нормально работать сразу.
Создание пользовательского интерфейса в АСУ ТП или платформы выглядит не сложнее, чем создание сайта. Мы даем все необходимые API, чтобы это было так. Ни одна другая система, которая сейчас используется на подобных объектах, так не работает, везде есть свои сложные редакторы и убогие интерфейсы. Представляю, каково операторам, которые смотрят на них каждый день. Конечно, многие думают, что не так важно, как это выглядит, главное – безопасность. Но мы хотим, чтобы и выглядело это красиво, потому что, на наш взгляд, это важно.
Как везде, у нас есть система разграничения доступа. Мы поддерживаем несколько режимов, чтобы было надежно и дешево. Кроме контейнерной и обычной виртуализации мы даем возможность сделать Data Lake. Тогда все помещаются в одну большую оперативную память, а режим multitenancy обеспечивает возможность разделения доступа к элементам дерева (объектам, данным). Поэтому можно держать несколько проектов фактически на достаточно недорогом железе.
Также чем больше железа, тем дороже синхронизация и тем больше вероятность ошибки. Поэтому, если мы сможем на большем количестве узлов просто скопировать эту базу, даже в таком режиме, то совокупная надежность всей системы растет.
Более того, следует отметить один момент: в режиме реального времени и большого количества объектов в памяти мы не можем работать с кэшем процессора. Он превратился в тыкву, потому что когда нужно обеспечивать навигацию и поиск по 10 или 100 млн объектов, то кэша нет – всё руками.
Прогнозирование
Мы делаем прогнозную аналитику с помощью нейросетей, машинного обучения. Расскажу, как это работает и сколько стоит в деньгах.
Справа график изменения мощности реактора при движении органов регулирования системы управления защитой — стержней регулирования. Вообще реактор регулируется концентрацией борной кислоты в воде, но когда производятся маневры мощности, то используются стержни. Каждое движение стержней – это пережоги топлива, а топливо достаточно дорогое: загрузка современного реактора ВВЭР-1200 примерно 10 тонн диоксида урана.
График, который дает обратный ход показывает, как оператор управляет всем вручную, то есть изменяет параметры мощности, видит, что мощность чуть-чуть ниже, чем нужно, чуть прибавляет и т.д… Ориентируясь на обратную связь оператор в итоге доводит мощность до нужного уровня.
Мы же обучили нейронную сеть на предыдущих показаниях. Но просто нейросеть никогда точно не спрогнозирует физический процесс. В реакторе 5 физических процессов: нейтронная кинетика, гидродинамика, химия и радиохимия вследствие различных превращений, и физика прочности. Любой расчет выглядит как моделирование каждого этого технологического процесса.
В основном есть два метода:
По расчетным характеристикам оптимизация на отсутствие обратного хода позволит сэкономить до 60 млн долларов в год, за трехлетнюю топливную кампанию (это значит, каждый год треть топлива меняется). Это хорошая цифра для суммарного KPI сотрудников, которые работают на блоке.
Пульт управления
Обычный блочный пульт управления выглядит так.
Слева – Нововоронежская АЭС, справа – Калининская АЭС и модель.
Но мы пошли дальше. Блочный пульт управления – это очень дорогая история. Есть много разработчиков, которые производят и оборудование, и ПО, которое туда сводится – это десятки и сотни компаний. Мы сделали VR-операторскую, загрузили в нее нашу систему.
Надеваешь очки, и получаешь такую же картину, как и на блоке, только без щита. Раньше был БЩУ (блочный щит управления) — оператор шел, крутил какие-то штуки. Потом ему поставили компьютер, он в него смотрел, но все равно вставал к щиту и крутил. Потом мы сделали возможность управления с монитора — БПУ (блочный пульт управления), а теперь – ВПУ (виртуальный пульт управления), за которым будущее.
Хотя будущее, конечно, за блоком без операторов — за искусственным интеллектом. Оператор превратится в супервизора. Потом будет можно управлять всей станцией целиком из общего пульта управления. А потом операторская сможет находиться за пределами АЭС.
Уже сейчас реализуется такой проект ITER. Сама станция находится в городе Кадараш во Франции, а пульт управления – в Японии в городе Рокасё. Это сделано, чтобы отладить технологии, используется квантовая связь и квантовая криптография. Можно сказать, будущее уже здесь!
Больший уклон в разработку программного и аппаратного обеспечения для интернета вещей мы сделаем на InoThings Conf 4 апреля. В прошлом году были доклады и про IIoT, и про электроэнергию. В этом году планируем сделать программу еще более насыщенной. Пишите заявки, если готовы нам в этом помочь.