Electronics and Semiconductor Manufacturing Case Studies
Industrial5 Case StudiesUpdated Sep 2026
In electronics and semiconductor manufacturing, every measurement is a physical fact with a history. A board or wafer carries its process settings, tool identity, and test trail, and the cases here show what happens when one link breaks. The scenarios are fictional, but the decisions are ones practitioners face on a working floor: restoring output after a change, deciding which numbers to trust, securing connected equipment, choosing an architecture, and judging whether automated inspection is better. Design constraints, operating data, quality tolerances, and maintenance records appear in every case because on the floor they rarely work in isolation.
Case Study 1
Reflow oven drift after a recipe release
Calder Ridge Assemblies, a contract electronics manufacturer running four lines and a conformal coating cell.
The situation
Calder Ridge Assemblies builds control boards for industrial drives on its surface-mount lines. In the second week of a quarter, the thermal profile for a high-density board was revised to shorten the cycle time by a little under two minutes per panel. The change passed the process engineer's review and was released to the line on a Monday. By Wednesday afternoon, the first-pass yield on the most complex board had fallen from roughly 97 percent to 88 percent, and the rework cell began to fill with boards showing cold joints under ball grid arrays. Nothing else on the line had changed that week, or so the first shift believed.
The challenge
The oven had three zones running different conveyor speeds, and the release notes listed only the setpoint changes. Operators were logging drift against a two-degree tolerance band, but the controller's drift alarm had been widened during commissioning and nobody had revisited it. The plant manager wanted the line back at target within the shift, while quality needed proof that boards already shipped were not affected. Maintenance records showed the zone three thermocouple had been replaced in the previous month without a recorded recalibration.
Analysis
Start with the constraints the profile was designed to satisfy. The thermal window for the board's lead-free solder and the component body sizes sets a peak temperature band and a time above liquidus that cannot move freely. A cycle-time gain that looks harmless on the summary can push the top zone into a range where packages warp or paste under the largest parts does not wet fully. Read the operating data against those limits, not the setpoint table. Teams grounded in Electronics and Semiconductor Manufacturing begin by lining up controller logs, profiler captures, and inspection results on one time axis, because a shift invisible in one record often shows up clearly in another.
The maintenance log changed the picture. A thermocouple replacement with no recalibration entry means the controller had been trusting a sensor whose offset was unknown, and the drift alarm had been set against an older baseline. Quality tolerances for this board were written as peak temperature plus or minus a few degrees, yet nobody had tied those limits to the sensor's calibration state. A useful test is to run a profiler across all three zones and compare its readings with the controller values. Where the gap is larger than the tolerance band, the fault lies in measurement rather than the recipe, and the recipe change may be innocent.
Actions taken
- Hold the release and revert the profile to the prior revision while the line runs a profiler pass on all three zones. Keep the change record attached so the rollback is traceable.
- Recalibrate the zone three thermocouple against a reference sensor and log the offset in the maintenance system. Re-baseline the drift alarm so it reflects the corrected reading rather than the old one.
- Pull every panel built during the affected window and sort by serial range. Run the inspection and X-ray sample plan on suspect boards, and hold any lot that falls outside the joint acceptance criteria.
- Add a prevention rule that any thermal recipe change requires a sensor status check and a three-panel trial with profiler data before release.
Results
The line returned to its previous yield within the shift after the profile was reverted. Recalibration showed the zone three sensor reading about four degrees high, which explained why the controller had run the top zone cooler than intended after the cycle-time change. Of the boards built in the window, a few showed marginal joints and were reworked, and lot disposition found no field escapes in the shipped sample. The revised release rule was applied to the next two recipe changes, and both caught a sensor issue before reaching the line.
Questions for discussion
- Which maintenance entries should block a recipe release automatically, and which should only generate a warning?
- How would the team have separated a sensor fault from a real thermal problem if the profiler had been unavailable?
- What evidence would be enough to tell a customer that shipped boards are unaffected, and who should sign that statement?
Case Study 2
Conflicting yield reports across three test stations
Ardent Lattice Test Services, an outsourced test house running wafer sort and final test for four device customers.
The situation
Ardent Lattice Test Services handles about 2,400 lots each month across six probers and eleven final test cells. In the third week of the month, one customer's quality team reported a yield figure for a lot that differed by nearly four points from the number the test house had posted. Internally, three separate yield numbers circulated: wafer sort yield from the prober logs, final test yield from the tester database, and a combined figure in the reporting warehouse. Each had a different owner, and each was correct for the process that produced it, which made the disagreement harder to settle.
The challenge
The reporting layer pulled from all three sources through a nightly load, and the load had been changed twice in the previous quarter without a shared change log. A bin code had been renamed at one station, a retest flag was no longer carried into the warehouse, and wafer map records from one prober were missing die position fields after a firmware update. Customers were now asking which figure to trust, and the commercial team needed an answer before the next shipment review.
Analysis
Yield in this business is a ratio of counts taken at different points, and each count depends on how bins were defined at the time of test. The design constraints in the test program, including the bin code map and the retest rules, decide whether two yields can legitimately be compared. Start by writing down the lineage: which prober or tester produced the raw record, which transform touched it, and where the reporting table takes its final counts. Experienced reconcilers often find the disagreement is not an error in one place but a difference in definition hidden behind a shared column name.
Operating data should be checked against tolerances the business already accepts. A gap of a couple of points between wafer sort and final test can be normal when package fallout is expected, but it becomes suspicious when one station shows a narrower gap than the others. Maintenance records matter here too: a firmware update on one prober, logged as routine, may have changed the wafer map format or dropped the die position field. Validation should compare row counts, bin totals, and map completeness at each transform against a tolerance set in advance, so the reconciliation works as a test and not as an argument.
- Trace lineage Map each field from prober output to the reporting table.
- Validate transforms Compare counts, bin totals, and map completeness against contract tolerances.
- Monitor gaps Alert when station yield gaps leave the agreed band.
- Review definitions Revisit bin codes and retest rules after each program change.
Actions taken
- Freeze the figures for affected lots and publish a note stating each yield's definition, source station, and transform stage. Stop the customer dashboard from showing one blended number until reconciliation is complete.
- Rebuild the lineage map from raw prober output through the nightly load, marking each field that is renamed, recoded, or dropped. Include wafer map and retest flags, which were lost in one stage.
- Add row-count, bin-total, and map-completeness checks at every transform, each with a tolerance written into the data contract before the next reconciliation run.
- Set alerts on yield gaps between stations that fall outside the agreed band, and route them to the test engineering and data owners together. Review the alert thresholds after every firmware or program change.
Results
Reconciliation showed the three numbers measured different things. Wafer sort counted first-pass good die, final test counted units after retest, and the customer's figure excluded lots reclassified during a bin code change. Once the definitions were aligned and the dropped die position field was restored for the affected prober, the remaining gap fell to a value the team could explain. The reporting layer now carries a definition tag on every yield figure, and the new monitoring rules caught a smaller mismatch in the following month's loads before anyone outside the plant saw it.
Questions for discussion
- Where in your own reporting chain does a shared column name hide a difference in definition?
- How would you set a tolerance for station-to-station yield gaps before any data had been reconciled?
- Which transform step would you check first if a row count matched but a field had shifted meaning?
Case Study 3
Suspicious remote sessions on a sinter press
Vantor Power Modules, a power semiconductor module plant whose tool network has grown in stages over the years.
The situation
The plant runs diode, sinter, and test lines on one shared network, with about 60 engineering and operator workstations sharing a segment with fourteen process controllers. Over three consecutive nights, the security monitoring service flagged outbound sessions from a sinter press controller's engineering interface to an address outside the vendor's published range. The sessions were short, timed for hours when no shift was running, and authenticated with a remote-access account last used for a vendor visit. The controller was in the middle of a lot. Nobody on the floor had noticed anything unusual, and the alarm first reached the plant security lead through a routine log review.
The challenge
Controllers on this segment run an operating system that cannot be patched in production without requalifying the recipe set, so any containment step has to be weighed against a lot in progress. The plant also has a contractual notification window with its largest customer, and the notice must describe what was accessed and whether parameters could have changed. The response had to be authorized and documented so an audit could follow each decision. Nobody knew whether the sessions had only read data or had written anything to the controller.
Analysis
Security response in this environment is limited by the process itself. A sinter press cannot be rebooted for a scan without losing the lot, and a controller image cannot be replaced without requalifying the recipes that depend on it. Operating data such as recipe checksums, controller logs, and flow records has to be preserved before anyone changes state, since a reboot erases the volatile evidence first. Responders who have worked on process lines write these constraints down before choosing containment steps, because the constraints decide which steps are possible at all on a given shift.
Quality tolerances add a second constraint. If recipe parameters may have been altered, the question is not only whether data left the plant but whether pressure, temperature, or force settings still sit inside validated windows. Compare the current parameter set with the last released version and with in-process measurements from the affected lots. Maintenance records help explain the exposure: a remote-access tool installed for a vendor visit and never removed, or a controller patch deferred for requalification, shows how the access happened and which fixes belong in a change request rather than an emergency action.
Actions taken
- Isolate the remote-access account and revoke its tokens through the identity system, with the change approved by the plant security lead and the on-call quality engineer.
- Capture controller and workstation logs, flow records, and configuration snapshots under the evidence procedure, and record hash values and custody transfers before any reboot or patch.
- Place the sinter segment on a restricted network path that blocks outbound traffic, and hold new lots until the parameter set is verified against the released version.
- Notify the customer quality contact within the contractual window using the approved template, and file the change requests for controller patching and remote-access removal.
Results
The investigation found that a contractor laptop holding a stale remote-access token had been used for the sessions. Recipe files showed no unauthorized writes, and the parameter comparison matched the released set. Two lots built during the suspicious nights were held and checked, and both met their validated windows. The customer received a complete log summary within the notification window, and the controller patch was scheduled as a requalified change rather than an emergency fix. Remote access now requires named accounts with expiry dates, and the segment has a documented break-glass procedure.
Questions for discussion
- What minimum evidence should a response lead collect before deciding that remote access must be removed rather than restricted?
- How should a plant balance a contractual notification window against the need to finish verifying the facts?
- Which controller changes would require requalification, and how would you separate those from pure security updates?
Case Study 4
Choosing a process data platform for a growing fab
Linden Crest Wafer Works, a mid-size analog fab with three process lines and a growing set of inline metrology tools.
The situation
Linden Crest Wafer Works has outgrown the on-premise historian that holds its process data, which was sized for a much smaller tag count. The plant now collects about 38,000 sensor tags at varying sample rates across three analog process lines. Engineers pulling a lot-level trend across several months wait many minutes for results, and statistical process control views lag far enough behind real time that operators have stopped using them during shift changes. The budget for the next phase is fixed, the security team wants data kept under plant control, and the tool vendors want remote access for service.
The challenge
The team had to choose among options that differed in cost pattern, latency, and the place where alarms were evaluated. Expanding the current historian was the cheapest in license terms but did little for query speed. A cloud streaming warehouse solved queries well but moved data outside plant control and added recurring egress charges. Any design also had to keep SPC alarms running through a network outage, and the choice would be judged by the people who would run it for years, not by the initial demo.
Analysis
Options should be compared against the workload, not against vendor brochures. Here the workload splits into two patterns: continuous tag writes at high frequency, and occasional wide queries that touch months of lots at once. A store tuned for writes handles the first pattern well and struggles with ad hoc joins across lots, and the reverse holds for analytical stores. Operating data such as tag count, sample rate, and the shape of the query log should drive the sizing. Engineers who have run these systems often build a small benchmark from real query logs before arguing about products.
Quality tolerances and maintenance records set the requirements that cannot be traded away. SPC alarms must reach the line inside a window that protects product, so any design that depends on a remote service for alarm evaluation needs a local fallback. Maintenance records show which tools have unreliable network links and how often historian outages blocked capture, which matters more to the reliability score than average uptime. A design that is cheap on paper but drops samples during a network event may fail traceability even when its dashboards are fast.
Actions taken
- Build a benchmark from twelve weeks of real query logs and sensor sample rates, and run it against two candidate stores on identical hardware or service tiers.
- Place alarm evaluation at the edge so SPC limits and interlock signals continue during a network outage, and define the buffer size from the longest outage in the maintenance records.
- Tier the data so high-frequency tags stay in the local store for thirty days, while lot-level summaries and metrology results move to a governed regional store with role-based access.
- Write the cost model with egress, storage growth, and support hours shown separately, and agree a review point where the choice is revisited if tag count passes the planned ceiling.
Results
The benchmark showed that the cloud option met query targets but its recurring egress charges exceeded the hybrid design in the modeled load. The hybrid design brought typical lot-level trends from many minutes down to seconds, and alarm evaluation at the edge kept running through two network interruptions in the first stage of operation. Storage growth came in below projection because high-frequency tags were downsampled after the local window. The team accepted more integration effort in exchange for governed retention and a clear support boundary between plant engineering and IT. The review point remains in the design document.
Questions for discussion
- Which workload measurement would change your ranking of the five options most quickly?
- How should the cost model treat data egress and support time that usually sit in different budgets?
- At what tag count or outage length would you reopen the architecture decision, and who should own that trigger?
Case Study 5
Automated optical inspection with a learned classifier
Marrow Bend Electronics, a contract assembler with a long record of automotive work and an optical inspection station on every line.
The situation
Marrow Bend Electronics builds sensor control boards for automotive customers on three surface-mount lines. Its optical inspection stations have relied on rule-based scoring for years, which produces a high volume of false calls on fine-pitch parts. A vendor offered a learned classifier that claimed to cut the number of boards sent to manual review by more than half. The pilot ran for three weeks on one line. Early numbers looked good on the summary screen, but a closer look showed the classifier flagging solder bridging on the fine-pitch connector well, while missing some tombstoned passives on the newest board revision.
The challenge
The plant needed a decision it could defend to customers: whether to expand the classifier, keep the rules, or run both for a period. The vendor's benchmark used a different camera setup and a balanced sample, so its accuracy figure did not transfer. Inspectors reported that the review queue was not shorter because the classifier's uncertain calls were routed back to them. Any change also had to respect the existing escape commitments with the automotive customer, and no one wanted errors concentrated on the boards that matter most.
Analysis
The evaluation has to begin with the constraints the inspection was designed for. Automotive sensor boards carry defect tolerances tied to customer requirements, and the AOI decision is only one layer in a chain that also includes in-circuit test and X-ray sampling. Operating data should be split by defect class, board revision, camera station, and supplier lot before any average is quoted, because an overall accuracy figure can hide a single class that matters more than the rest. Experienced evaluators set the metric set before the pilot starts, not after the results look encouraging.
Quality tolerances translate into two error costs that pull against each other. An escape reaches the customer, while overkill sends good boards into a human review queue and slows the line. Maintenance records matter because lenses, lighting modules, and fixture alignment drift over time, and a model trained on images from one calibration state may misread another. The rollout should log lighting and calibration events alongside each classifier output, so that a rise in escapes can be traced to a station event rather than blamed on the model without evidence.
- 1Shadow runClassifier scores each board silently while inspectors decide as usual.
- 2Compare by classMeasure escape and overkill rates per defect class, board revision, and station.
- 3Limited live useClassifier flags only; every pass decision still gets a second human look.
- 4Gated expansionWiden scope only when each class and station meets its agreed thresholds.
- 5Drift watchPause automatic action if calibration or lighting events change the score pattern.
Actions taken
- Define the metric set before the pilot: escape rate, overkill rate, per-class recall for the highest-risk defects, and review queue time. Write acceptance thresholds into the test plan under the quality lead's sign-off.
- Stratify the pilot sample by board revision, camera station, and supplier lot so that weak performance in any single group is visible rather than averaged away.
- Log lens cleaning, lighting replacement, and fixture alignment events against each inspection record, and require a recalibration check before the classifier resumes after any hardware change.
- Keep a named inspector on every shift with authority to override the classifier and stop the line, and record each override with its reason code for later review.
Results
The team did not adopt the classifier as a replacement. Stratified results showed strong performance on the connector and resistor families but weak recall on the smallest passives of the new revision, the same group where the camera station had recently been realigned. Once the calibration check was added, the weak group improved, but overkill stayed high enough that the net review time saving was modest. The line now runs the classifier in shadow mode with per-class reporting, and it may only flag in a restricted set of families. Override reason codes now feed the training plan.
Questions for discussion
- What error rate in a single defect class should stop a rollout even if the overall average looks acceptable?
- How would you assign review responsibility when the classifier and the inspector disagree on a board?
- Which hardware events should pause automatic action, and how would you confirm the pause has been lifted correctly?
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.