摘要：本文研究协同自动驾驶车辆系统的功能安全问题。为制定合理的功能安全分析方法，本文以ISO 26262标准为基础。由于ISO 26262标准是针对单车系统制定的，因此本文对该标准中描述的概念阶段进行了调整，使其适用于协同车辆系统。最终形成的功能安全分析方法从两个不同视角展开：车辆视角和协同视角。本文将该功能安全分析方法应用于i-CAVE项目的软件架构中，i-CAVE是一个研发协同双模自动运输系统的研究项目。分析结果表明，i-CAVE软件架构中已部分实现了功能安全。为进一步完善i-CAVE软件架构中的功能安全设计，本文提出以架构组件的形式增加安全机制，以解决功能安全相关问题。
原文作者：Rood,Niels
原文标题：Functional safety analysis and safety pattern application on i-CAVE
编译：猿东东，猿西西
安全一直是道路车辆关注的重要问题。在道路车辆的全生命周期中，人们不断增加各类安全功能以提升乘客的安全性。在法规层面，限速规定确保驾驶员能够对潜在的道路危险做出反应；道路基础设施中设置了交通信号灯，告知道路使用者何时可以安全通过交叉口，同时道路标志和标线提示驾驶员需要注意的事项；车辆本身也配备了安全气囊和安全带，其作用是在任何情况下最大限度地保障乘客安全。 近年来，车辆中软件的使用量大幅增加。除了多媒体和导航系统中的大量软件外，软件对车辆驾驶功能的控制也日益增强。自适应巡航控制、车道保持辅助和自动紧急制动等功能已逐渐普及到主流道路车辆中。这一发展使得汽车软件成为潜在的安全隐患，因为驾驶责任正从人类驾驶员转移到软件驱动的组件上。随着车辆自动驾驶等级的提高，这种责任转移将愈发明显。这种转移带来的安全问题已经显现，一些搭载高级自动驾驶功能的车辆因软件缺陷发生了致命事故。如今，车辆软件开始对乘客及车辆周边环境的安全负责，因此在这类软件的开发过程中必须充分考虑安全问题。
协同车辆系统是近期的研究热点。协同车辆系统的核心思想是车辆之间能够交换信息，从而实现多车协同行为。队列行驶就是一种典型的协同行为，多辆车以编队形式行驶。集成协同自动驾驶车辆（i-CAVE）项目旨在解决队列行驶车辆系统设计与开发中的相关挑战。该项目的目标是构建一个能够动态组建队列的车辆系统。在队列中，头车由驾驶员控制，后续车辆自动跟随前车行驶。从安全角度来看，ISO 26262等标准已经定义了如何在单车的全生命周期中融入功能安全设计。然而，随着车辆软件功能的不断升级，尤其是车辆开始实现协同运行，这些标准已无法直接适用。ISO 26262采用单车视角，并假设系统发生故障时驾驶员始终能够接管控制。标准的这些特性使其与自动驾驶车辆或i-CAVE这类协同车辆系统不兼容。 为了妥善解决协同车辆系统的功能安全问题，需要对ISO 26262安全分析方法进行扩展，使其能够覆盖这类协同系统。因此，本文以i-CAVE项目为研究对象，从协同车辆视角探讨功能安全问题。
首先，分析i-CAVE软件架构，明确其当前的安全实现情况；然后，扩展ISO 26262功能安全分析方法，使其能够应用于i-CAVE这类协同车辆系统；最后，将安全分析结果与i-CAVE软件架构中的功能安全实现进行对比，找出软件架构的改进方向。本文将解决以下研究问题：
RQ1 i-CAVE项目软件架构中功能安全的当前实现状态如何？
RQ2 如何将ISO 26262的功能安全分析方法应用于协同车辆系统？
RQ3如何利用i-CAVE软件架构的功能安全分析结果改进其软件架构？
2.1 软件架构
如前所述，本文聚焦于软件架构的安全分析。软件架构是一组可用于对系统进行推理的结构（包括软件元素及其关系）。软件架构可用于指导系统内软件的开发。设计良好的软件架构是开发优质软件的关键。但什么样的软件架构才算好呢？2.1.1节介绍软件架构中质量属性的考量方式，2.1.2节说明这些概念如何应用于安全领域。
2.1.1 软件架构中的质量考量
在任何软件项目中，最终产品或系统的不同方面都存在多种需求，这些需求来自不同的利益相关者，他们对系统有着不同的期望。系统最基本的需求是其预期功能（系统应该做什么？），同时还存在可用性、安全性、可靠性或安全性等方面的需求，这些构成了系统的质量要求。这些质量要求可在架构中通过质量属性来体现。质量属性是系统的可测量特性，描述了架构满足利益相关者需求的程度。 为了实现特定的质量属性，架构师可以使用架构策略。架构策略是针对单一质量属性的架构设计决策，系统设计是这些设计决策的集合。因此，架构策略可被视为架构设计的“构建块”。例如，针对可用性质量属性的监控策略，用于监控架构中组件的状态。 在软件架构中处理质量属性的一种更具体方法是使用架构模式。架构模式是架构元素的组合，用于在特定上下文中解决特定问题。这些模式是软件复用的一种形式：模式描述了一种已被证明能够解决特定问题的架构元素组合方式。它们经过了完善的文档化，以便其他开发者在遇到相同问题时能够复用。模式的定义始终包含上下文、所解决的问题以及所应用解决方案的架构描述。解决方案通常是多个设计决策的组合，在给定的上下文中解决相应问题。由于架构策略是单一的设计决策，因此架构模式是对架构策略的封装。例如，分层模式使用封装策略来降低耦合度，从而提高系统的可修改性。与策略不同，模式包含不同质量属性之间的权衡，这些权衡通过解决方案的文档化被固有地包含在模式的解决方案中。模式与质量属性之间的确切关系仍有待进一步探索，尤其是在模式组合使用的情况下。
2.1.2 软件工程中的安全
如上一节所述，安全是系统及其架构的一个质量属性。关于安全有多种定义。 Bass等人将软件安全定义为“软件避免进入可能导致或造成软件环境中参与者损害、受伤或生命损失的状态，并在进入此类不良状态时能够恢复并限制损害的能力”。在ISO 26262中，安全被定义为“不存在不合理的风险”，其中风险是“伤害发生概率与伤害严重程度的组合”。这两种定义都强调，在考虑安全问题时，软件的环境至关重要：只有当软件开始影响系统的其他部分或其环境时，才会成为潜在的安全问题，因为安全的核心是防止系统对人员造成损害或伤害。因此，在对软件进行安全分析时，必须结合其上下文进行考量。ISO 26262对安全的定义过于模糊，无法直接应用于软件：它完全没有提及不合理风险的来源。该标准还使用了“功能安全”这一术语，定义为“不存在因电气/电子（E/E）系统故障行为导致的危害所产生的不合理风险”。该定义明确了电气或电子系统故障是伤害的来源，其中包括软件运行所依赖的可编程电子系统。因此，在后续讨论软件故障相关的安全问题时，本文将使用“功能安全”这一术语。 尽管软件本身不会产生安全问题，但仍可能存在与安全相关的软件策略，以及应用这些策略的软件模式。事实上，文献中已经定义了专用的安全策略和安全模式。此外，还可以通过软件架构提升系统的功能安全。如果系统设计合理，在后续开发过程中融入功能安全设计会更加容易。为了便于功能安全的集成，软件应具有良好的可理解性。提升可追溯性和可审查性等质量属性，有助于开发者明确软件各部分应执行的功能。在架构设计阶段，高内聚（组件内容之间的强关联性、一致性）和低耦合（组件之间的弱关联性、少依赖）有助于功能安全的集成，同时应尽可能减小软件组件的规模，并采用分层结构对功能进行分解。
2.2 ISO 26262标准
ISO 26262是规定汽车项目功能安全管理全生命周期的标准，是IEC 61508在汽车行业的适配版本。该标准描述了如何在产品的全生命周期（从概念形成到开发）中融入功能安全设计。由于本文不涉及产品开发，因此重点关注标准的概念阶段。ISO 26262的概念阶段分为三个步骤。首先，根据所需功能编制系统定义，即“项定义”，它是后续所有分析的基础。所定义的项始终是车辆或车辆的某个组件。概念阶段的第二部分是危害分析与风险评估（HARA），用于探索系统及其环境的危害空间。基于项定义中确定的所需功能，编制潜在危害清单。对这些危害进行进一步扩展，最终形成功能安全目标清单。这些目标描述了保障待开发系统安全的最终目标。所有功能安全目标均根据相关危害的严重程度、人员可控性和暴露概率，划分汽车安全完整性等级（ASIL）。概念阶段的最后一步是制定功能安全概念，将功能安全目标映射到架构中。为此，通过制定功能安全需求，将功能安全目标分配给物理、电气/电子（E/E）或软件组件。功能安全需求是针对架构组件提出的、用于实现功能安全目标的要求。可以使用故障树分析（FTA）生成功能安全需求，故障树分析通过故障树探索不同组件的故障如何影响功能安全目标。为指导开发工作，在HARA阶段分配给功能安全目标的ASIL等级，将由相关的功能安全需求继承，进而由架构中应用这些功能安全需求的组件继承。还可以在软件架构中以安全机制的形式添加安全措施，以预防或降低组件故障的影响。安全机制是为实现功能安全需求而添加到架构中的组件。图2.1展示了ISO 26262过程的概念和开发阶段及步骤概述。
图2.1：ISO 26262流程的概念阶段与开发阶段及步骤概述
2.3 i-CAVE项目
集成协同自动驾驶车辆（i-CAVE）项目是一个研究项目，旨在解决协同双模自动运输（C-DMAT）系统设计与开发中的相关挑战。它是iGAME项目的延续，iGAME是一个关于自动驾驶通信车辆开发的国际项目。在C-DMAT系统中，车辆可根据需求在手动驾驶和自主协同驾驶模式之间切换。这类系统有多种潜在用例，i-CAVE项目重点研究队列行驶用例，即车辆在高速公路上动态组成“列车”，头车仍由驾驶员控制，队列中的其他车辆自动跟随前车行驶。i-CAVE项目由多个子项目组成，每个子项目聚焦于系统的不同方面。其中一个工作组负责开发演示平台，为雷诺Twizy车辆加装额外的传感器和执行器，用于展示其他工作组的研究成果。该演示平台还包含完整的软件栈及软件架构。本文选择i-CAVE项目作为案例研究，是因为它提供了完整的研究图景：不仅有完整的架构，还有可供分析的队列行驶用例。此外，该项目仍在开发中，可以进行调整以融入更多安全功能。第3章将详细介绍i-CAVE的软件架构，第4章将概述分析方法及其在这些架构上的应用结果。
2.3.1 队列行驶场景描述
本节详细描述i-CAVE项目中使用的队列行驶场景。在队列行驶场景中，两辆或多辆车辆组成“车辆列车”（即队列），最前方的车辆由驾驶员控制，所有后续车辆自动跟随前车行驶。车辆通过车对车（V2V）通信信道协同组建队列，V2V通信信道还用于车辆之间传递信息，以优化队列内的车距。 在队列的生命周期内，可能发生以下子场景：
·组建与解散：队列可以组建或解散。队列的生命周期从组建开始，到解散结束。
·扩容与缩容：当车辆加入或离开队列时，队列分别实现扩容或缩容。只要结果仍构成队列（即至少包含两辆车），车辆可随时加入或离开。当一辆车离开仅有两辆车的队列时，队列解散。加入和离开操作由加入或离开车辆的驾驶员手动执行。
·队列拆分：一个队列可拆分为两个队列。拆分后的两组车辆必须均为有效队列（包含两辆或多辆车辆），否则该操作实际为车辆离开。若需拆分为两个以上队列，可通过多次双向拆分实现。
·队列合并：两个相邻的队列可以合并。若需合并两个以上队列，可通过多次双向合并实现。在合并过程中，被合并队列的头车脱离原队列，加入合并目标队列；原被合并队列中头车的后车成为新的头车，重复该过程直至被合并队列完全并入目标队列。
·头车更换：在队列生命周期内，头车可以更换，方式包括头车离开队列或头车退入队列后部。当头车退入队列后部时，本质上是先离开队列，再从后方重新加入。
本章将详细阐述i-CAVE项目的软件架构。3.1节和3.2节分别概述i-CAVE项目使用的软件架构，其中3.1节聚焦于车辆视角，3.2节聚焦于队列视角。本章的主要目标是通过梳理i-CAVE软件架构中使用的不同组件及其功能安全实现方式，回答研究问题RQ1（i-CAVE项目软件架构中功能安全的当前实现状态如何？）。
3.1 车辆软件架构
本节介绍 i-CAVE 项目演示平台所使用的功能车辆架构。该软件架构基于Serban等人的研究成果，他们提出了一种基于SAE J3016标准的功能架构。SAE J3016标准定义了车辆驾驶自动化的多个等级，并给出了每个等级的功能定义。最终形成的架构如图3.1所示，包含多个层级，数据从传感器流向控制层，再流向执行器。i-CAVE车辆软件架构采用了与塞尔班等人提出的架构相同的分层原则。i-CAVE项目的车辆软件架构基于MATLAB实现，其整体结构如图3.2所示。架构分为多个层级，信息总体上从左至右流动，即从传感器流向执行器。组件之间的通信通过MATLAB的Goto和From元素实现，这是一种松耦合的通信方式。除了感知-控制-执行层外，还设有安全层，负责监控其他层级，确保系统始终处于安全状态。架构还包含用户输入层和用户输出层，通过控制面板提供输入和输出功能，该控制面板用于调试和用户交互。本节后续部分将详细介绍各个层级及其包含的组件。
图3.1：提出的自动驾驶车辆功能架构，为i-CAVE演示子项目的软件架构提供了设计灵感
3.1.1 输入接口层
输入接口层包含所有读取物理传感器输入，并将其转换为后续层级可用信息的软件组件。传感器通过CAN总线连接到主计算单元，各CAN总线的用途如下：
·V-CAN：V-CAN总线是车辆原有的唯一CAN总线，连接Twizy车辆上所有原厂CAN组件：包括控制车辆主驱动电机的电力电子模块（PEB）、充放电过程中监控电池的电池管理系统（BMS）和电池充电盒（BCB），以及仪表板。
·C-CAN：C-CAN总线连接为实现车辆自动驾驶功能而加装的所有CAN传感器和执行器，包括加速、转向和制动执行器，以及惯性测量单元（IMU）等传感器。
·P-CAN：P-CAN总线连接所有感知传感器到主计算单元，如前向雷达和计算机视觉平台。
·I-CAN：I-CAN总线连接仪表硬件，仅用于调试目的。 输入接口层为每条CAN总线设置了对应的组件，负责将总线上的所有传入CAN消息转换为下游模块可用的数据类型。对于部分消息，这些 “-CAN输入”（C-CAN输入、V-CAN输入、P-CAN输入和I-CAN输入）组件还会在可用时通过校验和执行消息完整性检查。这些消息完整性检查本身就是一种安全机制，用于解决传感器输入相关的功能安全问题。 除了“-CAN输入”组件外，还有GPS组件和V2V输入组件。GPS组件处理来自GPS硬件的串行消息，并通过校验和执行数据完整性检查。V2V输入组件处理V2V通信信道上的所有传入消息，该组件与V2V输出组件共同实现了欧洲智能交通系统（ITS）协议栈的所有软件组件，使用标准化的消息集（CAM、DENM）进行通信。欧洲ITS协议栈的完整概述如图3.3所示。
图3.3：欧洲实现智能交通系统（ITS）所使用的不同标准概述
3.1.2 传感器层
传感器层将来自不同来源的数据融合，生成关于车辆及其周边环境的信息。主车跟踪组件结合GPS和惯性测量单元（IMU）数据，确定车辆在任意时刻的绝对位置。车辆状态估计器结合加速度计信息和其他车辆信息，估计车辆的动态状态。目标跟踪组件使用雷达和视觉信息检测车辆周边的物体和其他车辆。
3.1.3 控制层
控制层负责根据车辆及其周边环境的状态，生成适当的自动驾驶控制信号。该层包含多种自动驾驶控制模式：服务模式、自主模式和协同模式。服务控制模式用于通过调试控制面板测试自动驾驶控制功能。 自主模式和协同模式均为车辆自动驾驶控制模式，负责在车辆处于队列中时控制车辆跟随前车行驶。自主模式仅使用雷达和视觉信息生成合适的跟随控制信号，而协同模式还会结合V2V信息进一步优化这些控制信号。
3.1.4 执行器层
执行器层的软件组件对应车辆的不同物理运动系统：加速（驱动）、转向和制动。每个物理系统对应的组件负责选择合适的控制信号源。除了控制层的不同自动驾驶控制模式外，执行器层组件还可选择手动控制模式，此时车辆驾驶员完全控制该物理运动系统。目前，控制信号源的选择由安全层中的监控器组件完成。该组件结合控制面板的输入和所需组件的状态信息，确定当前应使用的控制模式。
3.1.5 输出接口层
输出接口层接收来自前序层级、发往物理执行器的MATLAB消息，并将其打包为 CAN 消息，通过不同的CAN总线发送给物理组件。输出接口层的软件组件与输入接口层类似，按CAN总线分组。仅当物理组件被安全层“启用”时（即安全层根据车辆状态决定是否应向该物理组件发送命令），软件组件才会向其发送相关消息。
3.1.6 安全层
安全层的组件负责监控所有其他组件，并通过操作其他组件确保系统处于安全状态。为实现这一功能，安全层包含监控组件和监控器组件。传感器监控和执行器监控组件从CAN总线获取信息，生成车辆中不同传感器和执行器的状态概览。该状态概览包括传感器和执行器的错误消息，以及对传感器和执行器值的分析，以检测传感器或执行器故障及驾驶员干预。监控组件的所有状态信息都会传递给监控器组件，监控器组件通过状态转换系统确定控制层应采用的合适控制模式。 安全层的所有组件均作为与其交互的其他层级组件的安全机制。但这些组件并非基于（功能）安全分析设计。
3.2 队列软件架构
车辆软件架构仅展示了部分图景，虽然它包含了车辆与其他车辆协同所需的组件，但并未展示车辆之间的实际交互。为形成完整的分析视图，本文基于队列行驶用例及其需求，构建了独立的队列软件架构，如图3.4所示。该队列软件架构与车辆软件架构描述的是同一车辆系统，但处于更高的抽象层级：车辆架构展示了车辆内部各层级的组件，而队列架构展示了队列中车辆的层级划分。队列架构的引入，清晰呈现了队列中不同角色对应的活跃层级，以及车辆在功能层面的协同工作方式。
图3.4：i-CAVE项目的队列软件架构。图中展示了一辆头车（紫色）和两辆跟随车（深灰色）。浅灰色组件表示在所示角色下未用于车辆控制的组件，其连接用虚线箭头表示
在队列软件架构中，每辆车均包含感知、控制和执行组件，以及V2V输入和V2V输出组件。感知组件对应车辆架构的输入接口层和传感器层，控制组件对应控制层，执行组件对应执行器层和输出接口层。需要注意的是，V2V输入和V2V输出被单独列出，因为它们在车辆协同中扮演着重要角色：展示了协同过程中数据在车辆之间的流向，以及V2V数据在车辆内部的源和目标。如图3.4所示，图中展示的数据流仅表示数据的使用方式；在物理层面，数据采用广播方式发送，通信范围内的所有车辆均可接收。但在队列行驶示例中，车辆仅关注前车的信息，以保持合适的跟车距离。在安全分析中，假设i-CAVE车辆使用欧洲ITS协议栈进行通信，这与iGAME项目所使用的协议栈一致。
3.3 总结与结论
i-CAVE软件架构是一种分层软件架构，用于实现i-CAVE演示车辆的功能。该软件架构的开发重点是实现2.3.1节所述队列行驶场景所需的功能。队列中多辆车协同工作，但这一点并未在i-CAVE原软件架构中直接体现。因此，本文为研究目的构建了额外的队列软件架构，突出了车辆协同工作时的角色和交互方式。 为回答研究问题RQ1（i-CAVE项目软件架构中功能安全的当前实现状态如何？），可以得出：i-CAVE软件架构包含一些专注于监控其他架构组件的安全机制：“-CAN输入”组件通过校验和执行消息完整性检查，以应对传感器故障或信息损坏问题；安全层监控和管理通过不同CAN总线传入和传出的消息，并根据传入消息确定应激活的运行模式及自动驾驶控制系统。 尽管存在这些安全机制，但队列行驶场景和i-CAVE软件架构均未经过正式的功能安全分析。这意味着目前尚未为队列行驶场景制定潜在危害的正式定义，也无法确定已实现的安全机制覆盖了多少潜在危害。这两个结论凸显了对i-CAVE项目进行合理功能安全分析的必要性。第4章将提出一种可应用于i-CAVE这类协同系统的功能安全分析方法，第5章将展示该分析方法在i-CAVE项目中的应用结果。
本章将解决研究问题RQ2（如何将ISO 26262的功能安全分析方法应用于协同车辆系统？）。本文在A.K.Saberi等人研究成果的基础上进行扩展。他们初步提出了将ISO 26262标准扩展应用于协同车辆系统的方法，而ISO 26262标准最初是为单车设计的。本文对ISO 26262的概念阶段进行扩展，使其适用于协同驾驶场景，并以队列行驶场景为完整案例进行研究。
本文仅探讨ISO 26262标准的概念阶段，因为标准的其余部分旨在解决车辆系统实际实施过程中的安全问题。 本章所述的功能安全分析方法涵盖ISO 26262概念阶段的所有步骤：项定义、危害分析与风险评估（HARA）和功能安全概念，如2.2节所述。该分析方法的两个主要输入是场景和软件架构。软件架构需从以下两个视角定义：仅考虑单一车辆的车辆视角，以及考虑多车协同工作的协同视角。在分析过程中，将分别从这两个视角执行ISO 26262概念阶段的每个步骤。 本章将以队列的“扩容”子场景为运行示例，为功能安全分析方法的各个步骤提供上下文说明。 该功能安全分析方法将产生多项结果。首先，功能安全分析将探索与给定场景相关的潜在危害；其次，生成功能安全需求，即针对软件架构中组件提出的、用于解决这些潜在安全危害的要求；此外，作为功能安全分析的一部分，还将生成安全机制，即添加到软件架构中以实现这些功能安全需求的组件。本章后续部分将概述功能安全分析方法的各个步骤，整个流程的概览如图A所示。
4.1 项定义
与ISO 26262标准中描述的功能安全分析方法相同，本文提出的功能安全分析也从项定义开始。项定义的输入是待分析系统可能处于的不同场景的定义。场景可分解为多个运行模式和运行工况：运行模式定义了系统在场景中的运行方式，运行工况定义了场景中系统周边环境的可能状态。例如，运行示例中的“扩容”子场景可直接作为“扩容”运行模式，而该运行模式对应的运行工况可以是“在高速公路上”，因为队列通常行驶在高速公路上。从运行模式中可推导出一组所需功能，这些功能基于车辆或队列在每种运行模式下应具备的能力确定。功能与运行模式并非一一对应关系：一个功能可能与多个运行模式相关。在定义功能时，遵循的原则是找出特定运行模式所需的功能。在“扩容”运行模式的上下文中，队列应具备“为加入队列的车辆腾出空间”的功能，该功能同样适用于队列的“合并”运行模式，因为合并目标队列需要为合并队列中的所有车辆腾出空间。 图4.1展示了项定义过程中的信息流。运行工况和功能定义的组合构成了下一步危害分析与风险评估的基础。
图4.1：功能安全分析方法项定义阶段的数据流和步骤。椭圆表示不同的（中间）结果集，箭头表示用于生成其他（中间）结果的中间结果。车辆相关信息用绿色标注，协同相关信息用黄色标注，与两个过程均相关的信息用蓝色标注
4.2 危害分析与风险评估
功能安全分析的下一步是危害分析与风险评估（HARA）。本章开头提到的两个视角（车辆视角和队列视角）将分别执行完整的HARA。HARA的不同步骤及信息流如图4.2所示。HARA的第一步是将项定义中的功能与引导词结合，系统地生成危害清单。本文功能安全分析选用的引导词包括：无、过多、过少、部分、以及、反向和非预期。这些引导词提供了一种系统的方法，用于发现功能失效并转化为危害的方式。例如，在运行示例中，队列功能“为加入队列的车辆腾出空间”与引导词“无”结合，生成危害“队列未为加入的车辆腾出空间”。通过这种方法，分别从车辆视角和协同视角生成潜在危害清单。HARA的下一步是通过分析与危害相关的每种运行模式和运行工况的组合，将一个危害分解为多个危害事件。每个危害事件代表一个可能出现问题的具体场景。针对每个危害事件，制定对应的功能安全目标。功能安全目标是致力于预防某一危害事件的最终目标。
同时，还需为危害事件补充暴露概率、事件造成伤害的严重程度以及人员对事件的可控性信息。危害事件的暴露等级直接由其对应的运行模式和运行工况推导得出：对于每对运行模式和运行工况，估算车辆或队列处于该模式和工况的频率和时长，该估算基于ISO 26262中基于时长的暴露定义。可控性和严重程度也根据ISO 26262的定义确定，在确定危害事件的可控性和严重程度时，还需考虑相关危害本身。暴露、可控性和严重程度得分组合形成汽车安全完整性等级（ASIL）。每个危害事件及其对应的功能安全目标都会被分配一个ASIL等级。功能安全目标的ASIL等级表明了在后续开发阶段实现该目标的重要程度。在运行示例中，危害“队列未为加入的车辆腾出空间”与运行工况“高速公路”结合，生成危害事件“队列在高速公路上行驶时，未为加入的车辆腾出空间”，对应的功能安全目标为“队列在高速公路上行驶时，应为加入的车辆腾出空间”。该运行示例考虑“合并”运行模式，因此该危害事件可能在两个队列合并时发生。尽管这类事件可能定期发生，但队列合并的时间占队列总生命周期的比例不超过10%，因此为该危害事件分配暴露等级E3。当危害事件发生时，只有加入车辆处于人工控制状态，队列中的所有其他车辆均由软件控制，其“驾驶员”无法控制局面，因此为该危害事件分配可控性等级C3。最后，如果危害事件发生并造成伤害，由于事件发生在高速公路行驶速度下，可能导致危及生命的后果，因此分配严重程度等级S3。
综合暴露、可控性和严重程度等级，为危害事件“队列在高速公路上行驶时，未为加入的车辆腾出空间”及其对应的功能安全目标“队列在高速公路上行驶时，应为加入的车辆腾出空间”分配ASIL C等级。 在进入下一步之前，将高度相似的功能安全目标合并为聚合功能安全目标。功能安全目标的聚合可避免后续步骤中的不必要工作。聚合功能安全目标继承其所有原始功能安全目标中的最高 ASIL 等级：例如，如果一个聚合功能安全目标同时来自ASIL A和ASIL C的功能安全目标，则该聚合功能安全目标的等级为ASIL C。生成的带有对应ASIL等级的聚合功能安全目标将用于制定功能安全概念。
图4.2:功能分析方法危害分析与风险评估（HARA）阶段的数据流与执行步骤。方框代表流程步骤，椭圆代表各类（中间）结果集，箭头表示各步骤中中间结果的调用关系。车辆相关信息用绿色标注，协同相关信息用黄色标注，同时适用于两类流程的信息用蓝色标注
4.3 功能安全概念
功能安全概念是功能安全分析的最后一步。在这一步骤中，将HARA生成的功能安全目标映射到i-CAVE软件架构中。功能安全概念步骤的概览如图4.4所示。 在开始功能安全概念步骤之前，还需执行一项操作，以建立功能安全目标与架构组件之间的关联：此时，所分析的场景与待分析的软件架构之间尚无明确关系。为实现这种关联，将项定义中生成的功能直接映射到软件架构的组件上，每个功能对应一组软件架构组件。由于功能安全目标是从功能推导而来的，因此功能安全目标也可与软件架构组件建立关联。 在分析现有软件架构时，架构中可能已包含一些与安全相关的组件。在这种情况下，将这些组件映射到功能可能并不合适甚至不可行，因为这类组件的用途完全基于安全，与项定义中定义的功能无关。因此，现有的与安全相关的组件不纳入功能安全概念的前几步分析，而是在后续确定软件架构潜在安全机制的过程中再予以考虑。
在功能安全概念步骤中，将HARA生成的功能安全目标分配给待分析的软件架构。为实现这一分配，针对每个功能安全目标执行故障树分析（FTA），以生成功能安全需求。在针对某一功能安全目标的FTA过程中，构建树状结构，可视化展示不同组件与该功能安全目标的关联方式。树的叶子节点包含所有与该功能安全目标相关的单个组件。然后，分析每个组件可能发生的、导致根节点功能安全目标被违反的故障方式，并将这些组件故障转化为对应组件的功能安全需求。例如，组件故障描述为“组件A停止提供关于X的信息”，对应的功能安全需求为“组件A不应停止提供关于X的信息”。
功能安全需求也会根据其来源的功能安全目标被分配ASIL等级。一个功能安全需求可能与多个功能安全目标相关，因为一个组件故障可能影响多个功能安全目标。功能安全需求继承其所有相关功能安全目标中的最高ASIL等级。以之前确定的功能安全目标“队列在高速公路上行驶时，应为加入的车辆腾出空间”为例，该功能安全目标与队列级软件架构中的跟随车相关，因为队列中的跟随车负责为加入车辆腾出空间。在跟随车内部，控制组件负责控制跟随车为加入车辆腾出空间，V2V输入组件负责接收关于加入车辆加入流程的传入消息。基于这些组件角色分配执行FTA，生成的故障树如图4.3所示。
图4.3：针对功能安全目标“队列在高速公路行驶时，应为加入队列的车辆腾出空间”开展故障树分析（FTA）后得到的故障树。故障树中绿色叶节点代表故障树分析生成的各项功能安全需求。图中使用“或”符号表示跟随车功能依赖于控制组件功能与车车通信（V2V）组件功能，即控制组件或车车通信组件任意一方发生失效，都会造成跟随车出现故障
图4.4：功能安全分析中功能安全概念阶段的数据流与执行步骤。方框代表流程步骤，椭圆代表各类（中间）结果集，箭头表示各步骤中中间结果的调用关系。车辆相关信息用绿色标注，协同相关信息用黄色标注，同时适用于两类流程的信息用蓝色标注
除功能安全需求外，功能安全概念还包含安全机制。根据ISO 26262标准，安全机制是指“检测并缓解或容忍故障，或控制并避免失效，以维持预期功能或实现并维持安全状态”的组件。这类安全机制有两个来源：一是原始软件架构中在之前分析步骤中被排除的与安全相关的组件；二是通过应用架构安全模式生成的额外组件。
本文采用两步法，为每个功能安全需求系统地生成潜在适用的架构安全模式清单。该三步法基于C. Preschern等人的安全模式系统，该系统提供了架构安全模式体系，包括每个模式所应用的策略。第一步，将架构安全模式系统中使用的完整策略列表与功能安全需求列表进行对比，确定每对策略和要求中，应用该策略是否能够解决该要求。第一步的结果是每个功能安全需求对应的适用策略列表。在为每个功能安全需求找到适用策略列表后，下一步将这些列表与C. Preschern等人的架构安全模式系统中的模式进行自动对比。架构安全模式系统提供了其包含的每个安全模式所使用的策略列表。当一个安全模式所使用的所有策略均适用于某一功能安全需求时，该安全模式本身也被视为可能适用于该功能安全需求。对所有功能安全需求执行该推理过程，生成每个功能安全需求对应的潜在适用架构安全模式清单。最后一步是针对每个要求选择安全模式，将其转化为安全机制，即可以添加到软件架构中以实现功能安全需求的组件。
部分安全模式可能已通过之前分析中排除的原始软件架构中的安全相关组件实现。如果并非所有功能安全需求都被现有软件架构组件覆盖，则通过在与这些要求相关的架构组件上应用安全模式，添加更多安全机制。为此，可以从潜在适用的安全模式中选择一种。为说明安全机制的生成过程，仍以运行示例中的功能安全需求“控制组件应始终正确控制跟随车，为加入车辆腾出空间”为例。对于该功能安全需求，应用异构冗余策略，实现控制组件的多个不同版本是合理的，这可以抵消某一实现版本故障导致车辆无法为加入车辆腾出空间的影响。同时可使用表决策略组合这些实现版本的输出。 假设有一种名为“多数组合”的安全模式，添加一个表决器组件，接收多个实现版本的输出，并输出多数输入提供的值。该安全模式同时使用了异构冗余策略和表决策略，因此适用于上述功能安全需求。通过引入控制组件的多个实现版本，并将其连接到新增的表决器组件，即可将该安全模式作为安全机制应用。
4.4 总结与结论
本章在 A.K. Saberi等人研究成果的基础上，提出了一种功能安全分析方法，可将ISO 26262功能安全分析应用于协同车辆系统。该方法包含两个并行的安全分析：一个从单车视角，一个从多车协同视角。本文提出的功能安全分析方法解答了研究问题RQ2（如何将ISO 26262的功能安全分析方法应用于协同车辆系统？），因为它提供了将ISO 26262标准中描述的功能安全分析方法应用于协同车辆系统的流程。
本章将解决研究问题RQ3：如何利用i-CAVE软件架构的功能安全分析结果改进其软件架构？为回答该问题，本文将第4章所述的安全分析方法应用于i-CAVE项目，以2.3.1节所述的队列行驶场景作为功能安全分析的起点，以3.1节和3.2节所述的软件架构作为待分析的车辆架构和协同架构。然后利用功能安全分析的执行结果回答RQ3。5.1节概述功能安全分析的执行过程，说明分析每个步骤中所做的决策、假设及其背后的理由。5.2节总结功能安全分析的结果，展示所有步骤的输出。项定义生成了车辆级和队列级功能，这些功能在HARA阶段用于生成功能安全目标，功能安全目标又在功能安全概念阶段使用。所有这些结果使读者能够理解整个功能安全分析的推理过程。
5.1 功能安全分析执行
如第3章所述，当前i-CAVE软件架构已通过安全层和传感器输入校验和融入了功能安全设计。这些组件将按照第4章功能安全分析方法描述中的方式，作为与安全相关的组件处理：在安全分析的最后阶段才予以考虑。 除这些与安全相关的组件外，还有一些组件因不参与队列行驶场景而未纳入分析。例如，车辆软件架构控制层中的协同组件是控制层中唯一适用于队列行驶场景的控制模式组件，该层的所有其他组件均完全排除在功能安全分析之外。图5.1展示了纳入分析的组件完整概览，表5.1说明了排除某些组件的理由。
图5.1：i-CAVE车辆软件架构，图中标示出纳入功能安全分析范围的组件。所有未纳入分析范围的组件均采用虚线外框与斜体字体标识
安全分析从4.1节所述的项定义开始。项定义的第一步是为2.3.1节所述的队列行驶场景定义运行模式和运行工况，分别从车辆视角和队列视角进行定义。 例如，从队列视角来看，队列可能位于高速公路上或高速公路之间的过渡路段；而从单车视角来看，车辆可能位于队列内部或外部。队列的运行模式与单车的运行模式不同但相互关联：例如，队列具有“扩容”运行模式，即因车辆加入而使队列规模增大；相应地，单车具有“加入队列”运行模式，即车辆（尝试）加入队列。定义完所有运行模式后，从中推导出功能。项定义中的功能是HARA的基础，在HARA阶段，这些功能的失效将被转化为功能安全目标。完成HARA后，在功能安全概念步骤中，将功能安全目标映射到i-CAVE软件架构（包括车辆架构和队列架构）。
如4.3节所述，第一步是将每个功能映射到一组软件架构组件。下一步是利用功能与软件架构组件的映射关系，对每个功能安全目标执行故障树分析（FTA）。对某一功能安全目标执行 FTA 生成的故障树示例如图5.2所示。按照第4章的功能安全分析方法，功能安全概念的最后一步是定义可应用于i-CAVE软件架构的安全机制。与安全分析的其他部分一样，安全机制也从车辆视角和队列视角分别定义。由于软件架构实际在车辆层面实现，因此为队列软件架构定义的安全机制需要映射到车辆软件架构中。图5.5展示了应用于队列软件架构的队列级安全机制，图5.6展示了应用于车辆软件架构的安全机制（已包含映射后的队列安全机制）。
图5.2：针对功能安全目标PG8开展故障树分析后得到的故障树。根节点蓝色方框代表该功能安全目标，其余蓝色方框代表队列软件架构内各组件对应此功能安全目标承担的功能角色。红色方框代表违背该功能安全目标、对应功能角色的失效或故障。故障树叶节点的绿色菱形框，对应故障树分析最终输出的功能安全要求。全树使用“或”符号表示失效的关联逻辑。例如：头车切换失效，可由头车自身失效或跟随车失效任意一方引发
图5.3：分配至i-CAVE车辆软件架构各组件的汽车安全完整性等级（ASIL）
图5.4：分配至i-CAVE队列软件架构各组件的汽车安全完整性等级（ASIL）。所有车辆的ASIL等级分配规则完全一致，因此图中仅展示单台车辆
图5.5：队列级安全机制总览，结合队列软件架构进行展示。所有红色组件代表以新增组件与连接接口形式实现的安全机制；这些组件同时标注了PSM编码，用于标识其归属的安全机制类型。所有灰色淡化的组件均为未做修改的原有模块。由于队列内所有车辆配置的新增安全机制完全一致，图中仅展示单台车辆
图5.6：车辆级安全机制总览，结合车辆软件架构进行展示。分配至i-CAVE软件架构原有安全相关组件的安全机制以绿色显示，本次新增引入的安全机制以红色显示；所有灰度淡化的组件均为未做任何修改的原有模块
5.2 功能安全分析结果
在功能安全分析过程中分配给功能安全需求的ASIL等级，也可以映射到其对应的软件架构组件上。图5.3和图5.4展示了所有被分析的软件架构组件的ASIL等级分配情况。需要注意的是，功能安全目标中最常见的ASIL等级是ASIL C和ASIL D，这一现象可由队列行驶用例的两个特性解释：首先，队列中除头车外的所有车辆均处于完全自动驾驶状态，因此无法假设在车辆或队列发生故障时，驾驶员有能力将车辆驾驶至安全状态，这导致整体人员可控性较低；其次，队列主要在高速公路速度下行驶，若车辆或队列失效导致碰撞，将产生较高的严重程度等级。
一个有趣的发现是，尽管功能安全目标的ASIL等级已经较高，但功能安全需求的ASIL等级更高。通过分析功能安全目标与功能安全需求之间的关系可以发现，这是因为大多数功能安全需求与多个不同的功能安全目标相关，而功能安全需求继承其所有相关功能安全目标中的最高ASIL等级。 如图5.6和表5.2所示，除了已有的安全层和传感器输入完整性检查外，还有大量潜在的安全机制可以提升 i-CAVE软件架构的安全集成度。例如，VSM7、VSM10和VSM19表明，可以为传感器解释组件和控制算法引入冗余。传入传感器数据的周期性特性使得可以引入看门狗机制，这体现在安全机制VSM3、VSM6、VSM18和PSM6中。安全机制PSM3和PSM4引入了车辆之间传感器信息对比的可能性。其中PSM4尤为重要，它提出了车辆之间的信息共享，这一结果正是由于在完整分析中加入了队列视角才得以发现。
归属于现有组件的安全机制大多是与监控相关的组件。VSM8和PSM8则有所不同，它们应用了恢复块模式，这是一种冗余模式，在组件主功能发生故障时提供故障安全功能。此外，还在安全层中添加了更多与监控相关的组件，以弥补某些组件监控能力的不足。
表5.2：i-CAVE车辆软件架构上的安全机制列表（包含队列视角和车辆视角的结果）
在将功能安全需求映射到现有安全相关组件时，对这些组件的潜在功能做出了假设：例如，截至本文撰写时，车辆级软件架构中的监控器组件并未提供明确的功能降级（当正常功能因故障无法维持时，降低功能级别）能力，但这种功能可以集成到该组件所采用的状态机中。另一个例子是车辆级软件架构中的传感器监控组件，目前不具备对比不同传感器相似信息的功能，而传感器对比功能可以增强该组件当前监控传感器值正确性的能力。
5.3 总结与结论
本章将第4章所述的功能安全分析方法应用于描述的i-CAVE项目。分析结果可用于回答研究问题RQ3：如何利用i-CAVE软件架构的功能安全分析结果改进其软件架构？功能安全分析产生的多项结果可用于i-CAVE软件架构的后续开发。首先，带有对应ASIL等级的功能安全需求可用于确定架构中安全开发的优先级。需要注意的是，大多数组件都与ASIL D级的功能安全需求相关，因此在实际应用中，ASIL等级对于优先级划分的作用有限。 功能安全分析更有价值的结果是安全机制。分析结果表明，原始i-CAVE软件架构已包含一些安全机制，能够解决分析中得出的部分功能安全目标，但并非所有功能安全需求都被现有安全机制覆盖，需要应用更多安全机制来实现这些要求。 在分析过程中，同时采用车辆视角和队列视角的方法，相比仅采用车辆视角获得了更多的见解：车辆视角为V2V输出组件分配了ASIL C等级，而队列视角为其分配了ASIL D等级。这一差异可以解释为：单车更关注对自身环境的感知，而非与环境共享信息；而在队列视角中，信息共享同样重要。两个视角在ASIL等级分配上的其他差异并不明显，这可能是因为大多数组件从车辆视角来看已被分配了ASIL D等级。此外，队列视角还引入了车辆之间额外的冗余可能性。
本文分析了i-CAVE项目所使用软件架构的功能安全。第3章通过阐述论文撰写前i-CAVE软件架构中功能安全的实现情况，回答了研究问题RQ1（i-CAVE项目软件架构中功能安全的当前实现状态如何？）。研究发现，i-CAVE软件架构的输入接口层和安全层均包含专注于监控和管理其他架构组件的安全机制，但i-CAVE软件架构和队列行驶场景均未经过正式的功能安全分析。为了能够合理分析 i-CAVE 项目这类协同车辆系统，第4章在A.K.Saberi等人研究成果的基础上，对 ISO 26262 功能安全分析方法进行了扩展，同时采用车辆视角和协同视角进行分析。该功能安全分析方法解答了研究问题 RQ2（如何将ISO 26262的功能安全分析方法应用于协同车辆系统？）。第5章将第4章所述的功能安全分析方法应用于i-CAVE项目，生成了针对i-CAVE软件架构组件的功能安全需求集。分析结果还包括安全机制，这些安全机制既包括第3章中发现的可分配功能安全需求的现有安全机制，也包括为实现功能安全需求而新增的组件。这些安全机制解答了研究问题 RQ3（如何利用i-CAVE软件架构的功能安全分析结果改进其软件架构？）。
6.1 讨论
尽管功能安全分析结果表明，i-CAVE软件架构中存在大量未被现有安全机制覆盖的功能安全需求，但这并不意味着直接应用本文提出的所有安全机制是最佳决策。首先，i-CAVE是一个研究项目，研究范围广泛，涵盖协同车辆系统的多个方面，因此安全机制的应用必须与项目内的其他开发工作相协调。但也可以认为，这些安全机制是项目的重要组成部分，因为功能安全是i-CAVE其中一个子项目的核心主题。应用部分安全机制的另一个顾虑是开发成本。任何形式的冗余安全机制都需要更多的实施工作量，这可能会影响i-CAVE项目中演示平台正常运行所需的其他部分的开发。当原始组件本身正在实现新技术时，开发多样化的冗余组件可能并不具备可行性。此外，关于通信协议的实现问题：如果i-CAVE仅实现第3章所述的欧洲ITS通信栈，那么现有的消息类型将无法支持车辆之间共享环境信息。扩展欧洲ITS通信栈以支持这类数据的传输，可能超出i-CAVE项目的范围和资源能力。
6.2 未来工作
本文提出了一种协同车辆系统功能安全分析方法，将其应用于i-CAVE软件架构的结果表明，该方法能够提供关于i-CAVE软件架构安全性的新见解，以及解决潜在安全危害的可行安全机制。然而，这一结果也引出了更多基于本文研究成果的未来工作方向。首先，本文提出的安全机制尚未应用于i-CAVE软件架构的实际实现中。实施这些安全机制将能够验证功能安全分析方法的有效性。在实施安全机制的过程中，研究该过程是否也能遵循ISO 26262的方法也具有重要意义。 如6.1节所述，实施所有提出的安全机制可能并不具备可行性。因此，有必要进一步研究哪些安全机制在i-CAVE的背景下是可行的，哪些是不可行的。 还可以进一步研究本文提出的功能安全分析方法的普遍适用性：它是否也适用于其他协同车辆系统的软件架构，例如ECO-twin项目？理论上，任何提供功能车辆架构和用例场景的协同车辆系统都可以作为分析对象。但在实际应用中，对于其他协同车辆系统项目，将系统划分为车辆视角和协同视角可能并非易事。在分析过程中发现，为安全危害分配可控性得分时，粒度较粗：由于车辆在队列中时软件完全控制车辆，因此可控性大多处于最高等级。研究是否可以为自动驾驶车辆的安全分析增加更多可控性等级，是一个值得探索的方向。
免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。
10个月宝宝每天需要喝多少奶粉？
