Networked Input Messages and Default States
The IPC uses input messages from other modules to control the gauges, informational indicators, warning indicators and message center message displays over the communication networks. Network messages can drop out or be missing for a variety of reasons, such as high network traffic on the bus. The IPC incorporates a defined strategy for handling missing network messages based on time. The required time for a network message to be missing differs between the various gauges, indicators and message center displays. The strategy is basically the same for all types of indication but differs in the length of time required for the network message to be missing. If a required network message is missing or invalid for less than the preset time criteria, the gauge or indicator that requires the network message remains at the last commanded state based upon the last network message received. The example below describes how the stability-traction control indicator (sliding car icon) functions using a time criteria of 5 seconds.
If the stability-traction control network message is missing for less than 5 seconds and the stability-traction control indicator (sliding car icon) was on, the indicator remains in the on state until the next network message is received. Again, using the time criteria example, if the network message remains missing or invalid for more than 5 seconds, the IPC sets a U-code DTC and the IPC output becomes a default action for the indicator or gauge. The indicator may default on/off or the gauge may default to the rest position.
Each indicator or gauge utilizes a different default strategy depending on the nature of the indication. Refer to the diagnostic overview descriptions located before each individual pinpoint test for further description of the default action specific to each indicator or gauge. If the missing messaged input to the IPC returns at any time, the normal function of the gauge or indicator resumes.
In order to diagnose a messaged network concern, it is very important to understand:
- where the input originates.
- all the information necessary for a feature to operate.
- which module(s) receive(s) the input or command message.
- which module controls the output of the feature.
- whether the module that receives the input controls the output of the feature, or whether it outputs a message over the communication network to another module.