第2篇 智能技术

第2章 电子电气架构与计算平台

2.1 汽车电子电气架构

2.1.1 汽车电子技术发展历史

汽车电子技术的发展及其应用是从20世纪70年代末到现在，大致经历了4个发展阶段。

第一个发展阶段为1971年以前，汽车开始应用技术原理简单的交流发电机、电压调节器、电子闪光器等分立元器件搭建的电路，该阶段汽车为纯机械控制，电子技术只是作为辅助。

第二个发展阶段为1974—1982年，随着集成电路的快速发展，汽车开始应用16位以下的微控制器，电子汽油喷射技术的发展和ABS（防抱死制动系统）作为该阶段的典型代表，是汽车从机械控制逐步向电子控制转变的开始。

第三个发展阶段为1982—1990年，随着微处理器技术的逐渐成熟，汽车电子开始向智能化方向发展。汽车应用的产品有胎压控制器、数字式油压计、直视仪表板、倒车示警器、高速限制器、自动后视镜系统等，该阶段汽车控制系统逐步电子化，同时辅助驾驶系统开始开发应用。

第四个发展阶段为2005年至今，随着汽车智能化、网联化、电动化的快速发展，自动防撞、动力优化、自动驾驶、高清地图导航等技术逐步开始应用于汽车，该阶段表现为汽车开始转变为完全由电子系统掌控，不需要驾驶人，同时汽车开始作为一个网络终端，和其他网络设备一起构成新一代网络体系。

2.1.2 汽车电子电气架构相关知识

1.架构定义

电子电气架构包括所有的电子和电气部件、它们之间的互联结构（拓扑结构），以及它们之间的线束连接。一个完整的电子电气架构是由不同的车载网络连接在一起的，为了系统化管理和规划，按照功能将车辆划分为不同电子系统管理域，如信息娱乐系统（指示、娱乐和车载导航）、行车安全系统（底盘、主动、辅助驾驶系统）、传动系统（驱动、废气处理）等。通过划分不同的域，将功能和软硬件结合到一起，依维柯电子电气架构如图2-1所示。从图中可以看到，整个电子电气系统由不同的功能模块组成，功能模块之间通过总线进行连接。

2.架构模型

电子电气架构模型从不同的维度描述了电子电气架构系统，主要包括逻辑模型和实现模型两种，如图2-2所示。逻辑模型用来描述抽象逻辑层面上的功能，不依赖于实现该功能的硬件。实现模型用来确认实现功能需要的电子部件，同时会根据功能耦合关系进行合理的功能域分配和接口分配，其中，节点模型用来合并技术链不同的技术组件，电子部件硬件模型用来实现节点模型的硬件部分，电子部件软件模型又分为基础软件和应用软件两部分，通信网络模型用来描述通过总线进行连接的部件，电源网络模型描述负载对电源的需求，安装空间和线路模型定义具体部件的安装空间和线缆的走线和固定方式等。

图2-3所示为功能模型典型案例，它通过作用链来描述。该模型将功能和与之相连的传感器及执行器以粗略的功能块的形式加以描述，并不涉及其具体技术实现。

图2-4所示为技术模型实现过程。技术模型中由技术组件形成一个技术链，而技术组件要说明功能模块是采用硬件还是软件来实现，确认实现主体。

图2-5所示为节点模型实现过程。它属于技术链的技术组件合并到处于不同位置的节点中去。因此，节点模型包括并描述了电子电气架构中所有需要的部件。此外，在确定节点模型时还要决定功能的集成度，将功能进行合理的集成。

3.开发流程

电子电气开发过程遵循V模型开发流程，按照逻辑关系和时间先后顺序将开发步骤连接在一起，并对每个设计的输入/输出文档做出规定。

图2-6所示为汽车电子电气架构开发V模型，这是一种典型的V模型。汽车电子电气架构开发过程属于整车开发过程的需求分析阶段和设计阶段。在进行电子电气架构开发的需求管理和需求分析时，要区分功能需求和非功能需求。功能需求产生汽车制造商的功能列表，而非功能需求产生汽车制造商的决策矩阵和设计限制。电子电气的开发有两种模式，一种是从下到上的模式，一种是从上到下的模式。从下到上的开发模式是以现有的电子电气架构为基础，仅对某些附加功能和通信涉及的新部件加以补充，并执行相应的建模步骤。这种方式最适合于对现有电子电气架构的下一代进行开发。从上到下的模式则适合应用于新的车辆平台的开发。

4.开发工具链

在电子电气架构设计过程中需要应用到很多电子设计自动化（Electronics Design Automation, EDA）工具，比较有代表性的有DOORS（需求管理工具）、PreeVision（电子电气架构设计工具）、Capital（线束设计软件），通过应用EDA设计软件，可以提高开发效率和开发准确性。

整车电子电气系统开发过程中，会涉及需求、功能设计、网络设计、功能分配、线束设计等多方面内容，由不同的部门或工程团队进行共同开发。为了实现多团队并行开发过程中的合理分工与协作，整个电子电气架构设计需要按照分层设计的思路展开，如图2-7所示。在模型开发过程中需要进行不断的评估优化，最终选择最优的设计方案。

PreeVision开发过程包括按照架构模型的开发逻辑和V模型的开发过程，分为需求定义、功能逻辑设计、硬件系统设计、线束层设计和拓扑层设计几个部分。

（1）需求定义

该层需要导入需求开发的工作成果——需求规范，也可以直接将需求开发的工作在此阶段开展。该层用来描述电子电气系统要实现的功能需求和非功能需求，是电子电气架构设计的起始点。

（2）功能逻辑设计

该层约定整个系统功能的逻辑实现方法。功能网络层的内容包括逻辑传感器、功能块、逻辑执行器等功能模块，以及各功能模块之间的信息交互接口。当功能网络层各模块之间的端口通过信息交互接口连接后，相应模块就能进行数据和控制信息的交换。在功能网络里，用户可以看到各功能模块之间的逻辑关系。

（3）硬件系统设计

该层主要包括网络层、部件层和线路原理层。网络层描述各部件之间的逻辑连接方式，如总线系统、传统连接、电源供应和地线连接，这些连接将在随后的线路原理层进行进一步的细化；部件层描述每个部件内部构成及其对外接口的详细信息；线路原理层描述网络层中逻辑连接的具体实现情况，如具体的导线、线缆连接方式、保险继电器盒的内部结构等。

（4）线束层设计

逻辑和原理性的连接关系在线束层中进行物理实现。该层中可以将线路原理层的连接关系在电线和电缆两方面进一步细化，将线束特定的属性添加到模型中。在该层中每段电线（或电缆）及相应的接插件都具有其物理属性（包括单位长度重量、成本、过电流能力等信息）。线束元素将来可以在拓扑结构中形成具体的电线和电缆布局（包括结合点和对接插头的布局等）。

（5）拓扑层设计

该层描述了电子电气系统的实际布置情况。设计人员需要根据实际情况，确定各个部件以及线束的最终安装位置，需要设定不同安装位置之间的“线路段”的具体长度。之后便可以得出电子电气系统中的整个线束的统计长度。

2.1.3 汽车电子电气架构发展趋势

1.电动化

随着汽车电子电气架构的发展，全电力和数据网络冗余将变得至关重要。对可靠性要求较高的安全类关键应用，将利用整个冗余圈来完成所有对安全行驶至关重要的工作，如数据传输和电力供应等。电动汽车、中央计算机和高耗能分散式计算网络都需要具备冗余性的新型能源管理网络。线控转向和其他自动驾驶功能所需的高容错性，同样需要冗余系统设计。这一切尚难以在目前的故障保护监控应用架构上完成，仍有待进一步突破。

电动汽车属于新能源范畴，得到了各国政府的大力支持。一方面，电动汽车可以很好地解决各国政府所焦虑的能源结构多元化的问题；另一方面，电动汽车可以解决城市里汽车尾气污染问题。因此，电动汽车行业便成了各国优先扶持和发展的朝阳产业。通常，一个行业的发展需要技术、政策和市场三方面的支持，而在电动汽车行业发展中，政策明显走在了市场需求前面。图2-8所示为各国禁售燃油车时间表，挪威和荷兰宣布将于2025年禁售传统燃油车。法国则称最迟2040年禁售燃油车。印度称要在2030年禁售传统燃油车。而向来保守的汽车强国——德国，在2016年11月通过联邦内阁决议，宣布在2030年禁售传统燃油车，这在整个汽车市场和汽车行业引起了极大的轰动。

2.智能化

（1）ECU从分布式控制到集中式处理，域控制器成为主流

随着自动驾驶的发展，软件功能复杂化和硬件系统冗余化的进一步提升，对处理时延会有更严格的要求，因此域控制器作为高性能集中式处理中心的方式更加合理。从系统时间同步、软硬件解耦合、系统通信速率等方面考虑，集中式处理具有明显优势。

智能网联需求持续推动汽车电子电气架构变革。随着汽车智能化、网联化发展，汽车电子底层硬件不再是由实现单一功能的单一芯片提供简单的逻辑计算，而是要具备可移植、可迭代和可拓展等特性。智能化与网联化共同推动了汽车电子电气架构的变革，一方面是车内网络拓扑的优化和实时、高速网络的启用，另一方面是ECU的功能进一步集成到域控制器。

图2-9所示为汽车电子电气架构发展趋势，从图中可以看到随着汽车海量数据处理需求的快速增长，ECU逐步从分布式向集中式架构演进，从车端向云端过渡，以满足不断增长的运算需求。

域控制器（Domain Control Unit, DCU）的概念最早由以博世、大陆、德尔福为首的Tier1（一级供应商）提出，是为了解决信息安全和ECU瓶颈的问题。根据汽车电子部件功能将整车划分为动力总成、车辆安全、车身电子、智能座舱和智能驾驶等几个域，利用处理能力更强的多核CPU（Central Processing Unit）或者其他高性能AI（人工智能）芯片相对集中地去控制每个域，以取代目前的分布式汽车电子电气架构。

一个好的域控制器架构，可以带来未来硬件和软件的复用，将大大降低车辆的维护成本和提升用户体验。这在部分量产车上已经有非常成熟的应用。

而从设计角度来讲，多域控制器架构一是能够将传感与处理分开，传感器与ECU不再是一一对应的关系，尤其对于原始设备制造商（Original Equipment Manufacture, OEM）来说，可以随意更换传感器的供货商（在标准协议的基础上）；二是平台本身的可扩展性，能够对接的传感器类型与数目并不固定，可以根据OEM的需求对应开发。

自动驾驶域控制器注重的是灵活可用，满足端客户需求，因此在具体的实现方案上会有多种选择。域控制器在业内已经形成共识，无论是主机厂还是Tier1，都在加大研发力度。在下一代的车型中，域控制器将会成为主流。

（2）车载传感器数量将飞速增加且智能化和融合度越来越高

在今后两到三代汽车产品上，整车企业将安装多个具备相似功能的传感器，以确保车辆具有充足的安全冗余。长期看来，行业将开发更完善的传感器解决方案来减少传感器数量和成本。未来的高级算法与机器学习可增强传感器性能和可靠程度，再辅之更加强大的传感器技术，传感器冗余将有望减少。集成化的智能传感器将被用来管理自动驾驶所需的大量数据。传感器融合和3D定位等高级功能将在中心化运算平台上进行，预处理、筛选和快速反应则很可能直接在传感器内完成。据估算，一辆自动驾驶汽车每小时产生的数据量将达4TB，因此传感器将需要完成部分传统由ECU完成的工作。为确保正确运转，新一代传感器清洁系统，如除冰除尘等，将尤为必要。

图2-10所示为自动驾驶传感器功能评级，每种传感器都有自己最适合的工况，每种传感器都有自己无法克服的缺陷，因此“量”无法解决“质”的问题。真正的解决之道是综合不同传感器采集到的信息。举例来说，CMOS（互补金属氧化物半导体）摄像头在雨雾环境下就会“失明”，强光和弱光环境它也不能处理。现在的雷达技术在分辨率上也有些不合格，因此可以说每种传感器都有自己的软肋。

想做到完美的传感器融合，就要接受不同传感器的输入，并利用综合信息更准确地感知周边环境，其得出的结果比不同传感器各自为战要好得多，因此传感器融合才是未来的大趋势。

值得一提的是，将不同传感器进行融合还能换来一定程度的冗余，即使某个传感器出了问题（自然原因或人为）也不会影响车辆的安全。在驾驶人依然手握转向盘的阶段，这种冗余看似用处不大，但到了全自动驾驶的时代，一定程度的冗余就能给驾驶人换来自救的时间窗口。

不同等级的自动驾驶具有不同的方案，也需要不同的传感器。而按照NHTSA（美国国家公路交通安全管理局）和SAE（国际自动机工程师学会）对自动驾驶的划分，目前市场上在售的诸多具备车身稳定系统、防抱死制动系统、自动紧急制动系统、牵引力控制系统等功能的汽车已经达到了L1等级的自动驾驶，而人们熟悉的谷歌自动驾驶汽车，到目前为止也未能达到L4等级的自动驾驶。目前业界讨论的自动驾驶，更多的是L3和L4等级。

图2-11所示为自动驾驶传感器市场预测，预计2022年激光雷达市场营收将达到16亿美元，雷达市场营收将达到0.44亿美元，摄像头市场营收将达到6亿美元，惯性测量单元市场营收将达到9亿美元，全球导航卫星系统市场营收将达到1亿美元。更长远地看，预计2032年传感器硬件的总体营收将达到770亿美元，而计算硬件约为520亿美元。

3.网联化

（1）车载高性能网络快速发展

数据量的提升、自动驾驶的冗余要求、互联环境下的安全保障，以及跨行业标准协议的需求很有可能催生汽车以太网，并使其成为冗余中央数据总线的关键助推因素。以太网解决方案可以实现跨域通信，并通过添加以太网扩展，如AVB（音-视频桥接）和TSN（时间敏感网络）等，来满足实时性要求。

本地互联网络、控制器局域网络等传统网络将继续在车辆上运用，但仅用于封闭式的低级网络，如传感器和执行器等。FlexRay和面向媒体的系统传输（Media Oriented System Transport, MOST）等技术有可能被汽车以太网及其扩展（如AVB、TSN等）取代。整车企业会严控与功能安全及自动驾驶相关的数据互联，但将为第三方访问数据开放接口。发送与接收安全关键数据的中央互联网关将始终直接且仅连接到整车企业的后台，第三方会被允许进行数据访问（被监管法规排除的场景除外）。然而，在车辆APP化的推动下，资讯娱乐系统的新兴开放接口将允许内容和应用程序供应商加载内容，而整车企业将尽可能严格地保持各自的标准。

图2-12所示为域级车载以太网架构，以太网为车载网络骨干，集成动力总成、底盘、车身、多媒体、辅助驾驶，真正形成一个域级别的汽车网络。这种网络架构引入了一个新问题：如何组织ECU和网络管理者之间的通信，不可否认的是，这种分层式的架构会造成控制器通过以太网骨干网和交换机通信时所需的软件内容增加。有研究预计，以太网有望在2020年成为主要的汽车网络技术，预计到2025年可能替换所有其他的车载网络。

（2）汽车将在云端结合车内及车外信息以及OTA（Over-The-Air）更新

虽然非车企以外的企业参与程度仍取决于监管法规，非敏感数据（即非隐私或安全相关数据）仍然有望更多地在云端进行处理。随着数据量的增长，大数据分析将被越来越多地应用于数据处理，并将基于数据处理结果制定相应的行动方案。

基于数据的自动驾驶的应用及其他各项数字化创新将依赖于不同企业之间的数据共享。当然现在仍然不清楚不同企业间的数据共享将如何实现、由谁实现，但主要的传统供应商和技术企业已经开始建立有能力处理这种海量数据的集成化平台。通过车载测试系统，汽车可以实现自动检查功能和集成更新，从而推动生命周期管理，以及增强或解锁产品的售后功能。所有ECU都会与传感器和执行器交换数据，并检索数据包来支持创新性用例，如基于车辆参数的路线计算。

OTA更新是自动驾驶的前提条件，它还将有助于开发新功能、确保网络安全，并使车企得以更快部署功能与软件。车辆将在全生命周期内获取功能性及安全性升级。监管部门可能强制要求软件维护，以确保车辆设计的安全完整性。更新和维护软件的责任将在车辆维护与运行领域催生新业务模式。

OTA更新的基本流程如下：

1）管理和生成相关的文件：云端服务器是负责监测整个OTA更新过程的主要单元，它不仅要确定更新哪些车辆，是否与车辆建立可靠的连接（生成一个可靠的可信通道）并实时掌握消息，还要把固件包或者更新包从软件库里面提取出来，确定分发包的更新顺序，管理整个进程，并在完成后校验。

2）分发和检查：服务器端负责加密渠道分发，车端控制器负责接收服务器指令，并对更新包进行下载、验证和解密。针对每次更新，服务器与车端配合对过程进行监控。车端控制器必须具备足够的存储空间及计算能力。与服务器相对应的也有作业管理器负责报告当前状态和错误信息，每个更新作业都有一个用于跟踪使用情况的作业ID（身份识别码）。

3）更新和刷新安装：这里一定有读者会提问，车辆如果像手机一样刷死机了怎么办？通常整车企业在决定FOTA前需要做完备的考虑。以特斯拉为例，图2-13所示为特斯拉OTA架构，通过使用运算的联网模块（如仪表盘、中控台等）实现对整个进程的监控。将更新文件刷入ECU，对于仪表盘来说，每一步操作都会监控整个机制是否完整，并且保证能随时停止和重新写入，只要对应的ECU存在可以运行的导引程序，那么就保证了车辆和服务器对整个过程的控制，并把刷死机的风险降到最低。

完成最后的准备工作后，ECU将重新启动，代理和服务器之间将持续连接，服务器可以获得当前更新状态的最新信息。