重型车辆的网络开发趋势--电子系统开发的成功要素

重型车辆在ECU网络开发方面面临着与轿车相同的挑战,而型号多、低产量、生命周期长、需要适当的结构层次等因素，又带来了额外的困难。因此必须要有专门为重型车而改进的开发方法，来应对成本压力和确保产品可靠上市。

自从20世纪90年代电子技术开始应用到车辆上，ECU的数量以及软件的数量就开始成倍增加。最初涉及的只是发动机控制器，现在大量的电子“助手”正在应用，这些例子包括ABS、ESP、ACC以及其他的驾驶辅助系统等，这些都使驾驶车辆更加安全、舒适。文献设想了电子设备的应用会进一步增加，到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代码