• Online: 1.135

Mon Nov 12 06:16:34 CET 2007    |    BlackTM    |    Kommentare (6)    |   Stichworte: Bus, Daten, Fahrzeug, LIN, Protokoll, Spezifikation

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


Tue Nov 06 21:53:13 CET 2007    |    BlackTM    |    Kommentare (20)    |   Stichworte: Bus, CAN, Daten, Fahrzeug, Fehler, Notmodus, Protokoll, Spezifikation

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.


Tue Nov 06 21:53:02 CET 2007    |    BlackTM    |    Kommentare (2)    |   Stichworte: Bus, CAN, Daten, Fahrzeug, FlexRay, I²C, LIN, Protokoll, Spezifikation

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


Sat Nov 03 20:51:10 CET 2007    |    BlackTM    |    Kommentare (8)    |   Stichworte: BlackTM, Blog, Foren, Meinung, MfG, Motor-Talk, Vorstellung

Nur wer sich über seine Frage im Klaren ist und diese unmissverständlich äußern kann, kann mit der Antwort auch etwas anfangen. Andernfalls erhält man eine Antwort mit der man so viel oder wenig anfangen kann wie z.B. "42". Der Titel zielt auf das Pseudonym ab, also geht es auch nur um das Pseudonym.

Es geht in diesem Artikel also nicht darum mich selbst vorzustellen, sondern nur das was ich auf Motor-Talk mache.

Falls dich das interessiert, kannst du hier [more]weiterlesen.
So, erster Artikel, was schreibt man da? Tiefschürfendes, Langatmiges? Eine Einleitung bzw. Selbstvorstellung? Lies selbst!

Pseudonym
"BlackTM" ist natürlich nur ein Pseudonym, eines das erstmal nichts mit mir zu tun hat und das möglichst viele nichtssagende Ergebnisse bei der Suche auf google hervorbringt, um das ganze etwas komplizierter zu machen. Wer ich bin, geht auch keinen etwas an, insofern gibt es auch keine Realnamen oder Bilder von mir im öffentlichen Netz - keine die man schriftlich mit diesem Account verknüpfen könnte. Das spielt für meine Beiträge hier auch keinerlei Rolle und eine Antwort darauf gibt es ebenfalls nicht.

Warum?
Zu Motor-Talk kam ich, um herauszufinden welche Probleme denn so im Forum diskutiert werden. Nach einiger Zeit des Mitlesens, fing ich auch an Tipps zu geben wie sich das eine oder andere Problem denn beheben lässt. Man verbringt zunächst zwar viel Zeit damit, erstmal herauszufinden wo der Kern des Problems liegt, darauf hinzuweisen worauf eventuell zu achten ist und Bauteile auszuschliessen, manchmal natürlich auch ob etwas überhaupt ein Problem ist, ist das alles ausgeräumt bleibt aber meistens nicht viel übrig das die Ursache sein könnte. Deshalb funktioniert es aber recht gut und mir macht das nach über 3 Jahren immer noch Spass.

Ich denke es gibt wohl keine einzelne Person die sämtliches Fachwissen in sich vereint. Es gibt also immer jemanden der etwas besser kann, der mehr weiss oder die bessere Idee hat. Ich würde mein Wissen und die Fähigkeit Hinweise auf Motor-Talk zu geben deshalb auch eher als oberflächlich, aber breit verteilt bezeichnen. Unfehlbar bin ich zudem auch nicht, aber das weiss man ja. Man hat mir mal mehr oder weniger vorgeworfen den Showmaster-Effekt auszunutzen. Das stimmt, aber prinzipiell ist es wohl nicht verkehrt nur über die Dinge zu reden von denen man wenigstens ausreichende Kenntnisse und Erfahrungen hat.

Wie?
Alles was ich schreibe, schreibe ich nach bestem Wissen und Gewissen. Ich kopiere auch nicht schnöde Informationen ohne Quellenangabe. Notfalls recherchiere ich kurz etwas, aber gebe es lediglich aus dem Gedächtnis wieder (und ich habe ein verdammt gutes Gedächtnis für bestimmte - für mich interessante - Sachverhalte). Meine Beiträge sind an das Problem und das Fahrzeug meist angepasst. Ich schwächle bei mir unvertrauten Fahrzeugen, aber ein gewisses Schema lässt sich bei allem anwenden, man muss es nur kennen und richtig interpretieren.

Was ich an Motor-Talk gut finde, ist, dass sich jeder einbringen kann so viel und so gut er möchte. Haltbare Argumente zählen immer, egal ob neuer User oder alter Hase. Bei Diskussionen die sich rein um Meinungen drehen, kommt zwar oft nicht mehr heraus als die Meinungen, aber das wird an anderer Stelle durch schnelle und unkomplizierte Hilfestellung ausgeglichen. Auch hier punktet Motor-Talk durch große Benutzerzahlen und die wirklich große Anzahl Unterforen. Deshalb ist es auch möglich ohne Motor-Talk zu verlassen zu Problemen bei anderen Marken zu suchen oder sich die Sichtweise zu diesem oder jenem Argument in diesen Unterforen anzuschauen. Direkter und erfahrener kann eine Beratung vor dem Kauf eines neuen Autos eigentlich nicht sein - vom Kunden für den Kunden. Man kann viel reden, aber wegdiskutieren lassen sich schlechte Erfahrungen mit einem Produkt eben nicht und auf Motor-Talk ist der Platz wo das geht.

Blogs
Das neue Blog-Feature bietet jetzt zudem neue Möglichkeiten mehr Themen unterzubringen und kontrovers zu diskutieren, auch wenn es sich mal nicht um Themen dreht die durch Foren hier abgedeckt werden, oder einfach nur um seine Meinungen und Ansichten zur Diskussion zu stellen. Mein Blog habe ich deswegen "ganz einfach" genannt, weil ich das KISS-Prinzip mag und die einfachste voll funktionierende Umsetzung für die beste halte. Die ist zudem am wenigsten gefährdet falsch weitergegeben zu werden. Wer meine Beiträge kennt mag das für absurd halten, aber letztlich läuft es darauf hinaus möglichst die Details wegzulassen die den Lesern nichts nützen. Aber eines muss man noch dazu sagen - so sehr man sich auch um KISS bemüht, der Teufel steckt wie immer im Detail und ohne Kenntniss dieser Details lässt sich vieles nicht umsetzen. "Einfach" ist es somit meist nur für jemanden der sich letztlich doch damit beschäftigt hat.

Ich werde wohl versuchen in meinem Blog ein wenig Technik und mein Tun auf Motor-Talk zur Diskussion zu stellen, aber mit Hinblick darauf das es möglichst jeder versteht. Ich hoffe das Kommentarfeature wird fleissig genutzt, denn nur durch Rückmeldung weiss man wo man steht. Sollte es also Kritik oder Anmerkungen zu irgendeinem Thema (sei es im Blog oder im Forum) geben, bitte ich darum sie mir mitzuteilen.

restliche Zeit
Nur soviel zu meinem restlichen Leben: wie ich in meinem Profil angegeben habe fotografiere ich wahnsinnig gern und so oft möglich (eher Langzeitbelichtung, Städte, Landschaft, Natur, Technik) und baue Elektronik. Daneben programmiere ich auch in div. Programmiersprachen.

Ich fahre einen Astra H Caravan 1.9CDTI MT.

So, das wars fürs Erste.

MfG BlackTM
P.S.: das "MfG" am Ende fast aller meiner Beiträge ist weder unfreundlich gemeint noch abwertend, es ist schlichtweg ein Kürzel um sich jedes mal das Tippen von "Mit freundlichen Grüßen" zu sparen. Es hat sicher nach über 9000 Beiträgen eine Tastaturneuanschaffung gespart und gehört einfach dazu ;-)