汽車傳訊、數據分析參考架構

此參考架構旨在支援汽車 OEM 和行動提供者，以開發進階連線車輛應用程式和數位服務。 其目標是提供可靠且有效率的傳訊、數據和分析基礎結構。 此架構包含訊息處理、命令處理和狀態儲存功能，以利透過受控 API 整合各種服務。 它也描述數據和分析解決方案，可確保資料儲存和輔助功能以可調整且安全的方式，與更廣泛的行動生態系統進行數位工程和數據共用。

架構

高階架構圖表顯示汽車傳訊、數據分析解決方案的主要邏輯區塊和服務。 您可以在下列各節中找到進一步的詳細數據。

• 車輛包含裝置的集合。 其中有些裝置是 軟體定義，而且可以執行從雲端管理的軟體工作負載。 車輛會收集和處理各種不同的數據，從電子機械裝置的感測器資訊，例如電池管理系統到軟體記錄檔。
• 車輛 傳訊服務 會管理車輛的通訊。 負責處理訊息、使用工作流程執行命令，以及調解車輛、使用者和裝置管理後端。 它還會追蹤車輛、裝置和憑證註冊和布建。
• 車輛和裝置管理後端是 OEM 系統，可追蹤車輛設定從工廠到維修和維護。
• 操作員具有 IT 和作業 ，以確保車輛和後端的可用性和效能。
• 數據分析服務會提供資料儲存空間，並啟用所有用戶的處理和分析。 其會將數據轉換成深入解析，以推動更好的商務決策。
• 車輛製造商提供 數位服務 作為價值增加給終端客戶，從隨附應用程式到維修和維護應用程式。
• 數個數位服務需要 業務整合 至後端系統，例如轉銷商管理（DMS）、客戶關係管理（CRM）或企業資源規劃（ERP）系統。
• 同意管理後端是客戶管理的一部分，並根據地理國家/地區立法追蹤數據收集的用戶授權。
• 從車輛收集的數據是數位工程流程的輸入，目標是使用分析和機器學習來持續改善產品。
• 智慧 行動生態系統 可以訂閱及取用即時遙測，以及匯總的深入解析，以提供更多產品和服務。

Microsoft 是 Eclipse 軟體定義車輛工作組的成員，這是使用車輛軟體平臺 開放原始碼 進行開放共同作業的論壇。

資料流程

架構會使用 發行者/訂閱者 傳訊模式來將車輛與服務分離。

車輛到雲端訊息

雲端數據流的 車輛 可用來處理來自車輛的遙測數據。 遙測數據可以定期傳送（車輛狀態、從車輛感測器收集）或根據事件（錯誤狀況觸發程式、對使用者動作的反應）。

1. 車輛會根據使用管理 API 的所選選項，為客戶設定車輛。 組態包含：
   1. 為車輛和裝置布建 資訊。
   2. 以市場和商務考慮為基礎的初始車輛 數據收集 組態。
   3. 根據車輛選項和使用者接受，儲存體 初始使用者同意設定。
2. 車輛會透過消息佇列遙測傳輸 （MQTT） 用戶端，將遙測和事件訊息發佈至車輛傳訊服務中 Azure 事件方格 的 MQTT 訊息代理程式功能。
3. 事件方格會根據主題和訊息屬性，將訊息路由傳送至不同的訂閱者。
   1. 不需要立即處理（例如分析訊息）的低優先順序訊息會使用事件中樞實例進行緩衝處理，直接路由傳送至記憶體。
   2. 需要立即處理的高優先順序訊息（例如，必須在使用者面向應用程式中可視化的狀態變更）會使用事件中樞實例來路由傳送至 Azure 函式以進行緩衝處理。
4. 低優先順序訊息會使用事件擷取直接儲存在 Data Lake 中。 這些訊息可以使用 批次譯碼和處理 ，以獲得最佳成本。
5. 高優先順序訊息會使用 Azure 函式來處理。 函式會從 裝置登錄 讀取車輛、裝置和使用者同意設定，並執行下列步驟：
   1. 確認車輛和裝置已註冊且使用中。
   2. 確認使用者已同意訊息主題。
   3. 譯碼並擴充承載。
   4. 新增更多路由資訊。
6. 數據分析解決方案中的即時遙測事件中樞會收到已譯碼的訊息。 Azure 數據總 管會使用 串流擷取 來處理和儲存訊息的接收。
7. 數位服務層會接收已譯碼的訊息。 服務匯流排 會針對車輛狀態的重要變更/事件，向應用程式提供通知。 Azure 數據總 管提供車輛的最後已知狀態和短期歷程記錄。

雲端到車輛訊息

雲端 到車輛 數據流通常用來從數位服務在車輛中執行遠端命令。 這些命令包括使用案例，例如鎖定/解除鎖定門、氣候控制（設定慣用的機艙溫度）或設定變更。 成功的執行取決於車輛狀態，可能需要一些時間才能完成。

根據車輛功能和動作類型而定，命令執行有多種可能的方法。 我們涵蓋兩種變化：

• 將雲端導向至不需要使用者同意檢查且具有可預測的回應時間的裝置訊息 （A ）。 這涵蓋個別和多輛車的訊息。 範例包括天氣通知。
• 使用車輛狀態判斷成功並要求使用者同意的車輛命令 （B ）。 傳訊解決方案必須具有命令工作流程邏輯，以檢查使用者同意、追蹤命令執行狀態，並在完成時通知數字服務。

下列從隨附應用程式數位服務發出的數據流使用者命令作為範例。

直接訊息會以最小躍點量執行，以獲得最佳效能 （A）：

1. 隨附應用程式是可發佈訊息至 事件方格的已驗證服務。
2. 事件方格 會檢查隨附 App Service 的授權，以判斷它是否可以將訊息傳送至提供的主題。
3. 隨附應用程式會訂閱來自特定車輛/命令組合的回應。

當車輛狀態相依命令需要使用者同意 時 （B）：

1. 車輛擁有者/使用者同意對數位服務執行命令和控制功能（在此範例中為隨附應用程式）。 當使用者下載/啟動應用程式，而 OEM 會啟動其帳戶時，通常會完成此動作。 它會觸發車輛上的設定變更，以訂閱 MQTT 訊息代理程式中相關聯的命令主題。
2. 隨附 應用程式 會使用 命令和控制受控 API 來要求執行遠端命令。
   1. 命令執行可能會有更多的參數來設定選項，例如逾時、儲存和轉寄選項等。
   2. 命令邏輯會決定如何根據主題和其他屬性來處理命令。
   3. 工作流程邏輯會建立狀態以追蹤執行的狀態
3. 命令 工作流程邏輯 會檢查使用者同意資訊，以判斷是否可以執行訊息。
4. 命令工作流程邏輯會使用 命令和參數值，將訊息發佈至 事件方格 。
5. 車輛 中的傳訊模組 會訂閱命令主題並接收通知。 它會將命令路由傳送至正確的工作負載。
6. 傳訊模組會監視工作負載是否完成（或錯誤）。 工作負載負責命令的（實體）執行。
7. 傳訊模組會將命令狀態報告發佈至 事件方格。
8. 工作流程 模組 已訂閱命令狀態更新，並更新命令執行的內部狀態。
9. 命令執行完成後，服務應用程式會透過命令和控制 API 接收執行結果。

車輛和裝置佈建

此數據流涵蓋向車輛傳訊服務註冊及布建車輛和裝置的程式。 此程式通常會起始為車輛製造的一部分。

1. 工廠系統委託車輛設備到所需的建設狀態。 它可以包含韌體和軟體初始安裝和設定。 在此程式中，處理站系統會取得並寫入從公鑰基礎結構提供者建立的裝置憑證。
2. 工廠系統會使用車輛和裝置布建 API 來註冊車輛和裝置。
3. 處理站系統會 觸發裝置布建用戶端 ，以連線到 裝置註冊 並布建裝置。 裝置會擷取 MQTT 訊息代理程式的連接資訊。
4. 裝置 註冊 應用程式會使用 MQTT 訊息代理程式建立裝置身分識別。
5. 處理站系統會觸發裝置，第一次建立與 MQTT 訊息代理程式的連線。
   1. MQTT 訊息代理程式會使用 CA 跟證書 來驗證裝置，並擷取客戶端資訊。
6. MQTT 訊息代理程式會使用本機登錄來管理允許主題的授權。
7. 針對更換元件，OEM 經銷商系統 可以觸發新裝置的註冊。

注意

處理站系統通常是內部部署，且沒有直接連線到雲端。

資料分析

此數據流涵蓋車輛數據的分析。 您可以使用工廠或車間操作員等其他數據源來擴充和提供車輛數據的內容。

1. 車輛 傳訊服務 層提供從雙向通訊到車輛的遙測、事件、命令和組態訊息。
2. IT 和作業層提供車輛上執行的軟體和相關雲端服務的相關信息。
3. 數個管線會將數據處理成更精簡的狀態
   • 從未經處理的數據到擴充和重複數據刪除的車輛數據。
   • 車輛數據匯總、關鍵效能指標和深入解析。
   • 為機器學習產生定型數據。
4. 不同的應用程式會取用精簡和匯總的數據。
   • 使用 Power BI 的視覺效果。
   • 使用 Logic Apps 與 Dataverse 整合的商務整合工作流程。
5. ML Studio 之類的工具會取用產生的定型數據，以產生 ML 模型。

延展性

聯網車輛和數據解決方案可以調整為數百萬輛汽車和數千項服務。 建議使用 部署戳記模式 來達到延展性和彈性。

每個 車輛傳訊縮放單位 都支援已定義的車輛母體擴展（例如，特定地理區域中的車輛，依模型年份分割）。 應用程式 縮放單位 是用來調整需要傳送或接收訊息給車輛的服務。 通用服務可從任何縮放單位存取，並提供應用程式和裝置的裝置管理和訂用帳戶服務。

1. 應用程式 縮放單位 會將應用程式訂閱至感興趣的訊息。 一般服務會處理車輛傳訊縮放單位元件的訂用帳戶。
2. 車輛會 使用裝置管理服務 來探索其指派給車輛傳訊縮放單位。
3. 如有必要，車輛會使用 車輛和裝置 布建工作流程進行布建。
4. 車輛會將訊息發佈至 MQTT 訊息代理程式。
5. 事件方格 會使用訂用帳戶資訊來路由傳送訊息。
   1. 對於不需要處理和宣告檢查的訊息，它會路由傳送至對應應用程式縮放單位上的輸入中樞。
   2. 需要處理的訊息會路由傳送至 D2C 處理邏輯 以進行譯碼和授權（使用者同意）。
6. 應用程式會從其 應用程式輸入 事件中樞實例取用事件。
7. 應用程式會發佈車輛的訊息。
   1. 不需要更多處理的訊息會發佈至 MQTT 訊息代理程式。
   2. 需要更多處理、工作流程控制和授權的訊息會透過事件中樞實例路由傳送至相關的 C2D 處理邏輯 。

元件

此參考架構參考下列 Azure 元件。

連線性

• Azure 事件方格 允許透過 MQTT v5 的裝置上線、AuthN/Z 和 pub-sub。
• Azure Functions 會處理車輛訊息。 它也可以用來實作需要短期執行的管理 API。
• 當受控 API 背後的功能是由部署為容器化應用程式的複雜工作負載所組成時，Azure Kubernetes Service （AKS） 是替代方案。
• Azure Cosmos DB 會儲存車輛、裝置和使用者同意設定。
• Azure API 管理 為現有的後端服務提供受控 API 閘道，例如車輛生命週期管理（包括 OTA）和使用者同意管理。
• Azure Batch 會有效率地執行大量計算密集型工作，例如車輛通訊追蹤擷取。

資料與分析

• Azure 事件中樞 可讓您處理和擷取大量的遙測數據。
• Azure 數據總 管提供以時間序列為基礎的車輛遙測數據的探索、策展和分析。
• Azure Blob 儲存體 儲存大型檔（例如影片和可追蹤）和策劃的車輛數據。
• Azure Databricks 提供一組工具來大規模維護企業級數據解決方案。 大量車輛數據的長時間執行作業所需。

後端整合

• Azure Logic Apps 會根據車輛數據執行商務整合的自動化工作流程。
• Azure App 服務 提供使用者面向的 Web 應用程式和行動後端，例如隨附應用程式。
• Azure Cache for Redis 提供使用者面向應用程式經常使用的記憶體內部快取數據。
• Azure 服務匯流排 提供將車輛連線與數位服務和業務整合分離的代理程式。

替代項目

要實作訊息處理和Managed API的正確計算類型選擇，取決於許多因素。 使用 [選擇 Azure 計算服務指南] 選取正確的服務 。

範例：

• 適用於事件驅動、短期程式的 Azure Functions ，例如遙測擷取。
• 適用於高效能運算工作的 Azure Batch ，例如譯碼大型 CAN 追蹤/視訊檔案
• 適用於受控、完整複雜邏輯的 Azure Kubernetes Service ，例如命令和控制工作流程管理。

作為事件型數據共用的替代方案，如果目標是在數據湖層級執行批次同步處理，也可以使用 Azure Data Share 。

案例詳細資料

汽車 OEM 正經歷著重大轉型，因為它們從生產固定產品轉向提供連接、軟體定義的車輛。 車輛提供各種功能，例如無線更新、遠端診斷和個人化用戶體驗。 這項轉換可讓 OEM 根據實時數據和深入解析持續改善其產品，同時擴充其商業模式，以包含新的服務和收入來源。

此參考架構可讓汽車製造商和行動提供者：

• 使用意見反應數據作為數位工程程式的一部分，以推動產品持續改善、主動解決問題的根本原因，並創造新的客戶價值。
• 提供新的 數位產品和服務 ，並將業務 與企業資源規劃（ERP）和客戶關係管理（CRM）等後端系統整合，實現業務整合 。
• 使用更廣泛的 智慧行動生態系統，安全地共享數據，並解決使用者同意的國家/地區特定需求。
• 與用於車輛生命週期管理和同意管理的後端系統整合，可簡化使用軟體定義車輛DevOps工具鏈來部署和管理連線車輛解決方案。
• 大規模儲存 並提供車輛和分析的計算。
• 以符合成本效益的方式管理 數百萬部裝置的車輛連線 能力。

潛在的使用案例

OEM 汽車使用案例 是關於增強車輛效能、安全性和用戶體驗。

• 持續改善產品：藉由分析實時數據並遠端套用更新，來增強車輛效能。
• 工程測試車隊驗證：藉由收集和分析來自測試車隊的數據，確保車輛安全性和可靠性。
• 隨附應用程式與使用者入口網站：透過個人化應用程式和入口網站啟用遠端車輛存取和控制。
• 主動式修復和維護：根據數據驅動見解預測和排程車輛維護。

更廣泛的生態系統使用案例擴展 了聯網車輛應用程式，以改善整個交通格局中的車隊運營、保險、行銷和路邊援助。

• 連線 商業機隊營運：透過即時監視和數據驅動決策來優化車隊管理。
• 數字車輛保險：根據駕駛行為自定義保險保費，並提供立即事故報告。
• 以位置為基礎的營銷：根據其位置和喜好設定，將目標行銷活動傳遞給司機。
• 道路協助：使用車輛位置和診斷數據，為需要司機提供即時支持和協助。

考量

這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。

可靠性

可靠性可確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性要素概觀。

• 請考慮水平調整以增加可靠性。
• 使用縮放單位來隔離具有不同法規的地理區域。
• 自動調整和保留實例：根據需求動態調整計算資源，並使用預先配置的實例將成本優化。
• 異地備援：跨多個地理位置複寫數據，以進行容錯和災害復原。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性要素概觀。

• 保護車輛連線：請參閱憑證管理一節，以瞭解如何使用 X.509 憑證來建立安全的車輛通訊。

成本最佳化

成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素概觀。

• 每輛車的成本考慮：通訊成本應該取決於所提供的數位服務數目。 根據作業成本計算數位服務的 RoI。
• 根據訊息流量建立成本分析的做法。 隨著增加更多服務，連線 車輛交通往往隨著時間增加而增加。
• 考慮網路和行動成本
  • 使用 MQTT 主題別名來減少流量。
  • 使用有效率的方法來編碼和壓縮承載訊息。
• 流量處理
  • 訊息優先順序：車輛通常會重複使用模式，以建立每日/每周需求尖峰。 使用訊息屬性來延遲處理非關鍵性或分析訊息，以平滑負載並優化資源使用量。
  • 根據需求自動調整。
• 請考慮數據應該儲存在熱/暖/冷的時間長度。
• 請考慮使用保留實例來將成本優化。

卓越營運

卓越營運涵蓋部署應用程式的作業程式，並讓它在生產環境中執行。 如需詳細資訊，請參閱 營運卓越支柱概觀。

• 請考慮監視車輛軟體（記錄/計量/追蹤）、傳訊服務、數據分析服務和相關後端服務，作為整合IT作業的一部分。

效能效益

效能效率是工作負載調整的能力，以符合使用者以有效率的方式滿足其需求。 如需詳細資訊，請參閱 效能效率要素概觀。

• 請考慮針對規模超過50,000部裝置的解決方案使用 縮放概念 ，特別是如果需要多個地理區域。
• 仔細考慮擷取數據的最佳方式（傳訊、串流或批處理）。
• 請考慮根據使用案例分析數據的最佳方式。

下一步

• 建立自動駕駛汽車運營（AVOps）解決方案 ，以更廣泛地探討汽車數位工程，以進行自主和輔助駕駛。

相關資源

下列文章涵蓋架構中使用的一些概念：

• 宣告檢查模式 可用來支持處理大型訊息，例如檔案上傳。
• 部署戳記 涵蓋將解決方案調整為數百萬輛汽車所需的一般概念。
• 節流描述處理來自車輛的異常訊息數目所需的概念。

下列文章說明架構中元件之間的互動：

• 在 Azure 資料總管叢集上設定串流擷取
• 使用 Azure Synapse Analytics 擷取 Parquet 格式的事件中樞數據並加以分析