基于VxWorks的系统故障快速恢复设计

在CDMA基站BTS侧，EVDO基带信号处理板负责完成基带信号的调制和解调工作，在整个通讯系统中具有非常重要的作用。基带处理板的硬件系统包括PPC、高通CSM6800等芯片；软件系统包括VxWorks操作系统、BSP驱动层、信号处理应用层等部分。基带信号处理板在运行中对外界条件和组成单元要求苛刻，当运行条件不满足系统要求时，传统的方法是采用整板硬复位的方法进行故障恢复。

需要整板复位的情况包括：(1)时钟信号出现故障，导致调制和解调异常；(2)CSM6800调制解调芯片出现异常；(3)部分应用层任务出现异常；(4)在线修改基于CSM6800的基带参数，只有硬复位后才能生效；(5)更换新的单板软件版本等。

在基站系统的实际运行中，上述情况都比较常见。基带信号处理单板一旦整板复位，通常需要4～5分钟才能恢复正常工作，期间终端用户无法进行正常业务应用。对于用户来说，这个业务中断的时间长度难以容忍，因此增加了用户投诉概率和对运营商的压力。如何解决这个问题已成为当务之急。

1 单板快速恢复设计方案

1.1 单板架构分析

如图1，基带信号处理单板硬件由两个主要组成部分：一个是主控CPU，采用高性能的PowerPC；另外一个是高通公司的基带信号调制、解调芯片CSM6800。

主控CPU完成对整个单板的控制，包括对CSM6800的控制、与BSC侧进行媒体流数据的交互、单板自身各项功能的实现等。主控CPU采用VxWorks作为实时操作系统，对单板上任务、消息队列、内存等进行管理，采用百兆网口与BTS其他单板交换数据。

　　CSM6800是高通推出的支持CDMA3G EVDO第二代的调制解调芯片，它具有支持前向速率3.1Mb/s和反向1.8Mb/s的调制解调能力。CSM6800的工作条件比较苛刻：(1)需要时钟系统提供精确的PP2S信号和16CHIP信号；(2)修改CSM6800配置参数后，需要复位CSM6800后才能生效。

如图2，在基带信号处理板上CPU中的软件架构是在VxWorks操作系统上完成应用层任务的调度和运行。下面分析单板上软件系统：

(1)操作系统层。基带信号处理板对实时性要求很高，因此采用VxWorks作为操作系统，完成任务管理等操作系统工作。

(2)BSP底层驱动程序。该层封装了一些上层软件需要时使用的底层或者是硬件的接口，保证上层软件更好的移植性。

(3)应用层。该层完成处理底层数据，并与BSC侧完成数据交互、基带功能控制以及包括单板的一些应用程序，如告警模块、性能统计模块、信令跟踪模块等。

从以上分析，基带单板从软件和硬件上基本可以分为相对独立的主控CPU和CSM6800两大部分。

1.2 快速启动方案设计

首先分析基带信号处理板的各种复位场景，并且进行梳理。其场景分为两大类：一类是不需要整板复位就能解决问题或者故障恢复的场景；另外一类是只有复位整板才能够解决故障。在实际的商用环境中，第二类故障或场景非常少，主要包括：(1)基站软件升级；(2)底层操作系统跑死。由于系统升级频率极低，且选择升级的时间都是事先进行安排，因此对于用户业务影响很小。至于底层操作系统跑死的可能性更加低微，无论是实验室还是商用机都极少出现此类情况。

相对而言，第一类场景比第二类场景出现的概率更高一些，目前都是采用统一整板复位的方式来进行功能恢复或者重新启动。

在分析各类场景之前，首先分析整板启动时间消耗在哪里。经过测试和计算，其结果如表1。

分析表1，整体启动时间需要253s左右，但是前四步就占用了245s，尤其是第4步高通CSM6800芯片自检，消耗了170s的时间。

分析了所有的复位源，将可以归类到第一类场景的复位源进行了细化，具体如下：

(1)更改CSM6800参数，需要重新启动CSM6800生效；
(2)时钟系统出错，应用层诊断后，为防止CSM6800出错，需要重新启动CSM6800；
(3)CS6800运行期间报错，需要重新启动CSM6800；
(4)启动时的参数校验错误，需要重新复位系统。

针对(1)、(2)、(3)这三种情况，在PPC上即控制CPU上的程序本身并没有任何问题，因此不需要复位整个CPU。第4种情况是上层的配置参数有误，导致单板无法正常运行，但是实际上此时的单板并没有出现异常，其他各个功能模块也没有出现故障。

由此可见，基带信号处理板在CSM6800需要复位才能实现正常功能时，具有重新设计单板复位机制的基础。这个基础就是CSM6800复位，或者是针对CSM6800操作出现故障后，并不影响CPU操作系统上底层任务的正常运行，只是对CPU应用层任务产生了影响。依据这个分析基础，进行了基于VxWorks的快速恢复机制设计。其具体实施方法为：

(1)流程如图3，首先判断是要发起快速恢复启动还是正常的整个单板复位。

(2)正常的单板复位流程，按照单板原设计方案执行；如果是快速启动方案，则按照快速启动方案执行：
①清除各种定时器，包括单板与基站其他单板的握手定时器、任务自身的循环定时器，以及其他各种特殊用途的定时器，防止定时器溢出产生任务切换或者导致硬件中断。
②清除数据堆栈。
③调用msgQDelete()清除各个应用层任务消息队列[1]；清空后，任务不处理新来的消息，这样任务不会因为消息的激励产生任务切换。
④释放应用层任务的指针变量，防止出现无主内存，最终导致内存不断变小，单板无法执行正常的功能。
⑤清除各个应用层任务的静态变量；每个任务都有自己静态成员变量，因此必须要将这些成员变量的数值归于初始化值，否则将导致不可预见的错误。
⑥清除各个应用层任务的局部变量；尽管局部变量在释放任务后会自动释放，但是为了防止不可预知的错误，仍然要将其释放，进行初始化操作。
⑦各个应用层调用taskDelete()任务释放自己[2]；这个应用层多个任务需要完成的最后一个工作，完成自身释放后，任务构建时所在单板上申请的堆栈、任务ID、内存等全部从操作系统中抹掉，操作系统将把原先各个应用层任务占用的资源进行无主化管理。
⑧通过逻辑控制复位CSM6800；这是关键的一步，如果不能实现，则整个方案意义也就不大。在逻辑中增加可以单独控制CSM6800复位控制的逻辑，当单板完成应用层的快速启动准备后，要通过操作系统对CSM6800芯片进行复位。复位后，该芯片会重新启动恢复正常状态，并且，重新按照应用层给的新的配置参数进行配置。这样即满足了由于某些原因导致其进入到异常状态而无法正常调制和解调的问题，同时也解决了新的配置参数无法生效的问题。
⑨重新启动调用taskSpawn()[3]启动各个应用层任务。按照单板正常情况下进行各个应用层任务的启动。对于应用层而言，此时并不知道在执行快速启动后是任务启动还是在单板完全复位后的启动。
⑩启动的各个应用层任务只有在各自正常启动后，单板才进入到正常的工作状态，否则将重新执行快速启动。

1.3 快速恢复启动效果测试

采用中兴CDMA EVDO真实环境进行测试，选择高通支持第二代协议的手机进行测试。首先，将高通手机拨号进行网络连接，拨号成功后，再进行ping包，并保持ping包状态；然后，采用不同的复位策略复位基带信号处理单板，并进行对比测试。

按照两种方案进行测试，测试结果如果表2。

如表2，快速恢复启动方案的启动时间比原有正常启动缩短了95.3％，大大缩短了系统恢复正常功能所需要的时间，达到了系统设计目的。为了保证设计方案的稳定性，连续多天进行上千次快速恢复启动集成测试，测试表明设计方案稳定，并且对于系统的各方面性能指标无影响。

两种启动方式的区别：正常启动就是目前的做法，将整个单板上所有的硬件和软件同时做复位处理，其所需要时间达到了253s，十分漫长；快速恢复启动方案则并没有将整个单板复位，而只是在操作的过程中将CSM6800进行了硬复位操作，其主控CPU没有复位，不仅如此，主控CPU上面驻留的操作系统和操作系统隔离层都没有受到影响，只有应用层的各个任务被重新启动了一遍。