3.1 Demands on an IE Detection Algorithm
Intuitively one might think that the only goal of the algorithm is to detect, diagnose and fault isolate IEs. However, there is more to it than that. There are three identified customers of the algorithm being developed in this master thesis, all of them have different needs and
demands on the diagnostic algorithm. The identified customers are listed below.
1. Workshop Operator (Customer Satisfaction) 2. R&D Engineers at Scania (Knowledge & Statistics)
3. Legislation Requirements (Vehicle / Truck-Operator Safety & Compliance)
3.1.1 Workshop Operator
The workshop operator has different demands on the algorithm depending on the
circumstances. If the algorithm has detected that the number of IEs is above the threshold limit, a DTC should be triggered. The DTC should contain information such as pinpointing the faulty component, what eventual tests to perform, what order (if there are multiple tests), how to repair the component (if possible), or if the workshop operator should replace it entirely.
However, suppose that there is a generic DTC for the whole subsystem in which the algorithm operates. In that case, the algorithm should save key figures in the operational data to help the workshop operator search for the faulty component. If the values of the key figures are within predetermined ranges, different recommendations should be given. For example, if the values are low, that would indicate that the fault causing the unspecified DTC is not found in the components that this algorithm is monitoring. The probability that the
component that the algorithm is monitoring is causing the unspecified DTC increases as the key figure in the operational data increases.
If it is likely that the problem is regarding the component that this algorithm is monitoring, then a list of measures to be taken for the workshop operator should be provided. The list should be composed regarding the probability of the measures for solving the issue, the cost of the measures, the time required to perform the measures, and if the specific measure hinders the performance of a subsequent measure if the first measure did not solve the issue. An example of a measure hindering another measure can be one of the measures needs to be performed at an elevated temperature while the other has to be done at 0 degrees. Then it would be problematic to perform these measures one after the other. The goal of ordering the recommended measures is to save money and the time required from the workshop operator. [27]
3.1.2 R&D Engineers at Scania
There is a knowledge gap regarding IEs in the industry and academia (as explained in 2.6).
Therefore, the R&D Engineers at Scania are interested in obtaining statistics regarding IEs, such as the signal deviance resulting from IEs, IEs characteristics, and the conditions resulting in IEs. This data can be obtained by observing the freeze frames saved when DTC is triggered by the algorithm, recording algorithm data, and by observing how the key figures stored in the operational data develop over time.
Scania can use this knowledge to develop a theory that explains how IEs are connected to signal deviance, the root causes, and the typical development of IEs over time. The
developed theory can be used to prevent IEs from happening or at least reduce the probability of IE occurring considerably. Moreover, the theory can also be used to further perfect the algorithms from this master thesis. If this is done correctly, it can increase the uptime of all Scania vehicles.
3.1.3 Legislation Requirements and Vehicle Safety
Legislation requires that emissions are kept below certain limits and that the vehicle is safe to operate at all times. Therefore, one of the customers of this algorithm is the legislative authorities. The algorithm can be used to ensure no IEs affect critical sensors involved in emission measurement, such as the NOx sensor.
Furthermore, the vehicle safety is of concern when DTCs are triggered. There should be clear indications if the vehicle is not allowed to be driven because of the error. Determining how the vehicle operator should react when an error has appeared is a careful balancing between vehicle uptime, customer satisfaction, and hazard risk. [23]
3.2 Analog, Digital and Smart Sensors
The sensors that are examined in this master thesis are of different complexity. Arguably the exhaust manifold pressure sensor is the least complex sensor. It is the least complex
because it is an analog sensor. There are few embedded self-diagnostics in the sensor, and
the signal going from the sensor into higher software layers only contains information regarding the pressure.
The HTS is a bit more complicated. It deploys the SENT protocol for communication, which means that more information is available in each transmitted message. There can be from 1 up to 4 probes for each HTS. This means that the probes have to be treated separately, which essentially means that it requires one monitor for each probe. Moreover, the HTS sensor has self-diagnostics. The sensor sends an error code in the SENT message if its internal parameters are out of range, as explained in 2.5.2.
The NOx sensor is the most advanced and complicated sensor treated in this thesis, and it is arguably among the state of the art in sensor technology. The sensor’s embedded diagnostic routine is very sophisticated. Moreover, there is plenty of information available in each CAN message. For example, each CAN message contains measured NOx, and O2
concentrations, among the others.
Because of the varying self-diagnostic capabilities of the sensors, the demands on the monitoring algorithm vary as well, depending on which sensor is to be monitored. The simpler the sensor, the simpler the monitoring algorithm can be, but more upper software layer diagnostic routines are needed to capture all errors. The smarter the sensor, the more complex the monitoring algorithm has to detect errors which are not captured by the sensor's self-diagnostics. However, fewer diagnostic routines are needed for smart sensors because many errors are already captured by the embedded software within the sensor itself.
3.3 Multiple Monitoring Algorithms
As described in 2.4, different IEs cause different behavior in the signal going from the sensor into the upper software layers. No single monitoring algorithm can capture all of these signal behaviours. Therefore, to capture a broad range of IEs, multiple monitoring algorithms are needed.
Decisions regarding deployment of a monitoring algorithm, which algorithm, and how many are dependent on the sensor at hand. In some cases, no monitoring algorithm might be needed at all. For example, this can be the case if the sensor is very robust, and it is not likely that IEs will occur, and if they occur, the subsystem impact likely would not be
significant enough to be a problem. In contrast, if there is a very problematic sensor, it might be worth deploying many monitoring algorithms to capture future hard/permanent faults at an early intermittent stage which would enable proactive replacement.
3.4 Real-Time Processing
The developed algorithms are to be performing their diagnostics of IEs in an operating truck.
That implies that the algorithm needs to be able to perform real-time processing. In Figure 12 below, the “Data acquisition” is the time required to get the signal to the ECU, where the algorithm is running. The “Algorithm processing” is the time that the algorithm needs to perform its designated calculations and operations. Lastly, the “Frame” is the maximum time
allowed for the total processing of a sample before the subsequent signal sample needs to be processed. Real-time processing is achieved if the sum of data acquisition time and the algorithm processing time are less or equal to the frame time (see Figure 12).
Figure 12. Illustration of a real-time processing system. The picture is inspired by Vidya Viswanathan’s online presentation (MathWorks). [28]
The pressure sensor, HTS, and NOx-sensor signal frequencies have been stated in 2.1.3, 2.2.2, and 2.3.2. By knowing the sampling frequency, the calculation of the time between samples is possible. The time in between samples is equal to the frame time. See Table 3 for the frame time, data acquisition time, and algorithm processing time for the sensors examined in this master thesis.
Table 3. Frame time, data acquisition time, and algorithm processing time of the pressure sensor, HTS, and the NOx-sensor.
Maximum Frame Time and Data Acquisition Time + Algorithm Processing Time [ms]
Pressure Sensor, 100 Hz Signal ‘b’
Pressure Sensor 1kHz Signal ‘a’
HTS, 250 Hz Signal ‘f’
NOx-sensor, 20Hz Signal ‘g’
Since the algorithm processing time varies for different sensors (because of the varying signal frequency), the computationally intensive nature of algorithm operations has to be considered before deploying an algorithm to a specific sensor. For example, because the NOx-sensor has a low sampling frequency, more computationally intensive operations, such as spectral analysis, may be performed.
3.5 Test Conditions
The monitoring algorithms should not necessarily be active at all times. When the algorithm should be active is different for each sensor, it depends on sensor complexity, function, and location.
The pressure sensor algorithm should be active once the protocol ‘O‘ is completed. The NOx sensor algorithm should be active once the protocol ‘O’ is completed and the sensor heater reaches the temperature ‘P’.
The HTS sensor algorithm should be active once protocol ‘O’ is completed. Moreover, the HTS ambient temperature has to be between (-)’Q’ and (+)’R’ C°, which is the operational temperature range of the sensor. The temperature condition is there to avoid recordings of transient errors.
3.6 DTC Threshold
The purpose of the algorithm threshold is to trigger a DTC if the subsystem impact is too significant or if the diagnostic prognosis states that the sensor is about to fail shortly. Multiple variables need to be taken into consideration to enable the calculation of the threshold. See the numbered list below for all of the questions that need to be answered.
1. How much can the signal deviate before too much subsystem impact?
2. Is the threshold constant or variable?
3. If the threshold is variable, what variables should be considered, and how often should the threshold be calibrated?
4. How do factors such as performance of other sensors and actuators in the
subsystem, general engine health, engine load, vehicle speed, cold, heat, vibrations, and sensor age affect the threshold?
5. For how long does the signal have to deviate before DTC?
6. Is the threshold the same for all types of sensors and IEs?
7. How many IEs typically occur before resulting in a permanent error?
8. At what point can a prognosis regarding near future failure be stated depending on the occurrence of IEs?
When all eight questions above are answered, a threshold can be calculated. However, because of the knowledge gap (as discussed in 2.6), it is challenging to obtain the
information needed. Alternatives to a theoretically perfect threshold are presented in 4.3.3.