自动驾驶车辆的敏捷安全档案

近年来，在开发安全关键软件时，敏捷开发方法的使用日益增多。敏捷方法非常适合自动驾驶汽车软件的增量改进、运行设计域的逐步扩展以及新型智能路侧单元的开发。

由于车辆和智能路侧单元的预期改进，未来几年将会有新的自动驾驶车辆试验。因此，包括安全档案所需证据在内的流程必须既敏捷又标准化，以确保所有相关方的信心和信任。

本文展示了试验运营商如何为车辆试验运行开发敏捷安全档案，以确保基于以下内容的频繁更新：

· 敏捷安全档案

· ISO 22737:2021《低速自动驾驶》

· BSI PAS 1881:2020《确保自动驾驶车辆试验和测试的安全性 - 规范》标准

· BSI PAS 1883:2020《自动驾驶系统（ADS）运行设计域（ODD）分类法 - 规范》标准

敏捷开发方法使得制造商和运营商能够在进行其他开发的同时，对已开发部分的安全性进行审批。

通过我们一百多个与安全档案相关的项目（主要是铁路领域），我们还发现敏捷安全档案方法提高了软件开发人员和项目工程师的安全意识、信心以及对安全挑战的理解。

安全档案（SC）—— 也称为保障档案或安全论证 —— 长期以来一直是核工业、汽车工业和铁路等重要工业领域中安全关键系统的安全标准所要求的。我们发现的最早参考是 1997 年的 Def. 00 - 55:97。安全档案是一种有效的方法，能让开发公司专注于一个简单但重要的问题：“你如何知道你的系统足够安全？” 安全档案的理念不是提供数学或统计证明，而是像在法庭上那样进行论证 —— 因此得名安全档案。在信息可用时插入信息来构建安全档案是很高效的，这种敏捷方法还能提高安全意识和理解。

安全档案的目的是形成结构化的论证，并辅以证据，旨在证明产品或系统在特定应用和特定运行环境中具有可接受的安全性。“敏捷安全档案”（TASC）的目的还包括适应性、灵活性、改进的沟通和有效的解决方案。

关于如何证明试验运行的合规性，英国的英国标准协会（BSI）发布了 BSI PAS 1881:2020《确保自动驾驶车辆试验和测试的安全性 - 规范》标准。该 PAS 规定了英国自动驾驶车辆试验和开发测试安全档案的最低要求。通常是车辆 / 公交车的运营商发布此安全档案。

2.1 TrustMe 项目

TrustMe 项目于 2020 年 8 月 1 日启动，将持续到 2023 年底。TrustMe 项目的主要目标是为自动驾驶公交车开发安全档案、为试验运行开发安全档案以及为公众开发安全档案。安全档案对于建立对新技术的足够信心以及获得在正常交通中试驾的批准至关重要。长期目标是在公交车上没有运行员的情况下实现搭载乘客的常规运营。安全档案与信任案例一起，通过汇集必要的信息来证明安全水平，从而为乘客和其他道路使用者、政府和保险业等多个用户群体提供信任依据。

2.2 自动驾驶公交车和试验测试

如今，自动驾驶汽车和公交车的开发是汽车领域的一个重要趋势，信任在这一过程中成为一个重要因素。然而，致力于自动驾驶车辆（AV）系统的制造商和运营商不能仅仅在任何公共道路上测试他们的技术。随着自动驾驶车辆创新步伐的加快，世界各地的城市和社区越来越多地成为测试场地。地方政府首先需要批准自动驾驶试点项目进行运营。

目前正在努力开发完全自动驾驶的公交车，运营商将使用这些公交车提供出行即服务（MaaS）。MaaS 领域侧重于具有预定义路线或地理围栏的小型穿梭公交车，以建立安全路线。许多这些穿梭公交车仍然无法绕过其预定义路线上的障碍物或在障碍物前停车。它们目前以 12 - 30 公里 / 小时的低速运行。因此，按照敏捷术语，这些公交车显然是最小可行产品（MVP），或者对于汽车而言，是最小可行车辆（MVV）。最小可行产品是产品的一个版本，仅具有足够的功能供早期客户使用，这些客户可以为产品或车辆的进一步开发提供反馈。

根据英国毕马威（KPMG）的报告，一些国家已经建立了试点测试监管的法律框架，例如新加坡、荷兰和挪威。英国框架提到安全档案是一种必要的方法。

2.3 敏捷安全档案

制造商和运营商希望让客户相信车辆是安全的。在顶层，安全档案目标很容易想象。“系统是安全的，因为……” 这句话就说明了一切。“因为” 后面的任何内容都是安全档案。安全档案的目的是告知读者，例如安全评估员：

· 你为使系统安全做了什么

· 它如何有助于安全以及你开发的证据

· 你声称所做的事情，包括证明做这项工作的人具备适当的能力。

敏捷开发与安全档案的开发非常契合，因为我们 “一次一小部分” 地开发系统。将敏捷性和安全档案方法相结合将改善项目沟通。敏捷开发提供频繁、简短且重点突出的会议，并确保每个人都能得到更新。构建安全档案提供了关于每个安全问题如何解决以及哪些安全问题尚未解决的信息。以敏捷方式构建安全档案还将改善与评估员的沟通，因为我们可以展示到目前为止所做的工作，并就我们的解决方案是否为评估员所接受获得反馈。一些已发表的经验表明这是一种可行的方法。

2.4 ISO 22737:2021《低速自动驾驶》

低速自动驾驶（LSAD）系统通常用于商业区、工业园区或大学校园区域的自动驾驶汽车，有助于解决 “最后一公里或第一公里” 问题，且无碳排放。例如，参与 TrustMe 项目的自动驾驶公交车就应用了 LSAD 系统。自动驾驶车辆中的系统被设置为在低速环境中的预定义路线上运行，是交通枢纽与另一个目的地之间短距离出行的理想选择。

长期以来，LSAD 技术的发展一直因缺乏定义所需性能和安全要求的国际标准而受阻。这使得制造商难以描述车辆的安全工程水平，或难以将各种属性和功能与车辆的感知状态进行比较。幸运的是，ISO 22737:2021 的出现将消除这一障碍。

ISO 22737 是第一个自动驾驶系统国际安全标准。它规定了 LSAD 系统中的最低运行能力、风险机动和安全要求，使制造商能够在系统设计过程中考虑相关方面。

该标准中的速度限制为：

· 车辆速度 < 32 公里 / 小时

· 行人速度 < 8 公里 / 小时

· 骑自行车者速度 < 25 公里 / 小时

该标准还提供了关于运行设计域（ODD）限制以及 LSAD 如何设计以适应不同交通情况的指导。它还包括各种系统和情况的性能测试程序。

2.5 BSI PAS 1881:2020《确保自动驾驶车辆试验和测试的安全性 - 规范》标准

由于随着交互复杂性的增加，安全档案会不断增长和演变，因此标准化安全档案并非易事。然而，存在风险管理原则的标准，安全档案的接受可以与这一过程保持一致。这就是安全档案框架的意义所在，它规定了安全档案应包括符合哪些标准的内容。作为安全档案框架，BSI PAS 1881:2020 是关于联网和自动驾驶车辆（CAV）安全试验发布的第一个标准。该标准的目的是使 CAV 能够在英国道路上安全部署。该标准由英国的 BSI 制定，并在英国标准协会的许可下发布。运营商可以应用该标准来确保自动驾驶车辆试验和测试的安全性。

PAS 1881 涉及如何构建安全档案，包括运行设计域和测试目标、运行风险评估、安全测试、运行指导和培训、安全监控、合规性以及授予的权限。

开发强大的运行安全档案的目的是证明在自动驾驶车辆的测试和试验期间，所有相关方的潜在风险都保持在合理可行的最低水平（ALARP 原则）。此外，它侧重于运行安全性，并参考了安全评估的所需结果。由于安全要求是透明的，这种风险管理标准化也将使不断变化的安全档案在未来更容易进行试验。

2.6 BSI PAS 1883:2020《自动驾驶系统（ADS）运行设计域（ODD）分类法 - 规范》标准

BSI PAS 1883:2020 是由 CAV 中心委托的系列标准之一，旨在支持英国 CAV 的开发。它规定了指定运行设计域（ODD）所需的最低层次分类法，以便制造商能够安全地部署自动驾驶系统（ADS）。

它定义了一个通用分类法，用于定义 ADS 可能部署、测试或试验的所有环境。这使 ADS 的安全性可视化，从而更容易获得信任。通过本 PAS 中的 ODD 分类法，制造商可以在其设计中指定和实施最低安全要求，而最终用户、运营商和监管机构可以在其采购中准确且一致地参考最低限度的 ODD 属性和性能要求。

PAS 1881 和 PAS 1883 的贡献在于建立对自动驾驶车辆的信心，并向公众或第三方证明车辆为何是安全的。此外，它有助于塑造未来的国际 CAV 标准，这些标准面向开发商、制造商、保险公司等。

3.1 作为本文一部分的引言

在开发安全关键软件时，敏捷开发方法的使用日益增多。这种方法非常适合以下方面的必要增量改进：

· 自动驾驶车辆

· ODD

· 智能道路产品（智能信号、天气、交通检测等）

此外，对于必要的安全补丁，有一个敏捷流程很重要。纳入敏捷流程是为了确保补丁能够在给定时间内完成，例如在一个冲刺期（通常 2 - 4 周）内。

本文的第 3 章是敏捷安全档案和 BSI PAS 1881:2021（以下简称 PAS 1881）在自动驾驶车辆试验中的适应性应用，主要针对软件部分采用敏捷方法。以下要点中的章节名称与 PAS 1881 中呈现的章节相似，以确保与该 PAS 的可追溯链接。这些章节经过重新组织，以遵循常见的开发流程。我们仅添加了 “安全档案摘要和结论” 章节，以确保快速概述主要结果，以及可能的保留意见、不合规情况、安全相关应用条件（SRAC）和建议的概述。此外，我们添加了七个子章节：

· 安全相关应用条件，第 3.7.1 节

· 安全相关应用条件（SecRAC），第 3.9.1 节

· 制造商、车辆类型、授权和许可证编号，第 3.10.1 节

· 安全档案和相关认证的层次结构，第 3.10.2 节

· 车辆识别号，第 3.10.3 节

· 软件识别号，第 3.10.4 节

· 车辆授权摘要，第 3.10.5 节

3.2 安全档案的引言、目的和范围

安全档案的本章应包括对试验、测试或服务的描述，包括角色以及公众的参与。

安全档案中应提及所应用的相关标准，例如 ISO 26262:2018 系列、ISO 21448:2019《预期功能安全（SOTIF）》、ISO/SAE 21434:2021《 cybersecurity》和 ISO 22737:2021《LSAD》。应包括安全档案的变更历史。用几句话总结变更。必须包括版本号和日期。这也是评估员和认证机构的实用信息。

3.3 自动 / 自动驾驶车辆系统，系统描述（DoS）

这通常是一个简短的章节，因为在大多数情况下，安全档案中会包含对单独的 DoS 文档的引用，该文档涉及车辆，包括相关传感器。敏捷方法包括最小可行产品（MVP，也适用于系统和系统的相关部分，在本案例中为公交车）、车辆某些系统的增量开发，例如 ADS（自动驾驶系统）和相关传感器，包括传感器融合开发。

3.4 运行设计域和测试场景

本章与 DoS 相关，可基于例如：

· SAE 2020 - 04: AVSC00002202004《描述运行设计域的 AVSC 最佳实践：概念框架和词汇》

· ISO 22737:2021《LSAD》

敏捷方法包括最小可行产品（MVP，在本案例中为 ODD/OEDR）、项目开始时相关的 ODD 限制、车辆和相关传感器的增量开发，包括传感器融合开发。此外，ODD 的增量改进。

3.5 路线选择和评估

如 ISO 22737:2021 中所述，在过去几年的大多数试验运行中，都选择了预定义路线。运营商应描述预定义路线。我们还需要描述运营商将如何确保车辆不会在路线之外运行。这可以通过例如物理屏障或地理围栏来实现。到目前为止，我们还没有看到所选路线的增量开发，而是转向新的测试地点。

3.6 运行风险评估

运行风险评估通常作为单独的文档呈现。流程和证据应可重用，并包括敏捷方法，因为随着系统描述（包括传感器的车辆和 ODD）的增量开发，分析必须更新。英国高速公路局发布了安全风险评估要求。

3.7 运行指导

此信息通常包含在 OM（运行和维护）手册中。在某些情况下，SRAC 也包含在 OM 中。在某些项目中，它们包含在单独的文档中，或者仅包含在安全档案中。项目早期通常会发布多个 SRAC，然后作为项目的一部分，对车辆、ODD 以及例如人机界面（HMI）进行增量改进。

3.7.1 安全相关应用条件

本节定义了在车辆应用中需要遵守的与安全相关的规则、条件和约束。每个 SRAC 应至少与一个危害相关联，并且应让运营商能够理解。SRAC 有时包含在 IOM（安装、运行和维护）手册中，见下文子章节。

在第一个版本中有时会有多个 SRAC。通过增量改进，数量可以减少。下表显示了 SRAC 模板。

表 1：SRAC 模板

3.8 远程监控、运行和控制

如果自动驾驶车辆受到远程监控，运营商应证明该系统能够提供与警觉且称职的安全驾驶员坐在车辆驾驶座上相同水平的安全性、控制力和响应时间。必须描述如何监控、运行和控制车辆以及自动驾駛基础设施支持（ISAD），例如智能道路产品。这通常是一个单独的文档。安全档案应提供足够的证据，证明安全驾驶员或远程运行员能够随时恢复对车辆的完全控制，并且能够达到最低风险状态。

3.9 安全性

ISO/SAE 21434 于 2021 年 9 月发布。该标准包括对网络安全档案的要求。通常，参考此网络安全档案并提及相关限制、假设和 SecRACS 就足够了。ISO/SAE 21434 中对补丁的描述很少。如果需要打补丁，应进行影响分析，以评估是否对安全产生影响。当安全受到影响时，必须更新安全档案。如果没有，制造商可以进行安全补丁。IEC TR 62443 - 2 - 3《工业自动化和控制系统安全 - 第 2 - 3 部分：IACS 环境中的补丁管理》中描述了安全补丁。拥有敏捷的软件开发流程以便能够快速更新软件非常重要。

3.9.1 安全相关应用条件，SecRAC

除了相关的车辆授权外，本部分还应包含对安全档案、任何系统、子系统、设备或传感器的证书的引用，所考虑的系统依赖于这些。

3.10 系统安全保障

系统（自动驾驶车辆）的验收基于授权车辆，包括已经具有相应安全档案或类似文件的产品或项目。在规划和执行例如系统测试和分析时，必须仔细研究这些文件并将其考虑在内。

在以下子章节中，我们描述了评估自动驾驶车辆时的相关主题。

3.10.1 制造商、车辆类型、授权和许可证编号

车辆供应商必须遵守常规信息要求。因此，他们必须包含关于以下方面的信息：

1. 制造商和类型

2. 型式批准（在欧洲根据法规 2018/858）

3. 汽车牌照号码

3.10.2 安全档案和相关认证的层次结构

不同的子系统通常基于相关的安全档案。任何系统的相关安全档案都是所考虑的产品或系统所依赖的子系统、项目或设备，见图如下。

图 1. 相关安全档案的层次结构。SEooC（上下文外安全元素）

一些子系统、项目或设备可能不包含安全档案，但它们可能具有符合例如通用 IEC 61508 安全标准的合规证书。

3.10.3 车辆识别号

车辆识别号（VIN）（也称为底盘号或车架号）是制造商在汽车上提供的唯一代码，包括汽车行业用于识别单个机动车辆的序列号。标准化信息见 ISO 3779:2009《道路车辆 —— 车辆识别号（VIN）—— 内容和结构》。

图 2. 车辆识别号

3.10.4 软件识别号

软件版本控制变得越来越重要，因为软件可以在车辆的整个生命周期内进行更新。即使旨在改进，软件更改也会引入新的行为，从而带来新的风险。这意味着汽车，或者至少是与安全相关的软件，应该重新认证。然而，重新认证需要时间，在完成之前，汽车及其用户将面临风险。联合国欧洲经济委员会发布了关于 “RX 软件识别号（RXSWIN）” 的新法规（2020 年），包括解释这些要求的文件。RXSWIN 是由车辆制造商定义的专用标识符，表示有关电子控制系统中与法规 X 型式批准相关软件的信息，这些软件有助于车辆符合法规 X 型式批准的相关特性。对于车辆制造商而言，特定车辆的 RXSWIN 就像其 “Windows 版本”，制造商仅在修改经型式批准的系统时才增加该编号。

3.10.5 车辆授权摘要

在安全档案中，此信息可以总结为：

1. 制造商和车辆类型

2. 型式批准

3. 汽车牌照号码

4. 车辆识别号（ISO 3779:2009）

5. 相关安全档案和证书，包括安全方面

6. RXSWIN 编号

3.11 建模和模拟器研究

安全档案应包括在试验前进行的建模和 / 或模拟器测试的信息，以支持整体测试计划，包括例如：
a) 使用的模型或模拟类型
b) 模拟的运行设计域
c) 模拟器的任何限制，包括模拟环境的任何约束、假设或缺陷
d) 证明测试结果有效性和可靠性的证据

3.12 安全测试和验收过程

作为起点，我们假设车辆是按照 ISO 26262:2018 系列、ISO 21448:2019 和 ISO 22737:2021 开发和测试的。此外，必须进行相关的现场测试。哪些现场测试相关取决于对试验场地、相关用例、场景和风险分析的评估。验收过程可能因国家而异。

3.13 利益相关者咨询和协议

沟通是 Scrum 和 SafeScrum 的关键方面之一。敏捷宣言之一包括沟通：客户协作高于合同谈判。

安全档案应包括利益相关者列表，并详细说明与已识别组织的相关沟通和咨询。这可能包括公众教育和面向公众的宣传活动。我们在2021年自动驾驶公交车试验期间进行的审查表明，乘客认为自动驾驶公交车应该比普通公交车更安全。相关来源可以是面向公众的安全档案和信任案例。

3.14 监控、报告和持续改进

试验期间进行的监控应在安全档案中描述。安全档案应包括：
a) 负责数据采集过程的人员 / 角色
b) 正在收集的数据以及收集方式（例如，行车记录仪、传感器、摄像头、调查等）
c) 如何监控传感器、冗余和失效模式
d) 如何监控动态危害，例如天气 / 环境
e) 数据如何下载、存储和分析
f) 数据收集、传输和存储的安全性
g) 任何日志 / 监控的参数（即开始、结束、来源等）需要存储 / 保存。这还应包括数据未被篡改的保证
h) 影响试验安全性和持续性的问题的分析和报告程序
i) 负责确保遵守安全档案并作为与安全档案相关的任何关注或问题的单一联系人的指定人员姓名
j) 事件和未遂事件报告和分析流程

持续改进是采用敏捷方法和 DevOps（开发和运营）的主要原因之一。在进行持续改进时，拥有敏捷合同是有利的。挪威政府财务管理部门发布了敏捷合同模板。

3.15 安全档案摘要和结论

本章应总结安全档案前面部分提出的证据，并提出论点，证明所考虑的系统在遵守相关标准、法规以及指定的安全和安保应用条件的前提下具有足够的安全性。

调查结果、不合规情况、建议等应在本章中引用或呈现。

如上所述，多个标准要求安全档案，并且有多个标准可用作安全档案的基础。对于制造商来说，重要的问题是是否值得。对于使用敏捷方法的人来说，一个重要的问题是将构建安全档案纳入敏捷流程（如 SafeScrum）有多困难。在我们看来，所有开发生命周期安全关键软件的项目都应该构建安全档案，即使不是为了认证，也是为了创造安全文化并说服自己系统确实是安全的。

由于标准要求，很多必要的文档无论如何都必须编写，但仍然需要一些额外的文书工作和额外的活动，这些活动对客户没有好处，因此与敏捷宣言的以客户为中心的理念背道而驰。

然而，文档的重用和文档模板的使用将减少构建安全档案所需的额外努力。处理安全档案将增加对系统的理解，从而导致更高效的流程。已经提到了一些敏捷方法以及 DevOps，以确保改进的流程。

基于上述讨论，我们可以得出以下重要结论：

1. 我们开发了一个用于试验运行的敏捷安全档案模板（第 3 章）

2. 处理安全档案将提高利益相关者的安全意识

3. 安全档案可以增量开发。试验安全档案应不断更新，以记录项目的进展

4. 相关的敏捷方法包括：MVP、增量开发、敏捷合同、敏捷软件开发流程、客户协作和 DevOps。