Innovating in an environment with forty-five million lines of old and new code is no sinecure. John Koster describes how ASML handles the challenge in developing the software for its wafer scanners. ‘We’re truly breaking new ground in model-driven engineering.’
Did the move to EUV dramatically change software development at ASML? John Koster thinks not. ‘To be honest, I don’t see a big difference with our DUV work. The challenges are actually the same,’ says the manager of architecture and innovation within ASML’s eight-hundred-person software cluster. ‘Yes, we have fewer EUV machines out in the field, so their uptime is extremely important, but a DUV system that’s out of commission is at least as painful.’
The focus in software development hasn’t shifted from DUV to EUV, either. ‘We work on both,’ Koster emphasizes, without revealing the exact ratio between the two. ‘We innovate a great deal in EUV, particularly in terms of performance, but we’re also continuing to introduce a whole lot of innovations in our NXT line for DUV. Don’t underestimate that. We took the foundation for EUV from DUV, and every time we learn something new in DUV, we keep passing it on to EUV. And of course clients want to see the quality measures we take in DUV reflected in their EUV systems, too.’
Yoke
Innovating in an environment with forty-five million lines of old and new code and a wide diversity of old and new technologies and methods is no sinecure. ‘When we want to try something new, we can’t start out small. The problem is instantly massive,’ Koster says from experience. ‘But legacy code is no excuse; you have to travel with the tide of innovation.’
He sketches ASML’s approach: ‘Where possible, we try to innovate alongside our legacy code. Our rule of thumb is: don’t touch it unless you have to. We imprint that on all of our engineers here. It’s hard enough to integrate innovations into your existing environment. That’s a giant step, which is often neglected.’
PhD pitches at the Benelux RF Conference
Learn about the latest trends and developments in high-end RF techniques. On 24 May, the Benelux RF Conference will take place in Nijmegen. New this year are the PhD pitches, in which young professionals present their research results. Make sure to reserve your seat in time and register now.
But Koster’s group can’t completely avoid innovating within its legacy code. ‘For each new type of machine, we touch about a third of the code base. It’s inevitable that some legacy will be among that code; and some of those pieces, we’re constantly touching. And there comes a point where we have to improve the architecture, and we have to re-engineer it to make it conform to the latest insights.’
Such a re-engineering endeavour stands or falls by how well it defines its scope of operations, says Koster. ‘You have to be very certain about what the piece of legacy code you want to alter does. Once we have a clear picture of its behaviour, we can pretty successfully replace that building block by defining a new solution within the scope we’ve set.’
Koster’s people prep the chunk of legacy code to be excised as carefully as surgeons, but it remains a tricky task. ‘There are a lot of links around the edges that you have to cut through. Unfortunately they aren’t all clearly visible, which means sometimes you cut through one without knowing it. You don’t notice the negative consequences until later. We’re working with universities to research all kinds of techniques to get the best possible picture beforehand of all the dependencies we’re going to be affecting.’
By addressing the legacy code piece by piece, it should be possible to shake off that yoke entirely, Koster believes. ‘By properly isolating the code, you’ve already got the bulk of the solution. Over the next ten years we’re going to make major strides there. For example, I have high hopes for data analysis techniques. We’re currently looking at whether we can unleash those on our code base to automatically map out the external dependencies.’
DCA
To further increase the speed of development and streamline the link between innovation and legacy, ASML is betting on models. ‘Just as in the 1950s, 60s and 70s we moved from zeroes and ones to programming languages like Algol 60 and 68, with completely new concepts that we still use today, now we’re ready for the next step in abstraction through model-driven engineering,’ Koster says. ‘At ASML, we’ve made significant progress there in recent years.’
No sidelines rehearsals here; ASML has jumped straight into the deep end, tackling concrete development issues. ‘You can’t take steps like these in isolation; the technology and its implementation are too complex for that. We work right on our machines, on production code. That lets us kill two birds with one stone: we introduce new techniques and their concrete application instantly teaches us where we can improve. We’ve got two pilot projects in advanced stages and we’re on the eve of broader deployment. The result has been proven and is already out there in the field.’
In one of those pilots, ASML has re-engineered a piece of legacy code that’s part of what the company calls lot operations. ‘That’s a subsystem in our machine control,’ Koster explains. ‘We’re talking about more than five hundred thousand lines of code, 92 per cent of which we now generate automatically. That’s a huge task, but we’re delighted with the result. In fact, the automatic code generation has essentially eliminated coding errors. We’ve moved from code as the basis to executable specifications. As a result, we’ve discovered that we’ve missed a number of requirements. That’s still a point for improvement.’
The second pilot involves the measurement side of the scanner. ‘In our Twinscan concept, we simultaneously have two wafers in the machine: we expose one while we map out the surface of the other in three dimensions. In the z component we call that levelling, and we’ve greenfield-modelled an important piece of software there. The generated code comes in at 250 thousand lines now. Here, too, we haven’t found an error yet to date. And because it’s greenfield, we haven’t missed any requirements, either.’
And so in recent years ASML has developed a vision for model-driven engineering and translated it into an architectural pattern, supported by an extensive toolkit. As its name suggests, this DCA pattern distinguishes between data, control and algorithmics. ASML’s software developers use off-the-shelf tooling to model control and algorithmics. They’ve developed their own tool to model the data. ‘There isn’t anything commercially available that we can use,’ explains Koster. ‘And that’s not so strange, because our data structure is very specific to our scanner.’
The three paths come together in a system builder, also an in-house implementation. ‘That’s a tool for our systems engineers. When new developments come down the pipe, they can model the data, control and algorithms simultaneously, and generate code with a push of the button.’
Prototype
A good software chassis is essential for development, Koster says. ‘Just as the auto industry builds multiple vehicle models using the same chassis in order to cut costs, we want to have a software platform we can reuse in different machine types. There’s risk involved there. Our legacy code is part of the reason why our software has a much longer lifespan than our hardware. It’s quite possible that one of our old designs contains a software component that’s reached its end of life. We have to replace that on time. That makes a good software platform and good platform management essential.’
Koster describes the company’s approach: ‘For a given product family, we define the software platform it will use beforehand. Then we use that for the entire family. We also start thinking about the next generation. Later, we’ll define a new software platform for that. We keep these evolutionary platforms as close to one another as we can. We try to do the same thing across different types of machines, so we don’t have a new platform in each type.’
To fill the software chassis, ASML pursues aggressive modularization. ‘The auto industry mounts one and the same engine into different chassis,’ Koster notes. ‘That’s what we want to be able to do with the software components in our scanners. For that, it’s crucial to have reusable modules, which means modules with well-defined interfaces. This is particularly a challenge with legacy code, where a shortage of time has sometimes created impure dependencies. If you can keep the code pure, you can deliver higher quality.’
Not that this is new, Koster acknowledges. ‘But it remains hard to do. What are the design rules for achieving good modularization in a large software system? There’s no ready-made recipe for that. That’s a place where we want to make further strides.’
Given an executable specification and a software platform, it’s a small step to a virtual prototype. ‘There’s a great need for that, in both new and existing products,’ Koster says. ‘The number of available EUV prototypes is obviously limited because these systems are in the middle of development, but there’s a dearth in DUV, too: a whole lot of DUV machine types only exist out in the field now, where they’re in production. The client isn’t eager to give us access to his system, though we’re usually able to work something out. What’s more, we have a number of relatively limited software simulators that we try to keep aligned with our machines in the field as well as we can.’
But 90 per cent of the software functionality can simply be developed on a virtual prototype, says Koster. ‘We aren’t there yet, but that’s our goal. You should only have to use a real prototype when you want to test realtime performance.’
Momentum
Koster also gets together with his counterparts in the region to discuss his challenges. ‘I want to share all our progress in software methods and technologies with others. By telling everyone how we view things and what we’re doing, we’re trying to search for points of reference to mutually enrich our knowledge base. We are absolutely open to others’ experiences. We’re eager to learn from others.’
ASML formed a software innovation platform with other companies and technology partners some time ago. ‘Every once in a while we get together and discuss what we’re doing and where we all are. We also visit other companies. Our major topic of conversation is model-driven engineering. We share our knowledge and progress, learn from each other and develop a shared vision of how we can move regional MDE to the next level in order to further ramp up the speed of innovation. It’s gaining momentum. I think we’re truly breaking new ground.’
In addition to the innovation platform, ASML shares its MDE vision through partnerships with universities and by participating in TNO-ESI initiatives. ‘Through these, I hope to accomplish a number of things, including teaching students about MDE so they already have a background when they walk through our door. Right now MDE isn’t a real part of the curriculum, but in our talks with universities I see a lot of eagerness to change that.’