Regarding the tasks, GLAS employs a REpresentational State Transfer REST-API 42 to receive new tasks with optional arguments, thereby enabling for the addition of specific information to be utilized during the execution. The submission of new tasks is accomplished via the POST method at the following URL: The JSON body must adhere to the following structure: In GLAS, a task is a self-managed entity that runs as an isolated thread. The task is responsible for validating node execution and handling errors without interrupting the execution of the scheduler. This behavior ensures that access and control over the scheduler is maintained, allowing different clients to retrieve system health diagnostics to perform maintenance if necessary. At the node level, fault management essentially consists of reporting the status of the associated equipment after a BM has been executed. Errors are defined within the BM, are specific to each device and can have different forms (string, code...). They are converted to an integer in the node. A successful BM returns a 0 and any failure corresponds to a non 0. At the scheduler level, the error management must control the execution of the tasks according to the status returned by the nodes defined in the workflows. If a BM returns an error to the scheduler through a node, the task is suspended and the node is set to a "global" error state, prohibiting its use by any other potential task. This is necessary to ensure predictable results when running a task, and allows the error to be manually resolved and the task to be resumed via the PATCH route, where the uuid is the ID of the task to be resumed. It is also possible to manually pause a task via the PATCH route. A MySQL database is integrated into GLAS inside a Docker container and stores all runtime information about the program (including error states, messages, timestamps, and more). It contains tables for nodes, tasks, workflows, and their corresponding properties, states, and logs. Finally, a web client is available to help laboratories visualize what is happening in GLAS. The web client presents a page that displays all tasks, including information such as the previous, current, and future node to be executed. To facilitate the collection of execution times and enable interested laboratories to perform execution time optimization, a task timing tracker have been integrated into the GLAS web interface as well as a highly detailed, in-terminal logging system. In addition, the GLAS Github repository can be forked (a safe cloning strategy) to extend any laboratory GLAS based architecture functionalities and add custom views to its web interface.