FW16 Vehicle Simulation

Owned by Aryan Kashem
Last updated: Dec 16, 2024
3 min read

This simulation will be similar to our past project, MPXE.
It will log GPIO states, I2C transactions, SPI transactions, and CAN data. This includes mocking our LTC6811 ICs, current sense IC, and motor current/voltage.

Current Repo as of 15/12/2024 (Local testing on Aryan’s Github): https://github.com/Akashem06/Embedded_Simulation_Framework

image-20241215-235001.png
Simulation Top-Level 15/12/2024

DESIGN CHOICES:

  1. The server and client interface will be done in C++ using TCP/IP sockets to maintain communication.

  2. Everything will be modular to support scalable development. I have made it so the simulation framework can easily be ported to other chip families with varying GPIOs, I2C interfaces, etc.

  3. Log data into a single JSON file, containing each project's info. (Could be transitioned to multiple JSON files per project, as a single file can become very large).

  4. Currently, the C++ terminal is the user interface, but this can easily be transitioned to a more user-friendly GUI.

  5. The mock drivers supported by the simulation are in the following list:

    1. GPIO

    2. I2C

    3. SPI

    4. CAN

    5. Flash

    6. CRC

    7. ADC

    8. LTC6811

    9. MAX17261

    10. Wavesculptor motor controller

  6. Gpio Manager

    1. Server Instance

      1. Supports command generation for receiving all pin state/mode/alt functions.

      2. Supports command generation for receiving single pin state/mode/alt function.

      3. Supports processing/updating the JSON file after receiving a message from the client

      4. Utilizes heap memory to dynamically allocate vectors to deserialize data. This allows for future expansion if needed!

      5. Uses the heap to dynamically load/save the GPIO Json data. This way, if we are not updating JSON data, it is not stored in the background.

    2. Client Instance

      1. Support interacting with the C-drivers

      2. Support packaging single pin state/mode/alt function.

      3. Support packaging all pin state/mode/alt functions.

  7. I2C Manager

    1. To be completed

  8. SPI Manager

    1. To be completed

  9. CAN Manager

    1. To be completed

  10. ADC Manager

    1. To be completed

  11. The client name can be passed in when running the program as an argument (using argc argv).

    1. This prompts the question: Will we use a Python script to initiate the simulation, perhaps via SCons?

    2. Depending on future GUI development, we could integrate some JSON parsing application to manage to start the simulation. To be determined.

  12. We must synchronize the start of all programs. This could be done using a global barrier semaphore across all processes. This would require shmem. Another alternative is using a global START message sent to all clients. To be determined.

  13. Application thread/scheduling for periodic data scraping

    1. To be completed

    2. The idea is to create a data scraping task that schedules when we fetch GPIO data, set ADC readings, update BMS data etc.

      1. This can be done by generating multiple threads that sleep for x amount of time

      2. This can be done by following suite with master tasks, and defining 3 frequencies at which data can be collected

      3. This can be done by using the time library to allow data collection at certain times.

DESIGN IMPROVEMENTS/THOUGHTS

  1. We could use UDP rather than TCP since everything will be running locally. This reduces message overhead. This would modify the base server/client classes. Everything is built on top of these base classes.

  2. We could run the client projects on an external server like the Bay PC. This could be integrated into the CI/CD where the simulation can be used to verify the vehicle is functioning as expected (no faults/unexpected readings).

  3. We could transition message structures to Protobufs to standardize everything.

  4. Better synchronization/input buffering

    1. I was dealing with some issues when rapidly sending bytes from the client->server (Separate messages, so each byte would trigger the callback, and it would not complete fast enough to handle the next byte).

    2. One solution is to have an array store the received data so it can be buffered using a read/write pointer.

    3. Another solution is to use a mutex/spinlock that blocks reading the socket until data is done processing? I will play around with this in the final development stages.

  5. Aryan might have added too much abstraction; maybe we can remove some layers? Specifically between Datagram classes → Managers → Terminal interfaces? I think the abstraction makes the code pretty readable.