摘要：汽车功能的范畴已从单一车辆实体扩展到多车协同工作的实体，即所谓的协同驾驶。当前的汽车安全标准ISO 26262是为单一车辆设计的。随着具备协同驾驶能力的车辆在道路上日益增多，系统地评估这些车辆架构的功能安全已成为当务之急。在软件架构领域，已有多种方法可针对不同质量属性评估架构，但据我们所知，文献中尚未探讨过汽车架构的功能安全评估。本文提出一种方法，该方法利用软件架构和安全工程领域的现有研究成果，用于验证车辆技术架构是否满足协同驾驶场景下的功能安全需求。我们将该方法应用于协同驾驶场景（车队行驶）的实际学术原型，并对所得见解进行了探讨。

01. 简介

随着城市人口的持续增长，在可预见的未来，交通拥堵仍将是一个无法避免的问题。美国约70%的货物运输依靠卡车完成，而卡车运营成本的主要部分包括燃油成本和驾驶员薪资。协同驾驶是缓解交通拥堵、降低此类运营成本的潜在解决方案之一。

协同驾驶指通过无线通信（如对等网络）或借助云等其他主体共享信息，对交通参与者的行为进行集体优化。协同驾驶能够提高交通效率、降低成本并提升舒适性。根据市场研究，协同驾驶是影响技术市场的54个趋势之一。

多数协同驾驶功能的实现，依赖于根据从其他交通参与者处获取的信息确定车辆行为，以实现最优交通表现。此类最优行为（部分或全部）通过软件控制的转向、加速和制动系统来实现。因此，软件若出现任何问题，不仅可能对车辆自身造成灾难性影响，还可能危及其他交通参与者。为避免此类事件发生，协同驾驶系统在设计时需确保即使发生故障也能正常运行，或在故障时实现安全失效。

当前保障汽车系统（及其架构）安全的指南由ISO 26262:2018提供，该标准是汽车领域的产品开发标准。ISO 26262标准借鉴了安全工程领域的系统方法，用于识别安全需求。任何满足这些安全需求的汽车软件架构，均可被视为 “设计安全型” 架构。

然而，ISO 26262标准既未考虑协同驾驶场景，也未规定架构评估方法。该标准是为单一车辆设计的，未纳入“将多车视为单一实体”的协同视角。这意味着，从单一车辆视角看风险较低的安全需求，在协同场景下可能对其他协同车辆造成灾难性影响。为从协同视角构建功能安全架构，已有研究对标准指南进行了扩展，或提出了架构框架。但如何评估现有车辆软件架构在协同驾驶场景下的安全性，仍是一个尚未解决的问题。

ISO 26262标准未规定评估汽车架构功能安全的方法。在过去三十年中，软件架构领域已出现多种针对质量属性的架构评估方法。但其中仅有部分方法针对运行时质量属性（如性能）设计，而非开发阶段质量属性（如可维护性）。据我们所知，目前尚无任何一种方法专门用于评估汽车系统运行时质量属性中的功能安全。

本文提出一种方法，通过结合安全工程和软件架构领域的方法，评估现有汽车架构在协同驾驶场景下的功能安全。该方法包含两部分：

（1）推导协同驾驶场景下的功能安全需求（FSRs）—— 此部分是对我们前期研究的扩展；

（2）验证（技术层面的）软件架构是否满足推导得出的功能安全需求 —— 此部分整合了软件架构领域的多种技术并进行了适应性调整。

本文主要聚焦于设计阶段（对应ISO 26262中的概念开发阶段），以及在最终产品的软件架构中验证所得要求的有效性。我们将该方法应用于一个具备协同驾驶能力的学术原型架构，以“车队行驶”这一协同驾驶场景为例进行演示 —— 在该场景中，一辆人工驾驶的车辆作为头车，其后有多辆车自动跟随。

本文其余部分结构如下：第2节介绍与本研究相关的背景知识；第3节阐述所提方法，包括功能安全需求的推导以及验证车辆技术软件架构是否满足这些要求的过程；第4节详细说明将所提方法应用于车队行驶这一协同驾驶用例的学术原型的过程，并解读案例研究结果；第5节讨论所提方法的隐含假设、适用性及适用范围；第6节分析有效性威胁；第7节提出未来研究方向；第8节为结论。

02. 背景

本节将介绍构建本文研究成果所基于的三个核心概念。首先，概述汽车功能安全中的相关概念；其次，探讨安全策略与模式的基础知识；最后，简要介绍汽车架构的两种视图。

2.1 功能安全

功能安全的定义为 “因电气/电子（E/E）系统故障行为导致的危害不存在不合理风险”，其中E/E系统指电气和/或电子系统。在汽车领域，功能安全由两项标准定义：ISO 26262:2018和ISO 21448，二者功能互补。前者关注系统组件故障引发的危害，后者则聚焦于功能不足和误用导致的危害。ISO 26262是当前的安全标准，最新修订版发布于2018年；而ISO 21448目前以ISO/PAS 21448技术规范形式存在。这两项标准的前身是更通用的IEC 61508标准，该标准为开发用于执行安全功能的电气/电子/可编程电子系统提供了功能安全指南。

本文主要聚焦于ISO 26262标准的概念阶段（第3部分），该阶段规定了功能安全需求（FSRs）的推导及其向功能架构组件的分配流程。概念阶段的分析对象是 “项”（item），根据ISO 26262定义，“项”指“应用ISO 26262标准的系统或系统组合，用于在车辆层面实现某一功能或功能的一部分”。

功能安全需求（FSRs）的推导始于识别危害事件。每个危害事件由危害、运行模式和运行场景三部分组成。例如，“在高速公路行驶（运行场景）的经济驾驶模式（运行模式）下发生制动失效（危害）”，就是一个危害事件实例。运行模式和运行场景源于对系统预期运行环境或场景的自然语言描述，此类描述在本文中统称为场景描述或场景。

为防范危害事件，需定义安全目标。安全目标较为宏观，属于高层级安全需求。每个安全目标都会被分配一个汽车安全完整性等级（ASIL），分为 A、B、C、D 四个等级，用于明确在产品开发后续阶段实现该目标的重要性（A级重要性最低，D级最高）。根据 ISO 26262指南，ASIL等级需结合每个安全目标的暴露度、可控性和严重度来确定。每个安全目标可分解为一个或多个功能安全需求（FSRs），且每个FSR继承其所源自的安全目标的（最高）ASIL等级。

在文献中，关于安全需求属于功能要求还是非功能要求，尚未达成共识。在安全工程领域，FSRs被归为功能要求；但在软件架构领域，FSRs大多被归类为质量要求（非功能需求）。

2.2 安全策略与模式

架构策略是对设计决策的提炼，这些决策会影响系统在特定质量属性方面的表现。架构策略具有抽象性，不强制规定特定的实现结构，可视为无既定实现方案的建议。与之相对，架构模式是结构明确的实体，具有既定的实现方案，可用于实现架构策略。本文采用的安全策略与模式，就是用于应对安全问题的架构策略与模式。

2.3 架构视图

本文在两个场景下使用系统架构：（1）通过将危害事件映射到系统功能组件，从危害事件中生成 FSRs；（2）确定某一功能组件的实现是否采用了一种或多种安全策略。

第一个场景需要系统的功能分解视图，即功能架构视图。在汽车领域，功能架构视图用于描述车辆的功能构成、功能实体、接口、交互关系、依赖关系、行为及约束条件。该视图源于功能视角，即从车辆功能及其逻辑交互的黑箱视角审视系统。需注意，此视图的范围为系统层面。

第二个场景需要更详细的信息，而这些信息无法从功能架构视图中获取，只能从技术架构视图（也称为实现视图）中获得。技术架构视图描述具体的软件实现、物理组件（如电子电气硬件）、组件间关系、软件部分到硬件组件的分配、软硬件组件间的依赖关系及约束条件。显然，技术架构视图与功能架构视图之间存在高度一致性。图 1 展示了这两种架构视图的示意图。

图1：功能架构视图与技术架构视图及其范围。功能架构与技术架构是同一系统在不同架构抽象层级下的视图，其中功能架构处于最高抽象层级。运行时模型描述系统行为，而硬件拓扑描述硬件平台的结构，该平台包含电子控制单元、传感器、机械组件以及连接这些组件的总线。分配视图将运行时模型的元素与硬件拓扑的元素相关联。运行时模型与分配视图共同构成技术软件架构

本文选择技术架构视图，原因在于该视图能够帮助确定是否实现了一种或多种安全策略，且该视图易于获取——在汽车项目中，技术架构视图是必需的。相比之下，其他视图可能缺乏必要细节或存在更新不及时的问题。在本文后续内容中，技术架构视图中的运行时模型和分配视图部分统称为技术软件架构。

03. 方法

本文提出的方法用于验证车辆技术软件架构是否满足协同驾驶场景下的功能安全需求（FSRs）。该方法包含两部分：（1）推导协同驾驶场景下的FSRs（见第3.1节和图2）；（2）验证车辆技术软件架构是否满足推导得出的 FSRs（见3.2节和图3）。

协同驾驶场景下的FSRs需在单个车辆中实现。ISO 26262标准建议将FSRs（或FSRs分解后的子需求）映射到各个系统架构组件。考虑到系统的复杂性和规模，这种映射至关重要。参考安全工程领域的现有解决方案，当前方法尚未将协同驾驶场景下推导的FSRs映射到单个车辆组件。本文提出的解决方案通过将协同功能架构（其各个组件属于车辆功能架构）与现有FSRs推导方法相结合，填补了这一空白。第3.1节将详细介绍这一步骤。

接下来，需验证车辆技术软件架构是否满足推导得出的FSRs。本文提出的FSRs满足性评估方法，整合了软件架构领域多种技术并进行了适应性调整。由于目前尚无针对汽车系统功能安全这一质量属性的架构评估技术，所提方法借鉴了传统架构评估技术的思路，并采用安全策略框架以利用现有架构知识。第3.2节将详细介绍该方法的这一部分。

除功能安全外，网络安全是另一个日益与功能安全协同考量的领域。本文方法的范围仅限于功能安全，网络安全不在研究范围内。此外，FSRs的满足通常需通过专用硬件实现，或结合硬件与软件实现。尽管本文方法的第一部分将FSRs与系统层面的架构组件相关联，但第二部分的研究重点为软件。通过硬件架构（图1中的硬件拓扑）满足的FSRs，不在本文方法的研究范围内。

3.1 推导协同驾驶场景下的FSRs

该方法中推导FSRs的部分，仅需了解单个车辆功能的黑箱视图以及这些功能间的交互关系。因此，我们采用功能架构视图来推导协同驾驶场景下的FSRs。需注意，功能架构是整个系统的架构（见图1），包含硬件和软件组件。

本文对ISO 26262标准规定的传统方法进行扩展，以推导协同驾驶场景下的FSRs。传统方法（ISO 26262的概念阶段）以单个车辆作为“项”展开分析。本文提出类似方法，同时以整个协同系统作为分析对象。图2概述了所提方法。下文先介绍传统方法，再阐述我们前期对该方法的扩展研究，最后说明新的研究贡献。在本文后续内容中，“车辆视角”指以单个车辆为分析单元，“协同视角”指以多车组合为分析单元。

图2:推导合作驾驶场景的FSR的方法。右侧的灰色部分是ISO 26262中的传统方法，左侧的黑色部分是我们对传统方法的补充。系统架构师代表参与创建协同架构的外部实体

传统上，车辆视角下的FSRs推导过程为：将车辆的安全目标映射到车辆功能架构的各个组件。这种映射过程（也称为安全分析）需记录组件故障可能导致安全目标失效的相关信息。安全分析需通过系统化流程开展，如故障树分析（FTA）或失效模式与影响分析（FMEA）。开展安全分析需两个输入：（1）功能架构（描述系统分解后的功能组件及组件间连接关系）；（2）安全目标。

根据ISO 26262指南，安全目标需从危害事件中推导得出，而危害事件则通过危害分析与风险评估（HARA）技术对场景描述进行分解来识别。图2中第3部分及流程a和d展示了这种FSRs推导方法，其中流程a和d是安全分析的输入。这种从场景描述推导FSRs的方法，在汽车领域已作为标准实践应用了至少十年。

在通过HARA推导安全目标的过程中，需为每个安全目标分配ASIL等级。根ISO 26262提供的度量标准，ASIL等级需结合危害事件可能造成损害的严重度、事件暴露概率以及车辆在事件中的可控性来确定。每个FSR继承其所源自的安全目标的最高ASIL等级。ASIL等级为“D”意味着满足该FSR需采用最严格的安全措施，而ASIL等级为“A”则表示风险较低，所需安全措施等级也较低。

在协同系统中，某一车辆的安全目标可能会对另一车辆提出FSR需求。例如，考虑一个简单的协同驾驶场景：一辆跟驰车辆通过车对车（V2V）通信自主跟随一辆人工驾驶的引导车辆。该场景下的一个安全目标为：“跟驰车辆应根据引导车辆的加速度自主调整加速度”。尽管该安全目标看似仅与跟驰车辆的自主加速度控制组件相关，但它同样映射到引导车辆的功能架构组件。由此可推导出针对引导车辆加速度传感组件的FSR：“引导车辆加速度传感组件发生故障时，不得向跟驰车辆的自动转向组件传输错误的加速度信息”。若无法满足该需求（及其关联的安全目标），可能导致碰撞事故。然而，这类安全目标仅能从协同视角识别。

在本文提出的方法中，每种车型对应一个“项”，同时整个协同系统（车辆为其组成部分）也对应一个“项”。协同系统中可能包含多种车型（例如，两种功能架构不同的车辆构成一个协同系统），也可能包含云等其他实体以实现协同驾驶功能。若存在多种车型（功能架构不同），则每种车型对应一个“项”。对于除协同系统外的其他所有“项”，均可采用上述ISO 26262传统分析方法。我们认为，图2中展示的两个 “项”（单个车辆和协同系统）可推广到需要更多 “项” 的场景。此类场景仅需为每个新增“项”（即每个独特的功能架构）重复执行ISO 26262传统分析（见图2中阴影部分）。无论何种情况，协同功能架构始终唯一，因此协同系统对应的“项”也唯一。在本节后续内容中，我们仅考虑两个“项”：单个车辆（代表所有车辆功能架构）和协同系统。

本文提出，协同系统的FSRs需从两方面推导：（1）车辆视角的安全目标（传统方法）；（2）协同视角的安全目标。基于此，我们前期的研究对传统方法进行了扩展，将车辆视角的安全目标推导流程延伸到协同视角（见图2中第2部分），以覆盖两种视角下的FSRs。该流程将场景描述划分为车辆专属部分和协同专属部分，随后对这两部分分别执行传统的安全目标识别步骤，进而推导得出车辆视角的FSRs（如前文所述）。

我们发现，协同功能架构应基于单个车辆的功能组件构建。这一设计可确保协同系统功能架构与其实现视图（车辆技术架构）之间的映射关系。要通过故障树分析（FTA）等安全分析技术推导FSRs（将安全目标映射到功能架构组件），必须构建协同功能架构。本文提出，协同功能架构的构建需基于：（1）构成协同系统的单个车辆的功能架构；（2）描述单个车辆间交互关系的协同场景描述。根据这些要求，系统架构师可构建协同系统的功能架构，确保该架构的各个组件能映射到车辆功能架构的组件。这一流程在图2中标记为第1部分；从协同视角推导FSRs的完整流程由标记1、2、b和c共同表示。

综上，本文提出的方法将每个协同驾驶场景映射到一组FSRs，其中每个FSR至少与一个车辆功能相关联，而该车辆功能又与一个功能组件对应。需注意，为保证方法效率，建议采用一对一映射，但不强制要求。将一个FSR映射到多个功能组件并不可取，原因有二：（1）责任划分不明确，可能导致实现偏差；（2）该层级的测试无法开展，只能通过集成测试验证FSR的实现情况。在本文后续内容中，我们假设每个FSR均可映射到一个功能架构组件。

3.2 验证FSRs的满足情况

本文提出的验证单个车辆技术软件架构是否满足FSRs的方法，分为两个阶段。第一阶段通过识别是否存在冲突的FSRs，确保所有FSRs均具备实现可能性；第二阶段提出系统化方法，验证技术架构是否满足FSRs。图3概述了该流程。

该方法同时采用功能视图和技术视图：功能视图用于对FSRs进行一致性检查，识别冲突；技术视图则用于验证每个车辆功能（及其关联的安全机制）的实现是否符合对应的FSRs。

图3:技术架构中FSR履行情况的检查方法

3.2.1 第一阶段：检查FSRs冲突

若两个FSRs无法同时满足，则认为二者存在冲突。以下为冲突FSR的假设示例：

· FSR_01：执行器传感器发生失效时，传感器应发送故障消息进行提示。

· FSR_02：执行器传感器发生失效时，传感器应停止发送任何消息。

· FSR_01和FSR_02存在冲突：针对同一事件（执行器传感器失效），FSR_01要求发送消息，而FSR_02要求停止发送消息，二者无法同时实现。

若对所有FSR两两组合进行冲突检查，所需检查次数将呈二次方增长（若FSR数量为n，则检查次数为n (n-1)/2≈O (n²)）。本文提出，仅对属于同一功能架构组件的FSRs进行冲突检查，可将检查次数减少d倍（d为功能组件数量，即检查次数可减少至n (n-d)/d≈Ω(n²/d)）。之所以能实现这一简化，是因为用于推导FSRs的安全分析技术可确保每个FSR仅归属于一个功能组件。此外，同一组件的FSRs之间可能存在冲突，但不同组件的FSRs之间不会存在冲突。例如，在第4节的案例研究中，我们推导得出31个FSR，分布在8个功能组件中。若对所有FSR两两组合检查，需执行465次检查；而按功能组件分组后，检查次数减少至60次。这一流程在图3中标记为“第一阶段”。

若存在冲突的FSRs，可能表明以下环节存在问题：（1）功能架构；（2）场景的功能分解；（3）场景本身（假设其他步骤均正确执行）。在继续后续流程前，需解决这些冲突。尽管冲突解决不在本文研究范围内，但冲突检查可作为一致性验证步骤，确保在给定技术架构中所有FSRs均具备实现可能性。

3.2.2 第二阶段：验证FSRs与技术架构的符合性

一个FSR可通过单一安全策略或多个安全策略的组合来满足。为验证某一FSR是否得到满足，本文提出需检查车辆技术软件架构中是否实现了可满足该FSR的安全策略，具体通过以下两个步骤实现：（1）确定一组适用安全策略——该组策略中，单个策略或多个策略的组合可满足FSR；（2）检查车辆技术架构中是否存在来自适用安全策略的可行组合，以满足FSR。需注意，对于FSR fi及其对应的功能组件ci，仅需将fi的适用安全策略与技术架构中ci及其关联安全机制所采用的安全策略实现进行比对，因为fi仅与ci相关联。

可通过两种方式确定FSR的适用安全策略：（1）根据FSR描述，通过策略层级结构筛选；（2）将FSR描述与各策略描述进行匹配。以某一FSR为例：“引导车辆加速度传感组件发生失效时，不得向跟驰车辆的自动转向组件传输错误的加速度信息”。根据第一种方法（安全策略层级结构），适用于失效遏制的安全策略为“多样性冗余”；通过第二种方法（FSR描述与策略描述匹配），也可识别出该策略——“多样性冗余”策略的描述为“引入冗余系统，可检测或掩盖规格、实现过程中的失效以及硬件随机失效”，与上述FSR描述相符。

通过“确定适用策略”和“检查技术架构中的策略实现”这两个步骤，可识别出未实现可行策略组合的FSRs。若未识别出此类FSRs，则表明车辆技术架构满足给定协同驾驶场景下的所有FSRs；否则，未满足的FSRs将被列出。

此外，对于每个未满足的FSR，还可获得一组适用安全策略——该组策略中的某些可行组合可满足FSR。这些组合对应一组安全模式，因为安全模式与它们所实现的安全策略相关联。这些适用安全模式（及适用安全策略）为系统架构师提供了实现未满足FSRs的潜在设计方案。但适用安全模式的适用性分析及权衡分析不在本文研究范围内。

需注意，架构策略与安全完整性等级（ASIL）无关联。因此，某一策略是否适用于特定ASIL等级，需单独研究，不在本文研究范围内。本文方法（第二阶段）的目标是识别相关策略，并验证它们是否在技术软件架构中实现。

04. 案例研究

本节介绍将所提方法应用于协同驾驶场景（车队行驶）的过程。首先，描述车队行驶场景及单个车辆的功能架构（所提方法的两个输入）；随后，呈现方法应用结果及解读。

4.1 车队行驶场景与实验平台概述

车队行驶指多辆车组成的车队，其中一辆人工驾驶的车辆作为“引导车”，至少有一辆车辆作为“跟驰车”自动近距离跟随引导车行驶。在车队行驶过程中，车辆通过车对车（V2V）通信实现协同。研究表明，车队行驶具备以下潜力：（1）降低平均燃油消耗；（2）提升安全性——例如，通过车队范围内的协同制动防止追尾事故；（3）提高交通吞吐量 —— 通过提高平均车速和减少交通拥堵实现。本案例研究中，车队行驶的场景范围限定在高速公路及高速公路互通区域。

本文将所提方法应用于i-CAVE项目开发的协同驾驶软件架构，该架构部署在雷诺Twizy（一款小型电动汽车）上。实验车辆配备了额外的传感器和执行器，以及完整的软件栈（下文简称 “i-CAVE演示车”）。i-CAVE演示车的软件栈部署在两个硬件平台上：一个是运行Simulink RealTime操作系统的研华ARK 3520P实时计算机，另一个是英伟达Drive PX2平台。

4.2 功能架构描述

i-CAVE 演示车的简化功能架构如图4a所示。为简化表述，仅展示实现车队行驶所必需的功能组件。箭头表示从传感器抽象层到执行器的数据流向，整个系统构成一个闭环控制回路。部分功能架构组件根据功能划分为不同类别（如图4a所示）。例如，“传感器抽象层”是一个组件类别，包含“执行器传感器”和“环境感知传感器”两种功能组件。同一类别内的功能组件相互独立，无数据交互。各功能组件的描述如下：

图4：i-CAVE演示器的简化功能架构及其衍生的编队架构（协同架构）

（a）传感器抽象层：包含硬件传感器及其通过软件接口实现的封装。从功能上可将传感器分为两类：（1）执行器传感器——用于监测车辆状态和动态属性（如车速、惯性测量数据）；（2）环境感知传感器——如雷达（RADAR）、全球定位系统（GPS），用于监测车辆外部环境并实现车辆地图定位。

（b）传感器融合层：整合不同类型传感器的数据，生成车辆及其周边环境的信息。i-CAVE演示车的传感器融合层包含三个功能组件：（1）主机跟踪组件——结合位置数据和惯性测量数据，确定车辆的绝对位置；（2）车辆状态估计组件——结合加速度信息和执行器传感器数据，估计车辆动态状态；（3）目标跟踪组件——结合雷达等环境感知传感器数据，检测车辆周边的物体和其他车辆。

（c）V2V通信组件：用于在车辆之间传输车队行驶所需的执行器相关信号。

（d）车辆控制组件：利用车辆状态信息、周边环境信息及通过V2V通信获取的前车信息，生成车辆自动执行器的控制信号。当车辆处于人工驾驶模式时，该组件接收驾驶员的执行器控制指令。

（e）执行器组件：包含车辆加速、转向、制动系统的硬件及其对应的软件接口（也称为线控驱动接口）。需注意，与车队行驶功能无关的非功能需求相关组件（如安全管理组件）未在图中展示，因为它们不属于实现车队行驶所需的基础功能架构。

4.3 车队行驶场景下的FSRs推导

所提方法第一部分（FSRs推导）的步骤如图2所示，具体实施过程如下：

4.3.1 功能分解

将车队行驶场景描述（简称“SD”）分解为五个子场景：

· SC-1：车辆作为跟驰车加入车队，位于最后一辆跟驰车之后；

· SC-2：跟驰车退出车队；

· SC-3：车队拆分为两个独立车队；

· SC-4：两个相邻车队合并为一个车队；

· SC-5：引导车退出车队后，第一辆跟驰车成为新的引导车。

当一辆车加入另一辆车组成两辆车的车队时，车队即形成；当一辆车退出两辆车的车队时，车队即解散。车队的加入和退出操作由车辆驾驶员手动执行。

将车队行驶场景描述从两个视角分解为功能：车辆视角下分解为9个功能，协同视角下分解为6个功能，具体如表1所示。

表1：基于车队行驶场景描述识别的功能及对应危害数量

4.3.2 危害事件识别

基于上述功能，识别潜在危害。采用汽车领域常用的七个引导词（无、过多、过少、同时、部分、相反、其他），共识别出57个危害。例如，针对车队功能“保持足够安全的车距”，结合引导词“过少”，可识别出危害“车距小于安全距离”—— 该危害可能导致车队内车辆碰撞。各功能对应的危害数量如表1所示。

这57个危害（协同视角26个，车辆视角31个）与运行模式（协同视角7种，车辆视角6种）和运行场景（每个视角2种）组合后，共生成340个危害事件（车辆视角140个，协同视角200个）。需注意，并非所有危害、运行模式和运行场景的组合均可行，不可行的组合未纳入后续分析。例如，协同视角下的一个危害事件为：“在高速公路（运行场景）上与另一车队合并（运行模式）时，车距小于安全距离（危害）”。

4.3.3 安全目标制定

针对每个危害事件，制定相应的安全目标以防范危害。对每个视角下的相似安全目标进行合并，最终得到车辆视角14个安全目标，协同视角11个安全目标。例如，将56个危害事件对应的安全目标合并为一个安全目标：“无论车队处于何种运行模式或运行场景，均应保持足够安全的车距”。

在为安全目标分配ASIL等级时，假设除引导车外，车队内所有跟驰车在发生故障时无法依赖驾驶员作为备用方案；而对于正在加入或退出车队的车辆，假设在操作过程中可依赖驾驶员应对故障。因此，在跟驰车相关场景中，可控性评分设为最低；由于引导车为人工驾驶，其可控性评分设为最高。考虑到高速公路场景下的车速范围，若车辆或车队故障导致碰撞事故，严重度评分设为最高。根据场景（加入车队、退出车队、车队拆分、车队合并、引导车更换）和运行场景（高速公路、高速公路互通）的不同，设置不同的暴露度评分，其中高速公路场景的暴露度评分最高。因此，大多数安全目标的ASIL等级被定为D级。

4.3.4 协同功能架构构建

图4b展示了车队行驶的简化协同功能架构，包含实现车队行驶所需的功能组件及车辆在车队中的功能级工作流程。该协同功能架构由四位系统架构师共同构建，他们均为机械工程师，参与i-CAVE演示车的开发，至少拥有硕士学位及两年以上汽车架构开发经验。协同功能架构包含与车辆功能架构相同的组件（见图4a和4b），但仅保留实现协同功能所需的组件及其交互关系。例如，系统架构师的一个设计决策是：引导车的车辆控制功能单元向跟驰车传输信息，而非引导车与跟驰车之间直接传输传感器信息。因此，在引导车的协同功能架构中，传感器抽象层和传感器融合层的功能组件未用于协同驾驶功能；同时，由于引导车为人工驾驶，这些组件也未用于引导车自身的驾驶功能。因此，在协同功能架构的引导车模块中，未展示这些组件（见图4b顶部的引导车模块）。

4.3.5 安全分析

最后，通过故障树分析（FTA）将安全目标映射到功能架构，从而推导得出FSRs。该分析过程从车辆视角生成16个FSRs，从协同视角生成15个FSRs，总计31个FSRs。图5展示了每个功能组件对应的FSRs数量，表2第二列列出了部分FSRs示例。

图5：31个FSR，按相关功能组件分组。每组的总FSR显示在每个堆叠条的末尾

堆叠条形图末端的数值表示每个分组的FSRs总数；深色部分代表未满足的 FSRs（车辆视角），浅色部分代表已满足的FSRs（车辆视角），深色斜线部分代表未满足的FSRs（车队视角），浅色斜线部分代表已满足的FSRs（车队视角）。

表2：i-CAVE演示车技术架构中已满足的FSRs示例（注：蓝色单元格中的FSRs源于协同（车队行驶）视角，其他FSRs源于车辆视角）

4.3.6 结果解读

在本案例研究中，依据ISO 26262开展的传统安全分析（车辆视角）生成16个安全目标，对应16个FSRs；而通过本文提出的扩展安全分析方法，额外生成9个安全目标和15个FSRs，最终总计得到25个安全目标和31个FSRs。

从车辆视角看，车辆控制组件对应的FSRs数量最多（6个）；从协同视角看，V2V通信组件对应的FSRs数量最多（5个）。另一个值得关注的现象是：大多数FSRs（31个中的17个，其中车辆视角12个、协同视角5个）的ASIL等级为D级，而安全目标中ASIL等级为D级的比例相对较低（25个中的7个，其中车辆视角6个、协同视角1个）。安全目标与FSRs之间的ASIL等级差异，源于多数FSRs与多个安全目标相关联，且FSRs会继承其所关联安全目标的最高ASIL等级。

与工业场景相比，本研究中FSRs的数量（25个安全目标对应31个FSRs）相对较少——在工业场景中，相同数量的安全目标通常对应超过100个FSRs。我们认为，FSRs数量较少与车辆功能架构的简化有关。例如，Serban等人提出的参考架构包含39个功能组件，而本研究使用的简化架构仅包含8个功能组件。

理论上，从两个视角推导的FSRs可能存在重叠（即同一FSR既源于车辆视角，也源于协同视角），但本案例研究未发现此类重叠情况。

4.4 FSRs满足情况验证

所提方法第二部分（FSRs 满足情况验证）的步骤如图3所示，具体实施过程如下：

4.4.1 FSRs冲突检查

根据FSRs关联的功能架构组件对其进行分组。例如，有9个FSRs与车辆控制功能组件相关联，其中3个FSRs如表2所示（详见表2第三至五行，第一列和第二列）。图5展示了各功能组件关联的FSRs总数。在每个分组内，通过比对每对FSRs的描述来识别潜在冲突。结果显示，8个分组中均未发现冲突。

4.4.2 识别实现各FSRs所需的安全策略

为每个FSR确定一组适用安全策略。本文选择了13种安全策略，这些策略是15种最广泛使用的安全模式的核心，具体包括：简化（simplicity）、替换（substitution）、合理性检查（sanity check）、状态监测（condition monitoring）、比较（comparison）、多样性冗余（diverse redundancy）、复制冗余（replication redundancy）、修复（repair）、降级（degradation）、投票（voting）、覆盖（override）、屏障（barrier）和心跳（heartbeat）。

每种安全策略均有明确的目标和适用范围描述。例如，“简化”策略的目标是“通过尽可能简化系统来避免失效”，其描述为“简化可降低系统复杂性，包括采用结构化方法、剔除不必要功能、优化系统元素或仅保留核心安全功能，从而消除危害”。

4.4.3 各FSRs的适用安全策略匹配

通过将安全策略的目标和描述与FSR描述进行匹配，判断该策略的实现是否可满足FSR。表2列出了部分FSRs示例、与之匹配的安全策略及其在技术架构中的实现方式。表2还显示，列表中第一个FSR与“简化”策略不匹配（第三列未列出该策略），这是因为环境感知传感器本身具有固有的复杂性。

4.4.4 技术架构中安全策略的实现检查

最后，通过分析i-CAVE演示车技术架构中关联功能组件的实现情况，判断车辆架构是否满足FSR。i-CAVE演示车的技术架构基于MATLAB/Simulink实现，研究团队通过检 MATLAB代码和Simulink状态流图，识别功能架构组件及关联的安全管理系统，并将功能组件的实现与为每个FSR确定的安全策略进行映射，从而评估技术架构是否满足各FSR。表2列出了技术架构中已满足的FSRs、从适用策略中选择的应用策略，以及特定策略组合满足对应FSR的具体方式。此外，研究还发现了未满足的FSR示例，例如：“执行器（软件接口）发生失效时，不得将错误的控制信号传递给硬件执行器”。

图5展示了每个功能组件中，从车辆视角和车队视角分别推导的FSRs的满足与未满足数量。回顾第4.3节可知，从车辆视角和车队视角分别推导得出16个和15个FSRs，其中多数FSRs与车辆控制组件相关。在车辆视角的16个FSRs中，车辆技术架构仅满足3个，其余13个未满足；在协同视角的15个FSRs中，仅满足3个，其余12个未满足。研究团队将结果反馈给i-CAVE项目的四位系统架构师，他们确认i-CAVE演示车确实实现了已满足的FSRs，且未实现未满足的FSRs。针对i-CAVE演示车未满足的25个FSRs，研究团队提供了一组适用安全模式，可为技术架构的下一轮设计迭代提供参考。

4.4.5 结果解读

研究表明，i-CAVE演示车的技术架构仅满足31个FSRs中的6个（表2列出了所有已满足的FSRs）。本案例研究通过13种安全策略验证i-CAVE演示车是否满足FSRs，这些策略的选择基于其在15种最广泛使用的安全模式中的应用。理论上，由于仅考虑了13种策略，可能存在部分已满足的FSRs被误判为未满足的情况，但i-CAVE项目的架构师认可研究团队的判断，这表明分类结果具有准确性。

通过安全策略评估发现，协同视角的15个FSRs中有12个未满足；同时，车辆视角未满足的FSRs数量与协同视角相近。这一现象与i-CAVE演示车的硬件基础有关：i-CAVE演示车基于雷诺Twizy打造，该车型为极简设计的双座电动汽车，车身尺寸仅为2338毫米×1381毫米（可在自行车道行驶），总质量仅690公斤，最大续航里程仅51公里。相比之下，特斯拉入门级车型Model 3的尺寸约为其两倍，总质量约为其三倍，续航里程超过其十倍。因此，i-CAVE演示车的功能和组件存在局限性。此外，该演示车仍处于开发阶段，由跨领域团队逐步迭代开发，在本案例研究开展期间，技术架构的部分模块尚未实现，这导致车辆视角下部分FSRs被判定为未满足。演示车的后续迭代开发可参考车辆视角和协同视角下未满足的FSRs列表，进一步完善i-CAVE技术架构。

综上，本案例研究通过识别协同视角下未满足的FSRs，验证了所提方法的可行性和适用性。结果表明，与ISO 26262流程相比，所提方法通过补充额外FSRs，实现了对安全目标的更全面覆盖。当前基于ISO 26262标准的FSRs推导方法缺乏协同视角，而本研究为i-CAVE项目提供了有价值的见解——协同视角下的FSRs占总FSRs的48%（31个中的15个）。尽管本案例研究仅为方法的示例验证，仍需通过更多复现实验验证方法的通用性和可扩展性，但研究结果已与现有研究成果一致，证明当前安全标准确实遗漏了协同视角下的FSRs。

05. 讨论

本节将深入探讨所提方法的隐含假设，阐述该方法在实际协同驾驶场景中的应用潜力，并分析方法的可扩展性、通用性及适用范围。

5.1 隐含假设

所提方法借鉴了部分适用于单一车辆的假设，并将其扩展到协同驾驶场景。这些假设源于安全工程领域和软件架构领域，具体如下：

·功能分离假设：假设系统可实现合理的功能分离，确保每个FSR仅映射到一个功能组件。这种功能分离是安全工程领域的标准实践，已应用至少五十年，同时也得到汽车领域产品开发标准（ISO 26262）和汽车架构框架的支持。然而，该假设在协同驾驶场景中的适用性尚未得到验证。

·功能组件与技术架构映射假设：方法第二部分依赖两个假设：（1）功能组件可映射到技术软件架构的实现模块；（2）每个FSR可通过一组安全策略的组合来满足。第一个假设源于汽车领域的架构框架；第二个假设源于架构领域的认知——安全策略被视为设计基元，架构由设计基元的组合构成。成熟的架构评估方法（如ATAM）也依赖类似假设（尽管针对的是其关注的质量属性相关策略）。但这些假设在汽车领域的适用性尚未得到验证。

5.2 方法的适用性

本案例研究采用了简化的实际协同驾驶用例，而在实际应用中，所提方法需应对更大规模的系统，并适用于包含多种实体的协同驾驶系统。影响方法可扩展性和通用性的潜在因素包括：系统复杂性、参与系统的异质性（如不同类型车辆（轿车、卡车）或不同制造商的车辆），以及除车辆外其他实体（如云端）的纳入（用于实现协同驾驶功能）。

5.2.1 可扩展性

所提方法具有模块化特性，可适用于复杂系统。方法在架构层面采用两级抽象：功能架构视图通过功能分离确保每个组件执行唯一功能，且组件组合实现协同驾驶功能，这使得协同驾驶功能的安全需求可分配到单个车辆组件，无需涉及组件的实现细节；在方法第二部分，针对每个组件的FSRs需结合其实现细节进行评估。通过将每个组件的安全需求分离并单独处理，确保方法可适用于复杂系统。

5.2.2 异质性

功能架构视图作为“黑箱”，将功能组件及其交互关系与实现细节分离，使得方法不受车辆类型和品牌的限制。因此，只要提供参与实体的功能架构，该方法即可评估包含不同类型车辆（如同时包含卡车和轿车的车队）或不同汽车品牌（如同时包含宝马和通用汽车的车队）的协同驾驶系统的安全性。

5.2.3 非车辆实体的纳入

实现协同驾驶功能的实体可能不限于参与车辆，例如云端通信实体。方法第一阶段中专门引入的协同架构和对应“项”定义，可确保安全分析系统地涵盖所有参与协同功能实现的实体。例如，在包含云端通信的用例中，云端可作为协同架构的一部分纳入分析。

5.2.4 故障运行（Fail-Operational）与故障安全（Fail-Safe）设计

所提方法适用于各类协同系统，不受其运行设计领域限制，无论系统采用故障运行设计还是故障安全设计。该方法具有通用性，可同时覆盖两种设计类型，且在推导FSRs时兼顾协同视角和车辆视角。

06. 有效性威胁

所提方法及案例研究结果可能受到人为因素和技术选择的影响，存在有效性威胁。本节将阐述潜在威胁及相应缓解措施。

6.1 认知偏差

所提方法及案例研究的多个步骤依赖架构师的专家意见，这一过程可能因人为判断引入认知偏差。为缓解这一威胁，对于所有需人为判断的步骤，研究团队均咨询了至少三名专家，且专家需独立完成相关工作。例如：（1）协同功能架构由四位专业系统架构师基于车辆架构和场景描述独立构建；（2）两位作者独立检查FSRs之间的冲突；（3）安全目标的有效性依赖于场景描述到功能的分解结果，第三位作者（在功能安全领域拥有五年以上行业经验，参与过汽车行业功能安全标准ISO 26262和ISO 21448的制定）对场景描述的功能分解结果进行了验证。

6.2 技术偏差

在FSRs生成过程中，研究团队选择故障树分析作为安全分析技术。若选择其他技术（如失效模式与影响分析），可能导致结果差异。需通过实证研究验证安全分析技术的选择是否会对研究结果产生影响。

6.3 安全策略选择偏差

案例研究中，研究团队通过13种安全策略验证i-CAVE演示车是否满足FSRs。这些策略的选择基于其在15种最广泛使用的安全模式中的应用。但该安全策略列表并非详尽无遗，其范围限定了案例研究的分析边界。

07. 未来研究方向

本文是协同驾驶功能安全评估领域的初步探索，以下为潜在的未来研究方向：

7.1 功能安全与网络安全的协同考量

网络安全是协同驾驶领域需与功能安全协同探索的重要方向。协同驾驶的联网特性增加了潜在攻击面，可能危及系统功能安全。因此，将功能安全与网络安全整合的一体化方法是未来潜在研究方向。

7.2 硬件拓扑的纳入

功能安全通常通过硬件架构或软硬件结合的方式实现，但本文方法第二部分仅聚焦软件层面。未来可扩展该部分内容，以覆盖专门通过硬件拓扑或软硬件结合方式满足的FSRs，这是所提方法的合理延伸方向。

7.3 安全策略的ASIL等级关联

当前安全策略未与ASIL等级关联，导致仅能判断某一策略是否可满足FSR，而无法判断其是否能以特定ASIL等级满足FSR。未来可探索为安全策略添加ASIL等级属性，这一研究方向可支持基于风险的FSRs优先级排序，还可为需求权衡分析提供基础（即基于风险对FSRs与其他需求进行权衡）。

7.4 其他架构抽象层级的探索

当前方法第二部分（FSRs满足情况验证）采用技术架构视图。未来可探索采用比技术架构视图更高层级的架构抽象开展验证，并评估其可行性与有效性。

此外，本文方法通过调整现有解决方案以应对协同驾驶场景的功能安全问题，未来还可探索验证未满足FSRs的替代方法，这也是一个具有研究价值的方向。

08. 结论

本文研究了单一车辆架构是否满足协同驾驶功能安全需求，提出一种确保汽车架构在特定场景下具备功能安全性的方法。该方法可推导协同驾驶场景下的功能安全需求（FSRs），并验证车辆技术架构是否满足这些要求，其核心是整合安全工程与软件架构领域的现有方法。

通过将该方法应用于车队行驶这一协同驾驶场景的实际学术原型（i-CAVE演示车），研究团队识别出软件架构未满足的FSRs。该方法的设计动机及研究结果均表明，功能安全不应是汽车架构设计的事后考量，而应作为汽车系统架构定义的核心依据。