发布信息当前位置: 首页 » 供应 » PC/嵌入式系统 » 关于使用合格工具的DO_178B标准基于模型设计(二)

关于使用合格工具的DO_178B标准基于模型设计(二)

点击图片查看原图
公司: 北京经纬恒润科技有限公司 
单 价: 面议 询价 
最小起订量:    
供货总量:
发货期限: 自买家付款之日起 3 天内发货
有效期至: 长期有效
最后更新: 2015-07-20
相关信息
 
产品详细说明
DO-178B和相关标准综述
A.DO-178B
     DO-178是一种用于保证飞行系统软件的商业飞行标准。它被广泛应用于军事、宇宙空间等领域,这很大程度上是因为缺少一种可以宽泛应用的航空标准。DO-178A发布于1985年3月,DO-178B发布于1992年11月,DO-178C当下正在研究。DO-178B已经清晰地定义了一个完整的软件进程所包含的软件需求,比如,软件定义,编码,整合,认证和结构管理。对每一个对象来说,输出结果都是严格需要产生,检验,最后认证的。这些对象和输出结果按照完整的软件等级,总结在表A-1到A-10里。A是这套软件中最高等级的一级,它一般用于应对失败,或者突发状况时的应急操作。
     在DO-178B引进时期,开始了基于模型设计的初级实验。快速回顾模型的相关表和试验文档,展示了模型使用的相关概念。这也是为什么DO-178C正在研究的其中一个原因。DO-178C中第11个协议出现在2009年6月,这一次的会展有超过100参展作品,亮相了许多飞行器厂商和供应商。这次会展也有飞行器官方委员会成员参与,包括FAA成员,EASA成员,甚至有中国的CAA成员。从DO-178C诞生起,就肩负着补充完善DO-178B的使命,成为世界航空软件的最高开发标准。
     参与进DO-178C,而且为此项目成立了模型委员会。对先前基于模型设计活跃度的描述的对象和输出进行了刷新,使得该项目获得了切实可行的支持。文章第四节将对工作流程进行描述,并将其与传统DO-178方案中基于模型设计的部分进行了比较。
B.相关标准
     Simulink在支持多模和多部署领域的有着独一无二的能力。例如,许多航空安全标准采用Simulink进行仿真,但是并没有包含在DO-178B体系内,尽管DO-178B包含了系统工程,部署在底层基于DSPs的代码,还有基于HDL的硬件。工程组基于DO-178B程序在Simulink的仿真,可以复用于其他标准和应用,这也会影响到项目的投资,可复用的部分总结如下。
     ARP-4754“对于高集成和高复杂度的飞行器系统的认证考虑”,针对的系统工程,包含了:系统需求、需求确认、系统设计、系统认证。
     ARP-4761“民用飞机系统和设备的产生安全评估的流程的指导方针”,针对系统安全评估方面,包含了:树形检错图表、公共原因分析、区域安全分析、功能性危险评估。
     DO-278,“交通,航空,监督和空中交通管制的指导方针”,针对地面和空中基础系统软件工程,包括了:软件生存周期、对象安全、需要的证据、用于微处理器和数字信号程序的保护软件。
     DO-254“对飞行器电子硬件的安全设计”,针对硬件工程的保障,包含了:硬件的生存周期、对象安全、需要的证据、对FPGAs和ASICs的保护。
C. DO-178B工具的限制条件
     在DO-178B的12.2中,描述了工具的限制条件。现说明什么情况下工具的限制条件是需要的:当在输出没有未证实的情况下,使用软件工具,文件的程序是有限的,递减的而且是自动的,这在第六节中有详细说明。DO-178B提出了两种类型的限制标准,一个用于软件开发工具,例如代码生成器,代码编译器,其中代码编译器可能引进错误。另外一种用于软件认证工具,例如代码检测和代码静态分析,他们虽然不会引进错误,但是可以链接失败。一个工具不可能通过工具自动对自己进行检验。它只能在特定的项目环境或飞行应用中通过某个标准被检测是否符合条件。
     这种标准对于审核开发工具是非常严格的,尽管认证工具的标准很少,但是仍然意义重大。最后导致的结果是,虽然有很多认证工具但却很少有能通过标准审核而应用于商业的合格套件。事实上,随着一些理论[10]的开发,有很多非DO-178B的合格C编译器,作为一种飞机厂商的选择,展示在FAA工具论坛。
     对于为什么商用编译器不经过FAA认证,给出几个最主要的原因:
     1.复杂性
     2.利益不清晰
     3.市场的力量
     4.语言的趋势
     输送一个算法到飞行器,代码的执行过程需要代码生成器、交叉编译器、整合器、链接器、运行器,该过程需要许多工具,对于不清晰的利益的考虑很重要。如果一个链接器是合格的,那么要是能知道最后的利益应该给这个过程中的哪个部分就好了。同样,如果一个代码是正确的,但是编译器和链接器有问题,怎么证明代码本身有错,而编译器和链接器是正常的。
     一个出现在FAA工具论坛的供应商也曾经表示,合格的开发工具要么是一个非常简单的工具,要么远落后于技术的发展。这种简单归因于工具质量的现实需要,需要减少应用空间,导致减少了能达标的成果。这个供应商表示,他们内部的研究表明一个合格的开发工具要比一个合格的认证工具贵20倍。而且,他们在几个项目中对工具使用的统计结果报告中显示,开发工具的质量并没有给投资者相对应的回报。而使用合格的认证工具的结果却是节省了项目成本。
     这样一来,DO-178B的业界人士都普遍采用不达标,但是符合科技进步水平,自动化而且合格的认证开发工具。这使得科研者按自然合理的方式来激发他们的设计热情,提供一个很高的参考认证严苛条件,而且使投资者们甚至能在第一个项目中就得到收益。
     对于高完整度的系统,甚至是完整的包含了代码生成器、编译器等的合格工具链来说,模型的目标代码认证非常关键。一个原因单纯是因为可以增加信心;有些人称之为“安全带”。另一个原因是基于软件数值结果,不同的平台采用了不一样的小数部分近似取值。例如,0.1开平方,单精度的浮点型不是0.01,会在小数点的左边很远有小数。这些近似值的表示看似微妙,但是却会在精密数学算法中产生危险的不同的运行结果。
     这将会导致,同一个算法,相同的代码作为运行目标的时候,在不同的平台上运行会产生不一样的结果。或者再举一个例子,相同的代码,有着相同的编译器的同样的信息处理器,在刷新数学编辑器以后,也能产生不一样的结果。当今的算法采用坐标变换,快速傅里叶变换,以及三角函数进行动态变换和现代飞行控制法则。处理资源通常需要用到单精度数据类型。所以,虽然工程师们应该期望不同,但是他们应该检测系统的容错能力,而且坚持致力于研究出对这些影响具有更高稳定性的算法。一方面应该警惕限定测试方法。不要拘泥于限定测试,利用好SIL,PIL以及其他的自动化技术。
 
DO-178B开发方法
A.传统手动开发方法
     在1900年,为了满足DO-178B标准,传统开发和验证软件的方法是设计和编码是用手工结合一些自动工具用来编译和验证软件。DO-178B主要的开发进程包括高层次的需求、低层次需求、源代码和目标代码。开发过程中用到的工具有文本编辑器、各种集成开发环境、代码编译器。基于一些工具自动化代码动作的验证过程包括检查、符合标准、测试、和联合分析。正如在前一节中提到的,不但要使用合格的代码验证工具还有合格的代码编译器。开发和验证过程如图7所示。传统上,使用和选择工具基于工具的资格地位。
图 7应用DO-178B标准的传统手动开发方式
B.传统基于模型设计方法
     到2000年,基于模型设计和代码生成越来越多的应用于基于DO-178B标准开发。在2004年,一个公司报告称在过去一年里他们生成和验证了一百万行基于DO-178B标准的代码,而且软件被认定为A级水平。而且他们发现自动生成的代码达到了6σ软件标准,质量远远高于手写代码[13]。如图8所示,建模能够做到对预先的纸质设计更早和更严格的验证。然而,由于没有被授权,这些认证工具带来的好处还没有被完全挖掘出来。在2009年3月,当MathWorks公司发布DO认证工具包(到DO-178B)。
图 8传统的基于模型设计方法基于DO-178B应用
C.如今的基于模型设计方法
     MathWorks公司最近发布了DO认证工具包(到DO-178B),使得所选认证工具符合DO-178B标准。产品的1.0版本包括以下工具的鉴定数据都能够和以前发布的R2008a或者R2009a版本一起使用。
     1.Simulink验证和确认
      DO-178B模型检查
     2.系统测试
      元素临界测试
     3.软件运行时错误检测工具 PolySPACe代码验证
      Polyspace为C/C++代码验证产品
     图9展示了一个高度自动化验证工作流与合格的工具。建模工具为开发工程师体现设计的高灵活性。代码生成工具生成高效的代码而且提供了很多优化代码的选项。有一个例子,一个公司用simulink为一个多核型处理进程开发算法,按一个标准执行时发现生成的代码的运行速度比手动编写的代码快30%。
图 9现今用合格的工具基于DO-178B标准的基于模型设计的方法
对DO-178B项目的推荐
     以下的概述描述了使用MathWorks公司的使用合格工具基于DO-178B标准产品的推荐工作流程。
     1.需求过程
     需求验证使用传统的同类行业评审的需求。对于需求链接,使用需求管理界面在模型和高水平需求建立连接,高水平需求以文本或者第三方工具形式呈现。
     2.建模过程
     对于低级需求,用Simulink和Stateflow建模。注意每个项目必须分别考虑,并不是每一个领域都适合使用Simulink或Stateflow建模。一些特定的软件就需要用到传统的软件开发方式。避免从Simulink模型转化成第三方设计工具时增加一些没有实际意义的步骤,同时也可能引入新的错误。这也是额外的工作,必须进行评审。
     为了实现基于模型设计的全部优势,早期的设计验证应该是作为模型级别的验证,而不是仅仅作为底层信号流的活动。基于高级需求执行仿真测试。以下是一些关于模型验证过程中的建议:
     a.用模型顾问使项目符合DO-178B标准
     b.使用需求管理界面的链接需求和生成报告
     c.用系统测试(SystemTest)来自动仿真和生成报告使项目符合DO-178B标准
    d.在仿真时用模型覆盖度来评估高级测试用例的有效性
     使用DO-178B标准过程中一个重要的步骤是设计评审。评审的目的是低级需求服从高级需求且都要符合标准。达到这个目的的方法是评审和分析。模型顾问(Model Advisor)执行对模型自动检查,检查的内容包含了大部分的标准,这个是人工检查所不能做到的。用仿真对模型和高水平需求一致性的评估也是一种分析手段,而不仅仅是传统的设计检查。仿真相比于普通检查在查找设计中的实质性问题时更有效。
     仿真结果应记录,评估和项目归档。项目测试(SystemTest)为运行仿真提供了一种机制,那就是自动生成测试报告和用一个合格的通过/失败检查器来评估仿真结果。自动仿真使用项目测试这个工具(查看通过/失败检查器)从而减少执行仿真结果的检查次数。测试执行时在发现错误的情况下,它以自动存储数据的形式为工程师提供调查错误的能力。在模型发生变化时,也可以使用该工具重新回到测试阶段。
     到目前为止在仿真时还不能使用模型覆盖工具。在仿真时,使用模型覆盖工具提供意向评估,即对基于测试的有效高级需求怎么覆盖模型中功能进行评估。值得注意的是模型中可能会有派生的需求,因此在仿真时模型覆盖报告(Model Coverage Report)可能不能完全覆盖需求。用模型覆盖报告中的数据作为simulink设计验证器( Simulink Design Verifier )的输入来完善测试覆盖范围。
3.编码过程
     从开发的角度看,使用Real-Time Workshop Embedded CODer生成代码是非常有效的获得代码的方式。不管代码是不是自动生成的,对源代码的验证都需要把检查代码作为基于DO-178B标准认证过程的一部分。使用PolySpace产品自动分配代码审查和代码认证被认为是通过使用DO合格工具包(DO Qualification Kit)来执行PolySpace三个代码审目标。应用PolySpace和DO合格工具包(DO Qualification Kit) 大大减少了在检查代码的花费。
4. 目标代码测试过程
     在这些测试中,目标代码测试和结构覆盖的实现可能是DO-178B项目中更加耗时和昂贵的过程之一。因此需要实现这样一个目标,即将模型级使用过的高级测试用来测试这些代码。这个计划很棒,但可能还是需要一些低级测试,来保证代码的完整结构覆盖。
     嵌入式IDE LinkTM产品是在这个过程中用到的一个重要工具。这个工具允许Simulink对使用流行的IDEs和编译器编译的代码进行PIL测试。使用IDE链接和CPU开发板互相协调将允许测试用例复用,来检验飞行代码是否是最有效的方式。
     如上所述,模型覆盖工具可以用来判断仿真阶段使用的测试用例覆盖率达到什么水平。很可能高级测试用例无法达到全覆盖。为了实现全覆盖,Simulink设计验证器可以通过自动生成测试用例来补充高级测试用例。这样做的一种有效方式是在Simulink设计验证器中输入高级测试的模型覆盖数据,然后它将会生成需要的测试用例来补充未覆盖到的模型部分。工程师也可以使用模型覆盖工具来运行生成的测试,并且确认模型是否被覆盖。这组测试用例集合也可以在这个代码上执行。第三方代码覆盖工具也可以评估这些测试用例的实际代码覆盖。代码测试过程中可能会有一些额外的代码覆盖漏洞,这可能需要进一步的分析,但是这应该只是整个覆盖中的一小部分,整个测试的工作量已经显著地降低了。
     DO-178B标准还要求在输入数据范围进行等价的类测试。模型覆盖工具在这方面同样也可以有所帮助,因为它可以测试过程中记录信号范围,并且显示获取的最小值和最大值。此外,在输入信号上,Simulink设计验证器可以设置通过测试目标模块自动生成等价的类测试。这种情况下,用户必须根据数据范围和期望的等价类来指定测试值。使用Simulink设计验证器来生成等价类测试用例进一步的减轻了测试工作量。
     使用Simulink设计验证器来设置系统的最佳方式是在设计中使用参考模型,并且为每一个参考模型单独的生成测试用例。由于仿真性能的提高,参考模型已经应用到了许多公司大规模建模开发。
     信用(credit)可以取代某些类型的鲁棒性测试,用于PolySpace正式分析。PolySpace有能力检查出未初始化的变量、数字溢出、无限循环、除0等等。因此使用这个具有限制功能的工具,检查这些类型错误的测试用例就不再需要了。这样就消除了这些鲁棒性测试用例,从而进一步的减轻了整体目标代码测试的工作量。
 
总结
     本文介绍基于模型设计的概述以及重要的注意事项,关于使用模型进行开发以及生成嵌入式飞机软件。重点介绍了使用MathWorks中的新技术来进行模型和代码的验证。新的DO-178B验证工具资格包优化的了这个过程。
 
参考文献
1. “Design Times at Honeywell Cut by 60 Percent,” W. King, Honeywell Commercial Aviation Systems,Nov. 1999, http://www.mathworks.com/company/user_stories/
2. “Flight Control Law Development for F-35 Joint Strike Fighter,” D. Nixon, Lockheed-Martin Aeronautics,Oct. 2004, http://www.mathworks.com/programs/techkits/pcg_tech_kits.html
3. “ESA's First-Ever Lunar Mission Satellite Orbits Moon with Automatic Code,” P. Bodin, Swedish Space,Oct. 2005, http://www.mathworks.com/programs/techkits/pcg_tech_kits.html
4. “Automatic Code Generation at Northrop Grumman,” R. Miller, Northrop Grumman Corporation,June 2007, http://www.mathworks.com/programs/techkits/pcg_tech_kits.html
5. “Software considerations in airborne systems And equipment certification,” RTCA/DO-178B, RTCA Inc.Dec. 1992
6. The MathWorks, Inc., www.mathworks.com
7. “Best Practices for Establishing a Model-Based Design Culture,” SAE Paper 2007-01-0777, P. Smith, etc.,March 2007, www.mathworks.com/products/simulink/technicalliterature.html
8. “Eleventh Joint Meeting of Joint EUROCAE Working Group 71 And RTCA Special Committee 205 Software considerations in airborne systems And equipment certification,” RTCA No. 161-09/SC205-025,June 2009, http://www.rtca.org/CMS_DOC/205sum11ja-0906.pdf
9. SC-205/WG-71 Plenary Website, SG4 Model-Based Development Group, ultra.pr.erau.edu/SCAS
10. “Crafting an FAA-Qualifiable Compiler,” V. Santhanam, Boeing, ERAU/FAA Software Tool Forum,May 2004, http://www.erau.edu/db/campus/softwaretools_presentations.html
11. “Use of MathWorks Tool Suite to Develop DO-178B Certified Code,” B. Potter, Honeywell, ERAU/FAA Software Tool Forum, May 2004, http://www.erau.edu/db/campus/softwaretools_presentations.html
12. “What Every Computer Scientist Should Know About Floating-Point Arithmetic,” D. Goldberg,Computing Surveys, 1991, http://docs.sun.com/source/806-3568/ncg_goldberg.html
13. “Achieving Six Sigma Software Quality Through Automatic Code Generation,” B. Potter, Honeywell,June 2005, http://www.mathworks.com/industries/aerospace/miadc05/presentations/potter.pdf
14. “Software Development with Real-Time Workshop Embedded Coder,” N. Holliday, Thales Missile Electronics, April 2008, http://www.mathworks.com/programs/techkits/pcg_tech_kits.htm

公司联系方式
  • 北京经纬恒润科技有限公司 [加为商友]
  • [第3年] 指数:5
  • 联系人许女士(女士)    
  • 电话
  • 手机(010)64840808-5283
  • 地区北京
  • 地址北京市海淀区知春路7号致真大厦6层
  •   
同类产品

[ 供应搜索 ]  [ ]  [ 告诉好友 ]  [ 打印本文 ]  [ 关闭窗口 ]  [ 返回顶部 ]

中国测控网郑重提醒:网上过低的价格有可能是虛假价格信息,请买家谨慎对待,谨防价格欺诈行为。投诉或价格欺诈行为,请发送邮件至 [email protected]