Method and device for protecting camera function safety, electronic equipment and storage medium

Abstract

The invention provides a method and device for protecting camera function safety, electronic equipment and a storage medium. The method for protecting camera function safety comprises the following steps: detecting whether a system-on-chip (SoC) of a camera responds or not through a watchdog mechanism; in response to the fact that the watchdog mechanism detects that the SoC of the camera does not respond, first restart of the camera is triggered to complete fault processing; in response to the camera having a fault and the watchdog mechanism detecting that the SoC of the camera has a response, identifying the fault type of the camera; and triggering second restart of the camera to complete fault processing in response to the fact that the fault type of the camera is recognized to be a preset first type of fault.

Description

Technical Field

[0001] The present disclosure relates to the technical field of camera functional safety, and in particular to a method, device, electronic device, and computer-readable storage medium for protecting camera functional safety. Background Art

[0002] Intelligent driving operating systems are primarily targeted at the intelligent driving sector and are used in intelligent driving domain controllers. These operating systems have high requirements for safety and reliability, as well as performance and computing power. These operating systems are currently in the early stages of research and development worldwide, and the ecosystem is not yet complete. Regarding the functional safety mechanisms of automotive operating systems, existing technical examples primarily involve the functional safety mechanisms of safe vehicle control operating systems. For intelligent driving operating systems still under development, there are few independent, systematic application examples of functional safety mechanisms, and most are expanded upon in conjunction with the functional safety mechanisms of safe vehicle control operating systems. However, there are no examples of the application of complete, systematic functional safety technology solutions in actual vehicle camera equipment products.

[0003] The approaches described in this section are not necessarily approaches that have been previously conceived or employed. Unless otherwise indicated, it should not be assumed that any approach described in this section is prior art simply by virtue of its inclusion in this section. Similarly, unless otherwise indicated, the issues raised in this section should not be considered as having been recognized in any prior art. Summary of the Invention

[0004] The present disclosure provides a method, electronic device, and storage medium for protecting camera functional safety, so as to realize automatic recovery and fault feedback of the camera.

[0005] According to one aspect of the present disclosure, a method for protecting the functional safety of a camera is provided, comprising: detecting, by a watchdog mechanism, whether a system on chip (SoC) of a camera responds; in response to the watchdog mechanism detecting that the SoC of the camera does not respond, triggering a first restart of the camera to complete fault processing; in response to a camera fault and the watchdog mechanism detecting that the SoC of the camera is responsive, identifying a type of fault that has occurred in the camera; and in response to identifying that the type of fault that has occurred in the camera is a preset first type of fault, triggering a second restart of the camera to complete fault processing.

[0006] According to another aspect of the present disclosure, a device for protecting the functional safety of a camera is provided, including: a first unit configured to detect whether a system on chip (SoC) of a camera responds through a watchdog mechanism; a second unit configured to trigger a first restart of the camera to complete fault processing in response to the watchdog mechanism detecting that the SoC of the camera does not respond; a third unit configured to identify a type of fault that occurs in the camera in response to a fault occurring in the camera and the watchdog mechanism detecting that the SoC of the camera is responsive; and a fourth unit configured to trigger a second restart of the camera to complete fault processing in response to identifying that the type of fault that occurs in the camera is a preset first type of fault.

[0007] According to another aspect of the present disclosure, an electronic circuit is provided, comprising: a circuit configured to execute the steps of the above method.

[0008] According to another aspect of the present disclosure, an electronic device is provided, including: a processor; and a memory storing a program, wherein the program includes instructions, and when the instructions are executed by the processor, the processor executes the above method.

[0009] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing a program is provided. The program includes instructions that, when executed by a processor of an electronic device, cause the electronic device to perform the above method.

[0010] According to another aspect of the present disclosure, a computer program product is provided, which includes a computer program, and when executed by a processor, the computer program implements the above method.

[0011] According to another aspect of the present disclosure, a camera is provided, which includes the electronic device described above.

[0012] According to another aspect of the present disclosure, a vehicle is provided, which includes the camera described above.

[0013] According to the embodiments of the present disclosure, the watchdog mechanism and the fault detection and recovery mechanism can be used to automatically restart the camera when encountering a preset fault or a fault of SoC non-response, that is, to achieve automatic recovery of the camera fault to protect the safety of the camera function. In particular, when the camera is used for vehicle driving assistance, it can prevent the user from mistakenly believing that the camera function is still operating normally and making misjudgments in the corresponding usage scenarios, thereby threatening his or her own traffic safety, thereby ensuring the safety of the user when driving a vehicle, and also helping to realize timely reporting of fault events to users and complete recording of fault information for technical analysis.

[0014] These and other aspects of the disclosure will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings illustrate exemplary embodiments and constitute a part of the specification. Together with the description of the specification, they serve to explain exemplary implementation of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals designate similar, but not necessarily identical, elements.

[0016] Figure 1 A flowchart illustrating an exemplary process of a method for protecting camera function security according to an embodiment of the present disclosure; Figure 2 FIG. 4 shows an exemplary block diagram of an apparatus for protecting camera function safety according to an embodiment of the present disclosure; Figure 3 : shows an exemplary block diagram of a camera according to an embodiment of the present disclosure; Figure 4 A specific flow chart of an exemplary process of a method for protecting camera function security according to an embodiment of the present disclosure is shown in FIG; and Figure 5 is a block diagram illustrating an example of an electronic device according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0017] In this disclosure, unless otherwise specified, the use of terms such as "first" and "second" to describe various elements is not intended to limit the positional relationship, temporal relationship, or importance relationship of these elements. Such terms are only used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of the element, while in some cases, based on the context of the description, they may also refer to different instances.

[0018] The terms used in the descriptions of the various examples described in this disclosure are for the purpose of describing specific examples only and are not intended to be limiting. Unless the context clearly indicates otherwise, if the number of elements is not specifically limited, the element may be one or more. In addition, the term "and / or" used in this disclosure encompasses any one and all possible combinations of the listed items.

[0019] In the relevant technologies, there are no examples of the application of complete functional safety technology solutions for vehicle-mounted camera equipment products. Therefore, when a camera equipment malfunctions, the following problems may occur: (1) The user is unable to promptly detect the malfunction of the camera device. As an electronic device carried by a vehicle, this situation will cause great trouble to the user (for example, key evidence records will not be recorded), and may even cause the user to mistakenly believe that the product functions (for example, driving assistance functions such as rear lane change warning) are still working normally and make misjudgments in the corresponding usage scenarios, thereby threatening their own traffic safety; (2) The device is in a faulty state and cannot automatically recover. When the user is driving a vehicle, even if he or she senses that the vehicle camera has a fault, he or she cannot distract himself or herself to deal with it. If the device does not have a mechanism to automatically recover from a fault, it will bring a bad experience to the user; (3) Failure events cannot be recorded and traced, and vehicle camera manufacturers cannot collect specific information about the failure events through after-sales complaint channels, which is not conducive to manufacturers analyzing the cause of the failure and solving the problem in subsequent software upgrades and product iterations.

[0020] To address the aforementioned issues in the related art, the present disclosure provides a method for protecting camera functional safety. This method, through a watchdog mechanism and a fault detection and recovery mechanism, enables automatic restart of the camera when encountering a preset fault or an SoC failure, i.e., automatic camera fault recovery, thereby protecting the camera functional safety. In particular, when the camera is used for vehicle driving assistance, this method prevents users from mistakenly believing that the camera function is still operating normally and making misjudgments in the corresponding usage scenarios, thereby threatening their own traffic safety. This method ensures the safety of users while driving a vehicle and helps to promptly report fault events to users and comprehensively record fault information for technical analysis. The following describes embodiments of the present disclosure in detail with reference to the accompanying drawings.

[0021] Figure 1 A flowchart illustrating an exemplary process of a method 100 for protecting camera function security according to an embodiment of the present disclosure is shown.

[0022] In step S102 , whether the system on chip (SoC) of the camera responds may be detected through a watchdog mechanism.

[0023] In step S104 , in response to the watchdog mechanism detecting that the SoC of the camera is not responding, a first restart of the camera may be triggered to complete the fault handling.

[0024] In step S106 , in response to the camera failing and the watchdog mechanism detecting that the SoC of the camera is responding, the type of failure occurring in the camera may be identified.

[0025] In step S108 , in response to identifying that the fault type occurring in the camera is a preset first type of fault, a second restart of the camera may be triggered to complete fault processing.

[0026] By utilizing the method for protecting the functional safety of a camera provided by the embodiments of the present disclosure, a watchdog mechanism and a fault detection and recovery mechanism can be used to automatically restart the camera when encountering a preset fault or a fault in which the SoC does not respond, i.e., automatic recovery of the camera's fault can be achieved to protect the functional safety of the camera. In particular, when the camera is used for vehicle assisted driving, it can prevent users from making misjudgments in corresponding usage scenarios due to mistakenly believing that the camera function is still operating normally, thereby threatening their own traffic safety, thereby ensuring the safety of users when driving vehicles.

[0027] The various steps of method 100 are described in detail below.

[0028] In step S102 , whether the system on chip (SoC) of the camera responds may be detected through a watchdog mechanism.

[0029] A watchdog mechanism is a monitoring mechanism used to oversee the proper operation of a system, application, or hardware, and to initiate predefined recovery actions when anomalies or failures are detected. The primary purpose of a watchdog is to improve system reliability and stability, preventing system hangs or prolonged periods of unresponsiveness. Software watchdogs typically exist as independent threads or processes, periodically checking whether the monitored task or service is responding properly.

[0030] In step S104 , in response to the watchdog mechanism detecting that the SoC of the camera is not responding, a first restart of the camera may be triggered to complete the fault handling.

[0031] In some examples, in response to the watchdog mechanism detecting that the SoC of the camera is not responding, that is, the SoC watchdog feeding fails, a first restart of the camera is triggered to complete fault processing.

[0032] In some examples, the low-level software watchdog mechanism is independent of other logic modules in the camera firmware system and operates at a lower level than other logic modules in the camera system. Therefore, even if the SoC fails and becomes unresponsive, the watchdog mechanism will not fail.

[0033] In step S106 , in response to the camera failing and the watchdog mechanism detecting that the SoC of the camera is responding, the type of failure occurring in the camera may be identified.

[0034] In some embodiments, identifying the type of camera failure may include identifying the type of camera failure using a preset detection and judgment logic.

[0035] In some examples, specific detection and judgment logic is used for specific fault types. For example, the integrated circuit bus (IIC) communication between the main control SoC and the camera can be used to determine whether the camera connection is normal. If the IIC communication is unsuccessful, it is determined that the camera component has disconnected. In another example, the highest priority (minimum time period) message in the CAN bus communication between the recorder device and the external device (for example, the vehicle ECU) is used as the key message. By determining whether the key message has timed out, the bus communication status is monitored to determine whether the CAN bus communication between the recorder device and the external device (for example, the vehicle ECU) is abnormal.

[0036] In some examples, the camera firmware may include a global functional safety logic module that executes steps S106 and S108 independently of the camera's business module. Therefore, as long as the SoC remains responsive, the global functional safety logic module is unaffected by business module failures and can reliably determine the fault type.

[0037] In some embodiments, method 100 may further include, in response to identifying that the camera fault type is a preset second type of fault, triggering a reset of one or more camera components associated with the preset second type of fault to complete fault processing.

[0038] In some examples, the preset second type of failure may include two types: a failure caused by camera system data corruption and a failure of one or more components themselves.

[0039] When the preset second type of fault is caused by camera system data corruption, resetting one or more camera components can be performed by restoring data from a system data backup to ensure the normal operation of the one or more components that require the damaged system data. The system data may include camera calibration parameters, software authorization files and configuration files for third-party functional modules, all of which are backed up on the camera side. For example, camera calibration parameters are associated with the camera. If the camera calibration parameters are lost, the camera can be reset by restoring the camera calibration parameters from the system data backup.

[0040] When the predefined second-type fault is a failure of one or more components, resetting one or more camera components can involve restarting them. For example, if the detected fault is a substandard camera frame rate, this triggers a restart of multiple camera components related to image sensing to recover from the fault, while other components do not need to be restarted. Another example is a fault detected in the digital-to-analog converter IC responsible for inputting or outputting analog image signals (e.g., three consecutive unsuccessful read or write attempts on the IC) to trigger a restart of the digital-to-analog converter IC to recover from the fault.

[0041] Thus, faster automatic recovery of camera failures can be achieved by restarting or recovering data of one or more camera components associated with the failure without restarting the entire camera.

[0042] In some embodiments, the camera may have a microprocessor unit (MCU), and method 100 may further include: periodically detecting whether the microprocessor unit of the camera responds; and in response to the microprocessor unit of the camera not responding once or multiple times, triggering a third restart of the camera to complete fault processing.

[0043] In some examples, for some camera models with an MCU, the MCU's status can be periodically monitored via an interface. If no message is received from the MCU within a preset time threshold, it is considered a message return failure. One or more (for example, three) message return failures can be considered an MCU failure (MCU hang), triggering a third camera restart to recover from the failure. The specific preset time threshold and number of message return failures are not limited.

[0044] In some embodiments, the method 100 may further include, after identifying the type of fault occurring in the camera, generating an error code corresponding to the fault type; and recording the error code in a system log of the camera.

[0045] This enables comprehensive recording of fault information, making it easier for camera manufacturers to collect specific information about fault events, helping them analyze the causes of faults and resolve problems in subsequent software upgrades and product iterations.

[0046] In some embodiments, the camera in method 100 may be set on a vehicle, and method 100 may further include sending an error code to a computer of the vehicle to provide feedback on the fault event.

[0047] In some examples, the error code can be sent to the vehicle computer via a bus, Bluetooth, or Wi-Fi to trigger an early warning prompt to the user.

[0048] In some embodiments, providing fault event feedback may include displaying the fault type on a display screen of the vehicle computer or having the vehicle computer voice broadcast the fault type.

[0049] Therefore, by sending the error code to the vehicle's computer, users can be informed of camera device malfunctions in a timely manner, preventing users from mistakenly believing that product functions (for example, driving assistance functions such as rear lane change warning) are still operating normally and making misjudgments in corresponding usage scenarios, thereby threatening their own traffic safety.

[0050] In step S108 , in response to identifying that the fault type occurring in the camera is a preset first type of fault, a second restart of the camera may be triggered to complete fault processing.

[0051] In some examples, the camera manufacturer or user may preset the type of fault. When it is identified that the camera fault type is a preset first type of fault, the camera is restarted to complete the fault processing.

[0052] In some examples, failures that can be recovered by restart attempts may include, but are not limited to, the following failures: - The camera component is disconnected from the main control SoC; - Bluetooth (BLE) component interface abnormality; - Inertial measurement unit (IMU) interface abnormality (the main control SoC fails to read and write the IMU's IIC); - The CAN bus communication between the recorder and the external device (such as the vehicle ECU) is abnormal.

[0053] In some embodiments, the first restart, second restart, and third restart may be different from a manual restart. A manual restart requires a comprehensive TF card check, which is slow (usually takes tens of seconds after the camera is powered on again). The first restart, second restart, and third restart can skip the TF card check, thereby achieving a quick restart.

[0054] Specifically, the skipped TF card detection may include at least one of the following actions: detecting whether the capacity / speed level of the TF card after mounting meets the requirements, detecting whether the TF card file system is intact, detecting whether the directory structure of the TF card meets the requirements, and detecting whether there are non-native files on the TF card.

[0055] In some embodiments, the second reboot of the camera can be disabled through the debug serial port to prevent the camera from performing repeated second reboots.

[0056] Generally, the camera's SoC will not lose response repeatedly, so the first restart triggered by the watchdog mechanism will not occur repeatedly. However, if the SoC is still responsive, the camera may still detect the preset first type of fault after the second restart, causing the camera to restart repeatedly. Therefore, the second restart can be disabled through the debug serial port to prevent the camera from restarting repeatedly due to unrecoverable faults, facilitating repair and fault analysis.

[0057] According to an embodiment of the present disclosure, a device for protecting the safety of camera functions is also provided. Figure 2, an exemplary block diagram of an apparatus for protecting camera functional safety according to an embodiment of the present disclosure is shown in FIG. The apparatus 200 for protecting camera functional safety may include a first unit 210 configured to detect whether a camera system-on-chip (SoC) responds through a watchdog mechanism; a second unit 220 configured to trigger a first restart of the camera to complete fault processing in response to the watchdog mechanism detecting that the camera SoC does not respond; a third unit 230 configured to identify a type of camera fault in response to a camera fault and the watchdog mechanism detecting that the camera SoC responds; and a fourth unit 240 configured to trigger a second restart of the camera to complete fault processing in response to identifying that the camera fault is a preset first type of fault.

[0058] Here, the operations of the above-mentioned units of the device are similar to the operations of steps S102 to S108 described above, and will not be repeated here.

[0059] According to another aspect of the present disclosure, an electronic circuit is further provided, comprising a circuit configured to execute the steps of the above method.

[0060] According to another aspect of the present disclosure, an electronic device is provided, including: a processor; and a memory storing a program, wherein the program includes instructions, and when the instructions are executed by the processor, the processor executes the above method.

[0061] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing a program is further provided. The program includes instructions, which, when executed by a processor of an electronic device, cause the electronic device to perform the above method.

[0062] According to another aspect of the present disclosure, a computer program product is provided, including a computer program, wherein the computer program implements the above method when executed by a processor.

[0063] According to another aspect of the present disclosure, a camera is provided, comprising the above electronic device.

[0064] According to another aspect of the present disclosure, a vehicle is provided, comprising the above-mentioned camera.

[0065] Figure 3 An exemplary block diagram of a camera 3000 according to an embodiment of the present disclosure is shown in FIG.

[0066] The camera firmware 3000 may include a service module 3100 , a system basic support module 3200 , and a watchdog 3300 .

[0067] The watchdog 3300 belongs to the bottom layer of software and is independent of the business module 3100. Therefore, its working mechanism is stable and reliable and will not be disturbed or fail due to fault events of the camera-side business module 3100.

[0068] The service module 3100 may include an imaging service module 3110 and a communication service module 3120. The imaging service module 3110 may include an image acquisition and processing module 3111, a video storage module 3112, a visual algorithm model 3113, and an image output module 3114. The communication service module 3120 may include a bus communication module 3121, a Bluetooth communication module 3122, a Wi-Fi communication module 3123, and a warning light control module 3124. The communication service module 3120 may be used to send the error code corresponding to the fault to the vehicle's onboard computer for fault event feedback.

[0069] The system foundation support module 3200 includes board-side flash management 3210, power management 3220, system log 3230, and a global functional safety module 3240. The global functional safety module 3240 is independent of the camera's business module 3100 and, therefore, is unaffected by business module 3100 failures. It reliably performs functional safety logic actions such as fault type determination, corresponding fault code output, and camera reset based on specific fault codes. However, the global functional safety module 3240 still requires the SoC to function properly.

[0070] Figure 4 Detailed flowchart of an exemplary process 400 of the method 100 for protecting camera function security according to an embodiment of the present disclosure is shown in FIG.

[0071] The specific flow of the exemplary process 400 of the method 100 for protecting camera function safety according to an embodiment of the present disclosure may include the following steps: S401: The camera fails and the watchdog determines whether the SoC responds. If so, proceed to S405; otherwise, proceed to S402. S402, SoC did not respond, watchdog feeding failed; S403, the watchdog triggers the camera to restart; S404: Fault handling is complete, and the process ends. S405. Determine the specific type of fault through the functional safety mechanism; S406: Output an error code corresponding to the fault type, and execute S407 and S409; S407: Send the error code to the vehicle ECU; S408: Complete the feedback of the fault event to the vehicle computer, and then end; S409, recording the error code in the camera's system log; S410: Determine whether the fault is a preset serious fault. If so, proceed to S411; otherwise, proceed to S413. S411, functional safety mechanism triggers camera restart; S412, complete the fault processing, and end; and S413: Complete the fault handling and end.

[0072] It should be understood that Figure 3 The camera shown in Figure 4 The specific processes shown in FIG. 5 are for illustrative purposes only and not for limiting purposes.

[0073] See also Figure 5 Now, electronic device 500 will be described, which is an example of a hardware device (electronic device) that can be applied to various aspects of the present disclosure. Electronic device 500 can be any machine configured to perform processing and / or computing, and can be, but is not limited to, a workstation, server, desktop computer, laptop computer, tablet computer, personal digital assistant, robot, smartphone, vehicle-mounted computer, or any combination thereof. The above-described method 100 for protecting camera function security can be implemented in whole or in part by electronic device 500 or a similar device or system.

[0074] The electronic device 500 may include elements connected to or in communication with the bus 502 (possibly via one or more interfaces). For example, the electronic device 500 may include the bus 502, one or more processors 504, one or more input devices 506, and one or more output devices 508. The one or more processors 504 may be any type of processor and may include, but are not limited to, one or more general-purpose processors and / or one or more special-purpose processors (e.g., special processing chips). The input device 506 may be any type of device capable of inputting information to the electronic device 500 and may include, but are not limited to, a mouse, a keyboard, a touch screen, a microphone, and / or a remote control. The output device 508 may be any type of device capable of presenting information and may include, but are not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. Electronic device 500 may also include a non-transitory storage device 510. The non-transitory storage device may be any storage device that is non-transitory and can store data, including but not limited to a disk drive, optical storage device, solid-state memory, floppy disk, flexible disk, hard disk, magnetic tape, or any other magnetic medium, an optical disk or any other optical medium, ROM (read-only memory), RAM (random access memory), cache memory, and / or any other memory chip or cartridge, and / or any other medium from which a computer can read data, instructions, and / or code. Non-transitory storage device 510 may be removable from an interface. Non-transitory storage device 510 may contain data / programs (including instructions) / code for implementing the above-described methods and steps. Electronic device 500 may also include a communication device 512. Communication device 512 may be any type of device or system that enables communication with external devices and / or a network, and may include but is not limited to a modem, a network card, an infrared communication device, a wireless communication device, and / or a chipset, such as a Bluetooth™ device, an 802.11 device, a Wi-Fi device, a Wi-Max device, a cellular communication device, and / or the like.

[0075] The electronic device 500 may also include a working memory 514, which may be any type of working memory that can store programs (including instructions) and / or data useful for the operation of the processor 504, and may include, but is not limited to, random access memory and / or read-only memory devices.

[0076] Software elements (programs) may be located in the working memory 514, including, but not limited to, an operating system 516, one or more applications 518, drivers, and / or other data and code. Instructions for executing the aforementioned methods and steps may be included in one or more applications 518, and the aforementioned method 100 for protecting camera function security may be implemented by the processor 504 reading and executing the instructions of one or more applications 518. More specifically, in the aforementioned method 100 for protecting camera function security, steps S102-S108 may be implemented, for example, by the processor 504 executing an application 518 containing instructions for performing steps S102-S108. Furthermore, other steps in the aforementioned method 500 for protecting camera function security may be implemented, for example, by the processor 504 executing an application 518 containing instructions for performing the corresponding steps. The executable code or source code of the instructions of the software element (program) may be stored in a non-transitory computer-readable storage medium (such as the aforementioned storage device 510) and, upon execution, may be stored in the working memory 514 (possibly compiled and / or installed). The executable code or source code of the instructions of the software element (program) may also be downloaded from a remote location.

[0077] It should also be understood that various modifications may be made depending on specific requirements. For example, custom hardware may be used, and / or specific elements may be implemented using hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. For example, some or all of the disclosed methods and apparatus may be implemented by programming hardware (e.g., programmable logic circuits including field programmable gate arrays (FPGAs) and / or programmable logic arrays (PLAs)) using the logic and algorithms according to the present disclosure in assembly language or a hardware programming language (such as VERILOG, VHDL, C++).

[0078] It should also be understood that the aforementioned method can be implemented using a server-client model. For example, the client can receive data input by a user and send the data to the server. The client can also receive data input by the user, perform a portion of the processing in the aforementioned method, and send the processed data to the server. The server can receive the data from the client, execute the aforementioned method or another portion of the aforementioned method, and return the execution results to the client. The client can receive the execution results of the method from the server and present them to the user, for example, via an output device.

[0079] It should also be understood that the components of electronic device 500 can be distributed across a network. For example, some processing can be performed by one processor while other processing can be performed by another processor remote from the processor. Other components of computing system 500 can also be similarly distributed. In this way, electronic device 500 can be interpreted as a distributed computing system that performs processing at multiple locations.

[0080] Some exemplary aspects of the invention are described below.

[0081] Aspect 1. A method for protecting camera functional security, comprising: detecting whether the system on chip (SoC) of the camera responds through a watchdog mechanism; In response to the watchdog mechanism detecting that the SoC of the camera is unresponsive, triggering a first restart of the camera to complete fault handling; In response to the camera failing and the watchdog mechanism detecting that the SoC of the camera is responsive, identifying a type of failure that has occurred in the camera; and In response to identifying that the fault type occurring in the camera is a preset first type of fault, a second restart of the camera is triggered to complete fault processing.

[0082] Aspect 2. The method according to aspect 1, wherein identifying the type of failure occurring in the camera includes identifying the type of failure occurring in the camera through a preset detection and judgment logic.

[0083] Aspect 3. The method according to aspect 1, wherein the second restart of the camera can be disabled through a debug serial port to prevent the camera from repeatedly performing the second restart.

[0084] Aspect 4. The method according to aspect 1, wherein, compared with a normal restart, the first restart and the second restart of the camera skip TF card detection.

[0085] Aspect 5. The method according to aspect 1, further comprising: In response to identifying that the fault type occurring in the camera is a preset second type of fault, resetting of one or more camera components associated with the preset second type of fault is triggered to complete fault processing.

[0086] Aspect 6. The method according to aspect 1, wherein the camera has a microprocessor unit, the method further comprising: regularly detecting whether the microprocessor unit of the camera responds; and In response to the micro-processing unit of the camera failing to respond one or more times, triggering a third restart of the camera to complete fault processing.

[0087] Aspect 7. The method according to Aspect 6, wherein, compared with a normal restart, the third restart of the camera skips TF card detection.

[0088] Aspect 8. The method according to any one of aspects 1 to 7, further comprising: After identifying the type of fault occurring in the camera, generating an error code corresponding to the type of fault; and The error code is recorded in the system log of the camera.

[0089] Aspect 9. The method according to any one of aspects 1 to 7, wherein the camera is provided on a vehicle, further comprising: The error code is sent to the vehicle computer of the vehicle for fault event feedback.

[0090] Aspect 10. The method according to Aspect 9, wherein providing the fault event feedback includes displaying the fault type on a display screen of the vehicle computer or having the vehicle computer voice announce the fault type.

[0091] Aspect 11. A device for protecting camera function safety, comprising: a first unit configured to detect whether a system on chip (SoC) of the camera responds through a watchdog mechanism; a second unit configured to trigger a first restart of the camera to complete fault processing in response to the watchdog mechanism detecting that the SoC of the camera is unresponsive; a third unit configured to, in response to the camera failing and the watchdog mechanism detecting that the SoC of the camera is responsive, identify a type of failure occurring in the camera; and The fourth unit is configured to trigger a second restart of the camera to complete fault processing in response to identifying that the fault type occurring in the camera is a preset first type of fault.

[0092] Aspect 12. An electronic circuit comprising: Circuitry configured to perform the steps of the method according to any one of aspects 1 to 10.

[0093] Aspect 13. An electronic device comprising: processor; and A memory storing a program, the program comprising instructions which, when executed by the processor, cause the processor to perform the method according to any one of aspects 1 to 10.

[0094] Aspect 14. A non-transitory computer-readable storage medium storing a program, the program comprising instructions that, when executed by a processor of an electronic device, cause the electronic device to perform the method according to any one of aspects 1 to 10.

[0095] Aspect 15. A computer program product comprising a computer program, wherein the computer program implements the method according to any one of aspects 1 to 10 when executed by a processor.

[0096] Aspect 16. A camera comprising the electronic device according to aspect 13.

[0097] Aspect 17. A vehicle comprising the camera according to Aspect 16.

[0098] Although the embodiments or examples of the present disclosure have been described with reference to the accompanying drawings, it should be understood that the above-mentioned methods, systems and devices are merely exemplary embodiments or examples, and the scope of the present invention is not limited by these embodiments or examples, but is only limited by the claims after authorization and their equivalents. Various elements in the embodiments or examples may be omitted or replaced by their equivalents. In addition, the steps may be performed in an order different from that described in this disclosure. Further, the various elements in the embodiments or examples may be combined in various ways. It is important that as technology evolves, many of the elements described herein may be replaced by equivalent elements that appear after this disclosure.

Claims

1. A method for protecting camera functional security, comprising: detecting whether the system on chip (SoC) of the camera responds through a watchdog mechanism; In response to the watchdog mechanism detecting that the SoC of the camera is unresponsive, triggering a first restart of the camera to complete fault handling; In response to the camera failing and the watchdog mechanism detecting that the SoC of the camera is responsive, identifying a type of failure occurring in the camera; as well as In response to identifying that the fault type of the camera is a preset first type of fault, a second restart of the camera is triggered to complete fault processing.

2. The method according to claim 1, wherein Identifying the type of fault that occurs in the camera includes identifying the type of fault that occurs in the camera through a preset detection and judgment logic.

3. The method according to claim 1, wherein The second restart of the camera can be prohibited through the debug serial port to prevent the camera from repeatedly performing the second restart.

4. A device for protecting camera functional safety, comprising: a first unit configured to detect whether a system on chip (SoC) of the camera responds through a watchdog mechanism; a second unit configured to trigger a first restart of the camera to complete fault processing in response to the watchdog mechanism detecting that the SoC of the camera is unresponsive; a third unit configured to identify a type of failure occurring in the camera in response to the camera failing and the watchdog mechanism detecting that the SoC of the camera is responsive; as well as The fourth unit is configured to trigger a second restart of the camera to complete fault processing in response to identifying that the fault type occurring in the camera is a preset first type of fault.

5. An electronic circuit comprising: Circuitry configured to perform the steps of the method according to any one of claims 1 to 3.

6. An electronic device comprising: processor; as well as A memory storing a program, the program comprising instructions which, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 3. 7 . A non-transitory computer-readable storage medium storing a program, the program comprising instructions, which, when executed by a processor of an electronic device, cause the electronic device to execute the method according to claim 1 .

8. A computer program product comprising a computer program, wherein The computer program implements the method according to any one of claims 1 to 3 when executed by a processor.

9. A camera comprising the electronic device according to claim 6.

10. A vehicle comprising the camera according to claim 9.

Images