The Team Loek Cleophas TU/e Software Ernest Mithun Engineering - - PDF document

Applying Software Product Line Engineering Techniques to Develop Simulators for Early System Integration

Istvan Nagy Loek Cleophas

ASML TU/e

ASML Veldhoven 2011/09/29

The Team

• Loek Cleophas

TU/e – Software Ernest Mithun Engineering Technology

• Berrie van den Eijnden

ASML – Software Integration

• Istvan Nagy

ASML – Architecture & Platform

• Liviu Raulea

ASML – Embedded Software Dennis Verhaegh

Introduction

• One of the world’s leading manufacturers of chip-making

equipment

• Makes the scanners that print the chips
• 7697 employees (expressed in FTE, Q2 2011)
• Net sales in million EUR

1,529 (Q2 2011)

• R&D investment in million EUR

145 (Q2 2011)

• Number of systems shipped

63 (Q2 2011)

ASML

Moore’s Law

• Moore’s Law drives the

semi conductor industry

• ASML makes Moore’s

law happen by developing the scanners that allow chip manufactures to shrink their device features.

• At the same time the

cost of devices is brought down by increasing the scanner productivity

Software Introduction

• ASML’s scanners - lithographic systems - are complex

machines in which software plays an important role

• 35 million lines of code
• Mostly C, some Java, Python ↑, and C++ ↑
• About 7 DSLs.- increased focus on Model Driven Engineering
• > 15 years development history
• Distributed, heterogeneous,

concurrent system

• > 20 nodes, > 200 processes
• Deployed onto SUN and 7 VME

racks with power PCs (VxWorks

• r LINUX)

Early Testing & Integration

• Software tested on range from real machine to SW simulators
• Objectives:
• Shorten lifecycle of functional testing and qualification
• Optimize costs (development effort) in relation to qualification effort

Functional completeness Proto Availability Test Rig Test Bench DevBench simulation based

expensive inexpensive real robots, mirrors,…

Software in a Loop Simulation

TWINSCAN

test cases

Software

actuators, sensors

Software

Simulators test cases

real function calls to influence actuators, query sensors replies on sensor values and positions, with realistic data

Finding the level of testability / simulation interface Software

• Slide 8

Finding the level of testability / simulation interface Software

• !
• Slide 9

Machine Types & Platforms – Balancing Between Evolution and Revolution

• ASML develops 1-3 new machine types per year
• Platform: hardware foundation for range of

machine types.

• Platform determines maximum capabilities of member

machine types

• Development of new platform implies major changes of

subsystems: “Revolution”

• Example: EUV technology -

projection in vacuum with mirrors i.s.o. lenses

• Machines types built on same platform

have moderate changes in subsystems: “Evolution”

TWINSCAN Platforms and Machine Types

NXE platform XT platform NXT platform

TWINSCAN product family

TWINSCAN platforms

NXE:3100 ... NXT:1950i ...

Machine types

downto 38 nm upto 150 wafers/hr below 38 nm above 175 wafers/hr below 27 nm above 60 wafers/hr

Main specifications

common and unique HW (& SW) modules to maintain material (wafer) flow

How to create wafer-flow simulators efficiently for this product family?

How to Build a Wafer Flow Simulator?

?

Actuators Sensors Holders Operator

Transportable Material

Interactions

…try to re-create a virtual replica of the real world…

…

common and unique simulation (“virtual”) modules to maintain material (wafer) flow

How to Build a Wafer Flow Simulator? – Error Scenarios

?

…however, the real world usually does not “behave” perfectly…

Error-injection Scenarios in Simulation

Transfer without wafer displacement Transfer with wafer displacement

Need to Raise Abstraction Level

• 2

• ,!))+--#

• 1!

!!! 8 Template programming in C++ Vector Geometry Error-handling Statecharts Complex modeling and programming in solution (technology) space Simplified modeling and programming in problem space !

• !!

Model-Driven Engineering Approach

interacting actuators, sensors

Software

test cases

Automated + consistent generate & deploy Test nominal + non-nominal behavior Wafer Flow Simulator Wafer Flow

• config. with

static variation points

Simulation Scenarios model

Hardware Simulation Models (.VPDSL)

Domain-specific language to configure wafer flow simulators of different products = contract Editor in Eclipse + Design Checks = feedback

Features, Variants and Binding Times (Examples)

Purpose Feature Variant Instance Binding Time Device for Actuation Moveable Peripheral 3DOF Robot Load Robot (LR) Development Time Pin PA Pin Device for Holding Fixed Peripheral Pedestal Discharge Unit (DU) Device for Measurement Sensor Light beam Sensor LS1 @ Load- Lock 1 Position of Devices Coordinate Polar (…, …, …) Ensuring Non-nominal Behavior Fault Injection Wafer Lost Wafer Lost @ Load Robot Startup Time Wafer Displacement D(…, …) from LL1 to IVR Runtime 4 &

VPDSL – A DSL for Specifying and Generating Wafer Flow Simulators

& !

• !9
• &:&;;

Interactions for Material Transfer in VPDSL

Fixed Transfer Area Moving Transfer Area 3DOF Robot Arm (Actuator) Pedestal (Fixed) Wafer (Transportable Material) Geometric intersection detected ⇒Transfer detected ⇒Sensors updated in generated code, no need to specify

Design Workflow with VPDSL

Specify VPDSL model Generate simulation code Integrate simulation code with control software Eclipse-based Xtext DSL editor X LoC 12*X LoC (8*X model-dependent) Eclipse-based Xtend/Xpand DSL to C++ Technologies in target code:

• Boost state machines
• Geometry library
• ASML sw. facilities

• Public

Runtime Workflow

Use for Progression Testing

• New control SW functionality was

developed to have robot correctly center slightly displaced wafer while transferring it to load lock

• Integration with control SW showed bug in this new

functionality

• Would have turned up during test on proto machine
• Saved costly testing time on machine

Control SW detects eccentric wafer, uses robot to correct

Experiences and Lessons Learnt

• Many physical modules required for maintaining wafer flow

have evolved over more than 10 years → stable base for domain analysis

• DSL acts bridge between different disciplines: non-software

engineers implement the simulation models → code generator transforms these models into C++ code utilized by software engineers

• DSL has simple, intuitive textual syntax → easier for users

and for version control

• DSL evolves due to incremental approach → qualification

(test) suite on code generator is essential

Domain Specific Languages and Software Product Line Engineering

• DSL and its environment provides reuse on higher

abstraction level than code. The language

• expresses configurations of products directly as they are

built

• makes communication easy for different stakeholders

(speaking “the ubiquitous language” of the product)

• hides (complex) implementation details
• acts as contract between different teams/disciplines (e.g.
• ne discipline defines the models, the other uses the

generated artifacts from the models)

• enables automation and enforcement of architectural

constraints

Conclusions

• New (generated) simulators provide more realistic

simulation than old ones due to ‘standardized’ interactions → we found new SW bugs already in development phase

• Modeling of error injection scenarios at domain level

provides cheap way

• to increase coverage / robustness of SW
• to reproduce error situations from the field
• The DSL can be applied to forthcoming machine types of

the NXT and NXE platforms

Questions?

István Nagy

Loek Cleophas