CANaerospace

mini|Das Logo

CANaerospace ist ein auf Controller Area Network (CAN) aufsetzendes Protokoll für Steuerelektronik in der Luftfahrt und definiert zudem die Hardwareschnittstelle. Entworfen und entwickelt wurde es 1998 von Stock Flight Systemswww.stockflightsystems.com. Aufgrund seines Open-Source-Ansatzes kam CANaerospace zunächst sehr schnell in der Luftfahrtforschung zum Einsatz und nahm bezüglich CAN-basierten Systemen die weitere Entwicklung im Luftfahrtbereich in vielerlei Hinsicht vorweg (siehe auch ARINC 825).

Hintergrund der Entwicklung CANaerospace unterstützt das Konzept von Line Replaceable Units (LRU) und standardisiert die Kommunikation zwischen LRUs auf Systemebene beispielsweise durch definierte Hardwareschnittstellen, Netzwerkschichten, Sicherheitsmechanismen, Datentypen und Koordinatensystemdefinitionen. CANaerospace wird seither kontinuierlich weiterentwickelt, ist in der Luftfahrtindustrie weltweit verbreitet und wurde auch von der US National Aeronautics and Space Administration als NASA-Standard veröffentlicht. Ein maßgebliches Forschungsprojekt, in dem eine Vielzahl CANaerospace-vernetzter Systeme verwendet wird, ist das Stratospheric Observatory For Infrared Astronomy (SOFIA), eine Boeing 747SP mit einem 2,5-m-Spiegelteleskop für die Infrarot-Astronomie. Auch in der professionellen Flugsimulation konnte sich CANaerospace durchsetzen und wird für die Verbindung vollständiger Simulationscockpits wie das des Eurofighter Typhoon mit den zentralen Simulationsrechnern verwendet. In Italien wird CANaerospace bei UAVs eingesetztKurzübersicht CAN-basierter Avionik-Netzwerke auf www.avionics-networking.com, abgerufen am 9. Februar 2010.. Ferner dient CANaerospace als Kommunikationsnetzwerk verschiedener moderner integrierter Avioniksysteme für die Allgemeine Luftfahrt.

CANaerospace schließt die Lücke zwischen dem im CAN-Controller implementierten CAN-Protokoll und den besonderen Anforderungen verteilter Systeme in Luftfahrzeugen. Ein wesentliches Kriterium im Rahmen der Definition von CANaerospace war, eine kostengünstige Implementierung des Protokolls in intelligenten Integrated Modular Avionics (IMA)-Einheiten zu ermöglichen. Der Grund dafür ist, dass bei missions- oder flugsicherheitskritischen Systemen in Luftfahrzeugen deren vorhersagbare und korrekte Funktion nachgewiesen werden muss, was – neben anderen Anforderungen – auf der Entwicklungsebene die Erstellung qualitätsgesicherter Software erfordert. Die zur Sicherstellung der Qualität notwendigen und in den einschlägigen Zulassungsvorschriften (z. B. DO-178B) geforderten Vorgehensweisen unterscheiden sich zwar in ihrem Umfang hinsichtlich der möglichen Folgen beim Ausfall des betreffenden Systems; grundsätzlich steigt dieser Aufwand aber immer mindestens proportional mit dem Umfang des entsprechenden Softwarecodes. Da der Zeit- und Kostenaufwand für die Softwarequalitätssicherung insbesondere bei Systemen, die sehr hohen Zuverlässigkeitsansprüchen genügen müssen, extrem hoch werden kann, ist ein „schlankes“ Protokoll vor allem in diesen Fällen von entscheidendem Vorteil. Aber auch die – oft in einem Luftfahrzeug in großer Zahl verwendeten – kleineren Systeme mit geringeren Anforderungen profitieren davon.

Grundlegende Eigenschaften Die wesentlichen Eigenschaften von CANaerospace sind:

Demokratisches Netzwerk: In CANaerospace gibt es keinerlei vorgeschriebene „Master/Slave“-Beziehungen zwischen den Netzwerkteilnehmern. Jeder Busteilnehmer hat zu jedem Zeitpunkt grundsätzlich dieselben Rechte hinsichtlich der Teilnahme am Busverkehr. Durch das Fehlen eines „Bus Masters“ entfällt die damit verbundene potentiell singuläre Fehlerquelle im System.

Selbstidentifizierendes Nachrichtenformat: Jede CANaerospace-Nachricht enthält Informationen über den Typ der damit versendeten Daten sowie die Identifikation des Busteilnehmers, welcher die Nachricht gesendet hat. Dadurch lässt sich die Nachricht von jedem empfangenden Busteilnehmer eindeutig interpretieren.

Durchlaufende Nachrichtennumerierung: Jede CANaerospace-Nachricht enthält eine laufende Nummer, welche die kohärente Verarbeitung redundanter Daten seitens der empfangenden Busteilnehmern erlaubt.

Nachrichten-Statusinformation: CANaerospace-Nachrichten enthalten eine Information über die Integrität des Dateninhalts. Dadurch werden die empfangenden Busteilnehmer in die Lage versetzt, die Qualität der erhaltenen Daten zu beurteilen und entsprechend zu reagieren.

Signalisierung von Ausnahme- oder Fehlerzuständen: CANaerospace stellt einen Mechanismus zur Verfügung, der jedem Busteilnehmer das Signalisieren von Ausnahme- oder Fehlerzuständen durch entsprechende CAN-Nachrichten erlaubt.

Ansprechbarkeit ausgewählter Busteilnehmer: CANaerospace unterstützt den Austausch von Nachrichten zwischen bestimmten Busteilnehmern im Sinne einer allgemeinen Kommandoschnittstelle. Dieses dient beispielsweise der Überprüfung der Integrität von Netzwerk bzw. Busteilnehmern, dem Austausch von blockorientierten Nachrichten oder ähnlichen Operationen, welche Interaktionen zwischen zwei oder mehreren Busteilnehmern erfordern, ohne dass nicht betroffene daran teilnehmen.

Vordefinierte CAN-Identifierliste: CANaerospace bietet eine vordefinierte Standardverteilung von CAN-Identifiern für die operationellen Daten an, ähnlich dem in der Luftfahrt bekannten Mark 33 Digital Information Transfer Standard. Neben der Standardverteilung können auch vom Anwender definierte Listen verwendet werden.

Einfache Implementierung: Der Software-Aufwand für die Implementierung von CANaerospace ist äußerst gering. Dadurch wird der Test- und Zertifizierungsaufwand, insbesondere mit Hinblick auf komplexe missions- oder sicherheitskritische Systeme, minimiert.

Erweiterbarkeit: Alle Definitionen von CANaerospace sind vom Anwender erweiterbar, um eine möglichst große Flexibilität hinsichtlich zukünftiger Entwicklungen zu bieten.

Kostenlose Verfügbarkeit: Für die Verwendung des CANaerospace-Protokolls fallen keinerlei Kosten an. Die Spezifikation kann aus dem Internet heruntergeladen werdenDownloadseite auf www.stockflightsystems.com.

Netzwerkschichten Die CAN-Spezifikation sieht vor, dass versendete CAN-Nachrichten grundsätzlich von allen angeschlossenen Busteilnehmern empfangen werden, ein Kommunikationsprinzip, welches auch als „Anyone-to-Many“ (ATM) bezeichnet wird. Der Vorteil dieses Konzeptes ist die inhärente Datenkonsistenz zwischen allen Busteilnehmern. Sowohl das periodische als auch das aperiodische Versenden von Nachrichten während des normalen Betriebs sind möglich. Der Nachteil der ausschließlichen Festlegung der CAN-Spezifikation auf ATM ist, dass es per definitionem für CAN keine Teilnehmeradressierung gibt, welche wiederum die Grundlage für „Peer-to-Peer“ (PTP) Kommunikation darstellt. Für den Einsatz im Luftfahrtbereich mit seinen hohen Anforderungen an kontinuierliche Systemüberwachung aber ist die Möglichkeit, mit einzelnen Busteilnehmern zu kommunizieren, außerordentlich wichtig. CANaerospace stellt daher die erforderlichen Protokollfunktionen zur Verfügung, um PTP-Kommunikation zu ermöglichen.

PTP-Kommunikation erlaubt es, zusätzlich zu dem „normalen“ Datenfluss in einem System zeitweise oder dauerhaft Interaktionen zwischen einzelnen Busteilnehmern herzustellen und auch wieder aufzulösen, wodurch Netzwerkdienste auf „Client/Server“-Basis ermöglicht werden. Hierbei können mehrere dieser Interaktionen parallel laufen, und jeder Busteilnehmer kann gleichzeitig Client für bestimmte Interaktionen und Server für andere sein. Mit Hilfe dieses Mechanismus, in CANaerospace als „Node Service Concept“ bezeichnet, lassen sich beispielsweise Systemfunktionen auf transparente Art und Weise über verschiedene Teilnehmer im Netzwerk verteilen oder auch die dynamische Rekonfiguration eines gesamten Systems zur Erhöhung der Zuverlässigkeit im Fehlerfall steuern. Das Node Service Concept unterscheidet hierbei zwischen verbindungsorientierten und verbindungslosen Interaktionen, ähnlich wie im Falle von TCP/IP und UDP/IP für Ethernet.

Die gleichzeitige Verwendung von ATM- und PTP-Kommunikation für CAN erfordert die Einführung unterschiedlicher Netzwerkschichten, die eine voneinander unabhängige Kommunikation erlauben. Diese werden durch CANaerospace erzeugt, indem eine Gruppierung der CAN-Identifier wie in Abbildung 1 dargestellt vorgenommen wird. Die daraus resultierende Struktur erzeugt logische Kommunikationskanäle (Logical Communication Channel, LCC) und ordnet diesen eine bestimmte Kommunikationsart (ATM, PTP) zu. Benutzerdefinierte LCCs geben dem Anwender hierbei große Freiheiten, um die Implementierung von CANaerospace nach seinen Bedürfnissen zu ermöglichen.

Datei:CANaerospace 1.jpg

Abbildung 1: Logische Kommunikationskanäle von CANaerospace

Die CAN-Identifier-Bereiche in Abbildung 1 haben natürlich auch den entsprechenden Einfluss auf die Priorität der verschiedenen Kommunikationskanäle im Falle der Busarbitrierung. Aus diesem Grund sind die Kommunikationskanäle nach der relativen Wichtigkeit zueinander geordnet:

Emergency Event Data Channel (EED): Über diesen Kommunikationskanal werden Nachrichten verschickt, welche möglichst unmittelbar und demzufolge mit hoher Priorität versendet werden müssen. Damit verbunden sind in der Regel Ereignisse, die eine schnelle Systemreaktion (beispielsweise Systemdegradierung oder das Verlagern bestimmter Funktionen auf andere Busteilnehmer) erfordern. Für Emergency Event Data wird ausschließlich ATM-Kommunikation verwendet.

High/Low Priority Node Service Data Channel (NSH/NSL): Über diese Kommunikationskanäle werden Client/Server-Interaktionen mittels PTP-Kommunikation realisiert. Die entsprechenden Dienste können sowohl verbindungsorientiert als auch verbindungslos ablaufen. Die NSH/NSL-Kommunikationkanäle dienen auch der Unterstützung von Test- und Wartungsfunktionen.

Normal Operation Data Channel (NOD): Dieser Kommunikationskanal wird für die Übertragung der operationellen Luftfahrzeugdaten verwendet, welche im Normalbetrieb des Systems anfallen. Diese Nachrichten können sowohl synchron als auch asynchron und in von der Systemarchitektur vorgegebenen Intervallen versendet werden. Alle Nachrichten, welche nicht anderen Kommunikationskanälen zugeordnet werden, müssen diesen Kanal verwenden.

High/Low Priority User-Defined Data Channel (UDH/UDL): Diese Kommunikationskanäle stehen für benutzerdefinierte Nachrichten zur Verfügung, welche sich aufgrund ihrer Eigenschaften nicht innerhalb der anderen Kommunikationskanäle versenden lassen, ohne deren Definition zu verletzen. Solange der dafür festgelegte Identifierbereich eingehalten wird, können Nachrichteninhalt und die Zuteilung der Identifier vom Anwender festgelegt werden. Sowohl ATM- als auch PTP-Kommunikation sind zulässig. Um die Interoperabilität nicht zu stark einzuschränken, wird jedoch empfohlen, so weit wie möglich die anderen Kommunikationskanäle zu nutzen. Die Verwendung von anwenderdefinierten Nachrichten sollte die Ausnahme bleiben.

Debug Service Data Channel (DSD): Debug Service Data sind Nachrichten, welche im Verlauf der Entwicklung oder bei Sonderfällen wie Software Download für Entwicklungswerkzeuge benutzt werden und im Normalbetrieb nicht versendet werden. Der Inhalt der entsprechenden Nachrichten ist vollständig anwenderdefiniert.

Datenrepräsentation