Seminar Avionic Devices

Transkript

1 Seminar Avionic Devices IMA + ARINC653 Version: 1.0 Document Id: IMA-ARINC653 Datum: Author: Martin Wißmiller

2 1. Einführung 2 / Einführung Integrated Modular Avionics (IMA) und ARINC653 sind zwei entscheidende Entwicklungen im Bereich Avionik. Sie zielen darauf ab, durch Integration mehrerer Avionik-Komponenten den Entwicklungsaufwand und damit auch die Kosten zu reduzieren, Gewicht und Energieverbrauch zu sparen und gleichzeitig die Zuverlässigkeit zu erhöhen. Diese Entwicklungen sollen in dieser Ausarbeitung zu dem Seminarvortrag näher betrachtet werden. Inhaltsverzeichnis 1. Einführung IMA Traditioneller Ansatz IMA-Ansatz IMA-Generationen IMA erster Generation IMA zweiter Generation IMA dritter Generation Weitere Entwicklung ARINC ARINC653-Ansatz Space Partitioning Time Partitioning (Scheduling) APEX-Interface Vor- und Nachteile Fazit Literatur...12

3 2. IMA 3 / IMA 2.1. Traditioneller Ansatz Der traditionelle Ansatz bei Avionik-Komponenten war bisher, für jedes Gerät eine neue Komponente zu entwickeln. Dies ist durchaus sinnvoll, da inbesondere bei höchstkritischen Systemen die größtmögliche Zuverlässigkeit erwartet wird. Eine Möglichkeit um dieses Ziel zu erreichen ist ein möglichst einfacher Aufbau dieser Komponenten. Um die Leistung und die Sicherheit des Gesamtsystems Flugzeug oder Satellit zu erhöhen, wurden in den letzten Jahre immer mehr Avionik-Komponenten eingesetzt: Autopilot, GPS oder gar die Möglichkeit, aerodynamisch instabile Flugzeuge zu bauen und die Stabilität von Avionik-Komponenten regeln zu lassen. Doch die technische Entwicklung von Hard- und Software geht immer weiter, die Zuverlässigkeit selbst von komplexen Systemen ist heute deutlich höher als noch zu Beginn der Entwicklung. Traditioneller Ansatz: Jede Funktion wird von einem eigenen Gerät (mit eigener PSU) bereitgestellt

4 2. IMA 4 / IMA-Ansatz Ab etwa 1995 wurden sogar Integrated Modular Avionics (IMA) verwendet. Der Ansatz kann als Reaktion auf den Wildwuchs an Avionik-Komponenten betrachtet werden; in moderne Flugzeuge können mehreren hundert verschiedene Avionik- Komponenten vorhanden sein. Der IMA-Ansatz war es zunächst, die Komponenten auf Platinen zu implementieren, die in sogenannte IMA-Cabinets gesteckt wurden. Statt mehrere Power Supply Units (PSU) gibt es nur noch eine gemeinsame (bzw. mehrere redundante) PSU für alle Komponenten. Daraus ergeben sich mehrere Vorteile: Kleineres Gesamtvolumen Gewichtseinsparung Reduzierter Energieverbrauch Höhere Zuverlässigkeit Allerdings kann man auch einige Nachteile identifizieren: Schon vorhandene Geräte müssen neu entwickelt werden Abhängigkeit von nur einem Supplier (zumindest anfangs) Des weiteren stellt sich die Frage, welcher Bus-Standard verwendet wird Wichtige für die Luftfahrtindustrie relevante IMA-Standards sind: ARINC650 und ARINC651 RTCA DO-297: Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations

5 2. IMA 5 / IMA-Generationen IMA können in drei Generationen unterteilt werden IMA erster Generation Die IMA erster Generation stellen noch relativ einfache Implementierungen dar. Sie wurden als erstes 1995 in einer Boeing 777 eingesetzt. Sie können auf folgende Eigenschaften reduziert werden: Alle Module von einem Zulieferer Proprietäre, parallele Backplane Geschlossene Architektur Eine bzw. mehrere redundante PSUs für alle Module Als Beispiel soll hier das in der Boeing 777 eingesetzte AIMS von Honeywell dienen. Dieses IMA-Cabinet enthält das Flight-Management, Displays, Navigation, Flight- Deck-Communication, Thrust Management, Digital Flight Data, Engine Data interface und data conversion gateway. Screenshot von: 53-DF33-A457-6A98-3A9B478A5B22_H8426DF45-840B-4A22-F B234C9195.htm

6 2. IMA 6 / IMA zweiter Generation Die erste IMA zweiter Generation wurde ebenfalls 1995 in einer Boeing 777 eingesetzt. In dieser Generation waren die Backplanes teilweise schon standardisiert, teilweise war die Architektur offen und manche Backplanes waren seriell. Durch die Offenheit konnten auch Module verschiedener Hersteller eingesetzt werden IMA dritter Generation Bei IMA dritter Generation sind Backplanes und die Module standardisiert, die Architektur ist offen. Die PSUs können auch nur einzelne Module versorgen. Eine weitere, entscheidende Neuerung war die Standardisierung von Software- Schnittstellen. IMA dritter Generation wurde zum ersten Mal 2005 in einem Airbus A380 eingesetzt Weitere Entwicklung Mit fortschreitender Entwicklung wurde die Entwicklung von Geräten mit höherer Leistung immer komplexer, was letztlich zu stark steigenden Kosten führte. Parallel dazu wurde Standard-Hardware immer leistungsfähiger, zuverlässiger, günstiger und energieeffizienter. Daraus entstand die Idee, mehrere Applikationen auf derselben Hardware laufen zu lassen. Die Entwicklung der Hardware und der Software wurden voneinander getrennt. Dies wiederum eröffnete die Möglichkeit, verstärkt auf Customer-Off-The- Shelf (COTS)-Lösungen zu setzen - also auf Hard- und Software-Lösungen, die bereits (halb-)fertig auf dem Markt erhältlich sind und auch nicht zwangsweise speziell für die Luftfahrtindustrie entwickelt wurden.

7 3. ARINC653 7 / ARINC ARINC653-Ansatz Der ARINC653-Standard greift genau diese Entwicklung auf. ARINC653 spezifiziert ein allgemeines Application Programming Interface (API). Mehrere Applikationen können nun auf dem selben Gerät ausgeführt werden. Die Applikationen laufen dabei innerhalb von Partitionen. Dadurch sind sie um den hohen Anforderungen an die Kritikaltität gerecht zu werden komplett voneinander abgeschottet. Möglich aber unüblich ist es auch, mehrere Applikationen in einer Partition auszuführen oder auch Applikationen auf mehrere Geräte zu verteilen. ARINC653 wird als Embedded-Betriebssystem von mehreren Herstellern angeboten, meist auf Basis ihrer Standard-Embedded-Betriebssystemen. Bekannte Beispiele hierfür sind Windriver VxWorks 653, Sysgo PikeOS und Lyunxworks LynxOS. Hauptmerkmale von ARINC653 sind: Time- und Space-Partitioning Virtuelle Speicheradressierung Scheduling Applikationen werden komplett voneinander abgeschottet Standardisierte API: APEX (APplication Executive) Kommunikation innerhalb und zwischen den Partitionen nur über APEX möglich Health Monitoring

8 3. ARINC653 8 / Space Partitioning Space Partitioning (Virtualiserung) schottet eine Partition vom restlichen System komplett. Eine Applikation innerhalb einer Partition hat keine Möglichkeit, auf den Rest des Systemes zuzugreifen lediglich über das APEX-Interface kann kommuniziert werden. Die Partitionen haben alle ihrere eigene Speicheradressierung, wodurch Partitionen auch relativ leicht auf andere Hardware migriert werden kann. Wert wird dabei auf robuste Partitionierung gelegt. Der IMA-Standard DO-297 versteht darunter: 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)). Beispielhafter Aufbau eines VxWorks 653 Systems Das CoreOS ist dabei das eigentliche Betriebssystem, das auf der Hardware läuft. Innerhalb der Partitionen läuft ein separates Betriebssystem (PartitionOS). Die Namen CoreOS und PartitionOS sind VxWorks653-spezifisch, der Aufbau bei anderen ARINC653-Implementierungen ist analog mit evtl. anderen Namen. Die Applikationen innerhalb der Partition sind wie schon erwähnt voneinander unabhängig, es können sogar unterschiedliche Programmiersprachen verwendet werden - gängig sind jedoch C und Ada95. Letztlich dient Space-Partitioning dazu, Fehler zu isolieren. Ein Fehler innerhalb einer Partition kann keine Auswirkung auf eine andere Partition haben. Desweiteren ermöglicht dieses Konzept auch Partitionen einzeln zu zertifizieren.

9 3. ARINC653 9 / Time Partitioning (Scheduling) Bedingt durch die Partitionierung gibt es von außen betrachtet zwei Scheduling- Mechanismen: Einen statischen Zeitplan für die zeitliche Ausführung der Partitionen Einen beliebigen Scheduling-Mechanismus für Prozesse(Tasks) innerhalb der Partitionen diese können theoretisch auch unterschiedlich sein, sind in der Praxis aber meist die selben. Folgendes Bild verdeutlicht das Scheduling am Beispiel eines typischen ARINC653- Systems: Für jede Partition wird definiert, wie lange und wann diese aktiv ist (statischer, präemptiver Zeitplan). Die Aktivitätszeit einer Partition stellt ein sogenanntes Minor Frame dar, aus der Summe der Laufzeiten der Minor Frames ergibt sich ein Major Frame. Innerhalb einer Partition definiert die Applikationen ihre eigenen Prozesse. Prozesse sind eigentlich Tasks, im ARINC653-Kontext werden Tasks aber Prozesse genannt, obwohl sie innerhalb der Partition auch auf Speicherbereiche anderer Prozesse zugreifen können. Grund dafür sind mögliche Verwechslungen mit Ada- Tasks. Für jeden Prozess innerhalb der Partition wird eine Frequenz (z.b. 50Hz = 20ms) sowie eine Priorität definiert. Im Beispiel wird ein präemtives Rate Monotonic Scheduling verwendet. Das Major-Frame wird endlos wiederholt. Die Minor-Frames werden ausgeführt wie im statischen Zeitplan definiert, unabhängig davon ob die Prozesse darin schon beendet sind - ein nicht beendeter Prozess kann frühestens bei der nächsten Aktivität des Minor-Frames fortgesetzt werden.

10 3. ARINC / APEX-Interface Das APEX-Interface stellt die einzige Schnittstelle für eine Applikation nach außen dar. Die Spezifikation ist unabhängig von Plattform und Programmiersprache, gängige Implementierungen sind in C und Ada95. APEX stellt unter anderem folgende Services zur Verfügung: - Prozessmanagement (CREATE_PROCESS, PERIODIC_WAIT, SET_PRIORITY,...) - Kommunikation (CREATE_SAMPLING_PORT, WRITE_QUEUING_MESSAGE,...) - Semaphore (WAIT_SEMAPHORE, SIGNAL_SEMAPHORE,...) - Health Monitoring - Partition Management Beispiel für ein ARINC653-System mit Queuing Ports:

11 3. ARINC / Vor- und Nachteile ARINC653 hat einige Vorteile, man kann jedoch auch einige Nachteile ausmachen. Als wichtigste Vorteile sind zu nennen: Modularität Durch das APEX-Interface werden 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 Als Nachteile sind zu nennen: 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 z.b. 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 Als Folge dieser Nachteile werden indeterminischte HW-Features oft abgeschaltet. Das wiederum schränkt die theoretische Leistungsfähigkeit der HW stark ein das Abschalten der Caches einer CPU auf etwa ein Zehntel. Der tatsächliche Entwicklungsaufwand ist außerdem schwer einschätzbar, statt mehrerer kleiner Geräte wird ein großes entwickelt. Oft ergeben sich erst bei der Entwicklung oder der Verfikation Probleme, die vorher nicht absehbar waren.

12 4. Fazit 12 / Fazit IMA bzw. ARINC653 Systeme werden schon in allen modernen Flugzeugen eingesetzt, ein großer Teil der Avionik läuft auf solchen Geräten. IMA scheint sich hierbei schon durchgesetzt zu haben, ARINC653 Systeme sind derzeit größtenteils noch in der Entwicklung. Es besteht aber kein Zweifel, dass diese auch in den nächsten Jahren eine große Rolle in der Entwicklung von Avionik-Geräten spielen werden. Die Vorteile wiegen die weiter oben dargelegten Nachteile offenbar aus Sicht der Hersteller auf. 5. Literatur Civil Avionics Systems, Ian Moir, Verlag Wiley-Blackwell, ISBN-13: RTCA DO-297 "Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations", RTCA, 2005 RCTA DO-178B "Software Considerations in Airborne Systems and Equipment Certification", RTCA, 1992 ARINC653 "Avionics Application Software Standard Interface", ARINC, 1997