System upgrading method applied to telescope embedded system and related equipment

Abstract

The invention belongs to the technical field of embedded system upgrading, and relates to a system upgrading method applied to a telescope embedded system and related equipment.The method comprises the steps that an operation system partition and a to-be-upgraded system partition are determined in a first partition and a second partition, and a system corresponding to the operation system partition is loaded; adjusting an upgrading state in the secure storage partition to a write-in state, and adjusting a starting system identifier of the shared data area to a to-be-upgraded system identifier corresponding to the to-be-upgraded system partition; sequentially writing each component in the upgrading firmware package into the to-be-upgraded system partition; after the to-be-upgraded system partition completes the write-in operation, the upgrading state in the secure storage partition is adjusted to be a successful state; and when the telescope equipment is in an idle state, loading the upgraded system corresponding to the to-be-upgraded system identifier, and starting the upgraded telescope embedded system. According to the invention, the OTA upgrading operation of the telescope embedded system can be safely and efficiently completed.

Description

Technical Field

[0001] This application relates to the field of embedded system upgrade technology, and in particular to a system upgrade method and related equipment applied to a telescope embedded system. Background Technology

[0002] With the development of technology, the functions of telescope embedded systems are becoming increasingly complex, and the requirements for system stability and performance are also increasing. To fix system vulnerabilities, add new functions, or optimize system performance, it is necessary to upgrade the telescope embedded system regularly. Traditional upgrade methods usually require manual operation by the user, connecting the device to a specific upgrade device, a cumbersome and inefficient process.

[0003] OTA (Over-The-Air) upgrade technology, as a remote upgrade method, provides convenience for upgrading embedded systems. However, there are many challenges in the OTA upgrade process of telescope embedded systems. For example, how to accurately obtain the upgrade firmware package, how to reasonably determine the running system partition and the system partition to be upgraded to avoid system crashes during the upgrade, and how to decide whether to restart the system after the upgrade based on the system's operating status and the telescope's equipment status. Currently, existing OTA upgrade technologies often lack complete solutions to these problems, leading to instability in the upgrade process and potentially affecting the normal use of the telescope. Summary of the Invention

[0004] The purpose of this application is to propose a system upgrade method and related equipment for a telescope embedded system, so as to solve the problem that the existing OTA upgrade technology has unstable upgrade process, which affects the normal use of the telescope.

[0005] To address the aforementioned technical problems, this application provides a system upgrade method for a telescope embedded system. The storage medium of the telescope embedded system is an embedded multimedia card, which includes a first partition, a second partition, a shared data area, and a secure storage partition. The method employs the following technical solution: Receive over-the-air (OTA) upgrade requests carrying the identifier of the system to be upgraded; Obtain the upgrade firmware package corresponding to the identifier of the system to be upgraded according to the over-the-air download upgrade request; In the first partition and the second partition, determine the running system partition and the system partition to be upgraded, and load the system corresponding to the running system partition; The upgrade status in the secure storage partition is adjusted to write status, and the boot system identifier of the shared data area is adjusted to the upgrade system identifier corresponding to the upgrade system partition; Write each component in the upgrade firmware package into the system partition to be upgraded in sequence; After the system partition to be upgraded completes the write operation, the upgrade status in the secure storage partition is adjusted to a successful status. When the telescope device in the telescope embedded system is in an idle state, the upgraded system corresponding to the identifier of the system to be upgraded is loaded to start the upgraded telescope embedded system.

[0006] To address the aforementioned technical problems, this application also provides a system upgrade device for a telescope embedded system. The storage medium of the telescope embedded system is an embedded multimedia card, which includes a first partition, a second partition, a shared data area, and a secure storage partition. The device employs the following technical solution: The request acquisition module is used to receive over-the-air download upgrade requests carrying the identifier of the system to be upgraded; The firmware package acquisition module is used to acquire the upgrade firmware package corresponding to the identifier of the system to be upgraded based on the over-the-air download upgrade request. The system partition to be upgraded module is used to determine the running system partition and the system partition to be upgraded in the first partition and the second partition, and load the system corresponding to the running system partition; The write status adjustment module is used to adjust the upgrade status of the secure storage partition to the write status, and adjust the boot system identifier of the shared data area to the upgrade system identifier corresponding to the upgrade system partition. A firmware package writing module is used to sequentially write each component in the upgrade firmware package into the system partition to be upgraded. The success status adjustment module is used to adjust the upgrade status of the secure storage partition to a success status after the write operation of the system partition to be upgraded is completed. The system loading module is used to load the upgraded system corresponding to the identifier of the system to be upgraded and start the upgraded telescope embedded system when the telescope device of the telescope embedded system is in an idle state.

[0007] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution: The system includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the system upgrade method for a telescope embedded system as described above.

[0008] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below: The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the system upgrade method for a telescope embedded system as described above.

[0009] This application provides a system upgrade method for a telescope embedded system. The storage medium of the telescope embedded system is an embedded multimedia card, which includes a first partition, a second partition, a shared data area, and a secure storage partition. The method includes the following steps: receiving an over-the-air (OTA) upgrade request carrying an identifier of the system to be upgraded; obtaining an upgrade firmware package corresponding to the identifier of the system to be upgraded according to the OTA upgrade request; determining a running system partition and an upgrade system partition in the first partition and the second partition, and loading the system corresponding to the running system partition; adjusting the upgrade status in the secure storage partition to a write status, and adjusting the boot system identifier in the shared data area to the upgrade system identifier corresponding to the upgrade system partition; sequentially writing each component in the upgrade firmware package into the upgrade system partition; after the upgrade system partition completes the write operation, adjusting the upgrade status in the secure storage partition to a successful status; and when the telescope device of the telescope embedded system is in an idle state, loading the upgraded system corresponding to the upgrade system identifier to start the upgraded telescope embedded system. Compared with the prior art, this application can safely and efficiently complete the OTA upgrade operation of the telescope embedded system. During the upgrade process, the system operates stably and does not affect the normal use of the telescope equipment. Furthermore, the upgraded system is only loaded and started when the equipment is idle, improving the flexibility and adaptability of the upgrade. Attached Figure Description

[0010] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 This is a flowchart illustrating the implementation of a system upgrade method for a telescope embedded system provided in an embodiment of this application. Figure 3 This is a schematic diagram of the system upgrade device for a telescope embedded system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

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

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0015] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0016] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0017] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, and a desktop computer, etc.

[0018] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0019] It should be noted that the system upgrade method for a telescope embedded system provided in this application is generally executed by a server / terminal device, and correspondingly, the system upgrade device for a telescope embedded system is generally located in the server / terminal device.

[0020] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0021] Continue to refer to Figure 2 The diagram illustrates a flowchart of an embodiment of a system upgrade method for a telescope embedded system according to this application. The system upgrade method for the telescope embedded system uses an embedded multimedia card as the storage medium. The embedded multimedia card includes a first partition, a second partition, a shared data area, and a secure storage partition. The method includes steps S201, S202, S203, S204, S205, S206, and S207.

[0022] Explanation of key technical terms in the embodiments of this application: eMMC (embedded MultiMediaCard): An embedded flash memory chip with an integrated controller, widely used in mobile phones, tablets, and embedded devices. It features partitions such as Boot Area (embedded storage device), User Area (user data storage area), and RPMB (Replay Protected Memory Block).

[0023] RPMB (Replay Protected Memory Block): A secure partition built into eMMC that supports authenticated writes, tamper-proof writing, and atomic writes. It is often used to store critical data such as keys and status flags.

[0024] OTA (Over-The-Air): A technology that allows devices to update their firmware remotely via a wireless network.

[0025] Bootloader: The program that runs first when a device starts up, responsible for loading the operating system kernel. A common example is U-Boot.

[0026] A / B partitioning: Divides the system into two symmetrical partitions, A and B, which take turns running as the operating system, enabling seamless upgrades.

[0027] In this embodiment, the application is built upon the HiSilicon SoC hi35xx embedded main control chip and the eMMC storage chip (Jiangbolong FEMDNN064G-Axxxx series). The recommended eMMC capacity is ≥64GB, supporting standard functions such as Boot Area, RPMB, and User Area.

[0028] In this embodiment, the eMMC is divided into the following logical partitions (unit: sector or MB), adopting an A / B symmetric dual-system architecture, and introducing a shared data area and a virtual USB drive area:

[0029] Among them, kernel, rootfs, and appfs all implement A / B symmetric redundancy to ensure system-level dual backup.

[0030] userdata: Stores user configurations, observation logs, star map data, camera parameters, etc. Both the first and second partitions are readable and writable by the system, ensuring that no data is lost.

[0031] udisk: When the device is connected to a PC, it can be recognized as a standard USB flash drive and used to export large files such as observation images and videos. It is independent of the system partition and avoids being formatted during upgrades.

[0032] Udisk: During upgrades, Udisk is also used to temporarily store firmware packages downloaded via OTA (usually compressed files). The condition for this is that Udisk must have enough space to store the firmware packages.

[0033] RPMB: eMMC's built-in security partition is used to store critical status markers and has features such as rollback protection, tamper protection, and atomic write capability.

[0034] In this embodiment, the entire upgrade process is initiated by the currently running system, written through a non-current system partition, and finally achieves system rotation by switching the boot target through the bootloader. The implementation steps of this application are described in detail below: In step S201, an over-the-air (OTA) upgrade request carrying the identifier of the system to be upgraded is received.

[0035] In the embodiments of this application, a user inputs a request through their user terminal device, and the request is received by the system. The user terminal may be a mobile terminal such as a mobile phone, smartphone, laptop, digital broadcast receiver, PDA (personal digital assistant), PAD (tablet computer), PMP (portable multimedia player), navigation device, etc., or a fixed terminal such as a digital TV, desktop computer, etc. It should be understood that the examples of user terminals given herein are for convenience of understanding only and are not intended to limit this application.

[0036] In this embodiment of the application, the user can initiate an OTA upgrade request through the telescope's accompanying APP or web interface.

[0037] In step S202, the upgrade firmware package corresponding to the identifier of the system to be upgraded is obtained according to the over-the-air download upgrade request.

[0038] In this embodiment of the application, the new firmware package (including kernel, rootfs, appfs, etc.) can be downloaded to the udisk partition.

[0039] In this embodiment, the current system (such as the first partition system) verifies the integrity of the firmware package (SHA256 + RSA signature) to prevent malicious firmware injection.

[0040] In step S203, the running system partition and the system partition to be upgraded are determined in the first partition and the second partition, and the system corresponding to the running system partition is loaded.

[0041] In this application embodiment, this application needs to divide the running system partition (A) and the system partition to be upgraded (B) according to the status of the first partition and the second partition. For example, if the first partition is divided into the running system partition, then the second partition is divided into the system partition to be upgraded, and vice versa. This application takes the first partition as the running system partition as an example for the following detailed description.

[0042] In this embodiment of the application, after the system partitioning is completed, the application needs to start the system corresponding to the partitioned system.

[0043] In step S204, the upgrade status in the secure storage partition is changed to write status, and the boot system identifier in the shared data area is changed to the upgrade system identifier corresponding to the system partition to be upgraded.

[0044] In this embodiment, before writing to the system partition (B) to be upgraded, the upgrade_status in RPMB and env is set to writing, and next_boot_system is set to the system partition (B) to be upgraded. The writing to RPMB and env requires eMMC authentication (using a preset key) to ensure atomicity and tamper-proof performance, preventing intermediate states even during power outages.

[0045] In step S205, each component in the upgrade firmware package is written sequentially into the system partition to be upgraded.

[0046] In step S206, after the system partition to be upgraded completes the write operation, the upgrade status in the security storage partition is adjusted to a successful status.

[0047] In this embodiment, after all partitions of the system partition (B) to be upgraded have been written, the hash value of each partition is verified to be consistent with the recorded value. If successful, upgrade_status in RPMB and env is set to success. Then the device is restarted.

[0048] In this embodiment of the application, the Bootloader (U-Boot) executes the following process upon startup: (1) Load U-boot from bootrom; (2) U-Boot reads the env environment variables; (3) Based on the env parameter, load kernel_2 and rootfs_2, and mount appfs_2; (4) Start the second partition system.

[0049] In this embodiment, after the second partition system boots up and passes the self-test, it sets the current_system in RPMB and env to 'B' to prepare for the next upgrade.

[0050] In step S207, when the telescope device of the telescope embedded system is in an idle state, the upgraded system corresponding to the identifier of the system to be upgraded is loaded and the upgraded telescope embedded system is started.

[0051] In this embodiment of the application, the application obtains the current running status of the telescope embedded system and determines whether the telescope device of the telescope embedded system is in an idle state based on the current running status. If the telescope device is not in an idle state, the telescope embedded system is not restarted. If the telescope device is in an idle state, the upgraded system corresponding to the system identifier to be upgraded is loaded and the upgraded telescope embedded system is started.

[0052] In existing technologies, OTA upgrades are typically executed immediately upon receiving a command or triggered manually by the user, without considering the current operating status of the device. This application introduces a task-aware module to determine whether the telescope is in a critical task state, such as "AI recognition of birds or animals," "distant photography or video recording," or "GPS synchronization." If a critical task is in progress, the upgrade is delayed until the task is completed or the device enters an idle period.

[0053] Compared to existing technologies, microcontroller systems typically do not involve complex task scheduling and therefore do not need to consider this issue. This application uses "task status" as a prerequisite for upgrades, which is a deep customization for telescope application scenarios. It reflects a profound understanding of the device's operating context and is not a natural extension of the common A / B partitioning scheme.

[0054] This application provides a system upgrade method for an embedded telescope system. Compared with existing technologies, this application can safely and efficiently complete OTA upgrades for the embedded telescope system. During the upgrade process, the system operates stably and does not affect the normal use of the telescope equipment. Furthermore, the upgraded system is loaded and started only when the device is idle, improving the flexibility and adaptability of the upgrade.

[0055] In some optional implementations of the embodiments of this application, the steps of determining the running system partition and the system partition to be upgraded in the first partition and the second partition specifically include the following steps: Obtain the first partition indicator data corresponding to the first partition and the second partition indicator data corresponding to the second partition, respectively; Construct an indicator scoring model, and perform health assessment operations on the indicator data of the first partition and the indicator data of the second partition according to the indicator scoring model to obtain the indicator scores of the first partition and the indicator scores of the second partition. If the score of the first partition indicator is greater than that of the second partition indicator, then the first partition will be identified as the system partition to be upgraded, and the second partition will be identified as the running system partition. If the score of the first partition indicator is less than or equal to the score of the second partition indicator, then the second partition will be identified as the system partition to be upgraded, and the first partition will be identified as the running system partition.

[0056] Compared to existing technologies, the A / B rotation in existing technologies is usually a fixed round-robin, which does not consider the actual health status of the partition. In the embodiments of this application, a health scoring model is constructed, which dynamically selects a healthier system partition as the upgrade target by comprehensively considering indicators such as eMMC bad block rate, write count, and boot stability, rather than mechanically rotating the partition. This model needs to call eMMC low-level commands (mmc extcsd read), analyze file system errors, and statistically analyze historical boot data, involving cross-layer data fusion and intelligent decision-making. Existing technologies do not disclose such adaptive strategies, especially failing to incorporate eMMC hardware characteristics for health assessment.

[0057] In this embodiment, the health score model can be a weighted scoring model, a dynamic threshold model, a machine learning model, a fuzzy comprehensive evaluation model, etc., specifically: 1. Weighted scoring model: (1) Core logic: By assigning weights to different indicators, a comprehensive score is calculated to reflect the overall health status of eMMC; (2) Implementation steps: ①Indicator standardization: • Bad block rate: Calculate the ratio of the current number of bad blocks to the total number of blocks, and map it to 0-100 points (e.g., bad block rate <1% gets 90 points, 1%-5% gets 60 points, and >5% gets 30 points).

[0058] • Write count: Calculate the remaining lifespan percentage based on the P / E (Program / Erase) cycle life provided by the manufacturer (such as 3,000-100,000 times for NAND flash memory). (For example, if it has been written 50,000 times and has a lifespan of 100,000 times, it gets 50 points.)

[0059] • Startup stability: Statistical analysis of the success rate of the most recent N startups (e.g., 99% success rate gets 90 points, 95% gets 70 points, <90% gets 40 points).

[0060] ② Weight allocation: • Determine weights using expert scoring or the Analytic Hierarchy Process (AHP). For example: • Bad block rate (40%): Reflects physical damage to storage cells.

[0061] • Write count (35%): Reflects the wear and tear of NAND flash memory.

[0062] • Startup stability (25%): Reflects system-level reliability.

[0063] ③ Overall score: Formula: Health score = Bad block rate score × 40% + Write count score × 35% + Startup stability score × 25%.

[0064] Grading standards: >80 points is "healthy", 60-80 points is "sub-healthy", and <60 points is "warning".

[0065] 2. Dynamic threshold model: (1) Core logic: Combine the usage history of eMMC and environmental factors to dynamically adjust the indicator thresholds and improve the accuracy of the assessment.

[0066] (2) Implementation steps: ①Historical data modeling: • Collect historical data on eMMC's bad block rate, write count, and boot success rate, and fit trend curves (such as linear regression or exponential decay models).

[0067] Example: The bad block rate may increase exponentially with the number of writes, and the formula is bad block rate = a × e^(b × number of writes).

[0068] ② Dynamic threshold calculation: • Predict the upper limit of the expected bad block rate based on the current number of writes or usage time. For example: • If the expected upper limit for the bad block rate is 2%, but the actual bad block rate is 3%, an alert will be triggered.

[0069] ③Activate dynamic stability adjustment: • Analyze the operating patterns before the startup failure by combining system logs (e.g., frequent power outages may lead to an increased startup failure rate).

[0070] • Dynamically adjust startup stability weights (e.g., increase weight to 30% during periods of high load).

[0071] 3. Machine learning models: (1) Core logic: Use historical data to train a model to predict the remaining lifetime (RUL) or health status of eMMC.

[0072] (2) Implementation steps: ① Feature engineering: • Input characteristics: bad block rate, write count, boot success rate, temperature, operating voltage, etc.

[0073] • Output labels: health status (healthy / sub-healthy / faulty) or remaining lifespan (days / times).

[0074] ② Model selection: • Supervised learning: Use classification models such as random forest and XGBoost to predict health status.

[0075] Survival analysis: The Cox proportional hazards model is used to predict remaining life expectancy.

[0076] • Deep learning: Using LSTM networks to process time series data (such as the change of bad block rate over time).

[0077] ③ Model training and validation: • Divide the model into training, validation, and test sets, and evaluate its performance using metrics such as accuracy and F1 score.

[0078] Example: The random forest model achieves an accuracy of up to 92% on the test set.

[0079] 4. Fuzzy comprehensive evaluation model: (1) Core logic: The uncertainty of indicators is handled by fuzzy mathematics, which is suitable for health status assessment with fuzzy boundaries; (2) Implementation steps: ① Definition of fuzzy set: • The health status is divided into four levels: “healthy”, “sub-healthy”, “early warning”, and “faulty”, with each level corresponding to a fuzzy set.

[0080] ②Membership function construction: • Define a membership function for each indicator (e.g., the "healthy" membership function for the bad block rate is μ_healthy(x) = 1 - x / 5%, where x is the bad block rate).

[0081] ③ Fuzzy comprehensive evaluation: • Calculate the membership degree of each indicator to each health level, and determine the final health status through weighted average or the maximum membership principle.

[0082] Example: If the bad block rate is 0.7 for "sub-healthy" and 0.3 for "early warning", then the overall assessment is "sub-healthy".

[0083] In some optional implementations of the embodiments of this application, the steps of determining the running system partition and the system partition to be upgraded in the first partition and the second partition specifically include the following steps: Obtain the first partition's running log data and error record information corresponding to the first partition, and the second partition's running log data and error record information corresponding to the second partition, respectively; The decision tree algorithm is used to classify the first partition's operation log data and error record information to obtain the first partition's health score. The decision tree algorithm is used to classify the second partition's operation log data and error record information to obtain the second partition's health score corresponding to the second partition. If the health score of the first partition is greater than that of the second partition, then the first partition will be designated as the system partition to be upgraded, and the second partition will be designated as the running system partition. If the health score of the first partition is less than or equal to the health score of the second partition, then the second partition will be designated as the system partition to be upgraded, and the first partition will be designated as the running system partition.

[0084] In this embodiment, it is assumed that the implementation takes place in a computer system containing two partitions (a first partition and a second partition). The system is equipped with logging software capable of recording the partition's runtime log data and error information in real time. Simultaneously, the system is pre-installed with a software module implementing a decision tree algorithm for classifying and scoring the partition data.

[0085] In this embodiment, the application can use logging software to collect runtime log data and error log information from a first partition and a second partition, respectively. For example, the runtime log data in the first partition may include records of program A's startup and shutdown at specific times, as well as resource usage; the error log information in the first partition may record memory overflow errors that occurred during the operation of program A and the time of their occurrence. Similarly, relevant data from the second partition is collected. The collected data is organized and stored according to a predetermined format for subsequent processing.

[0086] In this embodiment, the first partition's runtime log data and error record information can be input into the decision tree algorithm software module. The decision tree algorithm, following a three-step process of "feature selection - tree construction - classification decision," transforms pre-defined classification rules (such as error type classification and error frequency thresholds) into executable classification logic. For example, it classifies error types into severe errors, general errors, and minor errors, and sets different thresholds based on error frequency to classify the input data. The specific implementation process is as follows: (1) Feature engineering: Quantitative classification rules: • Error type coding: Map text labels (severe / moderate / minor) to numerical values ​​(2 / 1 / 0) as a classification basis.

[0087] • Error frequency discretization: By setting a threshold (e.g., ≥5 times / day is considered high frequency), continuous values ​​are transformed into categorical features.

[0088] (2) Decision tree construction: rule embedding tree structure: • Selection of splitting criteria: Information entropy is used as the basis for node splitting, and features that can minimize uncertainty are given priority.

[0089] • Tree depth control: Limit tree complexity by setting max_depth=3 to avoid overfitting.

[0090] • Example of the splitting process: Root node: Split by error_frequency (threshold=2.5) to distinguish between high-frequency and low-frequency errors; Child nodes: further split according to error_type, such as error_type≥1.5 (i.e., general / critical error) in high-frequency errors enter the right branch; Leaf nodes: The final output severity label (0 / 1 / 2).

[0091] (3) Classification decision: Dynamic application of threshold: Prediction process: Input new data (e.g., error_type=1, error_frequency=4), match along the decision tree path: First, determine that error_frequency = 4 > 2.5, then enter the high-frequency branch; Then, if error_type=1<1.5, it falls into the "General Error" leaf node, and the label 1 is output.

[0092] Threshold dynamism: Decision trees automatically learn the optimal split threshold (e.g., 2.5) instead of hard-coding a fixed value, adapting to the characteristics of data distribution.

[0093] In the embodiments of this application, through the above process, the decision tree transforms manually set classification rules (such as error type classification and frequency threshold) into a mathematically optimized tree structure, thereby achieving efficient and interpretable classification decisions.

[0094] In this embodiment, the data from the second partition is also input into the decision tree algorithm software module for processing. Assuming that the errors in the second partition are mostly minor and the resource usage is normal, the decision tree algorithm may classify it as having a relatively good health status and assign it a high health score (e.g., 80 points).

[0095] In this embodiment of the application, by comparing the health score of the first partition (60 points) and the health score of the second partition (80 points), since 60 < 80, according to the upgrade decision rule of the present invention, the second partition is determined as the system partition to be upgraded, and the first partition is determined as the running system partition.

[0096] In this embodiment of the application, the application can perform corresponding upgrade operations on the second partition based on the decision result, such as updating the software version, fixing system vulnerabilities, etc., to improve the health status of the second partition.

[0097] Compared with existing technologies, this application can accurately acquire system partition data and use decision tree algorithms to perform objective health assessments, thereby making scientific upgrade decisions. In practical applications, this method can effectively improve the efficiency of system maintenance, reduce upgrade errors caused by subjective judgment, and ensure the stable operation of the system.

[0098] In some optional implementations of the embodiments of this application, the step of sequentially writing each component in the upgrade firmware package into the system partition to be upgraded specifically includes the following steps: When the system partition to be upgraded experiences a power outage and restarts during a write operation, the upgrade status and the boot system identifier are read from the boot loading program. The current running system is determined to be the running system corresponding to the running system partition based on the write status and the boot system identifier. Load and run the telescope embedded system; Change the upgrade status to a failed status.

[0099] In this embodiment of the application, if a power outage occurs during the upgrade process, the application can execute the following failure recovery mechanism after restarting: (1) The Bootloader reads the status from RPMB and env and finds that upgrade_status == 2 (writing); (2) Since current_system is still 'A', the first partition system is loaded and started. (3) After the first partition system starts up, check the RPMB and env status, clean up residual data in partition B (optional), set upgrade_status = 4 (failed), and record the error log; (4) Prompt the user that the upgrade failed and they can try again.

[0100] In this embodiment, if the second partition system fails to boot (e.g., kernel crash), the user can manually switch back to the first partition system via the U-Boot command line.

[0101] In this embodiment, to ensure that the upgrade process can be restored in the event of an unexpected power outage, a multi-layered protection strategy is adopted:

[0102] In some optional implementations of the embodiments of this application, the step of sequentially writing each component in the upgrade firmware package into the system partition to be upgraded specifically includes the following steps: Write the new kernel image data from the upgrade firmware package to the spare kernel partition of the system partition to be upgraded; Write the new root file system data from the upgrade firmware package to the spare rootfs partition of the system partition to be upgraded; Write the new application data from the upgrade firmware package to the spare appfs partition of the system partition to be upgraded.

[0103] In this embodiment, when the system to be upgraded is determined to be a second partition system (because the first partition system is currently running), the components in the firmware package are sequentially written to the corresponding B partition: kernel_B ← New kernel image; rootfs_B ← New root file system (supports incremental updates or full writes); appfs_B ← New application partition.

[0104] Compared to existing technologies, most current OTA upgrade technologies involve downloading and writing the entire package. This application, however, supports Delta Patch, updating only the changed partitions in the kernel, appfs, or rootfs, and combines sparse writing and batch writing to reduce the number of eMMC erases. Achieving reliable differential upgrades on eMMC requires solving problems related to file system-level difference calculations, block device mapping, and write consistency, presenting a high technical barrier. Existing technologies do not disclose a scheme for applying differential upgrades in embedded Linux dual-systems.

[0105] In some optional implementations of the embodiments of this application, the step of sequentially writing each component in the upgrade firmware package into the system partition to be upgraded specifically includes the following steps: Whenever the size of the written data meets the preset data volume threshold, a cyclic redundancy check operation is performed on the written data to obtain the check result; If the verification result indicates that the data is incomplete, delete the written data and rewrite it. If the verification result indicates that the data is complete, the unwritten components in the upgrade firmware package will be written to the system partition to be upgraded in sequence.

[0106] In this embodiment of the application, the writing process adopts a "block verification + breakpoint resume" mechanism. After each block (e.g., 1MB) is written, a cyclic redundancy check is performed to ensure data integrity.

[0107] In practical applications, taking a certain type of intelligent astronomical telescope operating at an automatic field observation station as an example, currently using the first zone system.

[0108] Machine execution process: 1. User operation: The maintenance personnel click "Upgrade Firmware" through the mobile APP.

[0109] 2. Equipment Response: The device connects to the server via Wi-Fi and downloads the firmware package (approximately 80MB) to the udisk partition.

[0110] The first partition system verified that the firmware signature passed.

[0111] 3. Write to the second partition system: The device begins writing firmware to the second partition, the system partition: kernel_B ← New kernel rootfs_B ← New root file system appfs_B ← New version of control software A CRC check is performed every 1MB of data written.

[0112] 4. Update status: After the write operation is complete, the first partition system sets upgrade_status to writing and next_boot_system to B in RPMB.

[0113] 5. User restart: The app displays the message "Upgrade complete, please restart".

[0114] When the user clicks "Restart," the device is powered off and then powered on again.

[0115] 6. Bootloader execution: Upon booting with U-Boot, the status is read from RPMB, and it is found that next_boot_system = B.

[0116] Load boot→env→kernel_B→ramdisk_B to start the second partition system.

[0117] 7. Second partition system self-test: After successful startup, the second partition system will write current_system = B to RPMB.

[0118] The app displays "Upgraded to V2.1".

[0119] If a power outage occurs: A power outage occurred while writing to appfs_B. After rebooting, the bootloader detected that upgrade_status == writing and current_system == A, so it loaded the first partition system. After the first partition system booted, it cleaned up the remnants on partition B, marked the upgrade as failed, and the app displayed "Upgrade failed, please try again".

[0120] In summary, the dynamic upgrade timing determination, adaptive health rotation, peripheral configuration isolation, and incremental differential upgrade techniques proposed in this application are all non-obvious improvements made to the existing A / B partition general architecture based on the specific needs of the telescope embedded system. These innovations cannot be obtained through simple logical reasoning or limited experiments, demonstrating the inventors' creative labor. Furthermore, this solution significantly improves upgrade success rate, system reliability, user experience, and eMMC lifespan; it upgrades from "passive recovery" to "active prevention" and "intelligent decision-making," representing a new trend in embedded OTA upgrades; and its intelligent, adaptive firmware management for complex embedded systems meets the development needs of high-reliability devices.

[0121] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0122] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0123] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0124] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0125] Further reference Figure 3 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of a system upgrade device applied to a telescope embedded system. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0126] like Figure 3 As shown in the embodiment of this application, a system upgrade device 300 applied to a telescope embedded system, wherein the storage medium of the telescope embedded system is an embedded multimedia card, the embedded multimedia card includes a first partition, a second partition, a shared data area, and a secure storage partition, and the above device includes: The request acquisition module 310 is used to receive an over-the-air download upgrade request carrying an identifier of the system to be upgraded; Firmware package acquisition module 320 is used to acquire the upgrade firmware package corresponding to the identifier of the system to be upgraded based on the over-the-air download upgrade request; The system partition determination module 330 is used to determine the running system partition and the system partition to be upgraded in the first partition and the second partition, and load the system corresponding to the running system partition. The write status adjustment module 340 is used to adjust the upgrade status of the secure storage partition to the write status and adjust the boot system identifier of the shared data area to the upgrade system identifier corresponding to the system partition to be upgraded. Firmware package writing module 350 is used to sequentially write the various components in the upgrade firmware package into the system partition to be upgraded. The success status adjustment module 360 ​​is used to adjust the upgrade status of the security storage partition to a success status after the write operation of the system partition to be upgraded is completed. The system loading module 370 is used to load the upgraded system corresponding to the identifier of the system to be upgraded and start the upgraded telescope embedded system when the telescope device of the telescope embedded system is in an idle state.

[0127] This application provides a system upgrade device 300 for a telescope embedded system. Compared with the prior art, this application can safely and efficiently complete the OTA upgrade operation of the telescope embedded system. During the upgrade process, the system can operate stably and will not affect the normal use of the telescope equipment. Furthermore, the upgraded system is only loaded and started when the device is idle, improving the flexibility and adaptability of the upgrade.

[0128] In some optional implementations of the embodiments of this application, the above-mentioned system partition determination module to be upgraded includes: The partition indicator acquisition submodule is used to acquire the first partition indicator data corresponding to the first partition and the second partition indicator data corresponding to the second partition, respectively. The health assessment submodule is used to construct an indicator scoring model and perform health assessment operations on the indicator data of the first partition and the indicator data of the second partition according to the indicator scoring model to obtain the indicator scores of the first partition and the indicator scores of the second partition. The first partition to be upgraded system partition determination submodule is used to determine the first partition as the partition to be upgraded and the second partition as the running system partition if the first partition indicator score is greater than the second partition indicator score. The second partition to be upgraded submodule is used to determine the second partition as the partition to be upgraded and the first partition as the running system partition if the first partition index score is less than or equal to the second partition index score.

[0129] In some optional implementations of the embodiments of this application, the above-mentioned system partition determination module to be upgraded includes: The information acquisition submodule is used to acquire the first partition's running log data and error record information corresponding to the first partition, as well as the second partition's running log data and error record information corresponding to the second partition. The first health score submodule is used to classify and process the first partition's running log data and first partition's error record information according to the decision tree algorithm, and obtain the first partition's health score corresponding to the first partition. The second health scoring submodule is used to classify the second partition's running log data and error record information according to the decision tree algorithm to obtain the second partition's health score corresponding to the second partition. The third submodule for determining the system partition to be upgraded is used to determine the first partition as the system partition to be upgraded and the second partition as the running system partition if the health score of the first partition is greater than that of the second partition. The fourth submodule for determining the system partition to be upgraded is used to determine the second partition as the system partition to be upgraded and the first partition as the running system partition if the health score of the first partition is less than or equal to the health score of the second partition.

[0130] In some optional implementations of the embodiments of this application, the firmware package writing module includes: The loader startup submodule is used to read the upgrade status and the startup system identifier based on the startup loader when the system partition to be upgraded is powered off and restarted during the write operation. The system determination submodule is used to determine the current running system as the running system corresponding to the running system partition based on the write status and the boot system identifier. The system startup submodule is used to load and run the system startup telescope embedded system; The Failure Status Adjustment submodule is used to adjust the upgrade status to a failure status.

[0131] In some optional implementations of the embodiments of this application, the firmware package writing module includes: The new kernel image data writing submodule is used to write the new kernel image data in the upgrade firmware package to the spare kernel partition of the system partition to be upgraded. The new root file system data writing submodule is used to write the new root file system data in the upgrade firmware package to the spare rootfs partition of the system partition to be upgraded; The new application data writing submodule is used to write the new application data in the upgrade firmware package to the spare appfs partition of the system partition to be upgraded.

[0132] In some optional implementations of the embodiments of this application, the firmware package writing module includes: The Cyclic Redundancy Check (CR) submodule is used to perform a cyclic redundancy check on the written data whenever the size of the written data meets the preset data volume threshold, and obtain the check result. The rewrite submodule is used to delete the written data and rewrite it if the verification result is that the data is incomplete. The firmware package writing submodule is used to write the unwritten components in the upgrade firmware package to the system partition to be upgraded in sequence if the verification result shows that the data is complete.

[0133] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of a computer device according to an embodiment of this application.

[0134] Computer device 300 includes a memory 310, a processor 320, and a network interface 330 that are interconnected via a system bus. It should be noted that only computer device 300 with components 310-330 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0135] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0136] The memory 310 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 310 may be an internal storage unit of the computer device 300, such as the hard disk or memory of the computer device 300. In other embodiments, the memory 310 may also be an external storage device of the computer device 300, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Of course, the memory 310 may include both internal storage units and external storage devices of the computer device 300. In the embodiments of this application, the memory 310 is typically used to store the operating system and various application software installed on the computer device 300, such as computer-readable instructions for system upgrade methods applied to a telescope embedded system. In addition, the memory 310 can also be used to temporarily store various types of data that have been output or will be output.

[0137] In some embodiments, processor 320 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. Processor 320 is typically used to control the overall operation of computer device 300. In embodiments of this application, processor 320 is used to execute computer-readable instructions stored in memory 310 or process data, for example, to execute computer-readable instructions for a system upgrade method applied to a telescope embedded system.

[0138] The network interface 330 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 300 and other electronic devices.

[0139] The computer equipment provided in this application can safely and efficiently complete OTA upgrades of the telescope's embedded system. During the upgrade process, the system operates stably and does not affect the normal use of the telescope. Furthermore, the upgraded system is only loaded and started when the device is idle, improving the flexibility and adaptability of the upgrade process.

[0140] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the system upgrade method for a telescope embedded system as described above.

[0141] The computer-readable storage medium provided in this application enables secure and efficient OTA upgrades for telescope embedded systems. During the upgrade process, the system operates stably without affecting the normal use of the telescope. Furthermore, the upgraded system is loaded and started only when the device is idle, improving the flexibility and adaptability of the upgrade process.

[0142] 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 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 device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0143] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A system upgrade method applied to a telescope embedded system, characterized in that, The storage medium of the telescope embedded system is an embedded multimedia card, which includes a first partition, a second partition, a shared data area, and a secure storage partition. The method includes the following steps: Receive over-the-air (OTA) upgrade requests carrying the identifier of the system to be upgraded; Obtain the upgrade firmware package corresponding to the identifier of the system to be upgraded according to the over-the-air download upgrade request; In the first partition and the second partition, determine the running system partition and the system partition to be upgraded, and load the system corresponding to the running system partition; The upgrade status in the secure storage partition is adjusted to write status, and the boot system identifier of the shared data area is adjusted to the upgrade system identifier corresponding to the upgrade system partition; Write each component in the upgrade firmware package into the system partition to be upgraded in sequence; After the system partition to be upgraded completes the write operation, the upgrade status in the secure storage partition is adjusted to a successful status. When the telescope device in the telescope embedded system is in an idle state, the upgraded system corresponding to the identifier of the system to be upgraded is loaded to start the upgraded telescope embedded system.

2. The system upgrade method for a telescope embedded system according to claim 1, characterized in that, The step of determining the running system partition and the system partition to be upgraded in the first partition and the second partition specifically includes the following steps: Obtain the first partition indicator data corresponding to the first partition and the second partition indicator data corresponding to the second partition, respectively; Construct an indicator scoring model, and perform health assessment operations on the first partition indicator data and the second partition indicator data according to the indicator scoring model to obtain the first partition indicator score and the second partition indicator score. If the score of the first partition indicator is greater than the score of the second partition indicator, then the first partition is determined as the partition of the system to be upgraded, and the second partition is determined as the partition of the running system. If the score of the first partition indicator is less than or equal to the score of the second partition indicator, then the second partition is determined as the partition of the system to be upgraded, and the first partition is determined as the partition of the running system.

3. The system upgrade method for a telescope embedded system according to claim 1, characterized in that, The step of determining the running system partition and the system partition to be upgraded in the first partition and the second partition specifically includes the following steps: Obtain the first partition's running log data and error record information corresponding to the first partition, and the second partition's running log data and error record information corresponding to the second partition, respectively. The first partition's runtime log data and error record information are classified and processed using the decision tree algorithm to obtain the first partition's health score corresponding to the first partition. The decision tree algorithm is used to classify the second partition's runtime log data and error record information to obtain the second partition's health score corresponding to the second partition. If the health score of the first partition is greater than the health score of the second partition, then the first partition is determined as the system partition to be upgraded, and the second partition is determined as the running system partition; If the health score of the first partition is less than or equal to the health score of the second partition, then the second partition is determined as the system partition to be upgraded, and the first partition is determined as the running system partition.

4. The system upgrade method for a telescope embedded system according to claim 1, characterized in that, The step of sequentially writing each component of the upgrade firmware package into the system partition to be upgraded specifically includes the following steps: When the system partition to be upgraded experiences a power outage and restarts during a write operation, the upgrade status and the boot system identifier are read according to the boot loading program. Based on the write status and the boot system identifier, the current running system is determined to be the running system corresponding to the running system partition; The telescope embedded system is started by loading the operating system; Adjust the upgrade status to a failed status.

5. The system upgrade method for a telescope embedded system according to claim 1, characterized in that, The step of sequentially writing each component of the upgrade firmware package into the system partition to be upgraded specifically includes the following steps: Write the new kernel image data from the upgrade firmware package into the spare kernel partition of the system partition to be upgraded; Write the new root file system data from the upgrade firmware package to the spare rootfs partition of the system partition to be upgraded; Write the new application data from the upgrade firmware package to the spare appfs partition of the system partition to be upgraded.

6. The system upgrade method for a telescope embedded system according to claim 1, characterized in that, The step of sequentially writing each component of the upgrade firmware package into the system partition to be upgraded specifically includes the following steps: Whenever the size of the written data meets the preset data volume threshold, a cyclic redundancy check operation is performed on the written data to obtain the check result; If the verification result indicates that the data is incomplete, then the written data is deleted and a rewrite operation is performed. If the verification result indicates that the data is complete, then the unwritten components in the upgrade firmware package will be written sequentially into the system partition to be upgraded.

7. A system upgrade device for use in a telescope embedded system, characterized in that, The storage medium of the telescope embedded system is an embedded multimedia card, which includes a first partition, a second partition, a shared data area, and a secure storage partition. The device includes: The request acquisition module is used to receive over-the-air download upgrade requests carrying the identifier of the system to be upgraded; The firmware package acquisition module is used to acquire the upgrade firmware package corresponding to the identifier of the system to be upgraded based on the over-the-air download upgrade request. The system partition to be upgraded module is used to determine the running system partition and the system partition to be upgraded in the first partition and the second partition, and load the system corresponding to the running system partition; The write status adjustment module is used to adjust the upgrade status of the secure storage partition to the write status, and adjust the boot system identifier of the shared data area to the upgrade system identifier corresponding to the upgrade system partition. A firmware package writing module is used to sequentially write each component in the upgrade firmware package into the system partition to be upgraded. The success status adjustment module is used to adjust the upgrade status of the secure storage partition to a success status after the write operation of the system partition to be upgraded is completed. The system loading module is used to load the upgraded system corresponding to the identifier of the system to be upgraded and start the upgraded telescope embedded system when the telescope device of the telescope embedded system is in an idle state.

8. The system upgrade device for a telescope embedded system according to claim 7, characterized in that, The module for determining the partition of the system to be upgraded includes: The partition indicator acquisition submodule is used to acquire the first partition indicator data corresponding to the first partition and the second partition indicator data corresponding to the second partition, respectively. The health assessment submodule is used to construct an indicator scoring model and perform health assessment operations on the first partition indicator data and the second partition indicator data according to the indicator scoring model to obtain the first partition indicator score and the second partition indicator score. The first partition to be upgraded system partition determination submodule is used to determine the first partition as the partition to be upgraded and the second partition as the running system partition if the first partition indicator score is greater than the second partition indicator score. The second partition to be upgraded submodule is used to determine the second partition as the partition to be upgraded and the first partition as the running system partition if the first partition index score is less than or equal to the second partition index score.

9. A computer device, comprising a memory and a processor, characterized in that, The memory stores computer-readable instructions, and when the processor executes the computer-readable instructions, it implements the steps of the system upgrade method for a telescope embedded system as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the system upgrade method for a telescope embedded system as described in any one of claims 1 to 6.

Images