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 |