汽車測試車隊的資料分析

汽車原始設備製造商 (OEM) 需要解決方案，以將試用產品之間的時間降到最低，並將試用產品診斷資料傳遞給研&發工程師。 隨著車輛越來越自動化，軟體開發生命週期變得較短，需要更快的數位回饋循環。 新技術可將資料存取大眾化，並提供 R&D 工程師近即時的試用產品診斷資料深入解析。 使用資料科學和資料工程的 Copilot 進行資料分析，以進一步縮短深入解析的時間。 安全的資料共用可以強化 OEM 與供應商之間的共同作業，並減少開發周期時間。

本文中的指引適用於遙測情境和批次試用產品資料擷取情境。 此架構著重於處理診斷資料和資料視覺效果和資料報告之連接器的資料平台。

架構

下載PowerPoint 檔案 (其中包含本文中所有圖表)。

資料流程

下列資料流程會對應至以上圖表：

1. 資料擷取裝置會連線到車輛網路，並收集高解析度車輛訊號資料和影片。 (1a) 裝置會發佈即時遙測訊息或 (1b) 會使用 MQTT 用戶端，要求將記錄的資料檔案上傳至 Azure 事件方格 MQTT 代理功能。 這項功能會使用宣告檢查模式。

2. (2a) 事件方格會將即時車輛訊號資料路由傳送至 Azure 功能應用程式。 此應用程式會將車輛訊號解碼為 JavaScript 物件表示法 (JSON) 格式，並將其張貼至事件串流。

   (2b) 事件方格會協調從裝置用戶端上傳至 Lakehouse 的檔案。 完成的檔案上傳會觸發解碼資料的管線，並會將解碼的檔案以適合擷取的格式，例如 parquet 或 CSV 寫入 OneLine。

3. (3a) 事件串流會路由傳送解碼的 JSON 車輛訊號，以在 Eventhouse 中擷取。

   (3b) 資料管線會觸發從 Lakehouse 擷取解碼的檔案。

4. Eventhouse 會使用更新原則 來擴充資料，並將 JSON 資料擴充為適當的資料列格式，例如位置資料可能會叢集以配合地理空間分析。 每次擷取新列時，即時分析引擎都會叫用相關的Update()函式。

5. 資料工程師和資料科學家會使用 Kusto 查詢語言 (KQL) 來建置分析使用案例。 使用者會將常用案例儲存為可共用的使用者定義函式。 工程師會使用內建的 KQL 函式，例如彙總、時間序列分析、地理空間叢集、視窗化，以及具有 Copilot 支援的機器學習外掛程式。

6. R&D 工程師和資料科學家會使用 notebooks 來分析資料，並建置測試和驗證使用案例。

   1. R&D 工程師會使用KQL 查詢集 和即時智慧的 Copilot來執行互動式資料分析。

   2. 資料工程師和資料科學家會使用 notebooks 來儲存及共用其分析過程。 使用 notebooks 時，工程師可以使用 Azure Spark 來執行分析，並使用 Git 來管理 notebook 程式碼。 使用者可以利用資料科學和資料工程的 Copilot，使用內容相關的程式碼建議來支援其工作流程。

7. R&D 工程師和資料科學家可以使用 Power BI 搭配動態查詢或即時分析儀表板，來建立視覺效果以與商務使用者共用。 這些視覺效果會叫用使用者定義的函式，以方便維護。

8. 工程師也可以將更多工具連線至 Microsoft Fabric。 例如，他們可以將 Azure 受控 Grafana 連線到 Eventhouse，或建立直接查詢 Eventhouse 的 Web 應用程式。

9. 資料工程師和 R&D 工程式會使用 Data Activator 來建立 reflex 項目，以監視狀態和觸發動作，例如觸發商務整合的 Power Automate 流程。 例如，如果裝置的健全狀況降低，Data Activator 可以通知 Teams 管道。

10. 資料收集器設定可讓工程師變更資料擷取裝置的資料收集原則。 Azure API 管理抽象化並保護合作夥伴設定 API，及提供可檢視性。

KQL 資料庫結構描述

當您設計表格結構描述時，請考慮fact表格和dimension表格之間的差異。 遙測是fact表，因為車輛訊號會逐漸以串流方式附加，或做為完整錄製的一部分，而且遙測不會變更。 您可以將車隊中繼資料分類為緩慢更新的fact表格。

車輛遙測會落在原始表格中。 您可以使用下列訊息處理概念來組織資料以供分析和報告：

• 使用下列方法建立更新原則，將 JSON 遙測檔案展開至個別車輛訊號記錄：

  • mv-expand() 將 JSON 結構中儲存的複雜值展開成具有個別訊號的資料列。
  • geo_point_to_h3cell()或geo_point_to_geohash()將緯度和經度轉換為地理空間分析的地理雜湊。
  • todouble()和tostring()會將從動態 JSON 物件擷取的值轉換成適當的資料類型。
  • lookup使用維度表中的值來擴充記錄。

• 使用唯一索引鍵和時間戳記上的彙總函數，建立take_any()具體化檢視。 這個具體化檢視會去除訊號的重複內容。

• 使用時間戳記上的彙總函數，建立最後已知值的訊號arg_max()具體化檢視。 這個具體化檢視會提供車輛的最新狀態。

• 使用具有時間間隔的摘要運算子，例如每小時和每天，建立下取樣的訊號具體化檢視。 這個具體化檢視會彙總訊號，並簡化整個車隊的報告。

• 建立提供異常偵測或根本原因分析的使用者定義函式。

  • 使用時間序列函式進行異常偵測和預測，以偵測潛在問題並預測失敗。

  • 使用掃描運算子從數資料掃描、比對和建置序列。 工程師可以使用scan運算子來偵測序列。 例如，如果發生特定事件，則後續事件必須在特定時間內發生。

  • 使用像是 autocluster 的機器學習外掛程式來尋找離散屬性的常見模式。

• 透過使用者定義的函式執行地理空間分析。 使用地理空間分析函式，將座標轉換成適當的網格系統，並針對數資料執行彙總。

• 建立車隊中繼資料表 ，以在車輛中繼資料和設定上儲存變更。 建立車隊中繼資料最後一個已知值具體化檢視，以根據上次修改的資料行儲存車輛車隊的最新狀態。

元件

下列關鍵技術會實作此工作負載。 對於架構中的每個元件，請使用架構完善的架構中可用的相關服務指南。 關於更多資訊，請參閱架構完善的架構服務指南。

• Fabric Real-Time Intelligence 可讓您擷取移動中車輛遙測的深入解析和視覺效果。 您可以使用事件串流和時間序列 KQL 資料庫來儲存和分析資料，並使用反射來回應事件。

• Data Activator 是一種無程式碼工具，可讓您在資料中的模式或條件變更時，自動執行動作。

• 事件方格是支援 MQTT 通訊協定的高度可擴增、完全受控發佈/訂閱訊息分發服務。 車輛可以使用事件方格來發佈和訂閱主題，例如可以發佈遙測並訂閱命令和控制訊息。

• Azure 事件中樞 是一個即時資料串流平台，非常適合每秒串流數百萬個車輛事件，且低延遲。

• Functions 是一種無伺服器解決方案，藉由使用您選擇的語言，透過事件導向觸發程序和繫結，大規模簡化車輛遙測事件。

• Azure 受控 Grafana是以 Grafana Labs 的軟體為基礎的資料視覺效果平台。 Microsoft 管理和支援 Azure 受控 Grafana。

• Azure 應用程式服務可讓您建置及託管 Web 應用程式、行動裝置後端，和 RESTful API，以存取儲存在 Fabric 中的車輛遙測資料。 此方法可簡化取用。

• API 管理是適用於 API 的混合多雲端管理平台。

替代項目

您也可以使用下列 Azure 服務來執行此架構：

• Azure Blob 儲存體儲存大量非結構化資料，例如來自車輛的錄製、記錄和影片。 它會取代 OneLake 儲存體。

• Azure 資料總管是快速、完全受控的資料分析服務，可即時進行分析。 它會取代 Fabric Real-Time Intelligence KQL 資料庫。

• Azure Batch 是可用來解碼複雜檔案的替代方案。 此情境涉及大量檔案，每個檔案都超過 300 MB。 檔案需要根據檔案版本或檔案類型的不同解碼演算法。 您可以使用 Fabric 或使用 Blob 儲存體和 Azure 資料總管來實作下列方法。

1. 使用者或錄製裝置會將錄製的資料檔案上傳至 Lakehouse。 上傳完成時，它會觸發排程解碼的 Functions 應用程式。

2. 排程器會啟動 Functions 應用程式，根據檔案類型、檔案大小和必要的解碼演算法來建立批次工作。 應用程式會從集區選取大小適當的虛擬機器，並啟動工作。

3. Batch 會在工作完成時，將產生的解碼檔案寫回 Lakehouse。 此檔案必須是 Eventhouse 支援的格式以適合直接擷取。

4. Lakehouse 會觸發函式，在檔案寫入時將資料內嵌至 Eventhouse。 此函式會視需要建立表格和資料對應，並啟動擷取過程。

5. KQL 資料庫會從 Lakehouse 擷取資料檔案。

此方法具有下列優點：

• 函式和 Batch 集區可以健全且有效率地處理可縮放的資料處理工作。

• Batch 集區提供處理數統計資料、工作佇列，和批次集區健全狀況的深入解析。 您可以將狀態視覺效果化、偵測問題，以及重新執行失敗的工作。

• Functions 和 Batch 的組合支援 Docker 容器中的隨插即用處理。

• 您可以使用現成虛擬機器在離峰期間處理檔案。 這種方法可節省成本。

案例詳細資料

汽車 OEM 使用原型的大型車隊和測試車輛來測試和驗證數個車輛功能。 測試程序很昂貴，因為它們需要真正的司機和車輛，且必須多次通過特定的真實世界道路測試情境。 整合測試對於評估複雜系統中電力、電子和機械元件之間的互動特別重要。

若要驗證車輛功能並分析異常和故障，您必須從電子控制單位 (ECU)、電腦節點、控制器區域網路 (CAN) 和乙太網路等車輛通訊匯流排，以及感測器擷取診斷資料的拍位元組。

過去，車輛中的小型資料記錄器伺服器會將診斷資料儲存為測量資料格式 (MDF)、多媒體融合擴充 (MFX)、CSV 或 JSON 檔案。 試用產品完成後，伺服器會將診斷資料上傳至資料中心，該資料中心會進行處理，並將其傳給 R&D 工程師進行分析。 此過程可能需要數小時或有時數天的時間。 較新的情境會使用遙測擷取模式，例如訊息佇列遙測傳輸 (MQTT) 型同步資料串流或近即時的檔案上傳。

潛在使用案例

• 車輛管理會評估每個車輛在多個測試情境中的效能和收集到的資料

• 系統和元件驗證會使用收集的車輛資料來驗證車輛元件的行為落在跨行程的作業界限內。

• 異常偵測會即時找出感測器值與其一般基準模式相較之下的偏差模式。

• 根本原因分析會使用機器學習外掛程式，例如叢集演算法，來識別多個維度上值分佈的變化。

• 預測性維護結合了多個資料來源、擴充的位置資料和車輛訊號，以預測元件故障的時間。

• 永續性評估會使用駕駛行為和能量消耗來評估車輛作業的環境影響。

• 賽車以了解和改善車輛在賽前、期間和賽後的表現。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。

可靠性

可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

• Azure 可用性區域是相同 Azure 區域內的唯一的實體位置。 可用性區域可以保護 Azure 資料總管計算叢集和資料免於部分區域失敗。

• Azure 資料總管中的企業持續性和災害復原可讓您的企業在發生中斷時繼續營運。

• 追蹤程式資料庫會分隔生產與非生產使用案例之間的計算資源。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。

了解汽車 OEM 和 Microsoft 之間的責任劃分非常重要。 在車輛中，OEM 擁有整個堆疊，但隨著資料移動到雲端，一些責任會轉移到 Microsoft。 Azure 平台即服務 (PaaS) 在實體堆疊上提供內建安全性，包括作業系統。

• 使用 Azure 原則來套用安全性護欄。

• 檢閱 Fabric 的治理概觀和指引。

• 使用私人端點為所有服務提供網路安全性。

  • 使用 Azure 資料總管的私人端點。

  • 允許透過專用端點存取事件中心命名空間。

• 加密待用資料和運輸中資料。

• 使用 Microsoft Entra 身分識別和 Microsoft Entra 條件式存取原則。

• 針對 KQL 資料庫和 Azure 資料總管使用資料列層級安全性 (RLS)。

• 當您實作具有 KQL 資料庫存取權的中介應用程式時，請使用 restrict 陳述式。 此設定會建立邏輯模型，以限制使用者存取資料。

所有這些功能都可協助汽車 OEM 為其車輛遙測資料建立安全的環境。 如需詳細資訊，請參閱 Fabric 中的安全性。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

此解決方案會使用下列做法來協助將成本最佳化：

• 正確設定原始和訊號表格的經常性快取和冷儲存體。 經常性資料快取會儲存在 RAM 或 SSD 中，並提供改善的效能。 不過，冷資料便宜 45 倍。 設定適合使用案例的經常性快取原則，例如 30 天。

• 在原始表格和訊號表格上設定保留原則。 決定訊號資料何時不再相關，例如 365 天後，並相應設定保留原則。

• 請考慮哪些訊號與分析有關。

• 當您查詢最後已知值的訊號、去除重複內容的訊號，以及下取樣的訊號時，請使用具體化檢視。 具體化檢視會耗用比在每個查詢上執行來源表格彙總更少的資源。

• 請考慮您的即時資料分析需求。 設定即時遙測表格的串流擷取，以提供擷取和查詢之間少於一秒的延遲。 這種方法會增加 CPU 週期和成本。

效能效益

效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 有關詳細資訊，請參閱效能效率的設計審核清單。

• 如果記錄的資料檔案數目和大小超過 1,000 個檔案或每天 300 MB，請考慮使用 Batch 來執行解碼。

• 請考慮在擷取並將其儲存在額外表格之後，執行常見的計算和分析。

• 使用 KQL 查詢最佳做法以提高查詢執行速度。

• 使用where子句來定義時間範圍，以減少查詢的資料量。 如果您常見的搜尋準則不是以時間為基礎，請考慮變更訊號表格的資料分割原則，例如，如果您是否透過錄製識別碼和訊號名稱來進行篩選。 當 KQL 資料庫展開為包含數十億或數萬億筆記錄時，適當的資料篩選就變得很重要，特別是考慮到使用中的分割原則。

部署此案例

使用逐步教學課程來部署此情境。 本指南將說明如何部署免費執行個體、剖析 MDF 檔案、擷取資料，以及執行數個基本查詢。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

• Boris Scholl | 首席架構師合作夥伴
• Frank Kaleck | 汽車產業顧問
• Henning Rauch | 首席專案經理
• Mario Ortegon-Cabrera | 首席專案經理

其他投稿人：

• Devang Shah | 首席專案經理
• Hans-Peter Bareiner | 雲端解決方案架構師
• Jason Bouska | 資深軟體工程師

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步

• 事件方格中的 MQTT 代理功能
• 將 KQL 資料庫目標新增到事件串流
• 從 OneLake 取得數據
• 具體化檢視
• 建立即時儀表板
• 從即時儀表板建立 Data Activator 警報
• Power BI 報表
• 在 Grafana 中從 Azure 資料總管將資料視覺化
• 汽車訊息傳遞、資料和分析參考架構

相關資源

• 軟體定義的車輛 DevOps 工具鏈
• 自駕車操作設計指南
• 宣告檢查模式