Zakres
1.1 Ogólny zakres
W niniejszej Normie Europejskiej ustalono jednolite wymagania dotyczące projektowania i rozwoju architektury oprogramowania dla modułowych systemów awioniki.
1.2 Przegląd architektury oprogramowania
Architektura oprogramowania MOAA jest oparta na trójwarstwowym stosie jak w sposób uproszczony pokazano na Rysunku 2.
Rysunek 2 – Trójwarstwowa architektura oprogramowania MOAA
Każda warstwa jest opisana pod względem zależności/niezależności zarówno od systemu statku powietrznego jak i od sprzętu bazowego.
Tablica 1 – Niezależność Warstwy Oprogramowania
1.3 Komponenty architektoniczne oprogramowania
1.3.1 Postanowienia ogólne
Na Rysunku 3 przedstawiono przegląd komponentów architektonicznych oprogramowania i interfejsów oprogramowania.
Rysunek 3 – Model architektury oprogramowania
1.3.2 Aplikacje funkcjonalne
Termin „Aplikacje funkcjonalne” odnosi się do wszystkich funkcji , które obsługują przetwarzanie danych operacyjnych , np.
– Aplikacje radarowe,
– Zarządzanie misją,
– Zarządzanie magazynem,
– System zarządzania pojazdem,
– Komunikacja, nawigacja i identyfikacja
1.3.3 Zarządzanie aplikacją (AM)
AM jest odpowiedzialne za nieznormalizowane zarządzanie systemem, tzn. AM realizuje nieuniwersalne zarządzanie systemem. Jako przykład, AM może realizować zarządzanie misją/modingiem. Interfejs między AM i GSM jest Interfejsem Logicznym Zarządzaniem Systemem (SMLI) (patrz 4.1.3).
1.3.4 System operacyjny (OS)
OS czasu rzeczywistego zapewnia część funkcjonalności OSL, która steruje zachowanie w czasie rzeczywistym elementu przetwarzającego i związanych z nim zasobów (patrz 5.2.2).
1.3.5 Uniwersalny system zarządzania (GSM)
GSM jest odpowiedzialne za zarządzanie przetwarzaniem rdzeniowym (patrz 4.1.2 i 5.2.1). Funkcjonalność ta jest podzielona na cztery obszary:
– Monitorowanie zdrowia,
– Zarządzanie błędami,
– Zarządzanie konfiguracją,
– Zarządzanie bezpieczeństwem.
1.3.6 Czas przetwarzania Blueprints (RTBP)
RTBP zawiera informacje (np. opis procesu, informacje rutynowe, dane dotyczące zarządzanie błędem) wymagane do konfiguracji i zarządzania przetwarzania rdzeniowego na serwerze, na którym jest zainstalowany.
1.3.7 Warstwa modułu wsparcia (MSL)
MSL obejmuje szczegóły podstawowego sprzętu i podaje ogólny, technologiczny niezależny dostęp do zasobów na niskim poziomie (patrz 5.1).
1.3.8 Aplikacja do interfejsu OS (APOS)
APOS jest bezpośrednim interfejsem, który oddziela oprogramowanie zależne od statku powietrznego (AL) od oprogramowanie niezależnego od statku powietrznego (OSL). Jego celem jest zapewnienie procesów w AL ze znormalizowanym niezależnym interfejsem OS do tych usług zapewnianych przez OS, promując w ten sposób przenośność i ponowne użycie oprogramowania (patrz 6.1).
1.3.9 Moduł Wsparcia do interfejsu OS (MOS)
MOS jest bezpośrednim interfejsem, który oddziela OSL od oprogramowania zależnego od sprzętu (MSL). Jego celem jest zapewnienie OS ze sprzętem niezależnym/przezroczystym technologicznie interfejsem do funkcjonalności zawartej w MSL. MOS umożliwia zatem takiemu samemu oprogramowaniu OSL rezydować na różnych implementacjach CFM, niezależnie od podstawowego sprzętu (patrz 6.2).
1.3.10 Zarządzanie systemem do interfejsu Blueprints (SMBP)
Bezpośredni interfejs, zamknięty w OSL między GSM i Blueprints, umożliwia strukturze i implementacji Blueprints pozostać nieznormalizowanej, jednocześnie definiując dla nich standardowy interfejs (patrz 6.2.3).
1.3.11 Zarządzanie systemem do interfejsu OS (SMOS)
Bezpośredni interfejs, zamknięty w OSL, opisuje usługi zapewniane przez OS świadczone GSM (patrz 6.3).
1.3.12 Interfejs logiczny OS (OLI)
OLI opisuje wzajemną komunikację między dwoma egzemplarzami OS zależnie od kanału wirtualnej komunikacji (VC) i prezentacji danych (patrz 7.1).
...
