Vehicle control device

Abstract

This vehicle control device is provided with a hypervisor, first and second virtual machines operating on the hypervisor, a real device occupied and directly accessible by the first virtual machine, and a shared memory accessible by the first virtual machine. The first and the second virtual machines communicate via a ring buffer. In that situation, the first virtual machine secures the ring buffer for each of different levels determined as safety standard levels.

Description

Vehicle control device

[0001] The present invention relates to a vehicle control device.

[0002] In recent years, the number of vehicle control devices installed in a vehicle such as an automobile has tended to increase as the vehicle control functions have become more sophisticated. When a large number of vehicle control devices are installed, there is a possibility that communication conflicts may occur between the vehicle control devices, resulting in problems such as increased processing time and other overhead.

[0003] For this reason, it has been proposed to incorporate multiple processing function units (so-called virtual machines) into one vehicle control device so that various control processes can be integrated into one vehicle control device. Patent Document 1 describes a technology in which, in a server equipped with multiple operating systems (OSs) on virtual machines, each OS communicates via a ring buffer, which is a shared memory provided on the server.

[0004] JP 2012-226471 A

[0005] Vehicle control devices installed in vehicles are classified into levels called Automotive Safety Integrity Levels (ASIL) depending on their functions. For example, data related to brake and airbag control is rated at ASIL-D, which is the strictest requirement for ensuring safety, because it poses the highest risk of failure. On the other hand, data related to backlight control is rated at ASIL-A, which is the lowest level. In this way, vehicle control devices installed in vehicles are assigned appropriate levels for each of their functions.

[0006] When the vehicle control device performs communication, the vehicle control device needs to perform communication appropriately with a priority that takes into account the ASIL level. Here, as described in Patent Document 1, if communication is simply performed between a plurality of processing units using a ring buffer, there is a possibility that FFI (Freedom From Interference, i.e., communications at each ASIL level do not interfere with each other) for communications at each level defined by ASIL cannot be ensured.

[0007] The present invention has been made in view of the above circumstances, and has as its object to provide a vehicle control device that is capable of transferring data appropriately for each function provided in the vehicle.

[0008] In order to solve the above problem, for example, the configuration described in the claims is adopted. The present application includes multiple means for solving the above problem, and one example thereof is a vehicle control device including a hypervisor that virtualizes computer hardware, a first virtual machine and a second virtual machine running on the hypervisor, a real device occupied by and directly accessible to the first virtual machine, and a shared memory accessible to the first virtual machine, the first virtual machine and the second virtual machine communicating via a ring buffer, and when the first virtual machine is started before the second virtual machine, the first virtual machine allocates the ring buffer in the shared memory and notifies the second virtual machine of the ring buffer, and the second virtual machine uses the ring buffer and the real device occupied by the first virtual machine, and the first virtual machine allocates a ring buffer for each level determined as a safety level.

[0009] According to the present invention, since a ring buffer is secured for each safety level, when a process at each safety level is executed, access to a process at another level is not possible, so that a process using a virtual machine can be executed while securing the safety level. Problems, configurations, and effects other than those described above will become clear from the description of the embodiment below.

[0010] 1 is a block diagram showing an example of the overall configuration of a vehicle control device according to a first embodiment of the present invention. FIG. 2 is a block diagram showing an example of the internal configuration of a SoC of the vehicle control device according to the first embodiment of the present invention. FIG. 3 is a block diagram showing an example of the internal configuration of a virtual machine image file of the vehicle control device according to the first embodiment of the present invention. FIG. 4 is a diagram showing an example of the internal configuration of a shared memory of the vehicle control device according to the first embodiment of the present invention. FIG. 5 is a diagram showing the logical configuration of the vehicle control device according to the first embodiment of the present invention. FIG. 6 is a block diagram showing an example of the internal configuration of a virtual machine of the vehicle control device according to the first embodiment of the present invention. FIG. 7 is a block diagram showing an example of the internal configuration of a virtual device driver of the vehicle control device according to the first embodiment of the present invention. FIG. 8 is a flowchart showing an example of main processing by the vehicle control device according to the first embodiment of the present invention. FIG. 9 is a flowchart showing an example of a virtual device driver transmission thread by the vehicle control device according to the first embodiment of the present invention. FIG. 10 is a flowchart showing an example of a virtual device driver reception thread by the vehicle control device according to the first embodiment of the present invention. FIG. 11 is a diagram showing an example of page table setting contents in access space setting by the vehicle control device according to the first embodiment of the present invention. FIG. 12 is a configuration diagram showing an example of a vehicle system including the vehicle control device according to the first embodiment of the present invention. FIG. 13 is a block diagram showing an example of the internal configuration of a virtual machine image file of the vehicle control device according to a modified example of the first embodiment of the present invention. 1 is a flowchart showing an example of a transmission thread of a second virtual device driver by a vehicle control device according to a modified example of the first embodiment of the present invention. FIG. 2 is a flowchart showing an example of a reception thread of a second virtual device driver by a vehicle control device according to a modified example of the first embodiment of the present invention. FIG. 3 is a diagram showing an example of the internal configuration of a shared memory of a vehicle control device according to a second embodiment of the present invention. FIG. 4 is a diagram showing an example of a ring buffer management table of a vehicle control device according to a second embodiment of the present invention. FIG. 5 is a diagram showing an example of the internal configuration of a virtual device driver of a vehicle control device according to a second embodiment of the present invention. FIG. 6 is a flowchart showing an example of main processing by a vehicle control device according to a second embodiment of the present invention.1 is a flowchart showing an example of initial setting processing by a vehicle control device according to a second embodiment of the present invention. FIG. 2 is a flowchart showing an example of termination processing by a vehicle control device according to a second embodiment of the present invention. FIG. 3 is a block diagram showing an example of the internal configuration of a SoC of a vehicle control device according to a third embodiment of the present invention. FIG. 4 is a block diagram showing an example of the logical configuration of a vehicle control device according to a third embodiment of the present invention. FIG. 5 is a diagram showing an example of the internal configuration of a virtual device driver of a vehicle control device according to a third embodiment of the present invention. FIG. 6 is a flowchart showing an example of main processing by a vehicle control device according to a third embodiment of the present invention. FIG. 7 is a block diagram showing an example of the logical configuration of a vehicle control device according to a fourth embodiment of the present invention. FIG. 8 is a block diagram showing an example of the internal configuration of a SoC of a vehicle control device according to a fourth embodiment of the present invention. FIG. 9 is a flowchart showing an example of main processing by a vehicle control device according to a fourth embodiment of the present invention.

[0011] <First Embodiment> A vehicle control device according to a first embodiment of the present invention will be described below with reference to FIGS. 1 to 12. FIG.

[0012] [Hardware Configuration of Vehicle Control Device] Fig. 1 shows the overall configuration of a vehicle control device 10 according to a first embodiment of the present invention. The vehicle control device 10 of this embodiment is an electronic device known as an ECU (Electronic Control Unit). One or more vehicle control devices 10 are installed in a vehicle such as an automobile, and control various parts of the vehicle.

[0013] The vehicle control device 10 includes a semiconductor device called a SoC (System on a Chip). The SoC includes at least an actual device 120. The actual device 120 includes hardware and performs communication processing or data arithmetic processing. In this embodiment, the actual device 120 is a device that performs communication processing with the outside of the vehicle control device 10, and is connected to other ECUs, sensors, and actuators.

[0014] 2 shows an example of the hardware configuration of a system on a chip (SoC) 100. As shown in FIG. 2, the SoC 100 includes a central processing unit (CPU) core 110, an actual device 120, and a memory 130.

[0015] The CPU core 110 controls the execution of applications in the first virtual machine image file 140a and the second virtual machine image file 150a configured in the memory 130. Note that, for ease of explanation, the following description may refer to a program as the subject, but the CPU core 110 is always the main operating entity. The CPU core 110 is capable of communicating with the real device 120 and the memory 130.

[0016] The real device 120 is a port that executes communication processing using a communication protocol such as Ethernet (registered trademark) or CAN (Controller Area Network). The vehicle control device 10 inputs and outputs data to and from the outside via the port implemented as the real device 120. Note that the real device 120 may be a device that does not communicate with the outside, such as a GPGPU (General-purpose computing on graphics processing unit) or an NPU (Neural network Processing Unit).

[0017] The memory 130 is loaded with a first virtual machine image file 140a, a second virtual machine image file 150a, and a shared memory 160. The first virtual machine image file 140a and the second virtual machine image file 150a are files necessary for the hypervisor 170 to start virtual machines 140b and 150b, respectively. The virtual machines 140b and 150b are computers (virtual machines) that are virtually configured in memory by executing a program started by the hypervisor 170.

[0018] The shared memory 160 provided in the memory 130 can be accessed by the applications 141, 142, 151, and 152 (FIG. 1) generated by the CPU core 110 via the virtual machines 140b and 150b.

[0019] [Internal Structure of Virtual Machine Image File] Fig. 3 shows an example of the internal structure of the first virtual machine image file 140a. Although not shown in Fig. 3, the second virtual machine image file 150a has the same internal structure as the first virtual machine image file 140a.

[0020] The first virtual machine image file 140a is provided with a first application 141, a second application 142, and an OS (Operating System) 143. Note that applications are abbreviated as "App" in the drawings. The first application 141 stores the programs and data that constitute the first application 141. The second application 142 stores the programs and data that constitute the second application 142. The second virtual machine image file 150a (not shown) may be equipped with different types of OS 143, first application 141, and second application 142 from those in the first virtual machine image file 140a.

[0021] The OS 143 is provided with a main processing unit 144, a virtual device driver 145, a transfer program 146, and a real device driver 147. The main processing unit 144 executes main processing such as starting the virtual device driver 145 provided for the first virtual device 140. The virtual device driver 145 is provided with a sending thread 145a and a receiving thread 145b.

[0022] [Internal Configuration of Shared Memory] Fig. 4 shows an example configuration of the shared memory 160. The shared memory 160 of this embodiment is provided with an ASIL-D area 161, an ASIL-B area 162, and a QM area 163. That is, as explained in the Background Art section, the functions controlled by the vehicle control device 10 of this embodiment are divided into levels called ASIL. Specifically, the functions controlled by the vehicle control device 10 are divided into four levels, ASIL-D, ASIL-C, ASIL-B, and ASIL-A, in descending order of importance. The vehicle control device 10 of this embodiment executes ASIL-D level control and ASIL-B level control.

[0023] Returning to the explanation of the shared memory 160, the ASIL-D area 161 is an area used when executing functions at the ASIL-D level, and the ASIL-B area 162 is an area used when executing functions at the ASIL-B level. The QM area 163 is an area that does not need to be provided with functions at the ASIL level. In other words, the QM area 163 is an area used when executing QM (Quality Management) functions. The configurations of the respective areas 161, 162, and 163 are identical.

[0024] Ring buffers 161a, 162a, and 163a are provided in the respective areas 161, 162, and 163 of the shared memory 160. It is preferable that each of the ring buffers 161a, 162a, and 163a be a pair of unidirectional ring buffers to enable two-way communication. In the following explanation, when the multiple ring buffers 161a, 162a, and 163a are collectively referred to, they will be referred to as ring buffer 161a, etc.

[0025] 5 shows the logical configuration of the vehicle control device 10. The vehicle control device 10 includes a real device 120, a first virtual machine 140b, and a second virtual machine 150a. A first application 141 and a second application 142 are implemented in the first virtual device 140. A third application 151 and a fourth application 152 are implemented in the second virtual device 150.

[0026] The applications 141, 142, 151, and 152 are a group of applications that generate and transmit data for controlling steering and the like, using data from various sensors installed in the vehicle. A specific example of steering control is an application that performs lane keeping based on white line recognition, etc. Various applications are prepared depending on the functions of the vehicle.

[0027] The first virtual device 140 and the second virtual device 150 are provided with operating systems 143 and 153, respectively. The applications 141, 142, 151, and 152 execute their assigned functions under the control of the respective operating systems 143 and 153. One of the programs provided in the OS 143 of the first virtual device 140 is a transfer program 146. The transfer program 146 may be, for example, a transfer program using a TCP / IP (Transmission Control Protocol / Internet Protocol) communication protocol. The first virtual device 140 and the second virtual device 150 are also provided with virtual device drivers 145 and 155.

[0028] Furthermore, the vehicle control device 10 has a shared memory 160, and the first virtual device 140 and the second virtual device 150 can execute their respective processes using the shared memory 160. The shared memory 160 has a plurality of ring buffers 161a, 162a, ..., and each of the ring buffers 161a, 162a, ... is used for data transfer between the first virtual device 140 and the second virtual device 150. The specific configuration of the plurality of ring buffers 161a, 162a, ... will be described later.

[0029] The input and output of data in each ring buffer 161 a, 162 a, ... is performed by the drivers 145, 155 of the respective virtual devices 140, 150. That is, the virtual device driver 145 performs input and output of data in each ring buffer 161 a, 162 a, ... in the first virtual device 140. The virtual device driver 155 performs input and output of data in each ring buffer 161 a, 162 a, ... in the second virtual device 150.

[0030] When operating the actual device 120, the first virtual device 140 and the second virtual device 150 transfer data via the hypervisor 170. The hypervisor 170 is software required for each of the virtual devices 140 and 150 to operate the actual device 120, and performs processing to virtualize computer hardware.

[0031] When the applications 141 and 142 in the first virtual device 140 operate the real device 120, data such as operation commands is transmitted to the real device 120 via the hypervisor 170. For example, as shown by the arrow in Figure 5, data is transmitted from the first application 141 to the real device 120 via the hypervisor 170.

[0032] On the other hand, when the applications 151 and 152 in the second virtual device 150 operate the real device 120, data is transmitted via ring buffers 161a, 162a, ... in the shared memory 160. For example, as shown by the arrow in Figure 5, data is transmitted from the fourth application 152 to the ring buffer 161a in the shared memory 160 via the virtual device driver 155. The data taken into the ring buffer 161a is transmitted to the virtual device driver 145 of the first virtual device 140, and the data is transmitted to the real device 120 via the hypervisor 170 by the transfer program 146 of the OS 143.

[0033] Here, if the first virtual device 140 is started before the second virtual device 150, the first virtual device 140 reserves a ring buffer on the shared memory 160 and notifies the second virtual machine of the ring buffer, and the second virtual device 150 performs processing to use the ring buffer and the actual device 120 occupied by the first virtual device 140. Note that, although the transfer program 146 is provided in the OS 143 in FIG. 5 , the transfer program 146 may be provided as an application program outside the OS 143.

[0034] 5 shows the internal configuration of the first virtual machine 140b. The first virtual machine 140b includes a first application 141, a second application 142, and an OS 143. The OS 143 includes a main processing unit 144, a virtual device driver 145, a transfer program 146, a real device driver 147, and a page table 148.

[0035] The real device driver 147 receives a processing request such as transmission from the transfer program 146 and starts processing of the real device 120 (FIG. 5). The real device driver 147 also passes the results of responses such as reception from the real device 120 to the transfer program 146. The virtual device driver 145 receives responses from the transfer program 146 and performs transmission processing to the ring buffer 161a, etc. The virtual device driver 145 also performs reception processing of requests from the ring buffer 161a, etc. and passes them to the transfer program 146.

[0036] It is preferable that the virtual device driver 145 has the same interface format as the real device driver 147. This enables the first virtual device 140 to perform input / output with the ring buffer 161a, etc., without modifying the OS 143 itself. The page table 148 is a table that sets access rights to memory areas.

[0037] [Internal Configuration of Virtual Device Driver] Fig. 6 shows the internal configuration of the virtual device driver 145 provided in the first virtual machine 140b. The virtual device driver 145 has a pair of a sending thread and a receiving thread for each ASIL level provided in the applications 141 and 142 implemented in the virtual machine 140b. For example, as shown in Fig. 7, the virtual device driver 145 has a sending thread 145a and a receiving thread 145b for ASIL-D. If the applications 141 and 142 perform processing of other ASIL levels, the virtual device driver 145 has a pair of a sending thread and a receiving thread for the corresponding ASIL level.

[0038] 8 is a flowchart showing an example of the main processing executed by the main processing unit 144 (FIGS. 3 and 6). When the main processing starts, the main processing unit 144 starts a transmission thread and a reception thread of the virtual device driver 145 (step S11). At the time of starting in step S11, the main processing unit 144 starts a transmission thread and a reception thread corresponding to the ASIL level of the processing executed by the applications 141 and 142 in the first virtual machine 140b.

[0039] For example, when the level is ASIL-D, the main processing unit 144 starts a sending thread 145a and a receiving thread 145b for ASIL-D shown in Fig. 7. When the processes executed by the applications 141 and 142 have multiple ASIL levels, the main processing unit 144 starts sending threads and receiving threads corresponding to the multiple levels.

[0040] The main processing unit 144 then determines whether the processing in the virtual machine 140b has ended (step S12). If the processing in the virtual machine 140b has not ended in step S12 (NO in step S12), the main processing unit 144 waits until the processing in the virtual device 140 has ended. If the processing in the virtual machine 140b has ended in step S12 (YES in step S12), the main processing unit 144 ends the main processing.

[0041] 9 is a flowchart showing an example of processing in a transmission thread (such as the transmission thread 145a in FIG. 7) of the virtual device driver 145. The transmission thread determines whether or not a processing request has been received from the OS 143 (step S21). If no processing request has been received in step S21 (NO in step S21), the transmission thread waits until a processing request is received.

[0042] If a processing request is received in step S21 (YES in step S21), the sending thread sets an access space (step S22). Here, the sending thread sets the page table 148 so that only a specified area (area at the corresponding level) in the shared memory 160 is accessible. Thereafter, the sending thread performs enqueueing to input data into the ring buffer handled by the sending thread (step S23). After executing the enqueue in step S23, the sending thread returns to the determination in step S21.

[0043] 10 is a flowchart showing an example of processing in a reception thread (such as the reception thread 145b in FIG. 7) of the virtual device driver 145. The reception thread determines whether new data is present in the ring buffer managed by the transmission thread paired with the reception thread (step S31). If no new data is present in step S31 (NO in step S31), the reception thread waits until new data is present.

[0044] If new data is found in step S31 (YES in step S31), the receiving thread sets an access space (step S22). Here, the receiving thread sets the page table 148 so that only a specified area (area at the corresponding level) in the shared memory 160 is accessible. Then, the receiving thread dequeues the data to output it to the ring buffer assigned to the receiving thread (step S33). The receiving thread then notifies the OS 143 of the completion of the dequeue (step S34) and returns to the determination in step S31.

[0045] [Page Table Setting Contents] Fig. 11 shows an example of the settings of the page table 148 when setting the access space. In the example shown in the upper part of Fig. 11, in the page table 148, the physical address of the QM area 163 is valid, and the physical addresses of the other areas (such as the ASIL-D area 161 and the ASIL-B area 162) are invalid.

[0046] When a data transmission thread for an ASIL-D level application is started in the state shown in the upper part of Figure 11, as shown in the lower part of Figure 11, in the page table 148, the physical address of the ASIL-D area 161 becomes valid and the physical addresses of other areas (ASIL-B area 162, QM area 163, etc.) become invalid.

[0047] [Overall System Configuration of a Vehicle Equipped with a Vehicle Control Device] FIG. 12 shows an example of the overall system of a vehicle equipped with a vehicle control device 10. Here, the vehicle control device 10 is an integrated ECU that performs integrated control of each ECU installed in the vehicle, and is equipped with a first application 141 and a second application 142. The first application 141 is, for example, a central gateway (CGW) that relays data between multiple drivers via Ethernet or the like. The second application 142 is, for example, an ADAS (Advanced Driver-Assistance Systems) that provides a function to assist the driver, such as lane keeping. Note that while examples of the first application 141 and the second application 142 are shown here, the third application 151 and the fourth application 152 ( FIG. 5 ) also provide their assigned functions.

[0048] 12, the vehicle is also equipped with another vehicle control device 200. This vehicle control device 200 is a zone ECU that aggregates data from various sensors, actuators, and control ECUs (none of which are shown) and transmits it to the vehicle control device 10, which serves as an integrated ECU. The vehicle control device 200, which serves as a zone ECU, distributes data received from the vehicle control device 10, which serves as an integrated ECU, to the various sensors, actuators, control ECUs, etc.

[0049] Here, the data transmitted between the vehicle control device 10 and the vehicle control device 200 includes ASIL-D level data, ASIL-B level data, and QM data for which no level is set as safety levels. ASIL-D level data is data for braking, steering, ECU, etc., and is data that requires a high safety level. On the other hand, ASIL-B level data and QM data for which no level is set is data from external sensors, etc., and is data with a lower safety level than ASIL-D level data.

[0050] In this way, a vehicle is equipped with a plurality of vehicle control devices 10, 200, etc., and an ASIL level is set for data exchanged between the vehicle control devices 10, 200. In the case of this embodiment, as already explained, data transfer via the ring buffer 161a etc. between the virtual devices 140, 150 of the vehicle control device 10 is performed by ring buffers divided for each ASIL level.

[0051] Therefore, the ring buffer can set access rights and access ranges for each ASIL level, but cannot be accessed by processing functions at other ASIL levels due to the settings in the page table 148. For this reason, the ring buffer allows only good data transfer with the safety level determined by the ASIL level ensured.

[0052] <Modification of First Embodiment> Next, a modification of the vehicle control device according to the first embodiment of the present invention will be described with reference to FIGS. 13 to 16. FIG.

[0053] [Another Example of Virtual Device Configuration] Fig. 13 shows the configuration of a first virtual machine image file 140a' according to a modified example of the vehicle control device according to the first embodiment of the present invention. The first virtual machine image file 140a' shown in Fig. 12 differs from the first virtual machine image file 140a shown in Fig. 3 in that a second virtual device driver 149 is added.

[0054] That is, the first virtual machine image file 140a' is the same as the first virtual device 140 in that it includes a first application 141, a second application 142, and an OS 143'. The OS 143' differs from the first virtual device 140 shown in FIG. 3 in that it includes a second virtual device driver 149 in addition to a main processing unit 144', a virtual device driver 145, a transfer program 146, and an actual device driver 147.

[0055] The second virtual device driver 149 includes a sending thread 149a and a receiving thread 149b. The sending thread 149a and the receiving thread 149b are prepared for each level of ASIL and for QM, similar to the sending thread 145a and the receiving thread 145b of the virtual device driver 145 shown in FIG.

[0056] 14 is a flowchart showing an example of the main processing executed by the main processing unit 144' (FIG. 13). When the main processing starts, the main processing unit 144' determines whether the virtual device to be processed is directly connected to a real device (step S41). If the virtual device is directly connected to a real device in step S41 (YES in step S41), the main processing unit 144' starts a thread for the virtual device driver 145 (step S42).

[0057] Furthermore, if the virtual device is not directly connected to a real device in step S41 (NO in step S41), the main processing unit 144' starts a thread for the second virtual device driver 149 (step S43). Here, a thread corresponding to the ASIL level of the function executed by the virtual device is started. After starting the thread in steps S42 and S43, the main processing unit 144' determines whether the virtual device has been terminated (step S44). If the virtual device has not been terminated in step S44 (NO in step S44), the main processing unit 144' waits, and if the virtual device has been terminated (YES in step S44), the main processing unit 144' ends the main processing.

[0058] [Processing of the Transmission Thread of the Second Virtual Device Driver] Figure 15 is a flowchart showing an example of processing in the transmission thread 149a of the second virtual device driver 149. The transmission thread 149a shown in Figure 13 determines whether or not there is a transmission request from the OS 143' (step S51). If there is no transmission request in step S51 (NO in step S51), the transmission thread 149a waits until there is a transmission request. If there is a processing request in step S51 (YES in step S51), as in the example of Figure 9, the access space is set in step S22 and the data is enqueued in step S23, and then the process returns to the determination in step S51.

[0059] [Processing of Reception Thread of Second Virtual Device Driver] Figure 16 is a flowchart showing an example of processing in the reception thread 149b of the second virtual device driver 149. The reception thread 149b determines whether there is a reception request from the OS 143' (step S61). If there is a reception request in step S61 (YES in step S61), the reception thread 149b executes the processing from step S32 onwards, as in the example of Figure 10. If there is no reception request in step S61 (NO in step S61), the reception thread 149b waits until there is a reception request.

[0060] After step S33, the receiving thread 149b notifies the OS 143' of the completion of the dequeue (step S34), and the receiving thread 149b returns to the determination in step S61.

[0061] As described in Figures 13 to 16, by providing the second virtual device driver 149, the receiving thread 149b can skip the processing from access space setting to data transmission (the processing of steps S31 to S34 in Figure 16) when there is no receiving request, thereby reducing the processing load.

[0062] <Second embodiment of the present invention> Next, a vehicle control device according to a second embodiment of the present invention will be described with reference to Figures 17 to 22. In Figures 17 to 22, parts corresponding to those in Figures 1 to 16 described in the first embodiment are given the same reference numerals, and duplicated explanations will be omitted.

[0063] [Internal Configuration of Shared Memory] In the vehicle control device of this embodiment, the shared memory 160' is different from the shared memory 160 of the vehicle control device 10 of the first embodiment. Fig. 17 shows an example of the internal configuration of the shared memory 160' of this embodiment.

[0064] The ring buffers 161a, 162a, and 163a in this embodiment are configured to be indexed by IDs (integer values). Furthermore, the ASIL-D area 161, the ASIL-B area 162, and the QM area 163 each have ring buffer management tables 161b, 162b, and 163b, respectively.

[0065] 18 shows an example of the configuration of the ring buffer management table 161b. The other ring buffers 162b and 163b have the same configuration as the ring buffer management table 161b. The ring buffer management table 161b indicates whether each ID of the ring buffer 161a it manages is in use or unused.

[0066] [Configuration of Virtual Device Driver] Figure 19 shows an example of the configuration of a virtual device driver 145' according to this embodiment. Unlike Figure 7, the virtual device driver 145' in Figure 19 has a ring buffer ID index for each pair of transmitting threads and receiving threads for each level. For example, a ring buffer ID index 145c indicating which ID ring buffer to use is added to the pair of transmitting thread 145a and receiving thread 145b for ASIL-D. The rest of the configuration of the vehicle control device according to this embodiment is the same as that of the vehicle control device according to the first embodiment.

[0067] [Main Processing] Figure 20 is a flowchart showing an example of main processing executed by the main processing unit 144 (Figure 3) of the OS 143 in this embodiment. When the main processing starts, the main processing unit 144 determines whether the corresponding virtual machine has resumed from a suspended state (step S71). If the corresponding virtual machine has not resumed from a suspended state in step S71 (NO in step S71), the main processing unit 144 executes initial setting (step S72). Details of the initial setting will be described with reference to Figure 21.

[0068] When the initial setting in step S72 is completed, the main processing unit 144 starts a transmission thread and a reception thread of the virtual device driver 145' (step S73).

[0069] After starting the transmission thread and the reception thread in step S73, the main processing unit 144 determines whether the processing in the virtual machine 140b has ended (step S74). Also, if the processing in step S71 is to resume from a suspended state (YES in step S71), the main processing unit 144 executes the determination in step S74.

[0070] If the processing by the virtual machine 140b has not ended in step S74 (NO in step S74), the main processing unit 144 waits until the processing by the virtual machine 140b has ended. If the processing by the virtual machine 140b has ended in step S74 (YES in step S74), the main processing unit 144 executes termination processing (step S75) and ends the main processing. Details of the termination processing will be described with reference to FIG. 22.

[0071] [Initial Setting Processing] Figure 21 is a flowchart showing the details of the initial setting processing of step S72 in the flowchart of Figure 20. First, the main processing unit 144 determines whether the virtual machine has started up before the other virtual machine (step S81). If the virtual machine has started up before the other virtual machine in step S81 (YES in step S81), the main processing unit 144 refers to a ring buffer management table (e.g., table 161b) and performs queue allocation processing (step S82). Here, the main processing unit 144 finds an unused ring buffer and sets the ID of the corresponding ring buffer management table to "in use."

[0072] Next, the main processing unit 144 writes the ID of the ring buffer that is in use to the shared memory 160' so that the other virtual device can refer to it (step S83). Also, if the virtual machine has not started up before the other virtual machine in step S81 (NO in step S81), the main processing unit 144 reads the ID of the ring buffer from the shared memory 160' (step S84).

[0073] After writing to the shared memory 160' in step S83 and receiving the queue ID in step S84, the main processing unit 144 further sets the queue ID (step S85). Here, the main processing unit 144 sets the ring buffer ID (145c, etc.) of its own virtual device driver 145' to the ID used in securing the queue (step S82) or receiving the queue ID (step S84). After setting the queue ID in step S85, the initial setting is completed.

[0074] [Termination Processing] Figure 22 shows details of the termination processing in step S75 of the flowchart in Figure 20. First, when the termination processing starts, the main processing unit 144 determines whether the termination processing is due to suspension (interruption) of the virtual machine (step S91). If it is determined in step S91 that the termination processing is not due to suspension (NO in step S91), the main processing unit 144 executes queue release processing (step S92). Here, the main processing unit 144 sets the entry in the ring buffer management table (table 161b, etc.) to "unused."

[0075] After releasing the queue in step S92, or when determining in step S91 that the termination process is to be performed by suspending (YES in step S91), the main processing unit 144 ends the termination process.

[0076] As described above, according to the vehicle control device of this embodiment, when the virtual machine resumes from a suspended state, the queue release process is not executed and the queue remains, so that already transmitted data can be received.

[0077] <Third embodiment> Next, a vehicle control device according to a third embodiment of the present invention will be described with reference to Figures 23 to 26. In Figures 23 to 26, parts corresponding to those in Figures 1 to 22 described in the first and second embodiments are given the same reference numerals, and duplicated explanations will be omitted.

[0078] [Hardware Configuration of Vehicle Control Device] Fig. 23 shows an example of the hardware configuration of the SoC 100' of this embodiment. The SoC 100' of this embodiment is the same as the SoC 100 of the first embodiment in that it includes a CPU core 110 and a memory 130'. In addition to the actual device 120, it also includes a second actual device 121 as an actual device. In the following description, the actual device 120 will be referred to as the first actual device 120.

[0079] The virtual machine image files stored in the memory 130′ include a third virtual machine image file 310a and a fourth virtual machine image file 320a in addition to the first virtual machine image file 140a and the second virtual machine image file 150a. The memory 130′ is similar to the memory 130 described in the first embodiment in that it includes a shared memory 160.

[0080] [Configuration of Vehicle Control Device] Fig. 24 shows an example of the configuration of the SoC 100' according to this embodiment from the perspective of processing operations. Similar to the first embodiment shown in Fig. 5, the first virtual machine 140b is provided with a first application 141 and a second application 142, and the second virtual machine 150b is provided with a third application 151 and a fourth application 152. The applications provided in the third virtual machine 310b and the fourth virtual machine 320b are not shown.

[0081] Data is transferred to each real device 120, 121 via the hypervisor 170. Data is transferred to the first real device 120 from the first virtual machine 140b. For example, control data and the like are transferred from the applications 141, 142 in the first virtual machine 140b to the first real device 120 under the control of the OS 143. Furthermore, control data and the like are transferred from the applications 151, 152 in the second virtual machine 150 to the first real device 120 via virtual device drivers 145", 155, a ring buffer (such as ring buffer 161a), and a transfer program 146. Up to this point, the configuration is the same as that described in the first embodiment.

[0082] Data is transferred from the third virtual machine 310b to the second real device 121. In this case, too, data may be transferred directly from an application in the third virtual machine 310b, or from an application in the second virtual machine 150b or the fourth virtual machine 320b via a ring buffer in the shared memory 160. In other words, in the configuration shown in FIG. 24 , one real device 120 or 121 is assigned to each of the first virtual machine 140b and the third virtual machine 310b. Specifically, virtual machines 310b and 320b other than the first virtual machine 140 and the second virtual machine 150 are prepared as virtual machines, and multiple real devices, such as the first real device 120 and the second real device 121, are also prepared. In this embodiment, when the number of virtual devices is greater than the number of real devices, each real device 120 or 121 can be exclusively used by only one virtual device.

[0083] [Configuration of Virtual Device Driver] FIG. 25 shows an example of the configuration of a virtual device driver 145" provided in the first virtual device 140 of this embodiment. The virtual device driver 145" of this embodiment has an area for performing transfer processing individually for each pair of virtual machines that perform data transfer. Specifically, the virtual device driver 145" has an area for performing data transfer between the first virtual machine 140b' and the second virtual machine 150b, an area for performing data transfer between the first virtual machine 140b' and the third virtual machine 310b, and an area for performing data transfer between the first virtual machine 140b' and the fourth virtual machine 320b.

[0084] Each area has the same configuration as the virtual device driver 145' of the second embodiment shown in Fig. 19. For example, as an area for data transfer between the first virtual machine 140b' and the second virtual machine 150b, a pair of a sending thread and a receiving thread and a ring buffer ID index are provided for each ASIL level. In the example shown in Fig. 25, a sending thread 145a and a receiving thread 145b for ASIL-D and a ring buffer ID index are provided.

[0085] Similarly, an area for data transfer between the first virtual machine 140b' and the third virtual machine 310b, and an area for data transfer between the first virtual machine 140b' and the fourth virtual machine 320b are also provided for each ASIL level.

[0086] Although not shown, the virtual device drivers provided in the second virtual machine 150b, the third virtual machine 310b, and the fourth virtual machine 320b are also provided only for pairs of devices with which data is transferred, similar to the example shown in Fig. 24. For example, the virtual device driver provided in the second virtual machine 150b provides an area for data transfer between the second virtual machine 150b and the first virtual machine 140b' and an area for data transfer between the second virtual machine 150b and the third virtual machine 310b.

[0087] In addition, the virtual device driver provided in the third virtual machine 310b has an area for data transfer between the third virtual machine 310b and the first virtual machine 140b′, an area for data transfer between the third virtual machine 310b and the second virtual machine 150b, and an area for data transfer between the third virtual machine 310b and the fourth virtual machine 320b.

[0088] Furthermore, the virtual device driver provided in the fourth virtual machine 320b is provided with an area for data transfer between the fourth virtual machine 320b and the first virtual machine 140b′, and an area for data transfer between the fourth virtual machine 320b and the third virtual machine 310b.

[0089] 26 is a flowchart showing an example of main processing executed by the main processing unit 144 (FIG. 3) of the OS 143 in this embodiment. When the main processing starts, the main processing unit 144 determines whether the corresponding virtual machine has resumed from a suspended state (step S101). If the corresponding virtual machine has not resumed from a suspended state in step S101 (NO in step S101), the main processing unit 144 determines whether there is an available real device, i.e., an unallocated real device (step S102).

[0090] If there are any unallocated real devices in step S102, the main processing unit 144 performs a process of associating the relevant virtual machine with the unallocated real device, and then transmits the allocation information to all virtual machines (step S103). Thereafter, the main processing unit 144 performs initial setting (step S104). Details of the initial setting are the process described in FIG. 21.

[0091] When the initial setting in step S104 is completed, the main processing unit 144 starts a transmission thread and a reception thread of the virtual device driver 145 (step S105). When starting up in step S105, the transmission thread and the reception thread are started corresponding to the ASIL level of the process to be executed.

[0092] After starting the transmission thread and the reception thread in step S105, the main processing unit 144 determines whether the processing in the virtual machine 140b has ended (step S106). The main processing unit 144 also executes the determination in step S106 if the processing in question is to resume from a suspended state in step S101 (YES in step S101) or if there is no free space in the actual device in step S102 (NO in step S102).

[0093] If the processing by the virtual machine 140b has not finished in step S106 (NO in step S106), the main processing unit 144 waits until the processing by the virtual machine 140b finishes. If the processing by the virtual machine 140b has finished in step S106 (YES in step S106), the main processing unit 144 executes termination processing (step S107) and ends the main processing. Details of the termination processing are the processing described in FIG. 22.

[0094] This configuration makes it possible to avoid concentration of real device allocations on a specific virtual device, thereby achieving load balancing.

[0095] <Fourth embodiment> Next, a vehicle control device according to a fourth embodiment of the present invention will be described with reference to Figures 27 to 29. In Figures 27 to 29, parts corresponding to those in Figures 1 to 26 described in the first to third embodiments are given the same reference numerals, and duplicated explanations will be omitted.

[0096] [Hardware configuration of vehicle control device] Figure 27 shows an example of the hardware configuration of SoC100'' of this embodiment. SoC100'' of this embodiment is the same as SoC100' of the third embodiment in that it has a CPU core 110 and a memory 130''. The real devices include a first real device 120, a second real device 121, and a third real device 122.

[0097] Furthermore, the memory 130″ includes the first virtual machine image file 140 a, the second virtual machine image file 150 a, the third virtual machine image file 310, and the fourth virtual machine image file 320 as virtual machine image files, and further includes a shared memory 160, which is similar to the memory 130 described in the third embodiment.

[0098] [Configuration of Vehicle Control Device] Figure 28 shows an example configuration of the vehicle control device 10" of this embodiment from the perspective of processing operations. The vehicle control device 10" shown in Figure 28 differs from the vehicle control device 10' shown in Figure 24 in that the third virtual machine 310b is connected to and communicates with the third real device 122 in addition to the second real device 121.

[0099] 28, one real device 120 is assigned to the first virtual machine 140b, and two real devices 121 and 122 are assigned to the third virtual machine 310b. Specifically, virtual machines 310b and 320b are prepared in addition to the first virtual machine 140b and the second virtual machine 150b, and multiple real devices are prepared, such as the first real device 120, the second real device 121, and the third real device 122. In this embodiment, when the number of virtual machines is greater than the number of real devices 120 to 122, one virtual machine (for example, the third virtual machine 310b) can exclusively use multiple real devices 121 and 122. The rest of the configuration is the same as that of the vehicle control device 10' shown in FIG. 24.

[0100] [Main Processing] Fig. 29 is a flowchart showing an example of main processing executed in this embodiment by the main processing unit 144 (Fig. 3) of the OS 143. In the main processing shown in Fig. 29, the processing from step S101 to step S105 and the processing from step S106 to step S107 are the same as the main processing of the third embodiment shown in Fig. 26.

[0101] After starting the thread for the virtual device driver in step S105, the main processing unit 144 determines whether the number of allocated actual devices is less than 3 (step S111). If the number of allocated actual devices is less than 3 in step S111 (YES in step S111), the main processing unit 144 returns to the determination in step S102.

[0102] If the number of allocated actual devices is not less than three in step S111 (NO in step S111), the main processing unit 144 proceeds to the determination in step S106. The other steps in the main processing in FIG. 29 are the same as those in FIG. 26.

[0103] By configuring in this way, it is possible to avoid allocating all real devices to the third virtual device 310, and load balancing becomes possible.

[0104] <Modifications> Note that the embodiments described so far have been described in detail to clearly explain the present invention, and are not necessarily limited to those having all of the configurations described.

[0105] In each embodiment, the real devices 120, 121, and 122 are devices that perform communication processing such as Ethernet or CAN. Alternatively, the real devices 120, 121, and 122 can also be devices that perform arithmetic processing. This allows real devices for various purposes, such as arithmetic processing devices in addition to communication devices, to transfer data with a ring buffer secured for each safety level. Alternatively, a first group of devices (one or more) of multiple real devices may perform communication processing, and a second group of devices (one or more) may perform arithmetic processing.

[0106] In addition, in the configuration diagrams shown in Figures 1 and 2, only control lines and information lines that are considered necessary for explanation are shown, and not all control lines and information lines in the product are necessarily shown. In reality, it can be assumed that almost all components are interconnected.

[0107] 10, 10', 10"... Vehicle control device 100, 100', 100"... SoC 110... CPU core 120... First real device 121... Second real device 122... Third real device 130, 130', 130"... Memory 140a, 140a'... First virtual machine image file 140b, 140b'... First virtual machine 141... First application 142... Second application 143... OS 144, 144'... Main processing unit 145, 145, 145"... Virtual device driver 145a... Sending thread 145b... Receiving thread 145c... Ring buffer ID index 146... Transfer program 147... Real device driver 148... Page table 149... Second virtual device driver 149a... Sending thread 149b... Receiving thread 150... Second virtual device 151... Third application 152... Fourth application 155... Virtual device driver 160, 160'... Shared memory 161... Area for ASIL-D 161a, 162a... Ring buffer 161b... Ring buffer management table 162... Area for ASIL-B 163... Area for QM 170... Hypervisor 200... Vehicle control device 310b... Third virtual machine 320b... Fourth virtual machine

Claims

1. A vehicle control device comprising: a hypervisor that virtualizes computer hardware; a first virtual machine and a second virtual machine running on the hypervisor; a real device occupied by and directly accessible to the first virtual machine; and a shared memory accessible to the first virtual machine; the first virtual machine and the second virtual machine communicate via a ring buffer; when the first virtual machine is started before the second virtual machine, the first virtual machine reserves a ring buffer on the shared memory and notifies the second virtual machine of the ring buffer, and the second virtual machine uses the ring buffer and the real device occupied by the first virtual machine; and the first virtual machine reserves the ring buffer for each level determined as a safety level.

2. The vehicle control device according to claim 1, wherein when the second virtual machine is terminated, the first virtual machine releases the ring buffer, and when the second virtual machine is suspended, the first virtual machine does not release the ring buffer.

3. A vehicle control device as described in claim 1, wherein a virtual machine other than the first virtual machine and the second virtual machine is prepared as the virtual machine, and a plurality of real devices are also prepared, and when the number of virtual machines is greater than the number of real devices, the number of virtual machines that can exclusively use each real device is one.

4. A vehicle control device as described in claim 1, wherein a virtual machine other than the first virtual machine and the second virtual machine is prepared as the virtual machine, and a plurality of real devices are also prepared, and when the number of the virtual machines is greater than the number of the real devices, one virtual machine can exclusively use a plurality of real devices.

5. The vehicle control device according to claim 1, wherein the actual device is a device that performs communication processing.

6. The vehicle control device according to claim 1, wherein the actual device is a device that performs arithmetic processing.

7. The vehicle control device according to claim 1, wherein the safety level is a plurality of levels set as automobile safety levels.

Images