ARINC 825

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.

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 Systems^[1] 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.^[2]

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“)

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.

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.

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.

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.

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

• Luftfahrtachsensysteme und Vorzeichendefinitionen (ISO1151 bzw. EN9300)

• Einheitendefinitionen (m, kg, ....)

• Definition der verschiedenen Luftfahrzeugfunktionen (Flight State, Air Data, ....)

Die Unterteilung nach Luftfahrzeugfunktionen wird unter anderem dazu benutzt, Quelle und Ziel von ARINC 825-Nachrichten zu identifizieren. Die entsprechenden Definitionen sind von den Air Transport Association (ATA) -Kapiteln abgeleitet, was es ermöglicht, bei der Systemauslegung Festlegungen zu verwenden, die bereits seit Jahrzehnten in der Luftfahrtindustrie gebräuchlich sind.

ARINC 825 verwendet das aus CANaerospace bekannte und 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 3 zeigt beispielhaft das Sendeschema eines ARINC 825-Netzwerks mit zwei Busteilnehmern, die ihre Nachrichten asynchron, in wechselnder Reihenfolge und zu variierenden Zeitpunkten innerhalb ihres Minor Time Frames versenden. Bei Anwendung dieses Konzepts lässt sich nachweisen, dass sich ein ARINC 825-Netzwerk vorhersagbar verhält und die Anforderungen eines flugsicherheitskritischen Systems erfüllt. Um dies auch unter Fehlerbedingungen aufrechtzuerhalten, müssen vom System-Designer Vorgaben gemacht werden, wie mit Störungen (z.Bsp. hohes Aufkommen von Error Frames) umzugehen ist^[3].

ARINC 825 kann daher auch für Systeme bis hin zu Design Assurance Level (DAL) A verwendet werden, sofern der Verlust eines einzelnen Netzwerks keine Auswirkung hat, deren Klassifikation höher als „major“ eingestuft ist.

Abbildung 3: Vereinfachtes ARINC 825-Sendeschema mit zwei Busteilnehmern

Für ARINC 825 wurden Inhalt und Formatierung der Nutzdaten vollständig dem Anwender überlassen. Das Fehlen eines selbstidentifizierenden Datenformats wie bei CANaerospace machte es daher erforderlich, die Interoperabilität auf anderem Weg sicherzustellen. ARINC 825 verwendet daher für die eindeutige und systemübergreifende Netzwerkbeschreibung eine sogenannte „Kommunikationsprofil-Datenbasis“. Hierzu enthält die ARINC 825-Spezifikation die Beschreibung eines Kommunikationsprofil-Dateiformats, ab Supplement 1 auf der Basis von XML 1.0^[2], welches für jeden Busteilnehmer zu erstellen ist. Die Gesamtheit der Kommunikationsprofile aller Busteilnehmer in einem gegebenen ARINC 825-Netzwerk beschreibt den gesamten Busverkehr und dient damit der Spezifikation eines Netzwerks, aber auch der Analyse für Zulassungszwecke sowie als Grundlage für Abnahme- und Integrationstests. Eine genaue Analyse einer solchen Kommunikationsprofil-Datenbasis erlaubt es, potentielle Netzwerkprobleme bereits im Vorfeld zu erkennen und zu vermeiden. Testwerkzeuge für ARINC 825-Netzwerke müssen dazu in der Lage sein, diese Kommunikationsprofil-Datenbasis zu lesen und richtig zu interpretieren.

Die Integrated-Modular-Avionics-Systemarchitekturen moderner Verkehrsflugzeuge verwenden in der Regel verschiedene Datenbusse mit unterschiedlichen Eigenschaften. Der Datenaustausch zwischen diesen Datenbussen muss durch Gateways sichergestellt werden, da Bandbreite und Kommunikationsmechanismen der betreffenden Netzwerke typischerweise nicht zusammenpassen. Um den Entwurf der entsprechenden Gateways zwischen CAN und anderen Netzwerken zu unterstützen, definiert ARINC 825 ein vereinfachtes Gateway-Modell und enthält tiefgreifende Informationen hinsichtlich Protokollanpassungen, Bandbreitenmanagement, Datenpufferung und Fehlerbehandlung.

Die ARINC Spezifikation 825 enthält ein Kapitel mit umfangreichen Entwicklungsrichtlinien, die Systemingenieuren und LRU-Entwicklern helfen soll, ARINC 825 spezifikationskonform und in zulassbarer Art und Weise zu verwenden. Die Entwicklungsrichtlinien dokumentieren eine breitgefächerte Sammlung von Erfahrungen aus der Luftfahrtindustrie, welche die Auslegung von ARINC 825 in erheblichem Maße beeinflusst haben. Es handelt sich bei den Entwicklungsrichtlinien jedoch nicht um harte Forderungen, sondern vielmehr um Empfehlungen, die Entwicklern helfen soll, potentielle Schwachstellen bei der Entwicklung von CAN-basierenden Systemen für Luftfahrzeuge zu vermeiden.

Die Konsistenz und Richtigkeit der ARINC Spezifikation 825 wurde während des mehrere Jahre dauernden Entwurfsprozesses kontinuierlich mit Hilfe eines Referenzsystems überprüft.^[4] In diesem Referenzsystem wurden alle Protokollfunktionen implementiert, gegen die Spezifikation getestet und damit die Integrität von ARINC 825 sichergestellt. Aufgrund dieses für ARINC Spezifikationen erstmals angewandten Qualitätssicherungsverfahrens hat das Airlines Electronic Engineering Committee (AEEC) entschieden, dass alle zukünftigen ARINC Spezifikationen, die CAN verwenden, auf ARINC 825 basieren werden. Beispiele hierfür sind der ARINC 826 Data Load und der ARINC 812 Galley Insert Communication Standard. Technische Entwicklungsanforderungen von Airbus definieren ARINC 825 bereits für eine Vielzahl von Systemen für den neuen Airbus A350. CANaerospace bleibt als eine der Grundlagen von ARINC 825 weiterhin als „11-Bit“-Alternative erhalten und wird kontinuierlich weiterentwickelt, wobei ab CANaerospace Version 1.8 eine erhöhte Kompatibilität zu ARINC 825 sichergestellt ist.

1. ↑ Stock Flight Systems
2. ↑ ^{a b} Network connectivity (Memento vom 15. Mai 2023 im Internet Archive)
3. ↑ Application Note AN-ION-1-0104. (PDF; 242 kB) In: CAN-based Protocols in Avionics. 5. Mai 2010, archiviert vom Original am 7. Oktober 2011; abgerufen am 7. Oktober 2010.  abgerufen am 15. Mai 2023
4. ↑ ARINC 825 Website (Memento vom 15. Februar 2013 im Internet Archive)