北京理工大学 软件工程实践 汤铭端 中国航天科工集团公司204所.

Presentation on theme: "北京理工大学 软件工程实践 汤铭端 中国航天科工集团公司204所."— Presentation transcript:

1 北京理工大学 软件工程实践 汤铭端 中国航天科工集团公司204所

2 欧洲宇航局（ESA）阿丽亚娜 5 501飞行失败案例分析
第十六讲 欧洲宇航局（ESA）阿丽亚娜 5 501飞行失败案例分析

3 阿丽亚娜 5 501飞行故障分析报告

4 说明 分析和报告主要基于ESA的报告

5 汇报分六个部分： 501飞行 事故描述 事故分析 产生故障的原因 501故障分析委员会的建议

6 501飞行

7 阿丽亚娜5的501飞行：阿丽亚娜5的首 次鉴定（qualification)飞行
这样的飞行计划安排三次 飞行在Guiana空间中心进行 阿丽亚娜5计划由ESA授权CNES（法国 航天局）进行管理

8 主要元部件于2月14日到达Kourou 2月19日和20日在CNES进行了501飞行 的飞行就绪评审（Flight Readiness Review） 在对组成火箭的硬件的质量与配置进行了仔细试验后，准许启动501飞行战役

9 501飞行战役于1996年3月4日开始 如一切顺利，计划在1996年5月15日 起飞 其间，由于卫星安装后延，起飞时间调整为5月30日 5月25日，在燃料过氧化氮（N204）的 加注阶段出现故障，起飞再次延迟

10 在5月30日和31日进行起飞就绪评审 （launcher Readiness Review）
起飞在6月4日Kourou时间08:35至10:15 进行

11 飞行失败

12 阿丽亚娜5的首次飞行没能确认欧洲的新型运载火箭
ESA/CNES 6月4日公告 阿丽亚娜5的首次飞行没能确认欧洲的新型运载火箭 这是一个全新运载器的首次飞行，它的每一个部 件在过去的年月里都在地面被测试。 对这个全新的设计，运载火箭使用了威力十倍于 阿丽亚娜4的发动机。其电子中枢的威力比以前 阿丽亚娜运载火箭的百倍还要强。非常多的鉴定 评审和地面测试对所有选择的正确性进行了极其 严格的检查。但是，没有绝对的保证。一个飞行 器的能力只能在真实条件下飞行后才能被确定。

13 计划中的第二次飞行已经安排在数月后进行。在此之前，将尽一切力量去查找事故原因，并进行必要的更正以保证第二次试验的成功。在以后的数天里将组成一个调查委员会。他们被要求在七月中旬提交一份完全独立的，报告，确定事故的原因，提出为避免如何进一步的事故而设计的修正建议。 阿丽亚娜5是欧洲航天事业的一项主要挑战。该计划 中所有队伍的技能，与所有行政、技术、工业领导的决心和团结一起，使我们对最后的成功充满信心。

14 6月6日发布了关于501飞行失败的第一次信息 501飞行于1996年6月4日在Kourou的 Guiana空间中心进行
箭上带有四颗研究地球－太阳作用的卫星 09:33:59火神发动机正常点火 H0+7.5s助推器正常点火、正常起飞 至H0+37s飞行导引和轨道正常 速度0.7马赫，高度3500米

15 根据遥测发现，在H0+37s至H0+39s，所有助推器的喷管转至极限，由此引起火箭急剧倾斜，过大的动力过载导致解体和自毁
对遥测数据的初步分析说明推进器功能正常，调查的方向主要为“电子和软件系统”

16 6月10日 ESA、CNES的局长决定 1。加强对所有火箭部件的起飞鉴定评 审的调查权力，特别要进行一些特殊的审查 2。建立调查委员会

17 调查委员会被授权 —确定发射故障的原因； —调查与所发生问题有关连的鉴定测试和验收测试是否适合；
—提出纠正措施，以排除异常起因及事故中发现的系统的其它弱处。 委员会在技术顾问委员会的协助下，可接触委员会需要的所有人员、文档、硬件设备。 在七月中旬提交报告

18 7月23日ESA公布了调查结果 7月25日获得了“501飞行故障”报告 ARIANE 5 Flight 501 Failure 我们的讨论基于这份报告 另有一份严格限制传阅的技术报告无法获得

19 事故描述

20 阿丽亚娜501的故障是由于主发动机点 火后37秒(起飞后30秒)制导和姿态信息 完全丢失造成的。信息的丢失是由于 SRI软件的规格说明和设计错误引起的
描述导致失败的错误、产生错误的原因

21 在阿丽亚娜５研制过程中进行的广泛评审和测试未包括对SRI或完整的飞行控 制系统进行充分的分析和测试，而这样的测试是能够查出潜在的故障的。
指出错误没有在事先被发现的原因

22 下面详细描述一下导致失败的错误 如何分析和发现错误并准确定位，在下一部分讨论 在再下一部分讨论产生错误的原因

23 涉及故障的几个部件： SRI1和SRI2：双备份的惯性制导系统 OBC：箭载计算机 火神发动机 固体助推器

24 阿丽亚娜５的飞行控制系统是一个标准设计。运载火箭的姿态和空间运动是由惯性制导系统(SRI)测量得到，SRI内部带 有计算机，根据带有激光陀螺和加速度表的“捷联”惯性平台提供的信息，计算角度和速度。来自SRI的数据通过数 据总线传输到箭载计算机(OBC)，箭载 计算机执行飞行程序，通过伺服机构控制固体助推器和火神(Vulcain)低温发动 机的喷管。

25 为了提高可靠性，在设备层有不少冗余。 有两个硬件和软件完全一样的SRI并行工作。以一个SRI为主，另一个作为“热”备份。如果OBC检测到主SRI出现故障，则立即切换到另一个SRI，保证该单元正常工作。

26 涉及故障的部件关系 SRI 2 SRI 1 OBC 备份OBC 火神发动机 固体助推器

27 SRI的理想工作时序（软件实现） 校准 制导 （飞行模式） 起飞时刻

28 但阿丽亚娜4因其它原因给SRI加了新功能 （阿丽亚娜5的SRI软件是阿丽亚娜2的重用）
背景： SRI飞行模式启动前－9至－5秒，倒计时在 极少的情况下会停顿 重新启动火箭要化几个小时 而地面恢复控制需约几十秒 由此：要求SRI不断重校准至恢复控制 （50秒内）

29 阿丽亚娜4对SRI软件的设计 不出现停顿时： 校准 制导 0秒 50秒 起飞时刻

30 阿丽亚娜4对SRI软件的设计 出现停顿时： 0秒 50秒 起飞 倒计时停顿

31 问题（对阿丽亚娜4） 1.用软件来弥补硬件的缺陷是否明智？ 2.就算为满足阿丽亚娜4的要求，为什么 起飞后还要运行校准功能？
目前普遍认为，对关键系统，能用硬件实 现的功能尽量用硬件实现。因为硬件的可 靠性一般比软件高。 2.就算为满足阿丽亚娜4的要求，为什么 起飞后还要运行校准功能？ 实际上这是“功能多余物”，“盲肠”

32 阿丽亚娜4中SRI的功能多余物导致了阿丽亚娜5的501飞行失败
而阿丽亚娜5根本就没有那条多余的需求

33 问题（对阿丽亚娜5） 1。为什么阿丽亚娜5的SRI软件还有功能多余物？ 2。为什么没有查出这段“盲肠”在阿丽亚娜5会“发炎”？

34 怎么发的炎？ 根源： SRI软件是由当前被认为最严谨的ADA语言 编制的。
这种转换涉及到的变量中包括BH，一个与 水平偏差有关的量。

35 怎么发的炎： 影响： 由于阿丽亚娜5轨道的起始部分于阿丽亚娜4不一样，水平速度更大，与此相关联的水平偏差BH比预想的大得多。
带符号16位整数的取值范围是： ＋ ~ －32768 当64位浮点数超出上述范围时，就产生一个运算错误（异常，exception）

36 ADA语言对异常的处理： 任何错误都不放过 出错后，马上转到本模块的异常处理部分 根据异常类型寻求保护（那里应有相应的 保护措施）
本模块中如无保护，则跳入上一个模块（ 调用本模块的模块）寻求保护 上过程循环至找到保护或至主程序

37 ADA 主程序 子程序1 子程序2 子模块 ADA语句 说明 功能语句 异常处理语句

38 怎么发的炎： 蔓延： 阿丽亚娜5在起飞后，BH值转换时超限 （需求错） SRI中对由BH引起的超限异常没有保护 （设计错）

39 怎么发的炎： 爆发： 异常得不到保护，引起SRI2关机 软件没有冗余（观念错），SRI1同样关机 （SRI1早一个时钟周期就关机了）
SRI向OBC传诊断信息，却被OBC当作了正 常的姿态信息（看来还有接口问题，另外 ，OBC应检测出SRI2故障并切换） OBC指令主发动机和助推器喷管转至极限

40 怎么发的炎： 结果： 姿态迅速改变，气动载荷导致火箭解体 解体后，自毁装置自动点火 自毁，爆炸

41 问题： 技术错误如前所述，很多很多，有些还 是观念错误 评审、测试没有查出错误是错中之错 过程的错也反映了管理的错

42 事故分析

43 委员会进行调查的基础和原始信息： 文档和实物（未参加501飞行） H0＋42秒前地面接收到的遥测数据 雷达站的轨道数据 光学观测 回收残骸

44 天气情况： 发射场的天气对发射来说是可接受的，在 运载火箭被运至发射台时没有造成阻碍 。特别是没有闪电危险，因为在发射场 地所测到的电场强度可以忽略。唯一的 不确定性是能见度标准的履行情况。 后来飞行延迟至预报能见度好转 （因此天气不成问题）

45 起飞情况： 倒计时在H0(主低温发动机点火命令)－7 分钟之前一直顺利进行，H0－7分钟由 于发射窗口开始时刻(当地时间08h35)不满足能见度规定，发射推迟。后预报能见度将好转，H0＝09h33mn59s开始发射。火神发动机和两个助推器正常点火并起飞 （点火、起飞也没问题）

46 初步分析： 运载火箭在H0＋36秒前正常工作； 备份惯性制导系统(SRI)先失效后，主SRI也随即失效（遥测数据）；
两个固体助推器喷管转到极限位置，接着火神发动机的喷管也转到极限位置，引起运载火箭突然转向（遥测数据）； 固体助推器与芯级的连接断裂引起运载火箭的自毁装置自动点火。 故障的原因很快局限于飞行控制系统，特别是两个惯性制导系统，很明显地在H0＋36.7秒左右几乎同时失效。

47 残骸回收： 从残骸中找回了两个SRI。 特别有用的是主模式工作并停止在后的SRI2，因为一些与它有关的信息未能从遥测数据中获得(遥测数据确定了两SRI 中哪一个首先失效－对遥测数据不满)。 该设备的检验结果对分析故障序列是非常有用的。（个人认为：对故障定位太有用了）

48 无关的异常： 有些异常在以前试飞时出现过，被认为无关
引起注意异常是控制主发动机喷管的液压伺服机构的液压波动，它始于H0+22 秒并逐渐发展，变化的频率约10Hz。 关于原因有些初步解释并正在调查之中。 委员会考虑后认为该异常现象虽然重要， 但与阿丽亚娜５01故障无关。

49 其它： ESA在6月14日公告：飞行器设备舱内的大部分设备已被复原和审查。已经显示在阿丽亚娜5操作模式中存在与惯性平 台有关的故障。
复原结果已报告故障分析委员会

50 据这些信息故障分析委员建立了故障事件链及其内在联系和因果关系，从火箭自毁开始按时间追溯到最初起因。

51 故障事故链

52 运载火箭在大约H0+39秒时开始解体， 原因是由于攻角大于20°引起了很高的气动载荷，导致了助推级与主级分离，继而运载火箭的自毁系统自动点火。
可通过遥测数据分析获得

53 这个攻角是由于固体助推器和火神主发动机喷管的极限偏转造成的。
也有遥测数据为证

54 喷管偏转指令由箭载计算机(OBC)软件 根据主惯性制导系统(SRI2)提供的数据 发出，而该时刻的部分数据不含有正常飞行数据，表示的是SRI2计算机的诊断位模式，但它却被认为是飞行数据。
喷管系统的异常被排除了 OBC有没有问题？ SRI肯定有问题，遥测说明它关机了 以下的分析大概就要靠复原和仿真了

55 主SRI2没有传送正确姿态数据的原因是由于软件上的异常。
这里有疑问的地方很多

56 疑问 1。SRI最后向OBC送了什么？ SRI按需求异常处理不了就停机。它送的诊断信息应包括在接口说明中？
输入、判别是否异常、异常时切换 现在SRI1已先停机，应该已报告OBC ？ SRI2的输入应包含停机的诊断信息 ？ 如果OBC判断出SRI2失效，为何还要计算 ？ 如果OBC没有判别出SRI2失效，SRI1停不停机都无所谓？

57 3。OBC有无缺陷？ 一种设想：OBC已知SRI1失效，后来又发现SRI2失效，反正两台SRI都失效后发现肯定失败，于是乱算一气 另一种设想：一台SRI失效后，对另一台SRI就不判别失效，因为失效后，判别也是死，不判别也是死 还有：就是OBC根本没有判别出SRI2失效 总之，OBC功能并不完备。 当然，致命的是SRI软件无冗余和停机

58 OBC不能切换到备份SRI1，由于与SRI2一样的原因，在前一数据周期(72ms)， SRI1已经停止了工作。
有专家说：SRI1和SRI2中各有备份的敏感设备，其测量是有误差的。可能上一周期BH在边缘，SRI2中没有超 限，而SRI1中超限了。

59 内部SRI软件异常是由执行从64位浮点 数向16位带符号整数转换时引起的。被转换的浮点数值大于16位带符号整数可表达的值，这就导致了一个运算错误。虽然在代码中同一位置的其它变量转换被保护了，但是这个数据转换指令(Ada语言)运算数错误没有被保护。 ADA中找错误，当然先找那些没有保护的异常

60 这个错误仅会在执行捷联惯性平台校准的那部分软件中出现，该软件模块仅在起飞前作有意义的计算，运载火箭一旦起飞，该功能就没用了。
盲肠

61 校准功能工作50秒，在阿丽亚娜５在H0－3秒启动的SRI飞行模式，在起飞后该功能持续工作约40秒的飞行时间。这个时序是根据阿丽亚娜４的要求制定的，但阿丽亚娜５没有此要求。
盲目重用、过分强调控制技术状态更改

62 由于一个称为BH(水平偏差)的内部校准功能结果的值出乎意料的大，运算错误就出现了。这个水平偏差是与平台敏感到的水平速度是相关联的，它的计算值表示了随时间变化的校准精度。
出现了新情况、新问题

63 BH值比预想的大很多，因为阿丽亚娜５轨道起始部分与阿丽亚娜４不同，存在更大的水平速度值。
没有认识到，或不负责任地忽略

64 产生故障的原因

65 错误的产生包括两个部分： 开发：为什么要这样编？ 检测：评审和检查为什么没有发现？

66 软件开发方面： 从全报告看，故障分析委员会试图对事不对人，只对阿丽亚娜５的故障发表看法。（这也带来了一些含糊）
故障分析委员会避开了阿丽亚娜４的问题 但这是避不开的

67 对开发的全面分析可考虑这几个方面： 1。阿丽亚娜4的问题 2。阿丽亚娜5的问题 3。系统和观念的问题 4。其它可能的缺陷

68 阿丽亚娜4的问题主要为： 1。为什么有功能多余物？ 2。为什么缺少异常保护？ 3。为什么关机？

69 为什么有功能多余物？ 很奇怪，报告只说了校准功能为什么要延长，却没有说为什么要延长到点火后的50秒，而不在点火时终止？
可能是很难办，如得不到准确点火时间 否则就是一个大失误

70 为什么缺少异常保护？ 异常有很多类，除自定义的异常外，ADA支持五种预定义异常：约束异常、数值异常、程序异常、存储异常、任务异常
这里出现的转换异常可含在数值异常中。 阿丽亚娜4似乎考虑到了这些异常－这可 能与Ada的严格和可靠性设计要求有关

71 为什么缺少异常保护？ 七个变量在浮点数向整数转换时有危险 保护了四个 不全保护是因为SRI已占其能力的80％ 有异议

72 异议 保护工作在不出异常时不占多少资源 不保护，难道在真出现异常时还去为了保护余量而死机吗？（这是软件问题，软件没有冗余，要死全死）

73 为什么缺少异常保护？ 异常是否保护的决定不严谨。 三个变量（含BH）不保护的原因是：实 际已受限or有充足余量。
但该决定却被各方认可（怀疑也有走过场，或被不严谨的分析所混淆）

74 为什么关机？ 运算出错，如妥善处理，不一定就会造成飞行失败
可怕的是在异常处理的规格说明中规定：故障在数据总线上应该指示出来，故障的来龙去脉也应该贮存在EEPROM贮存器中，最后SRI处理器应关机 这个决定是致命的，重新启动是不可能的

75 为什么关机？ 上述决定是建立在自认：有异常必是硬件出错了，修也修不好，没办法，关机了事。 这是由严重的观念错误造成的。

76 观念错误： 传统思想：只注意硬件随机故障。从这个观点出发，异常或错误处理机制是为硬件随机故障设计的，硬件随机故障通过备份系统是能够得到解决。
这就导致对软件无冗余 也就导致两个正常工作的关键设备关机

77 观念错误： 软件在出现错误之前总被认为是正确的 除非被严格证明，总应假设软件中含有错误。
在设计时应考虑到软件会有异常（允许它出错并对此预防），有时必须假定它就有错并对此进行保护。以此来保护系统正常工作。

78 观念错误： 软件故障和硬件不太一样 硬件会在同样条件下由于老化等原因失效，软件确不会 对软件也应有冗余，而且是特殊的冗余，例如多版本软件等。

79 阿丽亚娜5的问题： 整个报告中对SRI软件功能和设计中的 问题都是针对阿丽亚娜4的SRI软件的
报告把重点放在为什么阿丽亚娜5的检 测没有发现问题 因此...

80 怀疑： 阿丽亚娜5的SRI软件是在一个不充分的分析、评审下，决定完全重用阿丽亚娜4 的SRI软件的。（可能连软件的需求分 析都没有重做）
因此阿丽亚娜5的问题可能就是：系统规 格说明不全、软件重用分析不细、评审和测试问题

81 阿丽亚娜5： 不能相信阿丽亚娜5对SRI的规格说明会和阿丽亚娜4完全一样，多余的功能肯 定不会有了。但缺乏对验收测试和环境约束的明确规定。
这就是有关规范和标准不全或没有被严格执行、评审不充分的问题。

82 软件重用分析： 软件重用分析基于一个错误观点： 除非证明确有必要，要改变阿丽亚娜４中工作良好的软件是不明智的
即使如此，不对阿丽亚娜5与阿丽亚娜4的差异进行全面细致的分析，无疑是完全错误的

83 其它： 报告中对OBC软件的不足只字未提，但似乎还有一些疑义： 1。接口问题 2。对SRI的切换控制 3。自身的冗余
4。输出的合理性分析及切换 开发问题完

84 评审与测试： 在前面的假设下，估计SRI软件是这样形 成的：
SRI分包商基于继承性，决定重用阿丽 亚娜4的SRI软件，至少对该决定的评审是不充分的

85 之后进行的一系列测试，一方面是由于规格说明中没有明确规定，另一方面是自身也没有主动去求细求全，再有一些观念问题（后面分析），总之，是不充分的。

86 测试问题： 考虑到SRI软件的重用，有两类测试可以 发现故障： 1。鉴定测试 2。仿真测试

87 鉴定（Qualification）测试：
阿丽亚娜5控制系统的鉴定测试包括： 设备鉴定（SRI应是控制系统的有关设备） 软件鉴定(OBC软件) 各级综合 系统确认测试

88 SRI的鉴定测试： SRI也应按硬、软、组装、综合来测试 SRI的规格说明没有给全测试要求
供应商进行了严格的测试，没有主动地充分测试，而充分的测试可以发现故障 鉴定测试验证是否完成任务，以规格说明为依据。但测试时不考虑一个完整的工作程序，无疑是有欠缺的。尽管没要求

89 控制系统鉴定测试（没太多地说） 难道控制系统的规格说明中也没有提针对阿丽亚娜5轨道的需求？
控制系统集成后的确认测试不包括对飞行全过程的试验是不可理解的。

90 委员会认为： 委员会已注意到SRI的系统规格说明没有 指明对所选用实现方案的操作限制。这样的对每一个关键设备都必须强制遵循的对操作限制的声明，可用来鉴别任何与阿丽亚娜５轨道的不一致性。

91 不理解： 阿丽亚娜5的SRI的问题是在阿丽亚娜5 正常飞行时就会发生的问题
可能这样的测试都要写在规格说明中，这样的话，对规格说明的忽略就是规范、管理的大问题了

92 仿真测试： 阿丽亚娜5的仿真测试是验证系统的性 能、功能、协调性 不一定所有设备都用实物，但关键设备应置于回路
SRI由于其重要性，在开始是被要求置 于回路的

93 将SRI置于回路有两种方法： a.把它置于三轴转台上(用于激励环形激光陀螺)，用仿真的方法通过一个专用测试输入接插件和一个专门为此设计的电路板来代替加速度表的模拟量输出，这种方法与在设备层测试时提到的方法相似 b.由仿真提供的信号，通过一个专用测试 输入接口来代替加速度表和环形激光陀螺二者的模拟量输出。

94 第一种方法可进行高精度仿真(在三轴转 台带宽限制内)，费用昂贵。第二种方法便宜，其性能主要依赖于仿真精度。两种情况的大部分电子设备和全部软件都在真实的操作环境中进行测试。

95 但是 最初计划以方法b将SRI置于回路。 但最后还是用模拟软件代替了SRI
只是为了检验OBC和SRI的协调性，用真 实的SRI进行了一些开环试验

96 不用真实SRI的理由： ●单机SRI在设备层认为是完全合格的
●箭载计算机导航软件的精度主要取决于SRI测量精度，在ISF中这个精度不能通过电子线路 产生测试信号来达到 ●故障模式的仿真不可能采用实际设备，而只 采用模型 ●SRI的周期是1ms，而在ISF中仿真的周期是 6ms，这样增加了接口电路的复杂性，从而可能影响仿真精度。

97 委员会认为： 系统仿真测试的目的不仅要检验接口，还要把 系统作为完成特定用途的一个整体来检验。 假设象SRI这样关键的单机通过自身鉴定或者它在阿丽亚娜４中使用过就被批准通过，这 肯定是冒险的。 尽管希望得到高精度的仿真，但显然以牺牲精 度来达到其它目标更可取，其中包括检验设 备例如SRI的系统综合性能。制导系统的精度可通过分析和计算机仿真来得到验证。 测试完

98 评审的问题： 报告中对评审着墨不多（可能是评审的技术性太强，不易量化和控制。这也是软件工程技术正发展的方向），但也承认评审是一个最重要的方法。 确实是一个非常重要的方法。

99 评审： 防止故障的一个最重要方法是评审 评审是设计和鉴定过程中的一个组成部分，是在所有层次上必须进行的一项工作，它涉及所有参与工程的各方(也包括外界专家)。 在一个如此规模的研制计划中，在评审过程中确实已成功地解决了数千个问题和潜在故障，但...

100 评审： 但显然不容易检测出象引起阿丽亚娜 501故障的主要技术原因这种类型的软 件设计错误。 确实，要评审查出数据转换的错误很难
但评审没有查出规格说明、需求、重用的问题是说不过去的

101 评审： 然而，明显地在评审中，对SRI软件的 限制没作全面分析。没认识到测试覆盖不能充分暴露这种软件上的限制问题，也没认识到在飞行中允许校准软件工作可能造成的牵连影响。 在这些方面，评审过程是这次故障的一个责任因素。 评审完

102 其它推论： 报告中似乎对ESA的软件开发方法有疑义，有可能是针对开发过程及过程控制的 这与前面其它问题一起，可以看出，管理上还是有问题的。
许多问题最后都会与管理不足有关。

103 分析总结

104 a.在发射准备及倒计时过程中，无与故障 有关的事件发生；
b.发射时气象条件是可接受的，对故障的 发生没有影响。未发现外部关联因素； c.发动机点火和起飞正常，环境(噪声和振动)对运载火箭和有效载荷的影响与事故无关。推进器性能满足规格说明的要求

105 d.H0后22秒，控制主发动机喷管的液压伺服机构开始出现频率为10Hz的压力变化。这一现象非常重要且未解释完全，但考虑后认为它与故障无关；
e.在H0后36.7秒(起飞后约30秒)备份SRI中的计算机变得不可操作，该计算机是制导和姿态控制备用的计算机。这是由于一个与运载火箭水平速度有关的内部变量超过计算机软件要求的限制值引起的

106 f.约0.05秒后，硬件、软件与备份系统一 样的主SRI由于同样的原因失效。由于 备份SRI已经不可操作，以至不能继续 获得正确的制导和姿控信息，不可避免地丧失这次飞行任务。
g.SRI故障的结果是，主SRI实际上是传送诊断信息给运载火箭主计算机，这些信息被当作了飞行数据并用于飞行控制计算。

107 h.根据这些计算，主计算机控制助推器喷管，以及稍后的主发动机喷管，去对并未出现的姿 态偏差作了大的校正；
i.姿态的迅速改变发生了，由于气动载荷导致运载火箭在H0后39秒产生解体； j.由于解体，在4Km高度，离发射台的1Km处，按照设计，自毁装置自动点火； k.碎片散布在5×2.5Km2的范围内。在恢复的设备中有两个SRI，它们已用于分 析。

108 l.遥测数据的事后分析列出了许多其它异 常现象，调查后表明它们与事故无关
m.阿丽亚娜５的SRI与现应用于阿丽亚娜 ４的基本一样。在SRI计算机中产生停 机的软件部分在发射前用于校准SRI， 阿丽亚娜４在倒计时停顿情况下同时保证可迅速地对系统再校准。这个重新校准功能在阿丽亚娜５中无任何目的，然而为了通用的原因保留了，并象阿丽亚娜４那样允许在起飞后工作近40秒。

109 n. 在用于阿丽亚娜４和5的SRI软件设计中，采取了一个决定，即不必对SRI计算机由于与水平速度相关的变量值过大而产生的不可操作进行保护。而对校准软件的其它几个变量提供了保护。采取这一设计决定时，没有分析或完全理解当在起飞后校准软件操作时，这个特殊变量会取那些值。 o.在阿丽亚娜４飞行中采用的是同样类型的SRI ，由于在飞行前40秒中轨道与水平速度相关 的那个变量没有达到软件中给出的限定值，有足够的操作裕量，所以没有出现故障。

110 p.阿丽亚娜５具有较高的初始加速度和导致水平速度逐渐增大的轨道，该水平速度比阿丽亚 娜４的水平速度大5倍多。在40秒内，阿丽亚娜５产生的高水平速度超过限值，该值引起 SRI计算机停止 工作。
q.参与阿丽亚娜５研制的所有主要合作伙伴均参加的评审过程的目的是确认设计，并通过飞 行试验资格。在这个过程中，对校准软件的 限制没作全面分析，并且对允许其在飞行中 继续工作可能产生的牵连影响也未认识。

111 r.SRI的规格说明在设备层测试中没有明确包括 阿丽亚娜５轨道数据。因而没有在模拟阿丽 亚娜５飞行条件下测试重新校准功能，设计 错误没被发现。
s.在进行全系统仿真中采用完整的SRI在技术上 是可行的。基于一些原因，决定使用SRI的模拟输出，而不是SRI本身或其详细的仿真模型。假如用了SRI，故障就会被检查出来。 t.事后仿真已在含SRI的软件和模拟环境的计算 机上进行，包括了从阿丽亚娜５01飞行得到 的实际轨道数据。这些仿真真实地再现了导 致SRI故障的事件链。

112 结论 阿丽亚娜501的故障是由于主发动机点火 后37秒(起飞后30秒)制导和姿态信息完 全丢失造成的。信息的丢失是由于SRI 软件的规格说明和设计错误引起的。 在阿丽亚娜５研制过程中进行的广泛评审和测试未包括对SRI或完整的飞行控制 系统进行充分的分析和测试，而这样的测试是能够查出潜在的故障的。

113 基于分析和结论，阿丽亚娜5故障 分析委员会作出如下14条建议：
501故障分析委员会的建议 基于分析和结论，阿丽亚娜5故障 分析委员会作出如下14条建议：

114 R1. 起飞后立即关掉SRI的校准功能。更一 般地说，一切不是飞行所必需的软件功能，都不能在飞行时运行；
剔除直接原因 多余物不要

115 R2. 对准备的测试设备，在技术可行的条件下尽可能多地包括真实仪器，引入真实的输入数据，进行完整的、闭环的、系统的测试。在任何飞行试验之前必须进行完整的仿真。必须达到大的测试覆盖率。
这一条应作为通用的设计规范 以后就不用每次都要求在规格说明中写明确了 事实上这是最低、最基本的要求，不知怎么给丢了

116 R3. 不允许任何敏感器，如SRI，停止传送 正确的数据；
应该是对软件错误，应作处理，而不去关机 如是硬件错误，也只好关机 本质上是应允许软件出错，并对此进行预防、处理和保护 还有，软件也要冗余，以保护意想不到的错误

117 R4. 对每一个与软件一体的设备项目，组织一个专门的软件鉴定评审。系统设计师应参加这些评审，并对该设备参加整个系统测试作出报告。所有该设备的使用限制应当向评审委员会明确、显式地报告。把所有关键软件作为一个配置控制项目(CCI)； 一是评审要全面、明确 第二很重要，不仅要把软件当作产品，关键软件还要严格控制。

118 R5. 评审所有飞行软件(包括嵌入式软件)， 特别是
判别所有在代码及其说明文件基于设备提 供的数量值构成的隐含假设。检查这些假 设是否超出该设备的使用限制。 验证软件中任何内部或传送变量的取值范 围。 对箭载计算机软件，尤其是其转换处的潜 在问题，应有项目组提出解决的方法，并 经一组外部专家评审，这些专家应向箭载 计算机鉴定委员会作出报告。

119 这些具体的要求应纳入技术评审、走查、审查的检查单
同时也应纳入可靠性设计指南 对此在评审中严格检查 对评审的要求要规范化

120 R6. 若技术上可行，应考虑将异常限制在任务和设备备份能力之内；
将自身的异常处理本身就当作一项任务和需求 还要考虑备份－－软件冗余

121 R7. 为遥测提供较多的关于元部件故障数据，以降低回收设备的必要性；
看的出，他们对遥测不满意 遥测应立足于在失败后能提供故障分析的足够数据 首先假设：飞行失败

122 R8. 重新考虑关键部件的定义，把软件引起的故障考虑进去(特别是单点失效)。
把软件提到与硬件同等的地位 看来ESA也没有做到

123 R9. 当评审规格说明、代码及说明文件时，应包括外部(相对于该项目)参加者。确 保这些评审考虑了论据本身，而不是检查已作完的验证工作；
1。评审不能走过场 2。软件技术评审有其特定含义 3。有独立专家参加评审（专心找错误）

124 R10. 在规格说明和测试需求中包括轨道数据 亏吃得太大了 有必要通过两条渠道去提

125 R11. 评审现有设备的测试覆盖率，在认为必要时将其扩展；
按规范，所有测试都应该进行测试计划、测试完成两次评审，其中就应该包括测试的充分性和测试覆盖率 看来严格执行规范在ESA也是一个问题

126 R12. 给说明文件与代码同等的重视程度。改进技术以保持代码与说明文件相一致；
文实一致，永远是很重要的 配置管理是一种保证方法，但要严格执行 同时还需要不断改进和完善 当然，这一切都建立在首先要写、要按时写文档

127 R13. 建立一个小组，他们为阿丽亚娜５准备鉴定软件的过程，提出确认这一鉴定的严格规则，并保证在阿丽亚娜５中软件的规格说明、软件的验证和测试，具有一致的高质量。要考虑将外部RAMS专家包括进来；
成立专门的QA（质量保证）小组

128 R14. 在阿丽亚娜５研制中必须考虑工作伙伴间更为透明的合作组织结构。要达到系统协调，需要在合作伙伴间具有紧密的工程合作、明确的责任和权力划分、以及简单又明确的界面关系。
提出了行为规范的问题 责、权、利明确分工是先进管理的重要基础之一

129 68389085（O） 68389504（H） mdtang@btamail.net.cn
谢谢！ （O） （H）

130