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

　一、引言

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

　　二、概述

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

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

　　三、架構(gòu)開發(fā)

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

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

　　3.1工程需求捕捉(圖2)

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

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

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

　　3.2功能分配(圖4)

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

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