CAN Arbitrierung die zweite

[Gerhardt Hohn]

Hallo,

nochmals danke für die Antworten im vorigen Thread.

Ich hab noch mehr Fragen, aber erstmal der Kontext:

Ich soll ein dezentrales Energiemanagement für KFZ konzipieren und als
Simulation in CANoe prototypisch implementieren (für die Uni...).

Folgende Situation:
Jeder Verbraucher kriegt einen Netzknoten verpasst. Wenn jetzt ein
Verbraucher umgeschaltet wird, dann sollen die anderen Netzknoten informiert
werden.

Ursprünglich dachte ich an eine Nachricht wie zum Beispiel:

CAN-ID: 42 ("Umschaltung")
Datenfeld: +/-4,2Amper (aufgenommene oder freigegebene Stromstärke)

Da es nicht interessiert wer jetzt den Strom aufnimmt, oder freigibt, dachte
ich es reiche *eine* ID auf allen Netzknoten. Naja, mittlerweile weiß ich
ja, dass das nicht OK ist.


Okidoki, jetzt die Frage: Könnte ich nicht doch *nur eine einzige* ID
verwenden, wenn ich am Anfang des Datenfeldes eine Kennung des Netzknotens
(eindeutiger Integer der auch die Priorität beschreibt) mitschicke. Wird die
konsistente Arbitrierung auf dem Datenfeld fortgesetzt?


Wenn nein, wäre es wenigstens sinnvoll, ich würde mir die ersten 6 Bit der
ID als Nachrichtentyp "Umschaltung" definieren, und in die restlichen 5 Bit
die Kennung des Netzknotens reinschreiben. Kann man bei realen CAN
Bausteinen so eine Art Maske vorgeben? Zum Beispiel, "lauere auf
101010*****". In CANoe hab ich da auch noch keine Möglichkeit gefunden, wie
ich das machen könnte, ausser dass ich jede einzelne ID einzeln eingebe

Das ganze hätte auch den Nachteil, dass ich auf diese Weise wahrscheinlich
mehrere 100 IDs brauchen werde. Ausserdem müsste alles im voraus starr
festgelegt werden. Ich hatte davon geträumt, dass ich einfach ohne was zu
konfigurieren neue Netzknoten/Verbraucher "anstöpseln" könnte.


By the way, geht "hot plugging" bei CAN? Prinzipiell schon, oder? Der Knoten
müsste doch nur rezessiv bleiben, bis er feststellt, dass er am Bus hängt,
und ein paar Telegramme korrekt mitgelesen hat. Ist das realistisch?
speziell im Fahrzeug?

sorry wegen den vielen Fragen (kommen sicher noch mehr )

TIA,
Gerhardt

 

[Oliver Bartels]

On Sat, 5 Jul 2003 20:37:29 +0200, "Gerhardt Hohn" <gh-un@gmx.net>
wrote:

Okidoki, jetzt die Frage: Könnte ich nicht doch *nur eine einzige* ID
verwenden, wenn ich am Anfang des Datenfeldes eine Kennung des Netzknotens
(eindeutiger Integer der auch die Priorität beschreibt) mitschicke. Wird die
konsistente Arbitrierung auf dem Datenfeld fortgesetzt?
CAN ist CAN ist CAN ist nicht UDP ... ;-)

Warum nicht ganz einfach:
ID 501 : Starter-Generator-Steuerung Meldung
ID 511 : Lampenkontrolmodul Meldung
ID 521 : Getriebesteuergerät Meldung
ID 101 : Schampuskühlschranksteuerung (wichtig!) Meldung
ID 91 : Türzuziehhilfe hinten rechts (ganz wichtig!) Meldung
ID 81 : Pannenmelde-Infotainment (extrem wichtig!) Meldung

Jeweils in Byte 1 : Ist-Stromaufnahme z.B. in Ampere
Byte 2..8 stehen für weitere Detail-Stromaufnahmen
zur Verfügung.

Die Gesamt-Stromaufnahme ist dann die Summe aller Byte 1.

Die Freigaben könnten dann in einer ID stehen
(Byte 1 = Device, Byte 2 = Strom), oder mit einer ID pro
Ziel geschickt werden (vermeidet das Problem, dass bei
bestimmten CAN-Controllern ggf. die Mailbox überschrieben
wird, bevor sie gelesen werden kann, und ist daher sicherer.

Das ursprüngliche Konzept vom CAN war ganz einfach:
Die Datenquelle sendet (selbsttätig oder auf Anforderung)
und jeder, der an dieser Information unter der ID interessiert
ist, kann eine Mailbox dafür einrichten und erhält so immer die
neuesten Infos. Also z.B.: Meldung 101 : Byte 1 =
Schampuskühlschrank Stromaufnahme, Byte 2 = Temperatur.
Z.B. wird dann Dein Powermanagement auf Meldung 101 hören
und den aktuellen Strom immer aus Byte 1 der Mailbox lesen
können, genauso wird das ESP mitlesen (Byte 2: Notbremsung
bei steigender Temperatur vor dem nächsten Feinkostladen,
das ESP sollte dann auch eine Message vom Navi erhalten,
nämlich aktuelle Distanz zum nächsten Feinkostladen ;-)

Wenn nein, wäre es wenigstens sinnvoll, ich würde mir die ersten 6 Bit der
ID als Nachrichtentyp "Umschaltung" definieren, und in die restlichen 5 Bit
die Kennung des Netzknotens reinschreiben.
Warum den Aufwand mit der "Umschaltung". Das erfordert wieder, dass

sich irgendwelche Steuergeräte *Zustände merken*, und das will man bei
den totgegeizten Hochqualitätszinnschicht-Halbleitsteckverbindern
(das mit dem Halbleit(d)en bezieht sich auf die Time Domain ;-| mit
eingebautem Reset-Zufallsgenerator nicht wirklich.

Btw.: Du solltest Dir auch überlegen, was passiert, wenn das
zentrale Power Management seinen Geist aufgibt.
Es könnte besser sein, wenn jedes Steuergerät, das einbezogen
werden soll, lokal die Berechnungen anhand der gemeldeten Ströme
aller anderen Steuergeräte macht.

Warum ?
a) Das Power-Management-Steuergerät kann (und wird, auch
totgegeizt, gute Halbleiter waren für die Nobelkarosse zu teuer ;-|
ausfallen.
b) Ein Steuergerät kann sehr wohl noch funktionieren, aber keinen
Buskontakt mehr haben (Halbleidstecker oder Bus-Kurzschluß oder
Unterbrechung).

Das Power Management darf nicht dazu führen, dass bei einem
gestörten CAN Bus oder Buszugang oder spontanem Reset des
für das Power Management verantwortlichen Steuergerätes
(alte Zustände vergessen, deshalb nicht "Umschaltung" melden,
sodern "Strom ist *derzeit*") das Fahrzeug elektronisch und
kurz drauf mechanisch kollabiert.

Kann man bei realen CAN
Bausteinen so eine Art Maske vorgeben? Zum Beispiel, "lauere auf
101010*****". In CANoe hab ich da auch noch keine Möglichkeit gefunden, wie
ich das machen könnte, ausser dass ich jede einzelne ID einzeln eingebe
Bei den meisten Bausteinen ja. Aber häufig nur auf einer

Debug-Mailbox.

Das ganze hätte auch den Nachteil, dass ich auf diese Weise wahrscheinlich
mehrere 100 IDs brauchen werde.
Wozu ? Typisch eine ID pro Steuergerät für die Funktion, wenn

nicht woanders Platz ist.

Wollt Ihr einige hundert Steuergeräte und ein Kernkraftwerk einbauen,
darf man das Auto dann nur noch mit LKW-Führerschein fahren ;-/

Ausserdem müsste alles im voraus starr
festgelegt werden. Ich hatte davon geträumt, dass ich einfach ohne was zu
konfigurieren neue Netzknoten/Verbraucher "anstöpseln" könnte.
Nochmal: CAN ist CAN ist CAN ist ...

Es gibt durchaus Ansätze, auf das CAN ein weiteres Protokoll
zu legen.
Näheres findest Du z.B. auf der Seite von
http://www.vektor-informatik.de
Das ist der akkreditierte CAN-Softwarelieferant der
Deutschen Automobilindustrie AG

IMHO legt z.B. GM ein weiteres Protokoll oben drauf, andere
teilweise nur für die Diagnose, aber all das ist nicht wirklich bei
CAN vorgesehen gewesen.

Das Problem ist: Je mehr Protokoll, desto mehr Murksmöglichkeit.
Und bei einer Aktivlenkung, die qua E-Motor verstellt werden kann,
einer Bremse, die am ESP hängt, und einem Motor, dessen
Drosselklappe per EML/EGas gesteuert wird sowie Türen und Fenstern,
die am Komfort-CAN hängen, ist das nicht wirklich lustig.
Da war doch neulich dieser eine Fall in Fernost, wo die Bodyguards
am Ende nur noch die Panzerglasscheiben einschlagen konnten ...
Oder wie wäre es mit:
"Allgemeine Schutzverletzung durch Anwendung: BremsLenk" ;-/

By the way, geht "hot plugging" bei CAN? Prinzipiell schon, oder? Der Knoten
müsste doch nur rezessiv bleiben, bis er feststellt, dass er am Bus hängt,
und ein paar Telegramme korrekt mitgelesen hat. Ist das realistisch?
speziell im Fahrzeug?
Theoretisch ja, praktisch nein. Man wird nicht einen CAN-Bus, an dem

die Fahrsicherheit und/oder erhebliches Komfortstörpotential hängt,
während der Fahrt umkonfigurieren. Hinzu kommt, das es häufig
mehrere CAN Systeme gibt, z.B. High Speed für Motor/Fahrdynamik
und Low Speed für Komfortelektronik.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10