Symulacja SITL, HITL i HIL

Co jest modelowane#

W SITL firmware działa jako proces, a sensory i dynamika są symulowane. W HITL/HIL fizyczny kontroler uczestniczy w pętli z modelem. Nazwy bywają używane różnie, więc raport testu musi jawnie wymienić elementy prawdziwe i symulowane.

Model sensora#

Idealny sensor tworzy fałszywe poczucie jakości. Model powinien obejmować bias, szum, opóźnienie, dropout, ograniczenie zakresu i częstotliwość. Dla GNSS ważne są skoki jakości oraz utrata poprawek, nie tylko stały biały szum pozycji.

Fault injection#

Wstrzykuj jedną awarię z określonym czasem: zatrzymanie próbek IMU, skok barometru, utratę GNSS, opóźnienie łącza, spadek pojemności. Kryterium opisuje stan oczekiwany i maksymalny czas reakcji.

Powtarzalność#

Zapisuj commit, parametry, model, seed i wersję symulatora. Test ręczny w Gazebo jest demonstracją; test CI z tolerancją i raportem jest regresją. Modele muszą mieć walidację względem pomiarów fizycznych.

Granica#

SITL nie ujawni odwróconego złącza, grzania ESC ani rezonansu ramy, jeśli model ich nie zawiera. Celem symulacji jest wcześniejsze eliminowanie klas błędów, nie zastąpienie prób sprzętowych.

Nazwy i granica symulacji#

SIL, SITL, PIL, HITL i HIL nie mają jednej, konsekwentnie stosowanej definicji. Zamiast polegać na skrócie, raport powinien zawierać schemat granicy:

W SITL mogą działać prawdziwe algorytmy misji, estymator i regulatory, ale sterowniki sprzętowe są zastąpione warstwą symulacyjną. W HIL fizyczny kontroler otrzymuje sztuczne pomiary i zwraca komendy aktuatorów. HIL bada więc timery, obciążenie CPU, sterowniki i interfejsy, lecz nadal nie dowodzi poprawności modelu aerodynamicznego.

Z czego składa się środowisko#

Pełne stanowisko obejmuje:

scenariusz i środowisko
        ↓
model dynamiki ← komendy aktuatorów ← firmware/autopilot
        ↓                                  ↑
modele sensorów ───── komunikacja ─────────┘
        ↓
rejestrator, kryteria i raport testu

Model dynamiki całkuje równania ruchu bryły sztywnej oraz model napędu i aerodynamiki. Model środowiska dostarcza grawitację, atmosferę, wiatr, teren, pole magnetyczne i sygnały nawigacyjne. Modele sensorów zamieniają stan prawdziwy na to, co zobaczy firmware. Osobny moduł scenariusza steruje zdarzeniami i awariami. Jeśli wizualizator 3D nie uczestniczy w żadnym z tych zadań, jest tylko prezentacją — może być użyteczny, ale nie stanowi istoty symulacji.

Czas wirtualny i czas ścienny#

W SITL symulator może przyspieszać, zwalniać albo krokować czas deterministycznie. Firmware musi wtedy korzystać z dostarczonego zegara symulacji; odwołanie do zegara systemowego w jednym module psuje powtarzalność. Przyspieszenie jest szczególnie przydatne dla długich misji, testów zużycia energii i Monte Carlo.

HIL jest związany z czasem fizycznym. Jeżeli próbka IMU ma dotrzeć co 1 ms, komputer modelu musi dotrzymać deadline, a nie tylko wygenerować poprawną średnią częstotliwość. W raporcie zapisuje się jitter, liczbę przekroczeń i opóźnienie end-to-end. Model spóźniający się okresowo może sztucznie destabilizować regulator.

Deterministyczność wymaga zapisania:

• wersji firmware i modelu;
• kompletnego zestawu parametrów;
• ziarna generatora losowego;
• początkowego stanu i pozycji;
• wersji świata, mapy oraz zależności;
• skali czasu i konfiguracji komputera, gdy ma ona wpływ na deadline.

Model płatowca#

Minimalny model multirotora obejmuje masę, tensor bezwładności, geometrię rotorów, zależność ciągu i momentu od prędkości oraz opóźnienie napędu. Stała „ciąg równy komendzie” daje zbyt optymistyczną odpowiedź. Silnik, ESC i śmigło mają dynamikę, martwą strefę, ograniczenie prędkości oraz zależność od napięcia.

Dla fixed-wing potrzebne są co najmniej siły nośna i oporu zależne od kąta natarcia i prędkości, momenty aerodynamiczne, skuteczność powierzchni sterowych oraz model napędu. Liniowy model w pobliżu punktu pracy może wystarczyć do strojenia regulatora, ale nie do testu przeciągnięcia, startu czy głębokiego zakrętu. Zakres ważności modelu powinien być jawny.

Parametry nie mogą być dobierane wyłącznie tak, aby wykres wyglądał jak oczekiwany. Masę i geometrię mierzy się bezpośrednio, charakterystyki napędu na stanowisku, a współczynniki aerodynamiczne z danych producenta, CFD, tunelu lub identyfikacji w locie. Każdy parametr ma źródło i niepewność.

Modele aktuatorów i energii#

Model aktuatora powinien uwzględniać:

• limit amplitudy i szybkości zmian;
• opóźnienie transportowe;
• martwą strefę i histerezę serwa;
• różnice między kanałami;
• awarię typu stuck, loss-of-effectiveness i intermittent;
• wpływ napięcia oraz temperatury, jeżeli jest istotny.

Model baterii nie musi od razu rozwiązywać chemii ogniwa. Do testu logiki wystarcza często stan energii, rezystancja wewnętrzna i krzywa napięcia pod obciążeniem. Powinien jednak powodować realistyczny spadek autorytetu napędu. Stałe napięcie aż do nagłego zera nie sprawdzi progów ostrzegawczych ani decyzji powrotu.

Sensor to nie stan prawdziwy#

Firmware nie otrzymuje idealnego kąta czy pozycji, lecz surowe próbki. Użyteczny model IMU dodaje bias, szum, skalę, niewspółosiowość, ograniczenie zakresu, kwantyzację i opóźnienie. Bias może zależeć od temperatury, a szum powinien mieć właściwości czasowe — biały szum nie zastępuje random walk.

Każda próbka powinna mieć czas pomiaru, nie tylko czas dostarczenia. Estymator kompensujący opóźnienia musi wiedzieć, kiedy obserwacja rzeczywiście powstała. Losowe opóźnienie komunikacji i kolejki należy modelować osobno od częstotliwości sensora.

Środowisko i kontakt z otoczeniem#

Stały wiatr jest łatwym przypadkiem. Bardziej wartościowe są porywy, gradient z wysokością i turbulencja o określonym widmie. Dla lotu blisko gruntu znaczenie mają efekt przyziemny, struga od rotorów i wiatr zaburzony przez budynki. Symulowanie ich ma sens tylko wtedy, gdy model został zweryfikowany dla danego zastosowania.

Świat 3D powinien mieć geometrię zgodną z sensorami. Kamera potrzebuje tekstur i oświetlenia, lidar właściwości powierzchni, a GNSS modelu zasłonięcia lub wielodrożności, jeśli test ma badać miejską nawigację. „Ładna scena” nie gwarantuje poprawnej charakterystyki pomiaru.

Kontakt z ziemią jest trudny numerycznie. Parametry tarcia, sprężystości i kroku solvera wpływają na start i lądowanie. Skaczący płatowiec w Gazebo może wynikać z modelu kontaktu, a nie regulatora. Warto rozdzielić test logiki lądowania od dokładnej symulacji podwozia.

Fault injection#

Awaria jest eksperymentem z warunkiem początkowym, momentem aktywacji i kryterium zaliczenia. „Wyłączyć GPS i zobaczyć” nie daje powtarzalnego testu. Przykład specyfikacji:

given: stabilny lot na 40 m, wiatr 3 m/s, poprawne INS
when: od t=60 s brak nowych wiadomości GNSS przez 20 s
then: status źródła staje się invalid w ≤2 s,
      nie następuje skok żądania większy niż limit,
      tryb przechodzi do zdefiniowanego stanu degradacji,
      zdarzenie i przyczyna są zapisane w logu

Macierz testów powinna objąć awarie typu: brak danych, dane nieświeże, stała wartość, pojedynczy outlier, powolny dryft, błędny timestamp i niespójność dwóch sensorów. Są to inne przypadki. Watchdog wykryje zatrzymanie procesu, lecz może nie wykryć sensora wysyłającego wiarygodnie wyglądające, stare wartości.

W łączności testuje się opóźnienie, jitter, utratę serii pakietów, zmianę kolejności, ograniczoną przepustowość i rozłączenie. W energii — błędną kalibrację prądu, sag, szybkie starzenie oraz uszkodzenie ogniwa. W aktuatorach — ograniczenie skuteczności, zablokowanie i asymetrię.

ArduPilot SITL#

ArduPilot buduje SITL dla hosta i udostępnia narzędzia uruchamiające pojazd wraz z konsolą oraz mapą. Typowy bezpieczny start developerski ma postać:

cd ardupilot/ArduCopter
sim_vehicle.py -w

Opcja -w kasuje parametry symulowanego pojazdu i powinna być używana świadomie. Kolejne uruchomienia bez niej zachowują konfigurację. Typ ramy i lokalizację dobiera się argumentami narzędzia zgodnie z aktualną dokumentacją. Do automatyzacji służą testy AutoTest, a do analizy istniejącego logu — mechanizmy replay dla wspieranych strumieni.

Warstwa AP_HAL oddziela logikę autopilota od sprzętu. SITL dostarcza implementację zegara, wejść sensorów i wyjść. Dzięki temu znaczna część kodu jest wspólna z wersją sprzętową, lecz właśnie różnice HAL są granicą dowodu.

PX4 SITL i Gazebo#

PX4 buduje firmware dla celu px4_sitl, a wybrany model i symulator uruchamia celem make. Przykład z oficjalnej dokumentacji:

make px4_sitl gz_x500

PX4 komunikuje się z symulatorem przez warstwę mostu, publikuje dane w uORB i uruchamia te same moduły estymacji oraz sterowania co na sprzęcie, z zależnościami właściwymi dla celu SITL. Świat, model i parametry muszą być częścią wersjonowanego scenariusza. Ręczne sterowanie modelem w GUI jest dobrym smoke testem, lecz CI powinno sterować misją programowo i sprawdzać warunki liczbowe.

HIL: sprzęt w pętli#

HIL dodaje rzeczywisty kontroler, więc ujawnia:

• błędy konfiguracji zegarów i timerów;
• przeciążenie CPU oraz niewykonane deadline;
• problemy portów, prędkości i buforów;
• różnice arytmetyki i optymalizacji docelowego MCU;
• zachowanie watchdogów i restartów;
• błędy inicjalizacji, których build hosta nie ma.

Stanowisko musi uniemożliwiać przypadkowe uruchomienie napędu. Śmigła są zdjęte, linie aktuatorów prowadzą do bezpiecznego interfejsu, a zasilanie ma ograniczenie prądowe i fizyczny wyłącznik. Nie wolno zakładać, że tryb HIL zawsze blokuje wszystkie wyjścia — sprawdza się to dla konkretnej wersji firmware.

Interfejs podający sztuczne sensory powinien zachowywać poziomy elektryczne oraz timing, które test ma objąć. Gdy dane trafiają wyłącznie wysokopoziomowym protokołem, test nie sprawdza sterownika SPI rzeczywistego IMU. To nadal wartościowy HIL, ale o węższym zakresie.

Testy regresyjne i CI#

Dobry test automatyczny ma fazy: przygotowanie, osiągnięcie stabilnego stanu, pobudzenie, obserwację, asercje i zebranie artefaktów. Kryteria powinny uwzględniać tolerancję modelu, lecz nie mogą brzmieć „pojazd mniej więcej doleciał”. Przykłady:

• uzbrojenie następuje albo jest odrzucone z oczekiwanym kodem;
• wysokość pozostaje w przedziale przez ustalony czas;
• waypoint zostaje zaliczony z określonym promieniem;
• po awarii wybrany tryb pojawia się przed deadline;
• maksymalne przeregulowanie i czas ustalenia mieszczą się w granicach;
• nie wystąpił reset, błąd estymatora ani przekroczenie pętli.

Artefakty obejmują log autopilota, log symulatora, wersje, parametry i ziarno. Zrzut ekranu nie wystarcza do reprodukcji. Test niestabilny należy naprawić przez kontrolę czasu i losowości, a nie przez wielokrotne ponawianie do sukcesu.

Monte Carlo i testy parametrów#

Pojedyncza trajektoria bada jeden punkt. Monte Carlo losuje masę, wiatr, bias sensorów, opóźnienie i sprawność napędu w uzasadnionych zakresach. Wynikiem jest rozkład metryk i lista przypadków niezaliczonych, a nie tylko średnia. Najgorszy przypadek trzeba odtworzyć dzięki zapisanemu ziarnu.

Przestrzeń parametrów rośnie szybko. Zamiast losować wszystko bez planu, stosuje się klasy równoważności, wartości graniczne, projekt eksperymentu i ryzyko. Najpierw bada się parametry, na które dana funkcja jest fizycznie wrażliwa.

Walidacja modelu#

Model weryfikuje się pytaniem „czy równania rozwiązano poprawnie?”, a waliduje pytaniem „czy opisują rzeczywisty obiekt wystarczająco dobrze do celu testu?”. Walidacja jest lokalna: model potwierdzony dla zawisu nie musi być poprawny przy dużym kącie natarcia.

Porównuje się te same pobudzenia i sygnały w symulacji oraz eksperymencie: prędkości kątowe, przyspieszenia, RPM, prąd i trajektorię. Różnicę opisuje się metrykami, nie dopasowuje „na oko”. Dane użyte do strojenia parametrów należy oddzielić od danych użytych do oceny.

Drabina dowodów#

Praktyczna kolejność ogranicza koszt wykrycia błędu:

1. testy jednostkowe matematyki i automatów stanów;
2. testy komponentowe z kontrolowanym zegarem;
3. SITL pojedynczej funkcji;
4. scenariusze misji i fault injection;
5. Monte Carlo oraz regresja CI;
6. HIL z docelowym kontrolerem;
7. stanowisko napędu i integracja bez śmigieł;
8. próby naziemne;
9. ograniczony lot w bezpiecznym obszarze;
10. stopniowe rozszerzanie obwiedni.

Przejście poziomu nie unieważnia niższych testów. Po każdej zmianie firmware szybkie testy wracają w CI, a droższe są uruchamiane według ryzyka.

Typowe złudzenia#

• idealny GNSS ukrywa złą obsługę jakości i opóźnień;
• idealne aktuatory pozwalają regulatorowi wykonać nierealne polecenia;
• stały krok czasu nie ujawnia problemów schedulerów;
• jeden spokojny wiatr nie bada odporności;
• brak kolizji w świecie nie dowodzi obstacle avoidance;
• zgodność trajektorii nie dowodzi poprawnych stanów awaryjnych;
• działanie w SITL nie potwierdza pinów, zasilania ani EMC;
• działanie w HIL nie potwierdza aerodynamiki rzeczywistego płatowca.

Zarządzanie konfiguracją modelu#

Model jest artefaktem inżynierskim takim jak firmware. Ma właściciela, wersję, historię zmian, testy i opis zakresu ważności. Parametr bez źródła jest długiem: może pochodzić z pomiaru, datasheetu, identyfikacji albo świadomego założenia, ale musi to być zapisane.

Zmiana modelu nie może po cichu zmienić wyniku regresji. Review powinien pokazać wpływ na scenariusze referencyjne. Jeżeli nowa aerodynamika ujawnia błąd autopilota, nie „naprawia się” modelu, aby odzyskać zielony test; rozstrzyga się różnicę z danymi fizycznymi.

Modele wielu płatowców dzielą komponenty sensorów i środowiska, lecz masa, bezwładność, geometria i napęd pozostają własnością wariantu. Nazwa x500 nie wystarcza, gdy docelowa platforma ma inny payload.

Coverage scenariuszy#

Pokrycie kodu mówi, które instrukcje wykonano, ale nie czy zbadano przestrzeń stanów. Dla autopilota tworzy się macierz: tryb lotu × faza misji × źródło nawigacji × awaria × stan energii. Nie wszystkie kombinacje mają sens; odrzucenie także jest udokumentowane.

Szczególną uwagę dostają przejścia: uzbrojenie, start, zmiana trybu, odzyskanie sensora, utrata łącza, lądowanie i restart komponentu. Błędy najczęściej występują między stabilnymi stanami. Test powinien sprawdzać stan pośredni, nie tylko końcową pozycję.

Mutation testing automatów polega na kontrolowanej zmianie warunku i sprawdzeniu, czy test ją wykryje. Jeżeli odwrócenie krytycznego porównania nadal daje zielony wynik, scenariusz nie dowodzi wymagania.

Kryteria gotowości do HIL i lotu#

Do HIL przechodzi się, gdy SITL jest deterministyczny, wszystkie krytyczne wymagania mają asercje, a model ma udokumentowaną walidację w potrzebnym zakresie. Do lotu przechodzi się po potwierdzeniu deadline na sprzęcie, stanów bezpiecznych wyjść, sensorów fizycznych i zasilania.

Raport wymienia także luki: zjawiska niemodelowane, niepewne parametry i scenariusze odłożone. Jawna granica dowodu jest wynikiem testu, nie wadą dokumentu. Pozwala zaprojektować krótszy, bezpieczniejszy eksperyment fizyczny dla dokładnie tych niewiadomych.

Powiązane tematy#

• PID w kontrolerze lotu
• ArduPilot — architektura i start
• PX4 — architektura i start
• GNSS w UAV
• Diagnostyka drgań

Przypisy#

1. ArduPilot, SITL Simulator — uruchamianie i architektura SITL.
2. ArduPilot, Simulation Parameters — modele i wstrzykiwanie stanów w symulacji.
3. ArduPilot, Using SITL for ArduPilot Testing — automatyzacja i AutoTest.
4. PX4, Simulation — wspierane symulatory i granice integracji.
5. PX4, Gazebo Simulation — budowanie i uruchamianie modeli Gazebo.
6. PX4, Hardware in the Loop Simulation — konfiguracja HIL i ograniczenia stanowiska.
7. NASA, NASA Systems Engineering Handbook, rozdziały dotyczące verification and validation — rozróżnienie weryfikacji, walidacji i budowania dowodów testowych.

Powiązane tematy

ArduPilot — architektura i ścieżka startowaMapa stosu ArduPilot dla programisty: od uruchomienia SITL i parametrów przez bibliotekę AP_HAL po analizę logów i test zmian.PX4 — architektura i ścieżka startowaJak czytać i rozszerzać PX4: przepływ sensor–estimator–controller–actuator, komunikacja uORB i wybór między taskiem a work queue.Flight controller — jak działaPrzekrojowa techniczna anatomia kontrolera lotu: sprzęt, domeny czasu, sensory, estymacja stanu, regulatory kaskadowe, alokacja sterowania, wyjścia, zasilanie, odporność na awarie, logowanie i uruchomienie platformy.

Źródła z centralnego rejestru

1. ArduPilot: Using Simulation Parameters to Control the Simulation [dokumentacja]
2. PX4 Simulation [dokumentacja]