1.5.2 系统分解的4个步骤与3个原则

系统包含3个主要的组成部分：组件、环境和结构关系。系统分解的本质是在不改变原始系统的现有组件、环境和结构关系的前提下将组件进行分组，形成若干较小的子系统。在系统被分解后，各个组件在形式上已经归属于新的子系统，这些子系统则归属于原来的系统。在一个组件归属于新的子系统之后，这个组件与归属于其他子系统的组件的关系将被子系统继承，原本属于组件之间的关系就变成了子系统之间的关系。各个子系统以组件的形式存在于系统中。这个过程可以理解为从天上由近及远地看一个城市：虽然城市没有变，但看到的事物已经从一个个具体的建筑物变为一个个街区了。

系统分解分为纵向分解和横向分解。纵向分解指将复杂而庞大的系统进行分层，从而使每一层可以尽量独立地开展工作，这有助于效率和质量的提升。比如将电子电气系统按照开发阶段分为需求层、系统层和部件层等，将控制器的软件分为应用层、中间件层、驱动层等。横向分解是指将同一层的组件进行拆分和分组，如将需求分解为功能性需求和性能需求，将电子电气系统层分解为车身系统、动力系统、娱乐系统等。

本节将详细描述系统分解的步骤和原则。

1.系统分解的4个步骤

将系统进行分解是一个高度复杂的工作，可以按照以下4个基本步骤依次进行。

（1）明确对象 因为系统的分解主要是针对组件进行的，那么首先要明确的就是组件是什么。我们已经知道了，任何一个复杂系统都可以有多个视图，从每个视图看到的组件可能完全不同。对于电子电气系统来说，从逻辑视图看到的是逻辑功能，从物理视图看到的是各种部件，从过程视图看到的是开发过程中的各种阶段性工作和输出物。而且，所谓组件也完全取决于观察者的位置和角度：一个控制器既可以被继续分解为外壳、PCBA（Printed Circuit Board Assembly，印刷电路板总成）和插件等更小的部件，也可以与周边的传感器和执行器等组成一个较大的组件。

既然系统分解的目的是便于管理和开发，而且系统分解又有多个可以入手的角度，那么究竟应该从哪个视图入手对电子电气系统进行分解就取决于管理的方式和目的了。

对于以硬件系统集成为主要开发方式的车企，既然管理的主要标的物是硬件，那么从物理视图入手进行分解就是一种适合的方式，也就是将电子电气系统的所有零部件按照类别进行划分，从而得到多个子系统，比如可以分为底盘控制系统、动力控制系统等。每个子系统中的组件就是一个个控制器和相关的执行器与传感器。

如果整车厂有能力自己进行完整的上层功能逻辑设计，甚至可以深度参与到供应商的软件开发工作中，那么仅从物理层面划分系统就不够严谨了。因为在这种情况下，车企需要管理的不只是零部件，对逻辑层面也要进行深度管理。这个时候，从逻辑视图入手进行系统划分就变得很有必要了。因为逻辑子系统的组件是逻辑功能（Logical Function，LF，或称为逻辑部件，Logical Component，LC），所以从逻辑视图进行的系统划分就是将整个电子电气系统中的逻辑组件进行分类。虽然划分的结果可能还会有底盘控制系统、动力控制系统，但是它们内部的组件已经完全不同了。

电子电气系统还有一个过程视图，理论上也可以通过过程视图进行系统分解。事实上，所有整车厂早已按照开发过程将系统进行了分解，只是大家已经对这种划分习以为常，所以才察觉不到。如图1-10所示，每个按照功能属性划分的系统（动力、信息娱乐等）又被按照开发过程分为需求开发、架构设计和测试验证等更小的系统。

没有哪个车企只从单一的视图进行电子电气系统的分解，大多数都是从3个视图同时开展系统分解的。

（2）确定层级 明确了系统分解的对象之后，要做的是确定系统分解工作的层级，也就是将一个系统分解多少次。因为系统本身没有界定层级的作用，所以界定层级就只能依靠分解者自己了。

系统之间可以是并列关系，也可以是包含关系。例如，底盘系统与车身控制系统就是并列的关系，它们之间没有重叠的部分。像车身控制系统与外灯控制系统和锁系统之间的关系就变成了包含与被包含的关系。也就是说，一个系统既可以是其他系统的组件，也可以包含多个子系统。

另外，系统之间不可以有相互重叠的部分。例如，虽然从物理视图看到的灯光控制系统和雨刮系统共用了相同的部件（组合开关），但该部件在物理系统划分中应该唯一属于某一个系统，而不能被两个系统共同包含。

一个系统的大小取决于不同的视角和目的，也取决于组织对于系统的掌控程度，以及组织内部分工的细化程度。一般来说，掌控得越详细，系统中组件的颗粒度就越小，系统内部的组件就越多。

在整车的开发管理中，大多会采用如图1-11所示的整车电子电气系统分层方式，将电子电气系统分解为可以被管控的子系统，甚至物理或逻辑零部件。

在图1-11所示的分层示例中，电子电气系统首先被分为多个域，在这个层级中，每个域都可以被看作电子电气系统的一个子系统。不过，因为域通常过于庞大，所以会被进一步分解为更小一些的子系统，每个子系统中又包含众多物理或逻辑零部件。每个层级中的组件总数量都是上一个层级中组件总数量的10倍左右，从而形成了一个金字塔式的结构。在很多组织中，这种电子电气系统的分层结构也基本等同于组织的管理架构。

在不同的组织中有不同的分层方法和原则，共同点是每一层都会对本层中的“系统”进行进一步分解，并最终形成了一棵电子电气系统树。即使在低层，我们依然可以将零部件作为系统进行进一步的分解。例如我们可以将一个控制器作为一个系统，将其分解为至少3个组件：输入、处理和输出。系统分解的目的是将复杂的系统分解为可以被掌控的子系统或组件，如果子系统或组件的数量过多，管理的难度和成本会大幅度提升。行业惯例是尽量避免较多的层级划分，以减少系统的层级和组件的数量。

对于一个给定的复杂系统，将其分解为多个子系统是一件既需要技术又需要技巧的事情，因为分解工作不但需要对整个系统范围内各种技术细节有深度了解，还需要考虑并平衡各个方面的限制与诉求。然而，完美的系统划分是不存在的，只有暂时适合的划分方案，这既是因为系统的划分方案取决于各种非技术因素，也是因为系统本身是在动态的演进和变化中存在的。

（3）划定边界 在解决了待分解对象与待分解层级的问题后，我们就可以真正开始系统分解工作了，这是最难、最复杂，也是工作量最大的工作，因为我们要为每一个子系统确定边界。

首先，我们要明确电子电气系统的边界在哪里。这个问题看似简单，在实际操作中经常会出现让人迷惑的情况。从物理视图进行分解时，如果我们把消耗电能作为判断一个部件是否属于电子电气系统的依据，那么虽然自己不消耗电能，却与那些消耗电能的部件紧密相连甚至不可分割的部件是否也应该划到电子电气系统中呢？答案是不一定！比如，控制器的支架在某些整车厂中就属于电器部门负责的电子电气系统部件，而在某些整车厂中又属于非电器部门的部件。

类似的问题还有很多，空调的管路是否属于电子电气系统？仪表台上的装饰件是否属于电子电气系统？这类问题永远无法找到标准答案，只能人为决策。

解决了电子电气系统边界的问题之后，接下来逐层进行系统分解工作。对于稳定组织架构的成员来说，无论进行全新的系统分解还是对现有系统分解进行变更，都必然影响到现有人员的分工乃至整个组织架构。在进行系统分解的过程中要充分考虑人的因素，而且无论从哪个视图入手，都会涉及人员职责或组织架构的调整。在划定系统边界的时候，充分听取各方的建议，并在理想与现实之间取得适度的妥协，是不得不去做的事情。

（4）持续维护 经历了千辛万苦，完成系统的分解后，并没有万事大吉。随着各种新技术在汽车中陆续应用，电子电气系统中被不断添加了各种新的部件和新的功能，而且原有的部件与功能也在不断改变，这种持续不断的变化对电子电气系统中逻辑视图的组件和物理视图的组件都产生了持续的影响。同时，由于整车厂和供应商之间责任界限日益模糊，过程视图也受到了冲击。

随着智能驾驶辅助的兴起，电子电气系统需要被进一步拓展。有的车企把智能驾驶辅助相关的部件设置为一个与其他传统系统并列的系统；有的车企把智能驾驶辅助和被动安全整合到一起，统称为主被动安全；有的车企把智能驾驶辅助划归到电子电器系统中统筹管理；有的车企则将智能驾驶辅助的相关部件划分到了底盘系统中。

在逻辑视图层面，车企对智能驾驶辅助功能相关逻辑系统的划分方法同样是五花八门，有的将智能驾驶辅助功能以部件的功能划分为图像处理、雷达数据处理等逻辑子系统，有的车企按照功能类别划分为泊车辅助、行车辅助等逻辑子系统，有的则将其按照数据流向划分为感知、决策和执行等逻辑子系统。

各种划分方式无所谓好与坏，只是反映了划分时的态度与认知，并且与当时组织的机构设置、人员构成直接相关。说到底，系统是一个集合的概念，如何设置系统的边界，完全是人决定的，而不同人的认知和关注点总是差异巨大。

无论技术的发展、需求的变更，还是人员的调整，都可能导致原来的分解结果需要调整。因为系统分解的结果会反过来影响组织机构和相关人员的职责，继而对技术和需求产生影响，所以系统分解之后的持续维护和更新就变成了一项重要且持续的工作。

2.系统分解的3个原则

无论从哪个视图进行系统分解，下面列举的系统分解基本原则都是普遍适用的。

（1）完备性 对系统分解工作的基本要求是完备性，即不遗漏、不重叠，如图1-12所示。此原则也被称为MECE（Mutually Exclusive, Collectively Exhaustive，相互独立，完全穷尽）法则。无论哪一个视图，都需要充分识别系统中的所有组件，并让每一个组件都归属于某一个子系统，且唯一归属于这个子系统。也就是说，系统分解后不能出现原有系统的某个组件不在任何一个新产生的子系统中的情况，也不能出现一个组件同时分属两个子系统的情况。

完备性原则还可以被进一步细化为如下原则。

正交原则：和物理学中的正交分解类似，子系统应是相互独立的，在职责上没有重叠。

稳定性原则：将稳定部分和易变部分分解为不同的子系统，稳定部分不应依赖易变部分。通用部分和专用部分、动态部分和静态部分、机制和策略均应该被分开。

复用性原则：尽量进行知识重用，包括重用类似系统已有的设计方案、设计经验、成熟的架构模式或参考模型、设计模式、设计思想等，这可以大幅减少开发工作量并提升质量。

（2）可管理 分解后产生的子系统的颗粒度既不能太小也不能太大，要维持在一个可被管理的程度。如果太小，则管理成本会很高，需要大量的人力来对应。如果太大，则分解的作用就不明显了。是否可以被管理是一个相对的判断，取决于组织的人员数量和能力，没有一个绝对的标准。

（3）高内聚低耦合 由于被分解的系统中各个组件之间存在着各种连接关系，因此当被分解为多个子系统之后，这些子系统之间就会继承内部组件之间的连接关系，从而形成子系统之间的连接关系。这种子系统之间的连接关系导致了子系统之间的相关性。

对于子系统之间的相关性，我们可以用内聚与耦合这两个软件架构设计领域的词来表示。内聚指的是一个系统或模块内部的组件之间的相关性，相关性越高，内聚程度越高，系统的独立性越好，可靠性越高。耦合指的是不同系统或模块之间的相关性，相关性越高，耦合程度越高，系统的独立性越差，对其他系统的依赖程度就越高。

耦合度与内聚度虽然暂时没有可供量化的指标，但是尽量减少子系统之间的耦合度，并提高系统内部的内聚度，对系统的可靠性、可维护性都有很大的好处。而且，对于电子电气系统来说，内部子系统的耦合度和内聚程度会直接影响电子电气系统的开发、维护效率，从而影响系统的开发周期、成本和质量。高内聚低耦合原则不仅适用于系统分解，也适用于电子电气系统架构的设计和组织架构的设计。

系统设计如果依赖与之无关的因素，就会带来意料之外的麻烦。在系统设计中，如何减少功能之间、部件之间的耦合是一个极其考验架构师能力的问题，耦合越多，系统出错的可能性越大，将来系统扩展、更新的成本越高。