Railway Air Processing Units (APUs): Building an Explainable Condition Monitoring Dashboard with a Time-Series Database

Introduction

Predictive maintenance often brings to mind a machine learning model predicting equipment failures. But what maintenance staff really want to know is, “Why did the system reach that conclusion?” A system that provides only a score is hard to trust. It becomes useful when people can examine sensor data along a timeline and understand the result.

This article introduces a demo that loads the MetroPT-3 dataset from the UCI Machine Learning Repository into Machbase Neo and uses an interactive dashboard to explore the condition of a railway vehicle’s air processing unit (APU). The Health Score and events in this demo are rule-based indicators defined within the project, rather than outputs of a trained model. The formulas are open, so anyone can follow how each score was calculated.

Why MetroPT-3?

MetroPT-3 contains telemetry collected from a railway vehicle’s APU between February and August 2020. It has 1,516,948 timestamps and 15 original sensor channels, including pressure, temperature, current, valves, switches, and pulses—approximately 22.75 million sensor values in total. Crucially, the dataset authors provide four documented air-leak failure intervals, making it possible to see how changes in the sensors relate to actual failures. The airflow through the compressor, three-phase motor, cyclone separator filter, dryer towers, storage tanks, valves, and pneumatic panel is intuitive and well suited to visualization. The CC BY 4.0 license also permits reuse with attribution.

One limitation deserves attention. The public documentation identifies the equipment only as a railway compressor APU; its manufacturer, model, and vehicle number are unknown. The intervals actually observed in the CSV are approximately 9–10 seconds (about 0.1 Hz), which differs from the 1 Hz rate stated in the dataset description. This demo therefore uses the actual 1,516,948 timestamps instead of assuming a sampling frequency. The original time zone is not provided either, so timestamps are preserved as supplied and the interface labels them “Dataset local time · Time zone unspecified.” Acknowledging what we do not know is a starting point for explainable analysis.

What the Demo Shows

The dashboard lets you explore all approximately 1.51 million timestamps along a timeline while viewing the APU’s airflow and equipment state in 3D. Changes in the 15 sensors, documented air-leak intervals, and the rule-based Health Score and events share the same time axis. Playback lets you replay the sensor data chronologically. The interface supports English and Korean, with a 90-second guided tour.

A key design principle is to distinguish the sources of information. The documented failure intervals supplied with the dataset are displayed separately from the derived events calculated by the project. The demo makes no claim about machine learning accuracy; it clearly separates source facts from our computed interpretation.

How the Data Is Stored in Machbase Neo

The central table is IIOT_METRO_TIMELINE. It is a tag table using value JSON SUMMARIZED WITH ROLLUP, storing three kinds of JSON rows—telemetry, baseline, and event—under dataset metropt-3-uci-791 and asset apu-01. Raw telemetry, baselines, and derived events all reside within the same timeline model.

The advantage of this structure comes from rollups. Machbase Neo automatically maintains SEC, MIN, and HOUR rollup layers across the full JSON value. The API can aggregate all numeric fields with a single AVG(value) query, then extract only the sensors selected by the user. Whether there are 15 sensors or 30, separate aggregation queries are unnecessary. As the user zooms in or out, the appropriate rollup layer is selected for the display resolution, allowing fast queries over 1.51 million timestamps. JSON path indexes support frequently used filters such as row type, event type, event source, and health grade.

CSV ingestion is streamed rather than loading the whole file into memory. The download helper also only prints the required commands, avoiding loading the approximately 218 MB source file into JSH memory all at once.

An Explainable Health Score

The Health Score uses February 2020 as its baseline period. The p05, p50, and p95 quantiles are calculated from hourly features during that month. Values from the most recent one-hour rolling window are then converted into risk measures based on their deviation from this baseline distribution. The window uses actual timestamp intervals and requires at least 45 minutes of data to be valid. A gap longer than 120 seconds resets the window, so missing sensor data is not artificially filled in.

Indicators are divided into those where higher values imply greater risk and those where lower values imply greater risk. Each is normalized to a value between 0 and 1.

Higher-is-riskier = clamp((x - p95) / max(3 × (p95 - p50), ε), 0, 1)
Lower-is-riskier = clamp((p05 - x) / max(3 × (p50 - p05), ε), 0, 1)

The Health Score is a weighted combination of four risk measures:

Health Score = 100 × (1
  - 0.40 × pressure-drop risk
  - 0.25 × pressure-recovery risk
  - 0.20 × starts-per-hour risk
  - 0.15 × compressor loaded-duty-cycle risk)

Because air leakage is the main failure mode, pressure loss and delayed pressure recovery receive the largest weights. The other two terms reflect the fact that a leak causes the compressor to start more often and remain under load for longer. Oil temperature is displayed to help explain operating conditions, but it is deliberately excluded from the health formula because of seasonal variation. With February as the baseline and observations extending into August, including temperature could detect the season rather than a fault.

Events are defined by sustained conditions rather than instantaneous readings. An early warning occurs when the Health Score remains below 60 with at least two abnormal contributing factors for three consecutive hours. A critical event requires a score below 30 with at least three contributing factors for one hour. Recovery requires a score of at least 70 for three hours. These rules prevent brief spikes from triggering alarms. They are transparent, verifiable demo policies, not a trained failure-classification model.

An Evidence API That Shows How Results Were Produced

The backend consists of a small set of read-only APIs. /api/health and /api/manifest provide status and metadata, while /api/frame returns a single point at a specified time. The seek=next|prev option skips telemetry gaps to move to the next or previous available record. /api/window retrieves a time range, /api/signals returns time series for selected sensors (for example, signals=reservoirs,health_score), and /api/events provides the event list.

My favorite feature is that every data response includes supporting evidence: the executed SQL, bound values, target table, sample results, actual query time, and rollup interval used. This makes it possible to trace each number on the screen back to its query. Sensor names are restricted to an allowlist so that API inputs cannot be used as arbitrary SQL expressions. Instead of asking users to take our word that queries are fast, we include the measured query time in the response.

Try It Yourself

You need Machbase Neo 8.5.x, git, curl, sha256sum, unzip, and a browser that supports WebGL. Clone the repository from the directory containing the machbase-neo executable.

cd <MACHBASE_NEO_INSTALL_DIR>
git clone https://github.com/machbase/neo-train-apu-demo.git
cd neo-train-apu-demo

The original dataset is not redistributed in the repository, so download it yourself and verify its hash. Run the helper script to print the download commands, then execute those commands in your shell.

../machbase-neo jsh scripts/download-data.js

curl -L --fail --output 'data/raw/metropt-3/metropt-3-dataset.zip' \
  'https://archive.ics.uci.edu/static/public/791/metropt%2B3%2Bdataset.zip'

printf '%s  %s\n' \
  'aab991a970e58210de853bb8078ce0e63abb4d9412fdc5c79792dae3d8e1721a' \
  'data/raw/metropt-3/metropt-3-dataset.zip' | sha256sum --check

unzip -j -o 'data/raw/metropt-3/metropt-3-dataset.zip' \
  'MetroPT3(AirCompressor).csv' -d 'data/raw/metropt-3'

Next, create the schema, ingest the complete CSV, and start the server. If telemetry already exists, the importer refuses to overwrite it. Add --reset if you want to ingest it again.

../machbase-neo jsh scripts/ingest.js
../machbase-neo jsh app/server.js --host 127.0.0.1 --port 56802

Open http://127.0.0.1:56802 in your browser. To connect from another computer, run the server with --host 0.0.0.0 and open the port in your firewall. After ingestion, scripts/selftest.js can verify the 1,516,948 telemetry rows, the original timestamp range from 2020-02-01 00:00:00 to 2020-09-01 03:59:50, and the four documented air-leak intervals. When no data is available, the demo intentionally displays setup instructions rather than substituting synthetic data.

Conclusion

In Industrial AI, enabling people to verify and explain results matters as much as model accuracy. This demo shows how railway APU time-series data flows through rollup-based queries, rule-based health indicators, and evidence-bearing APIs to form a condition monitoring dashboard. The complete source is available on GitHub (machbase/neo-train-apu-demo), and a demonstration video is available on the showcase page. Please retain the MetroPT-3 attribution to UCI when distributing this demo or derivative materials.