Task execution method, apparatus and system

Abstract

The application relates to a task execution method, device and system. The method comprises the following steps: generating a device task operation flow according to received production task information and a preset standard action instruction library; the standard action instruction library comprises a plurality of standard action instructions and a mapping relationship between the production task information and each standard action instruction; performing format conversion processing on the device task operation flow according to a preset communication protocol to obtain a task operation request; the communication protocol of the task operation request is consistent with the communication protocol of a control module in a target device; and the task operation request is sent to the control module of the target device to enable the control module to control the target device to execute the task operation request. The method has low adaptation and maintenance costs.

Description

Technical Field

[0001] This application relates to the field of intelligent manufacturing technology, and in particular to a task execution method, apparatus and system. Background Technology

[0002] In smart factories, there are numerous production devices from different manufacturers. These devices typically use custom communication protocols and control interfaces from each manufacturer, leading to significant challenges in device integration and control.

[0003] In related technologies, dedicated communication drivers are developed for each type or even each device. The device control system needs to directly understand the proprietary protocols of each manufacturer, resulting in high device adaptation and maintenance costs. Summary of the Invention

[0004] Therefore, it is necessary to provide a task execution method, apparatus, and system with low adaptation and maintenance costs to address the aforementioned technical problems.

[0005] Firstly, this application provides a task execution method applied to a control terminal; the method includes:

[0006] Based on the received production task information and the preset standard action instruction library, a device task operation process is generated; the standard action instruction library includes multiple standard action instructions, as well as the mapping relationship between the production task information and each of the standard action instructions.

[0007] The device task operation process is format-converted according to a preset communication protocol to obtain a task operation request; the communication protocol of the task operation request is consistent with the communication protocol of the control module in the target device.

[0008] The task operation request is sent to the control module of the target device, so that the control module controls the target device to execute the task operation request.

[0009] In some of these embodiments,

[0010] The production task information includes the equipment type of the target equipment, the task name of the task instruction corresponding to the target equipment, and the task parameter information of the task instruction corresponding to the target equipment;

[0011] The step of generating equipment task operation procedures based on received production task information and a preset standard action instruction library includes:

[0012] Based on the device type and the task name, at least one target action instruction is obtained from the standard action instruction library; the target action instruction is one of multiple standard action instructions.

[0013] Generate an initial task operation flow based on at least one of the target action instructions;

[0014] The device task operation process is generated based on the task parameter information and the initial task operation process.

[0015] In some embodiments, the standard action instruction library further includes a logical order between the standard action instructions; when there are multiple target action instructions, generating an initial task operation flow based on at least one target action instruction includes:

[0016] Based on the standard action instruction library, determine the logical order among the multiple target action instructions;

[0017] The initial task operation flow is generated based on the logical order among the multiple target action instructions.

[0018] In some embodiments, the standard action instruction library is also used to store communication configuration information of the control module in the target device, and each standard action instruction includes mandatory parameters; the production task information includes the device type of the target device, the task name of the task instruction corresponding to the target device, and the task parameter information of the task instruction corresponding to the target device;

[0019] The step of generating equipment task operation procedures based on received production task information and a preset standard action instruction library includes:

[0020] Receive the production task information;

[0021] Based on the production task information, the standard action instruction library is subjected to a first task verification process to obtain a first verification result;

[0022] The production task information is subjected to a second task verification process based on the standard action instruction library to obtain a second verification result.

[0023] If both the first verification result and the second verification result are verified as passed, the equipment task operation process is generated according to the standard action instruction library and the production task information.

[0024] The first task verification process includes at least one of the following:

[0025] Verify whether the standard action instruction library includes the standard action instruction corresponding to the production task information;

[0026] Verify whether the standard action instruction library includes the communication configuration information corresponding to the control module;

[0027] The second task verification process includes: verifying whether the task parameter information includes the required parameters of the standard action command corresponding to the device type and the task name.

[0028] In some embodiments, the production task information includes the device type of the target device and the task name of the task instruction corresponding to the target device; the standard action instruction library includes the mapping relationship between the device type, the task name, and each of the standard action instructions.

[0029] Secondly, this application provides a task execution method, applied to the control module of a target device in a device terminal; the method includes:

[0030] Receive a task operation request; the task operation request is determined and sent by the control terminal executing the task execution method in any of the above embodiments;

[0031] Analyze the task operation request to determine the device task operation process;

[0032] Control the device body of the target device to execute the device task operation process.

[0033] In some embodiments, the device body controlling the target device executes the device task operation process, including:

[0034] Obtain the target action instructions in the device task operation process, as well as the logical order between the target action instructions;

[0035] The device body is controlled to execute the target action instructions in the logical order.

[0036] In some embodiments, the task operation request is in message format, and parsing the task operation request to determine the device task operation flow includes:

[0037] The task operation request is parsed to obtain task operation information; the task operation information includes a message header field, a data length field, a data payload field, and a checksum field; the data payload field is used to indicate at least part of the device task operation process, and the data length field is used to indicate the length of the data payload;

[0038] The task operation information is verified to obtain the verification result;

[0039] If the verification result is successful, the device task operation process is determined based on the task operation information.

[0040] The verification process includes at least one of the following:

[0041] The integrity of the task operation information is verified based on the data length field.

[0042] The identity of the task operation information is verified based on the verification code field.

[0043] The data payload field is validated for content integrity based on the data length field.

[0044] Thirdly, this application provides a task execution device applied to a control terminal; the device includes:

[0045] The equipment control module is used to generate equipment task operation procedures based on the received production task information and the preset standard action instruction library. The production task information includes the equipment type of the target equipment, the task name of the task instruction corresponding to the target equipment, and the standard action instruction library includes multiple standard action instructions, as well as the mapping relationship between the equipment type, the task name and each of the standard action instructions.

[0046] A communication protocol adaptation module is used to perform format conversion processing on the device task operation process according to a preset communication protocol to obtain a task operation request; the communication protocol of the task operation request is consistent with the communication protocol of the control module in the target device.

[0047] The device control driver module is used to send the task operation request to the control module of the target device, so that the control module controls the target device to execute the task operation request.

[0048] Fourthly, this application provides a task execution device applied to a control module of a target device in a device terminal; the device includes:

[0049] A request receiving module is used to receive task operation requests; the task operation request is determined and sent by the control terminal executing the task execution method in any of the above embodiments;

[0050] The request parsing module is used to parse the task operation request and determine the device task operation process;

[0051] The task execution module is used to control the device body of the target device to execute the device task operation process.

[0052] Fifthly, this application provides a task execution system, including a control terminal and a device terminal. The device terminal includes at least one device, which includes a control module and a device body. The control terminal is used to execute the steps of the task execution method executed by the control terminal in any of the above embodiments, and the device terminal is used to execute the steps of the task execution method executed by the control module of the target device in the device terminal in any of the above embodiments.

[0053] In the aforementioned task execution method, apparatus, and system, after receiving production task information containing the device type of the target device and the task name of the corresponding task instruction, the control terminal calls a preset standard action instruction library. The standard action instruction library stores atomic standard action instructions independent of the underlying hardware. Through the mapping relationship between the pre-set production task information and standard action instructions in the standard action instruction library, the control terminal decomposes and combines the business-level production task into a set of device task operation procedures composed of general standard action instructions. This application directly converts "business tasks" into "general instruction sequences," which is more conducive to achieving control normalization compared to the customized conversion logic of "business task → dedicated driver → device private message" in related technologies. Next, the control terminal performs format conversion and encapsulation of the generated device task operation procedure according to a preset communication protocol, ultimately generating a task operation request compatible with the control module protocol in the target device. The target of the conversion is not the native private protocol of the device hardware, but the standardized communication protocol of the control module installed on the device side. Further, the control terminal sends the converted task operation request to the control module of the target device, which receives the instruction and ultimately controls the device to complete the corresponding operation. As can be seen, the upper-level scheduling logic of the task execution method in this application is designed based on a unified standard action instruction system. It does not need to be aware of the protocol differences of different devices. It can command multiple devices to perform the same process through a single scheduling logic, which fundamentally reduces the complexity of the scheduling system, improves the reusability of the scheduling logic, and thus helps to reduce the adaptation and maintenance costs of the devices. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a flowchart of a device control method in related technologies;

[0056] Figure 2 This is a flowchart illustrating a task execution method applied to the control terminal in one embodiment of this application;

[0057] Figure 3 This is a flowchart illustrating step S201 in one embodiment of this application;

[0058] Figure 4 This is a flowchart illustrating step S302 in one embodiment of this application;

[0059] Figure 5 This is a flowchart illustrating step S201 in another embodiment of this application;

[0060] Figure 6 This is a flowchart illustrating a task execution method applied to a control module in one embodiment of this application;

[0061] Figure 7 This is a flowchart illustrating step S603 in one embodiment of this application;

[0062] Figure 8 This is a flowchart illustrating step S602 in one embodiment of this application;

[0063] Figure 9 This is a flowchart illustrating a task execution method in one embodiment of this application;

[0064] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] In semiconductor packaging and testing and intelligent factories, there are a large number of production equipment (such as testing machines, sorting machines, and packaging machines) from different manufacturers. These devices typically use custom communication protocols and control interfaces from each manufacturer, which leads to significant challenges in equipment integration and control.

[0067] The current mainstream approach is to develop dedicated communication drivers for each type or even each device. Device control systems need to directly understand the proprietary protocols of each manufacturer (such as semiconductor device and material communication standard protocols, Transmission Control Protocol / Internet Protocol custom messages, etc.).

[0068] For example, in a standard equipment control process in related technologies, after the Manufacturing Execution System (MES) issues a production task, the Material Control System (MCS) needs to identify the target equipment type, then call the corresponding dedicated driver module to convert the task into a message format specific to that equipment, and finally send it to the equipment controller for execution. The entire process is highly dependent on dedicated drivers; different brands of equipment require different driver implementations.

[0069] Please see Figure 1 The specific steps of the related technology may include steps S101 to S107.

[0070] S101: MCS receives production tasks.

[0071] S102: MCS identifies the type of target device (e.g., a test machine of brand A).

[0072] S103: MCS calls the brand's dedicated driver module.

[0073] S104: The dedicated driver translates the task into a message that the device can understand.

[0074] S105: Sends messages to the device controller via Transmission Control Protocol / Internet Protocol or serial port.

[0075] S106: The device executes and returns the original status data.

[0076] S107: Dedicated driver parses the raw data and feeds it back to MCS.

[0077] If the device is replaced with one from brand B, the drive logic corresponding to steps S103-S107 needs to be redeveloped. Therefore, the device control method in the relevant technology has the following drawbacks:

[0078] First, the adaptation cost is high. Every time a new brand of device is introduced, the driver call code needs to be rewritten, which results in a long development cycle and high labor costs.

[0079] Secondly, maintenance is difficult; device protocol upgrades can cause driver failures, requiring continuous investment of maintenance resources.

[0080] Third, the scheduling is complex, and it is impossible to use a unified logic to direct equipment of different brands to perform the same process, resulting in a high level of complexity in the scheduling system.

[0081] Fourth, it has poor scalability; the integration of new devices requires modifications to the existing system, affecting system stability.

[0082] To address the above technical problems, in some exemplary embodiments, this application provides a task execution system, including a control end and a device end. The device end includes at least one device, which includes a control module and a device body.

[0083] The control end can be a Material Control System (MCS), which may include an action instruction management module and a communication protocol adaptation layer. The action instruction management module is used to define and maintain a set of standard atomic instruction sets (i.e., standard action instruction library) that are independent of the device. The standard atomic instruction set includes, but is not limited to, interface operation instructions, image recognition instructions, system operation instructions, communication interaction instructions, script extension instructions, etc. The communication protocol adaptation layer is used to convert the device task operation process into protocol messages that can be recognized by the specific device, realizing protocol-level translation of instructions.

[0084] The control unit can also include a device control driver layer, which is responsible for establishing communication connections with the underlying physical devices or device-side control modules to send task operation requests and receive status data. By setting up a device control driver layer, asynchronous distribution of task operation requests and status feedback to each device on the device side can be achieved, supporting high-concurrency non-blocking scheduling.

[0085] The control module in the device can be device control software. The control module can be installed on the corresponding device body, or it can be connected to the device body through a relay server. The control module is responsible for receiving instructions and executing specific interface operations or hardware controls, and feeding back the execution results to the control terminal.

[0086] In this system, communication between the control terminal and the device control driver layer, as well as between the device control driver layer and the control module, is achieved through standardized interfaces to decouple business logic from physical drivers.

[0087] The task execution system of this application can be applied to various application scenarios such as semiconductor packaging and testing equipment control, electronic manufacturing production line equipment scheduling, intelligent warehousing and logistics equipment management, unified control of multi-brand testing machines, and automated transformation of old equipment interfaces.

[0088] In some exemplary embodiments, please refer to Figure 2 This application provides a task execution method, applied to the control terminal of the above-mentioned task execution system, the method including steps S201 to S203.

[0089] S201: Generate equipment task operation procedures based on the received production task information and the preset standard action instruction library.

[0090] In this embodiment of the application, the control terminal can receive production task information issued by the Manufacturing Execution System (MES). The production task information may include the equipment type of the target equipment and the task name of the task instruction corresponding to the target equipment.

[0091] The control unit can be configured with a standard motion instruction library, which stores multiple standard motion instructions, as well as the mapping relationship between production task information and each standard motion instruction. In some examples, the standard motion instruction library can store device type, task name, and the mapping relationship between each standard motion instruction.

[0092] In some examples, the standard action instruction library may include interface operation instructions, image recognition instructions, system operation instructions, communication interaction instructions, and script extension instructions. Specifically, interface operation instructions may include standard action instructions such as control handle operation, mouse click, and keyboard input; image recognition instructions may include standard action instructions such as optical character recognition and image feature matching; system operation instructions may include standard action instructions such as file read / write, process management, and registry operations; communication interaction instructions may include standard action instructions such as network communication, serial communication, and message queues; and script execution instructions may include standard action instructions such as custom script language execution and business logic orchestration. Based on the various types of instructions in the above standard action instruction library, the task execution system of this application can support multiple interaction modes between the control terminal and the control module, including at least a precise control mode based on control handles and a fallback control mode based on image feature recognition.

[0093] After receiving production task information, the control terminal can search for the corresponding standard action instruction in the standard action instruction library based on the equipment type of the target device and the task name of the task instruction in the production task information, and combine the found standard action instructions into a device task operation flow. The standard action instructions can be described using a structured data format, including a display name, interface name, and configuration fields.

[0094] S202: The device task operation process is format-converted according to the preset communication protocol to obtain the task operation request.

[0095] It is understood that the control module in this application can be control software pre-installed on the target device. In the case where the device side includes multiple devices, the control module installed on each device can be the same control software. The communication protocol followed by the control module can be independent of the original proprietary protocol of the target device. That is, the communication protocol followed by the task operation request after format conversion is not the native proprietary protocol of the device hardware, but a standardized communication protocol of the control module (device-side control software) installed on the device side.

[0096] The communication protocol for the task operation request is consistent with the communication protocol of the control module in the target device;

[0097] S203: Send the task operation request to the control module of the target device so that the control module controls the target device to execute the task operation request.

[0098] The control end can send task operation requests to the control module of the target device through the device control driver layer. The control end is only responsible for task scheduling, instruction mapping and protocol conversion, and does not directly drive the hardware device. The underlying execution logic is pushed down to the control module on the device side, which receives the instructions and ultimately controls the device to complete the corresponding operation.

[0099] In the above task execution method, after receiving production task information containing the device type of the target device and the name of the task instruction corresponding to the target device, the control terminal calls a preset standard action instruction library. The standard action instruction library stores atomic standard action instructions that are independent of the underlying hardware. Through the mapping relationship between the production task information and standard action instructions preset in the standard action instruction library, the control terminal decomposes and combines the business-level production task into a set of device task operation procedures composed of general standard action instructions. This application directly translates "business task" into "general instruction sequence", which is more conducive to achieving control normalization than the customized conversion logic of "business task → dedicated driver → device private message" in related technologies. Next, the control terminal performs format conversion and encapsulation of the generated device task operation procedure according to a preset communication protocol, and finally generates a task operation request compatible with the protocol of the control module in the target device. Here, the target of the conversion is not the native private protocol of the device hardware, but the standardized communication protocol of the control module installed on the device side. Further, the control terminal sends the converted task operation request to the control module of the target device, and the control module on the device side receives the instruction and finally controls the device to complete the corresponding operation. As can be seen, the upper-level scheduling logic of the task execution method in this application is designed based on a unified standard action instruction system. It eliminates the need to perceive protocol differences between different devices, and a single scheduling logic can command multiple devices to perform similar processes. This fundamentally reduces the complexity of the scheduling system, improves the reusability of the scheduling logic, and consequently reduces equipment adaptation and maintenance costs. Furthermore, in this application, adding new devices only requires supplementing the standard action instruction library with the mapping relationship between production task information and standard action instructions (e.g., the mapping relationship between "equipment type—task name—standard action instruction") and configuring the corresponding communication protocol conversion rules. There is no need to rewrite the core scheduling and driving logic, which helps reduce the development workload for new device integration, shortens the production line equipment integration cycle, and reduces labor costs. This solution also decouples the standard action instruction library from the underlying protocol. If the device protocol is upgraded, only the protocol adaptation rules between the control end and the device control module need to be adjusted, or only the underlying execution logic of the device control module needs to be updated. The core scheduling logic and standard instruction system of the control end do not need to be modified, significantly reducing the resource investment required for long-term system maintenance.

[0100] In some exemplary embodiments, the production task information includes the device type of the target device, the task name of the task instruction corresponding to the target device, and the task parameter information of the task instruction corresponding to the target device. The task parameter information is used to indicate the parameters required for the target device to complete the task instruction. Please refer to [link to relevant documentation]. Figure 3 Step S201: Based on the received production task information and the preset standard action instruction library, generate the equipment task operation process, including steps S301 to S303.

[0101] S301: Based on the device type and task name, retrieve at least one target action instruction from the standard action instruction library.

[0102] The target action instruction is one of several standard action instructions.

[0103] It's understandable that the standard action instruction library stores the mapping relationship between device type, task name, and various standard action instructions. Therefore, we can search the standard action instruction library for a device type and task name that match the target device's device type and task name, and then identify the standard action instruction corresponding to that device type and task name as the target action instruction. This step is used to determine the action framework corresponding to the task, i.e., which atomic operations need to be performed. This is only bound to the device type and task type and is unrelated to the specific work order's business parameters.

[0104] S302: Generate the initial task operation flow based on at least one target action instruction.

[0105] The essence of the initial task operation process is a standardized instruction sequence template. The initial task operation process can include various target action instructions, as well as the execution order of each target action instruction, fixed execution logic, parameter placeholders, and other information.

[0106] S303: Generate the device task operation process based on the task parameter information and the initial task operation process.

[0107] Among them, task parameter information refers to the dynamic business parameters required by the equipment to complete the current work order, such as test thresholds, application loading paths, material numbers, and process configuration values. These parameters change dynamically with different production work orders and are not part of the fixed definition of standard action instructions.

[0108] In some examples, the standard action instructions include parameter placeholders or initial parameters. After generating the initial task operation flow, the parameter placeholders or initial parameters in the target action instructions can be replaced with the parameters in the task parameter information to obtain the replaced target action instructions. Finally, a device task operation flow that is adapted to the current work order and can be directly issued and executed is obtained.

[0109] In some exemplary embodiments, the standard action instruction library also includes the logical order between the various standard action instructions; when there are multiple target action instructions, please refer to [link to relevant documentation]. Figure 4 Step S302: Generate an initial task operation flow based on at least one target action instruction, including steps S401 and S402.

[0110] S401: Determine the logical order between multiple target action instructions based on the standard action instruction library.

[0111] In the embodiments of this application, in addition to storing standard action instructions and the mapping relationship of "device type - task name - standard action instruction", the standard action instruction library also pre-stores the logical order between each standard action instruction. The essence of this logical order is the general timing dependency rule of device operation, such as the interface opening instruction must precede the parameter input instruction, the execution start instruction must be later than the parameter configuration instruction, and so on.

[0112] S402: Generate the initial task operation flow based on the logical order between multiple target action instructions.

[0113] When there are multiple target action instructions matched, the initial task operation process is not randomly arranged or dynamically arranged temporarily. Instead, it directly combines multiple target action instructions in an orderly manner according to the pre-set logical order in the standard action instruction library to form an initial process template with the correct execution sequence, i.e., the initial task operation process.

[0114] In this embodiment, the logical order between instructions is predefined and validated based on general operational logic, fundamentally avoiding timing logic errors caused by temporary instruction arrangement (such as the logical reversal of starting execution first and then configuring parameters), thus reducing the probability of process errors. Furthermore, by incorporating the instruction order relationship into the standard instruction library, the standard instruction system can be upgraded from a "fragmented set of atomic instructions" to a complete system of "instructions + combination rules." This helps to further shield the differences in operational processes between different devices, solidify the technical foundation for normalized scheduling, and support the unified scheduling of more complex multi-step production tasks.

[0115] In some exemplary embodiments, the standard action instruction library is also used to store communication configuration information of the control module; the standard action instructions include required parameters.

[0116] Please see Figure 5 Step S201: Based on the received production task information and the preset standard action instruction library, generate the equipment task operation process, including steps S501 to S504.

[0117] S501: Receive production task information.

[0118] The production task information is issued by the Manufacturing Execution System (MES). The production task information may include the equipment type of the target equipment, the task name of the task instruction corresponding to the target equipment, and the task parameter information of the task instruction corresponding to the target equipment.

[0119] S502: Perform the first task verification process on the standard action instruction library based on the production task information to obtain the first verification result.

[0120] In some examples, the first task verification process includes verifying whether the standard action instruction library includes standard action instructions corresponding to the production task information, and / or verifying whether the standard action instruction library includes communication configuration information corresponding to the control module.

[0121] The verification of whether the standard action instruction library includes standard action instructions corresponding to production task information involves verifying whether a mapping relationship exists between the target device's equipment type, the task name of the task instruction, and the standard action instructions in the standard action instruction library. This means that before generating the device task operation flow, it is necessary to verify whether the mapping relationship exists between the target device's equipment type, task name, and the standard action instruction library. In other words, it confirms whether the current task has a corresponding standard instruction flow definition, avoiding the issuance of undefined or unsupported invalid tasks to the target device. In application, if the mapping relationship between the target device's equipment type, task name, and the standard action instruction library does not exist, the control terminal can report an error message to the MES.

[0122] Verifying whether the standard action instruction library includes the communication configuration information corresponding to the control module refers to verifying whether the standard action instruction library stores the communication configuration corresponding to the control module of the target device. In some examples, the communication configuration information may include the IP address, port number, communication protocol type, connection parameters, etc., of the target device's control module. After receiving the production task information, the control terminal can search for the communication configuration information corresponding to the control module of the target device based on the device type. If the corresponding communication configuration information can be found, the control terminal verifies whether the communication configuration information of the control module of the target device is complete and valid, confirming that the device's communication parameters have been correctly entered into the instruction library, thus avoiding instruction issuance failure due to missing or incorrect communication configuration after process generation. If the corresponding communication configuration information is not found, the control terminal can report an error message to the MES.

[0123] In the first task verification process, which includes verifying whether the standard action instruction library contains standard action instructions corresponding to the production task information and whether the standard action instruction library contains communication configuration information corresponding to the control module, the first verification result is considered successful only if the standard action instruction library contains both the standard action instructions corresponding to the production task information and the communication configuration information corresponding to the control module.

[0124] S503: Perform second task verification processing on the production task information according to the standard action instruction library to obtain the first verification result.

[0125] In some examples, the second task verification process includes verifying whether the task parameter information includes the required parameters of the standard action instruction corresponding to the device type and task name. It is understood that the standard action instruction includes both required and optional parameters. Before generating the device task operation flow, it is necessary to verify whether the task parameter information carried by the production task information is complete, covering the integrity checks of both required and optional parameters, to avoid execution interruptions and logical anomalies due to missing parameters during subsequent instruction execution.

[0126] S504: If both the first and second verification results are passed, generate the equipment task operation process based on the standard action instruction library and production task information.

[0127] If the first verification result and / or the second verification result are unsuccessful, the control terminal can send error information to the manufacturing execution system. The error information may include the reason for the verification failure, that is, whether the standard action instruction library does not include the standard action instruction corresponding to the production task information, and / or whether the standard action instruction library does not include the communication configuration information corresponding to the control module, and / or whether the task parameter information includes the required parameters of the standard action instruction corresponding to the equipment type and task name.

[0128] In this embodiment, by moving the verification process forward to before the device task operation flow is generated, abnormal tasks with missing standard action instructions, missing communication configurations, or missing parameters can be intercepted before the task enters the core scheduling logic. This avoids invalid process generation, protocol conversion, and instruction issuance operations, reducing unnecessary system resource consumption. Simultaneously, it reduces the probability of device-side execution failures and task interruptions from the source, improving the overall stability of the scheduling system and the task execution success rate. Furthermore, the three types of verification correspond to three independent dimensions: process definition, communication configuration, and business parameters. When verification fails, the anomaly type and specific cause can be directly identified. Compared to the related technologies where task failure requires troubleshooting from multiple stages such as driver code, protocol parsing, and parameter passing, this application can reduce the time cost of fault diagnosis and improve the response efficiency of production line operation and maintenance.

[0129] In some exemplary embodiments, this application provides a task execution method applied to the control module of a target device in the device side of the aforementioned task execution system; please refer to... Figure 6 The method includes steps S601 to S603.

[0130] S601: Receive task operation request.

[0131] The task operation request received by the control module is determined and sent by the control terminal executing the task execution method in any of the aforementioned embodiments. The control module can be a standardized execution software on the device side, distinct from the device's native hardware controller in traditional solutions. This control module interfaces with the standardized communication protocol of the control terminal and drives the device itself to perform operations through interface operations, system calls, etc., serving as the core carrier for normalized scheduling on the device side.

[0132] S602: Parse the task operation request and determine the device task operation process.

[0133] The control module can decapsulate standardized, encapsulated task operation requests, extract the device task operation flow carried within, and obtain a structured sequence of standard action instructions. The object parsed by the control module is the unified format message issued by the control terminal, independent of the device manufacturer's proprietary protocol. The control module outputs a standard action instruction flow consistent with the control terminal's definition, ensuring the consistency of instruction semantics before and after transmission.

[0134] S603: Controls the target device to execute the device task operation process.

[0135] In this embodiment, the control module controls the target device to perform device task operation processes without relying on the target device's native private control interface. Instead, it controls the target device by simulating standardized atomic actions such as mouse clicks, keyboard input, interface control operations, and system calls.

[0136] In this embodiment, the control modules of each device in the device end can follow the same set of standardized input protocols and present completely consistent interactive interfaces to the control end. As a result, the control end does not need to be aware of the differences in the native protocols of different brands and models of devices. It only needs to send out task operation requests in a unified format to complete the scheduling. This supports the normalization goal of "develop once, run on multiple terminals" from the device end, fundamentally reducing the complexity of the task execution system.

[0137] In some exemplary embodiments, please refer to Figure 7 Step S603 involves controlling the target device to execute the device task operation process, including steps S701 and S702.

[0138] S701: Obtain the target action instructions in the device task operation process, as well as the logical order between the target action instructions.

[0139] In the application, after the control module completes the parsing and verification of the task operation request, it can extract the identifiers, parameter configurations, and logical order of all target action instructions from the structured device task operation process, and decompose the complete task into independent atomic execution units (i.e., target action instructions), providing a basis for subsequent instruction loading and execution.

[0140] S702: The control device body executes the target action instructions in logical order.

[0141] After the control software obtains the target action command, it can load the control program corresponding to the target action command in a logical order to control the device to execute the task command.

[0142] In some examples, the control module can be configured with a set of instruction actions, which stores control programs corresponding to multiple standard action instructions. The control module can first query the instruction action set to obtain the control program corresponding to a target action instruction. If no matching control program is found in the instruction action set, the control module can search for and load the corresponding control program from the external file system according to the preset instruction file loading path in the local configuration file. Then, the control module can sequentially call the control programs corresponding to each target action instruction to drive the device to perform operations, ultimately completing the entire production task.

[0143] In this embodiment, the updates of standard action instructions and the version upgrades of the control module can be decoupled. When adding new standard action instructions, optimizing their logic, or adapting to different equipment requirements, only the instruction files in the external path need to be updated. This eliminates the need for a full upgrade of the equipment-side control software or for halting production for software reinstallation and debugging, reducing production line downtime and maintenance time, and lowering the workload and risks associated with version upgrades. Simultaneously, different devices can be configured with dedicated external instruction sets as needed, while common instructions reuse the built-in version, avoiding maintenance redundancy caused by full-scale custom development. Furthermore, the storage, loading, and update logic of the control program corresponding to the standard action instructions can be completely enclosed within the equipment-side control module, making it completely transparent to the upper-level control scheduling system. The control end only needs to issue a standardized instruction sequence in a unified format, without needing to be aware of the instruction storage methods, loading paths, and implementation details of different devices, thus maintaining the universality and purity of the scheduling logic. This mechanism can support the differentiated execution needs of underlying devices without disrupting the core architecture of "upper-level standardized scheduling," allowing the system to combine unified standards with deployment flexibility.

[0144] In some exemplary embodiments, please refer to Figure 8 Step S602: The task operation request is in message format. Parse the task operation request and determine the device task operation process, including steps S801 to S803.

[0145] S801: Parse the task operation request and obtain the task operation information.

[0146] The task operation information includes a message header field, a data length field, a data payload field, and a checksum field; the data payload field is used to indicate at least part of the device task operation process, and the data length field is used to indicate the length of the data payload.

[0147] In some examples, to address the issues of excessively long complete device task operation data and unstable single transmissions, this application can employ a packet-based transmission mechanism, which involves splitting the complete task operation request into at least one task operation sub-request. The task operation sub-request is in message format and may include a message header field, a data length field, a data payload field, and a checksum field.

[0148] The message header field is the starting identifier of the task operation sub-request, serving as both a frame synchronization and protocol version identifier. The data length field records the actual byte length of the data payload in this sub-request, used by the control module to predict data volume and verify the completeness of received data, providing a baseline for subsequent content integrity verification. The data payload field is the core business carrier of the message, carrying part or all of the device task operation process data. The checksum field is a check value (e.g., CRC checksum) generated based on the message body content, serving as the basis for verifying data legality and integrity, used to verify whether bit errors, content tampering, or data loss have occurred during network transmission.

[0149] A task operation subrequest's data payload field indicates at least a portion of the device task operation flow; all data payload fields in a task operation subrequest indicate the entire device task operation flow. A task operation subrequest's data length field indicates the length of the data payload fields within that task operation subrequest.

[0150] In one example, within a task operation sub-request, the header field is 4 bytes, the data length field is 4 bytes, the data payload field is 512 bytes, and the checksum field is 2 bytes. It is understood that the byte counts of the above fields are for illustrative purposes only, and this application does not impose any limitations on them.

[0151] S802: Verify the task operation information and obtain the verification result.

[0152] In some examples, the verification process includes at least one of the following:

[0153] Perform integrity checks on task operation information based on the data length field;

[0154] The identity of the task operation information is verified based on the verification code field.

[0155] Perform content integrity verification on the data payload field based on the data length field.

[0156] The integrity check involves examining each sub-request within the task operation request to ensure it contains all required fields (header fields, data length field, data payload field, and checksum field) and that the format and length of each field conform to the protocol specifications. If each sub-request contains all required fields and the format and length of each field conform to the protocol specifications, the integrity check passes.

[0157] The identity verification process involves the control module recalculating a checksum for each sub-request within the task operation request, based on the received sub-request body, and comparing it with the checksum field in that sub-request. If the two values ​​do not match, it indicates that data errors, tampering, or packet loss occurred during transmission. The frame can be discarded, and an error message can be sent back to the control terminal, preventing erroneous commands from being executed by the device at the source. If the checksum of each sub-request matches the corresponding checksum field, the identity verification passes.

[0158] The content integrity check compares the number of bytes in the actual received data payload field with the declared length value in the data length field to determine if there is any data truncation or redundant data, further ensuring the integrity and accuracy of the payload content. If the number of bytes in the data payload field of each task operation sub-request matches the declared length value in the corresponding data length field, the content integrity check passes.

[0159] S803: If the verification result is successful, determine the device task operation process based on the task operation information.

[0160] When the verification process includes the above-mentioned integrity verification, identity verification, and content integrity verification, a verification result of "pass" means that the integrity verification, identity verification, and content integrity verification all pass.

[0161] If the verification result is unsuccessful, the control module can send an error message to the control terminal, which may include the reason for the verification failure.

[0162] In some exemplary embodiments, the control module can provide real-time feedback on the execution progress and status to the control terminal during the execution of task instructions by the control device. For example, a status code mechanism can be used, where code=0 indicates normal execution, code=1 indicates an execution error, and code=2 indicates execution in progress, and detailed error information can be returned.

[0163] In a detailed embodiment, the architecture of the task execution system needs to be built first. Specifically, standard action instructions are developed first, categorized into interface operation instructions, image recognition instructions, system operation instructions, communication interaction instructions, and script extension instructions. Each instruction module implements a specific type of atomic operation. For example, interface operation instructions may include standard action instructions such as control handle operations, mouse clicks, and keyboard input; image recognition instructions may include standard action instructions such as optical character recognition and image feature matching; system operation instructions may include standard action instructions such as file read / write, process management, and registry operations; communication interaction instructions may include standard action instructions such as network communication, serial communication, and message queues; and script execution instructions may include standard action instructions such as custom script language execution and business logic orchestration.

[0164] Secondly, a control module is deployed on the device side, with each device having its own control module installed. The control module integrates the following core units: a communication unit, a command scheduling unit, a command action set, and a software configuration parsing unit. The communication unit is responsible for establishing a connection with the MCS, receiving operation flow commands, and returning execution results. The command scheduling unit loads and schedules the control program corresponding to the standard action command based on the command type; the command action set stores the control program corresponding to each standard action command. The software configuration parsing unit reads and parses the software configuration file to obtain configuration information such as command paths and communication parameters.

[0165] Next, a standard action instruction library and a communication protocol adaptation layer are set up on the control module (MCS). The standard action instruction library is responsible for maintaining standard action instructions, the logical order between standard action instructions, and instruction version management; the communication protocol adaptation layer is responsible for converting standard instructions into task operation request messages of the control module's specific protocol.

[0166] Please see Figure 9 When the control terminal MCS receives the production task information, the control terminal performs task verification processing based on the equipment type and task instruction name in the production task information: whether the communication configuration of the device has been configured, including IP address, port number, communication protocol type, etc.; whether the standard action instructions corresponding to the task instruction have been defined in the standard action instruction library; and whether the configuration information required by the task instruction is complete, including at least the required parameters.

[0167] If verification is successful, the control unit retrieves the target action instructions from the standard action instruction library based on the equipment type and task instruction name in the production task information. It then generates an initial task operation flow according to the logical order of these target action instructions and generates the equipment task operation flow based on the task parameter information. In one example, the equipment task operation flow includes information such as the flow name, applicable equipment type, instruction sequence, parameter configuration, and error handling strategy.

[0168] Then, the control terminal communication protocol translates the device operation process into task operation requests that the control module can recognize. In one example, this application defines a standardized communication protocol structure as follows: The complete command structure consists of a start signal, a text command, an end message, and an execution status detection. Each command must provide a response confirmation after execution. The command field definition includes a message header field (4 bytes), a data length field (4 bytes), a data payload field (512 bytes), and a checksum field (2 bytes). The response mechanism adopts a status code mechanism, where code=0 indicates normal execution, code=1 indicates abnormal execution, and code=2 indicates execution in progress. Detailed error information is supported. Data is transmitted in packets: the text command sends the entire operation process data, which is relatively long. The text data payload will be split into 512-byte segments, meaning the maximum length of the text command is 522 bytes (including a 4-byte message header + a 4-byte data length + a 2-byte checksum).

[0169] The control module receives and verifies task operation requests, including integrity checks, identity verification, and content integrity checks. If the verification passes, the control module parses the task operation request, extracts each standard action instruction and its parameter configuration, and loads the corresponding control program. The control module executes each standard action instruction sequentially according to the operation flow steps and returns the execution results to the MCS in real time. The execution results include: current step status, execution progress, error messages (if any), and business data (such as test results). Upon receiving the results, the MCS updates the task status and sends the final result back to the MES after all steps have been executed.

[0170] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0171] Based on the same inventive concept, this application also provides a task execution apparatus for implementing the task execution method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more task execution apparatus embodiments provided below can be found in the limitations of the task execution method described above, and will not be repeated here.

[0172] In some exemplary embodiments, this application provides a task execution device applied to a control terminal; the device includes:

[0173] The equipment control module is used to generate equipment task operation procedures based on the received production task information and the preset standard action instruction library. The production task information includes the equipment type of the target equipment, the task name of the corresponding task instruction, and the standard action instruction library includes multiple standard action instructions, as well as the mapping relationship between equipment type, task name and each standard action instruction.

[0174] The communication protocol adaptation module is used to perform format conversion processing on the device task operation process according to the preset communication protocol to obtain the task operation request; the communication protocol of the task operation request is consistent with the communication protocol of the control module in the target device.

[0175] The device control driver module is used to send task operation requests to the control module of the target device, so that the control module controls the target device to execute the task operation request.

[0176] In some exemplary embodiments, this application provides a task execution device applied to the control module of a target device in a device terminal; the device includes:

[0177] The request receiving module is used to receive task operation requests; the task operation request is determined and sent by the control terminal executing the task execution method in any of the above embodiments.

[0178] The request parsing module is used to parse task operation requests and determine the device task operation process;

[0179] The task execution module is used to control the target device to perform the device task operation process.

[0180] In some exemplary embodiments, this application provides a task execution system, including a control terminal and a device terminal. The device terminal includes at least one device, which includes a control module and a device body. The control terminal is used to execute the steps of the task execution method executed by the control terminal in any of the above embodiments, and the device terminal is used to execute the steps of the task execution method executed by the control module of the target device in the device terminal in any of the above embodiments.

[0181] Each module in the aforementioned task execution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0182] In some exemplary embodiments, this application provides a computer device including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the task execution method applied to the control end in any of the above embodiments or the steps of the task execution method applied to the control module of the target device in any of the above embodiments.

[0183] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a task execution method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0184] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0185] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the task execution method applied to the control end in any of the above embodiments, or implements the steps of the task execution method applied to the control module of the target device in any of the above embodiments.

[0186] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the task execution method applied to a control terminal in any of the above embodiments, or implements the steps of the task execution method applied to a control module of a target device in any of the above embodiments.

[0187] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0188] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0189] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0190] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A task execution method, characterized in that, Applied to the control terminal; the method includes: Based on the received production task information and the preset standard action instruction library, a device task operation process is generated; the standard action instruction library includes multiple standard action instructions, as well as the mapping relationship between the production task information and each of the standard action instructions; The device task operation process is format-converted according to a preset communication protocol to obtain a task operation request; the communication protocol of the task operation request is consistent with the communication protocol of the control module in the target device. The task operation request is sent to the control module of the target device, so that the control module controls the target device to execute the task operation request.

2. The method according to claim 1, characterized in that, The production task information includes the equipment type of the target equipment, the task name of the task instruction corresponding to the target equipment, and the task parameter information of the task instruction corresponding to the target equipment; The step of generating equipment task operation procedures based on received production task information and a preset standard action instruction library includes: Based on the device type and the task name, at least one target action instruction is obtained from the standard action instruction library; the target action instruction is one of multiple standard action instructions. Generate an initial task operation flow based on at least one of the target action instructions; The device task operation process is generated based on the task parameter information and the initial task operation process.

3. The method according to claim 2, characterized in that, The standard action instruction library also includes the logical order between the standard action instructions; when there are multiple target action instructions, generating an initial task operation flow based on at least one target action instruction includes: Based on the standard action instruction library, determine the logical order among the multiple target action instructions; The initial task operation flow is generated based on the logical order among the multiple target action instructions.

4. The method according to claim 1, characterized in that, The standard action instruction library is also used to store the communication configuration information of the control module in the target device. Each standard action instruction includes mandatory parameters. The production task information includes the device type of the target device, the task name of the task instruction corresponding to the target device, and the task parameter information of the task instruction corresponding to the target device. The step of generating equipment task operation procedures based on received production task information and a preset standard action instruction library includes: Receive the production task information; Based on the production task information, the standard action instruction library is subjected to a first task verification process to obtain a first verification result; The production task information is subjected to a second task verification process based on the standard action instruction library to obtain a second verification result. If both the first verification result and the second verification result are verified as passed, the equipment task operation process is generated according to the standard action instruction library and the production task information. The first task verification process includes at least one of the following: Verify whether the standard action instruction library includes the standard action instruction corresponding to the production task information; Verify whether the standard action instruction library includes the communication configuration information corresponding to the control module; The second task verification process includes: verifying whether the task parameter information includes the required parameters of the standard action command corresponding to the device type and the task name.

5. The method according to claim 1, characterized in that, The production task information includes the equipment type of the target equipment and the task name of the task instruction corresponding to the target equipment; the standard action instruction library includes the equipment type, the task name, and the mapping relationship between each of the standard action instructions.

6. A task execution method, characterized in that, A control module applied to a target device in a device; the method includes: Receive a task operation request; the task operation request is determined and sent by the control terminal by executing the method described in any one of claims 1 to 5; Analyze the task operation request to determine the device task operation process; Control the device body of the target device to execute the device task operation process.

7. The method according to claim 6, characterized in that, The process of controlling the device body of the target device to execute the device task operation includes: Obtain the target action instructions in the device task operation process, as well as the logical order between the target action instructions; The device body is controlled to execute the target action instructions in the logical order.

8. The method according to claim 6, characterized in that, The task operation request is in message format. Parsing the task operation request to determine the device task operation flow includes: The task operation request is parsed to obtain task operation information; the task operation information includes a message header field, a data length field, a data payload field, and a checksum field; the data payload field is used to indicate at least part of the device task operation process, and the data length field is used to indicate the length of the data payload; The task operation information is verified to obtain the verification result; If the verification result is successful, the device task operation process is determined based on the task operation information. The verification process includes at least one of the following: The integrity of the task operation information is verified based on the data length field. The identity of the task operation information is verified based on the verification code field. The data payload field is validated for content integrity based on the data length field.

9. A task execution device, characterized in that, Applied to the control terminal; the device includes: The equipment control module is used to generate equipment task operation procedures based on the received production task information and the preset standard action instruction library. The production task information includes the equipment type of the target equipment, the task name of the task instruction corresponding to the target equipment, and the standard action instruction library includes multiple standard action instructions, as well as the mapping relationship between the equipment type, the task name and each of the standard action instructions. A communication protocol adaptation module is used to perform format conversion processing on the device task operation process according to a preset communication protocol to obtain a task operation request; the communication protocol of the task operation request is consistent with the communication protocol of the control module in the target device. The device control driver module is used to send the task operation request to the control module of the target device, so that the control module controls the target device to execute the task operation request.

10. A task execution device, characterized in that, A control module applied to a target device in a device; the device includes: A request receiving module is used to receive a task operation request; the task operation request is determined and sent by the control terminal by executing the method described in any one of claims 1 to 5; The request parsing module is used to parse the task operation request and determine the device task operation process; The task execution module is used to control the device body of the target device to execute the device task operation process.

11. A task execution system, characterized in that, It includes a control terminal and a device terminal, wherein the device terminal includes at least one device, the device including a control module and a device body; the control terminal is used to perform the steps of the method according to any one of claims 1 to 5, and the device terminal is used to perform the steps of the method according to any one of claims 6 to 8.

Images