CAT C4.4 Diesel Engine data logging and alarm system with HMI

May 13, 2017

(This article is currently a work in progress. Updates will be appended as work progresses. This project is my final thesis and it will be shared in its entirety, once completed and time allows for full disclosure.)

For a two-year study in electronics and embedded programming of which I am currently writing the final thesis, I have chosen to design and build an ECU and HMI for controlling/monitoring a Caterpillar C4.4 diesel engine.

The engine was originally meant to be used as a genset engine, but ended up being installed in a fishing boat as a prime mover for the propeller. The engine comes with no electronic controls, so it was a perfect candidate for a custom built system.

There are two parts to the system, the ECU which collects sensor data, and the HMI which logs the data, visualizes it and features an alarm system with high and low limits.

 System overviewECU

The system collects the following data from the engine:

  • Cool water temperature (NTC)
  • Lubrucation oil temperature (NTC)
  • Engine room temperature (NTC)
  • Exhaust temperature (K-type TC)
  • ECU board temperature (TMP36)
  • Battery voltage
  • Brake power output
  • RPM

The data is collected by a custom built ECU board based on an ATMega328P 8 bit microcontroller and converted to engineering units and sent to the HMI controller.


The ECU continually sends engine data at 5 Hz. The embedded Linux device parses the incoming data, performs any data manipulation required, logs data and check for alarms and visualizes on screen. Data is displayed on 10 inch Beetronics 1980×1080 display with a touch interface.


The HMI is programmed in Python by using Qt4 and PyQt4 on a Raspberry Pi 3 running Ubuntu Mate 16.04.

Alarm system

The alarm system is built by instantiating an alarm object for each ECU parameter that requires an alarm. Each object must have a lowlimit ang highlimit. At a specifiec interval, the incoming values from the ECU are checked if they are outside the specified range for each alarm object.

If a parameter is found to be outside the specified range, the yellow console window will turn red, an appropriate alarm message is displayed in the console and an alarm sound will start and continue until the Acknowledge button is pressed, after which the alarm sound will stop. The console window will remain red until the parameter is within the range specied in the alarm object.


Data logging is not performed at every received data event. Logging 5 times per second is unncesssary and would put needless wear on the SD card, fill up card space way too quickly and provide needlessly large data sets. Data is appended a date and time stamp

Conditions for logging:

  • Engine RPM must be more than 0
  • Logging interval is every other second


Defining the automotive temperature sensor characteristics

The negative temperature coeffficient sensor does not have a linear relationship between resistance and temperature, so calculating temperature is not as simple as using the straight line equation y=ax+b. For thermistors, the temperature is calculated using an alternative model instead of the more precise third order Steinhart-Hart equation. See reference 2 for more information. The alternative model:

eq 510 (5.1.0)

Rearranging 5.1.0 to find R at a given temperature when we have calculated the sensors beta value leaves the formula

eq 511(5.1.1)

The beta value is found in the datasheet for the sensor, but because the datasheet is not available, the beta value will have to be calculated. The temperature range of the medium which the sensor will measure is from 0 to 100 degrees C. To perform a calculation of the beta value for the sensor, an ice bath and a stove can be used to reference values 0 and 100 degrees. Temperature is given in Kelvin degrees in the forumlas.

So, by having two points on the T/R curve, a beta value can be calculated. The formula for calculating the sensors beta value is found by rearranging formula 5.1.0 to give β:

eq 512(5.1.2)

Now we can calculate the beta value for the NTC which will be used to measure the cooling water temperature. The NTC forms part of a voltage divider circuit like shown in illustration 5.1.

Thermistor Vdiv.png

Gathering data for temperature sensor T/R characteristics curve in illustration 5.2 was done by placing the sensor in a water bath while not touching the bottom and heating it while stirring and recording values of resistance and temperature at different temperatures after the temperature had stabilized. The temperature reference probe was a calibrated K-type thermocouple and a UNI-T 325 temperature meter. The construction of the thermocouple was done in a thinner material compared to the NTC, so the reaction time from a change in temperature to the temperature probe actually measuring it would be smaller for the thermocouple. Because of this, the temperature stabilized at the respective temperatures before the value was noted.

RvsT curve ill52.png

 The measured values which this curve is based on are shown in appendix 2.
When calculating the beta value using the measured data, the result will not be absolutely correct due to imprecision in the measured values, but close enough. I will use 3 values for calculating the beta value to check that the result is in the ball park. I will use 21,3 C as the T 0 and perform 3 calculations at 55, 83 and 100 degrees C. If the result is the same or close, the value is good.

Microcontroller and RPM input

The brain of the ECU will be an Atmel ATMega328P 8 bit microcontroller. I chose this processor because of familiarity, ease of coding, community support via the Arduino eco-system and because it does the job. Another candidate was the ATMega32 which has an extra port and 2 extra ADC inputs and provides more options for future expansion. It requires a larger footprint and is a little more expensive but most importantly, to my knowledge, does not offer the same support from the Arduino compiler out of the box because it is not part of the Arduino product line. The 328P is sufficient, so I chose to go with what I know to be working. The RPM optocoupler is shown in illustration 4.1, connected to PD2 because the pin is external interrupt 0. The output from one of the generator windings is routed to the pin 1 on the optocoupler and pin 2 goes to ground. On the rising edge of the positive sine wave, the optocouplers internal LED will emit light and the interrupt pin on the MCU is pulled low.