Fault Detection of Gas Turbine in MATLAB

Hello friends! Today, we will discuss fault detection of a gas turbine in MATLAB and Simulink. The aim is to understand how measurements, a reference model and decision logic can work together to identify abnormal behavior. We will move from the physical system to residual calculations, then examine how to test a detector without confusing a simulated alarm with a validated machine-protection system.

The original project contains a useful collection of scopes, delays, summing blocks and alarm indicators. However, some block names and explanations need correction. In particular, a mu-law signal compressor is not an air compressor, and a piston-engine power-stroke model does not become a gas-turbine model merely by changing its displayed name.

We will retain the original screenshots as a historical teaching example and explain their limitations directly. Alongside them, we will develop a clearer monitoring approach with defined units, operating conditions and fault labels. The calculations below are illustrative; they do not establish operating limits for an actual turbine.

What Happens Inside a Gas Turbine?

A gas turbine compresses incoming air, adds energy by burning fuel, and expands the hot gas through a turbine. Part of the turbine's work drives the compressor. Depending on the machine, useful output may drive a generator, another mechanical load or a propulsion system. Shaft arrangements differ, so not every installation has all rotating equipment on one shaft.

The ideal Brayton cycle provides a starting thermodynamic description. A practical engine also has pressure losses, component efficiencies, temperature limits and control dynamics. NASA's explanation of the combustor between the compressor and turbine helps establish the physical sequence before assigning mathematical blocks.

For monitoring, we might observe shaft speed, temperatures, pressures, fuel flow and vibration. Every signal needs an identified measurement location and unit. An exhaust temperature is not automatically the turbine inlet temperature, and a normalized controller signal is not automatically a pressure in bar.

Review the Original Simulink Model Carefully

The complete historical model is shown below. It combines a filtered input, a mu-law block, delays, temperature-related signals and an engine-dynamics section. These blocks demonstrate signal processing and feedback connections, but the diagram alone does not establish a physically consistent turbine model.

The block marked Reference Filter has the transfer function 10/(s + 10). With time measured in seconds, that is a first-order signal filter with a 0.1-second time constant. It does not remove dust from airflow. Its input and output are numerical signals, and its physical interpretation depends on the model surrounding it.

The mu-law subsystem shown next performs a nonlinear transformation involving magnitude, logarithm and sign. This is signal companding, as described in the MathWorks compand documentation. It does not calculate compressor pressure ratio, airflow, efficiency or shaft power.

For normalized input x, a common mu-law relation is y = sign(x) ln(1 + μ|x|)/ln(1 + μ). That equation changes the signal's amplitude distribution. A physical compressor instead needs relationships among mass flow, pressure, temperature, speed and efficiency. Similar words do not make the models interchangeable.

Distinguish Dynamic Approximations from Physical Components

The next historical image shows the block identified as Gas Turbine Dynamics. A first-order transfer function can approximate one measured input-output response near an operating point, but its gain and time constant must come from a stated model or identification procedure.

For G(s) = K/(τs + 1), K defines the steady-state gain and τ describes how quickly the output approaches its new value after a step. The response reaches approximately 63.2% of its final change after one time constant. This is a mathematical property, not proof that an arbitrary value of τ matches a real turbine.

The original throttle-and-manifold subsystem belongs to a different modeling vocabulary. It may illustrate a dynamic intake process, but its parameters cannot be accepted as gas-turbine compressor data without a justified translation.

The following induction-to-power-stroke delay and engine-torque images similarly contain concepts associated with reciprocating engines. A continuous-combustion turbine does not have the same repeating intake and power strokes as a piston engine.

A Divide block computes a quotient. It is not inherently a comparator or fault detector. To detect an error, define which values are being compared, how their units match, and what decision follows. Likewise, multiplying angular speed by a conversion factor is not a physical tachogenerator model.

Build a Monitoring Model with Explicit Assumptions

Start by defining the purpose. For a classroom exercise, we might want to detect a sustained speed-sensor bias at a fixed operating point. That is much narrower than diagnosing every compressor, combustor and bearing fault. A narrow objective allows the input data and expected detector behavior to be specified clearly.

A simplified shaft equation is J dω/dt = τ_turbine − τ_compressor − τ_load − Bω. Here J is rotational inertia, torque terms are in newton-metres, B represents a chosen viscous-loss approximation and ω is in radians per second. This is a lumped model; multiple shafts require additional states and couplings.

The speed conversion is n = 60ω/(2π). Thus 314.16 rad/s corresponds to approximately 3,000 rpm. Mechanical power is P = τω, so a hypothetical 100 N·m at that speed gives about 31.4 kW. Mixing rpm directly into this power equation would introduce a large unit error.

A thermocouple may be approximated locally by a first-order sensor response, but the measured temperature also depends on location and installation. Include sensor lag separately from the process dynamics when possible. Otherwise, a delayed measurement can look like a process fault simply because the reference responds faster.

1. Choose one operating region and state the model's valid range.
2. Define all inputs, outputs, units and sample times.
3. Obtain or generate a clearly identified healthy reference dataset.
4. Check the healthy model before adding faults.
5. Introduce a known fault with a recorded start time and magnitude.
6. Evaluate both detection performance and behavior when no fault is present.

Calculate a Residual

A residual is the difference between a measurement and its expected value. For speed, r_n(k) = n_measured(k) − n_expected(k). If the expected speed is 3,000 rpm and the measured value is 3,090 rpm, the residual is +90 rpm. The sign tells us the direction of the mismatch.

Different channels need different scales. A 10-degree temperature difference and a 10-rpm speed difference are not comparable merely because both have the number 10. One approach is z(k) = r(k)/σ, where σ represents a justified healthy residual scale for that channel and operating region.

If the healthy speed residual scale is 15 rpm, a 90-rpm difference gives z = 6. This does not automatically prove a mechanical fault. Sensor bias, a wrong operating-point reference, time misalignment or an unmodeled load change can all generate a residual.

Fault detection asks whether behavior is abnormal. Fault isolation asks which component or mechanism caused it. Remaining-life estimation asks a further question about degradation over time. Do not present a single threshold comparison as if it solves all three tasks.

Add Persistence, Hysteresis and Data-Quality Checks

A threshold crossed for one sample can be caused by noise. Persistence requires an abnormal condition to remain present for a selected duration or number of samples. At a 0.1-second sample period, five successive samples span four intervals, so the first-to-last observation span is 0.4 seconds; the detection delay also depends on when the fault began relative to sampling.

Hysteresis uses a different condition for clearing the alarm than for setting it. For example, an educational detector might set after several samples above |z| = 4 and permit clearing only below |z| = 2. These are demonstration values, not turbine operating limits.

Also create a distinct invalid-data state. NaN, an impossible sensor value, a stale timestamp or a lost communication channel should not silently become healthy. An alarm based on unavailable data is different from a confirmed process deviation, and the interface should make that distinction visible.

The historical Gear Box subsystem and disturbance control illustrate where decision logic was placed in the earlier project. Their names do not establish a bearing diagnostic model or calibrated vibration severity scale.

A Small MATLAB Residual-Detection Exercise

The following source uses synthetic speed data to demonstrate persistence. It injects a sustained 90-rpm measurement bias after 20 seconds. It is intentionally a sensor-bias exercise, not a simulation of a damaged bearing or full turbine thermodynamics. The script uses ordinary MATLAB operations and does not require the original project.

rng(1);
Ts = 0.1;
t = (0:Ts:40)';
expectedRpm = 3000 * ones(size(t));
healthySigma = 15;
measuredRpm = expectedRpm + healthySigma * randn(size(t));
faultActive = t >= 20;
measuredRpm(faultActive) = measuredRpm(faultActive) + 90;

z = (measuredRpm - expectedRpm) / healthySigma;
valid = isfinite(measuredRpm) & isfinite(expectedRpm);
alarm = false(size(t));
count = 0;
latched = false;

for k = 1:numel(t)
    if ~valid(k)
        count = 0;
    elseif abs(z(k)) > 4
        count = count + 1;
    else
        count = 0;
    end
    if count >= 5
        latched = true;
    end
    alarm(k) = latched;
end

subplot(2,1,1);
plot(t,z);
ylabel('Normalized residual');
grid on;
subplot(2,1,2);
stairs(t,double(alarm));
xlabel('Time (s)'); ylabel('Latched alarm');
ylim([-0.1 1.1]); grid on;

This example latches the alarm once it is set; it does not implement automatic clearing or a complete invalid-data display. The valid array is retained so missing-data handling can be reviewed separately. No newly executed plot or detection timestamp is claimed here. Run the code to inspect how noise changes the moment at which five consecutive exceedances occur.

Change one parameter at a time. Reduce the bias, increase the noise, shorten the fault duration or add a normal load transition to the expected value. The resulting missed detections and false alarms explain the limitations of a fixed threshold much better than a single successful demonstration.

Interpret the Historical Alarm Screens

The original low-disturbance screenshot shows the project's chosen indicators under its first input setting. Treat this as a software scenario, not evidence that a physical turbine is healthy.

The next scenario increases the disturbance setting. An indicator changing state demonstrates a relationship between that input and the implemented logic. Without physical units, calibration and validation, the number 10 cannot be described as a safe vibration level.

The final scenario uses a still larger setting and activates the more severe indicator. The label Dangerous expresses the programmer's selected category. It does not prove that a real machine would fail at the value 12, nor that it could safely continue operating below it.

For actual equipment, operating and shutdown criteria come from the machine design, manufacturer guidance and the installed protection system. An educational MATLAB dashboard should not override those systems. Its purpose here is to teach how a decision is formed and how that decision must be evaluated.

Read Scope Plots with Units and Context

The first historical scope compares delayed signals. Differences in rise time can follow directly from the selected delay blocks, so a separation between traces is not automatically an abnormal combustion event.

The temperature-related scope compares a response with a reference. Record each channel's unit, scale and sensor lag before subtracting the traces. A constant reference of 1 may be a normalized target; it is not one degree Celsius unless the model explicitly defines it that way.

The following scope includes processed signals and a decision-related channel. Filtering can reduce noise, but it also delays changes. A smooth curve is not necessarily a more accurate representation of the process.

The final scope presents a simulated speed response. Its endpoint and acceleration time depend on the configured equations and parameters. They should not be reported as measured turbine performance or a universally acceptable startup profile.

Why Shaft Speed Alone Cannot Diagnose Every Fault

A governor may maintain almost constant average speed while a bearing or alignment problem develops. Conversely, a commanded load change can alter speed without indicating damage. Vibration diagnosis therefore needs appropriate measurements and features, not simply a scaled copy of the speed signal.

For sampled acceleration x(k), RMS = √[(1/N)Σx(k)²]. If the quantity of interest is vibration about a baseline, remove the appropriate mean or trend before computing the feature. State the bandwidth and window duration, because different processing choices produce different values.

Sampling must capture the frequencies of interest and include suitable anti-alias filtering. A slowly sampled supervisory speed channel cannot reveal high-frequency bearing signatures that were never acquired. Frequency features can also depend on shaft speed, so comparisons between different operating points need care.

Evaluate Detection Performance Honestly

Define whether metrics count individual samples or complete fault events. A long fault can dominate sample-based accuracy while several short faults are missed. Keep healthy and faulty runs separate when dividing data for development and evaluation; adjacent windows from the same run can otherwise leak nearly identical information into both groups.

Retain the model version, solver settings, random seed, sample time and fault-injection schedule. Repeat the experiment with several noise realizations and normal operating transitions. Report the range of outcomes instead of selecting only the plot with the cleanest separation.

MathWorks distinguishes detection and diagnosis in its condition-monitoring guidance. That distinction also helps organize your report: show the measured signals, the extracted indicators and the decision separately. For example, a high speed residual is an observation, while a proposed sensor bias is a hypothesis. To test that hypothesis, compare an independent speed measurement or another justified signal relationship. If several causes remain compatible with the evidence, report an unresolved anomaly rather than assigning a confident component diagnosis. This preserves useful information without overstating what the available sensors can tell us.

Project Files and Further Study

The historical gas-turbine project page is retained for reference. Check its current contents and compatibility information directly; this article does not confirm a current price or claim that the older model has been rebuilt to match the revised methodology.

You can add a monitoring interface using our MATLAB GUI tutorial. The articles on P-code and Simulink packaging with S-functions discuss older distribution techniques. Keep model assumptions and validation evidence available even when implementation files are packaged.

Frequently Asked Questions

Is a mu-law compressor a turbine compressor model?

No. It compresses numerical signal amplitude through a nonlinear function. Modeling an air compressor requires physical relationships or validated performance data.

Does an alarm identify the failed component?

Not necessarily. A residual indicates disagreement with expected behavior. Additional signals, fault signatures and testing are needed to isolate a cause.

Can a fixed threshold work?

It can be useful over a defined operating region, particularly with persistence and data-quality checks. Its suitability must be evaluated under healthy variation and the faults of interest.

Are the old disturbance values engineering limits?

No. Their displayed numbers are model settings without demonstrated physical calibration. They must not be used as operating or shutdown limits for real equipment.

What should I improve first?

Define the monitored fault, correct the units and establish a healthy baseline. A simple transparent detector evaluated properly is more informative than an elaborate diagram with undefined signals.