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
which task (MP3 or navigation or ...)

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

Google for BAP, for example....

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

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...

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?

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: 
https://youtu.be/1jUGkbKmEPc?t=1m6s
This is how a CAN-Bus looks like sorted by source-ID. You can see e.g. 
the alive counters.

Lothar M. wrote:
> What "same" problem?

Same problem as here...
Beitrag "Ein HMI-Protokoll für den CAN-Bus"

Same problem as here...
Beitrag "HMI-Protokoll"

At least, now we know this question comes from a job application 
process. Can someone tell us the companys name?

What are all these fools going to do in their later developer/business 
lifes? Asking us for doing their job, I guess. jeeez...

br, mf