Diskussion:Controller Area Network

message: 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)
thread_title:  Vergleich CAN-FlexRay 

message: Vorschlag zur Wikifizierung weiterer Abschnitte:
:*OSEK 
ramtam 22:47, 21. Aug. 2006 (CET)
replies: text: 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)
thread_title:  höhere Protokolle 

message: 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)
replies: text: 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)
thread_title:  Netzwerkmanagement 

message: 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)
replies: text: 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)
thread_title:  ACK und Leitungslänge? 

message: 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)
thread_title:  Standards 

message: 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!
"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)
thread_title:  CAN-Bus in Avionik-Systemen? 

message: 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)
replies: text: 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)
thread_title:  CAN Frame Darstellung 

message: 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)
thread_title:  FlexCAN 

message: 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)
replies: text: 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)
thread_title:  Spaßvogel! 

message: 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)
thread_title:  Pegelangabe 

message: 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)
replies: text: Ein kurze Einführung mit dem Link zur Spezifikation von Bosch habe ich hinzugefügt. --Plupp (Diskussion) 14:41, 11. Aug. 2013 (CEST)
thread_title:  CAN Flexible Datarate 

message: 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)
thread_title:  Höhere Protokolle 

message: "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)
replies: text: 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)
thread_title:  frame aufbau 

message: 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)
replies: text: 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)
thread_title:  Stichleitung /stub falsch verwendet 

message: 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)
thread_title:  ACK-Slot 

message: 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)
replies: text: 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)
thread_title:  Bericht: CAN-Bus-Hack Altes Nokia Handy unterstützt Auto Diebstahl per Klick 

message: "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)
thread_title:  Funktion Übertragungsverfahren ist doch falsch?