簡介

近年來，在開發安全關鍵軟件時，敏捷開發方法的使用日益增多。敏捷方法非常適合自動駕駛汽車軟件的增量改進、運行設計域的逐步擴展以及新型智能路側單元的開發。

由于車輛和智能路側單元的預期改進，未來幾年將會有新的自動駕駛車輛試驗。因此，包括安全檔案所需證據在內的流程必須既敏捷又標準化，以確保所有相關方的信心和信任。

本文展示了試驗運營商如何為車輛試驗運行開發敏捷安全檔案，以確保基于以下內容的頻繁更新：

· 敏捷安全檔案

· ISO 22737:2021《低速自動駕駛》

· BSI PAS 1881:2020《確保自動駕駛車輛試驗和測試的安全性 - 規范》標準

· BSI PAS 1883:2020《自動駕駛系統（ADS）運行設計域（ODD）分類法 - 規范》標準

敏捷開發方法使得制造商和運營商能夠在進行其他開發的同時，對已開發部分的安全性進行審批。

通過我們一百多個與安全檔案相關的項目（主要是鐵路領域），我們還發現敏捷安全檔案方法提高了軟件開發人員和項目工程師的安全意識、信心以及對安全挑戰的理解。

1. 引言

安全檔案（SC）—— 也稱為保障檔案或安全論證 —— 長期以來一直是核工業、汽車工業和鐵路等重要工業領域中安全關鍵系統的安全標準所要求的。我們發現的最早參考是 1997 年的 Def. 00 - 55:97。安全檔案是一種有效的方法，能讓開發公司專注于一個簡單但重要的問題：“你如何知道你的系統足夠安全？” 安全檔案的理念不是提供數學或統計證明，而是像在法庭上那樣進行論證 —— 因此得名安全檔案。在信息可用時插入信息來構建安全檔案是很高效的，這種敏捷方法還能提高安全意識和理解。

安全檔案的目的是形成結構化的論證，并輔以證據，旨在證明產品或系統在特定應用和特定運行環境中具有可接受的安全性。“敏捷安全檔案”（TASC）的目的還包括適應性、靈活性、改進的溝通和有效的解決方案。

關于如何證明試驗運行的合規性，英國的英國標準協會（BSI）發布了 BSI PAS 1881:2020《確保自動駕駛車輛試驗和測試的安全性 - 規范》標準。該 PAS 規定了英國自動駕駛車輛試驗和開發測試安全檔案的最低要求。通常是車輛 / 公交車的運營商發布此安全檔案。

2. 背景

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. 車輛試驗運行的敏捷安全檔案

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 安全檔案摘要和結論

本章應總結安全檔案前面部分提出的證據，并提出論點，證明所考慮的系統在遵守相關標準、法規以及指定的安全和安保應用條件的前提下具有足夠的安全性。

調查結果、不合規情況、建議等應在本章中引用或呈現。

4. 討論

如上所述，多個標準要求安全檔案，并且有多個標準可用作安全檔案的基礎。對于制造商來說，重要的問題是是否值得。對于使用敏捷方法的人來說，一個重要的問題是將構建安全檔案納入敏捷流程（如 SafeScrum）有多困難。在我們看來，所有開發生命周期安全關鍵軟件的項目都應該構建安全檔案，即使不是為了認證，也是為了創造安全文化并說服自己系統確實是安全的。

由于標準要求，很多必要的文檔無論如何都必須編寫，但仍然需要一些額外的文書工作和額外的活動，這些活動對客戶沒有好處，因此與敏捷宣言的以客戶為中心的理念背道而馳。

然而，文檔的重用和文檔模板的使用將減少構建安全檔案所需的額外努力。處理安全檔案將增加對系統的理解，從而導致更高效的流程。已經提到了一些敏捷方法以及 DevOps，以確保改進的流程。

5. 結論

基于上述討論，我們可以得出以下重要結論：

1. 我們開發了一個用于試驗運行的敏捷安全檔案模板（第 3 章）

2. 處理安全檔案將提高利益相關者的安全意識

3. 安全檔案可以增量開發。試驗安全檔案應不斷更新，以記錄項目的進展

4. 相關的敏捷方法包括：MVP、增量開發、敏捷合同、敏捷軟件開發流程、客戶協作和 DevOps。