Vehicle lighting system

Hello everyone,

Just a heads-up, I'm new to this field and a complete beginner.
Okay, I need to create a lighting concept for a custom-built vehicle that doesn't resemble any production car. It is not intended for use on public roads, but it still needs to comply with the German Road Traffic Regulations (StVZO).
For the project, a control unit will be installed on each headlight, along with a main module on the driver's side, for a total of 5 modules.
The network should be expandable for other functions (e.g., powertrain) and built in a ring topology, which makes me suspicious, as I've read that this isn't possible with CAN. My boss told me to focus less on CAN and more on the messages themselves, such as their size (e.g., 4 bytes), what information they need to contain, how many identifiers are required, and what they represent. For example, if an emergency braking system is activated, not only should the brake lights come on, but also the hazard lights. So, who is communicating with whom, and about what.

I'm really struggling with this and I don't know where to start or how to begin.
Does anyone have a suggestion for my problem?

PS: Please ask if anything is unclear before making unnecessary comments.

Thank you in advance.

The CAN bus typically has either a linear topology or, in rare cases, a star topology. I think a ring would be rather impractical for the CAN bus.

You can handle the actual communication using the identifier; for example, a message with ID 0x10 might represent headlights, ID 0x30 might represent parking lights, and so on. Within each identifier, you can then determine the specific signals needed and the information required for each.

I wanted to create a small matrix in Excel, but I only saw a brief example and I don't remember all the details. Is there a place where I can find something like that?

Yes, that's the question: what other information is needed?

Normally, to process a message, you need information such as its ID, its length (DLC), and how it is sent (cyclically, sporadically, on request, etc.).
You can then include your signals within a message, specifying things like the length of the information (1 bit, 2 bits, 1 byte), where it starts (e.g., byte 0, bit 3), whether it has a physical conversion factor (e.g., divided by 10 for decimal places in voltages), and whether it has an offset (meaning the voltage range is not from 0-12V, but from 9-12V).
Then, it is usually also defined who should receive the information (the recipient) and when a timeout error should be detected.