A conversation with Sudhir Kumar Verma on automated health checks, trend-aware diagnostics, and why keeping the world’s most complex machines running is becoming a question of earlier warning.
Sudhir Kumar Verma works on diagnostic automation for EUV Build/Test systems, where a warning system “has to earn trust.” Photo: courtesy of the subject.
“The future of maintenance is not only faster repair. It is earlier warning.”
Every manufacturing engineer knows the weight of an unexpected stop. A machine goes down, a test run pauses, people gather around dashboards, and the organization starts counting what it has already lost. In advanced semiconductor fabrication, that weight is enormous: EUV lithography systems are among the most complex manufacturing machines ever built, with a single system costing more than two hundred million dollars, and at a leading-edge fab, unplanned downtime is widely estimated to run on the order of a million dollars or more per hour, because one stalled tool can block wafer starts across a tightly choreographed line.
Sudhir Kumar Verma, a software engineer with over 20 years of experience, works on diagnostic automation for EUV Build/Test systems. We asked him why he argues the next era of industrial reliability will be won before the failure, not after it. The conversation has been edited for length and clarity.
You argue the traditional reliability model has run out of road. What is that model, and why isn’t it enough anymore?
Verma: The traditional model is wait for a fault, inspect the logs, replace a part, restart. That worked when machines were simple enough for a fault to have one obvious cause and a short repair path. When a system is as complex as an EUV lithography tool, that model is no longer enough. The next era of reliability depends on moving from troubleshooting after failure to detecting risk before it. The economics force the issue: with a single system costing more than two hundred million dollars and downtime at a leading-edge fab widely estimated at a million dollars or more per hour, waiting for the failure is the most expensive strategy available.
The industry talks about moving from preventive to predictive maintenance. What actually changed to make that possible?
Verma: Preventive maintenance has always tried to avoid surprises by scheduling inspections and calibrations. What changed is that modern systems generate enough telemetry for maintenance to become genuinely intelligent. Instead of only asking whether the machine is broken, you ask sharper questions. Is it drifting? Is a sensor behaving differently from its historical pattern? Are the thermal responses changing? Do repeated small warnings point to a larger subsystem issue? The numbers back the direction of travel: analyst studies of predictive maintenance have repeatedly found unplanned-downtime reductions on the order of forty to sixty percent, often with twenty-four to ninety-six hours of advance warning before a failure would otherwise surface.
Your own practice offers a concrete example: pre-execution health checking. How does it work?
Verma: Before an engineer begins a complex workflow on a shared Build/Test system, the automation verifies that key prerequisites are met, and the environment is healthy enough to proceed. It sounds small, but it routinely prevents hours of lost effort. The alternative is starting a calibration or test sequence and discovering, far too late, that a basic condition was wrong from the start. On shared systems the waste compounds; one bad precondition can cost several engineers their day.
You’ve said a health-check framework is a design exercise, not a checklist. What are the design decisions?
Verma: A strong framework is not a list of yes/no checks. The engineer has to decide what machine state matters, which signals are reliable, how thresholds should be read, what to log, and when a warning should block execution versus simply inform. Each of those is a judgment about the machine and about the people using it. Get them wrong in one direction and you miss real problems; get them wrong in the other and you train everyone to ignore you.
That balance seems to be the heart of it. How do you keep a warning system from becoming background noise?
Verma: The hardest part is exactly that balance: conservative enough to catch real problems, quiet enough that engineers never start ignoring it. A warning system has to earn trust. The moment people start clicking past it, you’ve lost the whole benefit; the system is technically alerting and practically silent. So every threshold, every message, every block-versus-inform decision is really a decision about credibility. I would rather ship fewer checks that people believe than more checks that people bypass.
“The future of maintenance is not only faster repair. It is earlier warning.”
You insist generic checks aren’t enough, and that diagnostics must understand the subsystem they protect. Your example involves the tin-catch architecture in EUV machines. Explain.
Verma: Public explanations of EUV describe tin droplets as part of the laser-produced plasma process; inside the machine, the associated subsystems and their thermal behavior demand precise coordination among physical components. My background includes control and automation work around that tin-catch architecture, and it taught me why generic monitoring falls short. Thermal controls, communication signals, calibration routines, and driver interfaces each fail in different ways, and a simple pass/fail check may catch a hard failure while missing the slow ones. Trend-aware automation can detect drift, recurring instability, or a weakening margin before an obvious failure occurs. The code is valuable because it reflects real system behavior: it knows what to check, when, and how to turn raw signals into an engineering decision.
You also count validation speed as part of reliability. That’s not how most plants think about it.
Verma: It should be. Reliability is not only about maintenance after deployment; it also depends on how quickly teams can validate change. In Build/Test environments I optimized Python regression suites and achieved a documented reduction of roughly twenty percent in regression-testing time, and I put that gain in the reliability conversation because slow validation creates its own operational drag. Faster, better-maintained regression testing lets teams run meaningful checks more often, catch defects earlier, and qualify changes sooner. A plant that cannot validate quickly ends up either moving slowly or moving carelessly, and both cost money.
Why do you insist on that specific figure, roughly twenty percent, rather than a rounder, bigger number?
Verma: Because it is the number the test logs support, and in reliability work, credibility is the asset. If a regression suite was optimized, the execution logs should show it. Engineers live in evidence all day; they can smell an inflated claim instantly, and once they do, they discount everything else you say. A conservative, verifiable number does more work than an impressive one.
You’ve suggested test infrastructure and maintenance infrastructure are converging. What does that mean in practice?
Verma: As advanced manufacturing grows more software-defined, the discipline that refactors a regression suite is the same one that designs a health check worth trusting. Both are about deciding what evidence matters, generating it efficiently, and presenting it so an engineer can act. The artificial wall between “test engineering” and “maintenance engineering” is dissolving; underneath, it is one competency: turning machine behavior into justified confidence.
For reliability engineers outside semiconductors, in plants, warehouses, and utilities, what transfers from your experience?
Verma: The method, entirely. Start with the machine state that actually matters, not the signals that are merely easy to collect. Build checks that reflect how the subsystem really fails, including the slow ways. Tune for credibility, because an ignored warning system is worse than none. And treat your validation speed as an operational metric: if confirming a change takes too long, people will stop confirming changes. None of that is specific to lithography. It is specific to complex machines, and every industry has those now.
Machines are only getting more complex. Where does this end?
Verma: It doesn’t end; it escalates. The machines will keep getting more complex. The only sustainable answer is software that hears the early warnings and says so, clearly, before the line stops. That is the whole program: not heroic repairs, but systems honest enough about their own condition that the heroics become unnecessary.
ABOUT SUDHIR KUMAR VERMA
Sudhir Kumar Verma is a mission-critical software engineer whose current focus includes diagnostic automation, calibration support, health-check frameworks, regression optimization, and root-cause tooling for advanced semiconductor Build/Test environments. His broader background spans Ericsson mediation platforms, warehouse automation, satellite-broadband device management, embedded biometric terminals, and defense-grade test systems.
Email: sudhir.veerma@outlook.com | LinkedIn: linkedin.com/in/sv-b866258
