Integrated controller

Abstract

An integrated controller 1 comprises an RT core 10 and an AP core 20. At least one function from among a basic travel function and a required-for-activation function of a vehicle is provided to the RT core 10, and at least some functions from among vehicle functions that are different from the basic travel function and the required-for-activation function are provided to the AP core 20.

Description

Integrated Controller

[0001] The present invention relates to an integrated controller.

[0002] Conventionally, an in-vehicle network system in which an in-vehicle control device and a plurality of ECUs are connected to a network bus compliant with the CAN communication policy is known. For example, in the in-vehicle network system described in Patent Document 1, a plurality of ECUs are connected to communication buses corresponding to the systems (control system, body system, safety system, information system, etc.) to which they belong, respectively forming an in-vehicle network.

[0003] Japanese Patent Application Laid-Open No. 2019-159661

[0004] In the in-vehicle network system described in Patent Document 1, the processing of various functions of the vehicle is executed by a plurality of ECUs. When attempting to aggregate and arrange the functions processed by the plurality of ECUs in the in-vehicle control device, a microcomputer with high processing power is used in the in-vehicle control device. However, if the startup time of the microcomputer becomes long by increasing the processing power of the microcomputer, there is a problem that the responsiveness when starting the vehicle decreases.

[0005] The problem to be solved by the present invention is to provide an integrated controller with improved responsiveness when starting a vehicle.

[0006] The present invention includes an RT core and an AP core, and solves the above problem by arranging at least one of the basic driving functions and startup necessary functions of the vehicle in the RT core, and arranging at least some of the vehicle functions different from the basic driving functions and startup necessary functions in the AP core.

[0007] According to the present invention, the responsiveness when starting a vehicle can be improved.

[0008] FIG. 1 is a schematic configuration diagram of an integrated controller according to the present embodiment and a diagram for explaining a processing sequence of vehicle functions. FIG. 2 is a schematic configuration diagram of an integrated controller according to the present embodiment and a diagram for explaining a processing sequence of vehicle functions in a modified example.

[0009] Hereinafter, embodiments of the integrated controller according to the present invention will be described with reference to the drawings.

[0010] Figure 1 is a schematic diagram illustrating the configuration of the integrated controller 1 according to this embodiment, and a diagram illustrating the processing sequence of vehicle functions. The integrated controller 1 is mounted on a vehicle and executes task processing included in multiple vehicle functions. The vehicle is a hybrid vehicle or electric vehicle equipped with an engine and a motor. The integrated controller 1 may also be mounted on a vehicle that obtains power from an engine (ICE vehicle).

[0011] A vehicle has multiple control groups, each divided according to its basic configuration; these control groups are also called domains. Domains include the vehicle drivetrain domain, the vehicle driving assistance system domain, the body domain, the multimedia domain, the powertrain domain which controls the engine, etc., and the chassis domain which controls the steering mechanism, etc. Each domain includes an ECU as a control unit; for example, the vehicle drivetrain domain has a VCM (Vehicle Control Module), and the vehicle driving assistance system domain has an ADCU (Assisted Driving Control Unit). The ECUs belonging to each domain are connected by a vehicle communication network such as CAN.

[0012] Conventional vehicle network systems have numerous ECUs connected to them, and these ECUs can communicate with each other via gateways that have relay functions. Therefore, in conventional vehicle network systems, vehicle functions are distributed and located across each ECU.

[0013] In this embodiment, in order to consolidate multiple vehicle functions into the integrated controller 1, the integrated controller 1 has multiple cores, and the vehicle functions are arranged on multiple cores 11-13 and 21-24. The vehicle functions include functions that should be started in a short time, functions that should be executed by a processor with high processing power, and functions necessary for starting the vehicle, depending on the content of the function and the processing load of the task processing. For this reason, the integrated controller 1 is equipped with a real-time core (hereinafter also referred to as "RT core") 10 as a core with a fast startup time, and an application core (hereinafter also referred to as "AP core") 20 as a core with high processing power.

[0014] The RT core 10 includes multiple cores 11 to 13, and the AP core 20 includes multiple cores 21 to 24. Cores 11 to 13 and cores 21 to 24 are control units that process programs (software), such as microcontrollers or processors.

[0015] Furthermore, the RT core 10 and AP core 20 have memory for storing programs, etc., not limited to the multiple cores 11-13 and cores 21-24. The memory may be built into each of the multiple cores 11-13 and cores 21-24, or it may be built into the RT core 10 and AP core 20, allowing access from multiple cores. The RT core 10 and AP core 20 also have a communication network connecting each of the multiple cores 11-13 and cores 21-24 so that commands can be sent and received between each core. The communication network can also communicate between cores 11-13 and cores 21-24.

[0016] The RT core 10 is driven by a processing sequence that completes task processing included in the vehicle functions within a predetermined cycle. Vehicle functions are functions installed in the vehicle, such as powertrain control functions, chassis system control functions, body system control functions, and communication system control functions. As an example, task processing included in the powertrain control functions corresponds to the processing sequence executed by the core when controlling the torque of the motor. Task processing is executed by each of the multiple cores 11 to 13 and cores 21 to 24.

[0017] When RT core 10 performs a task, such as controlling torque to a predetermined value, it completes the task within a predetermined period (for example, a predetermined period of several tens to 100 ms). Furthermore, in RT 10, if cores 11 to 13 are executing one task within a predetermined period, they will not execute other tasks within the same core and period. For example, if one of the multiple cores 12 is executing a task that controls torque to a predetermined value, and a command to control the torque to a different value is input to the same core 12, core 12 will complete the currently executing task within the predetermined period and execute the other task (the task of setting the torque to a different value) after the predetermined period has elapsed. In other words, cores 11 to 13 execute task processing according to an arbitration rule that the currently executing task processing will be completed within a predetermined period, and other task processing will not be executed while a task processing task is in progress.

[0018] The AP core 20 is not required to complete task processing within a predetermined cycle. For example, when a vehicle calculates a route to its destination, it obtains real-time information such as road congestion from a server to provide optimal route guidance. Obtaining information from a server is performed as a task process included in the functions of the vehicle communication system (CCS). For example, in AP 20, core 22 communicates with a server and executes task processing related to data acquisition. Since core 22 has no periodic limit on terminating task processing, the timing of task completion varies depending on the processing time of the task. In other words, the processing cycle of task processing in AP core 20 is random. Also, for example, if a command to execute another task process is input while core 22 is executing task processing related to data acquisition via external communication, it will select which task process to execute according to the processing load of the competing task processes. For example, if the load of the data acquisition task processing is smaller than the load of the input task processing, core 22 will interrupt the data acquisition task processing or slow down the processing speed to prioritize the input task processing. In other words, if a core 22 included in AP20 is executing a task and an interrupt command for another task is input to the same core 22, the core 22 will execute the other task if the processing load (computational load) of the other task is greater than the processing load of the task currently being executed. That is, the AP core 20 does not have a predetermined order for executing tasks, and in the event of a task conflict, the AP core 20 will execute the task with the highest priority. The priority may be determined according to the processing load of the task, or it may be pre-set by the system according to the type of task.

[0019] The cores 21-24 included in the AP core 20 are higher processing power cores compared to the cores 11-13 included in the RT core 10. Therefore, the AP core 20 can perform processing-intensive tasks such as image processing compared to the RT 10. Also, because the AP core 20 uses the higher processing power cores 21-24, each core 21-24 included in the AP core 20 can determine priority for conflicting task processing and execute conflicting task processing in parallel. On the other hand, the RT core 10 uses cores 11-13 with lower processing power than the AP core 20, so the RT core 10 simplifies the task processing arbitration rules and executes task processing with the cores 11-13 with reduced processing power. Furthermore, cores 11-13 do not process conflicting task processing in parallel, but instead execute task processing so that one task processing is completed within a predetermined cycle.

[0020] As described above, the AP core 20 uses a core with high processing power and can execute demanding tasks, but its startup speed is slower than that of the RT core 10. On the other hand, the RT core 10 uses a core with lower processing power, so its startup speed is faster than that of the AP core 20, and the RT core 10 can ensure real-time performance.

[0021] Furthermore, the amount of software processed by the RT core 10 and the amount of software processed by the AP core 20 are small. Cores 11-13 and 21-24 execute task processing by unpacking the software stored in memory. Cores 11-13 can unpack small-capacity software quickly, thus further shortening the startup time of the RT core 10.

[0022] Cores 11-13 and 21-24 are grouped in predetermined numbers, and vehicle functions are assigned to the grouped cores 11-13 and 21-24, respectively. Note that the multiple cores included in RT core 10 and AP core 20 may be grouped in units of cores corresponding to the processing load of task processing, but they do not necessarily have to be grouped. Of the multiple vehicle functions, the basic driving functions and the startup functions necessary for starting the vehicle are assigned to RT core 10. The basic driving functions include at least the basic functions necessary for driving the vehicle, such as "driving, turning, and stopping" (hereinafter also referred to as "driving, turning, and stopping functions"). Note that the basic driving functions may also include driver assistance functions (such as AEB). Startup functions are functions that should operate in order for the vehicle to move from a parked state to a running state. For example, if the vehicle has a function to detect the approach of a user and a function to unlock the doors when the approach of a user is detected, these functions become startup functions.

[0023] Furthermore, at least some of the vehicle functions that are different from the basic driving functions and startup requirements are located in the AP core 20. Examples of functions located in the AP core 20 include autonomous driving (AD), CCS, road surface detection, facial recognition, voice recognition, and gesture recognition. Alternatively, all of the other vehicle functions that are different from the basic driving functions and startup requirements may be located in the AP core 20, or some of the vehicle functions that are different from the basic driving functions and startup requirements may be located in the AP 20 and the other functions may be located in the RT core 10.

[0024] In Figure 1, the RT core 10 is configured with an AEB 31, a driving / turning / stopping function 32, a proximity detection function 33, and a door lock release function 34, as examples of basic driving functions and startup-required functions. In addition, the AP core 20 is configured with an AD 41, a CCS 42, a road surface detection function 43, and a facial recognition function 44, as examples of other vehicle functions besides basic driving functions and startup-required functions.

[0025] The AEB 31 is located on the core 11, the driving / turning / stopping function 32 is located on the core 12, and the proximity detection function 33 and the door lock release function 34 are located on the core 13.

[0026] The AEB 31 detects obstacles ahead and activates the emergency brake. Task processing included in basic driving functions such as the AEB 31 or the driving / turning / stopping function 32 requires real-time performance. For example, in a scenario where an obstacle ahead is detected and the emergency brake is activated while the vehicle is in motion, the AEB 31 needs to be activated before the vehicle starts moving. Also, while the vehicle is in motion, the AEB 31 needs to execute task processing such as detecting obstacles ahead in a short amount of time. In this embodiment, since the AEB 31 is located on the core 11, the time it takes for the AEB 31 to be activated after the vehicle starts can be shortened, and the software can be deployed quickly when executing task processing. As a result, the functions of the AEB 31 can be operated in a short amount of time after the vehicle starts.

[0027] For example, after a user gets into the vehicle and presses the power switch (also called the ignition switch or main switch), the vehicle goes through a starting state before becoming drivable. However, the time spent in the starting state (starting time) should be shortened. The driving / turning / stopping function 32 operates in response to the power switch ON command. After receiving the trigger input, the core 12 deploys the software to activate the driving / turning / stopping function 32. In this embodiment, since the driving / turning / stopping function 32 is located in the core 12, the time from when the vehicle starts until the driving / turning / stopping function 32 is activated can be shortened, and the software can be deployed faster when executing task processing. This allows for faster vehicle startup.

[0028] The vehicle is equipped with a keyless entry system. In the keyless entry system, the key and the vehicle are pre-associated, and when a user with the key approaches the vehicle, the proximity detection function 33 receives the signal emitted by the key and detects the user's approach. Since the proximity detection function 33 needs to operate when the vehicle is parked, the core 13 remains active while the vehicle is parked. The door lock release function 34 releases the door lock mechanism in conjunction with the user detection by the proximity detection function 33. If the core 13 is stopped (or in sleep mode) when the proximity detection function 33 detects a user, the core 13 cannot immediately execute the task processing included in the door lock release function 34 and must wait for the core 13 to start up, resulting in a delay from user detection to door lock release. Therefore, in this embodiment, the core 13 where the door lock release function 34 is located also remains active while the vehicle is parked. Furthermore, in order to shorten the vehicle startup time, it is necessary to shorten the processing time from trigger input to function operation in the proximity detection function 33 and the door lock release function 34. Therefore, in this embodiment, the proximity detection function 33 and the door lock release function 34 are located in the core 13 included in the RT core 10.

[0029] Furthermore, the RT core 10 may be equipped with other vehicle functions, such as a power generation function, in addition to the AEB 31, driving / stopping function 32, proximity detection function 33, and door lock release function 34. The power generation function supplies operating power to cores 11-13 and 21-24 based on the power from the onboard battery. For example, if the power generation function is located in core 13, when the vehicle is parked, core 13 performs task processing to supply power to the other cores 13 equipped with the proximity detection function 33 and door lock release function 34, thereby maintaining the running state of core 13.

[0030] AD41 is located in core 21, CCS42 is located in core 22, road surface detection function 43 is located in core 23, and facial recognition function 44 is located in core 24. AD41 is an autonomous driving function, which, for example, allows the system to perform accelerator, brake, and steering operations while driving on a highway. For example, the navigation system determines the vehicle's current position and sets a driving route to the destination. When the vehicle's current position approaches a highway on the driving route, AD41 is activated and performs autonomous vehicle control.

[0031] The CCS 42 is a function that communicates with external systems such as servers. The CCS 42 is activated while the vehicle is in motion and communicates with external systems in response to user operation or system requests. The road surface detection function 43 detects the road surface condition based on images captured by a camera that photographs the area in front of the vehicle, and adjusts the responsiveness to steering input and the amount of brake operation according to the road surface condition. The facial recognition function 44 acquires images captured by cameras that photograph the interior or exterior of the vehicle, performs image processing on the captured images, and authenticates the faces of users that have been registered in advance. The authentication results from the facial recognition function 44 are used, for example, in a driver monitoring system (a system that detects drowsiness or distraction and issues an alarm) or an IVI (in-vehicle infotainment) system. For example, an IVI (in-vehicle infotainment) system manages entertainment apps and map apps according to the user's preferences, and if a registered user is detected from the authentication results of the facial recognition function 44, applications tailored to the detected user's preferences are displayed on the in-vehicle display.

[0032] Since AD41 is a function used after the vehicle starts moving, it only needs to be activated after the vehicle starts. Furthermore, CCS42, road surface detection function 43, and facial recognition function 44 involve processing high-load tasks. Therefore, AD41, CCS42, road surface detection function 43, and facial recognition function 44 are located on the AP core 20, which has high processing power.

[0033] Next, the processing sequence of vehicle functions will be explained with reference to Figure 1. In Figure 1, "Parked" indicates the vehicle is parked, "Approaching" indicates the user is approaching the vehicle, and "Boarding" indicates the user is boarding the vehicle. "Started" indicates the vehicle is started (or, in the case of an ICE vehicle, the engine is starting), "Normal Driving" indicates the vehicle is driving on a regular road, and "High-Speed ​​Driving" indicates the vehicle is driving on a highway. Furthermore, the state of the vehicle or user is assumed to have changed in the order of "Parked," "Approaching," "Boarding," "Started," "Normal Driving," and "High-Speed ​​Driving."

[0034] When the vehicle is in the "parked" state, core 13 is in the activated state, while the other cores 11, 12, 21-24 are in the deactivated state. When core 13 is activated, the proximity detection function 33 and the door lock release function 34 are enabled, and core 13 detects the presence or absence of a trigger input (step S1). In other words, core 13, which is equipped with the functions that need to be activated, maintains the activated state while the vehicle is parked. When the vehicle is in the "approaching" state, core 13 uses the signal from the key owned by the approaching user as a trigger to execute a task process to detect the user (step S2). When core 13 detects the user, it releases the door lock mechanism. When core 13 detects the user, it outputs an activation command to cores 22 and 24 (step S3). Cores 22 and 24 start task processing to move from the deactivated state to the activated state (step S4).

[0035] When a user gets into the vehicle and presses the brake pedal, turning on the vehicle's power switch changes the vehicle's status to "occupied." Core 13 receives the power switch ON command and recognizes that there is an intention to start the vehicle (step S5). If Core 13 recognizes the intention to start the vehicle, it outputs a start command to Cores 12 and 23 (step S6). Core 23 starts task processing to change the vehicle from a stopped state to an started state (step S7). Also, when the vehicle's status becomes "occupied," Core 24 is in an active state and the facial recognition function 44 is enabled. When a user gets into the vehicle, Core 24 executes the task processing included in the facial recognition function 44 and authenticates the user's face (step S8).

[0036] Furthermore, when the vehicle status becomes "started," the core 12 is in an activated state, and the drive-turn-stop function 32 is enabled. The vehicle start operation is completed (step S9). When the core 12 enters the activated state, it outputs a start command to the core 11 (step S10). The core 11 starts task processing to change from the stopped state to the activated state (step S11).

[0037] When the vehicle's current position approaches a highway on the driving route, the core 21 switches from a stopped state to an active state, and the AD 41 becomes active (step S12). On the other hand, while the vehicle is in motion, the proximity detection function 33 and the door lock release function 34 are not used, so the core 13 switches from an active state to a stopped state, and the proximity detection function 33 and the door lock release function 34 become inactive (step S13). In other words, when the vehicle is in a state such as "normal driving" or "highway driving," or when the vehicle is parked, the proximity detection function 33 and the door lock release function 34 and the AD 41 have an exclusive relationship. That is, when the vehicle is parked, the proximity detection function 33 and the door lock release function 34 are active, and the AD 41 is inactive. Also, when the vehicle is in motion, the AD 41 is active, and the proximity detection function 33 and the door lock release function 34 are inactive. Furthermore, the operating states of core 13 and core 21 are mutually exclusive depending on the vehicle's driving scene; when core 13 is running, core 21 is stopped, and when core 21 is running, core 13 is stopped.

[0038] As described above, in this embodiment, the integrated controller 1 comprises an RT core 10 and an AP core 20. At least one of the basic driving functions and startup-required functions of the vehicle is located in the RT core 10, and at least some of the vehicle functions that are different from the basic driving functions and startup-required functions are located in the AP core 20. This improves the responsiveness when starting the vehicle.

[0039] Furthermore, in this embodiment, the software capacity processed by the RT core 10 is smaller than the software capacity processed by the AP core 20. This shortens the startup time of the RT core 10 and improves responsiveness when starting the vehicle.

[0040] Furthermore, in this embodiment, if the operating state of one core 13 included in the RT core 10 and the operating state of another core 21 included in the AP core 20 are mutually exclusive depending on the vehicle's driving scene, then when one of the cores 13 and 21 is in an activated state, the other core 13 and 21 is in a stopped state. As a result, if there is a relationship where one of the vehicle's functions is enabled and the other function is not used, the cores 13 and 21 that house the unused function will be in a stopped state. This reduces the power consumption of the cores 13 and 21.

[0041] As a modification of this embodiment, the startup-required functions may be located in the AP core 20. The core on which the startup-required functions are located maintains an activated state while the vehicle is parked. For example, the processing sequence when the facial recognition function 44 is a startup-required function will be described. Figure 2 is a schematic diagram of the configuration of the integrated controller 1 according to a modification of this embodiment, and a diagram for explaining the processing sequence of vehicle functions.

[0042] In the modified version, the starting conditions for starting the vehicle include facial recognition in addition to recognition of the intention to start. The user takes the key associated with the vehicle and gets into the vehicle. The facial recognition function 44 detects a face from the image captured by the in-vehicle camera, and based on the detected facial feature information, compares it with pre-registered data to authenticate that it is the facial features of a registered user. Based on the authentication result, it is confirmed that the detected user is a registered user, and when the user turns on the vehicle's power switch while pressing the brake pedal, the vehicle starts.

[0043] The facial recognition function 44 is located in core 24 of the AP core 20 because it includes processing tasks that require a high processing load, such as image processing. Furthermore, in order for the facial recognition function 44 to perform facial recognition before the vehicle starts, the RT core 10, where the power generation function is located, supplies power to core 24 while the vehicle is parked. While the vehicle is parked, core 24 is activated and can detect the face of a user approaching the vehicle. The facial recognition function 44 may also recognize the face of a user who is inside the vehicle.

[0044] Next, the processing sequence of the vehicle functions will be described with reference to FIG. 2. When in the "parked" state, cores 13 and 22 are in the activated state, and the other cores 11, 12, 21, 23, and 24 are in the stopped state. When cores 13 and 24 are in the activated state, the proximity detection function 33, the door unlock function 34, and the face recognition function 44 become effective, and cores 13 and 24 detect the presence or absence of a trigger input (step S21). When in the "proximity" state, core 13 executes a task process for detecting a user using the start signal of the key owned by the approaching user as a trigger (step S22). When core 13 detects a user, it releases the door lock mechanism. When core 13 detects a user, it outputs a start command to core 22 (step S23). Core 22 starts a task process to change from the stopped state to the activated state (step S24). Also, core 24 executes a task process for authenticating the face of the approaching user (step S25). When core 24 confirms from the authentication result of the user's face recognition that the approaching user is a registered user, it outputs a start command to core 12 (step S26).

[0045] Core 13 acquires an on command of the power switch and recognizes that there is an intention to start (step S27). When core 13 recognizes the intention to start, it outputs a start command to cores 12 and 23 (step S28). Core 23 starts a task process to change from the stopped state to the activated state (step S29). When core 12 receives a start command from each of core 13 and core 24, it starts a task process to change from the stopped state to the activated state (step S30).

[0046] When the state of the vehicle becomes "started", core 12 is in the activated state and the turning and stopping function 32 is effective. The starting operation of the vehicle is completed (step S31). When core 12 becomes in the activated state, it outputs a start command to core 11 (step S32). Core 11 starts a task process to change from the stopped state to the activated state (step S33). The processing sequences of "normal driving" and "high-speed driving" are the same as above and will not be described.

[0047] In a modification of the present embodiment, among the plurality of cores 21 to 24 included in the AP core 20, the core 24 in which the functions necessary for startup are arranged maintains the startup state while the vehicle is parked. Thereby, the responsiveness when starting the vehicle can be enhanced.

[0048] In the present embodiment, the processing sequences shown in FIG. 1 or FIG. 2 do not necessarily have to include all of steps S1 to S11 and S21 to 31, and some steps may be omitted. For example, when the road surface detection function 43 is not enabled after the start intention is recognized, a part of step S6 and step S7 may be omitted. Also, the processing order of each step in the processing sequence may be changed as appropriate.

[0049] Note that the RT core 10 in the present embodiment corresponds to the "first core" of the present invention, and the AP core 20 corresponds to the "second core" of the present invention.

[0050] 1 Integrated controller 10 Real-time (RT) core 11 to 13 Cores 20 Application (AP) core 21 to 24 Cores

Claims

1. An integrated controller mounted on a vehicle, comprising: a first core that completes task processing included in the vehicle's functions within a predetermined period; and a second core that does not need to complete the task processing within the predetermined period and has higher processing capacity than the first core, wherein at least one of the basic driving functions of the vehicle and the startup functions necessary for starting the vehicle is located on the first core, and at least some of the vehicle functions that are different from the basic driving functions and the startup functions are located on the second core.

2. An integrated controller according to claim 1, wherein the capacity of the software processed by the first core to perform the task processing is smaller than the capacity of the software processed by the second core.

3. An integrated controller according to claim 1 or 2, wherein, among a plurality of cores included in the second core, the core on which the startup necessary function is located maintains an started state while the vehicle is parked.

4. An integrated controller according to any one of claims 1 to 3, wherein, when the operating state of one core included in the first core and the operating state of another core included in the second core are mutually exclusive according to the driving scene of the vehicle, the integrated controller wherein when one of the first core and the other core is in an activated state, the other core is in a stopped state.

Images