本文作者討論了功能安全標準中不同開發流程對場景描述的需求，根據不同的需求將場景劃分為三個抽象級別并介紹了各級別場景的轉化關系。雖然本文是從功能安全標準對場景描述的需求出發，但其提出的場景標準化方法以及場景與測試用例的轉化方式，可以被應用到一般的自動駕駛系統測試與驗證中。（公眾號后臺回復：IV2018測試，即可下載PDF論文。）

摘要：2016年更新的ISO 26262標準，引入了涉及車輛安全的關鍵電氣/電子系統開發與測試的最新進展，可以應用于高級駕駛輔助系統（ADAS）和自動駕駛系統的開發和驗證。標準規定了基于V型開發模式的各個階段所要求的工作內容和輸出產品。在V型開發模式的各個階段，均可應用基于場景的方法，來獲得相應的工作輸出產品。在應用基于場景的方法時，不同開發階段對場景細節程度的需求存在矛盾。本文作者討論了ISO 26262標準中不同階段對場景描述的要求，提出了滿足一致性的場景描述方法，并演示了如何系統建立滿足不同階段需求的場景。

一、 需求：基于場景的設計與測試過程

場景可以應用到標準的整個開發過程中以得到各中間產物，從概念階段到產品開發，再到系統驗證和測試。而在整個開發周期中，要求在不同抽象級別上對所用場景有一致性表述。本節分析了基于場景的方法在ISO 26262標準定義的開發過程中的可行性，以及各流程對場景的需求。

1概念階段的場景

在標準第3部分的概念階段，該標準對項目進行了定義，進行了危險分析和風險評估，并引出功能安全概念。

項目定義包括功能定義、系統邊界、操作環境、法規需求以及對其他項目的依賴關系的描述。基于這些信息，可以派生出可能的操作場景。此過程中的操作場景應以較抽象的方式描述，并以一種易于理解的方式表示。

危險分析和風險評估包括兩個步驟：首先分析出所有故障行為，并描述導致危險事件的所有操作場景，將操作場景和故障行為加以組合從而得到危險場景；然后依據汽車安全完整性級別（ASIL）對所有危險場景進行評級。

現有對危險場景的分析由專家進行，因此為了便于專家之間的溝通理解，應使用自然語言來表述，并需要一個統一的術語表，以半正式*的方式組織起來。

綜上，在標準提出的概念階段，場景必須滿足以下需求：

1.1：人類專家應該能夠用自然語言來描述該場景。

1.2：場景應以半正式的方式表示。

*譯者注：結合上下文，此處應指非格式化的自然語言和格式化的術語組織方式的結合應用

2系統開發階段的場景

一旦分析了危險場景，就會形成功能安全概念。為了實現功能安全，須提出安全需求。與功能需求不同，安全需求描述了可量化的條件。例如，保持與其他交通參與者的安全駕駛距離的安全需求通過以米為單位的距離來確定。因此，每個危險場景都必須從半正式的自然語言表述轉換為利用狀態量表述的方式。

為了減少場景的數量，可以給定狀態量的取值范圍，或者可以進一步劃分有效/無效的取值范圍，即安全/不安全的取值，從而明確系統邊界。場景的詳細表述確保了能以可驗證的方式制定開發項目的需求。

綜上，在系統開發階段，場景必須滿足以下需求：

2.1：場景應包括用于場景表示的狀態量的參數范圍。

2.2：場景應為每項參數指定一個標記，以支持自動處理。

3測試階段的場景

在測試階段，將驗證系統是否滿足了前述流程中指定的需求。這一過程，測試必須依據標準，系統地計劃、制定、執行、評估和記錄。

測試用例生成的一個難點在于輸入數據的規范性，包括每個參數的時間序列。概念階段已經給出了系統的操作環境和可能的操作場景，這是為測試用例派生一致的輸入數據的基礎。在安全需求的制定過程中對場景進行了詳細說明，包括系統如何對可能影響安全目標的外部影響做出反應，以及滿足系統安全需求的參數范圍。為了生成測試用例的輸入數據，必須從指定場景的連續參數范圍中選擇離散參數值。此外，還必須將場景轉換為正式表達，以確保之后測試用例的可執行性及可復現性。

具體而言，必須通過不同的測試方法（如模擬或場地測試），確定用于執行基于場景的測試用例所需的所有參數，并從基于術語的半正式表達轉換為基于系統狀態值參數的正式表達。最終，系統地導出參數化場景，作為被測系統的一致輸入參數，用于驗證系統功能。

綜上，在系統測試階段，場景必須滿足以下需求：

3.1：場景應該通過具體的狀態值來描述，以確保其可執行性和可復現性。

3.2：場景應具備一致性。

3.3：場景應該以一種高效的機器可讀的方式表示，以確保自動化測試的執行。

4對場景需求的分析

各階段對場景的需求是存在矛盾的。一方面，1.1要求抽象的、自然語言的表述形式；另一方面，2.2和3.3要求高效的機器可讀的表述形式。類似的，2.1和3.1要求場景表述的細節程度不同：2.1要求通過狀態空間中的參數范圍來表述場景，這樣在確定待測量時提供了多個自由度；而3.1要求表述中包括具體的參數值，這是測試用例可重復執行的必要條件。因此，機器可讀的場景必須支持兩種不同的細節程度。

二、實現：設計和測試過程中的場景術語

正如上一節所述，在ISO 26262標準的開發過程中應用場景時，對場景的細節程度的需求是存在矛盾的。本節作者將場景劃分為三個抽象級別：功能場景（Functional scenarios）、邏輯場景（Logical scenarios）和具體場景（Concrete scenarios），如圖1所示。

圖1 滿足ISO 26262標準的各開發階段的場景抽象級別

1功能場景

功能場景是場景表述的最抽象級別。在概念階段，這些場景可用于項目定義、危險分析和風險評估。作者提出了以下定義：

功能場景是通過語義描述的操作場景。通過語言場景符號來描述域內的實體以及實體間的關系。場景描述是一致的，用于描述功能場景的術語表應由一般用例或域內專用的術語組成，并且可以具有不同的詳細程度。

功能場景的表述包括實體和實體之間的關系，不同場景的描述方式必須是一致的。首先需要制定一個術語表，這個術語表包括不同實體的術語（車輛A、車輛B）和這些實體的關系短語（車輛A超越車輛B）。為了生成一致的功能場景，術語表的所有術語必須是明確的，其來源可以是實際的標準和法規，如道路交通規則。

功能場景的詳細程度取決于實際的開發階段和正在開發的項目。例如，高速公路行駛需要描述道路的幾何結構和拓撲結構、與其他交通參與者的交互以及天氣狀況。而在停車庫行駛則需要描述建筑物的布局，而天氣條件卻無關緊要。

圖2為在高速公路行駛的一個功能場景：一輛轎車和一輛卡車正行駛在右側車道上，轎車跟隨卡車行駛。在這個例子中，道路特征主要描述為橫斷面布置情況和幾何結構特征。

圖2 功能場景實例：跟車行駛

2邏輯場景

基于狀態空間變量，邏輯場景是對功能場景的進一步詳細描述。在系統開發階段，可以利用邏輯場景派生出安全需求。作者提出了以下定義：

邏輯場景以狀態空間呈現操作場景。通過定義狀態空間內變量的參數范圍，可以表達實體特征和實體間的關系。參數范圍可以選擇用概率分布來確定。此外，不同參數的關系可以通過相關性或數值條件來確定。邏輯場景應包含該場景的形式標記。

圖3 邏輯場景實例：跟車行駛

邏輯場景涵蓋了提出安全需求所需的所有元素。為了在標準規定的開發過程中逐步規范場景，必須在狀態空間中通過形式標記來表述邏輯場景，并從取值范圍中確定參數。可以通過概率分布（例如，高斯分布，均勻分布）為每個參數指定范圍。參數范圍間的關系可以由數值條件或相關函數來指定（例如，超車速度必須大于被超車速度，車道寬度與曲線半徑相關）。

圖3顯示了從圖2所示的功能場景中衍生出的邏輯場景。功能場景術語表中的每一項都必須分配一個描述該術語的參數。在這個例子中，兩條車道都是通過車道寬度來描述的，幾何結構是由一個半徑來表示的，車輛由其縱向位置來描述，并要求卡車縱向位置大于轎車。在實際應用中，可能需要多個參數來描述單個術語，例如，一輛卡車可以通過規定其尺寸、重量和發動機功率來定義。

3具體場景

具體場景由某個確定的參數值來表示狀態空間中實體和實體間關系。每個邏輯場景都可以通過從參數范圍中選擇具體值來轉換為具體場景。具體場景可以作為測試用例的基礎。作者提出了以下定義：

具體場景以狀態空間詳細描述了操作場景。通過確定狀態空間中每個參數的具體值來明確描述實體和實體間的關系。

對于每一個具有連續取值范圍的邏輯場景，都可以派生出任意數量的具體場景。為保證生成具體場景的效率，應選擇有代表性的離散值進行組合。必須強調的是，只有具體場景可以直接轉化為測試用例。要將具體場景轉換成測試用例，需要增加被測對象的預期行為表現，以及對相關測試設施的需求。而被測對象的預期行為則可以從操作場景、邏輯場景或項目定義中導出。

圖4顯示了從圖3中所示的邏輯場景中得出的一個具體場景。圖中可以看到，每個參數都從指定的參數范圍內確定了一個具體的參數值，從而確定了一個特定的測試條件。

圖4 具體場景實例：跟車行駛

三、結論

本文分析了基于場景的方法在依據ISO 26262標準開發自動駕駛系統過程中的可行性。作者分析了可以使用場景來生成工作輸出產品的各個工作階段，并明確了不同階段對場景描述的需求，闡述了場景描述需求在細節程度上存在的差異。在此基礎上，作者定義了場景的三個抽象級別，以滿足上文闡述的場景需求。