解決方案構想
本文說明解決方案概念。 您的雲端架構設計人員可以使用本指南，協助可視化此架構的一般實作的主要元件。 使用本文作為起點，設計符合您工作負載特定需求的架構良好解決方案。
此架構提供開發自動化駕駛解決方案的指引和建議。
建築
下載包含本文架構圖表的 Visio 檔案。
數據流
測量數據來自感測器的數據流，例如相機、雷達、超聲波、激光雷達和車輛遙測。 車輛中的數據記錄器會將測量數據儲存在記錄器儲存裝置上。 記錄器記憶體數據接著會上傳至登陸數據湖。
Azure 數據箱 或 Azure Stack Edge等服務，或 azure ExpressRoute 等專用連線，會將數據內嵌至 Azure。 測量數據也可以是模擬或其他來源的合成數據。 （MDF4、TDMS 和 rosbag 是度量的常見數據格式。在 DataOps 階段中，會處理內嵌的度量。 驗證和數據品質檢查，例如總和檢查碼，會執行以移除品質較低的數據。 在這個階段中，會擷取測試驅動程式在試用產品期間記錄的原始資訊元數據。 此數據會儲存在集中式元數據目錄中。 此資訊可協助下游進程識別特定場景和順序。
Azure Data Factory 會處理數據， 擷取、轉換和載入 （ETL） 管線。 輸出會以原始和二進位數據的形式儲存在 Azure Data Lake 中。 元數據會儲存在 Azure Cosmos DB
。 視案例而定，它可能會傳送至 Azure 資料總管 或 Azure 認知搜尋 。其他資訊、深入解析和內容會新增至數據，以改善其精確度和可靠性。
擷取的度量資料會透過 Azure Data Share，為合作夥伴加上標籤（人工迴圈）。 第三方合作夥伴會透過個別的 Data Lake 帳戶執行自動標記、儲存和存取數據。
卷標數據集會流向下游 MLOps 程式，主要是為了建立感知和感測器融合模型。 這些模型會執行自動駕駛汽車用來偵測場景的功能（即車道變化、封鎖道路、行人、紅綠燈和交通標誌）。
在 ValOps 階段中，已定型的模型會透過開放式循環和封閉式循環測試進行驗證。
Foxglove之類的工具，Azure Kubernetes Service 或 Azure Container Instances上執行，將內嵌和已處理的數據可視化。
數據採集
數據收集是自動駕駛汽車運營（AVOps） 的主要
DataOps
數據作業 （DataOps） 是一組改善資料作業品質、速度和可靠性的做法、程式和工具。 適用於自動駕駛的 DataOps 流程目標是確保用來控制車輛的數據品質高、準確且可靠。 藉由使用一致的 DataOps 流程，您可以改善數據作業的速度和精確度，並做出更好的決策來控制您的自動駕駛汽車。
DataOps 元件
- 數據箱 是用來透過區域貨運公司將收集的車輛數據傳輸到 Azure。
- ExpressRoute 透過私人連線，將內部部署網路延伸至Microsoft雲端。
- Azure Data Lake Storage 會根據原始或擷取等階段來儲存數據。
- Azure Data Factory 透過 批次計算 執行 ETL，並建立數據驅動工作流程，以協調數據移動和轉換數據。
- Azure Batch 針對數據整頓、篩選和準備數據，以及擷取元數據等工作執行大規模的應用程式。
- Azure Cosmos DB 儲存元數據結果，例如預存的度量。
- Data Share 可用來與合作夥伴組織共享數據，例如標記公司，具有增強的安全性。
- Azure Databricks 提供一組工具來大規模維護企業級數據解決方案。 對於大量車輛數據的長時間執行作業，這是必要專案。 數據工程師會使用 Azure Databricks 作為分析工作臺。
- Azure Synapse Analytics 可縮短跨數據倉儲和巨量數據系統深入解析的時間。
- Azure 認知搜尋 提供數據目錄搜尋服務。
MLOps
機器學習作業 （MLOps） 包括：
- 在 DataOps 管線期間，用於分類場景的功能擷取模型（例如，行人是否在場景中）。
- 自動套用標籤模型來標記擷取的影像和雷射雷達和雷達數據。
- 偵測對象和場景的感知和計算機視覺模型。
- 結合感測器數據流的感測器融合模型。
感知模型是此架構的重要元件。 此 Azure Machine Learning 模型會使用偵測到和擷取的場景來產生物件偵測模型。
容器化機器學習模型傳輸至可在晶元 （SoC） 硬體和驗證/模擬軟體上由系統讀取的格式發生在 MLOps 管線中。 此步驟需要SoC製造商的支援。
MLOps 元件
- Azure Machine Learning 可用來開發機器學習演算法，例如特徵擷取、自動標記、對象偵測和分類，以及感測器融合。
- Azure DevOps 支援 DevOps 工作，例如 CI/CD、測試和自動化。
- 適用於企業的 GitHub 是 DevOps 工作的替代選擇，例如 CI/CD、測試和自動化。
- Azure Container Registry 可讓您在私人登錄中建置、儲存和管理容器映像和成品。
ValOps
驗證作業 （ValOps） 是透過 受控案例在模擬環境中測試已開發模型的程式， 執行昂貴的真實世界環境測試。 ValOps 測試可協助確保模型符合您所需的效能標準、精確度標準和安全需求。 雲端中的驗證程序目標是在實時環境中部署自動駕駛汽車之前，先找出並解決任何潛在問題。 ValOps 包括：
- 模擬驗證。 雲端式模擬（開放式循環 和 封閉式循環測試）環境可讓您對自動駕駛汽車模型進行虛擬測試。 此測試會大規模執行，且成本低於真實世界測試。
- 效能驗證。 雲端式基礎結構可以執行大規模的測試，以評估自動駕駛汽車車型的效能。 效能驗證可能包括壓力測試、負載測試和基準檢驗。
使用 ValOps 進行驗證可協助您利用雲端式基礎結構的延展性、彈性和成本效益，並減少自動駕駛汽車車型上市時間。
開放式循環測試
重新模擬或 感測器處理，是自動駕駛功能的開放式循環測試和驗證系統。 這是一個複雜的程式，可能有安全性、數據隱私權、數據版本設定和稽核的法規需求。 重新模擬程式會透過雲端中的圖表，從各種汽車感測器記錄原始數據。 重新模擬會驗證數據處理演算法或偵測回歸。 OEM 會將感測器結合在代表真實世界車輛的導向非循環圖表中。
重新仿真是大規模的平行計算作業。 它會使用數萬個核心來處理數十或數百個 PB 的數據。 它需要超過 30 GB/秒的 I/O 輸送量。 來自多個感測器的數據會合併成數據集，代表當車輛瀏覽真實世界時，車輛計算機視覺系統所記錄的檢視。 開放式循環測試會使用重新執行和評分，根據地面真相來驗證演算法的效能。 輸出稍後會在工作流程中用於演算法定型。
- 數據集來自收集原始感測器數據的測試車隊車輛（例如相機、激光雷達、雷達和超聲波數據）。
- 數據量取決於相機解析度和車輛上的感測器數目。
- 原始數據會針對不同的裝置軟體版本重新處理。
- 原始感測器數據會傳送至感測器軟體的感測器輸入介面。
- 輸出會與舊版軟體的輸出進行比較，並針對錯誤修正或新功能進行檢查，例如偵測新的物件類型。
- 在模型和軟體更新之後，會執行作業的第二次重新插入。
- 地面真相數據是用來驗證結果。
- 結果會寫入記憶體，並卸除至 Azure 數據總管以取得視覺效果。
封閉式循環測試和模擬
自動駕駛汽車的封閉式循環測試是測試車輛功能的程式，同時包括環境的實時反饋。 車輛的行為都基於其預先程式設計的行為和它遇到的動態條件，並據此調整其行動。 封閉式循環測試會在更複雜的實際環境中執行。 它用來評估車輛處理真實世界案例的能力，包括其對非預期情況的反應。 封閉式循環測試的目標是要確認車輛能夠在各種條件下安全有效地運作，並視需要精簡其控制演算法和決策流程。
ValOps 管線整合了封閉式循環測試、第三方模擬和ISV應用程式。
案例管理
在 ValOps 階段中，會使用真實案例目錄來驗證自動駕駛解決方案模擬自動駕駛汽車行為的能力。 目標是透過從可公開存取且自由使用的數位地圖，自動讀取屬於案例的路線網路，以加速建立案例目錄。 將第三方工具用於案例管理或輕量型開放原始碼模擬器，例如 CARLA，其支援 OpenDRIVE （xodr） 格式。 如需詳細資訊，請參閱 ScenarioRunner for CARLA。
ValOps 元件
- Azure Kubernetes Service 執行大規模批次推斷，以在 Blob 架構內進行開放式循環驗證。 建議您使用 BlobFuse2 來存取度量檔案。 您也可以使用 NFS，但您必須評估使用案例的效能。
- Azure Batch 執行大規模批次推斷，以在 Blob 架構內進行開放式循環驗證。
- Azure 數據總管 提供測量和 KPI 的分析服務（也就是重新模擬和作業執行）。
集中式AVOps函式
AVOps 架構很複雜，且牽涉到各種第三方、角色和開發階段，因此實作良好的治理模型非常重要。
建議您建立集中式小組來處理基礎結構布建、成本管理、元數據和數據目錄、譜系，以及整體協調流程和事件處理等功能。 集中這些服務是有效率的，可簡化作業。
建議您使用集中式小組來處理這些責任：
- 提供ARM/Bicep 範本，包括標準服務的範本，例如AVOps架構的每個區域和子區域所使用的記憶體和計算
- 實作AVOps數據迴圈事件驅動協調流程的中央 Azure 服務總線/Azure 事件中樞實例
- 元數據目錄的擁有權
- 所有 AVOps 元件的端對端譜系和可追蹤性功能
案例詳細數據
您可以使用此架構在 Azure 上建置自動化駕駛解決方案。
潛在的使用案例
汽車 OEM、第 1 層廠商和 ISV，可開發自動化駕駛解決方案。
考慮
這些考慮會實作 Azure Well-Architected Framework 的要素，這是一組指引原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。
安全
安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性支柱概觀。
請務必了解汽車 OEM 與雲端提供者之間的責任劃分。 在車輛中，OEM 擁有整個堆疊，但隨著數據移至雲端，某些責任會傳輸到雲端提供者。 Azure 平臺即服務 （PaaS） 在實體堆疊上提供內建改善的安全性，包括作業系統。 除了基礎結構安全性元件之外，您還可以套用下列改進功能。 這些改進可啟用 Zero-Trust 方法。
- 網路安全性的私人端點。 如需詳細資訊，請參閱 Azure 資料總管的私人端點 和 允許透過私人端點存取 Azure 事件中樞命名空間。
- 待用加密和傳輸中。 如需詳細資訊，請參閱 Azure 加密概觀。
- 使用Microsoft Entra 身分識別和 Microsoft Entra 條件式存取 原則的身分識別和存取管理。
- Azure 數據總管的數據列層級安全性 （RLS）。
- 使用 Azure 原則的基礎結構治理。
- 使用 Microsoft Purview的數據控管。
- 憑證管理，協助保護車輛的連線。
- 最低許可權存取權。 使用 Just-In-Time（JIT）和 Just-Enough-Administration（JEA）、風險型調適型原則和數據保護來限制使用者存取。
成本優化
成本優化是減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化支柱概觀。
您可以使用這些策略來降低與開發自動駕駛解決方案相關的成本：
- 優化雲端基礎結構。 仔細規劃和管理雲端基礎結構可協助您降低成本。 例如，使用符合成本效益的實例類型和調整基礎結構，以符合變更的工作負載。 請遵循 Azure 雲端採用架構中的指引。
- 使用 Spot 虛擬機。 您可以判斷 AVOps 部署中的哪些工作負載不需要在特定時間範圍內進行處理，並針對這些工作負載使用現成虛擬機。 現成虛擬機可讓您利用未使用的 Azure 容量來節省大量成本。 如果 Azure 需要容量回來，Azure 基礎結構就會收回虛擬機。
- 使用自動調整。 自動調整可讓您根據需求自動調整雲端基礎結構，減少手動介入的需求，並協助您降低成本。 如需詳細資訊，請參閱 針對調整進行設計。
- 請考慮針對記憶體使用經常性存取層、非經常性存取層和封存層。 記憶體在自主驅動解決方案中可能是相當重要的成本，因此您必須選擇符合成本效益的記憶體選項，例如冷記憶體或不常存取記憶體。 如需詳細資訊，請參閱 資料生命週期管理。
- 使用成本管理和優化工具。 Microsoft成本管理 提供工具，可協助您識別和解決成本降低的領域，例如未使用或使用量過低的資源。
- 請考慮使用 Azure 服務。 例如，您可以使用 Azure Machine Learning 來建置和定型自動駕駛模型。 使用這些服務比建置和維護內部基礎結構更有成本效益。
- 使用共享資源。 可能的話，您可以使用共用資料庫或共用計算資源等共用資源，以減少與自主駕駛開發相關聯的成本。 集中式函式 在此架構中，例如實作中央總線、事件中樞和元數據目錄。 Azure Data Share 等服務也可以協助您達成此目標。
貢獻
本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。
主要作者：
- 里安松村 |資深項目經理
- Jochen Schroeer |首席架構師（服務線路行動性）
其他參與者：
若要查看非公用LinkedIn配置檔，請登入LinkedIn。
後續步驟
相關資源
如需開發自動化駕駛系統 DataOps 的詳細資訊，請參閱：
您可能也對下列相關文章感興趣：
- AVOps 設計指南
- 適用於汽車測試車隊的 數據分析
- 自主駕駛模擬環境的建置組塊