In-vehicle device, method of starting in-vehicle device, and startup program

Abstract

To reduce the startup time of an in-vehicle device.SOLUTION: An in-vehicle device includes: a first determination unit which determines, when the in-vehicle device is started, whether the start is a first start from a stop state in which functions are stopped, or a second start from a sleep state in which functions less than the functions stopped in the stop state are stopped; a first verification unit which executes, when the start is the first start, first verification processing of software which has not been executed on the in-vehicle device; and a second verification unit which executes, when the start is the second start, second verification processing of software which has not been executed on the in-vehicle device. The processing time of the second verification processing is shorter than the processing time of the first verification processing.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to an in-vehicle device, a startup method for an in-vehicle device, and a startup program. [Background technology]

[0002] Vehicles are equipped with a variety of on-board devices, including control ECUs (Electronic Control Units) that control the engine, transmission, etc., body ECUs that control headlights, power windows, etc., and information ECUs for navigation systems, multimedia devices, etc. Each on-board device is connected to an on-board network and can communicate with each other. Various software programs run in these ECUs to realize their respective functions.

[0003] When an ECU is started, a secure boot is executed, which is a process for detecting software tampering. Patent Document 1 discloses an electronic control unit that omits the secure boot when starting from a standby state and enables high-speed start-up by executing software code verification before a running ECU transitions to a standby state. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2022 / 158377 Summary of the Invention [Problem to be solved by the invention]

[0005] However, in the electronic control device disclosed in Patent Document 1, if software is tampered with while the ECU is in standby mode, the tampering cannot be detected at startup, and security cannot be ensured. Furthermore, the execution time of the code verification process is not shortened, so it takes time for the ECU to transition to standby mode. [Means for solving the problem]

[0006] An in-vehicle device according to one embodiment of the present disclosure includes a first determination unit that, when the in-vehicle device is started, determines whether the start-up is a first start-up from a stopped state in which functions are stopped, or a second start-up from a sleep state in which fewer functions are stopped than those stopped in the stopped state; a first verification unit that, if the start-up is the first start-up, performs a first verification process of software before it is executed in the in-vehicle device; and a second verification unit that, if the start-up is the second start-up, performs a second verification process of software before it is executed in the in-vehicle device, wherein the processing time of the second verification process is shorter than the processing time of the first verification process.

[0007] The present disclosure can be realized not only as an in-vehicle device having the above-described characteristic configuration, a startup method for an in-vehicle device having steps each representing a characteristic process, and a startup program for causing an in-vehicle device to execute a characteristic process, but also as an in-vehicle system including the in-vehicle device, or as a semiconductor integrated circuit in which part or all of the in-vehicle device is implemented. [Effects of the Invention]

[0008] According to the present disclosure, the startup time of an in-vehicle device can be reduced. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of an in-vehicle system according to the first embodiment. [Figure 2] FIG. 2 is a block diagram showing an example of a hardware configuration of the relay ECU according to the first embodiment. [Figure 3] FIG. 3 is a functional block diagram illustrating an example of functions of the relay ECU according to the embodiment. [Figure 4] FIG. 4 is a flowchart showing an example of a start-up sequence by the relay ECU according to the first embodiment. [Figure 5]FIG. 5 is a functional block diagram showing an example of functions of the relay ECU according to the third embodiment. [Figure 6] FIG. 6 is a flowchart showing an example of a start-up sequence by the relay ECU according to the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] <Summary of Embodiments of the Present Disclosure> Hereinafter, an outline of embodiments of the present disclosure will be listed and described.

[0011] (1) An in-vehicle device according to this embodiment includes a first determination unit that, upon startup of the in-vehicle device, determines whether the startup is a first startup from a stopped state in which functions are stopped or a second startup from a sleep state in which fewer functions are stopped than those stopped in the stopped state, a first verification unit that, if the startup is the first startup, performs a first verification process of software before it is executed on the in-vehicle device, and a second verification unit that, if the startup is the second startup, performs a second verification process of software before it is executed on the in-vehicle device, wherein the processing time of the second verification process is shorter than the processing time of the first verification process. This reduces the startup time of the in-vehicle device.

[0012] (2) In the above (1), a second verification range that is a target of the second verification process may be smaller than a first verification range that is a target of the first verification process. By limiting the second verification range, the processing time of the second verification process can be reduced.

[0013] (3) In the above (2), the first verification scope may include first software that is not included in the second verification scope and second software that is included in the second verification scope, and the in-vehicle device may further include a first execution unit that executes the first software and the second software after the first verification process is completed, and a second execution unit that executes the second software after the second verification process is completed. This makes it possible to exclude the first software that is not to be executed in the second boot from the second verification scope.

[0014] (4) In the above (3), the first software may be a boot loader. This makes it possible to exclude the boot loader, which is not required to be executed in the second boot-up, from the second verification range.

[0015] (5) In the above (3) or (4), the in-vehicle device may further include a second determination unit that executes determination software for determining whether the boot is the first boot or the second boot after the first verification process or the second verification process is completed, and the second software may be the determination software. This allows the determination software executed in the first boot and the second boot to be included in the first verification range and the second verification range, respectively. This allows security to be ensured in both the first boot and the second boot.

[0016] (6) In any one of (3) to (5) above, the first software may include target determination software that determines whether to launch control software for controlling hardware or for detecting or monitoring the state of the hardware, the state of the environment around the vehicle, or objects around the vehicle, or to launch update software for updating the control software, and the in-vehicle device may further include a control unit that launches the control software when it is determined by execution of the target determination software that the control software should be launched, and an update unit that launches the update software when it is determined by execution of the target determination software that the update software should be launched. This allows the target determination software to be excluded from the verification scope in the second launch, in which it is not necessary to determine whether the control software or the update software is to be launched.

[0017] (7) In the above (6), the in-vehicle device may further include a boot target determination unit that, when the first determination unit determines that the boot is the first boot, determines whether to boot the control software or the update software before executing the first verification process, and when the boot target determination unit determines that the control software is to be booted, the first verification range may include the control software, and when the boot target determination unit determines that the update software is to be booted, the first verification range may not include the control software. This makes it possible to verify the control software that is to be booted when the control software is to be booted, and to exclude control software that is not to be booted from the verification range when the update software is to be booted.

[0018] (8) In the above (7), when the activation target determination unit determines that the update software is to be activated, the second verification range may include the update software. This makes it possible to verify the update software that is the activation target when the update software is to be activated.

[0019] (9) A startup method for an in-vehicle device according to this embodiment includes the steps of: determining, at startup of the in-vehicle device, whether the startup is a first startup from a stopped state in which functions are stopped or a second startup from a sleep state in which fewer functions than those stopped in the stopped state are stopped; if the startup is the first startup, executing a first verification process for software before it is executed on the in-vehicle device; and if the startup is the second startup, executing a second verification process for software before it is executed on the in-vehicle device, wherein the processing time of the second verification process is shorter than the processing time of the first verification process. This reduces the startup time of the in-vehicle device.

[0020] (10) A startup program according to this embodiment is a startup program executed when an in-vehicle device is started, and causes a computer to execute the following steps: determine whether the start-up is a first start-up from a stopped state in which functions are stopped or a second start-up from a sleep state in which fewer functions are stopped than those stopped in the stopped state; if the start-up is the first start-up, execute a first verification process for software before it is executed on the in-vehicle device; and if the start-up is the second start-up, execute a second verification process for software before it is executed on the in-vehicle device, wherein the processing time of the second verification process is shorter than the processing time of the first verification process. This reduces the startup time of the in-vehicle device.

[0021] <Details of the embodiment of the present disclosure> DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. At least some of the following preferred embodiments may be combined in any desired manner.

[0022] [1. First embodiment] [1-1. In-vehicle systems] 1 is a block diagram showing an example of the configuration of an in-vehicle system according to the first embodiment. A vehicle is equipped with an in-vehicle network 100. The in-vehicle network 100 according to the first embodiment is a CAN (Controller Area Network) network capable of communication via a CAN. The in-vehicle network 100 includes buses 400A, 400B, and 400C, which are CAN buses.

[0023] The in-vehicle system 10 includes a relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E.

[0024] The multiple ECUs 300A, 300B, 300C, 300D, and 300E are disposed in various parts of the vehicle. The ECUs 300A, 300B, 300C, 300D, and 300E individually control the hardware of the various parts of the vehicle, and detect or monitor the state of the hardware of the various parts of the vehicle, the state of the environment around the vehicle, or objects around the vehicle. For example, the ECUs 300A, 300B, 300C, 300D, and 300E are ECUs for a control system, a body system, and an information system. In the following description, the ECUs 300A, 300B, 300C, and 300D are also collectively referred to as "ECU 300."

[0025] The functions of ECU 300 are realized by software. That is, ECU 300 can store and execute application software for individually controlling the hardware of each part of the vehicle, detecting or monitoring the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle.

[0026] The relay ECU 200 is connected to ECUs 300A, 300B, 300C, 300D, and 300E, respectively, via buses 400A, 400B, and 400C. Specifically, ECUs 300A and 300B are connected to bus 400A. ECUs 300C and 300D are connected to bus 400B. ECU 300E is connected to bus 400C. The relay ECU 200 can communicate with each of ECUs 300A, 300B, 300C, 300D, and 300E. The relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E are examples of "in-vehicle devices."

[0027] The relay ECU 200 and the ECU 300 use a communication protocol for periodically or aperiodically transmitting and receiving messages. The communication protocol is, for example, CAN or CAN FD (CAN with Flexible Data Rate). In another example, the communication protocol is Ethernet (registered trademark). When the Ethernet protocol is used, the in-vehicle network becomes an Ethernet network having a star-type network topology.

[0028] The relay ECU 200 functions as a gateway that relays communications between a plurality of ECUs 300. Specifically, the relay ECU 200 relays communications (frames) between the buses 400A, 400B, and 400C. The ECUs 300 can transmit frames. The frames are messages that comply with the above-mentioned communication protocol. The relay ECU 200 relays frames between the buses 400A, 400B, and 400C.

[0029] The functions of the relay ECU 200 are realized by software, that is, the relay ECU 200 stores application software for relaying frames and can execute the application software.

[0030] The relay ECU 200 is connected to an external communication device 350 via a bus 400C. The external communication device 350 is, for example, a TCU (Telematics Control Unit) and can communicate with devices outside the vehicle. The external communication device 350 has a wireless communication interface for a mobile communication system such as a fifth-generation mobile communication system (5G) or a fourth-generation mobile communication system (4G). The external communication device 350 can transmit and receive packets of, for example, TCP / IP (Transmission Control Protocol / Internet Protocol). The external communication device 350 is logically connected to a base station (not shown) of a mobile communication network and can communicate with devices connected to the Internet via the base station. Specifically, the external communication device 350 can communicate with a server 500. The external communication device 350 relays communication between the relay ECU 200 and the server 500.

[0031] The server 500 manages updates of application software in the relay ECU 200 and the ECU 300. The server 500 provides software for updating application programs (update software) to the relay ECU 200 and the ECU 300. That is, the server 500 transmits the update software when an application program needs to be updated. The external communication device 350 receives the update software and transfers the received update software to the in-vehicle device to be updated, i.e., the relay ECU 200 or the ECU 300. When the in-vehicle device to be updated receives the update software, it restarts and executes the update software after the restart to update the application software.

[0032] [1-2. Hardware configuration of relay ECU] 2 is a block diagram showing an example of a hardware configuration of the relay ECU according to the first embodiment. The relay ECU 200 includes a main processor 201, a non-volatile memory 202, a volatile memory 203, interfaces (hereinafter also referred to as “I / F”) 204A, 204B, and 204C, and a security module 270.

[0033] The main processor 201, the nonvolatile memory 202, the volatile memory 203, the I / Fs 204A, 204B, and 204C, and the security module are connected to one another by a bus (data bus) 205. The main processor 201, the nonvolatile memory 202, the volatile memory 203, the communication I / Fs 204A, 204B, and 204C, and the security module 270 can transmit data to one another via the bus 205.

[0034] The volatile memory 203 is a semiconductor memory such as a static random access memory (SRAM) or a dynamic random access memory (DRAM). The nonvolatile memory 202 is a rewritable nonvolatile memory such as a flash memory or a hard disk. The nonvolatile memory 202 stores a boot loader 210, determination software 230, an operating system (OS) 240, and application software 250. The relay function of the relay ECU 200 is realized by the application software 250 being executed by the main processor 201. Hereinafter, "software" may also be referred to as "SW."

[0035] The main processor 201 is, for example, a CPU (Central Processing Unit). However, the main processor 201 is not limited to a CPU. The main processor 201 may be a GPU (Graphics Processing Unit). In a specific example, the main processor 201 is a multi-core processor. The main processor 201 may be a single-core processor. The main processor 201 is configured to be able to execute computer programs. However, the main processor 201 may include, for example, an ASIC (Application Specific Integrated Circuit) in part, or a programmable logic device such as an FPGA (Field Programmable Gate Array) in part.

[0036] The boot loader 210 is software for executing processing (bootstrap) required to start up the relay ECU 200. In the bootstrap, the OS 240 is read from the nonvolatile memory 202 and loaded into the volatile memory 203.

[0037] The boot loader 210 includes object determination software 220. The object determination software 220 is software for determining whether the object to be started is application software (hereinafter also referred to as "APP") 250 or update software 260.

[0038] The determination SW230 is software for determining, when the relay ECU 200 is started, whether the current start is a first start from a stopped state in which functions are stopped, or a second start from a sleep state in which fewer functions are stopped than those stopped in the stopped state. The first start is a start when the relay ECU 200 is powered on (cold boot) or a start when reset (restart, warm boot). In the first start, the boot loader 210 is executed. The second start is a wake-up. In the second start, execution of the boot loader 210 is omitted.

[0039] The APP 250 is software for individually controlling the hardware of each part of the vehicle, detecting or monitoring the state of the hardware of each part of the vehicle, the state around the vehicle, or objects around the vehicle. The APP 250 of the relay ECU 200 is software for realizing the frame relay function.

[0040] The update SW 260 is software for updating the APP 250. The update SW 260 is provided when a new version of the APP 250 is released, and the APP 250 is upgraded by executing the update SW 260. The update SW 260 is stored in the non-volatile memory 202 only when the update SW 260 is provided from the server 500. After the APP 250 is updated, the update SW 260 is deleted from the non-volatile memory 202.

[0041] The nonvolatile memory 202 is provided with a startup flag 261. The startup flag 261 is a memory area for holding a value of "0" or "1." If the next startup is the primary startup, the startup flag 261 is set (reset) to "0." If the next startup is the secondary startup, the startup flag 261 is set to "1." That is, the main processor 201 sets the startup flag 261 to "0" when the relay ECU 200 is shut down or restarted. The main processor 201 sets the startup flag 261 to "1" when the relay ECU 200 transitions to a sleep state. Because the startup flag 261 is provided in the nonvolatile memory 202, the value of the startup flag 261 is held even when the relay ECU 200 is stopped. The startup flag 261 may be provided not in the nonvolatile memory 202 but in a retention RAM, which is a memory area that operates even in a sleep state.

[0042] The nonvolatile memory 202 is further provided with a target flag 262. The target flag 262 is a memory area for holding a value of “0” or “1.” If the activation target at the next activation is the APP 250, the target flag 262 is set (reset) to “0.” If the activation target at the next activation is the update SW 260, the target flag 262 is set to “1.” That is, when the update SW 260 is downloaded from the server 500, the target flag 262 is set to “1.” When the update SW 260 is deleted from the nonvolatile memory 202, the target flag 262 is set to “0.” Because the target flag 262 is provided in the nonvolatile memory 202, the value of the target flag 262 is held even when the relay ECU 200 is stopped. Note that the target flag 262 may be provided not in the nonvolatile memory 202 but in a retention RAM, which is a memory area that operates even in a sleep state.

[0043] The I / Fs 204A, 204B, and 204C are communication interfaces that comply with the above-described communication protocol for the in-vehicle network. That is, the I / Fs 204A, 204B, and 204C are, for example, CAN interfaces. In another example, the I / Fs 204A, 204B, and 204C are Ethernet interfaces.

[0044] The I / F 204A is connected to the bus 400A. The I / F 204B is connected to the bus 400B. The I / F 204C is connected to the bus 400C. The relay ECU 200 can communicate with the ECUs 300A and 300B via the I / F 204A. The relay ECU 200 can communicate with the ECUs 300C and 300D via the I / F 204B. The relay ECU 200 can communicate with the ECU 300E via the I / F 204C. Furthermore, the relay ECU 200 can communicate with the server 500 via the external communication device 350 via the I / F 204C.

[0045] The security module 270 is a hardware module for verifying software, such as an HSM (Hardware Security Module). The security module 270 includes a security processor 271, a nonvolatile memory 272, and a volatile memory 273.

[0046] The volatile memory 273 is a semiconductor memory such as a static random access memory (SRAM) or a dynamic random access memory (DRAM). The nonvolatile memory 272 is a rewritable nonvolatile memory such as a flash memory. A startup program 280 is stored in the nonvolatile memory 272. The startup program 280 is a program for executing software verification processing when the relay ECU 200 is started up.

[0047] The verification process will now be described. Security module 270 executes public key verification. First, security module 270 reads the software to be verified from nonvolatile memory 202. The software is affixed with a digital signature created in advance by the software creator using a private key. The digital signature is information generated by encrypting a hash value generated from the software code with the private key. Security processor 271 decrypts the digital signature using the public key previously held by security module 270, and compares the hash value obtained by decryption with the hash value generated from the software code to verify whether the software is authentic.

[0048] The security processor 271 is, for example, a CPU. However, the security processor 271 is not limited to a CPU. The security processor 271 may be a GPU. In a specific example, the security processor 271 is a multi-core processor. The security processor 271 may be a single-core processor. The security processor 271 is configured to be able to execute a computer program. However, the security processor 271 may include, for example, an ASIC or a programmable logic device as part thereof.

[0049] The security module 270 internally completes the software verification process and is configured to prevent data generated in the software verification process from leaking outside the security module 270.

[0050] [1-3. Functions of the relay ECU] FIG. 3 is a functional block diagram illustrating an example of functions of the relay ECU according to the embodiment.

[0051] Relay ECU 200 has the functions of first execution unit 211, second execution unit 212, second determination unit 213, activation target determination unit 214, control unit 215, update unit 216, first determination unit 281, first verification unit 282, and second verification unit 283. First execution unit 211, second execution unit 212, second determination unit 213, activation target determination unit 214, control unit 215, and update unit 216 are each a first function 201A realized by main processor 201, and first determination unit 281, first verification unit 282, and second verification unit 283 are each a second function 271A realized by security processor 271.

[0052] When the relay ECU 200 is started up, the first determination unit 281 determines whether the current start-up is the first start-up or the second start-up. In a specific example, the first determination unit 281 determines whether the current start-up is the first start-up or the second start-up based on the start-up flag 261. That is, when the value of the start-up flag 261 is "0," the first determination unit 281 determines that the current start-up is the first start-up. When the value of the start-up flag 261 is "1," the first determination unit 281 determines that the current start-up is the second start-up.

[0053] When the current startup is the first startup (i.e., startup upon power-on or restart), the first verification unit 282 executes a first verification process of the software before it is executed in the relay ECU 200. The first verification process is the verification process of the software described above. The verification range (first verification range) of the first verification process includes the boot loader 210 and the determination SW 230. In a specific example, the first verification range is the boot loader 210, the determination SW 230, and, if the update SW 260 exists, the update SW 260.

[0054] In the first embodiment, the first verification scope does not include the APP 250. The verification process of the APP 250 is performed while the APP 250 is running.

[0055] If the current startup is the second startup (i.e., wake-up), the second verification unit 283 executes a second verification process of the previous software executed in the relay ECU 200. The second verification process is the verification process of the software described above. The verification range (second verification range) of the second verification process includes the determination SW 230. In a specific example, the second verification range is only the determination SW 230.

[0056] The second verification range does not include the boot loader 210 and the update SW 260, which are included in the first verification range. On the other hand, the first verification range includes the determination SW 230, which is included in the second verification range. Therefore, the second verification range is smaller than the first verification range. Here, the boot loader 210 and the update SW 260 are an example of "first software," and the determination SW 230 is an example of "second software."

[0057] As described above, in the second verification process, verification of the boot loader 210 and the update SW 260 is omitted. Therefore, the processing time of the second verification process is shorter than the processing time of the first verification process. Therefore, the verification process (secure boot) when the relay ECU 200 wakes up from the sleep state is completed in a short time. Furthermore, even if the determination SW 230 is tampered with in the sleep state, the tampering can be detected by the second verification process.

[0058] After the first verification process is completed, the first execution unit 211 executes the determination SW230 and the boot loader 210. First, the first execution unit 211 executes the determination SW230.

[0059] After the second verification process is completed, the second execution unit 212 executes the determination SW230.

[0060] By executing the determination SW 230, the function of the second determination unit 213 is realized.

[0061] After the first verification process or the second verification process is completed, the second determination unit 213 determines whether the current boot is the first boot or the second boot. In a specific example, the second determination unit 213 determines whether the current boot is the first boot or the second boot based on the boot flag 261. That is, if the value of the boot flag 261 is "0," the second determination unit 213 determines that the current boot is the first boot. If the value of the boot flag 261 is "1," the second determination unit 213 determines that the current boot is the second boot.

[0062] If the current boot is the first boot, the first execution unit 211 executes the boot loader 210. This causes the OS to be loaded into the volatile memory 203.

[0063] When the relay ECU 200 transitions from an active state to a sleep state, the data (data being worked on) stored in the volatile memory 203 is saved to the non-volatile memory 202. When the relay ECU 200 wakes up from the sleep state, the saved data is restored to the volatile memory 203. Therefore, when the relay ECU 200 wakes up, the relay ECU 200 returns to a state in which the software that was running before the sleep state is running.

[0064] In the case of wake-up, since the OS 240 is already running, there is no need to start the boot loader 210. Therefore, the second execution unit 212 omits starting the boot loader 210. Therefore, when the relay ECU 200 wakes up from the sleep state, the start-up sequence (the processing from the start of start-up to the execution of the APP 250 or the update SW 260) is completed in a short time.

[0065] If the current boot is the second boot, the APP is currently running. In this case, the first execution unit 211 does not need to execute the boot loader 210.

[0066] When the boot loader 210 is executed, the target determination SW 220, which is a component of the boot loader 210, is activated. By executing the target determination SW 220, the function of the boot target determination unit 214 is realized.

[0067] The start target determination unit 214 determines whether to start the APP 250 or the updated SW 260. In a specific example, the start target determination unit 214 determines whether the current start target is the APP 250 or the updated SW 260 based on the target flag 262. That is, when the value of the target flag 262 is "0", the start target determination unit 214 determines that the start target is the APP 250. When the value of the target flag 262 is "1", the start target determination unit 214 determines that the start target is the updated SW 260.

[0068] After the OS 240 is started, if the APP 250 is to be started, the control unit 215 starts the APP 250. As a result, the relay process of frames between the buses 400A, 400B, and 400C is executed.

[0069] After the OS 240 is started, if the update software 260 is to be started, the update unit 216 starts the update software 260. As a result, the update process of the APP 250 is executed.

[0070] [1-4. Operation of relay ECU] FIG. 4 is a flowchart showing an example of a start-up sequence by the relay ECU according to the first embodiment.

[0071] When the relay ECU 200 is started up, the security processor 271 first executes the start-up sequence. The security processor 271 executes the start-up program 280. As a result, the security processor 271 executes the following steps S101 to S103.

[0072] The security processor 271 determines whether the current boot is the first boot or the second boot (step S101). That is, the security processor 271 refers to the boot flag 261 in the nonvolatile memory 202, and determines that the current boot is the first boot if the value of the boot flag 261 is "0," and determines that the current boot is the second boot if the value of the boot flag 261 is "1."

[0073] If the current boot is the first boot ("first boot" in step S101), the security processor 271 executes a first verification process (step S102). That is, the security processor 271 executes a verification process of the boot loader 210, and if the update SW 260 exists in the non-volatile memory 202, executes a verification process of the update SW 260. Furthermore, the security processor 271 also executes a verification process of the determination SW 230.

[0074] If the current boot is the second boot (step S101: "second boot"), the security processor 271 executes the second verification process (step S103). That is, the security processor 271 executes the verification process of the determination SW230.

[0075] Next, the execution of the startup sequence process is shifted to the main processor 201. The main processor 201 executes the decision SW 230. As a result, the main processor 201 executes the next step S104.

[0076] The main processor 201 determines whether the current boot is the first boot or the second boot (step S104). That is, the main processor 201 refers to the boot flag 261 in the nonvolatile memory 202, and determines that the current boot is the first boot if the value of the boot flag 261 is "0," and determines that the current boot is the second boot if the value of the boot flag 261 is "1."

[0077] If the current boot is the first boot ("first boot" in step S104), the main processor 201 boots the boot loader 210 (step S105). While the boot loader 210 is running, the target determination SW 220 is activated. As a result, the main processor 201 executes the following step S106.

[0078] The main processor 201 determines whether the current activation target is the APP 250 or the update SW 260 (step S106). That is, the main processor 201 refers to the target flag 262 in the nonvolatile memory 202, and determines that the current activation target is the APP 250 if the value of the target flag 262 is "0", and determines that the current activation target is the update SW 260 if the value of the target flag 262 is "1".

[0079] If the current activation target is APP 250 ("APP" in step S106), main processor 201 activates APP 250 (step S107). If the current activation target is update SW 260 ("Update SW" in step S106), main processor 201 activates update SW 260 (step S108). This completes the activation sequence.

[0080] On the other hand, if the current startup is the second startup ("second startup" in step S104), the APP 250 is already running. Therefore, the startup sequence also ends in this case.

[0081] [2. Second Embodiment] The hardware configuration of the relay ECU 200 according to the second embodiment is the same as the hardware configuration of the relay ECU 200 according to the first embodiment, and therefore description thereof will be omitted. In the second embodiment, the APP 250 is verified in the startup sequence. That is, in FIG. 3, the first verification range of the first verification unit 282 includes the boot loader 210, the determination SW 230, and the APP 250. In a specific example, the first verification range is the boot loader 210, the determination SW 230, the APP 250, and, if the update SW 260 exists, the update SW 260.

[0082] 4, in the first verification process, the security processor 271 verifies the boot loader 210, the determination SW 230, the APP 250, and, if the update SW 260 exists, the update SW 260. Other functions and operations of the relay ECU 200 according to the second embodiment are the same as those of the relay ECU 200 according to the first embodiment, and therefore description thereof will be omitted.

[0083] 3. Third Embodiment 5 is a functional block diagram showing an example of the functions of the relay ECU according to the third embodiment. Note that the hardware configuration of the relay ECU 200 according to the third embodiment is the same as the hardware configuration of the relay ECU 200 according to the first embodiment, and therefore a description thereof will be omitted.

[0084] The relay ECU 200 according to the third embodiment further has a function as an activation target determination unit 284. The first determination unit 281, the first verification unit 282, the second verification unit 283, and the activation target determination unit 284 are each a second function 271B realized by the security processor 271.

[0085] When the first determination unit 281 determines that the current startup is the first startup, the startup target determination unit 284 determines whether to start the APP 250 or the update SW 260 before executing the first verification process. In a specific example, the startup target determination unit 284 determines whether the current startup target is the APP 250 or the update SW 260 based on the target flag 262. That is, when the value of the target flag 262 is "0", the startup target determination unit 284 determines that the startup target is the APP 250. When the value of the target flag 262 is "1", the startup target determination unit 284 determines that the startup target is the update SW 260.

[0086] When the boot target determination unit 284 determines that APP250 is to be booted, the first verification range includes APP250. When the boot target determination unit 284 determines that the update SW260 is to be booted, the first verification range does not include APP250. More specifically, when the boot target determination unit 284 determines that the update SW260 is to be booted, the first verification range includes the update SW260. That is, in the third embodiment, when the boot target is APP250, the first verification unit 282 verifies the determination SW230, the boot loader 210, and the APP250. When the boot target is the update SW260, the first verification unit 282 verifies the determination SW230, the boot loader 210, and the update SW260.

[0087] Other functions of the relay ECU 200 according to the third embodiment are the same as those of the relay ECU 200 according to the first embodiment, and therefore description thereof will be omitted.

[0088] FIG. 6 is a flowchart showing an example of a start-up sequence by the relay ECU according to the third embodiment.

[0089] When it is determined in step S101 that the current boot is the first boot ("first boot" in step S101), security processor 271 determines whether the current boot target is APP 250 or update SW 260 (step S201). That is, security processor 271 refers to object flag 262 in nonvolatile memory 202, and determines that the current boot target is APP 250 if the value of object flag 262 is "0", and determines that the current boot target is update SW 260 if the value of object flag 262 is "1".

[0090] If the current boot target is APP 250 ("APP" in step S201), the security processor 271 verifies the decision SW 230, the boot loader 210, and the APP 250 (step S202). If the current boot target is update SW 260 ("Update SW" in step S201), the security processor 271 verifies the decision SW 230, the boot loader 210, and the update SW 260 (step S203). Steps S202 and S203 are the first verification process S102A according to the third embodiment.

[0091] Other operations of the relay ECU 200 according to the third embodiment are the same as those of the relay ECU 200 according to the first embodiment, and therefore will not be described.

[0092] [4. Variation example] In the above-described embodiments, the activation sequence of the relay ECU 200 has been described, but the invention is not limited to this. The activation sequence of the ECU 300 may also be the same as the above.

[0093] [5. Supplementary Notes] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of the present invention is defined by the claims rather than the above-described embodiments, and includes meanings equivalent to the claims and all modifications within the scope thereof. [Explanation of symbols]

[0094] 10 In-Vehicle Systems 100 In-Vehicle Network 200 Relay ECU (on-board device) 201 Main Processor 201A First Function 202 Non-volatile memory 203 Volatile Memory 204A, 204B, 204C Interface (I / F) 205 Bus 210 Bootloader 211 First Executive Division 212 Second Executive Division 213 Second Judgment Department 214 Startup target determination unit 215 Control Unit 216 Update Department 220 Object Determination Software (Object Determination SW) 230 Judgment Software (Judgment SW) 240 Operating System (OS) 250 Application Software (APP) 260 Update Software (Update SW) 261 Startup Flags 262 Target Flag 270 Security Module 271 Security Processor 271A,271B 2nd function 272 Non-volatile memory 273 Volatile Memory 280 Startup Program 281 1st Judgment Department 282 First Verification Section 283 Second Verification Section 284 Startup target determination unit 300,300A,300B,300C,300D,300E ECU (vehicle equipment) 350 External communication device 400A, 400B, 400C buses 500 servers

Claims

1. a first determination unit that determines, when starting up the in-vehicle device, whether the start-up is a first start-up from a stopped state in which functions are stopped, or a second start-up from a sleep state in which fewer functions are stopped than those stopped in the stopped state; a first verification unit that, when the startup is the first startup, performs a first verification process on software before it is executed in the in-vehicle device; a second verification unit that, when the startup is the second startup, performs a second verification process on the software before it is executed in the in-vehicle device; Equipped with The processing time of the second verification process is shorter than the processing time of the first verification process. In-vehicle device.

2. a second verification range that is a target of the second verification process is smaller than a first verification range that is a target of the first verification process; The in-vehicle device according to claim 1 .

3. the first verification range includes first software that is not included in the second verification range and second software that is included in the second verification range; The in-vehicle device a first execution unit that executes the first software and the second software after the first verification process is completed; a second execution unit that executes the second software after the second verification process is completed; Further provided with The in-vehicle device according to claim 2 .

4. the first software is a boot loader; The in-vehicle device according to claim 3 .

5. the in-vehicle device further includes a second determination unit that executes determination software to determine whether the startup is the first startup or the second startup after the first verification process or the second verification process is completed, the second software is the determination software; The in-vehicle device according to claim 3 .

6. the first software includes object determination software that determines whether to activate control software for controlling hardware or for detecting or monitoring a state of the hardware, a state around the vehicle, or an object around the vehicle, or whether to activate update software for updating the control software; The in-vehicle device a control unit that starts the control software when it is determined that the control software should be started by the execution of the object determination software; an update unit that starts the update software when it is determined that the update software should be started by the execution of the target determination software; Further provided with The in-vehicle device according to any one of claims 3 to 5.

7. the in-vehicle device further includes a boot target determination unit that, when the first determination unit determines that the boot is the first boot, determines whether to boot the control software or the update software before executing the first verification process; when the activation target determination unit determines that the control software is to be activated, the first verification scope includes the control software; When the activation target determination unit determines that the update software is to be activated, the first verification scope does not include the control software. The in-vehicle device according to claim 6.

8. When the activation target determination unit determines that the update software is to be activated, the second verification scope includes the update software. The in-vehicle device according to claim 7.

9. a step of determining, at the time of starting up the in-vehicle device, whether the start-up is a first start-up from a stopped state in which functions are stopped, or a second start-up from a sleep state in which fewer functions are stopped than those stopped in the stopped state; If the startup is the first startup, executing a first verification process of software before it is executed in the in-vehicle device; If the startup is the second startup, executing a second verification process of the software before it is executed in the in-vehicle device; Including, The processing time of the second verification process is shorter than the processing time of the first verification process. A method for starting an in-vehicle device.

10. A startup program executed when the in-vehicle device is started, On the computer, a step of determining, at the time of starting up the in-vehicle device, whether the start-up is a first start-up from a stopped state in which functions are stopped, or a second start-up from a sleep state in which fewer functions are stopped than those stopped in the stopped state; If the startup is the first startup, executing a first verification process of software before it is executed in the in-vehicle device; If the startup is the second startup, executing a second verification process of the software before it is executed in the in-vehicle device; Execute The processing time of the second verification process is shorter than the processing time of the first verification process. Startup program.

Images