A device management method and system with front-end and back-end separation in embedded software

Abstract

This invention belongs to the field of embedded system technology, and provides a device management method and system for front-end and back-end separation in embedded software. The method includes: starting a background service process as a daemon process; establishing a local Socket communication connection between the foreground application and the background service process; and communicating using a JSON-based command protocol. The foreground application generates commands and sends them to the background service process, which performs verification, parsing, and distribution. After a submodule executes, the background service process obtains the execution result and asynchronously returns a receipt. The background service process monitors the health status of submodules by receiving heartbeat signals. When no heartbeat is received for N consecutive cycles, the submodule is determined to be abnormal and restarted, while maintaining the normal operation of the background service process and other submodules. This achieves decoupling at the front-end and back-end process level, submodule fault restart, and adaptive adaptation between different hardware platforms, improving the stability and maintainability of the embedded system.

Description

Technical Field

[0001] This invention relates to the field of embedded system technology, and specifically to a device management method and system for separating the front-end and back-end of embedded software. Background Technology

[0002] Currently, most embedded device management systems in the industry adopt a single-process or weakly isolated architecture. The front-end user interface is highly coupled with the back-end business logic. A crash in the front-end application often leads to the interruption of the entire back-end service, resulting in insufficient overall system stability. At the same time, the management of embedded devices involves multiple functional modules, and the communication protocols between these modules are mostly simple text streams or without verification mechanisms. They lack necessary version compatibility handling, error feedback, and asynchronous processing capabilities, which limits the system's scalability.

[0003] To address the aforementioned technical problems, some solutions already exist in the prior art. For example, the Chinese invention patent "Embedded Platform Node Fault Recovery System and Method" (application number: CN202210232201.9) discloses a solution that generates heartbeat information by setting a node manager on each node and sending it to the node controller to determine whether the node is faulty. However, this solution is mainly applied to fault monitoring between distributed node devices and does not address process-level isolation between foreground applications and background services within embedded devices, nor does it solve the problem of fault isolation and self-recovery between different functional sub-modules within the same device. Another example is the Chinese invention patent "A Multi-Level Protection Method for Applications" (authorization number: CN112612635B), which discloses a solution using daemon processes to provide reliability assurance. However, in this solution, the daemon process is mainly used to monitor the overall running status of a single application and fails to achieve discrete, fine-grained monitoring of multiple functional sub-modules (such as Wi-Fi modules, audio modules, etc.). When a sub-module malfunctions, it is impossible to accurately locate and restart the malfunctioning sub-module individually; only the entire application can be restored. The isolation granularity is coarse, and the overall availability is limited.

[0004] Furthermore, current embedded devices generally face the challenge of rapid hardware platform iteration. In practical applications, when the same software runs on different hardware versions (such as first-generation screens and second-generation screens), functional failures often occur due to mismatches in driver parameters, interface timings, and other configurations. The system cannot automatically identify the hardware version and adapt the corresponding configuration parameters, requiring manual modification and system restart, resulting in high maintenance costs and low efficiency. At the same time, existing systems typically cannot detect hot changes to hardware devices during runtime (such as peripheral replacement or upgrades). After a hardware change, a power outage and system restart are required to reload the configuration, failing to achieve zero-downtime hot adaptation and affecting the continuous operation capability of embedded systems.

[0005] Therefore, there is an urgent need for a device management method and system that can achieve front-end and back-end process-level isolation, structured communication protocols, module-level abnormal restart based on heartbeat signals, and support cross-hardware platform adaptation and runtime hot adaptation. Summary of the Invention

[0006] This invention provides a device management method and system with front-end and back-end separation in embedded software, in order to solve the technical problems of high coupling between front-end and back-end, poor protocol scalability, weak fault isolation capability and poor cross-hardware platform compatibility in the prior art.

[0007] This invention provides a device management method for embedded software with front-end and back-end separation, comprising the following steps: S1: When the system starts, the background service process is started as a daemon process, and a local Socket communication connection is established between the foreground application and the background service process. The foreground application and the background service process communicate using a JSON-based command protocol, which includes a version number field, a checksum field, a command sequence number field, and an asynchronous execution flag field. S2: The foreground application generates a first instruction that conforms to the instruction protocol based on the user's operation, and sends it to the background service process through the local Socket communication connection; the background service process receives and parses the first instruction, performs integrity verification based on the checksum field, and judges protocol version compatibility based on the version number field. After the verification and judgment are passed, the first instruction is distributed to the corresponding first sub-module for execution. S3: The first submodule executes the first instruction, the background service process obtains the execution result, generates a receipt including the instruction sequence number field, the execution status code field and the error information field, and asynchronously returns it to the foreground application through the local Socket communication connection; S4: The background service process continuously monitors the health status of multiple sub-modules under its management, including the first sub-module. The monitoring includes receiving heartbeat signals sent by each sub-module at preset intervals. When no heartbeat signal is received from the first sub-module within N consecutive intervals, where N is a preset integer greater than or equal to 1, the first sub-module is determined to be abnormal and restarted. During the restart, the background service process and other sub-modules are kept running normally.

[0008] Furthermore, the JSON-formatted instructions further include a command name field and a parameter field; the receipt further includes a result description field.

[0009] Furthermore, each of the multiple submodules runs as an independent process, separate from the background service process.

[0010] Furthermore, health status monitoring further includes: the background service process receiving abnormal signals during the runtime of the submodule, including segmentation faults or illegal instructions.

[0011] Furthermore, restarting the first submodule specifically involves the background service process calling the preset process generation interface to recreate its process instance using the original configuration parameters of the first submodule.

[0012] Furthermore, starting a background service process as a daemon process specifically involves registering the background service process as an operating system service, starting it during system startup by the init or systemd system, and restarting it by the operating system after an abnormal exit.

[0013] Furthermore, the asynchronous return to the foreground application via the local Socket communication connection further includes: the foreground application maintaining a callback mapping table indexed by instruction sequence number; upon receiving an acknowledgment, the foreground application searching for and calling the corresponding callback function based on the instruction sequence number in the acknowledgment to process the execution result.

[0014] Furthermore, step S4 further includes: the background service process maintains a submodule configuration parameter template library, which stores submodule configuration parameters adapted to different hardware platform versions; the submodule configuration parameters include at least one of driver parameters, interface timing parameters, or communication protocol parameters; when the first submodule is determined to be abnormal, the background service process obtains the current hardware platform version information, selects the target configuration parameter that matches the current hardware platform version information from the template library, and restarts the first submodule using the target configuration parameter.

[0015] Furthermore, step S4 further includes: the background service process listens for hardware platform change events through the udev mechanism, and when it detects that the hardware platform has changed from the first hardware platform version to the second hardware platform version, it updates the current hardware platform version information and triggers the reload of the configuration parameters of the running sub-module.

[0016] An embedded software-based device management system with front-end and back-end separation includes: The initialization unit is configured to: start the background service process as a daemon process, and establish a local Socket communication connection between the foreground application and the background service process; the foreground application and the background service process communicate using a JSON-based command protocol, which includes a version number field, a checksum field, a command sequence number field, and an asynchronous execution flag field. The instruction sending and receiving unit is configured to: enable the foreground application to generate and send a first instruction conforming to the instruction protocol based on the user's operation; enable the background service process to receive, parse, verify, and distribute the first instruction to the corresponding sub-module for execution; wherein, the verification includes integrity verification based on the checksum field and protocol version compatibility judgment based on the version number field. The asynchronous receipt unit is configured to: obtain the execution result of the submodule, generate a receipt including the instruction sequence number, execution status code and error information, and asynchronously return it to the foreground application; The monitoring and recovery unit is configured to receive heartbeat signals from each submodule managed by the background service process at a preset period; when no heartbeat signal is received from any submodule within N consecutive periods, where N is a preset integer greater than or equal to 1, the submodule is determined to be abnormal, the submodule is restarted, and the normal operation of the background service process and other submodules is maintained during the restart.

[0017] Compared with the prior art, the present invention has the following beneficial effects: The front-end application and the back-end service processes are independent of each other. Sub-modules run as independent processes. The crash of any sub-module will not affect the back-end service or other sub-modules, and the overall stability of the system is significantly improved.

[0018] The JSON-based structured instruction protocol includes version number, checksum, sequence number, and asynchronous flag, and supports protocol version compatibility judgment and negotiation, error detection, and asynchronous non-blocking communication.

[0019] By monitoring the health status of submodules in real time using heartbeat signals, abnormal submodules can be automatically restarted without requiring a full system restart, thus achieving high availability at the module level.

[0020] By configuring a parameter template library, the correct driver parameters, interface timings, and other configurations are automatically matched and loaded according to the current hardware platform version, which solves the compatibility problem between different hardware versions and eliminates the need for manual adjustments.

[0021] By listening for hardware platform change events through the udev mechanism, the hardware version is automatically updated and the submodule configuration is reloaded at runtime, achieving zero-downtime hot adaptation.

[0022] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and drawings.

[0023] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 A schematic diagram illustrating the steps of a device management method that separates the front-end and back-end of embedded software. Figure 2 A schematic diagram illustrating the steps for restarting the first submodule based on the configuration parameter template library of the maintained submodule for the background service process; Figure 3 A schematic diagram of a device management system architecture that separates the front-end and back-end of embedded software. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of this invention.

[0026] Example 1: As Figure 1 As shown, this embodiment provides a device management method with front-end and back-end separation in embedded software, which is applicable to embedded systems such as smart home gateways and industrial control equipment.

[0027] Step S1: System initialization. After the system powers on and starts up, the operating system is loaded. The background service process is registered as an operating system service. When the system starts, the init system or systemd system starts the background service process as a daemon process (e.g., a daemon process named "devmgrd") according to the configuration file. This background service process is resident in memory as a system service and is restarted by the operating system after abnormal exit.

[0028] Meanwhile, the background service process creates a local socket server that listens on a predefined Unix domain socket path (e.g., / var / run / devmgrd.sock) or TCP loopback address port (e.g., 127.0.0.1:9527). Once the foreground application (e.g., a graphical user interface program or command-line tool) starts, it actively connects to this local socket to establish a bidirectional communication channel.

[0029] Both the front-end and back-end agree to use a JSON-formatted instruction protocol. This protocol includes a version number field, a checksum field, an instruction sequence number field, an asynchronous execution flag field, a command name field, and parameter fields. The JSON instruction contains the following fields: version (a string representing the protocol version number), cmd (a string representing the command name), params (an object representing the command parameters), seq (an integer representing the instruction sequence number), checksum (a string representing the checksum), and async (a boolean value indicating whether asynchronous execution is enabled). The async field is the asynchronous execution flag field.

[0030] The working principle and benefits of this technical solution are as follows: By running the core functions of device management as a resident background daemon, the stability and continuity of the device management service are guaranteed, and the device management capability will not be terminated due to the exit of a single foreground application. The self-recovery mechanism can further reduce the impact of abnormal failures on system device management. At the same time, the use of local Socket to achieve bidirectional communication balances communication security and development flexibility. The JSON format command protocol also reduces the development cost of front-end and back-end integration and facilitates the addition of custom device management commands in the future.

[0031] Step S2: Command Issuance and Processing. When the user clicks the "Turn on Wi-Fi" button on the front-end application interface, the front-end application generates the above JSON command and sends it to the background service process via the local socket.

[0032] After receiving the command data, the background service process first performs integrity verification on the checksum field to prevent transmission errors or tampering. Next, it determines the protocol version based on the version number field: if the version is higher than the version supported by the background service, an error code is returned to notify the foreground application to upgrade. Upon receiving this error code, the foreground application can proactively obtain the command format of the latest protocol version, upgrade its own protocol stack, and resend the command without modifying the background service or restarting the system. Thus, the background service can support the access of new protocol versions without downtime, achieving a smooth protocol upgrade. If the version is lower than the minimum compatible version, an incompatibility error is returned; if the version is compatible, processing continues. After successful verification, the background service process parses the command name field and distributes the command to the corresponding submodule (e.g., the "Wi-Fi management submodule"). Each of the multiple submodules runs as an independent process, independent of the background service process, and they do not share process address spaces.

[0033] The working principle and beneficial effects of this technical solution are as follows: By using a layered verification mechanism to intercept erroneous and incompatible instructions in advance, invalid processing that consumes system resources is avoided, thus improving the stability of instruction processing; at the same time, the design of sub-modules running as independent processes achieves the isolation of functional modules. An anomaly in a single sub-module will not affect the normal operation of the background main process and other sub-modules, and it also facilitates the independent development and updates of individual functional modules in the future, reducing the risk and cost of functional iteration.

[0034] Step S3: Asynchronous receipt. The Wi-Fi management submodule performs the operation to turn on Wi-Fi (which may involve loading the driver, configuring the firmware, initiating a scan, etc.). After the execution is completed, the execution result is returned to the background service process.

[0035] The background service process constructs a JSON receipt, which includes a command sequence number field, an execution status code field, an error message field, and a result description field. The background service process sends the receipt to the foreground application via a local socket. The foreground application maintains a callback mapping table indexed by the command sequence number. After receiving the receipt, the foreground application looks up and calls the corresponding callback function based on the command sequence number in the receipt to process the execution result (e.g., updating the interface to display "Wi-Fi is on").

[0036] The working principle and beneficial effects of this technical solution are as follows: By adopting an asynchronous receipt method, the front-end application does not need to block and wait for the sub-module to complete the time-consuming operation after initiating the command. It can continue to respond to other user interaction operations, avoiding interface lag and greatly improving the smoothness of front-end operation and user experience. At the same time, through the sequence matching callback mechanism, it can accurately match the command request and execution result, ensuring that the result correspondence will not be disordered when multiple concurrent commands are processed, and can still run stably in the scenario of multiple commands being processed in parallel.

[0037] Step S4: Health Monitoring and Self-Healing. The background service process starts a monitoring coroutine for each submodule (such as the Wi-Fi management submodule, audio submodule, Bluetooth submodule, etc.). Each submodule needs to send a heartbeat signal (such as a simple JSON message) to the background service process at fixed intervals (e.g., 5 seconds). The background service process performs heartbeat detection at the same intervals (e.g., 5 seconds). If no heartbeat is received from a submodule for N consecutive detection cycles (N=3 in this embodiment), the submodule is determined to be abnormal (it may have crashed due to segmentation fault, deadlock, etc.). At this time, the background service process calls the process generation interface pre-built by the operating system (e.g., fork+exec in Linux or CreateProcess in Windows) to recreate its process instance with the original configuration parameters of the submodule. The original configuration parameters are pre-stored in the configuration file (e.g., / etc / devmgrd / modules / wifi.conf) or solidified in the executable file during compilation. During the restart, the background service process continues to receive heartbeats from other submodules and process new instructions, without the foreground application being aware of it.

[0038] In addition, health status monitoring also includes the background service process receiving abnormal signals during the runtime of the submodule: the background service process also obtains the abnormal exit signal of the submodule (such as SIGSEGV segmentation fault, SIGILL illegal instruction) through the operating system signal mechanism (such as sigchld), determines whether the exit is due to a signal through WIFSIGNALED(status) (macro function, used to determine whether the subprocess is abnormally terminated by a signal), and then obtains the specific signal value through WTERMSIG(status) (macro function, used to extract the signal number that caused the process to terminate from the process exit status), and immediately triggers a restart.

[0039] The working principle and beneficial effects of this technical solution are as follows: In the front-end and back-end separation architecture, exception handling and self-healing logic are all completed by the back-end service. The failure of a single submodule will not affect the front-end interaction, nor does the front-end process need to participate in the exception handling process. This ensures the stability of device operation without interrupting the user's workflow. Simultaneously, a unified back-end service centrally manages the health status of all submodules, eliminating the need for each submodule to implement its own monitoring logic. This reduces redundant code development and makes the rules for exception detection and self-healing more consistent, facilitating subsequent maintenance and rule adjustments.

[0040] Example 2: Based on Example 1, this example further addresses the compatibility issues between different hardware platform versions.

[0041] Suppose an embedded device has two hardware versions, "first-generation screen" and "second-generation screen", with different Wi-Fi module driver parameters and screen interface timing. In the traditional solution, when the same firmware version is run on the second-generation screen, the Wi-Fi function fails due to parameter mismatch, requiring manual modification of the configuration file and restart.

[0042] In this invention, such as Figure 2 As shown, the background service process maintains a submodule configuration parameter template library, which is stored in non-volatile memory. The submodule configuration parameters include at least one of driver parameters, interface timing parameters, or communication protocol parameters. For example, the content is as follows: When the background service process determines that the Wi-Fi submodule is malfunctioning and prepares to restart, it first obtains the current hardware platform version (e.g., "V2.0") by reading system firmware information (e.g., / proc / device-tree / model or the Windows registry). Then, the background service process searches the template library for configuration parameters ({"driver":"rtl8822","tx_power":18,"regdomain":"CN"}) that match the current hardware platform version and submodule name. If a matching configuration parameter is found, it uses that parameter as the target configuration parameter to restart the Wi-Fi submodule; otherwise, it reverts to using the original configuration parameters of the submodule to restart. Using this approach, the same set of background service processes and foreground application firmware can automatically adapt to different hardware platform versions.

[0043] The working principle and technical effects of this embodiment are as follows: Traditional solutions require maintaining multiple firmware versions to adapt to multiple hardware versions. Different firmware versions are prone to confusion and errors, increasing development and maintenance costs. This solution maintains a unified parameter template library in the background, automatically matching and loading parameters during module startup or abnormal restart. Only one firmware release is needed to cover multiple hardware versions. This avoids errors from manual configuration modifications, reduces after-sales maintenance costs, and ensures parameter matching of submodules across different hardware platform versions, preventing functional abnormalities and effectively solving compatibility issues between multiple hardware versions.

[0044] Example 3: Based on Example 2, this example further implements adaptive hot-changing of the runtime hardware platform.

[0045] In real-world applications, devices may require the replacement of hardware modules while powered on. Examples include hot-swappable expansion modules for industrial panel PCs and replaceable communication modules.

[0046] The background service process listens for hardware platform change events through the udev mechanism (Linux kernel device management framework). The background service process starts a dedicated listening thread, first creating a udev context, then creating a udev monitoring object and binding it to the Netlink protocol. It sets the filter to only listen for device events from the platform subsystem (a virtual bus framework in the Linux kernel used to manage non-standard bus devices, primarily for on-chip peripheral controllers on SoC platforms). Finally, it enables event reception for the monitored object. During system operation, the listening thread continuously acquires the file descriptor of the monitored object, waiting for the file descriptor to become readable. Once the file descriptor is readable, the thread receives device events. If the received event is not empty, it obtains the action type of the event. When the action type is "change", it extracts the hardware version identifier from the event. If the extracted new hardware version differs from the currently recorded hardware version, it updates the current hardware version to the new version and iterates through all running submodules, sending a hot reload command to each submodule.

[0047] When a user inserts a second-generation screen display module, udev triggers a change event carrying device information. The background service process receives this event through a Netlink socket, parses out the new hardware platform version (such as changing from "V1.0" to "V2.0"), and automatically updates the current hardware platform version information in the internal storage.

[0048] Subsequently, the background service process iterates through all running submodules, reselects configuration parameters from the template library based on the new hardware platform, and notifies each submodule of hot reload configuration (e.g., sending a reload command, or smoothly restarting the submodule; a smooth restart means: the background service process first sends a state saving command (e.g., a JSON command) to the target submodule, and the submodule, upon receiving it, sends its current running state (including session identifier, temporary configuration parameters, cached data, etc.) back to the background service process via a local socket; the background service process receives and temporarily stores this state data, and then calls the operating system process management interface to terminate the submodule process; subsequently, the background service process restarts the submodule process using the new configuration parameters selected from the template library, and sends the temporarily stored state data to the new process via a local socket. The new process loads the state data and continues to provide services, thus achieving cross-process saving and restoration of submodule state. The entire process does not require power outages or a system restart, and the foreground application business is uninterrupted.

[0049] The working principle and technical effects of this embodiment are as follows: Through the front-end and back-end separation architecture design, the hardware adaptation logic is completely pushed down to the back-end service processing. The front-end is only responsible for the operation of business logic. When the hardware undergoes a hot change, the back-end service autonomously completes the hardware information update, configuration reload and sub-module adaptation, without affecting the normal operation of the front-end business. This not only solves the pain point of traditional embedded devices that must be powered off and restarted to replace hardware, but also meets the actual needs of maintaining hardware without downtime under high availability requirements such as industrial scenarios. At the same time, relying on the templated parameter configuration mechanism, there is no need to recompile and modify the code for new hardware, which greatly improves the efficiency of hardware change adaptation.

[0050] Example 4: Figure 3 As shown, this embodiment provides an embedded software front-end and back-end separated device management system. The system can be used to execute the methods described in Embodiments 1 to 3. The system includes an initialization unit, an instruction sending and receiving and processing unit, an asynchronous receipt unit, and a monitoring and recovery unit.

[0051] The initialization unit is configured as follows: A background service process is started as a daemon, establishing a local Socket communication connection between the foreground application and the background service process; furthermore, the foreground application and the background service process communicate using a JSON-based command protocol, which includes a version number field, a checksum field, a command sequence number field, and an asynchronous execution flag field; specifically: After the system powers on, the initialization unit starts first, launching the background service process as a daemon and creating a local Socket listener. Subsequently, the monitoring and recovery unit starts, creating heartbeat timers for each submodule. After the foreground application starts, it communicates with the background through the Socket connection established by the initialization unit. The instruction sending and receiving and processing unit and the asynchronous receipt unit are instantiated in the foreground and background respectively, awaiting user instructions.

[0052] In the specific implementation of the interaction sequence: after the user clicks the button, the front-end command sending and receiving unit constructs a JSON command and sends it; the back-end command sending and receiving unit receives, verifies, and distributes the command to the sub-module; after the sub-module completes its execution, it returns the execution result to the asynchronous receipt unit; the asynchronous receipt unit constructs a receipt and returns it to the front-end; the front-end callback mapping table triggers the corresponding callback function according to the command sequence number and updates the interface.

[0053] In actual deployments, the initialization unit can manifest as a service configuration file of the operating system (such as / etc / systemd / system / devmgrd.service) and the Socket initialization code called when the background service process starts. After the system powers on, systemd automatically starts the background service process according to the configuration file and creates a local Socket listener.

[0054] The instruction sending and receiving unit is configured to: enable the front-end application to generate and send a first instruction conforming to the instruction protocol based on the user's operation; enable the background service process to receive, parse, verify, and distribute the first instruction to the corresponding sub-module for execution. The verification includes integrity verification based on the checksum field and protocol version compatibility judgment based on the version number field.

[0055] The front-end application is responsible for generating JSON commands and sending them via Socket; the back-end service process internally implements a command dispatcher, which routes the command to the corresponding submodule entry point based on the cmd field in the command.

[0056] The asynchronous receipt unit is configured to: obtain the execution result of the submodule, generate a receipt including instruction sequence number, execution status code and error information, and return it asynchronously to the foreground application. In the background service process, this unit is manifested as a result collection and receipt construction module, and in the foreground application, it is manifested as a callback mapping table and its scheduling mechanism.

[0057] The asynchronous receipt unit in the background service process waits for the submodule to return the execution result, constructs a JSON receipt including the instruction sequence number, execution status code, and error information, and then sends it to the front end via a local socket. The asynchronous receipt unit in the front end application maintains a callback mapping table with the instruction sequence number as the key, and triggers the corresponding callback upon receiving the receipt.

[0058] The monitoring and recovery unit is configured as follows: it receives heartbeat signals from each submodule managed by the background service process at a preset period; when no heartbeat signal is received from any submodule within N consecutive periods (where N is a preset integer greater than or equal to 1), the background service process maintains a timeout counter for each submodule, initially set to 0, and sets the counter to 0 each time a heartbeat is received; the background service process executes the following heartbeat timeout judgment logic: in order to determine whether a heartbeat has not been received for N consecutive periods, the background service process iterates through all registered submodules: if a heartbeat from a submodule is received in the current period, the timeout counter of that submodule is cleared to zero; otherwise, the timeout counter of that submodule is incremented by 1; when the timeout counter of any submodule accumulates to a preset threshold N (N=3 in this embodiment), the background service process determines that the submodule is abnormal, and calls the operating system process creation interface to restart the submodule, and maintains the normal operation of the background service process and other submodules during the restart.

[0059] The background service process internally has a monitoring manager that creates a heartbeat timer for each submodule and is responsible for receiving heartbeat signals periodically sent by the submodules. If the timer expires, the monitoring manager calls the process management interface (such as fork+exec) to restart the abnormal submodule. In addition, the monitoring manager also uses a signal mechanism (such as sigchld) to capture abnormal exits of subprocesses, enabling rapid recovery.

[0060] The system's working principle and technical effects: Four units work collaboratively, fully realizing front-end / back-end process-level isolation, structured asynchronous protocol communication, and module-level abnormal restart functionality. The system boasts high overall stability and strong scalability, and its modular design ensures clear responsibilities for each unit, facilitating independent development, testing, and maintenance.

[0061] The method and system provided by this invention can be widely applied to embedded devices with high requirements for stability and maintainability, such as smart homes, industrial control, medical equipment, and in-vehicle entertainment systems. Through foreground and background process isolation, structured asynchronous protocols, abnormal restart, and cross-platform adaptive mechanisms, it significantly reduces development and maintenance costs and improves user experience.

[0062] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A device management method with front-end and back-end separation in embedded software, characterized in that, Includes the following steps: S1: When the system starts, the background service process is started as a daemon process, and a local Socket communication connection is established between the foreground application and the background service process. The foreground application and the background service process communicate using a JSON-based command protocol, which includes a version number field, a checksum field, a command sequence number field, and an asynchronous execution flag field. S2: The foreground application generates a first instruction that conforms to the instruction protocol based on the user's operation, and sends it to the background service process through the local Socket communication connection; the background service process receives and parses the first instruction, performs integrity verification based on the checksum field, and judges protocol version compatibility based on the version number field. After the verification and judgment are passed, the first instruction is distributed to the corresponding first sub-module for execution. S3: The first submodule executes the first instruction, the background service process obtains the execution result, generates a receipt including the instruction sequence number field, the execution status code field and the error information field, and asynchronously returns it to the foreground application through the local Socket communication connection; S4: The background service process continuously monitors the health status of multiple sub-modules under its management, including the first sub-module. The monitoring includes receiving heartbeat signals sent by each sub-module at preset intervals. When no heartbeat signal is received from the first sub-module within N consecutive intervals, where N is a preset integer greater than or equal to 1, the first sub-module is determined to be abnormal and restarted. During the restart, the background service process and other sub-modules are kept running normally.

2. The embedded software front-end and back-end separation device management method according to claim 1, characterized in that, The JSON-formatted instruction further includes a command name field and a parameter field; the receipt further includes a result description field.

3. The embedded software front-end and back-end separation device management method according to claim 1, characterized in that, Each of the multiple submodules runs as an independent process, separate from the background service process.

4. The embedded software front-end and back-end separation device management method according to claim 1, characterized in that, Health status monitoring further includes: the background service process receiving abnormal signals during the runtime of the submodule, including segmentation faults or illegal instructions.

5. The embedded software front-end and back-end separation device management method according to claim 1, characterized in that, Restarting the first submodule specifically involves the background service process calling the pre-defined process generation interface to recreate its process instance using the original configuration parameters of the first submodule.

6. The embedded software front-end and back-end separation device management method according to claim 1, characterized in that, Starting a background service process as a daemon process involves registering the background service process as an operating system service, starting it during system startup via the init or systemd system, and restarting it by the operating system after an abnormal exit.

7. The embedded software front-end and back-end separation device management method according to claim 1, characterized in that, The asynchronous return to the foreground application via a local Socket communication connection further includes: the foreground application maintaining a callback mapping table indexed by instruction sequence number; upon receiving an acknowledgment, the foreground application searching for and calling the corresponding callback function based on the instruction sequence number in the acknowledgment to process the execution result.

8. The embedded software front-end and back-end separation device management method according to claim 1, characterized in that, Step S4 further includes: the background service process maintains a submodule configuration parameter template library, which stores submodule configuration parameters adapted to different hardware platform versions; the submodule configuration parameters include at least one of driver parameters, interface timing parameters, or communication protocol parameters; when the first submodule is determined to be abnormal, the background service process obtains the current hardware platform version information, selects the target configuration parameter that matches the current hardware platform version information from the template library, and restarts the first submodule using the target configuration parameter.

9. The embedded software front-end and back-end separation device management method according to claim 8, characterized in that, Step S4 further includes: the background service process listens for hardware platform change events through the udev mechanism. When it detects that the hardware platform has changed from the first hardware platform version to the second hardware platform version, it updates the current hardware platform version information and triggers the reload of the configuration parameters of the running sub-module.

10. A device management system with embedded software front-end and back-end separation, characterized in that, include: The initialization unit is configured to: start the background service process as a daemon process, and establish a local Socket communication connection between the foreground application and the background service process; the foreground application and the background service process communicate using a JSON-based command protocol, which includes a version number field, a checksum field, a command sequence number field, and an asynchronous execution flag field. The instruction sending and receiving unit is configured to enable the foreground application to generate and send a first instruction conforming to the instruction protocol based on the user's operation. The background service process receives, parses, verifies, and distributes the first instruction to the corresponding sub-module for execution; wherein, the verification includes integrity verification based on the checksum field and protocol version compatibility judgment based on the version number field; The asynchronous receipt unit is configured to: obtain the execution result of the submodule, generate a receipt including the instruction sequence number, execution status code and error information, and asynchronously return it to the foreground application; The monitoring and recovery unit is configured to receive heartbeat signals from each submodule managed by the background service process at a preset period; when no heartbeat signal is received from any submodule within N consecutive periods, where N is a preset integer greater than or equal to 1, the submodule is determined to be abnormal, the submodule is restarted, and the normal operation of the background service process and other submodules is maintained during the restart.

Images