摘要：现行汽车安全标准为如何规避不合理风险提供了隐性指导，但制造商需为自动驾驶系统（SAE 3级及以上）制定风险接受准则。然而，自动驾驶系统的“不合理”风险水平尚未得到精准定义。仅将现行安全标准应用于这类新型系统，可能无法使其获得社会认可。由于现有汽车标准中风险管理依托于安全措施的隐性知识，要与风险接受准则实现显性匹配存在较大挑战。因此，本文提出一种风险显性化表示与管理的方法，将其命名为风险管理核心（Risk Management Core, RMC）。该流程框架的提出基于从现行安全标准中提取的需求，并通过示例场景将其应用于自动驾驶系统安全行为规范的制定任务中。
原文作者：NAYEL FABIAN SALEM，THOMAS KIRSCHBAUM，MARCUS NOLTE，CHRISTIAN LALITSCH-SCHNEIDER，ROBERT GRAUBOHM，JAN REICH，MARKUS MAURE
原文标题：Risk Management Core—Toward an Explicit Representation of Risk in Automated Driving
编译：猿东东，猿西西
根据欧盟实施条例（EU）2022/1426，“自动驾驶系统制造商应制定接受准则，自动驾驶系统的验证目标由该准则推导而来，以评估其设计运行域（ODD）内的残余风险……”。然而，现行汽车安全标准（如ISO 26262和ISO 21448）仅在道路车辆安全生命周期中，为如何满足风险接受准则提供了隐性指导。这些领域专用标准将基础安全标准IEC 61508的指导原则应用于汽车领域。IEC 61508明确规定了风险管理活动，旨在将目标系统的残余风险降低至合理水平，而ISO 26262仅制定了一系列措施，默认这些措施能充分降低系统（或产品）的风险，却未对其进行显性说明。
对于传统车辆和配备驾驶辅助系统的车辆（SAE 2级及以下），遵循最佳实践已使其风险水平获得普遍认可，因为这类系统的合理风险水平，或至少实现该水平的适当措施是业内默认知晓的：只要驾驶辅助系统可由驾驶员接管，或仅在人类驾驶员无法控制的场景下介入，人类驾驶员完成动态驾驶任务的能力即可直接作为风险可接受性的参考依据。但对于自动驾驶系统（SAE 3级及以上），其合理风险水平尚未明确，业内也未就实现该风险水平的适当措施形成共识。自动驾驶车辆的风险管理面临多重挑战，具体包括：
C1：制定有效的风险接受准则；
C2：分析自动驾驶车辆引入的风险；
C3：制定措施，使自动驾驶车辆的实际风险与既定风险接受准则相匹配；
C4：在开放交通环境中验证既定措施（包括部署前和部署后）；
C5：与所有相关利益相关方（如型式批准机构）沟通风险管理工作。
风险接受准则的分析与制定（C1）涉及社会层面的协商，超出了本文的研究范围。本文提出的框架旨在通过支持自动驾驶车辆风险分析（C2）和风险降低措施制定（C3），助力风险的显性化管理。我们将该框架命名为风险管理核心（RMC），因其阐述了风险管理的通用方法，且可应用于安全生命周期中的多项活动。该框架旨在使自动驾驶车辆引入的风险（包括前瞻性风险和回顾性风险）与既定风险接受准则保持一致。而所需风险降低措施的验证及双向沟通（C4和C5），将作为未来的研究方向。
本文通过以下方式解决挑战C2和C3：
· 从现有安全标准中提取风险管理框架的需求（第三部分）；
· 提出一种本体论，涵盖风险管理所需的专业术语（第四部分）；
· 阐述风险管理核心这一流程框架（第五部分）；
· 将风险管理核心应用于自动驾驶系统安全行为规范这一新任务（第六部分）。
研究结果也为向公众传达自动驾驶系统的安全水平这一挑战提供了解决思路。“安全” 是一个缺乏统一定义的术语，不同利益相关方对其理解差异显著。与自动驾驶相关的汽车安全标准和报告（如ISO 26262、ISO 21448和ISO/TR 4804）均将安全定义为“不存在不合理风险”。尽管该定义及相关指导原则明确聚焦于人身伤害风险，但部分利益相关方在判定合理风险水平时，还会考虑财产损失等其他因素。因此，如何向多方利益相关方论证系统的安全性成为一大难题，尤其是在缺乏定义合理风险水平的有效风险接受准则的背景下。
因此，本文认为，风险的显性化表示有助于使实际风险与各类风险接受准则相匹配，而这些准则需以社会可接受的方式为自动驾驶系统制定。这样一来，制造商可在自动驾驶车辆的整个安全生命周期中处理和管理风险。风险管理活动的显性化记录虽无法实现利益相关方对“安全”和“风险”术语的统一理解，但能促进不同利益相关方之间的透明沟通。
风险管理在概念构建和实际应用中面临的挑战并非自动驾驶领域独有。Fischhoff指出：“每年（甚至每天），都会有新的行业或机构发现自身也面临风险问题”。他认为，暴露风险冲突对于开展有效的风险管理（和风险沟通）至关重要。
从自动驾驶的伦理视角来看，Godall提出，历史上学界多以“电车难题”为切入点探讨合理风险水平。尽管这类人工构建的极端案例具有一定参考价值，但戈达尔指出，风险管理在评估不同行为时具有透明性和可调整性等优势。与“电车难题”的分析思路不同，基于风险的方法不仅能揭示特定场景下的规则冲突，还能为风险应对提供具体行动建议，从而实现更精细化的决策，这与人类驾驶员的行为模式更为接近。本文认同Fischhoff和Godall的观点，并据此提出在自动驾驶领域实现风险显性化表示的方法。
现行汽车安全标准为风险管理提供了指导，但遵循标准并不意味着能自动规避不合理风险，对于在复杂环境中运行的自动驾驶系统而言，这一问题尤为突出。Fowler探讨了交通领域安全标准的缺陷，重点分析了其与基础标准 ISO/IEC 61508 [4] 的合规性问题。在风险管理层面，这意味着这些标准更关注安全相关系统的可靠性，而非风险降低能力。因此，本文不仅参考ISO 26262和ISO 21448，还将验证所提方法与ISO/IEC 61508、ISO Guide 51等基础标准的合规性。
本文研究过程中参考的其他文献，均聚焦于风险管理的特定方面，未提供整体视角。例如，现有文献对风险管理的贡献主要体现在以下方面：
· 探讨风险可接受水平的确定方法；
· 提出风险分析方法；
· 聚焦于既定风险水平的验证与确认；
· 提出运行时维持既定风险水平的方法。
然而，据笔者所知，目前尚无已发表的研究提出聚焦于风险显性化表示、且能论证其与汽车及非汽车安全标准合规性的自动驾驶风险管理框架。
前文指出，自动驾驶系统需要一套支持风险显性化表示的框架。因此，本部分将从现有安全标准中提取此类框架的需求。需要说明的是，这些需求并非穷尽性的，因本文未涵盖所有与风险管理相关的国际标准，而是以部分代表性标准为基础，提出通用的风险管理流程框架。
在汽车领域，ISO 26262是ISO 21448、ANSI/UL 4600等其他安全标准的重要参考依据。ISO 26262为通过隐性风险管理实现功能安全提供了框架：首先，该标准未制定明确的风险接受准则；其次，为论证系统的功能安全性，企业需开展危害分析和风险评估，而后将已识别的潜在风险降低至合理水平，但同样未量化既定措施对实现“合理”风险水平所需的风险降低贡献。
ISO 26262中风险管理的隐性特征，在危害事件分析参数和安全目标定义中体现得更为明显。危害事件需根据潜在伤害的严重程度（S）、运行场景的暴露概率（E）以及驾驶员或相关人员对危害事件的可控性（C）进行分级。基于分级结果，企业需制定安全目标，并为其分配相应的汽车安全完整性等级（ASIL）。该等级由安全目标所针对的危害事件分级结果决定。尽管ISO 26262明确规定了组织和过程要求，以及与硬件相关的度量指标（涉及安全目标和安全需求的完整性等级），但既未明确制定ASIL所依据的风险接受准则，也未规定需实现的量化风险降低目标。因此，该标准未明确说明实施特定的ASIL相关措施如何实现不合理风险的规避，这一问题留待标准使用者自行解读，具有明显的隐性特征。
Fowler指出，交通领域（重点为铁路和空中交通管理）的安全标准在符合IEC 61508方面存在不足，并阐述了针对安全关键系统可靠性的工程实践，与针对其风险降低能力的工程实践之间的区别。
由于ISO 26262是汽车领域的核心安全标准，本文将分析其在功能安全保障中的风险管理活动，重点研究其第一部分（术语）和第三部分（概念阶段），因这两部分定义并阐述了风险管理指导原则。随后，本文将从IEC 61508中提取需求，以解决其在汽车领域应用于显性风险管理时存在的不足。
ISO 26262的适用范围在第一部分中界定，该标准针对由安全相关电气/电子（E/E）系统故障行为引发的潜在危害。尽管其适用范围排除了部分危害成因（如由预期行为引发的危害），但未限制风险降低措施的制定范围。第三部分第6条（危害分析和风险评估）和第7条（功能安全概念）为解决挑战C2（风险分析）和C3（制定应对措施）提供了指导。
首先，本文将ISO 26262中制定的目标转化为自动驾驶场景下风险管理框架的需求。
需求1：需识别危害事件。
ISO 26262-1将危害事件定义为危害与运行场景的结合。从功能安全的角度来看，故障行为（即由硬件或软件故障引发的系统失效或非预期行为可能导致危害（即潜在的伤害源），而危害则在目标系统的运行场景中显现。因此，识别车辆行为偏差和潜在危害事件（需求1），是ISO 26262框架下将风险降低至合理水平的基础。
需求2：需基于伤害发生的概率和严重程度，评估危害事件的风险。
通过对ISO 26262的进一步分析，可将需求2细化。该标准将风险定义为“伤害发生的概率与严重程度的结合”，据此本文提取需求3至需求5。
需求3：需识别危害事件可能造成的伤害。
需求4：需评估危害事件可能造成的伤害严重程度。
需求5：需评估危害事件可能造成的伤害发生概率。
在ISO 26262中，风险评估（包括伤害发生概率和严重程度的估算）是隐性进行的：通过估算严重程度、暴露概率和可控性参数对危害事件进行分级，基于分级结果确定ASIL等级。ASIL等级规定了为规避不合理风险，需遵循的ISO 26262需求和采取的安全措施。
此处需再次参考Fowler的研究，其指出IEC 61508中明确区分了安全完整性和风险降低的概念：为降低目标系统（即被控设备，EUC）的固有风险，需采取相应措施，这些措施可通过系统的安全功能实现；完整性被定义为“安全相关系统在规定条件下、规定时间内，圆满完成既定安全功能的概率”，因此，完整性对既定安全功能的风险降低效果存在负面影响。
与之相反，ISO 26262将风险降低和完整性整合到ASIL等级确定及后续的安全目标制定过程中。尽管该方法在现有驾驶辅助系统中应用成熟，但为应对自动驾驶这一新技术带来的挑战，本文将ISO 26262中的需求进一步拆解，从IEC 61508中提取需求6至需求8。
需求6：需制定安全措施，使风险降至可接受水平（即达到所需的安全水平）。
需求7：需评估既定安全措施实现的风险降低效果。
需求8：需评估既定安全相关功能在规定条件下、规定时间内圆满完成的概率（即其安全完整性）。
尽管IEC 61508第五部分附录A为资料性附录，不包含规范性需求，但其中明确提出了制定风险接受准则的必要性（需求9）。在汽车领域，ISO 21448 [第6.1条]也以规范性条款的形式作出了相同规定。
需求9：需通过为目标系统、面临风险的人员/财产/环境制定风险接受准则，明确所需的安全水平（即合理的风险水平），并遵守目标市场的社会道德准则。
这些基于IEC 61508的通用需求，涵盖了ISO 26262 [第三部分]中提及的大部分目标。ISO 26262新增的一个特定概念是安全目标（需求10），其被定义为顶层安全需求，旨在将风险降低至合理水平，同时包含必要的完整性要求。需说明的是，尽管ISO 26262仅聚焦于功能安全，本文将对安全目标的概念进行更广泛的应用。
需求10：需制定包含相应完整性要求的安全目标，以预防或缓解危害事件，规避不合理风险。
本文对ISO 21448的分析未提取出与风险表示相关的新需求。与功能安全不同，预期功能安全（SOTIF）要求考虑规范和性能缺陷，这是自动驾驶风险管理中需拓展的重要适用范围。但在风险评估方面，ISO 21448 [第6.4条] 主要参考ISO 26262。
ANSI/UL 4600 [第6条]明确涵盖了风险评估内容，其使用的术语与IEC 61508有所不同，但表达的概念相似，例如“事件发生的计算概率可得出整个因果链的概率和置信度”[第 6.1.1.3b条]。IEC 61508中的安全功能需求和安全完整性需求，恰好对应这两个方面：整个因果链的概率和置信度。
前文提取的需求主要针对导致危害事件的危险行为，而 ANSI/UL 4600（及ISO 26262）还要求识别并记录危害（需求11）。危害日志的编制（需求12）也为 ISO/IEC/IEEE 16085 [第6条]所要求的生命周期监控和风险管理提供了支持。
需求11：需识别潜在相关危害 [第6.3.1条]。
需求12：需建立危害日志，记录已识别的危害及其缓解状态。
本文发现，另一项与风险管理框架高度相关的规范性需求来源是ISO/IEC Guide 51。该标准为制定包含安全相关内容的标准提供了指导原则，前文列出的大部分需求均可从该标准中提取。此外，该标准还隐含了一项与风险评估活动相关的需求（需求13），此前的需求虽未明确提及，但已间接涵盖。
需求13：需开展风险评估，确定将目标系统的初始风险降低至可接受水平所需的风险降低幅度。
基于前文提取的自动驾驶场景下风险管理框架的需求，本文设计了一种本体论，旨在整合所分析标准中使用的术语。该本体论为风险管理相关概念的描述提供了方法，有助于实现自动驾驶风险的显性化表示。
根据ISO 31000中对风险管理活动的划分，本文将分两步阐述所需术语：
风险评估（图1）；
风险处置（图2）。
图1：风险评估本体论。该本体论界定了用于描述风险分析和风险评价相关活动的各类概念及其相互关联。依据 ISO Guide 51 的定义，风险分析包含危害识别与风险估算两大环节；风险评价则聚焦于将目标系统的评估残余风险与可接受风险水平进行对比分析
图2：风险处置本体论。依据ISO 31000的定义，风险处置是继风险评价之后开展的管理活动。风险处置的核心目的是“选定并实施各类风险应对措施”。在自动驾驶的应用场景中，本文纳入了ISO 26262中的相关术语，如安全目标、安全要求等。图中黄色标注为风险接受准则相关概念，蓝色标注为风险降低相关概念，紫色标注为安全完整性相关概念
4.1 风险评估本体论
本文提出风险管理核心的初衷之一，是为论证自动驾驶系统不存在不合理风险提供支持，这需要将实际风险与可接受风险进行显性匹配。因此，本文首先参考图1 中的风险概念。ISO Guide 51将风险定义为“伤害发生的概率与严重程度的结合”，因此风险取决于伤害的严重程度和发生概率。
在伤害概念方面，现有（汽车）安全标准均指人身伤害，但利益相关方对相关伤害的解读可能存在差异。本文认为，无需在风险管理核心的通用概念中对伤害概念进行具体化，保留其灵活性可更好地应对不同利益相关方对风险概念的不同解读。
用于量化风险的伤害发生概率和严重程度，均由伤害可能发生的具体场景决定。本文参考Ulbrich等人的定义（该定义已被ISO 21448采纳），将场景的时间发展过程称为场景（scenario）。ISO 21448中提出的危害事件模型进一步定义：在场景中可能导致伤害的事件为危害事件（hazardous event）。因此，可通过所有已知（危害）场景的数量，估算目标系统的固有风险。
要识别危害事件，需先明确潜在的伤害源，这些伤害源被定义为危害（hazard）。因此，危害事件是危害在特定场景中的具体体现，其特征是人员、财产或环境面临一种或多种危害。
该术语与汽车功能安全领域的使用存在细微差异：ISO 26262将危害事件定义为发生在运行场景中的事件。本文认为该差异可忽略不计，因为在危害分析和风险评估活动中，“运行场景”和“场景”的概念使用方式相似（参见 [第一部分，3.104]）。
ISO 31000将风险更广泛地定义为“不确定性对目标的影响”，而目标由主体提出，因此本文在本体论中引入**主体（agent）**概念，即受潜在伤害源（危害）威胁的对象。与ISO 31000主要关注组织目标受不确定性影响不同，本文结合ISO 26262和ISO 21448的适用范围，将其限定于自动驾驶领域。尽管组织也可被视为主体，但本文将其解读为公共道路交通中的个体，以契合研究范围。
ISO 26262 [第三部分，第6.4.2.3条] 规定，需在车辆层面识别危害。因此，本文提出的本体论明确：目标系统实现主体（即行驶在交通中的车辆）的功能，主体在特定用例中行动，同时也是风险管理活动的对象，其表现出既定的目标行为。
因此，系统边界的界定并非必须以主体为依据，例如，其可涵盖包含自动驾驶车辆的代客泊车系统及停车场内的辅助系统。该术语也适用于自动驾驶电动汽车子系统（如感知系统）的风险管理。为区分作为潜在伤害源的危害，与在特定场景中发生的危害事件，本文对**用例（use case）和场景（scenario**进行了区分：根据ISO 21448的定义，用例包含一系列场景。因此，主体在场景中扮演特定角色，同时在相应的用例中行动。
本文还可基于其他标准补充术语，例如欧盟快速预警系统（RAPEX），其指导原则由欧盟委员会2009年12月16日发布的2010/15/EU号决定制定，并由2018年11月8日发布的欧盟实施决定（EU）2019/417替代。RAPEX建议使用**危险（danger）**概念支持风险评估，但未对其作出明确定义。根据本文分析，该概念与危害、伤害、危害事件的概念存在冗余，因此未将其纳入本体论，尽管该术语在其他应用中可能具有价值。德国联邦议院的一份专项报告强调，在法律和工程等多个领域，区分危险和危害等概念存在较大难度。
前文阐述的所有概念，均可归属于**风险分析（risk analysis）活动，ISO 31000将其定义为“系统地利用现有信息识别危害并估算风险的过程”。此外，本文在本体论中纳入了风险评估（risk evaluation）**相关概念，ISO 31000将其定义为“基于风险分析，判定风险是否超出可容忍水平的过程”。
基于从IEC 61508和ISO 21448中提取的需求9，自动驾驶场景下的风险管理框架需包含风险接受准则（risk acceptance criteria）。该准则定义了不合理风险的阈值，即一个具体的风险水平。ISO Guide 51将该风险水平称为可容忍风险（tolerable risk），而非可接受风险。因此，在本文的风险管理术语中，“可接受的”、“可容忍的”和“合理的”为同义词。Favarò详细探讨了基于正风险平衡等接受准则定义不合理风险所面临的挑战。
ISO Guide 51指出，“产品或系统必然存在一定水平的固有风险”，这一点对于在开放交通环境中运行的自动驾驶系统（SAE 3级及以上）尤为重要。因此，即使目标系统表现出既定的目标行为，也仍存在固有风险。该行为（为在场景中扮演特定角色的主体所制定）是残余风险的一个潜在来源。残余风险是一个具体的风险水平，若要判定目标系统是安全的，其残余风险必须低于可接受风险水平。
4.2 风险处置本体论
要缩小目标系统固有残余风险与相应可接受风险水平之间的差距，需实现既定的风险降低幅度（risk reduction）（参见图2）。所需的风险降低幅度决定了安全措施的实施程度，这些措施通过降低伤害的严重程度和/或发生概率，满足风险接受准则。
基于需求8，安全措施的实施程度还由特定的**完整性（integrity）**决定：所需的风险降低幅度取决于不合理风险水平，而完整性则取决于未采取安全措施时目标系统的初始风险。ISO/IEC 61508 将完整性（参见图4）定义为“电气/电子/可编程电子安全相关系统在规定条件下、规定时间内，圆满完成既定安全功能的概率”。
图3：风险管理核心框架。风险管理核心是一套用于实现实际风险与可接受风险匹配的迭代式过程框架，该框架由风险分析、风险评价和风险处置三大环节构成
图4：风险降低构成要素示意图。Fowler以一维图形的形式，直观呈现了IEC 61508标准中针对被控设备（EUC）界定的风险降低各构成要素。其中R(L)代表由损失型失效引发的风险，R(C)代表由安全功能的异常失效行为引发的风险
根据需求6，需制定满足风险接受准则的安全措施。显性制定措施并明确其对整体风险降低的贡献，是实现风险显性化表示的关键步骤。与之相反，ISO 26262仅基于ASIL分级制定措施，默认这些措施能依托隐性知识将风险降低至合理水平。
此外，本文沿用ISO 26262中的**安全目标（safety goal）**概念，即安全目标的制定需以危害和危害事件为依据，是顶层安全需求，同时包含必要的风险降低幅度和完整性要求。最终，由于目标系统的目标行为是残余风险的来源，其不得违反安全目标。
在阐述了风险管理显性化所需的基本概念及其相互关系后，本文提出**风险管理核心（RMC**作为自动驾驶风险管理的流程框架。该框架旨在以迭代方式实现实际风险与可接受风险的匹配。
由于风险管理需在不同系统层级（如运行层、功能层、技术层）及产品和组织的全生命周期中开展，本文并非声称该流程框架适用于所有场景，而是基于第三部分提取的规范性需求，提出适用于自动驾驶场景的风险管理核心框架。本部分将阐述该框架的核心活动和产物（图3），下一部分将其应用于自动驾驶车辆安全行为规范的制定任务中。
使用风险管理核心的前提是掌握危害源的基本信息，这些信息可通过分析事故数据库或专家分析等方式获取。危害源是识别潜在伤害源（危害）的必要条件。此外，为实现实际风险与可接受风险的匹配，需制定适用于自动驾驶系统既定设计运行环境的风险接受准则，该准则代表了不合理风险的阈值。最后，还需具备场景目录，以对系统的实际风险进行管理。
本文不讨论因上述输入存在缺陷而产生的风险，例如场景目录不完整、危害源知识缺失等。但需说明的是，风险的系统化管理和显性化表示，有助于识别规范和性能缺陷。此外，通过采取预防措施并利用现场信息，可将风险管理活动与生命周期过程相整合，为其提供支持。
总体而言，风险管理核心由三部分组成，每一部分均与ISO Guide 51中描述的流程一致：第一，风险分析，包含危害分析和风险估算步骤；第二，风险评估，通过对比实际风险与可接受风险实现；风险分析和风险评估共同构成**风险评价（risk assessment）**活动；第三，风险处置，旨在解决风险评估中发现的风险差距。
ISO 31000还定义了在社会技术环境中开展风险管理所需的其他活动，将沟通与咨询、监控与评审列为独立任务。这些任务在考虑生命周期风险管理时，重要性愈发凸显。但本文的研究重点为风险分析、风险评估和风险处置。
5.1 风险分析
风险管理核心的总体目标是迭代实现实际风险与可接受风险的匹配，因此流程始于对目标系统风险的分析。与ISO 31000不同，本文将**风险识别（risk identification）**归为风险分析的一部分，该结构得到了ISO Guide 51的支持。
因此，风险分析步骤始于对危害源的分析。根据第四部分的定义，危害是在特定用例中对主体构成威胁的潜在伤害源。历史事故记录和事故发生机制的专家知识，可揭示场景条件与伤害之间的因果关系。分析此类因果关系无需掌握主体或其运行环境的详细技术信息，因此可基于初步识别的危害及其相应的伤害，建立危害日志。
基于场景的安全保障方法旨在构建自动驾驶系统的运行环境，为危害事件的识别和风险评估提供支持，这些知识也有助于论证系统不存在不合理风险。但由于场景目录的制定需要进行必要的假设（尤其是在制定逻辑场景或具体场景时），规范缺陷可能导致风险产生。
在风险管理核心中，通过分析已知场景，识别由场景特定条件与已知危害结合引发的危害事件。若系统运行过程中遇到未知的危险场景，可在后续的风险管理迭代中利用相应的监控手段。
根据UL 4600的要求，需将已识别的危害事件和已知伤害类型记录在危害日志中。该日志为风险管理的多个方面提供支持：由于风险管理是一项迭代任务，记录已妥善处理的危害和需要进一步采取措施的危害，有助于实现风险管理状态的显性化记录。
此外，风险管理需在系统开发全生命周期中开展，这要求在多个抽象层级（如功能层、技术层、软件层）评估设计决策对系统整体风险的影响，而危害日志可为每个层级的评估提供基准。在生命周期活动方面，危害日志为系统部署后的持续风险管理提供支持。
仅采取措施应对危害及相应的危害事件，不足以证明系统符合风险接受准则，因为这需要能够在所有已知（和未知）场景中完全缓解危害事件。但证明这种完全缓解不仅耗时费力，在开放的运行环境中更是难以实现。
风险概念通过为所有危害事件或单个事件提供量化指标，为系统的准则符合性评估提供了便利。因此，需按照UL 4600和ISO Guide 51的要求，估算目标系统的固有风险。目前已有多种风险估算技术被提出，例如，Stark等人展示了如何在仿真环境中基于事故数据库开展分析，Kramer等人提出了一种基于环境触发条件发生概率的风险估算方法，该方法同时考虑了估算的伤害严重程度。这类估算可在自动驾驶系统的全生命周期中不断细化。
ISO 26262定义了危害事件分级参数，为风险估算提供了基础：严重程度、暴露概率和可控性，这些参数为后续的风险评估提供了支持。本文需强调的是，ISO 26262基于这些参数直接推导ASIL等级，省略了显性风险评估的步骤。尽管该方法在传统道路车辆（及配备驾驶辅助系统的车辆）功能安全管理中应用成熟，但由于目前尚未为自动驾驶系统制定标准的充分安全措施，本文建议更严格地遵循ISO Guide 51的要求。
因此，本文将风险估算参数的确定，与基于第四部分定义的严重程度和概率显性推导（初始）风险的步骤进行区分。这既支持对风险进行离散分级，也允许以数学连续的方式计算风险。明确区分未采取安全机制时的初始风险，与实施既定安全措施后目标系统的实际残余风险，至关重要，这一区分有助于估算实际风险，并确定所需的安全完整性。
5.2 风险评估
风险评估的目的是判定风险是否超出不合理水平，但该判定过程本身也面临挑战：由于风险接受准则的表现形式多样（如每年的死亡人数、每年的严重事故数，甚至是总体的正风险平衡），将目标系统的实际残余风险与可接受风险进行对比并非易事。
德国自动驾驶与联网驾驶伦理委员会重点探讨了多种风险的权衡问题，其2017年的报告明确指出：“在不可避免的事故场景中，严格禁止基于个人特征（年龄、性别、身体或精神状况）进行区分——至少从德国立法角度来看是如此，也禁止对受害者进行相互权衡”。该伦理委员会制定的这些伦理规则，禁止基于困境场景（如电车难题）开展风险评估，例如Geisslinger等人提出的方法。
目前尚未解决的问题是，社会应如何处理不同的风险组合，Wachenfeld在随机风险评估的背景下详细探讨了此类问题。为应对这些问题，本文在风险管理核心的风险评估步骤中，明确纳入了**风险建模（risk modeling）**环节，并将其分为三项核心活动：
1. 将已识别的每项风险对应至相应的风险接受准则；
2. 对各类风险进行权衡，并考虑其相互关系；
3. 将实际（残余）风险与不合理风险水平进行对比。
在将已识别的风险对应至风险接受准则时，需注意准则可能存在多个，因此一项已识别的风险可能需要进行多次评估。对比残余风险与可接受风险，是判定目标系统是否存在不合理风险（即是否安全）的必要步骤。
若判定系统不存在不合理风险，则需编制安全论证（safety argumentation），全面阐述认定系统无不合理风险的依据、思路和证据；若发现系统违反风险接受准则，则需采取一定的风险降低措施，并开展进一步的风险管理迭代。
5.3 风险处置
安全措施的制定由两个因素决定：第一，需基于残余风险与可接受风险的差距，确定名义风险降低需求（nominal demand for risk reduction）；第二，需确定初始风险水平，以明确所需的安全完整性（safety integrity），该完整性也是总体风险降低需求的一部分。
Fowler通过区分 “最低可实现风险”“残余风险”、“可容忍风险” 和系统的初始固有风险，直观展示了这些风险预算（参见图4）。最大可实现风险降低幅度决定了最低可实现风险，其假设安全功能无故障；随后，由于安全功能的完整性通常低于100%，风险降低效果会出现一定损失（参见图4中的R(L)）；此外，安全功能为目标系统增加了新的功能，其故障行为可能引发新的风险（参见图4中的R(C)）；最终，由这些风险影响因素产生的残余风险，必须低于不合理风险水平。
在第四部分中，本文将安全完整性和风险降低定义为风险管理背景下的两项性能指标（即度量指标）。为遵循IEC 61508开展风险处置，需制定包含风险降低和安全完整性要求的安全措施（即预防措施）。风险管理核心将安全目标作为顶层安全需求，其同时包含所需的名义风险降低幅度和相应的安全完整性。随后，需制定满足风险降低和完整性要求的措施，这些措施最终会影响危害事件的概率和/或严重程度，从而降低目标系统的固有风险。通过后续的风险评估迭代，可验证这些措施是否真正满足风险接受准则。
5.4 安全论证
当风险分析、风险评估和风险处置步骤成功执行并完成迭代，且确定残余风险低于不合理风险水平后，在自动驾驶道路车辆的审批过程中，需向外部利益相关方透明地传达这一结论及其推导过程，作为审批决策的依据。风险管理核心为风险的显性化表示和后续沟通提供了支持。
**安全档案（safety cases）**被提出作为显性表示结构化论证的方法，其基于产生的证据证明相关依据已得到满足。根据Hawkins等人的研究，安全档案包含两部分论证内容：第一，主论证（primary argument），建立过程输出与待支持依据之间的论证关系。在风险管理核心的背景下，这意味着需要显性阐述风险分析、评估和处置过程中产生的产物，为何能支持“自动驾驶系统在其设计运行域内的实际风险<不合理风险”这一依据；第二，置信度论证（confidence argument），记录并解决与主论证或支持性证据相关的不确定性问题。
例如，由于安全工程师的经验和系统知识存在差异，（初始）风险的估算在实际操作中并非完全客观。因此，为避免风险估算不当带来的后果，置信度论证需记录相关问题，并论证为解决这些问题所采取的措施的合理性。
ISO 26262[第二部分，第6.4.8条] 已认可安全档案作为“逐步整合安全生命周期中产生的工作产物，为功能安全实现的论证提供支持”[第二部分，第6.4.8.2条] 的一种方法 [第二部分，第6.4.8.1条]。
因此，由于风险管理核心是一套比功能安全适用范围更广的系统性风险管理框架，且开放交通环境中自动驾驶系统安全论证的复杂性，远高于低自动化水平的系统，本文认为，合理的审批决策需要以安全档案为输入，显性记录风险管理核心流程的主论证和置信度论证。目前已有研究为这类论证提出了初步的构建原则。
06. 风险管理核心在自动驾驶系统行为规范制定中的应用
本部分将运用风险管理核心，展示该流程框架如何应用于自动驾驶系统行为规范制定中的风险管理。ISO 21448要求对因功能缺陷导致的不合理风险不存在性进行论证，该标准将功能缺陷定义为性能缺陷或规范缺陷，并为性能缺陷的识别提供了通用指导，但未提及解决规范缺陷的方法。
规范缺陷可能由对运行环境中所需行为的认知缺失引发，并可能导致系统产生不合理风险。本部分将提出一种解决规范缺陷的方法，助力基于风险的功能规范细化，并通过示例场景展示该方法的应用。
6.1 基于风险的功能规范细化
行为规范是ISO 21448要求的功能规范的一部分，本文提出的基于风险的功能规范细化方法（图5），要求具备推导目标行为形式化表示的方法。
图5：基于风险的功能规范细化流程。为论证自动驾驶系统行为规范中不存在不合理风险，可通过基于风险的功能规范细化流程为该论证提供支撑。本研究所提流程的输出结果为一份行为规范，其中包含行为安全要求及其对应的完整性需求
在这一背景下，Beck等人提出了一种可使行为规范中的设计假设和决策显性化的方法。现象-信号模型（Phenomenon-Signal Model, PSM）为显性表示构成道路交通中自动驾驶系统目标行为的事实和规则，提供了手段。此外，Salem和Beck、Salem提出了语义规范行为分析方法，该方法基于利益相关方的关注点（具体为从德国交通法规中提取的法律关注点），可追溯地推导此类事实和规则。将事实和规则以图结构的形式组合，即可得到自动驾驶系统目标行为的形式化规范。
为实现研究目标，本文参考Beck等人的研究，基于利益相关方关注点集合（根据定义的规范行为）和初步的危害表示（危害日志），开展目标行为的形式化描述（参见图5，步骤1）。
目标行为的形式化步骤，通过支持危险行为（即导致危害事件的行为）的表示，助力基于风险的功能规范细化。此外，还需表示触发条件和功能缺陷，以通过风险降低措施对其进行显性处理（包括定性和定量处理）。现象-信号模型（PSM）提供的目标行为形式化、图结构表示，满足上述所有要求，因为该表示基于事实和规则，而这些事实和规则可从所需的风险降低措施中推导得出。
“与本质上确定行为规范的法学类似，法律中将法律后果与违法行为关联，而事实是所有能证明规则适用的既定条件，即构成规则的‘如果’条件”。
图5中的步骤2a旨在识别危害的目标行为。若将目标行为设为集合T，危险行为设为集合H，则该步骤旨在识别并分析由T∩H引发的行为相关风险rbeh,t。行为相关风险可表示为映射关系f，即rbeh,t=f(T∩H)，并通过将（估算的）实际风险与可接受风险水平rrac对比，对其进行评估。需说明的是，此类标量评估仅用于展示对比关系，本文认可实际风险和可接受风险可能具有更高的维度。
若rbeh,t>rrac，则需采取风险降低措施，此时需制定安全目标（参见图5，步骤3），从定性和定量两方面明确风险降低需求，为名义风险降低幅度和安全完整性赋予具体数值。需注意的是，该步骤并非必须制定新的安全目标，也可通过细化现有安全目标实现。
安全目标的实现需通过制定安全措施（参见图5，步骤4）。为在行为规范层面制定安全措施，本文引入**行为安全需求（behavioral safety requirements）**概念，其是功能需求的一种特殊形式，用于指定特定场景下系统级的行为。
与之相反，传统的功能安全需求（尤其是在ISO 26262背景下）针对的是整个运行环境中的产品。本文利用**能力（capabilities）**概念，将行为安全需求分配至架构要素，已有研究详细阐述了将能力作为实现特定目标行为所需架构要素的方法。
Stolte等人遵循ISO 26262的术语，仅制定功能安全需求并将其分配至能力，但本文认为，为同时符合ISO 26262和ISO 21448的要求，区分功能安全需求和行为安全需求具有重要意义：
对于功能安全，需论证为何系统不存在由电气/电子（E/E）系统故障行为引发的不合理风险；而对于预期功能安全，需论证为何系统不存在由预期功能或其实现的功能缺陷引发的不合理风险。由于功能安全的前提是假设已制定了安全的目标行为规范，预期功能安全相关活动应（其中包括）推动安全目标行为规范的制定。
因此，行为安全需求可为**车辆级预期功能安全策略（VLSS）**提供支持，该策略仅包含预期功能的车辆级需求，尤其是通过显性添加风险降低和安全完整性作为相关信息。此外，对目标行为的严谨描述，可为功能安全生命周期中的活动提供支持，例如系统性危害识别和后续的安全目标制定。
本文示例应用风险管理核心的范围仅针对行为规范，因此在第一次迭代中可能会制定（例如在经济或技术层面）不可行的风险降低措施。若出现该情况，可制定调整目标行为的替代措施（参见图5，步骤5），例如修改设计运行域。
最终，第一次迭代（I₁）通过将既定的风险降低措施整合到行为规范中完成，随后需再次对目标行为开展风险分析。第一次迭代的目标是将rbeh,t=f(T∩H)降低至可接受水平。
假设当目标系统的目标行为产生的残余风险达到可接受水平时，进入第二次迭代（I₂）。根据ISO 21448的要求，需分析可能导致目标行为偏差的触发条件（参见图5，步骤2b）。若发现该偏差具有危害性，则需量化此类行为引发的风险rbeh,d=f(H∖T)。
要成功完成第二次迭代，目标行为引发的总风险需低于可接受风险水平，rbeh,t+rbeh,d<rrac。若风险评估发现系统至少违反一项风险接受准则，则需采取进一步的风险降低措施，此时需重新进入第一次迭代，分析既定安全机制引发的风险。若行为规范（包括风险降低和安全完整性要求）满足所有风险接受准则，则可得到细化后的行为规范。
6.2 细化后行为规范的示例
本部分将展示6.1节所述的基于风险的功能规范细化方法，在示例场景中的应用。本示例场景考虑城市T型交叉口（图6）：自动驾驶自车从图左侧驶入交叉口，T型交叉口左侧设有人行横道，该横道配有标线和交通标志，一名行人打算通过该横道。在该抽象层级，场景未进行进一步参数化，属于门策尔等人定义的功能场景。
图6：城市 T 型交叉口示例场景。本示例设定的场景为城市道路T型交叉口。一名行人拟通过有人行横道标线及对应交通标志指示的人行横道，自动驾驶自车从图示左侧驶入该场景
基于现象-信号模型（PSM），目标行为的形式化规范由**事实（facts）和规则（rules）** 构成。图7展示了现象-信号模型所包含知识的半形式化表示，本文假设通过示例分析已得到初始目标行为。
图7：目标行为形式化规范的因果图表示。目标行为的形式化规范基于适用于具体场景的事实与规则构建，这类规范需采用可解释的表示形式。因此，本文利用因果图，以人类可理解的形式对相关知识进行呈现与梳理
此类分析存在多项假设，本文不重点关注其显性表述，而是通过以下示例事实和规则，展示6.1节所述的流程。输入为规范行为的必要知识，本文通过对示例场景和德国交通法规第26条第1款的部分内容进行语义规范行为分析，获取该知识。标线和标志的编号遵循德国交通法规的定义。
事实：
1. 检测到人行横道标线（标志编号293）；
2. 检测到人行横道标志（标志编号350）；
3. 检测到人行横道；
4. 检测到行人；
5. 行人位于人行横道附近；
6. 检测到行人的过街意图；
7. 自车位于人行横道附近；
8. 在人行横道前停车。
规则：
1. 若检测到人行横道标线（293号）和人行横道标志（350号），则判定为有效人行横道；
2. 若行人位于人行横道附近，则判定其打算通过该横道；
3. 若检测到行人打算通过人行横道，且自车接近该横道，则自车应在横道前停车，让行人优先通过。
此外，本文还给出了初始危害日志，危害源是风险管理核心的输入。在示例危害分析中，假设此前已在仅包含上述两个主体的T型交叉口过街用例中，识别出一项危害。
危害：
道路车辆在人行横道与弱势道路使用者（VRU）发生碰撞，可能导致弱势道路使用者受伤。
遵循6.1节规定的流程，在第一次迭代（图5）中搜索危害的目标行为。在示例场景中，目标行为规范中的事实和规则要求自车在人行横道前停车。
为识别导致伤害（人身伤害）的危害事件，本文仅考虑车辆在交通中的外部行为，因此分析要求在人行横道前停车的规范，是否可能对行人造成人身伤害。在本示例中，该情况不会发生，因为本示例场景的行为规范未包含危险行为。
但对场景进行轻微修改后，即可展示既定行为规范如何导致伤害：假设行人未直接在人行横道上行走，而是在自车与人行横道之间横穿道路，此时目标行为保持不变（即自车继续按目标车速行驶），因为在该修改后的场景中，行人位于人行横道附近这一事实不成立，因此根据既定的行为规范，自车无需采取停车操作。
若行人按修改后的场景横穿道路，两个主体之间存在潜在的碰撞风险，由此引发以下危害事件：
危害事件：
道路车辆在人行横道前与行人发生碰撞。
该危害事件是示例场景中既定危害的具体体现。在UseCase描述中，无需对弱势道路使用者进行进一步细化，但在场景特定背景中，需提供更多细节。因此，该危害事件中的行人是弱势道路使用者的具体实例。
此类危害事件是规范缺陷的结果，即在目标行为形式化过程中，未考虑行人的非规则过街行为。
在缺乏有效数据的情况下开展风险评估具有较大挑战，尤其是在估算危害事件可能造成的伤害严重程度方面。由于本文的研究重点是论证风险管理方法，因此不尝试进行有效的风险量化，仅给出风险评估的潜在结果示例。
为估算已识别危害事件引发的风险，本文作出以下假设：由1000辆自动驾驶载人面包车组成的车队，在柏林市区运营，每年运行365天；由于车队车辆为电动汽车，考虑充电和维护时间，假设其每日运行22小时；假设每辆车每年在人行横道处与行人发生3次近距离接触，且每3000次近距离接触会发生1起致命碰撞。因此，示例中车队在人行横道处发生行人致命碰撞的时间间隔为1年；同时假设在该场景中，危害事件的发生必然导致伤害（例如相关主体无法控制）。
估算道路车辆与行人碰撞造成的伤害严重程度，需要对双方的行为进行参数化。在功能场景的范围内，本文作出进一步假设：在德国，人行横道仅允许设置在建成区内，此类区域的常规限速为 50km/h；在该一般条件下发生的碰撞，可能导致危及生命的伤害，且伤者的存活率无法保证（假设被碾压，相当于ISO 26262中的S3分级）。
需说明的是，本文仅基于粗略估算对风险进行量化，若要开展更详细的评估，需要逻辑场景和具体场景，以获取相关主体的质量和速度等信息。
基于上述假设，本文首先计算车队每年的运行小时数，再根据估算的车队每年发生1起人行横道致命碰撞，计算每运行小时内人行横道处的行人死亡数，以此表示实际风险的估算值：
对于基于风险管理核心的功能规范细化，需要将目标行为与风险接受准则进行对比评估。与风险评估步骤一致，本文重点关注方法的应用，而非识别有效的风险接受准则。德国自动驾驶与联网驾驶伦理委员会制定的一项风险接受准则为正风险平衡，即自动驾驶系统的引入应使风险低于人类驾驶的风险，本文假设该准则是示例中唯一相关的风险接受准则。
为表示满足该风险接受准则的可接受风险，本文参考当前人类驾驶的事故数据，并假设该数据涵盖的设计运行域（ODD），与本文估算实际风险时使用的设计运行域一致，以实现两者的对比。
根据柏林参议院政府的数据，柏林城市道路的年行驶里程为 8.623×10⁶公里/年，平均车速约为24km/h；2006-2011年期间，柏林仅记录到1起行人在人行横道处死亡的事故。基于上述假设，本文首先估算柏林每年的总驾驶小时数，再量化当前柏林交通中每驾驶小时内人行横道处的行人死亡频率：
对比危害事件的实际风险估算值与可接受风险表示值，结果表明系统超出了可接受风险阈值，违反了风险接受准则。因此，本文需要制定安全目标，并随后制定可赋予必要风险降低幅度的安全需求。
与ISO 26262中描述的活动相比，安全目标可在危害识别完成后制定，也可利用已有知识在安全生命周期的更早阶段制定，风险管理核心明确考虑了这一制定顺序。本文在确定必要的风险降低幅度后再制定安全目标，以突出研究的贡献。
需注意的是，示例安全目标同时参考了所考虑的危害和危害事件，以找到合适的抽象层级（基于危害），并根据危害事件的评估结果确定必要的风险降低幅度。本文示例中的风险评估包含了关于安全完整性的假设，该完整性是安全目标和行为安全需求所需风险降低的一部分。
第五部分已阐述，安全完整性取决于为目标系统确定的初始风险，IEC 61508为如何基于初始风险定义安全完整性（等级）提供了指导。
安全目标：
防止道路车辆在人行横道处与弱势道路使用者发生碰撞。
针对该示例安全目标，一项安全措施是将人行横道处行人的非规则过街行为纳入目标行为的形式化过程，并制定捕捉其过街意图的事实和规则。本文进一步假设，此类安全措施ⁿᵢ在技术上是可行的，现有先进的行人预测算法已能实现该功能。
行为安全需求：
若检测到人行横道，需可靠检测行人在人行横道处的过街意图。
为完成第一次迭代（图5），需要开展第二次语义规范行为分析，以提取与人行横道处行人可合理预见的非规则行为相关的事实和规则，例如基于法院判例。此外，IEEE 2846中也包含了关于对其他道路使用者作出假设的有益指导。
对于示例场景，本文规定，行人的过街意图不应仅基于其是否位于人行横道附近进行判断，而应结合当前的交通场景进行推断。即自车应检测到行人、推断其过街意图，并在人行横道前停车让行。
第一次迭代（图5）未考虑与既定行为的偏差，将既定安全措施整合到行为规范后，已识别的危害事件在本文的场景目录（包含两个场景）中将不会发生。需说明的是，本文忽略了在制定所有相关场景的过程中存在的不确定性，以及因场景目录不完整而产生的风险。
进入第二次迭代（图5）后，需要评估目标行为偏差引发的风险，Kramer等人阐述了此类评估的方法。在本示例中，目标行为偏差可能源于行人意图预测算法的性能缺陷，例如算法未能正确识别行人的非规则过街意图。
为量化此类行为偏差引发的风险 rbeh,d，本文作出以下假设：行人意图预测算法的准确率为99.9%，即每1000次行人过街场景中，会发生1次预测错误。结合第一次迭代中估算的车队每年 3000次人行横道近距离接触数据，可推算出每年约发生 3 次因预测错误导致的危害事件。基于第一次迭代中每3000次近距离接触发生1起致命碰撞的假设，此类行为偏差引发的致命碰撞概率极低，估算结果为每年约0.001起致命碰撞。
据此计算，行为偏差引发的风险约为1.25×10−10死亡人数/小时。将其与第一次迭代后目标行为的残余风险相加，总风险约为4.65×10−10死亡人数/小时，略高于可接受风险阈值。因此，需进一步采取风险降低措施，例如优化行人意图预测算法以提升准确率，或引入冗余感知系统以降低预测错误概率。
假设通过算法优化，预测准确率提升99.99%，则行为偏差引发的风险将降至 1.25×10−11死亡人数/小时，总风险约为4.64125×10−10死亡人数/小时，低于可接受风险阈值。此时，风险评估结果表明系统符合风险接受准则，无需进一步迭代。
最终，通过两次迭代，本文得到了细化后的自动驾驶系统行为规范，该规范既涵盖了针对行人非规则过街行为的规范补充，也考虑了因算法性能缺陷导致的行为偏差风险，并通过相应的风险降低措施确保总风险控制在可接受范围内。
7.1 研究结论
本文针对自动驾驶系统（SAE 3级及以上）风险管理中存在的“不合理风险”定义模糊、现行安全标准指导隐性化等核心问题，提出了**风险管理核心（RMC）**这一流程框架，旨在实现自动驾驶风险的显性化表示与管理。
研究的核心结论如下：
1. 需求提取与框架构建：通过分析ISO 26262、IEC 61508、ISO 21448等核心安全标准，提取出13项自动驾驶风险管理框架的关键需求，明确了风险识别、评估、处置、安全目标制定等核心环节的显性化要求。
2. 术语本体论统一：构建了涵盖“风险评估”与“风险处置”的专业术语本体论，整合了不同标准中存在的术语差异（如“可接受风险”与“可容忍风险”），为风险的显性化描述提供了统一的概念基础。
3. RMC框架有效性验证：将RMC框架应用于自动驾驶系统行为规范的制定任务，通过城市T型交叉口行人过街的示例场景，展示了其在解决规范缺陷、细化功能需求、量化风险降低效果等方面的可行性。该应用证明，RMC能够有效支撑自动驾驶系统从“隐性风险管控”向“显性风险论证”的转型。
4. 安全论证的支撑价值：RMC框架通过显性记录风险分析、评估与处置的全流程，为安全档案的编制提供了结构化的论证依据和证据链，能够满足自动驾驶车辆审批过程中对风险沟通透明度的要求。
本文的研究表明，风险的显性化表示是解决自动驾驶系统风险管理难题的关键。通过将隐性的风险知识转化为显性的量化指标、流程和文档，制造商能够更精准地匹配风险接受准则，同时也能向监管机构、公众等利益相关方清晰传达系统的安全水平。
7.2 未来工作
尽管本文提出的RMC框架为自动驾驶风险管理提供了系统性方法，但仍存在若干可拓展和深化的方向：
1. 风险接受准则的社会协商机制：本文未涉及风险接受准则的制定过程，未来可结合社会学、伦理学研究，探索多利益相关方（政府、制造商、公众、学术界）参与的风险接受准则协商与量化方法，为自动驾驶系统提供更具社会认可度的风险阈值。
2. 开放场景下的动态风险管理：当前RMC框架主要聚焦于部署前的风险管理，未来需拓展至部署后的动态监控与迭代优化，研究基于实车运行数据的风险实时评估、安全措施动态调整技术，以应对开放交通环境中的未知风险。
3. 不确定性的量化与管理：风险估算、场景目录完整性、算法性能等环节存在的不确定性，对风险管理结果的置信度有重要影响。未来需引入不确定性量化方法（如贝叶斯网络、蒙特卡洛仿真），并将其融入 RMC 的置信度论证环节，提升安全档案的可靠性。
4. 跨领域标准的融合应用：本文主要参考汽车领域安全标准，未来可探索将航空、铁路等成熟领域的风险管理经验（如DO-178C、EN 50126）融入RMC框架，针对自动驾驶系统的跨域运行特性（如车路协同、低空自动驾驶），构建更具通用性的风险管理体系。
5. 工具链的开发与验证：为推动RMC框架的工程化应用，未来需开发配套的风险管理工具链，涵盖危害日志管理、场景风险估算、安全目标生成、安全档案编制等功能，并通过实际自动驾驶项目进行验证与优化。
免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系TechApe@yeah.net告知，我们会在第一时间做出处理。
