嵌入式系统下位机故障定位及分析方案研究

董高云，余文兵，周庭梁

（卡斯柯信号有限公司 平台技术中心，上海200071）

在铁路信号领域，大量的安全相关产品（如计算机联锁、车站列控中心、临时限速服务器等）均采用运行于实时嵌入式操作系统的嵌入式下位机来执行核心的安全运算和I/O控制功能，这类产品对实时性有很高的要求，需要确保其安全稳定的运行。安全系统通常可以通过热备冗余设计来实现切换，确保单系宕机不会引起整个系统停机，此外，在出现单系宕机后，还需要在最短的时间内迅速定位下位机故障点，找出故障原因和解决方案，使整体安全系统尽快退出降级工作模式，恢复正常工作。因此，嵌入式系统的下位机故障定位和分析工作至关重要。

近年来，在铁路信号领域，专门针对嵌入式系统的故障分析和相关诊断设计的研究不多，且大多是针对特定的信号系统展开，如轨道交通车辆故障诊断系统设计[1]，独立式智能列车故障诊断系统[2]，基于通信的列车控制系统中计算机联锁系统故障因素分析[3]，铁路信号联锁设备的故障分析[4]等。其它领域针对嵌入式系统故障诊断分析的研究又多集中于特定的算法和方法理论研究，如基于嵌入式的智能故障诊断的研究与设计[5]，基于BP 神经网络的集中监测系统故障诊断[6]，基于大数据的控制系统故障诊断方法综述[7]，嵌入式装备故障诊断专家系统[8]。缺少专门针对铁路信号领域的嵌入式下位机故障类型梳理和故障定位的分析和研究成果。本文对典型嵌入式系统下位机的系统架构进行梳理，并提出相应的故障定位及分析设计方案。

1 嵌入式系统下位机架构及故障类型梳理

1.1 嵌入式系统下位机架构分析

图1 为典型的嵌入式系统下位机架构，由硬件、驱动&固件（包括bootrom、BSP 包等）、嵌入式操作系统（OS）和应用软件层组成。一套2 取2架构的SIL4 级安全系统下位机，通常采用2 个独立的如图1所示的单板板卡来实现组合故障安全。

图1 嵌入式系统下位机架构

如图1所示，最下层为硬件层；bootrom 和BSP包确保硬件上电之后能正常地进入初始工作状态，加载各个硬件端口、运行操作系统镜像等。各种端口设备（如USB口、网口、串口等）的驱动保证这些端口设备能够在不同的嵌入式操作系统环境下正常工作；

可编程固件指的是CPLD、FPGA等固件的可编程逻辑代码，可实现特定的功能（如计数器、安全时钟）并被驱动操控；

嵌入式OS负责嵌入式下位机系统的软硬件资源分配、任务调度、控制、协调并发活动。常用的嵌入式OS包括vxWorks、QNX，μCOS、嵌入式Linux 等；

最上层是应用软件，包含平台软件和上层应用软件，从故障定位的角度一般不予以区分。

1.2 嵌入式系统下位机故障类型梳理

1.2.1 硬件

硬件故障指硬件板卡整体或部分元器件（包括集成元器件模块）的瞬时或永久故障。绝大部分情况下嵌入式系统硬件故障均以个案形式出现。此外，嵌入式操作系统和驱动程序可能会对一些底层的硬件故障给出特定的故障报警码并显示在硬件报警设备（如故障指示灯）上面，或者返回给上层的软件调用接口，也可以用点灯或闪灯的方式对故障进行指示。相关设计在相应的操作手册中能查到，可以考虑通过合理的报警设计对相应的报警接口进行调用。

1.2.2 驱动&固件

驱动故障指驱动代码存在缺陷，或驱动代码与硬件不匹配导致驱动相关的硬件设备工作不正常。驱动故障和硬件故障最大的区别是：驱动故障具有普遍性，相同的驱动代码在同一种板卡上表现一致，更换同种硬件板卡后故障仍然存在。一些通信外设相关驱动故障（如串口驱动、网络驱动），其发生有一定概率和随机性，给复现、排查和分析带来困难。

另外，存在一定概率的具有普遍性的硬件设计缺陷，导致硬件工作不正常，即使更换板卡，问题仍会存在，容易与驱动故障的现象混淆。但这类硬件设计缺陷，也会从驱动层面体现出来，可以在驱动层面通过加补丁的方式解决。

除了通常意义上的驱动之外，如bootloader和BSP 包等启动阶段加载项也统一归类为驱动。bootrom 和BSP 包在厂家出厂之前一般会做通用功能的常规测试，出错之后会直接导致板卡无法启动且有明显故障指示，因此这两类底层驱动通常出错的可能性较小，问题定位也相对简单。另外，bootrom 启动过程中的部分错误也可能没有任何指示灯的提示，仅表现为板卡启动失败。尤其是安全产品的自研板卡的，板卡指示灯的设计也没有统一的规定，工程师依赖经验的成分更多。

固件代码（如FPGA、CPLD代码）的出错特征与驱动类似，表现为与相应代码对应的固件工作异常。出错也具有普遍性（更换硬件后，故障仍存在），并呈现一定的随机性概率（有时低概率出现）。

1.2.3 操作系统

操作系统的故障包括2类：（1）操作系统本身存在缺陷，使得其在特定的场景，或使用其某个缺陷模块时出现错误；（2）由于对操作系统相关函数和配置的错误使用，或其它层级的缺陷导致操作系统异常，有时表现为操作系统的崩溃。

操作系统本身的缺陷可以通过操作系统厂商提供的相应版本BugList 来获得一些信息，此外，厂商的技术支持也尤为重要。其它层级的缺陷导致的操作系统异常更为常见，多为使用人员对操作系统不熟悉，或针对相应组件操作不当而导致。

操作系统故障时，可以通过操作系统运行时自带的一些集成编译工具（如vxWorks的Tornado、Workbench、QNX 的Momentics工具包等），查看相应的运行参数，获悉一些关键运行信息，也可以通过操作系统自带的一些运行监控组件来跟踪程序异常。

1.2.4 应用软件

应用软件故障可以分为以下3种：

（1）应用软件设计缺陷导致的程序调度错误，可导致程序的任务调度异常，软件无法完成指定功能，或者导致部分任务被挂起而引起系统整体宕机。

（2）在内存分配、指针跳转或其它编程语言的用法上出现错误，导致程序异常，引起程序崩溃。包括未遵守安全编码规范，未加防护或防护不当。可通过操作系统提供的工具记录一系列内存越界等故障发生的执行点等信息，以适当方式导出和查看。

（3）逻辑错误造成的逻辑设计和实现上的缺陷，可能造成非预期的执行结果，但一般情况下，下位机程序运行没有明显异常，需要结合测试流程方能发现这类错误。

2 嵌入式系统下位机故障定位及分析方案

2.1 不同类型故障的定位及分析方案

根据故障分类梳理结果，本文对不同种类故障，有针对性地给出相应的故障定位及分析方案，如图2所示。

图2 嵌入式系统下位机故障定位及分析方案汇总

2.1.1 内核事件追踪

当硬件、驱动、操作系统等底层故障发生时，会引起整个软件的运行异常或操作系统的崩溃，在无法通过I/O设备导出相关故障时，需要采用其它方式记录崩溃之前的系统运行状态，以用于故障分析。常用的COTS型嵌入式操作系统（如vxWorks、QNX 等）均提供了一些内核事件追踪分析工具包，记录系统运行过程中发生的内核事件，基于该嵌入式系统的工具包，辅以一定的队列控制、内存及U盘读写策略，形成内核事件追踪方案。

以QNX 操作系统为例，QNX 提供一种系统追踪分析工具包[9]（SAT，System AnalysisToolkit）。SAT工作在操作系统的内核级，能够在不修改应用程序的情况下有效监控并记录系统运行过程中发生的内核事件（包括系统调用、进程间通信、中断等）。SAT 工作原理如图3所示[10]，由调试级内核、Kernel缓冲区、数据捕捉程序及数据解释程序组成。调试级内核负责采取内核事件，放入Kernel缓冲区（Kernel 缓冲区是一个循环列表，可以循环记录事件）。数据捕捉程序从Kernel缓冲区获取事件数据并保存为指定名字的.kev 文件，数据解释程序解析.kev文件。为了使内核支持SAT，需要将调试级内核和tracelogger 程序编译到内核镜像中。

图3 SAT工作原理

实时嵌入式应用程序一直持续运行，且其故障点具有不确定性，持续记录内核事件可能会导致宕机时文件无法导出或不易导出，如果频繁写到外部存储ROM中，会使文件过大，且容易损坏外部ROM，而写外存效率低也容易影响应用程序的运行。基于以上问题的考虑，内外存需配合使用，内存实时记录保证宕机时有记录，避免时间点不确定性问题；外存只在宕机时将内存数据写入，方便文件导出。

基于以上应用场景所设计的一种SAT的应用框架如图4 所示。其中，调试内核进程实时捕捉系统发生的事件并记录到内核缓冲区队列中；Tracelogger是QNX 提供的一个在后台运行的组件程序，其被触发后，可将调试内核捕捉到的事件（kernelbuffer）刷到指定文件；trace是自定义的追踪进程，它通过PULSE 监控用户关键进程的运行状况（见图4中的①），当用户关键进程挂掉或逻辑上出现宕机时，trace在规定时间内没收到该进程发送过来的PULSE，其会向调试内核进程发送STOP 命令（见图4中的②），调试内核收到该命令后会立即通过SIGINT 触发Tracelogger 进程（图4中的③）开始进行事件抓取和存储操作，主动去将当前内核缓冲区队列中的所有数据刷到ROM中，存储为trace.kev文件。

图4 SAT应用框架

在程序或操作系统崩溃后，Tracelogger 能够将系统崩溃之前一段时间（可自行设定）记录到的文件存到相关的ROM 存储设备中，之后可以将ROM中存储的.kev 文件导出，利用QNX 的IDE 进行查看。QNX的IDE 能够以图形化的方式清晰地展示不同任务对CPU的占用情况，以及程序在执行过程中发生的所有内核事件，再结合人工分析可确认内核事件的异常，从而推断底层故障的原因。

内核事件追踪机制针对调度错误的原因查找特别有帮助，对于操作系统本身故障的查找也有很大的参考价值，对于与任务调度和时序控制相关的驱动和硬件故障的查找也具有很好的参考价值，但是对于其他难以反馈到任务调度图中的驱动和硬件问题，则帮助不大，需要辅以其他手段来综合定位。

2.1.2 DUMP功能

应用软件的程序异常可能引起程序崩溃，嵌入式操作系统对于这种异常有相应的记录机制，可准确定位相应异常，并记录在相关的存储介质中，嵌入式操作系统的这种功能称为DUMP 功能。

本文以QNX 操作系统的coredump为例进行说明。UNIX 系统将“主内存”称为核心（core），核心映像（coreimage）包括CPU 现场、任务栈空间等。当进程发生错误或收到异常信号（signal）而终止执行时，系统会将coreimage写入一个.core文件，以作为调试时恢复进程现场，即所谓的核心转储（core dump）。QNX 继承了coredump的概念，在QNX下可以通过dumper 程序来使用coredump功能，dumper 程序必须编译到内核中。

一个进程通常有2种终止的方式：（1）正常的逻辑上的退出；（2）运行异常导致的Crash 退出。core dump正是针对后一种情况，dumper 程序在后台运行，并为所有进程提供一个算后转储服务。当程序异常终止时，程序当前状态的转储被写入磁盘。转储文件名称与使用.core扩展名的程序名相同。表1为QNX_IDE 列出的signal 异常信号[11]，用户可以参照这个集合，使用signal 函数来绑定自定义的异常处理逻辑。一旦发生表1中的各类异常，可以直接被DUMP 精准记录。在程序运行时可以将出错信息记录在ROM存储装置（Flash、U盘等）中，离线查看。

表1 异常信号集合

2.1.3 关键信息追踪

为了更有效地追踪上层应用软件执行情况，通常会在应用软件的各个关键位置增加一系列的关键信息追踪。关键信息添加的位置需要根据不同应用的情况来确认，但总体来看，可以大致上分为以下3类：

（1）程序框架逻辑、程序主分支的时序点，如主周期的起始或结束点、主周期运行过程中的分段时序响应起止点、定时中断或串口中断的定时响应点等。

（2）逻辑比较复杂，经分析认为容易出问题的点，如一些复杂算法的中间结果、2乘2取2系统的主备状态更新点、温度电压的超限判断点、串口数据接收点等。

（3）针对特定问题的信息追踪点，如不同安全产品的嵌入式系统下位机在现场应用时所碰到特定的稳定性问题，经分析需要追踪消息在某串口接收处理路径上的流转过程，就需要在这个路径上的所有消息传递点上增加相应的信息追踪。

关键信息的原始记录通常写入全局变量内存区，并且可以周期性地通过网络或串口发送给上位机系统维护台，或者在宕机时写入ROM（Flash 等）进行永久记录，以方便离线查看。对于正常运行时的关键信息应通过网络发送给上位机的相关诊断维护设备进行记录。正常运行过程中不宜写入ROM存储装置，以免因频繁写操作损坏ROM；异常宕机时的信息记录可考虑写ROM操作，以便在网络和串口异常导致关键信息无法发送至系统维护台时，可通过写ROM的方式进行本地记录。

2.1.4 错误码

错误码方式通过在整个程序中设计一种规范格式的错误码来实现一种通用函数错误返回逻辑。故障分析人员可以对照错误码的定义，对记录的错误码进行解析，从而准确地判断故障类型。在设计错误码时要做到错误分支的全覆盖，涵盖整个应用程序的所有函数和文件，也包括硬件设备的错误码。错误码的设计方式可参考以下某安全产品嵌入式下位机的错误码相关定义（C语言）：

由以上的代码可知，错误码的格式可采用4byte 32bit 长整形来表示，其中，高16bit 代表错误模块索引号（如代码中的MODULE_CXXM3模块为0x1002），低16bit 代表某错误模块的具体错误索引号。上述代码宏CXXM3_ERROR_4对应的错误码0x10020004即可代表一种特定的错误类型，可将其用于该种类型错误的返回值。此外，还可考虑采用分层和分类定位，在故障码的数据结构中包含代码行号和文件号等信息。

2.2 综合故障定位及分析方案

本文提出一种故障定位及分析的综合方案，如图5所示。该方案在程序中设计全覆盖的错误码和关键信息追踪，在出现故障后，将其记录在用户缓冲区中，并根据故障类别，考虑将关键故障写到ROM中，同时通过网络向系统维护台发送关键追踪信息和故障时的关键故障状态记录。

图5 一种故障定位及分析的综合方案

嵌入式下位机软件在运行时启动内核事件追踪机制，开一个自定义追踪进程trace，当用户程序进程挂掉或逻辑上的宕机导致trace在规定时间内没收到该进程发送过来的PULSE（图5中的①），trace会向调试内核发送STOP 命令（图5中的②），调试内核收到该命令后会立即通过SIGINT 触发tracelogger 进程（图5中的③）开始进行事件抓取和存储操作，主动去将当前内核缓冲区队列中的所有数据刷到ROM 中，存储为trace.kev文件。此外，在程序正常运行过程中，针对程序运行过程中的关键信息也需要每个周期实时记录和追踪相应状态，并通过网络发送给系统维护台（图5中的④），以便在程序发生异常时，可通过所记录的最后一个主周期各个关键信息的状态来推测和还原异常故障发生时的系统调度情况。另外，故障发生时的故障报警信息也要通过网络向系统维护台发送。在下位机故障报警设计时，还需要尽可能地把出错数据包的相关信息（如出错包号、错误包的包头信息等）上报给上位机诊断维护程序（图5中的④）。在较为严重的故障和宕机发生时，若网络通信发生了异常，可以将一些关键的故障报警信息，以及应用程序异常所引起的操作系统触发CoreDump异常记录（通过在运行时加载DUMP 功能而获取）等，以文件的方式写入ROM 中（图5中的⑤）。对于ROM的写操作仅限于在系统出现故障时进行，而在正常运行时的关键状态追踪，则只向网络发送，不写入ROM。

目前，这种综合方案已成功应用于iBase22-TSP型轨旁安全计算机平台中。基于该型轨旁安全平台可以实现地铁CBTC系统的ZC/LC应用和城际铁路CCS通信控制器应用。采用了本综合方案后，基于该型平台的嵌入式系统下位机的故障诊断维护功能得到丰富和加强，缩短了故障定位时间，增强了系统的可维护性，有助于系统稳定性的改善和提高。

3 结束语

本文梳理了铁路信号产品嵌入式系统下位机的故障类型，针对每一种故障类型，详细探讨了相应的故障定位及分析方法，最后提出一种嵌入式系统下位机故障定位及分析的综合方案，并将该综合方案成功应用于iBase22-TSP 型轨旁安全计算机平台中，使得该型平台嵌入式系统下位机的故障定位和诊断维护功能得到加强。虽然本文以铁路信号产品的嵌入式系统下位机作为研究对象，但所提出的方案本身具有通用性，也适用于其它工业控制自动化领域的嵌入式系统下位机故障定位及分析相关设计。然而，受研究对象的既有软硬件架构所限，本文中提到的故障类别和相应的分析方法还不够全面，要做到对嵌入式系统下位机故障的精确定位，还需要辅以更多的技术手段，不断丰富和补充。此外，故障定位及分析方法属于产品可维护性设计的一部分，如果要更进一步地加强故障定位及分析功能，还需要从产品可维护性的其它方面来采取措施。