Real-time operation and maintenance method and device for embedded device, electronic device and storage medium

Abstract

The application discloses a real-time operation and maintenance method and device of an embedded device, electronic equipment and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: receiving a problem message reported by an abnormal device to the Internet of Things platform; extracting system elements of the abnormal device according to the problem message, and determining software symbols of the abnormal device; receiving target script information for the abnormal device; generating a kernel module file based on the system elements, the software symbols and the target script information; deploying the kernel module file to the abnormal device through the Internet of Things platform to obtain a problem analysis result of the abnormal device. According to the technical scheme, the problem of the abnormal device can be received in real time, and online deployment can be performed after the corresponding kernel module file is generated, so that the problem of the abnormal device can be automatically solved without manual on-site service, and the timeliness and accuracy of operation and maintenance of the embedded device are improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a real-time operation and maintenance method, device, electronic device and storage medium for embedded devices. Background Technology

[0002] With the continuous development of communication technology, embedded devices used in daily life are also constantly improving, such as intelligent robotic vacuum cleaners, dashcams, and recording and broadcasting educational equipment. As the application scope of embedded devices continues to expand, people are placing higher demands on their operation and maintenance.

[0003] Currently, the main approach to maintaining embedded devices is for users to discover problems during use, contact after-sales service for repairs, and then have technicians dispatched for on-site repairs. However, this approach suffers from high labor costs and delayed device repairs. Furthermore, device malfunctions prevent users from continuing to use the device, negatively impacting their user experience. Summary of the Invention

[0004] The purpose of this application is to provide a real-time operation and maintenance method, device, electronic device, and storage medium for embedded devices, which can solve the problems of high operation and maintenance costs and untimely maintenance of embedded devices. By receiving abnormal device problems in real time and generating target script information for the problems, and generating kernel module files by combining device information and target script information, the effect of timely maintenance of abnormal devices can be achieved, improving the timeliness and accuracy of embedded device operation and maintenance.

[0005] In a first aspect, embodiments of this application provide a real-time operation and maintenance method for an embedded device, the method comprising:

[0006] Receive problem messages reported by faulty devices to the IoT platform;

[0007] Extract the system elements of the abnormal device based on the problem message, and determine the software symbol of the abnormal device;

[0008] Receive target script information for the abnormal device;

[0009] Based on the system elements, the software symbols, and the target script information, a kernel module file is generated;

[0010] The kernel module file is deployed to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device.

[0011] Secondly, embodiments of this application provide a real-time operation and maintenance device for embedded devices, the device comprising:

[0012] The problem message receiving module is used to receive problem messages reported by abnormal devices to the IoT platform;

[0013] The software symbol determination module is used to extract the system elements of the abnormal device based on the problem message and determine the software symbol of the abnormal device.

[0014] The script information receiving module is used to receive target script information for the abnormal device;

[0015] A kernel file generation module is used to generate a kernel module file based on the system elements, the software symbols, and the target script information;

[0016] The kernel file deployment module is used to deploy the kernel module file to the abnormal device through the IoT platform in order to obtain the problem analysis results of the abnormal device.

[0017] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0018] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0019] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0020] In this embodiment, a problem message reported by an abnormal device to the IoT platform is received; system elements of the abnormal device are extracted based on the problem message, and software symbols of the abnormal device are determined; target script information for the abnormal device is received; a kernel module file is generated based on the system elements, the software symbols, and the target script information; and the kernel module file is deployed to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device. This real-time operation and maintenance method for embedded devices can solve the current problems of high operation and maintenance costs and untimely maintenance of embedded devices. By receiving abnormal device problems in real time, generating target script information for the problems, and combining device information and target script information to generate a kernel module file, timely maintenance of abnormal devices can be achieved, improving the timeliness and accuracy of embedded device operation and maintenance. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the real-time operation and maintenance method for embedded devices provided in Embodiment 1 of this application;

[0022] Figure 2 This is a flowchart illustrating the real-time operation and maintenance method for embedded devices provided in Embodiment 2 of this application;

[0023] Figure 3 This is a schematic diagram of the structure of the real-time operation and maintenance device for embedded devices provided in Embodiment 3 of this application;

[0024] Figure 4 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0026] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0027] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0028] The real-time operation and maintenance method, apparatus, electronic device and storage medium of embedded devices provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0029] Example 1

[0030] Figure 1 This is a flowchart illustrating the real-time operation and maintenance method for embedded devices provided in Embodiment 1 of this application. The method is executed by a server, which connects to the running device via an IoT platform. Figure 1 As shown, the specific steps include the following:

[0031] S101, Receive the problem message reported by the faulty device to the IoT platform;

[0032] First, this technical solution can be used in scenarios where embedded devices need to be maintained. Specifically, it can be used in scenarios where users report faults in embedded devices in real time and where device faults are maintained promptly.

[0033] Based on the above usage scenarios, it can be understood that the executing entity of this application is a server for operating and maintaining embedded devices. The embedded devices can be application devices such as smart home appliances, recording and broadcasting equipment, and vehicle navigation equipment, without further limitations.

[0034] In this solution, the server can be a service program with authentication and data transmission functions, capable of providing resources to the client and storing client data. Specifically, it can be a service program used to receive device repair requests sent by users and deploy repair scripts to faulty devices. The client can be a program corresponding to the server, providing local services to the client. Specifically, it can be an end running the embedded device used by the user, or it can be an end providing device repair services.

[0035] In this solution, the Internet of Things (IoT) platform can collect and monitor object status information. Through diverse network connectivity methods, it can directly connect this status information to the internet, enabling rapid intelligent sensing of objects and facilitating object identification and management. Specifically, the IoT platform can obtain equipment maintenance reports and fault status. Maintenance departments can log into the platform or connect to it via a server to view equipment problems. The operating equipment can be an embedded device on the client side, and the server connects to the operating equipment through the IoT platform.

[0036] In this solution, the server can receive problem messages reported by faulty devices to the IoT platform via the MQTT protocol. MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol based on a publish / subscribe model, built on top of the TCP / IP protocol. MQTT's greatest advantage is that it can provide real-time and reliable messaging services to connected remote devices with minimal code and limited bandwidth. As a low-overhead, low-bandwidth instant messaging protocol, it has wide applications in IoT, small devices, and mobile applications. MQTT is a client-server based message publish / subscribe transport protocol. The MQTT protocol is lightweight, simple, open, and easy to implement, making it widely applicable. It is used in many situations, including constrained environments such as machine-to-machine (M2M) communication and the Internet of Things (IoT). It is widely used in sensors communicating via satellite links, medical devices making occasional dial-ups, smart homes, and some miniaturized devices. MQTT is a protocol that facilitates interaction between the client and server. The client can be a program or device using MQTT. The client can publish application messages to other devices that have subscribed to the application messages, and other devices can also unsubscribe to stop receiving application messages.

[0037] The server can be a program or device that receives problem messages published by clients through a subscription mechanism. Specifically, in this solution, the client can be a maintenance terminal used by R&D personnel, the abnormal device can be an abnormal device that reports a problem message, and the R&D personnel's maintenance terminal can be a device factory that repairs abnormal device problems.

[0038] MQTT's pattern is publish and subscribe, which is the main function this protocol aims to achieve. Publishes can be made by either the client or the server, but ultimately, forwarding must occur on the server. Subscriptions are initiated by the client, and their definitions are as follows: A subscription contains a topic filter and a maximum Quality of Service (QoS) level. A subscription is associated with a single session. A session can contain more than one subscription. Each subscription in a session has a different topic filter. The topic name is a tag appended to the application message, known to the server and matching the subscription. The server sends a copy of the application message to each matching client subscription. The topic filter is an expression contained in the subscription, representing one or more related topics; wildcards can be used in topic filters. A session is for state interaction between the client and the server. Some sessions last as long as the network connection, while others can extend across multiple consecutive network connections between the client and the server.

[0039] Control messages are essentially data packets. Clients and servers communicate using information from these messages to perform various operations. The MQTT protocol resides at the application layer of the five-layer model, its underlying foundation being TCP / IP. It uses socket programming to implement message editing and sending. MQTT messages are broadly divided into three parts: a fixed header, a variable header, and a payload. The fixed header exists in all MQTT packets and indicates the packet type and grouping identifier. The variable header exists in some MQTT packets; its presence and content are determined by the packet type. The payload exists in some MQTT packets and indicates the specific content the subscriber intends to use.

[0040] In this scheme, a message is a data unit exchanged and transmitted in the network, that is, a data block that a station sends at one time. A message contains complete data information to be sent, and its length varies greatly, being unlimited and variable. A message is also a unit of network transmission; during transmission, it is continuously encapsulated into packets, frames, and groups for transmission. Encapsulation involves adding information segments, which are the data organized in a specific format in the message header. When a station wants to send a message, it appends a destination address to the message. Network nodes, based on the destination address information in the message, forward the message to the next node, and so on, node by node, until it reaches the destination node. Each node, after receiving the entire message and verifying its correctness, temporarily stores the message, then uses routing information to find the address of the next node, and then forwards the entire message to the next node. The problem message can be a message containing device problem information and a device identification ID. The device identification ID can be a serial number used to identify the device type, including the device's address and model number. Each device corresponds to a unique identification ID, and different devices have different identification IDs.

[0041] In this solution, the abnormal device reports a problem message to the IoT platform in the following ways: when a user encounters a problem while using the device, they can click on the after-sales options such as reporting a problem or contacting customer service in the device, select the problem type, problem keywords, and the model or ID number of the problematic device, etc. The internal program of the device generates a problem list based on the above selection, which forms a problem message. After the user clicks the "submit" option, the message is reported to the IoT platform via the MQTT protocol.

[0042] S102, extract the system elements of the abnormal device based on the problem message, and determine the software symbol of the abnormal device;

[0043] In this scheme, elements are the various components of the system. These elements may be individuals, components, parts, or even a system or subsystem in themselves. A system is a collection of its constituent elements, which are interconnected and mutually restrictive. System elements can include information about the internal operating parts of malfunctioning equipment and the equipment itself. Specifically, these can be software elements such as software version, software running status, system information, and system running status, or hardware elements such as equipment status, equipment attributes, and equipment number.

[0044] In this scheme, software symbols can be symbols used to represent the name, type, and function of problematic software in an abnormal device. Specifically, they can be extracted from the symbol table of the abnormal device. The symbol table is a data structure used in language translators (such as compilers and interpreters). In the symbol table, each identifier in the program source code is bound to its declaration or usage information, such as its data type, scope, and memory address. During the compilation process, the symbol table needs to continuously collect, record, and use information related to the types and characteristics of some syntax symbols in the source program. This information is generally stored in the system in tabular form, such as constant tables, variable name tables, array name tables, procedure name tables, label tables, etc., collectively referred to as the symbol table. The quality of the organization, construction, and management of the symbol table directly affects the running efficiency of the compilation system. The symbol table is an important data structure created and maintained by the compiler to store the occurrence of various entities such as variable names, function names, objects, classes, and interfaces. The symbol table can be used in both the analysis and synthesis parts of the compiler. Symbol tables can be used for three operations: searching, hashing, and deleting. Specifically, they can be used to search for a specific name and check if it exists in the table; retrieve the attributes of a name; modify the attributes of a name; insert a new name and its attributes; and delete a name and its attributes.

[0045] In this solution, the IoT platform compiles the corresponding symbol table based on the received problem message and places the symbol table on the server. The system elements of the abnormal device are extracted through encoding. At the same time, the corresponding software symbols are extracted based on the problem message and the system elements.

[0046] S103, Receive target script information for the abnormal device;

[0047] In this scheme, a script is a specific descriptive language, an executable file written according to a certain format. Scripting languages ​​are also known as extended languages ​​or dynamic languages; they are programming languages ​​used to control software applications. Scripts are usually saved as text (ASCII) and are only interpreted or compiled when called. When a script is executed, the computer performs a series of operations. During execution, a script program is translated line by line into machine-readable instructions by an interpreter and executed sequentially. Scripting languages ​​have high-level data structures, such as lists and dictionaries, allowing for simple and convenient nesting and manipulation of these structures. Furthermore, scripting languages ​​do not have type declarations, allowing for dynamic type checking at runtime. A key characteristic of scripting languages ​​is interpretation; that is, instructions are executed immediately without a compilation intermediate state, meaning scripting languages ​​are interactive. Therefore, scripting languages ​​can be used for dynamic analysis of device problems.

[0048] In this solution, the target script information can be device-specific information generated by the host terminal in conjunction with the device model and device attributes. The host terminal can be a server-side application used by R&D personnel, specifically for tasks such as writing scripts and maintenance code. The host terminal can have multiple ports that subscribe to different types of device problems on the IoT platform via the MQTT protocol, generating target script information for different device attributes corresponding to the same type of device problem. Simultaneously, the code writing end on the host terminal receives the target script information and uses it to generate dynamic scripts for devices of the same type or with the same function. Different maintenance instructions are written for different faults and added to the dynamic scripts, achieving the goal of automatic maintenance of malfunctioning devices.

[0049] In this solution, eBPF can be used to generate dynamic analysis scripts. eBPF (extended Berkeley Packet Filter) can be a program that allows new features to be run without modifying the kernel source code or adding additional kernel modules. eBPF can execute user-provided programs in kernel mode, which is very helpful for debugging. At the same time, the eBPF virtual machine provides a secure environment that rigorously checks user-provided programs; only user programs that pass the check can be loaded, ensuring stable system operation.

[0050] Based on the above embodiments, optionally, receiving target script information for the abnormal device includes:

[0051] In response to the script configuration operation, determine the target script information for the abnormal device;

[0052] or,

[0053] Based on at least one of the problem message, the system element, and the software symbol, generate target script information for the abnormal device.

[0054] In this solution, receiving the target script information for the abnormal device can be achieved by the device R&D personnel responding to a script configuration operation, logging into the IoT platform, and determining the target script information for the abnormal device based on the obtained system elements and software symbols of the abnormal device. Alternatively, the target script information for the abnormal device can be automatically generated by the host server based on one or more of the problem message, the system elements, and the software symbols.

[0055] In this solution, the efficiency of acquiring target script information can be improved by having R&D personnel or servers obtain the target script information. At the same time, automatic maintenance can be performed on the same type of equipment based on the target script information, thereby improving the accuracy of equipment maintenance.

[0056] S104, Generate a kernel module file based on the system elements, the software symbols, and the target script information;

[0057] In this scheme, a kernel module (kernel object) can be a module in the operating system, running within the system to extend basic kernel functionality and allowing for dynamic loading or unloading during system operation. Generally, the kernel contains many pre-loaded modules, while some driver modules do not need to be continuously loaded into the kernel. To reduce kernel load, these modules are written separately and loaded into the kernel when needed. A module is a program with independent functionality; it can be compiled independently but cannot run independently. At runtime, it is linked into the kernel and runs as part of the kernel in kernel space, which is different from processes running in user space. A module typically consists of a set of functions and data structures used to implement a file system, a driver, or other higher-level kernel functionality. Kernel module files can be code files used to perform maintenance functions; specifically, they can be maintenance code files written based on system elements of the faulty device, the software symbols, and the target script information.

[0058] Based on the above embodiments, optionally, a kernel module file is generated based on the system elements, the software symbols, and the target script information, including:

[0059] Based on the system elements, the software symbols, and the target script information, an executable code file is generated;

[0060] Based on the executable code file, the kernel module file is obtained through parsing.

[0061] In this scheme, an executable code file can be a file format used to run a piece of code or start a software program during execution. Executable code refers to code formed by linking target code; simply put, it's code that a machine can directly execute. Executable code is generally part of an executable file. The presentation of executable programs varies depending on the operating system environment. Typically, executable files contain microprocessor instructions encoded in binary; therefore, executable files are sometimes called binary files. The encoding of these binary microprocessor instructions differs across various microprocessors, hence executable files often need to be separated into different microprocessor versions. Whether a computer file is executable is mainly determined by the operating system's conventions. The executable code file can be a program file written in C language on the host side based on the system elements, the software symbols, and the target script information.

[0062] In this solution, based on the executable code file, a compiler can parse it to obtain the kernel module file. Specifically, the compiler's parsing process can be as follows: a preprocessing stage, where the compiler reads the executable code file as a unit, processes macros, variables, function declarations, nested header file inclusions, detects dependencies, performs macro substitutions, and checks for duplicate definitions and declarations; a lexical and syntax analysis stage; a compilation stage, where the code is first compiled into pure assembly statements, then assembled into CPU-dependent binary code, generating various object files; and a linking stage, where the absolute addresses of each code segment in each object file are located, generating an executable file specific to the platform.

[0063] In this solution, an executable code file is generated using system elements, software symbols, and target script information. Based on the executable code file, a kernel module file is obtained through parsing. This allows for dynamic analysis of faults in abnormal devices without interrupting device use, thus improving the efficiency of device problem analysis.

[0064] S105, the kernel module file is deployed to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device.

[0065] In this solution, the problem analysis result of the abnormal device can be the result of whether the kernel module file can resolve the problem of the abnormal device. This result can be fed back to the host through the path of the problem message upload. The host can feed back the kernel module file to the IoT platform. The IoT platform uses the MQTT protocol to publish the kernel module file to the abnormal device. The abnormal device executes the kernel module file code and generates a result indicating whether the abnormal problem is resolved. Specifically, after executing the kernel module file code, the abnormal device problem analysis result can be generated based on whether the abnormal device can be used normally.

[0066] Based on the above embodiments, optionally, after deploying the kernel module file to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device, the method further includes:

[0067] Identify whether the analysis results of the problem are the expected results;

[0068] If so, then the abnormal device shall be maintained based on the expected result;

[0069] If not, then receive the update script information for the abnormal device, and regenerate the kernel module file based on the update script information to deploy it to the abnormal device.

[0070] In this solution, after receiving the problem analysis results of the abnormal device, the host identifies whether the analysis results are the expected results. The expected results could be that the abnormal device can be used normally after executing the kernel module file code. If the problem analysis results indicate that the abnormal device can be used normally, then the abnormal device is maintained based on the expected results. Specifically, the kernel module file can be stored in the abnormal device. When the user continues to use the device and reproduces the device problem, the kernel module file is executed again on the device. If the abnormal device cannot be used normally, the script information for the abnormal device is received again and updated. Specifically, the updated script information can be script information generated by the R&D personnel based on the abnormal device problem message uploaded by the user again, and the kernel module file is regenerated based on the updated script information for deployment to the abnormal device.

[0071] In this solution, by identifying the results of problem analysis, automatic device repair can be performed when the same problem is reproduced on abnormal devices. At the same time, unresolved problems can be regenerated into kernel module files for further repair, which can save equipment maintenance costs, improve maintenance efficiency, and enhance the accuracy of equipment maintenance.

[0072] The technical solution provided in this embodiment receives a problem message reported by an abnormal device to the IoT platform; extracts system elements of the abnormal device based on the problem message and determines the software symbols of the abnormal device; receives target script information for the abnormal device; generates a kernel module file based on the system elements, the software symbols, and the target script information; and deploys the kernel module file to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device. This real-time operation and maintenance method for embedded devices can solve the current problems of high operation and maintenance costs and untimely maintenance of embedded devices. By receiving abnormal device problems in real time, generating target script information for the problems, and combining device information and target script information to generate a kernel module file, timely maintenance of abnormal devices can be achieved, improving the timeliness and accuracy of embedded device operation and maintenance.

[0073] Example 2

[0074] Figure 2 This is a flowchart illustrating a real-time operation and maintenance method for an embedded device provided in Embodiment 2 of this application. Figure 2 As shown, the specific steps include the following:

[0075] S201, Receive the problem message reported by the faulty device to the IoT platform;

[0076] S202, extract the system elements of the abnormal device based on the problem message, and determine the software symbol of the abnormal device;

[0077] S203, Receive target script information for the abnormal device;

[0078] S204, Generate a kernel module file based on the system elements, the software symbols, and the target script information;

[0079] S205, determine the deployment path of the abnormal device based on the problem message;

[0080] In this solution, the deployment path can be the configuration path of the kernel module file; specifically, it can be the path from the host to the faulty device that the kernel module file can resolve. The deployment path can be determined by the host through the IoT platform based on the MQTT protocol subscription content and the subscription client, thus identifying the source of the problem message.

[0081] S206, According to the deployment path, the kernel module file is deployed to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device.

[0082] In this solution, deployment can be the process of running the program in a specific environment after development is complete. This process involves generating a runnable software package from the source code, placing the package in the desired deployment environment, and configuring it to function correctly on the target environment. Specifically, it can involve sending the kernel module file to the faulty device via the IoT platform and running it there. The host deploys the kernel module file to the faulty device via the IoT platform according to the deployment path, and obtains the problem analysis results of the faulty device based on the execution results of the kernel module file.

[0083] Based on the above embodiments, optionally, deploying the kernel module file to the abnormal device via the IoT platform according to the deployment path includes:

[0084] The deployment path determines the publishing information to the IoT platform, and the publishing information includes the kernel module file, which is provided to abnormal devices that subscribe to the publishing information.

[0085] In this solution, the published information can be programs or files that can run on faulty devices for equipment maintenance purposes. Specifically, the published information includes the kernel module file. Since different faulty devices, or even the same faulty device, have different problems, the host needs to determine the published information to the IoT platform based on the deployment path. The IoT platform then uses the MQTT protocol to allow faulty devices subscribing to the published information to obtain the kernel module file.

[0086] In this solution, the information to be published to the IoT platform is determined according to the deployment path, and the kernel module file is obtained by abnormal devices that subscribe to the published information. This allows for accurate device repair for different device problems, improving the efficiency of device repair and saving repair time.

[0087] The technical solution provided in this embodiment allows the host to determine the deployment path of the abnormal device based on the problem message, and then deploy the kernel module file to the abnormal device through the IoT platform according to the deployment path, so as to obtain the problem analysis results of the abnormal device. This allows for problem analysis and device maintenance without stopping device use or requiring on-site personnel, thereby improving the efficiency and accuracy of device repair.

[0088] Example 3

[0089] Figure 3 This is a schematic diagram of the structure of the real-time operation and maintenance device for embedded devices provided in Embodiment 3 of this application.

[0090] like Figure 3 As shown, it specifically includes the following:

[0091] Problem message receiving module 301 is used to receive problem messages reported by abnormal devices to the Internet of Things platform;

[0092] The software symbol determination module 302 is used to extract the system elements of the abnormal device based on the problem message and determine the software symbol of the abnormal device.

[0093] Script information receiving module 303 is used to receive target script information for the abnormal device;

[0094] The kernel file generation module 304 is used to generate a kernel module file based on the system elements, the software symbols, and the target script information;

[0095] The kernel file deployment module 305 is used to deploy the kernel module file to the abnormal device through the IoT platform in order to obtain the problem analysis results of the abnormal device.

[0096] Furthermore, the kernel file generation module is specifically used for:

[0097] Based on the system elements, the software symbols, and the target script information, an executable code file is generated;

[0098] Based on the executable code file, the kernel module file is obtained through parsing.

[0099] Furthermore, the device also includes:

[0100] The analysis result identification module is used to identify whether the analysis result of the problem is the expected result;

[0101] An abnormal equipment maintenance module is used to maintain the abnormal equipment based on the expected result if the identified problem analysis result is the expected result.

[0102] The kernel file update module is used to receive update script information for the abnormal device if the identified problem analysis result is not the expected result, and to regenerate the kernel module file based on the update script information for deployment to the abnormal device.

[0103] Furthermore, the script information receiving module is specifically used for:

[0104] In response to the script configuration operation, determine the target script information for the abnormal device;

[0105] or,

[0106] Based on at least one of the problem message, the system element, and the software symbol, generate target script information for the abnormal device.

[0107] Furthermore, the kernel file deployment module includes:

[0108] A deployment path determination unit is used to determine the deployment path of the abnormal device based on the problem message.

[0109] The kernel file deployment unit is used to deploy the kernel module file to the abnormal device through the IoT platform according to the deployment path.

[0110] Furthermore, the kernel file deployment unit is specifically used for:

[0111] The deployment path determines the publishing information to the IoT platform, and the publishing information includes the kernel module file, which is provided to abnormal devices that subscribe to the publishing information.

[0112] The technical solution provided in this embodiment includes a problem message receiving module for receiving problem messages reported by abnormal devices to the IoT platform; a software symbol determination module for extracting system elements of the abnormal device based on the problem message and determining the software symbols of the abnormal device; a script information receiving module for receiving target script information for the abnormal device; a kernel file generation module for generating a kernel module file based on the system elements, the software symbols, and the target script information; and a kernel file deployment module for deploying the kernel module file to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device. This real-time operation and maintenance device for embedded devices can solve the current problems of high operation and maintenance costs and untimely maintenance of embedded devices. By receiving abnormal device problems in real time, generating target script information for the problems, and combining device information and target script information to generate kernel module files, timely maintenance of abnormal devices can be achieved, improving the timeliness and accuracy of embedded device operation and maintenance.

[0113] The real-time operation and maintenance device for embedded devices in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0114] The real-time operation and maintenance device for embedded devices in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0115] The real-time operation and maintenance device for embedded devices provided in this application embodiment can achieve… Figures 1 to 2 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0116] Example 4

[0117] like Figure 4 As shown, this application embodiment also provides an electronic device 400, including a processor 401, a memory 402, and a program or instructions stored in the memory 402 and executable on the processor 401. When the program or instructions are executed by the processor 401, they implement the various processes of the above-described real-time operation and maintenance method embodiment of the embedded device and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0118] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0119] Example 5

[0120] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described real-time operation and maintenance method embodiment for embedded devices and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0121] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0122] Example 6

[0123] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described real-time operation and maintenance method embodiment for embedded devices, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0124] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0125] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0126] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0127] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0128] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A real-time operation and maintenance method for embedded devices, characterized in that, The method is executed by a server, which connects to the operating device via an IoT platform; the method includes: Receive problem messages reported by faulty devices to the IoT platform; The corresponding symbol table is compiled according to the problem message, the system elements of the abnormal device are extracted from the symbol table by encoding, and the software symbol of the abnormal device is determined from the symbol table according to the problem message and the system elements. Receive target script information for the abnormal device, the target script information including a dynamic analysis script generated using eBPF; Based on the system elements, the software symbols, and the target script information, a kernel module file is generated; The kernel module file is deployed to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device. The problem analysis results of the abnormal device include whether the kernel module file resolves the problem of the abnormal device.

2. The method according to claim 1, characterized in that, Based on the system elements, the software symbols, and the target script information, a kernel module file is generated, including: Based on the system elements, the software symbols, and the target script information, an executable code file is generated; Based on the executable code file, the kernel module file is obtained through parsing.

3. The method according to claim 1, characterized in that, After deploying the kernel module file to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device, the method further includes: Identify whether the analysis results of the problem are the expected results; If so, then the abnormal device shall be maintained based on the expected result; If not, then receive the update script information for the abnormal device, and regenerate the kernel module file based on the update script information to deploy it to the abnormal device.

4. The method according to claim 1, characterized in that, Receive target script information for the abnormal device, including: In response to the script configuration operation, determine the target script information for the abnormal device; or, Based on at least one of the problem message, the system element, and the software symbol, generate target script information for the abnormal device.

5. The method according to claim 1, characterized in that, Deploying the kernel module file to the faulty device via the IoT platform includes: Determine the deployment path of the abnormal device based on the problem message; The kernel module file is deployed to the abnormal device via the IoT platform according to the deployment path.

6. The method according to claim 5, characterized in that, Deploying the kernel module file to the faulty device via the IoT platform according to the deployment path includes: The deployment path determines the publishing information to the IoT platform, and the publishing information includes the kernel module file, which is provided to abnormal devices that subscribe to the publishing information.

7. A real-time operation and maintenance device for embedded devices, characterized in that, The device is configured on a server, and the server is connected to the operating equipment via an Internet of Things (IoT) platform; the device includes: The problem message receiving module is used to receive problem messages reported by abnormal devices to the IoT platform; The software symbol determination module is used to compile a corresponding symbol table based on the problem message, extract the system elements of the abnormal device from the symbol table through encoding, and determine the software symbol of the abnormal device from the symbol table based on the problem message and the system elements. The script information receiving module is used to receive target script information for the abnormal device, the target script information including a dynamic analysis script generated using eBPF; A kernel file generation module is used to generate a kernel module file based on the system elements, the software symbols, and the target script information; The kernel file deployment module is used to deploy the kernel module file to the abnormal device through the IoT platform to obtain the problem analysis results of the abnormal device. The problem analysis results of the abnormal device include whether the kernel module file resolves the problem of the abnormal device.

8. The apparatus according to claim 7, characterized in that, The kernel file generation module is specifically used for: Based on the system elements, the software symbols, and the target script information, an executable code file is generated; Based on the executable code file, the kernel module file is obtained through parsing.

9. The apparatus according to claim 7, characterized in that, The device further includes: The analysis result identification module is used to identify whether the analysis result of the problem is the expected result; An abnormal equipment maintenance module is used to maintain the abnormal equipment based on the expected result if the identified problem analysis result is the expected result. The kernel file update module is used to receive update script information for the abnormal device if the identified problem analysis result is not the expected result, and to regenerate the kernel module file based on the update script information for deployment to the abnormal device.

10. The apparatus according to claim 7, characterized in that, The script information receiving module is specifically used for: In response to the script configuration operation, determine the target script information for the abnormal device; or, Based on at least one of the problem message, the system element, and the software symbol, generate target script information for the abnormal device.

11. The apparatus according to claim 7, characterized in that, The kernel file deployment module includes: A deployment path determination unit is used to determine the deployment path of the abnormal device based on the problem message. The kernel file deployment unit is used to deploy the kernel module file to the abnormal device through the IoT platform according to the deployment path.

12. The apparatus according to claim 11, characterized in that, The kernel file deployment unit is specifically used for: The deployment path determines the publishing information to the IoT platform, and the publishing information includes the kernel module file, which is provided to abnormal devices that subscribe to the publishing information.

13. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein when the program or instructions are executed by the processor, they implement the steps of the real-time operation and maintenance method for the embedded device as described in any one of claims 1-6.

14. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions, which, when executed by a processor, implement the steps of the real-time operation and maintenance method for the embedded device as described in any one of claims 1-6.

Images