Controller Area Network

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Der CAN-Bus (Controller Area Network) ist ein serielles Bussystem und gehört zu den Feldbussen.

Um die Kabelbäume in Fahrzeugen (bis zu 2 km) zu reduzieren und dadurch Gewicht zu sparen, wurde der CAN-Bus 1983 von Bosch für die Vernetzung von Steuergeräten in Automobilen entwickelt und 1987 zusammen mit Intel vorgestellt. CAN ist als ISO 11898 international standardisiert und definiert die Layer 1 (physikalische Schicht) und 2 (Datensicherungsschicht) im ISO/OSI-Referenzmodell. Die beiden gängigsten Realisierungen der physikalischen Schichten nach ISO 11898-2 (Highspeed-CAN) und ISO 11898-3 (Lowspeed-CAN) unterscheiden sich außer in der Datenrate in weiteren Eigenschaften und sind deshalb nicht zueinander kompatibel.

Funktion[Bearbeiten]

Übertragungsverfahren[Bearbeiten]

Der CAN-Bus arbeitet nach dem CSMA/CR[1] (Carrier Sense Multiple Access / Collision Resolution)-Verfahren (nicht zu verwechseln mit CSMA/CD wie bei Ethernet). In der Literatur wird das Verfahren aus historischen Gründen auch CSMA/CA genannt. Dabei werden Kollisionen beim Buszugriff durch die Arbitrierung oder Bit-Arbitrierung aufgelöst (siehe unten). Die Daten sind NRZ-codiert. Des Weiteren kommt zur Datensicherung die Zyklische Redundanzprüfung (engl. CRC für Cyclic Redundancy Check) zum Einsatz. Zur fortlaufenden Synchronisierung der Busteilnehmer wird Bitstopfen (bit stuffing) verwendet (siehe unten). Der Bus ist entweder mit Kupferleitungen oder über Glasfaser ausgeführt. Der CAN-Bus arbeitet nach dem „Multi-Master-Prinzip“: Mehrere gleichberechtigte Steuergeräte (= Busteilnehmer) sind durch eine topologische Anordnung (siehe unten) miteinander verbunden.

Spannungspegel im Highspeed-CAN-Bus

Im Falle von Kupferleitungen arbeitet der CAN-Bus bei höheren Datenraten (s. u.) mit Differenzsignalen. Die Differenzsignale werden normalerweise mit zwei oder drei Leitungen ausgeführt: CAN_HIGH, CAN_LOW und optional CAN_GND (Masse). CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegenüber einer Ruhespannung von etwa 2,5 V beim Highspeed-CAN. Die Differenzspannung bei einem dominanten Bit beträgt mindestens 2 V. Dadurch können Gleichtaktstörungen unterdrückt werden, da die Differenz gleich bleibt.

Beim Lowspeed-CAN betragen die Ruhespannungen und rezessiven Spannungen 5 V und 0 V, die dominanten Spannungen ca. 1,4 V (CAN_LOW) und 3,6 V (CAN_HIGH). Bei Ausfall einer der beiden Leitungen kann die Spannung der anderen Leitung gegen Masse ausgewertet werden. Bei langsameren Bussen (‚Komfort-Bus‘ z. B. zur Betätigung von Elementen durch den Benutzer) kann ein Eindrahtsystem mit der Karosserie als Masse deshalb reichen. Praktisch wird es meistens doch als Zweidrahtsystem ausgeführt, verwendet aber im Fehlerfall eines Aderbruchs den Eindrahtbetrieb als Rückfallebene, um den Betrieb weiterführen zu können, das nennt sich dann „Limp-Home-Modus“ („nach-Hause-humpeln-Modus“). Um Störungen zu vermeiden, wird es grundsätzlich verdrillt.

Die Übertragung der Daten erfolgt so, dass ein Bit – je nach Zustand – entweder dominant oder rezessiv auf den Busleitungen wirkt. Ein dominantes überschreibt dabei ein rezessives Bit.

Übertragungsrate und Leitungslänge[Bearbeiten]

Es wird zwischen einem Highspeed- und einem Lowspeed-Bus unterschieden. Bei einem Highspeed-Bus beträgt die maximale Datenübertragungsrate 1 Mbit/s, bei Lowspeed 125 kbit/s.

Die maximale (theoretische) Leitungslänge beträgt z. B. bei 1 Mbit/s 40 m, bei 500 kbit/s sind 100 m möglich und bei 125 kbit/s 500 m. Diese Maximalwerte beruhen darauf, dass die Zeit, die ein Signal am Bus anliegt (Bitzeit, bit/Sekunde), umso kürzer ist, je höher die Übertragungsrate ist. Mit zunehmender Leitungslänge steigt jedoch die Zeit, die ein Signal braucht, bis es am anderen Ende des Busses angekommen ist (Ausbreitungsgeschwindigkeit). Daher darf die Zeit, die ein Signal am Bus liegt, nicht kürzer sein als die Zeit, die ein Signal braucht, um sich auszubreiten. Zu beachten ist, dass sich das Signal nicht nur ausbreitet, sondern auch innerhalb der Signalzeit der Empfänger auf den Sender reagieren muss (siehe ACK). Der Sender muss wiederum die eventuelle Buspegeländerung des/der Empfänger mitbekommen (siehe auch Arbitrierung). Deshalb ist die max. Leitungslänge etwas komplexer zu berechnen. Es müssen Verzögerungszeiten auf der Leitung, des Transceivers (Sender und Empfänger), des Controllers (Sender und Empfänger), Oszillatortoleranzen und der gesetzte Abtastzeitpunkt (Sender und Empfänger) berücksichtigt werden. Die Formel zur Berechnung und nähere Informationen sind der Literatur entnehmbar.

Als Busmedium werden nach ISO 11898-2 (High-Speed Medium Access Unit) von 1993 Twisted-Pair-Kabel mit einem Wellenwiderstand von 108–132 Ohm empfohlen. In der derzeit gültigen Ausgabe der ISO 11898-2 aus dem Jahr 2003 ist die Toleranz mit 95–140 Ohm spezifiziert (Abschnitt 7.5.1, Tabelle 9).

Die maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten Bustreiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit gängigen Bausteinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128) Teilnehmer pro Leitung möglich (Erweiterungsmöglichkeit über Repeater oder Bridge).

Topologie[Bearbeiten]

Linearer CAN-Bus

Das CAN-Netzwerk wird als Linienstruktur aufgebaut. Stichleitungen sind in eingeschränktem Umfang zulässig. Auch ein sternförmiger Bus (z. B. bei der Zentralverriegelung im Auto) ist möglich. Diese Varianten haben allerdings im Vergleich zum linienförmigen Bus Nachteile:

  • Der sternförmige Bus wird meist von einem Zentralrechner gesteuert, da diesen alle Informationen passieren müssen, mit der Folge, dass bei einem Ausfall des Zentralrechners keine Informationen weitergeleitet werden können. Beim Ausfall eines einzelnen Steuergeräts funktioniert der Bus weiter.
  • Für Stichleitungen und sternförmige Busarchitektur ist der Leitungswellenwiderstand etwas aufwändiger zu bestimmen. Die Anzahl der Stichleitungen und ihre Gesamtlänge wird durch empirische Richtformeln abgeschätzt. Der lineare Bus hat den Vorteil, dass alle Steuergeräte parallel an einer zentralen Leitung liegen. Nur wenn diese ausfällt, funktioniert der Bus nicht mehr. Diese Topologie wird häufig in Kraftfahrzeugen eingesetzt.

An jedem Leitungsende sollte sich ein Abschlusswiderstand von 120 Ohm befinden. Für einen einzelnen CAN-Bus-Teilnehmer an einer Stichleitung wirkt dies genauso wie ein einzelner 60-Ohm-Widerstand, der am Ort der Abzweigung eingefügt ist. Dieser Wert ist die zentrale Impedanz einer Sternarchitektur.

Objekt-Identifier[Bearbeiten]

Der Objekt-Identifier kennzeichnet den Inhalt der Nachricht, nicht das Gerät. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung und Druck jeweils ein eigener Identifier zugewiesen sein. Es können mehrere Parameter unter einem Identifier vereint sein solange die Summe der Daten die maximal mögliche Länge des Datenfeldes nicht überschreitet. Die Empfänger entscheiden anhand des Identifiers, ob die Nachricht für sie relevant ist oder nicht.

Zudem dient der Objekt-Identifier auch der Priorisierung der Nachrichten.

Die Spezifikation definiert zwei verschiedene Identifier-Formate:

  • 11-Bit-Identifier, auch „Base frame format“ genannt (CAN 2.0A)
  • 29-Bit-Identifier, auch „Extended frame format“ genannt (CAN 2.0B).

Ein Teilnehmer kann Empfänger und Sender von Nachrichten mit beliebig vielen Identifiern sein, aber umgekehrt darf es zu einem Identifier immer nur maximal einen Sender geben, damit die Arbitrierung funktioniert.

Der CAN-Standard fordert, dass eine Implementierung das „Base frame format“ akzeptieren muss, dagegen das „Extended frame format“ akzeptieren kann, es aber zumindest tolerieren muss.

In der Automobilindustrie wird die Liste der Objekt-Identifier, auch Kommunikationsmatrix genannt, streng geheim gehalten.

Arbitrierung, Priorität[Bearbeiten]

Der Buszugriff wird verlustfrei mittels der bitweisen Arbitrierung auf Basis der Identifier der zu sendenden Nachrichten aufgelöst. Dazu überwacht jeder Sender den Bus, während er gerade den Identifier sendet. Senden zwei Teilnehmer gleichzeitig, so überschreibt das erste dominante Bit eines der beiden das entsprechend rezessive des anderen, was dieser erkennt und seinen Übertragungsversuch beendet. Verwenden beide Teilnehmer den gleichen Identifier, wird nicht sofort ein Error-Frame erzeugt (siehe Frame-Aufbau), sondern erst bei einer Kollision innerhalb der restlichen Bits, was durch die Arbitrierung ausgeschlossen sein sollte. Daher empfiehlt der Standard, dass ein Identifier auch nur von maximal einem Teilnehmer verwendet werden soll.

Durch dieses Verfahren ist auch eine Hierarchie der Nachrichten untereinander gegeben. Die Nachricht mit dem niedrigsten Identifier darf immer übertragen werden. Für die Übertragung von zeitkritischen Nachrichten kann also ein Identifier hoher Priorität (= niedrige ID, z. B. 0x001; 0x000 für Netzmanagement – NMT) vergeben werden, um ihnen so Vorrang bei der Übertragung zu gewähren. Dennoch kann selbst bei hochprioren Botschaften der Sendezeitpunkt zeitlich nicht genau vorher bestimmt werden, da gerade in Übertragung befindliche Nachrichten nicht unterbrochen werden können und den Startzeitpunkt einer Sendung so bis zur maximalen Nachrichtenlänge verzögern können (nichtdeterministisches Verhalten). Lediglich die maximale Sendeverzögerung für die höchstpriore Nachricht kann bei bekannter maximaler Nachrichtenlänge errechnet werden. Für niederpriore Nachrichten ist im Allgemeinen keine Aussage über den Sendezeitpunkt möglich.

Sollte ein Teilnehmer kontinuierlich Nachrichten mit einer hohen Priorität versenden, kann dies zur Blockade des Busses führen, da die Nachrichten der anderen Teilnehmer jeweils die Arbitrierung verlieren. Dieses Verhalten wird als Babbling idiot beschrieben. Sollte dieses Verhalten auf einer Fehlfunktion basieren, kann es nur durch zusätzliche Hardware (sogenannte Bus-Guardians) gelöst werden. [2]

Frame-Aufbau[Bearbeiten]

CAN-Daten-Frame mit elektrischen Pegeln ohne Stuffbits
CAN-Datentelegramm im Base Frame Format
CAN-Datentelegramm im Extended Frame Format

Die Kommunikation erfolgt mit Telegrammen. Innerhalb eines Telegramms gibt es Steuerbits und Nutzbits (roter Bereich). Der genormte Aufbau eines solchen Telegrammrahmens wird als Frame bezeichnet.

Es gibt vier verschiedene Arten von Frames:

  • Daten-Frame, dient dem Transport von bis zu 8 Byte an Daten
  • Remote-Frame, dient der Anforderung eines Daten-Frames von einem anderen Teilnehmer
  • Error-Frame, signalisiert allen Teilnehmern eine erkannte Fehlerbedingung in der Übertragung
  • Overload-Frame, dient als Zwangspause zwischen Daten- und Remote-Frames

Daten-Frame[Bearbeiten]

Ein Daten-Frame ist logisch wie folgt aufgebaut:

  • Start of Frame (SOF) = ein dominantes Bit
  • Arbitrierungsfeld, bestehend aus einem Identifier-Segment (11 Bit oder 29+2 Bit) plus einem RTR-Bit (Remote Transmission Request, siehe unten)
  • Kontrollfeld (CTRL) = 6 Bit
    • Identifier Extension (IDE) = 1 Bit
    • reserved = 1 Bit
    • Data Length Code (DLC) = 4bit (Anzahl der Bytes im Datenfeld)
  • Datenfeld (DATA) = 0–64 Bit (in Einheiten von 8 Bit)
  • Prüfsummenfeld (CRC) = 16 Bit (15 Bit CRC plus einem rezessiven CRC-Delimiter-Bit)
  • Bestätigungsfeld (ACK) 2 Bit, bestehend aus einem ACK-Slot (siehe untenstehende Erläuterung) plus einem rezessiven ACK-Delimiter
  • End of Frame (EOF) 7 Bit (rezessiv)
  • Intermission (IFS – Intermission Frame Space) = 3 Bit (= min. Anzahl der Bits, die aufeinanderfolgende Botschaften trennt)

Remote Frame[Bearbeiten]

Ein gesetztes RTR-Bit (Remote Transmission Request) kennzeichnet einen Remote-Frame (rezessiv). Mit Hilfe eines Remote-Frames kann ein Teilnehmer einen anderen auffordern, seine Daten zu senden.

Im Falle eines „Extended Identifiers“ (siehe oben) wird das RTR-Bit durch das SRR-Bit (Substitute Remote Request) ersetzt und ebenfalls rezessiv gesendet. In diesem Fall wird das nachfolgende IDE-Bit ebenfalls rezessiv gesendet, wodurch ein „Extended Identifier“ signalisiert wird. Im Anschluss werden die restlichen 18 Bit des Identifiers und anschließend das eigentliche RTR-Bit gesendet. Das IDE-Bit zählt dabei logisch zum „Arbitrierungsfeld“, wobei das Kontrollfeld aber weiterhin aus 6 Bit besteht.

Die Datenlänge muss entsprechend der zu erwartenden Datenlänge gesetzt werden (Fehlerquelle: Viele Entwickler setzen die Datenlänge = 0 – dies ist falsch; ebenso sind CAN-Controller am Markt, welche RTR-Frames nur mit der Datenlänge 0 senden können). Der Objektidentifier ist derselbe wie der der angeforderten Nachricht.

Error Frame[Bearbeiten]

Der Error Frame besteht aus zwei Feldern:

Das erste Feld wird bestimmt durch die Überlagerung von ERROR FLAGS, die von den verschiedenen Stationen erzeugt werden können.
Das folgende Feld ist der ERROR DELIMITER (8 rezessive Bits) .

Es gibt zwei Typen von Error Flags:

Active Error Flag 
6 dominante Bits, gesendet von einem Knoten, der einen Fehler im Netzwerk entdeckt hat und im Fehler-Status „error active“ ist.
Passive Error Flag 
6 rezessive Bits, gesendet von einem Knoten, der einen Fehler im Netzwerk entdeckt hat und im Fehler-Status „error passive“ ist.

Overload Frame[Bearbeiten]

Der Overload Frame ist eine Zwangspause zwischen Daten- und Remote-Frames.

ACK-Slot[Bearbeiten]

Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten CAN-Frames zu quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pegel an der Stelle des ACK-Slots und überschreibt somit den rezessiven Pegel des Senders. Im Falle einer negativen Quittung (rezessiver Pegel) muss der fehlererkennende Knoten nach dem ACK-Delimiter ein Error-Flag auflegen, damit erstens der Sender vom Übertragungsfehler in Kenntnis gesetzt wird und zweitens um netzweite Datenkonsistenz sicherzustellen. Wird der rezessive Pegel von einem Empfänger durch einen dominanten überschrieben, kann der Absender jedoch nicht davon ausgehen, dass das Telegramm von allen anderen Empfängern erhalten wurde.

Bit Stuffing[Bearbeiten]

CAN-Frame mit Pegeln mit Stuffbits.svg

Bitfolgen mit mehr als fünf gleichen Bits werden im CAN-Protokoll für Steuerungszwecke z.B. „End of Frame“ benutzt. Es dürfen also innerhalb des CAN-Frames nicht mehr als fünf Bits mit dem gleichen Pegel hintereinander vorkommen. Um dies zu verhindern, wird nach fünf Bits mit dem gleichen Pegel ein Bit mit dem inversen Pegel eingefügt. Dieses Bit nennt man „Stopf-Bit“ oder „stuff bit“. Das Bild zeigt den gleichen CAN-Frame vor und nach dem Einfügen von Stopf-Bits. Die Stopfbits sind lila eingefärbt. Bitstopfen (bit stuffing) kann die physikalische Länge eines Frames vergrößern. Beim CAN-Bus sorgt das bit stuffing nach fünf gleichpoligen Bits für das Einfügen eines komplementären Bits (dem sog. Stopfbit) in den Bitstrom. Bit stuffing wirkt auf Start of frame (SOF) bis einschließlich Prüfsummenfeld (CRC) von Daten- sowie Remote-Frames und dient der Nachsynchronisation der Teilnehmer innerhalb eines Frames.

Synchronisierung und Zeitquanten[Bearbeiten]

Ein Bit wird in sogenannten Zeitquanten unterteilt. Sie entsprechen einem Vielfachen des Controllertaktes. In jedem Zeitquantum wird nur einmal abgetastet. Eine Flanke wird erkannt, wenn der Abtastwert vor dem Zeitquantum einen anderen Wert hat als der Wert danach. Die Nachsynchronisierung synchronisiert somit nur auf ein Zeitquantum und nicht auf die Flanke.

Datensicherung[Bearbeiten]

Erkennt ein Empfänger eine Fehlerbedingung, sendet er einen Error-Frame und veranlasst so alle Teilnehmer, den Frame zu verwerfen. Sollten andere Teilnehmer diese Fehlerbedingung nicht erkannt haben, senden sie ihrerseits direkt im Anschluss ein weiteres Error-Frame. Damit wird eine weitere Sicherheitsfunktion des CAN-Protokolls möglich. Um zu vermeiden, dass einzelne Teilnehmer durch irrtümlich erkannte Fehlerbedingungen dauerhaft den Nachrichtentransport blockieren, enthält jeder Teilnehmer Fehlerzähler. Diese Zähler erlauben nach den Regeln der Spezifikation, einen fehlerhaft arbeitenden Teilnehmer in zwei Stufen des Betriebszustands vom Bus zu trennen, wenn er wiederholt Fehler erkennt, welche andere Teilnehmer nicht erkennen oder wiederholt fehlerhafte Frames versendet. Die Zustände nennen sich error active (normal), error passive (Teilnehmer darf nur noch passive – das heißt rezessive – Error-Frames senden) und bus off (Teilnehmer darf nicht mehr senden).

Der Sender wiederholt nach dem Error-Frame seine Datenübertragung. Auch der Sender kann durch die zuvor erwähnten Fehlerzähler vom Bus getrennt werden, wenn die Datenübertragung dauerhaft fehlschlägt. Verschiedene Fehlerfälle führen zu einer unterschiedlich großen Erhöhung des Fehlerzählers.

Standards[Bearbeiten]

  • ISO 11898-1:2003 Road vehicles — Controller area network — Part 1: Data link layer and physical signalling
  • ISO 11898-2:2003 Road vehicles — Controller area network — Part 2: High-speed medium access unit
  • ISO 11898-3:2006 Road vehicles — Controller area network — Part 3: Low-speed, fault-tolerant, medium dependent interface
  • ISO 11898-4:2004 Road vehicles — Controller area network — Part 4: Time-triggered communication
  • ISO 11898-5:2007 Road vehicles — Controller area network — Part 5: High-speed medium access unit with low-power mode
  • ISO/NP 11898-6 Road vehicles — Controller area network — Part 6: High-speed medium access unit with selective wake-up functionality

Weiterentwicklung[Bearbeiten]

2012 wurde von Bosch ein Vorschlag zur Erhöhung der verfügbaren Bandbreite namens CAN FD (Flexible Data Rate) vorgestellt.[3] Dies wird durch Verkürzung der Bit-Zeiten in der Datenphase und Vergrößerung des Datenfeldes auf bis zu 64 Byte erreicht. Insgesamt verspricht man sich zur Zeit durch das „improved CAN“[4] genannte Verfahren einen bis zu 8-fach höheren Datendurchsatz. Durch Änderungen der CRC-Sicherung erhöht sich die Datensicherheit gegenüber dem Classic CAN auf eine Hammingdistanz von 6.

Anwendungsbereiche[Bearbeiten]

CAN-Protokolle haben sich in verschiedenen, vor allem sicherheitsrelevanten Bereichen etabliert, bei denen es auf hohe Datensicherheit ankommt. Beispiele:

  • Automobilindustrie (Vernetzung unterschiedlicher Steuergeräte, Sensoreinheiten und sogar Multimediaeinheiten)
  • Automatisierungstechnik (zeitkritische Sensoren im Feld, Überwachungstechnische Einrichtungen)
  • Aufzugsanlagen (Vernetzung der Steuerung mit verschiedenen Sensoren, Aktoren und Aufzugsanlagen untereinander innerhalb einer Aufzugsgruppe)
  • Medizintechnik (Magnetresonanz- und Computertomographen, Blutgewinnungsmaschinen, Laborgeräte, Elektro-Rollstühle, Herzlungen-Maschinen)[5]
  • Flugzeugtechnik (Vernetzung innerhalb von Kabinen- und Flugführungssystemen)
  • Raumfahrttechnik (vermehrte Verwendung in parallelen Busarchitekturen)
  • Beschallungsanlage (wird für die Steuerung von digitalen Endstufen verwendet)
  • Schienenfahrzeuge
  • Schiffbau (Die DGzRS lässt in die neue Generation ihrer Seenotrettungskreuzer Bus-Systeme einbauen.)

Höhere Protokolle[Bearbeiten]

CANopen[Bearbeiten]

CANopen ist ein auf CAN basierendes Schicht-7-Kommunikationsprotokoll, welches anfänglich in der Automatisierungstechnik verwendet wurde, mittlerweile aber vorwiegend in Embedded Systemen eingesetzt wird.

CANopen wurde vorwiegend von deutschen klein- und mittelständischen Firmen initiiert und im Rahmen eines ESPRIT-Projektes unter Leitung von Bosch erarbeitet. Seit 1995 wird es von der CAN in Automation gepflegt und ist inzwischen als Europäische Norm EN 50325-4 standardisiert. Der Einsatz erfolgt vorwiegend in Europa, gefolgt von Asien.

DeviceNet[Bearbeiten]

DeviceNet ist ein auf CAN basierendes Schicht-7-Kommunikationsprotokoll, welches hauptsächlich in der Automatisierungstechnik verwendet wird.

DeviceNet ist vorwiegend in Amerika verbreitet. Es wurde von Allen-Bradley (gehört zu Rockwell Automation) entwickelt und später als offener Standard an die ODVA (Open DeviceNet Vendor Association) übergeben.

J1939 sowie die Erweiterungen NMEA2000 und ISOBUS[Bearbeiten]

J1939 ist ein auf CAN basierendes Protokoll im Nutzfahrzeugbereich. Es wird von der Society of Automotive Engineers (SAE) gepflegt. Eine Einführung in J1939 findet sich in Application Note Introduction J1939[6]

NMEA 2000 ist eine Erweiterung von SAE J1939 für den maritimen Bereich. Das Protokoll der NMEA-Organisation breitet sich zunehmend aus. Vorgänger ist NMEA 0183.

In der Landwirtschaft und Kommunaltechnik kommt der ISOBUS (ISO11783), der eine Erweiterung des J1939 darstellt, zur Steuerung und Überwachung von Anbaugeräten zum Einsatz.

CleANopen[Bearbeiten]

Eine Arbeitsgruppe der CAN in Automation, die CANopen Special Interest Group (SIG) „Municipal Vehicles“, entwickelt das CANopen-Anwendungsprofil für Abfallsammelfahrzeuge (CleANopen).

CANopen-Lift[Bearbeiten]

Eine in 2001 gegründete Arbeitsgruppe der CAN in Automation, die CANopen Special Interest Group (SIG) „Lift Control“, entwickelt das CANopen-Anwendungsprofil (CANopen CiA-417) für Aufzüge (CANopen-Lift). Die erste Version wurde im Sommer 2003 veröffentlicht. Die Version 2.0 wurde als Draft-Standard verabschiedet und steht frei zur Verfügung. Aktuell (2013) wird an der Version 2.2 gearbeitet.

SafetyBUS p[Bearbeiten]

SafetyBUS p ist ein auf CAN basierendes sicheres Kommunikationsprotokoll, welches hauptsächlich in der Automatisierungstechnik zur Übertragung sicherheitsgerichteter Daten verwendet wird. Alle Busteilnehmer sind 2- oder sogar 3-kanalig aufgebaut und prüfen die Datenintegrität. Das Übertragungsmedium selbst ist nicht sicher, die Sicherheit wird durch das SafetyBUS p eigene Datenprotokoll erreicht. Der SafetyBUS p kann bis SIL3 eingesetzt werden.

TTCAN[Bearbeiten]

Time-Triggered Communication on CAN setzt auf dem CAN-Bus auf und ermöglicht über höhere Protokollebenen eine Echtzeitsteuerung.

CANaerospace[Bearbeiten]

CANaerospace ist ein Open-Source-Kommunikationsprotokoll, welches 1998 insbesondere für den Einsatz in der Luftfahrt mit ihren besonderen Zuverlässigkeits- und Leistungsanforderungen konzipiert wurde. Im Jahr 2000 hat die amerikanische NASA CANaerospace als eigenen Standard übernommen. CANaerospace wird in zahlreichen Forschungsflugzeugen weltweit eingesetzt und hat sich als De-facto-Standard in der militärischen Flugsimulationstechnik etabliert.

ARINC 825[Bearbeiten]

ARINC 825 ist ein internationaler Luftfahrt-Kommunikationsstandard, welcher in einer Technischen Arbeitsgruppe (bestehend aus mehreren Luftfahrtunternehmen, darunter Boeing und Airbus) auf der Basis von CANaerospace entwickelt wurde.

EnergyBus[Bearbeiten]

EnergyBus-Logo

EnergyBus ist ein Kommunikations- und Energieübertragungs-Bus und dazugehöriges Steckersystem für Leicht-Elektrofahrzeuge wie Pedelecs und E-Bikes. EnergyBus wird von einem eingetragenen Verein, dem EnergyBus e.V. mit Sitz in Tanna gemeinsam mit dem CAN in Automation e.V. spezifiziert. Mitglieder sind sowohl Einzelpersonen wie auch Hersteller von Steckern, Batterien, Steuerungen und Antriebseinheiten (darunter Bosch, Panasonic, Sanyo, Deutsche Bahn AG, Philips und Varta).[7]

Das Kommunikationsprotokoll ist im CANopen-Applikationsprofil 454 "energy management systems" definiert.

FireCAN[Bearbeiten]

FireCAN wurde durch Zusammenarbeit österreichischer und deutscher Feuerwehraufbauhersteller im Jahr 2006 gegründet und ist mittlerweile als Norm DIN 14700 vorhanden. Ursprünglich wurde FireCAN als freie Übereinkunft der wesentlichen am Markt befindlichen Hersteller, die redaktionelle Betreuung der gemeinsamen Spezifikation wird dabei durch die Firma Rosenbauer ausgeübt. Die Vorstellung erfolgte im Zuge der DIN-Sitzung des Ausschusses NA 031-02-02 AA „Elektrische Betriebsmittel“ am 29. Oktober 2009 in Berlin. Diese Datenbusfestlegung basiert auf einem vereinfachten CANopen-Standard und regelt sowohl die physikalischen Eigenschaften (Stecker, Leitungen, Pinning), die Art und Anzahl der Teilnehmer, sowie die verwendeten Datenformate und Dateninhalte. Als wesentlicher Vorgänger ist der in der Landwirtschaft erfolgreich eingeführte ISOBUS zu verstehen.[8]

Unified Diagnostic Services[Bearbeiten]

In Personenkraftwagen sehr verbreitet ist mittlerweile Unified Diagnostic Services gemäß der ISO 14229. In älteren Modellen verwendeten viele Hersteller eigene Standards, oft basierend auf der letztlich nicht standardisierten Norm für KWP on CAN (Normentwurf ISO/DIS 15765).

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

  • Wolfhard Lawrenz (Hrsg.): CAN Controller Area Network – Grundlagen und Praxis., 5. Auflage, VDE-Verlag, 2011, ISBN 978-3-8007-3332-3.
  • Konrad Etschberger (Hrsg.): CAN Controller Area Network – Grundlagen, Protokolle, Bausteine, Anwendungen. Hanser, 1994, ISBN 3-446-19431-2.
  • Horst Engels : CAN-Bus – Technik einfach, anschaulich und praxisnah vorgestellt. Franzis, 2002, ISBN 3-7723-5146-8.
  • Werner Zimmermann und Ralf Schmidgall: Bussysteme in der Fahrzeugtechnik – Protokolle, Standards und Softwarearchitektur. 5. Auflage, Springer Vieweg, 2014, ISBN 978-3-658-02418-5.
  • Kai Borgeest: Elektronik in der Fahrzeugtechnik. 3. Auflage, Springer-Vieweg, Wiesbaden, 2013, ISBN 978-3-8348-1642-9.

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. http://www.edn.com/archives/1998/081798/17df2.htm
  2. Giuseppe Buja, Juan R. Pimentel, Alberto Zuccollo: Overcoming Babbling-Idiot Failures in the FlexCAN Architecture. A Simple Bus-Guardian. In: Emerging Technologies and Factory Automation. 2005, ISBN 0-7803-9401-1, S. 461–468 (PDF-Datei).
  3. 13. iCC Conference Paper (PDF; 215 KiB)
  4. CAN FD Specification Version 1.0 (PDF; 313 KiB)
  5. http://www.can-cia.org/index.php?id=936
  6. Eine Protokolleinführung: Application Note Introduction J1939 (PDF; 284 kB)
  7. Liste der EnergyBus Mitglieder
  8. Webseite FireCAN