Cyphal

Cyphal ist ein leichtgewichtiges Protokoll für die zuverlässige Kommunikation innerhalb von Fahrzeugen über verschiedene Übertragungstechnologien. Ursprünglich für den CAN-Bus entwickelt ^{[ 2 ]} , unterstützt es in späteren Versionen verschiedene Netzwerktypen ^{[ 3 ]} . OpenCyphal ist ein Open-Source-Projekt, das unter der MIT-Lizenz stehende Implementierungen des Cyphal-Protokolls bereitstellt. Vor der Umbenennung im März 2022 war das Projekt unter dem Namen UAVCAN (Uncomplicated Application-level Vehicular Computing and Networking) bekannt.

Der erste RFC, der die allgemeinen Ideen skizzierte, die später die Kernprinzipien des Designs von Cyphal (damals unter dem Namen UAVCAN bekannt) bilden sollten, wurde Anfang 2014 veröffentlicht. ^{[ 4 ]} Er war eine Reaktion auf den wahrgenommenen Mangel an adäquater Technologie, die einen robusten Echtzeit-Datenaustausch innerhalb von Fahrzeugen zwischen verteilten Komponenten moderner intelligenter Fahrzeuge (vorwiegend unbemannter Luftfahrzeuge) ermöglichen könnte.

Seit dem ursprünglichen RFC wurde das Protokoll drei größere Designiterationen durchlaufen, die 2020 (sechs Jahre später) in der Veröffentlichung der ersten langfristig stabilen Version (LTS) mit der Bezeichnung UAVCAN v1.0 gipfelten. In der Zwischenzeit wurde das Protokoll in zahlreichen verschiedenen Systemen eingesetzt, darunter unbemannte Luftfahrzeuge ^{[ 5 , 6 ]} , Raumfahrzeuge ^{[ 7 ]} , Unterwasserroboter [8], ^{Rennwagen [} 9 ^{] , allgemeine Robotersysteme} [ ^{10 ] und} Mikromobilitätsfahrzeuge ^{[ 11 ] . Im Jahr 2022 wurde das Protokoll in Cyphal umbenannt [ 12 ]} .

Cyphal wird von seinen Entwicklern als hochdeterministische, sicherheitsorientierte Alternative zu High-Level-Publish-Subscribe-Frameworks wie DDS oder dem Berechnungsdiagramm von ROS positioniert . Es ist kompakt und einfach genug, um auch in tief eingebetteten, sicherheitskritischen Anwendungen eingesetzt werden zu können. ^{[ 13 ]} Cyphal hat sich als mit Bare-Metal-Mikrocontrollern mit nur 32 KB ROM und 8 KB RAM nutzbar erwiesen. ^{[ 14 ]}

Das Protokoll ist offen und kann ohne Genehmigung oder Lizenzgebühren frei wiederverwendet werden. Die Entwicklung des Kernstandards und seiner Referenzimplementierungen erfolgt transparent und wird über das öffentliche Diskussionsforum koordiniert. ^{[ 15 ]} Stand 2020 wird das Projekt von mehreren großen Organisationen unterstützt, darunter NXP Semiconductors ^{[ 16 ]} und das Dronecode-Projekt. ^{[ 17 ]}

a. MODBUS läuft oft über RS-232.

b. DDS entlehnt eine Schnittstellendefinitionssprache von CORBA.

c. MODBUS über TCP-Port 502.

d. Airbus wendet sich an ARINC mit der Bitte um die Entwicklung eines neuen CAN-Standards. Michael Stock bringt seine Erfahrungen aus der Entwicklung von CAN Aerospace ein . ARINC-825-1 ist das Ergebnis.

e. Der erste AVB- Standard wird von der AVB Task Group der IEEE 802.1 Arbeitsgruppe veröffentlicht. IEEE1722-2011 wird herausgegeben.

f. Die AVB Task Group wird in TSN Task Group umbenannt.

g. ROS2 baut auf DDS auf . Typisches Medium für verteilte ROS2-Systeme ist Ethernet.

h. Mit der Veröffentlichung von 802.1Qbv und 802.1Qbu können vollständig deterministische Ethernet-Netzwerke definiert werden.

i. Pavel Kirienko leitet ein Open-Source-Projekt zur Definition von UAVCAN v0. Anfangs unterstützt es nur CAN 2.0B.

j. Airbus hält vor dem IEEE einen Vortrag mit dem Titel „Avionics Full Duplex Ethernet and the Time-Sensitive Networking Standard“, in dem die Integration von AFDX in die TSN-Standards vorgeschlagen wird.

k. ARINC 825-4 fügt Unterstützung für CAN-FD hinzu und definiert Tunneling über ARINC-664.

l. Amazon Prime Air definiert einen minimalen Satz von Änderungen an Version 0, der CAN-FD-Unterstützung hinzufügt. Die inoffizielle Variante wird als Version 0.5 bezeichnet. Gleichzeitig wurde auf dem Stockholmer Gipfel ^{[ 18 ]} UAVCAN v1 konzipiert.

Mit m.10BASE-T1S wird IEEE 802.3 hinzugefügt. Diese Spezifikation definiert Halbduplex-Ethernet-Medien mit zwei Drähten und mehreren Anschlusspunkten sowie PLCA ( PHY-Level Collision Avoidance ). Sie ist für Anwendungen im Automobil- und Industriebereich vorgesehen (z. B. als Ersatz für MODBUS).

n. Die Produktion des Airbus A380 wird eingestellt.

o. UAVCAN v1 wird zur Beta-Version.

p. DroneCAN übernimmt die Wartung der UAVCAN v0/v0.5-Spezifikation und deren Weiterentwicklung.

q. UAVCAN v1 wurde in Cyphal umbenannt. ^{[ 12 ]}

Cyphal bietet kostenlose Abstraktionen, die für Softwareentwickler zugänglich und vertraut sind ^{[ 19 ]} , ohne Kompromisse bei funktionaler Sicherheit und Deterministik einzugehen. ^{[ 3 ]} Als neue Technologie ist sie frei von Altlasten ^{[ 3 ]} und profitiert stark von aktuellen Entwicklungen im Bereich der allgemeinen Informationstechnologie . ^{[ 20 ]} Das Protokoll bietet ein zustandsloses Publish-Subscribe-Kommunikationsmodell, bei dem ein Knoten nach der Verbindung mit dem Netzwerk sofort betriebsbereit ist, um Anwendungen mit hohen Integritätsanforderungen zu unterstützen. ^{[ 13 ]}

Das Protokoll besteht aus zwei klar getrennten Hauptkomponenten: ^{[ 21 ]} der Transportschicht, die auf zuverlässigen Fahrzeugnetzwerken wie Ethernet oder CAN FD aufsetzt , und der transportunabhängigen Darstellungsschicht (Serialisierungsschicht), die auf der sogenannten Datenstrukturbeschreibungssprache (DSDL) basiert. Es wurde gezeigt, dass das Protokoll mit weniger als 1000 logischen Codezeilen implementierbar ist. ^{[ 22 ]}

DSDL ist ideologisch ähnlich der in ROS verwendeten Schnittstellenbeschreibungssprache , führt jedoch zusätzliche statische Einschränkungen ein, um die Lösung für hochintegritätskritische Echtzeit-Systeme geeignet zu machen. Diese Ähnlichkeit veranlasste einige Entwickler, ROS mithilfe automatisierter Übersetzungsschichten mit Cyphal zu verbinden. ^{[ 10 ] [ 23 ]}

Das Protokoll basiert auf folgenden zentralen Gestaltungsprinzipien, die gewährleisten sollen, dass die Lösung für moderne, komplexe und sicherheitskritische Fahrzeugsysteme geeignet ist.

• Demokratisches Netzwerk – Es gibt keinen Masterknoten. Alle Knoten im Netzwerk haben die gleichen Kommunikationsrechte; es sollte keinen Single Point of Failure geben.
• Erleichterung der funktionalen Sicherheit – Die Entwickler von Cyphal-Systemen verfügen über die notwendigen Garantien und Werkzeuge, um das System zu analysieren und sein korrektes Verhalten sicherzustellen.
• Abstraktionen für die Kommunikation auf hoher Ebene – Das Protokoll unterstützt Publish/Subscribe- und Remote Procedure Call-Kommunikationssemantik mit statisch definierten und verifizierten Datentypen (Schema). Die für die Kommunikation verwendeten Datentypen sind klar und plattformunabhängig definiert und somit sowohl für Maschinen als auch für Menschen leicht verständlich.
• Förderung der herstellerübergreifenden Interoperabilität – Cyphal bietet eine gemeinsame Grundlage, auf der verschiedene Hersteller aufbauen können, um die Interoperabilität ihrer Geräte sicherzustellen. Cyphal stellt einen generischen Satz standardisierter, anwendungsunabhängiger Kommunikationsdatentypen bereit.
• Gut definierte generische High-Level-Funktionen — Cyphal definiert Standarddienste und -nachrichten für gängige High-Level-Funktionen, wie z. B.: Netzwerkerkennung, Knotenkonfiguration, Knoten-Softwareaktualisierung, Knotenstatusüberwachung, netzwerkweite Zeitsynchronisation, Plug-and-Play-Knotenunterstützung usw.
• Atomare Datenabstraktionen – Knoten können große Datenstrukturen austauschen, die die Kapazität eines einzelnen Transportframes übersteigen. Cyphal führt die automatische Datenzerlegung und -wiederzusammensetzung auf Protokollebene durch und verbirgt so die damit verbundene Komplexität vor der Anwendung.
• Hoher Durchsatz, geringe Latenz, Deterministik – Cyphal fügt dem zugrunde liegenden Transportprotokoll nur einen sehr geringen Overhead hinzu, was einen hohen Durchsatz und geringe Latenz gewährleistet. Dadurch eignet sich Cyphal hervorragend für harte Echtzeitanwendungen.
• Unterstützung redundanter Schnittstellen und redundanter Knoten – Cyphal eignet sich für Anwendungen, die modulare Redundanz erfordern.
• Einfache Logik, geringe Rechenanforderungen – Cyphal eignet sich für eine Vielzahl eingebetteter Systeme, von leistungsstarken Bordcomputern bis hin zu ressourcenbeschränkten Mikrocontrollern. Der Support ist kostengünstig in Bezug auf Rechenleistung und Entwicklungsstunden, und erweiterte Funktionen lassen sich bei Bedarf schrittweise implementieren.
• Umfangreiche Datentyp- und Schnittstellenabstraktionen — Eine Schnittstellenbeschreibungssprache ist ein Kernbestandteil der Technologie und ermöglicht es tief eingebetteten Subsystemen, direkt (und auf wartungsfreundliche Weise) mit Systemen höherer Ebene zu interagieren, während gleichzeitig Simulation und Funktionstests ermöglicht werden.
• Unterstützung für verschiedene Transportprotokolle — Cyphal ist mit verschiedenen Transportprotokollen nutzbar und kann zukünftig um die Unterstützung weiterer Transportprotokolle erweitert werden.
• API-unabhängiger Standard – Im Gegensatz zu einigen anderen Netzwerkstandards beschreibt Cyphal nicht die Anwendungsprogrammierschnittstelle (API). Alle Details, die das von anderen Netzwerkteilnehmern beobachtbare Verhalten einer Implementierung nicht beeinflussen, fallen nicht in den Geltungsbereich der Spezifikation.
• Offene Spezifikation und Referenzimplementierungen – Die Cyphal-Spezifikation ist und bleibt offen und für alle frei nutzbar. Die Referenzimplementierungen werden unter den Bedingungen der freizügigen MIT-Lizenz verbreitet oder als Public Domain veröffentlicht.

Der CAN-Transport basiert auf CAN und CAN FD und verwendet 29-Bit-Kennungen. Die CAN-Nutzdaten enthalten einen festen Overhead von einem Byte pro Frame für die Anforderungen der Transportschicht. ^{[ 21 ]}

Für Echtzeit-Ethernet-basierte Fahrzeugnetzwerke wurde das Cyphal/UDP-Transportprotokoll vorgeschlagen. Das Design soll von AFDX , DDS/RTPS und SOME/IP beeinflusst sein. ^{[ 20 ]}

Wie andere ähnliche Technologien bietet Cyphal eine Bibliothek gängiger Datentypen, die von den Protokollbetreuern verwaltet und gepflegt werden und bestimmte häufig auftretende Probleme in verbreiteten Anwendungen lösen sollen. ^{[ 24 ]} Diese Datentypen ergänzen herstellerspezifische oder anwendungsspezifische Datentypen, die von Anwendern definiert werden, ähnlich wie eine Programmiersprache üblicherweise eine Standardbibliothek definiert , auf die sich die vom Benutzer entwickelte Software stützt. Die Protokollspezifikation enthält eine Reihe von Regeln, die Konflikte vermeiden und die Interoperabilität von Datentypen unabhängiger Hersteller verbessern sollen. ^{[ 25 ]}

• Offizielle Website
• Öffentliches Forum für Entwicklungskoordinierung und Feedback