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
Hi ArthurD, hast du zufällig jetzt ein paar mehrere Ideen? Ich hab auch ziemlich gleiches Problem.
Hi ArthurD, hast du mehrere Ideen jetzt? Ich hab ziemlich gleiches Problem. wäre sehr nett wenn du mir darüber schreiben kannst.
S. R. schrieb: > - jede Frage enthält ein zufälliges Cookie und jede Antwort schickt > dieses Cookie zurück Hi svenska, was meinst du genau damit?
Annika schrieb: > was meinst du genau damit? Willst du uns hier für dumm verkaufen? Der englische Text ist so gut wie identisch mit dem ersten Beitrag hier. https://embdev.net/topic/413408#new
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)?
Hi, ich habe ähnliches Problem. Könnten Sie mir bitte in dieser Hinsicht helfen?
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
Beitrag #6817034 wurde vom Autor gelöscht.
> 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
Dann verrate uns doch mal die Firma die sowas fragt. Naja, da kommen auch nur ein paar in Frage... mfg mf
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.