目前有很多汽车软件工具都能够在其特定专业领域提供非常优质的功能和特性。在实际工作中,某些ECU的测试常常需要多种专业工具协同工作来搭建一个高效的测试环境。但大部分的测试工具往往只是单个孤立的程序,不支持与其他工具交互或是只开放了有限的功能。因此为了满足多工具集成测试系统的需求,每一个集成到系统中的工具都需要能够提供足够的接口来实现其与测试环境的交互。
本文将从集成测试系统对工具接口的需求出发,介绍目前常用的集成解决方案,以及几种CANoe支持的接口技术和可行的集成方法。
在汽车电子领域的开发和E/E系统测试过程中,相关工程师会面临到越来越多的需要协同工作的软件工具。比如在自动驾驶以及相关ADAS系统领域中,就需要多个工具共同工作以满足需求,不同的工具可能来自不同的供应商,用来实现特定领域的高度专业化功能。如图一所示,工具1实现通信网络的残余总线仿真;工具2和3搭建车辆动力学和环境模型;工具4将虚拟驾驶场景输入到仿真环境中;工具5则负责实现自动化测试,此外该系统还可能需要包含有与测试数据管理模块的连接,并且所有的工具都必须耦合在一起形成一个可执行的集成测试环境。
图1
为了搭建这样一个集成测试环境来连接不同的工具,比较容易想到的解决方案就是针对项目设计专用集成方案,这种方法的优点是实现过程完全由工程师操控,灵活度就非常高。但缺点也非常明显:一是复用性较差,因为解决方案一般都基于特定的项目,对其他项目不一定适用;二是交接困难,如果关键人物离开或者项目进行交接,学习成本和使用成本就会大大增加。此外,如果其中一个供应商改变了其工具接口或者接口行为,后期的维护也会比较困难。这些缺点也解释了为什么现在我们的集成测试环境更倾向于使用标准化的接口。
因为标准接口不会轻易改变,使用标准接口的方案就具有很高的复用性;虽然有些标准接口也存在扩展的可能性,但一般都会确保版本间的兼容,这样方案的维护成本就可以控制。标准接口的另一个优点是连接到标准接口的操作通常可以通过配置实现,而连接到专有接口则往往需要编程。但标准接口有时并不能覆盖所有期望的功能。因此,现在集成测试系统经常会使用一种混合解决方案:大部分工具间的连接由标准接口实现,针对其余的需求再进行专门的开发工作。
但不论采取何种解决方案,为了确保项目的有效实施,集成到系统中的任何软件都需要有足够全面的接口,方便其与系统环境进行数据或模型等交互。
Functional Mock-up Interface(FMI)
FMI是汽车设计和仿真领域中较常使用的一个标准接口。一般而言,FMI独立于软件,使用的模型可以来自不同的工具或软件;基于FMI接口协议封装的模型称为FMU。FMI接口数据的描述和接口功能是分离的,这意味着模型可以作为一个黑盒共享使用。FMI标准支持两种模式,模型交换(ME)和协同仿真(CS)。在ME模式下,FMU提供输入,输出和内部状态,求解器则由外部提供。在CS模式下,FMU中已经包含有求解器算法,导入工具不需要了解模型的任何内部细节,模型的输出自会根据输入和底层求解器计算得到。
FMI标准描述了模型的输入,输出,内部参数以及可能用于模型仿真步骤计算的步进函数。不同的工具之间可以通过FMI实现单纯的模型交换,还可以彼此耦合协同工作。但是FMI标准中没有关于进行实际数据交换的基础设施或传输协议的描述,那么如何才能把CANoe这种开发和测试中广泛使用的工具连接到其他系统呢?
一个CANoe工程中通常会包含有残余总线仿真模块以及自动化测试模块。仿真和测试都在同一进程中执行,因此也会基于相同的时基同步。自动化测试模块执行基于网络层或者ECU I/O相关的功能测试;另一方面,残余总线仿真模块由模拟的网络节点组成,通过交互层来实现整个网络通信模型的搭建。残余总线仿真可以包含有多个相同的网络,也可以包含有多种不同类型的网络,如CAN,LIN,FlexRay和Ethernet等,不同网络可以通过网关节点进行关联。实现多总线分析仿真和测试,同时保证多通道间时间同步是CANoe的一大功能。在此基础上,CANoe可以导出定义了相关交互数据的FMU(如图2)。在这个过程中,应该对导出的数据进行筛选。例如一些周期报文中的信号可能仅仅用来保持ECU唤醒状态,对应用来说并不是必须的,就不需要导出。在CANoe中,FMU通过简单的配置就可以导出,不需要做额外的手动调整或编程工作。
图2
Fast Data Exchange (FDX)
如前文所述,FMI标准不描述用于实际数据交互的基础设施或具体的传输协议。在技术实施层面上,CANoe提供了通过以太网进行快速数据交换(FDX)的接口,FDX基于以太网传输UDP数据。FDX接口协议是开放的,用户可以用来连接不同的组件和子系统,如测试台架等。由于UDP使用非常普遍,CANoe可以使用FDX与大量不同的系统耦合,但FDX高度灵活性带来的一个缺点是用户必须自己来配置实现远程节点。如图3所示,在CANoe中FMI的集成可以通过使用FDX作为传输介质实现CANoe与其他工具间的数据交换,但从用户角度来说,FDX是完全隐藏的不需要过度关注,并且导出FMU也只需要做些简单的配置而不需要额外编程,使用就非常便捷。由于FDX是基于UDP工作的,所以从CANoe导出的FMU也可以在非Windows系统上进行。除了通过FDX进行数据传输,CANoe和FMU之间另外建立了一个专用的TCP/IP连接,该连接起到一个控制通道的作用,通过这个连接可以控制仿真的启动和停止。
由于加载FMU的系统和CANoe基于不同的时基运行,因此CANoe和FMU之间需要进行仿真时间同步。对于CANoe来说,只有工作在Simulated模式下,才能进行仿真时间的同步,在这种情况下,仿真时间基于外部软件时基。相反的,当CANoe工作在RealBus模式下,它的仿真时间会独立于FMU模型的仿真时间。
除去残余总线仿真,CANoe还执行自动测试的功能。当与其他工具或者测试平台联合使用时,需要考虑将哪个工具作为测试的Master。如果CANoe是工作在RealBus模式下,即与真实总线网络连接,那么它通常也将会作为Master。
图3
ASAM XIL API
XIL API主要是为自动化测试环境提供了一个额外的接口。该接口标准由ASAM[1]组织从目前主流的仿真和测试工具中提取出来并进行标准化定义。以CANoe软件为例,测试运行控制和测试执行的分离意味着CANoe可以作为一个执行测试的实例由第三方软件进行远程控制,或者作为一个主导者远程控制其他测试执行工具(图4)。XIL API同样支持耦合来自不同制造商的工具,在集成系统中,XIL API需要访问各种不同的端口,其中最重要的一个端口是模型访问端口——MA,它提供对模型的读写访问服务,包括记录仿真数据、创建用于仿真的信号发生器、定义触发器、错误处理以及提供仿真控制的方法。
XIL API基于.NET平台,因此满足某些实时需求的能力将取决于具体的实现方式。在XIL API接口的实现中,CANoe使用上文提到的基于UDP的FDX接口进行数据传输。这样的数据传输可以保证测试系统具有较高的实时性性能,至少是能够胜任两个系统间专用以太网连接通信,即使是一对一的千兆以太网通信,其性能也能符合大多数应用程序的要求。
图4
Component Object Model (COM)
最后,我们谈一下微软的COM接口。尽管由于Windows调度的影响,COM不适合在仿真过程中进行数据交换,但其在工具配置以及运行控制方面功能非常强大。通过COM可以对大量使用用户界面进行交互操作的功能进行远程控制或者自动控制。
为了实现一个完全自动化的测试或者仿真序列,用户往往需要组合使用不同的接口,通常可以用COM来进行配置准备工作和序列控制,用FDX来实现系统运行时仿真数据的交换。CANoe中也提供丰富的COM接口以供外部工具调用。
展望
需要指出的是,使用标准接口也可能无法提供完整的解决方案。尽管模型可以通过FMI整合,CANoe也可以通过使用FMU输出功能与其他工具连接,但整个系统可能会缺少控制和配置整个系统的接口。另外一个问题是时间同步问题:在分布式系统中哪个模块来提供时基;该模块的时间又是怎么获取的;单个模块如何与系统的全局时间同步;仿真模块如何与真实模块耦合同步?ACOSAR项目对这些问题进行了研究,并于2018年8月发布了API相关规范[2]。
关于工具耦合的进一步建议
CANoe中oe两个字母是”Open Environment”的缩写,表示CANoe软件支持大量不同的应用程序选项和接口,本文中所提到的示例只是其中很少的一部分。除上述示例外CANoe还提供了很多与其他工具联合使用的方法:比如CANoe可以导入其他工具相关的共享变量,实现通过Ethernet与该工具系统交换数据的目的;CANoe的集成功能可以将Simulink模型集成到CANoe的MIL或者HIL环境中。因此我们建议用户在着手其项目开发之前查阅下CANoe相关的文档,CANoe可能已经提供了能够解决您手头问题的适当的工具。
在集成测试项目中,用户通过使用标准化的接口可以提高新版本工具的稳定性及复用性。