2.3 运用系统工程引擎的示例

为了帮助了解系统工程引擎是如何应用的，本节给出一个示例。相关讨论围绕工程和项目寿命周期的各阶段展开，关于寿命周期的内容将在第3章中进行更深入的讨论。在第3章中将描述NPR 7120.5所定义的用于NASA空间飞行工程和项目的寿命周期的概念。项目寿命周期的阶段划分见表2.3-1。

进行寿命周期的阶段划分，可以描述项目中不同产品从初始概念，到产品成型，再到最终退役/废弃处置的逐渐发展和成熟的过程。图2.1-1所示的系统工程引擎覆盖寿命周期所有的阶段。

在A前阶段，系统工程引擎用于开发初步概念；清晰定义人员、硬件和软件在实现使命任务目标中的特定作用；标定系统功能边界和性能边界；初步/概要地开发/制定系统关键顶层需求集；定义一个或多个初步的系统运行使用构想（ConOps）场景；通过迭代运用模型、样机、仿真或其他手段实现这些初步概念；验证并确认这些初步概念和最终产品将能够满足系统的关键顶层需求和运行使用构想。系统运行使用构想必须包括所有典型的运行使用场景，以及已知的非预设场景。开发一个可用的完备的运行使用场景集，必须考虑那些重要的可能出现系统功能障碍和性能降级的运行使用场景。对于在早期开发的运行使用构想，其重要性不应被低估。随着系统需求变得更加详细和包含更加复杂的信息，对于系统的利益相关者和用户来说，理解系统需求变得更加艰难；也就是说，有形地展现最终产品变得更加困难了，而运行使用构想可用于检查确认需求的缺失和冲突。

注意，在A前阶段开发初步概念的工作时，并不需要开发在最终产品上执行的正式验证和确认程序，而只是进行方法上的通查，确保在A前阶段提出的系统构想能够满足利益相关者可能的需求和期望。系统构想的开发应向下延展，直达需要达到的最低层级，以确保系统构想是可行的并且能够将风险降低到满足项目要求的水平。理论上，这个流程可以向下推进到每个系统的元器件层级，但是，这样做将消耗大量的时间和资金。也许只要达到某个比元器件更高的层级，就能够使设计人员准确地判定系统构想在项目中实现的可行性，这正是A前阶段的目的。

在阶段A，系统工程引擎继续递归应用。在本阶段的应用中提取A前阶段开发和确认的系统构想和初步关键需求，将其充实为确定了控制基线的系统需求和运行使用构想集。在本阶段，应当对高风险的关键领域进行建模仿真分析，确保所开发的系统构想和需求是良性的，并明确在随后的阶段中需要使用的验证和确认工具及技术。

在阶段B，系统工程引擎仍被递归应用，来进一步完善将要开发的产品树中所有产品的需求和设计，并且进行系统构想的确认和验证，确保系统设计方案能够满足系统需求。本阶段不仅需要对面向运行使用的设计方案和使命任务场景进行评价，而且需要对设计方案在技术性能和费用方面的可行性进行评估。

阶段C再次使用系统工程引擎图中左侧的系统设计流程，最终更新确定所有的需求，完成运行使用构想验证，开发产品结构树中最低层级产品的详细设计方案并开始制造。

阶段D使用系统工程引擎图中右侧的产品实现流程，递归进行目标产品的设计方案实施、集成、验证和确认，并最终将目标产品交付给用户。

在阶段E和阶段F使用系统工程引擎的技术管理流程，用于监测产品实效、控制产品技术状态，在系统运行使用、工程维护和退役处置方面做出相关决策。现有系统的任何新增能力或能力升级都将作为新项目重新使用系统工程引擎来进行开发。

2.3.1 系统工程引擎详细示例：空间运输系统（航天飞机）

为展示在阶段A如何使用系统工程引擎，这里给出一个详细示例——NASA的空间运输系统（STS）。这个例子将简要说明在系统工程引擎中系统工程流程的应用方式，但并不详细到足以实际建造高度复杂的飞行器。通过系统工程引擎的递归应用，每个步骤都能够获取越来越多的细节。在示例中使用图2.3-1中的图标来标示所使用系统工程引擎中流程的位置。图中的序号与图2.1-1所示的系统工程引擎中的流程标号相对应。这项设计工作一旦成熟，将开发出一个产品分解结构（PBS），用于确定项目需要获取的产品；设计示例同时展示项目最终产品是如何逐步分解为更小部件的。关于产品分解结构的更多信息参见4.3.2.1节。基本上，层级的编号越大，产品在产品分层结构中的层级就越低，而产品信息也就变得更详细（如从机箱细化到电路板，再细化到元器件）。

2.3.2 示例说明

2.3.2.1 A前阶段示例

NASA经过研究确认需要一个空间运输系统，负责像“卡车”一样将大量的设备运送到近地球轨道（LEO）。参考前面所述项目寿命周期划分，该项目首先进入A前阶段。在这个阶段，首先进行若干概念研究，并结合利用建模仿真、工程试样、理论分析及其他类似手段，确定开发这种“空间卡车”是可行的。为简单起见，假设已经通过概念模型证明了此构想的可行性，并且已经开发出初始的系统运行构想，初步明确了与系统有交互关系的人员角色、职责、数量和技能，能够确保全面运行效果。系统工程引擎流程和框架便可应用于这些模型的设计和实现。

随后该项目进入阶段A的活动，完善A前阶段的概念方案并定义所选定方案的系统需求。详细示例从阶段A开始，并且展示系统工程引擎如何运用。正如本节示例导言中所述，类似的流程也应用于项目的其他阶段。需要注意，在阶段A，系统构想和本阶段所花费的时间总长对于完全理解现实中这些构想如何实现非常重要。例如，图2.3-2显示了对航天飞机项目的初步设想及其最终实际效果。吸收参与运行使用的人员作为概念开发团队的成员有助于确定实际的寿命周期需求。

2.3.2.2 阶段A示例：系统设计步骤

1）第一次流程运用

在A前阶段开发出初步系统构想和关键系统需求之后，产品进入系统工程引擎的第1个流程，确定产品（空间运输系统）的利益相关者，以及他们想要的是什么。在A前阶段，这些需求和期望可能是一些非常普通的想法，如“航天飞机的基本任务是将货物运送到近地球轨道并部署在空间站上”。在阶段A的此刻运用系统工程引擎，这些普通想法将被细化并获得一致同意。在A前阶段生成的运行使用构想同样将被细化并获得一致同意，确保所有的利益相关者对于产品（空间运输系统）的真实期望有相同的意见。细化后的利益相关者期望被转化为合规的需求陈述（对应系统工程引擎的第2个流程）；关于如何构成良好的需求陈述，更多信息可参见附录C。例如，该阶段的需求可能是“固体火箭助推器只有在使用完之后才能与轨道飞行器/外部燃料箱正常分离”。本阶段的后续步骤和后续阶段将对需求进行改进，使之符合可实际生产制造的规范。还应注意到，所有的技术管理流程（图2.3-1系统工程引擎中编号为10～17的流程）在当前步骤及后续步骤的活动中也会运用到，确保相应的计划、控制、评估和决策得到使用和维护，确保相互竞争的利益和学科之间达到必要的平衡。这些流程对设计会产生显著影响并可能产生额外的需求（如风险管理、接口控制和人因系统集成活动），因此不能被忽视。尽管为了简化，本示例后续部分不再提及技术管理流程，但它们依然在发挥作用。

接下来，使用前期开发的系统需求和运行使用构想，建立逻辑分解模型/框图（对应系统工程引擎的第3个流程），将需求转变为可视的形式，同时显示它们的关系。最终，这些框图、需求和运行使用构想文档被用来开发一个或多个可行的设计解决方案（对应系统工程引擎的第4个流程）。注意在当前时刻，显然这只是系统工程引擎的第一次运用，所开发的设计解决方案并未详细到足以实际建立任何系统。因此，设计方案可归纳为如下描述：“为实现这个空间运输系统，经过权衡研究，最佳选择是建造一个由三个部分组成的系统：（1）运载航天员和货物的可重用轨道器；（2）大型外部燃料箱；（3）能够为发射提供额外动力的可翻新重用的两个返回式固体火箭助推器。”当然，实际设计方案应该会有更为详细、明确的描述。图2.3-3对此进行了描绘。

所以，经过第一步工作，产品第一层可能看起来类似于图2.3-4。其他配套产品也有可能出现在产品结构树中，但为了简化本示例仅展示主要产品。

同样，这一设计解决方案还未详细到足以建立这些产品的原型或模型的水平。这里的系统需求、运行使用构想、功能图和设计解决方案仍处于非常高的概要层次。注意：图2.3-1中系统工程引擎右侧的系统工程流程（产品实现流程）此时还未涉及。在应用系统工程引擎图中右侧流程之前，设计方案首先要保证系统处在可实际建造、编码或重用的水平上。为此开始第二次执行图2.3-1中的左侧流程。

2）第二次流程运用

系统工程引擎是完全递归的。也就是说，图2.3-4中第1层的四个组件都可以认为自身是一个独立产品，而系统工程引擎可以应用于其中任何一个。例如，将外部燃料箱看作一个目标产品，可以从系统工程引擎第一个流程重新开始。而此时只需关注外部燃料箱，确定利益相关者和他们对外部燃料箱的期望（对应系统工程引擎的第1个流程）。当然，主要利益相关者应包括第1层中需求的提出者和作为目标产品的空间运输系统的拥有者，但也会出现其他新的利益相关者。此时产生了外部燃料箱的需要、目标和目的（NGO），也称目标要求（对应系统工程引擎的第2个流程）。例如，目标要求之一可能是“外部燃料箱为轨道飞行器主发动机存储和提供低温推进剂”，这又引出一个外部燃料箱如何运转的新的运行使用构想。第1层应用到（分配给）外部燃料箱的需求将继续“向下分解”并需得到确认。通常，其中某些需求过于笼统而不能设计实现，必须再次进行分解和分配。在这些派生的需求基础上，还需加上来自利益相关者期望的新的需求，以及技能、安全、质量、可维护性、地面加工处理等方面的应用标准。

随后，明确外部燃料箱的需求和运行使用构想，开发出产品功能框图（对应系统工程引擎的第3个流程），这点与第一次递归运用中的空间运输系统相同。最终，这些框图、需求和运行使用构想文档被用于开发外部燃料箱的可行设计方案（对应系统工程引擎的第4个流程）。在这一步中，同样没有足够的细节来真正建造外部燃料箱或建立其原型。此时的设计方案可以概括为“为建造此外部燃料箱，权衡研究结果表明，最佳选择是使用低温推进剂，需要两个燃料箱用于盛放液氢和液氧，需要铝制外部结构安装燃料箱及相关仪器设备，外部结构需覆盖泡沫材料。”这样，面向外部燃料箱的第2层产品树可能如图2.3-5所示。

按照类似的方式，轨道器也将进行系统工程引擎的第二次递归运用，确定利益相关者和他们的期望，开发目标要求，并为轨道飞行器生成运行使用构想。一个轨道器目标要求的例子可能是“轨道飞行器需要最多能运送65000磅货物到近地球轨道”。适合轨道器的第一层需求将被“向下分解”和确认；由此派生的新需求和附加要求（包括与其他组件的接口）将被添加到需求集。对于轨道飞行器，一个可能的附加或派生需求是“轨道舱需要最多能容纳7名航天员”。

随后，根据轨道器的需求和运行使用构想开发功能框图，生成一个或多个轨道器设计方案。与外部燃料箱一样，在这一步中不会有足够的细节真正建造轨道器或建立轨道器的复杂模型。轨道飞行器设计方案可归纳为“为建立此轨道飞行器将需要一个有翼飞行器，配备热防护系统、飞航电子系统、指挥/导航和控制系统、推进系统和环境控制系统等。”因此，轨道器组件的第2层产品树可能如图2.3-6所示。

同样，固体火箭助推器也可以被看作目标产品，并像针对外部燃料箱与轨道飞行器所做的那样，通过系统工程引擎的运用产生一个第2层的设计方案。

3）第三次流程运用

第2层中的每个组件又可被认为是目标产品，并且进行系统工程引擎的再一次递归运用，确定利益相关者，产生运行使用构想，向下分配需求，产生新的需求和派生的需求，开发功能图表和设计解决方案。以飞航电子系统为例，第3级产品树可能如图2.3-7所示。

4）第四次直到第n次流程运用

递归运用针对各层级上每个产品（模型）持续进行，直到产品树的底层，形成阶段A的所有递归运用过程。注意：某些项目中，当给定成本和进度限制时，在阶段A中递归实施相应流程直到最小组件可能并不现实。所需要做的只是判断在进行需求分解时，只要系统设计在本层级的、与费用、技术和进度相关的一阶n维权衡空间中收敛，便可以停止需求向下分解。这往往不是靠直觉的，这需要具备经验知道什么时候在恰当的层级停止。

在这种情况下，必须根据工程技术经验判断可行的产品层级。需要注意的是，根据产品的复杂性，可行的最低层级可能有所不同。例如，对于某个产品可能会递归到第2层，而对于更复杂的产品，可能递归到第8层。这也意味着产品树上的不同分支达到最低层需要不同的时间。因此，对于确定的工程或项目，产品可能需要在不同层级和阶段开发。对于本例的阶段A，图2.3-8给出完全通过系统工程引擎的系统设计流程而得到的空间运输系统产品层级图。完成这么多次递归后，产品树中的每个产品都有了相应的系统需求、运行使用构想，系统也生成了顶层的概念架构、功能架构和物理架构。注意：这些只是对目标产品的初步设计，尚没有进行细化。细化需要在系统寿命周期后期完成。至此，足够的概念化设计工作已经完成，至少确保在后续的递归运用过程中高风险的需求能够达到。

2.3.2.3 阶段A示例：产品实现步骤

在阶段A中完成主要产品的需求开发和概念设计之后，需要对产品进行检查以确保它们是可以实现的。需注意的有两类产品，第一类产品是将实际交付给最终用户的“目标产品”；第二类产品称为“阶段产品”。阶段产品是在特殊的寿命周期阶段产生的，是项目推进和最终产品开发所必要的。例如，在A前阶段，所建立的模型可能是个内充泡沫的物理样机，或是个非实材的制造模型，或是个交互式计算机模型；制造这些模型的目的是帮助某些概念的形象化。这些原理模型不是“最终目标产品”，而是“阶段产品”。对于阶段A中的示例，可能需要建立关键概念的计算机模型进行仿真，以证明产品是可以实现的。这些模型就是示例中的阶段产品。

现在的重点转移到系统工程引擎右侧的流程，即产品实现流程，这是从产品的最低层开始的向上递归应用。

1）第一次流程运用

产品树中，每个底层（图2.3-8中无阴影部分）的阶段产品（如前面提到的计算机模型）都是独立实现的（可以购买、建造、编码或重用，对应系统工程引擎的第5个流程）。在本例中，假设外部燃料箱产品模型Aa是购买现货产品；产品Aba重用其他项目的模型，而产品Abb是一个必须在组织内部设计和开发的模型。需注意的是，这些模型是在系统工程引擎后续步骤中需要组装和集成到更大模型产品的组成部分。也就是说，为了实现外部燃料箱中产品Ab的模型，需要首先建立产品Aba和Abb的模型，然后进行集成。这一过程反映了系统工程引擎的实现部分。同样，其他无阴影的底层模型产品也在这一次递归运用中实现。这些模型将有助于系统工程实践者了解和计划实现目标产品的方法，并确保实施方法的可行性。

随后，每个实现的底层模型（阶段产品）被用于验证目标产品能否满足产品需求（对应系统工程引擎的第7个流程），这些需求是在2.3.2.2节的产品系统设计流程递归运用环节中通过实施技术需求开发流程而明确的。这表明通过产品试验、定量分析、外观检视和功能演示，该产品被证明能够满足所分配、派生或自生的“需要”陈述，即产品能够被“正确制造”。每个无阴影底层模型产品都需要验证。注意，在阶段A的递归运用中，所做的并不是目标产品的正式验证。不过，使用分析、仿真、模型或其他手段能够证明需求是否合理（可验证），以及证明概念设计满足需求的程度。这里还允许开发关键领域的验证技术规程草案。当然，需要进行正式验证的是阶段产品（模型）能否满足模型的需求。

在完成阶段产品（模型）验证，并在此基础上制定完成目标产品的验证计划后，模型需要进行确认（对应系统工程引擎的第8个流程）。也就是说，执行附加的产品试验、定量分析、外观检视或功能演示，以确保阶段产品和目标产品的概念化设计将有可能满足利益相关者的期望。这将回溯到前面所述产品系统设计流程递归运用中的运行使用构想，运行使用构想是在实施利益相关者期望开发流程中通过与利益相关者协商获得的。模型确认有助于确保在这一层级上项目“建造正确”产品。

在完成阶段产品（模型）验证和确认，并据此制定完成目标产品验证和确认计划之后，便可着手准备把模型提交到上一层级（对应系统工程引擎的第9个流程）。根据模型提交过程的复杂性和安全性需求等，提交形式包括装箱货运、网络传输或随身携带到上一层级的试验室。只要可能，每个底层产品模型都应做好准备工作并提交到上一层级进行集成。

2）第二次流程运用

目前，所有底层目标产品的模型（阶段产品）已经被实现、验证、确认和交付，可以开始将它们集成到上一层产品中（对应系统工程引擎的第6个流程）。以外部燃料箱为例，在第4层实现的产品Aba和Abb的模型可以集成为第3层产品Ab的模型。注意产品实现流程只是在底层的产品发生过。在产品集成中，系统工程引擎将再次递归运用，后续各个层级也是如此，通过递归运用系统工程引擎中的产品集成流程，把已实现的产品集成为新的上一层级产品。集成低一层级的阶段产品将产生较高一层级的阶段产品。这种集成流程也可用于实现顶层目标产品的集成。

较高层级的新的阶段产品（模型）集成后（如形成第3级产品Ab），必须证明该层级新产品满足所分配、派生或自生的需求（对应系统工程引擎的第7个流程）。对于这个集成产品模型来说，应当满足在前述系统设计递归运用中由技术需求开发流程确定的需求，包括分配需求、派生需求和自生需求，确保集成产品的正确制造（组装）。要注意，仅验证集成过程中的组件部分（即单个模型）不足以认定集成后的产品能够正常运行。这样可能会引发各方面的问题，如接口方面的需求不完整、设计期间的错误假设等。确定集成产品完好的唯一方法是在每个层级实施验证和确认活动。验证集成阶段产品所获得的知识也可用于制定最终顶层产品的验证计划。

同样，在完成集成阶段产品的验证后，需要确认其能够满足运行使用构想文件中所明确的对该层级产品模型的期望（对应系统工程引擎的第8个流程）。即使此时构成集成产品的组件部分已经通过确认，也必须对集成产品自身的进行确认，如此才能保证项目建造了“正确”的集成产品。这里的确认信息同样将有助于制定最终顶层产品的确认活动计划。

当前层级的集成阶段产品模型（如第3层产品Ab）已准备好提交到上一层级（本示例中为第2层）。与第一次递归运用中的产品相同，集成阶段产品已根据其需求/要求做好准备并运送或提交（对应系统工程引擎的第9个流程）。在本示例中，外部燃料箱的第3层集成产品Ab的模型被提交到第2层产品A的模型所有者手中。这个阶段的产品移交工作有助于制定最终顶层产品的交付活动计划。

3）第三次直到第n次流程运用

与第二次递归运用的方法类似，第3层产品模型经过集成、实现、验证、确认，完成到上一层级的移交。在本示例中，外部燃料箱第3层集成阶段实现的产品Ab和Aa的模型，经过集成形成第2层阶段产品A。需注意，第3层产品Aa是最低层产品，之前没有经历产品集成流程。它可能在某个较早时刻已经实现，等待着产品Ab的实现。完成移交的产品Aa可能已经安全存储，直到产品Ab可用；也可能Aa的获取需花费较长时间而Ab在某个较早时刻已经完成，并等待购买的Aa到达从而共同完成集成。产品树分支的长度不必转换为相应的时间长度。这就是为什么在项目最早阶段做出良好规划如此关键的原因。

4）最终的流程运用

在某个时刻，所有第一层级阶段产品的模型都将分别被用于确保阶段A中提出的系统需求和构想能够得以实施、集成、验证、确认和交付。本示例中，第一层单元被定义为外部燃料箱、轨道飞行器和固体火箭助推器。通过系统工程引擎的前一次递归运用，已经显示这些单元能够成功地实现、集成、验证和确认。这些产品最终将以系统需求、运行使用构想、概念化功能设计和物理设计的控制基线形式进入寿命周期的阶段B，并得以进一步完善。在后续的阶段中，这些产品将真正以实物形式实现。在项目各个阶段中，每个产品的主要特征都将通过关键系统工程文档传承下去。

2.3.2.4 系统工程引擎在阶段B到阶段D的运用示例

阶段B开始进行目标产品的初步设计。系统工程引擎的递归步骤以类似阶段A中详细讨论的方式来重复执行。在这个阶段，阶段产品可能是该产品的原型。开发原型的目的是通过有计划的验证和确认流程来确保在最终航天飞行器建造之前，设计方案能接近满足所有的需求和期望。相比于在航天飞行器实际建造和进行合格检验时找到错误并更正，在原型中找到各类错误并做出更正要更加容易且花费更少。原型包括但不限于物理样机、交互式人因集成计算机模型和非真实材料制造的模型（或测试组件）。

与前面几个阶段以分析、构想和原型的方式研究目标产品有所不同，阶段C和阶段D直接针对目标产品开展工作。在阶段C中，递归运用系统工程引擎的左侧流程进行详细设计。在阶段D中，递归运用系统工程引擎右侧流程最终实现产品，并进行正式验证和确认。在阶段D完成系统工程引擎的最后一步递归运用之后，得到完整实现的目标产品——空间运输系统，并可随时交付发射使用。用于保障的基础设施（如发射设施、任务控制系统、通信中继和经过培训的地面操作人员）也被交付。

2.3.2.5 系统工程引擎在阶段E到阶段F的运用示例

即使在寿命周期的阶段E（使用和维护阶段）和阶段F（退役废弃/处置阶段），继续进行良好的系统工程实践和运用系统工程引擎也极度重要，系统工程引擎的技术管理流程也仍在使用。在项目的运行使用阶段，多数活动仍在进行中。除了监控产品的日常使用，还有必要监督或管理系统的各个方面。早期开发阶段提出的关键技术性能指标在这里继续发挥作用（技术性能指标在第6.7.2节进行描述）。这些重要的监测指标能确保产品按照设计方案和预期运行。系统技术状态仍在控制范围内，技术状态管理流程仍在执行，仍然在通过决策分析流程进行决策。事实上，所有技术管理流程仍在应用中。

在本例的讨论中，术语“系统管理”专指系统运行使用过程中的技术管理方面。系统管理包括系统日常运行使用的监控、感知并处理发生的异常，以及发现并处理与系统相关的其他技术问题。

除系统管理和系统运行使用外，还可能需要系统或部件的定期翻新、修理、清洁、清理、配送或其他相关活动。此时，使用术语“维护工程”表示上述活动。

同样，所有技术管理流程仍然适用于这些活动。图2.3-9表示这三个活动在最终产品的运行使用周期内同时发生和连续发生的模型。系统工程流程中的某些部分需要不断进行，甚至在系统不再运行而停用、退役和处置后仍在进行。这符合系统工程“自始至终”掌控系统全寿命周期的基本原则。

然而，如果在本阶段开发新产品，或需要做出影响产品设计和验证的变更，或需要对现有产品进行升级，系统工程引擎中的产品开发流程就需要从头开始。也就是说，产品升级需要做的第一件事还是确定利益相关者和他们的期望。完整的系统工程引擎仅用于新产品开发，如图2.3-10所示。需注意，虽然在图中系统工程引擎只显示一次，但对升级产品却是按产品层次递归调用的，如同前面产品示例详细说明所描述的那样。