欢迎来到麦多课文档分享! | 帮助中心 海量文档,免费浏览,给你所需,享你所想!
麦多课文档分享
全部分类
  • 标准规范>
  • 教学课件>
  • 考试资料>
  • 办公文档>
  • 学术论文>
  • 行业资料>
  • 易语言源码>
  • ImageVerifierCode 换一换
    首页 麦多课文档分享 > 资源分类 > PDF文档下载
    分享到微信 分享到微博 分享到QQ空间

    REG NASA-LLIS-2050-2009 Lessons Learned NASA Study of Flight Software Complexity.pdf

    • 资源ID:1019354       资源大小:20.33KB        全文页数:5页
    • 资源格式: PDF        下载积分:10000积分
    快捷下载 游客一键下载
    账号登录下载
    微信登录下载
    二维码
    微信扫一扫登录
    下载资源需要10000积分(如需开发票,请勿充值!)
    邮箱/手机:
    温馨提示:
    如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如需开发票,请勿充值!如填写123,账号就是123,密码也是123。
    支付方式: 支付宝扫码支付    微信扫码支付   
    验证码:   换一换

    加入VIP,交流精品资源
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    REG NASA-LLIS-2050-2009 Lessons Learned NASA Study of Flight Software Complexity.pdf

    1、Lessons Learned Entry: 2050Lesson Info:a71 Lesson Number: 2050a71 Lesson Date: 2009-05-5a71 Submitting Organization: JPLa71 Submitted by: David Oberhettingera71 POC Name: Dan Dvorak; Adam Westa71 POC Email: Daniel.L.Dvorakjpl.nasa.gov; adam.d.west-1nasa.gova71 POC Phone: 818-393-1986 (Dvorak); 202-3

    2、58-1552 (West)Subject: NASA Study of Flight Software Complexity Abstract: Flight software development problems led NASA to study the factors that have led to the accelerating growth in flight software size and complexity. The March 2009 report on the NASA Study on Flight Software Complexity contains

    3、 recommendations in the areas of systems engineering, software architecture, testing, and project management.Description of Driving Event: Since 1968, the flight software (FSW) used aboard NASA human and robotic spacecraft has grown in size by a factor of ten every ten years. The primary FSW for the

    4、 NASA Crew Exploration Vehicle (Orion) and the Mars Science Laboratory (MSL) are each expected to exceed one million lines of code (LOC). The growth trend is expected to continue because of increasingly ambitious mission requirements and because of the advantages (e.g., zero mass, flexibility) of si

    5、tuating new functionality in software or firmware rather than in hardware. An increase in FSW size is often accompanied by an increase in FSW “complexity“- defined as a state in which the FSW is difficult to understand and verify- and an increase in risk. Problems with FSW during a variety of NASA s

    6、paceflight missions, like those recently reported in References (1) and (2), led NASA to conduct a study (Reference (3) of the engineering activities- from requirements development through operations- that lead to growth in FSW size and complexity. The final report from the study attributes NASAs la

    7、ck of control over these FSW characteristics to cultural factors such as: Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-1. Cost and schedule pressures that lead FSW managers and developers to reduce or eliminate activities where the benefits are no

    8、t as easy to quantify as those from the production of code. 2. Lack of enforcement of FSW standards and local best practices. 3. Pressure to re-use software from a previous mission because it is “flight-proven“ and presumed to be of lower risk. 4. Emphasis on the flight project at hand, with few pro

    9、grammatic incentives for project management to contribute to infrastructure and process improvements that benefit future missions. The NASA final reports findings in the areas of systems engineering, software architecture, testing, and project management are summarized in the Lessons Learned section

    10、 below, and its corresponding recommendations are summarized in the Recommendations section. References: 1. “MRO Spaceflight Computer Side Swap Anomalies,“ NASA Lesson Learned No. 2041, NASA Engineering Network, December 16, 2008. http:/www.nasa.gov/offices/oce/llis/imported_content/lesson_2041.html

    11、 2. “MRO Articulation Keep-Out Zone Anomaly,“NASA Lesson Learned No. 2044, NASA Engineering Network, April 7, 2009. http:/www.nasa.gov/offices/oce/llis/imported_content/lesson_2044.html 3. “Final Report: NASA Study on Flight Software Complexity,“ NASA Office of Chief Engineer, March 5, 2009 4. “NASA

    12、 Systems Engineering Handbook,“ NASA SP-2007-6105, December 31, 2007. 5. “Improving Fault Management for Spaceflight Missions,“ NASA Lesson Learned No. 2049, NASA Engineering Network, April 21, 2009. http:/www.nasa.gov/offices/oce/llis/imported_content/lesson_2049.html Lesson(s) Learned: 1. Engineer

    13、s and scientists often dont realize the downstream complexity (and cost) that result from their local decisions. Overly stringent requirements and simplistic hardware interfaces can complicate software; FSW descope decisions and ill-conceived autonomy can complicate operations; and inattention to te

    14、stability can complicate verification efforts. 2. Unsubstantiated requirements have caused unnecessary FSW complexity where the requirement was either unnecessary or overly stringent. Rationale statements have often been Provided by IHSNot for ResaleNo reproduction or networking permitted without li

    15、cense from IHS-,-,-omitted or misused in spite of a best practice that calls for a rationale for every requirement. Reference (4) places great emphasis on the need to provide rationales. 3. Although overall complexity can be reduced through engineering trade studies involving multiple stakeholders (

    16、e.g., flight, ground, hardware, software, testing, operations), Reference (3) found that trade studies were often omitted or performed superficially. 4. Good software architecture is the most important defense against incidental complexity in software designs, but good architecting skills are not co

    17、mmon. 5. A decision is often made not to implement a FSW function, or not to fix a FSW defect, principally because an operational workaround is feasible. This practice transfers complexity from FSW to mission operations where it is a continuing cost rather than a one-time cost and where it increases

    18、 the risk of an operational error. 6. Fault management (aka fault protection) software is among the most difficult FSW to specify, design, and test. Other fault management problems (Reference (5) include inconsistent fault management terminology used by NASA centers and their contractors, mismatches

    19、 between mission requirements and the fault management approach, and lack of attention to fault management in university curricula. 7. Commercial off-the-shelf (COTS) software can provide valuable functionality, but it often comes with unneeded features that interact with other features and complica

    20、te testing. 8. Because software development can generate at least 1 defect per 10,000 LOC, FSW with 1 million LOC will have 100 defects, some of which will likely manifest during mission operations. Mature software may contain latent defects that may manifest in new applications. Recommendation(s):

    21、1. Furnish appropriate educational materials, such as a “complexity primer,“ and submit lessons learned on FSW complexity to the NASA Lesson Learned Information System (LLIS). 2. Where well-substantiated requirements are exceedingly difficult to implement in software, software managers should proact

    22、ively inform the project of the impact. In some cases this might stimulate new discussion to relax hard-to-achieve requirements. 3. Project managers should promote the value of multi-disciplinary trade studies in reducing downstream complexity, and project engineers should raise complexity concerns

    23、as they become apparent. 4. Allocate a larger percentage of project funds to up-front architectural analysis in order to achieve project cost savings. Increase the number and authority of software architects. Create a professional architecture review board to provide constructive early feedback to p

    24、rojects. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-5. Involve mission operators in flight/ground trade studies and in decisions to descope FSW. Quantify the costs and risks of operational workarounds before reassigning a FSW function or fix to

    25、mission operations. 6. Develop a NASA Fault Management Handbook to provide guidance in fault management requirements specification, design, and test. Schedule fault management reviews in proposals and project plans. Sponsor or facilitate the inclusion of fault management courses within university en

    26、gineering programs. 7. Analyze a candidate COTS product for the ability to separate its components and features, and weigh the cost of testing unwanted features against the cost of in-house development. 8. To cope with the inevitable defects in new or revised FSW, conduct randomized testing to avoid

    27、 bias toward specific sources of error, extend fault protection to cover software faults as well as hardware faults, and employ fault containment techniques to mitigate the likelihood that residual defects will combine to produce complex error scenarios. Evidence of Recurrence Control Effectiveness:

    28、 JPL has referenced this lesson learned as additional rationale and guidance supporting Paragraph 6.4.3 (“Engineering Practices: System Engineering“) in the Jet Propulsion Laboratory standard “Flight Project Practices, Rev. 7,“ JPL DocID 58032, September 30, 2008. In addition, JPL has referenced it

    29、supporting Paragraph 4.11 (“Flight System Design: Flight Software System Design“) in the JPL standard “Design, Verification/Validation and Operations Principles for Flight Systems (Design Principles),“ JPL Document D-17868, Rev. 3, December 11, 2006.Documents Related to Lesson: N/AMission Directorat

    30、e(s): a71 Space Operationsa71 Sciencea71 Exploration Systemsa71 Aeronautics ResearchAdditional Key Phrase(s): a71 Systems Engineering and Analysis.Engineering design and project processes and standardsa71 Systems Engineering and Analysis.Level II/III requirements definitiona71 Systems Engineering an

    31、d Analysis.Mission and systems trade studiesProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-a71 Systems Engineering and Analysis.Mission definition and planninga71 Systems Engineering and Analysis.Planning of requirements verification processesa71 En

    32、gineering Design (Phase C/D).Software Engineeringa71 Engineering Design (Phase C/D).Spacecraft and Spacecraft Instrumentsa71 Integration and Testinga71 Mission Operations and Ground Support Systems.Mission control Planninga71 Mission Operations and Ground Support Systems.Mission operations systemsa7

    33、1 Safety and Mission Assurance.Early requirements and standards definitiona71 Safety and Mission Assurance.Review systems and boardsa71 Additional Categories.Flight Operationsa71 Additional Categories.Payloadsa71 Additional Categories.Risk Management/Assessmenta71 Additional Categories.Softwarea71 Additional Categories.Test & VerificationAdditional Info: a71 Project: variousApproval Info: a71 Approval Date: 2009-06-11a71 Approval Name: mbella71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-


    注意事项

    本文(REG NASA-LLIS-2050-2009 Lessons Learned NASA Study of Flight Software Complexity.pdf)为本站会员(eventdump275)主动上传,麦多课文档分享仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文档分享(点击联系客服),我们立即给予删除!




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1 

    收起
    展开