A customized product multi-terminal configuration method and electronic device

Abstract

The application discloses a customized product multi-terminal configuration method and electronic equipment. The method is applied to a cloud server, the cloud server comprises a product configuration module, is connected with a product manufacturing terminal and a product terminal, and the method comprises the following steps: obtaining a configuration requirement, the configuration requirement comprises software configuration and hardware configuration, the hardware configuration comprises first production process parameters; based on a predefined template and a dependency relationship, the configuration requirement is analyzed and verified, and after the verification is passed, hardware configuration instructions and software configuration instructions are obtained; the hardware configuration instructions are sent to the product manufacturing terminal, and the software configuration instructions are sent to the product configuration module, the hardware configuration instructions are used for instructing the product manufacturing terminal to execute production operations according to the first production process parameters, and the software configuration instructions are used for instructing the product configuration module to execute configuration deployment operations. The application uniformly processes software, hardware and process parameters, automatically sends production instructions and deploys software, and manual intervention is not needed.

Description

Technical Field

[0001] This invention relates to the field of computer configuration management technology, and in particular to a customized product multi-terminal configuration method and electronic device. Background Technology

[0002] In related technologies, multi-tenant terminal products often require customization. However, the multi-terminal configuration management of customized products suffers from problems such as scattered configurations, excessive manual operation, limited verification capabilities, and the need for manual issuance of production instructions. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a customized product automatic configuration method and electronic device to realize the automatic generation, dynamic deployment and production linkage of end-to-end product configuration.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for configuring customized products across multiple terminals, characterized in that it is applied to a cloud server, the cloud service including a product configuration module, the cloud server connecting the product manufacturing end and the product terminal, the method comprising: Obtain configuration requirements, which include software configuration and hardware configuration, and the hardware configuration includes first production process parameters; Based on predefined templates and dependencies, the configuration requirements are parsed and verified. After the verification is passed, hardware configuration instructions and software configuration instructions are obtained. The hardware configuration instruction is sent to the product manufacturing end, and the software configuration instruction is sent to the product configuration module. The hardware configuration instruction is used to instruct the product manufacturing end to perform production operations according to the first production process parameters, and the software configuration instruction is used to instruct the product configuration module to perform configuration deployment operations.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the aforementioned customized product multi-terminal configuration method.

[0006] The beneficial effects of this invention are as follows: By acquiring configuration requirements including software configuration, hardware configuration, and first production process parameters, and parsing and verifying these requirements based on predefined templates and dependencies, hardware configuration instructions and software configuration instructions are obtained after successful verification. This achieves unified processing of software, hardware, and process parameters, avoiding inconsistencies caused by decentralized configuration, reducing manual intervention, and improving configuration efficiency. By sending hardware configuration instructions to the product manufacturing end and software configuration instructions to the product configuration module, the hardware configuration instructions instruct the product manufacturing end to perform production operations according to the first production process parameters, while the software configuration instructions instruct the product configuration module to perform configuration deployment operations. This achieves automatic issuance of production instructions and automatic deployment of software configurations. Production integration can be completed without restarting the system or requiring manual intervention, forming an automated process from configuration acquisition, parsing and verification to instruction issuance, effectively ensuring the stability and reliability of automated product configuration generation and deployment. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a customized product multi-terminal configuration method provided in this embodiment of the invention; Figure 2 A closed-loop flowchart of a customized product multi-terminal configuration method provided in an embodiment of the present invention; Figure 3 This is an application flowchart of a customized product multi-terminal configuration method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by 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 are not intended to limit the scope of this application.

[0009] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0010] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0011] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0012] In related technologies, the configuration management of multi-tenant terminal products is usually handled by independent systems that handle software configuration, hardware configuration, and production process parameters separately. For example, the cloud configuration system only handles the version and parameters of the terminal software, the factory manufacturing system only handles the hardware bill of materials and production process, and the terminal management system only handles device registration and status monitoring. The lack of a unified modeling and collaboration mechanism between these systems can easily lead to inconsistencies in configuration between different systems. For example, the software version distributed from the cloud may not match the firmware version pre-installed in the factory, or the hardware functions required by the terminal may conflict with the production process parameters.

[0013] For example, after a product is manufactured, there may be many different users, each with their own customization needs. These customizations include product appearance (e.g., casing color, silkscreen logo), backend cloud server interface (e.g., interface style, functional module layout), and terminal software customization (e.g., application icons, function menus). However, product configuration generation in related technologies mainly relies on manual processing. Configurators must select each parameter one by one and ensure compatibility. When complex dependencies exist between configuration items—for example, a product appearance corresponds to a specific hardware bill of materials, which in turn determines the production process parameters and software function set—manual configuration struggles to ensure that each configuration item is generated in the correct order. This results in low configuration efficiency, a high risk of errors, and an inability to efficiently meet the diverse customization needs of multiple users.

[0014] Furthermore, the configuration verification mechanisms in related technologies are relatively simple, typically only verifying software or hardware configurations individually, lacking comprehensive verification capabilities across software, hardware, and production processes, and failing to effectively detect compatibility issues and resource conflicts; production instructions need to be manually generated based on the configuration results and sent to the production line, resulting in low integration efficiency and susceptibility to human error leading to instruction errors; software configuration updates usually require a system restart to take effect, affecting business continuity; and there is a lack of effective rollback and compensation mechanisms after configuration changes, making it difficult to ensure consistency between system configuration records and physical terminal states when configuration errors or production anomalies occur.

[0015] To address the aforementioned problems, this invention provides a customized multi-terminal configuration method and electronic device. The customized multi-terminal configuration method of this invention can be used for the unified management and automated deployment of software configuration, hardware configuration, and production process parameters of terminal products in a multi-tenant environment. The cloud server in this application can be a terminal management system server or other servers with configuration management and command issuance functions, such as a cloud server with a product configuration module deployed thereon.

[0016] The following describes in detail a customized product multi-terminal configuration method of the present invention, with reference to the appendix. Figure 1 This method is applied to a cloud server, which includes a product configuration module. The cloud server connects to the product manufacturing end and the product terminal. The product manufacturing end may include a factory production management system (such as a factory digital factory management platform system) for executing manufacturing operations such as hardware production, process processing, and assembly of terminal equipment. The product terminal corresponds to a payment terminal such as a POS device, used to receive and apply software configuration to realize the functional deployment and operation of the equipment. The method includes steps 110 to 130.

[0017] Step 110: Obtain configuration requirements, which include software and hardware configurations. The hardware configuration includes the first production process parameters.

[0018] For example, in the scenario of customizing a white-label POS for a chain supermarket, the supermarket operator selects the required software configuration (such as UI theme, payment module, function switch, etc.) and hardware configuration (such as model, shell color, button layout, interface configuration, etc.) through the configuration interface of the TMS system. Among them, the hardware configuration also includes the first production process parameters (such as anti-oil coating, remote key injection parameters, material batch number, etc.), and the system obtains the above configuration requirements as the initial input.

[0019] Step 120: Based on the predefined template and dependencies, the configuration requirements are parsed and validated. After the validation is passed, hardware configuration instructions and software configuration instructions are obtained.

[0020] For example, the system instantiates and resolves configuration requirements based on predefined atomic and composite templates and through dependency relationships, and performs multi-dimensional verification, including software and hardware compatibility verification, hardware and manufacturing process parameter matching verification, and resource conflict detection. After successful verification, the system compiles the hardware configuration and manufacturing process parameters into hardware configuration instructions that conform to the product manufacturing specifications, and compiles the software configuration into software configuration instructions.

[0021] Step 130: Send hardware configuration instructions to the product manufacturing end and software configuration instructions to the product configuration module. The hardware configuration instructions are used to instruct the product manufacturing end to perform production operations according to the first production process parameters, and the software configuration instructions are used to instruct the product configuration module to perform configuration deployment operations.

[0022] For example, the system sends hardware configuration instructions to the product manufacturing end via a secure transmission protocol or enterprise service bus. These instructions include the terminal serial number segment, hardware bill of materials identifier, remote key injection parameters, and special process codes. The product manufacturing end executes automated production operations based on the first production process parameters in the instructions, including assembling according to specified shell colors and button layouts, performing key injection according to the remote key injection parameters, and performing coating processes according to the anti-oil coating code. Simultaneously, the system sends software configuration instructions to the product configuration module's runtime environment via a hot-loading mechanism. The product configuration module performs configuration deployment operations, including dynamically adjusting the software configuration according to production process requirements and selectively loading based on configuration version differences, completing the configuration deployment operation without restarting the service instance.

[0023] In this way, by acquiring configuration requirements including software configuration, hardware configuration, and the first production process parameters, and parsing and verifying them based on predefined templates and dependencies, hardware configuration instructions and software configuration instructions are obtained after successful verification. This achieves unified processing of software, hardware, and process parameters, avoiding inconsistencies caused by decentralized configuration, reducing manual intervention, and improving configuration efficiency and accuracy. By sending hardware configuration instructions to the product manufacturing end and software configuration instructions to the product configuration module, the hardware configuration instructions are used to instruct the product manufacturing end to perform production operations according to the first production process parameters, and the software configuration instructions are used to instruct the product configuration module to perform configuration deployment operations according to the first production process parameters. This achieves automatic issuance of production instructions and automatic deployment of software configurations, completing production integration without manual intervention. It forms an automated process from configuration acquisition, parsing and verification to instruction generation and issuance, effectively ensuring the stability and reliability of multi-terminal configuration of customized products.

[0024] In one embodiment of this application, step 120 parses the configuration requirements based on predefined templates and dependencies, including steps 210 to 240.

[0025] Step 210: Obtain the nodes in the dependency relationship and the dependency edges between each node. Each node corresponds to a configuration item in the configuration requirement. For example, refer to... Figure 2 The system obtains the dependency relationships described by a directed acyclic graph. Each node in the graph represents a configuration item, such as node N1 corresponding to the chip model, node N2 corresponding to the remote key injection method, node N3 corresponding to the security certificate, node N4 corresponding to the screen type, node N5 corresponding to the UI theme, node N6 corresponding to the shell color, and node N7 corresponding to the anti-oil coating. The directed edges between nodes represent the dependency relationships, such as N2 depending on N1 (remote key injection method depends on chip model), N3 depending on N2 (security certificate depends on remote key injection method), N5 depending on N4 (UI theme depends on screen type), and N7 depending on N6 (anti-oil coating depends on shell color).

[0026] Step 220: Traverse each node according to the topological relationship between them. When traversing to a target node, check whether the configuration items corresponding to the predecessor nodes that the target node depends on have been generated. For example, the system follows... Figure 2 The nodes are traversed in the order of their dependencies. When node N2 is reached, it is checked whether the chip model configuration item corresponding to its predecessor node N1 has been generated. When node N3 is reached, it is checked whether the remote key injection method configuration item corresponding to its predecessor node N2 has been generated. When node N5 is reached, it is checked whether the screen type configuration item corresponding to its predecessor node N4 has been generated.

[0027] Step 230: If the configuration items for all dependent predecessor nodes have been generated, then generate the configuration items for the target node based on the template corresponding to the target node. For example, refer to... Figure 2During the traversal process, once it is confirmed that all the predecessor nodes that the target node depends on have been generated, the system will instantiate and generate its configuration items according to the template corresponding to the target node. Specifically: If the chip model corresponding to the front-end node N1 has been generated, the system obtains the remote key injection method template corresponding to node N2, and instantiates and generates the configuration item for N2 based on the chip model parameters of N1 (e.g., selecting the RKI_V2 injection method compatible with the chip); if the remote key injection method corresponding to the front-end node N2 has been generated, the system obtains the security certificate template corresponding to node N3, and instantiates and generates the configuration item for N3 based on the injection method determined by N2 (e.g., generating the corresponding security certificate parameters); if the screen type corresponding to the front-end node N4 has been generated, the system obtains the UI theme corresponding to node N5, and instantiates and generates the configuration item for N5 based on the dual-screen configuration of N4 (e.g., selecting a dark theme adapted for dual-screen display); if the shell color corresponding to the front-end node N6 has been generated, the system obtains the anti-oil coating template corresponding to node N7, and instantiates and generates the configuration item for N7 based on the red shell parameters of N6 (e.g., selecting an anti-oil coating formula compatible with the red shell). The generation of each configuration item is based on the generation results of its front-end node, ensuring parameter transfer and compatibility between configuration items.

[0028] Step 240: If there are incomplete predecessor nodes, the configuration items for the current target node will be generated only after all predecessor nodes have been generated. For example, if when traversing to node N2, it is found that its predecessor node N1 has not been generated, the system will wait for node N1 to be generated before continuing to generate the configuration items for node N2; if the predecessor node N2 of node N3 has not been generated, the system will wait for node N2 to be generated before generating node N3; if the predecessor node N6 of node N7 has not been generated, the system will wait for node N6 to be generated before generating node N7.

[0029] In this way, by using the dependency relationships described by the directed acyclic graph, each configuration item is generated sequentially in topological order, ensuring that the conditions that each configuration item depends on are ready when it is generated. This achieves automatic dependency resolution and order control between configuration items, avoids configuration errors caused by improper handling of dependency relationships during manual configuration, and improves the accuracy and reliability of configuration generation.

[0030] In one embodiment of this application, step 120 verifies the configuration requirements, including steps 310 to 340.

[0031] Step 310: Verify the compatibility between software and hardware configurations. For example, the system verifies whether the user-selected UI theme and shell color scheme meet the preset accessibility standards, ensuring that the generated interface remains clear and usable under different hardware configurations; at the same time, it verifies the compatibility between the payment module and the selected hardware interface, ensuring that the function switches match the hardware capabilities.

[0032] Step 320: Verify the compatibility between the first manufacturing process parameters in the hardware configuration and the preset second manufacturing process parameters. For example, the system verifies whether the chip model on which the remote key injection method depends meets the requirements, verifies the compatibility between the anti-oil coating and the paint color of the casing, and ensures that the manufacturing process parameters in the hardware configuration conform to the preset second manufacturing process parameters to avoid production abnormalities due to parameter mismatch.

[0033] Step 330: Verify whether there are resource conflicts in the software and hardware configurations. For example, the system checks whether the terminal identifier has been used by another tenant, whether the certificate number is duplicated, whether the production batch number conflicts, and whether there is resource contention between software function switches and hardware capabilities, ensuring that there are no conflicts in resource usage between the configuration items.

[0034] Step 340: If all checks pass, the multi-dimensional checks are confirmed to be successful. For example, when the compatibility check, matching check, and resource conflict detection all pass, the system confirms that the current configuration requirement parsing and check have passed, allowing the subsequent instruction generation and issuance steps to continue; if any check fails, the system outputs the check result and triggers configuration adjustment, automatically recommending alternative configuration schemes or process parameters.

[0035] In this way, by comprehensively verifying the compatibility between software and hardware configurations, the matching between production process parameters in hardware configurations and preset process standards, and resource conflicts between software and hardware configurations, a multi-dimensional verification capability across software, hardware, and processes is achieved. This enables timely detection and handling of problems when verification fails, effectively improving the accuracy and reliability of configuration and avoiding production failures caused by configuration errors.

[0036] In one embodiment of this application, step 130 sends hardware configuration instructions to the product manufacturing end, including steps 410 to 430.

[0037] Step 410: Compile the verified hardware configuration and second production process parameters according to the interface specifications supported by the product manufacturing end to generate an instruction file that conforms to the specifications of the production execution end. For example, the system compiles the verified hardware configuration (e.g., model, casing color, button layout, interface configuration) and production process parameters (e.g., remote key injection parameters, anti-oil coating code, material batch number) according to the interface specifications supported by the product manufacturing end MES (Manufacturing Execution System) to generate an instruction file that conforms to the MES system specifications. The instruction file adopts JSON (JavaScript Object Notation) or XML (Extensible Markup Language) format and includes information such as terminal serial number segment, hardware bill of materials identifier, remote key injection server address, and special process code.

[0038] Step 420: Send the instruction file to the product manufacturing end through a preset transmission channel. For example, the system sends the compiled instruction file to the MES system at the product manufacturing end through a secure transmission protocol or enterprise service bus, ensuring the security and reliability of the instruction file during transmission, while supporting breakpoint resumption and transmission failure retry mechanisms.

[0039] Step 430: Receive confirmation status from the product manufacturing end. For example, the system receives a confirmation status of instruction reception from the MES system at the product manufacturing end. The confirmation status includes a successful instruction reception status or a failure reason code. After receiving the instruction file, the MES system performs preliminary verification on the instruction format and content, and sends the verification result back to the system in the form of a confirmation status. The system determines whether the instruction has been successfully delivered and can be correctly parsed by the production execution end based on the confirmation status.

[0040] In this way, by compiling the verified hardware configuration and production process parameters into instruction files according to the interface specifications supported by the product manufacturing end, and sending them to the product manufacturing end through a preset secure transmission channel, while receiving the confirmation status returned by the product manufacturing end, the automatic compilation, secure sending and receiving of production instructions are realized. Production docking can be completed without manual intervention, which improves the efficiency and accuracy of production instruction sending and reduces the risk of instruction errors caused by human error.

[0041] In one embodiment of this application, step 130 sends the software configuration instruction to the product configuration module, including steps 510 to 530.

[0042] Step 510: Obtain the differences between the currently effective software configuration version and the software configuration version to be deployed. For example, the system reads the version number of the currently effective software configuration in the running environment and compares it with the version number of the software configuration to be deployed, identifying configuration items that differ between the two versions, such as the specific changes in UI theme color scheme, payment module certificate configuration, function switch status, etc.

[0043] Step 520: Based on the differences, selectively load the changed software configurations. For example, based on the differences identified in Step 510, the system only loads the changed configuration items (such as changing the UI theme from light to dark or adding payment certificate configuration), while leaving the unchanged configuration items unchanged, thus avoiding the waste of resources and system overhead caused by full loading.

[0044] Step 530: Deploy the selectively loaded software configuration to the product configuration module using a hot-loading mechanism and generate software configuration instructions. For example, the system deploys the selectively loaded software configuration to the runtime environment of the product configuration module using a hot-loading mechanism. During the deployment process, there is no need to restart the running service instance, maintaining the continuity of business processing. After deployment, the system generates software configuration instructions, which instruct the product configuration module to perform the corresponding configuration deployment operations and feed the deployment results back to the system.

[0045] In this way, by obtaining the differences between the currently effective and the software configuration versions to be deployed, selective loading of the changed software configurations is performed based on the differences, and the software configurations are deployed to the product configuration module through a hot loading mechanism. This achieves differentiated dynamic deployment of software configurations, which can complete the configuration update without restarting the system, effectively ensuring business continuity, while avoiding the resource waste caused by full loading, and improving the efficiency and flexibility of software configuration deployment.

[0046] In one embodiment of this application, the method further includes steps 610 to 630.

[0047] Step 610: Receive execution feedback proactively pushed by the product manufacturing end. For example, at each stage of production instruction execution (e.g., instruction reception, verification passed, production start, production completion, production exception, etc.), the MES system at the product manufacturing end proactively pushes execution status updates to the system through callback interfaces, message queues, or enterprise service buses. The system receives the above execution feedback in real time to know the current execution progress of the production instructions.

[0048] Step 620: If no proactive push is received within a preset time period after sending the hardware configuration command, or if consistency verification is required, a request to query execution feedback is sent to the product manufacturing end via polling. For example, after sending the hardware configuration command, the system starts a timer. If no proactive execution feedback is received from the product manufacturing end within the first preset time period, the system proactively sends a query request to the product manufacturing end through the polling interface to obtain the latest execution status of the production command. In addition, when the system needs to verify the consistency between the configuration record and the production status, it can also proactively trigger a polling query to ensure that the states of both parties are synchronized.

[0049] Step 630: When the execution feedback does not match the current configuration requirements, a compensation mechanism is triggered. This mechanism restores consistency between the product manufacturing end and the configuration requirements. For example, the system compares the received execution feedback with the current configuration requirements. If it finds that the actual production parameters executed by the product manufacturing end are inconsistent with the configuration requirements, the system automatically triggers the compensation mechanism. This is done by performing configuration rollback, generating adjustment instructions and sending them to the product manufacturing end, etc., to bring the state of the product manufacturing end back into consistency with the configuration requirements.

[0050] In this way, by receiving execution feedback actively pushed by the product manufacturing end, and actively polling when no push is received or when consistency needs to be verified, a two-way state synchronization mechanism between the system and the product manufacturing end is realized; when the execution feedback does not match the configuration requirements, a compensation mechanism is automatically triggered, which effectively ensures the consistency between the product manufacturing end and the configuration requirements, avoids production deviations caused by information asynchrony, and improves the reliability and fault tolerance of the system.

[0051] In one embodiment of this application, step 630 triggers a compensation mechanism, including steps 640 to 660.

[0052] Step 640: Create a version identifier for this configuration change and bind the version identifier to the current software and hardware configurations. For example, when the system detects a change in configuration requirements, it generates a unique full snapshot identifier (e.g., snapshot ID) for this configuration change and associates and binds this identifier with the current software configuration version (e.g., UI theme version, payment module version) and hardware configuration version (e.g., device model, shell color code, production process parameter version), storing it in the configuration history for subsequent rollback traceability and consistency verification.

[0053] Step 650: Restore the configuration records to the state before the change by performing a local configuration rollback. For example, when the compensation mechanism is triggered, the system reads the configuration record corresponding to the full snapshot created during the last configuration change, performs a local configuration rollback operation based on the configuration record, and restores the current system-side software and hardware configuration records to the state before the change, ensuring that the system-side configuration records are consistent with the actual requirements.

[0054] Step 660: Generate adjustment instructions based on the configuration state before the change and send them to the product manufacturing end. For example, the system generates corresponding adjustment instructions based on the configuration state before the rollback, including cancellation instructions or correction instructions; if the production instructions at the product manufacturing end have not yet entered the irreversible execution stage, a cancellation instruction is generated, instructing the product manufacturing end to cancel or suspend the production of the current batch; if the production instructions have entered the irreversible execution stage (e.g., material feeding, firmware writing, or packaging process has been completed), a correction instruction is generated, including a rework identifier or firmware re-flash parameters, instructing the product manufacturing end to perform correction processing on terminals that have been produced or are being produced; the system sends the generated adjustment instructions to the product manufacturing end through a preset transmission channel.

[0055] In this way, by creating a version identifier for configuration changes and binding it to the configuration, a local configuration rollback is performed when compensation is triggered to restore the configuration record to the state before the change. An adjustment instruction is generated based on the configuration state before the change and sent to the product manufacturing end, thus achieving two-way consistency between the system side and the production side. In the event of configuration changes or production anomalies, rollback and correction can be automatically completed, effectively ensuring the final consistency between the system configuration record and the physical terminal state.

[0056] In one embodiment of this application, steps 710 and 720 are included before step 660.

[0057] Step 710: Obtain the execution progress of the previously issued hardware configuration command returned by the product manufacturing end. For example, the system obtains the execution progress of the previously issued hardware configuration command returned by the product manufacturing end through active polling or receiving active push, including the current stage of the command (e.g., command received, verification passed, in production, completed, or encountered an error), and whether it has entered the irreversible production execution stage.

[0058] Step 720: Determine whether the hardware configuration instruction has entered the irreversible execution stage based on the execution progress. For example, the system determines whether the hardware configuration instruction has entered the irreversible execution stage based on the obtained execution progress. The irreversible execution stage includes physically irreversible steps such as material feeding, firmware writing, and the start of packaging process. If the production instruction has not yet started execution or is still in the reversible stage, it is determined that it has not entered the irreversible execution stage; if it has reached the irreversible step, it is determined that it has entered the irreversible execution stage.

[0059] Step 660 includes steps 730 and 740.

[0060] Step 730: If the hardware configuration instruction has not entered the irreversible execution stage, a cancellation instruction is generated. For example, when the system determines that the previously issued hardware configuration instruction has not yet entered the irreversible execution stage, a cancellation instruction is generated. This cancellation instruction is used to instruct the product manufacturing end to cancel or suspend the production operation of the current batch to avoid continuing to execute the changed or incorrect configuration instruction.

[0061] Step 740: If the hardware configuration instruction has entered the irreversible execution stage, a correction instruction is generated. For example, when the system determines that the previously issued hardware configuration instruction has entered the irreversible execution stage, a correction instruction is generated. This correction instruction includes a rework identifier, firmware re-flash parameters, or subsequent process adjustment parameters, which are used to instruct the product manufacturing end to correct the terminals that have been produced or are being produced, ensuring that the state of the physical terminal is consistent with the changed configuration requirements.

[0062] In this way, by obtaining the execution progress of the previously issued hardware configuration instructions, it is determined whether they have entered the irreversible execution stage, and based on the determination result, either a cancellation instruction or a correction instruction is generated, thus achieving differentiated compensation processing for production instructions. Instructions that have not entered the irreversible stage are cancelled, while instructions that have entered the irreversible stage are corrected. This avoids unnecessary production interruptions and ensures the eventual consistency between the physical terminal state and configuration requirements, improving the flexibility and effectiveness of the compensation mechanism.

[0063] In one embodiment of this application, the method further includes steps 810 to 830.

[0064] Step 810: Set a timeout threshold and retry strategy for each production instruction. For example, the system sets a timeout threshold (e.g., 30 seconds, 60 seconds) and a retry strategy for each issued hardware configuration instruction. The retry strategy includes a maximum number of retries (e.g., 3 times, 5 times), a retry interval (e.g., 5 seconds between each retry), and a retry method (e.g., instruction resending or status re-query). Different production instructions can be configured with different timeout thresholds and retry strategies according to their corresponding production process complexity.

[0065] Step 820: When the expected execution feedback is not received within a preset time, a retry strategy is triggered. The retry strategy includes retransmitting the production instruction or re-querying the status. For example, after sending a hardware configuration instruction, the system starts a timer. If the expected execution feedback is not received from the product manufacturer within a preset timeout threshold, the retry strategy is automatically triggered. At this time, the system performs one of the following two processes according to the preset retry method: First, retransmitting the production instruction, i.e., the system retransmits the hardware configuration instruction, suitable for scenarios where network jitter or temporary packet loss may occur during instruction transmission; second, re-querying the status, i.e., the system does not retransmit the instruction, but actively sends a query request to the product manufacturer to obtain the latest execution status of the current production instruction, suitable for scenarios where the instruction has been successfully delivered but the feedback information is lost during the return transmission. When performing either of the above processing methods, the system records the number of retries and the time.

[0066] Step 830: When the number of retries exceeds the preset maximum number of retries in the retry strategy, the production instruction is marked as abnormal and a compensation mechanism is triggered. For example, the system continuously records the execution result of each retry. When the cumulative number of retries exceeds the preset maximum number of retries (e.g., no expected feedback is received after 3 consecutive retries), the system marks the production instruction as abnormal and automatically triggers a compensation mechanism. This mechanism handles the abnormal situation by executing configuration rollback, generating adjustment instructions, etc., and can also issue an alarm to notify the administrator for manual intervention.

[0067] In this way, by setting timeout thresholds and retry strategies for each production instruction, a retry mechanism is automatically triggered when the expected feedback is not received within a preset time. When the number of retries exceeds the maximum number of retries, an abnormal state is marked and a compensation mechanism is triggered. This achieves automatic fault tolerance and abnormal handling in the transmission and execution of production instructions, effectively improving the reliability and stability of the system and avoiding the problem of instruction loss or execution failure caused by temporary faults such as network jitter and system overload.

[0068] In summary, this application provides a customized product multi-terminal configuration method and electronic device.

[0069] This invention acquires configuration requirements including software configuration, hardware configuration, and production process parameters. Based on predefined atomic and combined templates, it performs unified modeling, achieving unified configuration management of software, hardware, and process parameters, avoiding inconsistencies caused by scattered configurations across multiple systems. Based on dependencies described by a DAG (Directed Acyclic Graph), the execution order of configuration items is generated through topological sorting, automatically generating configurations sequentially. During configuration generation, multi-dimensional verification is automatically performed, including compatibility checks between software and hardware, matching checks between production process parameters in the hardware configuration and preset process standards, and resource conflict detection for terminal identifiers, certificate numbers, and production batches. This achieves automated configuration generation and comprehensive verification, reducing manual intervention and improving configuration efficiency and accuracy. The verified hardware configurations and production process parameters are automatically compiled into instruction files conforming to production system specifications and automatically distributed to the production system via secure transmission protocols or enterprise service buses. Simultaneously, a hot-loading mechanism dynamically deploys the software configuration to the runtime environment without requiring a system restart, achieving automatic distribution of production instructions and dynamic deployment of software configurations, completing production integration without manual intervention.

[0070] Finally, by receiving execution feedback from the production system, a two-way communication mechanism combining push and polling is used to synchronize the status in real time. When an execution status anomaly is detected or the execution feedback does not match the current configuration, a compensation mechanism is triggered. The compensation mechanism first determines whether the production instruction has entered the irreversible execution stage. If it has not, a cancellation instruction is generated to cancel or suspend production; if it has, a correction instruction is generated for rectification. Through version management and consistency compensation, end-to-end consistency between system configuration records and physical terminal status is ensured.

[0071] This invention implements a complete closed-loop process, including tenant configuration input, template instantiation, DAG parsing and generation, automatic verification, instruction compilation, execution, status feedback, version control, and consistency compensation. Compared with related technologies, the improvements of this invention are: changing from distributed configuration to unified modeling, from manual configuration to automatic generation, from single verification to a unified verification mechanism, from manually generated instructions to automatic delivery, from static deployment to dynamic updates, and from single-system consistency to end-to-end consistency.

[0072] This invention effectively solves the technical problems in related technologies, such as scattered configuration, excessive manual operation, limited verification capabilities, manual issuance of production instructions, system restart required for configuration updates, and lack of rollback compensation mechanisms. It forms a closed-loop automated configuration deployment mechanism that extends from configuration acquisition, parsing and verification, instruction compilation and issuance to status feedback and consistency compensation. Combined with version management and compensation mechanisms, it achieves coordinated protection of the stability and reliability of multi-terminal configuration of customized products in multi-tenant environments, providing a reliable and efficient automated solution for product configuration management in large-scale customized production scenarios.

[0073] See attached document Figure 3 The following describes specific application examples of this application. This application can apply the above solution to scenarios with high efficiency and high consistency requirements, such as multi-tenant environments that require multi-terminal configuration of terminal products, white-label terminal customization, and large-scale production deployment, especially in commercial fields with multi-tenant differentiated configuration needs, such as chain supermarket POS terminal customization and smart hardware white-label production.

[0074] S201. The tenant inputs end-to-end configuration requirements through the TMS system's configuration interface, including software configurations (such as UI theme, payment module, function switches) and hardware configurations (such as model, casing color, button layout, interface configuration, and manufacturing process parameters). The system then loads predefined atomic templates and combined templates to prepare for subsequent configuration generation. This is equivalent to obtaining configuration requirements in step 110 and loading templates in step 120 above.

[0075] S202. The system, based on the dependencies between configuration items described by a DAG (Directed Acyclic Graph), generates the execution order of each configuration item through topological sorting and instantiates the configurations sequentially. For example, if a hardware parameter depends on a specific chip model, or a process parameter depends on a specific coating state, the system will automatically identify and ensure that the dependent items are generated first. Simultaneously with configuration generation, a unified verification engine performs multi-dimensional verification, including compatibility verification between software and hardware, matching verification between production process parameters in the hardware configuration and preset process standards, and resource conflict detection such as terminal identifiers, certificate numbers, and production batches. If the verification fails, the system automatically adjusts or recommends alternative configuration schemes; if the verification passes, the configuration is frozen and a version snapshot is generated, storing the current configuration bound to a version identifier. This is equivalent to the instantiation and dependency resolution, multi-dimensional verification and version management in step 120, and the version identifier binding in step 640.

[0076] S203. Next, the instruction compilation and distribution stage begins. The production instruction compiler compiles the verified hardware configuration and production process parameters into instruction files that conform to the MES system or supplier API specifications, supporting JSON, XML, or MES formats. The instruction file includes information such as terminal serial number segments, hardware bill of materials identifiers, remote key injection parameters, special process codes, and material batch numbers. Subsequently, the production instruction distribution module distributes the instruction file to the production system via a secure transmission protocol (such as SFTP), enterprise service bus, or API interface, ensuring the security and reliability of the instructions during transmission. This is equivalent to the hardware configuration instruction generation and distribution in step 130 above, and the instruction compilation and distribution in steps 410 to 420.

[0077] S204. After the production system executes the instruction, it enters the status feedback phase. At each stage of instruction execution, the production system actively pushes status updates to the TMS status synchronization module through callback interfaces, message queues, or the Enterprise Service Bus. The TMS status synchronization module adopts a bidirectional communication mechanism combining push and polling. It actively polls when it does not receive an active push or when consistency verification is required, while setting timeout thresholds and retry strategies to ensure reliable synchronization of status information. The system receives multi-stage status feedback in real time, including instruction reception status, verification status, execution status, completion status, and exception status. This is equivalent to the execution feedback reception and polling in steps 610 to 620 above, and the timeout thresholds and retry strategies in steps 810 to 820.

[0078] S205. When the system detects an abnormal execution status or an execution feedback that does not match the current configuration, a compensation mechanism is automatically triggered. The compensation mechanism first determines whether the previously issued production instruction has entered an irreversible execution phase, such as whether physical steps like material feeding, firmware writing, or the start of the packaging process have been completed. If it has not entered the irreversible execution phase, a cancellation instruction is generated, instructing the production system to cancel or suspend the current batch of production. If it has entered the irreversible execution phase, a correction instruction is generated, containing a rework identifier or firmware re-flash parameters, instructing the production system to correct the terminals that have already been produced or are currently being produced. Through cancellation, suspension, or correction operations, consistency confirmation is finally achieved, ensuring that the system configuration record and the physical terminal state are ultimately consistent. This is equivalent to the compensation mechanism triggering and differential instruction generation in steps 630 to 660 above, and the irreversible judgment and cancellation / correction instruction generation in steps 710 to 740.

[0079] Through the above closed-loop process, this invention achieves unified processing of software, hardware, and production process parameters, avoiding inconsistencies caused by decentralized configuration, reducing manual intervention, and improving configuration efficiency and accuracy; it realizes automatic issuance of production instructions and automatic deployment of software configurations, completing production integration without system restart or manual intervention; and through status feedback and compensation mechanisms, it ensures consistency between system configuration records and physical terminal status.

[0080] Compared with related technologies, this invention changes distributed configuration to unified modeling, manual configuration to automatic generation, single verification to a unified verification mechanism, manual command generation to automatic issuance, static deployment to dynamic updates, and single-system consistency to end-to-end consistency. It effectively solves problems such as separate management of software, hardware and production processes, low efficiency and error-prone manual configuration, lack of comprehensive verification capabilities, low efficiency of manual issuance of production commands, system restart required for configuration updates, and lack of rollback compensation mechanisms.

[0081] Taking a scenario where a company provides customized white-label POS terminals for a chain supermarket as an example, the steps include: S301. The system predefines a template for large supermarkets and hypermarkets. The hardware configuration is a dual-screen touch POS machine (including model, shell color, button layout, and interface configuration). The software configuration supports membership points and electronic invoices (including UI theme, payment module, and function switches). The manufacturing process requires an anti-oil coating and RKI (Remote Key Injection). The RKI depends on a specific security chip model and coating status, and the dependency relationship is represented by a directed edge of a DAG. The new customer "FreshMart" inputs its customization requirements through the TMS system's configuration interface, selects a red shell and its own payment channel. The system loads the predefined atomic template and combined template, describes the dependency relationship between each configuration item based on a directed acyclic graph, and generates the execution order of the configuration items through topological sorting. This is equivalent to the template loading and dependency resolution in steps 110 and 120 above.

[0082] S302. The system traverses each configuration item sequentially according to the topology. Upon reaching a target node, it checks whether the configuration items corresponding to its dependent predecessor nodes have all been generated. If all have been generated, the system generates the configuration items for that node based on the template. If any predecessor nodes have not been generated, the system waits until all predecessor nodes are generated before generating the current node's configuration items. Subsequently, the unified verification engine performs multi-dimensional verification on the generated configuration, including verifying the compatibility of the red outer shell paint and the anti-oil coating, verifying the matching of the payment certificate and the RKI process, and detecting resource conflicts such as terminal identifier, certificate number, and production batch. If the verification fails, an automatic adjustment or replacement process is triggered, recommending alternative configuration schemes or process parameters. If the verification passes, the configuration is frozen and a version snapshot is generated, storing the current configuration bound to a version identifier. This is equivalent to the instantiation and dependency resolution, multi-dimensional verification, and version management in step 120 above, and the version identifier binding in step 640.

[0083] S303. The system compiles the verified hardware configuration and production process parameters according to the interface specifications supported by the product manufacturing end, generating production instruction files (e.g., JSON or XML format) for the first batch of 1000 POS terminals. The instruction files include SKU (Stock Keeping Unit), red casing color code, payment certificate ID, RKI server address, anti-oil coating code, terminal serial number range, hardware bill of materials identifier, special process code, and material batch number. Subsequently, the production instruction distribution module distributes the instruction files to the production system (MES or supplier system) via a secure transmission protocol (e.g., SFTP or Enterprise Service Bus). This is equivalent to the hardware configuration instruction generation and distribution in step 130 and steps 410 to 420 above.

[0084] S304. During each stage of instruction execution, the production system actively pushes status updates to the TMS status synchronization module via callback interfaces, message queues, or the Enterprise Service Bus. The TMS status synchronization module employs a bidirectional communication mechanism combining push and polling. When no active push is received or consistency verification is required, it actively queries the execution status via polling, while simultaneously setting timeout thresholds and retry strategies. The system receives multi-stage status feedback in real time, including instruction reception status, verification status, execution status, completion status, and exception status. This is equivalent to the execution feedback reception and polling query in steps 610 to 620 above, and the timeout thresholds and retry strategies in steps 630 to 640.

[0085] S305. During each stage of instruction execution, the production system actively pushes status updates to the TMS status synchronization module via callback interfaces, message queues, or the Enterprise Service Bus. The TMS status synchronization module employs a two-way communication mechanism combining push and polling. When no active push is received or consistency verification is required, it actively queries the execution status via polling, while setting timeout thresholds and retry strategies. The system receives multi-stage status feedback in real time, including instruction reception status, verification status, execution status, completion status, and abnormal status. When a defect is detected in a batch of red paint, the administrator triggers a configuration rollback. The system sequentially restores the software configuration to its state before the change, sends a "pause production of this batch" instruction to the production line, and simultaneously generates and issues a "backup paint batch" correction instruction to ensure consistency across the online system, in-production terminals, and subsequent production. This is equivalent to the execution feedback reception and polling query in steps 610 to 620 above, and the compensation mechanism triggering and differentiated instruction generation in steps 630 to 660.

[0086] Through the above application examples, this invention realizes a customized multi-terminal configuration method for products, completing a closed-loop process from tenant configuration input, template loading and dependency resolution, configuration instance generation and multi-dimensional verification, production instruction compilation and issuance, multi-stage status feedback and synchronization to consistency compensation. This solution effectively solves problems in existing technologies such as scattered configuration, excessive manual operation, limited verification capabilities, manual issuance of production instructions, system restarts required for configuration updates, and lack of rollback compensation mechanisms. It achieves unified processing and automated deployment of software, hardware, and process parameters, improving configuration efficiency and accuracy, reducing manual intervention, and ensuring the stability and reliability of automated product configuration generation and deployment in a multi-tenant environment.

[0087] Please refer to Figure 4 The present invention also provides an electronic device 900, including a memory 901 and a processor 902, and a computer program stored on the memory 901 and running on the processor 902. When the processor 902 executes the computer program, it implements the various steps in the customized product multi-terminal configuration method described above.

[0088] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0089] In summary, the customized multi-terminal configuration method and electronic device provided by this invention obtains configuration requirements including software configuration, hardware configuration, and production process parameters, parses and verifies them based on predefined templates and dependencies, and generates hardware configuration instructions and software configuration instructions. This achieves unified processing of software, hardware, and process parameters, avoids inconsistencies caused by decentralized configuration, and solves the defects of traditional configuration management where software, hardware, and production processes are independent and difficult to coordinate.

[0090] By sending hardware configuration instructions to the product manufacturing end and software configuration instructions to the product configuration module, the automatic issuance of production instructions and the automatic deployment of software configuration are realized. Production integration can be completed without manual intervention, forming an automated process from configuration acquisition, parsing and verification to instruction generation and issuance. This transforms product configuration from manual operation to automated closed-loop processing, effectively improving configuration efficiency and accuracy and reducing the risk of human error.

[0091] By receiving execution feedback from the product manufacturing end and triggering a compensation mechanism when the execution feedback does not match the current configuration requirements, including configuration rollback and generating adjustment instructions, the system achieves consistency assurance between configuration records and physical terminal status. This elevates configuration management from an uncontrollable single issuance to a closed-loop process that is feedback-enabled, verifiable, and compensable. It provides a highly reliable and efficient automated solution for multi-terminal configuration of customized products in a multi-tenant environment, effectively improving the stability and reliability of product configuration.

[0092] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for configuring customized products across multiple terminals, characterized in that, Applied to a cloud server, the cloud server including a product configuration module, the cloud server connecting a product manufacturing end and a product terminal, the method includes: Obtain configuration requirements, which include software configuration and hardware configuration, and the hardware configuration includes first production process parameters; Based on predefined templates and dependencies, the configuration requirements are parsed and verified. After the verification is passed, hardware configuration instructions and software configuration instructions are obtained. The hardware configuration instruction is sent to the product manufacturing end, and the software configuration instruction is sent to the product configuration module. The hardware configuration instruction is used to instruct the product manufacturing end to perform production operations according to the first production process parameters, and the software configuration instruction is used to instruct the product configuration module to perform configuration deployment operations.

2. The method for multi-terminal configuration of customized products according to claim 1, characterized in that, The parsing of the configuration requirements based on predefined templates and dependencies includes: Obtain the nodes in the dependency relationship and the dependency edges between the nodes, where each node corresponds to a configuration item in the configuration requirement; According to the topological relationship between each node, the nodes are traversed. When a target node is traversed, it is checked whether the configuration items corresponding to the predecessor nodes that the target node depends on have been generated. If all the configuration items corresponding to the preceding nodes that are relied upon have been generated, then the configuration items of the target node are generated according to the template corresponding to the target node. If there are any incomplete preceding nodes, the configuration items for the current target node will be generated after all preceding nodes have been generated.

3. The method for multi-terminal configuration of customized products according to claim 2, characterized in that, The configuration requirements are validated, including: Verify the compatibility between the software configuration and the hardware configuration; Verify the compatibility between the first production process parameters in the hardware configuration and the preset second production process parameters; Verify whether there are any resource conflicts between the software configuration and the hardware configuration; If all verifications pass, then the multidimensional verification is confirmed to be successful.

4. The method for multi-terminal configuration of customized products according to claim 1, characterized in that, Sending the hardware configuration command to the product manufacturing end includes: The verified hardware configuration and second production process parameters are compiled according to the interface specifications supported by the product manufacturing end to generate an instruction file that conforms to the specifications of the production execution end. The instruction file is sent to the product manufacturing end through a preset transmission channel; Receive confirmation status returned by the product manufacturing end.

5. A method for configuring customized products across multiple terminals according to claim 1, characterized in that, The step of sending the software configuration command to the product configuration module includes: Obtain the difference between the version of the currently active software configuration and the version of the software configuration to be deployed; Based on the aforementioned differences, the changed software configuration is selectively loaded; The selectively loaded software configuration is deployed to the product configuration module through a hot-loading mechanism, and the software configuration instructions are generated.

6. The method for multi-terminal configuration of customized products according to claim 1, characterized in that, Also includes: Receive execution feedback actively pushed by the product manufacturing end; If no active push or consistency verification is received within a preset time period after sending the hardware configuration command, a request to query the execution feedback is sent to the product manufacturing end through polling. When the execution feedback does not match the current configuration requirements, a compensation mechanism is triggered to restore the consistency between the product manufacturing end and the configuration requirements.

7. A method for configuring customized products across multiple terminals according to claim 6, characterized in that, The triggering compensation mechanism includes: Create a version identifier for this configuration change, and bind the version identifier to the current software configuration and hardware configuration; By performing a local configuration rollback, the configuration record is restored to the configuration state before the change. An adjustment instruction is generated based on the configuration status before the change and sent to the product manufacturing end.

8. A method for configuring customized products across multiple terminals according to claim 7, characterized in that, Before generating the adjustment instruction based on the configuration state before the change and sending it to the product manufacturing end, the process also includes: Obtain the execution progress of the previously issued hardware configuration instruction returned by the product manufacturing end; Based on the execution progress, determine whether the hardware configuration instruction has entered the irreversible execution stage; The step of generating an adjustment instruction based on the configuration state before the change and sending it to the product manufacturing end includes: If the hardware configuration instructions have not entered the irreversible execution stage, a cancellation instruction is generated; If the hardware configuration instructions have entered the irreversible execution stage, then a correction instruction is generated.

9. A method for configuring customized products across multiple terminals according to claim 1, characterized in that, Also includes: Set a timeout threshold and retry strategy for each of the aforementioned production instructions; If the expected execution feedback is not received within a preset time, the retry strategy is triggered, and the retry strategy includes resending the production instruction or re-querying the status. When the number of retries exceeds the maximum number of retries preset in the retry strategy, the production instruction is marked as abnormal and the compensation mechanism is triggered.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement each step of the customized product multi-terminal configuration method according to any one of claims 1 to 9.

Images