|
CANopen已经在很多对成本敏感且要求灵活组网的应用领域（从工业自动化到商用汽车）成为了总线通信标准。CANopen标准的设备子协议，简化了总线节点之间的通信，同时使来自不同厂商的ECU、传感器和执行器能够轻松实现互连。一个专业的原型建模及测试工具不仅能服务于复杂CANopen项目的工程开发 ，还能为工程师提供此领域的相关基础知识。
开发一个CANopen网络系统，其任务范围从开发各个单ECU到整个网络能够运行起来。对于系统开发商而言，如果从一开始就采用CANopen系统，则为整个系统开发工作开了个无法估量的好头。在系统开发的V模式流程中，“验证和确认”占了很大一部分工作。因此，尽可能早地进行全面的测试工作，可大大减少因为太晚发现错误而带来的风险。V模式开发流程如图1所示： （图片）
图1 V-模式开发流程 通过测试装置进行系统验证
系统开发过程中的系统化测试在所有开发步骤中是不可或缺的。但一般都要等到很晚，即获得真实的系统组件后，才能进行测试。如果出现问题，则系统完成的时间会面临风险。
实际上，测试一般都不在真实的系统上进行，取而代之的是使用测试装置，在模拟的测试环境下进行。除了有专门的测量和诊断装置外，还包括各种执行器，以尽可能的模仿切合实际的系统环境。根据不同的项目规模，这样的测试装置可能会花费很大的成本及劳力。这种测试装置的瓶颈在于如何将以上各种因素集成到各个测试环节之中。因为往往只能有一个测试设置可以起作用。
有一种方法可以摆脱这种窘境，那就是借助软件工具，在软件环境下搭建整个系统的原型。借助软件工具还具备一个优点是，软件工具同时还提供测试的测试功能。
借助软件工具创建系统原型环境
一个CAN网络系统的原型起码应支持测试及验证。此外，另一个重点是系统原型里的各个单独组件可以被真实的或模拟的ECU取代。利用这种方式，在系统开发的过程中，就可以比较容易地测试各个真实ECU的功能及性能。创建一个复杂系统的原型，需要借助合适的工具且要通过复杂的尝试。Vector公司提供的CANoe.CANopen在创建系统原型通信方面提供了有效的帮助。仅需通过短短几个配置步骤，就可让用户创建一个系统原型，其通信性能完全符合真实的系统。
CANopen网络中各ECU的行为通过描述文件（EDS-电子数据表格）定义，这些描述文件需要事先选择或创建好。接下来，需要定义将来会通过总线进行数据交换的的各数据间的相互关系，例如：某个CANopen网络上节点地址是5的设备（压力传感器），其输入值“压力”被链接到节点地址是10的设备（控制模块）的“气压”变量上。这些工作即是定义系统原型里所有PDO（进程数据对象）的相互关系。
配置工具会自动计算这些PDO的映射关系，这些映射关系如果有必要的话在以后还可以修改。所有配置都做好之后，配置工具的输出是设备配置信息DCF（DCF-设备配置文件），根据这个配置信息，用户就可以生成原型环境了，如，CANoe可以生成与各个真实ECU对应相同的通信属性。只要运行CANoe，整个原型环境的通信部分功能就已经具备了。如图2所示：（图片）
图2 一个简单的模拟的由中央控制和I/O节点组成的CANopen网络 定义应用程序行为
每一个单独ECU的应用程序行为都不可能直接从EDS文件中派生出来，因为EDS文件只是映射每一个对象字典的结构。因此，制定应用层程序行为总是涉及额外的编程工作。借助于CANoe环境里的CAPL编程语言，可以快速地实现ECU行为编程。此外，还可以将ECU行为编写成DLL文件，并在CANoe中引用，同样可以轻松集成Matlab/Simulink模型。如图3所示：（图片）
图3 CANoe.CANopen环境示意图 测试功能
当系统原型建立之后，需要对整个工程进行必要的测试。CANoe支持用户在它的环境下创建测试序列、测试过程记录及测试结果评估。一个CANopen系统的测试功能由以下几个等级构成：见图4所示。
协议级
通过协议级的测试，保证各个基于CANopen通信子协议的设备，可按照CANopen规范集成到整个系统里。
通信级
通信级测试重要的不是保证协议的正确，而是保证协议序列正确的逻辑顺序，如PDO的配置。对象字典里PDO相关入口描述必须要符合特定的顺序。
应用程序级
应用程序级测试用于检查过程变量之间的相互关系。下面的几个前提条件必须满足，甚至决定了相互关系：首先，过程变量交换必须使用PDO，因此，系统必须充分配置。这就意味着，例如，某个阀门的状态可以根据温度或压力的值来检测。显然，用户必须要有相关的know-how去制定测试。（图片）
图4 CANopen里的测试级别 用CANoe创建和执行测试流程
测试序列可借助集成于CANoe环境的CAPL编程语言来制定，每个CAPL测试模块代表一个单独的测试，每一个单独的测试有多个测试案例，这些测试案例又可能包含多个测试步骤。当测试运行时，CANoe按顺序调用各个测试案例。适当的测试流程控制可选择性的跳过或重复某个测试。同时，在后台监测此步骤与其他约束条件的一致性状态。例如，当CANoe正在等待某一个特定信息的同时时，又可以检测看是否有某个特定的其它报文被定期地发送到总线上。
特别是在自动化测试时，重要的是需要详细记录每一个测试步骤的结果。CAPL程序里的其它函数用于处理将测试结果写到XML文件，用于事后处理。CANoe的测试序列也可以通过XML语言实现。这在需要通过单个工具生成大量的测试流程时是非常有利的。因此，CANoe在XML中实现了一系列的测试模式，并能够进行相应的处理。
总结
创建CANopen网络的原型，总是需要花费相当大的劳力。然而，这一过程往往又是至关重要的，可以防止在项目的后期才发现功能性错误。用户借助CANoe.CANopen可以高效地创建系统原型，同时，可以很容易地满足在通信方面的技术要求。在项目的各个阶段，网络原型为系统开发商提供了及时检查和验证组件完整性所需的测试功能。
3/26/2009
| 
