Настанова ADMP-02 з надійності в експлуатації

Що це таке

ADMP-02, Guidance for Dependability In-Service, - це союзна публікація NATO з управління надійністю. Вона охоплює період після того, як одиницю оборонної техніки введено в експлуатацію: як організація стежить за її безвідмовністю, ремонтопридатністю, готовністю, контролепридатністю, обслуговуванням і безпечністю (разом це її "dependability") і що робить, коли ці показники починають просідати. Edition C, Version 1 промульговано в червні 2025 року, і воно заміщує Edition B, Version 1.

Вимог до надійності вона не встановлює. Їх задають раніше в житті виробу, і ADMP-02 припускає, що вони вже існують: як їх розробляють, охоплює супутній документ ADMP-01. Що додає ADMP-02, так це дисципліну перевіряти, коли виріб уже в полі, чи та надійність, яку в нього закладали проєктом, є тією надійністю, яку він насправді показує, і вирішувати, що робити з розривом.

Кому вона адресована і як набуває чинності

Документ поширюється на "dependability activities of all items procured for military use within NATO Nations when in-service" і написаний для "all members of projects and in-service organizations, including the various NATO Agencies, who are responsible for dependability" (пункт 1.3). Це проєктні офіси, організації експлуатаційної підтримки та агенції NATO, які їх наглядають, а не проєктний орган і не орган сертифікації.

Чинності вона набуває через рекомендацію, а не через угоду. STANREC 4174 фіксує рекомендацію держав NATO застосовувати ADMP-02; окремого кроку ратифікації немає. На практиці постачальник або підрядник з експлуатаційної підтримки виконує її тому, що цього вимагає національна домовленість про підтримку чи контракт, написаний за настановами NATO з надійності, тобто тим самим шляхом, яким до промисловості доходить більшість союзних публікацій.

Цикл моніторингу та збирання даних

Ядром документа є повторюваний цикл: стежити за показниками, збирати дані, аналізувати їх і діяти за результатом. Моніторинг має рано вловлювати "areas of concern or potentially detrimental trends", породжуючи звіти про відхилення, а не потік сирих чисел. Серед цілей, які він перелічує, - кількісно оцінити досягнуту надійність, показати відповідність вимогам, заданим раніше в житті виробу, перевірити припущення профілю життя, на яких ці вимоги ґрунтувалися, і оцінити залишковий корисний ресурс виробу.

Під цим лежить збирання даних, поділене на три типи, кожен зі своїм очікуваним вмістом:

• Дані про використання - напрацювання, стан готовності (у роботі, у черговому режимі чи в непрацездатному стані й чому), події на кшталт відмов і капітальних ремонтів, умови довкілля, зміни конфігурації та унікальна ідентифікація.
• Дані про подію відмови - опис, ідентифікація системи, що відмовила, час настання, умови, що панували на той момент, спосіб виявлення відмови, її наслідки, докорінна причина (разом з випадками "no fault found") і вжита дія з відновлення.
• Дані про дію з обслуговування - яку роботу виконано і чому, скільки часу вона забрала, скільки витрачено праці та запчастин і які проблеми з ресурсами обслуговування трапилися дорогою.

Документ недвозначний щодо переваги якості над обсягом: "Data quality is more important than data quantity", збирання має уникати повторного введення скрізь, де та сама операція може слугувати двом цілям, а сам процес збирання має бути "routinely audited to assess data quality" тією організацією, яка його веде.

Як дані перетворюють на рішення

Щойно дані проаналізовано методами, які документ називає, від простих (аналіз Парето, стратифікація, контрольні карти) до структурованих (аналіз докорінних причин, обслуговування, орієнтоване на безвідмовність, обслуговування за станом, причому сам метод класифікації охоплює ADMP-03), настає визначений набір варіантів: поліпшити програму обслуговування, модифікувати чи модернізувати виріб, продовжити його ресурс капітальним ремонтом, замінити його або, там, де жоден з цих варіантів не придатний, формально жити з проблемою, керуючи її наслідками.

Рішення про заміну зокрема залежать від названих чинників, що обмежують ресурс: зношування (неминучий поступовий процес), перевантаження (коли від виробу вимагають більшого, ніж закладено проєктом), дефекти, виявлені після введення в поле, і моральне старіння, про яке документ обачно зазначає, що воно "is as much of a problem for software as for hardware." Їх зважують за критеріями оптимізації, прийнятності та морального старіння, щоб призначити заміну до того, як показники справді перетнуть неприйнятний поріг, а не після.

Аналіз відмов і FRACAS

Від замкненої системи звітування про відмови, аналізу та коригувальних дій (FRACAS) очікують, що вона працюватиме далі, коли виріб уже в експлуатації, і спиратиметься на наявну інформаційну систему управління обслуговуванням, а не на окремий інструмент. Послідовність розслідування відмови є сталою: підтвердити, що виріб справді відмовив, провести фізичний аналіз відмови, паралельно переглянути технічні дані і використати обидва як вхідні дані для аналізу докорінних причин. Докорінні причини, зазначає документ, зазвичай зводяться до одного з шести джерел: проєкт, компоненти та матеріали, виготовлення, перевантаження, обслуговування або зношування.

На що дивиться оцінювач і що поза сферою застосування

ADMP-02 не створює ані сертифікації, ані акредитації, ані схеми аудиту, і NATO не оцінює відповідність організації їй. Найближче до зовнішньої перевірки вона підходить через контракт на підтримку за показниками, де набувач наглядає за узгодженими критеріями показників на кшталт готовності, безвідмовності, вартості на одиницю використання та часу реагування логістики. Це домовленість про аудит замовником, вписана в конкретний контракт, а не відповідність самій ADMP-02. Усередині організації документ вимагає, щоб процес збирання даних регулярно перевіряли на якість, а після будь-якої відмови з наслідками для безпеки проводили огляд обслуговування, щоб перевірити, чи стратегія обслуговування лишається достатньою.

Дві речі прямо винесено за межі сфери застосування: ADMP-02 не встановлює тих вимог до надійності, за якими веде моніторинг (це робить ADMP-01), і не приписує докладного методу класифікації даних, які просить збирати (це робить ADMP-03). Вона також зазначає один виняток, який варто запам'ятати: на відміну від більшості чинників, які вона розглядає, вікове погіршення "does not apply to software", хоча програмне забезпечення цілком відкрите до морального старіння.

Стандарти, на які він посилається

• ADMP-01Довідково
• ADMP-03Довідково
• ADMP-04Довідково
• AAP-20Довідково
• AAP-48Довідково
• ALP-10Довідково
• ALCCP-01Довідково

Інші стандарти в темі «Управління життєвим циклом і забезпечення якості»

• AACP-02AACP-02 - настанови щодо взаємного проведення аудитів контрактів
• AAP-20AAP-20 рамкова система управління програмами NATO
• AAP-48AAP-48 процеси життєвого циклу системи в NATO
• ACMP-2000ACMP-2000 політика NATO щодо управління конфігурацією
• ACMP-2009ACMP-2009: керівництво з управління конфігурацією
• ACMP-2100ACMP-2100 договірні вимоги до управління конфігурацією