uC/OS-II 在电动车电池管理系统中的应用研究

μC/OS-II在电动车电池管理系统中的应用研究

尹叶丹，吴友宇，程昌银
（武汉理工大学 自动化学院，湖北，武汉 430070）

摘要：电池管理系统是电动车的关键部件之一。本文介绍了电池管理系统具有多任务、实时性的特点。开发了一套基于TMS320LF2407 DSP与CAN总线设计的电池管理系统。提出了在软件开发中引入嵌入式实时操作系统μC/OS-II。并重点详述了μC/OS-II在该系统中的移植与应用。实验表明，该电池管理系统实时性好、可靠性高。
关键词：μC/OS-II，实时操作系统，电池管理，TMS320LF2407

1 引言
μC/OS-II是由美国人Jean Labrosse 编写的一个源码公开的嵌入式实时操作系统内核。它从1992年开始为人所知。μC/OS-II是一种占先式的多任务操作系统，可固化，可裁减，移植性好。μC/OS-II功能强大，支持56个用户任务，支持信号量、消息邮箱、消息队列等多种常用的进程间通信机制，现已成功应用到众多商业嵌入式系统中，其稳定性与可靠性已经得到检验[1]。
各类电动车的研究与开发目前在国内已经掀起了高潮，国家、地方以及越来越多的汽车公司都投入到这个前途光明的朝阳产业的研究中。混合动力电动车、燃料电池纯电动车是当前研发的主要方向。蓄电池不可避免地成为电动车辅助能源。镍氢电池、锂离子电池等因为其容量大、体积小、动力性较好而成为目前电动车研发的首选动力电池。对电池的过充电过放电很容易造成电池的损坏，并大大降低电池寿命。而如何能根据所用电池的特性，对其安全有效的使用即电池管理系统（Battery Management System，BMS）的设计成为关键。BMS负责实时地估测当前的电池容量，即荷电状态（State of Charge，SOC），以及对各电池组进行电压均衡，判断是否出现不正常电池单元，并发送报警信号。SOC估测方法的准确性已成为电动车研发的瓶颈之一，在世界范围内都未取得重大突破。限于篇幅，本文对SOC估测方法不做详细介绍，而主要描述电池管理系统的软硬件实现。

2  BMS的构成与硬件实现
2.1 基于光纤CAN总线的电动车分布式控制系统
电池管理系统BMS是电动车控制系统的组成部分之一。控制局域网CAN总线因为其结构简单，通信方式灵活，抗干扰能力强，目前已经在工业控制，汽车电子领域得到了广泛的应用。CAN总线最初即是德国的Bosch公司为汽车的监测、控制系统而设计的。CAN网络在电动车上的应用能使得各电控单元（ECU）之间的通信极为方便。如果通信介质采用光纤，那么通信介质上的干扰将被完全消除。本文所描述的对电池管理系统的研究是燃料电池电动车研发的子课题。电池采用的是容量为12安时（AH）的镍氢电池。
电动车控制系统一般包括能量流管理系统，电机控制器，燃料电池控制器，显示系统，电池管理系统等，若为混合动力车，还应包括发动机控制器等其他控制器。本文所描述的镍氢电池管理系统ECU（Electronic control unit）与这些控制系统采用光纤构成上层CAN网。而电池管理系统ECU又与24组电池组信息检测ECU构成下层CAN网络。我们所采用的镍氢电池每个基本电池单元提供1.2V左右的电压，10个单元串联构成一个电池组，24个电池组再串联产生约280V的高电压，作为车用辅助电源。设计的电池管理系统BMS及电动车控制系统基本结构如图1所示。
 
2.2 电池管理ECU的硬件方案
电池管理ECU采用TI公司的TMS320LF2407 DSP作为其CPU。主要原因在于其体积小，处理速度快，片内集成了A/D模数转换器和CAN总线控制器[2]。如图1所示，电池管理ECU需要两个CAN控制器。DSP内部集成的CAN控制器（CAN1）接上层光纤CAN网络；我们为系统另外扩展的Philip公司的SJA1000独立CAN控制器（CAN2）作为与下层电池组CAN网络通信用。电池管理ECU的结构框图如图2所示。
由于DSP的数据和地址线是分开的，而SJA1000的数据和地址线是分时复用的。其相互接口是本系统的难点之一。可通过将SJA1000映射为DSP的I/O地址，通过模拟SJA1000的读写时序对其进行读写访问。

3 采用前后台系统的软件设计方法
 在前后台系统中，应用程序被设计成一个无限的循环，循环中调用相应的函数完成相应的操作，这部分可看作是后台行为。中断服务程序处理异步事件，这部分可看作是前台行为。后台行为也称作任务级，前台也称作中断级。时间相关性很强的工作一般是靠中断服务子程序来保证的。中断服务所提供的信息（如标志）一直要等到后台程序（即循环）运行到处理该信息这一步时才能得到处理。这中间的时间间隔称任务级响应时间。这个时间具有不确定性，有时候会很长。可见前后台系统的实时性较差。
本系统的软件须完成的主要功能包括：中断方式接收24个电池组的ECU通过下层CAN总线传出的电压与温度信息，并对数据进行处理；定时采样电池的总电压与电流（采样频率越高则SOC估测效果越好）；通过电压、电流、温度等信息通过一定的算法计算电池SOC值；每隔50ms通过上层光纤CAN总线向控制系统中其他CAN节点发送一次SOC值以及其他信息；每隔1s通过上层光纤CAN总线发送一次所接收的电池组的电压温度信息;对电压偏高或偏低的电池组进行电压均衡；监测不正常情况，随时发送报警信号。
 若采用前后台的方法对本系统进行软件设计，有两种方案供选择。其一，可以将所有的工作都在后台的无限循环中处理，中断服务服务程序只提供标志信息。这样也就会出现上文所述的任务级响应时间的不确定性，实时性较差。其二，可以将大部分的工作，如A/D采样，SOC算法，CAN数据发送等系统中大部分的工作都在中断服务程序中处理。这种方法看起来实时性很好，但由于处理中断服务程序的时间较长，关中断的时间也就较长，所以不可避免的会引起中断事件的频繁丢失。
而若采用μC/OS-II操作系统进行软件设计，则所有的函数与任务的处理与执行时间具有可确定性，因而系统的可靠性将大大提高。下文笔者将详细介绍嵌入式实时多任务操作系统μC/OS-II的移植与应用。
4 移植 μC/OS-II 
TMS320LF2407满足μC/OS-II移植的条件[3]。TI公司提供的编译软件Code Composer V4.10.36也支持C语言与汇编语言混合编程[4]。笔者即在此编译器中进行μC/OS-II移植。
μC/OS-II操作系统的组成文件分为三类，一类是与处理器无关的代码文件，另一类是处理器有关的代码文件以及μC/OS-II与应用相关的设置文件。当然移植工作完成后编写应用程序，还应包括应用文件。移植所需要做的工作仅仅是修改部分与处理器有关的文件。这类文件包括：OS_CPU.H，OS_CPU_A.ASM，OS_CPU_C.C等三个文件。限于篇幅，本文仅描述移植过程的重点与难点。
TMS320LF2407 芯片本身的堆栈只有8级，从AR0到AR7。该C编译器将内部寄存器AR0、AR1保留，AR1作为堆栈指针SP，AR0被作为堆栈中的临时变量指针FP。所以在汇编语言中不要使用这两个寄存器，若一定要用，必须关中断，并注意保存和恢复。TI公司的Code Composer 编译软件里，中断要调用I$$SAVE 保存所有寄存器，各寄存器压入堆栈的先后顺序为：空字、，ST1、ST0、ACCH、ACCL、PREGH、PREGL、TREG、AR0、AR2、AR3、AR4、AR5、AR6、AR7、TOS、6个硬件堆栈，共22个。返回时“跳转”到I$$REST函数，恢复这些寄存器的值，顺序与I$$SAVE相反。这里用“跳转“而不是调用，是因为I$$REST执行完后不一定能返回到开始执行时的地址。
改写OSTaskStkInit()：该函数任务堆栈初始化函数，在创建任务的时候被调用。TMS320LF2407的堆栈是从低地址往高地址递增的。该函数首先获取该任务栈的栈顶地址。然后对该地址进行递增并赋初值。从栈顶地址开始的前两个地址分别装载栈顶地址，数据区地址，第三个地址保留。后面依次为上述寄存器值，从ST1到TOS，TOS装载的是中断的返回地址或任务起始地址，后面再保留6个硬件堆栈地址。该函数返回堆栈指针值，即最尾的地址。
改写OSStartHighRdy()：该函数启动最高优先级的任务。将当前就绪的最高优先级任务的堆栈指针赋于AR1，跳转到I$$REST函数，即可转到最高优先级任务的起始地址。
改写OSCtxSw()：该函数进行任务间切换，为OS_Sched()函数所调用。任务切换用8号软中断来实现。第一步：调用I$$SAVE函数压栈。第二步：为将当前原任务的堆栈指针保存到当前原任务的任务控制块（TCB）中；将处于就绪态的最高优先级新任务TCB地址赋给当前TCB；新任务的优先级赋给当前优先级；将新任务TCB中的堆栈指针赋给AR1。第三步：跳转到I$$REST。
改写OSIntCtxSw()：该函数只能在中断子程序中被OSIntExit()函数调用。由于中断可能会引起任务切换，所以在中断服务程序的最后调用OSIntExit()来检查是否需要进行任务切换。若有比被中断任务的优先级更高的任务处于就绪态，则调用此函数进行任务切换。该函数首先通过执行POP指令弹出调用OSIntCtxSw()时的返回地址，然后调整堆栈指针，然后转到OSCtxSw()函数的第二步执行。要调整堆栈指针的原因是在调用OSIntExit()时保存了返回地址和帧指针等相关的值，所以在进行任务切换前必须将先前任务的指针值恢复到中断前的位置。通过查看进中断后堆栈指针AR1的变化，我们发现程序运行到任务切换时，AR1增加了5个地址，故需要在此函数中将AR1减5，以恢复被中断前任务堆栈的指针。
改写OSTickISR()：时钟节拍中断服务子程序，可采用定时器1周期中断作为系统时钟节拍，这部分编写没有什么难点。但要注意的是一定不要在调用中断嵌套加1函数OSIntEnter()之前开中断。因为这样可能导致直接从非最后层的高优先级中断里切换到任务，这将导致致命后果，程序再也不能进某中断。
改写OS_CPU.H，关键语句如下：
  #define  OS_STK_GROWTH     0 
#define  OS_ENTER_CRITICAL() asm("SETC INTM");
   #define  OS_EXIT_CRITICAL()  asm("CLRC INTM");
#define  OS_TASK_SW()        asm("INTR 8");
按需配置OS_CFG.H。至此，μC/OS-II在TMS320LF2407上的移植就基本完成了。最后的工作是对部分代码进行改写和优化，从而提高运行速度，减少代码空间。本文对此不进行描述，读者可自行尝试处理。

5 应用程序改写
 在本应用中，笔者建立了四个应用任务，优先级分别为4、5、6、7。同时为每个任务分配了一个消息邮箱，使用基于消息邮箱事件的通信机制进行任务间通信与任务切换。整个软件的基本结构如图2所示。
 
 任务AdQTask（）：采样总电压、电流信号，并对电池进行容量（电量）累积。分配邮箱：pAdQMbox。
 任务SocTask（）：进行电池的SOC算法。分配邮箱：pSocMbox。
 任务SendTask（）：通过DSP内部CAN发送SOC值以及电池电压温度信息。分配邮箱：pSendMbox。
 任务SjaRxTask（）：对从SJA1000接收过来的电池组信息进行处理与故障诊断。分配邮箱：pSjaRxMbox。
由上节对堆栈的分析可看出，任务栈最少需要25个地址。笔者为每个任务分配了100个地址（200个字节）的任务栈空间。使用函数OSTaskCreate（）进行创建各任务，该函数的第三个参数为栈顶地址，为OSTaskStkInit()所调用。要注意TMS320LF2407的堆栈是递增的，故应传递任务栈的最低地址。而又由于任务程序是采用C语言编写，编译器对AR1的偏移范围可能会超过任务栈栈顶。虽然在这种情况下AR1是可恢复的，但仍可能会影响最低地址之前的地址内容。所以笔者建议对其进行适当后移。
中断1为SJA1000从CAN总线上接收到数据所引发。在中断1中读取SJA1000缓冲区的数据，然后向邮箱pSjaRxMbox发送标志信号。在中断处理完后即可到任务SjaRxTask（）执行。
中断2为定时器1周期中断。周期设为1ms。每10ms做一次时钟节拍。每个周期1ms向邮箱pAdQMbox发送数据1（标志信号），以使AdQTask（）任务列为就绪态，中断退出时若其为最高优先级任务则转到该任务执行。每50ms发送数据2，以就绪AdQTask（）任务和SocTask（）任务。每1s发送标志数据3，以就绪AdQTask（）任务，SocTask（）任务和SendTask（）任务。
各任务均等待相应邮箱以及相应标志信号。任务恢复后判断邮箱中的标志信号，从而转到相应的功能程序中。
下面列举SjaRxTask（）任务与中断1的中断服务程序的简化代码来描述μC/OS-II的邮箱通信机制，供读者参考。
void SjaRxTask(void data)  /*接收任务*/
{ INT8U  *FlagSjaRx=0;
 INT8U  error; 
 data=data;
 while(1) {
   FlagSjaRx=OSMboxPend(pSjaRxMbox,1,&error);  /*等待邮箱中的消息*/ 
   if(*FlagSjaRx)    /*判断标志信号是否为1*/
      SjaRxProcess(); /*接收数据处理函数*/
}
}
void c_int1()     /*SJA1000的中断服务程序*/
{ OSIntEnter();     /*中断嵌套层加1*/
 count=1;      /*标志信号置1*/
 ……  /*读取SJA1000缓冲区的数据，代码省略*/
 OSMboxPost(pAdQMbox,(void*)&count); /*发送标志信号*/
……  /*清中断标志并释放SJA1000缓冲区，代码省略*/
 OSIntExit(); /*检查是否需进行任务切换，若需要，则进行切换*/
    asm(" CLRC INTM ");  /*开总中断*/
}

6 结语
    如今，PC时代已经到来，嵌入式系统的应用开始无处不在，采用嵌入式操作系统的手机、信息家电等众多的嵌入式产品已经出现。而在相关场合，嵌入式实时操作系统（RTOS）的应用也愈加广泛。采用RTOS的最大好处就是可以提高系统的可靠性与实时性，同时也提高了软件开发的效率，缩短了开发周期。在本系统的软件设计中引入μC/OS-II以后，相比以前的前后台系统，所增加的代码空间为数据约1.5K字，程序约3.5K字，额外消耗的存储器资源较小。而因为μC/OS-II本身的实时特性，使本应用系统的实时性需要能得以满足，从而系统的可靠性也随之大大提高。因此，在一般的中小型实时嵌入式系统中，μC/OS-II是一种理想的选择。
本文从应用与实用的角度出发，详细介绍了μC/OS-II在基于TMS320LF2407内核的电动车电池管理系统中的应用，希望对相关的研究开发人员有所帮助。实验结果表明，该电池管理系统具有设计合理、性能稳定、实时性好、可靠性高等优点，取得了令人满意的工作效果。

参考文献
[1] Labrosse Jean J. μC/OS-II----源码公开的实时嵌入式操作系统. 邵贝贝译. 北京：中国电力出版社，2001
[2] 刘和平等．TMS320LF240xDSP结构、原理及应用．北京：北京航空航天大学出版社，2002．
[3] μC/OS-II在TMS320LF2407A上的移植与应用[J]. 单片机与嵌入式系统应用,2003(5):79-83
[4] 张雄伟,曹铁勇.DSP芯片的原理与开发应用（第2版）[M].北京：电子工业出版社,2000. 
[5] Texas Instruments. TMS320C2x/2xx/5x Optimizing C Composer User’s Guide. 1999

作者简介：
尹叶丹（1979-），男，湖北荆门人，武汉理工大学自动化学院硕士生，研究方向为嵌入式系统与智能控制
吴友宇（1963-）：女，副教授，武汉理工大学信息工程学院，硕士导师
程昌银（1943-）：男，教授，武汉理工大学自动化学院，硕士导师
基金项目：湖北省重大科技攻关项目（2003AA103B）

Research on Application of μC/OS-II in Electrical Vehicle Battery management System 
Yin Yedan，Wu Youyu，Cheng Changyin 
（Automation School, Wuhan University of Technology, Wuhan, 430070, China）
Abstract: The battery management system (BMS) is one of key part in electrical vehicle. This paper introduces the features of BMS that has multitask and real time. A BMS based on TMS320LF2407 DSP and CAN bus is developed. The application of μC/OS-II to its software design is put forward. And the transplant and application of μC/OS-II are particularly described in detail. The experiment shows the BMS to be a system of real time and higher reliability.
Keywords: μC/OS-II, real time operating system, battery management, TMS320LF2407