智驾功能安全量产落地随笔

lichengwan

智驾功能安全量产落地二三事

不知不觉转到智驾功能安全领域已近3年，笔者也一直在坚持着践行功能安全的量产落地。在最近的项目中，除了定义分配需求、参与设计架构之外，笔者还做了一部分软件开发、单元测试和台架测试的工作，也因此对于功能安全的量产落地有了更深的认识。回望来时的路，既有成功的经验，也有失败的教训。在这里笔者略做整理，算是给业内同行一些参考吧。

➡本文主要内容（约2800字，13分钟阅读）

01

需求冲突务必重视

对于安全需求和非安全需求融合的重要性，笔者早有认识。所以在项目实施的过程中，笔者先后在不同阶段至少核对了五六次，去检查二者之间有没有冲突。实话实说在项目早期就发现了一些有冲突的问题点，也和客户达成了一致意见。本以为这样就万无一失，没想到在项目过程中还是出现了一个需求冲突的问题，好在及时发现，然后赶紧修正。

现在回想起来，根本原因还是在于功能安全需求是从功能需求衍生而来的，先有功能后有功能安全。当功能需求发生变更的时候，功能安全需求必须经过重新评估（要不要变更取决于重新评估的结果）。可问题在于，功能需求的变更太频繁，造成功能安全需求和功能需求产生冲突。



看到这里你也许会说，到了项目的某个阶段就把需求冻结，不允许客户再随意变更，这不就完了吗？笔者只能说理想很丰满，现实很骨感，这一点只要在汽车行业做过量产项目的人应该都有体会。而且有的时候，其实客户也不想改需求，但是不改不行。因为他们最早输出的需求是平台化的，应用到某个具体项目的时候，必然要做一些适配修改。如果这个车型是全新开发，或者某些关联件是全新定点的话，平台化的需求就会有不少需要修改的地方，而某些细节问题只有到了测试验证阶段才会暴露出来，想在前期就全部考虑周全几乎是不可能的。然后为了解决这些bug，不得不回过头来修改需求。看到这里你也许又会说，这是需求开发做的不充分，没有达到相应的成熟度。对，确实是。只不过按照现在汽车行业的项目节奏，如果真的100%完全按照循序渐进、按部就班的方式来做的话，恐怕做出来的产品一上市就要面临因为过气而无人问津的尴尬局面了。

所以，比较现实的解决方案还是想办法让功能安全需求“跟紧”功能需求，让二者保持一致，笔者在项目中反复核对也是出于这个目的。那为什么还是有“跟丢”的情况呢？因为功能需求的条目数量远远大于功能安全需求的条目数量（仅针对辅助驾驶产品而言）。为了对接、维护这些功能需求，不管是OEM还是Tier1都派出了一个系统工程师小组。反观功能安全这边，在绝大多数公司里面，人力资源都是远远少于系统工程师的。当然在项目组眼里，功能安全需求的内容（数量）只有这么多。对，确实是。但是为了维护好“这么多”的功能安全需求，必须和“那么多”的功能需求对齐，这个过程是节省不了的。另一方面，系统工程师通常也并不知道功能需求在这样或那样的变更之后，对功能安全有没有影响。所以，大多数情况下只能靠功能安全工程师自己了。

02

安全机制必不可少

笔者早年在从事新能源动力域功能安全工作的时候，曾经面对过项目组的灵魂拷问：这么多安全机制，都是有必要的吗？以前的项目没有这么多诊断，也没出啥大问题。而当笔者转到智驾域之后，却发现情况很不一样。有些笔者曾经认为很难出现的故障，在项目后期大规模路测阶段真的就出现了，还好有故障信息，所以比较容易去追根溯源、解决问题。如果没有这些安全机制，很多问题光从算法性能角度去分析的话很难调查，效率很低。以至于有的时候开发工程师会主动提出要把QM的部分也参考功能安全的思路来设计，增加一些安全机制。

之所以差异如此巨大，笔者认为有以下两个重要原因：

1. 复杂度：相对于智驾域产品而言，新能源动力域的ECU是比较简单的。从使用场景、系统架构到芯片算力、软件规模，都完全不是一个层面。简单就意味着稳定可靠，因此“以前的项目没有这么多诊断，也没出啥大问题。”

2. 成熟度：从多传感器融合到纯视觉，从rule-based到AI-based，智驾产品的技术路线其实还在迭代升级过程中，而且常常是“颠覆性”的转变。新的技术从原型到量产，必然要经历磨合的阵痛，因此也就容易出故障。

所以至少对于现阶段的智驾产品而言，安全机制是必不可少的。在这里有必要再强调一下架构设计的重要性，尤其是软件架构，因为绝大部分的安全机制都是通过软件来实现的。要想把安全机制顺利落地，软件架构设计是重中之重。笔者认为以下几个问题一定要提前考虑清楚：

▶ 安全需求如何承接？对于某个具体的软件模块而言，是拆分、升级（从QM升级到ASIL）还是旁路（另外设置独立的安全机制模块，其实就是ASIL分解）？这里需要重点考虑的是如何使得后续开发及测试的工作量降到最低。

▶ 安全链路如何分工？谁做Detection，谁做Action？中间模块是透传还是整合？这些问题的答案对于不同的安全目标而言有可能是不同的，需要整体考虑。

▶ 安全接口如何定义？原始数据（raw data）和附加信息（status，timestamp，etc）以什么形式在软件模块之间传输？拆分和合并各有利弊，可能没有完美的解决方案。



这些事情要想做好，其实工作量是非常大的，需要考虑很多的细节。当然了，从功能安全的角度无法独立完成架构设计，需要和研发部门紧密合作，因为软件架构需要同时满足安全需求和非安全需求，只考虑功能安全是不够的。笔者一直认为ISO26262标准里有个词——“refine”，非常贴切的描述了功能安全开发在项目中的实施方式。

03

不能只做标准里规定的功能安全

什么是标准里规定的功能安全？笔者认为概括来说就是当出现违背安全目标的软硬件故障时，要保证系统能在FTTI时间内进入安全状态。由此展开的一系列活动，从需求分析、设计实现到测试验证，都是围绕这个出发点进行的。实事求是的说，能把这些事情做好、做实已经很不容易了。然而，做到这些就够了吗？



看到这里你也许会说，标准里规定的内容都已经做了，为什么还不够？那笔者就说几个在项目中实际会遇到的问题：

▶ 功能安全的状态机和功能的状态机如何对应？

▶ 进安全状态时的人机交互是什么样的？（有的项目会把人机交互的内容定义为安全状态的一部分，但不全都是这样）

▶ 进安全状态时应该记录什么日志？

▶ 如何从安全状态中退出？

▶ ……

这些问题在ISO26262标准里都没有相关的要求，但是当你在产品开发中落地功能安全的时候，它们就会浮出水面。你也许会说：这些不属于功能安全的范畴，应该由系统工程师和开发工程师自己去考虑。但别人也完全可以回怼你：这些问题就是由于做功能安全才引发的，你不管谁管？

究其原因，还是在于功能安全并不是孤立的，它是产品的一部分。因此，如果是朝着量产落地的目标，你不能只管自己那“一亩三分地”。

毫不讳言的说，在当前的汽车行业做量产项目是一件非常艰难的事情，周期紧、任务重、客户要求还高。考虑到智驾产品的复杂性，能够按期完成功能和性能的交付就已经非常不容易了，再叠加功能安全的话实在是难上加难，一点也不夸张。有感于此，笔者写了这篇文章，希望业内同行在做项目的时候能够少踩一些坑，提前做一些计划和安排。若能如此，也算是一件幸事。

04

静态分析，还有很多可挖掘

笔者这里说的静态分析是指编码规范检查、指标度量（如圈复杂度）等需要借助专业工具实施的验证。实事求是的说，汽车行业的安全编码规范是比较死板的，有些条款似乎过于机械，当然这也有可能是编码规范太久没有更新的缘故。这一点在笔者按照编码规范检查工具生成的issue list去整改代码的时候，有特别切身的感触。所以，笔者曾经也一度怀疑编码规范的价值到底体现在哪里？不按编码规范来就一定不安全吗？直到在项目里见到了一个由于浮点数赋值表达式写错引起的bug，笔者才认识到，编码规范确实能预防一些潜在的风险（尤其是低级错误），从安全的角度来看是有必要的。

另外，笔者还想说一下控制流分析和数据流分析。虽然辅助驾驶软件通常不要求（根据ASIL等级），但笔者认为这些方法/工具如果用好了应该能发现一些比较深层次的bug，比如代码实现和设计流程图不一致的问题。尤其是在软件比较复杂的情况下，靠code review去检查逻辑错误会变得越来越吃力，因此工具的重要性也会越来越突出。



05

单元测试，想说爱你不容易

要说单元测试的必要性，可以找出很多论据，经典的包括：

▶ 流程要求（V模型）

▶ 修复成本（越到项目后期修复bug成本越高）

▶ 容易实施（通常不需要软件集成，也不需要系统集成）

▶ 测试充分（黑盒测试对关键路径的覆盖不够）

▶ ……

那么问题来了，如此有必要的单元测试，在业内落实的情况如何？可能在很多企业里都是不如台架测试、实车测试等黑盒测试的。原因当然也有很多，但大家可能很少考虑国内OEM是基于黑盒测试来验收这一点。对于智驾产品而言，OEM一般都有专门的实车测试验收团队，等项目到了验收阶段就会亲自下场路测。至于台架测试，OEM即使没有亲自搭台架来测，一般也会要求Tier1提供测试报告作为“呈堂证供”。在这样的约束条件下，Tier1必然要在OEM验收之前先完成自测，然后才能“送审”，所以黑盒测试资源在大多数企业里通常都是具备的。那单元测试呢？不同的OEM有不同的要求，很多时候都是低于黑盒测试，要求没那么严格。



这样的一个现实情况给功能安全的量产落地带来了非常大的挑战，项目组有可能会认为做单元测试就是功能安全的特殊要求，如果没有功能安全的要求就不用做单元测试。另一方面，对于功能安全而言，不管是从流程上考虑还是从技术上考虑，单元测试都是必须要做的一项工作，是不可能省略的。怎么办？下面笔者说几点个人看法：

1. 单元测试真的有用

实事求是的说，单元测试确实能在相对早期发现软件问题，节省修复成本。笔者自己就在单元测试阶段测出过软件bug，当然那个问题等到系统测试阶段也能发现，但是就需要使用CAN OE来模拟总线信号作为测试激励输入，测试成本更高。而且笔者还曾经在写单元测试用例的时候，发现了需求的一个缺失点。就是在输入信号取某种具体的值的时候，不知道预期输出是什么，再一查原来是需求里没有定义。所以业内同行可以搜集一些单元测试效用的实际案例，应该也比较容易能搜集到。

2. 单元测试工作量真的很大

这一点笔者是在亲自做过一部分单元测试工作之后才深有体会的，正所谓“未经他人苦，莫劝他人善”，是这个道理。由于单元测试用例和代码实现是强相关的，如果需求变更导致代码修改，那之前编写的测试代码多半也要修改，所以需求变更要尽量的去管控好才行。另外就是在软件架构设计阶段就要考虑开发和测试的工作量，这个问题笔者在上一篇文章中也有提及。最后说一下单元测试覆盖率的问题，一般来说覆盖率不达标意味着现有的单元测试用例测试的不够充分，需要继续补充用例。但也可能存在其它原因，比如说由于代码结构问题，某些部分无法注入测试激励。所以并不能一味的去“撸起袖子加油测”，必要时得结合代码分析。如何在满足ISO26262标准要求的前提下，用尽可能少的测试用例获得尽可能多的测试效果，这是一个非常有挑战的技术课题，需要持续探索。

3. 单元测试最好先在特定项目里推行

这里说的特定项目就是没有历史包袱的项目，或者说就是从“0”到“1”的项目。因为功能安全规定的单元测试，对过程和结果都是有要求的，不是随便做一做就万事大吉。为了达到这样的效果，其实反过来对软件设计水平也是有要求的，换句话说就是写的差的代码无法通过功能安全要求的单元测试，除非代码重构。明白了这一点，什么样的项目容易推行单元测试其实也就不说自明了。



最后补充的一点就是笔者目前所在的公司是由开发人员自己完成单元测试，而笔者以前待过的公司有专门的测试工程师来做单元测试。这两种模式各有优劣，并不影响单元测试本身的意义和价值。

06

台架测试，可以做的更整体

台架测试在各个企业里普及程度比较高，测试方法、测试设备、测试人员都比较专业，测试效果也是比较明显的。在这里笔者只说一点：可以将ISO26262标准Part6里要求的“Testing of the embedded software”和Part4里要求的“System and item integration and testing”更加整体的来看待，包括用例设计和测试执行。当然了，这需要对SSR、TSR和FSR的内容有比较深入的理解，才能做到有机的串联。

在智驾功能安全量产落地的过程中，笔者也发现了一些技术上的新问题：比如说安全理论和实际应用的gap（典型的如RSS模型公式），再比如说功能安全和性能边界之间并没有那么泾渭分明等等。应该说这些问题跟智驾产品本身的复杂性是有密切关系的，也没那么容易解决。“革命尚未成功，同志仍需努力”，这是一项持久战，大家都要做好心理准备。

-end-

分享不易，恳请点个【👍】和【在看】