CN114116299A - Laser radar, starting system of laser radar and multiple starting method of laser radar - Google Patents

Abstract

The invention provides a multiple starting method of a starting system of a laser radar, the starting system and the laser radar. The starting system adopts a plurality of starting stages, and each starting stage corresponds to a plurality of starting files. The multiple boot method includes, for each boot phase: selecting a starting file from the starting files; verifying the selected starting file; if the selected boot file is not verified, another boot file is reselected from the plurality of boot files and the selected boot file is verified.

Description

Laser radar, starting system of laser radar and multiple starting method of laser radar

Technical Field

The present invention relates to the field of optoelectronic technologies, and in particular, to a multiple start-up method for a start-up system of a laser radar, the start-up system, and the laser radar.

Background

In the car networking environment, the data security, the communication security and the function security of the car are of great importance, and serious safety accidents can be caused by the leakage of key data, the stealing of communication and even the malicious control of the car function by hackers. With the development of unmanned driving, the laser radar has great significance in an internet of vehicles system as an important detection sensor of a vehicle. In order to prevent hackers from invading the laser radar system of the vehicle, causing dangerous behaviors such as laser radar point cloud data disturbance or other malicious tampering, and damaging the driving safety of the vehicle, a strict safety scheme should be designed for a software system of the laser radar.

However, current research on lidar focuses mainly on how lidar is used for peripheral detection perception, and no security scheme for software systems of lidar, in particular start-up systems of lidar, has been proposed.

Disclosure of Invention

In view of the above problems, the present invention provides a multiple start-up scheme for a start-up system of a laser radar, in which a plurality of corresponding start-up files are provided as backups for each start-up stage in a start-up process of the laser radar, respectively, so as to ensure the safety of the start-up process of the laser radar. In addition, the scheme according to some aspects of the invention can also ensure the communication safety, upgrade safety, data transmission safety and the like of the radar system.

According to one aspect of the present invention, a multiple start-up method of a start-up system of a lidar is provided. The starting system adopts a plurality of starting stages, and each starting stage corresponds to a plurality of starting files. The multiple boot method includes, for each boot phase: selecting a starting file from the starting files; verifying the selected starting file; if the selected boot file is not verified, another boot file is reselected from the plurality of boot files and the selected boot file is verified.

According to another aspect of the present invention, a lidar activation system is provided. The starting system comprises: a memory having machine-executable program code stored therein; and a processor configured to execute the machine-executable program code to perform the multiple boot method as described above.

According to a further aspect of the present invention there is provided a lidar which is started using a starting system as described above.

By utilizing the scheme of the invention, the starting safety of the laser radar can be realized, the completeness and the safety of system components are verified step by step in the starting process of the laser radar, the robustness of the system of the laser radar is ensured, and the stability and the reliability of the system of the laser radar are realized by constructing a multi-starting method. In addition, the upgrading safety of the laser radar is realized in some aspects, the correctness of the upgrading package can be verified when the version of the laser radar is upgraded, and the reliability and the stability of the upgrading are ensured.

Drawings

FIG. 1 shows a schematic diagram of an exemplary startup process of a startup system for a lidar;

FIG. 2 illustrates a file structure diagram of a boot system that performs the boot process shown in FIG. 1;

FIG. 3 shows a flow chart of a multiple start-up method of a start-up system of a lidar in accordance with an embodiment of the invention;

FIG. 4 shows a schematic diagram of a secure information storage structure according to an embodiment of the invention; and

FIG. 5 shows a schematic block diagram of an example device that may be used to implement an embodiment of the invention.

Detailed Description

The embodiments of the present invention will be described in detail below with reference to the accompanying drawings in order to more clearly understand the objects, features and advantages of the present invention. It should be understood that the embodiments shown in the drawings are not intended to limit the scope of the present invention, but are merely intended to illustrate the spirit of the technical solution of the present invention.

In the following description, for the purposes of illustrating various disclosed embodiments, certain specific details are set forth in order to provide a thorough understanding of the various disclosed embodiments. One skilled in the relevant art will recognize, however, that the embodiments may be practiced without one or more of the specific details. In other instances, well-known devices, structures and techniques associated with this application may not be shown or described in detail to avoid unnecessarily obscuring the description of the embodiments.

Throughout the specification and claims, the word "comprise" and variations thereof, such as "comprises" and "comprising," are to be understood as an open, inclusive meaning, i.e., as being interpreted to mean "including, but not limited to," unless the context requires otherwise.

Reference throughout this specification to "one embodiment" or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment. Thus, appearances of the phrases "in one embodiment" or "in some embodiments" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

As used in this specification and the appended claims, the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. It should be noted that the term "or" is generally employed in its sense including "and/or" unless the context clearly dictates otherwise.

In the scheme of the invention, a plurality of backups are prepared for the starting file required by each starting stage of the starting system of the radar system, so that the whole starting system can realize multi-system backup, restoration and recovery. In addition, by performing multiple verifications for the startup file used in each startup phase, the safety of the startup of the lidar is further ensured.

Fig. 1 shows a schematic diagram of an exemplary start-up procedure 100 of a start-up system of a lidar. Fig. 2 shows a file structure diagram of a boot system that executes the boot process 100 shown in fig. 1.

As shown in fig. 1 and 2, a complete startup process 100 of a current lidar startup system may include three startup phases, namely a first startup phase 110, a second startup phase 120, and a third startup phase 130, each corresponding to a plurality of startup files. The boot files corresponding to each boot phase have the same content and role, and thus can be regarded as backups of each other.

In one embodiment, the first boot phase 110 may be referred to as a boot file boot phase. It corresponds to a plurality of BOOT files, such as BOOT1, BOOT2, etc., shown in fig. 2.

The second launch phase 120 may be referred to as a system file launch phase, which corresponds to a plurality of system files, such as SYS1, SYS2, and SYS3 shown in FIG. 2. Here, SYS is a document system or the like for forming a system. In one embodiment, each system file is file information that is encrypted with the system file.

The third start-up phase 130 may be referred to as an application layer file start-up phase, which corresponds to a plurality of application layer files, such as APP1, APP2 shown in fig. 2.

The normal start sequence of the system is: searching for a valid boot file, then starting a corresponding file such as an FPGA (field programmable gate array), then loading a required file, guiding a kernel to start, and mounting a file system. Therefore, when the files in the system are maliciously replaced and tampered, the system cannot diagnose, and the laser radar enters a malicious system.

In order to ensure the security of the startup link, the operation of signing or encrypting each file is required. However, simple one-time encryption is used for

Although the startup process 100 is described in fig. 1 and 2 as including three startup phases, those skilled in the art will appreciate that the multiple startup scheme of the present invention may include more or fewer startup phases. Furthermore, although the description in fig. 2 is given by way of example that the first BOOT phase 110 corresponds to two BOOT files BOOT1, BOOT2, the second BOOT phase 120 corresponds to three system files SYS1, SYS2 and SYS3, and the third BOOT phase 130 corresponds to two application layer files APP1, APP2, it will be understood by those skilled in the art that each BOOT phase may correspond to more or fewer BOOT files.

Since each boot phase corresponds to multiple boot files, the multiple boot method according to the present invention can be designed for each boot phase to improve the success rate and safety of booting.

Fig. 3 shows a flow chart of a multiple start-up method 300 of a start-up system of a lidar in accordance with an embodiment of the invention. The method 300 may be used for at least one of the plurality of startup phases 110, 120, and 130, respectively, of the startup process 100 shown in fig. 1.

Method 300 includes step 310, wherein a boot file is selected from a plurality of boot files.

For the first boot phase 110, selecting a boot file from a plurality of boot files comprises: a BOOT file BOOT1 or BOOT2 is selected from a plurality of BOOT files.

For the second boot phase 120, selecting a boot file from the plurality of boot files comprises: one system file SYS1, SYS2, or SYS3 is selected from among the plurality of system files.

For the third boot phase 130, selecting a boot file from the plurality of boot files comprises: an application layer file APP1 or APP2 is selected from a plurality of application layer files.

Here, a method of selecting one start-up file from a plurality of start-up files may be various. In one embodiment, a boot file may be selected from a plurality of boot files in a predetermined order in step 310.

The predetermined order may be a fixed priority order set for a plurality of boot files.

For example, if the priority of the BOOT1 is preset to be higher than that of the BOOT2, the BOOT1 is preferably selected as the BOOT file at each BOOT. However, in this case, the BOOT file with the highest priority (for example, BOOT1) is always selected preferentially, and therefore, it may not be possible to find the failure of the other BOOT files (for example, BOOT2) in time, thereby losing the advantage that BOOT2 and BOOT1 are backup to each other.

For this reason, in another embodiment, the predetermined order may be designed as a rotation order set for a plurality of boot files, for example, the rotation order in which the three system files SYS1, SYS2, and SYS3 are set in advance is SYS2 → SYS1 → SYS2 → SYS1 … … → SYS3 → SYS 3. Thus, at the first system startup, the SYS2 is preferentially selected as the startup file in the second startup phase 120; at the second system boot, the SYS1 is preferentially selected as the boot file … … in the second boot phase 120, so that it can be timely found whether each boot file is operating normally.

Further, in some embodiments, the predetermined order may also be a combination of a fixed priority order and a rotating order. For example, assuming that one of the three system files SYS1, SYS2, and SYS3 (e.g., SYS3) is designated as a system file originating from the network side at the time of startup, it is possible to set the priority of the system file to be the lowest and set the startup order of the other system files to be rotated. In this case, when a system file is started, attempts are always made from the SYS1 or the SYS2, and only when neither of the SYS1 and the SYS2 is successful, attempts are made to start from the SYS 3.

In other embodiments, a boot file may be selected from a plurality of boot files in a random order in step 310. This also avoids the above-mentioned disadvantage of fixed priority order. However, in this manner, some extra measures are required in order to make the system aware that a failure has occurred in the boot file, as described below.

Next, at step 320, the boot file selected at step 310 is verified and a determination is made at step 330 as to whether the verification passed. Here, the verification of the selected boot file is mainly to verify whether the boot file is a secure boot file. To ensure security, step 320 preferably employs multiple levels of verification.

In one embodiment, the multi-level verification includes at least two levels of verification, referred to as primary verification and final verification. In the primary authentication, the primary authentication information may be authenticated using fixed authentication information in the one-time programmable memory. In the final verification, final verification information may be acquired and the boot file may be verified based on the final verification information. In the case where the multi-level verification includes only two-level verification, the primary verification information is the final verification information. In addition, in some embodiments, at least one level of intermediate verification may be included between the primary verification and the final verification, and may obtain intermediate verification information to verify the final verification information to obtain the final verification information. Wherein the intermediate authentication information may obtain authentication based on the primary authentication information.

For the first boot phase 110, step 320 may include verifying the stored information to be verified according to the primary verification information stored in the otp memory, and further verifying the subsequent other files and/or information to be verified by using the verified information to be verified.

For the second boot phase 120, step 320 may include verifying the system file using the information to be verified (e.g., private key or signature information, etc.) corresponding to the system file and corresponding verification information (e.g., public key, etc.).

For the third boot phase 130, step 320 may include verifying the application layer file selected in step 310 with the corresponding to-be-verified information and verification information.

Fig. 4 shows a schematic diagram of a secure information storage structure according to an embodiment of the invention. As shown in fig. 4, the first otp memory 410 and the second otp memory 420 have fixed authentication information for booting up the system stored therein. A one-time programmable memory refers to a memory that can be written to only once, such as an eFuse.

Specifically, the Encryption method according to the present invention includes, but is not limited to, using Encryption or verification algorithms and methods related to asymmetric Encryption algorithm (RSA), symmetric Encryption Algorithm (AES), Hash-based Message Authentication Code (HMAC), etc. to encrypt the boot file at each stage to determine the confidentiality and integrity of the boot file.

The one-time programmable memory can only be programmed once, so that the irreparable modification of the primary verification information is ensured from the aspect of hardware, and the reliability of the whole verification chain is ensured.

In other embodiments, the one-time programmable memory may include two regions, such as memory region 410 and memory region 420. For storing primary authentication information for different authentication objects, respectively.

More preferably, the primary authentication information stored in different storage areas can also be obtained by different encryption methods.

Referring to fig. 4, fig. 4 illustrates a storage structure for implementing authentication information.

The description is made with reference to fig. 4, in which the one-time programmable memory 410 stores therein primary authentication information for authenticating an associated public key of a boot file, and the memory 430 stores therein a primary public key 431 to be authenticated, a secondary public key 432, public key signature information 433, and corresponding boot file information. In the verification process, the primary public key 431 is verified by using primary verification information, if the verification is passed, the public key signature information 432 is decoded by using the primary public key 431, and then a secondary public key 433 is verified, if the verification is successful, a required boot file is verified according to the secondary public key 432, and after the verification is successful, a boot operation is executed by using the boot file 434.

It should be noted that, the primary verification information, the primary public key information, the secondary public key information, the public key signature information, and the like are only examples, and in practice, the stored verification information may be adjusted according to an actually used signature or encryption manner. For example, the public key signature itself may be stored in the one-time programmable storage 410 to verify the public key itself stored in the storage 430; as another example, the otp storage 410 stores therein encryption information of a public key signature to verify the public key signature or the like stored in the memory 430.

Also, those skilled in the art will appreciate that the order of storing the items in the memory 430 shown in FIG. 4 is merely illustrative and is not intended to limit the scope of the present invention. In different implementation environments, the items may be stored in different orders, even in different memories or different memory partitions of the same memory.

In accordance with a preferred embodiment of the present invention, taking the first BOOT phase 110 as an example, assume that the BOOT file BOOT1 was selected at step 310. Subsequently, the CPU executes corresponding verification instruction operation to verify the system file SYS at the second stage; and after the verification is finished, continuously verifying the application layer file based on the guidance of the system file SYS.

Preferably, during the verification, in each boot phase, there may be multiple files or information to be verified (such as public keys, signatures, encrypted information, etc.), and at this time, each file to be verified may correspond to different verification information, for example, for multiple files to be verified in the same boot phase, there may correspond to multiple different intermediate levels of verification information.

More preferably, the plurality of different intermediate-level authentication information can be stored in the primary authentication information of the one-time programmable memory to realize the primary authentication.

Subsequently, if all the verification processes are successful, the start-up process is performed using the current start-up file.

As described above, in the laser radar, in order to store important information of the system, such as a MAC address, hardware information, a parameter profile, a communication certificate, an upgrade certificate, and the like, a configuration information storage is introduced to store the information. In this case, the memory 430 of the booting system may further store therein authentication information (e.g., a public key) corresponding to the encryption information (e.g., a private key) of the configuration information storage. Therefore, in some embodiments, the verification may further include verifying correctness of the data stored in the configuration information storage by using a public key corresponding to a private key of the configuration information storage.

Through the multi-stage verification, the adopted public key and the adopted file are ensured to be correct, and the safety problem caused by the fact that the public key and the file are modified simultaneously is avoided.

Returning to FIG. 3, if the determination at step 330 is "NO," the method 300 proceeds to step 340 by reselecting another boot file from the plurality of boot files and performing the verification process of step 320 for the boot file. For example, if it is determined at sub-step 328 that the selected BOOT file BOOT1 did not verify, as described above, then at step 340 the BOOT file BOOT2 may be selected and the verification process described above performed thereon.

The reselection shown in step 340 may also be implemented differently depending on the rule for selecting the start-up file. For example, another boot file may be reselected from the plurality of boot files in a predetermined order or in a random order in step 340, similar to step 310. Except that when the boot files are selected in a random order, step 340 further includes setting a validation flag bit to indicate the presence of a boot file failure.

The startup process 100 (or the multiple startup method 300) according to the present invention may also include initiating a file recovery process. More specifically, in one embodiment, after the boot system is booted, it is determined whether the boot file used is an expected boot file determined in a predetermined order; and if it is determined that the used boot file is not the expected boot file, restoring the expected boot file using the used boot file, i.e., copying the used boot file to the expected boot file.

As described above, in step 310, the startup system may select a startup file according to a predetermined order. After the system is started, it may be determined according to the predetermined order whether the boot file used is the boot file determined according to the predetermined order in step 310. For example, in the case where the predetermined order is a fixed priority order, if the BOOT1 priority is greater than the BOOT2, the BOOT system may determine whether the BOOT file used for booting is BOOT1 or BOOT2 during BOOT file recovery. If the BOOT file used is BOOT1, it indicates that the BOOT file used BOOT1 has no failure. Conversely, if the BOOT file used is BOOT2, indicating that BOOT1 has failed, BOOT1 may be restored using BOOT 2. For another example, in a case where the predetermined order is a rotation order, if the rotation order of the three system files is SYS2 → SYS1 → SYS2 → SYS1 … … → SYS3 → SYS3, the startup system may determine whether the expected system file SYSi (i ═ 1, 2, 3) determined according to the rotation order and the actual system file SYSj (j ═ 1, 2, 3) used for this startup coincide in the startup file recovery process. In case of inconsistency, SYSi may be recovered using SYSj. Further, in the manner using the combination of the rotation order and the fixed priority order as described above, if it is determined that the system file used for this startup is the network system file SYS3, it represents that both SYS1 and SYS2 have failed, and at this time, SYS1 and SYS2 can be restored using the network SYS 3. In another embodiment of the startup file recovery process, after the startup system is started, it is determined whether a validation flag bit is set to indicate that there is a startup file failure; and if it is determined that there is a boot file failure, restoring other boot files of the plurality of boot files except for the used boot file using the used boot file. As described above, in step 310, the startup system may select a startup file according to a random order. And if the selected boot file is not validated, another boot file may be reselected and the validation flag bit set to indicate that there is a boot file failure in step 340. In this case, in the process of recovering the boot file, whether the boot file fails or not can be directly determined according to the verification flag bit, so that in the case of a failure, all other boot files except the boot file used in the current boot can be recovered by using the boot file used in the current boot.

Note that the boot file recovery process may be performed after any one of the first boot phase 110, the second boot phase 120, and the third boot phase 130 to recover the boot files used in the corresponding boot phase, such as boot files, system files, and application layer files. Alternatively, the startup file recovery process may be performed after the entire startup process 100 is completed. In this case, a boot file selection sequence or a verification flag may be set for each boot phase, or a unified boot file selection sequence or a unified verification flag may be set for the entire boot process 100.

The boot process 100 (or the multiple boot method 300) according to the present invention may also include initiating a file upgrade process. As described above, the configuration information storage may be verified to be secure during the laser radar startup process, and the communication certificate and the upgrade certificate are stored in the configuration information storage. The communication certificate is used for verification of a secure transport layer protocol (TLS), such as double-ended verification or single-ended verification, and is used for verification between the laser radar and the client, so that the laser radar is enabled to be trusted for the client, and meanwhile, the client is also enabled to be trusted for the laser radar. If double-end authentication is used, in the connection stage of the laser radar and the client, both sides need to send own certificates to the other side for authentication, so that communication between the malicious client and the laser radar is prevented. In order to ensure the access security of the lidar, a corresponding access protocol is set to restrict the access of external clients. The upgrade certificate is used for safety protection in the upgrade process so as to confirm the safety of the upgrade package. The upgrade certificate is used for realizing safe upgrade and the safety of the upgrade package needs to be confirmed.

It should be noted that, the configuration information storage is used to indicate a storage area for storing configuration file information. In some embodiments, different configuration information may be stored centrally in a memory area, however, in other embodiments, different configuration information may be stored in different areas, and even some of the areas for storing configuration information may coincide with areas for storing other information. For example, the communication certificate is stored in the configuration information storage, and the upgrade certificate is stored in the SYS file, or the like. Those skilled in the art will appreciate that there are many possibilities for the information storage area, but that it does not affect the implementation of the present solution.

The conventional starting file upgrading process is as follows: 1) firstly, reading an upgrade certificate in a memory (at the moment, an SYS file is already expanded into a file system and is stored in the memory), authenticating an upgrade package, and determining whether the upgrade package is signed correctly; 2) verifying the information stored in the upgrade package by using the hardware information stored in the configuration information memory, and checking whether the software version is matched with the corresponding machine type; 3) if the steps 1) and 2) are successful, upgrading the corresponding upgrading packet, and if the steps fail, reporting an error and not allowing the upgrading packet to be upgraded.

However, with such a conventional boot file upgrade process, a hardware problem may occur after the upgrade, which may cause a problem when the upgrade package is written into the memory, and cause the upgrade package to fail to be booted normally, thereby causing the laser radar system to crash.

For the multiple boot method 300 of the present invention, a new boot file upgrade process can be designed to solve the above-described problems.

Specifically, when an instruction to upgrade the boot file is received, for example, a new upgrade package is received, the boot system determines the boot file (referred to as a first boot file) used for the last boot. Then a second boot file other than the used first boot file is selected from the plurality of boot files and upgraded. Preferably, the selected second boot file is stored in a different memory or memory partition than the first boot file. That is, when the boot file needs to be updated, the boot system does not update a fixed boot file, but updates the boot files other than the boot file used last time.

Then, when the system is started next time, the updated second starting file is used for starting the starting system; and if the starting is successful, upgrading other starting files in the plurality of starting files by using the upgraded second starting file. Conversely, if the boot is unsuccessful (e.g., the upgraded second boot file is not verified according to the multi-boot method 300 of FIG. 3), the upgraded second boot file is restored with the first boot file used for the last boot of the boot system, or the second boot file is rolled back. In this way, the upgrading process has stronger error tolerance and self-correction capability.

For example, assuming that the BOOT file used at the last BOOT is BOOT1, when the BOOT file is to be upgraded, BOOT2 is selected for the upgrade, and at the next BOOT, upgraded BOOT2 is selected in step 310 when the multi-BOOT method 300 is executed. If the verification of upgraded BOOT2 passes, BOOT is performed with upgraded BOOT2 and BOOT1 is updated with upgraded BOOT 2. Conversely, if the verification of upgraded BOOT2 fails, BOOT1 is reselected for BOOT and upgraded BOOT2 is restored with BOOT 1.

Here, the boot file upgrade procedure may upgrade the boot file of any one of the first boot stage 110, the second boot stage 120, or the third boot stage 130, or upgrade all boot files involved in the whole boot procedure. More preferably, when the boot files of the third boot stage 130 are already included in the boot files of the second boot stage 120, the boot file upgrade procedure may upgrade the boot files of any one of the first boot stage 110 and the second boot stage 120. Thus, there is no need to separately upgrade the boot files of the third boot stage 130.

By utilizing the starting file upgrading process and adding the upgrading package starting verification link, the characteristic of multiple starting files is fully utilized, and even if the upgrading is unsuccessful, the normal starting of the system can be at least still maintained, so that the whole system has better robustness. I.e. not only the security of the system is ensured, but also the robustness of the system is ensured.

The start-up process 100 (or the multiple start-up method 300) according to the present invention may also include a rescue mode (rescue mode) process. The rescue mode procedure can be performed after the first start-up phase 110 or after the second start-up phase 120. Specifically, after the first boot stage 110, the boot system first determines whether the hardware memory corresponding to the system file used in the second boot stage 120 is intact, and if it is found that the system file is damaged, the system is restarted. And, in case the restart fails for a plurality of times (e.g. 3 times), trigger the start-up system to enter the rescue mode.

As an alternative, after the first boot phase 110, the boot system may also authenticate that other information, such as whether the data of the configuration information store is intact. And if the configuration information memory is damaged, starting the system to enter a rescue mode.

As an alternative, in the second boot phase 120, the boot system may enter the rescue mode if all system files (e.g., SYS1, SYS2, and network SYS3) fail to verify.

In the rescue mode, at least any one of the following ways can be provided to deal with the system fault:

1) error reporting operation;

2) uploading fault information;

3) formatting the partitions;

4) re-upgrade the system, etc.

In this way, the rescue mode provides a measure of relief in the event of a hardware failure or all boot files are incorrect.

FIG. 5 shows a schematic block diagram of an example device 600 that may be used to implement an embodiment of the invention. The device 600 may be, for example, a desktop or laptop computer, etc. As shown, device 600 may include one or more Central Processing Units (CPUs) 610 (only one shown schematically) that may perform various appropriate actions and processes according to computer program instructions stored in a Read Only Memory (ROM)620 or loaded from a storage unit 680 into a Random Access Memory (RAM) 630. In the RAM 630, various programs and data required for the operation of the device 600 can also be stored. The CPU 610, ROM 620, and RAM 630 are connected to each other via a bus 640. An input/output (I/O) interface 650 is also connected to bus 640.

Various components in device 600 are connected to I/O interface 650, including: an input unit 660 such as a keyboard, a mouse, etc.; an output unit 670 such as various types of displays, speakers, and the like; a storage unit 680, such as a magnetic disk, optical disk, or the like; and a communication unit 690 such as a network card, modem, wireless communication transceiver, etc. The communication unit 690 allows the device 600 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunications networks.

The method 100 described above may be performed, for example, by the processing unit 610 of the apparatus 600. For example, in some embodiments, the method 100 may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 680. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 600 via the ROM 620 and/or the communication unit 690. When the computer program is loaded into RAM 630 and executed by CPU 610, one or more operations of method 100 described above may be performed. Further, the communication unit 690 may support wired or wireless communication functions.

Lidar startup process 100, multiple startup method 300, and apparatus 600 in accordance with the present invention are described above with reference to the figures. Those skilled in the art will appreciate, however, that the device 600 need not contain all of the components shown in fig. 5, but may contain only some of the components necessary to perform the functions described herein, and the manner in which these components are connected is not limited to the form shown. For example, in the case where the device 600 is a portable device such as a cellular phone, the device 600 may have a different structure than that in fig. 5.

Furthermore, the present invention may be embodied as methods, devices, chip circuits, and/or computer program products as described above. The computer program product may include a computer-readable storage medium having computer-readable program instructions uploaded thereto for performing various aspects of the invention. The chip circuitry may include circuitry elements for performing various aspects of the present invention.

The computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, a punch card or an in-groove protrusion structure such as a punch card or a slot having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a variety of computing/processing devices, or from an external computer or external storage device via a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in the respective computing/processing device.

The computer program instructions for carrying out operations of the present invention may be assembler instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present invention are implemented by personalizing an electronic circuit, such as a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), with state information of computer-readable program instructions, which can execute the computer-readable program instructions.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processing unit of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable medium storing the instructions comprises an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims (11)

1. A multiple startup method for a startup system for a lidar, the startup system employing a plurality of startup phases, each startup phase corresponding to a plurality of startup files, the multiple startup method comprising, for each startup phase:

selecting a boot file from the plurality of boot files;

verifying the selected starting file;

if the selected boot file is not verified, another boot file is reselected from the plurality of boot files and the selected boot file is verified.

2. The multiple boot method of claim 1, wherein the plurality of boot stages comprises at least any two of:

-a boot file start-up phase, the boot file start-up phase corresponding to a plurality of boot files;

-a system file start-up phase, the system file start-up phase corresponding to a plurality of system files; and

-an application layer file launching phase, the application layer file launching phase corresponding to a plurality of application layer files.

3. The multi-boot method of claim 1, wherein validating the selected boot file comprises:

performing multi-stage verification on the selected boot file in at least one of the plurality of boot stages;

wherein the performing of the multi-level verification of the selected boot file at least comprises:

verifying the primary verification information using the fixed verification information stored in the one-time programmable memory; and

and acquiring final-level verification information to verify the starting file based on the final-level verification information.

4. The method of claim 3, wherein performing multi-level validation on the selected boot file further comprises:

performing two-stage verification on the selected starting file;

wherein the primary verification information is the final verification information.

5. The method of claim 3, wherein the multi-level verification further comprises:

at least one level of intermediate verification, which is used for acquiring intermediate verification information to verify final verification information so as to acquire the final verification information; wherein the intermediate authentication information obtains authentication based on the primary authentication information.

6. The multiple boot method of claim 1, further comprising:

determining whether the boot file used is an expected boot file after the boot system is booted, wherein the expected boot file is determined based on the predetermined order;

if it is determined that the boot file used is not the expected boot file, the expected boot file is restored using the boot file used.

7. The multiple boot method of claim 1, further comprising:

after the boot system boots up, determining whether a validation flag bit is set to indicate that there is a boot file failure;

and if the starting file fault exists, recovering other starting files in the starting files by using the starting file used by the starting.

8. The multiple boot method of claim 1, further comprising:

if an instruction for upgrading the starting file is received, determining a first starting file used for starting the starting system for the last time;

selecting a second boot file from the plurality of boot files, in addition to the first boot file used, wherein the second boot file is stored in a different memory or storage partition than the first boot file; and

and upgrading the second starting file.

9. The multiple boot method of claim 8, further comprising:

when the system is started next time, the updated second starting file is used for starting the starting system;

if the starting is successful, upgrading other starting files in the starting files by using the upgraded second starting file; and

and if the starting is unsuccessful, recovering the upgraded second starting file by using the first starting file used for starting the starting system for the last time.

10. A lidar actuation system comprising:

a memory having machine-executable program code stored therein; and

a processor configured to execute the machine executable program code to perform the multiple boot method of any of claims 1 to 9.

11. A lidar activated using the activation system of claim 10.

Images