Five-finger engine type scientific research execution system and control method for automated laboratory

Abstract

The present application belongs to the technical field of artificial intelligence, and is a five-finger engine type scientific research execution system and control method for an automated laboratory. It includes a hardware layer, a communication layer and a service layer. Through the five-finger engine micro-service architecture, DAG parallel scheduling, theorem verification hard linkage, soft and hard dual protection, multi-source constraint cost optimization collaborative innovation, significant technical progress is achieved in parallel efficiency, execution safety, economy and reproducibility.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology and is a five-finger engine-style scientific research execution system and control method for automated laboratories. Specifically, it involves a five-finger engine architecture that intelligently decouples scientific research operations into composable microservices, and its DAG parallel scheduling and theorem verification gating control method under multiple constraints such as budget, energy consumption, latency, wear and tear, and security. It is applicable to scenarios such as self-driven laboratories, materials / chemistry / physics experimental platforms, and high-throughput experimental screening. Background Technology

[0002] With the development of artificial intelligence and automation control technologies, multi-tool collaboration and automated scheduling solutions have emerged in fields such as general industrial control, intelligent vehicles, and remote sensing processing. Key representative technologies include: 1. MCP agent multi-tool collaborative link technology The Sanya Research Institute of Hainan University disclosed a general multi-tool collaboration system in its application CN202511257075.2, entitled "A Multi-Tool Collaboration Link Design and Intelligent Workflow Implementation Method for MCP Intelligent Agents". This system constructs a tool knowledge graph, builds a workflow execution graph based on the HEFT algorithm, adopts a dual-channel mechanism of event flow and shared context, and introduces state-driven and resilient fault-tolerance mechanisms to ensure stable node execution. Its tool types cover general software / hardware components such as RPA script executors, OCR recognition modules, and API callers, making it suitable for industrial scenarios such as intelligent manufacturing production lines.

[0003] 2. SOA Intelligent Vehicle Software Architecture Technology The Beijing Institute of Mechanical Equipment proposed a service-oriented architecture for intelligent vehicles in its application CN202411761210.2, titled "A Software Architecture and Software Platform for Intelligent Vehicles Based on SOA". This architecture supports plug-and-play components, XML / JSON service descriptions, BPMN 2.0 business process orchestration, and OTA updates, fundamentally addressing the issues of high cost of automotive-grade AUTOSAR tools and tight coupling between equipment and algorithms.

[0004] 3. On-orbit 3D modeling automation technology Shanghai Taiyi Micro-Aerospace Technology Co., Ltd. disclosed a remote sensing data processing system in application number CN202511525133.5, entitled "An On-Orbit 3D Modeling Method and System". This system achieves automated 3D modeling of SAR data, visible light images, etc., through a hybrid retrieval of a mission template library, MCP call chain construction, and a dynamic feedback update mechanism, aiming to reduce satellite-to-ground communication bandwidth and processing latency.

[0005] Despite the progress made by the aforementioned technologies in their respective fields, the following fundamental shortcomings still exist when applied to automated laboratory research execution scenarios: First, there is a lack of design specific to scientific research scenarios. Existing technologies are all geared towards general industrial control or specific fields (vehicles, remote sensing), and their toolchains are general software components or remote sensing processing modules, which are not adapted to the special needs of scientific research laboratories. For example, they cannot support microsecond-level synchronous triggering and real-time parameter adjustment of experimental instruments (such as spectrometers and mass spectrometers); they lack experimental logic verification mechanisms, such as pre-experiment verification, variable control, parallel experiment management and other research-specific processes; and they lack a full-chain traceability design for scientific research data, which cannot meet the compliance requirements for the associated storage of experimental parameters, operation records and result data.

[0006] Second, it is impossible to achieve hard real-time linkage between theory and execution. Compared with Patent 1, which uses the HEFT algorithm for static scheduling, Patent 2, which uses the BPMN 2.0 standard process, and Patent 3, which focuses on optimizing modeling accuracy, all three complete the planning before execution, but there is no dynamic verification during execution. They lack a formal theorem verification mechanism and cannot intercept experimental plans that are inconsistent with the theory during execution. There is no hard linkage between real-time gating signals (such as counterexamples falsification CE, unknown weight reduction UNK) and the actuator, which leads to invalid experiments being unable to be terminated and a material loss rate as high as 35% (data from a 2024 review in Nature Synthesis).

[0007] Third, there is a lack of integrated optimization capabilities across multiple constraints. Existing technologies have not established a unified experimental cost model. For example, Patent 1 only considers tool latency and load, Patent 2 focuses on vehicle real-time performance, and Patent 3 optimizes latency and bandwidth. None of them integrate multi-dimensional constraints such as budget, energy consumption, materials, equipment wear and tear, and safety risks, resulting in an experimental budget overrun rate of >40% (statistics from the 2023-2024 CRO Industry White Paper).

[0008] Fourth, the security protection mechanism is inadequate. Existing technologies rely on software-level fault tolerance and retries. For example, Patent 1 uses an error propagation model and BFS retries, Patent 2 relies on vehicle OTA updates, and Patent 3 lacks hardware protection design. None of them have a dual hardware and software security linkage mechanism, and they cannot implement microsecond-level hardware cutoff for physical quantities such as temperature, current, and pressure, thus failing to effectively reduce the security incident rate.

[0009] Fifth, the data traceability is insufficient and reproducibility is poor. The existing system lacks a standardized auditing mechanism, and the consistency of experimental reproducibility is only 70%-80%, which is difficult to meet the requirements of scientific research standards. Summary of the Invention

[0010] Existing technologies cannot simultaneously meet the four core requirements of adapting to specific scientific research scenarios, real-time linkage between theoretical verification and physical execution, integrated optimization of multi-source constraints, and dual hardware and software security protection. Therefore, this invention aims to provide a five-finger engine-style scientific research execution system for automated laboratories, achieving: 1. Through a microservice decoupled architecture, independent hot upgrades of the engine are supported, eliminating upgrade downtime; 2. Through hard real-time linkage between formal theorem verification and physical execution (gating delay ≤ 50ms), experimental plans that are inconsistent with theory or potentially dangerous are intercepted in real time during execution; 3. Through a dual hardware and software security protection mechanism, the security incident rate is significantly reduced; 4. Achieve precise budget control through a unified multi-source constraint cost model; 5. The SHA-256 audit mechanism ensures the full traceability and high reproducibility of experimental data.

[0011] A five-finger engine-style scientific research execution system for automated laboratories, comprising a hardware layer, a communication layer, and a service layer; The hardware layer includes a sensor array, actuator group, edge controller, host computer, and storage device; the communication layer includes the Envoy / Istio service mesh; the service layer includes a perception engine, planning engine, routing engine, execution engine, verification engine, and meta-orchestrator; the perception engine, planning engine, routing engine, execution engine, and verification engine are connected to the host computer via the meta-orchestrator, which is deployed on the host computer in the hardware layer; the hardware layer communicates with the service layer through the communication layer, and the engines in the service layer implement gRPC / HTTP communication, and Redis Stream sharding is used to achieve task distribution and load balancing; The sensor array consists of one or more of a camera, force sensor, temperature sensor, and pH sensor; the actuator group consists of one or more of a robotic arm, injection pump, heater, and stirrer; the edge controller is based on an STM32 microcontroller to implement hardware-level protection for the sensor array and actuator group; and the storage device is a PostgreSQL relational database for MinIO object storage.

[0012] The perception engine receives multimodal sensing data from the sensor array and outputs candidate propositions for anomalies and corresponding counterexample evidence based on time-series coding and anomaly scoring algorithms. The planning engine calculates the cost of the estimated duration, estimated energy consumption, material consumption, equipment wear and tear, and safety risk entropy value in the task. The cost is used to select the combination of hardware layer actions required for the task under the budget. The routing engine presets a maintenance method template library and a control strategy library. The routing engine selects maintenance methods and control strategies according to the task domain and hardware layer devices. The execution engine controls the actuator group and monitors the gating signals output by the verification engine in real time. When it receives the CE signal, it immediately performs a shutdown or rollback operation. The verification engine calls the SMT solver to determine the satisfiability of abnormal candidate propositions and execution observation data, and outputs a three-state gating signal {OK, CE, UNK}, where CE indicates that a counterexample has been found, UNK indicates that the verification is unknown, and OK indicates that execution should continue. The meta-orchestrator is used to orchestrate the above engines into a directed acyclic graph (DAG) task and perform topology-first parallel scheduling. The verification engine and the execution engine are connected through a communication layer, and the end-to-end delay of the gating signal is ≤50ms.

[0013] The formula for calculating the planning engine cost C(a) is: Estimated duration T(a), estimated energy consumption E(a), material consumption M(a), equipment wear H(a), safety risk entropy S(a), time weighting Energy consumption weight Material weights Wear weight Safety weight The weight values ​​range as follows: .

[0014] The execution engine applies a rate constraint to the control quantity u, limiting |Δu| ≤ 0.1·u_max, where u_max is the maximum acceleration rate. The edge controller is equipped with an over-limit protection circuit, which directly cuts off the actuator power supply within 1ms when the temperature is detected to be >120℃, the current to be >4A, or the speed to be >3000rpm. The meta-orchestrator uses Redis Stream sharded message queues for task distribution and dynamically sets the timeout rollback threshold to T_timeout = 1.2·T(a), where T(a) is the estimated duration.

[0015] A control method for a five-finger engine-style scientific research execution system for automated laboratories includes the following steps: S1, the meta-arranger receives the task text description and sets the budget B and safety threshold through the planning engine; S2. The perception engine analyzes the sensing data of the sensor array and generates anomaly candidate propositions. S3, the planning engine calculates the overall cost. Select the action set that satisfies total cost ∑C(a) ≤ budget B; S4. The routing engine matches method and policy templates with the control policy library by maintaining the method template library, and the meta-orchestrator generates a DAG. S5, the execution engine runs according to the DAG nodes and responds to the gating signals of the verification engine in real time; S6. The verification engine performs formal verification and outputs {OK, CE, UNK} signals. S7. If a CE signal is received, roll back to the previous safe node; if a UNK signal is received, reduce the confidence level and adjust the actuator group parameters. S8. If an OK signal is received, generate an audit report with a SHA-256 hash.

[0016] Compared with existing technologies, the present invention achieves at least the following quantifiable technical effects: 1. Significantly improved parallel throughput Compared to the HEFT serial scheduling mode used in the comparative document CN202511257075.2, this invention improves overall throughput by about 40% (from the baseline of 100 tasks / hour to 140 tasks / hour) in an 8-node parallel experimental scenario by identifying parallelizable nodes through DAG topology sorting, achieving load balancing through Redis Stream sharding mechanism, and reducing blocking and waiting through asynchronous message queues.

[0017] 2. Latency-controlled growth Compared to the SOA service architecture in reference document CN202411761210.2, this invention, under an 8-node parallel environment with the same network, only increases end-to-end latency by approximately 9% (from the baseline 183 ms to 200 ms), with single-node latency remaining below 200 ms, fully meeting industrial real-time requirements. The increased latency mainly originates from the gating verification stage (approximately 40 ms), but this is compensated by reliable guarantees of execution security and theoretical consistency, a trade-off that is acceptable in scientific research automation scenarios.

[0018] 3. Execution rate and security are improved in tandem. Compared to the ungated execution mode of the reference document CN202511525133.5, in 1000 experimental tasks (including normal and abnormal tasks): the Thumb engine's real-time gating intercepted about 35% of theoretically inconsistent or potentially dangerous plans (350 / 1000), avoiding invalid execution and material loss; the executability rate (effective experiments / total experiments) increased from the baseline of 65% to 78%, an increase of 13 percentage points; the safety incident rate decreased by about 90% (from the baseline of 10 / 1000 experiments to 1 / 1000 experiments); the reasons for the improvement are: (1) millisecond-level gating hard linkage real-time interception of anomalies; (2) coordinated linkage of soft and hard dual protection mechanisms; (3) the confidence reduction and parameter narrowing strategy of the UNK branch effectively suppressed the risk of boundary uncertain working conditions.

[0019] 4. Enhanced budget control capabilities Compared to traditional self-powered laboratory systems (based on baseline data from the IEEE TAS 2023 review paper), in a set of experimental tasks with a budget of B=100 cost units, this invention achieves accurate cost estimation, real-time cost monitoring and dynamic adjustment, and gating to prevent unnecessary material consumption through the comprehensive cost model of the Pinky engine. This reduces the budget overrun rate from the baseline of 40% to 8%, a decrease of 32 percentage points, significantly improving the economic efficiency of scientific research projects.

[0020] 5. Reproducibility and Auditability Assurance Compared to the shortcomings of existing systems that lack standardized auditing mechanisms, this invention achieves the following: object storage and SHA-256 hash records support full-process auditing of experimental data and results; verification reports are required to include engine version numbers and gating logs, supporting third-party verification and comparison; when the same task is reproduced at different times, the consistency of experimental trajectory reaches 99.2% (based on statistics from 100 repeated experiments), meeting the stringent requirements of scientific research standards for reproducibility.

[0021] 6. Breakthrough in system availability In the scenario of hot engine upgrade, this invention achieves 100% system availability with no downtime through blue-green deployment and traffic gray-scale switching. Compared with the industry status quo of traditional tightly coupled system upgrades requiring more than 2 hours of downtime, this invention achieves smooth upgrades with zero downtime, ensuring the continuity of scientific research and production.

[0022] In summary, this invention achieves significant technological advancements in multiple dimensions, including parallel efficiency, execution security, economy, and reproducibility, through collaborative innovations such as the five-finger engine microservice architecture, DAG parallel scheduling, hard linkage for theorem verification, dual protection of software and hardware, and cost optimization based on multi-source constraints. The effects of this technology are difficult for those skilled in the art to predict based on existing technologies, and it constitutes a creative contribution. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the overall system architecture; Figure 2 This is a diagram illustrating the interaction between the five-finger engine and data flow. Figure 3 For the control method flowchart; Figure 4 This is a schematic diagram of the DAG orchestration and fragmented event flow structure; Figure 5 A timing diagram of the gated link for the theorem verification; Figure 6 A schematic diagram of security supervision and hardware / software boundary protection mechanisms; Figure 6-1 This is a schematic diagram showing the optimal safety risk weight coefficient α_s in the comprehensive cost function C(a); Table 6-2 is a complete data matrix diagram of the α_s optimization experiment presented in a structured form; Figure 7 A schematic diagram illustrating the application of friction coefficient measurement for a trolley on an inclined plane. Figure 8 A schematic diagram illustrating the application of pendulum motion damping measurement. Figure 8-1 Gantt chart for engine hot upgrade timing; Figure 9 This is a schematic diagram illustrating the application of chemical reaction kinetics in experimental scenarios. Detailed Implementation

[0024] A five-finger engine-style scientific research execution system for automated laboratories, comprising a hardware layer, a communication layer, and a service layer; The hardware layer includes a sensor array, actuator group, edge controller, host computer, and storage device; the communication layer includes the Envoy / Istio service mesh; the service layer includes a perception engine, planning engine, routing engine, execution engine, verification engine, and meta-orchestrator; the perception engine, planning engine, routing engine, execution engine, and verification engine are connected to the host computer via the meta-orchestrator, which is deployed on the host computer in the hardware layer; the hardware layer communicates with the service layer through the communication layer, and the engines in the service layer implement gRPC / HTTP communication, and Redis Stream sharding is used to achieve task distribution and load balancing; The sensor array consists of one or more of a camera, force sensor, temperature sensor, and pH sensor; the actuator group consists of one or more of a robotic arm, injection pump, heater, and stirrer; the edge controller is based on an STM32 microcontroller to implement hardware-level protection for the sensor array and actuator group; and the storage device is a PostgreSQL relational database for MinIO object storage.

[0025] The perception engine receives multimodal sensing data from the sensor array and outputs candidate propositions for anomalies and corresponding counterexample evidence based on time-series coding and anomaly scoring algorithms. The planning engine calculates the cost of the estimated duration, estimated energy consumption, material consumption, equipment wear and tear, and safety risk entropy value in the task. The cost is used to select the combination of hardware layer actions required for the task under the budget. The routing engine presets a maintenance method template library and a control strategy library. The routing engine selects maintenance methods and control strategies according to the task domain and hardware layer devices. The execution engine controls the actuator group and monitors the gating signals output by the verification engine in real time. When it receives the CE signal, it immediately performs a shutdown or rollback operation. The verification engine calls the SMT solver to determine the satisfiability of abnormal candidate propositions and execution observation data, and outputs a three-state gating signal {OK, CE, UNK}, where CE indicates that a counterexample has been found, UNK indicates that the verification is unknown, and OK indicates that execution should continue. The meta-orchestrator is used to orchestrate the above engines into a directed acyclic graph (DAG) task and perform topology-first parallel scheduling. The verification engine and the execution engine are connected through a communication layer, and the end-to-end delay of the gating signal is ≤50ms.

[0026] The formula for calculating the planning engine cost C(a) is: Estimated duration T(a), estimated energy consumption E(a), material consumption M(a), equipment wear H(a), safety risk entropy S(a), time weighting Energy consumption weight Material weights Wear weight Safety weight The weight values ​​range as follows: .

[0027] The execution engine applies a rate constraint to the control quantity u, limiting |Δu| ≤ 0.1·u_max, where u_max is the maximum acceleration rate. The edge controller is equipped with an over-limit protection circuit, which directly cuts off the actuator power supply within 1ms when the temperature is detected to be >120℃, the current to be >4A, or the speed to be >3000rpm. The meta-orchestrator uses Redis Stream sharded message queues for task distribution and dynamically sets the timeout rollback threshold to T_timeout = 1.2·T(a), where T(a) is the estimated duration.

[0028] A control method for a five-finger engine-style scientific research execution system for automated laboratories includes the following steps: S1, the meta-arranger receives the task text description and sets the budget B and safety threshold through the planning engine; S2. The perception engine analyzes the sensing data of the sensor array and generates anomaly candidate propositions. S3, the planning engine calculates the overall cost. Select the action set that satisfies total cost ∑C(a) ≤ budget B; S4. The routing engine matches method and policy templates with the control policy library by maintaining the method template library, and the meta-orchestrator generates a DAG. S5, the execution engine runs according to the DAG nodes and responds to the gating signals of the verification engine in real time; S6. The verification engine performs formal verification and outputs {OK, CE, UNK} signals. S7. If a CE signal is received, roll back to the previous safe node; if a UNK signal is received, reduce the confidence level and adjust the actuator group parameters. S8. If an OK signal is received, generate an audit report with a SHA-256 hash.

[0029] The technical solution is further explained as follows: 1. System Solution This invention provides a five-finger engine-style scientific research execution system for automated laboratories, characterized in that the system includes at least: 1. Index Engine (401) Deployed on a host computer (204), it receives multimodal sensing data from a sensor array (201), performs temporal feature encoding based on a temporal convolutional network (TCN) or a Transformer encoder, and outputs anomaly candidate propositions and corresponding counterexample evidence through an anomaly scoring algorithm. Technical features include: (1) Supports multimodal data fusion (vision, force, temperature, pH, etc.): including multimodal sensing data from cameras, force sensors, temperature sensors, pH sensors, etc. (2) Configurable sampling frequency (10Hz-1000Hz): Feature extraction of sensor data based on time encoder (such as TCN, RNN or Transformer); (3) Anomaly detection delay ≤ 10ms: Utilize anomaly scoring algorithms (such as isolated forest, variational autoencoder, etc.) to output anomaly scores and anomaly windows; 2. Thumb Engine (402) Deployed on a host computer, it converts proposition and observation data from the Index and Middle engines into SMT-LIB2 formal expressions, calls the Z3 / CVC5 solver for satisfiability determination, and outputs a three-state gating signal {OK, CE, UNK}. Technical features include: (1) The formal expression adopts the SMT-LIB2 standard format: the anomalous propositions from the Index engine and the observation data from the Middle engine are encoded into SMT-LIB2 formal expressions; (2) The solver supports mainstream SMT solvers such as Z3 and CVC5: call the SMT solver (such as Z3 and CVC5) to perform theorem proofs or satisfiability checks; (3) Total delay of gating link ≤ 50ms: The gating signal is sent to the meta-arranger and the middle engine to achieve real-time gating of the execution process and the type of output result. And optional proof or counterexample delays are controlled; 3. Middle Engine (403) A hybrid architecture deployed on an edge controller (203) and a host computer is used to implement millisecond-level closed-loop control of the actuator group (202) and to apply limiting and out-of-range protection to the control quantities. Technical features include: (1) Control cycle configurable from 1ms to 10ms: running on a real-time operating system (such as PREEMPT_RT), the control loop cycle can be configured from 1ms to 10ms; (2) Built-in PID / MPC controller: Based on middleware such as ROS2 / DDS, control commands and status feedback are subscribed to and control quantities are sent to the actuator group; (3) Implement rate limiting and jerk soft constraints: Apply rate limiting and jerk constraints to the continuous control quantity to avoid control jitter and overshoot; (4) Support LoRA incremental online fine-tuning: Read the hardware registers exposed by the edge controller, such as temperature, current, and speed, to realize software-level out-of-bounds protection and respond to the shutdown, derating, and retest commands issued by the Thumb engine and meta-arranger.

[0030] Preferably, the Middle engine applies a two-layer limiting to the control variable u: (1) Rate limiting: ; (2) Amplitude limiting: ; Where sat is the saturation function, and umax and Δumax are dynamically obtained from the executor specifications and task configuration. The original control input value of the kth control cycle is calculated by the upper-level controller (such as MPC or PID), and the unit is the physical dimension of the actuator (such as speed rpm, current A, displacement mm).

[0031] The actual control output value in the (k-1)th control cycle, i.e., the final control quantity applied to the actuator in the previous cycle, in units of... .

[0032] u[k]: The intermediate control quantity after rate limiting in the k-th control cycle, used as the input for amplitude limiting, in units of u[k]. .

[0033] Maximum permissible rate of change (rate limit threshold) represents the maximum allowable increment of the controlled quantity within a single control cycle, in units of [unit name missing]. This value is dynamically obtained from the actuator specifications (e.g., converting the motor's maximum angular acceleration into a cycle increment) and configured according to the task's safety level; a typical value is... .

[0034] The actuator's physical limit amplitude (amplitude limiting threshold) represents the maximum allowable output value of the actuator, in units of [missing information]. .

[0035] The control quantity finally output to the actuator in the k-th control cycle, after double limiting, ensures that both the rate and amplitude are within a safe range. (Unit: same) .

[0036] It is a saturation function, defined as: Its function is to restrict the input x to a certain value. Within the specified range, measures should be taken to prevent exceeding the limits.

[0037] 4. Ring Engine (404) The method template is developed by researchers who, after reasoning and verifying based on the experimental objectives and corresponding theorems, decompose mature experimental schemes (such as "inclined plane friction measurement") into a sequence of parameterized action steps. The Ring engine automatically assigns a version number (such as "v2.1") and generates initial confidence weights. The Ring engine continuously collects template running data to achieve self-evolution. After each experiment, it automatically updates the historical success rate of the template, marks the template based on the success rate, and manages the template version after each experiment.

[0038] Deployed on a host computer, it maintains the method template library and control strategy library, selecting the optimal method template and control strategy for the target task based on the task domain, device reachability domain, and historical success rate. Technical features include: (1) Template library supports version management: maintain experimental templates for different experimental tasks (such as inclined plane friction measurement, pendulum motion damping measurement, chemical reaction kinetics test). (2) Task-template matching based on cosine similarity: Templates are filtered and sorted according to task type, equipment capabilities, budget and security constraints.

[0039] (3) Record and update the historical success rate of templates: Record the historical success rate and failure mode of each template under different device configurations and parameter ranges; (4) Return the selected template and initial parameter space to the meta-arranger for generating DAG.

[0040] 5. Pinky Engine (405) Deployed on the host computer, it is used to calculate the comprehensive cost C(a) of action a, and select the optimal combination of actions that meet the conditions under the constraints of budget B and safety threshold Θ.

[0041] The formula used for comprehensive cost calculation is: The range of weighting coefficient values ​​and the design basis: (1) Calculate the comprehensive cost C(a) of action a based on the estimated duration T(a), estimated energy consumption E(a), material consumption M(a), equipment wear quantification value H(a), and safety risk entropy value S(a). (2) Combine and screen the candidate action set ai to ensure that the set of actionable actions is obtained under the condition that ∑C(ai)≤budget B and each action satisfies the safety threshold Θ; (3) Sort the available actions in ascending order of C(a) to provide a priority queue for the meta-arranger.

[0042] 6-element arranger (406) Deployed on a host computer, it orchestrates the Index, Thumb, Middle, Ring, and Pinky engines as DAG tasks, performs topology-first parallel scheduling, and triggers rollback and engine hot upgrades in case of timeouts or failures. Technical features include: 1. DAG scheduling algorithm: It adopts a three-layer DAG scheduling strategy of topology priority + priority queue + timeout rollback, follows the node dependency relationship to ensure the correctness of execution logic, realizes efficient resource scheduling based on Pinky engine, and implements automatic rollback and retry for nodes with execution abnormality through timeout rollback mechanism.

[0043] 2. Dynamic calculation of timeout threshold: (Using...) The dynamic threshold calculation mechanism is as follows: T(a) is the estimated execution time of node a by the Pinky engine, and the coefficient 1.2 is derived from the empirical redundancy design of industrial scheduling practice.

[0044] 3. Supports seamless hot upgrades of the engine (zero downtime): Seamless hot upgrades of the engine are achieved through blue-green deployment and traffic canary switching.

[0045] 7. Hardware layer, including: (1) Sensor array (201): camera, force sensor, temperature sensor, pH sensor, etc.; (2) Actuator assembly (202): robotic arm, injection pump, heater, agitator, etc.; (3) Edge controller (203): Hardware out-of-bounds protection is implemented based on STM32 / ARM; (4) Host computer (204): The computing server that deploys the Five Fingers Engine; (5) Storage devices (205): MinIO object storage and PostgreSQL relational database.

[0046] 8 Communication Layer The communication layer connects the five engines, the meta-arranger, and the hardware layer, specifically including: (1) Engines are interconnected through a service mesh composed of gRPC / HTTP2. The service mesh preferably uses Envoy or a similar proxy to implement traffic management, circuit breaking and rate limiting. (2) The meta-arranger (406) and the message queue (207-1…207-4) interact with each other through the event flow interface; (3) All raw data and reports are persisted through object storage (205) and relational database (206) to meet the requirements of traceability and auditability; (4) The message queue preferably adopts a streaming message structure that supports multiple shards (such as Redis Stream sharding), with each shard bound to an independent consumer group to achieve task load balancing and order guarantee.

[0047] 9. Core Linkage Mechanism Each engine is deployed in a decoupled manner. The three-state gating signal output by the Thumb engine directly controls the start and stop of the Middle engine, thus forming a hard linkage between theoretical verification and equipment control. Key technical points include: (1) Gating signals are transmitted through a separate gRPC channel and have a higher priority than ordinary data streams; (2) The Middle engine sets up a gating signal listening thread, which responds immediately upon receiving the CE / UNK signal; (3) The end-to-end delay of the gated link is ≤50ms, which meets the real-time requirements.

[0048] The present invention also provides a control method based on the above system, comprising the following steps: S301 Task Reception and Constraint Loading The meta-arranger (406) receives the experimental task description input by the user from the message queue (207-1), parses it, and loads it: (1) Experimental objective (e.g., "measuring the coefficient of friction") (”); (2) Budget constraint B (unit: yuan or cost unit); (3) Safety threshold (Including upper limits for temperature, current, speed, etc.); (4) Equipment reachability (the working range of each device).

[0049] S302 Anomaly / Counterexample Detection The Index engine (401) receives multimodal sensing data (such as camera 60 fps, force sensor 200 Hz, etc.) and performs the following operations: (1) Receive multimodal timing data from sensor array (201); (2) Temporal feature encoding is performed using a TCN / Transformer encoder; (3) Based on anomaly scoring algorithm Abnormal detection; (4) Generate abnormal candidate propositions (such as...) (And mark the evidence time window.)

[0050] S303 Cost Planning and Action Selection The Pinky engine (405) performs the following operations on the candidate actions: (1) Calculate the comprehensive cost C(a) for each candidate action a; (2) Under constraints And meet the safety threshold The optimal action combination is selected using a dynamic programming algorithm. (3) Output the priority queue of actions that satisfy the constraints.

[0051] S304 Method Routing The Ring Engine (404) performs the following intelligent routing operations based on the abnormal propositions generated in S302 and the set of actionable actions selected in S303: (1) Retrieve all candidate templates that match the current task type and device configuration in the method template library, and filter out high-risk templates; (2) A multi-objective sorting algorithm is used to score the candidate templates and the template with the highest score is selected; (3) Bind the action parameters filtered by S303 to the template variable, generate an instantiated execution template, and return it to the meta-orchestrator.

[0052] S305 DAG Generation and Resource Mapping The meta-arranger (406) converts the instantiated template provided by S304 into an executable DAG and maps it to hardware resources: (1) Abstract the steps such as actions, collection, verification, and archiving in the template into nodes of a directed acyclic graph; (2) Check the nodes in the DAG that require exclusive access to the device, and allocate exclusive locks through the resource token bucket mechanism; (3) Prioritize mapping data acquisition nodes to edge controllers (203) to reduce latency, map complex computing nodes (such as Thumb verification) to host computers (204), and archive large-capacity storage nodes to object storage (205). The mapping decision is dynamically adjusted based on real-time load monitoring.

[0053] S306 Execution Control The Middle Engine (403) executes DAG nodes on the edge controller and responds to gating signals in real time: (1) Subscribe to control instructions with an adjustable period of 1-10ms, implement PID / MPC closed-loop control on actuator group (202), and read hardware registers to obtain temperature, current and speed feedback; (2) Apply a rate limiter before the control quantity u is output. Amplitude Limit , The value is dynamically obtained by reducing the equipment's rated value by 20%.

[0054] (3) The gating signal hard linkage monitors the security risk of the Thumb engine gating signal through the interrupt mechanism and dynamically executes the shutdown, derating or retesting strategy. S307 Theoretical Verification / Conformity The Thumb engine (402) performs formal verification on the S302 proposition and the S306 observation data: (1) Natural language propositions (such as The observed data (force sensor readings, acceleration) are converted into SMT-LIB2 format assertions, and logical expressions containing physical constraints and device error models are constructed. (2) Call the Z3 / CVC5 solver to perform a satisfiability check and set a timeout threshold; (3) Output three-state gating signals: OK, continue to execute the current plan; CE (Counter Example), a counterexample is found, the current assumption is determined to be invalid, and a rollback is triggered; UNK (Unknown), the solution is undetermined, the confidence level is reduced and a conservative execution strategy is enabled.

[0055] Preferably, when outputting the UNK signal, the confidence level of the current method template is reduced by about 50%, and the step size of parameter search or adjustment is narrowed by about 30% to reduce risk.

[0056] S308 Loop Feedback and Rearrangement The meta-arranger (406) dynamically adjusts the DAG based on the S307 gating results and execution monitoring data: (1) When the CE signal is received, the execution flow is rolled back to the previous safe node, and the node is regenerated by modifying the template parameters or replacing the action within the maximum retry limit of 1 to 3 times; (2) When an UNK signal is received, the confidence level of the current method template is reduced by 50%, and the step size of subsequent node parameters is narrowed by 30% (e.g., (From 5° to 3.5°), a more conservative search strategy will be adopted to continue execution; (3) When a timeout or equipment failure occurs, trigger the corresponding node timeout rollback or failure retry, and record the cause of the failure.

[0057] S309 Log and Reproducibility The system generates experimental files with cryptographic signatures, supporting full-process third-party reproduction: (1) Write the engine call log, gating signal log, alarm events, temperature / current / pH / energy consumption index curves, and DAG execution trajectory (including each retry record) into the relational database (206). (2) Generate a verification report with a digital signature. The report shall include at least the SHA-256 hash of the experimental data and results, the version number of each engine instance, the Thumb engine gating log and corresponding timestamp, energy consumption curve or key indicator curve, etc. (3) Automatically generate a PDF report with a digital signature, verify that the report exposes a reproducible interface for third-party verification and auditing.

[0058] Computer-readable storage media The present invention also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it implements all or part of the steps of the control method S301 to S309 described above, so as to realize the control flow of the five-finger engine-type scientific research execution system for automated laboratories of the present invention.

[0059] (a) Invention Application Scenarios This invention is applicable to industrial scenarios such as self-powered laboratories, materials / chemical / physical experimental platforms, and high-throughput experimental screening. (II) Specific Implementation Examples The technical solution, structural features, and achieved technical effects of the present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art should understand that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0060] Example 1: System Deployment Architecture Example (corresponding to) Figure 1 , Figure 2 ) like Figure 1 As shown, the overall system architecture consists of three layers: (1) Hardware layer: including sensor array (201, including camera, force sensor, temperature sensor, pH sensor), actuator group (202, including robotic arm, injection pump, heater, stirrer), edge controller (203, based on STM32 to implement hardware out-of-bounds protection), host computer (204), storage device (205, including MinIO object storage and PostgreSQL relational database).

[0061] (2) Communication layer: Envoy / Istio service mesh (206) is used to implement gRPC / HTTP communication between engines, and Redis Stream sharding (207-1 to 207-4) is used to implement task distribution and load balancing.

[0062] (3) Service layer: including Index engine (perception engine, 401), Pinky engine (planning engine, 402), Ring engine (routing engine, 403), Middle engine (execution engine, 404), Thumb engine (verification engine, 405), and Meta-Orchestrator (406).

[0063] like Figure 2 As shown, the interaction relationship between the five-finger engine and the data flow is as follows: Index Engine (Perception Engine) → Thumb Engine (Validation Engine): Transmitting candidate propositions for exceptions; Pinky Engine (Planning Engine) → Meta-Orchestrator: Delivers cost-optimized action combinations; Ring engine (routing engine) → Middle engine (execution engine): passing method templates and control strategies; Thumb engine (verification engine) → Middle engine (execution engine): Transmits three-state gating signals; The Meta-Orchestrator coordinates the task orchestration and scheduling of all engines.

[0064] Example 2: Control Method Flow Example (corresponding) Figure 3 ) This embodiment details the complete process of the control method.

[0065] like Figure 3 As shown, the specific execution steps of the control method flow S301 to S309 are as follows: Step S301: The Meta-Orchestrator receives the user-input JSON-formatted task description, parses the budget B (unit: yuan), and the security threshold. Constraints include (dimensionless, 0-1), time limit T_max (unit: seconds), etc.

[0066] Step S302: The Index engine (perception engine) receives sensor data at a sampling rate of 100Hz and performs temporal encoding using an 8-layer TCN network (convolution kernel size 3, dilation factor [1,2,4,8,16,32,64,128]). The anomaly scoring threshold is set to... .

[0067] Step S303: The Pinky engine (planning engine) calculates the cost of each action according to the comprehensive cost formula, and uses a dynamic programming algorithm to... Find the optimal action combination within time complexity.

[0068] Step S304: The Ring engine (routing engine) matches the task domain vector and the template vector based on the cosine similarity, and selects the template with the highest similarity and a historical success rate of >80%.

[0069] Step S305: The Meta-Orchestrator uses a topology sorting algorithm to identify parallelizable nodes and distributes tasks through Redis Stream sharding.

[0070] Step S306: The Middle Engine (Execution Engine) executes PID / MPC control with a 1ms control cycle to implement rate limiting. With jerk constraint .

[0071] Step S307: The Thumb engine (verification engine) converts the proposition into SMT-LIB2 format and calls the Z3 solver to determine its satisfiability, with a delay of ≤50ms.

[0072] Step S308: Perform the corresponding operation based on the gating signal (OK continue / CE ​​rollback / UNK demotion).

[0073] Step S309: Generate and archive the verification report of the SHA-256 hash.

[0074] Example 3: Parallel Scheduling Example of DAG (corresponding to...) Figure 4 ) This embodiment details the implementation mechanism of DAG orchestration and fragmented event flow.

[0075] like Figure 4 As shown, the DAG orchestration and fragmented event flow structure includes: (1) DAG Construction: The experimental process is abstracted into a directed acyclic graph, and the node types include: Action Node: Corresponds to the executor operation; Verification Node: Corresponds to the Thumb engine (verification engine) for judgment; Synchronization Node: Corresponds to the point where multiple branches merge.

[0076] (2) Parallel scheduling algorithm: Input: DAG G=(V,E), Resource pool R Output: Scheduling sequence S 1. Calculate the in-degree of all nodes. 2. Add nodes with an in-degree of 0 to a priority queue Q (sorted by priority). 3. while Q is not empty: 4. Extract the head node v of the queue. 5. Allocate resources to execute v 6. Update the in-degree of the successor node of v. 7. Add the new node with an in-degree of 0 to Q. (3) Redis Stream sharding mechanism: Number of shards: 4 (207-1 to 207-4); Sharding strategy: Based on hash modulo of node ID; Consumer Groups: Each engine corresponds to one consumer group; Timeout threshold: T(a)·1.2 is dynamically calculated.

[0077] In an 8-node parallel scenario, throughput is increased by about 40% compared to serial execution, while end-to-end latency increases by about 9%.

[0078] Example 4: Theorem Verification Gating Example (corresponding) Figure 5 ) This embodiment details the timing characteristics and implementation mechanism of the theorem verification gated link.

[0079] like Figure 5 As shown, the timing flow of the theorem verification gated link is as follows: Time T0: The Middle Engine (Execution Engine) completes the execution of action a and collects observation data O(a).

[0080] T0+5ms: Observation data is transmitted to the Thumb engine (verification engine) via gRPC.

[0081] T0+10ms: The Thumb engine (validation engine) converts the observed data and the expected proposition P(a) into an SMT-LIB2 expression. (declare-const obs_value Real) (declare-const expected_value Real) (declare-const tolerance Real) (assert (= obs_value 0.22)) (assert (= expected_value 0.25)) (assert (= tolerance 0.05)) (assert (>(abs (- obs_value expected_value)) tolerance)) (check-sat) T0+40ms: The Z3 solver completes the determination and outputs the result: SAT (satisfiable) → Output CE signal; UNSAT (Unsatisfiable) → Output OK signal; UNKNOWN (Timeout or Unknown) → Output UNK signal.

[0082] T0+45ms: The gating signal is transmitted to the Middle Engine (Execution Engine) and Meta-Orchestrator via gRPC.

[0083] T0+50ms: The Middle Engine (Execution Engine) performs the corresponding operation based on the gating signal.

[0084] End-to-end gating latency is ≤50ms, meeting real-time requirements.

[0085] Example 5: Implementation of Dual Hardware and Software Security Protection This embodiment details the design and implementation of a dual hardware and software security protection mechanism.

[0086] like Figure 6 As shown, the security monitoring and hardware / software boundary violation protection mechanisms include: (1) Software layer protection (implemented by the Middle Engine execution engine) Rate limiting: ,in Configure according to equipment type (e.g., robotic arm) ); Acceleration constraints: To prevent inertial impact; Soft constraint of jerk: To ensure smooth motion; Parameter boundary check: All control parameters are checked for range before being issued.

[0087] (2) Hardware layer protection (implemented by edge controller 203): Temperature over-limit protection: When the detected temperature T>120℃, the hardware circuit directly cuts off the actuator power supply; Overcurrent protection: When the detected current I > 4A, the hardware fuse is triggered. Speed ​​overrun protection: When the detected speed n>3000rpm, emergency braking is triggered; Response time: Hardware protection response time <1ms, operating independently of the software system.

[0088] (3) Hardware-software linkage mechanism: When the software layer detects an abnormal trend, it actively reduces the control input to avoid triggering hardware protection. After the hardware protection is triggered, an interrupt signal is sent to the software layer to trigger the fault handling process; Dual protection ensures that a single point of failure will not lead to a safety accident.

[0089] After adopting a dual hardware and software protection mechanism, the security incident rate was reduced by approximately 90%.

[0090] Example 6: Example of measuring the friction coefficient of an inclined plane trolley (corresponding to...) Figure 7 ) This embodiment uses the measurement of the friction coefficient μ of the inclined plane trolley as a typical application scenario to illustrate the complete workflow of the five-finger engine system.

[0091] Experimental scenario and configuration: To verify the friction coefficient μ of the inclined plane cart, target range. Budget constraint B = 50 unit cost; safety thresholds are motor speed 0-500rpm, current ≤2A, temperature ≤80℃; experimental equipment includes servo motor (speed 0-500rpm), force sensor (range 0-10N), and camera (60fps).

[0092] The specific execution process includes: Step 1: Task reception and constraint loading (S301) The meta-orchestrator (406) receives JSON-formatted tasks from message queue 207-1: { "task_id": "friction_exp_001", "objective": "measure_friction_coefficient", "target_range": [0.1, 0.5], "budget": 50, "safety_thresholds": { "motor_rpm": [0, 500], "current_A": [0, 2], "temperature_C": [0, 80] } } Step 2: Anomaly Detection (S302) The Index engine (Perception Engine, 401) receives data from the camera (60fps) and the force sensor (200Hz), and calculates the deviation between the ideal acceleration a_ideal and the actual acceleration a_real based on a time-series model: like Generate abnormal candidate propositions; Send the proposition “Friction coefficient anomaly: μ_observed ∉ [0.1, 0.5]” to the Thumb engine (verification engine).

[0093] Step 3: Cost Planning (S303) The Pinky engine (planning engine, 405) calculates the overall cost of candidate actions: Action a1 (low-speed measurement): C(a1) = 15 units; Action a2 (medium speed measurement): C(a2) = 25 units; Action a3 (high-speed measurement): C(a3) = 35 units; Under the constraint of budget B=50, select the action combination {a1, a2}, with a total cost of 40 units.

[0094] Step 4: Method Routing (S304) The Ring engine (routing engine, 404) selects the "Inclined Surface Friction Measurement_v2.1" template from the template library, with a historical success rate of 92%.

[0095] Step 5: DAG Generation and Execution (S305-S306) The Meta-Orchestrator generates a Directed Acyclic Graph (DAG): [Initialization] → [Low-speed measurement a1] → [Verification V1] → [Medium-speed measurement a2] → [Verification V2] → [Results Summary] The Middle Engine (Execution Engine, 403) executes control instructions sequentially.

[0096] Step 6: Theoretical Verification (S307) The Thumb engine (validation engine, 402) performs formal validation of the measurement results: Measured values ; Verify the proposition: ; Verification result: OK, execution is allowed to continue.

[0097] Step 7: Output the results (S309) Generate a verification report, which includes SHA-256 hash, experimental trajectory, and gating log.

[0098] Example 7: Example of measuring pendulum motion damping (corresponding to) Figure 8 ) This embodiment uses a damped pendulum experiment as a scenario to illustrate the application of the system in dynamic system parameter identification.

[0099] Experimental Scenario and Configuration: The experimental task is to measure the damping coefficient γ of a damped pendulum and verify the energy dissipation model; in terms of energy loss... Under the verification conditions, it is OK; the experimental equipment includes an electromagnetic brake, an angle encoder (1000 lines), and a current sensor.

[0100] Specific experimental methods are as follows: Figure 8 As shown: (1) Select the "Damping Measurement_v1.3" template in the Ring engine (routing engine); (2) The Middle Engine (Execution Engine) controls the electromagnetic brake with a 5ms cycle to collect angle and angular velocity data; (3) The Index engine (perception engine) detects cycle drift, when the difference between adjacent cycles... Exceptions are generated at any time; (4) Thumb engine (validation engine) validates the energy loss model: (5) The execution latency of a single node is ≤200ms, which meets the real-time requirements.

[0101] Example 8: Experimental Example of Chemical Reaction Kinetics (corresponding) Figure 9 ) This embodiment uses a chemical reaction kinetics experiment as a scenario to illustrate the application of the system under multi-actuator collaboration and complex safety constraints.

[0102] Experimental scenario and configuration: The experimental task is to measure the reaction rate constant k and verify the Arrhenius equation. The overall cost budget of the experiment is constrained to B = 100 cost units. The experimental safety thresholds are temperature ≤150℃, pH∈[2, 12], and pressure ≤2atm. The experimental equipment includes heating tube, injection pump, stirrer, temperature sensor, pH sensor, and ultraviolet-visible spectrometer.

[0103] Specific implementation methods are as follows Figure 9 As shown: (1) Multi-actuator cooperative control: Heating element: PID temperature control, target temperature 80±2℃; Injection pump: pulse injection, flow rate 0.5 mL / min; Mixer: Constant speed mixing, 300 rpm.

[0104] (2) Multi-sensor fusion: A temperature sensor (10Hz) monitors the reaction temperature; pH sensor (1Hz) monitors the acidity or alkalinity of solution; The concentration of the product was monitored using a UV-Vis spectrometer (0.1 Hz).

[0105] (3) Pinky Engine (Planning Engine) Optimization: Using a Bayesian experimental design, we maximize the information gain with a budget of B=100 yuan.

[0106] (4) Thumb engine (verification engine) gating: Verification of the Arrhenius kinetic equation: ; (5) Hardware security protection: When the pH exceeds the limit (pH<2 or pH>12), the edge controller directly cuts off the power supply to the injection pump.

[0107] After adopting this system, the rate of chemical experiment safety incidents has been reduced to zero.

[0108] Example 9: Engine Hot Upgrade Example (corresponding) Figure 9 ) This example illustrates the hot upgrade mechanism of the Five Fingers Engine microservice architecture, enabling upgrades without downtime.

[0109] Specific implementation methods are as follows Figure 8-1 As shown, the entire hot upgrade process sequence (taking the Thumb engine verification engine upgrade from v1.0 to v2.0 as an example): Phase 1 (0-5 seconds): New engine startup and registration T=0s: Deploy the Thumb Engine v2.0 container; T=2s: v2.0 completes initialization and registers with the Envoy service mesh; T=4s: v2.0 passed health check (HTTP 200 response).

[0110] Phase Two (5-20 seconds): Traffic Gradient Switching T=5s: The Meta-Orchestrator routes 10% of new tasks to v2.0; T=10s: The performance indicators of v2.0 are normal, and the flow rate ratio has increased to 50%; T=15s: Traffic ratio increased to 100%, v1.0 no longer accepts new tasks.

[0111] Phase 3 (20-25 seconds): Graceful exit of old instances T=20s: v1.0 waits for all associated DAG tasks to complete; T=25s: v1.0 completes all existing tasks and exits gracefully; The longest waiting time shall not exceed the timeout threshold of 1.2·T(a).

[0112] Phase 4 (after 25 seconds): Upgrade complete The system remains continuously available with no downtime. The upgrade process is transparent to users.

[0113] During the hot upgrade process, the system availability remained at 100%, with no task interruption.

[0114] Figure 1 The three-layer decoupled architecture of this invention is illustrated. The hardware layer (201-203) is responsible for real-time data acquisition and low-level control; the computing layer (204) deploys the microservice-based five-finger engine (401-405) and the meta-orchestrator (406), with loosely coupled communication between the engines via gRPC / service mesh; the data layer (205-207) provides persistence and an event bus. The key innovation lies in the fact that the gating signal output by the Thumb engine (402) to the meta-orchestrator (406) can directly interrupt the execution of the Middle engine (403), forming a hard linkage between theoretical verification and physical control. This architecture supports hot upgrades and fault isolation, and can improve parallel throughput by approximately 40% compared to traditional tightly coupled systems.

[0115] Figure 2 The data flow between engines is depicted. (1) The Index engine analyzes sensor data to generate anomalous propositions and sends them to Ring and Thumb; (2) The Pinky engine calculates the comprehensive cost C(a) and broadcasts the constraints; (3) The Ring engine selects a method template accordingly; (4) The meta-arranger aggregates decisions to generate a DAG; (5) The Middle engine executes and sends back the observation data; (6) Thumb performs formal verification and outputs a three-state gating signal {OK, CE, UNK}. The gating loop marked in the figure is the core of this invention, with a delay of ≤50ms, realizing online interception of invalid experiments and improving the executability rate by 78%.

[0116] Figure 3The process employs a main-feedback dual-path design. The main execution path (S301→S306) is responsible for task loading, anomaly detection, cost planning, method routing, DAG generation, and execution control. In the verification feedback path (S307→S309), the "CE" branch of S307 triggers a rollback in S308, and the "UNK" branch performs a reduced-rate retry, forming a closed loop of "experiment-verification-correction." This diagram defines the timing logic of theoretical verification embedded in the execution loop, which, unlike traditional offline verification modes, reduces the incidence of dangerous experiments by 90%.

[0117] Figure 4 The left side shows an example of a Directed Acyclic Graph (DAG), where nodes N1–N7 correspond to initialization, parallel collection, parallel computation, aggregation, and archiving, respectively, with dependencies strictly limited by directed edges. The right side shows Redis Stream using 4 shards (207-1 to 207-4) and consumer groups (C1–C4) to achieve task load balancing and fault isolation. Real-world testing shows that topology-first scheduling combined with priority queue scheduling improves throughput by 40% when 8 nodes are running in parallel, while only increasing end-to-end latency by 9%.

[0118] Figure 5 Focusing on the timing details of hard-linkage. The Thumb engine (402) completes the Z3 solution within 30ms and outputs the CE signal → the meta-arranger (406) parses and rewrites the DAG within 10ms → the Middle engine (403) receives the stop command and executes it within 10ms. The total gating delay is ≤50ms, ensuring that dangerous actions are intercepted before execution. The deterministic delay of this link is the technical guarantee of the security of this invention and meets the requirements of industrial-grade real-time control.

[0119] The total delay of the hard-linked loop of Thumb engine (402) → meta-arranger (406) → Middle engine (403) was decomposed in the form of a time-series waterfall. The measured total delay is ≤50ms, which meets the requirements of industrial-grade real-time control.

[0120] Figure 6 The dual hardware and software protection mechanism is demonstrated in detail. The hardware layer (203) uses an independent MCU to monitor analog signals such as temperature and current, and then uses a comparator circuit (response time...) Directly cut off the MOS transistor drive; the software layer (403) implements rate limiting. With acceleration constraints The two work together through the "rollback and derating" logic (406) to avoid malfunctions and omissions, reducing over-temperature / over-current events by 88% in industrial experiments.

[0121] Figure 6-1The experimental data show the optimization process of the safety risk weight coefficient α_s in the comprehensive cost function C(a). The horizontal axis represents the value of α_s (0.5-25), the left vertical axis represents the accident rate (%), and the right vertical axis represents the budget completion rate (%).

[0122] Table 6-2 presents the complete data matrix of the α_s optimization experiment in a structured form, including 8 sets of comparative experiments. Each set records five columns of data: α_s value, accident rate, budget completion rate, experiment interruption rate, and optimization conclusion.

[0123] Figure 7 This demonstrates the complete mapping of a friction force measurement experiment. The Index engine identifies a 12% acceleration deviation from data from the camera (60fps) and the force sensor (200Hz), generating the proposition " "; Pinky engine plans 4 sets of experiments (total cost 41.5 yuan ≤ B = 50 yuan); Thumb verifies and returns CE, triggering parameter replacement (θ changed from 15° to 25°); finally Archive.

[0124] This case demonstrates the end-to-end landing capability of the Five Fingers Engine in classical mechanics experiments.

[0125] Figure 8 For the damped pendulum experiment, the periodic drift detection and energy dissipation model verification are demonstrated. The Ring engine uses the "Damping Measurement_v1.3" template, the Middle engine controls the electromagnetic brake with a 5ms period, and the Thumb engine verifies the energy loss model. This scenario verifies the applicability of the system in dynamic system parameter identification, with a single-node latency of ≤200ms.

[0126] Figure 8-1 The entire hot upgrade process of the Five-Finger Engine microservice architecture is presented in Gantt chart format, with the horizontal axis representing time (0-25 seconds) and the vertical axis representing the upgrade stages. The entire process is divided into four stages: Stage 1 (0-5s): The new engine v2.0 starts up and registers with the Envoy service mesh, completing a health check; Stage 2 (5-20s): The meta-orchestrator routes new tasks to v2.0 in a gradient of 10%→50%→100%, while the old instance v1.0 continues to process existing DAG tasks; Stage 3 (20-25s): The old instance v1.0 waits for all associated DAGs to complete before exiting, with the longest waiting time not exceeding the timeout threshold of 1.2·T(a); Stage 4 (25s): The upgrade is complete, and the system remains available.

[0127] Figure 9This case presents a complex scenario involving multi-actuator collaboration (heater, injection pump, stirrer) and multi-sensor fusion (temperature, pH, UV-Vis spectroscopy). The Pinky engine optimizes information gain (using Bayesian experimental design) within a budget of B=100 yuan, while the Thumb engine performs gating checks on the Arrhenius kinetic equations. Hardware protection immediately shuts off the injection pump when the pH exceeds the limit. This case demonstrates the system's industrial value in automated chemical synthesis, achieving a zero safety incident rate.

[0128] The following is a full explanation of the terminology and nouns used in this document: 1. Standard Glossary 2. Glossary Five-Finger Engine: The microservice architecture paradigm proposed in this invention decouples the entire scientific research process into five orthogonal independent service engines: Index (perception), Thumb (verification), Middle (execution), Ring (routing), and Pinky (planning). The Index engine (meaning "index," for quickly screening anomalies), the Thumb engine (meaning "thumb," for final decision confirmation), the Middle engine (meaning "middle finger," for connecting and executing tasks), the Ring engine (meaning "ring," for closed-loop accumulation of the knowledge base), and the Pinky engine (meaning "little finger," for fine-tuning planning). Each engine communicates through a gRPC / HTTP service mesh, supporting horizontal scaling and independent hot upgrades.

[0129] Safety risk entropy S(a): A dimensionless safety risk metric constructed based on the Shannon entropy concept in information theory, used to quantify the degree of uncertainty that experimental action a may trigger a safety event. The calculation formula is as follows: ,in Let S(a) be the probability of the i-th type of security event. The value of S(a) ranges from [0,1], where 0 represents complete safety (highest certainty) and 1 represents the highest risk (maximum uncertainty).

[0130] Meta Orchestrator: A global coordination service deployed on the host computer. It orchestrates the decisions of each engine into an editable DAG, performing topology-first parallel scheduling, timeout rollback, fault retries, and engine hot upgrades. "Meta" comes from the Greek word for "beyond," emphasizing its meta-level management capabilities, situated above the five engines, including cross-engine coordination, cross-version management, and cross-task orchestration.

[0131] The three-state gating signals are a set of discrete control signals {OK, CE, UNK} output by the Thumb engine. The specific response strategies are {OK (theoretical verification passed, allow execution of the next DAG node), CE (a counterexample detected, immediately stop and roll back to the previous safe node, retry up to 1-3 times), UNK (verification timed out or insufficient evidence, confidence reduced by 50%, parameter step size narrowed by 30%, continue execution with limits)}. This discretized three-state design is the semantic foundation for achieving "hard linkage between theoretical verification and physical execution".

[0132] DAG Parallel Scheduling: The experimental process is abstracted as a Directed Acyclic Graph (DAG), where nodes represent actions or verification steps and edges represent dependencies. A topological sorting algorithm is used to identify parallelizable nodes, and task distribution is achieved through RedisStream sharding (from 207-1 to 207-4). The timeout threshold is dynamically calculated as T(a)×1.2.

[0133] A dual hardware and software protection mechanism: The software layer protection mechanism implements rate limiting for the Middle engine. ) and jerk constraint ( The hardware layer protection mechanism is that the edge controller's over-limit protection circuit directly cuts off the actuator power supply when the temperature is >120℃, the current is >4A, or the speed is >3000rpm, with a response time of <1ms.

[0134] SHA-256 audit: For each experiment, a data packet (raw sensor data, gating log, engine version, parameter hash) is generated and a SHA-256 digest is calculated. The data is then stored on the blockchain or in object storage (MinIO) to achieve full-process traceability and third-party reproducibility.

Claims

1. A five-finger engine-style scientific research execution system for automated laboratories, characterized in that, Includes hardware layer, communication layer, and service layer; The hardware layer includes a sensor array, actuator group, edge controller, host computer, and storage device; the communication layer includes the Envoy / Istio service mesh; the service layer includes a perception engine, planning engine, routing engine, execution engine, verification engine, and meta-orchestrator; the perception engine, planning engine, routing engine, execution engine, and verification engine are connected to the host computer via the meta-orchestrator, which is deployed on the host computer in the hardware layer; the hardware layer communicates with the service layer through the communication layer, and the engines in the service layer implement gRPC / HTTP communication, and Redis Stream sharding is used to achieve task distribution and load balancing; The sensor array consists of one or more of a camera, force sensor, temperature sensor, and pH sensor; the actuator group consists of one or more of a robotic arm, injection pump, heater, and stirrer; the edge controller is based on an STM32 microcontroller to implement hardware-level protection for the sensor array and actuator group; and the storage device is a PostgreSQL relational database for MinIO object storage.

2. The five-finger engine-type scientific research execution system for automated laboratories according to claim 1, characterized in that... The perception engine receives multimodal sensing data from the sensor array and outputs candidate propositions for anomalies and corresponding counterexample evidence based on time-series coding and anomaly scoring algorithms. The planning engine calculates the cost of the estimated duration, estimated energy consumption, material consumption, equipment wear and tear, and safety risk entropy value in the task. The cost is used to select the combination of hardware layer actions required for the task under the budget. The routing engine presets a maintenance method template library and a control strategy library. The routing engine selects maintenance methods and control strategies according to the task domain and hardware layer devices. The execution engine controls the actuator group and monitors the gating signals output by the verification engine in real time. When it receives the CE signal, it immediately performs a shutdown or rollback operation. The verification engine calls the SMT solver to determine the satisfiability of abnormal candidate propositions and execution observation data, and outputs a three-state gating signal {OK, CE, UNK}, where CE indicates that a counterexample has been found, UNK indicates that the verification is unknown, and OK indicates that execution should continue. The meta-orchestrator is used to orchestrate the above engines into a directed acyclic graph (DAG) task and perform topology-first parallel scheduling. The verification engine and the execution engine are connected through a communication layer, and the end-to-end delay of the gating signal is ≤50ms.

3. The five-finger engine-type scientific research execution system for automated laboratories according to claim 1, characterized in that... The formula for calculating the planning engine cost C(a) is:

4. Estimated duration T(a), estimated energy consumption E(a), material consumption M(a), equipment wear H(a), safety risk entropy value S(a), time weighting Energy consumption weight Material weights Wear weight Safety weight The weight values ​​range as follows: 。 5. A five-finger engine-type scientific research execution system for automated laboratories according to claim 1, characterized in that... The execution engine applies a rate constraint to the control quantity u, limiting |Δu| ≤ 0.1·u_max, where u_max is the maximum acceleration rate. The edge controller is equipped with an over-limit protection circuit, which directly cuts off the actuator power supply within 1ms when the temperature is detected to be >120℃, the current to be >4A, or the speed to be >3000rpm.

6. A five-finger engine-type scientific research execution system for automated laboratories according to claim 3, characterized in that... The meta-orchestrator uses Redis Stream sharded message queues for task distribution and dynamically sets the timeout rollback threshold to T_timeout = 1.2·T(a), where T(a) is the estimated duration.

7. A control method for a five-finger engine-type scientific research execution system for automated laboratories as described in any one of claims 1-5, characterized in that, Includes the following steps: S1, the meta-arranger receives the task text description and sets the budget B and safety threshold through the planning engine; S2. The perception engine analyzes the sensing data of the sensor array and generates anomaly candidate propositions. S3, the planning engine calculates the overall cost. Select the action set that satisfies total cost ∑C(a) ≤ budget B; S4. The routing engine matches method and policy templates with the control policy library by maintaining the method template library, and the meta-orchestrator generates a DAG. S5, the execution engine runs according to the DAG nodes and responds to the gating signals of the verification engine in real time; S6. The verification engine performs formal verification and outputs {OK, CE, UNK} signals. S7. If a CE signal is received, roll back to the previous safe node; if a UNK signal is received, reduce the confidence level and adjust the actuator group parameters. S8. If an OK signal is received, generate an audit report with a SHA-256 hash.

Images