The gap between “something physical happens” and “a number appears in your database” is where most data quality problems live. If you’ve only ever worked on the database side, that gap is invisible. This post is a map of it.

We’ll trace a single temperature reading from a heat exchanger through to a cloud application, step by step. At each stage I’ll show what the data looks like, what can go wrong, and what your code should account for.

Stage 1: The physical measurement

A PT100 resistance temperature detector is embedded in a pipe. Its resistance changes with temperature, predictably but not perfectly. Every PT100 has a tolerance class. Class B (the cheaper option) has an accuracy of ±0.3°C at 0°C, widening to ±1.3°C at 300°C.

Your sensor is already an approximation.

There’s also the installation to consider. Is the sensor mounted correctly in the flow? Is there air around it that might affect the reading? Has it been in service for 10 years without recalibration? Sensor drift, where a sensor’s output gradually deviates from the true value over time, is common and often undetected.

What to remember: The physical measurement has inherent uncertainty. Your data has error bars even before it leaves the sensor. ±1°C is normal. On an alert threshold of ±0.5°C, that matters.

Stage 2: Signal transmission (4-20mA)

The PT100’s resistance is converted to a 4-20mA current signal by a transmitter. This current travels over a cable to an input card in a PLC or remote I/O.

4-20mA is a very old standard and deliberately hard to break: it’s a current loop, so resistance in the cable doesn’t affect the reading, and a broken wire is detectable (0mA means fault, not zero). But it has limitations:

• The 16mA range (4 to 20) maps to your full engineering range (say, 0-200°C). Your resolution is limited by how finely the analog-to-digital converter on the input card can divide that range.
• Cable length and electromagnetic interference can introduce noise. A variable-frequency motor drive nearby can inject enough noise to make a reading jump by several counts.
• The current-to-value conversion uses a calibrated span. If the transmitter is configured for 0-200°C but the range has changed to 0-150°C and nobody reconfigured it, every reading is scaled wrong.

What to remember: By the time the physical measurement has become a digital number in the PLC, it has already been scaled, quantised, and potentially affected by electrical noise.

Stage 3: The PLC scan cycle

The PLC reads its inputs, executes its logic, and updates its outputs, in a cycle that repeats every 10-100ms. When you request a value from the PLC, you get whatever was in memory from the last scan.

This introduces a latency of up to one scan cycle between the physical world and the PLC’s view of it. For slow processes (temperatures, pressures, levels) this is irrelevant. For fast events (a valve that opens for 20ms), you might miss it entirely.

The timestamp on a PLC value is usually the time it was read by the SCADA system, not the time the physical event occurred. These can differ by seconds depending on polling frequency.

What to remember: PLC values are samples, not a continuous stream. Events faster than the scan cycle are invisible. The timestamp is often “when we asked”, not “when it happened.”

Stage 4: SCADA / historian

The SCADA system polls the PLC and stores values in a historian, a time-series database built for industrial data. Historians use a technique called exception reporting or deadbanding: they only store a new value if the reading has changed by more than a configured threshold.

If your temperature is stable at 73.2°C, the historian might store that value once and then not again for an hour. This is efficient for storage, but it means:

• Querying the historian for “the value at 14:32:17” returns the last recorded value before that time, which might be from 14:00. If you’re not aware of this, your trend looks flat because it is flat in the database, not necessarily flat in reality.
• The threshold for “changed enough to store” is a configuration parameter. If someone set it to 5°C to save storage, you’ll never see small fluctuations.

What to remember: Historian data is not a complete record of what happened. It’s a compressed approximation. Flat lines in your data might mean “nothing changed” or “we stopped recording small changes.”

Stage 5: The cloud pipeline

The historian exports data to your cloud pipeline via an MQTT broker, OPC-UA server, or a bespoke API. Each of these adds its own considerations:

• Buffering: If the connection drops, does the local system buffer unsent data? For how long? What happens at reconnect? Does it send a burst, or drop the gap?
• Resampling: If your cloud pipeline expects data at 1-minute intervals but the historian sends on-change, you’ll need to resample. Forward-fill? Interpolate? The choice changes the data.
• Time zones: Industrial systems often use local time. Your cloud pipeline probably expects UTC. If the historian is in Norway (CET/CEST), you have a seasonal 1-hour offset to handle.

What to remember: The cloud pipeline introduces its own latency, buffering behaviour, and resampling decisions. Each one is a transformation that should be explicit in your schema and documented.

Stage 6: Your application

By the time a temperature reading reaches your application, it has been:

1. Measured with inherent uncertainty (±1°C or more)
2. Transmitted as an analog signal and converted to digital
3. Sampled at the PLC scan cycle
4. Compressed by deadbanding in the historian
5. Transmitted over a network that may buffer or drop values
6. Resampled to fit your pipeline’s cadence

The number in your database is not “the temperature at that time.” It’s the best available approximation, given all of the above.

What to do about it

Document the uncertainty. Add metadata to your schema: sensor type, accuracy class, historian deadband, poll interval. Future you, or the developer debugging an anomaly at 2am, needs this.

Be conservative with alert thresholds. If your alert fires when temperature exceeds 95°C and your sensor accuracy is ±1.5°C at that range, your alert might be lying.

Don’t interpolate silently. If you resample sparse historian data, make it visible. A value filled from a reading that’s 30 minutes old is different from a value sampled 10 seconds ago.

Validate range and rate-of-change. A PT100 measuring a pipe temperature that jumps from 70°C to 500°C in one second is probably a sensor fault, not reality. Industrial processes have physical limits. Enforce them at ingestion.

Ask the operators. The people who run the plant know which sensors are reliable and which “always read a bit high.” That knowledge is rarely in the documentation.

The sensor data you’re working with is honest about what it is, if you know how to read it. The full stack is the context. Without it, you’re optimising code on top of uncertainty you haven’t accounted for.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.

“What’s your uptime requirement?”

“99.9%.”

“That’s about 8 hours of downtime per year. We can work with that.”

“No, 99.9% per shift. We run 24/7. And if the system goes down mid-batch, we lose the entire batch.”

The IT developer nods, makes a note, and quietly recalculates.

What uptime means in IT

In web services, uptime is a statistical measure. Your load balancer distributes traffic. A rolling deployment takes down one instance at a time. If a deploy goes wrong, you roll back. The user retries their request. Maybe they see an error page for a few seconds.

99.9% uptime means roughly 8.7 hours of downtime per year. For most web applications, that’s acceptable. For the unlucky users who hit those 8.7 hours, it’s annoying but not catastrophic.

The whole model assumes the system’s state is recoverable. A failed transaction gets retried. A dropped connection reconnects. Deployments are reversible.

What uptime means in OT

In industrial control systems, “the system” is not the software. It’s the physical process the software controls.

A water treatment plant doesn’t pause while you roll back a SCADA update. A cement kiln running at 1400°C doesn’t wait for your deployment pipeline. A paper machine running at 1000 meters per minute doesn’t retry when your historian goes offline.

The physical process continues whether the software is healthy or not. And if the software loses control of the process, even briefly, the consequences are measured in:

• Batches scrapped
• Equipment damaged by running outside safe parameters
• Product out of spec that must be discarded
• In the worst cases: fires, injuries, environmental incidents

Your 8.7 hours of acceptable downtime might span three production batches. That’s not an SLA problem. That’s a business continuity problem.

The rollback problem

Web developers treat rollbacks as a safety net. Something went wrong in production? Roll back to the last good version. Worst case, you lose a few minutes of data.

In industrial systems, rollback is often not an option mid-process.

If a PLC program update goes wrong mid-batch, you can’t simply restore the previous version and continue. The physical state of the process has changed. Temperatures, pressures, chemical compositions are now different from what the previous version expected. Restoring old software to a new physical state can be more dangerous than finishing the bad deploy.

This is why industrial systems have change management processes that look bureaucratic and slow to IT eyes: planned maintenance windows, tested rollback procedures, operator sign-offs. They’re not bureaucracy for its own sake. They’re built around the reality that the software controls something that doesn’t stop.

What to do about it

If you’re writing software that talks to industrial systems, a few things are worth internalising:

Graceful degradation looks different here. In web services, graceful degradation means showing a cached page or a friendly error. In OT, it means the control system continuing to operate safely in manual mode while your software is down. Design for that hand-off explicitly.

Test against the physical constraints, not just the software ones. What happens to your system when the network drops for 30 seconds? What does the PLC do? What does the operator see? What alarms trigger?

Understand the process before you touch it. The operators who run the plant know things about failure modes that aren’t in any documentation. Talk to them before you write a line of code.

The SLA number on the contract is the easy part. Understanding what it actually means for the thing being controlled is the hard part.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.

I started out as an electrician. Then I learned to write software, and for the past few years I’ve been building IoT solutions in the energy sector. This autumn I’m starting a three-year degree in Industrial Automation alongside my day job. It covers PLCs, instrumentation, industrial networks, and OT security.

That’s a deliberate move. The bridge between IT and OT, between the cloud-connected world of developers and the physical world of industrial control systems, is somewhere I find genuinely interesting, and a place where very few people are comfortable on both sides.

This blog is where I’ll write about what I learn along the way. Expect posts on:

• The strange and useful corners where IT and OT meet
• Industrial cybersecurity from a developer’s perspective
• Hands-on experiments with PLCs, sensors, and home labs
• Lessons from building IoT at scale in energy
• Whatever else I find worth sharing as I work my way through the degree

I’ll write when I have something to say, not on a schedule. Some posts will be technical deep-dives; others will be shorter reflections. All of it will be in my own words, and the code behind the projects will be open source on my GitHub.

If any of this is interesting to you, stick around.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.