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 be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author 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 General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and 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, please follow below link for the End User Agreement: www.tue.nl/taverne Take down policy If you believe that this document breaches copyright please contact us at: [email protected]providing details and we will investigate your claim. Download date: 15. Apr. 2022
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
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
11.2 Overview Plan ........................................................................ 29 11.2.1. Initial Plan ............................................................................. 29 11.2.2. Final plan ............................................................................... 29
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
In Table 11, we analyze the roles for each representative.
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
2.6.3. Responsibilities
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
- Help to review the document
2.6.4. Involvement
In Table 12, we analyze the roles for each representative.
Table 12 – Involvement of Supervisor from Eindhoven Uinversity of
Technology
Stakeholders Roles
Supervisor from
Eindhoven University
of Technology
Project steering meeting;
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
In Table 13, we analyze the roles of the representative.
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
2.7.3. Responsibilities
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
In Table 14, we analyze the roles of the representative.
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;
Project steering meeting;
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.