Zur Vernetzung von Elektronikkomponenten werden in der Luftfahrttechnik seit vielen Jahren Bussysteme eingesetzt. In neueren Systemen gewinnt dabei Controller Area Network (CAN) an Bedeutung. Die Spezifikation ARINC 825 der Standardisierungsorganisation ARINC beschreibt die empfohlene Nutzung von CAN in zivilen Flugzeugen. Einsatz findet diese Spezifikation bisher bei den Herstellern Airbus und Boeing.
Allgemeines In Verkehrsflugzeugen, wie dem Airbus A380 oder der Boeing 787, sind zwischen 80 und 250 Controller Area Network (CAN)-Netzwerke integriert. Durch die Vielzahl unterschiedlicher physikalischer Schnittstellen, Datenformate, Kommunikationsmechanismen und die nicht ausreichend abgestimmte Nutzung von CAN-Identifiern stellte sich der Aufwand für die Systemintegration aus Sicht der Flugzeughersteller allerdings als zunehmend problematisch heraus. Diese Erkenntnis führte bereits im Jahr 2004 zu einer gemeinsamen Initiative von Airbus und Boeing, die die Schaffung eines einheitlichen CAN-Standards für die Verkehrsluftfahrt zum Ziel hatte. Als Standardisierungsorganisation wurde ARINC ausgewählt und unter der Leitung von Airbus und Boeing eine technische Arbeitsgruppe des Airlines Electronic Engineering Committee (AEEC), bestehend aus erfahrenen Ingenieuren von Airbus (Bremen, Hamburg und Toulouse), Boeing, GE Aviation, Rockwell Collins und Stock Flight SystemsStock Flight Systems gebildet. Diese Gruppe entwickelte auf der Basis von CANaerospace innerhalb von drei Jahren die ARINC Spezifikation 825, die im Airbus A350 erstmals angewandt wurde. ARINC 825 entstand durch die Zusammenarbeit von Luftfahrtelektronikingenieuren aus vier Nationen, die alle bereits seit vielen Jahren für Entwicklung und Integration von CAN-basierenden Systemen in Luftfahrzeugen verantwortlich sind. Auf der Grundlage dieses Erfahrungshintergrundes wurde ein Standard geschaffen, der aufgrund der Unterstützung durch die großen Luftfahrzeughersteller Airbus und Boeing einen ganz erheblichen Einfluss auf die Entwicklung von CAN im Luftfahrtbereich hat.
ARINC 825 stellt nicht nur ein luftfahrtspezifisches höheres Protokoll dar, sondern geht auf CAN insgesamt ein und beschreibt auch die in den CAN-Controllern selbst implementierten Ebenen 1 und 2 des CAN-Protokolls. Zudem enthält es ein umfangreiches Kapitel, in dem Entwicklungsrichtlinien für CAN im Luftfahrtbereich festgelegt werden. Diese Richtlinien umfassen die physikalische Busanschaltung, enthalten aber auch wichtige und weitgehende Informationen bezüglich der Programmierung von CAN-Controllern und der Verwendung der in ARINC 825 definierten Kommunikationsmechanismen. Insbesondere die Vermeidung und Behandlung von Fehlern in CAN-Systemen wird im Einzelnen diskutiert und durch Hinweise für den Entwurf fehlertoleranter Systeme ergänzt. Insofern geht ARINC 825 weit über andere ARINC-Spezifikationen hinaus und stellt eine Art Entwicklungshandbuch für CAN-Systeme in Luftfahrzeugen dar. Die ARINC Spezifikation 825 wurde im November 2007 erstmals veröffentlicht, die aktuelle Version ist das Supplement 2.
Eigenschaften In Verkehrsflugzeugen wird CAN im Wesentlichen als Sekundär-Netzwerk für Kommunikationsdatenbusse nach ARINC Spezifikation 664, Part 7 (AFDX) verwendet. In diesem Fall dient CAN der Verbindung von Sensoren, Stellantrieben oder anderen Avionikgeräten, die niedrige bis mittlere Kommunikationsgeschwindigkeiten erfordern. CAN wird in dieser Flugzeugklasse daher in erster Linie als komplementäres Netzwerk zu den komplexen „Backbone“-Netzwerken wie AFDX verwendet. In Flugzeugen der Allgemeinen Luftfahrt hingegen kann CAN durchaus das zentrale Avionik-Netzwerk sein und muss daher alle Anforderungen an einen flugsicherheitskritischen Datenbus erfüllen. ARINC 825 wurde so ausgelegt, dass es beiden Anforderungen gerecht werden und daher sowohl als sekundäres als auch als Hauptnetzwerk dienen kann. ARINC 825 erfüllt daher folgende Kriterien:
Einfache Verbindung lokaler CAN-Busse zu anderen Flugzeugnetzwerken
Geringstmögliche Kosten hinsichtlich Implementierung und Änderungen im Laufe der Lebenszeit des Flugzeugs
Höchstmögliche Interoperabilität und Austauschbarkeit von CAN-verbundenen Line-replaceable Units (LRUs)
Höchstmögliche Flexibilität hinsichtlich der Wegnahme, Hinzufügung oder Änderung einzelner Busteilnehmer unter Vermeidung vermeidbarer Einflüsse auf andere Busteilnehmer
Unterstützung netzwerkübergreifender Kommunikation für Einzelparameter und Blockdatentransfers über Gateways
Integrierte Fehlererkennung und -signalisierung
Unterstützung systemübergreifender Funktionen wie der Konfiguration einzelner Busteilnehmer sowie der Flugzeuggesundheitsanalyse („Aircraft Health Management“)
Physikalische Schnittstelle Um Interoperabilität und zuverlässigen Datenaustausch sicherzustellen, definiert ARINC 825 elektrische Eigenschaften, Busanschaltungsanforderungen und Datenübertragungsgeschwindigkeiten einschließlich entsprechender Toleranzen auf der Basis von ISO 11898. Besonderes Augenmerk wird dabei auf die Definition CAN-spezifischer Zeitberechnungen (Genauigkeit der Datenübertragungsgeschwindigkeit, Festlegung des Abtastzeitpunktes) gelegt. Die von ARINC 825 unterstützten Datenübertragungsgeschwindigkeiten sind 1000 kbit/s, 500 kbit/s, 250 kbit/s, 125 kbit/s und 83.333 kbit/s.
Netzwerkschichten ARINC 825 baut bezüglich der Kommunikationsmechanismen in vielerlei Hinsicht auf CANaerospace auf, verwendet aber ausschließlich Extended (29 Bit) Identifier. Dadurch kann ein Teil der Identifier-Bits dafür genutzt werden, die für die Verkehrsluftfahrt typische große Anzahl verschiedener Systeme abzubilden und Interoperabilität auch in sehr komplexen Systemen sicherzustellen.
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. ARINC 825 stellt daher die erforderlichen Protokollfunktionen zur Verfügung, um PTP-Kommunikation zu ermöglichen. Außerdem wird dadurch die Implementierung zusätzlicher Funktionen der ISO/OSI-Schichten 3, 4 und 6 ermöglicht, was wiederum die Erzeugung logischer Kommunikationskanäle (Logical Communication Channel, LCC) und entsprechender Kommunikationsarten (ATM, PTP) erlaubt, wie in Abbildung 1 dargestellt.
Datei:A825 1.jpg
Abbildung 1: CAN-Identifierstrukturen für ARINC 825
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 ARINC 825 erzeugt, indem eine Gruppierung der CAN-Identifier wie in Abbildung 2 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 ARINC 825 nach seinen Bedürfnissen zu ermöglichen.
Datei:A825 2.jpg
Abbildung 2: Logische Kommunikationskanäle von ARINC 825
Zusätzlich sind für ARINC 825 die 29 Bit des Identifiers noch in weitere Felder unterteilt, welche die folgende Bedeutung haben:
Der Function Code Identifier (Source FID bzw. Server/Client FID) identifiziert das System bzw. Subsystem, in welcher die betreffende Nachricht ihren Ursprung hat, im Falle der Server FID auch das empfangende System bzw. Subsystem. Der FID entspricht weitgehend den in der Luftfahrt seit vielen Jahrzehnten verwendeten Air Transport Association (ATA)-Kapiteln, wobei die ARINC 825-Spezifikation die Zuordnung von ATA-Kapitel zu der entsprechenden Identifier-Bitkombination (und der damit verbundenen Nachrichtenpriorität) gemäß der Wichtigkeit der einzelnen Flugzeugsysteme vornimmt. Daneben sind verschiedene FIDs beispielsweise für temporäre Test/Wartungssysteme oder für die Verwendung durch andere, auf ARINC 825 basierender Standards reserviert. Die Verwendung definierter FIDs ist für alle Kommunikationskanäle außer UDC und FMC vorgeschrieben.
Das Reserved/Service Message Type (RSD/SMT)-Bit ist für ATM-Kommunikation immer 0, während es für PTP-Kommunikation die Richtung des Datentransfers zwischen Client und Server anzeigt. Für Serviceanforderungen (also vom Client versendete Nachrichten) wird dieses Bit auf 1 gesetzt, während es für die Antworten des Servers auf 0 gesetzt wird.
Das Local Bus Only (LCL)-Bit wird für Nachrichten auf 1 gesetzt, welche innerhalb des betreffenden Netzwerksegments verbleiben und nicht durch Gateways in andere Netzwerke durchgeleitet werden sollen.
Das Private (PVT)-Bit wird für solche Nachrichten auf 1 gesetzt, die für Busteilnehmer, welche nicht explizit für die Verarbeitung dieser Nachrichten programmiert wurden, keine Bedeutung haben. Nachrichten, in denen das PVT-Bit gesetzt ist, sind in der Regel nicht in der Kommunikationsprofil-Datenbasis beschrieben und nur für die „private“ Nutzung zwischen ausgewählten Busteilnehmern vorgesehen.
Der Data Object Code (DOC) für ATM-Kommunikation spezifiziert den mit der Nachricht versendeten Parameter. Die genaue Beschreibung aller Parameter bezüglich ihrer Eigenschaften (physikalische Einheit, Datentyp, Wiederholrate etc.) werden in der entsprechenden Kommunikationsprofil-Datenbasis beschrieben.
Der Redundancy Channel Identifier (RCI) definiert, welchem Redundanzkanal die betreffende Nachricht zuzuordnen ist. ARINC 825 unterstützt damit redundante Systeme bis zum Grad vier, wobei der RCI erlaubt, beispielsweise redundante Nachrichten auf einem einzigen Bus zu versenden und damit Redundanzsprünge im System auf einfache Art und Weise zu überwinden.
Der Server Identifier (SID) definiert den Busteilnehmer (oder eine entsprechende Funktion in einem Busteilnehmer), welche einen Dienst zur Verfügung stellt, der im Rahmen des Node Service Concept auf der Basis von PTP-Kommunikation nutzbar ist. Die Verbindung aus SID, Server FID und RCI bildet zusammengenommen einen Node Identifier (NID). Dieser NID sorgt für die eindeutige Adressierung eines Servers im Netzwerk.
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 ARINC 825 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.
Datenrepräsentation Zur Unterstützung der Interoperabilität in Flugzeugsystemen bietet ARINC 825 eine Reihe von Definitionen:
Datenformatdefinition (ausschließlich Big Endian)
Datentypdefinitionen (Boolean, Integer, Floating-Point, ....)