Addressing Connectivity Challengesof Disparate Data Sourcesin Smart Manufacturing

Addressing Connectivity Challenges
of Disparate Data Sources
in Smart Manufacturing
Smart Manufacturing Pavilion:
The Road to the Smart, Digital
and Connected Fab
Alan Weber, July 10, 2019

 Problem statement
 Gigafactory context
 Smart Manufacturing data sources
 Unifying concepts
 Characteristics
 Challenges
 Example solution architectures
 Questions
Outline

Problem statement
 Background
 Data collection is the principal enabling technology for
maintaining a Smart Factory’s “digital twin”
 The diversity of data sources in Smart Manufacturing
environments is growing, not shrinking
 Goals
 Access important information in these data sources with
minimal custom software
 Leverage existing data collection infrastructure to
seamlessly integrate data from all sources

Gigafactory context
In every minute of every day…
GEM messages
coordinate hundreds
of transactions…
GEM300 events
track thousands of
activities…
EDA services
collect millions
of parameters…
Copyright © 2019 Cimetrix. All Rights Reserved.

What is “Smart Manufacturing?”
From Industry 4.0 Wikipedia…
 “… cyber-physical systems monitor physical processes,
create a virtual copy of the physical world and make
decentralized decisions.
 Over the Internet of Things, cyber-physical systems
communicate and cooperate with each other and with
humans in real time…”

 SEMI Standards-compliant interfaces
 EDA/Interface A
 SECS/GEM/GEM300
 Custom interfaces
 Purpose-specific (EUV data collection)
 External sensors (RGA, OES, …)
 Equipment log files (many examples)
 OPC-enabled equipment/subsystems
 OPC Classic DA (Data Acquisition)
 OPC UA (Unified Architecture)
 IIoT…
Semiconductor Smart Manufacturing
Data sources (current sampling…)

 Models may or may not reflect equipment
structure, depending on when they were defined
 Models may not provide sufficient visibility into
equipment behavior
 Interface performance may not match expectations
if control system was not redesigned
 All of this is improving rapidly as fabs take a more
prescriptive approach to their automation specs
Issues with SEMI EDA data sources
Equipment models are vendor specific
Valid Entries:
Comply
Comply by (Date)
Partially Comply (Notes)
Do no comply
N/A

EDA adoption status
Cumulative # of production tools installed
9
We are here !
All are now requiring latest SEMI Standards for
equipment modeling and data acquisition
Principal Motivation: Flexibility…
• Data collection plan
• Changing requirements
• Multi-client architecture

Unifying concepts/relationships
Generalizable from SEMI EDA standards
Data
Equipment
Model
Equipment
Data
Consumers
Data
Collection
Plans
Manufacturing
Stakeholders
and their KPIs

Unifying concepts
Metadata model and data collection plan (DCP)

 Structure exactly reflects equipment
hardware organization
 Provides complete description of all
useful information in the equipment
 Always accurate and available – no
additional documentation required*
 Common point of reference across all
factory and supplier stakeholders
 Source of unambiguous information for
database configuration
 Reduces integration engineering
Shared equipment model benefits
Driven by factory requirements…
Process Module #1
Gate Valve Data
Substrate Location
Utilization
More Data,
Events, Alarms
Process Tracking
Other
Components
* As long as it can be queried from the equipment

 GEM/GEM300 will persist as the principal
“command and control” interface
 Data collection mechanisms are fixed and limited
 Event reporting
 Trace reporting
 Variable status queries
 Equipment “model” must be derived from lists of
variables, events, constants, state machines, etc.
 The recent SEMI E172 standard (SECS Equipment Data
Dictionary) offers a partial solution
 But must be specified if it is to be delivered
Issues with SEMI GEM data sources
Equipment model is not explicit

SEDD – SECS Equipment Data Dictionary
Schema and examples
….

GEM equipment model structure
Embedded in E172 (SEDD) <source> elements

 Set of architectural specifications for creating
integrated factory systems
 Systems include manufacturing equipment,
applications, data repositories, and the other
components that interconnect them all
 Interoperability of the system components
depends on their respective suppliers having
chosen compatible and similarly scoped profiles
 Because of the breadth of OPC UA’s applicability
and variety of implementation options, this itself
is a significant system engineering task
Issues with OPC UA data sources
OPC UA is an architecture, not a standard

Interoperability of OPC UA components
Requires compatible “mappings” and “profiles”
Figure 1 – The OPC UA Stack Overview
(from Volume 6)
Figure 1 – Profile – Conformance Unit – Test Cases
(from Volume 7)

Typical challenges….
1. Finding a sensor that works
2. Sampling/process synchronization
3. Dealing with multiple timestamps
4. Scaling and units conversion
5. Applying factory naming convention
6. Associating context and sensor data
7. Ensuring statistical validity
8. Aligning results in process database
Issues with external sensors
Implementations are factory specific

Example solution architecture
EDA-based sensor integration
OEM Tool
EDAGEM
Sensor/Actuator Gateway
Device Drivers
DP ATP S1
TPPump
I/F
FICS / MES
EDA Client
EDA Server
EDA Client
Smart
Data
Model
Raw Data
Metadata Model
Public
Data
DCIM* DCIM
Proprietary
Applications
Process-specific
applications Factory-level
EDA Client Apps
(DOE, FDC, PHM, …)
Custom
or
EtherCAT
TCP/IP
HTTP
HTTP HTTP
To factory-level systems
Context data
Synchronization data
S2 S3
* DCIM =
Data Collection
Interface Module
Synchronization signals
Process
Engineering
Database

 Optimized for ease of creation
 NOT consumption
 Type of information included varies
 Mixture of events, parameters, alarms
 Mixture of critical data and “just in case” stuff
 Parameter values often stored in native, binary form
 Format may change throughout the log
 Not just a simple set of identical records
 Multiple sections, headers, record layouts, even files
Issues with equipment log files
Their formats are custom designs

 Usually circular file system
 Fixed limits for file sizes and number
 When limits are reached, oldest files are overwritten
 Retention period may vary with activity
 And available storage space
They disappear over time

 Part of the local file/directory system
 Access methods dictated by platform technology
 Special permissions may be required to keep from
invalidating tool warranty
 They depend on the tool’s clock
 So the timestamps are almost always wrong…
 May be able to correct reports if offset from factory
reference clock is tracked continuously
They reside on the tool

Example solution architecture
Equipment Log File Processing
EDA
NewData
Reports
• Trace data
• Event data
• Context data
Factory
EDA Client
Software
Process
Data
Repository
(Historian)
Data Collection Plan
SEMI E134 .wsdl
(schema)
Data Source
Models
(1 per tool type)
DataSourceModel
.xsd
(schema)
Data Source
Model Validator
Log File Processor
XML/Text
Model
Editor
EDA
Server
Equipment
Control Platform
Log
Files
elastic
logstash
elastic
Filebeat
Isolates
Custom
content

 Foundation for entire system architecture
 Could be derived from EDA equipment metadata model
 Identifies type/name of the system that generated log file
 E.g., process equipment, supplier, tool type, model name, etc.
 Maps contents of custom log file into standard tool data reports
using unique “keys” for items of interest
 Keys are assigned in the log file parser
 Keys appear in correct equipment structural context in the DSM, resulting
in proper sourceId (location) and parameterName
 Includes optional elements for
 Data type declaration: necessary for subsequent report processing
 Units conversion: raw binary to scaled engineering units
 Event augmentation: generate enumerated state values
Key system components
Data Source Model (DSM)

 This is where most of the NRE (non-recurring engineering
effort) will be spent
 Some of this will be custom code, but it is also possible to
use commercial ETL (extraction, transformation, and
loading) software in many cases
 Example: elastic Filebeat and Logstash products
 Perhaps elasticsearch and Kibana for centralized storage and
visualization as well
 The back end of each parser is a standard EDA-compliant
data report generator
 Output format for all sources is the same
 This is NOT rocket science… just tedious
Key system components
Data source parser

 Analyze format and content of log file
 Identify data items of interest
 Don’t have to collect everything in the log file
 Develop custom parser, assign keys to items of interest
 Create Data Source Model with keys in hierarchical context
 May also derive it from EDA equipment metadata model
 Include scaling, units, and new state value elements as needed
 Validate with DSM validation utility
 Add new event states and other parameters to client
applications and data collection infrastructure
Implementation process
For each vendor/equipment type

 Danke
 감사합니다
 唔該
 Merci
 多謝
 Grazie
 ありがとうございます
 Gracias
Acknowledgements and Thanks
 SEMI staff and standards volunteers for decades of support !

Addressing Connectivity Challengesof Disparate Data Sourcesin Smart Manufacturing

More Related Content

What's hot (20)

Similar to Addressing Connectivity Challengesof Disparate Data Sourcesin Smart Manufacturing (20)

Recently uploaded (20)