Vehicle controller and its error management method

Abstract

The present application relates to a vehicle controller and an error management method thereof. The error management method of the vehicle controller according to the present invention includes: a step of collecting errors; a step of converting the collected error database into a form required for diagnosis and debugging; a step of executing a recovery mechanism in conjunction with a platform health management cluster (PHM), a state management cluster (SM), and an execution management cluster (EM), wherein the step of collecting errors may include: a step of collecting user errors occurring in vehicle applications; a step of collecting platform errors occurring in at least one of the platform health management cluster (PHM), the state management cluster (SM), and the execution management cluster (EM); or a step of collecting integration errors based on whether the network management cluster (NM), the time synchronization cluster (TS), and the persistence cluster (PER) are operating normally.

Description

Technical Field

[0001] The present invention relates to a vehicle controller and an error management method thereof. Background Art

[0002] Generally, intelligent electronic control units (ECUs) and technology-driven program environments require a large amount of computing performance. Power and cost efficiency are important parts, but high-performance computing (HPC) in the field of safety faces various problems. To solve this problem, technologies not utilized by ECUs need to be adopted, and innovative technologies should be utilized as much as possible. The Automotive Open System Architecture (AUTOSAR) Adaptive Platform dynamically manages resources and communication, reducing the effort required for software development and integration. At the same time, it distributes application programs and allows system integrators to carefully integrate them, eliminating the risk of failures to ensure safety. The dynamic operation of application programs is restricted according to the constraints specified in the application manifest. During execution, the dynamic allocation of resources and communication paths can only be carried out in a manner defined within the configuration range. The implementation of the AUTOSAR Adaptive Platform restricts dynamic functions in software configuration, in addition to the pre-determination of programs, dynamic memory limits in the startup phase, priority-based scheduling, by scheduling policies, fixed allocation of processes to the central processing unit (CPU), access to existing files, the Adaptive Platform (AP), application programming interface (API) usage limits, and verification of code execution.

[0003] Prior Art Documents

[0004] Patent Documents

[0005] Patent Document 1: Korean Patent Publication: 10-2016-0076270, Publication Date: June 30, 2016, Invention Title: Vehicle Multi-Core System

[0006] Patent Document 2: Korean Granted Patent: 10-1584213, Grant Date: January 5, 2016, Invention Title: Data Communication Flow Setting Device and Method in AUTSAR Platform. Summary of the Invention

[0007] An object of the present invention is to provide a vehicle controller that actively processes errors and an error management method thereof.

[0008] According to an embodiment of the present invention, the error management method of a vehicle controller includes: a step of collecting errors; a step of converting the collected error database into a form required for diagnosis and debugging; and a step of executing a recovery mechanism in conjunction with a platform health management cluster (PHM), a state management cluster (SM), and an execution management cluster (EM). The step of collecting errors may include: a step of collecting user errors occurring in vehicle applications; a step of collecting platform errors occurring in at least one of the platform health management cluster (PHM), the state management cluster (SM), and the execution management cluster (EM); or a step of collecting integration errors based on whether a network management cluster (NM), a time synchronization cluster (TS), and a persistence cluster (PER) are operating normally.

[0009] In an embodiment, the method may further include the step of periodically monitoring the error.

[0010] In an embodiment, the errors may be collected using the local host method of ara:com.

[0011] In an embodiment, the errors are collected by polling.

[0012] In an embodiment, the step of collecting integration errors may include: a step of calling an application programming interface (API) to confirm whether the network management cluster (NM), the time synchronization cluster (TS) or the persistence cluster (PER) is running normally; and a step of confirming a response to the call.

[0013] In an embodiment, the step of compiling into a database may include: a step of classifying the collected errors into diagnostic errors, debugging errors, or logging errors; and a step of compiling the classified errors into a database respectively.

[0014] In an embodiment, the step of executing the recovery mechanism may include: a step of monitoring a configuration related to whether the configuration is platform dependent; and a step of restarting or stopping the application according to the monitoring result.

[0015] In an embodiment, the recovery mechanism is performed using the collected error and client-specific callback information.

[0016] A vehicle controller according to an embodiment of the present invention includes: a communication device for communicating with an external device; a memory for storing an error manager; and a micro control unit for controlling the communication device and the memory and driving the error manager, wherein the error manager collects user errors occurring in vehicle applications, or collects platform errors occurring in at least one of a platform health management cluster (PHM), a state management cluster (SM) and an execution management cluster (EM), or collects integrated errors based on whether a network management cluster (NM), a time synchronization cluster (TS) and a persistence cluster (PER) are operating normally; the collected error database is converted into a form required for diagnosis and debugging, and a recovery mechanism is executed in conjunction with the platform health management cluster (PHM), the state management cluster (SM) and the execution management cluster (EM).

[0017] In an embodiment, the error manager is implemented by the AUTOSAR Adaptive Platform.

[0018] In an embodiment, the fault manager periodically monitors the network management cluster (NM), the time synchronization cluster (TS), and the persistence cluster (PER).

[0019] In an embodiment, the error manager periodically monitors whether at least one of the functional clusters has an error via the ara:api.

[0020] In an embodiment, the error manager transmits customer-specific callback information to user fail-safe logic of the vehicle application.

[0021] Effects of the Invention

[0022] The vehicle controller and the error management method thereof according to the embodiment of the present invention can proactively handle platform errors by having an error manager for collecting / managing platform errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The following drawings are used to help understand the present embodiment, and provide an embodiment together with the detailed description. The technical features of the present embodiment are not limited to specific drawings, and the features disclosed in each drawing can be combined with each other to form a new embodiment.

[0024] Figure 1 is an architectural diagram showing a general AUTOSAR adaptive platform.

[0025] Figure 2 The following diagram is an example of Proxy-Skeleton service communication via SOME / IP communication.

[0026] Figure 3 This is a diagram for explaining the operation of a general AUTOSAR adaptive platform.

[0027] Figure 4 It is a diagram for explaining the operation of the AUTOSAR adaptive platform according to an embodiment of the present invention.

[0028] Figure 5 It is an example flowchart of an operation method of an error manager for an application of the AUTOSAR adaptive platform according to an embodiment of the present invention.

[0029] Figure 6 It is an example diagram of a vehicle controller 1000 according to an embodiment of the present invention.

[0030] 100: Adaptive AUTOSAR function cluster, 200: Adaptive AUTOSAR application, 210: Error manager, 211: Error collection unit, 212: Error post-processing unit, 213: User-defined system recovery unit, 310: Vehicle application, 1000: ECU Detailed implementation mode

[0031] The content of the present invention will be described clearly and in detail below with reference to the accompanying drawings so that those skilled in the art to which the present invention pertains can easily implement it.

[0032] The present invention can be changed in various ways and can have various forms. Specific embodiments are shown in the drawings and described in detail herein. However, it should be understood that the present invention is not limited to the specific disclosed forms and includes all changes, equivalents, and substitutes included in the spirit and scope of the present invention. Terms such as first, second, etc. may be used to describe various components, but the components are not limited to these terms.

[0033] These terms are used to distinguish one component from other components. For example, without departing from the scope of the claims of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component. When it is mentioned that a certain component is "connected" or "coupled" to another component, it should be understood that it may be directly connected or coupled to other components, but there may also be other components in the middle. On the contrary, when it is mentioned that a certain component is "directly connected" or "directly coupled" to another component, it should be understood that there are no other components in the middle.

[0034] Other expressions for explaining the relationship between components, that is, expressions such as "between ~" and "directly between ~" or "adjacent to ~" and "directly adjacent to ~" should also be interpreted in the same way. The terms used in this specification are only for describing specific embodiments and do not limit the present invention. Unless clearly indicated otherwise in the context, singular expressions include plural expressions.

[0035] In this specification, terms such as "including" or "having" are intended to specify the presence of features, numbers, steps, actions, components, parts, or combinations thereof to be implemented, and shall not be construed as precluding the presence or additional possibility of one or more other features, numbers, steps, actions, components, parts, or combinations thereof. Unless otherwise defined, all terms used in this specification, including technical and scientific terms, have the same meaning as commonly understood by those skilled in the technical field to which the present invention pertains. Terms defined in commonly used dictionaries shall be interpreted as having a meaning consistent with the meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formalized manner unless clearly defined in this specification.

[0036] Figure 1 is an architecture diagram of a general AUTOSAR adaptive platform. Refer to Figure 1 , the adaptive platform provides functional clusters and basic services.

[0037] SWC (Software Component), which is formally defined by the interface of BSW (Basic Software), is a component of the AUTOSAR architecture. The BSW module provides basic standard services, such as bus communication, memory management, IO access, system and diagnostic services. Other components of AUTOSAR are the Runtime Environment (RTE), which controls the connections between SWCs or the connections from SWCs to the BSW. The Virtual Functional Bus (VFB) defined by AUTOSAR provides a conceptual basis for the communication between SWCs and the use of BSW services. All communications of SWCs are based on the VFB. Therefore, SWCs are independent of ECU hardware. Thus, SWCs can be reused in projects and platforms. The VFB is executed by providing a specifically configured RTE, and the RTE connects the BSWs appropriately configured for each ECU.

[0038] Adaptive Applications (AA) run based on ARA (AUTOSAR Runtime for Adaptive Application). ARA consists of APIs (Application Programming Interfaces) that provide functional clusters belonging to Foundation or Services. Foundation provides the basic functions of AP (Adaptive Platform) and Service. All adaptive applications can provide services for other adaptive applications.

[0039] The adaptive platform includes functional clusters to provide better services. The functional clusters include a time management cluster, an operating system cluster, an execution management cluster, a persistence cluster, a platform health management cluster, a logging and tracing cluster, a hardware acceleration cluster, and a communication management cluster. The functional clusters communicate with other applications through their respective APIs (Application Programming Interfaces). Since only the API implementations are defined, the degree of freedom in implementing the functional clusters of the adaptive platform is much higher than that of the BSW (Basic Software) protocol stack that constitutes the existing classic platform.

[0040] The basic services include software (SW, Software) configuration management services, security management services, and diagnostic services. The basic services can be invoked through ara::com (AUTOSAR Runtime for Adaptive Applications) with middleware properties.

[0041] The adaptive platform considers the hardware executed by the machine. The hardware is virtualized using various technologies. The hardware includes one or more machines. Only one AP instance runs. There is a single chip / multiple chips on the hardware that host the machines.

[0042] Figure 2 It is an example diagram of the communication oriented to the Proxy-Skeleton service through SOME / IP communication. The biggest difference between the AUTOSAR adaptive platform and the classic platform lies in the communication method. Most existing classic platforms are based on traditional signal-oriented communication. On the other hand, the adaptive platform is based on service-oriented communication (Service-Oriented Communication; SOC). This is a communication method in which the services required between the server that provides the service, i.e., the Skeleton, and the client that consumes the service, i.e., the Proxy, are dynamically connected through service discovery and SOME / IP (Scalable service-Oriented MiddlewarE over IP). The in-vehicle application server is a system equipped with the AUTOSAR adaptive platform and can freely monitor and control intelligent sensors and intelligent actuators according to the purpose of the in-vehicle application through SOME / IP.

[0043] Figure 3 It is a diagram for explaining the operation of a general AUTOSAR adaptive platform.

[0044] The adaptive AUTOSAR application 20 includes an error manager 21.

[0045] The error manager 21 periodically monitors whether there are errors in NM (Network Management), PER, and ETC. The error manager 21 checks whether there are errors in the adaptive AUTOSAR function cluster 10 through the ara:api of each cluster in each monitoring cycle.

[0046] When an abnormal symptom is found, the error manager 21 links PHM (Platform Health Management), SM (State Management) and EM (Execution Management) to make the adaptive AUTOSAR application 30 perform a recovery action, thereby completing the error operation.

[0047] PHM (Platform Health Management) performs monitoring functions. PHM (Platform Health Management) performs control flow monitoring, external monitoring. Alive Supervision periodically monitors whether the periodic-SWC is running normally. DeadlineSupervision monitors whether the non-periodic-SWC is running normally between two given points. Logical Supervision monitors whether the sequence of SWC units is executed in the predetermined order. Health Channel Supervision monitors external factors related to health.

[0048] PHM (Platform Health Management) and EM (Execution Management) perform error reading functions. Watchdog Control supports hardware watchdog. Error Handling performs processing after an error occurs. PHM's actions include ending or restarting the application, resetting the platform instance, hardware watchdog, and notification functions. Ending or restarting the application means stopping and restarting the SWC. Resetting the platform instance can be reset by the controller itself. Hardware watchdog supports hardware watchdog. The notification function performs notification when a corresponding problem occurs in the SWC that performs a safety role.

[0049] SM (State Management) manages the state of the ECU itself, receives events from the adaptive platform and SWC, controls NM (Network Management) to turn the network on / off, and controls system shutdown (Shutdawn) and restart (Restart).

[0050] EM (Execution Management) is responsible for system execution management, including platform initialization, startup and termination of applications. EM (Execution Management) runs together with the operating system and performs runtime scheduling of applications. In an embodiment, a monitoring period can be set. For example, the monitoring period is 1 ms, 10 ms, 100 ms, etc.

[0051] EM (Execution Management) performs system startup and shutdown, controls the process creation of the adaptive platform and applications after startup, and performs startup and shutdown of SWC (Software Component), and should control the application according to SM (State Management).

[0052] The general adaptive AUTOSAR platform monitors system anomalies through internal modules such as PHM (Platform Health Management), SM (State Management), and EM (Execution Management). When an anomaly occurs, it performs operations to re-execute / stop the corresponding application. However, these are the functions of each module and do not include the process of combining these to perform a recovery operation starting from the time point when an error actually occurs.

[0053] On the other hand, the adaptive AUTOSAR platform according to an embodiment of the present invention supplements this unimplemented part on the adaptive AUTOSAR OS.

[0054] Figure 4 It is a diagram for explaining the operation of the AUTOSAR adaptive platform according to an embodiment of the present invention. Refer to Figure 4 , the adaptive AUTOSAR application 200 may include an error manager 210. The error manager 210 may include: an error collection unit 211, an error post-processing unit 212, and a user-defined system recovery unit 213.

[0055] The error collection unit 211 can collect user errors, integration errors, and platform errors. In an embodiment, user errors can be transmitted from the vehicle application 310. In an embodiment, integration errors can be transmitted from NM (Network Management) 110, TS (Time Synchronization Management) 120, and PER (Continuity Management) 130 of the adaptive AUTOSAR function cluster 100. In an embodiment, platform errors can be transmitted from PHM (Platform Health Management) 140, SM (State Management) 150, and EM (Execution Management) 160 of the adaptive AUTOSAR function cluster 100.

[0056] The error post-processing unit 212 may include a debug database (DB), a log DB, and a diagnostic DB. In an embodiment, the debug DB may be transmitted to the PER 130. In an embodiment, the log DB may be transmitted to the vehicle application 310. In an embodiment, the diagnostic DB may be transmitted to the diagnostic module (DIAG) 170.

[0057] The user-defined system recovery unit 213 may include a customer specification callback. In an embodiment, the customer specification callback may be transmitted to the user fail-safe logic 312.

[0058] The error manager 210 corresponds to an application of Adaptive AUTOSAR. This application may perform the following functions.

[0059] First, the error manager 210 may access the PHM (Platform Health Management) 140, SM (State Management) 150, and EM (Execution Management) 160 respectively through the ara API.

[0060] Second, the error manager 210 may access the APIs that can read whether there are errors in the NM (Network Management) 110, TS (Time Synchronization Management) 120, and PER (Persistence Management) 130.

[0061] Third, the error manager 210 may always execute and run in the processing unit as an Adaptive AUTOSAR application.

[0062] Fourth, the error manager 210 may monitor whether an error occurs through the defined APIs during a set period. In an embodiment, the period may be 1 s, 1 μs, 1 ms, 1 ns, etc.

[0063] When an error occurs, the error manager 210 may switch the currently running application to the shutdown state through the SM 150, request a shutdown operation of the currently running application through the EM 160, and perform a recovery action on the corresponding application through the PHM (Platform Health Management) 140.

[0064] As described above, the Adaptive AUTOSAR platform according to an embodiment of the present invention may process errors through the error manager 210 based on the Adaptive AUTOSAR OS.

[0065] In general, Adaptive AUTOSAR provides SW functions that can handle errors, but the OS specifications do not include technologies that can actively handle actual errors. By internalizing these components and allocating them to Tier, stable and high-quality software (SW) can be mass-produced. In particular, in the development field of Tier, error handling is essential. Therefore, various requirements can be collected from Tier and customers, and its application scope is wide.

[0066] In an embodiment, the error manager 210 can periodically monitor whether there are errors. For example, the error manager 210 can check whether there are errors in the Adaptive AUTOSAR function cluster module through the ara:api of each cluster in each monitoring cycle. In an embodiment, the error monitoring cycle can be set by the user.

[0067] The error collection unit 211 can send and receive using the Local Host method of ara:com (communication similar to the IPC method of POSIX OS, usually constructing shared memory). In an embodiment, the communication can operate in a polling manner. This can reduce the load on the system.

[0068] In an embodiment, the error collection unit 211 can collect user errors (UserError) that occur in the vehicle application 300.

[0069] In an embodiment, the error collection unit 211 can collect platform errors (Platform Error) that occur in the FC (Functional Cluster) of Adaptive AUTOSAR.

[0070] In an embodiment, the error collection unit 211 can collect comprehensive errors. For example, the error collection unit 211 can call APIs that confirm whether the NM (Network Management) 110, TS (Time Synchronization Management) 120, and PER 130 are operating normally, and confirm the responses to them. When the responses are inappropriate, it can be determined as an integrated error (Integrated Error).

[0071] The error post-processing unit 212 can base on the collected error database into the form required for diagnosis and debugging as follows.

[0072] The error DB for diagnosis is a database based on error codes (Error Code), descriptions, and diagnostic parameters to be transmitted to the diagnostic device. The output format can include diagnostic specifications.

[0073] The error DB for system analysis is an error database used for debugging purposes. For example, the debugging DB can store error logs (Error Log) through PER130. The output format can be DLT format.

[0074] The log DB is a database in log format so that the vehicle application can handle appropriate exceptions. The output format can be printf format.

[0075] The user-defined system recovery unit 213 may include an adaptive AUTOSAR recovery mechanism that is executed in conjunction with PHM (Platform Health Management) 140, SM (State Management) 150, and EM (Execution Management) 160. This recovery mechanism only monitors elements that are completely dependent on the platform and are controlled, and can execute responses (such as recovery functions such as restart, application interruption, etc.).

[0076] In an embodiment, the user-defined system recovery unit 213 can call back the body area of the callback function defined by the customer to the "user-defined system recovery" area in the form of a function pointer. In an embodiment, the customer can directly redefine the recovery operation and use it according to the collected errors and the strategy determined by the customer.

[0077] For example, logic is needed to monitor whether the PCI Express interface is fail-safe. When the customer cannot set this function because it is not reflected in the User Configuration of the PHM (Platform Health Management) 140 of Adaptive AUTOSAR, the normal operation of the PCI Express interface cannot be observed. Through the above parts, the customer can further increase the function of directly monitoring PCI Express when the collected errors occur. The fail-safe area control logic is constructed in the CDD form of classic AUTOSAR.

[0078] Figure 5 1 is an example flow chart showing an operation method of an error manager for an application of an AUTOSAR adaptive platform according to an embodiment of the present invention. Figures 3 to 5 , error manager 210 (refer to Figure 3 ) can be done as follows.

[0079] The error manager 210 may collect errors from at least one functional cluster or other adaptive applications (S110). For example, the error manager 210 may periodically monitor the network management (NM), time synchronization management (TS) and persistence management (PER) of the functional cluster to collect integration errors, or collect user errors from vehicle applications, or collect platform errors output from platform health management (PHM), state management (SM) and execution management (EM).

[0080] The error manager 210 may database the collected user errors, integration errors, platform errors, etc. (S120). For example, the error manager 210 may create a database of errors for debugging purposes, or create a database of error codes, descriptions, and diagnostic parameters to be sent to a diagnostic device, or create a database of collected errors in the form of logs to apply exception handling in the vehicle.

[0081] The error manager 210 may be linked with a platform health manager (PHM), a state manager (SM), and an execution manager (EM) of at least one functional cluster to execute a user-defined recovery mechanism of the adaptive AUTOSAR application ( S130 ).

[0082] As can be understood by those skilled in the art, the steps and / or operations according to the present invention can be performed simultaneously in other embodiments in other orders, or in parallel, or for other specific times (epochs), etc. According to an embodiment, part or all of the steps and / or operations can be at least partially completed or executed using instructions, programs, interactive data structures (interactive data structures), and one or more processors driving the client and / or server stored in one or more non-transitory computer-readable media. As an example, one or more non-transitory computer-readable media can be software, firmware, hardware, and / or any combination thereof. In addition, the functions of the "modules" discussed in this specification can be composed of software, firmware, hardware, and / or any combination thereof.

[0083] Figure 6 FIG. 1 is an exemplary diagram of a vehicle controller 1000 according to an embodiment of the present invention. Figure 6 The vehicle controller (ECU) 1000 may include an MCU 1100 , a memory 1200 , and a communication device 1300 .

[0084] The microcontrol unit (MCU) 1100 may be implemented to perform the overall operation of the vehicle controller 100. The MCU 1100 may drive at least one program by executing at least one instruction. For example, at least one program may include reference to Figures 3 to 5 Describes the Adaptive AUTOSAR application.

[0085] The MCU 1100 may include a plurality of cores, which may include at least one main core and at least one sub-core.

[0086] The memory 1200 can be implemented to store at least one program. The memory 1200 can include volatile memory or non-volatile memory. For example, the memory 1200 can include storage media such as random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), programmable read-only memory (PROM), and electrically erasable programmable read-only memory (EEPROM), NAND flash memory, NOR flash memory, etc.

[0087] The communication device 1300 can perform an interface function to communicate with the outside of the vehicle controller 1000. Generally, in order to communicate with the vehicle controller 1000 and external devices of the vehicle controller 1000, controller area network (CAN) communication, local interconnect network (LIN) communication, and Ethernet communication can be used.

[0088] One or more non-transitory computer-readable media and / or means for implementing / executing one or more operations / steps / modules of embodiments of the present invention may include, but are not limited to, application-specific integrated circuits (ASICs), standard integrated circuits, microcontrollers, controllers that execute appropriate instructions, and / or embedded controllers, field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and the like.

[0089] In addition, the above content of the present invention is only a specific embodiment for implementing the invention. The present invention not only includes the specific and practically utilizable means themselves, but also includes the technical idea of abstract and conceptual ideas that can be used as technologies in the future.

Claims

1. An error management method for a vehicle controller, applied to an Automotive Open System Architecture (AUTOSAR) adaptive platform, characterized in that, The error management method comprises: Collect the steps for the error; Steps to convert the collected error database into a form required for diagnosis and debugging; and Cooperate with the platform health management cluster, state management cluster, and execution management cluster to execute the recovery mechanism steps. Steps to collect errors include: Steps to collect user errors that occur in vehicle applications; or The step of collecting platform errors occurring in at least one of the platform health management cluster, the state management cluster, and the execution management cluster; or Steps to collect integration errors based on whether the network management cluster, time synchronization cluster, and persistence cluster are functioning properly.

2. The error management method according to claim 1, wherein A step of periodically monitoring for errors is also included.

3. The error management method according to claim 1, wherein The errors were collected using the local host method of ara:com.

4. The error management method according to claim 1, characterized in that, The errors are collected by polling.

5. The error management method according to claim 1, characterized in that, Steps to collect integration errors include: The step of calling an application programming interface to confirm whether the network management cluster, the time synchronization cluster or the persistence cluster is running normally; and Steps to confirm the response to the call.

6. The error management method according to claim 1, wherein The steps of database formation include: The step of classifying the collected errors into errors for diagnosis, errors for debugging, or errors for logging; and The step of respectively storing the classified errors in a database.

7. The error management method according to claim 1, wherein The steps to execute the recovery mechanism include: Steps to monitor configuration related to platform dependencies; and Steps to restart or stop the application based on the monitoring results.

8. The error management method according to claim 1, wherein in, The recovery mechanism is performed using the collected error and client-specific callback information.

9. A vehicle controller is applied to an AUTOSAR adaptive platform of an automotive open system architecture, and is characterized in that The vehicle controller comprises: a communication device for communicating with an external device; a memory for storing an error manager; and a micro control unit, controlling the communication device and the memory, and driving the error manager, the error manager, Collect user errors that occur in vehicle applications, or collect platform errors that occur in at least one of a platform health management cluster, a state management cluster, and an execution management cluster, or collect integration errors based on whether a network management cluster, a time synchronization cluster, and a persistence cluster operate normally; The collected error database is converted into a form required for diagnosis and debugging, A recovery mechanism is executed in conjunction with the platform health management cluster, the state management cluster, and the execution management cluster.

10. The vehicle controller according to claim 9, wherein The error manager is implemented by an AUTOSAR adaptive application.

11. The vehicle controller according to claim 9, characterized in that, The error manager periodically monitors the network management cluster, the time synchronization cluster, and the persistence cluster.

12. The vehicle controller according to claim 9, wherein, The error manager periodically monitors at least one of the functional clusters for errors through the ara:api, and the functional clusters include a time management cluster, an operating system cluster, an execution management cluster, a persistence cluster, a platform health management cluster, a log and trace cluster, a hardware acceleration cluster, and a communication management cluster.

13. The vehicle controller according to claim 9, characterized in that, The error manager transmits customer-specific callback information to the user fail-safe logic of the vehicle application.

Images