聊聊汽车电子电气架构，你想知道的在这里吗？

huangguang

什么是电子电气架构？电子电气架构（EEA）包含了车上所有的硬件、软件、传感器、执行机构、电子电气分配系统，电子电气架构是通过系统集成化的工具把这所有的内容整合到一起，它包含了最软件设施、硬件设施和高效的动力和信号分配系统三个基础的要素，在软件设施和硬件设施具备基础上还要一套高效的动力和信号分配系统把这些软件和硬件有机地结合到一起。电子电气架构（EEA）涉及电子与电气两部分，它是在成本、重量、可靠性等一定约束条件下，能最优实现整车电子与电气需求的技术方案。电子电气架构是整车电子电气开发的主体框架，为具体的整车项目中的模块开发提供整车实现方案与规范指导，需具备前瞻性，平台化，可拓展性等特点。

总结来说，电气架构是整车电气系统的基本结构，它包括功能，系统，组成系统的零件，零件与零件之间的相互关系，零件与环境之间的关系，以及指导系统设计和演化的原理。



电子电气架构示例图

01
EEA 主要支撑技术

1.1车载以太网在车载以太网概念出现之前，我们知道汽车内已经有不同的总线标准在应用，包括 CAN、LIN、FlexRay、MOST 等；那为什么还需要车载以太网呢？主要还是因为车载以太网在面向未来应用的低成本、高带宽、低延迟等特性。

1.2仿真技术依赖于 V 流程，有整车级、系统级、软硬件等多种层级的仿真，针对于具体应用包括新能源、智能驾驶等领域的仿真，主要优点是可以缩短产品开发流程、降低开发成本。

1.3信息安全在 EEA 中，当车与外界互联时，涉及到信息安全。在第一、二代 EEA 中，广播收音系统、胎压监测系统、汽车安全门禁系统等都涉及到信息安全；未来 EEA 中，面向 5G 的 LTE V2X，基于以太网的 DOIP 等与外界频繁交互的功能及相关产品需要考虑信息安全。

1.4功能安全现在讲功能安全的车厂和零部件公司很多，但始终不要忘记，功能安全是正向开发的，一个优秀的 EEA，会将功能安全需求合理的分配给相应的零部件。

1.5网络设计根据 EEA 要求，设计网络节点、点与点的通信方式、传输速率等。

1.6诊断设计根据 EEA 要求，参考相关诊断标准，完成 ECU 级别的诊断设计。
1.7电气设计主要指线束设计，作为汽车内部的神经血管，未来 EEA 中对于线束设计的要求方向是：轻量化、缩短整车线束长度；电气设计还包括整车的电源分配、 EMC 设计等。
1.8硬件设计EEA，需要通过硬件来实现落地。未来架构中，域控制器/中央计算平台会随着 MCU / MPU 的性能提升而不断提升，而每个域下的传感器和执行器会逐步走向标准化。
1.9基础软件设计每个 ECU 的基础软件会走向标准化，即满足 Classic AUTOSAR 和 Adaptive AUTOSAR。

1.10应用软件设计基于模型的应用层软件开发将会是未来的发展趋势，而未来的 EEA 将是基于服务的，类似于手机 APP，可实现软硬分离，车厂可以根据用户的需求快速开发应用软件。

02
为什么要做电子电气架构（EEA）？

1. EEA是整车层面电子电气相关需求的继承及扩展，确保工程开发满足整车层面的需求；
2. 前期好的EEA规划，能够实现降低成本，增强产品的竞争力；
3. EEA会前期定义好软硬件接口，从而避免在系统开发设计过程中出现系统之间不匹配的问题；
4. EEA能够是实现平台化、模块化的基础，保证技术方案的一致性，避免重复的开发及验证，缩短开发周期，降低成本。

03
EEA 发展趋势



目前市场上一些厂家已经实现域控制器的量产，一些厂家还是用的分布式架构。现在的电子电气架构不仅要满足车辆本身的功能和车辆本身的服务，还要延伸到云端，实现车跟车之间的互联、车跟交通设施之间的互联、车跟人之间的互联，这些都将通过电子电气架构来实现，所以将来的电子电气架构是互联的电子电气架构。



随着智能化汽车的发展和新能源汽车的发展对电子电气架构的要求会越来越高，随着用户体验系统、娱乐系统、互动系统和主动安全功能的不断完善，导致目前的电子电气架构已经无法满足这些需求，现在的电子电气架构已经没有足够的空间和相应的成本增加，并且在物理安装上也有很大的困难。如果在想继续满足自动驾驶和新能源汽车的相应功能，现在的架构已经超过负载，目前的架构需要更新。随着智能车辆的普及，汽车会 采用集中计算架构，实现集中计算，区域连接。后续继续发展可能会将部分内容放至云端。
汽车电信通信速率朝着高速化方向发展，而且越来越注重安全。电气化、网联化的推进也使功能安全、信息安全的问题越来越凸显。安全的问题也在汽车开发过程中越来越受到重视。
未来的电子电气架构应该具备四个特点：第一，要易扩展，第二要高性能，第三要一体化，第四要强安全。
· 易扩展：就是电子电气系统要很方便的增加、减少，按照功能的需求进行增减。
· 高性能：不管我们在计算力还是通讯方面都需要有高性能的基础。
· 一体化：车和云是一体化的考虑，以后车不再是单独独立的个体，是云端互联和旁边的车一起形成有机的整体。
· 强安全：这是车从诞生以来就着重强调的，但是在智能网联的时代安全性就更加重要。
第二方面是软件，我们未来的架构需要开放标准化的基础软件平台，我们要从以前单个系统的纵向软件开发转向到横向分层的结构开发。面向服务架构的设计，要成为我们未来电子电气架构设计主流的思想，统一协调车内的资源，让车内的资源能够快速、有效的进行重新组合，形成新的功能。
第三方面是软硬分离对架构开发模式带来的变化。我们以前传统交钥匙的，整车厂、供应商、用户的关系很难维系，整车厂、供应商、用户要形成新的开发模式。我们合作模式来讲，以前整车厂提需求，供应商软件做好交到整车厂，整车厂组装测试，要变为整车厂更多的涉及到底层软件，包括硬件软件的开发。第二个改变思维要从以前和消费者之间一锤子的买卖，售出车辆之后不再进行优化的模式，变成全生命周期的迭代，就是从我们设计开始那一天到用户抛弃这辆车，这辆车报废的那一天，整个的生命周期要形成新的开发模式。第三是车云的协同开发，以后车的功能开发部再仅仅局限于车端，和云端一体化，以及云端快速的迭代、监测，一些控制，将会成为车功能开发新的特点。第四个要和用户一起，把用户介入进来，以后我们整车上的功能不仅仅是整车厂的想法，用户的想法要加入进来，要迭代到整个的开发流程当中去，让用户也成为开发的一个部分，让每个用户都有属于自己的一辆车，成为新的一个特性。

04
EEA应该怎么做？
4.1架构设计：明确开发目标对于城市规划师来说，他们的设计对象并不是某一个街区或某个建筑，而是整个城市，他们要对整个城市的设计质量负责。如果我们如果把汽车上每个控制器甚至电子部件都想象成城市中的一个特定功能区域，那么电子电气系统的架构师做的就是规划整个的E/E系统，并对E/E系统的设计质量负责。

架构师首先要确定E/E系统（整个城市）的主要功能和性能，然后根据确定的功能与性能的目标来规划整车的拓扑（城市的街区）：确定有多少个主要的控制器、每个控制器的基本功能和相互的连接方式、车辆的主要通信网络的形式（CAN 或者以太网或其它）等，并要设计整车的电源方案等。
因为 E/E 系统在车上并不是一个孤立的系统，它要与车辆本身的物理架构充分的融合，并与车辆的外部世界也有着密切的联系，所以，在进行 E/E 系统的规划时，他们还要考虑车辆本体的很多具体限制与能力，就如同城市规划师需要考虑城市的地形、气候以及与其它城市之间的关联性一样。每个控制器在车上的大致布置位置、质量要求、性能要求等也是需要在架构设计阶段需要考虑并确定的。
上述的各种架构设计阶段所确定的各种详细信息最终会以各种原则、规范、标准或者需求等形式输出给相关方，他们会根据得到的需求来进行详细的设计，然后再交给最终承担具体实现任务的各个供应商进行部件的开发。
4.2系统开发：细化具体策略对于一个城市来说，每个街区的功能都是不同的，比如说可以分为商业区、居住区、工业区等等。因为每个街区的功能不同，所以它们的设计要求也不同。例如：居住区要能够容纳100万人，并有各种便利的生活设施，而工业区要能够支持多个大型的工业项目的生产、物流等要求。当某一个街区的设计要求由城市规划师确定之后，一般会有专门的人员进行详细的设计。例如：负责居住区的设计师把城市规划师的要求可以细化为：1000栋高20层的楼、有3所小学、两座医院等等，并详细的在图纸上列出它们的位置和边界，并对区内的交通网络、通信、电力网络等进行详细的设计，并给出具体的要求。这个过程可以类比为E/E系统中的系统设计。

车上的E/E系统也会被分为多个域或者子系统，每个域或者子系统的功能与技术要求都是不同的，比如：底盘控制、仪表显示、电池管理等。所以一般都会由来自专业领域的系统工程师来负责进行详细的设计。他们会像街区的设计师一样，根据架构设计的要求对自己所负责的领域进行详细的设计。灯光控制的系统工程师会根据车辆的配置和功能需求来设计灯光系统的详细逻辑以及具体的信号交互、硬件驱动的参数要求，并且给出对每个相关部件的详细要求，从而让各个部件的工程师能够完成对部件的详细设计。
4.3零部件设计：详细设计不同的域、零部件当街区的设计完成之后，接下来要做的就是每栋建筑的详细设计，建筑的设计者发布的图纸中规定了房屋的主要结构、所在位置与周边环境的相互关系，以及屋中各种组件的位置与相互之间结合的关系，比如砖混结构、房屋的具体位置和朝向、卧室与客厅的相对位置与尺寸、马桶在卫生间中的位置等，还会对各种建筑材料的选取原则给出具体的标准，比如水泥的标号，钢筋的型号，各种电线的等级要求等等。

零部件工程师完成的也是类似的工作，他们会和供应商进行深入合作，在满足系统工程师给出的具体要求的前提下，进一步详细的设计每一个具体的零部件，完成诸如硬件、软件逻辑的详细设计、整个零部件的外观尺寸、可靠性和 EMC 标准等，并要确保供应商的产线能够保质保量的稳定生产，随时解答供应商的各种问题，并将其中的部分问题反馈给系统工程师乃至架构师，让他们决定是否要更改原来的设计。
4.4供应商开发：系统的搭建及实现在各种设计需求最终到达供应商的时候，供应商就要开始具体的实施工作了。

在建筑行业，施工单位拿到具体的图纸之后，将组织施工队伍进行具体的建造工作，并最终在验收完成后结束一切具体的工作。而汽车行业的供应商则有所不同，他们将在设计验收之后开始大规模的量产活动（SOP，Start Of Production），并且一直持续到产品退市（EOP，End of Production）。而且，对于很多复杂的产品，整车厂与零部件供应商的设计职责之间的界限并没有那么清晰，很多时候，整车厂只要给出概要性的设计，所有的详细设计工作都由供应商来完成。
从整个 E/E 系统的开发实现过程中可以看出：无论是架构设计、系统设计还是零部件的设计，其实都是设计的过程，而设计本身是一种不断产生需求、传递需求的活动，上下游之间的信息传递过程是以需求作为载体的，设计过程产生的各种规范、原则、标准等本质是一种需求——一种需要下游来遵守或满足的需求。需求的传递并非完全是瀑布式的单向传递，而是双向的，只有被下游接受了的需求才是有效的需求，而且，下游是可以反向对上游提出需求的。具体需求的最终实现则是通过供应商的开发、验证和生产活动完成的。

05
EEA 评估维度

评估维度	定义
可靠性/质量	系统在各种复杂环境下在一定的时间内保证功能满足设计意图的能力
安全	发生影响车辆、人员安全的失效的可能性
成本	设计、开发、制造、物流、维修等各阶段的成本
信息安全	预防非授权入侵、操控的能力
灵活性	在不更改硬件的前提下适应更改的能力
可扩展性	在硬件资源方面为可能得更改做好预留
复用性	零部件支持不同产品线的能力
车辆可用性	在特定失效模式下确保车辆基本操作的可用性
可维护性/可诊断性	失效系统可以在一定时间内完成维修、诊断的能力
重量?	零部件重量
开发周期?	满足项目开发周期的能力
布置灵活性	硬件资源在布置、设计等方面的自由度
兼容性	架构设计与过往设计、工具、数据、供应商等方面的兼容性
复杂性	对设计复杂度的评估