軟體定義汽車（SDV）時代來臨：車用軟體複雜度已超越傳統開發工具能力
現代汽車早已不再只是「加上一層軟體」的機械產品，而是名副其實運作於輪子上的軟體平台。
如今，一輛汽車平均執行數億行程式碼，分散於數十個獨立的電子控制單元（Electronic Control Unit，ECU）中，其軟體複雜度甚至足以媲美商用飛機。電源管理、車身控制、車載資訊娛樂系統，以及先進駕駛輔助系統（ADAS）皆仰賴程式碼運作，而這些程式碼也持續不斷演進。
然而，許多車用嵌入式開發團隊仍沿用為過去時代打造的工作流程與系統架構，當時五年的產品開發週期仍屬合理。如今，在業界所稱的 「China Speed（中國速度）」 推動下，產品開發週期已大幅縮短至兩年內。
新興 OEM 以極快速度推出新車，並透過 OTA（Over-the-Air）持續向車主推送軟體更新。如今，「中國速度」已不再只是個別市場現象，而是重新定義全球汽車設計、生產與更新的節奏。
這正是 IAR 所稱的 「1 億行程式碼陷阱（100 million-line trap）」，也是所有開發車用安全關鍵嵌入式軟體團隊必須面對的現實挑戰。
其他產業常見的「快速推出、事後修正」開發模式，並不適用於汽車軟體。產品召回（Recall）與後期修補不僅會帶來難以預估的成本，更可能對品牌造成長期風險。
1 億行程式碼陷阱：車用嵌入式軟體開發面臨的四大挑戰
真正的問題並非程式碼數量本身，而是程式碼的架構與管理方式。傳統車用平台由數十個彼此獨立的 ECU 組成，每個 ECU 都執行各自的軟體堆疊，由不同供應商維護，擁有各自的生命週期，並透過所有系統共同競用的 CAN 匯流排進行通訊。
在這種架構下，即使只是微小的變更，都可能演變成龐大的跨團隊協作工程。更新單一功能可能需要多家供應商共同配合、跨多個 ECU 重新測試，並重新提供驗證證據，才能獲得功能安全認證機構核准發布。
結果就是版本發布速度變慢、已知漏洞暴露時間拉長，技術債持續累積，使未來每一次變更的成本都更加高昂。
以下四項長期存在的挑戰，使許多團隊始終難以突破瓶頸：
- 傳統硬體限制： 透過 CAN 連接的傳統 ECU 架構，由於硬體高度耦合，加上頻寬與記憶體資源受限，不僅降低軟體重用率，也拖慢開發速度。
- 流程不一致： 以硬體為核心的開發模式與現代 DevOps、CI/CD 流程難以接軌，使自動化、模擬測試與可重現建置（Reproducible Build）變得困難，同時軟體成長速度也早已超越硬體演進速度。
- 架構碎片化： 缺乏一致性的架構策略，導致各團隊建立專屬軟體堆疊，難以整合 AUTOSAR、服務導向中介軟體（Service-Oriented Middleware）及多種通訊協定。
- 法規遵循複雜度高： 在數十個 ECU 上同時符合 ISO 26262 功能安全與 ISO/SAE 21434 網路安全要求，不僅耗時，也需要投入大量資源。即使只是小幅修改，也可能導致整體重新認證。
與 Infineon、Qt、Vector、Elektrobit 等合作夥伴提供的預先整合軟體套件，可直接提供經過驗證的基礎平台、圖形軟體堆疊及安全關鍵控制軟體，讓團隊無須從零開始整合，即可快速從概念設計推進至產品量產。
與 Vector、ETAS、Elektrobit 等合作夥伴共同完成驗證的 AUTOSAR Classic 與 MCAL 整合方案，可為安全關鍵 MCU 提供具決定性（Deterministic）且符合 ISO 26262 最佳化的開發流程，降低整合風險與重新認證成本，同時支援跨不同車輛領域的 ECU 擴展開發，並持續符合最高等級的安全要求。
像 Dojo5 這類 CI/CD 流程專家可協助缺乏內部 DevOps 能力的團隊建立並維護容器化 CI/CD Pipeline。他們可協助完成建置後交由團隊接手、培訓工程師自行維護，或持續提供代管服務。
因此，即使是小型團隊，沒有專職 CI/CD 工程師，也不再是導入現代化開發流程的阻礙。
當上述挑戰相互疊加後，車用軟體的規模化開發將變得極為困難，這也說明了為何導入新一代系統架構與開發流程已不再是可有可無的選項，而是必要條件。
重新思考車輛架構：從 Domain 架構走向 Zonal 架構
要擺脫這個陷阱，不僅需要重新思考車輛電子架構，也必須重新檢視整體開發流程。傳統車用平台採用以 ECU 為核心的 Domain（功能域）架構，例如車身（Body）、動力系統（Powertrain）、ADAS 等功能域。
然而，即使在這樣的架構下，團隊仍需面對軟體重複開發、線束複雜，以及整體系統更新速度緩慢等問題。
圖片：Siemens Digital Industries
目前汽車產業正逐步邁向 Zonal（區域式）架構與混合式 Domain-Zonal 架構。不同於依照功能劃分 ECU，Zonal 架構改以車輛的實體位置進行分區，再連接至中央運算平台或區域運算節點。
此架構不僅能減少線束與車重、提升資料傳輸效率，更重要的是大幅簡化系統整合與後續更新。
隨著越來越多功能整合至少數高效能控制器，容器化（Containerization） 與 虛擬化（Virtualization） 已成為不可或缺的技術，使不同安全等級（Mixed-Criticality）的軟體能夠安全地在共享硬體上執行。然而，要真正實現大規模部署，軟體必須與硬體解耦，才能在無須反覆重新認證的情況下進行重用與更新。
這也代表開發流程必須全面革新，促進硬體、軟體、功能安全與資安團隊之間更緊密的協作，同時導入具備可重現建置能力的統一工具鏈與 CI/CD Pipeline。
唯有開發流程同步升級，現代化車輛架構才能真正發揮其價值。
OTA 更新與可重現建置：確保車用軟體長期安全維護的關鍵
在軟體定義汽車（Software-Defined Vehicle，SDV）的時代，軟體不會在量產啟動（Start of Production，SOP）後停止演進。即使是安全關鍵系統，如今也已普遍透過 OTA（Over-the-Air）進行頻繁更新。
車輛在整個使用生命週期內，都必須持續修補漏洞、更新功能並進行優化，而這些需求已非傳統 V-Model 開發流程所能獨立支援。
這也帶來一項許多團隊容易低估的重要需求：數年之後，仍必須能夠重新建置出完全相同的軟體版本，以驗證 OTA 更新、調查現場問題（Field Issues），並維持功能安全法規遵循。
容器化正是實現這項能力的關鍵。透過將工具鏈與建置環境封裝於容器中，團隊可以產生具備決定性（Deterministic）且可追溯的 Binary，確保開發者電腦、CI Pipeline 與 OTA 發布系統皆產出完全一致的執行檔，並獲得監管機構的信任。
這並非理論上的優勢。IAR 在研討會中的實際展示便顯示，一個馬達控制專案雖然能在 GitHub Actions Pipeline 中順利完成建置，但在開發者本機上，即使使用相同版本的工具鏈與相同原始碼，仍產生不同的建置結果。
原因在於容器化 Docker 映像中包含了 Infineon MCU 所需的裝置支援檔案，而本機環境卻缺少這些檔案。當專案改為在與 CI Pipeline 相同的 Dev Container 中開啟後，問題立即消失，建置結果完全一致且沒有任何錯誤。這正是可重現建置（Reproducible Build）的最佳實例。
此外，由於汽車的產品生命週期通常長達 10、15，甚至 25 年以上，因此長期支援（Long-Term Support，LTS）並非加分功能，而是維持功能安全法規遵循的基礎。
每一次工具鏈變更，都可能增加開發流程與功能安全重新驗證的負擔。若缺乏穩定且持續受支援的工具鏈，車輛上市五年後的每一次 OTA 更新，都可能演變成重新認證專案。長期支援能確保 CI/CD Pipeline 與既有安全證據持續有效，讓整個車隊生命週期中的 OTA 更新，都能兼顧安全性、法規遵循與可預測性。
IAR Platform：支援 SDV 全生命週期的安全關鍵嵌入式開發平台
IAR 透過通過功能安全認證的開發平台，協助解決上述挑戰。此平台不僅支援產品上市，更著眼於軟體定義汽車的完整生命週期，從第一行程式碼提交（First Design Commit）開始，到未來數十年的 OTA 更新與現場維護，都能提供一致且可靠的支援。
CI/CD 流程示意圖
從專案一開始即符合最高 ASIL D 功能安全認證
IAR 的工具鏈已通過 TÜV SÜD 認證，符合 ISO 26262 最高等級 Automotive Safety Integrity Level D（ASIL D） 功能安全要求。
這項優勢的重要性，往往比許多團隊所認知的還高。若未採用預先完成資格認證（Pre-qualified）的工具鏈，每個新的認證專案通常都必須額外投入 6 至 12 個人月（Person-Month），重新驗證編譯器，並執行大量測試，以證明工具鏈能夠穩定產生可重複且符合標準要求的建置結果。
若採用已完成安全認證的工具鏈，相關驗證證據早已具備。團隊只需向認證機構提交工具認證文件，審查重點便能聚焦於應用程式本身的安全功能及其測試結果，而非工具鏈本身。如此可大幅節省認證時間、人力成本及整體專案風險。
這也說明了一項常令部分團隊感到意外的決策：功能安全工具應在專案一開始就選定，而非開發途中才導入。 專案進行期間更換工具鏈，是對開發流程影響最大的變更之一，也容易引起認證機構的疑慮。
實務上，一旦團隊決定採用某套經過認證的工具鏈，通常會在整個產品生命週期內持續使用，時間往往長達 10 至 15 年。因此，工具鏈的選擇代表的是整個專案的長期承諾，而非單純的採購決策。
內建除錯、程式分析與程式碼品質管理能力
IAR 提供完整的進階除錯與追蹤能力，包括 多核心除錯（Multi-core Debugging）、即時程式碼效能分析（Live Code Profiling） 以及 RTOS 感知（RTOS Awareness），讓複雜的 SDV 系統更容易觀察、分析與預測行為。
內建的 C-STAT 靜態分析與執行期分析（Runtime Analysis） 能在開發初期及早發現問題；搭配模型導向設計（Model-Based Design） 與符合 MISRA 規範的程式碼產生能力，可支援具備結構化且可認證的開發流程。
如此一來，每一次建置都能自動建立程式碼品質與法規遵循基礎，使後續更新不再演變為最後一刻的風險評估。
廣泛支援 MCU／MPU，避免硬體綁定
IAR 支援 ARM、RISC-V、Renesas、STM8 等多種處理器架構，並針對 Infineon、NXP、Microchip、STMicroelectronics、SemiDrive 等眾多晶片供應商提供完整的裝置支援。如此廣泛的支援能力，讓團隊能在不同 ECU、不同 Zonal 架構及不同車款世代間重複利用既有軟體，而無須因平台更換而重新開發。
面對持續變動的供應鏈環境，這種彈性更顯重要，因為它能降低硬體轉換所帶來的衝擊，保障長期產品開發計畫的穩定性。
CI/CD、容器化與現代嵌入式開發流程
IAR 可直接整合至現代化 CI/CD 環境，包括 GitHub Actions、GitLab CI、Jenkins 與 Kubernetes，讓嵌入式軟體團隊也能擁有與雲端軟體團隊相同的開發效率。適用於 VS Code 的 IAR 擴充套件，以及支援 Headless Build 的 IAR Build Tools，可將相同的功能安全認證工具鏈導入容器化 DevOps Pipeline。
透過雲端授權機制，工具鏈可隨團隊使用，而非綁定於特定電腦。容器化環境有效降低日常開發摩擦，使建置結果更具可預測性、更新流程更具一致性，也徹底解決「可以在我電腦上運作（Works on my machine）」的常見問題。
為大規模量產打造的完整生態系
要跟上「中國速度」，光有優秀的工具鏈還不夠，更需要一套經過預先驗證的整合生態系，才能省去數個月的平台 Bring-up 與整合工作。為了避免大量客製化 Glue Code 與脆弱的整合流程，IAR 建立了完整的合作夥伴生態系，讓開發團隊能直接以成熟且經驗證的基礎平台開始開發：
最後這一點的重要性，其實遠比表面看起來更高。許多人認為容器化只是大型企業、擁有專屬平台團隊才需要考慮的事情，但事實並非如此。對於小型團隊而言，經常會出現某位工程師的電腦默默成為實際上的 Build Server。一旦該人員請假、離職或無法提供支援，整個建置流程便可能停擺。
容器化能夠消除這個單點失效（Single Point of Failure），簡化新成員導入流程，也讓團隊未來在規模成長時，無須重新打造整套基礎設施即可順利擴充。導入成本並不高，但所帶來的風險降低效益卻十分可觀。
長期支援（LTS）為車用功能安全的重要基礎，而非單純供應商選擇
車用軟體的生命週期幾乎與其他產業截然不同。電動車的設計壽命通常長達使用者職涯的大半時間。即使在量產啟動（SOP）後 20 至 25 年，仍可能需要新增功能、修補缺陷，以及修正資安漏洞。
在這段漫長的期間，開發團隊必須持續重建軟體、發布 OTA 更新，並提供監管機構認可的法規遵循證據。
這代表企業需要一家具備長期經營能力的工具鏈供應商，確保二十年後仍能持續提供技術支援、維護版本，以及符合認證要求的更新套件。長期支援（Long-Term Support，LTS）並非單純的營運細節，而是維持軟體定義汽車（SDV）功能安全的重要基礎。
若缺乏長期支援，每一次工具鏈更新都有可能使既有的功能安全證據失效，進而被迫投入高昂成本重新進行工具資格認證與安全驗證。
IAR 自 1983 年成立以來，便持續投入嵌入式開發工具領域。其平台提供長期維運服務、維護版本更新、經認證的 Service Pack，以及穩定的授權機制，正是因為車用軟體的生命週期往往比多數科技公司的存在時間更長。因此，在採購階段就應將這項因素納入評估。
工具鏈的選擇，是整個產品開發計畫的長期承諾，而非一次性的採購決策。 在汽車產業，一套工具鏈往往會陪伴產品完整生命週期，其使用時間甚至可能超過當初導入它的工程師職涯。
現在做出正確的選擇，才能在未來長達數十年的產品生命週期中，持續維持穩定、可預測的開發與維護能力。
降低車用軟體開發風險：以安全認證平台加速 SDV 創新
「1 億行程式碼陷阱」是真實存在的，但並非無法避免。只要團隊重新檢視車輛架構、導入現代化開發流程，並以具備功能安全認證與真正長期支援能力的平台作為開發基礎，就能成功擺脫這項挑戰。
實際上，這代表團隊可以從專案第一個 Sprint 開始，就利用最高符合 ASIL D 的預先認證解決方案，降低後續認證工作量與專案風險。現代化開發流程與容器化技術，讓團隊能在維持程式碼品質的同時，加快開發速度。
平台可在開發早期即發現潛在問題，降低產品召回（Recall）及開發後期修補所帶來的高昂且難以預測的成本。
此外，結合廣泛的 AUTOSAR、MCAL 支援、完整的 MCU／MPU 裝置涵蓋能力，以及成熟的第三方合作夥伴生態系，讓團隊能在不同架構、不同晶片供應商與不同車輛功能域之間靈活開發，而無須為每個平台重複開發相同軟體。
減少額外負擔，降低不可預期風險，將更多時間投入打造真正能展現品牌競爭力的功能，並跟上現代車用軟體開發所要求的速度。這就是 IAR Platform 所帶來的價值。
下一步：探索如何突破 1 億行程式碼陷阱，打造敏捷化 SDV 開發流程
觀看隨選研討會 《Escaping the 100 M-line Trap: From Legacy Silos to Agile Software-Defined Vehicles》，了解實際示範內容，包括容器化建置如何解決安全關鍵嵌入式開發中常見的 「Works on my machine（在我電腦上可以運作）」 問題。
或親自體驗互動式展示，了解 IAR Platform 如何透過符合功能安全認證的編譯器、程式碼分析、進階除錯與現代化 CI/CD 流程，協助您降低 ISO 26262 法規遵循風險。
歡迎前往 ➤ 與 FSG 功能安全專家們繼續深入探討
文由IAR提供