Embedded equipment upgrading method and device, equipment, medium and program product
Through the device management platform, script links and version information are distributed, and embedded devices automatically download and execute scripts for upgrading, solving the problems of cumbersome upgrade process and limited storage space in the existing technology, and achieving efficient and flexible functional updates.
Patent Information
- Application Number
- CN202411288137.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-13
- Publication Date
- 2024-12-31
AI Technical Summary
In the prior art, the upgrade process of embedded equipment is cumbersome and requires equipment disassembly. The remote upgrade method has storage space and data traffic limitations, which cannot meet the needs of new function updates or fault resolution.
Through the device management platform, the embedded device obtains the link to the first script and downloads the script, and automatically executes the script to achieve function updates, avoiding the impact of the firmware version, reducing the amount of data and storage space, and improving the use of Upgrade efficiency and flexibility.
Automatic remote function update of embedded devices is realized, reducing the complexity of manual operation and the possibility of errors, reducing upgrade time and cost, and improving upgrade efficiency and device function update flexibility.
Smart Images

Figure CN119225763A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to an embedded device upgrade method, device, equipment, medium and program product. Background Art
[0002] An embedded device is an electronic device embedded in a device to perform specific tasks or control specific functions. It does not provide general computing capabilities and is usually composed of an embedded system, including basic components such as processors, memory, input / output interfaces, communication interfaces, and operating systems. It can run independently or communicate with other devices and is widely used in various fields such as consumer electronics, industrial automation, automotive electronics, medical equipment, and communication equipment.
[0003] Currently, a personal computer (PC) host computer is usually used to directly connect to an embedded device through a hardware interface, so that the firmware of the device is upgraded through the host computer software.
[0004] However, the above firmware upgrade method requires the device to be disassembled, so there is a problem of cumbersome operation. Summary of the invention
[0005] The present application provides an embedded device upgrade method, apparatus, equipment, medium and program product to solve the technical problem of cumbersome operation in the prior art for upgrading embedded devices.
[0006] In a first aspect, the present application provides an embedded device upgrade method, which is applied to an embedded device, and the method comprises:
[0007] Obtaining a link to a first script for upgrading the embedded device, where the link to the first script is determined based on the upgrade information issued by the device management platform or based on the version information of the first script issued by the device management platform, and the first script is a pre-designed script for upgrading the embedded device;
[0008] According to the link of the first script, obtain the first script from the device management platform;
[0009] According to the first script, the embedded device is upgraded.
[0010] Optionally, obtaining a link to a first script for upgrading the embedded device includes:
[0011] Obtain upgrade information or version information issued by the device management platform;
[0012] A link to the first script is parsed from the upgrade information or the version information.
[0013] Optionally, obtaining the first script from the device management platform according to the link of the first script includes:
[0014] Parsing the version of the first script from the version information;
[0015] When the version of the first script is inconsistent with the version of the second script, the first script is obtained from the device management platform according to the link of the first script, and the version of the second script is the version of the script used to upgrade the embedded device last time.
[0016] Optionally, the method further comprises:
[0017] When the version of the first script is consistent with the version of the second script, the version of the second script is sent to the device management platform.
[0018] Optionally, upgrading the embedded device according to the first script includes:
[0019] Read the source code of the first script;
[0020] Perform lexical analysis and syntax analysis on the source code to generate embedded bytecode;
[0021] Execute embedded bytecode to upgrade the embedded device.
[0022] Optionally, before obtaining the link of the first script for upgrading the embedded device, the method further includes:
[0023] Send heartbeat information to the device management platform. The heartbeat information is used to indicate that the embedded device is online.
[0024] Receive the response information corresponding to the heartbeat information sent by the device management platform.
[0025] In a second aspect, the present application provides an embedded device upgrade device, comprising:
[0026] A first acquisition module, used to acquire a link of a first script for upgrading an embedded device, wherein the link of the first script is determined based on the upgrade information issued by the device management platform or based on the version information of the first script issued by the device management platform, and the first script is a pre-designed script for upgrading an embedded device;
[0027] A second acquisition module, configured to acquire the first script from the device management platform according to a link to the first script;
[0028] The upgrade module is used to upgrade the embedded device according to the first script.
[0029] Optionally, the first acquisition module is specifically used to:
[0030] Obtain upgrade information or version information issued by the device management platform;
[0031] A link to the first script is parsed from the upgrade information or the version information.
[0032] Optionally, the first acquisition module is specifically used to:
[0033] Parsing the version of the first script from the version information;
[0034] When the version of the first script is inconsistent with the version of the second script, the first script is obtained from the device management platform according to the link of the first script, and the version of the second script is the version of the script used to upgrade the embedded device last time.
[0035] Optionally, it also includes:
[0036] The sending module is used to send the version of the second script to the device management platform when the version of the first script is consistent with the version of the second script.
[0037] Optionally, an upgrade module is specifically used to:
[0038] Read the source code of the first script;
[0039] Perform lexical analysis and syntax analysis on the source code to generate embedded bytecode;
[0040] Execute embedded bytecode to upgrade the embedded device.
[0041] Optionally, the sending module is further used for:
[0042] Send heartbeat information to the device management platform. The heartbeat information is used to indicate that the embedded device is online.
[0043] The first acquisition module is further used for:
[0044] Receive the response information corresponding to the heartbeat information sent by the device management platform.
[0045] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;
[0046] Memory stores computer-executable instructions;
[0047] The processor executes the computer-executable instructions stored in the memory to implement the embedded device upgrade method as described in the first aspect and various possible implementations of the first aspect.
[0048] In a fourth aspect, the present application provides a computer-readable storage medium, which stores computer execution instructions. When the computer execution instructions are executed by a processor, they are used to implement the embedded device upgrade method as described in the first aspect and various possible implementation methods of the first aspect.
[0049] In a fifth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, is used to implement the embedded device upgrade method as described in the first aspect and various possible implementations of the first aspect.
[0050] The embedded device upgrade method, apparatus, device, medium and program product provided by the present application are a means of upgrading the embedded device by synchronously obtaining the link of the first script according to the upgrade information or the version information of the first script issued by the device management platform, then obtaining the first script from the device management platform according to the link of the first script, and finally running the first script and completing the function set by the first script. The method enables the embedded device to add new functions or improve existing functions based on the version information or upgrade information of the first script issued by the device management platform, thereby controlling the current software logic of the embedded device, so that the embedded device can perform more tasks or improve its performance, and realize the process of remotely completing the upgrade of the embedded device. On the one hand, since the upgrade process is automatically executed by the first script, the complexity of manual operation and the possibility of error are reduced. On the other hand, the first script can be customized according to specific needs to perform specific upgrade tasks or configuration adjustments, thereby realizing incremental upgrades of embedded devices, updating only the necessary parts instead of the entire firmware, thereby reducing upgrade time and cost and improving upgrade efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0051] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0052] Figure 1 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 1 ;
[0053] Figure 2 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 2 ;
[0054] Figure 3 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 3 ;
[0055] Figure 4 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 4 ;
[0056] Figure 5 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 5 ;
[0057] Figure 6 The architecture of the embedded device upgrade system provided in the embodiment of the present application is shown as follows Figure 1 ;
[0058] Figure 7 The architecture of the embedded device upgrade system provided in the embodiment of the present application is shown as follows Figure 2 ;
[0059] Figure 8 A schematic diagram of the structure of an embedded device upgrade device provided in an embodiment of the present application;
[0060] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.
[0061] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION
[0062] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.
[0063] In the prior art, when upgrading embedded devices, the functions implemented by them are usually managed by firmware upgrade, that is, the firmware version is burned into the non-volatile storage area of the device through local upgrade or remote upgrade, and then the new firmware is run to implement the function update of the device. Among them, remote upgrade also includes the following methods: 1. Differential upgrade: The difference between two software versions is calculated by differential algorithm and stored in a file in binary form, that is, differential package. After the embedded device obtains the differential package through communication, the incremental update is restored by algorithm to achieve the purpose of remote upgrade; 2. Whole package upgrade: The embedded device obtains the complete firmware package through communication, and then applies the entire software package to the device; 3. Configuration-based upgrade solution: All required logic is pre-stored in the embedded device. After the embedded device obtains the configuration through communication, the required logic is selected from the existing logic according to the configuration to achieve the purpose of remote control software.
[0064] However, the above methods all have certain limitations. For example, when a device has a large number of firmware versions, if a differential upgrade is used, a large number of differential packages need to be produced, and different differential packages need to be selected for different upgrade processes for the current version of each device, resulting in an extremely cumbersome upgrade process. If a full package upgrade is used, the device and the system need to communicate with a large amount of data, and at the same time, double the space needs to be reserved to store the complete firmware. However, the storage space and computing power of embedded devices are limited, and often cannot meet the requirements of storage space and data flow. For configuration-based upgrade solutions, only limited functions can be switched, and new functions cannot be updated or faults cannot be solved.
[0065] In the process of solving the above technical problems, the inventor's technical concept is as follows: based on the consideration of the limited storage space of the embedded device, the upgrade of the embedded device, that is, the new function of the device, is converted into an automatically executed script, that is, the first script, and the script is stored on the device management platform at the same time. The script is managed by the device management platform, and then the link of the first script is obtained and the first script is downloaded through the embedded device, so that the device can be upgraded by executing the script. In this way, the remote function update of the embedded device can be automatically completed through the first script on the device management platform. This process is not affected by the firmware version of the device. The function update of the embedded device is realized only by the change of the first script. The amount of data transmitted is small, the storage space occupied is small, and the upgrade efficiency of the embedded device can be further improved, and the flexibility of the function update of the embedded device can be enhanced.
[0066] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.
[0067] Figure 1 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 1 .like Figure 1 As shown, the execution subject of the method is an embedded device, and the method includes:
[0068] S101, obtaining a link to a first script for upgrading an embedded device;
[0069] The link of the first script is determined based on the upgrade information issued by the device management platform, or based on the version information of the first script issued by the device management platform. The first script is a pre-designed script for upgrading the embedded device.
[0070] The device management platform may refer to a cloud platform deployed in the cloud, which is used to monitor, manage and control various embedded devices and scripts in the embedded devices, and has high scalability. In this embodiment, the device management platform can remotely manage the scripts in the embedded devices, control the embedded devices to run the scripts issued by the device management platform, and thus realize the remote upgrade of the embedded devices.
[0071] The first script is a pre-designed script for upgrading embedded devices and is stored on the device management platform. Specifically, the first script is an embedded type script that can be written in a variety of programming languages, such as Python, JavaScript, Shell script, etc. The first script is based on the development environment of embedded devices, is specially adapted to embedded devices, and is compatible with embedded devices. The language type of the script includes but is not limited to MicroPython type, eLua type, Elk type, etc., which is used to automatically execute preset functions, so that the device can execute new functions or update existing functions by running the first script.
[0072] It should be noted that when the user adds or modifies a script file, the device management platform will check the syntax of the script. If a syntax error is reported, the script cannot be added or modified. After the check is correct, the script will be stored for easy distribution to the embedded device.
[0073] Upgrade information can refer to update information for adding new functions to embedded devices, usually including detailed descriptions such as device version number, change log, new functions, fixed issues, performance improvements, security updates, compatibility information, etc. These descriptions are usually recorded in a document, such as release notes or change log, and published together with the new version, so that users can understand the specific content and impact of the upgrade and make corresponding adjustments or updates as needed.
[0074] The version information may refer to detailed information about the current version of the first script, which is used to identify and manage different versions of scripts, and usually includes key elements such as the script version number, release date, change log, compatibility information, license information, etc. These version information are usually recorded in a document, such as README.md, CHANGELOG.md, VERSION.txt (version information text file) or the comment section of the script file, where md is the extension of the Markdown file, indicating that the file is written in the Markdown language and can contain formatted text, links, pictures, etc. Markdow is a lightweight markup language.
[0075] It is understandable that when the device management platform sends upgrade information or version information of the first script to the embedded device, the information also carries a link to the first script. This can simplify the upgrade process and enable the embedded device to directly download the required first script file through subsequent steps without having to go through complex steps to find and obtain the file, thereby reducing the need for human intervention and improving upgrade efficiency. In addition, through the link download method, it can be combined with security mechanisms such as authentication to ensure the security of the download process and prevent the script file from being tampered with or replaced. At the same time, it can ensure that the embedded device obtains the correct version of the script file, avoiding compatibility issues caused by version inconsistencies.
[0076] In one achievable method, S101 is specifically implemented through the following steps:
[0077] The upgrade information or version information issued by the device management platform is obtained; then, a link to the first script is parsed from the upgrade information or version information.
[0078] It should be noted that the upgrade information or version information issued by the device management platform can be based on the query request of the embedded device and respond to the query request, or it can be automatically issued based on the manually controlled upgrade and update operation. When the upgrade information issued by the device management platform indicates that the embedded device needs to add certain functions, or the version information indicates that the version of the first script needs to be updated to add new functions, the upgrade information or version information will also carry a link to the first script, which is a download link for the first script.
[0079] Since upgrade information or version information is usually recorded in specific documents, the link pattern is searched for different document formats or structures. For example, the link usually starts with http: / / or https: / / , or appears in the form of [description](link) in Markdown format, so as to determine the link of the first script.
[0080] It can be understood that by pre-writing certain operating functions of the embedded device, including operations, tasks or behaviors, into a script, i.e., a first script, and storing it on a device management platform, the embedded device can obtain a link to the script according to actual needs, thereby dynamically updating the device's functions without changing the firmware of the embedded device, thereby achieving the purpose of upgrading.
[0081] In one achievable manner, before obtaining the link of the first script for upgrading the embedded device, the method further includes:
[0082] Send heartbeat information to the device management platform; then, receive response information corresponding to the heartbeat information sent by the device management platform.
[0083] Wherein, the heartbeat information is a signal sent periodically, which is used to detect whether the network device or system component is operating normally. In the present embodiment, the heartbeat information is used to indicate that the embedded device is in an online state, and is sent by the embedded device to the device management platform to prove its online state and normal function. Correspondingly, the response information is a response to the received heartbeat information, which is usually sent by the receiver to the sender, that is, sent by the device management platform to the embedded device to confirm that the information has been received and to perform corresponding processing. Therefore, if the device management platform does not receive the heartbeat information sent by the embedded device within a predetermined time, it can be considered that the embedded device may fail, so that the step of sending the link of the first script to the embedded device is not executed.
[0084] It is understandable that verifying the health status of embedded devices through the device management platform before upgrading them can ensure the stability and reliability of embedded devices, and potential problems can be discovered and handled in a timely manner through regular communication and feedback.
[0085] S102: Obtain the first script from the device management platform according to the link of the first script.
[0086] Among them, the first script is stored in the device management platform for unified management, so the script can be obtained according to the link of the first script through the network protocol corresponding to the link. In this embodiment, the network protocols used include but are not limited to Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Message Queuing Telemetry Transport Protocol (MQTT), Hypertext Transfer Protocol (HTTP), Constrained Application Protocol (CoAP), File Transfer Protocol (FTP), etc.
[0087] In some embodiments, when the device management platform is a cloud storage server, a corresponding software development kit (SDK) may be used to obtain the script.
[0088] It is understandable that when the device management platform releases upgrade information or a new script version, the embedded device can automatically download and apply it through the link immediately, ensuring that the device can obtain the latest functions and fixes in a timely manner, reducing the need for manual operations, simplifying the upgrade and update process, and improving efficiency, thereby reducing device downtime and improving device availability.
[0089] S103: Upgrade the embedded device according to the first script.
[0090] It should be noted that after obtaining the first script, the corresponding script interpreter can be used to run the script to implement the function corresponding to the first script. For different types of script files, the script interpreter can be a Python interpreter, a Bash interpreter, etc. These script interpreters can be downloaded and installed by visiting the corresponding official website, and this embodiment does not limit this.
[0091] Furthermore, in order to adapt to the smaller storage space, low operating speed and real-time requirements of embedded devices, in this embodiment, by integrating an embedded script interpreter, compared with traditional computer script interpreters, embedded system features are introduced, which can streamline script parsing strategies and execution statements, and only perform script parsing related to embedded system management, peripheral control and network communication. Among them, embedded script interpreters include but are not limited to MicroPython interpreters, eLua interpreters, Elk interpreters, etc.
[0092] It is understandable that, in addition to the above-mentioned beneficial effects, when upgrading the embedded device through the first script, the script can also record logs during the upgrade process, facilitate tracing and analyzing problems during the upgrade process, and ensure that the upgrade process is transparent and traceable. On the other hand, the first script can be reused for multiple devices or multiple versions, reducing the differences between different devices and versions, thereby reducing development and testing costs and simplifying development and testing work.
[0093] In this embodiment, S103 is specifically implemented through the following steps:
[0094] First, the source code of the first script is read; then, the source code is subjected to lexical analysis and syntax analysis to generate embedded bytecode; finally, the embedded bytecode is executed to upgrade the embedded device.
[0095] The source code of the first script may refer to a text file written in a programming language, which contains the instructions and logic of the program, and these instructions and logic define the behavior and function of the program. Through the compilation or interpretation process, the computer can execute these instructions to achieve specific tasks or functions.
[0096] By performing lexical analysis on the source code, the source code can be converted into a series of tokens, each of which represents a basic element in the source code, such as a keyword, identifier, operator, and symbol. Furthermore, by performing syntax analysis, the token stream can be converted into an abstract syntax tree (AST) to represent the structure of the source code, and then the abstract syntax tree is converted into embedded bytecode, and the generated embedded bytecode is output in binary format or other executable format so that it can be executed on embedded devices.
[0097] It is understandable that the above steps are all completed by the script interpreter. Specifically, the front end of the script interpreter is responsible for lexical analysis and syntax analysis, the middle stage of the script interpreter generates embedded bytecode, and the back end of the interpreter is responsible for executing the generated bytecode. By converting the source code into an executable form, the function of the first script can be realized, thereby efficiently completing the function update and upgrade of the embedded device.
[0098] For example, suppose the embedded device is a smart home device, such as a smart light bulb, whose basic functions are to turn on and off the light and adjust the brightness. When the function update requirement is to automatically adjust the brightness of the light bulb within a specific time period, by writing a corresponding script to implement this function, the smart light bulb device receives the script, interprets and executes the script through the script interpreter, and the function of automatically adjusting the brightness within a specific time period can be realized.
[0099] In the same situation, if the firmware is updated, it is necessary to add a timed brightness adjustment function to the original firmware code, compile the new code into a binary file that can be run by the device, test the new firmware in the development environment to ensure that it functions normally and does not introduce new problems, and then distribute the new firmware to the device, usually through Over-The-Air (OTA) update or through a physical connection. After the device receives the new firmware, it performs a firmware update operation and restarts the device to load the new firmware to achieve the same function.
[0100] It can be seen that compared with script updates, firmware updates are usually more complicated and time-consuming because the entire firmware needs to be recompiled, tested, and distributed. Script updates are more flexible and fast, and are suitable for frequent function adjustments and updates.
[0101] The embedded device upgrade method provided in the embodiment of the present application obtains the upgrade information issued by the device management platform or the version information of the first script, and synchronously obtains the link of the first script used to upgrade the embedded device, so as to obtain the first script. By executing the first script, the embedded device is added with the corresponding function, thereby realizing the automatic upgrade of the embedded device, reducing the complexity of manual operation by the user, improving the security and stability of the device, and further improving the upgrade efficiency of the embedded device.
[0102] Based on the above embodiments, Figure 2 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 2 .like Figure 2 As shown, a possible implementation of the above step S102 includes the following steps:
[0103] S201: parse the version of the first script from the version information.
[0104] It should be noted that different versions of scripts may contain different functions, fixes or improvements. Therefore, the embedded device receives the version information issued by the device management platform, parses the version information and matches the script version, thereby reducing the risk of errors caused by human operations and ensuring the accuracy of the upgrade process.
[0105] In some embodiments, the version information can be obtained through an application programming interface (API) call, file reading or other methods. The embedded device can also perform a consistency check to confirm the consistency of the script version required for the embedded device upgrade and the issued script version, thereby reducing errors caused by version mismatches.
[0106] It can be understood that by parsing the version of the first script from the version information, the embedded device can dynamically obtain and update the script according to the parsed version, and can selectively upgrade according to the actual needs and version information of the device to avoid unnecessary updates, thereby improving the flexibility and scalability of the system.
[0107] S202: When the version of the first script is inconsistent with the version of the second script, the first script is obtained from the device management platform according to the link of the first script, and the version of the second script is the version of the script used to upgrade the embedded device last time.
[0108] The version of the second script is the version of the script used to upgrade the embedded device last time, that is, the second script may refer to the script file currently run by the embedded device.
[0109] For example, suppose the device management platform issues a script file (first script) that implements a new function. The version number of the first script is v1.2. After receiving the version information, the embedded device will check the currently running script file (second script). The version number of the second script is v1.1, and compare the versions of the two scripts, that is, compare whether the version numbers are consistent. If they are inconsistent, the embedded device will download the latest version of the script file through the link of the first script, and execute the first script to add new functions to achieve the upgrade, that is, the embedded device is upgraded from running the second script with version number v1.1 to running the first script with version number v1.2.
[0110] Accordingly, after the above S201, there is another processing situation different from S202:
[0111] S203: When the version of the first script is consistent with the version of the second script, send the version of the second script to the device management platform.
[0112] It can be understood that if the version of the first script is consistent with the version of the second script, it means that the script version currently running on the embedded device is consistent with expectations. Therefore, by sending the version of the second script to the device management platform, the current information of the device can be synchronized to the device management platform to ensure data synchronization and consistency between the two. At the same time, the device management platform can monitor the operating status of the device through the received version information. For example, if the device sends version information regularly, the platform can ensure that the device is operating normally and there is no script loss or damage.
[0113] The embedded device upgrade method provided in the embodiment of the present application parses the latest script version from the version information, and then performs different subsequent processing steps according to the difference between the latest script version and the script version currently running on the device. When the two are consistent, the currently running version is further sent to the device management platform, which can ensure the data consistency between the platform and the device. When the two are inconsistent, the latest script is obtained for upgrading, which can avoid unnecessary updates and improve update efficiency.
[0114] Figure 3 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 3 .like Figure 3 As shown, this embodiment is in Figure 1 , Figure 2 Based on the embodiment, the overall process of the embedded device upgrade method is described, and the method includes:
[0115] S301, after the embedded device is powered on, the embedded device upgrade system is initialized, including the initialization of network communication and the initialization of the interpreter.
[0116] The embedded device upgrade system includes at least one embedded device and a device management platform, the device management platform can manage multiple embedded devices, and the embedded device integrates a script interpreter. Specifically, the device management platform can manage embedded devices in batches by group or by individual device.
[0117] Exemplarily, the device management platform can manage embedded devices in groups. A device can only belong to one group, but a group can contain multiple devices. Therefore, the script version that needs to be run can be set by group or by individual device, and the script version currently running on the device can be displayed.
[0118] Initialization can refer to the system loading necessary drivers, configuring hardware and software resources, initializing system variables and data structures, etc. Specifically, powering on an embedded device can refer to the device starting or restarting. After completing the boot process, it has network communication capabilities, can access external network resources, or exchange data with other devices, and the interpreter is ready to execute scripts.
[0119] It is understandable that initializing the embedded device is the basis for completing the subsequent upgrade process. At the same time, the embedded device upgrade system is initialized to ensure that when the entire system is started, all components and resources are correctly configured and ready, which facilitates the subsequent establishment of connection and communication between the embedded device and the device management platform.
[0120] S302, connecting the embedded device to the device management platform.
[0121] In this embodiment, each embedded device has a separate device identifier (ID) as the device identity. The embedded device initiates a connection request to the device management platform and reports the device ID to the device management platform. The device management platform searches for the device based on the reported device ID. If the corresponding device is found, the device connection is considered legal and the connection request of the embedded device is confirmed.
[0122] It can be understood that through the device ID, the device management platform can verify whether the device requesting a connection is within its management scope. Only device IDs that exist in the platform's database will be considered legitimate devices, thereby preventing unauthorized devices from accessing the system and ensuring system security and integrity.
[0123] Specifically, the device management platform can also issue personalized configurations or instructions to each device based on the device ID, that is, different upgrade information or version information. For example, devices of different models or different uses may require different function configuration scripts. The platform can issue the corresponding script link based on the device ID to ensure that the device can be upgraded normally.
[0124] S303: Query the device management platform to obtain and update the script.
[0125] Among them, querying the device management platform may refer to the embedded device sending a script version query request to the device management platform, comparing it with the script version stored in the device itself, downloading the script if there is inconsistency, and reporting the current script version to the device management platform.
[0126] S304: Run the embedded script program.
[0127] Herein, running the embedded script program may refer to obtaining the script currently required to be run through an interpreter and executing the script.
[0128] It is understandable that by running the script, the embedded device can complete device status management, peripheral operations, and network communication operations with the device management platform, thereby achieving the purpose of controlling the software logic of the embedded device.
[0129] S305: Periodically check the script version.
[0130] In this embodiment, the embedded device periodically queries and reports the script version. If the query result indicates that an update is required, the script is downloaded and updated.
[0131] It should be noted that, in addition to the periodic self-checks performed by the embedded device itself, the device management platform may issue update script instructions, and the above-mentioned upgrade process is also performed.
[0132] The embedded device upgrading method provided in the embodiment of the present application integrates a script interpreter in the embedded device, establishes a connection between the embedded device and the device management platform, remotely manages the scripts in the device through the platform, controls the device to run the corresponding script, and uses the interpretation characteristics of the script interpreter to complete the functions set in the script, thereby realizing remote function management of the device.
[0133] Based on the above embodiments, Figure 4 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 4 .like Figure 4 As shown, a possible implementation of the above step S303 includes the following steps:
[0134] S401. Send a heartbeat message to the device management platform to prove that the device is online.
[0135] The heartbeat information is used to prove that the device is online. If the device does not send a heartbeat message within a preset time, the device management platform determines that the embedded device is offline.
[0136] S402, query the script version, and determine whether the script version is the same as the script version stored locally. If so, execute S406, otherwise execute S403.
[0137] In this embodiment, by sending a script version query request to the device management platform, the embedded device can obtain the script version to be executed and compare the version with the script version stored on the device.
[0138] S403: Receive a response from the device management platform and obtain a download link for the script.
[0139] S404: Download the script according to the download link.
[0140] S405: Store the script in non-volatile storage.
[0141] Among them, non-volatile storage can refer to storage media that can still save data without power supply, such as NOR Flash Memory (NOR flash), NAND Flash Memory (NAND flash), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc.
[0142] It can be understood that by storing the script in non-volatile storage, it can be ensured that the script will not be lost due to unexpected power outages or system crashes, and data can be prevented from being lost when the device is shut down or restarted. In addition, the non-volatile storage can be used as part of the data backup to facilitate data recovery in the event of a system failure, thereby improving data security and reliability. At the same time, the script stored in the non-volatile storage can be accessed and executed at any time when needed without the need to re-download or rewrite.
[0143] S406: Report the currently stored script version to the device management platform.
[0144] In this embodiment, by reporting the currently stored script version to the device management platform, the user of the device management platform can view the script currently running on the embedded device in real time, which helps to manage, monitor and maintain the device.
[0145] The embedded device upgrade method provided in the embodiment of the present application first proves that the embedded device is online, then queries the consistency of the script version of the device management platform and the local machine, and then receives the platform response and synchronously obtains the download link of the script, so as to download and store the script. At the same time, the device will report the currently stored script version in real time, so that the entire upgrade process is controllable and has a high degree of security.
[0146] Based on the above embodiments, Figure 5 The process of the embedded device upgrade method provided in the embodiment of the present application Figure 5 .like Figure 5 As shown, a possible implementation of the above step S304 includes the following steps:
[0147] S501. Read embedded script source code from non-volatile storage.
[0148] S502: Perform lexical analysis on the embedded script and decompose it into a token sequence.
[0149] S503: Perform syntax analysis on the embedded script and convert the tag sequence into an abstract syntax tree.
[0150] Among them, the abstract syntax tree represents the hierarchical structure and logical relationship of the code.
[0151] S504: Convert the abstract syntax tree into embedded bytecode.
[0152] Among them, the embedded bytecode is a low-level instruction that can be executed by an embedded virtual machine.
[0153] S505: Execute the embedded bytecode.
[0154] The embedded bytecode can be executed by interpreting and executing the bytecode instructions one by one through the embedded virtual machine. Furthermore, the virtual machine manages the memory and calls functions to execute instructions.
[0155] S506: Perform garbage collection.
[0156] In this embodiment, the embedded script interpreter can automatically perform garbage collection during execution to release memory resources that are no longer in use, thereby reducing the occupied storage space.
[0157] The embedded device upgrade method provided in the embodiment of the present application uses a script interpreter to run the script to complete the functional update of the device. The script can be dynamically loaded and executed, so new functions can be tested without affecting the original functions of the device, reducing the risk of update failure. At the same time, since the script can be automatically loaded and executed, there is no need to recompile the entire firmware, making the functional update more flexible and faster.
[0158] Figure 6 The architecture of the embedded device upgrade system provided in the embodiment of the present application is shown as follows Figure 1 .like Figure 6 As shown, the embedded device upgrade system 60 includes: a device management platform module 610 and an embedded device module 620, wherein:
[0159] The device management platform module 610 includes a platform script management module 611, a device management module 612, and a platform communication module 613;
[0160] The embedded device module 620 includes a device communication module 621 , a device script management module 622 , and an embedded script interpreter module 623 .
[0161] Specifically, the device management platform module 610 is used to manage embedded devices and embedded scripts, which can be implemented using programming languages including but not limited to C, C++, Java, C#, JavaScript, Python, Go, etc. Further, the module includes a user interface (UI) for the interaction between the backend server and the front end, allowing users to access and interact through a web browser or PC application.
[0162] The platform script management module 611 is responsible for the script file management and version management on the device management platform, allowing users to add, modify, delete and query script files.
[0163] The device management module 612 is responsible for managing the script versions of embedded devices, allowing users to add, modify, query and delete devices, and query the online status and online history of devices.
[0164] The platform communication module 613 is responsible for network communication with the embedded device module 620. Specifically, with this module as the data path, the device management platform can respond to the embedded device's connection request, heartbeat request, script version query request, script download request, device script version reporting request, etc. When the script version corresponding to the device on the device management platform changes, it can also actively send a script update instruction to the embedded device.
[0165] The embedded device module 620 is used to obtain the script from the device management platform module 610 and execute the script to achieve the purpose of remote upgrade. This module uses a variety of embedded device systems with network connection capabilities, such as Wireless Fidelity (WiFi) modules, Global System for Mobile Communications (GSM) modules, Long Term Evolution (LTE) modules, etc., and runs a script interpreter.
[0166] The device communication module 621 is responsible for network communication with the device management platform module 610. Accordingly, with this module as the data path, the embedded device can send connection requests, heartbeat requests, script version query requests, script download requests, device script version reporting requests, and can also respond to script update instructions issued by the device management platform.
[0167] The device script management module 622 is responsible for managing scripts in embedded devices.
[0168] The embedded script interpreter module 623 is responsible for interpreting and executing embedded script files.
[0169] The embedded device upgrade system provided in the embodiment of the present application realizes communication and connection between different end sides through the independent action and interaction between the device management platform module and the embedded device module, and can remotely upgrade the embedded device while realizing efficient device management.
[0170] Figure 7 The architecture of the embedded device upgrade system provided in the embodiment of the present application is shown as follows Figure 2 .like Figure 7 As shown, this embodiment is in Figure 6 Based on the embodiment, the architecture of the embedded script interpreter module 623 is described in detail, including:
[0171] The interpreter system management module 701 is used to manage the system of the embedded device. Exemplarily, the device status management includes low power management, device restart, device shutdown, etc.; the file system includes file reading and writing, file system mounting, folder management, file search, etc.; time management includes network time synchronization, obtaining system time, obtaining power-on time, etc.; device information query includes querying the device serial number (SN) code, device software and hardware version, etc.
[0172] The interpreter peripheral management module 702 is used to manage the peripherals of the embedded device and provide an interface for script execution. Exemplary functions include GPIO management, timer management, UART management, I2C management, SPI management, USB management, interrupt management, LCD management, audio management, encryption management, SDIO management, etc.
[0173] The interpreter communication management module 703 is used to manage the communication of the embedded device.
[0174] Figure 8 This is a schematic diagram of the structure of the embedded device upgrade device provided in the embodiment of the present application. Figure 8 As shown, the embedded device upgrade device 80 includes:
[0175] A first acquisition module 801 is used to acquire a link of a first script for upgrading an embedded device, wherein the link of the first script is determined based on the upgrade information issued by the device management platform or based on the version information of the first script issued by the device management platform, and the first script is a pre-designed script for upgrading an embedded device;
[0176] A second acquisition module 802, configured to acquire the first script from the device management platform according to the link of the first script;
[0177] The upgrading module 803 is used to upgrade the embedded device according to the first script.
[0178] Optionally, the first acquisition module 801 is specifically configured to:
[0179] Obtain upgrade information or version information issued by the device management platform;
[0180] A link to the first script is parsed from the upgrade information or the version information.
[0181] Optionally, the first acquisition module 801 is specifically configured to:
[0182] Parsing the version of the first script from the version information;
[0183] When the version of the first script is inconsistent with the version of the second script, the first script is obtained from the device management platform according to the link of the first script, and the version of the second script is the version of the script used to upgrade the embedded device last time.
[0184] Optionally, it also includes:
[0185] The sending module is used to send the version of the second script to the device management platform when the version of the first script is consistent with the version of the second script.
[0186] Optionally, the upgrade module 803 is specifically configured to:
[0187] Read the source code of the first script;
[0188] Perform lexical analysis and syntax analysis on the source code to generate embedded bytecode;
[0189] Execute embedded bytecode to upgrade the embedded device.
[0190] Optionally, the sending module 803 is further configured to:
[0191] Send heartbeat information to the device management platform. The heartbeat information is used to indicate that the embedded device is online.
[0192] The first acquisition module 801 is further used for:
[0193] Receive the response information corresponding to the heartbeat information sent by the device management platform.
[0194] The embedded device upgrade apparatus provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be described in detail here.
[0195] Fig. 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig. 9 As shown, the electronic device 90 provided in the embodiment of the present application includes: at least one processor 901 and a memory 902. The device 90 also includes a communication component 903. The processor 901, the memory 902 and the communication component 903 are connected via a bus 904.
[0196] In a specific implementation process, at least one processor 901 executes the computer execution instructions stored in the memory 902, so that at least one processor 901 executes the above-mentioned embedded device upgrade method.
[0197] The specific implementation process of the processor 901 can be found in the above-mentioned method embodiment, and its implementation principle and technical effect are similar, so the embodiments of the present application will not be repeated here.
[0198] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. The steps of the method disclosed in the present application may be directly embodied as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.
[0199] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.
[0200] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.
[0201] The present application also provides a computer program product, including a computer program, which implements the above-mentioned embedded device upgrade method when executed by a processor.
[0202] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above-mentioned embedded device upgrade method is implemented.
[0203] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.
[0204] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.
[0205] To this end, an embodiment of the present application provides a computer-readable storage medium, in which multiple instructions are stored. The instructions can be loaded by a processor to execute the steps in any embedded device upgrade method provided in the embodiment of the present application.
[0206] The storage medium may include: a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.
[0207] According to one aspect of the present application, a computer program product or a computer program is provided. The computer program product or the computer program comprises computer instructions stored in a computer-readable storage medium.
[0208] Since the instructions stored in the storage medium can execute the steps in any embedded device upgrade method provided in the embodiments of the present application, the beneficial effects that can be achieved by any embedded device upgrade method provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.
[0209] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.
[0210] It should be further noted that, although the various steps in the flowchart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.
[0211] It should be understood that the above-mentioned device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units / modules in the above-mentioned embodiments is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.
[0212] In addition, unless otherwise specified, each functional unit / module in each embodiment of the present application may be integrated into one unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of a software program module.
[0213] If the integrated unit / module is implemented in the form of hardware, the hardware may be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. If not specifically stated, the processor may be any appropriate hardware processor, such as a CPU, a GPU, an FPGA, a DSP, and an ASIC, etc. If not specifically stated, the storage unit may be any appropriate magnetic storage medium or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random-Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.
[0214] If the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a memory and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the methods of each embodiment of the present application.
[0215] In the above embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not 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.
[0216] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.
[0217] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.
Claims
1. A method for upgrading an embedded device, characterized in that: Applied to an embedded device, the method comprises: Obtaining a link to a first script for upgrading the embedded device, wherein the link to the first script is determined based on upgrade information issued by a device management platform or based on version information of the first script issued by the device management platform, and the first script is a pre-designed script for upgrading the embedded device; Acquire the first script from the device management platform according to the link of the first script; The embedded device is upgraded according to the first script.
2. The method according to claim 1, characterized in that The step of obtaining a link to a first script for upgrading the embedded device includes: Obtaining the upgrade information or the version information issued by the device management platform; A link to the first script is parsed from the upgrade information or the version information.
3. The method according to claim 1 or 2, characterized in that: The obtaining the first script from the device management platform according to the link of the first script includes: Parsing the version of the first script from the version information; When the version of the first script is inconsistent with the version of the second script, the first script is obtained from the device management platform according to the link of the first script, and the version of the second script is the version of the script used to upgrade the embedded device last time.
4. The method according to claim 3, characterized in that The method further comprises: When the version of the first script is consistent with the version of the second script, the version of the second script is sent to the device management platform.
5. The method according to claim 1, characterized in that The step of upgrading the embedded device according to the first script includes: Read the source code of the first script; Performing lexical analysis and grammatical analysis on the source code to generate embedded bytecode; The embedded bytecode is executed to upgrade the embedded device.
6. The method according to claim 1, characterized in that Before obtaining the link of the first script for upgrading the embedded device, the method further includes: Sending heartbeat information to the device management platform, wherein the heartbeat information is used to indicate that the embedded device is in an online state; Receive response information corresponding to the heartbeat information sent by the device management platform.
7. An embedded device upgrade device, characterized in that: include: A first acquisition module, used to acquire a link of a first script for upgrading the embedded device, wherein the link of the first script is determined based on the upgrade information issued by the device management platform or based on the version information of the first script issued by the device management platform, and the first script is a pre-designed script for upgrading the embedded device; A second acquisition module, configured to acquire the first script from the device management platform according to a link to the first script; An upgrading module is used to upgrade the embedded device according to the first script.
8. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the embedded device upgrade method according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the embedded device upgrade method according to any one of claims 1 to 6.
10. A computer program product, characterized in that It comprises a computer program, which is used to implement the embedded device upgrading method as claimed in any one of claims 1 to 6 when executed by a processor.
