ARINK 653

ARINC 653 (Avionics Application Software Standard Interface) to specyfikacja oprogramowania do partycjonowania przestrzeni i czasu w systemach operacyjnych czasu rzeczywistego (RTOS) awioniki o krytycznym znaczeniu dla bezpieczeństwa . Umożliwia hostowanie wielu aplikacji o różnych poziomach oprogramowania na tym samym sprzęcie w kontekście architektury zintegrowanej modułowej awioniki .

Jest częścią ARINC 600-Series Standards for Digital Aircraft & Flight Simulators.

Przegląd

Aby oddzielić platformę systemu operacyjnego czasu rzeczywistego od aplikacji, ARINC 653 definiuje API o nazwie APplication EXecutive (APEX).

Każda aplikacja jest nazywana partycją i ma własną przestrzeń pamięci. Posiada również dedykowany przedział czasowy przydzielony przez API APEX. W ramach każdej partycji dozwolona jest wielozadaniowość . Interfejs API APEX zapewnia usługi zarządzania partycjami, procesami i taktowaniem, a także komunikacją między partycjami a procesami oraz obsługą błędów. Środowisko partycjonowania można zaimplementować za pomocą hiperwizora do mapowania partycji na maszyny wirtualne, ale nie jest to wymagane.

Norma jest nadzorowana przez Podkomitet AEEC APEX [1] .

Historia

Początkowa wersja

Wstępna wersja ARINC 653 została opublikowana 10 października 1996 r.

ARINC 653-1

Dodatek 1 został opublikowany w styczniu 1997 r. i wprowadził koncepcje partycjonowania APEX oraz czasu i przestrzeni.

ARINC 653-2

Suplement 2 został opublikowany w 3 częściach między marcem 2006 a styczniem 2007:

  • Część 1 (usługi obowiązkowe): zarządzanie partycjami ARINC 653, definiowanie zimnego i ciepłego startu, obsługa błędów aplikacji, zgodność z ARINC 653, powiązania języków Ada i C ;
  • Część 2 (usługi opcjonalne): Dostęp do systemu plików , Rejestracja danych , Punkty dostępu do usług, ...
  • Część 3 (Specyfikacja badania zgodności);

Obecna organizacja normy

  • Część 0 - Wprowadzenie do ARINC 653 (obecnie w wersji 3, wydanej w listopadzie 2021 r.)
  • Część 1 — Wymagane usługi (obecnie w wersji 5, wydanej w grudniu 2019 r.)
  • Część 2 — Usługi rozszerzone (obecnie w wersji 4, wydanej w grudniu 2019 r.)
  • Część 3A — Specyfikacja testu zgodności dla wymaganych usług (obecnie w wersji 2, opublikowana w listopadzie 2021 r.)
  • Część 3B — Specyfikacja testu zgodności dla usług rozszerzonych (obecnie wersja c1, opublikowana w lipcu 2019 r.)
  • Część 4 — Usługi podzbioru (obecnie w wersji 0, wydanej w czerwcu 2012 r.)
  • Część 5 — Zalecane możliwości podstawowego oprogramowania (obecnie w wersji 1, wydanej w sierpniu 2019 r.)


Podstawowe zasady partycjonowania

Platforma ARINC 653

Platforma ARINC 653 zawiera:

Inicjalizacja

Inicjalizacja partycji ARINC 653 tworzy zasoby używane przez partycję. Tworzenie zasobów (PROCESS, EVENT, SEMAPHORE...) odbywa się poprzez wywołanie usług API o nazwie CREATE_xxxx .

Obsługa błędów

Procedura obsługi błędów procesowych jest procesem wywłaszczającym o najwyższym priorytecie, przeznaczonym do obsługi wyjątków partycji. Jest tworzony przez usługę CREATE_ERROR_HANDLER podczas inicjalizacji partycji.

Interfejs API umożliwia obsłudze błędów zatrzymanie wadliwego procesu ( STOP_SELF ). W takim przypadku harmonogram RTOS wywoła następny proces o najwyższym priorytecie.

ARINC 653 nie określa, jak program planujący powinien się zachowywać, jeśli program obsługi błędów nie zatrzymuje wadliwego procesu. W niektórych (teoretycznych) przypadkach może to prowadzić do nieskończonej pętli między wadliwym procesem a procedurą obsługi błędów.

Program obsługi błędów może uzyskać informacje o źródle i kontekście wyjątku.

Zarządzanie trybami

Każda partycja może znajdować się w kilku trybach aktywacji:

  • COLD_START i WARM_START: Wykonywany jest tylko proces inicjalizacji,
  • NORMAL: Proces inicjalizacji zostaje zatrzymany, a inne procesy partycji są wywoływane przez program planujący RTOS w zależności od ich priorytetu,
  • BEZCZYNNY: Żaden proces nie jest wykonywany. Jednak implementacja mogłaby teoretycznie wykonać ukryty proces o najniższym priorytecie, na przykład w celu uruchomienia nieskończonej pętli.

Usługa SET_PARTITION_MODE umożliwia zarządzanie tymi stanami. Może być wywołany przez dowolny proces w partycji. Wejście w stan IDLE jest dla partycji nieodwracalne. Tylko zdarzenie zewnętrzne (takie jak ponowne uruchomienie platformy) może zmienić stan na inny tryb, gdy partycja jest w tym stanie.

Planowanie partycji i procesów

Norma definiuje dwupoziomowy harmonogram hierarchiczny. Pierwszy poziom planuje partycje. Jest to stały harmonogram okrężny, który powtarza główne ramy czasowe. Główne ramy czasowe planują każdą partycję w mniejszych ramach czasowych o ustalonym czasie trwania ze stałym przesunięciem od początku głównych ram czasowych.

Harmonogram partycji ARINC 653

W mniejszych ramach czasowych drugi poziom wykorzystuje planowanie procesów. Każda partycja ma co najmniej jeden proces . Planowanie procesów w mniejszych ramach czasowych jest zapobiegawcze . Harmonogram jest wywoływany przez timer lub przez usługi API.

Wielordzeniowy

ARINC 653 P1-5 został zaktualizowany w celu uwzględnienia architektur procesorów wielordzeniowych . Sekcja 4.2.1 „Zgodność implementacji wielordzeniowej systemu operacyjnego” wskazuje, że system operacyjny przeznaczony do przetwarzania wielordzeniowego powinien obsługiwać dwa przypadki:

  • Użycie wielu rdzeni przez pojedynczą partycję (której procesy obejmują wiele rdzeni)
  • Użycie wielu rdzeni przez wiele partycji

Stanowisko CAST-32A określa zestaw wymagań i wskazówek, które należy spełnić, aby certyfikować i używać wielordzeniowe procesory w lotnictwie cywilnym przez FAA i oczekuje się, że zostanie zastąpione okólnikiem doradczym, AC 20-193. Urząd lotniczy Unii Europejskiej, EASA, opublikował AMC 20-193 w styczniu 2022 r.


usługi API

Usługi ARINC 653 APEX to wywołania API należące do sześciu kategorii:

  • Zarządzanie partycjami
  • Zarządzanie procesem
  • Zarządzanie czasem
  • Komunikacja między partycjami
  • Komunikacja wewnątrz partycji
  • Obsługa błędów

Żadne usługi ARINC 653 nie są dostępne do zarządzania pamięcią partycji. Każda partycja musi obsługiwać własną pamięć (wciąż podlega ograniczeniom partycjonowania pamięci narzuconym przez ARINC 653).

Każda usługa zwraca wartość RETURN_CODE, która wskazuje, czy wywołanie powiodło się:

  • NO_ERROR: usługa wykonana nominalnie po prawidłowym żądaniu
  • NO_ACTION: stan systemu nie zmienił się po wykonaniu usługi
  • NOT_AVAILABLE: usługa jest chwilowo niedostępna
  • INVALID_PARAM: co najmniej jeden z parametrów usługi jest nieprawidłowy
  • INVALID_CONFIG: co najmniej jeden z parametrów usługi jest niezgodny z aktualną konfiguracją systemu
  • INVALID_MODE: usługa jest niekompatybilna z bieżącym trybem systemu
  • TIMED_OUT: upłynął czas oczekiwania na wykonanie usługi

Linki do POSIX i ASAAC

Pole objęte ARINC 653 jest podobne do ASAAC Def Stan 00-74 . Istnieją jednak różnice między tymi dwoma standardami.

Niektóre wywołania ARINC 653 (APEX) mają odpowiedniki POSIX , ale różnią się od tego, jak są zdefiniowane w POSIX.

Na przykład następujące wywołanie zdefiniowane w ASAAC:

Odbierz Bufor

zostanie przetłumaczony w ARINC 653 przez:

RECEIVE_BUFFER()

a także w POSIX przez:

recv()

Zobacz też

Pobrano z „ https://en.wikipedia.org/w/index.php?title=ARINC_653&oldid=1128886172 ”