如何预防和缓解系统潜在失效带来的安全风险?李珍珍表示，我们的安全策略1是分析所有整车安全相关系统的失效和影响，定义安全目标和安全需求；安全策略2是多学科、跨领域的融合电子电气失效(功能安全)和非电子电气失效的系统安全开发；安全策略3是融合预期功能安全方法和流程的系统安全开发；安全策略4是整车项目系统安全发布管控，确保安全分析和安全策略落地。

针对怎样做系统安全开发？为什么做预期功能安全？怎样做预期功能安全？李珍珍展开了详细的分享，并对融合功能安全、融合SOTIF的系统安全开发流程进行了分析。

智能网联时代，汽车面临着诸多安全挑战。一是起火、触电、中毒等能量类危害；二是刹车失灵、转向卡滞等运动类危害；三是除雾失灵、屏幕卡滞等非运动类危害。在追求智能网联汽车更加智能和数字化的道路上，功能越丰富的同时，我们面临的风险越来越多，场景也更加多样化。如用手机进行泊车时，如果指令卡住应当如何对车进行控制、远程开门如何确保周围环境安全等。针对这些整车危害，我们会对整车所有的安全系统的各种使用场景进行充分分析，识别潜在的系统失效和影响，我们都知道功能安全就是关注电子电气类失效，如何预防和缓解系统潜在失效带来的安全风险就是我们一直在做的功能安全研究课题。

要想解决智能网联汽车的安全问题，我们应当分析整车所有安全相关系统的安全失效及相关影响，定义安全目标和安全需求。但是如果只考虑功能安全范畴的电子电气失效，根本无法破除现阶段车辆所面临的安全挑战。

我们把系统失效分为电子电气类、机械结构类、生产管理和材料电化学类。针对这些失效，我们认为电子电气类是功能安全所要研究的领域，但是系统的安全还应该考虑电化学和机械结构类等失效如何避免或者缓解。

怎样才能做好系统安全开发？一定需要有多领域、跨学科、全方位的安全分析及评估，提出相应的安全需求，这些安全需求是多领域的。例如，电芯杂质的管理、下线产品质量的把控等都会影响到电芯最终的安全设计，我们认为这类安全需求属于生产管理类。除此之外，从系统安全工程师的角度来看，需要关注电芯的安全测试和评估，比如在过充过放的性能状态下如何定义安全边界等问题。

机械结构类层面，对于客户所担忧的新能源车在发生碰撞后是否容易着火的问题，我们主要从底部保护和侧边保护入手，对电池包侧边所有碰撞点做评估(国标仅一个)，定义量化的安全边界并通过车身结构设计筑起安全堡垒，并通过充分的测试验证确保风险控制。电子电气类层面，我们有ASIL D电池管理系统设计。除此之外，我们还会在整车层面充分考虑用户驾驶过程中可能面临的最恶劣的场景。例如，我们发现用户在最恶劣的场景下驾驶时，电池温度有可能达到45度及以上，如果在此情况下发生热失控，与常温和低温下热扩散性能会有差异，我们基于此情况，将最恶劣的场景组合提取做电池系统的测试条件之一，验证整个电池包的热扩散性能。除了测试条件，在开发过程中，我们按照至少高于国标10倍的危害控制时间提出相应安全需求，并提供24小时不间断的电池状态监控，车内和车外多重报警，并能通过手机或安吉星等方式联系客户确认安全风险并提供相应帮助。

我们的系统安全开发融合了功能安全开发的流程体系，这个流程和方法论是一致的。从功能安全开发的角度扩展到系统安全范畴的领域，实质上就是扩展到非电子电气类的失效以及相关设计措施上。从整个风险评估以及安全分析以及安全需求的定义，到最后的设计实现和测试验证确认，是符合我们整个V模型的设计开发的。

在智能网联汽车面临的挑战下，我们不仅要做多学科跨领域的安全分析及设计，还要基于用户最真实和恶劣的使用场景定义测试要求，落实在系统安全开发流程上。

在智能驾驶层面，智能网联汽车也面临诸多风险。如算法的不确定性导致功能的偏离，无法识别推着自行车过马路的人、静止的清扫车、白色货车等，以及环境对系统的影响，例如摄像头因为天气昏暗无法识别车道线。这一类问题属于功能局限和性能局限所导致的系统相关风险。另外，其他原因也有可能导致整车出现风险，、如驾驶员对车辆功能的不理解或者错误理解导致的误用等。在此背景下，预期功能安全应运而生。

预期功能安全是指不存在因功能或其实现不充分引起的危害行为而导致不合理的风险，主要关注功能局限和合理可预见的误用。

我们将系统开发流程融入了SOTIF开发流程，主要有安全分析和安全验证两大核心。我们应用这个核心作为领域的融合关键点，在融合非电子电气类安全开发的系统安全开发流程的基础上，融合预期功能安全相关的安全分析与验证确认，确定工作过程和相关责任人以及输入输出等。

预期功能安全主要围绕两个问题。一是把已知不安全和未知不安全场景转化成已知安全场景，二是如何评估可接受的准则。在预期功能安全领域，我们已有初步探索。针对已知不安全和未知不安全场景转化为已知安全场景的问题，我们建立了SOTIF的场景库，基于这个场景库不断通过仿真/测试验证和相关数据分析积累进行迭代，将新发现的未知的场景转化为已知场景，也将已知不安全场景通过设计方案转化为已知安全场景。形成整车实际的测试用例。这是一个长期并需要一直迭代的事情。做场景库也是一个比较烦琐的过程。我们最初将所有场景进行排列后有几百万条，如何从几百万的场景中挑选出我们需要的场景是一大问题。针对场景库和我们系统的传感器或者算法局限，需要找到它们的权重匹配关系，分析在某场景组合下的关联因子。匹配完成后，我们把较为重要的场景优先筛选出来。另一种方法是先分析传感器或者算法在单个因素的场景的影响，再将所有单一因素场景下关联因子结合起来考虑实际生活中场景组合的权重，就可以帮助我们简化相关工作。例如摄像头如果遇到大雨，无论其是城市路还是高架路，影响其目标识别功能的关联度最高的还是大雨这个要素，我们可以先把这个关键要素挑出来，再进行双场景和多场景的组合分析。

针对如何评估接受准则的问题，我们也做了许多探索。我们通过虚拟场景的搭建，开发相关测试用例，评估人在某个场景下开车的情景，利用六自由度的驾驶员在环的虚拟场景测试平台进行信心度和可控度评估。我们也会做一些实车相关测试，形成车辆主观以及客观的数据库，提炼成我们想要的接受准则。

智能网联汽车安全策略3是融合预期功能安全方法和流程的系统安全开发。目前我们需要尽可能降低造车的成本，提高效率，而且车的功能越来越多，也越来越智能，这之中存在着诸多矛盾。做”费钱又费设计”的系统安全开发，不论功能安全、预期功能安全都面临着很大的挑战。这个就需要安全策略4来保障。

智能网联汽车安全策略4是整车项目系统安全发布管控，确保安全分析和安全策略落地。以泛亚为例，我们建立整车项目的系统安全发布有两个重点，一是独立性，我们团队独立于系统开发和产品定义团队，保持独立思考，完成整车级/系统级/零部件级的安全分析以及安全需求定义，并通过评审测试验证等手段确认需求的落地；二是否决权，我们有整车的系统安全发布的管控，在整车项目的各大关键节点，基于安全需求实施状态评估发布整车安全状态，换句话说如果安全需求实施不到位，项目无法正常开展。

这些系统安全开发流程的建立实施才能确保安全需求的最终落地，但是这些需要充分的系统安全的文化为基础才可能推进，。

我们积极配合行业内的预期功能安全、功能安全相关标准法规，如34590、43267道路预期功能安全标准等。更多标准的发布将为我们行业的发展和功能安全和预期功能安全开发的工作中产生助力。

针对非电子电气类的失效，我们积极参加并推动了ISOTR9968的制定工作，在ISOTR里把非电子电气类的失效融入整个功能安全的开发领域中。ISO26262的第三版修订过程中，我们也在考虑相关建议，比如从电池的角度考虑非电子电气类的失效。

（以上内容来自泛亚汽车技术中心有限公司系统安全开发经理李珍珍于2023年12月7日在2023中国汽车功能安全与质量管理峰会发表的《智能网联汽车全域的系统安全融合开发》主题演讲。）