Documentation PDU-API MSP SFTNG ISO 11898 Onboard PDF

D-PDU API Protocol Documentation
Softing Specific Protocol

MSP_SFTNG_ISO_11898_onboard
Date: 14.06.2012
Software version 11.22.001
Softing Automotive Electronics GmbH

Richard-Reitzner-Allee 6
85540 Haar, Germany
Tel: +49 (0) 89 4 56 56 - 420
Fax: +49 (0) 89 4 56 56 - 399
info.automotive@softing.com
www.softing.com
Copyright by Softing Automotive Electronics GmbH, 2010

All rights reserved.

Version 11.22.001
Copyright Notice
2011 Softing Automotive Electronics GmbH. All rights reserved.

No part of these instructions may be reproduced or processed, copied or distributed in any
form whatsoever without prior written permission by Softing. Any violations will lead to compensation claims.
All rights are reserved, particularly with regard to patent issue and GM registration.
The producer reserves the right to make changes to the scope of supply as well as to technical data, even without prior notice.
Careful attention was given to the quality and functional integrity in designing, manufacturing
and testing the system. However, no liability can be assumed for potential errors or for their
effects. In particular, we cannot assume liability in terms of suitability of the system for a particular application. Should you find errors, please inform your distributor of the nature of the
errors and the circumstances under which they occur. We will be responsive to all reasonable ideas and will follow up on them, taking measures to improve the product, if necessary.
We call your attention to the fact that the company name and trademark as well as product
names are, as a rule, protected by trademark, patent and product brand laws.
Version 11.22.001
II

CONTENTS
1
INTRODUCTION
PROTOCOL OVERVIEW
2.1
Terms And Abbreviations
2.2
ISO 11898 Overview
2.3
MSP_SFTNG_ISO_11898_onboard Communication Overview
2.3.1
2.3.2
3
Differences to Other Protocols

Protocol Message Structure
COMPARAMS
3.1
ComParam Summary Tables
3.1.1
3.2
Physical Layer
ComParam Detailed Descriptions
3.2.1
4
5
6
Physical Layer ComParam Definitions
9
10
10
PROTOCOL DESCRIPTION
13
4.1
13
Protocol Initialization
4.1.1
4.2
Initialization Procedure
Protocol Communication
4.2.1
4.2.2
4.3
Communication Procedure
Communication Example
Protocol De-Initialization
4.3.1
4.4
De-initialization Procedure
Protocol Error Handling
4.4.1
4.4.2
Protocol Errors
Receive Errors
13
13
13
13
16
16
16
17
18
ANNEX
21
BIBLIOGRAPHY
23

Version 11.22.001
iii
FIGURES
Figure 1 D-PDU API and MSP_SFTNG_ISO_11898_onboard protocol overview
Figure 2 Communication overview on MSP_SFTNG_ISO_11898_onboard
Figure 3 MSP_SFTNG_ISO_11898_onboard protocol communication example
Figure 4 ComPrimitive PDU structure
Figure 5 Example of a complex sequence on MSP_SFTNG_ISO_11898_onboard
1
4
5
6
15
TABLES
Table 1 List of Terms and Abbreviations
Table 2 Physical layer ComParam summary table
Table 4 Physical layer ComParam definition table
Table 5 Sequence to reproduce using the MSP_SFTNG_ISO_11898_onboard protocol
Table 6 CAN frames used to reproduce sequence from table 5
Table 7 Error events handled by MSP_SFTNG_ISO_11898_onboard protocol
Version 11.22.001
iv
3
9
10
13
14
16

INTRODUCTION
The D-PDU API is an MVCI (Modular Vehicle Communication Interface) module, and the MVCI concept
was initiated by several OEMs in 2001. The main objective is to achieve exchangeability of components
in vehicle communication systems and thus have the ability to optimize systems in terms of functionality
and costs.
MVCI defines general requirements for VCI hardware, API software and diagnostic MCD 3D server applications. To allow exchangeability of vehicle interfaces 3 compliance levels are defined (software compliance, electrical compliance and mechanical compliance).
The open generic approach of MVCI sets no limits concerning applications, protocols or VCI capabilities.
The D-PDU API application programmers interface provides a flexible generic API to vehicle communication interfaces with benefits as follows:
D-PDU API allows scalable systems with multiple VCIs, even from different suppliers
Standardized tool integration with one D-PDU API DLL per VCI supplier
No limitations and restrictions concerning protocol support
Usage directly by applications or in combination with D-server
Standardized communication parameters for standard protocols, defined for usage with ODX
files
API specification allows high performance multilink applications
Flexibility for tool supplier and OEM
Since Softing actively contributes to D-PDU API, MVCI and ODX standardization work in ASAM and ISO
for many years it is able to offer a comprehensive D-PDU API product portfolio that includes the
MSP_SFTNG_ISO_11898_onboard protocol. The following diagram gives an overview of the D-PDU API
products that includes the MSP_SFTNG_ISO_11898_onboard protocol stack.
Figure 1 D-PDU API and MSP_SFTNG_ISO_11898_onboard protocol overview

Version 11.22.001
1
THIS PAGE IS INTENTIONALLY LEFT BLANK.
Version 11.22.001
2

Terms And Abbreviations
PROTOCOL OVERVIEW
This document defines the protocol behaviour as well as the protocol ComParams for the Softing specific
D-PDU API vehicle communication protocol MSP_SFTNG_ISO_11898_onboard. The protocol implementation is a part of the Softing system; all protocol-specific requirements for this non-standard protocol are defined in this document.
The Softing D-PDU API allows multiple concurrent ComLogicalLinks on each physical CAN channel,
independent from the ComLogicalLinks protocol. Thus, multiple ComLogicalLinks using the same or different CAN-based protocols can be used concurrently.
This protocol can be used to easily transfer arbitrary messages on the ISO_11898 CAN bus. It also provides the possibility to easily setup one or more CAN-Frames that are transmitted cyclically within a predetermined and synchronized timeframe.
With this behaviour, the MSP_SFTNG_ISO_11898_Onboard protocol can be used to perform cyclic
broadcast messages as they are used in other protocols without adding a special handling to every
single protocol requiring this feature.
The ISO_11898 (CAN bus) is described in the documents [ISO_DIS_11898_2] and [ISO_DIS_11898_3].
All standard D-PDU API descriptions apply, as defined in [ISO_22900_2].
This protocol can be identified after parsing the Module Description File (MDF) that is provided in the
D-PDU API installation package. The protocol can be found in the PROTOCOL section with the short
name MSP_SFTNG_ISO_11898_onboard.
2.1
TERMS AND ABBREVIATIONS
The following table describes all terms and abbreviations that are used in this document.
Table 1 List of Terms and Abbreviations
Term or Abbreviation
Definition
AHI
Application Host Interface protocol interface module in the firmware.
Application
Client application that uses the D-PDU API library.
API
Application Programming Interface
CAN
Controller Area Network
ComMan
Communication Manager
ComParam
Communication Parameter of D-PDU API
CoP
Communication Primitive
D-PDU API
Diagnostic protocol data unit application programmer interface,

ISO 22900-2
ECU
Electronic Control Unit
FW
Firmware
IOCTL
Input Output Control Command
ISO
International Organization for Standardization
LoLi
Logical Link
MDF
Module Description File, see D-PDU API

Version 11.22.001
3
Protocol Overview
Term or Abbreviation
Definition
MVCI
Modular vehicle communication interfaces
MW
Middleware
2.2
ISO 11898 OVERVIEW
The ISO 11898 international standard (Part 2 and 3) specifies the characteristics of setting up an interchange of digital information between ECUs of road vehicles equipped with Controller Area Network
(CAN) using high and low speed transmission rates.
Part 2 specifies the high-speed medium access unit as well as the medium dependent interface.
Part 3 specifies the low-speed medium access unit as well as the medium dependent interface.
The Controller Area Network (CAN) is a serial communication protocol which supports distributed control
and multiplexing.
Figure 2 Communication overview on MSP_SFTNG_ISO_11898_onboard
2.3
MSP_SFTNG_ISO_11898_ONBOARD COMMUNICATION OVERVIEW
There are several communication protocols that sometimes require the periodic transmission of CAN
frames (sometimes called broadcasts) independently from the regular diagnostic service routines. Earlier, so called special commands had been implemented into each protocol that required such functionality. With the D-PDU API, multi-link communication is available, and this functionality can be achieved
without adding special features to diverse protocols.
Therefore Softing introduced the MSP_SFTNG_ISO_11898_onboard protocol, which offers this functionality in a more generic way. CAN frames can easily be programmed to be sent in a cyclic way with determined timings, indefinitely or with a programmable send counter and several of these broadcasts can
be started and stopped independently.
The goal of this protocol is, to enable and disable periodic transmission of single CAN frames, or groups
of CAN frames at arbitrary times. Separate ComPrimitives are used, to enable such a periodic transmission, and to disable them. Each ComPrimitive in this protocol acts like a switch for the protocol engine
and will return with a state finished immediately.
Version 11.22.001
4

The following diagram offers a communication overview on the MSP_SFTNG_ISO_11898_onboard protocol:
The Application sends CoP1, to start the periodic transmission of CAN Frame1 with the time period T1 = 100ms. The CoP1 will finish immediately after triggering the sending process.
The Application sends CoP2, to start the periodic transmission of CAN Frame2 with the time period T2 = 200ms. The CoP2 will finish immediately after triggering the sending process.
The Application sends CoP3, to stop the periodic transmission of CAN Frame1 with the time period T1 = 100ms. The CoP3 will finish immediately.
The Application sends CoP4, to stop the periodic transmission of CAN Frame2 with the time period T2 = 200ms. The CoP4 will finish immediately.
The ComPrimitives CoP1 to CoP4 in this example are merely used as triggers to switch on or switch
off the generation of CAN frames by an independently running protocol engine. In the example below,
the first ComPrimitive is triggering cyclic sending of CAN Frame1. The ComPrimitive is then finished
(PDU_COPST_FINISHED) and is no longer used. Any script that only can handle synchronous generations of ComPrimitives can continue at this point, and trigger CAN Frame2 using a new ComPrimitive.
In order to stop sending CAN Frame1 a new ComPrimitive (CoP3) is issued, telling the protocol engine to
stop sending CAN Frame1.
Figure 3 MSP_SFTNG_ISO_11898_onboard protocol communication example
2.3.1
Differences to Other Protocols

Version 11.22.001
5
Protocol Overview
The protocol MSP_SFTNG_ISO_11898_Onboard is designed to easily setup transmission of (repeating)

CAN frames with a fixed timing relative to each other, without the usual diagnostics requirement of requests with associated responses. Therefore, ComPrimitives in this protocol have a number of characteristics different from other protocols:
ComPrimitives in this protocol only transmit frames and do not receive any answers.
Service ComPrimitives in this protocol are triggering certain actions on the CAN interface. The
lifetime of these actions is not equal to the lifetime of the ComPrimitives. The ComPrimitives always finish immediately after triggering their action.
ComPrimitives always have 1 as repetition counter (NumSendCycles), which means they start or
stop a CAN object once. The CAN object itself, however, can have arbitrary repetitions.
ComPrimitives in this protocol can trigger one or multiple CAN-Frames that can be started or
stopped on the vehicle bus. Each frame can be transmitted with the same or differing CANIdentifiers. When multiple CAN-Frames are sent from a single ComPrimitive, a separation time
for each frame can be specified.
2.3.2
Protocol Message Structure
The complete behaviour of the ComPrimitives is controlled by their PDUs which have to be structured in
the following way: A header information at the beginning of the PDU defines the behaviour of the ComPrimitive, followed by frame information for the one or multiple CAN frames that are to be sent.
Figure 4 ComPrimitive PDU structure
2.3.2.1 Header Information

The header information represents the first 8 bytes in the ComPrimitives PDU Data, and contains the
following fields:
Mode (UNUM16): Sets the operation mode of this ComPrimitive. The operation mode can have
the following values:
Mode=1: Start operation of the defined CAN object.
Mode=2: Stop operation of the defined CAN object. In this case, FrameCount is not evaluated.
Version 11.22.001
6

ObjectID (UNUM16): Sets an identifier for the CAN object. The valid values for ObjectID are in
the range: [0; 0xFFFF]. The ObjectID may be chosen freely, and can be used to uniquely identify
an object.
FrameCount (UNUM32): Sets how many CAN frames are defined by this ComPrimitive. Valid
values for FrameCount are in the range: [1; 100].
2.3.2.2 Frame Information

The frame information defines the structure of a single CAN frame in the ComPrimitive PDU. The frame
information has to be repeated FrameCount times to define all the CAN frames.
The frame information, contains the following fields:
CANID (UNUM32): specifies the CAN identifier for the frame. If the most significant bit is set, the
CAN identifier is sent as an extended (29 bit) identifier, otherwise as standard (11 bit) identifier.
The valid values for CANID are:
[0; 0x7FF]
[0x80000000; 0x9FFFFFFF]
[1; 0x7FFFFFFF]
Number of frame repetitions.
[-1]
Infinite number of repetitions.
CycleTime (UNUM32): Specifies the repetition cycle of the CAN frame. Valid values for CycleTime are in the range:
Delay time of this CAN frame in Microseconds.
Length (UNUM32): Defines the length of the given CAN frame and corresponds directly to the
DLC (data length code) of a CAN frame. Valid values for Length are in the range:
[0; 8]
Repetition rate of this CAN frame in s (microseconds).
Offset (UNUM32): Defines the initial delay before the CAN frame is sent to the bus for the first
time. This time is calculated from the starting time of the ComPrimitive; all CAN frames described
by the ComPrimitive are sent at this starting time plus their respective offset.
Note, that the CAN driver will use a as good as possible strategy, when the given timings cannot be realized, e.g. if two CAN frames are scheduled to be sent at the exact same time, they will
be sent as fast as possible. Valid values for Offset are in the range:
[0; 0xFFFFFFFF]
For 29 bit CAN identifiers 0-0x1FFFFFFF.
SendCount (SNUM32): Specifies the number how often the CAN frame shall be sent on the
bus. Valid values for SendCount are in the range:
[0; 0xFFFFFFFF]
For 11 bit CAN identifiers 0-0x7FF.
Data length of this CAN frame in bytes.
Data (UNUM8): Contains the (up to) 8 data bytes of the CAN frame. Note that this field is always
8 bytes long, even if length is smaller than 8. Valid values for Data are in the range:
[0; 0xFF]

CAN frame data bytes.
Version 11.22.001
7
Protocol Overview
THIS PAGE IS INTENTIONALLY LEFT BLANK.
Version 11.22.001
8

ComParam Summary Tables
COMPARAMS
3.1
COMPARAM SUMMARY TABLES
The following chapters give an overview of all ComParams that have been defined for this protocol regardless of their implementation status. These include ComParams of support type Standard and Optional. ComParams that are not supported by the Softing implementation of the D-PDU API are listed in
Chapter Fehler! Verweisquelle konnte nicht gefunden werden. Fehler! Verweisquelle konnte nicht
gefunden werden..
The ComParams for each layer are listed in a separate table. The tables also list the support type information, specified as S - Supported Mandatory or O - Supported Optional ComParam.
These ComParams are defined in the D-PDU API specification [ISO_22900_2].
3.1.1
Physical Layer
Table 2 Physical layer ComParam summary table
Parameter Short Name
PARAM_CLASS
Support
Type*
Default Value
CP_Baudrate
BUSTYPE
500000
CP_BitSamplePoint
BUSTYPE
80
CP_ListenOnly
BUSTYPE
CP_SamplesPerBit
BUSTYPE
CP_SyncJumpWidth
BUSTYPE
15
CP_TerminationType
BUSTYPE
*Legend for Support Type:

S Supported Mandatory Protocol Parameter
O Supported Optional Protocol Parameter

Version 11.22.001
9
ComParams
3.2
COMPARAM DETAILED DESCRIPTIONS
3.2.1
Physical Layer ComParam Definitions

Table 3 Physical layer ComParam definition table
Short Name
CP_Baudrate
Description
Structure
resolution
Range
Type
Description: Represents the desired baud rate. If the desired

baud rate cannot be achieved within the tolerance of the protocol, the interface will remain at the previous baud rate.
Type: PDU_PT_UNUM32
Range (ISO22900-2): [0; 0xFFFFFFFF]
[500000]
Range (Softing D-PDU API): [0; 1000000]

CP_BitSamplePoint
Description: This sets the desired bit sample point as a percentage of the bit time.
Type: PDU_PT_UNUM32
Range: [0; 100]
CP_ListenOnly
[80]
Description: Enable a Listen Only mode on the Com Logical

Link. This will cause the link to no longer acknowledge received
frames on the CAN Network.
Type: PDU_PT_UNUM32
Value: [0;1]
[0]
0 = Listen Only Mode Disabled

1 = Listen Only Mode Enabled
CP_SamplesPerBit
Description: Number of samples per bit.

Type: PDU_PT_UNUM32
Value: [0;1]
[0]
0 = 1 sample per bit

1 = 3 samples per bit
CP_SyncJumpWidth
Description: This sets the desired synchronization jump width

as a percentage of the bit time.
Type: PDU_PT_UNUM32
Range: [0; 100]
Version 11.22.001
10
[15]

ComParam Detailed Descriptions
Short Name
CP_TerminationType
Description
Structure
resolution
Range
Type
Description: CAN termination settings. This ComParam can be

used to manually change the termination being used on the vehicle bus line.
Type: PDU_PT_UNUM32
Value: [0;4]
[0]
0 = No termination
1 = AC termination
2 = 60 Ohm termination
3 = 120 Ohm termination
4 = SWCAN termination

Version 11.22.001
11
ComParams
THIS PAGE IS INTENTIONALLY LEFT BLANK
Version 11.22.001
12

Protocol Initialization
PROTOCOL DESCRIPTION
4.1
PROTOCOL INITIALIZATION
4.1.1
Initialization Procedure
There is no dedicated initialization procedure for the MSP_SFTNG_ISO_11898_onboard protocol.

The client application can start sending ComPrimitives right after the connection with the VCI is established and the physical parameters are set.
4.2
PROTOCOL COMMUNICATION
4.2.1
Communication Procedure
In order to start and stop periodic transmissions of CAN frames, ComPrimitives of the type
PDU_COPT_SENDRECV are used.
The NumSendCycles entry in PDU_COPT_CTRL_DATA of the ComPrimitive, is used only with value 1,
which means that a ComPrimitives can start or stop a CAN object once. All other values are ignored. The
CAN object itself, however, can have an arbitrary number of repetitions.
The NumReceiveCycles entry in PDU_COPT_CTRL_DATA of the ComPrimitive accepts only value 0.
This protocol can only transmit frames and does not receive any data. All other values are ignored.
4.2.2
Communication Example
This chapter describes a typical and more complex requirement (broadcast messages for the protocol
MSP_VW2000LP_on_TP20) that can be achieved using the MSP_SFTNG_ISO_11898_onboard protocol. The requirement is to reproduce the following sequence on the CAN bus:
Table 4 Sequence to reproduce using the MSP_SFTNG_ISO_11898_onboard protocol
Time
(from start of the ComPrimitive)
CAN bus
0ms
0x55, 0x55
20ms
0xaa, 0xaa
40ms
0x55, 0x55
60ms
0xaa, 0xaa
80ms
0x55, 0x55
1080ms
0xaa, 0xaa
2080ms
0x55, 0x55
3080ms
0xaa, 0xaa

Version 11.22.001
13
Protocol Description
In order to achieve this in MSP_SFTNG_ISO_11898_onboard, we need to define these four CAN

frames:
Table 5 CAN frames used to reproduce sequence from table 4
Frame
Nr
CANID
SendCount
CycleTime
[s]
Offset
Length
Data[8]
0x100
40000
0x55, 0x55
0x100
40000
20000
0xAA, 0xAA
0x100
-1
2000000
1080000
0xAA, 0xAA
0x100
-1
2000000
2080000
0x55, 0x55
These frames will guarantee the exact same sequence as the requirement has specified. The CAN
frames with acceptance key 0x55, 0x55 are sent every 40ms at first, while exactly at the time between
two 0x55, 0x55-frames (which is after 20ms and then every 40ms) the acceptance key 0xAA, 0xAA is
broadcast. Of course, with MSP_SFTNG_ISO_11898_onboard, it is also possible to start a second
ComPrimitive, to send another broadcast, maybe on a different or the same CAN ID.
Version 11.22.001
14

Protocol Communication
Figure 5 Example of a complex sequence on MSP_SFTNG_ISO_11898_onboard

Version 11.22.001
15
4.3
PROTOCOL DE-INITIALIZATION
4.3.1
De-initialization Procedure
There is no dedicated de-initialization procedure on the MSP_SFTNG_ISO_11898_onboard protocol.
4.4
PROTOCOL ERROR HANDLING
In the D-PDU API all error-handling mechanisms that are described in protocol specifications are implemented. The returned error item contains a D-PDU API defined error code (Event error code), which
identifies the error that occurred, along with a vendor-specific extra error code (Extra error code). A text
translation of vendor-specific extra error codes is available in the Module Description File (MDF). The
following table contains error events that are covered by the error handler.
Table 6 Error events handled by MSP_SFTNG_ISO_11898_onboard protocol
Event Error Code
Extra Error Code
Protocol Errors
(see 4.4.1, page 17)
PDU_ERR_EVT_PROT_ERR
PDU_XTRA_ERR_COB_LNK_BUS_OFF
PDU_XTRA_ERR_COB_LNK_ERROR_PASSIVE
PDU_XTRA_ERR_COB_LNK_ERROR_FRAME
PDU_XTRA_ERR_COB_LNK_ERROR_ACTIVE
Receive Errors
(see 4.4.2, page 18)
PDU_ERR_EVT_RX_ERROR
PDU_XTRA_ERR_COB_CMD_OBJEKTBUFFERFULL
PDU_XTRA_ERR_COB_CMD_OBJEKTNOUPDATE
PDU_XTRA_ERR_COB_CMD_OBJNOTINOBJBUFFER
PDU_XTRA_ERR_COB_CMD_NOTENOUGHOBJEKTINBUFFERFREE
PDU_XTRA_ERR_COB_CMD_MODE_NOT_SUPPORTED
PDU_XTRA_ERR_COB_CMD_OBJECT_WITH_OBJECTID_ALREADY_EX
IST
PDU_XTRA_ERR_COB_LNK_WRONG_INTERFACE
PDU_XTRA_ERR_COB_LNK_NOINSTANCEMAPPERFREE
PDU_XTRA_ERR_COB_LNK_OUT_OF_AHI_RESOURCES
PDU_XTRA_ERR_COB_LNK_VEHICLE_IF_NOT_FOUND
Version 11.22.001
16

4.4.1
Protocol Errors
Error Event Code = PDU_ERR_EVT_PROT_ERR

In the following paragraph the extra error codes that are part of the PDU_ERR_EVT_PROT_ERR group
are described.
PDU_XTRA_ERR_COB_LNK_BUS_OFF
Error Description:
The CAN controller of the selected ComLogicalLink resource is in bus off state. The CAN controller transmit error counter 256.
Involved ComParams and possible solution:
No ComParam involved. A possible solution to this error situation is to reset the diagnostic interface CAN controller. Also check the CAN bus for faults to eliminate bus errors; make sure the
CAN bus is terminated properly.
Link State Change:
No change.
PDU_XTRA_ERR_COB_LNK_ERROR_PASSIVE
Error Description:
The CAN controller of the selected ComLogicalLink resource is in error passive state. The CAN
controller transmit error counter or receive error counter 128.
No ComParam involved. A possible solution to this error situation is to check the CAN bus for
faults to eliminate bus errors; make sure the CAN bus is terminated properly.
Link State Change:
No change.
PDU_XTRA_ERR_COB_LNK_ERROR_FRAME
Error Description:
Error frame received on the CAN bus.
faults to eliminate the bus errors; make sure the CAN bus is terminated properly.
Link State Change:
No change.
PDU_XTRA_ERR_COB_LNK_ERROR_ACTIVE
Error Description:
The CAN controller of the selected ComLogicalLink resource is in error active state. The CAN
controller transmit error counter and receive error counter 127.
faults to eliminate bus errors; make sure the CAN bus is terminated properly.
Link State Change:
No change.

Version 11.22.001
17
4.4.2
Receive Errors
Error Event Code = PDU_ERR_EVT_RX_ERROR

Error event code for the receive errors. In the following paragraphs the extra error codes that are part of
the PDU_ERR_EVT_RX_ERROR group are described.
PDU_XTRA_ERR_COB_CMD_OBJEKTBUFFERFULL
Error Description:
The CAN object buffer is full. The maximum number of CAN objects that can be processed by
the protocol handler is 100. When this number is exceeded, this error event is sent to the application.
No ComParams are involved. Use less simultaneous ComPrimitives on this ComLogicalLink.
Link State Change:
No change.
PDU_XTRA_ERR_COB_CMD_OBJEKTNOUPDATE
Error Description:
Error on updating an active CAN object. The specified CAN object could not be updated because
it does not exist.
No ComParams are involved. Use a valid ObjectID to update an active CAN object (see 2.3.2,
page 6).
Link State Change:
No change.
PDU_XTRA_ERR_COB_CMD_OBJNOTINOBJBUFFER
Error Description:
Error on deleting an active CAN object. The specified CAN object could not be deleted because
it does not exist.
No ComParams are involved. Use a valid ObjectID to delete a CAN object (see 2.3.2, page 6).
Link State Change:
No change.
PDU_XTRA_ERR_COB_CMD_NOTENOUGHOBJEKTINBUFFERFREE
Error Description:
Not enough space in CAN object buffer the to create a new CAN object.
No ComParams are involved. Delete another CAN object before allocating a new one.
Link State Change:
No change.
Version 11.22.001
18

PDU_XTRA_ERR_COB_CMD_MODE_NOT_SUPPORTED
Error Description:
ComPrimitive operation mode not supported.
No ComParams are involved. Only use one of the supported operation modes that are defined in
section 2.3.2.1 on page 6.
Link State Change:
No change.
PDU_XTRA_ERR_COB_CMD_OBJECT_WITH_OBJECTID_ALREADY_EXIST
Error Description:
The used CAN object ID is invalid. Another object with the same ID already exists.
No ComParams are involved. Object IDs must be unique, you can only use each object ID once
during the same time.
Link State Change:
No change.
PDU_XTRA_ERR_COB_LNK_WRONG_INTERFACE
Error Description:
Wrong vehicle interface type selected. The MSP_SFTNG_ISO_11898_onboard protocol supports only CAN interfaces.
No ComParams are involved. You must choose a CAN interface resource when creating the
ComLogicalLink.
Link State Change:
No change.
PDU_XTRA_ERR_COB_LNK_NOINSTANCEMAPPERFREE
Error Description:
No more ComLogicalLinks available for MSP_SFTNG_ISO_11898_onboard protocol. The
maximum number of ComLogicalLinks has been exceeded.
Involved ComParams and possible solutions:
No protocol ComParam involved. Use less ComLogicalLinks.
Link State Change:
No change.

Version 11.22.001
19
PDU_XTRA_ERR_COB_LNK_OUT_OF_AHI_RESOURCES
Error Description:
No more firmware resources available for creating the ComLogicalLink, internal error.
Involved ComParams and possible solutions:
No ComParam are involved. Try to release some firmware resources by reducing the number of
concurrently running ComPrimitives or reducing the number of concurrently opened ComLogicalLinks on the affected MVCI hardware module.
Link State Change:
No change.
PDU_XTRA_ERR_COB_LNK_VEHICLE_IF_NOT_FOUND
Error Description:
The selected vehicle interface was not found.
No protocol ComParam involved. A possible solution to this error situation is to select the correct
vehicle
interface
instance
when
opening
a
new
ComLogicalLink
on
MSP_SFTNG_ISO_11898_onboard protocol.
Link State Change:
No change.
Version 11.22.001
20

ANNEX
The D-PDU API standard specifies that on a MVCI module one or more protocols can run in parallel on
different ComLogicalLinks. With Softings D-PDU API module, the following ComLogicaLinks can run in
parallel:
1 ComLogicaLink with a K-Line protocol
1 to 32 ComLogicaLinks with CAN protocols

Version 11.22.001
21
THIS PAGE IS INTENTIONALLY LEFT BLANK
Version 11.22.001
22

BIBLIOGRAPHY
/1/
[ISO_22900_2] Road vehicles Modular vehicle communication interface

(MVCI) - Part 2: Diagnostic protocol data unit application programming interface (D-PDU API), Specification release version 2.2.0, 2009-02-01.
/2/
[ISO_DIS_11898_2] Road vehicles Controller area network (CAN)

Part 2 High-speed, medium access unit.
/3/
[ISO_DIS_11898_3] Road vehicles Controller area network (CAN)

Part 3 Low-speed, fault-tolerant, medium dependent interface.
/4/
D-PDU API software for vehicle communication interfaces User Manual,

Softing AG

Version 11.22.001
23

Documentation PDU-API MSP SFTNG ISO 11898 Onboard PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Documentation PDU-API MSP SFTNG ISO 11898 Onboard PDF

Uploaded by

Copyright:

Available Formats

D-PDU API Protocol Documentation

Softing Specific Protocol

Softing Automotive Electronics GmbH

Copyright by Softing Automotive Electronics GmbH, 2010

D-PDU API Protocol Documentation

2011 Softing Automotive Electronics GmbH. All rights reserved.

D-PDU API Protocol Documentation

Terms And Abbreviations

ISO 11898 Overview

MSP_SFTNG_ISO_11898_onboard Communication Overview

Differences to Other Protocols

ComParam Summary Tables

Physical Layer ComParam Definitions

D-PDU API Protocol Documentation

D-PDU API Protocol Documentation

No limitations and restrictions concerning protocol support

Usage directly by applications or in combination with D-server

API specification allows high performance multilink applications

Flexibility for tool supplier and OEM

Figure 1 D-PDU API and MSP_SFTNG_ISO_11898_onboard protocol overview

D-PDU API Protocol Documentation

THIS PAGE IS INTENTIONALLY LEFT BLANK.

D-PDU API Protocol Documentation

Terms And Abbreviations

TERMS AND ABBREVIATIONS

Application Host Interface protocol interface module in the firmware.

Client application that uses the D-PDU API library.

Application Programming Interface

Controller Area Network

Communication Parameter of D-PDU API

Diagnostic protocol data unit application programmer interface,

Electronic Control Unit

Input Output Control Command

International Organization for Standardization

Module Description File, see D-PDU API

D-PDU API Protocol Documentation

Modular vehicle communication interfaces

ISO 11898 OVERVIEW

Figure 2 Communication overview on MSP_SFTNG_ISO_11898_onboard

MSP_SFTNG_ISO_11898_ONBOARD COMMUNICATION OVERVIEW

D-PDU API Protocol Documentation

MSP_SFTNG_ISO_11898_onboard Communication Overview

The following diagram offers a communication overview on the MSP_SFTNG_ISO_11898_onboard protocol:

Figure 3 MSP_SFTNG_ISO_11898_onboard protocol communication example

Differences to Other Protocols

D-PDU API Protocol Documentation

The protocol MSP_SFTNG_ISO_11898_Onboard is designed to easily setup transmission of (repeating)

Protocol Message Structure

Figure 4 ComPrimitive PDU structure

2.3.2.1 Header Information

D-PDU API Protocol Documentation

MSP_SFTNG_ISO_11898_onboard Communication Overview

2.3.2.2 Frame Information

Number of frame repetitions.

Infinite number of repetitions.

Delay time of this CAN frame in Microseconds.

Repetition rate of this CAN frame in s (microseconds).

For 29 bit CAN identifiers 0-0x1FFFFFFF.

For 11 bit CAN identifiers 0-0x7FF.

Data length of this CAN frame in bytes.

D-PDU API Protocol Documentation

CAN frame data bytes.

THIS PAGE IS INTENTIONALLY LEFT BLANK.