跳至主要內容
🚗 汽車製造 現行案例 難度 ★★★

KnightMotives Automotive

從製造汽車轉向 automotive experience

全車系一致體驗Build-to-order 與經銷商工具Hybrid cloud 與舊系統資安與 EU 資料保護

一句話描述(依官方原文):一家生產自動駕駛車(BEV、hybrid、ICE)的車廠,BEV 的車內體驗已有進展,其他車系落後,銷量與滿意度下滑;它想在五年內翻新全車系的消費者體驗,同時修好不可靠的線上訂車系統、補強經銷商工具,並處理老舊的 mainframe 與 ERP。

📄 官方案例整理:背景與需求

本節只轉述 Google 官方案例原文,沒有加入站內推論。原文:KnightMotives Automotive Case Study(官方 PDF,英文),是現行標準考綱連到的版本。核對日期:2026-10-07。

公司概況(Company Overview)

KnightMotives 是專做自動駕駛車的車廠,產品包含純電車(BEV)、hybrid 與傳統內燃機(ICE)車款。BEV 車系的車內體驗(in-vehicle experience)已有進展,但 hybrid 與 ICE 車款還沒導入這些新系統,車評與駕駛的評價都不好;原文說這已造成銷量與顧客滿意度下滑。

KnightMotives 想在五年內翻新所有車款的消費者體驗。原文認為 AI 可以改造車內體驗,也能改造選車、購車與保養維修的體驗;這項投資需要在全球層級調整財務優先順序。

不可靠的線上訂車系統(online ordering system)也要改善。讓顧客在線上配置車輛、再透過經銷商取得的系統,提供不了經銷商需要的資料與可靠度,使原廠與經銷商的關係變得緊張。維修技師與銷售人員需要更好的工具,包含客製訂車(built-to-order)的支援。

解決方案構想(Solution Concept)

KnightMotives 想從製造汽車,轉向打造完整的 automotive experience。策略重點有五個:所有車款體驗一致、開發 AI 功能、靠資料變現(data monetization)創造新營收、用數位化和競爭對手做出區隔,以及為技師與銷售人員開發更好的工具。

既有技術環境(Existing Technical Environment)

  • IT 大多在地端,部分(some)應用程式放在主要的雲端平台(major cloud platforms)。
  • 供應鏈系統跑在老舊的 mainframe 上;ERP 也過時,所以新的促銷與經銷商折扣很難上線。
  • 經銷商沒有添購新設備的預算。
  • 各車款之間有多套 codebase,零散不一;為了維持向下相容,累積了可觀的技術債。
  • 連到製造廠的網路,以及鄉村地區的車輛連線,都是難題。

業務需求(Business Requirements)

  • 與駕駛建立個人化的關係,並在所有車款提供一致的體驗。
  • 建立更好的 build-to-order 模式,縮短車輛停在車場的時間(time on the lot),並對經銷商與顧客都更透明(provide transparency)。
  • 把企業資料變現,用來支應新技術的投資;原文同時指出現有的 AI 基礎設施已經過時,企業資料仍是孤島。
  • 過去發生過資料外洩(data breaches),所以安全是首要考量。
  • 必須遵守歐盟(EU)資料保護法規,新興的自駕平台尤其如此。
  • 計畫大幅投資全自動駕駛,先從法規環境較有利的地區開始導入。
  • 員工技能提升(upskilling)、吸引頂尖人才、改善業務與技術團隊的溝通,也列為關鍵目標。

技術需求(Technical Requirements)

  • 車內體驗現代化:開發在所有車款都一致、整合 AI 功能的 UX;更新舊車款的車內硬體與軟體來支援新功能;確保網路連線可靠(特別是鄉村地區),以支援即時 AI 功能與資料傳輸。
  • 網路升級:支援增加的資料流量,並改善工廠與總部之間的連線。
  • IT 基礎設施現代化:採用 hybrid cloud 策略,同時運用地端與雲端,並逐步現代化或汰換舊系統。
  • 自駕車開發與測試:投資 AI 與機器學習技術、建立穩健的模擬環境(simulation environment),並符合持續演變的自駕車法規。
  • 資料變現與洞察:需要穩健的資料管理平台、嚴格的資料安全與隱私措施,以及可擴充的 AI/ML 基礎設施。
  • 安全與風險管理:建立完整的安全框架來防範網路威脅與資料外洩、制定事件應變計畫(incident response plan),並對員工做資安意識訓練。
  • 經銷商與顧客體驗:改善線上 build-to-order 系統;開發現代化的經銷商工具,涵蓋銷售、服務與庫存管理;導入完整的 CRM 系統,追蹤顧客互動並提供個人化體驗。

高層說法(Executive Statement)

CEO Michael Knight 表示,KnightMotives 致力於提升安全、拯救生命,做法是運用大量資料(駕駛、路況、行為研究與碰撞安全統計)為駕駛打造數位體驗。他說公司的 AI 表現持續優於全國安全統計,並要讓 KnightMotives 的體驗在所有車款上一致。

🧭 站內原創分析(非官方內容):讀題時先抓什麼

以下是登雲學院自己的讀法,不是 Google 的答案;官方案例只列需求,沒有指定架構。另外提醒:原文沒有給感測器或車輛的數量、資料量或回傳頻率,沒有提到預測性維護、保險業者或任何具名的資料合作對象,也沒有提到 MQTT、IoT Core 或時序資料庫;它提到製造廠的地方,講的是網路連線。

  • 它不只是車聯網題原文同時寫了老舊的企業系統、經銷商體驗、資安、隱私、人才與財務優先順序。任何一條都可能是題目的主約束,不要把它縮成一條 IoT 資料管線。
  • 舊系統分階段處理技術需求寫的是 hybrid cloud 策略、逐步現代化或汰換。Mainframe 與 ERP 要依相依性分批,不是一次全部重寫。
  • 連線不能假設永遠在線鄉村地區的車輛連線和製造廠的網路,都是原文點名的難題。車上功能要想清楚斷線時怎麼辦:本機決策、暫存、重送,以及安全的降級模式。
  • 經銷商沒有設備預算要經銷商添購專用硬體的方案先打問號。瀏覽器就能用、由原廠集中管理的工具通常比較合理,但仍要看題目的要求。
  • 資料變現之前先過安全與隱私公司發生過資料外洩,又要遵守 EU 資料保護法規。先處理同意、用途限制、去識別、存取控管與稽核,再談分享或販售。
  • 自駕和車內便利功能的風險不同自駕需要模擬環境、法規證據與退路;個人化或便利功能的風險等級不一樣,不要用同一套標準看待。
  • 人也是需求Upskilling 和跨團隊溝通寫在業務需求裡。導入一個團隊完全不會用的平台,卻沒有訓練與維運模式,答案就不完整。

🏗️ 站內延伸設計(非官方內容):從官方需求推候選方向

左欄是官方需求,中間和右欄是登雲學院的推論。產品只是候選方向,實際要看題目給的限制。

官方需求站內建議的候選方向動手前要確認
Hybrid cloud 與舊系統 用 Migration Center 建立資產清單,再補上相依關係後分批;新舊系統之間用 API 層隔開,逐步替換 哪些系統有硬相依、切換期間資料怎麼同步
工廠與總部的網路 原文要改善的是工廠與總部「之間」的連線。題目如果讓各據點都用 Cloud Interconnect 或 HA VPN 接上 Google Cloud,才考慮用 Network Connectivity Center 的 site-to-site data transfer,讓據點之間的流量走 Google 的網路;否則先看據點之間既有的 WAN 線路 頻寬、各廠區的線路條件、單一路徑故障時怎麼辦;site-to-site data transfer 是否支援據點所在的地點,而且它是盡力而為、沒有頻寬或延遲保證
鄉村地區連線 車上保留必要的本機決策;資料先暫存,連線恢復後再同步,並處理重送與重複 哪些功能必須離線可用、安全相關功能的降級規則
Build-to-order 與經銷商工具 做成 web 應用(例如放在 Cloud Run 或 GKE),不要求經銷商添購設備;訂單狀態對經銷商與顧客透明 和 ERP、供應鏈系統怎麼整合;CRM 要買現成的還是自建
資料變現與資料孤島 先把資料集中到有治理的資料平台(例如 BigQuery),敏感欄位用 Sensitive Data Protection 去識別 同意與用途限制、哪些資料可以離開哪個地區
安全與風險管理 身分、網路、資料、軟體供應鏈、偵測與應變一起補;員工訓練列入計畫 過去外洩的根因是什麼、事件應變由誰負責
EU 資料保護法規 限制資料與資源的所在區域,搭配存取控制與稽核紀錄 哪些資料屬於 EU 的當事人、跨境傳輸的規則
自駕開發與模擬 大量運算放雲端,用 Gemini Enterprise Agent Platform(原 Vertex AI)與 GPU、TPU 資源做訓練與模擬 資料與模型的治理、法規要求的證據
Upskilling 與團隊溝通 把訓練、維運模式與責任分工寫進導入計畫 團隊現有技能和新平台的落差

[車輛] 連線可用嗎?
   ├─ 否 → 本機安全決策、暫存事件、限制依賴雲端的功能 → 等連線恢復
   └─ 是 → 依序同步:重送、去重複、處理衝突
              │
              ▼
[中央平台] 車輛資料、經銷商與服務流程
              │
              ▼
[同意、用途、地區與存取政策允許嗎?]
   ├─ 否 → 限制使用,保留隱私證據
   └─ 是 → 分析、產品改善,或受控的資料產品

[安全攸關的決策] 模擬、退路、法規證據:獨立的風險邊界

這張圖是站內整理的流程,不是官方指定架構,而且只畫了「連線不穩」這一條線。官方案例的範圍更廣,舊系統、經銷商、資安與人才都要另外處理。

🚧 站內延伸設計(非官方內容):題目另外給條件才考慮

下面這些選項,官方案例沒有直接要求,但不代表它們一定是錯的。題目自己多給了條件,才把它們納入考慮。

如果題目說有大量車輛持續回傳資料,接入層要能緩衝尖峰

才考慮用 Pub/Sub 當接入緩衝。另外要知道 Cloud IoT Core 已在 2023 年停止服務,不會是可行的選項。官方案例沒有給車輛數、資料頻率或接入協定。

如果題目說資料一到就要即時計算

才考慮 Dataflow 這類串流處理。原文提到 real-time AI features 與資料傳輸,但沒有描述串流處理的需求。

如果題目說有大量時序資料,要低延遲讀寫

才考慮 Bigtable;要做跨年度的分析查詢則是 BigQuery。原文沒有提到時序資料或查詢型態。

如果題目說要把資料分享給外部組織,又不想複製資料

才考慮 BigQuery sharing(原 Analytics Hub)。原文有資料變現的目標,但沒有具名任何合作對象,而且要求嚴格的資料安全與隱私措施。

如果題目提到預測性維護

才規劃對應的 ML 模型與資料流程。原文沒有這個詞,它提到的是保養維修的體驗和維修技師的工具。

📐

換你練習(站內練習,非官方題目)

到 PCA 架構師設計工作坊 把 KnightMotives Automotive 當情境。第一步「定義案例情境」只填官方原文有的事實,再用「描繪 User Personas」分別寫經銷商銷售、維修技師與駕駛,最後在「安全與成本最佳化」寫出過去資料外洩與 EU 資料保護會改變哪些設計。

前往工作坊

🔗 延伸閱讀

徽章解鎖!
Nimbus

學習教練 Nimbus

你的雲端學習夥伴

依已保存的資源進度與學習目標提供練習建議。完成度不代表掌握程度或應考能力。

0
連續天數
0
確認讀完
0
收藏
0%
資源完成度
練習建議
    推薦下一步
    開始