电子发烧友App
汽车“四化”发展方向是汽车工业未来的发展趋势，其中包含自动驾驶、网联化、动力系统电气化和共享移动化。随着智能驾驶技术对于整车智能化程度要求的不断提升，对其整车的控制能力要求也大幅提升，这一过程推动整车电子电器架构逐渐从分布式架构向集中式专用域控制器架构进行不断演进和发展，以便提供更加高速、安全、可靠的电子架构。这一过程中，不仅要求智能驾驶功能能够运行在具有高性能软件到硬件集成的专用中央域控制器上，同时也要求整车控制这块也需要运行于稳定性、可靠性极高的中央与控制器上，这样的中央域控制器不仅需要充当对于整个车身控制的终端，也需要执行包含中央网关、动力、底盘等各域的综合控制系统端。这也是实现后续作为面向服务开发的前置条件。
本文将针对整车中央域控单元VDC从硬件、软件设计两个方面进行详细的方案设计介绍，以方便对整体控制能力进行详述。
1.整车域控硬件设计方案介绍
整车域控VDC的设计包含整机设计，具体硬件方案，视频输入/输出，通信链路、供电终端、存储终端。
1、硬件总体设计
从整个整车域控设计思路上讲，需要考虑MCU和MPU在整车域控中需要达到一定的功能安全等级前提下，满足对整车域控的控制能力输出。此外，设置通用接口GPIO用于对整车其他域控的输出指令控制（如油门开度、制动开关、输入唤醒、输出唤醒等）。设置CAN、ETH、LIN接口用于通信连接分别传输不同的数据类型；设置基础时钟晶振用于上下电时钟同步；设置双路供电电源用于考虑整车域控整体不会因为供电故障导致的失效。
从上图可以看出，整车域控从功能角度上讲就是一个多维度的准集中式中央处理单元，不仅需要执行包含低阶行泊车控制功能，还需要执行对整个底盘系统的整体控制，同时也需要承担中央网关的通信路由转发等功能。因此，在设计过程各种需要将各种不同功能性能的芯片能力充分调动起来，比如考虑实现低阶行泊一体控制能力，可以采用双TDA4VM或双J3这类中度算力芯片进行搭载。而考虑到实现中央网关功能，则可以考虑利用常见的网关芯片DRA821等。同时为了从终端控制上增强其功能安全特性，也可以在执行对整车控制输出端口，加入典型的高安全等级MCU芯片，如英飞凌的TC397或华为的麒麟系列。
高配版本的VDC需要考虑一部分功能为智驾功能预留。因此整车域控的设计过程将比传统的简单ECU复杂许多。典型的硬件端口设计思路参照如下图所示。
从配置整车智驾系统的角度出发，整车域控考虑了在一些关键设计环节上考虑对智驾域控做协同控制。一些主机厂的方案是将智驾系统的冗余控制放到整车域控端，比如设计将算力要求不高的单独前视摄像头接入整车域控VDC；同时也将只存在逻辑算力的毫米波雷达，超声波雷达数据通过CANFD协议连接至整车域控端。这里主要可以起到两方面的作用：
其一，是省功耗的运行低版本ADAS系统，比如在长续航模式或跛行回家这类整车运行状态下，还可以基本保留一些智驾系统功能，比如可以部分承载保留行车安全辅助性功能AEB、FCTA/B、RCTA/B，泊车报警辅助功能。
其二，是当主智驾域控失效时，整车域控检测到对应的失效状态后接管控制车辆，启动整车域控的基础视觉感知，并结合雷达数据进行轨迹规划和车辆控制，将车辆刹停至安全状态。
2、硬件结构设计
对于整车域控板间设计来说，考虑到其尺寸大小限制，同时可以考虑自身硬件级别的失效降级策略，可以将整车域控设计成双层板模式（主板和副板）。两层板间通过一定通信机制进行板间通信，当其中一个板子失效或出现问题时，可以启动另一块板子进行信息处理。 此外，对于硬件结构设计来说，通常比较关注整个域控的散热设计。业界对于整车域控的散热来说，通常可以采用风冷对流散热为主。通常，整车域控的双层板子采用一定的隔热设计，对于热设计来说也无需考虑其中一块板子的发热对另一块板子的散热影响。一般情况下，整车域控制器通常采用风冷散热。整个环境温度和通风程度对其会产生较大的影响。如下公式表示了芯片结温的影响要素。
芯片结温=环境温度+热阻*功耗
因此，整个散热过程大部分受制于环境温度影响，其中就需要充分考虑热对流的影响。散热设计基本原理：自然散热以辐射为主、风冷以对流为主。热量传递主要是3种方式：传导、对流、辐射。其中热传导主要是指分子之间的传递，主要是指盒子或模块内部的热扩散。主要涉及的传输链路为器件——>PCB——>外壳体。自然对流主要是指流体混合作用的热传递，包含盒子或模块与外部环境的热传递。热辐射主要是物体温度产生的电磁波传递能量。涉及盒子或模块与外部环境的热传递。如上自然对流和热辐射的传输链路都为外壳体——>环境。
如下图表示了一种典型的新能源车的散热设计流程图。
对于整车域控制器而言，由于其承载的相关联ECU终端是比较多的，就有可能造成计算过程中较大的热能，在做硬件设计中，其热设计过程将显得尤为重要。可以将整车域控制器布置在通风且空气对流较好的环境中，这里需要充分考虑其风道设计出口是否存在热风回灌的现象。
举个之前研发设计较为失败的粒子说明如何对散热设计才能取得较好的散热效果。
如下图所示，当设计整车控制器的风道朝向一边，而安装位置如果位于一个相对较为封闭的环境中，且出风口一边较为靠近密闭边界，那么就很可能其由控制器输出的热风被阻挡反弹回来。这样反弹回来的热空气又将重新进入入风口处，这样就不可能起到很好的散热。
因此在散热设计中需要从安装位置（安装位置不仅考虑通风性，还需要考虑出风口是否有足够的风道距离使其充分接触更多的冷空气来降温）、风道设计、控制器整体尺寸、功能降级（由系统工程师根据需要设定降级温度阈值，当超过某个值时降级全功能为部分功能。比如按照环境最高使用温度为85°，那么超过80°时，就将控制功能降级为仅存储功能）等方面进行全方位考虑。若温度规格降低，则整机尺寸可进一步降低（按照玻尔兹曼定律进行计算）。软件方面也可以增加动态温度-功耗控制措施。
当然最重要还是在选定布置位置时候选择最合适的布置位置，考虑痛风性、密闭温度限值等因素。当然也有部分有条件的情况下也可以考虑采用水冷措施，当然设计复杂度和成本也是较高。
3、硬件通信设计
VDC作为一种典型的中央网关，既要能支持CAN通信路由，也要能支持以太网通信路由。一般情况下，CAN通信由于其稳定性、安全性及成熟性。通常用来作为整车控制的信号协议类型，而Ethernet则是更多的承载智能终端数据通信，比如云端通信、智能驾驶数据显示等。
设计整车域控制器需要支持多路以太通信，从考虑缩小域控板子尺寸的角度出发考虑，通常将几种不同的芯片布置于不同的板层。本设计的过程考虑行泊车低阶控制过程中，两大重点发热芯片可能产生较大的发热量，因此，分别将两个MPU放在主板和副板上。此外，MCU放在主板上。主板和副板通过以太网Ethernet Switch连接至外部以太网通信端，整个Ethernet Switch的控制和配置由MCU完成。以太网Switch可以直接连出多路1000BASE-T1以及100BASE-TX接口。同时Switch还通过SGMII口和外扩PHY相连，可以引出多路1000BASE-T1口。对于实际通信连接过程中可以充分考虑通过多合一连接器进行信息合并，同时设计过程中充分考虑欠压监测、过温检测以及SQI的读取能力。
设计VDC时还需要使用关联ECU通信所需的N路CAN通信且兼容CAN-FD，CAN-FD接口电路采用标准CAN接口电路，支持ESD防护和终端匹配，每路CAN通信需要对应的终端匹配电阻，并预留一定大小的共模电感，选择性的根据EMC实测结果进行贴片。最重要的是支持任意帧CAN唤醒功能。
当然，对于一个标准的中央网关来说，还需要支持一定数量的LIN通信，并支持LIN唤醒，通信速率为1~20Kbps。默认为MASTER模式，通过电阻与二极管上拉配置，也可以根据具体需求配置成从模式，接口设计需要设计成ESD防护电路。
2.整车域控软件框架及部署介绍
整车域控的软件部署主要分为几个方面车控相关SWC、网关相关SWC、智驾系统SWC。其部署原则为对实时性要求较高功能部署在实时核，运算需求较高放在运算核，对功能安全要求较高的功能部署在锁步核。
以如上图中的整车域控架构为例。MCU部署动力控制、底盘控制、通讯管理、本地诊断、电性能以及设备抽象等软件模块。对应的算力主要是CPU逻辑算力，一般满足10K DMIPS即可。同时MCU需要承担整个VDC网络唤醒、诊断功能、电源管理相关功能。
1、网络管理功能
作为整车控制的终极大boss，VDC需要承担整个网络管理功能，其中网络管理涉及网络管理状态机设计，网络唤醒设计。
网络管理状态机中包含为整车域控设计各种工作模式。比如休眠（仅支持休眠唤醒状态）、待机（极低功耗）、准备（轻睡眠）、正常功耗（全功耗）、异常状态（故障检测）下的功耗等。各类不同的工作状态需要通过设置不同的跳转条件进行切换。
而对于网络管理中重要的唤醒功能而言，其需要支持不同的唤醒源，主要需要包含CAN、LIN、硬线、以太网。结合上面的附图说明唤醒过程。首先，四种唤醒源需要首先将SBC（一种包含电源、通信、监控诊断、安全监控等特性以及GPIO的独立芯片）唤醒，随即便可立即唤醒MCU。当MCU被唤醒后，可以对以太网Switch进行初始化配置确保以太网可以进行有效通信，这类初始化过程主要包括寄存器使能、收发路径绑定等。随后，MCU可以通过控制其他MPU的芯片供电来控制其余MPU的唤醒。
2、网络诊断功能
整个VDC域控的诊断过程包含远程诊断、近端诊断和OTA诊断。这三类诊断模型在构建诊断通道时，需要首先将VDC接入到车端网络中，实现两种诊断模式DoIP和DoCAN。通常，DoIP部署在MPU上，DoCAN部署在MCU上。通过VDC协议栈部署DoIP网关建立链路（包含支持DoIP-DoIP，DoIP-DoCAN双向诊断路由），部署DHCP客户端。
对于诊断来说一般需要根据如下不同的诊断接入场景设置相应的接入仲裁管理机制。这些诊断场景包括针对本地诊断、远程诊断、产线EOL下的OBD接入，针对OTA场景下的车内虚拟上位机接入。这三类OBD接入子场景通常情况下是不做具体区分的，而仅仅通过优先级判断可以在某一个固定的时刻激活其中一条链路。
对于OBD接入，优先级最高；车内上位机接入，优先级中；车云接入，优先级最低。当然，如果有两类接入诊断源输入时，通常需要由VDC进行有效的仲裁才能确保其功能多的正常响应。仲裁原则为：两个诊断业务优先级相同时，遵循先到先得、平等互斥的原则，当高优先级诊断接入低优先级诊断业务时，需要缓慢退出低优先级诊断，相应的高优先级诊断接入。当低优先级诊断接入高优先级诊断时，需要否定响应该低优先级诊断业务，并原路返回路由。
3、网关路由功能
针对VDC控制器在中央网关这一方面的作用而言，需要充分考虑其信号路由和协议转换方面的要求。其中，协议转换包括ETH数据转换成LIN/CAN数据、CAN报文间互转、ETH报文互转、CAN诊断报文转换成LIN/ETH诊断报文、ETH诊断报文转换成 LIN/ETH诊断报文。
VDC的网关路由功能模块通常是在一个专有的网关芯片（如前所述DRA821）上进行的，整个通信路由架构参照如下图所示。
整个VDC的PDUR Router模块功能包含单播、多播、网关1对多、多对一、多对多等多种方式的路由模块功能。期间，PDUR Router 需要执行PDU接收到本地模块（I-PDU从下接收发送至上层）、PDU从本地模块传输（I-PDU从上接收发送至下层）、PDU网关（从接口模块和传输协议模块接收I-PDU并传输至其他通信接口模块）这三种功能。从而确保路由功能的有效性。
4、低阶智驾功能
对于整车域控来讲，在设计过程中通常会连带作为智驾域控的低阶版本，或者也有部分车型在做配置分析时，直接将低配或次低配的智驾功能移植到整车域控中进行。这时整车域控就相当于一个base版本的行泊一体控制器，需要承担部分低阶行泊车控制功能。因此，对于在VDC中植入不同处理能力的芯片单元时，尽量选择具备集成式运算能力的超异构芯片。既能满足对行车功能的感知需求，也能满足对泊车感知能力需求。这里推荐的中等算力的集成式超异构芯片。可以采用目前国内正火的J3/J5，也可以考虑TI系列芯片TDA4VM即可。
同时，在对传感器的接入上需要充分考虑其所连接的智驾传感器单元。当然，由于VDC的算力不算多，因此，可能不能接入过多超算力的传感器（比如多组高分辨率摄像头、原始点云的毫米波雷达和激光雷达）。
从保证基础L2级及以下功能的角度上讲，需要接入包含前视摄像头（注意这里主要是前宽视摄像头），1个毫米波雷达以确保能够实现1R1V的基础L2传感器配置。此外，考虑泊车辅助系统控制，整个VDC也需要将泊车相关的传感器，环视+超声波接入。当然，考虑到如果只是实现低阶泊车辅助功能，其环视摄像头的分辨率可以不必向高阶全自动驾驶功能对齐，采用稍低分辨率也可。
审核编辑：汤梓红
工商网监
评论