Lithography Software Testing: RTOS, Simics, and Fault Injection

Lithography Software Testing: RTOS, Simics, and Fault Injection

🔍 Why Intentionally Introduce Faults During Lithography Software Testing?

#

Suppose a lithography machine receives an over-temperature signal while performing an exposure operation. Can its control software detect the abnormal condition in time? Will the system activate the appropriate protection mechanism? Can it prevent the equipment from continuing an operation that is no longer safe?

These are not questions that engineers should leave unanswered until the machine reaches a production line.

One way to verify the behavior is to simulate the over-temperature signal and feed it into the control software. The software processes the signal as it would during actual equipment operation, allowing engineers to observe whether the expected fault-detection and protection procedures are executed.

The timing of the injected signal can also be controlled. Engineers can trigger the same abnormal condition during initialization, measurement, exposure preparation, or another operating state to determine whether the software responds correctly in each situation.

This is the practical value of fault injection in semiconductor equipment development: it turns difficult-to-reproduce operating conditions into controlled test cases.

The need for this type of verification is growing alongside semiconductor manufacturing investment.

According to the Semiconductor Industry Association (SIA), global semiconductor sales reached $517.7 billion in the third quarter of 2026, up 24.1% from the second quarter. On the manufacturing equipment side, SEMI reported that global semiconductor equipment billings reached $40.53 billion in the second quarter of 2026, an increase of 23% year over year. SEMI attributed the continuing investment momentum partly to demand for advanced manufacturing capacity supporting AI infrastructure.

As semiconductor manufacturing equipment becomes more complex, software verification must cover more than normal operating procedures. Engineers also need to establish that control tasks meet their timing requirements, that distributed subsystems work together correctly, and that abnormal conditions produce the expected responses.

Wind River Helix RTOS and Intel Simics address different parts of this problem. The RTOS provides a predictable execution environment for time-sensitive control software, while Simics allows engineers to test software and hardware interactions in a virtual environment before the physical equipment is available.

⚙️ Why Do Lithography Machines Need a Real-Time Operating System?

#

Synchronizing the Mask Stage and Wafer Stage

#

A lithography machine must maintain extremely precise motion during scan exposure.

The mask stage and wafer stage move synchronously in opposite directions while the exposure system transfers the pattern onto the wafer. Their relative positions and velocities must remain within the required control tolerances throughout the scanning process.

This involves a continuous control loop.

During each control cycle, the software must:

1. Read the latest position feedback from the motion-control system.
2. Compare the measured position with the expected position.
3. Calculate the corresponding control deviation.
4. Update the drive commands.
5. Execute the next control cycle within its assigned time budget.

The same process repeats throughout the exposure operation.

The challenge is not simply performing the calculations quickly. They must be performed at predictable intervals.

A control task that occasionally executes late can introduce timing jitter into the motion-control loop. Variations in task response time can affect how accurately the two stages maintain their intended synchronization.

For equipment with stringent positioning requirements, timing behavior is part of the control-system design, not just an operating-system implementation detail.

The Role of Wind River Helix RTOS

#

Wind River Helix RTOS provides a real-time execution environment for critical equipment-control tasks.

Its priority-based preemptive scheduling allows higher-priority tasks to obtain processor resources ahead of lower-priority tasks. When critical motion-control operations must execute alongside other system activities, this scheduling model helps the development team control task execution order and response latency.

For example, an engineering team can assign appropriate priorities to critical control tasks and establish their expected execution periods.

The resulting software architecture can then be evaluated against the timing requirements of the equipment.

This provides a predictable foundation for implementing:

• Periodic motion-control tasks.
• Position-feedback processing.
• Drive-command updates.
• Time-sensitive equipment-state transitions.
• Other critical control operations.

An RTOS does not automatically guarantee that every application deadline will be met. Task execution time, interrupt latency, synchronization mechanisms, processor loading, and priority configuration still need to be engineered and measured.

The benefit is that the operating system provides scheduling mechanisms that allow developers to build and verify the required timing behavior.

From Individual Real-Time Control to Full-System Coordination

#

Real-time scheduling addresses the execution requirements of individual control nodes.

However, a lithography machine is a distributed system containing multiple controllers, sensors, actuators, and other subsystems.

During full-machine integration, engineers must verify more than whether an individual controller executes its tasks on time.

They also need to establish whether:

• Commands from the main controller reach the intended control nodes.
• Each node processes commands according to the expected sequence.
• Sensor feedback is returned correctly.
• The main controller receives the required status information.
• System-level state transitions occur only after the necessary conditions are satisfied.

This introduces a second verification problem: coordinating the complete equipment-control workflow.

Testing this interaction on physical equipment can be difficult, particularly when the hardware is still under development or when a specific fault condition is difficult to reproduce.

Wind River addresses this part of the development process through virtual system simulation with Simics.

🖥️ How Simics Enables Virtual Testing of Lithography Machine Software

#

Reproducing the Control System in a Virtual Environment

#

Intel Simics is a full-system simulator that allows developers to execute software against modeled hardware platforms.

Instead of waiting for every physical controller and peripheral to become available, engineers can construct a virtual representation of the target system and use it to validate software behavior.

In the lithography equipment development scenario described here, Simics is used to reproduce the control rack and its internal network according to the hardware configuration of the production equipment.

The virtual environment also connects to a model of the alignment sensor.

This allows engineers to test interactions among the main control software, real-time control nodes, and sensor interfaces without relying entirely on a physical machine.

A typical virtual test environment contains the following elements:

+--------------------------------------+
|       Lithography Control Software   |
|             Linux Host               |
+--------------------------------------+
                  |
                  |
+--------------------------------------+
|         Main Control Workflow        |
|                                      |
|  Measurement / Alignment / Exposure  |
+--------------------------------------+
                  |
                  |
+--------------------------------------+
|           Virtual Network            |
+--------------------------------------+
                  |
                  |
+--------------------------------------+
|        Virtual Real-Time Rack        |
|                                      |
|          Wind River Helix RTOS       |
|                                      |
|       Critical Control Applications  |
+--------------------------------------+
                  |
                  |
+--------------------------------------+
|          Virtual Device Models       |
|                                      |
|       Alignment Sensor Interface     |
|          Other Hardware I/O          |
+--------------------------------------+

Engineers can start the Linux main-control host and the real-time control rack running Wind River Helix RTOS in the same virtual test environment.

The actual equipment-control software can then execute against the modeled machine interfaces.

This is useful during system integration because the team can begin checking command exchanges, control sequences, and subsystem interactions while the physical test bench is still being prepared.

Testing Wafer Alignment and Measurement Workflows

#

Before a wafer enters the exposure station, the lithography machine must locate its alignment marks.

The alignment process determines the wafer’s position and provides the information needed to place the exposure pattern correctly.

This operation involves several software components.

The main control software organizes the measurement process and coordinates the required operations. At the same time, real-time control nodes communicate with the relevant sensors and process their feedback.

During integration testing, engineers need to establish that the complete sequence works as expected.

For example:

1. The main controller initiates an alignment measurement.
2. The corresponding control node receives the command.
3. The sensor interface performs the required measurement interaction.
4. Measurement information is returned to the control software.
5. The main controller processes the result.
6. The system proceeds to the next operation when the required conditions are satisfied.

A virtual test bench makes it possible to check these interactions before the complete physical machine is ready.

The important point is that testing does not stop at verifying whether an individual sensor model or controller responds. Engineers can examine whether the subsystems cooperate correctly through the actual software interfaces used by the equipment.

For additional background on Simics hardware modeling and virtual device integration, see Simics Device Model Building.

Extending Virtual Verification to EUV Light Source Control

#

The same approach can be applied to more specialized equipment subsystems.

In the EUV light source example, engineers use Simics to execute the actual light source control software and verify the startup sequence of the relevant subsystems.

These include components such as tin droplet generation and laser control.

The verification process follows the expected equipment startup sequence. Engineers check whether the subsystems initialize correctly and whether the light source can transition from its initialization state into its service state.

The simulation environment on the light source side can also connect to the scanner simulation environment.

This extends verification beyond an individual subsystem.

Instead of checking only whether the light source control software works independently, engineers can test the interface between the light source and the scanner, including the interactions required for their coordinated operation.

For complex semiconductor equipment, this type of integration testing helps identify interface and sequencing problems earlier in development.

🧪 Why Engineers Intentionally Introduce Faults During Testing

#

Normal Operation Is Not Enough

#

A system that completes its normal operating sequence successfully has not necessarily demonstrated that it can handle abnormal conditions.

Consider the over-temperature example introduced earlier.

Under normal conditions, the control software may receive valid sensor readings and execute the expected equipment-control sequence.

But what happens when a sensor reports an abnormal temperature?

Does the system recognize the fault? Does it trigger the correct safety interlock? Does it prevent subsequent operations from proceeding? Does the main controller receive the correct status information?

These questions require dedicated tests.

Waiting for the physical equipment to develop an actual over-temperature condition is not a practical verification strategy. It may be difficult to reproduce, could interrupt development, and may expose hardware to unnecessary risk.

A virtual environment provides another approach.

Engineers can deliberately inject the abnormal signal into the simulated system and observe the response of the real control software.

The objective is to test the software’s response to a defined fault condition, not to physically damage or overheat the equipment.

Controlling the Timing of Fault Injection

#

The timing of a fault can be just as important as the fault itself.

An over-temperature signal received during initialization may produce a different system response from the same signal received during exposure.

For this reason, fault-injection tests should consider both the abnormal input and the equipment’s operating state when that input occurs.

For example:

The same test input can be introduced at different points in the equipment workflow.

This helps expose timing-dependent defects that ordinary functional testing may miss.

It also allows engineers to verify whether the control software handles abnormal inputs consistently across different operating states.

Reproducing Problems with Saved System States

#

Another advantage of virtual testing is the ability to save a system state and use it as the starting point for multiple test cases.

Suppose engineers identify an intermittent problem that occurs only after the equipment has completed a particular sequence of initialization and measurement operations.

Reproducing that sequence manually for every debugging attempt would be time-consuming.

With a saved virtual system state, the team can restore the same starting conditions and execute the test again.

The workflow becomes:

1. Configure the virtual machine to a known operating state.
2. Execute the required preparation sequence.
3. Save the system state.
4. Restore that state before each test.
5. Inject the selected fault condition.
6. Record the software response and system behavior.
7. Repeat the test with different fault timings or input conditions.

This makes it easier to isolate the conditions associated with a failure.

It also reduces variation between test runs. When engineers change one test parameter, such as the timing of an over-temperature signal, they can keep the rest of the starting environment consistent.

Repeatability is particularly useful when debugging defects that depend on a specific combination of software state, command sequence, and input timing.

Integrating Fault Injection into Automated Regression Testing

#

Fault-injection tests are useful during initial debugging, but their value increases when they become part of the regular regression process.

After identifying and correcting a defect, engineers can preserve the corresponding test case.

The same scenario can then be executed again whenever the control software changes.

For example, a regression test may verify that:

• An injected abnormal signal is detected.
• The correct protection procedure is activated.
• The equipment does not continue into an invalid operating state.
• The main controller receives the expected fault status.
• The system follows the configured recovery procedure.

These checks can be repeated after changes to control logic, task scheduling, communication interfaces, or subsystem initialization.

A growing collection of repeatable fault scenarios helps prevent previously discovered defects from returning in later software versions.

It also provides engineering evidence that abnormal operating conditions have been considered throughout the software development lifecycle.

🔬 From Virtual Verification to Semiconductor Equipment Production

#

Moving Testing Earlier in the Development Cycle

#

Developing a lithography machine involves the integration of many hardware and software components.

Waiting until every physical subsystem is available before beginning full-system software testing can delay defect discovery and increase integration costs.

A virtual test bench changes the development sequence.

Engineers can begin testing control applications against modeled hardware interfaces while the physical equipment is still being assembled.

This allows several activities to proceed in parallel:

• Real-time control software development.
• Main-controller application development.
• Hardware-interface verification.
• Sensor and device-model development.
• Subsystem integration testing.
• Fault-injection testing.

Problems involving software interfaces and control sequences can be identified before the complete physical test bench is available.

The virtual environment does not eliminate the need for physical equipment testing. It moves part of the verification work earlier in the development process.

Combining Real-Time Execution and System Simulation

#

Wind River Helix RTOS and Simics address complementary engineering requirements.

Helix RTOS provides the execution environment for time-sensitive control tasks. Its scheduling mechanisms allow engineers to design around defined task priorities and timing requirements.

Simics provides the virtual hardware environment in which the team can execute software, reproduce equipment interfaces, and test interactions among different subsystems.

Together, they support two related questions:

• Can the critical control software execute within its required timing constraints?
• Can the complete control system coordinate correctly when its different components interact?

These questions should be evaluated separately as well as together.

A control task can meet its individual execution deadline while the overall equipment workflow still contains a communication or sequencing defect. Conversely, a virtual integration test may show that command exchanges work correctly without proving that every real-time deadline will be met under production hardware loading.

Both timing verification and system-level functional verification are needed.

Establishing a Repeatable Verification Strategy

#

As semiconductor equipment evolves toward more complex architectures and more demanding process requirements, software verification needs to cover a wider range of operating conditions.

A practical development strategy should combine several levels of testing:

Virtual testing is particularly valuable when test conditions are difficult to reproduce on physical equipment or when the hardware is not yet available.

However, the results still need to be correlated with physical hardware testing. Real devices introduce electrical characteristics, mechanical behavior, sensor tolerances, communication delays, and other effects that cannot automatically be assumed to match a virtual model.

For this reason, the virtual hardware models, software interfaces, and test scenarios should remain aligned with the actual equipment configuration.

The most useful outcome is a verification process in which a discovered failure can be reproduced from a known system state, traced to a specific input condition, and retained as an automated regression test for subsequent software releases.