Vehicle controller, control system of vehicle, and vehicle

Abstract

The embodiment of the application provides a vehicle controller, a control system of a vehicle and the vehicle. The vehicle controller adopts a layered security architecture, including a function layer for performing security control according to sensor data and forming a double protection path, a function monitoring layer for verifying collected data and monitoring function control abnormalities, and a running monitoring layer for monitoring the running states of the function layer and the function monitoring layer and implementing reset recovery when an abnormality occurs. By constructing a processing link connecting data verification, function monitoring and running recovery, the fault detection and abnormality handling capability can be improved under the premise of less modification of the existing controller architecture, the upgrading cost and resource pressure are reduced, and the system reliability and vehicle running safety are improved.

Description

Technical Field

[0001] This application relates to the field of functional safety of vehicle controllers, and more particularly to a vehicle controller, a vehicle control system, and a vehicle. Background Technology

[0002] The vehicle controller collects vehicle operating data through sensors, processes it through software to generate control commands, and drives actuators to perform vehicle functions. It is the core electronic unit for realizing vehicle control. Failure of the vehicle controller can directly lead to serious safety hazards such as vehicle power interruption and brake failure. Therefore, functional safety is the core requirement for vehicle controller design.

[0003] Functional safety refers to ensuring, through the design and implementation of safety mechanisms, that the functions of electronic and electrical systems do not pose unreasonable risks when malfunctions occur.

[0004] However, many existing controllers were not designed with functional safety in mind. Upgrading them to high-safety-level products requires large-scale software and hardware changes to meet safety mechanisms, resulting in long controller update development cycles and high costs. Summary of the Invention

[0005] This application provides a vehicle controller, a vehicle control system, and a vehicle. It constructs a hierarchical and collaborative control and monitoring system around the vehicle safety control requirements, and improves functional safety capabilities, anomaly handling capabilities, and resource utilization efficiency while minimizing changes to the existing controller architecture.

[0006] In a first aspect, embodiments of this application provide a vehicle controller, including:

[0007] The functional layer includes: a first protection path and a second protection path. The first protection path is used to perform safety control on the vehicle based on the data collected by the vehicle's sensor components, and the second protection path is used to perform safety control on the vehicle's actuators based on the verified collected data.

[0008] The functional monitoring layer is used to verify the collected data and monitor whether the function of the first protection path is abnormal.

[0009] A monitoring layer is used to monitor whether the operation of the functional layer and the functional monitoring layer is abnormal, and to perform a reset process if an abnormality occurs.

[0010] Secondly, embodiments of this application provide a vehicle control system, the control system comprising: a sensor assembly, an actuator, and a vehicle controller as described in any of the first aspects.

[0011] Thirdly, embodiments of this application provide a vehicle that includes the control system described in the second aspect.

[0012] The vehicle controller, vehicle control system, and vehicle provided in this application embodiment, by setting protection paths for vehicle control and actuator control respectively in the functional layer, and combining the functional monitoring layer to verify the collected data and monitor the functional abnormalities of the first protection path, and the operation monitoring layer to monitor the operation abnormalities of the functional layer and the functional monitoring layer and perform reset processing in abnormal situations, can form a layered security protection mechanism covering data, functions, and operating status. In this way, the functional safety level, abnormal recovery capability, and overall reliability of the vehicle controller can be improved with less increase in system modification and resource burden. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0014] Figure 1 Schematic diagram of the vehicle controller provided in this application Figure 1 ;

[0015] Figure 2 Schematic diagram of the vehicle controller provided in this application Figure 2 ;

[0016] Figure 3 A schematic diagram of the protection flow for the second protection path of the vehicle controller functional layer provided in this application;

[0017] Figure 4 Schematic diagram of the vehicle controller provided in this application Figure 3 ;

[0018] Figure 5 A schematic diagram of the protection process for the vehicle controller provided in this application. Figure 1 ;

[0019] Figure 6 A schematic diagram of the reset process for the vehicle controller provided in this application;

[0020] Figure 7 A schematic diagram of the protection process for the vehicle controller provided in this application. Figure 2 .

[0021] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0022] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0023] Functional safety technology for vehicle controllers is widely used in new energy vehicles, intelligent driving vehicles, and various drive-by-wire systems. It is particularly suitable for scenarios where vehicle controllers, power domain controllers, and battery management systems need to continuously collect sensor data and output control commands to actuators. In such scenarios, the controller typically receives data from sensor components such as temperature, pressure, speed, voltage, and current. After processing by internal control logic, it sends control signals to actuators such as relays, motors, brake actuators, and cooling devices to achieve functions such as power output, energy management, thermal management, and safety protection.

[0024] Due to the complex operating environment of vehicles, controllers must not only meet real-time requirements, but also deal with problems such as sensor malfunctions, software malfunctions, and control link malfunctions. Therefore, their functional safety capabilities are directly related to the stability of vehicle operation and the safety of occupants.

[0025] In practical applications, many existing vehicle controllers are developed based on Quality Management (QM) architectures, which are characterized by high design complexity, tight hardware-software coupling, and a lack of integrated functional safety mechanisms. Upgrading such controllers to a higher ASIL level (e.g., ASILC / D) of the Automotive Safety Integrity Level (ASIL) typically requires a large-scale reconstruction of the existing hardware and software architecture. This includes replacing the microcontroller unit (MCU) chip with one that meets high safety standards, adding an external hardware watchdog timer, decoupling existing software components, and redeveloping safety function modules. Such modifications are not only time-consuming and costly but may also introduce new design flaws, increasing the product failure rate. Furthermore, some controllers need to implement safety functions with limited hardware resources (such as memory and computing power), further exacerbating the technical challenges.

[0026] In view of this, how to achieve functional safety upgrades while minimizing changes to existing controllers, and balancing resource consumption and system reliability, has become an urgent technical problem to be solved.

[0027] To address the aforementioned technical problems, this application proposes a vehicle controller. By layering a functional layer, a functional monitoring layer, and an operational monitoring layer, an independent software protection path can be added for safety-related functions without modifying the original software. Simultaneously, the functional monitoring layer is added to diagnose the rationality of the collected data and whether the processing function of the first protection path has failed. An operational environment monitoring layer is added to monitor software operational failures, thereby achieving safety control and anomaly handling.

[0028] Specifically, the first protection path of the functional layer is used for vehicle safety control based on data collected by the vehicle's sensor components, and the second protection path is used for vehicle actuator safety control based on verified data. The functional monitoring layer is used to verify the collected data and monitor whether the first protection path is abnormal. The operation monitoring layer is used to monitor whether the operation of the functional layer and the functional monitoring layer is abnormal, and to reset the functional layer and the functional monitoring layer in case of anomalies. Through the above layered architecture, a continuous processing link can be formed during vehicle operation, from data verification and functional anomaly identification to operational anomaly recovery. This improves the functional safety implementation capability and overall operational reliability of the vehicle controller without relying on large-scale reconstruction of the existing controller architecture.

[0029] Safety requirements for vehicle controllers can be divided into two main categories: QM (Quality Management) and ASIL (Automotive Safety Integrity Level). The QM architecture is suitable for functional scenarios where failure will not pose a vehicle safety risk, such as in-vehicle entertainment systems. The ASIL architecture, on the other hand, is a functional safety level system defined for electronic and electrical systems that pose safety risks. It is divided into four levels from lowest to highest: ASILA, ASILB, ASILC, and ASILD, with ASILD being the highest safety level.

[0030] A higher ASIL level security requirement can be decomposed into two or more redundant security requirements of lower ASIL levels and allocated to independent hardware or software for implementation. Mathematically, this can be expressed as follows: with QM=0, ASILA=1, ASILB=2, ASILC=3, and ASILD=4, the sum of the values ​​of each element after decomposition must equal the original level value.

[0031] The specific decomposition forms include: ASILA(1) = ASILA(A) + QM(A) (i.e., 1 + 0 = 1);

[0032] ASILB(2)=ASILA(B)+ASILA(B) (i.e. 1+1=2);

[0033] ASILB(2) = ASILB(B) + QM(B) (i.e., 2 + 0 = 2);

[0034] ASILC(3)=ASILB(C)+ASILA(C) (i.e. 2+1=3);

[0035] ASILC(3)=ASILC(C)+QM(C) (ie 3+0=3);

[0036] ASILD(4) = ASILB(D) + ASILB(D) (i.e., 2 + 2 = 4);

[0037] ASILD(4)=ASILC(D)+ASILA(D) (ie 3+1=4);

[0038] ASILD(4) = ASILD(D) + QM(D) (i.e., 4 + 0 = 4).

[0039] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0040] Figure 1 Schematic diagram of the vehicle controller provided in this application Figure 1 ,like Figure 1 As shown, the vehicle controller includes:

[0041] The functional layer includes a first protection path and a second protection path. The first protection path is used to perform safety control on the vehicle based on the data collected by the vehicle's sensor components, and the second protection path is used to perform safety control on the vehicle's actuators based on the verified collected data.

[0042] Understandably, the first protection path is responsible for vehicle safety control based on the raw data collected by the vehicle's sensor components. These sensor components typically include, but are not limited to, temperature and pressure sensors. The core logic of the first protection path is that even when sensor data is in an unverified state, basic safety control functions, such as emergency braking and speed limit control, can still be performed based on this data. This ensures that even within the extremely short time window during which data verification is not yet complete, the vehicle still possesses a minimum level of safety assurance and will not experience a control gap due to waiting for verification. In other words, the first protection path acts as a fast response channel, ensuring that the vehicle never loses its basic safety control capabilities at any time with low computational overhead and short decision latency.

[0043] The second protection path is responsible for the safety control of the vehicle's actuators based on verified collected data. Actuators include, but are not limited to, brake actuators and drive motor controllers. The difference between the second and first protection paths is that the data used in the second protection path is reliable data verified and confirmed by the functional monitoring layer. This means that the control commands of the second protection path have higher reliability and accuracy, and can execute more precise control actions. The second protection path is equivalent to a precision control channel, achieving safe management of actuators based on higher data quality. The coexistence of the two protection paths can form a complementary relationship between rapid but relatively coarse-grained control and precise and highly reliable control. Even if one path malfunctions, the other path can still maintain the safe operation of the vehicle to a certain extent.

[0044] The functional monitoring layer is used to verify the collected data and monitor whether the function of the first protection path is abnormal.

[0045] Understandably, the functional monitoring layer is tightly coupled with the functional layer. One of the responsibilities of the functional monitoring layer is to validate the acquired data. Specifically, the functional monitoring layer can perform a series of integrity and reasonableness checks on the raw data acquired from sensor components. These checks may include: range verification, consistency verification, and timestamp verification, etc.

[0046] Only data that passes all verification logic will be marked as verified and passed to the second protection path. Data that fails verification may be isolated or discarded, and may trigger corresponding fault diagnosis logic. This verification mechanism fundamentally prevents erroneous data from flowing into the execution control loop, avoiding dangerous control behaviors caused by sensor failure or signal interference.

[0047] Monitoring the functionality of the first protection path is another responsibility of the functional monitoring layer. Because the first protection path directly uses unverified raw sensor data for safety control, it inherently carries the risk of generating erroneous control commands due to abnormal input data. The functional monitoring layer needs to continuously monitor the output behavior of the first protection path to determine whether its control logic is functioning correctly. Monitoring can be achieved by detecting the rationality of the control commands generated by the first protection path. When the functional monitoring layer determines that the first protection path is malfunctioning, it can implement degradation strategies, such as cutting off control access to the first protection path, retaining control only for the second protection path, or triggering the vehicle to enter a safe stopping state.

[0048] The operation monitoring layer is used to monitor whether the operation of the functional layer and the functional monitoring layer is abnormal, and to perform a reset process if an abnormality occurs.

[0049] The runtime monitoring layer is the last line of defense in the entire three-tier architecture. For example, if the functional layer is responsible for execution, and the functional monitoring layer is responsible for checking whether the execution is done correctly, then the runtime monitoring layer is responsible for checking whether the execution-related devices and structures themselves are functioning properly.

[0050] The operation monitoring layer needs to comprehensively monitor the operational status of both the monitoring function layer and the function monitoring layer. Specific monitoring dimensions include, but are not limited to: processor operation status monitoring, task scheduling monitoring, and communication monitoring. The operation monitoring layer is typically implemented using hardware resources independent of the function layer and the function monitoring layer (e.g., a dedicated monitoring MCU or a dedicated hardware security module) to ensure that even if both the function layer and the function monitoring layer experience hardware or software failures, the operation monitoring layer can still function independently and execute the final security response.

[0051] After detecting an anomaly, the monitoring layer can reset the hardware structure of the functional layer and the monitoring layer. This reset process is essentially the execution of a final safety action. Reset typically involves using methods such as hardware watchdog reset, software reset, or power cycle reset to forcibly restore the processors of the functional layer and monitoring layer to a known initial state, allowing them to resume normal operation.

[0052] The vehicle controller provided in this application adopts a layered safety architecture, including a functional layer for performing safety control based on sensor data and forming a dual protection path, a functional monitoring layer for verifying the collected data and monitoring functional control anomalies, and an operational monitoring layer for monitoring the operating status of the functional layer and the functional monitoring layer and implementing reset and recovery in case of anomalies, forming a complete safety closed loop from execution to verification to meta-monitoring. The three layers have clear division of responsibilities and cross-supervision relationships, ensuring that anomalies in any layer can be detected by the layer above and appropriate safety measures can be taken. This improves the functional safety implementation capability and overall operational reliability of the vehicle controller without relying on large-scale reconstruction of the existing controller architecture.

[0053] In some embodiments, Figure 2 Schematic diagram of the vehicle controller provided in this application Figure 2 ,like Figure 2As shown, the first protection path is also the protection path in the original QM architecture. The specific execution process of the first protection path can be implemented through the input module 201, processing module 202, and output module 203. Specifically, the sensor component can transmit the relevant data it collects to the input module 201 of the first protection path. That is, the input module 201 is responsible for receiving data collected in real time from the sensor component, including current, voltage, temperature, and other data. At the same time, it can filter and convert the data, converting the data into a standard data format. Afterward, the input module 201 can send it to other protection paths, and also to the processing module 202 of the first protection path.

[0054] After receiving the data, the processing module 202 can perform real-time comparison and analysis of the data transmitted by the input module 201 based on preset protection thresholds and fault judgment logic. This processing module 202 can quickly identify and classify potential fault conditions such as overcurrent, overvoltage, undervoltage, overtemperature, and short circuit, and generate corresponding protection action commands based on fault level and priority strategies. After determining the triggering conditions for protection, the processing module 202 will complete the logical calculation within a specified response time to ensure the timeliness and accuracy of the protection action. Afterwards, the processing module 202 can send the generated command to the output module 203 of the first protection path.

[0055] The output module 203 can output control signals to the corresponding actuators according to the protection instructions generated by the processing module 202, and start the actuators to complete protection actions such as circuit breaker disconnection, relay disconnection, and power device shutdown, thereby realizing the safety control of the vehicle.

[0056] In one possible implementation, Figure 3 A schematic diagram of the protection flow for the second protection path of the vehicle controller functional layer provided in this application is shown below. Figure 3 As shown, the modules corresponding to the second protection path here are specifically the input monitoring module 204, the processing module 207, and the output module 208. The specific process of the second protection path for vehicle safety control includes:

[0057] S301. Obtain the first diagnostic result, the second diagnostic result, and the third diagnostic result from the functional monitoring layer.

[0058] The first diagnostic result indicates the verification result of the collected data, the second diagnostic result indicates whether the processing function of the first protection path is abnormal, and the third diagnostic result indicates whether the actuator correctly executes the safety control operation corresponding to the first protection path.

[0059] Understandable, such as Figure 2As shown, the functional monitoring layer of the vehicle controller may specifically include an input monitoring module 204, a processing monitoring module 205, and an output monitoring module 206.

[0060] The input monitoring module 204 can receive data from the input module 201 and perform verification processing on this data to ensure the reliability and validity of the data upon which subsequent safety decisions are based. The verification processing may specifically include: range verification, which determines whether the values ​​collected by the sensor are within a preset reasonable physical range; if the data exceeds this range, it is considered abnormal.

[0061] Change rate verification involves detecting the difference in data between adjacent sampling periods. If the data jump is too large, it is determined that the data may have a sudden abnormality.

[0062] Consistency verification is to compare the data of the same physical quantity collected by different sensors or multiple channels of the same sensor. If the deviation between the data of each channel exceeds the allowable tolerance, it is determined that there is an inconsistency in the data. At the same time, it can be determined that the sensor corresponding to the data with large deviation may be faulty.

[0063] Timeout verification checks whether the update cycle of sensor data is within a preset time window. If no new data is received after a specified time, it is determined that the data has a timeout anomaly, and the corresponding sensor may be faulty.

[0064] Signal quality verification involves evaluating the signal quality indicators of the sensor's output signal. If the signal quality falls below a preset standard, it is flagged. After the above verification process, the input monitoring module 204 can output data containing the verification status to the next module.

[0065] It should be noted that the above data verification processing method is only an example. This application does not limit the data verification processing method, and the verification processing can be carried out according to the needs of the collected data.

[0066] The processing monitoring module 205 can monitor and judge the processing function of the first protection path to determine whether the first protection path is in a normal working state when performing data processing and security decisions. The first protection path refers to a path that does not undergo complex logical operations or multi-layered approvals to meet the functional safety requirements for response timeliness. The existence of the processing monitoring module 205 can add an independent monitoring guarantee to this fast path, ensuring that it does not lose diagnosticability while pursuing response speed.

[0067] Specific monitoring methods may include the following: First, execution time monitoring, that is, monitoring whether the time consumed by the first protection path from receiving data to outputting control commands is within the preset time window. If the processing time exceeds the allowable range, it is determined that the path may have processing delay or deadlock anomaly.

[0068] Secondly, hardware device status monitoring, that is, detecting the working status of the hardware devices (such as processor core, storage unit, communication interface, etc.) called by the first protection path when performing data processing, and determining whether they are in normal operating condition;

[0069] Third, output result rationality monitoring involves logically judging the control commands or intermediate calculation results output by the first protection path. For example, it checks whether the output value is within the expected safety control range. If the output deviates significantly from normal logic, the processing function is deemed abnormal. After the above monitoring and judgment, the processing monitoring module 205 can obtain the second diagnostic result, which clearly indicates whether the first protection path is currently in normal working condition.

[0070] It should be noted that the monitoring method of the above processing function is only an example. This application does not limit the monitoring method, and it can be changed according to the specific data processing process of the first protection path.

[0071] The output monitoring module 206 can monitor the working status of the actuator to confirm whether the actuator has correctly and completely executed the safety control operation issued by the first protection path. As the final physical execution unit of the safety control command, the working status of the actuator is related to whether the vehicle can implement protective actions (such as emergency braking, high voltage disconnection, etc.) in a timely and accurate manner under dangerous conditions. Therefore, the monitoring of the actuator is an indispensable closed-loop verification link in the functional safety link.

[0072] Specific monitoring methods may include the following: First, execution feedback comparison monitoring, which compares the actual action feedback signal of the actuator (such as position sensor feedback, current feedback, pressure feedback, etc.) with the target control command issued by the first protection path. If the deviation between the two exceeds the preset tolerance, it is determined that the actuator has not executed the command correctly and the actuator may have a fault or abnormality.

[0073] Secondly, actuator self-diagnosis monitoring, that is, reading the actuator's own fault diagnosis code or health status flag bit to determine whether there are internal faults such as short circuit, open circuit, over-temperature, or stall in the actuator;

[0074] Third, action timing monitoring, which monitors whether the time consumed by the actuator from receiving the control command to completing the target action is within a preset range. If the response times out, it is determined that the actuator may have mechanical jamming or drive abnormality. After the above monitoring and judgment, the output monitoring module 206 can obtain the third diagnostic result, which clearly indicates whether the actuator has correctly completed the safety control operation.

[0075] It should be noted that the above-described monitoring methods for the actuator's execution function are merely examples. This application does not limit the specific monitoring methods, which can vary depending on the actuator.

[0076] S302. Determine whether the first diagnostic result indicates that the collected data has passed verification. If yes, proceed to step S303; otherwise, proceed to step S304.

[0077] S303. Based on the collected data, the second diagnostic results, and the third diagnostic results, the vehicle is subjected to safety control.

[0078] Understandably, the first, second, and third diagnostic results mentioned above will ultimately be sent to the processing module 207 of the second protection path. As the core decision-making unit of the second protection path, the processing module 207 is responsible for receiving and integrating the first diagnostic result from the input monitoring module 204, the second diagnostic result from the processing monitoring module 205, and the third diagnostic result from the output monitoring module 206, and implementing corresponding safety control strategies for the vehicle accordingly. This processing module 207 is the convergence point and decision-making exit of the second protection path, and its control logic design strictly adheres to the basic principles of fault-oriented safety in functional safety.

[0079] Specifically, when the data verification is successful, the processing module 207 indicates that the sensor-collected data has passed all verification stages and the data quality is reliable. At this point, the processing module 207 will perform comprehensive safety control on the vehicle based on the verified collected data, combined with the second and third diagnostic results. This may include the following methods:

[0080] Scenario 1: If both the second and third diagnostic results indicate that the vehicle is normal, the processing module 207 will directly execute the corresponding safety protection control strategy based on the vehicle status reflected by the collected data.

[0081] Scenario 2: If the second diagnostic result indicates that the first protection path is normal but the third diagnostic result indicates that the actuator is abnormal, the processing module 207 can trigger a degraded control strategy, such as enabling the backup actuator to perform, and at the same time sending an actuator fault alarm to the whole vehicle.

[0082] Scenario 3: If the second diagnostic result indicates an abnormality in the first protection path but the third diagnostic result indicates that the actuator is normal, the processing module 207 can determine that there is a processing logic fault. In this case, it can automatically compare and analyze the data in real time according to the preset protection threshold and fault judgment logic, and generate corresponding protection action commands, which are then sent to the output module 208 of the second protection path. The output module 208 can output control signals to the actuator according to the protection commands generated by the processing module 207, start the actuator to perform protection actions, and thus achieve safety control of the vehicle.

[0083] In scenario four, if both the second and third diagnostic results indicate an abnormality, the processing module 207 will process the same procedures as in scenarios two and three, generating a protection action command and sending it to the output module 208. Simultaneously, the output module 208 may, for example, activate the backup actuator to issue an actuator fault alarm to the vehicle, or trigger a safety response, such as performing a minimum-risk operation like emergency stop or disconnecting the high-voltage system, and issue a serious fault message to the vehicle.

[0084] S304. Handle the faults of the sensors corresponding to the collected data.

[0085] Understandably, when data verification fails, the processing module 207 indicates that the sensor-collected data has failed verification and is unusable or unreliable. In this case, the processing module 207 will not make safety control decisions based on this abnormal data to avoid false or missed triggering of safety protection due to erroneous data. Simultaneously, the processing module 207 can perform abnormal fault handling on the sensor that collected this abnormal data.

[0086] The specific handling of abnormal faults may include: marking the sensor as abnormal and no longer accepting the sensor's data in subsequent control cycles; reporting the sensor fault event and fault code to the vehicle diagnostic system; if the sensor is a critical safety sensor and there is a redundant configuration, automatically switching to the redundant sensor to continue data acquisition and maintaining the continuous execution of the current safety control strategy; if there is no redundant configuration, executing the corresponding safety control actions according to the preset degradation protection strategy to ensure that the vehicle can still maintain basic safe operation capabilities in the event of sensor failure.

[0087] The vehicle controller provided in this application obtains the first diagnostic result, the second diagnostic result, and the third diagnostic result through the second protection path. It can simultaneously grasp the reliability of the input data, the functional status of the first protection path, and the action status of the actuator before executing safety control, thereby forming a joint judgment on the three links of data, processing, and output.

[0088] If the first diagnostic result indicates that the collected data has passed verification, then safety control is implemented based on the collected data, the second diagnostic result, and the third diagnostic result. This allows the control decision to not only rely on the original collected information, but also to be corrected and confirmed by combining the detection information of the preceding protection path and the execution result, thereby reducing the risk of miscontrol due to sensor abnormalities, processing abnormalities, or execution deviations.

[0089] If the initial diagnostic result indicates that the collected data verification fails, fault handling measures such as fault marking and result masking are performed on the abnormal sensor to prevent abnormal data from continuing to enter subsequent control links. This allows sensor-level anomalies to be promptly cut off on the input side, preventing actuators from malfunctioning due to incorrect input, thereby reducing the impact of single-point sensor failures on the stability and functional safety of vehicle control. Therefore, without changing the original structure, adding an independent second protection path can form a fault-tolerant mechanism of path cross-verification and rapid fault switching, effectively reducing the failure risk of the vehicle controller.

[0090] In some embodiments, such as Figure 2 As shown, when the vehicle controller includes a main control unit, both the aforementioned first protection path and second protection path are located on the main control unit. That is, the vehicle controller has two protection paths for vehicle safety control, and both protection paths exist on the main control unit. This corresponds to the first protection path (QM) originally located on the main control unit. Figure 2 The path formed by the input module 201, processing module 202, and output module 203 in the middle) and the newly added second protection path (ASILx(z), that is Figure 2 The path formed by the input monitoring module 204, the processing module 207, and the output module 208. For example, this situation can achieve a security level similar to ASILB(2) = ASILB(B) + QM(B) (i.e., 2 + 0 = 2).

[0091] Understandably, by centrally deploying the first and second protection paths on the main control unit, the processor, memory, and interface resources in the existing controller can be directly reused. This allows the two protection paths to complete data processing and safety control coordination within the same control core, thereby reducing the workload of modifying new hardware units and cross-chip communication links. This is beneficial for implementing functional safety upgrades on the existing QM architecture, ensuring that the original control logic and interface relationships remain as stable as possible, thus reducing development, adaptation, and verification costs. At the same time, the collaborative operation of the two protection paths within the main control unit can shorten data transmission and control response paths, thus helping to improve control real-time performance and system integration, and balancing safety control capabilities with engineering implementation efficiency in resource-constrained vehicle controllers.

[0092] It should be noted that when the first protection path and the second protection path are both located on the main control unit, the functional monitoring layer can also diagnose and monitor the processing function of the second protection path and whether the actuator correctly executes the safety control operation corresponding to the second protection path, just like the first protection path. The diagnostic method of the functional monitoring layer for the second protection path is similar to the diagnostic method of the functional monitoring layer for the first protection path, and will not be repeated here.

[0093] In some embodiments, Figure 4 Schematic diagram of the vehicle controller provided in this application Figure 3 ,like Figure 4 As shown, the vehicle controller also includes a redundant control unit, and the functional layer also includes a third protection path, which is located on the redundant control unit. That is, the vehicle controller includes three protection paths for vehicle safety control, and the three protection paths exist on the main control unit and the redundant control unit.

[0094] This situation corresponds to the first protection path (QM) that originally existed in the main control unit, i.e. Figure 4 The path formed by the input module 201, processing module 202, and output module 203 in the main control unit and the newly added second protection path (ASILx(z), i.e. Figure 4 The path formed by the input monitoring module 204, processing module 207, and output module 208 in the redundant control unit, and the newly added third protection path (ASILy(z), i.e. Figure 4 The path formed by the input monitoring module 401, the processing module 402 and the output module 403 in the example can achieve a security level similar to ASILD(4) = ASILB(D) + ASILB(D) (i.e., 2 + 2 = 4).

[0095] The third protection path is used to verify the collected data, and after the collected data passes verification, it performs safety control on the vehicle's actuators based on the collected data.

[0096] Understandably, by adding redundant control units to the vehicle controller and arranging the third protection path on the redundant control units, an independent safety control channel can be formed outside the main control unit.

[0097] The third protection path includes an input monitoring module 401, a processing module 402, and an output module 403. The functions of each module are the same as those of the second protection path, and will not be repeated here. The third protection path first verifies the acquired data, and then, after successful verification, directly implements safety control on the actuator based on the acquired data. This ensures effective intervention on the actuator even when the main control link malfunctions, processing is inaccurate, or the output is unreliable. This allows the data verification and actuator control to be completed in a closed loop within the redundant path, thereby improving the timeliness of response after fault detection and the reliability of control. Therefore, it can improve the functional safety level with minimal changes to the existing controller architecture, while also considering resource utilization efficiency and the vehicle's continuous operating capability.

[0098] In one possible implementation, the third protection path is also used to: if the first diagnostic result indicates that the data acquisition verification has failed, then perform fault handling on the sensor corresponding to the data acquisition.

[0099] Understandably, when the third protection path is set on the redundant control unit, it can also identify the source of data that is out of bounds, abruptly changes, distorted, or has timing anomalies during the verification of collected data such as temperature, pressure, current, or speed. Once the first diagnostic result indicates that the collected data verification has failed, fault handling is performed on the corresponding sensor, such as fault marking, isolation and deactivation, reporting an alarm, or switching to a backup signal source, thereby preventing abnormal sensors from continuously inputting erroneous data to the subsequent control links. The third path can form a collaborative protection with the main control unit, improving the vehicle controller's fault handling capability and operational reliability under load conditions.

[0100] For example, the following specific process illustrates the vehicle safety control process when the vehicle controller has three protection paths. Figure 5 A schematic diagram of the protection process for the vehicle controller provided in this application. Figure 1 ,like Figure 5 As shown, the specific process includes:

[0101] S501, Acquire the data collected by the sensor components;

[0102] S502. Determine whether the vehicle has a fault based on the collected data. If yes, proceed to step S503; otherwise, proceed to step S501.

[0103] S503. Generate control commands and send them to the actuators;

[0104] S504. Determine whether the collected data has passed the verification. If yes, proceed to step S506. If no, proceed to step S505.

[0105] S505, Output sensor assembly malfunction;

[0106] S506. Determine whether the vehicle has a fault based on the collected data. If yes, proceed to step S507; otherwise, proceed to step S501.

[0107] S507. Generate control commands and send them to the actuators;

[0108] S508. Determine whether the collected data has passed the verification. If yes, proceed to step S510. If no, proceed to step S509.

[0109] S509, Output sensor assembly malfunction.

[0110] S510. Determine whether the vehicle has a fault based on the collected data. If yes, proceed to step S511; otherwise, proceed to step S501.

[0111] S511. Generate control commands and send them to the actuators.

[0112] As can be seen from the above process, the three protection paths operate in parallel, allowing for simultaneous vehicle safety control. This ensures that even if some protection paths fail, the remaining paths can still provide safety control. The specific implementation method in this example is the same as that in the previous embodiments, and will not be repeated here.

[0113] In some embodiments, when the vehicle controller includes both a main control unit and a redundant control unit, the first protection path may be located on the main control unit, and the second protection path may be located on the redundant control unit. That is, the vehicle controller has two protection paths for vehicle safety control, and the two protection paths exist respectively on the main control unit and the redundant control unit.

[0114] This situation corresponds to the first protection path (the protection path of the QM architecture) that originally existed in the main control unit. Figure 4 The protection path formed by the input module 201, processing module 202, and output module 203 in the redundant control unit, and the second protection path (ASILx(z), i.e.) added in the redundant control unit. Figure 4 The protection path is composed of the input monitoring module 401, the processing module 402, and the output module 403. For example, this situation can achieve a security level similar to ASILB(2) = ASILB(B) + QM(B) (i.e., 2 + 0 = 2).

[0115] Understandably, in this scenario, by deploying the first protection path on the main control unit and the second protection path on the redundant control unit, the safety control functions can be separated in terms of physical resources and computational links, preventing both protection paths from being affected simultaneously when a single control unit fails. Therefore, even if the main control unit experiences operational abnormalities, software lag, or abnormal processing results, the second protection path on the redundant control unit can still continue to perform safety control based on the corresponding data, giving the vehicle actuators independent backup control capabilities.

[0116] Furthermore, this distributed setup facilitates functional safety upgrades on the existing QM architecture, reduces the need for significant reconstruction of the original main control logic, and thus balances upgrade costs, resource utilization, and system reliability, while enhancing the vehicle's ability to operate safely under complex conditions.

[0117] In some embodiments, if the vehicle controller includes only the main control unit, the function monitoring layer and the operation monitoring layer of the vehicle controller are both located on the main control unit; the operation monitoring layer is specifically used to monitor whether the software operation of the function layer and the function monitoring layer is abnormal, and to perform a soft reset of the main control unit in the event of an abnormality.

[0118] Understandably, centralizing the functional monitoring layer and the operational monitoring layer on the main control unit allows for the deployment of monitoring and recovery functions on the existing controller hardware, thereby reducing modifications to the original architecture, interface relationships, and chip platform.

[0119] The operation monitoring layer, as the underlying security mechanism in the vehicle controller MCU architecture, operates independently of the functional layer and the functional monitoring layer. Its core responsibility is to continuously and fundamentally monitor and protect the operational status of the MCU platform and the aforementioned two software layers. This layer focuses on the health status of the control unit itself, namely, whether the hardware structure supporting software execution is intact, and whether the software execution process has encountered faults such as infinite loops, jump anomalies, or task timeouts. When an unrecoverable operational anomaly is detected, the operation monitoring layer will immediately trigger a soft reset operation, forcibly restoring the MCU to a known safe initial state, thereby avoiding control failure caused by software faults.

[0120] like Figure 4 As shown, the operation monitoring layer can be specifically divided into a software operation monitoring module 404 and a soft reset module 405.

[0121] The software operation monitoring module 404 is the main logical unit for anomaly detection in the operation monitoring layer. It can monitor software operation from two aspects: program flow monitoring and task timing monitoring. In terms of program flow monitoring, this module can insert monitoring points in the critical task code paths of the functional layer and the functional monitoring layer. An independently running monitoring task verifies the trigger signals of each monitoring point at a fixed period. If a monitoring point is not triggered normally within a specified time window, it is determined that the execution flow of the task has encountered a jump error, deadlock, or crash, and a reset request is immediately sent to the reset module.

[0122] In terms of task timing monitoring, this module can configure an independent execution time window for each monitored software task. It continuously measures the actual execution time of the task through a hardware timer or system tick counter. Once the task execution time exceeds the preset upper limit threshold or falls below the lower limit threshold (i.e., the task does not start within the specified period), it is determined that the task has timed out or frozen, and a reset process is triggered.

[0123] The operation of this module must be independent of the monitored functional layer and functional monitoring layer software. It is usually executed by a highest priority monitoring task or a dedicated monitoring processor to ensure that even if the monitored software suffers a serious failure, the software operation monitoring module 404 can still operate normally and accurately issue reset commands, ensuring that the MCU can autonomously recover to a safe state under any abnormal software conditions.

[0124] The soft reset module 405 is the actuator for performing fault recovery actions in the operation monitoring layer. It can be implemented based on an independent hardware reset controller within the MCU. The soft reset module 405 receives an abnormal trigger signal from the software operation monitoring module 404. After confirming that the abnormal condition is met, it sends a reset request to the MCU's reset domain, forcibly completing the initialization and clearing of the CPU register group, program counter, stack pointer, and peripheral control registers. It then redirects the program flow to the reset vector address to execute the startup code, thereby enabling the MCU to fully recover from the abnormal state.

[0125] The soft reset module 405 is designed to respond to task timeout or process disorder signals detected by the internal software operation monitoring module 404. It can also integrate a hardware-level reset channel to cover a full range of fault scenarios, including power failures. Furthermore, the soft reset module 405 can provide a reset reason register to record the trigger source and fault type for each reset, facilitating subsequent fault diagnosis and log analysis.

[0126] In one possible implementation, if the vehicle controller includes a main control unit and a redundant control unit, the operation monitoring layer may specifically include: a first operation monitoring path and a second operation monitoring path; wherein, the function monitoring layer and the first operation monitoring path are both located on the main control unit, and the second operation monitoring path is both located on the redundant control unit;

[0127] The first operation monitoring path is used to monitor whether the software operation of the functional layer and the functional monitoring layer is abnormal, and to perform a soft reset of the main control unit in the event of an abnormality.

[0128] Understandably, by setting the first operation monitoring path on the main control unit, the software execution status of the functional layer and the functional monitoring layer can be continuously monitored nearby. In the event of a freeze, runaway, or scheduling out of sync, a soft reset can be triggered in a timely manner, thereby restoring software operation at a lower cost and reducing the impact on the existing control architecture.

[0129] The specific process of monitoring and soft reset in the first operation monitoring path is the same as the monitoring and soft reset process of the operation monitoring layer when the vehicle controller only has the main control unit, and will not be repeated here.

[0130] The second operation monitoring path is used to monitor whether the software operation of the functional layer and the functional monitoring layer is abnormal, and to perform a hard reset of the main control unit in the event of an abnormality.

[0131] Understandably, the second operation monitoring path is set on the redundant control unit, which can independently determine the abnormality and perform hard reset when the main control unit's own monitoring fails, the software abnormality persists, or the soft reset cannot recover, thus enabling the system to have external supervision capabilities across control units.

[0132] Specifically, when the software operation of the main control unit malfunctions, it usually manifests as a failure of coordination between the functional layer and the functional monitoring layer. For example, the monitoring layer may fail to detect faults such as dead loops, task timeouts, or data out-of-bounds errors in the functional layer, causing the entire main control unit to fall into an unrecoverable software abnormal state. In this case, relying solely on the main control unit's own monitoring mechanism may not be able to achieve self-healing.

[0133] To address the extreme scenario where the main control unit's own monitoring mechanism fails, a second operational monitoring path, independent of the main control unit's software architecture, is configured in the redundant control unit. This monitoring path is physically isolated from the main control unit at the hardware level, possessing its own microprocessor, power supply circuit, and signal acquisition channel, thus ensuring that it is not affected by the main control unit's software crash. The second operational monitoring path can be connected to the main control unit via a dedicated hardware signal line to continuously collect the main control unit's heartbeat signal, watchdog feedback signal, and key function output signals, using independent logic to determine whether the main control unit is in a normal operating state.

[0134] When the second operation monitoring path detects software malfunctions in both the functional layer and the functional monitoring layer of the main control unit, and these malfunctions exceed the capabilities of the main control unit itself, the second operation monitoring path will trigger a hard reset mechanism. A hard reset refers to applying a reset signal directly to the main processor of the main control unit via hardware circuitry, forcing it to restart from its initial power-on state. Regardless of the current abnormal state of the main control unit's processor, the hard reset signal bypasses all software-level logic and physically forces the processor to return to its initial state, thereby maximizing the reliability of the main control unit's recovery from malfunctions.

[0135] In one possible implementation, the first running monitoring path and / or the second running monitoring path are specifically used to determine whether the software operation of the functional layer and / or the functional monitoring layer is abnormal by monitoring the dog feed signal of the software in the functional layer and / or the functional monitoring layer.

[0136] Understandably, for the first operational monitoring path, a clear dog-feeding signal path can be set up between the functional layer and the functional monitoring layer within the main control unit. The functional layer and the functional monitoring layer send dog-feeding signals to the operational monitoring layer at preset short intervals to indicate that the software flow of the functional layer is still executing normally according to the expected sequence.

[0137] If the runtime monitoring layer fails to receive a watchdog signal from the functional layer or the functional monitoring layer within the specified time window, it determines that the software operation has malfunctioned, which may manifest as a program infinite loop, task scheduling blockage, or communication link interruption. In this case, the runtime monitoring layer can call the soft reset module 405 to perform a reset operation. By sending a software reset command to the MCU core, the program counter and stack pointer in the main control unit are restored to their initial state, thereby enabling the program to be reloaded and run.

[0138] Since the entire soft reset process does not involve cutting off and re-energizing the hardware power supply, the random access data (such as fault code cache, running status flags and other key non-volatile information) on which the main control unit depends are preserved. The system recovery speed is extremely fast, usually completed in milliseconds, and will not cause significant impact on the continuous operation of the vehicle control system.

[0139] For the second operational monitoring path, a more fundamental and thorough hardware-level reset strategy is employed. For example... Figure 4 As shown, the second operation monitoring path may specifically include a hard reset module 406 and a watchdog module 407. The watchdog module 407 is independent of the main control unit's software architecture and is directly bound to the hardware circuit of the redundant control unit. Its working principle is also based on the periodic detection of the feed signal: the main control unit must send a feed signal to the watchdog module 407 within a fixed time window. If the feed signal does not arrive within the time limit, the watchdog module 407 will determine that the main control unit's software operation is in an unrecoverable abnormal state.

[0140] In this scenario, the second running monitoring path can trigger a hard reset. The hard reset module 406 can directly control the hardware reset pin or the enable signal of the power management chip to execute a complete power-on reset sequence on the main control unit. That is, the main control unit will undergo a complete startup process, all data in volatile memory will be completely erased, and the system will restart from the initial power-on state. Although hard reset has a longer recovery time (typically in the tens to hundreds of milliseconds range), its thoroughness and reliability are far superior to soft reset, and it can effectively clear unrecoverable states caused by underlying hardware anomalies or deep software faults.

[0141] Figure 6 This is a schematic diagram of the reset process for the vehicle controller provided in this application, as shown below. Figure 6As shown, the specific steps for the main control unit's operation monitoring layer to perform a soft reset on the main control unit are as follows:

[0142] S601, Obtain the dog-feeding signal during software operation;

[0143] S602. Determine whether the software is running abnormally based on the dog-feeding signal. If yes, proceed to step S603; otherwise, proceed to step S601.

[0144] S603, Perform a soft reset operation.

[0145] The watchdog module 407 of the redundant control unit can also acquire the watchdog signal during software operation in the main control unit, and determine whether the software operation is abnormal based on the watchdog signal. If an abnormality occurs, a hard reset operation is performed on the main control unit. The specific implementation process of the above-mentioned soft reset operation and hard reset operation has been described in detail in the foregoing embodiments, and will not be repeated here.

[0146] The first operational monitoring path, located in the main control unit, and the second operational monitoring path, located in the redundant control unit, can reset the main control unit of the vehicle controller in parallel. Specifically, the first operational monitoring path addresses high-frequency, low-severity software anomalies, aiming to quickly recover without interrupting vehicle control continuity, ensuring driving experience and system availability. The second operational monitoring path addresses low-frequency, high-severity systemic failures, aiming to ensure that the system can return to a known safe initial state even in the worst-case scenario, guaranteeing the achievement of functional safety objectives. The two paths are independent of each other in terms of physical circuitry and logical architecture. Even if the soft reset of the first path fails to restore the normal operation of the main control unit, the second path can still intervene as a last resort safety measure.

[0147] The combination of the first and second operation monitoring paths can form a hierarchical recovery mechanism that combines soft and hard resets. This not only improves the coverage of anomaly detection and the reliability of fault recovery, but also takes into account the efficiency of vehicle control continuity and functional safety upgrades.

[0148] The following example uses temperature data as an illustration to explain the safety control process of the vehicle controller described above. Figure 7 A schematic diagram of the protection process for the vehicle controller provided in this application. Figure 2 ,like Figure 7 As shown, assuming the vehicle controller includes three protection paths, where the first and second protection paths reside in the main control unit, and the third protection path resides in the redundant control path, the specific safety control flow of the three protection paths of the vehicle controller includes:

[0149] S701, Acquire temperature data collected by the temperature sensor;

[0150] S702. Determine whether the temperature data is greater than the preset threshold. If yes, proceed to step S703; otherwise, proceed to step S701.

[0151] S703. Generate control commands and send them to the actuators;

[0152] S704. Determine whether the temperature data has passed the verification. If yes, proceed to step S706. If no, proceed to step S705.

[0153] S705, Output temperature sensor malfunction;

[0154] S706. Determine whether the temperature data is greater than the preset threshold. If yes, proceed to step S707; otherwise, proceed to step S701.

[0155] S707. Generate control commands and send them to the actuators;

[0156] S708. Determine whether the temperature data has passed the verification. If yes, proceed to step S710. If no, proceed to step S709.

[0157] S709, Output temperature sensor malfunction.

[0158] S710. Determine whether the temperature data is greater than the preset threshold. If yes, proceed to step S711; otherwise, proceed to step S701.

[0159] S711. Generate control commands and send them to the actuators.

[0160] Understandably, the above process is the control process in which the three protection paths each perform temperature judgment. Steps S702 to S703 constitute the execution flow of the first protection path, steps S704 to S707 constitute the execution flow of the second protection path, and steps S708 to S711 constitute the execution flow of the third protection path. While the execution content of the second and third protection paths is the same, in actual safety control, they are executed by different modules within different control units.

[0161] Specifically, for the first protection path, after receiving temperature data, the input module can send it to the processing module. The processing module, according to the preset temperature judgment logic, determines whether the temperature exceeds a preset threshold. If not, it continues to receive temperature data for further judgment. If so, it determines that there is a risk of overheating and can input a cooling command to the output module. The output module then sends the cooling command to actuators such as fans, cooling water pumps, radiator fans, and motors, so that the actuators can perform cooling or shutdown protection.

[0162] For the second protection path, after receiving temperature data, the input monitoring module 204 first verifies the data to determine its reasonableness. If the verification fails, the input monitoring module 204 considers the temperature sensor abnormal and outputs an abnormality message to the vehicle controller. If the verification passes, the verified temperature data is sent to the processing module. The processing module uses preset temperature judgment logic to determine if the temperature exceeds a preset threshold. If not, it continues to receive temperature data for further judgment. If the temperature exceeds the threshold, a risk of overheating is identified, and a cooling command is input to the output module. The output module then sends the cooling command to actuators such as the fan, cooling water pump, radiator fan, and motor, enabling the actuators to perform cooling or shutdown protection.

[0163] For the third protection path, after receiving temperature data, the input monitoring module 204 first verifies the data to determine its reasonableness. If the verification fails, the input monitoring module 204 considers the temperature sensor abnormal and outputs an abnormality message to the vehicle controller. If the verification passes, the verified temperature data is sent to the processing module. The processing module uses preset temperature judgment logic to determine if the temperature exceeds a preset threshold. If not, it continues to receive temperature data for further judgment. If the temperature exceeds the threshold, a risk of overheating is identified, and a cooling command is input to the output module. The output module then sends the cooling command to actuators such as the fan, cooling water pump, radiator fan, and motor, enabling the actuators to perform cooling or shutdown protection.

[0164] This application also provides a vehicle control system, which includes: a sensor assembly, an actuator, and the aforementioned vehicle controller.

[0165] Specifically, the sensor components can continuously collect operating information such as temperature, pressure, speed, voltage and current and input it into the vehicle controller. The vehicle controller processes the collected data based on the existing control architecture and outputs control commands to the actuators. The actuators then perform power output, thermal management, braking control or safety protection actions accordingly.

[0166] This application also includes a vehicle that incorporates the aforementioned control system. By integrating this control system, the vehicle can achieve layered safety control within onboard control units such as the vehicle controller, power domain controller, or battery management system.

[0167] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0168] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A vehicle controller, characterized in that, include: The functional layer includes: a first protection path and a second protection path. The first protection path is used to perform safety control on the vehicle based on the data collected by the vehicle's sensor components, and the second protection path is used to perform safety control on the vehicle's actuators based on the verified collected data. The functional monitoring layer is used to verify the collected data and monitor whether the function of the first protection path is abnormal. The operation monitoring layer is used to monitor whether the operation of the functional layer and the functional monitoring layer is abnormal, and to perform a reset process if an abnormality occurs.

2. The vehicle controller according to claim 1, characterized in that, The second protection path is specifically used for: The first diagnostic result, the second diagnostic result, and the third diagnostic result of the functional monitoring layer are obtained; wherein, the first diagnostic result is used to indicate the verification result of the collected data, the second diagnostic result is used to indicate whether the processing function of the first protection path is abnormal, and the third diagnostic result is used to indicate whether the actuator correctly executes the security control operation corresponding to the first protection path; If the first diagnostic result indicates that the collected data has passed verification, then the vehicle is subject to safety control based on the collected data, the second diagnostic result, and the third diagnostic result.

3. The vehicle controller according to claim 2, characterized in that, The second protection path is also used for: If the first diagnostic result indicates that the verification of the collected data has failed, then the sensor corresponding to the collected data shall be fault-handled.

4. The vehicle controller according to claim 1, characterized in that, The vehicle controller includes a main control unit, and both the first protection path and the second protection path are located on the main control unit.

5. The vehicle controller according to claim 4, characterized in that, The vehicle controller also includes: a redundant control unit; The functional layer further includes a third protection path; the third protection path is located on the redundant control unit and is used to verify the collected data, and after the collected data passes the verification, to perform safety control on the actuators of the vehicle based on the collected data.

6. The vehicle controller according to claim 5, characterized in that, The third protection path is also used for: If the collected data fails verification, the sensor corresponding to the collected data will be troubleshooted.

7. The vehicle controller according to claim 1, characterized in that, The vehicle controller includes: a main control unit and a redundant control unit; The first protection path is located on the main control unit, and the second protection path is located on the redundant control unit.

8. The vehicle controller according to claim 4, characterized in that, Both the functional monitoring layer and the operational monitoring layer are located on the main control unit; The operation monitoring layer is specifically used to monitor whether the software operation of the functional layer and the functional monitoring layer is abnormal, and to perform a soft reset of the main control unit in the event of an abnormality.

9. The vehicle controller according to any one of claims 5-7, characterized in that, The operation monitoring layer includes a first operation monitoring path and a second operation monitoring path; wherein, the function monitoring layer and the first operation monitoring path are both located on the main control unit, and the second operation monitoring path is both located on the redundant control unit; The first operation monitoring path is used to monitor whether the software operation of the functional layer and the functional monitoring layer is abnormal, and to perform a soft reset of the main control unit in the event of an abnormality. The second operation monitoring path is used to monitor whether the software operation of the functional layer and the functional monitoring layer is abnormal, and to perform a hard reset of the main control unit in the event of an abnormality.

10. The vehicle controller according to claim 9, characterized in that, The first operation monitoring path and / or the second operation monitoring path are specifically used to determine whether the operation of the software in the functional layer and / or the functional monitoring layer is abnormal by monitoring the dog feed signal of the software in the functional layer and / or the functional monitoring layer.

11. A vehicle control system, characterized in that, The control system includes: a sensor assembly, an actuator, and a vehicle controller as described in any one of claims 1-10.

12. A vehicle, characterized in that, The vehicle includes the control system as described in claim 11.

Images