近些年，随着汽车电气化，智能化，网联化，汽车产品的功能和边界不断被拓展。电动汽车，智能驾驶等功能的出现使得汽车早已不再是简单的出行工具，而更像一个智能移动终端。由此，整车电子电气架构日趋复杂与集中化、汽车软件代码量激增，软件服务化，OTA成为可能，软件定义汽车世代来临。
那么在这样的大背景下，面对日益复杂的汽车系统，我们该如何应对？
从研发角度讲，基于模型的系统工程(Model Based Sytem Engineering，MBSE)可能是应对系统复杂性的有效方法之一。
系统工程或者基于模型的系统工程虽然不是什么新鲜概念，甚至有些被过度使用，提到系统工程，大家第一反应就是实现产品的跨学科方法，通过系统思想解决复杂产品问题。但到底什么是系统？什么是系统工程？它的核心是什么？凭什么它能够解决系统复杂问题？
这些年以来，个人越发觉得系统工程的重要性和必要性。带着对这些问题的思考?，系统工程系列专题就和朋友们正式见面了，希望这个系列能给朋友们带来启发，我也会对其一些核心内容分别进行阐述。
由于系统工程涉及内容繁多，我们今天就先起个头，聊一聊系统工程的一些基本问题，带着对这些基本问题的理解，最后我会尝试去回答: 为什么系统工程或基于模型的系统工程可能是应付系统复杂性的应对之道？
01
什么是系统？
系统(System)是相互关联的元素或部分组合在一起构成的整体，它可以是物理或概念意义上的系统，或二者的结合。正是由于组成元素之间的关联性，当它们组合在一起时，可以形成特定的功能。
系统的存在有两方面意义:
1
帮助我们理解复杂对象，通过将复杂对象拆分成不同系统及子系统，降低研究对象的复杂度，便于我们逐个理解和突破。
2
划分职责，让特定的人做特定的事，共同协作开发复杂的对象，毕竟我们每个人能力和时间都是有效的。
个人觉得以下两处对系统定义比较有意思且相互补充:
-
国际系统工程学会(INCOSE)定义:
“A combination of interacting elements organized to achieve one or more stated purposes.”
-
ISO 26262定义:
一个系统至少由一个传感器，一个控制器和执行器构成，当然传感器和执行器可以处于系统外部。
其中，INCOSE定义从功能上定义了系统的存在，简言之，有特定意义或功能的集合即为系统，而ISO 26262从物理组成上定义了系统，传感器，控制器，执行器三者缺一不可。
02
什么是系统工程？
系统工程(Sytem Engineering，SE)是一种跨学科的综合性方法，系统工程强调使用系统的原理和概念，以及科学、技术和管理方法来实现系统设计与开发。
这个定义比较抽象，个人认为系统工程更多的是一种思维方式，重点在于系统一词，它包含两层含义:
1
从系统或整体的角度看待和分析问题，关注系统之间因果和相互作用，而不只是局限于系统本身。
2
运用系统的技术手段，以需求为导向，架构为开发基础，前期验证和确认为及时发现解决问题。
如下图所示，系统工程本身属于方法论，同样基于V模型，只不过它对需求，对架构以及验证和确认在产品设计中的发挥的作用更为重视：
来源: MathWorks
需求的重要性在于:
现在的汽车产品早已不再是简单的交通工具，汽车产品需求也是日益趋于复杂化，多样化，除了用户对产品功能方面的需求不断复杂化，例如，电动化需求，自动驾驶需求，智能座舱需求等，市场及相关法律法规的约束也不断增加，例如功能安全，信息安全，ASPICE等等。
需求是一切开发的基础，它深刻体现了我们对用户需求的理解以及产品定位的思考，直接决定了我们需要开发什么样的产品。完善的需求管理是项目成功的关键因素之一，帮助我们:
-
揭示用户对产品假定和潜在的需求
-
明确市场法律法规对产品的要求
-
明确定义交付成果并构建相关功能
-
衡量项目工作量，对项目周期和成本把控
糟糕的需求管理常常是项目失败的首要原因。在实际项目中，很多人认为需求只是一堆可有可无的文档，企业重视程度不高，导致需求质量低，书写不规范，常常被弱化，经常为了评审，硬补需求，需求没有被真正应用于产品开发，甚至很多中小型甚至大型企业需求管理都没有专门的成型的需求管理体系，只是通过一些简单定义的工作规范和工作流程来管理需求，需求管理工作也往往由一些没有太多经验的工程师承担。
下图充分说明了需求管理的重要性，错误或有问题的需求会直接导致产品开发的失败，虽然图片内容带有夸张成分，但很多产品的开发从需求开始就注定是失败的:
有问题的需求 > 设计缺陷 > 开发 > 更高的解决难度和处理成本
好的需求应该充分体现用户需求，市场现在及未来潜在要求，做到有层次，描述清晰无歧义，可追溯，可复用，可测试。
架构的重要性在于:
一旦确定了产品需求，我们就可以根据需求着手开发产品，但在产品具体详细设计前，尤其对于复杂系统，我们往往需要大致确定下可行方案，或者说给系统实现打个草稿，这个就是所谓的架构。
架构是产品需求的实现的初步设想，它帮助我们在产品开发前期，根据需求构建所需的功能，并从复杂度，成本等角度对其进行综合探讨和评估，找出最合适的实施方案。
所以架构的重要性在于:
1
架构帮助我们在一些重要的事情上一开始就做正确的决定，系统规划，确定方向，避免资源和时间浪费。
2
对系统或者产品形成统一的理解，帮助我们对内对外更好地沟通和决策，降低沟通成本。
3
对系统进行合理的抽象，便于复用。
4
架构模型为桥梁，有效统一产品需求，实现过程以及测试用例可追溯性。
尤其是对于基于模型的系统工程(MBSE)，架构是模型的重要体现，我个人一直认为在整个系统开发过程中，架构的设计可能是最困难同时也是最重要的过程，面对复杂的需求，如何对其进行功能抽象，以尽可能合理的方式对其功能进行组织，妥协，最终形成可实施的技术解决方案。
最后我想说架构是门艺术，任何重要的内容都属于架构的范畴，详细内容我们后面细聊。
验证和确认的重要性在于:
验证(Verification)和确认(Validation)是MBSE过程中重要的检查措施，其区别见:
12 – 汽车功能安全(ISO 26262)系列: 软件开发 – 软件详细设计及安全测试
确认和验证是整个系统生命周期过程中需持续进行的系统工程活动，主要通过分析，评审，测试等手段进行，是检查产品是否按照我们预期的方式和结果进行开发，是及时发现解决问题的有效途径，也是保证产品质量的关键措施。
03
基于模型的系统工程MBSE
在传统的系统工程应用过程中，不管是需求，还是架构都是以文档为中心，每个阶段工作输出结果的载体都是文档，不同团队和阶段的交流也都是基于文档。
但随着系统复杂性的上升，以文档为中心的系统工程（Text Based Systems Engineering，TBSE）方法存在很多问题，例如:
-
系统复杂化，文档数量增多，不便于书写，管理
-
文字描述存在歧义，对团队沟通协作不友好，不同部门及开发人员难以形成统一理解
-
需求变更，追溯困难
-
文档无法仿真验证
为了解决TBSE所存在的问题，国际系统工程学会(INCOSE)提出了基于模型的系统工程(Model Based Systems Engineering，MBSE)方法。
MBSE强调以图形化模型为核心，将SE方法论过程中设计内容通过工具模型化，电子化，构建不同阶段开发模型，例如需求模型，架构模型，详细设计模型等，并彼此相互关联，以此增加输出内容的可复用性、形成系统一体化设计，可以有效解决随着系统复杂度提高对传统基于文档的系统工程带来的挑战，这个也是目前大部分规范，例如ISO 26262，ASPICE等，对工作输出产物的基本要求。
-
建模语言
-
工具
这两项内容，这也就构成了MBSE落地三大基本要素PMT，即:流程(Process), 方法(Method)和工具Tools，所以简单地说:
MBSE = SE方法论 + 建模语言 + 工具
建模语言定义了建模过程中可以使用的可视化元素及其代表的意义。为消除歧义，MBSE要求使用统一化的建模语言SysML。它以图像化的方式定义了不同类型的视图表达方式，例如需求视图，结构视图，流程视图，状态视图等等，这些视图相互补充，可以用于表达MBSE设计过程中关注对象的不同侧面(View)，进而形成完整的系统架构模型。
但应该如何通过这些视图将SE方法论中的工作内容尽可能有层次地，可追溯地，完整地统一在一个系统化模型中，实现一体化的模型设计呢？
答案就是RFLP方法。
所谓的RFLP 方法就是：
R: 需求(Requirement)
F: 功能(Function)
L: 逻辑(Logical)
P: 物理(Physical)
RFLP认为我们应该从以上四个角度(Viewpoint)去对待系统，通过建立相应的架构模型，将复杂技术产品的实现过程进行完整映射。关于RFLP进一步内容我会在架构专题中进一步探讨。
工具是指在实施MBSE过程中建立，建立及管理模型所使用的软件工具，它们可能是多个工具，包括了需求定义及管理工具，架构建模工具，测试验证管理工具等，它们之间通过接口可以进行交互，建立可追溯性，也可以是自主开发的综合性设计工具，将MBSE过程建模统一在一起。
个人认为，MBSE方法论大家都比较熟悉，MBSE落地实施的关键除了思维转换，摈弃原有基于零部件的开发，以及开发流程匹配外，模型的建立是关键，而有效的工具支持是建立及管理模型的必要条件，它能帮助将工程师从繁杂的文档工作中解放出来，专注于可视化模型的建立，整个产品研发以模型作为驱动，提高产品开发效率。
聊了这么多关于SE或MBSE基本内容，我们现在回过头来再看下标题中的问题:
为什么MBSE是系统复杂性的应对之道？
这个问题有点大，我尝试回答如下:
所谓复杂性，主要是源于研究对象结构复杂，组成元素相互作用，存在错综复杂的关系，使得我们不能由局部来认识整体。所以解决复杂性的根本在于从整体上认识系统，将其进行系统化拆分，弄清其组成元素的相互作用关系，并通过有效的手段对其进行抽象化，直观化，使得我们能够从整体上认识和理解系统。
而SE或MBSE方法论的核心正是从系统角度认识整体，一方面通过系统的方法论，重视需求和架构的作用，及时对系统进行验证和确认。另一方面，开发过程以模型为驱动，通过系统模型以图像化方式直观地揭示系统的组成及它们之间的联系，让工程师能够以一种更加容易的方式掌控系统复杂性。
写在最后:
，接下来我会针对其具体相关内容，包括需求，架构，语言等方面分别进行展开，希望能够给朋友们理解系统工程，应对系统复杂性带来新的理解。
END
【点赞】和【在看】= 原创的动力
多谢【点赞】和【在看】
原文始发于微信公众号（AUTO世代）：为什么MBSE是系统复杂性应对之道
