一个例子是依据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工具的测试功能让系统开发人员在项目的每个阶段都能进行验证工作，直至最终得到完美的系统。