-
Notifications
You must be signed in to change notification settings - Fork 0
System Design
- Safely handle the inverter pre-charge sequence
- Control torque requests to the inverter based on throttle, brake, and system state
- Monitor inverter and battery management system (BMS) status' to control system state
- Monitor sensor readings from various sensors on the car and transmit the data over to the Data Acquisition System (DAQ)
- Communicate bi-directionally with various CAN Bus based peripherals
- Control the built-in high-side drivers to toggle various powerlines connected to the ECU
Based on the 5 key requirements, the software can be segmented into the following distinct systems to help compartmentalize the code base. I've also decided to take a bit of a less common approach and try to use object-oriented code in an embedded environment to help make the code base more approachable to work on. With that in mind, the systems will be grouped into object classes in C++.
Vehicle State machine: Simple finite state machine implementation to ensure that certain control actions can only occur in certain states
CAN Interface: A publisher/subscriber based abstraction layer for CAN bus that makes it easy for other systems to publish/subscribe to CAN signals
Sensor logger: Abstraction layer for defining various sensors and collecting data to transmit
Inverter/BMS: Classes encapsulating the key parameters that the inverter and BMS transmit over CAN bus to make it easier to make decisions in the state machine based directly on an object interface (more on this later).
Power Distribution Module: Interface for toggling the high-side drivers on the board and transmitting the states over CAN
This isn't an exhaustive list of all the Classes in the code base, but rather a systematic overview of the key pieces. There are several other classes used for supporting purposes but they don't relate directly to the system requirements.
While this project could certainly be executed without the added complexity of an operating system, sticking with the theme of segmenting the code to make it easier to work on, I've decided to use FreeRTOS such that certain critical systems can run independently in their own tasks without having to worry about maintaining a large super-loop. This also enables an easy way to have time-interval based interrupts to perform certain tasks at known frequencies, such as transmitting a CAN message once every 100ms. For more details on the RTOS implementation please see the dedicated page.