11月7日-8日，2024中国汽车软件大会在上海嘉定召开。本届大会由中国汽车工业协会和安亭•上海国际汽车城联合主办，以“软件智领未来，融合共创生态”为主题，共设置“1场闭门会议、1场大会论坛和6场主题论坛”。其中，在11月8日下午举办的“主题论坛五：融合共建：汽车基础软件新路径”上，AUTOSEMO技术专家程智锋发表精彩演讲。以下内容为现场发言实录：

　　各位专家大家好！我是来自地平线的程智锋，今天下午很荣幸受AUTOSEMO研究报告工作组委托，代表给大家分享一下关于自动驾驶Linux功能安全的研究报告，这项报告在汽车工业协会软件分会和AUTOSEMO的支持和组织下进行开展。
　　前面几位专家在演讲当中已经讲到自动驾驶系统的开放式软件架构，我们这项报告是属于开放式软件架构里面一个具体技术点——自动驾驶系统中所用到的Linux系统功能安全的研究。从几个方面分别给大家做一个介绍。
　　首先关于这项工作的背景。刚才几位专家也提到，对于自动驾驶软件架构来说，由于受到新型电子电气架构驱动，出现智驾域、座舱域、车控相互融合，在整个智能驾驶系统里出现多操作系统、多功能安全等级并存的局面。在多系统加持下才能共同完成智能驾驶、座舱内人机交互、车控等功能的并行运行。
　　这张图里所示的整体自动驾驶的软件架构刚才诸位专家都已经介绍过，这里不多赘述。在我们多域融合过程当中，并存多项具备不同功能安全等级的操作系统。其中这红色虚线框内的系统是我们这项报告本身主要研究对象，该系统主要承担是面向自动驾驶的基础底座，比如支撑上层的感知、规划以及决策这样的功能的底层的系统，这是我们今天所重点讨论的对象。
　　对于这一类系统来说，右边的几项内容是我们在进行选型，评估过程当中的重点关注点。首先，针对这类HL（High Level）的系统是否经历过严格的前装量产的检验以及在向上层感知规控功能当中至少要达到ASIL B的功能安全等级。在项目评估选择过程阶段，当我们放眼到目前市场，看上去应该选择面是挺多的，但到项目落地的过程中，我们发现其实可选的范围是非常有限的，其中有一个关键衡量因素就是该系统的功能安全特性，是否达到ASIL B安全水准。
　　为什么Linux系统应用于自动驾驶，其原因大家应该说普遍都非常熟悉。实际上有多个考虑点，不管从技术层面，从它的开源开放，从生态，包括人才储备，开发队伍的规模，这样的角度，大家共同倾向采用Linux系统。我们报告中整体预判，认为Linux系统未来将在自动驾驶领域需求，它所占的份额会持续提升。
　　在自动驾驶领域对于safety OS的功能安全需求来说，我们从3个层面去考虑：第一个就是从现在的法律法规层面，随着监管的趋严及法规完善，不管是全球法规如R152还是国内针对L3自动驾驶领域准入法律法规，共同对自动驾驶功能应用驱动所带来芯片和底层的操作系统功能安全，提出更高功能安全要求。
　　这里面以R152标准为例，对于ADAS系统里面最基础的AEB功能，也非常强调其可追溯性。我们从保守的角度解读，从应用功能推导到底座也就是操作系统和芯片这部分需要同时具备功能安全特性。
　　第二个层面，从国内OEM视角，同时面临在出海业务以及高等级自动驾驶的发展演进，也要去选用功能安全的操作系统。行业往上迁移到L2+等级自动驾驶去竞争，典型应用就是城区NOA智驾功能，处于最底座的这部分需要满足功能安全和高实时性、低延时的要求。
　　此外对于全球化布局的OEM和Tier1来说，它的流程体系，包括产品整体方案里面都对Safety OS提出来更严格的功能安全要求。
　　然而现状是什么？由于目前还没有出现应用于自动驾驶且达到ASIL B功能安全的Linux系统产品，在严格要求的场合，大家还是会倾向于使用已经通过认证的Safety RTOS的方案。
　　基于此，由多家机构于2023年1月共同发起这项关于自动驾驶Linux功能安全研究的项目，由地平线、长安汽车、红帽软件及零束科技四家单位联合牵头，整个参与单位有30余家，该工作主要受中国汽车工业协会软件分会和中国汽车基础软件生态委员会AUTOSEMO等单位指导和组织，在今年9月发布研究报告1.0。该报告聚焦在自动驾驶场景下面对国内外目前行业进展调研和综述，并在技术维度结合Linux安全特性如何进行功能安全开发和设计。另外，作为持续性的工作，后续会发布报告2.0版本。
　　正如刚才所讲到的报告分两个维度，分别是：1）我们从各类调研对象展开，涉及行业里面多个领先玩家，对于标准化涉及到的功能安全的标准，到行业代表性产品进展，从主机厂到Tier1到部件供应商等维度；2）技术功能安全开发过程。
　　这里简要介绍一下报告1.0的一个框架，整个报告分为十章内容，前面几个章节主要还是偏于通用性的概述，重点内容从第三章开始对Linux功能安全的全方位综述，第四章起对综述中所提到的工作进行专题分析，包括ELISA，经典的ISO26262如何去结合Linux去进行功能安全相关的设计和开发进行分析，ISO PAS8926标准与Linux结合，第7章有功能安全的各模块的开发过程，以及第8章是所涉及到开发过程中一些环境、工具和工具链，第9章是如何进行Linux相关的认证，最后第10章是总结和展望。附录部分包含两个在Linux开发过程中所涉及到的技术，具体的模块开发举例以及RUST语言如何进行内核安全开发。
　　10章内容的侧重点，其中第3章内容是我们报告调研部分最重要的内容，首先对于Linux的所涉及到的功能安全的范围的示意图，分析为什么在Linux里面对于取得功能安全认证，其固有安全性设计上的不足和挑战，在国内外行业里面对于目前进展的概述，从行业机构、标准角度、供应商、整车厂角度，我们分别进行了列举和分析。
　　第4章开始，去进入到具体章节里面，ELISA分析部分最核心观点是功能安全的开发应该结合具体的场景，涉及到的系统去进行特定的分析。
　　对于ISO 26262来说，主要针对Linux如何取得ASIL B为目标，结合通常的汽车软件开发流程如V模型，以及和社区开发产出成果，与Linux如何去进行结合，在这个层面去做一些分析。
　　对于ISO PAS 8926标准这部分，由于该标准所最新提出来的新的概念，就是预先存在的软件架构元素PSAE，对PSAE进行了多方面的分析，包括它的影响分析、实用性评估，以及在哪些场景下适合用PSAE方法进行分析，这项标准本身一个积极意义在于在汽车行业现存的尤其是像Linux这种开源复杂软件，如何去取得功能安全提供的一些有价值的探索和借鉴。
　　第7章开始结合Linux系统本身提供的功能安全机制，从多个层面，包括从内核安全架构、地址空间安全、内存如何去进行隔离，BSP功能安全等，里面也给出一些分析示例。
　　第8章针对我们的编译工具链和一些基础的库，比如GNU工具链中gcc的安全编译选项、数学库、libc的基础库等去做了一些分析。
　　第9章从两家认证机构角度，去给出对于现有的Linux功能安全的认证方面的建议和实践，最后是一个总结和展望。
　　接下来就把报告里面挑重点内容给大家做一个介绍，首先是对于分析对象Linux内核本身所涉及到的功能安全的模块，从内核角度可以看到有14个内核子目录的分类，所涉及的关键系统先进行拆解和分析，在后续第7章安全开发里面对这各子系统逐项进行分析。
　　在报告当中也提到目前自动驾驶领域各类企业从OEM，Tier1和零部件供应商的分类，在项目的落地实施过程当中，使用Linux系统的不同策略及发展方式，大家对于Linux所采取的一些不同的态度、实施方式以及节奏。我们看到部分整车厂会对于现有的在功能安全概念还比较严格情况下优先采用Safety RTOS，也有一些偏前瞻性方式会去展开和供应商进行在Linux的预研类项目，期待后续项目落地过程中，逐步迁移到Linux系统。还有一些考虑到项目落地速度，采用微内核结合虚拟化，包括对于Linux本身功能安全增强，来提升整体功能安全性，去保障去从整体设计角度保障功能安全，去符合相关的一些要求。还有一些OEM我们看到直接基于Linux在智驾域里面充当主力操作系统，并且结合其自研SoC里的BSP代码，UpStream到Linux社区主线代码，从5.18开始在主线代码上面可以看到。
　　从供应商角度来说更多还是受主机厂客户需求驱动，从满足需求的角度来说，不管从虚拟化，还有多系统结合，单Linux系统的方式，分别都有对应的方案。
　　关于特斯拉FSD上的系统，在车控、座舱和智驾三方面来说，尤其是在座舱和智驾都分别采用Linux系统，其中对于智驾功能利用Linux满足了感知、决策规控全套解决方案，特斯拉FSD中Linux系统最大特点是不是以通过ISO 26262认证为主要目标，而是从系统层面上面去保障包括冗余的设计如何达到更高安全性。
　　从供应商角度典型案例，英伟达在2022年的GTC会议上面所讲到的它的功能安全Linux相关方案，主要对于Linux内核分了3部分，分为Safety部分、Core部分及QM部分，3部分相互隔离，并使用Monitor进行监控，要求Safety部分上下文不受Core上下文的影响，主要在于各种内存，包括相对应的隔离机制如何满足智能驾驶功能具体要求。
　　红帽的RHIVOS系统，最大特点是在单Linux系统上实现ASIL B，从ADAS应用场景分析有哪些子系统需要满足ASIL B具体要求，此外红帽采用持续认证方法，多个子系统逐步认证的方式，达到最终ASIL B的要求。
　　EB的系统，采用组合方案，从底层基于微内核系统，结合Hypervisor和安全增强Linux的组合方案，在前几天我们看到最新的进展是Hypervisor通过ASIL B的认证。
　　综合下来，目前我们在行业里看到在智驾域通常采用三类系统方案。第一类是在一个SOC里面A核和M核分别运行有Linux和RTOS，其中RTOS和主要承载自驾业务功能的Linux进行交互，RTOS系统对Linux系统起监控和诊断。这里面满足了对于内核本身的安全性的要求，包括硬件冗余以及监控方式；第二类是RTOS+Hypervisor+Linux的组合方案，同时在比较复杂的SOC里面呈现；第三类也有部分车型直接采用基于单芯片Safety RTOS系统，也有安全岛MCU去进行交互和监控。
　　对于大家所熟知的ISO 26262的标准，如何和复杂Linux内核结合进行认证，正如我们共同感受到，由于Linux庞大代码规模，加上它开发方式，不管面向它的文档产出，还是开发、测试，第三方检测等内容，需考虑如何和V模型结合，这里面依然还是存在诸多难点。同时第三版ISO 26262正在进行修订之中。
　　ISO PAS 8926中关于PSAE的关键概念，如何跟Linux结合以及跟26262标准之间又是什么关系，报告中也做了一些分析。这里面主要从实施层面给出一些建议，现阶段应该主要采用和参考ISO 26262，鉴于ISO PAS 8926刚发布不久，从它修订到迭代以及为大家接受并实施，我们判断至少需2-3年的时间。在软件安全设计、安全编码与安全实操层面上依然存在诸多不明确的点，行业内各家单位的实践也不尽相同，如隔离机制、软件监控机制有效性、全面性如何判断等，我们还要从报告1.0到2.0后续阶段持续跟进分析。
　　第7章主要结合Linux内核安全机制如何和功能安全开发结合，也给出一些分析。主要从以下几项安全机制角度分析，分别是：地址空间安全、响应时间安全、时序安全、数据完整性，从通信到启动安全，以及如何保障它整体功能安全，在冗余设计过程当中如何进行故障诊断处理等，限于时间原因就不展开细节。
　　在认证部分，报告中列了两家认证单位，其中Linux如何去进行功能安全开发，有3项方法论层面建议，比如严格遵循ISO26262标准里Part6进行软件开发，采用软件组件的鉴定的方式以及在用证明的方式。
　　报告最后总结部分对于Linux安全合规提出一些在设计和开发上面的思路，主要有4个步骤，第一步主要对于单个Linux去进行功能安全增强；第二步ASIL B为核心的目标，结合Hypervisor的底座，支撑Linux系统进行功能安全隔离和监控。我们看到行业里主流的实施方案是结合第一步和第二步。第三步当前有些企业和组织正在以这种方式实施认证工作，主要参考ISO 26262以及国标34590的指导，通过Linux内核里SEooC的形式将Linux子系统进行分解，针对单独子系统进行功能安全改造和持续认证，对于大型复杂软件、宏内核采取逐个击破的方式。第四在将内核中必要的SEooC的子系统集成为完整的功能安全Linux产品以及发行版，具体针对智驾解决方案量产实施。在报告当中也提到了整个节奏，我们预判有望在2-3年时间也就是2026年左右解决该问题。
　　最后是关于Linux的发展建议，从现阶段起到2026年，Linux功能安全需求对应的产品仍然有机会和窗口期，这也是我们在座的各位，不管是整车厂的客户还是供应商，可以共同去对这个领域进行研究的基础。
　　对于Linux如何取得功能安全也提到一些具体技术设计建议，比如空间隔离，时域隔离，在通信上面如何保障可靠性、完整性以及如何保障所有活动内存分配等，都能做到可追溯、可监控。
　　之后展开多个层面生态合作，这个问题的良好解决有赖于行业上下游共同合作。
　　最后提出的一些事项在本报告1.0中未作重点分析，会在后续2.0阶段进行分析。例如面向自动驾驶领域的Linux内核是否要做UpStream，结合在整车的OTA的方式下，如何对Linux内核进行升级；从计算芯片角度和Linux内核版本的匹配，和整车软件系统的结合，时间节奏问题；开源Linux应用于自动驾驶产品，其商业模式和汽车行业结合的问题。这些不是功能安全的话题，但也是Linux落地过程中需要引起大家重视的问题，有赖于后续我们在报告2.0阶段去展开分析。
　　我的汇报就到这里，谢谢各位！