Хабрахабр

Высоконагруженная распределенная система управления современной АЭС

Без электричества не будет высоконагруженных интернет-сервисов, которые мы так любим. Как ни странно, системы управления объектами генерации электричества, например атомными электростанциями, тоже бывают распределенные, тоже подвержены высоким нагрузкам, тоже требуют множества технологий. К тому же, доля атомной энергетики в мире будет расти, управление этими объектами и их безопасностью – очень важная тема.

Поэтому давайте разбираться, что там есть, как оно все устроено, где основные архитектурные сложности и где в АЭС можно применить модные технологии ML и VR.


Атомная электростанция это:

  • В среднем 3-4 энергоблока со средней мощностью 1000 МВт на одну АЭС, потому что физические системы должны резервироваться, так же, как и сервисы в интернете.
  • Порядка 150 специальных подсистем, которые обеспечивают функционирование данного объекта. Например, это система внутриреакторного контроля, система управления турбиной, система управления химводоочисткой и т.д. Каждая из этих подсистем интегрируется в огромную систему верхнего блочного уровня (СВБУ) автоматизированной системы управления технологическими процессами (АСУ ТП).
  • 200-300 тысяч тэгов, то есть источников сигналов, которые изменяются в реальном масштабе времени. Нужно понять, что является изменением, что нет, не пропустили ли мы чего-нибудь, а если пропустили, то что с этим делать. За этими параметрами следят два оператора, ведущий инженер управления реактором (ВИУР) и ведущий инженер управления турбиной (ВИУТ).
  • Два здания, в которых сконцентрировано большинство подсистем: реакторное и турбинное отделение. Два человека должны в реальном времени принимать решение в случае, если происходят нестандартные, или стандартные, события. Такая высокая ответственность накладывается всего на двух человек, потому что если их будет больше, то им нужно будет между собой договариваться.

О спикере: Вадим Подольный (electrovenic) представляет Московский завод Физприбор. Это не просто завод — это прежде всего инжиниринговое бюро, в котором разрабатывается как аппаратное, так и программное обеспечение. Название является данью истории предприятия, которое существует с 1942 года. Это не очень модно, но очень надежно – вот что хотели им сказать.

IIoT на АЭС

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

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

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

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

Их сейчас немалое количество, наша – очень жестко привязана к реальному времени. Платформа, которая этим управляет – это платформа IoT, про которые многие слышали.

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

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

Система безопасности

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

Основа систем безопасности – это жесткая логика.

Фактически мы отлаживаем один или несколько алгоритмов управления, которые могут объединяться в функционально-групповой алгоритм, и всю эту историю распаиваем прямо на плату без микропроцессора, то есть получаем жесткую логику. Если когда-нибудь какой-то элемент оборудования нужно будет заменить, у него изменятся уставки или параметры, и потребуется внести изменения в алгоритм его работы – да, придется вынуть плату, на которой распаян алгоритм, и поставить новую. Но зато это безопасно – дорого, но безопасно.

Бывают три из четырёх – это как RAID. Ниже пример троированной системы диверсной защиты, на которой выполняется алгоритм решения одной задачи системы безопасности в варианте исполнения два из трех.

Технологическое разнообразие

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

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

Алгоритм считается правильным на основе двух из трех ответов. Ниже примерный алгоритм выбора решения на основе троированной системы диверсной защиты. Таких шкафов на АЭС целые поля. Мы считаем, что, если один из шкафов выйдет из строя, мы, во-первых, об этом узнаем, во-вторых, два остальных будут нормально работать.

Про железо поговорили, перейдем к тому, что всем интереснее – к софту.

Программное обеспечение. Вершок и Корешок

Так выглядит система мониторинга как раз этих шкафов.

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

Она дает больше всего информации, и если начинает работать нестабильно, фактически случается DDoS, потому что вся информационная система забивается диагностической информацией с этой турбины. Самый характерный пример – турбина. В случае, если QoS плохо отработает, могут возникнуть серьезные проблемы: оператор просто не увидит часть важной информации.

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

Программная платформа – это кроссплатформенная микросервисная архитектура, которая состоит из нескольких слоев:

  • Слой данных –база данных реального времени. Она очень простая — что-то типа Key-value, но value может быть только double. Больше никаких объектов там не хранится, чтобы напрочь убрать возможность переполнения буфера, стека или чего-то еще.
  • Отдельная база данных для хранения метаданных. Используем PostgreSQL и другие технологии, в принципе настраивается любая технология, потому что тут нет жесткого real time.
  • Архивный слой. Это оперативный архив (примерно сутки) для обработки текущей информации и, например, отчетов.
  • Долгосрочный архив.
  • Аварийный архив – чёрный ящик, который будет использован, если произойдет авария и будет поврежден долгосрочный архив. В него записываются ключевые показатели, тревоги, факт квитирования тревог (квитирование означает, что оператор увидел тревогу и и что-то начинает делать).
  • Логический слой, в котором находится язык выполнения сценариев. На нем основано вычислительное ядро, и после вычислительного ядра так же, как модуль, находится генератор отчетов. Ничего необычного: можно напечатать график, сделать запрос, посмотреть, как менялись параметры.
  • Клиентский слой – узел, который позволяет разрабатывать клиентские сервисы на базе кода, содержит API.

Существует несколько вариантов клиентских узлов:

  • Оптимизированный на запись. На нем разрабатываются драйвера устройств, но это не классический драйвер. Это программа, которая собирает информацию с контроллеров низовой автоматики, проводит предварительную обработку, парсит всю информацию и любые протоколы, по которым работает оборудование низовой автоматики, – OPC, HART, UART, Profibus.
  • Оптимизированный на чтение – для построения пользовательских интерфейсов, обработчиков и всего, что идет дальше.

На основании этих узлов мы строим облако. Оно состоит из классических надежных серверов, которые управляются с помощью распространенных операционных систем. Мы используем в основном Linux, бывает QNX.

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

Свою систему мы назвали Вершок, а ядро системы Корешок – понятно, почему.

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

Со временем показания плывут, мы знаем, по какому графику во времени они изменят свои показания, и вместо того, чтобы эти датчики менять, уточняем данные и делаем поправки – это называется тарировка датчиков. Иногда бывает так, что датчики приходится тарировать.

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

Мы подключаем язык сценариев, умеем работать с Lua, с Python (например, библиотекой PyPy), с JavaScript и TypeScript для решения задач с пользовательскими интерфейсами. Кроме того, у нас есть вычислительное ядро. Каждый микросервис может запускаться на процессоре абсолютно любого объема памяти и любой мощности. Эти задачи мы можем одинаково хорошо выполнять как внутри облака, так и на граничных узлах. Но система одинаково работает абсолютно на любом узле. Просто он будет обрабатывать тот объём информации, который возможно на текущих мощностях. Она же подходит для размещения на простых IoT устройствах.

Сейчас в эту платформу попадает информация из нескольких подсистем: уровня физической защиты, системы контроля управлением доступом, информация с видеокамер, данные пожарной безопасности, АСУ ТП, IT-инфраструктуры, события информационной безопасности.

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

Выше примеры оборудования, на котором все это работает, и его параметры:

  • Слева – обычный сервер Supermicro. Выбор пал на Supermicro, потому что с ним сразу доступны все возможности железа, возможно применение отечественного оборудования.
  • Справа – контроллер, который выпускается на нашем заводе. Мы полностью доверяем ему и понимаем, что там происходит. На слайде он полностью загружен вычислительными модулями.

Наш контроллер работает с пассивным охлаждением, и с нашей точки зрения это намного надежнее, поэтому стараемся перевести максимальное количество задач на системы с пассивным охлаждением. Любой вентилятор в какой-то момент выйдет из строя, а срок службы АЭС – это 60 лет с возможностью продления до 80. Понятно, что за это время будут сделаны планово-предупредительные ремонты, оборудование будет заменено. Но если сейчас взять объект, который запускался в 90-х или в 80-х, то даже невозможно найти компьютер, чтобы запустить программное обеспечение, которое там работает. Поэтому все приходится переписывать и менять, в том числе алгоритмику.

Узлы самоопределяются, можно делать Hot Swap, за счет чего можно добавлять и менять оборудование, и нет зависимости от выхода из строя одного или нескольких элементов. Наши сервисы работают в режиме Multi-Master, нет единой точки отказа, все это кроссплатформенное.

До определенной степени оператор не должен замечать, что с системой что-то происходит не так: сгорел процессорный модуль, или пропало питание на сервере и он отключился; канал связи перегрузился, потому что не справляется система. Есть такое понятие, как деградация системы. Сейчас у нас работают топология «двойная звезда» и mesh. Эти и подобные проблемы решается за счет резервирования всех компонентов и сети. Если какой-то узел выходит из строя, то топология системы позволяет продолжить нормальную работу.

Цифры 4 и 8 – это количество реплик, то есть база данных поддерживает актуальное состояние всех узлов в реальном масштабе времени – это multicast и real-time. Это сравнения параметров Supermicro (сверху) и нашего контроллера (внизу), которые мы получаем по апдейтам на базе данных реального времени. В тестовой конфигурации примерно 10 млн тэгов, то есть источников изменения сигналов.

Мы боремся, чтобы не терять мощность системы, с ростом числа узлов. Supermicro показывает в среднем 7 M/c или 5 М/с, при увеличении числа реплик. К сожалению, когда возникает необходимость обработки уставок и других параметров, мы теряем скорость с увеличением количества узлов, но чем больше узлов, тем потери меньше.

На нашем контроллере (на Atom) параметры на целый порядок меньше.

Ниже touch-ориентированный интерфейс для оператора, в котором он может выбрать параметры. Пользователю для построения тренда выводится набор тэгов. Разработчик клиентского приложения работает с локальной памятью и не думает о синхронизации данных по сети, просто делает Get, Set через API. На каждом клиентском узле есть копия базы данных.

Раньше мы боролись за real-time на клиенте, использовали C++, Qt. Разработка клиентского интерфейса АСУ ТП не сложнее, чем разработка сайта. Современные процессоры позволяют поддерживать надежность работы таких приложений. Сейчас мы от этого отказались и сделали все на Angular. Веб уже достаточно надежен, хотя память, конечно, плывет.

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

Тревога

Тревога – это единственный динамический объект, который появляется в системе. После того, как система запускается, все дерево объектов фиксируется, удалить оттуда ничего нельзя. То есть модель CRUD не работает, можно только сделать пометку «mark as deleted». Если необходимо удалить тэг, он просто помечается и прячется от всех, но не удаляется, потому что операция delete сложная и может повредить состояние системы, ее целостность.

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

Показывать тревогу двум операторам? Первый вопрос, который возникает, когда случается тревога, кому показывать сообщение о ней. На АЭС “чуть-чуть” отличаются базы данных у турбиниста и у реакторщика, потому что оборудование разное. Но наша система универсальная, операторов может быть больше. Понятно, конечно, если уровень сигнала вышел за рамки в реакторном отделении, то это увидит ведущий инженер управления реактором, в турбинном – турбиной.

Тогда тревогу всем показывать нельзя. Но представим, что операторов много. Это real-time операция, и когда два оператора возьмутся квитировать одну и ту же тревогу, они тут же начнут управлять оборудованием и алгоритмами. Или если ее кто-то берет под квитирование, ее нужно немедленно блокировать для квитирования на всех остальных узлах. Поэтому любой динамический объект нужно показывать, давать возможность им управлять и “гасить” тревогу только одному оператору. Все это связано с сетевым многопоточным программированием и может привести к серьезным системным конфликтам.

Какое-нибудь оборудование начинает “глючить” – тысяча тревог выскакивает. Более того, все тревоги друг от друга зависят. Это отдельная наука и мы как раз работаем над тем, как такие тревоги представлять. На самом деле, чтобы их все погасить, нужно найти только одну из них, ее квитировать, и тогда пропадает “дерево” остальных тревог. Сейчас модуль тревоги выглядит так, с вложенными данными. Единого мнения пока нет: либо дерево, либо прятать как вложенное.

Привожу примеры видеокадров, которые видит оператор, для общего представления.

  • Слева вверху – реакторное отделение,
  • слева внизу – видеокадр для ветропарка,
  • справа внизу — график,
  • cправа сверху – парогенераторы реакторного отделения.

Желтые ссылки – переходы на другие видеокадры.

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

Конфигурация системы

Мы предоставляем достаточно универсальный режим работы с базой данных.

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

Каждый производитель SCADA/HMI пытается сделать свой редактор, а потом, когда увольняются разработчики, концов не найдешь – появляются баги, все падает, этим невозможно управлять. Видеокадры – это элементы пользовательских интерфейсов, с которыми больше всего проблем. Хоть на Illustrator, хоть в Sketch – в любой программе, которая выдаст канонический SVG». Нам это надоело, поэтому мы решили: «Делайте, на чем хотите! Если примитивы в редакторе правильно называть, то больше ничего не нужно и все будет нормально работать сразу. Мы даём возможность открыть SVG и прицепить его к тегам БДРВ.

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

Мы поддерживаем несколько режимов, чтобы было надежно и дешево. Как везде, у нас есть система разграничения доступа. Тогда все помещаются в одну большую оперативную память, а режим multitenancy обеспечивает возможность разделения доступа к элементам дерева (объектам, данным). Кроме контейнерной и обычной виртуализации мы даем возможность сделать Data Lake. Поэтому можно держать несколько проектов фактически на достаточно недорогом железе.

Поэтому, если мы сможем на большем количестве узлов просто скопировать эту базу, даже в таком режиме, то совокупная надежность всей системы растет. Также чем больше железа, тем дороже синхронизация и тем больше вероятность ошибки.

Он превратился в тыкву, потому что когда нужно обеспечивать навигацию и поиск по 10 или 100 млн объектов, то кэша нет – всё руками. Более того, следует отметить один момент: в режиме реального времени и большого количества объектов в памяти мы не можем работать с кэшем процессора.

Прогнозирование

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

Вообще реактор регулируется концентрацией борной кислоты в воде, но когда производятся маневры мощности, то используются стержни. Справа график изменения мощности реактора при движении органов регулирования системы управления защитой — стержней регулирования. Каждое движение стержней – это пережоги топлива, а топливо достаточно дорогое: загрузка современного реактора ВВЭР-1200 примерно 10 тонн диоксида урана.

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

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

В основном есть два метода:

  • Монте-Карло для нейтронов и радиохимии (на CPU);
  • Computational Fluid Dynamics (CFD) для всего остального (на GPU).

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

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

Пульт управления

Обычный блочный пульт управления выглядит так.

Слева – Нововоронежская АЭС, справа – Калининская АЭС и модель.

Блочный пульт управления – это очень дорогая история. Но мы пошли дальше. Мы сделали VR-операторскую, загрузили в нее нашу систему. Есть много разработчиков, которые производят и оборудование, и ПО, которое туда сводится – это десятки и сотни компаний.

Раньше был БЩУ (блочный щит управления) — оператор шел, крутил какие-то штуки. Надеваешь очки, и получаешь такую же картину, как и на блоке, только без щита. Потом мы сделали возможность управления с монитора — БПУ (блочный пульт управления), а теперь – ВПУ (виртуальный пульт управления), за которым будущее. Потом ему поставили компьютер, он в него смотрел, но все равно вставал к щиту и крутил.

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

Сама станция находится в городе Кадараш во Франции, а пульт управления – в Японии в городе Рокасё. Уже сейчас реализуется такой проект ITER. Можно сказать, будущее уже здесь! Это сделано, чтобы отладить технологии, используется квантовая связь и квантовая криптография.

В прошлом году были доклады и про IIoT, и про электроэнергию. Больший уклон в разработку программного и аппаратного обеспечения для интернета вещей мы сделаем на InoThings Conf 4 апреля. Пишите заявки, если готовы нам в этом помочь. В этом году планируем сделать программу еще более насыщенной.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть