随着汽车软件的不断发展，汽车软件开发周期变得越来越短并且软件复杂性也呈几何指数上升，与此同时我们也需要关注软件问题可能导致的安全性风险，其不仅仅关乎驾驶员和乘客的安全，也关系到其他道路使用者的生命财产安全。
因此软件开发需建立在安全需求基础上，通过有效的软件功能安全需求，我们能够避免或迁移潜在的系统故障引发的事故风险，本文将围绕什么是软件功能安全需求、如何进行软件安全分析来展开介绍。
本期专家 ：
Zhike(左)、Alex(右)
博世智能驾驶与控制系统事业部中国区
软件功能安全专家
软件安全需求设计
① 技术安全需求TSR (系统需求级别);
② 硬件/中间层/操作系统/基础软件等导出的安全需求 (使用假设);
③ 集成平台或外部应用层软件模块的安全限制需求 (使用假设);
④ 权衡功能可用性
(functional availability)
那什么是软件安全需求？
软件安全需求 = 安全相关的软件功能需求 + 软件安全机制
① 使标称功能能够安全执行的功能；
常见如时钟，电源等确保软件安全运行的功能；实际项目实践中也需关注安全相关的应用层功能需求，其相应的故障会直接导致safety goal的违背，这一点在ADAS安全开发中尤为重要（例如感知子系统无法采用传统E-GAS架构等安全开发方式）。
② 与性能或时间关键型操作相关的功能；
例如性能优化相关的功能模块，其失效会直接导致不满足SOTIF相关的安全指标。
③ 生产，操作，服务和退役期间与机载和非机载测试有关的功能；
例如车载通信、车辆诊断等相关内容。
④ 允许在生产和服务期间修改软件的功能；
例如可配置参数或者标定数据等。
① 与基本软件或应用软件本身故障相关的自检或监控功能；
例如应用层软件程序流监控，合理性校验，上电自检等。
② 与安全相关要素的故障检测，指示和缓解有关的功能；
例如控制单元电源、时钟等安全要素的故障探测。
③ 使系统能够达到或保持安全状态或降级状态的功能；
例如失效后的功能降级管理，系统安全状态的行为等。
④ 对软件功能和特性的要求，包括不同功能之间的独立性或免于干扰。
例如独立性免扰分析中的软件分区等。
① 基于软件安全需求整理出安全关键路径，这是后面安全分析和风险评估的基础；
② 在架构层面对安全关键路径和非安全功能路径做免扰分析，保证接口/内存/时序上的独立性;
③ 在静态软件架构层面，分析接口/通讯潜在失效导致的安全风险；
④ 在动态软件架构层面，分析多并发线程下可能导致的故障是否违背安全需求；例如需要考虑:
软件单元调度的优先级；
软件单元的执行时间；
故障降级管理的最小时间要求;
多应用场景下的功能模块安全部署等等。
安全需求导向软件分析
这里提一下算法性能不足导致的非预期输出，比如车速补偿，一定程度上也可以归类为性能问题，但本质上也属于系统性失效，因此安全文化保守的OEM或供应商（如博世）会将其也列入安全导向软件分析的考虑范畴。
做SSA分析前，应明确分析颗粒度，即分析对象最小到什么层级，这决定了SSA的输入信息来源（比如分析颗粒度是runnable，那么需要的输入为对runnable的安全需求，原则上不必须打开runnable内部设计，当成黑盒）。但值得注意的是，在项目实操中，这个颗粒度更多起到的是一种guide的作用，但应避免将其奉为死规，很多情况下（尤其对算法类设计这种上层需求很难清晰严格定义的设计），适当下探最小颗粒度对找全找对合理失效模式和影响有很大的帮助。
① 软件复杂度：
软件接口数量，数据结构复杂程度，内部状态机数量，变量数量，程序流路径分支数量和交叉情况。越复杂的软件，越难理解，越容易出错，也越必要安全机制。
② 软件成熟度：
软件是否复用，Base软件市场运行情况，可以判断软件是否成熟，越不成熟的软件越需要额外安全机制。（值得注意的是，由于软件市场运行情况监控很难举证，这个方面在实操中需要谨慎，通常会将其转化为专家经验作为判断支持依据，但不作为决定性因素，在只有这个点支持时，一般保守考虑会要求增加安全机制）
③ 安全影响程度：
造成的impact对安全造成多大的影响，从功能安全角度考虑，违反安全目标的都是顶级，但实操时一般会根据伤害程度和伤害概率不同进行一些主观调节。（如顶层安全目标是超过ODD速度区间还是紧急避碰失效，二者都是安全相关，但critical程度有很大区别）
① 值域类监控：
Range check：如最大车速计算范围，如目标探测FOV合理范围，应注意阈值对功能可用性的合理兼容，测试log统计数据是很有效的依据。
Plausibility check：这种check一般case specific，比如雷达的RCS check，video的blindness check，都可以认为是plausibility check的一种，但常见的思路是用被检测对象本身物理属性（比如车速不可能跳变）、与其他物理量的关系（比如standstill信号不可能在轮速高时置位，不同来源时间戳不匹配）、瞬态故障机制（硬件锁步或软件锁步如冗余算法）。
② 时域类监控：
Checkpoint：基于checkpoint报出-计数机制，对进程/线程的执行时间进行超时和顺序的监控，比如alive check, deadline check, control flow check。
BSW特殊设计：通过BSW的一些特殊设计监控程序流运行及进入安全状态，如MCU周期性检查特定task运行完成情况，有问题即中断并重启。
③ 通讯类监控：
常见如外部信号E2E，内部变量由中间件内存保护机制覆盖如MPU，ECC等。
实例
① 进行瞬态故障的故障注入测试，注入包括：
输入数据
内部数据
配置参数
逻辑指令
② 测试结果存在两种case:
Case-1: 大部分瞬态故障造成输出影响仅持续一个周期，无安全风险(within FTTI)；
Case-2: 某些功能模块的瞬态故障造成输出影响持续一段时间，系统表现存在安全风险；如下图，由于车速计算是时间累积效应，轮速脉冲信号的单个周期瞬态故障会导致一段时间的错误车速输出，从而导致感知目标属性错误，造成最终系统故障行为表现。
①从影响分析的结果来看，Case-2相关的功能模块即为瞬态故障下的安全薄弱点，此时可以从架构层面考虑，例如关键功能模块部署到MCU锁步核、关键逻辑冗余计算和冗余输出比较等常见软件架构安全设计。
② 这里基于车速计算模块提出了监控机制，例如对轮速脉冲信号做了以下安全机制:
Range check/gradient check;
Timestamp check;
Plausibility check.
总结
来源:焉知汽车
-END-
