重型车辆在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]