Зміст
На нафтопереробці та в нафтохімії стаціонарне обладнання рідко ламається «за розкладом». Корозія, зміни режиму, відхилення параметрів і дефекти живуть своїм життям. Проте інспекції та частина ТОіР часто планують за календарем: дата підійшла — йдемо дивитися. Ризик при цьому «губиться» між інженерією, технологією, інспекцією та аудитом: оцінки роз’їхалися по 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 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 і контур навчання. Попереду — бекенд, калібрування на обсязі й звичка команди жити в черзі ризику.
Головний урок практики: календар фіксує факт огляду; ризик має вирішувати, що оглядати раніше.