In-vehicle network system and method for managing in-vehicle network system

Abstract

To prevent an inappropriate change of an activation condition of a control device with respect to an important function of a vehicle while flexibly coping with addition or change of the activation condition of the control device.SOLUTION: The plurality of lower ECUs 11 to 16 have cluster information to which they belong. When the cluster included in the startup cluster information included in the received NM message matches the cluster of the lower ECU, the lower ECU enters the startup state or maintains the startup state. The cluster information of the lower ECU is rewritable. However, when the rewriting of the cluster information is requested, the upper ECU10 determines that the rewriting request within the rewritable range of the cluster information determined according to the attribute of the rewriting request source is a proper rewriting request. Then, the host ECU rewrites the cluster information in accordance with the rewrite request determined to be appropriate.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to an in-vehicle network system in a vehicle that has a plurality of control devices connected to a communication bus and capable of communicating with each other, and a management method for the in-vehicle network system. [Background technology]

[0002] For example, Patent Document 1 discloses an in-vehicle network system including a host ECU, an intermediate ECU, and a subordinate ECU. In the in-vehicle network system of Patent Document 1, the intermediate ECU is supplied with power from a power supply, and supplies power from the power supply to the subordinate ECU in response to a message received from the host ECU. In other words, the intermediate ECU maintains the subordinate ECU in a power-off state until it receives a message from the host ECU. In response to the intermediate ECU receiving a message from the host ECU, power is supplied from the power supply to the subordinate ECU. This power supply causes the subordinate ECU to transition from the power-off state to a standby state in which it waits for an instruction. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7238650 Summary of the Invention [Problem to be solved by the invention]

[0004] Like the relationship between the intermediate ECU and the subordinate ECU described in Patent Document 1, in conventional in-vehicle network systems, a specific ECU (e.g., an intermediate ECU) is configured to manage the states of other ECUs (e.g., subordinate ECUs).

[0005] In recent years, after a vehicle is sold and distributed in the market, it has become possible for the vehicle user to update the software of the ECU (controller) installed in the vehicle by downloading an application of their choice. In this case, depending on the function of the downloaded application, the ECU with updated software may be required to start up when a different condition is met in addition to, or instead of, starting up when the condition set before the update is met.

[0006] However, in the in-vehicle network system described in Patent Document 1, the relationship between other ECUs and the specific ECU that manages the states of the other ECUs is fixed, making it extremely difficult to flexibly respond to changes in the ECU activation conditions. On the other hand, if changes to the ECU activation conditions are allowed without limit, there is a risk that if an inappropriate change is made to an important vehicle function, the ECU will not be able to start up when it should, and the vehicle will not be able to perform the necessary functions.

[0007] The present disclosure has been made in consideration of the above points, and aims to provide an in-vehicle network system and a management method for an in-vehicle network system that are capable of flexibly responding to additions and changes to the activation conditions of the control device while preventing inappropriate changes to the activation conditions of the control device with respect to important vehicle functions. [Means for solving the problem]

[0008] In order to achieve the above object, the in-vehicle network system according to the present disclosure is an in-vehicle network system (100) having a plurality of control devices (10 to 16) connected to a communication bus (17 to 19) in a vehicle and capable of communicating with each other, Each of the plurality of control devices has cluster information indicating a cluster to which it belongs among a plurality of divided clusters, and when a network management message transmitted from another control device contains activation cluster information indicating a cluster to be activated that matches a cluster in the cluster information, the control device enters an activated state or maintains an activated state; a determination unit (10a) for determining, when a request for rewriting cluster information is made for at least one of the plurality of control devices, that a rewrite request within a rewritable range of the cluster information, which is determined according to an attribute of a source of the rewrite request, is an appropriate rewrite request; and a rewriting section (10b) that executes rewriting of the cluster information in accordance with the appropriate rewriting request determined by the determining section.

[0009] Further, a management method for an in-vehicle network system according to the present disclosure is a management method for an in-vehicle network system (100) having a plurality of control devices (10 to 16) connected to a communication bus (17 to 19) in a vehicle and capable of communicating with each other, Each of the plurality of control devices has cluster information indicating a cluster to which it belongs among a plurality of divided clusters, and when a network management message transmitted from another control device contains activation cluster information indicating a cluster to be activated that matches a cluster in the cluster information, the control device enters an activated state or maintains an activated state; When a request to rewrite cluster information is made for at least one of the plurality of control devices, a rewrite request within a rewritable range of the cluster information, which is determined according to the attributes of the rewrite request source, is determined to be an appropriate rewrite request (S110 to S140); and rewriting the cluster information in accordance with the determined appropriate rewrite request (S180).

[0010] In the in-vehicle network system and the management method for the in-vehicle network system according to the present disclosure, each of the plurality of control devices has cluster information indicating the cluster to which it belongs among a plurality of divided clusters, and each of the plurality of control devices is configured to enter or maintain an activated state when a network management message transmitted from another control device contains activation cluster information indicating a cluster to be activated that matches a cluster in the cluster information.

[0011] According to the in-vehicle network system and the in-vehicle network system management method of the present disclosure, the cluster information of each of the plurality of control devices is configured to be rewritable, so that each of the plurality of control devices can flexibly respond to additions and changes to activation conditions.

[0012] Furthermore, according to the in-vehicle network system and the management method for the in-vehicle network system disclosed herein, when a request to rewrite cluster information is made, a rewrite request within the rewritable range of cluster information, determined according to the attributes of the source of the rewrite request, is determined to be an appropriate rewrite request. The cluster information is rewritten in accordance with the rewrite request determined to be appropriate. In this way, the in-vehicle network system and the management method for the in-vehicle network system disclosed herein only rewrites cluster information within the rewritable range of cluster information, determined according to the attributes of the source of the rewrite request. This makes it possible to minimize changes to cluster information that could lead to the addition or modification of inappropriate activation conditions for a control device with respect to important vehicle functions.

[0013] The reference numbers in parentheses above merely indicate an example of a correspondence with specific configurations in the embodiments described below, in order to facilitate understanding of the present disclosure, and are not intended to limit the scope of the present disclosure in any way.

[0014] Furthermore, the technical features of the present disclosure other than those described above will become apparent from the following description of the embodiments and the accompanying drawings. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a configuration diagram showing an example of the configuration of an in-vehicle network system according to an embodiment; [Figure 2] FIG. 1 is an explanatory diagram illustrating an example of a method for realizing partial networking, in which some lower-level ECUs are activated and other lower-level ECUs are put into a sleep state, based on an NM message generated by a higher-level ECU, PNC setting information possessed by each lower-level ECU, and the NM message and PNC setting information. [Figure 3] 10 is a flowchart showing a process for adding or changing a start condition of a lower-level ECU in an in-vehicle network system. [Figure 4] 10 is a diagram showing an example of the range of change of PNC setting information according to the attribute of the source of the change request for PNC setting information. FIG. [Figure 5] FIG. 10 is a diagram showing an example of PNC setting information before change that is set in one of the lower ECUs. [Figure 6] 6 is a diagram showing an example of PNC setting information included in a PNC change request for one of the lower-level ECUs having the PNC setting information shown in FIG. 5. FIG. [Figure 7] 7 is a diagram showing changed PNC setting information that has been changed based on the pre-change PNC setting information of FIG. 5 and the change request PNC setting information of FIG. 6. FIG. [Figure 8] 10 is a flowchart illustrating an example of a process for changing the changeable range of PNC setting information. DETAILED DESCRIPTION OF THE INVENTION

[0016] Hereinafter, embodiments of an in-vehicle network system and an in-vehicle network system management method according to the present disclosure will be described with reference to the drawings. However, the present disclosure is not limited to the following embodiments, and various modifications described below are also included within the technical scope of the present disclosure. Furthermore, in addition to the following, various modifications can be implemented without departing from the spirit of the present disclosure. The embodiments and various modifications can be implemented in appropriate combinations as long as no technical contradiction occurs. In the following description, identical or similar components may be assigned the same reference numerals across multiple drawings, and their description may be omitted. Furthermore, when only a portion of a component is mentioned, the description provided elsewhere may apply to the other components.

[0017] (First embodiment) FIG. 1 is a configuration diagram showing an example of the configuration of an in-vehicle network system 100 according to this embodiment. As shown in FIG. 1, the in-vehicle network system 100 includes a host ECU 10 and subordinate ECUs 11 to 16. ECU is an abbreviation for Electronic Control Unit (electronic control unit). The host ECU 10 may function as, for example, a domain controller that oversees the control of the subordinate ECUs 11 to 16. A domain refers to a functional unit when the vehicle functions are broadly categorized, such as a powertrain domain, a chassis domain, an advanced driver assistance domain, a body domain, and a cockpit domain. For example, when the host ECU 10 is the controller of the powertrain domain, the subordinate ECUs include various ECUs for controlling the vehicle's powertrain, such as an engine ECU, a motor (inverter) ECU, a battery monitoring ECU, and a transmission ECU. When the host ECU 10 is the controller of the chassis domain, the subordinate ECUs include various ECUs for controlling the vehicle's chassis, such as a steering ECU, a brake ECU, and a suspension ECU.

[0018] The above is an example of how the domains are divided, and the division of the domains may be different from the above example. Furthermore, the host ECU 10 may be an area controller that oversees the control of the subordinate ECUs 11-16 arranged in each area of ​​the vehicle. Furthermore, while FIG. 1 shows an example in which the in-vehicle network system 100 includes one host ECU 10, the in-vehicle network system 100 may be configured to include multiple host ECUs that are communicatively connected to each other. In this case, the respective host ECUs may be communicatively connected to each other, for example, via a gateway ECU.

[0019] The in-vehicle network system 100 can use CAN (registered trademark, the same applies hereinafter) as a communication protocol. CAN is an abbreviation for Controller Area Network. Note that the communication protocol is not limited to CAN, and the in-vehicle network system 100 may adopt another communication protocol such as CAN-FD (CAN with Flexible Data Rate). However, in this embodiment, the in-vehicle network system 100 is configured to be able to implement so-called network management, in which the subordinate ECUs 11 to 16 are switched between a normal operation mode (activated state) and a power-saving mode (sleep state) for each group (this group is referred to as a cluster) including at least one subordinate ECU 11 to 16. Therefore, the communication protocol adopted by the in-vehicle network system 100 needs to be compatible with network management.

[0020] 1, a first communication bus 17, a second communication bus 18, and a third communication bus 19 are connected to the upper ECU 10. Thus, although an example in which three communication buses 17 to 19 are connected to the upper ECU 10 is shown in FIG. 1, the number of communication buses connected to the upper ECU 10 may be two or less, or may be four or more.

[0021] 1, a first communication bus 17 is connected to a subordinate ECU 11 and a subordinate ECU 12. A second communication bus 18 is connected to a subordinate ECU 13 and a subordinate ECU 14. A third communication bus 19 is connected to a subordinate ECU 15 and a subordinate ECU 16. The number of subordinate ECUs 11 to 16 connected to each of the communication buses 17 to 19 may be one, or may be three or more.

[0022] Each of the subordinate ECUs 11-16 is, for example, a control ECU for controlling a predetermined control object in a vehicle, or a sensor ECU for calculating a predetermined physical quantity based on a detection signal detected by a sensor. When it is necessary to control a control object or to calculate a predetermined physical quantity based on a detection signal from a sensor, each of the subordinate ECUs 11-16 is activated in a normal operation mode and performs normal operation. On the other hand, when there is no need for such control, each of the subordinate ECUs 11-16 is in a sleep state in a power saving mode.

[0023] To switch between such an active state and a sleep state, each of the lower ECUs 11 to 16 has cluster information (also referred to as PNC setting information) that indicates the cluster to which it belongs among a plurality of divided clusters. The PNC setting information is information for grouping a plurality of lower ECUs 11 to 16 that need to be in an active state simultaneously when realizing at least one desired function in the vehicle. The PNC setting information will be described in detail later. PNC is an abbreviation for Partial Networking Clustering.

[0024] The upper ECU 10, for example, functions as a domain controller and controls the lower ECUs 11 to 16. The upper ECU 10 may also have a function for controlling switching between an active state and a sleep state of the lower ECUs 11 to 16. Specifically, the upper ECU 10 determines a function to be executed in the vehicle, and when execution of the desired function is required, switches the lower ECUs 11 to 16 that must be simultaneously activated to the active state when the desired function is executed to the active state. This switching to the active state can be performed by the upper ECU 10 generating a network management message (hereinafter, NM message) including activation cluster information (also referred to as PN request information) that specifies a cluster indicating a group of the lower ECUs 11 to 16 that must be simultaneously activated as an activation cluster, and transmitting the message via each of the communication buses 17 to 19. The function for determining a function to be executed in the vehicle and transmitting the NM message including the PN request information may be provided by any of the lower ECUs 11 to 16, rather than the upper ECU 10. Furthermore, if a vehicle is provided with a plurality of upper ECUs and a plurality of lower ECUs subordinate to each upper ECU, an NM message may be transmitted from another upper ECU or lower ECU.

[0025] Furthermore, the host ECU 10 executes a process for relaying messages between the respective subordinate ECUs 11 to 16 connected to the respective communication buses 17 to 19. While each of the subordinate ECUs 11 to 16 is in an activated state and performing normal operation, it transmits messages for cooperative control with the other subordinate ECUs 11 to 16, etc., and transmits an NM message indicating that it is in an activated state. These messages can be relayed via the host ECU 10 to the subordinate ECUs 11 to 16, etc., connected to the other communication buses 17 to 19. The host ECU 10 may also enter a sleep state when all of the subordinate ECUs 11 to 16 belonging to all clusters enter a sleep state.

[0026] Any of the ECUs belonging to the in-vehicle network system 100 has an exterior communication device 20 capable of wirelessly communicating with an external server such as a data center 30. FIG. 1 shows an example in which the exterior communication device 20 is connected to the host ECU 10. However, the exterior communication device 20 may be connected to an ECU other than the host ECU 10, or may be mounted on any of the ECUs. For example, the host ECU 10 can download, from the data center 30 via the exterior communication device 20, applications for realizing new functions in the vehicle, update programs for upgrading programs already installed in at least one of the subordinate ECUs 11 to 16, and the like. These applications and update programs may be provided by the vehicle manufacturer (hereinafter also referred to as OEM) or a third party.

[0027] Furthermore, any of the ECUs belonging to the in-vehicle network system 100 may have a data link coupler 21 to which a data device (not shown) is connected. FIG. 1 shows an example in which the data link coupler 21 is connected to the host ECU 10. However, the data link coupler 21 may be connected to an ECU other than the host ECU 10, or may be mounted on any of the ECUs. The data device, like the data center 30, may be capable of providing applications for realizing new functions, update programs for upgrading installed programs, and the like.

[0028] The upper ECU 10 and the lower ECUs 11 to 16 may be configured by a computer including a processor, a memory, a storage, and the like. The processor may be, for example, a central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), or a data flow processor (DFP) that executes predetermined processing according to a program. The memory is a volatile storage medium, such as a random access memory (RAM), that temporarily stores the results of calculations performed by the processor. The storage includes non-volatile storage media such as a flash memory or a read-only memory (ROM). The storage stores various programs and data executed by the processor. Some or all of the functions of the upper ECU 10 may be implemented by hardware using, for example, an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). FIG. 1 shows a determination unit 10a and a rewriting unit 10b, which are functional units that may be implemented in the upper ECU 10 by software and / or hardware. The determination unit 10a and the rewriting unit 10b will be described in detail later.

[0029] The upper ECU 10 and the lower ECUs 11-16 also include a communication interface (communication IF) for communicating with other ECUs. For example, when the communication IF receives an NM message while the lower ECUs 11-16 are in a sleep state, the communication IF has a function of temporarily switching the lower ECUs 11-16 from the sleep state to an active state in response to the reception of the NM message. When switched to the active state by the communication IF, each of the lower ECUs 11-16 determines whether its own activation is requested based on the PN request information and PNC setting information in the NM message. If it determines that its own activation is requested, the lower ECUs 11-16 continue to be in the active state. On the other hand, if it determines that its own activation is not requested, the lower ECUs 11-16 return to the sleep state. The determination based on the PN request information and PNC setting information in the NM message may be configured to be performed by the communication IF. In this case, if the communication IF determines that activation is requested based on the PN request information and PNC setting information, it transitions the corresponding ECU from the sleep state to the active state.

[0030] Next, referring to Figure 2, we will explain an example of a method for realizing partial networking, in which some of the lower-level ECUs 11 to 16 are activated and other lower-level ECUs 11 to 16 are put into a sleep state based on an NM message generated by the upper-level ECU 10, etc., the PNC setting information possessed by each of the lower-level ECUs 11 to 16, and the NM message and the PNC setting information.

[0031] The NM message includes data in bytes 0 to 7, as shown in FIG. 2, for example. Byte 0 includes a node ID (NID). The node ID is an identifier unique to each of the upper ECU 10 and the lower ECUs 11 to 16. The node ID allows the sender of the NM message to be identified. Byte 1 includes a control bit vector (CBV). The control bit vector is data indicating whether partial networking is used or not. If the control bit vector indicates the use of partial networking, the user data area of ​​bytes 2 to 7 includes PN request information, which is activation cluster information indicating the cluster to be activated.

[0032] In the example shown in Figure 2, the control bit vector indicates the use of partial networking, and PN request information is stored in bytes 6 and 7 of the user data area. The user data area from bytes 2 to 5 can be used to transmit any information, such as the wake-up trigger or information on normality or abnormality. Also, Figure 2 shows only one example of the format of the NM message, and the NM message may have other formats as long as it includes information on whether partial networking is used and PN request information.

[0033] The PN request information indicates, for each of a plurality of divided clusters, clusters that should be activated and clusters that do not need to be activated. More specifically, in the example shown in FIG. 2, the clusters are divided into 16 in advance. The PN request information includes 16 bits of data corresponding to the 16 divided clusters. That is, the 16 bits of data in the PN request information are associated with the 16 divided clusters in advance. When each of the 16 bits of data in the PN request information is "0", it indicates that the activation of the associated cluster is not necessary. On the other hand, when each of the 16 bits of data in the PN request information is "1", it indicates that the activation of the associated cluster is necessary.

[0034] As described above, each of the lower-level ECUs 11 to 16 has PNC setting information that indicates the cluster to which it belongs among the plurality of divided clusters. An example of this PNC setting information is shown in Fig. 2. That is, Fig. 2 shows the PNC setting information held by any one of the lower-level ECUs 11 to 16. In the PNC setting information shown in Fig. 2, if the associated clusters are classified as A to P from left to right in the figure, the PNC setting information in Fig. 2 indicates that the ECU having this PNC setting information belongs to clusters D, H, and J. Each of the lower-level ECUs 11 to 16 can perform various functions by executing a program, and therefore can belong to one or more clusters.

[0035] When each of the subordinate ECUs 11 to 16 receives an NM message including PN request information via the communication IF, it compares the PN request information with the PNC setting information bit by bit, as shown in FIG. 2, and calculates, for example, a logical product. That is, when each of the subordinate ECUs 11 to 16 receives an NM message via the communication IF, it temporarily enters an activated state. Then, each of the subordinate ECUs 11 to 16 determines whether the cluster whose activation is requested by the PN request information included in the NM message transmitted from the superior ECU 10 or the like matches the cluster in the PNC setting information. For example, in the example shown in FIG. 2, the clusters whose activation is requested by the PN request information are clusters D, G, I, M, N, and O. The clusters to which the ECUs belong, as indicated by the PNC setting information, are clusters D, H, and J. In this case, in cluster D, the cluster whose activation is requested by the PN request information included in the NM message matches the cluster in the PNC setting information. Therefore, as shown in FIG. 2, the result of the logical product is "1" in cluster D.

[0036] If any bit becomes "1" as a result of the logical AND, the ECU having the PNC setting information shown in FIG. 2 determines that startup of the ECU itself is requested. In response to this determination, the ECU having the PNC setting information shown in FIG. 2 transitions to an active state if its previous state was a sleep state, and maintains the active state if it was an active state. On the other hand, if the result of the logical AND does not result in any bit becoming "1" and all bits are "0", the ECU having the PNC setting information shown in FIG. 2 determines that startup of the ECU itself is not requested. In this case, the ECU having the PNC setting information shown in FIG. 2 discards the received NM message, and if its previous state was a sleep state, it returns to the sleep state.

[0037] In other words, each of the subordinate ECUs 11 to 16 performs filtering based on the PNC setting information to determine whether the NM message requests activation of the respective subordinate ECUs 11 to 16. By filtering based on this PNC setting information, only the ECUs having PNC setting information including the clusters whose activation is requested by the PN request information are activated in response to receiving the NM message, thereby realizing partial networking.

[0038] 1 shows an example in which the lower ECUs 11 and 13 are grouped into cluster C1, the lower ECUs 12, 14, and 15 are grouped into cluster C2, and the lower ECU 16 is grouped into cluster C3. Therefore, for example, when the upper ECU 10 transmits an NM message including PN request information that specifies cluster C1 as the cluster to be activated, the NM message causes the lower ECUs 11 and 13 to be activated, while the other lower ECUs 12, 14 to 16 remain in a sleep state. As a result, partial networking is realized, in which only the lower ECUs 11 and 13 are activated and the other lower ECUs 12, 14 to 16 are in a sleep state.

[0039] When each of the lower ECUs 11 to 16 enters an activated state and transitions to a normal operation mode, it periodically transmits NM messages to the other ECUs while it is performing its normal operation. After performing the necessary processing, each of the lower ECUs 11 to 16 stops transmitting the periodic NM messages when it no longer needs to perform its normal operation. When the period during which the lower ECUs 11 to 16 do not receive an NM message from another ECU belonging to the same cluster as itself reaches a predetermined standby time, the lower ECUs transition from the normal operation mode to a power-saving mode, switching from the activated state to a sleep state.

[0040] In recent years, after a vehicle is sold and distributed in the market, it has become possible for the vehicle user to update the software of the ECU installed in the vehicle by, for example, downloading an application. In this case, depending on the function of the downloaded application, it is possible that the ECU with updated software may be required to add or change the startup conditions of the ECU. However, if the addition or change of the startup conditions of the ECU is allowed without restriction, there is a risk that the ECU may not start up when it should, and important vehicle functions may not be able to function properly if an inappropriate change is made.

[0041] Therefore, the in-vehicle network system 100 according to this embodiment is configured to be able to flexibly respond to additions and changes to the activation conditions of the subordinate ECUs 11 to 16, while preventing inappropriate changes to the activation conditions of the subordinate ECUs 11 to 16 with respect to important functions. The process for adding or changing the activation conditions of the subordinate ECUs 11 to 16 in the in-vehicle network system 100 will be described below with reference to the flowchart in Fig. 3. Execution of the process shown in the flowchart in Fig. 3 corresponds to execution of the in-vehicle network system management method according to this embodiment.

[0042] The process shown in the flowchart of Fig. 3 may be executed by, for example, the host ECU 10. However, the process shown in the flowchart of Fig. 3 may also be executed outside the vehicle, for example, in the data center 30 or a data device connected to the data link coupler 21. Note that if the process is executed outside the vehicle, there is a concern that the amount of communication required to rewrite the PNC setting information may increase, so it is preferable to execute the process in an ECU provided in the vehicle. For example, if the host ECU 10 is configured to collectively receive requests to rewrite the PNC setting information, the amount of communication required to rewrite the PNC setting information can be reduced.

[0043] 3 may be executed by the host ECU 10, and the remaining processes may be executed by at least one of the subordinate ECUs 11 to 16. For example, the rewriting process of step S180, which will be described later, may be executed by the host ECU 10, and the remaining processes may be executed by at least one of the subordinate ECUs 11 to 16. In the following, an example in which the process shown in the flowchart of FIG. 3 is executed by the host ECU 10 will be described.

[0044] In step S100, the host ECU 10 receives a change request (rewrite request) for the PNC setting information of at least one of the slave ECUs 11 to 16 from the data center 30 or a data device connected to the data link coupler 21. When a vehicle user downloads an application from the data center 30 or a data device connected to the data link coupler 21, the change request for the PNC setting information is transmitted from the data center 30 or the data device to the host ECU 10 together with the application. The change request for the PNC setting information includes at least information indicating the attributes of the requester requesting the change of the PNC setting information, and the changed PNC setting information (change-requested PNC setting information).

[0045] At least one of the lower-level ECUs 11 to 16 that executes a downloaded application may need to add or change activation conditions depending on the function of the application. For example, suppose a vehicle is equipped with a camera that is used for advanced driver assistance functions such as lane keep assist and obstacle detection while the vehicle is in motion. Suppose a vehicle user downloads an application that uses the camera to monitor the area around the vehicle and their home while parking the vehicle. Then, the camera needs to operate not only while the vehicle is in motion but also while the vehicle is parked. In this case, the lower-level ECUs 11 to 16 that control the camera need to be activated while the vehicle is in motion and while the vehicle is parked.

[0046] The activation conditions of the lower ECUs 11 to 16 can be changed by the above-mentioned PNC setting information. Therefore, the data center 30 or the data device transmits, as necessary, to the upper ECU 10 a request to change the PNC setting information already set in at least one of the lower ECUs 11 to 16 that executes the downloaded application.

[0047] In step S110, the host ECU 10 determines, based on the received PNC change request, whether the requester requesting the change of the PNC setting information has the authority to change the PNC setting information. If the host ECU 10 determines that the requester has the authority to change the PNC setting information, the process proceeds to step S120. On the other hand, if the host ECU 10 determines that the requester does not have the authority to change the PNC setting information, the process shown in the flowchart in FIG. 3 ends.

[0048] The PNC change request includes identifier information indicating whether the requester is an OEM or a third party, as information indicating the attributes of the requester requesting a change to the PNC setting information, depending on whether the downloaded application was prepared by the vehicle manufacturer (OEM) or a third party other than the OEM. In the case of a third party, the PNC setting information may include identifier information for identifying whether the third party is an authorized third party certified by the OEM or an unauthorised third party. Furthermore, the PNC change request may include a passcode according to the attributes of each requester, in addition to the identifier information indicating the requester.

[0049] In step S110, if the PNC change request includes identifier information indicating an OEM or a third party, or a passcode corresponding to the OEM or the third party, the host ECU 10 can determine that the requestor has the authority to change the PNC setting information. On the other hand, if the PNC change request does not include identifier information or a passcode, the host ECU 10 can determine that the PNC change request is inappropriate and that the requestor does not have the authority to change the PNC setting information.

[0050] In step S120, the host ECU 10 identifies the range of change of the PNC setting information according to the attributes of each request source based on the identifier information included in the PNC change request. An example of the range of change of the PNC setting information according to the attributes of the request source will be described below with reference to Fig. 4. Note that Fig. 4 shows an example in which the clusters are divided into 12. The 12 divided clusters are classified into clusters A to L from left to right in the figure.

[0051] In the example shown in Fig. 4, if the downloaded application is prepared by the OEM and the request to change the PNC setting information is made by the OEM (or dealer), the OEM (or dealer) has the authority as an administrator to change the PNC setting information for all clusters A to L included in the PNC setting information. The OEM is familiar with the functions executed by each of the subordinate ECUs 11 to 16. For this reason, there is no risk of inappropriate changes to the PNC setting information that would prevent the subordinate ECUs 11 to 16 from starting up when they should in the vehicle.

[0052] In the example shown in FIG. 4 , if the downloaded application is prepared by third party X, an authorized third party, and the requester requesting a change to the PNC setting information is third party X, third party X has the authority to change the PNC setting information within the range of clusters E to L, excluding clusters A to D. In the example shown in FIG. 4 , if the downloaded application is prepared by third party Y, an unauthorised third party, and the requester requesting a change to the PNC setting information is third party Y, third party Y has the authority to change the PNC setting information within the range of clusters I to L, excluding clusters A to H. Authorised and / or unauthorised third parties do not necessarily have intimate knowledge of the functions executed by each of the lower-level ECUs 11 to 16. Therefore, when the requester is an authorized and / or unauthorised third party, the scope of changes to the PNC setting information is limited to a range that does not impair important vehicle functions. This makes it possible to prevent, as much as possible, changes to the PNC setting information that could lead to the addition or modification of inappropriate activation conditions of the lower-level ECUs 11 to 16 for important vehicle functions.

[0053] As explained with reference to Fig. 4, the changeable range of the PNC setting information according to the attributes of the source of the change request for the PNC setting information is predetermined based on the area of ​​a cluster divided into two or more areas. In the example shown in Fig. 4, clusters A to L are divided into three areas (A to D, E to H, and I to L). However, the number of areas dividing a cluster may be two, or may be four or more.

[0054] The attributes of the source of a change request to the PNC configuration information include a higher-level attribute with a broader scope of authority, such as the OEM (or dealer) who is the administrator, and a lower-level attribute such as a third party with a narrower scope of authority than the OEM (or dealer). A part of the range of changes that can be made by the request source corresponding to the higher-level attribute (multiple areas of the cluster) becomes the range of changes that can be made by the request source corresponding to the lower-level attribute (at least one area of ​​the cluster).

[0055] When dividing all clusters into two or more regions, the division may be based on domains, for example. Each cluster is a group of multiple lower-level ECUs 11-16 that must be activated simultaneously to realize at least one desired function in the vehicle. At least one desired function may be set to belong to one of multiple domains that broadly group various vehicle functions. Therefore, each cluster may be classified into one of the domains.

[0056] As described above, the domains may include the powertrain domain and chassis domain related to vehicle driving, as well as the advanced driver assistance domain related to vehicle driving safety. If the PNC setting information related to the clusters belonging to the powertrain domain, chassis domain, or advanced driver assistance domain is erroneously changed, there is a risk that important functions such as vehicle driving and driving safety may be impaired. Therefore, when all clusters are divided into two or more regions, for example, the clusters may be divided into a first region including all clusters and a second region excluding clusters belonging to the powertrain domain, chassis domain, and advanced driver assistance domain.

[0057] Furthermore, when dividing all clusters into two or more regions, the importance of the functions executed by the subordinate ECUs 11-16 grouped in each cluster may be determined for each cluster. For example, the region may be divided into a third region covering all clusters, including specific clusters that execute important functions, and a fourth region that does not include the specific clusters. The specific clusters may be clusters that execute functions related to vehicle operation and driving safety. Furthermore, if the vehicle is compatible with a so-called smart key or digital key, the specific clusters may be clusters to which the key verification ECU or digital key ECU belongs. This is because the key verification ECU and digital key ECU can be activated at the appropriate time to ensure user convenience and vehicle security.

[0058] Furthermore, when dividing all clusters into two or more regions, the regions may be divided based on the amount of power consumption by the subordinate ECUs 11 to 16 belonging to each cluster, so as to have a fifth region that covers all clusters including clusters to which subordinate ECUs 11 to 16 with relatively high current consumption belong, and a sixth region that does not include clusters to which subordinate ECUs 11 to 16 with relatively high current consumption belong. This is because if the activation conditions are changed so that clusters to which subordinate ECUs 11 to 16 with relatively high power consumption belong are activated more frequently, there is a high possibility that a serious situation such as a dead battery will occur in the vehicle.

[0059] The first and second regions based on domains, the third and fourth regions based on clusters, and the fifth and sixth regions based on the current consumption of each of the lower-level ECUs 11 to 16 may be used individually or in any combination.

[0060] Returning to the flowchart of FIG. 3, the description will continue. In step S130, the host ECU 10 compares the bits of the pre-change PNC setting information with the bits of the change request PNC setting information within the changeable range of the PNC setting information according to the attributes of the source of the PNC setting information change request. That is, the host ECU 10 determines that bits within the changeable range of the PNC setting information are appropriate change requests (rewrite requests), and determines that bits outside the changeable range are inappropriate change requests (rewrite requests). The host ECU 10 then compares the bits of the pre-change PNC setting information with the bits of the change request PNC setting information within the changeable range of the PNC setting information that correspond to the change request determined to be appropriate. In other words, bits of the PNC setting information outside the changeable range of the PNC setting information are ignored. As a result, the PNC setting information outside the changeable range of the PNC setting information is discarded.

[0061] For example, Fig. 5 shows an example of pre-change PNC setting information set in one of the lower ECUs 11 to 16. Fig. 6 shows an example of PNC setting information included in a PNC change request for one of the lower ECUs 11 to 16 having the PNC setting information shown in Fig. 5. As shown in Fig. 6, the attribute of the requester of the PNC change request is third party Y, which is an uncertified third party.

[0062] 6, the range of PNC setting information changes permitted to unauthorized third parties is the range of clusters I to L. Therefore, in step S130, the pre-change PNC setting information and the change request PNC setting information are compared for bits associated with clusters I to L, which are bits of PNC setting information within the changeable range. The bits associated with clusters A to H of the PNC setting information are ignored because they are outside the changeable range.

[0063] For example, in the change request PNC setting information shown in Fig. 6, the bits associated with clusters C and F indicated by hatching and the bits associated with cluster J indicated by dots are different from the bits in the pre-change PNC setting information. Cluster J belongs to the changeable range. Therefore, as shown in Fig. 7, in the changed (rewritten) PNC setting information, the bits associated with cluster J have been rewritten by the change request PNC setting information. On the other hand, the bits associated with clusters C and F in the change request PNC setting information are outside the changeable range and are therefore ignored. As a result, in the changed PNC setting information, the bits associated with clusters C and F remain the same as the bits in the pre-change PNC setting information.

[0064] In the above example, if the change request PNC setting information includes not only PNC setting information within the changeable range of the PNC setting information but also PNC setting information outside the changeable range, the pre-change PNC setting information is changed based on the PNC setting information within the changeable range and the PNC setting information outside the changeable range is discarded. However, if the change request PNC setting information includes PNC setting information outside the changeable range, the change request for PNC setting information including such change request PNC setting information may be deemed invalid, and the change request PNC setting information may be discarded without any change to the PNC setting information. In other words, the PNC setting information may be changed only if the change request for PNC setting information includes only PNC setting information within the changeable range of the PNC setting information.

[0065] In step S140, the host ECU 10 determines whether there is a difference between the bits of the pre-change PNC setting information and the bits of the change request PNC setting information within the changeable range of the PNC setting information. If there is a difference, the host ECU 10 proceeds to step S150. On the other hand, if there is no difference, the host ECU 10 ends the process shown in the flowchart of FIG. 3.

[0066] The above-described processing from step S110 to step S140 corresponds to the processing executed by the determination unit 10a built in the host ECU 10.

[0067] In step S150, the host ECU 10 determines whether the attribute of the source of the change request for the PNC setting information is an OEM (or a dealer) having administrator authority. If it is determined that the attribute of the source of the change request is an OEM (or a dealer) having administrator authority, the host ECU 10 proceeds to processing in step S180. On the other hand, if it is determined that the attribute of the source of the change request is a third party without administrator authority, the host ECU 10 proceeds to processing in step S160.

[0068] In step S160, the host ECU 10 requests approval for the change of the PNC setting information from a vehicle user (owner) who has administrator authority, because the attribute of the source of the change request for the PNC setting information does not have administrator authority. In step S170, the host ECU 10 determines whether the change of the PNC setting information has been approved by the vehicle user. This approval can be achieved, for example, by the vehicle user entering an authentication code indicating that the vehicle user is an administrator on a screen of the vehicle's infotainment system and performing an operation indicating approval (such as a touch panel operation or a voice operation). Alternatively, approval can be achieved by using a mobile terminal owned by the vehicle user to perform short-range wireless communication with the host ECU 10, transmitting an ID indicating that the vehicle user is a vehicle user, and performing an operation indicating approval. If it is determined that the vehicle user has approved, the host ECU 10 proceeds to the process of step S180. On the other hand, if it is determined that the vehicle user has not approved, the host ECU 10 ends the process shown in the flowchart of FIG. 3.

[0069] In step S180, the host ECU 10 rewrites the bits of the pre-change PNC setting information, within the changeable range of the PNC setting information according to the attributes of the source of the PNC setting information change request, with respect to the bits of the change-request PNC setting information that differ from the bits of the pre-change PNC setting information. The process of step S180 corresponds to the process executed by the rewriting unit 10b built in the host ECU 10.

[0070] As described above, according to the in-vehicle network system and the in-vehicle network system management method of this embodiment, the PNC setting information is changed (rewritten) only within the range of change allowed for the PNC setting information, which is determined according to the attributes of the rewrite request source. Therefore, it is possible to prevent as much as possible changes to the PNC setting information that may lead to the addition or change of inappropriate activation conditions of the lower ECUs 11 to 16 for important vehicle functions.

[0071] (Variation) The above describes preferred embodiments of the present disclosure, but the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms within the scope of the gist of the present disclosure.

[0072] For example, the changeable range of the PNC setting information, which is determined according to the attributes of the source of the change request for the PNC setting information, may be configured to be changeable by a person with administrator authority (such as an OEM or dealer, or the vehicle owner.) An example of a process for changing the changeable range of the PNC setting information will be described with reference to the flowchart of FIG.

[0073] In step S200, the host ECU 10 receives a request to change the changeable range of the PNC setting information according to the attributes of the source of the change request for the PNC setting information. In step S210, the host ECU 10 determines whether the change request has been made by an entity with administrator authority. For example, whether the entity has administrator authority can be determined based on a passcode or authentication code associated with the administrator. If it is determined that the entity has administrator authority, the host ECU 10 proceeds to step S210. On the other hand, if it is determined that the entity does not have administrator authority, the host ECU 10 ends the process shown in the flowchart of FIG. 8 without changing the changeable range of the PNC setting information.

[0074] In step S220, the host ECU 10 changes the changeable range of the PNC setting information based on the information indicating the changeable range after the change, which is included in the change request for the changeable range of the PNC setting information.

[0075] Furthermore, it is preferable that the authentication code and ID that identify the user (owner) of the vehicle are changeable, so that appropriate responses can be made when the vehicle owner changes due to a transfer of the vehicle, for example.

[0076] (Disclosure of technical ideas) Finally, this specification discloses several technical ideas described in the following paragraphs. Some paragraphs may be described in a multiple dependent form, alternatively referencing preceding paragraphs. Furthermore, some paragraphs may be described in a multiple dependent form, referencing multiple paragraphs including paragraphs in other multiple dependent forms. These multiple dependent forms and multiple dependent paragraphs define several technical ideas. Furthermore, the technical ideas described in the following paragraphs also apply to a method for managing an in-vehicle network system.

[0077] (Technical thought 1) An in-vehicle network system (100) having a plurality of control devices (10-16) connected to a communication bus (17-19) in a vehicle and capable of communicating with each other, Each of the plurality of control devices has cluster information indicating a cluster to which it belongs among a plurality of divided clusters, and when a network management message transmitted from another of the control devices includes activation cluster information indicating a cluster to be activated that matches a cluster in the cluster information, the control device enters an activated state or maintains an activated state; a determination unit (10a) that, when a request to rewrite the cluster information is made for at least one of the plurality of control devices, determines that a rewrite request within a rewritable range of the cluster information, which is determined according to an attribute of a source of the rewrite request, is an appropriate rewrite request; a rewriting unit (10b) that rewrites the cluster information in accordance with the appropriate rewriting request determined by the determination unit.

[0078] (Technical thought 2) The in-vehicle network system according to Technical Idea 1, wherein the determination unit determines a rewrite request outside the rewritable range of the cluster information as an inappropriate rewrite request and discards it.

[0079] (Technical Thought 3) A multi-partitioned cluster is divided into two or more regions, The range of the rewritable cluster area varies depending on the attribute of the rewrite request source, The in-vehicle network system according to Technical Idea 1 or 2, wherein the rewritable range of the cluster information according to the attributes of the source of the rewrite request is determined based on the area of ​​the cluster divided into two or more parts.

[0080] (Technical Thought 4) an authority determination unit (S210) that, when a request for changing the range of a rewritable cluster area determined according to the attributes of the rewrite request source occurs, determines whether the change request has been made by a person with administrator authority; The in-vehicle network system described in Technical Idea 3 further includes a modification unit (S220) that, when the authority determination unit determines that the change request has been made by a person with administrator authority, modifies the range of the rewritable cluster area, which is determined in accordance with the attributes of the source of the rewrite request, in accordance with the change request.

[0081] (Technical Thought 5) The attributes of the rewrite request source include a higher-level attribute having a broader range of authority and a lower-level attribute having a narrower range of authority than the higher-level attribute, The in-vehicle network system according to Technical Idea 3 or 4, wherein a part of the area where the higher-level attribute is rewritable becomes an area where the lower-level attribute is rewritable.

[0082] (Technical Thought 6) a confirmation unit (S160, S170) for confirming with the owner of the vehicle whether or not the owner approves the rewriting of the cluster information when the attribute of the rewriting request source is the lower attribute; The in-vehicle network system according to Technical Idea 5, wherein when the confirmation unit confirms that the vehicle has been approved by the owner of the vehicle, the rewriting unit executes rewriting of the cluster information.

[0083] (Technical Thought 7) The in-vehicle network system according to Technical Idea 6, wherein the confirmation unit requires authentication indicating that the person is the owner of the vehicle when approved by the owner of the vehicle.

[0084] (Technical Thought 8) the cluster information is information for grouping a plurality of the control devices that need to be activated simultaneously when realizing at least one desired function in the vehicle, the desired function is set to belong to any one of a plurality of domains into which various functions of the vehicle are broadly divided, The in-vehicle network system according to any one of Technical Ideas 3 to 7, wherein two or more regions of the cluster are divided based on the domain.

[0085] (Technical Thought 9) the cluster information is information for grouping a plurality of the control devices that need to be activated simultaneously when realizing at least one desired function in the vehicle, An in-vehicle network system described in any one of technical ideas 3 to 8, wherein two or more areas of a cluster are partitioned to have at least a first area that includes a specific cluster and a second area that does not include the specific cluster.

[0086] (Technical Thought 10) the cluster information is information for grouping a plurality of the control devices that need to be activated simultaneously when realizing at least one desired function in the vehicle, An in-vehicle network system described in any one of technical ideas 3 to 9, wherein two or more areas of the cluster are partitioned to have at least a third area including a cluster to which the control device with a relatively high current consumption belongs, and a fourth area not including a cluster to which the control device with a relatively high current consumption belongs.

[0087] (Technical Thought 11) The in-vehicle network system according to any one of Technical Ideas 1 to 10, wherein the determination unit is implemented in one of the plurality of control devices.

[0088] (Technical Thought 12) The in-vehicle network system according to any one of Technical Ideas 1 to 11, wherein the rewriting unit is implemented in one of the plurality of control devices. [Explanation of symbols]

[0089] 10: Upper ECU, 11 to 16: Lower ECU, 17 to 19: Communication bus, 20: External communication device, 21: Data link coupler, 30: Data center, 100: In-vehicle network system

Claims

1. An in-vehicle network system (100) having a plurality of control devices (10-16) connected to a communication bus (17-19) in a vehicle and capable of communicating with each other, Each of the plurality of control devices has cluster information indicating a cluster to which it belongs among a plurality of divided clusters, and when a network management message transmitted from another of the control devices includes activation cluster information indicating a cluster to be activated that matches a cluster in the cluster information, the control device enters an activated state or maintains an activated state; a determination unit (10a) for determining, when a request to rewrite the cluster information is made for at least one of the plurality of control devices, that a rewrite request within a rewritable range of the cluster information, which is determined according to an attribute of a source of the rewrite request, is an appropriate rewrite request; a rewriting unit (10b) that rewrites the cluster information in accordance with the appropriate rewriting request determined by the determination unit.

2. The in-vehicle network system according to claim 1 , wherein the determination unit determines a rewrite request outside a rewritable range of the cluster information as an inappropriate rewrite request and discards the request.

3. A multi-partitioned cluster is partitioned into two or more regions, The range of the rewritable cluster area varies depending on the attribute of the rewrite request source, 3. The in-vehicle network system according to claim 1, wherein a rewritable range of the cluster information according to the attribute of the rewrite request source is determined based on an area of ​​the cluster divided into two or more.

4. an authority determination unit (S210) that, when a request for changing the range of a rewritable cluster area determined according to the attributes of the rewrite request source occurs, determines whether the change request has been made by a person with administrator authority; The in-vehicle network system of claim 3 further comprises a modification unit (S220) that, when the authority determination unit determines that the change request was made by a person with administrator authority, modifies the range of the rewritable cluster area, which is determined in accordance with the attributes of the source of the rewrite request, in accordance with the change request.

5. The attributes of the rewrite request source include a higher-level attribute having a broader range of authority and a lower-level attribute having a narrower range of authority than the higher-level attribute, 4. The in-vehicle network system according to claim 3, wherein a part of the area where the higher-level attribute is rewritable is an area where the lower-level attribute is rewritable.

6. a confirmation unit (S160, S170) for confirming with the owner of the vehicle whether or not the owner approves the rewriting of the cluster information when the attribute of the rewriting request source is the lower attribute; 6. The in-vehicle network system according to claim 5, wherein when the verification unit verifies that the vehicle has been approved by the owner of the vehicle, the rewriting unit rewrites the cluster information.

7. The in-vehicle network system according to claim 6 , wherein the verification unit requires authentication indicating that the person is the owner of the vehicle when the owner of the vehicle approves the authentication.

8. the cluster information is information for grouping a plurality of the control devices that need to be activated simultaneously when realizing at least one desired function in the vehicle, the desired function is set to belong to any one of a plurality of domains into which various functions of the vehicle are broadly divided, The in-vehicle network system according to claim 3 , wherein two or more regions of the cluster are partitioned based on the domain.

9. the cluster information is information for grouping a plurality of the control devices that need to be activated simultaneously when realizing at least one desired function in the vehicle, The in-vehicle network system according to claim 3 , wherein the two or more regions of the cluster are partitioned to have at least a first region that includes a specific cluster and a second region that does not include the specific cluster.

10. the cluster information is information for grouping a plurality of the control devices that need to be activated simultaneously when realizing at least one desired function in the vehicle, 4. The in-vehicle network system of claim 3, wherein the two or more regions of the cluster are partitioned to have at least a third region including a cluster to which the control device with a relatively high current consumption belongs, and a fourth region not including a cluster to which the control device with a relatively high current consumption belongs.

11. The in-vehicle network system according to claim 1 , wherein the determining unit is implemented in one of the plurality of control devices.

12. The in-vehicle network system according to claim 1 , wherein the rewriting unit is implemented in one of the plurality of control devices.

13. A method for managing an in-vehicle network system (100) in a vehicle, the in-vehicle network system (100) having a plurality of control devices (10-16) connected to a communication bus (17-19) and capable of communicating with each other, comprising: Each of the plurality of control devices has cluster information indicating a cluster to which it belongs among a plurality of divided clusters, and when a network management message transmitted from another of the control devices includes activation cluster information indicating a cluster to be activated that matches a cluster in the cluster information, the control device enters an activated state or maintains an activated state; When a request to rewrite the cluster information is made for at least one of the plurality of control devices, determining that a rewrite request within a rewritable range of the cluster information, which is determined according to the attributes of the rewrite request source, is an appropriate rewrite request (S110 to S140); and and executing rewriting of the cluster information in accordance with the determined appropriate rewrite request (S180).

Images