康谋分享 | 如何应对ADAS/AD海量数据处理挑战？

随着软件定义汽车的发展，车辆生成的数据量也以前所未有的速度不断增加。这些数据包含广泛的信息，包括传感器数据、遥测数据、诊断数据等。在开发过程中，有效处理这些数据并从中获得见解至关重要。

对于原始设备制造商（OEM）和汽车一级供应商（Tier 1）来说，是否自主构建和维护数据处理流程是一个至关重要的考虑因素。数据处理流程是应对当下软件定义汽车所产生的海量数据的基础组件。

一、问题背景

在 AWS 等云平台上为高级驾驶辅助系统 （ADAS） 和自动驾驶 （AD） 数据构建鲁棒的数据处理流程，通常需要全面了解各种服务及其集成。您可能使用的特定服务可能取决于应用程序的要求、数据源和处理需求。

为了解决这一问题，康谋通过使用IVEX提出了专门用于应对ADAS/AD海量数据的数据处理流程。该流程的核心目的是自动从原始传感器数据等输入中识别出值得关注的事件和场景。构建这样的数据处理流程需要仔细考虑各种技术方面，例如：原始传感器数据的云端存储、基于原始数据的算法执行（包括需要例如GPU等特定资源的机器学习算法）、事件和场景等后处理数据的存储机制、算法版本控制、结果可视化以及确保数据仅对授权用户可见。

二、内部构建或获取预组装解决方案

IVEX的数据处理流程基于多种AWS服务实现无缝衔接，以下是经过策略性部署的AWS服务：

1. 原始传感器的数据（包括激光雷达点云、相机图像和GNSS信息）存储在S3存储服务中。S3用作采集数据的暂存地，为后期处理的数据提供扩展存储，并为处理提供经济高效的短期存储解决方案。此外，使用S3挂载点功能能让S3作为主要的“处理卷”，使其能够像文件系统一样使用。虽然它不完全符合POSIX标准，对某些工作负载存在限制，但可以通过整合EFS和可能添加的FSx来解决这个问题，以根据需要确保兼容性。

2. 处理后的数据（重要事件和场景）存储在关系型数据库服务（Relational Database Service，RDS）和DocDB中。RDS是一个高效的存储库，用于组织对分析至关重要的标记数据。同时，DocDB作为文档存储运行，它是专为快速变化的数据和显示目的所需的二进制数据而设计的。

3. EKS和EC2处理算法执行和可视化任务。EKS充当一系列服务的主机，包括后端、数据服务、前端和处理服务。EC2主要用于根据为EKS制定的规则配置机器。

4. 算法的版本控制通过 ECR 进行管理。ECR用于存储Docker容器镜像。

5. 身份验证通过Cognito进行。如果有必要，可以灵活地替换为任何OpenID Connect （OIDC）解决方案。

6. 数据传输和临时数据存储通过EFS进行管理。EFS作为临时处理区域运行，供各种数据处理流水线存放中间数据并促进不同进程之间的数据共享。因为EFS完全符合POSIX标准，所以可以选择它作为S3的替代文件系统。

这个方案示例突出了构建鲁棒的ADAS/AD数据处理流程所涉及的众多云服务，并强调了应对各种技术复杂性的必要性。此外，还必须解决诸如组织输入数据、确保数据格式兼容性以及管理和监控数据格式变化等挑战。

例如，随着ADAS/AD系统的发展，添加更多传感器以及管理不同车辆配置的需求成为数据处理流程中的关键考虑因素。如果不加以妥善处理，这些因素可能会导致不正确的数据处理，最终得到错误的结果。

上图列出的是构建此数据处理流程的预计工作量和成本细目，该处理流程可标记12种驾驶场景、提取驾驶参数，并支持可视化大型文件（≥ 10TB）。

三、总结

总之，解决上述的这些问题需要付出大量的努力。显而易见的是，选择预先搭建好的数据处理流程将拥有更低的开销。此后，便可以将节省的时间和成本分配给开发OEM和Tier1产品的关键方面。