A fault recovery method, device and equipment of a vehicle-mounted camera system

Abstract

This application relates to the field of vehicle-mounted camera technology and discloses a method, apparatus, and device for fault recovery of a vehicle-mounted camera system. The method includes: receiving fault information reported by the vehicle-mounted camera system, reading a predefined strategy configuration file, assigning a corresponding processing thread to the fault information, setting the processing thread to an arbitration decision state, generating and sending a primary recovery request to the vehicle-mounted camera system, and, if the primary recovery request fails, if the decision configuration strategy in the strategy configuration file is characterized as an observation strategy, setting the processing thread to a suspended observation state to continuously monitor other fault information reported by the vehicle-mounted camera system, and when other fault information meets the exit conditions in the strategy configuration file, setting the processing thread to an arbitration decision state, generating and sending a first recovery request to the vehicle-mounted camera system. The technical solution provided by this application can improve the stability and reliability of fault recovery in vehicle-mounted camera systems.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted camera technology, and in particular to a fault recovery method, apparatus and equipment for a vehicle-mounted camera system. Background Technology

[0002] With the continuous improvement of vehicle intelligence, in-vehicle camera systems are widely used in driving recording, facial recognition, fatigue detection, intelligent driving and other functional scenarios. Their stability and reliability have become one of the core elements of vehicle functional safety. In particular, when the in-vehicle camera system is in a faulty state, the effective restoration of the camera function is crucial to ensuring driving safety.

[0003] In vehicle-mounted camera systems, current fault recovery mechanisms are typically based on simple mapping tables, triggering corresponding recovery measures for a specific fault. However, in real-world vehicle environments, complex faults present diverse conditions and causes, making it difficult to achieve recovery through a single, targeted recovery measure. Furthermore, such measures can easily amplify what was originally a simple fault.

[0004] Therefore, improving the stability and reliability of vehicle-mounted camera systems during malfunctions and achieving accurate and controllable fault recovery has become a key research focus in the field of vehicle-mounted camera technology. Summary of the Invention

[0005] This application provides a fault recovery method, apparatus, and equipment for an in-vehicle camera system. It can accurately determine the root cause of the fault and solve the fault problem by triggering the recovery mechanism at this level or by upgrading it through multiple source conditions, thereby improving the stability and reliability of the in-vehicle camera system in the fault recovery state.

[0006] This application provides a fault recovery method for an in-vehicle camera system. The method includes: receiving fault information reported by the in-vehicle camera system and reading a predefined strategy configuration file; wherein the strategy configuration file includes at least a primary recovery measure, a decision configuration strategy, an exit condition, and a first recovery measure corresponding to the fault information; allocating a corresponding processing thread to the fault information, setting the processing thread to an arbitration decision state, and generating and sending a primary recovery request representing the primary recovery measure to the in-vehicle camera system; if the primary recovery request fails to execute, and if the decision configuration strategy represents an observation strategy, setting the processing thread to a suspended observation state and continuously monitoring other fault information reported by the in-vehicle camera system; when the other fault information meets the exit condition, setting the processing thread to the arbitration decision state, and generating and sending a first recovery request representing the first recovery measure to the in-vehicle camera system.

[0007] In one implementation, the strategy configuration file adopts a structured data format and is used to define fault response strategies corresponding to various fault conditions. The strategy configuration file is predetermined based on the hardware configuration of the vehicle-mounted camera system.

[0008] In one embodiment, the policy configuration file further includes a second recovery measure, wherein the first recovery measure and the second recovery measure include one or more levels of recovery steps; the method further includes: if the primary recovery request fails to execute, and if the decision configuration policy is characterized as a hierarchical policy, then maintaining the arbitration decision state of the processing thread, generating and issuing a second recovery request representing the second recovery measure to the vehicle-mounted camera system.

[0009] In one embodiment, the method further includes: restarting the vehicle-mounted camera system if the first recovery request or the second recovery request fails.

[0010] In one implementation, allocating a corresponding processing thread to the fault information includes: when the fault information is new fault information, creating a corresponding processing thread for the fault information; and when the fault information is existing fault information, assigning the fault information to the processing thread corresponding to the existing fault information.

[0011] In one embodiment, the method further includes: if the other fault information does not meet the exit condition, maintaining the suspended observation state of the processing thread until the vehicle enters a non-use state, and generating and sending a restart recovery request to the vehicle camera system in the non-use state.

[0012] In one implementation, the exit condition is that the other fault information and the fault information come from the same signal acquisition branch, and the total amount of the other fault information and the fault information reaches a preset threshold; wherein, the signal acquisition branch includes an image signal processor, a deserializer, and multiple camera groups connected to the deserializer.

[0013] In one implementation, the decision configuration strategy is determined based on the faulty object and its importance, the faulty object including multiple camera groups, deserializers, and image signal processors.

[0014] A second aspect of this application provides a fault recovery device for an in-vehicle camera system. The device includes: a receiving configuration unit, configured to receive fault information reported by the in-vehicle camera system and read a predefined strategy configuration file; wherein the strategy configuration file includes at least a primary recovery measure, a decision configuration strategy, an exit condition, and a first recovery measure corresponding to the fault information; a first decision unit, configured to allocate a corresponding processing thread to the fault information, set the processing thread to an arbitration decision state, and generate and send a primary recovery request representing the primary recovery measure to the in-vehicle camera system; an observation creation unit, configured to, in the event that the primary recovery request fails, if the decision configuration strategy represents an observation strategy, set the processing thread to a suspended observation state and continuously monitor other fault information reported by the in-vehicle camera system; and a second decision unit, configured to, when the other fault information meets the exit condition, set the processing thread to the arbitration decision state, and generate and send a first recovery request representing the first recovery measure to the in-vehicle camera system.

[0015] A third aspect of this application provides a computer device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the fault recovery method of the vehicle-mounted camera system described in the first aspect.

[0016] Based on the above ideas, the technical solution provided in this embodiment of the application, through a multi-source condition-triggered recovery mechanism, accurately determines the root cause of the fault and resolves the fault problem, thereby improving the stability and reliability of the vehicle camera system's fault recovery. Specifically, by assigning an independent processing thread to each fault information and setting an arbitration decision state, the system can independently manage the entire lifecycle of each fault recovery to support the independent processing of multiple concurrent faults. Simultaneously, by dynamically switching the processing thread to a suspended observation state or maintaining a hierarchical state according to the decision configuration strategy after a primary recovery failure, and by combining multi-source fault information with joint exit conditions, the root cause of the fault is accurately identified. This avoids the risk of fault escalation caused by blindly resolving a single camera module fault, while ensuring that necessary faults can be resolved quickly and effectively, thereby ensuring the stability and reliability of the vehicle camera system in the fault recovery state and guaranteeing driving safety.

[0017] It is evident that the technical solution provided in this application can improve the stability and reliability of the vehicle-mounted camera system during a fault, achieve accurate and controllable fault recovery, and enhance the stability and reliability of the vehicle-mounted camera system in fault recovery. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This application provides an example diagram of a scenario for fault recovery of an in-vehicle video system. Figure 2 A schematic diagram illustrating the steps of a fault recovery method for a vehicle-mounted camera system provided in this application embodiment; Figure 3 A schematic diagram illustrating the execution flow of a fault recovery method provided in one embodiment of this application; Figure 4 This is a schematic diagram of the hardware architecture of an in-vehicle camera system provided in one embodiment of this application; Figure 5 A schematic diagram of the structure of a fault recovery device for a vehicle-mounted camera system provided in one embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] Furthermore, the use of terms such as "first," "second," etc., in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of embodiments in this application, unless otherwise stated, "multiple" means two or more. Additionally, the use of "based on" or "according to" implies openness and inclusiveness, because processes, steps, calculations, or other actions "based on" or "according to" one or more of the stated conditions or values ​​may in practice be based on additional conditions or beyond the stated values.

[0022] Typically, in an in-vehicle camera system, the total number of cameras in the cockpit and for intelligent driving can reach a dozen or even twenty. The 360° surround view function, dashcam, facial recognition, fatigue detection, and intelligent driving involved in the camera system are all crucial functions related to driving safety. Therefore, as a core component ensuring the reliability of intelligent driving, the stability and reliability of the camera system are particularly important in in-vehicle systems. However, the driving environment is complex and ever-changing. Physical factors such as bumps and signal interference can cause temporary malfunctions in the camera hardware links at any time. Furthermore, prolonged and frequent use by users increases the possibility of abnormal camera stream transmission from the software level. When the in-vehicle camera system experiences these complex malfunction scenarios, it is often difficult to recover from the fault in a timely and effective manner, affecting driving safety.

[0023] Currently, most video fault recovery mechanisms are based on predefined fault-recovery mapping tables. This involves setting fault monitoring points for hardware nodes in the link, such as camera modules, serializers, deserializers, and ISPs, and configuring linearly corresponding recovery actions. When a node reports a fault, the system directly queries the mapping table and triggers the corresponding recovery measures. However, in real-world automotive environments, scenarios where fault recovery can be achieved through simple fault-recovery mapping are extremely rare. Most recovery attempts require multiple rounds of testing, upgrades, or even waiting and observation; otherwise, simple faults can easily be amplified through recovery measures. Furthermore, due to hardware differences between vehicle models, the same set of fault recovery measures may be effective on some hardware but become ineffective after hardware replacement, impacting the overall reliability of the system in complex automotive environments.

[0024] Please see Figure 1 In a typical scenario of a mainstream in-vehicle video system framework, the fault recovery mechanism of the in-vehicle video system involves the hardware links of the camera module (including multiple camera groups, each camera group including one camera and a serializer), DES (deserializer), and ISP (image signal processor). The ISP communicates with the CPU. The aforementioned fault conditions can include one or more camera group failures, DES failures, and ISP failures. Camera group failures are further divided into camera failures and deserializer failures. The entire fault recovery mechanism is a linear mapping relationship: a camera module reporting a fault triggers its recovery measures, and an ISP fault reporting triggers its recovery measures.

[0025] In this scenario, the entire video fault detection and recovery mechanism is fixed and singular, attempting a pre-defined recovery for a specific fault. However, if a camera group experiences image output anomalies, performing a single recovery for that camera group often fails, requiring an escalated recovery. This could involve performing recovery operations on the connected deserializer and multiple connected camera groups simultaneously. However, this could escalate the fault from a single camera group to multiple camera groups, making effective recovery difficult and potentially compromising the safety and reliability of the vehicle camera system.

[0026] The above description is merely a scenario example provided in the specification and is not intended to limit the present invention. Any modifications or equivalent substitutions made within the spirit and principles of the present invention should be included within the scope of protection of the present invention. In view of this, this application provides one or more embodiments of a fault recovery method, apparatus, and device for an in-vehicle camera system, which can solve the above-mentioned problems, improve the safety and reliability of the in-vehicle camera system during a fault, and achieve accurate, controllable, and platform-adaptive fault recovery.

[0027] Please see Figure 2 One embodiment of this application provides a fault recovery method for an in-vehicle camera system, which may include the following steps: S1: Receive fault information reported by the vehicle-mounted camera system and read the predefined strategy configuration file; wherein, the strategy configuration file includes at least the primary recovery measures, decision configuration strategies, exit conditions and first recovery measures corresponding to the fault information.

[0028] The hardware architecture of the vehicle-mounted camera system includes an image signal processor (ISP), a deserializer, and multiple camera arrays connected to the deserializer, which together form a signal acquisition branch. The image signal processor is connected to the deserializer via a hardware bus, and each deserializer is connected to multiple camera arrays. When any hardware node fails, the corresponding fault signal is transmitted upwards along the branch to the central processing unit.

[0029] The fault information is used to characterize the faulty object in the vehicle-mounted camera system. According to the fault level, it is divided into one or more camera group faults, deserializer faults, and ISP faults from bottom to top. Camera group faults are further divided into camera faults and serializer faults. The primary recovery measure corresponding to the fault information is to reset the faulty object characterized by the fault information at this level.

[0030] For example, if the fault information indicates a camera fault, the primary recovery measure is to reset the corresponding camera; if the fault information indicates a serializer fault, the primary recovery measure is to reset the corresponding serializer; if the fault information indicates a deserializer fault, the primary recovery measure is to reset the deserializer; and if the fault information indicates an ISP fault, the primary recovery measure is to reset the ISP.

[0031] The aforementioned strategy configuration file is a structured data file independent of the program code. It is used to define the fault recovery strategy chain corresponding to each type of fault information, including, for example, the primary recovery measures, decision configuration strategies, exit conditions, and first recovery measures. Specifically, the strategy configuration file is loaded and parsed during system initialization. During runtime, the corresponding fault recovery strategy chain is queried based on the fault information, and the corresponding recovery measures are executed according to the actual situation based on the fault recovery strategy chain.

[0032] The aforementioned decision configuration strategy determines the next recovery operation (e.g., upgrade recovery or suspension waiting) after the initial recovery measures. The aforementioned first recovery measure refers to a single or series of recovery measures executed for upgrade recovery. For example, for a single camera failure, the initial recovery measure might be resetting the camera itself, and the first recovery measure might be resetting the camera's upstream module (e.g., deserializer). The aforementioned exit condition is the termination condition for suspension waiting. Optionally, the aforementioned decision configuration strategy is pre-configured based on the system's hardware settings and importance.

[0033] S3: Assign a corresponding processing thread to the fault information, set the processing thread to the arbitration decision state, and generate and send a primary recovery request representing the primary recovery measures to the vehicle camera system.

[0034] The aforementioned processing threads are allocated from a thread pool created during system initialization. The number of threads in the thread pool is determined based on the number of possible fault information in the measurement configuration file. Each processing thread independently manages the entire lifecycle of a fault from occurrence to resolution. Each thread has its own independent execution context, enabling parallel processing of multiple faults without mutual interference. Since the vehicle-mounted camera system may experience multiple faults simultaneously, this independent thread processing method ensures that the recovery process for a single fault is not interrupted or obstructed by the injection of other faults, thus guaranteeing the stability of system fault handling.

[0035] Each processing thread can be divided into an arbitration decision state and a suspension / observation state during execution. The arbitration decision state indicates that the current processing thread is executing a recovery measure decision or issuing a recovery request, while the suspension / observation state indicates that the current processing thread is pausing decision processing until the exit condition is met. Each recovery request encapsulates the corresponding recovery measure into standardized request information, including specific actions, target objects, relevant parameters (such as delay parameters), and the number of attempts, and sends it to the vehicle-mounted camera system via IPC. If the recovery request is executed successfully, the corresponding processing thread terminates without further recovery settings. If the recovery request fails, the subsequent recovery measures are determined and executed based on the policy configuration file.

[0036] S5: If the primary recovery request fails, and the decision configuration strategy is characterized as an observation strategy, the processing thread is set to a suspended observation state to continuously monitor other fault information reported by the vehicle camera system.

[0037] In this embodiment, the decision configuration strategy represents either an observation strategy or a hierarchical strategy. Specifically, the observation strategy indicates that the processing thread enters a suspended observation state to perform a suspended waiting operation, that is, suspends the decision processing of the current fault information and continuously monitors other reported fault information until the exit condition is met. The hierarchical strategy indicates that the processing thread maintains an arbitration decision state to perform an upgrade recovery operation, that is, makes corresponding recovery decisions and issues requests based on the subsequent recovery measures represented by the strategy configuration file.

[0038] S7: When the other fault information meets the exit condition, the processing thread is set to the arbitration decision state, and a first recovery request representing the first recovery measure is generated and sent to the vehicle camera system.

[0039] The aforementioned exit conditions are typically set to receive an additional preset number of fault messages at the same level, or to receive additional fault messages from a higher-level module. For example, for a specific camera fault, the exit condition could be receiving fault messages from another camera while in a suspended observation state, or receiving fault messages from a deserializer or image signal processor while in a suspended observation state. Once the exit condition is met, the recovery processing thread enters an arbitration decision state to generate and issue a first recovery request. For example, for a specific camera fault, the initial recovery request instructs the camera itself to be reset, while the first recovery request instructs the deserializer or image signal processor to be reset.

[0040] In one embodiment, see Figure 3 , Figure 3This is a schematic diagram of the execution flow of the entire fault recovery method. Specifically, upon receiving the reported fault information, the primary recovery measure corresponding to the fault information is read from the strategy configuration file, and a primary recovery request is sent to the vehicle-mounted camera system. If the primary recovery request fails, the decision configuration strategy corresponding to the fault information is read from the strategy configuration file. Where the decision configuration strategy is a tiered strategy, the tiered strategy instructs the execution of the second recovery measure. If recovery fails, the vehicle-mounted camera system is briefly restarted for 1-2 seconds without affecting the driving status. Where the decision configuration strategy is a tiered strategy, a suspension observation is performed until the exit conditions are met, then the first recovery measure is executed. If the exit conditions are not met, the vehicle is restarted in a non-use state. Where all recovery measures indicate successful recovery, the arbitration decision ends, and the fault recovery ends.

[0041] For example, when the fault information indicates a fault in a regular camera, if the initial recovery measures fail, an observation strategy is typically executed. Specifically, if other cameras connected to the same deserializer and experiencing faults are found, the first recovery measure is executed if a preset number of such cameras are reached; otherwise, the original fault information remains suspended and observed until the vehicle enters a non-use state, at which point a restart recovery is performed.

[0042] For example, when the fault information indicates a camera malfunction but of high importance, a tiered strategy is typically executed if the primary recovery measures fail. For example, when the fault information indicates a deserializer malfunction or an ISP malfunction, a tiered strategy is typically executed if the primary recovery measures fail.

[0043] Based on the above ideas, the technical solution provided in this embodiment of the application, through a multi-source condition-triggered recovery mechanism, accurately determines the root cause of the fault and resolves the fault problem, thereby improving the stability and reliability of the vehicle camera system's fault recovery. Specifically, by assigning an independent processing thread to each fault information and setting an arbitration decision state, the system can independently manage the entire lifecycle of each fault recovery to support the independent processing of multiple concurrent faults. Simultaneously, by dynamically switching the processing thread to a suspended observation state or maintaining a hierarchical state according to the decision configuration strategy after a primary recovery failure, and by combining multi-source fault information with joint exit conditions, the root cause of the fault is accurately identified. This avoids the risk of fault escalation caused by blindly resolving a single camera module fault, while ensuring that necessary faults can be resolved quickly and effectively, thereby ensuring the stability and reliability of the vehicle camera system in the fault recovery state and guaranteeing driving safety.

[0044] In one implementation, the strategy configuration file adopts a structured data format, which is used to define fault response strategies corresponding to various fault conditions. Optionally, the structured data format can be JSON, YAML, XML, or other structured data formats. The structured fields preset fault response strategies adapted to different scenarios, including the initial recovery measures executed immediately after receiving fault information and the first recovery measures executed after exiting the suspension observation state.

[0045] Among them, the recovery timing, reset pulse width, retry interval, and other parameters of the components at each level of the vehicle camera system vary significantly under different vehicle models and hardware solutions from different suppliers, resulting in poor adaptability of various recovery measures across different systems. For example, for a camera failure in a certain system, the corresponding primary recovery measure is to perform register initialization with a 200ms delay after reset, while after replacing with a different model of camera, the register initialization should be performed with a 500ms delay after reset.

[0046] In this implementation, a strategy configuration file adapted to the system's hardware configuration needs to be pre-determined to determine the corresponding fault response strategies under different fault conditions. For different hardware platforms (such as different models of camera arrays, serializer / deserializer chips), only the configuration file needs to be modified (e.g., adjusting the delay time after reset, changing the order of recovery actions, defining new observation conditions), without altering the core code.

[0047] The technical solution provided in this embodiment, by employing a structured data format strategy configuration file, independently stores all recovery strategy information, including fault-recovery measure mapping relationships, decision path selection, and exit conditions, in a standardized and parsable manner, achieving complete decoupling between recovery strategies and arbitration logic. Furthermore, by modifying the values ​​of corresponding fields in the configuration file for different hardware platforms, it quickly adapts to system fault recovery requirements, significantly reducing cross-platform adaptation costs and improving system maintainability and scalability.

[0048] In one implementation, the policy configuration file further includes a second recovery measure, which can be understood as an upgraded recovery action with stronger recovery power than the primary recovery measure. The first recovery measure and the second recovery measure include one or more levels of recovery steps. It can be understood that the first recovery measure or the second recovery measure may contain multiple sub-actions executed sequentially, and each sub-action defines a corresponding recovery action identifier and the number of allowed attempts.

[0049] Specifically, if the primary recovery request fails, and the decision configuration strategy is characterized as a hierarchical strategy, the arbitration decision state of the processing thread is maintained, and a second recovery request representing the second recovery measure is generated and sent to the vehicle-mounted camera system.

[0050] The aforementioned tiered strategy can be understood as a decision path where, after a primary recovery failure, the processing thread does not enter a suspended observation state but instead directly escalates the recovery effort level by level in the arbitration decision state. For example, if the faulty object is a camera module, the primary recovery measure is a separate RESET operation for that camera module. After the primary recovery fails, the second recovery measure under the tiered strategy path can be a joint RESET operation of the deserializer to which the camera module belongs and all its connected camera groups, achieving a progressive increase in recovery effort from the camera module level to the deserializer level. Optionally, both the first and second recovery measures can include multiple recovery steps. For example, the first recovery measure can represent two sub-steps: "deserializer soft reset (attempt 2 times) → deserializer hard reset (attempt 1 time)," forming a tiered processing of fault information.

[0051] In this embodiment, if either the first or second recovery request fails, the vehicle-mounted camera system is restarted. This involves performing a complete reboot of the system, re-initializing hardware, loading drivers, and performing functional self-tests from its initial state to completely eliminate faults caused by abnormal software conditions or accumulated hardware errors. This restart process serves as a fallback measure for fault recovery, triggered only if all preceding recovery measures (primary recovery, first recovery, and second recovery) have failed. After the restart process is complete, the processing thread exits the fault recovery lifecycle, and the corresponding fault handling process ends.

[0052] The technical solution provided in this embodiment designs the restart process as a fallback measure for fault recovery, ensuring that any fault ultimately has a clear resolution point, thus guaranteeing the system's ultimate recoverability. In actual operation, a small number of faults caused by deep hardware device anomalies or serious software errors cannot be resolved by resetting individual devices. In such cases, a system-level restart is required to completely clear the abnormal state. This technical solution places the restart process at the very end of the recovery layer, avoiding frequent interruptions to camera functionality due to excessive use of restart operations, thus ensuring system recoverability while also considering user experience.

[0053] In one implementation, assigning a corresponding processing thread to the fault information falls into two categories: Scenario 1: If the fault information is new fault information, that is, the fault event described by the currently received fault information does not yet have a corresponding processing thread in the system to manage its recovery life cycle, such as the first reported fault or the fault that is re-reported after the previous recovery cycle has ended, then a corresponding processing thread is created for the fault information. Scenario 2: If the fault information is existing fault information, that is, the fault event described by the currently received fault information already has a corresponding processing thread managing its recovery life cycle, such as repeated reporting of the same fault event, then the fault information will be assigned to the processing thread corresponding to the existing fault information.

[0054] Optionally, the aforementioned thread pool is pre-created during the system initialization phase based on the number of fault types defined in the policy configuration file. During runtime, there is no need to dynamically request thread resources, thereby reducing fault response latency and improving system real-time performance.

[0055] The technical solution provided in this embodiment avoids repeatedly creating processing threads for the same fault event by differentiating between new and existing fault information in its thread allocation strategy, thus ensuring the continuity and consistency of fault recovery lifecycle management. In actual operation, faults of the same hardware node may be reported multiple times in a short period of time (e.g., a camera module continuously reports fault information during reset). If a new processing thread is created for each report, multiple threads will concurrently process the same fault event, resulting in repeated execution of recovery actions and wasted resources. This technical solution, through a thread reuse mechanism for existing fault information, ensures that all reported information for the same fault event is uniformly managed by the same processing thread, maintaining the logical integrity of the recovery process.

[0056] In one embodiment, the method further includes: if the other fault information does not meet the exit condition, maintaining the suspended observation state of the processing thread until the vehicle enters a non-use state, and generating and sending a restart recovery request to the vehicle camera system in the non-use state.

[0057] The aforementioned non-use state can be understood as the vehicle being locked, turned off, or parked—a state where the user is not using the vehicle. Restarting the in-vehicle camera system in this state will not affect the user's normal driving behavior. Understandably, if other fault information fails to meet the exit conditions while the vehicle is in use, the processing thread will remain in a suspended observation state and will not actively initiate any recovery operation. The aforementioned restart recovery request can be understood as a recovery command generated in the non-use state to trigger a complete restart of the in-vehicle camera system, with the purpose of restoring the system to its normal working state before the next use of the vehicle.

[0058] For example, when the vehicle is locked, the processing thread responds to the locking event, generates and sends a restart recovery request to the vehicle-mounted camera system. Optionally, the current fault status is recorded, including the fault object identifier, fault type code, fault occurrence timestamp, executed recovery measures and their results, and the current processing thread status, so as to be traced back to the next vehicle use or during fault analysis.

[0059] The technical solution provided in this embodiment balances the thoroughness of fault recovery with the continuity of function during driving by maintaining the suspension observation state without forcibly performing a restart operation during vehicle use, and performing a restart and recovery when the vehicle is not in use. Specifically, the vehicle camera system carries functions directly related to driving safety, such as reversing image and surround view. If a system restart is forcibly performed during vehicle use, it will cause a temporary interruption of camera function, posing a driving safety hazard. This technical solution postpones the restart and recovery to the non-use state, ensuring the continued availability of camera function during vehicle use (even if it is in a faulty state but not completely disabled), and ensuring that the system is completely restored before the next use of the vehicle, thereby ensuring the stability and safety of vehicle camera system fault recovery.

[0060] In one implementation, the exit condition is that other fault information and the fault information originate from the same signal acquisition branch, and the total amount of other fault information and fault information reaches a preset threshold. The signal acquisition branch includes an image signal processor, a deserializer, and multiple camera groups connected to the deserializer.

[0061] The aforementioned "same signal acquisition branch" can be understood as a complete signal acquisition link within the vehicle-mounted camera system hardware architecture, consisting of the same image signal processor, the same deserializer, and all camera groups connected to that deserializer. Please refer to... Figure 4 In the hardware architecture of the vehicle-mounted camera system, the image signal processor is connected to the deserializer via a hardware bus. Each deserializer hosts multiple camera groups, and all camera groups under the same deserializer belong to the same signal acquisition branch. Each camera group includes one camera and a corresponding serializer. The aforementioned preset threshold is the minimum total amount of fault information required to trigger the exit condition; this total amount is the sum of the number of other fault information and the original number of fault information.

[0062] Specifically, after detecting other fault information during the suspended observation state, it is determined whether the fault object of the other fault information belongs to the same signal acquisition branch as the original fault information, that is, whether the fault object of the other fault information is connected to the same deserializer as the original fault object. Optionally, if the total number of other fault information and fault information reaches or exceeds a preset threshold, it is determined that the exit condition is met. Optionally, if the fault object of the other fault information is a deserializer or ISP, it is determined that the exit condition is met. Optionally, the above-mentioned preset threshold can be dynamically configured in the strategy configuration file according to the number of camera groups connected to different signal acquisition branches.

[0063] The technical solution provided in this embodiment further defines the exit conditions for the suspended observation state. Specifically, when other monitored fault information and the original fault information come from the same signal acquisition branch and the total amount of fault information reaches a preset threshold, the exit condition is determined to be met. The aforementioned preset threshold can also be dynamically configured in the strategy configuration file according to the number of camera groups mounted on different branches. This technical solution can avoid the expansion of faults due to blindly upgrading recovery for single-point intermittent faults, and can also ensure that faults of high importance can be identified in a timely manner and trigger corresponding recovery measures, further enhancing the safety, stability, and flexibility of fault recovery for vehicle-mounted camera systems.

[0064] In one implementation, the aforementioned decision-making configuration strategy is determined based on the faulty object and its importance. The faulty object refers to the hardware nodes at various levels in the signal acquisition branch of the vehicle-mounted camera system that may fail, specifically including multiple camera groups, deserializers, and image signal processors. The importance can be understood as the degree of impact of the camera function supported by the faulty object on driving safety and user experience. The higher the importance, the higher the timeliness requirement for the recovery of the fault, and the more proactive recovery strategy should be adopted.

[0065] Optionally, the importance of the aforementioned faulty objects, from highest to lowest, can be ranked as image signal processor, deserializer, and camera group. Optionally, the grading criteria for this importance can be defined as enumerated values ​​in the policy configuration file, and a mapping relationship can be established with the corresponding decision configuration policy type for unified management and adjustment. Specifically, for the deserializer and image signal processor, since their fault impact covers the entire signal acquisition branch, they are typically configured with a tiered policy.

[0066] Different camera groups are assigned different levels of importance based on their specific functions. For example, camera groups that handle functions directly related to driving safety, such as reversing cameras and surround-view cameras, are of higher importance and are configured with a tiered strategy to restore normal function more quickly and avoid impacting driving safety. Conversely, camera groups that handle functions less related to driving safety, such as dashcams and driver monitoring, are of lower importance and are configured with an observation strategy to avoid unnecessary upgrades and recovery operations.

[0067] The technical solution provided in this embodiment achieves differentiated fault handling strategy allocation by determining the decision configuration strategy based on the faulty object and its importance. This enables the system to adopt the most suitable processing path for hardware faults of different levels and importance. Specifically, since the functional positioning and importance of each camera group in the vehicle camera system differ significantly, a uniform decision configuration strategy cannot simultaneously meet the rapid recovery requirements of critical functions and the precise recovery requirements of non-critical functions. This technical solution, through differentiated strategy configuration based on importance, allows the system to ensure the rapid recovery of critical camera functions while adopting a more cautious observation and waiting strategy for non-critical cameras, avoiding the impact of excessive recovery operations on the overall system stability.

[0068] In one embodiment, this application also provides an in-vehicle camera system, which performs the fault recovery method described in the first aspect above to perform fault recovery, the in-vehicle camera system including a fault monitoring module, a fault recovery module, and a camera driving module; wherein: The aforementioned fault monitoring module is used to generate and report corresponding fault information when a fault is detected in the target device. The aforementioned fault recovery module is used to receive a recovery request and distribute the recovery request to the camera driver module, wherein the recovery request includes at least a primary recovery request and a first recovery request; The aforementioned camera driving module is used to drive the target device to execute the recovery measures corresponding to the received recovery request; wherein, the recovery measures include at least a primary recovery measure and a first recovery measure.

[0069] Please see Figure 5 This application also provides a fault recovery device for an in-vehicle camera system, the device comprising: The receiving configuration unit 100 is used to receive fault information reported by the vehicle-mounted camera system and read a predefined strategy configuration file; wherein, the strategy configuration file includes at least the primary recovery measures, decision configuration strategies, exit conditions and first recovery measures corresponding to the fault information; The first decision unit 200 is used to allocate a corresponding processing thread to the fault information, set the processing thread to the arbitration decision state, and generate and send a primary recovery request representing the primary recovery measures to the vehicle-mounted camera system. The observation creation unit 300 is used to set the processing thread to a suspended observation state and continuously monitor other fault information reported by the vehicle camera system if the decision configuration strategy is characterized as an observation strategy when the primary recovery request fails. The second decision unit 400 is used to set the processing thread to the arbitration decision state when the other fault information meets the exit condition, and to generate and send a first recovery request representing the first recovery measure to the vehicle camera system.

[0070] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0071] The fault recovery device for a vehicle-mounted camera system in this application embodiment is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, or other devices that can provide the above functions.

[0072] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application, such as... Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.

[0073] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0074] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0075] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0076] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0077] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0078] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0079] The systems, devices, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0080] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0081] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer devices. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0082] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and computer devices according to embodiments of this application. 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 program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0083] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0084] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0085] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0086] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0087] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0088] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A fault recovery method for a vehicle-mounted camera system, characterized in that, The method includes: Receive fault information reported by the vehicle-mounted camera system and read a predefined strategy configuration file; wherein, the strategy configuration file includes at least the primary recovery measures, decision configuration strategies, exit conditions and first recovery measures corresponding to the fault information; Assign a corresponding processing thread to the fault information, set the processing thread to the arbitration decision state, and generate and send a primary recovery request representing the primary recovery measures to the vehicle camera system; If the primary recovery request fails, and the decision configuration strategy is characterized as an observation strategy, the processing thread is set to a suspended observation state to continuously monitor other fault information reported by the vehicle camera system. When the other fault information meets the exit condition, the processing thread is set to the arbitration decision state, and a first recovery request representing the first recovery measure is generated and sent to the vehicle camera system.

2. The method according to claim 1, characterized in that, The strategy configuration file adopts a structured data format and is used to define fault response strategies corresponding to various fault conditions. The strategy configuration file is predetermined based on the hardware configuration of the vehicle-mounted camera system.

3. The method according to claim 1 or 2, characterized in that, The strategy configuration file further includes a second recovery measure, wherein the first recovery measure and the second recovery measure include one or more levels of recovery steps; the method further includes: If the primary recovery request fails, and the decision configuration strategy is characterized as a hierarchical strategy, the arbitration decision state of the processing thread is maintained, and a second recovery request representing the second recovery measure is generated and sent to the vehicle-mounted camera system.

4. The method according to claim 3, characterized in that, The method further includes: If either the first recovery request or the second recovery request fails, the vehicle-mounted camera system will be restarted.

5. The method according to claim 1, characterized in that, Assigning corresponding processing threads to the fault information includes: When the fault information is new fault information, a corresponding processing thread is created for the fault information; When the fault information is an existing fault information, the fault information is assigned to the processing thread corresponding to the existing fault information.

6. The method according to claim 1, characterized in that, The method further includes: If the other fault information does not meet the exit conditions, the processing thread is kept in a suspended observation state until the vehicle enters a non-use state, and a restart recovery request is generated and sent to the vehicle camera system in the non-use state.

7. The method according to claim 1 or 6, characterized in that, The exit condition is that the other fault information and the fault information come from the same signal acquisition branch, and the total amount of the other fault information and the fault information reaches a preset threshold; wherein, the signal acquisition branch includes an image signal processor, a deserializer, and multiple camera groups connected to the deserializer.

8. The method according to claim 1, characterized in that, The decision configuration strategy is determined based on the faulty object and its importance. The faulty object includes multiple camera groups, deserializers, and image signal processors.

9. A fault recovery device for a vehicle-mounted camera system, characterized in that, The device includes: A receiving configuration unit is used to receive fault information reported by the vehicle-mounted camera system and read a predefined strategy configuration file; wherein, the strategy configuration file includes at least the primary recovery measures, decision configuration strategies, exit conditions, and first recovery measures corresponding to the fault information; The first decision unit is used to allocate a corresponding processing thread to the fault information, set the processing thread to the arbitration decision state, and generate and send a primary recovery request representing the primary recovery measures to the vehicle camera system. An observation creation unit is used to set the processing thread to a suspended observation state and continuously monitor other fault information reported by the vehicle-mounted camera system if the decision configuration strategy is characterized as an observation strategy, in the event that the primary recovery request fails. The second decision unit is used to set the processing thread to the arbitration decision state when the other fault information meets the exit condition, and to generate and send a first recovery request representing the first recovery measure to the vehicle camera system.

10. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the fault recovery method of the vehicle-mounted camera system according to any one of claims 1 to 8.

Images