# Forum: µC & Digital Electronics HMI Protocol for CAN BUS

Rate this post
 0 ▲ useful ▼ not useful
Hi .*,

I need to design a HMI protocol for ECUS in cars which are connected to
a CAN bus.
I have basically 3 tasks to consider.

The system is consisted of some Application control units and a HMI
control unit and these all are connected to a same CAN bus.

1- I have to make simultaneous communication of application CUs with HMI
possible.
- In my idea this is not possible since CAN protocol does not support
the Simultaneous communication on a same BUS. What I can do is to add
more CAN buses. one for each of Application CUs to be able to receive
more than one message at a time.

2- I need to control the access to the HMI so at each time HMI can
process the request of one of the Application CUs.

- I believe CSMA/CD which is designed in the Datalink Layer of CAN
makes this possible for me and gives the HMI enough time to process task
of each CU.

3- Here is the part which I'm really confused. I have to design it in a
way that the answer from HMI goes to the corresponding Application CU.
- CAN ID of each message is different and I can't get how a message
can go to a wrong Control Unit. Maybe the problem is here that How does
HMI understands if the driver pushes OK button , this OK belongs to

Also I see a conflict in first and second task. make communication
simultaneous but the HMI can process only one task at a time.

I have a question to this myself. How does the communication happens in
vehicles at all? Is it like this that HMI sends a message every 2ms and
inside is the status of the buttons on the HMI? Is it possible to embed
status of all buttons in HMI in one message? If possible then how is it
possible that all CUs read it and know which bit in the message belongs
to their task. Or maybe the communication is totally different and each
CU sends a CAN request frame to the HMI and HMI responds to that? or
maybe some other methods are used?

Please Let me know where you think I'm making mistake and also your
Ideas

Rate this post
 0 ▲ useful ▼ not useful
Hi .*,

I need to design a HMI protocol for ECUS in cars which are connected to
a CAN bus.
I have basically 3 tasks to consider.

The system is consisted of some Application control units and a HMI
control unit and these all are connected to a same CAN bus.

1- I have to make simultaneous communication of application CUs with HMI
possible.
- In my idea this is not possible since CAN protocol does not support
the Simultaneous communication on a same BUS. What I can do is to add
more CAN buses. one for each of Application CUs to be able to receive
more than one message at a time.

2- I need to control the access to the HMI so at each time HMI can
process the request of one of the Application CUs.

- I believe CSMA/CD which is designed in the Datalink Layer of CAN
makes this possible for me and gives the HMI enough time to process task
of each CU.

3- Here is the part which I'm really confused. I have to design it in a
way that the answer from HMI goes to the corresponding Application CU.
- CAN ID of each message is different and I can't get how a message
can go to a wrong Control Unit. Maybe the problem is here that How does
HMI understands if the driver pushes OK button , this OK belongs to

Also I see a conflict in first and second task. make communication
simultaneous but the HMI can process only one task at a time.

I have a question to this myself. How does the communication happens in
vehicles at all? Is it like this that HMI sends a message every 2ms and
inside is the status of the buttons on the HMI? Is it possible to embed
status of all buttons in HMI in one message? If possible then how is it
possible that all CUs read it and know which bit in the message belongs
to their task. Or maybe the communication is totally different and each
CU sends a CAN request frame to the HMI and HMI responds to that? or
maybe some other methods are used?

Please Let me know where you think I'm making mistake and also your
Ideas

Thanks in advance for any help

Rate this post
 0 ▲ useful ▼ not useful
Google for BAP, for example....

https://www.quora.com/What-is-BAP-Bedien-und-Anzeigeprotokoll-and-its-uses-in-the-automotive-software-development

Rate this post
 0 ▲ useful ▼ not useful
Goforit wrote:
> 1- I have to make simultaneous communication of application CUs with HMI
> possible.
>    - In my idea this is not possible since CAN protocol does not support
> the Simultaneous communication on a same BUS. What I can do is to add
> more CAN buses. one for each of Application CUs to be able to receive
> more than one message at a time.

Read a good CAN-Bus Documentation, since you did not understand the
function of the CAN-Bus.

Simultaneous is not possible right. but you don't need simultaneous. you
have to define what timings you need ...

Read the CAN-Bus Documentation and define the timings you need. you will
see that it offers more bandwith than you need :-)

hmi by the way is slow in terms of reactiontimes...

Rate this post
 0 ▲ useful ▼ not useful
All CAN bus devices can basically "see" all messages that are on the
bus. But usually they have filters in their CAN controllers so that the
software only gets the messages that are required.

The ECU with the controls (buttons, knobs...) usually sends its messages
event-driven (button pressed/released, new knob position,...).
For Example: Whenever the user presses the OK button, a CAN message
(e.g. ID 0x123) is sent with the corresponding bit set to 1 (e.g. lowest
bit in the first byte). When the button is released, the message 0x123
is sent again with the bit set to 0.
All bits in all messages on the CAN bus are well defined. And each ECU
knows, what signals/bits in which CAN message are relevant for its
application.

Regarding timing: A (High-Speed-)CAN bus can carry thousands of messages
per second - how many times can you press a button per second?

Rate this post
 0 ▲ useful ▼ not useful
mmm wrote:
> The ECU with the controls (buttons, knobs...) usually sends its messages
> event-driven (button pressed/released, new knob position,...).
> For Example: Whenever the user presses the OK button, a CAN message
> (e.g. ID 0x123) is sent with the corresponding bit set to 1 (e.g. lowest
> bit in the first byte). When the button is released, the message 0x123
> is sent again with the bit set to 0.

You will never never never find messages on a vehicle CAN that are only
sent when a certain event occures. They always depend on the status of
the car (sleep, ignition, motor running, ...). The values are sent in a
very well defined interval no matter if e.g. a button is pressed or not.
The value changes depending on the button state. Most CAN telegrams (at
least each device) has a telegram which contains an alive counter. There
are only very few cases where ther is additional data (that is not sent
regularly) on the bus.

This offers the following advantages: You can detect if a telegram get's
missing (bad cabeling or defective device) and (far more important) you
always have a defined bus traffic. The system is nearly no testable if
you don't have a defined bus load and "randomly" occuring CAN messages.

soundso wrote:
> Read a good CAN-Bus Documentation, since you did not understand the
> function of the CAN-Bus.

I'd suppose you to sniff your car's CAN (e.g. Entertainment-CAN) and
watch for button presses or similar activities. There is lots of
freeware on the market. The CAN-Bus adapter can be very simple and cheap
20\$ (see ebay, aliexpress). Just a random pick of video:
This is how a CAN-Bus looks like sorted by source-ID. You can see e.g.
the alive counters.

• $formula (LaTeX syntax)$