CPD integrated development toolkit

Alkalai, E.; Technische Universiteit Eindhoven (TUE). Stan Ackermans Instituut. SoftwareTechnology (ST)

Published: 25/09/2015

Document VersionPublisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the author's version of the article upon submission and before peer-review. There can be important differencesbetween the submitted version and the official published version of record. People interested in the research are advised to contact theauthor for the final version of the publication, or visit the DOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

Citation for published version (APA):Alkalai, E., & Technische Universiteit Eindhoven (TUE). Stan Ackermans Instituut. Software Technology (ST)(2015). CPD integrated development toolkit Eindhoven: Technische Universiteit Eindhoven

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal ?

Take down policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediatelyand investigate your claim.

Download date: 05. Jun. 2018

CPD integrated development toolkit

Erikos Alkalai

2015

CPD Integrated Development

Toolkit

Erikos Alkalai

September 2015

CPD Integrated Development Toolkit

Erikos Alkalai

Eindhoven University of Technology

Stan Ackermans Institute / Software Technology

Partners

ASML Eindhoven University of Technology

Steering Group John Vugts (ASML)

Wouter Tabingh Suermondt (ASML)

Marcel van Heerebeek (ASML)

Tim Willemse (TU/e)

Date September 2015

Document status Public

The design described in this report has been carried out in accordance with the TU/e Code of Scientific Conduct

Contact

Address

Eindhoven University of Technology

Department of Mathematics and Computer Science

MF 7.090, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands

+31402474334

Published by Eindhoven University of Technology

Stan Ackermans Institute

Printed by Eindhoven University of Technology

UniversiteitsDrukkerij

ISBN A catalogue record is available from the Eindhoven University of Technology Library

ISBN: 978-90-444-1372-4

(Eindverslagen Stan Ackermans Instituut; 2015/034)

Abstract

Keywords

Model Driven Development, CPD, Functional Design, Functional Requirements, ASML,

Domain Specific Language DSL, Ecore, Process Creation, Functional Requirements Trans-

lation

Preferred

reference

E. Alkalai, CPD Integrated Development Toolkit. Eindhoven University of Technology,

SAI Technical Report, September 2015. (978-90-444-1372-4)

Partnership This project was supported by Eindhoven University of Technology and ASML.

Disclaimer

Endorsement

Reference herein to any specific commercial products, process, or service by trade name,

trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorse-

ment, recommendation, or favoring by the Eindhoven University of Technology or ASML.

The views and opinions of authors expressed herein do not necessarily state or reflect those

of the Eindhoven University of Technology or ASML, and shall not be used for advertising

or product endorsement purposes.

Disclaimer

Liability

While every effort will be made to ensure that the information contained within this report is

accurate and up to date, Eindhoven University of Technology makes no warranty, represen-

tation or undertaking whether expressed or implied, nor does it assume any legal liability,

whether direct or indirect, or responsibility for the accuracy, completeness, or usefulness of

any information.

Trademarks Product and company names mentioned herein may be trademarks and/or service marks of

their respective owners. We use these names without any particular endorsement or with the

intent to infringe the copyright of the respective owners.

Copyright Copyright © 2015. Eindhoven University of Technology. All rights reserved.

No part of the material protected by this copyright notice may be reproduced, modified, or

redistributed in any form or by any means, electronic or mechanical, including photocopy-

ing, recording, or by any information storage or retrieval system, without the prior written

permission of the Eindhoven University of Technology and ASML.

i

Foreword

'The beginning is the most important part of the work' (Plato).

Dear Erikos,

The CIDT project is not a typical technical project in the sense that there is a (more

or less defined) problem and someone is requested to design a (technical) solution.

This project should be considered as a quest towards a new way of reasoning and

designing complex systems, using the technology and insights of today. Your OOTI

assignment was the very first start of this initiative, so I can say that you were also

the first employee working on the CIDT project.

The ideas of a more automated, model driven way of development, applied to the

CPD domain are not new. In fact it is already subject of discussion for many years.

However sometimes, someone has to start, igniting the fire that brings us the poten-

tial benefits. From this perspective, one can never start early enough.

Starting from a green field is always difficult, but you performed very well. You

were able to master the problem, building up your own network of people assisting

you, and last but not least, gaining the confidence of our intended functional key us-

ers by selling the message in a convincing way.

Some day we will wake up and discover that your work had resulted into a dramatic

change in the way we are reasoning and developing our software solutions. We will

remember that you initiated the program, worked in isolation and had to deal with an

engineering community that was barely understanding the impact with respect to

their daily work.

The great Greek philosopher Plato phrased this in an inspiring way: 'The beginning is

the most important part of the work'. Thanks for your contribution, your never ending

source of energy, your personal drive and your skills to create something out of noth-

ing,

Wouter Tabingh Suermondt

August, 2015

iii

Preface This report offers a detailed account of the graduation project for the Software

Technology program on behalf of the Eindhoven University of Technology and

the Stan Ackermans Institute. This project was carried out in ASML, a company

that designs, develops, and produces lithography solutions, over a period of nine

months from January until September 2015.

The project’s goal is to evaluate the author as a software designer, while provid-

ing ASML with a modern approach in designing CPD applications, which are

used in an ASML machine to perform calibrations, diagnostics and performance

tests. This report contains the design solution as well as a description of the pro-

cess that led there. Therefore, in addition to the new design, the domain, project

management conclusions, and retrospective are explained in corresponding chap-

ters.

Erikos Alkalai

August, 2015

v

Acknowledgements Firstly, I would like to express my sincere gratitude to my supervisor Wouter Ta-

bingh Suermondt for the continuous support of my OOTI graduation project and

related research, for his patience, motivation, and immense knowledge. His guid-

ance helped me in all the time of research and writing of this thesis. I could not

have imagined having a better advisor and mentor for my project.

Besides my supervisor, I would like to thank the rest of my thesis committee:

Marcel van Heerebeek as my Technical Mentor and leader of the CPD Technical

Competence Team, Dr. Tim Willemse as my TU/e supervisor, and Dr. Ad Aerts

as the OOTI coordinator, for their insightful comments and encouragement, but

also for the hard questions, which incented me to widen my research from various

perspectives.

My sincere thanks also go to the members of the CPD Technical Competence

Team: Leon Mertens as the CPD Technical Competence Owner, Tim Scheffers,

Danny Handoko, Stephan Hermans, Pieter Goudzwaard, Antoine op de Laak, and

Teun van de Berg, who provided me an opportunity to join their team as intern,

and who were challenging my findings concerning the CPD applications. Without

they precious support it would not be possible to conduct this research.

I also thank the functional engineers: Tom Mattaar and Gerbert ten Brinke from

the Wafer Stage Positioning FC, Kees Kotterink, Tabitha Kinyanjui, and Na-

tascha Mertens – De Jong from the Level Sensor FC, and Hans Schoormans from

the Metrology Grid and SPM FC, who were nicely cooperating in my investiga-

tion and showing actively an interest on my findings despite their busy schedule.

I would like to thank a group of people inside ASML: John Vugts, who initiated

this project, Ramon Schiffelers, who aligned this project within the Concerto Re-

search Program, and Robert Hoogland, who provided supporting resources. Their

contribution was very crucial for starting, supporting, and completing my project.

I thank my fellow OOTI peers in for the stimulating discussions, for the sleepless

nights we were working together before deadlines, and for all the fun we have had

in the last two years. I would like to also thank our OOTI program coordinator Ad

Aerts for his guidance and support throughout these two years. In addition, I have

to acknowledge the support of Maggy de Wert, management assistant of the OO-

TI program for always being ready to help and support us with the most efficient

way. Also I thank my friends in Boreas Association for the exciting sailing week-

ends.

Last but not the least, I would like to thank my family: my parents and to my sis-

ter for supporting me spiritually throughout writing this thesis and my life in gen-

eral.

Erikos Alkalai

August, 2015

vii

Executive Summary CPD applications are crucial for maintaining an ASML lithography scanner in a

high performance. The CPD family consists of three application types: Calibra-

tions, Performance, and Diagnostics. A calibration application tunes the ma-

chine’s parameters so that the system meets the requirements. A performance

application qualifies the machine according to the specification. A diagnostic

application locates potential machine problems. All three application types are

designed by highly skilled functional engineers and are developed by experienced

software engineers. However, there are many opportunities to improve the deliv-

ery time of these applications. The bottleneck is located in the current V-Model

hand crafted engineering process and more specific in the translation of the func-

tional to software requirements. This report focuses on an alternative process,

supported by the CPD Integrated Development Toolkit (CIDT) and is part of the

orientation phase of the CIDT initiative.

In the past years, there were various attempts to improve the delivery time, by

creating better and more modern tools for the software engineers. Although these

tools helped them to develop the required software faster, they did not provide a

solution for a better understanding of the functional requirements. In contrast, the

CIDT is developed by putting the CPD functional engineers in the center of atten-

tion. The CPD functional engineers hold the key to the solution. This initiative

will focus on their needs in order to design and develop a CPD application faster

and it is not an attempt to put more work on their daily job.

In order to achieve this, we invited CPD functional engineers to multiple inter-

view sessions and tried to grasp their underlying needs. The intention was to col-

lect a first order requirement list in order to develop a tool that would solve their

problems. Then, we used Domain Specific Language (DSL) techniques to devel-

op a language based on the functional requirements of a CPD application. Finally,

we used existing CPD applications to verify that the developed domain specific

language meets the collected requirements and can satisfy the needs of the func-

tional engineers. Finally, in every step of the process, we kept functional engi-

neers in the loop to ensure their alignment with the produced results.

The first order investigation is completed with four concrete deliverables. The

first one is a requirements list, which focuses on the CPD functional engineers’

needs. The second one is a new process that removes the software engineers from

the direct CPD development process and places them in the CPD tools develop-

ment. The third one is a zero order business case analysis that investigates the

CPD applications’ statistics and the return on investment for developing the

CIDT. Finally, the fourth deliverable is a CPD functional DSL that stands as a

proof of concept for the CPD application functional development. All these deliv-

erables are the main input for the feasibility phase of the CIDT initiative.

In conclusion, the results of the first order investigation seem promising into

achieving a CPD application functional DSL and including it into a single inte-

grated environment that will be used by the functional engineers. However, there

are some hidden challenges. As a result, I recommend in continuing and complet-

ing the feasibility phase to investigate the hidden technical challenges of the

CIDT initiative.

ix

Table of Contents

Foreword .................................................................................................... i

Preface ...................................................................................................... iii

Acknowledgements ................................................................................... v

Executive Summary ................................................................................ vii

Table of Contents ..................................................................................... ix

List of Figures ........................................................................................ xiii

List of Tables ........................................................................................... xv

Change History ..................................................................................... xvii

1. Introduction ....................................................................................... 1

1.1 Context ......................................................................................... 1

1.2 Outline .......................................................................................... 2

2. Stakeholder Analysis ......................................................................... 3

2.1 Introduction .................................................................................. 3 2.1.1. Analysis ..................................................................................... 4

3. Problem Analysis ............................................................................... 7

3.1 Introduction .................................................................................. 7

3.2 Roadmaps ..................................................................................... 8 3.2.1. Orientation Phase....................................................................... 8 3.2.2. Feasibility Phase ........................................................................ 8 3.2.3. Demonstration Phase ................................................................. 9 3.2.4. Prototype Phase ......................................................................... 9 3.2.5. Industrialization Phase ............................................................... 9 3.2.6. Rollout Phase ............................................................................. 9 3.2.7. Lifetime Support Phase ............................................................. 9

3.3 Stakeholders ................................................................................. 9

3.4 Design Opportunities ................................................................. 10

3.5 OOTI Project Requirements ....................................................... 10

4. Business Case ................................................................................... 11

4.1 Introduction ................................................................................ 11

4.2 CPD development history........................................................... 11

4.3 Analysis ...................................................................................... 12

4.4 Value Chain and Business Processes ......................................... 12

5. Domain Analysis .............................................................................. 13

x

5.1 Introduction ................................................................................ 13 5.1.1. Clients and Users ..................................................................... 13 5.1.2. Environment ............................................................................ 14 5.1.3. Current Situation ...................................................................... 14

5.2 The block approach .................................................................... 16

5.3 Users - Actors ............................................................................. 17

5.4 User Stories ................................................................................ 17 5.4.1. CPD Development Design ....................................................... 17 5.4.2. CPD Simulation ....................................................................... 18 5.4.3. CPD Maintenance .................................................................... 18 5.4.4. Block Design ........................................................................... 18 5.4.5. CIDT Support Competence Team ........................................... 19

6. Feasibility Analysis .......................................................................... 21

6.1 Issues .......................................................................................... 21

6.2 Risks ........................................................................................... 21

7. System Requirements ...................................................................... 23

7.1 Introduction ................................................................................ 23

7.2 CPD Development Process ........................................................ 23

7.3 CIDT Requirements .................................................................... 25

8. System Architecture ........................................................................ 29

8.1 Introduction ................................................................................ 29

8.2 Analysis ...................................................................................... 30 8.2.1. Functional Specifications ........................................................ 30 8.2.2. MathWorks Modeling .............................................................. 31 8.2.3. Model Representation .............................................................. 31 8.2.4. Simulation Environment .......................................................... 31 8.2.5. Generic and Application Specific Generators ......................... 31 8.2.6. Generic and Application Specific Binder ................................ 32 8.2.7. Generic and Application Specific Target ................................ 32

9. System Design .................................................................................. 33

9.1 Introduction ................................................................................ 33

9.2 CPD Model ................................................................................. 33

9.3 CPD Declaration and Definition................................................ 34

9.4 Blocks ......................................................................................... 34 9.4.1. Action Block ............................................................................ 34 9.4.2. Modeling Block ....................................................................... 35 9.4.3. Data Block ............................................................................... 35 9.4.4. Composite Block ..................................................................... 35

10. Verification ................................................................................... 37

10.1 Introduction ............................................................................ 37 10.1.1. Wafer Lift System Calibration ............................................... 37 10.1.2. WLS CPD Application Instance ............................................ 38

xi

11. Conclusions ................................................................................... 41

11.1 Results..................................................................................... 41

11.2 Lessons Learned ..................................................................... 41

12. Project Management .................................................................... 43

12.1 Introduction ............................................................................ 43

12.2 Work-Breakdown Structure (WBS) ......................................... 43 12.2.1. Activity-Cost Estimations ..................................................... 43

12.3 Project Planning and Scheduling ........................................... 45 12.3.1. Gantt Charts ........................................................................... 46

12.4 Earned-Value Analysis ........................................................... 47

12.5 Conclusions ............................................................................ 47

13. Project Retrospective ................................................................... 49

13.1 Introduction ............................................................................ 49

13.2 Personal Retrospective ........................................................... 49

13.3 Design opportunities revisited ................................................ 50

Glossary ................................................................................................... 51

Bibliography ............................................................................................ 53

References ............................................................................................. 53

About the Authors .................................................................................. 55

xiii

List of Figures [All figures in the report should be numbered and should have an appropriate

title.]

Figure 1 – Stakeholder Analysis Graph ................................................................. 3 Figure 2 – CPD Application Development V-Model ............................................ 7 Figure 3 – Number of CPD applications – annually .............................................11 Figure 4 – Components and CPD dependancies ...................................................12 Figure 5 – CPD Development Process organization .............................................13 Figure 6 – CPD Application Block Domain Diagram ..........................................16 Figure 7 – CPD Application Domain Diagram.....................................................17 Figure 8 – CPD Application Development Process ..............................................23 Figure 9 – High Level System Architecture .........................................................29 Figure 10 – Detailed System Architecture ............................................................30 Figure 11 – Functional Domains ..........................................................................30 Figure 12 – MathWorks Modeling: Matlab & Simulink ......................................31 Figure 13 – Madel Representation ans Simulation ...............................................31 Figure 14 – Binders ..............................................................................................32 Figure 15 – Generic Targets and ASML spceific CPD Execution Environment ..32 Figure 16 – CPD Model ........................................................................................33 Figure 17 – Types of Blocks .................................................................................34 Figure 18 – Composite Block Details ...................................................................36 Figure 19 – Wafer Lift System .............................................................................37 Figure 20 – Simplified Simulink model of WLS ..................................................37 Figure 21 – Measure Composite Block Visual Representation ............................38 Figure 22 – Process Data Composite Block Visual Representation .....................39 Figure 23 – Verify Composite Block Visual Representation ...............................39 Figure 24 – Initial Project Plan .............................................................................46 Figure 25 – Work Progress through time ..............................................................47

xv

List of Tables [All tables in the report should be numbered and should have an appropriate title.]

Table 1 – Stakeholders’ Analysis Table ................................................................ 3 Table 2 – OOTI Project Requirements .................................................................10 Table 3 – Users .....................................................................................................17 Table 4 – System Requirements List ....................................................................25 Table 5 – EPins Calibration Data .........................................................................38 Table 6 – Report Based WBS ...............................................................................43 Table 7 – V-Model activities and key dates .........................................................45 Table 8 – Constraints ............................................................................................45

xvii

Change History

Date Version Changes

Jan-15 0.00 Document Initialization

Feb-26 1.00 Introduction – Context

Stakeholder Analysis

Mar-16 1.01 Problem Analysis – Context, Stakeholders, Design Opportunities

Domain Analysis

Jun-8 1.02 Title

Domain Analysis - Current Situation (rewritten), One Stop Shop, Users,

User Stories (partial)

Review

Structural changes:

-Remove Feasibility, Implementation, Deployment

-Add subchapters titles

Jun 15 1.03 User Stories: (finished) CPD Development,

Structural changes: Bring back Feasibility, Add Business Case

Feasibility: Issues and Risks

System Requirements: Process

System Architecture: Figure

System Design: Figure

Jun 22 1.04 Problem Analysis: OOTI Project Requirements

User Stories: (finished) CPD Maintenance, Block Design, CIDT Support

System Requirements: Refine Requirements List

System Architecture: Introduction, Analysis

Problem Analysis: Roadmaps

Business Case: CPD development history

System Design

Verification

Structural changes: Add Verification

Review feedback applied

-Marcel’s based on half way v.1.04

-Tim’s based on v.1.03

Aug 2 1.05 Executive Summary

Conclusions: Results and Lessons Learned

Outline

Abstract texts: Introduction, Problem Analysis, Business Case, Domain

Analysis, Feasibility Study,

Stakeholders: Functional Organization and Technical Partners (Rewritten)

Project Retrospective

Review feedback applied

-Teun’s based on half way v.1.04

Aug 7 1.06 Project Management

Review feedback applied

-Judy’s based on half way v.1.04

Aug 8 1.07 Preface

Acknowledgements

Abstract texts: System Requirements, System Architecture, System Design,

Verification, Conclusions

Aug 11 1.08 Glossary

Bibliography

Add ISBN

Review feedback applied

-Wouter’s based on v.1.06

-Tim’s based on 1.06

Aug 13 1.09 Final Review

Aug 18 1.10 Foreword

1

1.Introduction

ASML develops lithography scanners that are designed to deliver high throughput,

measured in wafers per hour, at an exposure precision of nanometers. To achieve

this, ASML developed a complex system that incorporates state of the art technology.

The CPD (Calibration, Performance, and Diagnostics) applications, which are the

topic of this report, are ensuring the accuracy and the high throughput of the system.

However, the design and development process of this software is very time consum-

ing.

1.1 Context

An ASML lithography scanner consists of complex high-tech hardware with many

mechanical parts and software that is able to control it. The mechanical parts can

achieve measurement precision up to micrometers. The machine has to be calibrated

in order to compensate for both the mechanical imprecisions and the impact of wear

and environmental influences. In addition, ASML machines must operate within the

agreed with each customer specifications. This requirement leads to performance

measurements in order to qualify the machines.

Since a lithography scanner is such a complex system, locating the root cause of a

problem is very difficult. Therefore, diagnostic applications are performed to locate

machine problems and ensure the minimum delays before the production starts again.

Due to the number and the complexity of these applications, these complicated tasks

cannot be performed within specified time by production engineers. As a result, an

extensive set of CPD applications has to be developed. Even though the process of

developing and maintaining these applications results in high quality software, it is

not very cost efficient.

CPD applications are a result of a need at the functional level of the machine and

they are used throughout the whole production cycle of a machine. Due to the fact

that the CPD functional developer teams do not incorporate software skills, these

requests end up at the appropriate software team. It is estimated that there are more

than a thousand CPD applications and one new CPD application is requested every

week. All these CPD applications have to be maintained by a relatively small group

of software engineers. A CPD application can be very complex and needs deep do-

main knowledge for someone to understand it. Typically it results in a delivery-lead

time of three to six months.

This study is about investigating alternative CPD application development processes

that may result in higher efficiency and faster lead time. CPD applications share

much similarity in terms of functional actions that have to be performed, according to

ASML engineers. The vision is to develop a modular kit, which will enable a CPD

designer to construct a CPD application in a dramatically reduced amount of time,

using stable and predefined building blocks. These blocks should be functionally

connected through a Graphical User Interface (GUI) to structure the CPD application.

In addition to the application behavior, the system should provide functionality to

generate the end-user GUI and the CPD application’s reports according to ASML

standards. Moreover, a building block should allow certain calculations to be execut-

ed in another system, such as Matlab. Finally, this newly proposed system should be

able to generate code, which is able to be executed into the targeted ASML machine.

This vision came to life with the CPD Integrated Development Toolkit (CIDT) initia-

tive.

A CIDT has the potential to significantly benefit ASML, in terms of efficiency,

productivity, and cost reduction. The main advantage is the reusability of these build-

ing blocks and as a result the total effort of developing a new CPD application will

2

eventually decrease. Reusing existing blocks means that the CPD functional develop-

ers can use multiple times certain components and they will not have to create them

again. This will result in a considerably lower lead time. Another important ad-

vantage is that engineers from the functional organization will be able to develop

CPD applications due to the separation of software from functional concepts. Finally,

every building block will encapsulate the subsystem’s knowledge of the technical

know-how. Then, the total number of interfaces provided to the CPD software devel-

opers will be reduced, and as a result, it will allow a possible outsourcing of the de-

velopment.

1.2 Outline CPD applications are based on a sequence of actions performed on an ASML ma-

chine followed by a series of complicated mathematic algorithms. It is believed that

the process of developing the CPD software can be automated. The following chap-

ters are guiding the reader to this conclusion.

The second chapter presents all the different stakeholders and explains their interest

over the project. The third chapter gives an analysis of CPD applications and explains

the reasons why the CPD development is time consuming. The fourth chapter is ded-

icated in the business case to support the CIDT initiative. The fifth chapter deals with

the CPD application domain and present the different stakeholders approaches on the

development process. In addition, four user stories on the CIDT are presented on that

chapter. The sixth chapter presents the potential issues and the risks during the devel-

opment and usage of the CIDT. The seventh chapter gives the basic system require-

ments of the new tool and presents the new proposed CPD development process. The

eighth chapter places the purpose of this project into the big picture of the CIDT ref-

erence architecture and gives a brief description of its other parts. The ninth chapter

holds the model of the proposed domain specific language for the functional descrip-

tion of a CPD application. Finally, the tenth chapter shows an example of CPD appli-

cation using the proposed language. ■

3

2.Stakeholder Analysis

Stakeholder analysis, in project management, is the process of identifying the indi-

viduals or groups that are likely to affect or be affected by a proposed action. This

information is used to assess how the stakeholders' interests should be addressed in a

project plan. Stakeholder analysis is a key part of stakeholder management and con-

sists of weighting and balancing all of the competing demands. A stakeholder analy-

sis does not preclude the interests of a stakeholder’s subset, but it ensures that all

affected will be considered.

2.1 Introduction Since CPD applications are used throughout the whole production cycle of an ASML

machine, it is reasonable to involve many different stakeholder groups.

The following analysis is based on two dimensions: power and interest. On the one

hand, the interest of a stakeholder is measured with respect to the priorities set by

each stakeholder group. On the other hand, power is in relation to whose decision is

going to affect the progress and the status of this project more.

Table 1 – Stakeholders’ Analysis Table

Stakeholder Wpower Power Winterest Interest

Trainee 8 high 10 strong

TU/e 9 high 9 strong

ASML 9 high 8 strong

CPD Software Developers 5 medium 6 medium

Functional Development Organization 7 medium 7 medium

Concerto Program 3 low 7 medium

CPD User 1 low 1 weak

Management 10 high 3 weak

By taking into consideration Table 1 weights, Figure 1 is produced:

Figure 1 – Stakeholder Analysis Graph

4

2.1.1. Analysis

Trainee The main interest of the trainee is to graduate the OOTI program. In addition, he is

interested in designing a high quality system that will be able to solve the current

problem that ASML is facing during the development of a new CPD application.

Finally, the trainee intends to create a network of people working in and out ASML

to help him develop towards a potential future career at the company.

TU/e The Professional Doctorate in Engineering (PDEng) degree program in Software

Technology (OOTI) provided by the Department of Mathematics and Computer Sci-

ence of Eindhoven University of Technology in the context of the 3TU.School for

Technological Design, Stan Ackermans Institute is a two-year post-masters education

and training program in advanced software engineering with a strong emphasis on the

design and development of software for resource-constrained software-intensive sys-

tems such as real-time, embedded, or distributed systems. This industrial design and

development project is part of the trainee's education and training program. Such

projects are fixed-date, fixed-price, and they aim to support a high-quality software

engineering process and product design.

ASML (CPD Technical Competence Team CPD -TC) The main interest of ASML is to receive a high quality system design that meets the

initial project description. CPD Technical Competence covers the development of

CPD applications in the most effective way by thinking of how to specify, design,

and realize CPD applications. Moreover, it defines the means and methods, comes up

with a clear vision and roadmap that are aligned with ASML business. This project is

part of the competence’s roadmap. Due to the limited time of its members, the com-

petence team delegates the feasibility study to the CIDT initiative. The members in-

tend to support the trainee during the project and guide him to gather all the neces-

sary information needed for the study.

CPD Functional Engineers The functional development organization consists of engineers, who are the main

designers of the CPD applications. In addition, an ASML machine is divided in mul-

tiple functional clusters, which deal with a different aspect of it. Each functional clus-

ter incorporates engineers with different competencies, such as Mechatronics, Phys-

ics, Chemistry, Mathematics, etc. These engineers have a high technical and scien-

tific background and a deep knowledge in ASML’s domain. As a result, they are a

very important asset for ASML. However, they lack on software skills, which are

needed in order to develop a CPD application with the current process. A CPD appli-

cation consists of measurements, which are not a simple process to communicate to a

person without the domain knowledge. Thus, multiple iterations are needed to finish

the design of a single CPD application. As a result, valuable budget time is spent by

the functional engineers on putting extra effort to explain the CPD application’s do-

main to the software engineers. The functional development organization is looking

forward to a technology that would allow its engineers to design CPD applications

without the need of software skills. As a result, it should be the center of attention

during the design process of this project.

5

CPD Software Engineers Almost one third of software development's software engineers are working on the

development of CPD applications. Their main responsibilities are the translation of

functional requirements to software requirements and the implementation of the CPD

application itself. With the current way of working, they struggle a lot during the first

phase, i.e. the one of understanding the domain. This knowledge gap makes the pro-

cess of conversion very difficult and sometimes the results are not correct, which

leads to multiple iterations and interactions with the functional organization. Alt-

hough a very experienced CPD software developer has already bridged this gap,

there are no written guidelines. This knowledge comes by professional experience.

Technical Partners – Concerto Program ASML is the world's leading provider of lithography systems for the semiconductor

industry, by manufacturing complex machines that are critical to the production of

integrated circuits or chips. In order to achieve this, ASML has a very deep

knowledge in the underlying science and engineering. However, ASML has many

different external suppliers, mainly for management reasons. The Concerto program

is contributing in funding the CIDT initiative’s feasibility phase, which is going to

start in parallel towards the end of the orientation phase. Thus, the results of this pro-

ject are very important for them, since they are their main input.

CPD Users CPD applications are involved throughout the whole production cycle of a machine

both at ASML's facilities and the customer's site. The production cycle consists of

three phases: development, manufacturing, and field service. CPD users need a sim-

ple interface, which allows them to extract all the necessary information with as little

effort as possible. The GUI and the produced reports of CPD applications have been

standardized and they are very unlikely to change because the CPD users have been

using them for a long time. Their training to a potential new GUI or report style is

expensive.

Higher Management Higher management is interested in maintaining the success of the company by guid-

ing the daily work around the production line. A dramatic change in any product is a

high risk. Therefore, management needs very convincing arguments to proceed with

such changes. A strong business case based on facts is the key to motivate them allo-

cating budget to the project. ■

7

3.Problem Analysis

Every problem arises from the needs of its stakeholders. As such, the main stakehold-

ers of a CPD application are its designers and developers and they are not satisfied

with the current way of working.

3.1 Introduction A large organization such as ASML needs formal processes to minimize the risks in

their product development. These processes can be quite demanding and have to in-

volve a very formal procedure. The CPD development follows a strict process as

well.

A very common approach in software engineering is the V-Model methodology,

which is used in the CPD application development. The functional engineers describe

the functional requirements of a new CPD application and how to test its validity.

Then in collaboration with software engineers, they produce the software require-

ments and their testing requirements as well. Next, software engineers produce the

implementation code based on the requirements they receive. Finally, they proceed

with the validation and verification against the initial requirements. This process,

even though it is effective, is not efficient because of the large number of changes-

requests and the extra resulting lead time.

Figure 2 – CPD Application Development V-Model

The problem of this process is the translation of functional requirements to software

requirements. Every step needs a significant amount of resources, in terms of man

hour. A software engineer needs a lot of effort to understand the science behind the

CPD application in order to accurately create the software requirements. This re-

quirements’ translation is known as the knowledge gap between the functional and

the software organization. A CPD application may take from three to six months be-

fore it is delivered to the functional organization.

A derived effect of this lead time is that the CPD application might not pass the vali-

dation tests when it is delivered to the functional organization. As a result, a new

development cycle begins. The main problem here is that sometimes the functional

development organization starts the design of a new CPD application, which requires

its focus on it. When the CPD software engineers deliver the CPD application, some-

times it is not what the CPD functional engineers expected. So, they have to stop the

design process of the new CPD application and focus on to the previous one. This

leads to low productivity on both the functional and software organizations.

Another aspect of the CPD development process is that the CPD software engineers

expect the CPD functional engineers to consider some basic software knowledge in

their design. An example of software knowledge is the division by zero exception,

8

which is not described in a typical happy flow scenario mathematical algorithm. On

the other hand, the functional organization puts a lot of effort in describing the CPD

application so that it is understandable by the software engineers. This approach

keeps the focus of each discipline away from their real challenges and ends up as a

lot of extra work to their daily jobs.

There have been various attempts to solve the problem noticed in the CPD applica-

tion development. These attempts involve processes and tools to be used by both the

functional and software organizations. The main disadvantage in these attempts is

that they were software engineering oriented solutions. They were designed by CPD

software engineers to solve software engineering problems and not solving the

knowledge gap issues.

There is a solution that brings together the functional and the software CPD engi-

neers and divides the CPD development process into several steps. However, that

requires engineers from both sides to closely cooperate in the development of a sin-

gle CPD application. This is a well described solution, but due to the fact that all em-

ployees have a very busy schedule, it is almost impossible to synchronize their agen-

das to work together. As a result the software engineers use the provided tools in

order to be compliant with the process, but without using the full collaboration poten-

tials that these tools could offer.

The vision of the CIDT is to eliminate the knowledge gap between the functional and

the software CPD engineers. The development of a CPD application ideally should

be done directly at the functional level, without the need of any software knowledge.

The software engineers will not participate anymore in the CPD application devel-

opment process but they will develop only the tools needed for this process. This

approach separates the two disciplines and each one can focus on their domain by

using tools that they already are familiar with. On the one hand, the functional devel-

opment organization is already familiar with the MathWorks environment and on the

other hand the CPD software developers are familiar with the software engineering

oriented tools.

3.2 Roadmaps To make the CIDT into reality the following seven phases have been identified: Ori-

entation, Feasibility, Demonstration, Prototype, Industrialization, Rollout, and Life-

time Support phase.

3.2.1. Orientation Phase

The main objective of the Orientation phase is to create a map of the CPD develop-

ment domain. In addition, this phase defines the innovation, the project success fac-

tors, and key objectives.

During the orientation phase, the CPD development domain should be made clear

and well documented. It will be the initiation of the CIDT project. This project is part

of the orientation phase and it intends to present to the stakeholders an understanding

of CPD development domain. In addition, a first order requirements list and a prelim-

inary zero-order business case analysis are the fundamental deliverables.

3.2.2. Feasibility Phase

The main objective of the Feasibility phase is to analyze and expand in further details

the requirement list. In addition, this phase will produce a prototype, which intends to

show the feasibility of the CIDT project.

During the feasibility phase, there will be three different investigations. The first one

will be a domain specific language of the functional representation of the CPD appli-

cation development. The second one is the investigation on the MathWorks tools and

9

how they can be potentially used. The third one is looking the CPD application from

the targeted platform approach. At the end, the objective is to create mappings be-

tween these three investigations; from the functional specification, to the MathWorks

representation, and finally to the targeted platform.

As far as it concerns the first investigation, since this project is its main input. The

investigation is going to be performed into the following context. After the creation

of the functional CPD domain specific language, a small – but representative – set of

CPD applications will be validated against it. If it is necessary, there will be adjust-

ments to the language in order to satisfy the set of CPD applications. The next step is

to expand the set of CPD application in order to handle more complex cases.

The main deliverable of the feasibility study will be a verdict of continuing with the

CIDT project or not. In addition, the deliverables will contain a detailed representa-

tion of each investigation and the mappings between them.

3.2.3. Demonstration Phase

The demonstration phase intends to create a CIDT demo for the functional engineers

to use and provide feedback. The demonstrator does not necessarily be complete,

which mean that several parts of it can be implemented in other environments than

MathWorks. The purpose is to demonstrate the basic features and receive the feed-

back of the end users.

3.2.4. Prototype Phase

In the prototype phase, all CIDT components have to be integrated in the MathWorks

environment. The produced software has to present all the basic functionality to its

users.

3.2.5. Industrialization Phase

The Industrialization phase targets to create high quality software that meets all

ASML’s standards. Extensive tests to prevent major bugs will be performed.

3.2.6. Rollout Phase

The rollout phase is the transition between the old CPD development process and the

CIDT. The strategy for the rollout phase is defined in the previous phases, where

certain functional engineers will be involved to spread the knowledge under the guid-

ance of the CIDT support team.

3.2.7. Lifetime Support Phase

A very important phase of every project is to provide support after the initial devel-

opment. During this phase, the development team will be in charge of bug solving

and new features developing.

3.3 Stakeholders The proposed solution will benefit all major-concerned stakeholders: the functional

organization, software engineers, and management.

First of all, the CPD functional engineers will be in control of designing and imple-

menting new CPD applications. The design will be limited at the functional devel-

opment organization and the software would be automatically generated. The goal is

to reach the level of completely abstracting the software skills from the functional

design of a CPD application. Moreover, due to the fact that the functional engineers

will implement the CPD application they will be able to test it and validate it accord-

ing to their requirements immediately. Any required changes will be done on their

design and new software will be generated. Finally, their focus will remain on the

domain specific aspects and not on the process they have to follow.

10

Second, software engineers will no longer be involved in the CPD application devel-

opment and as a result, there will be no need for them to struggle with the knowledge

gap they face today. Their focus will be mainly on software engineering challenges

and not on trying to understand and optimize the functional requirements.

Finally, management will mainly benefit in their budget. Due to the fact that a CPD

application development will not involve software engineers anymore, they can allo-

cate software engineers to other projects, such as the maintenance of the CPD devel-

opment tools. The separation of the CPD-development and the development of CPD-

development tools will result in a more efficient usage of the available budget.

3.4 Design Opportunities The main design opportunity here is to create a simple and elegant design in spite of

the system complexity. In addition, the goal of this project is to prove that a separa-

tion of the functional and software organization can work. This leads to a design that

it is realizable and generic enough to prove its goal. After all, the impact will be the

turning point of modernizing many of the current ASML processes.

3.5 OOTI Project Requirements In coordination with the company supervisors, the OOTI project requirements were

set as presented in

Table 2 – OOTI Project Requirements

Id Requirement Priority

PR.1 Collect first order requirements Must Have

PR.1.1 Inform the CPD functional engineers about the CIDT ini-

tiative

Should have

PR.1.2 Collect the CPD functional engineer needs around the

CIDT

Must have

PR.1.3 Create a map of all the Functional Clusters that make us-

age of CPD applications

Could have

PR.1.4 Describe the process of creating a CPD application Must have

PR.2 Demonstrator Should have

PR.2.1 Create a Domain Specific Language for the functional

specification of a CPD application

Should have

PR.2.2 Design a mockup of the look and feel for CIDT Would not

have

PR.3 Business Case Should have

PR.3.1 Describe a process of extracting CPD information data

from the code archive

Should have

PR.3.2 Business Case Analysis Should have

■

11

4.Business Case

Based on the CPD application development process’s bottleneck, which is the trans-

lation of the functional to software requirements, the business case tries to investi-

gate the impact of removing the software engineers of the core CPD application de-

velopment.

4.1 Introduction Many ideas have failed to come to life because they were not supported by a strong

business case. A business case is an argument that is intended to convince manage-

ment to approve an action. It consists of facts that present the need for the proposed

action and show the upcoming benefits.

This business case is based on a zero order approximation analysis in which each

observation is independent of all previous observations in creating a new CPD appli-

cation framework. This means, that it will not include all the necessary parameters

and it gives an indication of either continuing to the next phase or not. The analysis

will be based on the CPD development history and the CPD development forecast.

4.2 CPD development history It is well known among the software and functional CPD engineers the fact that there

are many CPD applications. However, there is no concrete number available and as a

result a deeper investigation needed to be done. If someone looks at the code base, he

will probably find less CPD application than the total number that have been devel-

oped until today. The main reason is because throughout the different releases, cer-

tain CPD applications were removed or modified.

The investigation extracts historical data from the code archive. The zero order anal-

ysis was performed first to get an insight on the CPD application trend line. AQBL

baseline was chosen from a five year span, in order to get the total number of CPD

applications that it consists. The number of CPD applications could not be easily

accessed and as a result, scripts were created in order to get an accurate number. Fig-

ure 3 shows the total number of CPDs in software releases throughout the years, the

number of CPD applications that have been added and removed since the previous

sample.

Figure 3 – Number of CPD applications – annually

12

Although the number of CPD applications is an important sign of the CPD develop-

ment effort, it is not enough, because it shows only the quantitative characteristics

and not the quality ones. The next step is to look at the last release and find depend-

encies between the CPD applications and the other components. The investigation

shows how many CPD applications depending on other components. The result on

Figure 4 is that there are many components designed only for a small number of CPD

applications, as expected.

Figure 4 – Components and CPD dependancies

4.3 Analysis This analysis is based on data collected during the investigation and discussions with

ASML employees. The zero order analysis from Figure 3 shows that about 100 new

CPD applications are added every year to the repository. The estimated cost of a sin-

gle CPD application is about 50 thousand euros, based on the average duration and

the amount of employees involved.

The zero order investment analysis is based on the assumption of having the CIDT

framework immediately. The objective cost of a CPD application should be reduced

by a factor of ten. Moreover, there is an additional cost of supporting the CIDT

which is estimated to be ten full time employees. By setting the goal of breaking even

on the investment after five years, it results to an investment of more than 15 million

euros.

4.4 Value Chain and Business Processes ASML has three layers to describe its business processes, from which only two of

them directly incorporate the CPD applications. The main goal of ASML is to sell as

many lithography systems as possible. As such, the first layer is the primary business

process, which is the production and sales of Lithography solutions. The next layer is

the secondary business process, which targets the development of these lithography

solutions. CPD applications are part of the product development and as such they

belong to the second layer. Finally, the third layer is the tertiary business process,

which includes all the supporting mechanism for the second layer.

The CIDT can be placed directly to the third layer, since it is under the umbrella of

the Development Tools and Infrastructure. In addition, the usage of CIDT is going to

support the development of lithography solutions. By meeting the target of reducing

the delivery time of a single CPD application, there is an indirect positive impact in

bringing a lithography solution faster in the first layer and as a result an ASML ma-

chine can be delivered faster to the customer. ■

13

5.Domain Analysis

The most important step on creating a new product is to understand the user’s needs.

In order to achieve this, it is essential to understand their domain and communicate

the same language with them.

5.1 Introduction An ASML machine is a very complicated machine that incorporates very precise

actions for measuring and exposing wafers. Despite the mechanical constraints of

micrometer precision measurements, ASML is able to expose in nanometer precision.

In order to achieve this, a series of applications are performed regularly to make sure

that the machine runs according to its specifications. These applications cannot al-

ways run manually, because the operators do not have the knowledge, it is time con-

suming, and the machine’s down time at both the factory and the customer site is too

expensive. As a result, there is a need of special software, also known as CPD appli-

cations.

A CPD application performs calibration, performance measurements, or diagnostic

applications. A calibration application tunes the machine parameters so that the sys-

tem meets the requirements. A performance application qualifies the machine accord-

ing to the specification. A diagnostic application locates potential machine problems.

A typical CPD application consists of three parts: data acquisition, data processing,

and report generation and/or machine parameter saving. Abstractly, a CPD applica-

tion can be seen as a sequence of steps that need to be executed in order to conclude

to the final measurement. Each CPD application can be either placed in a queue, so

that a set of tests execute sequentially, or not. In addition, a CPD application can ei-

ther request some interaction from the user or not. Finally, every test is initialized and

observed through the GUI, which is standardized and which its operators are already

familiar with. This describes a typical CPD application execution, but this project’s

orientation is on the CPD development process.

5.1.1. Clients and Users

The CPD application development process should define concrete roles for each dis-

cipline. A CPD application can be used by machine operators throughout the whole

machine life cycle. The development of the application should ideally be designed at

the functional development organization by using a set of predefined and stable

blocks. These blocks can be designed either by the CPD functional engineers by

combining already existing blocks or by the CPD software engineers by creating new

primitive blocks. However, the actual implementation should be completely separat-

ed from the functional organization and only the software department should create

the required code generators to automatically transform the primitive blocks to code.

Figure 5 – CPD Development Process organization

14

5.1.2. Environment

The CPD application lifecycle environment needs to be carefully chosen. It is not

about the selected technology, but about this technology being accepted by manage-

ment and the CPD functional engineers.

First of all, CPD applications need to be executed on an ASML machine, but the de-

velopment of the CPD applications should be performed with tools that are familiar

to the functional development organization. Currently they are using MathWorks

tools – Matlab and Simulink – to perform their experiments and prove their algo-

rithms. Based on this fact, the new framework should be compatible with these tools.

On the one hand, there is the CPD application development and on the other hand,

there is the CPD application execution. In between these steps there is the simulation,

which provides valuable feedback to the CPD designer. Based on the idea that the

CPD designer will be a functional engineer, simulation should also be performed

using Matlab and Simulink, which are tools familiar to them. Finally, the code gener-

ators and the development of primitive blocks can be implemented in any conven-

tional programming language based on the needs of ASML at that point.

The selection of these tools is mainly based on achieving a solution acceptance

through all levels of the CPD lifecycle. MathWorks already offer a variety of tools

for simulating and generating code for other platforms.

The one stop shop Due to the fact that CIDT is intended to be an integrated environment for the CPD

functional engineers, the one stop shop concept applies. The term one stop shop is

meant to describe a location where various requirements can be met in one place.

This is a business model that has become commonplace. The theory is that, by

providing many services in one place, users get the convenience of obtaining their

needs in one stop. This is the reason for introducing the word “Integrated” in the

CIDT.

Integration means a seamless environment in which the CPD functional engineers

will work a CPD application. The chosen environment is MathWorks solutions due

to the fact that the functional development organization is already familiar with

Matlab and Simulink. With the provided tools the CPD functional engineers will be

able to perform all the necessary activities during the CPD development lifecycle.

5.1.3. Current Situation

CPD application development is a well-defined process and it delivers high quality

products. It involves people from both the functional and software development or-

ganizations. Due to the complexity and size an ASML machine there is a huge

knowledge gap between these two organizations, which leads to a time consuming

process in order to achieve the desired product.

The current process starts when a functional architect wants to introduce a new fea-

ture to an ASML machine. This can be either a new part or a new functionality. The

functional architect discusses the potential challenges in the design with one of

his/her functional engineers. Then, the latter starts to perform the initial investigation.

The investigation consists of a data collecting phase and modeling phase. The func-

tional engineer collects data from the machine by using Advanced Diagnostic Tools,

also known as ADTs, by creating a Python script to execute on the real hardware, or

by collaborating with a software engineer to implement the desired functionality. In

the modeling phase the functional engineer tries to use the collected data in order to

model the desired behavior of the new feature. These two phases usually are com-

15

pleted after multiple iterations until the functional engineer comes to a conclusion on

the feasibility of the development of the new feature. At that point, he/she will dis-

cuss the outcome of his/her investigation with his/her functional architect.

The next step is to include the CPD application into a project and therefore the func-

tional architect meets with the group and the team leaders to negotiate budget size.

When they reach an agreement, the process of CPD application development can

start.

The formal specification of a V-model, described in Figure 2, indicates that the func-

tional specifications must be ready before the software specifications. However, this

is not the case for the CPD development because sometimes the initial simulations

are totally different from the actual data collected from the real hardware. The CPD

development consists of three phases where the functional and the software engineers

have to work together: the data acquisition, the data processing, and the reporting

phases.

In the data acquisition phase, the CPD functional engineer describes how the data are

being collected, in other words, which components have to perform an action and

which sensors have to collect data. In addition, the format of the data is also de-

scribed in this phase by the functional engineer. Then, the software engineer converts

these functional requirements into software requirements and implements a part of

the software, which is returned to the functional engineer in order to proceed with the

next phase.

In the data processing phase, the CPD functional engineer has to convert the collect-

ed data to a valid format for his/her Matlab code. Next, he/she is working on model-

ing these data based on the investigation phase. At the end he/she produces an algo-

rithm, which is provided to the CPD software engineers. The typical scenario is that

the software engineers implement these algorithms using a Python framework. But in

some cases, software engineers embed the Matlab algorithm in Python by defining

the appropriate interfaces. When this data processing software part is ready, it is re-

turned to the CPD functional engineers in order to proceed to the next phase.

In the reporting phase, the CPD functional engineer selects which data has to appear

in the report and in which sequence and formalizes the rest of the CPD functional

specifications. The software engineer converts these to software requirements and

implements the CPD in Python. In addition, in this phase the GUI is completed, the

log files are defined, and the CPD application is completed in order to proceed to the

testing side of the V-Model.

The right side of the V-Model is dedicated to testing. First, the software engineers

test the CPD application to meet all the software requirements according to the test

plan and they produce a report. Next, the CPD functional engineers qualify the soft-

ware against the functional requirements according to the test plan and they also pro-

duce a report. When the CPD application is qualified, then it can be included to CPD

collection.

This process can easily take on average more than five months of development be-

cause of multiple iterations between the two organizations. Even though this process

has been significantly improved with the usage of smarter and better software

frameworks, they do not solve the knowledge gap issue that is responsible for long

lead delivery time. To summarize, the CPD functional engineers describe in docu-

ments, supported by Matlab algorithms what they want to implement and the CPD

software engineers develop the requested CPD software.

16

5.2 The block approach One of the CPD Integrated Development Toolkit’s benefits is the reusability of the

CPD functional engineers’ designs. In order to achieve this, the toolkit is based on

the block concept. A block represents a simple or more complicated function or ac-

tion that needs to take place on the machine. A simple example is to move a mechan-

ical part from one point to another.

To begin with, as the block becomes the core of this design, it needs to be carefully

designed with not many constraints and with future extensibility in mind. The primi-

tive blocks consist of typical read, process, and write actions. In addition, there are

blocks to denote the start and the end of an execution sequence, which is also known

as an algorithm. Based on the concept of reusing the existing blocks, there is a need

for simple and composite blocks. The latter contains other blocks inside them and

describes their execution sequence as well.

The execution sequence represents how these blocks are connected between their

ports. Now that the port is already defined, a new conditional simple block can be

introduced by owning an additional port to alternate the execution flow. This gives

the opportunities for more complex blocks such as loops.

A very important aspect is to allow designers and operators to trace data changes

along the CPD execution. Data can be either machine parameters that need to be set

very carefully, values to be written in diagnostic and report files, or even temporary

data that are used to assist the calculations. So every block might need some data as

input and it might affect some other data during its execution.

Finally based on the fact that a CPD application is a sequence of steps, it is safe to

say that it consists of only one composite block. The CPD designer can include as

many blocks as he/she thinks are necessary to build the desired algorithm by using

smaller or more complex blocks.

class Domain Objects

Block

Composite Simple

Port Read Process WriteStart End

Condition

CPD

Data

Sequence Connector

+entry+exit

+exit_false

+child

*

1

+affected

+input

1

*

+source

+target

Figure 6 – CPD Application Block Domain Diagram

The above scenario describes the block concept inside the CPD domain and is visual-

ly presented in Figure 6. Figure 7 shows the connection between the CPD application

world and the ASML machine. The only desired dependency should be on specific

blocks and in the lowest level. This will allow a decoupling from the CPD applica-

tion domain and the ASML machine specific concepts.

17

Figure 7 – CPD Application Domain Diagram

5.3 Users - Actors The CPD application domain has several user categories, which are enlisted in Table

3.

Table 3 – Users

Category Description

Functional architects They are responsible for guiding the functional engi-

neer on the new introduced features

CPD functional engi-

neers

They are responsible for designing the CPD applica-

tion

Block designers They are responsible for designing the required

blocks with the proper level of abstraction. This role

is a new one

Support Team They are responsible for supporting the users of the

CIDT. This role is a new one

5.4 User Stories This section describes a set of the CIDT’s user stories, which have been identified

from the first order analysis. The purpose of these user stories is to give a brief de-

scription on the envisioned daily work of the CPD application developers.

5.4.1. CPD Development Design

The CPD application development design must be a very well defined process in

order to be predictable, quantifiable, and manageable. The development consists of

seven different parts.

The first part is the design. The CPD functional engineer creates the infrastructure to

get the user’s inputs and assign them to the CPD application data variables. These

variables are going to be used during the CPD execution. The GUI design should be

an easy process based on templates and drag and drop components, in order to mini-

mize the total effort spent on this step.

18

The second part is the preparation of the CPD application. Here the CPD functional

engineer selects the main system’s components, which he/she is going to use in the

CPD application. In addition, he/she sets all the pre-conditions for this CPD applica-

tion, such as loading a wafer.

The third part is measurement. Here the CPD functional engineer describes how the

measurement is performed. In more details he/she describes which components have

to perform an action, such as moving or sensing a trace.

The fourth part is modeling. Here the CPD functional engineer implements the math-

ematical algorithms of the CPD application by using the input of the measurement.

The fifth part is verification. Here the CPD functional engineer selects which data

should be activated as machine constants in order to repeat the measurement.

The sixth part is evaluation. Here the CPD functional engineer selects which data

needs to be checked and with which method – usually a comparison formula is speci-

fied – in order to qualify the CPD application execution.

The seventh part is the tear down of the system. Here the CPD functional engineer

sets all the post conditions of this CPD application. If the application is a calibration

test, then he/she allows the user to save the new values of the machine constants,

which were calibrated.

5.4.2. CPD Simulation

In parallel with the above design procedure, the CPD functional engineer should be

able to simulate his design. The simulation can be either executed locally or remotely

connected to real hardware. This will help the CPD functional engineer to correct

his/her design in an earlier stage. When he/she completes all the phases and the simu-

lation of the CPD application satisfies all the initial requirements, then it is ready to

be integrated with the rest of the CPD applications.

5.4.3. CPD Maintenance

An important part of the CPD application lifecycle is maintenance. In some cases, the

CPD functional engineer finds a better and improved algorithm to perform the meas-

urement and the calculations. In other cases, a CPD application is not compatible

anymore with the new functionality that has been introduced to a machine. In addi-

tion, some of the upgrading solutions are provided via extending the configuration

files. The maintenance process can be completed within the CIDT environment.

Due to the fact that all artifacts are concentrated in the project, the functional engi-

neer can have a good overview of the whole CPD application in one place. This

means that there is no need to look for document files scattered around the organiza-

tion. If this is achieved the documents might not be needed at all because all the in-

formation could be located inside the models that describe the CPD application.

5.4.4. Block Design

A crucial part of CIDT is the correct usage of blocks, which should neither be very

abstract nor very specific. The responsibility of the correct block granularity is on the

Block Designer.

Every team has one engineer to work as a Block Designer. The block designer devel-

ops and maintains the available block libraries used for their team’s CPD applica-

tions. In addition, one of his/her responsibilities is to make sure that every newly

introduced block will cover future needs as well. In order to achieve this, the block

designer needs an overview of the team’s activities and a clear understanding of both

the machine and the CPD Domain.

19

The Block Designer organizes the blocks in libraries, which help the categorization

and the understanding of common functionality. These libraries need to promote the

re-usability of the blocks. As such, the Block Designer constantly observes the block

usage in CPD applications and suggests alternative designs.

When a CPD functional engineer wants to introduce a new block for the system, he

makes a proposal to the Block Designer. The latter investigates the benefits of this

new block and analyzes potential future usages as well. Then he/she might change

the block according to his/her analysis in order to fit better in the block ecosystem.

Finally, the Block Designer has to maintain the interface between MathWorks tools

and the actual implementation on the targeted platform. When the platform’s inter-

faces change, then the Block Designer has to adjust his team’s blocks to maintain the

functionality without breaking existing CPD applications.

In conclusion, the responsibility of the Block Designer is very important, since

his/her skills and knowledge of both the machine functionality and the CPD domain

will provide blocks with the proper level of abstraction.

5.4.5. CIDT Support Competence Team

Every newly introduced system brings a new way of thinking to an organization. As

such, its users might have questions about performing certain tasks or face technical

difficulties. It is important to form a team to be responsible for the CIDT support.

Their main activity is to actively provide technical support with any issue that the

CIDT users face. They will provide the users with technical guidelines and how-to

guides. These engineers are already part of other functional engineers’ teams, so they

participate in their processes and understand the daily problems they face. As local

experts, they will be in constant communication with the block designers and the

software engineering team to make sure that the CIDT is evolving.

Finally, they will meet with the other CIDT Support Engineers to develop the

roadmaps for the future. They will monitor their team’s use cases and analyze the

problems they are facing in order to propose new extensions for CIDT. ■

21

6.Feasibility Analysis

A feasibility analysis aims to objectively and rationally uncover the strengths and

weaknesses of a proposed solution. After understanding the domain, someone can

spot the pitfalls of the organization that can affect the success of a project. It is im-

portant to recognize them and have a mitigation solution ready.

6.1 Issues The CPD Integrated Development Toolkit is an expensive investment. Many similar

attempts in the past have failed because the targeted solution was deviated from the

initial goals. The objective is to develop CIDT by putting the functional engineers in

the center of attention it and to solve a big part of the current problem, which is the

translation of the functional requirements to the software requirements, as described

in Figure 2. A series of issues are recorded in order to be aware of them during de-

velopment.

The introduction of this toolkit will bring a new way of working that needs to be ac-

cepted by its users. The way of working has to be compliant with the company cul-

ture. In other words, any process proposed in this study has to be reviewed by well

experienced employees to make adjustments to fit the company culture.

Another issue that needs to be addressed is the automatic code generation of this

toolkit. The automatic code production will most probably add an overhead to the

final product, compared to hand-crafted code. This is reasonable, due to the fact that

the code generators are based on generic concepts and not specialized for each indi-

vidual case. Thus, in the feasibility study of CIDT will be determined if this overhead

is acceptable according to ASML’s requirements.

Finally, big companies tend to be conservative in changes due to high exposure to

risks. Thus, the CPD application domain could be used as a paradigm shift to prove

that the modern way of working can bring benefit to the organization. By starting

from CPD applications the organization is not facing all the risks from a potential

change in the production line.

6.2 Risks Risk is the potential of losing something of value. The goal of the CPD Integrated

Development Toolkit is to minimize the effort on the CPD application development.

Thus, it suggests removing software engineers from the CPD development process.

This attempt runs certain risks, which should be considered throughout the industrial-

ization phase.

Since only the functional development organization will be involved in the CPD ap-

plication development, there is the risk that they will not accept the provided solu-

tion. This might be because of the extra work that they will have to do in order to

deliver a complete CPD design. However, the total effort spent should be less, since

they will have to produce less documentation, because it will be auto generated by

the toolkit. The purpose of the documentation is to give an overall description of the

CPD application to the functional and production engineers.

Another risk is that the CPD functional engineers will not be able to fully understand

or accept the provided toolkit. Even though the vision is to totally separate the soft-

ware elements from the functional design, this might not be completely achieved. As

a result, the toolkit should be accompanied by best practices guidelines, which might

be out of the functional engineering scope.

22

Next, the auto generated code will most probably have overhead and it might not

meet the performance requirements. This means that the CPD functional engineers

will have to put effort on creating better designs, based on guidelines and best prac-

tices principles. However, the fact that the software aspects will be abstracted, this

might not be possible and leads to the last identified risk, the level of abstraction

Finally, it is very important to set the right level of abstraction on the functional ac-

tions that can be performed. The granularity of blocks can lead to different levels of

detail. If the toolkit provides very abstract blocks, then the CPD functional engineers

are not able to implement their designs and they have to find workarounds, which

leads to frustration and system dissatisfaction. On the other hand, if the toolkit pro-

vides a very detailed representation of the blocks, then the CPD functional engineers

have to do the software engineering job and find the best sequence of blocks to im-

plement the functional block. As a result, instead of using Python as a programming

language, the CPD application is developed with Matlab and Simulink.

These are the risks that have been identified during the orientation phase and should

be addressed in the next project’s phases in order to mitigate them as soon as possible

during the CPD Integrated Development Toolkit’s development cycle. ■

23

7.System Requirements

The translation of the functional requirements to the software requirements is the

main objective of this project, but for the CPD applications domain. This chapter

translates the needs of the CPD functional engineers into system requirements.

7.1 Introduction One objective of this project is to perform a first order requirement and constraint

investigation around the CIDT. This investigation is the input for the next phase, the

feasibility, of the CIDT project. The CIDT process is described along with the re-

quirements list because they are tightly connected.

7.2 CPD Development Process The proposed process is based on the CPD application lifecycle and the input from

the functional development organization. The process consists of six phases, which

are overlapping, and starts when a functional architect wants to introduce a new fea-

ture to an ASML machine. Figure 8 presents an overview of the proposed process,

which is described below in more detail.

The first phase is the investigation of the new feature and starts when a functional

architect discusses it with one of his functional engineers. The latter starts his/her

investigation with data collection from the real hardware. This can be done either by

simulating the behavior of it or remotely connecting to real hardware; in both cases

use MathWorks tools. Here the functional engineer describes which components

should move and what signals he/she wants to trace. Next, he/she starts working on

modeling the new feature with the collected data and applies them to the machine.

This sequence of collecting, modeling, and applying data is performed in multiple

iterations. During these iterations, the functional engineer uses tools to visualize the

collected data and compare them with the previous attempts. If the investigation

Figure 8 – CPD Application Development Process

24

phase concludes that the feature is not feasible around the proposed solution, then the

functional engineer points out to the functional architect that they have to find anoth-

er solution. However, if the investigation phase concludes that the feature is feasible

in a reasonable amount of time spent and is beneficial for the machine operations,

then the functional engineer presents a functional requirements checklist to the func-

tional architect. This functional requirements checklist is the input for the design

phase.

In the design phase, the functional engineer describes all the formal specification of

the new CPD application. This phase overlaps with the simulation phase, which al-

lows him/her to verify at any time if his/her design is correct. The following steps are

guidelines to complete a CPD application but they are not necessarily meant to be

implemented sequentially.

The preparation step, as the name states, is defining all the necessary information for

this CPD application. In this step, the CPD functional engineer declares which com-

ponents are going to be used during this CPD application. In addition, the CPD func-

tional engineer states which Machine Constants need to be read and which of them

need to be calibrated, in case of a calibration application, at the end of the CPD exe-

cution. Moreover, he/she defines all the Test Constants that are going to be used as

parameters during the calculations. Then, the CPD functional engineer has to declare

which sensors need to provide traces or values throughout the measurement. Finally,

he/she sets the preconditions to be satisfied before the execution of the CPD applica-

tion.

The GUI design step allows the CPD functional engineer to create a graphical user

interface and assign values from the components to the variables of his/her design. It

is very important to state here that the GUI is based on common templates that are

being used in this category of CPD applications. As such, the CPD functional engi-

neer is required to put the minimum effort on creating a new CPD application GUI.

The measurement step describes which actions need to be performed on a machine in

order to collect the data for the calculations. Here, the CPD functional engineer cre-

ates an activity diagram of actions. An action is either an interaction with a plat-

form’s component, or a request for a sensor’s trace. A partial version of this activity

diagram was already created during the investigation phase.

The modeling step is mainly a connection between the measured data and the models

created during the investigation phase. Here the CPD functional engineer uses Ma-

chine Constants, Test Constants, and the measured traces as input to the Matlab algo-

rithms. Thus, he/she has to create only one script to make this connection.

The verification step allows the CPD functional engineer to select which Machine

Constants he/she wants to activate at the platform side. Practically, this step changes

the machine constants with the new calibrated values and repeats the measurement.

The evaluation step contains information on how to evaluate the results of the last

measurement. First, the CPD functional engineer selects which traces he/she wants to

evaluate. Then, he/she defines the evaluation method in the form of a formula.

The tear down step is the last step of the design phase. Here the CPD functional en-

gineer specifies all the post conditions of the CPD application. These conditions can

be either an action required by the operator or a cleanup of the collected data that are

no longer required for other CPD applications.

However, the design phase consists of two more activities: the creation of the report

and the diagnostic files. During every step of the design phase the CPD functional

engineer can select data to be sent to the reporting mechanism. For the report the

CPD functional engineer has to define the layout and the format of the printed data.

25

For the diagnostic files he/she needs to specify only the format he/she wants the data

to be saved for later usage.

The simulation phase is active throughout the whole design phase, since the CPD

functional engineer is able to see the look and feel, progress, and status of the CPD

application he/she designs. It is advised that he/she first uses the local simulation in

order not to consume valuable hardware time. When he/she needs more precise data

input he/she remotely connects to real hardware. So this phase happens in parallel

with either the investigation or the design phase.

The CPD functional engineer completes the design phase when all the functional

requirements are satisfied by the results of the simulations. Then, he/she can official-

ly qualify the CPD application and proceed to the integration phase.

The integration phase requires only the final acceptance test from the CPD functional

engineer. The system auto-generates the executable software. The functional engi-

neer is now able to perform the acceptance test on the actual platform in order to

qualify each of the functional requirements in the checklist created at the end of the

investigation phase. This concludes the CPD application development.

Although the CPD application is part of the machine’s software, it will need mainte-

nance, which is the last phase of the CPD development lifecycle. If for any reason

there is a need for a change in the CPD application, the CPD functional engineer has

all the information in front of him/her. All blocks that he/she created and used in this

application support the version control system. If there is a radical change on the real

hardware, then all functional owners of the affected CPD application can be notified

to check if the CPD application needs to be upgraded as well.

These were all the phases in the CPD application development process. The most

important part of this process is that the CPD functional engineer is using only the

MathWorks tools throughout the whole process. In addition, all documentation is

produced with less effort than the current process, because the functional engineer

has only to describe the purpose and the science behind this CPD application. Every-

thing else is auto-generated by the tool.

7.3 CIDT Requirements Table 4 presents the system requirements collected from the functional engineers

during multiple interview iterations. The first column is an id to quickly refer to a

specific requirement. The Requirement and Notes columns denote a short description

and an explanation respectively. Finally the Priority column sets the importance of

each requirement according to the MoSCoW prioritization technique.

Table 4 – System Requirements List

Id Requirement Notes Priority

SR.1 Algorithms in Matlab All mathematics algorithms inside the CIDT must be in Matlab or

Simulink

Must have

SR.2 Data from ASML Ma-

chine

The CIDT should be connected to the real platform and have either a

simulated execution or a real time execution

Must have

SR.3 Executable for ASML

Machine

When the CPD application is ready, the CIDT should generate an

executable

Must have

SR.4 Data Visualization The collected data from the measurement should be available for cur-

rent or new Visualization tools

Could have

SR.5 Data Comparison The collected data from measurements and calculations should be

stored for later comparisons with new available data

Could have

SR.6 User Input – GUI Design Designer for creating the GUI. The CPD functional engineer will

make use of templates in order to minimize the number of actions to

create the GUI

Should

have

26

SR.7 Preparation – Initialize

necessary systems

The CPD functional engineer selects which subsystems of the ma-

chine, he/she is going to use for this CPD application

Must have

SR.8 Preparation - Machine

Constants selection

Machine Constants are selected and are available for usage in the next

steps of the process

Must have

SR.9 Preparation - Test Con-

stants definition

Test Constants are defined and are available for usage in the next

steps of the process. At the end they are stored at the Test Constant

Manager

Should

have

SR.10 Measurement – Define the

how

Functional actions are combined to create a sequence of activities that

the machine has to perform, either to adjust a component or to meas-

ure a trace

Must have

SR.11 Modeling – Algorithms Algorithms from the investigation phase use traced as input, using the

MathWorks tools

Must have

SR.12 Verification – Apply

model and repeat Meas-

urement

The CPD functional engineer should be able to reuse the sequence of

action to repeat the measurement

Should

have

SR.13 Evaluation – Compare

results

Produced data from the measurement and modeling phases should be

available for comparisons with other data

Should

have

SR.14 Report – Report Design Designer for creating the report. In every modeling or measurement

step the CPD functional engineer can select data to be sent at the re-

port designer. Then he/she is able to select the displayed unit and the

layout of the report

Should

have

SR.15 Tear-down – Prepare Sys-

tem for shutdown

A set of adjustment actions to define the post-conditions of a CPD

application

Should

have

SR.16 Local simulation The CPD functional engineer should be able to do local simulations,

without the need of the real hardware

Could have

SR.17 Real H/W simulation The CPD functional engineer should be able to remotely connect to

the platform and execute the CPD application

Could have

SR.18 Easy process The whole design process for a CPD application should be easy to

understand and get familiar with

Must have

SR.19 Version Control A version control system for blocks. Every older should be available

and workable

Could have

SR.20 Time Execution Indication A time-execution indication should be available for functional or

modeling blocks

Would not

have

SR.21 Data Size Consumption

Indication

A data size indication should be available for every block Would not

have

SR.22 Templates Templates of blocks should be possible to store and reuse. The de-

signer will have to specify only some parameters and connect with his

algorithms

Could have

SR.23 Code/Block Refactoring The functional development organization is not very familiar with

proper coding standards. As such this functionality will help them

organize and optimize their designs

Would not

have

SR.24 Functional Configuration Clear indication for which system this CPD is intended for. The con-

figuration should be decoupled from the design. When needed the

functional owner can specify the different values for parameters or

different implementations for different platforms

Should

have

SR.25 Introduce fault signals

during simulation

While simulating, the CPD functional engineer wants to see the what-

if scenario. It should be possible to introduce these faults

Would not

have

SR.26 Add new physical effect

to simulation

The simulators should be expandable and configurable. It should be

possible to add a physical effect described in a Matlab algorithm

Would not

have

SR.27 Connection with existing

simulators

There are already many existing simulators. It should be easy to con-

nect them to the new system, instead of using the default one

Should

have

SR.28 Block suggestion during

development

While designing a CPD application, the system should be able to sug-

gest blocks according to historical data and purpose of usage

Could have

SR.29 Easy Block Navigation The finding of a block should be easy. Navigation among the blocks

as well

Should

have

SR.30 Explicit Version migration When there is a new version of a block, it should not force the usage

in all existing CPDs. This should be done by a designer only if he

chose to

Could have

SR.31 Maintainability of blocks The blocks should be easily maintained Should

27

database have

SR.32 Reliability (S/W must

work)

The generated CPD software must run according to specification Must have

SR.33 Well-equipped block li-

brary before kick-off

The block database should contain enough blocks for the designers to

use. If the existing block do not meet the requirements and expecta-

tions of the functional organization, they will not use the system

Must have

SR.34 Introduction workshop As every new system, an introductory workshop is necessary. During

this, the benefits will be presented. Best practices and other general

guidelines

Should

have

SR.35 Principals list A set of principals should be given to everyone. General guidelines to

follow in order to help the maintainability of the block database

Should

have

SR.36 Best Practices guide per

team

Every team has their own specific needs and they use various pat-

terns, thus a best practices guide is necessary in order to give a quick

startup to the designer

Should

have

SR.37 Block maintainer Every CPD functional engineer will probably have a different ap-

proach on designing same functional blocks. Someone has to be re-

sponsible checking if it meets the requirements before allowing it to

be submitted

Could have

■

29

8.System Architecture

In order to keep the end goal alive, someone has to create the big picture. The archi-

tect selects the pieces of the puzzle, arrange them and connect them. It is important to

inform all the involved parties about the whole solution in order to make sure that

they are aligned with it.

8.1 Introduction CIDT is a complete environment to develop CPD applications and it consists of sev-

eral fundamental components, which serve a specific goal. On top there is the Func-

tional Specification, which gives input to the CPD application MathWorks Modeling.

These MathWorks models have an internal representation, which is used either for a

local simulation or Code Generation. There are two different paths. The first path is

for a regular PC or platform execution and the second path is for an ASML machine-

specific execution. On the one hand, there is a Generic Binder to connect the generat-

ed code to a Generic Target. On the other hand, there is the ASML machine Binder,

which combines the input from the Code Generator and the Application Specific

Generator to connect them with the CPD Safe Execution Environment. Finally, the

latter is connected to the ASML machine Target. The goal of this project is oriented

on the Functional Specification Models. However, in the following chapters there is a

more detailed description of each component.

This abstract architecture reference is also going to be used during the feasibility

study for creating a proof of concept. The first step is to create models that represent

CPD applications in the functional level. Then, there is a need for models that repre-

sent the CPD applications in the platform and the internal MathWorks representation.

The last step is to find the appropriate mappings between the functional and the soft-

ware representations.

Figure 9 – High Level System Architecture

30

8.2 Analysis The reference architecture for the CIDT is described in Figure 10, which is a more

detailed diagram of Figure 9. The following sections analyze each part of this archi-

tecture.

Figure 10 – Detailed System Architecture

8.2.1. Functional Specifications

The top layer is the functional specification representation, which contains all the

information to describe a CPD application in the real world. A functional specifica-

tion representation can be interpreted in many different ways. As a result each CPD

functional engineer produces his own explicit model, which is a simplified image of a

system. Models are used to represent reality.

Figure 11 – Functional Domains

31

In order to have a common understanding functional engineers have to produce a

formal model that follows some basic rules. This architectural layer describes the

CPD application as a model, which represents the functional point of view.

8.2.2. MathWorks Modeling

Functional engineers use the MathWorks tools to describe their functional models.

The MathWorks suite consists of Matlab and Simulink. A functional engineer can

make use of either tool since, Matlab integrates Simulink. A Simulink block can be

used inside a Matlab script. On the other hand, a Matlab script can be used as part of

a Simulink block. A CPD application is described using either Matlab or Simulink. In

all cases the functional engineer makes use of the built-in libraries, the custom made

libraries, and the provided functional actions to an ASML machine.

Figure 12 – MathWorks Modeling: Matlab & Simulink

8.2.3. Model Representation

MathWorks uses an internal common representation for Matlab and Simulink. That is

why the previous step, which makes Matlab to integrate Simulink, is possible. In this

level the CPD application has a representation in the MathWorks ecosystem.

Figure 13 – Madel Representation ans Simulation

8.2.4. Simulation Environment

The simulation environment consists of both the generic simulation and the applica-

tion specific one. The generic simulation is part of MathWorks tools and allows the

functional engineer to simulate the mathematical calculations. The application specif-

ic simulation is intended to simulate the real platform functionality and provide the

data for the calculations. As such, the functional engineer is able to simulate the real

platform functionality without the need of having access to the real hardware.

8.2.5. Generic and Application Specific Generators

The Internal MathWorks representation is not an understandable format for the plat-

form. In addition, it might not even be accessible, since it is a MathWorks proprie-

tary. Thus, there is a need for generators. On the left side of Figure 14 there is a path

to generate software using the default MathWorks generators. It is there to prove that

32

there is already a solution to generate Software from them. On the right side there are

the ASML machine related generators.

The ASML machine related generators consist of two parts. The first one is to gener-

ate the CPD application specific concepts, such as the GUI, the Reports, and the se-

quences. The second one is to generate all the mathematic calculations and the algo-

rithms.

Figure 14 – Binders

8.2.6. Generic and Application Specific Binder

The generators provide the binders software that needs to be executed on a platform.

The binders make the connection between the produced software and those plat-

forms.

8.2.7. Generic and Application Specific Target

The bottom layer of the architecture is the targeted platform. There are many off the

shelf platforms that could potentially execute the MathWorks generated software.

Due to the specialty of an ASML machine, the proposed architecture introduces a

CPD safe execution environment, which is responsible for the communication with

the platform. The communication is established with the current exposed interfaces,

which have a variety of formats for the software engineers.

Figure 15 – Generic Targets and ASML spceific CPD Execution Environment

■

33

9.System Design

Domain Specific languages are designed to decouple the functional description from

the implementation technology. Some companies are prepared to pay a last price for

building the abstract models of their business and services that will guarantee them

against technological obsolescence.

9.1 Introduction The CIDT includes a language for designing a CPD application by the CPD func-

tional engineers. This language is designed using the Eclipse Modeling Framework

(EMF) as proof of concept. The target is to implement it for the MathWorks envi-

ronment. The concepts of this language are based on the CPD application domain

analysis and the extracted requirements of the CPD development process.

9.2 CPD Model Figure 16 shows the big picture of the CPD Application domain specific language. In

the following sections, certain parts of the model will be further analyzed

Figure 16 – CPD Model

34

9.3 CPD Declaration and Definition A CPD application should be supported by different platforms. However, sometimes

a configuration file is not enough to distinguish some parameters. The structure of the

CPD and the implemented algorithms are different. Thus, the functional architect has

to define the CPD application declaration and then a functional architect will define

the CPD application definition for a specific platform. The VP-Expression handles

the different platforms that are allowed through the definition. This separation satis-

fies the requirement of having CPD applications running independent the platform.

9.4 Blocks A CPD application consists of a set of activities to be executed. These activities are

either mathematic algorithms that are designed in the MathWorks tools, or activities

performed on the ASML machine platform. Action and Modeling Blocks satisfy the

above statement.

The technology acceptance requirement can be satisfied via the block concept. The

functional engineers are acquainted with the Simulink tool, which treats data as

blocks. Based on this, the data block is introduced to this language.

A block has a set of ports to send and receive data. These ports are expected to get a

specific datatype and are being connected with connectors.

Figure 17 – Types of Blocks

9.4.1. Action Block

The targeted platform provides a set of interfaces to the software engineers. Howev-

er, these interfaces are not the same across the platform. The action block provides a

single and simple interface to the CPD functional engineers to access the targeted

platform. Every action block is mapped to an action in the real platform. For every

new action there must be a new action block created. For every modification in a

platform’s action, the corresponding action block has to be modified.

An action block can perform either an adjustment or retrieve a measurement from the

platform. The adjustment blocks do not yield any results data in contrast with the

measurement blocks. The latter can be either a trace or a sensed value and is depend-

ing on sensors.

35

Each action requires a set of parameters specified by certain datatypes. As such when

an action block is mapped to an action, it will automatically generate the appropriate

ports. These ports will be used as input and output for that block.

9.4.2. Modeling Block

The CPD functional engineers are already working in Matlab in order to create math-

ematic algorithms within Matlab functions. A modeling block is a connection be-

tween the CPD application and the MathWorks environment.

The Matlab function also requires a set of parameters and yields some data. As such,

when a modeling block is mapped to Matlab script it will automatically generate the

appropriate ports as well.

9.4.3. Data Block

A data block represents a variable that holds a value. There are two categories of data

blocks based on their location. First, there are data that are produced and maybe

stored in the CPD application; the test parameters and the modeled data. Second,

there are data that are stored in the ASML machine platform; the test constants and

the machine constants.

The local data’s values can be changed during runtime. The test parameters are usual-

ly used to get input from the user. The modeled data are holding the output of either a

modeling or a measurement block.

The remote data are stored in the platform and cannot be changed via the CPD appli-

cation. They can only be changed through special Test/Machine constants managers

on the platform. The machine constants are defined on the machine and are inde-

pendent of any CPD application. On the contrary, the test constants are defined in the

CPD development and are accessible only by this CPD application.

A data block has ports, since it is a block. The constraint is that it provides only one

port to either send over its value or receive a new value to assign in the variable.

9.4.4. Composite Block

A characteristic of CIDT is to assist the functional engineers in reusing part of their

working products. As such, they can combine the available blocks to create more

complex functionality. The sequencing is defined within activity diagrams, described

by an activity specification language.

The activity specification language is a generic component, designed for other pro-

jects as well. It will be imported from other projects and adjusted to the needs of

CIDT. The blocks are going to be connected through their ports and connectors to

transfer data information.

A composite block implements the composite pattern, since it inherits from the block

class and it contains other blocks. However, due to the fact that it cannot create an

instance of a test or machine constant, a new interface is introduced. This interface is

the composable block, which is realized only by the blocks that can be placed into a

composite block.

A composite block describes a sequence of activities and as such a CPD application

is a sequence of activities itself. It is safe to assign one single composite block to the

CPD application definition.

When a composite block is being reused very frequently, then the software engineers

will create this functionality within an action block, which will replace the former.

With this, the CPD functional engineers can replace these composite blocks with

single action blocks to achieve better performance in their CPD applications.

36

Figure 18 – Composite Block Details

■

37

10. Verification

The creation of a domain specific language is not as simple as someone might think.

During the instantiation of the business model, the language is going to be refined

many times, until it satisfies all the needs. It is important to keep the initial goals in

mind at all times.

10.1 Introduction The verification of the CPD functional domain specific language is against a simpli-

fied version of a Wafer Lift System (WLS) Calibration.

10.1.1. Wafer Lift System Calibration

The WLS mechanism transfer the wager from the Wafer Handler gripper to the wafer

table. The WLS mechanics consists of several components, but this simplified

version refers to one WLS, as Figure 19 shows. There is a motor that moves WLS in

the vertical axis. In addition there are sensors to mesaure the force, the accelaration

and the position of WLS.

Figure 19 – Wafer Lift System

The functional engineers from the Wafer Handler provided the Simulink model that

is described in Figure 20. The motor operates by applying current based on the “cur-

rent = Coefficient (position) ∙force” formula. The purpose of this CPD application is

to calibrate the Coefficient function, which is a lookup table based on the position of

WLS.

Figure 20 – Simplified Simulink model of WLS

The calibration moves WLS from a start to an end position and measures the applied

force in order to calculate the coefficients’ table. It consists of three steps, which are

measuring, processing, and verifying. The measuring step activates the nominal

lookup table to the machine constant, moves WLS to the start position, and then

moves WLS to the end position while obtaining the tracing data of position, accelera-

tion, and force applied to WLS. The processing step filters the traces, creates a new

38

coefficient table based on the values of the traces, and normalizes this table, based on

the user’s input table length parameter. Finally, the verifying step activates new coef-

ficients’ table, repeats the measurement, filters the traces again, and verifies that the

applied force is in between the verification margin. The required data for this calibra-

tion are presented in Table 5.

Table 5 – EPins Calibration Data

Data Name Type of Data Explanation

start_pos Test Parameter The start position of WLS

end_pos Test Parameter The end position of WLS

table_len Test Parameter The desired lookup table length

verification_margin Test Constant The allowed verification margin

nominal_value Test Constant The nominal values of the coefficients’ table

wls_mass Test Constant The mass of WLS

wls_coef Machine Constant The MC that holds the coefficients’ table

trace_position Modeled Data The result of position tracing

trace_acceleration Modeled Data The result of acceleration tracing

trace_force Modeled Data The result of force tracing

result Modeled Data The result of the calibration, either OK or NOK

smeas Modeled Data Number of samples

10.1.2. WLS CPD Application Instance

The analysis of the WLS calibration leads to a CPD application instance based on the

CPD functional DSL. The instance was created with the Tree Editor provided by

Ecore, but it is cannot nicely be presented in this document, due to a large amount of

ports and connectors. However, a visual representation is available divided into three

parts; measure, process data, and verify.

The Measure composite block consists of two parts and it is presented in Figure 21.

The first part is the activation of the nominal value to the Machine Constant and the

second part is the actual measurement. The actual measurement is a composite block,

due to the fact that it is going to be reused in one of the next steps.

Figure 21 – Measure Composite Block Visual Representation

The Process Data composite block consists of three modeling blocks and it is pre-

sented in Figure 22. The first modeling block is the filter trace, which takes the pro-

duced traces and filters the empty values. The second modeling block is the calcula-

tion of the new coefficients’ values based on the force trace and test parameters. The

last modeling block is the normalization of the new coefficients’ values. All three

modeling blocks should connect to a valid Matlab function file.

39

Figure 22 – Process Data Composite Block Visual Representation

The verify block consists of four blocks and is presented in Figure 23. The first three

blocks are the same with the measure block and the first block of the process data

block. However, the activation of the machine contact has a different input and in the

actual measurement the CPD functional engineer is interested only in the force, thus

not all ports are being used. The last modeling block is responsible for generating the

of this CPD calibration’s outcome, which practically shows if the calibration was

successful or not.

Figure 23 – Verify Composite Block Visual Representation

■

41

11. Conclusions

This project lasts for nine months; there is a lot of knowledge concentrated in many

different documents, but also a lot of experience gained. After the project finishes,

this report is the main deliverable. However, a series of other documents linked with

all the previous work is delivered to the organization as well.

11.1 Results This chapter summarizes the project’s results, which have been described in detail in

the previous pages. There are four deliverables and each one of them has its own sig-

nificance and it is going to be used during the next phases in the CIDT initiative.

The first deliverable is the business case analysis. This report presents a zero order

analysis based on data collected from the code archive. The collection of the data

needed some further investigation due to the changes of a TWINSCAN machine code

structure throughout the years. The outcome of the zero order analysis is that the re-

turn on investment can be achievable within five years. As a result it is recommended

to investigate further the business case and add more parameters for a more accurate

picture.

The second deliverable is system requirements for the CIDT. This report presents a

requirements list based on a first order collection from the functional organization. A

set of functional engineers cooperated in order to investigate the functional and non-

functional CIDT’s requirements that would satisfy the needs of the functional organi-

zation. It is recommended, to go through all the different groups of the functional

development organization in order to align every functional engineering team of the

organization with these requirements, since the success of the CIDT is highly de-

pending on the functional engineers’ acceptance.

The third deliverable is the CPD development process. This report presents a CPD

application development process, without the need of a software engineer. The new

process is a modified version of the process that the functional development organi-

zation is already using to design the functional requirements, but it is extended to

include the whole lifecycle of a CPD application.

The fourth deliverable is a CPD functional DSL proof of concept. This report pre-

sents the main elements of the proposed DSL and explains the design choices that

were taken. In addition, three different CPD applications, based on their functional

requirement documents, were instantiated in order to find missing spots in the DSL

and improve it. It is recommended to further investigate with a larger sample of CPD

applications.

Part of the deliverables was developed in parallel with the feasibility phase of the

CIDT initiative, since the major contribution of this project was the knowledge trans-

fer about the CPD applications and the functional organization’s needs about them.

11.2 Lessons Learned During the nine months of this project I learned some valuable lessons about the de-

livered results’ topics.

As far as it concerns the requirements collection, it can be a very difficult process.

Every person is different and has its own personality and interpretation of reality.

People have the tendency to express in a different way the same need for a feature,

but from a different perspective. It is very important to ask multiple questions to un-

42

cover the underlying needs from every conversation. In addition, writing everything

down is also very important in order not to miss any valuable information. The merg-

ing of the different requirement sources is an interesting challenge that needs a lot of

focus in order to fairly deal with conflicting requirements and to overall keep satis-

fied all the stakeholders.

Moreover, modifying and adapting a process in a big organization is not a trivia task.

There are many factors that need to be taken into account. First of all, a process has

to be designed according to the daily workload and not according to what looks nice

and beautiful. It needs to be realistic, in order for the participants to accept it and use

it without workarounds. In addition, it needs to consist of accurately measurable

blocks and equally distribute the weight among them. If this is achieved, then some-

one can look at the diagram and easily make associations and comparisons between

the covered progress and the pending work load.

Finally the development of a DSL is a very interesting and challenging activity. It

needs many hours of discussions over the advantages and the disadvantages of a cer-

tain design choice. Each alternative is like starting from scratch, because all the work

that has been done is deleted and it remains only in the documentation as a rejected

design alternative. The presentation of the DSL to stakeholders then becomes even

more challenging because it might seem like you have a done many steps back in

your progress, but the advantages usually cannot be expressed in the short available

time of a meeting. ■

43

12. Project Management

All things are created twice; first mentally; then physically. The key to creativity is to

begin with the end in mind, with a vision and a blue print of the desired result. Every

other change in the meantime can be handled as long as the vision remains. It’s not

the smartest who survives, but the one who adapts faster to changes.

12.1 Introduction In the beginning of the project the initial project plan is created and presented to the

supervisors. During this project, the plan is going to regularly refined to meet any

new requirements and direction of the CIDT initiative. In order to control and check

the progress of this project, there are three controlling mechanisms.

The first controlling mechanism is the Project Steering Group (PSG) monthly meet-

ing. This group consists of the trainee, the company supervisor, the company mentor,

and the TU/e supervisor. The purpose of this meeting is to manage the project’s pro-

gress and ensure that all parties are aligned.

The second controlling mechanism is the Performance Evaluation. Every three

months a performance evaluation form is sent to the PSG in order to evaluate the

trainee in certain aspects of the project. The purpose of these evaluations is to alert

potential problems and steer the trainee to better direction.

The third controlling mechanism is the weekly meetings with the company supervi-

sors. Every week the trainee and one of the supervisors meet in order to discuss the

progress of the project. In addition, in these meetings all the different design choices

are mentioned so that the supervisors can monitor this project and align it with the

organization’s direction.

The final delivery to the OOTI program is this technical report. Therefore, the work

breakdown structure is based on the sections of the technical report. On the one hand,

the project plan describes the greater categories that need to be investigated and im-

plemented. On the other hand, the technical report presents the outcome of the nine-

month OOTI project.

12.2 Work-Breakdown Structure (WBS) As mentioned in section 12.1 the work breakdown structure is based on the tech-

nical report. The technical report is decomposed into all the sections and an estima-

tion of the needed effort is assigned.

12.2.1. Activity-Cost Estimations

In Table 6 all the report related activities are enlisted. The third column denotes the

initial effort estimation. The fourth column shows the required effort needed. Finally,

the last column is the date of completion. During the project Table 6 is going to be

updated.

Table 6 – Report Based WBS

Id Item

Initial

Estimated

Effort Effort

Date

completed

1 Foreword 2.00 0.00 12-Aug

2 Preface 2.00 0.25 12-Aug

3 Acknowledgements 2.00 0.25 12-Aug

44

4 Executive Summary 8.00 3.00 2-Aug

5 Table of Contents 0.00 0.00 15-Jan

6 List of Figures 0.00 0.00 15-Jan

7 List of Tables 0.00 0.00 15-Jan

8 1 Introduction 1.00 0.25 3-Aug

9 1.1 Context 8.00 8.00 26-Feb

10 1.2 Outline 4.00 2.00 3-Aug

11 2 Stakeholder Analysis 8.00 8.00 26-Feb

12 2.1 Introduction 8.00 8.00 26-Feb

13 2.1.1. Analysis 8.00 8.00 26-Feb

14 3 Problem Analysis 1.00 0.25 3-Aug

15 3.1 Introduction 8.00 8.00 16-Mar

16 3.2 Roadmaps 4.00 4.00 22-Jun

17 3.2.1. Orientation Phase 1.00 1.00 22-Jun

18 3.2.2. Feasibility Phase 1.00 1.00 22-Jun

19 3.2.3. Demonstration Phase 1.00 0.50 22-Jun

20 3.2.4. Prototype Phase 1.00 0.50 22-Jun

21 3.2.5. Industrialization Phase 1.00 0.50 22-Jun

22 3.2.6. Rollout Phase 1.00 0.50 22-Jun

23 3.2.7. Lifetime Support Phase 1.00 0.50 22-Jun

24 3.3 Stakeholders 4.00 4.00 16-Mar

25 3.4 Design Opportunities 1.00 1.00 16-Mar

26 3.5 Requirements 4.00 2.00 29-Jul

27 4 Business Case 1.00 0.25 3-Aug

28 4.1 Introduction 4.00 4.00 22-Jun

29 4.2 CPD development history 4.00 4.00 22-Jun

30 4.4 Analysis 2.00 2.00 29-Jul

31 4.4.1. Value Chain and Business Processes 1.00 1.00 29-Jul

32 5 Domain Analysis 1.00 0.25 3-Aug

33 5.1 Introduction 8.00 8.00 16-Mar

34 5.1.1. Clients and Users 4.00 4.00 16-Mar

35 5.1.2. Environment 4.00 4.00 16-Mar

36 5.1.3. Current Situation 8.00 8.00 8-Jun

37 5.2 The block approach 2.00 2.00 16-Mar

38 5.3 Users - Actors 2.00 2.00 8-Jun

39 5.4 User Stories 8.00 8.00 8-Jun

40 5.4.1. CPD Development 8.00 8.00 8-Jun

41 5.4.2. CPD Maintenance 4.00 4.00 22-Jun

42 5.4.3. Block Design 2.00 2.00 22-Jun

43 5.4.4. CIDT Support 2.00 2.00 22-Jun

44 6 Feasibility Analysis 1.00 0.25 3-Aug

45 6.1 Issues 4.00 4.00 15-Jun

46 6.2 Risks 4.00 4.00 15-Jun

47 7 System Requirements 1.00 0.25 11-Aug

48 7.1 Introduction 4.00 4.00 15-Jun

49 7.2 CIDT Process 8.00 8.00 15-Jun

50 7.3 CIDT Requirements 4.00 4.00 29-Jul

51 8 System Architecture 1.00 0.25 11-Aug

52 8.1 Introduction 2.00 2.00 22-Jun

53 8.2 Analysis 2.00 2.00 22-Jun

54 8.2.1. Functional Specifications 2.00 2.00 22-Jun

55 8.2.2. MathWorks Modeling 1.00 1.00 22-Jun

56 8.2.3. Model Representation 1.00 0.50 22-Jun

57 8.2.4. Simulation Environment 1.00 0.50 22-Jun

58 8.2.5. Generic and Application Specific Generators 1.00 0.50 22-Jun

59 8.2.6. Generic and Application Specific Binder 1.00 0.50 22-Jun

60 8.2.7. Generic and Application Specific Target 1.00 0.50 22-Jun

61 9 System Design 1.00 0.25 11-Aug

45

62 9.1 Introduction 1.00 1.00 28-Jul

63 9.2 CPD Model 1.00 1.00 28-Jul

64 9.3 CPD Declaration and Definition 1.00 1.00 28-Jul

65 9.4 Blocks 1.00 1.00 28-Jul

66 9.4.1. Action Block 1.00 1.00 28-Jul

67 9.4.2. Modeling Block 1.00 0.50 28-Jul

68 9.4.3. Data Block 1.00 0.50 28-Jul

69 9.4.4. Composite Block 1.00 1.00 28-Jul

70 10 Verification 1.00 0.25 11-Aug

71 10.1 Introduction 1.00 1.00 31-Jul

72 10.2 CPD Application Instance 6.00 7.00 31-Jul

73 11 Conclusions 1.00 0.25 11-Aug

74 11.1 Results 4.00 1.50 3-Aug

75 11.2 Lessons Learned 4.00 1.50 3-Aug

76 12 Project Management 1.00 0.25 10-Aug

77 12.1 Introduction 2.00 0.25 10-Aug

78 12.2 Work-Breakdown Structure (WBS) 2.00 0.50 10-Aug

79 12.2.1. Activity-Cost Estimations 4.00 4.00 10-Aug

80 12.3 Project Planning and Scheduling 2.00 2.00 10-Aug

81 12.3.2. Gantt Charts 2.00 0.00 10-Aug

82 12.4 Earned-Value Analysis 2.00 2.00 10-Aug

83 12.6 Conclusions 2.00 2.00 10-Aug

84 13 Project Retrospective 1.00 0.50 5-Aug

85 13.1 Introduction 4.00 0.50 5-Aug

86 13.2 Design opportunities revisited 3.00 0.25 5-Aug

87 Glossary 4.00 3.00 11-Aug

88 References 2.00 4.00 11-Aug

89 About the Authors 2.00 0.50 11-Aug

12.3 Project Planning and Scheduling The project involves different activities, which have to be fit in the project plan. The

V-Model is selected in order to time-frame these activities. Table 7 shows these ac-

tivities and the planned week numbers.

Table 7 – V-Model activities and key dates

Activity Description Wk. #

Adaption Period Get to know the domain and the sources of information 1-6

Domain Analysis Analyze the ASML Domain around the CPD applications 5-10

User Requirements Collect User Requirements from the functional organization 8-13

System Requirements Translate the User Requirements into System Requirements 12-16

Implementation Generate a solution 16-21

Implementation Validation Validate the Implementation using testing techniques 21-24

System Validation Validate the implementation against the system requirements 23-25

User Validation Validate the implementation against the user requirements 24-26

Table 8 presents the PSG meetings dates, the Comeback days at TU/e, which are not

directly involved with the project

Table 8 – Constraints

Constraint Date

Progress Steering Group 1 January 22, 2015

Come Back Day 1 February 20, 2015

Progress Steering Group 2 February 26, 2015

Progress Steering Group 3 March 26, 2015

46

Come Back Day 2 April 13, 2015

Progress Steering Group 4 April 23, 2015

Progress Steering Group 5 May 28, 2015

Come Back Day 3 May 29, 2015

Progress Steering Group 6 June 25, 2015

Come Back Day 4 July 10, 2015

Progress Steering Group 7 August 6, 2015

12.3.1. Gantt Charts

Section 12.3 gives the dates of the project activities and constraints. Figure 24

shows these elements on a Gantt chart for better visualization.

ASML Wks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Adaptation

Kick-off

Introduction Days

SPG #1

Dezyne MDD Workshop

Domain Analysis

User Requirements

ComeBack Day 1

SPG #2

SW Introduction ASML

System Requirements

Initial Performance Evaluation

SPG #3

Come Back Day 2 & Presentation

System Design

Implementation

SPG #4

Implementation Validation

Come Back Day 3

SPG #5

System Validation

User Requirements Validation

Intermediate Performance Evaluation

SPG #6

Come Back Day 4

Report Finish

Report Review process

Report Apply review-comments

Send Report to Judith

Report Review by Judith

SPG #7

Report TPB

SPG #8

Final Evaluation

Submit Final Concept Report

Final Presentations

Supervisors' unavailability

Graduation

Figure 24 – Initial Project Plan

47

12.4 Earned-Value Analysis The technical report was gradually written. Figure 25 shows the progress of the re-

port in relation with the PSG meetings’ dates. From the same figure, it is noticeable

that the PSG controlling mechanism put the necessary pressure on the trainee to pro-

gressively write the technical report. The line is steeper before the third, sixth and

seventh meetings. The third and sixth are the progress evaluation meetings and due to

the fact that the TU/e supervisor could only judge the project progress via the report.

Figure 25 – Work Progress through time

12.5 Conclusions The project is over and in this section it will be evaluated. The project plan was too

optimistic and not adapted to the nature of the project. This project plan was made by

taking into account a typical OOTI project. However, this project started as an inves-

tigation around the CPD application domain and it continued as a proposal for the

Feasibility Phase of the CIDT initiative.

The initial plan was to develop a CPD toolkit that would allow the functional engi-

neers to design and develop CPD applications. However, this was too optimistic to

target during the nine month project because the CPD domain is large. Then, the pro-

ject turned into the Orientation phase of the CIDT initiative and its goals were al-

ready described in the previous sections of this report. By changing the goals, the

project plan had to be refined and adapted to the new requirements. Especially the

last two months, since the Concerto program join the efforts of the CIDT initiative,

this project goals changed again.

During this project two goals were kept in mind. The first one was to envision a CPD

application development toolkit, which will be used by the functional engineers. The

second one was to design a solution that would satisfy the OOTI criteria. Every

change in the project requirements was balanced against these two end-goals. ■

49

13. Project Retrospective

A project might have the perfect project plan, but changes will definitely appear.

Being agile and adapting to these changes can help you grow. The final reflection

has to be honest in order to face the strong points and the development areas.

13.1 Introduction This chapter is going to be a personal reflection on this project. I will try to look back

on the initial goals and reflect on if and how I achieved them. In addition, section 3.4

holds some design opportunities that were picked up during the first month of the

project. Here I will compare them with the end results and check how representative

they are.

13.2 Personal Retrospective A very important part of every project is the personal reflection process that follows.

In the interview, for getting “hired” for this project, Wouter Tabingh Suermondt

mentioned that they were looking for a candidate that has an interest in change man-

agement and in communication with different disciplines. Both topics are very inter-

esting for me, so I believed that we had a very good match.

In January I started working on the CIDT project in ASML, which involved a com-

pletely new and huge domain for me. While talking to one of my TU/e supervisors, I

expressed my concern about the domain, he mentioned, “Don’t worry, usually it

takes up to two years to fully understand what is going on”. For me, it meant that I

have to learn as much as possible about the CPD applications into the first two or

three months. As a result, I had to filter the important from the non-important infor-

mation.

After the first three months I started creating a network of people in the functional

organization. The main topic of our meetings was the requirements of the CIDT ac-

cording to their perspective. Multiple iterations were needed in order to uncover their

underlying needs and to convince them that I will protect their interests throughout

my project. I made clear that my scope is to put the functional organization in the

center of attention and propose a solution that would solve their problems. However,

it was very difficult to persuade them due to the fact that there were many previous

attempts to solve the same issues, but at the end the core problem was still there.

What was missing from my early results was a model to describe a CPD application.

A significant moment of my project was when the Concerto program and Teun van

de Berg joined it. Together with Teun, we gave a boost to the project by creating

many different versions of a CPD model. I realized that the process of producing a

model is not easy. The advantages of having a model are to give a substance to all the

ideas that were lying around and show some potential problems, which cannot be

revealed from various PowerPoint presentations. In addition it gives a certain direc-

tion and helps the planning of the project. If I could have started the project again, I

would have started modeling earlier. Even if the early models are not accurate or

correct, the knowledge that I built up throughout the development is more important.

A graduation OOTI project is usually a one-person project, in contrast with the in-

house projects, in which we are working in a big team. In this project I realized that I

am working more efficient and more productive when I am part of a team. Inside a

team, I can communicate and express my ideas and receive feedback on them. In

addition, I have to find the best way to explain them to my peers and then I am able

50

to see them from a different perspective. Finally, it is very important for me to listen

and discuss other’s ideas and as a result I get inspired and help them improve them.

13.3 Design opportunities revisited In the beginning of the project the following design opportunities were set:

Simple

Elegant

Realizable

Generic

During the design of the proposed DSL simplicity and elegance were always under

my attention. In every new version of the model I avoided to add extra details that

would breach these two parameters. There was always an alternative way to keep the

model neat and simple.

Due to the fact that the CPD applications are present in almost every functional clus-

ter of ASML, the design needed to be very generic. By having this requirement in my

mind I avoided to put any functional cluster specific element into the design.

Finally, I cannot prove how realizable is the proposed design. However, we managed

to formally describe the functional requirements of three CPD applications. The fea-

sibility phase of the CIDT initiative will investigate what is needed in order to trans-

form this functional specification model into a TWINSCAN machine executable

CPD application. ■

51

Glossary Apply a model Temporarily usage of a set of values

Calibration An application that tunes a machine’s parameters

CIDT CPD Integration Development Toolkit

Code Generator A tool to generate executable code from a model

CPD A set of applications that perform Calibrations, Perfor-

mance tests, and Diagnostic tests

CPD development cycle A single iteration of a specific CPD application develop-

ment

CPD development process The whole process of developing a CPD application

CPD tools development The tools that are used to develop a CPD application

Diagnostic A CPD application to locate potential machine problems

Diagnostic File A file that records either events that occur in an operating

system or other software runs, or messages between dif-

ferent users of a communication software

DSL Domain Specific Language

EMF Ecore Modeling Framework

FTE Full-time equivalent

Functional Action A function is an activity of the scanner defined on a high

enough aggregation level such that the nature of it

doesn’t change in time

Functional Cluster A group of people to work around a specific action

Functional Engineer An engineer that works on the functional actions, with

respect to the behavior

Functional Development

Organization

The group of people working on the behavior of the func-

tional actions

Functional Requirements A requirement that describes the behavior but not involv-

ing any technical implementation details

GUI Graphical User Interface

LS Level Sensor

Machine Constant A variable that holds a value that is defined for a specific

machine.

Machine Constant Manager A software that allows to change the values of the Ma-

chine Constants

Metro Metrology Department

OOTI Software Technology PDEng Program, Eindhoven Uni-

versity of Technology

PDEng Professional Doctorate in Engineering

Performance A CPD application that qualifies a machine according to

its specification

PSG Project Steering Group

QBL Qualified Baseline

Software Engineer An engineer with a software background, who is respon-

sible for the software implementation

Software Requirements The requirements that are needed to implement a specific

software

Test Constant A variable that holds a value that is defined for a specific

CPD application

Test Constant Manager A software that allows to change the values of the Test

Constants

TPB Technical Publication Board

TWINSCAN machine An ASML Lithography Scanner

VP- Expression Variability Parameter Expressions

WBS Work Breakdown Structure

WLS Wafer Lifting System

WS Wafer Stage

53

Bibliography

References ASML. (2008). Calibration & Performance Software (C&P). ASML.

Bézivin, J. (2006). Introduction to Model Engineering. Retrieved 2015, from Eclipse:

http://www.eclipse.org/gmt/omcw/resources/chapter02/downloads/Introduct

ionToModelEngineering.INRIA.ppt

Gamma, E., Helm, R., Johnson, R., & Vissides, J. (1994). Design Patterns: Elements

of Reusable Object-Oriented Software. Addison-Wesley Professional.

Model Driven Engineering. (n.d.). Retrieved 2015, from

https://en.wikipedia.org/wiki/Model-driven_engineering

55

About the Authors

Erikos Alkalai received his diploma in Computer Engi-

neering and Informatics from University of Patras, Greece

in 2012. During his diploma thesis he designed and in-

stalled a dynamic application for the total organization of

a small to medium company. Moreover as a Microsoft

Student Partner at University of Patras he led and founded

the first “Microsoft Student Tech Club” in Greece, also

known as StudentGuru Patras. In this effort he was part of

a team that organized software development competitions,

free seminars and lectures of programing techniques re-

garding mostly .NET technology. Last but not least he

participated in Microsoft’s ImagineCup competition with

project OramA, a fully personalized software platform,

specially designed for kids with mental disabilities.