reasons for system simulation with canoe.canopen · here the simulation of these partners is the...

Reasons for System Simulation with CANoe.CANopen

Version 1.3 2009-04-30

Application Note AN-ION-1-1400

Author(s) Jürgen Klüser Restrictions Public Document Abstract This Application Note discusses advantages of Communication System Modeling and

Simulation by using CANoe.CANopen. Table of Contents

1 Copyright © 2009 - Vector Informatik GmbH Contact Information: www.vector.com or ++49-711-80 670-0

1.0 Overview ..........................................................................................................................................................1 2.0 Basic Concept of System Modelling ................................................................................................................3 3.0 Advantages of System Simulation ...................................................................................................................5 3.1 Modelling a System.......................................................................................................................................5 3.2 Automated Testing ........................................................................................................................................5 3.3 Evaluation of Communication Channels .......................................................................................................6 3.4 Busload .........................................................................................................................................................6 3.5 Device Performance......................................................................................................................................6 3.6 Distributed Development Process with Suppliers .........................................................................................6 3.7 Device Design ...............................................................................................................................................7 4.0 Reference Applications....................................................................................................................................7 4.1 Automotive Body Electronics ........................................................................................................................7 4.2 Agriculture Electronics...................................................................................................................................7 4.3 Public Community Vehicles...........................................................................................................................8 4.4 Education ......................................................................................................................................................9 4.5 Railway Applications .....................................................................................................................................9 4.6 Embedded Applications: Door Environment .................................................................................................9 4.7 Cabs, Police Cars and other special Cars ..................................................................................................10 5.0 Questions and Answers.................................................................................................................................10 5.1 How much effort is it to set-up a project?....................................................................................................10 5.2 What is the Relationship to Mathematical Simulation Systems? ................................................................11 5.3 Does CANoe help me debugging my Device?............................................................................................12 5.4 Does CANoe help in Error Searching in a Network? ..................................................................................12 5.5 Can I do Online Evaluation of Data?...........................................................................................................12 5.6 How do I observe Problems while fast Traffic?...........................................................................................12 5.7 How do I talk with my Devices? ..................................................................................................................12 5.8 Does CANoe support reproducible Stimulation? ........................................................................................12 5.9 Is there a Reference Background Busload available? ................................................................................13 5.10 What about Protocol Testing?.....................................................................................................................13 6.0 Contacts.........................................................................................................................................................13

1.0 Overview For years, world-wide automotive and embedded systems network development has taken advantage of a powerful and comprehensive simulation and analysis tool by Vector called CANoe. CANopen-users can finally benefit from the Industry’s experience.


2 Application Note AN-ION-1-1400

CANoe.CANopen provides the user with an extensive simulation, development and test environment for CANopen systems. In the design phase of a CANopen system, the developer has the ability to simulate the remaining behaviour of the network, observe the bus load, and determine the necessary performance of the hardware which is being developed. The CANoe.CANopen tool makes it easy to generate a complete simulation, including the visualization of the actual values with just a push of a button. All target values can easily be manipulated in the automatically generated operating and display panels. Hereby the user is completely supported by the extensive CANopen-specific services. Therefore, the application of CANoe.CANopen leads to significant time and cost savings throughout the entire CANopen project.

ProCANopen, the CANopen network configuration tool from Vector is integrated in CANoe.CANopen. ProCANopen is used to create the project for the CANopen system that is to be simulated. CANoe.CANopen generates a CANoe database and a device model for each simulated CANopen device using the ProCANopen project file. Due to the fact that all communication relevant values are given, the device models can represent all bus communication. It is not necessary for the user to write code that simulates the communication, this code is generated automatically. Due to the flexible interface of the environment variables, the user can concentrate on the programming of the application. The simulation and visualization of external influences such as I/O values, temperatures, encoder values etc. take place via operating panels. The generated models can be gradually replaced by real CANopen devices. Each of the not yet physically available devices then are simulated in real-time together with the existing devices. This concept is called the remaining bus simulation. In the final phase of development, when all necessary devices are physically available, CANoe.CANopen provides the required analysis of the CANopen-System.

CANoe supports the test of ECUs and networks via special functions of the “Test Feature Set”. With these functions, tests can be created that verify single development steps, check prototypes or execute regression and conformity tests. Additionally, the check and stimulation functions, included in the test service library, simplify the set-up and execution of own test scenarios.

Figure 1: CANoe.CANopen simulating simple IO Devices



2.0 Basic Concept of System Modelling CANoe is a universal development, test and analysis environment for CAN bus systems, which is made available to all project participants over the entire development process. The system producer is supported in functional distribution, functional checking and integration of the overall system. The supplier obtains an ideal test environment by simulation of the remainder of the bus and environment.

The development process is based on a phase model which differentiates between three development stages (see Figure 2).

Phase 1: Requirements analysis and design of the networked system

First, the party responsible for design distributes the overall functionality of the system among different network nodes and refines the design to the level of the network node. This includes defining messages and selecting the baud rate of the bus. Finally the bus behavior of individual network nodes must be specified, e. g. in the form of cycle times or more complex protocols. Then this information can be evaluated first by the simulation tool to provide initial estimates of bus load and the latency times to be expected at the prescribed baud rate. Afterwards, this specification can also be utilized for testing in subsequent phases.

For a more accurate study, a dynamic functional model of the overall system is created. This involves specifying the behavior of the network nodes with regard to input and output variables and the messages to be received and transmitted. Especially useful here is an event-driven model with a procedural description of behavior. For example, the model may describe how - after receiving a message (Event) - the received data are to be further processed (procedural) and how the result is to be output as a control variable.

The user must also specify the input variables to the simulation tool, so that the time behavior of network nodes and the accumulation of messages can be simulated. The results of the simulation serve to validate the design and can later be used as a reference after implementation.

Phase 2: Implementation of components with simulation of remainder of the bus

After the first phase has been completed the design and development of individual network nodes is usually performed by all participants, independently and in parallel. The models for the other network nodes can now be used to simulate the remainder of the bus for testing of a developed network node. The tool requires an interface to the real bus for this, and it must be able to conduct the simulation in real time.

Phase 3: Integration of the overall system

In this last development phase all real network nodes are connected to the bus in a step-by-step manner. To accomplish this it must be possible to "disconnect" the models one-by-one in the simulation of the remainder of the bus. The tool serves increasingly as an intelligent analysis tool which observes the message traffic between the real network nodes on the bus and compares the results with the specified requirements.



Figure 2: Phase model of the development process

The behavior of network nodes with regard to input and output signals is described with the help of environment variables. CANoe differentiates between discrete and continuous variables. Switch positions can be represented as discrete environment variables. With continuous environment variables, dimensions such as temperature or engine RPM can be described.

The control panels provide a user-friendly interface to the environment variables. The user can create the panels independently with the help of the Panel Editor. During the simulation values of environment variables can be displayed (lamps, counters) and interactively modified (switches, potentiometers).

The example in Figure is intended to clarify the functions which CANoe provides for simulation and testing of CAN bus systems.

By pressing the pushbutton on the left control panel the discrete environment variable "Pushbutton" is set to the value 1. The bus node on the left reacts by sending out a message on the CAN bus. The bus node in the middle receives this message and sets the discrete environment variable "Light" to 1. This causes the small lamp in the middle control panel to light up.



Figure 3: Components of the simulation system

Analogously, the user can also adjust the potentiometer in the middle control panel, whereby the value of the continuous environment variable "Potentiometer" is modified. This causes the middle network node to place a message on the bus with the new data. This message is received by the network node on the right. There a new value is calculated from the signal contents for the environment variable "Engine RPM". Finally, this causes the display of engine speed to be updated on the right control panel.

The behavior presented in the previous sections can be described very easily with functions available in CAPL. By this method it is possible to implement a simulation of complex systems with relatively little effort.

3.0 Advantages of System Simulation

3.1 Modelling a System For building a complete communication system it is necessary to plan carefully the communication relationship between all devices. This sometimes is done on plain paper – without any possibility of further electronic processing. Many system designers do this process with some kind of a database. This allows to make further processing, such as generation of the documentation. Anyhow, this does not allow to use CAN-specific know-how. With a specific CAN simulation tool, the semantics of the communication can be planned and described.

There is already a standard to describe the facilities of single CANopen devices – the so-called EDS files. There exist two forms of EDS files. One is the well-established “Electronic data sheet”, a MS Windows INI file format. The other is the XDD “XML Device Description”, specified in 2008, which is based on a XML format and will be enhanced in the next years. The Vector tool chain supports both of them and is able to convert the common information of both into each other format. Using those device descriptions, plenty of work can be saved. Building a network description simply means to select the appropriate EDS files. Afterwards the communication relationships between the devices are defined. Again with that knowledge from the EDS the appropriate tools allow to do this by simple drag’n’drop.

Such tools allow exporting the data in different ways. Since the basic file formats are well-specified by CiA it is possible to build converters for any kind of database format. Later changes require only a push of a button to re-generate the exported documentation/database.

3.2 Automated Testing Beside the features for on-the-fly testing, required in the phase of Device development, reproducible tests with well-defined test groups and test steps are the basis for reliable high-quality products. ProCANopen is able to



generate in-depth test sequences with a few clicks. The knowledge about the Devices features comes from the EDS / XDD files. More than 10 years experiences with CANopen Devices were incorporated into ProCANopen and CANoe.CANopen to put CANopen Devices to the acid test.

Many features of a Device can in principle work only if the Device finds itself in a complete system with other communication partners. Here the simulation of these partners is the solution.

3.3 Evaluation of Communication Channels Defining the complex communication between many devices is a hard error-prone work. Using a simulation tool allows to immediately test the communication channels. One small change in the correlations may lead to a totally different distribution of signals (application values) on the messages. Using CANoe.CANopen this is transparent for the user. One further click – and the complete simulation is rebuild and can be tested again. This saves a lot of time.

If communication related errors are detected in the final phases of a project this will cause a lot of effort to fix the problems. Very often this affects not only the system provider but also the suppliers. CANoe.CANopen helps avoiding that by detecting errors already before suppliers are involved and before the concrete implementations are started.

3.4 Busload Simulating the communication system allows to get statements about the busload already in the planning phase of the project. This will avoid unpleasing surprises in the integration phase.

3.5 Device Performance The simulation helps in detecting load or even overload situations. Besides the general busload this affects the performance of the Devices’ micro-controllers. Some implementations of Devices will show problems only in critical load situations. One has to consider that a CANopen device normally will not only receive the messages targeted to it, but the complete message traffic and has to filter the messages by software.

Searching this kind of problems in an integrated system is very time consuming, since it is not easy to reproduce the unique situation. If found, solving the problem in the Device’s implementation may require a re-design of the software which will shift delivery dates significantly.

A big medical manufacturer detected sporadic problems in some of its components. With the help of generating a reproducible background busload (see also 5.9) these problems could be identified as performance problems.

3.6 Distributed Development Process with Suppliers A typical system development acts in a way, where interfaces between the suppliers are specified, then the suppliers develop the devices, perform self-defined tests and then deliver to the OEM. The OEM integrates the devices – and nothing will work. Finding the problems is hard and time-consuming, and it will be nearly impossible to uniquely identify the responsibilities.

Giving the system model to the suppliers will enable them to develop their devices in the environment of the complete system. By performing the real-time remaining bus simulation, the behaviour can be tested extremely close to the real system.

Many big car manufacturers world-wide have chosen this concept. This leads to a revolutionary increase of the performance of their development process. It is unthinkable now, how development of the CAN system could work without CANoe.



3.7 Device Design CANoe.CANopen allows to describe the requirements to the communication model and the signals (in CANopen terms: objects) in form of an electronic description. As format it uses the standardized EDS/XDD as a base. The development of the design is very efficient with the help of the simulation generation: After finishing the device definitions, a click is enough to generate a simulation of the device together with access panels and the rest bus simulation. Running this simulation allows to get feedback about the results of the definitions.

The turnaround times for this are extremely short.

In the further steps the device design can be used as electronic specification of the device’s communication behaviour.

4.0 Reference Applications

4.1 Automotive Body Electronics Originally CANoe had been developed in close co-operation with the research and pre-development departments from Daimler and others. They provided their experience as input for the requirement analysis. Meanwhile CANoe has proven it’s concept in most European and many world-wide designs for networking the Body Bus Electronics.

Figure 4: Automotive Example

4.2 Agriculture Electronics The agriculture market consists of many manufacturers of tractors and harvesters and many manufacturers of equipment machines – the so-called implements. They are faced with the problem that the farmers will try to attach any implement with any tractor. Having solved most mechanical and electrical interface problems the next step had



been the electronic interfacing. Started in the late 80’s with CAN and the protocol LBS they meanwhile have reached a highly sophisticated CAN-based bus system called ISO11783 or short ISOBUS.

In spring 2001 the specification achieved a more or less stable state. The goal was to present first products on a fair in autumn 2001 – only have a year later. The system development was supported by CANoe. Public statements said “We would never have reached our challenging goal in that short time without the help of CANoe”.

Figure 5: Testing Communication with Ag Implements (CANoe ISOBUS) and Tractor ECU

4.3 Public Community Vehicles The market for communal waste collection vehicles, street cleaning vehicles and machines for many other tasks of public community is stamped by a wide variety of different application in relatively small number of units. The manufacturers have to serve their customers by providing interfaces to all relevant truck manufacturers. This results in high efforts regarding bus communications. A group of manufacturers specified the CiA 413 “Device profile for truck gateways”. This is a CANopen profile supporting CANopen communication on the superstructure side, J1939 or proprietary communication on the truck side and furthermore the standard ISO 1992 for communication with and between trailers.

Another activity is the so-called FireCAN. Here a group of superstructure manufacturers and suppliers specify profiles for specific fire fighting equipment.



Figure 6: Fire-fighter Model

4.4 Education Several universities are using CANoe for teaching CAN and Higher Layer Protocols, such as CANopen. Simulation is a flexible way to demonstrate and practice a series of CAN use-cases without the need of many different hardware set-ups.

4.5 Railway Applications An important manufacturer of railway carriages and trolley-cars uses ProCANopen and CANoe.CANopen in several stages of the development of the embedded CANopen network.

ProCANopen is used for designing the network, including all required ECUs. The test department for example develops test stands for the main controller by just loading the ProCANopen project file for the appropriate train project and by generating the simulation of all connected ECUs in form of a CANoe model. This allows manipulating all input values even outside the specified ranges, which would be extremely complex and expensive if this would have to be done by physical hardware. With these tests the correctness and stability of the main controller functions can be validated.

CANoe.CANopen here is connected via COM to LABview, which is used for the test input data and result data management.

4.6 Embedded Applications: Door Environment There exists a wide variety of embedded networks with CAN. The word leader of building door environment systems has chosen CANopen for his new lock-technology standard. This means that installers and integrators of locks can quickly and automatically connect together all the units in an electromechanical locking system, regardless of their suppliers. Functions such as identity control, code reading, locking, door opening, intruder alarm and fire alarm can easily be installed without configuration, thanks to an open standard based on ‘plug and play’ technology with CANopen DS-416. The concept and design were developed with Vector’s support in consulting, software components and tools. Specifically CANoe.CANopen had been extended for this application profile with additional functionality, that enhances network specification, model generation, as well as simulation and test functionality.



4.7 Cabs, Police Cars and other special Cars In spring 2009 Daimler announced and offered a package for Cabs on base of the new E-class with the CANopen standard CiA 447. What’s the background?

Several car OEMs and a group of add-on devices manufacturers developed a communication profile under the umbrella of CiA. This profile is called CiA 447 “Car Add-on Devices” and targets mainly Cab (Taxis) equipment, as well as radio and light equipment for Police cars and other public authority vehicles.

In the beginning of the project the communication design was developed and proven with CANoe.CANopen. The next phase was the specification of device profiles, such as radio devices, printers, roof bars, taximeters, and several more. For the implementation of such devices CANoe.CANopen helped in performing the simulation of the car’s gateway. Finally the communication tests for the first series package could be successfully performed with CANoe.CANopen.

Other members of the group also performed developments and it can be expected that these will appear in the market soon.

Figure 7: CANopen networks Taxi add-on devices

5.0 Questions and Answers This chapter gives answers on some typical questions to the usage of CANoe.CANopen.

5.1 How much effort is it to set-up a project? The following steps show this procedure:

Project creation in ProCANopen

Specify the participating network devices. This is done by selecting the electronic descriptions – the so-called EDS files.

Description of the relationships

The communication connections between the devices are fixed by means of the „graphic connection“. This is done i.e. by selecting the communication channels with the mouse and connecting them to their partners.

Generation

One press of a button generates all required files for simulation: The CAPL models, the database, the user interface panels and the configuration file.

For the very first evaluation of the communication - that’s it !

Since the generation tools know all required information about the devices from the EDS files the generated models include everything to communicate with each other. The data contents can be set via the panels. The



timing relationships can be observed in the analysis windows of CANoe. The next step will be to insert some application description:

Application code and object directory

The objective of the model creation is not the complete simulation of the application. But the aspects of the application that have an impact on the communication have to be simulated accordingly.

Example: By normal use of an IO-device there is no need to emulate the application. But if you want to activate a control of threshold values of an analog input this has to be done in the simulation, too.

on envVar evN7RawInputValue { int actualValue; // get the value actualValue = getValue(evN7RawInputValue); // compare to the globally stored last value if(abs(actualValue-gLastValue)>10) { setValue(evN7_6401_1, actualValue); gLastValue=actualValue; } }

As you can see it is sufficient to set the value of a variable. No code needs to be written for sending these variables via a PDO.

Successive supplementation

Now panels and application code can be supplemented successively. If there are changes in the ProCANopen project it is important to know that the CAPL generator rereads and retains changes in CAPL programs programmed by the user. Only the generated part will be replaced. Thus you just have to be careful that code which stands inside of the generation markings must not be changed.

5.2 What is the Relationship to Mathematical Simulation Systems? Such simulation systems have a big strength in mathematical and logical simulation of application processes. Anyhow they lack of specific knowledge of CAN communication issues. CANoe is predestinated for this by the experience with CAN based systems of more than 15 years.

CANoe has an open interface to systems such as Matlab/Simulink. It is available for free for users with a CANoe maintenance contract.

As an example the University of Munich the project “Process security of agricultural electronic devices” built a model of a complete tractor with harrow and drilling machine was modelled, simulated and evaluated specifically regarding process safety requirements. This has been done in very close interaction between CANoe and Matlab/Simulink.

Figure 7: Test run in the project “Process security of agricultural electronic devices”



5.3 Does CANoe help me debugging my Device? When you are developing your own devices, you generally face the task of “seeing” the first message sent from the device and then stimulating the device with messages. If this is successful, it is followed by incremental tests that add implemented functions of the device.

After turning on the CANopen device, the device should transmit a so-called “Boot-Up message”. This message can be seen in the Trace window.

The interactive generator block can be used for stimulation purposes. Specific individual messages can be sent here without the time and overhead involved in configuration.

To use additional protocol-specific services, it is now recommended that you use ProCANopen. Messages for individual services can be conveniently observed in the CANoe Trace window.

5.4 Does CANoe help in Error Searching in a Network? Besides the pure observation of messages and values in the analysis windows you have convenient access to the object directories of the devices with ProCANopen. You can thus read error histories or individual entries and also set values. You can track the associated message traffic in the background with the CANoe Trace window.

5.5 Can I do Online Evaluation of Data? Current values of messages can be observed in various display formats in the data window. If you are more concerned with the temporal flow instead, you should use the graphics window.

5.6 How do I observe Problems while fast Traffic? CANoe allows recording the traffic to a file, which can be replayed afterwards. For data reduction it has filter and trigger capabilities. The search function allows to find specific messages or data contents on the application data level – such as “Temperature > 80 deg” - down to the bit level.

To aid you in quickly evaluating messages, you can also scroll through the Trace window without any recording. Together with the expandable node structure, this provides comprehensive information.

5.7 How do I talk with my Devices? There is a whole series of options for interacting with bus traffic with CANoe and generating messages and/or services.

A feature known as the “interactive generator block” is most suitable for transmitting PDOs, SYNC and EMCY. ProCANopen should be used for SDO services and NMT. This allows to interactively exchange information with the device.

5.8 Does CANoe support reproducible Stimulation? The generator block can be used for sequences that occur frequently, for example. A list of messages that are transmitted by pressing a key or by time control is entered into the generator block.

Another possibility is the Replay block. In this case, a file in which the messages are specified is played back. For example, you can record message traffic with the logging tool, modify it offline if necessary and then enter it in Replay. If you use the ASCII format, the file can also be modified manually in an editor.



5.9 Is there a Reference Background Busload available? For testing Devices under all circumstances one requirement is to have a reproducible bus load. The CiA has indicated certain tables that can be used to specify a reproducible reference background busload. These tables can be written to an ASCII file using the clipboard. The file can then be used for Replay.

5.10 What about Protocol Testing? While displaying the message traffic CANoe observes the protocol in the background. It implements checks for typical implementation errors. If one of them is detected, CANoe displays a corresponding clear text message.

Besides the symbolic representation of CANopen services CANoe can display raw data as messages, too.

6.0 Contacts

Germany and all countries not named below: Vector Informatik GmbH Ingersheimer Str. 24 70499 Stuttgart GERMANY Phone: +49 711-80670-0 Fax: +49 711-80670-111 Email: [email protected]

France, Belgium, Luxemburg: Vector France SAS 168 Boulevard Camélinat 92240 Malakoff FRANCE Phone: +33 1 42 31 40 00 Fax: +33 1 42 31 40 09 Email: [email protected]

Sweden, Denmark, Norway, Finland, Iceland: VecScan AB Theres Svenssons Gata 9 41755 Göteborg SWEDEN Phone: +46 31 764 76 00 Fax: +46 31 764 76 19 Email: [email protected]

United Kingdom: Vector GB Ltd. Rhodium Central Boulevard Blythe Valley Park Solihull, Birmingham West Midlands B90 8AS UNITED KINGDOM Phone: +44 754 9001197 Email: [email protected]

USA, Canada, Mexico: Vector CANtech, Inc. 39500 Orchard Hill Pl., Ste 550 Novi, MI 48375 USA Phone: +1 248 449 9290 Fax: +1 248 449 9704 Email: [email protected]

Japan: Vector Japan Co. Ltd. Seafort Square Center Bld. 18F 2-3-12, Higashi-shinagawa, Shinagawa-ku Tokyo 140-0002 JAPAN Phone: +81 3 5769 7800 Fax: +81 3 5769 6975 Email: [email protected]

Korea: Vector Korea IT Inc. Daerung Post Tower III, 508 182-4 Guro-dong, Guro-gu Seoul, 152-790 REPUBLIC OF KOREA Phone: +82 2 2028 0600 Fax: +82 2 2028 0604 Email: [email protected]

reasons for system simulation with canoe.canopen · here the simulation of these partners is the...

Documents