OBD: On Board Diagnostics

What is OBD?

Most governments have some emission compliance, or are heading in that direction. If a developer is creating an application that runs on the highway, there is a good chance that OBD certification will be required.

OBD, or On Board Diagnostics refers to Emmision regulations. Most governments have some emission compliance, or are heading in that direction. If a developer is creating an application that runs on the highway, there is a good chance that OBD certification will be required. The application would need to be “OBD Compliant” to a specific set of regulations depending on the target market.

OBD-Regulations depend on the location or country, as well as the market. OBD-Compliant depends on where the application will be used. Most countries have active or pending regulations, so it is important to understand where the vehicle will be used and what the OBD-requirements are. As an example, there is European E-OBD with ‘Euro-4” emissions regulations, or more stringent ‘Euro 6’. The US also has OBD regulations (CARB). Some countries ‘share’ regulations. There are also differences in OBD requirements based on the market, for example on-highway heavy duty vs light duty vehicles.

The need to understand the market and regulations makes OBD that much more complex and requires that an OBD- Fault Management blockset be flexible. <\font>

MotoHawk has an OBD Fault Manager Blockset that can assist application developers in designing OBD compliant systems.

As a mechanism for obtaining OBD certification, many OBD regulations exist that determine what fault states are required. Examples of these include:

• E-OBD – These regulations are enforced in Europe. Other countries have also adopted slight variances of this regulation as well. There are also different versions of the E-OBD standard which is where the term “Euro 4” and “Euro 6” originate.
• OBD II – This is enforced in the United States by the EPA and CARB. Other countries have adopted “lighter” versions of this regulation.
• WWH – This is otherwise known as “World Wide Harmonized” OBD. In general, this is an effort to standardize OBD regulations between countries.

OBD has four principal aspects: emission levels, fault storage, scan tool Interface, and certification process.

Emission Levels

Perhaps the most important part of OBD is the emission requirements. In fact, this aspect of OBD is the driving force behind the other three aspects. So, the application team must know which country will contain the end product and what is specifically required for OBD. The emission controls can change from year to year as well, so the application team needs to be aware of how the emission requirements will change.

Fault Storage

To enforce the emission control rules, a standard method of tracking and organizing faults is required. In addition to fault storage, other information is required for some regulations and not for others. The primary purpose of the OBD Fault Manager is to assist with this aspect of OBD. It can track fault states and also track extra data that is associated with a fault. There are special data stores called “Custom Fields” that will expand and contract with the number of faults present in the application. It allows the user to track information (e.g. “Number of Hours Since DTC was Set”) that is required for some regulations.

See also: MotoHawk Blocks: OBD Fault Manager

Scan Tool Interface

All OBD regulations have communication protocols necessary for extracting the OBD information from an OBD-compliant module. J1939, ISO15031 (a.k.a. SAEJ1979), and ISO14229 are examples of protocols that are OBD-compliant. Similar to the statements above, different OBD regulations require different protocols, so the application team needs to be aware of the required protocol(s). The secondary purpose of the OBD Fault Manager is to provide seamless integration with the various OBD scan tool protocols.

See also MotoHawk

ISO15765 Blockset

J1939 Blockset

Certification Process

The certification process is the verification that OBD applications are obeying the rules. There are some processes in place to prevent OBD applications from breaking the rules. The regulators will require that certain documents are in place and that certain procedures are followed. In summary, most procedures are meant to assure that the vehicles on the road are the same as the vehicles that are used for emissions and scan tool testing.

OBD Fault Manager Blockset

The goal of the OBD Fault Manager (FM) is to not only address OBD needs, but also create a more capable fault manager with more advanced features that allow users to accomplish commonly needed goals.

The OBD FM has:

• A concept of “Drive Cycle”. A “Drive Cycle” is a concept that is present in all versions of the OBD regulations.

• Separate “Emissions Related” and “Non Emissions Related” faults. Some faults impact emissions while others do not. They are treated different throughout the OBD scan tool and state management logic based on this distinction.

• A “Pending” state. The pending state is very similar to the “Active” state in the Classic FM. The difference is that the Pending state is NonVolatile and not Volatile. The pending state requires the concept of a Drive Cycle as it drives the setting of the “Confirmed” state.

• A “Confirmed” state, which is entered when a monitor is known to be failing.

• Aa “Permanent” state.

• A way to selectively clear states.

• A “Global Enable”. In the UDS protocol, the ability to “turn off” faults from being set is needed. If the other modules are in flux (i.e. being programmed) other modules on the bus should not record faults. This helps to prevent false failures.

• The ability to more easily implement commmunication protocol with scan tools.

• The ability to define significantly more faults in the application.

See the [FM Blockset] for full help text on each block.

Scan Tools

One aspect of any OBD system is a common protocol for scan tool fault reporting. Each OBD regulation has a set of required protocols for scan tool interface. It is important for the application designer to understand the market that the OBD system will be used in along with the OBD requirements that need to be met.

MotoHawk has two Blocksets to assist the application developer in reporting OBD faults via a scan tool.

ISO15765/UDS Blockset

J1939 Blockset