Walidacja modelu symulacyjnego UAV

Model UAV jest wystarczająco dobry tylko względem określonego zastosowania. Ten sam model może prawidłowo przewidywać hover throttle i błędnie odwzorowywać tłumienie roll przy 15 m/s; może wystarczyć do testu logiki misji, ale nie do strojenia regulatora ani prognozy energii. Walidacja nie nadaje symulatorowi ogólnego certyfikatu „zgodny z rzeczywistością”. Ustala, z jakim błędem i niepewnością reprezentuje wybrane zjawiska w konkretnej domenie oraz czy to wystarcza do decyzji.

Proces zaczyna się przed zebraniem danych. Trzeba określić intended use, wielkości decyzyjne, tolerancje, obwiednię i wymagany poziom wiarygodności. Następnie osobno weryfikuje się równania i kod, jakość danych eksperymentalnych, kalibruje identyfikowane parametry i porównuje predykcje z danymi niewykorzystanymi do strojenia. Bez takiego rozdziału model łatwo dopasować do jednego lotu i błędnie uznać za przewidujący.

Spis treści#

Intended use
Verification, calibration i validation
Akredytacja i decyzja
Inwentaryzacja modelu
Plan V&V
Verification równań i kodu
Jednostki, osie i znaki
Invariants i sanity checks
Convergence i krok
Benchmark i cross-verification
Weryfikacja danych eksperymentalnych
Kalibracja
Identyfikowalność parametrów
Rozdzielenie danych
Hierarchy of validation
Testy komponentów
Testy podsystemów i HIL
Dane lotne
Synchronizacja i preprocessing
Metryki w czasie
Metryki częstotliwościowe
Porównanie zdarzeń i stanów
Residuals i model discrepancy
Budżet niepewności
Kryteria akceptacji
Domain of validation
Ekstrapolacja
Korelacja SITL–HIL–lot
Rewalidacja po zmianie
Evidence package
Przykładowy program walidacji
Typowe błędy

Intended use#

Walidację formułuje się wokół decyzji, na przykład:

dobór zapasu ciągu i energii;
strojenie pętli rate do 20 Hz bandwidth;
ocena przejścia VTOL w wietrze;
test reakcji na utratę GNSS;
predykcja landing dispersion;
wybór przypadków do HIL;
kwalifikacja zmiany śmigła;
szkolenie operatora.

Dla każdego zastosowania zapisuje się:

decision + outputs + scenarios + domain + required accuracy + consequence

Przykład:

Model ma wspierać dobór regulatora roll dla wariantu A,
przy masie 2.8–3.4 kg, prędkości 0–15 m/s, wietrze do 8 m/s,
dla komend do 150 deg/s. Błąd magnitude/phase w paśmie 1–20 Hz
nie może przekroczyć ustalonych tolerancji, a actuator saturation
ma być odwzorowane z błędem czasu poniżej X.

To jest znacznie bardziej testowalne niż „model dynamiki ma być realistyczny”.

Krytyczność decyzji wpływa na niezależność review, ilość danych, uncertainty margin i wymaganą korelację z hardware. Model do wizualizacji nie potrzebuje tego samego evidence co model decydujący o obwiedni lotu.

Verification, calibration i validation#

Verification odpowiada: czy równania zostały rozwiązane i zaimplementowane poprawnie. Obejmuje code verification, testy jednostkowe, benchmarki, convergence i błędy numeryczne.

Calibration dobiera nieznane parametry, aby model odpowiadał danym. Jest częścią budowy modelu, nie dowodem predykcji.

Validation odpowiada: czy model reprezentuje rzeczywisty system wystarczająco dla intended use. Porównuje predykcje z referentem w scenariuszach i z niepewnością.

Uncertainty quantification opisuje niepewności wejść, pomiaru, parametrów, numeryczne i model-form oraz propaguje je do odpowiedzi.

Accreditation/acceptance jest decyzją organizacyjną, że evidence i ograniczenia są wystarczające do określonego użycia.

NASA-STD-7009B ustanawia praktyki M&S i wymaga powiązania acceptance criteria z projektem oraz techniczną odpowiedzialnością; jego celem jest redukcja ryzyka decyzji opartych na modelu.[1] Nie dostarcza gotowej tolerancji dla małego UAV — tę ustala program na podstawie konsekwencji i możliwości pomiaru.

Akredytacja i decyzja#

Model może przejść testy, lecz zostać odrzucony do konkretnej decyzji, jeśli:

validation domain nie obejmuje planowanej obwiedni;
uncertainty jest większa od marginesu projektu;
brak niezależnych danych;
referent ma zbyt dużą niepewność;
model nie obejmuje krytycznego zjawiska;
wersja użyta w analizie różni się od zwalidowanej;
proces nie jest reprodukowalny.

Odwrotnie, prosty model może być zaakceptowany do testu state machine, jeśli dynamika nie wpływa na wynik albo jest objęta konserwatywnym zakresem.

Decyzja powinna wymieniać dozwolone użycia, niedozwolone użycia, wersję, domain i expiry/review trigger. „Validated model” bez tych pól jest niepełnym statusem.

Inwentaryzacja modelu#

Symulator UAV jest złożeniem:

równań ruchu 6-DoF;
mass properties;
aerodynamiki płatowca;
napędu i baterii;
aktuatorów;
sensorów;
atmosfery/wiatru/terenu;
collision/contact;
firmware/autopilota;
transportów i zegarów;
scenariusza/operatora;
solvera i infrastruktury.

Każdy element ma owner, source, version, inputs/outputs, assumptions, valid range, verification status, calibration data i validation evidence. Zależności tworzą graf: zmiana gęstości wpływa na aerodynamikę, napęd, chłodzenie i sensory ciśnienia.

Inventory powinno wskazywać komponenty third-party (Gazebo, physics engine, plugins), ponieważ update biblioteki może zmienić wynik bez modyfikacji własnego kodu.

Plan V&V#

Plan zawiera:

intended uses i decisions;
requirements oraz tolerances;
inventory i traceability;
verification matrix;
referents i eksperymenty;
calibration/validation split;
uncertainty plan;
metryki i acceptance criteria;
domain coverage;
configuration management;
independent review;
reporting i revalidation triggers.

Plan powstaje przed obejrzeniem finalnych residuals. Inaczej tolerancje łatwo dopasować do wyniku.

Każdy test ma preconditions, exact model version, exact dataset version, processing code i expected output. Review obejmuje także aparaturę oraz preprocessing, nie tylko symulator.

Verification równań i kodu#

Verification rozpoczyna się od testów najprostszych:

stały stan z zerowymi siłami/momentami;
pojedyncza siła w osi;
pojedynczy moment;
swobodny spadek;
ruch bez oporu;
znane rozwiązanie oscylatora/filtra;
thrust scaling;
transformacja quaternion/matrix;
conservation energy/momentum w modelu bez strat;
symetria ramy;
ograniczenia i saturacje.

Każdy blok ma unit tests, następnie integration. Jeśli hover nie działa, nie zaczyna się od porównania pełnego lotu; najpierw bilansuje się siły i momenty.

Verification danych obejmuje parsowanie tabel aerodynamicznych, interpolację, units i extrapolation policy. Błąd kolumny degrees/radians może przejść test kompilacji, ale nie benchmark fizyczny.

Code review powinien sprawdzić kolejność aktualizacji stanów, delay queues, reset i determinism. Off-by-one w buforze sensora może wyglądać jak fizyczne latency.

Jednostki, osie i znaki#

Lista kontrolna:

SI w rdzeniu modelu;
RPM/rad/s i deg/rad jawnie rozdzielone;
NED/ENU, FRD/FLU zdefiniowane;
aerodynamic angles ze znakami;
pressure absolute/differential;
altitude MSL/AGL/ellipsoid;
moment applied to body ze znakiem CW/CCW;
quaternion order i normalization;
timestamp unit i epoch;
density/temperature reference.

Test transformacji powinien obejmować basis vectors oraz obroty 90° wokół każdej osi. Dla sił i momentów sprawdza się right-hand rule. Dla IMU — spoczynek w sześciu orientacjach.

Dimensional analysis wykrywa wiele błędów: T=C_Tρn²D⁴ daje N, a nie N·m; moment prop ma D⁵. Testy mogą korzystać z typów jednostek albo osobnych nazw pól.

Invariants i sanity checks#

Przykłady invariants:

masa dodatnia;
inertia tensor symetryczny i dodatnio określony;
quaternion norm blisko 1;
SOC w [0,1];
passive efficiency ≤ 1;
covariance PSD;
actuator output w zakresie;
czas monotoniczny;
energy balance z tolerancją;
na płaskiej Ziemi i bez sił stała prędkość;
w modelu symetrycznym równe rotory nie tworzą roll/pitch/yaw.

Assertions powinny działać w buildzie testowym i zapisywać pierwszy moment naruszenia. Clamping wszystkiego do zakresu może ukryć błąd; lepiej rozróżnić legal saturation od invariant violation.

Sanity ranges pochodzą z fizyki i obwiedni, nie z obserwowanego runu. Warto sprawdzać order of magnitude: hover thrust ≈ weight, prąd i power w możliwym zakresie, przyspieszenia zgodne z siłą/masą.

Convergence i krok#

Solution verification sprawdza wpływ:

kroku fizyki;
solvera/tolerancji;
liczby substepów napędu;
rate sensorów;
discretization aerodynamiki;
contact solver;
synchronizacji lockstep;
precision float/double.

Wykonuje się step refinement, na przykład Δt, Δt/2, Δt/4, i porównuje metryki. Zbieżność trajektorii chaotycznej punkt-po-punkcie może być nierealistyczna; wtedy porównuje się krótkie response segments, invariants lub statystyki.

Mały globalny błąd pozycji nie gwarantuje poprawnej fazy pętli sterowania. Dla regulatora analizuje się magnitude/phase i timing zdarzeń.

Wynik kampanii musi zawierać krok. Zmiana real_time_factor nie powinna zmieniać symulacyjnej odpowiedzi lockstep; jeśli zmienia, istnieje zależność od wall-clock/transportu.

Benchmark i cross-verification#

Benchmark może mieć:

rozwiązanie analityczne;
prosty check case ze znanymi time histories;
drugi niezależny kod;
dane producenta/stanowiska;
conservation law;
regression golden output.

NASA/NESC opublikowała 6-DoF check cases z dokładnie opisanymi modelami i historiami czasu do porównania różnych frameworków.[2] Nie są modelem drona, lecz pokazują dobrą praktykę: najpierw weryfikować integrator, frames i równania na kontrolowanych przypadkach, zanim złożony płatowiec zasłoni różnice.

Cross-verification między dwoma symulatorami jest użyteczne, ale wspólna zgodność nie dowodzi zgodności z realnym statkiem. Oba mogą dzielić ten sam błąd danych albo założenie. NASA wykorzystała time/frequency-domain comparison wielu 6-DoF simulations SLS do znajdowania niespójności modeli i źródeł danych.[3]

Regression golden output wykrywa zmianę, ale może zamrozić dawny błąd. Każdy golden ma źródło i review.

Weryfikacja danych eksperymentalnych#

Referent też ma błędy. Przed użyciem danych trzeba zweryfikować:

kalibrację i niepewność aparatury;
range/resolution/bandwidth;
sampling i synchronizację;
mounting/lever arms;
units/frames;
environmental conditions;
missing samples i clipping;
filter/preprocessing;
configuration statku;
repeatability;
traceability do surowego pliku.

Jeśli load cell ma bandwidth 10 Hz, nie waliduje transientu napędu 50 Hz. Jeśli GNSS ground truth ma 1 m accuracy, nie można na jego podstawie potwierdzić 10 cm landing error.

Pomiar uncertainty powinien być propagowany do residual. NASA-HDBK-8739.19-3 opisuje zasady measurement uncertainty analysis.[4] Użycie jednego „dokładnego” trace bez error bars prowadzi do zbyt ostrych lub arbitralnych wniosków.

Kalibracja#

Kalibracja minimalizuje wybraną funkcję błędu albo wyznacza posterior parametrów. Przykład:

θ* = argmin Σ w_i (y_meas,i - y_model,i(θ))²

Wagi powinny wynikać z uncertainty/celu, nie tylko wygody. Scale outputów zapobiega dominacji wielkości o dużych liczbach.

Proces zapisuje:

parameter bounds i priors;
dataset;
cost function;
optimizer i seed;
initial points;
constraints;
identifiability/correlation;
fitted values i uncertainty;
residual diagnostics;
out-of-sample performance.

W modelu napędu nie dopasowuje się niezależnie kT, kQ, efficiency i battery resistance do samego thrust. Potrzebne są RPM, torque/current/voltage i wiele punktów.

Regularization może stabilizować fit, ale wprowadza assumption. Parametr na granicy bounds często sygnalizuje brak modelu lub słabą identyfikowalność.

Identyfikowalność parametrów#

Dwa parametry są nierozróżnialne, jeśli zmieniają output w niemal ten sam sposób w wykonanych eksperymentach. Przykłady:

drag i wind bias w jednym kierunku;
motor time constant i sensor latency w jednym stepie;
mass oraz thrust scale bez niezależnego ważenia/RPM;
CG offset i stały trim;
IMU misalignment i frame rotation.

Analiza local sensitivity/Jacobian, profile likelihood, posterior correlation lub Fisher information pokazują problemy. Rozwiązaniem jest lepsze pobudzenie i niezależny pomiar, nie tylko dłuższa optymalizacja.

Jeśli parametr nie jest identyfikowalny, można:

zmierzyć go osobno;
ustalić z prior/datasheet;
połączyć parametry w efektywny współczynnik;
zaprojektować nowy eksperyment;
propagować szeroką uncertainty zamiast podawać punkt.

Model z wieloma parametrami może idealnie pasować do calibration set, lecz mieć duży predictive uncertainty.

Rozdzielenie danych#

Minimum:

calibration/training — dobór parametrów;
validation/test — zamrożona ocena;
challenge — inne warunki/obwiednia blisko granicy;
operational monitoring — dane po wdrożeniu.

Losowe dzielenie sąsiednich próbek jednego lotu powoduje leakage, bo zestawy są silnie skorelowane i dzielą warunki. Lepiej dzielić całymi lotami, dniami, egzemplarzami lub konfiguracjami.

Jeśli po obejrzeniu validation set zmieniono model, dane stały się częścią development. Potrzebny jest nowy niezależny zestaw albo jawna aktualizacja procesu.

Cross-validation może pomóc przy małej liczbie lotów, ale nie zastępuje challenge w innym reżimie. Raport wskazuje wszystkie iteracje, aby uniknąć selection bias.

Hierarchy of validation#

Walidacja jest piramidą:

materiał/komponent;
sensor/aktuator;
napęd na hamowni;
płatowiec statyczny/modalny;
podsystem zamkniętej pętli;
HIL;
ograniczone próby naziemne/tether;
loty w rosnącej obwiedni;
mission scenarios;
fleet/operational data.

Niższe poziomy izolują parametry i dają lepszą obserwowalność. Lot end-to-end potwierdza integrację, lecz trudno z niego jednoznacznie wyznaczyć przyczynę residual.

Każdy poziom ma własny referent i kryteria. Zgodność końcowej pozycji nie może kompensować złych sensorów, napędu i aerodynamiki, które przypadkiem się znoszą.

Testy komponentów#

Przykłady:

hamownia napędu: thrust/torque/RPM/current/voltage w statyce i transient;
model sensora: PSD, Allan deviation, latency, clipping, temperature;
serwo: position/velocity/torque/deadband/backlash;
bateria: OCV, pulse resistance, thermal, capacity;
rama: mass properties, modal frequencies i damping;
airframe: wind tunnel/CFD correlation lub flight ID.

Component validation powinna obejmować dokładny wariant, montaż i warunki. Śmigło bez ramienia na hamowni może różnić się od instalacji na pojeździe.

Wyniki trafiają do parameter database z uncertainty i provenance. Nie przepisuje się wykresu producenta jako dokładnej tabeli bez danych cyfrowych i warunków.

Testy podsystemów i HIL#

HIL waliduje:

timing i scheduling;
protokoły sensorów/aktuatorów;
latency/jitter;
watchdog/reset;
computational load;
state machines;
fault reaction;
zgodność builda targetowego.

Nie waliduje automatycznie fizyki sensora czy płatowca. Stanowisko HIL ma własny model i uncertainty.

Porównuje się ten sam manifest SITL i HIL. Różnice dzieli się na oczekiwane (hardware timing, quantization) i nieoczekiwane. Przydatne są GPIO markers oraz logic analyzer do niezależnego czasu.

Load emulators i prawdziwe peryferia zwiększają wierność warstwy interfejsu. Każdy dodany komponent zmienia boundary modelu i plan walidacji.

Dane lotne#

Flight-test matrix powinien pobudzać interesujące stopnie swobody i zakresy, zachowując bezpieczeństwo. Przykłady:

hover w wielu masach/SOC;
małe doublets/chirp roll/pitch/yaw;
step altitude/velocity;
straight flight na wielu prędkościach;
turn/climb/descent;
transition VTOL w kilku warunkach;
landing approach;
kontrolowany wiatr, jeśli możliwy;
bezpieczne scenariusze failure po wcześniejszym SITL/HIL.

Pobudzenie musi być wystarczające do identyfikacji, ale nie przekraczać zatwierdzonej obwiedni. Test plan ma abort criteria.

Ground truth może obejmować RTK, motion capture, tachometry, load telemetry, calibrated air data i niezależny logger. Flight controller log nie jest niezależnym referentem dla wszystkich jego własnych estymat.

NASA pokazała przykład walidacji flight simulation przez porównanie wyznaczonych z lotu sił i momentów aerodynamicznych z predykcją, a także ocenę charakterystyk przez pilotów; mimo dobrej ogólnej korelacji ujawniono różnice w określonych reżimach.[5] To ilustruje potrzebę wielu metryk i scenariuszy.

Synchronizacja i preprocessing#

Przed porównaniem trzeba ustalić:

wspólną oś czasu;
clock offset/drift;
latency każdego kanału;
resampling/interpolation;
frames i lever arms;
units;
filter phase/group delay;
missing/outliers;
trim/initial state;
atmospheric inputs.

Ręczne przesunięcie trace „aż pasuje” jest kalibracją czasu. Offset trzeba wyznaczyć metodą i uncertainty, najlepiej z trigger/marker. Osobne przesunięcie każdego kanału może sztucznie poprawić zgodność fazy.

Filtr offline powinien być zero-phase tylko wtedy, gdy celem nie jest timing; do walidacji causal dynamics trzeba modelować rzeczywiste opóźnienie. Raw i processed data zachowuje się razem z kodem.

Initial state modelu powinien pochodzić z pomiaru lub state estimation z uncertainty. Błąd startu może dominować krótki transient.

Metryki w czasie#

Nie ma jednej uniwersalnej metryki. Użyteczne:

bias/mean residual;
RMSE/MAE;
max absolute error;
normalized error względem uncertainty;
peak amplitude i timing;
rise/settling time;
overshoot;
integral absolute error;
cross-correlation lag;
envelope coverage;
dynamic time warping — ostrożnie, bo może ukryć błędną fazę.

Residual:

r(t) = y_meas(t) - y_model(t)

powinien być analizowany względem czasu, state, command, temperature i phase of flight. Zerowa średnia nie wystarcza, jeśli residual jest skorelowany z throttle.

Normalized residual może dzielić przez łączną standard uncertainty modelu i pomiaru. Jeśli uncertainty jest błędnie duża, model przejdzie łatwo; budżet podlega niezależnej ocenie.

Porównuje się także derivatives/rates, ale różniczkowanie danych zwiększa szum. Lepiej mierzyć właściwy kanał lub użyć zwalidowanego filtra z uncertainty.

Metryki częstotliwościowe#

Dla regulatora i drgań używa się:

PSD;
transfer function estimate;
gain/phase;
coherence;
resonant frequencies/damping;
bandwidth/crossover;
spectral lines i harmonics;
order tracking względem RPM.

Time-domain match jednego inputu może ukrywać zły phase margin. Frequency response na kontrolowanych pobudzeniach pokazuje różnice w paśmie intended use.

Coherence niska oznacza, że estymata FRF jest słaba lub system ma inne input/noise/nonlinearity. Nie porównuje się gain tam, gdzie coherence nie daje wiarygodności.

Nonlinear system wymaga kilku amplitud i punktów pracy. Jedna FRF wokół hover nie waliduje agresywnego lotu ani transition.

Rezonanse ramy należy walidować przez modal/FRF i dane IMU; tłumienie wysokich częstotliwości przez filtr nie jest zgodnością mechaniki.

Porównanie zdarzeń i stanów#

Modele software ocenia się także dyskretnie:

kolejność eventów;
mode transitions;
health flags;
estimator source selection;
arming checks;
failsafe entry/exit;
reset/recovery;
watchdog;
timeouty;
mission state.

Metryki to event latency, missing/extra event, wrong state i dwell time. Dwa trace ciągłe mogą być podobne, lecz state machine wybrać złą ścieżkę.

Oracle powinien używać ground truth i niezależnych clocków. Test fault injection weryfikuje zarówno fizyczny skutek, jak i decyzję software.

Residuals i model discrepancy#

Residual zawiera:

measurement error + input uncertainty + parameter uncertainty
+ numerical error + model-form discrepancy

Nie można przypisać go model form bez oszacowania pozostałych składników. Jednocześnie systematic structure residual — zależność od prędkości, throttle, temperatury — jest wskazówką brakującego zjawiska.

Diagnostyka:

histogram i Q-Q;
autocorrelation;
PSD;
residual vs predicted/state/input;
heteroscedasticity;
change points;
cross-run repeatability;
per-axis/per-phase.

Dodanie elastycznego discrepancy model może poprawić coverage, ale nie naprawia mechanizmu. Powinien być osobno wersjonowany i nie ekstrapolowany bez evidence.

Jeżeli calibration absorbuje discrepancy do parametru, jego wartość może być niefizyczna i nieprzenośna. W raporcie rozróżnia się effective fitted parameter od measured physical property.

Budżet niepewności#

Składniki:

measurement uncertainty referenta;
input/state uncertainty;
parameter posterior/tolerance;
numerical discretization;
stochastic sampling;
synchronization;
data processing;
model discrepancy;
configuration variability.

Nie zawsze można je sumować RSS — potrzebne są assumptions o niezależności i rozkładzie. Korelacje muszą być uwzględnione.

Propagacja może używać linear sensitivity, unscented transform, polynomial chaos, Monte Carlo albo bounds. Monte Carlo UAV opisuje sampling i confidence.

Validation comparison powinno mieć combined uncertainty. Przykład:

d = y_model - y_measurement
u_c² = u_model² + u_measurement² - 2 cov(...)

Następnie porównuje się discrepancy z tolerancją decyzji, nie tylko z zero. Niewielki statistically significant bias może być inżyniersko nieistotny; duża uncertainty może ukrywać inżyniersko groźną różnicę.

Kryteria akceptacji#

Kryteria powinny być:

ustalone przed final validation;
związane z intended use;
mierzalne;
per-output/per-domain;
uwzględniające uncertainty;
rozdzielające pass/fail/inconclusive;
zatwierdzone przez odpowiedzialną stronę.

Przykłady:

hover thrust/current error < określona wartość w domenie RPM/V;
motor rise time error < X ms;
magnitude/phase error w paśmie;
landing position distribution coverage;
state transition latency;
sensor PSD/Allan deviation bounds;
energy prediction interval coverage;
no unexplained systematic residual > margin.

Jedno globalne RMSE może ukryć lokalne błędy krytyczne. Kryteria powinny mieć też boundary segments.

Inconclusive jest prawidłowym wynikiem, gdy uncertainty referenta jest za duża albo pobudzenie niewystarczające. Nie należy wymuszać pass/fail z danych bez rozdzielczości.

Domain of validation#

Domain opisuje zakres zwalidowanych:

mass/CG/inertia;
prędkości, AoA/sideslip, rates;
altitude/density/temperature;
wind/turbulence;
RPM/throttle/voltage;
konfiguracji/variant/payload;
firmware/model version;
sensor modes/rates;
maneuvers i amplitudes;
ground/contact regimes;
failures.

Można przedstawić domain jako tabelę lub wielowymiarowy convex/nonconvex set. Prosty min/max na każdej osi może sugerować pokrycie kombinacji, których nie testowano. Lepiej zachować design points i coverage map.

NASA-HDBK-7009B opisuje domain of validation jako wynik scenariuszy empirical validation; intended use poza nim wymaga argumentu extrapolation i dodatkowej uncertainty.[6]

Status modelu powinien być automatycznie sprawdzany przy konfiguracji runu: inside_validated_domain, interpolation_with_gap, outside_domain. Wynik poza domain nie znika, ale ma ostrzeżenie i nie może być użyty tak samo.

Ekstrapolacja#

Ekstrapolacja jest czasem konieczna, lecz musi mieć:

fizyczne uzasadnienie trendu;
distance-to-domain;
uncertainty rosnącą z odległością;
sensitivity/model alternatives;
conservative margin;
plan zdobycia danych;
limit decyzji.

Tabela C_T(J) nie powinna być płasko przedłużona poza pomiary. Model IMU zwalidowany statycznie nie potwierdza vibration clipping. Aerodynamika w małym AoA nie waliduje stall.

Interpolation również nie jest automatycznie bezpieczna, jeśli domain ma holes albo regime change. Phase transition, saturation, contact i mode switch wymagają gęstszego pokrycia.

Model surrogate/ML powinien mieć out-of-distribution detection i provenance training data. Gładka predykcja poza danymi nie jest evidence.

Korelacja SITL–HIL–lot#

Korelacja używa wspólnego test ID i manifestu:

same scenario → SITL result → HIL result → rig result → flight result

Na każdym przejściu zmienia się boundary:

SITL→HIL: prawdziwy MCU, timing, drivers część/całość;
HIL→rig: prawdziwe peryferia/zasilanie/aktuatory;
rig→flight: mechanika, przepływ, środowisko i pełna integracja.

Różnice klasyfikuje się:

expected due to fidelity;
configuration mismatch;
timing/interface;
measurement uncertainty;
model-form;
unknown.

Nie „poprawia się” modelu po każdym locie bez zachowania wcześniejszej wersji. Model calibrated-v2 musi ponownie przejść independent validation.

Correlation dashboard może pokazywać metryki i domain coverage, ale raw traces oraz processing pozostają źródłem evidence.

Rewalidacja po zmianie#

Triggers:

zmiana równań/pluginu/solvera;
update Gazebo/PX4/ArduPilot;
nowy sensor/napęd/payload;
zmiana mass properties;
firmware affecting timing/control;
nowe dane lub poprawiona kalibracja;
zmiana intended use/domain;
wykryta anomaly w locie;
zmiana preprocessing;
przekroczenie expiry.

Impact analysis mapuje zmianę do modeli, testów i decyzji. Nie każda zmiana wymaga pełnej kampanii, ale zakres regression musi być uzasadniony.

Semantic version modelu może rozdzielać breaking physics change, calibration update i metadata. Każdy artefakt zapisuje exact hash, nie tylko nazwę „v2”.

Operational monitoring porównuje nowe loty z prediction intervals. Drift populacji komponentów lub firmware może wymagać rewalidacji nawet bez zmiany pliku modelu.

Evidence package#

Minimalny pakiet:

model requirements i intended use;
configuration/version inventory;
equations/assumptions;
source/data pedigree i licenses;
verification matrix/results;
calibration plan/data/code/results;
validation plan/data/code/results;
measurement uncertainty;
UQ/sensitivity;
residual diagnostics;
acceptance criteria i verdicts;
domain of validation;
limitations/known discrepancies;
cross-environment correlation;
independent review issues/resolution;
revalidation triggers;
reproducible run instructions i hashes.

NASA software assurance guidance wskazuje validation reports, output comparisons, input integrity, traceability, audits i anomalies jako objective evidence dla modeli używanych do kwalifikacji.[7]

Evidence powinno być możliwe do odtworzenia na czystym środowisku. Jeśli dataset jest poufny/duży, zapisuje się immutable identifier, checksum i dostęp, a publiczny raport opisuje metodę bez ujawnienia danych.

Przykładowy program walidacji#

Cel#

Model quadrocoptera ma wspierać strojenie rate/attitude i prognozę energii dla masy 2,8–3,4 kg, hover oraz lotu do 12 m/s.

Etap 1 — verification#

frames/units/basis tests;
force/moment balance;
analytical first-order motor;
integrator convergence;
energy/inertia invariants;
6-DoF benchmark;
deterministic replay.

Etap 2 — komponenty#

ważenie i CG/inertia;
hamownia T/Q/RPM/V/I, static + steps;
bateria pulse/capacity/thermal;
IMU static/PSD/Allan/latency;
modal test ramy;
servo response.

Etap 3 — kalibracja#

fit motor/prop on subset;
fit drag/damping on dedicated maneuvers;
quantify parameter covariance;
freeze model v1.

Etap 4 — validation#

unused hamownia points;
unused mass/voltage;
flight doublets/chirps;
hover/straight flight/turn/descent;
energy mission;
challenge at domain edges;
time/frequency metrics z uncertainty.

Etap 5 — HIL#

common manifests;
timing/latency/GPIO;
CPU overload/faults;
compare mode/events and response.

Etap 6 — Monte Carlo#

propagate measured variability;
identify boundary/failure clusters;
select HIL/flight cases;
report confidence.

Etap 7 — acceptance#

independent review;
domain/limitations;
approved intended uses;
revalidation plan.

Jeśli model nie spełnia kryterium, możliwe wyniki to: poprawa modelu, redukcja domain, zwiększenie uncertainty/margin, zmiana intended use albo dodatkowy eksperyment. Nie zawsze właściwa jest optymalizacja aż trace pasuje.

Typowe błędy#

„Walidacja” przez uruchomienie symulatora bez crashu.
Jedno successful hover jako evidence całej obwiedni.
Brak intended use i tolerancji przed testem.
Mylenie verification z validation.
Kalibracja i ocena na tych samych danych.
Losowy split próbek jednego lotu i leakage.
Referent bez uncertainty, synchronizacji i raw data.
Ręczne przesuwanie trace bez rejestracji latency.
Jedno RMSE dla wszystkich faz i osi.
Dobra zgodność outputu dzięki kompensującym się błędom podmodeli.
Brak step-size/convergence study.
Cross-verification dwóch kodów uznane za real-world validation.
Model producenta/CFD przyjęty bez provenance i domain.
Parametry na granicach fit bez identifiability analysis.
Brak residual vs state/input i PSD.
Ekstrapolacja poza domain bez rosnącej uncertainty.
Wyniki z innej wersji Gazebo/pluginu niż validated.
Update calibration bez powtórzenia independent validation.
Brak archive manifestów, kodu processing i hashes.

Walidacja jest argumentem, nie pojedynczym wykresem. Łączy poprawność implementacji, jakość referenta, identyfikowalność parametrów, niezależne dane, metryki związane z decyzją i jawny budżet niepewności. Najważniejszym produktem nie jest etykieta „validated”, lecz mapa: do czego model jest przydatny, w jakiej domenie, z jakim błędem, na podstawie jakich danych i co musi się wydarzyć, aby tę ocenę powtórzyć.

Powiązane tematy#

Przypisy#

NASA-STD-7009B, Standard for Models and Simulations, wydanie B, 2024 — lifecycle, credibility assessments i acceptance criteria dla intended use.
D. G. Murri, E. B. Jackson, R. O. Shelton et al., NASA/TM-2015-218675, Check-Cases for Verification of 6-Degree-of-Freedom Flight Vehicle Simulations.
NASA, Time and Frequency-Domain Cross-Verification of SLS 6-DoF Trajectory Simulations — porównanie niezależnych środowisk i wykrywanie niespójności.
NASA-HDBK-8739.19-3, Measurement Uncertainty Analysis Principles and Methods.
T. P. Ratvasky, B. P. Barnhart, S. Lee, J. Cooper, NASA/TM-2007-214936, Flight Testing an Iced Business Jet for Flight Simulation Model Validation.
NASA-HDBK-7009B, Handbook for Models and Simulations, 2026 — verification, empirical validation, calibration, domain of validation i evidence.
NASA Software Engineering Handbook, SWE-070, Models, Simulations, Tools — objective evidence, traceability, input integrity, comparisons i review.
U. B. Mehta et al., NASA/TP-2016-219422, Simulation Credibility: Advances in Verification, Validation, and Uncertainty Quantification.
NASA, The X-43A Six Degree of Freedom Monte Carlo Analysis — porównanie preflight predictions z danymi lotnymi i możliwe model shortfalls.

Źródła z centralnego rejestru

NASA-STD-7009B: Standard for Models and Simulations [aktywny standard NASA, wydanie B z 2024 roku]
NASA-HDBK-7009B: Handbook for Models and Simulations [aktualny publiczny handbook NASA, 2026]
NASA/TP-2016-219422: Simulation Credibility — Verification, Validation and Uncertainty Quantification [publikacja techniczna NASA]
NASA/TM-2015-218675: Check-Cases for Verification of 6-DoF Flight Vehicle Simulations [benchmark i raport techniczny NASA/NESC]
NASA: Time and Frequency-Domain Cross-Verification of SLS 6-DoF Trajectory Simulations [publikacja techniczna NASA]
NASA/TM-2007-214936: Flight Testing an Iced Business Jet for Flight Simulation Model Validation [przykład walidacji modelu symulacyjnego danymi lotnymi NASA]
NASA: The X-43A Six Degree of Freedom Monte Carlo Analysis [raport techniczny NASA z korelacją predykcji i lotu]
NASA-HDBK-8739.19-3: Measurement Uncertainty Analysis Principles and Methods [handbook NASA dotyczący niepewności pomiaru]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]