Director Science and Operations, resp. Director Business,
ESI (TNO)

Professor of Software Engineering, Director Software Center, Chalmers University of Technology

Digitalization is the great disruptor of the embedded systems industry and many companies are struggling to respond. During the keynote, I discuss the key implications for systems engineering as well as business models as well as present industry best practice approaches to dealing with software (DevOps), data (DataOps) and AI (MLOps). The talk is based on examples from several companies that are members of Software Center.

Senior Director Software Architecture, resp. Senior Principal Architect SW, ASML
The majority of high-end system vendors with a product lifecycle that spans decades, face challenges on the legacy of their SW. ASML is no different, with its need to balance the management of the installed base with new product introductions.

ASML is a unique company in the world operating at the edge of the laws of physics. Its continuous innovation ensures that the world’s Integrated Circuits technology stays on track of Moore’s law, thereby helping to reduce this “law” to a self-fulfilling prophecy. At the same time, ASML systems have a lifespan of more than 20 years. Products in the field are regularly upgraded and new products are built on top of the existing ones, profiting from reuse policies. It is thereby said that an ASML system never leaves the planet. Lastly, one of the key KPIs is machine up-time, since an ASML machine is designed to produce ICs 24/7, which emphasizes the importance of quality and robustness of HW, as well as SW.
These features of an ASML system lead to a priority competition between addressing the legacy SW issues and new features introduction. So far, the victory has often been claimed by the latter. However, we in ASML recognize that our SW development velocity will be hampered by our own legacy, our own unpaid technical debt. In this presentation, we will introduce the concept of technical debt in the context of ASML’s business. We will identify roadblocks as well as steps to get out of this technical debt trap.

Senior Research Fellow, ESI (TNO)

Managing your legacy software requires insight, especially in global aspects of your code base. Your software is probably large and complex, and contains in-house libraries. So you need automation to deal with the size, but off-the-shelf analysis tools do not focus on the use of your libraries. Luckily, you are not alone: ESI (TNO) has encountered this situation in several applied research projects. In this talk I will present our methodology that is based on model extraction using static analysis.

Go to presentation (pdf)

Group Leader at CWI and Professor at Eindhoven University of Technology (TU/e)

Beyond any doubt the competence of software engineers (designers, architects, programmers, testers) influence the productivity and the quality of their product - software- greatly. Since the software maintenance phase on software ownership is the longest and the most expensive phase, we focus on the software maintenance competences in this talk. What do software maintainers do? How could they improve their effectiveness? Which tools do they use and how can these tools be improved?

We focus on maintaining older systems, which are the most successful systems, yet they are also (typically) most vulnerable to high risk and high cost maintenance activities. Older systems are too big to comprehend, and sometimes incremental maintenance has clouded the clarity of the source code greatly (it does not make sense anymore). Which engineering competences float to the surface in the context of such legacy systems and how can we improve them?
The first step towards professional maintenance competences is to take the stance of the researcher: the software simply exists and interesting research questions are to be answered. The second step is to start automating bespoke software tests, source code analyses and source code transformations to (a) help improve the trust in future changes, (b) help answer the research questions and (c) make tractable and repeatable changes to the source code.

Senior Research Fellow at ESI (TNO), resp. Software Component Owner at ASML

Have you ever struggled to understand the behaviour of a piece of software? Have you ever seen a change in software cause a regression in a seemingly unrelated part of the system? These are the kinds of challenges we address.

Complex high-tech systems typically consist of many concurrently communicating software components. Understanding the current software behaviour is a major challenge, especially for legacy software for which the original developers have long since left and technical debt exists. Another challenge is that changing software is risky as any mistake can break the system. Preventing issues at the customer is essential as the impact is huge. This is particularly true for redesigns that bring no new value to customers.

In order to provide insight into the behaviour of the software, our approach allows inferring models that capture the complex interactions. Automatic inference avoids the laborious and error-prone effort of manual modelling. To understand the impact of software changes, identify regressions and reduce the risks, we compare software behaviour models and visualise the differences for various software versions.

We apply our approach to an ASML TWINSCAN software component. It helps to detect unintended behavioural regressions, reduce risks and save valuable time, thereby leading to faster deliveries.