DO-178关键等级

学术   科技   2023-10-21 09:32   山东  
SAE ARP 4761标准指导安全性评估,用于确定关键等级,有时客户会直接告知开发方软件关键等级。能否通过友好协商的方式降低客户要求的关键等级?答案是不行。
DO-178标准中定义了软件的关键等级。A级是最严格的。其失效会导致部分或全部乘客罹难,其下是B级,这一等级失效可能导致部分乘客死亡,然后是C级,这一等级的失效不会造成乘客死亡,但会造成重伤。D级失效会造成乘客轻伤,而E级失效对飞行安全无任何影响'。
对于关键等级E,可不必执行DO-178标准,这意味着如果分配了等级E级,就并不强制要求将DO-178或DO-254标准应用于航空电子系统开发之中。
对于如盥洗室顶灯或客舱娱乐系统之类的简单系统可否直接定义为E级?并非总是如此。盥洗室的顶灯可与独立的电源连接,因此可保持持续供电。如果电源故障,那么还可有电池作为备用电源。为什么要做这样的冗余设计呢?比如说飞机停留在地面上,座舱充满浓烟,机组人员要求紧急疏散。此时绝对不希望被困于盥洗室之中的乘客因为一团漆黑、手脚忙乱而找不着出路。因此,即使是盥洗室的顶灯也应进行D级认证。
客舱娱乐系统情况又如何呢?比如座椅后背上的显示器,在飞机飞行过程中,如果不是因为系统故障导致机舱浓烟弥漫,那么它看似并不重要。而在座舱中,浓烟往往又是导致机毁人亡的罪魁祸首之一,调查人员有时发现娱乐系统与座舱系统主电源共享一个总线。因此,关键等级是非常重要的,即使是互不相关的系统之间也是如此。

(1)A级:灾难性的,经常导致飞机损坏和乘客全员死亡。这种情况可能仅仅是因为机组人员过高的工作负荷造成。一些功能丧失不期而至,飞行员全神贯注处理问题时灾难就降临了。这种灾难不一定是因为系统故障或错误指示造成,可能是因为飞行员工作负荷过重而无法保持正常飞行。
DO-178C标准2.3.3节定义原文:A级软件指经过系统安全性评估过程表明其异常行为将导致系统功能失效进而产生航空器灾难性失效情况的软件。
(2)B级:危险的。也许不一定造成全部人员死亡,但是有导致危险的可能。
DO-178C标准2.3.3节定义原文:B级软件指经过系统安全性评估过程表明其异常行为将导致系统功能失效进而产生航空器危险失效情况的软件。
(3)C级:重大的。可能造成人员受伤和飞机失控。
DO-178C标准2.3.3定义原C级软件指经过系统安全性评估过程表明其异常行为将导致系统功能失效进而产生航空器重大的失效况的软件。
(4)D级:轻微的。可能造成一些影响,但是飞机能够克服这些影响,驾驶员能保持其操控。
DO-178C标准2.3.3节定义原文:D级软件指经过系统安全性评估过程表明其异常行为将导致系统功能失效进而产生航空器轻微的失效情况的软件。
(5)E级:无影响。由系统安全性评估过程确定这些关键等级。如果软件关键等级是E级,则需要说明确定为E级的原因,不能仅仅对CAAC说明:“E级,无关紧要。”如果客户没有说明E级的理由,则开发方必须予以说明。

DO-178C标准2.3.3节定义原文:E级软件指经过系统安全性评估过程表明其异常行为将导致系统功能失效,但不会影响航空器的工作性能或增加驾驶员工作负荷的软件。

在通常情况下,在设计一个产品或满足TSO时,需要澄清其对应的关键等级。DO-178标准附录A中给出了每个关键等级需要的工作,关键等级对比如表4-1所示。这往往是学习和研究的焦点所在,在其中也许能发现一些捷径,但与其对这些捷径不厌其烦、不遗余力地论证和说明,还不如老老实实遵循标准要求,这样反而花钱少见效快。

(1)语句结构覆盖。适用于A级、B级及C级。
(2)决策条件覆盖。C级不要求,仅适用于B级和A级。MC/DC仅适用于A级,这是DO-178B的特定要求。它不仅是测试,而且是分析。许多人认为他们必须不断地测试以达到结构覆盖要求,但其实MC/DC并不仅仅是覆盖率,也并非一定通过测试实现,在没有其他替代方法的情况下,甚至可以完全通过分析获得。
此处说明,在基于需求的软件测试中,并未要求完全使用测试用例实现测试用例对需求100%的覆盖同时实现对源代码100%的MC/DC,可以使用分析辅助测试的方式,但必须做出合理性解释并经过审定机构或DER的允许。使用分析的原因是在某些情况下,基于测试用例的源代码覆盖分析并非完全可行。使用测试用例执行结构覆盖分析的原理是对源代码进行插桩,而后用测试用例驱动插桩后的源代码执行,获取覆盖率信息。根据插桩技术的不同,覆盖率信息获取的方式也不同,覆盖率信息获取一般通过实时输出(运行时通过外部接口实时输出)或异步输出(运行时写内存,空闲后通过外部接口输出)方式。在某些情况下,如操作系统的内核函数、网络通信的核心协议处理等,对源码插桩后,获取覆盖率信息会影响代码的运行时序、导致运行错误,或无法运行。对一些特定系统,如单片机脉冲发生器,内存资源非常有限,无外部接口,导致无法插桩,即便插桩也无法输出覆盖率信息。虽然目前可使用目标码执行监控的方式获取覆盖率信息,但是工具专用,且需要特定工装支持,代价巨大。在此情况下,可使用覆盖率分析报告的方式对覆盖率进行补充。
(3)配置管理。随着关键等级的提高而越来越严,大多数DER(和FAA人员)基本都口执一词:“随着关键等级的提高,我们的要求会更加严格。
 然而,“严格”是一个模糊的词汇。DO-178标准并没有指出A,B和C级之间在配置管理方面的显著不同,但是随着从C级至B级到A级,管理会越来越严格。换句话说,问题报告、配置管理及状态管理过程必须更加准确,要求更详细的说明和更严格的变更管理。
之前从未有人对不同关键等级的配置管理写出不同的过程,但是DER对A 级要求更严格的执行过程,而对C级则有所放松。
(4)源代码与目标码关联。仅适用于A级。FAA对飞机制造商会发布一些用于解答特定问题的文件,例如,如果使用了一款编译器,那么许多人希望使用基于宿主机的编译器在宿主机上对系统进行测试,因此就使用交叉编译。时,软件研发人员也希望通过对代码优化以缩小目标码大小或提高执行速度,这往往通过编译时的“优化”选项。但能否测试或鉴定编译器?回答是否定的,这项工作会因工作量巨大而无法完成,如果某人认为可以对编译器进行彻底测试, 那么简直就是天方夜谭。此外,通过编译器产生的目标码其实最终是经过测试的,其中当然也就隐含了对编译器的测试。但对A级系统,必须要对编译器有充分置信度,因此对A级系统附加一个严格步骤:“源代码与目标码对应”,以显式地验证编译器将源代码转换为预期的目标码。
如果在仿真环境中测试,则所得结果能否直接用于最终装机飞行?答案是不行,因为最终具有“置信度”的测试必须在真实目标机上使用真实目标码进行。为获得测试的置信度,需要将目标码与源代码做比较,最好在目标机上从始至终使用同一编译器。对于A级系统,通过在目标机上进行测试,表明源代码被正确地编译为目标码。换言之,源代码由编码人员开发,通过编译器形成目标码,需要表明源代码和目标码都应是正确的。
源代码生成工具需要进行工具鉴定,原因是它使DO-178标准中要求的某些步骤自动化,从而不需要人为干预编码过程。工具一旦通过鉴定,即可用于编码过程中,原因是代码如何生成、如何编译及目标代码如何产生均已经得到明确。目前已有四个或五个系统能够自动生成代码并检查代码生成过程,已具备源代码与目标码的对比功能。
FAA并不审定产品工具。随着关键等级的提高,需要的证据和工作量就越多,从C级开始要求代码评审,对D和E级则不作要求。
(5)软件质量保证(software quality assurance,SQA)转换准则。从C级开始要求代码评审及架构需求。其对应的绝大多数工作是伴随自C级、B级至A级的结构覆盖分析活动完成。
对软硬件关键等级的确定基于顶层过程,因此在PSAC和 PHAC中只需要声明安全等级,如等级A,并描述过程,没有必要过多说明等级分配的理由。客户的安全性分析过程支持等级的确定,阐述等级理由应由用户负责,通常研制方只被告知等级分配结果。
应时刻铭记,关键等级的确定必须通过完备、彻底、慎之又慎的安全性分析过程。安全性分析过程确定整个系统及系统内各部件对安全性的影响,进一步确定关键等级及系统架构。

航空维修
航空机务人员的信息平台
 最新文章