CANaerospace

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 Systems. 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).

Das Logo

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 eingesetzt. 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 werden.

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.

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

Da die Mehrzahl der in Flugzeugen verwendeten Echtzeitrechnersysteme auf „Big Endian“-Prozessorarchitekturen basiert, wurde diese Datenanordnung konsequenterweise auch für CANaerospace festgelegt. Für die „Big Endian“- Datenanordnung ist das höchstwertige Bit eines Datums beliebiger Länge linksbündig angeordnet und wird über CAN als erstes gesendet (siehe Abbildung 2). CANaerospace ist auf Standard (11 Bit) Identifier ausgelegt, kann aber auch auf der Basis von Extended (29 Bit) Identifiern implementiert werden. Die Bits 12-28 des CAN-Identifiers wurden bis zur Version 1.7 von CANaerospace für Redundanz verwendet, ab Version 1.8 ist die Aufteilung dieser Bits auf die Kompatibilität zu ARINC 825 ausgerichtet.

Abbildung 2: Big Endian-Datenanordnung bei der Versendung von CANaerospace-Nachrichten

Eine Besonderheit von CANaerospace ist das selbstidentifizierende Nachrichtenformat, welches durch eine Strukturierung des Nachrichteninhalts erreicht wird, wie in Abbildung 3 dargestellt. Diese Struktur definiert einen 4-Byte Message Header und einen bis zu 4 Byte langen Parameteranteil.

Abbildung 3: Selbstidentifizierendes CANaerospace-Datenformat

Auf den ersten Blick erscheint der Verzicht darauf, alle der maximal 8 Bytes der CAN-Nachrichten für Parameter zu nutzen ineffizient zu sein, andererseits erfüllt der Message Header wichtige Zwecke, die auch bei einer anderen Konzeption durch die Verwendung von Nutzdatenbytes hätten erreicht werden müssen: Der CANaerospace Message Header ermöglicht es empfangenden Busteilnehmern, eingehende CAN-Nachrichten unmittelbar nach deren Empfang hinsichtlich Ursprung, Datentyp, Integrität und Zeitpunkt ihrer Erzeugung zu analysieren. Hierzu werden von den Busteilnehmern außer der Kenntnis der im System gültigen Identifierverteilung keine anderweitigen Informationen benötigt. Die einzelnen Header-Bytes haben dabei folgende Bedeutung:

• Node-ID: Der Node-Identifier identifiziert im Falle von ATM-Kommunikation (EED, NOD) den Busteilnehmer, welcher die Nachricht versandt hat, im Falle von PTP-Kommunikation (NSH, NSL) jedoch den angesprochenen Busteilnehmer (Client bzw. Server). Node.ID „0“ wird in letzterem Fall verwendet, um alle Busteilnehmer in einem Netzwerk gleichzeitig anzusprechen.

• Data Type: Der Datentyp definiert, wie der Inhalt der betreffenden Nachricht hinsichtlich seines Datenformats zu interpretieren ist (z. B. Anzahl der Bytes bei Integer-Formaten, deren Komplement oder Fließkommazahl). Die entsprechende Kodierung des Datentyps wird hierbei der CANaerospace Data Type List entnommen, die auch benutzerdefinierte Erweiterungen erlaubt.

• Service Code: Für Normal Operation Data (NOD)-Nachrichten ist der Service Code dafür vorgesehen, den empfangenden Busteilnehmern Zusatzinformationen hinsichtlich der Integrität des zugehörenden Parameters zu liefern. Dies kann beispielsweise das Ergebnis der kontinuierlichen Überprüfung eines Sensors, die ermittelte Genauigkeit eines GPS-Signals oder die aktuelle Gültigkeitsinformation eines Navigationssystems sein. Bezüglich PTP-Kommunikation enthält der Service Code den Node Service Code der entsprechenden Client/Server-Interaktion.

• Message Code: Für Normal Operation Data (NOD)-Nachrichten wird der Message Code für jede Nachricht pro Identifier vom versendenden Busteilnehmer um eins erhöht und springt nach Erreichen des Wertes 255 wieder auf 0. Dies erlaubt empfangenden Busteilnehmern, fehlende oder verzögerte Nachrichten zu identifizieren und entsprechend zu reagieren. Bezüglich PTP-Kommunikation dient der Message Code der detaillierten Spezifikation der betreffenden Client/Server-Interaktion.

Der Header enthält damit wesentliche Zusatzinformationen, um die Integrität des damit verbundenen Parameter für die Verwendung in sicherheitskritischen und insbesondere in redundant aufgebauten Systemen zu analysieren. Zudem wird auf diese Weise auch die Interoperabilität von Busteilnehmern verschiedener Hersteller erheblich verbessert. Nicht zuletzt vereinfacht die Auswertung des Headers die Analyse von CANaerospace-Netzwerken bezüglich des Status der einzelnen Busteilnehmer, was für Testbarkeit und Wartbarkeit der oft komplexen Systeme in Luftfahrzeugen außerordentlich hilfreich ist.

Zur weiteren Verbesserung der Interoperabilität definiert CANaerospace neben dem Datenformat auch luftfahrtspezifische Achsensysteme mit ihren entsprechenden Vorzeichen sowie physikalische Einheiten. Zusammen mit der vordefinierten Identifierverteilungsliste sind damit alle Nachrichten in einem CANaerospace-Netzwerk unverwechselbar beschrieben. Die Standard-Identifierverteilung reserviert den Identifierbereich von 300 bis 1799 und weist den verschiedenen Identifiern eindeutige Parameter zu. Abbildung 4 zeigt einen Ausschnitt aus dieser Verteilung.

Abbildung 4: Auszug aus der Standard-Identifierverteilung von CANaerospace V 1.7

Anwender können bei Bedarf eigene Identifierverteilungslisten verwenden, wobei es der zwingend in allen CANaerospace-Busteilnehmern zu implementierende „Node Identification Service“ erlaubt, alle an einem Netzwerk angeschlossenen Geräte hinsichtlich der von ihnen verwendeten Identifierverteilung abzufragen und damit Inkonsistenzen zu vermeiden. Sowohl die Identifierverteilung als auch die Listen für Datentypen und physikalische Einheiten haben zudem benutzerdefinierte Sektionen, in denen Anwender entsprechende Erweiterungen vornehmen können.

Zeitverhalten in CANaerospace-Netzwerken

Eine besondere Anforderung an sicherheitskritische Systeme in Luftfahrzeugen besteht darin, dass ihr Zeitverhalten präzise definiert, analysiert und geprüft werden können muss, um formale Zulassungsanforderungen zu erfüllen. Diese Anforderung an das Zeitverhalten bedeutet, dass das Zeitverhalten eines solchen Systems eindeutig und vorhersagbar sein muss. Die zeitliche Genauigkeit, mit der die Kommunikation vonstattengehen muss, ist abhängig von der jeweiligen Anwendung und muss durch eine entsprechende Systemanalyse bestimmt werden. Tatsächlich nachgewiesen werden muss den Luftfahrtzulassungsbehörden (z. B. FAA, EASA), dass sich ein sicherheitskritisches System unter allen Umständen vorhersagbar verhält. Dies kann mit CAN in dem Moment sichergestellt werden, in dem das zeitliche Schema, nach dem alle Busteilnehmer ihre Nachrichten versenden, einem Konzept zur Verteilung der zur Verfügung stehenden Bandbreite folgt. Dies gilt ungeachtet der Tatsache, dass dem Controller Area Network, bedingt durch die variable Nachrichtenlänge (verursacht durch Bit Stuffing) und dem Carrier Sense Multiple Access / Collision Resolution (CSMA/CR) Arbitrierungsverfahren eine Variation der Zeitpunkte, zu dem Nachrichten versendet werden, inherent ist. Entscheidend aber ist, dass das Konzept zum Management der Bandbreite dafür sorgt, dass keine zeitlichen Variationen auftreten, die nicht bestimmbar sind.

CANaerospace definiert ein solches, als „Time Triggered Bus Scheduling“ bezeichnetes Bandbreitenmanagement-Konzept sowohl für ATM- als auch PTP-Kommunikation. Dieses Konzept basiert auf einer Begrenzung der Anzahl von CAN-Nachrichten, die ein Busteilnehmer innerhalb eines im Rahmen der Vorentwicklung des Gesamtsystems definierten Zeitrahmens (Minor Time Frame) versenden darf, sowie auf einer höchstens 50%igen Ausnutzung der verfügbaren Bandbreite. Dadurch wird sichergestellt, dass die Versendung keiner Nachricht über einen festgelegten Zeitpunkt hinaus verzögert wird. Die größtmögliche Anzahl versendeter CAN-Nachrichten innerhalb eines Minor Time Frame kann sich durchaus von Busteilnehmer zu Busteilnehmer unterscheiden und kann eine gewisse „Reserve“ für zukünftige Erweiterungen vorsehen. Time Triggered Bus Scheduling macht sich die Erkenntnis zunutze, dass nicht alle CAN-Nachrichten in einem System mit der gleichen, durch den Minor Time Frame vorgegebenen Erneuerungsrate gesendet werden müssen. Die Definition ganzzahliger Vielfacher der durch den Minor Time Frame vorgegebenen Erneuerungsrate sowie zugehöriger „Transmission Slots“ lassen sich eine wesentlich größere Anzahl von CAN-Nachrichten in vorhersagbarer Weise versenden als wenn diese alle an den Minor Time Frame selbst gebunden wären.

Time Triggered Bus Scheduling erfordert, dass sich jeder Busteilnehmer zu jeder Zeit an das vorgegebene Sendeschema hält, also niemals mehr als die für ihn festgelegte maximale Anzahl von Nachrichten innerhalb eines Minor Time Frames versendet. Dies bedeutet jedoch nicht, dass die Busteilnehmer sich hinsichtlich ihrer Sendezeitpunkte oder der Reihenfolge der Versendung ihrer Nachrichten zeitlich synchronisieren müssen. Abbildung 5 zeigt beispielhaft das Sendeschema eines CANaerospace-Netzwerks mit zwei Busteilnehmern, die ihre Nachrichten asynchron, in wechselnder Reihenfolge und zu variierenden Zeitpunkten innerhalb ihres Minor Time Frames versenden. Das Beispiel erfüllt die Anforderungen des Time Triggered Bus Scheduling in vollem Umfang.

Abbildung 5: Vereinfachtes CANaerospace-Sendeschema mit zwei Busteilnehmern

Bei Verwendung von Time Triggered Bus Scheduling kann nachgewiesen werden, dass sich ein CANaerospace-Netzwerk unter der Bedingung vorhersagbar verhält, dass nicht mehr als 50 % der Bandbreite durch CAN Error Frames in Anspruch genommen werden. Um dies auch unter stärkeren Fehlerbedingungen aufrechtzuerhalten, müssen vom System-Designer Vorgaben gemacht werden, wie mit diesen Störungen umzugehen ist.