JP7468308B2 - On-vehicle ECU, program, and information processing method - Google Patents

Description

The present invention relates to an in-vehicle ECU, a program, and an information processing method.

There is known an electronic control device that is mounted on a vehicle and processes information related to the control of devices mounted on the vehicle, external communication, and driving control such as autonomous driving (for example, Patent Document 1). The electronic control device of Patent Document 1 is equipped with a multi-core CPU having multiple cores, and multiple program systems run on the multi-core CPU. The electronic control device is configured to change the cores assigned to each program system in the operating system of each program system according to changes in the system state.

JP 2019-179397 A

However, the electronic control device in Patent Document 1 has a problem in that it does not take into consideration the allocation of hardware resources such as a CPU core to other task processes upon completion of the currently executed task process.

This disclosure provides an in-vehicle ECU etc. that can efficiently allocate hardware resources such as a CPU to other programs depending on the state of the executed program.

An on-board ECU according to one aspect of the present disclosure is an on-board ECU mounted on a vehicle, and includes a control unit that executes multiple programs, and a storage unit that stores a virtualized operating system that is activated by the control unit. Multiple virtual environments are generated by activating the virtualized operating system, and the programs operate in the virtual environments. A management unit that manages the virtualized operating system allocates the allocated time period of the control unit that was allocated to one of the virtual environments to another virtual environment based on a task completion notification in a program executed in one of the multiple virtual environments.

According to one aspect of the present disclosure, an in-vehicle ECU or the like is provided that can efficiently allocate hardware resources such as a CPU to other programs depending on the state of the executed program.

1 is a schematic diagram illustrating a configuration of an in-vehicle system including an in-vehicle ECU according to a first embodiment; FIG. 2 is a block diagram illustrating a physical configuration of an in-vehicle ECU. FIG. 2 is a block diagram illustrating a logical configuration (virtual ECU) of an in-vehicle ECU. FIG. 2 is a functional block diagram illustrating functional units in a virtual ECU. FIG. 11 is an explanatory diagram illustrating an example of an allocation time table (allocation time information); FIG. 11 is an explanatory diagram regarding a time period allocated to a control unit for a virtual environment. 4 is a flowchart illustrating the processing of a control unit (virtual control unit) of an in-vehicle ECU (virtual ECU). FIG. 11 is an explanatory diagram illustrating an example of an allocation time table (allocation time information) according to the second embodiment. FIG. 11 is an explanatory diagram regarding a time period allocated to a control unit for a virtual environment.

[Description of the embodiments of the present invention]
First, embodiments of the present disclosure will be listed and described. In addition, at least some of the embodiments described below may be arbitrarily combined.

(1) An on-board ECU (Electronic Control Unit) according to one embodiment of the present disclosure is an on-board ECU mounted on a vehicle, and includes a control unit that executes multiple programs, and a storage unit that stores a virtualized operating system that is activated by the control unit. Multiple virtual environments are generated by activating the virtualized operating system, and the programs operate in the virtual environments. A management unit that manages the virtualized operating system allocates the allocated time period of the control unit that was allocated to one of the virtual environments to another virtual environment based on a task completion notification in a program executed in one of the multiple virtual environments.

In this embodiment, a single or multiple tasks (processing) are executed based on the contents defined (coded) in the program. The tasks are executed (started) periodically, that is, the tasks are started periodically, and are completed (ended) by performing information processing based on the predetermined contents. When the process generated to execute the program completes the task, it outputs a task completion notification to the management unit of the virtualized operating system. The management unit corresponds to the process generated to execute the management program for managing the virtual environment generated by the virtualized operating system. For example, when a hypervisor-type virtualized operating system is used, the virtual environment that is the operating environment of the program that controls the in-vehicle equipment, etc. corresponds to the virtual ECU. Therefore, by using the virtualized operating system, multiple virtual ECUs can be configured in the in-vehicle ECU according to the number or type of programs to be executed. In addition, the virtual environment that is the operating environment of the management program that manages the virtual environment may also correspond to a virtual ECU. In such an in-vehicle ECU in which multiple virtual environments (virtual ECUs) are configured, when the management unit receives a task completion notification from a program executed in the virtual environment, it assigns the assigned time zone of the control unit that was assigned to the virtual environment to another virtual environment. That is, the management unit performs a process to reschedule the time slots allocated to the control unit for each virtual environment based on the task completion notification. This allows the free time after a task in the program is completed to be allocated to another virtual environment that executes a program other than the program in question, and allows the execution of another program that uses the other virtual environment as its operating environment. Therefore, by effectively utilizing the free time after a task in a program is completed, it is possible to perform scheduling that efficiently allocates hardware resources such as the control unit shared by multiple virtual environments, and improve the effective utilization rate (CPU utilization rate) of the control unit (CPU).

(2) In one embodiment of the in-vehicle ECU of the present disclosure, the memory unit stores allocation time information that defines the allocation time zone of the control unit for the multiple virtual environments, and the allocation time information includes an allocation time zone of one of the virtual environments and an allocation time zone of a virtual environment that is next to the one of the virtual environments, and the allocation time zone allocated to the other virtual environment is from after the management unit obtains a task completion notification to the start of the allocation time zone of the next virtual environment.

In this embodiment, the allocation time information (allocation time table) that defines the allocation time of the control unit for multiple virtual environments is stored in the storage unit, and the management unit of the virtualized operating system allocates the use time of the control unit to each virtual environment by referring to the allocation time information. As a result, even if the control unit is configured with a single CPU with a single core, the processing power of the core can be time-shared (time sharing) to ensure processing time for each virtual environment. Even if the control unit is configured with a single CPU or multiple CPUs with a multi-core, similar time division can be performed for each core to ensure processing time for each virtual environment. In the allocation time information, the allocation time of one virtual environment and the allocation time of the next virtual environment for that one virtual environment are defined, and the allocation time of the other virtual environment is set to be from after the management unit obtains a task completion notification to the start of the allocation time of the next virtual environment. Therefore, the end of the allocation time of the other virtual environment is determined (constrained) according to the start of the allocation time of the next virtual environment. This allows the control unit's usage time to be allocated to the allocated time slot of the next-highest virtual environment based on the allocated time slot of the next-highest virtual environment, without being affected by the allocated time slots of other virtual environments. Even if the control unit's usage time is allocated to another virtual environment based on a task completion notification, the control unit's usage time is appropriately allocated to each virtual environment as predetermined in the allocated time information, including the allocated time slot of the next-highest virtual environment, without changing the scheduling based on the allocated time information. This allows efficient execution of programs that use that virtual environment as their operating environment.

(3) In one embodiment of the in-vehicle ECU of the present disclosure, the management unit calculates the remaining time from the time when the task completion notification is obtained to the start of the allocated time zone of the next virtual environment, and if the remaining time is equal to or greater than a preset time for a program that operates in the other virtual environment, the allocated time zone of the control unit that was allocated to one of the virtual environments in the previous period is assigned to the other virtual environment.

In this embodiment, when the management unit receives a task completion notification from a program executed in one of the virtual environments, if the remaining time from the time of the notification to the start of the allocated time slot for the next virtual environment is equal to or greater than a preset time for a program that uses the other virtual environment as its operating environment, the management unit allocates the control unit's usage time to the other virtual environment. Therefore, appropriate allocation to the other virtual environment can be made according to the calculated remaining time.

(4) In one embodiment of the in-vehicle ECU of the present disclosure, the management unit calculates the remaining time from the time when the task completion notification is obtained to the start of the allocated time zone of the next virtual environment, and if the remaining time is less than a preset time for a program that operates in the other virtual environment, the control unit continues to allocate the allocated time zone of the control unit that was allocated to one of the virtual environments to the one of the virtual environments without allocating it to the other virtual environment.

In this embodiment, if the calculated remaining time is less than a preset time for a program that uses another virtual environment as its operating environment, the management unit continues the allocation to one of the virtual environments without allocating the control unit's allocated time zone (usage time) to the other virtual environment. The preset time for a program that uses a virtual environment as its operating environment is, for example, the time estimated to be required to process a task in that program (estimated processing time). If the remaining time is less than the preset time, by continuing the allocation to one of the virtual environments without allocating to the other virtual environment, it is possible to reduce overhead caused by the management unit performing unnecessary processing.

(5) In an embodiment of the in-vehicle ECU of the present disclosure, the allocation period based on the allocated time zone for each virtual environment defined in the allocated time information is shorter than the start period of a task in a program executed in any of the virtual environments.

In this embodiment, the allocation period of the virtual environment determined by the allocation time information is a period (time) that is shorter than the start period of the task in the program that uses that virtual environment as its operating environment. Therefore, when a control unit is assigned to a virtual environment, it is expected that a task in the program that uses that virtual environment as its operating environment will not be started. Even in such a case, based on the task completion notification, the management unit assigns the allocation time period of the control unit that was assigned to one of the virtual environments to the other virtual environment. This makes it possible to effectively utilize the free time of the control unit and improve the utilization rate (CPU utilization rate) of the control unit.

(6) In an embodiment of the in-vehicle ECU of the present disclosure, the priority of a program that operates in one of the virtual environments is higher than the priority of a program that operates in the other virtual environments, and the priority is determined based on the Automotive Safety Integrity Level (ASIL) of ISO26262.

In this embodiment, a program that uses one of the virtual environments as its operating environment is executed regularly based on the allocated time information, and a program that uses another virtual environment as its operating environment is executed using the free time after a task completion notification is issued by the program that uses one of the virtual environments. The task completion notification is not always issued during the allocated time period for one of the virtual environments, so the program that uses the other virtual environment as its operating environment is executed non-regularly based on the task completion notification. In contrast, the priority of a program that is executed regularly is higher than the priority of a program that is executed non-regularly, and the priority is determined based on the ASIL (Automotive Safety Integrity Level). Therefore, for example, by setting the programs that are executed regularly to be programs ranging from ASIL-D to ASIL-A levels and the programs that are executed non-regularly to be programs at the QM level, it is possible to allocate (schedule) the control unit in consideration of the functional safety required for each program, while improving the utilization rate (CPU utilization rate) of the control unit.

(7) A program according to one aspect of the present disclosure generates multiple virtual environments by starting a virtualized operating system stored in a memory unit of a computer that is mounted on a vehicle and executes multiple programs, sets the virtual environments as operating environments for executing the programs, and, based on a task completion notification in a program executed in one of the multiple virtual environments, assigns an assigned time zone of the control unit of the computer that was assigned to one of the virtual environments to another virtual environment.

In this embodiment, the computer can function as an in-vehicle ECU that can efficiently allocate hardware resources such as the CPU to other programs depending on the state of the executed program.

(8) An information processing method according to one aspect of the present disclosure generates multiple virtual environments by starting a virtualized operating system stored in a memory unit of a computer mounted on a vehicle and executing multiple programs, sets the virtual environments as operating environments for executing the programs, and, based on a task completion notification in a program executed in one of the multiple virtual environments, allocates an assigned time zone of the control unit of the computer that was assigned to one of the virtual environments to another virtual environment.

In this aspect, an information processing method can be provided that causes a computer to function as an in-vehicle ECU that can efficiently allocate hardware resources such as a CPU to other programs depending on the state of the executed program.

[Details of the embodiment of the present disclosure]
The present disclosure will be specifically described with reference to the drawings showing the embodiments. An in-vehicle ECU 2 according to an embodiment of the present disclosure will be described below with reference to the drawings. Note that the present disclosure is not limited to these examples, but is indicated by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.

(Embodiment 1)
Hereinafter, an embodiment will be described with reference to the drawings. Fig. 1 is a schematic diagram illustrating a configuration of an in-vehicle system S including an in-vehicle ECU 2 according to the first embodiment. Fig. 2 is a block diagram illustrating a physical configuration of the in-vehicle ECU 2. The in-vehicle system S includes a plurality of in-vehicle ECUs 2 mounted on a vehicle C and an in-vehicle device 3 connected to the in-vehicle ECUs 2.

The multiple on-board ECUs 2 may include an integrated on-board ECU 2 (integrated ECU) that controls the entire vehicle C, and individual on-board ECUs 2 (individual ECUs) that are communicatively connected to the integrated on-board ECU 2 and directly connected to the on-board device 3. The integrated on-board ECU 2 may be communicatively connected to an external server 100 that is connected to an external network such as the Internet via the external communication device 1.

In the illustrated embodiment, the integrated vehicle ECU 2 and multiple individual vehicle ECUs 2 are communicatively connected by an in-vehicle network 4 that forms a star-shaped network topology, and the integrated vehicle ECU 2 is located at the center of the star-shaped network topology. Furthermore, adjacent individual vehicle ECUs 2 may be connected to each other to form a loop-shaped network topology, enabling two-way communication and achieving redundancy.

Multiple individual vehicle ECUs 2 are arranged in various areas of the vehicle C, and actuators 30 such as illumination lamps and vehicle devices 3 such as sensors 31 are directly connected to them via a wire harness such as a serial cable (direct wire). The individual vehicle ECUs 2 acquire (receive) signals (input signals) output from sensors, for example, and transmit request signals generated based on the acquired input signals to the integrated vehicle ECU 2. The individual vehicle ECUs 2 control the operation of actuators 30 such as illumination lamps directly connected to their own ECU based on the control signals transmitted from the integrated vehicle ECU 2.

The individual vehicle ECU 2 may be a relay control ECU that functions as a gateway or an Ethernet switch or other vehicle relay device that relays communication between multiple vehicle devices 3 connected to the individual vehicle ECU 2, or communication between the vehicle device 3 and other vehicle ECUs 2. The individual vehicle ECU 2 may be a PLB (Power Lan Box) that functions as a power distribution device that distributes and relays power output from a power storage device and supplies it to the vehicle devices 3 connected to the ECU itself, in addition to relaying communication.

The integrated vehicle ECU 2 generates and outputs control signals to the individual vehicle devices 3 based on data from the vehicle devices 3 relayed via other vehicle ECUs 2, such as individual vehicle ECUs 2, and is a central control device such as a vehicle computer. The integrated vehicle ECU 2 generates a control signal for controlling the actuator 30 that is the target of the request signal based on information or data such as a request signal output (transmitted) from other vehicle ECUs 2, such as individual vehicle ECUs 2, and outputs (transmits) the generated control signal to the other vehicle ECUs 2. In this embodiment, the vehicle system S is configured by the integrated vehicle ECU 2 (integrated ECU) and the individual vehicle ECUs 2 (individual ECUs), but is not limited to this. The vehicle system S may be configured by a plurality of vehicle ECUs 2 connected peer-to-peer by a relay device such as a CAN (Controller Area Network) gateway or an Ethernet switch.

The in-vehicle device 3 includes various sensors 31 such as LiDAR (Light Detection and Ranging), light sensors, CMOS cameras, infrared sensors, etc., and actuators 30 such as switches such as door switches and lamp switches, lamps, door opening/closing devices, motor devices, etc.

The external server 100 is a computer such as a server connected to an external network such as the Internet or a public line network, and has a storage unit such as a RAM (Random Access Memory), a ROM (Read Only Memory), or a hard disk. The integrated on-board ECU 2 (integrated ECU) is communicatively connected to the external communication device 1, communicates with the external server 100 connected via the external network via the external communication device 1, and may relay communication between the external server 100 and other on-board ECUs 2 or on-board devices 3 mounted in the vehicle C.

The vehicle-external communication device 1 includes an external communication unit (not shown) and an input/output I/F (not shown) for communicating with an integrated vehicle-mounted ECU 2 (integrated ECU). The vehicle-external communication unit is a communication device for wireless communication using a mobile communication protocol such as 4G, LTE (Long Term Evolution/registered trademark), 5G, or WiFi, and transmits and receives data to and from an external server 100 via an antenna 11 connected to the vehicle-external communication unit. Communication between the vehicle-external communication device 1 and the external server 100 is performed via an external network N such as a public line network or the Internet. The input/output I/F 22 is a communication interface for, for example, serial communication with the vehicle-mounted ECU 2. The vehicle-external communication device 1 and the vehicle-mounted ECU 2 communicate with each other via the input/output I/F and a wire harness such as a serial cable connected to the input/output I/F. In this embodiment, the vehicle-external communication device 1 is a separate device from the vehicle-mounted ECU 2, and these devices are communicatively connected by the input/output I/F or the like, but is not limited thereto. The external vehicle communication device 1 may be built into the vehicle ECU 2 as one component of the vehicle ECU 2.

The in-vehicle ECU 2 (integrated EUC, individual ECU) includes a control unit 20, a memory unit 21, an input/output I/F 22, and an in-vehicle communication unit 23, and may further include a verification unit configured with an HSM (Hardware Security Module) or the like. The control unit 20 is configured with a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control processes and arithmetic processes by reading and executing control programs and data previously stored in the memory unit 21. The control unit 20 includes, for example, a single-core single CPU, a single-core multi-CPU, a multi-core single CPU, and a multi-core multi-CPU. The control unit 20 is not limited to only a software processing unit that performs software processing such as a CPU, and may include a hardware processing unit that performs various control processes and arithmetic processes by hardware processing such as an FPGA, an ASIC, or an SOC.

The storage unit 21 is configured with a volatile memory element such as a RAM (Random Access Memory), a non-volatile memory element such as a ROM (Read Only Memory), an EEPROM (Electrically Erasable Programmable ROM) or a flash memory, or a combination of these storage devices, and stores a control program and data to be referenced during processing in advance. The control program includes a plurality of programs (applications), such as a program (application) for controlling various in-vehicle devices 3, or a program (application) for performing target recognition for automated driving based on output data from a LiDAR or CMOS camera. Furthermore, the storage unit 21 of the in-vehicle ECU 2 stores a virtual operating system, such as a Hypervisor or VMware.

The input/output I/F 22 is a communication interface for, for example, serial communication, similar to the input/output I/F 22 of the external communication device 1. The in-vehicle ECU 2 is communicatively connected to the external communication device 1 via the input/output I/F 22 and a wire harness such as a serial cable.

The in-vehicle communication unit 23 is an input/output interface that uses a communication protocol such as CAN (Controller Area Network) or Ethernet (registered trademark), and the control unit 20 communicates with other in-vehicle ECUs 2 connected to the in-vehicle network 4 via the in-vehicle communication unit 23.

Figure 3 is a block diagram illustrating the logical configuration (virtual ECU) of the vehicle-mounted ECU 2. This is a block diagram illustrating the logical configuration of the vehicle-mounted ECU 2 in the illustration of this embodiment, and is an example of a hierarchical structure in which the hardware layer (physical base) of the control unit 20, etc. is the lowest layer, and the software layer of the programs executed in the virtual environment and the virtual environment management program, etc. is the highest layer.

As described above, the storage unit 21 of the in-vehicle ECU 2 stores a virtual operating system such as Hypervisor or VMware, and the control unit 20 of the in-vehicle ECU 2 can build multiple virtual environments (virtual ECUs) on the virtual operating system by starting up using the virtual operating system. Programs for controlling various in-vehicle devices 3 are executed using one of these multiple virtual environments as the operating environment. In other words, these programs are executed on one of the virtual environments (virtual ECUs). By executing a program in the virtual environment (virtual ECU), a single or multiple tasks are generated depending on the processing content of the program. The tasks execute processing units that are more finely divided or segmented.

The virtualization method may be a hypervisor method in which a virtual operating system directly accesses hardware resources such as the control unit 20 as shown in the present embodiment, or a host OS method in which an operating system such as Linux (registered trademark) is interposed between the virtual operating system and the hardware resources. Alternatively, a container-based virtual operating system may be used.

The in-vehicle ECU 2 started up using the virtual operating system can create multiple virtual environments using the functions of the virtual operating system, and hardware resources such as the control unit 20 of the in-vehicle ECU 2 are assigned to the multiple virtual environments. Each virtual environment to which these hardware resources are assigned includes a virtual control unit 20 (virtual control unit), memory unit 21 (virtual memory unit), and in-vehicle communication unit 23 (virtual in-vehicle communication unit), and functions as a virtual ECU 200.

A guest OS (Operating System) such as Ubuntu (registered trademark) is stored in each virtual memory unit of the virtual ECUs 200, and each virtual ECU 200 starts the guest OS and executes a program on the guest OS. The guest OS may be a different type of OS depending on each virtual ECU 200. As described above, the virtual memory unit is actually a storage area of the storage unit 21 assigned to each virtual ECU 200, so it goes without saying that the guest OS is also stored in the storage unit 21 in the same way as the virtual operating system. When using a container-based virtual operating system, a guest OS may be unnecessary, and a container (virtual environment) may be generated on the virtual operating system, and a program may be executed on the container (virtual environment).

The control unit 20 of the in-vehicle ECU 2, which is started using the virtual operating system, executes a program (virtual environment management program) that manages all virtual environments in one of the virtual environments (virtual ECUs 200) that have been created. In other words, the virtual ECU 200 that executes the virtual environment management program functions as a control panel for the virtual operating system, and corresponds to the management unit 210. Alternatively, the virtual operating system itself may include the function of the management unit 210.

The memory unit 21 stores an allocation time table 21A (allocation time information) described below, and the management unit 210 allocates (schedules) the usage time of the control unit 20 to each virtual environment (virtual ECU) based on the allocation time table 21A.

Figure 4 is a functional block diagram illustrating functional units in virtual ECU 200. Figure 5 is an explanatory diagram illustrating allocation time table 21A (allocation time information). The virtual control unit (control unit 20) of virtual ECU 200 functions as a task generation unit 201 and a task completion monitoring unit 202 by executing a program stored in the virtual memory unit (memory unit 21) of the virtual ECU 200.

The control unit 20 that executes the virtual operating system, or the virtual control unit (control unit 20) of the virtual ECU 200 for managing the virtual operating system, executes a virtual environment management program stored in the virtual memory unit (memory unit 21) to function as a control panel of the virtual operating system, and corresponds to the management unit 210 in this embodiment. The management unit 210 includes a remaining time derivation unit 211, a completion determination unit 212, and an allocation execution unit 213. When the control unit 20 is configured with a multi-core, for example, the core to which the usage time is assigned to the management unit 210 (control panel of the virtual operating system) and the core to which the usage time is assigned to the virtual environment (virtual ECU 200), which is the operating environment of the program for controlling the in-vehicle device 3, etc., may be different cores.

As shown in the figure in this embodiment, the virtual ECUs 200 to which the utilization time of the control unit 20 is periodically (regularly) allocated based on the allocation time table 21A are, for example, three (VM1, VM2, VM3). The management unit 210 continuously performs a process (scheduling) of allocating the utilization time of any of the cores constituting the control unit 20 to these virtual ECUs 200 (VM1, VM2, VM3) by referring to the allocation time information stored in, for example, the storage unit 21. As shown in the figure in this embodiment, the allocation time information referred to by the management unit 210 is stored in the storage unit 21 in table format (lookup table), for example, as the allocation time table 21A.

The allocation time table 21A includes, as management items, an item for the virtual ECU 200, an item for the allocation period, an item for the allocation time, an item for the program type, an item for the ASIL indicating the priority, an item for the task, an item for the start period of the task, and an item for the expected processing time of the task.

The Virtual ECU 200 item stores the name or identifier of the virtual ECU 200 that shares the same control unit 20 (core) by time sharing.

The allocation period field stores the allocation period in the virtual ECU 200, which is allocated periodically (steadily). In this embodiment, the actual number of the allocation period is stored in VM1, VM2, and VM3, and the actual number of the allocation period is not stored in VM4 (a null value indicating that no value is stored is stored). In other words, the virtual ECUs 200 (VM1, VM2, and VM3) in which the actual number of the allocation period is stored correspond to the virtual ECUs 200 (virtual environments) to which the usage time of the control unit 20 is allocated periodically (steadily).

A virtual ECU 200 (VM4) in which the actual number of the allocation period is not stored corresponds to a virtual ECU 200 (virtual environment) to which the use time of the control unit 20 is non-stationarily allocated. The item of allocation time stores the allocation time allocated to each virtual ECU 200 in the virtual ECU 200 to which the use time of the control unit 20 is periodically (stationarily) allocated. The sum of these allocation times corresponds to the allocation period.

The program type field stores the type of program executed in each corresponding virtual ECU 200 (virtual environment) (stored in the same record). The ASIL field stores the ASIL level as an index indicating the priority of the program to be executed. That is, the priority is determined based on the corresponding in-vehicle device 3 and the function of the program to be executed, and may be determined based on the ASIL (Automotive Safety Integrity Level) of ISO26262, for example. The ASIL level is classified into QM, ASIL-A, ASIL-B, ASIL-C, and ASIL-D. The QM level is normal quality control that does not require the application of functional safety according to ISO26262. At the levels from ASIL-A to D, the application of functional safety according to ISO26262 is required, and the functional safety requirements become stricter as the levels go from ASIL-A to ASIL-D. That is, the priority of the QM level can be considered to be the lowest, and the priority of the ASIL-D level can be considered to be the highest. In this priority, the priority (ASIL level) of the virtual ECU 200 (virtual environment) that is periodically (regularly) assigned is a higher priority (ASIL level) than the priority (ASIL level) of the virtual ECU 200 (virtual environment) that is non-regularly assigned. In this embodiment, the ASIL is used as an index indicating the priority of the program, but this is not limited to this. The priority of the program may be determined by a value (priority setting value) separate from the ASIL, and the priority setting value may be set individually and changeably by, for example, the user, administrator, or manufacturer of the in-vehicle system S.

The task item stores the name of the task generated by the corresponding program. The task start period item stores the start period of the corresponding task. Each task is executed (started) based on the start period. The allocation period of the virtual ECU 200 determined by the allocation time information is a period (time) shorter than the start period of the task in the program whose operating environment is the virtual ECU 200 (virtual environment). Therefore, when the control unit 20 (core) is assigned to any virtual ECU 200 (virtual environment), it is assumed that the task in the program whose operating environment is the virtual ECU 200 (virtual environment) will not be started. Even in such a case, based on a task completion notification described later, the management unit 210 can assign the assigned time period of the control unit 20 assigned to any virtual ECU 200 (virtual environment) to another virtual ECU 200 (virtual environment). In this embodiment, the allocation period of the virtual ECU 200 determined by the allocation time information is a period (time) that is shorter than the start period of a task in a program that uses the virtual ECU 200 (virtual environment) as its operating environment, but this is not limited to this, and the allocation period and the start period may be the same value (period).

The estimated processing time of a task stores the time required to generate and execute the corresponding task (estimated processing time/configuration setting value). The allocation time table 21A is not only referenced by the management unit 210, but is stored in the memory unit 21 so that it can be referenced by the virtual control units of all virtual ECUs 200, and may be stored, for example, in the virtual memory units of all virtual ECUs 200.

As shown in the diagram of this embodiment, currently, the usage time of the control unit 20, which is configured with, for example, a single core, is allocated to one virtual ECU 200 (VM1) among the virtual ECUs 200 that are periodically (regularly) allocated. The task generation unit 201 of the virtual ECU 200 (VM1) refers to, for example, the allocation time table 21A, and executes (launches) a task based on the start period defined for each task in its own virtual ECU 200 (VM1). The task generation unit 201 may generate a sub-process or a thread when executing (launching) the task.

The task completion monitoring unit 202 of the virtual ECU 200 (VM1) monitors the execution status of the generated task and determines whether the task is completed. The task completion monitoring unit 202 may determine that the task is completed by detecting that a sub-process or thread generated to execute (launch) the task has disappeared. Alternatively, the task completion monitoring unit 202 may determine that the task is completed when it receives a completion signal transmitted from a process for executing the task.

When the task completion monitoring unit 202 determines that the task is completed, it transmits an output request signal to the management unit 210, requesting the output of the remaining time obtained by subtracting the elapsed time from the start of the allocation to the present time from the allocated time allocated to its own virtual ECU 200. The task completion monitoring unit 202 acquires the remaining time calculated by the management unit 210 based on the output request signal.

The task completion monitoring unit 202, for example, refers to the allocated time table 21A to determine whether there is a task (other task) other than the most recently completed task that needs to be executed (started) within the remaining time. That is, the task completion monitoring unit 202 refers to the allocated time table 21A to calculate each of the next start times determined based on the start period of each of the single or multiple other tasks executed in its own virtual ECU 200 (VM1), and determines whether there is a task (existence or non-existence) whose calculated start time is included in the remaining time.

If there is a task whose start time falls within the remaining time, the task completion monitoring unit 202 does not output (send) a task completion notification to the management unit 210. In this case, the task whose start time falls within the remaining time is executed (launched) by the task generation unit 201. If there is no task whose start time falls within the remaining time, the task completion monitoring unit 202 outputs (sends) a task completion notification to the management unit 210.

As described above, the management unit 210 includes a remaining time derivation unit 211, a completion determination unit 212, and an allocation execution unit 213. In response to a request from a virtual ECU 200, the remaining time derivation unit 211 calculates the remaining time by subtracting the elapsed time from the start of allocation to the current time from the allocated time allocated to the virtual ECU 200 that sent the output request for the remaining time, and outputs (transmits) the calculated remaining time to the virtual ECU 200.

In response to a task completion notification output (transmitted) from the virtual ECU 200, the completion determination unit 212 determines whether the remaining time calculated by the remaining time derivation unit 211 is equal to or greater than the set time (configuration setting value) of a program that operates in another virtual environment (another virtual ECU 200 (VM4)). The completion determination unit 212 extracts the estimated processing time (program setting time: configuration setting value) of a task executed by a program of the virtual ECU 200 (VM4) to which the usage time of the control unit 20 is non-stationarily allocated, for example, by referring to the allocation time table 21A, and determines whether the remaining time is equal to or greater than the estimated processing time. If the remaining time is equal to or greater than the estimated processing time, the completion determination unit 212 outputs an allocation instruction signal indicating an allocation instruction to the allocation execution unit 213. If the remaining time is not equal to or greater than the estimated processing time, the completion determination unit 212 does not output an allocation instruction signal.

Based on the allocation instruction signal output from the completion determination unit 212, the allocation execution unit 213 suspends the allocation to the virtual ECU 200 (VM1) to which the usage time of the control unit 20 is currently assigned, and allocates the usage time of the control unit 20 to another virtual ECU 200 (VM4) that has a lower priority (lower ASIL level) than the virtual ECU 200 (VM1). In other words, the allocation execution unit 213 functions as a rescheduling unit that reschedules within the assigned time of the virtual ECU 200 (VM1) that has output the task completion notification in the schedule defined in the assigned time table 21A. This causes the processing of a task generated (activated) by a program that uses the other virtual ECU 200 (VM4) as its operating environment to be executed.

6 is an explanatory diagram of the allocation time period of the control unit 20 for the virtual environment. As shown in the figure in this embodiment, for the virtual ECUs 200 (VM1, VM2, VM3) to which the use time of the control unit 20 is periodically (steadily) allocated, the management unit 210 allocates the use time of the control unit 20 based on the allocation period which is the sum (1000μs=500μs+300μs+200μs) of the allocation times of each virtual ECU 200 (VM1: 500μs, VM2: 300μs, VM3: 200μs). In addition, when a switching time (margin) is required to switch the allocation time period of the control unit 20 for the virtual environment, the allocation period may be set by taking into account the switching time. In other words, the allocation period may be a value obtained by adding the switching time to the sum (allocation period=sum + switching time).

As shown in the figure, in the first and second cycles, the remaining time in virtual ECU 200 (VM1) is equal to or greater than the expected processing time (configuration setting value) of virtual ECU 200 (VM4), and therefore virtual ECU 200 (VM4) is allocated to the remaining time. In contrast, the remaining time in virtual ECU 200 (VM2) in the first cycle and the remaining time in virtual ECU 200 (VM3) in the second cycle are less than the expected processing time (configuration setting value) of virtual ECU 200 (VM4), and therefore virtual ECU 200 (VM4) is not allocated to these remaining times.

Figure 7 is a flowchart illustrating the processing of the control unit 20 (virtual control unit) of the in-vehicle ECU 2 (virtual ECU 200). The control unit 20 of the in-vehicle ECU 2 performs the following processing after the in-vehicle ECU 2 (host ECU) is started (booted) when the vehicle C transitions from a stopped state (IG switch is off) to a running state (IG switch is on) and a virtualized operating system such as HyperVisor implemented in the host ECU is started. Alternatively, the in-vehicle ECU 2 may perform the following processing when it acquires (receives) a WakeUp signal, for example.

When the following process is executed in a virtual ECU 200 (virtual environment) for controlling various in-vehicle devices 3, the actual virtual control unit of the virtual ECU 200 (e.g., VM1 to VM4) is the control unit 20 of the in-vehicle ECU 2. The virtual control unit (control unit 20) of the virtual ECU 200 for controlling the in-vehicle devices 3 determines whether the task is completed (S101). The virtual ECU 200 for controlling the in-vehicle devices 3 is, for example, a virtual ECU 200 in which an allocation period is set in an allocation time table 21A, and the usage time of the control unit 20 is allocated (allocated time is given) periodically (regularly) based on the allocation period.

The virtual ECU 200 executes (starts) a single task or multiple tasks based on a predetermined start period, for example, as set in advance in the allocation time table 21A. When executing (starting) the task, the virtual control unit (control unit 20) of the virtual ECU 200 may generate a sub-process or thread to execute (start) the task.

When there is a task being executed (started), the virtual control unit (control unit 20) of the virtual ECU 200 monitors the status of the task and determines whether the task is completed. In determining the completion of the task, the virtual control unit (control unit 20) of the virtual ECU 200 may determine that the task is completed by detecting that a sub-process or thread generated to execute (start) the task has disappeared. Alternatively, the virtual control unit (control unit 20) may determine that the task is completed when it receives a completion signal transmitted from a process for executing the task. If the task is not completed (S101: NO), a loop process is performed to execute the process of S101 again.

When the task is completed (S101: YES), the virtual control unit (control unit 20) of the virtual ECU 200 for controlling the in-vehicle device 3, etc., acquires the remaining time (S102). The virtual control unit acquires the remaining time from the management unit 210, which is responsible for managing the virtual operating system, by, for example, communicating with the management unit 210 (sending an output request signal) and subtracting the elapsed time from the start of the allocation to the current time from the allocated time allocated to its own virtual ECU 200.

The virtual control unit (control unit 20) of the virtual ECU 200 for controlling the in-vehicle device 3, etc., determines whether or not to execute other tasks within the remaining time (S103). The virtual control unit (control unit 20) of the virtual ECU 200 determines whether or not to execute other tasks within the remaining time, i.e., whether or not they need to be executed. The virtual control unit (control unit 20) of the virtual ECU 200, for example, refers to the allocation time table 21A to calculate each of the next start times determined based on the start period of each of the other single or multiple tasks, and determines whether or not there is a task whose calculated start time is included in the remaining time (existence or non-existence).

If a task whose start time is included in the remaining time exists, the virtual control unit (control unit 20) of virtual ECU 200 determines that execution (startup) of that task (other task) is required (possible). If no task whose start time is included in the remaining time exists, the virtual control unit (control unit 20) of virtual ECU 200 determines that execution (startup) of that task (other task) is not required (not possible).

If another task needs to be executed within the remaining time (S103: YES), the virtual control unit (control unit 20) of the virtual ECU 200 for controlling the in-vehicle device 3, etc. executes (starts) the other task (S104). After executing (starting) the other task, the virtual control unit (control unit 20) of the virtual ECU 200 performs a loop process to execute the process of S101 again.

If no other tasks need to be executed within the remaining time (S103: NO), the virtual control unit (control unit 20) of the virtual ECU 200 for controlling the in-vehicle device 3, etc., outputs a task completion notification (S1031). If no other tasks need to be executed within the remaining time, the remaining time essentially corresponds to the free time of the control unit 20. In response to this, the virtual control unit (control unit 20) of the virtual ECU 200 outputs (transmits) the task completion notification to the management unit 210, thereby allocating the remaining time to another virtual ECU 200, making effective use of the free time in the control unit 20 and improving the utilization rate of the control unit 20.

When the following process is executed by the management unit 210 functioning as a control panel of the virtual operating system, the entity of the management unit 210 is the control unit 20 of the in-vehicle ECU 2. The management unit 210 (control unit 20) determines whether or not a request to output the remaining time has been received (S111). If a request to output the remaining time has not been received (S111: NO), the management unit 210 (control unit 20) performs loop processing to execute the process of S111 again.

When a request to output the remaining time is received (S111: YES), the management unit 210 (control unit 20) outputs the remaining time (S112). The management unit 210 (control unit 20) refers to the allocation time table 21A, for example, to calculate the remaining time by subtracting the elapsed time from the start of allocation to the current time from the allocation time allocated to the virtual ECU 200 that sent the output request for the remaining time, and outputs (transmits) the calculated remaining time to the virtual ECU 200.

The management unit 210 (control unit 20) determines whether or not a task completion notification has been obtained (S113). The management unit 210 (control unit 20) determines whether or not a task completion notification has been obtained from the virtual ECU 200 by communicating with the virtual control unit (control unit 20) of the virtual ECU 200. The management unit 210 (control unit 20) may, for example, process S111 and process S113 in parallel using different processes or threads. If a task completion notification has not been obtained (S113: NO), the management unit 210 (control unit 20) performs loop processing to execute the process of S113 again.

When a task completion notification is obtained (S113: YES), the management unit 210 (control unit 20) determines whether the remaining time is equal to or greater than the set time of a program whose operating environment is another virtual environment (S114). The management unit 210 (control unit 20) compares the remaining time calculated in S112 with the set time of a program whose operating environment is another virtual environment (virtual ECU 200) to which the remaining time is allocated, thereby determining whether the remaining time is equal to or greater than the set time. The set time of the program is, for example, the expected processing time (configuration setting value) of a task executed (launched) by the program.

If the remaining time is equal to or greater than the set time (S114: YES), the management unit 210 allocates the usage time of the control unit 20 to the other virtual environment (S115). The priority of the program whose operating environment is the other virtual environment (virtual ECU 200) is lower than the priority of the program in the virtual environment (virtual ECU 200) that output the task completion notification. The priority is determined based on the ASIL, for example, and the ASIL of the virtual environment (virtual ECU 200) that output the task completion notification may be a D or C level, and the ASIL of the program whose operating environment is the other virtual environment (virtual ECU 200) may be a QM level.

If the remaining time is equal to or greater than the set time, the control unit 20 (core, etc.) that is shared by multiple virtual environments (virtual ECUs 200) is divided into time periods and the assigned virtual environment (virtual ECU 200) is switched. By switching the assigned virtual environment (virtual ECU 200), the usage time of the control unit 20 (core, etc.) is assigned to the other virtual environment (virtual ECU 200), and processing of a task generated (activated) by a program that uses the other virtual environment (virtual ECU 200) as its operating environment is executed. The assignment to the other virtual environment (virtual ECU 200) ends with the end of the assigned time period for the virtual environment (virtual ECU 200) that output the task completion notification.

The management unit 210 (control unit 20) continues control of the end of the allocated time period and the start of allocation to the next virtual environment (virtual ECU 200), for example, by referring to the allocated time table 21A. Therefore, even if the control unit 20's usage time is allocated to another virtual environment (virtual ECU 200) with a lower priority based on a task completion notification, the control unit 20's usage time can continue to be allocated to multiple virtual environments, including the allocated time period of the next virtual environment, without changing the scheduling based on the allocated time information.

If the remaining time is not equal to or greater than the set time (S114: NO), i.e., if the remaining time is less than the set time, the management unit 210 ends the series of processes without allocating the control unit 20's usage time to other virtual environments (virtual ECUs 200). In other words, the management unit 210 maintains the allocation of the control unit 20's usage time to the virtual environment (virtual ECU 200) in which the program that output the task completion notification is the operating environment. The management unit 210 (control unit 20) continues to control the end of the allocated time period for the virtual environment (virtual ECU 200) and the start of allocation to the next virtual environment (virtual ECU 200), for example, by referring to the allocated time table 21A.

(Embodiment 2)
8 is an explanatory diagram illustrating an example of an allocation time table 21A (allocation time information) according to embodiment 2. The management items of the allocation time table 21A of embodiment 2 differ from those of embodiment 1 in that, in addition to the management items of the allocation time table 21A of embodiment 1, the allocation time table 21A further includes an item of an allocation core.

In the second embodiment, the control unit 20 is configured with, for example, multiple cores (multi-core), and a virtual operating system such as Hypervisor allocates the usage time of each of the multiple cores (as shown in the figure, a dual core consisting of core 1 and core 2) to multiple virtual ECUs 200 (virtual environments). In this embodiment, the control unit 20 is configured with multiple cores, but this is not limited to this. The control unit 20 may also be configured with multiple single-core CPUs. In this case, it goes without saying that the item for allocated cores in the allocated time table 21A corresponds to the item for allocated CPUs.

The assigned core item stores the number or identifier of the core assigned to the corresponding virtual ECU 200 (virtual ECU 200 stored in the same record). For virtual ECUs 200 (VM1 to VM6) that are assigned periodically (regularly), the number of one of the cores is stored. This determines which core (core number) is assigned to each virtual ECU 200. In the illustration of this embodiment, the virtual ECUs 200 (VM1, VM2, VM3) are assigned to core 1, and the virtual ECUs 200 (VM4, VM5, VM6) are assigned to core 2.

For the virtual ECU 200 (VM7) to which the usage time of the control unit 20 is non-regularly allocated, the numbers of multiple cores may be stored. That is, the virtual ECU 200 (VM7) to which the non-regular allocation is performed is assigned to core 1 and core 2. Therefore, when a task completion notification is output by the task completion monitoring unit 202 in any of the virtual ECUs 200 to which the usage time of the control unit 20 is periodically (regularly) allocated among the cores 1 and 2 constituting the control unit 20, the free time of core 1 or core 2 after the task completion notification is output can be assigned to the virtual ECU 200 (VM7) to which the non-regular allocation is performed.

Figure 9 is an explanatory diagram regarding the allocation time zones of the control unit 20 for the virtual environment. As in Figure 6 of the first embodiment, the management unit 210 (omitted from Figure 9) allocates the usage time of core 1 (shared by VM1, VM2, and VM3) and core 2 (shared by VM4, VM5, and VM6) constituting the control unit 20 to the virtual ECUs 200 (VM1 to VM6) that are allocated periodically (regularly).

In core 1, similarly to embodiment 1, the management unit 210 allocates the usage time of the control unit 20 to the virtual ECUs 200 (VM1, VM2, VM3) based on an allocation period that is the sum (1000μs=500μs+300μs+200μs) of the allocation times of each virtual ECU 200 (VM1: 500μs, VM2: 300μs, VM3: 200μs). In core 2, the management unit 210 allocates the usage time of the control unit 20 to the virtual ECUs 200 (VM4, VM5, VM6) based on an allocation period that is the sum (1000μs=300μs+300μs+400μs) of the allocation times of each virtual ECU 200 (VM4: 300μs, VM5: 300μs, VM6: 400μs).

In core 1, as in embodiment 1, the remaining time in virtual ECU 200 (VM1) is equal to or greater than the expected processing time (configuration setting value) of virtual ECU 200 (VM7) in the first and second cycles, so virtual ECU 200 (VM4) is allocated for the remaining time. In core 2, the remaining time in virtual ECU 200 (VM1) is equal to or greater than the expected processing time (configuration setting value) of virtual ECU 200 (VM5) in the second cycle, so virtual ECU 200 (VM7) is allocated for the remaining time.

Even if the control unit 20 is configured with multiple cores, when free time occurs in any of the cores, the utilization rate of the control unit 20 can be improved by allocating the utilization time of that core to a virtual ECU 200 (VM7) that is non-regularly allocated. In this embodiment, the number of virtual ECUs 200 (VM7) that are non-regularly allocated is one, but this is not limited to this, and the number of virtual ECUs 200 that are non-regularly allocated may be two or more, and the utilization time of the control unit 20 may be allocated sequentially to the two or more virtual ECUs 200.

The embodiments disclosed herein are illustrative in all respects and should not be considered limiting. The scope of the present invention is indicated by the claims, not by the meaning described above, and is intended to include all modifications within the scope and meaning equivalent to the claims.

C Vehicle S In-vehicle system 100 External server 1 External communication device 11 Antenna 2 In-vehicle ECU
20 Control unit 21 Storage unit 21A Allocation time table 22 Input/output I/F
23 In-vehicle communication unit 200 Virtual ECU (virtual environment)
201 Task generation unit 202 Task completion monitoring unit 210 Management unit 211 Remaining time derivation unit 212 Completion determination unit 213 Allocation execution unit 3 In-vehicle device 30 Actuator (ACT)
31 Sensor 4 Vehicle network

Claims (6)

An on-board ECU mounted on a vehicle,
A control unit that executes a plurality of programs;
a storage unit in which a virtualized operating system to be started by the control unit is stored,
A plurality of virtual environments are generated by booting the virtualized operating system, and the program operates in the virtual environments;
a management unit that manages the virtualized operating system, based on a task completion notification in a program executed in any one of the plurality of virtual environments, allocates an assigned time period of the control unit that was assigned to any one of the virtual environments to another virtual environment ;
the storage unit stores allocated time information that defines an allocated time period of the control unit for the plurality of virtual environments;
the allocated time information includes an allocated time period of any one of the virtual environments and an allocated time period of a virtual environment that is next in rank to the any one of the virtual environments;
the allocation time slot allocated to the other virtual environment is from after the management unit acquires a task completion notification to a start point of the allocation time slot of the next virtual environment,
The management unit
Calculating the remaining time from the time when the task completion notification is obtained to the start time of the allocated time slot of the next virtual environment;
When the remaining time is equal to or greater than a preset time for a program that operates in the other virtual environment, the allocated time zone of the control unit that has been allocated to any one of the virtual environments is allocated to the other virtual environment.
On-board ECU. The management unit
Calculating the remaining time from the time when the task completion notification is obtained to the start time of the allocated time slot of the next virtual environment;
The vehicle-mounted ECU described in claim 1, wherein when the remaining time is less than a set time predetermined for a program that uses the other virtual environment as its operating environment, the allocated time period of the control unit that was allocated to one of the virtual environments continues to be allocated to the one of the virtual environments without being allocated to the other virtual environment. An allocation period based on an allocation time period for each virtual environment defined in the allocation time information is shorter than a start period of a task in a program executed in any of the virtual environments.
The vehicle-mounted ECU according to claim 1 or 2 . a priority of a program that uses one of the virtual environments as its operating environment is higher than a priority of a program that uses the other of the virtual environments as its operating environment;
The in-vehicle ECU according to claim 1 , wherein the priority is determined based on an Automotive Safety Integrity Level (ASIL) of ISO26262. A computer installed in a vehicle that runs multiple programs
generating a plurality of virtual environments by booting a virtualized operating system stored in a storage unit of the computer;
The virtual environment is an operating environment for executing the program,
allocating a time slot of the control unit of the computer that has been allocated to any one of the virtual environments to another virtual environment based on a task completion notification in a program executed in any one of the plurality of virtual environments ;
the storage unit stores allocated time information that defines an allocated time period of the control unit for the plurality of virtual environments;
the allocated time information includes an allocated time period of any one of the virtual environments and an allocated time period of a virtual environment that is next in rank to the any one of the virtual environments;
the allocated time period allocated to the other virtual environment is from after the task completion notification is obtained to the start of the allocated time period of the next virtual environment,
Calculating the remaining time from the time when the task completion notification is obtained to the start time of the allocated time slot of the next virtual environment;
When the remaining time is equal to or greater than a preset time for a program that operates in the other virtual environment, the allocated time zone of the control unit that has been allocated to any one of the virtual environments is allocated to the other virtual environment.
A program that executes a process. A computer installed in a vehicle that runs multiple programs
generating a plurality of virtual environments by booting a virtualized operating system stored in a storage unit of the computer;
The virtual environment is an operating environment for executing the program,
allocating a time slot of the control unit of the computer that has been allocated to any one of the virtual environments to another virtual environment based on a task completion notification in a program executed in any one of the plurality of virtual environments ;
the storage unit stores allocated time information that defines an allocated time period of the control unit for the plurality of virtual environments;
the allocated time information includes an allocated time period of any one of the virtual environments and an allocated time period of a virtual environment that is next in rank to the any one of the virtual environments;
the allocated time period allocated to the other virtual environment is from after the task completion notification is obtained to the start of the allocated time period of the next virtual environment,
Calculating the remaining time from the time when the task completion notification is obtained to the start time of the allocated time slot of the next virtual environment;
When the remaining time is equal to or greater than a preset time for a program that operates in the other virtual environment, the allocated time zone of the control unit that has been allocated to any one of the virtual environments is allocated to the other virtual environment.
An information processing method for executing a process.

Images