嵌入式技術(shù)與整車(chē)網(wǎng)絡(luò )系統

　一、引言

　　隨著(zhù)市場(chǎng)需求和電子技術(shù)的發(fā)展，整車(chē)電氣系統經(jīng)歷著(zhù)電器化、電子化和網(wǎng)絡(luò )化三個(gè)階段性發(fā)展。嵌入式技術(shù)影響在電子化階段開(kāi)始體現，并在網(wǎng)絡(luò )化階段進(jìn)一步凸現。作為自主產(chǎn)業(yè)，直接面對電子化、網(wǎng)絡(luò )化發(fā)展階段重疊的局面，一方面存在缺乏積累、基礎薄弱等挑戰，另一方面也存在輕裝上陣、少走彎路的后發(fā)優(yōu)勢。因此，如何更好地將嵌入式技術(shù)與整車(chē)電氣系統開(kāi)發(fā)相融合，已經(jīng)成為自主產(chǎn)業(yè)技術(shù)路線(xiàn)的關(guān)鍵問(wèn)題。

　　二、概述

　　整車(chē)網(wǎng)絡(luò )是指將多個(gè)具有一定獨立工作能力的汽車(chē)電子系統通過(guò)總線(xiàn)實(shí)現資源共享和數據通信的分布式實(shí)時(shí)嵌入系統。由此定義可見(jiàn)，整車(chē)網(wǎng)絡(luò )以總線(xiàn)整合汽車(chē)電子系統的形式存在，但本質(zhì)仍然是由軟硬件構成的嵌入式系統。隨著(zhù)軟件在系統實(shí)現中占據日益主導的地位，整車(chē)網(wǎng)絡(luò )的開(kāi)發(fā)過(guò)程也來(lái)越接近典型的V模式軟件開(kāi)發(fā)過(guò)程，如圖1所示。

整個(gè)開(kāi)發(fā)過(guò)程可被分為系統開(kāi)發(fā)和零部件實(shí)施兩個(gè)應用層面，其中貫穿著(zhù)算法設計、軟件工程等基礎技術(shù)。由于種種原因，自主汽車(chē)電子產(chǎn)業(yè)存在著(zhù)重零部件輕系統、重應用輕基礎的問(wèn)題。需要指出的，基礎技術(shù)涉及的建模、仿真、軟件構架等均來(lái)源于主流的嵌入式技術(shù)體系，并不固定從屬于系統開(kāi)發(fā)或零部件實(shí)施的具體領(lǐng)域。因此，基礎技術(shù)也是系統開(kāi)發(fā)的必要前提。在系統開(kāi)發(fā)過(guò)程中，應用相應的基礎技術(shù)，結合上游用戶(hù)需求與下游零部件實(shí)施約束，才能完成嵌入式系統的集成設計與驗證。其中，工作內容可分為架構、總線(xiàn)和診斷的設計及驗證。

　　三、架構開(kāi)發(fā)

　　架構設計是借助工程方法，通過(guò)工程需求的捕捉，合理分配系統功能，最終完成網(wǎng)絡(luò )系統的結構設計。需要指出的是，工程方法是每個(gè)整車(chē)企業(yè)根據自身產(chǎn)品電氣系統的競爭策略，基于相符合的理論方法，結合自身的開(kāi)發(fā)配套體系，經(jīng)過(guò)長(cháng)期工程實(shí)踐建立的。不同整車(chē)企業(yè)甚至同一企業(yè)不同平臺的工程方法是不同的，作為結果的架構更是千差萬(wàn)別。因此，照搬系統架構甚至工程方法的做法是無(wú)法獲得合格架構的。

　架構開(kāi)發(fā)容易與總線(xiàn)開(kāi)發(fā)混淆。雖然同屬系統層面開(kāi)發(fā)，前者基于而高于后者。在架構設計中，總線(xiàn)僅是最主要的信息交互方式，其特點(diǎn)必須在設計過(guò)程中合理運用。反之，高性能、高質(zhì)量的總線(xiàn)也有效增加了架構的靈活性、復雜性。

　　3.1工程需求捕捉(圖2)

　　從用戶(hù)角度，工程需求不同于常見(jiàn)的市場(chǎng)需求：后者主要從市場(chǎng)用戶(hù)出發(fā)，關(guān)注的是網(wǎng)絡(luò )系統的外在使用價(jià)值而不是具體的構架、技術(shù)和零部件；除此之外，整車(chē)壽命周期內還有開(kāi)發(fā)工程師、制造工程師、售后工程師等內部用戶(hù)的需求。上述諸多用戶(hù)的需求同時(shí)也包含約束，例如法規、標準、成本、質(zhì)量、工程策略等等。從時(shí)間角度上。上述需求在項目周期中不同程度地動(dòng)態(tài)變化。因此，將所面臨的諸多用戶(hù)提出的變化的需求轉化為統一的工程需求，是架構開(kāi)發(fā)的起點(diǎn)，也體現了面向需求的設計理念。

　　工程功能(圖3)作為工程需求的基本載體，貫穿著(zhù)整個(gè)開(kāi)發(fā)過(guò)程。由于不同整車(chē)的需求差異，對工程功能的具體劃分不盡相同。一般而言，工程功能被分為用戶(hù)工程功能和非用戶(hù)工程功能：前者會(huì )被用戶(hù)直接感受到，例如燈光；后者不會(huì )被用戶(hù)直接感受到，一般是前者的支撐，例如總線(xiàn)喚醒，通常也被稱(chēng)為系統功能。對于每個(gè)工程功能的需求，也分為功能性需求和非功能性需求：前者主要定義不同狀態(tài)下輸入輸出等外在行為邏輯，通常是可復用在不同車(chē)型上，即實(shí)現功能性DNA，又減少了需求風(fēng)險，也為相關(guān)應用軟件復用提供了前提；后者包含了其他非功能性需求，如關(guān)鍵資源要求、成本，往往因車(chē)型而異。

對需求的捕捉中，需求的驗證是重要環(huán)節之一。上述需求數量浩大甚至相互矛盾，產(chǎn)生的需求風(fēng)險將嚴重影響下游的開(kāi)發(fā)。建立系統層面的功能性需求模型，不僅可以解決需求沖突問(wèn)題，也是對下游功能分配的必要約束。

　　3.2功能分配(圖4)

　　對于嵌入式軟硬件實(shí)現的工程功能，往往需要分布到多個(gè)零部件實(shí)現以滿(mǎn)足工程需求，因此合理的功能分配設計尤為關(guān)鍵。從實(shí)現角度而言，需要從邏輯、物理和機械布置層面進(jìn)行平衡。傳統的做法中功能分配僅被關(guān)注在機械布置和物理層面，簡(jiǎn)單地進(jìn)行基于物料成本的硬件分配。這種源自電器化階段的做法簡(jiǎn)單直觀(guān)，但是忽視邏輯分配會(huì )帶來(lái)響應性差、可靠性低等一些列原理問(wèn)題。

邏輯層面的分配，需要在保證關(guān)鍵資源、延遲、供電狀態(tài)、安全等非功能性需求前提下進(jìn)行。例如：某功能的子功能被分配到某控制器，除了需要傳感器／執行器等硬件外，控制器能否提供足夠的存儲空間、運算能力、供電狀態(tài)也同樣重要；子功能之間可通過(guò)總線(xiàn)、硬線(xiàn)進(jìn)行交連，但是連接方式必須確保功能本身的實(shí)時(shí)性、可靠性。