Nieke Roos
23 January 2017

Altran is supporting ASML in its model-driven engineering efforts. Among other things, the software company in Eindhoven is assisting in the introduction of new domain-specific languages. It’s also defining the language architecture, which can be used to model the use of languages in the development process.

In recent years, ASML has made great strides in model-driven engineering. Altran is playing a major role in developing the necessary MDE facilities: the domain-specific languages in which ASML’s software architects and engineers write specifications and the software factory that then implements them. ‘We’re working with ASML to develop DSLs for various layers in the software architecture,’ says Niels Brouwers at Altran. ‘These DSLs are used to automatically generate the production software for ASML’s Twinscan systems as well as to validate and verify it.’

The adoption of MDE is a stepwise process, says Brouwers’ colleague Marc Hamilton. ‘It usually starts in a part of the engineering process where a problem has cropped up, or where things need optimizing. You notice, for example, that when you change one thing, you have to change things in 101 other places. So you wrap a language around it, with the associated machinery. Because you know how that piece is constructed, you can expand on it. And so you can incrementally raise the level of automation.’

It’s definitely not a blind introduction, says Hamilton. ‘The MDE facilities we create automate a large part, but not everything. It just isn’t always worth the effort to fully automate it all. Sometimes it takes more effort to develop and maintain a language than to implement part of the software directly in a language like C++ or Java. You always have to weigh whether a resource serves the goal.’

Altran language architecture
Fragment of a language architecture: a high-level description of how several transformations will generate a model-based test engine from the system specifications.


‘On one hand, we use domain-specific languages to decouple from the underlying technology,’ Hamilton explains. ‘At several places in the engineering process, for example, you encounter state machines. You can create a DSL for those that you then transform using a kind of compiler into an implementation language like C++ or Java, or on the same abstraction level to a state-machine-specific solution like ASD or Stateflow. The advantage is that you only have to modify that transformation when you switch to a different technology. That way we can isolate generic subdomains – working horizontally in the engineering process.’

BCe24 save the date

On the other hand, Hamilton continues, Altran also uses DSLs to abstract to more specific concepts – working vertically in the engineering process. ‘A component you create according to specific rules can form a single concept in your language. These can be very advanced concepts such as scans, which encapsulate enormous meaning. So the expressive power is quite significant. And in doing that, you also decouple the implementation from the intention you’ve expressed in the concept. The disadvantage is that it becomes so context-specific that it can’t be translated to environments where the context isn’t exactly the same. A scan means something different at ASML than at Philips Healthtech.’

The trick here is to capture the concepts through which the architects and engineers communicate with one another, Hamilton says. ‘In a domain where we want to use this approach, we go looking for the prevailing concepts and the relationships between them. We convert these into a formal language, the DSL, which the developers can use to communicate just the way they would using that work-floor jargon. At the same time, we create transformations so we can convert to other DSLs and implementation languages with the push of a button.’

The engineers can always overrule what’s been generated, Hamilton notes. ‘If there’s a bug in it, for example, and waiting on the next update from the software factory isn’t an option. We’ve built in mechanisms for that, which they can use to manually replace the code and fix the problem.’

Altran has christened the construction of these kinds of ‘vertical’ DSLs ontology-based development. Ontology is the study of the objects of human thought. ‘Model-driven engineering is very broad,’ Hamilton says. ‘For example, it also includes the use of generic modelling languages for various horizontal domains. We introduced the term ontology-based software engineering to indicate the development of very specific languages.’

In addition, Altran uses DSLs that enable the architects and engineers to check whether they’re developing the right system. ‘You want to be certain of that as early as you can,’ Brouwers says. ‘The abstraction that DSLs provide lets us derive models we can use to prove whether the system being developed has the desired properties. If it doesn’t, the developers can act early to revise the design. In a sense, we’re moving up the V earlier.’

Major advantages

Altran has become quite skilled in DSL-based development. The next step is to keep it manageable. ‘If you apply DSLs on a large scale but don’t sufficiently monitor the links between them, it will mushroom out of control,’ Brouwers warns. ‘Engineering processes are extraordinarily complex. At a given point you no longer see the dependencies, not among the languages but also not between the languages and the tooling you use. That makes it hard to determine what impact a change in one of the languages or compilers will have on the rest.’

That’s why for the last several months Altran has been working on a way to formalize the engineering process. ‘A development project is one big cascade of parallel processes with conversions from one language to another, both human and machine languages,’ Hamilton explains. ‘When you try to automate that, it’s important to know not only which languages you’re using at every step, but also which tooling you’re using. We identify all that and capture it in what we call a language architecture.’

What the software architecture is to a piece of software, the language architecture is to the development process. ‘You start a software project by creating an architecture with a clean, tight design. You have to do the same thing when you automate a piece of an engineering process,’ Hamilton says. ‘You need a form of design for that, but one with a focus on the use of language. That’s the language architecture.’

Like every design, a language architecture can be created at multiple levels of abstraction. ‘Sometimes you know what you want to do, but not what technology you want to use. You can go ahead and set up a language architecture at a high level and later, refine it with additional detail,’ Hamilton says. ‘Sometimes there are external requirements you have to satisfy, such as language availability or contracts with tool suppliers. A reference architecture records the rules you have to follow in later refinement phases.’

The language architecture makes the impact of language changes visible, says Brouwers. ‘And that’s one of the major advantages. If you’ve identified the relevant languages for your engineering process and something changes in one of them, you can use the language architecture to analyse the impact of the change across the entire chain.’ Hamilton compares it to software interfaces: ‘When you tweak them, you also look at which components will be affected by your changes. You do the same thing for changes to the engineering process, only there the languages are the interface.’

Other stakeholders also benefit. ‘A project leader who wants to start using a new tool in a later phase of the engineering process can use the language architecture to perform a risk assessment, and based on that, ask the supplier to provide additional support if necessary,’ Brouwers illustrates. ‘A line manager can inventory the degree to which his software engineers are familiar with the languages and tooling they’re going to have to use, and if necessary, set up how-to workshops.’

Neatly integrated

‘Being able to manage the complex engineering environments well: that’s our current objective,’ Hamilton says, summarizing the challenge facing Altran. ‘In practice you see a lot of implicit communication, in documents and emails and other things. We briefly explain a new concept to each other, and then assume that everyone’s up to speed. At Altran, we’re working hard on resources to make that communication explicit, so the process becomes more manageable and the execution of changes is controlled.’

That also makes it significantly easier to incorporate new technologies, Hamilton says. ‘You can integrate the use of a formal language developed by a research institute in your automated engineering processes. Your engineers can concentrate on the aspects that are relevant to their domain and they no longer have to worry about the details of advanced, knowledge-intensive applications like these. That also gives you the scalability and flexibility you need. The language architecture helps you set up these automated processes cleanly.’