Upload
lykhanh
View
223
Download
3
Embed Size (px)
Citation preview
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.