《特别节目》你那么好看，让我只想搂你睡觉

新能源商用车车身功能越来越多,给车身控制和整车线束带来了新的挑战。为降低控制器数量和成本,减少整车线束的复杂程度,需要将原本多个独立的控制器集中在一个控制器上,域控制器的概念由此提出[1]。徐工汽车原有车身域控制器设计方案采用单个微控制单元(microcontroller unit,MCU)作为主控处理器,在集成了更多功能以后,原有的设计已经无法满足功能安全要求,因此本文考虑采用双MCU协同控制的设计方案。双MCU的设计已广泛应用于整车控制器、防抱死系统等整车控制或者主动安全核心装置,其目的是增加故障冗余,在主MCU发生故障时由从MCU接管控制,实现部分核心功能可以继续工作从而避免车辆失控[2-5]。

本文采用了主从MCU的方法,对原有车身域控制器方案进行修改,并设计了一套主从MCU的通信协议,在协议内增加了诊断功能。2个MCU可以相互监控对方的工作状态,如果对方发生死机或工作异常,可以发起MCU复位,并记录故障信息,不仅满足了功能设计要求,还提高了功能安全等级。

1 车身域控制器设计需求

新能源商用车的车身域控制器(body domain controller,BDC)集成了车身控制模块(body control module,BCM)、空调控制器(air conditioner,AC)、副驾驶门控制模块(pilot door control module,PDCM)和中央网关控制器。其中车身控制模块负责危险报警灯、天窗、门控、阅读灯、睡眠灯、喇叭、安全指示灯、行车灯等多个功能[6];空调控制器负责驾驶室空调功能;副驾驶门控制模块负责车窗升降、后视镜调节灯功能;中央网关控制器作为不同网络间信息传递的枢纽,负责协调不同CAN总线网络与其他数据网络协议间的数据交换、协议转换以及故障诊断等任务。

为节省控制器数量和成本,减少整车线束,简化整车网络结构,本文设计了一种集成中央网关、空调控制器、车身控制器、副驾驶门窗控制器的车身域控制器,并基于功能安全进行优化。

2 ISO 26262功能安全要求

ISO 26262是针对汽车电子系统开发和生产制定的功能安全标准,适用于所有提供安全相关功能的电力、电子和软件元素组成的设备。

2.1 功能安全目标确认

ISO 26262要求通过危害分析和风险评估(hazard analysis and risk assessment,HARA)来识别产品功能故障引起的危害,对危害事件进行分类,然后定义与之对应的安全目标(safety goal,SG),以避免不可接受的风险[7]。每一安全目标得到相应的汽车安全完整性等级(automotive safety integrity level,ASIL)。ASIL从低到高分为A、B、C、D四个等级,等级越高,表示危害事件的风险越高。

通过整车危害分析与风险评估,得到车身域所有相关功能的安全目标。本文以表1中部分灯光及雨刮器控制功能为例进行说明。

2.2 元器件的安全机制与诊断覆盖率确认

ISO 26262标准中将诊断覆盖率分为低、中、高3种等级,各等级的覆盖率分别可达到60%、90%和99%[8]。

控制器MCU选用国产车规芯片AC78406,该芯片基于ARM CortexM4F内核,144引脚,包含1.128 MB的Flash和124 KB 的系统 SRAM,功能安全符合ASIL B。AC78406芯片具有内核自测、访问保护、安全管理单元、内部错误检查和纠正 (error checking and correction,ECC)及循环冗余校验 (cyclic redundancy check,CRC)、时钟和电源监控等机制,并具有数字回读功能来检查数据发送的正确性。

为防止板上5 V供电模块出现硬件随机故障,额外增加了一路跛行电源。当供电发生故障时,跛行电源启动,并由硬件机制直接打开报警灯及转向灯等,实现对驾驶员的提醒。

高边驱动选用德州仪器公司的TPS1H100,该驱动带有过载保护和短路保护功能,并具有自恢复功能的热关断/热调节失地保护和失电保护功能;除此之外带有一路诊断引脚,可以对开路、短路、过载和接地短路进行检测以及对电流限制进行诊断。

表2为元器件的安全机制和诊断覆盖率。

2.3 功能安全指标的硬件参数要求

硬件功能安全确认主要是通过硬件架构指标来衡量是否符合对应的ASIL要求,行业内一般对电路进行失效模式影响与诊断分析(failure mode effect and diagnostic analysis,FMEDA),根据电路图中各个元器件的失效和失效影响,编制硬件指标计算表格来计算3个参数:单点故障度量(single-point fault metric,SPFM)、潜在故障度量(latent fault metric,LFM)、随机硬件失效概率度量(probabilistic metric for random hardware failures,PMHF)[9-10]。具体计算公式如下:

式中:下标“SR,HW”表示安全相关的硬件元素;λ为安全相关失效率;MSPF为单点故障度量;MLF为潜在故障度量;MPMHF为随机硬件失效概率度量;λSPF为单点故障失效率;λRF为残余故障失效率;λMPF,Latent为潜在多点故障失效率;T为产品生命周期。

失效率的单位是FIT(failures in time),1 FIT表示器件每运行109 h失效1次。高的单点故障度量意味着相关硬件的单点故障和残余故障所占比例低,所以单点故障度量的值越高越好。

功能安全对硬件指标的要求如表3所示。

表3 硬件度量指标

3 单MCU方案硬件架构指标计算

3.1 单MCU方案硬件失效度量计算

下文以安全目标SG1(控制器正确响应转向灯)为例,结合系统的诊断措施进行硬件失效分析。转向灯控制电路如图1所示。

转向灯开关作为信号输入,经过上拉操作后接入MCU,MCU输出引脚驱动高边驱动。当MCU检测到开关为低电平时,设置控制输出引脚高电平,驱动高边驱动输出高电压给灯组。TPS1H100会有一路诊断引脚输出电流诊断信号,该引脚通过电阻接地。MCU根据该引脚的电压反馈来判断高边驱动的故障情况。由于域控制器主控MCU引脚不足,输入需要采用复选芯片。

当R6出现对地短路时,U1出现过流故障,故障反馈信号会拉高,并关断输出。而当U2发生故障时,由于缺少足够的诊断措施覆盖,所以该失效单点故障率较高。当MCU发生诸如ECC错误、外部时钟不稳定等失效时,使用安全机制SM1～4可以有效检测该类故障。

根据ISO 26262-5中列出的电子元器件的失效模式及其分布律和各失效模式下适用的安全机制及其诊断覆盖率,再参考GB/T 37963—2019[11]标准中对电子元器件失效率的标准规定,编制了表4所示的转向灯控制电路的硬件指标计算表格。

3.2 硬件随机失效分析结论

硬件指标计算结果如表5所示。单点故障度量为88.5%,潜在故障度量为41.1%,仅符合ASIL A的要求。

以上结果表明单MCU的设计方案无法满足ASIL B的目标。原因是缺少外部芯片监控主控MCU是否工作正常,导致缺少对多点故障失效的覆盖,影响潜在失效率;其次,由于车身域控制器集成了多个功能以后,单MCU由于引脚不足,必须要使用多路复选IC才能满足设计要求,造成单点失效率大幅增加,从而无法满足技术安全目标。

4 功能安全优化

4.1 功能安全优化电路

为了解决以上问题,可以采用更高规格的MCU作为主控芯片,比如英飞凌公司的TRAVEO T2G系列车身控制专用芯片和恩智浦公司的S32K344系列都符合设计要求,但是两者的价格都远超AC78406,成本过高。

本文提出了一种可以提高车身域控制器功能安全的有效方式。为了消除多路复选芯片的硬件随机失效率,同时增加对MCU失效的诊断覆盖,最终符合功能安全目标,选择额外增加一个相同的MCU作为从MCU,同时设计一套主从MCU的通信协议,在协议内增加诊断功能。2个MCU分别独立接入总线诊断网络,支持诊断读取和清除,与使用高规格进口芯片相比,使用2个国产MCU也更具有成本优势。

根据以上设计,该车身域控制器增加了SM7安全机制,即双MCU之间相互监控,诊断覆盖率定为90%。

新的转向灯控制电路如图2所示,2个MCU直接接入对方复位引脚,从MCU直接驱动读取外部IO信号。由于增加了SM7这种安全机制,2个MCU可以互相监控,所以当其中一个MCU发生共因失效时,另一个MCU可以及时发现,并复位系统进入安全状态,鲁棒性较高,同时避免了多路复选芯片失效造成的单点故障。

相较于图1,图2减少了元器件U2,同时增加了从MCU。根据新的控制原理图,结合新增加的诊断条件,重新计算转向灯控制电路硬件指标。由于增加了诊断机制SM7,主从MCU在发生单点失效和潜在多点失效时均可以被该机制覆盖。经过计算,改进后硬件指标结果如表6所示。

由表6可以看出,优化后转向灯控制系统硬件架构的单点故障度量为94.7%,潜在故障度量为78.8%,参照ISO 26262硬件架构指标要求,该指标符合ASIL B。

通过前文的分析,额外增加一个MCU的方式可以在仅增加少量成本下,提高单点故障度量和潜在故障度量,并降低随机硬件失效概率度量,由此将功能安全等级从ASIL A提高到ASIL B,从而提高车身域控制器的可靠性。

4.2 硬件设计验证

ISO 26262推荐了3种硬件集成测试方法,分别是功能测试、故障注入测试、电气测试。这里采用故障注入测试,在电路上增加测试点,手动模拟故障的发生,并使用示波器监视控制器输出信号,从而验证安全机制的完整性和正确性。以TPH1S100为例,正常工作时,诊断引脚会将输出以电流的形式反馈,当发生故障对地短路以后,诊断引脚反馈会超过正常范围,MCU可以通过该引脚判断驱动芯片的工作状态。当手动在R6位置触发短路故障时,诊断引脚电平如图3所示,符合设计要求。

5 主从MCU通信协议设计

5.1 通信流程

为保证主从MCU通信的准确性和实时性,基于串行外设接口(serial peripheral interface,SPI)通信设计了一种主从MCU间的通信协议,如图4所示。其中,主MCU为主机,从MCU为从机。由于SPI为全双工通信,主从MCU可同时相互进行数据交换,全部通信的最大超时时间为200 μs。

如图5～6所示,通信分为读、写2组数据包,2组数据包均为16字节,包含了序列号、数据帧和循环冗余校验。写数据包由主MCU发送给从MCU,用于从MCU数字输出以及脉冲宽度调制(pulse width modulation,PWM)占空比的控制;读数据包由从MCU回复给主MCU,用于返回从MCU数字输入的读取值和错误状态。

如图7所示,通过使用逻辑分析仪获取的波形可以清楚地看出,主从MCU的通信过程与所设计的通信协议一致。

5.2 通信故障诊断

本文制定的基于SPI的通信协议有2种故障:通信超时故障、校验错误故障。

通信超时故障:在主从MCU通信中,当主MCU连续2个周期没有收到从MCU回复的信息,则从MCU通信超时,主MCU将从MCU复位,错误计数器清零,并记录故障信息。

校验错误:校验错误分为序列号校验、数据帧校验和CRC校验。序列号校验是总线上传输的每个单独的安全相关帧中包含一个作为信息一部分的计数器,在生成每个连续帧时计数器值增加。接收方随后能通过验证计数器的值是否加1来探测任何的帧丢失或者帧未更新。数据帧每个字节的bit0为奇校验位。读写数据包的最后2个字节为CRC校验部分。通过以上校验方式可以确保主从通信过程的稳定性和安全性。

6 硬件在环仿真测试

6.1 硬件在环仿真系统

本文采用基于Vector设备的硬件在环 (hardware in loop,HIL)仿真测试系统对车身域控制器进行功能测试。硬件在环仿真是一种半实物的闭环仿真方式,通过将真实的控制器接入虚拟建模出来的环境中进行各项功能的测试和验证,从而提高开发质量,缩短研发周期[12]。测试机柜由电源管理模块、程控电源、调理电源、工控机以及一系列Vector功能板卡组成[13]。测试时控制器通过扩展架与HIL机柜相连,以总线仿真与测试工具CANoe为载体搭建测试工程,以此来实现控制器与HIL机柜之间的信号实时交互;根据测试工程面板创建的输入输出信号按键来控制HIL机柜模拟实车给控制器发送开关量信号,同时将控制器的输出响应信号通过机柜显示到上位机用于观察结果。LabCar台架作为一个接近实车尺寸大小的物理装置,其中各类器件均按照实车结构进行布局[14]。按照实车零部件、线束、蓄电池等电器部件位置在LabCar台架上进行实物搭建。将通过HIL机柜验证后的控制器安装到LabCar上进行测试,检查车灯、转向灯等零部件是否可以正常工作。

6.2 车身域控制器测试平台搭建

如图8所示,将一键启动控制器、主驾驶门控、胎压传感器、整车控制器等报文节点添加到模拟设置窗口中,它们之间通过总线板卡连接。测试系统根据整车通信规则,通过模拟节点发送总线报文并使用数字接口模拟整车信号,通过判断被测控制器的响应情况来检查控制器是否符合功能设计要求。

根据该车身域控制器的功能及具体的HIL测试条件搭建测试面板,它包含商用车的前大灯、转向灯、驾驶室内部照明灯、雨刮、天窗、空调等功能的控制。此外,将各个执行部件的控制信号也做在面板上,以便于及时观察控制器控制信号的响应情况。

6.3 车身域控制器功能测试

测试项目工程搭建完毕后,基于车身域控制器的功能规范编写测试用例,再通过上述测试平台所搭建的测试面板对车身域控制器的功能进行逐一验证。该过程既可以验证应用层的功能逻辑的正确性,又能验证控制器底层对于输入输出的数字信号、模拟信号、PWM调速信号以及CAN信号处理的实效性。表7罗列了域控制器的所有功能测试项,将测试项目按照用例编写成脚本进行自动化测试,仅最后对测试结果进行分析,可省去大量测试时间。CANoe测试脚本运行结果如图9所示。

经过测试,车身域控制器上述功能满足设计要求,车身域、门控及空调的应用层功能都可以被正确地执行。该种控制器对域控制器功能中所涉及的数字信号、模拟信号、PWM信号以及CAN信号的处理能力均达到设计要求,对应用层逻辑的处理符合预期目标。

7 结束语

本文根据企业实际需求,在兼顾成本和实用性的情况下,提出了一种双MCU架构的车身域控制器设计方法。通过使用注入测试和HIL功能测试,证明该控制器符合设计要求。该方案具有良好的可靠性和工程实用性,给未来车身域控制器设计提供了新的思路。