CANopen系统的原型开发和测试

CANopen系统的原型开发和测试遵循v模式的大多数的开发任务可归结于测试和验证。全面的测试可以帮助开发人员 尽可能早的发现并排除错误。CANopen系统开发中涉及的任务范围包括从单个ECU的开发到整个系统的配置和启 动。一个比较可取的做法是使用经过验证的工具，这样能充分利用CANopen的灵活性。同 时，开发人员不必关心单个ECU的协议功能实现。在整个系统开发过程的每个阶段都必须有相应的测试工作。实际上，初始测试不是在第 一级客户的真实系统上完成的，而是使用一个包含有所有组成最终系统的组件的测试台进行 测试。该测试台同时也包括特殊的测量、测试诊断设备、执行器，尽可能使测试系统环境与 真实系统一致。当系统的规模较大时，构建这样一个测试台也许是非常困难的，而且成本很 高，通常情况下只能实现一个单独的测试台。在大多数情况下，这将成为测试过程中的一个 瓶颈。解决这一问题的出路在于使用一种成熟的，能容易实现整个系统原型的工具。该工具将提供 测试功能的理想的解决方案。.二 |Fig. 2; CANoCANopen 帥Ep丿日 configuration for 3 imu- Isted CANopen network原型环境首先并且首要的，整个系统的原型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将提供测试创建、评估和记录o CANopen系统的测试 功能需求包含以下几个等级：阳协议层：miiugi1wrriupdattiHi5. m關期卄如WQ二 CANopdf! t&st i&veiS一个例子是依据CiA e.V的规范对协议的测试。这个例子中，包括了对被测设备（DUT- device under test）发送请求，对接受到的响应作出评估。不管在系统的独立设备中是否 实现了基于CANopen的通信协议都可以对其进行测试。通信层：不在此处测试协议的正确性，而是对（独立的）协议顺序的逻辑流进行了验证，如对PDO 的配置。在PDO测试的例子中，在对象目录中的PDO相关的实体必须按指定的顺序书写。 在好的测试案例下，能检测到遵循这一顺序；在坏的测试案例下，错误的顺序将表现在被测 设备的响应中。创建这一测试需要彻底理解CANopen的细节，最主要的是理解所使用的不 同通信机制之间的相互关系。应用层：应用层的测试会检查过程变量之间的关系。要证实变量之间的关系，必须满足如下先决 条件：过程变量必须能与PDO发生交换，系统必须完全可配置。例如，在测试时，阀的状 态可被看作温度或压力的函数。这一例子说明用户必须能清楚地描述测试。测试过程使用CANoe工具，借助于集成的CAPL编程语言可以准确描述测试过程。开发者使用 CAPL语言可准确描述对复杂的通信系统的相当灵活的测试过程。每个CAPL测试模块是一 个包含许多独立测试用例的独立测试。每个测试用例又包含了许多测试步。在测试执行时, CANoe工具可依次运行各个测试用例。合适的测试流程控制可以跳过或重复某些测试。这 样可实现动态测试功能。借助预先定义的CAPL函数能大大简化产生测试用例的过程。一个典型的测试顺序可 能具有这样的结构：先仿真被测设备，测试人员等待其响应，然后做出评估oCAPL提供了 很多测试流程与事件同步的函数，比如接受一个特定的消息或者一个改变了的（可能通过 COM 修改）环境变量的值。与此同时，能在类似的后台监控到其它条件或约束的实现。如 果在等待某个特定报文的过程中，用户希望检查此总线上是否还在周期性发送另一不同报 文，这一功能就很有用。尤其是建立自动执行的测试时，对每个独立的测试步结果的详细数据记录是非常重要 的。另外的CAPL函数可用于将结果写入XML文件作后处理，也可以写入HTML文件做 直接评估。CANoe工具的测试过程也可以由XML文件指定。如果能通过同一工具生成许多 类似的测试过程，是更受欢迎的。CANoe工具提供了大量的XML格式的测试模板并能非常 合适地使用。总结CANopen 网络系统的原型开发总是有许多重要的工作要做。不管怎样，为了不需要等 到项目阶段的后期才能得到关于功能和系统性能的结论，原型设计经常是至关重要的。用户 通过专用工具创建原型并得到支持，尤其能很容易实现对技术通信需求的覆盖。 CANoe 工 具的测试功能让系统开发人员在项目的每个阶段都能进行验证工作，直至最终得到完美的系 统。