Fault injection w testach UAV

Fault injection jest kontrolowanym wprowadzeniem określonej usterki do systemu, aby zmierzyć detekcję, izolację, reakcję i odzyskanie. Nie jest przypadkowym „psuciem symulatora”. Dobry test zna wymaganie, miejsce wstrzyknięcia, czas aktywacji, obserwowalny skutek fizyczny, oczekiwany stan autopilota, limit czasu reakcji oraz warunek zakończenia. Bez tych elementów nagranie awarii może wyglądać przekonująco, ale nie daje powtarzalnego dowodu.

W UAV fault injection służy między innymi do oceny utraty GNSS, zablokowanej próbki IMU, degradacji silnika, spadku napięcia, zaniku RC/telemetrii, błędnej jakości sensora, przeciążenia CPU i resetu komponentu. Większość kampanii powinna zaczynać się w testach jednostkowych i SITL, przechodzić do HIL, a dopiero potem — dla wybranych, bezpiecznie ograniczonych przypadków — do stanowiska fizycznego. Symulacja przyspiesza i poszerza przestrzeń przypadków, ale nie zastępuje walidacji interfejsów elektrycznych, mechaniki i realnego czasu.

Spis treści#

Fault, error, failure i hazard
Od wymagania do eksperymentu
Model usterki
Miejsce wstrzyknięcia
Typy usterek danych
Usterki czasu
Sensory
Aktuatory i napęd
Zasilanie
Łączność
Oprogramowanie i zasoby
Usterki trwałe, przejściowe i intermittent
Common-cause i kombinacje
Czas aktywacji
Orkiestrator scenariusza
Monitor i oracle
Metryki
Pokrycie fault space
Deterministyczny reset
PX4
ArduPilot
SITL, HIL i hardware
Automatyzacja kampanii
Logi i artefakty
Testy negatywne mechanizmu injection
Bezpieczeństwo prób fizycznych
Przykładowe scenariusze
Kryteria gotowości
Typowe błędy

Fault, error, failure i hazard#

W praktyce testowej warto rozdzielić cztery pojęcia:

fault — przyczyna, na przykład przerwanie przewodu, zablokowany rejestr, błąd zegara albo uszkodzona łopata;
error — niepoprawny stan wewnętrzny lub dana, na przykład stała wartość żyroskopu;
failure — utrata wymaganej funkcji widoczna na granicy systemu;
hazard — stan systemu mogący prowadzić do szkody.

Jedna usterka może zostać zamaskowana i nie doprowadzić do failure. Ten sam error może wynikać z wielu faultów. Fault injection zwykle wprowadza abstrakcję przyczyny na określonej warstwie, a nie fizyczne uszkodzenie. Raport musi zatem mówić „wstrzyknięto zatrzymanie publikacji GNSS”, a nie „udowodniono odporność na wszystkie awarie odbiornika GNSS”.

Mechanizm bezpieczeństwa ocenia się względem wymagania, przykładowo:

Gdy podstawowy barometr przestaje publikować przez > 300 ms,
system ma oznaczyć go unhealthy, przełączyć źródło bez skoku wysokości > X
i zarejestrować zdarzenie w czasie Y.

Bez wartości X, Y, warunków początkowych i definicji „przestaje publikować” wynik jest interpretacyjny.

Od wymagania do eksperymentu#

Każdy przypadek powinien zawierać:

identyfikator wymagania i hazardu;
konfigurację statku i software;
stan początkowy oraz fazę lotu;
fault model i warstwę injection;
trigger oraz czas trwania;
oczekiwane obserwacje i stany;
limity czasu, pozycji, attitude, energii i jakości;
warunek pass/fail/invalid;
warunek bezpiecznego przerwania;
artefakty do zapisania.

Najpierw uruchamia się przebieg nominalny z identycznym seedem i misją. Dopiero różnica względem baseline pokazuje skutek faultu. Baseline także może nie spełniać kryterium — wtedy przebieg fault nie jest wiarygodnym testem odporności.

Model usterki#

Fault model opisuje co najmniej:

target + instance + layer + mode + magnitude + start + duration + recovery

Przykład:

target: gps
instance: 1
layer: measurement_publish
mode: delayed
latency_ms: 700
start_when: "mode == AUTO && waypoint_index == 3"
duration_s: 12
recovery: warm_reacquisition

To jest specyfikacja eksperymentu, nie komenda konkretnego autopilota. Adapter tłumaczy ją na PX4, ArduPilot, plugin Gazebo albo emulator magistrali.

Warto rozróżnić parametry scenariusza od parametrów systemu pod testem. Zmiana EKF timeout w celu wymuszenia reakcji modyfikuje konfigurację produktu i może sprawić, że test przestaje odpowiadać wymaganej wersji.

Miejsce wstrzyknięcia#

Ta sama nazwa „GPS off” może oznaczać:

usunięcie prawdy GNSS z modelu świata;
zatrzymanie generatora pomiarów;
zatrzymanie wiadomości uORB/ROS/MAVLink;
brak bajtów na UART;
brak odpowiedzi urządzenia na magistrali;
odcięcie zasilania modułu;
ignorowanie danych przez estimator.

Każde miejsce testuje inne komponenty. Zatrzymanie wiadomości middleware testuje timeout i failsafe, ale omija sterownik UART, wykrywanie urządzenia i brownout peryferium. Odcięcie zasilania na HIL testuje więcej warstw, lecz jest wolniejsze, mniej powtarzalne i wymaga bezpiecznego hardware.

Zasada brzmi: wstrzykuj możliwie blisko przyczyny opisanej w wymaganiu, lecz na poziomie, który stanowisko potrafi zwalidować. Jeśli celem jest „utrata aktualizacji pozycji”, injection na publikacji może wystarczyć. Jeśli celem jest „recovery po resecie modułu”, potrzebny jest model boot/reacquisition albo prawdziwe urządzenie.

NASA w systemie CFIMS rozdziela generowanie bodźców, fault injection i monitorowanie stanu badanego systemu, aby eksperymentalnie charakteryzować skutki niekorzystnych warunków w rozproszonych aplikacjach sterowania lotem.[1] Ten podział dobrze przenosi się na stanowisko UAV.

Typy usterek danych#

Off#

Brak nowych danych. Ostatnia próbka może pozostać w pamięci odbiorcy, ale timestamp się nie zmienia. Testuje timeout i przełączenie źródła.

Stuck#

Wartość jest zamrożona. Trzeba określić, czy timestamp/sequence nadal się zmienia. stuck value + fresh timestamp jest trudniejsze do wykrycia niż zatrzymany pakiet.

Bias/offset#

Do wyniku dodawany jest stały offset, step, ramp albo funkcja temperatury. Bias powinien mieć jednostkę i osie.

Scale i sign#

Wartość jest mnożona, osie zamieniane albo odwracany znak. Przy małej dynamice scale może pozostać latentny.

Wrong but plausible#

Dane pozostają w zakresie, mają poprawny format i quality, lecz są błędne. To istotna klasa dla monitorów reasonableness oraz fuzji.

Garbage#

Losowe lub nieinicjalizowane wartości. Trzeba zdefiniować rozkład, zakres i NaN/Inf; „random” bez granic utrudnia reprodukcję.

Saturation/clipping#

Wartość zatrzymuje się na granicy pełnej skali, często wraz lub bez flagi overrange.

Dropout#

Próbki są tracone według wzorca Bernoulliego, burst, Gilbert-Elliott albo harmonogramu. Ten sam średni packet loss może mieć różny skutek zależnie od długości serii.

Corrupted status#

Dane i status są niespójne: błędna próbka jako healthy, poprawna jako invalid, zawyżona accuracy lub błędny sensor ID.

Usterki czasu#

Systemy estymacji są wrażliwe nie tylko na amplitudę, lecz także czas:

stałe latency;
zmienny jitter;
slow publication;
burst po zatorze kolejki;
duplicated sample;
reordering;
timestamp jump w przód/tył;
clock drift;
timestamp dobry, arrival zły;
arrival dobry, timestamp zły.

Opóźnienie powinno działać przez kolejkę historycznych prawidłowych danych. „Delayed” nie oznacza obliczenia nowej wartości i wpisania starego timestampu; oba warianty testują inne zachowania.

Przyspieszenie SITL może przeciążyć zewnętrzny GCS lub transport i stworzyć nieplanowane timeouty. ArduPilot ostrzega, że duży SIM_SPEEDUP może generować wystarczający ruch, by MAVProxy nie nadążało, wywołując RC/GCS failsafe niezwiązany ze scenariuszem.[2] Takie przebiegi należy oznaczać jako invalid, chyba że przeciążenie transportu jest celem.

Sensory#

Profil dla każdego sensora powinien wynikać z jego fizyki i API. Model sensora opisuje rate, latency, bias, quantization i status; fault injection nadpisuje lub modyfikuje te mechanizmy.

Przykłady:

IMU: stuck jednej osi, clipping, bias ramp, FIFO overrun, zamiana osi, zatrzymanie jednej instancji;
GNSS: no fix, stale position z aktualnym timestampem, wrong plausible drift, zawyżona accuracy, delay, reset i reacquisition;
barometr: bias zależny od throttle, port blocked, slow response, jedna instancja off;
magnetometr: pole skorelowane z prądem, scale, sudden offset, data healthy mimo interferencji;
airspeed: blocked pitot, leak, icing-like slow dynamics na poziomie zjawiska, negative/implausible pressure;
rangefinder: max range, no return, false short return, intermittent quality;
optical flow/VIO: quality drop, stale frame, latency burst, frame transform error.

Fault ma wpływać na ground truth tylko wtedy, gdy opisuje zmianę środowiska lub platformy. Zakłócenie magnetyczne jest zmianą pola przy sensorze; uszkodzony magnetometr jest zmianą pomiaru. Rozróżnienie umożliwia test redundancji — pole zewnętrzne może dotknąć kilku sensorów jednocześnie.

Aktuatory i napęd#

Przykładowe tryby:

motor off;
thrust scale;
torque/current limit;
stuck command;
slow response;
ESC desync z recovery;
servo jam w pozycji;
servo runaway do limitu;
backlash lub wzrost deadband;
reversed actuator;
utrata telemetrii przy sprawnym napędzie;
fałszywe eRPM przy prawidłowym thrust.

Wstrzyknięcie motor off na końcowej sile sprawdza dynamikę płatowca i alokację, ale nie sprawdza monitoringu prądu/RPM. Zatrzymanie modelu silnika z prądem równym zero daje inny ślad niż zablokowany rotor pobierający limit current. Model silnika i śmigła powinien reprezentować warstwę przyczyny.

Fault aktuatora w locie fizycznym może natychmiast doprowadzić do utraty statku. Najpierw testuje się go w SITL i HIL z wyjściami energetycznymi odłączonymi. Stanowisko z wirnikiem wymaga osłony i ograniczenia energii; lot wymaga osobnej oceny ryzyka i nie wynika automatycznie z sukcesu symulacji.

Zasilanie#

„Battery off” może oznaczać fałszywy raport pustej baterii, spadek napięcia, odcięcie railu peryferium, brownout FC albo fizyczne odłączenie energii. Te przypadki mają różne skutki.

Przydatne scenariusze:

sag pod skokiem obciążenia;
cell imbalance;
stopniowy spadek capacity;
wysoka rezystancja złącza;
intermittent rail sensora;
reset companion computer bez resetu FC;
reset FC z kontynuacją zasilania peryferiów;
błędny voltage/current sensor;
BEC current limit;
thermal shutdown ESC.

Reset FC testuje boot, odzyskanie stanu, wyjścia i watchdog. W SITL zwykły restart procesu może wyzerować także świat, baterię i sensory, tworząc nierealny cold start całego systemu. HIL powinien rozdzielać domeny resetu.

Łączność#

Link można degradować parametrami:

packet loss i burst length;
latency i jitter;
ograniczenie bandwidth;
reorder/duplicate;
asymmetric uplink/downlink;
całkowity outage;
reconnect z nowym sequence/session;
stale heartbeat;
uszkodzona ramka/CRC na warstwie poniżej parsera;
poprawna ramka z błędną treścią na warstwie aplikacji.

Loss na poziomie socketu nie testuje CRC ani recovery sterownika radiowego. Corrupt przed CRC może zostać prawidłowo odrzucony, corrupt po weryfikacji testuje walidację aplikacji. Wymaganie musi wskazywać granicę.

RC, telemetry/GCS, companion link, GNSS corrections i inter-vehicle mesh są osobnymi kanałami. Nie należy wyłączać wszystkich przez wspólny „network off”, jeśli celem jest pojedyncza awaria.

Oprogramowanie i zasoby#

Fault injection może obejmować:

przeciążenie CPU;
wydłużenie wybranego tasku;
brak pamięci/alloc failure;
stack watermark przekroczony;
queue full;
priority inversion;
deadlock lub timeout mutex;
błąd odczytu flash/parametru;
uszkodzenie wybranej wartości w RAM;
reset watchdoga;
proces companion crash/restart;
zmiana lub skok czasu systemowego.

Takie testy są bardziej inwazyjne niż modyfikacja sensorów. Hooki powinny być kompilowane tylko w build testowy, kontrolowane i jednoznacznie oznaczone. Nie wolno pozostawiać nieautoryzowanego interfejsu fault injection w produkcyjnym firmware.

Fault na poziomie kodu musi mieć oracle, który nie korzysta z uszkodzonego mechanizmu. Jeśli monitor kampanii działa w tym samym tasku, którego deadlock wstrzyknięto, brak raportu nie odróżnia poprawnego resetu od zawieszenia całego stanowiska.

Usterki trwałe, przejściowe i intermittent#

Permanent pozostaje aktywny do końca/resetu. Transient trwa zadaną długość. Intermittent powraca według wzorca. Każdy typ testuje inny fragment maszyny stanów.

Parametry czasowe:

time-to-first-fault;
duration;
duty cycle;
burst length;
recovery interval;
liczba powtórzeń;
faza względem rate sensora lub pętli kontrolnej.

Przejściowa usterka krótsza od okresu próbkowania może nigdy nie zostać zaobserwowana. Usterka dokładnie zsynchronizowana z pętlą może zawsze trafiać w ten sam moment. Kampania powinna przemiatać fazę lub losować ją z zapisanym seedem.

Recovery nie zawsze oznacza natychmiastowy nominalny stan. GNSS może ponownie uzyskiwać fix, estimator stabilizować innovations, a sterownik urządzenia przechodzić init. Model powinien reprezentować te stany.

Common-cause i kombinacje#

Testy pojedynczego faultu są podstawą, lecz redundancja często przegrywa przez wspólną przyczynę:

dwa sensory na jednym railu;
wspólna magistrala;
zakłócenie środowiskowe dotykające obu GNSS/magnetometrów;
błąd konfiguracji skopiowany do wszystkich instancji;
spadek napięcia całej szyny;
wspólny zegar lub timestamp;
jedna biblioteka drivera;
uszkodzenie ramy wpływające na kilka IMU.

Nie należy zaczynać od pełnego iloczynu kombinacji. Najpierw safety analysis wskazuje kombinacje istotne dla hazardu. Następnie testuje się:

każdy fault osobno;
wspólną przyczynę;
fault latentny + drugi aktywny;
różne kolejności i odstępy;
recovery jednego przy aktywnym drugim.

Kombinacja A→B może dać inny wynik niż B→A z powodu latch, wyboru primary, hysteresis i stanu estymatora.

Czas aktywacji#

Fault można uruchomić:

w czasie bezwzględnym od startu;
po zdarzeniu armed, takeoff, zmianie mode;
na numerze waypointu;
po osiągnięciu prędkości/wysokości;
w określonym stanie estymatora;
po stabilnym baseline przez N sekund;
losowo w oknie z seedem.

Trigger oparty tylko o czas jest prosty, ale kruchy przy zmianie prędkości symulacji lub misji. Trigger semantyczny jest stabilniejszy, lecz musi mieć timeout: jeśli state nie zostanie osiągnięty, test kończy się precondition failed, nie pass.

Aktywację i deaktywację loguje się dwoma zegarami: czasu symulacji oraz czasu wall/monotonic stanowiska. To pomaga wykryć zator transportu.

Orkiestrator scenariusza#

Orkiestrator powinien być oddzielny od systemu pod testem i wykonywać maszynę stanów:

BOOT → CONFIGURE → BASELINE → ARM → MISSION
     → WAIT_TRIGGER → INJECT → OBSERVE → RECOVER → LAND/STOP → COLLECT

Każdy stan ma deadline i warunki wejścia. Orkiestrator potwierdza, że injection zostało przyjęte i zastosowane. Sam ACK komendy nie zawsze oznacza, że używany simulator implementuje dany tryb.

PX4 dokumentuje ważne ograniczenie: polecenie może zostać zaakceptowane przez moduł failure injection, choć konkretny symulator nie stosuje danego trybu; dostępność zależy od targetu i komponentu.[3] Test musi obserwować rzeczywisty skutek, na przykład zatrzymanie topicu, a nie tylko ACK.

Monitor i oracle#

Oracle decyduje pass/fail. Powinien łączyć:

ground truth ze środowiska;
telemetrię i stany wewnętrzne SUT;
zdarzenia/komunikaty operatora;
niezależny heartbeat i watchdog stanowiska;
limity bezpieczeństwa.

Przykładowe predykaty:

detected_within(0.5 s)
entered_mode("LAND") within 1.0 s
abs(roll) < 25 deg during recovery
position_error < 8 m until touchdown
never_commanded_actuator_outside([0,1])
no_reboot unless reboot_is_expected

Brak crash procesu nie jest sukcesem. System może pozostać armed, ignorować fault lub lecieć z błędnym stanem. Oracle powinien ocenić wymagane zachowanie i niedopuszczalne stany.

Monitor nie może ufać wyłącznie sensorowi objętemu faultem. Przy utracie GNSS pozycję do oceny bierze z ground truth symulatora, nie z tego samego GNSS.

Metryki#

Najważniejsze miary:

injection latency — od triggera do faktycznego faultu;
detection latency — od faultu do oznaczenia/detekcji;
isolation latency — do wskazania instance/przyczyny;
reaction latency — do zmiany mode/sterowania;
recovery latency — do stabilnego stanu po ustąpieniu;
fault coverage — odsetek faultów wykrytych/obsłużonych według zdefiniowanego zbioru;
false positive rate w nominalnych przebiegach;
mission impact — czas, odchylenie trasy, energia, utracona funkcja;
safety envelope violation — maksima attitude/rate/position/actuator;
availability — czas dostępności funkcji;
repeatability — rozrzut wyniku dla tego samego seed/config.

Fault coverage bez mianownika jest bezwartościowe. Trzeba podać listę faultów, rozkład parametrów i warunki. 95% z 20 arbitralnych przypadków nie oznacza 95% wszystkich awarii.

Pokrycie fault space#

Przestrzeń obejmuje target × instance × mode × magnitude × start phase × duration × vehicle state × environment × software version. Pełny iloczyn szybko staje się niemożliwy.

Redukcja powinna być jawna:

equivalence classes;
boundary values;
pairwise/combinatorial dla wybranych osi;
hazard-based priority;
sensitivity analysis;
Monte Carlo dla parametrów ciągłych;
targeted regression dla historycznych błędów.

Macierz śledzenia łączy wymaganie → hazard → fault model → test → wynik → artefakt. Osobno raportuje się nieobsługiwane kombinacje i luki środowiska.

Pokrycie kodu może być dodatkiem, ale nie zastępuje functional fault coverage. Uruchomienie gałęzi failsafe nie dowodzi, że reakcja fizyczna statku była bezpieczna.

Deterministyczny reset#

Po każdym teście trzeba przywrócić:

parametry autopilota;
persistent EEPROM;
aktywne faulty;
baterię/SOC;
świat, wiatr i pozycję;
biasy oraz RNG sensorów;
kolejki i zegary;
stan GCS/companion;
logi i identyfikator przebiegu.

ArduPilot przechowuje zmiany parametrów SITL w wirtualnym eeprom.bin; dokumentacja ostrzega, że fault/config może pozostać po restarcie, jeśli nie zostanie cofnięty lub środowisko uruchomione z czystymi ustawieniami.[2] Izolowany katalog instancji i deklaratywny snapshot parametrów są konieczne w CI.

Po faultcie trzeba wykonać test sanity: wszystkie komponenty healthy, brak aktywnego injection, pozycja startowa i oczekiwane parametry. Inaczej jedna kampania zanieczyszcza kolejną.

PX4#

PX4 udostępnia system failure injection kontrolowany parametrem SYS_FAILURE_EN. Polecenie konsoli ma formę:

failure <component> <failure_type> [-i <instance>] [-m <mask>]

Komponenty obejmują między innymi gyro, accel, mag, baro, GPS, optical flow, VIO, distance sensor, airspeed, battery, motor, servo, avoidance, RC i MAVLink. Typy obejmują ok, off, stuck, garbage, wrong, slow, delayed i intermittent, lecz rzeczywiste wsparcie zależy od komponentu, symulatora i builda.[3]

Przykład w SITL:

param set SYS_FAILURE_EN 1
failure gps off
# obserwacja faktycznego zaniku i reakcji
failure gps ok

Injection można zautomatyzować przez MAVSDK, mapujące API na mechanizm MAV_CMD_INJECT_FAILURE. PX4 publikuje aktywną konfigurację w wiadomości uORB FailureInjection, zawierającej jednostki, maski instancji i typy; aktualna dokumentacja ogranicza liczbę jednoczesnych wpisów zgodnie z definicją wiadomości.[4]

Nie wolno traktować listy typów jako gwarancji implementacji. Oficjalna dokumentacja podaje na przykład, że symulowany GPS obsługuje tylko część trybów. Test rozpoczyna się od capability probe i obserwacji apply-site.

ArduPilot#

ArduPilot SITL ma parametry SIM_* sterujące środowiskiem, sensorami i awariami. Przykłady z dokumentacji:

param set SIM_RC_FAIL 1
param set SIM_GPS_DISABLE 1
param set SIM_ACC_RND 3

Pełną listę dla aktualnego vehicle/build sprawdza się poleceniem:

param show SIM_*

Nazwy i semantyka parametrów mogą zmieniać się między wersjami; kampania zapisuje commit/tag i snapshot. Niektóre parametry wymagają restartu lub włączenia urządzenia. Oficjalna dokumentacja wyjaśnia także SIM_SPEEDUP, parametry wiatru, RC loss i GPS disable.[2]

W adapterze kampanii warto opakować parametry w komendy wysokiego poziomu, na przykład gps.off(instance=1), a następnie mapować je na mechanizmy właściwe wersji. Adapter potwierdza efekt przez log/topic.

SITL, HIL i hardware#

Środowisko	Zalety	Typowe luki
unit/component	szybkość, dokładna kontrola	brak fizyki i integracji
SITL	tysiące przebiegów, ground truth	desktop timing, abstrakcyjne I/O
HIL	prawdziwy MCU, scheduler, bus latency	modelowane sensory/fizyka
rig z peryferiami	sterowniki, zasilanie, recovery	koszt, mniejsza skala
tethered/ograniczony test	część realnej mechaniki	ryzyko, ograniczona obwiednia
lot	system end-to-end	najwyższe ryzyko i koszt

Ten sam identyfikator scenariusza powinien mieć adaptery dla kolejnych poziomów. Wyniki koreluje się, zamiast tworzyć niezależne testy o tej samej nazwie.

HIL dla flight controllera jest potrzebny dla resetu, watchdog, przeciążenia i realnego transportu. Symulowane sensor off nie wykryje problemu recovery sterownika po faktycznym brownoucie peryferium.

NASA zaleca rozdzielenie zalet simulation test bed od prób hardware i jawne testowanie interfejsów, timingów, fault tolerance oraz ograniczeń wierności.[5]

Automatyzacja kampanii#

Campaign runner powinien:

wybrać wersję i zbudować firmware;
utworzyć izolowany katalog;
uruchomić symulator i adapter;
potwierdzić health;
wykonać baseline/scenariusz;
wstrzyknąć fault i potwierdzić apply;
monitorować oracle oraz timeout;
bezpiecznie zakończyć;
zebrać logi i metadane;
wygenerować maszynowy JUnit/JSON i raport ludzki;
wyczyścić procesy oraz stan.

Minimalny opis scenariusza:

id: gps1_off_auto_wp3
vehicle: quad_x
seed: 18427
preconditions:
  mode: AUTO
fault:
  target: gps
  instance: 1
  mode: off
  trigger: waypoint_3_reached
  duration_s: 15
expect:
  detected_ms_max: 800
  position_error_m_max: 12
  forbidden_modes: [ACRO]
  end_state: LAND_OR_SAFE_HOLD

Parser musi walidować jednostki i dozwolone pola. Nieznany target albo nieobsługiwany mode powinien dać unsupported, nie cichy pass.

Równoległe instancje potrzebują unikalnych portów, SYSID, katalogów i seedów. Wydajność hosta jest parametrem kampanii; overload może generować dodatkowy fault timing.

Logi i artefakty#

Każdy przebieg zapisuje:

commit/tag firmware, dirty status i hash buildu;
wersję symulatora/modeli;
konfigurację i diff parametrów;
seed oraz środowisko;
definicję faultu;
czas request/ACK/applied/cleared;
DataFlash/ULog i log ground truth;
stdout/stderr oraz events;
wykorzystanie CPU/memory i real-time factor;
wynik każdego predykatu;
powód przerwania;
skrót plików artefaktów.

Oś czasu powinna łączyć zdarzenia:

t0 trigger
t1 injection applied
t2 sensor health changed
t3 estimator rejected source
t4 mode changed
t5 vehicle stabilized
t6 fault cleared
t7 source accepted again

Bez t1 nie wiadomo, czy długi detection latency wynika z systemu czy orkiestratora.

Testy negatywne mechanizmu injection#

Sam injector też wymaga testów:

nieznany target jest odrzucony;
nieobsługiwany mode nie daje pass;
zła instance nie dotyka innych;
ok rzeczywiście usuwa fault;
reset czyści albo zachowuje fault zgodnie ze specyfikacją;
dwa faulty nie nadpisują się przypadkiem;
ACK i applied są rozróżnione;
injector nie modyfikuje baseline, gdy wyłączony;
logi nie zależą od uszkodzonego kanału;
uprawnienia nie pozwalają użyć hooka w produkcji.

Golden test może wstrzyknąć łatwo obserwowalny bias i sprawdzić dokładną wartość przed uruchomieniem właściwej kampanii.

Bezpieczeństwo prób fizycznych#

Fault injection na prawdziwym hardware zaczyna się od wyjść bez energii. Dla FC:

śmigła są zdjęte;
linie motor enable fizycznie zablokowane;
zasilanie ma current limit i awaryjne odłączenie;
actuator outputs są monitorowane niezależnie;
fault injector nie korzysta z tego samego komputera/watchdoga co SUT;
operator ma kryterium natychmiastowego stopu.

Następny etap to load emulators, serwa bez obciążenia, napęd w osłonie/hamowni, tether albo platforma o ograniczonej energii. Każde poszerzenie wymaga osobnej oceny ryzyka. Sukces motor off w SITL nie autoryzuje wyłączania silnika podczas swobodnego lotu.

Usterki zasilania mogą uszkodzić elektronikę lub skorumpować pamięć. Stosuje się programowalne źródło, ograniczenia, separację i kopie konfiguracji. Nie zwiera się railu „dla realizmu”.

Przykładowe scenariusze#

GPS off w AUTO#

Cel: reakcja na brak publikacji. Warstwa: topic/simulator. Trigger: stabilny segment misji. Oracle: health false, ograniczony position error, wymagany mode. Recovery: przywrócenie + reacquisition. Ten test nie obejmuje wrong-but-plausible.

GPS plausible drift#

Cel: consistency monitor. Fault: ramp 0→20 m przez 15 s, status/accuracy bez zmian. Oracle: innovations i odrzucenie/przełączenie w wymaganym czasie; brak gwałtownego skoku sterowania. Ground truth jest niezależny.

IMU stuck jednej osi#

Cel: redundancja. Fault: gyro instance 1, X zamrożone z aktualnym timestampem. Oracle: identyfikacja instancji, przełączenie na IMU2, brak restartu i limit attitude. Osobno testuje się zatrzymanie całego topicu.

Powolna degradacja silnika#

Cel: allocation/monitoring. Fault: torque limit maleje do 70% przez 5 s. Oracle: eRPM/current/thrust signature, bounded attitude, decyzja mode. Nie zastępuje natychmiastowego motor off.

Sag wspólnej szyny#

Cel: common cause. Fault: wzrost internal resistance baterii podczas climb. Oracle: voltage threshold, ograniczenie mocy, brak brownoutu, energy reserve. Oddzielnie wstrzykuje się błędny voltage sensor.

Restart companion#

Cel: utrata funkcji zależnej od companion przy sprawnym FC. Fault: proces off przez 10 s, potem restart. Oracle: heartbeat timeout, zachowanie bezpieczne, reconnect bez zdublowanych komend.

Queue delay IMU#

Cel: odporność na latency. Fault: bufor 20 ms z burst release. Oracle: wykrycie timing fault albo bezpieczna degradacja, brak przetwarzania out-of-order. Ten scenariusz wymaga wysokiego rate logów.

Kryteria gotowości#

Do CI#

scenariusz jest deterministyczny;
baseline stabilny;
oracle bez zależności od GUI;
reset usuwa stan;
timeouty rozróżniają fail/invalid;
artefakty wystarczają do debugowania;
wersje są przypięte.

Z SITL do HIL#

pojedyncze faulty spełniają kryteria;
sensitivity i boundary cases są wykonane;
interfejs HIL ma zmierzone latency/jitter;
actuator energy jest fizycznie zablokowana;
injector i monitor są niezależne od SUT;
mapowanie faultu na HIL jest udokumentowane.

Do próby fizycznej#

pytania niemożliwe do rozstrzygnięcia w HIL są jawne;
ryzyko i containment są zatwierdzone;
stop/emergency działa niezależnie;
obwiednia jest ograniczona;
najpierw wykonano test o mniejszej energii;
telemetria i zapis ground truth są dostępne.

Typowe błędy#

Test bez wymagania i limitu czasu.
Uznanie ACK injection za dowód zastosowania faultu.
„GPS=0” zamiast braku fix/publikacji.
Stuck value bez określenia timestampu.
Jeden packet-loss percentage bez modelu burstów.
Fault na złej warstwie, omijający testowany driver.
Oracle korzystający z uszkodzonego sensora.
Brak przebiegu nominalnego z tym samym seedem.
Persistent SIM_* lub EEPROM zanieczyszczające kolejne testy.
Brak rozdzielenia fail i invalid/test-infrastructure error.
Tylko pojedyncze faulty mimo wspólnych raili i busów.
Kombinacje bez analizy priorytetów, generujące ogromną kampanię bez pokrycia hazardów.
Współdzielony RNG albo porty między równoległymi instancjami.
Brak testu mechanizmu clear/recovery.
Przejście z sukcesu SITL bezpośrednio do ryzykownego lotu.

Fault injection jest wartościowe, gdy eksperyment odróżnia przyczynę, skutek i obserwację. Powtarzalna kampania nie ma „zepsuć drona”, tylko ilościowo odpowiedzieć: czy system zauważył właściwą usterkę, w jakim czasie, jak ograniczył funkcję, czy zachował bezpieczny stan i czy prawidłowo wrócił po ustąpieniu problemu. Dopiero ślad wymaganie–fault–oracle–artefakt tworzy dowód, który można utrzymać wraz z rozwojem firmware.

Powiązane tematy#

Przypisy#

W. Torres-Pomales, A. M. Yates, M. R. Malekpour, NASA/TM-2010-216834, Fault Injection and Monitoring Capability for a Fault-Tolerant Distributed Computation System.
ArduPilot Project, Using Simulation Parameters to Control the Simulation — SIM_*, RC/GPS failure, wiatr, speedup i trwałość wirtualnego EEPROM.
PX4 Project, System Failure Injection — komponenty, typy failure, instancje, MAVSDK/console i ograniczenia wsparcia symulatorów.
PX4 Project, FailureInjection uORB message — reprezentacja aktywnych faultów, maski instancji i typy.
NASA Software Engineering Handbook, Use of simulation test bed versus flight hardware — ograniczenia timingów, interfejsów, fault tolerance i potrzeba korelacji z hardware.
MAVLink, Common Message Set — MAV_CMD_INJECT_FAILURE oraz identyfikatory failure unit/type używane przez kompatybilne implementacje.
PX4 Project, Simulate Failsafes — scenariusze failsafe w symulacji i zależność od targetu.
ArduPilot Project, Using SITL — środowisko testowe, modele, komponenty opcjonalne i automatyzacja.

Źródła z centralnego rejestru

PX4: System Failure Injection [dokumentacja projektu]
PX4 uORB: FailureInjection message [dokumentacja modelu danych projektu]
PX4 Guide: Simulate Failsafes [dokumentacja projektu open source]
ArduPilot Dev: Using Simulation Parameters to Control the Simulation [dokumentacja projektu open source]
ArduPilot Dev: Using SITL [dokumentacja projektu open source]
NASA/TM-2010-216834: Fault Injection and Monitoring Capability for a Fault-Tolerant Distributed Computation System [raport techniczny NASA]
PX4 Guide: Events Interface [dokumentacja projektu open source]
MAVLink Common Message Set: HIL_SENSOR, HIL_GPS, HIL_STATE_QUATERNION and HIL_ACTUATOR_CONTROLS [specyfikacja protokołu]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]