智能汽车操作系统功能安全探索与落地化实践_自动驾驶如何做到真安全 csdn

智能汽车操作系统的安全入场券

智能汽车操作系统的安全性如何保障？毋庸置疑，一定是先站在巨人的肩膀上，标准是行业智慧的体现，是经过时间见证的优秀方法论，标准不一定是最好最先进的，但一定是最基础的理论，所以对于智能汽车操作系统的安全之路第一步一定是先买入场券，我们在公司范围内建立安全体系，在基础质量体系基础上建设稳固的ASPICE体系、再在此基础上融合功能安全体系和预期功能安全体系，万丈高楼一定需要坚实的地基与框架。

在汽车行业里，很多人对于功能安全和预期功能安全的理解只停留在标准层面上，因此会有很多误解，认为它侧重在文档功夫上，甚至有些人认为它很鸡肋，但很多时候都是无知者无畏。真正的功能安全与预期功能安全一定是和技术融为一体，在开发过程中自然而然能够考虑到，也会自然而然去解决。文档作为一种载体和体现形式，虽然不是产品能够设计好的充分条件，但是一定是产品卓越的必要条件。

传统功能安全聚焦于电子电气设备的失效，对于硬件有形产品，硬件固有属性随着时间的推移会产生随机失效，例如一个电阻元器件可能随机产生开路、短路、阻值漂移等随机失效模式，如果它在一个电路中处于很关键的角色，那么它的失效可能带来整个电路、模块或设备、的失效，如果这个产品又是一个安全相关产品，它的失效就可能导致人身伤害的危险事故。而对于软件这种无形产品，软件人员能力差异，开发过程的疏忽，所使用的工具的准确度偏差都会影响最终软件的质量，这些不可量化的失效统称为系统性失效，系统性失效无法完全消除且一旦运行环境或条件达到相应触发临界点时，便一定会发生，同样，对于安全相关软件，系统性失效可能导致人身伤害的事故发生。因此功能安全的终极使命便是降低随机性失效和系统性失效，把一切风险控制在可接受的范围。

ISO26262基于对抗这两种失效给我们提供了一套最基础的方法论。总体概括，它包括两部分内容：功能安全技术和功能安全管理。功能安全技术包括逐层细化的功能安全分析，架构层面的功能安全方案设计，硬件的安全架构设计、失效探测、诊断措施、随机失效的度量与定量计算，软件的安全架构设计、故障检测与故障处理机制，各层级测试技术的充分运用。功能安全管理包括安全文化的建立、功能安全认可、功能安全审核、功能安全评估、配置管理、质量管理、变更管理、验证管理等内容。

同时ISO26262给我们提供了两种开发思路：一种是自上而下的开发，从概念阶段的HARA分析到功能安全概念FSC，到系统阶段的技术安全概念TSC，再到软硬件层面的安全需求、设计与测试，一切基于相关项定义进行分析与分解。另一种是自下而上的开发，也就是SEooC开发（脱离上下文环境的安全要素开发），我们选定要开发范围后假设它的上一层需求，以便推导出它的安全需求，然后进行相应的分析、设计和测试等一系列的活动，当它工程化实践落到实际应用场景中时，假设条件与实际条件进行相应的匹配与偏差分析。这两种开发思路的区别在于，第一种思路就是根据客户的需求进行定制；第二种思路是正向开发产品进行客户营销。

对于智能汽车操作系统，显然SEooC的开发方式更符合它的基因，而功能安全技术和功能安全管理是缺一不可的。

随着智能网联汽车的发展，面对复杂的应用场景，人们开始意识到事故的发生不仅仅来源于电子电气的失效，也有可能是功能不全、性能不足以及人的误操作。但早在传统功能安全诞生时，专家们就武断的给功能安全下了一个“针对电子电气失效”的紧箍咒，因此这些新型可能导致危害的情况衍生了一个功能安全的孪生体——预期功能安全。ISO21448在这种混沌的状态下诞生，立足对自动驾驶安全影响广泛的非故障安全领域，重点关注智能汽车的行为安全，解决因自身设计不足或性能局限在遇到一定的触发条件（如环境干扰或人员误用）时导致的整车行为危害。

ISO21448预期功能安全方法论总体概括也可分为两部分内容：一是功能设计、分析与优化；二是场景的验证与确认。前者包括功能规范设计、分析系统功能、危害识别与风险评估、改进系统设计进行功能优化；后者包括已知危险场景的评估和未知危险场景的评估。

在ISO21448标准中，从安全性和已知性角度，将车辆行驶场景划分为4类：

• 已知安全场景（区域1）

• 已知危险场景（区域2）

• 未知危险场景（区域3）

• 未知安全场景（区域4）

对于已知危险场景2，基于现有用例可以明确评估，通过SOTIF分析方法保证这类场景的残余风险足够低。基本思想是通过危害分析识别出风险场景，针对风险场景开发对应策略，再对已知场景搭建仿真环境或实车环境进行测试验证，根据实验结果优化系统设计，例如进行功能改进或限制功能使用，从而将相应的危险场景转移至区域1安全场景。

对于未知危险场景3， SOTIF基于危害分析、开放道路测试、随机输入测试等，发现系统设计不足，并将能检测到的危险场景转移到区域2当中。区域3的场景和相应用例可以通过行业最佳实践或者其他方法制定。最终基于统计数据和测试结果，间接证明区域3的残余风险可接受。

预期功能安全最终目标为评估系统在已知危险场景（区域 2）和未知危险场景（区域3）的残余风险控制在合理可接受范围。

智能汽车操作系统作为智能网联汽车的共性基础软件，所需要支持L2到L4不同的自动驾驶应用功能，因此预期功能安全的考虑也是必不可少。

无论是ISO26262功能安全标准还是ISO21448预期功能安全标准，它们只提供了最基础的方法论，而距离工程化实践还有很大的距离，按照标准开展相应活动也不过仅仅是智能汽车操作系统功能安全路上的一张入场券而已，后面任重而道远。

2020年，我们基于智能汽车操作系统的平台化特性，摸索确定其功能安全目标，由于智能汽车操作系统后续支持的服务及应用广泛，可能涵盖多种场景和自动驾驶等级，在不同的自动驾驶等级下，对智能汽车操作系统可能有不同的功能安全要求，所以最终确定按照ISO26262标准最高功能安全等级ASILD的要求对其进行流程体系构建与落地，全面建立功能安全开发流程、文档模板、检查单和各种功能安全活动指导手册。并在同年加入CAICV中国智能网联汽车产业创新联盟的预期功能安全工作组，对预期功能安全相关技术开展研究与评价。2021年初顺利通过ISO26262-2018标准流程体系认证，标志着我们在智能计算基础平台、智能汽车操作系统的安全之路上迈出了重要的第一步。

在智能汽车操作系统ICVOS产品开发过程中，我们也进行了很长时间功能安全开发模式的探索，前期采用自上而下的开发模式，从应用功能角度出发，以HWA和AEB功能为例，进行HARA分析，识别功能安全需求，基于架构分解技术安全需求，再进一步分解……在这个过程中，我们发现这种方式对于智能汽车操作系统的功能安全有两个弊端：一是对于基础平台化软件，需要支撑各种不同的应用及服务，安全需求如果来源于单纯一种或几种应用及服务并不全面，且这种方式分解出来的特定应用相关需求较多，而基础平台软件安全需求不足；二是这种分解到智能汽车操作系统层面的安全需求颗粒度不够细化。因此转为自下而上的SEooC的分析，从智能汽车操作系统的feature定义入手，进行假设分析，并进一步分解安全需求，这种方式更加聚焦共性基础软件的功能安全细节要求，实践证明这种方式更加适用于智能汽车操作系统的功能安全开发。而从应用角度启动的自上而下的分析与分解可以作为一种辅助形式，用来作为功能安全需求查缺补漏的验证。

智能汽车操作系统的安全挑战探索

智能汽车操作系统作为智能网联汽车时代的新产品，ISO26262功能安全标准无法覆盖它的安全性，即使是ISO21448预期功能安全的加持，也不能完全承载它所面对的安全挑战。

首先，智能汽车操作系统作为一个基础平台软件，需要支持L2到L4级自动驾驶应用，各种应用面临不同的使用场景，多种场景因素组合又会衍生无穷的新场景；新场景带来不可预知的功能、性能的局限性以及特定场景可能触发的失效情况，从而引发安全问题。而软件本身的属性只能对有限的场景或特征输入进行处理，这就要求对海量的场景进行抽丝剥茧，提取各种场景下共性的、与安全相关的特征进行分析，并最终分配至安全要素，而要完成对安全分析结果正确性验证则需要对海量场景进行测试，此过程的难度和工作量无疑是巨大的，需要灵活的软件架构、强大的自动化测试系统做支撑。并且汽车行业里很多标准来源于国际标准，或由国际标准转化的国家标准，而智能网联汽车安全与场景强相关，因此也具有一定的地域性，国外的标准理论固然可以借鉴，但是并不能真正彻底指导和解决中国的自动驾驶问题，中国特色的标准还在构建与规划中，还有待进一步完善。

智能汽车操作系统的软件规模也是空前庞大，随着整车电子电气架构从分布式向集中式的演变，智能计算基础平台承担越来越多原来单个ECU的功能，因此智能汽车操作系统软件代码量巨大，逻辑异常复杂，由此带来很多不确定性因素，系统性失效率可能随着代码量的增加而倍增，因为繁琐的流程和效率在一定程度上会存在冲突，大规模软件的安全性可靠性鲁棒性必然面临巨大挑战。

智能汽车操作系统中可包含算子库，对于AI算法，AI模型属性上存在一定的模糊性，参数在不断变化，没有固定的标准去评估下一次计算结果正确性，也就没有了功能安全上所谓的诊断依据。神经网络的不确定性与错误率是不可避免的，训练数据无法确保其完整性与全面覆盖，实际运行时数据与原始训练数据也会存在分布偏差，训练环境与实际运行环境可能存在差异，都可能导致输出结果偏差，这些问题无法通过功能安全方法论解决，也无法完全靠预期功能安全理论方法就能完美消除。

智能汽车操作系统底层采用linux内核，并且内部含有第三方的库函数和一些开源代码，从传统功能安全的角度，这些都是标准要求所不能接受的，而linux系统本身与智能汽车操作系统特性又高度契合，作为开源操作系统，Linux统治了服务器端75%的市场，在多年的使用、更新迭代的过程中，Linux自身具备了强大的、适应服务软件的稳定性、可靠性和安全性，同理，开源代码一般都是经过不断迭代，千锤百炼沉淀下来的行业智慧，很多时候自研代码性能未必优于开源代码。这些矛盾，就好像是一边是心之所向，一边是道德伦理；又好像一边是理想主义，一边是现实所趋，那么智能汽车操作系统如何面对这些挑战，解决这些矛盾呢。

我们在2021年到2022年的项目实践与探索中，逐渐意识到这些挑战，也逐步开始认知这些挑战背后的本质，对新生事物与理念首先是抱着一种接受的态度而不是本能的拒绝，放下安全相关标准的条条框框，用第一性原理去看待分析每一个问题，也从第一性原理去解决每一个安全问题。智能汽车操作系统作为功能安全路上的孤勇者，谁说站在光里的才是英雄，谁说只有照搬标准才算安全？！

智能汽车操作系统安全的落地化实践

在经过长达一年多的实践与探索中，我们终于对智能汽车操作系统安全实现了落地化。“世上本没有路，走的人多了，也便成了路。”对于智能汽车操作系统的安全，我们的策略是继承与创新。既继承功能安全标准与实践中的优良经验，也允许在本质趋向安全、风险可控的范围内接受一定的创新。

首先，我们定位智能汽车操作系统的安全目标的安全完整性等级，毋庸置疑，无论是其中的功能软件还是系统软件，一定要以ASILD为目标去实现，才能承载智能汽车操作系统跨车型跨平台跨自动驾驶等级的历史使命。

学习路线：

这个方向初期比较容易入门一些，掌握一些基本技术，拿起各种现成的工具就可以开黑了。不过，要想从脚本小子变成黑客大神，这个方向越往后，需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！