Introduction

Introduction#

The Developers section is for those who want to extend the framework by building new EquipmentAdapters or customising the modules within them.

Adapter Architecture#

The system’s design follows a modular, reusable structure, where only the EquipmentAdapter comprises modules and an interpreter. The modules are used to compose the EquipmentAdapter. This modular design allows developers to create EquipmentAdapters by nesting and connecting existing modules. Below is a brief description of all of the components of an adapter.

  • EquipmentAdapter is the central component that contains all other modules and manages the interaction between processes, events, and outputs for a specific piece of equipment.

  • ProcessModules manage different processes within the equipment. These processes may include start, measurement, and stop phases.

  • PhaseModules handle distinct phases within a process and ensure the correct sequence of actions is followed. They may trigger measurements, control actions, or data output during the running of a process.

  • EventWatcherModules detect specific events from equipment (e.g., file changes or API events) and trigger the corresponding phase or process actions.

  • MeasurementModules transform raw equipment data into a standardised format using predefined terms and units.

  • OutputModules transmit the transformed data to external systems (e.g., MQTT, databases).

As seen in Figure 1, these components all come together to identify events, take data from the equipment and route them to the correct place via the ProcessAdapter and PhaseAdapter based on the type of event (start, stop, measurement, etc).

Figure 1: Data Flow
This figure illustrates the high-level input/output data flow for EquipmentAdapters.

Data Flow

Adapter Composition and Class Hierarchy#

The EquipmentAdapter uses several modules (ProcessModules, PhaseModules, InputModules, OutputModules, and MeasurementModules) to handle different functionalities. The EquipmentAdapter itself is the primary container that manages how these modules interact.

Figure 2: Structure
This figure shows how different modules are composed to form an EquipmentAdapter.

Structure

Initialisation Process#

When the EquipmentAdapter starts, it initialises its modules (such as process and phase) and sets up the required input/output mechanisms. Initialisation typically involves linking the modules to specific equipment, setting up event watchers, and preparing for data collection or control actions.

Figure 3: Initialisation
This figure illustrates how the modules are initialised during the setup of an EquipmentAdapter.

Initialisation Process

Starting and Running EquipmentAdapters#

When an EquipmentAdapter starts, it begins monitoring for events, processing data, and passing it through the necessary modules, such as transformation or output. This involves using EventWatcherModules to monitor changes (e.g., file updates or API responses), transforming measurements (if required), and sending the final data output to a defined destination.

Figure 4: Start Process
This figure shows the actions that take place when an EquipmentAdapter starts running.

Start Process

Handling Events#

Once the system is running, EventWatcherModules detects events, which trigger actions defined in the ProcessModules and PhaseModules. Each event is processed, and the associated data is transformed (if necessary) and outputted. The sequence of event detection, data transformation, and output is central to the framework’s operation. Most adapters will likely inherit from one of two existing adapters.

  • DiscreteExperimentAdapter - for equipment that performs discrete experiments (measurements only taken during explicit experiments).

  • ContinuousExperimentAdapter - for equipment that continuously takes measurements without a concept of discrete experiments. Some adapter templates have been developed to develop new adapters and can be accessed here. Furthermore, the routing system, i.e. how events are mapped to topics/actions and then to specific outputs, is a defined and extensible system, which is explained further here

Figure 5: Event Handling
This figure details the flow of actions when an event occurs in the system.

Event Handling

Contents