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 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 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 Kollisionserkennung Der Fehlerfall 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
weitere Informationsquellen (kleine Auswahl davon) 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 LIN I²C FlexRay MOST Ä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. Pseudonym Warum? 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? 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 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 Ich fahre einen Astra H Caravan 1.9CDTI MT. So, das wars fürs Erste. MfG BlackTM |
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