Diskussion:Controller Area Network

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 180 Tage zurückliegt und die mindestens 3 signierte Beiträge enthalten.

Archiv

Archiv

Wie wird ein Archiv angelegt?

Maximale Teilnehmeranzahl

Hi. Wieviele Teilnehmer unterstützt das System maximal?

Gruss (nicht signierter Beitrag von 193.171.119.134 (Diskussion | Beiträge) 11:57, 21. Jun. 2005 (CEST))

CAN sieht keine Limitierung der Anzahl der Teilnehmer vor. Die Grenzen setzen heutzutage die Physik bei der Implementierung der CAN-Transceiver. Alte Transceiver unterstützen teilweise nur 32 Teilnehmer, neuere 64 oder gar 110. Angeblich hat Steve von TI auch ein System mit über 200 Teilnehmern laufen. Eine andere Möglichkeit, die Anzahl der Teilnehmer zu höhen, ist die Verwendung von Repeatern, um die Signale zu regenerieren. Allerdings haben diese den Nachteil, daß sie wie Verzögerungselemente, also wie ein langes Kabel wirken.

MisterTS 20:34, 25. Aug 2005 (CEST)

Entwicklungsstart

Die Angaben über das Jahr in dem bei Bosch die Entwicklung des CAN-Busses begannen gehen relativ stark auseinander. Viele Quellen geben 1981 an aber auch viele 1983.

Kennt jemand jemanden bei Bosch ?!? (nicht signierter Beitrag von Ulf Wetzker (Diskussion | Beiträge) 18:21, 8. Jan. 2005 (CET))

Ich kenne einige aus dem ursprünglichen Entwicklungsteam.

- Uwe Kiencke war der Projektleiter, der 1983 das Projekt Bosch-intern gestartet hat.

- Im Februar 1986 auf der SAE-Konferenz in Detroit wurde CAN erstmal der Öffentlichkeit vorgestellt. (nicht signierter Beitrag von MisterTS (Diskussion | Beiträge) 15:30, 31. Jan. 2005 (CET))

Anwendungsgebiete

Was wird denn überhaupt über den CAN-Bus übertragen? Zum Netzwerkspielen unter den Mitfahrern wird er ja nicht verwendet. Die Rubrik "Zweck des CAN" fehlt also noch komplett. Danke, --Abdull 18:35, 19. Apr 2005 (CEST)

In den Dokumenten auf der CAN Homepage werden für den Automobilbereich vier Bereiche genannt:

• Komponenten des Antriebsstrangs und des Fahrwerks
• Karosserie- und Komfortkomponenten
• Komponenten der mobilen Kommunikation
• Diagnose

Omit 22:56, 25. Mai 2005 (CEST)

Vergleich CAN-FlexRay

Hi, hat einer von euch eine gute Seite gefunden, in der die Unterschiede zwischen CAN und FlexRay beleuchtet werden? --Marc Höper 11:24, 8 Nov. 2005 (CET)

Der Hauptunterschied ist meines Erachtens die Sicherheit mit der Nachrichten übertragen werden sowie als wichtigste Eigenschaft der Deterministismus von Flexray. (nicht signierter Beitrag von 80.134.41.225 (Diskussion | Beiträge) 20:21, 19. Jan. 2006 (CET))

Zwei-Leiter CAN-Bus

HI aus welchen gründen braucht man beim Can Bus zwei Leiter sprich CAN H und CAN L.Und welche möglichen Fehler können im Systhem auftreten und wie werden sie erkannt.

Danke (nicht signierter Beitrag von 84.154.204.187 (Diskussion | Beiträge) 21:00, 26. Jan. 2006 (CET))

CAN ist ein sog. Differenzbus, das bedeutet die Differenz (und nicht der Absolutwert) der beiden Spannungen entscheidet, ob ein Pegel als dominant oder rezessiv erkannt wird. Der Vorteil liegt darin, dass sich (z.B. in einem Kfz durchaus übliche) störende Impulse (Stichwort EMV) auf beide Leitungen gleich/ähnlich auswirken und damit die Differenz erhalten bleibt.

Zusätzlich gibt es noch die Möglichkeit, FT-CAN (Fault-tolerant) Transceiver einzusetzen: diese können die Kommunikation auch im Falle des Ausfall einer Leitung aufrechterhalten (allerdings meines Wissens nach weniger verbreitet).

Fehlerfälle: MASSIG und beliebig viele  ;-) Ich würde ein gutes Buch wie z.B. den Etschberger empfehlen. Für tiefergehende Theorie und Anwendung dann den Lawrenz. (nicht signierter Beitrag von 80.134.19.66 (Diskussion | Beiträge) 20:53, 30. Jan. 2006 (CET))

höhere Protokolle

Vorschlag zur Wikifizierung weiterer Abschnitte:

• OSEK

ramtam 22:47, 21. Aug. 2006 (CET)

Theoretisch wäre ich dafür. Praktisch habe ich wenig Wissen dazu. Ich weiss nur, dass es OSEK/OS gibt, welches eine are von Echtzeit-Betriebssystem bescheibt. Es ist von allen(?) deutschen Automobilherstellen implementiert. Dann gibt es OSEK/NM, welches ein Netzwerkmansgement beschreibt (so wie ich es aus dem Artikel heute gelöscht habe, da es mit CAN selbst nichts zu tun hat) Denn theoretisch könnte man OSEK/NM auch auf andere Systeme abbilden, auch wenn es zurzeit nur eine Abbildung nach CAN gibt. AFAIK ist OSEK/NM zurzeit von Mercedes und vom VW-Konzern (VW + Audi) implementiert. Dann weiss ich noch von OSEK/COM welches eine Art von Kommunikation beschreibt. Leider hat die Automobilindustrie hier die Standardiserung verschlafen (vllt. auch gewollt). Denn AFAIK ist es nur von VW implementiert und dies auch wieder herstellerspezifisch (dieses Wissen mag falsch sein). Laut der OSEK-Webseite umfasst der Standard noch mehr, aber das kenne ich nicht. --MisterTS 00:20, 22. Aug 2006 (CEST)

Netzwerkmanagement

Ein Abschnitt zum Netzwerk-Management könnte die State-Machine des CAN Core erklären (Init-Phase, Error Active, Error Passive, etc.). ramtam 22:47, 21. Aug. 2006 (CET)

Das ist aber eigentlich kein Netzwerkmanagement. Vielleicht eine Art von dezentralem Netzwerkmanagement, jeder Teilnahmer steuert sich selbst, abhängig davon wieviele Fehler er für sich selbst erkannt hat. Eigentlich ist es nur eine Statusmaschine jedes Teilnehmers selbst. --MisterTS 00:13, 22. Aug 2006 (CEST)

ACK und Leitungslänge?

Hallo. In dem Abschnitt über die Leitungslänge steht, dass ein Knoten innerhalb der Bitzeit auf den angelegten Signalpegel reagieren können muss und man wird auf ACK verwiesen. Das ACK ist doch ein Bit innerhalb des CAN-Frames und muss nicht bei jedem Bit gesetzt werden. Was hat also das ACK mit der Leitungslänge zu tun? Also wenn mich nicht alles täuscht ist das was da steht falsch. Wenn ein Empfänger auf einen Sender reagieren muss, dann reicht es doch im nächsten Bit einen Errorframe zu beginnen. Korrigiert mich, aber innerhalb einer Bitzeit muss doch kein Sender schon reagieren können, sondern erst im nächsten Bit. Nautsch 09:18, 24. Jan. 2007 (CET)

dass ist schon richtig, so wie es im Artikel steht, du interpretierst es nur falsch: "Wenn du am nächsten Tag eine Prüfung schreibst, hast du einen Tag Zeit zu lernen --87.163.242.18 18:39, 23. Mär. 2007 (CET)

Standards

Ich finde, daß hier (freie Enzyklopädie) keine Links platziert werden sollten, die auf kostenpflichtige Informationsquellen verweisen:

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

Dies untergräbt meiner Ansicht nach die GNU-Philosophie. (nicht signierter Beitrag von 87.193.34.39 (Diskussion | Beiträge) 23:42, 8. Okt. 2007 (CEST))

CAN-Bus in Avionik-Systemen?

Soweit mir bekannt, wird der CAN-Bus im Flugzeug nur in weniger wichtigen Systemen, aber nicht in Avionik-Systemen eingesetzt. Die Zulassungsbehörden betrachten den CAN-Bus überaus kritisch, weil er eben nicht als sicher gilt. Bitte Quelle angeben!

Dieser Abschnitt kann archiviert werden. JuergenKlueser 08:06, 16. Nov. 2011 (CET)

"CAN wird in der Luftfahrt seit etwa 1990 verwendet. .... LBA...bestätigt erstmals dessen Eignung für den Einsatz in Luftfahrzeugen" CAN Controller Area Network, 5.Auflage W. Lawrenz, N.Obermöller(Hrsg.) Seite 333ff (nicht signierter Beitrag von 194.25.249.126 (Diskussion) 15:51, 30. Jun. 2014 (CEST))

CAN Frame Darstellung

Moin, müsste es in der bildlichen Darstellung des CAN Frame für das Datenfeld nicht heißen "0..63" (bits) ? Gruß --Borei (09:37, 31. Aug. 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Wenn Du es mit den anderen Feldern vergleichst, könnten das statt Bitnummern Bitanzahlen (im jeweiligen Feld) sein, und die können tatsächlich zwischen 0 und 64 (8 volle Bytes) liegen. --PeterFrankfurt 02:30, 1. Sep. 2010 (CEST)

FlexCAN

Wäre für FlexCAN einen eigenen Artikel gerechtfertigt, oder sollte das besser in einem eigenen Absatz im Artikel angesprochen werden? -- Sportler74 15:07, 4. Jan. 2011 (CET)

Spaßvogel!

Der erste Satz ruft bei mir Heiterkeit hervor, dort heißt es:

"Um die Kabelbäume (bis zu 2 km pro Fahrzeug) 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."

Wenn man die Elektrik moderner Wagen sieht, dann kommt zu den alten Leitungen (+12V, GND, Blinker, Bremse, Schalter, Licht ...) jetzt pauschal noch das Bussystem hinzu. Die Leitungslänge verdoppelte sich seit Einführung von Bussystemen! Bei Daimler sind es inzwischen bis zu 4,5 km verlegte Kabel, wenn ich richtig erinnere. Ich würde deshalb empfehlen, den ersten Satz zu streichen und erst mal darüber nachzudenken, welchen Sinn der CAN-Bus im Auto überhaupt spielt. Je länger ich darüber nachdenke, desto mehr befällt mich ein Gefühl völligen Unwohlseins. Ansonsten könnte man den ersten Satz natürlich auch wahrheitsgemäß abwandeln:

"Um die Kabelbäume (um bis zu 2,5 km pro Fahrzeug) zu verlängern und dadurch Kupferverbrauch, Kosten und Gewicht zu erhöhen, wurde der CAN-Bus 1983 von Bosch für die Vernetzung von Steuergeräten in Automobilen entwickelt und 1987 zusammen mit Intel vorgestellt."

Heinzelmann 16:19, 30. Jan. 2012 (CET)

Je nun, die Kabelbäume würden aber mindestens armdick werden, wenn man wie in alten Zeiten eine Ader je Signal von ganz hinten nach ganz vorn durchschleifen würde. Bei teilweise über 50 Steuergeräten im Auto hat man die Kabelanzahl somit noch im Rahmen gehalten, wenn sie auch absolut ein bisschen gestiegen ist. --PeterFrankfurt 02:59, 31. Jan. 2012 (CET)

Pegelangabe

Den Satz "CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegen Masse" halte ich für unglücklich formuliert, da der Eindruck entstehen könnte, CAN-L wäre einfach CAN-H mit geändertem Vorzeichen. Also CAN-H "+5V" -> CAN-L "-5V". Eine umfangreicherere Erklärung wäre sicher angebracht. (nicht signierter Beitrag von 62.154.182.130 (Diskussion) 14:37, 17. Apr. 2012 (CEST))

CAN Flexible Datarate

Der Artikel muss noch um CAN FD erweitert werden und entsprechend die Bezeichnungen der reservierten Bits geändert werden. CAN FD wurde von Bosch 2011 vorgestellt. Paper (nicht signierter Beitrag von 188.98.70.180 (Diskussion) 17:00, 29. Nov. 2012 (CET))

Ein kurze Einführung mit dem Link zur Spezifikation von Bosch habe ich hinzugefügt. --Plupp (Diskussion) 14:41, 11. Aug. 2013 (CEST)

Höhere Protokolle

Unified Diagnostic Services ist kein Protokoll das direkt auf CAN aufsetzt. Hier fehlt der Hinweis auf das Transportprotokoll ISO-TP / ISO 15765-2 --Dirk B. (Diskussion) 10:04, 9. Jul. 2014 (CEST)

frame aufbau

"Daten-Frame, dient dem Transport von bis zu 8 Byte an Daten"

muss das nicht 8 bit heißen laut der abbildung? (nicht signierter Beitrag von 193.17.22.2 (Diskussion) 10:09, 31. Mär. 2016 (CEST))

Du hast "bis zu" überlesen und die nachfolgenden Details zum Datenframe ignoriert. Den Daten geht das im Bild gelb markierte Feld DLC voraus, das im Bild den Wert 1 hat, 1 Byte zu 8 Bit. --Rainald62 (Diskussion) 23:54, 1. Apr. 2016 (CEST)

Stichleitung /stub falsch verwendet

in diesem artikel ist die bezeichnung "stichleitung" falsch.

stichleitungen bezeichnet eine leitung zur impedanzanpassung, wenn aufgrund beispielsweise steckverbinder die übertragungsleitung an dieser stelle von der leitungsimedanz abweicht. mit hilfe der stichleitung (länge der stichleitung und abschluss) lässt sich diese impedanzstörung reduzieren.

das hat nichts mit teilnehmer in einem can-bus zu tun! (nicht signierter Beitrag von 193.17.22.2 (Diskussion) 13:52, 31. Mär. 2016 (CEST))

Der Fehler liegt beim Zielartikel, vgl. [https://www.google.de/search?q=Stichleitung+bus+topologie&tbm=bks} (der Begriff wird im Kontext Bus-Topologie in der leitungstheoretischen Bedeutung verwendet). --Rainald62 (Diskussion) 20:58, 1. Apr. 2016 (CEST)

ACK-Slot

In dem Abschnitt zum ACK-Slot steht, dass ein Empfänger, der einen fehlerhaften Frame empfängt, nach dem ACK-Delimiter ein Error-Flag auf den Bus legen soll. Das erscheint mir falsch. Was hier gemeint sein dürfte ist ein Error Frame (nicht Flag). Inbesondere gibt es das Problem, dass ein Bus Teilnehmer einen gültigen Frame sieht, während die anderen Teilnehmer dies nicht tun. Es wird in diesem Fall trotzdem ein positives ACK geben und der englische Artikel erwähnt explizit, dass der Absender _nicht_ feststellen können, ob alle Empfänger die Nachricht korrekt erhalten haben. Ganz besonders interessieren würde mich, was der Sender macht wenn denn nun ein Empfänger einen Error Frame verschickt. Wird das CAN Paket dann erneut gesendet? Wenn nein, wie soll dann die im deutschen Artikel erwähnte Datenkonsistenz hergestellt werden? Was ist mit Datenkonsistenz überhaupt gemeint? --skoehler (Diskussion) 11:21, 13. Dez. 2019 (CET)

Abbildung und Text widersprüchlich

Im Abschnitt "Übertragungsverfahren" ist die Erklärung "Die logische 1 ist rezessiv (Wired-AND). Die Daten sind NRZ-codiert..." widersprüchlich zur Abbildung. Es handelt sich dementsprechend um NRZI-Codierung und eher Wired-OR.

Bericht: CAN-Bus-Hack Altes Nokia Handy unterstützt Auto Diebstahl per Klick

https://www.heise.de/news/CAN-Bus-Hack-Altes-Nokia-Handy-unterstuetzt-Auto-Diebstahl-per-Klick-8976444.html --2A02:908:898:9780:ABB1:F932:5FC8:F99E 12:35, 23. Apr. 2023 (CEST)

Ja? Es gibt ständig solche Berichte. Bereits Ende der 1990er Haben Forscher per Telefonanruf es geschafft ein Fahrzeug zu übernehmen. Wikipedia (und auch die Diskussionsseite ist jetzt keine Stelle, um alle diese Berichte zu sammeln. --MisterTS (Diskussion) 14:44, 24. Apr. 2023 (CEST)

Funktion Übertragungsverfahren ist doch falsch?

"Bei höheren Datenraten (Highspeed-CAN) ist der Spannungshub zwischen den beiden Zuständen relativ gering: Im rezessiven Ruhezustand ist die Differenzspannung null (beide Adern etwa 2,5 V über Masse), im dominanten Zustand beträgt sie mindestens 2 V (CAN_HIGH > 3,5 V, CAN_LOW < 1,5 V)."

Also wenn die kleine Spannung dominant ist, kann sie nicht "mindesten 2V" betragen.

"....Spannungshub von 5 V zum Einsatz, indem die rezessiven Ruhepegel auf 5 V (CAN_LOW) und 0 V (CAN_HIGH) gelegt sind. "

Wenn im folgenden Absatz nun von CAN_LOW =5V gesprochen wird soll der Satz wohl sagen, daß High und Low invertiert werden. Allerdings wind vorher von einem rezessiven Ruhezustand von 2,5V gesprochen. Das ist so gegeneinander, daß ich um folgendes Bitten würde:

Bitte beschreibt die folgenden verwendeten Kurzformen:

CAN_H; CAN_HIGH;

CAN_L; CAN_LOW

Rezessiver Ruhestand; Ruhespannung; Spannungshub

Und unbedingt immer wenn Wir Formeln oder Bilder verwendet.

Auch das Bild ist sehr ungeschickt, da es sich ja nur im eine "Sonderform" handelt. Zum einen sollte ein Bild alle Versionen beschreiben. Und es wurde bei Highspeed von einem Spannungshub von 5V gesprochen. Der Müßte da auch irgendwie zu sehen sein. Dann wüßte man auch ob es sich dabei um eine 5V DC Aufmischung handelt, oder um den Pegelbereich.

Danke.

--147.161.235.104ersteinmal --147.161.235.104 10:40, 27. Mär. 2024 (CET)