Wie funktioniert I²C? Ganz einfach!

[BlackTM]

Der I²C (Inter-IC Bus) ist ein 1980 von Philips eingeführter Standard. Zur Datenübertragung werden 2 Leitungen und Masse benötigt. Andere Hersteller nennen ihre Version davon aus Markenrechtsgründen TWI (Two Wire Interface). Die Einsatzgebiete sind natürlich überall wo man Daten mithilfe weniger Leitungen aus einfachen Komponenten übertragen möchte. So ist die Produktpalette für I²C sehr vielseitig, von Speicherbausteinen (EEPROM) über Echtzeituhren, Display Treibern bis zum Temperatursensor gibt es so einiges am Halbleitermarkt.

Für weitere Informationen hier [more]weiterlesen.

Der I²C Bus ist ein Master-Slave Bus mit der Möglichkeit mehrere Master an einem Bus zu haben. In der Regel wird der Bus (sofern frei) durch einen Master "gestartet", danach fragt der Master eine Adresse an und der betroffene Slave liest/schreibt die geforderten Daten auf den Bus bzw. in seinen internen Speicher, die übertragenen Daten werden vom Empfänger bestätigt und der Bus wird "gestoppt" oder alternativ wird fortgesetzt. Sollten mehrere Master gleichzeitig eine Anfrage starten wollen, so fährt der Master fort, der die Arbitrierung gewinnt.

Das Protokoll kann recht einfach in Mikrocontrollern implementiert werden. Typische Anwendungen umfassen z.B. im PC (dort der Ableger SMBus) die Temperaturerfassung und -steuerung, Echtzeituhren (RealTimeClock) und die Steuerung von Segmentdisplays. Im automobilen Bereich wird/wurde I²C ebenfalls zur allgemeinen Kommunikation im Infotainmentbereich eingesetzt, wobei diese Bereiche langsam durch CAN oder LIN ersetzt werden (vermutlich aufgrund besserer EMV-Eigenschaften und Kosten).

Die Übertragungsraten sind von anfänglich 100kBit/s über 400kBit/s auf mittlerweile 3,4MBit/s angestiegen. Das stellt jedoch nur das Maximum an einem Bus dar, denn dieser muss sich dem langsamsten Teilnehmer anpassen. Die einzelnen Knoten sind also in der Lage beim Schreiben auf den Bus ihre Geschwindigkeit variabel zu gestalten und müssen keine zeitkritische Datenübertragung gewährleisten, da sie die Übertragung des nächsten Zustands "hinauszögern" können. Damit ist I²C nicht echtzeitfähig, dafür aber recht ressourcenschonend und der internen Verarbeitung von Daten werden keine zeitlichen Limits gesetzt (ausser den für einen Bus vorgesehenen, selbst festgelegten). Man kann natürlich auf die maximale Übertragungsrate kommen, wenn jede beteiligte Komponente die Geschwindigkeit halten kann. Leichte Abweichungen zwischen den Baudraten erzeugen also keine Probleme.

Es gibt 2 Protokollversionen, die erste mit 7 Bit und die zweite mit 10 Bit Adressen. Diese Adressen für Slaves werden vom I²C Gremium vergeben, die letzten 3 Bits sind aber durchaus auch durch den OEM konfigurierbar (ggf. auch programmierbar) um mehrere Busteilnehmer des gleichen Typs an einem Bus betreiben zu können. Bei einem selbstgestalteten Protokoll zwischen Mikrocontrollern (Master + "intelligentere" Slaves) spielt das aber kaum eine Rolle.

Die Länge der in einem "Frame" übertragenen Daten ist quasi unbegrenzt, lediglich Designwünsche wie Reaktionszeit auf z.B. einen Tastendruck oder die Zeit bis Erkennung von Kommunikationsausfällen begrenzt den Zeitbedarf für eine Datenübertragung. Jedes übertragene Datenbyte wird einzeln bestätigt, auf Rückfalltechniken geht die Spezifikation nicht ein, das ist also dem OEM überlassen wie ein Fehler in den Daten zu behandeln ist. Üblicherweise ist wohl eine erneute Übertragung des gesamten Pakets fällig. Höhere Protokollebenen müssen demzufolge auch die Ermittlung von Gültigkeit und Ablehnung von Daten behandeln. Es wäre z.B. möglich nach jedem Schreibbefehl gleich einen Lesebefehl anzuhängen, in dem der Empfänger den Status, eine Checksumme und/oder die geschriebenen Daten zurückgibt, so das diese verglichen werden können.

Wie schon angedeutet besteht I²C aus 2 Leitungen und Masse.
Die zwei Leitungen nennen sich SDA (Data) und SCL (Clock). Der SCL Leitung kommt eine besondere Funktion für die Arbitrierung zu. Die SDA-Leitung darf ihren Status (bis auf die START- und STOP-Kondition) nicht ändern während SCL High ist. Bei beiden Leitungen dominiert der Low-Zustand über den High-Zustand. Je nachdem welcher Knoten Datenbits auf der SDA-Leitung einstellt, hat immer der Empfänger per SCL Vorrang bei der Entscheidung, ob neue Daten gesendet werden dürfen (indem die Leitung noch auf Low gehalten wird, während der Sender sie "released", also auf High gesetzt, hat). Der andere Teilnehmer bemerkt dann bei Zustandswechsel der SCL-Leitung, dass er weitersenden kann.

Es können immer nur zwei Busteilnehmer Daten austauschen und somit auch nur Sender oder Empfänger Daten als ungültig markieren (fehlendes ACK-Bit oder Fehlerbehandlung auf höherer Protokollebene). Eine Gültigkeitsüberwachung durch das gesamte Netzwerk wie bei CAN gibt es somit nicht. Auch wäre I²C anfällig gegen Einstreuungen und zu hohe Kapazität auf den Leitungen, da das Netzwerk durch fest eingebaute Widerstände stabilisiert wird. Eine Obergrenze für Kapazität sind 300pF für ein Subnetzwerk, wodurch die Leitungslänge ohne weitere Massnahmen stark begrenzt ist. Es ist nicht so, das man im Automobilbereich die volle Leitungslänge nutzen wollte oder müsste, diese Angabe lässt allerdings einen Rückschluss auf die Störungssicherheit zu. Übertragungssysteme mit LVDS (Low-Voltage-Differential-Signal) Technologie sind da robuster.

Links
I²C Spezifikation alternativ hier.
Produktübersicht für Logik-ICs

MfG BlackTM

Wünsche, Kritik, Anregungen? Wie geht´s weiter?

[BlackTM]

Du hast von einem Thema rund um Fahrzeugelektronik und Datenübertragung gelesen, das du nicht so recht durchschaut hast und benötigst jetzt ein wenig Grundlage? Etwas in diesem Blog oder im Forum ist dir nicht verständlich und du brauchst eine Erklärung? Du siehst einen Fehler in meinen Beiträgen? Dann her damit!

Ich kann nicht garantieren das alles zu 100% korrekt beantwortet wird, aber ich versuche es einfach und nehme gerne Themen technischer Natur auf. Im Forum ist selten der Rahmen um weiter auszuschweifen, hier geht das.

Weiterhin werde ich das Blog mit Artikeln rund um Datenübertragung füllen, speziell höhere Protokollebenen stehen ja noch aus und lassen viel Spielraum. Auch OBD soll nicht zu kurz kommen - zumindest alles was öffentlich verfügbar ist.

MfG BlackTM

Kleines Glossar der automobilen Datenübertragung

[BlackTM]

Nun, wenige Busse sind vorgestellt, einige werden noch folgen, jetzt fehlt noch so eine kleine Übersicht über diverse Begriffe die hier und da fallen. Deswegen hier das dazu passende Glossar: [more]

Alle Begriffe im Umfeld der automobilen Datenübertragung!

Acknowledge
engl.: Bestätigung. Drückt aus das etwas bestätigt wird oder wurde (z.B. der korrekte Erhalt von Datenpaketen). Es beschreibt schlichtweg die Information, diese kann über eine separate Leitung oder als Informationsfeld übertragen werden.

Bus
So bezeichnet man die meisten automobile Netzwerke. Von Bus spricht man immer dann, wenn sich mehrere Teilnehmer die gleichen Leitungen (Leitungspotentiale) (ein-)teilen.

Buslast
Die Ausnutzung der Busressourcen (Zeit oder Daten pro Zeit) in Prozent. Also die relative Menge an Daten die übertragen werden im Verhältnis zu dem was übertragen werden könnte in einem bestimmten Zeitraum.

CRC
Cyclic Redundancy Check ist ein Verfahren um zu überprüfen ob die Nutzdaten auch fehlerfrei übertragen wurden. Dazu wird mit dem Datenpaket diese CRC-Information übertragen anhand derer überprüft werden kann ob sich im Datenfeld oder dem CRC-Feld etwas unbeabsichtigt (z.B. durch eine Störung) geändert hat. Ist das der Fall werden die Daten verworfen. Hier die Beschreibung.

Feld (im Frame)
ein benannter Bereich mit einer definierten Länge in einem Frame. Welche Information in welchem Feld zu übertragen ist bestimmt das Protokoll.

Frame
englische Bezeichnung für ein sog. Datagramm. So bezeichnet man einen Informationsverbund auf physikalischer Protokollebene (also direkt mit einem Oszilloskop sichtbar). Das enthält alle Informationen die für den reinen Betrieb des Netzwerks benötigt werden und wird in der jeweiligen Spezifikation beschrieben. Man kann das je nach Protokoll meist in Header (Kopfteil), Datenfeld und Kontrollfelder einteilen. Nur das Datenfeld enthält echte Nutzdaten (und ggf. noch Bits für Verfahren die die Störfestigkeit unterstützen; und sofern man das Auftreten eines Frames als Information mal weglässt). Ein Header enthält idR Daten die der oder die Empfänger zunächst auswerten um entscheiden zu können ob das folgende für sie interessant ist. Kontrollfelder steuern und verifizieren die Datenintegrität. Der Aufbau ist von Protokoll zu Protokoll aber immer unterschiedlich und den physikalischen Möglichkeiten angepasst.

Gateway
Ein Netzknoten bzw. Busteilnehmer der zwischen verschiedenen Netzwerken Datenpakete weiterleitet. Diese sind wichtige Bauteile die einerseits die Stabilität erhöhen (da sie das Fahrzeug in mehrere Bereiche aufteilen kann sich ein Ausfall der Kommunikation in einem Bereich nicht auf das ganze Fahrzeug gleichzeitig auswirken) und zudem unabhängig von der Datenübertragungsrate Datenpakete bereitstellen können. Es gibt zudem in jedem automobilen Netzwerk eine theoretische Obergrenze für Teilnehmer und Buslast in einem Netz. Mit Gateways können diese - zwar kaum angetasteten, aber vorhandenen - Grenzen umgangen werden, indem nur relevante Datenpakete weitergeleitet werden. Sie filtern sozusagen.

ID
Identifikation - also eine Nummer die aussagt wie mit dem folgenden umzugehen ist bzw. wie es zu interpretieren ist. Wird meist nur an eine höhere Protokollebene durchgereicht, welche dieses bearbeitet. Das muss vor dem Betrieb des Netzwerks vereinbart sein. Einer ID wird zudem (meistens) ein Name/eine Bezeichnung zugeordnet, damit man noch weiss worüber man redet.

Jitter
Eine zeitliche Abweichung.

Knoten (auch Netzknoten)
Teilnehmer (also Steuergerät mit höherer interner Logik) in einem Netzwerk, der das Protokoll implementiert hat und somit Daten empfangen oder übertragen kann. Je nach Netzauslegung kann er ein Anfangs-, Endpunkt, zentral in der Mitte oder schlichtweg durchgeschleift am Netzwerk angeschlossen sein.

Latenz
Eine Zeitdifferenz zwischen zwei Ereignissen (Events). Das kann z.B. Empfang und Weiterleitung oder Empfang und Reaktion auf ein Datenpaket sein.

LVDS
Low Voltage Differential Signaling - (grob übersetzt) Differentielle Signalisierung bei geringer Spannung
Gemeint ist das auf 2 Leitungen ein jeweils invertiertes Signal übertragen wird. Also Leitung A hat z.B. ein Spannungspotential von +5V und Leitung B zum gleichen Zeitpunkt -5V. Ändert sich der Zustand des Signals kann Leitung A z.B. +2,5V und Leitung B -2,5V einnehmen. Wichtig ist, das sich beide Potentiale um die gleiche Grundspannung (sog. Offset) bewegen und die Leitungen parallel (bzw. verdrillt und parallel) geführt werden. Damit treffen die meisten Störungen immer beide Leitungen, die Differenz zwischen Leitung A und B bleibt aber immer gleich und nur die wird ausgewertet.
Siehe auch die Erklärung auf Wikipedia.

Master
In Netzwerken in denen ein Teilnehmer bestimmt wann andere Teilnehmer was tun sollen nennt man diesen Teilnehmer Master. Das kann sich auch nur auf bestimmte Funktionen beziehen oder auf mehrere Teilnehmer zutreffen (Redundanz). Die interne Logik dieses Teilnehmers übernimmt dann idR die Verarbeitung von Funktionen, während andere nur Information zuliefern oder Steuerbefehle ausführen.

Netzwerk
Ein Zusammenschluss von Teilnehmern.

OSI-Schicht / OSI-Layer / Protokollebene
Open Systems Interconnection
Siehe z.B. die Definition hier.

Overhead
Kontrollinformationen, die zusammen mit den Nutzdaten übertragen werden. Ist nötig, verwendet jedoch Ressourcen des Netzwerks die nicht durch Nutzdaten verwendet werden können. Damit ergibt sich abseits der Datenübertragungsrate ein Nutzdatendurchsatz der eigentlich zählt. Das reine Vorhandensein bestimmter Header kann ebenso als Information dienen, wird aber selten angewendet.

Paket
Ein Paket ist meistens die Summe aller Informationen eines Frames abzüglich der Protokollinformationen die nur die Übertragung sichern (Overhead, darunter z.B. das CRC-Feld). Sozusagen ein gefilterter Teil eines Frames, der weiter verarbeitet wird. Auch dieses kann man wieder in Header und Nutzdaten unterteilen. Höhere Protokollschichten können zudem die Aufteilung sehr langer Informationen auf mehrere Pakete bzw. Frames steuern.

Protokoll
Regelt den Aufbau und die Regeln für das Zusammenspiel von Netzteilnehmern. Es wird in der jeweiligen Spezifikation genau beschrieben.

Ring
Wenn ein Bus kein Anfang und kein Ende hat, sondern eben ringförmig aneinandergereiht ist, spricht man von einem Ring.

Schedule
Eine Tabelle die zeitlich bzw. ereignisorientiert festlegt in welcher Reihenfolge Datenpakete gesendet bzw. angefordert werden.

Slave
Ein Netzteilnehmer der auf Anforderungen des Masters reagiert.

Slot
Bei seriellen Bussen ein definierter Zeitbereich in dem eine Aktion erfolgen soll oder ausbleibt. Oft einfach nur der Zeitbereich in dem ein (Daten-)Feld übertragen wird.

Standby
Ruhezustand eines Netzwerks (ohne aktive Datenübertragung). IdR die häufigste Phase sobald man ein Fahrzeug abgeschlossen parkt, nur gelegentlich unterbrochen durch regelmässige Abfragen und Standardfunktionen (wie z.B. Öffnen des Fahrzeugs).

Stern
Im Gegensatz zu einem Ring die sternförmige Auslegung eines Netzwerks. Zumeist ein Master sitzt in der Mitte und hat ggf. zu jedem anderen eine einzelne Schnittstelle oder sitzt nahe dem Verbindungspunkt der Leitungsabschnitte. Es gibt natürlich auch Mischformen.

Terminierung
Gemeint ist eine (ohmsche) Last (also ein Widerstand) am Anfang bzw. Ende eines Busses. Dieser sorgt dafür das Störungen so wenig Einfluss wie möglich haben kann und das Signal nicht am Ende der Leitung reflektieren.

Erweiterungsvorschläge und Klarstellungen sind herzlich willkommen. Nutzt dazu die Kommentarfunktion!

MfG BlackTM

Wie funktioniert LIN? Ganz einfach!

[BlackTM]

Der LIN-Bus (Local Interconnect Network) stellt eine kostengünstige Möglichkeit dar, Datenübertragung im Fahrzeug per Bus zu realisieren wenn nur wenig Bandbreite benötigt wird und andere Lösungen überdimensioniert sind. Dies ist bei der Realisierung von gemischten Netzen aus Sensoren und Aktoren im Komfortbereich der Fall.

Wer mehr über den LIN-Bus erfahren möchte, kann hier [more]weiterlesen.

Physikalische Auslegung
Der LIN-Bus ist idR sternförmig aufgebaut und verfügt in der Mitte des Sterns über einen Busmaster. Dieser ist zumeist ein Steuergerät das noch über andere Busse verfügt und die Informationen, die es per LIN-Bus erhält, den restlichen Komponenten im Fahrzeug aufbereitet zur Verfügung stellt. Der LIN-Bus ist ein Eindraht-Bus und somit nicht so störsicher wie andere automobile Netze. Die relativ geringe Datenübertragungsrate und geringe Anforderungen an die Flankensteilheit lassen jedoch viel Spielraum.

Die Kommunikation
LIN arbeitet zeitgesteuert bzw. legt der Busmaster fest wann welche Nachricht gesendet wird. Dazu kennt jeder Teilnehmer die ihm zugeordneten Datenpakete und sendet deren Inhalt sobald der Master sie anfordert. Der Master selbst kann ebenso Daten senden. Es ist wichtig das der Masterknoten Kenntniss darüber hat wie lang welches Datenpaket sein kann, damit es nicht zu Timingproblemen kommt. Zumeist ist die Anwendung so, das der Master die Daten der (Sensor-) Knoten einholt, verarbeitet und Kommandos an die (Aktuator-) Knoten gibt. Die Knoten selbst verfügen idR nicht über höhere Verarbeitungslogik, können aber sehr wohl noch über die Ausführung des Kommandos entscheiden. Der LIN-Bus ist standbyfähig durch regelmässige Bestätigungen und so kann ein Knoten das Subnetz "aufwecken".

Ein paar Zahlen
Die maximale Datenübertragungsrate liegt bei 20kBit/s Rohdaten. Darin beinhaltet ist ein Protokolloverhead (applikationsunspezifische Daten im Verhältnis zu allen Daten eines Sendepakets inklusive Nutzdaten) von 35%-81%. Eventuell eingebaute Wartezeiten zwischen Frames nicht eingerechnet.

Kollisionserkennung
Eine echte Kollisionserkennung mit -reaktion gibt es nicht, da der Masterknoten Frames nach einem festen Plan anfordert. Eine Kollision wäre nur möglich wenn ein Knoten längere Datenpakete sendet als der Master es erwarten würde und somit die nächste Anfrage überschreibt. - damit wird ihr eingebautes CRC-Feld ungültig. Diese Datenpakete und alle die darauf aufbauen sind somit nicht mehr nutzbar und verursachen ggf. Fehler bis zur Funktionslosigkeit des Gesamtnetzwerks.

Der Fehlerfall
Der LIN-Standard selbst beinhaltet keine besondere Fehlererkennung ausser das natürlich jeder Knoten den korrekten Erhalt einer Nachricht über die mitgelieferte CRC-Checksumme überprüfen kann. Was er im Fehlerfall zu tun hat ist jedoch Inhalt höherer Protokollschichten. So gibt es also meist ein Datenpaket welches z.B. den Status fehlerhaft empfangener Frames wiedergibt.

Anwendungsfälle
Regen-/Lichtsensor mit integrierter LIN-Schnittstelle
Tastenfelder in Bedienelementen
Intelligente Schrittmotoren z.B. in Aussenspiegeln oder der Leuchtweitenregulierung
Gleichstrommotoren mit Einklemm- und Bauteilschutz z.B. im Fensterheber oder Schiebedach

Weitere Informationsquellen (kleine Auswahl)
Erklärungen auf Wikipedia
Die Homepage dieses Standards: LIN-Subbus.org
Infos zu LIN bei Vector-Informatik

Wie funktioniert CAN? Ganz einfach!

[BlackTM]

Der CAN Standard ist kein Geheimnis, aber dennoch für alle die sich die 73-Seiten CAN2.0 Spezifikation nicht durchlesen wollen kommt hier eine vereinfachte Erklärung.

Für mehr: [more]weiterlesen.

Physikalische Auslegung
Im Fahrzeug wird CAN als Stichleitung oder Ring ausgeführt, bei ersterem droht mit einer Unterbrechung der Kommunikationsausfall, bei letzterem erst ab zwei Unterbrechungen an unterschiedlichen Leitungsabschnitten. Bei beiden Varianten können Kurzschlüsse gegen Plus oder Masse den Bus befristet lahmlegen (der normale Dualwire-CAN kommt damit teilweise klar). Je nach Länge der Busleitungen werden zwei Terminationswiderstände (Abschlusswiderstände) im System benötigt, die können sich im Kabelsatz oder in verschiedenen Steuergeräten befinden.

Mir sind zwei Ausführungen bekannt: der 2-Draht CAN und der 1-Draht CAN. Bei einem 2-Draht-CAN System wird die Spannungsdifferenz der ersten und invertierten zweiten Leitung ermittelt und daraus eine logische 1 oder 0 erzeugt. Beim 1-Draht CAN (iirc nur bei General Motors in Verwendung) ermittelt man die Spannungsdifferenz zur Signalmasse. Prinzipiell sind auf einem 2-Draht-CAN höhere Übertragungsraten möglich und Störungen haben kaum Einfluss, da sie selten nur eine der beiden Datenleitungen betreffen, sondern beide. Damit ändert sich eventuell die Spannung auf beiden Leitungen, die Differenz bleibt aber gleich und das Signal damit unbeeinflusst. Die beiden Leitungen werden zudem verdrillt, damit sie möglichst keine Kapazität erzeugen (was bei 2 parallel liegenden Leitungen vorkommen könnte, sie wirken wie ein Kondensator). Der 1-Draht CAN funktioniert bei geringen Datenübertragungsraten aber ebenfalls zuverlässig.

Die Kommunikation
Ein Knoten sendet ein Paket (auch Frame genannt), alle anderen Knoten empfangen es und bestätigen noch bevor es komplett übertragen wurde den formal korrekten Erhalt (dafür ist der sogenannte Acknowledge-Slot gedacht) oder bei einem Problem verhindern sie die korrekte Übertragung. Auf höheren Protokollebenen entscheidet jeder Busknoten für sich, ob es für ihn relevant ist und ob die Daten gültig bzw. der Situation angemessen sind.

Es gibt also keinen bestimmten Knoten ohne den ein CAN-Netzwerk an sich nicht arbeiten würde, solange mindestens 2 da sind können diese arbeiten. Auf höheren Protokollebenen jedoch sieht es ganz anders aus, würde z.B. ein Steuergerät ausfallen welches für die Übermittlung der Zündschlossstellung zuständig ist müssen andere von einem Standardwert ausgehen, dieser sagt normalerweise, das die Zündung ausgeschalten ist.

Ein paar Zahlen
Übertragungsrate ist bis 1 MBit/s Rohdaten spezifiziert. Der Protokolloverhead beträgt bestenfalls rund 15%, schlechtestenfalls rund 60%.

Kollisionserkennung
Möchten 2 Knoten gleichzeitig senden, entscheidet sich noch während ein Paket übertragen wird ob es vollständig gesendet werden kann oder ob ein anderes Vorrang hat. Den Vorgang nennt man Busarbitrierung (Ressourcenverteilung auf dem Bus), der funktioniert bei CAN so, das jedes Frame eine Identifikation am Anfang des Datenpakets enthält. Diese Identifikation hat eine Länge von 11 oder 29 Bit (CAN 2.0) und da diese vom Anfang her gesendet wird setzen die sendewilligen Busknoten ihren CAN-Ein/Ausgang je nachdem was sie senden möchten der Reihe nach auf 0 oder 1. Eine 0 überschreibt eine 1 und jeder sendende Knoten beobachtet ob der Bus auch tatsächlich den Status hat den er selbst senden wollte. Wird bemerkt das der Bus einen anderen Status hat als vorgesehen, hört der Knoten auf, weiter sein Datenpaket senden zu wollen, hört bis zum Ende des Frames mit und versucht danach erneut sein Paket abzuschicken. Je niedriger die Identifikationszahl (kurz ID) ist, desto höher ist also die Priorität dieses Frames und desto wahrscheinlicher erhalten die darin enthaltenen Daten Vorrang vor niedriger priorisierten Frames.

Der Fehlerfall
Sollte ein Fehler auftreten bei dem andere Knoten oder der sendende Knoten selbst Formfehler in einem Frame entdeckt, so wird das Frame als defektes Frame markiert und nach mehreren dieser defekten Frames geht der sendende Knoten komplett in den passiven Modus. Er sendet dann also nichts mehr bis ein Ereignis eintritt nachdem dieser Zustand erneut überprüft werden soll. Das kann das Aus- und Wiedereinschalten der Zündung oder abklemmen der Batterie sein. Dies tritt zum Beispiel auf wenn systematisch ein Steuergerät aufgrund von zuviel Kapazität in der Leitung oder fehlenden Abschlusswiderständen keine saubere Flanke liefern kann oder wie weiter oben geschrieben Unterbrechungen auf dem Bus vorliegen, die verhindern das andere Knoten ein Frame als korrekt erhalten markieren.

Da es eine serielle Kommunikation ist (Bit für Bit wird übertragen), müssen sich die Knoten synchronisieren, damit immer im richtigen Moment geschrieben bzw. gelesen wird. Dies passiert bei CAN während eine Nachricht gesendet wird, nämlich eine bestimmte Zeit nach einer Bitflanke (Wechsel von 0 auf 1 bzw. 1 auf 0). Zu lange Zeit ohne eine Bitflanke wäre ein Fehler, deshalb wird nach 5 Bits ohne Änderung ein Bitwechsel erzwungen (ausser in 3 bestimmten Bereichen des Frames oder wenn nichts gesendet wird).

Wann ein Knoten überhaupt etwas senden möchte kann durch Eintreten eines Ereignisses (wie zum Beispiel Betätigung einer Taste im Armaturenbrett, Veränderung der Gaspedalstellung, Erkennen eines Hindernisses vom Parkassistent) ausgelöst werden, auf einer festen zeitlichen Basis (was letztlich auch ein Ereignis ist, z.B. pro Sekunde die Stellung des Zündschlossschalters oder alle 10 Millisekunden die Raddrehzahl) erfolgen oder einer Mischung aus beidem (pro Sekunde die Stellung des Zündschlossschalters und wenn sie sich ändert).

Am sinnvollsten werden also wichtige, sich schnell ändernde Informationen in Datenpaketen transportiert die eine niedrige ID haben und unwichtigere mit hohen IDs. Extrem kritische oder sicherheitsrelevante Signale jedoch werden meist hartverdrahtet, darunter zählen Crashsensoren und Zündpillen des Rückhalteystems. Zudem wird auch bei einigen Steuergeräten das geschaltete Plus noch verdrahtet, damit diese abschalten auch wenn das Fahrzeug sich in einem Notmodus ohne CAN-Kommunikation befindet. Diese Rückfallebene (nicht Teil des CAN-Protokolls, aber vorgeschrieben) sorgt dafür, dass mindestens

• das Abblendlicht und
• Rücklicht leuchten,
• die Blinker, die Hupe und die Warnblinkanlage noch funktionieren und
• die Scheibenwischer in geringer Stufe laufen.

• Bremssystem (ABS und ESP),
• Motorelektronik und
• Servolenkung funktionieren eingeschränkt weiter, ausser ihre Betriebsspannung fällt ebenfalls aus.

weitere Informationsquellen (kleine Auswahl davon)
Beschreibung auf Wikipedia
Erklärungen von Vector-Informatik

Falls ihr Anmerkungen, Kritik oder Fragen habt, verwendet die Kommentarfunktion oder schickt mir eine PN.

Datenbusse im Fahrzeug? Ganz einfach!

[BlackTM]

Wer sich schon immer dafür interessierte wie denn nun dieses oder jenes über ein paar wenige Leitungen funktioniert, für den habe ich hier eine kleine Übersicht und einen Vergleich über die üblichsten Busse aufgeschrieben. Ich weiss, es ist ein trockenes Thema, deswegen bin ich für auflockernde Vorschläge und Anregungen sehr dankbar. Öfters wird zudem auch ein wenig missverstanden worüber man sich genau unterhält und deshalb folgen noch Motor-Talk geeignete Artikel zu diesem Thema.

Ich hoffe ihr findet es allgemein hilfreich. Später werden noch einige tiefergehende Artikel zu dem Thema erscheinen. Kommentare und Ideen ausdrücklich erwünscht!

Falls euch das interessiert, könnt ihr hier [more]weiterlesen.

Die Ursprünge Datenbusse bzw. Netzwerke im Fahrzeug zu verwenden liegen darin weniger Leitungen zu benötigen. Das geschieht indem man auf "weniger" Leitungen "mehr" Informationen überträgt, statt pro Leitung eine Information bzw. Signal. Das man damit Kupfer einspart ist ebenso der Fall, wie die Tatsache das weniger Kontakte auch weniger Kontaktprobleme (Korrosion, Wackelkontakte, geweitete Pins, Kabelbruch aufgrund dickerer Kabelstränge, Probleme hochpoliger Stecker) bedeuten.

Nachteil hierbei: ist die Verbindung unterbrochen fallen viele Informationen weg, statt wie bei konventioneller Verdrahtung nur das einzelne Signal der betroffenen Leitung. Inwiefern eine Komponente jedoch ohne ein bestimmtes Signal noch arbeiten kann hängt von ihrer Funktion ab und insofern ist ein kompletter Ausfall meist nicht wesentlich schwerwiegender, da dann ein Notmodus in Kraft tritt.

CAN
Der CAN-Bus ist ausgelegt um bis zu 1 MBit/s (in Abhängigkeit der Leitungslänge) an Rohdaten zu übertragen und unterstützt bis zu 8 Byte an Daten pro Datenpaket. Der Overhead pro Datenpaket beträgt circa zwischen 50% und 85%. Die CAN 2.0 Spezifikation findet man unter anderem hier. Später dazu mehr.

LIN
Der LIN Bus stellt eine günstige Lösung für Datenübertragung mit geringer Bandbreite zwischen Komponenten zur Verfügung. Er erfordert einen Masterbusteilnehmer welcher der Reihe nach die Daten anderer Busknoten anfordert. Mit LIN sind bis zu 20 kBit/s möglich.
Die LIN-Spezifikation ist hier erhältlich.

I²C
I²C ist mittlerweile kaum noch eingesetzt und ist kurz gesagt ein serieller addressierter Bus bzw. Protokoll.
Die I²C Spezifikation ist hier erhältlich.

FlexRay
Flexray erlaubt Datenübertragungsraten von bis zu 10 MBit/s.
Die FlexRay-Spec gibts hier.

MOST
MOST sticht durch die Verwendung optischer Übertragungsmedien (Lichtwellenleiter) heraus. In einem Umfeld das normalerweise kritisch in Sachen Elektromagnetischer Verträglichkeit ist, kann mit MOST kein Problem durch die Art der Datenübertragung entstehen (die Elektronik in einem Steuergerät ist natürlich weiterhin elektromagnetisch beeinflussbar, aber idR geschirmt bzw. so designed das es nicht kritisch wird)

Ältere Protokolle : SAE J1850, ISO 9141 (K-Line)

Es werden weitere Artikel folgen in denen näher auf diese Protokolle eingegangen wird.

MfG BlackTM