干货 | 整车电控系统及架构设计技术

本文的目的是基于我们对域控制设计方法的研究， 提出相关的设计过程和规则， 从而设计出我们3年后的新电控系统及架构平台， 也就为实现软件定义汽车和硬件通用化提供可能性。 同时， 也希望能为国内电控系统及架构设计标准化带来一些思考。

1、设计方法

1.1新电控系统和架构核心设计方法

旧的电控系统架构基于分布式和集成式设计方法， 其中每个电控系统都基于AUTOSAR软件架构设计， 对应的用户功能基本都在一个系统内完成。 而当前随着用户需求越来越多， 许多功能都是跨系统的。 因此， 从IT行业引入层次化和系统低耦合性。

1.1.1分布式和集成式设计方法

分布式和集成式设计方法的架构方案大致拓扑如图1所示。 这是一种基本上可以不依赖其他系统， 就可以实现功能需求的设计方法。 车载电子控制单元(Electronic Control Unit， ECU)都是一个相对独立的系统， 所有输入传感器､输出执行器和逻辑处理都在一个主ECU控制的系统内完成。 这造成整车ECU数量众多， 难以管理。

1.1.2域控制设计方法

域控制架构拓扑如图2所示， 主要内容如下:

①功能分解:实现功能逻辑与实际的物理硬线信号剥离， 并把功能逻辑集中到一个域控制器实现。

②接口标准化:域控制器与区域控制器信号接口和区域控制器与所有物理信号输入输出设备接口。

③区域划分:整理出所有输入输出设备， 并按位置区域进行分配， 接入区域控制器管理。

1.1.3SOA设计方法

SOA是面向对象的服务架构， 本文不做深入探讨。 车辆接入物联网后， 可以挖掘出来的各类相关功能应用(Applica-tion， APP)， 大大提升用户服务价值， 而这些应用就是基于SOA思想设计的。 这些APP就建立在域控制设计平台架构之上。 由于SOA思想刚刚导入车载系统， 以及当前系统和架构拓展性不足， 目前的APP挖掘不够多， 功能拓展性也不高。

2、新电控系统和架构设计

基于对分布和集成式､域控制和SOA设计方法的研究， 以及对当前车联网和软件定义汽车需求的分析， 我们归纳出当前车端及关联系统大致组成元素及层次关系， 如图3所示。

可以看出未来车载电控架构的主要ECU节点由域控制器､区域控制器和输入传感器､输出执行器组成。 相比于未来的最佳化模型， 基于当前零部件供应商发展现状， 一些独立的传统ECU控制器(如电子车身稳定系统， Electronic Stability Program， ESP)还会存在。 未来的架构之所以呈现出这种形态， 是因为我们按照域控制设计方法把整车的需求进行分解。 由这三部分硬件组成的车载电控系统就可完成软件功能的开发。

因此最终网络拓扑就是由这三种模块构成。 下面我们对这三个模块的特点进行详细说明。

2.1车载域控制器或服务器的特点

由于当前的ECU模块芯片的算力有限， 所以在某些任务(如自动驾驶和智能座舱等)执行时存在计算性能不佳的问题。 当前流行分法为主域控制器(未来发展成车载服务器)､智驾域和信息娱乐域控制器， 它的关键性能指标如下:

①强大的计算能力， 用来完成纯功能逻辑处理。

②强大的网络连接和管理能力， 用来接收各种信息和发送控制指令的能力。

③满足从汽车安全完整性等级(Automotive Safety Integ-rityLevel， ASIL)的A到D所有功能安全等级的要求。

④快速启动和响应的能力。

⑤系统功耗与散热的平衡性。

⑥系统硬件平台方案的伸缩性， 如计算能力和芯片兼容性都有很大可选范围。

⑦系统软件平台方案的移植能力。

⑧模块外接电气接口比较少， 主要是电源和网络物理接口， 尽量提升模块的通用率。

当前域控制器发展具体的特征如下:

①由于芯片计算能力不足， 当前发展主流是主域､信息娱乐域和智驾域控制器， 主域集成中央网关功能。

②车载以太网已经成为域控制器间通信必备， 且域间可变速率的控制器局域网络(Controller Area Network with Flexible Data-Rate， CAN-FD)通信一定存在， 用于实时性和安全性的要求高于通信要求。

③域控制器支持多路以太网､CAN-FD和串行通信总线(Local Interconnect Network， LIN)， 用来拓展连接能力， 一般不带其他接口类型(如高低电平电气接口)。

④域控制器硬件平台当前是微控制单元(Micro con-troller Unit， MCU)+微处理器(Micro processor Unit， MPU)， 未来芯片集成度会越高， 偏向尽量一颗芯片搞定一切， 例如集成直流变换器(Direct Current/Direct Current， DC/DC)､CAN和LIN收发器等。

⑤智驾域控制器由于传感器的接口和协议没有标准化， 所以智驾域最终的网络形式还未确定。

⑥域控制器的软硬件平台目前已经统一， 通过同系列不同型号统一硬件平台， 通过Hypervisor和Adapter Autosar等实现应用APP的平台化。

2.2车载区域控制器特点

区域控制器能够接收输入传感器的信息和来自域控制的指令， 并控制实际的输出执行器， 以及把输出执行器和输入传感器状态发给域控制器｡它的关键性能指标如下:

①处理纯功能逻辑少， 以实时操作系统和微处理器为特点的平台， 主要完成一些实时性高的功能。

②支持很多路CAN和LIN， 以及一或两路以太网网络连接能力。

③满足ASIL从A到D所有等级功能安全的要求。

④启动和响应的能力。

⑤不用考虑增加额外的散热器件。

⑥系统硬件平台方案的伸缩性， 如计算能力和芯片兼容性都有很大可选范围。

⑦系统软件平台方案的移植能力。

⑧模块外接电气接口比较多， 但是后续都是通用的I/O接口。

当前区域控制器发展特征如下:

①功能执行要求实时性较强， 硬件一般以MCU(视频需求除外)为主。

②区域控制器当前无引入以太网的需求， 随着智驾方案确认才有可能引入以太网， 区域控制器主要以CAN､LIN和硬线等方式拓展功能灵活性。

③区域控制器的数量与整车的定位有关， 但是对于一款车型， 区域控制器的数量是固定的， 只有输入输出传感器和执行器的数量是变化的。

④区域控制器软硬件平台可以统一， 对比之前设计复杂度会降低， 重点在于整车厂的系统设计能力。

2.3输入传感器和输出执行器特点

随着智驾技术的发展， 各种各样的传感器和执行器被应用到车辆。 目前有多家供应商提供相关产品， 每家的思路不尽相同， 导致同种类型的传感器多种多样。 这就需要整车厂的系统设计和引导， 并在机械结构､分类方法､信号接口等几个方面对传感器进行标准化规范。

输入传感器的形状､结构和接口在未来会进一步标准化， 便于零件的通用化， 特别是对于大的整车厂更需如此。

输入传感器分类标准化， 如开关､视频､超声波雷达和加速度传感器等， 并且要对电气接口或通信协议进行标准化设计。

输入传感器与上层区域控制器接口实现标准化。 开关接口为高低电平､脉冲宽度调制(Pulse Width Modulation， PWM)和模数(Analogue/Digital， AD)， 以及超声波雷达和摄像头等。

3、域控制设计方法实现过程

原来整车系统及架构都是功能需求分析后， 大多直接把功能块分配给ECU， 再进行相关方案设计。 而新一代的电子架构的系统更加复杂， 所以正向开发显得尤为重要。 下面简要说明在原来开发过程需要增加的工作。

3.1功能需求分解

功能需求分解是把每个子功能块涉及的硬件(输入和输出)与功能逻辑分离。 也可以在原来的功能块定义的基础上进行分离， 并确定输入传感器和输出执行器件种类和数量。

3.2标准化所有的输入输出物理信号

根据功能定义和输入输出设备特性， 定义和设计所有输入输出物理信号， 包括信号名称和信号状态定义等。 如图4所示， 以中控门锁的模块设计为例， 对输入输出信号标准化进行说明。

3.3驱动层逻辑块定义

驱动层是直接接收和控制输入输出的物理信号的逻辑设计， 如图5所示。

3.4纯功能逻辑块定义

首先纯功能块定义一定要增加一个类似设备服务层(图6)， 提供一个唯一可调用所有输入输出设备提供服务的接口， 用来调度设备服务和监控设备的运行状态。

车辆通用功能块不宜太小， 可以参考功能列表来定义一部分功能块。 以功能模块独立性高､与外部输入输出接口信号少为优， 目的是减少功能逻辑耦合性。 图7所示为中控门锁功能设计。

3.5子系统(区域控制器)设计

根据车身结构､线束布局和装配工艺等特点， 把车身分为几大区域。 根据所处位置将输入输出物理硬件归入对应区域中， 计算出各区域输入输出物理硬件数量， 得出具体的接口需求。 根据接口数量合理设计出子系统的数量， 接口需求少的可以进行区域集成， 两个区域的信号合成一个子系统。 每个子系统都有一个主控ECU模块(区域控制器)。

相应的驱动层逻辑块属于区域控制器执行的内部， 再系统评估出MCU性能是否满足所有功能实时性要求。 同时ECU基于域控制设计思想， 对应的AUTOSAR软件架构需要做出相应变更， 如图8和图9所示。

主要差异点如下：

①可以发现随着应用功能的上移， 软件架构的运行环境(Run–Time Environment， RTE)和APP层会最终消失。

②由于域控制诊断方法， 系统服务层需要进行设计变更。

③由于区域控制器的网络连接和通信能力要求高， 并涉及相关的输入输出设备状态和接收指令， 所以通信层需要做出设计变更。

从中可以发现区域控制器ECU软件得到大大简化， 再加上平台化后， 软件稳定性和效率大大提升。

3.6域控制器设计

纯功能逻辑块大多都归入域控制器执行， 由于是不基于硬件， 域控制器处理性能有关。 但是完整的功能实现， 与每个设备同步性和实时性相关， 而实时性主要由以下几个参数决定:

①功能总的时间=信号采集时间+信号传递时间+逻辑处理时间+执行器硬件执行时间。

②信号采集时间和硬件执行时间:在器件选型后基本已经确定， 当然也可以改进。

③信号传递时间:通信方式和中转过程等。

④逻辑处理时间:本身逻辑复杂度､操作系统(Oper-System， OS)性能和处理器性能等。

特别说明的是， 整车初次上电实时性高的功能时， 一定要考虑应用启动时长， 不能存在功能失效的严重风险。

域控制器的软件架构分为MPU和MCU两部分， 这里主要说明MCU部分。 当前整车的通用功能， 如灯光和刮水器功能等， 这些控制类､逻辑简单､实时性高的功能都在MCU上实现， 具体的软件架构如图10所示。

域控制器MCU主要差异点如下:

①除模块本地系统服务外， 增加了域内设备服务和调度层， 为上层应用提供调用接口， 而不是通过RTE来实现， 包括接收MPU请求和反馈设备状态等。

②系统服务层提供的诊断服务， 涉及整个域内设备， 并整合系统功能故障等。

③当前整车通用纯逻辑功能绝大多数在MCU的APP层

MPU上实现一些计算能力要求高的功能， 如导航､音乐､视频和智驾等， 通过MCU和MPU间通信实现系统功能， 但是目前软件架构的标准化还处于初步阶段， 需要一定周期。

4、域控制设计方法优点和风险

域控制设计方法让车辆与外界实现很好的互联､互通和应用的协同性， 真正打通了物联网与车端的应用， 做到了完美连接， 同时带来以下价值。

4.1域控制设计方法优点

4.1.1电控系统软件和硬件平台化

域控制设计方法最终实现整车所有域控制器和区域控制器模块平台化。 多个硬件和软件都集中在同一个平台， 大大提升硬件和软件的复用率， 后期效率呈倍数级提升。 后续硬件可直接拔插升级， 软件空中升级也相当方便。

4.1.2网络拓扑的优化和负载率降低

网络拓扑的优化和负载率降低， 域控制设计方法可以大大降低总线的信号数量， 以及更加清晰地设计网络的拓扑结构。

4.1.3降本减重的需求

首先实现零部件的平台化， 未来装车量的增加， 零部件本身成本会有大幅下降ꎻ 其次， 由于设计方法中已经考虑了区域的问题， 所以线束长度和数量都会减少， 成本也将降低。

4.1.4软件定义汽车最好平台

软件定义汽车实现离不开整车电子电器提供的服务， 而域控制设计方法实现软硬件分离， 并充分挖掘出每个输入输出能提供的服务， 便于上层APP设计出更能给用户带来价值的功能。

4.2域控制设计方法风险

目前新架构还处于逐步成熟的过程中， 也有一些不确定因素， 主要风险如下:

①整车的系统设计能力不足， 需要一批对零部件设计比较熟悉的系统工程师， 从而决定域控制器和区域控制器模块数量及接口标准化程度。

②由于零部件供应商对整车厂需求并不是很清楚， 只是推出相关硬件和软件平台， 对于实际应该具有的功能并不明确， 所以难以确定最终的成本和价值是否合适。

③域控制器和区域控制器模块与主芯片紧密相关， NXP､英飞凌和瑞萨等厂商对于此设计处于刚刚定型状态。

④域控制器的软件成熟度和标准化都不完善。 虽说有和ETAS等专业软件设计供应商， 可是目前其产品也不够成熟。

⑤传感器和执行器模块等也没有标准化的管理， 不同的厂家接口千差万别， 如CAN-FD､以太网和低压差分信号接口(Low-Voltage Differential Signaling， LVDS)等。

⑥对于车载以太网的应用也正在研究， 在以太网诊断､安全和管理等方面并不是很成熟。 尽管相关的协议大都从传统互联网而来， 但是具体到车载以太网的数据协议， 其实时性和安全性能否真正满足车载的应用还在进一步研究。

⑦面临信息安全问题， 方案成熟度有待验证。

⑧目前真正成熟的能够提供用户价值的APP很少， 需求还在挖掘中， 造成具体收益未知。

5、结论

尽管目前有很多关于SOA的讨论， 但服务需要有一个良好的平台， 且SOME/IP (Scalableservice-Oriented Middle-war EoverIP)当前并不成熟， 本身车载以太网存在很多问题。 我们研究域控制设计方法， 目的是打造全新的整车电控系统和架构， 并为域控制器上实现SOA设计思想提供一个开发性的软硬件平台。 当然， 这也是技术发展和经济效益结合的产物。

来源：电动学堂