Controller Area Network (CAN) – Protokollübersicht

Ein CAN-Bus (Controller Area Network) ist ein hochintegriertes serielles Bussystem zur Vernetzung intelligenter Geräte. CAN-Busse und -Geräte sind gängige Komponenten in Automobil- und Industriesystemen. Das CAN-Protokoll ermöglicht beispielsweise eine effiziente Kommunikation zwischen Sensoren und elektronischen Steuergeräten (ECUs) zur Unterstützung moderner Fahrerassistenzsysteme. Mit einem CAN-Schnittstellengerät können LabVIEW-Anwendungen zur Kommunikation mit einem CAN-Netzwerk erstellt werden.

Das CAN-Protokoll wurde 1985 von Bosch entwickelt, um fahrzeugeigene Netzwerke zu vereinfachen. In der Vergangenheit haben Automobilhersteller elektronische Geräte in Fahrzeugen mit Punkt-zu-Punkt-Verbindungssystemen verbunden. Die Hersteller begannen, immer mehr Elektronik in Fahrzeugen einzusetzen, was zu sperrigen Kabelbäumen führte, die schwer und teuer waren. Anschließend ersetzten sie dedizierte Verbindungen durch fahrzeugeigene Netzwerke, was Kosten, Komplexität und Gewicht reduzierte. CAN, ein hochintegriertes serielles Bussystem zur Vernetzung intelligenter Geräte, hat sich als Standard-Fahrzeugnetzwerk etabliert. Die Automobilindustrie übernahm schnell CAN und wurde 1993 zum internationalen Standard ISO 11898. Seit 1994 sind mehrere übergeordnete Protokolle auf CAN standardisiert, wie CANopen und DeviceNet. Andere Märkte haben diese Zusatzprotokolle, die heute Standards für die industrielle Kommunikation sind, weitgehend übernommen. Dieses Whitepaper konzentriert sich auf CAN als fahrzeugeigenes Netzwerk.

Günstiges, leichtes Netzwerk

CAN bietet ein kostengünstiges, langlebiges Netzwerk für die Kommunikation mehrerer CAN-Geräte. Dies hat den Vorteil, dass elektronische Steuergeräte (ECUs) anstelle von analogen und digitalen Eingängen für jedes Gerät im System eine einzige CAN-Schnittstelle haben können. Dies verringert die Gesamtkosten und das Gewicht in Automobilen.  

Broadcast-Kommunikation

Jedes der Geräte im Netzwerk verfügt über einen CAN-Controller-Chip und ist daher intelligent. Alle Geräte im Netzwerk sehen alle übertragenen Nachrichten. Jedes Gerät kann entscheiden, ob eine Nachricht relevant ist oder ob sie gefiltert werden soll.  Diese Struktur ermöglicht Änderungen an CAN-Netzwerken mit minimalem Einfluss.  Weitere nicht sendende Knoten können ohne Änderung zum Netzwerk hinzugefügt werden.

Priorität

Jede Nachricht hat eine Priorität. Wenn also zwei Knoten versuchen, gleichzeitig Nachrichten zu senden, wird der mit der höheren Priorität übertragen und der mit der niedrigeren verschoben.  Dieses Schiedsverfahren ist zerstörungsfrei und führt zu einer unterbrechungsfreien Übertragung der Nachricht höchster Priorität.  Dadurch können Netzwerke auch deterministische Zeitvorgaben erfüllen.

Fehlerfunktionen

Die CAN-Spezifikation enthält einen Cyclic Redundancy Code (CRC) zur Fehlerprüfung des Inhalts jedes Frames.  Frames mit Fehlern werden von allen Knoten ignoriert und ein Fehler-Frame kann übertragen werden, um den Fehler an das Netzwerk zu signalisieren.  Globale und lokale Fehler werden vom Controller unterschieden. Wenn zu viele Fehler erkannt werden, können einzelne Knoten die Übertragung von Fehlern beenden oder sich vollständig vom Netzwerk trennen.

CAN wurde ursprünglich für den Automobileinsatz entwickelt, daher ist seine häufigste Anwendung die elektronische Vernetzung im Fahrzeug. Da jedoch andere Branchen in den letzten 20 Jahren die Zuverlässigkeit und Vorteile von CAN erkannt haben, haben sie den Bus für eine Vielzahl von Anwendungen eingesetzt. Bahnanwendungen wie Straßenbahnen, Straßenbahnen, U-Bahnen, Stadtbahnen und Fernzüge enthalten CAN. Sie finden Beispiele für CAN-Geräte, die die Türeinheiten, Bremssteuerungen, Fahrgastzähleinheiten und mehr auf verschiedenen Ebenen der verschiedenen Netzwerke in diesen Fahrzeugen verbinden. CAN hat auch Anwendungen in Flugzeugen mit Flugzustandssensoren, Navigationssystemen und Forschungs-PCs im Cockpit. Darüber hinaus finden Sie CAN-Busse in vielen Luft- und Raumfahrtanwendungen, von der Analyse von Flugdaten bis hin zu Flugzeugmotorsteuerungssystemen wie Kraftstoffsystemen, Pumpen und Linearaktoren. 

Hersteller medizinischer Geräte verwenden CAN als Embedded-Netzwerk in medizinischen Geräten. Tatsächlich verwenden einige Krankenhäuser CAN, um komplette Operationssäle zu verwalten. Krankenhäuser steuern OP-Komponenten wie Lichter, Tische, Kameras, Röntgengeräte und Patientenbetten mit CAN-basierten Systemen. Aufzüge und Fahrtreppen verwenden eingebettete CAN-Netzwerke, und Krankenhäuser verwenden das CANopen-Protokoll, um Aufzugsgeräte wie Panels, Controller, Türen und Lichtschranken miteinander zu verknüpfen und zu steuern. CANopen wird auch in nicht industriellen Anwendungen wie Laborgeräten, Sportkameras, Teleskopen, automatischen Türen und sogar Kaffeemaschinen eingesetzt.

CAN hat verschiedene physikalische Schichten, die Sie verwenden können. Diese physikalischen Schichten klassifizieren bestimmte Aspekte des CAN-Netzwerks, wie elektrische Pegel, Signalisierungsschemata, Kabelimpedanz, maximale Baudraten und mehr. Im Folgenden werden die gebräuchlichsten und am häufigsten verwendeten physikalischen Schichten beschrieben:

High-Speed-/FD-CAN

Hochgeschwindigkeits-CAN ist mit Abstand die häufigste physikalische Schicht. Hochgeschwindigkeits-CAN-Netzwerke sind zweiadrig ausgeführt und ermöglichen die Kommunikation mit Übertragungsraten bis zu 1 Mbit/s. Andere Bezeichnungen für Hochgeschwindigkeits-CAN sind CAN C und ISO 11898-2. Typische Hochgeschwindigkeits-CAN-Geräte umfassen Antiblockiersysteme, Motorsteuerungsmodule und Emissionssysteme.  CAN mit flexibler Datenrate (CAN FD) ist die nächste Generation der Hochgeschwindigkeits-CAN-Kommunikation mit neuen Standards für höhere Datenraten.  NI hat mit den Transceivern TJA1041 und TJA1043 über den NI-XNET Treiber Geschwindigkeiten von bis zu 8 Mbit/s aktiviert.  Da Transceiver-Anbieter für CAN-FD-Geschwindigkeiten qualifiziert sind, aktualisiert NI bei Bedarf unsere Dokumentation.

Low-Speed/Fault-Tolerant CAN Hardware

Low-Speed/fehlertolerante CAN-Netzwerke sind ebenfalls mit zwei Drähten implementiert, können mit Raten von bis zu 125 kbit/s mit Geräten kommunizieren und bieten fehlertolerante Transceiver. Andere Bezeichnungen für Low-Speed/Fault-tolerant CAN sind CAN B und ISO 11898-3. Typische langsame/fehlertolerante Geräte in einem Automobil sind Komfortgeräte. Verbindungen, die durch die Tür eines Fahrzeugs führen müssen, sind langsam/fehlertolerant im Hinblick auf die Belastung, die dem Öffnen und Schließen einer Tür innewohnt. Auch in Situationen, in denen ein fortgeschrittenes Sicherheitsniveau gewünscht wird, wie z. B. bei Bremslichtern, bietet Lowspeed/fehlertolerant CAN eine Lösung.

Eindraht-CAN-Hardware

Einzeldraht-CAN-Schnittstellen können mit Raten von bis zu 33,3 kbit/s (88,3 kbit/s im Hochgeschwindigkeitsmodus) mit Geräten kommunizieren. Andere Bezeichnungen für Single-Wire CAN sind SAE-J2411, CAN A und GMLAN. Typische Eindrahtgeräte in einem Automobil erfordern keine hohe Leistung. Gängige Anwendungen sind Komfortgeräte wie Sitz- und Spiegelversteller.

Per Software wählbare CAN-Hardware

Mit CAN-Hardware von National Instruments können Sie die per Software wählbaren CAN-Schnittstellen für die Verwendung aller geräteeigenen Transceiver (Hochgeschwindigkeits-, Low-Speed-/fehlertolerante oder Single-Wire-CAN) konfigurieren. Multi-Transceiver-Hardware bietet die perfekte Lösung für Anwendungen, die eine Kombination von Kommunikationsstandards erfordern. Bei per Software wählbarer CAN-Hardware können Sie auch Ihren eigenen externen CAN-Transceiver auswählen.

CAN-Programmierung in LabVIEW und anderen Programmiersprachen

NI-XNET Softwaretreiber

NI-XNET Software ist bei Geräten des Typs PCI/PXI-851x und NI 986x enthalten und kann kostenlos auf ni.com heruntergeladen werden. Mit diesem Treiber werden CAN-, LIN- und FlexRay-Anwendungen in NI LabVIEW, NI LabWindows/CVI und C/C++ unter Windows und LabVIEW Real-Time entwickelt. Als Teil der NI-XNET-Plattform eignet sich die Karte NI 851x insbesondere für Anwendungen, bei denen hunderte von FlexRay-Frames und -Signalen in Echtzeit und mit hohen Geschwindigkeiten manipuliert werden müssen, wie etwa bei Hardware-in-the-Loop-Simulationen, Rapid Control Prototyping, Bus-Monitoring, Automatisierungssteuerung usw.

NI-XNET: Eine API, viele Embedded-Netzwerke

Die NI-XNET-Plattform kombiniert eine Reihe leistungsstarker CAN-, LIN- und FlexRay-Schnittstellen mit der NI-XNET-API, einer gemeinsamen Reihe benutzerfreundlicher Funktionen zum Lesen und Schreiben von CAN-, LIN- und FlexRay-Frames und -Signalen.

Höchste Leistung mit weniger Programmierung

NI-XNET Schnittstellen vereinen die Leistung der Low-Level-Mikrocontroller-Programmierung mit der Geschwindigkeit und Leistungsfähigkeit von Windows und LabVIEW Real-Time. Die zum Patent angemeldete gerätegesteuerte DMA-Engine NI-XNET reduziert die Systemlatenz, die bei PC-basierten CAN-Schnittstellen häufig auftritt, von Millisekunden auf Mikrosekunden. Mit Hilfe der Engine kann der geräteeigene Prozessor CAN-Frames und -Signale zwischen Schnittstellen und Anwenderprogrammen austauschen, ohne dass es zu CPU-Interrupts kommt.

Weitere Informationen zu den Vorteilen und Anwendungen von NI-XNET finden Sie im NI-XNET CAN, LIN und FlexRay Platform Overview.

NI-CAN Softwaretreiber

National Instruments enthält NI-CAN Treibersoftware mit allen älteren CAN-Schnittstellen von National Instruments und stellt diese als kostenlosen Software-Download auf ni.com bereit. Bei anderen CAN-Schnittstellen können Sie nur einen kleinen Prozentsatz des Kartenumfangs nutzen, wenn Sie das schlüsselfertige Software-Tool nicht erwerben. Alle CAN-Kartenfunktionen von National Instruments sind jedoch vollständig verfügbar, so dass Sie Ihre eigenen benutzerdefinierten Anwendungen in der Programmiersprache Ihrer Wahl entwickeln können. Der NI-CAN Treiber bietet einfach zu bedienende Funktionen, mit denen Sie schnell und kostengünstig ganze CAN-Anwendungen entwickeln können.

Es gibt zwei APIs mit dem NI-CAN Treiber. Die Frame-API ist die ursprüngliche API für die CAN-Programmierung. In der Frame-API können Sie CAN-Frames senden und empfangen, die Rohdatenbytes enthalten. Ihr Programm muss diese Bytes analysieren und skalieren, um skalierte technische Einheiten zu erhalten. Weitere Informationen zur Programmierung mit der Frame-API finden Sie im Abschnitt "Using the Frame API" im NI CAN Hardware and Software Manual.


NI hat die Kanal-API erstmals in der Treibersoftware NI-CAN 2.0 eingeführt. CAN-Kanäle können mit Hilfe der in Datenbankdateien (*.dbc oder *.ncd) definierten Kanalnamen gelesen und in CAN-Kanäle geschrieben werden. Die Kanal-API bietet folgende Vorteile:

• Programmierung auf hohem Niveau
• Einfach zu verwendende physikalische Einheiten
• Hauptanwendung für einfache CAN-/Datenerfassungssynchronisation
• Möglichkeit zum Einbinden von Vektordatenbankdateien
  

Weitere Informationen zur Programmierung mit der Channel API finden Sie in der Dokumentation zur NI-CAN Channel API.

CAN-Geräte senden Daten in sogenannten Frames über das CAN-Netzwerk. Ein CAN-Frame besteht aus folgenden Abschnitten:

• CAN-Frame - eine gesamte CAN-Übertragung: Arbitrierungs-ID, Datenbytes, Bestätigungsbit usw. Rahmen werden auch als Nachrichten bezeichnet.

• SOF (Start-of-Frame) Bit – zeigt den Beginn einer Nachricht mit einem dominanten (logischen 0) Bit an.

• Schiedsgerichts-ID – Kennzeichnet die Nachricht und gibt die Priorität der Nachricht an. Frames gibt es in zwei Formaten -- Standard, der eine 11-Bit-ID verwendet, und erweitert, der eine 29-Bit-ID verwendet.

• IDE (Identifier Extension) Bit – ermöglicht die Unterscheidung zwischen Standard- und erweiterten Rahmen.

• RTR (Remote Transmission Request) Bit – dient zur Unterscheidung eines Netzwerk-Frames von einem Daten-Frame. Ein dominantes (logisches 0) RTR-Bit zeigt einen Daten-Frame an. Ein rezessives (logisches 1) RTR-Bit zeigt einen Netzwerk-Frame an.

• DLC (Datenlängencode) – gibt die Anzahl der Bytes im Datenfeld an.

• Datenfeld – enthält 0 bis 8 Datenbytes.

• CRC (Cyclic Redundancy Check) – enthält 15-Bit-Code für die zyklische Redundanzprüfung und ein rezessives Trennbit. Das CRC-Feld wird zur Fehlererkennung verwendet.

• ACK (ACKnowledgement) Slot – jeder CAN-Controller, der die Nachricht ordnungsgemäß empfängt, sendet am Ende der Nachricht ein ACK-Bit. Der sendende Knoten prüft, ob das ACK-Bit auf dem Bus vorhanden ist, und versucht die Übertragung erneut, wenn keine Bestätigung erkannt wird. CAN-Schnittstellen der Serie 2 von National Instruments verfügen über den Listen-Only-Modus. Dabei wird die Übertragung eines ACK-Bits durch die Überwachungshardware unterdrückt, um eine Beeinträchtigung des Verhaltens des Busses zu verhindern.

• CAN-Signal – eine einzelne Dateneinheit im CAN-Frame-Datenfeld. CAN-Signale werden auch als Kanäle bezeichnet. Da das Datenfeld bis zu 8 Byte Daten enthalten kann, kann ein CAN-Frame 0 bis 64 Einzelsignale enthalten (bei 64 Kanälen wären sie alle binär).  

CAN-Datenbankdateien sind Textdateien, die Skalierungsinformationen für CAN-Frames und Signaldefinitionen enthalten. NI-XNET erkennt FIBEX-Datenbankdateien (*.xml), Vector-Datenbankdateien (*.dbc) und CAN-Datenbankdateien (*.ncd).

CAN-Datenbanken definieren für jedes Signal Regeln für die Umwandlung in technische Einheiten. Folgende Daten werden in Datenbanken gespeichert:

• Kanalname
• Position (Startbit) und Größe (Bitanzahl) des Kanals innerhalb einer Nachricht
• Byte-Reihenfolge (Intel/Motorola)
• Datentyp (vorzeichenbehaftet, vorzeichenlos und IEEE-Float)
• Skalierung und Einheiten-String
• Range
• Standardwert
• Kommentar

Sie können diese Angaben verwenden, um die "rohen" Rahmenangaben (in der Regel Bytes) einfach in einen "realen" Wert umzuwandeln.  In der folgenden Abbildung sehen Sie ein Beispiel für diese Umwandlung.

^{Abbildung 4:  Alle notwendigen Skalierungsdaten befinden sich in einer Datenbank zur Umwandlung von Frames in Signale.}

CAN-Datenbankdateien können Frame- und Signaldefinitionen für ein gesamtes Fahrzeug enthalten. Jedes Netzwerk hat seine eigene Datenbankdatei. Darüber hinaus sind diese Datenbankdateien herstellerspezifisch und in der Regel vertraulich.

Durch die Verwendung einer Datenbankdatei für viele Frames im CAN-Netzwerk können viele CAN-APIs (wie NI-XNET) die Frame-Informationen automatisch direkt in einen realen Wert umwandeln. Dies vereinfacht die Anwendungsentwicklung, da Sie sich nie um die Roh-Frame-Werte kümmern müssen.

Wie bereits erwähnt, ist CAN ein Peer-to-Peer-Netzwerk. Das heißt, es gibt keinen Master, der steuert, wann einzelne Knoten Zugriff auf Daten auf dem CAN-Bus haben. Wenn ein CAN-Knoten zur Übertragung von Daten bereit ist, prüft er, ob der Bus belegt ist, und schreibt dann einfach einen CAN-Frame in das Netzwerk. Die zu übertragenden CAN-Frames enthalten weder Adressen des sendenden noch der beabsichtigten Empfangsknoten. Stattdessen wird der Frame durch eine im Netzwerk eindeutige Schlichtungs-ID beschriftet. Alle Knoten im CAN-Netzwerk erhalten den CAN-Frame und abhängig von der Arbitrierungs-ID des übertragenen Frames entscheidet jeder CAN-Knoten im Netzwerk, ob er den Frame akzeptiert.

Wenn mehrere Knoten gleichzeitig versuchen, eine Nachricht auf den CAN-Bus zu übertragen, erhält der Knoten mit der höchsten Priorität (niedrigste Arbitrierungs-ID) automatisch Buszugriff. Knoten niedrigerer Priorität müssen warten, bis der Bus verfügbar wird, bevor sie erneut senden. Auf diese Weise können Sie CAN-Netzwerke implementieren, um eine deterministische Kommunikation zwischen CAN-Knoten sicherzustellen.

^{Abbildung 5:  CAN enthält integrierte Priorität für Nachrichten, um Konflikte zu vermeiden.}

NI bietet eine Vielzahl von Hard- und Software-Tools für die Entwicklung von CAN-Anwendungen. NI bietet CAN-Schnittstellen für verschiedene Plattformen wie PCI, PXI, USB, CompactRIO und CompactDAQ (C-Serie). Bei PCI-, PXI- und C-Serien können Sie zwischen Hochgeschwindigkeits-/FD-, Low-Speed-/fehlertoleranten und Single-Wire-Physikalschichten wählen. Für PCI und PXI bietet National Instruments die branchenweit erste per Software wählbare CAN-Schnittstelle, die einen Hochgeschwindigkeits-/FD-, Low-Speed-/fehlertoleranten und Single-Wire-Transceiver auf jeder Karte für jeden Port auf einem einzigen Gerät enthält. So können Sie in Ihrer Software einfach auswählen, welchen Modus Sie verwenden möchten.

Darüber hinaus wird jedes dieser Geräte mit der entsprechenden Treibersoftware geliefert. Im Folgenden wird die Treibersoftware für CAN-Schnittstellen von NI beschrieben. 

Das National Instruments ECU Measurement and Calibration Toolkit erweitert die Entwicklungsumgebungen NI LabVIEW, NI LabWindowsTM/CVI und C/C++ um Funktionen zur Unterstützung von Mess- und Kalibrieranwendungen, die für die Entwicklung und Validierung von elektronischen Steuergeräten (ECUs) eingesetzt werden. Das ECU Measurement and Calibration Toolkit bietet einfach zu bedienende Funktionen basierend auf dem CAN Calibration Protocol (CCP), mit denen ECU-Entwickler, Tester und Ingenieure ihre eigenen benutzerdefinierten Mess- und Kalibrieranwendungen erstellen können.

Für die Verwendung der Marke LabWindows wurde eine Lizenz bei der Microsoft Corporation eingeholt. Windows ist ein in den USA und anderen Ländern eingetragenes Warenzeichen der Microsoft Corporation.