mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ein HMI-Protokoll für den CAN-Bus


Autor: ArthurD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Einwand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Forster (igel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Annika (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi ArthurD,

hast du zufällig jetzt ein paar mehrere Ideen? Ich hab auch ziemlich 
gleiches Problem.

Autor: Annika (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi ArthurD,

hast du mehrere Ideen jetzt? Ich hab ziemlich gleiches Problem. wäre 
sehr nett wenn du mir darüber schreiben kannst.

Autor: Annika (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: MahhhWa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ravi Tej (pathseeker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.