电子电气架构的开发，需要涉及整车开发中的大部分系统、功能与部件，横跨软件开发、硬件开发、机械设计、材料科学、生产工艺、人机交互和造型设计等各个工程领域，而且各个车企都有自己的独特之处，加之智能网联领域的迅速发展，新的挑战与应对方法在不断出现，任何一本书都无法详尽地描述电子电气架构的所有开发活动……

然而，万变不离其宗，当抛开各种细节之后，其本质可以被视为系统工程理论在汽车电子电气系统开发中的应用。

电子电气架构专家侯旭光先生在《智能汽车：电子电气架构详解》一书中，将汽车电子电气系统开发方法进行了详细阐述和简化总结（如下7项）；本文摘取书中片段进行分享，希望给大家以启发~

按照需求工程的方法收集、确认和管理需求。

将需求进行细化分解并分配到各个子系统。

将各个子系统的需求分解到各个部件。

各个部件按照步骤1至3进行部件级的设计。

开发部件的软件、硬件和机械等子系统。

进行部件、子系统、电子电气系统、整车等各个层级的集成、验证与确认。

电子电气系统交付与持续迭代。

【1】一个源头：需求 

一切的设计都源于需求，设计的目的是满足需求。需求来自各种利益相关者，虽然收集需求并不一定是架构师需要完成的工作，但对需求的判断和分析却是架构师责无旁贷的义务。通过对各种需求的分析，将决定哪些需求被纳入开发范围、以何种方式实现等，并将其转化为电子电气架构的具体设计。大部分的需求将被以树状结构的形式被不断分解和拓展，在不同的层级被进行不同的细化工作，最终变为具体的软件、硬件和机械等的需求，从而得以实现，并被逐层和逐条的验证。

并不是所有的需求都有唯一的来源，有很多下层的需求可能来自上一层级的多个需求。这些错综复杂的需求构成了一张庞大的网，共同撑起了电子电气架构。尽管电子电气架构的形态可能会大幅度变化，但很多需求却并不依赖电子电气架构的形态而存在，它们只与原始的功能或性能需求相关。对于任何一个车企而言，积累各个层级的需求就是积累自己的电子电气架构设计能力，只不过有些车企的能力存在于人的大脑中，有的存在于各种文档里，有的则存在于各种工具链中。

能够提出正确且全面的需求，就是实力的体现。不断创造出新的需求，就是不断地成长。掌握需求，就是掌握自己的命运。

【2】 两条主线：功能与性能 

整个电子电气系统的开发有两条主线：功能与性能，它们均以需求的形式进入到电子电气架构开发的活动中，是电子电气架构详细设计、开发的起点。

功能的设计多以逻辑设计为主，最终以软硬件结合的方式实现。性能的满足虽然大多以硬件为最终实现载体，但在软件占比越来越大的情况下，越来越多的电子电气相关性能需要软硬件结合来实现。例如：最为常见的EMC性能的满足不但需要硬件层面良好的设计，软件控制逻辑的配合也已经成为必不可少的保障。

没有良好的功能，就不可能有良好的用户体验与产品竞争力。而没有良好的性能，一切都是镜花水月。

【3】两个工作：分解和分配

对于任何复杂的事物，对其进行合理的分解都是一种可以对其了解或掌握的基本手段。电子电气架构设计过程中主要活动的核心方法可以使用两个词来表示：分解和分配。

鉴于电子电气系统的庞大和复杂，一般需要将其进行纵向分解和横向分解。

下图展示了一种电子电气系统的分解方式，首先按照逻辑功能开发的过程分为三个层级：需求层、子系统层和部件层（主要为ECU，传感器和执行器可被视为ECU的一部分）。然后将每一层中的主要组件进行分解：需求层中的组件为Feature/Function，子系统层的组件为子系统及其所包含的逻辑功能，部件层的核心组件为ECU。各种性能需求和基础技术的需求将按照实际情况被非分解和分配到每一层中的每一个组件。

电子电气系统的分层结构

为了方便管理，每一层中的原子组件一般都会被分配到本层中的较大一些的组合组件中。如Feature/Function会被归类到各个域中，如车身域、动力域等。逻辑功能组件会被分配到各个逻辑子系统中。部件层的组件也会被归类到各个域中，或是更小一些的系统中。

总结一下 在整个电子电气架构的开发过程中，首先进行的工作是收集各种需求，其中的功能性需求（特性或功能）将被细化和分解，从而转变为对具体子系统的需求。由于每个子系统都会承接来自需求层的众多具体需求，同时也会收到各种性能和基础技术的需求，这些需求在子系统层进行汇总并整合，进而产生了对每个LF的详细需求。同时，每个子系统的详细逻辑设计、软件架构和硬件设计也会被完成，并转换为对部件的各种详细需求。将软件组件和对硬件端口需求部署到各个部件之后，电子电气系统的设计工作就基本完成。余下的工作就是部件的开发、实现和测试验证了。

对于任何一个车企而言，如果能够将需求层和系统层的设计全面掌握在自己的手中，那么零部件供应商就只需要按照车企的需求进行软硬件实现。另外，不同ECU的差异主要在软件与硬件，相对而言，硬件设计的工作量要小于软件。在上述分层结构中，ECU的软件主要取决于对软件组件的部署，如果软件组件的设计都掌握在车企自己手中，那么ECU之间的合并、拆分或是控制逻辑的集中就只取决于部署的结果。无论对于集中式架构设计、区域控制器设计，还是车企自己进行软硬件开发，对需求层和系统层的深度掌握是必备的基础。

【4】两种思路：增量与重构 

回顾整车电子电气架构的发展历史，我们可以明显的关注到一个持续不变的现象：变化--形态在变化、功能在增加、性能在提升。虽然每隔一段时间，电子电气架构就会由于新技术的出现而发生较大的变化，但很少进行彻底的“重构”。无论是软件还是硬件，基本都是基于以前的基础逐渐发展而来。

对于车企而言，虽然不同代际的电子电气架构中很多控制器都变化很大，但这并不意味着进行了真正的重构，因为那些控制器的提供者仍然会沿用原有的很多设计，仅仅在物理形态上发生了一定的变化，其内部的很多电路仍然会借鉴甚至沿用原来的设计。

软件逻辑层面更是如此，代码级的沿用和移植是每个供应商都会采用的方式。控制器升级的主要目的是功能的增加与性能的提升，其增量与变更部分才是大量资源被投入的地方。这个过程如同很多人在共同堆起一座高山，每增加一点高度，其实都是在前人的基础上填了一筐土而已，只是当山越来越高的时候，填土的成本越来越高，人们不得不换一种方法继续增加山的高度。域控制器也好，中央计算机也好，无非是将原来的土用新的形式进行了整合。这一点可以从很多领域功能的增长变化看出：车身控制、底盘、信息娱乐等领域所增加的功能无一不是对新需求的满足，而那些基本的功能则很久没有本质地变化了，更鲜见有消失的功能。即使是自动驾驶等“新兴”领域，也是在逐渐地增加功能，从基本的ADAS逐渐拓展而成。

然而，量变不断积累必然会引起质变。随着芯片与软件等相关技术的发展，汽车电子这栋大厦从“石头与茅草”为主要材料变成了“钢筋和水泥”的“现代化”，实现手段有了翻天覆地的变化。这主要体现在以各种控制器和通信总线为核心的电子电气架构的形态上，以及设计工具上。

如果抛开电子电气架构的物理形态，那么其内部的逻辑在过去的几十年中一直处于不断增长的状态。逻辑的增长源于功能需求的增加。电子电气架构是逐渐成长起来的，其中的每个子系统也是成长起来的。只不过当今电子电气架构中的子系统数量在不断地增加，每个子系统中的逻辑与相应的需求也在不断地增加。

如果我们将视角聚焦在电子电气架构的物理形态，那么，电子电气架构工程师就不得不面对一个现实的问题：使用增量模式还是完全重构的方式来设计新的电子电气架构。虽然两种方式的共同点都是要在新电子电气架构上实现相比原有电子电气架构的功能和性能的拓展，但其开发难度和成本投入有很大差异。简而言之，这两者之间的差异可以类比为城中村的改造与拆迁重建之间的差异。改造的实施成本低、周期短、资源消耗少，但可扩展的功能与性能有限。而拆迁则可以将一切现有的东西推倒重来，按照当前最理想的情况重新构建，但必然会要求投入大量的资源与时间，相应的成本和风险必然要更高。

究竟哪个方式更好，无法一概而论。这取决于企业当前的资源拥有情况以及企业的目标。如果企业的人力与资金丰富，现有的产品线能够在未来很长一段时间内仍然支撑其收入和市场拓展，且其目标是构建领先所有竞争对手的全新技术平台，那么完全重构的电子电气架构也许可以为其带来未来几年的领先优势。

在进行两种方式的选择时，还有一个重要因素无法回避——电子电气架构相关技术的可获得性与电子电气系统的总成本。如果将实现一个完美电子电气架构所需要的各种技术能力的总和定为100分，那么无论是车企还是各种供应商都无法独自达到100分的要求，但车企和各个供应商能力的总和却可能达到这个要求。如果车企的能力较强，则可以以较低的成本获得自己所欠缺的技术能力。反之，获得成本就会很高。还有一种情况是双方能力的总和低于100分，即车企的能力较弱，合作的供应商的能力也不够强，那么，他们合作完成的电子电气架构的质量就一定会低于预期值。

评估一个电子电气架构的成本及其收益，单从开发成本或系统BOM成本的角度都是不完整的。至少要将二者结合起来，并考虑该电子电气架构所能搭载的车型的总销量，而且还要考虑新电子电气架构带来的各种其他附加收益：如功能的增加、质量的提升、品牌美誉度的提升、数据的收集、各种生产和售后成本的下降等。对于如此之多的因素，很难有任何一个企业能够对其进行完整评估，因此，实际情况是大家仍然较多地采用系统BOM成本作为一个主要的评估标准。 

【5】一个问题：架构设计是技术还是管理 

架构设计无疑是一个对技术能力和经验要求很高的工作，这是任何一个汽车行业的从业者都不会否定的事情。但对于架构设计工作的范围或边界究竟该如何确定，在不同的车企中却有不同的看法。架构设计、系统设计与开发和各种基础技术开发等一直有剪不断理还乱的复杂关系。以下的架构设计的工作内容是各方基本可以达成共识的。

架构设计是一种电子电气系统的顶层设计工作。

架构定义了平台开发的边界以及开发框架：需求，限制和解决方案等。

架构设计是整个电子电气系统设计的一部分，更多着重于系统中结构这一方面，至少包括物理结构和逻辑结构等，但也包括那些对系统的性能、可靠性、成本和演进性等有关联、有影响的其他方面。

各种设计原则的制定也是架构设计的重要工作。

架构设计的工作不直接包括具体子系统和部件的开发实现，但与上述组件的实现紧密相关。

基础设施（如软硬件平台选择、通信总线、中间件等）的选择同样也是架构的主要工作内容。

相关流程、方法论和工具的设计和管理维护也是架构工作中的重要部分。      

以上各项工作中，设计工作无疑是占比最大的，但设计工作不等于没有管理的成分。顶层设计的结果必然会影响众多的人、事、资金等的配置与走向。管理是指在特定的环境条件下，以人为中心通过计划、组织、指挥、协调、控制及创新等手段，对组织所拥有的人力、物力、财力、信息等资源进行有效的决策、计划、组织、领导、控制，以期高效的达到既定组织目标的过程。按照上述定义，将架构设计定义为一种技术管理工作并不为过。

架构在设计过程中对各种方案所做的决策，本身就是一种管理工作。对电子电气系统结构的设计更是决定了众多人的工作内容与工作量。而且，由于电子电气架构开发的复杂性，缺少权威与管理职能的架构团队是难以完成任务的。即使电子电气架构的设计最终得以落实，其开发效率也必然是差强人意。

我们再来简单总结一下架构师的主要工作 

完成电子电气系统的顶层设计，设计的对象为给定的目标电子电气系统的结构（关系）与原则。

原则的确定要先于结构的设计。

在电子电气系统的开发过程中，架构师需要参与整个项目开发的全部过程，包括需求开发、架构设计、系统设计、零部件开发、系统集成、各个阶段的测试和验证等各个阶段，负责在整个项目中对技术活动和技术规范进行指导和协调。

架构师在项目开发过程中要担当技术权威的角色。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照架构意图去实现各项功能。

任何一个具体的零部件或者系统都不是架构师的交付物，架构师的最终交付物是整个的电子电气系统。为了交付整个电子电气系统，架构师还需要设计很多供各个系统和零部件所公用的原则和规范，包括但不限于开发工作的方法论、流程和工具等。

架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

在架构实施的过程中，架构团队还有一件最重要的任务，就是知识与经验的积累，从而可以为整个组织的下一次架构设计活动提供支撑，并让整个组织的能力得以提升。

无论是确定目标系统的结构还是设计各种原则，本质都是做出一系列决策的过程，这也是架构设计与开发过程中最难的工作。