解決方案構想
本文說明解決方案概念。 您的雲端架構設計人員可以使用本指南，協助可視化此架構的一般實作的主要元件。 使用本文作為起點，設計符合您工作負載特定需求的架構良好解決方案。
此架構提供開發自動化駕駛解決方案的指引和建議。
架構
資料流程
測量數據來自感測器的數據流，例如相機、雷達、超聲波、激光雷達和車輛遙測。 車輛中的數據記錄器會將測量數據儲存在記錄器儲存裝置上。 記錄器記憶體數據接著會上傳至登陸數據湖。 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 容器執行個體 上執行，將內嵌和已處理的數據可視化。
資料集合
數據收集是自動駕駛汽車運營（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） 包括：
- 功能擷取模型（例如 CLIP 和 YOLO）用於分類場景（例如，在 DataOps 管線期間，行人是否在場景中）。
- 自動套用標籤模型來標記擷取的影像和雷射雷達和雷達數據。
- 偵測對象和場景的感知和計算機視覺模型。
- 結合感測器數據流的感測器融合模型。
感知模型是此架構的重要元件。 此 Azure 機器學習 模型會使用偵測到和擷取的場景來產生物件偵測模型。
容器化機器學習模型傳輸至可在晶元 （SoC） 硬體和驗證/模擬軟體上由系統讀取的格式發生在 MLOps 管線中。 此步驟需要SoC製造商的支援。
MLOps 元件
- Azure 機器學習 可用來開發機器學習演算法，例如特徵擷取、自動標記、物件偵測和分類，以及感測器融合。
- 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 階段中，會使用真實案例目錄來驗證自動駕駛解決方案模擬自動駕駛汽車行為的能力。 目標是透過從可公開存取且自由使用的數位地圖，自動讀取屬於案例的路線網路，以加速建立案例目錄。 針對案例管理或使用輕量型 開放原始碼 模擬器使用第三方工具，例如支援 OpenDRIVE （xodr） 格式的 CARLA。 如需詳細資訊，請參閱 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） 在實體堆疊上提供內建改善的安全性，包括作業系統。 除了基礎結構安全性元件之外，您還可以套用下列改進功能。 這些改進可啟用零信任方法。
- 網路安全性的私人端點。 如需詳細資訊，請參閱 Azure 資料總管的私人端點和允許透過私人端點存取 Azure 事件中樞 命名空間。
- 待用加密和傳輸中。 如需詳細資訊，請參閱 Azure 加密概觀。
- 使用Microsoft Entra 身分識別和Microsoft Entra 條件式存取原則的身分識別和 存取 管理。
- Azure 數據總管的數據列層級安全性 （RLS）。
- 使用 Azure 原則的基礎結構治理。
- 使用 purview Microsoft 的數據控管。
- 憑證管理 ，協助保護車輛的連線。
- 最低許可權存取權。 使用 Just-In-Time （JIT） 和 Just-Enough-Administration （JEA）、風險型調適型原則和數據保護來限制使用者存取。
成本最佳化
成本優化是減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化要素的概觀。
您可以使用這些策略來降低與開發自動駕駛解決方案相關的成本：
- 優化雲端基礎結構。 仔細規劃和管理雲端基礎結構可協助您降低成本。 例如，使用符合成本效益的實例類型和調整基礎結構，以符合變更的工作負載。 遵循 Azure 雲端採用架構 中的指引。
- 使用Spot虛擬機器。 您可以判斷 AVOps 部署中的哪些工作負載不需要在特定時間範圍內進行處理，並針對這些工作負載使用 Spot 虛擬機器。 現成 虛擬機器 可讓您利用未使用的 Azure 容量來節省大量成本。 如果 Azure 需要容量回來，Azure 基礎結構就會收回虛擬機。
- 使用自動調整。 自動調整可讓您根據需求自動調整雲端基礎結構，減少手動介入的需求，並協助您降低成本。 如需詳細資訊，請參閱 調整的設計。
- 請考慮針對記憶體使用經常性存取層、非經常性存取層和封存層。 記憶體在自主驅動解決方案中可能是相當重要的成本，因此您必須選擇符合成本效益的記憶體選項，例如冷記憶體或不常存取記憶體。 如需詳細資訊，請參閱 數據生命週期管理。
- 使用成本管理和優化工具。 Microsoft成本管理工具 可協助您識別並解決成本降低的領域，例如未使用或使用量過低的資源。
- 請考慮使用 Azure 服務。 例如，您可以使用 Azure 機器學習 來建置和定型自動駕駛模型。 使用這些服務比建置和維護內部基礎結構更有成本效益。
- 使用共享資源。 可能的話，您可以使用共用資料庫或共用計算資源等共用資源，以減少與自主駕駛開發相關聯的成本。 例如，此架構中的集中式函式會實作中央總線、事件中樞和元數據目錄。 Azure Data Share 之類的服務也可以協助您達成此目標。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- 里安松村 |資深項目經理
- Jochen Schroeer |首席架構師（服務線路行動性）
其他投稿人：
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
相關資源
如需開發自動化駕駛系統 DataOps 的詳細資訊，請參閱：
您可能也對下列相關文章感興趣：