技术干货 | 基于以太网的车载域控制器开发

1980年代随着IT技术的起步和兴起，在当时以机械为主宰的汽车行业内掀起了一场电子电气化革命。年轻的汽车电子系统迅猛发展，电子控制单元（Electronic Control Unit，ECU）占领了整个汽车，从防抱死制动系统、四轮驱动系统、电控自动变速器、主动悬架系统、安全气囊系统，逐渐延伸到了车身安全、网络、娱乐、传感控制系统等，逐渐成为汽车的重要组成部分。

此时的汽车电子电气架构都是分布式的，各个ECU都通过CAN（Controller Area Network，控制器域网络）或LIN（Local Interconnect Network，局部互联网络）总线连接在一起，通过工程师预设好的通信协议交换信息。

Strategy Analytics统计数据显示，各级别汽车ECU数量都在逐年递增，每台汽车搭载的ECU平均25个，而在一些高端车型中这一数量通常会超过100个。ECU数量越多，总线数量必将更长，2000年奔驰S级轿车的电子系统已经拥有80个ECU，1,900条总长达4km的通信总线。2007年奥迪Q7和保时捷卡宴（Cayenne）的总线长度突破6km，重量超过70kg，基本成为位列发动机之后的全车第二重部件。

为了控制总线长度、降低ECU数量（或者保持数量不变），从而降低电子部件重量、降低整车制造成本，分散的小传感器被逐渐集成为功能更强的单个传感器，将分散的控制器按照功能域划分、集成为运算能力更强的域控制器（Domain Control Unit，DCU）的想法应运而生。

除此之外，最近几年，随着ADAS（Advanced Driver Assistant System，高级驾驶辅助系统）的快速发展，包括停车辅助、车道偏离预警、夜视辅助、自适应巡航、碰撞避免、盲点侦测、驾驶员疲劳探测等在内的很多功能，如果采用分布式架构就无法适应需求。因为ADAS系统里有各种传感器（如摄像头、毫米波雷达和激光雷达等），产生的数据量很大，各种不同的功能都需要以这些数据为基础，每个传感器模块可以对数据进行预处理，通过车载以太网传输数据，为了保证数据处理的结果最优化，最好功能控制都集中在一个核心处理器里处理，这就产生了对域控制器的需求。

域控制器的概念最早由以博世、大陆为首的Tier1提出，它的出现是为了解决信息安全以及ECU瓶颈的问题。域控制器因为有强大的硬件计算能力与丰富的软件接口支持，使得更多核心功能模块集中于域控制器内，系统功能集成度大大提高，这样对于功能的感知与执行的硬件要求降低。加之数据交互的接口标准化，会让这些零部件变成标准零件，从而降低这部分零部件开发/制造成本。也就是说，外围零件只关注本身基本功能，而中央域控制器关注系统级功能实现。

所谓“域”，就是将汽车电子系统根据功能划分为若干个功能块，每个功能块内部的系统架构由域控制器为主导搭建，利用处理能力更强的多核CPU/GPU芯片相对集中地控制每个域，以取代目前的分布式电子电气架构。各个域内部的系统互联仍可使用现如今十分常用的CAN和FlexRay通信总线。而不同域之间的通讯，则需要由更高传输性能的以太网作为主干网络承担信息交换任务。

对于功能域的具体划分，不同整车厂会有自己的设计理念，如博世分为5个域：动力域、底盘域、座舱域、自动驾驶域、车身域，大众MEB平台车型为3个域：自动驾驶域、智能座舱域、车身控制域，华为同样也为3个域：自动驾驶域、智能座舱域、整车控制域。

下图给出了一种可能的划分方法。在每个功能域中，域控制器处于绝对中心，它们需要强大的计算能力、超高的实时性能以及大量的通信外设。

域控制器是以以太网为骨干网，面向服务的架构，按功能划分的集中化加速软硬件分离，节约整机成本，具体优点包括：

服务附加值提升

实现整车OTA功能后，整车厂可以通过系统升级持续地改进车辆功能，软件一定程度上实现了传统4S店的功能，可以持续地为提供车辆交付后的运营和服务。传统汽车产品交付就意味着损耗和折旧的开始，但软件OTA赋予汽车更多生命力，带来更好的用户体验。例如，自2012年Model S上市以来，特斯拉软件系统至今进行了多次大更新，平均几个月一次小更新，已经累计新增和改进功能超过50项，包括自动辅助驾驶、电池预热、自动泊车等功能。

算力集中化

可以真正地实现硬件标准化和软件开发重复利用，既实现供应商可替代，也可以大大缩短软件迭代周期，同时为日后第三方软件开发扫清了障碍。车辆将成为移动的智能终端，同时大量计算工作可以集中至车载中央处理器甚至云端，减少了内部冗余同时车联网协同成为可能。

内部结构简化

车载以太网开始取代CAN总线结构，半导体集成使得整车厂可以精简内部线束结构。例如，Model S内部线束长度长达3km，Model 3只有1.5km， Model Y的计划是将线束长度控制在100m。

服务接口定义：根据车辆架构的功能，将包含在网关控制器中的服务在PREEvision工具中设计。该服务包括服务提供者和服务消费者。服务提供者的主要工作是提供服务，服务消费者向服务提供者发送服务请求以获取服务功能，网关控制器车辆应用信息以服务接口的形式定义，主要包括方法、事件和属性。在PREEvision工具中，根据服务内容建立服务接口，定义其方法和事件。对于方法，需要定义其输入和输出参数。在这个设计过程中，服务的接口由AUTOSAR软件架构实现，服务提供者和消费者由AUTOSAR软件组件（SWC）实现，稍后分配给ECU组件。

图1.服务接口

图2.定义服务接口

图3.Autosar设计过程

图4.SWC 建模

SWCS 通过端口传输信息，服务接口封装到端口中。端口可分为“发送/接收数据”和“发送/接收服务”。SWC位于RTE的顶部，通过RTE调用底层协议接口来完成数据传输。在SWC中，服务提供方确认服务可用性，服务消费方确认服务请求状态;基本软件模式管理器（BSWM）用于管理服务模型和转发服务发现的可用性和请求状态到软件组件或者管理服务发现模块。

服务发现模块确认服务可用性和请求状态，并发送相应的 SD 消息（如 SD 提供服务消息），并根据接收到的SD消息转换为基本软件模式管理器模式。服务发现通过套接字适配器配置发送和接收的事件和方法。套接字适配器可以灵活分配PDU，实现多客户端接收，即一个PDU在多个套接字连接上动态发送，同时服务发现与SOME/IP模块通过套接字适配器完成信息交互。在工具中，建立相应的SWC和相应的接口。服务软件组件设计完成后，网关控制器可以通过服务发现将服务的可用性和位置发布到其他ECU。服务消息类型包括search service, provide / stop service, stop / subscribe event group and subscribe event group feedback。

图5.服务交互

图6.以太网通信协议

软件架构：车载网关控制器的底层通信协议如图6所示，其应用层的SWC组件在实时操作环境（RTE）上运行。在网关控制器的底层通信协议中，需要定义以太网报文的路由方式，并将服务的传输实例化为特定的信号和消息。通过达芬奇工具，以太网底部域控制器的通信层设计配置如图 7 所示。

图7.传输设计

该方案配备双MCU，其中飞思卡尔i.mx6q处理器用于复杂工况下算法的处理，恩智浦公司的S32K148处理器用于车辆信号路由;以太网网关包括CAN/CANFD和以太网通信模块，以太网通信模块电路由MAC控制和物理层PHY接口组成。以太网系统结构包括 5 通道 CAN（支持 4 通道 CAN FD）、1 路 Lin、4 路数字交换机采集、5 路 100base-t1、1 路 100base-tx 和 2 路电源输入。在以太网总线传输过程中，传输电缆本身和总线通道上的所有负载的损耗或多或少，包括电路消耗、滤波电路、电路转换器、各元件的连接器等。信号频率对衰减也有很大影响。基于此考虑，设计方案采用8层高密度板，布局和布线严格设置在规则中，以优化信号完整性设计。

图8.硬件原理实现

图9.硬件电路板设计

免责声明

本文来源于网络，文中观点仅供分享交流，不代表本公众号立场。如涉及版权等问题，请您告知，我们将及时处理。

关注公众号，实时关注智能汽车电子最新资讯