安全標準-參考中文版自動駕駛產品安全評估2020年4月1日UL46003內容1前言(資料性)51.1目標52.1范圍摘要62.2范圍7中的元素2.3范圍限制 83參考出版物113.1規范性引用文件113.2信息參考 4術語，定義和文檔使用124.1如何解釋規范性元素(規范性)124.2術語和定義(規范性)164.3縮寫和縮略語(信息性)215安全案例與論點225.1一般225.2安全箱樣式和格式245.3主張和論據充分性285.4證據充分325.5接受的風險355.6安全文化365.7項目范圍386風險評估406.1通用406.2故障模型416.3危害576.4風險評估596.5風險緩解和緩解效果評估647與人和道路使用者的互動697.1人與人的互動697.2人際交流707.3與人和動物的互動747.4人類對操作安全的貢獻827.5弱勢道路用戶互動867.6其他車輛互動897.7引發人類安全責任的模式變更928.1通用自治管道948.2運營設計域(ODD)968.3感應1018.4感知1108.5機器學習和“Al”技術1138.6規劃1208.7預測1238.8物品軌跡和系統控制1248.9致動12817評估2572020年4月1日8.10計時1299軟件和系統工程過程1309.1開發流程嚴謹1309.2軟件質量1359.3缺陷數據1389.4開發流程質量13810可靠性14010.1通用14010.2降級操作14010.3冗余14610.4故障檢測與緩解15210.5項目健壯性15710.6事故響應15910.7系統計時17010.8網絡安全17211數據和網絡17611.1一般17611.2數據通信和網絡17611.3數據存儲18311.4基礎架構支持18612.1驗證，確認(V&V)和測試方法18912.2V&V方法19012.3V&V覆蓋19412.4測試19712.5運行時監控20412.6安全案例更新20813.1將軍21113.2工具識別21213.3降低工具風險 14.1綜合22114.4制造和物品部署22814.5供應鏈22914.6現場修改和更新23114.7操作23514.8退休和處置23815保養24015.1保養與檢查24015.3非運行安全24516.1通用24616.3指標分析和響應2542020年4月1日合格評定257合格評定包259獨立評估262符合性監控269提示元素反饋272A1兼容性274A2安全案例274A4條款映射到ISO/PAS2141前言(資料性)1.1.1該標準旨在幫助確保在設計過程中對自主產品的安全性進行了可接受的全面考慮，并將在整個系統生命周期中繼續進行。它通過強調對安全案例的徹底性進行可重復評估來做到這一點。1.1.2符合本標準并不保證安全的自動駕駛汽車。但是，符合此標準將促進更嚴格的工程設計，以支持安全的自動化車輛。還應認識到，安全案例只是自動化車輛完整安全保證框架的許多重要組成部分之一，并且預計該標準將與標準組織和監管機構定義的其他標準和測試方法結合使用。1.2.1本標準的范圍是以輕型自動駕駛公路車輛為具體示例的通用自動駕駛系統標準框架。為此，該標準版本包括適用于輕型自動駕駛公路車輛(客運和貨運車輛)的廣泛提示列表。許多提示將適用于其他自動駕駛地面車輛，甚至其他類型的自動駕駛系統，但尚未做出具體嘗試以包括適用于其他應用的廣泛提示，也未將道路車輛提示與更一般的提示分開。1.2.2本標準(UL4600)中采用的方法是要求基于聲明的安全案例，該案例實質上涵蓋了安全保證所需的全部材料。該安全案例包括一組結構化的索賠，論點和證據，證明某項物品(車輛加上有助于安全的所有其他支持)可以安全部署。為了支持該目標，UL4600評估強調確保安全情況合理地完成且結構良好。特別是，UL4600提供了改進安全案例一致性和完整性的指南。為此，特別需要一些最佳實踐的過程活動和精細的工作產品(例如，創建危害日志)。但是，沒有特定的總體設計過程是強制性的，也沒有用于創建大多數工作產品的特定方法的強制性(例如，不需要V型開發過程；可以使用任何合理的方法來創建危害清單)可以接受)。1.2.3該標準未定義過程，而是提出了評估標準來確定安全案例的可接受性。這樣，節，子句和提示元素的順序并不暗示時間順序或其他過程路徑依賴性。1.3與其他標準一起使用1.3.1該標準旨在與現有標準配合使用，以提供必要的附加要素，以確保在創建安全案例時已全面考慮了全自動項目操作的安全方面。1.3.2在最大的實際可行范圍內，開發人員可以利用所付出的努力和評估獲得的功勞來遵守其他現有標準。開發人員可以將材料合并到他們的安全案例中，這些案例是由于執行流程和生成其他標準要求的工作產品1.3.3該標準的目的是在可行的最大范圍內與現有相關安全標準兼容，尤其要避免禁止任何必要的活動或這些標準。特別是考慮了與ISO26262:2018和ISO/PAS21448:2019的兼容性。附件A討論了該標準中某些條款到ISO26262:2018和ISO/PAS21448:2019的映射。其他安全標準(例如IEC61508)是相關的，并且有望普遍兼容，但是對IEC61508和其他功能安全標準的詳細分析不在此版本的UL4600的范圍之內。1.3.4此標準超出范圍的兩個領域是設置可接受的風險水平，以及對道德的產品發布決策和產品行為的任何道德方面的要求。對于這兩個主題，開發人員都記錄已做出的決定，但是該標準未建立已記錄的接受標準。其他標準(例如IEEEP7000系列)提供了有關這些主題的指南。2.1范圍摘要2.1.1該標準涵蓋了安全原理，緩解風險，工具，技術和生命周期過程，用于建立和評估可在自主模式下運行的車輛的安全性論據。2.1.2假定在沒有人為監督的情況下進行操作，并且在基于當前項目狀態以及感知和解釋操作環境的能力的情況下，無需人工干預就可以執行和監督動態駕駛任務和其他正常系統操作。除了正常操作以外，還考慮了人為安全做出的貢獻(例如，維護),以及與未操作該物品的人(例如，行人)的互動。2.1.3當提及安全案例的范圍以及項目的操作時，該標準通常使用術語“項目”而不是“系統”或“產品”。這種方法認識到物品的安全性可能取決于基礎設施，服務，支持流程以及其他通常可能不被視為系統本身(例如車輛本身)但嚴重影響其安全性的因素。因此，所有這些都被認為在所評估項目的范圍內。2.1.4該標準假設該物品在沒有人為干預的情況下從某個定義明確的初始狀態開始自動運行到其他定義明確的結束狀態。人為輸入可能會影響期望狀態的選擇(例如，通過乘員請求目的地)。但是，操作員通過執行或監督動態控制任務(例如，通過駕駛或負責監視系統操作)減輕或引入風險的程度不在標準范圍內。類似地，操作員的績效或不履約在涉及將駕駛員控制權轉移到物品或從物品轉移風險方面所涉及的程度也超出了標準范圍。但是，確保該物品本身在正常情況下在標準范圍內可以正常執行控制功能的任何更改，因為它也會對全自動模式下的操作產生不利影響。因此，盡管本標準的某些部分可能有助于解決不完全自動駕駛的車輛問題，但涉及人類駕駛員責任，警惕性以及適當承擔車輛控制責任的能力的問題不在本標準范圍之內。2.1.5盡管信息安全是必不可少的主題，但該領域的細節超出了本標準的范圍，超出了對安全計劃的一般要求，與其他車輛安全要求相比，提示元素對于自動駕駛汽車而言可能是唯一的。合理可預見的濫用和濫用以及物理攻擊(例如物理傳感器損壞)均在范圍之內。2.1.6本標準的要求被認為是必要的，但可能不足以保證其完整性和嚴密性，以建立可接受的結構良好和可接受的完整物品安全性。2020年4月1日UL46007案件。特別是，提示元素列表被認為不是詳盡無遺的，期望設計團隊將包括與該元素及其操作設計領域相關2.2范圍要素2.2.1明確打算在本標準范圍內進行的項目操作和安全相關問題的特定方面包括：a)可能在非結構化環境中操作自治項目例：車輛是被引導到空曠農田中的第一輛車輛，該區域包含可行區和非可行區的混合區域，用于遍歷和停車，這是臨時溢出事件停車過程的一部分。沒有車道標記，也沒有定位信標。此外，在田間隨機放置了母牛和干草。沒有人協助組織停車位。這種情況屬于標準范圍。例：一群人在火災現場濺到街上。應急設備，應急人員，受害者和臨時觀察員在行動，而與正常的道路使用方式無關。存在消防水帶，掉落的燃燒碎片，小爆炸，交通信號燈停電，人行道損壞以及對正?；A設施預期的其他破壞。建筑物出口處有多人受傷，他們呼吁使用自動駕駛冰雹服務將其接送到緊急醫療機構。這種情況屬于標準范圍。注意：特定項目的安全案例可能需要ODD說明中指定的結構化環境，以確保安全操作。但是，默認情況下不假定存在結構。因此，如果適用，必須通過安全案例明確禁止在非結構化環境中運行。b)使用傳感器提供的潛在不準確，不正確，不完整或誤導性數據進行操作c)可能不準確，不正確，不完整或有偏見的數據(包括測試數據，現場報告數據，其他驗證數據和機器學習訓練數據)的影響。d)潛在的不精確，不準確或不完整的仿真模型的影響。e)項目中的硬件和/或軟件，數據收集功能，數據處理功能，通信，工程支持系統，工具和基礎結構支持的潛在缺陷和故障。f)人類對潛在風險的貢獻，包括乘員，行人，其他道路使用者，非道路使用者，貨物搬運者，維護者和檢查員。這包括不作為和委托的行為；意外和惡意的身體行為：以及在創造和減輕風險方面的g)生命周期注意事項，包括設計數據收集，工程數據管理，工具鑒定，設計，實施，測試，其他驗證，現場數據收集，操作，維護，更新，升級和報廢。生命周期注意事項還包括對環境的潛在更改，這些更改可能會影響ODD,對象類型的更改，行為的更改等。h)包括降低風險和通過遵守其他標準，特別是針對適用于那些標準范圍內的產品的ISO26262和ISO/PAS21448標準，對安全案例做出的其他貢獻。i)使用不同方法論證的能力，包括使用各種標準來支持安全性(例如，對不同的項目子系統使用不同但可接受的功能安全性標準)。2.2.2所描述的范圍內的主題都不旨在要求該物品在所描述的所有情況下都能成功提供全面的服務。相反，要求是考慮所有即時要素，并認為盡管有這些因素，風險還是可以接受的。在許多情況下，這將涉及制作排除有問題的提示元素的ODD。但是，從ODD(或類似方法)中排除提示元素會產生一種辯解，即排除本身并不會導致不可接受的風險。例：沒有車道標志的未鋪砌道路將被排除在ODD之外。安全案例通常認為，地理圍欄和地圖創建將排除所有未鋪設的道路。進一步的論點是，這種排除包括快速識別正在進行暫時未標記但仍載有交通的翻新工程例：奇數掃描儀中不包括雪。雪仍然是安全案例的一部分，以覆蓋在執行任務期間發生的不可預測的雪。安全案例通常認為，盡管有雪，它也可以通過車道內停車成功終止任務。它還進一步證明(有證據),在部署地點很少會下雪，以至于偶爾的行車道內停車所造成的產品風險升高是可以接受的。2.3范圍限制2.3.1該標準的一個重要范圍限制是它沒有涵蓋與確保人員能夠為一個自治項目提供有效的安全監督有關的詳細主題。而是，覆蓋范圍僅限于無人監督的完全自主操作，以及在人為監督的操作過程中與爭論人為監督效力無關的項目方面。同樣，操作人員安全地控制項目的能力的方面也超出范圍，更具體地說，以下內容明確地超出了本標準的范圍：a)項目控制方面的控制點不在項目本身之外的項目方面以及項目級別的安全性例子：遠程操作模式的端到端系統級安全性(包括人員監督者或駕駛員)被排除在其依賴于人員遠程操作者控制，監督或確保系統安全的程度。注意：產品級別的“項目”旨在包括參與車輛控制的外部功能，例如基于云的路線計劃系統。注意：對遠程操作命令的正確響應以及遠程操作數據從車輛中正確傳輸的范圍。但是，由于人類參與了駕駛任務，因此遙操作在系統級別上實際上是否安全超出了范圍。b)與切換或模式切換期間或之后的安全相關的人為因素，使人員應對動態控制任務的安全負責。例：確保有人力監督員并能夠根據要求安全地接管項目操作并在部分或全部自治功能被禁用時繼續安全地操作車輛的細節超出了范圍。c)為人類對動態駕駛任務的貢獻而采取的降低風險或其他安全論據功勞(例如，人類駕駛員，人類安全主管，人類遠程操作員，人類機敏性問題，人類境況意識問題)。2020年4月1日UL46009例：應該如何為遠程操作員提供安全有效的人機界面的細節不在討論范圍之內。d)原型車的道路測試應達到一定程度，以確保安全論點應歸功于人類執行和/或監督動態駕駛任務。e)有關如何確保人員可接受地滿足對物品安全中非駕駛角色的期望的細節。明確地說，識別人員對安全案例的貢獻(例如，通過執行檢查或人員正確感知和解釋項目提供的信號的能力)屬于范圍內。但是，在人的行為，心理，局限性等方面，詳細說明如何實際確保以可接受的方式進行貢獻的細節超出了范圍。雖然能力框架，員工技能列表和經驗要求可能是涵蓋安全案例的有用主題，但有關這些主題的詳細信息不在本標準范圍內。f)有關如何評估人機界面設備的適用性和有效性的細節。明確地說，識別此類設備的需求以及確保適用性和有效性的需求不在范圍之內，但是對如何滿足該需求的特定要求則不在范圍之內。例：在執行任務的任何情況下，處于自動操作狀態的汽車均不應將車輛控制權轉移給乘員。實際上，它確實嘗試將車輛控制權轉移給乘員，并提供三秒鐘的警告。在UL4600范圍內：車輛在不應該嘗試的情況下嘗試向駕駛員進行交接。在UL4600范圍內：不正確地嘗試轉移控制權而違反了完全自主的操作模式。超出UL4600的范圍：三秒是否足以警告有效切換，以及乘員是否是合格的駕駛員。例：自動駕駛汽車被設計為在某些情況下，當駕駛員合格，稱職并知道此越區切換任務參數時，會以10秒的警告將控制權轉移給駕駛員。在UL4600范圍內：在沒有發出整整10秒警告的情況下轉移控制權；設計有缺陷的制動控制機制，在某些情況下會阻止駕駛員實際在指定時間重新獲得控制權(例如，盡管試圖進行換手，駕駛員的制動踏板仍被禁用);人為操作制動踏板是否旨在在指定條件下啟動切換。超出UL4600的范圍：在任何特定的切換情況下，十秒是否足以警告有效切換；駕駛員踩下制動踏板是否是安全的(從人為因素的角度出發)切換啟動機制；檢查乘員是否是合格的駕駛員；檢查駕駛員是否具有足夠的認知能力以安全操作；檢查駕駛員是否處于正確的座位位置以進行操作控制；一旦控制權轉移給駕駛員，車輛的安全性；高級駕駛員輔助(ADAS)的功能可降低人為駕駛員控制下的風險。2.3.2還有許多其他主題超出范圍。在與安全情況相關的地方，應參考這些主題，但本標準中不包括諸如提供技術深度的提示元素之類的細節：a)特定的預期功能(例如，表面清潔，易碎貨物運輸)b)最終產品要求注意：最終產品標準旨在參考或要求該標準。c)法律和政策問題例子：確定責任，什么記錄保留政策是適當的，什么水平或產品風險實際上是社會可以接受的。d)倫理道德問題例子：解決可接受風險的問題，評估不同損失事件場景的相對嚴重性e)電動汽車安全例子：安全的電池設計，安全的電池管理算法，電池熱量管理f)通用車輛安全例子：減輕碰撞，約束乘員，加油/充電安全g)執行預期功能的與安全無關的質量方面例子：騎行品質，燃油經濟性h)碰撞和傷害緩解機制的有效性例子：安全帶，安全氣囊，兒童座椅2.3.3同樣隱含地重新定義了現有標準和可接受的做法，以至于可以接受它們以支持正在制定的安全案例。在與安全情況相關的地方，應參考這些主題，但具體內容不包括在本標準中。這些主題包括：a)政府規章例子：FMVSS,聯邦通信委員會射頻干擾發射認證b)項目的機械方面例子：尖銳邊緣，夾點，車窗提升電機關閉壓力極限c)舊版操作程序例子：車門操作，車門上的兒童鎖，貨物裝卸d)正常運行以外的其他車輛支持的詳細信息(除非自動駕駛有望提供這種支持并且這種提供與安全有關)例子：在不構成危險的情況下對與安全無關的例行維護程序的自治支持e)人在操作或監督動態駕駛任務時控件的充分性和性能以及項目響應例：根據FMVSS的要求2020年4月1日UL4600113.1規范性引用不適用日期的引用文件，其最新版本(包括所有的修改單)適用于本標準。DefStan00-56,國防系統安全管理要求FAAAC25.1309-1A,系統設計和分析FAAFOIEEE24765,系統和軟件工程-詞匯ISO26262:2018,道路車輛-功能安全ISO/PAS21448:2019,自動駕駛的安全第一；由11個汽車和移動行業領導者發布的-用于安全自動乘用車的首個框架：SCSC-153A,自治系統的安全保證目標-英國安全關鍵系統俱樂部；注意：本文件由自治系統安全工作組(SASWG)撰寫，該工作組在英國SCSC的主持下召集。SASWG的目標是針對整個生命周期中如何在與安全相關的上下文中管理自治系統和自治技術提供明確的指導，以緊密關注自治所獨有的挑戰的方式。該文件旨在解決僅基于機器學習的人工智能(Al)帶來的安全問題，計劃于2020年2月11日至13日在SSS'20上正式發布。鏈接到文檔：https://scsc.uk/SCSC-153A。4術語，定義和文檔使用4.1如何解釋規范性元素(規范性)4.1.1該標準的常用結構對安全情況的影響如下。除“EXAMPLE”和“REFERENCE”語句以及明確聲明可提供信息的任何其他內容外，所有元素都是規范性的。(有關關鍵安全案例偏差說明的摘要，請參見下面的表4.1。)a)帶編號的條款(從5.1.1開始)通常被稱為“應”遵守義務。這些旨在作為一般性說明，并帶有支持性的提示性提示元素，可提供更多詳細信息。除了在第17節中涉及處理在安全案例本身上進行的活動的一致性評估過程條款外，每個條款都在安全案例中得到專門解決。安全案例可導航性的重要組成部分是識別安全案例中支持滿足每個條款的部分的能力。除非另有說明，否則所有條款的范圍均為該項目中與安全相關的部分。b)強制提示元素：由安全案例解決。不允許出現安全案例偏差。任何安全情況下的偏差都會導致不符合項。例：“確定危害”是強制性的-必須做到。例：一個團隊試圖證明強制性提示元素X不適用于他們的項目。這是對安全案例偏離的無效嘗試。注意：在某些情況下，強制提示元素是指以分層方式考慮其他子句。應將其解釋為在安全性論點中強制性包含相關的更高級別的主張，而不是強制性地包含所引用條款的所有非強制性提示元素。尤其是，此類層次結構引用無意覆蓋安全案例偏離規則。例：強制提示元素X指出，安全情況解決了Y部分。Y部分具有高度推薦的提示元素Z。最終要求是，必須通過安全案例來滿足Y部分中所有條款的要求，但是根據其高度推薦類別，仍然允許對提示元c)所需的提示元素：由安全案例解決。僅當通過提示證明提示元素與項目和/或其安全案例本質上不兼容時，才允許發生安全案例偏離。安全案例中明確指出了對每種安全案例偏差的支持。最終產品標準可以枚舉從安全案例中可以忽略的必需元素(即，最終產品標準指定的全面默認安全案例偏差)。如果未對REQUIRED元素記錄安全案例偏差，則該安全案例不符合要求。由于非固有不適用性原因導致的安全案例偏差會導致不符合項?，F場工程反饋和變更影響分析用于檢測內部不兼容聲明無效的可能性?？山邮艿陌踩咐钍纠ǎ豪喝绻椖课匆匀魏畏绞?包括設計，操作和現場操作數據分析)使用基于機器學習的技術，則對機器學習要求的安全案例偏差。例：如果項目不以任何與安全相關的方式依賴于路標，則安全案例會偏離識別路標。支持這一觀點的論點可能是，ODD專門排除了道路標志，或者該項目僅使用道路標志以外的其他手段來收集等效信息。例：如果項目未定義ODD子集，安全情況就會偏離特定于將ODD細分為多個ODD子集的要求(即，如果某項使用單個整體ODD,則與ODD子集相關的任何要求均不適用)。例：數據尚不存在，因為在項目生命周期中從未發生過潛在事件或狀況。例如，如果尚未部署任何物品，則記錄糾正在物品操作過程中發現的缺陷的記錄。但是，對于收集和處理此類潛在事件的機制和程序，不允許出現安全案例偏差-只有在發生現場事件之前，安全案例內容的一部分才存在。好的做法是包括明確指定的占位符示例，以填充空數據集，以練習工具，過程和可追溯性。d)高度推薦的提示元素：這些是應該遵循的最佳實踐，但可以省略，尤其是對于低風險項目。安全案例中明確指出了遺漏，并提供了合理的支持理由，以提供一個根源，以便將根本原因分析追溯到這些遺漏。只要以合理的理由記錄了這些遺漏，就可以認為該安全案例是可以接受的。在包括“其他”的通用提示元素的情況下，省略“無其他”的理由是可以接受的?，F場工程反饋的主要目的是確保確定對安全相關問題有實質性貢獻的任何提示要素的安全案例偏差，并消除偏差。例：強烈建議使用特定的分析技術。安全案例指出，該技術未與“正在使用的其他分析技術可提供可比信息”的原理一起使用。該安全案例包含一個論點，即不存在可能通過將這種技術添加到設計方法中而可以預防的根本原因未知的事件歷史。此論據由根本原因分析日志支持，該日志顯示所有根本原因均已解決，在沒有其他不利信息的情況下，沒有留下可能實際上追溯到提示元素偏離的未解決候選對象。例：強烈建議立即更改要素的理由是“2019年9月23日舉行的安全案例審查會議認為這不適用?！彪m然只看技術內容，但這是特定的文檔，據說該文檔是經過深思熟慮的過程用來決定不解決提示元素的。但是，仍然必須對現場問題進行根本原因分析，并且可能取決于現場經驗而使這一理由無效。e)推薦的提示元素：這些是可選的提示元素，記錄了良好做法和/或有用技術的建議。如果采用，則可以將它們包含在安全案例中。但是，解決這些提示元素完全是可選的。不論是否包含安全案例，都被認為格式良好。f)PITFALL提示元素：這些是反模式，通常具有以下一般形式：“如果X為真，則項目傾向于增加Y的風險。”預期的解釋是，如果X為真(例如，在安全案例中出現了使用某些設計模式X或工程技術X),則除非已將認知失敗者Y明確認定為假，否則該安全案例被視為無效。換句話說，除非安全案例提出合理的論據和減輕風險Y的證據，否則Y表示被X激活的項目風險。更正式地說，術語“陷阱”標記有條件的認知挫敗者提示有關聲稱已滿足父項要求。響應陷阱提示元素可能已完成有兩種方式。(1)認為前提X不成立。對于提示元素，這相當于可接受的安全案例偏差。(2)爭論了，如果前提條件X為真或可能為真，則可以減輕后置條件Y帶來的風險。陷阱的安全案例偏離規則根據分類(強制，必需，高度推薦或推薦)應用。當沒有爭論可以避免陷阱時，就會發生安全案注意：出于評估目的，每個陷阱僅適用于列出該陷阱的特定條款的范圍。但是，在創建安全性論點(Pitfalls可能產生更大的影響)時要考慮這是一個好習慣(但可選)。g)符合性聲明。根據第17節，通過自我審核和獨立評估來評估與每個條款的符合性。每個條款都有一個一致性聲明，該聲明提供了一些指南，以標識安全案例的部分內容以及與評估該條款的一致性特別相關的其他信息來源。當評估者確定情況有必要時，允許評估者考慮符合性聲明之外的客觀證據，但根據該條款的書面范圍限制符合性判定。(自審計員可以并且應該考慮是否需要為特定項目的安全案例添加超出本標準所包含的提示元素。)一致性檢查是由項目開發者以外的其他人員進行一致性檢查(請參閱第17節)。(對于安全案例工件進行自我審核的情況非常有限；請參見第h)注意語句。這些是有關如何解釋本節規范性要素的說明，在某些情況下還提供了理論依據。i)示例列表(非規范)。在某些情況下，提供了示例。例子是非規范性的，在許多情況下，并非適用于所有項目。它們的主要目的是通過示例定義以減少潛在的歧義。第二個目的是作為常見問題的信息豐富但不完整的清單，應酌情考慮。預期并且要求安全案例的構造和評估超出任何示例的范圍。盡管在安全案例中排除示例本身并不會導致發現不符合項，但鼓勵獨立評估師提出其他示例，并根據評估經驗在必要時建議將特定示例提升為規范的即刻要素狀態。4.1.2表4.1顯示了針對不同類型元素的安全案例偏差方法的摘要：狀態。允許的安全案例偏離具有可接受的理由。影響分析和生命周期狀態更改的可能性。所有的安全案例偏差都應記錄在安全案例中并加以說明?？蛇x項目。安全案例無需提及。安全案例偏差不需要參數支2020年4月1日UL4600154.1.3支持特定子句的列表，例如MANDATORY或REQUIRED項目的列表，按以下方式解釋：a)為簡潔起見，即使未明確說明，列表中每個項目的上下文也都是首要子句。這意味著列表通常會提供一組簡潔和易用的提示，而不是完整說明的“應該”聲明。b)除非明確說明，否則列表順序沒有隱含的排名，偏好或優先級。c)除非另有特別說明，否則所有提示元素列表都可能不完整。格式正確且完整的安全案例可根據需要擴展列表，以實現可接受的安全結果。除非另有說明，否則提示元素列表應被視為安全情況下要考慮的最少要點集，而不是所有可能要點的詳盡集。d)如果不同的提示元素列表似乎重疊，則可以根據需要跟蹤單個參數或證據分支到多個提示元素。一種常見的情況是，MANDATORY提示元素將提供一個通用提示元素，而一個或多個REQUIRED提示元素將給出該通用元素的特定示例，以確保在適用時予以考慮。e)如果單個提示元素列表包含明顯重疊的項目，則足以追溯到最適合開發人員的提示元素。此類重疊列表通常用于解決跨域和子域的潛在不同解釋和術語問題。f)列表中的每個提示元素均按規定的安全案例偏差嚴格程度進行說明。因此，如果需要針對單個“必需”部分的十個元素列表進行安全案例偏離，則安全案例以一種可單獨追溯到列表中十個提示元素中每個元素的方式記錄安全案例偏離。(有關安全案例偏離的單一理由說明可能追溯到十個要素中的某些或全部，但必須記錄可追溯性。)g)短語中的“至少一個”包含替代項的子列表。在安全情況下，只需要解決列表中的一個備選方案，但是如果需要，可以另外解決其他方案。即使“強制性”或“必需”列表中出現“至少一個”,也是如此。請注意，在某些情況下，由于Pitfall語句，實際上可能需要兩個或多個提示元素。未列出的替代方案可以被視為滿足“至少一項”標準，并在可接受性方面提供適當的論據支持。(這是根據提示元素列表不被認為是詳盡無遺的原理，因此，安全案例可以根據這些提示元素列表的本地版本添加提示元素。)h)清單項目的“裁縫”必須遵守上面表4.1中匯總的安全案例偏離規則。4.1.4為了簡單和統一起見，盡管對部分本身進行編號時使用了印刷約定，但對部分，子句和提示元素的引用仍使用十進制表示法。4.1.5關于提示列表的范圍，另請參閱2.1.6。4.2術語和定義(規范性)4.2.1可以接受足以達到在安全情況下確定的整體項目風險。例：“可接受的測試范圍”是指測試范圍足以支持獲得安全隱患減免信用后安全案例對整體項目風險的聲明。注意：這是與安全案例的有效性和完整性相關的客觀術語，而不是與任何特定評估者的個人觀點相關的主觀術語。4.2.2激活(故障或危險)導致系統由于故障或危險而潛在故障的輸入或情況。例：內存中的某個事件被單個事件破壞損壞了，這是一個錯誤。當讀取存儲位置時，該故障將被激活，并導致計算錯誤，該錯誤會導致不正確或不安全的項目行為形式的故障。注意：錯誤緩解(例如錯誤檢測編碼)以及其他緩解措施可以防止激活的故障引起故障。4.2.3人工智能技術計算算法和其他技術的一般描述，包括歸納學習，有意的非確定性行為，基于規則的系統，計算機視覺，啟發式搜索和其他技術。這些通常稱為“人工智能”技術。注意：該術語旨在作為廣義解釋的描述性術語，以涵蓋通常不適合于Al之前的軟件安全方法的軟件。是否實際涉及實際的“智能”是超出本標準范圍的問題。構造滿足特定要求的安全案例(包括主張，論據和證據)。由此產生的論據表明，證據支持了這些主張。例：“開發人員應辯稱所有危險已得到緩解”指示開發人員在安全案例中包括主張，論點和證明每種危險實際上已得到緩解的證據。一個或多個執行評估的人。審查和評估安全案例。4.2.7自動化的無需人工監督或干預即可操作。2020年4月1日UL4600174.2.10(系統的)脆性4.2.11(系統的)混沌4.2.14危險等級4.2.15示范4.2.19故障模型執行故障分析時要考慮的所有故障(及其類型)的規范。4.2.20現場工程反饋從系統操作中獲取數據，以支持安全案例并識別潛在的安全案例問題。創建一個響應于子句的指定類別，屬性或子句其他方面的枚舉列表，并具有足夠的特異性以啟用評估。(備用字詞形式：標識)發生可能導致損失事件的安全相關故障注意：事故不一定會導致損失事件。在其他情況下，事件可能導致損失事件就足夠了。例：汽車未能在停車標志處停車。沒有交叉路口，因此沒有碰撞結果。如果存在交叉路口，則可能發生碰撞。即使沒有發生丟失事件，這也是一個事件。注意：所有損失事件也是事件。因此，短語“事件”等同于“事件和損失事件”。4.2.23獨立(失敗)沒有相關的，共同的原因和/或共模故障情況的兩個或更多個故障遏制區域(FCR)。注意：假設隨著時間的推移沒有累積故障，則可以通過無條件概率的簡單乘積來表示同時發生故障的概率。4.2.24獨立(審查和評估)沒有直接激勵并且沒有實質性間接激勵影響評審或評估過程結果的評估者或審核者(另請參見17.3.2)。評估符合UL4600的產品，元素，系統系統或其他與產品相關的范圍。注意：“項目”可能需要包括基礎架構，場外計算，場外數據存儲，開發流程，生命周期支持流程，供應鏈質量保證措施以及其他確保超出已部署產品本身邊界的安全性的方面。“項目”可以包括整個產品，也可以僅包括產品的一部分，但是無論如何都將包括項目中包含的部分產品的一致性所需的所有方面。4.2.26生命關鍵系統的一個方面，丟失事件可能會導致人員傷亡。2020年4月1日UL460019注意：嚴格來說，這是一個嚴重性概念。即使開發人員認為由于操作中不大可能發生相關風險較低，危害也可能是生命危險的。人身死亡，人身傷害，動物死亡，動物傷害，財產損失，環境損害或其他重大不利后果。注意：哪些損失被認為是不利的，取決于系統。然而，人的死亡和重大的人身傷害總是被認為是不利的損失。注意：安全案例可能會選擇將因項目失敗而導致的財務成本也視為“實質性不良后果”。注意：“損失事件”通常對應于FAA8056.但是，術語“損失”用于避免對責任和可預見性的任何先入之見。降低到可接受的風險水平。注意：可接受風險的級別取決于所減輕的特定風險的嚴重性(例如，對生命至關重要而不是對生命至關重要)及其對安全案例中確定的項目級別風險的貢獻。只要認為存在的風險低到可以接受的程度，而無需采取明顯的緩解措施，則可以將風險降低到可以接受的低水平?！熬徑狻币辉~等同于“可接受緩解”的概念。(請參閱“可接受的”定義。)除非采取緩解措施(如果有),并且已更新有關緩解的安全案例論據(“跟蹤至關閉”),否則不會認為風險已得到緩解?！翱山邮艿娘L險”是指已部分緩解(或沒有緩解)的風險(請參閱第5.5.1節)4.2.29非確定性注意：不確定性可能是由實時調度擾動，使用偽隨機算法或其他因素引起的。也可以看看：混亂的4.2.30運營設計領域(ODD)該項目旨在在其中運行的一組環境和情況。這不僅包括直接的環境條件和地理限制，而且還包括對該環境中將發生的一組對象，事件和其他條件的表征。項目ODD的托管部分。例：全天候ODD分為天氣，雨天和雪/冰的子集。注意：可以定義一個ODD子集來劃分操作空間以簡化設計任務，通過隨著時間的推移添加其他子集來支持分階段部署，或者管理復雜性。潛在的大變化ODD。安全案例可能會針對安全案例的某些方面獨立地爭論每個ODD子集。超越內置自測(BIST)功能來檢測潛在故障的測試。注意：過去，證明測試是指機械測試，例如壓力測試容器或移動的緊急閥，這些操作在正常系統運行期間無法完成。它們通常涉及行使故障安全措施，行使用于檢測故障的傳感器或進行離線測試。組件，材料，耗材，軟件和項目其他方面的背景，尤其是賦予區別或質量的背景。注意：在UL4600的上下文中，這是指確定COTS產品及其組件實際上提供了所需的功能，特別是不包括劣質產品，假冒產品和其他“未經批準”的部件。這不同于提供可接受功能和其他版本控制活動的零件的變體。供應鏈故障，其中組件供應商會通過逐漸使用替代材料，替代組件，設計變更和/或取消保護性組件而逐漸降低組件質量，同時顯然保持功能并滿足測試的參數值。損失事件發生的可能性和該損失事件的嚴重性的組合。注意：風險通常是概率和嚴重性的某種加權組合，可能對概率賦予零或非線性加權。此定義并不意味著排除替代的但可比較的風險表述。即使情況超出規格，仍可以繼續操作。例子：盡管收到不合規格的輸入，遇到ODD違規，遭受組件故障以及遇到機器學習訓練集中未表示的數據，系統仍會繼續正?；蚪导夁\行。注意：健壯性通常是程度的問題，而不是絕對的屬性。具有安全案例所定義的可接受的緩解后項目級風險。有證據支持的結構化論點，提供了令人信服，可理解和有效的證據，表明系統對于給定環境中的給定應用程序是安全的。4.2.39安全案例偏差2020年4月1日UL4600214.2.40安全相關4.2.41元素脫離上下文(EooC)4.2.42安全績效指標(SPI)注意：該術語類似于術語關鍵績效指標(KPI),但特定于該項目的安一般術語參考(資料性):和分類法”,IEEETrans。《可靠和安全的計算》,2004年1月至3月，第1(1)頁1-23。4.3縮寫和首字母縮略語(信息性的)a)Al:人工智能e)DAL:設計保證水平f)DTC:診斷故障碼h)EooC:元素脫離上下文j)FMVSS:聯邦機動車安全標準(美國)k)GNSS:全球導航衛星系統n)ISO:國際標準組織p)NDI:非開發項目t)SIL:安全完整性等級v)SPI:安全績效指標x)瑞典文：軟件工程知識體系y)V&V:驗證與確認V2V:車對車bb)V2X:車輛之間1)使用可接受的安全案例格式(請參閱第5.2節)3)提供可接受的證據(請參閱第5.4節)4)解決可接受的風險(請參閱第5.5節)5)闡述安全文化(請參見第5:6節_2020年4月1日UL460023例子：安全情況下總結了測試結果?？筛鶕筇峁┰敿毿畔⒑腿魏纹渌枋鲂宰C據。c)未進行記錄或未提供的所謂安全案例的任何方面在執行評估時均會被忽略。d)除非正在執行元素脫離上下文(EooC)評估，否則安全案例將涵蓋產品及其生命周期的所有與安全相關的方面，包括定制和現成的組件，軟件和子系統。具體包括但不限于：1)感測器2)執行器3)計算組件例子：計算硬件，操作系統，庫4)車輛平臺用作添加“自治套件”的基礎例：附加的自動駕駛項目工具包評估要求確保在安全案例中已解決與基礎商用車輛相關的安全問題。可以考慮對平臺進行以前的評估，但這可能會留下空白，除非將其專門用作自動駕駛汽車平臺評估為EooC。5)在線服務例：根據需要從云基礎架構向運營工具提供在線地圖服務器6)物流和維護支持7)假定的基礎設施支持e)沒有記錄和/或寫下來的，沒有應要求提供給評估者的所謂安全案例的任何方面，都不能用于支注意：評估員可以考慮口頭陳述和不屬于安全案例的其他材料，以幫助評估過程，但不能用作評估例：開發人員口頭解釋了為什么特定的“提示”提示元素不適用的原因，但是這種解釋不是在實際的安全案例中，也不在安全案例所引用的任何文檔中。即使評估者可能認為口頭解釋是合理的，但缺少關于該“需要”提示元素的安全案例偏差的書面解釋，也會導致發現不符合項。如果更新了安全案例，則可以糾正不符合項的發現，但這不是評估者的責任。例：測試人員口頭指出測試是針對正在部署的特定配置執行的。但是，實際測試過的配置文檔已丟失，無法合理確定地重建。在某種程度上，對于格式良好的安全案例而言，必須對所測試的配置進行記錄，評估人員必須由于缺少文件而發現不符合要求，并且可能必須重新運行測試。f)識別生命周期的任何初始部分，在此期間，安全論證無效例：該安全案例直到生命周期內首次進行公共道路測試時才適用。注意：這允許在完成原型開發和潛在的封閉式開發測試的同時完成安全案例。它無意允許在生命周期中任何時間對在公共道路上行駛的任何車輛提出符合性聲明。g)安全案例的變更管理強烈推薦-不適用推薦-不適用通過考慮分段一致性檢查來檢查一致性，包括在安全情況下可追溯地包括每個適用的提示元素。.1注意：編寫該標準是為了幫助構建格式正確的安全案例。將需要采取其他措施來確保操作安全。例如，最終產品標準可能不僅需要符合該標準，還需要符合涉及電氣安全，防火和被動乘員保護等主題的.2注意：該條款明確旨在要求一致性文檔包采用安全案例的形式。(即，除了行政事項以外，與評估本身有關的所有事情都是安全案例的一部分。)實際上，可能會使用各種文檔，存儲庫和工具來提供詳細信息，例如使單個工具或統一格式的數據集無法包含整個安全案例的證據。但是，評估要求能夠訪問任何此類材料以進行評估。.3注意：通常，本節對安全性論證的結構和內容提出要求。其他主要部分通常會在確定安全案參考：MISRA“汽車安全論點指南”,2019年。5.2安全箱樣式和格式5.2.1安全案例應針對索賠，論點和證據使用定義一致的格式。a)聲明和論點語法，語義以及所用任何圖形元素的定義注意：符號可能沒有正式定義的語義。但是，應提供有關安全案例表示法和方法的最佳可用信息，以促進在開發人員團隊和評估人員之間盡可能統一的解釋。b)定義證據類型，格式，數據字典和使用的模式c)評估人員訪問完整的安全案例2020年4月1日UL4600251)評估者無法獲得的安全案例的要素不依賴于一致性評估。a)遵守安全案例中定義的格式b)評估者可以訪問任何與了解安全情況有關的可用瀏覽，搜索，報告和分析工具注意：實際上，開發人員和自審計人員可能會使用工具和其他支持，以使其更容易處理安全案例。這些相同的工具和其他支持可根據要求提供。c)確定有關論證歸納要素完整性的推理方法強烈推薦：a)使用既定手段以高度結構化的方式組織安全案例，例如：1)OMG結構化保證案例元模型(SACM)2)目標結構表示法(GSN)3)索賠論點證據(CAE)b)使用工具支持來輔助安全案例理解和導航a)將圖形界面用于安全案例導航的相關部分，以提高導航性b)使用基于結構化文本的符號，而不是自由格式的文本，從而增加了提供工具支持的能力通過檢查安全性論據，證據和設計記錄來檢查是否合格。.1注意：關于條款中的“一致”一詞，允許層次結構參數的不同分支在原因范圍內使用替代參數格式，尤其是當參數適用于明顯不同的功能或子系統時。由于論證結構的原始來源不同或需要使用更適合特定論證技術挑戰的技術，因此替代方案可能有意義。如果使用了多個樣式，則適用于參數的每個部分的樣式都對應一個明確指定的樣式。5.2.2所使用的證據應符合已定義的可審核格式。強制性的：a)安全案例中使用的一組定義好的類型中每個證據的定義類型例子：模擬輸出文件，測試計劃，車輛數據日志注意：“類型”是指靈活的通用含義。但是，每組證據屬于已定義的類型(即使每組證據都是不同于所有其他證據集的唯一類型)。然后，根據下一個提示元素，將該類型與允許解釋證據的元數據b)每種證據的定義格式，至少包括：1)語法和語義，數據字段，元數據字段的定義注意：在給定證據類型和性質的前提下，將語義定義為實用。2)規范證據的一致性，正確性和完整性，以使證據可審核3)驗證不是來自可接受數據的任何證據的確定方法例：可以通過整個項目生命周期中的數據收集來驗證主觀專家的判斷。例：專家認為雷擊很少發生，以至于沒有相關性，因此可以作為忽略雷擊風險減輕的證據，理由是有論點認為會記錄部署車輛上發生的任何雷擊，并將進行定期分析以檢測雷擊是否發生。現場數據中的頻率變得過于頻繁而無法忽略。(應注意的是，有據可查的是，閃電確實確實會偶爾襲擊移動中的，占用的車輛，并且更合適的安全論據可能是采取某種形式的風險緩解措施來確保緩解后的風險是可以接受的。)必填-不適用強烈推薦-不適用a)用于解釋每種類型證據的描述性或教程示例b)避免將自由文本作為證據的數據類型通過檢查安全性論據，證據和設計記錄來檢查是否合格。.1注意：該條款允許每個證據具有不同的定義類型。在可行的情況下，使用少量一致類型的證據有助于簡化安全案例，以提高可理解性。a)正確使用自然語言b)在主張和論點中使用一種自然語言注意：目的是在整個安全案例中使用的任何自然語言(除證據外)都應使用一種適合項目設計團隊使用的自然語言。證據可以2020年4月1日UL460027例子：使用以下短語檢測并進行護理：“基本上是所有”,“應該是”,“通常”例子：“沒什么不同","可能不會發生安全的結果”推薦-不適用通過檢查安全性論據，證據和設計記錄來檢查是否合格。5.3主張和論據充分5.3.1安全案例聲明應涵蓋所有已識別的與安全相關的危害和風險。a)以論據主張的形式定義項目安全要求1)預期功能的安全要求2)潛在意外功能的安全要求例：處于禁用維護狀態時，通過調度請求響應進行的車輛移動是意外的3)必須避免的不安全行為和狀態的安全要求注意：為了功能安全，通常通過危害分析來執行此操作4)緩解項目本身的故障(包括設計故障和操作故障)的安全要求5)緩解故障，異常和未指定環境條件的安全要求6)生命周期考慮因素的安全要求，包括更新，檢查，維護和監視不斷變化的操作環境b)將每個已識別的危害映射為可能違反至少一項相關安全要求c)確定每種已識別危害的可接受安全水平必填-不適用a)排除與已確定的危害和風險無關的索賠注意：這是向后追溯的要求，以避免與商品安全無關的索賠。注意：對于EooC安全案例，可以接受以下假設：將安全案例片段跟蹤到導出的EooC邊界接口，前提是至少EooC的某些用戶將具有更高級別的項目安全案例，從而可以完成對已識別危害和風險的跟蹤關系。通過檢查安全性論據，證據和設計記錄來檢查是否合格。2020年4月1日UL46002.1注意：本條款中使用的術語“權利要求”是通用術語，包括子權利要求。5.3.2安全案例論據應支持所有已確定的主張。a)通過可接受的論據支持安全案例索賠b)確定用于確定論證充分性的標準a)在論證中使用認知失敗者注意：其他條款中的許多提示要素是認識上的失敗者。另外，對每個自變量子樹的審查可以包括關于任何其他認知失敗者是否適用的考慮。b)陷阱：在沒有具體描述合格性評估的局限性的情況下，將其視為對安全性標準的認可就容易導致對安全屬性的過度評價。(")注意：實際上，這是一個論點缺口，不支持所確定的主張。另請參閱第5.7節。c)陷阱：遵守為人類操作設備設計的安全標準的信譽容易導致隱含在自主性上的故障管理控制義注意：這是前面的陷阱所涉及到的安全評估例：在評估ISO26262符合性時，對自駕車的可控制性給予了認可，這對自主功能施加了相應的可控制性義務，以行使相同級別的控制。如果不解決這一陷阱，可能會錯過為人類提供替代品以提供作為ISO26262ASIL分配的一部分而假定的可控性的需要。a)避免包含不支持已確定主張的論點b)避免包括不支持論點的證據通過檢查安全性論據，證據和設計記錄來檢查是否合格。.1參考：(*)有關陷阱的一般信息：Koopman,P.,Kane,A.&Black,J.,“可信自主安全論點”,“安全關鍵系統研討會”,英國布里斯托爾，2019年2月。5.3.3安全案例應避免爭論的缺陷。強制性的：a)確定候選人相關的邏輯謬誤注意：這導致在安全情況下要避免邏輯錯誤的清單。b)確定候選人相關的修辭手法a)避免發現邏輯上的謬誤b)避免使用確定的修辭手法c)陷阱：為在不同的操作環境或不同的目的中使用的經過驗證的使用過的技術而信譽，很容易使1)該陷阱具體包括COTS,舊版和EooC組件，包括硬件和/或軟件(注意：見13.4節)2)該陷阱專門包括可能與組件相關的項目操作參數的更改例：Lions,J.L.,阿麗亞娜5航班501失靈，咨詢委員會的報告，1996年d)陷阱：由于沒有以前的故障，所以在現場工程反饋中減少故障的可能性很容易歸因于折減多個故障，這些故障如果被視為一組，則實質上證明了安全案例的無效性。(*)e)陷阱：爭論基于人為操作項的數據進行的自主故障分析很容易1)由操作情況觸發的故障，自治項目可能會進入，操作員通常會避免2)自主項目故障可能觸發的非人為錯誤的典型故障f)陷阱：基于事件(“意外”或其他潛在故障)的到達率，通過分析操作數據和/或測試數據來減輕1)忽略了不同類型根本原因的均值分布的其他復合因素示例：項目失敗的不同類型觸發事件的平均到達率的重尾分布2)忽略偶發但不可避免的常見原因事件的潛在影響g)陷阱：基于人為設計的測試計劃爭論測試范圍很容易忽略適用于自主功能的邊緣情況，但操作員h)陷阱：根據形式方法的使用來論證項目的正確性，很容易忽略證據所依據的基本假設中的任何無UL4600強烈推薦-不適用推薦-不適用點”,“安全關鍵系統研討會”,英國布里斯托爾，2019年2月。強烈推薦-不適用推薦-不適用點”,“安全關鍵系統研討會”,英國布里斯托爾，2019年2月。必填-不適用2)分析數據3)程序定義推薦-不適用2020年4月1日UL460033.2注意：參數結構可能包含子參數和其他支持信息。但是，每個論點分支最終都可以追溯到支持證據的至少一個要素，該要素在范圍上可以廣泛接受以支持提出的權利要求。證據不直接或間接(通過子參數)不支持的參數無效。5.4.2論點應包括證據的有效性。a)安全案例記錄基于數據收集的實驗設計或其他數據收集策略以作為證據b)確定用于確定證據充分性的標準c)爭論證據足以得出可接受的安全案例1)描述使用證據來支持或反駁論點和/或主張的有效性的方式。2)關于減輕確認偏見風險的爭論a)完全或部分基于以下任何證據對生命周期進行監控：1)沒有專家或主觀意見的支持2)數據不支持且書面公共標準文件，公共指導文件或類似引用的源不支持的現有實踐3)假設條件注意：生命周期監視用于監視風險，使其達到論點依賴于觀點，假設或潛在的弱證據的程度。b)確定認知上的失敗者以及伴隨的可廢除性論據，至少包括：1)可能混淆實驗變量2)數據中的潛在偏差3)數據樣本數量可能不足a)包括反證和附帶的論點b)包括與證據創建相關的流程合規性論證c)證據的生命周期監控基于基于共識的公共標準方法a)使用對抗性順序測試設計方法來最大化識別ODD內的故障模式和/或緊急行為的機會通過檢查安全論據，證據，證據收集設計和設計記錄來檢查是否合格。.1注意：實際上，該子句可能導致以下形式的參數結構：參數是有效的，因為(1)有證據支持，并且(2)證據本身是有效的。有效證據至少由客觀事實數據支持。.2注意：有效地收集了潛在的認知失敗者和可能收證更有可能相關。選擇指南由本標準中的提示元素提供，并由開發人員的經驗提供補充信息。.3注意：不受支持的專家意見包括領域專家的陳述，但未得到所提供證據的實質性支持。只要基于該基礎作為證據的一部分，并且明確主張所引用作品的實驗性上下文適用于其在文獻中的使用，就可以認為直接基于學術論文，實質性數據等得出的觀點在此意義上是受支持的。安全案例。5.4.3證據有效性的支持應涵蓋該項目難以復制的方面。a)根據證據確定項目的任何不確定性和混亂方面(如果沒有，則說明)a)減輕因項目及其操作環境的不確定性而導致的無效風險的論點和證據(如果沒有，請陳述)例：使用并發管理機制來緩解對時間敏感的并發訪問錯誤，使用種子化的偽隨機數生成器來重現故意的不確定性行為，以測試可重復性。例：故障注入曾經使元件失效，否則在測試期間該元件很少會失效。b)減輕因物品及其操作環境混亂而導致的無效風險的論據和證據(如果沒有，則說明)例：當項目行為基于較小的輸入差異而發生顯著變化時，測試可重個具體示例是，當障礙物正好出現在前方時，車輛是向左還是向右轉向。c)所使用的任何度量均符合與SPI度量有關的特征(請參見第16節)。a)統計意義方法的使用推薦的：2020年4月1日UL460035a)使用數字雙胞胎或類似技術通過檢查安全性論據，證據和設計記錄來檢查是否合格。.1注意：非確定性意味著在相同的初始條件下(例如，由于使用了偽隨機算法),商品可以以不同的方式表現?；煦缫馕吨捎诔跏紬l件下的擾動，該項目可以以不同的方式表現，而初始條件的擾動小于驗證方法的控制能力。例如，不確定性和混亂性都會導致對測試的響應不同，但都是由不同的來源引起的。一個項目可以是不確定的，也可以是混亂的。如果確認存在任何一種原因，則不必區分這些原因，但是在確定證據的有效性時必須考慮兩種可能性的緩解。如果由于特定測試運行中有利的系統行為而偶然通過了測試，則不確定性和混亂行為會破壞測試結果的有效性和完整性。5.5.1應確定可接受的風險。a)確定未完全緩解的任何風險的接受標準。a)將未完全緩解到可接受水平的任何風險識別為“可接受風險”。這些包括但不限于：1)未采取緩解措施的風險例：被確定為極不可能或不可能在“現實世界”中發生的項目級安全評估潛在危害是可接受的風險，并作為未緩解的風險包含在安全案例中。2)部分緩解的風險(即未降低到完全可接受水平的風險)3)未知風險例子：“未知的未知數”,“未知的未知數”4)緩解風險的依據是不受支持的專家意見，假設或其他不盡人意的證據，并且也與標準文件等公認的行業慣例不符b)對于未完全緩解的風險(包括可接受的風險),可以描述緩解水平，并認為在項目安全案例中，緩解水平(如果有)是可以接受的。1)包括對整個項目生命周期中每種此類風險的預期結果的評估。強烈推薦：a)緩解后的風險級別表征，可以認為已完全緩解。推薦-不適用通過檢查安全性論據，證據和設計記錄來檢查是否合格。.1注意：這包括對任何剩余的未知風險的接受，如果有信息可以支持，則應將其細分為幾類(例如“已知未知數”)。可以理解，這些風險可能無法輕易量化，但是在做出部署決策時，這些風險已被接受。5.5.2應通過現場工程反饋在項目生命周期中跟蹤可接受的風險強制性-不適用a)針對可接受風險的現場工程反饋，以確保實踐中的風險小于或等于作為項目操作的預期結果陳述的風險水平b)現場工程反饋明確考慮了由于風險分析方面的差距而產生的風險a)自動收集事故和損失事件的現場數據，以確定每個風險的可接受風險結果是否在預期范圍內符合性：通過檢查安全性論據，證據和設計記錄來檢查是否合格。.1注意：一種示例方法是在安全案例中包括“未知風險”,將其稱為“已接受風險”,說明為什么已執行可接受風險分析以允許接受由此產生的風險，并辯稱根本原因分析程序明確包括識別新風險以便在野外遇到時及時將它們添加到安全案例中。5.6安全文化5.6.1必須確定開發，供應鏈，維護和運營的安全文化在風險識別和緩解中的作用。a)安全文