The software that runs a semiconductor machine does four jobs at once, inside one long-lived C++ application: it sequences the machine, moves things precisely, inspects and measures what it sees through cameras, and reports to the factory's central computer over an industry standard called SECS/GEM. It usually runs on Windows and is built in Visual Studio. Because changing it means re-proving the machine it controls, it gets extended rather than replaced — so the codebase routinely outlives the tooling generations, and often the people, that made it.
The person who understood the code is gone
An all too familiar scene: Someone new takes over a legacy sensor-testing system, but the handover from the previous engineer was already over.
Roger Swann’s experience as a director for an electronics and manufacturing company made such an impression we published a case study about it earlier this month.
But we’re not stopping there. We’re expanding the discussion to discuss what stayed with us afterward. It wasn’t the spaghetti code. It was how ordinary the situation is in industrial and manufacturing software, and how rarely anyone writes about it.
Semiconductor equipment gets covered as a hardware achievement: nanometer precision, EUV light sources, the most complex machines humans build. The software is arguably just as fascinating but it gets almost no coverage at all, and it’s some of the most demanding C++ in the industry.
In fabrication, up-time and repeatability are the most important metrics. Those don’t stop at the machine. They need to be embedded and reconciled straight into the code, and they’re the reason it lasts long enough to outlive the people who wrote it.
In this blog, we walk the four jobs one tool’s software has to do at once.
Sequencing the machine
This is the part that decides what action happens next, and will refuse to let it happen when a condition isn’t met. Other terms used are recipe execution, state machines, interlocks, alarm handling, and the flow of wafers or substrates through the tool. Here’s what companies usually look for in job postings and vendor docs for this type of work.
EFEM — Equipment Front End Module. The enclosed front section of a process tool where wafers are moved between carriers and the process chamber, typically by a robot arm. It’s the handoff point between the factory’s material handling and the tool’s own.
Moving things precisely
These deal with the realm of coordinated axes, stages, robot arms, wafer handling. The timing requirements are strict enough such that they constrain the whole technology choice.
You can usually see this in what the motion-control vendors ship. Most machines of this kind are driven by a motion controller that runs on an ordinary Windows PC rather than a sealed industrial box, and the vendors of those controllers hand you a C++ interface to program them with (e.g. Robotic Systems Integration’s RMP, a PC-based EtherCAT motion controller). The setup of real-time, PC-based and C++ interface shapes the engineering problem. Any delay or stutter at the wrong moment means a likely collision.
Seeing
This pertains to the more active inspection, metrology, and alignment. Cameras watch the process and the software decides whether what it sees is acceptable.
One of the larger machine vision software companies, MVTec, describes this work as one that runs the length of the entire production chain, “from wafer processing and lithography to packaging and final test,” because small defects and small misalignments both cost yield.
AOI — Automated Optical Inspection. Using cameras and image processing to find defects or check that something is in the right place, instead of having a person look at it. The term comes up constantly in this sector, usually shortened to AOI.
Almost no company creates this program from scratch. Teams buy a commercial machine vision library and build their inspection software around it. The two that dominate the market, HALCON and VisionPro, are both written in C++ and both offer C++ as a first-class way to drive them. Take note of that: when the library used by your inspection system is a C++ library, the application wrapped around it usually ends up being a C++ application too.
Talking to the factory
Every tool on a fab floor has to report to the factory host in a standard way, and that standard is SECS/GEM.
SECS/GEM — the agreed way a production machine and the factory’s central computer talk to each other, published by SEMI, the industry’s standards body. The standards cover three things: how a compliant machine is expected to behave, what the messages look like, and how they get carried between the two. Two carrying methods are specified, a network connection and an older serial cable.
For anyone who needs the specific documents: E30 defines the behavior model, E5 the message format, E37 the network transport, and E4 the serial one.
SEMI’s own introduction describes it as the layer that lets machines from completely different manufacturers all report to the same factory computer, whatever each one happens to do. The older of the two carrying methods is a serial cable, the same nine-pin connector that disappeared from consumer PCs two decades ago. It’s still in the standard.
Two transports, one standard. The RS-232 path is still specified.
| Part of the application | What it does | What it’s usually built with | Why it’s hard |
|---|---|---|---|
| Sequencing | Recipe execution, state machines, interlocks, alarms | C++ application code | Mistakes have physical consequences, and every machine option adds more states |
| Motion | Coordinated axes, stages, wafer handling robots | C++ interfaces supplied by motion-controller vendors | Strict timing; a late instruction can mean a collision |
| Vision | Optical inspection, measurement, wafer and die alignment | Commercial machine vision libraries, C++ at the core | Image processing at production speed, tied to specific cameras |
| Factory communication | Reporting to, and taking instructions from, the factory computer | C++ implementations of the SEMI messaging standards | Staying compliant across decades of factory software |
Four separate engineering problems, maintained as one application.
Why C++ on Windows in Visual Studio
A few reasons converge on why C++ on Windows remains one of the most prevalent setups.
The timing requirements rule out anything that might pause at an inconvenient moment. The software also needs to reach the hardware directly, talking to camera cards, motion cards and digital inputs and outputs without much standing in the way. The vision and motion libraries are C++ libraries, as we saw above, so the application tends to follow them. And twenty-plus years of accumulated support for specific devices exists in exactly one place, which is the codebase you already have.
Windows in particular is a deliberate choice rather than a compromise. Hardware vendors write their drivers for it, and the screen the machine operator actually uses is a Windows desktop application, sitting next to a machine worth more than the building it’s in.
Why these codebases get old, and stay
The most public example is ASML, mostly because they talk about it. The company describes its embedded software as steering and controlling its machines and consisting of “millions of lines of code,” maintained by “over 4,000 software engineers.” Their careers material puts the codebase under continuous development for the last thirty years, written in C, C++, Python, Java and MATLAB.
Thirty years is four or five generations of development tooling. The code has outlasted all of them.
Some of what sits underneath is older still. Microsoft continues to support MFC, but it receives no new features, only security updates, and it remains in active service in industrial control software. For a lot of equipment applications, the UI layer was laid down before anyone currently on the team arrived.
In fact, it’s the exact same reason financial institutions and banks are slower to adapt newer technologies. Have you ever noticed how startups and smaller firms were able to first introduce instant bank transfers and interoperable QR codes? It’s because like embedded software, these financial systems rely on decade old systems that will require significant refactoring, on top of the already heavy maintenance required just to keep them running.
The obvious question is why nobody rewrites it, and the answer is more disciplined than “nobody got around to it.” A tool in the field runs a qualified, validated software image. Changing that image means re-proving the machine behaves as certified. The cost of that requalification, not only the cost of the rewrite, is what influences businesses to push on with status quo.
Put simply: touching the software means re-proving the machine, so the bar for touching it sits much higher than in most software. Extending code you already trust is usually the rational choice, and it’s why these codebases grow rather than get replaced.
The tooling turns over. The codebase doesn’t.
What that means for the people who work in it
There are three consequences. Roger’s handover story is a great example but it happens more frequently than we’d like to admit. He had to update the software but he had to visit the factory floor to make changes—not the most efficient setup, right?
You mostly can’t run the thing at your desk. The machine is in a factory somewhere, or on a customer’s floor, and the hardware you’d need to reproduce a problem is expensive and booked. Simulators close part of that gap, though never the whole of it.
The know-how and only reference ends up living inside the code, because the people who could have mentored you have moved on. Roger’s case was unusually stark, but the shape of it is not rare: the original author unreachable, but the system had to change to adapt.
Research on developer onboarding puts ramp-up in months rather than weeks. DX’s research on ramp-up time reports managers citing three to nine months for a new engineer to reach full productivity, compressing to eight to twelve weeks where onboarding is deliberately structured. Where the code actually gets written
Semiconductor manufacturing usually gets described as a pipeline: design, fab, assembly, test. That framing leaves out the software layer all of it rests on. Somebody is sitting in an IDE writing the C++ that makes each of those steps happen. The software isn’t created arranged around the process It’s the process itself, expressed in code.
Sector coverage almost never shows that person, so it’s easy to forget where they actually sit. It isn’t the cleanroom or the fab floor. It’s a Visual Studio solution on an ordinary Windows machine, frequently in a different country from the tool the code will run on.
And their day is mostly not writing new algorithms. It’s reading existing code. Tracing a behavior back to whatever causes it. Changing one thing without disturbing twenty others. Then convincing themselves the change is safe before it reaches a machine that costs more than the building.
That last part is where this environment diverges from most software. Normally the editor is where you type and the runtime is where you learn, because you run the thing, watch it misbehave, and understand it better. When the runtime is a wafer handler you can’t access, more of the understanding has to come from the development environment itself, through symbol resolution, references and call hierarchy. You read your way to the answer instead of running your way there.
So these codebases put unusual weight on the IDE, at exactly the size and age where IDE tooling is tested hardest.
The machine’s requirements travelled into the code. They travel one step further, into what the people maintaining that code need from their tools.
The part we work on
This last part is our end of it. We make Visual Assist, a C++ productivity extension for Visual Studio, and it exists for the problem described above: reading and navigating code that’s too large, too old, or too incomplete for the default tooling to stay useful on.
How that plays out day to day in equipment software is its own subject, and we’ve written it up separately: how to work in a legacy equipment control codebase when you can’t run the machine.
FAQ
What makes equipment control codebases different from other large C++ codebases? Three things. The code is coupled to hardware you usually can’t run at your desk, which removes the debugger as the primary tool of understanding. Changing it can require requalifying the machine, so the cost of a change extends well past the code. And the expected lifespan is measured in decades, so the codebase accumulates far more history than most software. The language is typically C++ on Windows, built in Visual Studio or other similar IDEs.
What is SECS/GEM? The agreed way a production machine and the factory’s central computer exchange messages, published by SEMI, the semiconductor industry’s standards body. It covers how a compliant machine should behave, what the messages look like, and how they travel between the two, either over a network connection or over an older serial cable. The relevant documents are SEMI E30, E5, E37 and E4.
Why does semiconductor equipment still run on Windows and MFC? Hardware vendors write their drivers for Windows, the screen the operator uses is a Windows application, and the commercial vision and motion libraries are built for it. MFC persists because Microsoft still supports it, and because replacing the interface layer inside an approved software image means putting the machine through approval again, a cost that rarely justifies itself.
How big are equipment control codebases? It varies enormously by tool. The clearest public reference point is ASML, which describes millions of lines of code maintained by over 4,000 software engineers across roughly thirty years of continuous development. Most tools are considerably smaller, but they present the same category of problem at a different scale.
Where does software development fit in semiconductor manufacturing? Underneath all of it. Every process step (deposition, etch, inspection, test, material handling) is executed by a tool running control software someone wrote and someone else now maintains. The developers are generally not on the fab floor; they work in an IDE on ordinary Windows machines, often far from the equipment their code runs on.