随着智能驾驶向更高级别演进，国内外政策法规已经将预期功能安全列入车辆准入考核项，目前很多车企都在积极申请加入准入试点中，行业越来越关注功能安全。
但现行标准指南和法律法规并未定义清晰量化的分析、设计、测试、评价方法和指标，功能安全实施落地没有统一的路径。
“企业需要建立预期功能安全的开发流程，并建立相关的预期功能安全的管理制度。为了更好地推动未来产品研发，我们将建立一个统一的人员角色以及职责定位。”杨雪珠是中国第一汽车集团有限公司智能网联开发院电子电气安全设计领域经理兼系统安全高级主任，她历时两年带领团队完成了功能安全首发车型红旗EHS9功能安全设计，完成了行业内首个安全融合设计方案的实施和落地。对于功能安全开发的问题，她有着丰富的实践经验。
2023年12月7日，在2023中国汽车功能安全与质量管理峰会上，杨雪珠围绕“L3级自动驾驶系统预期功能安全开发探索”展开经验分享。
中国第一汽车集团有限公司智能网联开发院电子电气安全设计领域经理兼系统安全高级主任
以下为演讲内容整理:
新形势下的汽车智能安全
目前，全球智能网联汽车市场正在快速增长，市场规模逐渐扩大。2021年我国新能源汽车产销再创新高，达到352万辆、同比增长160%，L2级智能网联汽车渗透率达23.5%。随着智能网联汽车的高速发展，安全问题在这个领域变得越来越重要。
图源:演讲嘉宾素材
在人工驾驶时，94%的事故是由人为因素造成的。然而，随着智能化程度的提升，L2级车辆的安全原因将达到50%，L4级时整个安全将主要由机器负责。这意味着，汽车的制造商或当前L2级、L2.9级的供应商的安全责任也会随着智能化的提高而大幅提升。
当前，国内外对智能驾驶安全技术的讨论越来越热烈。21448相关白皮书和UNECE R157的发布，都表明国内外政策法规已将预期功能安全列到越来越重要的位置上。特别是预期功能安全标准的引入，将许多车辆的考核项纳入整个车辆准入的范畴。最近，准入试点工作已经开始进行，这是行业内当前最主要的话题。一汽正在申请第一批的准入试点单位，而我知道很多车企都在申请准入的试点。在准入过程中，功能安全、预期功能安全、信息安全等方面大概占了整个试点中50%以上的比重。除了准入之外，国家还推出了“沙盒”政策，一些企业和同行申请了安全的“沙盒”。
无论从国家政策方面还是国内外的发展层面，安全都是当前的重要话题。如何把法律要求、标准要求、法规要求、包括准入指南要求进行清晰量化的分析设计测试以及有效的评价，最终达成指标，在行业上没有统一的方法。在准入方面，大家采取各自的方法进行准入试点的申报。
企业预期功能安全总体框架
首先是企业保障层面的要求。在准入方面，企业需要建立预期功能安全的开发流程，并建立相关的预期功能安全的管理制度。在企业流程方面，我们都知道在没有预期功能安全标准之前我们的车辆也依然量产，也依然售卖。原有整车开发流程和产品开发流程随着ISO 26262标准的发布，融入了功能安全的很多要素。
在21448发布之后OEM不是建立全新的流程，而是在原有的流程基础上更加适用于自动驾驶开发的流程，包括分析设计、测试验证都把预期功能安全的活动融入到原有的企业开发流程里。同时，功能安全与预期功能安全在分析方面具有一定的交合性，这两者在分析设计方面有一定的融合。
为了更好地推动未来产品研发，我们将建立一个统一的人员角色以及职责定位。这是企业保障层面的重要措施。从流程体系建设方面来看，公司在整个安全体系的标准设计上分为三个层级。
在第一层级，我们定义了许多程序，包括原有的功能安全、预期功能安全、产品开发流程以及前瞻技术的研究等。这里也包括SEOC的定义。我们在第一层级就定义了安全的流程，此外，在安全设计程序的基础上，我们在各个开发环节都定义了符合标准流程的流程定义，以符合我们V字形的开发流程。具体分为概念阶段、系统阶段、软硬件阶段以及测试验证阶段。由于现代企业的自主化程度较高，我们在最新的流程中加入了软硬件和产品运营监控等部分，这些都是作为主机厂需要增加的部分。
图源:演讲嘉宾素材
在符合标准流程定义的基础上，我们实施了许多具体的流程方案。例如，我们将整个流程展开，包括项目计划中融入一些功能安全的要求。在我们的安全计划中，同时考虑SOTIF的部分。在图示里，所有红色部分是由于ISO 21448标准的加入而需要新增的一些流程内容。这里也有一些独立存在的部分，例如ODD的开发、误用风险的定义、包括触发条件和可接受准则的分析等，这是由于预期功能安全标准的发布所引入的一些全新的开发分析方法与设计理念。
无论如何，对于企业来说，这些都合并到总体的安全框架里，以一套完整的流程进行整个的安全开发。
除此之外，我们也定义了整个预期功能安全总体设计框架。这个框架分为三个层面。最中间的层面是与预期功能安全分析和设计相关的整体内容，围绕着“V字型”的开发流程进行展开，从程序定义到接受准则，到危害分析，风险评估，到未来的已知场景和未知场景。此外，还围绕着SOTIF产品的开发进行。在上下游各有一个环节。除了关注主机厂在产品SOTIF之前的所有开发活动之外，我们还考虑了额外的安全监控针对SOTIF量产之后一部分的工作内容。在这里我们也区分了云端的安全监控和车端的安全监控，将已知的交通事故场景、包括感知的场景导入到前端SOTIF的开发和设计里面，用大闭环完善我们的设计。
图源:演讲嘉宾素材
在分析和设计的基础上进行多支柱法的测试，即预期功能安全的过程，包括仿真测试、实车测试、定场景测试等。这是整体设计框架的概括。
产品预期功能安全开发实践
下面以实际产品开发过程中的实践为例，介绍我们在产品开发过程中预期功能安全是如何落地的。
首先需要明确国家对于准入标准的要求。企业应该建立预期功能安全的规范和设计要求，包括在准入过程中提到应该识别和评估由功能不足和触发条件引起的危害，并将其应用到功能更改中以避免不合理的风险。此外也提到了进行验证和确认准则的定义、进行预期功能安全的验证和确认等与供应商的开发接口协议相关的一些产品的要求。接下来，将这些要求细化到我们的产品设计里面。这是围绕整个分析设计、验证确认运行等流程来进行的。
下面我将逐一介绍我们在实际工作中如何定义预期功能安全标准。
首先，整个预期功能安全标准虽然具有很高的指标，但可操作性不是很强。因此，在企业的开发过程中，我们需要将这些指标细化为具体的开发过程。例如，在标准的初始工作中，对于预期功能安全的定义主要是设计和规范。在这里，我们在设计规范中除了原有的相关性定义等内容外，还融入了整个自动驾驶系统功能开发和设计所要求的设计规范和内容，这些是预期功能安全的前置条件。
图源:演讲嘉宾素材
这些前置条件包括ODD、用户定义、系统、元素、要素接口的定义、传感器、控制器、执行以及预期功能的分析等。需要注意的是，在任何一款产品开发之前，我们无法完全分析和设计这45个要素，因此，C5这部分的设计规范需要伴随着整个开发过程的持续迭代和更新，直到量产之前我们才会锁定最终的版本。
图源:演讲嘉宾素材
第二部分内容是针对危害的识别和评估。在标准中，有很多关于危害和风险的术语。虽然这些词汇在英语和汉语之间的翻译似乎很相似，但它们实际上代表了不同的概念。危害行为会导致危害的发生，而危害不能脱离场景而单独存在，它一定是在某个特定场景下才会存在。有了危害事件，才会产生事件的不可控性，从而造成对人或车的损害。
在危害分析环节，我们需要结合发生概率、暴露概率、可控性和严重度等因素来评估风险。在识别和评估危害的过程中，我们需要按照标准的要求识别整车级的危害、风险评估以及识别危害的场景等。这些活动可以通过流程图串联起来，每个要素之间存在前后置关系。
下面我举一个实例来说明。以TJP功能为例，它的危害行为是非预期的侧向运动，这既与功能安全相关也与预期功能安全相关。在定义它的危害行为时，我们首先基于整车级的危害表格进行分析。同时，在识别危害行为的过程中，我们也会考虑用户场景以及子功能等，通过关键词来定义危害。
为了使危害更加完整，我们还会通过UCA和向整车级反推的方式进行危害完整性的评估。在识别危害之后，我们需要为危害设定一个阈值，只有当该指标超过一定阈值时才会真正对车辆造成危害。这时，我们需要结合仿真措施研究和大规模可控性研究来定义危害度量值。
最后，根据危害矩阵的实际定义，我们可以判断危害的优先级和可控性准则。需要注意的是，这里的仿真数据是我们真实做过的实验结果。只有在这个区域里它的危害值是最高的，除此之外它的危害值没有那么高。因此，我们可以通过这种方式来评估产品的安全性能并进行相应的优化设计。
图源:演讲嘉宾素材
接下来，我将对潜在功能不足和触发条件进行分析和评估。在左边的图中，我们可以看到标准中的相关内容。在这个部分，我们的工作主要分为两大类:识别系统级的功能不足和误用，并将这些工作落实到要素级。要素级的工作直接指导我们的感知、决策等系统开发。
首先，我们来谈谈识别系统级的功能不足和误用。为了确保识别的完整性，我们采用了两种方法进行判定。最终，我们将这些识别结果整合成一个案例，使识别更加完整。
接下来，我们将识别出的系统功能不足和直接误用导入功能的架构里，也就是功能的架构，其中要素分为传感要素、处理要素、执行要素和外部要素。这样我们得出要素级的功能不足。除了从上到下的正向开发外，我们还在这个环节引入STPA的分析结果，识别UCA，通过UCA弥补要素级的功能不足，包括性能局限和规范不足。结合当时定义TGP功能的ODD，最终进行潜在触发条件的风险判定，这样就完成了分析内容。
在完成上述分析后，我们得到一些输入条件，包括系统级功能不足、系统级的直接误用、要素级的功能不足以及触发条件的风险要素。在这里面我们会分配到设计环节，这是整个分析工作的最终目标。
在设计环节中，我们需要涉及功能的一些修订方法、措施的定义。我们会把这些定义做成类似的库文件，无论是什么样的需求，最终都可以归结为几种设计概念里面，比如说系统的更新、对一些功能的限制、对驾驶员接管条件的判定以及一些人员误用的要素需求。这些可以认为是sotf方法措施的配置，类似于库的文件。再结合感知、规控、决策、HMI等这些方面，把我们这些要素落到设计里面，以设计的方案进行实际的分析和设计。这个就是我们建立的更新规范和定义的要素配置库。
以上内容以设计要求和规范的形式发布给Tier1的合作伙伴，进行实际的传感器、感知规控一些算法的开发，与实际设计更加紧密结合。这里的工作内容不是主机厂的范畴，我们只是以需求、要求让设计进行下去。在这个过程之后，我们更多进行的是预期功能安全的评估和审核，包括对供应商管理的过程，看整体的设计方案和设计是不是按照我们的要求实现。
供应商完成我们的设计之后会提交一个自测报告，拿到整车厂的时候会进行另外的一个预期功能安全的测试，这个测试覆盖了整个标准的C9-C12几个阶段。在行业里面比较主流的就是多支柱法的测试，我们常用是三支柱法，包括仿真测试，它主要用来验证已知的场景，并且辅助验证一些边缘的场景，包括辅助验证一些未知的场景。
图源:演讲嘉宾素材
我们将进行定场景的测试，以主要验证边界场景，并辅助验证已知场景。同时，我们还将进行里程累积测试，以验证未知场景的风险并辅助验证ODD的合理性。
