20110913 - HPL2011 presentation TPB final

7
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 Public 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 Slide 2 | Public Slide 3 | 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 Source: ASML Q2 2011 Public 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 Slide 4 |

Transcript of 20110913 - HPL2011 presentation TPB final

Applying Software Product Line Engineering Techniques

to Develop Simulators for Early System Integration

Istvan Nagy Loek CleophasASML TU/e

ASML

Veldhoven

2011/09/29Public

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

Slide 2 |

PublicSlide 3 |

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 EUR1,529 (Q2 2011)

• R&D investment in million EUR

145 (Q2 2011)

• Number of systems shipped

63 (Q2 2011)

ASML

Source: ASML Q2 2011

Public

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

Slide 4 |

Public

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 (VxWorksor LINUX)

Slide 5 | PublicSlide 6 |

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

Fu

ncti

on

al co

mp

lete

ness

Proto

Availability

Test Rig

Test Bench

DevBench

simulation based

expensive

inexpensive

real robots, mirrors,…

PublicSlide 7 |

Software in a Loop Simulation

TWINSCAN

test cases

Software

actuators, sensors

Software

Simulators

test cases

real function calls toinfluence actuators, query sensors

replies on sensor values and positions,

with realistic data

Public

Finding the level of testability / simulation interface

Software

effort vs. coverage?

coverage

effort

Slide 8 |

Public

Finding the level of testability / simulation interface

Software

effort vs. coverage?

takeOffland

ascend (altitude) descend (…)flyTo(…)

getAltitude

Hardware Abstraction Layer (HAL)

hides platform specific details

coverage

effort

Slide 9 | Public

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”

Slide 10 |

PublicSlide 11 |

TWINSCAN Platforms and Machine Types

NXE platformXT platform NXT platform

TWINSCAN product family

TWINSCANplatforms

NXE:3100...

NXT:1950i...

XT:1950Hi XT:1900Gi XT:1700Fi XT:1450G ...

Machine types

downto 38 nm

upto 150 wafers/hr

below 38 nm

above 175 wafers/hr

below 27 nm

above 60 wafers/hrMainspecifications

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

How to create wafer-flow simulators

efficiently for this product

family?

Public

How to Build a Wafer Flow Simulator?

Slide 12 |

?

Actuators Sensors Holders OperatorTransportableMaterial

Interactions

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

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

Public

How to Build a Wafer Flow Simulator? – Error Scenarios

Slide 13 |

?

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

Error-injection Scenarios in Simulation

Wafer Presence Sensor

Position Sensors

Transfer withoutwafer displacement

Transfer withwafer displacement

Public

Need to Raise Abstraction Level

Slide 14 |

template<typename T, typename F>void CLightBeamSensor::movingWaferIntersectionCheck( constGm::CartVector & cartVector, const CWafer *wafer, Sim_FSM *FSM ){bool intersects;Gm::CartPoint point; Gm::addCartPoints(cartVector.two, wafer->getRelPos(), point);…Gm::circleIntersectsVerticalVector(circle,

this->getVerVector(), intersects);if( intersects ) { FSM->process_event(T()); } …

}

Model wafer flow simulators of different systems with common

and unique features

Template programming in C++

Vector Geometry

Error-handling

Statecharts

Complex modeling and

programming in solution

(technology) space

Simplified modeling and

programming in problem space

automatedproductionmechanism

PublicSlide 15 |

Model-Driven Engineering Approach

interactingactuators, sensors

Software

test cases

Automated +

consistent

generate& deploy

Test nominal + non-nominal behavior

WaferFlow Simulator

Wafer Flow config. with static variation points

Configuration: e.g. wafers, wafer sizeFault injection: e.g. wafer found/lost, wafer displacement

runtimeinput

Simulation Scenarios

model

HardwareSimulation

Models(.VPDSL)

Domain-specific language to configure wafer flow simulators of different products = contract

Editor in Eclipse + Design Checks = feedback

Public

Features, Variants and Binding Times (Examples)

Slide 16 |

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

PeripheralPedestal

Discharge Unit

(DU)

Device for

MeasurementSensor

Light beam

Sensor

LS1 @ Load-

Lock 1

Position of Devices

Coordinate Polar (…, …, …)

Ensuring Non-nominal

Behavior

Fault Injection

Wafer LostWafer Lost @

Load RobotStartup Time

Wafer

Displacement

D(…, …) from

LL1 to IVR Runtime

Abstract - Concrete

PublicSlide 17 |

VPDSL – A DSL for Specifying and Generating

Wafer Flow Simulators

Closely resembles the final system –unlike C/C++

Public

Interactions for Material Transfer in VPDSL

Slide 18 |

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

PublicSlide 19 |

Design Workflow with VPDSL

Specify VPDSL model

Generate simulation code

Integrate simulation codewith control software

Eclipse-based Xtext DSL editor

X LoC

12*X LoC(8*X model-dependent)

Eclipse-based Xtend/XpandDSL to C++

Technologies in target code:•Boost state machines•Geometry library•ASML sw. facilities

mechanical engineer

software engineer

PublicSlide 20 |

Runtime Workflow

Initialize control software with simulator

Initialize injector

Read injectorconfiguration file

Wait for eventfrom control software

Check fault rules

Inject error

Robot1 actuated to {r1,phi1,z1}

WaferFlow Simulator

Control Software

FixedPeripheral

ActuatedPeripheral

Wafer displacement injectionduring transfer

DisplacedWafer

Light beamsensor

if(evCheckError)

[yes][no] if(satisfied)

[yes]

[no]

Public

Use for Progression Testing

Slide 21 |

• New control SW functionality wasdeveloped to have robot correctlycenter slightly displaced wafer whiletransferring 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

Public

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

Slide 22 |

Public

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.

one discipline defines the models, the other uses the

generated artifacts from the models)

• enables automation and enforcement of architectural

constraintsFor other benefits, see: Bruce Task et. al., Using model-driven engineering to complement software product lineengineering in developing software defined radio components and applications, ACM, US, New York, NY, USA, 2006

Public

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

Slide 24 |

Public

Questions?

István Nagy

Phone: (+31) (0)40-268 5355

E-mail: [email protected]

Loek Cleophas

Phone: (+31) (0)40-247 2406E-mail: [email protected]

Slide 25 |