Vector CANoe, CANalyzer User Manual
CANoe and CANalyzer as Diagnostic Tools
Version 1.6
2020-09-03
Application Note AN-IND-1-001
Author
Vector Informatik GmbH
Restrictions
Public Document
Abstract
This application gives an introduction into working with diagnostics in
CANoe/CANalyzer. It presents the basic technical aspects and possibilities with the
Diagnostic Feature Set, complements the help file of CANoe/CANalyzer and may be
used as a tutorial.
Table of Contents
1.0 Overview ................................................................................................................................... 3
1.1 Introduction ..................................................................................................................... 3
1.2 Diagnostic components ................................................................................................... 4
1.3 “Built-in” diagnostic channel vs. TP DLL and CAPL Callback Interface ............................. 5
2.0 Diagnostics in CANoe and CANalyzer .................................................................................... 6
2.1 Transport Protocol support .............................................................................................. 6
2.2 Diagnostic Descriptions ................................................................................................... 7
2.2.1 CDD – CANdela Diagnostic Description........................................................................... 7
2.2.2 ODX – Open Diagnostic Data Exchange.......................................................................... 7
2.2.3 MDX – Multiplex Diagnostic Data Exchange .................................................................... 7
2.2.4 Basic Diagnostic Description (UDS or KWP) .................................................................... 7
2.2.5 Standard Diagnostic Description ...................................................................................... 8
2.3 Additional Descriptions .................................................................................................... 8
2.4 Trace window .................................................................................................................. 9
2.5 Diagnostic Feature Set .................................................................................................. 10
2.5.1 Interactive Diagnostic Console window .......................................................................... 10
2.5.2 Fault Memory window.................................................................................................... 10
2.5.3 Variant Coding Window ................................................................................................. 11
2.5.4 Diagnostic Session Control window ............................................................................... 12
2.5.5 OBD-II window .............................................................................................................. 12
2.5.6 ECU, gateway or tester simulations using CAPL ............................................................ 12
2.5.7 Test modules using CAPL (CANoe only) ....................................................................... 13
2.5.8 Test Units (CANoe only) ................................................................................................ 13
2.5.9 Symbol Explorer for diagnostics objects and parameters ............................................... 13
2.5.10 Autocomplete Input Assistance for diagnostics .............................................................. 14
2.5.11 Functional Group Requests ........................................................................................... 14
2.6 Access to diagnostics features via COM ........................................................................ 14
2.7 Basic Diagnostic Editor .................................................................................................. 14
2.8 Security Access handling............................................................................................... 14
3.0 First steps............................................................................................................................... 15
3.1 Usage of Diagnostic Descriptions .................................................................................. 15
3.1.1 Add a Diagnostic Description ......................................................................................... 15
3.1.2 Configure the Diagnostic Description ................................................................ ............. 16
3.2 Usage of Diagnostic Console, Session Control and Fault Memory window ..................... 17
3.2.1 Send a diagnostic request and receive a response ........................................................ 18
3.2.2 Read fault memory ........................................................................................................ 18
3.2.3 Functional Group Requests ........................................................................................... 18
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 2
Contact Information: www.vector.com or +49-711-80 670-0
3.2.4 Change the session and security level ........................................................................... 18
3.3 Display diagnostic data .................................................................................................. 18
3.3.1 Diagnostic data in State Tracker, Data and Graphics window ........................................ 19
3.3.2 Diagnostic data in panels .............................................................................................. 19
4.0 Using CAPL for Diagnostics .................................................................................................. 20
4.1 Common techniques for Simulation and Tester .............................................................. 20
4.1.1 Usage of the CAPL Browser .......................................................................................... 20
4.1.2 Work with parameters.................................................................................................... 21
4.2 ECU diagnostics simulation ........................................................................................... 22
4.2.1 Necessary preparations ................................................................................................. 22
4.2.2 Add a Network Node to the Simulation Setup ................................................................ 23
4.2.3 Add a database in case of LIN and FlexRay .................................................................. 23
4.2.4 Add a Diagnostic Description and assign it to the network node ..................................... 23
4.2.5 Configure the Network Node in Simulation Setup ........................................................... 24
4.2.6 Add the CAPL Callback Interface................................................................................... 25
4.2.7 Debug level ................................................................................................................... 25
4.2.8 Add a diagnostics request event handler ....................................................................... 26
4.2.9 Create a diagnostic response ........................................................................................ 26
4.3 CANoe/CANalyzer as Diagnostic Tester ........................................................................ 27
4.3.1 Set the diagnostic target ................................................................................................ 27
4.3.2 Create a diagnostic request ........................................................................................... 27
4.3.3 Add a diagnostics response event handler ..................................................................... 27
4.3.4 Negative Response handling ......................................................................................... 27
4.4 Combine Test Feature Set and Diagnostic Feature Set.................................................. 28
4.4.1 Timeout handling ........................................................................................................... 28
4.4.2 Automated diagnostic tests with CANoe ........................................................................ 29
4.5 Using CAPL in the measurement setup ......................................................................... 32
5.0 Advanced examples ............................................................................................................... 32
5.1 ECU simulation of “Response Pending” ......................................................................... 32
5.2 Modifying the length of a diagnostic object ..................................................................... 33
5.3 Fill diagnostic content .................................................................................................... 33
5.4 Fault injection ................................................................................................................ 33
5.4.1 Make request length illegal ............................................................................................ 33
5.4.2 Introduce errors on transport protocol level .................................................................... 34
5.5 Access a node via a gateway simulation ........................................................................ 34
6.0 Common mistakes ................................................................................................................. 35
7.0 Abbreviations ......................................................................................................................... 37
8.0 References ............................................................................................................................. 37
9.0 Additional Resources ............................................................................................................ 38
10.0 Contacts ................................................................................................................................. 38
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 3
Contact Information: www.vector.com or +49-711-80 670-0
1.0 Overview
1.1 Introduction
Diagnostics is used to configure, maintain, support, control and extend an ECU before or after it is
installed in a system, e.g. a vehicle. Diagnostics is usually performed in a request – response scheme:
a tester (client) sends a request to an ECU (or even more than one ECU) and the ECU (server)
responds by sending a “positive response message” containing the requested information, or a
“negative response” indicating the reason for the negative response.
The purpose of this application note is to give a general introduction into working with diagnostics in
the Vector tools CANoe and CANalyzer. The basic technical aspects and possibilities (“first steps”)
with the Diagnostic Feature Set will be presented. Examples are used to get the test engineer started
with testing diagnostics in CANoe/CANalyzer.
This document is a complement to the online help in CANoe/CANalyzer and should be used as a
tutorial to learn the “first steps” of the Diagnostic Feature Set. For more detailed information about the
Diagnostic Feature Set, please refer to the CANoe/CANalyzer help file demo applications, both of
which come with a standard CANoe/CANalyzer installation.
Note
The functionality described below refers to CANoe and CANalyzer version 14.0 (unless
otherwise noted – please see the general limitations of CANalyzer in chapter 2.0). The
term “CANoe/CANalyzer” stands for both applications, while the term “CANoe” describes
functionality only available with CANoe.
For older program versions application notes can be requested from the Vector support
(cf. chapter 10.0).
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 4
Contact Information: www.vector.com or +49-711-80 670-0
1.2 Diagnostic components
The following table lists the names of the components relevant for diagnostics in CANoe/CANalyzer,
how to activate them and where to find more information.
Component
Description
Activation
More Information
Transport Protocol (TP)
DLLs
Implementation of the
respective Transport
Protocol for CANoe
simulation nodes
See chapter 2.1
Regarding CAN in
folder “User Assistance
| Documents”:
CanTP_Manual.PDF
ISO TP Observer
Displays TP information
in the trace window for
the CAN messages
used by the ISO TP
Menu: “Configuration->
Diagnostics/ISO TP
configuration”, page
“ISO TP Observer”
Online help:
“Diagnostics/ISO TP
Configuration: ISO TP
Observer”
KWP 2000 Observer
Extension of the ISO
TP Observer that
interprets the
transported data
according to Keyword
Protocol 2000
Like ISO TP Observer,
check box
“Interpretation
according to KWP2000”
Online help:
“Diagnostics/ISO TP
Configuration: ISO TP
Observer”
Diagnostics Observer
Extension of the ISO
TP Observer, interpret
the transported data
according to the
available diagnostic
specification(s)
Menu: “Configuration->
Diagnostics/ISO TP
configuration”,
corresponding network
in which Diagnostic
Descriptions can be
loaded
Online help: “Diag. /
ISO TP Obs.:
Diagnostic
Descriptions”
Interactive Diagnostic
Console
Direct sending of
requests defined in a
Diagnostic Description,
display of responses
By assigning a
Diagnostic Description
to any of the available
networks (see
Diagnostics interpreter
above) a corresponding
Diagnostic Console
window is made
available, and can be
accessed via the “View”
menu
Online help: “Diagnostic
Console: Overview”
Fault Memory window
Direct access to an
ECU’s fault memory
By assigning Diagnostic
Descriptions to any of
the available networks
(see Diagnostics
interpreter above) a
corresponding Fault
Memory window is
made available, and
can be accessed via
the “View” menu
Online help: “Fault
Memory window:
Overview”
Diagnostic Session
Control window
Easy switching of the
session state (e.g.
Default, Extended,
Programming), helpful
especially in
combination with
services protected by
security access
By assigning a
Diagnostic Description
to any of the available
networks (see
Diagnostics interpreter
above) a corresponding
Diagnostic Session
Control window is made
available, and can be
accessed via the “View”
Online help: “Diagnostic
Session Control:
Overview”
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 5
Contact Information: www.vector.com or +49-711-80 670-0
Component
Description
Activation
More Information
menu
OBD II window
Support of on-board
diagnostics
By choosing the
addressing mode (11
bit Normal or 29 bit
NormalFixed) at the
page “OBD-II
Functionality” (Menu:
“Configuration->
Diagnostics/ISO TP
configuration”)
Online help:
“Diagnostics
Description Settings:
OBD-II Functionality”
CAPL extensions for
diagnostics
Specialized CAPL
functions to access
diagnostics objects
specified via Diagnostic
Description(s)
The extended CAPL
API is available after
assigning at least one
Diagnostic Description
to the CANoe
configuration
Online help:
“Diagnostics: Expanded
Functions in CAPL”
CAPL Callback
Interface reference
implementation
Handles the
communication
between Diagnostic
Layer and
TransportProtocol
Layer in CANoe
Add the include file for
the respective TP into
the simulation or tester
node
Application Note
AN-IND-1-012
1.3 “Built-in” diagnostic channel vs. TP DLL and CAPL Callback Interface
While CANalyzer only provides the “built-in” diagnostic channel for diagnostic communication, CANoe
offers an additional alternative: The so-called CAPL Callback Interface (CCI) in combination with the
corresponding Transport Protocol (TP) DLL. The CCI acts as a kind of interconnection between
diagnostic layer and TP layer in CANoe.
The diagnostic windows (Diagnostic Console, Fault memory, Session Control and OBD-II window) are
always using the built-in diagnostic channel. Test Modules and Test Units are able to use both ways
alternatively. While CANoe versions up to 9.0 SPx mandatorily need the CCI for simulating ECU
diagnostics, CANoe 10.0 and higher also offers the built-in diagnostic channel for simulation nodes:
Figure 1: Layer model of CANoe
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 6
Contact Information: www.vector.com or +49-711-80 670-0
Before setting up a diagnostics configuration in CANoe, you should therefore make up your mind
about the intended use cases. In most cases, the built-in diagnostic channel will be sufficient. The CCI
is only needed if your CANoe configuration needs to be compatible with older CANoe versions or if
you intend to implement some fault injection functionality on TP layer. For more information on the
CCI, refer to the application note AN-IND-1-012.
2.0 Diagnostics in CANoe and CANalyzer
CANoe and CANalyzer can be used in all steps of developing ECUs and performing diagnostics on
them. The following table summarizes the main use cases, the corresponding diagnostic features and
the differences between CANoe and CANalyzer:
Use case
Feature
CANalyzer
CANoe
Analysis of real ECU
communication
ISO TP, KWP2000 and
Diagnostics Observer
Perform diagnostics with
ECUs using integrated tester
functionality
Diagnostic Console
Error search
Fault Memory window
Security access and session
control
Session Control window
On-board diagnostics
OBD II window
Design of the diagnostic
functionality
System / remaining bus simulation
Implementation of diagnostic
functionality in a simulated
ECU
TP DLLs, ECU simulation and
CAPL extensions
Specification-/Integration/Regression tests including
fault injection on TP level
TP DLLs (only necessary if TP fault
injection requested), CAPL
extensions, Test Feature Set (TFS)
2.1 Transport Protocol support
CANoe/CANalyzer supports several automotive protocols. For most of them, a node layer Transport
Protocol (TP) DLL and a corresponding CCI reference implementation exists in CANoe:
Network
Protocol
Interpretation
TP DLL (Node layer)
CCI reference
implementation
CAN
ISO/DIS 15765-2
DoCAN (OSEK TP)
ISO TP
observer
osek_tp.dll
CCI_CanTP.cin
LIN
ISO 17987-2
(LIN TP)
(with option
LIN)
LINtp.dll
CCI_LINTP.cin
K-Line
ISO 14230-2
DoK-Line
K-Line
observer
- (not necessary)
CCI_KLine.cin
(+KLine_Utilities.cin)
FlexRay
ISO 10681-2 Transport
Protocol STD Version
2.2 2008-11-28
FlexRay TP
observer
(with option
Flexray)
FlexRayTPISO.DLL
CCI_FrISOTP.cin
(+CCI_FrCommon.cin)
AUTOSAR Transport
Layer V2.1.1 R2.1 Rev
0014
FlexRay TP
observer
(with option
Flexray)
AutosarFlexRayTP3.dll
CCI_FrAsrTP.cin
(+CCI_FrCommon.cin)
Ethernet
ISO 13400-2
DoIP Packet
Events
DoIP.DLL
CCI_DoIP.cin
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 7
Contact Information: www.vector.com or +49-711-80 670-0
DoIP (on UDP + TCP)
observer
HSFZ (on UDP + TCP)
HSFZ
message
observer
DoIP.DLL
CCI_DoIP.cin
SoAd (on TCP)
(with option
Ethernet)
DoIP.DLL
-
The interpretation is typically performed by the TP observer for the respective network. The TP
observer interprets messages sent over the network according to this TP and displays the results in
the Trace window in clear text.
It also includes an implementation of the transport protocol that enables easy sending and receiving of
diagnostic objects. This implementation is realized by a node layer DLL that comes with every CANoe
standard installation and takes care of transport protocol specific functions such as segmentation, flow
control etc. For further explanation on CAN TP and the corresponding osek_tp.dll, refer to [1].
To enable transport layer interpretation, it is needed to activate the ISO TP Observer. Please refer to
the online help in CANoe/CANalyzer on how to activate the observer.
To enable the TP functionality for a simulated node, please refer to paragraph 4.2.
2.2 Diagnostic Descriptions
To work on diagnostics layer in CANoe/CANalyzer, Diagnostic Descriptions have to be assigned to the
configuration. Simple diagnostic descriptions can be defined using CANoe/CANalyzer’s Basic
Diagnostic Editor. If you want to take advantage of the Fault Memory or the Session Control window,
Diagnostic Descriptions in the shape of CDD, ODX (PDX) or MDX files are necessary. All of these
types are referred to as “Diagnostic Descriptions” in this application note. It is possible to mix those file
types within one CANoe/CANalyzer configuration.
2.2.1 CDD – CANdela Diagnostic Description
CANdela Diagnostic Descriptions (CDD) files are databases for diagnostic data, comparable to the
.dbc-file used for CAN messages and signals. The CDD files are created in the Vector tool
CANdelaStudio and can be used in CANoe/CANalyzer for symbolic access and interpretation of
diagnostic services and parameters.
2.2.2 ODX – Open Diagnostic Data Exchange
ODX files (Open Diagnostic Data Exchange) also carry diagnostic data. This data can be divided into
several ODX files and stored in PDX files (ODX archives). Since a single ODX file does not contain
enough information for a diagnostic tester, Vector recommends using PDX (packed ODX) files instead
which contain all relevant single ODX files. The usage of PDX files is similar to the usage of CDD
files.
2.2.3 MDX – Multiplex Diagnostic Data Exchange
MDX files (Multiplex Diagnostic Exchange) is an OEM-specific format carrying diagnostic data as well.
The usage of MDX files is similar to the usage of ODX archive files.
2.2.4 Basic Diagnostic Description (UDS or KWP)
Basic Diagnostic Descriptions are created using CANoe/CANalyzer’s Basic Diagnostic Editor and
therefore can be customized by the user. They are stored as part of the CANoe/CANalyzer
configuration, can be exported and then imported into another CANoe/CANalyzer configuration.
Compared to the above Diagnostic Description formats, they only have limited functionality: since
Basic Diagnostic Descriptions do not contain a fault memory model and also no session model, the
Fault Memory and the Session Control Window is not available when using them. Variants, different
languages, target groups and security access using a Seed&Key DLL are also not available. However,
it is possible to describe simple diagnostic services (UDS & KWP) and afterwards send/receive the
defined requests/responses on CAN, LIN, FlexRay, K-Line and via DoIP using the Diagnostic
Console, CAPL, CAPL test modules/ test case libraries and test units. Additionally, CANoe/CANalyzer
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 8
Contact Information: www.vector.com or +49-711-80 670-0
supports symbolic interpretation of the Basic Diagnostics services and their parameters in the Trace
window. Basic Diagnostic Descriptions can also be used as “additional descriptions”, see chapter 2.3.
For simple applications, Basic Diagnostics thus represents an extension to the process-oriented
approach with CANdela Diagnostic Descriptions.
In order to use Basic Diagnostics, you need to add a “Basic Diagnostic Description” (KWP or UDS) to
the CANoe/CANalyzer configuration using the “Diagnostics/ISO TP…” configuration dialog. While
measurement is stopped, you can define/modify the diagnostic services in the Basic Diagnostics
Editor and commit them to the Diagnostic Console. Saving the CANoe/CANalyzer configuration also
commits these changes.
On the same network, you are able to work with ECUs configured using Diagnostic Description files as
well as with multiple Basic Diagnostic Descriptions at the same time. The TP parameters of these
control units must be different though.
2.2.5 Standard Diagnostic Description
A Standard Diagnostic Description only contains services defined in the ISO standards “Unified
Diagnostic Services” (UDS, ISO 14229) or “Keyword Protocol 2000” (KWP2000, ISO 14230). It is
based on the CDD format, does not contain any OEM-specific services and cannot be customized.
Parameter values can only be chosen based on those defined in the respective standard.
UDS and KWP2000 are standard diagnostic protocols used by many OEMs. Please note that most
manufacturers use diagnostics specifications that differ from these standards!
Three “Generic CDDs” are provided. They describe diagnostics on the level of the standards. This has
the following advantages:
> All mechanisms implemented for concrete Diagnostic Descriptions can be applied for the
standard CDDs, though certain restrictions apply, e.g. the parameter definitions cannot be as
precise as for concrete Diagnostic Descriptions.
> It is possible to set the communication parameters in the configuration dialog, removing the
need to enter them in a database or code them into a CAPL program.
> The Diagnostic Console can be used to get fast access to ECUs.
> The interpretation of the transmitted data can also be parameterized with the Diagnostic
Description(s).
You can also look at the standard definitions by opening the generic CDDs [2] with the CANdelaStudio
Viewer application provided with CANoe/CANalyzer.
Note
The below mentioned features can only be used after including a Diagnostic Description
into the CANoe/CANalyzer configuration.
2.3 Additional Descriptions
Diagnostic Descriptions are sometimes provided by an OEM to his suppliers and the supplier either is
not allowed to or does not want to modify it since this file is the reference for testing. However,
especially during development, it is helpful to be able to use services which are not defined in the
original (“Master-“) Diagnostic Description.
For such cases, it is possible to add so-called “Additional Descriptions” to a “Master” Diagnostic
Description. Each “Additional Description” will take over the communication parameters from its
“Master” Description and provide a dedicated Diagnostic Console, in case of CDD, PDX or MDX
descriptions additionally a Fault Memory Window and Session Control Window. Based on the order
defined in the “Diagnostics/ISO TP” configuration dialog, the Diagnostic Observer will use the
Additional Descriptions to interpret diagnostic messages in the Trace Window, trying to apply the
descriptions in top-down order. The order can be changed in the “Diagnostics/ISO TP” configuration
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 9
Contact Information: www.vector.com or +49-711-80 670-0
dialog via drag & drop. Also in CAPL programs, these Additional Descriptions can be used as
diagnostic targets.
2.4 Trace window
A Diagnostic Description allows tracing diagnostic services (requests/responses) and their parameters
in a symbolic fashion. You can expand the requests/responses in the same way as with ordinary bus
messages:
Figure 2: Trace window
Using the predefined filters of the trace window, you can reduce the amount of displayed data to the
information you are interested in. You can easily e.g. filter out Tester Present messages to a specific
ECU by unchecking the corresponding filter setting:
Figure 3: Predefined filters for diagnostics
Using the analysis filters and column filters of the trace window, you can either filter out a specific
service (stop filter) or only keep a specific service visible in the trace (pass filter). To add such a filter,
just pause the trace and configure the service by drag & drop of a diagnostic observer event to the
filter on the left. By right-clicking on “Stop filter” or “Pass filter”, you can also add a service from the
Symbol Explorer (menu “Add condition… | Add Diagnostic Service…”). Right-clicking on an already
configured service, you can modify the filter conditions (menu “Edit condition…”) in order to filter only
requests or only responses. Additionally, you may use the column filters to show only specific patterns
in the trace:
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 10
Contact Information: www.vector.com or +49-711-80 670-0
Figure 4: Using the column filters of the trace window
2.5 Diagnostic Feature Set
The Vector Diagnostic Feature Set includes several functions that are necessary for development, test
and application of ECUs with/via diagnostics.
Based on the Diagnostic Description, the Diagnostic Console provides interactive access to all
diagnostic services. Diagnostic requests can be selected, parameterised and displayed with their
dedicated response.
The Fault Memory Console provides quick and easy access to the fault memory of an ECU.
With the Session Control window, you can easily change the active session. In combination with a
configured Security DLL, restricted security levels can easily be accessed.
Finally, the OBD-II window allows you to perform On-Board Diagnostics (OBD) according to the SAE
J1979 standard.
Apart from CANoe/CANalyzer the Diagnostic Features Set is also included in the Vector products
CANape MC+D and CANdito. Thereby the complete development process is supported identically.
2.5.1 Interactive Diagnostic Console window
The Interactive Diagnostic Console fetches its information from the Diagnostic Description and
presents an easy way to select a diagnostic request, manipulate its parameters and to send the
request. The response received is presented together with its parameters.
Figure 5: Interactive Diagnostic Console window
2.5.2 Fault Memory window
The Fault Memory window presents a possibility to read out the fault memory list of an ECU once or
cyclically.
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 11
Contact Information: www.vector.com or +49-711-80 670-0
Note
Although with Standard Diagnostic Descriptions (“generic CDDs”) and Basic Diagnostic
Descriptions no Fault Memory Window is available, it is possible to access the fault
memory of an ECU via the Diagnostic Console and via CAPL.
Figure 6: Fault Memory window
2.5.3 Variant Coding Window
The Variant Coding Window is intended to read, write and compare Variant Coding data. Under the
hood, the window takes care about security aspects – i.e. depending on the configured security
source, the variant coding sequence itself is embedded in diagnostic communication sequences
performing e.g. authentication or further security mechanisms.
In order to be able to process variant coding data of an ECU, the corresponding diagnostic description
must be in CDD, ODX / PDX or MDX format and needs to contain variant coding services.
Figure 7: Variant Coding Window
CANoe and CANalyzer as Diagnostic Tools
Copyright © 2020 - Vector Informatik GmbH 12
Contact Information: www.vector.com or +49-711-80 670-0
2.5.4 Diagnostic Session Control window
With the Diagnostic Session Control window, the user can easily switch between different session
states like Default, Extended, or Programming session.
In combination with a security DLL assigned to the corresponding Diagnostic Description (see chapter
2.8 for details), it is possible to switch the session state without having to care about the computation
and exchange of security keys. After switching the session state via the Diagnostic Session Control
window, the user can easily execute diagnostic services from the Diagnostic Console which are only
accessible within sessions protected by a certain security level.
Figure 8: Diagnostic Session Control (left) and OBD-II window (right)
2.5.5 OBD-II window
On-Board Diagnostics, or OBD, in an automotive context, is a generic term referring to a vehicle's selfdiagnostic and reporting capability. OBD systems give the vehicle owner or a repair technician access
to state of health information for various vehicle sub-systems.
OBD implementations use a standardized fast digital communications port to provide real-time data in
addition to a standardized series of diagnostic trouble codes (DTCs), which allow to rapidly identify
and remedy malfunctions within the vehicle.
After configuring 11bit or 29bit Addressing in the “Diagnostics/ISO TP…” configuration dialog for a
network, the OBD-II window plus the corresponding Diagnostic Console and Fault Memory window will
open. Using the OBD-II window by, you can manually start a network scan, so that a request is sent to
all ECUs that will answer with the corresponding responses when they are supported. Based on the
responses the module calculates all available ECUs and the requests supported by them, updating the
corresponding pages “System Status”, “Live Data Grid”, “Vehicle Info” and “On-Board Test Results”.
Additionally, you can send requests using the corresponding Diagnostic Console window as well as
reading the OBD-II related fault memory using the Fault Memory Window for OBD-II.
2.5.6 ECU, gateway or tester simulations using CAPL
CAPL can be used to simulate an ECU, gateway or a diagnostic tester even if no real ECU, gateway
or tester is present. The diagnostics commands in CAPL enable access to the diagnostics services
and data using symbolic names that were defined in the Diagnostic Description. The simulation has to
react on the requests or responses from its counterpart (real or simulated by CANoe) that are received
and processed in appropriate event procedures. It is even possible to implement interactive tester
Loading...