2.3 新型电子电气架构的挑战

互联网技术和移动通信技术的成熟将大大加快电子电气架构在当前基础上的进一步演进。计算机技术的高速发展推动控制器计算能力向中央和云端集中，汽车电子电气架构朝着集成式、服务器式这一方向演进。

目前，车载服务器已经被开发出来，可用于预定义功能的应用软件和第三方软件及服务平台，凭此可实现新的移动概念，提升终端用户体验。这对于汽车电子电气架构而言，是未来发展的驱动力量和发展机遇，车辆智能网联化发展为汽车电子电气架构带来了更大的挑战。

1.安全问题

随着汽车电气化、智能化、网联化的发展，汽车功能越来越复杂，数据信息呈指数级增加。而数据涉及用户隐私和人身安全，必须系统分析安全漏洞与威胁风险，实施有效的安全防护策略，部署相关安全措施，如图2-16所示。

功能安全是指避免由系统功能故障导致的不可接受的风险，重点关注系统发生故障之后的行为因素，致力于找出所有可能的系统失效原因，并针对这些失效原因制定相应的安全机制，采取相应的安全措施。

电子电气架构面临的功能安全挑战主要体现在感知冗余和自动驾驶控制冗余两方面。车辆的电子电气架构从最初的单激光雷达单摄像头架构，到后来的多激光雷达多摄像头架构及复合摄像头架构，这些架构中不同种类的摄像头、激光雷达都需要进行安全冗余设计。在传感器出现故障后，系统能够依靠冗余备份的传感器进行工作，保证车辆正常行驶。在自动驾驶系统中，自动驾驶域控制器主要负责决策、路径规划控制。为了避免由自动驾驶域控制器失效引起的系统故障，自动驾驶域控制器也要采用冗余设计（一般采用双冗余设计），当主用自动驾驶域控制器失效时，备用自动驾驶域控制器开始工作。

预期功能安全的关注点是由于功能不足、可合理预见的人员误用所导致的危害和风险。例如，传感系统在暴雨、积雪等天气情况下，本身并未发生故障，但能否执行预期的功能是预期功能安全的重点。

信息安全问题一是车载系统本身的网络安全风险迅速增加，智能网联化升级带来代码数量增加，而代码所存在的漏洞是与生俱来的；二是汽车智能网联化功能大幅增加，汽车成为车联网系统中的关键信息节点，人、车、路、云之间的信息传输存在风险；三是云端安全隐患，即车联网云端服务器可能存在安全漏洞，导致黑客通过云端发送恶意文件、向车辆下达指令等问题。

由于汽车产业涉及诸多领域，汽车数据处理能力日益增强，汽车数据规模庞大，汽车数据安全问题和风险隐患也日益突出。例如，汽车数据处理者超越实际需要过度收集重要数据；未经用户同意，违规处理用户个人信息，特别是个人敏感信息；未经安全评估，违规出境重要数据等。因此，亟须加强汽车数据安全管理，防范化解上述安全问题和风险隐患。

2.通信架构

随着汽车电子电气架构日益复杂化，其中的传感器、控制器和接口越来越多，自动驾驶也需要海量的数据用于实时分析决策，要求车内外通信具有高传输速率、低时延和多通信链路，这对架构的通信能力提出了更高的要求。通信架构升级是电子电气架构亟须解决的问题，如图2-17所示。

3.计算能力

智能网联汽车的发展对于电子电气架构的另一个挑战是控制器算力。智能网联汽车功能繁多，对汽车处理器性能的要求越来越高。据评估，自动驾驶等级每提高一级，算力需要增加一个数量级。L2级别大概需要2TFLOPS的算力，L3级别需要24TFLOPS的算力，L4级别为320TFLOPS，L5级别为4000+TFLOPS，如图2-18所示。如此巨大的算力需求，对于电子电气架构是个巨大的考验。

4.硬件超前部署

硬件和软件的分离，以及软件的爆炸性增长，远远超过了技术的变化。软件由于标准化的接口和模块化，可以实现重复使用。一旦汽车成为一个由软件、应用程序和新功能组成的生态系统的移动数据中心，就需要实现硬件的超前部署。功能不再是一个由ECU和软件组成的固定品，而是整个生态系统的一部分。虽然过去的标准是将每个ECU的计算和存储能力及其基础设施限制在最低水平，但HPC提供了从不同来源（新软件供应商、开源社区）OTA安装额外功能的可能性。如果在HPC中提供了足够的资源作为未来的性能缓冲，那么硬件在未来几年内都是适用的，也为随后实现新的基于数据和服务的商业模式（功能升级、新功能）提供了可能性。因此，硬件必须满足未来5年甚至10年的需求，确保计算能力和存储能力满足未来功能的扩展。

5.软件架构

随着汽车及其环境中的软件驱动创新不断增加，其复杂度也在快速增长，甚至在有些情况下，复杂度已经超出了可以控制的范围。软件驱动创新的快速增长也是汽车电子日趋复杂的驱动力之一，如图2-19所示。

为了管控快速增长的复杂度，汽车软件需要一个清晰的架构。当今的架构演进是各公司关注的重点。架构的影响是多方面的，主要包括：系统模型、测试、功能安全；具有安全通信、面向服务式高级操作系统（如Adaptive AUTOSAR）；ADAS（高级驾驶员辅助系统）和自动驾驶的多传感器融合和图片识别；车辆控制器固件远程更新所需的端对端信息安全；云技术和IT骨干网与数十亿辆汽车及其车载设备的连接，以实现信息娱乐、在线应用、远程诊断和紧急呼叫处理。

6.开发模式

为了确保汽车中安全攸关系统的安全性和可回溯性，以及为了明确责任认定，汽车软件行业如今普遍采用ISO 26262和ASPICE等标准作为软件开发的方法和流程。汽车行业的供应商多数采用传统的瀑布式流程或V型流程来进行软件开发，并编制出大量的相关支持文档。这种流程不仅烦琐，而且越来越不适应如今快速变化的市场需求。

开发汽车控制软件毫无疑问是一个系统工程。V型流程通常先冻结需求，再让软件和测试团队开始工作，这在实际操作中是很难实现的。因为客户需求在不断变化，软件团队也需要不断调整工作策略。因此，越来越多的软件团队如今倾向于使用敏捷框架进行软件开发，以缩短软件迭代的时间，在保证软件安全性和完备性的前提下，更好地实现不同职能团队之间的协作。

软件定义汽车整车开发模式结合了传统软件开发模式和整车V型开发模式的优点，具备快速迭代、持续集成、并行开发、多平台适用及用户个性化等特点，如图2-20所示。

在软件定义汽车整车开发模式中，首先进行系统解耦分析，将整车解耦为子系统进行需求分析，然后进入持续集成开发阶段，按照“设计-开发-测试-发布”循环往复进行，持续将软硬件集成至系统主干上，最终完成发布。在持续集成开发阶段，各类开发工具平台如CarSim、PreScan、CARLA等的适用性可使整车开发效率大幅提升。整车投入使用后，根据用户反馈情况进行快速迭代，再次经历“系统需求分析-持续集成”的流程并通过OTA技术完成功能发布。

软件定义汽车整车开发模式继承了传统软件开发模式的优势，通过并行开发、持续集成，高效利用多开发工具平台的优势，可极大地提升整车系统的开发和测试效率。同时，利用快速迭代的软件开发模式可使用户个性化需求得到最大程度的满足，使整车开发贯穿全产品使用周期。

7.供给关系

软件定义汽车的概念出现后，传统的主机厂、Tier1的垂直关系会变成主机厂与合作伙伴之间相互交叉、协同和合作的关系，形成一个开发的生态群，大家一起把产品做好，如图2-21所示。

功能实现不再只依靠硬件，算法、软件成为功能实现的重要组成部分，随之也出现以算法、软件供应商为主的新型Tier0.5级供应商，如自动驾驶算法、自动驾驶解决方案、人工智能、OTA系统、信息安全等全新供应商，新的生态群合作模式会进一步深度化。