一、从一次诡异的ECU复位说起
上周在联调阶段,某个控制器在连续运行48小时后突然复位。抓到的错误日志里只有一句含糊的“EcuM_Shutdown”。硬件同事查了电源纹波,软件同事翻了任务栈溢出,都没定位到根因。最后在MemIf模块里发现端倪:某个非安全相关的任务写穿了安全内存分区,把安全相关的变量给污染了。
问题来了:为什么MemIf没能拦住这次非法访问?因为配置里把安全分区和非安全分区的地址范围设重叠了——人肉手写地址映射表时漏看了一行。这种问题在功能安全审核时很难一眼发现,但运行时就是颗定时炸弹。
二、AutoSAR CP的安全机制不是“配了就完事”
很多人以为AutoSAR CP的功能安全就是勾选几个Safety Mechanism(比如E2E保护、内存保护、程序流监控),再在Davinci里点几下生成代码就高枕无忧了。实际上,安全机制本身也需要被验证,而且验证的覆盖度直接决定ASIL等级能否达标。
举个例子:你启用了E2E保护,但E2E Profile选错了。本来该用CRC8+Counter的Profile 1,结果手滑选了Profile 5(适用于大型数据包),实际运行时CRC校验永远通过——因为算法根本不对。这种错误在静态测试里很难暴露,只能靠背靠背测试或故障注入抓出来。
/* 错误示例:这里踩过坑 */E2E_P01ConfigType config