Vehicle Control Unit

Cal Poly Computer Engineering Senior Project

Date: June 14, 2019

Prepared By: Ayusman Saha
Advised By: Dr. Andrew Danowitz
Contents

Introduction 2
Project Overview 2
Outcomes and Deliverables 3

Project Requirements 3
Base Requirements 3
Additional Features 4

Detailed Design 5
Software Architecture 5
Motor Logic 7
Shutdown Logic 8
Redundancy Logic 9

System Integration & Testing 9

Development Testing 9
Bench Testing 10
System Testing 12
Vehicle Testing 16

Experimental Features 17
Power Limiting 17
Traction Control 17
Final Words 18

Appendices 19
Acknowledgments 19
References 19

1
Introduction

Project Overview
The Vehicle Control Unit (VCU) is the central computer for Cal Poly’s Society of Automotive
Engineers (SAE) formula electric race car. It is responsible for processing driver inputs,
managing the electric motor, and providing a robust safety net in the case of system failure.
Additional functionality of the system include a power limiting mechanism as well as a traction
control system. All VCU logic must abide by SAE International rules for the competition.

The VCU was implemented as an embedded system on the MKE18F512 microcontroller

developed by NXP Semiconductors. A development board was used for testing before moving to
the control board. Table 1 details the components for this project. Note that components with an
asterisk (*) were developed in-house by members of the electronics team.

Table 1: Project Components

Component Function

Development Board* Development Microcontroller

Control Board* VCU Microcontroller

Battery Box* Power System

Front Harness* Electrical Cables for Rear Devices

Rear Harness* Electrical Cables for Front Devices

MoTeC ACL CAN Data Logger

Rinehart PM100DX/DZ AC Motor Controller

EMRAX 228 Three-Phase Electric Motor

2
Outcomes and Deliverables
The outcome of this project was firmware that could be run on the control board for the 2019
formula electric race car. The firmware had to be fully-functional and satisfy the minimum
requirements necessary for safe vehicle operation. Additionally, logic had to be tested thoroughly
and independently before system integration. All code had to be properly documented and
uploaded to the Cal Poly Racing GitHub for contribution and use by other team members.

Additional features were requested to be implemented as VCU logic. These included a power
limiting system to regulate the amount of power the vehicle drew from the battery pack and a
traction control system to reduce excess tire slippage.

Project Requirements

Base Requirements
Primary functions of the VCU were broken into three distinct subsections: motor control, safety
shutdown, and software redundancy. The VCU was expected to log important signals on the
Controller Area Network (CAN) bus and abide by SAE International rules.

Motor logic had to be computed by observing driver signals as well as safety signals. Driver
signals included 2 driver pedal sensors, front brake pedal sensor, rear brake pedal sensor, and an
enable switch. Safety signals included positive and negative Actuator Isolation Relays (AIRs) as
well as motor controller faults. Motor logic also consisted of implementing an Accelerator Pedal
Position Sensor (APPS) implausibility check and an APPS/brake pedal plausibility check
mandated by rules T.6.2 and EV.2.4 respectively [1]. These are safety checks that assess the
validity of the driver signals.

3
Shutdown logic had to immediately disable the vehicle if any safety check failed. This would be
achieved by disabling the AIRs which connect the output of the battery to the electric motor. It
also had to delay activating the positive AIR until the negative AIR was active. This was to
ensure the motor controller successfully pre-charged before it was enabled. Additionally,
shutdown logic had to be synchronized with motor logic so the vehicle could be shut down
without causing a fault in the motor controller.

Redundancy logic consisted of monitoring the Battery Management System (BMS), Insulation
Monitoring Device (IMD), and a software Brake System Plausibility Device (BSPD). This was
required by rule IC.4.8 [1]. If any of these signals went low, the VCU had to deactivate its 2
redundancy relays to cut power to the AIRs and power down the car. The software BSPD had to
be computed based on front brake pressure, rear brake pressure, and a current sensor located
inside the battery box.

Additional Features
A power limiting mechanism was requested to limit power draw from the battery box while
minimizing impact on the driver. This prevents violating rule EV.1.4 which limits the maximum
power draw to 80kW [1].

Traction control was another requested feature to improve performance. The idea was to limit
torque to the rear wheels when the vehicle enters a slip condition. However, solutions can only
lower the total driver requested torque per rule EV.2.2 [1]. This is to ensure the safety of the
driver by preventing positive feedback loops.

4
Detailed Design

Software Architecture
The primary goal of software design was to make the VCU modular to streamline development,
testing, and integration. My proposed design achieved this by separating core logic from
Input/Output (I/O). Figure 1 is a block diagram of the architecture.

Figure 1: VCU Software Architecture Block Diagram

Input signals from CAN, General-Purpose I/O (GPIO), and the Analog-to-Digital Converter
(ADC) are buffered in an input structure that gets passed to the logic block. This block performs
all the computations based on the input and generates an output structure. The resulting buffer is
then output to CAN and GPIO.

This design allows independent development of logic and I/O; one could be implemented and
debugged without the reliance of the other. This is particularly useful if development and testing
occurs on different hardware like it did for this project. After I/O is functional on the
development board, logic can be added and debugged in a black box. When migrating to the
control board, only the I/O blocks need to be swapped. If a signal needs to be sourced from a
different hardware block, only a single line of code will have to be changed. This allows testing
CAN and ADC based signals via GPIO if hardware is unavailable. It also provides the ability to
verify the system in software by emulating the hardware blocks.

5
Some drawbacks of this design include reduced performance and a one abstraction for all
hardware. Since every signal is being buffered after input and before output, resource utilization
is higher. Another issue is generalizing CAN, GPIO, and ADC into a single model even though
they have different hardware characteristics. For instance, ADC signals take more clock cycles to
read compared to GPIO signals and CAN signals are usually read via an interrupt subroutine.
This can cause problems when swapping between I/O sources since processing logic may vary.

The VCU needs to perform computations at a constant frequency for CAN communications.
Since the motor controller broadcasts CAN messages at either 10Hz or 100Hz, 100Hz was
chosen as the computation frequency [2]. Figure 2 is a block diagram of program flow. Note that
the combined computation time for these processes must be less than 10ms to achieve the target
frequency.

Figure 2: VCU Program Flow

The System Tick Timer (SysTick) module of the MKE18F16 was used to synchronize the
computations [3]. After the SysTick module is configured, an interrupt triggers every 10ms and a
flag is set. After all computations are performed, the main loop clears the flag and spin locks
until another SysTick interrupt occurs. Because the MKE18F16 core clock was configured to
60MHz, the VCU was able to update at a stable 100Hz.

6
Motor Logic
The motor logic handles communication between the VCU and the motor controller. It also
guarantees safe transitions between the standby and driving states. Figure 3 is a state machine
diagram of the motor logic.

Figure 3: Motor Logic State Machine

The THROTTLES_VALID signal ensures the 2 throttle signals are within 10% of each other as
required by rule T.6.2 [1]. Rule EV.2.4 is satisfied by using THROTTLE_AVG and
BRAKES_ACTIVE to transition between states [1]. If the throttle is engaged above 25% and the
brakes are active in the driving state, the vehicle immediately returns to the standby state. The
driving state cannot be entered again until the throttle falls below 5%.

While in the standby state, the motor controller is disabled by the VCU. Once the driving state is
entered, the VCU will disable the motor controller inverter lockout by sending a torque request
of 0Nm [2]. Torque requests are then linearly mapped from 0Nm at 0% throttle to 228Nm at
100% throttle. The motor controller accepts requests via a CAN message with an ID of 0x0C0
[2]. Figure 4 is the format of the CAN frame for sending command messages containing torque
requests.

7
 Figure 4: CAN Frame Format for Torque Requests

Shutdown Logic
The shutdown logic is responsible for safely transitioning the vehicle into the driving state. It
directly controls the motor logic via the AIR_POS and AIR_NEG signals. Figure 5 is a state
machine diagram of the shutdown logic.

Figure 5: Shutdown Logic State Machine

8
The shutdown logic controls the pre-charging process of the motor controller. It achieves this by
enabling AIR_NEG when in the pre-charging state and waiting 4s for MC_VOLTAGE to reach
at least 90% of BMS_VOLTAGE. Once the motor controller is sufficiently powered, AIR_ON
goes high and the VCU transitions to the charging ready state if a charger is connected or the
driving ready state if no charger is connected. The TS_READY_SENSE signal acts as a master
switch that causes a transition to the AIRs off state if it goes low.

Redundancy Logic
The redundancy logic evaluates logic equations to control MCU_REDUNDANCY_1 and
MCU_REDUNDANCY_2 for software safety. Equations 1 and 2 are used to determine these
signals.
MCU_REDUNDANCY_1 = BSPD_OK && IMD_OK && BMS_OK (1)
MCU_REDUNDANCY_2 = BSPD_OK && IMD_OK && BMS_OK (2)

Note that the BSPD_OK signal used for the redundancy logic is calculated in software by
Equation 3.

BSPD_OK = !((CURRENT_SENSE > CA) && BRAKES_ACTIVE) && BRAKES_VALID (3)

This is required to satisfy rule IC.4.8 in the case of a hardware failure [1].

System Integration & Testing

Development Testing
Initial testing occurred periodically as VCU logic was being developed. Basic signal processing
and programming logic was debugged on the development board. The shutdown logic was
implemented first due to its simplicity and was tested via GPIO and ADC inputs along with a
power supply. The redundancy logic was added next. It was verified in the same manner as the

9
shutdown logic . Lastly, the motor logic was implemented and tested with the motor controller.
Figure 7 is a picture of the testing setup used to verify the motor logic.

Figure 7: Testing Setup with Motor Controller

A CAN analyzer was used to debug communications between the microcontroller and the motor
controller to ensure CAN messages were exchanged at the correct frequency. Testing with the
motor controller also demonstrated its functionality and how to properly operate it without
inducing system faults.

Bench Testing
Once the control board was fabricated, firmware was ported over and the I/O blocks were
adjusted to accommodate the new hardware. Because of its modular design, VCU logic did not
have to be retested. Figure 8 is a picture of the control board.

10
 Figure 8: Cal Poly Racing Control Board

After the battery box was completed, initial system testing began outside of the vehicle. This was
done to find major issues before placing the components in an enclosed space. Bench testing
comprised of the Power Distribution Module (PDB), VCU, BMS, motor controller, and electric
motor connected via the front and rear harnesses. Shutdown and motor logic were verified with
the electric motor powered by the battery. Figure 9 is the setup used for bench testing and Figure
10 is the electric motor assembly used to spin the motor outside of the vehicle.

Figure 9: Testing Setup with Battery Box

11
 Figure 10: Electric Motor Assembly for Bench Testing

After fixing bugs in the shutdown logic, the electric motor was spun using console commands
delivered via Universal Asynchronous Receiver/Transmitter (UART). Some important safety
checks that were bypassed during testing were throttle checks, brake checks, and the motor
controller enable switch. This was done due to a lack of hardware at the time.

System Testing
The motor controller and electric motor were mounted in the chassis for system testing. The tests
performed during bench testing were performed again with the addition of the throttle and brake
pedals. Figure 11 is a picture of the motor controller and battery box wired inside the vehicle
while Figure 12 is a picture of the electric motor mounted to the chassis and attached to the
drivetrain.

12
Figure 11: Battery Box and Motor Controller Inside Chassis

Figure 12: Electric Motor Connected to Drivetrain

13
One major issue that occurred was a recurring IMD fault. This occurs if there is a short in the
high voltage electronics. The problem was eventually traced to the high voltage connectors
between the motor controller and the battery box. Due to improper construction, the shielding of
the cable was being shorted to the power line. After the cable was reworked, the motor controller
successfully pre-charged and the electric motor was spun inside the car.

Another issue arose when testing ADC signals while the electric motor was on. Electromagnetic
Interference (EMI) from the motor induced high frequency noise into the throttle and brake
signals. This was problematic because it caused multiple safety checks to fail and rendered the
car inoperable. To reduce the noise, low-pass filters were added to the ADC inputs on the control
board. 16 sample hardware averaging was enabled in the ADC driver to further smoothen the
signal. Figure 13 is a graph of the filtered throttle signals. Note that the electric motor was
activated after 15s.

Figure 13: Filtered Throttled Signals with Electric Motor EMI

14
Wheel speed measurements were calculated by catching rising edges of the signal and timing its
period. The conversion to RPM is given by Equation 4.

WHEEL_SPEED = ((60 / RELUCTOR_TEETH) * TIMER_FREQUENCY) / SIGNAL_PERIOD (4)

RELUCTOR_TEETH corresponded to the number of teeth on the reluctor wheel while

TIMER_FREQUENCY was the frequency of the timer module used to time the signal. The
reluctors had 20 teeth and the timer was set to 125MHz. This frequency was chosen in order to
capture wheel speeds as slow as 6RPM. Figure 14 is a picture of the wheel assembly with the
reluctor and hall effect sensor.

Figure 14: Reluctor Wheel with Hall Effect Sensor

Figure 15 is a graph comparing the wheel speed from the VCU with the motor speed from the
motor controller. The calculated speed closely follows the speed of the motor with some minor
spikes. Note that the motor spins faster than the wheels because of a 42:13 gear ratio.

15
 Figure 15: Wheel Speed vs. Motor Speed

Vehicle Testing
The vehicle was first tested off the ground to make sure the safety checks were functional and the
electric motor could be operated with the throttle pedal. The electronics were then packaged and
a driver was placed in the vehicle. For the first run, torque was limited to 10Nm. The
pre-charging process was done with the wheels on the ground and safety checks were reverified.
The car was then driven outside the hanger in 25ft sprints. After confirming that the VCU could
transition between the standby and driving state without faulting, the torque limit was increased
to 20Nm and several runs were performed to collect data. On occasion, the VCU would
transition into the standby state even though the driver was operating the vehicle correctly. The
logging data revealed one of the brake sensors was near its lower threshold in steady-state. This
was fixed by lowering the threshold so that the brake safety check would not trigger accidentally.

Before the competition, the vehicle has to be tested at a higher torque limit and for a longer
duration. Outstanding electronics, such as the IMU or dashboard, have to be system tested with
the VCU before integration. Lastly, calibrated sensors have to be periodically checked to ensure
sensor drift does not occur.

16
Experimental Features

Power Limiting
Power limiting was handled in an active manner. Previously, the power draw from the battery
was estimated by multiplying the requested driver torque with the current speed of the motor.
Although it was easy to implement, it had the drawback of prematurely limiting power. The new
design calculates power draw based on the voltage and current reported by the motor controller.
Because the low voltage electronics do not require a substantial amount of power, this estimate is
very close to the actual power draw from the batteries. The power limiting system them reduces
the torque with Equation 5.

TORQUE = TORQUE - (POWER - THRESHOLD) * (POWER - THRESHOLD) (5)

The threshold can be set by the driver but defaults to 60kW. A quadratic drop off is used to
rapidly decrease torque if the power draw is much higher than the threshold. This aggressive
reduction is necessary to prevent violating rule EV.1.4 [1]. If the threshold is at 60kW and the
power draw is 65kW, torque will be reduced by 25Nm; if the power draw is 70kW, torque will be
reduced by 100Nm.

Traction Control
Traction control design was restricted by rule EV.2.2 which prevents raising the requested driver
torque [1]. This created a nonlinear control problem that could not be solved with linear control
laws such as PID control. More specifically, the integral and derivative controllers could cause
system instability due to the nonlinearity.

Another issue was that control systems require a stable signal for reference. Ideally, this would
be computed using an Inertial Measurement Unit (IMU) and the front wheel speeds. A
complementary filter would combine these signals by filtering out the low frequency noise from

17
the IMU accelerometer and the high frequency noise from the front wheel speeds. Unfortunately,
the IMU was not completed in time for system integration.

The proposed solution only considers the front and rear wheel speeds for traction control. It first
checks if the rear wheels are spinning faster than the front wheels. This is to determine if the
vehicle has entered a slip condition. A new torque value is then computed using Equation 6.

TORQUE = TORQUE - 0.1 * (REAR_WHEELS_SPEED - FRONT_WHEEL_SPEED) (6)

Because of the initial check, the new torque value will always be less than the original torque. If
the rear wheels are spinning at 200RPM while the front wheels are spinning at 100RPM, torque
is reduced by 20Nm. The idea is to slow down the wheels enough to gain traction without
overpowering the driver. The 0.1 scale factor is a parameter that can be adjusted and should be
empirically determined for optimal performance.

Final Words
These features are strictly experimental and have not been tested. They are solely based on
theory and need to be verified at low speeds before running on the racetrack. However, the
vehicle currently has other issues that need to be fixed beforehand. The battery has to be tested
with a more demanding load to find the ideal threshold for power limiting. In regards to traction
control, the wheel speed readings are currently not suitable for mathematical operations. The
sensors do not have enough drive to reach 5V when connected to the harness and EMI from the
motor disrupts the period timing by introducing extraneous rising edges. Once the hardware has
been fixed, the sensors need to be tested at speeds greater than 1000RPM. After these steps are
completed, traction control can be enabled and adjusted incrementally.

18
Appendices

Acknowledgments
I would like to thank FSAE electronics members Oliver Ousterman, Graydon Wilson, and
Hunter Borlik for assistance with this project. Oliver helped me understand the functionality of
the VCU at a system level and provided the project requirements with state diagrams. Graydon
assisted with testing since he was in charge of the BMS for the vehicle. We worked in tandem to
debug critical components of the car such as the electric motor and safety mechanisms. Hunter
aided in implementing CAN and testing communications between devices over the harness.

Lastly, I would like to thank Dr. Andrew Danowitz for serving as my advisor. This project would
not have been possible without his support and guidance.

References
[1] Formula Society of Automotive Engineers, “Formula SAE Rules 2019,” Society of
Automotive Engineers International, 2018. [Online]. Available: https://
www.fsaeonline.com/cdsweb/gen/DocumentResources.aspx. [Accessed May 26, 2019].
[2] Rinehart Motion Systems, “RMS CAN Protocol,” PM100DX/DZ datasheet, May 2018.
[3] NXP Semiconductors, “Kinetis KE1xF Sub-Family Reference Manual”, MKE18F512
datasheet, Jul. 2018.

19