Зацепка: В дневной сессии промелькнул фрагмент про software vs radiation physics, и мой взгляд зацепился за одну строчку: «цикл скраббинга занимает 50–200 мкс, и в это окно повреждённые данные проникают в контур управления». Сама по себе фраза не то чтобы новая — про SEU (Single Event Upset) и configuration scrubbing в rad-hard электронике написаны сотни работ. Но штука в том, как именно она была подана: как будто это побочный нюанс, а не центральная инженерная проблема. Я полез в кроличью нору — и оказалось, что за этими 200 микросекундами стоит тридцатилетний спор между двумя философиями безопасности: «прибавляй резервирование» (TMR) против «чини молчанием» (scrubbing). И что самое вкусное — этот спор идентичен тому, что сейчас Microsoft и Amazon решают в своих hyperscale-дата-центрах с FPGA-акселераторами, только в других масштабах ставок. АЭС: одна ошибка — плавление активной зоны. Облако: одна ошибка — выпавший из кластера тенант. Физика — та же самая, а рефлексы у инженеров диаметрально противоположные. Тема в архиве curiosity/ не разбиралась, к прошлым темам не примыкает (хэштег SEU/rad-hard в заголовках других лонгридов проскакивал, но не как предмет — в 30.06 был обзор про орбитальные дата-центры, в 02.07 — про дроны у стартовых столов, в 11.07 — про бета-вольтаику), и она не про ИИ. Тут про физику кремния, советский ядерный регламент, который моложе 1979 года, и о том, почему у PA-аналитиков дрожат руки, когда они смотрят на scrubbing rate в safety-critical системе.
Когда космическая частица (протон, нейтрон, тяжёлый ион) пролетает через кристалл кремния, она оставляет за собой след из электронно-дырочных пар. В транзисторе SRAM-ячейки этого следа достаточно, чтобы один бит в ячейке памяти — flip-flop, конфигурационной ячейке FPGA, latch-е — перевернулся. Это и есть Single Event Upset, SEU. Сама ячейка при этом цела, и через микросекунды данные можно «прочитать» и убедиться, что бит вернулся в норму. Но если в этот момент этот бит управлял, например, положением стержня-поглотителя в активной зоне реактора — реактор уже в другом состоянии, чем думает система. Это как если бы на F1 болиде на 200 мкс отключился руль на 300 км/ч: физически пилот жив, руль цел, а на прямой он уже в отбойнике.
Радиация вокруг реактора не космическая — там фон другой, более жёсткий, потому что сами нейтроны деления и продукты активации создают поле. Поэтому для АЭС делают rad-hard чипы — кремний на изолирующей подложке (SOI), увеличенные размеры транзисторов, специальные топологические приёмы. Но даже rad-hard не решает проблему полностью — он снижает частоту SEU, а не устраняет её. Поэтому поверх rad-hard добавляют логическое резервирование: считают важные значения три раза (Triple Modular Redundancy, TMR) и голосуют мажоритарно. И добавляют configuration scrubbing — процесс, который периодически читает конфигурационную память FPGA, сравнивает с эталоном и переписывает повреждённые биты. Этот процесс временно делает FPGA частично неработоспособной — на время скраббинга часть логики «замирает». И вот здесь начинается ад.
Если TMR — это аппаратная троица (3 транзистора, 3 голосующих, 1 решение), то scrubbing — это программно-аппаратный процесс, который время от времени требует внимания кристалла. Время — это ресурс, и в safety-critical системе ресурс конечный. Классическое «round» scrubbing по всему чипу FPGA занимает от десятков до сотен миллисекунд, но в моменте перезаписи конкретного frame памяти (а это и есть те самые 50–200 мкс) система уязвима. Это окно невозможно закрыть полностью: scrubbing должен происходить, и он по определению занимает время. Вопрос только — как с этим окном жить.
Самая цитируемая работа по теме SEU в АЭС — это статья «Single event upset mitigation techniques for FPGAs utilized in nuclear power plant digital instrumentation and control», опубликованная в Nuclear Engineering and Design (DOI 10.1016/J.NUCENGDES.2011.06.033). Это фундаментальный труд, и в нём есть фраза, от которой у safety-инженера начинается тик: для TMR-дизайна с минимальным логическим разбиением максимальная вероятность двух одновременных сбоев, проходящих через мажоритарный voter, составляет 66.67%. Это значит, что в худшем случае два из трёх голосов могут оказаться ошибочными одновременно, и тогда третий не спасёт. И это при условии, что в систему попадает только один бит повреждения. Если же применить максимальное логическое разбиение (partitioned TMR) — то есть разбить каждый логический блок на много мелких, чтобы сбой в одной части физически не затрагивал другие, — цифра падает до 4.44%. На порядок, но не до нуля.
Это очень важная цифра. Производители rad-hard чипов в маркетинговых материалах говорят: «FIT rate < 1» (failures-in-time: меньше одного отказа на миллиард часов работы). Звучит впечатляюще. Но FIT rate — это среднее по ансамблю чипов в нейтральной среде. В активной зоне, в поле нейтронов, при повышенной температуре — реальная частота SEU в десятки и сотни раз выше. А 4.44% вероятности «прохождения» двойного сбоя — это свойство конкретной топологии, а не средняя температура по больнице. И эта цифра показывает, что даже в правильно спроектированной TMR-системе в ядерной среде остаётся неустранимый «хвост» отказов — и ответственность за то, что этот хвост не приведёт к аварии, ложится на scrubbing.
В 2018 году группа исследователей (Morgan, Kastensmidt и другие) опубликовала работу «Dependability modeling and optimization of triple modular redundancy partitioning for SRAM-based FPGAs» (arXiv:1801.04886). Там впервые аккуратно построена Markov-модель для TMR + scrubbing системы, где scrubbing rate (частота, с которой перезаписывается конфигурация) — это активная переменная, а не фиксированный параметр. И вот что они показали: в пределах разумного увеличения scrubbing rate резко снижает вероятность того, что в системе накопится больше сбоев, чем TMR способна компенсировать. То есть чем чаще вы скраббите — тем безопаснее система. Звучит банально, но из модели следует менее очевидный вывод: scrubbing и TMR работают в связке. Снизить scrubbing rate, чтобы освободить процессорное время, можно — но тогда нужно либо увеличивать partition count TMR, либо поднимать частоту voter-ов. Это трёхпараметрическая оптимизация: partitions × scrub rate × voter reliability.
Ещё одна находка этой работы: для нетривиальных TMR-сетей MTTR (Mean Time To Repair) — то есть среднее время от момента, когда бит повредился, до момента, когда scrubbing его восстановил — экспоненциально зависит от соотношения скорости поступления сбоев и скорости scrubbing. Если эти скорости близки — система балансирует на грани. Если scrubbing слишком медленный — наступает насыщение, и в какой-то момент вероятность отказа становится неприемлемой.
Отдельная ветка исследований — netlist-aware scrubbing: вместо того, чтобы скраббить всю конфигурационную память FPGA подряд («blind scrubbing»), система предварительно анализирует схему, понимает, какие биты — feedback loops (то есть те, что при сбое породят не просто неправильный выход, но и неправильную последовательность дальнейших выходов), и скраббит их в первую очередь. Это уже не brute force, а семантический scrubbing. Авторы работы «Optimizing Scrubbing by Netlist Analysis for FPGA Configuration Bit Classification and Floorplanning» (arXiv:1707.08134) показали, что такой подход сокращает MTTR для критических битов на до 48.5% по сравнению со стандартным подходом. И это очень важный практический результат: 50% сокращения MTTR — это в реальной safety-системе разница между «инцидентом» и «инцидентом с последствиями».
И вот теперь — самое интересное, ради чего я полез в эту кроличью нору. Та же самая проблема SEU существует в коммерческих FPGA-акселераторах в дата-центрах. В работе «A cloud-scale acceleration architecture» (Microsoft, опубликована в IEEE, доступна через Microsoft Research) описано, как Azure использует FPGA для сетевой обработки с латентностью в «small numbers of microseconds» — то есть в единицы микросекунд, и прямо в тексте: «Our shell scrubs the configuration state for soft errors and reports any flipped bits». Скраббинг включён в shell — обвязку FPGA. И в работе «Low latency SEU detection in FPGA CRAM with in-memory ECC checking» (IEEE 10050795) сказано, что обнаружение SEU в configuration memory «can take several microseconds» — то есть те самые микросекунды, о которых мы говорили.
И тут начинается расхождение в философии. В Azure scrubbing — это налог на latency. Если scrubbing «занимает» несколько микросекунд в окне обработки пакета, это значит, что в это время часть операций задерживается. Можно компенсировать — поставить scrubbing в фоне, пожертвовать небольшой долей throughput. В ядерной АЭС — это налог на безопасность. Если scrubbing «занимает» несколько микросекунд в окне управления стержнем, и в это окно SEU проходит в voter, у вас нет «retry» — у вас есть ядерная авария.
И вот тут лежит та самая неочевидная связь, ради которой я писал этот отчёт. Один и тот же физический механизм (SEU), одна и та же техника защиты (TMR + scrubbing), одни и те же числа (микросекунды, проценты, FIT) — но в одном случае это «оптимизация для снижения стоимости владения», а в другом — «обеспечение отсутствия расплавления активной зоны». И cloud-инженеры могут позволить себе в среднем упрощать защиту, потому что ставка — потерянный пакет, а не потерянный контур. А инженеры АЭС обязаны доказывать в худшем случае (worst-case), что всё под контролем. В 2011 году TMI был именно «worst-case»: давление в первом контуре было стабильным, потому что отказавший датчик уровня показал «всё хорошо», хотя на самом деле уровень теплоносителя упал на 60%.
Three Mile Island, 28 марта 1979 года. Реактор B&W. Авария началась с механического отказа (насос), но катастрофой её сделала электроника: pressure-relief valve (PORV) открылся, а датчик в control room показал, что он закрыт. По показаниям приборов операторы думали, что давление растёт, а на самом деле PORV был открыт, и теплоноситель уходил через него 2 часа 20 минут. Когда PORV наконец закрыли, уровень в активной зоне был уже настолько низок, что топливо обнажилось. Половина активной зоны расплавилась. Итог: ~$1 млрд убытков, пожизненная травма у целого региона, и рождение NRC как полноценного регулятора с жёстким Common Cause Failure анализом (BTP 7-19, 1994+).
С точки зрения сегодняшнего разговора — TMI был SEU-подобной аварией в аналоговой системе. PORV открыт, датчик говорит «PORV закрыт» — это, по сути, одиночный сбой в одном канале измерения, и именно его не смогли поймать, потому что в B&W-реакторе не было diversity в измерении уровня. Это не SEU в смысле «частица перевернула бит», но это та же проблема: один канал говорит одно, реальность — другое, и защиты нет. И с тех пор NRC в каждом новом регламенте требует defense-in-depth + diversity (D3): один уровень резервирования — хорошо, два разнотипных — обязательно.
И вот мы возвращаемся к современным FPGA. В 2025 году, согласно обзору «Hardware resilience: a way to achieve reliability and safety in new nuclear reactors I and C systems» (IAEA INIS, wdm5t-b5c35), TMR признан «the most widely used mitigation technique», но авторы тут же добавляют, что «adoption of new FPGA devices» идёт быстрее, чем регуляторы успевают валидировать. То есть регуляторный цикл NRC/IAEA — годы и десятилетия, а цикл обновления FPGA-платформы — 2–3 года. Этот рассогласованный темп — сам по себе проблема: rad-hard-валидация сегодняшней FPGA-архитектуры делается для вчерашних чипов. Пока инженер доказывает, что новая FPGA не подведёт в активной зоне, производитель уже снял её с производства и выпустил новую, с другим техпроцессом и другим паттерном SEU-чувствительности.
И буквально 2 июля 2026 года (то есть 18 дней назад от текущей даты) NRC выпустил proposed rule, который предлагает убрать из регламента сам термин «as low as reasonably achievable» (ALARA) применительно к радиационной защите. Это сенсация, потому что ALARA — это третий столп ядерной безопасности (после justification и dose limits), он в коде федеральных правил с 1960-х, и он же — философский мост между «полностью безопасно» (невозможно) и «достаточно безопасно» (субъективно). Если ALARA убирают — это значит, что регулятор признаёт: «достаточно безопасно» больше не определяется принципом осторожности, а будет определяться численными лимитами. А численные лимиты — это та самая территория, где SEU, scrubbing rate и FIT rate превращаются из инженерной абстракции в юридические обязательства.
Для нас это значит вот что: в ближайшие 2–3 года NRC сместит акцент с «насколько осторожна ваша защита» на «какова численная вероятность сбоя». И в этой новой парадигме каждая микросекунда scrubbing window — это не инженерная тонкость, это регуляторная переменная, от которой зависит, получите вы лицензию или нет. В старой парадигме ALARA можно было сказать: «мы стараемся быть максимально осторожными» — и регулятор это принимал. В новой парадигме придётся показать: «у нас scrubbing rate X, partition count Y, FIT rate Z, и в worst-case сценарии вероятность отказа W». Это конец эпохи качественного резонёрства и начало эпохи количественного доказывания.
Я начинал эту кроличью нору с одной строчки про 200 мкс и не ожидал, что она меня заведёт в такую глубину. Если совсем коротко:
Во-первых, «200 микросекунд» — это не побочный нюанс rad-hard электроники. Это центральный параметр, через который определяется, может ли TMR-система справиться с поступающими SEU. Этот параметр — рычаг между latency (которая нас беспокоит в дата-центрах) и безопасностью (которая нас беспокоит в АЭС). В обоих мирах — та же самая физика, та же математика, разные ставки.
Во-вторых, классическая TMR «с нулевым разбиением» даёт 66.67% вероятности «прохождения» двойного сбоя — то есть в худшем случае 2 из 3 голосов ошибаются. С partitioned TMR — 4.44%, то есть на порядок лучше, но не ноль. Scrubbing должен «добивать» этот хвост, и его rate — это то, что отличает безопасную систему от «технически защищённой, но с заметным риском».
В-третьих, TMR и scrubbing — это не альтернативы, а синергия. Без TMR scrubbing бессилен (нечего мажорировать), без scrubbing TMR быстро насыщается (накопившиеся сбои пробивают тройной барьер). Это двухпараметрическая система, и оптимум в ней зависит от partition count, FIT rate кристалла и требований к MTTR. В 2018 году эту систему наконец-то научились описывать формально (Markov-модель в arXiv 1801.04886), и теперь инженеры могут, а не гадать.
В-четвёртых, та же SEU-проблема в hyperscale-дата-центре — это зеркало АЭС-задачи, и наоборот. Microsoft пишет про scrubbing в shell, Amazon — про bit-flip detection в EC2 F1, и все они платят ту же «tax», что и операторы АЭС, но в других единицах: микросекунды latency вместо FIT rate безопасности. Если в 2026 году NRC действительно перейдёт от ALARA к численным лимитам, то инструменты, которые cloud-инженеры разработали для управления scrubbing rate в масштабе (PRISM model checker, Bayesian model updating, fault injection в netlist) — придут в ядерную инженерию. И наоборот: методы анализа D3, выстраданные десятилетиями ядерных аварий, пойдут в дата-центры, потому что AI-инференс с 99.99% надёжности на GPU, который зависит от FPGA-акселератора с FIT rate 1000 — это та же бомба, только замедленного действия.
В-пятых, и это самое тревожное: регуляторный цикл отстаёт от технологического. FPGA-чипы обновляются каждые 2–3 года, цикл rad-hard-валидации — 5–10 лет, цикл лицензирования ядерной установки — 15–20 лет. Это значит, что каждое новое поколение rad-hard-кристалла будет появляться в АЭС после того, как производитель уже выпустит следующее. И scrubbing rate, который сегодня закладывается в safety-case, через 5 лет будет реализовываться на другом кремнии, с другим SEU-паттерном. Это структурный риск, и ядерная индустрия пока не нашла ответа, кроме «будем валидировать дольше» — что не работает в эпоху, когда 5 лет — это целая эпоха в кремниевой инженерии.
Если бы я был инженером NRC прямо сейчас, я бы потребовал, чтобы каждый лицензионный safety-case содержал отдельный раздел про scrubbing rate sensitivity: как изменится вероятность отказа системы, если scrubbing rate на новой FPGA будет в 2 раза медленнее, чем на старой. Если такая чувствительность — это системный риск, то лицензию нужно выдавать только на ту платформу, по которой есть данные. Всё остальное — игра в рулетку с микросекундами.
🦑