Дві справні підсистеми, одна несправна система. Де я б шукав ризик до інтеграційних випробувань

💡 Усі статті, обговорення, новини про оборонні технології — в одному місці. Приєднуйтесь до DefTech спільноти!

Мене звати Олександр Бондар. Я засновник Sequtr і зараз працюю з питаннями інженерного ризику та перевірки технічних припущень у складних системах. Цей текст насамперед для тих, хто працює з апаратними системами, інтеграцією та випробуваннями і стикався з ситуацією, коли окремо все працює, а після складання системи починаються сюрпризи.

Останнім часом я кілька разів повертався до однієї інженерної проблеми. Окремі компоненти можуть пройти свої перевірки, відповідати специфікаціям і нормально працювати самі по собі, а після інтеграції система починає поводитися не так, як очікували.

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

Через це я й почав уважніше дивитися на ризики, які виникають на стиках між підсистемами.

Одразу уточню межі того, про що пишу. У мене немає статистики по сотнях defense-проєктів і я не можу сказати, яка частка системних відмов виникає саме на стиках. Є два незалежні спостереження і моя спроба розібратися, чи є за ними більш загальна логіка.

З чого я взагалі про це задумався

В одній розмові з командою, яка працює над складною системою, ми обговорювали майбутню архітектуру і місця, де вони самі бачать найбільше невизначеності. Назву компанії та деталі проєкту я розкривати не можу, але для цієї статті вони й неважливі.

Цікавим було те, що розмова постійно поверталася до взаємодії між підсистемами: як одна частина системи поводитиметься поруч з іншою, що відбудеться при переході між автоматичним і ручним режимом, як робота одного модуля змінює умови для сусіднього.

Причому співрозмовника ніхто спеціально до цього не підводив. Він сам виділив ці місця як складні.

Спочатку я подумав: якщо команда це вже бачить, то де проблема? Вони знають свою систему значно краще за будь-якого зовнішнього консультанта.

Але знати, що «ось тут щось може піти не так», і сформулювати перевірку виявилося двома різними речами. Треба визначити, яке саме припущення перевіряємо, що будемо змінювати, де закінчується нормальна поведінка і який результат реально змусить переглянути рішення.

Через деякий час я натрапив на ще один, уже публічний приклад.

У матеріалі CTO Frontline Robotics Павла Косолапкіна на DOU описана ситуація з інтеграцією камери, яка конфліктувала з іншими компонентами дрона і знижувала їхню ефективність. На початку вони ізолювали сигнал камери буквально консервною банкою, а остаточне вирішення проблеми потребувало ще кількох прототипів.

Ця деталь мені запам’яталась. Не через її екзотичність, якраз навпаки. Просте рішення швидко дозволило перевірити гіпотезу. Цікавіше було те, що небажана взаємодія стала очевидною вже тоді, коли компоненти опинилися разом.

Тоді в мене і виникло питання: скільки таких речей можна побачити раніше, якщо свідомо аналізувати не тільки самі компоненти, а й те, що відбувається між ними?

Інтерфейс не обов’язково намальований стрілкою

Слово «інтерфейс» легко звузити до роз’єму, CAN, UART, API або формату пакета. Але дві підсистеми можуть впливати одна на одну і без прямого інформаційного зв’язку.

Вони можуть мати спільне живлення або землю, стояти в одному корпусі, гріти одна одну, передавати вібрацію через кріплення, створювати електромагнітні завади або конкурувати за часовий чи обчислювальний ресурс. Іноді спільним «інтерфейсом» фактично стає оператор.

Тому на архітектуру я б дивився не лише через задокументовані інтерфейси. Мене цікавило б, що модуль A вважає нормальною властивістю свого середовища і чи не змінює модуль B цю властивість своєю цілком штатною роботою.

Умовно, одна команда розраховує на певну якість живлення. Інший модуль при цьому залишається в межах власної специфікації, але створює режим, якого перша команда не враховувала.

Або програмна частина очікує дані не пізніше певного часу, тоді як для джерела даних більша затримка все ще вважається нормальною.

Жоден компонент формально не відмовив. Просто не збіглися припущення.

А як щодо FMEA

Коли я почав про це думати, першою була досить проста версія: можливо, FMEA через декомпозицію системи природно гірше бачить такі стики.

Але чим більше я це обдумував, тим менше мені подобалось таке пояснення. System FMEA цілком може працювати з відмовами через взаємодію та інтерфейсами. Design Review теж не зобов’язаний обмежуватися окремими компонентами. Було б дивно оголошувати проблему методів там, де проблема може бути просто в тому, як конкретно ними користуються.

Мені зараз цікавішою здається організаційна сторона.

Складну систему все одно доводиться ділити. Є команди, які відповідають за електроніку, програмну частину, механіку, є постачальники окремих компонентів. У кожного своя зона відповідальності та свої вимоги. Інакше розробкою просто неможливо було б керувати.

Але разом з межами відповідальності з’являється питання про власника припущень між цими межами.

Особливо це помітно, коли залучені різні постачальники. Кожен може чудово знати власний компонент і чесно виконувати специфікацію, не знаючи всіх припущень, які зробила сусідня команда.

У зрілому інженерному процесі такі речі, звісно, можна закрити. Моє питання трохи інше: чи завжди ми свідомо робимо сам стик окремим об’єктом перевірки?

Що б я перевіряв

Якби переді мною зараз була архітектурна схема і треба було спробувати знайти такі проблеми до дорогого інтеграційного випробування, я б спочатку подивився на пари підсистем.

Причому не лише на очевидні A ↔ B, між якими вже є потік даних. Я б додав компоненти, які фізично знаходяться поруч, мають спільне живлення, корпус, кріплення або інший ресурс.

Потім поговорив би окремо з людьми, відповідальними за кожну сторону. Для мене тут важливо отримати дві незалежні картини до того, як усі сядуть за один стіл і узгодять спільну відповідь.

Я б запитав у кожного, що він вважає стабільною властивістю середовища для свого модуля. А потім, що його модуль віддає назовні, хоча це і не є його основною функцією.

Це може бути тепло, вібрація, електромагнітні завади, затримка, пульсація живлення, короткі сплески трафіку, механічне навантаження. Конкретний список уже залежатиме від системи.

Після цього відповіді можна покласти поруч і подивитися, чи немає ситуації, де припущення однієї сторони конфліктує зі штатною поведінкою іншої.

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

Між нормальною роботою і відмовою теж є життя

З документацією тут є цікава особливість: їй природно простіше описувати чіткі стани. Зв’язок є або його немає, сенсор справний або несправний, модуль працює або переходить у стан відмови. У реальній системі між цими станами залишається досить велика сіра зона.

Зв’язок формально може залишатися активним, але пакети вже приходять нерегулярно. Сенсор продовжує видавати дані, хоча його показники поступово дрейфують. Температура все ще залишається в допустимому діапазоні, але вже впливає на сусідній модуль. Алгоритм теж не обов’язково відмовить повністю: проблема може проявлятися лише в періодичних переходах у fallback-режим.

Такі режими я б перевіряв окремо. Повну відмову часто простіше помітити і правильно обробити, тоді як часткова деградація неприємна тим, що система все ще виглядає працездатною. Формально все може залишатися в допустимих межах, хоча поведінка вже відрізняється від тієї, на яку ми розраховували.

Те саме стосується часу. Деяких проблем на стиках може взагалі не бути під час першого запуску. Система збирається, проходить тест і дає нормальний результат, а проблема проявляється після термоциклів, транспортної вібрації, повторних з’єднань конектора, накопичення люфту, дрейфу або іншого повторюваного навантаження.

Тобто припущення, яке було правильним на першому тесті, з часом може перестати ним бути. Тому до питання «чи працює?» я б додавав ще одне: яке припущення має залишатися правильним після N повторень і що здатне поступово його порушити?

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

Від підозри до сценарію перевірки

Фраза «тут можуть бути проблеми зі зв’язком» мало допомагає інженеру, який має готувати випробування.

Тому я б спробував розкласти таку підозру хоча б на чотири речі: яке припущення ми робимо, як можемо його порушити, якої реакції очікуємо від системи і який результат вплине на наше рішення.

Наприклад, ми виходимо з того, що затримка каналу не перевищує X. Тоді цікаво подивитися не лише на X, а й на X + 20%, коротке двократне перевищення, серію нерівномірних затримок. Коли контролер повинен перейти у fallback-режим? За яких умов повернутися назад? Що ми взагалі вважаємо правильною реакцією?

І найважливіше для мене питання: за якого результату ми визнаємо, що початкове припущення про архітектуру було неправильним?

Цей критерій краще сформулювати до тесту. Після отримання результатів у нас усіх з’являється спокуса трохи підлаштувати трактування під те, що побачили.

Що перевіряти першим

Тут я поки не бачу сенсу вдавати точність, якої немає.

Без накопичених даних я не знаю ймовірність конкретного сценарію відмови. Поставити навпроти нього умовні 0,37 тільки тому, що так відчувається, не зробить рішення кращим.

Але сценарії можна порівняти за іншим питанням: що зміниться, якщо наше припущення виявиться неправильним?

Одна проблема вимагатиме невеликої локальної зміни. Інша змусить замінити компонент. Ще одна може означати перегляд архітектури або зробити наступне дороге випробування передчасним.

Останній тип я б намагався перевірити раніше, навіть якщо поки не можу чесно оцінити його ймовірність. Просто тому, що отримати цю інформацію до витрат на наступний етап цінніше.

Можливо, це вже окрема тема для розмови про те, як взагалі визначати цінність технічного доказу.

Поки що висновок у мене досить простий

Я не називав би описане вище новим методом. Поки це радше робочий спосіб подивитися на архітектуру трохи під іншим кутом.

Для себе я б перевірив пари підсистем, включно з фізичним сусідством, порівняв припущення різних команд, окремо подивився на часткову деградацію і додав час та повторення як змінні.

Може виявитися, що такий прохід нічого нового не знайде. Це теж нормальний результат.

Але якщо він витягне хоча б одне критичне припущення до того, як його знайде вже зібрана система, кілька годин на таку перевірку були витрачені не дарма.

Мені цікаво порівняти це з практикою інших команд, які працюють зі складними апаратними системами. Як ви працюєте з ризиками на стиках? Виділяєте їх в окремий review, закриваєте через System FMEA чи основна перевірка відбувається вже під час інтеграційних випробувань? І де у вашій практиці частіше виникали неприємні сюрпризи: всередині самого компонента чи у взаємодії між компонентами?

Підписуйтеся на WhatsApp-канал DefTech спільноти!