CAPL Callback Interface in CANoe
Copyright © 2024 - Vector Informatik GmbH 3
Contact Information: www.vector.com or +49-711-80 670-0
In some cases it is possible to use a gateway or proxy on a supported bus technology (e.g. CAN) with
a supported transport protocol (e.g. ISO TP). All CANoe features are available in this case, only the
gateway or proxy has to forward the data to and from the ECU.
You may want to read the application note AN-IND-1-004 “Diagnostics via Gateway in CANoe”, which
lists different concepts of implementing such gateway nodes. This use case of CANoe is also of
special interest for users who need a diagnostic gateway e.g. in early development stages where the
gateway hardware to access the ECU is not readily available to developers or testers.
Finally in rare cases it may be more efficient to implement the communication on transport protocol
level directly, especially if no (standard) diagnostics description can be used.
2.4 What can you do with the CCI?
The following is a list of tasks possible once the CCI is implemented:
> Change CAN identifiers to test if the ECU only responds to the IDs it was assigned to.
> Delay response messages from an ECU simulation for an arbitrary amount of time to test the
timeout implementation in a tester.
> Delay transport protocol messages individually to check the transport protocol implementation in
the ECU for correct handling of timeouts.
> Change the content of individual transport protocol messages, like padding byte values.
> Make the tester or ECU simulation send transport protocol messages which do not conform to the
specification and should cause some error reaction in the receiver.
> Any use-case specific non-standard handling that needs direct access to the transport protocol
layer, and non-standard changes to the diagnostics protocol.
3.0 Basic concept of the CAPL callback interface for diagnostics
The CCI works as glue between the diagnostics and transport protocol layers: Whenever a diagnostics
object (diagRequest or diagResponse) is sent by the CAPL program, its data is forwarded to the
transport protocol, which transfers it on the bus. In addition there are CAPL functions that control the
setup and status of the communication connections, and functions that provide information to the CCI.
3.1 CAPL functions called by the CCI
The following CAPL functions are called by the CCI when specific events occur. The functions are
denoted by a underscore “_” at the start of the function name. The CAPL program has to perform
actions that depend on the concrete transport protocol or use case.
> void _Diag_SetChannelParameters()
The CAPL program is instructed to configure a communications channel to the peer (in a tester
node to the ECU, and vice versa). The transport protocol parameters are typically retrieved from
CANoe or hard-coded values might be used as well.
In a tester, this function is called every time DiagSetTarget is called, in an ECU simulation it is
called during measurement start.
> void _Diag_DataRequest (BYTE data[], DWORD count, long furtherSegments);
The provided data has to be sent to the peer. If the argument furtherSegments is non-zero, the
data is segmented and may be sent in a special way, e.g. when using OEM-specific Modeling
Add-ons.
> void _Diag_SetupChannelReq();
Called only in a tester before the first request is sent to indicate that a communications channel to
the ECU should be established. Connection-oriented protocols need to perform a “channel setup”
step, while for most connection-less protocols (like ISO/OSEK TP), nothing has to be done. In
latter case it suffices to call Diag_SetupChannelCon() immediately.
> void _Diag_SendFunctional();
Called only in a tester, when a functional request is sent (by the CAPL function
DiagSendFunctional).
3.2 CCI functions called by CAPL
The following functions are implemented by CANoe and can be called from the CAPL code. Note the
prefix Diag_ differentiating the functions from other diagnostics related CAPL functions.