ISO 22900-2:2009(E)
12
© ISO 2009 – All rights reserved
In order to declare the capabilities of a D-PDU API implementation, a MVCI protocol module vendor shall
provide a module description file (MDF) in XML. The MDF shall contain all information about supported MVCI
protocol module types, bus types, protocols, and communication links, as well as all related information
regarding parameters and I/O controls. The application may parse the file for resources and use them
dynamically. It may also make use of static information. In the latter case, the application developer could
create a C header file containing and statically matching all necessary resource Ids. For a detailed description
and structure of the files, see Clause F.2.
All API functions return a SNUM32 value representing the function result.
The D-PDU API implementation shall not be restricted to a dedicated operating system or programming
language and shall be portable. However, for unique and clear definition, C was chosen as the programming
language to describe the API.
In general, the D-PDU API implementation shall be made available as a dynamically linkable software module
independent of the target operating system. The approach of a separate software module guarantees easy
exchange. However, in some cases, it may be useful or more appropriate to link the software module statically.
Those cases are considered as proprietary solutions and shall not be the main target of this part of ISO 22900.
The D-PDU API implementation shall support, at a minimum, single clients and asynchronous, multi-thread
operation. Multi client support is not a requirement, but may be offered as an additional feature by an MVCI
protocol module vendor. A multi client implementation shall support multiple sessions and links in parallel. For
every communication link, the implementation shall take care of queuing communication requests.
The D-PDU API implementation shall cover full duplex and event-driven communication, enabling coverage of
advanced vehicle communication principles (e.g. response on event, periodic transmission, etc).
9.1.2 Vehicle protocol requirements
The D-PDU API functions shall be protocol independent. Since protocol standards have frequently changed in
the past and new protocols will be released in the future, the D-PDU API needs to be flexible and generic
enough to easily cover additional protocols not taken into account at time of definition. In order to provide the
application the capability to use any protocol and any of its tool supplier specific implementations, all protocol-
related ComParams have to be documented in a standardized and generic manner. The documentation is
stored in a module description file (MDF) in XML and shall be provided by the MVCI protocol module supplier.
In general, there is no minimum set of protocols with respect to the D-PDU API. However, in order to provide
the required SAE J2534-1 and RP1210a compatibility, and to avoid interference of D-PDU API
implementations of different suppliers, minimal protocol naming conventions are necessary. For all protocols
and ComParams defined in SAE J2534-1 and RP1210a, appropriate definitions will be specified for the
D-PDU API to achieve full compatibility.
9.1.3 Timing requirements for protocol handler messages
There can be unexpected results if two requests are made to the same ECU “simultaneously”. Most ECUs will
ignore the second request, but some ECUs will ignore both requests. As a result, the protocol handler has to
properly serialize requests across multiple CLLs, while still allowing valid parallel communication.
It should also be emphasized that for the cases where CLLs are sharing a physical serial bus, all timing
requirements (CP_P3Min, CP_P3Phys and CP_P3Func) shall be satisfied before subsequent transmissions
can occur.
Message serialization is also required for some complex single CLL scenarios. Consider the case where
Tester Present messages, functionally addressed ComPrimitives and physically addressed ComPrimitives are
all occurring on one bus. Message serialization may be required to assure that the protocol handler adheres to
proper inter-transmit timing and receive timing. All standard Protocols have their timing individually defined
using ComParams. This allows for minor changes in the timing behaviour of a protocol in order to satisfy the
unique attributes of an installed vehicle ECU.