重型車輛在ECU網絡開發方面面臨著與轎車相同的挑戰,而型號多、低產量、生命周期長、需要適當的結構層次等因素，又帶來了額外的困難。因此必須要有專門為重型車而改進的開發方法，來應對成本壓力和確保產品可靠上市。
自從20世紀90年代電子技術開始應用到車輛上，ECU的數量以及軟件的數量就開始成倍增加。最初涉及的只是發動機控制器，現在大量的電子“助手”正在應用，這些例子包括ABS、ESP、ACC以及其他的駕駛輔助系統等，這些都使駕駛車輛更加安全、舒適。文獻【1】設想了電子設備的應用會進一步增加，到2010年，電子控制模塊將在所有創新技術中占到90%。關鍵的一點是這些創新的80%是由軟件或軟件所實現的功能構成的。在這篇文章中，可以很清楚的看出，在整車開發過程中，軟件開發方法起著至關重要的作用，他們對車輛的成功上市產生著重要的影響。
與轎車相比，重型車輛生產商面臨著特別巨大的挑戰，那就是改型多且產量低。盡管不同品牌車輛同時使用相同的ECU，以及集成標準的組件能夠減少成本壓力，以上因素仍會導致電子和軟件的設計更加復雜。
需求靈活的解決方案
只要考慮到不同重型車生產商會采用不同的開發策略時，就會意識到沒有通用的解決方案。然而，因為ECU的數量增加的速度相對緩慢，而純粹軟件功能的增加卻相當快。因此，從全局的角度考慮，參照標準、使用代碼生成工具以及通用的工具鏈肯定是一種趨勢。
通用的解決方案就是從需求到驗證的各階段，使用全面且統一的工具鏈。像過去一樣使用獨立的、非通用的工具被證明是不切實際的。各種工具的配置過程和生成成果差異很大。這導致開發過程中需求改變時，工具之間難以達成一致。因此需要在不同的工具中修改配置來滿足一個需求的改變，而不會自動完成，也沒有工具間的一致性檢測能力。這給整個組織帶來很大麻煩，尤其是部門之間或者項目之間。
因此，一個數據庫及其開發工具應該作為整個工具鏈的核心。數據庫及其開發工具都需要適應整車廠的特殊需求。除了純粹的技術方面，工具也應該考慮公司的開發過程。變更管理、配置管理、甚至工作流程的維護都應該在工具里體現。如果外部供應商需要集成到這個過程中，就需要考慮數據交換格式，可以是某個標準或者事實上的工業標準，例如Vector的CANdb++數據格式。在一些情況下，整車廠也給他的供應商指定了具體的工具，然后基于數據庫與供應商進行協作，并在符合需求、提高質量和效率等方面更好的幫助供應商。這方面的例子包括：嵌入式系統代碼生成或者測試工具，例如Vector提供的CANoe.J1939 開發和測試工具。
網絡功能需求的增長使系統設計變得更加復雜，不同的ECU正在應用到不同的平臺以及不同的國家，這大大增加了改型的數量。這就要求通信構架以及ECU間的信號映射關系具有靈活性。這不僅影響了可用的信號，也影響了通信協議的使用。例如，在歐洲，通常會采用企業內部通信協議，這與轎車行業的情形相似。而在北美市場，SAE J1939在重卡領域占據主導地位。在車載診斷領域也有不同：在歐洲，通過UDS（ISO15765）實現OBD診斷，而美在國則通過SAE J1939-73來實現。
通過不同方法實現目標
MAN商用車輛股份公司采用的是集成的研發數據庫。這個數據庫被稱為“通用工程數據核心系統”。所有車輛特定的功能都在這個平臺上開發，所有車輛特定的信息也都存儲在這里。具有8個終端的Vector的eASEE工具鏈作為統一的研發數據庫管理工具，非常適合MAN公司的配置過程構架的需求（圖1）。它滿足了功能開發以及描述了通信矩陣。由于MAN公司要求在通信方面盡可能的符合SAE J1939標準，所以eASEE工具也適合于J1939協議的需求。
圖1：MAN公司的工程數據核心系統
Vector專為MAN公司開發了一個特殊的模塊，以適應MAN公司的數據核心系統，并在eASEE建模和ECU自動代碼生成之間充當橋梁作用（圖2）。在代碼生成方面，慕尼黑的重型車輛生產商采用的是經過驗證的Vector的CANbedded.J1939標準軟件組件。CANbedded.J1939直接從數據庫獲取所需的所有配置信息，并在不需要人工干涉的情況下自動生成嵌入式代碼。這使從模型改變到ECU代碼實現的迅速轉換成為可能。這個過程避免由于代碼生成工具的錯誤配置而引入錯誤，并保證正確、完成地生成代碼。因為軟件的每一段都已經被檢查過了，這個過程也簡化了整個系統的驗證工作。也可以在應用層開發工具中重新使用這些通信數據來進行測試，像Vector的分析工具CANalyzer.J1939或者測試工具CANoe.J1939等。
圖 2: 基于eASEE功能數據管理所描述的電子架構信息生成ECU代碼
Volvo 卡車公司選擇了一種軟件開發策略，這個策略也已經在轎車領域開始應用，就是AUTOSAR及相關工具（如圖3）。這種方法的優勢是標準的、成熟的工具的使用。他們從不同供應商的不同品牌的ECU的集成開發中獲得了好處。底層的軟件結構和構架能夠很快被理解，集成各供應商產品變得更容易，而且也不需要特意的指定使用某個工具，這就減少了對個別工具生廠商和供應商的依賴。
圖 3: 當使用了標準化的數據格式，即可使用標準的工具來描述和生成ECU功能軟件
這種策略所遇到的問題是通信方法的使用：要么與AUTOSAR特性不兼容，要么只能以某種特殊的方法來使用。在這篇文章中特別要提到的是J1939使用。 AUTOSAR事實上假定網絡上的節點是預先知道的，因此在集成時，通信矩陣是確定的，這就不能滿足J1939的即插即用的概念。面對這個問題，Volvo卡車采用了兩種方案。一是確認Volvo卡車中使用了J1939的那些部分，并且把他們集成到已有的Vector AUTOSAR工具鏈中。其次，Volvo和Vector，與其他的歐洲卡車生產商一起，將部分J1939協議引入到AUTOSAR規范中。這種策略讓 Volvo直接從AUTOSAR中獲得了優勢。另一方面，將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]