系统工程实施示例:空间系统

全球定位系统(GPS)案例研究是由位于空军理工学院(AFIT)的美国空军系统工程中心(AF CSE)开发的。GPS是一种天基无线电定位系统。包括三个备件在内的24颗卫星组成了整个系统，向全世界的军事和民用用户提供导航和授时信息。GPS卫星在地球六轨道中的一轨道上，每12小时绕地球一周，以两个不同的l波段频率连续发射导航信号。该系统由另外两个主要部分组成:全球卫星控制网络和GPS用户设备，GPS用户设备既可以由人类用户携带，也可以集成到船舶、车辆或飞机等主机平台上。

本案例研究讨论基于原始源代码(O 'Brien and Griffin, 2007)，它为我们可能考虑的“传统”SE应用程序提供了有用的见解。第二个全球定位案例研究从系统中的系统工程(sos)和企业系统工程(ese)的角度来看同一个案例研究。

领域背景

在查看全球定位系统 (GPS) 时，很难想象还有另一个系统如此严重地依赖于如此广泛的领域，万维网 (WWW) 可能是个例外。此外，在这些领域内运行的各种系统必须完美地协同工作才能取得成功。从阅读本案例研究可以明显看出，它与以下领域直接相关：

航天;
空间;
通讯；
运输。

这也是系统系统 (SoS) 的一个示例，被认为是一项创新技术。

GPS 案例研究包括对 GPS 及其组件的开发以及其他适用领域的详细讨论。在获得成功所需的系统工程支持的背景下，本研究的读者将更深入地了解 GPS 对军事和商业行业的影响。

案例研究背景

美国空军系统工程中心 (AF CSE) 于 2002 年在空军技术学院 (AFIT) 成立，其任务是开发案例研究，重点关注系统工程原理在各种航空航天项目中的应用。 GPS 案例研究（O'Brien 和 Griffin 2007）由 AFIT 开发，以支持系统工程研究生院的教学。这些案例使用 Friedman-Sage 框架（Friedman and Sage 2003；Friedman and Sage 2004, 84-96）构建，该框架将案例分解为承包商、政府和以下九个概念领域的共同责任：

需求定义和管理
系统架构开发
系统/子系统设计
验证/确认
风险管理
系统集成和接口
生命周期支持
部署和部署后
系统和程序管理

案例研究的附录 A 中提供了 Friedman-Sage 框架 (2004)。这个案例研究是政府——特别是 JPO 系统工程局——承担系统集成和配置管理责任的一个例子。也就是说，政府在 GPS 系统的系统工程中发挥的不仅仅是监督作用。如案例研究中所述，JPO 开发了 CONOP、任务分析、需求和设计分析，包括安全性，并开发了自己的密码学方法。 JPO 协调由项目主任主持的配置控制委员会 (CCB)。 JPO 还负责 ICD 和系统设计配置；承包商负责其部门内的系统架构和 ICD。

案例研究说明

“全球定位系统 - 系统工程案例研究”描述了系统工程在 GPS 程序的概念验证、系统设计和开发以及生产阶段的应用（O'Brien 和 Griffin 2007）。该案例检查了应用系统工程过程，以及 GPS 联合项目办公室 (JPO)、主要承包商以及与项目开发和部署相关的众多政府机构之间的相互作用。系统工程过程从开始研究和开发关键技术（在 1960 年代确立了卫星导航系统的愿景）到多阶段联合计划（导致 1995 年全面运行能力发布）都可追溯。

GPS 案例研究得出了四个学习原则 (LP)，这些原则解释了案例研究所涉及的系统工程知识的更广泛适用领域。这四个 LP 在以下领域与 SEBoK 密切相关：

个人能力（LP1）；
配置管理（LP2）；
使组织成为可能（LP3）；
风险管理（LP4）。

此外，GPS 案例研究包含对生命周期管理的全面概述，并举例说明了系统思考原则。

个人能力

学习原则 1 ：项目必须努力为关键职位配备领域专家。

从项目管理团队到系统工程、设计、制造和运营团队，项目中的每个人都精通各自的学科，并且都拥有项目的系统视图。虽然沟通、工作关系和组织很重要，但整个团队在各个级别上理解他们的工作对系统的影响的能力至关重要。他们基于知识的决策方法具有缩短决策周期的效果，因为信息被理解并且基础和替代解决方案被准确地呈现。

配置管理

学习原则 2 ：系统集成商必须严格维护程序基线。

联合项目办公室 (JPO) 保留了管理和控制系统规范的角色，因此保留了功能基线。 JPO 推导出并构建了一套相互同意的系统要求，这些要求在 1973 年成为项目基线。在执行开发项目时，GPS 团队能够根据功能基线进行性能、风险、成本和贸易分析，以控制风险和成本。 JPO 完全认识到功能要求对分配的基线的影响，因为他们管理了接口控制工作组流程。管理该流程为他们提供了第一手知识和对最低级别风险的洞察力。具有系统集成者角色的个人必须严格维护系统规范和功能基线。

赋能组织

学习原则 3 ：获得一致和持续的高层支持和宣传有助于资金稳定性，这会影响系统工程的稳定性。

一致、持续的高层支持提供了需求并有助于资金稳定性。在这个角色中，国防部长办公室 (OSD) 在项目的关键时刻提供宣传和资金来源，促进各部门之间的协调，并审查和批准 GPS JPO 系统要求。 OSD 在程序的建立和生存能力方面发挥了核心作用。 GPS JPO 得到了国防发展、研究和工程总监 Malcolm Currie 博士的明确支持，以及国防部副部长 David Packard 博士的项目支持。显然，军队——尤其是早期的海军和空军，以及后来的陆军——是 GPS 的主要用户和最终用户。然而，每个武装部队对其各自的项目或当时的运行导航系统都有最初的需求。此外，空军部长还为供应人力和设施提供了计划支持。

风险管理

学习原则 4 ：必须在整个生命周期中应用有纪律和适当的风险管理。

GPS 计划的结构是为了在整个多阶段计划中以几种不同的方式解决风险。在预先知道关键风险的情况下，承包商和/或政府使用经典的风险管理方法来识别和分析风险，以及制定和跟踪缓解措施。这些设计（或制造/发布）风险由拥有风险的办公室管理。确定的技术风险通常通过技术性能指标（如卫星重量和软件代码行）进行跟踪，并在每周的总工程师会议上得到解决。

担任项目集成商的明确角色使 JPO 能够赞助最高级别的风险贸易研究。日本特许厅将向若干投标人发出研究提案，以开发概念和/或初步设计。然后，一个承包商将被淘汰，该过程将继续进行。这种方法通过竞争提供了创新的解决方案，并有助于为用于开发和生产的固定价格合同方法定义风险更低、定义更明确的开发计划。

作为系统集成商，日本特许厅也密切参与了技术开发。为了确定不可预见的独特技术挑战，日本特许厅将资助研究以确定解决新问题的最佳方法。由于与航天器和控制部分（软件开发）有关的不可预见的 Block II 问题，与第一次发射相关的进度风险。尽管这是一场灾难性事件，但挑战者号事故实际上提供了急需的时间表缓解。使用决策分析方法使 JPO 采用了另一种方法来开发 Block II 卫星的消耗性运载火箭。

由合作工作关系促进的良好沟通是 GPS 计划成功的一个显着积极（尽管无形）因素，无论它是在承包商和政府（JPO 或其他机构）之间，还是在承包商和分包商之间。承包商。真正的团队环境在降低风险方面也发挥了重要作用，尤其是考虑到参与这项工作的政府机构和承包商过多。

生命周期管理

GPS 案例研究带领读者了解 GPS 的最初概念（1942 年 3 月），一直到系统的开发、生产和运行能力。当前的 GPS 计划可以追溯到 1960 年代初期，当时空军系统司令部启动了由航空航天公司进行的基于卫星的导航系统分析。案例研究从构思开始到 1995 年 4 月 27 日全面发布 GPS 计划执行。案例研究的集中度不限于任何特定时期，学习原理来自不同时期在程序的整个生命周期中。

系统思维

GPS 案例研究强调了整个系统思考的必要性。 GPS 卫星位于六个地球轨道之一，每十二小时绕地球一圈。这些卫星在两个不同的 L 波段频率上发射连续的导航信号。该系统由另外两个主要部分组成：全球卫星控制网络和 GPS 用户设备，这些设备既可以由人类用户携带，也可以集成到船舶、车辆或飞机等主机平台中。构思、开发、生产、部署和维持 GPS 的能力需要最高水平的系统思维。

概括

GPS 案例研究对于全球系统工程学习很有用，并提供了系统工程生命周期的全面视角。该研究适用于以下领域的详细指导：

赋能个人；
配置管理；
使组织能够；
风险管理；
生命周期管理；
系统思维。

GPS 案例研究表明，国防部的关键人员对这种前所未有的天基导航能力保持着清晰和一致的愿景。案例研究还表明，日本特许厅很幸运，因为有些独立但至关重要的太空技术及时成熟。

尽管 GPS 计划需要在系统内部和系统外部进行大量集成，但在众多机构和承包商之间，还是采取了必要的努力以取得成功。

最后，GPS 案例研究的读者将在获得成功所需的系统工程支持的背景下，进一步了解 GPS 对军事和商业行业的影响。该系统最初旨在帮助“在一个孔中投下五枚炸弹”，这定义了上下文特定术语中的准确性要求。 GPS 信号需要保持一致、可重复和精确到一定程度，当弹药制导系统使用时，可以将多个单独制导的弹药成功交付到地球上任何时间任何地点的几乎相同位置。 40 到 50 年前，军方以外很少有人认识到所提出的准确性的价值，而且 GPS 的大多数非军事用途在 1990 年之前都没有得到认可。

全球定位系统II

这篇文章强调了所谓的经典、传统或传统系统工程(SE)方法与较新的、迄今尚未定义的系统中的系统(SoS)工程(SoSE)、企业系统工程(ESE)和/或复杂系统工程(CSE)或复杂自适应系统工程(Gorod et al. 2015)的原则之间的一些差异。这个话题仍然有一些争议，特别是考虑到有人怀疑，当一个人沉浸在试图应对我们最困难的问题时，更广泛的SE观点可能会更好。事实上，缺乏统一的SE理论是产生和分析案例研究的主要动机之一，以开发更多的知识，了解什么可行，什么不可行，以及真正挑战SE环境的原因。

关于附加信息，请参考系统工程:历史和未来的挑战，系统工程和其他学科，企业系统工程，以及系统中的系统工程。

本文没有修改SEBoK中先前关于全球定位系统案例研究的讨论，而是通过评论来自原始案例研究源文件(O 'Brien and Griffin, 2007)的引文，将重点放在比较和对比SE的新旧形式上。

前言

最初的案例研究从描述系统工程(SE)原则开始。例如,

系统需求对成功的系统程序开发的所有方面都至关重要。首先，系统开发必须从一组良好开发的需求出发。第二，不管进化获取方法如何，系统需求必须向下流到所有子系统和较低层次的组件。第三，系统需求必须是稳定的、平衡的，并且必须适当地反映所有预期环境中的所有活动。然而，系统需求不是一成不变的。随着系统设计的进行，如果一项或一组需求被证明满足起来过于昂贵，那么过程必须通过更改或修改需求或一组需求来重新平衡进度、成本和性能。(O 'Brien and Griffin, 2007，第9页)

全球定位系统(GPS)，包括其多种应用，是许多贡献者多年来努力的结果。很难相信上述段落中描述的经典的、传统的或传统的系统工程方法(尤其是作者用粗体字强调的那些短语)是这一深刻影响我们生活的显著成就的真正原因。更确切地说，系统工程(SE)的一些更高级的形式，可能被称为系统的系统工程(SoS)工程(SoSE)，企业系统工程(ESE)，或复杂(自适应)系统工程(CSE)，或这些方法或方法的混合和/或组合，必须负责。在下面使用粗体的案例研究修订中，这个前提得到了明确和反复的支持。

继续，下面引用的段落在以粗体突出显示的几个地方似乎有缺陷。粗体短语可以用括号中的短语[…]代替。这种括号也可以包括目前作者的其他编辑意见。

系统工程包括在建立系统架构的过程的早期进行关键的系统和设计交易。“这些体系结构工件”[该体系结构]可以描述任何新的系统、遗留系统、对其的修改、新技术的引入，以及整个系统级的行为和性能。在此阶段，建模和仿真通常用于组织和评估体系结构系统的备选方案。系统和子系统设计遵循功能[系统]体系结构[从功能角度定义的]。如果元素太冒险、太昂贵或太耗时，系统架构设计就会被修改。(O 'Brien and Griffin, 2007，第9页)

一个良好的体系结构一旦建立，就应该指导系统开发，并且不会有太多的变化，如果有的话，至少与系统设计中可能发生的变化相比，当然，随着人们对问题和可能增加系统能力的潜在解决方案的更多了解，这些变化可以不断发展。因此，不将架构与实例化架构的设计混淆是至关重要的，这与(Ricci, et al. 2013)中的情况相反。

对于功能和物理架构设计的有效分解和创建来说，接口的管理和子系统的集成非常重要。接口管理和集成应用于系统内的子系统或跨大型复杂系统的子系统。一旦规划、分析、设计和构建了解决方案，就会进行验证和验证，以确保满足需求。测试标准的定义、有效性度量(MOEs)和性能度量(MOPs)作为需求过程的一部分被建立，在任何组件/子系统装配设计和构造发生之前很久就开始了。(O 'Brien and Griffin, 2007，第10页)

在上面引用的段落中，粗体字强调了还原论方法，还原论，其中非常重视子系统并管理它们之间的接口。这与专注于整个系统的整体方法相反，它认识到很难将整体系统行为识别为取决于任何特定子系统或子系统集。在一个真正复杂的不断进化的系统中，上述需求过程是有缺陷的，因为系统是不断变化的，即系统是进化的；需求要么在一开始就定义不明确，要么因为利益相关者而被修改改变他们的想法，或者因为系统环境的变化而变得有些无关紧要。

文献中介绍了[通常的传统或传统]系统工程过程的几种出色表现。这些描述展示了系统工程过程的成熟度和评估的当前状态。您可以从国际系统工程委员会 (INCOSE)、欧洲工业协会 (EIA)、电气和电子工程师协会 (IEEE) 以及国防部 (DoD) 的各个机构和组织。他们展示了应该应用的过程[真的吗？在所有情况下？] 由今天有经验的从业者。国防采办大学 (DAU) 长期使用的其中一个流程不是一次性完成的[模型]。这种迭代和嵌套的过程被重复到设计及其接口的最低定义级别。（奥布莱恩和格里芬 2007 年，第 10 页）

上面的描述似乎是自豪地编写的，但没有承认如果根据这些指南应用这种 SE 方法可能无法工作，或者可能有新的 SE 技术在某些情况下可能更有效。同样，这反映了一种简化方法，它忽略了整体论和紧急属性，即使彻底理解了系统组件及其相互作用，也可能无法解释这些属性。从积极的方面来看，下一段暗示了世界正在如何变化，并暗示需要更多的东西。尽管如此，该建议似乎更倾向于更积极地应用现有的 SE 学科，而不是寻求可能更有效的新方法。

与所有其他模型一样，DAU 模型在过去的二十年中得到了记录，并且已经扩展和发展以反映不断变化的环境。系统在内部变得越来越复杂，在外部变得越来越相互关联。过去用于开发飞机和系统的过程在当时是有效的。它满足了从业者的需求，并在我们的库存中产生了许多成功的系统。尽管如此，过去项目的成本和进度绩效充满了管理良好的项目和执行不那么出色的项目的例子。随着美国进入 1980 年代和 1990 年代，大型国防部和商业采购经历了成本超支和进度延误。航空航天工业及其组织变得越来越大，并且在地理和文化上更加分散。大型航空航天公司一直在努力建立跨企业的通用系统工程实践。然而，由于大型（和一些小型）项目的大趋势，这些常见的做法必须在企业之外和多个公司中得到理解和使用。系统工程过程必须管理集成、平衡、分配和验证，并且对整个程序团队有用，直至设计和接口级别。（奥布莱恩和格里芬 2007 年，第 11 页）系统工程过程必须管理集成、平衡、分配和验证，并且对整个程序团队有用，直至设计和接口级别。（奥布莱恩和格里芬 2007 年，第 11 页）系统工程过程必须管理集成、平衡、分配和验证，并且对整个程序团队有用，直至设计和接口级别。（奥布莱恩和格里芬 2007 年，第 11 页）

最后，在下一段中，有人建议 SE 可以变得更加复杂，但没有提到解决人的问题或提倡更广泛的跨学科方法。

今天，许多因素掩盖了新的收购；包括系统系统 (SoS) 环境、网络中心战和作战以及信息技术的快速发展。这些因素正在推动更复杂的系统工程过程，具有更复杂和更强大的功能，以及新的工具和程序。系统工程过程日益关注的一个领域是系统分析期间使用的信息系统架构定义。这一过程在 DoD 架构框架 (DoDAF) 中进行了描述，强调更多地依赖于描述系统上下文和操作概念、互操作性、信息和数据流以及面向网络服务的特征的可重用架构视图。（奥布莱恩和格里芬 2007 年，第 11 页）

原始案例研究的系统工程原理部分的最后两部分涉及案例研究本身，主要用于学术目的，以帮助人们了解系统工程原理，以及案例研究中使用的框架，即相当狭义的 Friedman-Sage下文第二节将简要讨论的框架。

案例研究原因的处理非常好，因为它谈到了应用系统工程原理的好处，正如现实世界中的例子所强调的那样，哪些有效，哪些无效。除了在接近尾声的地方暗示了新的努力系统工程原则的可能性，所支持的原则往往是传统的或传统的。

另一方面，根据最初的案例研究（O'Brien 和 Griffin 2007），如果认为 GPS 系统的边界主要包括与 GPS 空间段及其控制地面网络相关的技术，那么它可以是假设系统可能主要通过遵循传统或传统的系统工程过程来实现。如果有人采取这种观点，那么上述所有试图指出传统系统工程的一些缺点的批评充其量可能看起来是空洞的，或者最坏的情况是政治不正确。很可能许多人宁愿不通过将原始 GPS 案例研究暴露于更广泛的系统工程方法的可能性来诋毁它。

除非另有说明，正如本文作者所做的那样，现有 SEBoK 中未更改的引文在下面缩进。对此类引文的修改显示在括号 [...] 中；删除不一定明确显示。

背景

全球定位系统 (GPS) 案例研究由位于空军技术学院 (AFIT) 的美国空军系统工程中心 (AF CSE) 开发。 GPS是一种基于空间的无线电定位系统。一个由 24 颗卫星组成的星座，包括三颗备用卫星，构成了为全球军事和民用用户提供导航和时间信息的整个系统。 GPS 卫星位于六个地球轨道之一，每十二小时绕地球一圈，在两个不同的 L 波段频率上发射连续的导航信号。该系统由另外两个主要部分组成：全球卫星控制网络，以及可以由人类用户携带或集成到船舶、车辆或飞机等主机平台中的 GPS 用户设备。

用户需要同时接收来自至少四颗 GPS 卫星的信号（卫星轨道位置和地面地形阻塞可能是降低性能的问题）以确定自己在三个维度上的位置；高度确定通常不如其他两个维度准确。

在查看 [GPS] 时，很难想象另一个系统如此严重地依赖于如此广泛的 [包含必须有效交互以实现成功 GPS 操作的系统的域]。很明显，[GPS 与许多领域和应用直接相关，包括：

位置定位和跟踪
时间同步
导航
运输
到达时间
空中交通管理
对情况的意识
抗干扰通信
商业和商业
农业
航天
从太空感知核爆炸
军事作战
定位
武器交付
ETC。]。

[GPS 是] [系统的协作 (Dahmann, et al. 2008) 系统 (SoS)] 的一个例子。因此，没有人负责，能力（不是要求）是自下而上的，而不是自上而下的。

目的

这可能是，但本修订案例研究的主要目的是提出更广泛的 GPS 视图，讨论 SoS、企业和复杂系统的特征方面，并强调 SoSE、ESE 和 CSE。

[AF CSE] 的任务是开发案例研究，重点关注 [SE] 原则在各种航空航天项目中的应用。 GPS 案例研究 [是为支持 SE 开发的] 使用 Friedman-Sage 框架 (Friedman and Sage 2003) (Friedman and Sage 2004) 的研究生教学。]

然而，Friedman-Sage 框架只涉及两个合同利益相关者，政府和承包商；此外，该框架仅限于传统或传统的 SE 生命周期，主要以线性而非非线性方式处理活动；此外，只考虑风险，而不是风险和机会的平衡。因此，目前的作者认为包含 SoSE、ESE 和 CSE 的更广泛的框架更合适。

挑战

在最初的案例研究中，第一个技术含量很高的部分（第 2 部分）是系统描述。最初的想法源于试图确定苏联于 1957 年发射的第一颗人造卫星（例如人造卫星）的精确轨道参数。约翰霍普金斯大学的研究人员意识到了相反的情况，即如果人们准确地知道轨道参数，地面的位置可以相当准确地确定接收卫星信号的电台。（O'Brien 和 Griffin 2007，第 20 页。）

GPS 始于 70 年代初（O'Brien 和 Griffin 2007，第 19 页），建立在以前的几个卫星导航系统的基础上。主要动机是用于军事应用的非常准确的位置信息。例如，美国空军希望以前所未有的准确度和精确度从轰炸机上投放核武器。（奥布莱恩和格里芬 2007 年，第 29 页）

鉴于军方如此强烈的兴趣，第一个真正的挑战，除了使 GPS 工作和设想的许多技术挑战之外，可能是如何让平民社区使用 GPS 以便他们可以分享收益的问题. 该研究声称该系统始终提供给民用，尽管有一些费用。在韩国客机误入歧途并被苏联拦截机击落后，里根总统将GPS正式免费提供给民用。（奥布莱恩和格里芬 2007 年，第 14 页）

第二个挑战可能与只为军方保留精确能力以及将航向获取 (C/A) 准确性委托给平民社区有关。（O'Brien 和 Griffin 2007，第 15 页）后来，这种二分法基本上被消除了，因为认识到涉及具有精确已知位置的固定地面站的差分 GPS 配置将产生很高的准确性。 (Kee, et al. 1991)

GPS卫星使用星载原子钟。为了减轻对这些时钟更新的过于频繁的需要，开始了一项成功的努力来修改国际时间标准，最终使用相对不频繁的“闰秒”。（O'Brien 和 Griffin 2007，第 23 页）即使这些对于许多其他应用来说仍然很烦人，例如不断需要实现跳频无线电的精确同步。

联合项目办公室（JPO）的成立克服了军种间竞争的组织挑战。（奥布莱恩和格里芬 2007 年，第 25 页。）

例如，在卫星通信系统的早期，卫星非常小且功率低，而终端却很大且功率高。当 GPS 出现时，卫星变得越来越大，越来越复杂。然后，开发相对低成本的终端，特别是针对移动用户的终端的挑战大大增加。（奥布莱恩和格里芬 2007 年，第 29 页）

一个小而有趣的挑战是系统系统 (SoS) 的定义。之所以决定 GPS 是一个 SoS，是因为它涉及三个独立的系统，即航天器 (SV)、控制段 (CS) 和用户设备 (UE)，它们“仅仅”必须相互连接。（奥布莱恩和格里芬 2007 年，第 30 页）

不断变化的需求通常是一个问题，尽管在这种情况下，需求并没有像它们可能的那样经常变化。（奥布莱恩和格里芬 2007 年，第 31 页）

GPS 项目主管布拉德·帕金森上校在很大程度上克服了定义和更新许多 GPS 接口的困难，他说服了自己的管理人员——太空与导弹系统办公室 (SAMSO)（最终成为太空部门）的舒尔茨将军GPS 应该仅由空间中的信号结构而不是物理接口来定义。（奥布莱恩和格里芬 2007 年，第 31 页）

系统工程实践

尽管之前已经讨论了第一阶段的系统工程过程，但本节将扩展这些概念。例如，其中一位用户设备承包商技术能力强，但缺乏有效管理。日本特许厅强烈建议聘请一家系统工程公司来协助承包商管理项目，他们同意了。（奥布莱恩和格里芬 2007 年，第 42 页）

似乎没有提及雇用了哪家 SE 公司（如果有的话）。航空航天公司是一家非盈利的联邦资助研究与开发中心 (FFRDC)，在 GPS 的筹备过程中发挥了如此重要的作用，它也突出和集中地参与了这个庞大项目的开发阶段。（O'Brien 和 Griffin 2007，第 20、22、25、33、34、40、41、44、48、50-52、56、57、62、63、64、66、67、71 页）

得到教训

通信是整个 GPS 开发过程中培养的关键要素。（奥布莱恩和格里芬 2007 年，第 71 页）

是的，从阅读原始案例研究来看，各个组织之间似乎有很多合作，比在一个不太引人注目的案例中预期的要多。

全球定位卫星计划的几个原则或基础是其成功的原因。这些基础对今天的项目具有指导意义，因为它们对那些总是寻求深入了解项目在审查中的进展的人来说是发人深省的。当然，过去程序的这些基础并不是一整套必要和充分条件。对于从业者而言，从概念构思到系统的使用和最终处置，在整个程序的整个过程中都需要成功应用不同的系统工程过程。应用完善的系统工程原理、实践、流程和工具的经验丰富的人员在每一步都是必不可少的。前 GPS JPO 的康利先生提供了这样的话：“系统工程是一项艰苦的工作。它需要知识渊博的人，他们对项目有远见，并注重细节。” （奥布莱恩和格里芬 2007 年，第 72 页）

在这类非常复杂的系统工程工作中，探索试图处理涉及人的“软”问题的新技术也很重要。那些看起来有效的可以添加到系统工程过程集合中。

系统工程在该计划的成功中发挥了重要作用。集成新技术、识别系统要求、整合系统方法、与过多的政府和行业机构接口以及在程序形成早期处理缺乏操作用户的挑战需要强大、高效的系统工程过程. GPS 计划将系统工程嵌入到他们的知识库、愿景和日常实践中，以确保正确识别系统要求。它还确保将这些要求分配给几乎自主的部分开发，并超出分包商/供应商级别，评估新要求，创新测试方法以验证设计性能是否符合要求，一个坚实的操作/任务分析概念，一个捍卫程序需求的成本效益分析，以及一个强大的系统集成过程来识别和控制程序遇到的接口的“九头蛇”。该计划能够通过他们的采购策略、贸易研究的使用、概念设计的早期测试、对该主题的详细了解以及该计划在政府和承包商方面的愿景来避免重大风险。（奥布莱恩和格里芬 2007 年，第 72 页）对主题的详细了解，以及政府和承包商方面的计划愿景。（奥布莱恩和格里芬 2007 年，第 72 页）对主题的详细了解，以及政府和承包商方面的计划愿景。（奥布莱恩和格里芬 2007 年，第 72 页）

这很好地总结了 GPS 中使用的成功的系统工程方法。实现整体平衡的另一个要素是寻求机会作为风险缓解的“反面”。

最后，这里是原始案例研究中提供的学术问题列表。

给学生的问题（O'Brien 和 Griffin 2007，第 73 页）

以下问题旨在挑战读者并为案例讨论做准备。

这个项目是典型的由 ARPA/DARPA 资助的项目吗？为什么或者为什么不？
您是否经历过联合计划的相似或截然不同的方面？
应该以 JPO 为模型的一些特征是什么？
想想 GPS JPO 的人员配备。这该如何描述？它应该在今天的节目中重复吗？它可以？
对这个项目的支持有什么特别之处吗？
整个 GPS 计划存在哪些风险。这些是如何处理的？
需求管理和稳定性经常被认为是国防部采购的核心问题。这个程序与大多数其他程序有何相似或[不] 相似？
用户设备的商业方面是否可以预测或计划？在适当的情况下，COTS 方面是否应该成为其他国防部项目的战略？为什么或者为什么不？

其他问题可能是：对这种 GPS 功能的需求或向公众提供的可能影响是什么？如果公众从一开始就更加意识到潜在的应用对他们的好处，那么 GPS 的发展可能会出现哪些差异？

俄罗斯航天局项目管理系统

本文基于俄罗斯航天局项目管理系统案例研究(Rzevski和Skobelev, 2014)。该案例研究的重点是开发一个实时复杂自适应项目管理系统，该系统能够有效地管理多个相关项目，共同贡献一个定义的企业价值。

背景

每个管理系统的本质应该是相同的：将人力、物理、财务和智力（知识）资源分配给需求（任务），以增加特定的企业价值，其中企业价值是一个价值系统，例如利润、市场份额、业务可持续性、对客户的服务质量、员工的工作条件质量、社区生活质量等。企业管理和项目管理之间的关键区别在于，企业是持续不断的不断发展的过程，而项目有指定的开始和结束。

项目管理的标准挑战是：

严格的预算和期限
对有限资源可用性的激烈竞争，例如最新的领域知识、技能和先进的生产力工具
职能组织，不可避免地阻碍部门间的合作
官僚管理，更关心指挥和报告，而不是充分利用项目成员的主动性和创造力，这会对他们的积极性产生负面影响
僵化的项目计划，导致项目计划与现实之间的快速分歧

大型企业通常同时经营多个项目。对单个项目最好的并不总是对企业最好，因此有必要对同时运行的项目进行协调，以显着提高企业价值。

21世纪给我们带来了两个新的关键问题。

首先是基于互联网的全球市场迅速增加的复杂性，这会产生频繁的不可预测的破坏性事件。这需要实时自适应项目管理，目前还没有先例。

二是知识替代资本成为经济中的关键商业资源，知识服务创造的财富大于商品生产者创造的财富。目前还没有能够发现、处理、存储和分配知识到项目任务的管理系统。

目的

本案例研究的客户是俄罗斯的关键空间技术组织之一，相当于美国国家航空航天局，它在任何时候都在运行许多并发的关键任务项目。

项目管理系统的目的是使客户能够有效地管理多个相关项目（至少十个），共同为指定的企业价值做出贡献，并具有以下要求：

每个项目最多可包含 5,000 个组成任务
项目成员可能有不同的背景和技能，可能属于不同的商业文化
项目成员必须有机会为决策过程做出贡献，这会影响他们的工作领域（分布式决策）
项目管理人员和项目成员都必须分别掌握有关项目和个人进度、生产力和目标实现情况的随时可用的最新信息
资源分配给任务必须考虑4种资源，即人力、体力、财力和知识
每个项目的资源可用性和组成任务可能会在短时间内发生变化，这些变化必须迅速纳入系统
项目将受到频繁的破坏性事件的影响，例如预期订单未到、意外订单到货、外部/内部竞争对手的突然和不可预见的出现、取消、任务规范更改、延迟、失败、未出现等。
管理项目的规章制度可能会经常发生变化，规章制度的任何变化都必须立即轻松地纳入相关的项目管理系统
必须持续监控项目计划与现场实际情况之间的任何差异，并迅速发现和报告
项目可能会合作和/或竞争资源以增加特定的企业价值

对客户需求的彻底分析得出的结论是，有必要开发一个能够与其他系统合作和/或竞争的实时、复杂的自适应项目管理系统，其总体目标是不断增加特定的企业价值。

新系统将取代许多对进度和生产力监控不足的独立、手动或半自动化的项目管理系统。

对当代实践的深入分析表明，这种转变以前从未实现过。据团队所知，世界上任何地方都不存在实时项目管理系统。

挑战

这项特殊的任务面临许多挑战。

最重要的挑战是客户经理对变革的抵制。具有进度和生产力监控功能的新系统可能会暴露效率低下，因此并未受到普遍欢迎。计划采用两种方法来应对这一挑战：第一种是对参与者的教育，第二种是提议一种新的支付结构，该结构将工资与目标的实现联系起来，正如新系统所报告的那样。

提议的系统网络的规模是一个更重要的挑战，尤其是因为所有项目都是关键任务。为了应对这一挑战，制定了采用渐进式发展战略的计划。第一步计划是一个功能有限的完全设计的原型，只有在客户完全接受原型能够提供指定的有限功能后，才能将其扩展到第一个项目管理系统。项目管理系统网络将逐步扩大。

支持该系统的多智能体技术得到了团队的充分了解，并且制定了管理任务复杂性的方法（Rzevski 和 Skobelev，2014 年）。

系统工程实践

概述

客户项目的复杂性排除了所有传统的项目管理实践和系统。相反，该团队为每个项目设计了一个复杂的自适应项目管理系统，该系统基于多代理技术，能够满足客户的要求。

该系统由以下主要组件组成（Rzevski 和 Skobelev，2014 年）：

包含与客户项目管理流程相关的领域知识的知识库
多智能体虚拟世界，它模拟项目的真实世界并能够管理现实世界的复杂性
虚拟世界和现实世界之间的接口，使虚拟世界能够有效地管理现实世界，无论是否有人工干预

知识库

本体中的对象类的示例是：企业、组织单位、项目、任务、项目成员（人力资源）、硬件（物理）资源、文档、软件资源、知识资源和流程。

属性的示例是，对于任务：内容、成本、持续时间、截止日期和偏好；对于项目成员：组织单位、能力、简介、时间表、当前任务、薪水、成就和偏好。

企业本体的片段如下所示。

虚拟世界

填充虚拟世界的代理示例包括：

任务代理，其目标是搜索能够满足其要求的最佳资源
人力资源代理，其目标是获得尽可能好的任务，这将让项目参与者全神贯注，提供奖金机会和/或使参与者能够学习新技能或获得新经验
物理资源代理，其目标是最大化资源利用率
项目代理，其目标是最大化项目价值
企业代理，其目标是最大化企业价值

所有决定都是通过代理协商做出的，例如以下过程：

任务代理向具有所需能力的人力资源代理发送消息，邀请他们为完成任务做出贡献。可用的人力资源代理发送他们的投标。任务代理向那些发出最佳投标的代理提供项目参与。投标须经受影响代理之间的协商。

每当制定新任务或修改先前分配的任务时，都会创建新的任务代理。新的任务代理咨询本体以了解其目标是什么以及如何实现这些目标，然后继续向选定的人力资源代理发送消息，邀请他们竞标参与项目。这个邀请很可能会导致重新安排，给那些对之前的分配不完全满意的人力资源代理提供机会来改善他们的职位。报酬，包括奖金（如有）是根据项目成员的参与和取得的成果计算的。企业成员可以参与多个项目。

物理、软件和知识资源的分配以类似的方式进行。先进的方法（Rzevski 和 Skobelev，2014 年）已被用于最大限度地提高代理谈判的有效性，例如虚拟微观经济学、代理满意度、代理主动性、企业代理、群体合作等。

为项目任务分配资源的决策是使用多种标准做出的，例如，完成时间的减少、质量的提高和已识别的风险的降低，如下图所示。

连接虚拟世界和现实世界

项目成员仪表板是系统与项目成员之间的关键链接。可以使用仪表板进行的信息交换包括：

任务内容、风险、期限和预算的谈判
项目成员接受/拒绝提供的项目任务
项目成员对项目期间意外破坏性事件的输入和评论
系统报告项目成员在执行已接受任务方面的表现

系统可以决定让两个或更多可用的项目成员相互竞争，以确保就可接受的任务绩效达成一致。

虚拟世界和现实世界之间的另一个关键环节是项目经理仪表板，它以各种图表和甘特图的形式显示详细的项目绩效数据，并允许经理检查或修改系统自主做出的决策。

得到教训

首个实时复杂自适应项目管理系统于2014年由客户委托部署，取得以下成果：

项目成员生产力提高 10% 到 15%；
项目调度、监控和协调所需的人力减少 3 至 4 倍；
对不可预测的破坏性事件的响应时间减少 2 到 3 倍；
按预算按时完成的项目数量增加 15% 至 30%；
项目成员积极性显着提高；
在不增加员工数量的情况下增加并行运行的项目数量的可能性。

缺乏信息共享是如何危及NASA/ESA卡西尼/惠更斯号土星任务的

这篇文章描述了一个深空任务，在这个任务中，团队和竞争机构之间可以更直接地交换信息，既可以保留原来的计划，又可以节省很多时间和金钱。这一主题可能对那些参与机构合作的人特别有兴趣，因为这些机构在保护而不是共享信息方面有既得利益。

要获得更多信息，请参阅与信息管理、组织企业执行系统工程和服务基础密切相关的主题。

背景

在 1990 年代引入“更快、更好、更便宜”的理念之前，美国国家航空航天局 (NASA) 专注于三类无人太空任务。按照成本递增的顺序，这些是发现、新前沿和旗舰计划。旗舰项目通常花费超过 $1B，包括航海者（外行星）、伽利略（木星）、卡西尼-惠更斯（土星）、火星科学实验室（火星）和詹姆斯韦伯太空望远镜。（墙 2012）

卡西尼-惠更斯号任务的概念是由美国国家科学院和欧洲科学基金会组成的工作组于 1982 年提出的。该小组寻求联合太空任务的机会；随后的几份报告支持了工作组的土星轨道飞行器与土卫六（土星最大的卫星）着陆器相结合的概念。（罗素 2003 年，第 61 页。）

到 1988 年，NASA 出于政治动机通过参与一项联合任务来扭转早先与欧洲航天局 (ESA) 的紧张关系。 Cassini-Huygens 被视为实现这一目标的一种机制，NASA 和 ESA 之间的合作帮助该计划在潜在的预算削减中幸存下来（因为美国有义务履行 ESA 的承诺）。（罗素 2003 年，第 62 页。）

NASA 和 ESA 批准了 Cassini-Huygens 计划，并按照传统的管理方法进行。美国宇航局建造了卡西尼号轨道器（有史以来最大、最复杂的无人太空探测器），欧空局建造了惠更斯号着陆器。这种责任划分几乎导致了泰坦调查部分任务的失败。卡西尼号（将对土星行星系统进行各种科学调查）预计会将惠更斯号的传输中继到美国宇航局的深空网络（DSN）；然而，着陆器和轨道器之间的接口管理不善，关于分离后轨道器/着陆器系统将如何表现的错误假设几乎注定了任务的泰坦探索部分。（奥伯格，2004 年。）

目的

卡西尼-惠更斯号任务的土卫六调查部分的目的是，惠更斯号着陆器将与卡西尼号轨道器分离，并开始单程 2.5 小时下降到土卫六的大气层。它的小型发射器会将数据发送回轨道飞行器，然后再将信息传递给地球。（Oberg 2004，第 30 页。）这有效地使两个航天器之间的无线电链路成为特征不佳的单点故障 (SPOF)。

建造无线电系统的意大利通信供应商 Alenia Spazio SpA 忽视了当惠更斯号与卡西尼号分离并开始下降时会发生的多普勒频移（约 38 kHz）（Oberg，2004 年，第 31 页）（Oberg 2004 年，第 31 页）。 38). 通信协议是二进制相位键移：“[the] 传输系统通过改变输出载波的相位来表示 1 和 0。恢复这些位需要精确的计时：简单来说，卡西尼的接收器旨在将输入信号每秒分成 8192 个块。它确定每个块与未调制波相比的相位，并相应地输出 0 或 1”。（奥伯格，2004 年，第 31 页。 ) 接收器被适当配置为补偿载波的多普勒频移，但无法针对编码数据的多普勒频移进行调整。 “实际上，这种偏移会使信号与用于从相位调制载波恢复数据的时序方案不同步。” (Oberg 2004, p. 33) 因此，通信系统将无法解码来自着陆器的数据，然后将加扰信息传递给 NASA。由于涉及的故障机制，数据将完全无法恢复。通信系统将无法解码来自着陆器的数据，然后将加扰的信息传递给美国宇航局。由于涉及的故障机制，数据将完全无法恢复。通信系统将无法解码来自着陆器的数据，然后将加扰的信息传递给美国宇航局。由于涉及的故障机制，数据将完全无法恢复。

卡西尼号和惠更斯号在发射前都经过了测试；然而，没有一项测试准确地反映了在任务的这个关键阶段所经历的多普勒频移。由于预算限制，一个进行全面、高保真无线电测试的机会被忽略了；测试将需要对探头进行拆卸和随后的重新认证。（Oberg，2004，第 30 页。）在航天器发射之前（Oberg，2004，第 33 页），一旦它们在前往土星的途中，通过轻微的固件升级来纠正这个潜在问题将是微不足道的。任何纠正措施都将是严重的有限且昂贵。

一旦任务开始，探测器就会沿着其七年的轨迹滑行到土星及其卫星。 ESA 地面运营经理克劳迪奥·索拉佐（Claudio Sollazzo）对未经测试的通信系统感到不舒服。他委托具有无线电和遥测经验的工程师 Boris Smeds 寻找一种使用地球生成信号测试通信系统的方法。（奥伯格，2004 年，第 30 页。）

Smeds 花了六个月的时间开发测试协议，该协议将使用喷气推进实验室 (JPL) 地面站和惠更斯的精确复制品。模拟遥测数据将从地球广播到卡西尼号并转发回来；测试信号的功率水平和多普勒频移会发生变化，以充分发挥通信链路并准确反映惠更斯下降到土卫六大气层期间的预期参数。（欧空局 2005）

挑战

Smeds 的测试计划遭到了那些认为没有必要的人的反对，但最终在 Sollazzo 和惠更斯项目科学家 Jean-Pierre Lebreton 的支持下获胜。任务启动两年多后，Smeds 前往加利福尼亚州的一个 DSN 站点进行测试。（奥伯格 2004 年，第 31 页）

测试信号被广播，由卡西尼接收，重新传输到 DSN 站点，然后转发到位于德国达姆施塔特的 ESA 的欧洲空间操作中心 (ESOC) 进行分析。必须在轨道飞行器在天空中处于正确的相对位置时进行测试；它距离超过 25 万英里，信号往返时间近一个小时。测试立即暴露了一个问题；数据流间歇性损坏，故障与测试信号的功率电平无关。两天测试的第一天没有确定明确的根本原因。（奥伯格，2004 年，第 31 页。）

尽管探测器离它的最终目的地还很远，但许多科学团队都在争先恐后地利用有限的可用带宽与它进行通信。通讯团队将无法在几个月内进行另一组试验。 Smeds 诊断出问题的根本原因；他觉得这是模拟信号中引起的多普勒频移。然而，测试计划不包括无偏移遥测（具有讽刺意味的疏忽）。他连夜修改了自己的测试计划，将计划中的测试时间缩短了 60%；这为他恢复了足够的时间将未移位的信号注入测试协议。（奥伯格 2004 年，第 32 页）

这种未移位的信号没有遭受同样的劣化；但是，其他工程师拒绝对问题进行诊断。使用探针模型和其他设备进行的后续测试最终使 ESA 确信该问题；这又花了七个月的时间。（奥伯格，2004 年，第 33 页。）

到 2000 年底，欧空局向美国宇航局通报了卡西尼号和惠更斯号之间通信链路的潜在故障。调查委员会证实，Alenia Spazio 重新使用了地球轨道卫星上使用的通信系统的计时功能（无需补偿这种幅度的多普勒频移）。（Oberg，2004 年，第 33 页。）此外，由于 NASA 被视为竞争对手，因此通信模块的完整规格并未与 JPL 共享。通信协议的实现在系统的固件中；发射前修正微不足道，发射后修正不可能。（欧空局 2005 年。）

2001 年初成立了一个 40 人的惠更斯恢复工作组 (HRTF)，以调查潜在的缓解行动。分析表明，对信号的任何修改都不会阻止退化；该团队最终提议改变卡西尼号的轨迹以减少多普勒频移。 (ESA 2005) 进行了多项研究来验证这种补救措施的有效性，最终使任务成功完成了泰坦调查。

系统工程实践

太空任务特别具有挑战性；一旦航天器在前往目的地的途中，它就完全被隔离了。无法提供额外的资源，也无法进行维修（尤其是无人任务）。由于停靠的月球游览舱 (LEM) 的资源和地面控制小组专家的足智多谋，阿波罗 13 号的机组人员勉强在其任务中的重大事故中幸存下来。伽利略号木星任务期间发生了一个鲜为人知的失败。挑战者号灾难发生后，NASA 采用了限制航天飞机携带的助推器尺寸的安全标准。（伦泽蒂 1995 年。）伽利略号在航天飞机停飞时被推迟，伽利略号的轨迹被重新规划，包括飞越金星以加速和补偿较小的助推器。伽利略的主天线未能展开；在延长的计划外存储过程中，润滑剂已经蒸发（Evans 2003），有限的计算机空间导致删除了天线电机反转软件，以便为热保护程序腾出空间。当天线部分展开时，它被卡在了原位，无法重新卷起并重新展开。工程师最终使用了机载录音机、修改后的传输协议、可用的低增益天线以及对 DSN 的地面升级来挽救任务。（Taylor、Cheung 和 Seo 2002。）它被卡在了原地，无法重新折叠和重新部署它。工程师最终使用了机载录音机、修改后的传输协议、可用的低增益天线以及对 DSN 的地面升级来挽救任务。（Taylor、Cheung 和 Seo 2002。）它被卡在了原地，无法重新折叠和重新部署它。工程师最终使用了机载录音机、修改后的传输协议、可用的低增益天线以及对 DSN 的地面升级来挽救任务。（Taylor、Cheung 和 Seo 2002。）

泰坦调查最终成功，因为模拟技术能够验证计划的轨迹修改，并且有足够的反应质量来完成必要的机动。此外，Smeds 的分析为任务团队提供了充分诊断问题并制定和实施补救措施所需的时间。如果这项测试在调查前一天进行，它只会提前向 NASA 和 ESA 发出灾难警告。所提供的时间使任务计划者能够制定出解决通信问题的轨迹，然后重新融入原始任务配置文件，以保持为卡西尼号计划的土星飞越的平衡。（奥伯格，2004 年，第 33 页。）

得到教训

卡西尼-惠更斯对土卫六的调查几乎失败了，因为少数专门的系统工程师争取并进行了相关测试，暴露了一个潜在的缺陷，并且在任务中做得足够早，以便制定恢复计划并执行。该问题的根本原因包括政治驱动的分区、糟糕的界面管理、忽视的上下文信息以及对单点故障 (SPOF) 缺乏认识。

希望使用联合太空任务作为使 NASA 和 ESA 更紧密地联系在一起的机制（以及相关的对外关系的积极影响）在系统中引入了一个不必要的接口。必须始终小心管理接口；组织之间的接口（尤其是那些跨越组织或政治边界的接口）需要额外的努力和关注。波音和空客在波音 787 和 A380 的开发过程中遇到了类似的问题；设计活动和供应链中的国际接口导致了以下问题：

…自然界中的每个界面都有表面能。创建一个新的表面（例如，通过将一块钢切成两块）会消耗能量，然后能量会束缚在该表面（或界面）中。人类系统（或组织）中的接口是此类复杂系统的一个关键方面，在创建和维护它们方面也有成本。其次，摩擦会降低性能。著名军事战略家卡尔·冯·克劳塞维茨（Carl von Clausewitz）将摩擦定义为单位、组织或系统的理想表现与其在现实世界中的实际表现之间的差异。摩擦的主要原因之一是信息不明确或不明确。对任何系统进行分区都会在界面处引入摩擦。（Vinarcik 2014，第 697 页）

Alenia Spazio SpA 在土卫六调查期间对惠更斯和卡西尼的计划相对轨迹引入的多普勒频移不清楚，导致它重新使用地球轨道卫星的一个组件。因为它认为 NASA 是竞争对手，并且将通信系统的细节隐藏在适当的面纱后面，所以它阻止了在设计阶段发现这个缺陷。（奥伯格 2004 年，第 33 页）

由于 NASA 和 ESA 没有将此通信链路确定为关键的 SPOF，因此他们都牺牲了在权宜之计和节省成本的祭坛上进行的发射前测试。这阻止了在任务被派往土星之前检测和纠正缺陷。后来的分析和补救行动的资源成本是不小的，如果没有足够的时间和反应质量，任务就会受到影响。应该注意的是，最近的一些航天器故障直接归因于 SPOF（特别是火星极地着陆器（JPL 2000）和创世纪样本返回任务（GENESIS，2005））。有效的 SPOF 检测和修复必须是任何产品开发工作的优先事项。更一般地说，在开发过程的早期，

惠更斯对泰坦的调查的成功建立在 Boris Smeds 通过确定关键通信链路中设计缺陷的根本原因所建立的基础之上。本案例研究强调了对 SPOF 的清晰的上下文理解、强大的界面管理、代表性测试以及适当的表征和管理的需求。

哈勃太空望远镜

这篇文章描述了一个具有巨大科学效益和影响的非凡工程壮举。对于那些面临艰巨的系统工程挑战的人来说，这个话题可能会特别有趣，因为在这些挑战中，一个人可能会凭借谦逊和乐观的深思熟虑而茁壮成长。有关其他信息，请参阅下文第五节:经验教训中提供的链接。

背景

哈勃太空望远镜 (HST) 案例研究由位于空军技术学院 (AFIT) 的美国空军系统工程中心 (AF CSE) 开发。 AF CSE 的任务是开发案例研究，重点是系统工程原理在各种航空航天项目中的应用。 HST 研究（Mattice 2005）是 AFIT 为支持系统工程研究生院教学而选择的四个初步案例研究之一。这些案例是使用 Friedman-Sage 框架构建的（Friedman and Sage 2003；Friedman and Sage 2004, 84-96），将案例分解为承包商、政府和以下九个概念领域的共同责任：在此停止

需求定义和管理
系统架构开发
系统/子系统设计
验证/确认
风险管理
系统集成和接口
生命周期支持
部署和部署后
系统和程序管理

该案例研究提供了一个有用的示例，说明通过连续生命周期阶段的缺陷纠正成本不断上升，展示了如何在设计阶段以 1,000 美元修复错误（在测试夹具规范中），或如何以 1000 万美元检测和修复在地面上对望远镜进行端到端测试的投资，最终在系统投入使用时花费了 10 亿美元来修复。

目的

哈勃太空望远镜 (HST) 是一个轨道天文观测台，在从近红外到紫外的光谱中运行。 HST 于 1990 年推出并仍在运行，携带并已携带各种仪器，通过定向和平行观测计划产生成像、光谱、天体测量和光度数据。已对 20,000 多个目标进行了 100,000 多次观测以供检索。该望远镜被誉为科学奇迹。本案例研究希望代表 HST 的一个方面，这是一个系统工程的奇迹，事实上，它产生了现在全世界都赞赏的科学研究和观察能力。

从只有时间和事后才能提供的清晰度来看，HST 计划无疑代表了在任何国际范围和复杂性的任何规模上最成功的现代人类努力之一。作为一个系统工程项目，HST 必须响应来自不同国际科学界的要求，当时美国宇航局正在实施与大多数主要政府采购计划中主要使用的不同的研究-开发-采购理念和流程。与大多数其他大型程序一样，系统工程过程本身之外的强大影响成为 HST 系统工程师的问题实际上，他们必须承认他们的整体系统/程序/工程管理责任是不可或缺的。

挑战

这种非凡能力是如何产生的故事是一个系统工程过程的复杂相互作用的故事，我们希望相信我们理解这个过程，以及我们经常无法理解或理解的同样苛刻的政治、预算和制度过程。它们发生的时间。归根结底，这些过程是实现项目成功不可分割和不可或缺的。现代系统工程师面临的挑战是完全接受系统工程过程的学科，同时学习如何在不可避免的外部影响和通常无法预料的不稳定性的情况下继续实践它。

主要区别在于与大多数 DoD 系统非常不同的 HST“客户”或用户的性质和需求。 HST 必须响应来自不同国际科学界的要求，而不是来自国防部作战司令部的要求。此外，当时，NASA 实施了与 DoD 5000 系列采办改革中描述的 DoD 采办管理框架不同的研究-开发-采办理念和流程。与大多数其他大型程序一样，系统工程过程本身之外的强大影响成为 HST 系统工程师实际上必须承认的问题，这是他们整体系统/程序/工程管理责任的组成部分。

系统工程实践

在 HST 计划的关键系统工程阶段（1970 年代概念研究到 1990 年发射）似乎没有 NASA 系统工程主流程。相反，现场中心流程是有效的，甚至可能在竞争中，因为中心（尤其是 HST 的 Marshall 和 Goddard）在领导管理角色和职责方面处于激烈竞争中。我们将看到这场竞赛对 HST 的系统工程和项目管理影响，科学任务目标和仪器有效载荷是戈达德的动力，而马歇尔的车辆/有效载荷访问空间动力。归根结底，主要承包商在系统工程设计中所扮演的角色，而 NASA 在系统生命周期中的参与程度参差不齐，产生了明显的影响。

得到教训

五个学习原则（LPs）被推导出来解决系统工程知识更广泛适用的领域。这五个 LP 告知 SEBoK 中与案例研究最密切相关的领域。这五个领域是：

利益相关者需求定义（LP1）；
规划（预科贸易研究）（LP2）；
系统集成（LP3）；
生命周期模型管理（LP4）；和
风险管理（LP5）。

HST 学习原则 (LP) 的概要如下：

利益相关者要求定义 LP1：客户/用户在整个计划中及早和充分参与对于成功至关重要。在 HST 计划的早期阶段，涉及客户的机制没有很好地定义。用户社区最初是两极分化的，没有有效地参与项目定义和宣传。尽管在很大程度上受到外部政治和相关国家计划举措的推动，这种情况最终变得更好。最终，用户参与过程的制度化确保了强大的代表性以及在建立和管理程序需求方面的基本利益和作用。随着时间的推移，“研究所”的有效性导致用户同样有效地参与了系统的部署和在轨操作。

规划 LP 2：使用项目前贸易研究（例如“分阶段研究”或“分阶段项目规划”）广泛探索技术概念和替代方案是必不可少的，并提供来自各种承包商和政府（NASA ) 中心。这些活动涵盖一系列可行性、概念、替代和初步设计交易，成本最初是次要因素（后来成为主要因素）。就 HST 而言，一些 NASA 总部和中心组织资助了这些研究，并赞助了 HST 概念技术研讨会。这种方法可以促进健康或不健康的竞争，特别是当参与的管理中心内部和之间的角色和责任尚未确定并且竞争的外部组织利用这些研究来推进技术和政治议程时。根据政治和/或预算现实，NASA 中心的角色和任务也可能受到威胁。这个阶段的系统工程挑战是“保持技术性，愚蠢！”

系统集成 LP 3：用于组装、测试、部署和操作系统的高度系统集成对于成功至关重要，并且必须被确定为作为项目基线的一部分的基本项目资源需求。对于 HST 而言，该计划与航天飞机的早期结合、之前 NASA 和 NASA 承包商在类似复杂计划（如阿波罗）方面的经验，以及对载人在轨服务的早期需求，使得人们很难不承认这是一个大型系统工程集成挑战。尽管如此，政府工程师、承包商工程师以及客户之间的协作必须在早期得到明确定义和实施，以克服不可避免的集成挑战和不可预见的事件。

生命周期模型 LP 4：生命周期支持计划和执行必须从第一天开始就不可或缺，包括概念和设计阶段。结果会说明一切。具有实际生命周期性能的程序作为设计驱动程序将能够更好地在服务中执行，并且能够处理不可预见的事件（甚至在未预料到的任务中使用）。 HST 可能代表了构建系统维护（可靠性、可维护性、技术升级、内置冗余等）的基准，同时提供对服务任务至关重要的功能（计划内和计划外）的人工执行。完成了四项成功的服务任务，包括一项最初未计划的（主镜维修）、为维持而设计的好处或生命周期支持，在程序的所有阶段都变得相当明显。如果没有这种设计方法，甚至不可能尝试意外的、计划外的镜像修复，更不用说完全成功了。

风险管理 LP 5：对于复杂的项目，利益相关者（政府和承包商）的数量要求项目的结构能够同时应对许多管理和技术领域的高风险因素。 HST 项目严重依赖承包商（尤其是洛克希德导弹和航天公司 (LMSC) 和珀金埃尔默 (PE)），每个承包商都“拥有”非常重要和独特的项目风险领域。在光学系统的关键领域，NASA 依靠 LMSC 作为整体集成商来管理 PE 显然是技术专家的领域的风险。因此，NASA 依赖于 LMSC，而 LMSC 依赖于 PE，但整个过程中质量保证职能的检查、监督和独立性不足。虽然大多数其他风险领域无疑得到了有效管理，

基于模型的30米望远镜支撑需求分析

本文描述了如何使用基于模型的系统工程(MBSE)方法来支持30米望远镜(TMT)[8]关键子系统的需求分析、系统设计和早期验证。MBSE方法采用可执行系统工程方法(ESEM)[4][5]和开源工程环境(OpenMBEE)[7]来指定、分析和验证TMT的对准与相位系统(APS)和窄场红外自适应光学系统(NFIRAOS)的需求。应用这种MBSE方法的价值主张是建立对系统设计的精确需求和细粒度的可跟踪性，并在开发早期使用可执行的SysML[6]模型验证关键需求。

背景

TMT（图 1）是下一代地面超大型望远镜，旨在回答有关宇宙性质和组成的关键科学问题。其核心是宽视场、高度方位角 Ritchey-Chrétien 设计，具有 492 段、直径 30 米的主镜 (M1)、完全有源的副镜和铰接式第三镜。每个部分的光学性能都对三个刚体自由度敏感：活塞、尖端和倾斜。为了获得最佳图像质量，分段式 M1 必须像单个单片镜一样运行，通过大量控制来实现其部分的共同对齐、共同聚焦和同相。 APS（图 2）负责整体预自适应光学波前质量，使用星光测量波前误差并校准 TMT 光学。 NFIRAOS（图 2）等自适应光学系统旨在感知实时大气湍流并校正望远镜的光束以消除其影响，从而在地面上实现衍射限制成像。在 LGS MCAO 和 NGSAO 模式下，这是通过使用波前传感器检测激光和自然导星以及可变形镜将校正后的波前引导至科学仪器来实现的。这些光机设计和复杂的控制受到一些必须满足的要求的限制。这是通过使用波前传感器检测激光和自然导星以及可变形镜将校正后的波前引导至科学仪器来实现的。这些光机设计和复杂的控制受到一些必须满足的要求的限制。这是通过使用波前传感器检测激光和自然导星以及可变形镜将校正后的波前引导至科学仪器来实现的。这些光机设计和复杂的控制受到一些必须满足的要求的限制。

图 1. 30 米望远镜。 （经许可使用。由 Jamie Nakawatase 授予许可。）

图 2. APS 和 NFIRAOS 早期光照位置。 （经许可使用。由 Jamie Nakawatase 授予许可。）

TMT International Observatory (TIO), LLC 是一个由国际成员组成的非营利组织，负责管理 TMT 的设计、开发和运营。喷气推进实验室 (JPL) [9] 参与了多个 TMT 子系统的设计和开发，并提供了一个可操作的 APS，其中 TIO 负责向 JPL 提供需求。 APS 团队应用 MBSE 方法来分析需求、推导出架构设计和实施系统。 TIO 还与 JPL 合作，通过使用 Monte-Carlo 模拟对系统级操作场景（如回转、采集和抖动）进行建模，分析 NFIRAOS 的操作行为。建模模式用于捕获功能和物理系统特征、行为、需求、参数关系和用例场景。

目的

本文描述了如何将 MBSE 应用于复杂跨学科系统的关键子系统的开发以及这种方法的好处。虽然在整个开发生命周期中都需要基于文档的工件，但复杂的系统工程在很大程度上依赖于使用模型来解决来自各个领域（例如机械、光学、控制）的问题（图 3）。 MBSE 有助于管理对这些跨域文档中包含的信息的隐含依赖性、了解变更影响、分析设计并传达不断发展的技术基线。模型作为系统工程信息的唯一权威来源，通过一致和自动化的数据交换、增强的分析、

图 3. 工程模型图。 （经许可使用。由 Jamie Nakawatase 授予许可。）

MBSE挑战

系统工程 (SE) 本身就具有跨越多个工程学科的概念的挑战性。在模型中表达这些概念需要使用灵活的方法、语言和工具。建模者必须了解如何利用这种灵活性来严格指定具有广泛复杂设计考虑的系统。这带来了最初的 MBSE 挑战—— 学习曲线 。然而，这一挑战是任何新事业所固有的，并且可以通过实践经验、培训和不断增长的资源来克服。

另一个挑战是确定如何应用 MBSE 来满足项目的需求。 MBSE 与 SE 并不分离——它是一种更有效地实现 SE 基本目标的方法。 MBSE 不应该被用来重复工作，而应该取代可以通过建模更好地正式完成的工作。

工程师生活在不同领域（例如 ALM、PLM、CAD）的工具和信息模型之间的可变性环境中，这些领域通常是隐式连接的 [4]。为了从基于模型的范式中受益，模型需要明确的连接。一个关键挑战是如何利用数据和相关模型来实现 跨域集成 。

最后， 标准化 是 MBSE 面临的挑战。模型只有在利益相关者能够理解的情况下才有效。 SysML 是一种不断发展的建模语言，它正在成为沟通系统架构的主要标准，独立于使用它的建模工具。但是，SysML 只是必须应用的众多标准之一，以确保工具和用户能够一致地解释模型。

MBSE方法

MBSE 方法遵循由基于模型的范例丰富的传统 SE V 过程（图 4）。此 MBSE 应用程序的范围涉及 L2 和 L3 的模型，以及向下流向 L4 的需求，尽管该方法也可以应用于支持其他级别的规范和架构设计。相关的建模工件是早期创建的，并在整个开发生命周期中进行维护。

图 4. 基于 JPL 模型的 V 流程。 （经许可使用。由 Jamie Nakawatase 授予许可。）

MBSE 在一个正式的、可执行的模型中阐明了系统架构，该模型捕获了系统元素的结构、行为、需求和参数关系。操作场景在模型中定义，并通过系统级仿真进行分析，以验证需求并在预期的条件和参数范围内验证整体系统设计。系统模型也是多个工程文件的权威来源。 MBSE 方法随后通过其方法、工具基础设施和分析过程进行描述。

方法

可执行系统工程方法 (ESEM) [1] 用于形式化需求、指定系统设计、表征组件和指定/运行分析。 ESEM 通过启用可执行模型来增强面向对象的系统工程方法 (OOSEM) [2]，这些模型通过应用各种 SysML 图指定的分析模式来增强对需求的理解、精度和验证。 ESEM 还支持供应商/客户模型的集成。

图 5 显示了使用 OOSEM 的 SE 流程常见的主要活动。红色圆圈表示 ESEM 注入正式建模方法的位置。

图 5. OOSEM 活动。 （经许可使用。由 Jamie Nakawatase 授予许可。）[8]

ESEM 用于对不同级别的抽象进行建模，这些抽象级别使用 [4] 中详述的几种建模模式进行分析。感兴趣的系统被建模为与外部子系统（例如控件）交互的黑匣子。使用端口对交互进行建模，以识别感兴趣系统接口处的操作和流。

概念模型指定与技术无关的系统组件并捕获它们的行为。这部分模型用于分析操作场景的持续时间等特征。使用状态机和活动图捕获组件行为，并在表格中捕获约束参数。内部和外部系统组件之间的通信是通过端口发送和接收信号来完成的。该模型支持通过查询从一个组件通过端口发送到另一个组件的信息来生成接口控制文档。

概念模型作为指定物理组件实现模型的基础。实现模型对设计解决方案施加了依赖于技术的约束。概念（即逻辑）和实现（即物理）模型都代表“指定的”系统。

工装

MBSE 方法使用标准 SysML 语言和建模工具来最小化定制软件。 OpenMBEE 社区提倡开放工具环境，为建模提供平台。它利用模型管理系统 (MMS)，可以从丰富的 SysML 桌面客户端（如 MagicDraw）、基于 Web 的轻量级客户端（如 View Editor）、计算程序（如 Mathematica）以及其他利用 RESTful Web 服务的工具访问。 MMS 还为搜索、关系管理、版本控制、工作流、访问控制、内容灵活性、Web 应用程序支持、基于 Web 的 API 访问以及跨工程和管理学科的多工具/存储库集成提供基本的基础设施。

图 6 显示了由 MMS、View Editor 和 MagicDraw 生成的模型工件的集成。系统模型是按照 MMS 中的视图和视点范式 [3] 构建、查询和渲染的。

图 6. OpenMBEE 交互。 （经许可使用。由 Jamie Nakawatase 授予许可。）

分析

一个关键的 SE 过程是分析需求变化对系统设计的影响。图 7 说明了如何使用 MBSE 方法通过以下步骤支持需求影响分析：

第 1 步：变更的需求触发影响分析。
第 2 步：MMS 集成 DOORS（管理文本需求）和 SysML 模型，使 DOORS 需求更改能够传播到 SysML 模型。
第 3 步：在 SysML 中形式化基于属性的需求，启用可以通过工程分析评估的需求规范。
步骤 4-6：根据更改的需求自动验证概念和/或实现设计，从而确定通过或失败。

图 7. 变更需求的传播。 （经许可使用。由 Jamie Nakawatase 授予许可。）

在本文中，展示了一个简化的 APS 模型，以说明基于模型的方法来分析更改的需求。完整的分析可在 [4] 和 [5] 中找到。

基于模型的方法也应用于 APS 进行错误分析，以描述预期系统性能与要求的准确性。它涉及多个工件来分析要求，例如“APS 应以瞳孔直径的 0.03% 的精度测量望远镜瞳孔的位置”。在模型中定义要求和参数表明了系统设计所需的精度和当前最佳估计。定义允许误差分解计算的各种汇总模式。当应用参数求解器为模型中的指定方程制定结果时，自动需求验证实现了好处。这种基于模型的方法将精度要求与系统设计正式集成。

NFIRAOS LGS MCAO 和 NGSAO 模式的系统模型旨在捕获序列行为和运行场景，以运行 Monte-Carlo 模拟，以验证采集时间、观测效率和运行行为要求。该模型对于调查并行化的影响、识别接口问题和重新排序序列采集任务特别有用。

ESEM 通过进行定量评估来选择和/或更新最有效的系统架构并生成衍生的工程数据，从而实现系统分析。系统分析为技术决策提供了严谨性。它包括建模和模拟、成本、技术风险和有效性分析，并用于进行贸易研究。特别是，它支持需求验证，即评估系统设计是否满足其目标并满足系统需求所施加的约束。

观察到的好处

应用于 APS 和 NFIRAOS 的 MBSE 方法的动机是优化以协调复杂系统开发的工作。在这些应用程序中，隐式依赖关系通过使用 ESEM、OpenMBEE 和 SysML 建模结构在正式模型中显式化。需求被形式化并直接跟踪到不断发展的系统设计。通用环境中需求的这种紧密关联促进了利益相关者之间的跨域集成和有效沟通。该模型用于自动化需求验证并生成系统工程产品。相对于传统的基于文档的方法的好处是，当前断开的工件在模型中变得相关，从而能够生成一致的基于模型的文档。需求验证是在 MBSE 环境中进行的一项重要分析。要执行此分析，必须集成需求、可执行行为和预测系统性能的模型。使用 ESEM 和 OpenMBEE 工具基础设施集成这些元素的能力是本文描述的 MBSE 方法的重要价值主张。在正式集成和可执行的 SysML 模型中，执行模拟以分析更改需求的影响，并验证在各种操作场景的指定约束内满足需求。 MBSE 通过创建传达系统行为的可视化来增强信息交换。例如，进行持续时间分析以研究观察的采集时间。蒙特卡罗模拟的使用证明了基于模型的方法如何优化分析过程。通过在铰接式系统模型中执行操作场景运行获得了更高质量的分析结果，并且该模型继续充当跨各个领域的通信工具。

微型导引头技术集成航天器

微型导引头技术集成 (MSTI) 航天器是同类中的第一个：一种快速发展的航天器，在一年内设计并发射。作为卫星应用的航空航天示例，案例研究“MSTI：优化整个系统”（Grenville、Kleiner 和 Newcomb 2004）描述了该项目的系统工程方法。在积极的时间表的推动下，MSTI 对整个项目进行了优化，而不是允许在组件级别进行子优化。作为与菲利普斯实验室、喷气推进实验室 (JPL) 和 Spectrum Astro 的合作伙伴，MSTI 于 1992 年 11 月 21 日进入轨道。MSTI-1 成功实现了所有主要任务目标，超过了为期 6 天的数据收集任务要求.

领域背景

有许多航空航天系统的案例研究示例。这个案例特别有趣，因为它突出了在积极的时间表之后能够成功执行的机制。由于这种快速发展的航天器是在一年内设计和发射的，因此需要采用新的方式来构建该项目。在这个领域内，MSTI 项目使用了一种创新方法。该项目的实践促成了 JPL 的任务设计中心和系统测试台。

案例研究背景

本案例研究由弗吉尼亚理工学院、州立大学和科学管理公司的作者为支持美国国家航空航天局 (NASA) 计划和项目管理计划而开发。开发案例研究是为了不断改进计划NASA 的项目管理（NASA 2010）。该案例的研究包括全面的文献回顾和详细的访谈。该项目是根据提供经验教训的潜力来选择的。

案例研究说明

MSTI 案例研究说明了系统工程知识体系 (SEBoK) 中描述的许多原则。 MSTI 团队不得不对传统的航天器开发方法进行调整，以保持在预算范围内，并满足在一年内将航天器从构思到发射的紧迫时间表。车队意识到他们“制造的是保时捷而不是一级方程式赛车”（Grenville, Kleiner, Newcomb 2004）。满足时间表是影响所有决定的关键因素。 SEBoK 生命周期模型知识领域更详细地描述了生命周期设计。

该团队利用现有的硬件架构进行架构设计以加快项目进度。此外，在每个设计阶段，整个系统都被优化而不是优化子系统，降低了子系统层面的优化水平。整个项目都使用了硬件在环测试台，从而加快了系统集成。

该计划仅在项目管理办公室保持在较高水平，并且使用“完成成本”的成本报告技术管理成本。预计责任工程当局 (REA) 不会报告过去的支出，而是不断评估他们在预计成本内完成任务的能力。使用硬件采购团队实现了更快的采购，其中技术团队成员与每个设计功能的采购代表相匹配。这对夫妇一起编写了规格并启动了采购申请。

从组织的角度来看，赋予每个团队成员更多的责任和义务。个人对自己的工作拥有自主权，并且简化了决策过程。团队做出了更多“好的决定”，而不是最优的决定。团队并置，日常会议用于分配日常任务，让团队专注于发布。简化了标准问题故障报告 (PFR)，电子报告提供了已解决和未解决的 PFR 的快照。该报告帮助 REA 掌握潜在问题领域。 REA 负责展望项目范围并通知团队任何潜在的问题领域。

MSTI 系列中的第一颗卫星 MSTI-1 于 1992 年 11 月 21 日发射。该航天器重 150 公斤，在不到 12 个月的时间内以 1900 万美元的价格建造。从航天器返回了超过 200,000 张照片。从项目管理的角度来看，所有任务目标都已完成。

此外，MSTI 拥有持久的遗产。更快的采购发展成为 JPL 现在称为“快速通道采购”的一种方法。 JPL 项目中经常使用硬件采购团队。硬件在环试验台是喷气推进实验室飞行系统试验台的前身。由于在 MSTI 项目中被赋予的更多责任和权力，团队成员在 JPL 中迅速晋升。

阿波罗一号灾难

1967 年 1 月 27 日，阿波罗 204 号的机组人员正在为首次载人阿波罗飞行进行训练，这是一项计划于 2 月 21 日发射的地球轨道飞行任务。飞行指挥官格斯·格里森、宇航员爱德华·怀特和宇航员罗杰·查菲在这次飞行前测试中因大火席卷阿波罗指挥舱而死亡。事故发生后，NASA 将阿波罗 204 号重新归类为阿波罗 1 号。本案例研究考察了导致阿波罗 1 号灾难的一些人为因素不足。

背景

1967 年 1 月 27 日，阿波罗 204 号的机组人员正在为首次载人阿波罗飞行进行训练，这是一项计划于 2 月 21 日发射的地球轨道飞行任务。就像在实际发射中一样，他们在发射台上进行了“拔出”测试，只是火箭没有加油。这个测试是一个模拟，经历了一个完整的倒计时序列。飞行指挥官格斯·格里森、宇航员爱德华·怀特和宇航员罗杰·查菲在这次飞行前测试中因大火席卷阿波罗指挥舱而死亡。事故发生后，美国宇航局将阿波罗 204 号重新归类为阿波罗 1 号。

在测试和随后的事故中，应急小组没有出席（Benson 和 Faherty 1978）。由于车辆没有加油，消防人员只是待命（Freiman and Schlager 1995）。人们认为，该测试没有对危险分类进行评级（Benson 和 Faherty 1978）（NASA 历史办公室 1967），并且位于发射塔测试室的应急设备并非针对导致的火灾类型而设计（NASA 历史办公室1967）。在太空舱内，没有任何防火设计特征，因为没有人考虑过火箭发动机以外的任何东西引起火灾的可能性（美国宇航局历史办公室 1967 年）。机舱内甚至没有灭火器（Freiman 和 Schlager 1995）（Kranz 2000）。宇航员弗兰克博尔曼后来说，

NASA 利用来自两个早期水星和双子座太空计划的技术知识，并将它们的设计用作阿波罗计划的基线（Rosholt 1966）。如此庞大的工程，自然会出现一些问题。部分由于大量的整合问题，机组人员无法逃离火灾。然而，事故发生后，NASA 官员承认他们将精力集中在“飞行中”的情况上，甚至没有考虑地面上的问题（Benson 和 Faherty 1978）（Kranz 2000）。

挑战

在 1960 年代后期，NASA 的系统集成小组似乎主要集中在文书工作上，尽管 NASA 将 Apollo 204 测试视为一种系统集成测试（Baldwin 和 Reilly 2005）。不管系统集成工作如何，在集成宇航员方面存在明显的差距，导致阿波罗 1 号人员死亡的不幸后果。

孵化场的整合

众所周知，从太空计划开始就将安全性设计和集成到太空舱中是一个重要因素。舱口是航天员进出舱的主要方式，是航天员整合的重要组成部分。

水星和阿波罗太空舱都配备了从运载火箭故障中逃脱的方法（Purser、Faget 和 Smith 1965）（Swenson Jr.、Grimwood 和 Alexander 1998）。这个逃生系统由太空舱上的助推火箭组成，它可以使太空舱远离故障火箭。双子座太空舱有弹射座椅。由于紧急弹射过程中的危险，阿波罗的设计回到了逃生塔助推器（Purser、Faget 和 Smith 1965）。如果没有弹射座椅，则不需要双子座计划使用的快速打开舱口。最初，阿波罗太空舱承包商北美航空公司推荐了一个向外打开的舱口，舱口带有爆炸螺栓，以备不时之需。 NASA 的设计师不同意，因为早期的水星太空舱意外打开了类似的舱口设计（Brooks、Grimwood 和 Swenson 1979）。 “美国宇航局和北美设计师对逃生意外事件的担忧不如他们对舱口突然打开到太空真空中的可能性或在水上着陆期间另一个无意中打开的可能性”（Kranz 2000）。

为了保证宇航员的安全，“阿波罗任务的设计者宁愿机组人员永远不要离开太空舱”（Mendell 1998）。因此，设计者将舱口集成为向内打开，这使得内部压力有助于保持舱口的安全（Murray 和 Cox 1989）。集成过程的结果是一个由三部分组成的舱口，一个在太空舱在地面上时向内打开的内部压力舱口，一个在太空中向外打开的烧蚀舱口，以及一个在发射过程中保护太空舱不受伤害的助推保护盖。逃生塔助推器 (Freiman and Schlager 1995) (Kranz 2000) (NASA History Office 1967)。此外，设计师选择不使用爆炸舱口。作为阿波罗一号事故的旁白，即使太空舱有一个爆炸舱口，

在理想条件下打开舱口至少需要 90 秒（Freiman 和 Schlager 1995）（参议院航空和空间科学委员会 1968）。实际上，机组人员从未在最短的时间内完成撤离。此外，在紧急情况下，逃生是一个非常复杂的过程。例如，它需要一名宇航员降低另一个人的头枕，以启动棘轮式装置，该装置将释放一系列闩锁中的第一个（NASA 历史办公室 1967 年）。事故发生时，打开舱门需要 5 分 25 秒（NASA 历史办公室 1967）。阿波罗审查委员会批评了这个问题，并且显然建议改变它（Benson 和 Faherty 1978）。

阿波罗一号的事故导致美国宇航局重新考虑其决定和流程。尽管在技术上整合得很好，但美国宇航局在将宇航员与舱口整合方面缺乏。为了解决这个问题，舱口被重新设计为单铰链，可以在三秒钟内解锁，并且可以用最小的力向外摆动（Benson 和 Faherty 1978）。

环境控制系统的集成

也许所有人为因素中最复杂的因素与环境控制系统 (ECS) 有关。该系统旨在控制输送给宇航员的空气的数量和质量，保持机舱压力，并对宇航员、设备和机舱进行加热和冷却。必须预见到极端的太空飞行，并且该系统需要满足恶劣环境的需求。内置冗余以提供合适的备份系统并确保可靠性和可用性（NASA History Office 1967）。

NASA 工程师进行的贸易研究得出结论，机舱内的纯氧气氛是首选。再一次，这个决定没有充分考虑到宇航员。 1964 年，Lovelace 医学教育和研究基金会的 Emmanuel Roth 博士为 NASA 准备了一篇警告纯氧危险的论文（Benson 和 Faherty 1978）。天然织物、大多数合成材料，甚至据称是防火材料，都会在纯氧环境中剧烈燃烧。同年，北美航空阿波罗空间科学与系统公司的科学家 Frank J. Hendel 博士写了一篇文章，警告人们不要使用纯氧，尤其是在发射台上（Benson 和 Faherty 1978）。当时阿波罗航天器计划办公室负责人乔·谢伊在一份备忘录中写道， “问题很棘手——我们认为我们有足够的余地来防止火灾发生——如果有的话，我们确实有问题。尚未开发出合适的灭火剂”（Murray 和 Cox 1989）。

由于 ECS 运行所在的持续重新设计和测试环境，需要快速轻松地更换组件以节省时间（NASA 历史办公室 1967）。这种需要导致布线和绝缘不良（Stavnes and Hammoud 1994）。冷却液盘管放置在允许它们用作手柄在机舱内移动的位置。这种意外使用导致机舱内的冷却剂泄漏，蒸气易燃，液体形式的冷却剂本身会腐蚀命令模块中近 12 英里的电线绝缘层（Freiman 和 Schlager 1995）（NASA历史办公室 1967 年）。冷却系统遍布整个胶囊，焊点处的冷却剂泄漏已经成为一个长期问题（NASA 历史办公室，1967 年）。

一根 ECS 电缆楔入宇航员使用的门的底部。当门关上时，它会刮掉电缆。反复磨损最终暴露了电缆上的两小部分电线（Murray 和 Cox 1989）。当绝缘层磨损时，布线系统会失效，并且会产生火花（Stavnes 和 Hammoud 1994）。更糟糕的是，磨损电缆附近的易燃拉舍尔网比应有的位置更靠近电缆（Murray 和 Cox 1989）。

宇航员的宇航服也没有很好地融入 ECS。一个西装回路为宇航员和机舱提供空气质量控制、温度控制、压力控制、湿度控制和去污。有三名宇航员穿上衣服，并以第四件衣服的位置插入环路。这种所谓的第四套防护服位置提供了强制通风和与防护服回路进行机舱空气交换（Bellcomm, Inc. 1964）。宇航服与客舱的这种连接在紧急情况下无法关闭。结果将允许来自火灾的内部有毒气体穿透宇航员的衣服。

出口系统的集成

直到事故发生之前，没有人认真考虑过太空舱内存在安全问题的可能性。允许宇航员离开发射台的出口系统没有被彻底探索，并且遗漏了几个集成问题（NASA历史办公室1967）。 “我们都认为，当一场灾难袭来时，它会在飞行中。我们的噩梦是发射过程中的爆炸，或者是飞行中的棺材，是卡在无尽轨道上的有缺陷的飞船”（Kranz 2000）。对于机组人员或航天器垫工作组（NASA 历史办公室，1967 年），地面上的舱内紧急情况没有正式的程序。

根据设计者的经验，“如果在轨道的动力上升部分发生故障，应使用逃生系统”（Purser、Faget 和 Smith 1965）。不幸的是，设计师只考虑了宇航员必须留在太空舱中的逃生情况。进行了危险分析以“检查在动力飞行期间可能需要从运载火箭逃生的所有危险”（Purser、Faget 和 Smith 1965）。尽管如此，人们认为危险是通过三个运行阶段来实现的，“1) 升空和此后不久，2) 通过最大动态压力状态的跨音速，以及 3) 停机和分级”（Purser、Faget 和 Smith 1965）。没有提到胶囊本身存在危险。

可以在发射台环境中找到不令人满意的出口的其他证据。即使他们可以打开舱口，也没有应急准备允许机组人员从内部胶囊火灾中逃生或营救。脐带塔通道臂包含诸如台阶、滑动门和阻碍紧急行动的出口路径中的急转弯等特征（NASA 历史办公室 1967）。尽管对阿波罗 1 号来说为时已晚，但阿波罗 204 审查委员会严厉批评了宇航员无法快速逃离太空舱的事实（Benson 和 Faherty 1978）。

920 次浏览	4次

欢迎参加课程:
	数据建模方法与工具
	MBSE（基于模型的系统工程）
	基于 UML 和EA进行分析设计

< 首页