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

　一、引言

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

　　二、概述

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

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

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

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

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

　　3.1工程需求捕捉(圖2)

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

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

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

　　3.2功能分配(圖4)

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

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

　　功能分配僅針對單個工程功能，而功能與功能、系統(tǒng)與零部件存在的關(guān)聯(lián)和由此產(chǎn)生的沖突。因此，系統(tǒng)層面上針對功能、零部件的平衡是架構(gòu)整合的基本內(nèi)容。同時。合格的架構(gòu)不僅必須滿足成本要求，還需要與開發(fā)人力、可靠性、技術(shù)風(fēng)險和可配置性進行折中。鑒于架構(gòu)設(shè)計的復(fù)雜性和平臺化戰(zhàn)略考慮，通常以架構(gòu)平臺的形式出現(xiàn)。

　　作為分布式嵌入式系統(tǒng)，網(wǎng)絡(luò)系統(tǒng)的架構(gòu)(圖5)存在著更分布還是更集中的爭議。在更分布式的系統(tǒng)中，諸多功能盡可能按功能分布在不同的控制系統(tǒng)實現(xiàn)，系統(tǒng)的可配置性好、可靠性高但物料成本較高；在更集中的系統(tǒng)中，諸多功能盡可能按區(qū)域分布在同一的控制系統(tǒng)實現(xiàn)，系統(tǒng)的物料成本較低但可配置性差、可靠性低。在實際工程應(yīng)用中，由于不同整車系統(tǒng)、不同功能領(lǐng)域的需求差異，更分布和更集中架構(gòu)往往是折中的。架構(gòu)開發(fā)常見的輸出是輸出文檔是電氣原理圖、功能分配規(guī)范，并直接作為線束、控制系統(tǒng)和總線開發(fā)的設(shè)計輸入。

四、總線開發(fā)

　　總線是指連接控制器的數(shù)字、雙向傳輸、多分支結(jié)構(gòu)的通信系統(tǒng)，通常一條或多條總線和網(wǎng)關(guān)構(gòu)成整車網(wǎng)絡(luò)。常見的總線如CAN、LIN，以及MOST、FlexRay。

　　總線可被視為滿足分布式功能需要的用于數(shù)據(jù)交換的非用戶工程功能，依托節(jié)點的嵌入式軟硬件分布式實現(xiàn)的。因此，運用總線時必須考慮其資源占用、時延、可靠性、線束布局等需求；反之，這些也是總線技術(shù)升級換代的驅(qū)動力。通常，總線開發(fā)包括物理層、通信層、網(wǎng)絡(luò)管理和網(wǎng)關(guān)四部分內(nèi)容。

　　4.1物理層(圖6)

　　物理層指構(gòu)成總線硬件的線束、接插件及板級收發(fā)電路。作為硬件部分，主要的難點在于設(shè)計偏差認可和一致性保證。前者主要是存在于沿用其他總線設(shè)計的控制系統(tǒng)，硬件的設(shè)計偏差認可與否很大程度上影響了方案最終確定；后者是指批量情況下全壽命周期的性能一致性保證，為避免散差、老化造成的質(zhì)量問題，必須在設(shè)計階段對性能指標(biāo)進行相應(yīng)分配，并通過耐久試驗進行測試與改進。

4.2通信層(圖7)

　　通信層介于物理層和應(yīng)用軟件之間，是通信協(xié)議的主體，主要包含通信策略和信號配置。

　　通信策略定義了通信機制的傳輸模型和時延模型，本質(zhì)上服務(wù)于功能內(nèi)部的數(shù)據(jù)交換需求，并屬于后者的抽象。例如人機類功能一般屬于開環(huán)控制類，事件觸發(fā)的傳輸模式即可滿足數(shù)據(jù)交換需要，總體時延要求在200毫秒以上。通信策略不僅可以直接作為通信層軟件開發(fā)需求，也是通過總線進行功能分配的重要參考依據(jù)。忽視通信策略的設(shè)計和驗證。容易造成總線負載高、時延超差等問題，由此引發(fā)的功能失效的代價極大。一般而言，采用含有成熟通信策略的嵌入式軟件是較保險的解決方案。

信號配置是與架構(gòu)設(shè)計直接相關(guān)，也是總線設(shè)計中最直觀的部分。信號配置本質(zhì)上是把信號根據(jù)協(xié)議特性和架構(gòu)需求進行組幀的過程。從邏輯角度，信號配置必須滿足架構(gòu)中的流向關(guān)系、幀裝載字長和帶寬等限制；從時序角度，分配后信號的傳輸時延應(yīng)確保滿足功能的總體時延分配。

　　4.3網(wǎng)絡(luò)管理

　　網(wǎng)絡(luò)管理主要完成啟動／停止、休眠／喚醒、錯誤處理和版本控制等功能。網(wǎng)絡(luò)管理通常包含節(jié)點管理和系統(tǒng)管理(狹義網(wǎng)絡(luò)管理)，前者限于節(jié)點本地的通訊管理，后者協(xié)調(diào)節(jié)點間的系統(tǒng)級行為。

　　作為解決方案，可以直接引入包含網(wǎng)絡(luò)管理算法的嵌入式軟件，進一步定義網(wǎng)絡(luò)管理策略的時間參數(shù)設(shè)定、網(wǎng)絡(luò)管理底層策略與應(yīng)用層的接口和應(yīng)用層對網(wǎng)絡(luò)管理的具體需求。需要指出的是，網(wǎng)絡(luò)管理的失效易導(dǎo)致意外的休眠／喚醒，輕者導(dǎo)致相關(guān)功能失效，重者將影響蓄電池電置。

4.4網(wǎng)關(guān)

　　網(wǎng)關(guān)實現(xiàn)不同總線的不同類型的數(shù)據(jù)交換，不僅包括常見的信號數(shù)據(jù)，還包含喚醒／休眠、啟動／停止等管理指令。對于信號數(shù)據(jù)的路由組織，基于信號的方式利于時延的評估，而基于幀的方式便于配置的標(biāo)準化，分別體現(xiàn)了不同的架構(gòu)設(shè)計理念。

　　網(wǎng)關(guān)的功能性需求來源于架構(gòu)設(shè)計，越復(fù)雜越分布，系統(tǒng)的網(wǎng)關(guān)復(fù)雜度越大。從實現(xiàn)角度，網(wǎng)關(guān)功能增加了系統(tǒng)的可配置性但降低了可靠性，需要在架構(gòu)設(shè)計中進行合理平衡。

五、診斷開發(fā)

　　診斷系統(tǒng)能實時監(jiān)控功能運行，并通過總線接口與外部用戶設(shè)備實現(xiàn)數(shù)據(jù)交換，滿足法規(guī)、開發(fā)、制造、售后甚至信息服務(wù)的需求。從法規(guī)角度，通常排放相關(guān)的診斷內(nèi)容是強制性標(biāo)準化的．如常見的在線診斷(OBD)。診斷開發(fā)的基本內(nèi)容主要包括功能自診斷、診斷管理、通信協(xié)議和配置系統(tǒng)四部分開發(fā)內(nèi)容。

　　5.1功能自診斷(圖9)

　　任何嵌入式方式實現(xiàn)均存在軟硬件失效的可能，因此實時在線的功能自診斷是必要的保障手段。功能診斷包括面向應(yīng)用功能的自診斷和面向系統(tǒng)功能的自診斷，后者通常是指操作系統(tǒng)、總線等基礎(chǔ)或者內(nèi)核部分。功能自診斷通常針對對物理輸入輸出和邏輯輸入輸出，前者通過相關(guān)電路特性判斷是否存在物理失效，后者對邏輯信號的數(shù)值、變化特性進行可信度判斷。一經(jīng)判斷出失效，系統(tǒng)將采取缺省值甚至降級運行等處理策略。需要指出的是，功能自診斷的初衷是針對潛在失效，因此相關(guān)的失效模式分析是其設(shè)計來源
[!--empirenews.page--]5.2診斷管理

　　診斷管理的主要內(nèi)容是故障管理。系統(tǒng)運行期間，功能自診斷因為隨機失效會產(chǎn)生相當(dāng)數(shù)量的故障指示，不加處理容易造成虛警；對于正常的故障診斷，故障信息存儲也容易受到非易失性存儲資源的限制。故障管理將處理本地所有功能自診斷的故障指示，根據(jù)故障特性進行“識別-確認-退出”的過程管理；存在多個故障時進行類似堆棧的處理，保證高優(yōu)先級故障信息的存儲；根據(jù)診斷協(xié)議的指令輸出或清空故障信息。

　　5.3診斷通信

　　區(qū)別于總線的在線通信，診斷通信被稱為離線通信，蓋因其非常在線特點。其服務(wù)層為診斷功能提供國際通用和自定義兩種診斷服務(wù)支持。診斷服務(wù)層為上層屏蔽具體通信特征，使其只考慮功能應(yīng)用方面。每條診斷服務(wù)作為控制器功能的觸發(fā)條件或入口點。診斷服務(wù)層提供診斷服務(wù)(service)的軟件實施效率是保證控制器能夠及時響應(yīng)外部診斷診斷請求的重要因素之一。其會話層控制器與診斷工具之間的通信使能，打開或斷開雙方的通信。當(dāng)診斷工具與控制器間的應(yīng)用服務(wù)無法維持時關(guān)閉這些服務(wù)。將所有服務(wù)功能分布到合適session中，滿足診斷功能分級是該設(shè)計目的。其傳輸層設(shè)計實現(xiàn)塊數(shù)據(jù)的傳遞功能，為大數(shù)據(jù)量的傳遞提供通信通道。此外還需定義傳輸層與上、下層之間的軟件接口，優(yōu)化匹配參數(shù)。除診斷數(shù)據(jù)外，應(yīng)用功能也存在塊數(shù)據(jù)傳輸需求(例如曲目名稱)，因此傳輸層也面向應(yīng)用軟件。其物理層將定義其相應(yīng)的具體總線協(xié)議的初始化，如診斷數(shù)據(jù)幀標(biāo)識符ID分配，還包括一些特殊硬件操作，如診斷工具接入步驟。

　　5.4 配置系統(tǒng)(圖10)

　　基于市場、工程等多方面需要，整車網(wǎng)絡(luò)存在大量的通過診斷進行的信息配置。以中級車為例，整車配置信息多達上百條、數(shù)十千比特。在項目的不同階段，對上述配置進行正確無誤的快速處理是配置系統(tǒng)的主要功能。

六、集成測試(圖11)

　　不同于零部件實施的測試，集成測試關(guān)注的是系統(tǒng)層面的測試驗證。

　6.1基礎(chǔ)測試

　　基礎(chǔ)測試針對系統(tǒng)中總線、診斷等系統(tǒng)功能：控制器是否能夠及時地通過總線將采集到的傳感器信號傳遞給其他控制器，是否能夠及時響應(yīng)其他控制器通過總線傳遞的指令并驅(qū)動執(zhí)行機構(gòu)；網(wǎng)關(guān)實現(xiàn)的功能是否正確(滿足設(shè)計要求)；所有控制器是否能按規(guī)定進入／退出睡眠模式(網(wǎng)絡(luò)管理策略是否滿足設(shè)計規(guī)范)；控制器網(wǎng)絡(luò)的電流消耗是否在規(guī)定的范圍之內(nèi)；總線負載是否符合設(shè)計要求；在線診斷功能是否符合設(shè)計要求。

　　6.2功能測試

　　根據(jù)系統(tǒng)架構(gòu)、功能需求等設(shè)計規(guī)范，結(jié)合測試平臺結(jié)構(gòu)和測試環(huán)境特點生成測試規(guī)范。測試規(guī)范詳細定義了測試要求和步驟，包括點火開關(guān)狀態(tài)、功能實現(xiàn)的條件、功能結(jié)果、具體描述及注意事項等。同時對誤用濫用也要進行詳盡分析，生成相應(yīng)的測試文檔。

　　根據(jù)上述測試規(guī)范進行詳細的功能測試，以確認集成效果是否滿足設(shè)計規(guī)范。測試解決方案建立在標(biāo)準系統(tǒng)框架基礎(chǔ)上，通過開放式接口提供完整的模型設(shè)計、測試設(shè)計、診斷和標(biāo)定設(shè)計，虛擬試驗環(huán)境、實時仿真模型、試驗和試驗參數(shù)可在不同設(shè)計階段和項目中得以復(fù)用。

　　七、總結(jié)

　　本文對整車網(wǎng)絡(luò)開發(fā)和系統(tǒng)開發(fā)工作進行了詳細描述，結(jié)合嵌入式理論介紹了基于功能面向需求的架構(gòu)設(shè)計方法以及總線、診斷、集成測試的工作重點。