CANopen系统的原型开发和测试.docVIP

CANopen系统的原型开发和测试 遵循V模式的大多数的开发任务可归结于测试和验证。全面的测试可以帮助开发人员尽可能早的发现并排除错误。CANopen系统开发中涉及的任务范围包括从单个ECU的开发到整个系统的配置和启动。一个比较可取的做法是使用经过验证的工具，这样能充分利用CANopen的灵活性。同时，开发人员不必关心单个ECU的协议功能实现。在整个系统开发过程的每个阶段都必须有相应的测试工作。实际上，初始测试不是在第一级客户的真实系统上完成的，而是使用一个包含有所有组成最终系统的组件的测试台进行测试。该测试台同时也包括特殊的测量、测试诊断设备、执行器，尽可能使测试系统环境与真实系统一致。当系统的规模较大时，构建这样一个测试台也许是非常困难的，而且成本很高，通常情况下只能实现一个单独的测试台。在大多数情况下，这将成为测试过程中的一个瓶颈。 解决这一问题的出路在于使用一种成熟的，能容易实现整个系统原型的工具。该工具将提供测试功能的理想的解决方案。 原型环境 首先并且首要的，整个系统的原型CAN网络应该支持测试和验证。此外，该原型还应该提供早期项目开发功能。因此，用真实的ECU或仿真ECU表示整个系统中的各个独立组件这一过程是非常重要的。这样可以相对简单的在系统开发过程中测试真实ECU的功能完整性。因此原型环境的功能性要求比纯仿真要多得多。仿真一个复杂系统是成本很高的，而且工作量很大。合适的工具可以大大简化这一任务。Vector Informatik 公司的CANoe. CANopen产品能真正支持用户建立系统原型的通信部分。只需要几个简单的配置步骤就可以创建一个原型系统，其通信功能与真实系统完全相同。首先，为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系统的测试功能需求包含以下几个等级： 协议层：一个例子是依据CiA e.V的规范对SDO协议的测试。这个例子中，包括了对被测设备(DUT- device under test)发送请求，对接受到的响应作出评估。不管在系统的独立设备中是否实现了基于CANopen的通信协议都可以对其进行测试。 通信层： 不在此处测试协议的正确性，而是对(独立的)协议顺序的逻辑流进行了验证，如对PDO的配置。在PDO测试的例子中，在对象目录中的PDO相关的实体必须按指定的顺序书写。在好的测试案例下，能检测到遵循这一顺序；在坏的测试案例下，错误的顺序将表现在被测设备的响应中。创建这一测试需要彻底理解CANopen的细节，最主要的是理解所使用的不同通信机制之间的相互关系。 应用层： 应用层的测试会检查过程变量之间的关系。要证实变量之间的关系，必须满足如下先决条件：过程变量必须能与PDO发生交换，系统必须完全可配置。例如，在测试时，阀的状态可被看作温度或压力的函数。这一例子说明用户必须能清楚地描述测试。 测试过程 使用CANoe工具，借助于集成的CAPL编程语言可以准确描述测试过程。开发者使用CAPL语言可准确描述对复杂的通信系统的相当灵活的测试过程。每个CAPL测试模块是一个包含许多独立测试用例的独立测试。每个测试用例又包含了