CN114194125A

CN114194125A - Vehicle control unit, running method of vehicle control unit and vehicle

Info

Publication number: CN114194125A
Application number: CN202111669788.1A
Authority: CN
Inventors: 黄超; 黄云南
Original assignee: Shanghai Xiantu Intelligent Technology Co Ltd
Current assignee: Shanghai Xiantu Intelligent Technology Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2022-03-18
Anticipated expiration: 2041-12-31
Also published as: CN114194125B

Abstract

The specification provides a vehicle control unit, an operation method of the vehicle control unit and an automobile, wherein a first core and a second core in the vehicle control unit are mutually master-slave, different sets of CAN buses are configured for the first core and the second core, and a third core in the vehicle control unit has the authority of state scheduling of the first core and the second core. Therefore, communication redundancy backup based on a multi-core and multi-CAN bus is realized, and when the main backup core fails, the third core CAN wake up the backup core to take over the bus in time, so that the whole vehicle controller CAN keep control over the node equipment, and the safety is improved.

Description

Vehicle control unit, running method of vehicle control unit and vehicle

Technical Field

The specification relates to the technical field of automobiles, in particular to a vehicle control unit, an operation method of the vehicle control unit and an automobile.

Background

With the continuous progress of the intelligent process in the automobile field, users have made higher and higher requirements on the performance of automobiles. A Vehicle Control Unit (VCU) is used as a core Control Unit of an automobile, and performs information interaction with a motor Controller, a battery management system, a steer-by-wire system, a light-by-wire system and other node devices in a manner of a CAN (Controller Area Network) bus or a Vehicle-mounted ethernet, and performs reasonable and safe instructions by processing received information, thereby realizing the Control of the whole automobile. Therefore, the functionality and reliability of the vehicle control unit are of great importance. At present, when a vehicle control unit is in a hardware fault (such as disconnection of a CAN bus) or a single-node fault (such as excessive single-node error frames caused by poor bus consistency and active bus exit), the vehicle control unit cannot maintain control over node equipment, so that a great safety risk exists.

Disclosure of Invention

According to a first aspect of embodiments of the present specification, a vehicle control unit is provided, which includes a first core, a second core, and a third core, where when any one of the first core and the second core is in an active state, the other one is in a standby state; wherein: the first core is used for communicating with the node equipment through the first group of CAN buses when in the active state, and processing a computing task distributed by the second core or keeping a suspended state when in the standby state; the second core is used for communicating with the node equipment through a second group of CAN buses when in the active state, and processing the calculation task distributed by the first core or keeping the suspension state when in the standby state; the third core is used for monitoring the states of the first core, the second core and the node equipment and sending corresponding scheduling signals to the first core or the second core according to the states.

In some embodiments, the first core is further configured to: in the initialization process, checking whether the working state of the second core is a suspended state, if so, keeping the running state, otherwise, switching to the suspended state; the second core is further configured to: in the initialization process, whether the working state of the first core is in a suspended state or not is checked, if yes, the running state is kept, and if not, the first core is switched to the suspended state.

In some embodiments, the third core is further configured to: in the initialization process, a system clock and node equipment are initialized.

In some embodiments, the third core is further configured to: after power-on initialization is completed, if the first core is in a main state, monitoring whether a first group of CAN buses survive according to a zone bit of a bus register, if so, continuing monitoring, otherwise, sending a first scheduling signal to the second core to enable the second core to be switched from a standby state to the main state, and sending a reset signal to the first core to enable the first core to be reset; and if the second core is in the active state, monitoring whether the second group of CAN buses are alive according to the zone bit of the bus register, if so, continuing to monitor, otherwise, sending a second scheduling signal to the first core to enable the first core to be switched from the standby state to the active state, and sending a reset signal to the second core to enable the second core to be reset.

In some embodiments, the vehicle control unit further includes: the watchdog module is internally provided with a timer; the counting value of the timer is cleared according to a dog feeding signal periodically sent by the core in the main state, and the third core judges whether the core in the main state is in failure according to whether the counting value of the timer overflows or not.

In some embodiments, the first core is further configured to: when a second scheduling signal is received, acquiring the calculation task data of a second core from the shared memory; the second core is further configured to: when a first scheduling signal is received, acquiring computing task data of a first core from a shared memory; the computing task data includes real-time task progress and corresponding variable values.

In some embodiments, the first core is further configured to: after the reset is finished, confirming whether the second core is in the main state, if so, entering a standby state; the second core is further configured to: and after the reset is finished, confirming whether the first core is in the active state, and if so, entering the standby state.

In some embodiments, the first set of CAN buses includes a 4-way CAN bus and the second set of CAN buses includes a 4-way CAN bus.

According to a second aspect of embodiments of the present specification, there is provided an operating method of a vehicle control unit, where the vehicle control unit includes a first core, a second core, and a third core, and when any one of the first core and the second core is in a master state, the other one is in a standby state; when the first core is in the active state, the first core communicates with the node equipment through the first group of CAN buses, and when the first core is in the standby state, the first core processes the calculation tasks distributed by the second core or keeps a suspended state; the second core communicates with the node equipment through a second group of CAN buses when in the active state, and processes the calculation tasks distributed by the first core or keeps the suspended state when in the standby state; the method is applied to a third core, and comprises the following steps: monitoring the states of the first core, the second core and the node device; and sending a corresponding scheduling signal to the first core or the second core according to the state.

According to a third aspect of the embodiments of the present specification, there is provided an automobile including the vehicle control unit according to any one of the embodiments of the specification.

The technical scheme provided by the embodiment of the specification can have the following beneficial effects:

in an embodiment of the present specification, a vehicle controller, an operating method of the vehicle controller, and an automobile are disclosed, in which a first core and a second core in the vehicle controller are mutually active and standby, different sets of CAN buses are configured for the first core and the second core, and a third core in the vehicle controller has an authority to schedule states of the first core and the second core. Therefore, communication redundancy backup based on a multi-core and multi-CAN bus is realized, and when the main backup core fails, the third core CAN wake up the backup core to take over the bus in time, so that the whole vehicle controller CAN keep control over the node equipment, and the safety is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the specification.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present specification and together with the description, serve to explain the principles of the specification.

FIG. 1 is a schematic illustration of a vehicle control unit shown in accordance with an exemplary embodiment of the present description;

FIG. 2 is a flow chart illustrating a method of operating a hybrid vehicle controller in accordance with an exemplary embodiment of the present description;

FIG. 3 is a schematic diagram illustrating the structure of a hybrid vehicle controller according to an exemplary embodiment of the present description;

fig. 4 is a schematic diagram of an architecture supporting CAN redundancy backup shown in accordance with an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the specification, as detailed in the appended claims.

The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Based on this, the embodiments of the present disclosure provide a vehicle control unit to solve the above technical problems. The following provides a detailed description of examples of the present specification.

As shown in fig. 1, fig. 1 is a schematic diagram of a vehicle control unit according to an exemplary embodiment, where the vehicle control unit 11 includes a first core 12, a second core 13, and a third core 14, and when any one of the first core 12 and the second core 13 is in an active state, the other one is in a standby state;

wherein:

the first core 12 is configured to communicate with the node device 17 through the first set of CAN buses 15 in the active state, and process a computation task allocated by the second core 13 or maintain a suspended state in the standby state;

the second core 13 is configured to communicate with the node device 17 through the second set of CAN buses 16 in the active state, and process a computation task allocated by the first core 12 or maintain a suspend state in the standby state;

the third core 14 is configured to monitor states of the first core 12, the second core 13, and the node device 17, and send a corresponding scheduling signal to the first core 12 or the second core 13 according to the states.

The vehicle control Unit of this embodiment may be a chip having a architecture of three or more cores, and the chip may be an MCU (micro controller Unit) chip, where the MCU chip is a chip-level computer formed by appropriately reducing the frequency and specification of a CPU (Central Processing Unit) and integrating a Memory, a counter, a USB (Universal Serial Bus), an analog-to-digital converter, a DMA (Direct Memory Access), and the like on a single chip. The MCU chip has the advantages of high performance, low power consumption, programmability, high flexibility and the like, so that the MCU chip is suitable for being used as a whole vehicle controller. Of course, the chip may also be other types of chips, such as an NPU (Neural-network Processing Unit) chip, and the like. It should be noted that the chip may also adopt a heterogeneous architecture, such as an MCU + NPU architecture. The Core (Core) of the vehicle control unit is a hardware unit that can perform computing tasks. Taking the vehicle controller as a multi-core MCU as an example, the multi-core MCU is a microprocessor having two or more CPUs, and each CPU can be considered as a core of the vehicle controller.

In this embodiment, when any one of the first core and the second core is in the active state, the other one is in the standby state, that is, the first core and the second core are mutually active and standby, the core in the active state may communicate with the node device through the taken-over bus, that is, the task is normally executed, and part of the computation tasks which have a large computation amount but have low real-time requirements may be allocated to the core in the standby state; and the core in the standby state keeps silent on the bus, if the distributed computing task is received, the computing task is executed, otherwise, the core keeps the suspended state. The third core of this embodiment may check the states of the first core, the second core, and the node device, so as to perform scheduling, so as to switch the states of the first core and/or the second core, that is, schedule the core in the active state to switch to the standby state, and/or schedule the core in the standby state to switch to the active state.

In some examples, when the vehicle control unit is a chip integrating an energy efficiency core (E-core) and a performance core (P-core), since the pipeline stage number of the P-core is generally greater than that of the E-core, i.e., the performance of the P-core is generally higher, the first core and the second core mainly responsible for processing the computing task may be the P-core, and the third core mainly responsible for scheduling work may be the E-core. While for the first core and the second core, the two cores may be equivalent, i.e. the performance is the same; alternatively, the first core may be set to enter a master state after the vehicle control unit is started, that is, the first core is taken as a master and the second core is taken as a standby, in this case, one of the cores of the vehicle control unit with the best performance may be taken as the first core, so that the performance of the first core is higher than that of the second core.

In this embodiment, the first set of CAN buses assigned to the first core and the second set of CAN buses assigned to the second core are different paths of CAN buses. The CAN is a serial communication network capable of realizing distributed real-time control, and the CAN bus is a multi-master control bus system, and the communication medium of the CAN bus CAN be any one of twisted pair, coaxial cable, optical fiber and the like. The devices connected with the vehicle control unit through the CAN bus are called node devices, such as a motor controller, a battery management system, a steer-by-wire system, a light-by-wire system and the like. The architecture of the vehicle control unit in the related art is generally a multi-core isomorphic architecture, and therefore, the vehicle control unit in the related art generally communicates with the node devices through a set of CAN buses, and once a fault occurs, the node devices cannot be kept under control. In this embodiment, two sets of CAN buses are configured, and the core in the active state takes over the CAN buses, so that the two sets of CAN buses CAN perform redundancy backup with each other, for example, when the first core is in the active state and the second core is in the standby state during normal operation, when a certain bus of the first set of CAN buses fails at a certain moment, the third core detects that the state of the first core is a failure, immediately schedules the second core to switch to the active state, and the second core communicates with the node device through the second set of CAN buses, so that the entire controller CAN continue to maintain control over the node device.

In the vehicle control unit of this embodiment, the first core and the second core are mutually active and standby, different sets of CAN buses are configured for the first core and the second core, and the third core in the vehicle control unit has an authority to schedule the states of the first core and the second core. Therefore, communication redundancy backup based on a multi-core and multi-CAN bus is realized, and when the main backup core fails, the third core CAN wake up the backup core to take over the bus in time, so that the whole vehicle controller CAN keep control over the node equipment, and the safety is improved.

In some examples, the first core may also be to: in the initialization process, checking whether the working state of the second core is a suspended state, if so, keeping the running state, otherwise, switching to the suspended state; the second core may also be to: in the initialization process, whether the working state of the first core is in a suspended state or not is checked, if yes, the running state is kept, and if not, the first core is switched to the suspended state. The run state and the suspend state represent the actual operating state of the core, and in addition, the actual operating state of the core may include an idle (idle) state and a reset (reset) state. Wherein the operating state characterizes that the core is executing a computing task; the suspended state represents that the core stops working and waits to be awakened; the idle state represents that a core waits to distribute a computing task; the reset state indicates that the core is being restored to the starting state. When the first core and the second core are initialized, whether the working state of the other core is in a suspended state or not is checked, if yes, the running state is kept, otherwise, the first core and the second core are switched to the suspended state, and therefore only one of the two cores is in the running state after the initialization of the first core and the second core is completed.

In some examples, the third core may also be to: in the initialization process, a system clock and node equipment are initialized. The system clock can be a circuit composed of an oscillator, a frequency divider and the like, each core of the whole vehicle controller completes actions such as instruction execution, state conversion and the like under the drive of the system clock, and each node device completes actions such as serial port data sending, analog-to-digital conversion and the like under the drive of the system clock. For example, assuming that the system clock and the node device are initialized by the first core, when the first core enters a reset state in the process of initializing the system clock and the node device, the first core re-initializes the system clock and the node device after the reset is finished, which results in the system clock and the node device losing the original progress and reducing the reliability, and similarly, assuming that the system clock and the node device are initialized by the second core, the security risk is also increased; and the third core does not bear the calculation task, and the load is light, so that the situation is not easy to occur, and the reliability is improved.

In addition, after the initialization is completed, the third core can keep the running state, check the states of the first core and the second core, and perform corresponding scheduling according to the states. The states may include an active state/a standby state, and an operating state, for example, when the third core checks that the first core and the second core are both in the standby state, a scheduling signal may be sent to one of the cores, so that the core receiving the scheduling signal is switched to the active state; or, when the third core checks that the first core and the second core are both in the operating state, a state update signal may be sent to the core in the standby state to indicate that the core that receives the state update signal switches the operating state to the suspend state or the idle state. In addition, the third core checks the states of the first core and the second core, which may be implemented by inter-core communication, such as SRI Crossbar (a bus system that can implement inter-core communication).

In some examples, the third core may be further configured to: after initialization is finished, if the first core is in a main state, monitoring whether a first group of CAN buses survive according to a zone bit of a bus register, if so, continuing monitoring, otherwise, sending a first scheduling signal to the second core to enable the second core to be switched from a standby state to the main state, and sending a reset signal to the first core to enable the first core to be reset; and if the second core is in the active state, monitoring whether the second group of CAN buses are alive according to the zone bit of the bus register, if so, continuing to monitor, otherwise, sending a second scheduling signal to the first core to enable the first core to be switched from the standby state to the active state, and sending a reset signal to the second core to enable the second core to be reset. The bus register is a register embedded in the vehicle controller and used for recording the survival state of each path of CAN bus through a zone bit, the third core CAN monitor whether the corresponding CAN bus is alive or exited according to the zone bit of the bus register, and when the CAN bus in a group of CAN buses connected with the core in the main state exits, the third core CAN schedule the core in the standby state to be switched to the main state, so that the vehicle controller CAN keep control over node equipment, and redundant backup capability based on multi-core and multi-CAN is realized.

In order to improve the accuracy of the state check of the first core and the second core, in some other examples, the vehicle control unit may further include a watchdog module, a timer is built in the watchdog module, and a count value of the timer is cleared according to a dog feeding signal periodically sent by the core in the active state; and the third core judges whether the core in the main state fails according to whether the count value of the timer overflows or not. The watchdog module may be a timer circuit, and when any one of the first core and the second core is in the active state, a signal is output to the watchdog module at intervals, where the signal is referred to as a dog feeding signal and used to zero a count value of a counter of the watchdog module, and if the specified time is exceeded and the dog is not fed, the count value of the timer of the watchdog module overflows, which indicates that the core in the active state has a fault, at this time, the third core may send a scheduling instruction to the core in the standby state to switch the core in the standby state to the active state, and at the same time, the third core may send a reset signal to the core in the active state to reset the core in the active state. Therefore, through the watchdog module, the third core CAN perform scheduling processing in time when the main backup core fails, so that the whole vehicle controller CAN keep control over the node equipment, and redundant backup capability based on multi-core and multi-CAN is realized.

Also, to implement active/standby non-inductive switching, in some examples, the first core may be further configured to: when a second scheduling signal is received, acquiring the calculation task data of a second core from the shared memory; the second core may also be to: when a first scheduling signal is received, acquiring computing task data of a first core from a shared memory; the computing task data includes real-time task progress and corresponding variable values. The shared memory may be a shared data area inside the vehicle controller, the first core, the second core and the third core may all read and write the shared memory, when the first core and the second core execute a calculation task, key parameters of the calculation task, such as a real-time task progress and a corresponding variable value, may be written into the shared memory, and when the first core, the second core and the third core are normally operated, a necessary operation state may be written into the shared memory, and when the first core is switched to an active state, data representing that the first core is in the active state may be written into the shared memory. Therefore, the core just switched to the primary state can acquire the real-time task progress and the corresponding variable value of the core originally in the primary state from the shared memory, continue to execute the calculation task and realize the non-inductive switching takeover of the bus.

Further, in some examples, the first core may also be to: after the reset is finished, confirming whether the second core is in the main state, if so, entering a standby state; the second core may also be to: and after the reset is finished, confirming whether the first core is in the active state, and if so, entering the standby state. That is to say, after the reset is finished, the first core or the second core may confirm the state of the other core which is a primary core and a standby core, and if the core is confirmed to be in the primary state, the core actively enters the backup core mode; if the core is confirmed not to be in the active state, which indicates that the core may have a fault or is being reset, the core may not enter the backup core mode, but still maintain the primary backup core mode before reset, and continue to execute the previous computing task. Accordingly, the state of the other core, which is determined to be active and standby by the first core or the second core, may be implemented by sharing a memory and/or by using an SRI Crossbar, and of course, in other embodiments, the process of determining the state may also be implemented by using other inter-core communication methods.

For the first group of CAN buses and the second group of CAN buses, it is considered that the current multi-core MCU chip generally supports 8 CAN buses, and therefore, in some examples, the first group of CAN buses and the second group of CAN buses may respectively include 4 CAN buses, so that the performance of the first core and the performance of the second core are averaged, and the control capability of the entire controller may be kept unchanged before and after the switching of the master cores. Of course, in other embodiments, the number of the CAN buses included in each of the first group of CAN buses and the second group of CAN buses may be different, and the total number of the CAN buses may also be greater than 8, which is not limited in this specification.

It should be noted that the vehicle control unit described above may also include other hardware units, such as a housing, a memory, other communication interfaces, and the like, and the memory may include but is not limited to: phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, and the like. In addition, the vehicle control unit of the present embodiment may be applied to various types of vehicles including conventional passenger cars, buses, and autonomous vehicles, etc.

Corresponding to the foregoing embodiments of the vehicle control unit, the present specification also provides embodiments of an operating method of the vehicle control unit. As shown in fig. 2, fig. 2 is a flowchart illustrating an operation method of a vehicle control unit according to an exemplary embodiment, where the vehicle control unit includes a first core, a second core, and a third core, and the method is applied to the third core, and the method includes:

step 201, monitoring the states of a first core, a second core and node equipment; the first core communicates with the node equipment through a first group of CAN buses when in the active state, and processes the calculation tasks distributed by the second core or keeps the suspended state when in the standby state; the second core communicates with the node equipment through a second group of CAN buses when in the active state, and processes the calculation tasks distributed by the first core or keeps a suspended state when in the standby state; when any one of the first core and the second core is in a main state, the other one is in a standby state;

step 202, sending a corresponding scheduling signal to the first core or the second core according to the state.

The implementation process of each step in this embodiment is specifically described in the implementation process of the function and action of each module of the vehicle controller, and is not described herein again.

To describe the vehicle control unit in more detail, an embodiment is described as follows:

as shown in fig. 3, fig. 3 is a schematic view of a structure of the vehicle controller according to this embodiment, where the vehicle controller according to this embodiment includes a processor 31, a memory 32, and a communication interface 33, and the elements are electrically connected to each other through at least one communication bus to implement data transmission or interaction. The memory 32 may be used to store programs that may be run on the processor 31 and the communication interface 33 may be used to communicate signaling or data with the node device. Specifically, in the present embodiment, the processor 31 employs a three-Core MCU chip, which includes three independent cores, Core0, Core1 and Core2, wherein Core0 is an E Core, and Core1 and Core2 are P cores, and the three cores can operate simultaneously in Lockstep (Lockstep). The Memory comprises a Shared Memory (Shared Memory), which is a common storage area Shared by the three cores, and the Core0, the Core1 and the Core2 can read and write the Shared Memory, such as writing key parameters and necessary operating states of computing tasks into the Shared Memory. Core1 is equivalent to Core2, Core1 is the default primary Core and Core2 is the backup Core. In addition, the vehicle control unit of this embodiment further includes a watchdog module, and the master core periodically sends a dog feeding signal to the watchdog module when the master core is in a run state, so as to zero a count value of a timer built in the watchdog module, and sends a reset signal to the master core when the count value of the timer built in the watchdog module overflows.

The vehicle control unit of this embodiment CAN be used to build a structure shown in fig. 4 that supports CAN redundancy backup, in which a first group of CAN buses 42 is allocated to a Core1 (411 in the drawing) of the vehicle control unit 41, a second group of CAN buses 43 is allocated to a Core2 (412 in the drawing) of the vehicle control unit 41, NodeA, NodeB, and NodeC (441, 442, and 443 in sequence in the drawing) are three of the node devices 44, the first group of CAN buses 42 and the second group of CAN buses 43 are both connected to each node device 44, a termination resistor 45 in the structure is set for reasonable circuit matching, and is used to reduce standing waves and losses in signal transmission, and optionally, the termination resistor may be a 120 ohm resistor.

The vehicle control unit provides communication redundancy backup capability based on the following operation scheme:

first, in an initialization phase:

core1 performs the following actions: checking the working state of the Core2, if the Core2 is in a hash state, keeping a run state, starting to execute a calculation task, and if the Core2 is not in the hash state, entering the hash state;

core2 performs the following actions: checking the working state of the Core1, if the Core1 is in a hash state, keeping a run state, starting to execute a calculation task, and if the Core1 is not in the hash state, entering the hash state;

core0 performs the following actions: initializing a system clock and node equipment, entering a run state, checking the working states of Core1 and Core2 through SRI Crossbar, and if both Core1 and Core2 are in the run state, sending an indication signal to Core2 to indicate that Core2 switches the working state to a halt state;

second, in the normal operation stage:

core1 performs the following actions: normally executing a calculation task, distributing part of the calculation task which is large in calculation amount and low in real-time requirement to Core2 through a shared memory, and communicating with node equipment through a first group of CAN buses;

core2 performs the following actions: the method comprises the steps of bearing a calculation task distributed by Core1, ignoring an indication signal if the indication signal which is sent by Core0 and used for indicating that the status is halt is entered in the process of executing the calculation task, entering an idle status after the calculation task is completed, serving as a backup Core, and keeping silence on a second group of CAN buses;

core0 performs the following actions: whether each bus is alive is detected through a zone bit of a bus register, whether a program of a master Core flies is detected through a watchdog module, states of the Core1 and the Core2 are confirmed through an SRI Crossbar as an inter-Core communication mode, and the Core1 and the Core2 are authorized to be subjected to state scheduling;

third, when a fault occurs, i.e., Core0 detects a Core1 fault (e.g., watchdog timeout/CAN bus exit, etc.):

core0 performs the following actions: sending a scheduling signal to the Core2 to wake up the Core2 to take over the bus, and sending a reset signal to the Core1 after the taking over is successful;

core2 performs the following actions: when a scheduling signal is received, switching to a main Core sharing mode, acquiring the real-time task progress and the corresponding variable value of the Core1 from the shared memory, continuing to execute a calculation task, and communicating with the node equipment through a second group of CAN buses;

core1 performs the following actions: and when a reset signal is received, entering a reset state for resetting, after the resetting is finished, checking the shared memory and confirming the state of the Core2 through an SRI Crossbar, and if the Core2 is in a state of taking over the bus, actively entering a backup Core mode to undertake the backup task undertaken by the Core 2.

By the scheme, an architecture combining an HSM (Hardware Security Module), a secure internal communication bus and a distributed memory protection system is constructed, so that the Security of a whole vehicle system is improved while the hard real-time is met; and moreover, the multi-path CAN bus is adopted for communication redundancy backup, so that the noninductive communication link switching under the low-level fault is realized, and the safety of high-level automatic driving is ensured to a certain extent.

Corresponding to the foregoing embodiments, the present embodiment further provides an embodiment of an automobile (not shown), where the automobile includes the vehicle control unit of the foregoing embodiment. The automobile can be a traditional passenger car, a traditional bus and the like, and can also be an automatic driving car, such as an automatic driving sweeper, an automatic driving passenger car and the like.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Other embodiments of the present description will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This specification is intended to cover any variations, uses, or adaptations of the specification following, in general, the principles of the specification and including such departures from the present disclosure as come within known or customary practice within the art to which the specification pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the specification being indicated by the following claims.

It will be understood that the present description is not limited to the precise arrangements described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.

Claims

1. The vehicle control unit is characterized by comprising a first core, a second core and a third core, wherein when any one of the first core and the second core is in a main state, the other one is in a standby state; wherein:

the first core is used for communicating with the node equipment through the first group of CAN buses when in the active state, and processing a computing task distributed by the second core or keeping a suspended state when in the standby state;

the second core is used for communicating with the node equipment through a second group of CAN buses when in the active state, and processing the calculation task distributed by the first core or keeping the suspension state when in the standby state;

the third core is used for monitoring the states of the first core, the second core and the node equipment and sending corresponding scheduling signals to the first core or the second core according to the states.

2. The vehicle control unit of claim 1, wherein the first core is further configured to: in the initialization process, checking whether the working state of the second core is a suspended state, if so, keeping the running state, otherwise, switching to the suspended state;

the second core is further to: in the initialization process, whether the working state of the first core is in a suspended state or not is checked, if yes, the running state is kept, and if not, the first core is switched to the suspended state.

3. The vehicle control unit of claim 2, wherein the third core is further configured to: in the initialization process, a system clock and node equipment are initialized.

4. The vehicle control unit of claim 1, wherein the third core is further configured to: after power-on initialization is completed, if the first core is in a main state, monitoring whether a first group of CAN buses survive according to a zone bit of a bus register, if so, continuing monitoring, otherwise, sending a first scheduling signal to the second core to enable the second core to be switched from a standby state to the main state, and sending a reset signal to the first core to enable the first core to be reset; and if the second core is in the active state, monitoring whether the second group of CAN buses are alive according to the zone bit of the bus register, if so, continuing to monitor, otherwise, sending a second scheduling signal to the first core to enable the first core to be switched from the standby state to the active state, and sending a reset signal to the second core to enable the second core to be reset.

5. The vehicle control unit of claim 1, further comprising: the watchdog module is internally provided with a timer; the counting value of the timer is cleared according to a dog feeding signal periodically sent by the core in the main state, and the third core judges whether the core in the main state is in failure according to whether the counting value of the timer overflows or not.

6. The vehicle control unit of claim 5, wherein the first core is further configured to: when a second scheduling signal is received, acquiring the calculation task data of a second core from the shared memory;

the second core is further to: when a first scheduling signal is received, acquiring computing task data of a first core from a shared memory;

the computing task data includes real-time task progress and corresponding variable values.

7. The vehicle control unit of claim 4, wherein the first core is further configured to: after the reset is finished, confirming whether the second core is in the main state, if so, entering a standby state;

the second core is further to: and after the reset is finished, confirming whether the first core is in the active state, and if so, entering the standby state.

8. The vehicle control unit of claim 1, wherein the first set of CAN buses comprises a 4-way CAN bus and the second set of CAN buses comprises a 4-way CAN bus.

9. The operation method of the vehicle control unit is characterized in that the vehicle control unit comprises a first core, a second core and a third core, wherein when any one of the first core and the second core is in a main state, the other one is in a standby state; when the first core is in the active state, the first core communicates with the node equipment through the first group of CAN buses, and when the first core is in the standby state, the first core processes the calculation tasks distributed by the second core or keeps a suspended state; the second core communicates with the node equipment through a second group of CAN buses when in the active state, and processes the calculation tasks distributed by the first core or keeps the suspended state when in the standby state; the method is applied to a third core, and comprises the following steps:

monitoring the states of the first core, the second core and the node device;

and sending a corresponding scheduling signal to the first core or the second core according to the state.

10. An automobile, characterized by comprising the vehicle control unit according to any one of claims 1 to 8.