A one-to-many dynamic host computer software implementation method

Abstract

The application discloses a one-to-many dynamic host computer software implementation method, and relates to the field of industrial automation control, which comprises the following steps: loading a basic module in response to a user input lower computer interaction request and a lower computer IP address; after loading is completed, sending a module request protocol message to the lower computer according to the lower computer IP address, and receiving lower computer feedback information; after analyzing the lower computer feedback information, obtaining a loading source code file; scheduling a loader to read the loading source code file and run a hot loading module, and when the running is successful, showing a loading interface to the user and responding to user operation information in real time to execute interaction. The technical problem that the existing host computer and lower computer interaction has poor universality, high development cost, poor flexibility and difficult maintenance is solved, and the technical effect of reducing development cost, improving software flexibility and simplifying the maintenance process is achieved by providing a universal host computer software.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of industrial automation control, in particular to a one-to-many dynamic host computer software implementation method. BACKGROUND

[0002] In the field of industrial control, the host computer plays a key role in testing, controlling, and data acquisition of the lower computer. The types of lower computers are diverse, and the functions are complex and varied, which poses a severe challenge to the development of host computer software. In the prior art, for the interaction between the host computer and the lower computer, the common method is to develop a dedicated host computer software in the form of hard coding. This method requires the development of corresponding host computer software for each type of lower computer, so that the interface and corresponding functions of the host computer for each lower computer are hard-coded. Due to the diversity of lower computers, each type of lower computer requires the development of dedicated host computer software, which significantly increases the development cost. The hard-coded host computer software has fixed functions, which is difficult to adapt to changes or extensions of lower computer functions, resulting in poor flexibility. With the update and iteration of lower computer software, the corresponding host computer software also needs to be modified accordingly, which increases the complexity and cost of maintenance.

[0003] At the present stage, in the related art, the interaction between the host computer and the lower computer has poor universality, resulting in the technical problems of high development cost, poor flexibility, and difficult maintenance. SUMMARY

[0004] The present application provides a one-to-many dynamic host computer software implementation method. After the user inputs the request and the IP address, the host computer loads the basic module, sends a request to the lower computer and receives feedback information, parses the source code file to achieve hot loading of the module through the loader, and finally displays the loading interface and responds to user operations. The technical means achieves the technical effects of providing a universal host computer software, reducing development cost, improving software flexibility, and simplifying the maintenance process.

[0005] The present application provides a one-to-many dynamic host computer software implementation method applied to a host computer, including: loading a basic module in response to a user input lower computer interaction request and a lower computer IP address; when the basic module is loaded, sending a module request protocol message to the lower computer according to the lower computer IP address, and receiving lower computer feedback information; after parsing the lower computer feedback information, obtaining a loading source code file; scheduling a loader to read the loading source code file and run the hot loading module, and when the running is successful, displaying a loading interface to the user and responding to user operation information in real time to perform interaction.

[0006] In a possible implementation, the basic module comprises at least a general module, a communication module, and a parsing module, and the following processing is performed in response to a lower machine interaction request and a lower machine IP address of a user input: when the loading of the basic module fails, a loading failure signal is fed back to the user and a loading failure log is recorded; and the loading of the basic module fails when any one of the modules of the basic module fails to load.

[0007] In a possible implementation, the following processing is performed when the basic module is loaded: the general module is loaded; when the loading of the general module fails, a loading failure signal is fed back to the user and a loading failure log is recorded; when the loading of the general module succeeds, the communication module is loaded; when the loading of the communication module fails, a loading failure signal is fed back to the user and a loading failure log is recorded; when the loading of the communication module succeeds, the parsing module is loaded; when the loading of the parsing module fails, a loading failure signal is fed back to the user and a loading failure log is recorded; and the loading of the basic module is completed when the loading of the parsing module succeeds.

[0008] In a possible implementation, the following processing is performed after the loading of the basic module is completed: a module request protocol message is sent to the lower machine according to the lower machine IP address, and lower machine feedback information is received; when the lower machine feedback information is not received or is empty within a preset time zone after the module request protocol message is sent to the lower machine according to the lower machine IP address, the module request protocol message is sent to the lower machine again according to the lower machine IP address; and when the lower machine feedback information is received and is not empty within the preset time zone after the module request protocol message is sent to the lower machine according to the lower machine IP address, a subsequent process is performed.

[0009] In a possible implementation, the lower machine feedback information comprises hot loading module serialization and hot loading source code file encryption information, and the following processing is performed after the lower machine feedback information is parsed: a first loading source code file is obtained by performing deserialization analysis on the hot loading module serialization; a second loading source code file is obtained by performing decryption on the hot loading source code file encryption information; and the first loading source code file and the second loading source code file are added to the loading source code file.

[0010] In a possible implementation, the loading source code file is in a qml source code format.

[0011] In a possible implementation, the following processing is performed after the lower machine feedback information is parsed to obtain a loading source code file: when the parsing of the lower machine feedback information fails, the module request protocol message is sent to the lower machine again according to the lower machine IP address.

[0012] In a possible implementation, the scheduling loader reads the loading source code file and runs, and performs the following processing: reading the loading source code file according to the loader; when the reading is successful, running the loading source code file; when the running is successful, the hot loading is completed and the operation interface is displayed on the host computer; when the reading fails or the running fails, recording and sending a module request protocol message to the lower computer according to the IP address of the lower computer again.

[0013] In a possible implementation, the loading interface is displayed to the user and the interaction is performed in real time in response to the user operation information, and the following processing is performed: interacting with the lower computer through a data interaction protocol, a query protocol and a control protocol; sending a module request protocol message to the lower computer according to the IP address of the lower computer through a module request protocol; and receiving the information actively reported by the lower computer through an active reporting protocol.

[0014] In a possible implementation, the scheduling loader reads the loading source code file and runs, and when the running is successful, the following processing is further performed after the loading interface is displayed to the user and the interaction is performed in real time in response to the user operation information: uninstalling the hot loading module when the user closes the host computer; and uninstalling the basic module when the hot loading module is uninstalled.

[0015] The application provides an implementation method of one-to-many dynamic host computer software, which comprises the following steps: firstly, loading a basic module in response to a lower computer interaction request and an IP address of the lower computer input by a user; secondly, sending a module request protocol message to the lower computer according to the IP address of the lower computer, and receiving feedback information of the lower computer; thirdly, obtaining a loading source code file after the feedback information of the lower computer is analyzed; fourthly, reading the loading source code file by a scheduling loader and running to complete loading of a hot loading module; and finally, displaying a loading interface to the user and performing interaction in real time in response to user operation information when the running is successful, so that the technical effects of reducing development cost, improving software flexibility and simplifying maintenance process are achieved by providing a general host computer software. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the application, the drawings of the embodiments of the application will be briefly introduced below. In the present application, a flowchart is used to illustrate the operations performed by the method according to the embodiments of the application. It should be understood that the foregoing or the following operations are not necessarily performed in sequence. On the contrary, various steps can be processed in reverse order or simultaneously according to needs. Meanwhile, other operations can be added to these processes, or a step or several steps can be removed from these processes.

[0017] Figure 1 The flowchart of the implementation method of one-to-many dynamic host computer software provided by the embodiments of the application is shown.

[0018] Figure 2 A software interaction flowchart of a one-to-many dynamic host computer software implementation method provided by an embodiment of the present application.

[0019] Figure 3 A flowchart of loading a basic module in a one-to-many dynamic host computer software implementation method provided by an embodiment of the present application.

[0020] Figure 4 A flowchart of timeout retransmission when receiving feedback information from a slave computer in a one-to-many dynamic host computer software implementation method provided by an embodiment of the present application.

[0021] Figure 5 A flowchart of retransmitting a module request protocol packet when feedback information from a slave computer fails to be parsed in a one-to-many dynamic host computer software implementation method provided by an embodiment of the present application.

[0022] Figure 6 A flowchart of a scheduler loading a loader to read a source code file and run in a one-to-many dynamic host computer software implementation method provided by an embodiment of the present application.

[0023] Figure 7 A flowchart of interaction between a host computer and a slave computer in a one-to-many dynamic host computer software implementation method provided by an embodiment of the present application.

[0024] Figure 8 A flowchart of uninstalling a module after closing a host computer software in a one-to-many dynamic host computer software implementation method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0025] The above description is only a summary of the technical solutions of the present application. In order to make the technical solutions of the present application more clear, the present application can be implemented according to the content of the description, and in order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the following specific embodiments of the present application are described.

[0026] In order to make the purposes, technical solutions and advantages of the present application more clear, the present application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0027] In the following description, "some embodiments" are referred to, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict, the term "first\second" referred to only distinguishes similar objects, and does not represent a specific order for the objects. The terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or server including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or modules not clearly listed or inherent to these processes, methods, products or devices. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as understood by those skilled in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application.

[0028] The embodiments of the present application provide a one-to-many dynamic host computer software implementation method, applied to a host computer, such as Figure 1 and Figure 2 As shown, the method comprises:

[0029] Step S100, loading a basic module in response to a user inputted slave computer interaction request and slave computer IP address.

[0030] Specifically, the host computer software first waits for user input. User input includes two parts: one is the request to interact with the slave computer (for example, starting communication, data query, etc.), and the other is the IP address (Internet Protocol address, used to uniquely identify devices on the network) of the slave computer. The slave computer refers to a device controlled or monitored by the host computer, which has a specific function or performs a specific task. When the user inputs this information through the graphical user interface (GUI) or command line interface (CLI), the host computer software will capture these inputs. Next, the host computer software will load the basic module according to the preset logic. The basic module is a collection of components in the host computer software responsible for basic communication functions, including core libraries, protocol stacks, log recorders and other components required for communication with the slave computer. These components are the basis for communication between the host computer and the slave computer, responsible for tasks such as establishing a connection, sending / receiving data, and handling errors.

[0031] In one possible implementation, the basic module includes at least a general module, a communication module, and a parsing module. In response to the user inputted slave computer interaction request and slave computer IP address, the basic module is loaded, and step S100 further comprises step S110: when the basic module fails to load, a loading failure signal is fed back to the user while recording a loading failure log; wherein the basic module fails to load if any one of the modules of the basic module fails to load.

[0032] Specifically, loading the basic modules is a crucial step in starting the host computer software and enabling interaction with the slave device. The basic modules contain components that implement the core functions of the software, such as general modules (providing basic functions required for software operation, such as data processing and interface rendering), communication modules (responsible for sending and receiving data), and parsing modules (parsing received data). When a user inputs an interaction request and the slave device's IP address through the host computer software, the host computer software needs to load these basic modules first to facilitate subsequent communication and data interaction with the slave device.

[0033] The host computer software initiates an attempt to load basic modules (general modules, communication modules, parsing modules, etc.) based on the user's input of the lower-level machine interaction request and IP address. During the loading process, the host computer software uses a built-in monitoring mechanism to check the loading status of each module in real time, including checking if the module file exists, if the file is corrupted, and if dependencies are met. If the monitoring mechanism detects that any basic module has failed to load (e.g., missing file, unmet dependencies, version incompatibility, etc.), it immediately triggers a loading failure signal. Once a loading failure is detected, the host computer software executes an error handling process, including displaying a loading failure signal to the user (e.g., displaying an error message box) and logging the loading failure. The loading failure log contains detailed information such as the name of the failed module, the reason for the failure, and the time of failure, for subsequent analysis and troubleshooting. This implementation method, by monitoring the loading status of basic modules in real time and triggering error handling processes promptly when loading fails, effectively prevents the software from crashing or entering an unstable state due to module loading failures.

[0034] like Figure 3 As shown, in one possible implementation, loading the basic module, step S110 further includes step S111, loading the general module. Specifically, the host computer software first locates the file location of the general module. The module file is loaded using an operating system API (such as LoadLibrary in Windows or dlopen in Linux). The loading result is checked; if successful, the process continues to the next step; if it fails, the process jumps to step S112.

[0035] Step S112: When the general module fails to load, a loading failure signal is sent to the user, and a loading failure log is recorded. Specifically, when the general module fails to load, a logging function (such as a log file, database, or log queue in memory) is used to record the specific reason for the loading failure (such as missing files, version incompatibility, etc.). A user-friendly error message box is displayed to the user, informing them that the general module has failed to load, suggesting possible solutions, and the software startup process is terminated.

[0036] Step S113, when the general module is loaded successfully, load the communication module; step S114, when the communication module fails to load, feedback a loading failure signal to the user and record the loading failure log; step S115, when the communication module is loaded successfully, load the analysis module; step S116, when the analysis module fails to load, feedback a loading failure signal to the user and record the loading failure log.

[0037] Specifically, these steps are similar to steps S111 and S112, but are directed to the communication module and the analysis module. The communication module is responsible for data sending and receiving, and the analysis module is responsible for analyzing the received data.

[0038] Step S117, when the analysis module is loaded successfully, the basic module is loaded. Specifically, check the loading status of all modules, if all modules are loaded successfully, enter the next step (step S200). If there is still a module that fails to load, terminate the starting process. This implementation manner can ensure that the software does not crash or become unstable due to missing or damaged modules during the starting process, and improves the reliability and stability of the software by loading each module step by step and checking the loading status of each module.

[0039] Step S200, when the basic module is loaded, send a module request protocol message to the lower machine according to the IP address of the lower machine, and receive the feedback information of the lower machine.

[0040] Specifically, after the basic module is loaded, the upper machine software will use the functions of these modules, construct and send a module request protocol message through the network according to the IP address of the lower machine provided by the user, the module request protocol message is a data packet that complies with a specific communication protocol, and is used to transfer information between devices, and contains a list of module information or functions that the upper machine hopes the lower machine to provide. After receiving this message, the lower machine will analyze the message content, and according to its own configuration and state, perform module data serialization, encryption and other operations to generate a feedback information message, which contains a list of modules supported by the lower machine, module version, state information and the like. Among them, JSON can be used as a communication protocol carrier, JSON format is simple, easy to read and write, file size is small, occupies less bandwidth, and is easy to parse, other formats such as XML can also be used.

[0041] As Figure 4As shown, in one possible implementation, after the basic module is loaded, the module request protocol message is sent to the lower machine according to the IP address of the lower machine, and the feedback information of the lower machine is received, and step S200 further includes step S210: when the module request protocol message is sent to the lower machine according to the IP address of the lower machine, if no feedback information of the lower machine is received or the feedback information of the lower machine is empty within a preset time zone, the sending of the module request protocol message to the lower machine according to the IP address of the lower machine is recorded and repeated. Specifically, after the basic module is loaded, the upper machine sends the module request protocol message according to the IP address of the lower machine, and records the sending time. The upper machine enters a waiting state, and a timer is set to monitor whether the feedback information of the lower machine is received within a specified time window (a preset time zone). If no feedback information is received within the preset time zone, or the received feedback information is empty, it is considered that the communication fails. At this time, the upper machine records this event (including the failure time, the IP address of the lower machine, the number of attempts, and the like), and when a certain retransmission condition (such as the number of retransmissions not reaching an upper limit) is met, the upper machine sends the module request protocol message according to the IP address of the lower machine again, and the above waiting and judgment process is repeated.

[0042] Step S220: when the module request protocol message is sent to the lower machine according to the IP address of the lower machine, if the feedback information of the lower machine is received within a preset time zone, and the feedback information of the lower machine is not empty, a subsequent process is performed. Specifically, when the upper machine receives the feedback information of the lower machine within the preset time zone, and the information is not empty, it is considered that the communication is successful. The upper machine analyzes the received feedback information (as described in step S300) to obtain the source code file or other necessary information. Then, the loader is dispatched to read and execute these files (as described in step S400), and finally the loading interface is displayed to the user and the user operation is responded in real time. This implementation introduces a timeout retransmission mechanism, which can ensure that the upper machine has enough opportunity to receive the feedback information of the lower machine in the case of unstable network environment or large processing delay of the lower machine, thereby avoiding the interruption of the entire process due to single communication failure, and improving the reliability of the communication.

[0043] Step S300: after the feedback information of the lower machine is analyzed, the source code file is obtained.

[0044] Specifically, after receiving the feedback information of the lower machine, the host machine software performs reverse sequence, decryption operation on the data through the analysis module, and determines the module and its source code file to be loaded according to the analysis result. These source code files can be stored locally on the host machine, or can need to be downloaded from a remote server. For the source code files stored locally, the host machine software will directly locate to the file path; for the files that need to be downloaded from the remote server, the host machine will initiate a download request through HTTP, FTP or the like, and receive the source code file returned by the server. Among them, the loading source code file is a file containing program source code, which is used for compilation and execution.

[0045] In a possible implementation, the feedback information of the lower machine includes hot loading module serialization and hot loading source code file encryption information, and after the feedback information of the lower machine is analyzed, the loading source code file is obtained, and step S300 further includes step S310, reverse sequence analysis of the hot loading module serialization is performed to obtain a first loading source code file. Specifically, in the feedback information of the lower machine, the hot loading module exists in the form of serialization. Serialization is a process of converting the state of an object into a format that can be stored or transmitted, so as to be transmitted to the host machine through a network. First, the host machine identifies the specific format used by the hot loading module serialization in the feedback information of the lower machine according to the communication protocol between the lower machine and the host machine, uses a corresponding reverse serialization tool or library, and analyzes the serialization data of the hot loading module according to the identified serialization format to reconstruct the object structure of the hot loading module in the memory. In the object after reverse serialization, the source code file content or reference related to the hot loading module is extracted. These source code files can be stored in the form of a string, or encapsulated in an object in a certain specific encoding manner. The extracted source code file content is saved to a certain location in the local or memory to form a first loading source code file.

[0046] Step S320, the hot loading source code file encryption information is decrypted to obtain a second loading source code file. Specifically, in the feedback information of the lower machine, in addition to the serialized hot loading module, the encryption information of the hot loading source code file is also included. This is to protect the source code file from being accessed by unauthorized users. The encryption information of the hot loading source code file and the key or key identification used for decryption are extracted from the feedback information of the lower machine. Among them, the key can be agreed in advance in the communication protocol between the lower machine and the host machine, or transmitted separately through a certain secure channel. According to the encryption algorithm used in the encryption information, a corresponding decryption algorithm is selected for decryption operation. The selected decryption algorithm and the key are used to decrypt the encryption information to restore the original source code file content. The decrypted source code file content is saved to the local or memory to form a second loading source code file.

[0047] Step S330: Add the first and second loaded source code files to the loaded source code file. Specifically, read the contents of the first and second loaded source code files generated in steps S310 and S320, respectively. Merge the contents of the two files according to a certain rule (such as sequential concatenation, separation by specific markers, etc.). Save the merged contents to a new file, which is the final loaded source code file. This implementation reduces the amount of data transmitted during communication and increases data security by serializing the hot-loading module and encrypting the source code file. Serialization removes redundant information from the object, transmitting only the necessary state data, thus improving communication efficiency; encryption prevents data from being intercepted or tampered with during transmission, enhancing data security.

[0048] In one possible implementation, step S330 further includes step S331, wherein the loaded source code file is in qml source code format.

[0049] Specifically, QML is a declarative programming language for describing user interfaces, allowing developers to define the behavior and appearance of UI components in an easy-to-understand and maintainable way. The first and second load source files are parsed using a QML parser or related libraries. Based on the logical relationships and dependencies between the files, the contents of the two QML files are merged into a new QML file, including copying code blocks, adjusting code structure, and handling naming conflicts. It is ensured that all references to external resources in the merged QML file are valid and that all necessary resources have been correctly loaded. The merged QML file is checked for syntax and logical errors using Qt's debugging tools or other relevant tools. The merged, resource-managed, and error-checked QML file is saved as the final load source file. This implementation uses QML as the format for load source files. QML's declarative programming approach allows developers to define the behavior and appearance of UI components more intuitively, reducing the complexity of UI development. Furthermore, as part of the Qt framework, QML has good cross-platform compatibility and can run on multiple operating systems and platforms without extensive modifications. Furthermore, qml files can be dynamically loaded and executed, which allows the host computer software to respond more flexibly to the requests and changes of the slave computer.

[0050] like Figure 5 As shown, in one possible implementation, after parsing the feedback information from the lower-level machine to obtain the source code file, step S300 further includes step S340, where if the parsing of the feedback information from the lower-level machine fails, the error is recorded and a module request protocol message is sent to the lower-level machine again according to the lower-level machine's IP address.

[0051] Specifically, when the upper computer receives the serialized data sent by the lower computer, it uses the corresponding deserialization method to restore the data into an object or data structure in memory. If an error occurs during deserialization (for example, incorrect data format, data corruption, or version incompatibility, etc.), the upper computer cannot correctly parse the first part of the load source code file. In this case, the upper computer records the deserialization failure information and re-sends the module request protocol message.

[0052] The lower computer encrypts the hot load source code file before sending it to the upper computer to protect the confidentiality of the data. The upper computer uses the correct decryption key and algorithm to decrypt the received encrypted data. If an error occurs during decryption (for example, incorrect key, algorithm mismatch, or data corruption, etc.), the upper computer cannot correctly obtain the second part of the load source code file. In this case, the upper computer also records the decryption failure information and sends the module request protocol message.

[0053] After successful deserialization and decryption, the upper computer needs to combine the obtained data into a complete source code file. If an error occurs during this process (for example, incomplete data, format mismatch, or insufficient file write permissions, etc.), the upper computer cannot generate a valid load source code file. In this case, the upper computer still re-sends the request to ensure the integrity and accuracy of the data.

[0054] When encountering any of the above failure cases, the upper computer processes according to the following flow: records detailed error information, including failure type, timestamp, possible error causes, etc. According to the pre-set retry strategy (such as maximum number of retries, retry interval, etc.) to determine whether to continue retrying. If it needs to be retried, it re-builds the module request protocol message and sets an appropriate timeout. Send a request to the lower computer through the network and wait for its response. According to the response result of the lower computer, continue to execute the subsequent parsing, deserialization, decryption and source code file generation steps. If the retry reaches the pre-set limit and still fails, further error handling measures are taken, such as displaying error messages to the user, recording serious error logs, etc.

[0055] Step S400, the scheduling loader reads the load source code file and runs to complete the loading of the hot loading module, and when the running is successful, a loading interface is displayed to the user and real-time user operation information is responded to for interaction.

[0056] Specifically, in this step, the host computer software schedules a loader component. The loader can be a parser capable of processing source code files in a specific format, or an interpreter / compiler capable of executing source code files, for reading the obtained load source code file and dynamically loading and executing the corresponding module according to the file content, that is, dynamically adding or updating functions (i.e. hot loading) without restarting the host computer software. After successful loading, the host computer will show a loading interface to the user, which includes the status of the newly loaded module, configuration options, commonly used interface controls (buttons, input / output controls, tables, tree structures, pop-up boxes, progress bars, picture controls, etc.), etc. At the same time, the host computer will listen to the user's operation information (such as clicks, inputs, etc.) in real time, and execute the corresponding interaction logic according to the information. Through the technical means of user input request and IP address, the host computer loads the basic module, sends a request to the lower computer and receives feedback information, parses the source code file to obtain the source code file, runs the source code through the loader to realize module hot loading, and finally displays the loading interface and responds to user operations, etc. The technical effects of reducing development costs, improving software flexibility, and simplifying maintenance processes are achieved by providing a general host computer software.

[0057] As shown in Figure 6 In a possible implementation, the step S400 further includes a step S410 of reading the load source code file according to the loader. Specifically, the loader is scheduled to perform a reading operation. The loader opens and reads the content of the load source code file, and the loader stores the read content in the memory for subsequent processing.

[0058] Step S420, when reading is successful, running the load source code file. Specifically, after successfully reading the load source code file, the host computer checks the integrity of the load source code file (such as checksum matching), uses an appropriate execution environment (a software framework or platform for running or interpreting the load source code file, such as a virtual machine, an interpreter or a compiler) to run the load source code file, that is, to convert the content of the load source code file into executable code, and execute these codes on the processor of the host computer.

[0059] Step S430, when running is successful, hot loading is completed and an operation interface is displayed on the host computer. Specifically, after successfully running the load source code file, the host computer dynamically integrates the newly loaded module into its running environment, including updating internal data structures, registering new functions or methods, and displaying new user interface components.

[0060] Step S440, when the reading fails or the running fails, record and send the module request protocol message to the lower machine according to the IP address of the lower machine again. Specifically, when the reading or running of the source code file fails, the upper machine will record error information, including error type, timestamp and possible error cause, and decide whether to resend the module request protocol message to the lower machine according to the preset retry strategy (such as maximum number of retries, retry interval, etc.). If it needs to be retried, the module request protocol message is reconstructed and sent to the lower machine according to the IP address of the lower machine. Wait for the response of the lower machine, and continue to execute the subsequent steps according to the response result. This implementation ensures that the user can always see a complete and responsive user interface, even if there is a problem when loading a new module, which can be handled and feedback in time.

[0061] As shown in Figure 7 In a possible implementation, the loading interface is displayed to the user and real-time user operation information is responded to perform interaction, and step S400 further includes step S450, interacting with the lower machine through a data interaction protocol, a query protocol and a control protocol. Specifically, a plurality of protocols are established between the upper machine and the lower machine to ensure that the two parties can efficiently and accurately exchange data, perform queries and control commands. Among them, the data interaction protocol defines the format and method of data exchange between the upper machine and the lower machine. For example, TCP / IP protocol can be used as the transport layer protocol, and the application layer adopts a custom binary or text format to encapsulate data. The data interaction protocol ensures that both parties can correctly send and receive data. The query protocol allows the upper machine to send a query request to the lower machine to obtain specific status information or data. The query protocol includes the definition of query command, parameter and response format. The lower machine will return the corresponding data according to the content of the request after receiving the query request. The control protocol allows the upper machine to send control commands to the lower machine to change the state of the lower machine or perform specific operations. The control protocol includes the definition of control command, parameter and confirmation mechanism. The lower machine will perform the corresponding operation after receiving the control command, and return the execution result or state information.

[0062] Step S460, sending a module request protocol message to the lower machine according to the IP address of the lower machine through the module request protocol. Specifically, the upper machine uses the module request protocol to request the lower machine to provide specific modules or functions. The upper machine constructs a module request protocol message according to the user's request or the system's needs. The message contains request commands, module identifiers (such as module names or version numbers) and any necessary parameters. The upper machine sends the module request protocol message to the IP address of the lower machine through the network. The lower machine parses the message content after receiving the message, and provides the corresponding module or function according to the request.

[0063] Step S470: Receive proactively reported information from the lower-level machine via the proactive reporting protocol. Specifically, the lower-level machine uses the proactive reporting protocol to send status information, alarm information, or other important data to the upper-level machine. When the lower-level machine detects an important event or status change, it constructs a proactive reporting protocol message. The message contains the type and content of the reported information, as well as any necessary additional information. The lower-level machine sends the proactive reporting protocol message to the upper-level machine's IP address (or a pre-configured communication endpoint) via the network. After receiving the message, the upper-level machine parses the message content and takes appropriate actions or displays it to the user as needed. This implementation, by defining multiple protocols, allows the upper-level machine to flexibly exchange data, query, and control operations with the lower-level machine as needed, increasing the system's flexibility and scalability.

[0064] like Figure 8 As shown, in one possible implementation, the scheduler loader reads and runs the source code file. Upon successful execution, it displays a loading interface to the user and responds to user actions in real time. After the interaction, the method further includes step S500: when the user closes the host computer, the hot-loaded module is unloaded. Specifically, the host computer software listens for the user's closing operation through the operating system's window management API or a closing event callback provided by the framework. Once a closing event is detected, the system triggers an unloading process responsible for handling the unloading of all hot-loaded modules. The unloading process iterates through all loaded hot-loaded modules and calls the corresponding unloading functions or methods. These functions or methods release resources occupied by the module, such as memory, file handles, and network connections. The unloading process checks the unloading status of each module to ensure that all modules have been successfully unloaded. If a module fails to unload, the system records an error log.

[0065] Step S600: After the hot-loading module is unloaded, the base module is unloaded. Specifically, if all hot-loading modules have been unloaded, the system will call the unload function or method of the base module. This function or method is used to release the resources occupied by the base module and clean up the communication connection with the lower-level machine. The system will check the unloading status of the base module to ensure that it has been successfully unloaded. If the unloading fails, the system will record an error log. Finally, the system will call the exit function or method of the operating system to terminate the operation of the upper-level software. This implementation method, by unloading the hot-loading module and the base module, can release the occupied resources, avoid memory leaks and resource waste, and ensure that the upper-level software does not leave any unprocessed connections or processes when exiting, thereby improving the stability and security of the system.

[0066] The foregoing DETAILED DESCRIPTION, including the above section titled "Detailed Description," is not to be taken as limiting the scope of the application. Various modifications, combinations, and equivalents can be apparent to those skilled in the art and can be made once the nature of the application is understood. Any modification, combination, or equivalent, which falls within the principles and the scope of the present application, is intended to be included in the present application. In some instances, the actions or steps can be performed in different order from those described herein, and still achieve desirable results. Additionally, the process depicted in the figures can not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

Claims

1. A method for implementing one-to-many dynamic host computer software, characterized in that, Applied to a host computer, the method includes: In response to the user's input of a lower-level machine interaction request and the lower-level machine's IP address, load the basic module; Once the basic module is loaded, a module request protocol message is sent to the lower-level machine according to the lower-level machine's IP address, and feedback information is received from the lower-level machine. After parsing the feedback information from the lower-level machine, the source code file is obtained; The scheduler loader reads the source code file and runs it to complete the loading of the hot loading module. When the loading is successful, it displays the loading interface to the user and responds to the user's operation information in real time to perform the interaction. The basic module includes at least a general module, a communication module, and a parsing module. In response to user input of a lower-level machine interaction request and the lower-level machine IP address, the basic module is loaded, and the module also includes: When the basic module fails to load, a loading failure signal is sent to the user and a loading failure log is recorded. If any one of the basic modules fails to load, then the basic module fails to load. Once the basic module is loaded, a module request protocol message is sent to the lower-level machine according to the lower-level machine's IP address, and feedback information is received from the lower-level machine, including: If no feedback information is received from the lower-level machine within a preset time zone after the lower-level machine sends a module request protocol message to the lower-level machine using the lower-level machine's IP address, or if the feedback information from the lower-level machine is empty, record the information and send a module request protocol message to the lower-level machine again using the lower-level machine's IP address. When the lower-level machine receives feedback information from the lower-level machine within a preset time zone after sending a module request protocol message to the lower-level machine via the lower-level machine's IP address, and the feedback information from the lower-level machine is not empty, the subsequent process is executed.

2. The method for implementing one-to-many dynamic host computer software as described in claim 1, characterized in that, Load the basic modules, including: Load the general module; When the general module fails to load, a loading failure signal is sent to the user and a loading failure log is recorded. When the general module is successfully loaded, the communication module is loaded. When the communication module fails to load, a loading failure signal is sent to the user and a loading failure log is recorded. When the communication module is successfully loaded, the parsing module is loaded. When the parsing module fails to load, a loading failure signal is sent to the user and a loading failure log is recorded. When the parsing module is successfully loaded, the basic module is loaded.

3. The method for implementing one-to-many dynamic host computer software as described in claim 1, characterized in that, The lower-level machine feedback information includes hot-loading module serialization and hot-loading source code file encryption information. After parsing the lower-level machine feedback information, the loaded source code file is obtained, including: The hot-loading module serialization is deserialized and parsed to obtain the first loading source code file; The encrypted information of the hot-loaded source code file is decrypted to obtain the second loaded source code file; Add the first and second source code files to the source code loading file.

4. The method for implementing one-to-many dynamic host computer software as described in claim 3, characterized in that, The source code file being loaded is in qml source code format.

5. The method for implementing one-to-many dynamic host computer software as described in claim 3, characterized in that, After parsing the feedback information from the lower-level machine, the source code file is obtained, and the file also includes: When the lower-level machine fails to parse the feedback information, record the error and send a module request protocol message to the lower-level machine again based on the lower-level machine's IP address.

6. The method for implementing one-to-many dynamic host computer software as described in claim 1, characterized in that, The scheduler loader reads and runs the source code file, including: The loader reads the loaded source code file; If the read operation is successful, the source code file will be loaded. When the operation is successful, hot loading is completed and the operation interface is displayed on the host computer. If reading or running fails, record the error and send a module request protocol message to the lower-level machine again based on the lower-level machine's IP address.

7. The method for implementing one-to-many dynamic host computer software as described in claim 1, characterized in that, Display a loading screen to the user and respond to user actions in real time, including: It interacts with the lower-level machine through data interaction protocol, query protocol, and control protocol; The module request protocol is used to send a module request protocol message to the lower-level machine according to the lower-level machine's IP address. The system receives information proactively reported by the lower-level machine through a proactive reporting protocol.

8. The method for implementing one-to-many dynamic host computer software as described in claim 1, characterized in that, The scheduler loader reads and runs the source code file. Upon successful execution, it displays a loading interface to the user and responds to user actions in real time. This process also includes: When the user closes the host computer, the hot-load module is unloaded; After the hot-loading module has been unloaded, the basic module is then unloaded.

Images