目 录
0 修订历史... 2
1. 概要... 5
1.1. 目的... 5
1.2. 适用范围... 5
1.3. 参考文档... 5
2. 缩写或定义... 5
3. 业务概述... 6
3.1. 业务视图... 6
3.2. 功能描述... 6
3.2.1 状态监控... 6
3.2.2 数据收集和上报和分析... 7
3.2.3 故障诊断... 7
3.2.4 失效保护... 7
3.2.5 故障恢复... 7
3.3. 性能描述... 7
3.3.1 状态监控... 7
3.3.2 故障诊断... 8
3.3.3 数据收集... 8
3.3.4 失效保护... 8
4. 总体设计... 8
4.1. 概述... 8
4.2. 状态监控... 9
4.3. 故障诊断... 10
4.4. 失效保护... 11
4.5. 故障恢复... 12
4.6. 业务需求实现... 13
4.6.1 司机操作类... 13
4.6.2 车身类... 15
4.6.3 业务逻辑类... 17
4.6.4 HAVP 退出... 19
4.6.5 HAVP 中断... 20
4.7. 数据收集上报... 21
5. 软件故障表... 21
概要
目的
本文档定义AVP中安全运行相关的的架构设计。用于说明其含义，范围，主要接口，实现约束，功能列表和功能的主要对内和对外接口，以指导后续设计和开发。
适用范围
读者包括：开发人员，产品人员和测试人员。
参考文档 缩写或定义
AVP（Automate Valet Parking）：自主泊车产品总称。
HAVP（Home-zone Automated Valet Parking）：应用于私人停车场的自主泊车产品，可通过手机APP实现50米内的远程取还车。
PAVP（Public-zone Automated Valet Parking）：应用于公共停车场的自主泊车产品，实现从停车场入口到车位的无人驾驶。
CMS（Condition Monitor System）：状态监控系统，该系统通过对车身及系统数据的实时监控及时发现异常，从而对车辆采取有效的保护措施，并将故障及时上传云端，报告给用户。
FPM（Failure Protection Mechanism）：失效保护机制，当系统监控到失效时，对车辆采取有效的保护措施。
卫兵系统：AVP系统安全系统的统称，其中包含安全系统状态监控+失效保护统称为卫兵系统。
业务概述
业务视图
在技术实现上，卫兵系统分为：状态监控、故障诊断、失效保护、故障恢复、数据收集、守护进程等车端模块。同时通过数据回传通路，系统安全相关数据会上报云端，并在云端通过数据分析实现对车端功能迭代和效果优化。
功能描述
状态监控
获取系统在运行过程中，各个子模块产生各种错误信息。监控项包括车身、硬件、系统、执行器等方面的数据。
数据收集和上报和分析
发生异常时，收集相关数据，上报到云端。在云端分析回传的数据。通过对收集的数据进行统计分析，能够更加精准地给出监控的阈值，提升监控的准确性。
故障诊断
对异常信息作出梳理判断，找出问题出现的根本原因，并将根本原因输出，供故障恢复模 块执行恢复动作 。
失效保护
当系统失效时，发出刹车命令，降低车辆碰撞风险。
故障恢复
对可恢复故障采取有效恢复措施。
车身和硬件故障为不可恢复故障，发生此类故障后，卫兵应该采取的动作为：刹停，上报状态，等待维修 。
发生系统故障时，或者尝试清理磁盘，或等待适当时间，若故障依然不能恢复则转入功能故障状态。
发生执行器故障时，尝试重启执行器，若故障依然不能恢复则转入功能故障状态。
性能描述
在2m/s(7km/h)的速度下，要在故障发生后，1.5m以内实现刹车。
状态监控
覆盖率100%，发生异常后，要求在100ms内捕获异常。
故障诊断
诊断正确率100%
数据收集
收到异常后，要将异常发生前后一段时间的数据收集、打包，以用于研发分析。
失效保护
收到异常后，要求在100ms内发出刹车指令（到UMB）。
总体设计
概述
故障信息的收集包括三个大方向，分别是：
算法内部故障信息，系统资源监控的故障信息，硬件故障信息。
其中：
硬件故障通过uds[W,2] 上报，然后通过数据采集模块向云端同步； 算法内部故障和系统资源监控的故障通过mlog的report机制将故障信息输入到pavaro框架中。同时在pavaro的参数服务器中设置一个表示有系统严重故障的标志位，Uds每个周期检查此标志位，当有系统严重故障时，UDS通过umb中心将故障发送到MCU，此时MCU进入接管流程，MCU会进行刹车，切P档，退线控的操作。当MCU进入接管流程后，会通知canreader此时MCU进入故障处理流程，canreader发出对应的topic通知相关模块这一事件，状态机收到此topic后，将状态切换成standby，随后HMI走break和stop的流程。[W,3] MCU在 MSG_PP_Sta 消息中增加 Mcu_Sta_Mach 字段， car_info_datasource 在收到 MSG_PP_Sta消息时根据 Mcu_Sta_Mach 字段判断当前MCU的状态，并做出动作。
Mcu_Sta_Mach == 12[W,4] 时， car_info_datasource 抛出 automode_request 数据，其中携带退出自动驾驶的请求，即 automode_request = false。can_sender_exec 在收到 automode_request == false 时， 退出线控，进入非自动驾驶状Mcu_Sta_Mach == other 时， 不处理。 CU[W,5] 新增 0x181 frame （MSG_CAN_RD），can_sender 根据当前所处的状态，给MCU发送对应的 Havp_Alg_Sta：
非自动驾驶状态下发送 Havp_Alg_Sta = 0；开始请求握手时发送 Havp_Alg_Sta = 2；握手成功进入自动驾驶后发送 Havp_Alg_Sta = 1;
状态监控
Monitor的工作原理如下图所示，监控内容包含了算法内部错误，CPU，内存，flash使用超限，数据流频率异常，车身信息异常，车辆配置参数异常，硬件异常。每种错误或者异常在Monitor内部都有一个与之对应的detector负责具体的监控工作。Monitor每个周期执行时会将每个detector发现的故障汇总成一个err_code的故障列表，诊断和数据回传将获取此故障列表做后续的处理。[W,6]
故障诊断
Diagnosis模块内部维护一个根因表，根因表记录着所有可能导致系统严重故障的根因err_code。诊断模块首先从monitor获取此时的故障列表，然后在内部根因表中进行根因匹配，匹配过程如下图所示，需要通过框架提供的相关接口，查找对应err_code的上游执行器和数据源，再通过反馈回来的执行器和数据源与故障列表中的故障进行匹配，若匹配成功，则说明当前被识别的故障在故障列表中存在上游故障，因此当前被识别的故障非根因，应该从故障列表中将其删除。[W,7]
失效保护
在正常行驶中，车辆的刹停由control模块输出，并经仲裁模块转发，can_sender模块翻译为线控命令最终实现控车。当系统出现异常时，故障诊断模块发出紧急刹车指令，同时通知control模块。仲裁模块保证紧急刹车指令被最高优响应，减少时延。control模块被通知处于紧急刹车状态后，也做出对应的处理（内部状态机流转）。[W,8]
Supervisor实现进程级的失效保护，为主进程（avp-pavaro eda）失效或者SOC整体失效提供保护。MCU监听『supervisor心跳为supervisor失效』或『soc死机心跳消失』后的进行刹车和流转状态，并进行故障处理（重启SOC）。[W,9]
故障恢复
对可恢复故障采取有效恢复措施。恢复措施包括：对执行器进行reset操作、重启执行器所在线程、重启Pavaro进程、重启Soc等。[W,10]
好文链接
您阅读本篇文章共花了：
发表评论