Содержание
На нефтепереработке и в нефтехимии стационарное оборудование редко ломается «по расписанию». Коррозия, изменения режима, отклонения параметров и дефекты живут своей жизнью. Тем не менее инспекции и часть ТОиР часто планируют по календарю: дата подошла — идём смотреть. Риск при этом «теряется» между инженерией, технологией, инспекцией и аудитом: оценки разъехались по Excel и PDF, операционные сигналы не запускают переоценку, а доказать допущения через полгода почти невозможно.
В пилоте цифровой программы целостности мы строим другой контур: приоритеты по инспекции на основе риска (RBI, Risk-Based Inspection) — через вероятность отказа (PoF, Probability of Failure) и последствия отказа (CoF, Consequence of Failure). Это не готовая инструкция «внедрите RBI за спринт» и не реклама одной кнопки «посчитать матрицу». Модуль в активной разработке; репозиторий закрытый. Ниже — полевые заметки: зачем нужен контур, из каких частей он складывается и какие инженерные решения уже держат практику.
Краткий публичный обзор стека — на странице портфолио RBI. Соседняя заметка из серии практики — про рукописные бланки УЗТ: другой домен, та же дисциплина «система важнее одной модели/экрана».
Ключевые выводы
Календарь без риска даёт ложную полноту. Можно закрыть график и всё равно пропустить актив с высокой полосой риска.
RBI — программа, а не один экран матрицы. Нужны сигнал → переоценка → план неразрушающего контроля → доказательная база.
Уровни L1 / L2 / L3 отвечают на разные вопросы: очередь предприятия, карточка актива, пошаговый анализ.
Операционные модули обязаны триггерить переоценку — окна целостности (IOW), управление изменениями (MOC), расследования, качество данных.
Документация API RP и подготовка к аттестации (ICP) — часть продукта для русскоязычной команды, а не «приложение в PDF».
Инженерия: вынос модуля из монолита, общий пакет документации, сначала контракты интерфейса — потом выравнивание бэкенда.
Модуль ещё в активной разработке: фронтенд с моками, рост покрытия тестами, стабилизация API ещё впереди.
Задача и цена ошибки
Без единой программы целостности типичная картина такая:
- оценки риска разрознены и плохо сравнимы;
- на уровне предприятия не видно очереди действий;
- отклонения окон целостности и изменения на объекте не всегда доходят до пересчёта риска;
- нет следа допущений, пригодного для аудита;
- англоязычные стандарты API тяжело использовать ежедневно;
- подготовка к официальному экзамену ICP оторвана от живой методологии.
Цена ошибки здесь — не «неудобный интерфейс», а промах в приоритетах инспекции и ТОиР: ресурсы уходят на спокойные активы, а спорные живут дольше, чем стоило бы. Поэтому в пилоте мы сразу отказываемся от схемы «сделаем красивую матрицу риска и выгрузим в Excel». Нужен контур, в котором риск обновляется и объясняется.
Почему календарь проигрывает контуру
Календарный план удобен для отчётности: дата, факт, галочка. Он плохо отвечает на вопрос «куда идти сегодня, если ресурсов меньше, чем активов». RBI отвечает через PoF × CoF и матрицу риска по логике API RP 581 — но только если входные данные, механизмы повреждения и последствия согласованы, а не нарисованы «на глаз».
На практике календарь и риск не враги. Календарь остаётся каркасом обязательств. Риск должен переставлять очередь внутри каркаса и запускать внеплановую переоценку, когда меняется процесс, появляется дефект или выходит за окно целостности.
flowchart LR
signal[OpsSignal] --> reassess[RiskReassess]
reassess --> plan[InspectionPlan]
plan --> evidence[AuditEvidence]
evidence --> portfolio[PortfolioQueue]
portfolio --> reassess
Нормативная опора — не список для галочки
В продукте семейство API задаёт роли, а не «декор в футере»:
| Стандарт | Роль в контуре |
|---|---|
| API RP 580 | Элементы программы RBI, жизненный цикл, роли, данные |
| API RP 581 | Методология PoF × CoF, матрица, план инспекций, фактор систем менеджмента |
| API RP 571 | Каталог механизмов повреждения |
| API RP 584 | Окна целостности (IOW) |
| API RP 970 | Коррозионные системы / документ контроля коррозии |
| API 579 | Пригодность к эксплуатации (FFS) |
| API RP 585 | Расследования отказов |
| API 653 | Резервуары и контур обучения ICP |
Важно: наличие стандарта в списке ≠ внедрение. Внедрение начинается там, где стандарт связан с очередью действий и с переоценкой.
Как выглядит контур продукта
Четыре крупных раздела навигации:
- Портфель — риск активов и очередь действий на уровне предприятия.
- Программа целостности — операционные модули + управление RBI.
- Документация — переводы ключевых API RP с поиском и ссылками.
- Обучение — академия и банки вопросов для подготовки к ICP.
Уровни работы с активом
L1 — портфель. Показатели риска и просрочек, матрица PoF/CoF, тепловая карта, фильтры по цеху, типу оборудования, механизму повреждения, полосе риска. Ценность: работать по очереди риска, а не «по алфавиту».
L2 — карточка оборудования. Текущий риск, вклад механизмов, последствия, история анализов, объяснимость («разобрать доверие» к результату).
L3 — пошаговый анализ. Сценарии → критерии → факторы / механизмы повреждения → расчёт PoF и CoF → решение и план инспекции. Результат возвращается в портфель и становится частью программы, а не одноразовым файлом.
На L3 особенно видно, зачем нужен контур, а не «калькулятор в чате». Каждый шаг фиксирует допущения: какой сценарий последствий выбран, какие механизмы повреждения считаем достоверными, какая версия методологии действует на площадке. Если шаги нельзя воспроизвести, матрица риска превращается в мнение с красивой раскраской.
Практически мы разделяем расчёт и решение. Расчёт даёт категории и вклад факторов. Решение — план инспекции и то, что уходит обратно в портфель как обязательство. Смешивать их в одном поле «итог» опасно: потом нельзя отличить «модель так посчитала» от «аналитик так решил».
Двенадцать модулей — зачем они рядом с «калькулятором»
RBI без операционного контура быстро устаревает. В программе целостности две группы.
Операционная целостность: каталог механизмов повреждения, коррозионные системы, окна целостности (IOW), пригодность к эксплуатации (FFS), расследования.
Управление RBI: управление изменениями (MOC), устаревшие анализы, качество данных, сценарии последствий (CoF), методология, аудит, аналитика.
Смысл не в том, чтобы сделать «двенадцать экранов». Смысл в замкнутых триггерах: отклонение IOW, изменение MOC или урок расследования должны попасть в очередь «что пересчитать», иначе портфель риска тихо гниёт.
Отдельно — качество данных. Высокий риск при плохих входах и высокий риск при хороших входах — разные управленческие решения. Модуль качества данных отделяет «надо инспектировать» от «надо сначала дособрать факты».
Рядом стоит аудит: не только посчитать риск, но и собрать пакет допущений и происхождения данных. Без этого программа не переживает внешнюю проверку и внутренний спор «почему этот аппарат красный».
Ещё один недооценённый контур — устаревшие анализы. Даже идеальный L3 стареет: сменился режим, обновили методологию, истёк срок актуальности. Очередь «что пора пересчитать» удерживает портфель живым. Иначе через год вы смотрите на красивую, но историческую картину риска.
Документация и академия как продуктовые контуры
Англоязычный PDF стандарта плохо живёт в ежедневной работе смены и аналитика. В пилоте документация — отдельный контур: перевод ключевых API RP, оглавление, поиск, перекрёстные ссылки, переключение на оригинал. Инженерно это вынесено в общий пакет: один источник правок для встроенного раздела /docs и отдельного читального приложения (веб и установщик под Windows). Правило простое: не копировать файлы документации между приложениями, иначе переводы разъедутся за неделю.
Академия закрывает компетенции: треки обучения и банки практики под ICP (в том числе режимы «без материалов» и «с материалами» для части стандартов). Важно не путать «банк для подготовки» с «официальным экзаменом» и не выносить тексты вопросов в публичные статьи. Публично достаточно сказать: подготовка привязана к той же методологии, что и рабочий контур.
Связка «документ ↔ обучение ↔ рабочий анализ» звучит очевидно, но на площадках часто рвётся: стандарт лежит в одном месте, курс — в другом, а оценка риска делается «как привыкли». В пилоте мы сознательно тянем эти три контура в один продукт, даже если наполнение ещё растёт.
Инженерные решения, которые уже окупились
Вынос из монолита. Модуль живёт отдельным репозиторием со своей сборкой, тестами и релизами. Это дороже на старте и дешевле, когда целостность начинает расти быстрее «родительского» приложения.
Сначала интерфейс и контракты. Поведение экранов стабилизируем раньше выравнивания серверной части: схемы ответа (в т.ч. через zod) меняются вместе с сущностями. Подстановки данных по умолчанию позволяют прогонять сценарии аналитика без ожидания каждой конечной точки API.
Документация как пакет. Поиск и оглавление собираются скриптами сборки; растровые иллюстрации ужимаются для офлайн-раздачи. Это скучная инженерия — и именно она делает стандарт пригодным к работе в поле.
Стек публично можно назвать без деталей заказчика: React, Ant Design, TanStack Query, визуализации (d3 / потоковые схемы), поиск по документации, TypeScript. Это не «модный набор», а следствие задач: плотные таблицы портфеля, объяснимые шаги анализа, длинные документы стандартов.
Что ещё не закрыто
- Выравнивание бэкенда с уже зафиксированными контрактами интерфейса.
- Рост покрытия тестами и стабилизация демо/прод-режимов данных.
- Калибровка методологии и политик объекта на реальных объёмах активов.
- Дальнейшее наполнение академии и дисциплины обновления эталонных банков вопросов.
- Производительность тяжёлых визуализаций портфеля на больших выборках.
Типичные ошибки команд
Купить «матрицу 5×5» и назвать это RBI. Без данных, механизмов повреждения и триггеров переоценки это плакат.
Держать IOW и MOC в отдельных журналах. Если сигнал не доходит до очереди риска, программа мертва.
Считать риск без качества данных. Получите уверенность без оснований.
Переводить стандарты «файлом на шару» без поиска и ссылок. Через месяц никто не найдёт нужный абзац.
Обещать полный бэкенд до стабилизации сценариев аналитика. Сначала контракт шагов L3 и статусов портфеля.
Что сделать сегодня
- Запишите, где у вас сейчас живёт «истина риска» (Excel, PDF, голова эксперта) и сколько стоит ошибка приоритета.
- Разделите вопросы L1 / L2 / L3 — не смешивайте портфель предприятия с пошаговым анализом одного аппарата.
- Выберите один операционный триггер (IOW или MOC) и проведите его до переоценки на бумаге или в прототипе.
- Проверьте, может ли инженер за 30 секунд найти нужный фрагмент API RP 580/581 в вашей текущей базе знаний.
Часто задаваемые вопросы
Это уже промышленная эксплуатация?
Пилот закрывает связный контур на уровне продукта и интерфейса; модуль в активной разработке. Копируйте дисциплину контура, а не ждите «коробочного RBI из статьи».
Чем это отличается от простого расчёта риска в Excel?
Excel не держит очередь предприятия, триггеры переоценки, след аудита и связанную документацию/обучение. Матрица — один артефакт контура, не весь контур.
Нужны ли все двенадцать модулей сразу?
Нет. Начинайте с портфеля, одного L3-сценария и одного операционного триггера. Остальное наращивайте, когда появляется боль.
Где публичное описание проекта?
На странице портфолио RBI. Исходники и данные площадок не публикуются.
Как это связано со статьёй про бланки УЗТ?
Там — распознавание полевых форм и цена ошибки в миллиметрах. Здесь — программа приоритетов инспекции. Обе заметки из серии практики: промышленный контур важнее одиночного инструмента.
Итог
Стоит ли внимания команде с похожими активами? Да — если вы готовы строить контур риска, а не рисовать календарь и матрицу по отдельности. В пилоте уже складываются портфель, пошаговый анализ, модули целостности, документация API RP и контур обучения. Впереди — бэкенд, калибровка на объёме и привычка команды жить в очереди риска.
Главный урок практики: календарь отмечает факт осмотра; риск должен решать, что осматривать раньше.