共用方式為

汽車傳訊、資料與分析參考架構

  • 發行項

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

架構

高層級結構的圖表。

概略架構圖顯示出汽車傳訊、資料與分析解決方案的主要邏輯區塊和服務。 如需更多詳細資料，請參閱下列小節。

  • 車輛包含一系列的裝置。 這些裝置有一些是「以軟體定義」，且可以執行雲端受控的軟體工作負載。 車輛會收集及處理廣泛類型的資料，從電子機械裝置 (例如電池管理系統) 的感應器資訊到軟體記錄檔。
  • 車輛傳訊服務會管理針對及來自車輛的通訊。 其負責處理訊息、使用工作流程執行命令，以及協調車輛、使用者及裝置管理後端。 其也會追蹤車輛、裝置及憑證註冊和佈建。
  • 車輛和裝置管理後端是追蹤從原廠車輛設定到後續維修和保養的 OEM 系統。
  • 操作員具有 IT 與作業以確保車輛和後端的可用性和效能。
  • 資料與分析服務提供資料儲存體，並為所有資料使用者提供處理和分析。 其會將資料轉換為見解，以促成更佳的商務決策。
  • 車輛製造商會以加值服務的形式為客戶提供數位服務，從隨附應用程式到維修和保養應用程式。
  • 數個數位服務都需要與後端系統進行商務整合，包括經銷商管理 (DMS)、客戶關係管理 (CRM) 或企業資源規劃 (ERP) 系統。
  • 同意管理後端是客戶管理的一部分，且會根據地理國家/地區法律追蹤使用者在資料收集上的授權。
  • 從車輛收集到的資料會成為對數位工程流程的輸入，其目標是使用分析和機器學習來持續改善產品。
  • 智慧行動生態系統能夠訂閱並擷取即時遙測和彙總見解，以提供更多產品和服務。

「Microsoft 為 Eclipse Software Defined Vehicle (英文) 工作群組的成員，其為針對車輛軟體平台使用開放原始碼進行開放共同作業的論壇。」

資料流程

此架構使用發行者/訂閱者 (部分機器翻譯) 傳訊模式來將車輛與服務分離。

車輛到雲端的訊息

「車輛到雲端」資料流程是用來處理來自車輛的遙測資料。 遙測資料可以定期傳送 (車輛狀態、從車輛感應器收集) 或根據事件傳送 (由錯誤條件觸發、對使用者動作的反應)。

傳訊資料流程的圖表。

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

雲端到車輛訊息

「雲端到車輛」資料流程經常用來在車輛中從數位服務執行遠端命令。 這些命令包括如將車門鎖上/解鎖、氣候控制 (設定偏好的車內溫度) 或設定變更的使用案例。 成功的執行需取決於車輛狀態，且可能需要一些時間才能完成。

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

  • 不需要使用者同意檢查，且具有可預測回應時間的直接雲端到裝置訊息 (A)。 這同時涵蓋針對個別和多輛車輛的訊息。 範例包括天氣通知。
  • 使用車輛狀態來判斷成功及要求使用者同意的車輛命令 (B)。 訊息解決方案必須有能夠檢查使用者同意、追蹤命令執行狀態，以及在完成時通知數位服務的命令工作流程邏輯。

例如，下列資料流程使用者命令是從隨附應用程式數位服務發出的。

命令和控制資料流程的圖表。

直接訊息會以最低數目的躍點來執行，以提供最佳效能 (A)：

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

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

  1. 車輛擁有者/使用者會針對對數位服務 (在此範例中為隨附應用程式) 的命令和控制函式的執行提供同意。 通常在使用者下載/啟動應用程式，且 OEM 啟動其帳戶時進行。 它會在車輛上觸發設定變更，以在 MQTT 代理中訂閱相關聯的命令主題。
  2. 隨附應用程式會使用命令和控制受控 API 來要求遠端命令的執行。
    1. 命令執行可能會有更多參數，以設定如逾時、儲存和轉接選項等選項。
    2. 命令邏輯會決定如何根據主題和其他屬性來處理命令。
    3. 工作流程邏輯會建立狀態 (State) 以追蹤執行的狀態 (Status)
  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 儲存體能儲存大型文件 (例如影片和 CAN 追蹤)，以及對車輛資料進行策展。
  • Azure Databricks (部分機器翻譯) 能提供一組工具來大規模維護企業級資料解決方案。 此為針對大量車輛資料進行之長時間執行作業的必要項目。

後端整合

  • Azure Logic Apps (部分機器翻譯) 會根據車輛資料針對商務整合執行自動化工作流程。
  • Azure App Service (部分機器翻譯) 能提供使用者面向的 Web 應用程式和行動後端，例如隨附應用程式。
  • Azure Cache for Redis (部分機器翻譯) 能為使用者面向應用程式經常使用的資料提供記憶體內快取。
  • Azure 服務匯流排 (部分機器翻譯) 能提供將車輛連線能力與數位服務和商務整合分離的訊息代理功能。

替代項目

用來實作訊息處理和受控 API 之正確計算類型的選取，需取決於許多因素。 請使用選擇 Azure 計算服務 (部分機器翻譯) 指南來選取正確的服務。

範例：

  • Azure Functions 適用於由事件驅動的短期處理序，例如遙測擷取。
  • Azure Batch 適用於高效能計算工作，例如將大型 CAN 追蹤/影片檔案解碼
  • Azure Kubernetes Service 適用於對複雜邏輯進行受控的完整協調流程，例如命令與控制工作流程管理。

作為事件型資料共用的替代方案，也可以在目標是要在資料湖層級執行批次同步處理的情況下使用 Azure Data Share (部分機器翻譯)。

案例詳細資料

高階檢視的圖表。

隨著汽車 OEM 從生產固定的產品，逐漸轉變為提供以軟體定義的連線車輛，這個產業正在經歷著重大的轉型。 這些車輛提供各式各樣的功能，例如無線更新、遠端診斷，以及個人化的使用者體驗。 此轉換使得 OEM 得以根據即時資料和見解持續改善他們的產品，同時擴展其商務模型以包括新的服務和收入來源。

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

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

潛在使用案例

「OEM 汽車使用案例」與強化車輛效能、安全性和使用者體驗相關。

  • 持續產品改善：透過分析即時資料並從遠端套用更新來強化車輛效能。
  • 工程測試車隊驗證：透過收集和分析測試車隊的資料來確保車輛安全性和可靠性。
  • 隨附應用程式與使用者入口網站：透過個人化應用程式和 Web 入口網站提供遠端車輛存取和控制的能力。
  • 主動維修與保養：根據資料驅動的見解針對車輛保養進行預測和排程。

「更廣泛的生態系統使用案例」能擴展連線的車輛應用程式以改善整個交通環境的車隊作業、保險、行銷及路邊救援。

  • 連線的商業車隊作業：透過即時監視和資料驅動決策制定來對車隊管理進行最佳化。
  • 數位車輛保險：根據駕駛行為對保險費用進行自訂，並提供立即的事故報告。
  • 位置型行銷：根據駕駛的位置和偏好為其提供針對性的行銷活動。
  • 道路救援：使用車輛位置和診斷資料為具有需求的駕駛提供即時支援和協助。

考量

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

可靠性

可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性要素的概觀 (部分機器翻譯)。

  • 考慮進行水平縮放以新增可靠性。
  • 使用縮放單位來隔離具有不同法規的地理區域。
  • 自動縮放和保留執行個體：透過根據需求進行動態縮放來管理計算資源，同時搭配預先配置的執行個體將成本最佳化。
  • 異地備援：將資料複寫到多個地理位置，以獲得容錯和災害復原的能力。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性要素的概觀。

  • 保護車輛連線：參閱憑證管理 (部分機器翻譯) 來了解如何使用 X.509 憑證來建立安全的車輛通訊。

成本最佳化

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

  • 每部車輛的成本考量：通訊成本應該取決於所提供之數位服務的數目。 針對作業成本計算數位服務的 ROI。
  • 根據訊息流量建立成本分析的做法。 連線的車輛流量通常會隨著新增更多服務而持續提升。
  • 考慮網路與行動成本
    • 使用 MQTT 主題別名來減少流量。
    • 使用有效的方法來對承載訊息進行編碼和壓縮。
  • 流量處理
    • 訊息優先順序：車輛通常會有會產生每日/每週需求尖峰的重複性使用模式。 使用訊息屬性來延遲非關鍵或分析訊息的處理，以使負載更加平滑並將資源使用方式最佳化。
    • 根據需求自動調整。
  • 考慮資料應該要儲存多久：經常性存取/非經常性存取/極非經常性存取。
  • 考慮使用保留執行個體來將成本最佳化。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運要素的概觀 (部分機器翻譯)。

  • 考慮以整合 IT 作業之一部分的形式監視車輛軟體 (記錄/計量/追蹤)、傳訊服務、資料與分析服務，以及相關的後端服務。

效能效益

效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 如需詳細資訊，請參閱效能效率要件概觀。

  • 考慮針對會縮放至超過 50,000 部裝置的解決方案使用縮放概念，特別是在需要涉及多個地理區域的情況下。
  • 仔細考慮內嵌資料的最佳方法 (傳訊、串流或批次)。
  • 考慮根據使用案例分析資料的最佳方法。

下一步

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

  • 宣告檢查模式 (部分機器翻譯) 用來支援處理大型訊息，例如檔案上傳。
  • 部署戳記 (部分機器翻譯) 涵蓋將解決方案縮放至數以百萬計車輛的一般概念。
  • 節流 (部分機器翻譯) 描述處理來自車輛異常數量訊息所需的概念。

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