AlabOS: A Python-based Reconfigurable Workflow Management Framework for Autonomous Laboratories

TL;DR

AlabOS addresses the need for robust workflow management in increasingly complex autonomous laboratories by introducing a Python-based, graph-enabled framework with a central resource manager and sample-position tracking. Its graph-based experiment model, manager–worker architecture, and simulation mode enable dynamic multi-device scheduling, parallel task execution, and safe operation across varied lab workflows. The system includes a web dashboard, JSON/API interfaces, and data management via MongoDB with GridFS backups, supporting end-to-end experiment submission, monitoring, and logging. In practice, AlabOS underpins the A-Lab solid-state synthesis platform, handling thousands of samples and diverse processing steps, while enabling close-loop experimentation and scalability across labs. Overall, AlabOS offers a general, open framework that reduces bespoke workflow coding for autonomous laboratories and accelerates materials discovery.

Abstract

The recent advent of autonomous laboratories, coupled with algorithms for high-throughput screening and active learning, promises to accelerate materials discovery and innovation. As these autonomous systems grow in complexity, the demand for robust and efficient workflow management software becomes increasingly critical. In this paper, we introduce AlabOS, a general-purpose software framework for orchestrating experiments and managing resources, with an emphasis on automated laboratories for materials synthesis and characterization. AlabOS features a reconfigurable experiment workflow model and a resource reservation mechanism, enabling the simultaneous execution of varied workflows composed of modular tasks while eliminating conflicts between tasks. To showcase its capability, we demonstrate the implementation of AlabOS in a prototype autonomous materials laboratory, A-Lab, with around 3,500 samples synthesized over 1.5 years.

Figures (6)

• Figure 1: Schematic representation of lab states managed within the AlabOS system. The lab status is divided into four collections: (a) The sample collection tracks the sample’s position and identifies the task reserving that position; (b) the device collection records the status of the device and the task assigned to it; (c) the task collection records the order of execution for different experimental tasks. The order of tasks is encoded in a graph data structure to ensure sequential execution is performed in the correct order; (d) the experiment collection records a batch of samples and their associated tasks.
• Figure 2: An architecture diagram for AlabOS. (a) Human operators submit experiments, monitor the laboratory state, and manage user requests. (b) The physical laboratory performs these tasks via manager processes. These include (c) the dashboard server that hosts the user interface and APIs for monitoring and controlling the experiment workflows; (d) the experiment manager that transforms high-level requests into specific tasks; (e) the task manager that launches each task and monitors its status; (f) the resource manager that assigns and tracks the status of available lab devices and sample positions; (g) the device manager that directs traffic between task actors and physical lab devices. Outside the manager processes, a logger module (h) logs the runtime information and saves task results into a central database; a user request module (i) requests user interventions and sends user responses back to the requester. In the worker processes, each task is carried out within a task actor (j) that can request resources, send commands to devices, log data, and initiate user requests.
• Figure 3: A code example of the resource request in the task definition. In this example, the heating task initiates three request resources with their contexts highlighted in different colors. The requested resources are assigned by the resource manager when entering Python's "with" context. It will be automatically released when exiting the context.
• Figure 4: The execution time of processing resource requests under different numbers of tasks, devices, and sample positions. The time to process all the resource requests (a) with varied numbers of tasks in a virtual lab with 50 devices and 1000 sample positions (20 sample positions per device), (b) with fixed 200 tasks in a virtual lab with varied number of devices and sample positions (20 sample positions per device). The test is run on a Macbook Pro 2021 with M1 Pro CPU, 32 GB RAM. Each point is run 10 times repeatedly to obtain the error bar. The top and bottom of the error bar represent the 25th and 75th quantile of all the runtime data.
• Figure 5: Images of three pages associated with different tabs in the dashboard. (a) The main tab shows the status of ongoing experiments. Each experiment has a progress bar with different colors, including blue (all tasks are running normally), green (all tasks are completed), and red (at least one task encountered an error). (b) The notification page shows messages from the system and its tasks. The operators can choose from the options provided and take action as instructed for maintenance and error recovery. (c) The device page shows the status of each device. When the operators wish to perform maintenance on a device, they can pause it from this page so that it will no longer be assigned to any tasks.