作者 | Jessie
智能驾驶功能的逐渐普及使得整个功能设计已经在不知不觉中被人们所认可和接受了，当然相比于传统汽车功能来说，我们更希望看到一种相互磨合，相互成就的状态。这实际就是在智能驾驶各类功能开发过程中能够更多的考虑其对汽车传统驾驶功能的影响，特别是针对那些影响车辆基础功能的智驾系统功能就需要更多的考虑其设计要素中的互斥性。本文以智能驾驶系统的多个主要关联系统功能为例，说明如何对智能驾驶系统功能设计能够使其应用对整车控达到最优化。
本系列文章将就这些基础的汽车功能如何融入到先进的智能驾驶功能中进行详细的方案分析，以为读者提供更多在 ADAS 功能开发为前提下的设计前端思考和优化策略。
哨兵模式
哨兵模式功能是一种在智能汽车领域已经被大家完全熟悉的一种功能，实际是一种由特斯拉首创的功能。由于其是通过调用泊车系统环视摄像头对车辆一周进行实时持续的监控。探测到可疑行为时，车辆可根据对应可疑行为发出声音报警、自动拨通车主电话、打开报警灯等不同程度的警示行为，同时会将该可疑行为进行自动记录并保存上传等，其结果是有效的提醒了车主可能有事故发生。
那么具体如何定义哨兵模式的工作状态呢？
哨兵模式整个工作前提是停车、熄火，用户通过影音娱乐系统进程或手机端远程开启，智能座舱域控单元以最低功耗调用其被智驾域控控制的环视摄像头进行影像传输。在接收端通过视频回放、下载、删除等操作可以很好的还原即时场景。如此，整个工作过程涉及的要素包含如下：
智驾域控：负责接入环视摄像头。实际上，由于环视摄像头的主要目的是用来做泊车控制的，因此对于实时性要求高的驾驶泊车辅助场景来说肯定是直接接智驾域控了。
如上图所示，哨兵模式工作在图中的硬件系统中，哨兵模式软件运行在智驾域控主机软件中，显示端口在主机的外设 IVI 总成或手机显示屏上进行显示。整体上要求座舱域控的主机及智驾域控的硬件系统链路要能保证视频接入必须是低延时的（如在帧率为 20fps 下需小于 40ms 传输延迟）。其次，智驾域控需要在接收到车身指令后高效的打开摄像头，并开启视频录制端口，其开启指令执行效率或延迟不可超过 3s。最重要的是不可出现时序不同步及时序错乱。
对于各部分承担的工作如下所示。
1、视频源输入：
环视视频输入是通过环视摄像头（或称全景摄像头）对近车身外的影像并传输给中央智驾域控的。
2、视频数据处理：
对于智驾域控而言，需要负责将全景摄像头的数据转换成主机智能座舱域控 SOC 能够识别的数据格式。期间，还需要保持视频一定的电平格式、且满足建立保持时序；对于智驾域控而言，需要接收车身控制器以及车身的其他控制指令打开全景摄像头，同时生成同步时间戳后输入至收端智能座舱域控。
3、工作状态管理：
智驾域控与智能座舱域控的视频传输一般是直接进行的，智驾域控需要反馈摄像头的开闭状态及异常状态，同时反馈智驾域控自身工作状态（如 Working、Standby、OFF、Sleep 等状态），并将该状态通过网关转发后输入至智能座舱域控。其目的是智能座舱域控通过该状态反馈可以有效判定视频输入的合理性，输入失效原因等。
行车记录仪 DVR 及其增强版 AVR
行车记录仪实际是一个相对简单的传统汽车功能。其启动过程也非常简单，这里为什么和 ADAS 相关功能扯到一起呢？是因为，对于在智能驾驶系统中实现行车记录仪会相对实现更高版本的功能。比如传统行车记录仪分辨率通常采用 100-200 万像素摄像头进行行车记录，而相对于更高配置的智能驾驶功能而言，则通常是将 800 万像素高清前视摄像头复用作为行车记录仪，当然此时可以记录更加清晰的视频。此外，对于带有智能驾驶功能的汽车而言，很多还往往同时会对行车记录这块提出了更高标准的记录要求，比如通过将全景摄像头视频数据纳入到整个行车记录过程中来，实现对车辆周边的全视角视频录制。此外，对于很多场景还会有专门针对车内驾驶员的视频采集和录制。
这里需要注意的是，针对高级自动驾驶的车辆视频录制的先进功能要重点考虑如下一些可能产生的限制要素：
1）关于前视摄像头复用为行车记录仪是否可行，还要重点考虑行车记录仪对于视频记录清晰度、完整度。
比如通常情况下行车记录仪需要将车辆前舱拍摄到记录的视频中（因为主要考虑一些碰撞时直接撞到机舱盖上），然而从纯粹 ADAS 功能要求的感知视频则是尽量不要让前舱盖挡住对于前向目标的拍摄，因为可能导致漏识别。那这两者可能存在的矛盾点就是需要在设计中做平衡的。当然从国标对行车记录仪的角度讲，可能需要更加关注行车记录对视频的需求，而摄像头的前方探测盲区大部分还可用前毫米波雷达、前环视摄像头、前激光雷达加以弥补。
2）关于如何对高清多视角视频进行有效的编码存储也是后续行车记录仪需要重点考虑的问题。
比如在考虑多路视角输入的 AVR 视频录制再加上对前视视频的录制，整体对于存储卡的能力要求就有很大程度的提升。那么对智驾域控而言，就提出了很高的视频编码能力要求。比如很多 SOC 芯片的编码能力只支持 H.264 的标清视频编码，这样就不适合与这类高清多视角的是视频编码了。对于我们的芯片选型而言就需要支持到 HEVC 这样的高清视频压缩能力了。
3）关于行车记录过程如何考虑对于域控制器的算力和功耗分配问题，也是需要我们提前做好规划的。
看起来作为一个小小的视频录制，实际没有涉及到实际感知处理过程，是否就可以认为不耗费任何算力和功耗呢？实际不然，就像之前哨兵模式说的，对于由智驾域控控制的摄像头来说，是需要启动其中的 IIC 控制线对摄像头进行开闭，同时启动时间同步模块打上时间戳后，才能输入相应的视频源的，而这一切都是需要启动芯片并做好算力、功耗预留的。当然，从设计优化的角度出发完全可以通过控制内部芯片中涉及到视频处理的这部分芯片（如下图缩水）进行单独启动，从而可以最大限度的降低功耗和算力。
远程实时监控功能
远程实时监控功能，顾名思义主要实现在车辆状态满足条件时，用户可以在 App 端实时查看车辆内部、车前（外）及周围的实时影像，也支持拍摄单张照片。其工作原理是通过手机或 iPad 启动云服务并调用车内摄像头进行座舱内监控，同时融合全景影像和行车记录仪功能实时监控车辆周边实时情况。
这个功能更加适用于女性驾驶员通过此功能实现车内遗落物品（钥匙、手机、包包、小孩、宠物）查找及车辆周边情况的查看。实现对车辆的远程查看而不必近身车辆，从而确保很大程度下的安全性。
综上，对于远程监控的千里眼功能主要涉及要素包括监控实时性、监控无死角、功耗尽量低等。以上可能由于车型硬件规划不同，各摄像头所属模块存在差异。比如行车记录仪是否与前视摄像头复用，可能导致在设计本功能时考虑是否驱动智驾域控中的前视摄像头模块。同时，整个影像显示系统与摄像头间交互亦存在差异。
如上图所示，对于整个开发远程移动监控功能主要涉及如下几个关键要素：
1）实时视频调用：
远程监控的摄像头调用主要通过前视摄像头视频调用（根据实际情况可以是单独的行车记录仪，也可以是复用智驾系统的高清前视探测摄像头）、全景 / 倒车影像调用、以及车内摄像头调用。其中视频采集前还需要进行车辆状态查询（一般是包括是否上电打火、门锁状态、档位状态等）、控制摄像头自学习（配置信息、标定状态、视频采集状态）、流量控制状态等。
2）视频处理
整个监控前端需要进行包含视频采集、视频脱敏、视频拼接、图像渲染（可选）、时间水印等。同时，还可以根据实际环境情况选择是否进行手动远程补光以增强视频采集效果；如果针对车内监控而言，很多厂家还可能采用灵活布置摄像头（比如电动 DMS/OMS）的方式，此时也可以远程增加与 DMS/OMS 之间的信息交互（如升起 / 降下摄像头）。如果考虑数据安全，一般会对采集的视频进行脱敏处理后在回传，甚至有时候在驾驶时候就直接通过合规开关关闭摄像头视频采集了。
3）视频查看
如果考虑远程查看而言，需要通过云端信息检测车辆是否处于驻车档，门锁是否关闭，车辆相关的摄像头是否被占用，整个无线传输链路是否被打开。如果以上条件均满足时，可以启动相应的视频查看开关通过不同的开关选项，对视频进行包含前向、侧向、后向、车内等影像查看。当然，如果车内本身已有用户存在，对于视频查看需要满足该用户 「确认」 这一前提条件才可以被远程用户启动查看。
如下表示了整个远程监控功能的工作时序图：
很明显对于整个远程视频监控功能而言，从智驾系统来说，需要提供的部分除了与哨兵模式一样的全景摄像头视频信息外，还需要根据车型前视摄像头和行车记录仪的复用情况选择是否需要打开和控制前视视频流的输出。如果是纯粹的行车记录仪而言，对于智驾域控的需求就和哨兵模式没有太大的区别了。但是对于复用前视摄像头的行车记录仪而言就需要充分考虑如何以最低功耗和代价打开前视摄像头为后端录入视频。
由于前视摄像头对于整个 ADAS 功能感知起着举足轻重的作用，通常会把前视摄像头放到与智驾域控中最为核心的 SOC 处理端口进行处理。因此在启动智驾域控整体处理核模块时才能将整个前视部分调度起来。然而，视频监控这类应用又是一种时间完全不受控的基础服务（也就是说用户用多少时间是完全不受控的，长时间的使用会导致电量的大量消耗）。我们在设计过程中就需要充分考虑其是否能从节约功耗角度出发，设计满足整体需求的系统。
总结
对于以上影像功能来说，由于对于智驾域控来说只是使用了其在对摄像头的简单开闭过程中的驱动功能，而并未使用其高功耗的 SOC 进行 AI 信息处理。而对于影像传输或显示记录来说，通常很可能是一种长时间的电量消耗。因此，在设计智驾域控相对来说，需要考虑在影像功能激活时可以充分降低其运行功耗，以增强整车的续航或待机能力。
