Industrial IoT Applications Case Studies
Industrial5 Case StudiesUpdated Sep 2026
Industrial connectivity work rarely fails in tidy ways. Sensors, gateways, historians and control networks each keep their own clocks, owners and tolerance for delay, so a problem that starts in one layer often appears as a symptom in another. The five cases below come from plants, distribution yards and utility sites where a missed reading can stop a line or spoil a batch. Each one asks what the system had to do, what the measurements showed, who could reach what, and whether the fix will survive the next handover.
Case Study 1
Telemetry collapse after a gateway firmware release
Harrowgate Tooling Works, a precision die maker with three stamping plants and about 2,400 connected vibration and temperature sensors.
The situation
Harrowgate pushed a firmware update to its edge gateways on a Monday evening, after a two-week test window on a single plant. Within the first shift, the central message broker began to back up. The update changed how gateways batched readings, so each device sent larger packets at fixed intervals, and all three plants hit the broker at the same moment at shift change. Press line dashboards began showing readings that were four and five minutes old. Operators could not tell whether a bearing was warming or the screen was simply lagging.
The challenge
The plant manager wanted the gateways rolled back at once. The engineering lead argued that a rollback would discard two days of buffered readings that the quality team needed for a batch investigation, and that the broker problem might also return on the older firmware under the same load. Both were partly right. Nobody had a current map of which dashboards, alarms and historian jobs depended on the broker, and the on-call rota had no one who had seen the gateway configuration.
Analysis
Start with what the line required. The press control logic tolerated stale data for no more than a few seconds before an operator had to be warned, which meant the real requirement was an end-to-end latency bound at the broker, not a throughput number on a datasheet. Teams grounded in Industrial IoT Applications usually begin by writing that bound down and measuring against it. The evidence came from three sources that had to agree: broker queue depth, gateway send timestamps, and dashboard arrival times. The send timestamps showed the batching change had doubled burst size, and arrival histograms showed the spikes lined up across plants.
Access was the second weak point. All gateways authenticated to the broker with one shared service credential, and that credential could publish to every plant topic and read the configuration store. Nobody had revoked it because rotating it meant touching every device in the field. During recovery the team split the credential by site and by role, so a gateway could publish only to its own topics and the historian job could read but not write. The same review found configuration kept in spreadsheets on two laptops, so the next change would have no record of what was running.
Actions taken
- Roll back only the batching change on the two heaviest plants and keep the credential fix in place. Export buffered readings for the quality team before any gateway restarts.
- Write the latency bound into the gateway specification as a measured acceptance test, not a design note. Each firmware candidate now has to hold the bound on a replay of a full shift-change burst.
- Build a dependency map from the broker's subscription list, then assign a named owner to each consumer. Review it at every release so that the next change shows its blast radius before it ships.
- Put configuration under reviewed version control, and give each gateway site its own credential with rotation in the maintenance calendar. Keep the runbook beside the code and test a restore once per quarter.
Results
Telemetry latency at the broker returned to under two seconds at all three plants by the end of the second shift after the change. The batching rollback on two plants was kept for the quality investigation, and the third plant ran the corrected firmware once its bursts were spread across the interval. The shared credential was retired within the week, and the configuration now has a change history that the on-call engineer can read in a few minutes. Two unclaimed dashboards gained owners, and one historian job turned out to read a topic that no longer existed.
Questions for discussion
- Which latency bound would you have written down before the release, and who should have signed off on it?
- If the broker had been sized for the old batching pattern, would the shared credential still have been the first thing to fix?
- How would you decide how long a rollback can be delayed while buffered data is still being exported?
Case Study 2
Conflicting excursion counts traced to two silent filters
Pellmore Cold Chain Logistics, a regional distributor whose reporting team is small and whose sites rarely share a standard.
The situation
Pellmore runs refrigerated storage for dairy and frozen goods across four sites. Each site reports temperature from wireless probes into a shared lake, and two weekly reports are built from that data: an operations summary that drives replenishment, and a compliance pack that goes to the customer and the auditor. In the third week of a quarter, the two reports disagreed about how many cold-room excursions had happened at the largest site. Operations showed four. Compliance showed eleven. Both teams had used the same source table and both were confident in their filters.
The challenge
The customer had already asked for a written explanation, and the auditor had a sampling plan that would pull records from whichever report looked worse. Replenishment decisions for the largest site were running on the operations figure, which meant cold stock might be left in a room that had been warm for hours. The data team had no lineage view, so nobody could say which transformation had changed the count, or whether the probes themselves had drifted.
Analysis
The requirement was never stated as a single number. Compliance needed every excursion above the contractual threshold, while replenishment needed a reading fast enough to act on within the hour. Those are different tolerances, and a shared table served neither well without explicit rules. Careful teams separate the two by writing each consumer's freshness and completeness requirement next to the transformation that feeds it. Here the trace showed the operations filter dropped readings with a missing value, removing nearly a fifth of probe records at the largest site, while compliance carried the last value forward and hid short outages.
Access controls explained part of the drift. The probe ingestion job ran under a service account that could also write to the compliance schema, so a fix in one place had quietly changed what the other report read. Separating read and write roles per schema was the first change. Maintainability was the larger problem. The transformation logic lived in two notebooks written by different analysts, with threshold values typed directly into the code. Neither had tests, and the history showed a unit conversion added and then reverted with no comment.
- 1Wireless probe readingRaw value in degrees with a device timestamp and battery level.
- 2Ingestion jobConverted probe units and stamped records with ingestion time.
- 3Shared source tableSingle table feeding both reports with no lineage tags.
- 4Operations filterDiscarded gap records, leaving a thinner sample for excursions.
- 5Compliance filterCarried last values forward, smoothing short outages out.
Actions taken
- Freeze the shared table as it stood before the quarter, then rebuild both reports from raw probe records with each transformation written as a named, versioned step.
- Trace lineage for each report field, noting which job wrote it, which filter touched it and which threshold applied. Keep that map beside the code so any figure traces back to its probe.
- Add validation checks at ingestion for gaps, unit mismatches and timestamps out of order, and make each check fail loudly rather than filter silently. Route failures to the site engineer on duty.
- Split access so the ingestion account writes only to raw tables, and each report reads from its own published view. Assign every threshold to a named owner in a configuration file under review.
Results
The compliance count settled at nine excursions after the rebuild, and the operations figure moved to match once gaps were tagged rather than dropped. Both reports now cite the same view and show the number of records missing per site beside each figure. The validation checks caught a unit mismatch on a replacement probe within the first month, before it reached either report. Replenishment for the largest site was adjusted in the week the revised figures were confirmed, and the auditor accepted the lineage map as the basis for the next sample.
Questions for discussion
- Which of the two filters would you have trusted on its own, and what evidence would have made you distrust it?
- How should a team decide which thresholds belong to compliance and which belong to operations when one source feeds both?
- What monitoring signal would have flagged the reverted unit conversion before the quarter closed?
Case Study 3
Suspicious logins at a remote pumping station
Calder Ridge Water Cooperative, a member-owned utility that operates eleven remote pumping stations and a central process historian.
The situation
A maintenance contractor's laptop was used to reach the historian from an address that had never appeared in the access logs. The login came in outside the contractor's scheduled window and succeeded on the second attempt. Over the next two hours the same account queried tag lists for three stations, including setpoint tags that operators do not normally read from the historian. A monitoring rule flagged the pattern, and the on-call analyst, Priya, saw that the account was still active. Nobody had yet decided whether the activity was a misconfigured script or a live intrusion.
The challenge
Stations are remote and some have only a satellite link, so the team could not simply pull network cables without a dispatch. Isolating the historian would cut off trend data that the district used for reporting to regulators, and the contractor's account was also used by a vendor for a scheduled calibration that afternoon. The team had to scope the activity, keep evidence intact, and contain the account without breaking the work that depended on it.
Analysis
The first requirement was keeping pumps under local control, not protecting every byte of historical data. Control logic ran on a separate segment that the historian could read but could not command, so the question was whether the session could cross that boundary. Performance evidence settled part of it. The account normally issued about a dozen queries across a working day, and this session issued several hundred across all stations in under two hours. Packet captures from the historian host showed no connections to controller addresses, and the baseline for that host had been recorded when it was last rebuilt.
The contractor account was the real finding. The account still carried read rights from a project that had closed long before, and it had no multi-factor requirement because the historian predated the policy. Nothing in the account review had flagged it, since reviews compared group membership and not the tag lists each group could reach. Maintainability was poor for the same reason: the station list, the account inventory, and the vendor schedule lived in three different documents, so nobody could answer quickly which accounts touched which stations.
- First ten minutesAnalyst confirmed the account was still active and disabled sessions.
- Within the first hourHistorian snapshot taken and access logs exported before any change.
- Second hourContractor and vendor contacted through approved channels, not email alone.
- Later that afternoonStations checked by dispatch; calibration rescheduled under a new account.
- End of the weekScoped findings reviewed, rules tightened, and the account retired.
Actions taken
- Disable the contractor account and terminate its sessions, but leave the historian running so trend data for regulators keeps flowing. Record the time of each step in the incident log as it happens.
- Preserve evidence before any cleanup: export access logs, take a full snapshot of the historian host, and hash each file. Store copies on write-protected media held by someone outside the operations team.
- Scope the activity by replaying the session against the tag list and station inventory. Confirm with the vendor by phone, using a known number, that no calibration session was open.
- Replace the shared contractor login with individual accounts that expire on a fixed date, require multi-factor sign-in, and are reviewed against tag-level permissions each quarter. Document each step in the runbook before closing.
Results
The contractor session was confirmed as an unauthorized use of a stale credential, probably reused from an old laptop, and no controller commands were sent. Historian trend data remained available throughout, so regulatory reporting did not slip. The vendor's calibration went ahead two days later under a new individual account. The access review found eleven other accounts with the same stale read rights, and all were removed before the review closed. The incident report went to the district board with the evidence chain attached.
Questions for discussion
- What evidence would have been enough to justify disabling the historian itself instead of only the account, and who should make that call?
- How would you set the threshold for the query-rate alert so that dispatch calibration work does not trigger it every month?
- Which steps in this response would you want rehearsed before a real event, and which people would need to be in the room?
Case Study 4
Edge filtering versus cloud-only ingestion for quarry telemetry
Tennick Telemetry Systems, a small firm that sells equipment tracking and fuel monitoring to quarry and construction operators.
The situation
Tennick's telemetry service receives position and machine data from about 6,300 mobile assets across quarry and construction sites. Every device sends a reading every ten seconds, and every reading goes straight to a central cloud broker, where stream jobs decide whether to raise an alert. The model worked when the fleet was smaller. Now the monthly cloud bill for ingestion and storage has grown faster than the subscription revenue, and alerts for fuel drops and hydraulic faults arrive late on sites with weak cellular coverage, when a device buffers and then floods the broker after reconnecting.
The challenge
Three options were on the table. The product lead wanted to keep the cloud-only design and add capacity. The field team wanted edge gateways that filtered and summarized readings locally. A third proposal put a regional broker close to the larger sites. Each had a different owner, and each made a different promise about alert latency, data retention, and what happens when a gateway is stolen off a truck.
Analysis
Requirements differ across message types, and that drives the design. Position data can tolerate minutes of delay and benefits from batching. Fuel theft and hydraulic faults need an alert within seconds of the event, even if the rest of the record waits. Performance evidence came from the existing broker: the ninety-fifth percentile arrival delay for alerts on well-covered sites was under four seconds, but on poorly covered sites it stretched past several minutes after each reconnect burst. That pattern pointed at the buffering behavior, not at the cloud capacity. Adding cloud capacity would have bought little, because the delay came from bursts after reconnection rather than from steady load.
Access and maintainability shaped the options as much as cost did. Edge gateways sit in trucks and yards, so each one is a device an outsider could physically take and query. Any design that stores credentials on the gateway needs per-device keys, remote revocation, and a way to wipe local buffers. The regional broker option multiplies the number of places where tenant data is held, which adds access paths to review and places where a retention rule can drift. A design the team cannot describe on one page will not survive the next change, so the evaluation counted the components each option asked the team to keep patched.
Actions taken
- Build a load model from the reconnect pattern, not the average: replay a full site's buffered burst against both candidate designs and record alert delay at the ninety-fifth percentile.
- Write a single-page data flow for each option listing every component, credential, and retention rule, then count the components the operations team would patch each quarter. Use that count as a tie-breaker, not a footnote.
- Pilot the gateway option on one quarry with the weakest coverage for a month, keeping the central broker as the system of record until alert delay and cost both meet targets.
- Require per-device keys and remote revocation as a precondition for any gateway rollout, and test a stolen-device scenario before the pilot starts. Assign one owner for each credential and retention rule.
Results
The pilot ran on one quarry for the planned month. Alert delay at poorly covered sites dropped from several minutes to under ten seconds, because gateways held the alert logic locally and sent only summaries once a link returned. Cloud ingestion costs for the pilot site fell by about a third, though the team kept the central broker as the record and did not retire it. The stolen-device test exposed a gap in buffer wiping, which was fixed before the rollout widened to the next five quarries.
Questions for discussion
- Which latency target would you have written into the requirements before the pilot, and who would have had the authority to change it?
- How would a gateway loss change the alert design if the device held the only copy of a buffered fuel reading?
- What would make you retire the central broker, and what evidence would you need before that decision is safe?
Case Study 5
Automated visual defect screening on a coating line
Gildmere Finishing Works, a job shop that applies protective coatings to structural fasteners and inspects each lot before shipment.
The situation
Gildmere coats structural fasteners in batches and inspects each lot by sampling, with two inspectors per shift looking for bare spots, runs, and blistered coating. A vendor offered a camera system that classifies every piece as it passes the end of the line. The sales material promised fewer missed defects, a smaller inspection crew, and round-the-clock coverage. The demonstration used a set of about 400 images that the vendor had chosen from its own customers' lines, and the claimed accuracy came from that set. Nobody at Gildmere had yet seen how the system behaved on their own coatings, lighting, or defect mix.
The challenge
The plant manager liked the labor savings and the audit trail. The quality lead was not willing to remove the sampling inspectors until the system had been shown to miss fewer defects than people did, on Gildmere's own product. A miss on structural fasteners could mean a field failure with a builder, so a false negative mattered far more than a false alarm. Both sides needed a way to measure the system before anyone changed a staffing plan.
Analysis
Define the requirement before the metric. For this line, the requirement was that escaped defects stay below an agreed rate for each defect class, with a tighter limit for coating that affects corrosion protection. Accuracy on a mixed sample hides that split, because most pieces are good and a classifier that calls everything acceptable scores well. Evaluation needed a labeled set drawn from Gildmere's own lines over several weeks, stratified by defect class and lighting condition, with disputed calls reviewed by the quality lead. Per-class recall, the false negative rate on the tight-limit class, and the share of pieces sent to manual recheck would decide the rollout.
Whether a model stays trustworthy after the pilot depends on who can change it. The camera system stores images and labels on a vendor-hosted service, so Gildmere had to settle who could export, retrain, and deploy, and whether a retrained model could go live without quality sign-off. The answer was role separation: supervisors could view results and override with a reason, inspectors could label but not deploy, and only the quality lead could approve a model version. Maintainability was the quieter risk. Lighting changes, new coating colors, and operator adjustments all drift the input, and the vendor's retraining schedule ignored the plant's change control, so the team asked for pinned and logged model versions.
- Measure by class Score recall per defect class against the tight-limit threshold.
- Shadow the inspectors Run the model beside inspectors and log every disagreement for review.
- Gate the release Only the quality lead approves a version after the shadow period.
- Review drift weekly Compare lighting and defect mix against the evaluation set, then retrain or hold.
Actions taken
- Hold out the labeled set and score each defect class before any model reaches the line, recording recall and false negatives separately for the tight-limit coating defects.
- Run the system in shadow mode for a full production cycle, with inspectors still making the release decision and every disagreement logged with a photo and a reason.
- Set rollout limits in writing: the system may clear a piece only above a confidence threshold, and anything below it goes to manual recheck. Sampling inspectors stay until the tight-limit class meets its target.
- Restrict access so only the quality lead approves model versions, pin each version in the line's change log, and schedule a drift review that can pause automatic clearing without a vendor call.
Results
Recall on the tight-limit coating class came in below the level that the sampling inspectors had achieved, so the team did not remove sampling. The shadow period flagged a lighting problem at one station, where a worn bulb changed the color of the coating under the camera. After the bulb was replaced and the model was retrained on the corrected images, disagreements with inspectors fell sharply. Manual recheck volume stayed high enough that the labor case was smaller than the vendor had promised, and the plant decided to redeploy one inspector rather than remove two.
Questions for discussion
- What recall figure on the tight-limit class would you have required before letting the system clear a single piece, and who should own that number?
- How would you decide how long a shadow period must run before the disagreement log is trustworthy enough to act on?
- When a vendor retrains a model on images from other customers, what evidence would you need that it still reflects your own coatings?
Learning Resources
Industrial CASE STUDIES
China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.