Patent Description:
A vehicle has an in-vehicle system that includes a plurality of actuators and a plurality of control devices that controls each of the actuators. Functions of the control devices may be realized by software. By being realized by software, it is possible to correct or add functions by receiving provision of update programs even after they are put on the market. Further, for the correction or addition of the functions that are executed in cooperation with the control devices, such as various pieces of driving assistance, such as autonomous driving, it is required to update software of all target control devices and to confirm whether the update in each control device has been appropriately executed.

For example, <CIT> discloses a technology for determining whether a combination of each software of the ECUs is consistent by comparing identification information of a list stored in a storage unit of each ECU at a time of a start of the in-vehicle system.

Document <CIT> relates to ensuring software compatibility of software updates to a vehicle component with software versions installed to other vehicle components.

The execution of the updated software may be executed at the time of the next start of the in-vehicle system in order to simultaneously switch from pre-updated software in the ECUs. In that case, whether the software has been appropriately updated is also confirmed at the time of a next start of the in-vehicle system.

However, when only some of the control devices from among the control devices are restarted due to some trouble, such as momentary failure of a power source, before the time of the next start of the in-vehicle system, the updated software is executed only in the some part of the control devices that are restarted and an inconsistent state of a combination of software identification information in the control devices is continued at least until the in-vehicle system is started next time, such that a correction or an addition of a function may not be appropriately implemented.

The present disclosure provides an in-vehicle system and a control device that early detect inconsistency in a combination of software identification information in the control devices.

An in-vehicle system according to a first aspect of the present disclosure includes a plurality of control devices including a master control device and a slave control device. Each of the master control device and the slave control device is configured to set, as a start storage area, any one of a plurality of storage areas set as storage areas that store software, and to be started using the software stored in the start storage area. The master control unit is configured to, when software stored in a storage area different from the start storage area is updated in the slave control device, transmit, to the slave control device, a switching instruction for setting the storage area that stores the updated software as the start storage area. The slave control device is configured to, when receiving the switching instruction, implement setting of the start storage area at a time of a next start, and request, at every start, the master control device to execute a consistency determination processing for determining whether pieces of identification information of the software stored in the start storage area are consistent between the control devices. The master control device is configured to, when receiving the request for the execution of the consistency determination processing from the slave control device, execute the consistency determination processing.

In this manner, the master control device is requested to execute the consistency determination processing and executes the consistency determination processing at every start of the slave control device. For this reason, in the case where the storage area that stores the updated software is set as the start storage area at the time of the next start, even when only the slave control device is restarted due to trouble or the like, the master control device is requested to execute the consistency determination processing at the time of the restart. As such, it is possible to early detect inconsistency in a combination of the identification information of the software in the control devices.

In the first aspect, the master control device may be configured to prohibit, when determining that the pieces of identification information of the software stored in the start storage area are not consistent between the control devices, execution of a function implemented by the software.

In this manner, it is possible to restrict the function to be realized by the software from being executed in a state where the combination of the identification information of the software is not consistent in the control devices.

In the first aspect, the master control device may be configured to transmit a completion notification to the slave control device after completion of the consistency determination processing. The slave control device may be configured to determine, using the completion notification, to determine whether to request the execution of the consistency determination processing.

In this manner, when, for example, there is a plurality of requests for the execution of the consistency determination processing for the master control device, it is possible to restrict the consistency determination processing from being unnecessarily executed.

In the first aspect, the slave control device may be configured to request the master control device to determine executability of the consistency determination processing at a time of the start, and determine, using a determination result of the executability and the completion notification from the master control device, whether to request the execution of the consistency determination processing.

In this manner, by requesting for the determination of the executability before requesting for the execution of the consistency determination processing, it is possible to restrict the unnecessary execution of the consistency determination processing from being requested.

In the first aspect, the slave control device may include a first slave control device and a second slave control device. When receiving the request for the determination of the executability from the first slave control device in a case where the request for the determination of the executability is not received from the second slave control device before the first slave control device, the master control device may be configured to transmit, to the first slave control device, a determination result indicating the executability of the consistency determination processing.

In this manner, by transmitting the determination result indicating the executability of the consistency determination processing to the first control device from which the determination request is received before the second control device, the master control device can execute the consistency determination processing in response to the request from the first control device.

In the first aspect, when receiving the request for the determination of the executability from the second control device after the request for the determination of the executability from the first control device, the master control device may be configured to prohibit a transmission of the determination result to the second control device.

In this manner, it is possible to restrict both the first control device and the second control device from requesting the execution of the consistency determination processing.

In the first aspect, the master control device may be configured to transmit, to the master control device, a first completion notification of the consistency determination processing that is executed at a time of a start and a second completion notification of the consistency determination processing that is executed when the execution of the consistency determination processing is requested from the slave control device. The slave control device may be configured to stop, when receiving the first completion notification and the second completion notification, requesting the execution of the consistency determination processing, and request, when not receiving the first completion notification, the execution of the consistency determination processing.

In this manner, it is possible to restrict the slave control device from requesting the unnecessary execution of the consistency determination processing.

A master control device according to a second aspect of the present disclosure is configured to be implemented among a plurality of control devices. Each control device is configured to set, as a start storage area, any one of a plurality of storage areas set as storage areas that store software, and to be started using the software stored in the start storage area. The control device includes one or more processors configured to transmit, when software stored in a storage area different from the start storage area is updated in another control device, to the other control device, a switching instruction for setting the storage area that stores the updated software as the start storage area, receive, at every start of the other control device, a request for execution of a consistency determination processing for determining whether pieces of identification information of the software stored in the start storage area are consistent between the control devices, and execute, when receiving the request for the execution of the consistency determination processing from the other control device, the consistency determination processing. When receiving the switching instruction, the other control device is configured to implement setting of the start storage area at a time of a next start.

A slave control device according to a third aspect of the present disclosure is configured to be implemented among a plurality of control devices. Each control device is configured to set, as a start storage area, any one of a plurality of storage areas set as storage areas that store software, and to be started using the software stored in the start storage area. The control device includes one or more processors configured to implement, when software stored in a storage area different from the start storage area is updated and a switching instruction for setting the storage area that stores the updated software as the start storage area is received, setting of the start storage area at a time of a next start, and request, at every start, a master control device that is any one of the control devices to execute a consistency determination processing for determining whether pieces of identification information of the software stored in the start storage area are consistent between the control devices. When receiving the request for the execution of the consistency determination processing from the control device, the master control device is configured to execute the consistency determination processing.

With each aspect of the present disclosure, it is possible to provide an in-vehicle system and a plurality of control devices that early detect inconsistency in a combination of software identification information in the control devices.

The same or corresponding parts in the drawings are denoted by the same reference signs, and the description thereof is not repeated.

<FIG> is a diagram for describing an example of a configuration of a communication system <NUM>. As illustrated in <FIG>, the communication system <NUM> includes a management server <NUM>, a communication network <NUM>, and an electrified vehicle <NUM> that can communicate with the management server <NUM> via the communication network <NUM>.

The management server <NUM> may be, for example, a computer including a central processing unit (CPU), various memories, and a communication interface. The management server <NUM> provides update information of various pieces of software to a plurality of vehicles or manages an update status of the various pieces of software stored in each of the vehicles. <FIG> illustrates, as an example, the electrified vehicle <NUM>, which is one of the vehicles. In the following description, information exchanged between the management server <NUM> and the electrified vehicle <NUM> is described. However, since information exchanged between the management server <NUM> and other vehicles is the same, detailed description thereof is not repeated.

A storage device (not shown) of the management server <NUM> stores, in advance, for example, identification information (hereinafter, referred to as a vehicle ID), which is unique information for identifying the electrified vehicle <NUM>. Various pieces of software stored in the electrified vehicle <NUM> include, for example, control programs respectively stored in a plurality of electronic control units (ECUs) mounted on the electrified vehicle <NUM>. The management server <NUM> manages identification information including version information of the various pieces of software for each ECU of the electrified vehicle <NUM>. The storage device of the management server <NUM> stores version information of software of a master ECU and version information of software of a slave ECU included in the electrified vehicle <NUM> in association with the vehicle ID, as described below. The management server <NUM> manages version information of the software using a unique item numbers. Upon providing update information to the electrified vehicle <NUM>, the management server <NUM> manages update statuses of the various pieces of software in the electrified vehicle <NUM> using an item number corresponding to the provided update information.

For example, when software with a new item number (a new version) is prepared, the management server <NUM> requests the electrified vehicle <NUM> for update a control program, or provides the electrified vehicle <NUM> with the software with the new item number in response to a request from the electrified vehicle <NUM>.

Next, a specific configuration of the electrified vehicle <NUM> in the present embodiment is described with reference to <FIG> is a diagram schematically illustrating an example of a configuration of the electrified vehicle <NUM> in the present embodiment. As illustrated in <FIG>, the electrified vehicle <NUM> includes a master ECU <NUM>, a slave ECU <NUM>, a drive device <NUM>, a data communication module (DCM) <NUM>, an autonomous driving system (ADS) <NUM>, and a communication bus <NUM>. The master ECU <NUM>, the slave ECU <NUM>, and the ADS <NUM> are communicably connected via the communication bus <NUM>.

The master ECU <NUM> instructs the slave ECU <NUM> to switch to software with an updated item number, described below, or manages the update status of software of each ECU including the master ECU <NUM> itself. The master ECU <NUM> corresponds to a "master control device".

The master ECU <NUM> includes a CPU <NUM> and a memory <NUM>. The master ECU <NUM> may include a plurality of CPUs <NUM>, and may include a plurality of memories <NUM>. When the CPU <NUM> executes a program stored in the memory <NUM>, various pieces of control are executed on a control target of the master ECU <NUM> (for example, the DCM <NUM>). The memory <NUM> includes a first storage area 202A and a second storage area 202B. A control program for starting the master ECU <NUM> is stored in both the first storage area 202A and the second storage area 202B. The master ECU <NUM> sets one of the first storage area 202A and the second storage area 202B as a start storage area, and is, at the time of the start, started with executing the control program stored in the set start storage area at the time of the start. Upon receiving the update information from the management server <NUM> via the DCM <NUM>, the master ECU <NUM> stores the control program that is updated using the update information in a storage area (hereinafter, sometimes referred to as an "update storage area") other than the storage area set as the start storage area. When the updated program is stored in the update storage area, the master ECU <NUM> sets the update storage area as the start storage area at the time of the next start, and also instructs the slave ECU <NUM> described below to set the update storage area as the start storage area at the time of the next start.

For this reason, when the electrified vehicle <NUM> becomes IG-ON (a power source is in an on state) by a user's operation or the like after it becomes IG-off (the power source is an off state), each of the master ECU <NUM> and the slave ECU <NUM> is started with executing the updated control program stored in the start storage area. The storage area set as the start storage area until the time of the start is set as the update storage area. Hereinafter, changing and newly setting the start storage area may be referred to as switching the start storage area.

The master ECU <NUM> acquires the item number (hereinafter, referred to as an updated item number) of the updated control program stored in the slave ECU <NUM> from the management server <NUM> or the slave ECU <NUM>, and stores it in the memory <NUM>. Further, the master ECU <NUM> acquires the item number (hereinafter, referred to as an execution item number) of the control program being executed from the slave ECU <NUM> described below, and stores it in the memory <NUM>.

The DCM <NUM> is an in-vehicle communication module configured to be able to wirelessly communicate with the management server <NUM>. The DCM <NUM> is configured to be able to execute bidirectional data communication with the management server <NUM> according to a control signal from the master ECU <NUM>. The DCM <NUM> is connected to the master ECU <NUM>. Via the DCM <NUM>, the master ECU <NUM> transmits, for example, various requests or information on the electrified vehicle <NUM> to the management server <NUM>, or receives update information of various pieces of software from the management server <NUM>.

The slave ECU <NUM> includes a CPU <NUM> and a memory <NUM>. The slave ECU <NUM> may include a plurality of the CPUs <NUM>, and may include a plurality of the memories <NUM>. The slave ECU <NUM> corresponds to the "slave control device". When the CPU <NUM> executes a program stored in the memory <NUM>, various pieces of control are executed on a control target of the slave ECU <NUM> (for example, the drive device <NUM>). The memory <NUM> includes a third storage area 212A and a fourth storage area 212B. A control program for starting the slave ECU <NUM> is stored in both the third storage area 212A and the fourth storage area 212B. The slave ECU <NUM> sets one of the third storage area 212A and the fourth storage area 212B as a start storage area, and is, at time of the start, started with executing the control program stored in the set start storage area. Upon receiving provision of the update information from the management server <NUM> via the DCM <NUM> and receiving an instruction for switching the start storage area from the master ECU <NUM>, the slave ECU <NUM> sets the update storage area as the start storage area at the time of the next start.

The drive device <NUM> is connected to the slave ECU <NUM> and executes a drive operation for driving the electrified vehicle <NUM> according to a control signal from the slave ECU <NUM>. The drive device <NUM> includes, for example, a motor generator, a power accumulation device, and a power control unit (PCU) (none of which shown). The power accumulation device includes, for example, a secondary battery, such as a nickel-hydrogen battery or a lithium-ion battery having a liquid or solid electrolyte, or a direct current power source, such as a capacitor. The PCU converts direct current power of the power accumulation device into alternating current power and supplies it to the motor generator, or converts alternating current power generated by the motor generator into direct current power and supplies it to the power accumulation device. The motor generator is a drive source and a power generation source of the electrified vehicle <NUM>, and causes drive wheels <NUM> to rotate or generates power by the rotation of the drive wheels <NUM>. The drive device <NUM> may further include an internal combustion engine as a drive source or a power generation source.

The ADS <NUM> is configured to enable autonomous driving of the electrified vehicle <NUM>. Specifically, the ADS <NUM> acquires information (surrounding environment) indicating a state of the electrified vehicle <NUM> from the master ECU <NUM>, the slave ECU <NUM>, and various sensors, and creates a traveling plan using, for example, the acquired information or a destination. The ADS <NUM> outputs various control requests for causing the electrified vehicle <NUM> to travel according to the created traveling plan to the master ECU <NUM> and the slave ECU <NUM> that control various actuators including the drive device <NUM>.

In the present embodiment, the ADS <NUM> is described as being built into the electrified vehicle <NUM>, but it may be capable of being installed at a position decided in advance, such as a rooftop of the electrified vehicle <NUM> and may be composed of an autonomous driving kit that can be removed from the electrified vehicle <NUM>.

In the electrified vehicle <NUM>, driving is executed by any one of an autonomous driving mode in which the autonomous driving can be implemented according to a control request from the ADS <NUM>, and a manual driving mode in which driving can be implemented according to various operations (for example, an accelerator operation, a brake operation, and a steering operation) by a user. As described above, the case where the master ECU <NUM> has the DCM <NUM> as the control target and the slave ECU <NUM> has the drive device <NUM> as the control target has been described as an example, but other actuators mounted on the electrified vehicle <NUM> are controlled by at least one of the master ECU <NUM> and the slave ECU <NUM>.

In the electrified vehicle <NUM> configured as above, the function of each of the master ECU <NUM> and the slave ECU <NUM> is realized by executing software as described above. Then, the software stored in each of the master ECU <NUM> and the slave ECU <NUM> is updated using the update information received from the management server <NUM>, and can correct an existing function or add a new function. In order to appropriately execute the function by these pieces of updated software, the master ECU <NUM> executes consistency determination processing (hereinafter, sometimes referred to as a "version consistency check (VMC)" for confirming whether a combination of the execution item numbers of the software executed in the master ECU <NUM> and the slave ECU <NUM> is consistence after, for example, IG-ON.

When, for example, the combination of the execution item numbers in the master ECU <NUM> and the slave ECU <NUM> is a combination decided in advance, the master ECU <NUM> determines that the combination of the execution item numbers is consistent. The combination decided in advance includes, for example, a combination of item numbers before and after the update. When, for example, the combination of the execution item numbers matches the combination of the update item numbers, the master ECU <NUM> can confirm that switching of the start storage area is appropriately executed.

<FIG> is a diagram for describing an example of operations executed by the master ECU <NUM> and the slave ECU <NUM>. <FIG> illustrates operation histories of the master ECU <NUM> and the slave ECU <NUM>.

For example, when the user executes a start operation for starting a system of the electrified vehicle <NUM>, as illustrated in (A) of <FIG>, the electrified vehicle <NUM> becomes IG-ON. When the electrified vehicle <NUM> becomes IG-ON, power is supplied from a power source to each of the master ECU <NUM> and the slave ECU <NUM> and the master ECU <NUM> and the slave ECU <NUM> are started.

At this time, for example, as illustrated in (B) of <FIG>, it is assumed that the slave ECU <NUM> transmits the execution item number to the master ECU <NUM> after the start. The slave ECU <NUM> transmits, to master ECU <NUM>, for example, the item number of the software stored in the start storage area after the start as the execution item number. A well-known technique may be used as a method for acquiring the item number of the software stored in the start storage area, and detailed description thereof is not given.

As illustrated in (C) of <FIG>, after the electrified vehicle <NUM> becomes IG-ON, the master ECU <NUM> executes VMC by receiving the execution item number from the slave ECU <NUM> for the first time. As such, the master ECU <NUM> can determine whether the combination of the execution item numbers is consistent according to whether a combination of a first execution item number of software being executed in the master ECU <NUM> and a received second execution item number of the software being executed in the slave ECU <NUM> is a combination decided in advance.

The master ECU <NUM> may acquire, for example, configuration information on the combination decided in advance from the management server <NUM>, or may acquire, as the configuration information, the combination of the item numbers before and after the update, using the update information received from the management server <NUM>.

However, when the slave ECU <NUM> is restarted due to an occurrence of some trouble, such as momentary failure of a power source that supplies power to the slave ECU <NUM> after the master ECU <NUM> instructs the slave ECU <NUM> to switch the start storage area at the time of the next start and before the electrified vehicle <NUM> becomes IG-OFF, the switching of the start storage area may be executed only in the slave ECU <NUM>.

For example, as illustrated in (D) of <FIG>, when the slave ECU <NUM> is reset due to an occurrence of some trouble, as illustrated in (E) of <FIG>, the slave ECU <NUM> is restarted. At this time, as illustrated in (F) of <FIG>, even when the execution item number is transferred to the master ECU <NUM>, VMC is not executed in the master ECU <NUM>. For this reason, since the execution item number of the master ECU <NUM> becomes the item number before the update and the execution item number of the slave ECU <NUM> becomes the item number after the update before the time of the next start of the master ECU <NUM>, a period in which the combination of the execution item numbers between the master ECU <NUM> and the slave ECU <NUM> becomes inconsistent occurs.

<FIG> is a diagram for describing an example of operations when the combination of the execution numbers between the master ECU <NUM> and the slave ECU <NUM> becomes inconsistent. As illustrated in <FIG>, the master ECU <NUM> includes a control unit 201A and a switching unit 201B. When the updated software is stored in the update storage area, as illustrated in (A) of <FIG>, the control unit 201A transmits a switching instruction to the slave ECU <NUM> and the switching unit 201B in the master ECU <NUM>. Upon receiving the switching instruction from the control unit 201A, as illustrated in (B) and (C) of <FIG>, the switching unit 201B and the slave ECU <NUM> respectively execute switching processing of the start storage area and set the update storage area as the start storage area at the time of the next start (corresponds to the time of the IG-ON illustrated in (G) of <FIG>.

However, as illustrated in (D) of <FIG> thereafter, when momentary failure of the power source occurs in the slave ECU <NUM>, only the slave ECU <NUM> is restarted. As a result, since the slave ECU <NUM> is started using the updated software, in a period until a timing in which the electrified vehicle <NUM> becomes IG-OFF as illustrated in (F) of <FIG>, the execution item number of the master ECU <NUM> becomes the item number of the software before the update, and the execution item number of the slave ECU <NUM> becomes the item number of the software after the update. For this reason, a period in which the combination of the execution item numbers becomes inconsistent occurs.

Then, in the present embodiment, at the time of the start of the slave ECU <NUM>, the slave ECU <NUM> requests the master ECU <NUM> to execute the consistency determination processing for determining whether the identification information (that is, the execution item number) of the software stored in the start storage area is consistent between the master ECU <NUM> and the slave ECU <NUM>. In each of when the master ECU <NUM> is started and when it receives the request for the execution of the consistency determination processing from the slave ECU <NUM>, the master ECU <NUM> executes the consistency determination processing (VMC).

In this manner, the master ECU <NUM> is requested to execute the consistency determination processing at the time of the start of the slave ECU <NUM> and executes the consistency determination processing. For this reason, in the case where the update storage area is set as the start storage area at the time of the next start, even when only the slave ECU <NUM> is restarted due to trouble or the like, the master ECU <NUM> is requested to execute the consistency determination processing at the time of restart. As such, it is possible to early detect the inconsistency in the combination of the execution item numbers between the master ECU <NUM> and the slave ECU <NUM>.

Hereinafter, an example of processing executed by the master ECU <NUM> is described with reference to <FIG> is a flowchart illustrating an example of the processing executed by the master ECU <NUM>. A series of processes illustrated in this flowchart are repeatedly executed by the master ECU <NUM> at each predetermined processing cycle.

At step (hereinafter, step is referred to as S)<NUM>, the master ECU <NUM> determines whether an initial check has been unimplemented. The master ECU <NUM> determines whether the initial check is unimplemented based on, for example, a state of a flag indicating whether the initial check has been implemented. When, for example, the flag is in an OFF state, the master ECU <NUM> determines that the initial check has been unimplemented. The master ECU <NUM> may set the flag to the OFF state, for example, immediately after the start, or may set the flag to the OFF state when the electrified vehicle <NUM> becomes IG-OFF. When the master ECU <NUM> determines that the initial check has been unimplemented (YES in S100), the process proceeds to S102.

In S102, the master ECU <NUM> determines whether all the execution item numbers have been acquired. The master ECU <NUM> determines that all the execution item numbers have been acquired when, for example, the first execution item number and the second execution item number have been acquired. The master ECU <NUM> acquires, for example, the item number of the software stored in the start storage area of the memory <NUM> as the first execution item number. The master ECU <NUM> acquires the second execution item number from, for example, the slave ECU <NUM>. When the master ECU <NUM> determines that all the execution item numbers have been acquired (YES in S <NUM>), the process proceeds to S104.

In S104, the master ECU <NUM> executes the consistency determination processing. The master ECU <NUM> determines whether the combination of the first execution item number and the second execution item number is the combination decided in advance. The master ECU <NUM> compares the combination of the first execution item number and the second execution item number with the combination stored in the memory <NUM> and decided in advance, and determines whether they match. Since the method of acquiring the combination decided in advance is as described above, detailed description thereof is not repeated. Thereafter, the process proceeds to S108. When the master ECU <NUM> determines that all the execution item numbers have not been acquired (NO in S102), the process proceeds to S106.

In S106, the master ECU <NUM> determines whether a reception standby time of the execution item numbers is longer than a predetermined time T1. The reception standby time may be, for example, an elapsed time since it is determined that the initial check has been unimplemented. The predetermined time T1 is adapted by, for example, experimentations or the like. When the master ECU <NUM> determines that the reception standby time of the execution item numbers is longer than the predetermined time T1 (YES in S106), the process proceeds to S116. When the master ECU <NUM> determines that the reception standby time of the execution item numbers is equal to or shorter than the predetermined time T1 (NO in S106), the process proceeds to S102.

In S108, the master ECU <NUM> determines whether the first execution item number and the second execution item number are consistent. For example, when the combination of the first execution item number and the second execution item number is a combination decided in advance, such as a combination of the item numbers of the software before the update or a combination of the item numbers of the software after the update, the master ECU <NUM> determines that the first execution item number and the second execution item number are consistent. When the master ECU <NUM> determines that the first execution item number and the second execution item number are consistent (YES in S108), the process proceeds to S110. When the master ECU <NUM> determines that the first execution item number and the second execution item number are not consistent (NO in S108), the process proceeds to S116.

In S110, the master ECU <NUM> transmits, to the slave ECU <NUM>, information (hereinafter, referred to as a completion notification) indicating that the consistency determination processing has been completed. Thereafter, the process proceeds to S112.

In S112, the master ECU <NUM> sets a state of the flag indicating whether the initial check has been completed to the ON state. Thereafter, the process proceeds to S114.

In S114, the master ECU <NUM> sets the autonomous driving to a permitted state. When the autonomous driving is set to the permitted state, the autonomous driving of the electrified vehicle <NUM> using the ADS <NUM> can be implemented. For this reason, in the electrified vehicle <NUM>, when the autonomous driving mode is selected, the autonomous driving using the ADS <NUM> is implemented.

In S116, the master ECU <NUM> sets the autonomous driving to an unpermitted state. In a case where the autonomous driving is set to the unpermitted state, when the autonomous driving mode is being selected, it is switched to the manual driving mode. Further, even when an operation for selecting the autonomous driving mode is executed while the manual operation mode is being selected, selection of the autonomous driving mode is rejected.

Next, an example of another processing executed by the master ECU <NUM> is described with reference to <FIG> is a flowchart illustrating an example of another processing executed by the master ECU <NUM>. A series of processes illustrated in this flowchart are repeatedly executed by the master ECU <NUM> at each predetermined processing cycle.

In S <NUM>, the master ECU <NUM> determines whether the initial check has been implemented. Since the method of determining whether the initial check has been implemented is as described above, detailed description thereof not repeated. When the master ECU <NUM> determines that the initial check has been implemented (YES in S150), the process proceeds to S152.

In S <NUM>, the master ECU <NUM> determines whether a VMC request is received from the slave ECU <NUM>. The "VMC request" includes a request for the execution of the consistency determination processing. When the master ECU <NUM> determines that the VMC request is received from the slave ECU <NUM> (YES in S152), the process proceeds to S154. When the master ECU <NUM> determines that the VMC request is not received (NO in S <NUM>), the process returns to S152.

In S154, the master ECU <NUM> executes the consistency determination processing. Since the method of executing the consistency determination processing is as described above, detailed description thereof is not repeated. Thereafter, the process proceeds to S156.

In S156, the master ECU <NUM> determines whether the first execution item number and the second execution item number are consistent. Since the method of the determination is as described above, detailed description thereof is not repeated. When the master ECU <NUM> determines that the first execution item number and the second execution item number are consistent (YES in S <NUM>), the process proceeds to S <NUM>.

In S158, the master ECU <NUM> transmits the completion notification to the slave ECU <NUM>. Since the completion notification is as described above, detailed description thereof is not repeated.

In S160, the master ECU <NUM> sets the autonomous driving to the permitted state. Since the operation of the electrified vehicle <NUM> in the permitted state of the autonomous driving is as described above, detailed description thereof is not repeated. Thereafter, the process returns to S152. When the master ECU <NUM> determines that the first execution item number and the second execution item number are not consistent (NO in S156), the process proceeds to S162.

In S162, the master ECU <NUM> sets the autonomous driving to the unpermitted state. Since the operation of the electrified vehicle <NUM> in the unpermitted state of the autonomous driving is as described above, detailed description thereof is not repeated. Thereafter, the process ends. When the master ECU <NUM> determines that the initial check has not been implemented (NO in S150), the process ends.

Next, an example of processing executed by the slave ECU <NUM> is described with reference to <FIG> is a flowchart illustrating an example of the processing executed by the slave ECU <NUM>. A series of processes illustrated in this flowchart are repeatedly executed by the slave ECU <NUM> at each predetermined processing cycle.

In S200, the slave ECU <NUM> determines whether it is the time of the start. When, for example, start processing for starting the slave ECU <NUM> is being executed, the slave ECU <NUM> determines that it is the time of the start of the slave ECU <NUM>. When the slave ECU <NUM> determines that it is the time of the start of the slave ECU <NUM> (YES in S200), the process proceeds to S202.

In S202, the slave ECU <NUM> transmits the second execution item number to the master ECU <NUM>. Since the second execution item number is as described above, detailed description thereof is not repeated. Thereafter, the process proceeds to S204.

In S204, the slave ECU <NUM> transmits the VMC request. Since the VMC request is as described above, detailed description thereof is not repeated. The slave ECU <NUM> may intermittently transmit the VMC request each time a predetermined time elapses, or may continuously transmit the VMC request.

In S206, the slave ECU <NUM> determines whether the completion notification has been received from the master ECU <NUM>. Since the completion notification is as described above, detailed description thereof is not repeated. When the slave ECU <NUM> determines that the completion notification has been received (YES in S206), the process proceeds to S208.

In S208, the slave ECU <NUM> stops the transmission of the VMC request. When the completion notification has not been received from the master ECU <NUM> (NO in S206), the process proceeds to S210.

In S210, the slave ECU <NUM> determines whether the reception standby time of the completion notification is longer than a predetermined time T2. The reception standby time of the completion notification may be, for example, an elapsed time from a point at which the VMC request has been sent. The predetermined time T2 is adapted by, for example, experimentations or the like. When the slave ECU <NUM> determines that the reception standby time of the completion notification is longer than the predetermined time T2 (YES in S210), the process proceeds to S208. When the slave ECU <NUM> determines that the reception standby time of the completion notification is equal to or shorter than the predetermined time T2 (NO in S210), the process returns to S206. Further, when the slave ECU <NUM> determines that it is not the time of the start of the slave ECU <NUM> (NO in S200), the process ends.

An example of operations of the master ECU <NUM> and the slave ECU <NUM> based on the above structure and the flowcharts is described with reference to <FIG>.

<FIG> is a diagram for describing an example of the operation of the master ECU <NUM> and an example of the operation of the slave ECU <NUM>. <FIG> illustrates operation histories of the master ECU <NUM> and the slave ECU <NUM>.

For example, when the user executes the start operation for starting the system of the electrified vehicle <NUM>, as illustrated in (A) of <FIG>, the electrified vehicle <NUM> becomes IG-ON. When the electrified vehicle <NUM> becomes IG-ON, power is supplied from a power source to each of the master ECU <NUM> and the slave ECU <NUM> and the master ECU <NUM> and the slave ECU <NUM> are started.

When the slave ECU <NUM> determines that it is the time of the start (YES in S200), as illustrated in (B-<NUM>) of <FIG>, the second execution item number is transmitted to the master ECU <NUM> (S202), and, as illustrated in (B-<NUM>) of <FIG>, the VMC request is transmitted to master ECU <NUM> (S204).

When the master ECU <NUM> determines that the initial check is unimplemented (YES in S100), it is determined whether all the execution item numbers have been received (S102). When the first execution item number is acquired and the second execution item number is received from the slave ECU <NUM>, it is determined that all the execution item numbers have been received (YES in S102), and, as illustrated in (C-<NUM>) of <FIG>, the VMC is executed (S104). When the VMC is executed and the master ECU <NUM> determines that the first execution item number and the second execution item number are consistent (YES in S108), as illustrated in (C-<NUM>) of <FIG>, the completion notification is transmitted to the slave ECU <NUM> (S110). Thereafter, the flag indicating whether the initial check has been implemented is set to the ON state (S112), and the autonomous driving is permitted (S114). Upon receiving the completion notification (YES in S206), the slave ECU <NUM> stops the transmission of the VMC request (S208).

for example, as illustrated in (D) of <FIG>, it is assumed that the slave ECU <NUM> is reset due to some trouble. As such, as illustrated in (E) of <FIG>, in a case where the slave ECU <NUM> is restarted, when the slave ECU <NUM> determines that it is the time of the start (YES in S200), as illustrated in (F-<NUM>) of <FIG>, the second execution item number is transmitted to the master ECU <NUM> (S202). Then, as illustrated in (F-<NUM>) of <FIG>, the VMC request is transmitted to the master ECU <NUM> (S204).

In the case where the master ECU <NUM> determines that the initial check has been implemented (YES in S150), when the VMC request is received from the slave ECU <NUM> (YES in S152), as illustrated in (G-<NUM>) of <FIG>, the VMC is executed (S154). When the VMC is executed and the master ECU <NUM> determines that the first execution item number and the second execution item number are consistent (YES in S156), as illustrated in (G-<NUM>) of <FIG>, the completion notification is transmitted to the slave ECU <NUM> (S158). Thereafter, the autonomous driving is permitted (S <NUM>). Upon receiving the completion notification (YES in S206), the slave ECU <NUM> stops the transmission of the VMC request (S208).

In this manner, the slave ECU <NUM> transmits the second execution item number and the VMC request each time of the start. Further, in the case where the initial check is unimplemented, the master ECU <NUM> executes the VMC by receiving the second execution item number from the slave ECU <NUM>. Further, in the case where the initial check has been implemented, the master ECU <NUM> executes the VMC by receiving the VMC request from the slave ECU <NUM>.

For this reason, for example, when the updated software is stored in the update storage areas of the master ECU <NUM> and the slave ECU <NUM> and the update storage areas are set as the start storage areas at the time of the next start, before the electrified vehicle <NUM> becomes IG-OFF, even when the slave ECU <NUM> is restarted due to some trouble occurring in the slave ECU <NUM> and the slave ECU <NUM> is started using the updated software, the VMC is promptly executed by the VMC request from the slave ECU <NUM> to the master ECU <NUM>. When it is determined that the first execution item number and the second execution item number are not consistent by executing the VMC (NO in S156), the autonomous driving becomes the unpermitted state or the like (S162), and the execution of the function using the updated software only in the slave ECU <NUM> is restricted.

As described above, according to the in-vehicle system of the present embodiment, the master ECU <NUM> is requested to execute the VMC each time the slave ECU <NUM> is started, and the master ECU <NUM> executes the VMC. For this reason, in the case where the update storage area is set as the start storage area at the time of the next start, even when only the slave ECU <NUM> is restarted due to a trouble or the like, the VMC request is transmitted to the master ECU <NUM> at the time of the restart. As such, it is possible to early detect the inconsistency in the combination of the execution item numbers between the master ECU <NUM> and the slave ECU <NUM>. Therefore, it is possible to provide the in-vehicle system and the control devices that early detect inconsistency in the combination of the identification information of the software in the control devices.

Further, when it is determined by the execution of the VMC that the first execution item number and the second execution item number are not consistent, the execution of the function (for example, the autonomous driving using the ADS <NUM>) to be realized by the software stored in the start storage area becomes the unpermitted state (a prohibited state). In this manner, it is possible to restrict the function, such as the autonomous driving, from being executed in a state where the first execution item number and the second execution item number are not consistent.

Hereinbelow, modified examples will be described.

In the above-described embodiment, a configuration in which the ECUs mounted on the electrified vehicle <NUM> include the master ECU <NUM> and the slave ECU <NUM> has been described as an example, but the configuration may have the ECUs including the master ECU <NUM> and a plurality of ECUs. In this modified example, for example, a configuration in which the ECUs mounted on the electrified vehicle <NUM> include the master ECU <NUM>, a first slave ECU 210A, and a second slave ECU 210B will be described as an example.

<FIG> is a diagram schematically illustrating an example of a configuration of the electrified vehicle <NUM> in the modified example. Compared to the configuration of the electrified vehicle <NUM> illustrated in <FIG>, the electrified vehicle <NUM> illustrated in <FIG> differs in that it includes the first slave ECU 210A instead of the slave ECU <NUM> and further includes the second slave ECU 210B. Other configurations have the same configuration, and are denoted by the same reference signs. For this reason, detailed description thereof is not repeated.

For example, the first slave ECU 210A has the same configuration as the slave ECU <NUM> of <FIG>. Compared to the first slave ECU 210A, the second slave ECU 210B has a different detection targets of sensors, control targets (for example, a steering system or a brake system) and control operations. Other configurations are similar to those of the slave ECU <NUM>. For this reason, detailed description of each of the first slave ECU 210A and the second slave ECU 210B is not repeated.

Even in a configuration including a plurality of slave ECUs, the same problem as when there is a single slave ECU may occur.

<FIG> is a diagram for describing an example of operations executed by the master ECU <NUM> and the slave ECUs in the modified example. <FIG> illustrates operation histories of the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B.

For example, when the user executes a start operation for starting a system of the electrified vehicle <NUM>, as illustrated in (A) of <FIG>, the electrified vehicle <NUM> becomes IG-ON. When the electrified vehicle <NUM> becomes IG-ON, power is supplied from the power source to each of the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B, and the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B are started.

At this time, as illustrated in (B) of <FIG>, in the first slave ECU 210A, for example, it is assumed that the item number of the software stored in the start storage area of a memory of the first slave ECU 210A after the start is transmitted to the master ECU <NUM> as the execution item number.

Further, as illustrated in (C) of <FIG>, similar to the first slave ECU 210A, in the second slave ECU 210B, for example, it is assumed that the item number of the software stored in the start storage area of a memory of the second slave ECU 210B after the start is transmitted to the master ECU <NUM> as the execution item number.

As illustrated in (D) of <FIG>, after the electrified vehicle <NUM> becomes IG-ON, the master ECU <NUM> executes the VMC by receiving the execution item number from the first slave ECU 210A and the second slave ECU 210B. As such, the master ECU <NUM> can determine whether a combination of the execution item numbers is consistent by whether a combination of the first execution item number of the software being executed in the master ECU <NUM>, the second execution item number of the software being executed in the received first slave ECU 210A, and the third execution item number of the software being executed in the received second slave ECU 210B is the combination decided in advance. The combination of the execution item numbers decided in advance is acquired in the same manner as the combination of the two execution item numbers decided in advance in the embodiment described in advance. For this reason, detailed description thereof is not repeated.

However, in this case, in the same manner as in the embodiment described above, after the master ECU <NUM> instructs each of the first slave ECU 210A and the second slave ECU 210B to switch the start storage area at the time of the next start, when any one of the first slave ECU 210A and the second slave ECU 210B is restarted due to an occurrence of some trouble, such as momentary failure of power source that supplies power before the electrified vehicle <NUM> becomes IG-OFF, the switching of the start storage area may be executed only in the slave ECU.

For example, as illustrated in (E) of <FIG>, when the first slave ECU 210A is reset due to an occurrence of some trouble, the first slave ECU 210A is restarted. At this time, as illustrated in (F) of <FIG>, even when the execution item number is transmitted to the master ECU <NUM>, the VMC is not executed in the master ECU <NUM>. For this reason, since the execution item numbers of the master ECU <NUM> and the second slave ECU 210B become the item numbers before the update, and the execution item number of the first slave ECU 210A becomes the item number after the update before the time of the next start of the master ECU <NUM> and the second slave ECU 210B, a period in which the combination of the execution item numbers is inconsistent between the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B occurs. In the same manner as when some trouble occurs in the second slave ECU 210B, in this case, a period in which the combination of execution item numbers is inconsistent may occur.

Then, in the modified example, at the time of the start of each of the first slave ECU 210A and the second slave ECU 210B, they request the master ECU <NUM> to execute the consistency determination processing for determining whether the identification information (that is, the execution item number) of the software stored in the start storage area is consistent between the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B. In each of when the master ECU <NUM> is started and when it receives the request for the execution of the consistency determination processing from the first slave ECU 210A or the second slave ECU 210B, the master ECU <NUM> executes the consistency determination processing (the VMC).

In this manner, the master ECU <NUM> is requested to execute the consistency determination processing at the start of the first slave ECU 210A or the second slave ECU 210B, and executes the consistency determination processing. For this reason, in the case where the update storage area is set as the start storage area at the time of the next start, even when the first slave ECU 210A or the second slave ECU 210B is restarted due to a trouble or the like, the master ECU <NUM> is requested to execute the consistency determination processing at the restart. As such, it is possible to early detect the inconsistency in the combination of the execution item numbers between the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B.

Hereinafter, an example of processing executed by the master ECU <NUM> is described with reference to <FIG> in the modified example. <FIG> is a flowchart illustrating an example of the processing executed by the master ECU <NUM> in the modified example. A series of processes illustrated in this flowchart are repeatedly executed by the master ECU <NUM> at each predetermined processing cycle.

The flowchart of <FIG> differs from that of <FIG> in that processes of S300, S302, S304, S306, and S308 are executed in the former instead of the processes of S102, S104, S106, S108, and S110. In the flowchart of <FIG>, the same step numbers are assigned to the same processes as in the flowchart of <FIG>, and the contents of the processes are also the same except for cases described below. For this reason, detailed description thereof is not repeated.

When the master ECU <NUM> determines that the initial check has been unimplemented (YES in S100), the process proceeds to S300.

In S300, the master ECU <NUM> determines whether all the execution item numbers have been acquired. The master ECU <NUM> determines that all the execution item numbers have been acquired when, for example, the first execution item number, the second execution item number, and the third execution item number have been acquired. The master ECU <NUM> acquires, for example, the item number of the software stored in the start storage area of the memory <NUM> as the first execution item number. The master ECU <NUM> acquires the second execution item number from, for example, the first slave ECU 210A. Further, the master ECU <NUM> acquires the third execution item number from, for example, the second slave ECU 210B. When the master ECU <NUM> determines that all the execution item numbers have been acquired (YES in S300), the process proceeds to S302.

In S302, the master ECU <NUM> executes the consistency determination processing. The master ECU <NUM> determines whether the combination of the first execution item number, the second execution item number, and the third execution item number is the combination decided in advance. Thereafter, the process proceeds to S308. When the master ECU <NUM> determines that all the execution item numbers have not been acquired (NO in S300), the process proceeds to S304.

In S304, the master ECU <NUM> determines whether the reception standby time of the execution item numbers is longer than the predetermined time T1. Since the reception standby time and the predetermined time T1 are as described above, detailed description thereof is not repeated. When the master ECU <NUM> determines that the reception standby time of the execution item numbers is longer than the predetermined time T1 (YES in S304), the process proceeds to S116. When the master ECU <NUM> determines that the reception standby time of the execution item numbers is equal to or shorter than the predetermined time T1 (NO in S304), the process returns to S300.

In S306, the master ECU <NUM> determines whether the first execution item number, the second execution item number, and the third execution number are consistent. For example, when the combination of the first execution item number, the second execution item number, and the third execution item number is the combination decided in advance, such as the combination of the item numbers of the software before the update or the combination of the item numbers of the software after the update, the master ECU <NUM> determines that the first execution item number, the second execution item number, and the third execution item number are consistent. When the master ECU <NUM> determines that the first execution item number, the second execution item number, and the third execution item number are consistent (YES in S306), the process proceeds to S308. When the master ECU <NUM> determines that the first execution item number, the second execution item number, and the third execution item number are not consistent (NO in S306), the process proceeds to S116.

In S308, the master ECU <NUM> transmits the completion notification (hereinafter, referred to as a completion notification at the time of master start) of the consistency determination processing at the time of the master start. The master ECU <NUM> transmits the completion notification at the time of the master start to each of the first slave ECU 210A and the second slave ECU 210B. Thereafter, the process proceeds to S112.

Next, another example of processing executed by the master ECU <NUM> is described with reference to <FIG> in the modified example. <FIG> is a flowchart illustrating an example of another processing executed by the master ECU <NUM> in the modified example. A series of processes illustrated in this flowchart are repeatedly executed by the master ECU <NUM> at each predetermined processing cycle.

The flowchart of <FIG> differs from that of <FIG> in that processes of S400, S402, S404, S406, S408, S410, S412, S414, and S416 are executed in the former instead of the processes of S152, S154, S156, and S158. In the flowchart of <FIG>, the same step numbers are assigned to the same processes as in the flowchart of <FIG>, and the contents of the processes are also the same except for cases described below. For this reason, detailed description thereof is not repeated.

When the master ECU <NUM> determines that the initial check has been unimplemented (YES in S150), the process proceeds to S400.

In S400, the master ECU <NUM> determines whether a VMC state confirmation (n) (n is <NUM> or <NUM>) is received. Upon, for example, receiving a VMC state confirmation (<NUM>) from the first slave ECU 210A or upon receiving a VMC state confirmation (<NUM>) from the second slave ECU 210B, the master ECU <NUM> determines that the VMC state confirmation (n) has been received. Details of the VMC state confirmation (<NUM>) and the VMC state confirmation (<NUM>) will be described below. When the master ECU <NUM> determines that the VMC state confirmation (n) has been received (YES in S400), the process proceeds to S402. When the master ECU <NUM> determines that the VMC state confirmation (n) has not been received (NO in S400), the process returns to S400.

In S402, the master ECU <NUM> determines whether a VMC state confirmation (m) (m is <NUM> or <NUM> other than n) is received. Upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> determines whether to receive the VMC state confirmation (<NUM>). Alternatively, upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> determines whether to receive the VMC state confirmation (<NUM>). When the master ECU <NUM> determines that the VMC state confirmation (m) has been received (YES in S402), the process proceeds to S404. When the master ECU <NUM> determines that the VMC state confirmation (m) has not been received (NO in S402), the process proceeds to S406.

In S404, the master ECU <NUM> does not permit transmission of a VMC possibility (m), which is a notification indicating that the VMC can be executed. For example, upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> does not permit transmission of a VMC possibility (<NUM>) to the second slave ECU 210B. Alternatively, for example, upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> does not permit transmission of the VMC possibility (<NUM>) to the first slave ECU 210A. Thereafter, the process proceeds to S406.

In S406, the master ECU <NUM> transmits a VMC possibility (n). For example, upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> transmits the VMC possibility (<NUM>) to the first slave ECU 210A. The VMC possibility (<NUM>) includes information indicating that the VMC can be executed by the request of the first slave ECU 210A. Alternatively, for example, upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> transmits the VMC possibility (<NUM>) to the second slave ECU 210B. The VMC possibility (<NUM>) includes information indicating that the VMC can be executed by the request of the second slave ECU 210B. Thereafter, the process proceeds to S408.

In S408, the master ECU <NUM> determines whether a VMC request (n) is received. For example, upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> determines that the VMC request (n) has been received when it receives the VMC request (<NUM>) from the first slave ECU 210A. The VMC request (<NUM>) includes a VMC execution request to the master ECU <NUM> of which a transmission source is the first slave ECU 210A. Alternatively, for example, upon receiving the VMC state confirmation (<NUM>) in S400, the master ECU <NUM> determines that the VMC request (n) has been received when it receives the VMC request (<NUM>) from the second slave ECU 210B. The VMC request (<NUM>) includes the VMC execution request to the master ECU <NUM> of which the transmission source is the second slave ECU 210B. When the master ECU <NUM> determines that the VMC request (n) has been received (YES in S408), the process proceeds to S410.

In S410, the master ECU <NUM> executes the consistency determination processing. Since the consistency determination processing is the same as the process of S302, detailed description thereof is not repeated. Thereafter, the process proceeds to S414. When the master ECU <NUM> determines that the VMC request (n) has not been received (NO in S408), the process proceeds to S412.

In S412, the master ECU <NUM> determines whether the VMC request (m) has been received. For example, upon receiving the VMC state confirmation (<NUM>) in S400 and receiving the VMC request (<NUM>), the master ECU <NUM> determines that the VMC request (m) has been received. For example, upon receiving the VMC state confirmation (<NUM>) in S400 and receiving the VMC request (<NUM>), the master ECU <NUM> determines that the VMC request (m) has been received. When the master ECU <NUM> determines that the VMC request (m) has been received (YES in S412), the process returns to S408. When the master ECU <NUM> determines that the VMC request (m) has not been received (NO in S412), the process returns to S408.

In S414, the master ECU <NUM> determines whether the first execution item number, the second execution item number, and the third execution number are consistent. Since the determination method is as described above, detailed description thereof is not repeated. When the master ECU <NUM> determines that the first execution item number, the second execution item number, and the third execution item number are consistent (YES in S414), the process proceeds to S416. When the master ECU <NUM> determines that the first execution item number, the second execution item number, and the third execution item number are not consistent (NO in S414), the process proceeds to S162.

In S416, the master ECU <NUM> transmits the completion notification. The master ECU <NUM> transmits the completion notification to each of the first slave ECU 210A and the second slave ECU 210B. Thereafter, the process proceeds to S418.

In S418, the master ECU <NUM> permits the transmission of the VMC possibility (m). For example, master ECU <NUM> permits the transmission of the VMC possibility (m) by not permitting the transmission in S404. Thereafter, the process proceeds to S160.

Next, an example of processing executed by each of the first slave ECU 210A and the second slave ECU 210B is described with reference to <FIG> is a flowchart illustrating an example of another processing executed by each of the first slave ECU 210A and the second slave ECU 210B in the modified example, "n" illustrated in the flowchart illustrated in <FIG> is a value indicating an execution subject. For example, when n = <NUM>, the flowchart of <FIG> illustrates the processing in which the first slave ECU 210A is the execution subject. Further, when n = <NUM>, the flowchart of <FIG> illustrates the processing in which the second slave ECU 210B is the execution subject. In the following description, a case where execution subject of the processing illustrated in the flowchart of <FIG> is the first slave ECU 210A is described as an example. Since the same applies to a case where the second slave ECU 210B is the execution subject, detailed description thereof is not repeated.

In S500, the first slave ECU 210A determines whether it is the time of the start. Since the determination method is the same as the determination method in the process of S200 described above, detailed description thereof is not repeated. When the first slave ECU 210A determines that it is the time of the start (YES in S500), the process proceeds to S502. When the first slave ECU 210A determines that it is not the time of the start (NO in S500), the process ends.

In S502, the first slave ECU 210A transmits the second execution item number to master ECU <NUM> as the execution item number (n). Thereafter, the process proceeds to S504.

In S504, the first slave ECU 210A transmits the VMC state confirmation (<NUM>) to the master ECU <NUM> as the VMC state confirmation (n). Thereafter, the process proceeds to S506.

In S506, the first slave ECU 210A determines whether the completion notification at the time of the master start has been received. When the first slave ECU 210A determines that the completion notification at the time of the master start has been received (YES in S506), the process proceeds to S508.

In S508, the first slave ECU 210A stops the transmission of the VMC state confirmation (<NUM>) and the VMC request (<NUM>). For example, when the VMC state confirmation (<NUM>) is being transmitted, the first slave ECU 210A stops the transmission of the VMC state confirmation (<NUM>). Further, for example, when the VMC state confirmation (<NUM>) and the VMC request (<NUM>) are being transmitted, the first slave ECU 210A stops the transmission of the VMC state confirmation (<NUM>) and the VMC request (<NUM>). When the first slave ECU 210A determines that the completion notification at the time of the master start has not been received (NO in S506), the process proceeds to S510.

In S510, the first slave ECU 210A determines whether the VMC possibility (n) is received from the master ECU <NUM>. Upon receiving the VMC possibility (<NUM>) from the master ECU <NUM>, the first slave ECU 210A determines that the VMC possibility (n) has been received. When the first slave ECU 210A determines that the VMC possibility (n) has been received (YES in S510), the process proceeds to S512. When the first slave ECU 210A determines that the VMC possibility (<NUM>) has not been received (NO in S510), the process returns to S506.

In S512, the first slave ECU 210A transmits the VMC request (n) to the master ECU <NUM>. The first slave ECU 210A transmits the VMC request (<NUM>) to the master ECU <NUM> as the VMC request (n). Thereafter, the process proceeds to S514.

In S514, the first slave ECU 210A determines whether the completion notification has been received from the master ECU <NUM>. When the first slave ECU 210A determines that the completion notification has been received (YES in S514), the process proceeds to S508. When the first slave ECU 210A determines that the completion notification has not been received (NO in S514), the process proceeds to S516.

In S516, the first slave ECU 210A determines whether the reception standby time of the completion notification is longer than the predetermined time T2. Since the reception standby time of the completion notification and the predetermined time T2 are as described above, detailed description thereof is not repeated. When the first slave ECU 210A determines that the reception standby time of the completion notification is longer than the predetermined time T2 (YES in S516), the process proceeds to S508. When the first slave ECU 210A determines that the reception standby time of the completion notification is equal to or shorter than the predetermined time T2 (NO in S516), the process returns to S514.

The example of operations of the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B based on the above flowcharts in the modified example is described with reference to <FIG>.

<FIG> is a diagram for describing an example of the operation of the master ECU <NUM> and an example of the operation of each slave ECU in the modified example. <FIG> illustrates operation histories of the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B.

For example, when the user executes the start operation for starting the system of the electrified vehicle <NUM>, as illustrated in (A) of <FIG>, the electrified vehicle <NUM> becomes IG-ON. When the electrified vehicle <NUM> becomes IG-ON, power is supplied from the power source to each of the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B, and the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B are started.

When it is determined that the first slave ECU 210A is started (YES in S500), as illustrated in (B-<NUM>) of <FIG>, the second execution item number is transmitted to the master ECU <NUM> (S502), and, as illustrated in (B-<NUM>) of <FIG>, the VMC state confirmation (<NUM>) is transmitted to the master ECU <NUM> (S504).

In the same manner, when it is determined that the second slave ECU 210B is started (YES in S500), as illustrated in (C-<NUM>) of <FIG>, the third execution item number is transmitted to the master ECU <NUM> (S502), and, as illustrated in (C-<NUM>) of <FIG>, the VMC state confirmation (<NUM>) is transmitted to the master ECU <NUM> (S504).

When the master ECU <NUM> determines that the initial check is unimplemented (YES in S100), it is determined whether all the execution item numbers have been received (S300). When the first execution item number is acquired, the second execution item number is received from the first slave ECU 210A, and the third execution item number is received from the second slave ECU 210B, it is determined that all the execution item numbers have been received (YES in S300), and, as illustrated in (D-<NUM>) of <FIG>, the VMC is executed (S302). When the VMC is executed and it is determined that the first execution item number, the second execution item number, and the third execution item number are consistent (YES in S306), the completion notification at the time of the master start is transmitted to each of the first slave ECU 210A and the second slave ECU 210B (S308). Thereafter, the flag indicating whether the initial check has been implemented is set to the ON state (S112), and the autonomous driving is permitted (S114).

Upon receiving the completion notification at the time of the master start (YES in S506), the first slave ECU 210A stops the transmission of the VMC state confirmation (<NUM>) (S508). Further, upon receiving the completion notification at the time of the master start (YES in S506), the second slave ECU 210B stops the transmission of the VMC state confirmation (<NUM>) (S508).

For example, as illustrated in (E) of <FIG>, the first slave ECU 210A is reset due to some trouble. As such, in the case where the first slave ECU 210A is restarted, when it is determined that it is the time of the start (YES in S500), as illustrated in (F-<NUM>) of <FIG>, the second execution item number is transmitted to the master ECU <NUM> (S502). Then, as illustrated in (F-<NUM>) of <FIG>, the VMC state confirmation (<NUM>) is transmitted to the master ECU <NUM> (S504).

Upon determining that the initial check has been implemented (YES in S150), the master ECU <NUM> receives the VMC state confirmation (<NUM>) from the first slave ECU 210A. Then, when the VMC state confirmation (<NUM>) has not been received (NO in S402), as illustrated in (I) of <FIG>, the VMC possibility (<NUM>) is transmitted to the first slave ECU 210A (S406).

When the first slave ECU 210A receives the VMC possibility (<NUM>) (YES in S510) without receiving the completion notification at the time of the master start (NO in S506), as illustrated in (J) of <FIG>, the VMC request (<NUM>) is transmitted to the master ECU <NUM> (S512).

When the master ECU <NUM> receives the VMC request (<NUM>) (YES in S408), as illustrated in (K) of <FIG>, the VMC is executed (S410). When the VMC is executed, it is determined whether the first execution item number, the second execution item number, and the third execution item number are consistent.

For example, as illustrated in (G) of <FIG>, during the execution of the VMC, in a case where the second slave ECU 210B is reset due to some trouble and is restarted, when it is determined that it is the time of the start (YES in S500), as illustrated in (H-<NUM>) of <FIG>, the third execution item number is transmitted to the master ECU <NUM> (S502), and, as illustrated in (H-<NUM>) of <FIG>, the VMC state confirmation (<NUM>) is transmitted to the master ECU <NUM> (S504).

When the master ECU <NUM> determines that the first execution item number, the second execution item number, and the third execution item number are consistent (YES in S414), as illustrated in (L-<NUM>) of <FIG>, the completion notification is transmitted to the first slave ECU 210A, and, as illustrated in (L-<NUM>) of <FIG>, the completion notification is transmitted to the second slave ECU 210B (S416). Then, the transmission of the VMC possibility (<NUM>) is maintained in the permitted state (S418), and the autonomous driving is permitted (S <NUM>).

Upon receiving the completion notification (YES in S514), the first slave ECU 210A stops the transmission of the VMC state confirmation (<NUM>) and the VMC request (<NUM>) (S508).

On the other hand, since the transmission of the VMC state confirmation (<NUM>) from the second slave ECU 210B to the master ECU <NUM> is continued, it is determined that the VMC state confirmation (<NUM>) has been received (YES in S400), and when the VMC state confirmation (<NUM>) has not been received (NO in S402), as illustrated in (M) of <FIG>, the VMC possibility (<NUM>) is transmitted to the second slave ECU 210B (S406).

When the second slave ECU 210B receives the VMC possibility (<NUM>) (YES in S510) without receiving the completion notification at the time of the master start (NO in S506), as illustrated in (N) of <FIG>, the VMC request (<NUM>) is transmitted to the master ECU <NUM> (S512).

When the master ECU <NUM> receives the VMC request (<NUM>) (YES in S408), as illustrated in (O) of <FIG>, the VMC is executed (S410). When the VMC is executed, it is determined whether the first execution item number, the second execution item number, and the third execution item number are consistent.

When the master ECU <NUM> determines that the first execution item number, the second execution item number, and the third execution item number are consistent (YES in S414), as illustrated in (P-<NUM>) of <FIG>, the completion notification is transmitted to the first slave ECU 210A, and, as illustrated in (P-<NUM>) of <FIG>, the completion notification is transmitted to the second slave ECU 210B (S416). Then, the transmission of the VMC possibility (<NUM>) is maintained in the permitted state (S418), and the autonomous driving is permitted (S <NUM>).

When the second slave ECU 210B receives the completion notification (YES in S514), the transmission of the VMC state confirmation (<NUM>) and the VMC request (<NUM>) is stopped (S508).

In this manner, in the first slave ECU 210A the second execution item number and the VMC state confirmation (<NUM>) are transmitted each time of the start, and the VMC request (<NUM>) is transmitted when the VMC can be executed. Further, in the second slave ECU 210B, the third execution product number and the VMC state confirmation (<NUM>) are transmitted each time of the start, and the VMC request (<NUM>) is transmitted when the VMC can be executed.

Further, in the case where the initial check is unimplemented, the VMC is executed when the master ECU <NUM> receives the second execution production number and the third execution production number. Further, in the case where the initial check has been implemented, the VMC is executed when the master ECU <NUM> receives the VMC request (<NUM>) after the transmission/reception of the VMC state confirmation (<NUM>) and the VMC possibility (<NUM>). Alternatively, in the case where the initial check has been implemented, the VMC is executed when the master ECU <NUM> receives the VMC request (<NUM>) after the transmission/reception of the VMC state confirmation (<NUM>) and the VMC possibility (<NUM>).

For this reason, for example, when the updated software is stored in the update storage areas of the master ECU <NUM>, the first slave ECU 210A, and the second slave ECU 210B and the update storage areas are set as the start storage areas at the time of the next start, before the electrified vehicle <NUM> becomes IG-OFF, even when at least one of the first slave ECU 210A and the second slave ECU 210B is restarted due to an occurrence of some trouble and is started using the updated software, the VMC is promptly executed by the VMC request from the first slave ECU 210A or the second slave ECU 210B. When it is determined that the first execution item number, the second execution item number, and the third execution item number are not consistent by executing the VMC (NO in S414), the autonomous driving becomes the unpermitted state or the like (S <NUM>), and the execution of the function using the updated software only in the first slave ECU 210A or the second slave ECU 210B is restricted.

As above, with the in-vehicle system according to this modified example, even when two or more slave ECUs are included, it is possible to early detect inconsistency in the combination of the identification information of the software in the control devices.

When the initial check has been implemented (YES in S <NUM>), it is assumed that both the first slave ECU 210A and the second slave ECU 210B are restarted at different timings due to the occurrence of some trouble in any one of them, and the VMC state confirmation (<NUM>) has been received immediately after the reception of the VMC state confirmation (<NUM>). In this case, until the next completion notification is transmitted, since the transmission of the VMC possibility (<NUM>) is not permitted, the transmission of the VMC possibility (<NUM>) in response to the reception of the VMC state confirmation (<NUM>) is restricted. In this manner, it is possible to restrict the execution of the VMC from being requested from both the first slave ECU 210A and the second slave ECU 210B in parallel.

In this modified example, it is described that, in a case where the completion notification of the VMC for the VMC request (<NUM>) is received from the first slave ECU 210A, when the transmission of the VMC state confirmation (<NUM>) from the second slave ECU 210B is continued, the VMC is executed by the transmission/reception of the VMC possibility (<NUM>) and the VMC request (<NUM>) from the master ECU <NUM>. However, for example, the possibility of the execution of the VMC may be determined using the content (for example, the content indicating that the execution item number is consistent, or not consistent) of notification of the completion notification. For example, when the content of notification of the completion notification indicates that the execution item numbers are consistent, it is determined that the VMC is not executed redundantly, or when the content of notification of the completion notification indicates that the execution item numbers are not consistent, it is determined that the VMC is executed again. In this manner, it is possible to restrict the VMC from being unnecessarily executed.

Further, in this modified example, an example is described that, in the case where the initial check has been implemented, when the VMC is executed in response to the VMC request from one of the first slave ECU 210A and the second slave ECU 210B and the VMC is executed in response to the VMC request from the other thereof. However, when the VMC is executed in response to the VMC request from one thereof, the VMC does not have to be executed even when the VMC request is received from the other thereof. In this manner, it is possible to restrict the VMC from being unnecessarily executed.

Further, in this modified example, an example is described that, in the case where the initial check has been implemented, when the VMC is executed in response to the VMC request from one of the first slave ECU 210A and the second slave ECU 210B and the VMC is executed in response to the VMC request from the other thereof after the reception of the completion notification. However, when the completion notification has not been received for a certain period, the VMC may be executed in response to the VMC request from the other thereof.

All or part of the modified example described above may be combined as appropriate and implemented.

Claim 1:
An in-vehicle system comprising:
a plurality of control devices including a master control device (<NUM>) and a slave control device (<NUM>) each of which is configured to:
set, as a start storage area, any one of a plurality of storage areas set as storage areas that store software; and
be started using the software stored in the start storage area,
the master control device (<NUM>) being configured to, when software stored in a storage area different from the start storage area is updated in the slave control device (<NUM>), transmit, to the slave control device (<NUM>), a switching instruction for setting the storage area that stores the updated software as the start storage area,
the in-vehicle system being characterized in that:
the slave control device (<NUM>) is configured to
implement, when receiving the switching instruction, setting of the start storage area at a time of a next start, and
request, at every start, the master control device (<NUM>) to execute a consistency determination processing for determining whether pieces of identification information of the software stored in the start storage area are consistent between the control devices, and
the master control device (<NUM>) is configured to, when receiving the request for execution of the consistency determination processing from the slave control device (<NUM>), execute the consistency determination processing.