3 - 2392.0_ADD_Nexteer_CBD_GMLAN_31_Mch_Renesas RH850 -CBD1400346.D01s

ADDENDUM TO
MASTER SOFTWARE LICENSE AGREEMENT 
Notice: This Addendum shall be deemed accepted regardless of signature pursuant to Section 7.1 of the Master Software License Agreement
between Vector CANtech, Inc. and Nexteer Automotive Corporation (Agreement") if not otherwise rejected along with the Licensed Software in
accordance with Section 7.2 of the Agreement.
0.1
Addendum Effective Date:
2016/04/29
0.2
Pursuant to and fully incorporated into the Vector CANtech, Inc. 
2009/11/01
Master Software License Agreement, dated:
0.3
License Serial Number
CBD1400346
1.0
GENERAL TERMS
APPLICABLE TO ALL  SOFTWARE LISTED IN ADDENDUM
1.1
Licensee (Licensee Division):
Nexteer Automotive Corporation
1.2
Sublicense Affiliate(s):
Not Applicable
1.3
Excluded Affiliates and/or Divisions:
Not Applicable
1.4
Sublicense Contractor(s):
All Licensee software engineering sub-contractors which are not affiliated with a competitor of
Vector
1.5
Excluded Contractors:
All contractors competitive with Vector, including but not limited to, the Elektrobit Group Plc, all
affiliates thereof (including 3SOFT), Mentor Graphics Corp. and all affiliates thereof (including
Volcano Communications Technologies AB, and Dearborn Group Inc.
1.6
License Term:
Perpetual
1.7
Geographical Restriction on License:
North America (the geographic restriction applies only to the "Point of Sale" location of the 
Licensee business entities that may enter into business agreements for the sale of products 
incorporating the Vector Licensed Software listed below. The geographic restriction does not 
restrict the location in which the Licensee or Licensee's contractors develop, and/or 
manufacture the Licensee's products.
1.8
Standard Warranty for Licensed Software:
Two (2) Years
1.9
Extended Warranty and Extended Warranty Fee:
Two (2) Years
1.10 Total Warranty Period for Licensed Software:
Four (4) Years
2.0
Identification of Protocol-Specific (CAN, LIN, Flexray, ect.) 
Multi Channel CAN Driver- High End
Embedded Software:
2.1
OEM Restriction:
No OEM Restriction
2.2
Licensed Application:
Restricted solely to the development of electronic modules manufactured by the Licensee.
2.3
Excluded Applications:
All applications not specified in Part 2.2 of this Addendum, including but in no way limited to:
network development and analysis tools for sale, aerospace, locomotive, medical, military and
earth moving applications, and for those safety-critical component applications, Licensee hereby
acknowledges, agrees, and assumes sole responsibility for the fact that Vector is unable to
assess and warrant the fitness of the Licensed Software for integration and use with the safety-
critical applications contemplated by Licensee; however, irrespective of such, Vector would be
willing (for an additional cost) to assess and consult on the Licensed Software for integration
and use with such applications without assuming any additional responsibility or liability
therefore.
2.4
General Microcontroller Family:
Renesas RH850 P1X
2.5
General Compiler Family:
Greenhills
2.6
Specific Microcontroller:
R7F701311
2.7
Specific Compiler Version:
2015.1.7
2.8
Applicable Specifications:
Vector User Manual supplied with the CAN-Specific Embedded Software, to the exclusion of all
other specifications, documents, previous or subsequent manual versions, and/or written or oral
communications.
2.9
Corresponding Software License Fee:
Included In Total Software Fee.
3.0
Identification of OEM-Specific Embedded Software:
GMLAN_3.1 Multi Channel-SIP
-GMLAN Interaction Layer Multi Channel
-GMLAN Network Management Multi Channel  
-GMLAN Transport Protocol Multi Channel 
- CANdesc (GM)
-GMLAN Gateway Diagnostics Add-on (GGDA)
-XCP-on-CAN
3.1
OEM Restriction:
Restricted solely to the following original equipment manufacturer (OEM): General Motors, LLC,
to the exclusion of all subsidiaries and affiliates of the same.
3.2
Licensed Application:
Restricted solely to the development and manufacturing of electronic modules for the
automotive industry, on GM product/vehicle applications, and for component application for
integration into those products manufactured by GM.
© 2016 Vector CANtech, Inc.
Page 1 of  3
CBD1400346_ PO#_UI129133

---

ADDENDUM TO
MASTER SOFTWARE LICENSE AGREEMENT 
3.3
Excluded Applications:
All applications not specified in Part 3.2 of this Addendum, including but in no way limited to:
network development and analysis tools for sale, aerospace, locomotive, medical, military and
earth moving applications, and for those safety-critical component applications, Licensee hereby
acknowledges, agrees, and assumes sole responsibility for the fact that Vector is unable to
assess and warrant the fitness of the Licensed Software for integration and use with the safety-
critical applications contemplated by Licensee; however, irrespective of such, Vector would be
willing (for an additional cost) to assess and consult on the Licensed Software for integration
and use with such applications without assuming any additional responsibility or liability
therefore.
3.4
General Microcontroller Family:
Renesas RH850 P1X
3.5
General Compiler Family:
Greenhills
3.6
Specific Microcontroller:
R7F701311
3.7
Specific Compiler Version:
2015.1.7
3.8
Applicable Specifications:
To the exclusion of all other specifications, documents, previous or subsequent GMLAN 
versions, and/or written or oral communications, the following specifications apply: 
Based on the following specifications:
GMW3104_Communication_Strategy_Specification_v1-5R03Final and ISO15765-2.2.
The CANdesc software component provides services according to the specification
ISO/DIS 15765-3 (Diagnostics on CAN) dated 1999-11-30. In addition the
diagnostics layer provides enhancements of application functions as specified
by GMW 3110 Version 1.6.
3.8
Applicable Specifications:
The CANdesc AddOn "GMLAN Extension Gateway" fulfills the requirements
(multi channel ECUs) of the GMW3110 V1.6 specification (s. chapter 6.3.4).
XCP-on-CAN: ASAM specification, version 1.0 and the XCP on CAN transport Layer for 
the Vector CAN Driver.
3.9
Corresponding Software License Fee:
Included In Total Software Fee.
4.0
Identification of Application-Specific Embedded Software:
Not Applicable
4.1
OEM Restriction:
Not Applicable
4.2
Licensed Application:
Not Applicable
4.3
Excluded Applications:
Not Applicable
4.4
General Microcontroller Family:
Not Applicable
4.5
General Compiler Family:
Not Applicable
4.6
Specific Microcontroller:
Not Applicable
4.7
Specific Compiler Version:
Not Applicable
4.8
Applicable Specifications:
Not Applicable
4.9
Corresponding Software License Fee:
Not Applicable
5.0
Identification of Flash-Specific Embedded Software:
Not Applicable
5.1
OEM Restriction:
Not Applicable
5.2
Licensed Application:
Not Applicable
5.3
Excluded Applications:
Not Applicable
5.4
General Microcontroller Family:
Not Applicable
5.5
General Compiler Family:
Not Applicable
5.6
Specific Microcontroller:
Not Applicable
5.7
Specific Compiler Version:
Not Applicable
5.8
Applicable Specifications:
Not Applicable
5.9
Corresponding Software License Fee:
Not Applicable
6.0
Identification of Generation Tool PC Software:
GMLAN Generation Tool
6.1
OEM Restriction:
Restricted solely to the following original equipment manufacturer (OEM): General Motors, LLC,
to the exclusion of all subsidiaries and affiliates of the same.
6.2
Licensed Application:
Restricted solely to the development and manufacturing of electronic modules for the
automotive industry, on GM product/vehicle applications, and for component application for
integration into those products manufactured by GM.
6.3
Excluded Applications:
All applications not specified in Part 6.2 of this Addendum, including but in no way limited to:
network development and analysis tools for sale, aerospace, locomotive, medical, military and
earth moving applications, and for those safety-critical component applications, Licensee hereby
acknowledges, agrees, and assumes sole responsibility for the fact that Vector is unable to
assess and warrant the fitness of the Licensed Software for integration and use with the safety-
critical applications contemplated by Licensee; however, irrespective of such, Vector would be
willing (for an additional cost) to assess and consult on the Licensed Software for integration
and use with such applications without assuming any additional responsibility or liability
therefore.
6.4
General Microcontroller Family:
Renesas RH850 P1X
© 2016 Vector CANtech, Inc.
Page 2 of  3
CBD1400346_ PO#_UI129133

---

ADDENDUM TO
MASTER SOFTWARE LICENSE AGREEMENT 
6.5
General Compiler Family:
Greenhills
6.6
Specific Microcontroller:
R7F701311
6.7
Specific Compiler Version:
2015.1.7
6.8
Applicable Specifications:
To the exclusion of all other specifications, documents, previous or subsequent GMLAN 
versions, and/or written or oral communications, the following specifications apply: 
Based on the following specifications:
GMW3104_Communication_Strategy_Specification_v1-5R03Final and ISO15765-2.2.
The CANdesc software component provides services according to the specification
ISO/DIS 15765-3 (Diagnostics on CAN) dated 1999-11-30. In addition the
diagnostics layer provides enhancements of application functions as specified
by GMW 3110 Version 1.6.
6.8
Applicable Specifications:
The CANdesc AddOn "GMLAN Extension Gateway" fulfills the requirements
(multi channel ECUs) of the GMW3110 V1.6 specification (s. chapter 6.3.4).
XCP-on-CAN: ASAM specification, version 1.0 and the XCP on CAN transport Layer for 
the Vector CAN Driver.
6.9
Corresponding Software License Fee:
Included In Total Software Fee.
7.0
Identification of Flash Programming Tool PC Software:
Not Applicable
7.1
OEM Restriction:
Not Applicable
7.2
Licensed Application:
Not Applicable
7.3
Excluded Applications:
Not Applicable
7.4
General Microcontroller Family:
Not Applicable
7.5
General Compiler Family:
Not Applicable
7.6
Specific Microcontroller:
Not Applicable
7.7
Specific Compiler Version:
Not Applicable
7.8
Applicable Specifications:
Not Applicable
7.9
Corresponding Software License Fee:
Not Applicable
8.0
Total License Fee for All Software Listed in This Addendum:
$198,653 
$198,653 
9.0
This Addendum, having an effective date set forth above in Part 0.1 hereof, shall be subject to the terms, conditions, and limitations of the Master Software License
Agreement specified in Part 0.2 hereof, which are  hereby incorporated into and made a part of this Addendum by reference as though fully set forth herein.
© 2016 Vector CANtech, Inc.
Page 3 of  3
CBD1400346_ PO#_UI129133

---

6 - AN-IND-8-003_GM_Support_in_CANoe_7.2s

 
GM Support in CANoe 7.2 
Version 2.1 
2010-02-23  
Application Note AN-IND-8-003 
 
 
 
Author(s) 
Siegfried Beeh, Friederike Gengenbach 
Restrictions 
Customer Confidential: GM worldwide and GM suppliers  
Abstract 
This application note explains the current stage of GM support in CANoe 7.2 and its 
component Test Feature Set. 
 
Table of Contents 
 
1.0 
Overview ..........................................................................................................................................................2 
1.1 
Introduction....................................................................................................................................................2 
1.2 
Terms and Abbreviations ..............................................................................................................................2 
2.0 
Basic Support in CANoe ..................................................................................................................................3 
2.1 
Trace Window ...............................................................................................................................................3 
2.2 
Logging..........................................................................................................................................................3 
2.3 
Export ............................................................................................................................................................3 
2.4 
Interactive Generator Block...........................................................................................................................3 
2.5 
Generator Block ............................................................................................................................................3 
2.6 
Symbol Selection Dialog ...............................................................................................................................3 
2.7 
Data Window .................................................................................................................................................5 
2.8 
Graphics Window ..........................................................................................................................................6 
2.9 
Panels............................................................................................................................................................6 
2.10 
CAPL .............................................................................................................................................................7 
3.0 
“GM Package” Modeling Package ...................................................................................................................8 
3.1 
Model Generation..........................................................................................................................................8 
3.2 
Node Panels, Message Panels .....................................................................................................................8 
3.3 
Interaction Layer..........................................................................................................................................10 
3.4 
Network Management .................................................................................................................................10 
4.0 
Modeling Control Units (ECUs) in CAPL .......................................................................................................11 
4.1 
Signal Access..............................................................................................................................................11 
4.2 
Receiving Standard Messages ...................................................................................................................11 
4.3 
Receiving GM-Extended Messages............................................................................................................11 
4.4 
Receiving Signals Directly...........................................................................................................................11 
4.5 
Sending Standard Messages ......................................................................................................................12 
4.6 
Sending GM-Extended Messages ..............................................................................................................12 
5.0 
Test Feature Set ............................................................................................................................................13 
5.1 
Test Feature Set in CAPL ...........................................................................................................................13 
5.2 
Test Feature Set in XML .............................................................................................................................16 
5.3 
Test Service Library in CAPL and XML Test Modules................................................................................18 
5.4 
Test Automation Editor................................................................................................................................19 
5.5 
CANdb++ Test Module Generator ..............................................................................................................19 
6.0 
Additional Resources .....................................................................................................................................19 
7.0 
Contact...........................................................................................................................................................19 
 
 
 1  
Copyright © 2010 - Vector Informatik GmbH 
Contact Information:   www.vector.com   or ++49-711-80 670-0 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
1.0  Overview 
1.1  Introduction 
As a simulation, analysis and testing tool for electronic control units, CANoe supports the GMLAN 3.0 protocol in a 
special way. This document briefly describes the support provided by CANoe specifically for GMLAN and explains 
the possible use cases of the “Test Feature Set” for GMLAN in detail. This document is based on CANoe version 
7.2. Because CANoe support for GMLAN is extended continuously, we recommend that the reader checks whether 
a newer version of this document is available. 
The general Test Feature Set concept is explained in a separate document; see chapter 6.0. Familiarity with the 
Test Feature Set is assumed in this document. 
1.2  Terms and Abbreviations 
Term 
Meaning 
CANoe Vector 
product 
SUT 
System under Test 
TFS Test 
Feature 
Set 
ÆCANoe component 
TSL Test 
Service 
Library 
ÆTFS component 
CAPL 
CANoe Access Programming Language 
ÆLanguage used for programming simulation 
nodes, test modules etc. in CANoe. 
hsCAN 
High speed CAN Bus (GM-specific terminology)
swCAN 
Single wire CAN Bus (GM-specific terminology) 
GM extended 
Message with a 29-bit identifier 
message 
Standard message  Message with an 11-bit identifier 
Panel Designer 
Vector product for editing panels 
Panel Editor 
Vector product for editing panels 
Test Automation 
Vector product for editing XML test modules 
Editor 
Table 1: Terms and Abbreviations 
 
2 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
2.0  Basic Support in CANoe 
Basic support for GMLAN is activated automatically as soon as a GMLAN network file is identified. The existence 
and contents of the “UseGMParameterIds” network attribute are used as identification criteria. 
Details about basic support, which are available in the Online Help for CANoe, are referenced briefly in the 
following chapters. 
2.1  Trace Window 
Separate columns display GM-specific “SourceID”, “Prio” and “ParameterID” information. The “GMLAN” base 
configuration can be selected. This contains basic information along with additional GM-relevant default columns 
such as “Prio”, “PID”, “SourceID” and “CAN-ID”. 
2.2  Logging 
GM-extended messages are logged along with standard messages. The CAN-ID is decoded in the comment field 
and documented separately as “ParameterID”, “SourceID” and “Prio”. 
2.3  Export 
Signal histories for standard messages can be exported from the log block, but this is not possible for signals on 
GM-extended messages. 
2.4  Interactive Generator Block 
The Interactive Generator Block (IG) allows GM-extended messages to be sent. A special “GMLAN” tab is 
provided for this purpose, as well as the ability to modify the message priority and SourceID. 
 
Figure 1: Defining a message in the Interactive Generator Block 
2.5  Generator Block 
The Generator Block makes it possible to send GM-extended messages in symbolic entry mode. 
2.6  Symbol Selection Dialog 
The symbolic selection dialog makes it possible to select symbols from the network database (*.dbc). 
 
3 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
2.6.1  Selecting a Message 
Messages can be selected, for example, in filters, in the Interactive Generator Block and in the CAPL browser. 
 
Figure 2: Message selection in the symbolic selection dialog 
 
Only the message name is included in the CAPL browser, regardless of the path followed in the selection dialog. 
 
 
4 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
2.6.2  Selecting a signal 
Signals can be selected, for instance, in the CAPL browser, the Data Window and the Graphics Window. 
 
Figure 3: Signal selection in the symbolic selection dialog  
 
Only the signal name is included in the CAPL browser, regardless of how the selection dialog is navigated. If 
additional qualifiers are required, these can be inserted in the CAPL browser by choosing “Insert message from 
CANdb++…”. 
2.7  Data Window 
Application signals are fully supported in the Data Window.  
. 
 
Figure 4: Data Window 
 
5 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
The send node of the signals can be checked in the special dialog “configuration overview” that is accessible from 
the context menu of the Data Window: 
 
 
Figure 5: Configuration overview 
2.7.1  Special signals in the Data window 
Message-specific statistical signals can be selected in the Data and Graphics windows. These are available for 
standard messages but not for GM-extended messages. 
2.8  Graphics Window 
The Graphics Window allows the display of signals on a timeline. The notes that apply to the Data Window apply 
equally to the selection of signals and special signals in the Graphics Window (see 2.7). 
2.9  Panels 
A panel may contain elements used to visualize and control signal values. The notes that apply to the Data 
Window apply similar to the selection of signals here (see 2.7).  
The Panel Editor selects a signal via a symbol path that contains the database name, the tx node, the tx message 
and the signal. For older configurations (created with older versions than CANoe 7.0), it must be ensured that the 
tx node is part of the symbol path (see area highlighted in red).  
 
6 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
 
Figure 6: Configuration dialog for an “Input/Output Box” panel control 
The Panel Designer fully supports GM by automatically inserting the tx node. 
2.10 CAPL 
A special message type – “gmlanMessage” – is available for GM-extended messages in CAPL, the CANoe 
programming language. With this message type, the Prio and SourceID parameters present in addition to the 
ParameterID can be queried using operators and set using special functions.  
Relevant CAPL code fragments are available e.g. in chapter 4.3. 
 
7 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
3.0  “GM Package” Modeling Package 
The “GM Package” modeling package contains the following special GM-specific components: 
• Interaction 
layer 
• Network 
management 
• Model 
generation 
•  Message panels for visualizing and controlling signal values. 
 
Since the supplied manual of the GM Package provides details on the modeling package and the components 
included in it, the following chapter discusses the functionality of the package only briefly. 
The modeling package is not included in the default CANoe installation, but can be requested from Vector support 
mailto:support@de.vector.com as a separate package free of charge. 
3.1  Model Generation 
The model generation wizard included in CANoe has been extended to include a GM option. swCAN and hsCAN 
networks can be generated. 
 
Figure 7: Model Generation Wizard 
 
It is also possible to generate a multi-bus configuration. 
Generation produces a complete CANoe configuration; the only action required is to select a node from the 
alternative nodes in the GM network file and to deactivate or delete unused nodes in the simulation setup. 
3.2  Node Panels, Message Panels 
The configuration generated by the model generation wizard uses message controls developed especially for GM. 
These message controls make it possible, for example, to modify the signal values that are transmitted by the 
simulated nodes. The panels can be used to visualize signal values for concretely existing nodes. 
These controls can be created/changed in the “Panel Editor”. 
 
8 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
 
Figure 8: Panel for changing and visualizing all send signals of a node in their messages 
 
In addition, a network management panel is generated for each node with which the virtual network status for 
existing simulated nodes can be visualized and modified.  
 
Figure 9: Panel for controlling and visualizing the network status for the current node 
 
9 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
3.3  Interaction Layer 
The interaction layer can be integrated into individual simulation nodes as a modeling DLL. It is used automatically 
when a model is generated using the model generation wizard. The interaction layer configures itself on the basis 
of the network database. Changes to the network database are therefore integrated automatically. The tasks of the 
individual components are: 
•  To provide a signal-oriented interface, i.e. individual signal values can be set as signal stimulants from 
within in CAPL, panels and the Test Feature Set. When using the COM server, then ensure to use the 
signal objects that are “outputs” or “inputs” of nodes. 
•  To utilize the network database’s transmission model. Cyclical transmissions, spontaneous transmissions 
in reaction to changes, etc. are sent to the bus in accordance with the transmission model. 
•  For some test cases, it is also necessary to be able to send messages on request. This is supported as 
well. 
•  Linkage to the network management: The “virtual networks” observed by the network management are 
known to the interaction layer. This affects whether a transmission should actually be sent or not. 
•  To provide a standard fault injection interface which is suitable to control the sending of messages from 
within CAPL. For more information about these functions refer to the CANoe Online Help. These 
functionalities can also be used comfortable in CANoe Test Modules. 
3.4  Network Management 
Network management is also available as a special modeling DLL. This component also configures itself based on 
information contained in the network database. 
The individual tasks of the components are: 
•  To control bus communications when waking up virtual networks and keeping them awake, insofar as the 
node‘s role is that of an activator. 
•  To observe bus communications in order to detect changes in the status of the virtual networks that control 
the node. 
•  Depending on the status of the virtual networks, the interaction layer is informed and its transmissions are 
suppressed completely. The virtual networks can be activated or deactivated manually in CAPL or on the 
panel. 
•  To provide a CAPL interface that makes it possible to control virtual networks or remain informed of virtual 
network status changes from within the application. 
 
10 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
4.0  Modeling Control Units (ECUs) in CAPL 
In principle, the following message types are available with GMLAN: 
•  Standard messages (with 11-bit message IDs) 
•  GM-extended messages (with 29-bit message IDs) 
Messages of both types can be sent as well as received: 
4.1  Signal Access 
To access to signal values (set and get signal value) there is a tight way available by using the $-operator: 
dword sigValue;  
$ECC::A2RAlrmTime = 10;           // set signal value 
sigValue = $ECC::A2RAlrmTime;     // get signal value 
4.2  Receiving Standard Messages 
Standard messages can be received and evaluated in the usual way by defining “on message” handlers: 
on message Dynamic_Normal_Force 
{ 
  long val; 
  val = this.DynNrmlFrcFrLfWhl;  // signal access 
  // Application code … 
} 
4.3  Receiving GM-Extended Messages 
GM-extended messages can be received and evaluated by defining “on gmlanmessage” handlers: The message 
handler can then be programmed specifically for one or more SourceIDs: 
on gmlanmessage Chime_Status  
{ 
  long val; 
  if(gmLanGetSourceId(this) == AMP.SourceId) 
  { 
    val = this.ChmAct; 
    // Application code … 
  } 
} 
4.4  Receiving Signals Directly 
Signals can be received directly in CANoe by defining an “on signal” handler in CAPL. This is supported for signals 
on standard messages but not currently for signals on GM-extended messages. 
 
11 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
 
4.5  Sending Standard Messages 
Standard messages are sent according to the following general principle: 
  message Dynamic_Normal_Force msg; 
  msg.DynNrmlFrcFrLfWhl = 1;  // example signal value 
  output(msg); 
 
4.6  Sending GM-Extended Messages 
Before a GM-extended message is sent, the SourceID must be specified; whereas the Prio is added automatically: 
gmlanmessage ChimeStatus msg; 
gmLanSetSourceId(msg, AMP.SourceId); 
output(msg) 
Hint: When working signal oriented (4.1), the message is sent by the Interaction layer; no need to care about 
SourceIDs. 
 
12 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
5.0  Test Feature Set 
5.1  Test Feature Set in CAPL 
A typical test sequence consists of 
•  Stimulation of signals or messages (SUT input vector) 
•  Allowance for a SUT settling time until the expected reaction is to occur, and 
•  Evaluation of signal states or message events (SUT output vector) in response to the stimulation. 
 
The allowed settling time can be shortened by specifying a concrete event in the test sequence, e.g. receipt of a 
message with a specific message ID. 
Test sequences can be structured into test cases, test groups and test modules. 
The CANoe test sequence and test structure apply equally to GMLAN, regardless of whether the test modules are 
formulated in CAPL, XML or .NET. There are, however, a number of particularities, which are explained in the 
following chapters.  
5.1.1  Configuring the Restbus Simulation 
The restbus simulation is used directly by the Test Feature Set. Based on the interaction layer configured there, it 
takes charge of sending messages and thus of signal stimulation. Consequently, the prerequisite for the 
stimulation of signal values is that the restbus simulation node is present in the simulation setup and is assigned to 
the database node, and that the “CANoe GM Interaction Layer” modeling DLL is assigned to the simulation node. 
Note: 
The restbus simulation will be correctly and fully configured if it is created using the “model 
generation wizard” that comes with the modeling package. Use of this generation method is 
therefore recommended. 
 
5.1.2  Signal Abstraction – Evaluation 
Note: 
For signals that are mapped onto GM extended messages the signal symbol has to be prefixed by 
the send node, e.g. checkSignalInRange(ECC::A2RAlrmTime, 10, 20). 
A signal value can be compared directly to a specified interval using the following functions: 
long checkSignalInRange(dbSignal aSignal,          
                        float aLowLimit,  
                        float aHighLimit); 
 
Combined signal value queries, immediate comparison with a specified interval and automatic recording of the 
actual and target values for the comparison results are also possible by means of special functions:  
 
13 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
long testValidateSignalInRange (char aTestStep[],  
                                dbSignal aSignal,  
                                float aLowLimit,  
                                float aHighLimit) 
long testValidateSignalOutsideRange (char aTestStep[],  
                                     dbSignal aSignal,  
                                     float aLowLimit,  
                                     float aHighLimit) 
Please refer to the CANoe Online Help for further details about these functions. 
5.1.3  Signal Abstraction – Stimulation 
Signal values can be stimulated with the $-operator (4.1). This requires (at least for the specified Tx node) a 
configured restbus simulation (5.1.1). 
$ECC::A2RAlrmTime = 10;  
If a signal that is already being sent by a real ECU is to be stimulated as part of a test sequence, then the real ECU 
should be stimulated, thereby indirectly causing the changed signal value to be sent. 
Using the signal stimulation within the Test Feature Set the stimulation is reported in the test report. 
5.1.4  Message Abstraction – Evaluation  
There are also wait functions available for testing message events, with which the test sequence pauses until the 
event condition is fulfilled.  Simulation node techniques (see 4.1 and 4.3) are available likewise. These wait 
functions can be used either symbolically by specifying a message symbol from the network file or numerically by 
specifying a message ID. 
For standard messages these are: 
long TestWaitForMessage(dbMessage aMsg, dword aTimeout) 
long TestWaitForMessage(long aMsgId, dword aTimeout) 
 
For GM-extended messages, only the numeric function for passing the message ID is available; alternative ways 
of using the wait function are described below: 
a) Symbolic setup via instantiation of a message buffer 
The “aMsgId” expected in the function is created by means of a series of calls. The example below is 
constructed for the send node “AMP” that transmits the message “Chime_Status”, with a maximum wait 
time of 2000ms: 
 
14 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
// Example signal evaluation on message level  
testcase a () 
{ 
  gmlanmessage Chime_Status msg;   
 
  if(testWaitForMessage(gmLanId(Chime_Status, AMP), 2000) == 1) 
  { 
    testGetWaitEventMsgData(msg); 
 
    if(msg.ChmAct == 1) 
      TestStepPass("A", "Message received, signal matches"); 
    else 
      TestStepFail("A", "Message received, signal does not match"); 
  } 
  else  
    TestStepFail("A", "Message missing"); 
} 
 
Commonly, application level tests are done by using signal access and signal test functions. Message 
level checks are done mostly by utilizing the TSL checks (refer 5.3 for details).   
b) Numerical setup via modification of a message buffer 
If the name of the message or send node is not known in CAPL and the message ID is to be set up in a 
strictly numerical manner, the following steps are necessary: 
// initialise local variables 
gmlanmessage * msg1; 
 
// do something, e.g. stimulate the SUT 
 
// Set up and wait for response 
msg1.id = (0x10); 
gmLanSetSourceId(msg1, 0x81); 
gmLanSetPrio(msg1, 4); 
TestWaitForMessage(msg1.id, 2000); 
 
5.1.5  Message Abstraction – Stimulation  
GM messages are sent in the same way as in simulation nodes. Standard GM messages are handled as described 
in the CANoe Online Help. Only the GM-extended messages require special treatment: The “Prio” and “SourceID” 
parameters can be added to a CAN-ID in the following ways: 
Numerically, within the variable definition: 
testcase numericOutput() 
{ 
  gmlanmessage 0x10x msg1 = {SA =0x81, PRIO= 0x4}; 
  output(msg1); 
} 
Specifying PRIO (for the message priority) is optional, as this is taken from the message definition. If it is not 
specified, the SA selector (for the SourceID) is taken to be 0. For this reason, it is absolutely necessary to add the 
SourceID by using, for example, the following process (see also 4.6): 
 
15 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
testcase symbolicOutputProgrammatic() 
{ 
  gmlanmessage Chime_Status msg2; 
  gmLanSetSourceId(msg2, AMP.SourceId); 
  output(msg2); 
} 
5.1.6  Interaction Layer Fault Injection Functions 
There are also Fault Injection functions available which are suitable to control the sending of messages, e.g. to 
change the cycle time, to suppress messages completely or to change the DLC of messages. For more information 
about these functions refer to the CANoe Online Help. 
These fault injection functions can also be used for messages with extended IDs. Therefore the ID-based functions 
have to be used: 
id_DDM = gmLanId(Driver_Door_Status, DDM); 
TestDisableMsg(id_DDM); 
This example disables the sending of the message “Driver_Door_Status” of node “DDM”. 
5.2  Test Feature Set in XML 
GMLAN requires no new constructs with the Test Feature Set in XML test modules. The existing qualification of 
signals using send nodes can be used directly here and must be used for GM-extended messages and their 
signals. 
The table below shows the existing test functions and their GM support: 
Test function name 
Usage in test modules for messages with standard or GM-
extended IDs 
Await Value Match 
3 
CANstress Configuration 
3 Trigger/disturbance definition for standard IDs 
: Trigger/disturbance definition for GM-extended IDs 
CANstress State 
3 
Diagnostics Service 
3 
Diagnostics Service Check 
3 
(replaced by Diagnostics Service) 
Initialize 
3 for signal abstraction 
3 for message abstraction 
Replay 
3 
Request Response 
3 
Set 
3 for signal abstraction 
3 for message abstraction 
State Change 
3 
State Check 
3 
Stimulate Ramp 
3 
System Call 
3 
Tester Confirmation 
3 
Until End 
3 
VT System Configuration 
3 
Wait 
3 
Window Capture 
3 
Table 2: XML Test Functions 
 
 
16 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
Syntax example for GM-extended: 
<testcase title="my GM test case"> 
  <statechange wait="200ms"> 
    <in> 
      <cansignal id="stim_sig" node="sender"> 
       10 
      </cansignal> 
    </in> 
    <expected> 
      <cansignal id="expected_sig" node="sender"> 
        <eq>10</eq> 
      </cansignal> 
    </expected> 
  </statechange> 
</testcase> 
 
 
17 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
5.3  Test Service Library in CAPL and XML Test Modules 
The table below shows the existing check objects (“TSL checks”) and their usage for different message types: 
Check base name 
Usage in test modules 
Usage in test modules for messages with 
for messages with 
GM-extended IDs 
standard IDs 
 
 
CAPL  
XML 
CAPL 
XML 
Cycle Time (Abs) 
    For message 
3 
3 
3 (ID-based)  
3 
Cycle Time (Rel) 
    For message 
3  
3 
3 (ID-based) 
3 
    For node 
3 
3 
3 
3 
DLC Monitoring 
    For single message 
3 
3 
3 (ID-based) 
3 
    For all tx messages of node 
3 
3 
3 
3 
    For all rx messages of node 
3 
3 
3 
3 
Error Frame Check 
3 
3 
3 
3 
Fallback Observation 
-- 
3 
-- 
3 
Message Distance 
3 
3 
3 (ID-based) 
3 
Unknown Message Received 
3 
3 
3 
3 
Signal Value Constancy 
3 
3 
3 
3 
Node Active 
    For message list 
-- 
3 
-- 
3 
    For single node 
3 
3 
3 
3 
    For all nodes 
3 
-- 
3 
-- 
Node Inactive 
 
 
    For message list 
-- 
3 
-- 
3 
    For single node 
3 
3 
3 
3 
    For all nodes 
3 
-- 
3 
-- 
Absence of Defined Message 
3 
3 
3 (ID-based) 
3 
Occurrence of a Message 
    For single message 
3 
3 
3 (ID-based) 
3 
    For node 
3 
-- 
3 
-- 
Request Response Check 
-- 
3 
-- 
3 
Value Invariant 
-- 
3 
-- 
3 
Signal Value 
3 
3 
3 
3 
Timeout Check 
3 
3 
3 
3 
Table 3: Test Service Library Checks 
 
Symbols 
Meaning 
3 
Fully supported 
-- 
Generally not available (specific feature of 
XML test modules or CAPL test modules) 
: 
Not supported for GM-extended messages 
 
 
 
18 
Application Note AN-IND-8-003 
 

---

 
 
GM Support in CANoe 7.2 
 
 
 
 
 
5.4  Test Automation Editor 
The Test Automation Editor 1.1 supports fully the GMLAN networks and the editing of XML test modules.  
It provides a setting to fill in always the send node of an added symbol. 
 
For further information about the separate Vector product Test Automation 

Document Outline

• 1.0 Overview
  • 1.1 Introduction
  • 1.2 Terms and Abbreviations
• 2.0 Basic Support in CANoe
  • 2.1 Trace Window
  • 2.2 Logging
  • 2.3 Export
  • 2.4 Interactive Generator Block
  • 2.5 Generator Block
  • 2.6 Symbol Selection Dialog
    • 2.6.1 Selecting a Message
    • 2.6.2 Selecting a signal
  • 2.7 Data Window
    • 2.7.1 Special signals in the Data window
  • 2.8 Graphics Window
  • 2.9 Panels
  • 2.10 CAPL
• 3.0 “GM Package” Modeling Package
  • 3.1 Model Generation
  • 3.2 Node Panels, Message Panels
  • 3.3 Interaction Layer
  • 3.4 Network Management
• 4.0 Modeling Control Units (ECUs) in CAPL
  • 4.1 Signal Access
  • 4.2 Receiving Standard Messages
  • 4.3 Receiving GM-Extended Messages
  • 4.4 Receiving Signals Directly
  • 4.5 Sending Standard Messages
  • 4.6 Sending GM-Extended Messages
• 5.0 Test Feature Set
  • 5.1 Test Feature Set in CAPL
    • 5.1.1 Configuring the Restbus Simulation
    • 5.1.2 Signal Abstraction – Evaluation
    • 5.1.3 Signal Abstraction – Stimulation
    • 5.1.4 Message Abstraction – Evaluation 
    • 5.1.5 Message Abstraction – Stimulation 
    • 5.1.6 Interaction Layer Fault Injection Functions
  • 5.2 Test Feature Set in XML
  • 5.3 Test Service Library in CAPL and XML Test Modules
  • 5.4 Test Automation Editor
  • 5.5 CANdb++ Test Module Generator
• 6.0 Additional Resources
• 7.0 Contact

---

9 - AN-ISC-2-1052_CANbedded_and_Operating_Systemss

 
CANbedded and Operating Systems 
Version 1.0 
2007-01-18  
Application Note  AN-ISC-2-1052 
 
 
 
Author(s) Hartmut 
Hörner, Patrick Markl 
Restrictions Restricted 
Membership 
Abstract 
The Vector CANbedded software components have some requirements for the run-time 
environment. These requirements are described in this application note.  
 
 
Table of Contents 
 
1.0 
Overview ..........................................................................................................................................................1 
2.0 
General Requirements.....................................................................................................................................1 
3.0 
Interrupt Handling ............................................................................................................................................2 
3.1 
Interrupt Service Routines (ISRs) .................................................................................................................2 
3.2 
Access to interrupt control registers..............................................................................................................2 
4.0 
Data consistency..............................................................................................................................................3 
5.0 
Memory protection and virtual memory management .....................................................................................3 
6.0 
Privilege modes ...............................................................................................................................................4 
7.0 
Operating systems with stringent driver models..............................................................................................4 
8.0 
Startup Time ....................................................................................................................................................5 
9.0 
Contacts...........................................................................................................................................................5 
 
 
 
1.0 Overview 
The Vector CANbedded components have some requirements for the run-time environment. Some of these might 
impact the usage of the operating system elements as well as the real-time design. 
Two run-time environments are explicitly supported by CANbedded: 
•  A system without operating system 
•  An OSEK Operating System (version 2.1r1 onwards) such as Vector osCAN 
 
In the following chapters the requirements are listed and for some cases where no explicitly support exists 
workarounds are described. 
2.0 General Requirements 
Higher layer CANbedded components require an initialization function and one or more cyclic functions. 
CANbedded hardware drivers have an initialization function, ISRs in interrupt driven mode and cyclic functions in 
polling mode. The initialization function must be called before the cyclic function is called for the first time and 
before the first ISR occurs. 
The CANbedded stack requires a shared address space with the application since some functionalities such as 
signal and flag access are implemented by macros. 
There are no requirements for dynamic memory management. All not constant global variables are explicitly 
initialized in the initialization functions. There are no requirements for memory initialization in the start-up code 
unless constant data is located in RAM. 
 1  
Copyright © 2007 - Vector Informatik GmbH 
Contact Information:   www.vector-informatik.com   or ++49-711-80 670-0 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
Since the CANbedded components have to interface directly with the communication hardware adequate access 
privileges are required. 
3.0 Interrupt Handling 
3.1  Interrupt Service Routines (ISRs) 
If the CAN Driver is used in an interrupt driven mode one or more ISRs must be installed. 
Two categories of ISRs are supported: 
•  ISR implemented with the related compiler pragma or qualifier. This is used in a system without operating 
system and for OSEK-OS ISRs of category 1. 
•  OSEK-OS ISR category 2. 
 
If an operating system other than OSEK is used the following workaround is possible:  
If OSEK-OS and OSEK-OS category 2 ISR support are selected in the generation tool the ISR has the following C 
syntax: 
 
ISR(CanInterrupt) 
{ 
  … 
} 
 
Supply a header file osek.h with the following macro, to make the ISR available in other modules as a void-void 
function. 
 
#define ISR(x) void x(void) 
 
Example for an operating system which provides a service OSRegisterISR to register an ISR: 
 
OSRegisterISR(CanInterrupt, 10);     /* second parameter is interrupt vector number */ 
 
If the prototype of the ISR required by the OS is not of the kind void x(void) an intermediate function must be used 
to circumvent type conflicts. 
3.2  Access to interrupt control registers 
To achieve its own data consistency and to export such services to the application the CANbedded components 
require access to the interrupt control registers of the communication controller and to interrupt control registers of 
the interrupt controller or the CPU which allow to disable interrupts globally or up to a certain level. 
If it is not desirable or possible that the CANbedded components access the global interrupt directly this 
functionality can be replaced by other mechanisms (“interrupt control by application”, supported in CAN driver RI 
version 1.4 onwards).  
If a resource locking mechanism of the operating system is used it must support nested critical sections.  
 
2 
Application Note  AN-ISC-2-1052 
 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
4.0 Data consistency 
For efficiency reasons some services of the CANbedded components are implemented as macros with  
unprotected critical sections. If these macros are used in multiple full-preemptive tasks or in multiple ISRs data 
consistency problems can be caused. One of the following solutions is possible: 
•  Use these services only in non-preemptable tasks 
•  Use these services only in one cooperative task group (OSEK: internal resource concept) 
•  Supply critical section in the application code 
 
Some CANbedded components have specific requirements concerning processing priorities and reentrancy. These 
requirements are described in the technical reference of the individual component. 
 
5.0  Memory protection and virtual memory management 
This chapter is only applicable if the processor and the run-time environment support such mechanisms. 
Since some CANbedded services are implemented as macros which access to global variables the application part 
which uses the CANbedded services and the complete CANbedded stack must reside in one address space.  
In addition all CANbedded tasks and ISRs must be able to access the peripheral address space of the 
communication hardware. 
The following figure shows a possible configuration with three different applications with an own address space. 
Two applications perform application tasks (drawn in green), one application is responsible for the communication 
(drawn in red). 
Application 1
Application 2
Communication application
CANbedded stack
Communication hardware
 
Figure 1 Different applications with own address space 
 
To move data between the applications operating system services are required which have the capability to tunnel 
the address barrier (drawn with blue arrows).. 
 
3 
Application Note  AN-ISC-2-1052 
 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
6.0 Privilege modes  
This chapter is only applicable if the processor and the run-time environment support such mechanisms. 
In some architectures different privilege modes such as user and supervisor mode are defined. If a task or ISR is 
running in user mode the access to peripheral hardware and global resources such as interrupt control registers 
may be restricted.  
It must be possible to assign all tasks and ISRs which provide or use CANbedded services a sufficient privilege 
level to allow for: 
•  Access to communication hardware 
•  Access to communication related interrupt control 
•  Access to global interrupt control registers including the capability to execute instructions related to global 
interrupt control registers unless interrupt control by application is used (s. chapter 3.2). 
 
If such a privilege level is not possible for tasks but only for ISRs a cyclic timer ISR can be used to perform all 
required CANbedded cyclic processing. Note that such an ISR must have a lower interrupt level than the ISRs of 
the CANbedded drivers. 
7.0  Operating systems with stringent driver models 
This chapter is only applicable if the run-time environment supports such mechanisms. 
In some operating systems hardware access is only allowed for specific hardware drivers which have to follow a 
predefined implementation model. When a hardware driver is called in such a system the required privileges are 
assigned. To allow the usage of CANbedded a wrapper layer between application and CANbedded is required to 
implement the required driver interface. 
Such a design is illustrated in the figure below, the driver interface is drawn with blue arrows: 
Application 1
Application 2
Wrapper layer
CANbedded stack
 
Figure 2 With Wrapper Layer 
 
4 
Application Note  AN-ISC-2-1052 
 

---

 
 
CANbedded and Operating Systems 
 
 
 
 
 
8.0 Startup Time 
Some Operating systems (especially more sophisticated and larger ones) are running out of RAM, while the 
binaries are stored in non-volatile memories like Flash. This requires that the startup code transfers the OS image 
into RAM after power on reset. Depending on the size of the OS image this can take up to several hundreds of 
milliseconds. As a consequence the initialization of the CANbedded stack occurs after the kernel is loaded 
completely. Often this long startup times do not match the OEMs’ startup requirements. There are two possibilities 
to solve this issue. Either the OEM accepts the longer startup time or the operating system supports a mechanism 
that allows initialization of the CANbedded stack before the kernel is loaded completely. 
If the operating system supports some kind of a runtime environment before the kernel is loaded it could be also 
relevant to have a possibility to hand over the information received during the startup phase via CAN to the fully 
loaded kernel environment. 
9.0 Contacts 
 
 
 
 
Vector Informatik GmbH 
Vector CANtech, Inc. 
VecScan AB 
Ingersheimer Straße 24 
39500 Orchard Hill Pl., Ste 550 
Lindholmspiren 5 
70499 Stuttgart 
Novi, MI  48375 
402 78 Göteborg  
Germany 
USA 
Sweden 
Tel.: +49 711-80670-0 
Tel:  +1-248-449-9290 
Tel:  +46 (0)31 764 76 00 
Fax: +49 711-80670-111 
Fax: +1-248-449-9704 
Fax: +46 (0)31 764 76 19  
Email: info@vector-informatik.de 
Email: info@vector-cantech.com 
Email: info@vecscan.com 
 
Vector France SAS 
Vector Japan Co. Ltd. 
 
168 Boulevard Camélinat 
Seafort Square Center Bld. 18F 
92240 Malakoff  
2-3-12, Higashi-shinagawa, 
France 
Shinagawa-ku 
Tel:  +33 (0)1 42 31 40 00 
J-140-0002 Tokyo 
Fax: +33 (0)1 42 31 40 09 
Tel.: +81 3 5769 6970    
Email: information@vector-france.fr 
Fax: +81 3 5769 6975 
 
Email: info@vector-japan.co.jp 
 
 
 
5 
Application Note  AN-ISC-2-1052 
 

---

12 - AN-ISC-8-1056_CANbedded_Program_Stack_Usages

 
CANbedded Program-Stack usage 
Version 1.0 
2007/01/08  
Application Note  AN-ISC-8-1056 
 
 
 
Author(s) Andreas 
Raisch 
Restrictions Customer 
confidential 
- subject to prior approval by PSC 
Abstract 
This application note provides basic information on the (program-) stack consumption of 
Vector's CANbedded communication components. 
 
 
Table of Contents 
 
1.0 
Overview ..........................................................................................................................................................1 
1.1 
Definition “The Stack”....................................................................................................................................1 
1.2 
Embedded System Stack Handling...............................................................................................................2 
1.3 
Stack-Usage Approach in CANbedded.........................................................................................................3 
1.3.1 
Example ......................................................................................................................................................3 
1.3.2 
Configuration Aspects.................................................................................................................................5 
1.4 
Calculating and Measuring Stack Need........................................................................................................5 
2.0 
Summary..........................................................................................................................................................5 
3.0 
Contacts...........................................................................................................................................................6 
 
 
 
1.0 Overview 
This application note provides basic information on the (program-) stack consumption of Vector’s CANbedded 
communication components. 
1.1  Definition “The Stack” 
In computer science, a call stack is a special stack, which stores information about the active subroutines of a 
computer program. (The active subroutines are those, which have been called but have not yet completed 
execution by returning.) This kind of stack is also known as a program stack, execution stack, control stack, 
function stack or run-time stack and is often abbreviated to just "the stack". 
 
The actual details of the stack in a programming language depend upon the compiler, operating system, and the 
available instruction set. 
 
As noted above, the primary purpose of the stack is: 
•  Storing the return address – When a subroutine is called, the location of the instruction to return to 
needs to be saved somewhere.  
 
A stack may serve additional functions, depending on the language, operating system and machine environment. 
Among them can be: 
•  Local data storage – A subroutine frequently needs memory space for storing the values of local 
variables, the variables that are known only within the active subroutine and do not retain values after it 
returns.  
 1  
Copyright © 2007 - Vector Informatik GmbH 
Contact Information:   www.vector-informatik.com   or ++49-711-80 670-0 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
•  Parameter passing – Subroutines often require that values for parameters must be supplied to them by 
the code which calls them and it is not uncommon that space for these parameters may be laid out in the 
stack. Generally if there are only a few small parameters, processor registers will be used to pass the 
values. The stack works well as a place for these parameters, especially since each call to a subroutine, 
which will have differing values for parameters, will be given separate space on the stack for those values. 
•  Other return state – Besides the return address, in some environments there may be other machine or 
software states that need to be restored when a subroutine returns. This might include things like 
processor registers, privilege level, exception handling information, arithmetic modes and so on. If needed, 
this may be stored on the stack just as the return address is. 
 
The typical stack is used for the return address, locals, and parameters (known as a call frame). In some 
environments there may be more or fewer functions assigned to the stack.  
A stack is composed of stack frames (sometimes called activation records). Each stack frame corresponds to a call 
to a subroutine, which has not yet terminated with a return. For example, if a subroutine named DrawLine is 
currently running, having just been called by a subroutine DrawSquare, the top part of the stack might be laid out 
like this: 
 
The stack frame at the top of the stack is for the currently executing routine. In the most common approach the 
stack frame includes space for the local variables of the routine, the return address back to the routine's caller, and 
the parameter values passed into the routine. The memory locations within a frame are often accessed via a 
register called the stack pointer, which also serves to indicate the current top of the stack. Alternatively, memory 
within the frame may be accessed via a separate register, often termed the frame pointer, which typically points to 
some fixed point in the frame structure, such as the location for the return address. 
Stack frames are not all of the same size. Different subroutines have differing numbers of parameters, so that part 
of the stack frame will be different for different subroutines, although usually fixed across all activations of a 
particular subroutine. Similarly, the amount of space needed for local variables will be different for different 
subroutines.  
[Source: Wikipedia] 
 
1.2  Embedded System Stack Handling 
The bandwidth of embedded system architectures and also the used µC (and compilers) results in a huge variety 
of stack handling approaches. 
The simplest approach is often valid, when no operating system (OS) is used. In such a case the stack is simply a 
 
2 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
reserved RAM area used by the whole system. 
If an OSEK/OS or AUTOSAR OS is used, the stack handling depends on the available features in the OS and the 
underlying µC. Each OS task has usually its own stack but can share this stack if some preconditions are kept with 
other tasks. Providing one or more own stacks for interrupts can reduce the stack need of the OS tasks, too.  
The stack need of an embedded system depends also on the specific handling for interrupts: 
•  Storing of CPU registers on the stack or simply switching to a different stack bank 
•  Supporting/using nested interrupts; i.e. interrupts can cause multiple store actions to the stack 
•  Configuring own stack(s) for interrupts or using the stack of the currently running OS task (or other 
interrupt) 
Please note that for most implementations the stack pointer starts at a high address and grows to lower addresses. 
1.3  Stack-Usage Approach in CANbedded 
The CANbedded architecture is optimized for so-called deeply embedded systems with limited RAM and runtime in 
real-time systems. As a result of this, the architecture is gained to be a good compromise between  
•  ROM usage (multiple implementation of same behavior vs. in-lining or calling functions) 
•  RAM usage (static parameters vs. local parameters on the stack; calling a function vs. implementing 
something short twice, …) 
•  Runtime consumption (calling a function needs more time than local handling) 
 
A CANbedded function shall therefore  
•  have only few arguments (none, 1 or 2, very very rarely more than 2 parameters) 
•  be implemented in a way that local data stored on the stack is minimized 
•  call no other functions unless it is necessary due to layered architecture 
 
Most CANbedded API functions are implemented in a way that only flags are set which are evaluated on a cyclic 
function to prevent too deep function call trees (and with this an increased stack need). 
An additional task of the CANbedded communication components is the separation of the interrupt driven 
hardware handling and the task-level view of the application. To be able to react on communication events 
correctly, parts of the handler implementation are executed on interrupt level and parts are executed on task level. 
Which stack and how much stacks are used for the task and the interrupt context depends on the underlying 
system (see chapter 1.2 for details). 
1.3.1 Example 
A typical example for such a CANbedded implementation is a transport protocol, where the reaction on incoming 
events has to be fast whereas the timeout and state handling can be slower. The implementation will therefore be 
split in a function called within the CAN RX interrupt for fast actions and a cyclic called function for the slower ones. 
The same is true for the next upper layer, the diagnostic layer. See Figure 2 for details how the diagnostic layer 
handles the separation of RX event notification in CAN ISR context and further handling on task context. 
As a result, the call tree of the RX event handling in ISR context stops latest on diagnostic layer level. All further 
handling (including application calls) is processed a few milliseconds later from task level with only very few 
function calls on the stack. 
 
3 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
osCAN
Application
Diagnostics
Layer
Universal
Measure-
Interaction 
Network
ment
Layer
Management
And 
Communication
Calibration
Control
Transport Protocol
Protocol
Layer
CAN Driver
CAN Controller
Transce
Transc iver
CAN Bus
 
Figure 1 Example CANbedded Stack with CAN Driver, TP and Diagnostic Layer as the largest call-tree 
 
Data 
Da
Eve
Ev nt 
ready 
Cyclic 
han
ha dler
flag
hand
ha
l
nd er
CAN 
CAN
Transp
Trans ort
Diagnostics
osti                          
                    
Application
Driver
Protocol
Protoc
Laye
Lay r
Further handling
RX o
RX f TP frame
am
Optional call to application
unknown to std. SW
Copy RX data
 dat
Check RX
data ready
Further handling
RX o
RX f last TP frame
am
Optional call to application
unknown to std. SW
Copy RX data
 dat
Indicate RX data ready
Check RX
data ready
PreHandler
Further handling
unknown to std. SW
MainHandler
Further handling
unknown to std. SW
ISR/Event context
Task context
 
Figure 2 Example call-tree for diagnostic data reception 
 
 
4 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
1.3.2 Configuration 
Aspects 
The configurations of the CANbedded components have a large impact on the stack needs. There is a customer 
specific, static setup of CANbedded components which interact together to fulfill the OEM requirements. I.e. the 
CAN driver always informs e.g. the transport layer if a specific CAN frame is received and the transport layer 
informs the diagnostic layer if the full message is received. This call sequence is preconfigured by Vector, 
nevertheless, the software supports multiple points (callbacks) where customer specific hooks can be included. 
This customer hooks have additional influence to the stack needs. 
Another very important configuration parameter is the decision if the RX/TX handling shall be processed in 
interrupt or on task context. If it is processed on task context, the stack need can be calculated easier than when 
the handling is performed with interrupts. 
In an ECU with one CAN bus, an interaction layer (IL), a network management (NM), a transport layer (TP) and a 
diagnostic component, the RX path of incoming diagnostic CAN messages has usually the largest call tree form 
communication point of view and therefore the highest stack need. 
1.4  Calculating and Measuring Stack Need 
Exactly calculating the stack needs is a difficult and error-prone task. Therefore the stack size is often estimated 
based on the environmental conditions described in chapter 1.2 and a safety value of 10% to 20%, sometimes 
100%, is added to the result. 
If an operating system is used, this system usually provides means to measure stack usage and test stack 
consistency. OSEK/OS and AUTOSAR OS for instance provides such means to check the stack with each OS 
action and also to initialize the stack with patterns so the worst case usage for a given scenario can be found. 
When using such a method, it is important to analyze upfront the worst case call trees and make sure they have 
happened during test execution, too. This implies also “special” scenarios like “ECU in diagnostics”, “ECU with high 
I/O interrupt load”, occurrence of OSEK category 1 and 2 interrupts at the same time, … 
2.0 Summary 
As a result of all this effects, no detailed figure for the concrete stack usage of the CANbedded communication 
components can be given upfront of the real usage in an ECU project. 
Vector offers different levels of support to customers, starting from telephone hotline for the more simple questions, 
integrating the CANbedded communication components and other software up to analyzing your ECU setup as a 
separate project work. 
 
Note:  
Please be aware that due to all the points mentioned in this application note Vector can not finally 
list the stack needs of the CANbedded communication components in your project. The concrete 
layout and dimension of the stack(s) in an ECU project is the task of the system integrator.  
 
 
5 
Application Note  AN-ISC-8-1056 
 

---

 
 
CANbedded Program-Stack usage 
 
 
 
 
 
3.0 Contacts 
 
 
 
 
Vector Informatik GmbH 
Vector CANtech, Inc. 
VecScan AB 
Ingersheimer Straße 24 
39500 Orchard Hill Pl., Ste 550 
Lindholmspiren 5 
70499 Stuttgart 
Novi, MI  48375 
402 78 Göteborg  
Germany 
USA 
Sweden 
Tel.: +49 711-80670-0 
Tel:  +1-248-449-9290 
Tel:  +46 (0)31 764 76 00 
Fax: +49 711-80670-111 
Fax: +1-248-449-9704 
Fax: +46 (0)31 764 76 19  
Email: info@vector-informatik.de 
Email: info@vector-cantech.com 
Email: info@vecscan.com 
 
Vector France SAS 
Vector Japan Co. Ltd. 
 
168 Boulevard Camélinat 
Seafort Square Center Bld. 18F 
92240 Malakoff  
2-3-12, Higashi-shinagawa, 
France 
Shinagawa-ku 
Tel:  +33 (0)1 42 31 40 00 
J-140-0002 Tokyo 
Fax: +33 (0)1 42 31 40 09 
Tel.: +81 3 5769 6970    
Email: information@vector-france.fr 
Fax: +81 3 5769 6975 
 
Email: info@vector-japan.co.jp 
 
 
 
6 
Application Note  AN-ISC-8-1056 
 

---