Scalable reticle heating correction design

Scalable reticle heating correction design

Citation for published version (APA):Wang, J. (2017). Scalable reticle heating correction design. Technische Universiteit Eindhoven.

Document status and date:Published: 28/09/2017

Document Version:Publisher’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 version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI 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 pagenumbers.Link to publication

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.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:[email protected] details and we will investigate your claim.

Download date: 15. Apr. 2022

https://research.tue.nl/en/publications/9dc35beb-4b73-4baf-9239-faaffedb8aa6

/ Department of

Mathematics and

Computer Science

/ PDEng Software

Technology

Scalable Reticle Heating

Correction Design

Jie Wang

September 2017

Where innovation starts

Scalable Reticle Heating

Correction Design

Jie Wang

September 2017

Scalable Reticle Heating Correction Design

Jie Wang

ASML

Eindhoven University of Technology

Stan Ackermans Institute / Software Technology

Partners

ASML Netherlands B.V. Eindhoven University of Technology

Steering Group

(By alphabetical

order)

Javad Vazifehdan

Julien Schmaltz

Marten Jansen

Stanislau Shumiacher

Date September 2017

Document status Public

PDEng report no. 2017/061

The design described in this report has been carried out in accordance with 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

PDEng report no. 2017/061

Abstract With the increasing complexity of ASML machines, the Metrology department has

developed many measurement and correction mechanisms for improving the exposure

accuracy. One of such mechanisms is reticle heating correction. This project provided

design and implementation for reticle heating correction by following the 4+1 view model.

As a result, a software framework was delivered, including the data model of reticle heating

correction. With this software framework, reticle heating correction can be easily extended,

for example by adding and removing reticle heating correction models. In addition, it

demonstrated that the software framework does not introduce negative overlay impact.

Keywords

Software framework, Reticle Heating Correction, data model, design pattern, metrology,

ASML, Software Technology, OOTI

Preferred

reference

Jie Wang, Scalable Reticle Heating Correction Design. Eindhoven University of

Technology, SAI Technical Report, September 2017.

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

Netherlands B.V.

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

endorsement, recommendation, or favoring by the Eindhoven University of Technology or

ASML Netherlands B.V. The views and opinions of authors expressed herein do not

necessarily state or reflect those of the Eindhoven University of Technology or ASML

Netherlands B.V., 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, ASML makes no warranty, representation 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 © 2017. ASML. 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

photocopying, recording, or by any information storage or retrieval system, without the

prior written permission of the Eindhoven University of Technology or ASML Netherlands

B.V.

Foreword The ASML's TWINCSAN lithography systems work with the nanometer accuracy at

high speed. This cannot be realized by mechatronics alone. The metrology

department is making the software that measures and corrects for small mechanical

inaccuracies. We created mathematical models, describing the lithography machines

and their correction potential. The parameters of these models are calibrated using

the sensors present in the machines. Afterwards, TWINSCAN software uses the

calibrated models to correct for the hardware inaccuracies 24/7.

Reticle heating correction (RHC) is one of such metrology models. It compensates

the distortion of the photomask caused by heating during the wafer exposures. At

some point we realized that to meet the tighter accuracy specs of the upcoming new

machine models we need to develop new RHC model with the changed calibration

protocol. Maybe, even several model versions. Knowing that TWINSCAN software

has to support all the machine types, including the whole install base, we realized that

the scalability might become an issue on the short term. In order to prevent high

development costs we need to invest into the software architecture and find the

potential bottlenecks at the early stage. That was the moment, when I decided to

write the OOTI project proposal on behalf of the metrology department, which

resulted in the work of Jie.

Initially, the scope of the project was very broad. Our metrology engineers were so

enthusiastic about this study that they managed to put in it half of the department

roadmap. It took us 5 weeks to filter out this huge feature list and identify a few items

Jie has focused upon and successfully completed in the remaining time. She made the

RHC prototype, scalable for the currently known variation points and put forward the

reference design for the control / data separation.

The way to success was not easy. Jie had many challenges. She had to learn ASML's

interface definition language and the code generators, had to deal with the large

legacy code base and concurrent development in the same code area, running in

parallel by multiple teams. During her project she identified a number of

interoperability issues with the existing software, which hampers the support of

multiple programming languages.

Besides the working prototype, Jie left behind some other valuable results. She

measured and analyzed the inter-process communication penalty. These results will

be used and referred to when we face the software deployment decisions. During the

development she was using the continuous integration framework to monitor the

code quality. Her work has proved once more the need for a good regression test

suit, integrated into the development environment and confirmed the importance of

backwards compatibility of interfaces.

We are happy that Jie decided to continue her career at ASML. With her intelligence

and critical thinking, she has all the potential to sharpen her skills and grow as

software professional.

Thank you, Jie, for your hard work and all the best in your future life.

Stanislav Shumiacher,

ASML engineer

September 2017

iii

Preface This report describes the “Scalable Reticle Heating Correction Design” project

that was carried out by Jie Wang at ASML Netherlands B.V (ASML). The project

was initiated and fully funded by ASML as a full-time, nine-month graduation

assignment of the Software Technology PDEng program. The Software

Technology PDEng program is a two-year technological design program,

provided by Eindhoven University of Technology under the auspices of the Stan

Ackermans Institute.

This feasibility project focuses on pattern-based design and data model research.

It was conducted by the author, under the guidance of the project steering group,

which includes the ASML supervisors, the ASML project manager, and the TU/e

supervisor.

This report is structured from stakeholder analysis and problem analysis to the

solution and validation. Furthermore, it is intended for different people who have

different purposes. Those who are interested in the project context and the

problem analysis can refer to Chapters 1-4 and 10. People who have the greatest

interest in the detailed requirements, corresponding solutions and validations,

please read Chapter 5 to Chapter 9. Chapters 11 and 12 are for those who are

interested in the project management of this nine-month project.

Jie Wang

September 2017

v

Acknowledgements The success of this project cannot be reached without the guidance, assistance,

and collaboration of people whom I worked with.

Firstly, I want to express my sincere gratitude to my supervisor from ASML,

Stanislau Shumiacher, for providing the opportunity of working on my final

project in ASML. I would like to thank him for the continuous guidance,

supportive ideas and experienced ideas for helping me to impel my ideas and

understanding the company working way. I enjoyed working with him in these

nine months and thank him for the great experience I have been able to have with

him. Next, I would like to thank Marten Jansen for his feedback and comments,

which inspired me to improve my project management and working way.

Furthermore, I would like to thank Javad Vazifehdan for his valuable suggestions

of managing the project and my tasks. Additionally, I would like to give thanks to

all the Image Align group members who made me feel welcome and helped me a

lot, especially the Reticle Heating Correction team members: Hristina Pavlovska,

Fred Benedosso, David Zaragoza, Ying Zhang, Milan Pavlovic, and Tamir

Tsedenjav.

I would like to give my great appreciation to my university supervisor Julien

Schmaltz. Thank you for your contribution to this project and your valuable

feedback to this report. Additionally, I want to thank everybody from OOTI

program, especially Ad Aerts, Yanja Dajsuren, and Desiree van Oorschot for

providing me the opportunity of joining OOTI program and guiding my

professional and personal improvement. I also would like to thank professional

development coaches, Cynthia Schreuder and Sandra van Dongen for their

suggestions and feedback, which helped me a lot in the past two years and will

bring me more benefits in my future career. Moreover, I thank my technical

writing coach, Judith Strother, for her guidance of technical writing skills and

conscientious reviews of this report. I also would like to thank all my colleagues

from the OOTI program for the great moments that we experienced together.

Finally, I give my gratitude to my family and friends for their unconditional love

and support to my career.

Jie Wang

September 2017

vii

Executive Summary ASML is the world’s top supplier of photolithography systems, which are broadly

used by the semiconductor industries. In the systems, the hardware needs to be

moved with nanometer accuracy. This accuracy is achieved with the help of the

Metrology department that provides measurement and correction mechanisms

including functions and software.

In the past years, Metrology has developed several measurement and correction

mechanisms to improve the photolithography system accuracy. One of the

important mechanisms is the reticle heating control. However, because of the

increasing complexity of the functions and software, reticle heating control is

suffering from several issues:

- The software is hard to extend when adding new reticle heating

correction models;

- Switching between different reticle heating correction models costs a lot

of time, since the engineers need to shut down the machine, change the

software, deploy the software on the machine and start the machine

again.

It is getting increasingly urgent to solve these issues in order to improve the

machine accuracy.

This project focused on solving the problems that are mentioned above. It started

with stakeholder and problems analysis. Based on the problem analysis, it used

the 4+1 view model for creating the architecture and system design. Additionally,

several design patterns were introduced to the software framework. For example,

the Facade pattern was used to shield the RHC clients. The Abstract factory

pattern was used for creating different reticle heating correction models based on

a user configuration and switching between those models. The Bridge pattern was

used for different reticle heating correction models to follow the same abstract

interfaces of reticle heating correction model. For improving the data flexibility

of the reticle heating correction component, the data model was created with the

modeling tool ASOME. However, since the reticle heating correction data model

depends on data models used by other components that have not been delivered

yet, one subcomponent was designed to replace this data model.

In this project, a software framework was implemented and delivered, including

the replacement design of the data model. This software framework helps

improving reticle heating correction extensibility by providing a mechanism for

adding new models. Additionally, its online switch method for reticle heating

correction models could help the engineers to save a considerable amount of time.

In addition to these benefits, the software framework did not introduce negative

overlay impact to the legacy system, which has been proved by the backward

compatibility test.

This project is a feasibility project for concept approval. In the future, the results

will be used in the company product project, which will be planned by the reticle

heating control team.

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

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

1.1 Context ......................................................................................... 1 1.1.1. PDEng Software Technology Program ..................................... 1 1.1.2. ASML ........................................................................................ 1 1.1.3. Metrology .................................................................................. 2 1.1.4. Reticle ........................................................................................ 2

1.2 Assignment of This Project ........................................................... 3

1.3 Outline .......................................................................................... 3

2. Stakeholder Analysis ......................................................................... 5

2.1 Project Owner and Project Mentor .............................................. 5 2.1.1. Roles .......................................................................................... 5 2.1.2. Expectations .............................................................................. 5 2.1.3. Responsibilities ......................................................................... 5 2.1.4. Involvements ............................................................................. 5

2.2 Software Architects ...................................................................... 6 2.2.1. Roles .......................................................................................... 6 2.2.2. Expectations .............................................................................. 6 2.2.3. Responsibilities ......................................................................... 6 2.2.4. Involvement ............................................................................... 6

2.3 Software Engineers ...................................................................... 6 2.3.1. Roles .......................................................................................... 6 2.3.2. Expectations .............................................................................. 7 2.3.3. Responsibilities ......................................................................... 7 2.3.4. Involvement ............................................................................... 7

2.4 Functional Architects ................................................................... 7 2.4.1. Roles .......................................................................................... 7 2.4.2. Expectations .............................................................................. 7 2.4.3. Responsibilities ......................................................................... 7 2.4.4. Involvement ............................................................................... 8

2.5 Functional Engineers ................................................................... 8 2.5.1. Roles .......................................................................................... 8

x

2.5.2. Expectations............................................................................... 8 2.5.3. Responsibilities .......................................................................... 8 2.5.4. Involvement ............................................................................... 8

2.6 Supervisor from Eindhoven University of Technology ................. 8 2.6.1. Roles .......................................................................................... 9 2.6.2. Expectations............................................................................... 9 2.6.3. Responsibilities .......................................................................... 9 2.6.4. Involvement ............................................................................... 9

2.7 PDEng Trainee ............................................................................. 9 2.7.1. Roles .......................................................................................... 9 2.7.2. Expectations............................................................................... 9 2.7.3. Responsibilities ........................................................................ 10 2.7.4. Involvement ............................................................................. 10

2.8 Stakeholder Power and Interest Analysis ................................... 10 2.8.1. Project Owner .......................................................................... 10 2.8.2. Project Mentor ......................................................................... 10 2.8.3. Software Architect ................................................................... 10 2.8.4. TU/e Supervisor ....................................................................... 10 2.8.5. PDEng Trainee ........................................................................ 10 2.8.6. Functional Architect ................................................................ 11 2.8.7. Functional Engineer ................................................................. 11 2.8.8. Software Engineer ................................................................... 11

3. Problem Analysis ............................................................................. 13

3.1 Context ....................................................................................... 13

3.2 Reticle Heating Correction Problems ........................................ 13

3.3 Roadmaps ................................................................................... 14 3.3.1. Business Roadmap ................................................................... 14 3.3.2. Technology Roadmap .............................................................. 14

3.4 Design Opportunities ................................................................. 14 3.4.1. New RHC Model ..................................................................... 14 3.4.2. RHC Software Framework ...................................................... 14

4. Feasibility Analysis .......................................................................... 15

4.1 Added Values .............................................................................. 15 4.1.1. Software Framework ............................................................... 15 4.1.2. New RHC Model ..................................................................... 15

4.2 Issues and Risks .......................................................................... 15

4.3 Project Scope and Deliverables ................................................. 16

4.4 Project Milestones ...................................................................... 16

5. System Requirements ...................................................................... 17

5.1 Requirement Analysis Approach ................................................ 17

5.2 High-level Requirements ............................................................ 17

5.3 Detailed Requirements ............................................................... 17

6. System Architecture ........................................................................ 19

6.1 System Architecture Design ........................................................ 19

xi

6.1.1. Proposal 01 – Unified Interfaces ............................................. 19 6.1.2. Proposal 02 – Separated Interfaces .......................................... 19 6.1.3. Proposal 03 – Unified Interfaces with Common Module ........ 20 6.1.4. Design Decision ...................................................................... 21

7. System Design .................................................................................. 22

7.1 Introduction ................................................................................ 22

7.2 System Design ............................................................................ 22 7.2.1. System design with the separated data service ........................ 22 7.2.2. Replacement design of data service......................................... 23

8. Implementation ................................................................................ 25

8.1 Introduction ................................................................................ 25

8.2 Software Framework .................................................................. 25

8.3 Data Service ............................................................................... 25

9. System Validation ............................................................................ 26

9.1 Introduction ................................................................................ 26

9.2 Backwards Compatibility Test ................................................... 26

9.3 Throughput Test ......................................................................... 26

10. Conclusions ................................................................................... 28

10.1 Project Results ........................................................................ 28

10.2 Future Work ............................................................................ 28

11. Project Management .................................................................... 29

11.1 Introduction ............................................................................ 29

11.2 Overview Plan ........................................................................ 29 11.2.1. Initial Plan ............................................................................. 29 11.2.2. Final plan ............................................................................... 29

11.3 Work-Breakdown Structure (WBS) ......................................... 30 11.3.1. Initial Activity-Cost Estimations ........................................... 30 11.3.2. Real Activity Costs ................................................................ 31

Glossary ................................................................................................... 33

Bibliography ............................................................................................ 35

About the Author .................................................................................... 37

xiii

List of Figures

Figure 1 – Product history of ASML ............................................................... 2 Figure 2 – TWINSCAN machine .................................................................... 2 Figure 3 – Expose profile ............................................................................... 3 Figure 4 – Stakeholder power and interest grid ............................................... 11 Figure 5 – Reticle deformation ..................................................................... 13 Figure 6 – Architecture solution of Unified Interfaces ..................................... 19 Figure 7 – Architecture solution of Seperated Interfaces ................................. 20 Figure 8 – Architecture solution of unified interface with common module ...... 20 Figure 9 – System design with separated data service ..................................... 22 Figure 10 – Replacement design of data service ............................................. 23 Figure 11 – Initial overview plan .................................................................. 29 Figure 12 – Final overview plan .................................................................... 30

xv

List of Tables

Table 1 – Roles of Project Owner and Project Mentor ....................................... 5 Table 2 – Involvements of Project Owner and Project Mentor ........................... 5 Table 3 – Roles of Software Architect ............................................................. 6 Table 4 – Involvements of Software Architect .................................................. 6 Table 5 – Roles of Software Engineer ............................................................. 6 Table 6 – Involvement of Software Engineer ................................................... 7 Table 7 – Roles of Functional Achitect ............................................................ 7 Table 8 – Involvement of Functional Architect................................................. 8 Table 9 – Roles of Functional Engineer ........................................................... 8 Table 10 – Involvement of Functional Engineer ............................................... 8 Table 11 – Roles of Supervisor from Eindhoven University of Technology ........ 9 Table 12 – Involvement of Supervisor from Eindhoven Uinversity of Technology

............................................................................................................ 9 Table 13 – Roles of PDEng Trainee ................................................................ 9 Table 14 – Involvement of PDEng trainee ..................................................... 10 Table 15 – Project Scope .............................................................................. 16 Table 16 – High-level Requirements ............................................................. 17 Table 17 – Design decision for overview architecture ..................................... 21 Table 18 – Work-breakdown and estimations ................................................. 30 Table 19 – Real activities and their costs ....................................................... 31 Table 20 – Abbreviation ............................................................................... 33

1

1.Introduction

In this chapter, we analyze the context of this project to give a general introduction.

For example, what is the PDEng Software Technology program and what is the

history of ASML and its products? To zoom in, what is metrology and what the

metrology group works on. Additionally, we describe the software context and the

assignment context in the following sections. Finally, we explain what the following

chapters focus on.

1.1 Context Since the project is set up by the PDEng Software Technology program from

Eindhoven University of Technology and metrology group of ASML, We describe

the context of this project based on these two organizations.

1.1.1. PDEng Software Technology Program

The Software Technology of Professional Doctorate Engineering (PDEng) degree

program (OOTI in Dutch) is a two-year program [1], which is provided by the

Department of Mathematics and Computer Science of Eindhoven University of

Technology in the context of the 4TU.School for Technological Design, Stan

Ackermans Institute. During the two years, the trainees focus on strengthening their

technical and non-technical competencies related to the effective and efficient design

and development of software for resource-constrained software-intensive systems,

such as real-time embedded or distributed systems, in an industrial setting. In

particular, the PDEng program focuses on large-scale project-based design and

development of this kind of software.

1.1.2. ASML

ASML is a company, which was founded in 1984 by Philips and Advanced

Semiconductor Materials International. In same year, they launched the PAS 2000

(see from Figure 1) stepper, which was their first system. In 1986, they brought the

PAS 2500 stepper to market, which impressed the semiconductor industry with its

superior alignment technology [2]. Five years after they launched that turned out to

be their breakthrough platform, the PAS 5500, which reduced manufacturing times

for their customers. In 2001, they introduced the TWINSCAN system and its dual-

stage technology. These systems expose one wafer while the next wafer is already

being measured, which maximizes the productivity of the system as well as its

accuracy, boosting the value of ownership for their customers. Ten years later,

in 2010, they shipped the first NXE: 3100, a prototype Extreme Ultraviolet (EUV)

lithography tool, to the research facility of an Asian chip maker. This cutting-edge

technology uses light of a shorter wavelength than previous lithography machines,

meaning customers can image smaller features, and thus pack more transistors on a

chip, continuing Moore’s Law [3] (the observation that the number of transistors in a

dense integrated circuit doubles approximately every two years) [4].

https://en.wikipedia.org/wiki/Transistor

https://en.wikipedia.org/wiki/Integrated_circuit

2

Figure 1 – Product history of ASML

1.1.3. Metrology

Since the machine needs to be very accurate, any movement could cause some

impacts to the system. Several metrology strategies are introduced to the system. For

example, one of these strategies is to measure the movement and, based on the

movement impact to adjust the specific part of the machine. In this way, the influence

can be counteracted and the machine accuracy could be kept as the customer

expected. Figure 2 shows ASML’s main product TWINSCAN that currently sells on

the market. It is also the main product that metrology is working on.

Figure 2 – TWINSCAN machine

1.1.4. Reticle

From Figure 2, we can see the profile of the machine’s core part. It starts with the

light source, which is Deep Ultra Violet (DUV). The light goes through the Reticle,

which is a photomask made by the customer. In the Lens, several adjustments are

made for making sure that the light exposes the correct pattern on the Wafer. Figure 3

shows the exposure profile that is explained above. On the Reticle there is pattern

that the user wants to expose on the Wafer. The light comes from the top and goes

through the Reticle. After the Lens, the light exposes on a small area on the Wafer.

This procedure repeats until all the small areas are exposed. Later, the Wafer is

processed by other machines and cut to small pieces, which are chips that can be used

on electronic products.

3

Figure 3 – Expose profile

1.2 Assignment of This Project The main assignment of this project is:

- Provide software framework for RHC.

o Separate data and control logics to make data flow more flexible.

o Make software system switchable between RHC models.

o Provide structure for adding new RHC models to improve RHC

extensibility.

- Provide test deign for verifying and validating the solution.

1.3 Outline In order to understand the project context, we start with stakeholder analysis to

explain the role of all the stakeholders, their expectations for this project, and how

they could help. After that, in Chapter 3, we make the plan for how to involve the

stakeholders into the project. In the following chapter, we state the problems that the

customers have and what problems they want this project to solve. Furthermore, in

Chapter 4, we describe the feasibilities of this project to see what we could do.

Additionally, in Chapter 5, we analyze the requirements, which include both

functional requirements and non-functional requirements. In Chapter 6 and Chapter

7, we describe the system architecture and system design for solving customers’

problems. After these, we implement the design and explain the implementation in

Chapter 8. In addition to implementation, we verify and validate the system and show

the results. Then, we have the conclusion of this project in chapter 10. In chapter 11,

we explain our project management strategy and the milestones. In the last chapter,

we discuss the project retrospective.

5

2.Stakeholder Analysis

In this chapter, we analyze the stakeholders based on their roles and their

expectations. In addition, we discuss their input to this project and how are they

being involved in this project.

2.1 Project Owner and Project Mentor In this section, we describe the project owner and project mentor from ASML, as

well as the project ambassador.

2.1.1. Roles

Table 1 provides the analysis of the roles for each representative.

Table 1 – Roles of Project Owner and Project Mentor

Stakeholders Roles

Project Owner Defines the goal for this project

Funds the project

Defines the added business value for the company

Project Ambassador Manages the project communication between the

company and the university

Project Mentor Supervises the project and makes sure the project goals

are met on time and within the budget

2.1.2. Expectations

The expectations from the project owner and mentor are the following:

- Bring added value to the company;

- Finish the report on time;

- Deliver the Software Framework design and implementation on time;

2.1.3. Responsibilities

The project owner and mentor’s responsibilities are the following:

- Make the final decisions for this project;

- Guide the project progress and deliverables;

- Provide the needed knowledge or provide the contact person of the needed

knowledge.

2.1.4. Involvements

The way the project owner, project mentor, and the project ambassador are involved

in this project is described in Table 2.

Table 2 – Involvements of Project Owner and Project Mentor

Stakeholders Roles

Project Owner Project update meeting every two months;

CC project steering meeting minutes;

Project Ambassador Project steering meeting;

CC project steering meeting minutes;

Project Mentor Daily update meeting;

Review document;

Project steering meeting;

Update meeting every two months;

6

2.2 Software Architects Software architects have the overview of the system and technologies that are being

used. They could provide a lot of knowledge or suggestions, since the project is part

of the system.

2.2.1. Roles

In Table 3, we analyze the roles for each representative.

Table 3 – Roles of Software Architect

Stakeholders Roles

Sub-function

Software Architect

Make the subsystem architecture design;

Communicate with other subsystems;

Communicate with the corresponding functional team;

Communicate the subsystem architecture within the team;

2.2.2. Expectations

In the list below, we describe the software architect’s expectations.

- Improve the current design of the subsystem

- Make the subsystem switchable between different models

- Improve the extensibility of the subsystem and provide interfaces for adding a

new model

- Make it configurable for different models

- Make the corresponding simulator for the new design


The list below provides the responsibilities of software architect:

- Provide the knowledge or contact person of the current system

- Provide related documents of the current subsystem

- Review the new design and give feedback

2.2.4. Involvement

In Table 4, we list how the software architect was involved in this project.

Table 4 – Involvements of Software Architect

Stakeholders Roles

Software Architect Standup meeting;


Project steering meeting minutes;

Project update meeting every two months;

Document review;

Design discussion;

2.3 Software Engineers Software engineers know the specific technologies that the system is using.

Additionally, they have clear views of the engineering tools that the company is

using. So for the specific knowledge, the software engineers could help a lot.

Furthermore, this project provides a software framework that the software engineers

will use later. In this case, their opinions are very important input for the solutions

and the decisions.

2.3.1. Roles


Table 5 – Roles of Software Engineer

Stakeholders Roles

Software Engineer Make the function design and implementation;

7

Communicate the design with the subsystem architect;

Help to solve the problems of the current subsystem;

Provide improvement ideas for the team;

2.3.2. Expectations

The software engineers’ expectations are:

- Improve the subsystem for easy to maintain

- Update the document corresponding to the current system


The list below provides the responsibilities of the software engineers.

- Provide design and implementation knowledge of current subsystem

- Provide engineering knowledge of the company

- Help to review the documents

2.3.4. Involvement


Table 6 – Involvement of Software Engineer

Stakeholders Roles

Software Engineer Standup meeting;

Knowledge sharing meeting;

Document review;

Task board;

2.4 Functional Architects In ASML, most of the software requirements come from functional requirements.

The functional architects have a clear view of the requirements from the customer

and transform the customer requirements to functional requirements. Then they

extract which requirements need the help from software. So, actually, the functional

architects are the direct customer of the software.

2.4.1. Roles


Table 7 – Roles of Functional Achitect

Stakeholders Roles

Functional Architect Make the functional architect design;

Communicate the functional architect design with the

software team;


functional team;


other functional teams;

Provide feedback for software design;

2.4.2. Expectations

The list below describes software architect’s expectations:

- Offline testing

- Improved diagnostics of RHC configurations

- Mechanism to support rapid prototyping


The list below provides the responsibilities of the functional architect.

- Provide knowledge of corresponding functional design

- Provide expectations for software

8

- Help to review the document

2.4.4. Involvement

In Table 8, we analyze the roles of the representative.

Table 8 – Involvement of Functional Architect

Stakeholders Roles

Functional Architect Project scope definition meeting;

Review document;

2.5 Functional Engineers Mostly, functional engineers work together with software engineers to solve the

problems for the customer. They design the functional solutions and, if the solutions

need software to help, then they provide specific requirements to the software.

2.5.1. Roles


Table 9 – Roles of Functional Engineer

Stakeholders Roles

Functional Engineer Make the functional design and implementation;

Communicate with the functional architect;

Communicate with the corresponding software team;

2.5.2. Expectations

In the list below, we describe the functional engineer’s expectations.

- Provide interfaces for initializing, starting and stopping the model

- Provide interfaces to get/receive data

- Provide interfaces for adding new models


The list below provides the responsibilities of the functional engineer.

- Provide knowledge of the corresponding functional design and implementation

- Provide expectations for software


2.5.4. Involvement

In Table 10, we will analysis the roles for each representative.

Table 10 – Involvement of Functional Engineer

Stakeholders Roles

Software Engineer Project scope definition meeting;

Design discussion;

Weekly project meeting;

Review document;

2.6 Supervisor from Eindhoven University of

Technology The supervisor from the university is to help the trainee to finish this project both in

technical and non-technical aspects. He monitors the project status and provides

feedback for how to manage the project. Moreover, he helps to find the proper

solutions for solving the problem. Last but not least, he reviews the report and gives

feedback for how to improve it.

9

2.6.1. Roles


Table 11 – Roles of Supervisor from Eindhoven University of Technology

Stakeholders Roles

Supervisor from

Eindhoven University

of Technology

Supervise the project and make sure the project goals are

met on time

Director of PDEng

Software Technology

program

Manage trainees from PDEng Software Technology

program

Manage the final projects

2.6.2. Expectations

The list below describes supervisors’ expectations.

- Finish project on time

- Finish the report on time

- Meet the customers’ requirements


The list below provides the responsibilities of supervisors from Eindhoven University

of Technology.

- Provide software related knowledge

- Provide domain related knowledge

- Guide the project process


2.6.4. Involvement


Table 12 – Involvement of Supervisor from Eindhoven Uinversity of

Technology

Stakeholders Roles

Supervisor from

Eindhoven University

of Technology


Review document;

Direct of OOTI CC project steering meeting munities;

Comeback day presentation;

2.7 PDEng Trainee The PDEng trainee manages this project and the design solutions for solving the

problem. Additionally, she needs to implement the solution and verify if the software

solves the problem or not.

2.7.1. Roles


Table 13 – Roles of PDEng Trainee

Stakeholders Roles

PDEng Trainee Manage this project

Design and implement the software

2.7.2. Expectations

In the list below, we describe PDEng trainee’s expectations.

- Finish the project on time - Finish the report on time - Finish the deliverables on time

10

- Meet the software and functional requirements


The list below provides the responsibilities of the PDEng Trainee.

- Update the project to the stakeholders - Define the project scope with the stakeholders - Make the design and implementation - Write the report and send it for review - Provide the deliverables

2.7.4. Involvement


Table 14 – Involvement of PDEng trainee

Stakeholders Roles

PDEng trainee Standup meeting;

Project scope definition meeting;

Weekly project meeting;

Project update meeting every two-months;

Finding the solutions;

Implementing and Testing the solution;


Document writing and updating based on the feedback

2.8 Stakeholder Power and Interest Analysis Figure 4 shows the power and interest of each stakeholder. Based on the power and

the interests of each stakeholder, we make the project decisions and provide different

involvement solutions for different stakeholders [5].

2.8.1. Project Owner

The project owner is a group leader in this project. As a manager, he is rather

interested in the added values for ASML. However, he has the highest power to make

the decision for this project.

2.8.2. Project Mentor

As project mentor, on the one hand, he is very interested in this project. On the other

hand, he is supervising this project, so he has the power to make the decision both

technical and non-technical. He is the one who knows most of the project from the

company side. In another way, he is representing the company to participate in this

project.

2.8.3. Software Architect

The software architect has the full roadmap of the team, for example, the overview of

the system, the technologies currently being used, and the plan for the next step.

Since this project aims at solving the problems for his team, he will be very interested

in solutions and technologies that this project is going to use. However, as he does

not participate in this project directly, he mostly provides knowledge instead of

making decisions.

2.8.4. TU/e Supervisor

As the supervisor of this project, he is interested in this project. However, he does not

represent the customer. Mostly, he will provide support instead of making decisions.

2.8.5. PDEng Trainee

The PDEng trainee is fully involved in this project. She manages this project and

finds the solutions to help the customer to solve their problems. She provides the

11

solutions and knowledge. Additionally, for each problem, she proposes solutions.

However, the customers choose which solutions are going to be used and make the

final decisions for the project.

2.8.6. Functional Architect

Most of the software requirements come from the functional design. Therefore, the

functional architect is the important stakeholder of the software. He cares about the

software solution but not the details, and of course, he does not make the decisions

about the software.

2.8.7. Functional Engineer

The functional engineer works on specific functional problems. He works together

with software engineer to develop the solution. He is interested in the interfaces and

functions, but does not care about the software inside the implementation. Obviously,

he provides some suggestions in the functional view but does not make decisions

about the software.

2.8.8. Software Engineer

The software engineer has knowledge of specific functions of the system. Especially,

the software engineers who work on the same sub system with this project provide a

lot of knowledge and suggestions. However, they do not have the power to make

decisions about this project.

Figure 4 – Stakeholder power and interest grid

From the above analysis, which is based on interest and power, we see that the

project owner has the highest power to make decisions but he is not interested in the

project details. However, the project mentor and software architect are very

interested in this project, especially the technical solutions. Moreover, they are the

customers of this project, so they have a high power to make decisions. The

functional architect, the functional engineer, and software engineer, are working in

the company, so they have a lot of knowledge about the company. In this case, they

provide suggestions and help. However, since they do not participate in this project

directly, they have low power to make decisions. As the project manager and

designer, the trainee is very interested in this project, but has lower power to make

the final decision. The supervisor from the university is supporting this project both

in technical and non-technical aspects. However, he leaves the decision to the

company.

13

3.Problem Analysis

In this chapter, we present the stakeholders’ challenges and explain their relations to

the market.

3.1 Context As the technology develops, ASML’s customers want the lithography system to be

more accurate to produce high quality chips. Additionally, they want to keep high

throughput of the machine to quickly bringing chips to the market. That means for

the software, we need to control the machine with more accuracy. Heating created by

the system causes the reticle deformation, therefore, the image that is exposed on the

wafer is distorted. This causes the problem of low accuracy. From Figure 5, we see

the original reticle is the blue square, and the arrows indicate the deformation. To

improve the exposed image quality, we need to predict the deformation, and adjust

the control logic to avoid image distortion. [6]

Figure 5 – Reticle deformation

Furthermore, the current system was designed in 2010 without scalability in mind. As

a result of maintaining the system and fixing the bugs, the system changed a lot

beyond the original design. Now it is hard to maintain and extend it to add new

reticle heating correction models. In order to help the engineers to maintain the

system easily, as well as easily adding new models, redesigning the software

structure is needed.

3.2 Reticle Heating Correction Problems In this section, we list the reticle heating problems as below:

- Problems of current reticle heating correction models:

o Customer wants to improve the exposure accuracy

- Problems of legacy software:

o Legacy system was designed several years ago, not updated as the

software changed a lot

o It is hard to extend reticle heating control (e.g. adding new reticle

heating control models)

o Consumes a lot of time (turn down and start the machine) to make

some quick experiment (import and export data)

14

3.3 Roadmaps

3.3.1. Business Roadmap

Firstly, we find out the solutions, and test the solutions (software framework and the

new RHC model) on ASML’s proto machine. If it shows we achieved good results,

we start to develop on the customer branch and release versions to some of the

customers who are willing to try the new solutions. If it shows on the customer side

that we help them improve the production then we will release the version to all the

customers.

3.3.2. Technology Roadmap

For reticle heating correction model, the functional team tries to research new

solutions and make a functional design. If they find a solution that could help to

improve the reticle heating correction, they provide requirements to the software

team. After that, the software team starts the software design and implementation,

and test on the prototype machine.

For the software framework, we need to learn the current system and find solutions

for both the current models and models that will be added in the future. Additionally,

we will test on the proto machine.

If the test shows that the results are improved, then we will propose a production

project that will develop the solution on the customer branch and release new the

software to the customer.

3.4 Design Opportunities This section analyzes several design opportunities of solving the problems.

3.4.1. New RHC Model

Functional engineers proposed this model. Based on their analysis, they show that

this model will help to improve the deformation prediction. For the software team,

we define the execution sequences together with the functional team. Additionally,

we design the interfaces and data flow for this model to make it easy to maintain and

reuse.

3.4.2. RHC Software Framework

There are many design opportunities for a software framework. Firstly, we design the

interfaces and data flow for the reticle heating correction model to communicate with

other components. Secondly, since there are several reticle heating correction models

are being used currently and there will be more coming out, we need a mechanism to

manage these models and make them easy to configure for the customer. Finally, we

need an architecture that could allow the D&E engineers to quickly prototype and do

experiment, instead of shut down the machine and deploy another system on the

machine. Shutting down the machine and deploying the system on the machine will

cost a lot of time and money. Having this software framework could help to save

time and money for ASML. For example, when the software engineers want to test

several solutions on the machine and compare results, they firstly need to deploy one

solution on the machine. Then they need to run the machine and save the results. For

testing the next solution, they need to shut down the machine, and deploy the

solution. Then they need to run the machine again and save the results. If we have an

easy way to avoid shutting down the machine and deploying a new software system

repeatedly, we will save a lot of time for them.

15

4.Feasibility Analysis

Before starting this project, we need to analyze its feasibility. This chapter presents

the project feasibility in different views. The first one is the possible added values as

a result of this project. In other words, what benefits could this project bring to

ASML or ASML’s customers? The second view is the issues or risks that the project

will face. The third one is the project scope and deliverables. Finally, the project

milestones are given.

4.1 Added Values Here we analyze the added values of the software framework and the new RHC

model. We believe this analysis will be helpful later to make the decisions about the

project scope and requirements.

4.1.1. Software Framework

In the list below, we explain the added values of the software framework.

- Make RHC models easy to maintain;

- Make RHC models extensible for adding new models;

- Make the data flow flexible for adapting to the changing data type and size;

o A different RHC model needs different input data;

o Related components are changing data type and size;

- Long term benefits for the team and company;

o Save time and resources of maintaining the software;

o Save human resources for adding new models;

- Additional added values to the OOTI final project;

o It is an opportunity to learn technologies from the company;

o It is an opportunity to practice and improve design skills;

4.1.2. New RHC Model

For the new RHC model, we need to define the interfaces and implement in the

software system for proto testing. So the purpose is to determine if the model could

help to improve the prediction of reticle deformation. The added values of this

project for this model are:

- Verify the model on prototype machine;

- Make it generic for reusing;

4.2 Issues and Risks This section presents the issues and risks that affect this project.

- Initially, this study was planned as a part of internal ASML project, which has its

own milestones and deadlines. Some of the deadlines were in the middle of the

study.

- We defined the priority as first the software framework and then the new RHC

model. If this priority changes, it makes the software framework more complex.

After the design and implementation of the new RHC model, if we start design

the software framework, we need to consider adapting new RHC model.

- Currently, there are several models used in the system. If we want the software

framework to support these two models, we need time to learn them first. Based

on my problem analysis (see Chapter 3), we need to change them somehow in

order to make the software framework work with them.

- ASML has a procedure for the proto test. We need some time to follow this

procedure for preparing the patch and proto test.

- Based on OOTI’s final project schedule, we need to have the report ready in

August.

From the list above, we see there are some conflicts in the tasks and deadline. When

we define the project scope and deliverables, we need to consider them carefully.

16

4.3 Project Scope and Deliverables After discussing with the stakeholders about the added values and about the issues

and risks of their expectations, we developed a project scope. It is shown in Table 15.

Table 15 – Project Scope

Items Descriptions

Define and implement RHC model

Interfaces and data flow

Design the interfaces in a generic way.

Since many data is coming into the models and

going out to other components, a design for

data flow is needed.

Switch mechanism to specific RHC

model

Design a switch mechanism between models.

If new models come in, they should also be

switchable.

Structure for adding new RHC

models

Design and implement a structure for adding

new models.

The interface is dummy implemented, e.g.

return 0.

Configuration for RHC model –

both online and offline

This configuration is for the switch

mechanism. It switches to specific models

according to the configuration.

This configuration is dummy implemented.

Design and implementation of

database for the new RHC model is

out of scope of this project

This project focuses on the software

framework prototype;

The database design is not being covered.

Design and execute unit test Requirements are covered.

Implemented correctly.

Design and execute integration test Verify the Interfaces;

Design and execute system test Throughput test which helps to qualify the

model productivity;

Design and execute backward

compatibility test

Verify no overlay/ impact for RHC correction

models;

Black box system level test only;

Based on the project scope, we also defined the project deliverables as below:

- D1: Technical Report, which follows the report template from Eindhoven

University of Technology;

- D2: Prototype implementation of the RHC software framework;

4.4 Project Milestones Based on the project scope and deliverables explained above, we define the project

milestones as below:

- Project scope and deliverables, refer to D1 mentioned in the previous sub-

section;

- Project requirements and use cases, refer to D1 mentioned in the previous sub-

section;

- System design and implementation, refer to D2 mentioned in the previous sub-

section;

- System verification and validation, refer to D2 mentioned in the previous sub-

section;

17

5.System Requirements

This chapter provides the analysis of system requirements based on expectations of

the stakeholders. Additionally, we prioritize each requirement.

5.1 Requirement Analysis Approach In order to clearly define the requirements, we use MoSCoW method [7]. This

method is widely used in software development to reach a common understanding

with stakeholders on the importance of requirements. The categories are typically

understood as:

- Must have (M)

Requirements labeled as “Must have” are critical to the current delivery time

box in order for it to be a success. If even one “Must have” requirement is not

included, the project delivery should be considered a failure.

- Should have (S)

Requirements labeled as “Should have” are important but not necessary for

delivery in the current delivery time box. While “Should have” requirements can

be as important as “Must have”, they are often not as time-critical or there may

be another way to satisfy the requirement so that it can be held back until a

future delivery time box.

- Could have (C)

Requirements labeled as “Could have” are desirable but not necessary and could

improve user experience or customer satisfaction for little development cost.

These will typically be included if time and resources permit.

- Won’t have (W)

Requirements labeled as “Won't have” have been agreed by stakeholders as the

least-critical, lowest-payback items or not appropriate at that time. As a result,

“Won't have” requirements are not planned into the schedule for the

delivery time box.

5.2 High-level Requirements There are two high-level requirements are defined based on the project scope, see

from Table 16.

Table 16 – High-level Requirements

Requirement ID Description

HLR1 Prototype a software framework, in order to:

Improve the extensibility of RHC.

Improve the data flexibility of RHC.

HLR2 Design the data model for RHC based on DCA pattern

5.3 Detailed Requirements We divided the detailed requirements into two categories. The first one is functional

requirements, which describes the required functionalities of the software framework.

The second one is non-functional requirements, which explains the non-functional

aspects, such as extensibility and flexibility. The detailed functional and non-

functional requirements were included in the report for the company.

https://en.wikipedia.org/wiki/Timeboxing



19

6.System Architecture

This chapter describes the system architecture design for solving the problems

mentioned in Chapter 3. Additionally, we redesigned the interfaces for improving the

extensibility.

6.1 System Architecture Design This chapter gives the proposals for system architecture design in component level

[8]and the design decision is made based on the non-functional requirements, which

are mentioned in Chapter 5.

6.1.1. Proposal 01 – Unified Interfaces

In this architecture design, we propose to redefine the interfaces, and those interfaces

are implemented by different RHC models. In order to connect the model to the

interfaces, each model has some wrappers. In this case, the client communicates with

the RHC component by using of the unified interfaces, see Figure 6. It does not care

which model is going to be used.

Figure 6 – Architecture solution of Unified Interfaces

6.1.2. Proposal 02 – Separated Interfaces

This proposal describes the architecture design that for each model we have a group

of interfaces, see Figure 7. This means each model has the different interfaces. This

will save time of adjusting legacy source code. However, it needs more effort to

maintain several groups of interfaces. Additionally, the client needs to know which

RHC model is going to be used because for different models, it needs to use different

interfaces.

20

Figure 7 – Architecture solution of Seperated Interfaces

6.1.3. Proposal 03 – Unified Interfaces with Common Module

This proposal is similar to Proposal 01 that it keeps the unified interfaces for different

RHC models. However, the difference is that different models have several of the

same operations; for those operations, we put them in a common module Figure 8. In

this case, we need to reconstruct the legacy source code to separate model to specific

operations and common operations.

Figure 8 – Architecture solution of unified interface with

common module

21

6.1.4. Design Decision

Table 17 – Design decision for overview architecture

Items Unified

Interfaces Separated Interfaces

Unified interfaces

with common

module

Extensibility Rarely needs

new interfaces

More and more

interfaces will be

needed

Rarely needs new

interfaces

Flexibility Not so flexible

for different

models, because

they need to

adapt to these

interfaces

More flexible for

different models, since

they could define the

interfaces they need

Not so flexible for

different models,

because they need to

adapt to these

interfaces

Maintainabilit

y Less

maintenance

effort,

All the

maintenance will

be carried out by

each model, the

client does not

need to maintain

them

The client needs to

maintain the RHC

related operations, since

it needs to know the

model that is going to

be used

All the maintenance

will be inside each

model, the client does

not need to maintain

them

Additionally, it saves

the effort to maintain

the RHC models

Backward

compatibility More efforts

needed to keep

RHC backward

compatible

Since the interfaces for

the legacy code will

stay, it does not need

any effort to keep RHC

backward compatible

More effort needed to

keep RHC backward

compatible.

Furthermore, since

the legacy code is

reconstructed and

separated, it needs

more effort to keep

backward

compatibility

Performance Should be the

same as the

legacy code

Should be the same as

the legacy code

Should be the same

as the legacy code

Extra effort Less effort to

maintain

More effort for

keeping

backward

compatibility

More effort to add new

interfaces

More effort to maintain

Less effort for keeping

backward compatibility

More effort to

maintain the common

module

More effort for

keeping backward

compatibility

To summarize, based on the above analysis, we see that Proposal 03 could not only

save the maintenance effort but also reduce the source code redundancy, which allow

the system to reuse the source as much as possible. We decided to choose Proposal

03, which means to have the unified interfaces for different RHC models.

22

7.System Design

After making the overview design, in this chapter, we describe the design details in

different views to help to understand the system. Besides, several design decisions

are made in this chapter.

7.1 Introduction In the previous chapter, we made the architecture design for this system. However,

several detail points are not clear. In this chapter, we continue with the design and

focus on more details. Firstly, we give the generic class diagram to show the main

logics. Secondly, we analyze the proposals and give the decision of which design we

choose.

7.2 System Design This chapter states the different proposals for deployment. Additionally, we compare

different proposals and make the decision of which proposal we prefer to use.

7.2.1. System design with the separated data service

This proposal is to create an individual process for RHC component, see Figure 9.

Process1, which runs the client, communicates with Process2, where RHC is running.

This communication is via a group of interfaces that are implemented by RHC.

Figure 9 – System design with separated data service

Furthermore, ASML is using Data, Control and Algorithm (DCA) separation for the

sake of stable control interfaces and saving data communication time. In this design,

we also introduced this pattern by creating data repository, which is used for

managing the data for communication between different components. Additionally,

23

ASML is using a data modeling tool to create the data model and generate code. This

generated code actually is the main logic of the data service. We created the data

model for RHC, however, this data model is depending on the data models of other

components, and those data models are not delivered yet. As a result, we cannot

integrate the data model into this software framework until the dependent data model

is delivered. In order to test the other parts of the software framework, we proposed a

replacement design in the next sub-section.

7.2.2. Replacement design of data service

This section gives the proposal of the replacement design of the data service. On

Process2, we created a new component DataService to manage the data for

communicating between different components, see Figure 10. Additionally, we

defined the interfaces for data management (Interface2).

Since the dependent data models are being developed by other teams and they do not

have a clear delivery deadline yet, even though we have finished the data model

design, we cannot integrate the data model to the system. Only after the dependent

data models are delivered to the system, we can integrate our data model. In order to

test the system design that is proposed in the above sections, we need to think about

the replacement solution.

Figure 10 – Replacement design of data service

25

8.Implementation

The previous chapter explains the system design for solving the problems mentioned

in Chapter 3. This chapter describes how we implemented the system and what kind

of technologies we used.

8.1 Introduction From the system design we see that the software system could be separated into two

parts, the control logics and the data management logics. In the following two

sections, we explain them one by one.

8.2 Software Framework The software framework implementation utilizes some technologies that are used in

the company. The first one is the interface definition and the other one is inter-

process communication.

The company has its own interface definition language. There is a tool, which uses

the files, as input to generate C-types. Furthermore, the tool also can generate C++

and python interfaces. It is convenient to integrate the components that provide

different types of interfaces (C, C++ and Python). Based on this development

environment, we provided three types (C, C++ and Python) of interfaces, and the

internal logic was implemented in C++.

ASML has its own technology for creating process, which includes two steps:

- When defining the interface, specify the server (process) that implements this

interface.

- Define the class, which includes the interfaces that specified with the server.

8.3 Data Service The goal of data service is to manage the data that communicated between different

components or processes to avoid passing data via functions. The reason is that there

are many data passed between components or processes. Those data brings several

problems to the system. The first problem is that the data size and data type are

changed based on the technologies, the software interfaces needs to be changed

frequently, in order to cooperate with the changing data size and data type. The other

problem is that big data will cost more time for inter-process communication.

Therefore, we introduced data service to manage the data to avoid the impacts that

introduced by the above problems.

The data service manages the data by different structures. These data structures keep

similar mechanism as the entities from the data model, which is being developed with

ASOME. In this case, if the data model is finished, it could replace this

implementation easily.

For each data entity, the data service generates a unique data id. The unique data id is

passed to the component, which creates the data. Then the data id is used for inter-

component or inter-process communication. The component, which receives the data

id, gets the data from the data service by the data id.

26

9.System Validation

In this chapter, we give the verification and validation strategy to make sure the

design and implementation satisfy the requirements. Additionally the test plan and

results are presented.

9.1 Introduction The previous chapter described the design and implementation for how to solve the

problems that mentioned in Chapter 3. However, only those cannot make sure that

the design and implementation satisfies the requirements and helps to solve the

problem well. This chapter is focusing on validating the design and implementation.

Since we moved one RHC model from the legacy code to this system, we propose to

test its backward compatibility to make sure that the RHC model works as well as the

legacy code. Additionally, we introduced new process to the system. As we know,

inter-process communication consumes more time. In order to validate if the system

still fulfills the productivity requirements, we introduce productivity test.

9.2 Backwards Compatibility Test As mentioned above, we plan to test the backward compatibility for this system,

because we separate RHC model to another process, and we want to check if the

RHC model works as well as before. Currently, the software team has a RHC specific

method to test the software backward compatibility. The method is to test with and

without the changes, and measure and compare the overlay.

i. What to test?

The main purpose of backward compatibility test is to make sure the system

with the new changes works as well as old system that without those new

changes. We need to measure the system overlay for comparing the overlay

from with and without the changes to see the differences.

ii. How to test? Firstly, we measure the system overlay with and without the software

framework to see their differences. In order to make sure the test results are

valid for comparison, the test should be executed on the same platform with

the same user configurations.

iii. What are the results?

We processed one group of wafers by the legacy software and the other

group of wafers with the software framework, and got two groups of results.

By comparing overlay impact, we see that the differences between those two

groups of results are below 5×10-8nm, which can be ignored. This means

the software framework does not introduce overlay impact to the system,

and it is backwards compatible.

9.3 Throughput Test Throughput is a very important requirement of the customers. Since we introduced a

new software framework for RHC, we need to verify if RHC throughput still satisfies

customers’ requirements.

i. What to test?

From the above explanation, we see that we need to verify the RHC

throughput. Furthermore, we introduced new process for RHC and as we

know, inter-process communication consumes additional time. Therefore, in

throughput test, we focus on the inter-process communication to verify the

time consumptions.

ii. How to test? ASML has a mechanism to test the throughput of the software system and a

throughput view tool to analyze and visualize the throughput. For the

convenience of communication with stakeholders from the company and

27

saving cost (ASML has the tool), we use them for RHC throughput test as

well.

iii. What are the results?

The results were analyzed statistically based on the mean cost of time,

standard deviation, etc.

28

10. Conclusions

In this chapter, we make the conclusion of this project by results and future work. We

analyze the project results and the benefits we could achieve. Additionally, we

describe the work that need to be done in the future.

10.1 Project Results This section describes the project results and explains what benefits we can get from

the results of this project:

i. Software Framework In the software framework design, we introduced a couple of design patterns

and other technologies for solving different problems. Firstly, we created a

new process for RHC, which isolates RHC from its client component. For

easily managing the RHC models, we introduced abstract factory and bridge

pattern to help the engineers adding new models and connecting the new

models to the software framework. These design patterns could help to

improve the extensibility of RHC model. For improving the data flexibility

of RHC, we introduced data model based on DCA pattern that is used in

ASML to separate data and control.

ii. Documentation

Besides the software framework, we updated technical report, which

includes stakeholder analysis, problems analysis, requirement analysis,

system architecture, system design, system verification and validation, and

ends up with project management. This report could help people who are

interested in this project to get more details and understand the software

framework.

10.2 Future Work In this section, we described what should be done in the future to help to improve the

RHC system:

i. Integrate to production system

As mentioned before, this project is feasibility project for concept approval.

From the previous section, we see that the software framework could help to

improve the extensibility and flexibility for RHC. Meanwhile it could save

time for engineers to do quick experiment on the machine. After the concept

approval, the RHC software team plans to add the software framework to

the production system.

ii. Plugin architecture verification

As mentioned before, currently, there are several RHC models have been

added to the TWINSCAN system. With the software framework design, at

one time, only one RHC model will be used. For other models, we only load

them to the memory but do not use them, which actually is a wasting of

memory. If we could just load the model that we need to use then we could

save a lot of memory. This is possible by using plugin architecture, which

needs to be verified.

29

11. Project Management

This chapter explains our project management process. We firstly give the overview

plan to describe what are planned in the project and the milestones. Then we

elaborate the work breakdown structure to explain the activities and the cost

estimation for each of them. Additionally, we compare the estimation and the real

costs.

11.1 Introduction We have two ways to manage the project. The first way is on the overview level. We

make the overview plan to keep track of the main tasks monthly and we review it on

every project steering meeting. The second way is based on the main tasks, we make

a breakdown structure and we manage the breakdown structure on JIRA [9]. JIRA is

a proprietary issue-tracking product, which is used by ASML for issue tracking and

project management. We use this tool for two reasons. One is the company has the

license. The other one is that it is convenient for communicating with the

stakeholders and customers who are working in the company.

11.2 Overview Plan

11.2.1. Initial Plan

At the beginning of this project, we made the overview plan for keeping track of the

main tasks and allocating the time for the main tasks. For final project, we need to

finish it at the end of September. Therefore, we made the initial overview plan as in

Figure 11. We planned to get the stakeholder list before 15 January and to finish the

project scope definition at the end of January. In February, we planned to work on

the requirements and finish the requirement analysis at the end of February. From the

beginning of March, we planned to work on the design and finish the design before

May. Furthermore, we planned to finish the implementation before the middle of

June. After that, we planned to finish testing in July. Then we planned to work on the

documents and knowledge transfer.

11.2.2. Final plan

From the previous sub-section, we see that our initial plan is based on the waterfall

approach. It is not flexible to the fast changing situation in the company. Therefore,

we extended the initial plan as shown in Figure 12. From Figure 12, we see that there

are overlays between the main tasks. That is because we have small v-models under

the plan. For example, we made part of the design and implemented it. After the

implementation, we tested it. If it needs to be improved, we start the next v-model to

refine the design, implement and test again. Meanwhile, we also updated the tasks on

reports.

Figure 11 – Initial overview plan

https://en.wikipedia.org/wiki/Proprietary_software

https://en.wikipedia.org/wiki/Issue_tracking_system

30

11.3 Work-Breakdown Structure (WBS) In this section, we give the activity cost estimation based on the work breakdown

structure. Since we manage those activities on JIRA, we give the Cumulative Flow

Diagram and analyze the specific situations that we met.

11.3.1. Initial Activity-Cost Estimations

Table 18 shows the activity cost estimation that was made at the beginning of this

project. We group the activities as stakeholder and requirement analysis, design,

implementation, test design and execution, and documents. The total cost is 31

weeks.

Table 18 – Work-breakdown and estimations

Activity Group Activities Deliverables Est.

(weeks)

Stakeholder and

requirement

analysis

Collect stakeholders’

expectations.

List of stakeholders’

expectations

3

Define the project

scope.

Decision and Document 1

Requirement

specification

User requirement and use

cases

3

Design Learn legacy code. Class diagram 3

Architecture design Proposals and decisions 2

System design

Class diagrams, sequence

diagram, deployment

diagram and design

decisions

2

Data model design Data flow and Data model

by ASOME

2

Implementation Interface definition

(Create new driver

Data service)

Source code of interface

definition and

corresponding generated

files

1

Switch mechanism Source code of switch

mechanism

1

RHC model interfaces Source code of RHC

model interfaces

1

Migrate the legacy code Integrate the legacy code

and make it switchable

2

Figure 12 – Final overview plan

31

Separate the legacy

code with different

RHC models

Separate RHC models to

different modules

2

Test design and

execution Test RHC Productivity

Test design and results

analysis

1

Test RHC backward

compatibility


analysis

1

Technical report Technical report 3

Documents Public report Public report 2

Final presentation Presentation 1

Total 31

11.3.2. Real Activity Costs

As the project was going, we found that some of the activities needed to be refined

and some other activities needed to be added. Table 19 shows the real cost.

Table 19 – Real activities and their costs

Activity Group Activities Deliverables Cost

(weeks)

Stakeholder and

requirement

analysis

Collect stakeholders’

expectations.

List of stakeholders’

expectations

2

Define the project scope. Decision and

Document

1

Requirement specification User requirement and

use cases

2

Design Learn the system and

legacy code.

Class diagram 5

Learn the data flow Data flow diagram 1

Architecture design Proposals and

decisions

1

External interface design Interfaces 1

System design

Class diagrams,

sequence diagram,

deployment diagram

and design decisions

2

Data model design Data flow and Data

model by ASOME

2

Implementation

Interface definition

And create new driver

Source code of

interface definition

and corresponding

generated files

2

Switch mechanism Source code of switch

mechanism

1

RHC model interfaces Source code of RHC

model interfaces

1

Migrate the legacy code

Integrate the legacy

code and make it

switchable

2.5

Data service

Source code of the

replacement design for

data service module

2

Test design and

execution Test RHC Productivity


analysis

2

Test RHC backward

compatibility


analysis

2

Technical report Technical report 4

Documents Public report Public report 2

32

Final presentation Presentation 1

Total 35.5

The real costs are more than the estimations. The first reason is that the first month of

the project, people were still on holiday. We spent the first month to learn the

TWINSCAN system and attended some introduction courses. Actually, we started to

work on this project from February. The other reason is that it cost more time to learn

the engineering technologies that are used in the company. Furthermore, we did not

plan many tasks for data management, but we found that in order to test our design,

we must have the data management module. So we added some tasks for data service

module.

33

Glossary

Table 20 – Abbreviation

Abbreviation Description

4TU.School

The four universities of technology (TU Delft, Eindhoven

University of Technology, University of Twente, and University

of Wageningen)

ASML ASML Netherlands B.V.

ASOME ASML Software Modeling Environment

B.V. Besloten Vennootschap (Limited, Ltd)

DUV Deep Ultra Violet

EUV Extreme Ultra Violet

JIRA A proprietary issue tracking product, developed by Atlassian

NXE NXT with Extreme Ultra-Violet

NXT New Generation TWINSCAN

PDEng Professional Doctoral Engineering

QR code Quick Response Code

RH Reticle Heating

RHC Reticle Heating Correction

WBS Work-Breakdown Structure

35

Bibliography

[1] Eindhoven University of Technology, "PDEng Software Technology," [Online].

Available: https://www.tue.nl/en/education/tue-graduate-school/pdeng-

programs/pdeng-programs-overview/pdeng-software-technology-st/.

[2] ASML, "History," [Online]. Available:

http://www.asml.com/asml/show.do?lang=EN&ctx=277&rid=51985.

[3] G. Moore, "Moore's Law," [Online]. Available: http://www.mooreslaw.org/.

[Accessed 11 06 2015].

[4] ASML, "Our products," [Online]. Available:

http://www.asml.com/asml/show.do?lang=EN&ctx=51431&dfp_fragment=strat

egy_1. [Accessed 12 06 2015].

[5] "Stakeholder Management," [Online]. Available:

https://en.wikipedia.org/wiki/Stakeholder_management.

[6] H. Pavlovska, EDS metrology reticle heating correction, Veldhoven: ASML,

2015.

[7] D. Haughey, "MoSCoW Method," [Online]. Available:

http://www.projectsmart.co.uk/moscow-method.html. [Accessed 03 February

2015].

[8] D. Pilone and N. Pitman, "Component Views," in UML 2.0 in a Nutshell,

O'Reilly, 2005, p. 93.

[9] Atlassian, "Integrating and Development Tools," Atlassian, [Online]. Available:

https://confluence.atlassian.com/adminjiraserver070/integrating-with-

development-tools-776637096.html. [Accessed 20 January 2017].

37

About the Author

Jie Wang received her Bachelor degree of Computer

Science from Zhengzhou University in 2007. In 2011 she

received her Master degree of Computer Engineering

from Huazhong University of Science and Technology.

During her master study she mainly focused on the

research of video transcoding and communication. Her

Master thesis, “Transrating-Assisted Spatial Resolution

Conversion Methods for Compressed Videos (TRAC)”

was finished in the Multimedia Laboratory. After

graduation she worked as a software engineer at Tencent

in China and her work focused on improving video

communication quality and user experience. After 3 years

working at Tencent, she decided to join Software

Technology (ST) designer program, which is provided by

Eindhoven University of Technology. In January 2017,

She started her nine-month final project at ASML

Netherlands B.V., in partial fulfillment of the

requirements for the degree of Professional Doctorate in

Engineering (PDEng) at the Eindhoven University of

Technology.

38

Date post:	15-Apr-2022
Category:	Documents
Upload:	others
View:	11 times
Download:	0 times