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
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,
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.
9