标签: 数据处理

随着软件定义汽车的发展，车辆生成的数据量也以前所未有的速度 不断增加 。这些数据包含广泛的信息，包括传感器数据、遥测数据、诊断数据等。在开发过程中， 有效处理这些数据并从中获得见解 至关重要。 对于原始设备制造商（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产品的关键方面。

随着软件定义汽车的发展，车辆生成的数据量也以前所未有的速度 不断增加 。这些数据包含广泛的信息，包括传感器数据、遥测数据、诊断数据等。在开发过程中， 有效处理这些数据并从中获得见解 至关重要。 对于原始设备制造商（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产品的关键方面。

随着软件定义汽车的发展，车辆生成的数据量也以前所未有的速度 不断增加 。这些数据包含广泛的信息，包括传感器数据、遥测数据、诊断数据等。在开发过程中， 有效处理这些数据并从中获得见解 至关重要。 对于原始设备制造商（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产品的关键方面。

一、前言 作为一名 高校的科研工作者 ，在高校的科研工作中，经常需要处理各种复杂的数据流，尤其是 视频采集和处理 的工作，对数据的实时性和精度要求非常高，我首次试用ADTF时，主要负责开发一个 集成FFmpeg的Filter组件 ，处理摄像头采集的raw数据，并对其进行H264编解和解码。在这个试用的过程中，我对ADTF的初步体验是它的设计 非常便捷 ，尤其是对于 图像和视频数据的处理。 通过这次开发，我对 ADTF的模块化设计、流数据传输机制以及其便捷的开发环境 有了更加深刻的认识。接下来，我将从多个角度详细分享我的试用体验，内容涵盖 ADTF的优势、工作流程中的亮点 ，以及 未来展望 等方面。 二、ADTF的用户界面与灵活性 在打开ADTF时，我觉得其 直观的GUI设计 非常的友好。作为一名高校科研工作者，我们通常需要频繁的调整实验配置、切换不同的开发场景，而ADTF的界面布局使得这些操作变得十分便捷。 其工具栏、Component、Sessions管理以及快捷命令栏 的存在，极大的 优化了工作的流程 。能够在搭建工作流时，迅速的找到所需要的工具和组件，并轻松的管理多个实验配置，这在需要进行多项实验的科研工作中尤其重要。 ADTF的模块化设计 使我能够快速自由的组合各种组件，构建适合 具体科研需求 的工作流。例如，我能够通过ADTF提供的Store模块，轻松地管理不同的数据流和实验配置。这种灵活性对于需要 快速迭代实验和算法验证 的科研工作来说非常有利。 三、便捷的组件开发 我在ADTF中开发的Filter组件，集成了FFmpeg进行H264图像数据编解码，这使得我能够处理摄像头采集的raw数据。ADTF提供了 标准的图像数据流定义 ，使我可以快速上手，并通过 自定义的数据流类型进行数据的高速传输。 让我印象深刻的是，ADTF允许我创建自定义的流类型，并将编码后的视频数据发送至下一个Filter进行解码。这种模块化的设计对于处理复杂的多步数据流非常有帮助，尤其是在 处理视频和音频等 连续数据时。 ADTF的流数据传输机制非常稳健 ，特别是在 高速数据吞吐 情况下，它依然能够保证数据的完整性和及时性。例如，当我处理大规模视频数据时，ADTF通过其文件的流数据传输体系很好地管理了数据流的传输，确保没有出现数据丢失的现象。这一点在要求 高精度 的场景下， ADTF的表现非常好 。 此外，ADTF的组件开发过程也充分展示了其 灵活性 。在开发Filter组件时，ADTF中可以自定义流类型，不仅能与标准化的数据流兼容，还能针对特定需求自己定义。通过这种方式，我可以轻松的将编码后的视频数据 传输至下一个 解码或者处理视频数据的组件，实现多步数据流处理。在整个开发过程中，我清晰地感受到了ADTF模块化设计所带来的便利，它允许我 根据不同的实验需求进行自由组合和扩展。 四、丰富的工具箱和组件 ADTF还有一个非常好的亮点是它 丰富的工具箱 。我在开发组件的过程中直接使用了ADTF自带的Windows摄像头驱动采集数据，避免了繁琐的硬件配置。此外，ADTF还提供了Qt以及foxglove等显示组件，使我能够实时监控摄像头捕获的视频流，很大程度上方便了我的开发和测试。这种 预制组件的存在大幅度缩短了开发时间 ，我可以把更多的精力集中在数据处理的核心逻辑上。 在科研项目中，快速的验证新算法和新想法是我们的日常工作。 ADTF通过大量现成的组件，帮助我们在短时间内可以搭建一个完整的测试环境 。例如：我可以迅速继承已有的摄像头采集组件，并通过简单的操作和配置就可以完成视频流的显示和存储。这种集成工具的便利性是在科研工作中快速迭代优化的重要支撑。 五、外部库与ADTF完美结合 在科研项目中，大部分的功能需要 依赖外部库 ，比如OpenCV、FFmpeg…，在这次的开发过程中，我通过FFmpeg对摄像头采集的raw数据进行H264编解码。 ADTF的开放性和模块化 使得FFmpeg的集成过程十分顺畅，通过Filer组件可以轻松调用FFmpeg的功能，将raw数据进行编码，并在解码阶段还原数据进行显示。 FFmpeg强大的视频处理能力与ADTF的稳定数据流传输机制相结合，使我能够达到项目中要求的实时数据处理。通过把FFmpeg集成到ADTF中，我能够以较低的系统资源消耗完成高效的视频编码和解码，还可以在我设计不同的试验方案时，快速的帮我搭建适合试验方案要求的工作流。 ADTF与FFmpeg的结合组件展现了非常出色的扩展性和稳定性。 六、未来展望 通过对ADTF的使用，我认为ADTF为高校的科研人员提供了一个强大的数据处理和开发平台，A DTF在处理大规模数据流、视频数据编解码等领域具有极大的潜力。 这种模块化设计使我们能够轻松定制复杂的工作流程，特别是在处理多个传感器数据和视频流时，ADTF提供了极高的灵活性。 在未来对ADTF的使用中，我将会进一步探索ADTF在 自动驾驶、智能交通系统等领域 的应用，并希望能够看到它在数据处理和算法开发中的更多突破。

在上期 数据隐私和匿名化系列 文章中，我们主要分享了 《中国个人信息保护法》（PIPL） 和 《欧盟通用数据保护条例》（GDPR） 在 涵盖范围、定义、敏感信息 等方面的异同点，今天，我们将重点分析PIPL与GDPR在 数据处理行为及其基础合法性 方面的异同，旨在帮助车企更准确地把握数据隐私保护法规的要求，有效应对相关挑战，推动自动驾驶行业健康发展。 一、PIPL和GDPR的异同点 1、数据处理行为定义 两部法规（PIPL和GDPR）均明确界定了 不同的数据处理行为 ，这些行为将触发各自法规的管理范畴。此处所提及的信息， 已不再局限于敏感信息 ，而是涵盖了两部法规所规定的 所有相关信息 。 在 英文版的PIPL 中，数据处理行为被表述为“ Handling ”，而 GDPR 则使用 “Processing” 一词，两者在本质上并无区别。然而，在 数据处理行为的定义上，两部法规却存在些许差异 。 PIPL中的“Handling”涵盖了 收集、存储、使用、加工、传输、披露以及删除个人信息 等一系列行为。相较于PIPL， GDPR 关于数据处理行为的定义则 更为详尽 ，除了包含上述相同的行为外，还涉及到了 个人数据的检索、咨询 等多个方面。 但实际上，当我们深入探讨PIPL中定义的数据处理行为时，相关法律专家指出： “在中国境内处理个人信息时，GDPR所涵盖的任何数据行为都需要被纳入考虑范围，即使PIPL并未完全列举出所有要点。” 由此可见，在各自司法管辖区域内处理相关数据时，任何数据处理行为都将受到该区域法律条例的约束。 2、数据处理基础合法性 为了进一步对比数据处理行为的异同，我们在此列举了中国的《个人信息保护法》（PIPL）与欧盟的《通用数据保护条例》（GDPR）在 数据处理基础合法性 方面的相关规定。 “同意”（Consent） 是指数据主体明确授权或表示同意其个人数据被处理的行为。这种同意必须是建立在充分知情的基础上，且必须是明确且自愿给出的。 除了“同意”这一点外，我们重点关注两部法律在 合法利益（Legitimate Interest）和公共利益（政府任务）（Public Interest/Government Task） 方面的差异。实际上，PIPL在这两点上并未作出明确规定，这主要归因于中国和欧洲在法律及监管环境上的差异。 首先在 合法利益 这一点上，GDPR作为欧洲地区的人权保护框架，旨在平衡企业与个人之间的权益，为企业提供一定的 灵活性 ，允许其在没有明确同意的情况下处理个人数据，从而在一定程度上增强了企业的自主权。相比之下， PIPL更加强调对个人信息的严格控制。 在处理个人数据时，PIPL要求必须获得明确的授权或依据法律规定进行，更倾向于通过明确同意或法律规定来实施严格监管。 其次在 公共利益 方面，两部法律对公共事务和政府职责的界定存在差异。 GDPR 在确保公共机构履行任务时赋予了更大的 灵活性 ，而PIPL则通过其他法律条款来规范政府的处理权限，更加侧重于 信息透明性和数据主体的保护 。 二、信息跨境处理注意事项 在 跨境处理信息 的过程中，除了需遵循《个人信息保护法》（PIPL）和《通用数据保护条例》（GDPR）这两部基础法律的规定外，还需执行一系列严格的 安全评估措施。 以中国车企为例，若需将欧盟境内的数据传输回中国进行处理，必须确保该跨境数据传输完全符合GDPR的严格要求。 GDPR对向欧盟外传输数据有着明确的规范，要求必须依赖 标准合同条款（SCCs）或充分性决定（Adequacy Decision） 来确保数据的合法传输。特别是当涉及敏感个人信息处理时，如位置数据、行为数据以及测绘数据等，企业可能还需进行 数据保护影响评估（DPIA） ，以全面评估数据处理的合法性、必要性和风险性。 值得注意的是，由于欧盟目前尚未对中国作出充分性决定，因此中国企业在向欧盟外传输数据时，可能需要与相关方签订 标准合同条款（SCCs） 来确保数据传输的合法性。 总之，在跨境传输过程中，为降低数据泄露或不当使用的风险，企业需对敏感数据进行加密或匿名化处理。