The Kiira EV SMACK is a hybrid electric vehicle developed by the Kiira Motors Project to expand the range of her first prototype - the fully electric Kiira EV- as well as support her vision of being at the forefront of the emerging automotive industry in Uganda [1].

Hybrid vehicle powertrains are typically designed with an engine and at least one electric machine in a series, parallel or series - parallel configuration [2]. The SMACK is based on a series hybrid configuration with 64 lithium ion cells and a 4-cylinder engine-generator set connected via a converter to an electric motor. The electric motor is coupled directly to the front axle using a single gear ratio for propulsion. The engine extends both power assist and onboard charging roles

The introduction of alternative fuel solutions into the vehicle has led to an increase in the number of vehicle subsystems especially in the powertrain, with each having a control unit that requires centralized control. The master control unit (MCU) provides this top level control logic. The extra energy resources in a hybrid vehicle create a need for the MCU to implement an efficient energy management module alongside its other roles.

This paper discusses major steps taken to implement the MCU logic for the Kiira EV SMACK using a model based design approach. A detailed account of the switching strategy employed for energy management is also given.

The roles of the MCU in the Kiira EV SMACK include initiating vehicle startup, monitoring vehicle operation, implementing a shutdown sequence and providing energy-, thermal- and fault management strategies. To achieve this, it communicates with the control units using a two-level architecture illustrated in Figure 1. The architecture was realized using a use case analysis for each MCU signal as defined in Table 1.

Table 1: Sample use case analysis for the master controller.

Figure 1: System architecture.

System architecture and requirements

All the CAN-enabled control units were networked on a twolevel architecture using the CAN2.0B version of the Bosch vehicle bus system. The components connected to the vehicle bus include a battery management system (BMS), two motor control units, a shift selector and display units (instrument cluster and CANvu). A summary of the specifications for the control units connected to the master controller are given in Table 2.

Table 2: Summary of component specifications.

The MCU logic was designed to receive battery parameters on the low speed CAN channel at speeds of 250 kbps to communicate with the motor controller, generator controller, instrument cluster and at 500 kbps with the electronic shift selector on the high speed channel. The MCU also controls various relays and contactors for the precharge sequence of the electric motors (drive motor and generator) and enables the high voltage connection to the DC-DC Converter. It also interacts with other components using analogue connections such as the accelerator pedal, body electronics and relay switches connecting the thermal management system.

Implementation

The design was implemented using the MotoHawk development tool built by Woodward to work with the MATLAB Simulink Environment. MotoHawk allows developers to write code that runs on MotoHawk-enabled electronic control units. It plays a key role in model based design, i.e., it enables code and model re-use through user defined libraries, facilitates rapid prototyping and testing on production grade hardware, as well as design verification through simulation [3].

It also features an option for auto generation of code documentation.

The selection of the Motohawk development tool was based on the benefits of model based design for a startup as discussed by Sameer and Jonathon [4] such as reduced production time and costs. The major steps followed in developing the software using MotoHawk include:

1. Model definition; splitting the complex control system into smaller components called models which can be designed and tested independently. The models could represent an entire subsystem control unit or may be functional models such as the Kiira EV SMACK energy management module. This simplifies development and fosters developer collaboration.

2. Implementation involves writing the control logic using Simulink blocks and Stateflow. MotoHawk features blocks that target particular Woodward hardware platforms. It also has vehicle specific blocks such as specific engine control, analog and digital I/O, CAN, calibration, fault management and diagnostics, and automated documentation.

3. Code generation is done using a compatible compiler such as Greenhills, CodeWarrior or GCC. This creates a file which can be flashed directly onto the hardware.

4. Calibration involves modifying block data at runtime using the MotoTune tool. Calibratible blocks can have default values which are edited as the generated code runs directly on the hardware, hence providing flexibility for values that are only determined at runtime. This step is not applicable on production hardware modules.

5. Flashing the target hardware with the generated code is the final step which is achieved with a Boot Key.

The implemented logic is as follows:

1. Drive Inputs: At startup, the MCU responds to drive commands from the drive inputs; shift selector, start button, accelerator and brake pedals. Based on the shift selector position and pedal position, it determines the vehicle state as idle, operational or shutdown. It also computes torque commands. A dual channel accelerator pedal provides a voltage of 0-5 V which is mapped to a position percentage, 0-100%. The MCU uses a pedal position index array to determine dynamic torque command values (-Torque_min to Torque_max) using a torque-pedal map lookup table. The position can be mapped against the motor torque using a linear interpolation as illustrated in Figure 2 which is based on an electrical machine with a maximum rated torque of 157 Nm. Research also shows that accelerator pedals can be calibrated with braking and regenerative braking regions Boekel, Besselink, Nijmeijer [5] based on the vehicle performance target [6].

Figure 2: Torque - pedal map.

2. The drive selector communicates position messages over the high speed channel to the MCU which interprets these messages and sends them to the motor control unit. A torque request and position messages enable the motor control unit to respond with torque commands to the drive motor.

3. Battery Management System: The BMS monitors the battery cells for state of charge, battery temperature, battery voltage, V_batt, current, battery pack health and fault status. The MCU uses these parameters in motor operation, switching drive regimes, thermal management, fault mitigation, vehicle startup and shutdown.

4. Motor Control Unit: The motor controller and MCU follow a strict handshaking protocol to transition between motor states. There are seven motor states; Initialization, Standby, Startup, Operational, Tear Down, Close Down and ReadyToShutdown. In the Initialization state the MCU sends an Enable signal to the motor control unit and initiates the motor pre-charge sequence by closing the HV (high voltage) contactors. The motor system moves into the Standby state during which the motor control unit sends a StandbyReady signal to the MCU. The MCU ensures that the shift selector is in the Park Position and sends 0 Nm Torque Request. In the Startup state, it ensures that the high voltage at the motor contactors is equal to the battery voltage, V^batt reported by the BMS. If V^batt ≥ 180 V, the minimum operating voltage of the motor, and the pre-charge sequence is complete it sends a Startup Ready signal to the motor control unit. When the motor goes into the Operational state, it readily responds to torque requests and drive selector changes between Reverse, Drive and Neutral. The MCU initiates the shutdown sequence by sending a shutdown request and deactivating the Enable signal. The above control logic was implemented using State flow.

5. Generator Control Unit: There are three use cases implemented by the MCU for this module; Initialization, Throttle Request and Monitoring. The Initialization use case is characterized by the MCU sending an Enable signal to initialize the engine-generator set start up, a Crank Engine signal and disabling torque requests. It then computes and sends throttle requests as summarized in Figure 3. When running, the MCU logs status information from the generator control unit.

Figure 3: Throttle request activity diagram.

6. The CANvu display indicates drive state information, motor and battery parameter information as well as fault information from the MCU. This unit has the capability to provide fault management i.e., display information on how to correct and clear faults.

The Kiira EV SMACK powertrain drive mode selection is based on three drive regimes: Purely electric, Engine only and Hybrid. Energy resources are dynamically drained and replenished during vehicle operation, the MCU decides whether to implement a switching strategy or to maintain the current drive regime. In the EV mode, only the battery powers the electrical machine while in engine only mode, the engine powers it. The engine-generator configuration is designed to charge the battery pack in this mode. When the switching strategy is well-designed, the purely electric mode operates at low start/stop speeds, the engine is only run at maximum efficiency, and the hybrid mode provides range extension benefits.

• Purely Electric: In this regime the final drive is powered by batteries only. No engine charging is possible. This drive regime is operable when the battery SOC is above 80% and vehicle speed is below 50 km/hr. At such low speeds the power requirements can be sustained by the battery system. 50 km/hr is chosen because it is the speed limit for the Kampala city drive cycle, therefore operating the drive train at zero tail pipe emissions is desirable. When the fuel level is below 8%, the engine cannot operate on an empty tank; therefore the only possible drive regime is purely electric. Figure 4 shows the rules which govern vehicle operation in this regime

Figure 4: Purelyelectric drive regime.

• Engine Only: In this mode, the engine powers the vehicle; the battery system is disabled by opening the battery contactors. This mode is engaged at vehicle speeds above 50 km/hr and fuel capacity above 8% to ensure engine is not started with an empty tank. At such speeds, the power requirements are high and therefore, the engine can be operated in the efficient operating regions. If the battery SOC is below 20%, the SC enables battery charging to avoid draining the battery beyond this limit below which it has a degraded performance.

• Hybrid Regime: In this mode, the engine and battery systems provide power either simultaneously or interchangeably. This drive regime can sustain the vehicle operation at very high speeds (above 120 km/hr) and hill climbing.

The detailed description of energy management and drive control regimes is summarized in Table 3.

Table 3: Drive regimes based on current powertrain parameters.

The management of the drive-train power sources is also based on two (2) operating modes;

1. Automatic Control Mode: In this mode, the selection of the active optimal drive regime is based on rule-based deterministic control taking current battery SOC, engine fuel capacity and vehicle speed metrics upon which the decisions on electric only, engine only or hybrid drive regimes are made.

2. Manual Control Mode: In this mode, control is switched from the SC to the driver. The driver can then select the drive regime as desired.

During operation, the heat generated by the machines in the engine bay needs to be extinguished. A thermal management module employing pumps, fans and radiators is used. The mechanical system is connected using relay switches to the MCU The MCU determines when to turn on/off these auxiliary units based on a predefined threshold value. This maintains an optimal temperature for the machines in the engine bay and cells in the battery pack. Two independent systems are used; one for the batteries and another for the engine and motors.

An air cooled system is used to keep the batteries at optimum operating temperature. The system utilizes cooling ducts that conduct cool air to the battery bank. The flow of the air is accentuated by a blower/fan controlled by the MCU. The development of the thermal control strategy was targeted towards a tropical climate where temperatures range from 15-35°C. As such, cooling the batteries to a desired temperature rather than battery heating was the core focus of this module. The control strategy for the cooling of the battery pack is an ON/OFF strategy where the fan is switched on once the battery temperatures reported by the BMS exceeds a set threshold, T_batt,max. The MCU controls the Fan Enable Signal of the BMS by switching ON/OFF of a relay.

The fans continue running until the temperature of the battery pack goes be below the T_batt,max temperature threshold. The fans run at a single speed and do not support PWM functionality. Possible avenues to improve the functionality of this control strategy of thermal management include:

1. Thermal management for both low and high temperature thresholds hence battery warming and cooling so that the vehicle can perform optimally in diverse weather conditions.

2. PWM Support for the Fan operation. This improves functionality by providing different fan speeds based on the temperature of the battery pack. A large difference between battery pack temperature and predefined threshold would imply a high fan speed whereas a small difference between battery pack temperature and predefined threshold would imply a low fan speed.

Thorough V&V (Validation and Verification) tests were carried out to ensure conformity with design requirements and component manufacturer recommendations minimize costly re-design/repairs and eliminate unexpected system behavior. These tests were carried out both off-board and on-board on each subsystem connected to the MCU. The off-board tests were made on both isolated and integrated sub systems and in some cases were characterized by dummy input data to simulate various operational conditions. This set of tests was fundamental in both design validation and verification while the onboard tests mainly targeted verification concerns. The on-board tests were based on real load data with all system components integrated into the vehicle. Table 4 shows a test specification used to carry out functional tests on the MCU (Figures 5-7).

Table 4: Summary of test specification for acceleration test case.

Figure 5: Hybriddrive regime.

Figure 6: Engineonlydrive regime.

Figure 7: Off-Board and on-Board Testing.

The Master Controller is a module central to interfacing and controlling different vehicle control units for synchronous operation. This paper has illustrated the major considerations taken while implementing the firmware on this module for the Kiira EV SMACK hybrid vehicle. The design utilizes the typical two-level control architecture for the CAN based control units and a model based software design approach making it highly scalable. Future prospects include having body electronics controlled by the controller and addition of smart features such as park assist and collision avoidance to this module.

The Kiira Motors Project is funded by the government of the Republic of Uganda. The authors are thankful for all the funding that has supported the work leading to the realization of the Kiira EV SMACK vehicle. The entire participating research and support team on this project is appreciated for their contribution.