Driverless Fault Management Module

When I became the Electrical Lead for UQ Racing, one of my key responsibility was to get a working Driverless Fault Management Module (DFMM) for the autonomous vehicle (AV), as it was more often than not the key blocker on the critical path for a functioning AV. In previous iterations, the autonomous fault loggic was integrated directly with the primary vehicle Fault Management Module (FMM) for a more compact and integrated unit. However, this created a significant bottleneck, where if we needed to pull the autonomous hardware out for debugging or software updates, the entire vehicle would have been grounded. This stopped a large number of testing track days where the car could not function as an Electric Vehicle (EV), meaning that both EV and AV debugging and testing would have to happen concurrently which was an inefficient usage of time.

Stepping into my role, I recognised to meet our aggressive 2024 autonomous shakedown deadline, we needed a modular architecture. My goal was to design a standalone DFMM that could be integrated alongside a prexisting FMM taken from an old EV  to allow for parallel development, testing, and integration, thus reducing vehicle downtime and increasing our testing throughputs by 50%.

The Design:

I designed the DFMM around two distinct functional layers to balance safety and intelligence:

Non programmable Logic (The Safety Core): Being responsible for the shutdown circuit (a logic level high safety circuit that provides power to the high energy battery's contactors, this circuit ensures that a detected fault immediately stops any high powered actuation on the car), I chose to use discrete logic gates and D type flip flops rather than a processor. This ensures that the car starts in a "fail safe" error state, where the safety state cannot be entered until the initial safety checks has been done. This sees the system starts in an error state before entering a non error state. Additionally, any faults that happens after the safety check will immediately be latched to prevent false positives, which could be seen in the following state machine depiction:

From this state machine, I used LogiSim and Altium Designer to design the necessary logic circuit:

The supervisor (The Brain): The supervisor monitors the status of the Emergency Braking System (EBS) and pperforms the initial checks for the system uppon startupp. In the case of a failure within the car, the sueprvisor will trigger the EBS and stops all high powered actuation within the vehicle. Based on an STM32 microcontroller, I migrated the pre-existing AVR platform to leverage the 32 bit performance and native CAN 2.0B supppport, which allows for a better implementation of a deterministic monitoring of the Emergency Braking System (EBS).

Additionally, the extra computational power meant that I could implement a finite state machine to conduct continuous monitoringg, which is used during operation to detect failures like cables or ppneumatic line ruptures. The typical values for monitoring are the energy storage of the mechanical EBS part and the state of Remote Emergency Stop (RES). In case of triggered EBS the function of the EBS must be checked as well. If sufficient brake line pressure is not built up, the redundant system must be activated. This can be represented through the state machine diagram:

Overall, an initial setup of the supervisor and its communication to other systems with the DFMM network is as depicted:

The Implementation

The project was done in Altium, which allowed me to maintrain strict version control over the component library and perform real time design rule check as I progress. Additionally, the collaborative cloud platform enabled me to present biweekly updates to the rest of the UQ Racing Team. My focus with the schematic was to create a highly readable, hierarchical design:

To maintain the vehicle's waterproofing and vibration resistance, I was required to fit the DFMM into a pre-existing, SAE-grade enclosure. The internal dimensions were strictly limited, making a traditional 2 layer layout improbable due to the number of traces required. As such, I decided to go with a 4 layer PCB stackupp to maximise spatial efficiency and improve signal integrity as follows:

1. Signals: Dedicated to high-speed digital signals and sensitive analog traces. By keeping these on the top layer, I minimized the use of vias, reducing parasitic inductance. 

2. Power Plane: A dedicated internal copper pour for the 3.3V, 5V, and 12V rails. This acted as a low impedance reservoir, ensuring stable voltage delivery during high-current solenoid switching. 

3. Ground Plane: A solid, uninterrupted reference plane. This provided the most critical benefit: EMI Shielding. By placing the Ground plane directly beneath the Signal layer, I aim to reduce the "loop area", significantly lowering the electromagnetic emissions and susceptibility of the board. 

4. Secondary Signals/Bottom: Used for non-critical routing and thermal relief for power components. 

By utilizing the internal planes for power and ground, I was able to reduce the overall PCB footprint by 40%, allowing the board to slide perfectly into the ruggedized enclosure while maintaining clear signal paths and superior heat dissipation. 

This was then fabricated and assembled through PCBWAY, which was a long term sponsor of the team, resulting in the final PCB:

Testing and Future Plans

To ensure that the DFMM works, I implemented a multi-stage validation process:

• Bench Testing and Logic Verification: 

Before integration, I performed isolated bench tests to verify the non programmble logic state machine. Using a variable power supply and signal generator, I simulated different possible fault combination (e.g., EBS failure, loss of CAN heartbeat, and emergency stop activation).

The Result: The hardware logic correctly triggered the SDC in all test cases. However, during bench testing of the software, it was discovered that certain components were faulty (CAN transceiver, logic level converters, various op amps) due to poor choices in passive components (pull-up resistors, decoupling capacitors). These components were changed on the board and noted in the schematic. In particular, a pin conflict was disicovered which affected the primary CAN transceiver, however a redundant CAN transceiver was available, allowing for an immediate failover.

• Thermal Stress and Vibration Assessment:

Given the enclosure constraints, I conducted a 60 minute full load thermal soak due to the usage of multiple linear voltage regulators in an enclosed sppace. I used a thermal camera to monitor the STM32 and voltage regulator to confirm that the 4 layer design of the PCB was effective in spreading heat.

The Result: The STM32 and LLCs did not exceed more than 40 degrees, while the rest of the board did not notably increase from the ambient room temperature.

• In Vehicle System Integration

The final validation involved live vehicle testing. I monitored the CAN bus traffic alongside the software team using a logic analyser to ensure the DFMM was able to read and write to the system CAN Bus.

The Result: Initially, the DFMM was unable to reliably communicate to the CAN bus due to intefference within the CAN network. To solve this, I replaced the CAN terminating resistor with different values whilst monitoring the line with a oscilloscope to match the line impedance to maximise power transfer and minimise signal reflection.

While the DFMM successfully achieved my goals of modularity and parallel testing, the design process revealed several opportunities for future iterations:

• Hardware-in-the-Loop (HIL) Automation: I plan to develop a dedicated HIL test rig using Python to automate the fault-injection process. This would allow for regression testing whenever the STM32 firmware is updated, ensuring safety is never compromised by new code. 

• Enhanced Telemetry: Future versions could include a microSD logging circuit to capture high-frequency black box data during a fault event. This would provide the team with sub millisecond resolution data to diagnose the root cause of track side shutdowns.

Project Takeaways

The design and implementation of the DFMM was a pivotal milestone in my development as an Electronics Engineer. It required a rigorous balance between strict autonomous safety regulations and the harsh electrical and physical constraints of a high-performance racing vehicle.

What I learnt:

• Advanced PCB Design (Altium Designer): This project was my transition from basic prototyping to designing a full on PCB from beginning to end, and was my first multi-layered PCB. I learnt how to do multi-layered stackup management, using internal power and ground planes to solve EMI and spacial issues in a PCB.

• Constraint Driven Engineering: I navigated extreme physical limitations by designing the hardware to fit a pre-existing, SAE-grade ruggedized enclosure. This taught me to prioritise mechanical integration and thermal management alongside electrical functionality.

• Safety-First Design Philosophy: I implemented my first redundant watchdog system, using a combination of software heartbeats and non-programmable hardware logic. This reinforced the importance of hardware-level fail-safes in autonomous vehicle safety, and taught me how to engineer for real world faults and situations.

• Systematic Debugging: I developed a methodical approach to hardware validation, identifying and resolving signal integrity issues in the logic-level translation and CAN communication stages during the prototyping phase. This gave me more confidence to use tools like oscilloscopes and logic analysers in my future projects.