Description diagnosis process
In order to describe the actual primary process of solving an unscheduled down a detailed reconstruction of a Long Down Time unscheduled down (LDT) has been performed. A LDT is an unscheduled down that lasts longer than eight hours in a row. Describing a LDT has been done by selecting a relevant and representative LDT and by interviewing the actors of solving the LDT. The customer site Infineon in Dresden has been chosen to conduct this research since many LDT’s occurred at its machine park. It is acknowledged that the selected LDT and customer site may have its own distinctive characteristics.
Some characteristics of this case study, therefore, can not be seen as completely representative for all LDT’s at all customer sites. This issue will be discussed at the end of this appendix. It is believed however that the process of solving the LDT in this case study gives a reasonable insight on how unscheduled downs are solved at other customer sites.
Site background
The man-machine ratio at the Infineon site has been reduced the last two years from effectively three people for eight machines (1:2.5) to effectively one Field Service Engineer (FSE) for nine machines (1:9). The decrease of the man-machine ratio can be explained, because many FSE’s and 2
ndline engineers went to the XT and fab 36 and no additional engineers were contracted. The man-machine ratio is fixed in the service contract with the customer. Infineon had decided to spend less money on labour costs, which resulted in a decrease of the man-machine ratio. In practice there is only one FSE present in the fab, where two engineers are scheduled (this is due to training, vacations, and illness). The FSE’s work in three shifts (scheduled 6 people a day) and in total there are 10 FSE’s working at the Infineon site. Since one year the preventive maintenance on all machines is done by the customer (see figure A1). The machine park at the Infineon site has two special characteristics. There are two machines on which research is done in daytime, and there is one pilot machine. Pilot machines have relatively more problems due to their technological immaturity.
Next to the fact that the Infineon site has many LDT’s, the site is interesting for another reason. As already mentioned, the site has a man-machine ratio from 1:9, which corresponds with the future target set by the ASML headquarters for all Twinscan sites.
The Infineon site is one of the few sites in the world who already has their man-machine ratio in line with the ASML target. It is interesting to see what difficulties come forward when applying the target man-machine ratio. Furthermore the bottlenecks with regard to solving unscheduled downs are more clearly visible when the man-machine ratio is low (1:9), than when the man-machine ratio is high (1:2).
Case study background
The Long Down Time which is used as a case study in this research is the LDT of the
1250 Twinscan. One important limitation of the description of the LDT is that it was not
possible to interview every FSE who has worked on the LDT. The reason for this is that
the machine went down for approximately eighty hours starting from the early shift on 15
December and ending the late shift of 18 December 2004.
In the process of solving the LDT four to five different FSE’s have been working on the LDT in eleven shifts of eight hours. Due to the high work pressure the FSE’s were very occupied and did not have much time for interviews. The 1250 Twinscan is a pilot machine and has been installed at the Infineon site since march 2004. A pilot machine means that it has passed the prototype phase (by developers in the headquarters), but it has not yet been put into (mass)-production. A pilot machine is placed at the customer where it is carefully monitored for a specific period and lessons of the machine are used to improve the machine design. The monitoring is done by the New Product Introduction (NPI) department of Customer Support at the headquarters. When a pilot machine is introduced the FSE’s and 2
ndline engineers are additionally trained, the machine is introduced at the customer site, and additional support is available. Since October the intensive monitoring of the 1250 by the NPI department has been reduced and the machine is managed the same as the rest of the machine park.
A1. Subdivision of total machine time
The case study will be described by focusing on the role of each type of actor in the total unscheduled down process (see Appendix C). Each actor type has to take various steps that can be subdivided in input, transformation, and output related actions (see figure A2). The steps that each actor type has to take are graphically represented in a so-called Actor Activity Diagram.
A2. Link input, transformation, and output process Infineon
When a machine goes down the first actor who is involved in the unscheduled down solving process is the customer.
Transformation
Input Output
operation engimeer customer
maintenance engineer customer
Noticing machine unscheduled
down
C
VerbalC
(face to face or by
phone) Register
down?
Collect information
down
Perform fast start-up
C
Describeproblemverbally (first by phone later face to
face) Register
down?
Figure A3. Infineon process unscheduled down
solving
Input
When a machine goes down an alarm signal goes off and the Infineon production engineer is informed. Sometimes when a machine goes down it fails to give an alarm signal. This might happen when there is an error on the product itself. In this case it may take for about an hour for the Infineon production engineer to notice that the machine is malfunctioning.
Transformation
When an Infineon production engineer has noticed that a machine is down, he will inform the Infineon maintenance engineer about the unscheduled down. The customer maintenance engineer first collects and stores all the data in an information system called Logfinder in order to get a clear picture of the problem. When the information about a down is not logged properly, performing a fast start-up loses essential information. This is especially the case when the cause of the down is software related. If the logging of information is always done correctly has not become clear in this study. After the data has been collected the maintenance engineer performs a fast start-up. In about 60% of all downs the machine functions normally after a fast start-up has been performed.
Output
All information about the down is stored in Logfinder, which can be accessed on the machine. Furthermore, the customer books the time of the down in the customers’
information system. The reason for this is to determine the performance of how long it takes to solve unscheduled downs. It is not clear how the time of the down is administrated: when the Infineon production engineer discovers the down, or when the Infineon maintenance engineer is informed. There may be a substantial time lag between the time in which the production engineer discovers the down, when the Infineon maintenance engineer is informed, and when the ASML FSE is informed. It may occur that when the ASML FSE is called, the machine is already down for two hours. This may be attributed to the performance of ASML.
When the fast start-up fails the Infineon maintenance engineer escalates the problem to the ASML FSE.
The customer has a rather limited definition on what actions are necessary in order to solve unscheduled downs. Only visible actions on the machine are regarded as productive. Some necessary actions in order to solve the LDT efficiently, such as information gathering, are considered by the customer as unproductive and thus idle time.
Scheduled downs
As already mentioned, the customer performs the preventive maintenance part of the total
process of the ASML-machines since one year. Most customers at other sites do not
perform the maintenance of the machines themselves. Doing the preventive maintenance
on the machines, makes the customer also responsible of the first crucial steps of data
collection and diagnosis of downs. The customer has to collect information and performs
a fast start up. When the maintenance task of the machines has been transferred to the
Infineon maintenance engineers, they had to be additionally trained by ASML. Still the
skill level of the Infineon maintenance engineers is not always sufficient.
Infineon does not have access to the spare parts, so the maintenance engineers cannot perform spare part swap actions. They only have access to consumables such as filters.
But even here are sometimes problems with installation. At a filter swap action problems occurred because the Infineon maintenance engineer was not skilled enough. In this case the ASML FSE’s are assumed to help the Infineon maintenance engineers to adequately perform the maintenance. In general the ASML FSE’s are obliged to assist and train the Infineon maintenance engineers in maintenance, next to their current work load.
Field Service Engineers
Input
When a down machine cannot be fixed by the Infineon maintenance engineer, the ASML field service engineer (FSE) is involved. This is usually done by calling the FSE on his mobile phone. If an FSE is on duty he can be in the clean room where he performs actions on the machines or he can be in an office at the Infineon site. This office is physically separated from the clean room for about a ten minutes walk. Furthermore, when an FSE travels from the clean room to the office and back, he has to change clothes.
In this office there is an Ethernet connection to the ASML network.
Figure A4. Field Service Engineer process unscheduled down Communicate information by phone and
C C1
Communicate progress problem solving
field service engineer AMSL
second line engineer ASML
C
maintenance engineer customer
Diagnose down, run tests, swap
parts
Escallate in ASML-Q &
verbally
C
Describe problem verbally (first by phone later
face to face)
C
C
Run tests &
collect data for 2nd line engineer
Administrate actions
C
Next to the office at the customer site there is also an Infineon terminal where emails can be sent and received. The disadvantage is that on this terminal no ASML applications are available. Furthermore, there are a few computer terminals in the Infineon clean room, but these are not always available.
The most important input in the transformation process of unscheduled downs is the FSE who attempts to fix the machines. Their capability to successfully do this depends from two factors: the FSE’s experience and training level. The FSE’s at the Infineon site are considered to be fairly experienced: most FSE’s work in the clean room for two to three years. Since the last reorganisation many experienced FSE’s left or were transferred (for example to the regional office). According to one FSE most problems are tackled by experience.
In order to get a clear picture of the machine down, there are various information sources which the FSE can use. Firstly, he can use Logfinder on the machine to retrieve all background information about the down. Many tests on the machine may also provide information. The information on the machine is said to be the most important source of information for solving unscheduled downs. The FSE can also communicate verbally with the Infineon maintenance engineer in order to get more background information of the situation. Finally, the ASML network databases Coach and Problem Cause Solution (PCS) can assist the FSE in finding information about similar problems and how these may be solved.
It is said that there are difficulties to get Coach-updates in the office at Infineon. This might take up to six hours due to a slow connection. This is an Ethernet-connection, which is able to deliver twice an ISDN speed (256kb). This is considered as too slow by the FSE’s, and in practice Coach is only updated when the FSE’s are in the regional ASML office. Since the FSE’s do not regularly visit the regional office their Coach database is not updated most of the time. In the two days that the case study has been described in the clean room the use of (databases on) laptops has not been observed.
There is a big separation between the FSE’s at the customer site and 2
ndline engineers in the office. Some FSE’s do not go to the regional office for one and a half month. This might be a problem since they are not fully aware of what goes on in the regional office.
The FSE’s do get emails, which keep them up to date, but due to an information overload not all emails are read.
The description above focused on the process of when a down is first identified. But as
already mentioned in the background of the case study, FSE’s work in shifts and
unscheduled downs may last longer than an eight hour shift. In this case information and
knowledge about a down must be transferred from one FSE to the next FSE. This is done
by organising an overlap in shifts of half an hour. In this half hour the FSE has time to
communicate which machines had what problems, what actions have been taken, and
what actions still have to be done. In order to have a complete picture of what has been
done on the machines the passdown report is used. Every FSE writes a passdown report
at the end of his shift, although this is not always (correctly) done. The basis for the
passdown report is the logbook on the machine. In the logbook all actions and tests on the
machine are administered and this is mainly for internal use.
Added to the passdown report is an Excel sheet where additional information about the machines is stored, such as Field Change Orders (FCO’s) or patches which need to be installed.
Transformation
With the available information the FSE tries to solve the problem on the machine. Here verbal communication plays an important role. FSE’s estimate that waiting for parts, recovery sequences, and waiting for response from the headquarters consume the most time when solving unscheduled downs. The diagnostics itself is said to consume for about 10%-20% of the total problem solving time. The latter is an interesting remark, since the headquarters assumes that diagnosis consumes for about 50%-60% of all problem solving time. Finally, it seems to be very difficult to give a practical definition of what diagnosis exactly means. For example, is running a test considered to be diagnostics? Is the escalation of an unscheduled down to 2
ndline engineers considered diagnostic time?
Diplomacy is felt to be an important part of the daily job of an FSE. When a machine is down the customer expects that the FSE is continuously busy with actions on the machine. In reality the FSE sometimes has to wait for diagnostic data from the regional office or headquarters or he has to wait for spare parts to arrive. In order to give the impression that work is being done on a down machine, the FSE sometimes starts up some diagnostic tests.
When multiple machines are down at the same time the FSE has to work on the machine which has the highest priority for the customer. A machine with a lower priority is then down for a considerable time. This is booked as a LDT for ASML.
One explanation by the FSE’s for the long LDT’s is that there is limited support from 2
ndline engineers and the headquarters at night and in weekends. If a machine goes down at this time, and the FSE on duty does not know how to solve the problem the unscheduled down time increases rapidly. At nights there is 2
ndline support from the US headquarters in Tempe, but this support is not considered as helpful. There are two reasons for this.
First, it is felt that Tempe gives priority to escalations from the US. Second, the quality of support is seen as insufficient. The feedback from Tempe is seen as useful for getting ideas about the problem, though. When Tempe is contacted this is mostly done when everything else has failed. In order to overcome the lack of support, 2
ndline engineers sometimes create an action plan that FSE’s can follow when a machine is down. The advantage of this is that the FSE can analyse, isolate, and possibly solve a problem when no 2
ndline engineers are available.
Output
The main output of the unscheduled down are a passdown report and call-id in ASML-Q
when the unscheduled down is escalated. The passdown reports are the input for the
performance co-ordinator at the regional office. In interviews the performance co-
ordinator has complained about the quality of the output of the FSE’s. For example, the
passdown reports often do not contain all actions that are taken, the times of the actions,
and sometimes the passdown reports are not sent. The administration of the times of the
actions in the passdown reports is subjective.
Regional office
The actors in the regional office are next to the 2
ndline engineers also for example a performance co-ordinator who monitors machine performance, and a customer support supervisor who operationally manages the FSE’s and the 2
ndline engineers.
Input
When the problem is escalated to the 2
ndline engineers the data about the down will be transferred in a call-id. Next to this official escalation, the FSE on duty will informally call to the regional office in order to make sure that they are aware of the unscheduled down.
The sources of information for the regional office are as follows. The first source of information is the FSE. The FSE gives information about the down usually by mobile phone. Another important source of information for the 2
ndline engineers is the machine itself. The 2
ndline engineers sometimes have a direct connection to the machine in order to remotely run tests and download data. Further sources of information about a down are the results of tests on the machine that can be collected by FSE’s by instruction of the 2
ndline engineer. The event log viewer collects all the machine data on the machine which can be assessed by the customer and the FSE’s in the clean room. The event logs are also uploaded at nights to the database of the headquarters where it can be remotely and easily accessed and downloaded by all engineers. Other information about unscheduled downs can be collected from the logbook and the Call Identification Number (CID) in ASML-Q.
When the performance co-ordinator has analysed the data of an unscheduled down, this is passed on to the responsible 2
ndline engineer.
Figure A5. regional office process unscheduled down solving
Escallate in ASML-Q &
verbally Communicate
information by phone and email
C field service
engineer AMSL
second line engineer
ASML
third line engineer ASML
C
Diagnose down on site:
run tests, swap parts (possible with
FSE) Diagnose
down at office: if necessary return to C1
C C
C
C Communicate
progress problem solving maintenance
engineer customer
Transformation
As came forward from the research, all unscheduled downs that are escalated to the regional office should first be handled by the performance co-ordinator. If there is a long down the performance co-ordinator will analyse the data of the down. After this he will check in PCS if it is a known problem. Sometimes he gives procedures from the PCS to FSE’s by phone. When a problem is located to a specific subsystem, the problem is passed on to the responsible 2
ndline engineer. It is not clear, if the FSE on duty always calls the performance co-ordinator or that he directly calls a 2
ndline engineer. The same is true when a 2
ndline engineer is already in the clean room when a machine goes down.
When a down is escalated to the regional office, the relevant people (such as customer support supervisor) are informally informed in an early stadium.
When an unscheduled down is escalated to the 2
ndline engineer, the background information about the down is transferred mainly by communication by phone. The next step is that the 2
ndline engineer asks for additional information from the FSE such as the call-id and results from tests of the machine. The 2
ndline engineers feel that not always all necessary data has been (properly) collected. When this is the case the 2
ndline engineer must wait until the FSE has collected the data or he has to collect the data himself. When the necessary data is collected the 2
ndline engineer may send a procedure, which has to be followed by the FSE in order to determine the root cause of the problem.
Small procedures are usually passed on by phone and more complicated procedures are sent by email. When this is done and the machine is still down the 2
ndline engineer may go into the customer site. He can do this in an earlier stage when he feels that this is necessary.
When the 2
ndline engineer is on site working on the unscheduled down, the FSE is not always involved. For example, when a 2
ndline engineer was working on the unscheduled down, he did not involve the FSE about his actions. The FSE felt that he was able to perform some actions on the machine, but the 2
ndline engineer chose to not involve him.
In another situation the FSE was working on another machine, when the 2
ndline engineer performed diagnostics on a LDT. It is unclear why the FSE sometimes is not involved. In the daytime FSE’s are very busy with working on other machines. Also 2
ndline engineers are not always able to share knowledge. Sometimes specific procedures have to be followed and it may take a long time to explain these to the FSE’s. Because the FSE is not involved in the diagnostic actions important learning opportunities are missed.
Output
When a down has to be escalated to the headquarters, the 2
ndline engineers have to collect al the necessary data and information, fill in ASML-Q, and verbally communicate the problem to colleagues and the customer.
When an unscheduled down is solved it has to be administered so it can be presented to
the customer and analysed. First, it has to be reported in ASML-Q. Due to the high
workload and a low priority this is sometimes done two weeks after the down has
occurred. The customer support supervisor creates the Field Service reports (FSR: is
created after each down) and Long Down Time reports (LDT: is created after a down of
longer than four hours).
In the FSR the distribution of the man-hours for each sub-task of the problem solving is administrated. This subdivision is subjective, since the subdivision is mainly based on often-incomplete passdown reports.
Every three weeks a knowledge transfer meeting is organised at the local office where 2
ndline engineers and FSE’s come together to exchange knowledge about important parts of the job. Here, knowledge about solving unscheduled downs can be transferred. These meetings are not visited often by FSE’s.
In a weekly customer interface meeting with the customer the most important topics with unscheduled downs and reliability issues are discussed. The FSR, LDT and particularly Post Mortem Analysis are the main inputs for these meetings. Here the problems with the machines are analysed and improvement and prevention plans are constructed. For the Infineon customer in Dresden this meeting is prepared at the office with multiple actors:
the customer support supervisor, the performance co-ordinator, the lead engineer, and involved 2
ndline engineers.
Training
Almost all FSE’s are level three trained with some specific level four training. Training level 1 to 3 is a minimum in order to be allowed to work on the system. Based on a global estimation the FSE’s at Infineon Dresden are trained 15 days per year. The training package is based on the shift team. When there are three people in the shift, the complete training package can be spread over three people. Due to the decrease in people the same amount of training now has to be done by two people. The decrease of the man-machine ratio has thus resulted in an effective increase of training effort of 50% per FSE. The supervisor determines who has to do which training programs and hereby he focuses on the training programs that have a relationship on the most problematic topics.
Input
Return fized machine
Communicate information by
email machine father
customer
C C
field service engineer
AMSL
second line engineer
ASML
third line engineer ASML
Diagnose down at office
Communicate solution by verbally of by
email C C
Diagnose down on site
Diagnose down on site:
run tests, swap parts
(with 2nd liner)
C C
C
C Communicate
progress problem solving
Administrate solution in ASML-Q and
write LTD Communicate information by
email Diagnose down at office
Escallate in ASML-Q &
verbally
Request for more information
C C
C C
C C
Run tests &
collect data for 3rd line
engineer
Diagnose down at office
Figure A6 Third line engineer process unscheduled down
Third line engineer
operation engineer customer
D D
When the LDT cannot be solved regionally (when the 2
ndline engineer is ‘out of ideas’) it is escalated to the headquarters. Officially the problem has to be escalated to the headquarters after 24 hours, and has to be decided after 48 hours if a 3
rdline engineer has to come on site. However, this procedure is not always followed in practice. A 3
rdline engineer can be contacted by composing an ASML-Q with all necessary information and asking for 3
rdline support. Previously 3
rdline support was given less formally: 3
rdline engineers could be called informally and could be asked for a brief consultation. Today 3
rdline support is only possible by formally asking for support. The regional office feels that this procedure is bureaucratic and that the headquarters is less inclined to give support than before. At the headquarters a 3
rdline engineer is assigned to the LDT and he requests additional information from the local competence engineer.
Transformation
When the 3
rdline engineer receives the necessary data he starts diagnosing and the problem is discussed with his colleagues in order to get a clear picture of the problem. In this process he mainly has contact by phone or email with the assigned 2
ndline engineer.
When the 3
rdline engineer is busy diagnosing, the customer support supervisor is already organising for the 3
rdline engineer to come on site if necessary. In co-operation with the customer a meeting has been organised in which would be decided if a 3
rdline engineer had to come on site. In cooperation with the customer it was agreed that a 3
rdline engineer would go to the fabrication site. The visit of the 3
rdline engineer to the site was an open end stay: the 3
rdline engineer had to stay as long as the machine was down. In the mean time that a 3
rdline engineer is travelling from the headquarters to the customer site, another 3
rdline engineer temporarily takes over and assists with the unscheduled down so that the 3
rdline support is continued.
When the 3
rdline engineer arrived, it took one hour for him to get from the airport to the machine. He subsequently had to be administered, to get clean room clothes, to get dressed (here the problem was already explained to him), before he could actually work on the machine. Each customer site has its own administrative access procedures. Arrived at the machine the 3
rdline engineer rapidly asked many high level analytical questions in order to get a clear picture of the problem. The communication was mainly between the responsible 2
ndline engineer and the 3
rdline engineer. The FSE was not involved in the problem solving process. Instead he started to work on other machines. The 3
rdline engineer first globally checked the hardware, after turning to the software. All this is done in close co-operation and communication with the 2
ndline engineer. The 3
rdline engineer took the initiative to collect data on the machine and 2
ndline engineer mainly assisted. It seemed that the third engineer had a somewhat different approach of diagnosing than the seconds line engineer. Where the FSE’s and 2
ndline engineers mainly focused on the hardware, the 3
rdline engineer focused mainly on the data and tests on the machine.
After the problem was relatively well isolated but it was clear that the problem would be
difficult to be found, a mass-swap action was proclaimed. This means that the most
essential spare parts of the isolated problem would be ordered and replaced. The cause of
the problem was found by coincidence: the 2
ndline engineer accidentally opened the
wrong side of the machine, and saw that a cable was damaged.
After the problem was found, the third and 2
ndline engineer reasoned back that this had to be the source of the malfunctioning of the machine. When the cable was fixed, some tests were performed and the machine performed normally.
Output
For the 3
rdline engineer the output of the transformation is a fixed machine. Next to this he analyses the LDT in reports, which can be done in two ways. When the root cause of the LDT is a structural problem, such as an patch or an FCO, an Improvement Proposal (IP) is written and escalated to the fourth line engineers (developers). If the root cause of the LDT is not structural a technical post mortem is constructed, which may lead to improvements of the procedure or the construction of an PCS. The 2
ndline engineer makes the ASML-Q report and the LDT-report for the customer.
The added value of a 3
rdline engineer on site is big. Firstly, the customer feels that his problem is taken seriously, since a 3
rdline engineer from the headquarters is on site.
Secondly, a 3
rdline engineer has more specialised (software) tools to his disposal. He has support from his colleague 3
rdliner engineers at the headquarters and he is also able to contact 4
thline engineers (developers) at the headquarters. Finally, the problem solving is much easier when 3
rdline engineer is on site than when he is at the headquarters.
When there is no 3
rdline engineer on site (see I in figure A7), the 2
ndline engineer must diagnose according to directions by phone or email, and he must find ways to email data to the headquarters. When a 3
rdline engineer is on site (see II in figure A7), he can diagnose himself in co-operation with the 2
ndline engineer. This face-to-face communication is very effective and it goes very fast. The 3
rdline engineer also has easy contacts by phone and email with third and fourth line engineers.
A7. Difference between remote and on site support 3
rdline engineer
Note: this description of the primary process is a personal interpretation based on unstructured interviews and observations in a period of ten days. This description of the case study has been given to key respondents for feedback. Feedback from a 2
ndline engineer and a 3
rdline engineer has been incorporated.
Time delay
Low detail
REMOTE ON SITE
2 3
4 3 3
I
2 3
4 3 3
II
Generalise-ability case study
The findings of how unscheduled downs are solved at Infineon Dresden cannot be completely generalised to all the other ASML sites in the world. This is because not all customer fabrication sites are identical. For instance, customer fabs can differ in their size (from small to large), ASML system (mature PAS technology versus maturing Twinscan technology), purpose (from research fab to production fab), product types (DRAM, processors, and logic). Also customer sites can differ in their performance, their man- machine ratio, the average level of training, and so forth.
Although customer sites can differ substantially, the results of the description of the case
study may be generalised under the following conditions. The first classification is the
distinction between PAS and Twinscan systems. These systems differ substantially with
regard to their technology maturity. The PAS system technology can be typified as
mature, whereas the Twinscan technology can be labelled as not yet mature. The solving
of unscheduled downs on Twinscan machines is more difficult, because much less
problems are known. Since the research has been conducted at a Twinscan site it is
assumed that the results can only be generalized to other Twinscan sites. Another variable
that has to be kept in mind, is the man-machine ratio. The Infineon site has an
extraordinary low man-machine ratio, which has resulted in a high workload. The man-
machine ratio at other sites is often lower. With regard to the training and experience
level of the FSE’s and 2
ndline engineers this seems to be fairly in line with other sites in
the world. A final characteristic of the case study is the management of the FSE’s. The
FSE’s seem to have much freedom in performing their task and seem to be only limitedly
managed by their customer support supervisor. The case study results may only be
generalized when the FSE’s are similarly managed. Since the research has been
conducted at a German site, the results of this research may only be generalise-able to
sites with similar cultures, such as the so-called western cultures.
APPENDIX B AAD PROCESS UNSCHEDULED DOWN SOLVING
Actor activity diagram process unscheduled down solving, sheet I
Based on observations and interviews LDT 1250XToperation engimeer customer
maintenance engineer customer
Noticing machine unplanned
down
C Verbal C
(face to face or by
phone) Register
down?
Collect information
down
Perform fast start-up
C Register
down?
Communicate progress
problem solving
C
Diagnose down, run tests, swap parts C
C Describe
problem verbally (first by phone later
face to face)
third line engineer ASML field service
engineer AMSL
second line engineer
ASML
Run tests
& collect data for 2nd line engineer
Administrate Escallate in
ASML-Q &
verbally
C1
Cmaintenance engineer customer
Actor activity diagram process unscheduled down solving, sheet II
maintenance engimeer customer
machine father customer operation
engimeer customer
Communicate information by phone and email field service
engineer AMSL
second line engineer
ASML
third line engineer ASML
C C
Diagnose down on site:
run tests, swap parts (possible with
FSE) Diagnose
down at office: if necessary return to C1
C
C
Communicateprogress problem solving
Communicate information by
email Diagnose down at office
Escallate in ASML-Q &
verbally
Request for more information
C C
C C
C C
Run tests &
collect data for 3rd line engineer
Diagnose down at office
Actor activity diagram process unscheduled down solving, sheet III
operation engimeer customer
Communicate information by
email machine father
customer
C C
field service engineer
AMSL
second line engineer
ASML
third line engineer ASML
Diagnose down at office
Communicate solution by verbally of by
C C
Diagnose down on site
Diagnose down on site:
run tests, swap parts
(with 2nd liner)
C
C
Communicateprogress problem
solving Administrate
solution in ASML-Q and
write LTD
D D
Return fixed machine
APPENDIX C SUPPORT ORGANIZATION ESCALATION PROCESS
APPENDIX D ABC-SCHEDULE
Rooterror finding (5 to 10 min)
Recovery (30 to 60 min)
Error History and recovery File (Currently the logbook)
Return system to customer
Check if problem is
“known”
Follow PCS & check
ASL-Q
Return system to customer
Max 2 hours before you escalate to a higher level
A
B
C
Fast start up if nok reset all processor perform a full start up if NOK initialize via ADT Observe and write
down the error situation
Follow PTCL (DATA collection)
Escalate to 2nd or 3 rd line
Perform action
plan When problem
is
“unknown”
Return system to customer
Make LDT Report When standard recovery
fails, determine if problem seen before or not . Use PCS in Coach
When problem is unknown gather all required information as listed in the PTCL and escalate
Availability focus of Working supervisor, Fab team leader, reliability coordinator