Integrated Modular Avionics & ARINC 653

Größe: px

Ab Seite anzeigen:

Download "Integrated Modular Avionics & ARINC 653"

Kristian Bieber
vor 9 Jahren
Abrufe

1 Integrated Modular Avionics & ARINC 653 Martin Wißmiller

2 Gliederung IMA - Traditioneller Ansatz - IMA-Ansatz - IMA-Generationen ARINC653 - Speicherpartitionierung - Zeitpartitionierung - Kommunikation - APEX

3 Traditioneller Ansatz Verschiedene einzelne Avionikgeräte

4 IMA (Integrated Modular Avionics) Vorteile: - Kleineres Gesamtvolumen - Gewichtseinsparung - Reduzierter Energieverbrauch - Höhere Zuverlässigkeit

5 IMA (Integrated Modular Avionics) Nachteile: - Geräte müssen neu entwickelt werden - Anfangs Abhängigkeit von einem Zulieferer - Möglicherweise gegenseitige elektromagnetische Störung der einzelnen Module - Frage nach einem Bus-Standard

einem Zulieferer - Möglicherweise gegenseitige

6 IMA Erste Generation Honeywell AIMS (Einsatz in Boeing 777) - Relativ einfache Implementierung - Alle Module von einem Zulieferer - Proprietäre, parallele Backplane - Geschlossene Architektur - Eine oder mehrere PSUs für alle Module Einsatz ab 1995 (Boeing 777)

mehrere PSUs für alle Module Einsatz ab 1995 (Boeing 777) http://www.honeywell.

7 IMA Erste Generation Honeywell AIMS (Einsatz in Boeing 777) - Flight Management - Displays - Navigation - Flight Deck Communication - Thrust management - Digital flight data - Engine data interface - Data conversion gateway

data interface - Data conversion gateway http://www.honeywell.

8 IMA Zweite & Dritte Generation Zweite Generation: - Backplanes teilweise standardisiert - Module von mehreren Herstellern - Teilweise offene Architektur - Teilweise serielle Backplane ab ca (Boeing 777) Dritte Generation: - Standardisierte, serielle Backplane - Standardisierte Module verschiedener Hersteller - Offene Architektur - PSUs auch nur für einzelne Module - Einführung von Standard-Softwareschnittstellen ab ca (Airbus A380) IMA-Standards: - ARINC650 & ARINC651 - RCTA DO-297 "Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations"

1995 (Boeing 777) Dritte Generation: - Standardisierte, serielle Backplane - Standardisierte Module verschiedener Hersteller - Offene Architektur

9 IMA - Weitere Entwicklung - Entwicklung von Geräten mit höherer Leistung wird immer komplexer steigende Kosten - Hardware wird - leistungsfähiger - zuverlässiger - günstiger - verbraucht weniger Energie Versuch, - Mehrere Applikationen auf derselben HW laufen zu lassen - Entwicklung von SW und HW komplett zu trennen - soweit wie möglich auf Customer-Off-The-Shelf (COTS)-Lösungen Zurückzugreifen (insbesondere bei HW)

Versuch, - Mehrere Applikationen auf derselben HW laufen zu lassen - Entwicklung von SW und HW komplett

10 ARINC653 - Mehrere Applikationen auf einem Gerät - Applikationen werden in Partitionen voneinander abgeschottet - Möglich aber unüblich: - Mehrere Applikationen in einer Partition - Applikationen verteilt auf mehrere Geräte

abgeschottet - Möglich aber unüblich: - Mehrere

11 ARINC653 - Time und Space-Partitioning (Virtualisierung) Virtuelle Speicheradressierung Scheduling Applikationen werden komplett voneinander abgeschottet - Standardisierte API: APEX (Application Executive) Abstraktion von der HW - Kommunikation innerhalb und zwischen den Partitionen - Health Monitoring Verschiedene Hersteller bieten ARINC653-Implementierungen auf Basis ihrer Embedded-Betriebssysteme an z.b. Windriver VxWorks 653, Sysgo PikeOS, Lyunxworks LynxOS, etc.

Kommunikation innerhalb und zwischen den Partitionen - Health Monitoring Verschiedene Hersteller bieten

12 ARINC653 - Partitionierung Aus DO-178B: "Partitioning is a technique for providing isolation between functionally independent software components to contain and/or isolate faults and potentially reduce the effort of the software verification process. Aus DO-297: The objective of robust partitioning is to provide an equivalent level of functional isolation and independence as a federated system implementation(i.e., applications individually residing on separate Line Replaceable Units (LRU)). isoliert Fehler Zertifizierung von einzelnen Partitionen möglich Reduzierter Aufwand bei Verifikation und Zertifizierung

Aus DO-297: The objective of robust partitioning is to provide an equivalent level of functional isolation and independence as a federated system

13 ARINC653 - Speicher-Partitionierung

14 ARINC653 - Scheduling Beispiel für ARINC653-Scheduling mit Rate Monotonic Scheduling innerhalb der Partitionen 1. Für jede Partition wird definiert, wie lange diese aktiv ist statischer Zeitplan Aus der Summe der Laufzeiten der Partitionen ergibt sich ein Major Frame 2. Die Applikationen definieren ihre eigenen Prozesse (eigentlich Tasks, im ARINC653-Kontext werden Tasks aber Prozesse genannt, obwohl sie innerhalb der Partition auch auf Speicherbereiche anderer Prozesse zugreifen können). Für jeden Prozess innerhalb der Partition wird eine Frequenz (z.b. 50Hz = 20ms) sowie eine Priorität definiert Rate Monotonic Scheduling (präemptiv) Betrachtet man das Gesamtsystem von außen, hat man ein doppeltes Scheduling

Die Applikationen definieren ihre eigenen Prozesse (eigentlich Tasks, im ARINC653-Kontext werden Tasks aber Prozesse genannt, obwohl sie innerhalb der Partition auch auf

15 ARINC653 - Kommunikation Jede Kommunikation mit anderen Partitionen erfolgt über die APEX-Schnittstelle!

16 ARINC653 APEX (Application Executive) APEX-Spezifikation ist Programmiersprachenunabhängig Gängige Implementierungen in C und Ada Services: - Prozesse (CREATE_PROCESS, PERIODIC_WAIT, SET_PRIORITY,...) - Kommunikation (CREATE_SAMPLING_PORT, WRITE_QUEUING_MESSAGE,...) - Semaphore (WAIT_SEMAPHORE, SIGNAL_SEMAPHORE,...) - Health Monitoring - Partition Management

(CREATE_PROCESS, PERIODIC_WAIT, SET_PRIORITY,.

17 ARINC653 - Vorteile Modularität Durch das APEX-Interface wird SW und HW abstrahiert Portabilität und Wiederverwendbarkeit Eine Applikation kann relativ einfach auf eine andere Hardware portiert werden Applikationen mit unterschiedlicher Kritikalität auf einem Gerät Eine Applikation ist nach außen hin isoliert und kann andere Applikationen auf dem selben Gerät nicht beeinflussen

Hardware portiert werden Applikationen mit unterschiedlicher Kritikalität auf einem Gerät Eine

18 ARINC653 - Nachteile - Ein hochkomplexes Avionik-Gerät statt mehrerer einfacher Geräte - Verwendung von leistungsfähiger, aber komplexer Hardware - Zusätzliche Softwareschicht durch ARINC653 Betriebssystem - Mikroprozessoren erreichen ihre hohe Leistung meist durch komplexe Features wie Caches, Out-of-Order Execution und Multi-Pipelining, die eigentlich nicht für den Einsatz in sicherheitskritischen eingebetteten Systemen entwickelt (inbesondere indeterminische Features wie Caches mit Random- Replacement-Strategien) Hoher Aufwand bei der Zertifizierung, insbesondere bei hochkritischen Applikationen Statische Analysetools (zur Zertifizierung bei hochkritischen Geräten vorgeschrieben) haben Probleme mit komplexer HW und SW Abschaltung indeterministischer HW-Features Tatsächlicher Entwicklungsaufwand schwer einschätzbar, Probleme werden oft erst in der Entwicklung oder Verifikation erkannt

sicherheitskritischen eingebetteten Systemen entwickelt (inbesondere indeterminische Features wie Caches mit Random- Replacement-Strategien) Hoher Aufwand bei der Zertifizierung, insbesondere bei

19 IMA / ARINC653 Heutige Verwendung IMA bei allen modernen Flugzeugen im Einsatz, Anzahl der IMA-Anwendung steigend. ARINC653-Anwendungen größtenteils noch in der Entwicklung

20 IMA / ARINC653 Fazit - Entwicklung hin zu Avionik-Geräten mit mehreren Applikationen - IMA wird schon in vielen Flugzeugen eingesetzt offenbar wiegen die Vorteile die Nachteile auf

Ähnliche Dokumente

Seminar Avionic Devices

Seminar Avionic Devices IMA + ARINC653 Version: 1.0 Document Id: IMA-ARINC653 Datum: 05.03.2013 Author: Martin Wißmiller 1. Einführung 2 / 12 1. Einführung Integrated Modular Avionics (IMA) und ARINC653