智能驾驶系统：软件融合设计案例分析文档
|
文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 |
|
发文件起草分工： 1. |
|
编制： |
签名： 日期： |
|
审核： |
签名： 日期： |
|
批准： |
签名： 日期： |
|
所有权声明 |
|
该文档及其所含的信息是财产。该文档及其所含信息的复制、使用及披露必须得到的书面授权。 |
未实施安全要求的软件架构 如下图所示。
自动紧急换道系统的软件原始架构包含感知、决策规划与控制三大核心模块 。其中，感知模块作为系统信息输入的前端，集成了来自 P - BOX 、 T - BOX 、摄像头、毫米波雷达等多源设备的数据，经由各传感器感知单元获取原始信息，并通过感知信息融合技术提炼出有效感知信息，为后续决策规划提供基础支撑；决策规划模块基于感知信息，依托 TTC 换道模型进行换道时机等判断，并运用五次多项式轨迹规划算法，生成合理的换道轨迹规划信息；控制模块则依据规划信息，借助 MPC 横向控制与纵向控制策略，协同人机交互功能，对线控制动系统及人机交互系统等执行机构发出指令，实现自动紧急换道的精准控制与交互反馈，各模块相互协作，构成系统运行的完整逻辑流程 。
技术安全要求导出 软件 安全要求，如下图所示，即需要在 软 件层面采取具体措施来实现技术安全要求，为了更加全面地实现技术安全要求，在技术安全要求导出 软件 安全要求中，需要借助分析方法，结合原始的软件架构，本案例中采用 FTA 故障树的方法，结合原始 软 件架构，对技术安全要求逐一进行分析 。
|
TSR2.1.3.1.1.1 |
实时 持续监 测 摄像头 自检信号来识别故障状态 |
D |
DC |
|
|
|||
|
(F)SSR-01-01 |
实时周期性地读取并解析摄像头的自检信号 |
D |
DC |
|
(F)SSR-01-02 |
应实现故障状态识别算法，能够根据自检信号识别摄像头的故障类型以及故障程度（电源故障、图像信号处理故障、通讯故障） |
D |
DC |
|
(F)SSR-01-03 |
识别到故障状态后，立即更新摄像头故障状态，并触发故障处理流程 |
D |
DC |
|
TSR2.1.3.1.1.2 |
摄像头的冗余设计与故障隔离，包含冗余摄像头以及冗余通讯回路 |
D |
DC |
|
|
|||
|
(F)SSR-02-01 |
应同时支持两个摄像头的初始化、配置和数据采集 |
D |
DC |
|
(F)SSR-02-02 |
应通过两条独立的通信回路与摄像头通信，且两条回路应物理隔离 |
D |
DC |
|
(F)SSR-02-03 |
应验证冗余配置完整性，在启动时执行主冗余回路自检 |
D |
DC |
|
TSR2.1.3.1.1.3 TSR2.1.3.1.2.4 TSR2.1.3.1.3.4 |
根据主冗余摄像头故障状态、运行工况、网络攻击状态来切换摄像头工作 |
D |
DC |
|
|
|||
|
(I)SSR-01-01 |
实时监测比较主冗余摄像头的故障状态、运行状态、攻击状态来切换摄像头工作 |
D |
DC |
|
(I)SSR-01-02 |
主摄像头异常时立即切换到冗余摄像头，不能影响摄像头的感知作用 |
D |
DC |
|
(I)SSR-01-03 |
在切换后对原主摄像头进行复位操作，并尝试恢复主摄像头 |
D |
DC |
|
TSR2.1.3.1.1.4 |
实时评估故障状态对工作摄像头感知的影响程度 |
D |
DC |
|
|
|||
|
(F)SSR-03-01 |
应基于故障类型和故障参数（如故障持续时间、严重程度）计算当前工作摄像头感知能力的置信度 |
D |
DC |
|
(F)SSR-03-02 |
应实时周期性地将评估的置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3.1.2.1 |
实时 感知信息进行检测 来识别摄像头的运行工作状况 |
D |
DC |
|
|
|||
|
(S)SSR-01-01 |
实时对车辆行驶天气进行检测，来识别 摄像头的运行工作状况 |
B |
DC |
|
(S)SSR-01-02 |
实时对车辆驾驶场景进行检测，来识别 摄像头的运行工作状况 |
B |
DC |
|
TSR2.1.3.1.2.2 |
实时评估运行工作状况对摄像头感知的影响程度 |
D |
DC |
|
|
|||
|
(S)SSR-02-01 |
应基于运行工况和工况恶劣程度（如持续时间、严重程度）计算当前工作摄像头感知能力的置信度 |
D |
DC |
|
(S)SSR-02-02 |
应实时周期性地将评估的置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3.1.3.1 |
实时持续进行（主冗余）摄像头信号正确性检验来识别网络攻击 |
D |
DC |
|
|
|||
|
(C)SSR-01-01 |
利用冗余设计，实现差异检验机制，比较主摄像头和冗余摄像头的信号在允许的时间差内的一致性来检测攻击 |
D |
DC |
|
(C)SSR-01-02 |
应实现网络攻击识别算法，能够根据图像信号识别摄像头的网络攻击类型以及攻击程度 |
D |
DC |
|
(C)SSR-01-03 |
识别到网络攻击后，立即更新摄像头攻击状态，并触发攻击响应流程 |
D |
DC |
|
TSR2.1.3.1.3.2 |
主冗余 摄像头的身份验证与加密处理 |
D |
DC |
|
|
|||
|
(C)SSR-02-01 |
在摄像头初始化时进行双向身份认证，未通过认证的摄像头不得使用 |
D |
DC |
|
(C)SSR-02-02 |
对所有传输的图像数据和控制命令进行数据加密校验处理 |
D |
DC |
|
TSR2.1.3.1.3.5 |
实时评估网络攻击状态对工作摄像头感知的影响程度 |
D |
DC |
|
|
|||
|
(C)SSR-3-01 |
应基于网络攻击类型和攻击参数（如持续时间、严重程度）计算当前工作摄像头感知能力的置信度 |
D |
DC |
|
(C)SSR-3-02 |
应实时周期性地将评估的置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3.1.2.3 |
根据摄像头的影响程度来对多传感器感知融合权重的调整 |
D |
DC |
|
|
|||
|
(I)SSR-2-01 |
设计感知融合权重动态调整算法，使得摄像头置信度降低时，其权重降低，其他传感器权重相应提高 |
D |
DC |
|
(I)SSR-2-02 |
确保权重调整后，多传感器融合系统的整体置信度可靠 |
D |
DC |
|
TSR2.1.3.2.1.1 |
实时 持续监 测毫米波雷达自检信号来识别故障状态 |
D |
DC |
|
|
|||
|
(F)SSR-0 4 -01 |
实时周期性地读取并解析 毫米波雷达 的自检信号 |
D |
DC |
|
(F)SSR-0 4 -02 |
应实现故障状态识别算法，能够根据自检信号识别雷达的故障类型以及故障程度 |
D |
DC |
|
(F)SSR-0 4 -03 |
识别到故障状态后，立即更新 毫米波雷达 故障状态，并触发故障处理流程 |
D |
DC |
|
TSR2.1.3.2.1.2 |
毫米波雷达 的冗余设计 与故障隔离 ，包含冗余 雷达 以及冗余通讯回路 |
D |
DC |
|
|
|||
|
(F)SSR-0 5 -01 |
应同时支持两个 毫米波雷达 的初始化、配置和数据采集 |
D |
DC |
|
(F)SSR-0 5 -02 |
应通过两条独立的通信回路与 毫米波雷达 通信，且两条回路应物理隔离 |
D |
DC |
|
(F)SSR-0 5 -03 |
应验证冗余配置完整性，在启动时执行主冗余回路自检 |
D |
DC |
|
TSR2.1.3.2.1.3 TSR2.1.3.2.2.4 TSR2.1.3.2.3.4 |
根据主冗余雷达故障状态、运行工况、网络攻击状态来切换 毫米波雷达 工作 |
D |
DC |
|
|
|||
|
( I )SSR-03-01 |
实时监测比较主冗余 毫米波雷达 的故障状态、运行状态、攻击状态来切换 毫米波雷达 工作 |
D |
DC |
|
( I )SSR-03-02 |
主 毫米波雷达 异常时立即切换到冗余 毫米波雷达 ，不能影响 毫米波雷达 的感知作用 |
D |
DC |
|
( I )SSR-03-03 |
在切换后对原主 毫米波雷达 进行复位操作，并尝试恢复主 毫米波雷达 |
D |
DC |
|
TSR2.1.3.2.1.4 |
实时评估故障状态对工作 毫米波雷达 感知的影响程度 |
D |
DC |
|
|
|||
|
(F)SSR-0 6 -01 |
应基于故障类型和故障参数（如故障持续时间、严重程度）评估当前工作 毫米波雷达 感知能力的置信度 |
D |
DC |
|
(F)SSR-0 6 -02 |
应实时周期性地将评估的 毫米波雷达 置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3.2.2.1 |
实时 感知信息进行检测 来识别 毫米波雷达 的运行工作状况 |
D |
DC |
|
|
|||
|
(S)SSR-0 3 -01 |
实时对车辆行驶天气进行检测，来识别 毫米波雷达 的运行工作状况 |
B |
DC |
|
(S)SSR-0 3 -02 |
实时对车辆驾驶场景进行检测，来识别 毫米波雷达 的运行工作状况 |
B |
DC |
|
TSR2.1.3.2.2.2 |
实时评估运行工作状况对 毫米波雷达 感知的影响程度 |
D |
DC |
|
|
|||
|
( S )SSR-0 4 -01 |
应基于运行工况和工况恶劣程度（如持续时间、严重程度）评估当前工作 毫米波雷达 感知能力的置信度 |
D |
DC |
|
( S )SSR-0 4 -02 |
应实时周期性地将评估的 毫米波雷达 置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3.2.3.1 |
实时持续进行（主冗余） 毫米波雷达 信号正确性检验来识别网络攻击 |
D |
DC |
|
|
|||
|
( C )SSR-0 4 -01 |
利用冗余设计，实现差异检验机制，比较主 毫米波雷达 和冗余 毫米波雷达 的信号在允许的时间差内的一致性来检测攻击 |
D |
DC |
|
( C )SSR-0 4 -02 |
应实现网络攻击识别算法，能够根据点云信号识别 毫米波雷达 的网络攻击类型以及攻击程度 |
D |
DC |
|
( C )SSR-0 4 -03 |
识别到网络攻击后，立即更新 毫米波雷达 攻击状态，并触发攻击响应流程 |
D |
DC |
|
TSR2.1.3.2.3.2 |
主冗余毫米波雷达 的身份验证与加密处理 |
D |
DC |
|
|
|||
|
( C )SSR-0 5 -01 |
在 毫米波雷达 初始化时进行双向身份认证，未通过认证的 毫米波雷达 不得使用 |
D |
DC |
|
( C )SSR-0 5 -02 |
对所有传输的点云数据和控制命令进行数据加密校验处理 |
D |
DC |
|
TSR2.1.3.2.3.5 |
实时评估网络攻击状态对工作 毫米波雷达 感知的影响程度 |
D |
DC |
|
|
|||
|
( C )SSR- 06 -01 |
应基于网络攻击类型和攻击参数（如持续时间、严重程度）计算当前工作 毫米波雷达 感知能力的置信度 |
D |
DC |
|
( C )SSR- 06 -02 |
应实时周期性地将评估的 毫米波雷达 置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3.2.2.3 |
根据 毫米波雷达 的影响程度来对多传感器感知融合权重的调整 |
D |
DC |
|
|
|||
|
(I)SSR- 04 -01 |
设计感知融合权重动态调整算法，使得 毫米波雷达 置信度降低时，其权重降低，其他传感器权重相应提高 |
D |
DC |
|
(I)SSR- 04 -02 |
确保权重调整后，多传感器融合系统的整体置信度可靠 |
D |
DC |
|
TSR2.1.3. 3 .1.1 |
实时 持续监 测 V2X 自检信号来识别故障状态 |
D |
DC |
|
|
|||
|
(F)SSR-0 7 -01 |
实时周期性地读取并解析 V2X 的自检信号 |
D |
DC |
|
(F)SSR-0 7 -02 |
应实现故障状态识别算法，能够根据自检信号识别 V2X 的故障类型以及故障程度 |
D |
DC |
|
(F)SSR-0 7 -03 |
识别到故障状态后，立即更新 V2X 故障状态，并触发故障处理流程 |
D |
DC |
|
TSR2.1.3. 3 .1.2 |
V2X 的冗余设计 与故障隔离 ，包含冗余 V2X 以及冗余通讯回路 |
D |
DC |
|
|
|||
|
(F)SSR-0 8 -01 |
应同时支持两个 V2X 的初始化、配置和数据采集 |
D |
DC |
|
(F)SSR-0 8 -02 |
应通过两条独立的通信回路与 V2X 通信，且两条回路应物理隔离 |
D |
DC |
|
(F)SSR-0 8 -03 |
应验证冗余配置完整性，在启动时执行主冗余回路自检 |
D |
DC |
|
TSR2.1.3. 3 .1.3 TSR2.1.3. 3 .2.4 TSR2.1.3. 3 .3.4 |
根据主冗余 V2X 故障状态、运行工况、网络攻击状态来切换 V2X 工作 |
D |
DC |
|
|
|||
|
( I )SSR-0 5 -01 |
实时监测比较主冗余 V2X 的故障状态、运行状态、攻击状态来切换 V2X 工作 |
D |
DC |
|
( I )SSR-0 5 -02 |
主 V2X 异常时立即切换到冗余 V2X ，不能影响 V2X 的感知作用 |
D |
DC |
|
( I )SSR-0 5 -03 |
在切换后对原主 V2X 进行复位操作，并尝试恢复主 V2X |
D |
DC |
|
TSR2.1.3. 3 .1.4 |
实时评估故障状态对工作 V2X 感知的影响程度 |
D |
DC |
|
|
|||
|
(F)SSR-0 9 -01 |
应基于故障类型和故障参数（如故障持续时间、严重程度）评估当前工作 V2X 感知能力的置信度 |
D |
DC |
|
(F)SSR-0 9 -02 |
应实时周期性地将评估的 V2X 置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3. 3 .2.1 |
实时 感知信息进行检测 来识别 V2X 的运行工作状况 |
D |
DC |
|
|
|||
|
(S)SSR-05-01 |
实时对车辆行驶天气进行检测，来识别 V2X 的运行工作状况 |
B |
DC |
|
(S)SSR-05-02 |
实时对车辆驾驶场景进行检测，来识别 V2X 的运行工作状况 |
B |
DC |
|
TSR2.1.3. 3 .2.2 |
实时评估运行工作状况对 V2X 感知的影响程度 |
D |
DC |
|
|
|||
|
( S )SSR-06-01 |
应基于运行工况和工况恶劣程度（如持续时间、严重程度）评估当前工作 V2X 感知能力的置信度 |
D |
DC |
|
( S )SSR-06-02 |
应实时周期性地将评估的 V2X 置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3. 3 .3.1 |
实时持续进行（主冗余） V2X 信号正确性检验来识别网络攻击 |
D |
DC |
|
|
|||
|
( C )SSR-07-01 |
利用冗余设计，实现差异检验机制，比较主 V2X 和冗余 V2X 的信号在允许的时间差内的一致性来检测攻击 |
D |
DC |
|
( C )SSR-07-02 |
应实现网络攻击识别算法，能够根据 V2X 信号识别 V2X 的网络攻击类型以及攻击程度 |
D |
DC |
|
( C )SSR-0 7 -03 |
识别到网络攻击后，立即更新 V2X 攻击状态，并触发攻击响应流程 |
D |
DC |
|
TSR2.1.3. 3 .3.2 |
主冗余 V2X 的身份验证与加密处理 |
D |
DC |
|
|
|||
|
( C )SSR-0 8 -01 |
在 V2X 初始化时进行双向身份认证，未通过认证的 V2X 不得使用 |
D |
DC |
|
( C )SSR-0 8 -02 |
对所有传输的 V2X 数据和控制命令进行数据加密校验处理 |
D |
DC |
|
TSR2.1.3. 3 .3.5 |
实时评估网络攻击 状态 对工作 V2X 感知的影响程度 |
D |
DC |
|
|
|||
|
( C )SSR- 09 -01 |
应基于网络攻击类型和攻击参数（如持续时间、严重程度）计算当前工作 V2X 感知能力的置信度 |
D |
DC |
|
( C )SSR- 09 -02 |
应实时周期性地将评估的 V2X 置信度传递给感知融合模块 |
D |
DC |
|
TSR2.1.3. 3 .2.3 |
根据 V2X 的影响程度来对多传感器感知融合权重的调整 |
D |
DC |
|
|
|||
|
(I)SSR- 06 -01 |
设计感知融合权重动态调整算法，使得 V2X 置信度降低时，其权重降低，其他传感器权重相应提高 |
D |
DC |
|
(I)SSR- 06 -02 |
确保权重调整后，多传感器融合系统的整体置信度可靠 |
D |
DC |
|
TSR2.3.2.1.1 |
实时持续监测问答机制检测信号来识别定位信息通讯状态 |
D |
DC |
|
|
|||
|
(F)SSR- 10 -01 |
实时周期性地问答握手协议，监测定位 通讯 链路状态 |
D |
DC |
|
(F)SSR- 10 -02 |
应实现故障状态识别算法，能够根据问答握手协议 状况 识别定位 通讯 链路的故障类型以及故障程度 |
D |
DC |
|
(F)SSR-1 0 -03 |
识别到故障状态后，立即更新定位 通讯 链路故障状态，并触发故障处理流程 |
D |
DC |
|
TSR2.3.2.1.2 |
车辆定位信息传输链路的冗余设计与故障隔离 |
D |
DC |
|
|
|||
|
(F)SSR- 11 -01 |
应通过两条独立的 车辆定位信息 通信回路，且两条回路应物理隔离 |
D |
DC |
|
(F)SSR- 11 -02 |
应验证冗余配置完整性，在启动时执行主冗余回路自检 |
D |
DC |
|
TSR2.3.2.1.3
|
根据主冗余 定位信息通讯链路 故障状态、网络攻击状态来切换 通信回路 工作 |
D |
DC |
|
|
|||
|
( I )SSR-0 7 -01 |
实时监测比较主冗余 定位信息通讯链路 的故障状态、运行状态、攻击状态来切换 通信回路 工作 |
D |
DC |
|
( I )SSR-0 7 -02 |
主 通信回路 异常时立即切换到冗余 通信回路 ，不能影响 车辆的定位功能 |
D |
DC |
|
( I )SSR-0 7 -03 |
在切换后对原主 通信回路 进行复位操作，并尝试恢复主 通信回路 |
D |
DC |
|
TSR2.3.2.1.4 TSR2.3.2.3.4 |
定位信息通讯容错抗攻击鲁棒横向换道控制 |
D |
DC |
|
|
|||
|
( I )SSR-0 8 -01 |
对定位信息进行滤波处理，增强抗干扰能力 |
D |
DC |
|
( I )SSR-0 8 -02 |
主冗余定位信息异常状态下鲁棒定位算法 |
D |
DC |
|
( I )SSR-0 8 -03 |
实现横向控制容错机制，定位估计偏差大时限制换道 |
D |
DC |
|
TSR2.3.2.3.1 |
实时持续 对 主冗余 定位信息 进行 攻击 检测 |
D |
DC |
|
|
|||
|
( C )SSR- 10 -01 |
利用冗余设计，实现差异检验机制，比较主 定位信息 和冗余 定位信息 的信号在允许的时间差内的一致性来检测攻击 |
D |
DC |
|
( C )SSR- 10 -02 |
应实现网络攻击识别算法，能够根据 定位信息 识别 定位信息 的网络攻击类型以及攻击程度 |
D |
DC |
|
( C )SSR- 10 -03 |
识别到网络攻击后，立即更新 定位信息 攻击状态，并触发攻击响应流程 |
D |
DC |
|
TSR2.3.2.2.2 |
（主冗余车辆定位信息传输）采用高速传输通讯方式，确保车辆定位信息传输实时可靠 |
D |
DC |
|
|
|||
|
(S)SSR-07-01 |
采用高传输速率的通讯协议，确保定位信息通讯高速传输 |
D |
DC |
|
(S)SSR-07-02 |
提高代码的通讯效率，确保定位信息通讯高速传输 |
D |
DC |
|
TSR2.3.2.3.2 |
主冗余车辆定位信息安全通信 |
D |
DC |
|
|
|||
|
( C )SSR- 11 -01 |
定位信息传输前进行加密处理 |
D |
DC |
|
( C )SSR- 11 -02 |
定位信息获取时进行解密校验 |
D |
DC |
2.3 横向控制单元异常软件安全要求
|
TSR2.3.4.1.1 TSR2.3.4.3.1 |
横向控制算法数据冗余备份与安全存储，确保车辆横向控制的正常启动 |
D |
DC |
|
|
|||
|
( I )SSR-0 9 -01 |
在非易失性存储器中存储至少两份互为备份的控制算法参数 |
D |
DC |
|
( I )SSR-0 9 -02 |
使用加密存储（如 AES-256 ）保护控制算法参数 |
D |
DC |
|
( I )SSR-0 9 -0 3 |
实现安全启动机制，在启动过程中验证算法数据的完整性和真实性 |
D |
DC |
|
( I )SSR-0 9 -0 4 |
定期（如每 24 小时）检查备份数据的完整性并修复损坏 |
D |
DC |
|
TSR2.3.4.1.2 |
实时持续监测 MCU 的自检信号来识别横向控制模块故障状态 |
D |
DC |
|
|
|||
|
(F)SSR- 12 -01 |
实时周期性地读取 MCU 自检状态寄存器 |
D |
DC |
|
(F)SSR- 12 -02 |
实现故障诊断算法，能够根据自检信号识别故障类型以及故障程度 |
D |
DC |
|
(F)SSR- 12 -03 |
检测到故障 后，立即更新 横向控制模块故障 状态，并触发 故障处理 流程 |
D |
DC |
|
TSR2.3.4.3.2 |
实时持续 对 主冗余 横向控制单元进行 攻击 检测 |
D |
DC |
|
|
|||
|
( C )SSR- 12 -01 |
利用冗余设计，实现差异检验机制，比较主 横向控制单元 和冗余 横向控制单元 的信号在允许的时间差内的一致性来检测攻击 |
D |
DC |
|
( C )SSR- 12 -02 |
应实现网络攻击 入侵检测 算法，能够根据 异常行为 识别 横向控制单元 的网络攻击类型以及攻击程度 |
D |
DC |
|
( C )SSR- 12 -03 |
识别到网络攻击后，立即更新 横向控制单元 攻击状态，并触发攻击响应流程 |
D |
DC |
|
TSR2.3.4.1.3 |
车辆 横向控制单元 的冗余设计与故障隔离 |
D |
DC |
|
|
|||
|
(F)SSR- 13 -01 |
应通过两条独立的 车辆横向控制单元 ，且两条回路应物理隔离 |
D |
DC |
|
(F)SSR- 13 -02 |
实现故障隔离机制，确保单个 横向 控制单元的故障不会影响另一个单元 |
D |
DC |
|
(F)SSR- 13 -02 |
应验证冗余配置完整性，在启动时执行主冗余 横向控制单元 自检 |
D |
DC |
|
TSR2.3.4.3.3 |
（主冗余）横向控制单元网络安全隔离与防护设计 |
D |
DC |
|
|
|||
|
( C )SSR- 13 -01 |
横向控制模块 应配置入侵检测，检测异常模式 |
D |
DC |
|
( C )SSR- 13 -02 |
横向控制模块 应配置防火墙规则，仅允许授权通信 |
D |
DC |
|
TSR2.3.4.2.2 |
实时检测车辆实时状态以及外部驾驶条件 |
D |
DC |
|
|
|||
|
( S )SSR-0 8 -01 |
实时采集车辆状态（车速、横摆角速度、方向盘转角等） |
D |
DC |
|
( S )SSR-0 8 -02 |
实时采集外部环境信息（路面状况、周围车辆等） |
D |
DC |
|
( S )SSR-08-03 |
验证传感器数据的有效性，确保检测驾驶条件真实有效 |
D |
DC |
|
TSR2.3.4.2.4 |
（主冗余）横向控制单元根据车辆的实时状态和外部环境的变化，自动调整控制参数 |
D |
DC |
|
|
|||
|
( S )SSR-0 9 -01 |
实现基于车辆状态与外部驾驶条件的 横向 控制参数自适应调整算法 |
D |
DC |
|
( S )SSR-0 9 -02 |
设计参数调整的安全边界，防止参数超出安全范围 |
D |
DC |
|
TSR2.3.4.1.4
|
根据主冗余横向控制单元故障状态、网络攻击状态来切换横向控制单元工作 |
D |
DC |
|
|
|||
|
( I )SSR- 10 -01 |
实时监测比较主冗余 横向控制单元 的故障状态、运行状态、攻击状态来切换 横向控制单元 工作 |
D |
DC |
|
( I )SSR- 10 -02 |
主 横向控制单元 异常时立即切换到 横向控制单元 ，不能影响 车辆的 横向控制能力 |
D |
DC |
|
( I )SSR- 10 -03 |
在切换后对原主 横向 控制单元 进行复位操作，并尝试恢复主 横向 控制单元 |
D |
DC |
|
TSR2.5.1.1.3
|
根据感知传感器的异常状态来评估感知失效程度 建立感知轻微失效、中度失效、严重失效的感知失效程度分级 |
D |
DC |
|
|
|||
|
( I )SSR- 11 -01 |
综合故障状态、驾驶条件、攻击状态评估传感器对系统感知的失效程度 |
D |
DC |
|
( I )SSR- 11 -02 |
建立传感器异常转态映射表，量化异常对感知能力的影响权重 |
D |
DC |
|
( I )SSR- 11 -0 3 |
应实现三级失效分级机制，基于影响权重进行失效程度分级 |
D |
DC |
|
TSR2.5.1.2.2
|
感知轻微失效系统维持自动紧急换道能力
|
D |
DC |
|
|
|||
|
( I )SSR- 12 -01 |
感知轻微失效采取保守的换道决策，维持自动紧急换道能力 |
D |
DC |
|
( I )SSR- 12 -02 |
感知轻微失效 应限制换道速度，提高安全裕度 |
D |
DC |
|
TSR2.5.1.2.3
|
感知中度失效系统退出换道功能采取制动降级处理并提醒驾驶员
|
D |
DC |
|
|
|||
|
( I )SSR- 1 3-01 |
感知中度失效立即禁用换道功能并启动车道保持 |
D |
DC |
|
( I )SSR- 1 3-02 |
感知中度失效，车辆减低车速并采用制动的方式来避障 |
D |
DC |
|
( I )SSR- 1 3-0 3 |
感知中度失效，触发多种报警方式来提醒驾驶员 |
D |
DC |
|
TSR2.5.1.2.4
|
感知 严重 失效 系统减速并请求驾驶员接管
|
D |
DC |
|
|
|||
|
( I )SSR- 14 -01 |
感知严重失效立即禁用换道功能并进行减速 |
D |
DC |
|
( I )SSR- 14 -02 |
感知严重失效实现接管倒计时接管机制，多种接管提醒并每秒加强提醒强度 |
D |
DC |
|
( I )SSR- 14 -0 3 |
感知严重失效驾驶员未接管车辆时执行最小风险策略 |
D |
DC |
|
TSR2.5.3.1.4
|
根据横向换道控制单元的 异常状态 来评估横向控制失效程度 建立换道控制轻微失效、中度失效、严重失效的控制失效程度分级 |
D |
DC |
|
|
|||
|
( I )SSR- 15 -01 |
综合故障状态、驾驶条件、攻击状态评估 横向换道控制单元 对系统横向换道的失效程度 |
D |
DC |
|
( I )SSR- 15 -02 |
建立 横向换道控制 异常转态映射表，量化异常对横向控制能力的影响权重 |
D |
DC |
|
( I )SSR- 15 -0 3 |
应实现三级失效分级机制，基于影响权重进行横向控制失效程度分级 |
D |
DC |
|
TSR2.5.3.2.2
|
横向换道控制 轻微失效系统维持自动紧急换道能力
|
D |
DC |
|
( I )SSR- 16 -01 |
横向换道控制 轻微失效维持自动紧急换道能力 |
D |
DC |
|
TSR2.5.3.2.3
|
横向换道控制 中度失效系统 限制 换道功能采取制动降级处理并提醒驾驶员
|
D |
DC |
|
|
|||
|
( I )SSR- 17 -01 |
横向换道控制 中度失效立即限制换道功能，采取保守的换道决策 限制换道速度 |
D |
DC |
|
( I )SSR- 17 -02 |
横向换道控制 中度失效，车辆减低车速并采用制动的方式来避障 |
D |
DC |
|
( I )SSR- 17 -0 3 |
横向换道控制 中度失效，触发多种报警方式来提醒驾驶员 |
D |
DC |
|
TSR2.5.3.2.4
|
横向换道控制 严重 失效 系统禁止换道功能 采取制动降级处理 并请求驾驶员接管
|
D |
DC |
|
|
|||
|
( I )SSR- 18 -01 |
横向换道控制 严重失效立即禁用换道功能并进行减速避障 |
D |
DC |
|
( I )SSR- 18 -02 |
横向换道控制 严重失效实现接管倒计时接管机制，多种接管提醒并每秒加强提醒强度 |
D |
DC |
|
( I )SSR- 18 -0 3 |
横向换道控制 严重失效驾驶员未接管车辆时执行最小风险策略 |
D |
DC |
AES 紧急驾驶系统主要有三种转态：系统正常运行启动状态、系统降级转态以及请求驾驶员接管状态，该系统主要有四大模块组成，感知模块、决策模块、控制模块以及执行模块，系统四大模块的工作状态决定了系统能否正常的启动运行，只有在四大模块均处于良好的工作转态时，系统才能做出正确的动作来保证车辆的安全，因此只有在四大模块均正常工作时系统才能启动，当有任何一个模块没法有效运行时，系统将请求驾驶员接管车辆并退出 AES 系统。启动系统后，应根据交通驾驶场景以及系统的工作状态来决定是否采取转向换道来保证车辆安全，当驾驶场景和系统工作状态不满足转向换道时，系统将采取制动的形式来保证车辆的安全或者将车辆的碰撞风险与程度将至最低，随着驾驶场景以及系统工作状态的改变，均不满足系统正常工作时，系统请求驾驶员接管车辆并退出系统，系统的决策逻辑如下图所示。为了保证车辆的安全行驶，对四大模块工作状态的判断、驾驶场景的评估以及对具体工作状态和驾驶场景的决策是非常关键的。根据软件安全要求的导出，现将围绕感知、决策、控制模块对不同工作状态，结合驾驶场景来对软件单元进行详细设计。
感知失效只要由传感器失效、传感器通讯失效以及感知处理失效造成，传感器、通讯、感知中某一环节故障、不足、或遭到网络攻击均会导致感知失效，本案例中仅对应对传感器中的失效来采取相应措施来保证车辆安全进行感知失效的检测与应对策略进行分析。根据软件安全要求，首先需要实时检测传感器的工作状态，即是否存在故障或者是正遭受网络攻击，还是被环境触发导致不足；然后对所处的工作状态进行评估，评估其对感知的影响程度；最后根据对感知的影响程度来进行决策，来保证车辆的安全。
4.2.1 传感器异常检测
1 ）摄像头异常检测
根据软件安全要求 (F)SSR-01-02 ， (F)SSR-07-01 以及 (F)SSR-07-02 ，需要对实时对摄像头的故障状态以及网络攻击转态进行检测， 为了使得故障检测以及网络攻击检测能够将绝大部分的故障以及攻击进行覆盖，首先需要对摄像头的可能存在的故障以及攻击进行详细的分析，然后再根据潜在的故障以及攻击导致的异常表现形式来设计相对应的检测措施来覆盖这些异常。根据摄像头的组成以及功能，车载摄像头可能存在供电故障、镜头损坏、图像传感器故障、图像信号处理故障、通讯故障、连接线路故障、电磁干扰这些潜在故障。车载摄像头的网络攻击可能会遭到拒绝服务攻击、篡改攻击、数据注入攻击、恶意软件攻击。摄像头的故障类型以及攻击类型对应的表现类型如下表所示。
|
摄像头故障类型攻击类型及其表现形式 |
|||
|
故障类型 |
表现形式 |
攻击类型 |
表现形式 |
|
电源故障 |
图像丢失 |
拒绝服务攻击 |
图像卡顿丢失 |
|
镜头损坏 |
图像模糊 |
篡改攻击 |
图像篡改 |
|
图像传感器故障 |
图像失真丢失 |
数据注入攻击 |
图像噪点失真 |
|
图像处理故障 |
图像卡顿 |
干扰攻击 |
图像花屏模糊 |
|
通讯故障 |
图像丢失 |
重放攻击 |
图像滞后 |
|
连接线路故障 |
图像花屏 |
|
|
|
电磁干扰 |
图像噪点 |
|
|
根据软件安全要求 (F)SSR-01-02 可以充分利用摄像头本身的故障自检功能来识别摄像头的故障，通过实时周期性的解析摄像头的状态码来判断摄像头的故障状态，目前车规级带故障自检的前视摄像头可以进行电源管理模块自检、图像信号处理模块自检以及通讯自检，通过这些自检机制，可以覆盖摄像头的供电故障、图像信号处理故障以及通讯故障，此外在这些检验机制下也可以用来检测遭到网络攻击导致上述故障的网络攻击，余下摄像头的故障有镜头损坏、图像传感器故障、连接线束故障、电磁故障，所造成的故障类型表现形式与网络攻击所导致的异常表现形式高度相似，因此摄像头余下的故障类型则可以根据软件安全要求 (F)SSR-07-01 以及 (F)SSR-07-02 来进行覆盖，绝大多数情况下，主冗余摄像头同时发生故障的可能性比较低，此时可以通过主冗余摄像头的设计，通过实时的对比主冗余摄像头的图像信号来检测故障，当一路信号发生异常时，就可以判断该路摄像头存在故障或者网络攻击，当无法通过对比两路信号来检测和识别故障和网络攻击时，此时就需要额外对主冗余信号都进行图像识别，来检测故障和网络攻击，通过图像识别的方法来检测图像噪点、失真、模糊、丢失，而对于篡改攻击可以根据 (F)SSR-09-02 来防护与检测，通过对图像数据进行加密的手段来保护图像数据避免遭到篡改，通过信号校验以及加密手段来检测篡改攻击，摄像头故障检测与网络攻击检测方法如下图所示。
根据 (S)SSR-05-01 、 (S)SSR-05-02 ，需要实时检测车辆驾驶场景以及行驶天气来识别摄像头的运行工况， 通过对摄像头的潜在不足以及触发条件的识别，对摄像头感知造成影响的驾驶交通场景有拥挤场景、高速场景、弯道、坡度、隧道、桥梁、城市或者郊区；对摄像头感知造成影响的具体天气状况：雨、雪、雾、强光、弱光。因此需要对上述的驾驶交通场景以及天气进行识别与检测，通过车辆定位信息以及云平台远程信息服务的方式来识别拥挤场景、高速场景、隧道、桥梁、城市或者郊区，通过图像识别检测来检测天气状况以及道路曲直与坡度。
2 ）毫米波雷达异常检测
根据软件安全要求 (F)SSR-01-02 ， (F)SSR-07-01 以及 (F)SSR-07-02 ，需要对实时对毫米波雷达的故障状态以及网络攻击转态进行检测， 为了使得故障检测以及网络攻击检测能够将绝大部分的故障以及攻击进行覆盖，首先需要对 毫米波雷达 的可能存在的故障以及攻击进行详细的分析，然后再根据潜在的故障以及攻击导致的异常表现形式来设计相对应的检测措施来覆盖这些异常。根据 毫米波雷达 的组成以及功能，车载 毫米波雷达 可能存在电源故障、发射天线故障、接收天线故障、点云信号处理故障、通讯故障、连接线路故障、电磁干扰这些潜在故障。车载摄像头的网络攻击可能会遭到拒绝服务攻击、篡改攻击、干扰攻击、重放攻击、欺骗攻击。 毫米波雷达 的故障类型以及攻击类型对应的表现类型如下表所示。
|
毫米波雷达故障类型攻击类型及其表现形式 |
|||
|
故障类型 |
表现形式 |
攻击类型 |
表现形式 |
|
电源故障 |
目标丢失 |
欺骗攻击 |
虚假目标 |
|
发射天线故障 |
距离偏差丢失 |
篡改攻击 |
距离偏差丢失 |
|
接收天线故障 |
距离波动丢失 |
干扰攻击 |
距离跳变 |
|
信号处理故障 |
距离跳变丢失 |
重放攻击 |
距离重复出现 |
|
通讯故障 |
跟踪滞后丢失 |
拒绝服务 |
目标丢失 |
|
电磁干扰 |
距离跳动 |
|
|
根据软件安全要求 (F)SSR-01-02 可以充分利用雷达本身的故障自检功能来识别雷达的故障，通过实时周期性的解析雷达的状态码来判断雷达的故障状态，目前车规级带故障自检的雷达可以进行电源管理模块自检、点云信号处理模块自检以及通讯自检，通过这些自检机制，可以覆盖雷达的电源故障、点云信号处理故障以及通讯故障，此外在这些检验机制下也可以用来检测遭到网络攻击导致上述故障的网络攻击，余下雷达的故障有 发射天线故障、接收天线故障 、连接线束故障、电磁干扰故障，所造成的故障类型表现形式与网络攻击所导致的异常表现形式高度相似，因此摄像头余下的故障类型则可以根据软件安全要求 (F)SSR-07-01 以及 (F)SSR-07-02 来进行覆盖，绝大多数情况下，主冗余摄像头同时发生故障的可能性比较低，此时可以通过主冗余摄像头的设计，通过实时的对比主冗余雷达的点云信号（目标检测信号）来检测故障，当一路信号发生异常时，就可以判断该路雷达存在故障或者网络攻击，当无法通过对比两路信号来检测和识别故障和网络攻击时，此时就需要额外对主冗余信号都进行点云攻击识别（目标检测信号攻击识别），来检测故障和网络攻击，通过目标检测信号攻击识别的方法来检测检测目标出现目标丢失、目标距离跳变、目标距离与历史重复以及虚假目标的情况，而对于篡改攻击可以根据 (F)SSR-09-02 来防护与检测，通过对目标检测数据进行加密的手段来保护目标检测数据避免遭到篡改，通过信号校验以及加密手段来检测篡改攻击，毫米波雷达故障检测与网络攻击检测方法如下图所示。
根据 (S)SSR-05-01 、 (S)SSR-05-02 ，需要实时检测车辆驾驶场景以及行驶天气来识别摄像头的运行工况， 通过对雷达的潜在不足以及触发条件的识别，对雷达感知造成影响的驾驶交通场景有拥挤场景、隧道、桥梁、城市或者郊区；对雷达感知造成影响的具体天气状况：雨、雪、雾。因此需要对上述的驾驶交通场景以及天气进行识别与检测，通过车辆定位信息以及云平台远程信息服务的方式来识别拥挤场景、隧道、桥梁、城市或者郊区，通过图像识别检测来检测天气状况。
3 ） V2X 异常检测
根据软件安全要求 (F)SSR-01-02 ， (F)SSR-07-01 以及 (F)SSR-07-02 ，需要对实时对 V2X （ T-BOX ）的故障状态以及网络攻击转态进行检测， 为了使得故障检测以及网络攻击检测能够将绝大部分的故障以及攻击进行覆盖，首先需要对 T-BOX 的可能存在的故障以及攻击进行详细的分析，然后再根据潜在的故障以及攻击导致的异常表现形式来设计相对应的检测措施来覆盖这些异常。根据 T-BOX 的组成以及 V2X 功能， T-BOX 可能存在电源故障、 V2X 信号处理故障 、通讯故障、电磁干扰这些潜在故障。 T-BOX 的网络攻击可能会遭到拒绝服务攻击、篡改攻击、干扰攻击、重放攻击、欺骗攻击。 T-BOX 的故障类型以及攻击类型对应的表现类型如下表所示。
|
T-BOX主要故障类型攻击类型及其表现形式 |
|||
|
故障类型 |
表现形式 |
攻击类型 |
表现形式 |
|
电源故障 |
信号丢失 |
欺骗攻击 |
虚假目标信号 |
|
信号处理故障 |
信号错误 |
篡改攻击 |
信号篡改 |
|
通讯故障 |
信号丢包延迟 |
干扰攻击 |
信号波动 |
|
电磁干扰 |
信号波动错误 |
重放攻击 |
信号重复出现 |
|
|
|
拒绝服务 |
信号丢失延迟 |
根据软件安全要求 (F)SSR-01-02 可以充分利用 T-BOX 本身的故障自检功能来识别 T-BOX 的故障，通过实时周期性的解析 T-BOX 的状态码来判断 T-BOX 的故障状态，目前车规级带故障自检的 T-BOX 可以进行电源管理模块自检、 V2X 信号处理模块自检以及通讯自检，通过这些自检机制，可以覆盖 T-BOX 的电源故障、 V2X 信号处理故障以及通讯故障，此外在这些检验机制下也可以用来检测遭到网络攻击导致上述故障的网络攻击，余下 T-BOX 的故障有电磁干扰故障，所造成的故障类型表现形式与网络攻击所导致的异常表现形式高度相似，因此 T-BOX 的电磁干扰故障则可以根据软件安全要求 (F)SSR-07-01 以及 (F)SSR-07-02 来进行覆盖，绝大多数情况下，主冗余 T-BOX 同时发生故障的可能性比较低，此时可以通过主冗余 T-BOX 的设计，通过实时的对比主冗余 T-BOX 的 V2X 信号来检测故障，当一路信号发生异常时，就可以判断该路 T-BOX 存在故障或者网络攻击，当无法通过对比两路信号来检测和识别故障和网络攻击时，此时就需要额外对主冗余信号都进行 V2X 信号攻击识别，来检测故障和网络攻击，通过 V2X 信号攻击识别的方法来信号出现丢失、波动、历史重复、虚假以及篡改的情况，而对于篡改攻击可以根据 (F)SSR-09-02 来防护与检测，通过对目标检测数据进行加密的手段来保护目标检测数据避免遭到篡改，通过信号校验以及加密手段来检测篡改攻击，对于虚假攻击可以通过身份认证的形式来检测与防护虚假攻击， V2X 故障检测与网络攻击检测方法如下图所示。
根据 (S)SSR-05-01 、 (S)SSR-05-02 ，需要实时检测车辆驾驶场景以及行驶天气来识别 V2X 的运行工况， 通过对 V2X 的潜在不足以及触发条件的识别，对 V2X 感知造成影响的驾驶交通场景有拥挤场景、隧道、桥梁、城市或者郊区；对 V2X 感知造成影响的具体天气状况：雨、雪、雾。因此需要对上述的驾驶交通场景以及天气进行识别与检测，通过车辆定位信息以及云平台远程信息服务的方式来识别拥挤场景、隧道、桥梁、城市或者郊区，通过图像识别检测来检测天气状况。
4.2.2 传感器异常响应与加密协同设计
1 ）图像加密与异常响应协同设计
根据技术安全措施矩阵关系可知，软件安全要求 (F)SSR-01-02 、 (S)SSR-05-01 与软件安全要求 (F)SSR-09-02 存在实时性与加密检验时延之间矛盾，如下图所示。
对图像信号的处理首先需要经过加密解密与检验，然后再来检测故障、运行工况以及网络攻击，经过加密解密和校验势必会导致故障、运行工况、网络攻击检测的延迟，当异常发生时就无法对异常进行及时的响应与处理，因此需要来平衡他们之间的矛盾。为了减低信号加密解密带来的时延，除了提升域控制器的性能，比如通过额外的硬件安全模块专门来加速处理加密解密校验的过程，同时我们将图像信号的加密过程通过摄像头本身来实现，降低硬件安全模块的计算量，同时我们进行双路径强弱加密校验通道设计来降低异常检测和时延的延迟，双路径强弱加密校验通道设计如下图所示。
对图像信号同时进行加密解密以及校验，对于图像信号的异常检测，只是经过轻量加密解密以及强校验，可以初步判断图像信号的完整性，对于一些隐匿性比较低的网络攻击就能够被检测到立即作出异常相应，同时对图像信号的高强度加密解密完整校验与异常检测就能够同步进行，避免高强度加密解密完整校验带来的延迟，当高强度加密解密完整校验检测到完整性被破坏，系统立即作出异常响应，当检测到图像信号完整性正常时，只需要再根据异常检测来作出异常响应即可。
2 ）雷达信息加密 与异常响应协同设计
根据技术安全措施矩阵关系可知，软件安全要求 (F)SSR-01-02 、 (S)SSR-05-01 与软件安全要求 (F)SSR-09-02 存在实时性与加密检验时延之间矛盾，因此需要来平衡他们之间的矛盾。为了减低信号加密解密带来的时延，除了提升域控制器的性能，比如通过额外的硬件安全模块专门来加速处理加密解密校验的过程，同时我们将点云信号的加密过程通过摄像头本身来实现，降低硬件安全模块的计算量，同时我们进行双路径强弱加密校验通道设计来降低异常检测和时延的延迟，双路径强弱加密校验通道设计如下图所示。
对毫米波雷达目标检测信号同时进行加密解密以及校验，对于目标检测信号的异常检测，只是经过轻量加密解密以及强校验，可以初步判断目标检测信号的完整性，对于一些隐匿性比较低的网络攻击就能够被检测到立即作出异常相应，同时对目标检测信号的高强度加密解密完整校验与异常检测就能够同步进行，避免高强度加密解密完整校验带来的延迟，当高强度加密解密完整校验检测到完整性被破坏，系统立即作出异常响应，当检测到目标检测信号完整性正常时，只需要再根据异常检测来作出异常响应即可。
3 ） V2X 信息加密与异常响应协同设计
根据技术安全措施矩阵关系可知，软件安全要求 (F)SSR-01-02 、 (S)SSR-05-01 与软件安全要求 (F)SSR-09-02 存在实时性与加密检验时延之间矛盾，因此需要来平衡他们之间的矛盾。为了减低信号加密解密带来的时延，除了提升域控制器的性能，比如通过额外的硬件安全模块专门来加速处理加密解密校验的过程，同时我们将 V2X 信号的加密过程通过 T-BOX 本身来实现，降低硬件安全模块的计算量，同时我们进行双路径强弱加密校验通道设计来降低异常检测和时延的延迟，双路径强弱加密校验通道设计如下图所示。
对 V2X 信号 同时进行加密解密以及校验，对于 V2X 信号 的异常检测，只是经过轻量加密解密以及强校验，可以初步判断目标检测信号的完整性，对于一些隐匿性比较低的网络攻击就能够被检测到立即作出异常相应，同时对 V2X 信号 的高强度加密解密完整校验与异常检测就能够同步进行，避免高强度加密解密完整校验带来的延迟，当高强度加密解密完整校验检测到完整性被破坏，系统立即作出异常响应，当检测到 V2X 信号 完整性正常时，只需要再根据异常检测来作出异常响应即可。
4.2.3 传感器异常响应策略
根据软件安全要求，需要基于传感器的故障类型、运行工况、网络攻击类型和他们之间对应的严重程度来评估当前传感器的感知能力的置信度，因此需要对传感器的异常表现以及严重程度来分析对感知的影响，然后根据影响程度来评估感知能力的置信度。以下是交通场景、以下是交通场景、形式天气以及各种故障和网络攻击对各自传感器对感知的影响程度的分析。
不同恶劣环境对车载传感器的影响程度 :
|
恶劣天气 |
摄像头 |
毫米波雷达 |
V2X |
备注 |
|
小雨 |
2 |
1 |
1 |
每种环境对传感器的影响程度： 0- 可忽略：几乎可以被忽略的影响； 1- 较小：几乎不会导致检测错误的影响； 2- 轻微：在特殊情况下导致小错误的影响； 3- 中度：造成感知错误的影响高达30%； 4- 严重：造成感知误差超过30%但低于50%的影响； 5- 恶劣：噪声或阻塞导致误检测或检测失败。 |
|
中雨 |
3 |
1 |
1 |
|
|
大雨 |
4 |
2 |
1 |
|
|
小雪 |
2 |
1 |
1 |
|
|
中雪 |
3 |
2 |
1 |
|
|
大雪 |
4 |
3 |
1 |
|
|
轻雾 |
2 |
1 |
1 |
|
|
中雾 |
3 |
1 |
1 |
|
|
浓雾 |
4 |
2 |
1 |
|
|
强光 |
4 |
0 |
0 |
|
|
弱光 |
3 |
0 |
0 |
不同 驾驶场景 对车载传感器的影响程度 :
|
驾驶场景 |
摄像头 |
毫米波雷达 |
V2X |
|
低拥挤交通 |
1 |
1 |
1 |
|
中拥挤交通 |
2 |
2 |
2 |
|
高拥挤交通 |
3 |
2 |
2 |
|
中低车速 |
2 |
1 |
1 |
|
中高车速 |
2 |
1 |
1 |
|
大弯道 |
1 |
1 |
1 |
|
中弯道 |
2 |
2 |
2 |
|
小弯道 |
2 |
2 |
2 |
|
小坡度 |
1 |
1 |
1 |
|
中坡度 |
2 |
2 |
2 |
|
大坡度 |
3 |
3 |
3 |
|
短隧道 |
2 |
1 |
2 |
|
中隧道 |
3 |
2 |
3 |
|
长隧道 |
4 |
3 |
4 |
|
矮护栏桥梁 |
1 |
1 |
1 |
|
中护栏桥梁 |
2 |
1 |
1 |
|
高护栏桥梁 |
2 |
1 |
1 |
|
城市 |
2 |
2 |
2 |
|
郊区 |
1 |
1 |
1 |
不同车载 摄像头故障对感知 的影响程度 :
|
故障类型 |
表现形式 |
影响程度 |
|
镜头损坏 |
图像轻微模糊 |
1 |
|
图像中度模糊 |
4 |
|
|
图像严重模糊 |
5 |
|
|
图像信号处理故障 |
图像偶尔卡顿 |
1 |
|
图像卡顿频繁 |
3 |
|
|
图像完全黑屏 |
5 |
|
|
连接线路故障 |
图像偶尔闪烁 |
1 |
|
图像频繁闪烁 |
3 |
|
|
图像持续花屏 |
5 |
|
|
电磁干扰 |
图像少量噪点 |
1 |
|
图像较多噪点 |
3 |
|
|
图像布满噪点 |
5 |
|
|
遮挡干扰 |
图像少量遮挡 |
1 |
|
图像部分遮挡 |
3 |
|
|
图像大量遮挡 |
5 |
不同车载 摄像头网络攻击对感知 的影响程度 :
|
故障类型 |
表现形式 |
影响程度 |
|
拒绝服务攻击 |
图像偶尔卡顿 |
1 |
|
图像卡顿频繁 |
4 |
|
|
图像完全黑屏 |
5 |
|
|
篡改攻击 |
图像轻微篡改 |
1 |
|
图像中度篡改 |
4 |
|
|
图像严重篡改 |
5 |
|
|
数据注入攻击 |
图像少量噪点 |
1 |
|
图像较多噪点 |
3 |
|
|
图像布满噪点 |
5 |
|
|
恶意软件攻击 |
图像轻微模糊 |
1 |
|
图像中度模糊 |
4 |
|
|
图像严重模糊 |
5 |
不同 毫米波雷达故障对感知 的影响程度 :
|
故障类型 |
表现形式 |
影响程度 |
|
发射天线故障 |
目标距离稍微偏差 |
1 |
|
目标距离明显偏差 |
3 |
|
|
目标距离严重偏差 |
4 |
|
|
接收天线故障 |
目标距离稍微波动 |
1 |
|
目标距离波动较大 |
4 |
|
|
目标距离大量丢失 |
5 |
|
|
信号处理器故障 |
目标距离偶尔跳变 |
1 |
|
目标距离频繁跳变 |
4 |
|
|
目标距离严重跳变 |
5 |
|
|
雷达驱动程序故障 |
动态目标跟踪稍有影响 |
1 |
|
动态目标跟踪明显滞后 |
3 |
|
|
动态目标跟踪严重滞后 |
4 |
|
|
电磁干扰 |
目标距离小幅跳动 |
1 |
|
目标距离频繁跳动 |
4 |
|
|
目标距离严重跳动 |
5 |
|
|
遮挡干扰 |
目标距离稍微偏差 |
1 |
|
目标距离明显偏差 |
3 |
|
|
目标距离严重偏差 |
5 |
不同 毫米波雷达网络攻击对感知 的影响程度 :
|
故障类型 |
表现形式 |
影响程度 |
|
欺骗攻击 |
闪现少量虚假目标 |
1 |
|
频繁出现虚假目标 |
3 |
|
|
密集出现虚假目标 |
5 |
|
|
篡改攻击 |
目标距离轻微变化 |
1 |
|
目标距离明显偏差 |
4 |
|
|
目标距离严重偏差 |
5 |
|
|
干扰攻击 |
目标距离偶尔跳变 |
1 |
|
目标距离频繁跳变 |
4 |
|
|
目标距离严重跳变 |
5 |
|
|
重放攻击 |
目标距离轻微变化 |
1 |
|
目标距离明显偏差 |
3 |
|
|
目标距离严重偏差 |
4 |
不同 V2X故障对感知 的影响程度 :
|
故障类型 |
表现形式 |
影响程度 |
|
通讯故障 |
信息轻微丢包与延迟 |
1 |
|
信息丢包与延迟较大 |
4 |
|
|
信息严重丢包与延迟 |
5 |
|
|
信号处理故障 |
信号处理偶尔出错 |
1 |
|
信号处理错误较多 |
3 |
|
|
信号处理完全混乱 |
5 |
|
|
电磁干扰 |
信号短暂波动 |
1 |
|
信号波动频繁 |
3 |
|
|
信号严重波动 |
5 |
不同 V2X网络攻击对感知 的影响程度 :
|
故障类型 |
表现形式 |
影响程度 |
|
欺骗攻击 |
偶尔接收少量虚假交通信息 |
1 |
|
频繁出现虚假交通信息 |
3 |
|
|
密集出现虚假交通信息 |
5 |
|
|
篡改攻击 |
少量不重要的交通信息被篡改 |
1 |
|
部分重要信息被篡改 |
3 |
|
|
大量关键信息被恶意篡改 |
5 |
|
|
干扰攻击 |
信号出现短暂波动 |
1 |
|
信号传输错误较多 |
4 |
|
|
信号传输严重错误 |
5 |
|
|
重放攻击 |
偶尔重放少量历史交通信息 |
1 |
|
重放历史信息频率增加 |
3 |
|
|
持续重放大量历史信息 |
4 |
|
|
拒绝服务攻击 |
V2X 通信服务响应时间偶尔延长 |
1 |
|
通信服务响应延迟明显 |
3 |
|
|
通信服务几乎完全中断 |
5 |
感知模块是由感知单元与感知信息融合单元组成，对于不同的驾驶场景、天气以及不同的故障网络攻击，不仅需要对感知单元进行讨论，还需要结合信息融合单元进行考虑，已知感知融合单元是由各传感器感知单元感知结果的后融合，其后融合方式如下面的公式所示，各单元的融合权重与各传感器的工作状态相关，在不同的故障、网络攻击以及驾驶场景下，对传感器影响程度越小的，则该传感器的融合权重越大，感知的置信度越高，反之则越小。当对传感器的影响程度大于 3 时，则认为该传感器的感知不可靠，感知信息融合单元丢弃该传感器的感知结果，仅仅对剩下的传感器感知结果进行融合 , 此外为了保证权重调整后对感知置信度的可靠，采取不同的降级措施，系统换道对感知的可靠性要求最高，当感知传感器较为完备时，即保持系统主动换道路的能力；系统自动制动对感知的可靠度要求次之，当传感器部分失效不可靠时，仅维持系统主动制动的能力；当传感器大部分失效时，系统不进行主动换道与主动制动而是通过请求驾驶员来接管车辆保证安全。
感知 = W 摄像头 S 摄像头 + W 雷达 S 雷达 + W V2X S V2X
W 摄像头 = ( 5 - I 摄像头 )/(5 - I 摄像头 + 5 - I 雷达 + 5 - I V2X )
W 雷达 = ( 5 - I 雷达 )/(5 - I 摄像头 + 5 - I 雷达 + 5 - I V2
W V2X = ( 5 - I V2X )/(5 - I 摄像头 + 5 - I 雷达 + 5 - I V2X )
如果影响程度 I 大于等于 4 则该传感器不参与感知
应对不同传感器失效的决策策略如下：
如果 I 1 、 I 2 、 I 3 小于 4
则 : 启动系统
感知 = W 1 S 1 + W 2 S 2 + W 3 S 3
W 1 = ( 5 - I 1 )/(5 - I 1 + 5 - I 2 + 5 - I 3 )
W 2 = ( 5 - I 2 )/(5 - I 1 + 5 - I 2 + 5 - I 3 )
W 3 = ( 5 - I 3 )/(5 - I 1 + 5 - I 2 + 5 - I 3 )
如果 I 1 + I 2 + I 2 大于等于 8 ：
则：不进行转向
采取降级措施
如果 I 1 + I 2 + I 2 小于 8 ：
则：进行转向
如果 I 3 大于等于 4 、 I 2 、 I 3 小于 4
则：启动系统
感知 = W 1 S 1 + W 2 S 2
W 1 = ( 5 - I 1 )/(5 - I 1 + 5 - I 2 )
W 2 = ( 5 - I 2 )/(5 - I 1 + 5 - I 2 )
如果 I 1 + I 2 大于等于 5 ：
则：不进行转向
采取降级措施
如果 I 1 + I 2 小于 5 ：
则：进行转向
如果 I 2 、 I 3 大于等于 4 、 I 1 小于 4
则：启动系统
感知 = W 1 S 1
W 1 = ( 5 - I 1 )/(5 - I 1 )
如果 I 1 大于等于 2 ：
则：不进行转向
采取降级措施
如果 I 1 + I 2 小于 2 ：
则：进行转向
如果 I 1 、 I 2 、 I 3 大于等于 4
则：退出系统
请求接管
控制失效只要由车辆定位失效、定位信息通讯失效以及控制单元失效造成，定位、通讯、控制中某一环节故障、不足、或遭到网络攻击均会导致横向换道控制失效，本案例中仅对应对通讯以及控制单元中的失效来采取相应措施来保证车辆安全进行控制失效的检测与应对策略进行分析。根据软件安全要求，首先需要实时检测定位信息通讯以及控制单元的工作状态，即是否存在故障或者是正遭受网络攻击，还是被环境触发导致不足；然后对所处的工作状态进行评估，评估其对横向换道的影响程度；最后根据对横向换道的影响程度来进行决策，来保证车辆的安全。
4.3.1 控制异常检测
1 ）定位信息异常检测
根据软件安全要求 (F)SSR-01-02 ， (F)SSR-07-01 以及 (F)SSR-07-02 ，需要对实时对定位信息通讯的故障状态以及网络攻击转态进行检测， 为了使得故障检测以及网络攻击检测能够将绝大部分的故障以及攻击进行覆盖，首先需要对 定位信息通讯 可能存在的故障以及攻击进行详细的分析，然后再根据潜在的故障以及攻击导致的异常表现形式来设计相对应的检测措施来覆盖这些异常。 定位信息通讯 可能存在电源故障、 定位信息节点故障 、通讯链路故障、总线负载过高、电磁干扰这些潜在故障。 定位信息通讯 可能会遭到拒绝服务攻击、篡改攻击、重放攻击、欺骗攻击。 定位信息通信 的故障类型以及攻击类型对应的表现类型如下表所示。
|
定位信息通讯主要故障类型攻击类型及其表现形式 |
|||
|
故障类型 |
表现形式 |
攻击类型 |
表现形式 |
|
节点故障 |
信号丢失 |
欺骗攻击（节点冒充） |
虚假信号 |
|
通讯链路故障 |
信号丢失 |
篡改攻击 |
信号篡改 |
|
总线负载过高 |
信号丢包延迟 |
干扰攻击 |
信号波动错误 |
|
电磁干扰 |
信号波动错误 |
重放攻击 |
信号重复出现 |
|
|
|
拒绝服务 |
信号丢包延迟 |
|
|
|
|
|
根据软件安全要求 (F)SSR-01-02 可以通过通信信号的问答机制功能来识别通信的故障，实时解析问答状态来判断定位信息通信的故障状态，可以覆盖节点故障、通讯链路故障、总线关闭的故障以及部分拒绝服务的攻击，此外在这些检验机制下也可以用来检测遭到网络攻击导致上述故障的网络攻击，余下定位信息故障有电磁干扰故障，所造成的故障类型表现形式与干扰攻击所导致的异常表现形式高度相似，因此电磁干扰故障则可以根据软件安全要求 (F)SSR-07-01 以及 (F)SSR-07-02 来进行覆盖，绝大多数情况下，主冗余定位信息通信回路同时发生故障的可能性比较低，此时可以通过主冗余定位信息通信回路的设计，通过实时的对比主冗余通信信号来检测故障，当一路信号发生异常时，就可以判断该路存在故障或者网络攻击，当无法通过对比两路信号来检测和识别故障和网络攻击时，此时就需要额外对主冗余信号都进行信号攻击识别，来检测故障和网络攻击，通过定位信号攻击识别的方法来信号出现波动错误、历史重复、虚假以及篡改的情况，而对于篡改攻击可以根据 (F)SSR-09-02 来防护与检测，通过对目标检测数据进行加密的手段来保护定位信息避免遭到篡改，通过信号校验以及加密手段来检测篡改攻击，对于虚假攻击可以通过身份认证和合理性检测形式来检测与防护虚假攻击，定位信息通信故障检测与网络攻击检测方法如下图所示。
2 ）横向换道控制单元异常检测
根据软件安全要求 (F)SSR-01-02 ， (F)SSR-07-01 以及 (F)SSR-07-02 ，需要对实时对横向控制单元的故障状态以及网络攻击转态进行检测， 为了使得故障检测以及网络攻击检测能够将绝大部分的故障以及攻击进行覆盖，首先需要对 横向控制单元 可能存在的主要的故障以及攻击进行分析，然后再根据潜在的故障以及攻击导致的异常表现形式来设计相对应的检测措施来覆盖这些异常。 横向控制单元 可能存在 MCU 故障、内存 故障 、启动故障、控制算法故障这些潜在故障。 横向控制单元 可能会遭到拒绝服务攻击、篡改攻击、信号注入攻击、窃取攻击。 横向控制单元 的故障类型以及攻击类型对应的表现类型如下表所示。
|
控制单元主要故障类型攻击类型及其表现形式 |
|||
|
故障类型 |
表现形式 |
攻击类型 |
表现形式 |
|
MCU硬件故障 |
控制指令计算错误 |
数据窃取攻击 |
隐私泄露 |
|
存储故障 |
算法参数读取错误 |
篡改攻击 |
控制参数异常 |
|
启动故障 |
无法启动 |
重放攻击 |
控制指令重复 |
|
软件故障 |
横向控制信号跳变错误 |
拒绝服务 |
控制指令丢包延迟 |
|
|
|
信号注入攻击 |
非预期横向控制信号 |
根据软件安全要求 (F)SSR-01-02 可以通过 MCU 自检功能来识别控制单元的故障，实时读取解析寄存器的状态码来判断横向控制单元的故障状态，可以覆盖绝大部分的 MCU 硬件故障：电源故障、时钟故障、 CPU 故障、内存故障和软件故障中的程序运行故障，此外在这些检验机制下也可以用来检测遭到网络攻击导致上述故障的网络攻击，余下横向控制单元故障有存储故障、启动故障、控制算法逻辑故障，控制算法逻辑故障表现形式与信号注入攻击所导致的异常表现形式高度相似，都会造成车辆非预期的横向控制，因此控制算法逻辑故障则可以根据软件安全要求 (F)SSR-07-01 以及 (F)SSR-07-02 来进行覆盖，绝大多数情况下，主冗余横向控制单元同时发生故障的可能性比较低，此时可以通过主冗余横向控制单元的设计，通过实时的对比主冗余横向控制信号来检测故障，当一路信号发生异常时，就可以判断该路存在故障或者网络攻击，当无法通过对比两路信号来检测和识别故障和网络攻击时，此时就需要额外对主冗余信号都进行横向控制指令合理性检查攻击识别，来检测故障和网络攻击，通过预测横向控制指令对控制跟踪的效果来识别横向控制指令的跳变与错误，对于拒绝服务攻击可以通过对横向控制指令的丢包和时延进行诊断来检测，对于启动故障以及存储故障，根据 (F)SSR-09-02 ，通过横向控制算法的多重冗余备份以及启动安全校验来覆盖，而对于篡改攻击以及算法数据窃取可以根据 (F)SSR-09-02 来防护与检测，通过对目标检测数据进行加密的手段来保护横向控制算法避免遭到篡改以及窃取，通过启动安全校验以及加密手段来检测算法参数的篡改攻击，横向控制单元故障检测与网络攻击检测方法如下图所示。
根据软件安全要求，需要实时采集车辆状态与外部条件，因此需要分析对横向控制影响较大的车辆状态以及外部条件。 自动换道系统的横向控制需以车辆动态响应能力与路面侧向承载极限为核心约束，而车速与路面附着系数恰好是决定这两大约束的关键参数。车速直接决定车辆转向响应的灵敏度与离心力大小，高速状态下相同转向输入会产生更大的侧向动态，需通过平缓转向避免失稳；路面附着系数则限定了轮胎能提供的最大侧向力，低附着路面会显著降低这一极限，即使小幅转向也可能引发侧滑。二者共同构建了横向控制的安全边界， 因此需要实时采集和获取路面附着系数。
车速的获取以电子稳定控制系统（ ESC ）为主要来源，其通过融合轮速传感器与加速度信号计算高精度车身纵向速度，经 CAN 总线以周期 性的发送给自动换道系统。
路面附着系数的获取采用 “ 图像预估计 - 制动动态修正 ” 的闭环机制：非制动阶段，通过前视摄像头采集路面图像，提取纹理、反光率等特征，利用深度学习模型识别路面类型 （干燥 / 潮湿 / 积雪 / 结冰） 并映射至附着系数范围（如干燥沥青 μ=0.8~1.0 ，结冰路面 μ=0.1~0.2 ），作为初始控制依据；制动过程中，结合 ESC 的轮速与车身速度计算滑移率，通过制动压力推导轮胎纵向力，基于 “ 滑移率 - 附着系数 ” 单峰特性，以递归最小二乘（ RLS ）算法动态修正模型参数，提升估计精度。当路面图像特征突变时，优先更新图像估计值并触发制动模型的重新校准，形成双向迭代机制，确保附着系数实时反映路面真实状态，为横向控制提供可靠的极限约束。
4.3.2 控制异常响应与加密协同设计
1 ）定位信息异常响应与加密协同设计
根据技术安全措施矩阵关系可知，软件安全要求 (F)SSR-01-02 、 (S)SSR-05-01 与软件安全要求 (F)SSR-09-02 存在定位信息问答机制与高速通信之间的人矛盾、异常检测与高速通信之间的矛盾、高速通信实时性与加密检验时延之间矛盾、以及实时异常响应与加密之间的矛盾因此需要来平衡他们之间的矛盾。为了解决问答机制占用带宽影响定位信息的高速通信，采用变周期的问答机制来解决与高速实时性的矛盾：根据当前带宽的占用情况来动态调整周期，带宽占用高时，减低问答机制的频率，带宽占用高时，提高问答机制的频率；根据其他通信的安全等级以及历史故障状态来动态调整问答机制的周期，安全等级越高，问答机制的频率越高，故障频次越高，问答机制的频率越高，反之则越小。为了减低信号加密解密带来的时延，解决高速通信实时性、异常响应与加密检验时延之间矛盾，除了提升域控制器的性能，比如通过额外的硬件安全模块专门来加速处理加密解密校验的过程，同时将 车辆定位信息 的加密过程通过定位模块本身来实现，降低硬件安全模块的计算量，并进行双路径强弱加密校验通道设计来降低异常检测和时延的延迟，对定位信息同时进行高低加密解密以及校验，对于定位信息的异常检测，只是经过轻量加密解密以及强校验，可以初步判断目标检测信号的完整性，对于一些隐匿性比较低的网络攻击就能够被检测到立即作出异常相应，同时对定位信息的高强度加密解密完整校验与异常检测就能够同步进行，避免高强度加密解密完整校验带来的延迟，当高强度加密解密完整校验检测到完整性被破坏，系统立即作出异常响应，当检测到定位信息完整性正常时，只需要再根据异常检测来作出异常响应即可。为了减低信号深度异常检测带来的时延，解决高速通信实时性与深度异常检测之间矛盾，除了提升域控制器的硬件性能，比如通过高性能的处理芯片以及多核并程来加快异常检测的过程，同时将进行双路径强弱异常检测通道设计来降低异常检测带来的延迟，对定位信息同时进行轻量异常检测以及深度异常检测，来保证横向控制的实时性。双路径强弱加密校验通道设计如下图所示。
4.3.3 控制异常响应策略
1 ）横向控制单元冗余设计
为实现横向控制的高安全性与连续性，设计采用物理隔离的主冗余双回路架构：主控制单元基于 MPC 算法，冗余控制单元采用 PID 算法，两者搭载于独立 MCU ，配备独立供电模块、通信接口完全分离，通过光电隔离实现车载网络物理隔离，避免故障传导。软件层面，双回路代码存储于独立存储分区，运行空间相互隔离，核心控制逻辑经编译隔离确保独立性，从硬件到应用层构建完整隔离屏障，满足单个单个单元故障不影响另一单元的安全要求。
系统启动阶段需完成冗余配置完整性验证与主冗余单元自检：硬件层面校验 MCU 核心、外设及通信通道的初始化状态，软件层面通过 CRC 校验确保 MPC 与 PID 算法代码完整性，并验证输入接口映射正确性；主冗余单元分别执行内置自检， MPC 单元校验模型矩阵与优化器实时性， PID 单元验证参数有效性与阶跃响应特性。自检通过后，主单元激活运行，冗余单元进入热备状态，实时接收传感器数据但不输出控制指令。
设计独立监控模块实现主冗余单元的实时状态监测与动态切换：通过采集心跳帧监测故障状态，比对输入输出数据与资源使用率评估运行状态，借助消息认证码检测攻击状态。当主单元（ MPC ）出现离线故障、输出偏差超限或攻击告警时，监控模块立即触发无扰切换：冻结主单元输出，激活冗余单元（ PID ），通过前馈补偿实现控制指令平滑过渡（ 20ms 内完成），确保横向控制精度（车道保持 ±30cm ）不受影响，维持车辆横向控制能力。
切换完成后启动原主单元（ MPC ）的恢复机制：首先执行软件复位清除运行时错误，若失败则触发硬件复位（切断供电 300ms 后重启）；复位后自动执行完整性验证与自检，生成诊断报告。若自检通过且与冗余单元（ PID ）输出偏差连续 5 00ms ＜ 2° ，则软切换恢复主单元激活状态；经 3 次复位仍无法恢复时，标记为永久故障，维持冗余单元控制，保障系统可用性。
（ 1 ） 横向控制失效降级处理
综合故障状态、驾驶条件、攻击状态评估横向换道控制单元对系统横向换道的失效程度 ，横向换道失效的程度主要体现在换道的跟踪精度，衡量跟踪精度可以通过瞬态误差以及稳态误差来衡量，瞬态误差可以用来判断跟踪结果是否复合跟踪轨迹的趋势走向，本自动换道系统采用五次多项式轨迹来进行换道，瞬态误差即衡量跟踪效果是否仍然为五次多项式轨迹，稳态误差可以用来判断最后车辆换道的位置是否能够在可行区域内，避免与旁边发生碰撞。需要综合考虑故障、驾驶条件、攻击对跟踪控制的影响，不仅需要根据异常类型以及异常程度来评估，还需要考虑多维异常叠加的进行评估，比如需要考虑网络攻击与故障同时发生、故障与驾驶条件恶劣状况同时发生、网络攻击与与驾驶条件恶劣状况同时发生甚至是故障、网络攻击以及驾驶恶劣状态的同时发生。
建立横向换道控制异常转态映射表，量化异常对横向控制能力的影响 程度。
将故障状态、驾驶条件、攻击状态映射到具体的跟踪失效程度，对异常状态的映射应该对故障类型、驾驶条件类型、攻击类型及其严重程度来一一映射到跟踪失效程度，影响程度通过瞬态偏差以及稳态偏差来衡量如下表所示。
|
控制单元异常转态映射表 |
|||
|
故障类型 |
驾驶条件状况 |
攻击类型 |
影响程度 |
|
轻微故障 1 |
轻微条件 1 |
轻微攻击 1 |
偏差 1 |
|
轻微故障 1 |
轻微条件 1 |
中等攻击 1 |
偏差 2 |
|
轻微故障 1 |
轻微条件 1 |
严重攻击 1 |
偏差 3 |
|
轻微故障 1 |
中等条件 1 |
轻微攻击 1 |
偏差 4 |
|
轻微故障 1 |
中等条件 1 |
中等攻击 1 |
偏差 5 |
|
轻微故障 1 |
中等条件 1 |
严重攻击 1 |
偏差 6 |
|
轻微故障 1 |
严重条件 1 |
轻微攻击 1 |
偏差 7 |
|
轻微故障 1 |
严重条件 1 |
中等攻击 1 |
偏差 8 |
|
轻微故障 1 |
严重条件 1 |
严重攻击 1 |
偏差 9 |
|
中等故障 1 |
轻微条件 1 |
轻微攻击 1 |
偏差 1 0 |
|
中等故障 1 |
轻微条件 1 |
中等攻击 1 |
偏差 11 |
|
中等故障 1 |
轻微条件 1 |
严重攻击 1 |
偏差 12 |
|
中等故障 1 |
中等条件 1 |
轻微攻击 1 |
偏差 13 |
|
中等故障 1 |
中等条件 1 |
中等攻击 1 |
偏差 14 |
|
中等故障 1 |
中等条件 1 |
严重攻击 1 |
偏差 15 |
|
中等故障 1 |
严重条件 1 |
轻微攻击 1 |
偏差 16 |
|
中等故障 1 |
严重条件 1 |
中等攻击 1 |
偏差 17 |
|
中等故障 1 |
严重条件 1 |
严重攻击 1 |
偏差 18 |
|
严重故障 1 |
轻微条件 1 |
轻微攻击 1 |
偏差 19 |
|
严重故障 1 |
轻微条件 1 |
中等攻击 1 |
偏差 20 |
|
严重故障 1 |
轻微条件 1 |
严重攻击 1 |
偏差 21 |
|
严重故障 1 |
中等条件 1 |
轻微攻击 1 |
偏差 22 |
|
严重故障 1 |
中等条件 1 |
中等攻击 1 |
偏差 23 |
|
严重故障 1 |
中等条件 1 |
严重攻击 1 |
偏差 24 |
|
严重故障 1 |
严重条件 1 |
轻微攻击 1 |
偏差 25 |
|
严重故障 1 |
严重条件 1 |
中等攻击 1 |
偏差 26 |
|
严重故障 1 |
严重条件 1 |
严重攻击 1 |
偏差 27 |
应实现三级失效分级机制，基于影响 程度 进行横向控制失效程度分级 。失效程度用跟踪的稳态误差与瞬态偏差来衡量，轻微失效：跟踪的效果仍然为五次多项式轨迹，稳态偏差小于 +-10cm; 中度失效：跟踪的效果仍然为五次多项式轨迹，稳态偏差超出 +-10cm ；严重失效：跟踪的效果不是五次多项式轨迹或者为五次多项式轨迹但是稳态大幅度波动，幅度大于 50cm 。三级失效分级机制如下表所示。
|
三级失效分级机制 |
||
|
瞬态误差 |
稳态误差 |
失效程度 |
|
仍然为五次多项式轨迹 |
小于 +-10cm |
轻微失效 |
|
仍然为五次多项式轨迹 |
超过 +-10cm |
中等失效 |
|
不是五次多项式轨迹 |
----------- |
严重失效 |
|
------------ |
超过 +-50cm |
严重失效 |
横向换道控制轻微失效维持自动紧急换道能力 。 横向换道控制轻微失效时，车辆的 横向换道 控制存在一定偏差，但自动紧急换道功能的基本 能力 尚未被破坏。这种偏差通常在可接受的范围内，不会导致车辆明显偏离 跟踪路径 ， 对车辆横向换道的影响较小。
横向换道控制中度失效 时， 换道过程中可能出现车辆偏离预定轨迹、与其他车辆距离过近等安全隐患，车辆在换道过程中难以保持 规划 的轨迹，极易与周边车辆发生碰撞 ， 进行换道 的 风险较高。横向换道控制中度失效立即限制换道功能，采取保守的换道决策 。 采取保守的换道决策：这是中度失效时保障安全的核心策略，其核心在于根据车辆的状态以及驾驶条件来决定换道还是制动的形式来完成避障。具体决策逻辑如下：
车辆状态评估：软件实时采集车辆的当前速度等参数。当车辆速度较高（如超过 60km/h ）时，换道所需的距离增加，风险相应提高； 速度较大时 存在较大的横向偏移量， 而且稳态时间可能延长 。
驾驶条件评估：主要 是 目标车道的可利用空间、与 周围 车辆的距离和相对速度等。若目标车道前方有足够的 纵向 安全距离（如大于当前车速下的制动距离的 1.5 倍），且目标车道前方有足够的 横向 安全距离（ 偏差值导致的安全边界变大 ），同时道路平直则可考虑进行紧急换道避障。 当车辆决定是否换道时，对于目标车道的横向安全距离是第一个需要考虑的因素，只有足够的安全横向距离才能有足够的横向空间来容纳自车形式，车辆进行换道才能避开前方车辆，不发生碰撞。车辆在轨迹跟踪控制的异常则会影响控制精度，对于目标的横向换道距离存在偏差或者换道中会有波动，甚至是完全失去控制。足够容纳车辆行驶的横向空间一般为：
如上图所示，
其中
为自车的宽度，
为与边界预留的安全距离。此时车辆的换道横向距离应该满足：
即：
由于环境、场景以及故障和网络攻击的影响下，车辆在轨迹跟踪控制的异常则会影响控制精度，对于目标的横向换道距离存在偏差或者换道中会有波动，如下图所示。
对于车辆的控制偏差，有两种极端的情况：一是超出道路边界与边界发生碰撞，而是无法完成避障与前方跟随车辆发生碰撞，为了避免环境、场景以及故障和网络攻击对轨迹跟踪的影响从而导致发生碰撞的危险，同样对所需要容纳横向距离进行重新的修正：
其中
为轨迹跟踪偏差的容错距离，其大小随着轨迹跟踪偏差增大而增大，当轨迹跟踪完全失效时，其大小变为无穷大，因此需要根据不同的异常影响程度来确定其大小，进行调整动态。
决策逻辑执行：当车辆状态和驾驶条件均满足上述换道要求时，软件启动保守换道模式，在换道过程中增加转向控制的冗余量，降低换道速度，并增大与周边车辆的安全距离阈值。若有任何一项条件不满足，软件则选择制动避障方式，通过逐步增大制动压力，使车辆平稳减速，直至达到安全车速或停止。
横向换道控制中度失效，车辆减低车速并 启用 制动的方式来避障 。 在采取保守决策的同时，软件需根据与障碍物的距离和相对速度，计算出合适的减速度和制动时机。通过建立制动模型，结合当前路面摩擦系数（根据天气和路面状况估算），确保制动过程既能够有效避免碰撞，又不会对车辆的稳定性造成影响。当检测到潜在碰撞风险时，首先通过降低油门输出减少动力，使车辆自然减速，若减速效果不佳，则逐步施加制动，直至风险解除。
横向换道控制中度失效，触发多种报警方式来提醒驾驶员 ，在启用保守换道策略以及制动的同时， 需立即触发多种报警机制。视觉报警方面，在仪表盘上显示醒目的 黄 色警示图标，并伴随文字提示（如 “ 横向控制失效， 减速保守驾驶 ” ）；听觉报警采用高频蜂鸣声；触觉报警通过方向盘振动和座椅左侧或右侧的振动提示换道方向或危险方向，多维度提醒驾驶员 车辆正处于降级模式 。
横向换道控制严重失效立即禁用换道功能并进行减速避障 ， 根据与障碍物的距离和相对速度，计算出合适的减速度和制动时机。通过建立制动模型，结合当前路面摩擦系数（根据天气和路面状况估算），确保制动过程既能够有效避免碰撞，又不会对车辆的稳定性造成影响。
横向换道控制严重失效实现接管倒计时接管机制，多种接管提醒并每秒加强提醒强度 ， 在启动上述避障措施的同时，需立即触发多种报警机制。视觉报警方面，在仪表盘上显示醒目的红色警示图标，并伴随文字提示（如 “ 横向控制失效，请接管车辆 ” ）；听觉报警采用高频蜂鸣声，其频率随风险等级升高而加快；触觉报警通过方向盘振动（振动频率与蜂鸣声同步）和座椅左侧或右侧的振动（提示换道方向或危险方向），多维度提醒驾驶员及时接管车辆控制权。同时，报警信息需持续输出，直至驾驶员接管车辆或风险解除。
横向换道控制严重失效驾驶员未接管车辆时执行最小风险策略 。