Ich stehe vor einem Projekt, bei dem ich grob ein Konzept erstellen
will, welches den Zugriff auf ein HMI-Gerät regeln soll. Das ganze soll
mithilfe des CAN-Busses geschehen. Folgende Anforderungen will ich
erfüllt haben. Die Lösungen die ich mir dabei ausgedacht habe, stehen
auch dabei:
1) Eine erste Anforderung ist, dass Gleichzeitigkeit erfüllt wird. Die
Kommunikation zwischen HMI-Gerät und anderen Steuergeräten soll quasi
gleichzeitig vonstatten gehen können. Wie würde das funktionieren?
Ich denke, diese Eigenschaft ist automatisch erfüllt, wenn CAN benutzt
wird. CAN ist nämlich ein Bus-System, welches für Realzeitanwendungen,
bei denen Gleichzeitigkeit eine Rolle spielt, gut eingesetzt werden
kann.
2) Eine zweite Anforderung ist, die Buszugriffsregelung auf das
HMI-Gerät.
Ich denke, dass könnte das CSMA/CA Prinzip, das bei CAN im
data-link-layer (ISO/OSI) definiert ist, für mich lösen. --> höher
periodisierte Anfragen kommen eher durch (Periodisierung am MID).
3) Die dritte und etwas schwierigere Anforderung ist, dass ich mehrere
Endapplikationen haben werde, die auf das HMI-Gerät zugreifen werden.
Dabei soll jede Antwort des HMI-Geräts eindeutig auf eine Frage der
Endapplikation zugeordnet werden können. Folgendes habe ich mir bis
jetzt gedacht:
Generell hat das HMI-Gerät eine eindeutige Message-ID (MID), mit dem man
das Gerät eindeutig kennzeichnen kann. Alle Nachrichten, die mit dieser
MID auf den Bus gelegt werden sind also von diesem HMI-Gerät. Wird z.B.
eine Taste gedrückt ('OK'), wird nach dem Broadcast Prinzip eine
Nachricht auf den Bus gelegt, dass diese Taste gedrückt wurde. Alle
Geräte, für welche die Nachrichten des HMI-Geräts interessant sind
(entsprechende Filter im CAN Controller), fangen diese ab und leiten es
an den Host-Prozessor weiter. Wie könnte hier bestimmt werden, dass
dieses 'OK' z.B. für das Navigationssteuergerät war und nicht für den
MP3 Player? Hier schwirren mir zwei Sachen im Kopf.
3.1) Entweder antwortet das HMI-Gerät nur wenn es gefragt wird, i.e. ein
Gerät am Bus sendet eine Request Nachricht und fordert das HMI-Gerät auf
zu senden (RTR bit = 1). Das HMI-Gerät sendet also nur, wenn es
aufgefordert wird, und die Antwort kann dann der entsprechenden
Aufforderung, also auch der Applikation zugeordnet werden.
3.2) Das HMI-Gerät sendet seine Nachricht und im Nutzdatenfeld (0..8
Bytes) steht sowohl der Inhalt der Nachricht, als auch für welches
Steuergerät genau seine Nachricht bestimmt ist. Das finde ich etwas
redundant, da beim CAN ja bereits nur die MID reichen sollte um die
interessanten Nachrichten für einen zu filtern.
Habt ihr noch weitere Anregungen oder bin ich irgendwo in ein
Fettnäpfchen getreten? Das ganze Protokoll soll nur grob geplant werden.
TLTR, aber:
" CAN ist nämlich ein Bus-System, welches für Realzeitanwendungen,
bei denen Gleichzeitigkeit eine Rolle spielt, gut eingesetzt werden
kann."
hat mich stutzen lassen. Sicher?
Angenommen eine Höherpriore ID belagert den CAN - dann wars das mit
Realzeit-(besser, Echtzeit-)anwendung.
Konzept prüfen!
ArthurD schrieb:> Generell hat das HMI-Gerät eine eindeutige Message-ID (MID), mit dem man> das Gerät eindeutig kennzeichnen kann. Alle Nachrichten, die mit dieser> MID auf den Bus gelegt werden sind also von diesem HMI-Gerät.
Die ID dient primär nicht der Erkennung des Absenders, sondern des
Inhalts der Botschaft.
> Wird z.B. eine Taste gedrückt ('OK'), wird nach dem Broadcast Prinzip> eine Nachricht auf den Bus gelegt, dass diese Taste gedrückt wurde.
Was anderes als Broadcasts gibt's ja bei CAN auch nicht.
> Alle Geräte, für welche die Nachrichten des HMI-Geräts interessant sind> (entsprechende Filter im CAN Controller), fangen diese ab und leiten es> an den Host-Prozessor weiter. Wie könnte hier bestimmt werden, dass> dieses 'OK' z.B. für das Navigationssteuergerät war und nicht für den> MP3 Player?
Ich frage mich hier, warum das HMI-Gerät das überhaupt wissen muss - und
wie es das überhaupt unterscheitet. Wenn man auf den OK-Knopf drückt,
woher weiß das HMI-Gerät denn, ob ich damit das Navi oder den MP3-Player
gemeint hab?
Du musst dir außerdem überlegen, was passiert, wenn mal eine
CAN-Botschaft verloren geht.
Im Auto wird das normalerweise auch etwas anders gemacht. Da schickt das
HMI-Gerät einfach zyklisch z.B. zweimal pro Sekunde eine Botschaft, die
den Status aller Tasten enthält (ein Bit pro Taste). Beim Drücken oder
Loslassen einer Taste wird die Botschaft ebenfalls geschickt, damit die
Reaktionszeit nicht zu lang ist.
ArthurD schrieb:> CAN ist nämlich ein Bus-System, welches für Realzeitanwendungen,> bei denen Gleichzeitigkeit eine Rolle spielt, gut eingesetzt werden> kann.
Gleichzeitigkeit ist bei Zeitmultiplexverfahren, wie sie bei Bussystemen
(und damit bei CAN) verwendet werden, prinzipbedingt unmöglich.
Ich fürchte, du hast den Unterschied zwischen Echtzeit und
Gleichzeitigkeit nicht verstanden. Die haben genau nichts miteinander zu
tun.
> Habt ihr noch weitere Anregungen oder bin ich irgendwo in ein> Fettnäpfchen getreten? Das ganze Protokoll soll nur grob geplant werden.
Was du vorhast, ergibt keinen richtigen Sinn, dafür klingt es nach
Hausaufgaben. Warum sonst sollte man nur grob planen wollen?
Am einfachsten ist es, du:
- machst ausschließlich Frage/Antwort
- jede Frage und jede Antwort besteht aus exakt einem Datenpaket
- jede Frage enthält ein zufälliges Cookie und jede Antwort schickt
dieses Cookie zurück
ArthurD schrieb:> CAN ist nämlich ein Bus-System, welches für Realzeitanwendungen,> bei denen Gleichzeitigkeit eine Rolle spielt, gut eingesetzt werden> kann.
Was ist denn das Gegenteil? Imaginärzeit? ;-)
Gleichzeitigkeit gibt es nicht wie bereits geschrieben. Aber bei einem
Highspeed-CAN kannst du bei wenigen Botschaften eine Wiederholrate von
1ms schaffen. Ist das gleichzeitig genug?
ArthurD schrieb:> Generell hat das HMI-Gerät eine eindeutige Message-ID (MID), mit dem man> das Gerät eindeutig kennzeichnen kann. Alle Nachrichten, die mit dieser> MID auf den Bus gelegt werden sind also von diesem HMI-Gerät.
Beim CAN haben eigentlich nicht die Geräte eine ID, sondern die
Botschaften, also die eigentlichen Nutzdaten. Dein HMI-Interface sendet
z.B mit der ID 0100H alle 10ms den Status aller Bedienknöpfe. Die
anderen Teilnehmer am Bus nutzen anhand der ID dann die Information -
oder auch nicht.
ArthurD schrieb:> Das ganze Protokoll soll nur grob geplant werden.
Für mich ist das beschriebene schon eine Feinplanung.
Schon mal den ISOBUS angesehen?
https://de.wikipedia.org/wiki/ISOBUS
Annika schrieb:> was meinst du genau damit?
Frage: "Hallo Gerät X, ich bin Y und hätte gerne Datenwort Z. Mein
Cookie lautet 409233."
Antwort: "Hallo Y, ich bin Gerät X und Antwort auf Cookie 409233. Die
Antwort lautet Z-Strich".
Schon kann der Frager ständig neue Fragen fragen, ohne jede Antwort
einzeln abwarten zu müssen.
Interessante Diskussion: -
Hi @rmagnus, @svenska, @igel
Ich möchte hier keine zeitgesteuerte CAN. Alle Steuergeräte würden
versuchen, gleichzeitig auf die HMI-ECU zuzugreifen. Jetzt Meine Fragen
sind:
1) Muss das HMI ECU mit der niedrigsten Nummer ID (während der
Design-Periode) so zugeordnet werden, dass es immer auf höhere Priorität
und sendet den Status, dass es frei ist oder nicht zu allen anderen
CAN-Knoten?
2) Sagen wir nun, dass der "Navigation Node" einige Daten auf den Bus
gesendet hat und wie würde das HMI-Steuergerät wissen, dass es Daten von
der Engine (oder) Navigation (oder) Gearbox (oder) Navigation lesen
muss? Geht es vom User Click (Userwunsch)?
3) Dann wird die HMI-ECU zum Client und andere ECUs werden zu Servern.
Wie funktioniert das hier? Ist die RTR (Remote Transmission Request) vom
HMI Client zum jeweiligen Steuergeräteknoten? Ich bin hier nicht klar
4) Nun benötigt mein HMI keine Navigationsdaten und dann wird die
entsprechende CAN-Nachricht verworfen (da kein anderer CAN-Knoten sie
benötigt)?
Ich muss das gleiche Projekt für ein Vorstellungsgespräch vorbereiten.
Wie lief der Vorstellungsgespräch bei dir? Ich würde gern ein paar Typs
Haben? gern Kannst du mir per E-Mail kontaktieren nanacena12@gmail.com
Nana C. schrieb:> für ein Vorstellungsgespräch vorbereiten
Ist ja noch schlimmer als im anderen Thread von mir angenommen
Beitrag "HMI-Protokoll"
Wie soll es später im Berufsalltag gehen? Wirst du da auch immer wieder
in einem Forum Fragen und andere Leute die Arbeit für dich machen
lassen?
mfg mf
> Wie soll es später im Berufsalltag gehen? Wirst du da auch immer wieder> in einem Forum Fragen und andere Leute die Arbeit für dich machen> lassen?
Nein es geht nicht darum dass ich kein Kommunikationsprotokoll
schreiben kann :). Ich will nur wissen welche Fragen er bekommen hat.
und wie sein Vorstellungsgespräch lieft
