重型車輛在ECU網(wǎng)絡(luò)開發(fā)方面面臨著與轎車相同的挑戰(zhàn),而型號多、低產(chǎn)量、生命周期長、需要適當?shù)慕Y(jié)構(gòu)層次等因素，又帶來了額外的困難。因此必須要有專門為重型車而改進的開發(fā)方法，來應(yīng)對成本壓力和確保產(chǎn)品可靠上市。

自從20世紀90年代電子技術(shù)開始應(yīng)用到車輛上，ECU的數(shù)量以及軟件的數(shù)量就開始成倍增加。最初涉及的只是發(fā)動機控制器，現(xiàn)在大量的電子“助手”正在應(yīng)用，這些例子包括ABS、ESP、ACC以及其他的駕駛輔助系統(tǒng)等，這些都使駕駛車輛更加安全、舒適。文獻【1】設(shè)想了電子設(shè)備的應(yīng)用會進一步增加，到2010年，電子控制模塊將在所有創(chuàng)新技術(shù)中占到90%。關(guān)鍵的一點是這些創(chuàng)新的80%是由軟件或軟件所實現(xiàn)的功能構(gòu)成的。在這篇文章中，可以很清楚的看出，在整車開發(fā)過程中，軟件開發(fā)方法起著至關(guān)重要的作用，他們對車輛的成功上市產(chǎn)生著重要的影響。

與轎車相比，重型車輛生產(chǎn)商面臨著特別巨大的挑戰(zhàn)，那就是改型多且產(chǎn)量低。盡管不同品牌車輛同時使用相同的ECU，以及集成標準的組件能夠減少成本壓力，以上因素仍會導(dǎo)致電子和軟件的設(shè)計更加復(fù)雜。

需求靈活的解決方案

只要考慮到不同重型車生產(chǎn)商會采用不同的開發(fā)策略時，就會意識到?jīng)]有通用的解決方案。然而，因為ECU的數(shù)量增加的速度相對緩慢，而純粹軟件功能的增加卻相當快。因此，從全局的角度考慮，參照標準、使用代碼生成工具以及通用的工具鏈肯定是一種趨勢。

通用的解決方案就是從需求到驗證的各階段，使用全面且統(tǒng)一的工具鏈。像過去一樣使用獨立的、非通用的工具被證明是不切實際的。各種工具的配置過程和生成成果差異很大。這導(dǎo)致開發(fā)過程中需求改變時，工具之間難以達成一致。因此需要在不同的工具中修改配置來滿足一個需求的改變，而不會自動完成，也沒有工具間的一致性檢測能力。這給整個組織帶來很大麻煩，尤其是部門之間或者項目之間。

因此，一個數(shù)據(jù)庫及其開發(fā)工具應(yīng)該作為整個工具鏈的核心。數(shù)據(jù)庫及其開發(fā)工具都需要適應(yīng)整車廠的特殊需求。除了純粹的技術(shù)方面，工具也應(yīng)該考慮公司的開發(fā)過程。變更管理、配置管理、甚至工作流程的維護都應(yīng)該在工具里體現(xiàn)。如果外部供應(yīng)商需要集成到這個過程中，就需要考慮數(shù)據(jù)交換格式，可以是某個標準或者事實上的工業(yè)標準，例如Vector的CANdb++數(shù)據(jù)格式。在一些情況下，整車廠也給他的供應(yīng)商指定了具體的工具，然后基于數(shù)據(jù)庫與供應(yīng)商進行協(xié)作，并在符合需求、提高質(zhì)量和效率等方面更好的幫助供應(yīng)商。這方面的例子包括：嵌入式系統(tǒng)代碼生成或者測試工具，例如Vector提供的CANoe.J1939 開發(fā)和測試工具。

網(wǎng)絡(luò)功能需求的增長使系統(tǒng)設(shè)計變得更加復(fù)雜，不同的ECU正在應(yīng)用到不同的平臺以及不同的國家，這大大增加了改型的數(shù)量。這就要求通信構(gòu)架以及ECU間的信號映射關(guān)系具有靈活性。這不僅影響了可用的信號，也影響了通信協(xié)議的使用。例如，在歐洲，通常會采用企業(yè)內(nèi)部通信協(xié)議，這與轎車行業(yè)的情形相似。而在北美市場，SAE J1939在重卡領(lǐng)域占據(jù)主導(dǎo)地位。在車載診斷領(lǐng)域也有不同：在歐洲，通過UDS(ISO15765)實現(xiàn)OBD診斷，而美在國則通過SAE J1939-73來實現(xiàn)。

通過不同方法實現(xiàn)目標

MAN商用車輛股份公司采用的是集成的研發(fā)數(shù)據(jù)庫。這個數(shù)據(jù)庫被稱為“通用工程數(shù)據(jù)核心系統(tǒng)”。所有車輛特定的功能都在這個平臺上開發(fā)，所有車輛特定的信息也都存儲在這里。具有8個終端的Vector的eASEE工具鏈作為統(tǒng)一的研發(fā)數(shù)據(jù)庫管理工具，非常適合MAN公司的配置過程構(gòu)架的需求(圖1)。它滿足了功能開發(fā)以及描述了通信矩陣。由于MAN公司要求在通信方面盡可能的符合SAE J1939標準，所以eASEE工具也適合于J1939協(xié)議的需求。

圖1：MAN公司的工程數(shù)據(jù)核心系統(tǒng)

Vector專為MAN公司開發(fā)了一個特殊的模塊，以適應(yīng)MAN公司的數(shù)據(jù)核心系統(tǒng)，并在eASEE建模和ECU自動代碼生成之間充當橋梁作用(圖2)。在代碼生成方面，慕尼黑的重型車輛生產(chǎn)商采用的是經(jīng)過驗證的Vector的CANbedded.J1939標準軟件組件。CANbedded.J1939直接從數(shù)據(jù)庫獲取所需的所有配置信息，并在不需要人工干涉的情況下自動生成嵌入式代碼。這使從模型改變到ECU代碼實現(xiàn)的迅速轉(zhuǎn)換成為可能。這個過程避免由于代碼生成工具的錯誤配置而引入錯誤，并保證正確、完成地生成代碼。因為軟件的每一段都已經(jīng)被檢查過了，這個過程也簡化了整個系統(tǒng)的驗證工作。也可以在應(yīng)用層開發(fā)工具中重新使用這些通信數(shù)據(jù)來進行測試，像Vector的分析工具CANalyzer.J1939或者測試工具CANoe.J1939等。

圖 2: 基于eASEE功能數(shù)據(jù)管理所描述的電子架構(gòu)信息生成ECU代碼

Volvo 卡車公司選擇了一種軟件開發(fā)策略，這個策略也已經(jīng)在轎車領(lǐng)域開始應(yīng)用，就是AUTOSAR及相關(guān)工具(如圖3)。這種方法的優(yōu)勢是標準的、成熟的工具的使用。他們從不同供應(yīng)商的不同品牌的ECU的集成開發(fā)中獲得了好處。底層的軟件結(jié)構(gòu)和構(gòu)架能夠很快被理解，集成各供應(yīng)商產(chǎn)品變得更容易，而且也不需要特意的指定使用某個工具，這就減少了對個別工具生廠商和供應(yīng)商的依賴。

圖 3: 當使用了標準化的數(shù)據(jù)格式，即可使用標準的工具來描述和生成ECU功能軟件

這種策略所遇到的問題是通信方法的使用：要么與AUTOSAR特性不兼容，要么只能以某種特殊的方法來使用。在這篇文章中特別要提到的是J1939使用。 AUTOSAR事實上假定網(wǎng)絡(luò)上的節(jié)點是預(yù)先知道的，因此在集成時，通信矩陣是確定的，這就不能滿足J1939的即插即用的概念。面對這個問題，Volvo卡車采用了兩種方案。一是確認Volvo卡車中使用了J1939的那些部分，并且把他們集成到已有的Vector AUTOSAR工具鏈中。其次，Volvo和Vector，與其他的歐洲卡車生產(chǎn)商一起，將部分J1939協(xié)議引入到AUTOSAR規(guī)范中。這種策略讓 Volvo直接從AUTOSAR中獲得了優(yōu)勢。另一方面，將J1939集成到AUTOSAR中，使得在工具選擇上做到基本獨立成為可能。Volvo選擇 Vector作為他的工具和嵌入式軟件組件供應(yīng)商，是因為Vector在所有領(lǐng)域提供了解決方案，并且可以很靈活的改變，以滿足Volvo的具體需求。