上个月帮朋友看一个车控模块的代码,他说评审方要 MISRA C 合规报告,团队三个人查了两个星期,查到眼睛都花了。我问了一句:你们没用工具?他愣了一下,说以为是买个工具就完事的事,没想到这么麻烦。
其实这事我想说很久了。MISRA C 这套规范,做汽车、医疗嵌入式的基本躲不开。C:2012 版本里光规则就有一百七十条多,再加上指令,接近两百条。每一条后面还有必选、推荐、强制这些分级。靠人去查?一条规则一行代码地比对,那不叫审查,那叫熬人。而且人查有个致命问题——今天状态好查得细,明天累了就漏。合规这个东西,漏一条就是隐患。
所以我的做法一直是:让工具扫,人来判。
具体到 Parasoft,主力是 C/C++test。它内置了 MISRA C:2004、C:2012,连比较新的 C:2023 都有对应的规则集,不用自己去网上扒规则文件再导入。装好之后,选规则集这一步要稍微动动脑子。我的建议是别一上来就全开,先把必选(Mandatory 和 Required)级别跑起来,推荐(Advisory)的后面再说。为什么?全开的话,第一个月的报警量会把团队心态搞崩,工具还没立起来,人就先不用了。
跑完第一轮扫描,才是真正的工作开始。
你会看到一堆 violation,别慌,这里面有水分。有些是真问题,数组越界、隐式转换这种,该改就改。但还有一些,属于业务上合理、规范上不允许的情况。比如某些底层寄存器操作,就是得用强制转换,MISRA 偏偏不让。这类就轮到 deviation(偏差)出场了。Parasoft 里可以对单条违规做抑制,关键是抑制不能瞎做——每条偏差都要写清楚理由、范围、责任人,评审的时候拿得出来。这一步工具帮不了你,得靠团队的纪律。
我见过最可惜的项目,就是偏差管理形同虚设,suppress 注释满天飞,最后报告倒是绿的,一问为什么抑制,没人说得上来。这种合规,糊弄得了内部,糊弄不了认证方。
再往上一层,如果团队规模大、项目多,建议把 C/C++test 和 DTP(开发测试平台)连起来。单机扫完出的是一份份孤立的报告,DTP 能把所有项目的合规状态聚到一块,哪个模块违规数在涨、哪类规则反复出问题,一张报表看清。给管理层汇报的时候,你也不用再截图拼文档,合规率多少、趋势怎么样,直接看板。评审方来问,导出合规报告就行,格式他们也认。
还有个容易忽略的点:合规不是一次性的事。代码天天在改,今天合规不代表下周合规。所以扫描要进 CI,每次提交增量跑一遍,新增违规当场拦住。等攒了三个月再回头清,那就不是清违规了,是清债务。
回头看朋友那个项目,我给他排了个路子:第一周装 C/C++test、跑通必选规则;第二周集中处理存量违规和偏差文档;第三周接进流水线。三个人两个星期的活,压缩下来其实没那么吓人。
工具不便宜,但人更贵。这笔账,做过一次 MISRA 合规的人都算得明白。