宝马集团和高通需要在自动驾驶/高级驾驶辅助系统 (AD/ADAS) 领域解决几个挑战,以使各种自动驾驶功能成熟。这包括使用配备最新传感器的测试车辆在广泛的不同交通场景和环境条件下收集数千公里的测试数据。这还涉及测试汽车感知其周围环境整体的数据质量。此外,这些示例还需要在一系列真实世界、道路场景和情况下对安全和驾驶功能进行验证和确认。为了应对这些挑战,宝马集团、高通和 AWS 专业服务部门合作开发了 AWS 上的多租户 AD/ADAS 解决方案,即所谓的下一代 ADAS 平台。该平台基于以下设计原则构建在 AWS 之上:- 云优先方法:使用灵活且可扩展的 AWS 云,通过 AWS 灵活的按需付费计费模式根据需要动态调整资源;
- IaC(基础设施即代码)蓝图和模块的可重用性:利用 AWS 开源项目自动驾驶数据框架 (ADDF) 和 AWS 部署框架 (ADF) 缩短开发周期;
- 自助服务:使用基于 UI 的门户,让软件工程师和其他最终用户能够轻松访问和进行用户管理;
- 协作:专为多租户和共享租户而设计,以促进多个公司和合作伙伴的数百个团队之间的合作;
- 全球 ADAS 平台范围:代码库能够部署在 AWS 中国和 AWS 商业分区中。
本文介绍了安全、灵活、可扩展且高度集成的下一代 ADAS 平台的架构。本博客首先从与 ADAS 平台交互的不同角色的角度,从高层次讨论了下一代 ADAS 平台。然后,我们从最终用户的角度描述了基于 UI 的 ADAS 工作负载环境创建过程。为了更深入地了解,我们将解释底层 ADAS 平台部署机制和架构细节。最后,我们将提供有关 ADAS 平台如何帮助加快事件驱动架构中 ADAS 相关工作负载的开发时间的见解。
解决方案概述 - 下一代 ADAS 平台上的 ADAS 工作负载生命周期宝马集团使用 ADAS 平台来管理 Neue Klasse 的高级驾驶辅助系统 (ADAS) 工作负载的验证和确认。在这篇博文中,ADAS 工作负载被定义为与现实世界数据采集、数据质量控制、自动数据标记、注释和引用相关的任何任务。它还包括数据分析和可视化、模拟、再处理和关键绩效指标 (KPI) 计算。下图概述了典型 ADAS 工作负载环境的端到端生命周期。它还展示了下一代 ADAS 平台支持的核心角色。图 1. ADAS 平台上 ADAS 工作负载环境的生命周期 — 从配置到退役BMW Group ADAS 应用程序所有者通过 UI 请求创建 ADAS 工作负载环境。这些 ADAS 工作负载环境称为“Realms”。Realm 是应用程序逻辑、人员、成本和安全设置的逻辑分组,由四个 AWS 账户组成(用于开发 (Dev)、集成测试 (Int)、生产 (Prod) 和 CICD)。只有管理员明确批准后才会创建 Realm。请求获得批准后,将自动创建 AWS 账户。然后为这些账户配置资源和控件,以实现安全性、身份访问管理、网络和预配置的 Git 存储库。它们还包括用于 ADAS 工作负载开发的 CI/CD 管道。成功创建和配置后,ADAS 应用程序所有者将管理对 Realm 的访问,并且可以根据明确定义的角色概念对应用程序开发团队进行入职培训,并根据每个用户进行细粒度的权限分配。BMW 集团 ADAS 应用程序开发人员现在可以访问他们配置的开发环境,此时,ADAS 验证开发工作可以开始了。用户可以访问预先部署的 Git 存储库和 CI/CD 管道。常见的 ADAS 工作负载包括数据提取、重新模拟和数据质量评估等。在下一步中,ADAS 应用程序开发人员将他们的 ADAS 验证应用程序集成到类似于 BMW 云数据中心 (CDH) 的数据网格应用程序结构中。在这个网格中,事件驱动的方法允许 ADAS 工作负载使用明确定义的模式相互通信和交换数据。一个示例 ADAS 工作负载是再处理即服务领域 (RaaS),它集成到事件驱动的数据网格 ADAS 应用程序空间中。BMW 集团 ADAS 应用程序开发人员可以监控其 ADAS 验证和验证工作负载的基础设施,如果出现任何问题,各种日志记录机制都可以随时提供帮助,提供快速一致的分析。BMW 集团财务运营经理和 ADAS 应用程序所有者会随着时间的推移监控领域的成本。一旦超过预定义的成本阈值,就会发出警报以避免意外发生成本。广泛的仪表板可以快速轻松地识别关键成本驱动因素和成本趋势。仪表板按自定义标签、AWS 帐户和每个领域汇总成本。如果不再需要某个领域,领域所有者可以触发其退役。调用的退役过程会执行多项检查,以帮助验证在自动退役之前是否备份了存储的数据和工件。下一节详细介绍了领域结构以及如何通过 UI 请求它。解决方案 - 在下一代 ADAS 平台上的领域中创建 ADAS 工作负载本节深入探讨了领域概念以及如何通过 UI 轻松请求领域。在下一代 ADAS 平台的背景下,下图显示了领域概念的概述,以及通过将每个领域集成到事件驱动的数据网格状结构中的总体编排来促进跨领域的通信:
图 2. 下一代 ADAS 平台中 Realm 的定义
一个 Dev AWS 账户,用于提供独立的开发阶段。一个 Int AWS 账户,用于提供独立的集成和测试阶段。一个 Prod AWS 账户,用于提供独立的生产阶段。一个工具链 (CI/CD) AWS 账户,用于管理其他 3 个 AWS 账户(Dev、Int 和 Prod)之间的代码传播。2. Realm 有一个所有者(ADAS 应用程序所有者),可以执行以下操作:b. 通过 UI 授予和撤销用户对预配置角色的分配来管理访问权限。a. Realm 类定义部署在四个 AWS 账户中的其他 AWS 资源。根据所选的 Realm 类,特定的预定义网络资源、ADAS 相关的 Git 存储库和 CI/CD 管道将部署在 Dev、Int 和 Prod AWS 账户中。b. Realm 所有者可以在创建 Realm 期间选择 Realm 类。Realm 类的一个示例是“数据提取”。4. Realm 完全集成到下一代 ADAS 平台中:a. Realm 使用 AWS Systems Manager (SSM) 参数来描述 Realm 在下一代 ADAS 平台中的上下文(租户、网络设置和其他元数据)。b. 根据特定 Realm 的个别要求,可提供定制的 VPC 配置和网络连接。c. Realm 自动集成到 ADAS 平台的集中成本和计费管理中。d. 它提供与 ADAS 平台身份访问管理系统的完全集成。e. 对于每个 Realm,都可以使用 AWS 安全服务进行自动设置和注册。f. Realm 的设置使其能够轻松集成到用于事件处理的 Overarching Orchestration 以及集中提供的日志记录和监控功能中。a. 由于下一代 ADAS 平台是多租户平台,因此一个 Realm 一次只能属于一个租户。系统允许租户内 Realm 通信,但禁止跨租户交换。图 3. ADAS 平台自助服务 UI 上的端到端 Realm 创建工作流
现在我们解释了 Realm 的概念和创建,让我们在下一章中向您展示用于提供所有基础设施以实现此工作流的部署机制。为了能够创建 Realm 并运行前面几节中概述的工作流,ADAS 平台 DevOps 团队首先需要使用 AWS Organizations 服务在空组织中部署下一代 ADAS 平台:在本节中,我们概述了初始 ADAS 平台部署和后续更新过程。下一代 ADAS 平台的起点是三个空的 AWS 组织:每个 AWS 组织都包含下一代 ADAS 平台的完整实例。Dev 和 Int AWS 组织专门用于下一代 ADAS 平台 DevOps 团队的 ADAS 平台开发和测试,而 Prod AWS 组织则用于为 ADAS 应用程序开发人员部署 ADAS 工作负载环境。此设置支持开发新的 ADAS 平台功能,而不会危及下一代 ADAS 平台的 Prod Org 实例的稳定性。下图显示了多 AWS 组织方法:图 4. 下一代 ADAS 平台多 AWS 组织方法
ADAS 平台使用 AWS Control Tower 设置初始 AWS 组织、基线安全功能和初始 AWS 账户。为了提供所有 ADAS 平台功能,ADAS 平台 DevOps 团队需要部署 AWS 账户,用于联网、IAM 访问管理、计费、成本控制、AWS 账户销售、CI/CD、安全、UI 以及日志记录和监控。总体而言,该系统在多个 AWS 区域的 14 个 AWS 账户上部署了 94 个独特的基于 CDK 和 CloudFormation 的 ADAS 平台级应用程序(平台级应用程序)。为了更轻松地完成此操作,使用了 Amazon 部署框架 (ADF)。ADF 可实现并帮助确保下一代 ADAS 平台的以下功能:- 跨区域和账户的所有平台级应用程序的通用构建说明(部署图)。
- 从一个阶段到下一个阶段的所有平台级应用程序的明确定义的代码传播过程。部署顺序定义为:从 Dev Org 到 Int Org 再到 Prod Org。
ADF 使用 AWS CodePipeline(一种完全托管的持续交付服务,可帮助自动化发布管道)基于 YAML 定义(称为部署图)自动生成管道。这种方法减轻了 ADAS 平台 DevOps 团队在 CI/CD 管道生成方面所有无差别的繁重工作。相反,ADAS 平台 DevOps 团队可以专注于编写高质量的代码和测试。下图显示了 ADF 在高层次上的工作原理。图 5. ADF 工作流 — 通过 AWS CodePipeline 自动生成的管道从代码存储库到完全部署的平台级应用程序
跨账户、多堆栈平台级应用程序的一个示例是下面显示的 CDK 应用程序“Account Vending AppSync API”。此特定的平台级应用程序部署 API 以使用基于事件的无服务器方法促进 AWS 账户的参数化创建。部署后,此 CDK 应用程序将提供用于 AWS 账户配置、更新和停用的 API。部署此 API 的起点是下面显示的 ADF 部署图:图 6. CDK 平台级应用程序“Account Vending AppSync API”的 ADF 部署图,其中细分了不同的部分。
此部署图包含 ADF 自动生成 AWS CodePipeline 所需的所有信息。在此特定示例中,YAML 文件定义了管道元数据、源提供程序、带有单元测试的构建步骤以及带有附加集成测试的部署目标。基于此信息,ADF 生成以下 AWS CodePipeline:图 7. 使用 AWS CodePipeline 为平台级应用程序“AppSync API Management”自动生成的管道,包括构建和测试阶段
源阶段提供来自引用的 AWS CodeCommit Git 存储库的代码。在此示例中,使用存储库“platform-appsync-api-management”的 dev 分支的内容。构建阶段运行存储库 buildspec.yaml 中定义的单元测试并创建构建工件。在我们的示例中,构建工件由“cdk synth”命令生成的 AWS CloudFormation 模板组成。3. DeployToDeploymentAccount-0:部署阶段执行将平台级应用程序部署到目标 AWS 账户的操作。集成测试对刚刚部署的账户销售 API 执行不同的调用,以验证它是否在所有端点上按预期工作。一旦创建、触发并成功执行了所有 ADF 自动生成的管道,所有平台级应用程序都将部署,并且下一代 ADAS 平台将完全正常运行,包括 UI。以下屏幕截图显示了应用程序部署管道的子集,其中总共有 120 个由 ADF 生成的部署管道。图 8. 使用 AWS CodePipeline 自动生成的所有管道的子集,它们是下一代 ADAS 平台的基础。
此时,下一代 ADAS 平台已完全部署,可供不同用户使用。ADAS 应用程序开发人员的下一步是什么 - 使用预配置的 ADAS 平台和 Realms 来帮助加快 ADAS 验证和确认工作负载的开发在部署下一代 ADAS 平台并创建所有所需的 Realms 后,ADAS 应用程序开发人员可以访问 AWS 服务和必要的工具来支持功能验证和批准。每个 Realm 都提供了关键的加速器,使 BMW 集团 ADAS 应用程序开发人员能够更快地行动。默认情况下,每个 Realm 都预先配置了 CI/CD 服务,这些服务可用于以最少的努力在 Realm 中开发、构建和部署 IaC 应用程序。另一个关键的加速器是一个集中式 IaC 存储库,其中包含基于开源项目自动驾驶数据框架 (ADDF) 和行业数据框架 (IDF) 的可重复使用的 IaC 代码模块集合。ADDF 和 IDF 提供了可立即运行的示例,这些示例实现了 EKS 集群等常见服务模式。ADAS 平台上的每个 Realm 都能够轻松集成到定制的总体编排中,从而促进 Realm 之间的标准化发布-订阅通信。这篇博文概述了下一代 ADAS 平台上 ADAS 工作负载环境的生命周期,该平台由宝马与高通和 AWS 合作构建。它通过平台的定制 UI 展示了 ADAS Realm 配置过程。然后,该博客描述了通过 ADF 部署可扩展、安全、灵活且高度集成的下一代 ADAS 平台的端到端过程。最后,它解释了如何使用 Realm 的预配置组件显著加快 ADAS 验证和确认的开发过程。在这个数据网格环境中,这是通过使用 IDF 模块的标准化部署过程和跨领域通信的事件驱动方法实现的。References
Develop and deploy a customized workflow using Autonomous Driving Data Framework (ADDF) on AWS
Amazon Deployment Framework
BMW Cloud Data Hub: A reference implementation of the modern data architecture on AWS
Scaling Automated Driving data processing and data management with BMW Group on AWS
Developing a Platform for Software-defined Vehicles with Continental Automotive Edge (CAEdge)