WO2022102384A1 - 車載ｅｃｕ、プログラム、及び情報処理方法 - Google Patents

車載ｅｃｕ、プログラム、及び情報処理方法 Download PDF

Info

Publication number
WO2022102384A1
WO2022102384A1 PCT/JP2021/039215 JP2021039215W WO2022102384A1 WO 2022102384 A1 WO2022102384 A1 WO 2022102384A1 JP 2021039215 W JP2021039215 W JP 2021039215W WO 2022102384 A1 WO2022102384 A1 WO 2022102384A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual
verification
verification result
ecu
program
Prior art date
Application number
PCT/JP2021/039215
Other languages
English (en)
French (fr)
Inventor
康彦 野口
秀俊 宮田
広生 堀
Original Assignee
住友電装株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 住友電装株式会社 filed Critical 住友電装株式会社
Publication of WO2022102384A1 publication Critical patent/WO2022102384A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present disclosure relates to an in-vehicle ECU, a program, and an information processing method.
  • This application claims priority based on Japanese Application No. 2020-189750 filed on November 13, 2020, and incorporates all the contents described in the Japanese application.
  • Patent Document 1 There is known an electronic control device that is mounted on a vehicle and performs information processing related to control of the equipment mounted on the vehicle and driving control such as out-of-vehicle communication and automatic driving (for example, Patent Document 1).
  • the electronic control device of Patent Document 1 includes a multi-core CPU having a plurality of cores, and a plurality of program systems operate on the multi-core CPU.
  • the electronic control device of Patent Document 1 is equipped with a hypervisor as a component of a function realized by executing a program, and the hypervisor creates a plurality of virtual machines on a multi-core CPU. Operate in parallel, and run the OS on the created virtual machine.
  • the in-vehicle ECU is an in-vehicle ECU mounted on a vehicle, and is a verification unit that executes a plurality of programs and verifies each of the plurality of programs when the own ECU is activated.
  • a unit and a storage unit for storing a virtualized operating system activated by the control unit are provided, and by starting the virtualized operating system, a plurality of virtual environments serving as an operating environment for the program are generated.
  • the plurality of virtual environments include virtual environments having different priorities according to the program, and the verification unit outputs the first verification result based on the verification of the program whose operating environment is the virtual environment having the higher priority.
  • the management unit that outputs the second verification result based on the verification of the program whose operating environment is the low priority virtual environment and manages the virtualized operating system is the first. 1 If the time zone allocated to the control unit for the plurality of virtual environments is different between the time when the verification result is output and the time when the second verification result is output and after the second verification result is output. Let me.
  • Patent Document 1 does not consider the point of verifying a plurality of virtual machines from the viewpoint of security.
  • the present disclosure provides an in-vehicle ECU or the like that can efficiently perform verification for a plurality of virtual environments generated by a virtualized operating system.
  • an in-vehicle ECU or the like capable of efficiently performing verification for a plurality of virtual environments generated by a virtualized operating system is provided.
  • the in-vehicle ECU is an in-vehicle ECU mounted on a vehicle, and is a control unit that executes a plurality of programs, and verification of each of the plurality of programs when the own ECU is activated.
  • a plurality of virtual environments that serve as an operating environment for the program by starting the virtualized operating system, including a verification unit for performing the above and a storage unit for storing the virtualized operating system activated by the control unit. Is generated, the plurality of virtual environments include virtual environments having different priorities according to the program, and the verification unit first verifies the program based on the verification of the program whose operating environment is the virtual environment having the higher priority.
  • the management unit that outputs the result, outputs the second verification result based on the verification of the program whose operating environment is the low priority virtual environment, and manages the virtualized operating system after the output of the first verification result. Between the time when the first verification result is output and the time when the second verification result is output and after the second verification result is output, the allocation time of the control unit to the plurality of virtual environments Make the band different.
  • a verification unit such as an HSM (Hardware Security Module) verifies a plurality of programs, that is, the in-vehicle ECU is the verification unit. Perform secure boot using. Multiple programs to be verified by the verification department are classified based on the priority of these programs. For example, a high priority program (high priority program) and a low priority program (low priority program) are classified. Program) and included. As a result, the priority of the virtual environment is also determined according to the program to be executed.
  • HSM Hard Security Module
  • the priority of the virtual environment (high priority virtual environment) that is the operating environment of the high priority program is higher than the priority of the virtual environment (low priority virtual environment) that is the operating environment of the low priority program.
  • the verification unit performs verification in descending order of priority. Therefore, the verification unit verifies the low-priority program after verifying the high-priority program.
  • the verification unit outputs the first verification result when the high priority program is verified, and after the output of the first verification result, the verification of the low priority program and the second verification result which is the result of the verification are output. do. Therefore, since the verification unit verifies these programs in the order according to the priority of the programs, efficient verification can be performed.
  • the plurality of programs are executed (started) in any virtual environment (virtual ECU) generated by the virtualized operating system as an operating environment.
  • virtual ECU virtual ECU
  • the in-vehicle ECU uses the high-priority virtual environment as the operating environment from the output of the first verification result to the output of the second verification result. Execution of the program and verification of the program whose operating environment is the virtual environment having the lower priority are performed in parallel.
  • the verification unit can verify the low-priority program in the low-priority virtual environment in parallel with the execution (starting) of the high-priority program in the high-priority virtual environment. Secure boot can be performed.
  • the management unit that manages the virtualization operating system allocates time to the control unit to the high-priority virtual environment according to the first verification result. After the first allocation control for allocating the band is started and the second verification result is output, the allocation time zone of the control unit is allocated to the high priority virtual environment and the low priority virtual environment. The second allocation control is started.
  • the management unit controls the virtual environment with high priority from the time when the first verification result is output to the time when the second verification result is output according to the first verification result.
  • the first allocation control (scheduling based on the first schedule) for allocating the allocation time zone is performed. After that, after the second verification result is output, the management unit allocates the allocation time zone of the control unit to the virtual environment with high priority and the virtual environment with low priority. Second allocation control (second schedule). Scheduling based on) is started. Therefore, according to the first verification result, the allocation time zone of the control unit is assigned to the virtual environment with high priority, and the high priority program with the virtual environment with high priority as the operating environment is executed (started) at an early stage. can do.
  • the storage unit stores the allocation time information that determines the allocation time zone of the control unit for the plurality of virtual environments, and the allocation time information is stored in the storage unit.
  • the management unit includes the first allocation time information corresponding to the first allocation control and the second allocation time information corresponding to the second allocation control, and the management unit uses the first allocation time information as the reference allocation time information. By switching to the second allocation time information from the above, the first allocation control is changed to the second allocation control.
  • the allocated time information stored in the storage unit includes the first allocated time information corresponding to the first schedule and the second allocated time information corresponding to the second schedule.
  • the management unit that manages the virtualized operating system allocates the usage time of the control unit to each of the virtual environments with reference to the first allocation time information or the second allocation time information. After the second verification result is output, the management unit refers to the target (allocation time information) to be referred to when changing from the scheduling based on the first schedule to the scheduling based on the second schedule. To switch to the second allocation time information. As a result, the management unit can efficiently change the scheduling.
  • the verification unit verifies the guest OS that is started in the high-priority virtual environment when outputting the first verification result, and the first is described. 2 In outputting the verification result, the guest OS started in the low priority virtual environment is verified.
  • a guest OS such as Ubuntu (registered trademark) is started in the generated virtual environment.
  • the verification unit verifies the guest OS that is started in the high-priority virtual environment (high-priority virtual environment) that is the operating environment of the high-priority program.
  • the verification unit verifies the guest OS that is started in the low-priority virtual environment (low-priority virtual environment) that is the operating environment of the low-priority program.
  • the verification unit When the storage area (storage area) of the in-vehicle ECU is divided for each of the plurality of virtual environments generated by the virtualization operating system, the verification unit is assigned to each storage area corresponding to each virtual environment. It may be verified. As a result, when the verification unit verifies the program, it also verifies the guest OS (Operating System) that is started in the virtual environment that is the operating environment of the program, so that the program is executed in the in-vehicle ECU. , A secure operating environment can be guaranteed.
  • the guest OS Operating System
  • the priority is determined based on the ASIL (Automotive Safety Integrity Level) of ISO 26262.
  • the virtual environment that is the operating environment of the high-priority program is generated earlier than the virtual environment that is the operating environment of the low-priority program, that is, depending on the program to be executed.
  • the priority of the virtual environment is also determined.
  • the high-priority program can be executed before the verification of the verification unit for the low-priority program is completed.
  • the priority is determined based on ASIL (Automotive Safety Integrity Level), that is, as the level of ASIL improves, the priority also increases.
  • ASIL Automotive Safety Integrity Level
  • the control unit is composed of a multi-core CPU including a plurality of cores, and each of the plurality of virtual environments is one of the plurality of cores.
  • the verification unit outputs the first verification result based on the verification of all the programs assigned to each of the plurality of cores and whose operating environment is the high priority virtual environment.
  • the second verification result is output based on the verification of a plurality of programs whose operating environment is a low priority virtual environment, and the management unit outputs the second verification result in each of the plurality of cores. Allocate the allocation time zone to the plurality of virtual environments.
  • the verification unit outputs the first verification result based on the verification of the program in which the virtual environment with high priority is the operating environment in each of the cores, and then sets the virtual environment with low priority as the operating environment.
  • the second verification result is output based on the verification of the program to be performed.
  • the management unit schedules each core to allocate the allocation time zone to the plurality of virtual environments according to the first verification result and the second verification result. Therefore, even if the in-vehicle ECU includes a control unit composed of a multi-core CPU, it is possible to efficiently verify a plurality of virtual environments generated by the virtualized operating system and to execute a high priority program in each core. Can be done early.
  • the program according to one aspect of the present disclosure is a program mounted on a vehicle and causing a computer that executes a plurality of programs to execute a process in a plurality of virtual environments generated by activating a virtualized operating system. Therefore, the plurality of virtual environments include virtual environments having different priorities according to the program using the virtual environment as the operating environment, and the first is based on the verification of the program using the high priority virtual environment as the operating environment. After outputting the verification result and outputting the first verification result, the second verification result is output based on the verification of the program whose operating environment is the virtual environment having the lower priority, and after the first verification result is output.
  • the time zone allocated to the control unit of the computer for the plurality of virtual environments is different between the time until the second verification result is output and the time after the second verification result is output.
  • the computer can function as an in-vehicle ECU that can efficiently perform verification against a plurality of virtual environments generated by the virtualized operating system.
  • the information processing method causes a computer that executes a plurality of programs to execute a process in a plurality of virtual environments that are mounted on a vehicle and generated by activating a virtualized operating system. It is an information processing method, and the plurality of virtual environments include virtual environments having different priorities according to a program having the virtual environment as an operating environment, and verification of a program having the high priority virtual environment as an operating environment.
  • the first verification result is output based on the above, and after the output of the first verification result, the second verification result is output based on the verification of the program whose operating environment is the virtual environment having a low priority, and the first verification result is The time zone assigned to the control unit of the computer for the plurality of virtual environments is different between the time when the second verification result is output and the time after the second verification result is output.
  • 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 the physical configuration of the vehicle-mounted ECU 2.
  • the in-vehicle system S includes a plurality of in-vehicle ECUs 2 mounted on the vehicle C and an in-vehicle device 3 connected to the in-vehicle ECU 2.
  • the plurality of vehicle-mounted ECUs 2 are individually connected to the integrated vehicle-mounted ECU 2 (integrated ECU) that controls the entire vehicle C and the integrated vehicle-mounted ECU 2 in a communicable manner and directly connected to the vehicle-mounted device 3. It may include ECU 2 (individual ECU).
  • the integrated in-vehicle ECU 2 may be communicably connected to an external server 100 connected to an external network such as the Internet via an external communication device 1.
  • the integrated in-vehicle ECU 2 and the plurality of individual in-vehicle ECUs 2 are communicably connected by an in-vehicle network 4 forming a star-shaped network topology, and the integrated in-vehicle ECU 2 is , Is located at the center of the star-shaped network topology. Further, adjacent individual vehicle-mounted ECUs 2 may be connected to each other to form a loop-shaped network topology, enabling bidirectional communication and achieving redundancy.
  • a plurality of individual in-vehicle ECUs 2 are arranged in each area of the vehicle C, and an actuator 30 such as an illumination lamp and an in-vehicle device 3 such as a sensor 31 are directly connected by a wire harness such as a serial cable (direct wire). It is connected.
  • the individual vehicle-mounted ECU 2 acquires (receives) a signal (input signal) output from the sensor, and transmits a request signal generated based on the acquired input signal to the integrated vehicle-mounted ECU 2.
  • the individual in-vehicle ECU 2 controls the drive of the actuator 30 such as the illumination lamp directly connected to the own ECU based on the control signal transmitted from the integrated in-vehicle ECU 2.
  • the individual in-vehicle ECU 2 is an in-vehicle relay device such as a gateway or an ether switch that relays communication between a plurality of in-vehicle devices 3 connected to the individual in-vehicle ECU 2 or communication between the in-vehicle device 3 and another in-vehicle ECU 2. It may be a relay control ECU that functions as.
  • the individual in-vehicle ECU 2 distributes and relays the electric power output from the power storage device in addition to the relay related to communication, and also functions as a power distribution device to supply the in-vehicle device 3 connected to the own ECU. ) May be.
  • the integrated in-vehicle ECU 2 generates and outputs a control signal to each in-vehicle device 3 based on data from the in-vehicle device 3 relayed via another in-vehicle ECU 2 such as an individual in-vehicle ECU 2.
  • a central control device such as a vehicle computer.
  • the integrated in-vehicle ECU 2 controls to control the actuator 30 that is the target of the request signal based on information or data such as a request signal output (transmitted) from another in-vehicle ECU 2 such as an individual in-vehicle ECU 2.
  • a signal is generated, and the generated control signal is output (transmitted) to another vehicle-mounted ECU 2.
  • the in-vehicle system S is configured by the integrated in-vehicle ECU 2 (integrated ECU) and the individual in-vehicle ECU 2 (individual ECU), but the present invention is not limited thereto.
  • the in-vehicle system S may be composed of a plurality of in-vehicle ECUs 2 connected peer-to-peer by a relay device such as a CAN (Controller Area Network) gateway or an ether switch.
  • a relay device such as a CAN (Controller Area Network) gateway or an ether switch.
  • the in-vehicle device 3 includes, for example, various sensors 31 such as LiDAR (Light Detection and Ringing), a light sensor, a CMOS camera, an infrared sensor, a switch such as a door SW (switch) and a lamp SW, a lamp, a door opening / closing device, a motor device, and the like. Includes the actuator 30 of.
  • sensors 31 such as LiDAR (Light Detection and Ringing), a light sensor, a CMOS camera, an infrared sensor, a switch such as a door SW (switch) and a lamp SW, a lamp, a door opening / closing device, a motor device, and the like.
  • sensors 31 such as LiDAR (Light Detection and Ringing), a light sensor, a CMOS camera, an infrared sensor, a switch such as a door SW (switch) and a lamp SW, a lamp, a door opening / closing device,
  • 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 includes a storage unit such as a RAM (RandomAccessMemory), a ROM (ReadOnlyMemory), or a hard disk.
  • the integrated in-vehicle ECU 2 integrated ECU is communicably connected to the external communication device 1 and communicates with the external server 100 connected via the external network via the external communication device 1, and communicates with the external server 100 and the vehicle. Communication with another vehicle-mounted ECU 2 or vehicle-mounted device 3 mounted on C may be relayed.
  • the out-of-vehicle communication device 1 includes an out-of-vehicle communication unit (not shown) and an input / output I / O (not shown) for communicating with the integrated in-vehicle ECU 2 (integrated ECU).
  • the out-of-vehicle communication unit is a communication device for wireless communication using mobile communication protocols such as 4G, LTE (Long Term Evolution / registered trademark), 5G, and WiFi, and is an antenna 11 connected to the out-of-vehicle communication unit.
  • Data is sent and received to and from the external server 100 via the above. Communication between the external communication device 1 and the external server 100 is performed via, for example, a public line network or an external network N such as 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-mounted communication device 1 and the vehicle-mounted ECU 2 communicate with each other via a wire harness such as an input / output I / F and a serial cable connected to the input / output I / F.
  • the vehicle-mounted communication device 1 is a separate device from the vehicle-mounted ECU 2, and these devices are communicably connected by input / output I / F or the like, but the present invention is not limited to this.
  • the vehicle-mounted communication device 1 may be built in the vehicle-mounted ECU 2 as a component of the vehicle-mounted ECU 2.
  • the in-vehicle ECU 2 (integrated ECU, individual ECU) includes a control unit 20, a storage unit 21, an input / output I / F 22, an in-vehicle communication unit 23, and a verification unit 24.
  • the control unit 20 is configured by a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or the like, and various control processes and various control processes can be performed by reading and executing a control program and data stored in advance in the storage unit 21. It is designed to perform arithmetic processing and the like.
  • 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 a software processing unit that performs software processing such as a CPU, and includes a hardware processing unit that performs various control processing and arithmetic processing in hardware processing such as FPGA, ASIC, or SOC. It may be.
  • the storage unit 21 is a volatile memory element such as a RAM (RandomAccessMemory), a non-volatile memory element such as a ROM (ReadOnlyMemory), an EEPROM (ElectricallyErasableProgrammableROM), or a flash memory, or a storage device thereof. It is configured by the combination of the above, and the control program and the data to be referred to at the time of processing are stored in advance.
  • the control program includes, for example, a plurality of programs (applications) for controlling various in-vehicle devices 3, or a program (application) for performing target recognition for performing automated operation based on output data from a LiDAR or CMOS camera. Includes programs (applications). Further, a virtual operating system such as Hypervisor or VMware is stored in the storage unit 21 of the vehicle-mounted ECU 2.
  • a virtual operating system such as Hypervisor or VMware is stored in the storage unit 21 of the vehicle-mounted ECU 2.
  • the input / output I / F 22 is, for example, a communication interface for serial communication, like the input / output I / F 22 of the external communication device 1.
  • the vehicle-mounted ECU 2 is communicably connected to the external communication device 1 via a wire harness such as an input / output I / F 22 and a serial cable.
  • the in-vehicle communication unit 23 is an input / output interface using, for example, a CAN (Controller Area Network) or Ethernet (Ethernet / registered trademark) communication protocol, and the control unit 20 is connected to the in-vehicle network 4 via the in-vehicle communication unit 23. It communicates with another vehicle-mounted ECU 2 that has been installed.
  • CAN Controller Area Network
  • Ethernet Ethernet / registered trademark
  • the verification unit 24 is, for example, an HSM (Hardware Security Module) or an SHE (Secure Hardware Extension), and is configured as a device or a separate module from the control unit 20 configured by a CPU or the like.
  • the verification unit 24 composed of the HSM or the like plays a part in the secure boot process performed when the in-vehicle ECU 2 (own ECU) is started (booted), and is stored in the storage unit 21. It is a functional module that verifies the appropriateness (completeness) or soundness of software executed when the in-vehicle ECU 2 is started, such as a program.
  • the verification unit 24 includes, for example, a processor for cryptographic processing, and uses a cryptographic algorithm such as CMAC (Cipher-based Message Authentication Code) to ensure the appropriateness (completeness) of the program to be verified and the software such as the guest OS. ) Is verified.
  • the verification unit 24 verifies the appropriateness (integrity) of each of the plurality of programs to be verified in the secure boot process (secure boot sequence) performed when the in-vehicle ECU 2 is started, and outputs the verification result for each program. ..
  • the verification result includes a positive verification result indicating that the program or the like is legitimate, or a negative verification result indicating that the program or the like has been tampered with and is fraudulent.
  • the verification unit 24 is configured to perform verification in two stages for all virtual ECUs 200 (guest OS, program).
  • the verification unit 24 verifies the high priority virtual ECU 200 among the virtual ECUs 200 assigned to each core as the first step, and becomes other than the high priority virtual ECU 200 as the second step. , Verify the low priority virtual ECU 200.
  • the verification unit 24 outputs the first verification result (reset release signal) to the control unit 20 as the verification result for the high priority virtual ECU 200, and controls the second verification result as the verification result for the low priority virtual ECU 200.
  • the verification unit 24 may output a reset release signal to the core constituting the control unit 20 when outputting the first verification result. Alternatively, the verification unit 24 may output a reset release signal to the core in addition to the output of the first verification result.
  • FIG. 3 is a block diagram illustrating a logical configuration (virtual ECU 200) of the in-vehicle ECU 2.
  • the illustration in this embodiment illustrates the logical configuration of the in-vehicle ECU 2, and is a program executed in a virtual environment and a virtual environment management program with the hardware layer (physical base) by the control unit 20 or the like as the lowest layer.
  • It is a block diagram exemplifying the hierarchical structure with the software layer as the uppermost layer by the above.
  • the storage unit 21 of the vehicle-mounted ECU 2 stores, for example, a virtual operating system such as Hypervisor or VMware, and the control unit 20 of the vehicle-mounted ECU 2 is activated by using the virtual operating system to perform virtual operating.
  • a plurality of virtual environments can be constructed on the system.
  • the program for controlling various in-vehicle devices 3 is executed using any one of these plurality of virtual environments as the operating environment. That is, these programs are executed on one of the virtual environments (virtual ECU 200).
  • a single task or a plurality of tasks are generated according to the processing content of the program. The task results in the execution of more subdivided or segmented processing units.
  • the virtualization method is a hypervisor method in which a hardware resource such as a control unit 20 is directly accessed by a virtual operating system as shown in the figure of the present embodiment, or a Linux (Linux) between the virtual operating system and the hardware resource. It may be a host OS system in which an operating system such as (registered trademark) intervenes. Alternatively, a container-type virtual operating system may be used.
  • the in-vehicle ECU 2 activated by using the virtual operating system can construct a plurality of virtual environments by the function of the virtual operating system, and the plurality of virtual environments include hardware resources such as a control unit 20 included in the in-vehicle ECU 2. Assigned. Each of the virtual environments to which these hardware resources are assigned is provided with a virtual control unit 20 (virtual control unit), a storage unit 21 (virtual storage unit), and an in-vehicle communication unit 23 (virtual in-vehicle communication unit). It functions as an ECU 200.
  • a virtual control unit 20 virtual control unit
  • storage unit 21 virtual storage unit
  • in-vehicle communication unit 23 virtual in-vehicle communication unit
  • a guest OS such as Ubuntu (registered trademark) is stored in each virtual storage unit of each virtual ECU 200, and each virtual ECU 200 starts a guest OS and executes a program on the guest OS.
  • the guest OS may be a different type of OS depending on the individual virtual ECU 200.
  • the substance of the virtual storage unit is the storage area of the storage unit 21 assigned to each of the virtual ECUs 200, it goes without saying that the guest OS is also stored in the storage unit 21 in the same manner as the virtual operating system.
  • a container-type virtual operating system even if a guest OS is not required, a container (virtual environment) is created on the virtual operating system, and a program is executed on the container (virtual environment). good.
  • the control unit 20 of the in-vehicle ECU 2 activated by using the virtual operating system is a program (virtual environment management program) that manages all virtual environments in one of the constructed virtual environments (virtual ECU 200). ) Is executed. That is, the virtual ECU 200 that executes the virtual environment management program functions as a control panel of the virtual operating system, and corresponds to the management unit 210. Alternatively, the virtual operating system itself may include the function as the management unit 210.
  • the verification unit 24, which is a device separate from the control unit 20, is not subject to virtualization by the virtual operating system, and the verification unit 24 constitutes the management unit 210 (control panel of the virtual operating system) or the control unit 20. It will communicate with the core.
  • the storage unit 21 stores allocation time information (first allocation time table 21A, second allocation time table 21B), which will be described later.
  • the management unit 210 selects the first allocation time table 21A or the second allocation time table 21B according to the output contents (first detection result, second detection result) from the verification unit 24, and based on the selected table.
  • the usage time of the control unit 20 (each core) is allocated (scheduled) to each virtual environment (virtual ECU 200).
  • FIG. 4 is a functional block diagram illustrating a functional unit in the virtual ECU 200.
  • FIG. 5 is an explanatory diagram illustrating the first allocation time table 21A (first allocation time information).
  • FIG. 6 is an explanatory diagram illustrating the second allocation time table 21B (second allocation time information).
  • the virtual control unit (control unit 20) of the virtual ECU 200 functions as a task generation unit 201 by executing a program stored in the virtual storage unit (storage 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 is a virtual environment management program stored in the virtual storage unit (storage unit 21). By executing the above, it functions as a control panel of a virtual operating system and corresponds to the management unit 210 in the present embodiment.
  • the management unit 210 includes a table selection unit 211 and an allocation execution unit 212.
  • control unit 20 When the control unit 20 is composed of, for example, a multi-core, the core in which the usage time is allocated to the management unit 210 (control panel of the virtual operating system) and the operating environment of the program for controlling the in-vehicle device 3 and the like.
  • the core may be different from the core to which the usage time is allocated to the virtual environment (virtual ECU 200).
  • the management unit 210 continues the process (scheduling) of allocating the usage time of any of the cores constituting the control unit 20 to the virtual ECU 200 by referring to the allocation time information stored in the storage unit 21, for example. I am doing it.
  • the allocation time information referred to by the management unit 210 is stored in the storage unit 21 in a table format (look-up table) as, for example, the first allocation time table 21A and the second allocation time table 21B. Has been done.
  • the management items of the first allocation time table 21A and the second allocation time table 21B are the virtual ECU 200 item, the allocation core item, the allocation cycle item, the allocation time item, the program type item, the ASIL item, and the priority. Includes degree items. That is, the management items of the first allocation time table 21A and the second allocation time table 21B are the same.
  • the name or identifier of the virtual ECU 200 shared by time-dividing the same control unit 20 is stored.
  • the first allocation time table 21A in the present embodiment only the virtual ECU 200 (VM1, VM5) having a high priority is defined.
  • the second allocation time table 21B all virtual ECUs 200 (VM1 to VM7) including the virtual ECU 200 having a high priority and the virtual ECU 200 having a low priority are defined. Therefore, by selecting the first allocation time table 21A, the management unit 210 allocates the usage time of the control unit 20 (core 1, core 2) targeting only the virtual ECU 200 (VM1, VM5) having a high priority. It can be performed. By selecting the second allocation time table 21B, the management unit 210 can allocate the usage time of the control unit 20 (core 1, core 2) for all the virtual ECUs 200 (VM1 to VM7). ..
  • the number or identifier of the core assigned to the corresponding virtual ECU 200 (virtual ECU 200 stored in the same record) is stored.
  • the virtual ECU 200 (VM1 to VM6) to which allocation is performed periodically (steadily), the number of any one of the cores is stored. Thereby, which core (core number) usage time is allocated to each virtual ECU 200 is determined.
  • the virtual ECU 200 (VM1) is assigned to the core 1
  • the virtual ECU 200 (VM5) is assigned to the core 2.
  • the virtual ECU 200 (VM1, VM2, VM3, VM4) is assigned to the core 1
  • the virtual ECU 200 (VM5, VM6, VM7) is assigned to the core 2.
  • the allocation cycle in the virtual ECU 200 in which allocation is performed periodically (steadily) is stored.
  • the allocated time allocated to each virtual ECU 200 is stored. The total value of these allocation times corresponds to the allocation cycle.
  • the number of virtual ECUs 200 allocated to a single core is also one, so the allocation cycle and the allocation time are equal values.
  • the second allocation time table 21B since the number of virtual ECUs 200 allocated to a single core is two or more, the total value of the allocation times allocated to each virtual ECU 200 in each core is the allocation cycle. Corresponds to.
  • the program type item stores the type of the program executed in each corresponding virtual ECU 200 (virtual environment) (stored in the same record).
  • the ASIL item stores the ASIL level, which indicates the safety index of the program to be executed.
  • a value indicating the priority of the program (high / low in this embodiment) is stored.
  • the order of verification of the verification unit 24 for the virtual ECU 200 corresponding to the program and the order of generation of the virtual ECU 200 by the management unit 210 are determined.
  • the priority is determined based on the functions of the corresponding in-vehicle device 3 and the program to be executed, and may be determined based on, for example, the ASIL (Automotive Safety Integrity Level) of ISO 26262.
  • the levels of ASIL are classified into the levels of QM, ASIL-A, ASIL-B, ASIL-C, and ASIL-D.
  • the QM level is a normal quality control that does not require the application of functional safety according to ISO 26262.
  • ASIL-A to D it is necessary to apply the functional safety according to ISO26262, and the functional safety requirement becomes stricter from ASIL-A to ASIL-D. That is, it can be considered that the priority of the QM level is the lowest and the priority of the ASIL-D level is the highest.
  • ASIL is used as an index indicating the priority of the program, but the present invention is not limited to this.
  • the priority of the program may be determined by a value (priority setting value) different from that of ASIL, and the priority setting value is, for example, a user, an administrator, or a manufacturer of the in-vehicle system S. It may be set to be individually changeable by a person.
  • the priority of the ASIL-D program and the virtual ECU 200 (core 1: VM1, core 2: VM5) which is the operating environment of the program is set. , High priority.
  • the priority of the virtual ECU 200 (VM2, VM3, VM4, VM6, VM7) is set to a low priority.
  • the classification of priorities in the present embodiment is an example and is not limited to this.
  • the verification unit 24 refers to the first allocation time table 21A stored in the storage unit 21 and verifies the virtual ECU 200 having a high priority in the virtual ECU 200 corresponding to each core constituting the control unit 20.
  • the first verification result (reset release signal) is output to the table selection unit 211.
  • the verification unit 24 may output a reset release signal to each corresponding core as the first verification result.
  • the table selection unit 211 selects the allocation time information (first allocation time table 21A) that defines the first schedule corresponding to the virtual ECU 200 having a high priority.
  • the allocation instruction according to the first allocation time table 21A is output to the allocation execution unit 212.
  • the allocation execution unit 212 generates a virtual ECU 200 with a high priority based on the allocation instruction, and allocates the usage time of the allocated control unit 20 (core).
  • the task generation unit 201 of the high-priority virtual ECU 200 executes a high-priority program applied to the self-virtual ECU 200 to generate a task, and a more subdivided or divided processing unit is executed by the task. Will be done.
  • the verification unit 24 refers to, for example, the second allocation time table 21B stored in the storage unit 21, and verifies the low priority virtual ECU 200 in the virtual ECU 200 corresponding to each core constituting the control unit 20. , The second verification result is output to the table selection unit 211.
  • the process related to the verification of the low priority virtual ECU 200 by the verification unit 24 and the process related to the high priority virtual ECU 200 by the management unit 210 are executed in parallel.
  • the table selection unit 211 defines the second schedule corresponding to all the virtual ECUs 200 (high priority and low priority virtual ECUs 200). Allocation time information (second allocation time table 21B). ) Is selected, and the allocation instruction according to the second allocation time table 21B is output to the allocation execution unit 212.
  • the allocation execution unit 212 generates a virtual ECU 200 with a low priority based on the allocation instruction. From this, all virtual ECUs 200 are generated. The allocation execution unit 212 allocates the usage time of the control unit 20 (core) assigned to the virtual ECU 200 to all the virtual ECUs 200. That is, the allocation execution unit 212 switches from the first schedule (first allocation time table 21A) to the second schedule (second allocation time table 21B) and reschedules based on the output content from the verification unit 24. Functions as a department.
  • FIG. 7 is an explanatory diagram regarding the assigned time zone of the control unit 20 for the virtual environment.
  • the control unit 20 is a dual-core CPU composed of two cores.
  • the verification unit 24 verifies the virtual ECU 200 (VM1 or the like) having a high priority in the core 1 and the core 2 after starting the firmware (FW) in the own unit.
  • the first detection result (reset release signal) is output to each core. After outputting the first detection result (reset release signal), the verification unit 24 verifies the low priority virtual ECU 200 and outputs the second detection result.
  • Each core to which the first detection result (reset release signal) is input initializes BSW (BasicSoftWare) according to standards such as Hypervisor and AUTOSAR, and has a high priority to which the usage time of the core is allocated.
  • BSW BasicSoftWare
  • the virtual ECU 200 is generated.
  • the high-priority program is executed (started) in the high-priority virtual ECU 200 (virtual environment).
  • the management unit 210 which functions as a control panel of the virtual operating system, allocates (schedules) the usage time of the control unit 20 (core) to these high-priority virtual ECUs 200 based on the first allocation time table 21A.
  • a low priority virtual ECU 200 to which the usage time of the core is allocated is generated.
  • the low priority program is executed (started).
  • all virtual ECUs 200 are generated, and each program is executed (started) in each virtual ECU 200 (virtual environment).
  • the management unit 210 which functions as a control panel of the virtual operating system, allocates (schedules) the usage time of the control unit 20 (core) to all the virtual ECUs 200 based on the second allocation time table 21B.
  • FIG. 8 is an explanatory diagram illustrating the sequence by the control unit 20 and the verification unit 24.
  • the control unit 20 core 1, core 2 is configured to be composed of a dual-core CPU.
  • the processing of the control unit 20 and the verification unit 24 in the present embodiment is performed as a part of the secure boot sequence performed when the vehicle-mounted ECU 2 is activated.
  • the verification unit 24 verifies the high-priority virtual ECU 200 (guest OS, program) executed by the core 1 (S01).
  • the verification unit 24 outputs (transmits) the first verification result in the core 1 to the control unit 20 (S02).
  • the verification unit 24 may output a reset release signal to the core 1 as the first verification result.
  • the verification unit 24 may output a reset release signal to the core 1 in addition to the output of the first verification result.
  • the control unit 20 acquires the first verification result in the core 1 (S03).
  • the control unit 20 generates a high-priority virtual environment (virtual ECU 200: VM1) executed by the core 1 based on the first verification result, and executes a high-priority program using the virtual environment as an operating environment ( (Start) (S04).
  • the control unit 20 schedules the allocated time in the core 1 according to the first schedule (S05).
  • the usage time of the core 1 (control unit 20) is allocated only to the virtual ECU 200 (VM1) having a high priority.
  • the control regarding the generation of the virtual environment (virtual ECU 200) and the allocation of the usage time of the core 1 to the virtual environment (virtual ECU 200) functions as the control panel of the virtual operating system. It is performed by the management unit 210.
  • the verification unit 24 verifies the high-priority virtual ECU 200 (guest OS, program) executed by the core 2 (S06).
  • the verification unit 24 outputs (transmits) the first verification result in the core 2 to the control unit 20 (S07).
  • the verification unit 24 may output a reset release signal to the core 2 as the first verification result.
  • the verification unit 24 may output a reset release signal to the core 2 in addition to the output of the first verification result.
  • the control unit 20 acquires the first verification result in the core 2 (S08).
  • the control unit 20 generates a high-priority virtual environment (virtual ECU 200: VM5) executed in the core 2 based on the first verification result, and executes a high-priority program using the virtual environment as an operating environment ( (Start) (S09).
  • the control unit 20 schedules the allocated time in the core 2 according to the first schedule (S10).
  • the usage time of the core 2 (control unit 20) is allocated only to the virtual ECU 200 (VM5) having a high priority.
  • the control regarding the generation of the virtual environment (virtual ECU 200) and the allocation of the usage time of the core 2 to the virtual environment (virtual ECU 200) functions as the control panel of the virtual operating system. It is performed by the management unit 210.
  • the verification unit 24 verifies the low-priority virtual ECU 200 (guest OS, program) executed by the core 1 (S11).
  • the verification unit 24 outputs (transmits) the second verification result in the core 1 to the control unit 20 (S12).
  • the control unit 20 acquires the second verification result in the core 1 (S13).
  • the control unit 20 creates a low-priority virtual environment (virtual ECU 200: VM2, VM3, VM4) executed in the core 1 based on the second verification result, and uses the virtual environment as an operating environment to generate a low-priority virtual environment.
  • Execute start) the program (S14).
  • the control unit 20 schedules the allocation time in the core 1 in the second schedule (second allocation time table 21B) (S15).
  • the usage time of the core 1 (control unit 20) is used for all the virtual ECUs 200 (VM1, VM2, VM3, VM4) sharing the core 1. Is assigned.
  • the verification unit 24 verifies the low-priority virtual ECU 200 (guest OS, program) executed by the core 2 (S16).
  • the verification unit 24 outputs (transmits) the second verification result in the core 2 to the control unit 20 (S17).
  • the control unit 20 acquires the second verification result in the core 2 (S18). Based on the second verification result, the control unit 20 generates a low-priority virtual environment (virtual ECU 200: VM6, VM7) executed in the core 2, and uses the virtual environment as an operating environment to create a low-priority program. Execute (start) (S19). The control unit 20 schedules the allocation time in the core 2 in the second schedule (second allocation time table 21B) (S20). In the second schedule (second allocation time table 21B) in the present embodiment, the usage time of the core 2 (control unit 20) is set for all the virtual ECUs 200 (VM5, VM6, VM7) sharing the core 2. Assigned.
  • the in-vehicle ECU 2 generates a high-priority virtual environment by the control unit 20 (management unit 210), executes (starts) a high-priority program in the high-priority virtual environment, and is low by the verification unit 24. Verification of the priority virtual ECU 200 is performed in parallel. As a result, while the high-priority virtual ECU 200 (virtual environment) is generated at an early stage and the high-priority program is executed (started) at an early stage, the verification unit 24 delays the verification of all the virtual ECU 200 (virtual environment). The secure boot process can be efficiently performed without causing the problem.
  • FIG. 9 is a flowchart illustrating the processing of the control unit 20 and the verification unit 24 of the in-vehicle ECU 2.
  • the control unit 20 of the vehicle-mounted ECU 2 is, for example, when the vehicle-mounted ECU 2 (own ECU) is started (booted) when the vehicle C transitions from a stopped state (IG switch is off) to a started state (IG switch is on).
  • the following processing is performed based on the secure boot processing (secure boot sequence) performed in.
  • the verification unit 24 of the in-vehicle ECU 2 verifies the virtual ECU 200 having a high priority (S101).
  • the verification unit 24 refers to, for example, the first allocation time table 21A stored in the memory, and identifies the high priority virtual ECU 200 associated with each core.
  • the verification unit 24 may verify the program executed by the virtual ECU 200 and the guest OS to be activated.
  • the storage area in the storage unit 21 is divided for each of the virtual ECUs 200
  • the verification unit 24 verifies the program or guest OS stored in the storage area corresponding to the virtual ECU 200. May be.
  • the verification unit 24 is a high-priority virtual ECU 200 (high-priority virtual ECU 200) executed in each core. Will be verified in sequence.
  • the verification unit 24 of the in-vehicle ECU 2 determines whether or not the verification of the high priority virtual ECU 200 in all the cores has been completed (S102). When the verification of the high priority virtual ECU 200 in all the cores is not completed (S102: NO), the verification unit 24 of the vehicle-mounted ECU 2 performs a loop process in order to execute the process of S101 again.
  • the verification unit 24 of the vehicle-mounted ECU 2 When the verification of the high priority virtual ECU 200 in all the cores is completed (S102: YES), the verification unit 24 of the vehicle-mounted ECU 2 outputs the first verification result (reset release signal) (S103).
  • the verification unit 24 may output the first verification result for each core for which verification has been completed when outputting the first verification result for each core.
  • the control unit 20 is composed of a dual core CPU including two cores (core 1 and core 2)
  • the verification unit 24 checks the core 1 when the verification of the high priority virtual ECU 200 in the core 1 is completed.
  • the first verification result may be output, and after the output of the first verification result, the first verification result for the core 2 may be output when the verification of the high priority virtual ECU 200 in the core 2 is completed.
  • the verification unit 24 of the in-vehicle ECU 2 verifies the virtual ECU 200 having a low priority (S104).
  • the verification unit 24 refers to, for example, the second allocation time table 21B stored in the storage unit 21 and identifies the low priority virtual ECU 200 associated with each core.
  • the verification unit 24 of the in-vehicle ECU 2 determines whether or not the verification of the low priority virtual ECU 200 in all the cores has been completed (S105). When the verification of the low priority virtual ECU 200 in all the cores is not completed (S105: NO), the verification unit 24 of the vehicle-mounted ECU 2 performs a loop process in order to execute the process of S105 again.
  • the verification unit 24 of the in-vehicle ECU 2 outputs the second verification result (S106).
  • the verification unit 24 may output the second verification result for each core for which verification has been completed when outputting the second verification result for each core.
  • the control unit 20 is composed of a dual core CPU including two cores (core 1 and core 2)
  • the verification unit 24 checks the core 2 when the verification of the low priority virtual ECU 200 in the core 2 is completed.
  • the second verification result may be output, and after the output of the second verification result, the second verification result for the core 2 may be output when the verification of the low priority virtual ECU 200 in the core 2 is completed.
  • the substance of the management unit 210 is the control unit 20 of the in-vehicle ECU 2.
  • the management unit 210 of the in-vehicle ECU 2 determines whether or not the first verification result (reset release signal) has been acquired (S111).
  • the management unit 210 determines whether or not the first verification result (reset release signal) output from the verification unit 24 has been acquired.
  • the control unit 20, which is the actual state of the management unit 210, is in a state of waiting for the first verification result (reset release signal) output from the verification unit 24 configured by the HSM or the like.
  • the management unit 210 can recognize that the process at the time of activation in the in-vehicle ECU 2 is being performed.
  • the core to which the reset release signal is input becomes an active state.
  • BSW Basic SoftWare
  • BSW may be initialized according to standards such as Hypervisor and AUTOSAR.
  • the management unit 210 of the vehicle-mounted ECU 2 selects the first schedule (S112).
  • the management unit 210 selects the first allocation time table 21A that defines the first schedule as the schedule table used for allocating the usage time of the control unit 20 (core) to the virtual ECU 200.
  • the allocation time zone and the allocation cycle of the high priority virtual ECU 200 to which the usage time is allocated in each core are defined.
  • the management unit 210 of the in-vehicle ECU 2 executes scheduling based on the selected schedule (first schedule) (S113).
  • the management unit 210 allocates the usage time of the control unit 20 (core) to the virtual ECU 200 based on the contents defined in the first allocation time table 21A.
  • the usage time of the control unit 20 (core) is set to the first schedule (the first schedule (core) with respect to the high priority virtual ECU 200 (high priority virtual ECU 200) that is the verification target in the first verification result (reset release signal). It is allocated based on the first allocation time table 21A), and the high priority program is executed (started) on the high priority virtual ECU 200 (virtual environment).
  • the management unit 210 of the vehicle-mounted ECU 2 After the processing of S113 is executed, or when the management unit 210 of the vehicle-mounted ECU 2 has not acquired the first verification result (reset release signal) (S111: NO), the management unit 210 of the vehicle-mounted ECU 2 obtains the second verification result. It is determined whether or not it has been acquired (S1111). The management unit 210 determines whether or not the second verification result has been acquired based on whether or not the second verification result from the verification unit 24 has been input. When the second verification result has not been acquired (S1111: NO), the management unit 210 of the vehicle-mounted ECU 2 performs a loop process in order to execute the process of S1111 again.
  • the management unit 210 of the vehicle-mounted ECU 2 selects the second schedule (S1112).
  • the verification unit 24 has completed the verification for all the virtual ECUs 200 (program and guest OS), that is, the second verification result corresponds to the verification completion notification of all the virtual ECUs 200. ..
  • the management unit 210 selects the second allocation time table 21B that defines the second schedule as the schedule table used for allocating the usage time of the control unit 20 (core) to the virtual ECU 200.
  • the second allocation time table 21B when the control unit 20 is composed of a multi-core CPU, the allocation time zone and the allocation cycle of all the virtual ECUs 200 to which the usage time is allocated in each core are defined.
  • the management unit 210 of the in-vehicle ECU 2 executes scheduling based on the selected schedule (second schedule) (S1113).
  • the management unit 210 allocates the usage time of the control unit 20 (core) to the virtual ECU 200 based on the contents defined in the second allocation time table 21B.
  • the usage time of the control unit 20 (core) is based on the second schedule (second allocation time table 21B). It is assigned and the program is executed (started) on each virtual ECU 200 (virtual environment).
  • the in-vehicle ECU 2 executes all the programs applied to the own ECU in the virtual environment (operating environment) corresponding to each of the programs, and operates according to the functional specifications defined by the own ECU. To start.
  • the process of the verification unit 24 that becomes the trigger is the output (S103) of the first verification result (reset release signal). Therefore, during the period from processing S112 to S1112 in the management unit 210, the high-priority program is executed (started) in the high-priority virtual ECU 200 (virtual environment), and in parallel with this, the verification unit 24 executes (starts) the program. , Processing related to verification of the virtual ECU 200 having a low priority (S104 to S106) is performed.
  • the high-priority virtual ECU 200 (virtual environment) is generated at an early stage, and the high-priority program is executed (started) at an early stage while the verification unit is executed.
  • the secure boot process can be efficiently performed without delaying the verification of all the virtual ECUs 200 (virtual environment) by 24.
  • the management unit 210 of the in-vehicle ECU 2 performs a process of performing the series of processes according to the number of cores of the control unit 20 configured by the multi-core CPU. It may be generated and the series of processes may be performed for each core. That is, the management unit 210 of the in-vehicle ECU 2 generates, for example, the same number of subprocesses or threads as the number of cores of the control unit 20, and in each subprocess or the like, a series corresponding to each core (core 1, core 2). (S111 to S1113) may be performed, and processing related to generation and scheduling of the virtual ECU 200 in each core may be performed in parallel.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)

Abstract

車載ＥＣＵは、制御部、起動する際に複数のプログラムそれぞれの検証を行う検証部、仮想化オペレーティングシステムが記憶されている記憶部を備え、仮想化オペレーティングシステムを起動することにより、プログラムの動作環境となる複数の仮想環境が生成され、検証部は、優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、第１検証結果の出力後、優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、仮想化オペレーティングシステムを管理する管理部は、第１検証結果が出力されてから第２検証結果が出力されるまでの間と、第２検証結果が出力された以降とでは、複数の仮想環境に対する制御部の割当時間帯を異ならせる。

Description

車載ＥＣＵ、プログラム、及び情報処理方法
　本開示は、車載ＥＣＵ、プログラム、及び情報処理方法に関する。
　本出願は、２０２０年１１月１３日出願の日本出願第２０２０－１８９７５０号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用するものである。
　車両に搭載され、当該車両に搭載された機器の制御や、車外通信、自動運転等の走行制御に関する情報処理を行う電子制御装置が知られている（例えば特許文献１）。特許文献１の電子制御装置は、複数のコアを有するマルチコアＣＰＵを備え、マルチコアＣＰＵ上で複数のプログラムシステムが、動作する。特許文献１の電子制御装置には、プログラムが実行されることによって実現される機能の構成要素として、ハイパーバイザが搭載されており、当該ハイパーバイザにより、マルチコアＣＰＵ上で複数の仮想マシンを作成して並列に動作させ、作成された仮想マシン上でＯＳを動作させる。
特開２０１９－１７９３９７号公報
　本開示の一態様に係る車載ＥＣＵは、車両に搭載される車載ＥＣＵであって、複数のプログラムを実行する制御部と、自ＥＣＵを起動する際に、前記複数のプログラムそれぞれの検証を行う検証部と、前記制御部によって起動される仮想化オペレーティングシステムが記憶されている記憶部とを備え、前記仮想化オペレーティングシステムを起動することにより、前記プログラムの動作環境となる複数の仮想環境が生成され、前記複数の仮想環境は、前記プログラムに応じた異なる優先度の仮想環境を含み、前記検証部は、前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、前記第１検証結果の出力後、前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、前記仮想化オペレーティングシステムを管理する管理部は、前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間と、前記第２検証結果が出力された以降とでは、前記複数の仮想環境に対する前記制御部の割当時間帯を異ならせる。
実施形態１に係る車載ＥＣＵを含む車載システムの構成を例示する模式図である。 車載ＥＣＵの物理構成を例示するブロック図である。 車載ＥＣＵの論理構成（仮想ＥＣＵ）を例示するブロック図である。 仮想ＥＣＵにおける機能部を例示する機能ブロック図である。 第１割当時間テーブル（第１割当時間情報）を例示する説明図である。 第２割当時間テーブル（第２割当時間情報）を例示する説明図である。 仮想環境に対する制御部の割当時間帯に関する説明図である。 制御部及び検証部によるシーケンスを例示した説明図である。 車載ＥＣＵの制御部及び検証部の処理を例示するフローチャートである。
［本開示が解決しようとする課題］
　特許文献１の電子制御装置は、複数の仮想マシンに対するセキュリティ的な観点から検証を行う点について、考慮されていない。
　本開示は、仮想化オペレーティングシステムによって生成される複数の仮想環境に対する検証を効率的に行うことができる車載ＥＣＵ等を提供する。
［本開示の効果］
　本開示の一態様によれば、仮想化オペレーティングシステムによって生成される複数の仮想環境に対する検証を効率的に行うことができる車載ＥＣＵ等を提供する。
［本開示の実施形態の説明］
　最初に本開示の実施態様を列挙して説明する。また、以下に記載する実施形態の少なくとも一部を任意に組み合わせてもよい。
（１）本開示の一態様に係る車載ＥＣＵは、車両に搭載される車載ＥＣＵであって、複数のプログラムを実行する制御部と、自ＥＣＵを起動する際に、前記複数のプログラムそれぞれの検証を行う検証部と、前記制御部によって起動される仮想化オペレーティングシステムが記憶されている記憶部とを備え、前記仮想化オペレーティングシステムを起動することにより、前記プログラムの動作環境となる複数の仮想環境が生成され、前記複数の仮想環境は、前記プログラムに応じた異なる優先度の仮想環境を含み、前記検証部は、前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、前記第１検証結果の出力後、前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、前記仮想化オペレーティングシステムを管理する管理部は、前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間と、前記第２検証結果が出力された以降とでは、前記複数の仮想環境に対する前記制御部の割当時間帯を異ならせる。
　本態様にあたっては、車載ＥＣＵ（Electronic Control Unit）が起動する際、例えばＨＳＭ（Hardware Security Module）等の検証部により複数のプログラムに対する検証が行われるものであり、すなわち、車載ＥＣＵは、当該検証部を用いたセキュアブートを行う。検証部による検証の対象となる複数のプログラムは、これらプログラムの優先度に基づき区分化されており、例えば、高い優先度のプログラム（高優先度プログラム）と、低い優先度のプログラム（低優先度プログラム）とを含む。これにより、実行するプログラムに応じて、仮想環境の優先度も決定される。すなわち、高優先度プログラムの動作環境となる仮想環境（高優先度の仮想環境）の優先度は、低優先度プログラムの動作環境となる仮想環境（低優先度の仮想環境）の優先度よりも、高いものとなる。検証部は、当該複数のプログラムに対する検証を行うにあたり、優先度の高い順番に検証を行う。従って、検証部は、高優先度プログラムの検証を行った後、低優先度プログラムの検証を行う。検証部は、高優先度プログラムの検証を行った際に第１検証結果を出力し、当該第１検証結果の出力後に低優先度プログラムの検証及び当該検証の結果となる第２検証結果を出力する。従って、検証部はプログラムの優先度に応じた順番にて、これらプログラムの検証を行うため、効率的な検証を行うことができる。当該複数のプログラムは、仮想化オペレーティングシステムによって生成されるいずれかの仮想環境（仮想ＥＣＵ）を動作環境として実行（起動）される。仮想化オペレーティングシステムを管理する管理部は、第１検証結果が出力されてから第２検証結果が出力されるまでの間と、第２検証結果が出力された以降とでは、異なるスケジューリングによって、複数の仮想環境に対する制御部の割当時間帯を割り当てるため、優先度に応じた検証結果に基づき適切なスケジューリングを行うことができる。
（２）本開示の一態様に係る車載ＥＣＵは、前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間は、前記優先度の高い仮想環境を動作環境とするプログラムの実行と、前記優先度の低い仮想環境を動作環境とするプログラムの検証とが、並行して行われる。
　本態様にあたっては、高優先度の仮想環境における高優先度プログラムの実行（起動）と並行して、低優先度の仮想環境における低優先度プログラムに対する検証部の検証を行うことができるため、効率的にセキュアブートを行うことができる。
（３）本開示の一態様に係る車載ＥＣＵは、前記仮想化オペレーティングシステムを管理する管理部は、前記第１検証結果に応じて、前記優先度の高い仮想環境に対し前記制御部の割当時間帯を割り当てる第１割当制御を開始し、前記第２検証結果が出力された以降は、前記優先度の高い仮想環境及び前記優先度の低い仮想環境に対し、前記制御部の割当時間帯を割り当てる第２割当制御を開始する。
　本態様にあたっては、管理部は、第１検証結果に応じて当該第１検証結果が出力されてから第２検証結果が出力されるまでの間は、優先度の高い仮想環境に対し制御部の割当時間帯を割り当てる第１割当制御（第１スケジュールに基づくスケジューリング）を行う。その上で、管理部は、第２検証結果が出力された以降は、優先度の高い仮想環境及び優先度の低い仮想環境に対し制御部の割当時間帯を割り当てる第２割当制御（第２スケジュールに基づくスケジューリング）を開始する。従って、第１検証結果に応じて、優先度の高い仮想環境に対し制御部の割当時間帯を割り当て、当該優先度の高い仮想環境を動作環境とする高優先度プログラムを早期に実行（起動）することができる。すなわち、検証部による全領域の検証後に起動する方法を用いた場合、優先度の高い仮想環境を動作環境とする高優先度プログラムも含め、起動に時間がかかってしまうところ、本態様による方法を用いることにより、優先度の高い仮想環境を動作環境とする高優先度プログラムを早期に実行（起動）することができる。
（４）本開示の一態様に係る車載ＥＣＵは、前記記憶部には、前記複数の仮想環境に対する前記制御部の割当時間帯を定める割当時間情報が記憶されており、前記割当時間情報は、前記第１割当制御に対応した第１割当時間情報と、前記第２割当制御に対応した第２割当時間情報とを含み、前記管理部は、参照する割当時間情報として、前記第１割当時間情報から前記第２割当時間情報に切り替えることにより、前記第１割当制御から、前記第２割当制御に変更する。
　本態様にあたっては、記憶部に記憶されている割当時間情報は、第１スケジュールに対応した第１割当時間情報と、第２スケジュールに対応した第２割当時間情報とを含む。仮想化オペレーティングシステムを管理する管理部は、当該第１割当時間情報、又は第２割当時間情報を参照して、仮想環境夫々に対し、制御部の利用時間を割り当てる。管理部は、第２検証結果が出力された以降、第１スケジュールに基づくスケジューリングから、第２スケジュールに基づくスケジューリングへの変更を行うにあたり、参照する対象（割当時間情報）を、第１割当時間情報から第２割当時間情報に切り替える。これにより、管理部は、効率的にスケジューリングの変更を行うことができる。
（５）本開示の一態様に係る車載ＥＣＵは、前記検証部は、前記第１検証結果を出力するにあたり、前記優先度の高い仮想環境にて起動されるゲストＯＳの検証を行い、前記第２検証結果を出力するにあたり、前記優先度の低い仮想環境にて起動されるゲストＯＳの検証を行う。
　本態様にあたっては、仮想化オペレーティングシステムとして、例えばハイパーバイザー方式を用いる場合、生成された仮想環境においてＵｂｕｎｔｕ（登録商標）等のゲストＯＳ（Operation System）が起動される。検証部は、高優先度プログラムの検証を行うにあたり当該高優先度プログラムの動作環境となる優先度の高い仮想環境（高優先度仮想環境）にて起動されるゲストＯＳの検証を行う。更に、検証部は、低優先度プログラムの検証を行うにあたり当該低優先度プログラムの動作環境となる優先度の低い仮想環境（低優先度仮想環境）にて起動されるゲストＯＳの検証を行う。仮想化オペレーティングシステムによって生成される複数の仮想環境それぞれに対し、車載ＥＣＵの記憶部の領域（記憶領域）が区分化されている場合、検証部は、個々の仮想環境に対応した記憶領域それぞれに対し検証を行うものであってもよい。これにより、検証部は、プログラムの検証を行う際、当該プログラムの動作環境となる仮想環境にて起動されるゲストＯＳ（Operating System）についても検証を行うため、車載ＥＣＵにおいてプログラムが実行されるにあたり、セキュアな動作環境を担保することができる。
（６）本開示の一態様に係る車載ＥＣＵは、前記優先度は、ＩＳＯ２６２６２のＡＳＩＬ（Automotive Safety Integrity Level）に基づき決定される。
　本態様にあたっては、優先度の高いプログラムの動作環境となる仮想環境は、優先度の低いプログラムの動作環境となる仮想環境よりも、早期に生成されるものであり、すなわち実行するプログラムに応じて、仮想環境の優先度も決定される。これにより、優先度の低いプログラムに対する検証部の検証が完了するよりも前に、優先度の高いプログラムを実行することができる。当該優先度は、優先度はＡＳＩＬ（Automotive Safety Integrity Level）に基づき決定されるものであり、すなわちＡＳＩＬのレベルが向上するにつれ、優先度も高くなる。従って、車載ＥＣＵの起動時にＨＳＭ等の検証部による検証を行う場合であっても、ＡＳＩＬのレベルが高いプログラムの動作環境となる仮想環境を早期に起動し、当該プログラムを早期に実行することにより、個々のプログラムに要求される機能安全を鑑みた制御部の割り当て（スケジューリング）を効率的に行うことができる。
（７）本開示の一態様に係る車載ＥＣＵは、前記制御部は、複数のコアを備えるマルチコアＣＰＵにて構成されており、前記複数の仮想環境それぞれは、前記複数のコアの内のいずれかのコアに割り当てられるものであり、前記検証部は、前記複数のコアそれぞれに割り当てられる、全ての前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき前記第１検証結果を出力し、前記第１検証結果の出力後、複数の前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき前記第２検証結果を出力し、前記管理部は、前記複数のコアそれぞれにおいて、前記複数の仮想環境に対する割当時間帯の割当を行う。
　本態様にあたっては、検証部は、全てのコアそれぞれにおいて、優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力した後、優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力する。その上で、管理部は、コアそれぞれにおいて、第１検証結果及び第２検証結果に応じて、複数の仮想環境に対する割当時間帯を割り当てるスケジューリングを行う。従って、車載ＥＣＵがマルチコアＣＰＵにて構成される制御部を含むものであっても、仮想化オペレーティングシステムによって生成される複数の仮想環境に対する検証を効率的に行い、各コアにおける高優先度プログラムを早期に実行することができる。
（８）本開示の一態様に係るプログラムは、車両に搭載され、仮想化オペレーティングシステムを起動することにより生成される複数の仮想環境において、複数のプログラムを実行するコンピュータに処理を実行させるプログラムであって、前記複数の仮想環境は、該仮想環境を動作環境とするプログラムに応じた異なる優先度の仮想環境を含み、前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、前記第１検証結果の出力後、前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間と、前記第２検証結果が出力された以降とでは、前記複数の仮想環境に対するコンピュータの制御部の割当時間帯を異ならせる。
　本態様にあたっては、コンピュータを、仮想化オペレーティングシステムによって生成される複数の仮想環境に対する検証を効率的に行うことができる車載ＥＣＵとして機能させることができる。
（９）本開示の一態様に係る情報処理方法は、車両に搭載され、仮想化オペレーティングシステムを起動することにより生成される複数の仮想環境において、複数のプログラムを実行するコンピュータに処理を実行させる情報処理方法であって、前記複数の仮想環境は、該仮想環境を動作環境とするプログラムに応じた異なる優先度の仮想環境を含み、前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、前記第１検証結果の出力後、前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間と、前記第２検証結果が出力された以降とでは、前記複数の仮想環境に対するコンピュータの制御部の割当時間帯を異ならせる。
　本態様にあたっては、コンピュータを、仮想化オペレーティングシステムによって生成される複数の仮想環境に対する検証を効率的に行うことができる車載ＥＣＵとして機能させる情報処理方法を提供することができる。
[本開示の実施形態の詳細]
　本開示をその実施の形態を示す図面に基づいて具体的に説明する。本開示の実施形態に係る車載ＥＣＵ２を、以下に図面を参照しつつ説明する。なお、本開示はこれらの例示に限定されるものではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
（実施形態１）
　以下、実施の形態について図面に基づいて説明する。図１は、実施形態１に係る車載ＥＣＵ２を含む車載システムＳの構成を例示する模式図である。図２は、車載ＥＣＵ２の物理構成を例示するブロック図である。車載システムＳは、車両Ｃに搭載される複数の車載ＥＣＵ２及び、当該車載ＥＣＵ２に接続される車載装置３を含む。
　複数の車載ＥＣＵ２は、車両Ｃの全体を制御する統合的な車載ＥＣＵ２（統合ＥＣＵ）、及び当該統合的な車載ＥＣＵ２と通信可能に接続され、車載装置３と直接、接続される個別的な車載ＥＣＵ２（個別ＥＣＵ）を含むものであってもよい。統合的な車載ＥＣＵ２は、車外通信装置１を介して、インターネット等の外部ネットワークに接続される外部サーバ１００と、通信可能に接続されるものであってもよい。
　本実施形態において図示においては、統合的な車載ＥＣＵ２と、複数の個別的な車載ＥＣＵ２とは、スター状のネットワークトポロジーを形成する車載ネットワーク４によって通信可能に接続され、当該統合的な車載ＥＣＵ２は、スター状のネットワークトポロジーの中心（センター）に位置して設けられている。更に、隣接する個々の個別的な車載ＥＣＵ２同士が接続され、ループ状のネットワークトポロジーを構成し、双方向通信を可能として冗長化を図るものであってもよい。
　複数の個別的な車載ＥＣＵ２は、車両Ｃにおける各エリアに配置され、イルミネーションランプ等のアクチュエータ３０、及びセンサ３１等の車載装置３が、シリアルケーブル（じか線）等のワイヤーハーネスにて、直接接続されている。個別的な車載ＥＣＵ２は、例えば、センサから出力された信号（入力信号）を取得（受信）し、取得した入力信号に基づき生成した要求信号を統合的な車載ＥＣＵ２に送信する。個別的な車載ＥＣＵ２は、統合的な車載ＥＣＵ２から送信された制御信号に基づき、自ＥＣＵに直接、接続されたイルミネーションランプ等のアクチュエータ３０の駆動制御を行う。
　個別的な車載ＥＣＵ２は、当該個別的な車載ＥＣＵ２に接続される複数の車載装置３間の通信、又は車載装置３と他の車載ＥＣＵ２との通信を中継するゲートウェイ又はイーサスイッチ等の車載中継装置として機能する中継制御ＥＣＵであってもよい。個別的な車載ＥＣＵ２は、通信に関する中継に加え、蓄電装置から出力された電力を分配及び中継し、自ＥＣＵに接続される車載装置３に供給する電力分配装置としても機能するＰＬＢ（Power Lan Box）であってもよい。
　統合的な車載ＥＣＵ２は、個別的な車載ＥＣＵ２等、他の車載ＥＣＵ２を介して中継された車載装置３からのデータに基づき、個々の車載装置３への制御信号を生成及び出力するものであり、例えばヴィークルコンピュータ等の中央制御装置である。統合的な車載ＥＣＵ２は、個別的な車載ＥＣＵ２等、他の車載ＥＣＵ２から出力（送信）される要求信号等の情報又はデータに基づき、当該要求信号の対象となるアクチュエータ３０を制御するための制御信号を生成し、生成した制御信号を他の車載ＥＣＵ２に出力（送信）する。本実施形態においては、統合的な車載ＥＣＵ２（統合ＥＣＵ）及び個別的な車載ＥＣＵ２（個別ＥＣＵ）により車載システムＳは構成されるとしたがこれに限定されない。車載システムＳは、例えばＣＡＮ（Controller Area Network）ゲートウェイ又はイーサスイッチ等の中継装置によってピアツーピアに接続された複数の車載ＥＣＵ２によって構成されるものであってもよい。
　車載装置３は、例えばＬｉＤＡＲ（Light Detection and Ranging）、ライトセンサ、ＣＭＯＳカメラ、赤外線センサ等の各種センサ３１及び、ドアＳＷ（スイッチ）、ランプＳＷ等のスイッチ、ランプ、ドア開閉装置、モータ装置等のアクチュエータ３０を含む。
　外部サーバ１００は、例えばインターネット又は公衆回線網等の車外ネットワークに接続されているサーバ等のコンピュータであり、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）又はハードディスク等による記憶部を備える。統合的な車載ＥＣＵ２（統合ＥＣＵ）は、車外通信装置１と通信可能に接続され、車外通信装置１を介して車外ネットワークを介して接続された外部サーバ１００と通信し、外部サーバ１００と、車両Ｃに搭載される他の車載ＥＣＵ２又は車載装置３との間の通信を中継するものであってもよい。
　車外通信装置１は、車外通信部（図示せず）及び、統合的な車載ＥＣＵ２（統合ＥＣＵ）と通信するための入出力Ｉ／Ｆ（図示せず）を含む。車外通信部は、４Ｇ、ＬＴＥ（Long Term Evolution／登録商標）、５Ｇ、ＷｉＦｉ等の移動体通信のプロトコルを用いて無線通信をするための通信装置であり、車外通信部に接続されたアンテナ１１を介して外部サーバ１００とデータの送受信を行う。車外通信装置１と外部サーバ１００との通信は、例えば公衆回線網又はインターネット等の外部ネットワークＮを介して行われる。入出力Ｉ／Ｆ２２は、車載ＥＣＵ２と、例えばシリアル通信するための通信インターフェイスである。車外通信装置１と車載ＥＣＵ２とは、入出力Ｉ／Ｆ及び入出力Ｉ／Ｆに接続されたシリアルケーブル等のワイヤーハーネスを介して相互に通信する。本実施形態では、車外通信装置１は、車載ＥＣＵ２と別装置とし、入出力Ｉ／Ｆ等によってこれら装置を通信可能に接続しているが、これに限定されない。車外通信装置１は、車載ＥＣＵ２の一構成部位として、車載ＥＣＵ２に内蔵されるものであってもよい。
　車載ＥＣＵ２（統合ＥＵＣ、個別ＥＣＵ）は、制御部２０、記憶部２１、入出力Ｉ／Ｆ２２、車内通信部２３及び検証部２４を含む。制御部２０は、ＣＰＵ（Central Processing Unit）又はＭＰＵ（Micro Processing Unit）等により構成してあり、記憶部２１に予め記憶された制御プログラム及びデータを読み出して実行することにより、種々の制御処理及び演算処理等を行うようにしてある。制御部２０は、例えば、シングルコアのシングルＣＰＵ、シングルコアのマルチＣＰＵ、マルチコアのシングルＣＰＵ、及びマルチコアのマルチＣＰＵを含む。制御部２０は、ＣＰＵ等のソフトウェア処理を行うソフトウェア処理部のみに限定されず、ＦＰＧＡ、ＡＳＩＣ又はＳＯＣ等のハードウェア処理にて種々の制御処理及び演算処理等を行うハードウェア処理部を含むものであってもよい。
　記憶部２１は、ＲＡＭ（Random Access Memory）等の揮発性のメモリ素子又は、ＲＯＭ（Read Only Memory）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）若しくはフラッシュメモリ等の不揮発性のメモリ素子、又は、これら記憶デバイスの組み合わせにより構成してあり、制御プログラム及び処理時に参照するデータが予め記憶してある。当該制御プログラムは、例えば、各種の車載装置３を制御するためのプログラム（アプリケーション）、又はＬｉＤＡＲ又はＣＭＯＳカメラからの出力データ基づき自動化運転を行うための物標認識を行うプログラム（アプリケーション）等の複数のプログラム（アプリケーション）を含む。更に、車載ＥＣＵ２の記憶部２１には、例えば、Ｈｙｐｅｒｖｉｓｏｒ又はＶＭｗａｒｅ等の仮想オペレーティングシステムが記憶されている。
　入出力Ｉ／Ｆ２２は、車外通信装置１の入出力Ｉ／Ｆ２２と同様に、例えばシリアル通信するための通信インターフェイスである。入出力Ｉ／Ｆ２２及びシリアルケーブル等のワイヤーハーネスを介して、車載ＥＣＵ２は、車外通信装置１と通信可能に接続される。
　車内通信部２３は、例えばＣＡＮ（Controller Area Network）又はイーサネット（Ethernet／登録商標）の通信プロトコルを用いた入出力インターフェイスであり、制御部２０は、車内通信部２３を介して車載ネットワーク４に接続されている他の車載ＥＣＵ２と相互に通信する。
　検証部２４は、例えばＨＳＭ（Hardware Security Module）又はＳＨＥ（Secure Hardware Extension）であり、ＣＰＵ等で構成される制御部２０とは別デバイス又は別モジュールとして構成されている。ＨＳＭ等にて構成される検証部２４は、車載ＥＣＵ２（自ＥＣＵ）が起動（ブート）される際に行われるセキュアブート処理の一端を担うものであり、記憶部２１に記憶されている複数のプログラム等、車載ＥＣＵ２の起動において実行されるソフトウェアの適正性（完全性）又は健全性を検証する機能モジュールである。検証部２４は、例えば、暗号処理用のプロセッサを含み、例えばＣＭＡＣ（Cipher-based Message Authentication Code）等の暗号アルゴリズムを用いて、検証対象となるプログラム及びゲストＯＳ等のソフトウェアの適正性（完全性）を検証する。検証部２４は、車載ＥＣＵ２の起動時に行われるセキュアブート処理（セキュアブートシーケンス）において、検証対象となる複数のプログラム等それぞれの適正性（完全性）を検証し、プログラムそれぞれに対する検証結果を出力する。当該検証結果は、プログラム等が正当である旨を示す肯定的検証結果、又はプログラム等が例えば改竄等され不正である旨を示す否定的検証結果を含む。
　検証部２４は、全ての仮想ＥＣＵ２００（ゲストＯＳ、プログラム）に対し、２段階にて検証を行うように構成されている。検証部２４は、第１段階として、それぞれのコアに対し割り当てられている仮想ＥＣＵ２００のうち、高い優先度の仮想ＥＣＵ２００の検証を行い、第２段階として、当該高い優先度の仮想ＥＣＵ２００以外となる、低い優先度の仮想ＥＣＵ２００の検証を行う。検証部２４は、高い優先度の仮想ＥＣＵ２００に対する検証結果として、第１検証結果（リセット解除信号）を制御部２０に出力し、低い優先度の仮想ＥＣＵ２００に対する検証結果として、第２検証結果を制御部２０に出力する。検証部２４は、当該第１検証結果を出力するにあたり、制御部２０を構成するコアに対しリセット解除信号を出力するものであってもよい。又は、検証部２４は、当該第１検証結果の出力に併せて、当該コアに対しリセット解除信号を出力するものであってもよい。
　図３は、車載ＥＣＵ２の論理構成（仮想ＥＣＵ２００）を例示するブロック図である。本実施形態における図示にて車載ＥＣＵ２の論理構成を例示するものであり、制御部２０等によるハードウェア層（物理基盤）を最下層とし、仮想環境にて実行されるプログラム、及び仮想環境管理プログラム等によるソフトウェア層を最上層とした階層構造を例示するブロック図である。
　上述のとおり、車載ＥＣＵ２の記憶部２１には、例えば、Ｈｙｐｅｒｖｉｓｏｒ又はＶＭｗａｒｅ等の仮想オペレーティングシステムが記憶されており、車載ＥＣＵ２の制御部２０は、仮想オペレーティングシステムを用いて起動することにより、仮想オペレーティングシステム上にて複数の仮想環境（仮想ＥＣＵ２００）を構築することができる。各種の車載装置３を制御するためのプログラムは、これら複数の仮想環境のうちのいずれかの仮想環境を動作環境として、実行される。すなわち、これらプログラムは、いずれかの仮想環境（仮想ＥＣＵ２００）上にて、実行されるものとなる。仮想環境（仮想ＥＣＵ２００）にてプログラムが実行されることにより、当該プログラムの処理内容に応じて単一又は複数のタスクが生成される。当該タスクによって、より細分化又は区分化された処理単位が実行されるものとなる。
　仮想化の方式は、本実施形態の図示のように仮想オペレーティングシステムによって直接的に制御部２０等のハードウェアリソースにアクセスするハイパーバイザー方式、又は仮想オペレーティングシステムとハードウェアリソースとの間にＬｉｎｕｘ（登録商標）等のオペレーティングシステムが介在するホストＯＳ方式であってもよい。又は、コンテナ方式の仮想オペレーティングシステムを用いるものであってもよい。
　仮想オペレーティングシステムを用いて起動した車載ＥＣＵ２は、仮想オペレーティングシステムの機能により、複数の仮想環境を構築することができ、複数の仮想環境には、車載ＥＣＵ２が備える制御部２０等のハードウェアリソースが割り当てられる。これらハードウェアリソースが割り当てられた仮想環境それぞれは、仮想的な制御部２０（仮想制御部）、記憶部２１（仮想記憶部）及び車内通信部２３（仮想車内通信部）を備えるものとなり、仮想ＥＣＵ２００として機能する。
　仮想ＥＣＵ２００それぞれの仮想記憶部それぞれには、例えばＵｂｕｎｔｕ（登録商標）等のゲストＯＳ（Operation System）が記憶され、仮想ＥＣＵ２００それぞれはゲストＯＳを起動し、当該ゲストＯＳの上でプログラムを実行する。当該ゲストＯＳは、個々の仮想ＥＣＵ２００に応じて、異なる種類のＯＳであってもよい。上述のごとく仮想記憶部の実体は、仮想ＥＣＵ２００それぞれに割り当てられた記憶部２１の記憶領域であるため、ゲストＯＳも仮想オペレーティングシステムと同様に記憶部２１に記憶されていることは、言うまでもない。コンテナ方式の仮想オペレーティングシステムを用いる場合、ゲストＯＳを不要とし、当該仮想オペレーティングシステムの上でコンテナ（仮想環境）を生成し、当該コンテナ（仮想環境）上にてプログラムを実行するものであってもよい。
　仮想オペレーティングシステムを用いて起動した車載ＥＣＵ２の制御部２０は、構築したいずれかの仮想環境（仮想ＥＣＵ２００）のうちの一つの仮想ＥＣＵ２００にて、全ての仮想環境を管理するプログラム（仮想環境管理プログラム）を実行する。すなわち、仮想環境管理プログラムを実行する仮想ＥＣＵ２００は、仮想オペレーティングシステムのコントロールパネルとして機能するものであり、管理部２１０に相当する。又は、仮想オペレーティングシステム自体が、管理部２１０としての機能を包含するものであってもよい。制御部２０とは別個のデバイスである検証部２４は、仮想オペレーティングシステムによる仮想化の対象外となり、当該検証部２４は、管理部２１０（仮想オペレーティングシステムのコントロールパネル）又は制御部２０を構成するコアと通信するものとなる。
　記憶部２１には、後述する割当時間情報（第１割当時間テーブル２１Ａ、第２割当時間テーブル２１Ｂ）が記憶されている。管理部２１０は、検証部２４からの出力内容（第１検出結果、第２検出結果）に応じて、第１割当時間テーブル２１Ａ又は第２割当時間テーブル２１Ｂを選択し、選択したテーブルに基づき、個々の仮想環境（仮想ＥＣＵ２００）に対する制御部２０（コアそれぞれ）の利用時間の割当（スケジューリング）を行う。
　図４は、仮想ＥＣＵ２００における機能部を例示する機能ブロック図である。図５は、第１割当時間テーブル２１Ａ（第１割当時間情報）を例示する説明図である。図６は、第２割当時間テーブル２１Ｂ（第２割当時間情報）を例示する説明図である。
　仮想ＥＣＵ２００の仮想制御部（制御部２０）は、当該仮想ＥＣＵ２００の仮想記憶部（記憶部２１）に記憶されているプログラムを実行することにより、タスク生成部２０１として機能する。
　仮想オペレーティングシステムを実行する制御部２０又は、当該仮想オペレーティングシステムを管理するための仮想ＥＣＵ２００の仮想制御部（制御部２０）は、仮想記憶部（記憶部２１）に記憶されている仮想環境管理プログラムを実行することにより、仮想オペレーティングシステムのコントロールパネルとして機能し、本実施形態における管理部２１０に相当する。当該管理部２１０は、テーブル選択部２１１、及び割当実行部２１２を含む。
　制御部２０が、例えばマルチコアにて構成される場合、当該管理部２１０（仮想オペレーティングシステムのコントロールパネル）に対し利用時間が割り当てられるコアと、車載装置３等の制御を行うためのプログラムの動作環境となる仮想環境（仮想ＥＣＵ２００）に対し利用時間が割り当てられるコアとは、異なるコアであってもよい。
　管理部２１０は、例えば記憶部２１に記憶されている割当時間情報を参照することにより、仮想ＥＣＵ２００に対し、制御部２０を構成するいずれかのコアの利用時間を、割り当てる処理（スケジューリング）を継続して行っている。本実施形態における図示のとおり、管理部２１０が参照する割当時間情報は、例えば第１割当時間テーブル２１Ａ、及び第２割当時間テーブル２１Ｂとして、テーブル形式（ルックアップテーブル）にて記憶部２１に記憶されている。
　第１割当時間テーブル２１Ａ、及び第２割当時間テーブル２１Ｂの管理項目は、仮想ＥＣＵ２００の項目、割当コアの項目、割当周期の項目、割当時間の項目、プログラム種別の項目、ＡＳＩＬの項目、及び優先度の項目を含む。すなわち、第１割当時間テーブル２１Ａ及び第２割当時間テーブル２１Ｂの管理項目は、同一である。
　仮想ＥＣＵ２００の項目には、同一の制御部２０（コア）を時分割することにより共用する仮想ＥＣＵ２００の名称又は識別子が格納される。本実施形態における第１割当時間テーブル２１Ａにおいては、優先度の高い仮想ＥＣＵ２００（ＶＭ１、ＶＭ５）のみが、定義されている。第２割当時間テーブル２１Ｂにおいては、優先度の高い仮想ＥＣＵ２００及び低い仮想ＥＣＵ２００からなる全ての仮想ＥＣＵ２００（ＶＭ１からＶＭ７）が、定義されている。従って、管理部２１０は、第１割当時間テーブル２１Ａを選択することにより、優先度の高い仮想ＥＣＵ２００（ＶＭ１、ＶＭ５）のみを対象とした制御部２０（コア１、コア２）の利用時間の割り当てを行うことができる。管理部２１０は、第２割当時間テーブル２１Ｂを選択することにより、全ての仮想ＥＣＵ２００（ＶＭ１からＶＭ７）を対象とした制御部２０（コア１、コア２）の利用時間の割り当てを行うことができる。
　割当コアの項目には、対応する仮想ＥＣＵ２００（同じレコードに格納される仮想ＥＣＵ２００）に割り当てられるコアの番号又は識別子が格納される。周期的（定常的）に割当が行われる仮想ＥＣＵ２００（ＶＭ１からＶＭ６）に対しては、いずれか一つのコアの番号が、格納される。これにより、各仮想ＥＣＵ２００は、どのコア（コア番号）の利用時間が割り当てられるかが、定められている。本実施形態における第１割当時間テーブル２１Ａにおいては、仮想ＥＣＵ２００（ＶＭ１）は、コア１に割り当てられ、仮想ＥＣＵ２００（ＶＭ５）は、コア２に割り当てられている。第２割当時間テーブル２１Ｂにおいては、仮想ＥＣＵ２００（ＶＭ１、ＶＭ２、ＶＭ３、ＶＭ４）は、コア１に割り当てられ、仮想ＥＣＵ２００（ＶＭ５、ＶＭ６、ＶＭ７）は、コア２に割り当てられている。
　割当周期の項目には、周期的（定常的）に割当が行われる仮想ＥＣＵ２００における割当周期が、格納される。割当時間の項目には、周期的（定常的）に制御部２０の利用時間が割り当てられる仮想ＥＣＵ２００において、それぞれの仮想ＥＣＵ２００に割り当てられる割当時間が格納される。これら割当時間の合算値が、割当周期に相当する。
　本実施形態における第１割当時間テーブル２１Ａにおいては、単一のコアに対し割り当てられる仮想ＥＣＵ２００の個数も１つであるため、割当周期と割当時間とは、等しい値となる。第２割当時間テーブル２１Ｂにおいては、単一のコアに対し割り当てられる仮想ＥＣＵ２００の個数は２つ以上であるため、それぞれのコアにおいて、それぞれの仮想ＥＣＵ２００に割り当てられる割当時間の合算値が、割当周期に相当する。
　プログラム種別の項目には、対応する（同じレコードに格納される）各仮想ＥＣＵ２００（仮想環境）にて実行されるプログラムの種別が格納されている。ＡＳＩＬの項目には、実行されるプログラムの安全性指標を示すＡＳＩＬのレベルが格納される。優先度の項目は、プログラムの優先度を示す値（本実施形態では、高／低）が格納される。当該優先度に基づき、当該プログラムに対応する仮想ＥＣＵ２００に対する検証部２４の検証の順番、及び管理部２１０による仮想ＥＣＵ２００の生成の順番が、決定される。当該優先度は、対応する車載装置３及び実行するプログラムの機能に基づいて決定されるものであり、例えばＩＳＯ２６２６２のＡＳＩＬ（Automotive Safety Integrity Level）に基づいて決定されるものであってもよい。ＡＳＩＬのレベルは、ＱＭ、ＡＳＩＬ－Ａ，ＡＳＩＬ－Ｂ，ＡＳＩＬ－Ｃ，ＡＳＩＬ－Ｄのレベルに分類される。ＱＭレベルは、ＩＳＯ２６２６２による機能安全を適用しなくてもよい通常の品質管理である。ＡＳＩＬ－ＡからＤのレベルにおいては、ＩＳＯ２６２６２による機能安全の適用が必要となるレベルであり、ＡＳＩＬ－ＡからＡＳＩＬ－Ｄになるについて、機能安全要件が厳しくなる。すなわち、ＱＭレベルの優先度が最も低く、ＡＳＩＬ－Ｄレベルの優先度が最も高いとみなすことができる。本実施形態において、プログラムの優先度を示す指標としてＡＳＩＬを用いるとしたが、これに限定されない。当該プログラムの優先度は、ＡＳＩＬとは別個の値（優先度設定値）により決定されるものであってもよく、当該優先度設定値は、例えば、車載システムＳの利用者、管理者又は製造者によって、個々に変更可能に設定されるものであってもよい。
　本実施形態においては、コア１及びコア２にて実行されるプログラムの内、ＡＳＩＬ－Ｄのプログラム及び当該プログラムの動作環境となる仮想ＥＣＵ２００（コア１：ＶＭ１、コア２：ＶＭ５）の優先度を、高い優先度としている。これ以外の仮想ＥＣＵ２００（ＶＭ２、ＶＭ３、ＶＭ４、ＶＭ６、ＶＭ７）の優先度を、低い優先度としている。本実施形態における優先度の区分けは、一例であり、これに限定されるものでないことは、言うまでもない。
　検証部２４は、例えば記憶部２１に記憶されている第１割当時間テーブル２１Ａを参照し、制御部２０を構成するそれぞれのコアに対応する仮想ＥＣＵ２００において、高い優先度の仮想ＥＣＵ２００に対する検証を行い、第１検証結果（リセット解除信号）をテーブル選択部２１１に出力する。検証部２４は、当該第１検証結果としてリセット解除信号を、対応するそれぞれのコアに出力するものであってもよい。
　テーブル選択部２１１は、第１検証結果（リセット解除信号）に基づき、高い優先度の仮想ＥＣＵ２００に対応した第１スケジュールを定義している割当時間情報（第１割当時間テーブル２１Ａ）を選択し、当該第１割当時間テーブル２１Ａに応じた割当指示を割当実行部２１２に出力する。
　割当実行部２１２は、当該割当指示に基づき、高い優先度の仮想ＥＣＵ２００を生成し、割り当てられている制御部２０（コア）の利用時間を割り当てる。
　高い優先度の仮想ＥＣＵ２００のタスク生成部２０１は、自仮想ＥＣＵ２００に適用される高い優先度のプログラムを実行してタスクを生成し、当該タスクによって、より細分化又は区分化された処理単位が実行されるものとなる。
　検証部２４は、例えば記憶部２１に記憶されている第２割当時間テーブル２１Ｂを参照し、制御部２０を構成するそれぞれのコアに対応する仮想ＥＣＵ２００において、低い優先度の仮想ＥＣＵ２００に対する検証を行い、第２検証結果をテーブル選択部２１１に出力する。検証部２４による低い優先度の仮想ＥＣＵ２００に対する検証に関する処理と、管理部２１０による高い優先度の仮想ＥＣＵ２００に関する処理とは、並行して実行される。
　テーブル選択部２１１は、第２検証結果に基づき、全ての仮想ＥＣＵ２００（高い優先度及び低い優先度の仮想ＥＣＵ２００）に対応した第２スケジュールを定義している割当時間情報（第２割当時間テーブル２１Ｂ）を選択し、当該第２割当時間テーブル２１Ｂに応じた割当指示を割当実行部２１２に出力する。
　割当実行部２１２は、当該割当指示に基づき、低い優先度の仮想ＥＣＵ２００を生成する。これより、全ての仮想ＥＣＵ２００が生成されるものとなる。割当実行部２１２は、全ての仮想ＥＣＵ２００に対し、それぞれに仮想ＥＣＵ２００に対し割り当てられている制御部２０（コア）の利用時間を割り当てる。すなわち、割当実行部２１２は、検証部２４からの出力内容に基づき、第１スケジュール（第１割当時間テーブル２１Ａ）から第２スケジュール（第２割当時間テーブル２１Ｂ）に切り替えて再スケジュールを行う再スケジュール部として機能する。
　図７は、仮想環境に対する制御部２０の割当時間帯に関する説明図である。本実施形態における例示として、制御部２０は、２つのコアから構成されるデュアルコアＣＰＵである。
　検証部２４は、セキュアブート処理（セキュアブートシーケンス）を開始するにあたり、自部におけるファームウェア（ＦＷ）の起動後、コア１及びコア２において高い優先度の仮想ＥＣＵ２００（ＶＭ１等）の検証を行い、それぞれのコアに対し第１検出結果（リセット解除信号）を出力する。検証部２４は、当該第１検出結果（リセット解除信号）の出力後、低い優先度の仮想ＥＣＵ２００の検証を行い、第２検出結果を出力する。
　第１検出結果（リセット解除信号）が入力されたそれぞれのコアは、例えばＨｙｐｅｒｖｉｓｏｒ及びＡＵＴＯＳＡＲ等の規格によるＢＳＷ（Basic Soft Ware）の初期化を行い、当該コアの利用時間が割り当てられる高い優先度の仮想ＥＣＵ２００が、生成される。当該高い優先度の仮想ＥＣＵ２００（仮想環境）において、高い優先度のプログラムが実行（起動）される。
　仮想オペレーティングシステムのコントロールパネルとして機能する管理部２１０は、第１割当時間テーブル２１Ａに基づき、これら高い優先度の仮想ＥＣＵ２００に対する制御部２０（コア）の利用時間の割り当て（スケジューリング）を行う。
　第２検出結果が入力されたそれぞれのコアにおいては、当該コアの利用時間が割り当てられる低い優先度の仮想ＥＣＵ２００が生成される。当該低い優先度の仮想ＥＣＵ２００（仮想環境）において、低い優先度のプログラムが実行（起動）される。これにより、全ての仮想ＥＣＵ２００が生成され、それぞれの仮想ＥＣＵ２００（仮想環境）において、それぞれのプログラムが実行（起動）される。
　仮想オペレーティングシステムのコントロールパネルとして機能する管理部２１０は、第２割当時間テーブル２１Ｂに基づき、全ての仮想ＥＣＵ２００に対する制御部２０（コア）の利用時間の割り当て（スケジューリング）を行う。
　それぞれのコアにおける高優先度の仮想環境の生成及び当該高優先度の仮想環境にて高優先度のプログラムを実行（起動）する処理と、検証部２４による低優先度の仮想ＥＣＵ２００に対する検証とは、並行して行われる。これにより、高優先度のプログラムを早期に実行（起動）しつつ、検証部２４による検証を遅延させることなく、効率的にセキュアブート処理を実施することができる。
　図８は、制御部２０及び検証部２４によるシーケンスを例示した説明図である。本実施形態における図示において、制御部２０（コア１、コア２）はデュアルコアＣＰＵにより構成されるものとしている。本実施形態における制御部２０及び検証部２４の処理は、車載ＥＣＵ２の起動時に行われるセキュアブートシーケンスの一環として行われる。
　検証部２４は、コア１にて実行される高優先度の仮想ＥＣＵ２００（ゲストＯＳ、プログラム）の検証を行う（Ｓ０１）。検証部２４は、コア１における第１検証結果を制御部２０に出力（送信）する（Ｓ０２）。検証部２４は、当該第１検証結果として、コア１に対しリセット解除信号を出力するものであってもよい。又は、検証部２４は、当該第１検証結果の出力に併せて、コア１に対しリセット解除信号を出力するものであってもよい。当該リセット解除信号が入力されることにより、コア１のリセット解除が行われ、コア１は、非活性状態（ノンアクティブ）から活性状態（アクティブ）に遷移する。
　制御部２０は、コア１における第１検証結果を取得する（Ｓ０３）。制御部２０は、第１検証結果に基づき、コア１にて実行される高優先度の仮想環境（仮想ＥＣＵ２００：ＶＭ１）を生成し、当該仮想環境を動作環境として高優先度のプログラムを実行（起動）する（Ｓ０４）。制御部２０は、第１スケジュールにてコア１における割当時間のスケジューリングを行う（Ｓ０５）。本実施形態における第１スケジュール（第１割当時間テーブル２１Ａ）においては、高優先度の仮想ＥＣＵ２００（ＶＭ１）に対してのみコア１（制御部２０）の利用時間が、割り当てられる。ＨｙｐｅｒＶｉｓｏｒ等の仮想化オペレーティングシステムからの観点においては、仮想環境（仮想ＥＣＵ２００）の生成及び当該仮想環境（仮想ＥＣＵ２００）に対するコア１の利用時間の割り当てに関する制御は、仮想オペレーティングシステムのコントロールパネルとして機能する管理部２１０によって行われる。
　検証部２４は、コア２にて実行される高優先度の仮想ＥＣＵ２００（ゲストＯＳ、プログラム）の検証を行う（Ｓ０６）。検証部２４は、コア２における第１検証結果を制御部２０に出力（送信）する（Ｓ０７）。検証部２４は、当該第１検証結果として、コア２に対しリセット解除信号を出力するものであってもよい。又は、検証部２４は、当該第１検証結果の出力に併せて、コア２に対しリセット解除信号を出力するものであってもよい。当該リセット解除信号が入力されることにより、コア２のリセット解除が行われ、コア２は、非活性状態（ノンアクティブ）から活性状態（アクティブ）に遷移する。
　制御部２０は、コア２における第１検証結果を取得する（Ｓ０８）。制御部２０は、第１検証結果に基づき、コア２にて実行される高優先度の仮想環境（仮想ＥＣＵ２００：ＶＭ５）を生成し、当該仮想環境を動作環境として高優先度のプログラムを実行（起動）する（Ｓ０９）。制御部２０は、第１スケジュールにてコア２における割当時間のスケジューリングを行う（Ｓ１０）。本実施形態における第１スケジュール（第１割当時間テーブル２１Ａ）においては、高優先度の仮想ＥＣＵ２００（ＶＭ５）に対してのみコア２（制御部２０）の利用時間が、割り当てられる。ＨｙｐｅｒＶｉｓｏｒ等の仮想化オペレーティングシステムからの観点においては、仮想環境（仮想ＥＣＵ２００）の生成及び当該仮想環境（仮想ＥＣＵ２００）に対するコア２の利用時間の割り当てに関する制御は、仮想オペレーティングシステムのコントロールパネルとして機能する管理部２１０によって行われる。
　検証部２４は、コア１にて実行される低優先度の仮想ＥＣＵ２００（ゲストＯＳ、プログラム）の検証を行う（Ｓ１１）。検証部２４は、コア１における第２検証結果を制御部２０に出力（送信）する（Ｓ１２）。
　制御部２０は、コア１における第２検証結果を取得する（Ｓ１３）。制御部２０は、第２検証結果に基づき、コア１にて実行される低優先度の仮想環境（仮想ＥＣＵ２００：ＶＭ２、ＶＭ３、ＶＭ４）を生成し、当該仮想環境を動作環境として低優先度のプログラムを実行（起動）する（Ｓ１４）。制御部２０は、第２スケジュール（第２割当時間テーブル２１Ｂ）にてコア１における割当時間のスケジューリングを行う（Ｓ１５）。本実施形態における第２スケジュール（第２割当時間テーブル２１Ｂ）においては、コア１を共用する全ての仮想ＥＣＵ２００（ＶＭ１、ＶＭ２、ＶＭ３、ＶＭ４）に対し、当該コア１（制御部２０）の利用時間が、割り当てられる。
　検証部２４は、コア２にて実行される低優先度の仮想ＥＣＵ２００（ゲストＯＳ、プログラム）の検証を行う（Ｓ１６）。検証部２４は、コア２における第２検証結果を制御部２０に出力（送信）する（Ｓ１７）。
　制御部２０は、コア２における第２検証結果を取得する（Ｓ１８）。制御部２０は、第２検証結果に基づき、コア２にて実行される低優先度の仮想環境（仮想ＥＣＵ２００：ＶＭ６、ＶＭ７）を生成し、当該仮想環境を動作環境として低優先度のプログラムを実行（起動）する（Ｓ１９）。制御部２０は、第２スケジュール（第２割当時間テーブル２１Ｂ）にてコア２における割当時間のスケジューリングを行う（Ｓ２０）。本実施形態における第２スケジュール（第２割当時間テーブル２１Ｂ）においては、コア２を共用する全ての仮想ＥＣＵ２００（ＶＭ５、ＶＭ６、ＶＭ７）に対し、当該コア２（制御部２０）の利用時間が、割り当てられる。
　車載ＥＣＵ２は、制御部２０（管理部２１０）による高優先度の仮想環境の生成及び当該高優先度の仮想環境にて高優先度のプログラムを実行（起動）する処理と、検証部２４による低優先度の仮想ＥＣＵ２００に対する検証とを、並行して行う。これにより、高優先度の仮想ＥＣＵ２００（仮想環境）を早期に生成して高優先度のプログラムを早期に実行（起動）しつつ、検証部２４による全ての仮想ＥＣＵ２００（仮想環境）に対する検証を遅延させることなく、効率的にセキュアブート処理を実施することができる。
　図９は、車載ＥＣＵ２の制御部２０及び検証部２４の処理を例示するフローチャートである。車載ＥＣＵ２の制御部２０は、例えば、車両Ｃが停止状態（ＩＧスイッチがオフ）から起動状態（ＩＧスイッチがオン）に状態遷移するにあたり、車載ＥＣＵ２（自ＥＣＵ）が起動（ブート）される際に行われるセキュアブート処理（セキュアブートシーケンス）に基づき、以下の処理を行う。
　車載ＥＣＵ２の検証部２４は、高い優先度の仮想ＥＣＵ２００の検証を行う（Ｓ１０１）。検証部２４は、例えば記憶に記憶されている第１割当時間テーブル２１Ａを参照し、それぞれのコアに関連付けられている高い優先度の仮想ＥＣＵ２００を特定する。仮想ＥＣＵ２００に対する検証を行うにあたり、検証部２４は、当該仮想ＥＣＵ２００にて実行されるプログラム及び起動されるゲストＯＳに対する検証を行うものであってもよい。又は、仮想ＥＣＵ２００それぞれに対し、記憶部２１における記憶領域が区分化されている場合、検証部２４は、当該仮想ＥＣＵ２００に対応する記憶領域にて記憶されているプログラム又はゲストＯＳに対する検証を行うものであってもよい。車載ＥＣＵ２の制御部２０が、例えば複数のコアを含むマルチコアＣＰＵによって構成されている場合、検証部２４は、それぞれのコアにて実行される高い優先度の仮想ＥＣＵ２００（高優先度の仮想ＥＣＵ２００）に対する検証を順次に行う。
　車載ＥＣＵ２の検証部２４は、全てのコアにおける高い優先度の仮想ＥＣＵ２００の検証が完了したか否かを判定する（Ｓ１０２）。全てのコアにおける高い優先度の仮想ＥＣＵ２００の検証が完了していない場合（Ｓ１０２：ＮＯ）、車載ＥＣＵ２の検証部２４は、再度Ｓ１０１の処理を実行すべく、ループ処理を行う。
　全てのコアにおける高い優先度の仮想ＥＣＵ２００の検証が完了した場合（Ｓ１０２：ＹＥＳ）、車載ＥＣＵ２の検証部２４は、第１検証結果（リセット解除信号）を出力する（Ｓ１０３）。検証部２４は、各コアそれぞれにおける第１検証結果を出力するにあたり、検証が完了したコア毎に当該第１検証結果を出力するものであってもよい。制御部２０が、２つのコア（コア１、コア２）を含むデュアルコアＣＰＵによって構成される場合、検証部２４は、コア１における高い優先度の仮想ＥＣＵ２００の検証が完了した際にコア１に対する第１検証結果を出力し、当該第１検証結果の出力後、コア２における高い優先度の仮想ＥＣＵ２００の検証が完了した際にコア２に対する第１検証結果を出力するものであってもよい。
　車載ＥＣＵ２の検証部２４は、低い優先度の仮想ＥＣＵ２００の検証を行う（Ｓ１０４）。検証部２４は、例えば記憶部２１に記憶されている第２割当時間テーブル２１Ｂを参照し、それぞれのコアに関連付けられている低い優先度の仮想ＥＣＵ２００を特定する。
　車載ＥＣＵ２の検証部２４は、全てのコアにおける低い優先度の仮想ＥＣＵ２００の検証が完了したか否かを判定する（Ｓ１０５）。全てのコアにおける低い優先度の仮想ＥＣＵ２００の検証が完了していない場合（Ｓ１０５：ＮＯ）、車載ＥＣＵ２の検証部２４は、再度Ｓ１０５の処理を実行すべく、ループ処理を行う。
　車載ＥＣＵ２の検証部２４は、第２検証結果を出力する（Ｓ１０６）。検証部２４は、各コアそれぞれにおける第２検証結果を出力するにあたり、検証が完了したコア毎に当該第２検証結果を出力するものであってもよい。制御部２０が、２つのコア（コア１、コア２）を含むデュアルコアＣＰＵによって構成される場合、検証部２４は、コア２における低い優先度の仮想ＥＣＵ２００の検証が完了した際にコア２に対する第２検証結果を出力し、当該第２検証結果の出力後、コア２における低い優先度の仮想ＥＣＵ２００の検証が完了した際にコア２に対する第２検証結果を出力するものであってもよい。
　以下の処理が、仮想オペレーティングシステムのコントロールパネルとして機能する管理部２１０にて実行される場合、当該管理部２１０の実体は、車載ＥＣＵ２の制御部２０である。車載ＥＣＵ２の管理部２１０は、第１検証結果（リセット解除信号）を取得したか否かを判定する（Ｓ１１１）。管理部２１０は、検証部２４から出力される第１検証結果（リセット解除信号）を取得したか否かを判定する。管理部２１０の実態である制御部２０は、ＨＳＭ等により構成される検証部２４から出力される第１検証結果（リセット解除信号）を待ち受ける状態にある。従って、管理部２１０は、第１検証結果が入力された場合、車載ＥＣＵ２における起動時の処理が行われていることを認識することができる。当該第１検証結果がリセット解除信号を含む場合、又は第１検証結果がリセット解除信号に相当する場合、リセット解除信号が入力されたコアは、活性状態となる。リセット解除信号により活性状態に遷移したコアにおいて、例えばＨｙｐｅｒｖｉｓｏｒ及びＡＵＴＯＳＡＲ等の規格によるＢＳＷ（Basic Soft Ware）の初期化が行われるものであってもよい。
　第１検証結果（リセット解除信号）を取得した場合（Ｓ１１１：ＹＥＳ）、車載ＥＣＵ２の管理部２１０は、第１スケジュールを選択する（Ｓ１１２）。管理部２１０は、第１スケジュールを定義している第１割当時間テーブル２１Ａを、制御部２０（コア）の利用時間を仮想ＥＣＵ２００に割り当てるための用いるスケジュールテーブルとして選択する。第１割当時間テーブル２１Ａには、制御部２０がマルチコアＣＰＵで構成されている場合、各コアにおいて利用時間が割り当てられる高優先度の仮想ＥＣＵ２００の割当時間帯及び割当周期が定義されている。
　車載ＥＣＵ２の管理部２１０は、選択したスケジュール（第１スケジュール）に基づき、スケジューリングを実行する（Ｓ１１３）。管理部２１０は、第１割当時間テーブル２１Ａにて定義されている内容に基づき、制御部２０（コア）の利用時間を仮想ＥＣＵ２００に割り当てる。これにより、第１検証結果（リセット解除信号）において検証対象となった高い優先度の仮想ＥＣＵ２００（高優先度の仮想ＥＣＵ２００）に対し、制御部２０（コア）の利用時間が、第１スケジュール（第１割当時間テーブル２１Ａ）に基づき割り当てられ、当該高優先度の仮想ＥＣＵ２００（仮想環境）上で、高優先度のプログラムが実行（起動）される。
　車載ＥＣＵ２の管理部２１０は、Ｓ１１３の処理の実行後、又は第１検証結果（リセット解除信号）を取得していない場合（Ｓ１１１：ＮＯ）、車載ＥＣＵ２の管理部２１０は、第２検証結果を取得したか否かを判定する（Ｓ１１１１）。管理部２１０は、検証部２４からの第２検証結果が入力されたか否かに基づき、当該第２検証結果を取得したか否かを判定する。第２検証結果を取得していない場合（Ｓ１１１１：ＮＯ）、車載ＥＣＵ２の管理部２１０は、再度Ｓ１１１１の処理を実行すべく、ループ処理を行う。
　第２検証結果を取得した場合（Ｓ１１１１：ＹＥＳ）、車載ＥＣＵ２の管理部２１０は、第２スケジュールを選択する（Ｓ１１１２）。第２検証結果を取得した場合、検証部２４により、全ての仮想ＥＣＵ２００（プログラム及びゲストＯＳ）に対する検証が完了したものであり、すなわち第２検証結果は、全仮想ＥＣＵ２００の検証完了通知に相当する。管理部２１０は、第２スケジュールを定義している第２割当時間テーブル２１Ｂを、制御部２０（コア）の利用時間を仮想ＥＣＵ２００に割り当てるための用いるスケジュールテーブルとして選択する。第２割当時間テーブル２１Ｂには、制御部２０がマルチコアＣＰＵで構成されている場合、各コアにおいて利用時間が割り当てられる全ての仮想ＥＣＵ２００の割当時間帯及び割当周期が定義されている。
　車載ＥＣＵ２の管理部２１０は、選択したスケジュール（第２スケジュール）に基づき、スケジューリングを実行する（Ｓ１１１３）。管理部２１０は、第２割当時間テーブル２１Ｂにて定義されている内容に基づき、制御部２０（コア）の利用時間を仮想ＥＣＵ２００に割り当てる。これにより、全ての仮想ＥＣＵ２００（高優先度の仮想ＥＣＵ２００、及び低優先度の仮想ＥＣＵ２００）に対し、制御部２０（コア）の利用時間が、第２スケジュール（第２割当時間テーブル２１Ｂ）に基づき割り当てられ、それぞれの仮想ＥＣＵ２００（仮想環境）上で、プログラムが実行（起動）される。これにより、車載ＥＣＵ２は、自ＥＣＵに適用されている全てのプログラムを、当該プログラムそれぞれに対応する仮想環境（動作環境）にて実行し、自ＥＣＵにて定められている機能仕様に応じた動作を開始する。
　管理部２１０による処理Ｓ１１１において、トリガーとなる検証部２４の処理は、第１検証結果（リセット解除信号）の出力（Ｓ１０３）である。従って、管理部２１０における処理Ｓ１１２からＳ１１１２まで期間において、高優先度の仮想ＥＣＵ２００（仮想環境）にて高優先度のプログラムが実行（起動）されると共に、これに並行して、検証部２４によって、低い優先度の仮想ＥＣＵ２００の検証に関する処理（Ｓ１０４からＳ１０６）が行われる。管理部２１０及び検証部２４による処理を並行して行うことにより、高優先度の仮想ＥＣＵ２００（仮想環境）を早期に生成して高優先度のプログラムを早期に実行（起動）しつつ、検証部２４による全ての仮想ＥＣＵ２００（仮想環境）に対する検証を遅延させることなく、効率的にセキュアブート処理を実施することができる。
　車載ＥＣＵ２の管理部２１０は、本フローチャートにおける一連の処理（Ｓ１１１からＳ１１１３）を行うにあたり、マルチコアＣＰＵで構成されている制御部２０が有するコアの個数に応じて、当該一連の処理を行うプロセスを生成し、各コア毎にて当該一連の処理を行うものであってもよい。すなわち、車載ＥＣＵ２の管理部２１０は、例えば、制御部２０のコア数と同数のサブプロセス又はスレッドを生成し、各サブプロセス等にて、それぞれのコア（コア１、コア２）に応じた一連の処理（Ｓ１１１からＳ１１１３）を行い、各コアにおける仮想ＥＣＵ２００の生成及びスケジューリングに関する処理を並行して行うものであってもよい。
　今回開示された実施形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
　Ｃ　車両
　Ｓ　車載システム
　１００　外部サーバ
　１　車外通信装置
　１１　アンテナ
　２　車載ＥＣＵ
　２０　制御部
　２１　記憶部
　２１Ａ　第１割当時間テーブル
　２１Ｂ　第２割当時間テーブル
　２２　入出力Ｉ／Ｆ
　２３　車内通信部
　２４　検証部
　２００　仮想ＥＣＵ（仮想環境）
　２０１　タスク生成部
　２１０　管理部
　２１１　テーブル選択部
　２１２　割当実行部
　３　車載装置
　３０　アクチュエータ（ＡＣＴ）
　３１　センサ
　４　車載ネットワーク
 

Claims (9)

  1. 　車両に搭載される車載ＥＣＵであって、
    　複数のプログラムを実行する制御部と、
    　自ＥＣＵを起動する際に、前記複数のプログラムそれぞれの検証を行う検証部と、
    　前記制御部によって起動される仮想化オペレーティングシステムが記憶されている記憶部とを備え、
    　前記仮想化オペレーティングシステムを起動することにより、前記プログラムの動作環境となる複数の仮想環境が生成され、
    　前記複数の仮想環境は、前記プログラムに応じた異なる優先度の仮想環境を含み、
    　前記検証部は、
    　前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、
    　前記第１検証結果の出力後、前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、
    　前記仮想化オペレーティングシステムを管理する管理部は、
    　前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間と、前記第２検証結果が出力された以降とでは、前記複数の仮想環境に対する前記制御部の割当時間帯を異ならせる
    　車載ＥＣＵ。
  2. 　前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間は、前記優先度の高い仮想環境を動作環境とするプログラムの実行と、前記優先度の低い仮想環境を動作環境とするプログラムの検証とが、並行して行われる
    　請求項１に記載の車載ＥＣＵ。
  3. 　前記仮想化オペレーティングシステムを管理する管理部は、
    　前記第１検証結果に応じて、前記優先度の高い仮想環境に対し前記制御部の割当時間帯を割り当てる第１割当制御を開始し、
    　前記第２検証結果が出力された以降は、前記優先度の高い仮想環境及び前記優先度の低い仮想環境に対し、前記制御部の割当時間帯を割り当てる第２割当制御を開始する
    　請求項１又は請求項２に記載の車載ＥＣＵ。
  4. 　前記記憶部には、前記複数の仮想環境に対する前記制御部の割当時間帯を定める割当時間情報が記憶されており、
    　前記割当時間情報は、前記第１割当制御に対応した第１割当時間情報と、前記第２割当制御に対応した第２割当時間情報とを含み、
    　前記管理部は、参照する割当時間情報として、前記第１割当時間情報から前記第２割当時間情報に切り替えることにより、前記第１割当制御から、前記第２割当制御に変更する
    　請求項３に記載の車載ＥＣＵ。
  5. 　前記検証部は、
    　前記第１検証結果を出力するにあたり、前記優先度の高い仮想環境にて起動されるゲストＯＳの検証を行い、
    　前記第２検証結果を出力するにあたり、前記優先度の低い仮想環境にて起動されるゲストＯＳの検証を行う
    　請求項１から請求項４のいずれか１項に記載の車載ＥＣＵ。
  6. 　前記優先度は、ＩＳＯ２６２６２のＡＳＩＬ（Automotive Safety Integrity Level）に基づき決定される
    　請求項１から請求項５のいずれか１項に記載の車載ＥＣＵ。
  7. 　前記制御部は、複数のコアを備えるマルチコアＣＰＵにて構成されており、
    　前記複数の仮想環境それぞれは、前記複数のコアの内のいずれかのコアに割り当てられるものであり、
    　前記検証部は、
    　前記複数のコアそれぞれに割り当てられる、全ての前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき前記第１検証結果を出力し、
    　前記第１検証結果の出力後、複数の前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき前記第２検証結果を出力し、
    　前記管理部は、前記複数のコアそれぞれにおいて、前記複数の仮想環境に対する割当時間帯の割当を行う
    　請求項１から請求項６のいずれか１項に記載の車載ＥＣＵ。
  8. 　車両に搭載され、仮想化オペレーティングシステムを起動することにより生成される複数の仮想環境において、複数のプログラムを実行するコンピュータに処理を実行させるプログラムであって、
    　前記複数の仮想環境は、該仮想環境を動作環境とするプログラムに応じた異なる優先度の仮想環境を含み、
    　前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、
    　前記第１検証結果の出力後、前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、
    　　前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間と、前記第２検証結果が出力された以降とでは、前記複数の仮想環境に対するコンピュータの制御部の割当時間帯を異ならせる
    　処理を実行させるプログラム。
  9. 　車両に搭載され、仮想化オペレーティングシステムを起動することにより生成される複数の仮想環境において、複数のプログラムを実行するコンピュータに処理を実行させる情報処理方法であって、
    　前記複数の仮想環境は、該仮想環境を動作環境とするプログラムに応じた異なる優先度の仮想環境を含み、
    　前記優先度の高い仮想環境を動作環境とするプログラムの検証に基づき第１検証結果を出力し、
    　前記第１検証結果の出力後、前記優先度の低い仮想環境を動作環境とするプログラムの検証に基づき第２検証結果を出力し、
    　　前記第１検証結果が出力されてから前記第２検証結果が出力されるまでの間と、前記第２検証結果が出力された以降とでは、前記複数の仮想環境に対するコンピュータの制御部の割当時間帯を異ならせる
    　処理を実行させる情報処理方法。
     
PCT/JP2021/039215 2020-11-13 2021-10-25 車載ｅｃｕ、プログラム、及び情報処理方法 WO2022102384A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-189750 2020-11-13
JP2020189750A JP7463947B2 (ja) 2020-11-13 2020-11-13 車載ｅｃｕ、プログラム、及び情報処理方法

Publications (1)

Publication Number Publication Date
WO2022102384A1 true WO2022102384A1 (ja) 2022-05-19

Family

ID=81601092

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/039215 WO2022102384A1 (ja) 2020-11-13 2021-10-25 車載ｅｃｕ、プログラム、及び情報処理方法

Country Status (2)

Country Link
JP (1) JP7463947B2 (ja)
WO (1) WO2022102384A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009107349A1 (ja) * 2008-02-25 2009-09-03 パナソニック株式会社 情報処理装置
JP2010237787A (ja) * 2009-03-30 2010-10-21 Fujitsu Ltd プログラム、情報処理装置及び状態出力方法
JP2019179397A (ja) * 2018-03-30 2019-10-17 株式会社デンソー 電子制御装置及びマルチコアの割当て方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009107349A1 (ja) * 2008-02-25 2009-09-03 パナソニック株式会社 情報処理装置
JP2010237787A (ja) * 2009-03-30 2010-10-21 Fujitsu Ltd プログラム、情報処理装置及び状態出力方法
JP2019179397A (ja) * 2018-03-30 2019-10-17 株式会社デンソー 電子制御装置及びマルチコアの割当て方法

Also Published As

Publication number Publication date
JP7463947B2 (ja) 2024-04-09
JP2022078815A (ja) 2022-05-25

Similar Documents

Publication Publication Date Title
JP6903784B2 (ja) 車両システム、車両およびこの種の車両システムの動作方法
JP7280412B2 (ja) ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
CN111800506B (zh) 一种边缘计算节点部署方法及相关装置
US9218201B2 (en) Multicore system and activating method
JP7392157B2 (ja) コンピューティングデバイスの動作方法及び動作装置
WO2022102384A1 (ja) 車載ｅｃｕ、プログラム、及び情報処理方法
AU2021308570B2 (en) Pool management for in-vehicle device application startup
JP7447782B2 (ja) 車載コンピュータ、コンピュータ実行方法及びコンピュータプログラム
WO2022102383A1 (ja) 車載ｅｃｕ、プログラム、及び情報処理方法
WO2022097448A1 (ja) 車載ｅｃｕ、プログラム及びフェールセーフ方法
WO2023106073A1 (ja) 車載装置、プログラム及び情報処理方法
CN114625424B (zh) 基于硬隔离的资源重分配方法、系统和设备
US20240220308A1 (en) In-vehicle apparatus, information processing method, and computer program
US20240303103A1 (en) Vehicle-mounted computer, computer execution method, and computer program
CN114625427B (zh) 基于硬隔离的分区启动方法、系统和设备
US20240330073A1 (en) Arithmetic processing apparatus and arithmetic processing method
US20240134679A1 (en) On-board device, information processing method, and computer program
CN116367335A (zh) 资源分配方法、装置和存储介质
CN118672722A (zh) 一种容器系统及其实现方法
CN118827422A (zh) 一种基于mcu微容器的应用网管平台及物联网平台系统
CN113934509A (zh) 支持混合虚拟机管理器的系统和运行方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21891631

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21891631

Country of ref document: EP

Kind code of ref document: A1