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.

24

5.4.1. Application layer

This layer deals with processing the incoming client requests dispatched through the dispatcher and forwarding the requests to the communication or hardware abstraction layers. There are several classes in this layer that are responsible for handling the main functionality of the camera driver. The internal structure and relationship of these classes are shown in Figure 13.

Figure 13: UML class diagram for the application layer

In the class diagram above, each of the classes has a specific responsibility to handle the client’s request.

The StartAndShutdown class deals with starting and shutting down the camera driver. The client per-forms step-wise initialization of the image sensor hardware components. The InitializationAndTermi-nation class is responsible for the initialization and termiInitializationAndTermi-nation of hardware modules that the camera driver controls. The client is in control of initializing the hardware components in steps and checks that all necessary steps are initialized. It requests the camera driver to initialize given hardware using the step id that indicates the step to be initialized. This request is dispatched to the InitializationAndTermi-nation class and this class checks if the requested step is valid. Then, it delegates the initialization task to the concrete classes responsible for initializing specific hardware, dynamically using the generic Ihardwareinitialization interface class. This design defines the family of hardware initialization into a separate class and uses their objects interchangeably using a common interface. This approach is com-monly known as the Strategy design pattern [10].

The other classes in this application layer are responsible for scan control, frame processing, frame grabbing, status handling, and test and diagnostic functions. They manage and process the dispatched client request and they further forward the request to the lower layers when necessary.

5.4.2. Communication layer

This layer is used for communication purposes between the camera driver hardware modules (COB, Sensors, relays) and the lower hardware modules (DHP, SBD, HSSL, DMA). The structure, function-ality, and design alternatives for the driver hardware modules are presented in this subsection. Figure 14 shows the UML class diagram of the communication layer. The sensor and relay are further designed in detail.

25 Figure 14: UML class diagram for the communication layer

The COBCommunication class is responsible for communication with the COB hardware. The COB hardware is connected to relay hardware and lower hardware modules through the HSSL link for data transfer and communication purposes. Hence, the COBCommunication class manages and processes the COB hardware-related functions and uses a relay object to send relay-related commands. The Do-moUpgrade class is responsible for updating a relay firmware using a DOMO protocol. As a general rule, a relay board must be running on the latest firmware version available that is compatible with the existing sensor types. The HardwareMatching class deals with finding the requested hardware type us-ing a hardware identification number. The design for the relay and sensor modules is discussed in the following subsections.

Sensor and relay design

The sensor and relay are some of the key hardware components of the image sensor subsystem driver.

The sensor is used to grab an image of a wavefront of the ASML’s lithography machine, and the relay is used as an interface between sensors and other hardware components of the ASML’s machine. There are two variants of sensors and relays in the existing system driver. The design focuses on these device types and considers extendibility for new sensors and relays in the foreseeable future. Figure 15 shows the class diagram for the sensors and relays.

26

Figure 15: UML class diagram for sensors and relays

As shown in the UML class diagram above, there are two controller classes: SensorController and Re-layController. The SensorController class is responsible for managing the different sensor types and storing the instances of these sensors by delegating the creation of the sensor objects to the ISensorFac-tory class. Similarly, the RelayController class is responsible for detecting the type of relay devices and managing the instances of these specific relay devices. This class delegates the creation of relay objects to the IRelayfactory class. Both the SensorController and RelayController classes depend on generic abstract classes for accessing the operation of their respective concrete classes as well as for creating an instance of the concrete device type. Hence, SensorController and RelayController act as entry points for accessing sensor and relay operations, respectively. This approach is commonly known as the Fa-çade design pattern [10].

The ISensor class defines a generic interface for relay-type devices. It contains functions for any oper-ations that the camera driver must be able to perform with any relay-type device. Likewise, the Irelay class defines an interface for all sensor-type devices. It consists of methods for any operations that the camera driver should be able to perform with any sensor-type device. The concrete classes of sensor and relay provide functions that are specific to the concrete hardware type. Factory Method [11] pattern is used to create an instance of a relay and sensor. This design is flexible enough to extend a new relay or sensor device in the near future as both the controller and concrete classes depend on a generic inter-face.

The design uses two factory method interfaces for creating sensor and relay objects. The structure and behavior of these two factory interfaces are similar. Therefore, they can be combined so that one generic factory can be applied to create a relay or sensor object. This is achieved through an Abstract Factory design pattern [11]. We decided to have a separate controller rather than one for each sensor and relay to decouple between the sensor and relay. This is because both sensors and relays have different func-tionality. The updated UML class diagram of the sensor and relay is shown in Figure 16.

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

The updated sensor and relay UML class diagram has one generic abstract factory class to create both relay and sensor. This design is stable and decided as final for realization purposes. Additionally, this design is flexible for code optimization and extension of a new sensor or relay. For code optimization, an abstract class can be introduced between each of the interface and concrete classes if two or more sensors or relays have some common behavior. Similarly, the extendibility depends on the hardware types and versions. If the new sensor or relay hardware is different from the existing ones, then this new sensor or relay should implement its respective common interface. If the new sensor or relay is an upgraded version of an already existing type, then it should inherit from its original hardware type.

5.4.3. Hardware abstraction layer

This layer provides an abstraction to the firmware in the image sensor hardware components. The cam-era driver does not directly access the hardware modules. It uses another software component to access all these hardware components. The hardware modules are the DHP module and the SBD module. The DHP module is equipped with HSSL and DMA hardware. The HSSL is used to communicate with the camera hardware modules (COB, Relay, Sensor), which are described in the communication layer sec-tion above, to send and request frame data. The DMA is used to store the received frame data from the sensor in memory. SBD is used for synchronization with other subsystem software components. There-fore, four classes are designed to manage and access the functionality of these aforementioned hardware modules. The UML class diagram for the hardware abstraction layer is shown in Figure 17.

The HPMCommunication, SBDCommunication, HSSLCommunication, and DMACommunication classes provide abstraction functions for DHP, SBD, HSSL, and DMA hardware, respectively. There are two options,i.e., whether to access the actual hardware or its simulated versions. A generic interface class is introduced to bind these two options dynamically. The four classes depend on this generic in-terface so that these classes do not require to know the details about whether the commands are sent to access the real hardware or simulated one. The access mode of these classes is set during the initializa-tion of the driver by the Initializainitializa-tionAndTerminainitializa-tion class of the applicainitializa-tion layer.

28

Figure 17: UML class diagram for the hardware abstraction layer

The FirmwareSimulation class is responsible for implementing the simulated behavior of the hardware modules. The FirmwareAccess class is used to send the commands to the real hardware modules. It uses the firmware software components interface to access these hardware modules. This design decouples the hardware abstraction implementation from the information about whether we are simulating or ac-cessing the actual hardware.