下载掌阅APP，畅读海量书库
立即打开
设计方案开发流程的作用是把来自利益相关者期望的高层需求和逻辑分解流程输出的派生需求转化为满足需求的系统设计方案，或者说是把已经确定的层次化系统逻辑分解模型及其相应的系统派生技术需求转换为系统备选方案。通过对这些备选方案进行详细的权衡研究分析，可以选定首选的备选方案。选定的备选方案被完整、明确地定义为一个满足系统技术需求的最终设计方案。设计方案开发流程将用于生成目标产品的技术规范，据此生产产品和进行产品验证。根据目标产品是否有需要开发设计方案的子系统，设计方案开发流程可能需要做进一步细化。
图4.4-1所示是设计方案开发流程的典型流程框图，图中给出在设计方案开发流程中需考虑的典型输入、输出和活动。
图4.4-1 设计方案开发流程的典型流程框图
启动设计方案开发流程时，所需的基本输入包括如下内容。
● 技术需求 ：指客户和利益相关者的需要，该需要已经转化为经过确认的合理且完整的系统需求，包括所有接口需求。
● 逻辑分解模型 ：采用一种或多种不同的（如基于功能的、基于时间的、基于行为的、基于数据流的、基于状态的、基于模式的、基于系统架构的等）方法对系统需求进行分析和分解，以便于能够得到对系统接口和行为更容易的综合理解（参见本手册附录B中术语“模型”的定义）。
1.明确备选的设计方案
系统的实现跨越其整个寿命周期，其中涉及一系列在备选的实施方案之间的决策。如果备选方案能够被精确地定义和完全理解，则能够在成本-效能空间上进行有效区分，从而系统工程师能够自信地在这些备选方案中做出选择。
为了得到足够可信的便于做出良好决策的评估结果，通常需要对可能的设计方案空间进行更深入的研究，如图4.4-2所示。然而应该认识到，这个图中表述的既不是项目从概念探索到退役处置全寿命周期中所包含的所有系统开发流程，也不是系统设计方案开发和实施所依赖的产品开发流程。
图4.4-2 持续细化的理论
图4.4-2中“产生构思”步骤的多次实施是一个由利益相关者期望驱动的递归和迭代的循环设计过程。在此设计过程中开发出系统架构/设计草案、相关的运行使用构想和派生的技术需求。该设计过程还需要考虑诸如费用和进度这样的工程性约束条件。设计过程的上述三个产品应当是相互一致的，这种一致性需要经过反复的设计决策。这个迭代和递归设计循环如图4.0-1所示。
每次实施图4.4-2中“产生构思”的步骤还需要对技术持续发展所产生的潜在能力进行评估，以及对潜在缺陷进行评估，这些潜在缺陷来自于针对以往工程/项目中取得的经验教训进行的基于经验的评审。极为重要的是，在技术开发流程、设计流程和诸如人因系统集成的相关流程之间应保持持续交互，从而确保设计方案反映可用技术的现实性，并确保避免对不成熟技术的过度依赖。此外，对任何可能应用的技术应当进行适当的状态监控，且应当关注并适时评估技术进步对构思效果的影响。通过在所需要的技术成熟度方面对设计方案进行定期评估，可以促进前面所述流程之间的交互，参见4.4.2.1节对技术评估更细致的讨论。这些技术单元通常存在于产品分解结构的较低层级。尽管通过集成较低层级单元进行系统开发的设计构思流程是系统工程流程的一部分，但总是存在自顶向下的流程不能同自底向上流程保持一致的危险。因此，系统架构的问题需要在早期解决，这样系统才能够通过充足的实际数据建立模型并进行可信赖的权衡研究。
随着系统设计方案的实施，系统特征也变得更加清晰，但也就更难改变。参见图2.5-3中“改变设计思路的代价”所表现的上升趋势。系统工程的目的是，确保设计方案开发流程采用的方式能够在给定的进度约束条件下，引导实现功能最佳、安全性最佳和效益最佳的系统。基本思想是在做出很难撤销的决策之前，应当对备选方案反复进行细致的评估，特别是考虑所需技术的成熟度及利益相关者在高效有益的运行使用方面的期望。
2.生成备选方案设计构思
一旦理解了要实现的是何种系统，就可以采取多种各不相同的方式来实现这些目标。有些时候，接下来需要考虑备选方案的功能分配，以及考虑集成可用的子系统设计选项，所有这些都涉及成熟度各不相同的技术。理想情况下，针对在不断细化的流程中当前所处的阶段位置，以及在保证与设计组织的工作性质相一致的前提下，可能需要明确尽可能合理的备选方案范围。当实施自底向上的流程时，系统工程师所面临的一个问题就是设计人员都趋于欣赏他们自己创造的设计方案，从而丧失客观性。系统工程师则应当保持“局外人”角色，以保证更为客观。在系统设计实现过程中进行必要的子系统和组件技术成熟度评估时，这一点尤为重要。对部分技术开发者和项目管理层来说有个趋势，即可能过高估计实施设计方案所需技术的成熟度和可用性，而对于既有设备尤其如此。结果就是系统工程的某些关键环节经常被忽视。
图4.4-2所示的持续细化的第一轮中，主体通常是一般的方法或策略，有时是系统的架构构想。接下来的一轮是功能设计，再下一轮是详细设计，如此下去。因为目的是发现真正的最佳设计方案，故应避免不成熟地关注单轮设计。系统工程师的一部分工作就是确保参与比较的设计构思已经考虑所有的接口需求。典型的问题包括：“你是否考虑了布线？”或“你是否考虑了如何使维修人员能够修理系统？”在可能的情况下，每个设计构思应通过可控设计参数进行描述，并使得每个设计构思尽可能合理地代表更多的设计类别。此刻，系统工程师应谨记潜在的变更可能涉及组织结构、人员约束、进度安排、技术规程，以及任何其他可作为系统组成部分的事项。如果可能，约束条件也应该用参数描述。
3.分析每个备选设计方案
技术团队负责（定量或非定量）分析每个备选设计方案（在技术缺陷、效能、技术可达性、性能、成本、进度、风险等方面）满足系统目标的程度。这项评估通过应用权衡研究来完成。实施权衡研究流程的目的是确保系统架构、运行使用意图（运行使用构想）和设计决策在可用资源限制条件下达成最好的设计方案。这个流程包括如下基本步骤。
（1）寻求备选的设计路线以满足系统功能需求。在项目寿命周期的早期阶段，该设计路线集中于系统架构；在后期阶段，集中于系统设计方案。
（2）按照效能指标和系统寿命周期费用对这些备选方案进行评价。这一步骤中数学模型很有用，不仅体现在辨明输出变量之间的关系方面，而且还体现在帮助决定哪些性能指标应该量化方面。
（3）按照适当的选择标准对备选方案排序。
（4）剔除不良备选方案，如果需要可推进到下一层级进行分析。
权衡研究流程应当开放和包容地完成。即使是使用定量技术和规则，主观性同样起着重要作用。为了使流程有效地工作，参与研究的人员应当思想开放，而且有不同技能的个人，包括系统工程师、设计工程师、相关专业学科和领域工程师、计划分析师、系统最终用户、决策科学家、系统维护人员、系统运行使用人员和项目负责人等应当相互合作。应当运用正确的定量方法和选择标准。权衡研究的前提假设、分析模型和结果应当作为项目档案资料的一部分记录存档。参与研究的人员应当时刻关注功能需求，包括配套产品的需求。关于权衡研究流程的深入讨论参见6.8节。实施权衡研究的能力可以通过开发与评价设计参数的相关系统模型得以提高，当然这个能力不依赖于模型。
开发系统模型时，技术团队应当考虑广泛的设计构思。模型应当描述系统中的运行使用人员、维护人员、后勤人员、硬件和软件的作用。模型应当确定为完成使命任务所需要的关键技术，应当考虑从生产制造到退役处置的整个寿命周期，应当建立选择设计构思的评价标准。成本必定是限制性因素，然而其他标准，如开发和认证基础构件所需要的时间，以及风险和可靠性也非常关键。不考虑操作人员和维护人员的作用，模型开发就不能完成。评价标准对整个寿命周期费用及系统可靠性是非常重要的因素。可靠性分析需要基于对硬件组件故障率的估计和对故障后果的理解进行。如果运用风险概率评估模型，则软件故障或人为操作失误的发生概率就很有必要包括进来。这些模型应当包括通过故障管理实现的危害性分析和控制。应当完成对所需技术成熟度的评估，并且需要制定出技术开发计划。
设计构思的开发和修正应当可控，系统模型的开发也应当可控，通常允许运用最优化技术来探索能够保证实施进一步观察的设计空间。
不管是否会用到系统模型，为进一步的系统开发寻求最好的选择是一个闭合的循环过程，设计构思在这个循环过程中开发、改进、再评估，并与竞争的备选方案做比较。系统和子系统的规模通常在权衡研究中确定。最终结果是确定备选设计方案相对费效比的范围，使用量化的系统目标进行度量。因为刻意回避决定设计方案的最终细节，从而只可能获得效费比的范围，却得不到最终价值。随着不断改进的方案中相关细节的增加，流程推进时便缩小了这个范围上界和下界之间的距离。
4.选择最佳的备选设计方案
技术团队从备选的设计构思中选择最佳的设计方案，需要考虑团队无法进行定量化的主观因素，例如，对备选方案满足定量需求程度的预估、可用技术的成熟度，此外还要考虑方案的鲁棒性、效能、成本、进度、风险和其他约束条件。
应当采用决策分析流程，如6.8节所述，对备选设计构思进行评估，并且要推荐出最佳的设计解决方案。
如果可能，应开发出所谓“目标函数”的数学表达式，这样做虽然困难但很值得，因为它把可能结果的综合值表述为一个单指标量：费效比，如图4.4-3所示。即使在费用和效能两项指标可能需要用多个指标量来描述的情况下也要尽量这么做。
目标函数（或称作费用函数）在备选方案空间或“搜索空间”中为备选方案或“可行方案”赋一个实数值。能够使目标函数最小化（有些情况下是目标最大化）的可行解决方案就是“最优方案”。当能否达到目标的判据可以用此类目标函数量化表达时，设计方案就可以按照它们的相应量值进行比较。伴随设计构思而存在的风险可能会使这些评价有些模糊，因为这些风险是不确定的。风险最好用概率分布描述。
注：不同的阴影区域表示不同水平的不确定性。虚线代表目标函数（费效比）为常数。通过向左上方移动可以得到更高的费效比。A、B和C分别代表不同风险类型下的设计构思。
图4.4-3 定量目标函数，依赖于寿命周期费用和效能的所有方面
在图4.4-3中，设计构思A的风险相对大些。设计构思B中效能或费用的风险都很小，而设计构思C有高代价失败的风险，如图中接近坐标横轴的概率云团表示费用高且几乎没有效能。进度因素可能影响效能值和成本值，并影响风险的分布。
各类系统使命任务成功的判断准则有极大不同。在某些情况下，效能指标可能比其他指标更重要，而另外一些项目可能需要低成本、不可更改的进度表，或要求某类风险最小化。产生关联着所有重要因素的组合量化指标的可能性很小（如果有），即使它可以表述为若干组分合成的矢量。就算能做到如此，重要的是彻底发现那些潜在因素及其影响关系，并且被系统工程师所理解。系统工程师应当像对量化数据所做的那样，为那些无法量化因素的重要性赋予权重。
基于数据和分析的技术评审，包括技术成熟度评估，是为技术团队准备决策支持材料中的重要组成部分。所做出的决策通常在出现系统控制基线变更或细化的情况下进入技术状态管理系统。支撑决策的权衡研究结果被存档以备将来使用。系统工程流程的一个基本特征是，在做出决策之前进行权衡研究，这样它们的控制基线能更准确地确定下来。
5.提高设计方案的分辨率
图4.4-2所示的持续细化理论描绘了系统设计方案的不断细化。在分解进行到每个层级时，已确定控制基线的派生需求（和分配需求）转变为一组针对本层级单元的高层需求，然后重新启动流程向下层分解。可能有人会问，“我们应该何时终止设计方案的细化？”答案是设计工作要推进到足够深度，以满足某些需要。例如，设计流程要充分深入以允许对设计方案是否满足需求和运行使用构想进行辨析确认，设计流程同样要有充分的深度以支持费用建模和运行使用过程建模，并能在性能、成本和风险方面就设计方案的可行性说服评审专家。
随着系统的开发，系统工程引擎不断地重复运用，以及随着系统的实现，考虑的问题和相关活动的特点有可能都会改变。大多数大型工程/项目的系统决策（目标、架构、可接受的寿命周期费用等）在项目的早期阶段就完成了，接下来的细化并不精确地对应系统寿命周期的各个阶段。许多系统架构实际上在开始时便能够看清，因此随后的细化并不一定精确地对应于架构层级的开发。细化工作更有可能体现在对系统进行更高分辨率的定义上。
随着时间推进，期望能够在更高分辨率上明确系统是合理的。这个趋势在（阶段B）某个时间点上通过明确系统定义并设定控制基线而得到固化。通常情况下，目的、目标和约束条件被看作控制基线的需求部分，从而完整的控制基线便处在技术状态控制之下，旨在能够确保任何后续变更确实是正当的且是可承受的。
在系统工程流程的这个时间点上有个逻辑分支点。对于推进了足够远的后续细化流程所碰到的问题，下一步是在当时相应的分辨率层级进行决策。对于那些仍不能充分解决的问题，需要做进一步的细化开发。
6.完整描述设计方案
一旦选定了合意的备选设计方案且完成了适当层级的细化，则设计方案被完全确定，成为满足系统技术需求和运行使用构想的最终设计解决方案。所明确的设计方案将用于目标产品技术规范的生成，该技术规范可用于生产产品和进行产品验证。如果目标产品有相应的子系统需要确定设计方案，则设计流程可能需要进一步细化。
对于完整的系统设计方案描述，其范围和内容应当适合于目标产品寿命周期的各个阶段、阶段成功评判准则及目标产品在系统产品分解结构中的位置。依赖于这些因素，设计方案的形式可以简化为一个仿真模型或书面研究报告。技术数据资料随着阶段推进而丰富，从概念草图或模型开始，到形成完整的图样、部件清单及产品生产或集成所需要的其他细节时结束。设计方案开发流程的典型输出如图4.4-1所示，且在4.4.1.3节中将做明确描述。
7.设计方案的验证
一旦从多个备选设计方案中选定可接受的设计方案且在技术数据资料中进行记录，接下来就应当根据系统需求和约束条件完成对设计方案的验证。进行验证的方法可以是通过同行评审来评价所选定的设计方案。如何进行同行评审将在6.7.2.5.6节讨论。
此外，同行评审作为高层级技术性和工程性评审的组成部分，在进行详细技术评审中起重要作用。例如，对电池组件设计方案的同行评审与对集成的能源子系统的评审相比，可能需要探究关于电池的更多技术细节。同行评审能够覆盖从子系统组件层级向下，直到能够根据需求对设计方案进行验证的相应层级。同行评审所关心的问题，可能涉及能源子系统的设计和验证方面，因而应当向能源子系统的更高层级提交评审报告。
通过验证应表明，设计方案开发流程能做到如下几点。
●在技术工作的约束条件下能够完成设计。
●有详细的以可接受的方式表达的需求陈述，在技术需求和利益相关者期望之间存在双向可追溯性。
●形成解决方案时所做出决策的客观依据和前提假设遵从相应的技术需求集和已明确的系统产品与服务的约束条件。
设计方案的验证和目标产品的验证形成对照，后者在技术数据资料中用目标产品验证计划描述。目标产品的验证发生在寿命周期的后期阶段，是产品验证流程（参见5.3节）的结果，运用在目标产品设计方案实现流程中。
8.设计方案的确认
设计方案的确认是个迭代和递归的过程，如图4.0-1所示。每个备选设计构思的确认都根据利益相关者的期望进行。利益相关者的期望引导设计流程的循环迭代，据此开发出系统架构/设计草案、运行使用构想和派生需求。这三个产品之间应当保持相互一致性，这种一致性需要通过反复迭代和设计决策才能达到。一旦达到一致性要求，研究团队可以采用功能分析方法根据利益相关者期望对设计方案进行确认。一个简化的确认过程是询问如下问题：系统能否像所期望的那样运行？系统出现故障、失效和异常该如何响应？系统费用能否承受？如果任何一个问题的答案是否定的，则需要变更设计方案或变更利益相关者期望，流程就要重新开始。确认流程持续进行，直到系统的架构、运行使用构想和需求都满足利益相关者的期望。
设计方案的确认与目标产品的确认形成对照，后者在技术数据资料中用目标产品确认计划描述。目标产品的确认发生在寿命周期的后期阶段，是产品确认流程（参见5.4节）的结果，运用在目标产品设计方案实现流程中。
9.明确配套产品
配套产品包括为系统全寿命周期（如生产、试验、部署、培训、维护和处置）提供支持保障的产品和服务，能够促进可运行使用的目标产品在全寿命周期中的开发进展和运行使用。目标产品及其配套产品是相互依赖的，可以看成是同一个系统。项目的职责在此延展到在寿命周期的每个阶段从相关的配套产品获取服务。当合适的配套产品尚不存在时，对目标产品负责的项目同样要对制造和使用配套产品负责。
因此，在设计方案开发流程中一个重要的活动就是根据选定的设计方案确定在其寿命周期中需要的配套产品和人员，促成这些配套产品的获取或开发。配套产品需要使用的日期应当实际标注在项目进度表中，并允许适当的进度延迟。同时规定的义务应当以合同、协议、运行使用计划等形式确定下来，以确保配套产品在需要其对产品寿命周期各阶段中的活动提供支持时是可用且有效的。对配套产品的需求应当作为设计方案开发流程中技术数据资料的一部分记录归档。
密闭环境试验箱便是配套产品的例子，在空间飞行系统试验阶段的某个时候可能需要使用到。专门的试验装置或专门的机械操作装置也可以看作配套产品的例子，它们可能必须由项目自行制造。由于开发时间很长及订购的设施过多，明确配套产品并确保尽可能在设计阶段早期确定这些配套产品的作用和职责是非常重要的。
10.设定设计方案控制基线
正如图4.0-1所示，一旦选定的系统设计方案满足利益相关者期望，研究团队便可设定产品控制基线，并准备进入产品寿命周期的下一阶段。由于设计细化工作的递归特性，作为流程的一部分，产品分解的中间各层级通常需要进行确认和设定控制基线。在向下层的分解中，设定控制基线的需求转变为一组待分解的高层单元的需求，流程重新开始。
为指定的设计方案设定控制基线，能够使技术团队在所有备选设计构思中专注于单个方案。这是设计流程的关键点。它相当于建立了一个基础，使设计团队中每个人都关注同一构思。当处理复杂系统时，如果系统设计目标改变，会造成团队成员在完成所负责的系统设计部分时面临困难。设定控制基线的设计方案应当归档并置于技术状态控制之下，其中包括系统需求、设计规范和技术状态描述。
即使设定设计方案的控制基线对设计流程有益，也还是存在其在设计方案开发流程中运用过早的危险。备选设计方案的早期探索应该是自由的和开放的，并包容广泛的思路、概念和方法。控制基线设定过早，概念探索就可能会降低创造性。因此，设定控制基线应该是设计方案开发流程的最后一个步骤。
设计方案开发流程的输出包括提交到产品实现和运用阶段中产品实现流程的设计规范和计划，包括产品如何设计、如何建造、如何培训和如何编码的相关文件，这些文件遵从系统被批准的控制基线。
如前面所述，完整设计方案描述的范围和内容应当适合产品寿命周期的各个阶段，服从阶段成功评判准则和产品在产品分解结构中的位置。
设计方案开发流程的输出包括如下内容。
● 系统设计规范 ：系统设计规范包括作为设计方案开发流程结果的系统功能控制基线。系统设计规范为设计工程师开展系统设计工作提供充分的指南、约束条件和系统需求。
● 系统外部接口规范 ：系统外部接口规范描述系统与外部世界之间所有物理接口上相应行为和特征的功能控制基线。这些接口包括所有结构接口、热交换接口、电路接口、信号接口及人机系统接口。
● 目标产品技术规范 ：目标产品技术规范包括目标产品如何建造和如何编码的详细需求。技术规范是对设计细节详细而准确的表述，如规定原料和尺寸，以及建造或组装目标产品工作的质量要求等表述。
● 目标产品接口规范 ：目标产品接口规范包括目标产品与外部单元之间的所有逻辑接口和物理接口（包括人机接口）在其相关行为和特性方面如何构建和如何编码的需求。
● 子系统初始技术规范 ：与目标产品子系统相应的初始技术规范。在需要时提供关于子系统的详细设计信息。
● 配套产品需求 ：与配套产品相应的需求。其能够提供所有配套产品的细节。配套产品是为产品寿命周期提供支持保障的产品、基础设施、人员、后勤和服务，可促进相应可运行使用的目标产品在其寿命周期的开发进展和运行使用。它们被认为是系统的一部分，因为目标产品及其配套产品是相互依赖的。
● 产品验证计划 ：目标产品的（通过技术规划流程生成的）验证计划，针对目标产品全部验证活动的完整可视性，提供所需的内容和详细程度。根据目标产品的范围，该验证计划包含针对空间飞行器硬件和软件的鉴定、验收、发射前、运行使用和退役处置等相关验证活动。
● 产品确认计划 ：目标产品的（通过技术规划流程生成的）确认计划，根据设定控制基线的利益相关者期望，针对目标产品开展全部确认活动的完整可视性，提供所需的内容和详细程度。该确认计划包括确认的类型、确认的技术规程，以及适合于证实已实现目标产品符合利益相关者期望的确认环境。
● 后勤保障和运行使用技术规程 ：可行的系统后勤保障和运行使用技术规程描述特定设计方案在控制、运输、维护、长期储存和运行使用方面需考虑的事项。
流程的其他输出可能包括：
人因系统集成计划 ：系统的人因系统集成计划应当更新，说明在系统全寿命周期的部署和运行使用中所需人员的数量、技能和成长（培训）等方面的内容。
正如在4.4.1节的流程描述中所提到的，备选设计方案的生成，涉及对状态不断变化的技术进展所提供的潜在能力的评估。在技术开发流程和设计方案开发流程之间保持持续交互可以确保设计方案反映可用技术的现实性。通过在所需要的技术成熟度方面对设计方案进行周期性评估，可以促进两个流程之间的交互。
对于特定的设计构思，在明确其中的技术缺口之后，通常有必要采取技术开发措施以确保设计的可行性。一般情况下资源总是有限的，所以有必要追求实现最有希望的技术以满足特定设计构思的需要。
如果没有能够完整地理解完成技术开发所需要的资源，而又在此情况下确定了系统需求，那么工程/项目就处于风险之中。技术评估应当反复进行，直到技术需求和可用资源都处于可接受的风险范围之内。技术开发在工程/项目的寿命周期内所起到的作用远比传统上想象的更大，而系统工程师的职责是帮助加深对工程/项目更广阔影响的理解，使得效益最大化和负面作用最小化。在传统意义上，从工程/项目的角度看，技术开发总与那些为了满足系统需求而需要开展的“新”技术开发和技术引入相关。然而，对既有系统进行改进而可能形成不同的系统架构，系统的运行使用环境可能与设计方案中原定的环境不同，这些情况却经常被忽视。如果所需要的系统改进和/或使用环境变化超出已有的经验范畴，这种情况下同样应该慎重考虑是否应当进行技术开发。
为了达到了解是否需要进行技术开发的目的，进而能够量化相应的费用、进度和风险，有必要按照系统架构和使用环境对每个系统、子系统或组件的成熟度进行系统性评估。这样就有必要评估需要开发什么和使用什么开发方式才能够将成熟度提升到相应水平，如此才能够顺利地与费用、进度及性能等约束条件相适应。完成这项评估的流程在本手册附录G中描述。因为技术开发对工程/项目有潜在的显著影响，技术评估的作用需要贯穿系统设计和开发流程，包括从概念开发到初步设计评审流程。因此，应当在工程的最后阶段开展并完成从技术开发的角度总结经验教训这项工作。
就像处理硬件/软件技术一样，复杂系统中必要的人因组分（运行使用人员、维护人员等）应该在系统工程流程实施期间根据相应的期望值对其做出评估。如果对人因要素期望得太多或假设太多，而它们又有可能容易失败，就像不适当的技术子系统可能无法运行一样，从而降低硬件/软件/人因系统的总体性能。例如，航天飞机被期望成为往返飞行使用率非常高的系统（每年执行多达40次任务），但实际上从未达到过（最多每年9次飞行），因为该系统设计时并没有考虑快速多次往返费时、地勤人员能力、高效的地面维护/测试/飞行前检查等因素。对于某些子系统，往返飞行的频率或范围与初始估算值不匹配。
在NASA系统工程流程中纳入人因系统集成计划，旨在引导工程/项目负责人和系统工程师实际掌握可分配人力资源的能力，并尽早评估整个工程/项目寿命周期中对人因要素的期望，避免在运行使用时出现意外情况。发生意外的代价可能远超过通过运行使用训练而使系统发挥作用所需的人力资源成本。尽早考虑人因系统集成是为了避免低估寿命周期维护成本，包括维修和更换零件费用，以及设计和建造地面保障设施的费用。
专业工程师是开展技术工作不可缺少的组成部分，他们通常与系统工程师/子系统设计师协同工作，执行常见的跨学科工作任务。这些学科涉及系统的制造、安全、保密、运行等特性及经济上的可承受性。某些横向关联的学科专业工程师能够运用专门的分析技术生成相关信息，满足项目负责人和系统工程师的需要。他们同样能帮助在运行使用构想和系统需求的撰写中明确其专业领域内的内容；他们参与评审数据资料、工程变更请求、试验结果和重要项目的文档资料。项目负责人和系统工程师应确保如此生成的信息和产品对项目的附加价值与其成本相当。专业工程技术工作应被很好地集成到项目中。专业工程技术学科的作用和职责也应在系统工程管理计划中概要描述。
本手册中确定和描述的专业工程学科包括安全性和可靠性、故障管理、质量保证（QA）、综合后勤保障（ILS）、可维护性、可生产性和人类因素。将这些领域的专家集成在一起，需要组织能力、技巧和时间，这些可以做成计划编入系统工程管理计划。本手册给系统工程师提供这些专业工程技术学科的总体简明介绍，并不刻意成为这些学科专业中任何一个的综合手册或实施计划，而且并非所有这些学科都需应用于每个项目。
1.概述和目的
安全、可靠的系统通过在其预期寿命内正常运行来确保使命任务的成功。安全、可靠的系统，其故障概率很低且可接受。这一点通过简化，或针对预设和非预设活动的适当设计，或可靠部件和材料的正确应用来实现。除了具有长期使用寿命，可靠系统还是健壮的和容错的，意味着它可以在出现故障及操作参数和环境发生变化的情况下继续发挥其预期的功能作用。一个高效实用的系统能够很好地将其硬件、软件和人因要素集成起来，实现使命任务目标。
2.系统设计中的安全性和可靠性
在执行使命任务的全过程中关注安全性和可靠性，对确保使命任务成功是必要的。现实中制造的系统相对于所设计的安全性和可靠性的逼近程度，依赖于使命任务类型和所需要的信息。对于载人系统，安全性和可靠性是贯穿设计过程的主要目标。对于科学试验使命任务，安全性和可靠性要与工程或项目的资金和能承受的风险相适应。不论使命任务的类型如何，考虑安全性和可靠性都应当是复杂系统设计流程中的一部分。
为实现可靠性分析的利益最大化，在设计团队中加入风险、可靠性和故障管理专家是必要的，这一点毫不夸张。风险和可靠性分析师仅在设计方案形成后对其进行分析，这样的反面案例太多了。这样做的结果就是，安全性和可靠性特征是额外加入的，而非设计出来的。这可能导致不切实际的分析，设计中没有关注风险源，而分析结果也没能为设计方案提供有价值的贡献。
风险和可靠性分析需要回答设计方案成熟度及相应权衡分析的关键问题。可靠性分析需利用系统信息识别风险和风险源，并且为决策提供重要的输入。NASA-STD-8729.1《规划、开发和维护有效的可靠性和可维修性（R&M）工程》给出了相关工程技术活动的概述，供每个特定项目进行剪裁，其中的观点是选择一组有效的可靠性和可维修性工程技术活动，确保所设计、建造和部署的系统能够成功地全程执行所需的使命任务。
在项目的早期阶段，风险和可靠性分析能帮助设计者理解运行使用构想、系统需求、系统架构、人因/系统功能分配、约束条件和资源的相互关系，揭开其中的关键关联关系和动因，如此便于对这些因素进行适当地分析。分析人员应帮助设计人员在需求之外理解设计构思成熟时显现的内在依赖关系。幻想着通过设计需求能够准确获取所有风险和可靠性方面的问题，并且有针对性地得到可靠的设计方案是不现实的。系统工程师应当开发与产品分解结构或系统功能相对应的系统开发策略，说明如何在系统纵向和水平结构上分配和协调可靠性、容错性及恢复能力，以期满足使命任务的全部需求。设计方案的系统性影响在设计过程中起着关键作用。使设计者感知其决策对整个使命任务可靠性的影响是关键。
随着设计方案的成熟，可以运用既定技术进行初步可靠性分析。设计方案和运行使用构想应当做彻底检查，因为事故苗头或隐患可能会导致灾难。基于对危险发生可能性和后果的保守估计，可以使用设计资源来减小失败风险。设计团队也应当确保失效模式已经在整个系统中考虑和应对，确保能够满足系统目标。
在项目的后期阶段，设计团队可以运用风险评估和可靠性技术检验设计方案是否满足其风险和可靠性目标，帮助开发在目标不能满足或发生偏差/失效时的风险缓解策略。
3.可靠性分析技术和方法
这里简要概述可靠性分析技术和方法的类型。
● 事件序列图 / 事件树 ：两者都是描述在使命任务执行过程中可能发生的事件序列和对非正常情况响应的模型。
● 失效模式及影响分析（FMEA） ：自底向上的分析模型，用于辨识系统可能发生的失效类型，明确失效的原因和产生的影响，以及用于控制失效影响的缓解策略。
● 定性逻辑模型 ：自顶向下地辨识系统中的失效如何组合，从而引起意外事件的发生。
● 定量逻辑模型（概率风险评估） ：该模型是对定性模型的扩展，模型中包含了失效的可能性。此类模型涉及基于系统物理原理和系统成功评定准则开发失效评定准则，并应用统计技术评估不确定条件下失效的可能性。
● 可靠性框图 ：由系统单元构成的逻辑框图，用于评估系统实现某项功能的可靠性。
● 危险性预分析（PHA） ：指结合使命任务中需要应用的功能在早期进行的风险分析。危险性预分析是一个确定“如果……会怎样”的过程，需要考虑潜在的危险，启动事件发生场景，评判事件后果的影响，明确可能的调整和控制措施。该方法的目标是决定危险是否能排除，不能排除时应如何进行控制。
● 危险性分析 ：用于评价已完成的设计方案。危险性分析是一个确定“如果……会怎样”的过程，需要考虑潜在的危险，启动事件发生，评判事件后果的影响，明确可能的调整和控制措施。该方法的目标是决定危险是否能排除，不能排除时应如何进行控制。
● 人因可靠性分析 ：是了解人为失误如何导致系统失效及评估这些失效发生可能性的方法。
● 概率结构分析 ：结合材料和载荷的不确定性来评估结构单元失效的方法。
● 备件 / 后勤分析模型 ：提供实时评估系统交互的方法。此类模型包括地面勤务过程仿真和使命任务活动仿真。
4.可靠性分析的局限性
工程设计团队应当理解，在表述使命任务成功概率的同时也表述了系统的可靠性。概率是对特定事件发生可能性的数学度量和表达。因此，概率估计应当基于工程实践数据和历史数据，并且在估算过程中任何既得概率均应包括对不确定性的某种估量。
不确定性可用于表述分析人员相信其所做估计结果的程度。随着数据质量的提高和对系统理解的增强，不确定性会相应减小。对失效率或失效概率的初始估计可能需要基于相似设备、历史数据（固有特性）、手册中失效率数据或专家诱导。
综上所述，可以得出以下结论：
●可靠性估计可用于表达成功的概率。
●不确定性应包含在对可靠性的估计中。
●可靠性估计与FMEA结合，能为辅助决策流程提供附加的且有价值的信息。
1.概述和目的
故障管理（FM）将在7.7节详细讨论，其作用是保持系统按预期发挥功能作用的能力。故障管理需要处理如下内容：
●意外发生和无意引起的情况；
●通过监控关键部件来降低风险；
●故障的检测和定位；
●预测未来的性能下降；
●在试验和运行使用阶段确保系统和人员安全的措施。
故障管理活动越早开始越有效，通常需要在概念设计阶段开始，并且需要具有系统级视角，而不是局部视角，因为在潜在故障得到解决之前系统的设计是不完整的。可以依靠那些单独部署的系统单元之间协同设计和运行来实现整体的可靠性、可用性和安全性目标，这便是综合故障管理。与其他所有系统单元一样，故障管理受工程计划和运行使用资源的限制。因此，故障管理实施人员面临着如下挑战，在保证识别、评估和平衡这些目标存在风险的同时，还要受提升故障管理功能特性可能带来的成本风险制约。
2.故障管理工程师的角色和职责
故障管理工程师的角色和职责是设计在非设定情况下能够维持所需系统行为的一组系统功能和系统单元。故障管理工程师应与系统工程师、安全性和使命任务质量保证工程师、子系统工程师（有时他们自己是特定子系统的故障管理工程师）及生产工程师密切合作，评估应在哪些潜在目标（子系统/组件）上实施故障管理功能。其中需要确定每个管理目标所需的故障管理登记，并将故障管理需求分配给各个子系统。为了使系统获得最大可能的益处（如降低的成本和风险、更强壮的功能特性、强化的适变能力），在系统设计中将故障管理需求、概念设计方案和系统架构进行协同开发是非常必要的。故障管理工程师在系统顶层进行故障管理设计，分配子系统需求，并在所有分配了需求的区域内监督故障管理功能的设计和实现。针对软件和硬件的设计方案和相应需求必须通过风险/效能对比分析进行评估和协商。故障管理工程师需要努力了解所分配子系统故障管理需求的设计和实现，因此在分析过程中需完成以下工作：
●明确并阐明与整体使命任务态势相称的适变能力和恢复特性；
●搜索子系统和系统设计方案之间有潜在危险的相互作用关系；
●了解系统顶层故障管理设计方案直接在子系统实施的后果；
●制定系统故障管理功能的验证和确认计划。
作为项目系统工程团队的一员，故障管理工程师最大限度地利用整个系统显性的常规功能特性，来识别非常规行为并规划对此行为的适当响应。故障管理工程师利用安全性和使命任务质量保证（SMA）分析师的分析结果，分析可靠性、可用性、可维护性、FMEA、概率风险评估（PRA）和危害性/系统安全性等内容。故障管理工程师利用子系统工程开发中的非常规物理分析，并基于所有分析数据来源组织自己的集成分析，对各个层级和多个子系统的权衡研究结果进行分析。故障管理系统工程师多数情况下是飞行系统工程团队的组成部分，但可以根据项目结构，还可以在项目顶层系统工程团队和/或子系统层级系统工程团队中发挥作用。因此，项目的组织结构和其中各个角色/职责/权限的确定必须包含故障管理工程，并允许在子系统之间和跨工程学科明确地通过交流解决权衡研究问题。故障管理工程师需要不断了解可能会影响故障管理的工程决策整体特性，也需要不断了解可能影响系统整体复杂性和运行使用的故障管理决策。其他有关详细信息，可参阅NASA-HDBK-1002《故障管理手册》。
1.概述和目的
即使是最好的设计方案，硬件制造和试验都可能遭遇人为错误。系统工程师需要获得信心，系统实际上是依照其功能需求、性能需求和设计需求生产和提交的。质量保证为项目负责人和系统工程师提供在项目寿命周期中所生产产品和所使用流程的独立评估结果。项目负责人和系统工程师应当与质量保证工程师协同工作，开发适合项目的质量保证计划（质量保证活动的范围、责任和时间）。
质量保证是NASA工程实践中质量的支柱。NPD 8730.5《NASA质量保证计划策略》中阐述的NASA政策为“通过质量保证计划实施，使项目符合工作性能既定需求，并且提供独立的合规担保”。安全性与使命任务质量保证的作用在于保证承包商和其他NASA职能部门按照其承诺及其工作准备开展工作。这确保了目标产品和工程的质量、可靠性及全局风险被控制在计划规定的水平。
2.系统工程师与质量保证的关系
同可靠性、可生产性和其他特征一样，质量应当作为系统整体性的组成部分进行设计。对于系统工程师来说，重要的是理解安全性与使命任务质量保证在全面风险环境下的安全防护作用，并切实保障其在质量方面的作用。如果有效地考虑了使命任务质量保证的作用，并且如果从概念开发阶段开始，所有的设计都考虑了质量要求，则上述一切就会更容易做到。这样做有助于缓解在设计需求和质量需求之间可能体现出的“容差累积”效果冲突。
质量是风险管理的关键部分。误差、偏差、遗漏和其他问题可能要消耗时间、工程资源、钱，甚至生命。了解质量如何影响项目并鼓励以最优方法达到质量水平的要求，是系统工程师的职责所在。
尽管在小型低成本的无人飞行项目中有更大的余地，但对于高风险和产量低的航天飞行项目，通常有必要严格遵守技术规程。因为缺少大量的样本和长时间的生产，依照书面技术规程进行生产，对确保流程及产品的一致性是非常重要的步骤。为说明这点，NASA要求设计出质量保证计划来降低不符合这些需求的风险。
这样可能生成大量需求和技术规程，并且这些应当分解到供应链，甚至分解到最低层级的供应商。对于因不符合需求而可能导致生命损失和使命任务失败的情况，应当要求在政府强制检查节点（GMIP）嵌入相应的技术规程，以确保百分之百地满足安全性要求/使命任务关键属性。安全性要求/使命任务关键属性包括硬件特性、制造工艺要求、运行使用条件、功能实现标准。这些如果得不到满足，将可能导致生命损失和使命任务失败。按照美国联邦采购法规（FAR）第46部第4章
的要求，应制定适当的工程/项目质量保证监督计划。NPR 8735.2《关于NASA合同的政府质量保证功能管理》中给出了工程/项目质量保证监督计划的准备内容大纲。该文件涵盖了低风险和高风险采购的质量保证需求，内容包括文档评审、产品检查、流程见证、质量系统评价、违规报告和纠错行动、质量保证和监督，以及政府强制检查节点。此外，多数NASA项目都有遵从质量系统管理需求标准的相关要求，非关键工作需坚持ISO9001，关键工作需坚持AS9100。对于大多数NASA岗位，质量保证系统培训都是强制的。因此，假设系统工程师已经具备这些系统的能力知识。培训的内容和意图应完全反映在NASA的质量技术规程文档中。
在系统工程流程中，综合后勤保障的目标是确保产品系统在其开发（阶段D）和运行使用（阶段E）期间能够以经济有效的方式得到支持。综合后勤保障对可重用或可维护的项目尤为重要。对于主要产品在运行使用阶段不发生变化的项目，通常仅将综合后勤保障应用于项目的某些部分（如地面系统）或某些单元（如运输单元）。作为综合后勤保障的组成部分，故障管理能够通过促进及时维修和维护来改进项目的规划和运行使用，这不仅节省了时间和费用，而且还能够防止出现延误。符合备用哲理的故障管理和可靠性分析有助于确定备件采购方法。综合后勤保障的实现主要依赖于早期同时考虑多单元保障性特征，对可选的系统和综合后勤保障构想进行权衡研究，使用最佳实践经验量化每个综合后勤保障单元的资源需求，并获取与每个综合后勤保障元素相关的保障产品。在运行使用期间，综合后勤保障活动为系统提供保障，同时根据实际运行使用条件进行分析来寻求成本效益的提升。这些分析不断重塑综合后勤保障系统及其资源需求。忽略综合后勤保障或不良的综合后勤保障决策必然会对系统寿命周期的最终成本产生不利影响。表4.4-1概要总结了综合后勤保障的学科内涵。
表4.4-1 综合后勤保障的技术内容
来源：Blanchard所著《系统工程管理》。
综合后勤保障应该在项目寿命周期早期做出计划并归档。这个计划应说明表4.4-1中包含的要素是如何考虑、执行和集成到系统工程流程需求中的。
1.概述和目的
可维修性被定义为在特定条件下，由具有特殊技能水平的人员，使用预定的技术规程和资源，在预定的维修层级进行维修时，对一个产品组件维持和恢复其能力的度量。可维修性考虑采取维修行动的方便性、经济性、安全性和精确性，是系统设计或安装的固有特性。
2.维修性工程师的作用
维修性工程是一门重要的专业学科，其目标是维持一个可保障系统。维修性工程主要是在系统工程流程中通过积极实施特定设计功能来实现的，这样做可以在预定的物理环境中实现安全有效的维护操作，并在综合后勤保障系统开发中起核心作用。维修性工程师的任务涉及多个方面，例如，开发和维护系统维修概念，建立和分配维修性需求，通过分析完成对系统维护资源需求及系统可维修性验证需求的量化。
1.概述和目的
可生产性是与系统便捷性和经济性相关的系统特征。基于此，所完成的设计方案能够（通过生产、制造或编码）实现方案到硬件产品或软件产品的转化。由于对于多数NASA系统而言，一般仅需要少量生产，特殊的可生产性特征对系统的费效比至关重要，正如航天飞机隔热瓦的生产和使用经历所表明的。影响设计方案可生产性的因素包括原料的选择、设计的简化、产品方案的灵活性、严格的容差需求和技术数据资料的简明化。
2.产品生产工程师的作用
产品生产工程师（作为多学科产品开发团队的成员）辅助系统工程流程的实施，其积极作用体现在通过实现专门设计特征来增强可生产性，进行项目所需要的产品生产工程技术分析。其中包括如下任务和分析工作：
●执行系统风险管理计划中关于生产/制造的部分。做到这一点需要进行严格的产品风险评估并制定有效的风险缓解活动计划。
●确认系统的设计特征能够提高可生产性。通常工作的重心在于设计简化、生产/制造容差和避免危险性材料。
●进行可生产性权衡研究，决定具有最佳成本效益的生产/制造流程。
●在项目约束条件内评估产品生产的可行性。其中可能包括评估承包商和主要分包商的生产经验和能力、新的建造技术、特殊工具和生产人员的训练需求。
●确认长效构件和关键原料。
●估计生产成本，作为寿命周期费用管理的一部分。
●支持技术成熟度评估。
●开发生产进度表。
●开发用于确认产品生产/制造流程的方法和计划。
这些任务和生产的工程技术分析结果应编入生产计划中，所编写的详细程度与项目阶段相适应。产品生产工程师还参与针对上述事项的项目评审（主要是初步设计评审和关键设计评审），参与特殊的临时评审，如生产技术成熟度评审，并提出自己的观点。
产品原型
原型试样的作用是展示系统的形状、尺寸和功能，使之看上去就像是真实的最终产品在其运行使用环境中的尺度和行为。
经验表明，即使在建造单一的飞行系统时，原型系统也可以有效地增强可生产性和可维护性。产品原型应在寿命周期早期建造，并且在相应的开发阶段应尽可能使制造出的原型与飞行正样在形状、尺寸和功能上一致。
产品原型用于“描绘出”设计方案，从产品原型中得到的经验能够反馈到设计变更中，从而提升单一飞行正样的制造、集成和维护水平，或提升制造若干飞行正样的能力。
产品原型的建造经常遇到项目需节省费用的挑战。这通常会导致项目只能接受寿命周期开发阶段所增加的风险。重要的是，系统工程师应当了解产品原型的用途，设法缓解风险，保证工程费用和进度的合理性。
幸运的是，计算机辅助设计和辅助制造技术的进步在某种程度上降低了这些风险，使得设计者能够将设计过程可视化为“按部就班”的集成和维护步骤，在引起高费用的问题成为现实之前发现它们。这个步骤应包括对集成和维护活动中人因交互关系的评估。
1.概述和目的
人因工程（HFE）是研究人因系统接口和交互的学科，为人因系统提供需求、标准和指导，确保系统整体能够有效地适应人类组件并达到所设计的功能。
人因工程专注于那些人类与系统交互的方面。人因工程考虑所有应该与系统进行交互的人员，而不是仅仅考虑运行使用人员。人因工程处理含有人类组织的系统及硬件和软件，并检查所有类型的交互关系。人因工程专家的作用是为人因组件提供支持，并确保硬件、软件、任务和环境的设计与人因系统交互的感应、感知、认知和物理属性相容。
2.人因工程师的角色
在整个系统工程公共技术流程中，有必要在开发团队中包含人因工程人员，以便他们可以创建和执行针对特定流程或项目定制的专用人因工程分析技术和试验。人因工程专家不仅帮助开发目标产品，而且还确保验证试验和完整性技术适合人类采用。人因工程师在此过程的早期参与尤为重要。尽早进入系统设计流程可确保人因系统需求能够融入“设计”而不是以后再纠正。
人因工程师将人性化设计流程作为实施人因系统集成的一部分。对于载人空间飞行，人性化设计由NASA-STD-3001《NASA空间飞行人因系统标准》强制执行；设计中包括运行使用构想和运行使用场景开发、任务分析、人因与系统之间的功能分配、人类角色和责任的分配、迭代概念设计和原型设计、经验性试验、人在回路的和基于模型的人因系统性能评估，以及运行使用期间人因系统性能的现场监测。
很有可能的是，在本手册7.9.1节中提到的所有人因系统集成领域中，人因工程将为系统工程管理计划和人因系统集成计划做出重大贡献。传统上，人因工程流程设计成与系统工程、迭代概念开发、评价/验证/确认/运行使用评估等流程协调和集成。如果在A前阶段的最初开发工作中，人因工程/人因系统集成便在系统设计中起作用，则人因工程（包括所有人因系统集成）将得到最大的成本效益。
人类最初是通过分析使命任务整体而“集成”到系统中的。使命任务功能在利益相关者期望开发流程（参见4.1节）的早期分配给人因，同时也分配给系统架构、技术能力、成本因素和航天机组能力。在完成功能分配后，人因分析师与系统设计人员合作，确保已经为运行使用人员（地面保障人员和航天机组）、培训人员和维护人员提供安全有效地执行其分配任务所需的设备、工具和接口。
图4.4-4给出了在系统规划、分析、设计、试验、运行使用和维护时需要注意的人因流程阶段，以供参考。
图4.4-4 人因工程流程及其与NASA工程/项目寿命周期的联系
人因工程方法用于了解用户需求、设计备选方案原型、进行系统分析、提供人因绩效数据、预测人因系统性能，以及评估人机系统性能是否符合设计标准。随着系统开发的进展，这些方法应用于系统设计的所有阶段，处理设计方案中不断上升的特异性和细节。人因工程原则必须进行剪裁以适应设计阶段。人因工程方法包括：
● 任务分析 ：对每个人员在系统中为完成任务应当做的事项进行详细描述，强调对信息表达、制定决策、任务时间、操作动作和环境条件的需求。
● 时间线分析 ：在任务分析中已经确认任务的持续时间，并且用图形表示这些任务的发生时刻，同时显示任务顺序。时间线分析的目的是辨识两类活动的需求，一是不能同时发生的活动，二是耗时超过许可的活动。给定任务相应的时间线可以描述多个运行使用人员和航天机组的活动。
● 建模和仿真 ：为预测系统性能、比较系统技术状态、评价技术规程和评价备选方案，建立数学模型或工程样机。仿真可以采用简化的模型，例如，可能是在运行使用人员工作站上利用图形模型定位具有真实人体测量维度的图形人体模型，也可以是诸如获取决策点时刻和误差可能性等方面的复杂随机模型。
● 可用性试验 ：基于任务分析和初步设计，在带有监视和记录设备的可控环境下执行实际任务。对客观指标（如完成时间和错误数量）进行评价，同时积累主观评估结果（如问卷调查和评定量表）。试验结果能够系统地描述关于备选设计方案的优缺点。
●
工作量评估
：使用标准化尺度度量工作总量和工作类型，如采用NASA工作量评估工具NASA-TLX或库珀-哈伯等级
进行度量。评估内容包括运行使用人员和航天机组人员的任务量，确定相关人员在给定时间内以给定精度执行给定任务的能力。
● 人为错误和人因可靠性评估 ：包括自顶向下（故障树）和自底向上（人因流程失效模式和影响）的分析。目标是创造能容忍和恢复人为错误的系统来提升人因可靠性。此类系统应支持在将可靠性加入系统中时人因的作用。