Required High-Level Functionality
In the past, applications have required that a VDA vendor allow more than one call to LoadLibrary () and then allow RP 1210 connections from both copies of the DLL that are open. Typically, an API such as RP 1210 does not require a DLL to be "reentrant." APIs are typically written for a single application loading a DLL and then allowing multiple connections from that one copy of the DLL that is open.
To address the issue, TMC's RP 1210 Update Task Force created terminology that VDA vendors and application developers could use so that end users would know what was required by the application, and what the VDA supported. See "Application, Single-Application, Multi-Application" in TERMINOLOGY .
To be an RP 1210-compiliant VDA, the VDA needs only to implement the "Single Application" mode. The following table addresses the detailed functionality a VDA must implement to be RP 1210-compiliant.
| Item | Notes |
|---|---|
| Single Application | The VDA API shall support a minimum of one executable application using the VDA. This application can spawn sub-processes, threads, applets, and ActiveX controls that share the databus connection once the DLL has been loaded. From that one application, the VDA shall allow up to 16 RP1210_Client-Connect () calls to any number of protocols, or the same protocol. Each client will have its' own filter sets and RP 1210 variables (covered in detail later), allowing each client to be complete separate from one another. |
| Supporting 16 J1939 Addresses (If J1939 is Supported) | The VDAAPI shall support the protection of 16 different J1939 addresses, including handling of RTS/CTS messages for those 16 addresses. These addresses can be claimed from one or more clients, and the VDAAPI will respond with address/NAME data for the highest priority NAME for each address upon request. This is covered in detail later in this document. In order for an application to know if an API has implemented this feature, a new variable [Vendor Information] J1939Addresses=X is present. If the variable does not exist, the application is assumed to allow the protection of 1 J1939 address. If the variable exists, the application should query this value to see how many SRC addresses the VDA will allow it to claim. |
| Automatic Baud/Bit Rate Detection on CAN-Related Protocols | The VDAAPI shall support automatic baud rate detection for all CAN-based protocols when a client connects using "Protocol:Baud=Auto" (i.e. "J1939:Baud=Auto"). When doing the automatic baud detection, the VDA should make every effort to not cause error frames on the CAN bus. |
| Send/Receive Message Buffering | Since Microsoft Windows™ is event-driven; an API satisfying this RP must support this feature. There must be implicit support for asynchronous communication. Blocking (synchronous) requirements were removed in 2011 from all functions except RP1210_ReadMessage ( ). |
| Initialization/Reset | The application software must be able to initialize and reset the hardware through API-supplied functions. |
| Time-Stamping of Messages | Since messages received from the vehicle data link are buffered by the API, there must be a time-stamp associated with each message to resolve ambiguity and establish an order between successive messages. The timestamp is four bytes in length and is in Big Endian (MSB) or Motorola format. See the RP1210_ReadMessage ()
function for the definition and layout of the timestamp. The resolution of the timestamp is implementation-dependent and is given in the API vendor's INI file. Timestamps shall be "global", not "by protocol". For example, if a CAN message comes into the VDA followed immediately by a J1708 message, the timestamps would be sequential. In the past, this was not completely defined and some VDA vendors implemented timestamps globally, others were "per protocol". Having global timestamps help engineers debug using a VDA's "trace" log. |
| Version Reporting | The API shall be able to report its software version information. Both RP1210_ReadVersion ()
and RP1210_ReadDetailedVersion ()
shall be implemented by the API. Software applications should begin using the newer function RP1210_Re-adDetailedVersion (). |
| RP 1210 Variables/Filters | Each client gets its own set of RP 1210 variables (i.e., J1708 Raw/Converted Mode, Echo On/Off), and complete set of filters independent from other clients. This is discussed in depth later in the document. |
| Message Filtering | The API must support message filtering as specified in the definition of the RP1210_SendCommand () function. An implementation of the API shall provide each client with exactly those messages as are specified by the applications filter settings. Each client gets their own separate set of message filters that are completely independent from all other clients. |