Пытка тишиной: как начиналась работа над цифровыми моделями энергосистем АЭС
Руки дрожат. Сервер не перезагружается, а время уходит. Начальник не отвечает - вероятно, обедает или вышел покурить. Из коридора доносится шум приближающейся группы людей.
"Ещё двадцать минут, - думаю я. - Если дадут хотя бы двадцать минут, всё заработает".
Но дверь уже открывается.
Перед глазами всплывает другая сцена - мой первый год работы инженером по моделированию систем электроснабжения собственных нужд атомных электростанций. Тогда я ещё не знал, насколько часто в инженерной профессии восторг сменяется раздражением, а тщательно рассчитанная система сталкивается с реальностью, где не хватает времени, денег, документации и иногда даже исправного оборудования.
Начало пути
На дворе стоял 2013 год. Впереди были защита диплома, поступление в аспирантуру и первое полноценное место работы. Искусственный интеллект ещё не был повседневным инструментом, цифровые двойники только набирали форму, а компания занималась созданием операторских тренажёров для АЭС.
Я пришёл инженером по моделированию систем электроснабжения собственных нужд. Название должности звучало солидно, а перечень задач выглядел ещё внушительнее: требовалось описывать работу генераторов, электродвигателей, распределительных устройств, систем управления, релейной защиты и автоматики.
На практике это означало постоянное балансирование между теорией и необходимостью быстро заставить модель работать.
Мой интерес к технике появился ещё в детстве. Позже к нему добавились автоматика, электрооборудование и привычка искать нестандартные решения. На производственной практике третьего курса это качество проявилось особенно ярко.
Нам поручили запустить компрессор мощностью примерно 140 кВт. По документации агрегат имел защиту по протоку охлаждающей воды. Схема выглядела безупречно - правда, только на бумаге. Самому компрессору и его обвязке было около тридцати лет, а контур охлаждения фактически оказался разомкнутым.
Датчик и релейная автоматика были исправны, но охлаждать двигатель было нечем. Тогда мы нашли двухсотлитровую бочку, установили её ниже уровня агрегата за зданием цеха, вручную набрали воды и подключили вибрационный насос "Малыш" обычными шлангами непосредственно к рубашке охлаждения.
Формально автоматика продолжала работать штатно. Руководитель практики отправился к распределительному устройству включать установку. Раздался хлопок, посыпались искры, но компрессор всё-таки запустился и начал нагнетать воздух в ресивер.
Тогда я усвоил важное правило: если система безопасности мешает производству работать, производство почти всегда найдёт способ её обойти. В дальнейшем этот опыт неоднократно помогал при доработке чужого программного кода и восстановлении старых моделей.
Что именно нужно было моделировать
Систему электроснабжения собственных нужд можно разделить на несколько крупных блоков:
- расчёт установившегося режима;
- электрическая схема собственных нужд;
- модели генераторов и электродвигателей;
- системы управления;
- релейная защита и противоаварийная автоматика.
Каждый блок сам по себе требовал серьёзной проработки. Но настоящая сложность появлялась на стыке подсистем: изменение напряжения влияло на двигатели, работа двигателей - на нагрузку, срабатывание защиты - на конфигурацию сети, а переключение схемы - на весь режим станции.
В упрощённом виде электрическую сеть можно представить как систему, где энергия производится, передаётся и потребляется. Её элементы бывают активными - источники ЭДС, генераторы и нагрузки, - и пассивными: сопротивления, проводимости, трансформаторы и линии, по которым протекает ток.
Для расчёта установившегося режима задают топологию сети, параметры ветвей, величины генерации и потребления, а также напряжение базового узла. Затем необходимо определить напряжения во всех узлах и токи в ветвях.
Решать задачу непосредственно по ветвям обычно невыгодно. Гораздо эффективнее перейти к узловым уравнениям: количество узлов, как правило, существенно меньше числа ветвей, поэтому уменьшается и размер вычислительной задачи.
Сначала находят узловые напряжения, а затем вычисляют токи в ветвях по закону Ома. В матричной форме система записывается как
[
Y cdot U = I,
]
где (Y) - матрица проводимостей, (U) - вектор узловых напряжений, а (I) - вектор токов и эквивалентных источников.
На первый взгляд всё выглядит просто. Но за этой компактной записью скрываются вопросы нумерации узлов, выбора опорного узла, обработки нулевых и бесконечных сопротивлений, контроля размерности и корректного задания режимов работы оборудования.
Почему расчётная модель быстро превращается в испытание
Теоретически для построения модели достаточно знать электрическую схему и параметры оборудования. На практике документация часто оказывается неполной, противоречивой или устаревшей.
Один и тот же двигатель мог иметь разные параметры в паспорте, проектной документации и старой версии программы. Названия сигналов не совпадали, единицы измерения отличались, а часть защит была описана только в виде фраз вроде "срабатывает при недопустимом режиме".
Особенно трудно приходилось с программами, написанными много лет назад. Код на Fortran мог корректно работать десятилетиями, однако любое изменение требовало осторожности. Ошибка вроде деления на ноль приводила не к аккуратному сообщению, а к остановке расчёта в самый неподходящий момент.
Поэтому инженер занимался не только физикой процесса. Нужно было разбираться в структуре старой программы, восстанавливать логику неизвестных участков, проверять исходные данные и одновременно следить за тем, чтобы новая функция не сломала уже работающие сценарии.
Как не допустить аварии при доработке модели
Первое правило - разделять физику и программную реализацию. Уравнение должно быть проверено отдельно от кода, а код - протестирован на понятных эталонных примерах.
Полезно начинать с простых схем: одного источника, одной нагрузки и минимального количества ветвей. Если модель не может воспроизвести результат для элементарной сети, бессмысленно запускать её на полноценной схеме энергоблока.
Второе правило - всегда проверять предельные режимы. К ним относятся:
- нулевая нагрузка;
- отключённый источник;
- короткое замыкание;
- разрыв ветви;
- потеря питания;
- скачок напряжения;
- отрицательные или физически невозможные параметры;
- деление на нулевое значение.
Третье - сохранять промежуточные результаты. Если программа завершилась с ошибкой, журнал расчёта должен показывать, на каком шаге, узле или элементе возникла проблема. Молчаливое завершение процесса превращает поиск причины в угадайку.
Уроки, которые остаются после первого года
Работа над моделями научила меня, что инженерная задача редко ограничивается формулой. Важно понимать назначение оборудования, реальные ограничения системы и последствия каждого упрощения.
Нельзя бездумно заменять сложную подсистему идеализированным блоком только потому, что так проще считать. Но и пытаться описать абсолютно всё с максимальной точностью тоже не всегда разумно. Модель должна быть достаточно подробной для поставленной задачи, но не настолько тяжёлой, чтобы её невозможно было сопровождать и проверять.
Большое значение имеет и коммуникация. Ошибка в исходных данных нередко появляется не из-за плохого программирования, а потому, что разные специалисты по-разному понимают одно и то же обозначение. Поэтому полезно фиксировать допущения, версии параметров и правила преобразования единиц.
Наконец, нельзя подменять надёжность героизмом. Временный обходной путь может спасти запуск, как насос и бочка когда-то спасли компрессор. Но в критически важных системах такой подход должен оставаться исключением. После аварийного решения необходимо возвращаться к нормальному проектированию, документировать изменения и устранять первопричину.
И всё же инженерная работа ценна именно этим сочетанием расчёта и реальности. В одной минуте ты разбираешь матрицу узловых проводимостей, а в следующей пытаешься понять, почему старый алгоритм внезапно получил нулевой параметр. Потом слышишь шаги в коридоре, видишь закрывающуюся дверь и понимаешь: твоя модель должна выдержать не только формулы, но и проверку временем, людьми и настоящим оборудованием.
