A lightweight industrial workflow engine based on XState5 and a method for resuming execution after breakpoints.

Abstract

This invention provides a lightweight industrial workflow engine and breakpoint resumption method based on XState5, comprising: a core interpreter for interpreting and executing a state machine model; a snapshot persistentizer for serializing the current state machine's state value and context data into a snapshot record and persisting it to a local log file after each state transition; a unified job gateway for managing all calls to external jobs; an offline manual intervention module for generating a QR code containing the current job context information when a job fails to execute automatically or when the network is interrupted, allowing operators to scan and input data offline, and then sending the input data back to trigger the state machine to continue transitioning; and a restorer for restoring the state machine state before the system crashes and restarts. It achieves the technical effects of single-file deployment, second-level recovery, sub-block-level resumption, fully offline operation, and seamless automatic and manual fallback.

Description

Technical Field

[0001] This invention belongs to the field of industrial automation technology, and in particular relates to a lightweight industrial workflow engine based on XState5 and a method for resuming execution after a breakpoint. Background Technology

[0002] In industrial settings, the term "workflow" has long been associated with two drastically different images: one exists in bright offices, where flowcharts are filled with swimlanes for submissions, approvals, and copies, with nodes progressing via emails and to-do lists; the other is hidden deep within noisy workshops, where PLC registers, thermocouples, and robots form an invisible chain, where any signal loss or misalignment can lead to the scrapping of an entire batch. The former relies on the BPMN 2.0 specification, winning favor with business personnel with its rich visual symbols and loose semantics, but proves cumbersome and sluggish when faced with millisecond-level synchronization, breakpoint resume, or complete offline requirements. The latter has long lacked a lightweight, serializable process engine, relying instead on bloated distributed middleware or custom PLC programs, resulting in crashes requiring rework and power outages causing production stoppages to become the norm.

[0003] The incompatibility of traditional BPMN engines. In production scheduling, the core is monitoring and controlling the status of jobs or equipment, such as ready, running, paused, completed, and faulty. The rich features of BPMN engines, such as user tasks for manual approval and exclusive gateways for complex routing, are largely unnecessary in this scenario, instead introducing unnecessary complexity and resource overhead. Their relatively heavyweight architecture also struggles to meet the demands of the extreme industrial environments requiring offline, low-resource, and high-real-time performance.

[0004] In the fields of industrial automation and production scheduling, there are special requirements for workflow engines in terms of reliability, real-time performance, and lightweight deployment.

[0005] Currently widely used traditional workflow engines, such as Camunda and Flowable based on BPMN 2.0, are powerful, but they were originally designed for Business Process Management Systems (BPMS) that are centered on human activities and have relatively fixed processes. In the aforementioned industrial scenarios, they have inherent shortcomings such as heavy architecture, complex models, and unsuitability for describing state-driven logic.

[0006] With the rise of classified scenarios such as remote sensing imagery, military surveying and mapping, and chip manufacturing, data must not leave the internal network, and external network resources are completely cut off. The mirror warehouses, software sources, and cloud clusters that traditional engines rely on become instantly ineffective. At the same time, a single scene image can reach tens of gigabytes, and chip temperature control requires a response time of seconds. If the entire batch of data is reprocessed due to server downtime, it not only wastes a lot of computing power but may also delay delivery windows. The market urgently needs a lightweight workflow solution that can be deployed with a single file, restored in seconds, and handled manually offline. It should retain the strict semantics of state machines, run smoothly on single machines such as Raspberry Pi, industrial PCs, and offline environments, and be able to be revived on the spot through a pure JSON snapshot in the instant of a crash.

[0007] In summary, existing technologies cannot simultaneously meet the core requirements of single-file deployment, second-level recovery, sub-block-level resume operation, fully offline operation, and on-site manual backup in industrial scenarios. There is an urgent need for a lightweight workflow engine and breakpoint resume method that can adapt to extreme industrial environments. Summary of the Invention

[0008] Therefore, the technical problem to be solved by the present invention is to provide a lightweight industrial workflow engine based on XState5 and a method for resuming interrupted runs, which overcomes the inability of the prior art to simultaneously meet the requirements of single-file deployment, second-level recovery, sub-block-level resuming runs, fully offline operation, and on-site manual backup in industrial scenarios.

[0009] In a first aspect, the present invention provides a lightweight industrial workflow engine based on XState5, comprising: The core interpreter is used to interpret the execution state machine model, which adopts a true loop transition within a single instance. The true loop transition within a single instance includes: jumping within the current thread during state transition, adopting a tokenless architecture, the context persisting throughout the instance's lifecycle, and the crash snapshot falling on any phase within the loop. A snapshot persistent device is used to serialize the current state machine's state value and context data into a snapshot record after each state transition and persist it to a local log file. The unified job gateway is used to manage all calls to external jobs, generate globally unique idempotent keys for each job, and maintain the execution status of the jobs.

[0010] The offline manual intervention module is used to generate a QR code containing the current job context information when the automatic execution of the job fails or the network is interrupted. This code is then scanned by the operator to enter data offline, and the entered data is sent back to trigger the state machine to continue transitioning. The restorer is used to read the last snapshot record in the local log file after a system crash and restart, restore the state machine state before the crash, and query the real state of incomplete jobs through the unified job gateway to achieve state alignment and continue executing the state machine.

[0011] Furthermore, the snapshot persistent device adopts a sequential append-only writing method, and the local log file is subjected to rolling compression after reaching a preset size.

[0012] Furthermore, the idempotent key of the unified job gateway includes the order number, node name, and retry sequence number. When the instruction with the same idempotent key is called repeatedly, only the stored execution result is returned, and no new execution action is triggered.

[0013] Furthermore, the unified job gateway module exposes a start interface, a get interface, and a cancel interface; the start interface is used to start a job and return an idempotent key, the get interface is used to query the job status based on the idempotent key, and the cancel interface is used to cancel a job that is currently being executed.

[0014] Furthermore, the offline manual intervention module includes: The QR code generation unit is used to encode the context information of the current job into a QR code when the state machine enters a node that requires manual intervention; The offline manual operation unit is used by operators to scan QR codes using a PWA application, display job details and input forms offline, and receive the entered data; The data feedback unit is used to transmit the entered data back to the server where the engine is located via Bluetooth or LAN UDP protocol. The event feedback unit is used to send the received feedback data to the core interpreter to trigger a state transition.

[0015] Furthermore, the core interpreter runs on XState5, and the state machine model includes only three elements: nodes, transitions, and guards.

[0016] Furthermore, the core interpreter runs on a Tree-Shaking-trimmed version of XState5.

[0017] On the other hand, this invention provides a lightweight industrial workflow breakpoint resumption method based on XState5, applied to the aforementioned engine, including: Normal operating procedure: Start loading the state machine model and initialize the connection. If the local log file exists, restore the context from the last snapshot record. Wait for internal or external events. The core interpreter determines whether to perform a state transition based on the guard. After the state transition is completed, serialize the state and context and append them to the log. Then, issue job instructions through the job unified gateway. The job unified gateway generates a unique idempotent key for the job. Execute event waiting and state transition repeatedly until the workflow reaches the final state. Crash recovery steps: After the system restarts, the recovery device is started, the last snapshot record in the local log file is read, and the state and context before the crash are parsed out; the context is passed to the job unified gateway, the job unified gateway uses idempotent keys to query the real state of jobs that have been issued but have not been confirmed and updates the context; the state machine model loads the aligned context from the saved state points, triggers subsequent actions according to the actual state of the job, and completes the resumed operation; Offline manual intervention steps: When the state machine model enters a node requiring manual intervention or the unified job gateway detects that the network is unreachable for an extended period, a QR code containing task context information is generated; the user scans the code using a cached PWA application, enters the data offline, and then transmits the data back via Bluetooth or UDP; after receiving the transmitted data, it is parsed into an event and sent to the core interpreter to trigger the state transition to continue the process.

[0018] Furthermore, in the normal operation steps, the persistence of state transitions and job issuance are atomic operations. Job instructions are only issued after the log is successfully written, ensuring the consistency between state records and job execution.

[0019] Furthermore, in the crash recovery step, if the job is found to be completed, the result is directly reused without reissuing the job instruction; if the job is not completed or times out, the same idempotent key is used to re-initiate the request to ensure that the job is not executed repeatedly.

[0020] Beneficial effects: Dependency: Traditional engines require clusters of ZooKeeper, MySQL, message queues, etc., which cannot be deployed in secure data centers; this invention eliminates all external dependencies and can run after being packaged as a single file.

[0021] Coarse-grained recovery: Existing technologies use tasks / activities as the smallest unit, and if a 10GB image block within a single task fails, the entire process must be redone; this invention refines nodes to sub-blocks or millisecond signals, so that only the last small block is rerun after a crash.

[0022] Long recovery time: The background technology has an RTO in minutes; this invention achieves an RTO of ≤3 seconds through JSON snapshots + local alignment.

[0023] No offline manual backup: In the case of technical anomalies, it is necessary to log in to the database or blockchain console; this invention provides an offline channel via QR code, allowing on-site workers to complete the closed loop without IT skills.

[0024] Deployment is complex: Traditional engine upgrades require rolling shutdowns of the cluster; this invention copies a single file and restarts the process, the old process automatically writes a snapshot, and the new process reads the snapshot to continue, with zero downtime.

[0025] Controllable cycle time: Traditional DAG engines require "loop sub-processes" or multiple instance starts to simulate the cycle. There is no real cycle within a single instance, and after a crash, it can only return to the starting point of the sub-process. This invention utilizes XState5 real cycle transfer, which can infinitely heat up, heat up, cool down, and heat up again within a single thread. The crash snapshot stops precisely at any phase within the cycle, and when resuming, it continues the current cycle without having to rerun the entire cycle, which significantly saves energy and time.

[0026] Constant memory usage: BPMN-type engines expand linearly with the number of tokens, and large loops are prone to memory overflow; the state machine interpreter of this invention is resident at ≤30 MB, and the JSON snapshot only records the path of active nodes, which does not expand with the number of loops. The Raspberry Pi Zero can handle 100,000 loops without overflowing memory.

[0027] Zero repetition of side effects: The background technology relies on developers to manually write idempotency; this invention sinks the idempotency key into the engine's forced mechanism. Multiple starts of the same command only return the old result, ensuring that the cylinder does not press down twice and the image block does not infer twice, thus reducing scrap rate and electricity costs simultaneously. Attached Figure Description

[0028] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0029] Figure 1 Here is a flowchart of satellite data processing for Example 1; Figure 2 This is a flowchart of remote sensing image processing in Example 1; Figure 3 This is a flowchart of the breakpoint resume method in Example 2. Detailed Implementation

[0030] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. The principles and features of the present invention are described below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other. The embodiments given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0031] This invention first examines the existing technology, such as a patent that discloses a method, apparatus, device, and storage medium for resuming workflow execution after a breakpoint. Its purpose is to solve the problem of how to automatically retrieve the breakpoint and re-execute after a distributed workflow node fails.

[0032] This solution enables task-level resume from breakpoint in public clouds or large intranets, with an RPO (Recovery Point Objective) of 1 task and an RTO (Recovery Time Objective) in minutes (depending on the scheduler scan cycle).

[0033] Analyze its inherent defects: (1) Weight dependency: It requires three clusters: ZooKeeper, MySQL, and message queue, and cannot be deployed in a secure data center without external network access; (2) Coarse recovery granularity: The task is the smallest unit. If a single task processes 10GB of images, it will still need to be processed from scratch after failure. (3) No manual backup: If the abnormal information is stored in the database and the rerun still fails, only the maintenance personnel can log in to the database to manually modify the status. On-site operators cannot intervene. (4) No offline mechanism: When ZooKeeper and MySQL crash, the breakpoint records are also lost, and the recovery process is interrupted.

[0034] The paper also analyzed a patented method for resuming workflow interruptions based on blockchain, which aims to leverage the immutability of blockchain to ensure the reliability of interrupted data.

[0035] This process relies on FabricSDK and chaincode transactions to ensure data immutability; it relies on on-chain event notifications to trigger a rerun; and it relies on counter terminals to complete manual backup.

[0036] This solution enables trusted retry within a financial-grade intranet, with an RPO of one activity and an RTO in minutes (on-chain consensus time). The manual review process reduces the risk of erroneous retries.

[0037] The inherent defects are: (1) Weight dependency: It requires components such as Fabric cluster, Kafka, Orderer, and CA, and cannot run on a single machine; (2) No offline capability: The blockchain itself requires consensus among multiple nodes. When all nodes fail, the on-chain state cannot be written, and the recovery process is interrupted. (3) No easy manual access: Tellers must log in to the Fabric browser through the Web console to verify, and on-site operators cannot complete the process by scanning the code with their mobile phones; (4) Coarse granularity recovery: Similar to the aforementioned patent, it still uses activities as the smallest unit and cannot achieve sub-block level continued operation; (5) Confidentiality restrictions: TLS handshake and certificate exchange are required between blockchain nodes, making it difficult to deploy CA and DNS in a completely physically isolated confidential data center.

[0038] This invention addresses the shortcomings of the aforementioned technologies by proposing a lightweight industrial workflow engine and breakpoint resume method based on XState5. Through a three-in-one mechanism of JSON snapshot, job idempotent alignment, and QR code offline fallback, it achieves second-level recovery, sub-block-level resume, and fully offline operation, thereby filling the technological gap in scenarios such as confidential environments and remote sensing image processing.

[0039] When discussing workflows, most people envision office scenarios like leave requests, approvals, and CCs: an employee submits an application, their direct supervisor receives the request, clicks "approval," the system automatically pushes the process to the next position, and finally, it's archived and CC'd by HR. This everyday experience is precisely where BPMN 2.0 shines, abstracting the approval chain between people into visual swimlanes, using gateways to express approval and CC status, and using timeout events to send emails if there's no action within two days. Its design aims to be understandable to business users, hence its rich symbols, flexible semantics, and emphasis on flowcharts being code.

[0040] XState5 brings a completely different workflow. It directly embeds state machine theory into the production line, replacing approvals with heating, heat preservation, and cooling processes; replacing pending tasks with bit 3 of PLC register 0x0401; and replacing timeout reminders with indicators such as thermocouple temperature >230℃ for 180 seconds. The entire process is no longer human-readable, but rather machine-executable and crash-response-recovery-capable.

[0041] 1. Particle size and rhythm BPMN tasks typically correspond to a form, a REST call, or a manual click, with execution times measured in minutes or hours. XState5 nodes, on the other hand, can be refined to a Modbus write register or inference of a 512x512 image, with tick times measured in milliseconds or seconds. While parallel gateways can also draw concurrent tasks, their underlying mechanisms are often asynchronous messages and database states, not guaranteeing strict synchronization. XState5's type: 'parallel' allows simultaneous activity within the same thread or thread pool, making it suitable for industrial control applications requiring millisecond-level synchronization, such as simultaneous heating and nitrogen filling.

[0042] 2. State Expression BPMN uses the Activity containing the token to describe the process state. The token list is stored in the engine database and cannot be directly serialized into a JSON tree. After a crash, the entire Activity can only be rerun based on the database row records. XState5's state.value is itself pure JSON, such as {heat:'soak',motor:'on'}, which can be instantly written to disk and instantly transmitted over the network. Therefore, after a crash, it can resume at the instruction level simply by using actor.start(restoredSnapshot), without needing to replay the database logs.

[0043] 3. Side effect boundaries The side effects of office workflows are usually simply writing an approval record or sending an email, which can be retried if it fails. However, the side effects of production line workflows might be writing 0x0401.3=1 to press down the cylinder; repeated writing could cause the workpiece to crack. XState5 encapsulates all cross-process, cross-network, and cross-security domain actions into job commands and executes them through a unified gateway. Internally, the gateway implements a lookup-before-write or unique index rejection mechanism, thus transforming the developer-mandated idempotency conventions of BPMN into an engine-level enforcement mechanism.

[0044] 4. Has ring support capability BPMN 2.0's underlying execution model is a Directed Acyclic Graph (DAG): tokens can only be consumed along unidirectional edges. Although backtracking or looping sub-processes can be drawn in the diagram, they do not form true closed-loop back edges during runtime. To achieve an infinite cycle of heating, maintaining temperature, cooling, and then heating again, it can only be achieved through the following two syntactic sugar methods: Loop Sub-Process: Mark isSequential=true and loopMaximum=N on the sub-process. The engine instantiates the same sub-process N times, consuming it with a new token each time. The drawing itself is still a DAG.

[0045] Event rollback (Compensation / Jump): Using compensation events or engine-private APIs, tokens are jumped back from downstream nodes to upstream nodes, and the drawing shows a back edge. However, the runtime still destroys old tokens and creates new tokens, rather than continuously looping within the same thread.

[0046] The commonality between these two approaches is that there is no true cycle during the runtime of a single instance. Each loop is accompanied by the creation of a new token and the destruction of an old token. When a crash occurs and the process resumes, it can only return to the starting point of the subprocess and cannot stop precisely at any point within the cycle.

[0047] XState5 uses a true-loop state machine model: the transition table allows any target to point back to itself or an upstream node, for example: heat:{on:{TEMP_OK:'soak',TEMP_LOW:'heat'}} The runtime interpreter jumps back to the old node directly within the current thread, without creating a new token or destroying the old context. Therefore: The drawings and the running state are completely consistent; a loop is a loop and there is no need to wrap it with sub-processes. A crash snapshot can be precisely placed at any point within the loop, such as stopping at the 137th cycle of heat; when resuming the run, it continues to the 138th cycle without having to reheat from the beginning of the subprocess.

[0048] This would significantly benefit the following industrial scenarios: Chip vacuum furnace: heating, holding, cooling, and heating again, each cycle lasting 40 minutes, possibly for 20 cycles; the true loop model allows the state machine to stop at any phase of any cycle, and when it resumes running, it continues the current cycle instead of rerunning the entire 20 cycles.

[0049] Traffic light controller: red, green, yellow, red, with an infinite cycle; the true ring model allows the current color phase to continue immediately after a run, without needing to return to the initial red and start counting down again.

[0050] The XState5 model is a natural fit: the concept of finite state machines aligns perfectly with the discrete state changes in production scheduling. The three-element model of nodes, transitions, and guards clearly and unambiguously defines the production process. This simplicity directly translates to advantages in reliability, predictability, and execution efficiency—precisely what high-reliability industrial systems strive for.

[0051] In summary, XState5's ability to have cycles is a continuous loop within a single instance, which is fundamentally different from BPMN's DAG and syntactic sugar. This is also the core technical basis for this invention to achieve sub-block-level continuation rather than task-level rerun.

[0052] 5. Offline and human-machine backup BPMN engines heavily rely on databases, message queues, and HTTP interfaces; if the data center loses network access or the database crashes, the process stops, and on-site personnel can only manually change the status by logging into the backend. The entire core of the XState5 engine is less than 50MB and can be copied to a secure data center along with the installation package; when a node enters a state to wait for external results, it can generate a QR code and an offline PWA page, allowing operators to scan the code with their mobile phones to enter actual test values, which are then written back to the local SQLite via Bluetooth / UDP. The state machine continues the transition after receiving the event—ensuring a closed loop even if the entire server goes down.

[0053] 6. Deployment and Operation Traditional BPMN solutions require advance preparation of HA databases, shared storage, and load balancers. Upgrades require stopping the cluster, backing up, and rolling deployment. The XState5 solution is a single-file executable. The new version is copied to a USB drive and can be upgraded via engine-upgrade on an industrial control computer next to the production line. When the old process receives a SIGTERM, it will automatically write a snapshot, and the new process will read the snapshot and continue, with zero downtime.

[0054] 7. Applicable Context BPMN's success hinges on people, forms, and approvals; its symbol system, such as user tasks, copy, and countersignature, is naturally suited for office work. XState5's symbol system, including entry, exit, invoke, guard, and final, directly maps sensor signals, actuator actions, and state transitions, naturally designed for machine timing. In other words, BPMN solves the problem of people waiting for people, while XState5 solves the problem of machines waiting for signals.

[0055] Table 1 shows a comparison of the features of BPMN2.0 and XState5.

[0056] Table 1 Core Concepts State-driven: Focuses on the specific states that an entity (such as a production task or a piece of equipment) will experience during its lifecycle, and what events can trigger the transitions between states. Activity-driven: Focuses on which activities (tasks) make up a business process, how these activities flow sequentially, and the collaboration among participants. Modeling Basics State diagrams are defined using code (such as JavaScript / TypeScript) or declarative configuration (JSON / SCXML), and are tightly integrated with the application's business logic, forming part of the system. Modeling is done using standardized visual symbols (such as rounded rectangles for tasks and diamonds for gateways), emphasizing separation from specific technical implementations, and involving business analysts in the design process. Key elements States, events, transitions, actions, guards. The model is relatively lightweight and rigorous. Activities, events, gateways (used to control process branches, aggregations, etc.), and sequence flows. A rich set of elements to describe complex business process patterns. Typical scenarios UI process control, device control, game logic, communication protocols, and other internal system logics that are clearly defined, logically rigorous, and event-driven. Complex business processes involving multiple participants, multi-system integration, and clearly defined business procedures, such as OA approval, order processing, and cross-departmental collaboration. Advantages The model is simple and intuitive, making it easy for developers to implement and reason; it has strong type support (TypeScript), allowing errors to be detected at compile time; it is lightweight, making it easy to embed into applications; and it is highly predictable, with all paths clearly defined. Standardization is the industry's common language, facilitating communication; it boasts powerful visual modeling and monitoring capabilities; and it has built-in support for complex business models such as manual tasks, countersigning, reassignment, and rollback. Disadvantages There is a lack of industry-standard visual modeling tools; for pure business processes that require multi-person collaboration and complex routing, it is necessary to build them yourself, which is not straightforward. The specifications are extensive, resulting in a steep learning curve; the engines are usually relatively heavyweight; for scenarios involving pure system automation and simple state logic, it may seem like using a sledgehammer to crack a nut, and not nimble enough. In short, BPMN 2.0 workflows resemble a corporate management system diagram, emphasizing who approves and who copies; XState 5 workflows resemble a device sequence logic diagram, emphasizing when to heat up, when to maintain temperature, and when to end. The former makes the office more efficient, while the latter allows the production line to resume operation within 3 seconds after a crash, network outage, or power failure. They have different purposes, semantics, and recovery models, and therefore cannot replace each other. Example 1

[0057] This embodiment discloses a lightweight industrial workflow engine based on XState5, including: The core interpreter is used to interpret and execute the state machine model. The state machine model adopts true loop transitions within a single instance. True loop transitions within a single instance include: jumping within the current thread during state transitions, adopting a tokenless architecture, the context persisting throughout the instance's lifecycle, and crash snapshots falling on any phase within the loop. A snapshot persistent device is used to serialize the current state machine's state value and context data into a snapshot record after each state transition and persist it to a local log file. The unified job gateway is used to manage all calls to external jobs, generate globally unique idempotent keys for each job, and maintain the execution status of the jobs. The offline manual intervention module is used to generate a QR code containing the current job context information when the job fails to execute automatically or the network is interrupted. Operators can scan the code and enter the data offline, and then send the entered data back to trigger the state machine to continue transitioning. The restorer is used to read the last snapshot record in the local log file after a system crash and restart, restore the state machine state before the crash, and query the real state of incomplete jobs through the job unified gateway to achieve state alignment and continue executing the state machine.

[0058] In some optional implementations, the core interpreter runs on a Tree-Shaking trimmed version of XState5, with a size not exceeding 400kB and a resident memory of ≤30MB. It can interpret and execute state machine models described by SCXML or JSON. The model contains only three elements: nodes, transitions, and guards, and does not contain specific device calls.

[0059] In some alternative implementations, the snapshot persistent file uses sequential appending of log files. After each state transition is completed, the state.value and context are immediately serialized into JSON and written to disk. The log is rolled and compressed after reaching a set size, and at most the last transition is lost in the event of a power outage.

[0060] The idempotent key of the unified job gateway includes the order number, node name, and retry sequence number. When the same instruction with the same idempotent key is called repeatedly, only the stored execution result is returned, and no new execution action is triggered. The unified job gateway is a single executable file that supports local pipe / Unix domain socket calls. Internally, it integrates offline drivers for PLCs, databases, and AI inference libraries. Externally, it exposes start, get, and cancel interfaces. The start interface is used to start a job and return the idempotent key, the get interface is used to query the job status based on the idempotent key, and the cancel interface is used to cancel a job that is currently being executed. Internally, it implements idempotent key and query-before-write logic.

[0061] In some alternative implementations, the offline manual intervention module includes: The QR code generation unit is used to encode the context information of the current job into a QR code when the state machine enters a node that requires manual intervention; The offline manual operation unit is used by operators to scan QR codes using the PWA application, display job details and input forms offline, and receive entered data; The data feedback unit is used to transmit the entered data back to the server where the engine is located via Bluetooth or LAN UDP protocol. The event feedback unit is used to send the received feedback data to the core interpreter to trigger state transitions.

[0062] Offline manual backup includes a PWA static page + QR code generator. The page is less than 2MB and is cached locally on the phone after the first opening. When the network is down on site, the operator scans the code to enter the actual measurement value, and then feeds it back to the local SQLite via Bluetooth or LAN UDP, and the state machine continues to transition.

[0063] The restorer uses a standalone CLI. After startup, it reads the last log entry and completes the snapshot loading, job alignment, and state machine continuation process within 3 seconds. If the job does not return, it re-queries using the same idempotent key and does not reissue the job.

[0064] Figure 1 A flowchart illustrating the state machine operation after deploying the workflow engine of this invention in the field of satellite data processing.

[0065] Figure 2 To deploy the remote sensing image processing flowchart of this invention, in terms of remote sensing block processing, the process includes block segmentation, inference, writing results, and loop-based block segmentation, with 100,000 blocks per scene; the true loop model ensures that after a crash, only the current block is rerun, without needing to re-decompress from the first block.

[0066] Existing technologies record breakpoints by writing task quadruples to a central MySQL database. After a crash, the scheduler needs to scan the database tables and re-deliver messages, resulting in a typical RTO of minutes. Furthermore, breakpoint records are lost when the database itself crashes. This invention, for the first time, directly serializes the XState5-generated state.value (JSON tree structure) and the current context into a single flat text string, and writes it to a local log file via sequential appending. Each state transition is written to disk, with a write time of only milliseconds. Because appending does not modify historical blocks, even in the event of a sudden power outage, only the last transition is lost, and the file itself remains intact. After a power outage and restart, the recoverer can read the last log entry and rebuild the in-memory state tree within 3 seconds, immediately resuming execution without rescanning the database or replaying the message queue. This mechanism refines the recovery granularity from the task level to the transition level, reducing the RTO from minutes to seconds, while eliminating dependence on external databases, meeting the deployment requirements of database-less environments such as Raspberry Pi and secure data centers.

[0067] The most common crash scenario in industrial settings is that an instruction has been issued, but the state machine has not received a response before power is cut off. Traditional BPMN engines or background technologies can only rerun the entire task, leading to repeated register writing by the PLC and repeated inference by the GPU, resulting in scrap or energy waste. This invention generates a globally unique idempotent key for each job within the gateway, composed of order number, node name, and retry sequence number, and embeds a look-before-write logic: when the restorer resumes the job, it first calls the gateway's get interface to query the job's actual status; if it has succeeded, the result is reused without re-issuing; if it is NOT_FOUND or times out, the same idempotent key is used to start the job again. Due to the unique index constraint, the gateway only returns the old result and does not trigger new side effects. This design moves idempotency from an application-layer slogan to an engine-level enforcement mechanism, ensuring that the same cylinder is not pressed down twice or the same image block is not inferred twice during crash recovery, significantly reducing scrap rate and energy consumption, while eliminating the need for developers to write any compensation code.

[0068] Existing technologies require manual verification and login to a web console, relying on TLS, CA, and DNS, making them unusable in physically isolated server rooms. Furthermore, the lack of event-level linkage between manual operation and the state machine easily leads to gaps where human confirmation is not recognized by the machine. This invention encapsulates manual verification as a state machine event: when an automated operation enters the WAIT_MANUAL node due to a complete network outage or PLC disconnection, the engine driver locally publishes a QR code via HTTP, containing the order number, node name, and required parameter structure. The operator scans the code with their mobile phone; the page is a static PWA resource, cached locally upon first opening and usable offline thereafter. After entering measured values, the mobile phone writes the results back to the Raspberry Pi's local SQLite via Bluetooth or LAN UDP, and the gateway immediately sends a MANUAL_OK event, allowing the state machine to continue transitioning. The entire process requires no login or TLS handshake; the QR code is the event entry point. After network recovery, the PWA uploads offline records in batches, forming a complete audit chain. This mechanism transforms manual input into a consumable state machine event for the first time, achieving seamless automatic-manual switching while meeting the requirements of a confidential environment with zero external network and zero certificate requirements.

[0069] These features together form a complete technical loop of lightweight deployment, second-level recovery, and offline fallback capability.

[0070] Example 2 This embodiment provides a method for resuming interrupted runs in a lightweight industrial workflow engine based on XState5, such as... Figure 3 As shown, it includes the following steps: 1. Normal procedure The normal process refers to the standard operation of the engine under fault-free conditions, and its core lies in event-driven, state synchronization, and log-first operation.

[0071] Startup and Initialization: The user starts the engine's executable file. The engine loads the workflow state machine model and initializes connections to external resources. If historical logs exist, the context is restored from the latest snapshot.

[0072] Event handling and state transition: The engine waits for internal events or external events received through the job unification gateway.

[0073] After an event is triggered, the core interpreter determines whether to perform a state transition based on the conditions (guards) defined in the state machine model.

[0074] Atomization operations and persistence: Step 1: After the state transition logic is executed, immediately serialize the new state value (state.value) and the updated context data (context), append them sequentially to the log file as a new record, and force write them to disk. This is a crucial step to ensure that no data is lost.

[0075] Step Two: Only after the log is successfully written will the engine issue specific job instructions to external devices or services through the unified job gateway, such as controlling PLC actions or triggering AI model inference. Internally, the gateway generates a unique idempotent key for each job to ensure that duplicate requests do not cause anomalies.

[0076] Loop: The engine enters the next event waiting loop, repeating the above process until the workflow reaches the final state.

[0077] 2. Crash recovery process The crash recovery process is designed to handle unexpected system crashes or power outages and achieve recovery within seconds. Its core lies in utilizing snapshot logs and idempotent queries from the job unified gateway.

[0078] Trigger: The recovery CLI is executed automatically or manually after the system restarts.

[0079] Load snapshot: The restorer reads the last valid record in the log file and parses out the state machine state (state.value) and the complete context before the crash.

[0080] State alignment (key step): The restorer passes the loaded context to the job unification gateway.

[0081] The gateway checks all jobs that were "deployed but not confirmed" at the time of the crash. Instead of re-deploying the start operation, it uses the stored idempotent key to send a GET query request to the corresponding external system.

[0082] This process aims to obtain the actual current state of the job and update the state machine's context with the result.

[0083] Resuming the state machine: The state machine loads the aligned context from the saved state points, and then determines the next action based on the actual state of each job. For example, if a job has been completed, a completion event is triggered; if it has failed, an error event is triggered. The entire process is designed to be completed within 3 seconds, achieving seamless transition to interrupted tasks.

[0084] 3. Offline manual backup process This process is used to introduce manual intervention when an automated process cannot be completed automatically due to network interruption or system malfunction, ensuring that the process is not interrupted.

[0085] Triggering and QR Code Generation: When the state machine transitions to a node requiring manual intervention, such as quality inspection, or when the unified job gateway detects prolonged network unavailability, the system automatically invokes the QR code generator. The generator encodes the current task's context information, such as the task ID, parameters to be inspected, and the result of the previous step, into a QR code image, which is then displayed on the industrial control screen or output to a printer.

[0086] Offline manual operation: On-site operators scan QR codes using a PWA application on their personal mobile phones. This application is cached and can run completely offline. The application interface displays task details and required forms. After completing on-site measurements or observations, the operator enters the data into the form.

[0087] Data feedback: After data entry is complete, the mobile application sends the data back to the engine's server via available communication methods, such as Wi-Fi UDP broadcast or Bluetooth. UDP is preferred in this scenario due to its simplicity and low overhead.

[0088] Event Feedback and Process Continuation: The engine's data receiving service listens for the returned data packets, parses them into structured data, and sends them along with the data as a manual completion event, such as MANUAL_INPUT_RECEIVED, to the core interpreter. The state machine triggers a state transition based on this event, and the process continues to run automatically.

[0089] This invention overcomes the inherent defects of existing workflow engines in confidential, offline, and high real-time production scenarios, and provides a lightweight industrial workflow solution that can be deployed with a single file, restored in seconds, and manually handled offline.

[0090] Workflow engines popular in large companies and enterprises typically rely on heavyweight clusters such as ZooKeeper, MySQL, and message queues, making them unsuitable for deployment in secure data centers without external network access or dedicated maintenance. This invention reduces the core to a mere 50MB offline package, eliminates reliance on external databases and coordinators, and achieves append-only log-based persistence through XState5 native JSON snapshots, enabling on-the-spot recovery within 3 seconds of a crash, reducing RTO from minutes to seconds.

[0091] This invention refines state nodes to sub-block or millisecond-level signal dimensions. Utilizing XState5's hierarchical and parallel semantics, it incorporates micro-steps such as image blocks, temperature zones, and PLC register bits into the state tree. After a crash, only the last small block is rerun, avoiding the need to re-decompress tens of gigabytes of raw data. Addressing the pain points of traditional engines that halt offline and require manual intervention via background database modifications, this invention introduces a PWA offline console and a QR code degradation channel. Field operators can use their mobile phones to scan a code and input measured values ​​even in the event of a complete network outage. Data is then fed back to the local SQLite database via Bluetooth / UDP. Upon receiving an event, the state machine continues its transition, forming a seamless automatic-manual closed loop.

[0092] Through the above innovations, this invention enables the workflow engine to operate reliably for the first time under the triple constraints of being completely offline, completely lightweight, and completely recoverable, filling the technological gaps in scenarios such as confidential production lines, remote sensing images, and military manufacturing.

[0093] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A lightweight industrial workflow engine based on XState5, characterized in that, include: The core interpreter is used to interpret the execution state machine model, which adopts a true loop transition within a single instance. The true loop transition within a single instance includes: jumping within the current thread during state transition, adopting a tokenless architecture, the context persisting throughout the instance's lifecycle, and the crash snapshot falling on any phase within the loop. A snapshot persistent device is used to serialize the current state machine's state value and context data into a snapshot record after each state transition and persist it to a local log file. The unified job gateway is used to manage all calls to external jobs, generate globally unique idempotent keys for each job, and maintain the execution status of the jobs. The offline manual intervention module is used to generate a QR code containing the current job context information when the automatic execution of the job fails or the network is interrupted. This code is then scanned by the operator to enter data offline, and the entered data is sent back to trigger the state machine to continue transitioning. The restorer is used to read the last snapshot record in the local log file after a system crash and restart, restore the state machine state before the crash, and query the real state of incomplete jobs through the unified job gateway to achieve state alignment and continue executing the state machine.

2. The lightweight industrial workflow engine based on XState5 according to claim 1, characterized in that, The snapshot persistent device uses a sequential append-only writing method, and the local log file is rolled and compressed after reaching a preset size.

3. The lightweight industrial workflow engine based on XState5 according to claim 1, characterized in that, The idempotent key of the unified job gateway includes the order number, node name, and retry sequence number. When the instruction with the same idempotent key is called repeatedly, only the stored execution result is returned, and no new execution action is triggered.

4. The lightweight industrial workflow engine based on XState5 according to claim 3, characterized in that, The unified job gateway module exposes a start interface, a get interface, and a cancel interface. The start interface is used to start a job and return an idempotent key, the get interface is used to query the job status based on the idempotent key, and the cancel interface is used to cancel a job that is currently being executed.

5. The lightweight industrial workflow engine based on XState5 according to claim 1, characterized in that, The offline manual intervention module includes: The QR code generation unit is used to encode the context information of the current job into a QR code when the state machine enters a node that requires manual intervention; The offline manual operation unit is used by operators to scan QR codes using a PWA application, display job details and input forms offline, and receive the entered data; The data feedback unit is used to transmit the entered data back to the server where the engine is located via Bluetooth or LAN UDP protocol. The event feedback unit is used to send the received feedback data to the core interpreter to trigger a state transition.

6. The lightweight industrial workflow engine based on XState5 according to claim 1, characterized in that, The core interpreter runs on XState5, and the state machine model includes only three elements: nodes, transitions, and guards.

7. The lightweight industrial workflow engine based on XState5 according to claim 6, characterized in that, The core interpreter runs on a Tree-Shaking-modified version of XState5.

8. A lightweight industrial workflow breakpoint continuation method based on XState5, applied to the engine according to any one of claims 1 to 7, characterized in that, include: Normal operating procedure: Start loading the state machine model and initialize the connection. If the local log file exists, restore the context from the last snapshot record. Waiting for internal or external events, the core interpreter determines whether to perform a state transition based on the guards; after the state transition is completed, the state and context are serialized and appended to the log, and then the job instruction is issued through the job unified gateway, which generates a unique idempotent key for the job; the event waiting and state transition are executed in a loop until the workflow reaches the final state; Crash recovery steps: After the system restarts, the recovery tool is started, the last snapshot record in the local log file is read, and the state and context before the crash are parsed out; The context is passed to the unified job gateway, which uses an idempotent key to query the true status of jobs that have been issued but whose results have not been confirmed and updates the context accordingly. The state machine model loads the aligned context from the saved state points and triggers subsequent actions based on the actual state of the job to complete the continued running; Offline manual intervention steps: When the state machine model enters a node requiring manual intervention or the unified job gateway detects that the network is unreachable for an extended period, a QR code containing task context information is generated; the user scans the code using a cached PWA application, enters the data offline, and then transmits the data back via Bluetooth or UDP; after receiving the transmitted data, it is parsed into an event and sent to the core interpreter to trigger the state transition to continue the process.

9. The lightweight industrial workflow breakpoint resumption method based on XState5 according to claim 8, characterized in that, In the normal operation steps, the persistence of state transitions and job issuance are atomic operations. Job instructions are only issued after the log is successfully written, ensuring the consistency between state records and job execution.

10. The lightweight industrial workflow breakpoint resumption method based on XState5 according to claim 8, characterized in that, In the crash recovery step, if the job is found to be completed, the result is reused directly without reissuing the job instruction; if the job is not completed or times out, the same idempotent key is used to re-initiate the request to ensure that the job is not executed repeatedly.

Images