# Presentation: 134984

## Practical Aspects ImpactingTime Synchronization Data Qualityin Semiconductor Manufacturing

**Practical Aspects Impacting*****Time Synchronization Data Quality*****in Semiconductor Manufacturing**
- _Naveen Kalappa_, James Moyne,
- Jonathan Parrott, and Ya-Shian Li
***2006 Conference on IEEE 1588**** *

**Official contribution of the National Institute of Standards and Technology; not subject to copyright in the United States.**
*Certain commercial equipment, instruments, or materials are identified in this paper to foster understanding. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.*

## Why is time synchronization so important in semiconductor manufacturing?

Components in the end-to-end synchronization problem 
Currents efforts in semiconductor manufacturing impacting time synchronization data quality
NIST and the University of Michigan

Key points and future efforts

**Components in the end-to-end synchronization problem**** **
**Currents efforts in semiconductor manufacturing impacting time synchronization data quality**
**NIST and the University of Michigan**
**Key points and future efforts**

**Outline**

**Notes:**
Outline

## Time Synchronization and Manufacturing

-  Test and Measurement
-  Fault Diagnosis
-  Network Operations
-  Security
-  QoS measurement

- Manufacturing Automation
-  Process Control
-  Coordination among tools
-  Scheduling/Dispatching

**Robotics Coordination for Auto Industry**

**Fault Diagnosis for Power Industry**

**Notes:**
Traditionally measurement and control systems in industrial automation implemented in centralized architecture
As time progressed – more features, reconfigurability, etc... and the network gained importance
Progressed to distributed architecture – alternate means for enforcing timing requirements
Thus, arose the need for time synchronization in industrial automation 
Measurement, control, event and data reporting all need to be coordinated

## Ethernet Everywhere!
Interfaces A, B and C
EDA, PCS, e-diagnostics
HSMS
XML, VPN, OPC
MES to I/O Level

_**Ethernet Everywhere!**_
**Interfaces ****A, B and C**
**EDA, PCS, ****e-diagnostics**
**HSMS**
**XML, VPN, OPC**
**MES to I/O Level**

**Motivation: The Move to Networks**

**Factory**

**Host**

**Equipment**

**Tool**

**Tool**

**Tool**

**Switch**

**Switch**

**Switch**

**Notes:**
“Ethernet everywhere” is the word in the manufacturing industry
Low cost, interoperability and rapid developments in the technology contribute to its popularity
Picture shows Ethernet from Manufacturing Execution System to the I/O level 
For semiconductor manufacturing Interfaces A, B, C for EDA, Process Control and Security respectively are all going to be based on Ethernet
Protocols such as XML, PN, EIP, OPC are present on Ethernet to meet timing and reconfigurability requirements

##    Semiconductor Factory

**EES (Equipment Engineering System)**

**Factory Network**

**Equipment Engineering Network**

**EE**
**Access **
**Control**

**EE Data**
** ****Collection**
**And Storage**

**         ****MES**
**Equipment Control**
**WIP Tracking**
**Factory Scheduling**

**Global **
**EE Data**

**SECS/GEM**
** ****Interface**

*Interface “A” Components*
*Process Control and Equipment Operational Data*
*Host-Independent Data Collection*
*Data Collection Plans **** E134*
*Equipment Self-Description **** E125 *
*Authentication and Authorization **** E132*

**Notes:**
Typical layout of a semiconductor manufacturing factory
Interface A, B and C indicated
Interface A – A second standard communication port on the equipment that is used for high speed data collection and not control, and thus could support things like FDC, virtual metrology and e-diagnostics

## Motivation in Chip Manufacturing

- 	**Advanced Process Control:**
- Fault Detection Classification
- e-diagnostics
- Process Optimization
- Virtual Metrology
- 	**Precision time-stamping and time synchronization:**
- Merging data from heterogeneous sources
- Maintain data and event ordering
- Improve multivariate, advanced correlation and analysis
- Expose new cause-effect relationships

**Notes:**
APC requires stringent timing requirements (1ms today and more stringent as time progresses)
Data recorded helps in FDC where the occurrence, cause and severity of the fault can be analyzed accurately 
Data from the sensor, process parameters, data from the different tools and factory environment settings have to be accurately reported for optimizing the process in semiconductor manufacturing
All the above calls for precision time-stamping and time synchronization 
Data from a particular equipment (tool, sensor) needs to be precisely time stamped (event occurrence or transmission?)
And since data from different equipments have to be analyzed need for their clocks to be synchronized

## Common Time Sync. Pain Points in APC

**Events and data are received out-of-order**
**Inability to support high data collection rates ****with good data quality**
**Cannot synchronize data across multiple ****systems (e.g., equipment & metrology systems)**
**“****False Positives” in fault detection systems ****bring equipment down unnecessarily**
**Out-of-order data, poor time-stamping**
**Time-stamping at point of sending instead of ****point of event occurrence**
**“****Out-of-control” situations for R2R controllers**
**Poor data quality due to delay and **_***delay variability***_
**Inability to migrate from the equipment level to the factory-wide level with APC systems**
**Etc...**

**Notes:**
Now again, looking into the common time sync points in APC
Out of order events, data
Higher data collection rates as messages are becoming larger due to more features – no support for such high rates with good quality

## Solutions for Time Synchronization

- NTP 4.0 or SNTP 4.0
- Software only
- 50 us to 50 ms accuracy, depending largely on software environment
- More mature
- ANSI/IEEE 1588 – (IEC 61588)
- Software and hardware
- Approx 100ns accuracy
- Infancy in standard and solutions

**Notes:**
Coming to time synchronization solutions – NTP, PTP
Accuracy achievable can vary ... operating system, clock quality, etc. The NTP standard itself allows up to picosecond resolution ... but of course that accuracy is not achievable.  
NTP 50 microseconds using a PC quality clock and FreeBSD (one of the better OSes for time synchronization).  Over the Internet, synchronization typically degrades to about 50 ms. Even on LAN, with different subnets 5 ms synchronization achievable. 
IEEE 1588 experiments have shown accuracy levels at 100 ns.

## Outline

**Why is time synchronization so important in semiconductor manufacturing?**
**Components in the end-to-end synchronization problem**** **
**Currents efforts in semiconductor manufacturing impacting time synchronization data quality**
**NIST and the University of Michigan**
**Key points and future efforts**

## Where are the sources of delay and variability?
Network and nodes

**Components of Delay**

**Total end-to-end delay is the sum of**
- Pre-processing time: microprocessor
- Waiting time: network protocol - MAC
- Transmission time: data rate & length
- Post-processing time: microprocessor

**Where are the sources of delay and variability?**
- Network and nodes

**Notes:**
How an NCS operates.  
What/where are the sources of delay and variability in the system.  
The two sub-categories are the device and the network. 

## Experimental Analysis

**The Delay**
**is in the**_***Node Software***_
_***(Tpre, Twait ***__***and Tpost)***_

**Notes:**
The experiments pointed to showing that
Delay and delay variability is in the node software
So node delays are hampering network times

## Application level delays

**Application level delays**

**UDP round-trip delays (100Mbps switched network)**

**Mean = 0.33ms****, max = 1.89ms**
**Stdev = 0.03ms**

**OPC round-trip delays (100Mbps switched network)**

**Mean = 1.5ms****, max = 16.8ms**
**Stdev = 0.81ms**

**OLE for Process Control:**
**“****THE” diagnostics protocol utilized outside of semiconductor mfg. today**

**The Delay and delay Variability**
**is in the **_***Node Software***_

**Notes:**
Results for UDP and OPC
UDP shows lower values for delay compared to OPC as expected
The experiment was carried out for 10000 packets exchanged via UDP and OPC

## Varying packet size

**UDP round-trip delays ****(100Mbps switched network)**

**Slope = 0.411********s/bit**
**Theory:  0.32 ********s/bit**
**Intercept: 0.285ms**

**VPN round-trip delays ****(100Mbps switched network)**

**Slope = 0.848********s/bit**
**Intercept:  1.07ms**
**Using DES (data encrypt. std)**

**Notes:**
Further experiments showing the variation of the round trip delay
With data size as it is varied to 1400 bytes
VPN encoding for data using DES

## Network Delay Test Results

|  | UDP | VPN
(UDP) | OPC
(TCP) |  | DeviceNet |
| --- | --- | --- | --- | --- | --- |
| Delay Average (ms) | 0.33 | 1.21 | 1.48 |  | 0.3-1.2 |
| Delay Variation (3σ) (ms) | 0.09 | 0.49 | 2.43 |  | 0.005-0.2 |
| Min. Network Delay Contribution (ms) | 0.035 | 0.035 | 0.035 |  | 0.188 |
| % of Delay Due to Network | 11% | 3% | 2% |  | 63% |

**The Message:**
_**We need time synchronization and time-stamping**_** to mitigate delay and delay variability disturbances of end-to-end network communication**
_**We need standards for time synchronization and **__***when ***__**to timestamp information**_** in the end-to-end communication path**
**Using synchronization and time-stamping, we can decouple application node time from communication network time**

**Notes:**
Summary of the results – with DeviceNet also
- Indicates in Ethernet compared to DeviceNet (dedicated Fieldbus) the delay due to the application software is more pronounced

So how do we use Ethernet for industrial automation?
This is where we expect time synchronization and accurate timestamping to come into effect

## Why is time synchronization so important in semiconductor manufacturing?

Components in the end-to-end synchronization problem 
Currents efforts in semiconductor manufacturing impacting time synchronization data quality
NIST and the University of Michigan

Key points and future efforts

**Why is time synchronization so important in semiconductor manufacturing?**
**Components in the end-to-end synchronization problem**** **
**Currents efforts in semiconductor manufacturing impacting time synchronization data quality**
**NIST and the University of Michigan**
**Key points and future efforts**

**Notes:**
Outline

## IEEE 1588 testbed in operation
1588 hardware I/O cards
LabVIEW as the application software
XML traffic generators
Routines for encapsulation, e.g., VPN, OPC, UDP, as necessary

Performance testing of IEEE 1588 for semiconductor manufacturing applications
Data collection
Event reporting
Remote monitoring 

**NIST / University of Michigan Project**

**IEEE 1588 testbed in operation**
- 1588 hardware I/O cards
- LabVIEW as the application software
- XML traffic generators
- Routines for encapsulation, e.g., VPN, OPC, UDP, as necessary
**Performance testing of IEEE 1588 for semiconductor manufacturing applications**
- Data collection
- Event reporting
- Remote monitoring

**Notes:**
To look into these practical aspects of time synchronization in semiconductor manufacturing environments NIST and UM have collaborated
Setting up of a 1588 testbed to simulate a semiconductor manufacturing environment
Look into the issues in semiconductor manufacturing environment such as data collection, event reporting and remote monitoring with 1588 time synchronization

Mention NI hardware cards (I/O w/ 1588 hardware)

## NIST / University of Michigan Project

**Tests with 1588**

- Tests designed to see effect of 1588 time-stamping and synchronization
- Nodes synchronized through IEEE 1588 protocol
- Time-stamping through 1588 clock
- 1588 timestamps exchanged

**Notes:**
Similar to the tests mentioned earlier
Goal is to see what effect 1588 time synchronization and timestamping has on the previous results
Timestamping is through the 1588 clocks present on the PCI boards
Timestamps exchanged as previously

## NIST / University of Michigan Project

-  LabVIEW is used as the application layer for programming
-  Time synchronization interval for PTP set at two seconds
-  Interface through LabVIEW for accessing 1588 clock
-  UDP data time-stamped with 1588 clock and exchanged
-  UDP Round Trip time calculated from data exchange

**Notes:**
Shows example of a LabVIEW VI used for the testing
The PTP protocol is activated throught his VI and also the UDP data exchange can be controlled
1588 timestamps used for the data exchange
The timestamps from the stored messages used for analysis.
Comparison the delay with using 1588 clock and the computer clock

## NIST / University of Michigan Project

** ****UDP Round Trip delays for 100 Mbps network (250ms delay between packets)**

-  **Crossover Cable**

-  **Switch**

| ` | Max (ms) | Mean (ms) | Min (ms) | Std Dev (ms) |
| --- | --- | --- | --- | --- |
| Crossover | 1.188 | 0.251 | 0.201 | 0.053 |
| Switch | 1.134 | 0.250 | 0.237 | 0.056 |

**Values for 5000 packets with a delay of 250ms between packets**

**Notes:**
Summarizes the results for two nodes using switch and the crossover cable
No significant difference using a switch and boundary clock 
Switch does not have boundary clock functionality since it is a small network

## NIST / University of Michigan Project

| ` | Max (ms) | Mean (ms) | Min (ms) | Std Dev (ms) |
| --- | --- | --- | --- | --- |
| Crossover | 0.325 | 0.248 | 0.236 | 0.003 |
| Switch | 0.317 | 0.243 | 0.234 | 0.003 |

**Values for 5000 packets with a delay of 1s between packets**

** ****UDP Round Trip delays for 100 Mbps network (1s delay between packets)**

-  **Crossover Cable**

-  **Switch**

## NIST / University of Michigan Project

**Summary of initial results  **
- With 1588 time-stamping, increasing the delay between packets led to lower values of jitter for the UDP round trip delay
- LabVIEW used on Windows (OS used) may introduce variability
- UDP data exchanged is time-stamped through the application (LabVIEW) GUI, no hardware time-stamping of data
**Future tests**
- Use Linux OS and 1588 time-stamping

**Notes:**
No significant changes seen from the earlier tests
LabVIEW runs on Windows and the since the time-stamping is done through LabVIEW interfaces no much improvement in delay
and delay variability
Future tests to be done on Linux OS to remove dependency of Windows

## Outcome
Exploration of Time Synchronization for Semiconductor Manufacturing
Identification of weak links in equipment, software systems, standards, etc.
Input into SEMI standards effort

**Outcome**
- Exploration of Time Synchronization for Semiconductor Manufacturing
- Identification of weak links in equipment, software systems, standards, etc.
- Input into SEMI standards effort

-    **Next Steps**
-  Benchmark common protocol scenarios (XML, VPN, etc.)

**XML Protocols**

**XML on Ethernet**

**Security**

**Data Collection**

**Metadata**

**Traffic patterns similar to Interface A**

-  Interface “A” traffic volume analysis and performance benchmarking
-  Simple equipment EDA traffic simulators
-  APC scenario analysis

**Notes:**
Next Steps as part of the project
Use XML VPN and measure performance
Simulate EDA type traffic and see impact of 1588 time synchronization and time-stamping
Move towards simulation of entire semiconductor manufacturing environment
Outcome – should help to identify weak links in equipment, software, standards

## Why is time synchronization so important in semiconductor manufacturing?

Components in the end-to-end synchronization problem 
Currents efforts in semiconductor manufacturing impacting time synchronization data quality
NIST and the University of Michigan

Key points and future efforts

**Why is time synchronization so important in semiconductor manufacturing?**
**Components in the end-to-end synchronization problem**** **
**Currents efforts in semiconductor manufacturing impacting time synchronization data quality**
**NIST and the University of Michigan**
**Key points and future efforts**

**Notes:**
Outline

## Many efforts in implementing EDA and PCS implementation will fail if data quality is not addressed
Lack of time synchronization and accurate time-stamping is a common source of poor data quality
The weak link is often the tool software performance, so where you timestamp is very important
NIST, The University of Michigan and SEMI are working together to address this issue, with the end result being standards and prototypes that will impact PCS, EDA and e-diagnostics

**Lack of time synchronization and ****accurate time-stamping**** is a ****common source of poor data quality**
**The weak link is often the ****tool software ****performance****, so *****where you timestamp***** is very important**
**NIST, The University of Michigan and SEMI are working together to address this issue, with the end result being ****standards and prototypes**** that will impact PCS, EDA and e-diagnostics**

**Key Points**

**Notes:**
Drawing attention to the key points

## Identify and quantify the weak links in timing and time synchronization for APC
Education
When and how to apply time synchronization, and at what level
Simulation of semiconductor factory environment
Provide cost / benefit analysis
What level of time synchronization is needed at various places throughout the fab; e.g., is hardware time synchronization required?
SEMI standards for time synchronization and time-stamping

**Education**
**When and how to apply time synchronization, and at what level**
**Simulation of semiconductor factory environment**
**Provide cost / benefit analysis**
**What level of time synchronization is needed ****at various places throughout the fab; ****e.g., is hardware time synchronization required?**
**SEMI standards for time synchronization and time-stamping**

**Future Efforts**

**Notes:**
Where the future efforts should be directed to successfully employ time synchronization standards to semiconductor manufacturing 

## Thank You !! 

**For further information**
**James Moyne:****	**_[moyne@umich.edu](mailto:moyne@umich.edu)_
**UM-ERC-RMS:****	**_[http://](http://erc.engin.umich.edu/)__[erc.engin.umich.edu](http://erc.engin.umich.edu/)_
- J. T. Parrott, J. R. Moyne, D. M. Tilbury, "Experimental Determination of Network Quality of Service in Ethernet:  UDP, OPC, and VPN,"* Proceedings of the American Control Conference,* Minneapolis, MN, June 2006.
**Acknowledgments**
**NIST**
**NSF Engineering Research Center for Reconfigurable Manufacturing Systems (UM-ERC-RMS)**
**ISMI and SEMI**
**Jonathan Parrott and Dawn Tilbury**** **
**Questions?**