4.5 设计定义过程

4.5.1 目的

如ISO/IEC/IEEE 15288所述：

设计定义过程的目的是提供关于系统及其元素的充分详细的数据和信息，使实现能够与架构实体一致，正如系统架构的模型和视图中所定义的那样。

4.5.2 概述

系统设计是对系统架构进行补充，提供对系统元素的实现有用且必要的信息和数据。这些信息和数据详细描述了分配给每个系统元素所期望的特性，和（或）能够推进这些系统元素实现的各种期望的特性。

设计是为了系统架构能够实现，所以系统设计将以适合于实现的设计特征集合的形式来开发、表达并文件化，系统设计是沟通系统架构和系统实现的过程。

设计关注特定工程过程所需的每一个系统元素(例如所构成的实现技术构成，如机械、电子、软件、化学、人员操作和服务)。设计定义过程提供使特定系统元素能够实现的各种详细信息和数据。

因此，设计定义过程是为实现提供必要的设计特征和设计使能项的描述。设计特征包括尺寸、形状、材料和数据进程结构。设计使能项包括正式表达式或方程、图样、图、带有具体的值和公差的指标表、特征模式、算法和启发法。

4.5.3 活动描述

图4-34是根据《INCOSE系统工程手册》设计定义过程IPO图改编的设计定义过程图。

根据ISO/IEC/IEEE 15288：2015，架构定义过程包含以下活动：

（1）设计定义准备 本活动包含以下任务：

1）为组成系统的每一个系统元素确定所需的技术。

2）确定必要的设计特性类型。

3）定义设计进化原则。

4）定义设计定义策略。

5）识别并计划必要的使能系统或所需的服务以支持设计定义。

6）获得或购买使能系统或服务的使用权。

（2）建立每个系统元素的设计特性及关联设计使能项 本活动包含以下任务：

1）分配系统需求到系统元素。

2）将架构特性转换成设计特性。

3）定义必要的设计使能项。

4）检查设计备选方案。

5）完善或定义系统元素之间以及同外部实体之间的接口。

6）建立设计产出物。

（3）评估备选方案获取系统元素 本活动包含以下任务：

1）识别任何可以考虑使用的候选非开发项（NDI）。

2）根据由预期的设计特性和系统元素需求而开发的标准，评估每一个候选NDI和新设计备选方案，以确定是否适合预期应用。

3）在候选NDI方案和新设计备选方案中确定首选方案。

（4）管理设计 本活动包含以下任务：

1）映射设计特性到系统元素。

2）捕获设计和理由。

3）维护设计可追溯性。

4）为基线提供已选定的关键信息项。

4.5.4 关键要素解析

1.整体设计与系统思维

整体设计（Holistic Design）是指设计定义开始于将系统作为一个整体并结束于每一个系统元素（不只是其中之一）的定义（即设计），以及它们是如何设计成一个完整的系统一起工作。在我国，尤其是航天领域，也叫“总体设计”。

整体设计充分体现了系统思维的核心要素，“设计定义始于将系统作为一个整体”体现了整体论的思想，“结束于每一个系统元素（不只是其中之一）的定义（即设计）”体现了还原论的思想，“它们是如何设计成一个完整的系统一起工作”则体现了合成论的思想。

此外，在MBSE的方法论中，黑盒描述模型是将系统对象作为整体来考虑其活动时序与状态，白盒描述模型则是将整体的各种特性解析并还原到不同的构成要素中，而设计综合过程则是将系统重新合成为一个一起工作的整体。

在设计定义过程中，可能需要附加系统元素以使整个系统工作：

1）需要在系统边界中嵌入一些使能的元素或服务。通常需要在将使能项纳入系统内和置于系统外之间进行权衡。

2）架构定义过程可以做此项权衡，但让设计定义来处理可能更好。这经常取决于设计过程中其他的设计权衡与设计决策。

3）设计决策和权衡结果向架构定义过程反馈。是否更新架构取决于所捕获的这些特征对于架构是否重要。

4）整体设计区别于独立产品或服务的设计。

①整体设计是一种设计的方法。

②系统被设计为一个相互关联的整体，该系统是更大的系统的一部分。

③整体概念可以应用到将系统及其所在的环境（如该系统参与的企业或使命）作为一个整体，也可以是机械设备的设计与空间布局等。

④整体设计结合了对环境的关注，总体设计师们考虑他们的设计将如何影响环境，并试图减少设计对环境的影响。整体设计不仅仅是试图满足系统的需求。

2.架构定义与设计定义

架构定义过程聚焦于相关方关切点的理解和解析，并对这些关切点、解决方案需求及系统的涌现性和行为之间关系开发深入透视。架构聚焦于整个生存周期的适用性、生存力和适应性。有效的架构尽可能独立于设计，以便在设计权衡空间中有最大灵活性。它更聚焦于“做什么”，而不是“如何做”。

另一方面，设计定义过程由特定的需求、架构以及性能和可行性更为详细地分析所驱动。设计定义阐述实现技术以及这些技术同化的过程。设计提供定义的“如何做”或“实现至……程度”的层级。设计师视角如图4-35所示。

虽然架构定义与设计定义所考虑的侧重点不一样，但是在工程实践中，架构定义与设计定义往往需要密切协同工作。

3.设计定义与实现

设计定义应确保设计输出数据的完整性，并使设计输出数据易于准确理解。关于硬件方面的描述数据通常风险不大，例如工程图纸往往是按照成熟、通用的标准绘制的，所使用的工具通常也是成熟、通用的。需要特别关注的是通过软件实现的功能。在这方面，系统定义与软件定义工作应充分、有效地衔接。如果软件开发采用面向对象的方法，那么较为理想的系统定义方法也应是面向对象的。设计定义与软件开发之间一旦存在鸿沟，将为项目带来极大风险。尤其是随着功能软件化的趋势，越来越多的功能依赖于软件实现，对于这样的系统，更应该重视这个问题。

4.5.5 案例——导弹设计定义（基于知识组件设计）

导弹设计定义包含了将导弹作为整体的方案设计，以及将总体需求分解到各个子系统后的递归活动，还包括专业设计活动。本案例主要介绍了如何基于知识组件完成导弹的总体方案设计、子系统方案设计以及专业设计定义。利用Sysware工程中间件平台，将导弹的总体方案设计、子系统方案设计与专业设计的过程、活动，以及活动所需要的知识、完成活动的工具、活动之间的数据传递等，封装成知识组件，利用知识组件高效准确地完成相关的设计。

图4-36~图4-41所示为本案例中几个典型的设计知识组件。

对于各个子系统的专业设计，通过工程中间件定义各种知识组件，可以将企业长期以来积累的各种专业设计知识通过显性化、组件化实现知识积累，通过高效率的重用体现知识的价值。

从设计定义过程开始，主要面向系统对象的物理域开展工作，各种专业设计工具与领域知识被大量应用到设计定义过程中。需要强调一点的是，在当前的情况下，一般所说的产品设计大多数都是指系统设计定义过程的系列活动，基本上是面向物理域的设计定义。现实中的问题在于很多人重视设计定义而忽略了设计定义之前的各种逻辑层面的定义活动。而逻辑层面的定义往往更重要，系统对象的各种缺陷、遗漏的问题基本可以通过逻辑层面的定义活动在早期发现。现实工作中经常会出现的在产品研制后期发现这样那样的问题，基本原因都是逻辑层面的定义工作没有做到位。

此外，这里面还包含了另外一个困扰很多系统工程师的问题，那就是在系统设计定义之前的所有工作。如果不按照系统工程的过程工作，仅仅凭借经验基本上可以完成系统对象工作的70%~80%。所以有人就提出了疑问，“既然凭借经验就可以快速完成的工作，为什么还要我们按照这一套复杂的过程去做，那不是给我们添活儿吗”？这几乎代表了绝大多数设计师的心声，尽管有些人没有明确提出来。原因主要有以下几点：

1）根据经验来完成，基本上以前别人在其他型号上犯过的错误你还会再犯一次。因为大多数型号研制过程中的问题往往都在研制后期阶段被发现，而通常这些问题并没有完全反馈到系统定义的早期阶段。例如：当产品实物出来后发现了问题，反馈到设计部门，设计部门会根据问题对设计模型进行变更，这种变更绝大多数是就问题修改问题，很少有人对问题点之前的各种设计内容进行对应的修改。

问题未被发现并不表示问题不存在，因此在问题被发现之前的、隐含了问题的各种设计被重用后，同样的问题被复制到新的系统中。这就是最典型的重复地犯同样的错误。

2）根据经验来完成，严重依赖设计者的个人能力与经验，“五花八门”就是用来形容这个情况的。系统工程过程，至少从程序上让工程师们在一开始就将问题考虑得更为全面。

3）经验虽然得到了70%~80%的结果，但是，我们知道，一般的产品研制其实就是70%~80%的重用，10%~20%的改进，10%的创新。这其中的创新与改进包括了应用模式的创新与技术的创新。这些创新的内容，需要用系统工程方法来支撑。