智能驾驶系统：危害分析和风险评估规范
文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 |
发文件起草分工： 1. |
编制： |
签名： 日期： |
审核： |
签名： 日期： |
批准： |
签名： 日期： |
所有权声明 |
该文档及其所含的信息是财产。该文档及其所含信息的复制、使用及披露必须得到的书面授权。 |
本规范的目的是为了地识别、分类和评估智能驾驶系统可能面临的潜在危害，从而制定相应的措施来避免不合理的危险，确保智能驾驶的安全性，并为后续系统的开发提出要求。
本规范规定了智能驾驶系统对可能产生的危害进行识别、分类和风险评估的方法和标准，并确定相应的安全目的和制定相应的预防措施。该规范适用于智能驾驶系统的开发、测试、部署和运营等各个阶段，以确保系统在整个生命周期内都符合安全标准。
本规范的版本变更说明如表1所示。
表1 更改历史
版本 |
更改描述 |
更改日期 |
更改人 |
1.0 |
|
|
|
1.1 |
|
|
|
1.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
下列文档中的条款通过本标准的引用成为本标准的条款。凡是注日期的引用文档，其随后的修改单(不包含勘误的内容)或修订版均不适用于本标准。凡是不注日期的引用文档，其最新版本适用于本标准。
2.1 国际标准和技术规范
表2 规范性引用文件
编号 |
文档 |
Ref [1] |
ISO 21448: Road Vehicles — Safety of the Intended Functionality |
Ref [2] |
ISO 21434: Road Vehicles — Cybersecurity Engineering |
Ref [3] |
ISO 26262: Road Vehicles — Functional safety |
Ref [4] |
UL 4600: UL Standard For Safety Evaluation of Autonomous Products |
Ref [5] |
IEC 61508：Safety of machinery - Functional safety of electrical, electronic and programmable electronic control systems |
Ref [6] |
|
2.2 国内标准和技术规范
本规范参考的国内标准和技术规范如表3所示。
表3 规范性引用文件
编号 |
文档 |
Ref [1] |
GB/T 34590.1: 道路车辆 功能安全 第1部分：术语 |
Ref [2] |
GB/T 34590.2: 道路车辆 功能安全 第2部分：功能安全管理 |
Ref [3] |
GB/T 34590.3: 道路车辆 功能安全 第3部分：概念阶段 |
Ref [4] |
GB/T 34590:道路车辆功能安全 |
Ref [5] |
GB/T 20438—2006:电气/电子/可编程电子安全相关系统的功能安全 |
Ref [6] |
|
Ref [7] |
|
3.术语缩写与定义
3.1 缩写
表4列出了本规范中专有名词的英文全称及相应的中文。
表4 缩写
缩写 |
含义 |
ASIL |
Automotive Safety Integrity Level(汽车安全完整性等级) |
FMEA |
Failure Mode and Effects Analysis(失效模式与影响分析) |
FTA |
Fault Tree Analysis(故障树分析) |
HARA |
Hazard analysis and Risk assessment(危害分析和风险评估) |
ETA |
Event Tree Analysis(事件树分析) |
DFMEA |
Design Failure Mode and Effects Analysis(设计失效模式及后果分析) |
FMEDA |
Failure Modes Effects and Diagnostic Analysis(失效模式、影响及其诊断分析) |
FMECA |
Failure Mode and Effects and Criticality Analysis(失效模式、影响及危害性分析) |
ISO |
International Organization for Standardization(国际标准化组织) |
RTOS |
Real-Time Operating System(实时操作系统) |
IC |
Integrated Circuit(集成电路) |
EEPROM |
Electrically Erasable Programmable Read-Only Memory(带电可擦可编程只读存储器) |
ODD |
Operational Design Domain(操作设计域) |
3.2 术语和定义
严重度
危害事件发生后，对人员、环境和车辆可能造成的伤害或损害的预估程度。
暴露率
特定危害场景发生的概率或频率。
可控性
在危害事件发生时，通过系统或人员操作避免或减少损害的能力。
故障模型
定义了故障可能发生的方式，以便理解故障所产生的影响。
风险缓解
各种技术和战略的集中性应用，用于最大限度地降低风险水平，并将其减少到可承受的程度
RTOS
指实时操作系统，当外界事件或数据产生时，能够接受并以足够快的速度予以处理，其处理的结果又能在规定的时间之内来控制实时任务，并控制所有实时任务协调一致运行的操作系统。
ASIL
汽车安全完整性等级，对失效后带来的风险进行评估和量化以达到安全目标。
恶意数据
一种具有破坏性与损坏性质的数据。
IC制造故障
集成电路缺陷而导致的电路逻辑功能错误或电路异常操作。
ODD
自动驾驶系统运作的设计范围。
3.3 约定术语
本文档中使用了下列术语：
“要求”:表示一种必须/强制的需求。
“应当”:表示一种推荐或建议。
“必须”:表示一种法律或标准的需求。
“将会”:表示一种预计的考虑情况，或者一种附加或可选的特性。
“可以”:表达一种被允许的行为或方法，并不认定为需求。
本章节描述了确定道路使用者受危害影响程度及如何解决的方法，这些方法及其工作成果统称为危害分析和风险评估，并从受到影响的道路使用者的角度出发，本规范中采取的定义方法是通用模块，可以从项目、系统或者某一具体部件的生命周期的任何一点系统的调用，具体章节内容：
a) 项目及其运行环境(详情见第5章节)
b) 故障（扩展故障的范围）及其场景、定义(详情见第6章节)
c) 故障识别与危害分析(详情见第7章节)
d）风险评估(详情见第8章节)
f) 风险缓解和缓解效果评估(详情见第9章节)
通过上述表明的通用模块，本规范中的相关案例示例基本适用，如有特别说明，会进行相应的警告注释。
注1：故障所包含的概念范围将会扩大，不仅限于硬件、软件故障，也包含网络攻击引发的损害等。
注2：警告注释内容包括但不限于，不在本规范使用范围内，但有特别安全需求的项目产品。
图1 危害分析和风险评估规范设计流程
图2 危害分析和风险评估规范工作流程
本章节的目标是：
a) 准确定义项目。
b) 确定故障的具体类型。
c) 确定故障导致的危害并进行分析。
d）确定危害的风险程度。
e) 确定风险的安全需求和安全目标。
f) 确定风险缓解策略并评估缓解效果。
项目定义，也就是对要进行研发的产品进行一个定义，进行一个描述。主要有两个目的：一个是定义和描述项目；一个是对项目有一个足够的理解，以便能够很好的完成安全生命周期中定义的每一个活动。
基于以上目的，要对项目进行明确、准确、正确的定义，就需要获得一些基本信息：
1、项目信息：
a) 项目的目的和功能。
b) 项目的非功能性要求，如操作要求、环境限制等。
c) 法规要求（特别是法律和法规），已知的国家和国际标准等。
d）类似功能、系统或元素达到的行为。
e) 对项目预期行为的构想。
f) 已知的失效模式和风险在内的项目缺陷造成的潜在影响。
2、 项目的边界条件以及相关项目之间的接口条件：
注：项目边界将项目与它的运行环境区分开来。项目边界的描述可以包括与车辆内部其他项目和与车辆外部E/E系统的接口。
a） 项目的所有元素。
b） 项目对其他项目或项目环境元素的相关影响。
c） 其他项目，元素和环境对本项目的要求。
d） 在系统或者包含的元素中，对功能的定位和分配。
e） 影响项目功能时，项目的运行情况。
根据上述项目的基本信息以及项目条件，通过对项目安全需求的不同角度以及项目文档的需求进行下述内容的定义：
a） 相关项定义(详情见第5.2章节)。
b） 功能规范定义(详情见第5.3章节)。
c） 项目运行环境定义(详情见第5.4章节)
注：在5.3章节系统及与其功能定义中，不在描述与5.2章节相关项及功能定义中，存在重复的定义部分。
注：有关网络信息环境与“车-路-云”环境将会在5.4章节体现，同样不再定义与之前章节重复的部分。
相关项是一个系统或多个系统的组合，其本质特征为能够实现或部分实现整车的功能，而从系统层面再向下还可分解为：组件、硬件元器件/软件单元等下层要素
a)
要素：
系统、组件、硬件元器件或软件单元。可分解要素允许被标注为系统、子系统或组件，其中满足系统标准的可分解要素可被标注为系统或子系统，当着重强调要素是一个更大系统的一部分时，使用术语
“子系统”。
b) 系统：
一组至少与一个传感器、一个控制器和一个执行器相关联的要素。
注1：相关的传感器或执行器可包含在系统中，也可存在于系统之外。
注2：系统中的要素也可能是另一个系统。
c) 组件：
组件是系统的一部分，是非系统层面的、逻辑上和技术上可分的独立要素，由一个以上硬件元器件或一个到多个软件单元组成。通常“组件”用于仅由元器件和单元组成的要素，但也能用于由更低层面的特定技术领域要素组成的要素。
d) 硬件元器件：
硬件组件的一部分，例如微控制器的CPU、电阻、电容。
e) 软件单元：
软件架构中的最低层级且可被孤立测试的软件组件。
相关项定义的目的是定义并描述相关项的功能，及其与驾驶员、环境、其它相关项在整车层面的相关性和相互影响；并为充分理解相关项提供支持，以便执行后续阶段的活动。
相关项定义的内容应包括以下几个部分：
a) 功能需求：
整车层面的功能概念，包括运行模式及状态。
b) 非功能需求：
1)法规要求、国家标准和国际标准；
2)功能相关的质量、性能和可用性要求（如果适用）；
3)相关项的约束条件，例如功能与其它相关项及运行环境的相关性；
c) 行为不足：
包括已知的失效模式和危害造成的潜在后果（可包括关于类似相关项的已知的与安全相关的事件）。
d) 执行器的能力或能力假设：
例如扭矩输出、施加的力、运行速度、亮度、响度这些值或估计值，在评定严重度和可控度等级时，需考虑这些影响。
e) 初始架构：
1)相关项包括的要素（要素也可基于其他技术）；
2)功能在所涉及的系统和要素间的分配。
5.3章节是5.2章节相关项及功能定义的补充，特别针对由于系统设计不足或局限性(非故障导致的)而导致的安全问题,同时考虑由功能规范定义不准确引发的安全问题。
预期功能安全（SOTIF）是指系统在预期的操作条件下，能够安全地处理其功能范围内的正常变异和扰动，为了确保系统能在安全的工作范围内工作，应该明确定义系统的相关方面(如适用)包括但不限于以下方面：
a) 对预期的功能、支持子系统和组件的功能的描述:
1) 运行范围(ODD)。
2) 自动驾驶功能控制车辆动态任务的权限级别和细节。
3) 整车层面的SOTIF策略。
4) 功能可被激活或关闭的用例,以及激活和关闭用例间的转换。
5) 决策逻辑的描述(例如,路径规划、驾驶策略)。
b) 实现预期功能的相关系统及其要素的设计:
c) 为实现预期功能而安装的传感器、控制器、执行器或其他输人及组件(例如,地图)的性能目标。
注1:自动驾驶系统的性能目标(见D.5),例如,包括在ODD范围内对关键目标和事件(例如,行人、车辆、自行车、摩托车和交通标志)的探测与响应。
d) 预期功能与如下条目间的依赖关系、交互或接口:
1) 驾驶员。
2) 驾驶员交互(例如,HMI),及如何使用交互以减轻已知的可合理预见的误用远程/后台操作人员。
3) 车辆上可能干扰预期功能的其他功能,包括信息交换和相应的使用假设。
e) 可合理预见的误用(直接和间接)。
f) 系统及其要素的潜在的性能局限、已识别出的触发条件、应对措施。
g) 报警和降级概念。
1) 报警策略。
2) DDT后援:接管/后援的条件和方案,用于在各自的用例中,将控制权从自动驾驶系统转移到驾驶员或另一个系统。
3) 最小风险状态方案(例如,自动靠边停车、在路径中停车、后援用户)。
4) 驾驶员监控系统及其对后援策略的影响。
h) 在预期功能的开发过程中和开发后,支持数据收集和监控的程序。
设计包括对可能因要素输出值引起潜在性能局限的考虑,这些性能局限可能潜在导致整车层面的危害行为。潜在性能局限的非穷尽示例包括:
a) 分类不充分。
b) 测量不足。
c) 跟踪不足。
d) 目标选择不足。
e) 运动学估算不足。
f) 假阳性探测(误报,例如,鬼影、幻影物体)。
g) 假阴性探测(漏报)。
h) 驾驶策略层面的局限,例如,对遮挡区域的考虑。
通过定义项目运行环境，可以明确智能驾驶安全规范所适用的具体场景和条件。这有助于确保规范的针对性和实用性，避免在不适用的环境中应用规范导致安全问题，并且可以使驾驶员和测试、开发人员更好地理解智能驾驶系统的能力和限制，当了解车辆在特定环境下的性能和安全要求时，他们可以更合理地使用智能驾驶功能，并对系统的安全性有更清晰的认识，因此确定项目的运行环境对于自动驾驶安全的作用巨大。
自动驾驶项目运行环境是一个多维度的生态系统，因此必须从多个维度进行多层次，多角度，全方位的描述，以下是一些主要的智能驾驶车辆的项目运行环境，智能车辆必须考虑和适应：
注1：如对某一个具体环境信息有明确要求的，应明确标出。
应描述与网络安全有关的项目的操作环境信息：
已知的网络攻击手段，当前针对智能车辆的常见网络攻击方式，如远程控制、数据窃取、恶意软件注入。
注1：对操作环境及其与项目的相互作用的描述，可以识别或分析相关的威胁情景和攻击路径。
注2：相关信息可以包括假设，例如假设该项目所依赖的每个公共基础设施证书机构都得到了适当的管理。
a) 车辆自身状态环境：
1) 电量/燃料状态
示例：电动汽车的电池电量或燃油车辆的油箱油量。
2) 行驶速度
示例：车辆当前的行驶速度和相对于限速的状态。
3) 位置和导航信息
示例：车辆的GPS位置、方向和目的地。
4) 传感器状态
示例：摄像头、雷达、激光雷达（LiDAR）、超声波传感器等的状态和数据质量。
5) 轮胎状况
示例：轮胎的压力、温度和磨损情况。
6) 发动机和动力系统性能
示例：燃油车辆的发动机状态和电动汽车的电机/电池性能。
7) 制动系统
示例：制动液位、制动片磨损和制动响应。
8) 转向系统
示例：转向助力和转向角度。
9) 车辆健康状况
示例：车辆各系统和组件的健康状态，包括故障检测和诊断。
10) 内部环境状态
示例：乘客舱的温度、湿度、空气质量等。
11) 车辆载荷
示例：车辆当前的载荷重量和分布。
12) 外部照明和信号灯
示例：头灯、尾灯、转向灯和刹车灯的工作状态。
13) 雨刷和洗涤器
示例：雨刷的状态和洗涤液的存量。
14) 安全系统状态
示例：安全带、气囊和自动紧急制动系统的状态。
15) 车辆通信能力
示例：V2X（车对外界）、V2V（车对车）和其他通信系统的状态。
16) 软件和固件版本
示例：控制系统和传感器的软件版本，确保系统已更新至最新。
17) 维护和保养状态
示例：车辆的维护和保养历史，包括下次保养的时间和项目。
18) 行驶模式和驾驶辅助功能
示例：车辆当前所采用的驾驶模式（如经济、运动、自动驾驶等）和激活的驾驶辅助功能。
19) 车辆识别码（VIN）和注册信息
示例：用于识别车辆和合规性检查的车辆识别码和注册信息。
20) 能量消耗和效率
示例：车辆的瞬时和平均能量消耗，包括电池效率或燃油效率。
a) 道路环境：
1) 道路类型
示例：如高速公路、城市道路、乡村道路等。
2) 道路状况
示例：包括道路的平整度、坡度、弯道半径等。
3) 交通标志和标线
示例：如交通信号灯、限速标志、车道线等。
4) 道路设施
示例：如护栏、隔离带、桥梁、隧道等。
5) 交通流量
示例：道路上的车辆密度和交通拥堵情况。
6) 地形地貌
示例：如山区、平原、丘陵等地形特点。
7) 道路施工和维护
示例：道路施工和维护情况对车辆行驶的影响。
8) 环境光照
示例：白天和夜晚的光照条件，以及天气对光照的影响。
b) 气候环境：
1) 晴朗天气
示例：理想的驾驶条件，但也需要考虑光线过强（如直射阳光）对传感器的影响。
2) 雨天
示例：细雨、中雨、大雨和雷暴等不同的降水条件，这些可能影响道路摩擦系数和传感器性能。
3) 雪天
示例：新雪、积雪、冰雨和暴风雪等，这些会使道路变得滑，影响车辆控制和传感器精度。
4) 雾天：
示例：影响能见度，对车辆的感知系统，特别是视觉传感器造成挑战。
5) 冰雹
示例：冰雹对车辆结构和传感器的冲击可能会影响性能。
6) 霜冻
示例：结霜可能影响传感器的清晰度和车辆的摄像头视野。
7) 沙尘暴
示例：扬沙和尘埃可能损坏机械部件，降低传感器性能。
8) 高温
示例：高温环境会影响车辆电子设备的性能和散热能力。
9) 低温
示例：低温可能会影响电池性能、轮胎压力和润滑油的粘度。
10) 湿度变化
示例：湿度的高低会影响道路表面状况和空气中的水分含量，可能影响传感器和电子设备。
11) 海拔
示例：高海拔地区的空气稀薄可能会影响车辆的发动机效率和氧气传感器的性能。
12) 沿海气候
示例：海边的盐雾可能会腐蚀车辆的金属部件和传感器。
13) 风速
示例：强风可能影响车辆的稳定性，特别是对于大型卡车或高车身的车辆。
14) 季节变化
示例：不同季节可能带来的气候变化，需要车辆能够适应从春季到冬季的各种环境。
c) 其他车辆和行人：
1)车辆多样性
示例：包括各种大小和类型的车辆，如轿车、卡车、摩托车、自行车、公共交通工具（公交车、有轨电车）和紧急服务车辆（救护车、消防车、警车）。
2)交通流量
示例：不同水平的交通流量，从拥堵到流畅，影响车辆的导航和决策。
3)行人行为
示例：行人的行走路径、速度和行为往往是不可预测的，他们可能在人行横道、路边或意外的地方穿过马路。
4)动物穿越
示例：野生或家养动物在道路上的出现可能会影响交通流和自动驾驶车辆的反应。
注1：针对于我国某些地区特别提出，若不涉及，无需考虑。
5)交通规则遵守程度
示例：司机和行人对交通规则的遵守程度参差不齐，可能会进行一些非预期的交通行为。
6)交通信号和标志
示例：其他车辆和行人对交通信号灯、交通标志的响应可能会影响自动驾驶车辆的行驶路径。
7)道路共享情况
示例：不同的道路使用者在同一路段共享空间，如自行车和机动车共用车道。
8)交通事件
示例：事故、车辆故障或其他交通事件可能导致交通流的突然变化。
9)特殊事件
示例：节日、游行、体育赛事等可能导致道路使用模式和行为的变化。
10)施工区域
示例：施工车辆和设备的移动，以及行人在施工区域的活动。
11)停车和路边活动
示例：车辆在道路上的停放可能不规律，行人可能在停车区域穿行。
12)交通参与者之间的交互
示例：车辆和行人之间的交互，如礼让、超车、变道等。
13)视线受限
示例：其他车辆的大小和位置可能阻挡自动驾驶车辆的视线，影响对行人和交通状况的感知。
14)特殊交通参与者
示例：残疾人士、儿童或老年人可能具有不同的行走速度和行为模式。
15)交通拥堵
示例：拥堵时行人和其他车辆的行为模式可能与正常情况不同。
16)紧急情况
示例：火灾、交通事故等紧急情况下，其他车辆和行人可能表现出非典型的紧急行为。
保证人工智能与智能云控网络环境安全对于保护数据隐私、防止恶意攻击、确保系统可靠性、保护知识产权等方面都有着非常重要的作用，必须定义全面、准确、清晰的人工智能(AI)与智能云控网络环境，以下是一些主要的智能驾驶车辆的项目运行中，应该被智能车辆所考虑人工智能(AI)与智能云控网络环境因素：
a) 人工智能(AI)环境
1) 计算平台：
示例：多组件的车载计算平台，包括GPU、CPU、FPGA或专用AI芯片。
2) 数据存储和管理：
示例：高速、大容量的数据存储解决方案，以及有效的数据管理系统。
3) 算法开发和部署：用于路径规划、碰撞避免、决策制定和其他关键功能的算法。
4) 智能交通系统（ITS）集成：
示例：与智能交通系统的集成，如交通管理、拥堵控制等。
b) 智能运控网络环境
车路云一体化融合控制系统，简称“云控系统”。利用新一代信息与通信技术，将人、车、路、云的物理层、信息层、应用层连为一体，进行融合感知、决策与控制，实现车辆行驶和交通运行安全、效率等性能综合提升的一种信息物理系统，以下是确保这一系统安全环境需要考虑的内容：
1) 车辆与其他交通参与者
Ⅰ)车辆：
示例：需要通过车载终端或移动终端向路侧和/或云控基础平台发送行驶动态信息，接收来自路侧和/或云控基础平台提供的感知、决策甚至控制信息服务。
Ⅱ)其他交通参与者：
示例：其他交通参与者以及非平台注册车辆的行驶动态行为对交通安全的影响通过路侧感知设备进行感知，并及时利用RSU进行广播，以及上报云控基础平台。
2) 通信网络
通信网包括C-V2X网络、固网光纤、4G/5G蜂窝网络、互联网以及其他专有网络，用于支撑车路、车云、路云以及云云之间信息的安全、高效互通。
Ⅰ)C-V2X网络与4G/5G蜂窝网络
示例：主要支撑车辆与路侧、云端的互联互通
Ⅱ)固网光纤
示例：主要保障路云之间以及云控基础平台各级云之间的互联互通
Ⅲ)互联网
示例：实现云控基础平台与在互联网环境下运行的第三方平台的互联互通
Ⅳ)其他专有网络
示例：搭建的车路云通讯环境由其自身保障车云、路云、云云之间的安全、高效互通
3) 网络边界防护：
示例：确保车辆的各通信接口具有防火墙和入侵检测系统，以防止未授权的访问。
4) 数据加密：
示例：对车辆传输的数据（包括车辆与车辆、车辆与基础设施之间）进行加密，保护数据的机密性和完整性。
5) 通信协议安全：
示例：采用安全的通信协议和安全层，如TLS/SSL、DTLS等，确保数据传输安全。
6) 身份验证和授权：
示例：对通信的各方进行身份验证，并根据身份授权不同的访问权限。
7) 访问控制：
示例：实施基于角色的访问控制策略，限制对车辆系统的访问。
8) 安全配置管理：
示例：确保车辆系统和网络设备按照安全标准进行配置。
9) 第三方服务安全：
示例：确保所使用的第三方服务和API符合安全标准
10)路侧基础设施
实现环境感知、局部辅助定位、实时获取交通信号及交通通告信息
保障前述信息在车路云之间互联互通。
11)云控基础平台
Ⅰ)边缘云：
示例：网联汽车提供增强行车安全的实时性和弱实时性云控应用。
Ⅱ)区域云：
示例：交通运输和交通管理部门提供弱实时性或非实时性交通监管、执法等云控应用。
Ⅲ)中心云：
示例：交通决策部门、车辆设计与生产企业、交通相关企业及科研单位，提供宏观交通数据分析与基础数据增值服务。
a)安全性
示例：避免碰撞，自动驾驶系统必须能够识别和避免与其他车辆、行人、障碍物等发生碰撞。
b)遵守交通规则
示例：系统需要遵守所有的交通规则，包括速度限制、交通信号、道路标志等。
c)处理系统降级
示例：在发生安全相关功能或系统组件故障时，系统需要能够安全地将控制权转移到车辆操作员手中，或者采取其他措施来确保安全。
d)最小风险状况
示例：车辆操作员未能响应接管请求，系统必须能够执行操作以最小化风险。
e)各种条件下运行
示例：自动驾驶系统需要具备在各种天气条件和道路状况下正常运行的能力，减少故障和失灵的可能性。
f)鲁棒性
示例：当系统遭遇电子的、通信的或机械的误操作时，以及遭遇软件错误时，仍能保持处于安全状态。
g)适应性
示例：适应不同环境,自动驾驶系统需要能够适应城市道路、高速公路、复杂交通情况等不同的环境和情况。
h)处理非预设事件
示例：系统需要能够处理非预设的事件或问题，而不仅仅是基于预设的场景和规则进行操作。
<
为每个与安全相关的项目组件，功能部件或与故障分析相关的其他方面确定的故障模型，故障模型有助于设计系统的安全架构，包括硬件、软件和通信等层面的安全功能。
通过考虑各种可能的故障情况，可以确保系统架构在各种故障条件下都能保持安全和可靠，有助于全面评估系统的安全性和可靠性，指导安全设计、测试和验证等过程，并为持续改进提供基础，以下是故障模型的一些基本类别(包括但不限于)：
a) 设计故障模型：在自动驾驶汽车设计阶段，为识别和预测潜在故障而建立的模型。
注1：模型主要用于分析自动驾驶系统在设计上可能存在的缺陷或不足，以确保在车辆实际运行之前能够发现并解决这些问题。
b) 制造故障模型：在自动驾驶产品的制造阶段中，旨在识别和预测因制造过程导致的潜在故障。
1)材料缺陷
示例：分析自动驾驶产品所使用的材料在制造过程中可能出现的缺陷，如杂质、裂纹、不均匀性等。
示例：评估材料缺陷对产品性能和安全性的影响，以及如何通过材料选择和质量控制来减少缺陷的发生。
2)工艺问题
示例：识别制造过程中可能存在的工艺问题，如温度控制不当、压力不稳定、机械振动等。
示例：分析问题如何影响产品的制造精度、稳定性和可靠性，并提出相应的改进措施。
3)生产误差控制
示例：制定严格的生产误差控制标准，确保产品制造过程中的每一步骤都符合设计要求。
c) 运行故障模型：智能驾驶车辆在实际运行中可能遇到的各种故障情况的模拟或描述。
注1：设计故障可能涉及硬件、软件、传感器、通信系统等多个方面，对车辆的安全运行构成潜在威胁。
1)硬件故障
示例：传感器失效、执行器故障等，可能导致车辆无法准确感知环境或执行驾驶决策。
2)软件故障
示例：算法错误、系统崩溃等，可能导致车辆无法正确处理感知数据或做出错误的驾驶决策。
3)通信故障
示例：车辆与基础设施、其他车辆或行人之间的通信中断或延迟，可能导致车辆无法及时获取重要信息或做出必要的反应。
d) 非运行故障模型: 在自动驾驶系统非运行状态下(例如，在维护、测试、充电、存储等阶段)可能发生的故障或失效情况。这些故障虽然不直接涉及系统的运行过程，但同样可能对系统的安全性能产生重要影响。
1)系统存储和充电故障：
示例：自动驾驶车辆在充电或长期存储过程中，电池系统可能发生的故障，如电池老化、过热、过充等。
2)系统维护和检修故障：
示例：在对自动驾驶系统进行维护和检修时，可能由于操作不当或工具设备问题导致的故障，如传感器损坏、线路接错等。
3)环境适应性故障：
示例：自动驾驶系统在不同环境条件下（如极端温度、湿度、电磁干扰等）可能发生的故障。
4)软件更新和配置故障：
示例：在对自动驾驶系统的软件进行更新或配置时，可能由于软件漏洞、版本不兼容等原因导致的故障。
注1: 非运行故障模型还包含与使用年龄相关的组件退化，由于在存储过程中缺乏操作而导致的物品退化
e) 维修故障模型：在自动驾驶产品维修过程中可能出现的故障或问题，以及这些故障或问题对系统安全性和性能的影响。
1) 操作不当
2) 工具使用错误
3) 零件更换不当
4) 系统改动引入的新风险
f) 程序故障模型：自动驾驶系统软件在设计和运行过程中可能出现的错误、异常或故障，以及这些故障对系统整体安全性和性能的影响。
1)代码错误：
示例：编程人员的疏忽或技能不足，可能导致代码中存在语法错误、逻辑错误或算法错误。
2)逻辑错误：
示例：系统逻辑设计不当或存在缺陷，可能导致系统无法正确处理某些情况或做出错误决策。
3)内存泄漏：
示例：内存管理不当，可能导致系统内存逐渐耗尽，影响系统性能和稳定性。
4)数据不一致：
示例：系统内部数据不一致或数据损坏，可能导致系统无法正常工作或产生错误结果。
注1：由于UL 4600的具体文本内容未在参考文章中提供，因此无法直接引用其中的数字和信息。但一般而言，在评估程序故障模型时，可能需要关注一些关键的量化指标，如代码覆盖率、缺陷密度、故障率等。
注2：这些指标可以通过具体的测试和分析获得，用于评估自动驾驶系统软件的质量和可靠性。
g) 项目操作故障模型：动驾驶系统在项目实施、操作和维护等阶段，由于人为操作错误、管理不当或外部干扰等因素导致的系统故障或问题。
1)人为操作错误：
示例：操作员在配置、监控或控制自动驾驶系统时可能出现的错误，如错误地设置参数、忽视警告信息或误操作等。
2)管理不当：
示例：项目管理过程中存在的缺陷，如缺乏有效的监控机制、培训不足或维护不及时等，这些都可能导致系统出现故障。
3)外部干扰：
示例：系统可能受到来自外部环境的干扰，如电磁干扰、网络攻击等，这些干扰可能导致系统性能下降或失效。
注1：项目操作故障模型是UL 4600中关注的一个重要方面, 通过严格的评估和预防措施，可以有效地减少项目操作故障的发生，提高自动驾驶系统的稳定性和安全性。
h) 工具故障模型: 自动驾驶产品相关工具使用过程中，由于设计缺陷、操作错误、老化损坏等原因，导致工具无法正常工作或提供准确数据，进而影响自动驾驶系统安全性和性能的故障模式。
1)设计缺陷：
示例：工具在设计阶段可能存在的错误或不足，如软件缺陷、硬件设计错误等，这些缺陷可能导致工具无法正常工作或提供准确数据。
2)操作错误：
示例：使用工具的人员可能因操作不当、疏忽大意等原因，导致工具出现故障或数据错误。
3)老化损坏
示例：随着使用时间的增长，工具可能因磨损、老化等原因导致性能下降或故障发生。
i) 随机故障: 自动驾驶系统中由于随机事件或不可预测因素导致的、非系统性的、偶发性的故障。
1)硬件随机故障
示例：硬件组件如传感器、执行器、电路板等，可能因材料老化、环境应力、电磁干扰等原因发生随机失效。
2)软件随机错误
示例：软件代码在执行过程中可能因内存泄漏、数据竞争、时序问题等出现随机错误，导致系统行为异常。
3)环境随机变化
示例：自动驾驶系统所处的环境，如天气、路况、其他交通参与者等，可能发生不可预测的随机变化，对系统性能产生影响。
j) 系统性故障:自动驾驶系统中由于系统内部设计、制造、集成或配置等方面的缺陷或错误，导致系统整体或部分功能出现异常的故障模式。
1)集成问题：
示例：在系统集成阶段可能出现的问题，如不同模块之间的通信故障、接口不匹配、软件与硬件不兼容等，这些问题可能导致系统无法正常工作。
2)配置错误：
示例：在系统配置阶段可能出现的错误，如参数设置不正确、配置文件缺失或损坏等，这些错误可能导致系统性能下降或功能异常。
k) 故障多重性：自动驾驶系统中，由于多个单一故障或失效的并发或相互作用，导致系统整体性能下降、功能失效或产生安全隐患的现象。
1)累积效应：多个单一故障或失效可能同时或相继发生，它们的累积效应可能导致系统整体性能下降或功能失效。
示例：一个传感器的失效可能导致系统感知能力降低，而另一个控制单元的故障可能进一步影响系统的决策能力，两者的共同作用可能使系统无法正常工作。
2)相互作用：不同故障之间可能存在相互作用，导致故障的影响相互放大或产生新的故障。
示例：一个软件的缺陷可能导致系统内存泄漏，进而影响系统的实时性能，而另一个硬件的故障可能进一步加剧这种影响，导致系统崩溃。
3)常见原因导致的多个故障
4)在项目的整个生命周期中积累了多个故障
注1:如果有证据支持，可以将其归功于诊断，恢复，降级的操作模式和维修能力
l) 未检测到(潜在)故障：自动驾驶系统中，由于系统自身的设计、制造、集成或运行过程中的限制，导致某些潜在故障未能被及时检测或识别出来的故障模式。
1)设计限制
示例：系统在设计阶段可能存在某些限制，如传感器检测范围不足、算法处理速度有限等，这些限制可能导致系统无法检测到某些潜在故障。
2)制造和集成问题
示例：在制造和集成过程中，可能存在零部件质量不达标、装配错误或接口不匹配等问题，这些问题可能导致潜在故障无法被及时发现。
3)运行环境和条件
示例：系统在实际运行过程中，可能受到环境、天气、其他车辆和行人等因素的影响，导致某些潜在故障在特定条件下才能被触发或显现。
m) 永久性，暂时性和间歇性故障
1)永久性故障是指那些一旦发生并持续存在，直到被移除或修复的故障。这类故障通常与硬件组件的损坏或软件系统的根本性错误有关。
Ⅰ)持续性：故障会一直存在，直到采取修复措施。
Ⅱ)系统性：某些系统性故障通常表现为永久性故障，影响整个系统的正常运行。
Ⅲ)难以预测：由于故障原因可能多种多样，包括材料老化、环境应力等，因此永久性故障的发生往往难以预测。
2)暂时性故障是指那些在一定时间内发生，但随后可能自行恢复或经过简单修复即可恢复的故障。这类故障通常与临时性的系统错误、外部环境变化或偶然事件有关。
Ⅰ)短暂性：故障只在特定时间段内存在，之后可能自行恢复。
Ⅱ)可恢复性：经过简单修复或系统重启等操作，故障可能得到恢复。
Ⅲ)影响因素多样：包括软件错误、硬件老化、环境变化等多种因素都可能导致暂时性故障的发生
3)间歇性故障是指那些随机出现和消失的故障，它没有明确的模式或频率。这类故障通常与系统内部的缺陷（如不稳定的硬件和软件）有关，其发生与否取决于某些特定的系统条件。
Ⅰ)随机性：故障的出现和消失都是随机的，没有固定的模式或频率。
Ⅱ)难以检测：由于故障是间歇性的，因此在线检测可能难以发现，而离线检测则更加困难。
Ⅲ)多种原因：产生间歇性故障的原因多种多样，包括系统内部的硬件和软件缺陷、外部环境变化等。
对危害场景进行分类是为了更好地理解和评估自动驾驶车辆在不同情况下可能面临的风险，进而采取适当的安全措施。危害场景通常被分为以下四大类：
a) 已知安全场景（Known Safe）：这些场景下的自动驾驶功能被认为是安全的，不需要额外的风险评估或安全措施。
b)已知不安全场景（Known Unsafe）：这些场景下的自动驾驶功能存在已知的安全风险，需要通过风险评估确定风险的大小，并采取相应的安全措施来降低风险。
c) 未知不安全场景（Unknown Unsafe）：这些场景下的自动驾驶功能存在未知的安全风险，需要通过测试、模拟等方法来发现和评估这些风险，并采取相应的安全措施。
d) 未知安全场景（Unknown Safe）：这些场景下的自动驾驶功能的安全性尚未经过充分评估，需要进一步的研究和测试来确定其安全性。
为了保证对于SOTIF危害场景划分的准确性，本规范也提出了如下的分类要求：
a) 全面性和准确性：分类应该全面覆盖所有可能的危害场景，并准确反映各类场景下的安全风险。
b) 可操作性和实用性：分类结果应该能够指导实际的安全风险评估和策略制定，具有可操作性和实用性。
c) 动态性和适应性：随着自动驾驶技术的不断发展和应用环境的变化，危害场景的分类也需要不断更新和完善，以适应新的安全风险和挑战。
那些在系统设计和预期功能范围内，已经通过充分验证和测试，确认在各种正常操作条件下均能够安全运行的场景。这些场景是智能驾驶系统设计和验证的基础，也是确保系统安全性的重要前提，已知安全场景涵盖了多种具体的驾驶和操作情况。以下是几个具体的场景示例，这些场景在系统设计和验证阶段都被视为安全可控的：
a)正常天气下的城市驾驶
在晴朗的天气下，智能驾驶车辆在城市道路上行驶，遵循交通规则和信号灯指示，与其他车辆和行人保持安全距离。
示例：车辆能够准确识别行人、非机动车和机动车，根据道路情况自动调整车速和行驶轨迹，确保安全行驶。
b) 高速公路上的自动驾驶
在高速公路上，智能驾驶车辆进入自动驾驶模式，根据路况和车流情况自动调整车速和车道位置，保持与前车的安全距离。
示例：车辆能够识别高速公路上的各种标志和标线，如限速标志、车道指示等，并根据这些信息自动调整行驶策略。
c) 驾驶员辅助系统下的变道
在驾驶员的监控下，智能驾驶车辆通过驾驶员辅助系统（如转向辅助、盲点监测等）辅助驾驶员进行变道操作。
示例：车辆能够实时检测周围车辆和道路情况，为驾驶员提供变道建议，并在驾驶员确认后进行自动变道操作。
d) 紧急情况下的自动制动
当智能驾驶车辆检测到前方有障碍物或即将发生碰撞时，自动启动紧急制动系统，避免或减轻碰撞造成的损失。
示例：车辆通过雷达、摄像头等传感器实时检测前方路况，并在需要时自动启动制动系统，确保车辆在最短时间内减速停车。
注1：SOTIF的已知安全场景是智能驾驶系统能够正常运行并保证安全性的基础场景，需要在系统设计和验证阶段得到充分考虑和测试。
已知不安全场景需要通过危害识别和风险评估过程进行详细的分析和评估。这些过程旨在识别可能导致伤害或损害的各种潜在场景，并评估这些场景的风险水平。基于这些评估结果，可以制定相应的安全策略和措施来降低或消除这些风险，已知不安全场景主要包括以下几类：
a) 合理可预见的误操作导致的场景：
驾驶员在城市设置中错误地激活了用于高速公路的功能，导致车辆处于不能检测到红绿灯的场景。
示例：在模式混乱的情况下，驾驶员认为系统处于活动状态，即使它已被停用，从而可能导致事故。
b) 系统感知或决策局限导致的场景：
传感器感知局限可能导致系统在某些场景下的性能不如预期，如场景识别错误或决策算法判断错误。
示例：在恶劣天气（如大雾、暴雨）下，传感器可能无法准确识别前方障碍物，导致车辆无法及时做出避让。
c) 执行器功能局限导致的场景：
执行器（如制动系统、转向系统）的功能局限也可能导致系统无法按预期执行指令，从而引发危险。
示例：在紧急制动时，如果制动系统存在故障或性能不足，可能导致车辆无法及时减速或停车。
d) 已知设计或制造缺陷导致的场景：
这类场景通常是在车辆开发或生产过程中就已经被识别出来的潜在风险，但由于成本、时间等因素未能在上市前完全消除。
示例：某个软件版本的算法存在已知错误，可能导致在某些特定情况下系统行为异常。
e) 特定环境条件下的不安全场景：
某些特定的环境条件（如极端温度、高海拔等）可能导致系统性能下降或失效。
1)极端天气条件
Ⅰ)暴雨天气
示例：在暴雨中，路面积水可能导致传感器（如激光雷达、摄像头）的探测距离和准确性下降，使智能驾驶系统难以准确识别前方车辆、行人或障碍物，增加碰撞风险。
Ⅱ)大雾天气
示例：大雾会严重影响能见度，使得智能驾驶系统的视觉传感器（如摄像头）几乎无法发挥作用。即使使用雷达等其他传感器，也可能因为雾中水滴的散射和反射而导致误判，增加事故风险。
Ⅲ)极端温度
示例：在高温环境下，车辆内部电子元件可能会过热，导致性能下降甚至失效。而在极寒环境中，电池性能可能受到影响，导致续航里程缩短或无法启动。这些都会影响到智能驾驶系统的正常工作。
2)复杂地形和路况
Ⅰ)山区和丘陵地带
示例：在这些地区，道路可能蜿蜒曲折、坡度较大，对智能驾驶系统的导航和路径规划能力提出了更高要求。同时，山区和丘陵地带的能见度也可能受到天气影响，进一步增加驾驶风险。
Ⅱ)沙地和雪地
示例：在沙地和雪地上，车辆的轮胎与地面之间的摩擦力会减小，导致车辆的操控性变差。智能驾驶系统需要针对这些特殊路况进行专门的优化和调整，否则可能无法准确控制车辆行驶轨迹和速度。
Ⅲ)道路施工和损坏
示例：道路施工和损坏可能导致路面不平整、标线模糊或缺失等情况，这些都会影响到智能驾驶系统的感知和决策能力。系统可能无法准确识别道路标志和标线，导致误判或决策失误。
3)特殊场景和事件
Ⅰ)夜间行驶夜间能见度低，且光线条件复杂多变（如路灯、车灯等），对智能驾驶系统的视觉传感器提出了更高要求。
Ⅱ)交通事故现场：
示例：交通事故现场通常伴随着车辆碎片、液体泄漏、烟雾等复杂情况，这些都会影响到智能驾驶系统的感知和决策能力。系统需要能够快速准确地识别这些复杂情况，并作出相应的应对措施。
Ⅲ)大型活动和集会：
示例：在大型活动和集会期间，道路上可能会有大量行人、非机动车和机动车混杂在一起，形成复杂的交通场景。
预期功能安全（SOTIF）关注于系统在无故障情况下的安全性问题，这些问题可能源于设计、操作环境或其他未知因素，SOTIF的未知安全场景主要包括以下几类：
a) 未知的环境条件
1)极端但罕见的天气
示例：罕见的自然灾害（如龙卷风、海啸）或极端气候事件（如极端高温或低温），这些条件在设计和测试阶段可能无法完全模拟或预测。
2)未知的地理特征
示例：某些偏远或新开发的地区可能存在未知的地理特征（如特殊的土壤结构、未知的障碍物），这些特征可能影响智能驾驶系统的性能。
b) 未知的交通模式
1)非典型的交通场景
示例：大规模的交通拥堵、突发性的道路关闭或重定向等，这些非典型的交通场景在常规测试和模拟中可能未被充分涵盖。
2)非标准的交通参与者
示例：新型的交通工具（如电动滑板车、无人飞行器）或非典型的驾驶行为（如危险驾驶），智能驾驶系统可能需要时间适应和识别这些非标准的交通参与者。
c) 未知的技术发展
1)新兴技术的影响
示例：随着5G、物联网、人工智能等技术的不断发展，新的技术挑战和安全问题可能随之出现。
2)未来系统更新和升级
示例：智能驾驶系统的持续更新和升级可能引入新的功能或改变现有功能，这些变化可能带来新的未知安全风险。
d) 未知的人类行为
1)人类行为的不确定性
示例：尽管可以通过大量的数据和算法来预测人类行为，但人类行为本身具有极大的不确定性，这种不确定性可能导致智能驾驶系统无法完全理解和适应某些驾驶场景。
2)人为错误或欺诈行为
示例：驾驶员故意误导系统、黑客攻击等人为因素，可能导致智能驾驶系统出现意外的行为或失效。
e)未知的系统交互
1)与其他系统的交互
示例：智能驾驶系统可能需要与其他系统（如交通管理系统、基础设施系统等）进行交互，这些系统的未知行为或故障可能影响智能驾驶系统的安全性。
2)车辆内部的系统交互
示例：车辆内部的各个系统（如感知系统、决策系统、执行系统等）之间的交互也可能出现未知的安全风险。
网络信息威胁场景指的是在车载网络环境中，可能对网络系统、数据、服务或车辆使用人员造成安全威胁的各种具体情形。这些威胁可能来源于外部攻击者、内部人员或系统自身的漏洞，并可能通过不同的攻击方式和手段来实现。
注1：ISO 21434主要考虑的是来自外界的恶意入侵，对资产造成的损害，本规范补充了来自内部的威胁场景，弥补对于信息安全内部冲击的空白。
外部威胁场景在网络安全领域中呈现出多样化的特点，这些威胁通常源自车辆网络外部，并可能对智能车辆目标系统、数据或服务造成损害。
a) 网络攻击与入侵：
1)远程攻击：
示例：攻击者通过公共网络对智能驾驶系统进行远程渗透，尝试获取系统控制权或窃取敏感数据。
2)分布式拒绝服务（DDoS）攻击：
示例：DDoS攻击可能针对网站的HTTP/HTTPS服务、DNS服务器、游戏服务器等，造成服务中断或性能下降。
注1：攻击者可能使用各种技术来隐藏自己的真实身份和攻击来源，如使用反射或放大攻击来掩盖真实的流量来源。
b) 恶意软件与病毒：
1)车载系统病毒
示例：针对智能驾驶车辆的车载系统设计的病毒，可能通过车载网络传播，导致系统崩溃或数据泄露。
2)恶意软件注入
示例：攻击者通过无线接口或漏洞，将恶意软件注入到智能驾驶系统中，干扰或控制车辆的正常行驶。
c) 无线信号干扰与劫持：
1)信号干扰
示例：使用无线信号干扰设备对智能驾驶车辆使用的无线通信信号进行干扰，导致车辆无法接收或发送关键信息。
2)无线信号劫持
示例：攻击者通过破解无线通信协议，劫持车辆与基础设施之间的通信，发送虚假指令或拦截敏感数据。
d) 伪造与欺骗攻击：
1)GPS欺骗
示例：通过发送伪造的GPS信号，误导智能驾驶车辆的定位系统，使其产生错误的行驶路径或位置判断。
2)传感器欺骗
示例：针对智能驾驶车辆的传感器进行欺骗攻击，发送虚假的传感器数据，影响车辆的感知和决策能力。
e) 供应链攻击：
1)硬件篡改
示例：在智能驾驶车辆的硬件制造过程中，攻击者可能篡改或植入恶意硬件，导致系统漏洞或安全隐患。
2)软件植入
示例：在智能驾驶系统的软件开发和分发过程中，攻击者可能植入恶意代码或后门，以便在后续阶段进行远程攻击或数据窃取。
a)部人员恶意行为：
1)员工不当操作
示例：员工可能出于好奇、误操作或故意破坏等原因，对智能驾驶系统进行未经授权的访问或修改，导致系统不稳定或数据泄露。
2)内部欺诈
示例：部分员工可能利用职务之便，盗取智能驾驶系统的敏感数据或技术信息，用于非法获利或泄露给竞争对手。
b)权限管理不当：
1)权限分配不当
示例：智能驾驶系统的权限分配可能存在问题，导致某些员工或第三方合作伙伴获得了过高的权限，能够访问或修改敏感数据和系统配置。
2)权限滥用
示例：即使权限分配合理，员工也可能滥用其权限，例如私自访问非授权区域或进行未授权的操作，从而对系统安全构成威胁。
c)内部网络与系统漏洞：
1)系统漏洞
示例：智能驾驶系统可能存在已知或未知的安全漏洞，这些漏洞可能被内部人员利用，对系统进行攻击或破坏。
2)网络配置错误
示例：内部网络配置可能存在错误，例如防火墙规则设置不当、安全策略未及时更新等，使得内部人员能够绕过安全机制，对系统进行非法访问。
d)内部数据泄露：
1)数据备份不当
示例：智能驾驶系统的数据备份可能存储在不安全的位置或设备上，导致数据泄露风险增加。
2)数据传输风险
示例：内部人员在传输敏感数据时可能使用不安全的通信渠道，如未加密的电子邮件或即时通讯工具，使得数据在传输过程中被截获或篡改。
e) 第三方合作伙伴风险：
1)供应商风险
示例：智能驾驶系统可能依赖于多个供应商提供的组件或服务，如果供应商的安全管理存在漏洞或疏忽，将可能对整个系统的安全构成威胁。
2)合作伙伴不当行为
示例：与智能驾驶系统相关的合作伙伴可能出于各种原因进行不当操作，例如未经授权访问系统、泄露敏感数据等。
f)内部安全意识不足：
1)安全意识淡薄
示例：部分员工可能对智能驾驶系统的安全重要性认识不足，缺乏必要的安全意识，导致在日常工作中忽视安全规定或操作不当。
2)安全培训不足
示例：组织可能未能提供足够的安全培训和教育，使员工无法充分理解和掌握智能驾驶系统的安全要求和操作规范。
本章的目的是实现以下目标：
a) 应系统地识别智能驾驶车辆所受到的危害。
b) 应系统地识别和评估由识别的危害行为导致的风险,及危害行为可能导致危害的相应场景。应定义不安全的情况下的参数。
示例：参数可以是速度偏差或与其他物体的最小距离。
c) 应定义残余风险的接受准则及外部入侵的攻击路径。
在整车层面，功能安全、网络信息安全以及预期功能安全问题导致危害及伤害的过程具备相似性，这也为三个安全技术的融合开发提供了基础。
如图3所示，无论功能安全领域关注的电气/电子系统故障导致的功能异常，或是预期功能安全领域关注的功能不足，或是网络信息安全领域关注的外界恶意冲击，都可能引发车辆层面的危害行为，当该行为其超过一定门限，即：安全度量(参数)，则将导致危害。当危害发生在特定场景中时(这些场景具备使危害能导致伤害的条件因素)，就会构成危害事件，因为危害行为已经超过安全度量(参数)值。并且安全度量通常根据可控性水平定义，意味着此时涉险人员难以有效控制危害事件，最终导致伤害(财产损失)的发生。通过综合考虑这些因素，我们可以更好地保护系统的稳定性和安全性，减少潜在的风险和损失。
图3 本规范中故障识别和危害分析通用要素示意图
注1：这里“财产”的定义非具体的财产：车辆及其相关系统和组件受损、数据泄露或未经授权的访问等都可能导致财产损失。
注2：我们可以将其理解为与车辆网络安全相关的各种资产和数据的统称。
项目定义包括但不限于，相关项定义、项目边界、功能规范、初步架构等，项目定义的首要目的是描述、定义或划分考虑单位，这有助于明确危害分析的范围。通过项目定义，可以确定哪些系统、组件或功能需要进行详细的危害分析，避免分析过程过于宽泛或遗漏关键部分：
示例：识别潜在的系统故障、评估故障可能导致的危害以及制定相应的安全措施等。这有助于确保危害分析过程具有针对性和实效性。
注1：项目定义中包含了项目的安全需求和约束条件，有利于解项目的安全需求和期望达到的安全水平，从而制定相应的安全措施来确保项目的安全性。
故障模型为故障识别提供了一个系统性的框架。它允许分析人员从整体上理解系统可能发生的故障，而不仅仅是针对个别或局部的故障进行识别。通过将现有故障与章节6.2的系统故障模型进行整合分析，可以使故障的识别与分析流程更加系统化以及规范化以下是模型识别对于故障识别与危害分析的作用：
a) 明确故障类型和范围
UL 4600中的故障模型有助于明确智能驾驶系统中可能出现的故障类型和范围。通过识别和分析这些故障，可以更加精确地了解系统可能面临的风险和挑战。
b) 指导危害识别
故障模型为危害识别提供了指导。在智能驾驶系统中，危害可能来源于各种故障，如传感器故障、控制算法错误、通信中断等。故障模型可以帮助分析人员系统地识别这些潜在的危害。
c) 分析故障对系统的影响
故障模型不仅识别故障本身，还分析这些故障对系统整体性能和安全性的影响。这有助于评估故障的严重性和紧急性，从而确定相应的风险等级和应对措施。
d) 促进安全措施的制定
故障模型的分析结果有助于制定针对性的安全措施。针对不同类型的故障和危害，可以制定相应的预防措施、故障检测机制和应对措施，以确保智能驾驶系统的安全性能。
e) 与其他安全标准的协同
UL 4600中的故障模型与其他安全标准如ISO 21434（网络安全）和ISO 26262（功能安全）等可以相互协同。
示例：在识别和分析故障时，需要考虑网络安全因素（如数据完整性、非驾驶员的人机交互等），同时也需要满足功能安全的要求（如失效防止技术、管理要求等）。这种协同有助于实现智能驾驶系统的全面安全性能。
应对相关项的故障行为导致一个危害事件发生时所处的运行场景及运行模式进行描述,既要考虑正确使用车辆的情况,也要考虑可预见的不正确使用车辆的情况，具体场景类别详见章节6.3、章节6.4
注1：运行场景描述了期望相关项以一种安全的方式进行工作的边界范围。
示例：不期望普通乘用车在越野路面高速行驶。
应通过使用足够的技术方法手段系统地确定危害，除了需要在组件或系统层面对危害机型识别分析还应该关注整车层面产生的危害问题，这里给出在行业内对于危害识别与分析表现较好的一些方法：
a) 失效模式和影响分析(FMEA)
1) 识别潜在失效模式
示例：FMEA被用于识别自动驾驶系统中各个组件和子系统的潜在失效模式。这些失效模式可能包括传感器故障、控制器失效、通信中断等。
2) 评估影响
示例：对于识别出的每一个失效模式，FMEA进一步评估其可能导致的后果，包括事故风险、乘客安全、道路安全以及系统稳定性等方面的影响。
3) 风险分级
示例：基于失效模式的严重性和发生的可能性，FMEA可以对风险进行分级，从而帮助决策者确定哪些失效模式需要优先处理。
4) 制定缓解措施
示例：针对高风险的失效模式，FMEA可以指导制定相应的缓解措施，如增加冗余设计、改进故障诊断系统等，以降低失效模式的发生概率或减轻其影响。
5) 多标准的协同
Ⅰ) 在ISO 26262标准中，FMEA也是必须执行的一个环节，用于帮助识别潜在的安全风险。UL 4600与ISO 26262在FMEA的应用上具有一定的相似性，但侧重点可能有所不同。
Ⅱ) ISO 21434和GB T43267作为智能驾驶领域的网络安全标准，虽然不直接涉及FMEA的应用，但它们的实施可以为FMEA提供更为全面的安全分析背景，确保在评估失效模式和影响时能够充分考虑网络安全方面的因素。
b) 失效模式影响和临界度分析(FMECA)
1)失效模式识别：
UL 4600要求分析智能驾驶系统中的各个组件、子系统以及它们之间的相互作用，以识别潜在的失效模式。这些失效模式可能源于随机硬件故障、系统性失效、外界信息冲击等，如图片中所述。
2)影响评估：
对于每一个识别出的失效模式，需要评估其可能导致的影响。这些影响可能包括系统性损害、对乘客和道路使用者的潜在危害、以及网络安全问题等。在评估时，会参考图片中提到的触发条件、不可控危害事件等因素。
3)临界度分析：
FMECA（失效模式、影响及临界度分析）进一步扩展了FMEA的内容，增加了对失效模式严重性和发生频率的考虑。这有助于确定每个失效模式的风险等级，从而决定应该采取何种措施来降低风险。
4)风险管理：
基于FMEA和FMECA的结果，可以制定风险管理策略。这可能包括改进设计以减少失效模式的发生概率、增加冗余以提高系统的容错能力、实施更严格的监控和测试策略等。
c) 定性故障树分析(定性FTA)
1)系统性故障识别：
故障树分析从顶层事件（如系统性故障）开始，然后逐步向下分析，识别可能导致这一顶层事件发生的各种故障模式或子事件。这与系统性故障、随机硬件故障、系统性失效等概念相一致。
2)因果链分析：
通过故障树，可以清晰地看到各种事件之间的因果关系。
示例：外界信息冲击可能是一个重要的触发条件，它可能导致系统失效或性能下降。故障树分析可以帮助识别这些触发条件，并理解它们如何导致最终的危害事件。
3)危害评估：
示例：危害事件、危害（威胁）场景、不可控危害事件等概念，故障树分析可以帮助评估这些危害事件的严重性和可能性。通过了解每个事件的发生概率和后果，可以更准确地评估整个系统的风险水平。
4)风险控制：
基于故障树分析的结果，可以制定针对性的风险控制措施。
示例：如果发现某个故障模式的发生概率很高，或者其导致的后果很严重，那么就需要优先考虑采取预防或缓解措施。
d) 设计失败模式和影响分析 (DFMEA)
1)识别设计失败模式：
首先，基于智能驾驶系统的设计和功能，通过FMEA方法来识别潜在的设计失败模式。这些模式可能源于系统设计的缺陷、硬件组件的可靠性问题、软件错误或系统与其他组件之间的交互问题。
2)分析影响：
对于每一个识别出的设计失败模式，分析其可能导致的系统性故障、外界信息冲击或其他危害事件。这些事件可能涉及车辆性能的降低、乘客和行人的安全威胁、数据泄露等。同时，考虑这些事件的严重性和发生的可能性，以确定其风险等级。
3)评估风险：
结合图片中提到的触发条件、不可控危害事件、预期功能安全等因素，对设计失败模式和其影响进行综合评估。通过考虑这些因素的组合，可以更准确地评估每个设计失败模式的潜在风险。
4)制定控制措施：
基于FMEA分析的结果，制定针对性的控制措施来降低或消除设计失败模式的风险。这些措施可能包括改进系统设计、增加冗余组件、加强测试和验证过程、提高网络安全防护等。
e) 故障校式和影响分析－监视和系统响应 (FMEA-MSR)
1)故障障校式（故障模式）分析是识别系统中可能发生的所有故障模式的过程。这些故障模式可能源于硬件、软件、环境或其他因素。在智能驾驶系统中，这些故障模式可能包括传感器故障、控制器失效、通信中断等。
2)影响分析用于评估每个故障模式对系统性能和安全性的影响。图片中的流程图详细列出了故障模式与可能发生的危害事件之间的关联。
示例：一个传感器故障可能导致车辆无法准确感知周围环境，从而增加碰撞的风险。这种风险评估不仅考虑了故障的严重度，还考虑了其发生的可能性和可控性。
3)在监视和系统响应的过程中，故障校式和影响分析的结果被用于指导系统的设计和运行。
f) 失效模式影响和诊断分析 (FMDA)
g) 失效模式影响分析（FMEA）：
在智能驾驶系统中，FMEA是一个关键的过程，它识别和分析系统中潜在的失效模式及其可能的影响。从图片中可以看到，系统可能会遭遇到各种故障，如“随机硬件故障”和“系统性失效”，这些故障都可能导致“危害事件”的发生。FMEA旨在列出这些潜在的故障模式，评估其发生的概率以及一旦发生时可能带来的后果，从而为后续的改进措施提供依据。在智能驾驶系统中，FMEA是一个关键的过程，它识别和分析系统中潜在的失效
1)诊断分析（D）：
在FMEA的基础上，UL 4600提到的FMEDA加入了诊断分析（D）的元素。这一步主要是评估当某个失效模式发生后，系统是否能够及时诊断出故障并采取相应的措施。这通常涉及到系统的监控和诊断策略，比如使用传感器监测系统的状态，或者使用软件算法分析数据以识别潜在的问题。通过FMEDA，我们可以不仅了解失效模式的影响，还能知道这些影响是否可以被有效地检测和诊断。
2)在智能驾驶系统中的应用：
在智能驾驶系统中，FMEDA被应用于系统的整个设计和开发过程中。首先，在系统设计阶段，通过FMEDA来识别潜在的故障模式，并考虑如何在设计中避免或减轻这些故障的影响。其次，在系统开发过程中，通过FMEDA来评估不同设计选项的风险，并选择最佳方案。最后，在系统测试阶段，使用FMEDA的结果来制定测试用例和策略，以确保系统在实际运行中能够正确地响应各种故障。
h) 危害与可操作性分析 (HAZOP)
1)定义研究范围：
示例：明确要分析的系统边界、功能和操作过程。
2)选择引导词：
示例：引导词用于描述系统可能出现的偏差，如“无”、“多”、“少”、“反向”等。
3)识别偏差：
示例：将引导词应用于系统的各个元素，识别出可能的偏差情况。
4)分析后果：
示例：评估每个偏差可能导致的后果，包括危害事件、系统性损害等。
5)制定措施：
示例：针对每个识别的危害，制定相应的预防或缓解措施。
i) 共因故障 (CCF)分析
CCF分析被用于识别潜在的系统失效模式，评估其对系统安全性的影响，并制定相应的预防和缓解措施。
1)应用过程：
识别潜在CCF源：
示例：分析可能导致CCF的潜在因素，如电源系统、传感器、通信模块等。
2)评估CCF影响：
示例：使用风险评估方法（如FMEA、FTA等）来评估CCF对系统安全性的影响，包括其发生的可能性、严重性和可检测性。
3)制定缓解措施：
示例：根据评估结果，制定相应的缓解措施，如改进系统设计、增加冗余组件、加强监控和检测等。
4)验证与测试：
示例：通过模拟和实验验证缓解措施的有效性，确保系统在面对CCF时能够保持安全和可靠。
j) 共模分析 (CMA)
1)识别潜在共模故障源：
示例：通过分析智能驾驶系统的各个组成部分（如传感器、控制器、通信模块等），识别可能导致共模故障的潜在因素。这些因素可能涉及硬件、软件、环境等多个方面。
2)评估共模故障影响：
评估共模故障对系统安全性和可靠性的影响。
示例：包括分析共模故障发生的可能性、严重性以及可能导致的后果（如车辆失控、事故风险等）。在这个阶段，可以运用风险评估方法（如FMEA、FTA等）来量化评估共模故障的风险水平。
3)制定预防和缓解措施：
根据评估结果，制定相应的预防和缓解措施。
示例：包括改进系统设计、增强系统冗余性、加强监控和诊断能力等。同时，还需要制定应急响应计划，以应对共模故障发生时可能出现的紧急情况。
4)验证和测试：
通过模拟和实验验证预防和缓解措施的有效性。
示例：包括在实验室环境中模拟共模故障场景，测试系统的响应和恢复能力，以确保系统在面对共模故障时能够保持安全和可靠。
k) 区域安全分析 （ZSA）
1)确定评估区域：
根据系统的结构和功能，确定需要进行安全评估的区域或组件。这些区域或组件可能是自动驾驶系统中的关键部分.
示例：感知系统、决策系统、执行系统等。
2)识别潜在风险：
对选定的区域或组件进行深入分析，识别可能存在的安全风险
示例：风险可能来自硬件故障、软件漏洞、传感器误差等方面。
3)评估风险影响：
评估潜在风险对系统安全性的影响.
示例：包括风险的严重性、发生概率以及可检测性等方面。这有助于确定哪些风险需要优先处理。
4)制定缓解措施：
根据风险评估结果，制定相应的缓解措施。
示例：措施可能包括改进系统设计、加强安全保护、提高系统冗余性等。
5)实施验证和测试：
对制定的缓解措施进行验证和测试，确保它们能够有效地降低或消除潜在的安全风险。
l) 系统功能危害分析 （SFHA）
1)识别潜在的系统功能危害：
通过详细审查系统设计文档、功能需求以及可能的操作场景，识别出可能导致系统功能失效的潜在危害。
示例：危害可能源于硬件故障、软件缺陷、外部干扰等多种因素。
2)评估危害的严重性和可能性：
对识别出的潜在危害进行评.，
示例：包括评估其发生的可能性（如暴露概率、触发条件等）以及可能导致的后果（如严重度、系统性损害等）。这个过程需要综合考虑多个因素，如危害事件的频率、持续时间、影响范围等。
3)制定风险控制措施：
根据危害评估的结果，制定相应的风险控制措施。
示例：包括改进系统设计、增加冗余组件、提高系统可靠性等。通过实施这些措施，可以降低危害发生的可能性或减轻其导致的后果。
4)验证和测试：
示例：对实施风险控制措施后的系统进行验证和测试，以确保其能够满足预期的安全性能要求。
包括模拟各种可能的故障场景、进行安全性能测试等。
m) 系统理论过程分析 (STPA)
1)定义系统范围与边界：
在应用STPA之前，首先需要明确定义智能驾驶系统的范围与边界。
示例：这包括确定系统的主要功能、组件以及它们之间的交互关系。
2)识别不安全控制行为：
根据系统定义，识别可能导致不安全状态的控制行为。
示例：这些行为可能包括传感器故障、控制器逻辑错误、执行器故障等。
3)分析控制结构：
使用STPA的控制结构模型（包括控制器、被控过程、传感器和执行器），分析系统中可能存在的控制结构缺陷。
示例：包括控制逻辑错误、传感器信息失真、执行器响应不足等。
4)识别不安全控制行为的前置条件：
识别导致不安全控制行为的前置条件。
示例：环境因素（如天气、道路状况）、系统状态（如车辆速度、加速度）、用户输入（如驾驶员操作）等。
5)制定安全措施：
根据分析结果，制定相应的安全措施来防止或减轻不安全控制行为的影响。
示例：包括改进控制逻辑、增加冗余组件、提高传感器精度等。
通过危害分析方法以及系统可能出现的故障模型、外部威胁（如网络攻击）以及与其他系统或环境的交互等得到的危害与章节6.3、章节6.4提到的危害与网络威胁场景得相结合，得到可能发生的危害事件。
注1：相同的一种危害行为，会因为结合的危害(威胁)场景不同，从而得到多种不同的危害事件，如图4所示。
图4 不同场景导致的不同危害事件示意图
对于如何判定伤害发生的可能概率或者说如何确定伟华事件的可控性，参照汽车安全完整性等级，将危害事件按照其发生的可能性进行划分，如下表所示：
表5 伤害判定等级
-
判定等级标准
判定等级内容
L5
现场没有采取防范措施或危害经常发生
L4
害的发生不容易被发现，或控制措施未有效执行
L3
没有充分保护措施或未严格按操作程序执行
L2
危害能及时发现并有有效的控制措施
L1
有充分、有效的防范措施，极不可能发生事故
注1：在部分条件缺失无法准确得到危害事件的可控性概率的情况下，可以参考L判定等级标准
风险评估旨在评估给定场景中危害行为的风险;这有助于定义SOTIF相关风险的接受准则。
注1:由整车层面功能不足导致的危害行为(如果有)是本评估的一部分。
可以使用GB/T34590.3-2022中第6章描述的方法来评估伤害的严重度和危害事件的可控性尽管共享分析方法,但SOTIF分析中观察到的结果和特定危害的评估参数可以是不同的。
注2:GB/T34590.3-2022给出了可控性、严重度和暴露概率等级。
在本章中,仅考虑危害事件在总体上是否可控,或者是否会导致伤害。暴露概率不是本章风险评估的决定参数。这是因为对场景中需要评估的风险的选择已经意味着它们的暴露与SOTIF相关,否则分析中将不作考虑。
注3:为定义确认目标,可能考虑暴露于特定场景的概率。
示例1:对于因自动紧急制动引发的与主车辆的追尾,可通过限制制动干预的幅度来降低严重度。
幅度限制可被视为增加可控性的安全措施,或视为对预期行为的功能修改。在分析危害时,该限制被认为是预期行为的一部分;与此不同的是,对于该限制在实施过程中的失效,则属于其他安全标准的范畴。考虑危害事件的严重度和可控性,以确定危害行为在给定场景下产生的风险是否合理。严重度和可控性的评估考虑功能规范)。可控性评估包括相关人员为控制危害而做出的“无反应”或“延迟反应”,例如这些反应可能是由可合理预见的间接误用导致的。评估也可考虑外部措施。如果可控性被评为“可控”(即C=0)或严重度被评为“无伤害”(即S=0),则认为不存在不合理的风险。其他情况的危害事件被认为与SOTIF相关。对这些危害行为,使用可测量的参数(如速度的偏差和与其他物体的最小距离)来进行描述,这些参数是危害行为接受准则(第一层接受准则)的来源,对于不符合这些接受准则的危害行为,需要进行合理的应对,并在接下来的SOTIF残余风险评估中予以考虑。
驾驶员延迟的反应或不恰当的反应,包括驾驶员为获得足够的态势感知和恢复控制所需的时间,可能会影响可控性的评估,是SOTIF相关分析时需要考虑的。
危害日志记录了每种危害的严重程度和初始风险，从中确定每种危害的具体严重度等级以及既定的初始风险。
a)使用以下风险评估方法中的至少一种
1)风险表
风险表是一个包含潜在风险的清单，它可以帮助组织或个人识别和评估可能影响项目、业务或决策的各种风险。风险表通常列出了风险的名称、描述、可能性、影响和应对措施等信息。通过对风险表的分析和管理，组织或个人可以采取相应的措施来降低风险的影响，提高决策的准确性和项目的成功率。
2)风险方程式(加权概率乘以严重性)
风险方程式是指通过将风险发生的概率和风险发生后的损失相乘来计算风险值的一种方法。其计算公式为：风险值=概率×影响。
在这个公式中，概率是指风险发生的可能性，通常用百分数表示；影响是指风险发生后可能造成的损失，通常用货币单位表示。
注：这个公式只是一种简单的计算方法，实际应用中还需要考虑其他因素，如风险的可接受性、风险管理的成本效益等。
3)故障树分析(FTA)
故障树分析（Fault Tree Analysis，简称 FTA）是一种系统可靠性分析方法，它通过对可能导致系统故障的各种因素进行分析，找出系统故障的原因和发生概率，从而为系统的设计、运行和维护提供重要的参考依据。故障树分析的基本思想是将系统故障作为顶事件，将导致系统故障的各种因素作为底事件，按照逻辑关系构建一棵倒立的树状图，称为故障树。在故障树中，用事件符号表示系统的各种状态，用逻辑门符号表示事件之间的逻辑关系。
故障树分析的步骤如下：
Ⅰ)确定系统的顶事件，即系统发生的故障或失效事件。
Ⅱ)确定系统的底事件，即导致系统故障的各种因素。
Ⅲ)绘制故障树，根据系统的结构和功能，以及导致系统故障的各种因素，构建一棵倒立的树状图。
Ⅳ)分析故障树，根据故障树的结构和逻辑关系，计算系统故障的概率和原因。
Ⅴ)提出改进措施，根据故障树分析的结果，提出改进系统设计、运行和维护的措施，以降低系统故障的概率。
4) 事件树分析(ETA)
事件树分析（Event Tree Analysis，ETA）是一种从初始事件开始，按时间顺序分析各环节事件状态（成功或失败），直到最终结果的分析方法。它是一种归纳推理法，是安全系统工程中常用的一种分析方法。
事件树分析的步骤如下：
Ⅰ)确定初始事件：即系统中可能发生的初始故障或失效事件。
Ⅱ)构建事件树：根据初始事件和系统的结构和功能，构建一棵倒立的树状图，称为事件树。在事件树中，用事件符号表示系统的各种状态，用逻辑门符号表示事件之间的逻辑关系。
Ⅲ)分析事件树：根据事件树的结构和逻辑关系，计算系统故障的概率和原因。
Ⅳ)提出改进措施：根据事件树分析的结果，提出改进系统设计、运行和维护的措施，以降低系统故障的概率
6)危害分析与风险评估(HARA)
危害分析与风险评估（Hazard Analysis and Risk Assessment，HARA）是一种用于识别、评估和控制潜在危害的方法。它通常用于食品安全、药品安全、工业安全等领域，以确保产品或过程的安全性和可靠性。
HARA 的基本步骤包括：
Ⅰ)危害识别：确定可能导致危害的因素，如生物、化学、物理等。
Ⅱ)风险评估：评估危害的可能性和严重性，以确定风险的级别。
Ⅲ)风险控制：采取措施降低风险，如消除危害源、采用防护措施等。
Ⅳ)风险监测：监测风险控制措施的效果，以确保其有效性。
Ⅴ)风险沟通：将风险评估和控制的结果传达给相关人员，以促进风险意识的提高。
8)系统理论事故模型和过程 (STAMP)
系统理论事故模型和过程（Systems Theory Accident Model and Processes，STAMP）是一种用于分析复杂系统事故的方法。它将系统工程、控制理论和安全工程等多个领域的知识相结合，通过建立系统模型和分析事故过程，来识别和评估系统中的潜在风险和故障，并提出相应的预防和控制措施。
STAMP 的基本思想是将系统视为一个动态的、开放的、自适应的、非线性的复杂系统，其行为受到多种因素的影响和制约。通过建立系统的数学模型和逻辑模型，以及分析事故的过程和原因，STAMP 可以帮助分析人员更好地理解系统的行为和故障模式，从而预测和预防事故的发生。
STAMP 的主要特点包括：
Ⅰ)强调系统的整体性和动态性，将系统视为一个整体，并考虑系统的动态变化和相互作用。
Ⅱ)采用多层次的分析方法，包括系统层次、组件层次和操作层次等，以全面分析系统的行为和故障模式。
Ⅲ)强调人的因素和组织因素的重要性，认为人的行为和组织的决策对系统的安全和可靠性有着重要的影响。
Ⅳ）采用图形化的表示方法，如领结图（Ligament Diagram）和事件树图（Event Tree Diagram）等，以帮助分析人员更好地理解系统的行为和故障模式。
10)其他相关风险评估方法
Ⅰ)风险矩阵法（Risk Matrix Method）：将风险发生的可能性和影响程度分别划分为不同的等级，然后将两者相乘得到风险值，从而评估风险的大小和优先级。
Ⅱ)危害分析与关键控制点（Hazard Analysis and Critical Control Points，简称 HACCP）：通过分析功能过程中的危害因素及其控制措施，从而评估食自动驾驶系统的安全风险的大小和优先级。
注1：推荐使用综合分析方法，以提高风险评估的准确性与可靠性
应根据表6为严重度指定一个So.s1、S2或S3的严重度等级。
注1:危害事件的风险评估关注的是潜在的处于风险中的每个人受到的伤害情况——包括引起危害事件的车辆的
注2:严重度等级的评估可基于对多个伤害的综合性的考量,相比只考虑单一伤害的评估结果而言,这样可能会导致一个较高的严重度评估。
注3:对被评估中的场景,严重度预估需要考虑事件发生的合理顺序。
注4:严重度的确定基于目标市场且有代表性的个体样本。
表6 严重度等级
等级 |
S0 |
S1 |
S2 |
S3 |
描述 |
无伤害 |
轻度和中度伤害 |
严重的和危机生命的伤害（有存活可能） |
危及生命的伤害（存活不确定），致命的伤害 |
操作条件下暴露于危险中的可能性。能性被分为 5 个等级，即：E0，E1，
E2，E3，E4，具体分级见下表。至于暴露值是选 E1还是选 E2，主要看车辆在目标市场正常、合理的使用情况。这里要注意的是，评估暴露于危险中的可能性并不考虑在车上安装了多少个要评估的产品，且假设了所有的车上都安装了这个产品。对于那种认为不是每辆车都安装的产品，其相应的暴露在危险中的可能性会减小的说法也是错误的。
表7 暴露度等级
-
等级
E0
E1
E2
E3
E4
描述
几乎不可能
可能性非常低
可能性低
中等可能性
可能性高
危险事件能被司机或者其他交通参与人员进行控制并减小或者避免伤害的可能性。可控性被分为 4个等级，即：C0，C1，C2，C3。但要注意，使用这个分级的条件是司机处于正常状态，即：不疲劳，有驾照，按照交通规则行驶，当然，其中要考虑可预见的误操作和误使用。 四个级别为：
表8 可控性等级
等级 |
C0 |
C1 |
C2 |
C3 |
描述 |
通常可控 |
简单可控 |
正常可控 |
很难控制或不可控 |
在智能驾驶项目中，从项目风险提取安全需求和安全目标是一个至关重要的过程。结合智能驾驶安全标准ISO 21434、UL 4600、GB/T 43267（尽管GB/T 43267并非直接针对智能驾驶，但我们可以参考其预期功能安全的概念）和ISO 26262，我们可以设计如下方法来提取安全需求和安全目标：
a) 项目风险识别
1)分析项目需求、设计、实施、测试和维护等阶段可能面临的风险。
2)考虑硬件、软件、网络、功能等各方面的潜在风险。
3)利用故障树分析（FTA）、失效模式和影响分析（FMEA）等工具辅助风险识别。
b) 风险分析与评估
1)对识别出的风险进行定性和定量分析。
2)确定风险的严重程度、可能性和可检测性。
3)利用风险评估矩阵等工具对风险进行排序和优先级划分。
c) 安全需求提取
1)针对每个已评估的风险，制定针对性的安全需求。
2)安全需求应明确、可验证，并涵盖预防、检测、响应等方面。
3)考虑系统在整个生命周期内的安全需求，包括设计、开发、测试、部署和维护等阶段。
d) 安全目标设定
1)根据安全需求，设定明确、可衡量的安全目标。
2)安全目标应涵盖系统关键功能的安全性、数据保护、系统可用性等方面。
3)考虑目标的可行性、经济性和时效性，确保目标的可实现性和可持续性。
e) 验证与确认
1)制定详细的验证和确认计划，包括测试方法、测试场景、测试数据等。
2)实施测试，并对测试结果进行分析和评估。
3)根据测试结果，对安全需求和安全目标进行必要的调整和优化。
f) 持续改进
1)建立安全监控和评估机制，定期评估系统的安全状况。
2)收集和分析系统的运行数据，发现潜在的安全隐患和问题。
3)针对发现的问题，制定改进措施并付诸实施。
4)不断学习和借鉴新的安全技术和方法，提升系统的安全防护能力。
注1：8.4应为具有ASIL等级的每个危害事件确定一个安全目标,该ASIL等级从危害分析中得出。如果所确定的安全目标是类似的,可将其合并为一个安全目标。
注2:安全目标是相关项最高层面的安全要求。安全目标导出功能安全要求,以避免每个危害事件的不合理风险。安全目标不表述为技术解决方案,而表述为功能目的。
应将为危害事件所确定的ASIL等级分配给对应的安全目标。如果将类似的安全目标合并为一个安全目标,应将最高的ASIL等级分配给合并后的安全目标。
注1:如果合并后的安全目标是针对不同场景下的相同的危害,则安全目标的ASIL.等级是每种场景下所考虑的安全目标中最高的一个.
项目级风险标准是指在项目管理中，为了评估和管理风险而制定的一系列标准和指标。这些标准通常包括风险的概率、影响、优先级等方面的评估，以及针对不同风险级别的应对措施和管理策略。
项目级风险标准的制定需要考虑项目的特点、目标、范围、资源等因素，同时也需要考虑项目所处的环境和背景。通过制定项目级风险标准，可以帮助项目团队更好地识别和评估风险，制定合理的风险管理策略，从而降低项目风险的影响，提高项目的成功率。
注1：不同的项目和组织可能会有不同的项目级风险标准，因此在制定项目级风险标准时，需要根据实际情况进行调整和优化。
制定风险缓解策略是风险管理的重要环节，以下是一些步骤：
a)识别风险：
需要识别可能会影响项目或业务的风险。这可以通过风险评估、头脑风暴、历史数据分析等方法来完成。
b)分析风险：
对识别出的风险进行分析，确定其可能性和影响程度。这可以帮助你确定哪些风险需要优先处理。
c)制定策略：
根据风险分析的结果，制定相应的风险缓解策略
示例：包括风险规避、风险转移、风险减轻和风险接受等。
d)实施策略：
将制定的风险缓解策略付诸实施。这可能需要采取一些具体的行动
示例：购买保险、建立备份系统、调整项目计划等。
e)监控风险：
在实施风险缓解策略的过程中，需要对风险进行监控，以确保策略的有效性。如果发现风险仍然存在或有所变化，需要及时调整策略。
结合智能驾驶安全标准ISO 21434、UL 4600、GB/T 43267和ISO 26262，以下是对风险缓解策略的详细说明和示例：
a)ISO 21434：汽车网络安全标准
1)风险缓解策略：
加强网络安全防护：通过采用先进的网络安全技术和加密算法，保护自动驾驶汽车的通信和数据安全。
建立网络安全团队：实时监控和应对网络攻击，确保系统的安全性。
2)具体体现：
自动驾驶系统使用加密技术保护车辆与基础设施之间的通信数据。设立专门的网络安全部门，负责监控网络威胁并及时响应。
b)UL 4600：自动驾驶车辆安全标准
1)风险缓解策略：
系统级安全案例：提供指导，确保自动驾驶系统在设计、开发和验证过程中遵循安全原则。
冗余设计：在关键组件中采用冗余设计，以提高系统的可靠性和安全性。
2)具体体现：
在自动驾驶汽车中，采用多个传感器进行环境感知，并通过数据融合提高感知准确性。
在自动驾驶系统的控制单元中，使用冗余的硬件和软件设计，确保在单一组件失效时系统仍能正常运行。
c)ISO 21448：道路车辆预期功能安全标准
1)风险缓解策略：
考虑预期外功能失效：评估自动驾驶系统在预期外场景下的安全性，并制定相应的风险缓解措施。
提供故障降级模式：在自动驾驶系统出现故障时，提供降级模式以确保车辆能够安全停车或切换到人工驾驶模式。
2)具体体现：
在自动驾驶汽车中，设置多种故障检测机制，一旦发现预期外的功能失效，立即切换到故障降级模式。
提供紧急接管功能，允许驾驶员在需要时接管车辆控制权。
d)ISO 26262：道路车辆功能安全标准
1)风险缓解策略：
功能安全概念：制定功能安全概念，明确系统的安全目标和安全性能要求。
风险分析和评估：通过风险分析和评估确定ASIL等级，指导安全性能需求定义。
故障检测与诊断：实施故障检测、诊断和容错措施，确保在故障发生时系统能够安全地运行或停车。
2)具体体现：
在自动驾驶汽车中，使用高级驾驶辅助系统（ADAS）进行实时环境感知和决策，并在检测到潜在危险时向驾驶员发出警告。
在系统设计中采用故障检测机制，如传感器自检、控制器自检等，确保在故障发生时能够及时发现并采取相应的措施。
2)示例
当自动驾驶汽车的摄像头在恶劣天气下受到影响导致视觉感知失效时，激光雷达和毫米波雷达等其他传感器可以提供冗余的感知信息，确保车辆能够继续安全行驶。
在自动驾驶汽车的控制单元中，如果主控制器出现故障，备用控制器可以立即接管控制权，确保车辆能够安全停车或继续行驶至安全区域。
缓解效果指标是指用于衡量风险缓解措施效果的指标，通常包括以下几个方面：
a)风险降低程度
风险缓解措施实施后，风险发生的可能性和影响程度降低的程度。
b)成本效益比
风险缓解措施的成本与预期收益的比值，用于衡量风险缓解措施的经济性。
c)实施难度
风险缓解措施实施的难易程度，包括技术难度、实施周期等。
d)可操作性
风险缓解措施的可操作性，包括是否易于实施、是否需要特殊的技能和知识等。
e)可持续性:
风险缓解措施的可持续性，即是否能够长期有效地降低风险。
当涉及到智能驾驶的风险缓解效果指标与分析时，一个综合的方法需要确保系统在整个设计和运行周期内都具备高度的安全性和可靠性。
a)透明度和可追溯性的要求：
1)确保智能驾驶系统的决策过程具有透明度和可追溯性，以便在发生事故时进行责任追踪和事故分析。
2)记录系统的关键数据和决策逻辑，以便在需要时进行审计和验证。
3)提供清晰的用户界面和反馈机制，让用户能够了解系统的状态和决策过程。
b)安全生命周期的考虑：
1)将安全性作为智能驾驶系统设计和开发的核心原则，从需求分析到部署维护的每个阶段都充分考虑安全因素。
2)在系统的整个生命周期内，持续进行风险评估、监控和更新，确保系统的安全性能够随着技术和环境的变化而得到维护。
c)透明度和可追溯性的要求：
1)确保智能驾驶系统的决策过程具有透明度和可追溯性，以便在发生事故时进行责任追踪和事故分析。
2)记录系统的关键数据和决策逻辑，以便在需要时进行审计和验证。
3)提供清晰的用户界面和反馈机制，让用户能够了解系统的状态和决策过程。
d)测试与验证的严谨性：
1)制定严格的测试计划和方法，包括模拟测试、实地测试、仿真等，以确保智能驾驶系统在各种情况下都能达到预期的安全性能。
2)在测试过程中，模拟各种可能的场景和故障情况，以验证系统的稳定性和鲁棒性。
3)收集和分析测试数据，评估系统的安全性和可靠性，并根据需要进行迭代和优化。
e)冗余设计与容错机制：
1)在关键组件和系统中采用冗余设计，以提高系统的可靠性和容错能力。
2)设计故障降级模式，在系统出现故障时能够自动切换到备用模式或降级模式，确保车辆能够安全停车或继续行驶至安全区域。
3)实时监控系统的状态和性能，及时发现并处理潜在的安全隐患。
风险报告是风险管理的重要组成部分，它可以帮助组织了解风险状况，制定相应的风险应对措施，提高风险管理的效率和效果。以下是一些制定风险报告的步骤：
a)确定报告的目的和受众：
在制定风险报告之前，需要明确报告的目的和受众。报告的目的可能是向管理层汇报风险状况，为决策提供支持，或者向利益相关者通报风险信息等。受众可能是管理层、董事会、投资者、监管机构等。
b)收集和整理风险信息：
收集和整理风险信息是制定风险报告的基础。可以通过风险评估、风险监测、风险审计等方式收集风险信息。在收集风险信息的过程中，需要注意信息的准确性和完整性。
c)分析风险状况：
在收集和整理风险信息的基础上，需要对风险状况进行分析。可以采用定性和定量分析相结合的方法，对风险的可能性、影响程度、优先级等进行评估。
b)制定风险应对措施：
根据风险分析的结果，制定相应的风险应对措施。风险应对措施可以包括风险规避、风险转移、风险减轻和风险接受等。
e)撰写风险报告：
在制定风险应对措施的基础上，撰写风险报告。风险报告通常包括风险概述、风险分析、风险应对措施、风险监测和风险评估等内容。
f)审核和批准风险报告：
在撰写风险报告之后，需要对报告进行审核和批准。审核和批准的人员通常是管理层、董事会或其他相关人员。
g)发布和沟通风险报告：
在审核和批准风险报告之后，需要将报告发布和沟通给相关人员。发布和沟通的方式可以是电子邮件、会议、报告等。
h)监测和更新风险报告：
风险报告不是一次性的文件，需要定期监测和更新。在监测和更新风险报告的过程中，需要关注风险的变化情况，及时调整风险应对措施。