汽车 OEM 需要解决方案，以最大程度地减少推出体验版和向研发工程师获取体验版诊断数据之间的时间。 随着车辆越来越自动化，软件的生命周期越来越短，数字反馈循环必须变得更快。 新技术可以使数据访问大众化，并为研发工程师提供对试驾诊断数据的准实时见解。 安全数据共享可以增强 OEM 和供应商之间的协作，进一步缩短开发周期。
此示例工作负载与遥测和批量试驾数据引入方案相关。 工作负载侧重于处理诊断数据的数据平台，以及用于可视化和报告的连接器。
体系结构
下载包含本文中所有示意图的 PowerPoint 文件。
数据流
Azure IoT 中心引入实时的原始遥测数据 (A) 并从车辆上传记录的数据文件 (B)。
IoT 中心将实时遥测 (A) 发送到 Azure Functions 应用，该应用将遥测解码为 JavaScript 对象表示法 (JSON) 并将其发布到 Azure 事件中心。
IoT 中心将记录的数据文件 (B) 发送到 Azure Blob 存储。 文件上传完成会触发 Functions 应用，该应用对数据进行解码并将解码后的文件以适合引入的逗号分隔值 (CSV) 格式写入 Blob 存储。
Azure 数据资源管理器将解码的 JSON 遥测数据从事件中心 (A) 引入到原始遥测表中，并从 Blob 存储中引入解码的 CSV 文件 (B)。
Azure 数据资源管理器使用
Update函数将 JSON 数据扩展为合适的行格式并扩充数据。 例如，该函数对位置数据进行聚类以支持地理空间分析。数据科学家和研发工程师使用 Kusto 查询语言 (KQL) 功能来生成他们存储为用户定义函数的分析用例。 KQL 函数包括聚合、时序分析、地理空间聚类分析、窗口化和机器学习 (ML) 插件。
Power BI 使用 Dynamic Query 通过用户定义的查询创建可视化效果。 Azure 数据资源管理器的 Grafana 数据源插件使用用户定义的查询进行准实时更新。
Azure 应用程序服务应用使用 Azure Maps 数据源呈现功能来可视化使用 GeoJSON 格式的用户定义查询结果。
Azure API 管理提供对车辆存储的原始数据文件的访问，以及管理第三方数据收集策略的配置 API。
Azure 数据资源管理器架构
Update()函数使用如下方法：mv-expand()，用于将存储在 JSON 结构中的复杂值扩展为具有单独信号的行。geo_point_to_h3cell()或geo_point_to_geohash()，用于将纬度和经度转换为 geohash 以进行地理空间分析。todouble()和tostring()，用于将从动态 JSON 对象中提取的值强制转换为适当的数据类型。
“车队元数据上一个已知值”视图将其他视图作为引入的一部分联接以提供上下文。 如果新的用例需要重新处理原始遥测数据，则历史车队元数据非常有用。
如有必要，“重复数据删除信号”具体化视图会使用
take_any()对信号进行重复数据删除。“信号元数据上一个已知值”具体化视图在时间戳上使用
arg_max()以进行实时报告。“下采样信号”具体化视图通过使用预定义的箱（例如每小时和每天）来聚合信号，以简化整个车队的报告。
像
DetectAnomaly()这样的存储插件函数会发现数据系列中的异常情况。 像 autocluster 这样的 ML 插件可以找到离散属性的常见模式。GetGeospatial()函数生成 GeoJSON 文件，其中包含按 geohash 分组的信号。
组件
以下关键技术实现此工作负载：
- Azure 数据资源管理器
- Azure IoT 中心
- Azure Blob 存储
- Azure 事件中心
- Azure Functions
- Microsoft 托管 Grafana
- Azure 应用程序服务
- Azure Maps
- Azure API 管理
- Power BI
备选方法
对于复杂的文件解码，Azure Batch 是一个很好的选择。 此方案涉及超过 300 兆字节的大量文件，这些文件需要基于文件版本或类型的不同解码算法。
- 将记录的数据文件上传到 Blob 存储会触发 Functions 应用来计划解码。
- Functions 应用会创建批处理作业，并考虑文件类型、大小和所需的解码算法。 应用从池中选择合适的虚拟机 (VM) 并启动作业。
- 作业完成后，Batch 会将生成的解码文件写回 Blob 存储。 此文件必须适合采用 Azure 数据资源管理器支持的格式直接引入。
- 将解码的信号文件上传到 Blob 存储会触发一个函数，该函数将数据引入到 Azure 数据资源管理器中。 此函数在必要时创建表和数据映射，并启动引入过程。
- Azure 数据资源管理器直接从 Blob 存储引入数据文件。
此方法具有以下优势：
- Azure Functions 和 Batch 池能够稳健高效地处理可缩放的数据处理任务。
- Batch 池提供有关处理统计信息、任务队列和批处理池运行状况的见解。 你可以可视化状态、检测问题并重新运行失败的任务。
- Azure Functions 和 Azure Batch 的组合支持 Docker 容器中的即插即用处理。
方案详细信息
汽车 OEM 使用大量原型和测试车队来测试和验证各种车辆功能。 测试过程成本高昂，因为需要真实的驾驶员和车辆参与，并且某些特定的实际道路测试场景必须多次通过。 集成测试对于评估复杂系统中电气、电子和机械组件之间的交互尤其重要。
为了验证车辆功能并分析异常和故障，必须从电子控制单元 (ECU)、计算机节点、控制器局域网 (CAN) 和以太网等车辆通信总线以及传感器捕获数千兆字节的诊断数据。 过去，车辆中的小型数据记录器服务器将诊断数据本地存储为主数据库 (MDF)、多媒体融合扩展 (MFX)、CSV 或 JSON 文件。 试驾完成后，服务器会将诊断数据上传到数据中心，数据中心对其进行处理并将其提供给研发工程师进行分析。 此过程可能需要数小时，有时数天。 最近的场景使用遥测引入模式，例如基于消息队列遥测传输 (MQTT) 的同步数据流，或准实时文件上传。
可能的用例
- 车辆管理会评估每个车辆在多个测试场景中的性能和收集的数据。
- 系统和组件验证使用收集到的车辆数据来验证车辆组件的行为是否在行程中处于操作范围内。
- 异常情况检测可实时定位传感器值相对于其典型基线模式的偏差模式。
- 根本原因分析使用 ML 插件（如聚类分析算法）来确定多个维度上值分布的变化。
- 预测性维护结合了多个数据源、扩充的位置数据和遥测，以预测组件故障时间。
- 可持续性评估通过驾驶员行为和能源消耗来评估车辆运行对环境的影响。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
- Azure 可用性区域是同一 Azure 区域中独特的物理位置。 可用性区域可以保护 Azure 数据资源管理器计算群集和数据不会在部分区域发生故障。
- 使用 Azure 数据资源管理器中的业务连续性和灾难恢复 (BCDR)，你的业务能够在发生中断时继续正常运转。
- 考虑在 Azure 数据资源管理器中使用后继数据库来分隔生产用例和非生产用例之间的计算资源。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
请务必了解汽车 OEM 与 Microsoft 之间的责任分工。 在车辆中，OEM 拥有整个堆栈，但随着数据迁移到云，一些责任也转让给了 Microsoft。 Azure 平台即服务 (PaaS) 在物理堆栈（包括操作系统）上提供内置安全性。 可以在基础结构安全组件的基础上应用以下功能。
- 用于网络安全的专用终结点。 有关详细信息，请参阅 Azure 数据资源管理器的专用终结点和允许通过专用终结点访问 Azure 事件中心命名空间。
- 静态加密和传输中加密。
- 使用 Microsoft Entra 标识和 Microsoft Entra 条件访问 策略的身份验证和访问控制。
- Azure 数据资源管理器的行级别安全性 (RLS)。
- 使用 Azure Policy 的基础结构治理。
- 使用 Microsoft Purview 的数据治理。
所有这些功能都有助于汽车 OEM 为其车辆遥测数据创建安全环境。 有关详细信息，请参阅 Azure 数据资源管理器中的安全性。
成本优化
成本优化着眼于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
此解决方案使用以下做法来帮助优化成本：
- 正确配置 Raw 和 Signals 表的热缓存和冷存储。 热数据缓存存储在 RAM 或 SSD 中，性能更佳。 但是，冷数据便宜 45 倍。 为用例设置适当的热缓存策略，例如 30 天。
- 在 Raw 和 Signals 表上设置保留策略。 确定信号数据何时不再相关（例如 365 天后），并相应地设置保留策略。
- 考虑哪些信号与分析相关。
- 查询信号上一个已知值、重复数据删除信号和下采样信号时，请使用具体化视图。 具体化视图消耗的资源比对每个查询执行源表聚合要少。
- 考虑实时数据分析需求。 为实时遥测表设置流式引入可以在引入和查询之间实现不到一秒的延迟，但代价是 CPU 周期成本更高。
性能效率
性能效率是工作负载高效缩放以满足用户需求的能力。 有关详细信息，请参阅性能效率要素概述。
- 如果记录的数据文件的数量和大小超过 1,000 个文件或每天 300 MB，请考虑使用 Azure Batch 进行解码。
- 考虑在引入后执行常见的计算和分析，并将其存储在其他表中。
部署此方案
要部署 Azure 数据资源管理器并引入 MDF 文件，可按照此分步教程操作，了解如何部署免费实例、分析 MDF 文件、引入和执行一些基本查询。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Frank Kaleck | 汽车数字架构师
- Mario Ortegon-Cabrera | 首席项目经理
- Henning Rauch | 首席项目经理
- Boris Scholl | 合伙人、首席架构师
其他参与者：
- Hans-Peter Bareiner | 云解决方案架构师
- Jason Bouska | 高级软件工程师
若要查看非公开领英个人资料，请登录领英。
后续步骤
- 将数据从事件中心引入 Azure 数据资源管理器
- 使用 IoT 中心上传文件
- 具体化视图
- 在 Grafana 中可视化 Azure 数据资源管理器中的数据
- 在 Power BI 中可视化 Azure 数据资源管理器中的数据
- 在 Microsoft Azure Maps 中为地图创建数据源