重型車(chē)輛的網(wǎng)絡(luò )開(kāi)發(fā)趨勢

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

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

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

需求靈活的解決方案

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

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

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

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

通過(guò)不同方法實(shí)現目標

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

圖1：MAN公司的工程數據核心系統

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

圖 2: 基于eASEE功能數據管理所描述的電子架構信息生成ECU代碼

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

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

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