CANopen系统的原型开发和测试

　　遵循V模式的大多数的开发任务可归结于测试和验证。全面的测试可以帮助开发人员尽可能早的发现并排除错误。

　　CANopen系统开发中涉及的任务范围包括从单个ECU的开发到整个系统的配置和启动。一个比较可取的做法是使用经过验证的工具，这样能充分利用CANopen的灵活性。同时，开发人员不必关心单个ECU的协议功能实现。

　　在整个系统开发过程的每个阶段都必须有相应的测试工作。实际上，初始测试不是在第一级客户的真实系统上完成的，而是使用一个包含有所有组成最终系统的组件的测试台进行测试。该测试台同时也包括特殊的测量、测试诊断设备、执行器，尽可能使测试系统环境与真实系统一致。当系统的规模较大时，构建这样一个测试台也许是非常困难的，而且成本很高，通常情况下只能实现一个单独的测试台。在大多数情况下，这将成为测试过程中的一个瓶颈。

　　解决这一问题的出路在于使用一种成熟的，能容易实现整个系统原型的工具。该工具将提供测试功能的理想的解决方案。

原型环境

　　首先并且首要的，整个系统的原型CAN网络应该支持测试和验证。此外，该原型还应该提供早期项目开发功能。因此，用真实的ECU或仿真ECU表示整个系统中的各个独立组件这一过程是非常重要的。这样可以相对简单的在系统开发过程中测试真实ECU的功能完整性。因此原型环境的功能性要求比纯仿真要多得多。

                  
　　仿真一个复杂系统是成本很高的，而且工作量很大。合适的工具可以大大简化这一任务。Vector Informatik 公司的CANoe. CANopen产品能真正支持用户建立系统原型的通信部分。只需要几个简单的配置步骤就可以创建一个原型系统，其通信功能与真实系统完全相同。[page]

　　首先，为CANopen ECU选择一个EDS(Electronic Data Sheet)描述文件。如果该设备的描述文件不存在，是因为设备开发过程尚未结束，将使用一个空模板占位。

　　下一步，在总线上交互的应用程序数据被关联起来。例如，位于5#地址设备的输入“PressureValve” 与10#地址设备的变量 “GasPressure“相关联。用这样的方法定义原型系统的所有的过程数据对象( Process Data Object)连接。CANopen可以自动计算映射关系，并可以在随后修改。

　　下一步，所有原型系统的配置信息都存放于设备配置文件(DCF – Device Configuration File).中。用户可以利用这些配置文件来创建一个原型环境。对于每个真实系统中的ECU都生成一个具有相同通信属性的CANoe中的副本。

　　原型环境的通信部分在CANoe工具启动时生效。通过服务数据对象(SDO=Service Data Objects)可以访问（仿真）ECU的目标目录；可以对这些目录作额外的修改。

应用表现

　　系统中独立ECU的应用表现是另一个原型阶段感兴趣的内容。不能从EDS文件中导出ECU的应用表现，因为EDS文件只是表示了目标目录的框架。通常应用表现的构建是另外编程实现的。

　　集成了CAPL编程语言的软件工具CANoe可以非常容易地描述ECU的表现。也可以用DLL描述ECU的表现。DLL用C/C++编写，并链接到原型环境。CANoe也可以与Matlab/Simulink很好的集成。

　　根据需求等级不断细化，原型将越来越优化。完成了原型系统后，需要对整个系统进行测试。在这一环节，软件工具CANoe将提供测试创建、评估和记录。CANopen系统的测试功能需求包含以下几个等级：

协议层：

[page]

　　一个例子是依据CiA e.V的规范对SDO协议的测试。这个例子中，包括了对被测设备(DUT- device under test)发送请求，对接受到的响应作出评估。不管在系统的独立设备中是否实现了基于CANopen的通信协议都可以对其进行测试。
通信层：

　　不在此处测试协议的正确性，而是对(独立的)协议顺序的逻辑流进行了验证，如对PDO的配置。在 PDO测试的例子中，在对象目录中的PDO相关的实体必须按指定的顺序书写。在好的测试案例下，能检测到遵循这一顺序；在坏的测试案例下，错误的顺序将表现在被测设备的响应中。创建这一测试需要彻底理解CANopen的细节，最主要的是理解所使用的不同通信机制之间的相互关系。
应用层：

　　应用层的测试会检查过程变量之间的关系。要证实变量之间的关系，必须满足如下先决条件：过程变量必须能与PDO发生交换，系统必须完全可配置。例如，在测试时，阀的状态可被看作温度或压力的函数。这一例子说明用户必须能清楚地描述测试。

测试过程

　　使用CANoe工具，借助于集成的CAPL编程语言可以准确描述测试过程。开发者使用CAPL语言可准确描述对复杂的通信系统的相当灵活的测试过程。每个CAPL测试模块是一个包含许多独立测试用例的独立测试。每个测试用例又包含了许多测试步。在测试执行时，CANoe工具可依次运行各个测试用例。合适的测试流程控制可以跳过或重复某些测试。这样可实现动态测试功能。

　　借助预先定义的CAPL函数能大大简化产生测试用例的过程。一个典型的测试顺序可能具有这样的结构：先仿真被测设备，测试人员等待其响应，然后做出评估。CAPL提供了很多测试流程与事件同步的函数，比如接受一个特定的消息或者一个改变了的（可能通过COM修改）环境变量的值。与此同时，能在类似的后台监控到其它条件或约束的实现。如果在等待某个特定报文的过程中，用户希望检查此总线上是否还在周期性发送另一不同报文，这一功能就很有用。

　　尤其是建立自动执行的测试时，对每个独立的测试步结果的详细数据记录是非常重要的。另外的CAPL函数可用于将结果写入XML文件作后处理，也可以写入HTML文件做直接评估。CANoe工具的测试过程也可以由XML文件指定。如果能通过同一工具生成许多类似的测试过程，是更受欢迎的。CANoe工具提供了大量的XML格式的测试模板并能非常合适地使用。

总结

　　CANopen网络系统的原型开发总是有许多重要的工作要做。不管怎样，为了不需要等到项目阶段的后期才能得到关于功能和系统性能的结论，原型设计经常是至关重要的。用户通过专用工具创建原型并得到支持，尤其能很容易实现对技术通信需求的覆盖。 CANoe工具的测试功能让系统开发人员在项目的每个阶段都能进行验证工作，直至最终得到完美的系统。