Remote operation and maintenance method and system for embedded device and storage medium

Abstract

The application relates to a remote operation and maintenance method, system and storage medium of an embedded device, wherein the remote operation and maintenance method of the embedded device comprises the following steps: monitoring a file writing operation on a storage area in the embedded device, and acquiring calling stack information corresponding to the file writing operation; in the case that the operation frequency of the file writing operation is detected to be higher than a preset threshold, uploading the calling stack information to a cloud server; wherein the cloud server performs symbol analysis on the calling stack information, generates a function calling sequence, and outputs positioning and diagnosis information for abnormal writing operation of the embedded device based on the function calling sequence. Through the application, the problem that the operation and maintenance efficiency of the embedded device is low and code-level repair cannot be performed is solved.

Description

Technical Field

[0001] This application relates to the field of embedded systems, and in particular to remote operation and maintenance methods, systems and storage media for embedded devices. Background Technology

[0002] Embedded devices commonly use non-volatile storage media such as NOR / NAND FLASH, which have a limited number of physical erase / write cycles. During field operation, abnormally frequent file write operations caused by software defects can rapidly deplete the FLASH's lifespan, leading to data loss or device failure.

[0003] In real-world operating environments, the causes of frequent and abnormal FLASH writes are often complex and subtle. These can include program logic errors (such as incorrect log write-back strategies, excessive and frequent configuration saving, infinite loops writing to temporary files, etc.) or unexpected external environmental anomalies triggering large amounts of data writing. In related technologies, such anomalies are typically monitored by locally recording write counts or simple event reporting. However, these methods usually only record the event itself or provide a simple count, offering limited information dimensions. This makes it difficult to remotely and accurately trace the specific software code path that caused the abnormal writes, thus hindering remote and accurate diagnosis of which specific process or code logic triggered the abnormal writes. This results in low operational efficiency and an inability to perform code-level repairs.

[0004] Currently, no effective solution has been proposed to address the issues of low operational efficiency and inability to perform code-level repairs in embedded devices in related technologies. Summary of the Invention

[0005] This application provides a remote operation and maintenance method, system, and storage medium for embedded devices, to at least solve the problems of low operation and maintenance efficiency and inability to perform code-level repairs in related technologies.

[0006] In a first aspect, embodiments of this application provide a remote operation and maintenance method for an embedded device, the method comprising:

[0007] Monitor file write operations to the storage area of ​​the embedded device and obtain the call stack information corresponding to the file write operation;

[0008] If the frequency of file writing operations exceeds a preset threshold, the call stack information will be uploaded to the cloud server.

[0009] The cloud server performs symbolic parsing on the call stack information to generate a function call sequence, and outputs location and diagnostic information for abnormal write operations on the embedded device based on the function call sequence.

[0010] In some embodiments, uploading the call stack information to a cloud server includes:

[0011] Obtain the process identifier and file information corresponding to the file write operation;

[0012] The process identifier, file information, and call stack information are associated and uploaded to the cloud server; the cloud server determines the corresponding target symbol table based on the process identifier and uses the target symbol table to perform symbol resolution on the call stack information.

[0013] In some embodiments, the cloud server determines the corresponding target symbol table based on the process identifier, including:

[0014] The cloud server searches for and retrieves a target symbol table containing the process identifier from the archive library of the software integration environment, based on the process identifier and the device identifier information received from the embedded device.

[0015] In some embodiments, associating the process identifier, file information, and call stack information with the data and uploading them to a cloud server includes:

[0016] On the embedded device side, multiple file write operation events acquired within a fixed time window are statistically analyzed;

[0017] Write file operation events with the same call stack information and the same target file path are merged into a single statistical entry, and the total information, including the statistical entry and the associated process identifier, file information and call stack information, is uploaded to the cloud server.

[0018] In some embodiments, the method further includes:

[0019] The cloud server obtains the corresponding symbol table based on the process identifier or device identifier associated with the call stack information;

[0020] The cloud server uses the symbol table to resolve the addresses in the call stack information into corresponding function names, source code file names, and line numbers, and organizes them into the function call sequence according to a preset function call order.

[0021] In some embodiments, detecting the frequency of the file write operation includes:

[0022] The number of write operations to the FLASH storage area within a preset time window is counted; when the number of write operations exceeds a first threshold, it is determined that the preset threshold has been exceeded; or,

[0023] The total amount of data written within the preset time window is counted; when the total amount of data written exceeds the second threshold, it is determined that the preset threshold has been exceeded.

[0024] In some embodiments, obtaining the call stack information corresponding to the file write operation includes:

[0025] The eBPF program is executed in the kernel of the embedded device to obtain the first device identifier of the file write operation.

[0026] When the device identifier is detected to match the second device identifier in a preset storage area using the eBPF program, the corresponding call stack information is recorded.

[0027] In some embodiments, the eBPF program is attached to the standard library write function entry point of the embedded device via a userspace probe.

[0028] Secondly, embodiments of this application provide a remote operation and maintenance system for embedded devices, including a device-side monitoring module and a cloud server;

[0029] The device-side monitoring module is deployed in the embedded device and is used to monitor file write operations to the storage area in the embedded device, obtain the corresponding call stack information, and upload the call stack information when the frequency of file write operations exceeds a preset threshold.

[0030] The cloud server is used to perform symbolic resolution on the received call stack information to generate a function call sequence, and output location and diagnostic information for abnormal write operations on the embedded device based on the function call sequence.

[0031] Thirdly, embodiments of this application provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the remote operation and maintenance method for the embedded device as described in the first aspect above.

[0032] Compared to related technologies, the embodiments of this application provide a remote operation and maintenance method, system, and storage medium for embedded devices. This method monitors write file operations to the storage area of ​​the embedded device and obtains the call stack information corresponding to the write file operations. When the frequency of write file operations exceeds a preset threshold, the call stack information is uploaded to a cloud server. The cloud server performs symbolic resolution on the call stack information, generates a function call sequence, and outputs location and diagnostic information for abnormal write operations on the embedded device based on the function call sequence.

[0033] By directly monitoring write operations on the device and synchronously capturing their complete call stack information, a snapshot of code execution at the moment the problem occurred was successfully obtained. Simultaneously, stack information compression and selective uploading were implemented, allowing the cloud server, with its powerful storage and computing capabilities, to perform symbolic analysis on the received raw stack information. This enabled remote, automatic, and code-level precise location of software defects causing abnormal writes in resource-constrained embedded environments. This upgrades traditional, inefficient, and vague passive alerts to efficient and accurate proactive diagnosis, significantly improving operational efficiency and opening up a path for code-level repair. Therefore, it effectively solves the problem of low operational efficiency and the inability to perform code-level repairs on embedded devices.

[0034] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0035] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0036] Figure 1 This is a hardware structure block diagram of a terminal for a remote operation and maintenance method for an embedded device according to an embodiment of the present invention.

[0037] Figure 2 This is a flowchart of a remote operation and maintenance method for an embedded device according to an embodiment of this application;

[0038] Figure 3 This is a schematic diagram of an embedded device according to an embodiment of this application;

[0039] Figure 4 This is a flowchart of another remote operation and maintenance method for an embedded device according to an embodiment of this application. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application. Furthermore, it is understood that although the efforts made in such a development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, modifications to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0041] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0042] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application means two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The terms “first,” “second,” “third,” etc., used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0043] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. Taking running on a terminal as an example, Figure 1 This is a hardware structure block diagram of a terminal for a remote operation and maintenance method for an embedded device according to an embodiment of the present invention. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0044] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the remote operation and maintenance method for embedded devices in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0045] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0046] This embodiment provides a method for remote operation and maintenance of embedded devices. Figure 2 This is a flowchart of a remote operation and maintenance method for an embedded device according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0047] Step S210: Monitor file write operations to the storage area in the embedded device and obtain the call stack information corresponding to the file write operation.

[0048] In this step, all file write operations on the embedded device targeting a specific storage area (such as FLASH memory) are captured, and a snapshot of the software source code execution path that triggers each write operation is simultaneously captured, i.e., the call stack information. For example, monitoring file write operations can be achieved using mechanisms such as the inotify mechanism provided by the Linux kernel; alternatively, the eBPF (Extended Berkeley Packet Filter) technology framework can be used to monitor write events.

[0049] The aforementioned monitoring mechanism can be triggered at a precise moment for each such write operation, and it doesn't just record the result (such as success or failure), but rather deeply captures the complete software logic sequence driving the operation. More specifically, the monitoring program needs to examine the current write operation to a specific storage area, that is, to check the identifier of the underlying physical storage device of the file involved in the operation, i.e., the device number. By comparing this device number with the preset device numbers of the FLASH storage areas to be monitored, it can quickly determine whether this write falls within the monitoring scope. If not, it is ignored; if so, the next step is taken to ensure that only relevant operations are captured, avoiding the collection of large amounts of useless data.

[0050] After identifying the target, the monitoring program performs a call stack capture operation. During program execution, function A calls function B, and B then calls function C. The system internally uses a call stack structure to remember this order so that functions know where to return to when they need to. Capturing the call stack at the moment a write operation occurs involves tracing this complete call chain back layer by layer from the function currently performing the write operation until the program's entry point is recorded. What is recorded is a string of memory addresses, each address corresponding to the location of a function call.

[0051] Thus, through the above steps S210, the precise interception, filtering, context information capture, and event reporting of FLASH write operations are completed. The entire process occurs in kernel mode, takes very little time, and requires no modification to the monitored application code, achieving true non-intrusive monitoring.

[0052] Step S220: If the frequency of file writing operations exceeds a preset threshold, the call stack information is uploaded to the cloud server. The cloud server performs symbolic parsing on the call stack information, generates a function call sequence, and outputs location and diagnostic information for abnormal write operations on the embedded device based on the function call sequence.

[0053] The aforementioned monitoring mechanism does not simply report the stack information of every write operation in real time. Instead, it introduces a frequency-based judgment logic to achieve intelligent and economical data reporting. Specifically, the device continuously evaluates the frequency of file write operations. Here, operation frequency refers to the rate or density of write operation events occurring per unit time. The device needs to compare the real-time statistical or calculated operation frequency value with a preset threshold. This threshold is a configurable critical value, representing the upper limit of the normal write operation rate allowed by the system design. Its specific value (e.g., how many times per minute) and statistical time window (e.g., the past minute) are preset operation and maintenance strategy parameters. When the real-time operation frequency is detected to exceed this preset threshold, it is determined that abnormal or intensive write behavior has occurred within the current time period, triggering the reporting condition.

[0054] Once the triggering conditions are met, the device will upload the call stack information to the cloud server. This means that the device will transmit the call stack information corresponding to one or more write operations collected within the triggering period (usually the same time window as the frequency statistics) as data payload to the remote cloud server via a network connection. This upload may also include necessary encapsulation, packaging, or addition of device identifiers and other metadata by the device to form a complete upload data packet that can be recognized by the cloud, but its core content is still the original call stack information representing the code execution path.

[0055] After receiving the call stack information uploaded from the device, the cloud server initiates its core analysis function: symbol resolution. This is a crucial conversion process. Because the call stack information uploaded by the device is essentially a sequence of binary memory addresses, the cloud server needs to convert (i.e., resolve) these memory addresses into meaningful program symbols. To do this, the cloud server should access or obtain symbol table data that precisely corresponds to the software running on the device. A symbol table is a mapping data generated by the compiler when building software; it establishes the correspondence between the symbol names of functions, variables, etc., in the program and their final memory locations. By querying the correct symbol table, the cloud server can translate each stack address into a specific function name.

[0056] After completing the symbolic resolution of all addresses in the stack, the cloud server generates a function call sequence. This sequence is a readable list reflecting the function call hierarchy, formed by replacing the original address sequence with the corresponding function names (and possibly source code file names and line numbers, if a debug symbol table is used). For example, the original "[0x1234, 0x5678, 0x9abc]" is transformed into "main() -> save_config() -> write_to_flash()". This sequence clearly reveals which function and under what call relationship the write operation was ultimately performed.

[0057] Ultimately, the cloud server can combine the context of this upload (such as trigger frequency exceeding a threshold) and the information reflected by the sequence itself (such as frequently occurring specific call patterns) to make a comprehensive judgment and output a location diagnosis result; this information must be able to point to the code location that caused the abnormal write. Therefore, the diagnostic information will at least include or be derived from the previously generated function call sequence, thus clearly informing the operations and maintenance personnel or developers: which software module (corresponding process) in the device, and through which specific code execution path (function call sequence), was determined to have caused the abnormal write behavior. For example, the output information might be: "Alert: In the process 'app_service' of device [ID], the function call chain 'thread_loop() -> log_debug() -> file_write()' was detected to have a high-frequency write operation."

[0058] It should also be understood that the location diagnostic information output here is the conclusion of the analysis, which may take the form of an alarm notification, a diagnostic report, or a log entry.

[0059] In related technologies, the device side can only provide a general alarm of "frequent storage writes". The operation and maintenance personnel cannot remotely know which process or which code logic caused the problem. They are forced to rely on on-site log capture, manual reproduction and guess analysis, which is inefficient and difficult to find the root cause.

[0060] In comparison, the embodiments of this application, through the above steps S210 to S220, directly monitor the write operation on the device side and synchronously capture its complete call stack information, successfully obtaining a code execution snapshot at the moment the problem occurs. At the same time, the stack information is compressed and selectively uploaded, enabling the cloud server to utilize its powerful storage and computing capabilities to perform symbolic resolution on the received raw stack information. Thus, in resource-constrained embedded environments, remote, automatic, and code-level precise location of software defects causing abnormal writes is achieved. This upgrades the traditional inefficient and vague passive alarms to efficient and accurate proactive diagnosis, greatly improving operation and maintenance efficiency and opening up the path to code-level repair. Therefore, it effectively solves the problem of low operation and maintenance efficiency and inability to perform code-level repair on embedded devices.

[0061] In some embodiments, uploading the call stack information to a cloud server as described above may further include the following steps:

[0062] Obtain the process identifier and file information corresponding to the file write operation; associate the process identifier, file information and call stack information and upload them to the cloud server; the cloud server determines the corresponding target symbol table based on the process identifier and uses the target symbol table to perform symbol resolution on the call stack information.

[0063] The symbol table contains the mapping between function names and their corresponding memory addresses, which are the addresses recorded in the stack trace. With the symbol table, the corresponding function name can be found through the memory address in the stack trace; this is symbol resolution. The debugging symbol table contains more information, such as the filename and line number of the source code containing the function. Developers can use this information to trace the detailed order of function calls and confirm the current program code logic. During compilation, developers can choose whether to include the symbol table information in the final executable file / process. To reduce program size and prevent reverse engineering (understanding code logic), developers usually strip the symbol table information. After stripping, the running process only has addresses left, and it's impossible to directly know what each address represents.

[0064] Specifically, when the device performs a file write operation monitoring, it simultaneously acquires the process identifier (e.g., process ID or process name) and file information (e.g., file path) corresponding to the operation. The device then binds these two metadata pieces of information with the captured raw call stack information, forming an associated data packet which is uploaded to the cloud server. Upon receiving the data packet, the cloud server first extracts the process identifier and uses this identifier to search and match in a symbol table resource library stored in the cloud. This determines the target symbol table corresponding to the specific process. Then, using this explicitly selected target symbol table, the server performs symbol resolution on the raw call stack information in the data packet, which exists in the form of memory addresses. This translates each stack address into readable symbol information such as its corresponding function name and source code location.

[0065] Through the above embodiments, by strongly associating the process identifier captured by the device with the call stack information and uploading it, the cloud server can accurately match each piece of stack data with its own symbol table, thereby ensuring the accuracy of the symbol resolution results, avoiding function name resolution errors or failures caused by symbol table mismatches, and ensuring that the final output diagnostic information can reliably point to the real source code location that caused the exception write.

[0066] In some embodiments, the cloud server determining the corresponding target symbol table based on the process identifier may further include the following steps:

[0067] Based on the process identifier and the device identifier information received from the embedded device, the cloud server searches and retrieves the target symbol table containing the process identifier from the archive of the software integration environment.

[0068] After receiving uploaded data from the embedded device, the cloud server parses the data packets and extracts the process identifier and device identifier information. This device identifier uniquely identifies the embedded device's model and the specific firmware version it runs. Subsequently, the cloud server uses this identifier information as a query basis to access a separate software integration environment archive. This archive, established during the software development process, systematically stores all compiled output files corresponding to different device models and firmware versions, including symbol table files for each process. The server locates the corresponding device version directory based on the device identifier information, and then searches for and retrieves the target symbol table file containing the process's debugging information within that directory, ensuring that the retrieved symbol table is completely consistent with the device's runtime environment that generated the stack information.

[0069] Through the above embodiments, by establishing a dual precise matching mechanism that combines device identifiers and process identifiers, and based on a pre-built software integration environment archive library, it is ensured that the cloud server can obtain symbol table resources that are completely corresponding to the version for each anomaly diagnosis. This ensures the accuracy of stack parsing results and the reliability of diagnostic conclusions in complex actual deployment environments with multiple device models and firmware versions.

[0070] In some embodiments, the above-mentioned association of process identifier, file information, and call stack information with the cloud server may further include the following steps:

[0071] On the embedded device side, multiple write file operation events acquired within a fixed time window are statistically analyzed; write file operation events with the same call stack information and the same target file path are merged into a single statistical entry, and the total information, including the statistical entry and associated process identifier, file information, and call stack information, is uploaded to the cloud server.

[0072] In this step, the device-side program sets a fixed time window (e.g., one minute) and continuously captures multiple monitoring events triggered by file write operations within this window. For all events captured within the window, the program categorizes and merges them based on two strict equality conditions: first, the call stack information carried by the events must be completely identical; second, the target file paths pointed to by the events must also be completely identical. Only when both conditions are met will the corresponding events be merged into the same statistical entry. This merging process essentially aggregates scattered, repetitive events into a unique record. Finally, the device does not upload all the original events; instead, it packages the summary results containing these statistical entries, along with the process identifier, file information, and call stack information associated with each entry, as a complete set of information and uploads it to the cloud server.

[0073] Through the above embodiments, write file operation events within a fixed time window are statistically analyzed on the embedded device side based on call stack information and target file path. Events with the same source and operation object are aggregated into a single statistical entry. This significantly reduces the amount of data that needs to be uploaded to the cloud while retaining key diagnostic information (process identifier, file information, call stack), thereby reducing network transmission overhead and cloud storage and processing pressure. At the same time, this preprocessing makes the uploaded information more structured, highlighting high-frequency anomaly patterns. This helps the cloud server quickly and accurately locate the software code path that causes frequent FLASH writes, improving the efficiency and accuracy of remote diagnostics. Ultimately, this enables proactive and efficient maintenance of the embedded device's storage lifespan.

[0074] In some embodiments, the above method further includes the following steps:

[0075] The cloud server obtains the corresponding symbol table based on the process identifier or device identifier associated with the call stack information. The cloud server uses the symbol table to resolve the addresses in the call stack information into the corresponding function names, source code file names and line numbers, and organizes them into a function call sequence according to the preset function call order.

[0076] More specifically, after receiving the records uploaded by the device, the cloud server can retrieve the symbol table and debug symbol table containing the process that perfectly corresponds to the device's firmware version from the repository archived during software build, based on the device identification information such as the device model and version number, as well as the process name. Subsequently, the cloud server uses these obtained symbol tables to perform symbol resolution on the stack address list contained in each stack information entry in the record, converting the memory address into the corresponding function name. It then further uses the debug symbol table to parse out the source code file name and line number of the function. The cloud server organizes these parsed function names, file names, and line numbers according to the function call order represented by the stack addresses, reconstructing a complete function call sequence from the call initiation point to the final write operation point, for technical personnel to analyze.

[0077] Through the above embodiments, the cloud server matches the device and process identifiers and calls the pre-stored symbol table and debug symbol table to accurately restore the original memory address reported by the device to the specific function name, file name and line number. This transforms the unreadable stack address information into a function sequence with clear code location and call relationship that can be directly understood by technical personnel. This enables maintenance personnel to quickly and accurately locate the exact source code location that caused the FLASH abnormal write problem, greatly improving the efficiency and accuracy of remote diagnosis, while avoiding the performance overhead caused by complex parsing on resource-constrained devices.

[0078] In some embodiments, the process of detecting the frequency of file write operations may further include the following steps:

[0079] The system counts the number of write operations to the FLASH storage area within a preset time window. When the number of write operations exceeds a first threshold, it is determined that the preset threshold has been exceeded. Specifically, on the embedded device side, after receiving write operation information reported by the kernel via the perf event, the user-space program sets a fixed statistical time window (e.g., 1 minute). Within this time window, the program merges all received write operation events according to their stack address information and corresponding file paths. Each merged item, uniquely identified by a specific stack and file path, is recorded for its cumulative occurrence, i.e., the number of writes. When the time window ends, the program checks whether this cumulative number of writes exceeds the preset first threshold (e.g., 20 times per minute). If it does, the monitored file write operation frequency is determined to have exceeded the preset threshold.

[0080] Alternatively, the total amount of data written within a preset time window can be counted. When the total amount of data written exceeds a second threshold, it is determined that the preset threshold has been exceeded. Specifically, on the embedded device side, when the user-space program merges write operation events within a fixed statistical time window (e.g., 1 minute), in addition to accumulating the number of writes, it also accumulates the number of bytes written in each write operation. Each merged item, determined by a specific stack and a specific file path, records the sum of the number of bytes written by all write operations within that time window, i.e., the total amount of data written. The program compares this total amount of data written with a preset second threshold (e.g., 20KB per minute). If the total amount of data written exceeds the second threshold, it is determined that the frequency of the monitored file write operations exceeds the preset threshold.

[0081] Through the above embodiments, by setting a dual threshold judgment mechanism for the number of write operations and the total amount of data written, embedded devices can intelligently distinguish between normal business writes and abnormal write modes caused by software defects, thereby improving the accuracy and coverage of monitoring. This ensures that only abnormal modes that may truly threaten the lifespan of the FLASH will be triggered and reported, thereby reducing invalid data uploads, saving network and cloud resources, focusing on issues that require urgent handling, and improving the efficiency and practicality of the remote operation and maintenance system.

[0082] In some embodiments, the above-mentioned acquisition of the call stack information corresponding to the file write operation may further include the following steps:

[0083] The eBPF program is executed in the kernel of the embedded device to obtain the first device identifier for the file write operation; if the device identifier is detected to match the second device identifier of the preset storage area using the eBPF program, the corresponding call stack information is recorded.

[0084] Specifically, the eBPF program executing in the kernel of the embedded device uses the kernel helper function bpf_get_file_dev to obtain the actual device number corresponding to the file descriptor of the target file of the current write operation, which is the first device identifier. At the same time, the eBPF program reads the device number corresponding to the FLASH mount path to be monitored, set by the user-space program, from an eBPF mapping of type BPF_MAP_TYPE_HASH, which is the second device identifier of the preset storage area. The eBPF program compares these two device identifiers. Only when they match completely does it determine that the write operation is for the target FLASH storage area, and then execute subsequent operations such as recording stack information; otherwise, it exits directly.

[0085] Optionally, the aforementioned eBPF program is attached to the standard library write function entry point of the embedded device via a user-space probe. In other words, in the user space of the embedded device, the monitoring program uses the specific interface function bpf_program__attach_uprobe provided by the libbpf library to dynamically attach the compiled eBPF program to the entry address of the write function in the glibc dynamic library linked by the target user-space process, using a user-space probe. This write function is a system call wrapper function in the standard library used to perform file writing operations. By attaching it here via uprobe, any user-space process that calls the write function will trigger the execution of the aforementioned kernel eBPF program, thereby achieving kernel-level monitoring and information capture of write operations.

[0086] Through the above embodiments, by accurately comparing the first device identifier of the operation target with the second device identifier of the preset FLASH area in the eBPF program, the monitoring scope can be strictly limited to the specified key storage devices, effectively filtering out normal write operations to other non-volatile storage media (such as temporary file systems) in the system, and significantly reducing the generation of false alarms and invalid data. At the same time, by attaching the eBPF program to the write function entry point of the standard library as a user-space probe, interception and monitoring can be achieved at the level of user-space function calls, which is closest to the application logic. This ensures that the captured call stack information completely and accurately reflects the real code path of the application initiating the write operation, providing a reliable and high-quality data foundation for subsequent precise code-level root cause analysis in the cloud.

[0087] The present application will now be described and illustrated with reference to specific embodiments. Figure 3 This is a schematic diagram of an embedded device according to an embodiment of this application, such as... Figure 3 As shown, the execution flow on the embedded device side is as follows:

[0088] The user-space eBPF process first uses the libbpf library to load its written eBPF program into the Linux kernel of the embedded device via the bpf() system call. Next, the user-space process obtains the mount path (e.g., " / mnt") of the FLASH storage area to be monitored and retrieves the corresponding file system device number (including the major and minor device numbers) based on this path. This device number, as a key parameter, is passed to the eBPF program loaded into the kernel through an eBPF mapping of type BPF_MAP_TYPE_HASH. Subsequently, the user-space program attaches the eBPF program to the glibc library's write function entry point via an uprobe (user-space probe), specifically by calling the libbpf library's bpf_program__attach_uprobe function.

[0089] When any user-mode process on the embedded device calls the `write` function, the configured uprobe is triggered, causing the kernel to begin executing the aforementioned eBPF program. This kernel-mode eBPF program performs the following operations in sequence: (a) obtains the device number of the target file for the current write operation, which is achieved by calling the helper function `bpf_get_file_dev(fd)`; (b) compares this device number with the preset FLASH memory region device number read from the eBPF mapping; if they differ, the eBPF program exits directly; (c) if the device numbers match, records relevant information about this write operation, including the number of bytes written (from the `count` parameter of the `write` function), and the name of the current process (via `bpf_get_current_file_dev(fd)`). (d) Obtain the following information: (omm) process ID (lower 32 bits of bpf_get_current_pid_tgid), file descriptor fd (fd parameter of the write function), and user-space stack information (stack_id obtained through the bpf_get_stackid function, and the complete stack information is saved to a dedicated mapping of type BPF_MAP_TYPE_STACK_TRACE); (d) Finally, the key information such as the number of bytes written, process name, file descriptor fd, and stack_id is sent back to user space in the form of perf events.

[0090] After receiving a perf event from the kernel, the user-mode program initiates the following process: (a) Parses the event content, reads the specific stack address information from the corresponding stack map based on the stack_id in the event, and reads the / proc / file descriptor provided by the operating system based on the process ID and file descriptor fd in the event. <pid> / fd / <fd>(a) Resolve symbolic links to obtain the complete file path; (b) Within a fixed time window (e.g., 1 minute), statistically analyze the stack information of all received write operation events, merge them using the stack address information and file path as a combined index, and record the merged process name, total number of writes, and total number of bytes written; (c) Determine whether the merged number of writes or the number of bytes written exceeds a preset threshold. If it does, generate a complete record containing the device model, firmware version number, device serial number (SN), and a table of all stack information within the current time window. Each entry in the table contains stack address information, process name, and file information (file path, number of writes, and number of bytes written); (d) Finally, upload the generated record to the cloud platform.

[0091] Figure 4 This is a flowchart of another remote operation and maintenance method for an embedded device according to an embodiment of this application, such as... Figure 4 As shown, the process also includes the following steps:

[0092] On the embedded device side, FLASH write operations are detected, and events, including device model, version number, process name, stack information, etc., are uploaded to the cloud platform (i.e., the aforementioned cloud server).

[0093] After receiving the record, the cloud platform executes the following processing steps: (a) Based on the device identifier (model, version number) and process name, it requests the corresponding symbol table and debug symbol table (archived during firmware build) from the software integration environment. (b) For each address in the stack address list, it performs symbol resolution using the symbol table and debug symbol table to obtain the function name, source code file name, and line number, converting them into an easily readable function call sequence. (c) The stack information is sorted by frequency, and the relevant technical maintenance personnel are notified of the high-frequency stack-related information.

[0094] Through the above embodiments, eBPF technology is used to monitor the frequency and number of bytes of file write operations under the FLASH path on embedded devices. The source process of file write operations is traced, and the file name, number of writes, number of bytes written, source process name, and stack information of all file write operations within a fixed window time are statistically analyzed. When the frequency of FLASH file write operations exceeds a set threshold, the source process information and file information of all file write operations within a fixed time are uploaded to the cloud platform, and the technical maintenance personnel of the relevant processes are notified to locate and troubleshoot the problem. This proposes a device-cloud collaborative analysis framework for effectively maintaining the lifespan of embedded device FLASH, which can effectively detect accidental defects in the device software program, improve device quality and lifespan, and significantly reduce the time cost required for FLASH maintenance while controlling network transmission and resource consumption.

[0095] Furthermore, the device only uploads stack address information, and the cloud platform uses the symbol table and debugging symbol table saved during version building to perform symbol resolution on the addresses in the stack information to obtain an easily readable function call sequence. This device-cloud collaborative stack method effectively reduces network transmission and resource consumption, and improves operation and maintenance efficiency.

[0096] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0097] This embodiment also provides a remote operation and maintenance system for embedded devices, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as described above. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0098] The remote operation and maintenance system for the aforementioned embedded devices includes a device-side monitoring module and a cloud server; wherein:

[0099] The device-side monitoring module is deployed in the embedded device to monitor file write operations to the storage area of ​​the embedded device, obtain the corresponding call stack information, and upload the call stack information when the frequency of file write operations exceeds a preset threshold.

[0100] The cloud server is used to perform symbolic resolution on the received call stack information to generate a function call sequence, and output location and diagnostic information for abnormal write operations on embedded devices based on the function call sequence.

[0101] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0102] This embodiment also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0103] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0104] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0105] S1 monitors write file operations to the storage area of ​​the embedded device and obtains the call stack information corresponding to the write file operation.

[0106] S2, if the frequency of file writing operations exceeds a preset threshold, the call stack information is uploaded to the cloud server; the cloud server performs symbolic parsing on the call stack information, generates a function call sequence, and outputs location and diagnostic information for abnormal write operations on the embedded device based on the function call sequence.

[0107] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0108] Furthermore, in conjunction with the remote operation and maintenance method for embedded devices in the above embodiments, this application embodiment can provide a storage medium for implementation. The storage medium stores a computer program; when the computer program is executed by a processor, it implements any of the remote operation and maintenance methods for embedded devices in the above embodiments.

[0109] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

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

Claims

1. A method for remote operation and maintenance of an embedded device, characterized in that, The method includes: Monitor file write operations to the storage area of ​​the embedded device and obtain the call stack information corresponding to the file write operation; If the frequency of file writing operations exceeds a preset threshold, the call stack information will be uploaded to the cloud server. The cloud server performs symbolic parsing on the call stack information to generate a function call sequence, and outputs location and diagnostic information for abnormal write operations on the embedded device based on the function call sequence.

2. The method according to claim 1, characterized in that, Uploading the call stack information to the cloud server includes: Obtain the process identifier and file information corresponding to the file write operation; The process identifier, file information, and call stack information are associated and uploaded to the cloud server; the cloud server determines the corresponding target symbol table based on the process identifier and uses the target symbol table to perform symbol resolution on the call stack information.

3. The method according to claim 2, characterized in that, The cloud server determines the corresponding target symbol table based on the process identifier, including: The cloud server searches for and retrieves a target symbol table containing the process identifier from the archive library of the software integration environment, based on the process identifier and the device identifier information received from the embedded device.

4. The method according to claim 2, characterized in that, The step of associating the process identifier, file information, and call stack information with the cloud server and uploading them includes: On the embedded device side, multiple file write operation events acquired within a fixed time window are statistically analyzed; Write file operation events with the same call stack information and the same target file path are merged into a single statistical entry, and the total information, including the statistical entry and the associated process identifier, file information and call stack information, is uploaded to the cloud server.

5. The method according to claim 2, characterized in that, The method further includes: The cloud server obtains the corresponding symbol table based on the process identifier or device identifier associated with the call stack information; The cloud server uses the symbol table to resolve the addresses in the call stack information into corresponding function names, source code file names, and line numbers, and organizes them into the function call sequence according to a preset function call order.

6. The method according to claim 1, characterized in that, Detecting the frequency of the file write operation includes: The number of write operations to the FLASH storage area within a preset time window is counted; when the number of write operations exceeds a first threshold, it is determined that the preset threshold has been exceeded; or, The total amount of data written within the preset time window is counted; when the total amount of data written exceeds the second threshold, it is determined that the preset threshold has been exceeded.

7. The remote operation and maintenance method according to any one of claims 1 to 6, characterized in that, The step of obtaining the call stack information corresponding to the file write operation includes: The eBPF program is executed in the kernel of the embedded device to obtain the first device identifier of the file write operation. When the device identifier is detected to match the second device identifier in a preset storage area using the eBPF program, the corresponding call stack information is recorded.

8. The method according to claim 7, characterized in that, The eBPF program is attached to the standard library write function entry point of the embedded device via a user space probe.

9. A remote operation and maintenance system for embedded devices, characterized in that, Includes device-side monitoring modules and cloud servers; The device-side monitoring module is deployed in the embedded device and is used to monitor file write operations to the storage area in the embedded device, obtain the corresponding call stack information, and upload the call stack information when the frequency of file write operations exceeds a preset threshold. The cloud server is used to perform symbolic resolution on the received call stack information to generate a function call sequence, and output location and diagnostic information for abnormal write operations on the embedded device based on the function call sequence.

10. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the remote operation and maintenance method of the embedded device according to any one of claims 1 to 8 when it runs.

Images