Hiya,

I'm trying to create a document structure that can be used as a source of information on how to request and parse information from vehicles through a diagnostics interface. The point would be to provide software developers with a quick way to incorporate support for vehicle diagnostics, and for software end users to add support for their own vehicles. If this is still confusing, think of it as one file definition you could use to tell your ELM327 to request or interpret vehicle specific information.

I thought I'd walk through what I've come up with so far. I'm looking for feedback, suggestions, etc.

Here's the basic structure:

Code:
<type>                      <!-- J1979,GMLAN,vehicle specific codes -->
  <protocols>            <!-- physical protocol specifications: CAN, ISO9141,etc -->
    <controller />        <!-- 'controller' or functional group parameter request is sent to -->
  </protocols>
  <active>                  <!-- parameters that are explicitly requested and have a response -->
    <parameters>         <!-- parameter command that must be sent out for request -->
      <parameter>
        <conversion />    <!-- parameter response data conversion info -->
      </parameter>
    </parameters>
  </active>
  <passive>                <!-- parameters that are read from watching bus traffic -->
    <parameter>         <!-- parameter command that must be sent out for request -->
      <conversion />    <!-- parameter response data conversion info -->
    </parameter>
  </passive>
</type>
You start out with a specific type of diagnostic data, the most common being the OBD2 pids we all know from SAEJ1979. Another few examples include GMLAN (GM's internal data), SSM (from Subaru), MMDS (from Mazda) and so on. The <protocols> tags specify the physical protocols compatible with the type of diagnostic data we're interested in. So for SAEJ1979, we might have something like:
Code:
<type name="SAEJ1979" desc="OBDII Standard PIDs">
  <protocols>
    <protocol name="SAE J1850 PWM" />
    <protocol name="SAE J1850 VPW" />
    <protocol name="ISO 9141-2"/>
    <protocol name="ISO 14230-4 (KWP 5BAUD)" />
    <protocol name="ISO 14230-4 (KWP FAST)" />
    <protocol name="ISO 15765-4 (CAN 11/500)"/>
    <protocol name="ISO 15765-4 (CAN 29/500)" />
    <protocol name="ISO 15765-4 (CAN 11/250)" />
    <protocol name="ISO 15765-4 (CAN 29/250)" />
  </protocols>
(pretty much all protocol types are supported with J1979 for obvious reasons)

Or for SSM, which uses only a small subset of protocols, you might get something like:
Code:
<type name="SSM3" desc="Subaru Select Monitor III">
  <protocols>
    <protocol name="ISO 9141-2"/>
    <protocol name="ISO 15765-4 (CAN 11/500)"/>
  </protocols>
OBD Messages are constructed with something like the following format: [h0 h1 h2 d0 d1 d2 d3 d4 d5 d6]. Three header bytes, specifying the message priority, and the source and target addresses, and 7 data bytes. The goal of this document definition is to be able to construct and parse such messages.

To construct the header, I have each protocol specify controllers available. The most common is the ECU. So if we had a car that talked the ISO 9141-2 protocol, we'd probably have an ECU specified like so:
Code:
    <protocol name="ISO 9141-2">
      <controller id="ECU" name="Engine Control Unit" prio="0x68" target="0x6A" sender="0xF1" />
    </protocol>
Assuming we've finished defining protocols, there are now two categories for parameters: active and passive. Active parameters are meant to represent commands that must be explicitly sent, whereas passive represent parameters you see when you monitor bus traffic. We further wrap individual parameters with a <parameters> tag to specify the controller type associated with each parameter (ie pids for your ECU, your TCU, etc). Here's what the first few active parameters from SAEJ1979 might look like.
Code:
  <parameters controller="ECU">
    <parameter data="01 00 00 00 00 00 00" name="PIDs Supported 0x01-0x20" desc="?" numbytes="4">
      <conversion expr="MAPPED"/>
    </parameter>
    <parameter data="01 01 00 00 00 00 00" name="Monitor Status Since DTCs Cleared" desc="?" numbytes="4">
      <conversion expr="MAPPED"/>
    </parameter>
    <parameter data="01 02 00 00 00 00 00" name="Freeze DTC" desc="?" numbytes="2">
      <conversion expr="MAPPED" />
    </parameter>
    <parameter data="01 03 00 00 00 00 00" name="Fuel System Status" desc="?" numbytes="2">
      <conversion expr="MAPPED" />
    </parameter>
    <parameter data="01 04 00 00 00 00 00" name="Calculated Engine Load Value" desc="?" numbytes="1">
      <conversion units="%" default="true" expr="x*100/255" min="0" max="100"/>
    </parameter>
  </parameters>
It might seem convoluted to wrap parameters in a controller specification, but this lets you determine which parameters are available on a vehicle. The parameter elements themselves contain a data attribute which fill the [d0-d7] part of the standard obd message. The conversion specifies what needs to be done with the response data to convert it to a meaningful value.

I haven't looked at specifying passive parameters yet, but they'll likely be the same as active without a controller specified and with the expected header bytes explicitly included.

So yeah, that's pretty much it. I'm particularly worried about glancing over something major that makes incorporating other diagnostic types impossible. Also, this idea is something that's contingent on people actively contributing to it -- especially in its initial implementation. Any advice would be greatly appreciated.

Regards,


Preet