Industrial Automation and Smart Manufacturing Case Studies
Industrial5 Case StudiesUpdated Sep 2026
A controller change, a drifting sensor, or a dashboard that averages away a bad hour can each look like something else. The five cases come from a casting plant, a bottling line, a snack packaging line, a robotics integrator, and a stamping shop. Each one turns on the same four kinds of evidence: the design constraints the system was built under, the operating data it produces, the quality tolerances the product must meet, and the maintenance records that show what was touched and when. Several fixes were only partial, and the open questions stay on the page.
Case Study 1
Porosity spike after a controller release on cell six
Harrow Creek Die Casting, a plant of about 140 people running eleven aluminum die casting cells that supply transmission housings to two vehicle assemblers.
The situation
Harrow Creek upgraded the supervisory software on its eleven die casting cells over a weekend. The release bundled a new recipe manager with a revised injection ramp for thin-wall housings. In the second week afterward, cell six began producing gas porosity at a rate the quality lab had not seen in months. Scrap climbed from about 2.1 percent of shots to 6.8 percent across two shifts. The HMI showed the vacuum assist pressure as a rolling average, so the operators saw a pressure that looked normal while the alarm log filled with short excursions. Production asked to keep cell six running to meet a Friday shipment while engineering looked at it.
The challenge
The release notes called the recipe change cosmetic, and nobody could say whether the injection profile or the vacuum valve response had moved. Maintenance records showed a seal replacement on the vacuum pump four weeks earlier, but the pressure transducer calibration sheet for cell six was undated. The team had to decide whether to roll back the release, stop the cell, or hold the parts already made. A rollback would touch all eleven cells, stopping cell six would cut weekly capacity by about a fifth, and holding parts meant sorting every one by hand.
Analysis
Teams grounded in Industrial Automation and Smart Manufacturing usually start by separating what the system was designed to tolerate from what it is being asked to do now. Here the design constraints were clear on paper: the vacuum assist was sized for a particular fill time, and the new ramp shortened that window by a few hundredths of a second on thin sections. That is a small change in a recipe file, but it moves the point where air is entrapped in the melt. The HMI averaged vacuum pressure over a window long enough to hide excursions lasting a fraction of a shot.
The customer specification allowed porosity only in the outer wall and capped the affected area, so a rise to several percent meant parts were failing a limit that sampling had been checking only once per hour. Maintenance records were the most useful source once someone read them carefully. The seal replacement on the vacuum pump was logged as routine, but the transducer for cell six had been recalibrated against a reference gauge that was itself past its due date. Tying those two entries together was what turned a software question into a question about the measuring chain.
Actions taken
- Freeze the recipe change on cell six and restore the prior injection ramp, keeping the new file in the release folder for comparison.
- Pull the transducer calibration history and the reference gauge certificate, then recalibrate against a traceable standard before the cell runs again and log both in the maintenance system.
- Change the HMI so vacuum pressure shows raw peak and minimum values per shot alongside the average, with an alarm on excursions rather than the smoothed value.
- Move the x-ray sample to a fixed count per shift and tie hold decisions to the sample result, so product is not shipped on a plan that lags the process.
Results
Scrap on cell six returned to its prior level within a week after the ramp was restored and the transducer was recalibrated. The recalibration shifted the pressure reading by a margin large enough to hide the excursions, which confirmed that the measuring chain had been part of the cause. Cell six shipped the customer order two days late, and the other ten cells were unaffected. The HMI change went into the next release with a review of every averaged display. The pump stays on a watch list until a teardown inspection settles whether the seal change played a part.
Questions for discussion
- Which measurements in the plant are averaged before operators see them, and who chose that window length?
- How should a lapsed calibration on a reference gauge be handled when parts made during that period have already shipped?
- What evidence would have justified stopping cell six earlier, and who should hold that authority during a customer deadline?
Case Study 2
Conflicting yield reports from one shared historian
Pell Valley Bottling, a regional plant with three filling lines that supplies sparkling water and juice concentrates to grocery distributors.
The situation
Pell Valley Bottling runs three filling lines and sends every count to a plant historian, which a reporting layer turns into daily output and yield figures. In the eighth week of the quarter, the operations review showed line two at 91 percent of planned output while the finance team's yield report put the same line at 84 percent. Both figures came from the same historian. Plant managers disagreed about which to use for a night shift staffing decision, and the argument had grown sharper because both dashboards were now being quoted during customer calls. Nobody had reconciled the two reports since the reporting layer was rebuilt, and the operations lead had asked for a single answer before the next weekly review.
The challenge
The reports could be explained by three things at once. Line two's edge gateway had dropped counts during a network switch, and the historian filled the gaps with zeros. The reporting layer converted bottle counts into cases using a table that had not been updated for a new twelve-pack format. The two reports also used different definitions of a rejected bottle, one counting fill-level rejects and the other only rejects that reached the packer. Nobody could see which definitions were in force.
Analysis
Start with where each number is born and what happens when its source goes quiet. Pell Valley's historian accepts whatever the gateways send and stores a count for every minute, so a missing interval and a true zero look identical once they are in the table. The design choice to fill gaps was made to keep trend charts continuous, not to protect the accuracy of totals. Operating data from the line controllers can settle some of this, because each controller keeps its own count and a heartbeat. Comparing the two per shift shows where the historian is inventing or losing values.
Tolerance matters here because the two reports were each within their own tolerance and still contradicted each other. The yield report allowed a reconciliation gap of half a percent against the packer count, which was reasonable for a finance close but loose for a staffing call. Maintenance records supplied the context. The edge gateway on line two had a firmware update logged in the fourth week, and a switch replacement was logged the day before the discrepancy first appeared. Read together, those records pointed to a gap window rather than a systematic bias, and that changed the fix: a completeness check at ingestion, not a correction factor applied to the totals.
- Capture Gateways flag missing minutes instead of letting the historian fill them.
- Define One dictionary sets the meaning of reject, case, and yield, with owners.
- Transform Lookups keyed on pack format fail loudly when a new format has no entry.
- Reconcile Compare historian totals with packer counts each shift and review variances.
Actions taken
- Add a completeness check at the gateway that flags any missing minute per line and blocks the shift total until the gap is explained or marked as known.
- Stop filling gaps with zeros and store a null with a reason code, so trend charts and totals can handle missing minutes differently.
- Publish one data dictionary that defines a reject, a case, and a yield, with an owner for each term and a dated change log that both reports read from.
- Replace the case conversion table with a lookup keyed on pack format code, and add a test that fails the build when a new format has no entry.
Results
Line two's gaps were confirmed as a gateway fault during the network switch, and the historian now stores explicit nulls with a reason code. The yield figure for the week was restated to 88 percent, with missing minutes removed from planned time rather than counted as zero output. The data dictionary was signed off by the operations, finance and quality leads. Night shift staffing was set on the restated figures. The reject definition is still split between the two teams, so both figures are reported until the next review.
Questions for discussion
- Which of our reports would have been wrong if the historian had kept filling gaps with zeros, and how would anyone have noticed?
- When two teams own different definitions of the same term, who should decide which one a shared dashboard uses?
- What would a useful completeness threshold look like for a line that runs on a slow network segment?
Case Study 3
Suspected controller compromise after an off-hours remote session
Corran Mill Packaging, a snack food packager with one flexible packaging line that feeds a regional distribution center.
The situation
Corran Mill Packaging runs one flexible line for snack food bags, with a PLC network, a local historian, and a remote access gateway that its controls integrator uses for support. On a weeknight outside the maintenance window, the integrator's session logged in from an address that was not on the approved list. Within the hour, the line four controller recorded a program download that nobody had scheduled, and the seal temperature setpoint on the HMI moved by a few degrees before an operator reset it by hand. The line stopped on a temperature alarm, and the shift lead called the plant's systems group.
The challenge
The plant had no confirmed compromise, only a pattern that fit a stolen credential, a misconfigured vendor account, or an internal test gone wrong. Evidence had to be preserved before anyone rebooted the controller, but the line was down and the production lead wanted it running by morning. Any action on the PLC or the gateway would change the state that investigators needed to see. The team had to decide what to isolate, what to leave running, and what to record before touching anything.
Analysis
Industrial control networks were built to keep machines running, not to make every change attributable. The packaging cell was designed with a flat layer between the PLCs and the HMIs, and a remote gateway was added later with a shared vendor account. Those constraints explain how a single credential could reach a controller, since the safety case depended on predictable timing. Operating data was the quickest source of truth. The historian held controller state every second, and it showed the download event, the setpoint change, and the session start time in the same minute. Correlating those three timestamps mattered more than any single log.
Seal temperature carries the tightest quality tolerance on this line, and the packaging standard ties it to a documented range. Even a brief excursion can produce leakers that pass a visual check and fail later on the shelf. That made the setpoint change a possible recall issue, so the quality hold had to start before the security question was settled. Maintenance records showed the vendor's last approved visit had been closed out with a backup of the controller program. The backup on file was two revisions behind the running program, so a restore would not be a neutral act.
Actions taken
- Disconnect the remote gateway from the plant network at the firewall, leave the PLC powered, and record the time and the person who made the change.
- Export the controller program, the change log, and the historian window for the three hours around the session into a sealed evidence folder with hash values recorded.
- Revoke the shared vendor account, issue named credentials with multifactor sign-in to the integrator, and check the engineering workstation for unlisted USB devices before reconnecting.
- Hold line four until the quality lead has checked seal samples from the last two hours and the controller is restored from a verified backup, with the vendor's involvement recorded in writing.
Results
The session log and historian showed one login from an unapproved address, followed by the download, which fit a stolen vendor credential better than an authorized visit. The vendor confirmed that its support engineer had not been working that night. Line four was restored after seal samples passed and a verified backup was loaded, costing about two shifts of output. The shared account was retired, and remote access now requires named credentials and a scheduled window. The workstation was clean. Forensic review of the gateway itself is still open, and the plant has not ruled out a second entry point.
Questions for discussion
- What would have to be true for the plant to restore the controller before the evidence folder was complete, and who should make that call?
- How should a plant decide between keeping a remote gateway online for vendor support and cutting it off during an open investigation?
- Which of the design constraints in this cell would need to change first to make a single credential less able to reach a controller?
Case Study 4
Choosing a telemetry architecture for growing robot fleets
Tallow Ridge Robotics Integration, a systems integrator of about 90 staff that builds robot cells and sells a telemetry service to six plants.
The situation
Tallow Ridge Robotics Integration builds palletizing and welding cells for six customer plants, and sells a telemetry service that collects cycle counts, servo currents, and fault codes from installed robots. The service runs on a single cloud region and currently ingests from 260 cells. The commercial plan calls for 1,200 cells within two years, and two customers have asked for fault alerts within a few seconds, not the minute-level rollup the platform provides now. Costs are rising with message volume, and a regional network outage last quarter left one customer's cells without telemetry for most of a shift.
The challenge
The architecture team had four options on the table: keep everything in the cloud and buffer harder, move alert logic to a gateway in each plant, run a full historian on premises at each site, or split responsibilities between a local buffer and central analytics. Each option changed the security boundary, the on-call workload, and the bill. The platform could not stay as it was, and the decision had to be defensible to customers whose plants cannot accept a remote access path they cannot audit.
Analysis
The design constraints start with the cell controller, which was never built to be a data source. Each robot controller has a finite buffer and a fixed polling priority, so any telemetry feed competes with motion and safety tasks. Fault records arrived in bursts after a cell tripped, and those bursts drove most of the ingestion cost. Median latency stayed under a minute, but the slowest one percent of fault alerts stretched to several minutes during bursts. Those tail figures, not the averages, were what customers were reacting to.
Quality tolerances for this service are set by customers, not by the engineering team. One customer's contract requires that a fault alert reach the on-call technician within a window the plant can act on, and a missed alert counts against their uptime. The maintenance records tell a more specific story. Forty-three of the cells on the outage shift had a controller firmware update logged, and the firmware changed the telemetry port behavior, so the outage was partly a compatibility issue rather than a pure network problem. Any architecture that keeps a buffer at the edge has to be tested against those firmware differences before it can be trusted with alerts.
Actions taken
- Keep the central cloud pipeline for trend analytics and fleet reporting, where a delay of several minutes is acceptable and volume is easy to scale.
- Place a small gateway at each plant that owns fault alerts, buffers telemetry during a WAN outage, and forwards queued records in order once the link returns.
- Make the gateway outbound-only, with customer-owned certificates and no inbound remote access path, so each plant's security team can audit every connection it makes.
- Run a firmware compatibility matrix against the gateway for each controller model in the field, and gate every release on a replay of the last outage's traffic.
Results
The first two customer plants moved to the gateway model in the following month, and alert delivery now completes within a few seconds during bursts. The replay test caught a port behavior change in one firmware version before it reached the field. Cloud ingestion cost fell because the gateway aggregates routine counts and sends only changes. The team did not get everything it wanted: analytics still depend on one region, and the 1,200 cell target needs a second region that has not been priced.
Questions for discussion
- Which alert types would justify the cost of an edge gateway, and which could tolerate the minute-level rollup that the cloud path already provides?
- How should a platform team weigh a regional outage against a plant's requirement for outbound-only connections?
- What evidence from firmware testing would convince you that an edge buffer is ready for alerts that carry safety weight?
Case Study 5
Vision inspection pilot for stamped bracket acceptance
Sable Point Metal Works, a stamping and finishing shop producing brackets for agricultural equipment makers across four presses.
The situation
Sable Point Metal Works stamps and finishes brackets for agricultural equipment makers. Final inspection is done by two inspectors per shift at a bench, and the plant runs about 14,000 parts per shift across four stamping presses. A vendor proposed a camera-based classifier that would accept or reject each part in under a second and free one inspector per shift for rework sorting. The vendor's demonstration figures came from a clean dataset collected under one lighting setup, using one supplier's material. The plant's own defect history includes burrs, hairline cracks, and coating runs that appear only on certain die sets.
The challenge
A classifier that misses hairline cracks on a load-bearing bracket is worse than a slower bench, and an error rate that looks acceptable overall can hide a pattern on one press or one shift. The quality team had to decide what to measure before the pilot, who would review the results, and what would stop the rollout. Maintenance records showed two of the four presses had cameras serviced more often, which mattered for any model trained on one press.
Analysis
The constraints on the proposal came from the line, not from the model. Parts pass on a conveyor at a fixed pitch, so the camera has a short window to capture both faces of each bracket. Operating data from the bench records was the most useful evidence the team had. The records were not clean, but defect codes, press numbers, and die set changes showed that certain defects clustered on particular dies. A model that performs well on average could still fail on exactly the parts that matter.
The quality tolerance for this bracket is asymmetric. A false reject costs rework and some scrap, while a false accept can reach a customer's assembly line and generate a field claim. The evaluation therefore had to weight misses more heavily than false alarms, and it had to report them separately by defect class. Maintenance records added a second layer. The cameras on presses three and four had been recalibrated more often, and the lens cleaning log showed gaps of several weeks on the other two presses. Any evaluation that pooled images across presses without accounting for that would overstate how well the model generalized.
- 1Define metricsMiss rate by defect class and die set, plus false reject rate.
- 2Blind bench comparisonInspectors decide before seeing the classifier output on each shift.
- 3Human review of rejectsEvery classifier reject reaches a person before scrap is written.
- 4Press by press rolloutAdd one press at a time, with automatic fallback to manual inspection.
- 5Weekly threshold reviewMiss rates compared against the agreed limit before any expansion.
Actions taken
- Define metrics before the pilot: miss rate on cracks and burrs by die set, false reject rate, and bench agreement on a held-out set from all four presses.
- Keep two inspectors on the bench for every shift during the pilot, with the classifier output hidden until after their call, so their agreement can be measured honestly.
- Route every classifier reject to a human before scrap, and send any accept on a flagged die set to a sampled bench check, with the sampling rate set by the miss rate.
- Roll out one press at a time, with an automatic return to manual inspection if the weekly miss rate on any defect class exceeds the agreed threshold.
Results
The pilot ran on press four first and then press one, with the threshold set in advance. The classifier agreed with bench decisions on most parts, but its miss rate on hairline cracks ran higher on one die set, so that set stayed on manual inspection. The vendor adjusted lighting and retrained on the plant's own images before the second press started. The rollout now covers three presses, and the freed inspector time goes to rework sorting rather than headcount reduction, as the quality lead requested at the outset.
Questions for discussion
- Which defect class would you want reported on its own line, even if the overall accuracy looked strong?
- When a model performs well on most parts but poorly on one die set, who should decide whether the system is still acceptable?
- What would make you trust a human inspector's call over the classifier's, and how would you record that decision for later review?
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.