AI-driven laboratory workflows enable operation in the age of social distancing.

The COVID-19 (Coronavirus disease 2019) global pandemic has upended the normal pace of society at multiple levels-from daily activities in personal and professional lives to the way the sciences operate. Many laboratories have reported shortage in vital supplies, change in standard operating protocols, suspension of operations because of social distancing and stay-at-home guidelines during the pandemic. This global crisis has opened opportunities to leverage internet of things, connectivity, and artificial intelligence (AI) to build a connected laboratory automation platform. However, laboratory operations involve complex, multicomponent systems. It is unrealistic to completely automate the entire diversity of laboratories and processes. Recently, AI technology, particularly, game simulation has made significant strides in modeling and learning complex, multicomponent systems. Here, we present a cloud-based laboratory management and automation platform which combines multilayer information on a simulation-driven inference engine to plan and optimize laboratory operations under various constraints of COVID-19 and risk scenarios. The platform was used to assess the execution of two cell-based assays with distinct parameters in a real-life high-content screening laboratory scenario. The results show that the platform can provide a systematic framework for assessing laboratory operation scenarios under different conditions, quantifying tradeoffs, and determining the performance impact of specific resources or constraints, thereby enabling decision-making in a cost-effective manner. We envisage the laboratory management and automation platform to be further expanded by connecting it with sensors, robotic equipment, and other components of scientific operations to provide an integrated, end-to-end platform for scientific laboratory automation.

Introduction

The COVID-19 global pandemic has upended the normal rhythm of society at multiple levels—from daily activities in personal and professional lives to the way businesses and the sciences operate. The disruption has affected various operations at different levels, from complete “lockdown” to “work from home” to partial or “socially distant” work procedures. The pandemic crisis has posed unprecedented challenges to the operation of scientific research laboratories across the world. Particularly, it has led to shortages in vital supplies, changes in standard operating protocols leading to suspension of operations because of social distancing and stay-at-home guidelines. These changes have led to limiting their operational capabilities causing delays and loss in productivity [1], [2], [3], [4], [5].

While the entire scientific community has acknowledged such social-distancing measures as a critical step to slowing down the pandemic, these measures have come at a cost, leading to a huge “loss of scientific progress” [6], [7], [8]. Thus, the pandemic has led to a growing need for enabling laboratory operations in the “new normal” [1], [2], [3]. Despite this awareness of the challenges and costs of “shelter in place” and social distancing on laboratory research, most responses have focused on identifying remote operational issues and developing re-entry roadmaps for risk and safety compliance checklists, with little to no use of digital technologies for redefining laboratory operations [1,8].

Rapid progress in digital technologies—particularly sensing modalities for the internet-of-things, artificial intelligence (AI), and robotics—provide promising avenues for digital transformation of laboratory operations. Particularly in the area of laboratory automation, the major focus has been on robotics [3], specifically on using robotic arms to automate specific processes [[9], [10], [11]]. Similarly, electronic laboratory notes [12] and cloud-based documentation and sharing platforms [13] have enabled process automation of laboratory functions. Recent developments in augmented or virtual reality, robotic process automation, and conversational interfaces (voice) have opened potential new opportunities for automating laboratory processes [14].

Laboratory operations involve complex, multicomponent systems involving equipment (robotics or devices), reagent supply chains, protocols, human resources, data handling and quality control, high-performance computing, and analytics. It is unrealistic to completely automate the entire diversity of laboratory processes. It would require significant investment in terms of equipment, facility planning and organization, and training of personnel.

With recent developments, particularly in the role of game simulations for training machine learning algorithms, AI technologies have made significant strides in modeling and learning complex, multicomponent systems [15], [16], [17], [18]. Simulation models, which capture various layers and constraints, play a pivotal role prior to the building of actual systems, and they require significant cost and time resources. Game simulation models have been used extensively in AI development; for example, the DeepMind AlphaGo [19] program (from Google DeepMind) combined deep reinforcement learning to defeat the human champion in the ancient game of Go by generating millions of game moves to explore the parameter space of the gameplay and present novel moves. Various simulation techniques (e.g., agent-based simulations and Monte Carlo and discrete event simulations) are incorporated to study the interaction dynamics of individual components in a system, which are represented as “digital twins” or avatars [20] with different parameters. Further, the system can be augmented with real-life data from various activity monitors, equipment sensors, cameras, and robotic instruments to capture multiple layers of granularity.

Thus, a platform which connects diverse laboratory processes and data sensing and monitoring modalities while leveraging the power of simulation-driven learning can provide the foundation for laboratory automation by flexibly combining human and machine intelligence to optimize performance and productivity under various constraints and risk scenarios as exemplified by the COVID-19 global pandemic.

This paper outlines a laboratory management and automation platform customized and developed by SBX Corporation, based on the Garuda platform [21]. It combines multilayer information (physical layout, operational information, data, and computational information) on a simulation-driven learning engine to plan and optimize laboratory operations under various constraints and risk scenarios. Specifically, the platform provides: (a) Integration of multidimensional information layers for laboratory management, (b) Connectivity of the different information layers on a single, secured, and privacy-preserving private cloud-based dashboard and (c) Simulation-driven learning engine, which combines game simulation dynamics with learning and optimization techniques for hypothetical scenario generation (HSG) of laboratory operations under different working conditions, constraints, parameters, and protocols for assessment, planning, and optimization of workflows.

The technology platform components are elucidated in the Methods section; the Results section outlines specific laboratory workflows and insights on their real-life operational optimization under various constraints, particularly under COVID-19 safety protocols. The Future Perspectives section highlights the possibilities of expanding and augmenting the platform to provide an end-to-end laboratory management and automation framework for operating in the age of social distancing and beyond.

Methods

This section outlines the technology components of the laboratory management and automation platform, particularly focusing on the design and development of the core modules and their connectivity to facilitate seamless flow of information towards enabling laboratory management and automation. The platform design focuses on multilayer operational flow: (a) Facility layer: The physical layout of the laboratory facility, including entry and exits, windows and exhausts, electrical and plumbing layouts, as well as specific constraints based on building codes and other requirements; (b) Equipment layer: Based on the specific facility layout of a laboratory room, the position of various laboratory equipment, furniture, and data and computation servers are captured in this layer; (c) Operational layer: This layer encapsulates the operational flow of a laboratory experiment protocol, particularly the movement of materials and people and use of equipment, depending on the specific standard operating protocol (SOP) and d) Information layer: This layer captures the flow of information (data) related to the SOPs and computational workflows that drive downstream analysis and interpretation of experimental results.

It is pertinent to note that the dynamic nature of laboratory operations requires such a platform to allow flexibility in configuration of the different layers. For example, a change in building codes for safety might necessitate a change in the physical layout; or new equipment (sensors or robotic instruments) may necessitate a change in equipment layout or operational layers. Thus, from a “design thinking” perspective, the platform mandates a plug-and-play modular architecture which allows the development and configuration of individual connected components.

Based on the Garuda platform, a connectivity and automation technology, the laboratory management and automation platform were developed as a customized solution which provides an automation dashboard with different modules (called gadgets) for the different layers, as shown in Fig.1 (details in Fig. S1). The Garuda platform provides the underlying connectivity between the gadgets and allows configuration, customization, and development of new gadgets on the automation dashboard.

Fig. 1

Automation dashboard: A dashboard panel, which provides a single launch panel for.

Layout manager (LM)

The LM encapsulates the facility and equipment layers and provides the ability to capture the floor plan and layout of the laboratory room, allowing users to design, modify, and view the room configuration. The manager allows users to create a new laboratory floor plan layout with specific facility materials (furniture and equipment) and their configurations, including dimensions, orientation, and layout (Fig. S2a). The catalog panel allows configuration of facility inventory, which can be used to select specific materials from the inventory to be configured for a specific laboratory. The design panel allows both 2D and 3D view of the layout as well as mapping of a layout to a specific laboratory to represent a specific laboratory (Fig. S2a, 2b, 2c). The LM module is connected to the other modules on the automation dashboard and serve as the baseline for the operational and information layers. The LM provides a flexible option for changing layouts to address needs arising from different operational and business conditions. It can also be used to create multiple layout configurations for a laboratory by changing the physical location of specific equipment or putting constraints on movement of people (social distancing). These layout configurations can be associated with a specific workflow and simulated on the platform to plan the optimal layout configuration for different operating conditions.

Workflow manager (WM)

The WM captures the operational information associated with the SOP for an experiment in a laboratory. Specifically, the WM is used to encode the details of an experimental protocol—the tasks, subtasks, detailed description of the tasks, associated devices (equipment as outlined in the LM), time of execution, and role of personnel associated with the workflow (Fig. S2d). The workflow forms the baseline of an experimental protocol associated with a laboratory. A laboratory can have multiple workflows assigned, depending on the experiment focus area, personnel, or devices used and can be duplicated or merged to create complex processes. Further, task details can be duplicated and reused across different workflows or assigned to different laboratory layouts (Fig. S2f).

Thus, the operational activities of a laboratory are represented in the WM and can be analyzed using the workflow analysis option. The WM performs static analysis of a selected workflow to summarize various key parameters in the workflow (Fig. S2d, 2e). For example, for the workflow in Fig. S2d, 2g shows the machine unit utilization matrix. The matrix depicts which equipment are used frequently (plate washer and workbench table [IDs 10,564 and 111]) and which are used for long periods of time (CO2 incubators [IDs 557 and 11,478]) and enables inventory planning, maintenance, and scheduling of devices in the laboratory. The WM computes the baseline statistics of a given workflow as shown in Fig. S2f, which shows the distribution of steps (subtasks) and devices for the different tasks in a workflow (in this case, for the same baseline high-content screening [HCS] process) as well as the time distribution for the tasks.

It is important to note that the workflow analysis in WM is “static” i.e., the distributions are computed on the baseline workflow and does not consider the dynamics of changing the task dependencies, number of devices, personnel, or other constraints of operation.

Simulation and results manager (SM, RM)

The SM and RM together form the core of the platform for HSG based on a specific laboratory layout and associated workflows. The SM allows simulation of a laboratory operation scenario under various operating conditions, constraints, and parameters. An HSG (Fig. S3a) defines a combination of the laboratory layout, workflow, and operating conditions (parameters) for a simulation run in two key dimensions:

Workflow parameters: Defines the specific workflow and laboratory layout for a simulation, together with the task dependencies in the specific workflow. The dependencies of the task establish the sequence of actions for the tasks and subtasks for a given workflow in a particular HSG.

Simulation parameters: The parameter control panel (Fig. S3c) outlines the key operating conditions and constraints for executing the HSG on the simulation panel. The parameters for control include: (a) Personnel: Number of personnel assigned to the workflow for a particular HSG; (b) Safety parameters: Social distancing constraint and maximum number of personnel allowed during the HSG; (c) Optimization (AI) options: These parameters specify the options to the simulation engine for enabling optimization of the HSG execution on:

The factors include, Parallelization using AI: automatic parallelization of tasks based on dependency during the HSG execution; Use alternative devices: enable the HSG to use alternative devices for a given task or subtask where applicable for expediting execution; Normalize factor: normalize the time of execution for a task or subtask to expedite the simulation run time.

There are more advanced options which allow further granular control to the optimization engine on the HSG, including, Speed of personnel: Optimize the speed of personnel; All tasks are independent: allows hyper-parallelization of tasks, particularly for automated processes; Use same personnel as much as possible: allow control of personnel reuse to optimize resource utilization; give priority to longer duration: Allow the optimization engine to prioritize tasks based on their time distribution.

In summary, the HSG represented in Fig. S3a (called NEW_HCS Baseline 3p2m) captures a scenario of a workflow named “New Baseline HCS WF v2.2″, with three technicians operating at a social distance of 2 m and maximum personnel of four, enabling parallelization with AI, the use of alternative devices, a normalization factor of 1.0 (operating at base timescale), an average speed of 5 km per hour, and optimization for personnel reuse as much as possible.

The combination of various workflow and simulation parameters allows users to create a large spectrum of HSGs to explore the impact of these conditions on laboratory operations in terms of cost and productivity of experiments. The HSG landscape allows users to create different "what if" conditions for assessing, planning, and scheduling experiments, analyzing various tradeoffs (e.g., increasing the number of resources against safety protocol impact), and automating laboratory processes.

While the simulation panel allows real-time execution and tracking of HSG simulations through the simulation controls and results-tracking interfaces (Fig. S3c), it is infeasible to run various HSGs in real-time mode. The RM provides offline access to the results of different HSGs. The results explorer panel allows users to explore different HSGs that have been simulated and saved on the SM (Fig. S3c). The results visualization panel displays the simulation results for the specific HSG—simulation and workflow parameters, simulation runtime statistics, and graphical charts of resource (device) utilization for the HSG. Further, to facilitate comparison of two different HSGs, the RM provides a comparison visualization panel (Fig. S3d), which allows comparative analysis of the HSGs and shows a comparison of simulation statistics and device utilization rates between two HSGs.

The LM, WM, SM, and RM together form the interconnected core components of the laboratory management and automation platform, which provides the framework for encoding laboratory room and equipment layouts, representing workflow tasks and subtasks, generating what-if scenarios (HSGs) under different operating conditions, and comparing results to gain operational insights for assessment and planning. In the next section, we present the technical details of the simulation-driven optimization engine that powers the platform.

Optimization engine

Computational modeling and simulation form the bedrock of the study of complex systems, from engineered systems like racing cars and space rockets to factory and supply chain operations research to the study of complex biological pathways [[18], [19], [20],22]. As mentioned earlier, recent advancements in AI and machine learning have been largely facilitated by the use of game simulation dynamics for exploring the combinatorial parameter search space for augmenting deep-learning models (e.g. AlphaGo [19] employed deep reinforcement learning strategies for designing the gameplay of Go). Further, simulation plays a major role in robotics, where systems like Amazon RoboMaker [23] and Unity Robotics simulation [24] provide a framework for the design and development of robotic systems through modeling and simulation.

As mentioned earlier, the platform presented in this work builds a novel simulation-driven optimization engine, which uses the LM and WM to define and simulate different HSGs under various operating conditions. In this section, we delve into the core components of the simulation-driven optimization engine (Fig. S4).

The engine consists of two main components, the details of which are explained below.

The first is the Simulation processing engine, composed of the controller, configurator, and reporter modules, with the following functionalities: (a) Simulation execution controller: The simulation engine gets instructions to play, pause, resume or abort a simulation from the user interface; (b) Simulation property configurator: The simulation engine gets inputs regarding workflow parameters and simulation parameters from the user interface; (c) Simulation result logs: The simulation results are shared to user interface as execution event logs and (d) Simulation event reporter: The simulation life cycle and error reporting are captured and communicated.

The second is the Simulation which interacts with the processing engine controller and configuration to execute the sequence of events under various constraints. The components of the engine include: (a) SM: Various core functionalities are managed, such as the state, simulation clock, execution, and error detection of the simulation; (b) Execution sequence generator: A task execution sequence is generated based on the workflow parameters; (c) Layout and workflow loader: Responsible for generating the task sequence and loading the layout and workflow to the simulation engine; (d) Job scheduler: Responsible for assigning and managing each defined task; (e) Resource manager: Responsible for assigning and managing each device for defined tasks and (f)Player manager: Responsible for assigning and managing each personnel for defined tasks.

The complete flow of the simulation command-control is outlined in Fig. S5, including initiation of the simulation servers, connection to the LM and WM, loading of simulation parameters in the simulation engine, and creation of the task queue. The simulation and resource (player) engines are synchronized, with the simulation engine executing the sequence of tasks from the task queue and the player engine controlling the interaction dynamics of the resources and constraints and their states in the system.

The process for task queue creation (green highlight in Fig. S5) in the command-control flow employs an optimization module for parallelization of tasks in the workflow. Specifically, the module employs a graph-based topological sort algorithm to generate a directed acyclic graph (DAG) associated with a given workflow—first, generation of a task graph, followed by identification of parallel tasks and subtasks (subgraph detection) and, finally, merging of tasks to generate the DAG through a breadth-first search routine on the topological sort results of the graph nodes. This optimization module is executed in the command-control flow when the "parallelize using AI" option is selected in the parameters panel of the SM.

The engine is built on and customized on Garuda libraries for supporting various simulation and optimization algorithms and is implemented on the Unity Framework [24] for game engine simulations. As outlined in this section, the simulation-driven optimization engine is built in a modular and extensible manner on the Garuda platform to support addition of modules for learning (e.g., scheduling, spatial intelligence, sequence generation, and optimal route selection), real-life (sensor) data integration, etc. (see Fig. S6).

Scalable platform deployment

The laboratory management and automation platform presented in this work is a compute-intensive process, particularly the simulation-driven optimization engine, which requires massive computation cycles for exploring the combinatorial space of different workflow and simulation parameters associated with an HSG. Further, different what-if scenarios may be executed for different workflow combinations, leading to multiple HSGs being generated for a given workflow. Thus, it is imperative to engineer the platform development and deployment for scale. In this section, we highlight some of the key system engineering design, technology architecture, and deployment frameworks for the platform.

As detailed in the Methods section, the system was developed on the Garuda platform to leverage the modularity of components, connectivity, and automation features on a cloud-based architecture. Each of the components (gadgets) of the LM, WM, SM, and RM were developed as individual services but by using the same technology stack (the front-end and back-end stack technologies are described in Fig. S7a, b) to leverage reusability. The individual services were connected through the Garuda platform on a central dashboard (the automation dashboard), (Supplementary Fig. S8a). A central database architecture based on a document-oriented database (MongoDB) was designed to reduce the overhead of database query communication across the services (schema provided in Supplementary Fig. S8a). The Unity-based simulation engine was configured on client-side (WebGL) execution to allow browser-based execution of simulation runs.

However, the cloud-based approach together with the individual service-oriented architecture also enables deployment of the system on distributed multi-server systems (Fig. S8b). Its support for distributed deployment is critical for scaling the simulation engine to leverage graphical processing unit (GPU) systems and other dedicated computation configurations for future development of machine learning and AI modules on the platform.

The platform is delivered as a suite of Docker containers (Fig. S7a) deployed on Linux servers by Ansible playbooks and roles covering all stages of the process, from basic configuration of the server to deployment and customization of the application modules. This approach is easily parametrizable, allowing reproduceable deployment on premise or on public, private, or hybrid cloud. Access details on the specific software tools are provided in Fig. S7c.

In summary, the platform design, development, and deployment architectural choices were governed by the goals of scalability, modularity, extensibility, and Continuous Integration, Continuous Deployment (CICD) to enable support for large-scale simulation-driven optimization of laboratory operation management and automation. A concept video demonstrating some key features of the platform is available as supplementary material.

Results

The execution of preclinical in vitro studies is a complex procedure which requires integration of multiple fundamental highly interconnected steps including: (1) study ideation, (2) laboratory activity preparation, (3) laboratory activity execution, and (4) data analysis and reporting. While normal operating circumstances allow coordination and flow of information through established procedures, operating under the COVID-19 pandemic-imposed restrictions requires a significant shift in workstyle, particularly with the constraints of working from home or social distancing in laboratories (Fig. 2 ).

Fig. 2

Laboratory operations in the age of the COVID-19 pandemic. The figure shows the standard operations under normal conditions with access to the laboratory and office space and how the change in operations under work-from-home and remote communication restrictions.

Most, if not all, office-based operations can be easily adapted to such restrictions thanks to the implementation of virtual meetings, which allow effective interactions among required stakeholders. Moreover, the use of platforms which ease document sharing and coediting provides adequate support, allowing multiple contributors to operate simultaneously.

Laboratory experiments are complex processes that require coordination and information exchange across multiple dimensions of devices (or equipment), experimental materials, personnel, data, and computational analysis. Unlike office-based operations, laboratory experiments require physical presence at work. Therefore, some of the key aspects of laboratory management and operations in the “new normal” include granular scheduling of tasks to maintain social-distancing protocols and allow maximum utilization of devices, remote access to data for processing and analysis, and identifying bottlenecks in processes and protocols.

In this section, we present in detail the results of application of the simulation-driven laboratory management and automation platform in assessing and planning experimental workflows under real-life circumstances during the COVID-19 period. The results focus on experimental workflows performed in an HCS laboratory. In particular, we analyzed the execution of two cell-based assays that are characterized by distinct features, including different readouts, incubation times, and complexity (Fig. 3 a):

Fig. 3

Key workflow combinations and assessment conditions for analysis with the laboratory management and automation platform. The assessment is based on different assays with different operating protocols. The assessment focuses on the laboratory performance (impact on the execution time of different workflows) under constraints of resources, devices (equipment), and social distancing.(For interpretation of the references to color in this figure, the reader is referred to the web version of this article.)

Assay #1: Fluorescence imaging-based; 4- and 24 h incubation; multiple steps before readout

Assay #2: Luminescence-based; 6-h incubation (1 h preincubation); single step before readout

Operating in the "new normal"

The COVID-19 pandemic presents potential challenges to normal study lifecycle management and experimental execution, with the need for remote or work-from-home restrictions and communication being restricted to online conferences rather than in-person meetings. Fig. 2 shows the changes in laboratory operations in the COVID-19 period relative to the normal pre-COVID-19 period. As can be seen from the illustration, these changes require planning and scheduling of laboratory operations to prioritize safety (ensuring social distancing and minimizing contact between technicians) while optimizing laboratory performance (in terms of the execution time of assays and multiplexing of multiple assays).

As part of planning and scheduling experiments in the “new normal,” the simulation-driven optimization platform presented in this work was used to assess the different workflow combinations under different operating conditions (with and without social-distancing restrictions). Fig. 3b shows the key workflows and assessment criteria. Specifically, four workflows in increasing complexity of operating protocols were tested on the platform: (a) Assay #1 1x: Baseline assay #1 workflow (color-coded in yellow); (b) Assay #1 3x: Three assays of the Assay #1 workflow (for triplicate measurement; color-coded in green); (c) Assay #1 3x + 1X Assay #2: Combination of three Assay #1 workflows with an additional Assay #2 workflow (color-coded in orange) and (d) Assay #1 3x + 3X Assay #2: Multiplexing of three Assay #1 workflows with three Assay #2 workflows (color-coded in blue).

The assessment criteria, as shown in Fig. 3b, focused on laboratory performance, specifically the impact of the platform on the execution times of the different workflows during a weekly time window under the contracts of personnel resources, social distancing, and instrument utilization. The next section highlights the results of the assessment based on the platform along with the insights obtained to enable decision-making.

Laboratory performance under different operating conditions

As shown in the Methods section, the workflow combinations for assessment were encoded on the platform through the WM gadget. Based on the static analysis of the workflows along with the specific assessment criteria elucidated previously, different HSGs were simulated on the SM gadget to computationally explore the search space of parameter combinations for optimal assessment. The key set of HSGs for the different workflows along with the set of simulation and workflow parameters are tabulated in Supplementary Table 1. The rows (representing the HSG) are color-coded according to the workflows.

The baseline workflow simulations (called Assay #1 1x, 1–5 in Supplementary Table 1) serve as the benchmark for establishing the ability of the platform to capture the normal working condition of the assay (approximately 2 days). As the baseline workflow has more device utilization than personnel utilization, increasing the number of personnel or the impact of social distance does not lead to a significant change in performance (execution time).

For three assays of the HCS workflow in a 1-week time window (called Assay #1 3x Assay #1 Weekly, rows 6–10 in Supplementary Table 1), the platform leverages the parallelization within the different task or subtasks of the workflow (intra-SOP parallelization) to enable performance gain (the workflow is executed in approximately 4 days and does not require three times the baseline for Assay #1 1x). The impact of personnel or social distancing is limited, as seen in the HCS 1x case, except in the case of three personnel with social-distancing constraints, where the execution time is increased (no. 10 in Table 1 a). Thus, for the Assay #1 3x workflow, operating with two people under social-distancing constraints allows optimal performance (no. 8 in Supplementary Table 1).

Table 1

Summary of results for specific combinations of workflows for Assay #1 and Assay #2. Each cell of the matrix has two details: (1) the number above refers to the serial number of the HSG in Table 1a; (2) the bottom number refers to the execution time of the experimental protocol under the operating conditions.

Number of persons	Social Distance in Meters	Assay# 1X(Daily)	Assay#1 3X(Weekly)	Assay#1 3X + Assay #2 1X	Assay#1 3X + Assay#2 3X
1	0	1	6	11	21
		2d 5 h 46 m 37s	4d 5 h 32 m 56s	4d 5 h 36 m 7s	4d 15 h 27 m 49s
2	0	2	7	12	22
		2d 5 h 47 m 12s	4d 5 h 35 m 43s	4d 5 h 52 m 25s	4d 5 h 41 m 35s
2	2	3	8	13	23
		2d 5 h 51 m 18s	4d 5 h 38 m 5s	4d 6 h 22 m 50s	4d 17 h 10 m 3s
3	0	4	9	14	24
		2d 5 h 47 m 19s	4d 5 h 41 m 44s	4d 5 h 41 m 25s	4d 5 h 39 m 13s
3	2	5	10	15	25
		2d 5 h 46 m 55s	4d 9 h 17 m 2s	4d 5 h 39 m 51s	5d 20 h 22 m 58s

When the protocol is updated to include an additional Assay #2 assay with the 3x Assay #1 (called Assay #1 3x + Assay #2 1x Assay #1 Weekly and 1x RGA, rows 11–15 in Supplementary Table 1), the platform can achieve parallelization efficiency between the two workflows. In fact, as shown in row no. 13 in Supplementary Table 1, the execution time is only increased by 1 h for the Assay #1 3x + 1x Assay #2 workflow relative to the Assay #1 3x assay workflow (from approximately 4 days 5 h to 4 days 6 h). To delve deeper into these results, the timing sequence of events generated by the simulation run for these two cases (nos. 8 and 13 in Supplementary Table 1) are shown in Fig. 4 . The Manhattan plots (refer to Fig. 4 legend for details) of the timing sequence show that the system attains efficiency by scheduling “bursts” of simultaneous activities (taller bars) between periods of low parallelization, where mainly device-only tasks are executed. However, the sequence distribution shows that the platform distributes the tasks and subtasks of the combination workflow (Assay #1 3x + Assay #2 1x) across the entire week (orange boxes in the two workflows), thereby leveraging parallelization across the workflows and increasing performance efficiency.

Fig. 4

Timing sequence analysis of the of two workflows (Assay #1 3X and Assay #1 3X + Assay #2) from the output of the simulation manager. The timing sequence is represented as a Manhattan plot, with the x-axis representing the time (in a 24 h cycle from 8:00 am to 7:00 am, color-coded for 5 days of the week) and the y-axis showing the number of subtasks in the workflow that are executed in parallel at a given time point. Thus, tall bars at any time point represent a greater degree of parallelization of the workflow (greater number of simultaneous operations).

The final workflow combination, which mandates the multiplexing of three Assay #1 and three Assay #2 workflows (called Assay #1 3x + 3X Assay #2 Assay #1 Weekly + 3X Assay #2) and is shown in row no. 16–25 in Supplementary Table 1. The role of optimal scheduling of the workflows is evident in this complex 3x + 3x case, as the performance is severely impacted in cases where parallelization of the workflows (both intra- and inter-SOP) is not optimized, irrespective of the number of personnel or social-distancing restrictions, as seen in Cases no. 16–19 in Supplementary Table 1. In fact, increasing the number of personnel without optimizing the workflows leads to severe performance penalties, as shown in case no. 19 in Supplementary Table 1. Thus, the platform optimizes the workflow by parallelizing the tasks or subtasks of the Assay #1 3x and Assay #2 3x workflows to increase performance (decrease the time of execution), as seen in Cases 19–24 in Supplementary Table 1. Specifically, the impact of personnel and social distancing is elucidated in Cases no. 22 and 23 in Supplementary Table 1, as applying the constraint of social distancing on two personnel forces the system to distribute the tasks, thereby increasing the time requirement, as shown in the sequence timing diagrams in Fig.4 (top and middle panel). Increasing the number of personnel gives back the performance gain (Fig.4 bottom panel), but not under social-distancing constraints (Case no. 25 in Supplementary Table 1). Thus, for multiplexed workflows, optimization is critical prior to assignment of personnel and social-distancing constraints to achieve performance within a 5-day period (weekly time window).

Summary

Table 1 summarizes the key results for the combination of workflows under the constraints of personnel and social distancing. Based on the simulation of the HSGs for the workflows, several key insights are obtained from the platform. At single-experiment level, we observed no substantial improvement in execution time when the number of lab personnel was increased. Upon establishing social-distancing limitations, we only observed a limited impact on execution time. With multiple experiments (3X per week) we observed that three independent experiments can be performed within a week with no substantial improvement in execution time when the number of lab personnel was increased. Again, only a limited impact on execution time was observed upon establishing social-distancing limitations. Lastly, one RGA (Reporter Gene Assay) experiment can be executed jointly with the 3x Assay #1 workflow and three RGA experiments can be executed jointly with the 3x Assay #1 workflow, but they require more than 5 days without optimization of the workflows. Once the RGA assays are parallelized with the Assay #1 workflow, it is possible to execute the combination within a 1-week window. There are tradeoffs in execution time and social distancing with respect to the number of personnel.

It is pertinent to note that all our simulation results are based on the use of alternative and nonblocking devices for removing device bottlenecks. The results show the ability of the platform to provide a systematic framework for assessing different laboratory operation scenarios under different conditions and quantifying the tradeoffs and performance impact of specific resources or constraints, thereby enabling decision-making in a cost-effective manner. While the results elucidated in this section are focused on the specific requirements for the HCS laboratory, the platform can be flexibly configured to assess different laboratory settings and conditions.

Discussions

This laboratory management and automation platform provides a foundation for enabling the planning, operation, and analysis of complex laboratory processes. As shown in this study, the various modules within the platform address specific components of the operational processes, from laboratory layout and inventory planning to workflow and protocol management to simulation of different conditions (HSGs) and interpretation of the results to enable decision-making. The current platform and its application in the use cases outlined in the Results section showcase the potential of the system to enable quantified decision-making for operational processes rather than making decisions only based on prior experience, intuition, or trial-and-error methods, which are expensive in terms of cost and risks. There are various dimensions in which the laboratory management and automation platform is limited in its application and can be enhanced and expanded, both in the context of laboratory operations and the broader areas of scientific operations and office work [25].

Specifically, one dimension for the platform is around the simulation engine (SM module), which does not capture the impact of equipment usage, inventory, layout, and position through a spatial intelligence component. This dimension can be enhanced with the addition of sensing modules (motion, temperature, pressure, or vibration sensors) that can capture real-time data on actual operations and can be used for simulation-driven inference [15,22] and optimization, which is currently lacking in the platform. Further, the learning modules in the simulation engine are currently limited in their scope and can be developed to support different classes of learning algorithms—specifically, reinforcement learning (RL) modules [17], [18], [19]. While the current platform does not incorporate real-time data, addition of RL modules can learn and search for optimal solutions in real-time from different conditions (for example, find rescue-mode operations in case of a sudden change in operations involving equipment malfunction or accidental reagent spill, which can impact interdependent workflows). Combination of simulation-driven optimization and an RL module for adaptive learning in real-time based on sensor data can help build a robust platform for laboratory management.

Another dimension of laboratory automation is the increasing use of robots and robotic equipment [3,16,25]. A synergistic combination of human–machine collaboration across a spectrum of operations provides a realistic use case for robotics, particularly in the post-pandemic era [25]. The current platform does not support the integration of robotics in the system. The platform outlined in this work, however, provides a modular architecture that can support the integration of robotic systems into the workflow, allowing users to first “simulate” their dynamics prior to physical deployment in efficient and cost-effective configurations.

While the current work encapsulates the core modules for layout, workflow, simulation, and results, we envisage that the laboratory management and automation platform will further connect with other components of scientific operations, including quality management, inventory and logistics management, facilities management, training and data management, and financial management systems, to provide an integrated, end-to-end platform for scientific laboratory automation in the times of COVID and beyond.

Funding

Philip Morris International is the sole source of funding and sponsor of this research. The lab automation platform was customized and developed based on a proprietary platform software developed by SBX Corporation, Japan.

Declaration of Competing Interest

Diego Marescotti, Filipe Bonjour, Luc Graber, Florian Calvino-Martin, and Julia Hoeng are employees of Philip Morris International or had worked for Philip Morris International under contractual agreements. Chandrasekaran Narayanamoorthy, Ken Kuwae, and Samik Ghosh (SBX Corporation, Japan) were part of the team responsible for customizing and developing the platform based on a proprietary software licensed by SBX Corporation, Japan.