泊车功能专题介绍 ———— 泊车功能整体设计特别关注点（持续更新）

介绍

 本文重点介绍的内容不针对某个功能，而是针对泊车功能的整体表现。本文属于持续更新的内容，如果有伙伴想了解的话，烦请点个收藏，方便后续的阅读。如果出现了不同意见，欢迎大家留言讨论。目前该文讨论的内容均是基于规则的自动驾驶方案，端对端的自动驾驶方案不在此文讨论范围内。

问题1 —— 视图显示问题

 随着功能的增加，各个功能之间对于中控屏的显示请求可能存在缺陷。基于现在的自动驾驶方案，功能的运行基本基于既有规则展开，那么必然会存在同时满足的情况。例如：在APA功能开启的过程中，切换至R档，此时退出功能，系统的表现应该如何？根据推荐国标《汽车全景影像监测系统性能要求及试验方法》来讲，R档状态下必须强制开启AVM功能。如果前期设计的过程中，系统需求未定义此问题，开发人员对相关功能整体的表现不清晰的情况下，这点就容易出现问题。接着例子，我们画一个时序图进行了解。

 从这里我们可以看到，其实出问题的地方在于红色方框内。此时对于HMI来讲，它收到了两个不同的显示请求。通常来讲，APA的功能优先级会高于AVM功能（注：APA功能页面下也可以观察车辆周围环境），所以HMI会选择不响应AVM侧的请求。如果在软件实现层面来讲，对于请求的处理为变化沿策略的话，此时必然会出现在APA功能退出后，无法进入AVM页面。这里其实并不是设计或者实现的问题，单拎出来，需求和实现都没有问题。针对上述问题，我个人认为的解决方案有两个：
   1. 显示请求持续发送，HMI持续关注显示请求。在显示屏幕空闲后，关注最终接收的请求。
   2. 显示请求不持续发送，HMI对请求进行记忆。在显示屏幕空闲后，显示最先记忆的请求。
 上述方案来讲，我的理解都存在一定的缺陷。对于方案1，在APA功能退出的过程中驾驶员再次切换档位至D当时，按照方案1的设计，最终HMI画面显示会是D档的视图，而非R档的视图。对于方案2，在APA功能退出的过程中驾驶员再次切换档位至D当时，按照方案1的设计，最终HMI画面显示会是R档的视图，而非D档的视图。在分析的过程中，我衍生出了一个新的解决方案，先显示R档视图，显示一段时间后切换至D档视图。针对于上述的方案，我个人认为都会有不同的见解。比如说：方案1 的问题点在于忽略了R档的显示请求，客户可能会抱怨为什么R档不响应AVM；对于方案2来讲，客户可能抱怨我处于D档却显示R档的的视图；对于衍生方案来讲，客户可能抱怨我明明在D档下什么都没有操作，视图为什么切换。我不是抛出一个问题，这里我是想引申出一个问题：功能设计可能不完美，但是不代表功能不能够使用。 工程设计追求的不是完美的设计，这或许不存在，工程设计追求的应当是最优解。


 上述的解决方案来讲，均可以解决APA功能退出后，无法响应档位激活AVM请求。对于OEM来讲，终端用户的使用不受制定的规则约束。如果不满足他的期望，他就可能产生不良的市场反馈。本着推动解决此问题的初衷，可能需要OEM基于前期的市场调研和常规的驾驶操作综合考虑最终的解决方案了。

问题2 —— 使用场景局限

 身为自动驾驶领域的从业人员来讲，在说明使用场景局限的问题前，我想先引入一个术语 —— ODD( Operational Design Domain)。这相当于功能运行的前提条件或者说是在ODD之内能保障功能正常运行。这部分内容常见于每个车型自带的用户手册上，例如下图是阿维塔11在官网上的用户手册上的说明文字。

 从OEM角度出发，这块相当于自己对系统功能局限情况的声明，但是实际的情况中，可能跟实际使用过程中存在差异。OEM无法要求用户在何种场景、何种条件使用功能，所以实际环境千变万化，无法详尽。针对现在的自动驾驶方案 —— 既有规则主导，从工程的角度来讲，ODD只能完善，无法完尽。按照我的理解，端对端的自动驾驶方案会有一定的改善。