Error management method and framework of vehicle-mounted controller
A centralized error management architecture for vehicle control systems addresses the complexity and portability issues by integrating error detection, repair, and collection modules, enabling efficient and prioritized error handling across different platforms, thereby improving system reliability.
Patent Information
- Application Number
- CN202411793440.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-06
- Publication Date
- 2025-03-28
Smart Images
Figure CN119718744A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a vehicle-mounted controller, and in particular to an error management method and architecture of a vehicle-mounted controller. Background Art
[0002] The vehicle's electronic and electrical architecture is changing from traditional distributed to centralized, from signal-oriented software architecture to service-oriented software architecture, and from CAN (control area network) and LIN (local interconnect network) bus networks to in-vehicle Ethernet communication architecture.
[0003] On this basis, vehicle controllers such as domain controllers (DCU), zone controllers (ZCU) and high-performance computers (HPC, also known as central control units) are being widely used. At the same time, these vehicle controllers are becoming more and more complex, for example, they have more and more functions, more and more complex modules, and usually require joint development across companies or departments. All of these will inevitably lead to various errors in the development or operation of vehicle controllers.
[0004] In some approaches, errors in the vehicle controller are handled by each module within it, for example, each module is responsible for storing the fault and performing reset operations. However, as the functions of the vehicle controller increase and the structure becomes more complex, this approach will increase the complexity of the solution. In addition, implementing error handling in each module is not conducive to the portability of error management solutions between different chip platforms. Summary of the invention
[0005] In view of this, the present invention provides an error management method and architecture for a vehicle-mounted controller, which can achieve centralized management of errors, thereby improving the portability of the error management solution.
[0006] The error management architecture of the vehicle controller of an embodiment of the present invention includes: at least one error detection module, which is used to detect errors; an error repair module, which is used to repair errors; an error collection module, which is used to collect error data; and an error management module, which is responsible for the centralized management of errors and is specifically used to: obtain error information reported by the error detection module; query a configuration table based on the obtained error information to determine a corresponding error handling strategy, wherein the configuration table predefines the correspondence between the error information and the error handling strategy; when the error handling strategy contains at least one error repair operation, control the error repair module to execute the error repair operation; and control the error collection module to store or report error data related to the error information.
[0007] In some embodiments, the error handling strategy further includes: a delay time, and the error management module is specifically used to control the error repair module to perform the error repair action after the delay time; wherein, the delay time is used to control the execution priority of the error repair operation when different errors exist at the same time.
[0008] In some embodiments, the error detection module is further used to: when a specific type of error is detected, directly control the system restart without reporting error information; the error management module is further used to: after restart, actively read the error information before restart saved by the power management module.
[0009] In some embodiments, the error information includes: an identity of an error detection module, at least two levels of error parameters; and / or, the error data includes: an identity of an error detection module; at least two levels of error parameters; and at least one of the following information: time information, the number of consecutive occurrences of the error, and an error handling strategy.
[0010] In some embodiments, the on-board controller includes: a first core and a second core, the error management architecture runs on the first core; the error collection module includes at least one of the following: a non-volatile memory for storing the error data; a diagnostic fault code reporting unit for reporting diagnostic fault codes based on the error information / error data; and a diagnostic recording and tracking unit for sending the error data to the second core, and storing it in a file system and / or reporting it to a cloud server through the second core.
[0011] In some implementations, the error management module is a basic software component located in a basic software layer in compliance with the AUTOSAR standard, and the error management module includes the configuration table that can be configured.
[0012] An error management method for a vehicle-mounted controller in an embodiment of the present invention comprises: obtaining error information reported by each error detection module in the vehicle-mounted controller; querying a configuration table to determine a corresponding error handling strategy based on the obtained error information, wherein the configuration table predefines a correspondence between error information and error handling strategy; when the error handling strategy contains at least one error repair operation, controlling the vehicle-mounted controller to execute the error repair operation; and controlling the vehicle-mounted controller to store or report error data related to the error information to a cloud server.
[0013] In some embodiments, the error handling strategy further includes: a delay time, controlling the on-board controller to perform the error repair operation after the delay time; wherein, the delay time is used to control the execution priority of the error repair operation when different errors exist at the same time.
[0014] The vehicle-mounted controller of the embodiment of the present invention uses the above-mentioned error management architecture.
[0015] The computer device / equipment / system of the embodiment of the present invention includes a memory, a processor, and a computer program / instruction stored in the memory, and the processor executes the computer program to implement the steps in the above method.
[0016] Beneficial effects of the embodiments of the present invention:
[0017] In the embodiment of the present invention, an error management module is set to uniformly collect errors, uniformly process errors, and uniformly store or report errors, thereby enabling centralized management of errors. Moreover, when it is necessary to transplant in different chip platforms or cars, the error management module is mainly transplanted, thereby improving the portability of the error management solution. For example, in some examples, the error management module can be designed as a basic software component (basic software component) in the BSW (basic software) layer that complies with the AUTOSAR standard, and then the error management solution of the embodiment of the present invention can be applied on different platforms by configuring the component based on different platforms. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Other details and advantages of the present invention will become apparent from the detailed description provided below. It should be understood that the following drawings are merely illustrative and thus cannot be considered as limiting the present invention. The following will be described in detail with reference to the drawings, wherein:
[0019] Figure 1 is a schematic structural diagram of an embodiment of a vehicle-mounted controller of the present invention;
[0020] Figure 2 is a schematic diagram of an embodiment of an error management architecture of an on-board controller of the present invention;
[0021] Figure 3 is a schematic structural diagram of another embodiment of the error management architecture of the vehicle controller of the present invention;
[0022] Figure 4 It is a schematic diagram of the layered architecture of AUTOSAR;
[0023] Figure 5 is a flow chart of an embodiment of an error management method of an on-board controller of the present invention;
[0024] Figure 6 It is a structural diagram of an embodiment of a computer device / equipment / system of the present invention that can implement the above method. DETAILED DESCRIPTION
[0025] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present invention clearer and more understandable, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.
[0026] In the description of the present invention, it is to be understood that the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. Moreover, the terms "first", "second", etc. are applicable to distinguishing similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way are interchangeable where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein.
[0027] like Figure 1 As shown, it is a structural schematic diagram of an embodiment of the vehicle-mounted controller of the present invention. The vehicle-mounted controller can be, for example, a domain controller (such as a body domain controller, a chassis domain controller), a regional controller, an HPC (High Performance Computer), and an ECU (Electronic Control Unit). The vehicle-mounted controller is a dual-core structure and includes an A core and an M core, and information interaction is achieved between the two cores by means of shared memory and the like. Among them, the A core is generally a performance core, and the M core is generally a real-time core. In applications, the software / program running on the M core is generally the underlying or critical software / program, so the M core needs to be monitored. In some embodiments, each module in the M core, such as an operation mode selection (Msel) module, a safe boot (SBoot) module, etc., is responsible for respective error monitoring and processing. However, when the structure of the vehicle-mounted controller becomes more and more complex and the functions become more and more, this approach will increase the complexity of the solution. In addition, since each module performs error monitoring and processing separately, it is not conducive to the transplantation of error management solutions between different vehicles and chip platforms.
[0028] Therefore, the embodiment of the present invention proposes an error management solution for a vehicle controller, which implements centralized monitoring and processing of errors by adding an error management module for centralized error management, thereby enhancing the portability of the solution. Figures 2 to 6 The specific scheme of the embodiment of the present invention is described.
[0029] like Figure 2 FIG. 1 is a schematic diagram of an embodiment of an error management architecture of a vehicle-mounted controller of the present invention. The vehicle-mounted controller may be, for example, Figure 1The structure shown in the embodiment, the error management architecture of this embodiment can be used in the M core of the vehicle controller. In the following, the M core is mainly used as an example for illustration. However, it can be understood that the vehicle controller itself is not limited to a dual-core structure, it can be a single-core structure, and can also have more than three cores; the error management architecture of this embodiment is also applicable to the A core or other cores in a single-core controller or a multi-core structure, which will not be repeated here.
[0030] like Figure 2 As shown, the error management architecture includes: a plurality of error detection modules 101 - 10 n , an error repair module 201 , an error management module 301 and an error collection module 401 .
[0031] The error detection modules 101-10n are used for error checking, such as monitoring whether the value of a register is a legal value, whether the memory is wrong, whether the bus is wrong, whether the hardware is wrong, whether the operation logic and frequency of important functions are normal, etc. The errors referred to in this embodiment mainly refer to errors related to functional safety, such as functional safety related to various safety levels defined by ASIL (Automotive Safety Integrity Level).
[0032] In some embodiments, the error detection module may include: a RegMon (Registry Monitor) module for monitoring a registry database, such as monitoring whether the value of a register is a legal value. An operation mode selection (Msel) module for selecting a startup mode during the system startup phase and detecting whether the startup mode is successfully selected. A safe boot (SBoot) module for detecting abnormal codes during the system startup phase. An embedded memory and register check and monitoring (eMCEM) module for detecting whether the Fccu (Fault Collection and Control Unit) register is a normal value. A built-in self-test module (Bist) including a logic built-in self-test and a memory built-in self-test. A watchdog timer (WatchDog) for detecting whether the operation logic and frequency of important functions are normal. A low latency communication engine (LLCE) error detection module for detecting whether external LLCE hardware is working properly. And an analog-to-digital converter check (ADC_check) module for self-testing the samplers of the brake and accelerator pedals. It should be noted that these modules are only examples and not limitations.
[0033] When the error detection modules 101-10n detect relevant errors, they can call the interface (such as API interface) provided by the error management module 301 and report the error information to the error management module 301 in a predetermined format. The error management module 301 can manage the errors in a unified manner, and the management in this embodiment includes but is not limited to: error processing, storage, reporting, etc.
[0034] The error detection modules 101-10n may report error information in the following format: an identification (ID) of the error detection module, a primary error parameter, and a secondary error parameter. The contents of the primary error parameter and the secondary error parameter may be user-defined, and may be the scene when the error occurs, such as a register number or a subdivision error type of the error module, or an action that the error management module 301 is expected to perform, such as notifying other modules, performing a soft reset or a hard reset, etc.
[0035] For example, when the RegMon module detects a data error in the target register, it can first try to recover the data by itself, that is, write the correct register value again. At this time, the error data reported can be: RegMon(X), Rewrite(0) and Retry Register Address. Among them, RegMon(X) is the identity of RegMon, Rewrite(0) is a first-level error parameter, indicating that the RegMon module will recover the error by itself, and Retry Register Address is a second-level error parameter, indicating the address of the register to which the value is to be rewritten. When the RegMon module fails to recover to normal after three attempts, the new error data reported is: RegMon(X), FunctionReset(X), Retry Register Address. Among them, FunctionReset(X) indicates that it is expected to perform a soft reset, that is, the ECU is powered off but the FLASH is not powered off, so as to recover the abnormality. In this way, the error information reported by the RegMon module can be shown in Table 1 below.
[0036] Table 1:
[0037] ID First level error parameter Secondary error parameters RegMon(X) Rewrite(0) Retry Register Address RegMon(X) Rewrite(0) Retry Register Address RegMon(X) Rewrite(0) Retry Register Address RegMon(X) FunctionReset(X) Retry Register Address
[0038] In the error management module 301, a configurable configuration table is pre-set, and the configuration table may include: information of the error detection module to be uniformly managed, and the corresponding relationship between the error information and the error handling strategy. Among them, the user can reconfigure the configuration table to add or delete the error detection module to be uniformly managed based on the actual application, and can also reconfigure the relationship between the error information and the error handling strategy, as well as the specific content of the reconfiguration processing strategy. By providing a configurable configuration table, it is beneficial for the error management module 301 to be compatible with different chip platforms, applicable to different scenarios, and improve the portability of the solution.
[0039] After the configuration table is configured, when the reported error information is received, the configuration table can be queried based on the error information to obtain the corresponding error handling strategy. Among them, the error handling strategy may include: error repair operation to repair the error. Of course, the error handling strategy can also be empty, indicating that no specific operation needs to be performed.
[0040] For example, assume that it is defined in the configuration table that: the error handling strategy corresponding to (RegMon(X), Rewrite(0)) is empty, and the error handling strategy corresponding to (RegMon(X), FunctionReset(X)) is a soft reset operation. Then, when the RegMon module reports error information for the first three times, the error management module 301 will not perform a specific error recovery operation according to the configuration table, but will only record the relevant errors. When the error information is reported for the fourth time, it is determined according to the configuration table that a soft reset operation is to be performed, and the error management module 301 can control the execution of a soft reset.
[0041] In some embodiments, the error handling strategy may include: a delay time, which indicates how long the error recovery operation is delayed to execute, wherein when the delay time is set to a value of 0, it indicates immediate execution. By setting the delay time, the execution priority problem of the error recovery operation when multiple error detection modules report error information simultaneously or successively can be solved. For example, when it is determined to perform a soft reset based on the error information reported by the RegMon module and the delay time is 100ms, if within this 100ms, it is determined to perform a hard reset based on the error information reported by the watchdog timer and it is executed immediately, then the hard reset operation will be executed. Because hard reset has a higher recovery effect than soft reset, performing a hard reset will also repair the errors detected by the RegMon module.
[0042] The error management module 301 may perform error recovery operations through the error repair module 201. For example, the error repair module 201 may include a PMIC (power management IC) for performing a reset operation. The error management module 301 may perform a reset operation by sending a reset instruction to the PMIC.
[0043] In addition, when the error management module 301 receives the reported error information, it can store or report the error data related to the error information through the error collection module 401. The error data may further include: time information when reporting, the number of consecutive occurrences of the error, and the corresponding error handling strategy, etc., in addition to the reported error information.
[0044] In the error collection module 401, it may include: NVM (non-volatile memory) for storing error data locally; DTC (diagnostic trouble code) unit for reporting DTC code according to error information / error data; and DLT (Diagnostic Log And Trace) unit for sending error data to A core, and storing it in the file system of A core and / or reporting it to the cloud server through A core.
[0045] Specifically, in the error management module 301, the reported error information can be managed in a transient RAM (volatile memory) first. Then, it is reported according to the reporting conditions defined by the DTC. At the same time, the state of the NVM state machine is stored in the NVM, and at each restart, the error management module 301 reads the last error data saved in the NVM into the RAM for management. Finally, if the A core runs normally (detected by the heartbeat connection between the A core and the M core), it is synchronized to the A core through the DLT.
[0046] In some implementations, the error management module 301 manages the error data in a queue manner, for example, based on a first-in-first-out mechanism. The data format stored in the queue may be, for example, the ID of the error detection module, the primary error parameter, the secondary error parameter, the time of error reporting, the execution operation triggered when the error occurs, and the number of consecutive occurrences of the same error.
[0047] In addition, for some more important hardware errors, the error detection module will be set not to report error information but directly instruct the error repair module 201 to perform a reset operation. For such cases, after resetting (restarting), the error management module 301 can actively read the error information saved in the Fccu through IPL (Initial Program Loader) and the power management module to obtain the error condition of the last reset operation. This is because before restarting, the Fccu of the chip will keep the last error information, and before the ECU is initialized, it will be copied to the RAM through IPL, and converted into error information through the power management module, which can be used as a basis for understanding the error. For such errors, on the one hand, the error involved has a greater impact, and on the other hand, it cannot be processed by software, so it will not involve a processing strategy, and another queue can be used for management. The storage format of the queue can be: the ID of the error reporting module, the first-level error parameter, the second-level error parameter, the third-level error parameter, and the number of consecutive occurrences of the same error, etc. Among them, the ID of the error reporting module is always the ID of the power management interface. The first-level error parameter can save the information in the DES (Destructive Event Status) register and the FES (Functional / External Reset Status) register. The second-level error information can be the information of the corresponding register read according to the errors recorded in the DES and FES. For example, when the first-level error parameter indicates POR_Reset, the shared register data of the PMIC can be read and saved in the second-level error parameter. The third-level error parameter is used as an extension to store data when the amount of data in the register is large. For example, the software reset triggered by MC_RGM (microcontroller reset and management module) will set the 5th position of the FES register to 1 and reset it. After restarting, the EFS register will be saved to the first-level error parameter, and the value of the PMIC register will be saved to the second-level error parameter. At this time, the status register of Fccu may not be read after restarting, so it is necessary to extend the A2FF and N2FF registers in Fccu to judge and write them into the third-level error parameter for subsequent error source query.
[0048] like Figure 3 , which is an example of a specific application of the error management architecture of the present invention. Figure 3 In FIG. 4 , two error detection modules, the registry monitor (ReMon) and the eMCEM, are shown.
[0049] When the registry monitor detects for the first time that the value of the target register has been tampered with to an illegal value, and the RegMon module configures the target register to have a three-time self-recovery mechanism, the RegMon module will attempt to write a legal value into the target register and simultaneously report the error information (RegMon module identity, self-recovery, target register address) to the error management module 301.
[0050] After the error management module 301 receives the reported error information, it obtains the current timestamp through the STBM (Synchronized Time-Base Manager), and looks up the table according to the pre-configured configuration table, and finds that there is no action to be executed. Then, the error information, current time, and execution action are stored in queue 1, and the queue information, such as queue member information and queue pointer, is updated. Finally, according to the state machine of NvM, the information in the queue is stored in the local NVM, which may further involve reporting to DTC or synchronizing to the file system of core A through DLT or reporting to the cloud, etc.
[0051] Then, when the next detection cycle of RegMon is reached, it will check again whether the rewrite is successful. If it is unsuccessful, the above steps will be repeated for 3 times. After the fourth detection of unsuccessful rewrite, the error management module 301 triggers the soft reset recovery mechanism. At this time, the error data uploaded to the error management module 301 is (RegMon module identity; soft reset; target register address).
[0052] After the error management module 301 collects the reported error information, similarly, the current time is obtained through STBM, the execution action obtained through the configuration table is soft reset and the corresponding delay time is obtained. Then, the relevant data is queued and the queue information is updated. Then, the data in the queue is immediately written to NvM, and the power management interface is notified to perform the reset operation. Because the reset will be performed, there is no operation synchronized to the A core through DLT at this time, and it will be executed after the restart.
[0053] After the reset, the error management module 301 reads the error data before the restart stored in the NvM after the restart, that is, loads the error data into the program running memory, and then synchronizes the error data to the A core for information storage and reporting.
[0054] The above process is a reset process initiated by the error management module 301. In the application, the reset may be initiated directly by the error detection module instead of through the error management module 301. For example, for some eMCEM errors that are configured to be directly processed, when it detects an error, it directly notifies the PMIC to perform a reset operation through the power management interface, and does not report the error information to the error management module. At this time, after the error management module 301 is restarted, it actively reads the error information through the interface provided by the power management module, and then queues the relevant error data, writes NVM, and shares it with the A core through DLT for storage and reporting, etc. to achieve management of such errors.
[0055] In the above embodiment, the error management module 301 is a basic software component located in the basic software layer (BSW) in accordance with the AUTOSAR standard. Figure 4 As shown, in AUTOSAR, from top to bottom, it can include: application software layer, which is composed of multiple software components (SWC); RTE (runtime environment) layer and BSW layer. The BSW layer includes: various service components and hardware-oriented driver or interface components. The error management module 301 in the above embodiment can be set in the BSW layer to uniformly manage various functional safety-related components in the BSW layer, so that it can be easily transplanted between different chips / automobile platforms.
[0056] like Figure 5 FIG. 1 is a flow chart of an embodiment of an error management method for a vehicle-mounted controller of the present invention, which includes the following steps:
[0057] Step S50: Obtain error information reported by each error detection module in the vehicle controller.
[0058] Step S52: According to the acquired error information, query the configuration table to determine the corresponding error handling strategy, wherein the configuration table predefines the corresponding relationship between the error information and the error handling strategy.
[0059] Step S54: when the error handling strategy includes an error repair operation, controlling the vehicle controller to execute the error repair operation; and
[0060] Step S56: Control the vehicle-mounted controller to store or report error data related to the error to the cloud server.
[0061] The specific details of each step in this embodiment have been described above. Please refer to the architecture embodiment for details.
[0062] like Figure 6As shown, it is a schematic diagram of the structure of an embodiment of the computer device / equipment / system 6 of the present invention, which includes: a memory 60, a processor 62 and a computer program or executable code stored in the memory 60. When the processor 62 executes the computer program or executable code, the error management method in the embodiment of the present invention is implemented.
[0063] The description of the above computer device / equipment / system embodiment is similar to the description of the above method or architecture embodiment, and has similar beneficial effects as the method or architecture embodiment. For undisclosed technical details, please refer to the description of the method or architecture embodiment of this application for understanding.
[0064] The processor may be at least one of an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, a microprocessor, etc. It is understandable that the electronic device that implements the function of the processor may also be other, and the embodiments of the present application are not specifically limited.
[0065] The above-mentioned computer storage medium / memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory (Flash Memory), a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM) and the like; it can also be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.
[0066] It should be noted that the above description is only for example and not for limitation of the present invention. In other embodiments of the present invention, the method may have more, fewer or different steps, and the order, inclusion and function of each step may be different from that described and illustrated. For example, generally multiple steps can be combined into a single step, and a single step can also be divided into multiple steps. For those of ordinary skill in the art, without paying creative work, the sequential changes of each step are also within the scope of protection of the present invention.
[0067] The technical solution of the present invention, in essence or the part that contributes to the prior art, or all or 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 a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor or a microcontroller to perform all or part of the steps of the method described in each embodiment of the present invention.
[0068] Those skilled in the art will appreciate that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed.
[0069] Although the present invention has been disclosed as above with preferred embodiments, the present invention is not limited thereto. Any changes and modifications made by any person skilled in the art without departing from the spirit and scope of the present invention should be included in the protection scope of the present invention, and therefore the protection scope of the present invention should be subject to the scope defined by the claims.
Claims
1. An error management architecture for a vehicle controller, characterized in that: include: at least one error detection module, configured to detect errors; Error repair module, used to repair errors; An error collection module, used to collect error data; as well as The error management module is responsible for the centralized management of errors, specifically for: Obtaining error information reported by the error detection module; According to the acquired error information, query a configuration table to determine a corresponding error handling strategy, wherein the configuration table predefines a corresponding relationship between the error information and the error handling strategy; When the error handling strategy contains at least one error repair operation, controlling the error repair module to perform the error repair operation; as well as Control the error collection module to store or report error data related to the error information.
2. The error management architecture of the vehicle controller as claimed in claim 1, characterized in that: The error handling strategy further includes: a delay time, the error management module is specifically used to control the error repair module to perform the error repair operation after the delay time; The delay time is used to control the execution priority of the error repair operation when different errors exist at the same time.
3. The error management architecture of the vehicle controller as claimed in claim 1, characterized in that: The error detection module is further used to: directly control the system to restart without reporting error information when a specific type of error is detected; The error management module is further used to: after restarting, actively read the error information before restarting saved by the power management module.
4. The error management architecture of the vehicle controller as claimed in claim 1, characterized in that: The error information includes: an identity identifier of the error detection module and at least two levels of error parameters; And / or, the error data includes: an identification of the error detection module; at least two levels of error parameters; and at least one of the following information: time information, the number of consecutive occurrences of the error, and an error handling strategy.
5. The error management architecture of the vehicle controller as claimed in claim 1, characterized in that: The vehicle controller includes: a first core and a second core, the error management architecture being deployed in the first core; The error collection module includes at least one of the following: A non-volatile memory, used for storing the error data; a diagnostic trouble code reporting unit, configured to report a diagnostic trouble code according to the error information / error data; and The diagnostic recording and tracking unit is used to send the error data to the second core, and store the error data in a file system and / or report it to a cloud server through the second core.
6. The error management architecture of the vehicle controller as claimed in claim 1, characterized in that: The error management module is a basic software component located in a basic software layer in compliance with the AUTOSAR standard, and the error management module includes the configuration table that can be configured.
7. An error management method for a vehicle controller, characterized in that: The method comprises: Obtaining error information reported by each error detection module in the vehicle controller; According to the acquired error information, query a configuration table to determine a corresponding error handling strategy, wherein the configuration table predefines a corresponding relationship between the error information and the error handling strategy; When the error handling strategy includes at least one error repair operation, controlling the onboard controller to execute the error repair operation; and Control the vehicle-mounted controller to store or report error data related to the error information to a cloud server.
8. The error management method of the vehicle controller as claimed in claim 7, characterized in that: The error handling strategy further includes: a delay time, controlling the onboard controller to perform the error repair operation after the delay time; The delay time is used to control the execution priority of the error repair operation when different errors exist at the same time.
9. A vehicle-mounted controller, characterized in that: An error management architecture as claimed in any one of claims 1 to 6 is used.
10. A computer device / equipment / system comprising a memory, a processor and a computer program / instruction stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to claim 7 or 8.