某伺服实时控制软件SFMEA/SFTA*

黄梅红，黄志华，宋 冰，王 玥，薛 靓

( 1. 上海航天控制技术研究所·上海·201109；2.上海伺服系统工程技术研究中心·上海·201109)

0 引 言

提高软件的安全性、可靠性，是当前宇航型号软件研发与验证工作的迫切需求，是各研制型号的重点和难点，也是国家推进GJB5000A《军用软件研制能力成熟度模型》的重要目的。法国阿里安5运载火箭的首飞失败、日本X射线太空望远镜“瞳”升空后失效等案例，都可归因于由软件引发的系统故障。

软件的安全性和可靠性实现均采用了需求分析驱动、设计编码实现、测试运行验证的技术途径，以实现指标要求。在软件需求分析阶段，需提出安全性和可靠性需求。所采用的方法中的第一类是以故障树FTA为代表的“演绎法”技术，“自上而下”地进行分析，多用于从系统故障角度追溯软件的原因分析，进行系统需求的安全性、可靠性分配；第二类是以FMEA(失效模式分析)为代表的“归纳法”技术，“自下而上”地进行分析，从软件需求自身的角度出发，识别和获取软件失效可能导致的系统故障。一旦该故障会导致危险事故发生，则这个软件导致的故障就是一个安全性问题；如果故障未导致危险事故发生，则是一个可靠性问题。上述故障的源和因——软件失效的控制措施，就成为了软件的安全性和可靠性需求，这也是提出软件安全性、可靠性需求的最重要的阶段[1-2]。

本文以助推伺服控制软件为例进行了SFMEA和SFTA分析，该软件安装于三通道冗余伺服控制器中。三通道采用了同一版本的控制软件，该软件的功能为：接收1553B总线指令，回送伺服系统参数，通过CAN总线实现在3个DSP间交换数据进行反馈和指令的“三取二”冗余表决功能，与三冗余伺服控制器硬件协同工作，控制伺服机构推摆发动机，实现伺服系统的闭环实时控制。

1 SFMEA分析

SFMEA是一种针对安全性、可靠性的分析与设计技术，用来分析、审查系统及其软件的潜在故障模式，确定其对系统工作能力的影响，从而发现设计中潜在的薄弱环节，提出可能采取的预防改进措施，以消除或减少故障发生的可能性，提升软件和系统的安全性和可靠性水平。

基于软件功能的SFMEA以SPHA为基础，根据助推伺服控制软件任务书对软件功能、性能、可靠性、安全性的要求，按以下几个步骤实施：

1)根据系统设计要求进行软件安全性需求分析；

2)确定助推伺服控制软件的工作分解结构；

3)软件失效模式、影响分析及改进措施。

1.1 根据系统设计要求进行软件安全性需求分析

1.1.1 系统安全性、可靠性设计要求

1)软件需求分析必须遵守《军用软件需求分析》(GJB1091)的规定，确保软件需求规格说明的无歧义性、完整性、可验证性、一致性、可修改性、可追踪性和易使用性。

2)通过PHA分析，以及按照《软件可靠性和安全性设计准则》(GJB/Z102)，确定助推伺服控制软件的等级为A级。

3)软件具有健壮性，对系统所受的外界干扰、接口故障(非法输入、常0/1故障)等具有适应能力；安全关键功能必须具有强数据类型；不得使用1位的逻辑“0”或“1”来表示“安全”或“危险”状态。

4)软件在设计过程中应采取必要的可靠性措施。可根据软件的关键性及特点采取冗余设计、多数表决处理、软件自检等方法，以提高软件的可靠性。软件在完成设计后，应进行优化处理，删除多余的指令和内容。

5)状态信息的获取，应考虑采用在一个周期内进行多次查询或在多个周期内进行连续查询的滤波处理方式，滤除掉可能的干扰信号。

6)数据的存放应考虑其安全性及需要便于软件的优化，重要的标志应安排在所有数组前面，确保即便在下标超界的情况下，数组也不会对重要标志造成破坏。对重要标志应尽量采用直接寻址的方式进行寻址。

7)为确保总线数据传输的有效性与完整性，应为每帧数据后置CRC校验和，并且在总线超时未收到数据时，应采取缺省值等必要措施。

8)软件(程序)多余物的处理，程序块的隔离，内存未用空间和未采用中断的处理，对关键数据、变量的保护和校核等采取有效措施。

9)对于控制软件分支的重要判别标志和软件结构，必须保证足够的可靠性。

10)要处理好运行过程中产生的极小值。

11)使用中断要慎重，各中断无论是否屏蔽，都应有“出口”。

12)在软件设计过程中, 对内存的使用应满足20%的余量要求。特别是对动态数据缓冲区及计算周期时间的余量，更应准确地进行测算。

13)在软件设计过程中, 应注意收集有关助推伺服控制软件的信息和数据，逐步对软件进行定量的可靠性分析。

14)对任务书中描述的公式、变量，其量纲、定义域和值域在软件实现时要予以说明和仔细检查。

15)要求助推伺服控制软件周期监视BU65170芯片的工作状态，在发现异常后，对BU65170芯片重新进行初始化设置。

1.1.2 软件安全性需求分析

1.1.2.1 软件性能的安全性需求

1)在助推伺服控制软件中，对未使用中断和野中断(指在程序运行过程中不期望发生的异常中断)应采取安全保护措施；尽量避免中断嵌套的使用。在必须使用中断嵌套完成对各项任务的调度时，需要对中断嵌套在使用过程中引起的中断冲突和资源竞争进行深入分析：

a)对程序运行过程中不使用的中断源用屏蔽字进行屏蔽；

b)对不使用中断编写的空中断处理程序，需使程序正确地返回到原来的断点。在正常情况下，未使用中断和野中断不会出现，该处理程序不会执行，因此，不会对程序运行产生任何影响。只有在非正常状态下，即未使用中断和野中断出现时，该处理程序才会起作用；

c)对于使用中断嵌套而引发的每一种中断冲突情况，需做具体分析，对所有可能产生的资源冲突(包括堆栈、全局变量、处理器的标志寄存器等)逐一进行分析，判断是否有发生的可能或进行了保护。

2)软件应满足对时间、容量的使用预留20%余量的要求，对周期内的运行时间余量应进行准确的测算：

a)如果软件运行时间不能满足要求，一方面可优化程序，一方面可根据计算精度适当调整控制周期；

b)如果空间不能满足要求，则需要进行优化处理。如果经优化后的软件仍然超过有效范围，导致程序不能正常执行，则需要寻求新的途径以解决问题。

3)软件设计要考虑实时性要求：

a)上电后按任务书提出的时间要求完成系统的初始化设置；

b)在控制周期内完成对伺服机构的实时控制指令和位置反馈等信号的综合、校正、滤波，将计算得到的误差信号分别送达对应的DA，以驱动伺服机构；

c)1553B总线周期应满足任务书要求；

d)上电或收到“启动自检测”模式码后，按任务书提出的时间要求完成自检；

e)从收到BC控制指令(SCU1摆角控制信息)到指令实际输出的时间，应满足任务书要求；

f)在收到“时间同步消息”后，在控制周期内完成系统对时；

g)在控制周期内完成位置反馈等重要信号的AD采集，其余遥测用信号完成1次采样更新，采样周期不小于1553B总线周期；

h)在控制周期内完成1次遥测数据的更新上传。

4)在软件设计完成后，需对整个软件的程序结构和数据结构进行优化和完善，删除多余的语句、数据和注释。

1.1.2.2 软件功能的安全性需求

1)在收到时间同步码后，不再响应、启动自检测模式码和复位远程终端模式码。

2)对摆角指令绝对值按任务书要求进行限幅。

3)软件中不允许出现不期望的死循环。

1.1.2.3 关键数据安全性需求

1)针对数据合理性检测，需采取有效措施对关键数据、变量等进行校核，例如对变量的值域进行检测。

2)数据有效性处理。对关键数据进行有效性判断，注意计算过程中数据的合理性，对除法计算的分母、被开方数和反三角函数进行合理性保护，对浮点数下溢等问题进行处理，避免出现无效操作数。

3)软件设计所用的公式和参数的量纲，必须与任务书的要求一致。

4)数据必须全部初始化为合理数值，数据缓冲区、查询表需被正确初始化。

1.1.2.4 接口安全性需求

1)软件采用结构化设计方法，应合理划分功能模块，模块设计需按高内聚、低耦合的设计原则进行，调用关系及输入、输出数据需明确。模块和标志间的接口应尽可能简单。

2)对AD采样数据和DA计算数据进行限幅。

3)为保证助推伺服控制器1553B总线芯片发送、接收数据的完整性，需要采用发送、接收数据双缓冲的设计方法。

4)注意数据采样的时间，避免出现死循环。

1.2 助推伺服控制软件工作分解结构

根据软件任务书，绘制软件功能流程图，定义软件约定层次结构，确定不同角度的2种分法，如图1所示。

图1 软件约定层次图Fig.1 Functional and design blocks

1.2.1 主程序模块

1)初始化功能

2)自检功能

3)参数烧写功能

1.2.2 毫秒中断模块

1)AD采集功能

2)DA输出功能

3)“三取二”表决功能

4)差分方程计算功能

5)遥测消息更新上传功能

6)本机发送CAN数据功能

1.2.3 1553B中断模块

1)1553B消息解析功能

2)1553B消息执行功能

1.2.4 CAN中断模块

1)接收另2机CAN数据的功能

1.3 软件失效模式、影响分析及改进措施

基于功能的软件失效模式、影响及危害性分析大致可分为4类。软件失效模式影响的严酷度等级的评分标准从1级(无影响)到10级(影响系统运行的安全性)，共分为10级；发生的可能性从1级(无影响)到10级(影响极高)，共分为10级。

基于功能的软件失效模式、影响及危害性分析中的第1类，为地面各项试验、负载试验、全箭综合试验、发射前电气系统试验可发现的错误，通过更换控制器备份、程序重新烧入等方法可以解决，但可能会推迟发射，其危害程度相对较低。软件失效模式的影响轻微，严酷度等级的评分为3～4分，发生的可能性较低，评分为3～4分。例如：

1)DSP初始化错误；

2)65170芯片初始化错误；

3)上电自检功能错误；

4)1553总线自检功能错误；

5)参数烧写功能错误。

第2类，为地面试验、发射前电气系统试验可发现的错误或火箭飞行时可能发生的错误，但对火箭的飞行结果影响不大，软件失效模式影响的严酷度等级评分为5～6分(系统仍能运行，但影响使用的方便与舒适性)；发生的可能性较低，评分为3～4分，例如：

1)遥测消息更新上传功能错误；

2)本机发送CAN数据功能；

3)接收另2机CAN数据功能(CAN总线在本系统中的作用为：在一路1553指令故障或一路反馈故障时提高可靠性)。

第3类，经地面试验的充分考核，火箭在飞行时发生错误的可能性低，但错误一旦发生，会严重影响火箭控制系统的控制精度，对火箭飞行的成败影响重大。软件失效模式影响的严酷度等级的评分为8分(影响系统丧失主要功能而不能运行)，但其发生的可能性很小，评分为2～3分，例如：

1)差分方程计算错误；

2)程序版本号代码和错误；

3)“三取二表决功能”错误。

第4类，火箭在飞行时可能发生的错误，会影响火箭控制系统的控制精度，对火箭的飞行结果影响大。软件失效模式影响的严酷度等级的评分为7～8分，发生的可能性评分为4分，例如：

1)DA输出功能错误；

2)AD采集功能错误；

3)1553B控制指令接收错误。

经SFMEA分析，对各种故障模式分别采取改进措施，例如：1)严格按芯片使用手册，进行程序设计；2)加强软件单元测试、代码走查、配置项测试、综合试验等测试；3)仔细检查诸元文件，设立一二岗，确保诸元生成正确；4)在出厂前、基地单元测试时设置强制检验点，确保软件版本、代码和正确。

2 SFTA分析

软件故障树分析是一种用于风险分析的、系统性的、自上向下的演绎方法，即从助推伺服控制软件不希望发生的事件(顶事件)、特别是对人员和设备的安全产生重大影响的事件开始，向下逐步追查导致顶事件发生的原因，直至到达基本事件(底事件)。SFTA的结果可以用来指导后续的可靠性、安全性设计，确定软件测试的重点，使软件可靠性得到更充分的保障。

软件故障树中的危险事件是由软件初步危险分析(SPHA)的结果确定的，在需求分析阶段，需进行基于软件功能的SFTA分析，该分析按以下3个步骤进行：

1)软件控制流分析；

2)建立软件故障树模型；

3)对软件故障树进行定性分析。

2.1 控制流分析

助推伺服控制软件按照功能可划分为4个相对独立的功能模块，即主程序、毫秒中断、1553B中断和CAN中断，其层次关系如图2所示。各模块的控制流程如图3～图6所示。

图2 助推伺服控制软件的层次关系图Fig.2 Design blocks of servo-control software

图3 主程序的控制流程Fig.3 Flow chart of main program

图4 1553B中断处理流程Fig.4 Flow chart of 1553B interrupt

图5 毫秒中断处理流程Fig.5 Flow chart of millisecond interrupt

图6 CAN中断处理流程Fig.6 Flow chart of CAN interrupt

2.2 故障树模型的建立

软件故障树由一套逻辑和事件符号构建而成，利用图形化的方式直观地标识故障事件之间的逻辑关系。建立故障树的基本流程是：选择要分析的顶事件(即不希望发生的事件)作为故障树的根，然后分析导致顶事件发生的直接原因，并用适当的逻辑门与顶事件相连，作为故障树的节(中间事件)，以此逐步深入，一直追溯到导致顶事件发生的全部原因(底层的基本事件)。这些底层的基本事件被称为底事件，构成故障树的叶。

本软件SFTA的过程为：首先，选择故障树的顶事件(根)为系统报废、任务失败，底事件(叶)则定义到软件功能级的失效原因；其次，根据控制流程中各功能模块间的调用关系，得到故障树的结构；再通过对各功能模块的输入数据进行分析，得出故障树的叶节点，从而绘制出完整的软件故障树模型，如图7所示。

根据软件故障树模型，在进行软件设计时，应对所有底事件中的失效原因进行有针对性的安全性设计，从而防止中间事件和顶事件的发生，或降低其发生概率。

图7 助推伺服软件基于功能的软件故障树模型Fig.7 FTA model based on software function

其中,符号的含义为：

T1：系统报废、任务失败；

M1：主程序模块失效；

M2：毫秒中断模块失效；

M3：1553B中断模块失效；

M4：CAN中断模块失效；

M11：初始化功能错误；

M12：自检功能错误；

M13：参数烧写功能错误；

M21：差分方程计算错误；

M22：DA输出功能错误；

M23：AD采集功能错误；

M24：遥测消息更新上传功能错误；

M31：1553B消息解析错误；

M32：1553B消息执行功能错误；

M111：DSP初始化错误；

M112：65170芯片初始化错误；

M121：上电自检功能错误；

M122：总线自检功能错误；

X1：寄存器初始化错误；

X2：中断向量地址设置错误；

X3：查询表初始化错误；

X4：数据块地址初始化错误；

X5：DSP内存自检错误；

X6：65170芯片检测错误；

X7：机构参数自检错误；

X8：获取RT地址有误；

X9：烧写参数错误；

X10：烧写地址错误；

X11：反馈输入错误；

X12：差分方程错误；

X13：DA输出地址错误；

X14：DA输出值超范围；

X15：AD采集地址错误

X16：AD采集反馈值错误；

X17：AD采集遥测值错误；

X18：总线消息解析错误；

X19：总线消息有效位判断错误；

X20：时钟同步错误；

X21：总线消息发送错误；

X22：CAN中断标志位判断错误；

X23：CAN邮箱读取错误；

X24：“三取二”表决错误；

X25：CAN发送错误；

X26：程序版本号代码和错误。

2.3 定性分析

通过故障树模型分析出最小割集。所谓割集是指能引起顶事件发生的底事件的集合。最小割集是指不包含任何冗余因素的割集。如果去掉最小割集中的任何事件，它将不再成为割集。

当故障树建立并得出所有的最小割集后，应对割集进行定性比较，并将结果应用于指导故障诊断或指出改进方向。最小割集定性比较应遵循以下原则：

首先，根据最小割集的阶数(所包含底事件的数目)将割集进行排序，再参照各底事件发生的可能性(可能性越大就越重要)。在各底事件发生的可能性均较小且差别不大的情况下，再根据各底事件的出现次数、定性地确定各底事件的重要级别。一般而言，最小割集越多，引发的顶事件的故障模式就越多；另外，底事件在最小割集中出现的次数越多，就越重要，一阶最小割集中底事件的重要度要大于多阶最小割集中底事件的重要度。

本故障树中只有或门而没有与门，所以故障树中的所有底事件(X1～X26)均是最小割集，各最小割集的阶数也均为1，即任何一项底事件的发生均会导致顶事件的发生。其中，X1、X3、X4底事件出现的次数为2次，其他底事件出现的次数均为1次。经分析，得到重要的最小割集为：X9烧写参数错误、X14DA输出值超范围、X16-AD采集反馈值错误、X21-1553B总线发送摆角指令错误、X26程序版本号代码和错误。后续，将通过单元测试、代码走查、配置项测试、仿真试验、综合试验、第三方评测等验证措施及严格按型号进行软件工程化管理等措施，来避免底事件的发生。

3 结 论

根据SFMEA及SFTA的分析结果，针对软件设计中可能存在的薄弱环节和引发软件失效的各底事件，在软件设计阶段应进行有针对性的设计，采取措施，以避免底事件的发生，从而降低顶事件的发生概率。同时，以此为依据进行基于软件部件和单元的SFMEA和SFTA分析。通过分析可得，软件中的参数烧写、与硬件间的接口操作、中断使用等都是软件设计中的关键环节或关键事件，在后续的安全性设计中应加以重点考虑，并加强测试。