MotoHawk Blocks: OBD Fault Manager
Contents
OBD Fault Manager Blockset
MotoHawk already had a Fault Manager blockset, but it does not have all the components required for an OBD Fault Manager. Therefore, a new OBD Fault Manager blockset was developed. In this article, ‘Fault Manager’ will refer to the existing Fault Manager blockset and OBD Fault Manager will refer to the OBD Fault Manager Blockset (OBD-FM).
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 Fault Manager has:
- A Distributed fault detection method where the user can distribute Fault blocks throughought the model and the faults are collected in one calibration Fault Manager table.
- A marquees displays the current fault states (suspected, active, occurred) with 6 modes (disabled, enabled, sticky…).
- Blocks to iterate through the faults. Simulink logic can be used to iterate though each fault. OBD-FM also has this capability, and it is expanded.
- Fault action blocks decouple detection logic from the fault response logic. So, a fault can be detected in one subsystem, and an action taken in other subsystems elsewhere in the model without wires or busses.
Limitations of the Fault Manager:
The Fault Manager blockset is useful and has many well like features, but it is not capable to implement a full OBD system.
- The Fault Manager has no concept of a ‘Drive Cycle’ which is critical for bookkeeping purposes. All the regulations have some definition of a drive cycle (or operating cycle). Ex. If you turn the key on and it turns on for x time, and engine reaches y degrees, this could be considered a drive cycle (depending on the regulations).
- All faults have the same category. There is no distinction between emissions-related faults and normal faults which is required by OBD, and is also required by diagnostic protocols.
- Exisisting Fault states in the Fault Manager of suspected, active, occurred do not correspond to legislated definitions of required fault states (ex. Pending, MIL request..).
- There is no concept of ‘Permanent” faults, which is required for OBD. A ‘permanent fault’ cannot be cleared from the scan tool. In the Fault Manager, ‘fault clear’ would clear any fault.
What is the OBD Fault Manager?
The OBD-FM is a new fault manager designed to accommodate OBD compliant systems. It is intended to be as simple as necessary, but flexible enough to satisfy multiple OBD standards. The OBD-FM is designed from the ground up to be able to work with many different of protocol handlers such as UDS or J1939.
The OBD-FM contains 12 states that track the progress of a fault from initial detection to fault storage and clearing. It introduces new features for fault action routing that are not present in the Fault Manager. Finally, it introduces the concepts of ‘Fault Related Data” and “Drive Cycle” into the OBD-FM.
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.
By itself, the use of the OBD Fault Manager does not satisfy OBD requirements. It sets up the building blocks to create an OBD compliant system. An OBD infrastructure needs to be built in the application.
OBD Fault Manager Concepts
Fault States are the ability to track the progression of the occurance of a fault. While the Fault Manager had 3 states (suspected, active, occured) and 6 modes (Disabled, Enabled, Sticky, Enabled-Persistant, Sticky-Persistant, Save Occcurred) the OBD-FM has twelve states and no modes. The states are shown below.
Suspected is the same as on the Fault Manager. Pending is similar to Active but a little different. The main difference between Active and Pending is that Pending is always in Non-Volatile and Pending won't be cleared - the application can clear it with a block at the end of a drive cycle. A fault is pending if it passes the 'pending filter', so it is detected X out of Y samples. Confirmed is the next stage after pending. Once a pending state happens it needs to happen on multiple drive cycles to be confirmed. There is another X of Y type of filter. So if X /Y is set to 1 /1 then the fault won't go to confirmed immediately, but on the next drive cycle it can go to Confirmed. Fault must be pending on X /Y COMPLETED drive cycles to be confirmed. On the first drive cycle the fault is pending, it will move to Confirmed on the next drive cycle. Confirmed is also in NonVolatile, and it doesn't clear on it's own.
OBD Fault States
- NonVolatile fault states do not "self heal". Because there are many OBD regulations with different criteria for when a fault can be cleared, the OBD-FM NV fault states will not 'self heal' if there is not a fault for a length of time.
- Intervention by the Application is necessary - action must be taken in the application to clear the faults. This is called "bookkeeping" and usually occurs at the end of a drive cycle.
OBD Fault States Table
Ready means that the X of Y has finished. The manager has gone through all X of Y samples. It doesn't matter if a fault is set or not, just if it went through all the cycles. This means that the diagnostic has run to completion at least once. Failed this Drive Cycle may not be needed in the application, but can be used to move pending fault to confirmed. Test Complete this drive cycle is similar to Ready except that it gets reset each time a drive cycle is finished. There are some services that require that state.
MIL (Malfunction Indicator Light) request is a specialized state that may or may not be used depending on the regulations. Some regulations require that if at least one state is requesting the MIL, then the MIL needs to be left on. This does not turn on any lights, it just tracks the state. Previously Active means the state was Confirmed but it was cleared by a mark to clear block. It is NV. Faults with Permanent state cannot be cleared by the fault clear blocks. Permanent state gets set by a calibration, when you enter the Confirmed state it would also set to Permanent. Each regulation has its own requirements for the criteria that must be used to clear a fault. This is up to the user to determine criteria to clear the fault.
These last three states are specific to UDS states. Test Failing is a non-latched version of Pending. It is stored in Volatile. Failed Last Drive Cycle is a special state for J1939 - did it fail the last drive cycle, not the current one.
Blockset Overview
The following is a discussion of some of the OBD-FM blocks that would be frequently used in the application. For a full list and description of all available OBD Fault Manager Blocks, Click Here.
OBD Fault Manager Block
This is shown in the upper right and needs to be placed once somewhere in the model if the applicaton is going to use the OBD Fault Manager.
Fault Definition and Mark to Clear
The next two blocks will likely be important in the OBD application.
The OBD Fault Definition block is similar to the classic fault manager fault definition block. It tells the application whether there is an OBD fault or there isn't.
The next block, OBD Fault Mark to Clear, is used for the 'bookkeeping'. A boolean signal is input that you want to clear the particular fault state, and at the end of the drive cycle, the fault state is cleared.
Fault Iterator Blocks
The OBD Fault Iterator block iterates through the OBD Fault Definitions in the OBD Fault Manager, and gets a obdfault_T reference to each one matching a given criteria. The OBD FaultT to Integer block can be used to convert the faultT to an integer for the application.
The Fault Iterator block can be used to iterate through all of the faults, the suspected faults, the pending faults, the confirmed faults, the ready faults, the completed faults, the MIL request faults, the previously active faults, the permanent faults, the test failing faults, the test failed since last clear faults, the failed last drive cycle faults, and the test failed since key cycle faults.
OBD Fault Property Block
The OBD Fault Property block is similar to the fault properties block in the 'classic' fault manager, but you only have one outport, so if you want multiple properties you would need to copy the block multiple times in the model. The block outputs one of the following properties: The output may be one of the following properties: Suspected X Counts, Suspected Y Counts, Pending Drive Cycles, Total Drive Cycles, Suspected X Count Limit, Suspected Y Count Limit, Pending Drive Cycle Limit, •Total Drive Cycle Limit, Emission-Related, Is Permanent.
OBD Fault Trigger Blocks
The OBD-FM has several blocks that trigger based on status of the OBD-FM. For example, the end of a drive cycle can be triggered by the OBD Drive Cycle Complete Block.
The Clear all Faults Block will clear all faults (except faults with a permanant state - these can only be cleared by Mark to Clear) and resets the counters. The block can be configured to clear all, or only emmission related faults.
OBD Fault Activity trigger executes when the fault meets the set criteria.
OBD Fault Manager (FM) Blocks
MotoHawk contains an OBD Fault Manager Blockset to assist the application developer in designing systems that satisfy OBD requirements. The use of the blockset in itself does not ensure OBD compliance.
See the Current Version MotoHawk Help for additional information on all MotoHawk Blocks and OBD FM.
Basic Blocks
OBD Convert Fault Reference to Integer
Advanced Blocks
OBD In Use Performance General Counter Definition
OBD In Use Performance General Counter Get
OBD In Use Performance General Counter Increment
OBD In Use Performance Monitor Definition
