系统工程—战略性选择适用于功能与逻辑结构

目录

概要
介绍
系统工程的现状，
提高系统工程的价值 3当前框架：需求和零部件 5新框架：需求、功能、逻辑和物理(RFLP). 6功能和逻辑概览 7在系统结构的最高层面建立价值 8总结/结论. 11

概要

对汽车OEM厂商和供应商来说，机电一体化的开发仍然是一个挑战。多学科多专业协同开发至关重要，尤其是在汽车行业，架构和解决方案不断演进以满足日新月异的客户需求与环境需求。新的移动、可持续性和信息娱乐方式要求对电气、软件、机械和化学专业知识进行新的组合。

目前大部分基于模型和需求驱动的基于模型的开发的的框架能够支持单一专业领域，但真正需要的是一种需求驱动的基于模型的设计框架在该框架下能够支撑车辆或者系统的多学科架构的开发，且能使开发团队分解开发对象以便进行细化开发和验证，这就意味需求(R),功能(F),逻辑(L)物理(P)也即是(RFLP)的方法必须既能满足整车级的顶层开发又能满足最底层的技术架构分解。能够管理整车或系统的多专业领域架构。这样就能帮助研发部门进一步分解对象进行细化处理与验证。这也意味着需求、功能、逻辑和物理（RFLP）的方法不仅可应用于整车级别的高层架构开发同样也可以应用到最低层的技术组件。

我们在上述车辆顶层架构去展示RFLP用于定义和精细化车辆的整车架构定义和概念即便是需求在某种程度上的"高层需求”，基于RFLP整车架构能够捕获“用户需求的声音”并框定出高层的有关产品定义、以及提供低层决策和分析所需的上下文的方向性决策。

我们在“整车架构”上的方法是展示如何能够将RFLP用于定义和优化整车定义与概念，即便是需求仍然可能有些“高层面”的情况下。使用RFLP整车辆架构师能够捕获“客户需求”并使用它们在产品定义的最高层面定义出决策框架，为底层的决策和分析提供所需的上下文环境。

介绍

对当今的整车厂和供应商来说，系统工程已不是新的专业领域。那么为什么许多人觉得这个专业领域在主流开发中使用不足或完全没有使用呢？对那些将系统工程看作开发周期中的一项关键工作的人来说，他们为什么普遍无法对它的定义达成一致或解释它如何在开发周期中体现出来？如果观察当今领先的OEM厂商和供应商的开发活动，毫无疑问汽车行业的产品开发是一项复杂且精细的工作。在典型的汽车产品生命周期中，涉及到许多专业领域和用到许多专项技能。要指出几种看似体现了系统工程存在的工具似乎并不难，但要清楚地定义我们是否采用了系统工程，或是在哪种程度上采用系统工程，仍然有一定的难度。

系统工程的现状

首先，理解使用系统工程的方式以及在目前汽车开发实践中它所处的位置是很有用的。如果要描述系统工程，许多汽车经理会从开发前段的需求管理描述开始。对于需求结构和内容的定义往往需要详尽的讨论才能用于开发团队的工作，一些要点也会被提出来展现这个过程中要管理多少种不同类型的需求，具体类型如功能要求、非功能要求、环境要求、制造要求和服务要求。然后就要对需求结构的复杂性进行深入讨论。那么工程师将会自豪地强调那些从高层面目标向下分解为详细规格组件的需求。工程师甚至可能会将部分需求强调为“系统需求”，部分为“子系统要求”，其余的为“组件要求”。这种讨论非常具有说服力，我们可能会在这点上止步，满足于我们已经发现的东西。

但是如果我们去另一个部门，我们可能会得到不同的观点。一些产品线经理可能认为公司内部是用到系统工程的，原因是对于产品的各项特性都有详细描述。他们可能会提供具有相同说服力的清单，以及在各种情况下整车特性的分类、创建目录和描述结构。在结构的最高层面，各项特性以相对含糊的表述加以描述，类似于产品的市场营销描述，这和之前提到的需求讨论非常相似，功能结构的最低层面会包含非常详尽的特征具体实施的方法。

忽略组织会阻碍创新、组织性忽略或遏制创新

类似的，其他部门会强调系统工程是如何通过详尽的建模和CAE分析体现出来的。可以肯定是，构建这些复杂模型中的虚拟智能证明了系统工程存在于开发流程中。为仿真机械结构，分析机电系统行为和细化软件控制系统而创建的模型也会体现这一点。结构的复杂性、建模元素的组织结构都再次为较高层面的系统思维提供了依据。

那么究竟是什么定义了汽车行业里的系统工程流程呢？答案是“以上全部”活动和解决方案，再加上许多其他内容，才构成系统工程域。实际上，系统工程并不是一个单独的领域，它是工程和开发所有领域的集合。在更广阔的背景下，系统工程是远远超出了开发工作的活动。除传统的开发工作外，它还包含社交、经济和物流等功能。

这一视角让系统工程延伸到单一专业领域之外，让它在汽车行业能更好地发挥自身的优势，开发出更理想的车辆技术，在保证企业目标的情况下按时的推出产品。要实现这些，企业必须将系统工程视为交付产品的核心流程，而非工具或解决方案。使它成为所有开发活动的真正中心，为汽车团队开发产品和技术提供基础框架。在本白皮书的后续章节中，我们将分析如何通过在传统需求和物理结构之间加入正式的功能和逻辑结构将系统工程定位为开发框架。

提高系统工程的价值

系统工程对汽车行业而言肯定不是什么新鲜事。大多数领先的汽车公司已经将该专业领域以一种或某种形式正式的融入到自己的开发流程中。然而，许多公司对于他们是否真正地充分利用了系统程的支持者所宣称的的优势而感到困惑。具体而言，在INCOSE资助的一项关于系统工程工作（SEE）的价值的研究中，他们发现日益增多的SEE导致成本超支下降以及项目执行变数下降。

因此带来了了这样一个问题，我们怎样做才能够改善我们的系统工程工作(SEE)让我们从系统工程的定义开始。以下是引用的三种常见的系统工程定义：

“系统工程与关注于单独零部件的区别在于它关注于设计与整体（系统）的应用。它要求从整体上观察问题，考虑所有的领域和变量，并将社会问题与技术问题关联。"1

“系统工程是一种将真实世界的系统进行综合、开发和运营的自上而下的迭代的流程，它能够以近于理想地方式满足对系统的所有需求。2

“系统工程是一种跨多专业的方法来实现系统的成功实施。3

作为上述定义的共同要素都有一个统一的观点：系统工程是涉及跨多专业领域的广泛视角。此外，这些定义表明了对问题的逐渐解决和/或某些开发系统对需求实现的满意度。但是没有任何定义指出使用的具体工具和流程。相反，他们指出系统工程是一种用于开发所需产品的方法和流程。《INCOSE系统工程手册》会进一步介绍使用系统工程方法开发产品时使用的大量工具和流程。这其中包括部分下列内容：

·决策管理；
·需求管理；
·风险与机遇管理；
·采购与供应；
·架构设计;
·项目管理；
·质量管理；
·审核；
·验证；
·建模、仿真和原型构建.

正如我们所看到的，这里有许多流程而且这些流程在性质上极为宽泛。再次强调一下，系统工程不仅仅是一种工具或解决方案，它是开发周期中的一个流程和框架。

本文的论点是部分或全部使用这些类型的工具和流程并不说明存在着有效的系统工程，或后续章节中描述的系统工程工作（SEE）的增加。这种开发流程中正式化的框架为有效地运用上文列出的各项系统工程工具去支持产品开发和交付提供了基础。因为系统工程流程可能存在于产品分解的许多层面上，我们将重点讲述系统工程框架如何有效的帮助理解汽车行业较高层面的架构开发。我们会提出一个框架的建立对产品各个层级的理解和分解起到重要的作用。从性质上讲，任务分解为产品描绘制了一个较高层面的组成图。那么这个较高层面的视图是如何被搭建出来的，我们如何能从这个视图中真正获益呢？

当前框架：需求和零部件

汽车行业目前使用的系统工程只包括两种主要的结构：需求和零部件。许多人会认为还存在其他对象和表达，但这些表达一般都是从物理零部件结构或需求结构的转变过来的。构建它们的目的不是用于以不同的方式查看或了解产品，而是改善使用产品信息的工具或流程的格式或适配性。即使产品的结构或视图发生重大变化，如果脱离产品结构所使用的工具，这种视图就毫无价值。

图1演示从需求到零部件的路径。

举例来说，工程物料清单转变为制造物料清单就是典型的重组产品零部件以更好地体现制造和/或采购流程。这一视图对零部件结构来说是一个必要的转型，但一般并未当作理解、构建和改进系统的核心结构来维护。此外，用于分析目的形成的CAE结构（网状网产品）是可更改的物理零件，它能够帮助CAE工具更轻松地使用该数据。有许多这样的转变存在，但它们并未从根本上改变产品的视图或理解方法。

出于这个原因，我们一般使用需求和物理零部件结构作为主框架，用于理解产品和将客户的需求与开发流程的结果建立关联。需求和零部件结构之间缺乏通用框架，这代表我们对为什么开发这款产品的原因（需求）的理解与我们为满足这些需求而开发的零部件所做的改变之间是存在差距的。我们忽略了一些关于正在开发的产品的根本问题。具体而言，我们在开发“什么”，我们“如何”实现我们的目标。

由于这个差距的存在，以及在进入物理产品设计之前需要其他工具设计产品，我们将系统工程实践的重点放在简单地将需求和部件与它们之间的结构和工具的关联上。我们将重点关注在何时自动运行集成工作，何时停止并开展手动转变等问题。但是我们的重点不是对这些关系/集成的基础性的理解，他们只是实现目标的一种手段，一种使用工具并回溯到需求的途径。

新框架：需求、功能、逻辑和物理(RFLP)

如果我们要更好地理解如何分解以及“什么”和“如何”这样的关键问题，我们必须将我们开发框架的范围延伸至需求结构和部件结构之外。我们必须引入适合于解答这些问题的框架，且它必须从根本上独立地作为开发流程的一部分。

插入两个结构来答复这些问题能够显著地帮助我们对产品和开发流程的理解。在需求（R)结构和物理（P）部件结构之间插入的结构包括功能（F）结构和逻辑（L）结构。功能对象和关系有助于我们理解我们在开发“什么”，而逻辑结构则有助于我们定义将“如何”实现我们的目标。这些新结构的完美结合，将传统视图转型为需求、功能、逻辑和物理结构视图，或简称RFLP。

创建这些结构的目的是帮助我们从不同角度，根本上理解我们的设计。从结构的意义上来说这些结构是彼此独立的。需求结构提供的是我们开发产品的原因的背景，即搜集客户需求和企业目标的背景。功能对象和关系是使用解决方案来完成目的的深度解读，让开发部门了解实现这些目标的最终产品。逻辑结构定义的是如何实现这些功能的方法，它汇集解决问题的不同方法并加以研究和比较。最终，物理部件代表的是最终被制造、采购并提供给最终用户的虚拟产品。

这些视图并非新鲜事物，而是我们通常在开发的概念阶段用于定义产品的术语。但是这些术语不是开发流程中的产品的“正式”视图。那些主张“正式”地使用这些结构的做法一般可分为两类。第一类做法是将功能和逻辑定义当做需求的不同子类型来归类。它们用类似于管理需求的方式进行处理和结构组织，但往往让用户困惑于它们所代表的内容，而且一般会破坏功能与逻辑视图与需求的独立性。

第二类做法是为它们创建不同的结构，并为我们在完成物理设计前使用的单独建模开发工具专门构建结构。这些工具则代表了需求结构和物理结构之间的解决方案。这种方法的不足之处在于我们定义结构的方法缺乏一致性，并失去了这些专用工具之外的结构的价值。功能和逻辑定义可能会以某些方式进行表达，但它主要是服务某些点对点的解决方案，而不关注与对产品的理解和收益。在下面的引文中，Maier和Rechin5介绍了用于理解产品的一些不同观点背后的重要意义和原则。

"一套良好的视图应该是完整的（应能覆盖所有架构师的干系人的所有关注点）和各自独立的视图（从不同视角捕获信息的不同关注点）。下面图3所示的是甄选出的对架构工作最为重要的视图集。”

如上文的引文指出的，这种方法涉及专门的结构和表达，以便系统架构师从不同角度“视图”解决方案，而且每个视图都具有最大的独立性。实际上，引用的表格指出的是部分被视为“最重要的”的视图。可以看出，理解行为、目的和性能目标是理解和构建复杂系统的重要元素。为了更好开发和理解复杂产品，达索系统的RFLP方法也遵循了相同的原则。

功能和逻辑概览

目前为止，我们已经确立了需求和物理产品定义之间存在功能和逻辑视图的需要。本章节将进一步介绍如何使用这些功能结构的细节。和先前指出的一样，传统方法会通过大量集成直接将需求关联到物理表达上，其间存在大量集成。

RFLP方法提供了一个结构化的桥梁，便于我们能更好地将需求转化为物理形态。在对复杂系统使用建模和仿真等工具时，这些功能和逻辑结构提供了更多视图供使用。因此我们的图形从图1开始看似图4中的图形。

图4RFLP框架展示。

在本图中，单项的解决方案充分利用包含功能和逻辑定义的通用框架和通用结构集。例如可以创建逻辑结构来代表软件对象。这些逻辑结构有助于定义如何开发代码块并将其部署在指定的电子控制单元（ECU）上。该逻辑对象提供所需的输入和输出信息，从而为代表该段代码的软件模块提供了良好的定义。此外，可以创建的一系列功能并分配给逻辑对象。这种功能结构为开发人员提供了实现什么的代码的定义。

用于软件行为建模的工具可使用DSDynamicBehaviorModeling(DBM)模块，或者用户也可以使用其他解决方案。无论使用哪种方法，用户都能够从所代表系统需要完成的目标以及如何构建系统以结构化的方式实现这些目标中大获益。现在多种工具能够使用通用的结构集合。注意到从单项解决方案到RFLP框架的箭头是双向的。这意味解决方案的知识和结果会回流到框架中，作为决策和架构的额外背景与知识。这种通用框架更有利于集中学习经验教训和管理知识，而不是让它们隐藏在单项解决方案中。

在系统结构的最高层面建立价值

系统工程存在于或能够存在于产品结构的所有层面上。典型的观点是认为为系统工程用于描述和解决最复杂的多学科领域产品结构。这也就是为什么这种方法常用于航空航天与汽车产品中的原因。但是系统工程思想和方法的价值对任何能够分解为多项学科和子复杂功能的对象有意义，诚如前面章节提到的定义。汽车OEM厂商和大多数一二线供应商的产品能够以这种方式进行分解，而且在许多情况下都能够分解成多个层级。出于这个原因，RFLP结构能够能好的支持和处理多个层级。在本白皮书中我们将重点关注最高层面的结构。对这个层面进行抽象概括的益处往往被低估了，我们下面会对其原因进行探究。

以典型的车辆结构和分解为例。我们可以从最高层级开始，去发现能够反映最终客户购买车辆意向的需求。我们经常讨论如安全性、特性、动力、容量、燃油经济性等需求。同样，我们描述的功能也涉及的是高级功能，例如“提供座椅”或“允许方向调整”。这个层面的逻辑表达将包括一些通用的平台定义，例如底盘、传动、车体等。最终，这些逻辑对象的CAD定义会涉及包络区域的模糊表达，这些区域被预留出来供后续开发详细组件使用。

相反地，最底层的细节可能涉及用于实现网络驱动程序的具体软件。这个层面的需求会涉及在网络总线上传递的特定消息的最小延迟。功能表达将软件信号编码为可靠的消息。逻辑对象可以代表为实现该功能而正在编码的网络驱动程序，物理结构可以是实现逻辑对象的二进制代码或源代码。

显而易见从汽车的顶层到底层，结构分解的颗粒度发生了巨大的变化。较低层面上的结构分解的价值已经得到广泛的理解，尤其是在传动和电气/电子系统等特定领域中。而较高层面结构的分解则往往被忽视，因为这些结构看似不太确切或性质上“模糊”。但是理解产品的高层面的分解对理解和管理关注点，搜集知识，充分发挥平台的重复利用性和实现执行的一致性的角度出发提供某些显著的好处。

首先，将系统-V和产品最终目标建立直接链接，来实现正确的关注点管理。随着我们给产品需求添加越来越多的层面，我们与产品最初的北京发生脱离。由于我们失去与了客户需求的关联，因此我们失去了做出正确的权衡取舍决策的能力。我们认为自己理解了客户的要求，因为我们已经处理了非常详细的需求。但是在最低层做出的设计决策可能导致我们不得去重新评估在较高层面做出的决策。扎实地理解最高层面的产品构成（需求、功能、逻辑和物理）结合自顶向下的追踪能力，就能够让设计人员和工程师迅速评估原始假设是否仍然有效和充分。

图5RFLP框架举例。

其次，对高层结构有良好的搭建及思考，能帮助用户搜集在开发过程中取得的知识。将随后在设计、分解和建模过程中学习到的经验教训进行捕获并用于构造系统结构，可以帮助理解高层系统决策和对其的细化。例如，如果电动助力转向技术方案的某些选择被视为不可接受或对特定卡车平台不兼容，该信息能在最高层面上被正式化，这样就能尽早在后续项目中避免发生不兼容情况。这种情况可以在更复杂的系统中被搜集和理解，因为它们不仅根据需求来决定流程，它们还能充分利用导致不兼容结果的功能和逻辑含义。因此可以更轻松地探索和理解未来的技术，从而潜在的避免最初发现的不兼容性。

最后，我们将超出零部件和子系统重用的范围，开始充分发挥系统重用的优势。在对产品组合的高层级有很好的定义的情况下，企业能够迅速地确立产品的整体发展方向，依托更丰富的假设和上下文环境启动开发工作。对于需求、功能、逻辑和物理层面的理解为概念阶段的高层面的决策权衡研究提供亟需的信息。而系统组件的重用能加快理解和决策的进程。这可以看作将系统工程结构以类似于CAD模板的方法模板化来加快物理几何结构的开发进程。

接受高端车和产品架构的重要性和价值的难题之一在于缺乏准确的变量和具体的数学证明来评估和优化这个层面上的设计。在设计产品时，复杂系统最高层级的定义的对象和范围缺乏工程师所期待的准确度。但是这种工作环境对架构师和艺术家来说是司空见惯的。而且在评估这些工作的时候，架构师和艺术家通过启发式的方法来引导他们完成开发工作。这种启发法非常适用于系统结构的最高层级，因为它让专业开发人员能够从专家和以往的项目中搜集到有价值的原理。这些启法随后被用于代表开发工作的结构上（包括RFLP）。

“每一代都会比上一代知道更多、学习更多、规划更多、尝试更多和成功更多，因为不需要重复耗费时间来重建积累经验的过程....通过应用相同的流程、定性尝试、积累和规范化个人体验，通过科学和工程公式和算法的有力支撑来实现对复杂问题的解决。”5

部分“系统思维者”可能对在开发复杂系统的过程中使用定性尝试来引导自己的思路极为满意。但是有人发现如果没有正确的框架来应用这些宝贵的经验和教训，从其中汲取的价值将难以被使用，或者更糟糕的是，它们会被误用，导致错误的决策。为此原因，规范化开发框架并将其延伸到需求结构和零部件之外，充分发挥功能和逻辑结构的优势，能够让汽车专业人员逐渐提高学习和使用。整车和产品架构师能正确地将尝试法应用到正确结构的平台表达上，提高理解的准确度。

总结/结论

系统工程将继续在汽车OEM厂商和供应商实现业务成功方面发挥主导性作用。这样汽车行业也会基于企业的需求和为客户交付成功产品的意愿来寻求专业领域的成功。但是为系统工程的内容下定义对企业来说仍然是一个挑战，即便是对那些系统思考者的人也是如此。如果将系统工程视为开发的核心框架，同时将其作为成功理解、开发、优化和部署正确结构的方法将会克服这一挑战。

我们的3体验平台能为各品牌应用注入强大动力，服务于12个行业，并提供丰富多样的行业解决方案体验。

作为一家为全球客户提供3DEXPERIENCE解决方案的领导者，达索系统为企业和客户提供虚拟空间以模拟可持续创新。其全球领先的解决方案改变了产品在设计、生产和技术支持上的方式。达索系统的协作解决方案更是推动了社会创新，扩大了通过虚拟世界来改善真实世界的可能性。达索系统为140多个国家超过19万个不同行业、不同规模的客户带来价值。如欲了解更多信息，敬请访问：www.3ds.com