自从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公司的工程数据核心系统
图 2: 基于eASEE功能数据管理所描述的电子架构信息生成ECU代码
Figure 3: 当使用了标准化的数据格式,即可使用标准的工具来描述和生成ECU功能软件
参考文献:
[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)
上一篇:汽车电子诊断服务的自动验证
下一篇:利用FPGA新特性实现高可靠性汽车系统设计
推荐阅读最新更新时间:2024-05-02 22:53