Light Duty: Saving Interface

By Robert Braswell, TMC Technical Director & Marsh Galloway, TMC Information Manager

Industry standards are great for two reasons: they facilitate market transactions and lower acquisition costs. When it comes to diagnostic tools for commercial vehicles, that means cheaper prices and better interoperability between vehicle/component manufacturers. But compliance issues can cause quite a bit of consternation for technicians and fleets.

Fleets and suppliers recognized the need for developing a common communication adapter for diagnostic tools 10 years ago when every electronic control unit (ECU) manufacturer had a proprietary adapter and every ECU application required use of the OEM’s adapter. The situation was fast becoming intolerable, with training and tool costs rapidly multiplying for multi-make fleets.


Various industry segments approached TMC about the issue and the Council’s S.12 Onboard Vehicle Electronics Study Group decided to tackle the situation by developing a communication adapter best practice. The result was RP 1210, Windows Application Program Interface, and it brought substantial efficiencies for both maintainers and manufacturers.

In the 10 years since its introduction, RP 1210 has undergone two major revisions. As a result:

  • Hardware adapter manufacturers can now concentrate on adapters and hardware;
  • PC-application developers can now concentrate on diagnostic applications; and
  • Market competition is providing better and faster adapters, better diagnostic applications and reduced overall diagnostic cost.

Most manufacturers are aware of RP 1210 and are complying—or working on complying—with the voluntary standard. But compliance is not universal, and that costs the industry significant time and resources. When technicians encounter device-to-software-to-vehicle interface issues, the root of the problem is frequently unclear. Meanwhile, days can be spent going back and forth with application and adapter OEMs trying to debug the problem.

Because of this, technicians can’t assume that a RP 1210-compliant application will always work with a RP 1210-compliant adapter. In fact, some application developers have written their application to only work with certain adapters, defeating the purpose of RP 1210. This is especially troublesome if the application developer has not adequately communicated the need to use a specific adapter, said Ken DeGrant, field application engineering manager for Dearborn Group.


At TMC’s 2008 Annual Meeting, the S.12 Study Group presented a state-of-the-industry report on compliance with RP 1210. During this session, panelists highlighted the most common problems technicians encounter today, and what can be done to solve them. These include:

1. The adapter does not seem to be communicating. If so, it’s important to verify that the:

  • Adapter drivers have been installed;
  • Adapter has been configured in the application (and sometimes in several different places);
  • Application allows you to choose all RP 1210 compliant adapters, and;
  • Correct protocol has been selected (such as J1708, J1939).

2. A corrupted RP 1210A.INI file is preventing the application from “seeing” all installed drivers. Plugging in any non-Microsoft-certified device—which includes most RP 1210A adapters— into a universal serial bus (USB) port other than where it was first installed will generate the operating system’s “Hardware Found” wizard. Pressing “Cancel” is a sure-fire way to cause the adapter not to work, said DeGrant. Do not “Cancel,” just press “Next,” “Next,” etc.

3. The adapter sometimes loses communications in USB devices. If this occurs, the following should be attempted to resolve the issue:

  • Unplug the USB cable from the adapter;
  • Unplug the vehicle-side cable from the truck;
  • Ensure the power is off for five seconds;
  • Plug the USB cable into the adapter;
  • Reconnect the adapter to the truck; and
  • If that fails, reboot the computer and try the process again.

4. The adapter is not supporting multiple applications simultaneously. To identify if that is the issue, look for applications that are minimized to the Windows task bar.

DeGrant said most adapter vendors have some type of application that is used to troubleshoot the communication status. Verifying the communication with these applications, can help to answer the question: “Who do I call; the application vendor or the adapter vendor?”


Being an informed consumer is critical when it comes to purchasing diagnostic communication adapters. It’s important to know not only what applications the fleet needs, but also what those applications themselves require, said David Shock, product manager for Snap-On/NEXIQ Technologies, who also served on the S.12 panel.

An application OEM may specify a specific adapter and not test with all available RP 1210A adapters for several reasons. First, it’s very costly to test all adapters and manufacturers are committed to their own dealer network/products. Second, TMC RP 1210 is only a voluntary standard so not everyone feels obligated to comply.

Noncompliance to standards also contributes to hidden costs. Technicians become frustrated and lose valuable time, and fleets find they must go out and buy multiple adapters.

Lee Lackey, technical sales lead for Noregon Systems, Inc., reported that SAE and ISO committees have found that simply providing examples of a standard doesn’t do enough to clarify how to interpret a given specification. Compliance standards do a much better job of providing methods and processes to verify that a device or application has implemented a standard correctly.

In light of this, TMC’s S.12 Study Group has created a RP 1210 Compliance Task Force with Lackey as chairman. The Task Force plans to:

  • Develop a compliance test plan for both RP 1210A and RP 1210B versions, including compliance for both drivers and applications;
  • Define known incompatibilities that have been coded around by existing applications; and
  • Encourage application developers to test their software against all major RP 1210 adapters.

Preliminary recommendations from the Task Force thus far include:

  • Discouraging hard coding for a specific adapter(s) in production release software;
  • Ensuring an RP 1210-compliant application provides the ability to select any RP 1210 adapter;
  • Ensuring the application is robust enough to work even with slight variances in the .INI file; and
  • Encouraging both application owners and adapter vendors to provide contacts for resolving engineering and test issues.

A compliance standard, however, does have limits. It may not adequately address changes in technology, such as a lack of serial or parallel ports, or increases in processor speed.

And compliance testing does not come free. However, Lackey said having adapter vendors and application developers working closely together will reduce support costs and reduce the frustrations of the end user of the tools.
In the end, that’s what everybody wants—especially customers.