自动驾驶代客泊车架构设计说明书

目    录

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

1. 概要
   1. 目的

本文档定义AVP中安全运行相关的的架构设计。用于说明其含义，范围，主要接口，实现约束，功能列表和功能的主要对内和对外接口，以指导后续设计和开发。

1. 1. 适用范围

读者包括：开发人员，产品人员和测试人员。

1. 1. 参考文档
2. 缩写或定义

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系统安全系统的统称，其中包含安全系统状态监控+失效保护统称为卫兵系统。

1. 业务概述
   1. 业务视图

在技术实现上，卫兵系统分为：状态监控、故障诊断、失效保护、故障恢复、数据收集、守护进程等车端模块。同时通过数据回传通路，系统安全相关数据会上报云端，并在云端通过数据分析实现对车端功能迭代和效果优化。

1. 1. 功能描述
      1. 状态监控

获取系统在运行过程中，各个子模块产生各种错误信息。监控项包括车身、硬件、系统、执行器等方面的数据。

1. 1. 1. 数据收集和上报和分析

发生异常时，收集相关数据，上报到云端。在云端分析回传的数据。通过对收集的数据进行统计分析，能够更加精准地给出监控的阈值，提升监控的准确性。

1. 1. 1. 故障诊断

对异常信息作出梳理判断，找出问题出现的根本原因，并将根本原因输出，供故障恢复模 块执行恢复动作 。

1. 1. 1. 失效保护

当系统失效时，发出刹车命令，降低车辆碰撞风险。

1. 1. 1. 故障恢复

对可恢复故障采取有效恢复措施。

车身和硬件故障为不可恢复故障，发生此类故障后，卫兵应该采取的动作为：刹停，上报状态，等待维修 。

发生系统故障时，或者尝试清理磁盘，或等待适当时间，若故障依然不能恢复则转入功能故障状态。

发生执行器故障时，尝试重启执行器，若故障依然不能恢复则转入功能故障状态。

1. 1. 性能描述

在2m/s(7km/h)的速度下，要在故障发生后，1.5m以内实现刹车。

1. 1. 1. 状态监控

覆盖率100%，发生异常后，要求在100ms内捕获异常。

1. 1. 1. 故障诊断

诊断正确率100%

1. 1. 1. 数据收集

收到异常后，要将异常发生前后一段时间的数据收集、打包，以用于研发分析。

1. 1. 1. 失效保护

收到异常后，要求在100ms内发出刹车指令（到UMB）。

1. 总体设计
   1. 概述

故障信息的收集包括三个大方向，分别是：

• 算法内部故障信息，
• 系统资源监控的故障信息，
• 硬件故障信息。

其中：

1. 硬件故障通过uds[W,2] 上报，然后通过数据采集模块向云端同步；
2. 算法内部故障和系统资源监控的故障通过mlog的report机制将故障信息输入到pavaro框架中。
3. 同时在pavaro的参数服务器中设置一个表示有系统严重故障的标志位，Uds每个周期检查此标志位，
4. 当有系统严重故障时，UDS通过umb中心将故障发送到MCU，此时MCU进入接管流程，MCU会进行刹车，切P档，退线控的操作。
5. 当MCU进入接管流程后，会通知canreader此时MCU进入故障处理流程，canreader发出对应的topic通知相关模块这一事件，状态机收到此topic后，将状态切换成standby，随后HMI走break和stop的流程。
6. [W,3] MCU在 MSG_PP_Sta 消息中增加 Mcu_Sta_Mach 字段， car_info_datasource 在收到 MSG_PP_Sta消息时根据 Mcu_Sta_Mach 字段判断当前MCU的状态，并做出动作。
   1. Mcu_Sta_Mach == 12[W,4]  时， car_info_datasource 抛出 automode_request 数据，其中携带退出自动驾驶的请求，即 automode_request = false。
   2. can_sender_exec 在收到 automode_request == false 时， 退出线控，进入非自动驾驶状Mcu_Sta_Mach == other 时， 不处理。
7. CU[W,5] 新增 0x181 frame （MSG_CAN_RD），can_sender 根据当前所处的状态，给MCU发送对应的 Havp_Alg_Sta：
   1. 非自动驾驶状态下发送 Havp_Alg_Sta = 0；
   2. 开始请求握手时发送 Havp_Alg_Sta = 2；
   3. 握手成功进入自动驾驶后发送 Havp_Alg_Sta = 1;

1. 1. 状态监控

Monitor的工作原理如下图所示，监控内容包含了算法内部错误，CPU，内存，flash使用超限，数据流频率异常，车身信息异常，车辆配置参数异常，硬件异常。每种错误或者异常在Monitor内部都有一个与之对应的detector负责具体的监控工作。Monitor每个周期执行时会将每个detector发现的故障汇总成一个err_code的故障列表，诊断和数据回传将获取此故障列表做后续的处理。[W,6] 

1. 1. 故障诊断

Diagnosis模块内部维护一个根因表，根因表记录着所有可能导致系统严重故障的根因err_code。诊断模块首先从monitor获取此时的故障列表，然后在内部根因表中进行根因匹配，匹配过程如下图所示，需要通过框架提供的相关接口，查找对应err_code的上游执行器和数据源，再通过反馈回来的执行器和数据源与故障列表中的故障进行匹配，若匹配成功，则说明当前被识别的故障在故障列表中存在上游故障，因此当前被识别的故障非根因，应该从故障列表中将其删除。[W,7] 

1. 1. 失效保护

在正常行驶中，车辆的刹停由control模块输出，并经仲裁模块转发，can_sender模块翻译为线控命令最终实现控车。当系统出现异常时，故障诊断模块发出紧急刹车指令，同时通知control模块。仲裁模块保证紧急刹车指令被最高优响应，减少时延。control模块被通知处于紧急刹车状态后，也做出对应的处理（内部状态机流转）。[W,8] 

Supervisor实现进程级的失效保护，为主进程（avp-pavaro eda）失效或者SOC整体失效提供保护。MCU监听『supervisor心跳为supervisor失效』或『soc死机心跳消失』后的进行刹车和流转状态，并进行故障处理（重启SOC）。[W,9] 

1. 1. 故障恢复

对可恢复故障采取有效恢复措施。恢复措施包括：对执行器进行reset操作、重启执行器所在线程、重启Pavaro进程、重启Soc等。[W,10]