细说车灯功能安全
引言
细说车灯功能安全
前后经手过数十个广义上涉及车灯功能安全的项目(包括车灯/车灯+ECU/车灯ECU平台/BCM等等),虽然现已离开这条赛道,能对自己感兴趣的一些话题加以总结,也算是对此前工作经历的回顾;正好也借此机会抛砖引玉,有请业内方家的提点与斧正。
附赠自动驾驶最全的学习资料和量产经验:链接
广义上来说,在Tier1向OEM提供具备车灯功能的产品时,提供的可以是车灯造型件,外加直接提供点亮功能的电子和光学部分(传统意义上的“灯泡”);也可以是上述部分外加用于驱动的boost-buck电路,以及集成了符合法规灯控逻辑的车灯ECU;除此之外,甚至还可以再提供一个BCM,并在其中打包提供一些车灯以外的车身电子功能。
而作为一个功能安全相关的产品,车灯颇有一些特殊的地方:一方面,车灯的ASIL level往往并不高;按功能划分通常是ASIL A或者ASIL B,只有在很少见的情况下会达到ASIL C;另一方面,车灯可以说是少数迭代频率甚至高于整车的“门面产品”(不论是新车还是中期改款,车灯都是卖点的重要组成部分,在竞争激烈的国内市场尤其如此),可识别性强,技术更迭也非常迅速。不论是BMW的天使眼,还是Volvo的雷神之锤,都具备一种特有的魅力;而国内的各大造车势力中,近年来也有一些品牌逐渐将特定风格的车灯打造成了自己的车型/车系名片。
“天使眼”
和
“雷神之锤”
车灯的功能安全要求曾经非常地“固化”:对于各个安全相关的车灯功能而言,其对应的安全目标、ASIL等级乃至实现方式都较为固定。然而,随着新能源车和造车新势力的兴起,以及电气架构的更新,传统车灯原有的布局、功能划分正逐渐打破陈规:各个功能之间复用的情况越来越频繁_(如Stop/Pos之间的复用),而单一功能又往往由多个模块合成(如Low Beam可以由多个组件的组合,实现基本功能/拓展功能,抑或是DRL/Pos在造型方面的复杂光学件组合,贯穿式Pos灯组、矩阵式High Beam灯组的应用,以及引入灯语交互功能的点阵Pos灯组等等)_,一切都在为这个领域带来新的挑战和机遇。
—— 一些特点、趋势和思考傅翀
➡本文主要内容分为6个部分(约3400字,15分钟阅读)
目录
1
ASIL分解
对于车灯功能相关的安全目标而言,如前所述,其安全目标_(SG)_的ASIL等级通常不高,而对于这些SG分解往往并不容易,也不太推荐。
对于近光_(Low Beam,LB)功能,较常见的SG是Avoid unintended low bean loss when needed(或者更通行地表述为:Avoid sudden loss of forward illumination of the road during night drive)_;早年部分车厂使用过一个现在看来不太合适的分解方式,即对左右近光灯做分解,如下图所示:
但事实上,这种分解方式的合理性值得商榷。通常来说,提供近光功能的左右灯需要分别独立满足法规,并各自符合“左低右高”的光型及法规所要求的明暗截止线。在上述条件下,左右近光灯通常也会使用相同的驱动电路设计、使用同型号的ECU_(尽管在安装时仍然需要对左右侧进行识别)_,这意味着相关失效的影响是不可忽略的。
在进行相关失效分析_(DFA)的前提下,传统车灯功能中,能够进行ASIL分解的,恐怕也只有刹车灯(Stop)较为合适:在左右刹车灯和高位刹车灯(CHMSL)之间能够充分保证独立性的前提下(具备独立供电、电路设计异构),对刹车灯的安全目标,如:Avoid no actuation of Stop lights when needed(ASIL B)_,在左右刹车灯和高位刹车灯之间进行分解。
以上的讨论较为浅显,但讨论并不是到此结束,而是刚刚开了个头——随着车灯设计思路的不断丰富,ASIL分解的思路也就随之拓宽了,例如:
如果由2组(或更多)LED String实现左/右刹车灯功能,是否可以在设计中考虑,让每一组区域分别通过灯光法规的要求,并尽可能保留异构特性,由此进行分解?
在某些大型SUV车型上,整片式可掀起的尾箱盖和车身部分分别安装了所有的主要功能灯,这种冗余设计是否支持在一定程度上的分解,还是只能由车身部分作为常设灯组?
安全而有效的ASIL分解,需要主机厂和Tier1紧密而长期的合作,对需求端的know-how也提出了更高的要求,简单的功能描述往往不足以敲定整个设计,研发期间的反复同步才能提炼出最优的方案。
2
安全状态
传统的安全状态无非亮灯或灭灯,这一部分的新挑战主要来自三类情况,即功能的组合实现/复用/冗余灯的使用。
“抽象派画风”下的车灯功能分布,实际项目中也存在比下图更复杂的情况
单一功能由多个区块实现,需要和光学/法规团队的深度合作,以及经过多次仿真才能确认各个组合下何种情况可以达到安全状态;
而如果同一区块复用为多个功能,则要确认是否能够同时满足多个功能的安全状态_(Pos/Stop复用较为常见,但不同功能所对应的亮度未必一致)_;进一步说,各个区块的优先级孰先孰后,以及对应不同SG的不同FHTI如何取舍,都是需要考虑的。
LED点阵的引入,提供了冗余功能的可能性,也为安全状态提供了额外的思路:假如某个功能灯损坏了,是否可以利用点阵进行降级“补位”,也是一个很有意思的话题。
3
安全架构
整个车灯功能的控制链路并不短,举例而言,可以是由灯光开关/踏板/仪表盘/中控->BCM->车灯ECU->车灯(或LED灯板);符合功能安全的良好设计,需要考虑每个环节的实现,并合理地allocate对应的SG。
对于刹车灯,双侧功能均异常的SG:Avoid wrong-side activation of Turn Indicator_(ASIL B)_会allocate到BCM及更“上游”的组件;相比之下,其他针对单侧功能失效的SG则需要整个控制链路共同承担。
传统仪表盘上的报警灯_(tell-tale)仅局限于少数功能,因此Tier1有义务和OEM确认具体哪些故障可以得到显示(不论是报警灯还是中控,或者是故障码)_,由此才能保证计算FMEDA时对于诊断和诊断覆盖率的立论有理有据。
对于BCM,如果在架构方面的储备足够充分,甚至可以对于前灯-后灯功能交叉配置不同的型号的driver,避免因为相关失效导致同类型的driver,从而更好地保障一部分双侧车灯功能(LB/Stop/Pos)的可靠性。
4
强制力与优先级
到了2022年,功能安全虽然“名义上”依然是自愿标准,但作为零部件Tier1,一旦客户RFQ中包含了对于ISO 26262的合规,在事实上一旦项目定点,对应的内容就已经转化为了强制要求;在这种情况下,并不需要讨论“是否做”,而只需要考虑“如何做”。
但与此同时,车灯标准本身_(无论是ECE还是SAE)同样具备非常高的强制力;所以实际工作中所遇到的问题,往往是调和两者(以及各自衍生出的理解和BP)_之间的差异。
在较早的车灯驱动架构中,车灯ECU往往无法对每颗LED上的每个失效模式进行诊断上报;为了防止部分LED/LED string在受损后无法上报,从而使得车灯亮度在下一个维保周期内始终低于法规的要求,有一种倾向于车灯法规的策略是采用“一灭全灭”的逻辑,通过灭灯的方式让使用者发现故障_(虽然笔者认为这个思路并不靠谱)。_
这在某种程度上和功能安全的思路是相悖的_(一个功能,在很多场合下哪怕降级也比完全丧失要强);最终在实现层面,需要考虑光学法规和功能安全两方面的诉求,以及光学仿真的情况(具体损失哪几颗LED构成法规的违背)_,在不同的车灯功能上进行取舍。
另一个例子则是转向灯:对于转向灯而言,FHTI并不是越短越好–转向灯的点亮周期本身已经在法规中进行了定义,无论诊断和动作有多快,只要在下一个亮灯周期前完成即可,较短的FHTI既无必要也会挤占资源。
5
行业趋势
从整车电子架构来看,集成程度在逐渐提高,这也意味着,随着domain / zonal架构的普及,独立车灯ECU的订单会逐渐减少,而与车灯逻辑相关联的部分也就随之并入了_(更多由OEM侧主导的)_domain controller或zonal gateway;由此,OEM对于车灯的掌控能力有所提升,但也因此承接了灯控逻辑、法规和功能安全所带来的挑战。
与此同时,在IC层面/板级方案上的集成度也在不断提升。对于专用LED driver而言,不论是诊断还是驱动,功能都愈发齐全;而在某些产品_(如三星的PixCell LED)_上,甚至直接对于适用于Low Beam/High Beam/ADB功能的LED阵列进行了集成。专用芯片/方案意味着功能更紧凑、理论失效率相较之于通用方案更低,但买家也要基于专用芯片/方案,对车灯这样的“个性化”产品进行定制,并保证功能安全符合性的适配。考虑到目前官方并未宣称PixCell LED的功能安全等级,对于这类混合了电子和光学要求的产品,如何在集成过程中完成Component Evaluation也是需要好好考虑的。
三星的PixCell LED_(右)_
相比传统的板级解决方案_(左)_紧凑得多
6
结语
以上种种所述,大体上是基于传统Tier1视角的一些现状总结和思考。
在Tier1利润空间不断被压缩、OEM亲自下场、IC产品也越来越靠近终端的这个“乱战”时代,新生事物层出不穷,用“忙碌而充实”来形容车灯功能安全负责人的工作应当是恰如其分的。
附:常见的车灯功能安全目标(仅供参考):