案例研究：KnightMotives Automotive

深入理解 KnightMotives Automotive 案例研究

KnightMotives Automotive 是一家全球汽車製造商，專注於開發下一代連網汽車與自動駕駛汽車。他們面臨的主要挑戰是管理來自數百萬輛汽車的龐大即時遙測 (Telemetry) 數據流、實施預測性維護 (Predictive Maintenance) 以減少製造停機時間，並確保汽車與雲端之間的安全、低延遲通訊（邊際運算 / Edge Computing）。

在 GCP Professional Cloud Architect (PCA) 考試中，KnightMotives 測試您設計高吞吐量數據攝取管道以及針對工業 IoT 的專門 AI/ML 工作流的能力。2025/2026 年的更新特別強調了 Google Distributed Cloud (Edge) 的使用，以及在工廠端利用 Vertex AI 進行即時推論。

白話文解釋 KnightMotives 架構

管理全球汽車車隊就像是為數據經營一家龐大且高速的郵政服務。

類比 1 — 智慧車隊調度員

將 KnightMotives 的遙測系統想像成一個智慧車隊調度員。每輛車都是一輛不斷發送「狀態報告」（遙測數據）的運貨卡車。卡車不再需要一路開回總部（中央雲端）來報告輪胎漏氣，而是與駐紮在高速公路沿線的「地方調度員」（邊際運算 / Google Distributed Cloud）交談。這些地方調度員可以比總部更快地告訴卡車「立即靠邊停車」（即時安全警報），同時僅將報告摘要發送回總部進行長期記錄。

類比 2 — 工廠裡的「預言家」

預測性維護就像是在裝配線上有一位預言家。在過去，您只有在機器人壞了之後才去修理（被動維護）。現在，您有一位預言家 (Vertex AI)，他傾聽機器人的「心跳」——它的溫度、振動和速度。預言家可以察覺到機器人機械心臟中的細微雜音並說：「三天後，這個機器人會故障。」這讓您可以在計劃好的休息時間進行修理，而不是在繁忙的班次中停止整個工廠。

類比 3 — 全球供應鏈帳本

管理數百萬輛汽車的零件就像維持一個全域即時帳本。您在德國、墨西哥和中國都有工廠。當中國工廠使用了一個零件時，帳本 (BigQuery / Cloud Spanner) 會在全球範圍內立即更新。「供應鏈帳本」確保墨西哥工廠確切知道下一批感應器何時到達，防止出現因為缺少一個五分錢螺絲而導致價值十億美元的汽車無法完工的「瓶頸」。

技術需求：IoT 與邊際運算

KnightMotives 需要處理來自經常處於低連線環境中汽車的數據。

數據攝取管道

1. 汽車連接： 汽車通過 MQTT 或 HTTPS 連接。由於 Google Cloud IoT Core 已停用，「最優」架構涉及使用運行在 GKE 上的合作夥伴 MQTT 代理程式（如 HiveMQ 或 EMQX），或者如果硬體支援，直接使用 Cloud Pub/Sub。
2. 串流處理： Cloud Pub/Sub 以全域規模攝取數據。
3. 處理： Cloud Dataflow 執行即時轉換，例如過濾「雜訊」或使用元數據（如車主資訊）豐富遙測數據。
4. 存儲： 將用於低延遲查詢的「熱 (Hot)」數據存儲在 Bigtable 中，將長期分析所需的「冷 (Cold)」歷史數據存儲在 BigQuery 中。

使用 Google Distributed Cloud (GDC) 進行邊際運算

• 低延遲： 對於時間敏感的決策（如自動煞車輔助），使用 GDC Edge 在靠近汽車或工廠端運行容器化的 AI 模型。
• 數據主權： GDC 允許 KnightMotives 將敏感的製造數據保留在特定國家的物理邊界內（例如德國），以符合當地法規，同時仍使用 GCP 的管理介面。

使用 Vertex AI 進行預測性維護

KnightMotives 希望消除工廠中「計劃外的停機時間」。

• 數據攝取： 通過 Pub/Sub 從製造機器人收集感應器數據。
• 模型訓練： 使用 Vertex AI 對存儲在 BigQuery 中的歷史故障數據進行模型訓練。使用 AutoML 進行快速原型設計，或使用自定義訓練 (Custom Training) 處理專用工業感應器數據。
• 推論： 將訓練好的模型部署到 Vertex AI Endpoints 進行雲端預測，或將模型匯出（使用 TensorFlow Lite）到 GDC Edge 進行工廠端的即時推論。
• 可解釋 AI (Explainable AI)： 使用 Vertex AI Explainable AI 告訴工廠經理機器人被預測會故障的原因（例如：「振動水平超過安全閾值 20%」）。

全球供應鏈分析

• BigQuery： 使用 BigQuery 作為中央數據倉庫，分析供應鏈效率、保修索賠模式和銷售預測。
• BigQuery Omni： 如果 KnightMotives 在 AWS S3 或 Azure Blob Storage 中也有部分數據（由於與零件供應商的合作），使用 BigQuery Omni 直接分析該數據而無需將其移動到 GCP，節省數據傳輸成本和複雜性。
• Looker： 使用 Looker 為高階主管建立即時儀表板，監控全球所有工廠的生產健康狀況。

連網汽車遙測管道深入解析

KnightMotives 從約 300 萬輛在線車輛各自每秒接收 4–6 則訊息，在跨區域的早高峰時段可飆升至 18M msg/sec。「最優」管道是針對此突發流量模式量身打造。

Pub/Sub 攝取層

• 依地理位置佈署區域性 Pub/Sub 主題（例如 proj/km/topics/vehicle-telemetry-eu、-us、-apac），確保歐盟車輛酬載永遠不會跨出區域邊界。為格式錯誤的 CAN-bus 訊框設置死信主題 (dead-letter topic)。
• 啟用以 VIN 為基礎的訊息排序索引鍵 (message ordering keys)，讓單輛車的事件在事故重建需要嚴格時序時保持順序。
• 設置 messageRetentionDuration=7d，讓 Dataflow 能在發現轉換錯誤時回溯並重播 (seek + replay) 過去一週的遙測資料。

Dataflow 串流作業

• 使用啟用 --enableStreamingEngine 的 Dataflow Streaming Engine，讓工作節點磁碟保持小巧、自動擴縮更快。
• 套用時段視窗 (session windows，gap=30s) 將遙測數據依駕駛行程分組，並將 TripSummary PCollection 發送至 BigQuery。
• 透過旁路輸入 (side-input) 查詢 Bigtable 中的 vehicleProfile，在落地前以車型年份／韌體版本豐富每筆事件。
• 將熱資料列寫入 Bigtable（/cf:speed、/cf:rpm、/cf:engine_temp），並透過 WriteToBigQuery 以 STREAMING_INSERTS 模式（每秒 >100k 筆時改用 Storage Write API 節省成本）將每日彙整視圖寫入 BigQuery。

Bigtable 時間序列結構設計

• Row key 格式：<reverse-VIN>#<reverse-timestamp>，將寫入分散到節點之間，並讓最新讀取落在每列的頂端附近。
• 單一欄族 cf 搭配 GC 規則 MaxVersions=1 + MaxAge=90d，讓舊遙測資料自動下沉淘汰。
• 使用 Bigtable 自動擴縮（min=10、max=200 節點）吸收通勤尖峰，無需在夜間為閒置容量付費。

IoT Core 退場路徑與 GKE 上的 MQTT 代理程式

Google Cloud IoT Core 已於 2023-08-16 退場，因此 KnightMotives 必須自行運行 MQTT 結構。「最優」做法是在 GKE Autopilot 上佈署合作夥伴代理程式，而非將數百萬輛車重新平台化到 HTTPS。

參考架構

• 在區域性 GKE Autopilot 叢集上佈署 HiveMQ 或 EMQX Enterprise，前端使用內部／外部 TCP 網路負載平衡器搭配 MQTT over TLS（連接埠 8883）。
• 透過 Workload Identity 讓代理程式 pod 將身分驗證事件寫入 Cloud Logging，並透過代理程式原生的 Pub/Sub bridge 將轉發遙測送往 Pub/Sub。
• 為每輛車配發由 Certificate Authority Service (CA Service) 簽發的唯一 X.509 用戶端憑證 — 每年透過 OTA 韌體推送進行輪替。
• 將裝置身分對應 (VIN → certFingerprint → ownerId) 儲存在 Firestore（Native mode），讓代理程式的身分驗證外掛能於 10ms 內完成查詢。

使用 Vertex AI 進行邊際推論

• 在 Vertex AI Training 中訓練撞擊偵測與車道偏離模型、匯出為 TensorFlow Lite，並隨 OTA 酬載派送至車輛。
• 使用 Vertex AI Model Registry 追蹤每個 VIN 正在執行的模型版本，並透過 BigQuery 與現場故障進行關聯分析。
• 對工廠機器人，在廠內 Google Distributed Cloud (GDC) Edge 裝置上運行 Vertex AI Prediction 容器，讓模型每秒能對 2,000 筆振動樣本計分而不需離開廠區。

預測性維護與用於保固詐欺的 BigQuery ML

• 在歷史保固索賠與遙測彙整資料的 join 結果上訓練 BigQuery ML BOOSTED_TREE_CLASSIFIER：SELECT ... FROM ML.PREDICT(MODEL km.warranty_fraud, TABLE km.claim_features)。將預測詐欺機率 >0.85 的索賠標記送交人工審查。
• 在每項零件故障率上使用 BQML ARIMA_PLUS 預測未來 90 天的備件需求，並回饋至先前敘述的供應鏈帳本。

使用 Dataplex 的召回 Lineage 與 OEM 經銷商入口網

• 將遙測資料湖（Bigtable + BigQuery + GCS 韌體儲存桶）註冊到 Dataplex，並開啟自動資料 lineage — 當召回事件被觸發時，法務團隊可在一次查詢中回答「哪個韌體建置、哪些 VIN、哪段日期區間內，產生了這些讀數？」。
• 將面向經銷商的召回查詢與服務通報 UI 託管在 App Engine Standard（Java 21），前端搭配 Identity-Aware Proxy — App Engine 的依請求擴縮與 99.95% SLA 符合經銷商入口網的流量輪廓，且無需強迫經銷商使用 VPN。

連網汽車的安全性

• 身份感知代理 (IAP)： 在無需 VPN 的情況下，安全地存取 KnightMotives 員工使用的車隊管理軟體。
• 二進位授權 (Binary Authorization)： 確保只有經過信任且簽署過的韌體更新，才能通過 CI/CD 管道部署到汽車的車載電腦中。
• VPC 服務控制 (VPC Service Controls)： 保護「汽車主數據庫」免受未經授權的存取或數據外洩。

KnightMotives Automotive 最優解 (Optimal) vs. 可行解 (Viable) 決策摘要

FAQ — KnightMotives Automotive 案例研究

Q1. KnightMotives 如何處理 Google Cloud IoT Core 停用的影響？

KnightMotives 應採用代管在 GKE 上的合作夥伴 MQTT 解決方案（如 HiveMQ），或者如果其硬體支援，則直接使用 Cloud Pub/Sub。這為 MQTT 代理程式的功能提供了更大的靈活性和控制權。

Q2. 為什麼遙測數據使用 Bigtable 而非 BigQuery？

雖然 BigQuery 非常適合分析，但 Bigtable 對於高頻寫入和低延遲讀取是「最優」的。每秒發送數據的汽車需要一個能高效處理恆定小量寫入流的數據庫，這正是 Bigtable 的強項。

Q3. 在此背景下，「預測性維護」是指什麼？

它是利用 ML 模型 (Vertex AI) 分析來自機器的感應器數據，在故障發生之前預測何時會故障。這使得 KnightMotives 能夠在計劃停機期間執行維修，節省數百萬美元的生產損失。

Q4. 邊際運算如何幫助 KnightMotives？

邊際運算 (GDC) 允許在本地（汽車或工廠內）處理數據，而不是將所有數據發送到中央雲端。這為安全關鍵型決策提供了所需的低延遲，並降低了頻寬成本。

Q5. KnightMotives 如何確保汽車韌體更新的安全？

通過使用具備二進位授權的 Cloud Build，KnightMotives 確保只有通過所有安全測試並由授權機構簽署的程式碼，才能部署到車隊中。

最終架構師提示

對於 KnightMotives Automotive，關鍵在於**「速度與規模」。您正在處理數百萬個設備和 PB 級的數據。您的架構必須是「非同步的」（使用 Pub/Sub）且「高度專門化的」（使用 Bigtable 和 GDC Edge）。掌握串流數據管道和工業 AI** 模式，您就能輕鬆通過 PCA 考試。