Design of vehicle controller system technology based on μC/OS-II

There are many subsystems in the hybrid power system. The vehicle controller, as a management system to achieve the driver's driving needs and energy safety, needs to coordinate the reasonable distribution of the engine, torque, motor and battery power under different working conditions, realize braking energy feedback, and control peripheral equipment (such as air conditioning, lighting) to achieve the best energy-saving and emission effects. The complexity of system tasks and the strong electromagnetic interference environment pose major challenges to the real-time and reliability of the vehicle controller. The traditional single-task cyclic program control mode is difficult to meet the requirements. This paper uses the open source embedded operating system μC/OS-II to design the vehicle controller system software.

1. Vehicle system structure

The fully hybrid sedan developed is a major special project of Tianjin, based on the Great Wall Harvard SUV sedan. The vehicle power system is mainly composed of an engine, an AC motor, an AC generator, a high-performance nickel-hydrogen battery, a planetary carrier power distribution mechanism, and a DC-AC inverter. The vehicle controller uses a bus to exchange information with the engine management system, the motor controller, and the power battery pack management system, and a CAN channel is reserved for later communication with the body system.

The vehicle controller controls the operation of each subsystem according to a certain strategy based on the driver's input signal, the battery pack status and the current vehicle operation status, to achieve the goal of energy saving and emission reduction. The system network topology is shown in Figure 1.

2 Vehicle Controller Hardware Design

According to the modular principle, the hardware design of ECU can be divided into the following functional modules: microcontroller module, data acquisition module, power drive and protection module, D/A conversion module, power module, communication module, display and alarm interface and calibration diagnosis interface, etc. Infineon's XC164CS microcontroller is used, which is based on the enhanced C166SVZ core and has better performance than other 16-bit microcontrollers: internal integrated DSP function, extended interrupt processing capability, powerful on-chip peripherals and high-performance on-chip Flash, as shown in Figure 2.

3. Porting of μC/OS-II

The μC/OS-II embedded real-time operating system is written in ANSI C language, which has good readability and portability; it does not require high hardware resources and can be ported to most 8-bit and 16-bit microcontrollers.

3.1 Starting μC/OS-II

First, the hardware driver is called to initialize the hardware, and then the system initialization function OSlnit() is called to initialize all variables and data structures of μC/OS-II.

[page]

Before starting μC/OS-II, create an application task. OSlnit() creates an idle task idletask, which is always in the ready state. The priority of the idle task OSTaskIdle() is set to the lowest, i.e. OS_LOWEST_PRIO. The user needs to call OSStart() to start multiple tasks. Of course, there are other settings, which will not be introduced here one by one.

3.2 Porting of μC/OS-II

The transplantation of μC/OS-II operating system on XC164CS microprocessor mainly realizes the processing of three files: OS_CPU.H, OS_CPU_C.C, OS_CPU A.ASM.

3.2.1 Header file INCLUDES.H

The INCLUDES.H header file should be included as the first line of all C files. Although including unrelated files may increase the compilation time of the file, it enhances the portability of the code. Users can edit and add their own header files, but they must be added at the end of the header file list.

3.2.2 OS_CPU.H File

The OS_CPU.H file contains the definitions of processor-related constants, macros, and structures. For the XC164CS processor, the stack data type is defined as 16 bits, and the stack decreases downward; the two macros OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL() of μC/OS-II control interrupts are defined as instructions for the microcontroller to turn off (SETC) and turn on (CLRC) interrupts; the OS_TASK_SW() function is declared, and the entry of the interrupt service routine ISR points to the function OSCtxSw().

3.2.3 OS CPU A.ASM

When porting μC/OS-II, users are required to write four assembly language functions: OSStartHighRdy(), OSCtxSw(), OSIntCtxSw(), and OSTickISR().

(1)OSStartHighRdy()

Calling this function starts the task with the highest priority in the ready state. Since the real-time operating system is a non-returning function, the return address at the top of the stack needs to be removed after the call, and then the user call function OSTaskSwHook() is executed, and finally the multi-tasking is started, the pointer of the task with the highest priority is obtained, and all registers are restored from the task stack according to this pointer. After the restoration, the interrupt return is executed to run the ready state task.

(2)OSCtxSw()

When switching from a low-priority task to a higher-priority task, the task switching function OSCtxSw() is called to save the contents of the processor and the task pointer to the task stack of the current task, and then the user calls the function OSTaskSwHook(), and finally restores the registers and stack contents from the task stack of the task to be executed, and executes the interrupt return instruction to start running the new task.

(3)OSIntCtxSw()

When it is necessary to switch to a higher priority task after an interrupt occurs, the interrupt-level task switching function OSIntCtxSw() is called, and then the user call function OSTaskSwHook() is executed. Because this function is called in the interrupt program, there is no need to save the registers of the interrupt task; when the interrupt subroutine calls the function OSInExit(), the return address is pushed into the stack. There is no need to return here, so the return address must be cleared from the stack.

(4)OSTickISR()

OSTickISR() is the clock tick interrupt service routine in μC/OS-II. This function is called at each clock tick, and the delay of each delayed task is reduced by 1, and all delayed tasks are checked to see if the delay ends and become ready tasks. Then OSIntExit() is called. If a task with a higher priority is ready, OSIntExit() will schedule the task. OSIntExit() does not return to the caller, but uses the content in the new task stack to restore the CPU scene, and returns from the interrupt to execute the new task.

[page]

3.2.4OS_CPU_C.C

The user needs to write 6 C language functions: OSTaskStkInit(), OSTaskCreateHook(), OSTaskDelHook(), OSTaskSwHook(), OSTaskSatHook(), OSTimeTickHook(). Among them, the only necessary one is OSTaskStkInit(), and the other 5 functions must be declared but do not need to contain code.

OSTaskStkInit() is called by the task creation function OSTaskCreate() or OSTaskCreateExt() to initialize the task stack when each task is created. Starting to run this task is to simulate an interrupt return and restore the values ​​saved in the stack after initialization to each register. When initializing the task stack, the task code start pointer (Ptask), parameter pointer (Pdata), and task stack top pointer must be passed. After the task stack is initialized, a new stack top pointer is returned, and OSTaskCreate() or OSTaskCreateExt() saves it to OSTCB.

Five hook functions can be created in the OS_CPU_C.C file. The prerequisite for use is that the constant OS_CPU_HOOKS_EN in the configuration file is enabled.

At this point, the porting of the μC/OS-II operating system is basically completed.

4 Multi-task design of vehicle controller software

The vehicle controller software design uses the real-time operating system as the development platform, decomposing the application into multiple tasks, simplifying the system software design, ensuring the real-time performance of the vehicle control system, and improving the stability and reliability of the system. The main program flow of the entire system is shown in Figure 3.

4.1 Timer Module

The main function of the timer is to provide a reference clock for the software program. This application selects T5 as the clock reference and completes the module register configuration in the initialization function void GPT_vInit(); the interrupt service program is set to OSTicklSR(), and the interrupt vector is 0x25. By establishing the clock task function Timer_Int() and calling the clock tick function OSTimeTick(), the connection between the timer and the system clock is realized. The system clock tick is programmed to 1 ms, which can reduce the interrupt service time and improve real-time performance.

4.2 CAN Communication Module

[page]

The function of the CAN communication module is to realize the information transmission between the vehicle controller and other nodes. The transmission is periodic, the transmission period is 20 ms, the communication rate is 250 kbps, and the CAN communication service program is called by interrupt.

Create a CAN communication module task CAN_Trans, task priority 3:

4.3 A/D Module

The function of the A/D module is to read the battery voltage, accelerator pedal sensor and throttle position sensor signals, perform analog-to-digital conversion, and be called by other functions.

Create the A/D conversion module task ADC_Cony, task priority 4:

4.4 Vehicle control main program module

After the self-test of each module of the hybrid vehicle system is successful, the vehicle controller requires starting the battery and entering the normal EV working mode. Then, by judging the gear position, key switch and accelerator pedal information, different processing modules are entered. The control strategy includes the vehicle control strategy and energy flow management strategy to achieve control output based on the torque algorithm.

Create the vehicle control main program task Drive_Ctr, priority 9:

OSTaskCreate(Drive_Ctr, (void*)&Drive_Ctr[OS_TASK_STK], 9)

Due to space limitations, other modules will not be introduced here, but the general process is similar.

Conclusion

With the continuous development of automobile technology and increasingly stringent regulatory requirements, automotive electronic systems will become more and more complex, and the use of operating systems to manage and coordinate complex tasks will become an inevitable trend.

This paper describes the μC/OS-II system transplantation process in detail through the hardware and software design of the hybrid vehicle controller, optimizes the system software design, and fully meets the system requirements. The actual vehicle test has achieved good results.