• No results found

Redesigning the Image Sensor Subsystem Driver Using the Object-Oriented Paradigm

N/A
N/A
Protected

Academic year: 2022

Share "Redesigning the Image Sensor Subsystem Driver Using the Object-Oriented Paradigm"

Copied!
75
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

Redesigning the Image Sensor Subsystem Driver Using the Object-Oriented Paradigm

Citation for published version (APA):

Beyene, S. T. (2021). Redesigning the Image Sensor Subsystem Driver Using the Object-Oriented Paradigm.

Technische Universiteit Eindhoven.

Document status and date:

Published: 04/10/2021

Document Version:

Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.

• You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne Take down policy

If you believe that this document breaches copyright please contact us at:

openaccess@tue.nl

providing details and we will investigate your claim.

Download date: 28. Jul. 2022

(2)

PDEng SOFTWARE TECHNOLOGY

Redesigning the Image Sensor Subsystem Driver using the Object-Oriented Paradigm

Samsom Tsegay Beyene October 2021

Department of Mathematics & Computer Science

(3)
(4)

Redesigning the Image Sensor Subsystem Driver using the Object-Oriented Paradigm

Samsom Tsegay Beyene

October 2021

Eindhoven University of Technology Stan Ackermans Institute – Software Technology

PDEng Report: 2021/066

Confidentiality Status: Public

Partners

ASML Netherlands B.V. Eindhoven University of Technology Steering

Group

Samsom Tsegay Beyene Camiel Rouweler Tom Verhoeff

Fernando Velho Dutra Yanja Dajsuren

Date October 2021

(5)

Composition of the Thesis Evaluation Committee:

Chair: Prof.dr.ir. Mark van den Brand Members: Ir. Camiel Rouweler

Fernando Velho Dutra, MSc Dr.ir. Tom Verhoeff

Ir. Sander van den Berg Dr. Kees Huizing

The design that is described in this report has been carried out in accordance with the rules of the TU/e Code of Scientific Conduct.

(6)

Contact Address

Eindhoven University of Technology

Department of Mathematics and Computer Science

MF 5.080A, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands +31 402743908

Partnership This project was supported by Eindhoven University of Technology and ASML.

Published by Eindhoven University of Technology Stan Ackermans Institute

PDEng-report 2021/066 Preferred

reference

S.T. Beyene, Redesigning the Image Sensor Subsystem Driver using the Object- Oriented Paradigm, Eindhoven University of Technology, PDEng Report 2021/066, October 2021

Abstract ASML’s lithography machines are driven by complex software components. The camera driver is one of the software components inside ASML’s image sensor subsystem driver. This driver is implemented in the C language and has grown its complexity over the last few years. Hence, it becomes hard to maintain and to modify when we add new features over time. This project was organized to assess the benefits of applying Object-Oriented design and its added value by redesigning the driver and migrating the main use cases of the driver into C++.

Keywords Object-Oriented, Driver, Image Sensor, Complexity, Maintainability, modifiabil- ity, PDEng Software Technology, ASML

Disclaimer Endorsement

Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the Eindhoven University of Technology or ASML. The views and opinions of authors expressed herein do not necessarily state or reflect those of the Eindhoven University of Technology or ASML, and shall not be used for advertising or product endorsement purposes.

Disclaimer Liability

While every effort will be made to ensure that the information contained within this report is accurate and up to date, Eindhoven University of Technology makes no warranty, representation or undertaking whether expressed or implied, nor does it assume any legal liability, whether direct or indirect, or responsibility for the accuracy, completeness, or usefulness of any information.

Trademarks Product and company names mentioned herein may be trademarks and/or service marks of their respective owners. We use these names without any particular en- dorsement or with the intent to infringe the copyright of the respective owners.

Copyright Copyright © 2021. Eindhoven University of Technology. All rights reserved.

No part of the material protected by this copyright notice may be reproduced, mod- ified, or redistributed in any form or by any means, electronic or mechanical, in- cluding photocopying, recording, or by any information storage or retrieval sys- tem, without the prior written permission of the Eindhoven University of Technol- ogy and ASML.

(7)

i

Foreword

To those familiar in the industry, ASML has the image of a company that produces cutting-edge tech- nology, which makes the impossible possible. If I may say so, this image is well deserved. But to the surprise of many people new to ASML, the technology that ASML uses to create their products is not always state of the art. The bulk of the source code for the TWINSCAN software is still written in C, a programming language from the 1970s.

Although ASML aims to replace the use of C by C++ (a slightly less ancient programming language!), there is a lack of time and sometimes experience to convert legacy code systematically. We invited Samsom Beyene to convert one software component to C++ as an assignment for his OOTI education.

This pilot project to convert a component should demonstrate the benefits of using C++ and expose challenges and best practices to be used in the conversion. Samsom’s experiences with this undertaking are described in full detail in this thesis.

Despite the steep learning curve involved in understanding the ASML business domain, legacy software and development environment, Samsom made a quick start and steady progress since then. He showed us how some common coding patterns in ASML can be done much more simple and robust when using Object-Oriented techniques and a programming language that supports them. I considered the Image Sensor Driver, the software component that Samsom converted, to be a complex component, but after his redesign it looks much simpler already.

Samsom’s report gives us a good insight in the challenges one encounters when making the transition to C++ and provides valuable suggestions on how to deal with commonly occurring patterns in ASML code in an objected-oriented way.

I hope that Samsom’s experiences as documented in this report will convince everyone involved in ASML software development of the power of C++ and will inspire them to upgrade their code and tooling.

I want to thank Samsom for his dedication and hard work.

Camiel Rouweler

ASML Software Architect and ASML supervisor of Samsom.

September 2021

(8)

ii

(9)

iii

Preface

This report describes the graduation project for a partial fulfillment to obtain the Professional Doctorate in Engineering (PDEng) degree in Software Technology from the Eindhoven University of Technology.

The project titled “Redesigning the Image Sensor Subsystem Driver using the Object-Oriented Para- digm” was executed under the supervision of ASML Netherlands B.V. in Veldhoven. The project was performed in ten months and was conducted in the Embedded software department within the Image Sensors team. The goal of the project was to redesign the image sensor’s camera driver using Object- Oriented Design (OOD) techniques and implement the design using C++ to achieve maintainability, readability, and modifiability while maintaining the functionalities and performance. In addition, the project aimed to assess the benefits of applying Object-Oriented (OO) programming techniques over the C language in an embedded software environment and demonstrate the integrability of the new C++

implementation with its surrounding C code.

This project was carried out by the author, Samsom Beyene, under the supervision of Camiel Rouweler from ASML and Tom Verhoeff from the Eindhoven University of Technology.

The report is intended for readers who are interested in Object-Oriented Analysis and Design. A basic understanding of software engineering, Design patterns, and UML diagrams is assumed. This report is organized such that readers are guided smoothly from the problem through to the solution. The first four chapters present the context, the thorough analysis of the problem, the stakeholder analysis, and requirements consecutively. In Chapter 5, the redesign of the image sensor’s camera driver is described.

In this chapter, the detailed design applied for each layer of the driver is explained. In Chapter 6, the prototype implementation of the redesigned driver is described.

In Chapter 7, the techniques used to verify and validate the prototype implementation and their results are presented. The results obtained in this project are summarized in Chapter 8. Future work recom- mendations are also presented in this chapter. Finally, Chapter 9 and Chapter 10 describe the project management and project retrospective, respectively.

Samsom T. Beyene October 2021

(10)

iv

(11)

v

Acknowledgments

First of all, I would like to thank ASML For considering me worthy of carrying out this project. I would like to thank my company supervisors, Camiel Rouweler, Fernando Velho Dutra, and Jianfeng Zhao, for their continuous support, guidance, and feedback throughout the project. Their experienced insight helped me to continuously improve myself both professionally and technically. I would also like to thank the Image Sensors team for helping me during the project.

I would like to extend my thanks to my university supervisor, Tom Verhoeff, for his constructive feed- back and encouragement throughout the project. I very much appreciate his continuous commitment to this project and his critical scientific feedback on my process and deliverables. I would also like to thank the program director of PDEng Software Technology, Yanja Dajsuren, and the program secretary, De- siree van Oorschot, for their support and management of the entire curriculum of the Software Tech- nology program. Also, I would like to thank all the coaches for their instructive lectures, which helped me improve myself during the program period.

I would like to thank all my fellow PDEng Software Technology 2019 trainees for their feedback and support throughout the program. The lessons learned from working with them played an essential part in my design and teamwork process for the thesis project. It was a pleasure to work with these beauti- ful people from around the world.

Finally, I would like to offer my special thanks to my parents, sisters, brothers, and friends for their love, support, and encouragement.

Samsom T. Beyene October 2021

(12)

vi

(13)

vii

Executive Summary

ASML is the leading provider of lithography systems in the world. These lithography systems are com- plex machines that are critical in the production of integrated circuits or microchips. Inside the ASML machines, there is an image sensor module that measures various optical system parameters such as lens aberrations, pupil illumination, and polarization state of the scanner. This module is controlled by a set of software components, with the camera driver being one of them. Over the years, the camera driver has become more complex as a result of incorporating new requirements. Most importantly, the driver is implemented in C language, which is generally not efficient and modular. In addition, as the software driver gets bigger and bigger, it becomes hard to maintain and to modify it more easily. There- fore, ASML needed an object-oriented modular redesign of the driver and a prototype implementation of the redesign to exploit the advantages of Object-Oriented (OO) programming.

The goal of the project was to redesign the camera driver using Object-Oriented Design (OOD) tech- niques and implement the design using C++. In addition, the project aimed to assess the benefits of applying OO programming techniques over the C language in an embedded software environment and demonstrate the integrability of the new C++ implementation with surrounding C code. The prototype implementation of the redesign of the driver should have the same functionalities as its original C im- plementation without hurting its performance quality.

A redesign of the camera driver was developed. In this redesign, different OOD techniques such as design patterns and SOLID principles were applied. Applying these techniques helps to divide and structure the responsibility of the camera driver into smaller and decoupled classes. This arrangement improves the modularity of the driver. Furthermore, the design avoids cyclic dependencies between classes or layers of the driver and is flexible for the extendibility of new camera sensors in the new feature. For a proof of concept, a prototype implementation of this redesign in the C++ language was provided. This implementation was tested on an ATTEST, unit testing environment, the testing simu- lation environment (Devbench) and on the testing environment that involves real hardware (Testbench).

The result shows that the prototype implementation fulfills the main functional requirements of the camera driver. In addition, C++’s memory management and exception handling techniques were ap- plied to efficiently manage memory leaks and debug errors, respectively. Furthermore, the size of the driver codebase (total number of lines of code) is reduced by at least 15% in the new C++ implementa- tion. This reduction improves the maintainability and readability of the driver’s code with insignificant performance differences from its original implementation. Besides, A short guideline for migrating a C component to C++ is provided in the confidential version of this document as an appendix.

In conclusion, the redesign of the camera driver and its prototype implementation in C++ brings many benefits compared to its original C implementation. The benefits are that it is easy to:

• Apply design patterns and SOLID principles

• Apply good memory management and exception handling techniques

• Increase modularity and maintainability

• Extend new features

Furthermore, C++ provides the Standard Template Library (STL) that consists of containers, iterators, and algorithms. The STL library greatly improves productivity by helping developers deliver fast, effi- cient, and robust code. Therefore, we recommend that ASML migrate other software components in the image sensor subsystems written in C into C++ to improve the quantity and quality of the software components.

(14)

viii

(15)

ix

Table of Contents

Foreword ... i

Preface ... iii

Acknowledgments ... v

Executive Summary ... vii

Table of Contents ... ix

List of Figures ... xii

List of Tables ... xiv

1. Introduction ... 1

1.1 Context ... 1

1.2 Project goal and scope ... 1

1.3 Image Sensors ... 2

1.3.1. Purpose of the Image Sensors ... 2

1.3.2. Functionality of image sensors ... 3

1.4 Image sensor subsystem driver ... 4

1.5 Outline ... 5

2. Problem Analysis ... 6

2.1 Problem definition ... 6

2.1.1. Analysis of existing subsystem driver ... 6

2.1.2. Problem Statement ... 7

2.2 Design challenges ... 7

2.3 Assumptions ... 8

2.4 Constraints ... 8

3. Stakeholder Analysis ... 9

3.1 Stakeholder identification ... 9

3.2 Stakeholder interests ... 10

4. Requirements Elicitation ... 13

4.1 MoSCoW ... 13

4.2 Project Requirements ... 13

4.3 Product Requirements ... 16

5. System Design ... 19

5.1 Driver overview ... 19

5.2 Design strategy ... 20

5.3 High-Level Architecture ... 21

(16)

x

5.4 Detailed design ... 23

5.4.1. Application layer ... 24

5.4.2. Communication layer... 24

5.4.3. Hardware abstraction layer ... 27

5.5 Sequence diagrams ... 28

6. Implementation ... 30

6.1 Environment setup and C++ DDF bindings ... 30

6.1.1. Environment setup ... 30

6.1.2. C++ DDF bindings ... 30

6.2 Use case Implementation snippets ... 30

6.2.1. Driver startup and shutdown ... 30

6.2.2. Hardware initialization and termination ... 31

6.2.3. Frame grabbing ... 32

6.3 Implementation of the redesign improvements ... 32

7. Verification and Validation ... 33

7.1 Validation process ... 33

7.2 Verification process ... 33

7.2.1. Unit testing ... 33

7.2.2. Integration testing ... 34

7.2.3. System testing ... 36

7.3 Performance quality ... 37

7.4 Extendibility quality... 38

8. Conclusion ... 39

8.1 Results ... 39

8.2 Future work ... 39

8.3 Good practices on migrating C codebase into C++ ... 40

8.3.1. Understand the codebase thoroughly and extract the main use cases ... 41

8.3.2. Prioritize the use cases and migrate step by step ... 41

8.3.3. Have a C++ reference guideline at an early stage of the migration ... 41

8.3.4. Use C++ STL libraries over company-specific C macros ... 42

9. Project Management ... 43

9.1 Work-breakdown structure ... 43

9.2 Project planning ... 43

9.3 Risk management ... 45

10. Project Retrospective ... 47

10.1 Challenges ... 47

10.1.1. Understanding the domain and learning the tools... 47

10.1.2. Extracting main functionalities from a legacy code ... 47

10.2 Lesson learned ... 47

10.2.1. Communicate project progress and concerns openly... 47

10.2.2. Ask people around and do not wait ... 47

(17)

xi

Glossary ... 49

Bibliography ... 51

Appendix A – Migration from C to C++ quick reference guidelines ... 53

About the Author ... 54

(18)

xii

List of Figures

Figure 1: Process of pattern printing on a wafer ... 2

Figure 2: Life cycle of a wafer ... 3

Figure 3: Example of a wavefront and perfect lens ... 4

Figure 4: Context diagram of image sensor subsystem driver ... 5

Figure 5: Existing situation of image sensor’s camera driver ... 6

Figure 6: Desired solution of image sensor's camera driver ... 7

Figure 7: Stakeholder analysis matrix ... 9

Figure 8: Image sensor’s camera driver use case ... 17

Figure 9: Component diagram of the camera driver ... 19

Figure 10: Existing driver layering dependency ... 21

Figure 11: High-level design alternative one ... 22

Figure 12: High-level design alternative two ... 23

Figure 13: UML class diagram for the application layer ... 24

Figure 14: UML class diagram for the communication layer ... 25

Figure 15: UML class diagram for sensors and relays ... 26

Figure 16: Updated UML class diagram for sensors and relays ... 27

Figure 17: UML class diagram for the hardware abstraction layer ... 28

Figure 18: Sequence diagram for driver start up ... 28

Figure 19: Sequence diagram for driver HSSL hardware initialization ... 29

Figure 20: Driver startup and shutdown snippets ... 31

Figure 21: Driver hardware initialization and termination snippets ... 32

Figure 22: Grab frame use case snippet ... 32

Figure 23: test case results for COB initialization ... 34

Figure 24: The SUT and its test environment ... 35

Figure 25: Integration test results before and after step-wise initialization ... 36

Figure 26: System test result for grabbing frame use case ... 37

Figure 27: Performance measurement for grabbing frame use case ... 38

Figure 28: UML class diagram for extending a new sensor and relay ... 38

Figure 29: C++ wrapper for non-DDF dependencies ... 40

Figure 30: Work-breakdown structure of the project ... 43

Figure 31: Initial project plan ... 44

(19)

xiii

(20)

xiv

List of Tables

Table 1: Main stakeholder concerns and interests ... 10

Table 2: Additional stakeholder concerns and interests ... 11

Table 3: Project requirement ... 13

Table 4: Product requirements ... 17

Table 5: Test cases for COB initialization ... 34

Table 6: Existing sample test cases used in integration test ... 35

Table 7: Project risks ... 45

(21)

1

1. Introduction

This chapter provides a brief introduction to this project by discussing its context, goal, and scope.

Additionally, this chapter also introduces the Image Sensing (IS) functionality within the ASML lithog- raphy machines. Section 1.6 presents the outline of this report.

1.1 Context

This project is carried out as a final design project for the Professional Doctorate in Engineering (PDEng) program. The PDEng degree program in Software Technology is provided by the Department of Mathematics and Computer Science at Eindhoven University of Technology (TU/e) in the context of the 4TU. School for Technological Design, Stan Ackerman’s Institute. This project was conducted at ASML, and people from both parties (ASML and TU/e) supervised me throughout the project.

ASML is the leading provider of lithography systems in the world. These lithography systems are com- plex machines that are critical in the production of integrated circuits or microchips. In the process of manufacturing integrated circuits, lithography is the name for the cycle of steps where one of the circuit layouts is scanned (printed) onto a microchip. Hence, ASML’s lithography TwinScan machines need to perform with high precision to ensure that manufactured chips work as intended. For this reason, ASML machines heavily rely on a complex software that is divided into functional clusters, which contain one or more components. The components in each functional cluster are developed and main- tained by a specific group of developers.

One of these software groups in ASML is the Image Sensing Embedded Software Group. This group initiated this project. The group develops and maintains image sensor drivers for measuring various optical system parameters such as lens aberrations, pupil illumination, and polarization state of the scanner for ASML’s lithography machines. A subteam of this group develops subsystem drivers for different sensor types. One of these drivers is the Image Sensor Subsystem Driver. It is responsible for measuring the shape of wavefronts passing through the optical system. Since this driver's software logic is implemented using the C programming language, it is becoming more complex as new features are added over time. Most importantly, the implementation of this complex component using a C program- ming language is not efficient and not modular. Therefore, a modular redesign and implementation of this component were needed to continue delivering a high-quality product to ASML customers.

1.2 Project goal and scope

This project aims to redesign the image sensor driver component using Object-Oriented Design (OOD) techniques and implement the redesign using C++. It aims to assess the benefits of using Object-Ori- ented (OO) programming techniques and the integrability of C++ code with surrounding C code. The scope of the integration with surrounding C code is mainly with the client of this component. This project shall act as a technical proof of concept for applying an OO programming approach to the image sensor driver using C++. The following subgoals (tasks) were formulated to achieve the goals of this project:

1. Extract the functional and non-functional requirements of the image sensor driver component from the current existing source code, requirement and design documents, and experts.

2. Redesign the component using OOD techniques.

(22)

2

3. Implement a prototype of the redesign using the C++ language (C++11 + boost)

4. Validate the prototype against the main use cases of the component. Validation here is about functional correctness and includes non-functional requirements, particularly the extendibility of the redesign for new sensors and relays.

5. Report the project findings for future use in the ASML image sensing domain and possibly for subsystem driver development in other ASML domains.

The scope of the project is the image sensor’s camera driver. It is responsible for controlling the differ- ent types of cameras to capture wavefront images. It also manages communication links that connect the cameras with the CPU board on which the driver runs.

1.3 Image Sensors

1.3.1. Purpose of the Image Sensors

Manufacturing integrated circuits in the semiconductor industry requires several process steps, from slicing a cylinder of purified silicon material into wafers to packaging. The ASML machine performs one of the IC manufacturing key process steps called the lithography process. It is the name for the cycle of steps in which one layer of the circuit layout is exposed onto a chip. This process of pattern printing on a wafer using ASML lithographic machines is shown in Figure 1. First, a beam of ultraviolet (UV) light is passed through a reticle that is to be printed on the wafer. Then, the pattern is projected on the wafer by the projection lens after light passes through it. Several image sensors are used in the wafer stage to achieve the quality requirements, such as image resolution and overlay accuracy.

Figure 1: Process of pattern printing on a wafer

(23)

3 During the pattern projection, the lens’s accuracy is critical to print the chip patterns on the wafer cor- rectly. Hence, the image sensing subsystem provides a measurement of the scanner's optical parameters at the exposed side.

1.3.2. Functionality of image sensors

In ASML lithographic machines, a wafer life cycle has two stages: measurement and exposure. These two stages are shown in Figure 2. A wafer can be either at the measure or expose stage. The wafer position is measured with respect to the chuck in the X, Y, and Z directions on the measurement side.

The result of these measurements is used to align the position of the wafer with the reticle on the expose stage. After the wafer is aligned to the reticle, it is exposed to the reticle’s pattern to be printed on it.

Figure 2: Life cycle of a wafer

The image sensors technically exist on both sides. However, they are only used on the expose side because they are used to measure the quality of the light at the wafer level, which is done only at the exposed side. The beam of light is diffracted, using a diffraction material, into the chip’s layout in the form of a spherical wavefront. The projection lens turns this wavefront into a spherical wavefront with opposite curvature and converges to a focal point to form an image of the layout, as shown in Figure 3.

A perfect lens creates a perfectly spherical wavefront, and hence the image produced at the focus point is sharp. However, a lens has aberrations due to aging, heat, and dust that make a non-spherical wave- front, leading to so-called aberrations that cause distortion on the wavefront and compromise the image quality printed at the wafer.

(24)

4

Figure 3: Example of a wavefront and perfect lens

Therefore, the image sensors are used to capture the wavefronts at the requested exposure time, and the captured image is post-processed to know the lens’s degree of deviation. This degree of deviation is used by higher-level software layers in order to close a control loop that actuates on moving lens ele- ments to minimize aberrations. For more information on image sensor functionalities, refer to [1].

1.4 Image sensor subsystem driver

The image sensor driver is divided into software layers, and there is one layer to control physical actions in the machine and another layer to control logical actions. The image sensor subsystem driver provides functions to execute physical actions requested by the image sensor logical actions. It programs the image sensor electronics, measures various optical parameters of the scanner, and provides information needed to set up the scanner. Besides, the driver offers functionality for simulation and diagnostics of the image sensor subsystem electronics.

The image sensor is used to scan different images. The image sensor moves, based on its setting, while taking pictures, creating real scans that allow further use of interferometry to measure lens aberrations.

To apply these scans, the image sensor subsystem driver forwards the command to its own image sen- sor’s camera driver, as shown in Figure 4, to execute the requested action. This scan is necessary to measure the lens’s aberrations and other main optical parameters.

(25)

5 Figure 4: Context diagram of image sensor subsystem driver

For measuring the scanner’s optical parameters, different scan types are applied with different direc- tions, positions, and a number of frames at a given exposure time. Hence, the image sensor subsystem driver’s main purpose is to apply different scan types and measure the scanner's optical parameters to keep it in a high-performing state during production.

1.5 Outline

This report is further structured as follows. Chapter 2 provides the problem analysis and an overview of the design challenges. Chapter 3 presents the stakeholders’ interests and goals. The project require- ments elicited from stakeholder meetings and documents are presented in Chapter 4. Chapter 5 describes the high-level design and detailed design of the image sensor’s camera driver, including design alterna- tives that were considered. In addition, the design decisions that guided the design process are docu- mented. Chapter 6 explains the implementation aspects of the driver. In Chapter 7, the verification and validation techniques performed in this project as well as the results of applying those techniques, are discussed in detail. Chapter 8 discusses the conclusion, good practices on migrating C code drivers to C++, and future work. Finally, Chapter 9 and Chapter 10 describe the project management and retro- spective, respectively.

(26)

6

2. Problem Analysis

This chapter describes the existing image sensor driver in ASML’s lithography machines. The problem definition, the proposed solution direction, and the identified design challenges are also presented.

2.1 Problem definition

2.1.1. Analysis of existing subsystem driver

The image sensing embedded software team develops and maintains subsystem drivers for different sensor types. One of these drivers is an image sensor subsystem driver responsible for image scanning and measuring the scanner’s optical parameters at the expose stage. This driver’s software logic is im- plemented using the C programming language, as shown in Figure 5. Because of continuous innovation and new features, the software driver logic is becoming complex and not as structured as ASML would like it to be. For this reason, it becomes increasingly difficult to innovate and add new features into the driver for which the source code is not modular, reusable, and flexible.

Figure 5: Existing situation of image sensor’s camera driver

Implementation of a complex driver using a procedural programming language (C) has some of the following drawbacks:

• Explicit allocation and deallocation of memory

• Prone to type-safety issues

• Poor on error handling

• Requires more Line of Codes (LOC) for the same functionality than C++, as LOC is a good measure of maintainability

• Not modular and inflexible to new features

To alleviate the above problems and develop efficient, reusable, modular, and flexible complex driver software, embedded software companies have been making a transition from C to C++ [2] following some basic refactoring guidelines [3]. Hence, ASML wanted to implement the driver in object-oriented

(27)

7 programming, particularly in C++, which is the current default programming language for new or rede- signed driver development. Therefore, a redesign of the image sensor’s camera driver using an object- oriented paradigm was needed.

2.1.2. Problem Statement

In light of the analysis described above, the project focuses on redesigning the image sensor’s camera driver using object-oriented design, implementing the prototype of the design in C++, and integrating the implemented prototype with its client, which is implemented in C. This approach has the following advantages:

• Easy to apply design patterns that help to have efficient, reusable, and maintainable code

• Good memory management

• Good exception handling

• Type-safe features

• Increases modularity

• Extendable for new features

The overview of the desired solution expected from this project is shown in Figure 6. The redesign of the image sensor’s camera driver is designed following Object-Oriented Design (OOD) principles [4].

The redesigned driver component is implemented in C++ following ASML’s coding standard [5]. This project reports the guidelines, best practices, and challenges to migrate a C component to C++. As a result, ASML's image sensing team benefits from the learning experience gained during the migration of the C driver component to C++.

Figure 6: Desired solution of image sensor's camera driver

2.2 Design challenges

The most important design challenges identified in this project were flexibility, extendibility, maintain- ability, and testability. These design challenges were identified through analysis of requirements,

(28)

8

problem domain, and discussion with stakeholders. These criteria were used throughout the course of the project to improve the redesign of the image sensor’s camera driver.

Flexibility

Reducing dependency between layers of the driver component increases its flexibility. In the existing codebase, there is a cyclic dependency between these layers. Hence, avoiding cyclic dependency be- tween different driver layers was one of the design challenges in this project. It was also necessary that upward dependency between layers should be avoided in the design.

Extendability

The image sensor’s camera driver component supports different hardware versions, i.e., the relays and sensors. Hence, the design solution had to be robust enough to support new versions of these devices in the near future.

Maintainability

The design challenge here was to make the implementation of the camera driver clean, simple, and easy to modify. This was achieved by applying SOLID principles [6] and other object-oriented features in the design iteratively throughout the project period.

Testability

The challenge here was to make the prototype implementation of the design easy to test. In particular, the challenge was to be able to provide unit tests that focus on small units by ensuring decoupling. This helps to easily locate and fix bugs early. Unit tests were applied for each class to validate the testability of the camera driver prototype.

2.3 Assumptions

The following assumptions were considered at the beginning of this project.

• The codebase version of the image sensor driver was fixed and used as a reference to the pro- totype C++ implementation.

• The component’s main functionalities have no major change from the Element Performance Specification (EPS) document [7]. New feature changes during the project period will not be considered.

• The design prototype implementation will be tested in the NXE machine testing environment.

2.4 Constraints

After discussions with stakeholders, the project had the following constraints that might also influence the design decisions.

• The external interfaces of the component should remain intact. This means that the clients should not need to change to use the redesign component.

• The implementation of the redesign should use the C++ language (version: C++11 + boost, compiler: gcc 4.4.2).

• The implementation of the redesign should use ASML’s C++ coding standard [5].

• The duration of the project is ten months.

(29)

9

3. Stakeholder Analysis

Stakeholder analysis helps to identify and understand key stakeholders’ concerns as well as their ex- pectations from the project. This chapter identifies the main stakeholders of the project. The stakeholder identification process, their interests, and communication channels used are also discussed in this chap- ter.

3.1 Stakeholder identification

Stakeholder analysis is a process of identifying people who are interested in the project or affected by the project; grouping these people according to their levels of participation, interest, and influence in the project; and determining how best to engage and communicate with each of these stakeholder groups throughout the project period. In this project, a stakeholder analysis matrix [8] is used to help identify- ing, prioritizing, and grouping important stakeholders. This matrix categorizes stakeholders into a 2x2 grid based on their influence (power), interest, and levels of participation in the project. In order to address and monitor different stakeholder concerns, the following techniques were applied throughout the project:

• Stakeholders who hold high power and high interest need to be managed closely.

• Stakeholders who hold high power and low interest need to be kept satisfied.

• Stakeholders who hold low power and high interest need to be kept informed.

• Stakeholders who hold low power and low interest need to be monitored.

Figure 7 shows the stakeholder analysis matrix of this project. The vertical axis represents the power a stakeholder holds that could affect the project. The horizontal axis represents the interests and level of participation a stakeholder has toward the project. Several stakeholders based on their roles were iden- tified and mapped into the matrix, as can be seen clearly in the figure below. A detailed explanation of their interests and roles are discussed in subsection 3.2.

Figure 7: Stakeholder analysis matrix

(30)

10

3.2 Stakeholder interests

The concerns, interests, and involvement for the main stakeholders that are identified in the stakeholder identification subsection above are described here. These concerns are later mapped or translated into the project requirements. The following stakeholder-specific aspects are used to describe the main stakeholder concerns, as shown in Table 1.

• Goals: Their goals or interest in the project

• Roles: Their roles in the project

• Acceptance criteria: Their expectations from the project

• Involvement: Their availability and the communication channels used

Table 1: Main stakeholder concerns and interests Camiel Rouweler: Project supervisor from ASML

Goals

• Demonstrate feasibility and added value of redesigning an existing C implementation of an image sensor subsystem driver into a new equivalent OO variant.

• Demonstrate the challenges and best practices in C++ driver de- velopment that can serve as a benchmark for next developments in the image sensing domain group of ASML.

• Integrate the new OO prototype with other subsystem components.

Roles

• Provide guidance on the project.

• Evaluate progress and provide feedback.

• Evaluate project deliverables.

• Review project technical report.

Acceptance criteria

• Weekly and monthly progress reports.

• Prototype for the image sensor subsystem driver using OOD and C++.

• Proof of concept of the redesign solution that provides extendibil- ity for new sensors and relays.

• Proof of concept for integrating the prototype with existing other C components.

• Final report for the project findings.

Involvement

• Weekly meetings and additional ad-hoc meetings throughout the project duration and monthly PSG meetings alongside other stake- holders.

Tom Verhoeff: Project supervisor from TU/e

Goals

• Guide the trainee throughout the project duration.

• Ensure that the solution design fulfills the defined project goal.

Roles

• Provide guidance on the project.

• Evaluate project progress and provide feedback.

(31)

11

• Evaluate trainee’s overall performance and provide feedback.

• Review project technical report.

Acceptance criteria • Regular project progress update.

• The project process management, design, and realization meet the requirement of the PDEng Software Technology program.

• Final report for the project findings.

Involvement • Biweekly meetings and monthly PSG meetings alongside other stakeholders.

Fernando Velho Dutra: Managerial supervisor from ASML

Goals

• Demonstrate feasibility and added value of redesigning an existing component into a new equivalent OO variant.

• Knowledge, challenges, and experiences gained on migrating from C into C++.

Roles

• Provide guidance and managerial support to the trainee.

• Evaluate progress and provide feedback.

• Evaluate the performance and approach of the trainee as well as provide feedback on potential improvements.

Acceptance criteria

• Regular project progress report.

• Keep all stakeholders informed about the project methodology and progress.

Involvement • Monthly PSG meetings and additional ad-hoc meetings.

The concerns and involvements for the main stakeholders that have to be managed closely or need to be kept satisfied are described in detail in Table 1. Additional stakeholder concerns and interests are discussed in Table 2. The involvement with these stakeholders is by ad-hoc meetings or email commu- nication.

Table 2: Additional stakeholder concerns and interests

Stakeholder Interest Concerns

PDEng ST management Successful completion of the pro- ject.

The project fulfills the criteria for completion.

Technical mentor Demonstrating the redesigning of the image sensor subsystem driver by applying the OO approach. Eval- uate the integrability of the imple- mented prototype with other com- ponents that are implemented in C.

The project fulfills the criteria for completion, and the prototype of the project acts as a reference for future use of C++ language as a standard in the image sensing do- main group.

(32)

12

Stakeholder Interest Concerns

Image sensor subsystem software development team

Software development using the OO approach helps to have effi- cient, flexible, reusable, and main- tainable code. This motivates the development team to transit from old C to C++, which allows them to facilitate their development and de- liver a high-quality product to their customer.

The OO approach (C++) transi- tion might introduce additional burdens such as studying and ap- plying the OO approach using C++. Documentation of all the ex- periences and practices gained in this project solves this problem.

(33)

13

4. Requirements Elicitation

The problem and stakeholder analysis are presented in Chapters 2 and 3, respectively. The purpose of this chapter is to present the requirements considered for this project. The requirements are divided into two categories: project requirements and product requirements. The project requirements are defined by analyzing the problem and discussing it with stakeholders. The product (image sensor’s camera driver) requirements are elicited from an already existing requirement document [7] in ASML. The requirements, their priorities, and the primary use cases are provided in this chapter.

4.1 MoSCoW

MoSCoW [9] is a requirement prioritization technique containing the following levels:

1) Must have (M) requirements:

The requirements under this category must be satisfied for the product to be accepted 2) Should have (S) requirements:

The requirements under this category should be satisfied if possible. It is not acceptable that all of the requirements in this category are entirely ignored.

3) Could have (C) requirements:

The requirements under this category could be satisfied if time is available. The requirements under this category are also called nice to have requirements

4) Won’t have (W) requirements:

The requirements under this category will not be satisfied in the scope of the project.

In this project, the MoSCoW technique was used to prioritize the project requirements.

4.2 Project Requirements

The project requirements were formulated after investigating the codebase, reading existing documen- tation, and discussing with experts. Table 3 shows the list of the requirement derived from stakeholders’

interests and their priorities. These requirements also include the system’s quality (non-functional) as- pects and other requirements related to constraints. Furthermore, the requirements are described in de- tail, i.e., the rationale behind each of these requirements is given and the test strategies that were used for verifying each of these requirements are also explained.

Table 3: Project requirement

Req_Id Description, Rationale, and verification Priority

Description: The image sensor’s camera driver shall be redesigned using class and object modeling (object-oriented modeling). The redesign must be implementation technology independent.

Must

(34)

14

Req_Id Description, Rationale, and verification Priority

Req-1 Rationale: If the redesign is implementation specific, it would be highly coupled to the implementation technology. This would make changing implementation technology cumbersome without redesigning the driver.

Verification: This will be tested through reviews by supervisors and stakeholders. The test passes if no implementation-specific concepts are included in the design; it fails otherwise.

Req-2

Description: The design shall be implemented in the C++ (C++11 (with limited features) + boost) programming language.

Rationale: The design is targeted to be implemented using OOP lan- guages such as C++, Java, and Python. C++ is the target for this project and is a standard at ASML.

Verification: This will be tested by code reviews and compiling the im- plemented code using C++ compilers.

Must

Req-3

Description: The C++ implementation of the design shall follow the C++

coding standard of ASML.

Rationale: The implementation should be in compliance with the ASML coding standard for consistency purposes.

Verification: This will be tested by running an ASML tool called TICS that checks the compliance of the code with the coding standard.

Must

Req-4

Description: The implementation of the redesign shall use ASML’s C++

exception handling macros that propagate and log the exception (error) to the calling function or client.

Rationale: If an exception (error) occurs during an operation, the calling client should be notified about the error. Additionally, the source of the error should be known for debugging (diagnostics) purposes.

Verification: This will be tested by using a test-to-fail scenario. The test passes if the exception is correctly logged in the TwinScan machine’s error log file, and the record shows the source of the error as it propagates through different software classes; otherwise, it fails.

Must

Req-5 Description: The implementation of the redesign shall use the TwinScan diagnostic tracing facilities to log function tracing.

Rationale: It helps to identify failures caused by functional errors.

must

(35)

15

Req_Id Description, Rationale, and verification Priority

Verification: This will be tested by running the camera driver on Devbench and activating the trace mode. The test passes if the trace is correctly logged in the trace file of the ASML tracing facility.

Req-6

Description: A brief guideline reference on migrating a C component to C++ shall be formally reported in a document for future reference in ad- dition to this final report. The guideline report is added as an appendix to the confidential version of this final report.

Rationale: The findings, challenges, guidelines, and best practices can be used as a reference for future use or decision making in the image sensing domain and possibly other ASML domains.

Verification: The guideline reference will be reviewed by an expert. In addition, periodic progress updates through presentations, demos, and reports will be done with all stakeholders to ensure that all project find- ings and progress are discussed clearly.

Must

Req-7

Description: The complete solution (design and implementation) shall be integrated with the existing image sensor subsystem driver and other TwinScan generic facilities.

Rationale: The implementation of the redesign should be integrable with its client and other software components.

Verification: This will be tested by executing integration tests; after the implementation of the main use cases are fully developed.

Must

Req-8

Description: The redesign shall be extendable for new image sensors or relay devices.

Rationale: New image sensors or relay devices can be introduced in the near future.

Verification: This will be tested through reviews by supervisors and stakeholders.

Must

Req-9 Description: The redesign shall avoid cyclic dependency between the different layers of the driver component.

Rationale: Cyclic dependency between the layers increases complexity.

Hence, the cyclic dependency between layers of a component should be avoided.

Verification: This will be tested through reviews by supervisors and stakeholders.

Must

(36)

16

Req_Id Description, Rationale, and verification Priority

Req-10

Description: The implementation of the redesign shall be testable.

Rationale: The developed driver should be tested to verify that it is free of bugs and meets the functionality of the driver.

Verification: Unit tests will be applied for key public functions of each class of the driver. Besides, an integration test will be applied to test the camera driver with its client.

Must

Req-11

Description: The external interfaces of the driver shall not be redesigned or modified.

Rationale: These interfaces are a contract among the different image sen- sor subsystem components and should not be changed.

Verification: This will be tested through reviews by supervisors and stakeholders.

Must

Req-12

Description: The complete solution shall not hurt the performance (exe- cution time) of the existing system. The execution time should be more or less the same compared to the existing implementation.

Rationale: The implementation of the redesign should not introduce ex- ecution time bottlenecks.

Verification: This can be tested by running critical module use cases of the driver under the same environment setting and measuring the time it takes for both the new and existing systems.

Should

Req13

Description: The total memory size consumption of the implementation of the redesign shall be the same or less compared to the existing imple- mentation.

Rationale: The implementation of the redesign should use efficient memory management utilities (libraries).

Verification: This will be tested through a memory consumption ana- lyzer tool if it exists.

Could

4.3 Product Requirements

This subsection describes the functional requirements of the image sensor’s camera driver. These re- quirements describe the tasks that the driver should accomplish and how the driver completes the task.

The requirements are derived from an existing requirement document in ASML. The main UML use case functionality of the driver is shown in Figure 8.

(37)

17 The client, the image sensor subsystem driver, controls the camera driver. First, the client starts the camera driver during system startup, which sets global data and flags. After the startup of the driver is successful, the client initializes hardware components used to communicate with the camera, then ac- tivates the actual sensor. Next, the client can perform a queue scan, grab a frame, and request each hardware’s health status when the system is running. Finally, the client terminates the hardware com- ponents as well as shuts down the camera driver.

Figure 8: Image sensor’s camera driver use case

The camera driver’s main functional requirements [7] with their priorities are shown in Table 4. The camera driver provides interfaces for the client and peripheral to perform the use case actions shown in Figure 8. Code review, unit test, and component (integration) were used to verify each of these functional requirements.

Table 4: Product requirements

Req_Id Requirements Priority

PR1 The camera driver shall provide a startup interface to be started up by the client.

Must PR2 The camera driver shall provide a shutdown interface to be closed down

by the client.

Must PR3 The camera driver shall be able to perform step-wise initialization of

the image sensor hardware components.

Must PR4 The camera driver shall be able to terminate the image sensor hardware

components.

Must PR5 The camera driver shall handle actions related to queueing scan in the

image sensor peripherals

Must PR6 The camera driver shall activate the specified sensor type Must

(38)

18

Req_Id Requirements Priority

PR7 The camera driver shall be able to grab a frame using the specified sen- sor type

Must PR8 The camera driver shall deactivate the specified sensor type Must PR9 The camera driver shall request a test frame from the specified sensor

or relay.

Should PR10 The camera driver shall provide diagnostic data access facilities for the

specific image sensor hardware registers

Should

(39)

19

5. System Design

This chapter presents the design of the image sensor camera driver. It covers the overview of the driver, the design strategy, and the object-oriented analysis and design of the driver with their design alterna- tives. Section 5.1 discusses a brief overview of the camera driver followed by the design strategy in Section 5.2. Sections 5.3 to 5.5 present the detailed design of the image sensor’s camera driver.

5.1 Driver overview

The camera driver component is a component that provides an abstraction to the hardware components’

firmware in the image sensing domain. The image sensor subsystem driver component is the client of this driver. The driver uses another firmware component to access lower layer hardware modules that are used to communicate with the camera driver hardware modules. The lower layer hardware module contains a Dual High-speed serial link Pmc module (DHP), High-Speed Serial Link (HSSL), Direct Memory Access (DMA), and SyncBus Decoder (SBD). The camera driver consists of Copper to Optic Board (COB), Relays, and Sensors. The interaction of these three components is shown in Figure 9.

The main functions of the camera driver include the following:

• Initialize hardware components

• Facilitate queue scan on image sensor hardware components

• Request frame data from the camera sensor

• Request hardware health status and other hardware related information

Figure 9: Component diagram of the camera driver

As seen in Figure 9, the camera driver provides external interfaces to its client, the image sensor sub- system driver. The client uses these interfaces to command the camera driver to perform its main tasks.

The camera driver has no knowledge about the order of command operations from the client. It is up to

(40)

20

the client to manage and control the sequence of actions sent to the camera driver. This project forbade modifying both the required and provided interfaces as they are agreed on contracts among other soft- ware components of the ASML machine. Hence, the details of these interfaces are not discussed in this report. For complete descriptions of the interfaces, the reader might refer to the EPS of the camera driver component [7].

5.2 Design strategy

Every software design application has priority quality attributes that are determined by a software de- sign decision. To achieve all the software quality attributes at once is impossible. In most cases, a design strategy used to enable one quality attribute can have a negative impact on another quality attribute. For example, a design option that enables a system’s tolerance to failure and allows self-recovery may po- tentially affect the application’s performance. In this project, the design mainly aims to improve the following two quality attributes:

• Extensibility of the camera driver for future new sensor and relay hardware types (Req-8)

• Reducing the cyclic dependency (complexity) among different layers of the driver (Req-9)

Design pattern and the SOLID design principles [6] are used to achieve the attributes mentioned above and other software qualities. The SOLID design principle consists of the following aspects.

Single responsibility: A method, class, or package should have only one responsibility. Having one responsibility in a class enhances cohesion as functionalities related to that responsibility are group together. It also makes code easier to test and maintain and helps to avoid unanticipated side effects of future changes.

Open-closed principle: The idea of the open-closed principle is that an existing well-tested class should be open for extension and closed for modification. This principle means that when a new feature needs to be added to a class, we should be able to extend the class’s behavior without modifying it. The way to comply with this principle is using inheritance or interfaces that allow dynamic polymorphic substi- tutions. Dynamic polymorphism is a technique where a different form of a concrete class with the same interface or abstract class is instantiated during runtime. This technique is commonly known as Strategy Pattern [10]. Applying the open-closed principle improves the structure of an application and helps to write code that is maintainable and revisable.

Liskov substitution principle: The broad idea of this principle is that every child class should be sub- stitutable for its parent class. Inheritance is one of the object-oriented concepts where a class inherits behaviors of another class. Hence, the Liskov substitution principle ensures that derived (child) classes extend the base class without changing the specification of the base class.

Interface segregation: The general idea of interface segregation is that it is better to have many smaller interfaces than one general interface. This is achieved by making fine-grained interfaces that are client specific. Clients must implement all their provided interfaces and should not be forced to import inter- faces they do not use.

Dependency inversion: This principle offers a way to decouple software modules. This means that a class or module should depend on abstraction instead of concretions. Martin [6] further explains this principle by asserting that high-level modules should not depend on low-level modules. Both of them

(41)

21 should depend on abstractions, i.e., abstractions should not depend on details, and details should depend on abstractions.

5.3 High-Level Architecture

The camera driver is a component that is responsible for controlling the cameras and uses them to capture wavefront images. The driver also manages communication links that connect the cameras with the CPU board on which the driver runs. The tasks of the component are divided into the following hierarchical structure layers.

Dispatch layer: This layer handles the incoming client request operations. It receives and dispatches the client’s incoming command requests to the application layer.

Application layer: This layer contains different modules that are responsible for processing the re- quested operation received from the dispatch layer. It composes necessary actions and forwards to the low-level layers when appropriate.

Communication layer: This layer is responsible for communication with sensors and relays through COB hardware. The COB is also used to communicate with the lower hardware layer, which contains DHP and SBD modules.

Hardware abstraction layer: This layer provides hardware abstraction functions to the DHP and SBD hardware modules.

Support layer: This layer provides functionalities of the camera driver related to diagnostic logging and datastore support.

Figure 10 illustrates the existing layering structure and interactions of the driver component. This struc- ture is obtained as a result of investigating the source code and reading the driver documents.

Figure 10: Existing driver layering dependency

As a general layering structure principle, there should not be a cyclic dependency between the different layers of the driver and modules in a higher layer can depend on lower layers modules, but not the other way around. Furthermore, modules in the support layer cannot depend on modules in any of the other

(42)

22

layers. However, the existing camera driver does not meet these layering principles and the dependency category of these layers is shown in three categories: desired, undesired, and must be avoided. The interpretation of these categories is described as follows:

• Desired: This dependency is desired and should be kept as it is in the redesign

• Undesired: This dependency is unwanted and should be removed as much as possible in the redesign unless there is a reason to leave it as it is.

• Must be avoided: This dependency is forbidden and must be removed in the redesign

Two high-level design alternatives are proposed to solve the above-described limitation of the driver.

Figure 11 shows the first alternative design. This design is created by encapsulating data and similar functions of the driver into the five modules. It is an ideal design solution that solves cyclic and upward dependency. In addition, the support layer dependency on communication and hardware abstraction layers is resolved.

Figure 11: High-level design alternative one

This design option, however, has some drawbacks. This design forces some functions in the application layer to pass through the communication layer that is supposed to be forwarded directly to the hardware abstraction layer. This hurts the driver’s performance as these functions do not have any effect on the communication layer except adding overhead to the layer. Consequently, an updated version of this design is shown in Figure 12.

(43)

23 Figure 12: High-level design alternative two

This design solves the drawbacks mentioned for design alternative one as the application layer now has the freedom to choose either to the communication layer or directly forward to the hardware abstraction layer. Therefore, this design is realized, and the following high-level design decisions were made:

• Layers can only use the layer directly below it with the exception of the application layer, which can also use the hardware layer

• The dispatcher layer can only depend on the Support layer or Application layer

• Classes in the Support layer cannot depend on classes in any of the other layer classes

• Other layer classes can depend on the classes in the support layer

5.4 Detailed design

The detailed UML class diagrams and design alternatives are presented for the camera driver layers in this subsection. The dispatcher layer contains only a single class. This class is an entry point to the camera driver component, and it is responsible for validating the incoming client function calls from the client and dispatching them to the application layer if the requests are valid. Similarly, the support layer consists of four self-contained classes that provide generic facilities related to frame data storage and diagnostic logging. The detailed class diagram design for the application, communication, and hard- ware abstraction layers is discussed in the following subsections. In the diagrams, sample fields and function members of the class are mentioned for the simplicity of the diagram. Furthermore, the multi- plicity relationship between classes is one to one if it is not shown in the class diagram.

Referenties

GERELATEERDE DOCUMENTEN

The second sentence of article 51 of the Charter of the United Nations requires that measures taken by States in the exercise of the inherent right of self-defence ‘shall be

The addition of lower and higher concentrations of the mix of cryoprotectants as well as the addition of trehalose at the highest concentration, enhanced the earlier recovery time

circuits in Figure 8 share four terminals, but it is not possible to speak of the energy that flows from circuit 1 to circuit 2, unless the connected terminals form internal ports,

Since most of the rural areas in Indonesia have a high development potential in the agricultural sector (i.e. rice cultivation), community capacity building

The size and complexity of global commons prevent actors from achieving successful collective action in single, world- spanning, governance systems.. In this chapter, we

triage flow as a graph by encoding medical knowl- edge. This graph plays the role of dialogue man- agement to guide a system to interact with users and make a triage decision.

At the same time, nanotechnology has a number of characteristics that raise the risk of over-patenting, such as patents on building blocks of the technology and. overlapping

So far, UTAUT2 has been used to study online subjects similar to social media platforms, such as consumer acceptance behavior of mobile shopping (Marriott & Williams,