SASETalk | 走出文档，扎根代码：探寻汽车功能安全演进与线控跃迁
“SASETalk”是磐时打造的深度访谈栏目，通过与企业内资深技术专家对话，记录他们亲历的技术历程与行业观察，从个人视角解读行业发展变迁，共同探讨未来技术趋势与工程师成长路径。
本期嘉宾PROFILE
石磊
资深功能安全工程师
10年汽车功能安全ISO26262、ASPICE方向经验
擅长 ISO 26262 系统/硬件/软件/流程全栈开发与 ASPICE 软件流程规范，熟练运用 HARA 分析、IQ-RM/FMEA 安全分析方法进行安全机制设计；熟知第三方安全组件（如vector SIP包、英飞凌 硬件驱动组件），曾主导多家主机厂 ASILD 级功能安全流程体系建设项目。
01
跨域深耕全栈破局
您先后参与过动力系统与底盘转向等核心高安全领域的开发，这种跨领域与不同层级的转变，带给您怎样不同的安全工程视角？
动力和底盘在整车里是耦合的。比如转向系统的安全策略要考虑动力系统的状态，反过来亦然。这种跨领域让我学会从"子系统安全"上升到"系统级安全"，考虑交互失效模式。
另外，安全验证方法的不同。动力系统可以靠台架、仿真做大量验证，但底盘转向的某些场景（比如极端工况下的转向特性）很难完全仿真，需要更多的实车验证和场景覆盖。这让你更重视"未知"的风险。
您从前期的标准理论沉淀起步，再到贯通量产交付与底层研发，是什么促使您不断突破边界，去完成这样一套跨维度的技术积累？
最开始学标准、啃理论，是搭一套体系化的安全思维；但越往下做越发现，安全不是纸上谈兵。很多失效场景、工程约束，只有扎进量产交付和底层研发才能看见。
理论告诉你该做什么，量产告诉你现实里哪些做不到、怎么取舍，底层研发又帮你理解失效的根因。动力、底盘、智驾互相耦合，单一维度根本看不全系统级风险。
所以不断跨维度突破，并不是我主动想当“全能选手”，而是高安全工程本身的要求：要守住安全底线，认知就不能只停留在文档或代码某一层。外部技术迭代只是推着你往前走，核心驱动力，还是希望设计的功能在真实世界里足够可靠。
02
底盘攻坚体系赋能
底盘转向系统属于严苛的ASIL D等级。在将前期的系统安全分析，真正转化为底层软件安全机制与代码落地时，工程团队通常面临哪些实际挑战？
底盘转向是ASIL D，安全分析做到位只是第一步，真正落地到底层代码，挑战不小。
第一个是实时性与资源的矛盾。ASIL D要求大量安全机制，比如冗余校验、周期监控、故障诊断，但这些机制本身要算时间、占内存。转向系统毫秒级响应，安全机制不能拖后腿，怎么在有限算力下做平衡，是很大难题。
第二个是从安全目标到可执行机制的断层。HAZOP、FTA告诉我们“失效了该进安全状态”，但代码要定义清楚：什么叫失效、多久检测一次、检测到后是降级还是切断、冗余切换会不会产生力矩抖动。分析输出的是目标，工程要输出的是可集成、可测试、可量产的机制。
第三个是安全机制的验证。写了一段校验逻辑，怎么证明它不漏检故障？需要大量故障注入、HIL测试。但底盘转向的很多极端工况，台架很难完全复现，验证周期长，误报和漏报还要反复权衡。
简单说，ASIL D最大的难点不是写代码，而是把上游的安全分析，变成在真实硬件上稳定可靠、可验证、可量产的底层安全机制。
您曾为多家供应链企业提供 ASIL D 体系辅导，从整车到上游软硬件供应商，不同环节在推进功能安全落地时，最常见的痛点或断层是什么？
从整车到芯片、软件、硬件供应商，最常见的痛点不是“不会做安全机制”，而是安全要求传着传着就变了形。
整车厂说“转向不能非预期”，到 Tier 1 变成技术需求，再拆到软硬件，接口、响应时间、诊断覆盖率这些信息容易丢。很多项目 DIA 只当合同附件，没写清谁分析、谁验证、变更谁批，出事就互相推。
更常见的是“文档工程”——开发是一套，安全文档是另一套，HAZOP、FMEA、Safety Case 看着齐全，但安全目标到代码、测试对不上，量产时一集成就暴露。
还有底层供应商能力跟不上，能给 datasheet，给不出 FIT、FMEDA、故障注入证据。变更管理也容易崩，改一个信号，HARA、安全机制、测试全要重评，越往后整改越贵。
总结一句话：整车厂谈目标，Tier 1 谈方案，下游谈零件——三方没在同一套安全逻辑里说话，这是供应链最大的断层。
03
动底融合线控跃迁
现在很多车企都在推进中央计算平台与区域控制架构，甚至探索“动底融合”。在多核异构芯片上做高安全任务的隔离与免干扰，通常会遇到哪些新挑战？
以前汽车里每个系统各管各的，仪表就仪表，底盘就底盘，互不干扰。现在要把这些都塞进同一颗芯片里，麻烦就来了。
最大的麻烦是：大家共用同一个"地基"，但有的活儿要绝对靠谱，有的活儿可以随便。
比如仪表盘显示车速，这要是错了，车可能超速；但中控屏卡了一下，顶多听个歌不爽。现在这两件事跑在同一颗芯片上，怎么保证中控屏卡的时候，仪表盘照样准？
技术上，芯片得画好几道"墙"——内存要隔开，外设要隔开，连缓存、总线这些共用资源也得管住。但墙好画，时间不好管。低安全任务突然猛刷内存，高安全任务就可能被拖慢，这在功能安全里叫"干扰"。
而且认证也头疼。底盘系统是ASIL-D级别，座舱是QM级别，原来各过各的。现在塞一块儿，如果证明不了它们真隔离，整个平台可能得按最严的ASIL-D来开发，成本就上去了。
所以现在车企的方案，基本是"硬件分区+裸机虚拟化+安全岛兜底"这套组合拳。但最难的不是技术，是流程——原来底盘团队和座舱团队各干各的，现在要坐一张桌子上定义接口、商量OTA谁负责、死机了谁来背锅。这才是中央计算真正要跨的坎。
近年来线控转向逐渐走向实车量产，在取消了传统机械转向柱的物理兜底后，系统必须做到 Fail-Operational（故障运行）。这种从“故障后安全停机”到“故障后带伤运行”的转变，带来了怎样的架构考验？
以前转向系统是有机械转向柱兜底的。哪怕电子系统全挂，你打方向盘，车轮还能跟着转，顶多手感重一点，但不会彻底失控。
现在线控转向把这根机械柱拿掉了，方向盘和车轮之间只剩电线。一旦电子系统坏了，转向就直接没了。所以不能再像以前那样，出故障就停车，而是必须做到故障了还能继续转向，也就是Fail-Operational。这个转变带来三个很实在的架构难题。
第一，单点故障不再是能停下来，而是直接丧失转向。以前出故障，可以安全停车，慢慢减速就好。现在一出故障，转向就没了，这是单点失效，所以必须做冗余。双核锁步、双路供电、双路通信、双路电机，任何单一故障都不能让转向失效。但冗余不是简单堆硬件，最怕共因失效。比如同一路电源浪涌、同一条线束磨损、同一款芯片的设计缺陷，冗余也扛不住。所以冗余通道之间要做物理隔离，甚至用多样性设计，从根源上避免共因失效。
第二，故障探测和切换必须快到驾驶员无感。转向是毫秒级的实时系统，从发现故障、隔离故障，到备份通道接管，整个过程必须在几十毫秒内完成，驾驶员根本感受不到。这就要求故障诊断要嵌入每一个节点，备份通道必须热待机随时能接管，切换逻辑最好硬件化，不能靠软件层层判断。一旦切换慢了，高速行驶时方向盘突然变重或者卡顿，很容易出事故。
第三，功能安全的思路变了。以前功能安全主要是预防故障，故障了就安全停车。现在Fail-Operational要求系统带着已知故障继续工作。这就必须设计降级运行模式。比如主电机坏了，备份电机以降额状态继续提供基本转向能力，同时报警提示驾驶员尽快维修。但这个降级模式本身也需要论证：降额后的转向性能是否仍然安全？降级过程中会不会产生新的风险？这也需要在架构设计之初就考虑清楚。
简单总结一下。去掉机械转向柱之后，安全兜底从原来的机械结构搬到了电子电气架构里。Fail-Operational不是多装几个冗余零件就万事大吉，而是从故障探测、隔离、切换到降级运行，全链路都要无缝衔接，整个设计要有完整的证据链。这就是线控转向在功能安全方面最大的架构挑战。
04
量产世界的安全底色
大家常把功能安全工程师调侃成项目里的“刹车片”。在您眼里，这个岗位对量产车的价值是什么？
大家叫我们刹车片，听着像只会踩刹车、拖慢项目。但我觉得，功能安全工程师更像汽车电子系统的安全设计师。
以前车里很多是机械部件，坏了容易发现，责任也清楚。现在汽车电子越来越复杂，芯片、软件、总线一大堆。很多危险不是零件突然断掉，而是设计时埋下的隐患，比如某条电源线、某个软件逻辑没考虑周全。这种问题往往等车已经量产了才暴露，轻则大规模召回，重则危及生命。
我们的工作不是等项目快结束才去检查，而是从方案设计第一天就提前找隐患。比如做线控转向，我们会思考：这个芯片失效会怎样？电源断了会怎样？通信卡住会怎样？然后推动团队提前做备份、做实时检测、做故障切换。
我们也不是只提要求，还要确认这些方案真的落地、能实测、有完整记录。
当然，我们也不是硬踩刹车。安全要求太严、不考虑成本和进度，项目也推不动。好的功能安全工程师是帮团队划出安全边界：哪些地方风险可控，可以大胆创新；哪些是红线，绝对不能碰。
简单说，这个岗位不是拖慢项目，而是帮团队一边创新，一边守住安全的底线，保护每一位开车、坐车的人。
