Model checking systems, described using UML activity diagrams, within ASML

1. Model checking systems,described using UML activity diagrams,within ASML Rick van Lierop, Software Architect at ASML The 3rd Dutch Model Checking Day 7th November 2001, TU Eindhoven

2. ASML – Company overview • Company producing advanced lithography systems (e.g. a wafer scanner) • Founded in 1984 • Situated in Veldhoven (the Netherlands) • 8,349 employees world-wide • Latest product: the TWINSCAN wafer scanner system

3. PD: How to make a Chip?

4. PD: What dimensions are involved? Hair 150 nm

5. What are the No1. Business Drivers (primary requirements)? • Imaging • Overlay • Productivity

6. ASML - TWINSCAN 2.9m 5.2m 2.0m

7. ASML Wafer Scanner Reticle Stage Reticle Projection Lens Wafer Stage Wafer

8. Video (break)

9. How to make a control design? • Documentation available: • Informal textual descriptions in Dutch-English • Incomplete, necessary actions are missing • Poor concurrency description, missing productivity opportunities • Expertise available: • Many domain experts, e.g. ASML System Engineers • Few formal language experts • Common subset of the above, is the empty set

10. So, what is the strategy? • We need a better description of the control behavior • Which actions need to be executed? • What is the sequence of these actions? • Which actions need / can be executed in parallel? • …, this description can be made using UML activity diagrams, • These allow describing asynchronous concurrency, for designing optimal productivity • These are intuitive to use, so Domain Experts can be easily involved

11. UML activity diagrams (example 1) synchronization condition

12. Control design • This resulted in: • Involvement of Domain experts, OK! • Complete control sequence design, OK! • Reviewed and Accepted control design, OK! • Better concurrency and thus, productivity, OK! • An informal (we didn’t follow UML standard exactly) UML activity diagram, so what!? • Complex concurrent system control description, Mmh!?

13. Control design • Still, we had some hesitations… • Reviewers considered only some of the possible scenario’s, but the state space of this system is huge, did we cover sufficient scenario’s? • Is this system free of deadlock? • Will all wafers that enter the system, eventually leave it? And, the same, for reticles? • Steady state behavior was covered, but what about starting and stopping the system? • How do lot-to-lot transitions work out? • What throughput (productivity) will this system have?

14. Let’s simulate the behavior in time! • Example1. • Oops, there is no: • Timing • .. Nor .. • Resource Allocation • Information available in UML activity diagrams! synchronization condition

15. Additional simulation information needed (example 1)

16. The Dynamic Behavior (example 1.) 3 4 5 3 2 1 5

17. Used Strategy Gantt

18. Translation of UML to c

19. Results from c-simulator < WSE 1 0 15 > < WH 1 0 8 > < DO 1 0 7 > < WSM 1 0 8 > < RH 1 0 18 > < RS 1 0 18 > < RM 1 0 19 > < IL 1 0 20 > < RM 0 0.1 19 > < WSE 0 0.372 15 > < DO 0 4 7 > < DO 1 4 25 > < WSM 0 4.21 8 > < WH 0 4.21 8 > < CPU 1 4.21 45 > < CNT 1 4.21 44 > < WSM 1 4.21 30 > ……………….

20. Gantt Chart for TWINSCAN design

21. What did simulation & verification bring us? • Now we have the resulting time domain behavior: • It shows resource usage in time for the described behavior • It is a diagram for communication about this time behavior • It gives an idea about throughput • It gives an idea about possible throughput bottlenecks • We found and corrected defects in the design, e.g.: • Deadlocks detected in startup behavior • Possible (race-condition) to place more than one reticle on reticle stage (missing [implicit] requirement!!!)

22. Example detected undesired behavior • Load Reticle  Load Reticle  Unload Reticle (undesired) • Load Reticle  Unload Reticle  Load Reticle (desired) • Test: # Reticles on Reticle Stage  1 • Note: Reticles cost about $50-100K (Mercedes!!!) 2 1 1 1 1 2

23. The manual translation process is still cumbersome… • Automation of manual translation steps is needed: • Now an expert in SPIN/Promela and Chi needed, we don’t have that many (say: none) that are also Domain Expert. • It is error prone, large number of Chi and Promela statements can contain a lot of bugs. • It is time consuming, because a large number of Chi and Promela statements have to be written

24. Approach - High level view Simulation Output GSV Process UML model (incl. Activity Diagrams) Verification Output Data format Black box UML: Unified Modelling Language GSV: Generation Simulation Verification

25. Approach - Analysis • TWINSCAN activity diagrams: • ‘free-form’ UML • insufficient information (single source) • We have made a design, that covers: • UML extensions • UML restrictions • Rules that describe how UML elements are translated into Chi and Promela

26. UML Activity1 Activity2 prev1 prev0 next join Activity3 Approach - Formal translation Example translation rule of the ‘join’ Chi proc join(trigger_prev0, trigger_prev1: ?void, trigger_next: !void) = |[ *[ trigger_prev0?  [ trigger_prev1?  trigger_next! ] | trigger_prev1?  [ trigger_prev0?  trigger_next! ] ] ]| Promela proctype join(chan trigger_prev0, trigger_prev1, trigger_next) { do :: trigger_prev0?true; trigger_prev1?true; trigger_next!true :: trigger_prev1?true; trigger_prev0?true; trigger_next!true od }

27. UML2XMI Exporter XMI specification Chi generator Chi specification Chi simulator Promela generator Promela model SPIN UML DTD Data format Off-the-shelf tool Black box Approach - Architecture GSV Process UML model (incl. Activity Diagrams) Simulation output Verification output XMI: XML Metadata Interchange DTD: Document Type Definition

28. XML Parser DOM tree DOM2Chi converter DOM API DOM impl. Approach - Component design Chi generator UML DTD Chi specification XMI specification Interface Data format Off-the-shelf tool Implemented component XML: eXtensible Markup Language DOM: Document Object Model API: Application Program Interface

29. Conclusions • Off-the-shelf-tools and industry standards are available and usable. • TWINSCAN activity diagrams contained defects. Simulation results and Verification results led to the solving of defects in the design description • Extensions to UML activity diagrams are required. • Informal UML to formal (correct) UML: The designer of UML activity diagrams is forced to design concrete and unambiguous diagrams.

30. Conclusions • Visualization with graphs helps in understanding and communicating the behavior • By automating the translation process: • The expertise shifts from Chi & SPIN to UML. • Less error prone: Consistency between Chi and UML and Promela and UML improved. • Less time consuming: From >40 hours to <1 hour.

31. Future extensions (ideas) • Some UML possibilities were omitted, but are very useful, e.g. Composite states, allows to decompose a complex activity diagram in several simper connected sub-diagrams. Add this functionality. • Compare the results from the real machine with the model simulation results, to pin-point design problems and/or update the model • Automatically generate program code (C, C++, Java) for the control sequence • Run-time optimization (recipe dependent scheduling)

32. Consideration… • If one diagram says more than 100 lines of text, • if one formula says more than 100 diagrams, • if there are not many people grasping the formula’s, • if there are many people grasping the diagrams, … • then, combine diagrams and formulas, and automate the checking • But always, if possible, keep it simple!!!