新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設計應用 > 重型車輛的網(wǎng)絡開發(fā)趨勢--電子系統(tǒng)開發(fā)的成功要素

重型車輛的網(wǎng)絡開發(fā)趨勢--電子系統(tǒng)開發(fā)的成功要素

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

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

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

newmaker.com

需求靈活的解決方案

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

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

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

網(wǎng)絡功能需求的增長使系統(tǒng)設計變得更加復雜，不同的ECU正在應用到不同的平臺以及不同的國家，這大大增加了改型的數(shù)量。這就要求通信構架以及ECU間的信號映射關系具有靈活性。這不僅影響了可用的信號，也影響了通信協(xié)議的使用。例如，在歐洲，通常會采用企業(yè)內部通信協(xié)議，這與轎車行業(yè)的情形相似。而在北美市場，SAE J1939在重卡領域占據(jù)主導地位。在車載診斷領域也有不同：在歐洲，通過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公司的配置過程構架的需求（圖1）。它滿足了功能開發(fā)以及描述了通信矩陣。由于MAN公司要求在通信方面盡可能的符合SAE J1939標準，所以eASEE工具也適合于J1939協(xié)議的需求。

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

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

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

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

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

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

參考文獻:
[1] J. Svensson, “The Use of AUTOSAR in Volvo Group”, presentation at Vector J1939 User Day;slides may be downloaded at: www.vector-informatik.de/j1939ud [most of them are German](end)

評論


技術專區(qū)

關閉