Дедушка, а что ты делал в Росатоме? Или почему атомная отрасль — это не только про АЭС

Где-то писали, что одну треть жизни мы проводим на работе. Если отмести время на сон, то это очень много. И мы с коллегами задались вопросом: какое наследие мы оставим после себя и чем будем гордиться, будет ли нам что рассказать нашим внукам?

Мы представили себе будущее, где эти самые внуки пришли к нам, чтобы расспросить о работе. Какой-нибудь далёкий 2065 год, где все летают на космолётах и строят зелёные города, а дети стали настолько акселератами, что ML они проходят на утренниках. В детском саду нашим внукам дали задание рассказать о том, чем занимались их дедушки и бабушки. Они пришли к нам, и мы начали свой рассказ о том, как «мы-то в те времена у-у-у-у!».

Вот пять наших историй о том, что мы делали в Росатоме, рассказанные нашим внукам. 

Изучал льды, чтобы судоходство было безопасным и не вредило природе

Савелий Сергеев, эксперт

Наверное, таким я буду, когда стану дедушкой

Я пришёл в «Гринатом» в 2022 году — давно это было, даже не верится! Нам с командой поручили создать систему мониторинга состояния морского ледяного покрова и арктических ураганов в Арктике, а именно в зоне СМП — Северного морского пути. Ну чтобы понимать, какой именно лёд перед нами, куда он движется, есть ли там айсберги или большие торосы. Нужно было прогнозировать, где могут появиться арктические ураганы, а потом засечь их на спутниковых снимках. Спутниковые снимки похожи на наши с тобой фотографии в альбоме, только чёрно-белые и немного странные. С их помощью мы создавали карты ледовой обстановки, чтобы в реальном времени оценивать состояние льдов и строить маршруты для судов. Нужно было разработать программу, чтобы, загрузив в неё такой снимок и нажав на кнопку в программе, ты мог видеть всё ледовое разнообразие в разных цветах, приблизительно как у папы в навигаторе в машине.

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

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

Поэтому чтобы понять, что происходит со льдом, как меняется поверхность или распознать на снимке арктический ураган, мы стали использовать машинное обучение. С помощью алгоритмов классического и глубокого обучения и их комбинаций мы находили искомые объекты — определённый тип льда или опасное ледяное образование (например, айсберг или торос) или мезомасштабные полярные циклоны (МПЦ), а по-простому — арктические ураганы. Результаты стали точнее, обработка быстрее, а типов карт — больше.

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

Помнишь, я показывал тебе, как по небу летит спутник? Так вот, они, как труженики пчёлы, летают день и ночь вокруг Земли и посылают нам снимки нашей прекрасной планеты, чтобы в любую погоду, днём и ночью, можно было отследить перемещение разных типов морских льдов, вычислить их сжатие, а также указать места скопления опасных ледяных образований, которые могут помешать судам двигаться по маршруту.

Ты понимаешь, дешифрование — процесс сложный, особенно когда на картах нужно указать всё до мельчайших деталей. В каждом пикселе таких карт была информация о конкретном классе льда или наличие или отсутствие опасных ледяных образований. Пространственное разрешение — то есть то, насколько чётким будет изображение тематической карты зависело от разрешения исходного снимка и могло достигать несколько десятков метров на пиксель. А начинали мы с разрешения порядка 300 м на пиксель, при этом, точечные объекты типа айсбергов или стамух были различимы уже с размера порядка 40–80 метров. Дополнительно мы могли обнаруживать и суда. Да-а-а, вот были времена...

Новые карты получились настолько детализированными, что позволяли видеть влияние изменений циркуляции атмосферы на то, как перераспределялся морской лёд. Время получения новых карт зависело только от возможностей поставки исходных снимков — то есть от того, насколько много спутников на орбите и каковы их параметры съёмки. Тогда, в 2020-х годах, появление нового снимка того же самого места на море от интересующего нас спутника могло занимать до суток, а иногда и двое. А сейчас на это уходит минуты, верно? Спутники-то стали в тысячу раз круче!

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

Вот, смотри: это пример карты классификации льда по возрасту и номенклатуре:

А вот карта дрейфа льда:

А вот как на ИК-снимке мы находили арктический ураган:

И таких различных тематических карт мы делали более десятка.

Карты легко интегрировались в Единую Платформу Цифровых Сервисов СМП (ЕПЦС СМП), в которой ледовые эксперты из Научно-Оперативной Группы и Штаба Морских операций АТОМФЛОТА анализировали полученные результаты, давали рекомендации капитанам и принимали соответствующие решения.

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

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

Да, чуть не забыл: мы использовали архитектуру из микросервисов. Угадаешь почему? Всё верно, причин несколько: такую архитектуру было проще создать и поддерживать. А ещё так легче проводить тестирование и можно динамически распределить нагрузку. Для разработки системы мы использовали инструменты контейнеризации и оркестрации. Универсальным инструментом, который мы применили для этой задачи, был Kubernetes. Да-да, я такой старый, что помню Kubernetes! Ну ничего, приятно иногда вспомнить старые добрые инструменты.

Были в таком формате, конечно, и минусы. Давай подумаем вместе какие. Ну, например, развертывать архитектуру из микросервисов было сложнее, её нужно было интегрировать с другими программами, а ещё модули микросервисов могли быть написаны на разных языках, что усложняло мониторинг такой системы. Некоторые из этих трудностей нам удалось решить с помощью четкого технологического стека Единой Технологической Платформы как основы для разработки системы. 

Всё, что мы разработали, помогало развитию Северного морского пути — строительству и модернизации портов, расширению зон добычи полезных ископаемых. Но мы, конечно, понимали, что чем больше судов, тем выше нагрузка на экологию региона. Поэтому запустили проект «Экология» внутри ЕПЦС СМП, чтобы собрать в одном месте данные об экологической обстановке в местах, где проходят суда. В эту базу включали сведения о морской окружающей среде и береговой зоне, картосхемы, диаграммы состояния морских экосистем. Эти сведения помогали найти источники возможных загрязнений и спрогнозировать, как изменится экообстановка в регионе. Но это уже другая история.

Разрабатывал цифровых двойников и первый российский МРТ

Михаил Трухин, технический директор. Проект по созданию цифровых двойников, предприятие ДЖЭТ

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

На дворе стоял 2022 год (ох, как же давно это было!), и я как раз начинал свой путь в атомной отрасли. До этого я целых десять лет работал в нефтегазовой отрасли: поддерживал эксплуатацию трубопровода, отвечал за бизнес-системы, участвовал в формировании стратегии всей компании. И вот однажды мне предложили работу в Росатоме: они искали руководителя для развития нового направления. А спустя какое-то время я стал техническим директором. Да-да, твой дедушка был директором!

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

Цифровой двойник — это такой помощник для технического персонала и руководителей ТЭЦ. Он может подсказать, что нужно подкрутить, чтобы станция работала эффективнее, помочь сэкономить топливо и найти неисправности ещё до того, как что-то сломалось. И самое интересное — он позволяет экспериментировать с настройками станции без риска что-нибудь испортить в реальной жизни. Вот было бы здорово сделать двойника для твоего уже сломанного конструктора или для моих суставов, ха-ха-ха!

Работу цифровых двойников можно представить на примере с твоей игрушечной машинкой. У машинки есть разные датчики. Один следит за скоростью, другой — за зарядом батареи, третий — за температурой мотора. Машинка ездит по комнате, а в компьютере есть её точная копия — цифровой двойник. Он взаимодействует с настоящей машинкой: датчики передают ему данные, а двойник анализирует и подсказывает, что делать. Например, если двойник видит, что мотор начинает перегреваться, он даёт команду сбавить скорость. Если бы в компьютере была просто обычная модель машинки, которая бы знала, как машинка должна двигаться, но никак не могла бы получать от неё данные или давать советы, тогда бы это была просто математическая модель. А цифровой двойник — всегда связан с настоящей машинкой в режиме реального времени. Он не просто повторяет, а работает вместе с ней. Помогает экономить заряд, следит за её состоянием и подсказывает, как лучше ехать. А ведь точно так же цифровые двойники могут помогать не только машинкам, но и большим заводам и электростанциям. 

Мне предстояло создать такой цифровой двойник для ТЭЦ. Для этого нужно было оцифровать все технологические процессы станции и создать её точную компьютерную копию. Цифровой двойник ТЭЦ должен был работать с огромной точностью: повторять работу настоящей станции до 98%.

Первый наш проект был пилотным. Мы взяли две ТЭЦ в Екатеринбурге. Это такой город на Урале, мы туда ездили к твоей тётушке, помнишь? Одна ТЭЦ — современная, с кучей датчиков и продвинутой IT-системой. Вторая — старая, построена ещё в 80-х годах двадцатого века, с оборудованием тех времён. Для тебя это как мезозой, понимаю. И мы разработали для каждой цифровой двойник.

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

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

На старой станции такого эффекта сразу получить не удалось. Только после того, как мы поставили современные IoT-датчики и обновили буквально всю IT-инфраструктуру, нам удалось создать цифрового двойника и для этой станции.

Работать в энергетической отрасли на большом объекте не всегда просто: нужно много внутренних согласований и разрешений. Но мне помогало то, что я работал с отличными ребятами — программистами, инженерами, аналитиками, которые верили в наш проект. А ещё то, что мы занимались по-настоящему важным делом, которое помогало экономить ресурсы и заботиться об экологии. 

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

Это была полностью российская разработка — от железа до программного обеспечения. Тогда в мире было всего несколько компаний, которые умели производить такие аппараты. Нам же нужно было создать свою уникальную разработку.

Команда, в которой я работал, взяла на себя часть проекта: создание математической модели МРТ и разработку программного обеспечения для МРТ. Для создания математической модели нужно было рассчитать и смоделировать, как протекают физические процессы в трёх комнатах: операторной (комната, где сидят лаборант и врач), технической (тут расположены серверы и происходит управление всей системой) и пространстве с МРТ-аппаратом. Моделировали их в нашем же ПО REPEAT. Круто, что сегодня REPEAT полностью вытеснил Matlab в мире.

Создание ПО было громоздкой и, по сути, исследовательской задачей. Нам нужно было написать верхнеуровневую систему, которая бы принимала команды от лаборанта или врача, обрабатывала их и уже давала команды на аппаратную часть МРТ. Полученные аппаратной частью данные (сырые данные) мы принимали и должны были на их основе построить изображения — те снимки, с которыми уже работает врач для выдачи заключения. Это сейчас такие снимки отлично реконструируются нейронными сетями, а раньше надо было вручную писать сложные математические алгоритмы.

Первой задачей было создание MVP системы. Нам удалось написать пайплайн МРТ-исследования за три месяца: расписали, как проходит исследование, как должен работать аппарат и что должен делать врач. Для реализации мы использовали несколько эмуляторов — программы, которые симулируют тот или иной процесс в рамках работы аппарата МРТ. А собрав их вместе и правильно распределив данные между ними, мы смогли симулировать работу целого комплекса МРТ. Например, важной составляющей была разработка научного медицинского университета Чили. Мы и сейчас хорошо дружим с ними, верно?

Знаешь, какая часть проекта была одной из самых важных? Это работа с импульсными последовательностями. Это такие сигналы, которые формируют команды для работы аппаратной части МРТ, чтобы получить данные. Это те самые команды от врача или лаборанта. Параметры импульсных последовательностей должны точно соответствовать проводимому исследованию, а время работы каждой импульсной последовательности — максимально быстрым. Для генерации и приёма сигналов нужны радиочастотные катушки — их разрабатывали в университете ИТМО. Нашей задачей было в том числе наладить взаимодействие с этими катушками. Поэтому мы сотрудничали с коллегами из университетов. Кстати, в ИТМО сейчас открыли новое направление нейрокибернетики — очень крутые ребята, надо бы тебя познакомить с деканом.

Далее нужно было построить не просто изображение, а объёмное изображение, чтобы врач мог видеть всё от мозга до мельчайших сосудов. Мы получали данные в виде файла DICOM — был такой древний медицинский стандарт. В нём были не только картинки, но и метаданные: настройки аппарата МРТ, параметры пациента. Нам нужно было формировать DICOM-файлы, а ещё создать просмотровщик для них, чтобы врач мог быстро «прочитать» этот файл и использовать его на других системах. Это сегодня заключение формирует ИИ, ему даже никаких картинок не нужно.

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

Тогда, в 2024 году, мы только начинали проект, разрабатывали софт, а через несколько лет сделали работающий прототип. Затем запустили отечественное МРТ в производство. Теперь больницы могли закупать МРТ российской разработки, которые были более доступными по цене и конкурировали с ведущими производителями. Наша разработка помогала врачам распознать ранние стадии рака, проблемы с сосудами и заболевания мозга. А пациентам — вовремя получить помощь и сохранить жизнь. Вот таким важным делом занимался твой дедушка!

Прокладывал маршруты судов среди айсбергов и торосов

Игорь Лысенков, эксперт

Твой дедушка и не представлял, каким будет мир через сорок лет

В проект я пришёл в 2021 году, а до этого работал в нефтегазе. Тогда я не представлял, что однажды буду работать в атомной отрасли, а тем более в чём-то связанном с судоходством. При слове «Арктика» я представлял себе белых медведей, громадные льдины, холод и ветер — прямо как ты в детском саду. Но оказалось, что это ещё и огромная транспортная артерия, где непредсказуемо движутся ледовые поля, а погода может меняться так быстро, что любой прогноз устаревает через пару часов. 

Мне поручили ответственную задачу — создание единой системы информации о Северном морском пути. Знаешь, это был настоящий вызов для меня: применить знания и математические методы в совершенно новой сфере. У нас с командой была чёткая цель — создать систему, которая сделала бы Северный морской путь безопасным для мореплавания. А ещё таким, чтобы другим судам, не только отечественным, тоже хотелось по нему ходить. Нужно было добиться того, чтобы проводка судов по Северному морскому пути была выгодной и эффективной. Чтобы плавание стало простым, как дорога в офис, — с прогнозами, подсказками и без неожиданных сюрпризов.

Самое сложное в нашем проекте — это ледовая обстановка. Лёд постоянно двигается и образовывает опасные торосы — это такие поля размером с ледяные глыбы. Это затрудняет судоходство по СМП. Расскажу тебе на простом примере, чем же я занимался. На рейде стоит десяток транспортных судов. Они не могут пройти сложные участки без помощи ледоколов. Но часто бывает так, что ледоколов меньше, чем нужно. За один раз ледокол может провести только одно судно или караван из  двух–трёх судов. Ну и мы спросили себя: как организовать работу всех ледоколов и судов, чтобы никто не ждал зря своей очереди и не терял время? Именно для этого я с командой и работал над системой, которая называлась сложным названием — Единая Платформа Цифровых Сервисов.

Для работы над проектом нужно было собрать множество данных из разных источников и использовать разные технологии. Об этих технологиях ты сейчас знаешь больше меня. Я имею в виду ИИ и машинное зрение. Но тогда это всё было в новинку в нашей отрасли.

Мы собирали данные из разных источников:

• спутниковые снимки SAR — это такие фотографии поверхности земли;

• оптические снимки;

• информацию от метеостанций и измерительных бортовых комплексов на судах. 

Затем мы проводили предобработку данных: устраняли шумы и искажения на спутниковых снимках.

Потом мы сегментировали эти данные, то есть распределяли их по группам, чтобы выделить основные элементы и научить систему понимать, что на картинке: лёд, открытая вода или торосы. Для этого применяли фильтры Гаусса и адаптивную бинаризацию, а также алгоритмы кластеризации для сегментации изображения. Ну про это я как-нибудь отдельно тебе расскажу.

После этого мы создавали ледовую модель, или модель интегральной ледовой проходимости. Это такая модель, которая помогала понять, какой именно вид льда у нас на снимке, где ледовые условия будут легче для судов, а где — тяжелее, и рассчитать, проложить оптимальные маршруты с учётом прогнозов изменения ледовой обстановки. Представляешь, существует более десяти видов льда, например тонкий, припайный, торосистый, и у каждого вида свои параметры проходимости. Чтобы понять, что перед нами дрейфующие льды, мы использовали векторные поля, рассчитывали направление и скорость движения льда на основе спутниковых данных и прогнозов ветра. 

Затем мы придумали граф переходов. Граф — это основа маршрутизации. Узлы графа — это точки маршрута, а рёбра — возможные переходы между ними. У льда есть разные параметры: толщина, возраст, а ещё он под действием ветра и температуры может двигаться, расширяться, т. е. изменяться в течение нескольких часов. Это всё влияет на вес ребер графа переходов. Так мы понимали, нужна ли транспортным судам помощь атомного ледокола или, например, судам будет достаточно сбавить скорость. 

Последний этап — оптимизация маршрута. Это когда нужно выбрать самый удобный и безопасный маршрут. Для этого мы использовали разные алгоритмы. Например, алгоритм А со звездочкой — A*. Он помогал быстро найти самый короткий путь по графу с учётом веса ребер и заданных точек начала и окончания маршрута.

Это был наш черновой опорный маршрут. Но ведь маршрут должен быть точным. Чтобы проложить точный и безопасный путь, мы применяли волновые методы — представляли, как суда проходят через ледовые поля с помощью методов численного моделирования. Если участок особенно важный, то предлагали разные варианты: система придумывала несколько маршрутов на случай, если обстановка на воде резко ухудшится. 

Чтобы понять, как это работало, приведу пример. Судно получило задание: довезти груз из порта Сабетта в Обской губе до Мурманска. Судно выходило из порта и двигалось по маршруту. В это время система маршрутизации получала множество данных в режиме реального времени: спутниковые снимки, прогнозы погоды, данные о толщине льда, а также параметры судна. На основе этих данных строился граф маршрутов. Узлы графа — это опорные точки: входы в проливы, развилки и зоны ледовой разведки. Рёбра графа получали веса, которые зависели от толщины льда, прогнозируемого дрейфа, опасности торосов и времени, необходимого на прохождение участка. Например, переход через зону с плотным льдом получал высокий вес равный нулевой скорости движения судна, чтобы путь судна точно не проходил через такой участок.

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

A* анализировал возможные маршруты, выбирая путь с минимальной суммарной стоимостью — то есть самый безопасный. Например, прогноз показывал, что через 12 часов на одном из участков маршрута лёд начнёт дрейфовать, создавая непроходимую зону. A* учитывал этот фактор и не предлагал вариант маршрута через опасное место. В этом случае получаемый с помощью алгоритма А* маршрут формировал рекомендацию выполнить поворот для огибания опасного места. Для того чтобы найденный с помощью алгоритма А* маршрут был более оптимальным, мы придумали использовать волновые методы.

Когда в дело вступили волновые методы, у ЕПЦС СМП начали получаться геометрически точные результаты за приемлемое время. 

Теперь наши маршруты были хоть куда! А работала система так.

Представь себе лёд толщиной 1,5 метра. Судно должно было пройти через зону с таким льдом. Модуль маршрутизации «представлял», как на корпус судна повлияет лёд такой толщины, он учитывал используемую судном мощность, с которой оно вращало свои винты и загрузку судна, определял скорость движения с учётом прогнозов изменения направления, силы сжатия и скорости дрейфа льда. При решении задачи прокладки маршрута сквозь ледяные поля алгоритм маршрутизации учитывали возможность как носом, так и кормой вперёд (такой вид движения во льдах применяется при необходимости «размыть» впереди стоящее препятствие из льда). А если выяснялось, что транспортное судно не сможет преодолеть такой участок, система генерировала альтернативный маршрут или запрашивала ледокол.

В итоге маршрут получался не только безопасным, оптимальным и физически реализуемым, но и динамически обновляемым — то есть менялся во время всего пути с учётом изменения морских и погодных условий, ледовой обстановки. Если условия ухудшались, система мгновенно пересчитывала путь и предупреждала капитана. В результате судно достигало Мурманска с минимальными задержками, избегая как айсбергов, так и ночёвки в ледяном плену.

Проект, над которым я работал, — это уникальная штука, потому что судоходство в таких сложных условиях на тот момент не вели нигде в мире. Лёд, ветер, айсберги — в те времена не поддавались полной предсказуемости. И знаешь, что я понял? Арктика учит скромности, когда человек понимает, насколько сильной бывает природа. Этим и занимался твой дедушка 40 лет назад.

Создавал модели прогнозирования поломок на предприятии с помощью ИИ

Дмитрий Распопов, эксперт отдела искусственного интеллекта. Проектный офис программы СЦТиУД, ЧУ «Цифрум»

Таким я себя вижу лет так через 40

Возьмём двух твоих игрушечных роботов: они совершенно одинаковые, от одного производителя. Но один у тебя уже сломался, а со вторым ты до сих пор играешь. Так бывает и с обычными машинами для взрослых: в салоне рядом стоят два одинаковых авто, но одно сразу по выезду начинает барахлить, а другое по сто тысяч километров намотает — и ничего. Чтобы предотвратить все поломки и трудности, нужно «прислушиваться» к машинам — именно поэтому я в команде «Цифрума» разрабатывал системы предиктивной аналитики с использованием ИИ.

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

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

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

Типичная бизнес-гипотеза обычно выглядела следующим образом: «Мы полагаем, что, внедрив систему раннего обнаружения отклонений в работе оборудования, мы уменьшим количество внеплановых остановок оборудования на 10%». 

Затем из этой бизнес-гипотезы мы формировали DS-гипотезу: «Мы полагаем, что, используя данные системы сбора (ССД) вместе с рекуррентными нейронными сетями, мы повысим точность обнаружения отклонений в работе установки на 5%».

На выходе мы получали типичный шаблон DS-гипотезы: «Мы полагаем, что, используя [метод] на [данные], мы изменим [ds-метрики] на [X%, значение]».

После того как мы составляли список данных для анализа, мы направляли аналитиков для сбора этих данных. Они получали нужные нам сведения, на основе которых мы строили прогнозы. Почти как нынешний точнейший посекундный прогноз погоды, ты верно подмечаешь. Мы выделяли инсайты и из них генерировали новые признаки, которые помогали понять, как оборудование можно будет использовать в дальнейшем. Важно, чтобы модель не «загрязнялась» лишними данными — поэтому информация проходила процесс «очистки» и настройки с учётом специфики работы конкретного оборудования. Даже небольшие отличия в степени шумности работы, вызванные особенностями сборки, могли повлиять на сигналы с датчиков. Поэтому всё нужно было проверить. Сейчас-то, понятное дело, датчики стали почти вечными, а тогда это надо было учитывать.

Как ты уже знаешь из своих утренников по ML, сбор данных — это сложный процесс. А для нас он был сложный ещё и потому, что мы использовали не только сигналы с датчиков, но и информацию из журналов технического обслуживания и ремонта. Они заполнялись работниками вручную, и часто бывало, что в них попадались неточности. Поэтому мы фильтровали данные, отсеивали нереальные значения, выделяли полезные для нас сигналы и удаляли лишние. Дальше мы с командой разрабатывали модели, экспериментировали с архитектурой. Если время и возможности позволяли, то применяли нейронные сети. Они в то время были не то что сейчас, но всё-таки кое-что умели. 

Вот с такими промышленными данными с датчиков мониторинга мы работали:

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

Часто мы строили модель на основе регрессии, то есть прогнозировали то, что произойдёт с оборудованием на основании исторических данных и пробегов оборудования в прошлом. Это помогало примерно оценить остаточный ресурс. Знаю, что сейчас мы в этом достигли чрезвычайной точности.

Предпоследний этап работы — создание программного продукта (например, веб-приложения) на основе модели и запуск пилота. Программу писали на Python — да-да, представь себе, какой древний язык мы использовали, вы его уже изучили в детсаде в начальной группе! Выбрали именно его, потому что нам нужны были готовые библиотеки и фреймворки, которые помогали проводить ускоренную аналитику данных, быстро загружать и просматривать данные и строить первоначальные модели. Библиотеку Pandas мы использовали для работы с массивами данных и линейной алгебры, Scikit-learn — для моделей машинного обучения и для работы с нейросетями. Чтобы упростить этап подготовки моделей, применяли сборные библиотеки, такие как Keras и PyTorch. Сами модели наши Data Scientists писали на JavaScript, а фронтенд — на Python или JS. Ох, вот сейчас вспоминаю всё это, и аж ностальгия взяла: пайтон, джава, джи-эс…

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

Результатом работы нашей команды был налаженный процесс, когда предприятие функционировало с минимальными сроком простоя. Работники тратили меньше времени на проверку всех сигналов и заполнение информации, их основной задачей теперь были контроль аномальных показателей и принятие решений о дальнейшей эксплуатации установок. Это экономило сотруднику кучу времени и сил. А ещё — помогало помирить тех, кто говорит, что срочно нужно обновить оборудование, с теми, кто говорит, что «оно ещё сто лет проработает и нас всех переживёт».

Разворачивал софт в пустыне на фоне египетских пирамид

Денис Пешехонов, главный прикладной архитектор продуктов. Проект IMS4, «Атомстройэкспорт»

40 лет тому вперёд

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

Итак, мы плавно подошли с тобой к моей истории. Когда я был помоложе, то участвовал в одном интересном проекте. Задачи, о которых я тебе рассказал вначале, стояли перед нами и в те далекие времена. Для их решения нашей командой ИТ-специалистов Росатома был разработан специализированный программный комплекс IMS4, который являлся частью более крупной технологии MULTI-D. Одной из ключевых функций IMS4 было управление объёмной древовидной структурой технической электронной документации. Это включало не только контроль версий и доступов, но и организацию допуска к выполнению работ, что критически было важно для соблюдения сроков и стандартов безопасности. Последнее представляло отдельную сложность с учётом того, что на «атомной стройке» уровень строгости и контроля и по сей день остается невероятно высоким.

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

Мы строили АЭС по всему миру: в Венгрии, Бангладеш, Китае, Узбекистане и даже в Египте — на фоне величественных пирамид, высоких пальм и задумчивых верблюдов! И везде IMS4 помогала решать не только задачи цифровизации, но и становилась ключевым инструментом для управления сложностью и спецификой строительства атомных станций. Она обеспечивала прозрачность, контроль и синхронизацию данных, что было особенно важно в условиях, где каждая ошибка могла иметь серьёзные последствия. 

Благодаря развитию IMS4 стало возможным сегодня возводить энергоблоки даже на далеких космических объектах — Луне и Марсе. За полвека эта система превратилась в нечто фантастическое: сейчас управление всеми процессами доверено искусственному интеллекту и квантовым технологиям. Но особенно приятно осознавать, что именно в 2010 году был заложен прочный фундамент для нынешних достижений в атомной энергетике. Сегодня я уверен: без таких передовых решений, как IMS4, наши успехи в строительстве АЭС были бы куда скромнее.

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

Вместо заключения

Мы лишь представили себе, чем можем поделиться с нашими внуками, когда придёт время. На самом деле таких историй внутри Росатома — тысячи, и у каждого есть что рассказать. И мы уверены, что вам тоже будет что вспомнить через 20, 30, 40 лет. А что бы вы рассказали своим внукам в 2065-м? Делитесь в комментах.