Automatic data reporting method of embedded system

Abstract

The invention relates to the technical field of embedded systems, and discloses an automatic data reporting method of an embedded system, which comprises the following steps: reading and loading a preset configuration file, and carrying out resource initialization according to the configuration requirement of the configuration file, including memory allocation, thread pool creation, timer setting and log system initialization; according to the set configuration report parameters in the configuration file, data acquisition, data preprocessing and data packaging are carried out in sequence; establishing a connection with the target server according to a protocol selected in the configuration report parameters, and reporting and sending the packaged data; monitoring an abnormal condition in a reporting process in real time, and executing a corresponding exception handling mechanism according to the abnormal condition; and after the report is completed, executing a service termination mechanism, including task cleaning, connection closing and resource release. According to the invention, efficient and reliable data reporting is realized by optimizing the data acquisition, processing and transmission processes of the embedded system in the resource-constrained environment.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded systems, and in particular to an automatic data reporting method for embedded systems. Background Art

[0002] With the rapid development of Internet of Things (IoT) technology, embedded systems have been widely used in various fields, such as smart home, industrial automation, medical monitoring, etc. Embedded systems are usually deployed in resource-constrained environments, such as small sensor nodes or remote monitoring equipment, and need to be able to automatically report the collected data to the remote server for further data analysis and processing.

[0003] However, due to the limited resources of embedded systems, traditional methods often suffer from problems such as unreasonable memory allocation and inefficient thread utilization, which affects the stability and performance of the system. In the event of network instability or server failure, traditional methods lack an effective exception handling mechanism, which may lead to data loss or reporting failure.

[0004] In view of this, the present invention provides an automatic data reporting method for an embedded system to solve the above problems in the prior art. Summary of the invention

[0005] The present invention proposes an automatic data reporting method for an embedded system, aiming to optimize the data collection, processing and transmission process of the embedded system in a resource-constrained environment to achieve efficient and reliable data reporting.

[0006] In order to achieve the above object, the present invention provides an automatic data reporting method for an embedded system, comprising:

[0007] Read and load the preset configuration file, and initialize resources according to the configuration requirements of the configuration file, including allocating memory, creating a thread pool, setting timers, and initializing the log system;

[0008] According to the configuration reporting parameters set in the configuration file, data collection, data preprocessing and data packaging are performed in sequence;

[0009] Establishing a connection with a target server and reporting the encapsulated data according to the protocol selected in the configuration reporting parameters;

[0010] Monitor abnormal situations in the reporting process in real time and execute corresponding abnormal handling mechanisms according to the abnormal situations;

[0011] After the report is completed, the service termination mechanism is executed, including cleaning up tasks, closing connections, and releasing resources.

[0012] Preferably, the reading and loading of a preset configuration file, and initialization of resources according to the configuration requirements of the configuration file, including allocating memory, creating a thread pool, setting a timer, and initializing a log system, are specifically:

[0013] Read and load the preset configuration file from the memory, including the server address, port number, authentication information, protocol type and keep-alive interval;

[0014] Perform validity check on the loaded configuration parameters. If the validity check finds an error, log it and try to use the default value, and / or prompt the user to make corrections.

[0015] Allocate memory according to configuration requirements and reserve buffers and queues for subsequent operations;

[0016] Create a thread pool for concurrent processing tasks, including data collection, data packaging, and data sending;

[0017] Initializing a timer according to the keep-alive interval to periodically trigger the sending of keep-alive packets;

[0018] Specify the log level and output path to log important events throughout the process.

[0019] Preferably, the reporting parameters are configured according to the settings in the configuration file, specifically:

[0020] According to the settings in the configuration file, determine the protocol to be used for this report, and initialize the corresponding client library accordingly;

[0021] Configure necessary connection parameters for the selected protocol, including server address, port, user name and password;

[0022] Register a series of event listeners to monitor trigger conditions such as device status changes and abnormal alarms, and associate corresponding reporting actions.

[0023] Preferably, a series of event listeners are registered to monitor trigger conditions such as device status changes and abnormal alarms, and associate corresponding reporting actions, specifically:

[0024] Monitoring device status changes includes sensor data monitoring and system log monitoring, wherein the sensor data monitoring is used to capture and process sensor reading changes, and the system log monitoring is used to track system operation status in real time;

[0025] Abnormal alarm includes fault detection and safety event response to trigger the alarm mechanism and respond in time according to the cause of the fault;

[0026] Reporting actions include instant reporting, batch reporting and conditional reporting. The instant reporting is used to report relevant data to the server immediately when the listener captures an important event. The batch reporting is used to accumulate frequently occurring low-priority events for a period of time and then report them to the server in a unified manner; the conditional reporting is used to decide whether to report to the server based on preset rules or policies.

[0027] Preferably, data collection, data preprocessing and data packaging are performed in sequence, specifically:

[0028] Data is collected periodically through sensors associated with the data source;

[0029] Perform preliminary processing on the collected raw data, including noise removal, filtering and formatting;

[0030] Search the predefined tag mapping table according to the data type and assign a unique tag to each piece of data;

[0031] Measure the actual length of each Value part, and combine it with the Tag to form a complete TLV unit;

[0032] Each TLV unit is connected in series to form a final reporting data packet.

[0033] Preferably, according to the protocol selected in the configuration reporting parameter, a connection is established with the target server and the encapsulated data is reported and sent, specifically:

[0034] According to the determined protocol, a connection request is sent to the target server, and necessary authentication information is provided, wherein the authentication information includes a user name and a password, and a response returned by the target server is received to determine whether the connection is successful;

[0035] Sending the encapsulated data to the target server through the established connection, and waiting for a confirmation reply from the target server to ensure that the data is correctly received;

[0036] If the confirmation reply is not received, retry according to the preset strategy.

[0037] Preferably, the abnormal situation in the reporting process is monitored in real time, and the corresponding abnormal handling mechanism is executed according to the abnormal situation, specifically:

[0038] Real-time monitoring of abnormal situations during the reporting process, including network failures and server errors;

[0039] The corresponding exception handling mechanism is executed according to the abnormal situation, and the exception handling mechanism includes logging, alarm notification, cache data, retry mechanism and post-recovery processing.

[0040] Preferably, a corresponding exception handling mechanism is executed according to the abnormal situation, and the exception handling mechanism includes logging, alarm notification, cache data, retry mechanism and post-recovery processing, specifically:

[0041] When the abnormal situation is a network failure,

[0042] Record the time and type of network failure and the last successful connection time information;

[0043] Send network failure warning notifications to administrators via SMS and / or email;

[0044] Temporarily storing the data that failed to be reported successfully in the local storage;

[0045] Re-establishing the network connection based on a preset time interval strategy, wherein the preset time interval strategy increases the time interval duration in steps according to the number of reconnections;

[0046] After the network is restored, the data cached in the local memory is immediately uploaded to the server and the status is synchronized with the server. After all the cached data has been successfully received, the local cache is cleaned up and the log file is updated.

[0047] Preferably, a corresponding exception handling mechanism is executed according to the abnormal situation, and the exception handling mechanism includes logging, alarm notification, cache data, retry mechanism and post-recovery processing, specifically:

[0048] When the abnormal situation is a server error,

[0049] Record the time, type, request URL, and request parameter information of server errors;

[0050] Send server error warning notifications to administrators via SMS and / or email;

[0051] Temporarily storing the data that failed to be reported successfully in the local storage;

[0052] The server error includes a temporary server error and a persistent server error. For the temporary server error, the request is resent immediately and the retry is performed a maximum of a preset number of times;

[0053] For the persistent server error, a delayed retry is performed, that is, a resending request is performed based on a preset time interval strategy, wherein the preset time interval strategy increases the time interval duration in steps according to the number of times the resending request is performed;

[0054] After the server returns to normal, the data cached in the local memory is immediately uploaded to the server and the status is synchronized with the server. After all cached data has been successfully received, the local cache is cleaned up and the log file is updated.

[0055] Preferably, after the report is completed, a service termination mechanism is executed, including cleaning up tasks, closing connections, and releasing resources, specifically:

[0056] After the report is completed, the service termination mechanism is executed, which includes cleaning up tasks, closing connections, and releasing resources;

[0057] The cleanup task includes canceling all registered event listeners, turning off the keep-alive timer, and clearing the data buffer in the memory;

[0058] Closing the connection includes disconnecting the network connection and releasing resources related to the network communication;

[0059] The releasing of resources includes reclaiming thread pool resources, releasing all allocated memory blocks, and saving current state variables to the local memory.

[0060] The embodiment of the present application discloses an automatic data reporting method for an embedded system. The method reads and loads a preset configuration file, and the system can automatically complete the initialization process, reducing the complexity and error probability of manual configuration. At the same time, the configuration parameters are checked for validity, and the default value can be automatically used or the user can be prompted to correct when an error is found, thereby improving the flexibility and accuracy of the configuration. The present invention introduces a thread pool management and memory buffer reservation mechanism to ensure that the system can still maintain high efficiency and stability during multi-task concurrent processing. In addition, by initializing a keep-alive timer and a log system, the robustness and traceability of the system are further enhanced. The present invention can monitor network failures and server errors in real time through a perfect exception handling mechanism, and take corresponding countermeasures. For example, when the network is interrupted, the system will record fault information, send an alarm notification, cache unsuccessfully reported data, and try to re-establish a connection based on a preset strategy; when an error occurs on the server, the system will adopt different retry strategies according to the error type to ensure that the data can eventually be successfully uploaded to the server. After the data is reported, the system will perform cleanup tasks, close connections, and release resources in sequence to ensure that all resources are properly recycled and state variables are correctly saved. This service termination method helps maintain a clean system, prevent resource leakage and state confusion, and prepare for the next data report. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0062] Figure 1 A flowchart of an automatic data reporting method for an embedded system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0063] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art. It should be noted that, in the absence of conflict, the embodiments of the present invention and the features described in the embodiments can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0064] like Figure 1 As shown, in some embodiments of the present application, this embodiment provides an automatic data reporting method for an embedded system. Specifically, the method includes the following steps:

[0065] Step S101, read and load a preset configuration file, and initialize resources according to the configuration requirements of the configuration file, including allocating memory, creating a thread pool, setting a timer, and initializing a log system.

[0066] As mentioned above, during the startup phase of an embedded system, it is first necessary to read a pre-set configuration file from a storage medium (such as flash memory, EEPROM, or an external memory card). The configuration file contains all the parameters and setting information required for the system to run, including server address, port number, authentication information, protocol type, keep-alive interval, etc. By loading these configurations, the system can automatically complete the initialization process, reducing the need for manual intervention and improving the accuracy and efficiency of the configuration. Once the configuration file is successfully loaded, the system will perform a series of resource initialization operations based on the parameters therein, including: allocating memory to ensure that the system will not crash or degrade due to insufficient memory during operation; creating a thread pool to improve the system's response speed and throughput; setting a timer to ensure that the connection with the server can be maintained even when there is no data transmission for a long time; initializing the log system to provide a basis for subsequent maintenance and optimization.

[0067] For example, suppose there is a temperature sensor node deployed in a smart home environment, which needs to regularly report the collected temperature data to the cloud server. To achieve this function, the system will read the configuration file and initialize resources at startup. Reading the configuration file means that the system reads the configuration file named config.json from the built-in flash memory, which includes: server address, port number, user name and password, protocol type, keep-alive interval, log level, log output path, etc. Resource initialization includes: allocating memory. The system allocates 1MB of memory space for the data buffer to temporarily store the collected temperature data. At the same time, it allocates 512KB of memory for the message queue to store the data packets to be sent; creating a thread pool. According to the configuration file, the system creates a thread pool containing 4 threads. These threads will be responsible for concurrently processing data collection, data encapsulation and data sending tasks to ensure that the system can efficiently process data from multiple sensor nodes; setting a timer. The system initializes a timer that is triggered every 60 seconds to send keep-alive packets. When the timer is triggered, the system sends a simple HTTP request to the server to confirm the status of the network connection; initializing the log system. The system sets the log level to I NFO and sets the log output path to / var / log / sensor.log. In this way, all important events during the system operation will be recorded in the log file for subsequent viewing and analysis.

[0068] It should be noted that in a specific implementation scenario, a multi-configuration file support solution can be adopted on the basis of the above solution, that is, in order to adapt to different application scenarios, the system supports the selection of multiple configuration files. For example, users can place multiple configuration files (such as config_dev.json, confi g_prod.json) on the device and specify the configuration file to be loaded through command line parameters or environment variables. This method allows the system to automatically adjust its behavior according to different environments (development, testing, production), thereby enhancing the flexibility and maintainability of the system; a dynamic configuration update solution is adopted, that is, during the operation of the system, users can modify the configuration parameters through a remote management interface (such as an API or a Web interface), and they will take effect in real time. For example, users can adjust the keep-alive interval, change the server address, or modify the log level without restarting the device. This dynamic update mechanism not only improves the flexibility of the system, but also reduces the downtime caused by configuration changes. The above optional solutions all fall within the scope of protection of this application.

[0069] Step S102: According to the configuration reporting parameters set in the configuration file, data collection, data preprocessing and data packaging are performed in sequence.

[0070] As mentioned above, after completing resource initialization, the system will guide the subsequent data processing process according to the reporting parameters set in the configuration file. These reporting parameters include the time interval for data collection, the method of data preprocessing, the format of data encapsulation, etc. Through these parameters, the system can flexibly adjust the specific behavior of data processing to adapt to different application scenarios and needs. The system will regularly collect raw data from sensors or other data sources at the time interval specified in the configuration file to realize data collection; the collected raw data needs to be preliminarily processed to remove noise, filter, format, etc. to ensure the quality and consistency of the data; the preprocessed data will be encapsulated according to the format defined in the configuration file for subsequent transmission and analysis.

[0071] For example, there is an intelligent agricultural monitoring system that deploys multiple sensor nodes to monitor environmental parameters such as soil moisture, air temperature, and light intensity, and regularly reports these data to the cloud server. First, configure the reporting parameters according to the settings in the configuration file, including data collection time interval, data preprocessing method, data encapsulation format, reporting protocol, server address, and port number. Perform data collection, that is, the system collects data from each sensor every 30 seconds. For example, the soil moisture sensor measures the current soil moisture percentage, the air temperature sensor measures the ambient temperature, and the light intensity sensor measures the current light intensity. For the soil moisture sensor, the system removes the noise generated during the measurement process and filters the data to ensure the stability of the data. For example, if the measurement results fluctuate greatly for several consecutive times, the system takes the average value as the final humidity value; for the air temperature sensor, the system filters out abnormally high temperature values ​​(such as more than 50°C) to avoid false alarms; for the light intensity sensor, the system converts the measurement results into standard units (such as lux) and formats them to ensure data consistency. The preprocessed data will be encapsulated into TLV format. For example, assuming the collected data includes soil moisture, 65% (tag: 0x01, length: 1 byte, value: 65); air temperature, 25℃ (tag: 0x02, length: 1 byte, value: 25); light intensity, 800 lux (tag: 0x03, length: 2 bytes, value: 800). These data will be combined into a complete TLV unit and further concatenated into the final report data packet, ready to be sent to the server.

[0072] It should be noted that, in a specific implementation scenario, an adaptive data acquisition frequency scheme can also be adopted on the basis of the above scheme, that is, the system dynamically adjusts the frequency of data acquisition according to changes in the actual environment. For example, when a significant change in environmental parameters is detected (such as a sudden increase in temperature or a sharp drop in humidity), the system can automatically shorten the acquisition interval and increase the frequency of data acquisition to capture more details; on the contrary, when the environment is relatively stable, the system can appropriately extend the acquisition interval to reduce unnecessary energy consumption and data transmission. This adaptive mechanism enables the system to optimize resource utilization while ensuring data quality. A multi-format data encapsulation scheme is adopted, that is, in order to adapt to different reporting protocols and server requirements, the system can support multiple data encapsulation formats. For example, in addition to the common TLV format, the system can also support formats such as JSON, XML, and Protobuf. Users can select a suitable encapsulation format through a configuration file, or let the system automatically select the most suitable format according to the requirements of the target server. This method not only improves the compatibility of the system, but also simplifies development and maintenance work. The above optional schemes all belong to the protection scope of this application.

[0073] Step S103: Establish a connection with the target server according to the protocol selected in the configuration reporting parameters and report the encapsulated data.

[0074] As mentioned above, after completing data collection, preprocessing and packaging, the system will determine the communication protocol used for this data reporting based on the reporting parameters set in the configuration file. Common protocols include HTTP, HTTPS, MQTT, CoAP, etc. According to the selected protocol, the system will send a connection request to the target server specified in the configuration file and provide the necessary authentication information (such as user name and password). The server will verify this information and return a successful connection response after confirmation. If the connection fails, the system will record the error information and retry or issue an alarm notification according to the preset strategy. Once the connection is successfully established, the system will send the encapsulated data packet to the target server through the established connection.

[0075] For example, there is a smart home system that deploys multiple sensor nodes to monitor indoor temperature, humidity, and air quality, and regularly reports these data to the cloud server. The system reads the following parameters from the configuration file config.json: reporting protocol, MQTT; server address, mqtt.example.com; port number, 1883; user name, sensor_user; password, sensor_password; keep-alive interval, 60 seconds. The system uses the MQTT protocol to send a connection request to port 1883 of mqtt.example.com, and provides the user name sensor_user and password sensor_password. The server verifies these authentication information and returns a successful connection response after confirmation. At this time, the system and the server are connected and data can be transmitted. The system sends the previously encapsulated data packets (such as temperature, humidity, air quality, etc.) to the server through the established MQTT connection. After receiving the data, the server returns a confirmation reply, indicating that the data has been successfully received. The system records this successful transmission and continues to collect and report subsequent data.

[0076] It should be noted that in a specific implementation scenario, a dynamic protocol switching solution can be adopted on the basis of the above solution, that is, the system dynamically adjusts the communication protocol according to the network status or server feedback. For example, when insufficient network bandwidth is detected, the system can automatically switch from HTTP to a lighter MQTT or CoAP protocol to reduce bandwidth usage; when the network is restored to stability, the system can switch back to the HTTP protocol. This dynamic switching mechanism can effectively cope with complex network environments and ensure the reliability and efficiency of data transmission. A multi-server redundancy solution is adopted, that is, in order to improve the reliability of data transmission, the system configures multiple target servers as redundant backups. When the main server is unavailable, the system will automatically switch to the backup server and continue to report data. This method not only improves the fault tolerance of the system, but also avoids data loss caused by single point failures. The above optional solutions all fall within the scope of protection of this application.

[0077] Step S104: monitor abnormal situations in the reporting process in real time, and execute corresponding abnormal handling mechanisms according to the abnormal situations.

[0078] As mentioned above, during the data reporting process, the system will continuously monitor multiple links such as network connections and server responses to promptly detect and handle possible abnormal situations. Common abnormalities include but are not limited to: network failures, such as network interruptions, packet loss, and excessive latency; server errors, such as server connection rejection, authentication failure, request timeout, and server internal errors (500 series errors). The system captures these abnormal situations in real time through the built-in monitoring module and records detailed log information for subsequent analysis and troubleshooting. Once an abnormality is detected, the system will take appropriate processing measures based on the specific type of abnormality to ensure data security and system stability. The processing mechanism usually includes the following aspects: logging, which records in detail the time, type, cause and related parameters of the exception, providing a basis for subsequent troubleshooting; alarm notification, which sends exception alarms to administrators in a timely manner through SMS, email or push notifications, reminding them to take necessary actions; caching data, which temporarily stores data that has not been successfully reported in local storage to prevent data loss, and re-uploads it after the network or server returns to normal; retry mechanism, which automatically attempts to re-establish a connection or re-send data according to preset strategies to ensure that the data can eventually be successfully uploaded; post-recovery processing, after the network or server returns to normal, the system will immediately upload the cached data to the server, synchronize the status with the server, clean up the local cache and update the log file.

[0079] For example, an industrial automation system deploys multiple sensor nodes to monitor the operating status of production equipment and regularly reports this data to the cloud server. The system will continuously monitor the status of the network connection to check whether there is a network interruption, packet loss or high latency. For example, if the network latency exceeds 100 milliseconds, the system will mark the network as unstable. The system will also monitor the response of the server to check whether there are problems such as server rejection of connection, authentication failure or request timeout. For example, if the server fails to return a confirmation reply within 30 seconds, the system will consider the server response to have timed out. When a network interruption is detected, the system will record the time, type and last successful connection time of the interruption, and send an alarm notification to the administrator via SMS and email; at the same time, the system will temporarily store the data that failed to be reported successfully in the local storage, and based on the preset time interval strategy (such as retrying every 5 minutes), gradually increase the retry interval and try to reestablish the network connection; once the network is restored, the system will immediately upload the cached data to the server, synchronize the status with the server, clean up the local cache and update the log file. When it is detected that the server refuses the connection or the authentication fails, the system will record the time, type, request URL and request parameters of the error, and send an alarm notification to the administrator via SMS and email; for temporary server errors (such as server busy), the system will immediately resend the request and retry up to 3 times; for persistent server errors (such as server crashes), the system will execute a delayed retry strategy, based on a preset time interval (such as retrying every 10 minutes), gradually increasing the retry interval until the server returns to normal; once the server returns to normal, the system will immediately upload the cached data to the server, synchronize the status with the server, clean up the local cache and update the log file.

[0080] It should be noted that in specific implementation scenarios, a multi-level alarm mechanism can be adopted on the basis of the above scheme, that is, in order to better deal with different types of abnormal situations, the system introduces a multi-level alarm mechanism. For example, for minor abnormalities (such as short-term network jitter), the system can only record logs without sending alarm notifications; for more serious abnormalities (such as long-term network interruptions or server errors), the system can send alarm notifications via SMS or email; for very urgent situations (such as key equipment failures or security incidents), the system can send emergency alarms via phone or instant messaging tools to ensure that relevant personnel can respond in time. This hierarchical alarm mechanism not only improves the pertinence of alarms, but also avoids unnecessary interference. A data priority management scheme is adopted, that is, in order to optimize the efficiency of data transmission, the system sets different priorities according to the importance and urgency of the data. For example, for critical alarm information or abnormal data, the system can report immediately to ensure timely response; for conventional environmental monitoring data, the system can choose to report in batches to reduce the number of network transmissions. In addition, when network or server resources are tight, the system can give priority to high-priority data to ensure that important information is not missed. This method not only improves the efficiency of data transmission, but also ensures the timely delivery of key information. The above optional solutions all belong to the protection scope of this application.

[0081] Step S105: After the reporting is completed, the service termination mechanism is executed, including cleaning up tasks, closing connections, and releasing resources.

[0082] As mentioned above, after the data is successfully reported to the target server, the system needs to perform a series of service termination operations to ensure that all resources are properly recycled and the system status remains clean. This process not only helps to improve the stability and efficiency of the system, but also prepares for the next data reporting. Cleanup tasks refer to canceling or terminating all activities and operations related to the current data reporting; closing the connection refers to disconnecting the network connection with the target server and releasing resources related to network communication; releasing resources refers to recycling all system resources allocated during the data reporting process to ensure that there is no resource leakage.

[0083] For example, a smart home system deploys multiple sensor nodes to monitor indoor temperature, humidity, and air quality, and regularly reports these data to the cloud server. After the data is successfully reported, the system performs the following steps: clean up tasks, close connections, and release resources. Clean up tasks include canceling event listeners. The system will cancel all registered event listeners, such as temperature change listeners, humidity change listeners, etc., to prevent these listeners from continuing to trigger unnecessary operations; turning off the keep-alive timer. The system will stop the keep-alive timer to prevent it from continuing to send keep-alive packets periodically and wasting network resources; clearing the data buffer in the memory. The system will clear the buffer in the memory used to temporarily store temperature, humidity, and air quality data, release the occupied memory space, and ensure that there is enough available memory for the next data collection. Closing the connection includes disconnecting the network connection. The system will terminate the TCP connection with the cloud server to ensure that no data is transmitted; releasing network interface resources. The system will turn off the Wi-Fi or Ethernet interface to release hardware resources related to network communication; cleaning the connection pool. If the system uses a connection pool management mechanism, it will return all unused connections to the connection pool, or directly close the connection pool to release related resources. Releasing resources includes recycling thread pool resources. The system will terminate all working threads in the thread pool and release the CPU and memory resources occupied by the thread pool. Releasing memory blocks. The system will release all memory blocks allocated during data collection, preprocessing and packaging to ensure that the system memory is restored to its initial state. Saving state variables. The system will save the current state variables (such as configuration parameters, running status, etc.) to the local storage so that they can be quickly restored at the next startup.

[0084] It should be noted that in a specific implementation scenario, a phased termination scheme can be adopted on the basis of the above scheme, that is, the system will gradually perform the operations of cleaning up tasks, closing connections and releasing resources in a predetermined order to ensure that each stage can be successfully completed, for example, first cleaning up tasks, then closing connections, and finally releasing resources. This method not only improves the stability of the termination process, but also avoids system crashes or resource leaks caused by untimely release of resources. An exception handling and retry scheme is adopted, that is, in order to cope with possible abnormal situations, the system introduces an exception handling and retry mechanism in the termination process. For example, if a network failure occurs when closing a connection, the system can try to re-establish a connection to ensure that all resources can be released smoothly; if an error occurs when releasing resources, the system can record detailed error information and retry or alarm notification according to a preset strategy. This method not only improves the reliability of the termination process, but also ensures that the system is always in the best state. The above optional schemes all belong to the protection scope of this application.

[0085] In some embodiments of the present application, in order to automatically complete resource initialization according to a preset configuration file and ensure efficient and stable operation in a resource-constrained environment, the preset configuration file is read and loaded, and resource initialization is performed according to the configuration requirements of the configuration file, including allocating memory, creating a thread pool, setting a timer, and initializing a log system, specifically:

[0086] Read and load the preset configuration file from the memory, including the server address, port number, authentication information, protocol type and keep-alive interval;

[0087] Perform validity check on the loaded configuration parameters. If the validity check finds an error, log it and try to use the default value, and / or prompt the user to make corrections.

[0088] Allocate memory according to configuration requirements and reserve buffers and queues for subsequent operations;

[0089] Create a thread pool for concurrent processing tasks, including data collection, data packaging, and data sending;

[0090] Initializing a timer according to the keep-alive interval to periodically trigger the sending of keep-alive packets;

[0091] Specify the log level and output path to log important events throughout the process.

[0092] As mentioned above, when the system starts, it first reads the preset configuration file from the memory, which contains all the parameters and setting information required for the system to run, such as server address, port number, authentication information, protocol type, and keep-alive interval. By loading these configurations, the system can automatically complete the initialization process, reduce the need for manual intervention, and improve the accuracy and efficiency of the configuration. After loading the configuration file, the system will check the validity of the parameters therein. Specifically, the system will verify whether each parameter conforms to the expected format and range. If any errors or invalid parameters are found, the system will record detailed log information and try to use the preset default values ​​instead. For example, if the server address is empty or incorrectly formatted, the system can use the default local test server address; if the authentication information is invalid, the system can temporarily disable the authentication mechanism and allow the user to manually enter the correct credentials. In addition, the system can also prompt the user to correct the errors in the configuration file to ensure that the system can start and run normally. In order to ensure that the system has enough memory available in subsequent operations, the system will allocate memory according to the requirements in the configuration file. Specifically, the system will reserve buffers and queues for operations such as data acquisition, preprocessing, and transmission. Reasonable memory allocation not only improves the performance of the system, but also avoids crashes or performance degradation caused by insufficient memory. In order to improve the concurrent processing capability of the system, the system will create a certain number of worker threads according to the thread pool parameters in the configuration file. These threads can perform multiple tasks in parallel, including data collection, data encapsulation and data transmission. The introduction of the thread pool not only improves the response speed and throughput of the system, but also reduces the overhead caused by frequent creation and destruction of threads. In order to maintain the connection status with the target server, the system will initialize a timer according to the keep-alive interval in the configuration file. The timer will periodically trigger the sending of keep-alive packets to ensure that the connection can still be effective when there is no data transmission on the network for a long time. This mechanism not only improves the stability of the system, but also can timely discover and handle network failures. In order to facilitate troubleshooting and system monitoring, the system will initialize the log system according to the log level and output path in the configuration file. The log system can record important events during the system operation, such as configuration loading, resource allocation, exception handling, etc. Users can specify the log detail level (such as DEBUG, INFO, WARN, ERROR) and the log output path (such as file, console or remote server) through the configuration file. In this way, all important events during the system operation will be recorded in the log file, providing a basis for subsequent maintenance and optimization.

[0093] In some embodiments of the present application, in order to monitor the device status and abnormal conditions in real time and take corresponding reporting actions according to different trigger conditions to ensure the timeliness and accuracy of data, the reporting parameters are configured according to the settings in the configuration file, specifically:

[0094] According to the settings in the configuration file, determine the protocol to be used for this report, and initialize the corresponding client library accordingly;

[0095] Configure necessary connection parameters for the selected protocol, including server address, port, user name and password;

[0096] Register a series of event listeners to monitor trigger conditions such as device status changes and abnormal alarms, and associate corresponding reporting actions.

[0097] As mentioned above, the system will determine the communication protocol to be used for this data reporting based on the reporting parameters set in the configuration file. Common protocols include HTTP, HTTPS, MQTT, CoAP, etc. According to the selected protocol, the system will initialize the corresponding client library. These client libraries provide the functions and interfaces required to communicate with the target server to ensure that the system can correctly send and receive data. After determining the communication protocol, the system will configure the necessary connection parameters according to the settings in the configuration file. These parameters usually include: server address, that is, the IP address or domain name of the target server; port number, that is, the port number listened by the target server; user name, that is, the user name used for authentication; password, that is, the password used for authentication. The system will pass these parameters to the corresponding client library to ensure that the correct authentication information and connection address can be provided during the connection process. In order to monitor trigger conditions such as device status changes and abnormal alarms, and associate corresponding reporting actions, the system will register a series of event listeners. Specifically, the system will monitor device status changes and abnormal alarms. Each event listener is associated with a corresponding reporting action, including instant reporting, batch reporting, and conditional reporting.

[0098] In some embodiments of the present application, in order to monitor the device status and abnormal conditions in real time, and take corresponding reporting actions according to different trigger conditions, to ensure the timeliness and accuracy of data, while optimizing resource utilization and improving the stability and reliability of the system. A series of event listeners are registered to monitor trigger conditions such as device status changes and abnormal alarms, and associate corresponding reporting actions, specifically:

[0099] Monitoring device status changes includes sensor data monitoring and system log monitoring, wherein the sensor data monitoring is used to capture and process sensor reading changes, and the system log monitoring is used to track system operation status in real time;

[0100] Abnormal alarm includes fault detection and safety event response to trigger the alarm mechanism and respond in time according to the cause of the fault;

[0101] Reporting actions include instant reporting, batch reporting and conditional reporting. The instant reporting is used to report relevant data to the server immediately when the listener captures an important event. The batch reporting is used to accumulate frequently occurring low-priority events for a period of time and then report them to the server in a unified manner; the conditional reporting is used to decide whether to report to the server based on preset rules or policies.

[0102] As mentioned above, the system will register a series of event listeners to monitor the status changes of the device in real time, including sensor data monitoring and system log monitoring. Sensor data monitoring includes capturing and processing changes in sensor readings and processing sensor data, that is, the system will continuously monitor the connected sensors and capture changes in their readings; and will perform preliminary processing on the captured sensor data to ensure the accuracy and consistency of the data. System log monitoring includes real-time tracking of system operation status and recording of important events, that is, the system will monitor its own operation status. By analyzing the system log, the system can promptly discover potential problems; the system log records important events during the system operation, which is not only helpful for troubleshooting, but also can be used as a basis for triggering reporting actions.

[0103] In order to deal with abnormal situations that may occur during the operation of the device, the system will register event listeners to monitor abnormal alarms, including fault detection and security event response. Fault detection includes device hardware or software fault detection, that is, the system will monitor the hardware and software status of the device to detect whether there is a fault. When a fault is detected, the system will immediately trigger the alarm mechanism and record detailed fault information; trigger the alarm mechanism, that is, according to the cause and severity of the fault, the system will take different alarm measures. For example, for minor faults (such as short network interruptions), the system will record logs and try to recover automatically; for serious faults (such as hardware damage), the system will immediately send an alarm notification to the administrator and take emergency measures, such as restarting the device or switching to a backup device. Security event response, that is, the system will monitor possible security threats and take immediate measures when a security incident is detected, such as disconnecting the network connection, locking the device, recording event logs, etc. And the system will respond in time according to the type and severity of the security incident. For example, when an illegal login attempt is detected, the system will immediately lock the account and send an alarm notification to the administrator; when data tampering is detected, the system will record the time and content of the tampering and report the relevant information to the server.

[0104] According to different trigger conditions, the system will perform corresponding reporting actions, including instant reporting, batch reporting and conditional reporting. Instant reporting means that for important and urgent events, the system will immediately trigger the reporting operation to ensure that the data can be transmitted to the server in time. It is suitable for events that need to be processed immediately to ensure that relevant personnel can obtain key information in the first time and take necessary measures. Batch reporting means that for frequent but low-priority events, the system will accumulate them for a period of time (such as every hour or every day) and then report them to the server uniformly. It is suitable for those events that do not need to be processed immediately. Through batch processing, it can optimize resource utilization and improve overall efficiency. Conditional reporting means that the system can determine whether certain events need to be reported based on preset rules or policies. By allowing users to flexibly set reporting conditions according to actual needs and avoid unnecessary data transmission, it not only improves the intelligence level of the system, but also reduces unnecessary resource consumption.

[0105] In some embodiments of the present application, in order to efficiently complete data collection, preprocessing and packaging, ensure the quality and consistency of reported data, and optimize the efficiency and reliability of data transmission, data collection, data preprocessing and data packaging are performed in sequence, specifically:

[0106] Data is collected periodically through sensors associated with the data source;

[0107] Perform preliminary processing on the collected raw data, including noise removal, filtering and formatting;

[0108] Search the predefined tag mapping table according to the data type and assign a unique tag to each piece of data;

[0109] Measure the actual length of each Value part, and combine it with the Tag to form a complete TLV unit;

[0110] Each TLV unit is connected in series to form a final reporting data packet.

[0111] As mentioned above, the system will periodically collect data from sensors related to the data source according to the time interval set in the configuration file and store it in a buffer in the memory. In order to ensure the quality and consistency of the data, the system will perform preliminary processing on the collected raw data, including noise removal, that is, the system will identify and filter out abnormal data points caused by environmental interference or other factors; filtering, that is, the system will filter the data to eliminate unnecessary fluctuations or outliers; formatting, that is, the system will format the processed data to ensure that it meets the requirements of subsequent processing and transmission. In order to facilitate the server-side parsing and processing of reported data, the system will search the predefined Tag mapping table according to the data type and assign a unique tag to each piece of data. The Tag mapping table is usually pre-defined by the developer and contains identifiers for different types of data. In order to improve the efficiency and reliability of data transmission, the system will encapsulate each piece of data into a TLV (Type-Length-Value) unit, including measuring the actual length of the Value part, that is, the system will calculate the actual length (Length) of each piece of data, that is, the number of bytes occupied by the data value (Value); combined into a TLV unit, that is, the system will combine the Tag, Length and Value into a complete TLV unit. The structure of each TLV unit includes: Type (Tag), which is a unique identifier indicating the data type, usually 1 to 2 bytes; Length, which indicates the actual length of the data value, usually 1 to 2 bytes; Value, which indicates the actual data value, and the length is specified by the Length field. In order to facilitate server-side parsing and ensure the integrity and accuracy of the data, the system will connect all generated TLV units in series in sequence and package them into a complete report data packet. The server can quickly identify the type of each piece of data based on the Tag field of the TLV unit and accurately extract the data value based on the Length field.

[0112] In some embodiments of the present application, in order to ensure reliable data transmission and improve the stability and reliability of the system, a connection is established with the target server and the encapsulated data is reported and sent according to the protocol selected in the configuration reporting parameters, specifically:

[0113] According to the determined protocol, a connection request is sent to the target server, and necessary authentication information is provided, wherein the authentication information includes a user name and a password, and a response returned by the target server is received to determine whether the connection is successful;

[0114] Sending the encapsulated data to the target server through the established connection, and waiting for a confirmation reply from the target server to ensure that the data is correctly received;

[0115] If the confirmation reply is not received, retry according to the preset strategy.

[0116] As mentioned above, the system will determine the communication protocol to be used for this data reporting according to the reporting parameters set in the configuration file. According to the selected protocol, the system will initialize the corresponding client library and send a connection request to the target server through the library. The connection request includes: server address, that is, the IP address or domain name of the target server; port number, that is, the port number listened by the target server; user name and password, which are credentials for authentication to ensure that only authorized devices can access the server. The system will pass this information to the client library, which will be responsible for building and sending the connection request. After receiving the request, the target server will verify the provided authentication information. If the verification is successful, the server will return a successful connection response; if the verification fails, the server will return an error message. Once the connection is successfully established, the system will send the encapsulated data packet to the target server through the established connection, that is, the system will send the previously encapsulated TLV unit or other format data packet to the server through the connection. At the same time, during the sending process, the system will ensure the integrity and accuracy of the data to avoid data loss or damage. After sending the data, the system will wait for the target server to return a confirmation reply, indicating that the data has been received correctly. If the server fails to return a confirmation reply within the preset time, the system will consider the data transmission to have failed. In order to ensure that data can be successfully uploaded to the server, the system will process according to the preset retry strategy if no confirmation reply is received. The preset retry strategy includes: the system will record detailed log information, including the time when the confirmation reply was not received, the content of the data packet, possible reasons, etc., to provide a basis for subsequent troubleshooting; the system will gradually increase the number of retries according to the preset time interval to avoid network congestion or server overload caused by frequent retries; the system will set a maximum number of retries (for example, 3 times). If it still fails after reaching the maximum number of retries, the system will temporarily store the unsuccessfully reported data in the local storage and retry uploading after the network or server returns to normal; if multiple retries fail, the system can send an alarm to the administrator through SMS, email or push notification, reminding him to take necessary measures, such as checking the network connection or server status; for data that failed to be successfully reported, the system will temporarily store it in the local storage to ensure that the data will not be lost. When the network or server returns to normal, the system will automatically resend the cached data to ensure that all data can be finally uploaded to the server.

[0117] In some embodiments of the present application, in order to monitor the abnormal situation in the reporting process in real time and take corresponding processing measures according to the specific abnormal type to ensure the security of data and the stability of the system. Real-time monitoring of abnormal situations in the reporting process, and executing corresponding abnormal handling mechanisms according to the abnormal situations, specifically:

[0118] Real-time monitoring of abnormal situations during the reporting process, including network failures and server errors;

[0119] The corresponding exception handling mechanism is executed according to the abnormal situation, and the exception handling mechanism includes logging, alarm notification, cache data, retry mechanism and post-recovery processing.

[0120] As mentioned above, during the data reporting process, the system will continuously monitor multiple key links and detect possible abnormal situations in real time, including network failures and server errors. Network failures include network interruptions, packet loss, and excessive latency; server errors include server connection rejection, authentication failure, request timeout, and server internal errors. Once an abnormal situation is detected, the system will take corresponding processing measures based on the specific type of abnormality to ensure data security and system stability. Specific exception handling mechanisms include logging, alarm notifications, caching data, retry mechanisms, and post-recovery processing.

[0121] In some embodiments of the present application, in order to effectively record abnormal situations, notify administrators, protect data, and quickly resume normal operation after the network is restored when a network failure occurs, to ensure data security and system stability, a corresponding abnormality handling mechanism is executed according to the abnormal situation, and the abnormality handling mechanism includes logging, alarm notification, caching data, retry mechanism, and post-recovery processing, specifically:

[0122] When the abnormal situation is a network failure,

[0123] Record the time and type of network failure and the last successful connection time information;

[0124] Send network failure warning notifications to administrators via SMS and / or email;

[0125] Temporarily storing the data that failed to be reported successfully in the local storage;

[0126] Re-establishing the network connection based on a preset time interval strategy, wherein the preset time interval strategy increases the time interval duration in steps according to the number of reconnections;

[0127] After the network is restored, the data cached in the local memory is immediately uploaded to the server and the status is synchronized with the server. After all the cached data has been successfully received, the local cache is cleaned up and the log file is updated.

[0128] As mentioned above, when the system detects a network failure, it will immediately record detailed log information to ensure that effective troubleshooting and analysis can be carried out later. The specific content recorded includes the time when the network failure occurred, the type of network failure, and the last successful connection time. In order to promptly notify the administrator of the network failure, the system will send alarm notifications in a variety of ways, including SMS notifications and email notifications, to ensure that the administrator can receive the alarm information in a timely manner and take necessary measures. In order to prevent data loss, the system will temporarily store the data that has not been successfully reported in the local memory. The cached data can be the original TLV unit or compressed data to save storage space. At the same time, the system will regularly check the amount of cached data to ensure that it will not occupy too much storage resources due to excessive cache. If the amount of cached data is close to the storage limit, the system can prioritize caching high-priority data or delete older cached data. In order to restore the network connection, the system will gradually try to re-establish the network connection according to the preset time interval strategy, that is, the system will wait for a short time interval, such as 5 seconds, in the first retry, so that it can quickly respond to the network recovery situation; if the first retry fails, the system will gradually increase the retry time interval, for example, the second retry waits for 10 seconds, the third retry waits for 20 seconds, the fourth retry waits for 40 seconds, and so on. This method can avoid network congestion or server overload caused by frequent retries; at the same time, the system will set a maximum number of retries, such as 3 times. If it still fails after reaching the maximum number of retries, the system will stop automatic retrying and continue to cache data, waiting for the network or server to recover before trying to upload. When the network is restored, the system will immediately upload the data cached in the local storage to the server. During the upload process, the system will ensure the integrity and accuracy of the data to avoid repeated uploads or data loss. If the network problem is encountered again during the upload process, the system will continue to process according to the preset retry strategy. After the upload is completed, the system will synchronize the status with the server to ensure that the status of the local and server sides is consistent. After all cached data has been successfully received, the system will clean up the local cache to release the occupied storage space. The cleanup operation can be performed immediately or periodically to ensure that the system always has enough available storage space. The system will update the log file to record the time of network recovery, the amount of data successfully uploaded, and the time of local cache cleanup. These log information will help with subsequent system maintenance and optimization.

[0129] In some embodiments of the present application, in order to effectively record the abnormal situation, notify the administrator, protect the data, and quickly resume normal operation after the server returns to normal when a server error occurs, to ensure data security and system stability. According to the abnormal situation, a corresponding exception handling mechanism is executed, and the exception handling mechanism includes logging, alarm notification, caching data, retry mechanism, and post-recovery processing, specifically:

[0130] When the abnormal situation is a server error,

[0131] Record the time, type, request URL, and request parameter information of server errors;

[0132] Send server error warning notifications to administrators via SMS and / or email;

[0133] Temporarily storing the data that failed to be reported successfully in the local storage;

[0134] The server error includes a temporary server error and a persistent server error. For the temporary server error, the request is resent immediately and the retry is performed a maximum of a preset number of times;

[0135] For the persistent server error, a delayed retry is performed, that is, a resending request is performed based on a preset time interval strategy, wherein the preset time interval strategy increases the time interval duration in steps according to the number of times the resending request is performed;

[0136] After the server returns to normal, the data cached in the local memory is immediately uploaded to the server and the status is synchronized with the server. After all cached data has been successfully received, the local cache is cleaned up and the log file is updated.

[0137] As mentioned above, when the system detects a server error, it will immediately record detailed log information to ensure that effective troubleshooting and analysis can be carried out later. The specific recorded content includes: the time when the server error occurred, that is, accurately recording the time when the server error occurred; the type of server error, that is, describing the specific error type, such as server refused to connect, authentication failed, request timeout or server internal error (500 series error); request URL, that is, recording the request URL that caused the error in order to locate the specific interface of the problem; request parameters, that is, recording the request parameters sent to the server, including user name, password, data packet content, etc. In order to promptly notify the administrator of the server error, including SMS notification and email notification, to ensure that the administrator can receive the alarm information in time and take necessary measures. In order to prevent data loss, the system will temporarily store the data that failed to be successfully reported in the local storage. The cached data can be the original TLV unit or the compressed data to save storage space. At the same time, the system will regularly check the amount of cached data to ensure that it will not occupy too much storage resources due to excessive cache. If the amount of cached data is close to the storage limit, the system can cache high-priority data first or delete the older cached data. The nature of server errors includes temporary server errors and persistent server errors. Depending on the nature of the server errors, the system will adopt different retry strategies. For temporary server errors (such as server busy), the system will immediately resend the request and try to quickly resume data transmission; at the same time, the system will set a maximum number of retries, such as 3 times. If it still fails after reaching the maximum number of retries, the system will stop automatic retries and continue to cache data, waiting for the server to return to normal before trying to upload. For persistent server errors (such as server downtime), the system will perform delayed retries, that is, resend requests based on a preset time interval strategy, including: the system will wait for a shorter time interval, such as 5 seconds, during the first retry; if the first retry fails, the system will gradually increase the retry time interval, which can avoid network congestion or server overload caused by frequent retries; at the same time, the system will set a maximum number of retries, such as 5 times. If it still fails after reaching the maximum number of retries, the system will stop automatic retries and continue to cache data, waiting for the server to return to normal before trying to upload. When the server returns to normal, the system will immediately upload the data cached in the local storage to the server. If the network problem is encountered again during the upload process, the system will continue to handle it according to the preset retry strategy. After the upload is completed, the system will synchronize the status with the server to ensure that the status of the local and server sides is consistent. After all cached data has been successfully received, the system will clear the local cache and release the occupied storage space to ensure that the system always has enough available storage space.The system will update the log file to record the time of network recovery, the amount of data successfully uploaded, and the time of local cache cleanup. This log information will help with subsequent system maintenance and optimization.

[0138] In some embodiments of the present application, in order to improve the stability and efficiency of the system and to make full preparations for the next data reporting, a service termination mechanism is executed after the reporting is completed, including cleaning up tasks, closing connections, and releasing resources, specifically:

[0139] After the report is completed, the service termination mechanism is executed, which includes cleaning up tasks, closing connections, and releasing resources;

[0140] The cleanup task includes canceling all registered event listeners, turning off the keep-alive timer, and clearing the data buffer in the memory;

[0141] Closing the connection includes disconnecting the network connection and releasing resources related to the network communication;

[0142] The releasing of resources includes reclaiming thread pool resources, releasing all allocated memory blocks, and saving current state variables to the local memory.

[0143] As mentioned above, after the data is successfully reported to the target server, the system needs to perform a series of service termination operations to ensure that all resources are properly recovered. This process not only helps to improve the stability and efficiency of the system, but also prepares for the next data report. The cleanup task refers to canceling or terminating all activities and operations related to the current data report, including canceling all registered event listeners, that is, the system will cancel all registered event listeners to prevent these listeners from continuing to trigger unnecessary operations; turning off the keep-alive timer, that is, the system will stop the keep-alive timer to prevent it from continuing to send keep-alive packets periodically and wasting network resources; clearing the data buffer in the memory, that is, the system will clear the buffer in the memory used to temporarily store data, release the occupied memory space, and ensure that there is enough available memory for the next data collection. Closing the connection means disconnecting the network connection with the target server and releasing resources related to network communication to ensure that no data transmission is performed. Releasing resources means recycling all system resources allocated during the data reporting process to ensure that there is no resource leakage, including recycling thread pool resources, that is, the system will terminate all working threads in the thread pool and release the CPU and memory resources occupied by the thread pool. Timely recycling of thread pool resources can improve system performance and stability; releasing all allocated memory blocks, that is, the system will release all memory blocks allocated during data collection, preprocessing and packaging to ensure that the system memory is restored to its initial state; saving the current state variables to the local memory, that is, the system will save the current state variables (such as configuration parameters, running status, the time of the last data reporting, etc.) to the local memory so that it can be quickly restored at the next startup. This method can reduce the user's manual configuration requirements and ensure that the system can continue to work from the last state.

[0144] Compared with the prior art, the embodiment of the present application discloses an automatic data reporting method for an embedded system. By reading and loading a preset configuration file, the system can automatically complete the initialization process, reduce the complexity and error probability of manual configuration, and at the same time, check the validity of the configuration parameters, and automatically use the default value or prompt the user to correct it when an error is found, thereby improving the flexibility and accuracy of the configuration. The present invention introduces thread pool management and memory buffer reservation mechanism to ensure that the system can still maintain high efficiency and stability during multi-task concurrent processing. In addition, by initializing the keep-alive timer and log system, the robustness and traceability of the system are further enhanced. The present invention can monitor network failures and server errors in real time through a perfect exception handling mechanism, and take corresponding countermeasures. For example, when the network is interrupted, the system will record fault information, send alarm notifications, cache unsuccessfully reported data, and try to re-establish the connection based on the preset strategy; when an error occurs on the server, the system will adopt different retry strategies according to the error type to ensure that the data can eventually be successfully uploaded to the server. After the data is reported, the system will perform cleanup tasks, close connections, and release resources in sequence to ensure that all resources are properly recycled and state variables are correctly saved. This service termination method helps maintain a clean system, prevent resource leakage and state confusion, and prepare for the next data report.

[0145] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0146] The present application is described with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0147] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0148] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. An automatic data reporting method for an embedded system, characterized in that: include: Read and load the preset configuration file, and initialize resources according to the configuration requirements of the configuration file, including allocating memory, creating a thread pool, setting timers, and initializing the log system; According to the configuration reporting parameters set in the configuration file, data collection, data preprocessing and data packaging are performed in sequence; Establishing a connection with a target server and reporting the encapsulated data according to the protocol selected in the configuration reporting parameters; Monitor abnormal situations in the reporting process in real time and execute corresponding abnormal handling mechanisms according to the abnormal situations; After the report is completed, the service termination mechanism is executed, including cleaning up tasks, closing connections, and releasing resources.

2. The method according to claim 1, characterized in that The preset configuration file is read and loaded, and resources are initialized according to the configuration requirements of the configuration file, including allocating memory, creating a thread pool, setting a timer, and initializing a log system, specifically: Read and load the preset configuration file from the memory, including the server address, port number, authentication information, protocol type and keep-alive interval; Perform validity check on the loaded configuration parameters. If the validity check finds an error, log it and try to use the default value, and / or prompt the user to make corrections. Allocate memory according to configuration requirements and reserve buffers and queues for subsequent operations; Create a thread pool for concurrent processing tasks, including data collection, data packaging, and data sending; Initializing a timer according to the keep-alive interval to periodically trigger the sending of keep-alive packets; Specify the log level and output path to log important events throughout the process.

3. The method according to claim 1, characterized in that Configure the reporting parameters according to the settings in the configuration file, specifically: According to the settings in the configuration file, determine the protocol to be used for this report, and initialize the corresponding client library accordingly; Configure necessary connection parameters for the selected protocol, including server address, port, user name and password; Register a series of event listeners to monitor trigger conditions such as device status changes and abnormal alarms, and associate corresponding reporting actions.

4. The method according to claim 3, characterized in that Register a series of event listeners to monitor trigger conditions such as device status changes and abnormal alarms, and associate corresponding reporting actions, specifically: Monitoring device status changes includes sensor data monitoring and system log monitoring, wherein the sensor data monitoring is used to capture and process sensor reading changes, and the system log monitoring is used to track system operation status in real time; Abnormal alarm includes fault detection and safety event response to trigger the alarm mechanism and respond in time according to the cause of the fault; Reporting actions include instant reporting, batch reporting and conditional reporting. The instant reporting is used to report relevant data to the server immediately when the listener captures an important event. The batch reporting is used to accumulate frequently occurring low-priority events for a period of time and then report them to the server in a unified manner; the conditional reporting is used to decide whether to report to the server based on preset rules or policies.

5. The method according to claim 1, characterized in that Carry out data collection, data preprocessing and data packaging in turn, specifically: Data is collected periodically through sensors associated with the data source; Perform preliminary processing on the collected raw data, including noise removal, filtering and formatting; Search the predefined tag mapping table according to the data type and assign a unique tag to each piece of data; Measure the actual length of each Value part, and combine it with the Tag to form a complete TLV unit; Each TLV unit is connected in series to form a final reporting data packet.

6. The method according to claim 3, characterized in that According to the protocol selected in the configuration reporting parameters, a connection is established with the target server and the encapsulated data is reported and sent, specifically: According to the determined protocol, a connection request is sent to the target server, and necessary authentication information is provided, wherein the authentication information includes a user name and a password, and a response returned by the target server is received to determine whether the connection is successful; Sending the encapsulated data to the target server through the established connection, and waiting for a confirmation reply from the target server to ensure that the data is correctly received; If the confirmation reply is not received, retry according to the preset strategy.

7. The method according to claim 1, characterized in that Monitor abnormal situations in the reporting process in real time, and execute corresponding abnormal handling mechanisms according to the abnormal situations, specifically: Real-time monitoring of abnormal situations during the reporting process, including network failures and server errors; The corresponding exception handling mechanism is executed according to the abnormal situation, and the exception handling mechanism includes logging, alarm notification, cache data, retry mechanism and post-recovery processing.

8. The method according to claim 7, characterized in that Execute the corresponding exception handling mechanism according to the abnormal situation, which includes logging, alarm notification, cache data, retry mechanism and post-recovery processing, specifically: When the abnormal situation is a network failure, Record the time and type of network failure and the last successful connection time information; Send network failure warning notifications to administrators via SMS and / or email; Temporarily storing the data that failed to be reported successfully in the local storage; Re-establishing the network connection based on a preset time interval strategy, wherein the preset time interval strategy increases the time interval duration in steps according to the number of reconnections; After the network is restored, the data cached in the local memory is immediately uploaded to the server and the status is synchronized with the server. After all the cached data has been successfully received, the local cache is cleaned up and the log file is updated.

9. The method according to claim 7, characterized in that Execute the corresponding exception handling mechanism according to the abnormal situation, which includes logging, alarm notification, cache data, retry mechanism and post-recovery processing, specifically: When the abnormal situation is a server error, Record the time, type, request URL, and request parameter information of server errors; Send server error warning notifications to administrators via SMS and / or email; Temporarily storing the data that failed to be reported successfully in the local storage; The server error includes a temporary server error and a persistent server error. For the temporary server error, the request is resent immediately and the retry is performed a maximum of a preset number of times; For the persistent server error, a delayed retry is performed, that is, a resending request is performed based on a preset time interval strategy, wherein the preset time interval strategy increases the time interval duration in steps according to the number of times the resending request is performed; After the server returns to normal, the data cached in the local memory is immediately uploaded to the server and the status is synchronized with the server. After all cached data has been successfully received, the local cache is cleaned up and the log file is updated.

10. The method according to claim 1, characterized in that After the report is completed, the service termination mechanism is executed, including cleaning up tasks, closing connections, and releasing resources. Specifically: After the report is completed, the service termination mechanism is executed, which includes cleaning up tasks, closing connections, and releasing resources; The cleanup task includes canceling all registered event listeners, turning off the keep-alive timer, and clearing the data buffer in the memory; Closing the connection includes disconnecting the network connection and releasing resources related to the network communication; The releasing of resources includes reclaiming thread pool resources, releasing all allocated memory blocks, and saving current state variables to the local memory.

Images