Monte Carlo w symulacji UAV

Pojedynczy udany lot symulacyjny odpowiada na pytanie „czy ten konkretny zestaw parametrów przeszedł scenariusz”. Kampania Monte Carlo odpowiada na szersze pytanie: jak rozkład masy, środka ciężkości, aerodynamiki, napędu, sensorów, wiatru, opóźnień, warunków początkowych i decyzji logiki przekłada się na rozkład wyniku. Nie zamienia jednak niezwalidowanego modelu w wiarygodną prognozę. Tysiąc precyzyjnie policzonych przebiegów błędnego równania daje precyzyjny opis błędnego równania.

W inżynierii UAV Monte Carlo służy do badania marginesu stateczności, odsetka ukończonych misji, rozrzutu zużycia energii, landing dispersion, reakcji na usterki i kombinacji tolerancji. Kampania musi zachować śledzenie źródła każdego rozkładu, korelacje, seedy, wersje modeli i kryteria pass/fail. Wynik „99,8% sukcesu” bez liczby prób, definicji sukcesu, przedziału ufności i przestrzeni wejść jest tylko liczbą z generatora.

Spis treści#

Co losujemy
Variability, uncertainty i błąd modelu
Rejestr niepewności
Rozkłady wejściowe
Granice i truncation
Korelacje
Parametry zależne i constraints
Seedy i strumienie losowe
Metody próbkowania
Random sampling
Latin hypercube i quasi-random
Scenariusz 6-DoF
Oracle i metryki
Campaign runner
Kontrola jakości przebiegu
Liczba prób
Przedziały ufności
Order statistics
Zero zaobserwowanych failures
Rare events
Importance sampling
Sensitivity analysis
Analiza przebiegów nieudanych
Model discrepancy
Wybór przypadków do HIL i lotu
Regresja w CI
Przykład kampanii
Raport
Typowe błędy

Co losujemy#

Przestrzeń wejść może obejmować:

Płatowiec: masa, położenie środka ciężkości, momenty bezwładności, geometria, sztywność, współczynniki aerodynamiczne, asymetrie i tolerancje montażu.

Napęd: krzywe thrust/torque, stałe czasu, KV/resistance, sprawność, napięcie, rezystancja baterii, rozrzut rotorów, limity ESC i temperatura.

Sensory: bias, noise density, scale, misalignment, latency, jitter, dropout, accuracy GNSS i cross-correlation.

Środowisko: density, temperatura, wiatr średni, gust/turbulence, gradienty, ground effect, powierzchnia i warunki widoczności.

Stan początkowy: pozycja, attitude, prędkość, SOC, temperatura, stan estimatorów i timing startu.

Operacja: trasa, payload, wysokość, punkt decyzji operatora, opóźnienie reakcji, dostępność linku.

Usterki: czas, duration, magnitude, instance i kolejność, zgodnie z fault injection.

Nie wszystko należy losować jednocześnie. Najpierw określa się decyzję i odpowiedź, potem parametry mogące ją zmienić. Dodanie setek arbitralnych wejść utrudnia interpretację i może ukryć brak kluczowego zjawiska.

Variability, uncertainty i błąd modelu#

W praktyce przydatny jest podział:

aleatory variability — rzeczywista zmienność między lotami/egzemplarzami, której nie redukuje dodatkowy pomiar ogólny, na przykład losowy gust;
epistemic uncertainty — brak wiedzy o stałej lub funkcji, możliwy do zmniejszenia pomiarem, na przykład niepewny współczynnik rotor drag;
numerical uncertainty — błąd kroku, solvera i tolerancji;
model-form discrepancy — brak lub uproszczenie zjawiska, którego samo strojenie parametrów nie usuwa.

Te kategorie wpływają na decyzję inaczej. Zmienność lot-do-lotu można propagować jako rozkład. Niepewność parametru może wymagać zewnętrznej pętli lub analizy przedziałowej/scenariuszowej. Błąd modelu musi wejść do marginesu predykcji albo ograniczenia zastosowania.

NASA w praktykach M&S podkreśla verification, validation i uncertainty quantification jako elementy wiarygodności modelu.[1] Kampania powinna wskazywać, które wejścia są zmiennością, a które niewiedzą; nie sprowadzać wszystkich do jednego Gaussian noise.

Rejestr niepewności#

Każde losowane pole ma rekord:

name: mass_kg
meaning: takeoff mass including payload
category: variability
distribution: truncated_normal
parameters: {mean: 3.20, std: 0.08, min: 3.00, max: 3.45}
unit: kg
source: weighing_campaign_2026_07.csv
correlation_group: build_mass_properties
applies_to: vehicle_variant_A
verified_at: 2026-08-10
owner: structures

Rejestr zawiera też transformację do modelu, wersję danych, jakość, warunki i uzasadnienie rozkładu. Jeśli wartość jest eksperckim założeniem, oznacza się ją jako assumption, nie measurement.

Źródło „datasheet” wymaga strony, wersji, warunków i informacji typical/max. Tolerancja produkcyjna nie jest automatycznie rozkładem normalnym; może oznaczać granicę specyfikacji bez informacji o gęstości.

Rejestr powinien mieć maszynową walidację jednostek, zakresów, covariance oraz zależności. Zmiana parametrów wejściowych między kampaniami jest zmianą modelu testowego i podlega review.

Rozkłady wejściowe#

Popularne rozkłady:

normalny — proces wokół średniej bez twardych granic; ryzykowny dla wielkości dodatnich i tails;
lognormalny — dodatnie wielkości o multiplikatywnej zmienności;
uniform — wiedza ograniczona do przedziału bez preferencji; często nadużywany;
triangular — min/mode/max przy skąpych danych eksperckich;
beta po skalowaniu — ograniczony przedział z elastycznym kształtem;
empiryczny/ECDF — sampling z pomiarów;
mixture — kilka populacji lub trybów;
categorical — wariant komponentu, model pogody, konfiguracja payloadu;
time series/process — wiatr, bias, packet loss, a nie pojedyncza stała.

Dobór powinien wynikać z mechanizmu i danych. Normalny rozkład czasu opóźnienia może generować ujemne latency. Uniform wokół nominalu może sztucznie zwiększać gęstość na krawędziach w porównaniu z rzeczywistą produkcją.

Rozkład empiryczny zachowuje zmierzone kształty, ale ma ograniczony zakres i zależność od małej próby. Bootstrap odwzorowuje niepewność danych, lecz nie tworzy obserwacji poza zebranym zakresem.

Granice i truncation#

Clipping i truncation nie są tym samym.

Clipping: losujemy z rozkładu, a wartości poza granicą ustawiamy dokładnie na granicy. Powstaje sztuczna masa prawdopodobieństwa na min/max.

Truncated distribution: losujemy warunkowo tylko z dopuszczalnego przedziału i renormalizujemy gęstość.

Rejection due to constraint: odrzucamy cały niespójny wektor i losujemy ponownie.

Granice fizyczne, specyfikacyjne i obserwacyjne trzeba rozróżnić. Masa nie może być ujemna (fizyka), może mieć limit konfiguracji (specyfikacja), a kampania ważenia objęła tylko pewien zakres (dane). Truncation na zakresie obserwowanym może fałszywie wyciąć możliwe ogony.

Każdy sampler powinien raportować rejection rate. Wysoki odsetek odrzuceń sygnalizuje zły dobór rozkładów niezależnych lub zbyt skomplikowaną geometrię constraints.

Korelacje#

Losowanie wszystkich parametrów niezależnie tworzy fizycznie niemożliwe egzemplarze. Przykłady korelacji:

masa payloadu i położenie CG;
masa oraz momenty bezwładności;
temperatura, density i wydajność baterii;
resistance i KV silnika w partii;
bias osi jednego IMU;
błędy GNSS dwóch odbiorników w tym samym środowisku;
wiatr w kolejnych chwilach i wysokościach;
thrust oraz torque tego samego śmigła.

Dla wektora normalnego można użyć macierzy covariance i rozkładu Choleskiego. Dla rozkładów nienormalnych przydają się transformacje lub copula, ale korelacja Pearsona po transformacji nie musi pozostać taka sama.

Macierz musi być dodatnio półokreślona. Automatyczne „naprawienie” jej do nearest PSD zmienia założenia i powinno być raportowane. Korelacje szacowane z małej próby mają własną niepewność.

W niektórych przypadkach lepiej generować parametry ze wspólnej przyczyny. Zamiast korelować voltage i capacity arbitralnie, losuje się temperaturę/stan ogniw i przepuszcza przez model baterii.

Parametry zależne i constraints#

Parametry pochodne liczy się z pierwotnych:

I = I_geometry(mass_distribution)
T_required = mass · g · margin
rho = atmosphere(altitude, temperature, pressure)

Nie losuje się niezależnie masy i hover thrust requirement, jeśli drugie jest deterministyczną funkcją pierwszego. Niezależne losowanie prowadzi do podwójnego liczenia niepewności albo niespójności.

Constraints mogą obejmować:

CG wewnątrz obwiedni;
dodatnio określoną macierz bezwładności;
sumę mas komponentów równą masie całkowitej;
voltage/current w obwiedni hardware;
zgodność śmigła i ramy;
wind profile ciągły w czasie/przestrzeni;
payload variant zgodny z konfiguracją.

Zamiast odrzucać dużo próbek, można parameterize model tak, aby constraints były spełnione konstrukcyjnie.

Seedy i strumienie losowe#

Każdy przebieg ma run_seed, ale jeden globalny RNG jest niewystarczający. Dodanie nowego losowania kamery przesunie całą sekwencję i zmieni wiatr, IMU oraz fault time. Lepsze są deterministycznie wyprowadzone strumienie:

seed_mass   = hash(campaign_seed, run_id, "mass")
seed_wind   = hash(campaign_seed, run_id, "wind")
seed_imu0   = hash(campaign_seed, run_id, "imu0")
seed_faults = hash(campaign_seed, run_id, "faults")

Algorytm RNG, biblioteka i sposób transformacji rozkładów także są częścią wersji. Ten sam integer seed w dwóch bibliotekach nie gwarantuje tych samych próbek.

Zapisuje się zarówno seed, jak i finalny wektor wejść. Replay może wtedy użyć dokładnych wartości nawet po zmianie generatora. Dla procesów czasowych przechowuje się parametry i seed, a w krytycznych przypadkach pełny trace.

Common random numbers pomagają porównać dwa warianty kontrolera: oba otrzymują te same próbki masy, wiatru i sensorów. Różnica wyników ma mniejszą wariancję. Należy jednak zachować zgodne mapowanie strumieni.

Metody próbkowania#

Metoda zależy od celu:

estymacja prawdopodobieństwa → losowanie zgodnie z rozkładem docelowym;
pokrycie przestrzeni → Latin hypercube, quasi-random lub design of experiments;
worst/boundary search → optimization/adversarial search;
sensitivity → dedykowany design Sobol/Morris;
rare event → importance/subset/splitting;
requirement percentile → sampling + order statistics lub model statystyczny.

Nie każda „seria losowych przebiegów” jest Monte Carlo w sensie estymacji prawdopodobieństwa. Space-filling design może świetnie znajdować nieliniowości, ale jego proste proporcje pass/fail nie muszą być estymatorem prawdopodobieństwa operacyjnego.

Random sampling#

Prosty independent Monte Carlo losuje wektory zgodnie z joint distribution. Ma zalety:

łatwa interpretacja statystyczna;
niezależne przebiegi;
proste równoleglenie;
convergence rate niewrażliwy formalnie na wymiar w takim sensie jak siatki;
prosty sequential extension — można dodać dalsze próby.

Wadą jest wolna zbieżność dla percentyli ogonowych i rzadkich failures. Błąd standardowy estymaty średniej maleje około 1/√N, więc dziesięciokrotne zmniejszenie błędu wymaga około stukrotnie więcej prób.

Sampling bez replacement z małego katalogu komponentów jest innym modelem niż niezależne losowanie wariantu w każdym runie. Trzeba określić, czy kampania reprezentuje flotę, serię produkcyjną czy kolejne loty jednego egzemplarza.

Latin hypercube i quasi-random#

Latin hypercube sampling dzieli każdy marginal na N przedziałów o równym prawdopodobieństwie i używa każdego raz. Poprawia pokrycie marginesów w małej próbie. Zachowanie zależy jednak od korelacji i permutacji; nie zapewnia dobrego pokrycia wszystkich projekcji wysokiego rzędu.

Sekwencje quasi-random (np. Sobol) mogą równomierniej pokrywać hipersześcian. Nie są zwykłym losowaniem i wymagają ostrożności przy przedziałach ufności; stosuje się randomization/scrambling albo inne metody błędu.

LHS jest dobry do eksploracji i surrogate training. Dla formalnej estymacji prawdopodobieństwa trzeba uwzględnić design w estymatorze. Nie wolno opisać „200 punktów LHS, 2 fail” jako dokładnie 1% ryzyka bez analizy.

Scenariusz 6-DoF#

Kampania UAV powinna mieć stabilny scenariusz nominalny i jawne fazy:

initialize → estimator settle → arm → takeoff → climb → mission
→ perturbation/fault window → return/land → post-flight checks

Warunki startowe muszą obejmować stany filtrów i modeli dynamicznych. Losowanie attitude przed pełnym settle może mieszać niepewność inicjalizacji z dynamiką lotu.

Każdy run ma timeout symulacyjny i wall-clock. Warunek zakończenia nie może zależeć tylko od lądowania, bo zawieszony state machine zatrzyma całą kampanię.

Scenariusz powinien działać poprawnie przy nominalnych medianach i w punktach deterministycznych min/max przed uruchomieniem tysięcy prób. Najpierw wykonuje się verification pojedynczej trajektorii, potem losowanie.

Oracle i metryki#

Metryki ciągłe:

maksymalny attitude/rate error;
minimum voltage i SOC reserve;
track/cross-track error;
landing position/velocity;
czas misji i energia;
innovation ratios;
actuator saturation duration;
detection/recovery latency;
temperatura i margines napędu.

Metryki dyskretne:

mission completed;
geofence violation;
estimator reset;
unexpected mode;
collision/contact;
watchdog reboot;
lost control;
timeout/infrastructure invalid.

Pass/fail powinien wynikać z predykatów, nie z ręcznego oglądania. Jednocześnie zachowuje się wartości ciągłe — binary result traci informację o marginesie.

Run invalid (crash symulatora, overload hosta, brak injection) nie jest pass ani failure systemu. Odsetek invalid jest osobną metryką wiarygodności kampanii.

Campaign runner#

Runner przygotowuje immutable manifest wejścia:

{
  "campaign": "vtol-transition-v7",
  "run_id": 1842,
  "seed": 91248831,
  "firmware_commit": "...",
  "model_commit": "...",
  "inputs": {"mass_kg": 3.31, "cg_x_m": 0.014, "wind_mps": 9.2},
  "scenario": "transition_headwind",
  "limits": {"pitch_deg": 45, "min_voltage_v": 18.0}
}

Następnie:

tworzy izolowany katalog/porty/SYSID;
ładuje dokładny wektor parametrów;
wykonuje preflight assertions;
uruchamia scenariusz;
zbiera logi i ground truth;
ocenia oracle;
zapisuje status pass/fail/invalid;
oblicza hash artefaktów;
czyści procesy i persistent state.

Wynik jest append-only. Ponowienie runu dostaje attempt, nie nadpisuje pierwotnego failure. Dzięki temu nie znika instability infrastruktury.

Kontrola jakości przebiegu#

Przed analizą statystyczną sprawdza się:

czy próbki wejściowe mają oczekiwane marginals;
czy correlations są zgodne w granicach błędu;
czy constraints i jednostki są spełnione;
czy wszystkie wersje są identyczne;
czy real-time factor i CPU nie tworzą timeoutów;
czy losowane wartości faktycznie trafiły do modelu;
czy seed/replay daje identyczny wynik deterministycznego modelu;
czy invalid nie korelują z określonym regionem przestrzeni.

Jeśli skrajne parametry zwiększają czas obliczeń i te runy częściej timeoutują, usunięcie invalid wprowadza selection bias. Trzeba naprawić infrastrukturę lub modelować censoring, nie ignorować prób.

Histogram każdego wejścia i scatter najważniejszych par powinny być częścią raportu. Sam kod samplera nie dowodzi poprawności danych.

Liczba prób#

N=1000 nie jest uniwersalnym standardem. Liczba zależy od:

mierzonej statystyki;
oczekiwanego prawdopodobieństwa;
wymaganej precyzji/confidence;
liczby podgrup i porównań;
metody sampling;
rare-event strategy;
zmienności odpowiedzi.

Dla średniej można użyć estymaty wariancji i planowanej szerokości przedziału. Dla proporcji potrzebny jest binomial interval. Dla percentyla i requirement compliance przydają się order statistics. NASA opisuje ich zastosowanie do określenia liczby prób dla wymagań probabilistycznych, wraz z rozróżnieniem rodzajów niepewności.[2]

Plan liczebności tworzy się przed kampanią, a sequential stopping ma zdefiniowaną regułę. Zatrzymanie „gdy wynik wygląda dobrze” wprowadza bias.

Przedziały ufności#

Jeśli k z N niezależnych przebiegów zakończyło się failure, estymata punktowa to:

p_hat = k / N

Przy małym k, szczególnie 0 lub N, symetryczne przybliżenie normalne jest słabe. Stosuje się dokładny Clopper-Pearson, Wilson albo uzasadnioną metodę bayesowską z jawnym priorem.

Raport:

k/N failures, estimate, 95% CI, sampling design, exclusions/invalid

Jeśli runy nie są niezależne — np. grupy lotów dzielą jeden losowany egzemplarz — prosty binomial interval jest niewłaściwy. Potrzebny jest model hierarchiczny albo sampling na właściwym poziomie.

Przy wielu wymaganiach jednocześnie rośnie ryzyko przypadkowego przekroczenia. Plan powinien rozróżniać eksplorację od formalnego verification i uwzględniać multiple comparisons.

Order statistics#

Order statistics używa uporządkowanych wyników bez konieczności dopasowania parametrycznego rozkładu. Jeśli interesuje nas wysoki percentyl maksymalnego pitch, sortujemy y_(1) ≤ ... ≤ y_(N) i wybieramy odpowiedni rząd wraz z poziomem confidence wynikającym z rozkładu dwumianowego.

Zaletą jest brak założenia normalności outputu. Wadą: bardzo wysokie percentyle wymagają wielu prób, a wynik opisuje tylko distribution of inputs i model w zadanej konfiguracji.

Nie należy po prostu nazwać maksimum z 100 runów „99.9 percentile”. Pozycja maksimum ma określony, szeroki rozkład percentyla. NASA pokazuje, jak order statistics może połączyć percentile requirement z consumer risk/confidence i liczbą prób.[2]

Dla dwustronnych granic potrzebna jest odpowiednia para order statistics. Wybór musi zostać wykonany przed obejrzeniem wyników.

Zero zaobserwowanych failures#

Zero failures nie oznacza p=0. Przy niezależnym Bernoulli i prostych założeniach jednostronna górna granica ma postać:

p_upper = 1 - α^(1/N)

Dla małych p często używa się przybliżenia p_upper ≈ -ln(α)/N. Dla 95% confidence (α=0.05) jest to około 3/N — tzw. rule of three. To przybliżenie, nie dowód bezpieczeństwa.

Jeśli w 1000 próbach nie ma failure, można ograniczyć prawdopodobieństwo w ramach modelu i rozkładu na poziomie rzędu kilku na tysiąc, nie milionowej części. Wymagania bardzo rzadkich zdarzeń wymagają innych metod, analiz i danych.

Rare events#

Dla prawdopodobieństwa 10^-6 brute-force potrzebuje ogromnej liczby prób, by nawet zobaczyć failure. NASA zwraca uwagę, że do dobrego oszacowania zdarzeń o bardzo małej częstości liczba standardowych próbek rośnie odwrotnie do prawdopodobieństwa i szybko staje się niepraktyczna.[3]

Opcje:

importance sampling;
subset simulation;
splitting/RESTART;
cross-entropy;
surrogate-assisted search;
adaptive stress testing;
worst-case optimization;
analytic reliability model;
fault tree/event tree z danymi komponentów.

Te metody wymagają poprawnych wag lub osobnej interpretacji. Zwiększenie wiatru i liczby usterek aż pojawi się crash nie pozwala liczyć crashów jako prawdopodobieństwa operacyjnego.

Rare-event search może służyć do odkrywania failure modes nawet bez estymacji p. Wtedy raportuje się „znaleziono kontrprzykład w regionie X”, nie „prawdopodobieństwo wynosi Y”.

Importance sampling#

Importance sampling losuje z proposal distribution q(x), częściej odwiedzającego interesujący ogon, i waży wynik:

w(x) = p(x) / q(x)

Estymator failure probability:

p_fail ≈ (1/N) Σ w(x_i) · I[failure(x_i)]

Proposal musi mieć support wszędzie tam, gdzie target p(x) i failure mogą być istotne. Złe q daje ogromną wariancję wag. Raportuje się effective sample size, rozkład wag i sensitivity proposal.

NASA opisała zastosowanie importance sampling do analizy rzadkich niepożądanych dynamik startu i lądowania X-59, gdzie conventional Monte Carlo byłby kosztowny.[3] Metoda jest przenośna koncepcyjnie, ale proposal dla UAV musi wynikać z własnego modelu i failure boundary.

Nie należy używać tych samych danych do agresywnego dopasowania proposal i finalnego potwierdzenia bez uwzględnienia adaptacji. Dobrą praktyką jest faza pilot/adaptive i osobna faza estimation.

Sensitivity analysis#

Sensitivity odpowiada, które wejścia napędzają variance lub failure. Metody:

scatter/conditional plots;
rank correlation PRCC/Spearman;
standardized regression coefficients;
Morris screening;
Sobol indices;
mutual information;
tree/forest surrogate z ostrożną interpretacją;
local gradients wokół punktu;
variance decomposition według grup.

Korelacja nie jest przyczynowością. Przy skorelowanych wejściach attribution jest niejednoznaczne. Feature importance modelu ML może dzielić wpływ między zmienne arbitralnie i wymaga walidacji out-of-sample.

Dla binary failure bardziej informacyjne bywają conditional distributions:

P(input | failure) vs P(input | pass)

oraz boundary classifier. Następnie przeprowadza się targeted runs zmieniające jeden czynnik lub grupę, aby sprawdzić hipotezę.

Sensitivity służy też do redukcji modelu. Parametr o małym wpływie w badanym zakresie można ustalić, ale nie wolno przenosić tego wniosku poza scenariusz.

Analiza przebiegów nieudanych#

Failures trzeba grupować według sygnatury, nie tylko liczyć:

faza misji;
pierwsze przekroczone kryterium;
mode/estimator status;
actuator saturation;
fault active;
parametry wejściowe;
trajectory shape;
events/reset;
energy/timing.

Clustering może pomóc, ale każda grupa wymaga analizy osi czasu i reprezentatywnego replay. Najbardziej skrajny output nie zawsze jest najbardziej reprezentatywnym failure.

Wybiera się:

medoid klastra;
najwcześniejszy failure;
największe naruszenie;
przypadek najbliższy boundary;
najmniej i najbardziej prawdopodobny w klastrze;
parę pass/fail o podobnych wejściach.

Replay z dokładnym manifestem jest warunkiem debugowania. Jeśli failure nie jest powtarzalny, trzeba rozdzielić niedeterminizm modelu od race/timing infrastruktury.

Model discrepancy#

Monte Carlo propaguje rozkłady wewnątrz modelu. Nie obejmuje automatycznie brakującego efektu, np. blade flexibility, interference rotorów czy multipath zależnego od sceny.

Model discrepancy można reprezentować jako:

dodatkowy stochastic process zidentyfikowany z residuals;
bias/scale w output;
ensemble alternatywnych modeli;
scenariusze low/nominal/high fidelity;
margin/uncertainty bound;
Gaussian process discrepancy z ostrożną ekstrapolacją.

Nie należy „kalibrować” parametrów fizycznych tak, by wchłonęły wszystkie residuals, a następnie losować je jak tolerancję produkcyjną. To miesza parametric uncertainty z model form.

Raport X-43A porównał preflight Monte Carlo z danymi lotnymi i wskazał przypadki przekroczenia przewidywanych bounds oraz możliwe braki modelu.[4] To ważna lekcja: zgodność kampanii wewnętrznej nie kończy walidacji; dane operacyjne mogą ujawnić brakujący reżim.

Wybór przypadków do HIL i lotu#

Nie da się przenieść wszystkich runów do HIL. Wybiera się zestaw pokrywający:

nominal median;
wysokie/niske percentyle każdej metryki;
boundary pass/fail;
medoid każdego failure cluster;
skrajne timing/CPU;
common-cause fault;
kombinacje o dużej sensitivity;
przypadki o wysokim prawdopodobieństwie i dużej konsekwencji;
przypadki kwestionujące model.

NASA w analizie X-43A opisała wybór hardware validation cases na podstawie wyników 6-DoF Monte Carlo.[4] To lepsze niż ręczne wybranie kilku „ładnych” trajektorii.

W HIL powtarza się dokładny manifest, ale sensory i timing mogą mieć inny adapter. Różnicę SITL–HIL zapisuje się jako correlation error. Do próby fizycznej przechodzą tylko przypadki, których ryzyko jest ograniczone i pytanie nie może zostać rozstrzygnięte bez hardware.

Regresja w CI#

Pełna kampania może być zbyt kosztowna na każdy commit. Warstwy:

deterministyczne golden runs na każdy commit;
mały smoke Monte Carlo z common seeds;
targeted historical failure seeds;
nightly medium campaign;
release full campaign z frozen model/input registry;
okresowa rare-event/sensitivity campaign.

Porównując firmware A/B używa się paired runs z tymi samymi input vectors. Raportuje się różnicę metryk per para i confidence, nie tylko niezależne średnie.

Golden seeds nie mogą zastąpić świeżych prób. Controller może przeuczyć się na znane przypadki. Część seedów jest stała dla regresji, część nowa i zapisywana po kampanii.

Budżet CI powinien monitorować invalid rate i runtime distribution. Nagły wzrost czasu runu może wskazywać performance regression przed timeoutami.

Przykład kampanii#

Pytanie#

Czy quadrocopter ukończy powrót i lądowanie przy zadanej rodzinie wiatru, masy, SOC i biasu GNSS bez przekroczenia 35° roll/pitch, minimalnego napięcia i geofence?

Wejścia#

masa: zmierzony truncated distribution;
CG: joint distribution z masą payloadu;
inertia: wyliczana z modelu mas;
battery resistance: rozkład zależny od temperatury;
wind: proces Dryden/empiryczny o parametrach z danych;
GNSS: bias Gauss-Markov + white noise;
latency: empiryczny histogram;
mission start SOC: beta na zakresie operacyjnym.

Output#

pass/fail;
max tilt/rate;
minimum voltage;
energy reserve;
landing error;
geofence distance;
estimator innovations;
actuator saturation time.

Procedura#

verification sampler i constraints;
20 deterministycznych boundary runs;
pilot N=200 dla variance/runtime/failure modes;
aktualizacja planu liczebności bez zmiany kryterium;
frozen production campaign;
binomial CI i order statistics;
sensitivity i failure clustering;
replay 10 wybranych cases w HIL;
correlation report.

Jeśli pilot ujawni brak modelu, kampanię anuluje się i wersjonuje poprawiony model. Nie łączy się prób ze starym i nowym modelem w jeden wynik.

Raport#

Raport powinien zawierać:

decyzję/wymagania;
zakres applicability;
wersje code/model/data;
rejestr niepewności i provenance;
joint distribution, constraints i correlations;
sampling design, seed policy i N;
invalid/exclusion policy;
definicje metryk/oracle;
wyniki punktowe i intervals;
order statistics/percentiles;
wykres convergence;
input marginal/correlation checks;
failure clusters i replay IDs;
sensitivity;
model discrepancies i luki;
selected HIL/flight cases;
archiwum manifestów i logów.

NASA-HDBK-7009B jest aktualnym przewodnikiem dobrych praktyk M&S, uzupełniającym wymagania standardu i obejmującym produkcję, użycie oraz ocenę produktów symulacyjnych.[1] Dla portalu jest dobrym punktem odniesienia do struktury evidence package, ale konkretna kampania UAV wymaga własnych danych i kryteriów.

Typowe błędy#

Losowanie bez rejestru źródeł i jednostek.
Wszystkie parametry normalne i niezależne.
Clipping mylony z truncated distribution.
Niezależne losowanie wartości pochodnych.
Jeden globalny RNG i brak zapisu wektora wejść.
Proporcja failure z LHS interpretowana bez uwzględnienia design.
N=1000 wybrane bez power/precision planu.
Zero failures opisane jako zero ryzyka.
Wysoki percentile nazwany na podstawie maksimum małej próby.
Invalid runs usunięte bez analizy zależności.
Zatrzymanie kampanii, gdy wynik wygląda korzystnie.
Brute-force do estymacji zdarzeń 10^-6.
Importance sampling bez wag, support i effective sample size.
Feature importance opisane jako przyczyna.
Kalibracja i walidacja na tych samych lotach.
Połączenie wyników z różnych wersji modelu.
Brak korelacji SITL–HIL–lot.
Precyzyjne prawdopodobieństwo podane mimo niezwalidowanego modelu form.

Monte Carlo jest narzędziem propagacji jawnych założeń. Jego największą wartością nie jest duża liczba runów, lecz możliwość odtworzenia drogi od danych wejściowych przez konkretny model do rozkładu decyzji, znalezienia regionów failure i wyboru przypadków do droższej walidacji. Dopiero wraz z verification kodu, walidacją modelu i kontrolą niepewności wynik staje się argumentem inżynierskim, a nie kolorowym histogramem.

Powiązane tematy#

Przypisy#

NASA-HDBK-7009B, Handbook for Models and Simulations: An Implementation Guide for NASA-STD-7009B, 2026.
J. M. Hanson, B. B. Beard, NASA, Applying Monte Carlo Simulation to Launch Vehicle Design and Requirements Verification — typy niepewności, order statistics, confidence i liczebność prób; metody mają zastosowanie poza pojazdami nośnymi.
J. Ouellette, NASA, Using Importance Sampling Monte Carlo to Analyze Aircraft Takeoff and Landing — rare events i importance sampling dla dojrzałego projektu lotniczego.
NASA, The X-43A Six Degree of Freedom Monte Carlo Analysis — niepewności, wybór przypadków hardware i porównanie predykcji z lotem.
U. B. Mehta et al., NASA/TP-2016-219422, Simulation Credibility: Advances in Verification, Validation, and Uncertainty Quantification.
PX4 Project, Simulation — dostępne środowiska, sensory, modele i faster-than-real-time.
ArduPilot Project, Using SITL — konfiguracja symulacji, warianty pojazdów i uruchamianie scenariuszy.

Źródła z centralnego rejestru

NASA-HDBK-7009B: Handbook for Models and Simulations [aktualny publiczny handbook NASA, 2026]
NASA: Applying Monte Carlo Simulation to Launch Vehicle Design and Requirements Verification [publikacja techniczna NASA; metody statystyczne mają szersze zastosowanie inżynierskie]
NASA: Using Importance Sampling Monte Carlo to Analyze Aircraft Takeoff and Landing [publikacja badawcza NASA]
NASA: The X-43A Six Degree of Freedom Monte Carlo Analysis [raport techniczny NASA z korelacją predykcji i lotu]
NASA/TP-2016-219422: Simulation Credibility — Verification, Validation and Uncertainty Quantification [publikacja techniczna NASA]
PX4 Simulation [dokumentacja]
ArduPilot Dev: Using SITL [dokumentacja projektu open source]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]