As previously stated, the GLAS architecture is not specific to a particular Main Laboratory Scheduler type. In contrast, the latter constitutes a discrete layer that can be tailored to align with the particular requirements of any given laboratory. One of the key advantages of the GLAS architecture is its ability to facilitate the parallelization of tasks within a given sub-scheduler, which is associated with a specific set of equipment, as well as between different sub-schedulers. The nodes are executed in a First-In, First-Out (FIFO) at the task level, with nodes being immediately processed in the order in which they become available. In certain cases, contingent on the architectural design (multithreaded, as exemplified in the OmiFire Use Case 2) and the associated hardware accessibility, multiple instances of a node may be operational concurrently. For example, the fleet manager node in the Robot Sub-Scheduler (Use Case 1) may be one such instance, as it comprises multiple sub-instruments (mobile robots), and is therefore immediately available as soon as one of them is available. The number of parallel tasks that can be controlled is constrained only by the computing power of the laboratory architecture and the availability of the requested workflow. Consequently, even in the event of the utilization of a basic FIFO-based Main Lab Scheduler, GLAS enables the attainment of a substantial degree of operation parallelization. This approach may be conceptualized as a graph-based methodology for task scheduling. (Ref.) An experimental example of task execution time is provided in Experimental Use Case 1 below. Further study will present more detailed results regarding parallelization strategies in the context of laboratory automation.