Over the past years, ASML has been taking determined steps toward model-based systems engineering (MBSE), driven by growing system complexity, cost pressure and the need for earlier insight into the impact of design decisions. Inspired by the multi-company workshops facilitated by TNO-ESI, the litho giant’s systems engineers are gradually converging on a shared ambition: moving from isolated models toward a connected digital thread across the full product lifecycle.
“The way we developed our products in the past was mainly supported by adding resources,” says Henning Farthmann, who leads the Design and Engineering Automation program at ASML. “We were basically doing more work with more people. That approach doesn’t scale anymore.”
This realization became increasingly urgent as systems grew more complex, more integrated and more expensive. Physical prototypes became a bottleneck. “With today’s hardware, you can’t afford to build and test multiple protos anymore,” Farthmann explains. “So, the idea emerged: shift left. Use models and simulation as early as possible, when changes are still cheap.”
Within the Design and Engineering Automation program, ASML started investing structurally in this direction, enabling smarter engineering practices. “Efficiency is part of it,” Farthmann says, “but more important is earlier insight. Behavior, cost, maintainability, availability – we want to understand these aspects much earlier in the design cycle.”
As modeling activity increased, so did the need for structure. “If everyone builds models in their own way, it becomes impossible to connect them,” Farthmann notes. “You need a reference architecture, you need standards and guidelines that help relate the models, the requirements and the engineering structures. MBSE provides that reference.”
Connected models
From the software side, the same pressure was felt. Frank Commissaris works in ASML’s metrology and machine control cluster, where hardware models are essential to predict and control scanner disturbances. “For example, to optimize machine performance, we predict the heating behavior of the lens, reticle and wafer and compensate them by adjusting the lens and stages.”
Within his domain, model-based thinking had already matured considerably. ASML developed internal frameworks such as ASOME for data handling and uses tools like Popili from Cocotec to automatically generate control sequences. “In metrology and machine control, that’s probably the closest we were to MBSE already,” Commissaris reflects. “But it was still very much local.”
It became increasingly clear that local optimization was no longer sufficient. “We do budgets in Excel today,” Commissaris illustrates. “However, if we want to understand system behavior under different conditions, lots or product variants, we need connected models. Ultimately, that points toward a digital twin.”
Cost pressure reinforced that need. “We’re constantly looking at more cost-effective materials or alternative designs,” Commissaris goes on to explain. “But you can’t easily predict what that does to overlay or imaging performance. Simulation helps, but only if models are connected at the system level.”
That realization marked the transition from modeling as a domain activity to MBSE as a systems discipline. As Rentia Barnard, working from enterprise and business architecture, puts it: “MBSE isn’t about modeling for the sake of modeling. It’s about making better decisions – earlier, with more confidence and with full visibility of impact.”
System BOI
ASML’s MBSE journey formally started about five years ago, when the company decided to move core systems engineering information out of documents and into models. “We wanted to get requirements, interfaces and architecture information out of Powerpoint and Word,” Barnard explains, “and turn them into living information objects.”
The emphasis, she stresses, is on decision support. “Models shouldn’t be static documentation. They must help engineers understand impact: cost, schedule, performance, sustainability. If a change happens at the system level, everyone downstream should immediately see the consequences.”
The concept of a single source of truth frequently comes up. “It’s extremely important,” Barnard says, “but not always realistic. Sometimes data lives in multiple information systems. Then you need to at least know exactly how data is connected. Otherwise, you can’t analyze impact.”
That’s where the digital thread becomes central. “MBSE is the start of that thread,” Barnard explains. “Once information is digital and connected, you can build digital twins and feed real-life data back into design.”
One tangible outcome is the so-called System Bill-of-Information (System BOI). Instead of relatively vague descriptions of changes, ASML now aims to define explicit features and link them directly to affected system elements and requirements. “That makes the impact transparent,” says Frank de Lange, responsible for systems architecture. “Not only for engineers, but also for program management, system integration and even the factory.”
Lost in translation
ASML has adopted the Capella tool and the Arcadia modeling language as its MBSE standard. “But the most important thing isn’t whether it’s SysML or Arcadia,” Barnard stresses. “What matters is standardization. Everyone must tell their story in the same language, and we found Arcadia more intuitive for the engineers.”
The language aspect turned out to be one of the biggest hurdles. “It’s not about tools first,” says ASML systems engineer Marijn Kessels. “It’s about having a common modeling language. If I talk about variants and configuration and others don’t share that understanding, I’m speaking French while they speak Dutch.”
A lot is lost in translation, Barnard points out. “Requirements specifications and other systems engineering documents written in English can be interpreted and understood differently by different people. We have to support standardization with something more exact, like adding models with explicit performance boundary conditions attached.” Formalization is key, maintains systems engineer Jonnro Erasmus. “It helps safeguard model integrity.”
Data is an exact formalism, but data isn’t yet information. “With model-based systems engineering, you see a lot of emphasis on putting in data,” Kessels notes. “At ASML, we have huge amounts of data. The hard part is creating the right model to deliver the right information.” De Lange: “It’s crucial to find out what’s really needed for making a good decision and then get the tooling to produce the required output. For instance, an overview of which system elements are impacted by a feature.”
Erasmus concurs. “I would say the hardest lesson we learned is that we underestimated the importance of being able to present the information in a way that people can use it. Building a model is one thing; making it accessible, meaningful and useful is a completely different matter.”
Resistance
Another lesson is that experienced systems engineers are both the key enablers and the biggest bottleneck. “They carry enormous knowledge in their heads,” says Barnard. “But they’re also the busiest people, with the least time to learn new ways of working. Asking them to model information they’ve been capturing in Visio, Powerpoint or Excel for years – it’s a learning curve that also triggers resistance.”
“The digital thread needs to start somewhere,” De Lange points out. “At the system level, we see real value in making an architecture model where we capture system design-related information and make sure that all involved know what we’re talking about. Having all the information together in one source of truth will bring efficiency by preventing misunderstandings between stakeholders. But it’s not an easy path we’re on. We need to show people that that value is really there.”
“We can’t convince them; they need to convince themselves,” says Kessels, who is working daily with his colleague Erasmus to overcome the resistance with their fellow systems engineers. “We encounter a lot of misunderstanding about what model-based systems engineering is. Our colleagues often think a system model is just another model. They struggle to understand what it can bring them. As long as they don’t put in the effort to see the value, they’ll keep on resisting.”
“All we can do is lead by example and provide as much information as we can,” adds Erasmus. “We start doing MBSE ourselves and we show them concrete results. Once colleagues see how it could help their own work, things start moving.”
Future steps
Despite significant progress, ASML’s MBSE journey is far from finished. “Acceptance is the first real milestone we still need to reach,” De Lange says. “Systems engineers and functional cluster architects must truly embrace this way of working.” He’s realistic about the pace. “It will take a few more years, definitely. Things don’t move fast. I hoped we would be where we are now already a year ago.”
For Kessels, future steps depend largely on people, not technology. “We have many ideas on our roadmap,” he says. “But we can only move forward if colleagues are prepared to invest time. Their willingness to endorse this and take next steps is our guide. We can’t force MBSE, and we shouldn’t.”
“We are going to apply a bit of pressure, though,” notes De Lange. “Within the EUV and DUV departments, we’ve agreed on introducing the System BOI. So, in our talks with relevant people, we’ll politely tell them to have a look at it and start using it.”
De Lange is already noticing signs of a mentality change, although ever so slightly. “Just this morning, I talked to one of our seasoned systems engineers who, not so long ago, called MBSE useless, but he’s now slowly coming around. I find that quite telling.”
Barnard agrees. “I also think people are starting to see the value that MBSE can bring to their daily decision-making. They get answers faster. The impact of a decision becomes clear much more quickly. It provides a better insight into cost development and other trends. The big challenge for introducing MBSE, not only in ASML but in all companies starting this journey, is that people need to learn a new way of doing things.”
Eye-opener
In ASML’s journey, TNO-ESI plays a facilitating role by connecting the litho giant with other Dutch high-tech companies facing similar challenges. “From 2020-2022, we conducted a study into the added value of MBSE, which showed that the issues aren’t unique. Interface management, model integration, governance – everyone struggles with them,” says Joris van den Aker, ESI’s program manager for systems engineering. “Subsequently, we organized some deep dives, two-day workshops with several companies presenting what they were doing with MBSE. Last year, we brought them all together in a special interest group that convenes every quarter.”
De Lange was invited to one of the workshops, which turned out to be a real eye-opener for him. “At that time, I had no clue, absolutely no clue what MBSE was,” he recollects. “In the meeting, someone from Thales said: ‘The most important thing is to have a clear goal for your model and stick to it. Otherwise, it quickly balloons out of control.’ That has always stuck with me. Looking at all the companies doing MBSE has taught us the wisdom of that lesson: how extremely important it is to keep a tight rein on the goal of your model and to have a good description of that goal.”
Through TNO-ESI, collaboration is now also expanding across Europe. “Fraunhofer is starting a German MBSE SIG,” indicates Van den Aker. “They want to connect with us.” That broader perspective is valuable, De Lange believes. “Different industries look at systems differently. That helps sharpen our own thinking.”
Top image credit: ASML. This article was written in close collaboration with TNO-ESI.
