英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料
基于模型的航天器故障管理设计
|
Corrina Gibson 加州理工学院喷气推进实验室 4800 Oak Grove Dr. Pasadena, CA 91109 626-660-5107 Corrina.L.Gibson@jpl.nasa.gov |
Michael Bonnici 加州理工学院喷气推进实验室 4800 Oak Grove Dr. Pasadena, CA 91109 626-720-3119 Michael.F.Bonnici@jpl.nasa.gov |
Jean-Francois Castet 加州理工学院喷气推进实验室 4800 Oak Grove Dr. Pasadena, CA 91109 818-354-3210 JeanFrancois.Castet@jpl.nasa.gov |
这篇文章将会讨论一种基于模型的软件系统逻辑设计和形式化验证方法，它将用于对整个项目生命周期中的故障管理。我们已经证实，在项目设计阶段中建立故障诊断系统的模型时，一些可预测的行为可以通过分析模型提前被证实。正确捕获模型中的预期行为改进了系统设计，从而更好地定义和完成了系统的实现。此外，执行模型检查会根据正确性(明确性)属性形式化验证行为模型。从故障保护逻辑化行为模型中生成与链接额外的基于模型的故障管理产品的可能性是项目采用模型驱动的设计，保留单一的原理来源的关键。当模型继承系统或者需要一个字典式的数据库，一个针对机器可读的故障管理参数的进出口标准会支持更简单的飞行软件以及基于模型的产品。根据在开发行为模型时是否有故障管理信息可用，自动生成模型的方法将会被使用以降低人为错误并且加速建模速度。
1.0 介绍
传统方法对喷气推进实验室（JPL）的故障保护系统的测试与验证（Vamp;V）的限制性在已经随着航天系统的复杂性越来越显著。2011年启动的喷气推进实验室火星科学实验室（MSL）已经装载了超过1000个监控器（可以检测症状然后标记故障的故障保护功能）。作为在JPL计划中发射过的最大的航天器，MSL要求MSL的Vamp;V小组拥有大量的人员去弥补复杂故障保护系统。基于模型的故障保护实施可以使系统级的软件保护技术成为可能并且改进Vamp;V技术、降低风险。
在此项目中，基于模型的系统工程方法通过使用可执行的、模型可检查的SysML行为模型被用来捕捉JPL （主被动土壤湿度检测卫星）SMAP航天器故障保护系统的逻辑行为。这种故障保护系统采用监控-保护设计。这种设计意味着在监控器检测到一个症状并且声明有一个错误模型，特定响应就运行以减轻错误。模型的结构及模式对整个航空器错误管理系统来说都是可升级的，允许在仿真以及通过模型的特定域验证中直行的端到端测试。这篇论文将会总结讨论以模型为中心的故障管理的优势，这项技术的特殊作用以及它怎么在航空项目的生命周期与其他以基于模型的产品链接。
在建立一个航空器故障诊断系统的完整模型的时候遇到的挑战之一就是需要捕捉到的在本地以及系统层次上响应的数量。这项挑战可以通过模型创建过程的自动计数来实现。然而，在SAMP案例中，响应的规范以一个免费的文本形式被写出来，这就要求模型中引入人工介入以及自动排除。一个关键任务就是将这个文本翻译成可以被脚本明确解释的形式。这篇论文描述了为了捕捉到故障保护响应规范而定义的精细标准化的机器可读的语法。此外，一个可以从机器可读的相应规范中自动生成SysML行为图的工具也被开发了出来。反过来，这个方法也允许直接在模型里定义故障保护响应的规范，然后输出他们的文件或者将它们与其他产品链接在一块。通过已存在的设计或字典库创建SysML模型的方法以及创建SysML模型前端的方法都有狠多好处。我们已经证实当一个高继承的任务被设计出来时，建模工作就可以通过导入之前的任务设计的数据自动开始并且自动生成图形。对于新的技术任务设计，SysML图可以被人工创建来展示设计，并且模型里面的数据可以被导入进文件与库中。
本文的核心工作是通过仿真验证模型是否正确地反映了故障保护行为，并通过形式化检验对模型进行了验证。一个关键且具有挑战性的步骤是定义应该满足的断言，以便考虑验证的模型。本文将会讨论这些基于模型的Vamp;V方法与特定域逻辑化属性的产生。
2.0 项目全生命周期中的基于模型工具的整合
基于模型的故障管理方法的优势
这部分将讨论使用模型进行故障管理的优势以及基于模型的Vamp;V工具是怎么与飞行项目全生命周期整合在一起的。
在JPL的故障保护的专家已经了解到，将故障保护问题与系统硬件和软件设计相结合的模型能够使正式的关系成为“提高飞行系统故障保护的实施效率、正确性和验证的巨大潜力”。对建立Vamp;V模型功能的SMAP故障保护系统可交付性包括在设计、测试以及系统逻辑验证中的可执行故障保护行为模型，以及形式化验证的模型转换和检查工具。
基于模型的系统工程（MBSE）允许V＆V在项目生命周期的早期阶段进行，因为在项目子系统传统上交付之前，可以根据需求分析和验证初始模型生成的产品。 此外，经过验证的软件模型可以引导或直接转换到飞行软件的早期阶段。MBSE本身提供了一种配置管理架构，项目的模型数据库是唯一的事实来源。 所有链接到模型并从模型自动生成的基于Web的文档都保证包含来自单一事实来源的最新信息。
SysML提供了一种标准语言，可减少不同的工程组和级别之间可能存在的模糊度，从而改善协作、提高了质量和提高了效率。生成行为图/视图以捕获模型中的信息，以便人类更容易清楚地看到系统设计。系统设计和对系统设计的更改的重要细节可以以有组织的方式可视化，使人们能够理解系统结构和行为的复杂性、体系结构和设计选项以及不同设计如何修改项目风险、成本、调度等。故障保护系统的设计需要自上而下和自下而上的分析，以确保在所有任务阶段为每个故障场景提供所需的故障保护功能。当对系统功能和状态进行建模并将其内在映射到建模的故障集和故障场景时，这种确定必要的故障保护功能的工作变得更容易，更不容易出现漏洞。下图显示了航天器故障保护范围内的关键关系，这些关系可以在系统模型中正式表示，以获得这些好处。
图1 ：故障保护系统链路
在测试故障保护软件的逻辑时，代表系统逻辑设计的可执行状态图可用于执行多故障注入(端到端)测试、系统响应测试、安全模式输入和退出测试等。使用SysML作为一套协同状态机（扩展的有限状态机）设计故障保护逻辑，将会使得Vamp;更加高效与形式化。类似于MagicDraw的SysML工具提供状态机执行插件来验证模型中行为描述的正确性。显式状态模型检查器搜索SysML状态图的转换表示，以根据逻辑属性形式化验证模型。
传统产品与模型产品的比较
在项目的故障管理程序的早期阶段，故障保护的规则、结构以及概念设计就被开发出来。定义要求和故障空间，以指定关键任务方案和需要的故障管理行为，以便进行分析和交易。初始故障树和事件树（传统上）是由手工创建的故障覆盖矩阵是开发的。将容错策略和任务风险分类相结合，得到故障管理策略，提出了故障管理原则、冗余/交叉约束方法和故障包容区域。
在生命周期的后期阶段，故障空间进一步定义为：需求、故障管理体系结构和设计、故障覆盖矩阵、故障模式影响和关键性分析（FMECA-描述定义的故障模式、症状和任务关键度的文件）和故障树分析。FMECA和故障树分析依赖于系统框图来获取故障信息。此外，还使用功能需求、概念设计和系统设备列表来完成FMECA。有效性分析由故障覆盖、概念设计、故障管理设计文档、故障管理系统、任务场景、需求和故障控制区组成。一个监视器和响应字典成形了，它保存了哪些条件应该触发监视器以及哪些响应应该运行以缓解故障的信息。最后，还从FMECA中形成缓解矩阵，该缓解矩阵展示了检测到响应映射的失败模式。
大多数故障保护产品传统上都是在单独的电子表格和文档中捕获的。这种方法导致了系统设计的附加基线，在描述行为方面受到限制，并且缺乏对从故障模式到减轻故障响应的所有关系的支持。此外，传统的基于文档的系统工程在设计中容易出现漏洞和不一致之处，因为多个文档的开发过程中从一个层次到另一个层次都有重叠的信息。
理想情况下，系统和故障管理概念和产品从头到尾都是联系在一起的-这就是MBSE的优势所在。通过集成的系统模型，可以生成等效的产品和分析，而无需重复输入不同格式和多个文档或电子表格的信息。在基于模型的工作中，系统架构和设计从正式的SysML语义开始就被捕获，这些语义定义了系统层次结构、关系、通信路径和特定领域的行为。当创建一个系统模型时，分析就变得成本更低了，该模型与工具接口以自动生成报告、执行模型和验证模型。以下模型的类型是可作为集成航天器系统模型的一部分生成的产品的示例：1. SysML序列和活动图已成功地用于描述和执行任务场景；2. 基于状态的故障和事件树模型是从任务场景生成的，并链接到故障保护逻辑行为状态图；3. 在逻辑行为模型中直接使用在建模的FMECA中定义的每个故障模式和症状状态；4. 使用冗余/交叉带信息将故障遏制区域添加到航天器(系统)框图中。
3.0基于模型的SMAP故障保护系统
在较高级别上，SMAP故障保护系统体系结构包含错误监视器、本地响应和故障保护引擎。错误监测器分散在航天器周围，以检测故障症状。故障保护引擎将错误监视器映射到基于系统模式的响应，根据优先级对响应进行排队，通过一组激活规则运行每个响应，最后依次运行每个响应。
图2：SMAP 故障保护系统架构
对于SMAP故障保护逻辑行为模型，FMECA提供了状态图中捕获的故障模式和症状。由于模型只表示软件状态，所以没有对物理阈值(即行程监视器)进行建模。当然，故障模型以及它们的特征（本地特征优先于系统特征）被作为其他自动故障保护行为模型的最初状态被插入到模型中。SMAP缓解矩阵提供应发生的状态更改，以保护航天器不受主动故障模式的影响。该信息在模型中被转换为从故障模型到模型的名义操作的转换。
图3：故障模型/症状状态图
SMAP的缓解矩阵也为故障模型提供了故障检测器映射。故障检测器基于注入故障模式的介入，并执行递增功能以确保故障在变为“红色”(即命令本地和系统响应运行)之前是持久的(没有假警报)。另外被提供了的SMAP字典管理系统（DMS – 一种提供故障保护设计信息和飞行软件参数的在线词典）是事件报告、命令名、系统响应定义和错误监视器到响应映射，这些映射被转换为故障保护引擎状态中的区域和子状态。为了完成故障保护引擎的逻辑行为模型，将SMAP功能设计描述文档中的信息转换为定时和等待状态、激活规则、重置和重新启动状态以及响应队列逻辑。
为逻辑行为模型中表示的所有函数开发的模式共享以下基本状态图特性：初始状态、超级状态、复合状态、子状态、并行区域、事件、信号、入口动作、保护(条件)和转换。这些特征也与W3C状态图XML（SCXML）可执行环境相符，并且能够被自动转化为Java代码以供Java寻迹器进行模型检查。第6部分会介绍故障保护模型图如何被用来进行SMAP建模。
SMAP故障保护系统的行为模式呈现表明一致和可执行的状态图模式助力了在JPL中开发的大型航天器系统的发展。 当将SMAP文档和基于电子表格的故障保护设计转换为正
全文共14699字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[2755]
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
