内容提要：在本文中，我们提出了ISO 26262和ISO 21448之间的详细工作流程，展示了哪些阶段需要协调一致。我们还讨论了确保解决SOTIF问题的设计更改不会导致新的FuSa问题的必要性，反之亦然。我们通过一个示例架构讨论了工作流，该架构具有对驱动、制动和转向执行器的自动控制功能。

确保安全对于自动驾驶汽车来说非常重要。自动驾驶安全性主要可以从两个角度来看：功能安全(FuSa)和预期功能安全(SOTIF)。FuSa确保系统在电气和电子元件失效时的风险可接受，而SOTIF确保系统在功能不足和性能限制时的风险可接受。

ISO 26262 和ISO 21448是先进的国际标准，分别用于确保自动驾驶汽车系统符合FuSa和SOTIF。ISO 21448标准提到需要使ISO 26262开发活动与ISO 21448开发活动保持一致，并在非常高的层次上描述了映射关系。然而，考虑到ISO 21448中SOTIF开发活动的迭代性质，两个标准之间的工作流程并不是直接的一对一映射。因此，我们需要清楚地了解如何调整ISO 26262和ISO 21448开发活动，以及在一个标准中进行的分析如何影响另一个标准。

为实现这一目标，我们在本文中提出了ISO 26262和ISO 21448标准之间的详细工作流程。我们讨论了如何确定由于SOTIF更改而导致的设计变更是否会影响FuSa分析，反之亦然。我们还讨论了敏捷开发需要考虑的安全流程问题。

介绍

在开发汽车系统时，安全是我们需要考虑的重要方面之一。随着许多公司转向自动驾驶，系统的复杂性一直在增加，进而增加了安全保障方面的复杂性。安全标准，例如ISO 26262、ISO 21448，和ANSI/UL 4600就工程师和分析师如何确保汽车系统的安全性提供指导。

ISO 26262是一项功能安全标准，它为如何证明系统的电气和电子组件不会产生不可接受的风险提供了指导。ISO 21448是预期功能的安全性(SOTIF)标准，它提供了有关如何确保系统不存在由于系统中组件的功能不足和性能限制而导致的不合理风险的指南。SOTIF标准旨在减少已知和未知的风险。与ISO 26262和ISO 21448标准不同，UL 4600是一个为无人系统构建安全档案提供指导的标准。这三个标准都有助于提高自动驾驶汽车的安全性。

虽然UL 4600是一个独立的标准，但ISO 21448第4.4条提到需要使其开发活动与ISO 26262开发活动保持一致。虽然ISO 21448附件A.2.3提供了有关ISO 21448和ISO 26262开发活动一致性的顶层信息，但我们没有足够的信息来说明这些开发活动如何相互作用。此外，ISO 26262将其分析限制在与安全系统相关的电气和电子元件。然而，ISO 21448适用于整个自动驾驶汽车以及任何人机界面。因此，有必要了解系统、硬件和软件级别的活动的首选工作流程是什么，以及如何制定既能从ISO 26262和ISO 21448的角度确保安全，又有助于识别未知风险的系统化流程。

为了解决这一局限性，我们在本文中详细介绍了使ISO 26262和ISO 21448之间的开发活动保持一致的工作流。我们还讨论了工作流中考虑的流程背后的原因，并给出了一个说明性示例来展示工作流程。我们相信我们的工作流程将有助于在组织中创建更好的流程，并促进协同工作的团队之间更好的沟通。

背景及相关工作

ISO 26262

ISO 26262是道路车辆的功能安全标准。功能安全是指不存在由于电气和电子系统失效而导致的不合理风险。ISO 26262遵循系统级开发、硬件开发和软件开发的V模型。ISO 26262所遵循的过程模型以及与各阶段相关的部分编号如图1所示。

我们从概念阶段（ISO 26262第3部分）开始，在此阶段我们定义要分析功能安全的相关项。创建功能框图并确定与每个模块关联的功能。相关项定义完成后，我们将识别项目边界内模块的故障。基于这些故障，我们识别相应的危害并进行危害分析和风险评估(HARA)。在HARA期间，我们为每个故障分配严重性(S)、可控性(C)和暴露(E)等级，并确定相应的汽车安全完整性等级(ASIL)。确定的最高级别是分配给整个系统的ASIL级别。我们还定义了与HARA期间每个危害相对应的安全目标。HARA完成后，我们将创建功能安全要求并将所有发现汇总到功能安全概念(FSC)中。

FSC生成后，我们进入下一阶段：系统规范和设计（ISO 26262的第4部分）。在此阶段，我们定义系统规范、架构、技术安全要求、硬件-软件接口要求，并将发现汇总到技术安全概念(TSC)中。在定义了TSC之后，我们开始进行硬件级别的开发（ISO 26262的第5部分）。在此阶段，我们创建硬件(HW)安全规范和HW设计，分析和评估HW架构指标，计算随机硬件失效率，并执行HW集成和测试。

图1—ISO 26262（功能安全）的工作流程

我们的软件阶段（ISO 26262的第6部分）开发与硬件开发阶段并行。在此阶段，我们首先定义软件(SW)安全规范、SW架构和设计。然后我们实施软件，并执行单元、集成和基于需求的测试。

在硬件和软件级别的开发完成后，我们进入系统测试和安全验证阶段（ISO 26262的第4部分），在此期间我们制定计划对硬件、软件、系统和车辆进行集成测试，以及进行安全验证。测试完成后，我们将进入生产、运营、服务和报废阶段（ISO 26262第7部分），在此期间我们执行生产和维护计划，创建维修说明并准备用户手册。在遵循ISO 26262过程模型的同时，我们可能会使用ISO 26262第8部分中详述的其他支持过程，例如工具鉴定和配置管理。

ISO 21448

与ISO 26262不同，ISO 21448不涉及车辆中电气和电子元件的故障，也不限于安全关键系统。ISO 21448是预期功能的安全标准，主要适用于无人系统。它处理由于功能不足、性能限制和可预见的误用而出现的安全问题。

ISO 21448建议的过程如图2所示。该图显示了过程中的每个阶段及其在标准中的相应条款编号。如图所示，我们从收集无人系统的规范和设计（ISO 21448的第5条）开始。基于规范中定义的功能，我们通过识别潜在的危害行为来执行危害识别和风险评估(HIRE)（第6条）。

在HIRE期间，我们评估每个危害行为的可控性(C)和严重性(S)，如果C=0或S=0，则将它们定义为合理和可接受的风险。如果C和S均大于零，则风险为认为是不可接受的。

也是在HIRE阶段，我们可以开始制定不可接受风险的危害的验收标准规范。要定义验收标准，我们需要有一个基本原理，例如GAMAB（全球至少同样好，来自法语“globalement au moins aussi bon”）、ALARP（尽可能低的合理可行）和MEM（最小内生死亡率），以及包含事故或死亡信息的数据源。使用此信息，我们提出了一个验收标准，以确保可能导致的潜在事故数量少于人类驾驶员，或少于或类似于以前版本的车辆。

HIRE完成后，我们将对触发事件和功能不足进行分析（第7条）。在此阶段，我们确定传感器限制、算法限制、执行器限制和可能的误用案例。然后我们分析具有不可接受风险的触发条件，比如残余风险高并且可能不满足相应的接受标准。对于具有不可接受风险的触发条件，我们定义了与SOTIF相关的功能修改（第8条）。如果触发条件确实有C=0或S=0，可以到达接受标准，那么我们可以认为它具有可容忍的风险并进入到验证和确认策略的定义（第9条）。

图2—ISO 21448 (SOTIF)工作流程

定义验证和确认策略后，我们将执行已知场景的评估（第10条），在此期间我们将执行传感器验证、算法验证、执行器验证和车辆验证。一旦我们完成了对已知场景的评估，我们就会转向对未知场景的评估（第11条）。我们通过在现实世界中进行安全确认，并确保残余风险处于可接受的水平。

在完成对未知场景的评估后，我们转向SOTIF发布（第12条），我们在其中确定系统是否经过严格和充分的分析，以确保SOTIF是可接受的。如果不是，则需要执行SOTIF功能修改。如果评估人员认为SOTIF可以接受，那么我们就可以进行生产和运营。在运行阶段（第13条），仍然需要有运行时监控等机制，来识别可能导致SOTIF问题的任何新事件或条件。

相关工作

我们提出了一个涵盖系统、硬件和软件开发的完整通用工作流程。

ISO 26262和ISO 21448之间的工作流程

图3说明了我们提出的ISO 26262和ISO 21448之间的详细工作流程。矩形表示ISO 26262活动及其相关部分。圆角矩形表示SOTIF活动及其相应的条款编号。单个方向箭头表示单向关联—这意味着它是预期的活动顺序流。双向箭头表示双向关联，这意味着，根据其中一项活动的更新，可能需要再次执行另一项活动或需要修改相应的工作产品。双向虚线箭头表示ISO 26262活动和ISO 21448活动之间的双向影响。双向影响意味着在一个标准中找到的信息可能会影响另一个标准中的活动或工作产品。

如图3所示，ISO 26262从相关项定义开始，而ISO 21448从规范和设计开始。请注意，一开始可能无法拥有完整的规范和设计。因此，SOTIF是一个高度迭代的过程。从规范和设计中，我们可以生成高层功能架构（类似于FuSa的功能框图，但面向无人系统）。ISO 26262中使用的相关项不需要与我们在ISO 21448中分析的无人系统完全匹配。

在FuSa系统和无人系统之间，我们可以考虑三种不同类型的架构，如图4。对于类型1架构，我们有一个单独的保护系统和无人系统。例如，如果我们考虑为车辆配备远程监控器以确保系统安全。然后考虑与远程操作员和控件相关的系统的功能安全性，而对于SOTIF，我们考虑无人化以及人机交互。在这些架构中，SOTIF和功能安全方面不会相互影响太多，并且更容易执行变更影响分析。

我们考虑的第二种架构是类型2架构，其中功能安全系统是无人系统的一个子集。一个例子是紧急制动系统被认为是FuSa系统，但该车辆具有额外的感知算法，这些算法不包括在FuSa系统中。在这些系统中，我们需要将与FuSa组件及其接口相关的任何更新映射到SOTIF，反之亦然。它有助于使设计更好，并在我们需要在SOTIF中提供功能修改时，同时考虑FuSa和SOTIF。

图3—ISO 26262和ISO 21448之间的工作流程

图4—可能存在的架构类型

第三种架构，在图中称为类型3，需要同时符合FuSa和SOTIF的架构是同一个。一个例子是使用端到端机器学习(ML)模型的车辆，即以传感器数据作为输入，并产生车轮电机速度作为输出的ML模型。

在ISO 26262中的相关项定义之后，我们执行HARA。对于ISO 21448，我们执行HIRE。请注意，在HARA期间，可能会发现与SOTIF相关的问题，同样在HIRE期间，我们可能会发现失效。因此，我们需要跟踪它们并相应地更新分析。

在HARA之后，在ISO 26262中，我们创建了一个功能安全概念(FSC)，其中包含功能安全要求、安全目标、ASIL信息以及HARA的任何发现。我们在ISO 21448中没有FSC等同物。在ISO 26262中创建FSC后，我们进入系统开发阶段，在此期间我们首先创建系统规范和设计。虽然ISO 21448没有等效阶段，但可以更新规范和设计中的架构（以及FuSa系统架构，如果它是无人系统的一部分）。

在ISO 26262中的系统架构和设计阶段之后，我们完成了技术安全概念(TSC)，其中包含技术安全要求、硬件-软件接口规范以及作为系统安全分析一部分的任何其他观察结果。TSC阶段与ISO 21448中的活动等效的是对系统级功能不足和触发条件的分析。在此阶段，类似于我们根据ISO 26262中的硬件和软件详细信息预测功能安全问题的方式，我们根据传感器、算法和执行器列表识别潜在的不足及其原因。然而，这些不足之处无法最终确定，因为我们不确切知道组件的不足之处是什么，以及导致这些不足之处的触发条件。有必要进行自下而上的分析，以了解我们假设的潜在不足是否真的会在系统级别发生。

在ISO 26262中开发TSC之后，我们进入硬件(HW)安全分析阶段。请注意，虽然我们指定了硬件安全分析阶段，但在TSC完成后，硬件和软件开发可以并行开始。在硬件分析阶段，我们生成硬件规范、设计、评估硬件架构指标并执行FMEDA。对于ISO 21448，我们执行的等效分析是分析特定于HW组件的功能不足和触发条件。在此阶段，我们估计传感器限制、执行器限制以及ECU，或任何其他硬件性能可能受到影响的条件。

图5—包含姿态、定位、预测、规划和控制功能的类型2架构

在ISO 26262的硬件安全分析之后，我们进行硬件安全验证，在此期间我们集成硬件并对其进行测试。ISO 21448中的等效项是根据操作设计域(ODD)中可能发生的场景验证硬件组件。通过这样做，我们可以验证系统在存在触发条件的情况下，是否按预期安全运行。

在ISO 26262中的硬件(HW)安全验证之后是软件安全(SW)分析，我们在其中定义软件规范、设计和执行软件FMEA以识别软件级别的问题。ISO 21448中的等效项是对软件功能不足和触发条件的分析。在此阶段，我们确定算法限制。请注意，对于机器学习(ML)算法，我们不仅需要对ML模型进行分析，还需要对支持这些模型的ML库进行分析。

在ISO 26262中的软件安全分析之后，我们通过单元测试、集成测试和基于需求的测试来执行软件验证。ISO 21448中的等效步骤是根据ODD中的场景验证软件。在此分析过程中，我们或许能够发现算法的新触发条件。如果更新硬件或软件的触发条件，则执行自下而上的分析，以更新系统级的不足以及车辆级的危险。请注意，在分析或验证过程中，我们可能会发现新的FuSa或SOTIF问题，并且需要相应地跨标准进行映射。如果我们提出修改来解决SOTIF问题，我们还应该考虑新添加的更改是否会导致任何新的功能安全问题。

在完成ISO 26262中的软件验证后，我们进行集成和测试，然后进行整车级测试。ISO 21448中相应的等效项是基于场景的集成验证和车辆验证。在此活动期间，如果我们发现任何新问题，我们会将它们映射到触发条件和功能不足的系统级分析。此外，如果我们能够根据硬件和软件级别的验证，确定系统级事件的任何新触发条件，则会更新测试计划。请注意，车辆级验证的风险验收，是根据我们的验收标准和相应的验证目标完成的。

表1—类型2架构的工作流程说明

在ISO 26262车辆级测试后，我们进行安全确认。与ISO 21448中的此活动等效的是对未知场景的评估，我们将车辆部署到道路上并计算残余风险。在未知情况下发现的任何新问题都用于执行SOTIF功能修改以及根据需要更新规范和设计。

在ISO 26262安全确认之后，我们进入生产、运营、退役和服务阶段，在此期间我们制定生产和维护计划、升级和维修程序以及开发用户手册。ISO 26262中的一个等效项是运行阶段，在此期间我们监控部署在现实世界中的车辆，以查看是否可能出现潜在的未知触发条件。如果确定了新的触发条件，我们将其添加到现有列表中并重复SOTIF过程。

案例分析

为了对图3中所示的拟议详细工作流程和图4中所示的不同类型架构提供清晰的指导，请考虑图5中所示的以下类型2架构来执行驱动、制动和转向执行器的自动控制。

示例的工作流程在表1中提供。表中的第一列指的是ISO 26262的部分编号和ISO 21448的条款编号，我们认为它们具有一致性。符号PX表示零件编号X，符号CY表示条款编号Y。

结论和未来的工作 

在本文中，我们提出了ISO 26262和ISO 21448之间的详细工作流程，展示了哪些阶段需要协调一致。我们还讨论了确保解决SOTIF问题的设计更改不会导致新的FuSa问题的必要性，反之亦然。我们通过一个示例架构讨论了工作流，该架构具有对驱动、制动和转向执行器的自动控制功能。尽管我们讨论了阶段的对齐，但我们没有讨论在对齐两个标准时，如何考虑质量管理和变更管理。我们打算将此类分析作为我们未来工作的一部分。           

培训课程咨询及报名，添加牛小喀微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！