引言 细说车灯功能安全
前后经手过数十个广义上涉及车灯功能安全的项目（包括车灯/车灯+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也是需要好好考虑的。
6 结语
以上种种所述，大体上是基于传统Tier1视角的一些现状总结和思考。
在Tier1利润空间不断被压缩、OEM亲自下场、IC产品也越来越靠近终端的这个“乱战”时代，新生事物层出不穷，用“忙碌而充实”来形容车灯功能安全负责人的工作应当是恰如其分的。
附：常见的车灯功能安全目标（仅供参考）：
END
作者：傅翀
文章来源：sasetech
推荐阅读
更多物联网安全，PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA技术交流群，请备注研究方向。
