An and 1 118 Canoe Tfs Tutorial

CANoe Test Feature Set Tutorial
Version 2.0 2009-05-28 Application Note AN-AND-1-118

Restrictions Abstract Public Document This application note is a step-by-step tutorial to introduce the basic process of developing a simple CANoe test application with CANoes Test Feature Set. Used as a guide, the focus is to better understand how to use CANoes Test Feature Set.
Table of Contents 1 2 3 4 5 5.1 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.4.1 5.2.5 5.3 5.4 5.4.1 5.4.1.1 5.4.1.2 5.5 5.6 5.7 5.7.1 5.7.2 6 6.1 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.4.1 6.2.4.2 6.2.4.3 6.2.4.4 6.2.4.5 6.2.4.6 6.2.4.7 6.2.4.9 6.3 6.3.1 6.3.2 6.3.3 6.4 Overview ..........................................................................................................................................................3 About this Tutorial ............................................................................................................................................3 References.......................................................................................................................................................3 Definition of Terms...........................................................................................................................................3 Simulating a CAN Network ..............................................................................................................................4 Create a New Directory .................................................................................................................................4 CAN Network Database Setup......................................................................................................................4 Creating a New Database File....................................................................................................................4 Creating Network Nodes ............................................................................................................................5 Creating Messages.....................................................................................................................................5 Creating Signals .........................................................................................................................................5 Creating and Assigning Value Tables (Optional).....................................................................................6 Creating Environment Variables.................................................................................................................7 Associate a Database ...................................................................................................................................8 Create User Test Panel.................................................................................................................................8 Opening Panel Designer ............................................................................................................................8 Adding Switches.......................................................................................................................................8 Adding Push Buttons................................................................................................................................9 Associate the Panel to CANoe......................................................................................................................9 Add Nodes to the Network ..........................................................................................................................10 Create Node Behavior.................................................................................................................................10 Programming the MainControl Node Behavior ......................................................................................11 Programming Doors Node Behavior.........................................................................................................13 Programming with CANoes Test Feature Set...............................................................................................15 Differences between XML and CAPL..........................................................................................................15 Programming with XML ...............................................................................................................................15 Test Setup ................................................................................................................................................15 Basic Understanding of the TAE Tool ......................................................................................................16 Creating a Test Group ..............................................................................................................................17 Creating Test Cases .................................................................................................................................17 Ignition Test:...........................................................................................................................................17 Window Panel Test ................................................................................................................................18 Test Windows Button .............................................................................................................................19 (Optional) Adding Window Captures to XML Test Groups/Cases.........................................................22 Test Lock................................................................................................................................................23 Wait 10 Seconds ....................................................................................................................................25 (Optional) Adding Description to Test Groups/Cases............................................................................26 TAE Generated XML Code (in text view)...............................................................................................27 Notes on writing XML files without TAE ......................................................................................................31 Empty Spaces and Line Breaks ...............................................................................................................31 Characters with Fixed Meanings in XML ..................................................................................................31 Inserting HTML code ................................................................................................................................31 Programming with CAPL .............................................................................................................................32
1 Copyright 2009 - Vector CANtech, Inc. Contact Information: www.vector-cantech.com or 1-248-449-9290
6.4.1 Test Setup ................................................................................................................................................32 6.4.2 Creating a Test Module ............................................................................................................................32 6.4.2.1 MainTest() ..............................................................................................................................................32 6.4.2.2 Test Cases .............................................................................................................................................33 6.4.2.2.1 TC_IgnitionTest().................................................................................................................................34 6.4.2.2.2 TC_TestLock().....................................................................................................................................35 6.4.2.2.3 TC_Wait10sec()...................................................................................................................................36 6.4.2.2.4 TC_WindowDown() .............................................................................................................................36 6.4.2.2.5 TC_WindowUp() ..................................................................................................................................37 6.4.3 (Optional) Adding Window Captures to CAPL Test Groups/Cases .........................................................38 6.4.4 (Optional) XML Linked CAPL Test Cases and Functions ........................................................................38 6.4.5 Vector Test Feature Set Functions...........................................................................................................40 6.5 Running the Test Modules ..........................................................................................................................41 6.5.1 Compiling the Test files ............................................................................................................................41 6.5.2 Testing the XML Test file ..........................................................................................................................41 6.5.3 Testing the CAPL Test file ........................................................................................................................42 6.5.4 Viewing the Test Report ...........................................................................................................................42 6.5.4.1 One Page Test Report ...........................................................................................................................43 6.5.4.2 Extended Test Report ............................................................................................................................43 6.5.4.3 Combined Test Report ...........................................................................................................................44 6.5.4.4 Window Captures and Images...............................................................................................................45 7 Conclusion .....................................................................................................................................................47 8 Contacts .........................................................................................................................................................47
2 Application Note AN-AND-1-118
Overview
This application note is a step-by-step tutorial to introduce the process of developing a simple CANoe test application with CANoes Test Feature Set (also known as TFS). Using this document as a guide, the user will be able to better understand how to use CANoes Test Feature Set. Before we discuss what TFS is, here is some background on CANoe. CANoe is very well-known for its network simulation capabilities. It not only has the capability to simulate multiple nodes in a network, it can also simulate multiple networks of various bus types such as CAN, LIN, MOST, and FlexRay. Imagine a vehicle with multiple data networks, consisting of a CAN network for powertrain, LIN networks for body electronics and lightings, MOST for entertainment and GPS navigation, and FlexRay for chassis, CANoe can be used to model all the network data and functions in these bus systems. When network data and functions need to be evaluated and validated at the design, implementation, or production stage, CANoe can become a test tool as well as a network simulation tool to test these network functions. This is made possible in CANoe with the Test Feature Set. TFS has been part of CANoe since version 5.0. It provides the user the ability to implement and execute a sequential set of test instructions written in XML, CAPL, or both. Since version 5.0, numerous improvements have been made to TFS to support various bus types: CAN, LIN, MOST, and FlexRay.
About this Tutorial
This tutorial will focus only on CAN and will demonstrate the implementation of a simulated CAN network that handles three simple functions: starting/stopping vehicle ignition, locking/unlocking the doors, and adjusting window position. Once these functions are simulated, we will then use the TFS to implement a few test case scenarios in both XML and CAPL to test the simulated CAN network. In practice, a simulated CAN network is not required to use the TFS functions in CANoe. Since the application to be tested is unknown, developing a simulated CAN network is inevitable. For system-level testing, such as on a breadboard or plywood buck, CAN network simulation is typically not required if all the CAN signals already exist on the CAN bus. For any other type of testing that involves rest-of-bus simulation, especially when testing a standalone ECU, the test application typically requires signal transmissions.
References
Vector provides various application notes (downloadable online at www.vector-cantech.com) pertaining to CANoe and its features. The following material may provide further useful information. AN-AND-1-112 CANoe Tutorial Overview of CANoe and its features AN-AND-1-113 A Quick Introduction to CAPL Overview of the CAPL language and the CAPL Browser AN-IND-1-002 Testing With CANoe Testing concepts in CANoe and potential applications
Definition of Terms
Condition A circumstance of the device being tested that must be fulfilled during the test case. If a condition is not met, then the test case will fail. Conditions can be used to check the system under test (SUT) behavior during the test execution. These can be defined easily with the functions or checks of the Test Service Library. Constraint A circumstance of the test execution environment that must be fulfilled during the test case. If a circumstance is not fulfilled, then the test case will fail. Constraints can make sure that no impermissible states occur in the test environment which would lead to the invalidity of the test result. These can be defined easily with the functions or checks of the Test Service Library. System under test (SUT) The system or device that is being tested by a test module. Test case A specific property of a system/device under test (SUT) is tested in a test case. A test case has a clearly stated test task. After execution, a test result or verdict will state whether the test case has failed or passed.
Test group A test group is typically used to categorize a set of test cases in a test module to provide a better organizational structure and report generation. Test groups may be nested. Test module A test sequence consisting test cases that are executed by CANoe. Test pattern A test pattern is a pre-defined test procedure that is parameterized with concrete parameter values for execution. The execution of the test pattern and its result can change the verdict of the surrounding test case. Pre-defined test patterns are only used when a test module is implemented in XML. Test Service Library (TSL) A collection of prepared test functions (or checks) and value generation functions (stimuli) which make it easier for a user to assemble tests. These checks assist in solving specific test problems more effectively and efficiently. The usage of TSL functions is not restricted to test modules but, it is recommended that they only be used in XML and CAPL test modules. Test step A test case consists of test steps or routines that are used to justify the test result or verdict. Test steps provide a finely structured and comprehensible manner when it comes to report generation. Verdict A final result of a test step, test case, test group, or test module. A verdict may result in any of the following conditions: 1) Without Note: The test step only specifies that an action was carried out. The execution of the test step has no affect on the verdict of the test case. 2) Pass: An expected result was achieved. 3) Fail: The expected behavior was not detected, a deviation from the expected behavior occurred. 4) Warning: No deviation from the expected behavior was detected, however the behavior detected could contribute to a problem later on, which may lead to the failure of the test case.
Simulating a CAN Network
We will begin by developing a CAN database to symbolically represent the data on a CAN network. Since this tutorial does not pertain to any type of network, this database will help us define a simulated, virtual CAN network. The network will have two simulated network nodes and a panel as a user interface. The panel will give the user the ability to set the ignition to on/off, the doors to lock/unlock, and the window to up/down. Once the simulated network is implemented, we will then use TFS to define a few test cases in both XML and CAPL to test the functional behavior of the network.
5.1 Create a New Directory

1) Before loading CANoe, create a new directory called "testTFS" to contain the new configuration. 2) Load CANoe and use the main menu to go to File New Configuration. A prompt will appear to select the default template and then click [OK] 3) Go to File Save Configuration As. Name the file "testTFS.cfg" and save it into the new directory. Then, click [OK].
5.2 CAN Network Database Setup

A network database is not required, but it is always helpful to have one. In most test applications, a network database will save a lot of time and effort implementing the test cases. If one is not available, creating a database is a good first step.
5.2.1
Creating a New Database File
1) On the CANoe toolbar, click the CANdb++ Editor button (the one with 4 interconnected red nodes) to launch the integrated database tool.
2) In the CANdb++ Editor, go to File Create Database. A prompt appears to select a template. Select the empty template. 3) Name the empty DBC file "testTFS.dbc" and save it into the testTFS directory.
5.2.2
Creating Network Nodes
1) Select "Network Nodes" from the tree view on the left pane of the Overall View window, right-click on it, and select New. Name the first network node "Doors" and then click [OK]. 2) Repeat the step above to create a second network node and name it "MainControl".
5.2.3
Creating Messages
We will now create five messages for our simple test application. 1) Select "Messages" in the tree view on the left pane of the Overall View window, right-click on it, and select New. 2) Set up the messages as follows: o Name = IgnitionStatus Set the DLC (Data Length Code) to "1, for 1 byte of data. Select the Transmitter tab and click [Add]. Select "MainControl" and then click [OK]. o Name = LockingControlRq Set the DLC to 1. Set MainControl to be the transmitter of the message. o Name = LockingSysState Set the DLC to 1. Set Doors to be the transmitter of the message. o Name = WindowRq Set the DLC to 1. Set MainControl to be the transmitter of the message. o Name = WindowState Set the DLC to 2 Set Doors to be the transmitter of the message.
5.2.4
Creating Signals
We will now create five signals to represent data within the messages we have just created, 1) Select Signals" in the tree view on the left pane of the Overall View window, right-click on it, and select New. 2) Set up the signals as follows: o Name = Ignition_Status Enter 1 for Length (bit) Select unsigned for the Value Type Set Minimum to 0 and Maximum to 1
o o o o 5.2.4.1
Switch to the Message tab. Add the message, IgnitionStatus, and click [OK].
Name = LockRequest Enter 1 for Length (bit) Select unsigned for the Value Type Set Minimum to 0 and Maximum to 1 Switch to the Message tab. Add the message, LockingControlRq, and click [OK].
Name = LockState Enter 1 for Length (bit) Select unsigned for the Value Type Set Minimum to 0 and Maximum to 1 Switch to the Message tab. Add the message, LockingSysState, and click [OK].
Name = WindowPosition Enter 8 for Length (bit) Select unsigned for the Value Type Set Minimum to 0 and Maximum to 15 Switch to the Message tab. Add the message, WindowState, and click [OK].
Name = WindowStatus Enter 2 for Length (bit) Select unsigned for the Value Type Set Minimum to 0 and Maximum to 2 Switch to the Message tab. Add the message, WindowRq, and click [OK].
Creating and Assigning Value Tables (Optional)
Value tables can be made for each signal to symbolically represent the different value states. We will create a value table for four of our signals. 1) Select View Value Tables. 2) Right-click anywhere on the empty page and select New to create a value table. 3) Setup the value tables as follows: o Name = IgnitStatus o In the Value Descriptions tab, click the [Add] button twice. Replace the description for 0x0 to Engine Off Replace the description for 0x1 to Engine On
Name = LockRq In the Value Descriptions tab, click the [Add] button twice. Replace the description for 0x0 to Request to Lock Replace the description for 0x1 to Request to Unlock
Name = LockStatus In the Value Descriptions tab, click the [Add] button twice. Replace the description for 0x0 to Unlocked Replace the description for 0x1 to Locked
Name = WinStatus In the Value Descriptions tab, click the [Add] button three times. Replace the description for 0x0 to Nothing Replace the description for 0x1 to Roll Window Up Replace the description for 0x2 to Roll Window Down
4) Go back to the Overall View window. 5) Double-click on Ignition_Status" under Signals. In the window that appears, select IgnitStatus in the drop-down box for Value Table. Click [Ok]. 6) Double-click on LockRequest" under Signals. In the window that appears, select LockRq in the dropdown box for Value Table. Click [Ok]. 7) Double-click on LockState" under Signals. In the window that appears, select LockStatus in the dropdown box for Value Table. Click [Ok]. 8) Double-click on WindowStatus" under Signals. In the window that appears, select WinStatus in the dropdown box for Value Table. Click [Ok].
5.2.5
Creating Environment Variables
Environment variables are defined to represent user inputs on the panel. When a user selects a button on the panel, for example, the environment variable associated with that button will be set to a value and simultaneously trigger an event to be executed within its virtual network node. 1) Select "Environment variables" in the tree view on the left pane of the Overall View window, right-click on it, and select New. 2) Setup the environment variables as follows: o Name = IgnitionStart o o o Expand the Access drop-down list and select ReadWrite. Set Maximum value to 0x1
Name = LockRq Expand the Access drop-down list and select ReadWrite. Set Maximum value to 0x1
Name = Window Expand the Access drop-down list and select ReadWrite. Set Maximum value to 15
Name = WindowDown Expand the Access drop-down list and select ReadWrite. Set Maximum value to 0x1
Name = WindowUp Expand the Access drop-down list and select ReadWrite. Set Maximum value to 0x1
3) Now, lets save the database by selecting File Save. 4) Close the CANdb++ Editor
5.3 Associate a Database

1) Go to CANoe and select the menu command View Simulation Setup to make sure the Simulation Setup window is displayed. 2) Expand the tree list on the right pane and select Databases. Right-click on it and select Add. 3) Associate the testTFS.dbc database file.
5.4 Create User Test Panel

There are two tools available to create graphic control panels, Panel Designer and Panel Editor. Each tool may be used as a separate application program; however, it is recommended to open them from CANoe so the associated database is reference. We will use Panel Designer in this example to create the panel.
5.4.1
Opening Panel Designer
1) To open the Panel Designer, click on the icon with a blue meter on the main toolbar of CANoe or via menu File Open Panel Designer. 2) On the menu bar of Panel Designer, select File Save Panel As. 3) Using the extension .xvp and the path to the new directory, name the file "Test.xvp". Click [OK]. Test will also be the title of the panel when displayed in CANoe. 5.4.1.1 Adding Switches
Three switches will be used in this tutorial; one for IgnitionStart, LockRq, and Window. The following steps show how to add a panel switch. 1) On the top-right side of Panel Designer, there should be a Toolbox box. Scroll down the list of Vector Standard Controls and click on Switch/Indicator and drag it onto the gray platform in the center of Panel Designer. A box with a dashed border and a black color switch should than appear. 2) On the bottom-right side of Panel Designer, the properties of this switch should be displayed in the Properties box. 3) Set the State Count to 2 and the State Values to 0 for State 1 and 1 for State 2. 4) Under the Symbol section, set the symbol filter to Environment Variable. Next, click on Symbol, and then click on the button to the right of the white box. 5) A window should appear with the list of environment variables, expand the Environment variable list, and select IgnitionStart. Afterwards, click [OK]. (Alternatively, the environment variable can be assign by dragging it from the Symbol Explorer on the left pane to the switch box.) 6) Under the Toolbox section, scroll down the list, drag and drop Static Text next to the switch on the gray platform. A box with the words Description should appear. 7) In the Properties box, replace the text box property, Font Text, from Description to Ignition Start. 8) Repeat steps 1-7 and create the following switches for the following environment variables
o o 9)
LockRq Window with a State Count of 17.
(Optional) Switch images may be replaced with user created graphics. o For LockRq and Window, the lock and window image from CANoes Central Locking State Demo was used. (Images used: LockUnlock.bmp and WindowsLeft.bmp. Located in the file directory: C:\...\Demo_CAN_CN\TestFeatureSet\CentralLockingSystem\Panels\Bitmaps\). See Figure 1.
5.4.1.2
Adding Push Buttons
Next, we will add two push buttons to control the vehicles window position. 1) On the top-right side of Panel Designer, there should be a Toolbox box. Scroll down the list of Vector Standard Controls and drag and drop Button onto the gray platform. A push button image should appear with the name Button. 2) On the bottom-right side of Panel Designer, the properties of this button should be displayed in the Properties box. 3) Under the Text section, replace Button with Window Down. 4) Under the Symbol section, set the symbol filter to Environment Variable. Next, click on Symbol, and then click on the button to the right of the white box. 5) A window should appear with the list of environment variables, expand the Environment variable list, and select WindowDown. Afterwards, click [OK]. (Alternatively, the environment variable can be assign by dragging it from the Symbol Explorer on the left pane to the switch box.) 6) Resize the button to fit the text. 7) Repeat steps 1-6, to create a button labeled Window Up and assigned the WindowUp environment variable. 8) Save the panel by going to menu File Save.
Figure 1 Test Panel
5.5 Associate the Panel to CANoe

There are many ways to associate a panel to CANoe. The easiest method is by clicking once on the blue icon that looks like a meter with a plus sign on the toolbar of Panel Designer. Afterward, CANoe should be associated with a Test panel that looks like Figure 1.
5.6 Add Nodes to the Network

1) Go back to CANoe and open the Simulation Setup window. 2) In the left half of the window, right-click on the black/red parallel lines and select Insert network node. A new node will appear on the network with the default name "ECU 1". 3) Right-click on this new node and select Configuration. 4) Expand the CANdb Name drop down list and select the node name "testTFS::MainControl". Click [Ok]. The node name should change from ECU 1 to MainControl. The new node will appear in the tree list to the right. 5) Add the second node Doors in the same manner.
Figure 2 CANoe Simulation Setup with Two New Nodes
5.7 Create Node Behavior

Next, we use the CAPL programming language feature of CANoe to define the behavior of our two virtual nodes. A CAPL program is usually developed using the CAPL Browser. The CAPL Browser utility is subdivided into three distinct areas, or panes. The left pane contains a tree view of available event types which can be defined by rightclicking and selecting New. The area on the upper right is where global variables will be placed for the CAPL program. The area below it is where the actual source code for each event procedure is written.
Figure 3 CAPL Browser
5.7.1
Programming the MainControl Node Behavior
We will begin by associating the Ignition Start, Lock Request, Window Down and Window Up panel elements on the Test panel to transmit a message onto the CAN network. 1) In the Simulation Setup window of CANoe, click on the pencil icon located on the lower-left corner of the MainControl network node to open the CAPL Browser. 2) An Open dialog window will appear asking for the CAPL program to be given a name. Type in mainctrl.can and save the file into the testTFS directory. Then, click on Open. 3) In the upper right pane (global variable definitions) of the CAPL Browser, enter the following code:
variables { //The following three messages are defined for transmission message IgnitionStatus IgnitionStat; message LockingControlRq LkCtrlRq; message WindowRq WindowCtrl; }
4) On the tree view at the left, right-click on "Environment" and select New. An empty procedure for the environment variable appears in the bottom right window. 5) Right-click on the highlighted <newEnvVar> and select Environment variable from CANdb.... 6) Select the variable IgnitionStart from the list and click [OK]. 7) Enter the following code:
on envVar IgnitionStart { if(getValue(this)) IgnitionStat.Ignition_Status = 1; // Start Ignition else IgnitionStat.Ignition_Status = 0; // Turn off Ignition output(IgnitionStat); // Outputs message onto the bus }
8) Repeat step 4-5. Then, select the variable LockRq 9) Enter the following code:
on envVar LockRq { if(getValue(this)) LkCtrlRq.LockRequest = 1; else LkCtrlRq.LockRequest = 0;
// Request Unlock Doors // Request Lock Doors
output(LkCtrlRq); // Outputs message onto the bus }
10) Repeat step 4-5. Then, select the variable WindowDown 11) Enter the following code:
on envVar WindowDown { if(getValue(this)) WindowCtrl.WindowStatus = 2; // Set window to roll down else WindowCtrl.WindowStatus = 0; // Set window to do nothing output(WindowCtrl); // Outputs message onto the bus }
12) Repeat step 4-5. Then, select the variable WindowUp 13) Enter the following code:
on envVar WindowUp { if(getValue(this)) WindowCtrl.WindowStatus = 1; // Set window to roll up else WindowCtrl.WindowStatus = 0; // Set window to do nothing output(WindowCtrl); // Output the message to the bus }
14) On the toolbar, click the "Compile" icon (a single arrow pointing down onto a stack of papers) or select from the menu Compiler Compile. If a compile error is shown at the bottom pane of CAPL Browser, then double-click on the listed error to get close to the source code line where the problem is. Fix the error and re-compile it until all problems are fixed. If the source code entered has no problem, the last line at the bottom pane of the CAPL Browser will read Compiled . 15) On the menu, go to File Save to save the CAPL program. Then, close the CAPL Browser.
5.7.2
Programming Doors Node Behavior
1) In the Simulation Setup window of CANoe, click on the pencil icon located on the lower-left corner of the Doors network node to open the CAPL Browser. 2) An Open dialog window will appear asking for the CAPL program to be given a name. Type in doors.can and save the file into the testTFS directory. Then, click on Open. 3) In the upper right pane (global variable definitions) of the CAPL Browser, enter the following code:
variables { int IgnitionState; message LockingSysState LockSysState; message WindowState WindowStat; }
4) In the tree view at the left of the CAPL Browser, right-click on "CAN Messages" and select New. An empty procedure for a CAN message appears in the bottom right window. 5) Right-click on the highlighted <newMessage> and select Message from Database. 6) Select the CAN message IgnitionStatus from the list and click [OK]. 7) Enter the following code:
on message IgnitionStatus { if(this.Ignition_Status) IgnitionState = 1; else IgnitionState = 0; }
// Ignition is On // Ignition if Off
8) Repeat steps 4-5. Then, select the CAN message LockingControlRq. 9) Enter the following code:
on message LockingControlRq { if (this.LockRequest) LockSysState.LockState = 1; else LockSysState.LockState = 0; output(LockSysState); }
// Set Lock State to Unlock
10) Repeat steps 4-5. Then, select the CAN message WindowRq. 11) Enter the following code:
on message WindowRq { if(IgnitionState) { if(this.WindowStatus == 1) { if(WindowStat.WindowPosition > 0) WindowStat.WindowPosition--; } if (this.WindowStatus == 2) { if(WindowStat.WindowPosition <= 16) WindowStat.WindowPosition++; }
} putValue(Window, WindowStat.WindowPosition); output(WindowStat); }
12) On the toolbar, click the "Compile" icon (a single arrow pointing down onto a stack of papers) or select from menu Compiler Compile. If a compile error is shown at the bottom pane of CAPL Browser, then double-click on the listed error to get close to the source code line where the problem is. Fix the error and re-compile until all problems are fixed. If the source code entered has no problem, the last line at the bottom pane of the CAPL Browser will read Compiled . 13) On the upper menu, go to File Save to save the empty CAPL program. Then, close the CAPL Browser. Now, let's verify that the setup of our simulated network behaves the way we intended. The following actions can only be performed if CANoe is licensed and CAN channels are assigned correctly. 1) In the main CANoe application, make sure the panel is open. 2) Make sure the Trace Window can be seen (menu command Window Trace). 3) Click on the [Start] button (the "lightning bolt" icon) on the CANoe toolbar. 4) On the Test Panel window, right- or left-click on the rocker switch ("IgnitionStart"). 5) A message with a new time stamp is displayed in the Trace window every time the switch is clicked, which indicates that the IgnitionStatus message is being transmitted onto the CAN bus with its signal set. 6) Right- or left-click on the lock switch (LockRq). 7) The CAN message, LockingControlRq, should appear in the Trace Window with a new timestamp every time the switch is clicked. 8) Now, press either window up/down push button. The window in the car graphic should open or close every time a button is pushed. 9) If you created value tables for any of the signals, the symbolic values will be shown next the signal under the message in the Trace window. 10) To stop the simulation, click on the [Stop] button (the stop sign icon) on the CANoe toolbar. The simulation must be stopped before any changes to the setup can be made.
Programming with CANoes Test Feature Set
CANoes Test Feature Set allows the user to test control devices and network functions through special CAPL functions. These functions are used to create tests, verify individual development steps, check prototypes, or execute regression and conformity tests. All test cases are defined with these special test functions either in XML or CAPL format or a mixture of both. A combination of test cases will then form a test module in CANoe. After running all test cases in a test module or when the test module is stopped, a test report is generated in either XML and/or HTML format. The test report indicates the verdict of the test cases, either pass or fail, with an explanation.
6.1 Differences between XML and CAPL

Users may choose to implement a test module completely in XML or CAPL. Both languages offer some advantages and disadvantages. However, a user may use both languages to implement a test module and neglect the disadvantages. Some important differences: CAPL Test cases execution order Test case execution Test groups End-user-selectable test case or test group for execution Generated test specification May be driven by runtime events May be executed more than once Dynamically defined by code No No XML Fixed Only once Statically defined Yes Yes
6.2 Programming with XML

The use of XML to create test modules is especially useful when a large number of test cases have to be generated from an existing database. Test modules are descriptively written in XML where each test case contains information about what should be tested and in what order. To program a test module in XML, Vector provides an optional, standalone tool called the Test Automation Editor (TAE). The greatest advantage in using TAE is its user-friendly GUI and that it eliminates the need to know XML and the XML schema used by CANoe. Test cases are implemented by simple drag and drop operations. If a newer database is used with the same test cases, the tool will also perform consistency checks. In this tutorial, the Test Automation Editor version 1.1 will be used to create the XML file. Other than TAE, users may use a third party XML editor such as Altovas XMLSpy together with the XML schema provide by CANoe. The schema is located in the \CANoe\EXEC32 directory. Note: TAE is not included with CANoe.
6.2.1
Test Setup
We will begin by setting up the test environment in CANoe. 1) Open the Test Setup window by going to View Test Setup. 2) Right-click on anywhere on the blank page and select New Test Environment. 3) Name the test environment Test Environment or anything you like. A folder icon should appear with the test environment name in the window.
4) Right-click on the folder icon and select Insert test module XML. An icon that looks like a network node with a T in the red box should appear with the name Test 1. 5) Right-click on Test 1, select Configuration. 6) In the Program: section, click on [Edit]. Name the XML file myTest.xml. Click [Ok]. The Test Automation Editor should open automatically. 7) A window should pop-up to Create this test module?. Click [Yes]. 8) A window titled Testmodule Properties should now pop-up. Click [Ok]. This will create a copy of the CANoe schema file in the project directory.
Note: TAE automatically loads the XML schema provided by the CANoe version that the TAE editor is opened from. To use a different XML schema file, click on the [] button next to the Individual schema file.
6.2.2
Basic Understanding of the TAE Tool
Before programming the test module, lets review the different parts of the TAE tool. As you can see in Figure 4, the tool contains four separate panes: Browser (left), List View (middle-top), Pattern Editor (middle-bottom), Pattern/Check Explorer (right-top), and Symbol/Library Explorer (right-bottom).
Figure 4 Test Automation Editor
The Browser allows the user to view the different test groups and cases. For each test case selected, the Pattern Editor will display the sequence of tests to be executed. At first there will be no tests assigned to a test case. The test patterns available are listed in the Object Explorer.
6.2.3
Creating a Test Group
Test cases may be categorized into test groups. These test groups may be nested, but they have no effect when the test cases are executed in CANoe. Using test groups can lead to better organization of the test report. 1) Right-click on myTest in the Browser pane of the TAE tool and select Add Test Group. 2) A new test group should appear with the title -title. In the Pattern Editor pane, replace -title with Simulation of Signals. This will be the new title of the test group.
6.2.4
Creating Test Cases
Now, lets create some test cases for the virtual network that was implemented earlier. 6.2.4.1 Ignition Test:
This test case will test whether the Ignition_Status CAN signal is set to the correct value when the ignition button on the panel is switched. As defined earlier, an environment variable is assigned to the ignition button. During the test, this environment variable value will be monitored together with the Ignition_Status CAN signal. Note: On a bench where a 12V ignition line is available, the same environment variable assigned to the ignition button on the panel can also be assigned to the 12V power line. CANoe also supports digital and analog I/O triggering via the Portlink feature. Please refer to CANoes online help for more information on this feature. 1) Right-click on the newly created test group and select Add Test Case. A new test case should appear under the test group. 2) Click on the new test case and in the Pattern Editor pane, replace -title with Ignition Test. 3) In the Object Explorer, click on [Patterns]. A list of test patterns should appear. Drag State Change onto the button that appears at the top of the List View pane. It should then change into three buttons: Preparation, Sequence, and Completion. Drop the test pattern onto the Sequence button. 4) Replace the -title of the State Change test pattern with Ignition On in the Pattern Editor pane. 5) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Environment data. Drag and drop the environment variable, IgnitionStart, onto the in field in the Pattern Editor pane. 6) Set the IgnitionStart value to 1. 7) Now, select Filtered by: Symbols in the Object Explorer pane. Drag and drop the signal, Ignition_Status, onto the expected field in the Pattern Editor pane. 8) Set the Ignition_Status value to 1. 9) Also in the Pattern Editor pane, set the wait period to 300. This will allow the application to wait 300ms before going on to the next test step in the test case. This 300ms is also the maximum time duration to evaluate and compare the expected results following the Stimulation (in) conditions. We have just made a test to check that the signal Ignition_Status is 1 when the environment variable IgnitionStart changes to 1. The last five steps below are used to check for ignition off/on cycle. 10) Next, select Ignition Test in the Browser section. 11) In the List View pane, right-click on the State Change test pattern under Sequence and select Copy. 12) Right-click on Sequence and select Paste. Do this twice. 13) Rename the second State Change to Ignition Off. Leave the other two patterns the same.
14) In the Ignition Off test pattern, set IgntionStart to 0 and Ignition_Status to 0. This test will check that the signal Ignition_Status is 0 when the environment variable IgnitionStart changes to 0.
The test case should appear as follows:
Figure 5 - Ignition Test 6.2.4.2 Window Panel Test
In this test, we will move the panel window by setting the environment variable, Window, value. 1) Right-click on the Simulation of Signals and select Add Test Case. A new test case should appear under the test group. 2) Click on the new test case and in the Pattern Editor pane, replace -title with Window Panel Test. 3) Click on Window Panel Test in the Browser pane. 4) In the Object Explorer pane, click on [Patterns]. Drag Stimulate Ramp onto the button that appears at the top of the List View pane. Drop the test pattern onto the Sequence button in the List View pane. 5) Replace -title with Test Window Panel States. 6) In the Pattern Editor box, set the following: cycle: 10, Sets cycle time duration: 5000, Total duration timeUp: 2500 timeDown: 2500
min: 0 max: 16
7) Click on [Symbols] under the Object Explorer. Select Filtered by: Environment data. Drag and drop Window into the Pattern Editor pane.
Figure 6 - Roll Windows Test 6.2.4.3 Test Windows Button
This test case will check that the panel buttons will trigger the correct signals to open and close the panel window. 1) Right-click on the Simulation of Signals and select Add Test Case. 2) In the List View pane under Sequence, a new test case should have appeared. Replace -title with Test Window Buttons. 3) In the Object Explorer pane, click on [Patterns]. Drag State Check onto the button that appears at the top of the List View pane. Drop the test pattern onto the Preparations button in the List View pane . 4) Replace -title of the State Check test pattern with Make sure Ignition On. 5) In the Pattern Editor pane, set the wait period to 100. 6) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Symbols. Drag and drop the signal, Ignition_Status, onto the Expected field of the Pattern Editor pane. 7) Set the Ignition_Status value to 1.
8) Now, select Filtered by: Environment data. Drag and drop the environment variable, IgnitionStart, onto the Expected field in the Pattern Editor pane. 9) Set the IgnitionStart value to 1. 10) In the Object Explorer pane, click on [Patterns]. Drag State Change onto the button that appears at the top of the List View pane. Drop the test pattern onto the Sequence button in the List View pane. 11) Replace -title of the State Change test pattern with Position = 1. 12) In the Pattern Editor pane, set the wait period to 300. 13) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Environment data. Drag and drop the environment variable, WindowDown, onto the Stimulation (in) field of the Pattern Editor pane. 14) Set the WindowDown value to 1. 15) Now, select Filtered by: Symbols. Drag and drop the signal, WindowPosition, onto the Expected field in the Pattern Editor pane. 16) Set the WindowPosition value to 1. 17) Repeat step 11 thru 17 with the following patterns in chronological order.
Pattern State Change State Change State Change State Change State Change State Change State Change State Change State Change
Title Reset Button Window Down
Wait Period 300 300 Down 300 300 300 300 300 300 300
IN Field Environment Variable and Value WindowDown = 0 WindowDown = 1 WindowDown = 0 WindowDown = 1 WindowUp = 1 WindowUp = 0 WindowUp = 1 WindowUp = 0 WindowUp = 1
EXPECTED Field Signal and Value WindowStatus = 0 WindowPosition = 2 WindowStatus = 0 WindowPosition = 3 WindowPosition = 2 WindowStatus = 0 WindowPosition = 1 WindowStatus = 0 WindowPosition = 0
Position = 2 Reset Button Window
Position = 3 Position = 2 Reset Window Up Button Position = 1 Reset Window Up Button Position = 0
Now, to finish the test case, we will turn the Ignition off and check to make sure it is off. 1) In the Object Explorer pane, click on [Patterns]. Drag State Change onto the button that appears at the top of the List View pane. Drop the test pattern onto the Completions button in the List View pane. 2) Replace -title of the State Change test pattern with Set Ignition = 0. 3) In the Pattern Editor pane, set the wait period to 300. 4) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Environment data. Drag and drop the environment variable, IgnitionStart, onto the Stimulation (in) field of the Pattern Editor pane. 5) Set the IgnitionStart value to 0. 6) Now, select Filtered by: Symbols. Drag and drop the signal, Ignition_Status, onto the Expected field in the Pattern Editor pane. 7) Set the Ignition_Status value to 0.
8) In the Object Explorer pane, click on [Patterns]. Drag State Check onto the button that appears at the top of the List View pane. Drop the test pattern onto the Completions button in the List View pane. 9) Replace -title of the State Check test pattern with Make sure Ignition is Off. 10) In the Pattern Editor pane, set the wait period to 100. 11) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Environment data. Drag and drop the environment variable, IgnitionStart, onto the Expected field in the Pattern Editor pane. 12) Set the IgnitionStart value to 0. 13) Now, select Filtered by: Symbols. Drag and drop the signal, Ignition_Status, onto the Expected field in the Pattern Editor pane. 14) Set the Ignition_Status value to 0.
Figure 7 Test Window Buttons
6.2.4.4
(Optional) Adding Window Captures to XML Test Groups/Cases
Window captures during a XML test group or test case can be added in TAE so that the user can view the bus data at that particular moment the test takes place. These window captures are limited to only the Data, Graphic, Statistics, and Trace window of CANoe. The window capture will be displayed in the generated test report after the test module has finished testing. Note: CANoe must be in the foreground for the window capture function to work correctly. Also, the window to be captured must be open before the test case starts.
To add window captures: 1) Select the test module, test group, or test case in the Browser pane. 2) In the Object Explorer pane, click on [Patterns]. Drag Window Capture onto the button that appears at the top of the List View pane. Drop the test pattern into either the Preparation, Sequence, or Completion button in the List View pane. 3) Set the following: name Data, Graphic, Statistics, or Trace; name of the window to be captured file Name of file created value Description in test report
Lets add some window captures to the Test Window Buttons case. To begin: 1) In the Browser pane, select the Test Window Buttons test case. 2) In the Object Explorer pane, click on [Patterns]. Drag Window Capture onto the button that appears at the top of the List View pane. Drop the test pattern onto the Sequence button in the List View pane. 3) Next, set the following: name Trace file winState_0 value Window State 0
4) Click on the Window Capture test pattern and drag it above the first State Change test pattern titled Position = 1. 5) Repeat steps 2-3, with the following changes: name Graphics file winState_1 value Window State 1
6) Click on the newly created Window Capture test pattern and drag it above the State Change test pattern titled Position = 2.
The test case should now appear as follows:
Figure 8 Test Window Buttons 6.2.4.5 Test Lock
In this test case, we will verify that the locks will lock and unlock correctly when the environment variables, LockRq and IgnitionStart, values are changed. 1) Right-click on the Simulation of Signals and select Add Test Case. 2) In the List View pane under Sequence, a new test case should have appeared. Replace -title with Test Lock. 3) In the Object Explorer pane, click on [Patterns]. Drag Initialize onto the button that appears at the top of the List View pane. Drop the test pattern onto the Preparations button in the List View pane. 4) Replace -title of the initialize test pattern with Initialize Variables. 5) In the Pattern Editor pane, set the wait period to 300. 6) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Environment data. Drag and drop the environment variables, IgnitionStart and LockRq, onto the Pattern Editor pane. 7) Set the IgnitionStart value to 0 and LockRq value to 0.
8) In the Object Explorer pane, click on [Patterns]. Drag State Change onto the button that appears at the top of the List View pane. Drop the test pattern onto the Sequence button in the List View pane. 9) Replace -title of the State Change test pattern with Ignition Off, LockRq = 1. 10) In the Pattern Editor pane, set the wait period to 300. 15) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Environment data. Drag and drop the environment variables, IgnitionStart and LockRq, onto the Stimulation (in) field of the Pattern Editor pane. 11) Set the IgnitionStart value to 0 and LockRq value to 1. 12) Now select Filtered by: Symbols. Drag and drop the signals, Ignition_Status and LockState, onto the Expected field of the Pattern Editor pane. 13) Set the Ignition_Status value to 0 and LockState value to 1. 14) In the List View pane, right-click on the State Change test pattern under Sequence and select Copy. 15) Right-click on Sequence and select Paste. Do this twice. 16) On the second State Change test pattern, rename the title to Ignition On, LockRq = 1. 17) Also for the second State Change test pattern, set the following values in the Pattern Editor pane: LockRq = 1 IgnitionStart = 1 Ignition_Status = 1 LockState = 1
18) On the third State Change test pattern, rename the title to Ignition On, LockRq = 0. 19) Also for the third State Change test pattern, set the following values in the Pattern Editor pane: LockRq = 0 IgnitionStart = 1 Ignition_Status = 1 LockState = 0
20) In the Object Explorer pane, click on [Patterns]. Drag Initialize onto the button that appears at the top of the List View pane. Drop the test pattern onto the Completions button in the List View pane. 21) Replace -title of the Initialize test pattern with Reset Initial Values. 22) In the Pattern Editor pane, set the wait period to 300. 23) Click on [Symbols] under the Object Explorer pane. Select Filtered by: Environment data. Drag and drop the environment variables, IgnitionStart and LockRq, onto the Pattern Editor pane. 24) Set the IgnitionStart value to 0 and LockRq value to 0.
Figure 9 Test Lock 6.2.4.6 Wait 10 Seconds
Before ending our test module, we will create a test case that will wait exactly 10 seconds before ending the test module. 1) Right-click on myTest in the Browser pane and select Add Test Case. 2) In the List View pane under Sequence, a new test case should have appeared. Replace -title with Wait 10 seconds. 3) In the Object Explorer pane, click on [Patterns]. Drag Until End onto the button that appears at the top of the List View pane. Drop the test pattern onto the Sequence button in the List View pane. 4) Replace -title of the Until End test pattern with Wait 10s before ending tests. 5) In the Pattern Editor pane, set the wait period to 10s without the quotation. If the letter s is used, it sets the unit in seconds instead of milliseconds.
Figure 10 Wait 10 seconds Now, lets save our XML file by selecting File Save Test Module. 6.2.4.7 (Optional) Adding Description to Test Groups/Cases
Comments or statements describing the test group or test case can be added in TAE to make the XML and HTML report more readable. These statements can describe many things like who wrote the test module, when it was written, the company name and address, etc. To add descriptions 1) Select the test module, test group, or test case in the Browser pane. 2) In the Pattern Editor pane, click on the down arrow on the gray toolbar to see the different descriptions that can be added and select one. A different menu is displayed depending on what is selected in the Browser pane.
Figure 11 Different Descriptions for a Test Module, Test Group, and Test Case
6.2.4.8 6.2.4.9 TAE Generated XML Code (in text view)
<?xml version="1.0" encoding="iso-8859-1"?>   <testmodule title="myTest" version="1.0" xmlns="http://www.vectorinformatik.de/CANoe/TestModule/1.12" xsi:schemaLocation="http://www.vectorinformatik.de/CANoe/TestModule/1.12 testmodule_1.12.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <testgroup title="Simulation of Signals"> <testcase title="Ignition Test" ident=""> <statechange wait="300ms" title="Ignition On"> <in> <envvar name="IgnitionStart">1</envvar> </in> <expected> <cansignal name="Ignition_Status">1</cansignal> </expected> </statechange> <statechange wait="300ms" title="Ignition Off"> <in> <envvar name="IgnitionStart">0</envvar> </in> <expected> <cansignal name="Ignition_Status">0</cansignal> </expected> </statechange> <statechange wait="300ms" title="Ignition On"> <in> <envvar name="IgnitionStart">1</envvar> </in> <expected> <cansignal name="Ignition_Status">1</cansignal> </expected> </statechange> </testcase>
<testcase title="Window Panel Test" ident=""> <miscinfo title="-title-"> <info> <name> </name> <description> </description> </info> </miscinfo> <extendedinfo type="html"> </extendedinfo> <stimulate_ramp title="Test Window Panel States" cycle="10" duration="5000" timeUp="2500" timeDown="2500" timeHigh="-timeHigh-" timeLow="-timeLow-" min="0" max="16"> <envvar name="Window"> <range> <from>0</from> <to>16</to> </range> </envvar> </stimulate_ramp> </testcase> <testcase title="Test Window Buttons" ident=""> <preparation> <statecheck wait="100" title="Make sure Ignition On"> <expected> <cansignal name="Ignition_Status">1</cansignal> <envvar name="IgnitionStart">1</envvar> </expected> </statecheck> </preparation> <windowcapture name="Trace" file="winState_0">Window State 0</windowcapture> <statechange wait="300" title="Position = 1"> <in> <envvar name="WindowDown">1</envvar> </in> <expected> <cansignal name="WindowPosition">1</cansignal> </expected> </statechange> <statechange wait="300" title="Reset Window Down Button"> <in> <envvar name="WindowDown">0</envvar> </in> <expected> <cansignal name="WindowStatus">0</cansignal> </expected> </statechange> <windowcapture name="Graphics" file="winState_1">Window State 1</windowcapture> <statechange wait="300" title="Position = 2"> <in> <envvar name="WindowDown">1</envvar> </in> <expected> <cansignal name="WindowPosition">2</cansignal> </expected> </statechange>
<statechange wait="300" title="Reset Window Down Button"> <in> <envvar name="WindowDown">0</envvar> </in> <expected> <cansignal name="WindowStatus">0</cansignal> </expected> </statechange> <statechange wait="300" title="Position = 3"> <in> <envvar name="WindowDown">1</envvar> </in> <expected> <cansignal name="WindowPosition">3</cansignal> </expected> </statechange> <statechange wait="300" title="Position = 2"> <in> <envvar name="WindowUp">1</envvar> </in> <expected> <cansignal name="WindowPosition">2</cansignal> </expected> </statechange> <statechange wait="300" title="Reset Window Up Button"> <in> <envvar name="WindowUp">0</envvar> </in> <expected> <cansignal name="WindowStatus">0</cansignal> </expected> </statechange> <statechange wait="300" title="Position = 1"> <in> <envvar name="WindowUp">1</envvar> </in> <expected> <cansignal name="WindowPosition">1</cansignal> </expected> </statechange> <statechange wait="300" title="Reset Window Up Button"> <in> <envvar name="WindowUp">0</envvar> </in> <expected> <cansignal name="WindowStatus">0</cansignal> </expected> </statechange> <statechange wait="300" title="Position = 0"> <in> <envvar name="WindowUp">1</envvar> </in> <expected> <cansignal name="WindowPosition">0</cansignal> </expected> </statechange>
<completion> <statechange wait="300" title="Set Ignition = 0"> <in> <envvar name="IgnitionStart">0</envvar> </in> <expected> <cansignal name="Ignition_Status">0</cansignal> </expected> </statechange> <statecheck wait="100ms" title="Make sure Ignition is Off"> <expected> <cansignal name="Ignition_Status">0</cansignal> <envvar name="IgnitionStart">0</envvar> </expected> </statecheck> </completion> </testcase> <testcase title="Test Lock" ident=""> <preparation> <initialize title="Initialize Variables" wait="300"> <envvar name="IgnitionStart">0</envvar> <envvar name="LockRq">0</envvar> </initialize> </preparation> <statechange wait="200" title="Ignition Off, Lock Rq = 1"> <in> <envvar name="IgnitionStart">0</envvar> <envvar name="LockRq">1</envvar> </in> <expected> <cansignal name="Ignition_Status">0</cansignal> <cansignal name="LockState">1</cansignal> </expected> </statechange> <statechange wait="200" title="Ignition On, Lock Rq = 1"> <in> <envvar name="LockRq">1</envvar> <envvar name="IgnitionStart">1</envvar> </in> <expected> <cansignal name="Ignition_Status">1</cansignal> <cansignal name="LockState">1</cansignal> </expected> </statechange> <statechange wait="300" title="Ignition On, Lock Rq = 0"> <in> <envvar name="IgnitionStart">1</envvar> <envvar name="LockRq">0</envvar> </in> <expected> <cansignal name="LockState">0</cansignal> <cansignal name="Ignition_Status">1</cansignal> </expected> </statechange>
<completion> <initialize title="Reset Initial Values" wait="300"> <envvar name="IgnitionStart">0</envvar> <envvar name="LockRq">0</envvar> </initialize> </completion> </testcase> </testgroup> <testcase title="Wait 10 seconds" ident=""> <untilend title="Wait 10s before ending tests" wait="10s" /> </testcase>
6.3 Notes on writing XML files without TAE

Writing XML test scripts is not a difficult task when using task oriented editor such as TAE. When TAE is not available, writing XML that produces pleasing output structures can be somewhat challenging. This section provides some user guidelines to make this task less frustrating.
6.3.1
Empty Spaces and Line Breaks
XML files that include empty spaces and line breaks within the XML tag may lead to less than beautiful output. This practice may also lead to the failure of a test because certain parameters cannot be assigned the correct values.
For example,
<description>Description test</description>
Is not the same as the following:

<description> Description text </description>
Line breaks like those above will be lost when the HTML report is generated. However, it is possible to explicitly insert line breaks in the descriptions of test modules, test groups, test cases, and test steps in the HTML test report by using the following: 1) \n in an XML test module 2) \\n in a CAPL function call
6.3.2
Characters with Fixed Meanings in XML
The characters <, >, and & have special meaning in XML and cannot occur in character strings. To include them into character strings use &alt;, >, and &amp instead.
6.3.3
Inserting HTML code
Since HTML is written in a similar way to XML, problems could arise when processing of XML files in the <extendedinfo> XML lines.
Potential problems that can occur are: 1) Validating parser reports errors when the HTML code was not recognized. 2) HTML permit tags not closed properly.
6.4 Programming with CAPL

Other XML test modules in CANoe may be implemented in the CAPL language. With CAPL, test cases will be executed in the order in which they are written in the MainTest() test control. Unlike XML the test cases written and defined in CAPL can be used more than once. Also, it is important to note that the functionality of a test module CAPL program is not quite the same as that of a regular CAPL program written to simulate a network node.
6.4.1
Test Setup
Lets begin by setting up the test environment in CANoe. 1) Open the Test Setup window by going to View Test Setup. 2) Right-click on the test environment Test Environment and select Insert test module. An icon that looks like a network node with a T in the red box should appear with the name Test 2. 3) Right-click on Test 2, select Configuration. 4) In the Module Name: section, rename the module as myTest-CAPL. 5) In the Program: section, click on [Edit]. Name the CAN file Tester-capl.can. Click [Ok]. The CAPL Browser should open automatically.
Note: The CAPL Browser is a tool that comes with the CANoe installation. Typically, this browser is used to implement a CAPL program to simulate a network node, but it is possible to use it to implement test cases for a test module.
6.4.2
Creating a Test Module
The CAPL template opened by the CAPL Browser is different than the CAPL template for a network node. There are two new event types, TestControl and Testcase. The TestControl event drives which and when each test cases should be executed. The test cases are defined in the Testcase event type. Note: User defined CAPL test functions cannot be used in CAPL test modules. 6.4.2.1 MainTest()
Under TestControl, we will create our main program. This will specify the sequence of test cases to run. 1) In the variables pane (top-right), type the following code:
variables { message WindowRq WinRq; message WindowState WinStat; message LockingSysState LockSysState; const int kWAIT_TIMEOUT = 500; // 500msecs long WaitResult; int msgReceived = 1; }
2) Expand TestControl on the left pane, right-click on MainTest() and select New. 3) Type the following code for MainTest():
void MainTest() { word count = 1; /* Add Description of Test Module */ TestModuleTitle("myTest"); TestModuleDescription("Sample test cases written in CAPL."); TestModuleDescription("This is the same test that was written in XML."); /* Add Information into Test engineer Information Table */ TestReportAddEngineerInfo("Company", "Vector CANtech, Inc."); TestReportAddEngineerInfo("Tester name", "vadeli"); TestReportAddEngineerInfo("Version", "1.0"); TestWaitForTimeout(2000); // Wait for 2sec
/* Add Test Groups/Cases */ TestGroupBegin("Simulation of Signals", "Test node communication"); TC_IgnitionTest(); // Ignition Test Case // Rolling Windows Down and Up while(count != 16) { TC_WindowDown(count); TestWaitForTimeout(kWAIT_TIMEOUT); count++; } count = count-2; while(count != 0) { TC_WindowUp(count); TestWaitForTimeout(kWAIT_TIMEOUT); count--; } TC_WindowUp(0); TestWaitForTimeout(kWAIT_TIMEOUT); // Test Lock TC_TestLock(); // Wait 10secs before end TC_Wait10sec(); TestGroupEnd(); }
The main program should first set the description of the test module and engineer information and then run through our test cases in the order they are called starting with the Ignition test case. 6.4.2.2 Test Cases
We will create 5 different test cases in this CAPL test module. Each test case is created as follows: 1) Right-click on Testcase in the left pane, select New. Do this 5 times. 2) Once a new testcase event tag is created on the middle pane, replace <newTestcase> that is highlighted with the following: TC_IgnitionTest
TC_TestLock TC_Wait10sec TC_WindowDown TC_WindowUp
6.4.2.2.1
TC_IgnitionTest()
This test case verifies that the ignition turns off or on correctly when the environment variable is set. Click on the TC_IgnitionTest test case on the left pane. In the middle pane, type the following code for TC_IgnitionTest:
testcase TC_IgnitionTest() { message IgnitionStatus IgnitStat; float IgnitStart_Value; // Set Test case title and test step #1 description TestCaseTitle("Ignition Start/Stop Check", "Ignition test"); TestStep("Test Step 1", "Set envVar signal 'IgnitionStart' = 0"); // Set IgnitionStart = 0 putValue(IgnitionStart, 0); // Wait for the environment variable IgnitionStart to occur for 500ms WaitResult = TestWaitForEnvVar(IgnitionStart, kWAIT_TIMEOUT); // Determine results of test step switch(WaitResult) { case 0: TestStepFail("Test Step 1", "envVar not received!"); break; case 1: // Retrieve the value of IgnitionStart & store in IgnitStart_Value TestGetWaitEventEnvVarData(0, IgnitStart_Value); if(!IgnitStart_Value) TestStepPass("Test Step 2", "Switch is working!"); else TestStepFail("Test Step 1", "Switch not working!"); break; } TestWaitForTimeout(kWAIT_TIMEOUT); // Wait for 500ms
// Set test step #2 description TestStep("Test Step 2", "Set envVar signal 'IgnitionStart' = 1); // Set IgnitionStart = 1 putValue(IgnitionStart, 1); // Wait for the message IgnitionStatus to occur for 500ms WaitResult = TestWaitForMessage(IgnitionStatus, kWAIT_TIMEOUT); // Determine results of test step switch(WaitResult) { case 0: TestStepFail("Test Step 2", "Signal not received"); break; case 1: // Retrieve the message data of IgnitStat
TestGetWaitEventMsgData(IgnitStat); if(IgnitStat.Ignition_Status) TestStepPass("Ignition on!"); else TestStepFail("Ignition off!"); break; } TestWaitForTimeout(kWAIT_TIMEOUT); } // Wait for 500ms
6.4.2.2.2
TC_TestLock()
This test case will verify that the locks of the system work properly when the lock panel button is pushed. The test results will be displayed in the test report. Click on the TC_TestLock test case on the left pane. In the middle pane, type the following code for TC_TestLock:
testcase TC_TestLock () { // Test case & step #1 description TestCaseTitle("", "Test Lock"); TestStep("Test Step 1", "Set envVar signal 'LockRq' = 1"); // Set LockRq = 1 putValue(LockRq, 1); // Wait for the message LockingSysState to occur for 500ms WaitResult = TestWaitForMessage(LockingSysState, kWAIT_TIMEOUT); // Determine results of test step switch(WaitResult) { case 0: TestStepFail("Test Step 1", "Message not received"); break; case 1: // Retrieve the message data of LockSysState TestGetWaitEventMsgData(LockSysState); // If Lock state is locked (=1), then test passed. if(LockSysState.LockState) TestStepPass("Locking Passed!"); else TestStepFail("Still Unlocked"); break; } TestWaitForTimeout(kWAIT_TIMEOUT); // Wait for 500ms
// Test step #2 description TestStep("Test Step 2", "Set envVar signal 'LockRq' = 0"); // Set LockRq = 0 putValue(LockRq, 0); // Wait for the message LockingSysState to occur for 500ms WaitResult = TestWaitForMessage(LockingSysState, kWAIT_TIMEOUT); // Determine results of test step switch(WaitResult) { case 0: TestStepFail("Test Step 2", "Message not received"); break;
case 1: // Retrieve the message data of LockSysState TestGetWaitEventMsgData(LockSysState); // If Lock state is unlocked (=0), then test passed. if(LockSysState.LockState == 0) TestStepPass("Unlocking Passed!"); else TestStepFail("Still Locked"); break; } TestWaitForTimeout(kWAIT_TIMEOUT); // Wait for 500ms }
6.4.2.2.3
TC_Wait10sec()
The purpose of this test case is just to wait 10 seconds. Click on the TC_Wait10sec test case on the left pane. In the middle pane, type the following code for TC_Wait10sec:
testcase TC_Wait10sec () { // Test case description TestCaseTitle("Wait", "10sec Wait Period"); // Wait for 10 seconds TestWaitForTimeout(10000); }
6.4.2.2.4
TC_WindowDown()
This test case will roll the window down once each time it is called by the MainTest function. It also checks that the position of the window is the same as window position value provided to the test case as an integer. If the test is true, a screenshot of the Trace window will be taken. Click on the TC_WindowDown test case on the left pane. In the middle pane, type the following code for TC_WindowDown:
testcase TC_WindowDown (int value) { // Test case title description TestCaseTitle("Rolling Windows", "Window Down"); // WindowDown = 1 putValue(WindowDown, 1); // Retrieve message content WindowState WaitResult = TestWaitForMessage(WindowState, kWAIT_TIMEOUT); // Determine results of test step switch(WaitResult) { case 0: TestStepFail("Test Step 2", "Message not received"); break; case 1: // Retrieve the message data of WinStat TestGetWaitEventMsgData(WinStat); // If current window position = theoretical window position, then test // step has passed. Also, take a screenshot of the Trace window if(WinStat.WindowPosition == value) { TestStepPass("Rolling Window Down Passed!"); TestReportAddWindowCapture("Trace", "" , "Window Down"); }
else TestStepFail("Window Position is incorrect!"); break; } // Make sure to reset Window Down button to original position putValue(WindowDown, 0); }
6.4.2.2.5
TC_WindowUp()
This test case will roll the window up once each time it is called by the MainTest function. It also checks that the position of the window is the same as window position value provided to the test case as an integer. If the test is true, a screenshot of the Data window will be taken. Click on the TC_WindowUp test case on the left pane. In the middle pane, type the following code for TC_WindowUp:
testcase TC_WindowUp (int value) { // Test case title description TestCaseTitle("Rolling Windows", "Window Up"); // WindowDown = 1 putValue(WindowUp, 1); // Retrieve message content WindowState WaitResult = TestWaitForMessage(WindowState, kWAIT_TIMEOUT); // Determine results of test step switch(WaitResult) { case 0: TestStepFail("Rolling Windows", "Message not received"); break; case 1: // Retrieve the message data of WinStat TestGetWaitEventMsgData(WinStat); // If current window position = theoretical window position, then test // step has passed. Also, take a screenshot of the Data window. if(WinStat.WindowPosition == value) { TestStepPass("Rolling Window Up Passed!"); TestReportAddWindowCapture("Data", "" , "Window Up"); } else TestStepFail("Window Position is incorrect!"); break; } // Make sure to reset Window Up button to original position putValue(WindowUp, 0); }
6.4.3
(Optional) Adding Window Captures to CAPL Test Groups/Cases
Window captures during a CAPL test group or test case can also be added so that the user can view the bus data at that particular moment the test takes place. These window captures are limited to only the Data, Graphic, Statistics, and Trace window of CANoe. The window capture will be displayed in the generated test report after the test module has finished testing. Note: CANoe must be in the foreground for the window capture function to work correctly. Also, the window to be captured must be open before the test case starts.
To add window captures, the following CAPL test function is used:

TestReportAddWindowCapture("<Window Name>", "<test step description>" , "<description>");
An example of a window capture within the TC_WindowUp() test case is shown below:
if(WinStat.WindowPosition == value) { TestStepPass("Rolling Window Up Passed!"); TestReportAddWindowCapture("Trace", "" , "Window Up"); }
6.4.4
(Optional) XML Linked CAPL Test Cases and Functions
Alternatively, CAPL test cases and/or functions may also be included into an XML test module. To do this, a CAPL test case library containing these test case and/or functions must be configured to the XML test module. Note: This test case library is created by the user.
CAPL test cases in XML are important to use because it gives the user with more flexibility handling messages and signals to create user-specific test checks. These CAPL test cases are used when a user wants to run a userdefined test case within XML.
Unlike CAPL test cases, user defined CAPL test functions can only be use in XML test modules. The importance of using CAPL test functions is that it provides the user with more flexibility when handling signal stimulations such as simulation of acceleration or deceleration of a vehicle. A user may use a test function to simulation a situation in order to check whether or not their system is performing correctly. Note: CAPL test functions are created by the user.
To setup an XML test module with a CAPL test case library, the following steps are taken: 1. In CANoe, right-click on the XML test module. 2. On the Libraries tab, click on Add and select your particular CAPL test case library (*.CAN) file which contains your defined CAPL test cases and/or functions you would like to use. Press Open.
Once the CAPL test case library file has been associated, all CAPL test cases and/or functions defined within the test case library file should be viewable in the TAE environment in the Library Explorer pane as seen in Figure 12.
To use the test cases: 1) Drag and drop the test case of your choice into the Browser pane 2) Set the title for the test case
To use test functions: 1) Drag and drop the test function of your choice into the List View pane of any test group or case 2) Set the title for the test step 3) Set any other required input parameters the test function may have
Below are examples of a CAPL test case and CAPL test function.
Example of CAPL Test Case:

//Function to Wait 1 Second testcase TC_Wait1sec () { // Test case description TestCaseTitle("Wait", "10sec Wait Period"); // Wait for 1 seconds TestWaitForTimeout(1000); }
Example of CAPL Test Function:

//Function to Set Window Position to User-defined Position testfunction TF_SetWindowPos(int targetPos){ int currentPos; putValue(IgnitionStart, 1); TestStep("Window Position Change", "Requested position: %d", targetPos); currentPos = getValue(Window); if(targetPos > currentPos) { while (targetPos != currentPos) { putValue(WindowDown, 1); TestWaitForTimeout(500); putValue(WindowDown, 0); TestWaitForTimeout(500); currentPos = getValue(Window); } } else if(targetPos < currentPos) { while (targetPos != currentPos) { putValue(WindowUp, 1); TestWaitForTimeout(500); putValue(WindowUp, 0); TestWaitForTimeout(500); currentPos = getValue(Window); } } TestStep("Position Change", "Reached Position: %d", currentPos); }
An example of how a user may set up a test case using CAPL test functions is shown as follows:
Figure 12 - Usage of CAPL Test Functions
6.4.5
Vector Test Feature Set Functions
To view more detailed explanation of the many Test Feature Set functions provided by Vector (e.g. TestWaitForMessage(), TestStepPass()), please go to CANoes Help document (Help -> Contents, search for Test Feature Set CAPL functions).
6.5 Running the Test Modules 6.5.1 Compiling the Test files
Before we can begin the tests, we must first compile the tests files we have created. 1) In CANoe, in the Test Setup window, right-click a test module. 2) Select Compile.
6.5.2
Testing the XML Test file
Now that we have our application programmed and our XML file of test cases built and compiled, we can begin the testing of our test cases. Assuming CANoe is licensed and all CAN channels are set up properly, perform the following steps: 1) In CANoe, hit the lightning bolt button to start the measurement. The network simulation should now be started; nothing should appear in the Trace window. 2) Now, there should be a window titled myTest in CANoe opened. If not, double-click on the myTest test module in the Test Setup window. Near the bottom-right of the myTest window, there should be toolbar with a red play button. 3) Push the red play button to start the test module to execute the test cases.
As each test case is being executed, you should see a clock icon with the words Running next to it as shown in Figure 13. When a test case finishes running, its verdict is displayed on the right-most column with either a checkmark with the words Passed in green or an x with the words Failed in red.
Note: If one test case in a test group fails, than the whole test group fails. This also fails the test module as well.
Figure 13 Testing of XML File
6.5.3
Testing the CAPL Test file
Lets test the CAPL Test file as well. 1) In CANoe, hit the lightning bolt button to start the measurement. The network simulation should now be started; nothing should appear in the Trace window. 2) Double-click on the myTest-CAPL test module in the Test Setup window to open the test module window. 3) Near the bottom of the myTest-CAPL window, there should be a toolbar with a red play button. Push this button to start the test module to execute the test cases.
As each test case is being executed, you should see a clock icon with the words Running next to it as shown in Figure 13. When a test case finishes running, its verdict is displayed on the right-most column with either a checkmark with the words Passed in green or an x with the words Failed in red.
6.5.4
Viewing the Test Report
After all test cases have been executed, a test report may be generated in XML and in HTML. For HTML test reports, there are two types of report formats: one page and extended test reports. These are discussed in the following sections. Note: Multiple test reports can be combined into one large test report.
To view the test report of a test module, click on the following figure:
icon in the test module window. This is shown in the
Figure 14 Location of Test Report Button
Alternatively, the XML or HTML test report may be viewed by double-clicking on the file in the directory the report was saved. 6.5.4.1 One Page Test Report
A one page test report is the default setting in CANoe. This one page format allows the report to be printed as a handout. To view this report after the test module has finished executing all the test cases, go to the toolbar of the test module window and click on the button that has an x and a green check mark on it. This should open the report in a web browser as an HTML. The XML file will be found in the current project directory (in this case testTFS) named report.xml.
Figure 15 One Page Test Report for CAPL Test Module
6.5.4.2
Extended Test Report
The test report may be organized into multiple frames for easy navigation and debugging purposes. This format is not suitable for printing but a log file may be added to one of the frames for debugging purposes. When a time stamp (hyperlink in blue) under the test case is clicked on, the log file will auto-scroll to that time displaying the data for evaluation. To view the extended test report format, we must first set it up. Note: To make this report layout works, a Java plug-in must be installed to the web browser. 1) In the Test Setup window, right-click on the test module. Select Configuration. 2) Click on the Report tab.
3) In the HTML section, click on the [] button. By default it should open to the folder C:\...CANoe 7.0\Exec32\report\. 4) A list of *.xslt files should appear, select the extendedNavigation.xslt. Then, hit the [Open] button.
After the test module is done executing all of its test cases, click on the button on the toolbar that has an x and a green check mark on it. The extended test report should open in a web browser as an HTML file. It should appear as follows:
Figure 16 Extended Test Report
6.5.4.3
Combined Test Report
Test reports of different test modules may be organized into one large test report. This includes combining CAPL test reports with XML test reports. The format of the test output can be set match a one page or extended test report. To combine test reports, we must first set it up. Note: To make this combined test report: 1) In the Test Setup window, right-click on the test environment. Select Configure Report.
2) On the Report tab, select or create a file to save the combined test report under the XML report file by clicking on the [] button. 3) In the HTML section, click on the [] button. By default it should open to the folder C:\...CANoe 7.0\Exec32\report\. 4) A list of *.xslt files should appear, select the extendedNavigation.xslt. Then, hit the [Open] button. 5) Right-click on a test module you wish to have its test report combined, select Configuration. 6) On the Report tab, in the HTML section, click on the [] button and select merge.xslt. 7) Repeat step 6 for each test module you wish to have in the combine test report.
Next, well run the test modules sequentially by starting the CANoe measurement. Then, well right-click on the test environment and select Execute test modules sequentially. After the all tests have completed, right-click the test environment again and this time select Create report. The report will be located in our test directory, click on the generated HTML file. It should look as follows:
Figure 17 Combined Extended Test Report 6.5.4.4 Window Captures and Images
If window captures are used within XML or CAPL test groups or cases such as in Section 6.2.4.4 & 6.4.3, then the generated test report(s) will be configured to contain screenshots of the user-specified CANoe window (Data, Graphics, Statistics, and/or Trace). Unless specified by the user, these window captures created by CANoe can be found in the report folder (or the folder with the label of your test report name) within the test directory containing the CANoe configuration.
Note: CANoe must be running in the foreground for the window captures to work properly.
Sample image that would appear in the test report for the XML code:
<windowcapture name="Trace" file="winState_0">Window State 0</windowcapture>
Figure 18 - Trace Window Capture
Not only can the test report contain screenshots, it may also be set up to contain user-specified images using the CAPL test function TestReportAddImage().
Figure 19 - Example of User-specified Image & CAPL Code
Conclusion
We have now successfully created a working network system with two nodes and a panel with functional windows and buttons. Also, we have created two test files of different formats, XML and CAPL, to test the network functionality.
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: info@vector-informatik.de France, Belgium, Luxemburg: Vector France SAS 168 Boulevard Camlinat 92240 Malakoff FRANCE Phone: +33 1 42 31 40 00 Fax: +33 1 42 31 40 09 Email: information@vector-france.fr Sweden, Denmark, Norway, Finland, Iceland: VecScan AB Theres Svenssons Gata 9 41755 Gteborg SWEDEN Phone: +46 31 764 76 00 Fax: +46 31 764 76 19 Email: info@vecscan.com
United Kingdom, Ireland: Vector GB Ltd. Rhodium Central Boulevard Blythe Valley Park Solihull, Birmingham West Midlands B90 8AS UNITED KINGDOM Phone: +44 754 9001197 Email: info@vector-gb.co.uk
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: info@vector-cantech.com
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: info@vector-japan.co.jp
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: info@vector-korea.com

An and 1 118 Canoe Tfs Tutorial

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An and 1 118 Canoe Tfs Tutorial

Uploaded by

Copyright:

Available Formats

CANoe Test Feature Set Tutorial

Version 2.0 2009-05-28 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

2 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

About this Tutorial

3 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Simulating a CAN Network

5.1 Create a New Directory

5.2 CAN Network Database Setup

Creating a New Database File

4 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Creating Network Nodes

5 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Creating and Assigning Value Tables (Optional)

6 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Creating Environment Variables

7 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

5.3 Associate a Database

5.4 Create User Test Panel

Opening Panel Designer

8 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

LockRq Window with a State Count of 17.

Adding Push Buttons

Figure 1 Test Panel

5.5 Associate the Panel to CANoe

9 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

5.6 Add Nodes to the Network

Figure 2 CANoe Simulation Setup with Two New Nodes

5.7 Create Node Behavior

10 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Figure 3 CAPL Browser

Programming the MainControl Node Behavior

11 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

// Request Unlock Doors // Request Lock Doors

output(LkCtrlRq); // Outputs message onto the bus }

12 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Programming Doors Node Behavior

// Ignition is On // Ignition if Off

// Set Lock State to Unlock

13 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

} putValue(Window, WindowStat.WindowPosition); output(WindowStat); }

14 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Programming with CANoes Test Feature Set

6.1 Differences between XML and CAPL

6.2 Programming with XML

15 Application Note AN-AND-1-118

CANoe Test Feature Set Tutorial

Basic Understanding of the TAE Tool

Figure 4 Test Automation Editor

16 Application Note AN-AND-1-118