首页- 新闻中心- 正文

浅谈重型车辆的网络开发趋势

来源:芯片解密-龙芯世纪   时间:2009-09-10   阅读:1609

  重型车辆在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代码
  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的具体需求。