1

Prototyping and Testing CANopen SystemsReaching Goals Rapidly with Minimal EffortCANopen established itself as a standard for cost-effective and flexible networking of components in numerous applica-tion fields ranging from industrial automation to commercial vehicles. Standardized device profiles simplify communica-tion between bus nodes and facilitate smooth interplay between the ECUs, sensors and actuators from different manu-facturers. A specialized prototyping and test tool not only performs valuable services in developing complex CANopen projects, but also in providing a fundamental introduction to the subject area.

cost and effort. Bottlenecks are built into the process during the test phase, since generally only one test setup is available.A way out of this dilemma might be offered by a software tool that could be used to create a prototype of the future total system in a simple way. Optimally, this tool would also offer extensive test functions.

Creating a Prototype Environment with Tool SupportAbove all, prototypes of total systems networked by CAN should support testing and validation activities. In addition, it is important to represent the individual components by real or simulated ECUs. This makes it relatively easy to test the functional capabilities of real ECUs over the course of system development.Creating a prototype for a complex total system is a com-plicated endeavor in which it pays to use suitable tools. CANoe .CANopen from Vector offers valuable assistance in creating communication for the prototype system. In just a few configuration steps, it lets the user create a prototype whose communication properties match those of the later real system.

The bandwidth of tasks in the development of CANopen systems ranges from developing individual ECUs to config-uring and starting up total systems. For system producers, the initial use of a system such as CANopen is associated with an incalculable startup effort. In the framework of the V-model, a large share of development tasks involves verifi-cation and validation. The risk of detecting errors too late is minimized by comprehensive tests at the earliest possible time (Figure 1).

System Verification with Test SetupsSystematic tests accompanying the development of a to-tal system are indispensible in all development steps. Often it is possible to test, but not until a very late time, when actual system components are available. Then, the system completion date is at risk if problems occur.In practice, tests are not performed on the real system at the customer’s facilities, rather test setups are used for this purpose. Besides special measurement or diagnostic setups, in testing they also include actuators for simulating system environments as realistically as possible. Depend-ing on the project size, such a test setup could incur much

Figure 1: Representation of the V-model

2

(control module). This is how all PDO (Process Data Object) interrelationships are defined in the prototype system.The tool automatically computes the resulting mapping, which can be modified later if necessary. From this config-uration information (DCF – Device Configuration File) the user now generates the prototyping environment, i.e. CANoe generates a counterpart for each real ECU with identical communication properties. When CANoe is started, the communications portion of the prototyping environment is already available (Figure 2).

Defining Application Behavior The application behavior of individual ECU nodes cannot be derived directly from the EDS files, since they only map the structure of an object directory. Therefore, formulation of application behavior always involves additional program-ming effort. The CAPL programming language integrated in CANoe makes it possible to program ECU behavior quickly. As an alternative it is possible to code ECU behav-ior in a DLL that is linked in the prototyping environment under CANoe. It is also easy to integrate Matlab/Simulink models (Figure 3).

Test FunctionalityAfter the prototype system has been completed, the neces-sary tests for the total project follow. CANoe supports the user here, both in creating tests and in logging and evalua-tion. The test functionality required for a CANopen system comprises several stages (Figure 4):

The behavior of the CANopen ECUs is defined in descrip-tion files (EDS – Electronic Data Sheet) that are selected or created beforehand. This next step is to define the inter-relationships between calibration data that will later be exchanged over the bus, e.g. the “PressureValve” input of the device with address 5 (pressure transducer) is linked to the “Gas pressure” variable of the device with address 10

Figure 2: Sample configuration of a simple, simulated CANopen network with central control and I/O node

Figure 3: Representation of the CANoe . CANopen environment

3

Especially in automated tests, it is important to record the results of individual test steps in detail. Other CAPL func-tions handle writing of test results to an XML file for later post-processing. Test sequences for CANoe can also be specified under XML. This is advantageous when a large number of test flows need to be generated with a single tool. So CANoe utilizes a number of test patterns specified in XML and processes them accordingly.

SummaryWhen prototypes are created in CANopen networked sys-tems, this process always involves considerable effort. Yet the process is often essential to prevent findings on func-tionality from being delayed until a later project phase. Special tools such as CANoe .CANopen offer the user effi-cient support in creating prototypes. The requirements for technical aspects of communication, in particular, are very easy to cover in this way. In every phase of a project, this gives the system developer the test functionality needed to check and verify components completed up to that point in time.

Mirko Tischer, Product Manager for CANopen.

> Protocol level: Tests on this level ensure that CANopen-specific communication protocols of the individual devices are implemented within the total system according to specification. > Communication level: What is important here is not the correctness of the protocol, but the correct logical order of (independent) protocol sequences, e.g. in configuring PDOs. Description of the PDO-relevant entries in the object directory must conform to a specific sequence. > Application level: Application tests check the relationships between process variables. The following preconditions must be met to even determine such relationships: First, the process variables must be exchanged via PDOs, and the system must be fully configured. This means, for example, that the state of a valve can be checked as a function of a temperature or a pressure. Clearly, the user must have the relevant know-how to formulate the test.

Creating and Executing Test Procedures with CANoeTest sequences are formulated under CANoe with the help of the integrated CAPL programming language. Each CAPL test module represents a separate test consisting of individual test cases, which in turn contain a number of test steps. During the test run, CANoe processes the individual test cases sequentially. Suitable test flow control makes it possible to skip or repeat individual tests. Simultaneously, it is possible to monitor conformance to other conditions and restrictions – quasi in background. This might be done, for example, to determine – while waiting for a specific message of interest – whether a specific other message is sent periodically on the bus.

Figure 4: Test levels in CANopen