Method and system for processing exception of domain controller and domain controller

Abstract

The invention provides a domain controller exception handling method and system and a storage medium. The method comprises the steps that the working state of an SOC system is monitored based on a preset time period; wherein the working state at least comprises a GPIO state and SPI data; whether SPI communication abnormity exists or not is judged based on the SPI data, and if yes, a function abnormity type is obtained based on a preset time threshold level and the SPI data; otherwise, acquiring a function abnormality type based on the preset time threshold level and the current GPIO state; and executing corresponding exception handling work based on the function exception type. According to the method, the working state of the SOC system in the domain controller of the intelligent driver and the intelligent cabin is detected, and the abnormity is divided into different functional abnormity types based on different time threshold levels when the abnormity exists, so that the targeted abnormity processing is carried out, the requirements of the intelligent cabin and the intelligent driver on fault-tolerant time can be compatible, and the fault-tolerant efficiency of the intelligent driver and the intelligent cabin can be improved. And the safety and robustness of the system are ensured.

Description

Technical Field

[0001] The present application belongs to the field of automotive electronics technology, and specifically relates to a domain controller exception handling method, system, and domain controller. Background Art

[0002] With the rapid development of intelligent and highly integrated vehicles, the integration of smart cockpits and intelligent driving systems has become a key industry trend. However, traditionally, smart cockpits and intelligent driving systems are separate systems. Traditional cockpit controllers primarily perform multimedia entertainment and instrument display functions. Malfunctions in these functions only result in a poor user experience and do not pose safety risks. Instrument display functions, on the other hand, require real-time display of essential vehicle status information. Errors in many of these signals can pose safety risks, such as the automated driving takeover request signal. If the takeover request is not displayed in a timely manner or not at all, the driver may miss the opportunity to take over, potentially leading to an accident. However, the real-time display requirements for these signals are not stringent. For example, a three-second delay does not immediately pose a safety risk to the driver. Therefore, cockpit controllers typically have an error tolerance measured in seconds. For example, a fault is considered an error only if it persists for more than five seconds.

[0003] In intelligent driving systems, the domain controller directly controls vehicle acceleration, deceleration, and steering, so fault tolerance is very strict, typically within 300ms. If the same fault tolerance as for the smart cockpit is used, and a fault (such as a SOC anomaly) occurs while driving at 100 km / h on the highway, and the MCU detects an error after 10 seconds, the vehicle will have already traveled 277 meters. If there is a curve or obstacle ahead, an accident could result.

[0004] Smart cockpit and intelligent driving systems typically utilize a domain controller architecture, comprised of an MCU and a SOC. The SOC handles complex functions such as multimedia, screen display, and autonomous driving algorithms, while the MCU is the master control chip, responsible for managing and monitoring the SOC's status and overall controller operation scheduling. The MCU's real-time monitoring of the SOC and the duration of abnormalities can detect SOC anomalies in real time. However, due to the different tolerance times for abnormalities between traditional cockpit functions and intelligent driving functions, adopting the fault tolerance time parameters of traditional cockpits would not meet the requirements of intelligent driving functions, seriously impacting the safety of vehicle users. Adopting the fault tolerance time parameters of intelligent driving would result in an overly sensitive system with low robustness, resulting in a very poor user experience and leading to user complaints. Summary of the Invention

[0005] In order to solve the above technical problems, the present application proposes a domain controller exception handling method, system and domain controller that are compatible with intelligent driving functions and intelligent cockpit functions.

[0006] Specifically, this application proposes a domain controller exception handling method, including: The operating status of the SOC system is monitored based on a preset time period; wherein the operating status includes at least GPIO status and SPI data.

[0007] Based on the SPI data, it is determined whether there is an SPI communication abnormality. If so, the function abnormality type is obtained based on the preset time threshold level and the SPI data; otherwise, the function abnormality type is obtained based on the preset time threshold level and the current GPIO state.

[0008] And, executing corresponding exception handling work based on the functional exception type.

[0009] In the above technical solution, by real-time monitoring of the GPIO status and SPI data of the SOC system during a preset time period, the abnormal status of the SOC system can be detected in time, avoiding missed abnormalities. By dividing the preset time threshold levels, the domain controller's exception handling can be compatible with the different requirements for error tolerance of intelligent driving and intelligent cockpits, effectively improving the safety and robustness of the system. The monitoring of the SOC system mainly through the MCU in the domain controller reduces the need for complex hardware redundancy design, reducing system complexity and cost. By executing the corresponding exception handling work through the obtained functional abnormality classification, functional abnormalities can be handled in a targeted manner, ensuring the accuracy of exception handling and improving the reliability of the system.

[0010] Furthermore, the GPIO state includes at least a level state and a state duration; and the SPI data includes a message time, message data, and message verification information.

[0011] Exception monitoring through both GPIO status and SPI data avoids the failure of traditional GPIO status monitoring to promptly address errors, thereby improving the comprehensiveness and reliability of exception monitoring. The SPI data includes message ID, message time, message data, and message verification information. Specific error information can be reported through SPI data, facilitating problem analysis and troubleshooting, and enabling comprehensive assessment of the integrity and correctness of SPI communications. Using both GPIO status and SPI data enables the domain controller to promptly detect and handle exceptions, improving the system's efficiency in responding to exceptions. Reporting message data within the SPI data reduces communication load and CPU operating load, enabling timely error reporting and processing.

[0012] Further, judging whether there is an SPI communication abnormality based on the SPI data includes: The message data is verified based on the message verification information and the message time. If the message verification information fails to be verified and / or the message time does not conform to a preset time rule, the message data verification fails and an SPI communication anomaly occurs.

[0013] If the message verification information is successfully verified and the message time conforms to the preset time rule, the message data verification is successful and there is no abnormality in the SPI communication.

[0014] The dual verification of message verification information and message time ensures the integrity and accuracy of SPI communication data. Message verification information is used to detect whether message data has been tampered with or damaged during transmission, while message time is used to determine whether message data arrives within the specified time. This avoids communication delays and improves the reliability of SPI communication. Real-time verification of message data allows for rapid detection of anomalies in SPI communication, improving system reliability and robustness.

[0015] Furthermore, the preset time threshold level includes at least a first time threshold, a second time threshold, and a third time threshold; and the abnormality type of the function acquired based on the preset time threshold level and the SPI data includes: The message time is compared with the preset time threshold level. If the message time is within the first time threshold, the functional abnormality type is determined to be intelligent driving abnormality.

[0016] If the message time is within the second time threshold, the functional abnormality type is determined to be a smart cockpit abnormality.

[0017] If the message time is within the third time threshold, it is determined that the functional abnormality type is an SOC system abnormality.

[0018] By comparing preset time threshold levels with message times, the system can accurately distinguish between intelligent driving, intelligent cockpit, and SOC system anomalies, achieving precise classification of functional anomaly types. This classification of functional anomaly types ensures that the domain controller's anomaly handling is compatible with the different fault tolerance requirements of intelligent driving and intelligent cockpit functions, ensuring system safety and robustness. This clear classification of functional anomalies simplifies fault diagnosis and maintenance.

[0019] Furthermore, before obtaining the function abnormality type based on the preset time threshold level and the current GPIO state, the method further includes: The level state is compared with the level state based on a preset level state rule to obtain a level state type; the level state type includes at least a first level state and a second level state.

[0020] By comparing the preset level status rules with the level status, the level status can be accurately classified. This level status classification can flexibly respond to different types of level anomalies, enhance fault tolerance, and detect the level status so that GPIO status anomalies can be promptly detected, improving the real-time performance of GPIO status monitoring.

[0021] Furthermore, the obtaining of the function abnormality type based on the preset time threshold level and the current GPIO state includes: When the level state type is the first level state, a comparison is performed between the state duration and the preset time threshold level. If the state duration is within the first time threshold, the functional abnormality type is determined to be an intelligent driving abnormality.

[0022] If the state duration is within a second time threshold, it is determined that the functional abnormality type is a smart cockpit abnormality.

[0023] By comparing the duration of each level state type with preset time thresholds, the system can accurately distinguish between functional anomalies in intelligent driving and intelligent cockpit. By using these tiered time thresholds, the system can accommodate the differing error tolerance requirements of intelligent driving and intelligent cockpit. Judgment based on the first time threshold ensures the high real-time performance and rapid response of intelligent driving functions, ensuring their safety. Judgment based on the second time threshold avoids oversensitivity due to real-time requirements, improving the user experience.

[0024] Furthermore, corresponding exception handling tasks are performed based on the functional abnormality type, including: If the functional abnormality type is intelligent driving abnormality, deceleration processing is performed and a takeover request signal is sent to the user.

[0025] If the functional abnormality type is a smart cockpit abnormality, the abnormality information will be displayed on the display screen.

[0026] If the functional abnormality type is an SOC system abnormality, a reset processing operation is performed on the SOC system.

[0027] When the functional anomaly is an intelligent driving anomaly, deceleration processing can effectively avoid vehicle loss of control due to the anomaly. By sending a takeover request signal to the user to prompt the driver to take over in time, accidents can be effectively prevented, thereby improving the safety of the driving process. When the functional anomaly is an intelligent cockpit anomaly, the display screen displays abnormal information to prompt the user of the abnormal situation, avoiding confusion caused by the functional anomaly and improving the user experience. When the SOC system is abnormal, performing a reset processing operation can ensure that the system can quickly resume stable operation. Different processing measures are taken according to the type of functional anomaly, realizing hierarchical abnormality processing and improving the flexibility and efficiency of the system.

[0028] Furthermore, executing corresponding exception handling work based on the functional abnormality type also includes: When the level state type is the second level state, abnormal information is reported and a reset processing operation is performed on the SOC system.

[0029] The second level status primarily indicates a serious anomaly or fault. By reporting the anomaly and executing a reset, potential safety hazards can be promptly eliminated, improving system security. The reset operation allows the system to quickly resume operation after a verified anomaly, enhancing the system's fault tolerance. Promptly handling anomalies ensures system reliability and stability.

[0030] Based on the same inventive concept, the present application also proposes a system for handling domain controller exceptions, the system comprising: The status monitoring module is used to monitor the working status of the SOC system based on a preset time period; wherein the working status at least includes GPIO status and SPI data.

[0031] The type acquisition module is used to determine whether there is an SPI communication abnormality based on the SPI data. If so, the function abnormality type is acquired based on the preset time threshold level and the SPI data; otherwise, the function abnormality type is acquired based on the preset time threshold level and the current GPIO state.

[0032] And, an exception handling module is used to perform corresponding exception handling tasks based on the functional exception type.

[0033] Based on the same inventive concept, the present application also proposes a domain controller, which is composed of an MCU and a SOC. The MCU communicates with the SOC via SPI and GPIO, and the domain controller exception handling method is executed based on the SPI communication and GPIO communication.

[0034] Compared with the prior art, this application has at least the following beneficial effects: In this application, the GPIO status and SPI data of the SOC system are monitored in real time during a preset time period, so that the abnormal status of the SOC system can be monitored in time, avoiding missed abnormalities. By dividing the preset time threshold levels, the exception handling of the domain controller can be compatible with the different requirements of intelligent driving and intelligent cockpit for error tolerance, effectively improving the safety and robustness of the system. By dividing the types of functional abnormalities, the real-time nature of the intelligent driving function can be met, ensuring that the intelligent driving function can be handled in a timely manner when it is abnormal. The excessive sensitivity of the abnormal time parameters of the intelligent cockpit function is avoided, and the user experience is improved. The monitoring of the SOC system by the MCU in the domain controller reduces the need for complex hardware redundant design, and reduces the complexity and cost of the system. By executing the corresponding exception handling work through the obtained functional abnormality classification, the functional abnormality can be handled in a targeted manner, ensuring the accuracy of the exception handling and improving the reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a flowchart of a method for handling domain controller exceptions shown in an embodiment of the present application.

[0036] Figure 2 This is a schematic diagram of a domain controller exception handling system shown in an embodiment of the present application.

[0037] Figure 3 This is a schematic diagram of the domain controller structure shown in an embodiment of the present application. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0039] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0040] Example 1: Please refer to Figure 1 The domain controller exception handling method mainly includes steps S1 to S3.

[0041] Step S1 includes monitoring the operating status of the SOC system based on a preset time period; the operating status includes at least GPIO status and SPI data. Common domain controllers are composed of an MCU and a SOC. The SOC primarily handles complex functions such as multimedia, screen display, and autonomous driving. The MCU is the main control chip, responsible for managing and monitoring the SOC status and overall domain controller operation scheduling. In other words, the MCU can monitor the operating status of the SOC system in real time. The preset time period can be set based on actual conditions. For example, a 10ms time period can be set, and the MCU can monitor the operating status of the SOC system at that 10ms time period.

[0042] Step S2 includes: determining whether an SPI communication anomaly exists based on the SPI data; if so, obtaining the type of functional anomaly based on a preset time threshold level and the SPI data; otherwise, obtaining the type of functional anomaly based on the preset time threshold level and the current GPIO state. The SPI data may include at least a message ID, a message time, message data, and message verification information. The message verification information and message time may be used to determine whether an SPI communication anomaly exists. The message verification information may be a CRC (Cyclic Redundancy Check), and the message data is verified using the CRC. If the CRC verification fails and / or the message time does not change according to a regular pattern, the SPI communication is determined to have an anomaly. If the CRC verification succeeds and the message time changes according to a regular pattern, the SPI communication is determined to have no anomaly.

[0043] The preset time threshold levels may include at least a first time threshold, a second time threshold, and a third time threshold. Those skilled in the art may set the time threshold levels based on actual needs. For example, the first time threshold may be set to 300ms, the second time threshold may be set to 5s, and the third time threshold may be set to 20s. When the abnormality duration exceeds the first time threshold, the functional abnormality is determined to be an intelligent driving function abnormality; when the abnormality duration is within the second time threshold, the functional abnormality is determined to be an intelligent cockpit function abnormality; and when the abnormality duration is within the third time threshold, the functional abnormality is determined to be an SOC system abnormality.

[0044] And step S3 includes: performing corresponding abnormality handling work based on the functional abnormality type. The functional abnormality type may include at least intelligent driving function abnormality, intelligent cockpit function abnormality and SOC system abnormality. The abnormality handling work can mainly be to perform deceleration processing and send a takeover request signal to the user when the intelligent driving function is abnormal. When the intelligent cockpit function is abnormal, an alarm message is displayed on the display screen. When the SOC system is abnormal, the SOC is reset.

[0045] For example, the MCU monitors the SOC system's operating status in real time at a 10ms time interval. Based on the SPI data from the SOC communication, it determines whether there is an SPI communication anomaly. If an anomaly is present, the system determines the type of functional anomaly based on a preset first time threshold of 300ms, a second time threshold of 5s, and a third time threshold of 20s, along with the SPI data. If the message time in the SPI data is within 300ms, the anomaly is determined to be an intelligent driving function anomaly; if the message time is within 5s, the anomaly is determined to be an intelligent cockpit function anomaly; and if the message time is within 20s, the anomaly is determined to be an SOC system anomaly. If no anomaly is present, the anomaly type is determined based on the preset time threshold level and the current GPIO status. Based on the anomaly type, the system performs corresponding anomaly handling. For example, if the intelligent driving function is anomaly, the system performs deceleration and sends a takeover request signal to the user. If the intelligent cockpit function is anomaly, an alarm is displayed on the display screen. If the SOC system is anomaly, the system is reset.

[0046] In some embodiments, the GPIO state includes at least a level state and a state duration; and the SPI data includes message time, message data, and message verification information.

[0047] The message ID is primarily used to indicate the message type. For example, a message ID of 0x01 indicates a heartbeat packet, and 0x05 indicates an error packet. The message time is used to record the time of each frame of message data. The message data is used to transmit information such as SOC faults or internal operating status. The message verification information is used to verify the data in each frame of message is correct. For example, the message verification information can be a CRC.

[0048] Optionally, determining whether there is an SPI communication abnormality based on the SPI data includes: Verifying the message data based on the message verification information and the message time; if the message verification information fails to be verified and / or the message time does not conform to a preset time rule, the message data verification fails and an SPI communication anomaly occurs; If the message verification information is successfully verified and the message time conforms to the preset time rule, the message data verification is successful and there is no abnormality in the SPI communication.

[0049] The message verification information may be primarily a CRC checksum, and the message time may be primarily a timestamp. Verification is performed using the CRC checksum and timestamp. If the CRC checksum fails or the timestamp times out, the SPI communication is determined to be abnormal. If the CRC checksum succeeds and the timestamp conforms to a preset time pattern, the SPI communication is determined to be normal.

[0050] Optionally, the preset time threshold level includes at least a first time threshold, a second time threshold, and a third time threshold; and acquiring the abnormality type of the function based on the preset time threshold level and the SPI data includes: The message time is compared with the preset time threshold level. If the message time is within the first time threshold, the functional abnormality type is determined to be intelligent driving abnormality.

[0051] If the message time is within the second time threshold, the functional abnormality type is determined to be a smart cockpit abnormality.

[0052] If the message time is within the third time threshold, it is determined that the functional abnormality type is an SOC system abnormality.

[0053] Those skilled in the art can set the first time threshold, the second time threshold and the third time threshold according to actual conditions. For example, the first time threshold can be set to 300ms, the second time threshold can be set to 5s, and the third time threshold can be set to 20s. When the message time is within 300ms, the functional abnormality type is determined to be an intelligent driving abnormality; when the message time is within 5s, the functional abnormality type is determined to be an intelligent cockpit abnormality; when the message time is within 20s, the functional abnormality type is determined to be an SOC system abnormality.

[0054] Optionally, before obtaining the function abnormality type based on the preset time threshold level and the current GPIO state, the method further includes: The level state is compared with the level state based on a preset level state rule to obtain a level state type; the level state type includes at least a first level state and a second level state.

[0055] The GPIO level states are classified. The first level state primarily represents a low level state, and the second level state primarily represents a high level state. The classification is performed according to preset level state rules. For example, a level greater than or equal to 2.4V is determined to be a high level state, and a level less than or equal to 0.8V is determined to be a low level state. Those skilled in the art may further classify the level state types based on actual circumstances, and the present invention is not limited thereto.

[0056] Optionally, obtaining the type of functional abnormality based on the preset time threshold level and the current GPIO state includes: When the level state type is the first level state, a comparison is performed based on the preset time threshold level and the state duration. If the state duration is within the first time threshold, the functional abnormality type is determined to be an intelligent driving abnormality; if the state duration is within the second time threshold, the functional abnormality type is determined to be an intelligent cockpit abnormality.

[0057] When an exception is reported through SPI communication, that is, when there is no exception in SPI communication, the exception is handled directly through SPI data. If there is no error report in SPI, that is, when there is no exception in SPI communication, the functional abnormality type is obtained through the GPIO status, and the duration of the first level state is compared with the preset time threshold level to classify the functional abnormality type.

[0058] Optionally, performing corresponding exception handling based on the functional exception type includes: If the functional abnormality type is intelligent driving abnormality, deceleration processing is performed and a takeover request signal is sent to the user.

[0059] If the functional abnormality type is a smart cockpit abnormality, the abnormality information will be displayed on the display screen.

[0060] If the functional abnormality type is an SOC system abnormality, a reset processing operation is performed on the SOC system.

[0061] Since the intelligent driving function has a short error tolerance time, anomalies within the first time threshold are determined to be intelligent driving anomalies. When an intelligent driving anomaly occurs, the vehicle is controlled to slow down and a takeover request signal is sent to the user, thereby avoiding accidents caused by the fault tolerance time parameters of the intelligent cockpit. Since the intelligent cockpit function has a longer fault tolerance time, anomalies within the second time threshold are determined to be intelligent cockpit anomalies. When an intelligent cockpit anomaly occurs, an alarm message or a black screen is displayed on the control display to remind the driver that there is an abnormality in the vehicle's intelligent cockpit system. When the SOC system is abnormal, resetting the SOC system can quickly restore the SOC system to normal.

[0062] Optionally, performing corresponding exception handling based on the functional abnormality type further includes: When the level state type is the second level state, abnormal information is reported and a reset processing operation is performed on the SOC system.

[0063] The second level state is used to indicate a serious abnormality or fault. By promptly reporting abnormal information and resetting the SOC system when the level state type is determined to be the second level state, potential safety hazards can be eliminated in a timely manner and further expansion of the fault can be avoided.

[0064] Example 2: Please refer to Figure 2 The present application also proposes a system that adopts the domain controller exception handling method described in Example 1, which mainly includes: a status monitoring module, a type acquisition module and an exception handling module.

[0065] The status monitoring module is configured to monitor the operating status of the SOC system based on a preset time period. The operating status includes at least GPIO status and SPI data. The operating status of the SOC system can be monitored in real time by the domain controller's MCU, and the SOC system promptly reports the operating status information via GPIO and SPI communications.

[0066] The type acquisition module is configured to determine whether an SPI communication anomaly exists based on the SPI data. If so, the type of functional anomaly is acquired based on a preset time threshold level and the SPI data. Otherwise, the type of functional anomaly is acquired based on the preset time threshold level and the current GPIO status. The SPI data may primarily include a message ID, message time, message data, and message verification information. The SPI communication anomaly is determined based on the message verification information and message time. The preset time threshold levels may primarily include a first time threshold, a second time threshold, and a third time threshold. If no SPI communication anomaly exists, the type of functional anomaly is acquired based on the message time and the preset time threshold level in the SPI data. The functional anomaly types may primarily include intelligent driving function anomaly, intelligent cockpit function anomaly, and SOC system anomaly. When the message time is within the first time threshold, the functional anomaly is determined to be an intelligent driving function anomaly; when the message time is within the second time threshold, the functional anomaly is determined to be an intelligent cockpit function anomaly; and when the message time is within the third time threshold, the functional anomaly is determined to be an SOC system anomaly. When there is an abnormality in SPI communication, the function abnormality type is obtained through the preset time threshold level and GPIO status. The GPIO status mainly includes the level state and the state duration. The function abnormality type is mainly obtained through the state duration and the preset time threshold level.

[0067] And, an exception handling module is used to perform corresponding exception handling tasks based on the functional anomaly type. Specifically, when the functional anomaly type is an intelligent driving anomaly, the module can mainly control vehicle deceleration and send a takeover request signal to the user; when the functional anomaly type is an intelligent cockpit anomaly, the module can mainly display the abnormality information on the display screen; when the functional anomaly type is an SOC system anomaly, the module can reset the SOC system to quickly restore it to normal.

[0068] Example 3: Please refer to Figure 3 , this application also proposes a domain controller, which is composed of an MCU and a SOC.

[0069] The MCU communicates with the SOC via SPI and GPIO, and the domain controller exception handling method described in Example 1 is implemented based on the SPI communication and GPIO communication.

[0070] The MCU and SOC can each be configured with an SPI interface and a GPIO interface, respectively, to transmit information such as SOC faults or internal operating status. The MCU periodically reads SOC communication data via the SPI interface and verifies the communication data to determine the SPI communication status. The MCU reads the SOC's power level and duration in real time via the GPIO interface. The MCU uses the received SPI data and GPIO status to determine and classify anomalies. If an intelligent driving function fails, the MCU performs corresponding exception handling.

[0071] In summary, in this application, by real-time monitoring of the GPIO status and SPI data of the SOC system during a preset time period, the abnormal status of the SOC system can be monitored in time, avoiding missed detection of abnormalities. By dividing the preset time threshold levels, the exception handling of the domain controller can be compatible with the different requirements of intelligent driving and intelligent cockpit for error tolerance, effectively improving the safety and robustness of the system. By dividing the types of functional abnormalities, the real-time nature of the intelligent driving function can be met, ensuring that the intelligent driving function can be handled in a timely manner when it is abnormal. The excessive sensitivity of the abnormal time parameters of the intelligent cockpit function is avoided, and the user experience is improved. Through the monitoring of the SOC system by the MCU in the domain controller, the need for complex hardware redundant design is reduced, and the complexity and cost of the system are reduced. By executing the corresponding exception handling work through the obtained functional abnormality classification, the functional abnormality can be handled in a targeted manner, ensuring the accuracy of the exception handling and improving the reliability of the system.

[0072] In several embodiments provided in the present application, it is understood that each box in the flow chart or block diagram can represent a part of a module, program segment or code, and the part of the module, program segment or code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, which depends on the functions involved.

[0073] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling an electronic device to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0074] The specific embodiments described above further illustrate the objectives, technical solutions, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application by those skilled in the art should be included within the scope of protection of this application.

Claims

1. A domain controller exception handling method, characterized in that: include: Monitoring the operating status of the SOC system based on a preset time period; wherein the operating status includes at least GPIO status and SPI data; Determine whether there is an SPI communication abnormality based on the SPI data; if so, obtain the type of functional abnormality based on a preset time threshold level and the SPI data; otherwise, obtain the type of functional abnormality based on the preset time threshold level and the current GPIO state; And, executing corresponding exception handling work based on the functional exception type.

2. The domain controller exception handling method according to claim 1, characterized in that: The GPIO state includes at least a level state and a state duration; The SPI data includes message time, message data and message verification information.

3. The domain controller exception handling method according to claim 2, characterized in that: Determining whether there is an SPI communication abnormality based on the SPI data includes: Verifying the message data based on the message verification information and the message time; if the message verification information fails to be verified and / or the message time does not conform to a preset time rule, the message data verification fails and an SPI communication anomaly occurs; If the message verification information is successfully verified and the message time conforms to the preset time rule, the message data verification is successful and there is no abnormality in the SPI communication.

4. The domain controller exception handling method according to claim 2, characterized in that: The preset time threshold level includes at least a first time threshold, a second time threshold, and a third time threshold; the abnormality type of the function acquired based on the preset time threshold level and the SPI data includes: Comparing the message time with the preset time threshold level, and if the message time is within the first time threshold, determining that the functional abnormality type is an intelligent driving abnormality; If the message time is within the second time threshold, it is determined that the functional abnormality type is a smart cockpit abnormality; If the message time is within the third time threshold, it is determined that the functional abnormality type is an SOC system abnormality.

5. The domain controller exception handling method according to claim 2, characterized in that: Before obtaining the function abnormality type based on the preset time threshold level and the current GPIO state, the method further includes: The level state is compared with the level state based on a preset level state rule to obtain a level state type; the level state type includes at least a first level state and a second level state.

6. The domain controller exception handling method according to claim 5, characterized in that: The obtaining of the function abnormality type based on the preset time threshold level and the current GPIO state includes: When the level state type is the first level state, comparing the state duration with the preset time threshold level, if the state duration is within the first time threshold, determining that the functional abnormality type is intelligent driving abnormality; If the state duration is within a second time threshold, it is determined that the functional abnormality type is a smart cockpit abnormality.

7. The domain controller exception handling method according to claim 6, characterized in that: Execute corresponding exception handling tasks based on the functional exception type, including: If the functional abnormality type is intelligent driving abnormality, deceleration processing is performed and a takeover request signal is sent to the user; If the functional abnormality type is a smart cockpit abnormality, abnormal information is displayed on the display screen; If the functional abnormality type is an SOC system abnormality, a reset processing operation is performed on the SOC system.

8. The domain controller exception handling method according to claim 7, characterized in that: Executing corresponding exception handling work based on the functional exception type also includes: When the level state type is the second level state, abnormal information is reported and a reset processing operation is performed on the SOC system.

9. A system based on the domain controller exception handling method according to any one of claims 1 to 8, characterized in that: The system comprises: A status monitoring module, configured to monitor the operating status of the SOC system based on a preset time period; wherein the operating status includes at least GPIO status and SPI data; a type acquisition module, configured to determine whether an SPI communication anomaly exists based on the SPI data; if so, acquire the type of the functional anomaly based on a preset time threshold level and the SPI data; otherwise, acquire the type of the functional anomaly based on the preset time threshold level and the current GPIO state; And, an exception handling module is used to perform corresponding exception handling tasks based on the functional exception type.

10. A domain controller, characterized in that: The domain controller is composed of an MCU and a SOC, the MCU communicates with the SOC via SPI and GPIO, and the domain controller exception handling method according to any one of claims 1 to 8 is executed based on the SPI communication and GPIO communication.

Images