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

    REG NASA-LLIS-1743--2006 Lessons Learned Mitigating the Risk of Single String Spacecraft Architecture.pdf

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

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

    REG NASA-LLIS-1743--2006 Lessons Learned Mitigating the Risk of Single String Spacecraft Architecture.pdf

    1、Lessons Learned Entry: 1743Lesson Info:a71 Lesson Number: 1743a71 Lesson Date: 2006-04-7a71 Submitting Organization: JPLa71 Submitted by: David Oberhettingera71 POC Name: Jeffrey Nunesa71 POC Email: jeffery.nunesjpl.nasa.gova71 POC Phone: 818-354-8367Subject: Mitigating the Risk of Single String Spa

    2、cecraft Architecture Abstract: Mars Exploration Rover met and exceeded mission requirements despite a largely single string spacecraft architecture. Balance the risk of a single string flight system with effective risk management, ample fault tolerance, flight system flexibility, access to experienc

    3、ed designers, ample stress testing, use of proven designs, and a rigorous approach to fault protection.Description of Driving Event: The Mars Exploration Rover (MER) project was extremely successful despite the largely single string flight system, which included such single string elements as the fl

    4、ight computer and the panoramic camera (Pancam). The lack of backups for many mission-critical system functions was largely due to spacecraft mass limitations. Constrained project resources were also responsible for other design tradeoffs (Reference 1) that increased the risk to mission success. The

    5、 following 7 design features or program provisions (Reference 2) mitigated the risks posed by MERs design constraints: 1. Effective Risk Management. The MER risk management approach involved the identification of risks and failure modes at project inception and their continuous modeling throughout d

    6、evelopment. For example: a72 MER probabilistic risk assessment (PRA) included development of high level fault trees for the entry, descent, and landing (EDL) event that were completed for the Project Mission, System Design, and Cost Review (PMSDCR). Subsequent Provided by IHSNot for ResaleNo reprodu

    7、ction or networking permitted without license from IHS-,-,-preparation and refinement of event trees and lower level fault trees were performed, not to pass reviews, but rather to understand system vulnerabilities and threats to EDL success. Significant failure modes were checked against contingency

    8、 plans and reported at mission readiness reviews. The Mars Polar Lander (MPL) 1999 mission failure encouraged MER project management to impose a healthy skepticism towards success. The project continuously demanded proof that the system would work, rather than assuming that risks were acceptable unl

    9、ess shown to the contrary. 2. Ample Fault Tolerance. The MER design featured extensive fault tolerance to allow full or degraded operation in the presence of a fault. Examples of this approach include: a72 The MER design did not include a backup flight computer, but multiple EPROMs provided redundan

    10、t copies of the boot code and of the flight software. a72 The MER flight system design was tolerant to nearly all transient errors (e.g., power-on-resets) during EDL or on the Martian surface. a72 The Heat Rejection System, which provided active cooling during the Cruise phase, featured a single coo

    11、lant filter that could become clogged. However, a check valve permitted the coolant to bypass the filter if the coolant pressure reached a threshold value. a72 The Pancam cameras were effectively single string as both needed to be operational to permit stereoscopic imaging, and both the failure mode

    12、s, effects and criticality analysis (FMECA) and the PRA identified failure of a camera as a major risk to rover mobility. JPL planned for a degraded operational mode that could acquire an image from a single working camera, shift the rover several centimeters, take a second picture with the camera,

    13、and use ground software to combine the two images into a stereo image. a72 A software commanding error could power a warm-up heater during the Mars daytime when it was not normally powered, and cause overheating. Hence, thermostats were added for fault mitigation. 3. Flight System Flexibility. MER f

    14、eatured a very flexible design that, though it resulted in a very complex vehicle, permitted flaws to be corrected after launch: a72 The MER PRA identified EDL as the most risky mission phase. Arguably, this held true for the Genesis and Stardust missions, which hard wired the EDL sequences such tha

    15、t they could not be changed after launch. In contrast, MER retained an ability to update critical EDL parameters during the latter stages of encounter and EDL. (See Reference (3).) This included both a flight system capability to uplink software updates during entry, and the operational plan, proces

    16、s, and tools for ground personnel to prepare the updates. a72 Rover egress from the lander required the removal of various launch locks by firing pyrotechnic cable cutters and pin pullers in a predetermined sequential order. The firing of the pyro to permit deployment of the rover robotic arm had be

    17、en timed to mitigate the risk that the arm might encounter higher than expected dynamic forces during egress. After launch, extensive analysis of the sequence revealed a yet greater risk that another, earlier, pyro firing to cut the final rover-lander cable could enable a sneak circuit that could be

    18、 triggered by any subsequent pyro events. (see Reference Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-(4). So a decision was made to reorder the deployment sequence to release the rover arm before the final rover-lander cable cut to prevent activa

    19、ting any sneak circuits set up by the rover-lander cable cutter. 4. Experienced Personnel. The lead engineers in each area had an unusually high level of experience, and were in many cases drawn from other current flight projects. These individuals were well acquainted with the MER mission failure s

    20、pace, and recent JPL mission failures had negated any complacency about mission risks. The JPL line/project matrix organization facilitates such project access to key personnel. With JPLs reputation at stake, the MER project made sure that each critical failure mode was fully understood and the risk

    21、 mitigated before the risk item was retired. (See Reference (5).) 5. Ample Stress Testing. Significant resources were devoted to testing flight system robustness. MER utilized multiple flight system testbeds that were very flight-like. Compared to a project like Stardust that had only pieces of cert

    22、ain subsystems, the MER testbeds were hardware-rich and were not as dependent on simulators. (See Reference (6).) Long after launch, the project continued to perform system-level stress testing to identify system performance margins. Just prior to EDL, for example, a decision was made to enable all

    23、pyros. This posed a risk of premature pyro firing, but the additional test data indicated a higher risk that the safeties might inhibit a pyro during the firing sequence. 6. Mars Program Synergy. Despite the short MER development schedule, the MER project was able to take advantage of the avionics c

    24、oncept and rover designs developed for the 1999 version of the Mars Sample Return project architecture. 7. In-House Project. Because the MER flight system was largely an in-house development, the designers and testers understood how the subsystems worked. Although some items like the radar altimeter

    25、 and solar arrays were procured, JPLs lesser dependence on major subsystems provided by other organizations or countries permitted the same rigorous approach to fault protection to be employed at all hardware levels. References: 1. Rob Manning, “MER Project: Stealing Success from the Jaws of Failure

    26、, Video Presentation AVC-2005-200,“ September 23, 2005. 2. David Oberhettinger, “Mitigation of Risks Associated with MER Single String Architecture,“ OCE DJO 05-001, November 28, 2005. 3. “Provide In-flight Capability to Modify Mission Plans During All Operations, NEN No.1480,“ NASA Engineering Netw

    27、ork (NEN), June 21, 2004. 4. “Plasma Arcs from Pyro Firing May Cause Prolonged NSI Shorts,“ NEN No.1412, NASA Engineering Network (NEN), April 19, 2004. 5. “If You Dont Understand an Environment, Provide Well-Margined Capabilities to Encompass the Worst Case,“ NEN No. 1712, NASA Engineering Network

    28、(NEN), December 16, 2005. 6. “The Risk Reduction From Two-fers (Multiple Sister Spacecraft) May Outweigh the Incremental Cost,“ NEN No.1485, NASA Engineering Network (NEN), May 17, 2004. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Lesson(s) Learn

    29、ed: A system architecture that is highly dependent on single string subsystems can succeed by focusing project resources on intensive analysis of known failure modes and on ample testing.Recommendation(s): Balance the risks of single string spacecraft architectures with effective risk management, am

    30、ple fault tolerance, flight system flexibility, access to experienced designers, ample stress testing, use of proven designs, and a rigorous approach to fault protection.Evidence of Recurrence Control Effectiveness: JPL opened Preventive Action Notice (PAN) No. 1474 on July 18, 2006 to initiate and

    31、document appropriate Laboratory-wide action on the above recommendations.Documents Related to Lesson: N/AMission Directorate(s): a71 Space Operationsa71 Sciencea71 Exploration Systemsa71 Aeronautics ResearchAdditional Key Phrase(s): a71 Program Management.a71 Program Management.Acquisition / procure

    32、ment strategy and planninga71 Program Management.Contractor relationshipsa71 Program Management.Program planning, development, and managementa71 Program Management.Risk managementa71 Missions and Systems Requirements Definition.a71 Missions and Systems Requirements Definition.Level 0/1 Requirementsa

    33、71 Missions and Systems Requirements Definition.Planetary entry and landing conceptsa71 Missions and Systems Requirements Definition.Requirements critical to costing and cost credibilitya71 Systems Engineering and Analysis.a71 Systems Engineering and Analysis.Mission and systems trade studiesProvide

    34、d by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-a71 Systems Engineering and Analysis.Mission definition and planninga71 Engineering Design (Phase C/D).a71 Engineering Design (Phase C/D).Lander Systemsa71 Engineering Design (Phase C/D).Roboticsa71 Engineerin

    35、g Design (Phase C/D).Spacecraft and Spacecraft Instrumentsa71 Safety and Mission Assurance.a71 Safety and Mission Assurance.Early requirements and standards definitiona71 Safety and Mission Assurance.Reliabilitya71 Additional Categories.a71 Additional Categories.Environmenta71 Additional Categories.

    36、Flight Equipmenta71 Additional Categories.Flight Operationsa71 Additional Categories.Hardwarea71 Additional Categories.Payloadsa71 Additional Categories.Risk Management/Assessmenta71 Additional Categories.Softwarea71 Additional Categories.Spacecrafta71 Additional Categories.Test FacilityAdditional Info: a71 Project: MERApproval Info: a71 Approval Date: 2006-12-06a71 Approval Name: ghendersona71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-


    注意事项

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




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

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

    收起
    展开