智能汽车操作系统安全性如何保障？
前言
汽车行业正在经历一场翻天覆地的变革，从机械化到电子化、电动化，再到自动化、智能化，以及未来的云计算化、车路云协同化……智能网联汽车时代已经拉开序幕，智能汽车的诞生推动汽车行业从硬件主导的传统方式转变为以软件为中心的个性化模式。
汽车电子产业链也在发生巨变与重塑，面向部件的整体功能式供应链转为硬件+平台化软件+定制化开发的联合形态，急需构建围绕主机厂和最终用户需求的智能计算基础平台和产业链生态，智能汽车操作系统必将成为产业核心，推动和引领智能网联汽车的发展。只有智能汽车操作系统才能支撑打造跨车型、应用定制，适配不同异构分布硬件的统一汽车智能驾驶产业化平台合作模式，实现软硬解耦、功能应用解耦、车型解耦的灵活开发模式，真正赋能主机厂的自主开发。
纵观历史，每一次科技变革，一定会带来一场旧思想的颠覆和新思想的渗透与冲击！对于汽车行业的巨变，随之带来的是新思想新理念新技术的融合与创新。
传统车企多年沉淀的优势在于强大的集成能力与规范且规模化的生产制造能力，传统汽车行业零部件供应商具有良好的电子零部件开发及供货能力，但是二者在大规模平台化软件开发方面经验欠缺，缺乏较大型软件规划、架构、设计等方面的正向积累，所以传统汽车行业的各路玩家是无法独自撑起一个完整的智能网联汽车时代，在这样智能汽车取代传统汽车的大时代背景下，融合车企规范性和ICT先进性的高科技平台软件公司必将登上历史舞台，作为中坚力量，向下实现跨车型跨硬件的扩展集成，向上赋能车企深入到软件开发中，真正实现定制化应用软件的自主开发。
由此诞生的智能计算基础平台、智能汽车操作系统，作为承上启下的时代新产物，大家对它的认知还需要时间的沉淀，而我们作为智能计算基础平台，智能汽车操作系统最早的定义者和引领者，在行业内不断的授人以渔，慢慢的让行业各路资深玩家们开始觉醒，认同，并开始协同合力共创智能网联汽车时代华章。
对于智能网联汽车，安全是最为关注的话题。从功能安全ISO26262到预期功能安全ISO21448，标准只是提供最基本的方法论，而如何真正做到安全是需要每一个从业者深度思考、深入研究以及深刻实践的。智能汽车操作系统作为支撑智能网联汽车产业的核心产品，其安全可靠也是我们一直以来追求的目标，传统的安全标准虽然按部就班的给出相应的开发指导，但是对于智能汽车操作系统而言，所需支持的应用场景复杂多变，AI算法作为服务嵌入其中，功能逻辑复杂，代码量巨大，大量开源代码的使用，基于linux内核开发的广泛应用……这些似乎都与传统的功能安全背道而驰，新生的预期功能安全似乎也还处于一种混沌状态，那么智能汽车操作系统安全性如何保障？
智能网联汽车的安全是否有明天？在智能汽车操作系统功能安全上，我们就好像是“孤身走暗巷”的孤勇者一样，虽然对峙绝望但也算一路披荆斩棘，摸索开拓出一条属于智能汽车操作系统功能安全的正确之路，也希望能把这些经验与理念传播给行业内为了确保安全而奋力作战的同行者们，大家共同真正推动落实智能汽车操作系统的安全可靠性。
智能汽车操作系统的安全入场券
智能汽车操作系统的安全性如何保障？毋庸置疑，一定是先站在巨人的肩膀上，标准是行业智慧的体现，是经过时间见证的优秀方法论，标准不一定是最好最先进的，但一定是最基础的理论，所以对于智能汽车操作系统的安全之路第一步一定是先买入场券，我们在公司范围内建立安全体系，在基础质量体系基础上建设稳固的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为目标去实现，才能承载智能汽车操作系统跨车型跨平台跨自动驾驶等级的历史使命。
智能汽车操作系统中系统软件是基础，功能软件是核心，而功能软件的重中之重则是数据流，负责节点的部署、调度与编排。系统软件其实相对成熟，操作系统内核与中间件都有比较成熟的框架和协议，也有大量的应用实践数据可以参考借鉴。而功能软件相对较新，它能更好的支持SOA架构，是软件定义汽车时代的重要产物，所以我们的安全策略是以数据流为中心，将功能软件作为重要的核心内容彻底安全化。因此我们将功能软件进行全面的功能安全产品认证，并且在基础服务中添加全面的安全机制可供应用及服务自由使用。
通过建立平台化的安全监控框架实现故障监测与故障处理的解耦，通过全面的安全分析识别安全监控所需提供的安全措施，实现以下内容：
• 故障码设计
• 异常检测对象管理
• 异常处理对象管理
• 异常监测
• 异常处理
• 异常发布
• 异常订阅
• 异常信息查询
• 系统资源监控
• 冗余-类锁步核-比较器
• 检查点服务
• 心跳服务
• 安全动态加载/运行/卸载
我们通过功能安全技术全面构建安全的环境模型服务，保障安全的接收环境数据并分类存储；安全的数据抽象，确保上行和下行数据进行安全的抽象转换与收发；安全的数据流，确保所承载节点及算法的启动、加载、部署、调度、编排、运行、退出的安全性，为智能汽车操作系统的功能安全提供全面保障。
针对智能汽车操作系统所面对超出功能安全标准范畴的那些安全挑战，我们从第一性原理出发挖掘问题的本质，同时也从第一性原理出发，找寻解决办法。这是一条真正的孤勇者之路，需要探索的勇气，需要选择性继承的智慧，更需要冲破枷锁的创新。
在智能汽车操作系统的系统软件内核选择上，Linux无疑是当前最优选择，如果仅仅因为其无法确定满足功能安全标准而弃之不用未免有点太武断。如果要把一个Linux系统完全转化为满足功能安全标准的内核，所花费的成本据不完全统计也是一个天文数字，而借鉴功能安全“ALARP”原则，所花费的成本超过其转化所带来的受益程度，那么转化这件事本身在功能安全理论上也是不支持的，所以由此看来，对于Linux我们不能一味的反对或盲目的接受，而是寻求最优性价比。
因此，我们在对待Linux的态度是“取其精华、去其糟粕”，选取关键内容进行充分功能安全分析、验证与确认，针对安全相关的特定功能对其进行自上而下的实时性和安全性评估，充分利用其自身的安全机制，同时不断为其添加新的安全机制作为现阶段可落地的安全措施。
同理，针对开源代码和第三方库函数的使用，也采用此策略，并且实践是检验真理的标准，实践数据表明集众人智慧的开源软件代码的可靠性往往高于新开发的代码，所以是默守陈规坚持所有代码重新按照功能安全标准重新编写验证还是根据实际情况评估，选取关键且薄弱的部分进行优化更加实际，在我们看来更支持后者，但这不代表我们对标准的漠视，也不代表这样做工作量会少，而是更加说明对功能安全的深刻理解，从真正的需求与目标出发，不拘泥于形式，只忠于安全本质。
对于自动驾驶复杂多变的场景，数据驱动一定是重点突破口。我们不断构建场景库、事故库，并建立随机泛化，不断积累经验数据。同时，我们也在同步尝试开展预期功能安全的危害分析与风险评估，不断的将未知的危险场景转化为已知危险场景，将已知危险场景转化为安全场景。在测试方式方法上继承功能安全、预期功能安全中测试、验证与确认的相关经验，借鉴等价类边界值的用例选取思想，充分进行仿真验证，HIL台架验证及真正的实车测试，并在SIL环境下建立全面的自动化测试机制，注重Corner case的建立、积累与充分测试。
建立中国化标准法规，才能真正适用于本土智能网联汽车及智能汽车操作系统。我们牵头和参与了多项智能网联汽车国标、团标的撰写工作，对智能网联汽车产业化落地实施有深刻的理解感悟和十足的信心。
在算法安全性方面，我们目前已对数十万张图片进行精确标注用于算法训练，同时继承功能安全标准中软件功能安全开发要求，最大限度的争取让算法设计增加可解释性，并最大限度的争取降低系统性失效影响。功能安全开发过程中，也对算法的输入输出增加检测机制，确保在输入输出端实现故障安全策略，并且在我们的安全机制中可提供软件冗余机制，在应用及服务需要时实现冗余策略。
对于智能汽车操作系统这种大规模软件产品开发，我们秉承功能安全高内聚、低耦合的设计要求，采用模块化设计、软硬解耦、模块间解耦的方式进行安全软件开发，融合继承传统车企规范性和ICT行业高效性，创建高效融合的开发流程体系。巨大的代码量会带来BUG概率的增加，但我们努力用规范高效的流程来降低BUG发生概率，让二者处于一个平衡。并在软件开发过程中，采用系统工程思维，权衡系统安全性、可靠性、可用性、可维护性。
结束语
在智能汽车操作系统功能安全这条路上，经历着“孤身走暗巷”，经历着“对峙过绝望”，但“为何孤独不可光荣”，相信“不完美值得歌颂”。安全这个话题，永远没有百分之百的绝对，竭尽全力降低风险到可接受程度就是最美的姿态。
在智能汽车操作系统安全的开拓探索中，愿所有人都能做一个不借光，不教条，不妥协，不盲从，在废墟之上造城邦的孤勇者。战吗？战啊！追寻安全的梦，竭尽我们所能，联合行业同盟之力，走出一条踏实稳健的智能汽车操作系统安全之路。
