Vehicle network system, control method of a vehicle network system and manager control device applied to a vehicle network system

Abstract

A vehicle network system mounted on a vehicle is provided, the system comprising a management target control device (14 to 19) and a manager control device (10). The management target control device maintains cluster information specifying a cluster to which the management target control device belongs and enters an active state in response to an activation message containing active cluster information indicating that the cluster corresponding to the cluster specified by the cluster information is active. When cluster setting information for updating is received from an external device, the manager control device stores the updated cluster setting information in a storage medium or a space separate from a storage medium, or a space that stores the cluster setting information.

Description

Technical field The present disclosure relates to a vehicle network system comprising a plurality of mutually communicable control devices, a control method of a vehicle network system, and a manager control device applied to a vehicle network system. For example, JP2024-64428A describes an in-vehicle system that includes an in-vehicle device with a communication I / F that supports the subnetwork function and an in-vehicle device with a communication I / F that does not support the subnetwork function. In the in-vehicle system of JP2024-64428A, the in-vehicle device with the communication I / F that does not support the subnetwork function is configured to operate according to the subnetwork function. Specifically, the operating mode of the in-vehicle device with the communication I / F, which does not support the subnetwork function, includes a normal mode, a low-frequency mode, and a sleep mode. In sleep mode, only one function of the communication I / F, to detect the dominant of a communication signal (frame), is executed, and other functions of the communication I / F are or are stopped. When the communication I / F detects the dominant of the communication signal, the in-vehicle device switches from sleep mode to low-frequency mode. In low-frequency mode, the communication I / F can perform a frame reception process, but a transmission function remains stopped.In low-clock mode, the ECU of the vehicle's internal device operates at a low clock speed and can determine whether a received frame contains identification information that designates this internal device as an activation target. If the received frame contains the identification information, the internal device switches from low-clock mode to normal mode. In the JP2024-64428A's in-vehicle system, in-vehicle devices are classified into multiple clusters based on their function. A frame (a network management message) containing the identification information specifying which cluster should be active is used to activate in-vehicle devices performing a requested function, while the other in-vehicle devices remain in sleep mode. This is how the subnetwork is implemented in the in-vehicle system. In recent years, after a vehicle's release or market launch, it has become possible to update the software of ECUs (Electronic Control Units) installed in the vehicle, for example, by downloading an application. Depending on a function of the downloaded application, the ECU may need to activate, not only when an activation condition configured before the update is met, but also when a different activation condition is met. Alternatively, the ECU may need to activate when a different activation condition is met, instead of one configured before the update. It may be possible to add and modify the activation condition by adding or changing a cluster associated with a specific ECU. Therefore, for example, a vehicle network system can be provided with a manager ECU that can modify cluster information for the ECUs via communication with the ECUs mounted in the vehicle. This can provide flexibility in adding and modifying the activation condition for each or any individual ECU. Hereinafter, the ECU that is a target for adding and / or modifying the activation condition is referred to as a manager target ECU. For example, it may be possible to modify the cluster information of the management target ECU in the following way. First, an external server can prepare cluster setting information for updating, including cluster information specifying the cluster to which each management target ECU belongs, based on a function of the downloaded application or the addition or replacement of the management target ECU. A manager ECU can then download the cluster setting information for updating from the external server. Using the downloaded cluster setting information, the manager ECU updates the cluster information held by each management target ECU. This allows adding or changing a cluster assigned to each management target ECU and, accordingly, enabling the setting of an activation condition for each.to add or modify a respective management target ECU. However, in a configuration where the manager ECU stores the cluster setting information for updating by overwriting the current cluster setting information when the cluster setting information for updating is downloaded, the following difficulty may occur. For example, if download data is interrupted mid-download due to a communication error between the external server and the manager ECU, the current cluster setting information and the updated cluster setting information may coexist. In this case, even if the manager ECU modifies the cluster information of each target management ECU based on the updated cluster setting information, the cluster information of each target management ECU may not necessarily be changed to appropriate cluster information. It is possible that the current cluster setting information is overwritten by the cluster setting information for update while the manager ECU modifies the cluster information of each or a specific management target ECU based on the current cluster setting information. In this case, the cluster information of some of the management target ECUs may differ from the cluster information in the cluster setting information for update. The present disclosure is made in view of the foregoing and has an objective of providing a vehicle network system, a control method of a vehicle network system and a manager control device applied to a vehicle network system in which it is possible for a manager control device to receive cluster setting information for updating from an outside and to adequately store the received cluster information for updating. According to a first aspect, a vehicle network system is provided that is mounted on a vehicle and has a variety of control devices that can communicate with each other.The multitude of control devices includes: a management target control device, which holds cluster information specifying a cluster to which the management target control device belongs, among a multitude of clusters, which are subdivisions, and which enters an active state in response to an activation message from another control device containing active cluster information indicating that the cluster corresponding to the cluster specified by the cluster information is active; and a manager control device, which contains a storage medium that stores cluster setting information for configuring the cluster information of the management target control device and has a function for configuring the cluster information of the management target control device based on the stored cluster setting information.The manager control device is capable of receiving cluster setting update information from an external device. When the cluster setting update information is received, the manager control device stores the updated cluster setting information in a storage medium separate from the storage medium that stores the cluster setting information, or in a storage area separate from a storage area that stores the cluster setting information. According to a second aspect, a control method for a vehicle network system is provided, which is mounted on a vehicle and contains a variety of mutually communicable control devices.The multitude of control devices includes: a management target control device, which holds cluster information specifying a cluster to which the management target control device belongs, among a multitude of clusters, which are subdivisions, and which enters an active state in response to an activation message from another control device containing active cluster information indicating that the cluster corresponding to the cluster specified by the cluster information is active; and a manager control device, which contains a storage medium that stores cluster setting information for configuring the cluster information of the management target control device and has a function for configuring the cluster information of the management target control device based on the stored cluster setting information.The control procedure features: the manager control device receives cluster setting information for updating from an external device; and, when the cluster setting information for updating is received, the manager control device stores the cluster setting information for updating in a storage medium separate from the storage medium that stores the cluster setting information, or in a memory area separate from a memory area that stores the cluster setting information. According to a third aspect, a manager control device is provided that is applied to a vehicle network system mounted on a vehicle and contains a variety of mutually communicable control devices.The multitude of control devices includes: a management target control device, which holds cluster information specifying a cluster to which the management target control device belongs, among a multitude of clusters, which are subdivisions, and which enters an active state in response to an activation message from another control device containing active cluster information indicating that the cluster corresponding to the cluster specified by the cluster information is active; and the manager control device, which contains a storage medium that stores cluster setting information for configuring the cluster information of the management target control device and has a function for configuring the cluster information of the management target control device based on the stored cluster setting information.The manager control device is capable of receiving cluster setting update information from an external device. When the cluster setting update information is received, the manager control device stores the updated cluster setting information in a storage medium separate from the storage medium that stores the cluster setting information, or in a storage area separate from a storage area that stores the cluster setting information. In the vehicle network system, the control method of the vehicle network system, and the manager control device applied to the vehicle network system, as disclosed herein: the plurality of control devices includes the manager control device, which has the function of configuring the cluster information of the manager control device based on the stored cluster setting information. Therefore, it is possible to provide flexibility with regard to adding and / or changing an activation condition of the manager control device. Furthermore, in the vehicle network system, the vehicle network system control method, and the manager control device applied to the vehicle network system, according to the present disclosure, when the cluster setting information for updating is received, the manager control device stores the cluster setting information for updating in a storage medium separate from the storage medium that stores the cluster setting information, or in a memory area separate from a memory area that stores the cluster setting information. Therefore, it is possible to avoid a coexistence of the cluster setting information and the cluster setting information for updating, even if download data is truncated. It is also possible, even when the cluster setting information for updating is received while the cluster information of each...The cluster information of each management target ECU can be changed based on the cluster settings information to configure the cluster information of each management target ECU consistently. Brief description of the characters The above and other tasks, features, and advantages of the present disclosure will become clear from the following detailed description, which is made with reference to the accompanying drawings. Fig. 1 is a diagram representing an exemplary configuration of a vehicle network system. Fig. 2 is a functional block diagram representing the functions of the first through sixth lower-level ECUs with respect to network management. Fig. 3 is a diagram representing an example of an NM message, PN request information, and PNC setting information. Fig. 4 is a flowchart representing an example of a main process routine that can be executed by a higher-level ECU when a cluster manager unit is provided in the higher-level ECU. Fig. 5 is a flowchart representing an example of a PNC setting necessity determination process at S140 of the flowchart in Fig. 4.Figure 6 is a flowchart illustrating an example of a setting status determination process at S350 of the flowchart in Figure 5. Figure 7 is a sequence diagram illustrating an example of the flow of processes at the higher-level ECU and the first six lower-level ECUs when the setting status determination process is executed. Figure 8 is a flowchart illustrating an example of the PNC setting process at S160 of the flowchart in Figure 4. Figure 9 is a sequence diagram illustrating an example of the flow of processes at the higher-level ECU and the first six lower-level ECUs when the PNC setting process is executed. Figure 10 is a flowchart illustrating an example of a PNC setting completion process at S190 of the flowchart in Figure 4. Figure 11 is a diagram illustrating an example of a PNC setting table.Figure 12 is a flowchart showing an example of a table update process in S210 of the flowchart in Figure 4. Figure 13 is a sequence diagram showing an example of the sequence of processes at the higher-level ECU and the first six lower-level ECUs when the table update process is executed. Figure 14 is a flowchart showing an example of the PNC setting table receive process in S920 of the flowchart in Figure 12. Figure 15 is a flowchart showing an example of the PNC setting table update process. Figure 16 is a flowchart showing an example of a main process routine executed by each of the first six lower-level ECUs. Figure 17 is a flowchart showing an example of a (first-time) PNC setting response process in S1410 of the flowchart in Figure 16.Figure 18 is a flowchart illustrating an example of a (second time) PNC hiring response process in S1430 of the flowchart in Figure 16. Figure 19 is a flowchart illustrating an example of a hiring status verification process in S1440 of the flowchart in Figure 16. Figure 20 is a diagram describing a first example of changing the activation condition according to a first modification. Figure 21 is a diagram describing a second example of changing the activation condition according to the first modification. Figure 22 is a flowchart illustrating a hiring status verification process according to a second modification. Figure 23 is a flowchart illustrating a (first time) PNC hiring response process according to the second modification. Description of the exemplary implementations Embodiments of a vehicle network system, a control method for a vehicle network system, and a manager control device applied to a vehicle network system, according to the present disclosure, are described with reference to the drawings. 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. In addition to the following embodiments, various modifications may be made without departing from the spirit and scope of the present disclosure. The embodiments and various modifications may be combined to an extent that does not cause technical inconsistency.In the following description, the same or similar components may be designated by the same or similar reference numerals in the drawings, and descriptions thereof may be omitted. Additionally, in a case where reference is made only to a part of the configuration in an embodiment or modification example, the description in the preceding embodiment may be applied to the remainder of the configuration. First embodiment Fig. 1 shows an exemplary configuration of a vehicle network system 100 according to the present embodiment. As can be seen in Fig. 1, the vehicle network system 100 comprises a higher-level ECU 10, first to third GW-ECUs 11 to 13, and first to sixth lower-level ECUs 14 to 19, which can communicate with each other via a network. ECU is an abbreviation for electronic control unit. GW is an abbreviation for gateway. In the present embodiment, the higher-level ECU 10, the first to third GW-ECUs 11 to 13, and the first to sixth lower-level ECUs 14 to 19 are mounted on a vehicle. Examples of vehicles include a passenger car, a motorcycle, a transport vehicle, a construction vehicle, and an agricultural vehicle. The higher-level ECU 10 can, for example, act as a domain control unit or operating area control unit, overseeing the control of the first six lower-level ECUs (14 to 19). Operating areas refer to functional units when vehicle functions are generally divided into, for example, a powertrain area, a chassis area, an advanced driver assistance area, a body area, a cockpit area, and so on. If the powertrain operating area control unit is, for example, the higher-level ECU 10, the first six lower-level ECUs (14 to 19) contain various ECUs for controlling the vehicle's powertrain, such as an internal combustion engine ECU, a motor or electric motor (or inverter) ECU, a battery monitoring ECU, and a transmission ECU.If the chassis area control unit is the higher-level ECU 10, the first to sixth lower-level ECUs contain 14 to 19 different ECUs for chassis control of the vehicle, such as a steering ECU, a brake ECU, and a suspension ECU. The foregoing is an example of how the operating areas are to be divided, and the operating areas may differ from the example described above. The higher-level ECU 10 may be a central ECU that monitors the controls of the first to sixth lower-level ECUs 14 to 19, which are located in areas of the vehicle. In this case, the first to third GW-ECUs 11 to 13, together with the first to sixth lower-level ECUs 14 to 19, are located in a respective area. Furthermore, although Fig. 1 shows an example of the vehicle network system 100 with a higher-level ECU 10, the vehicle network system 100 may contain multiple higher-level ECUs. In this case, multiple higher-level ECUs may be communicatively interconnected. GW-ECUs and lower-level ECUs may be subordinate units of a respective higher-level ECU. The higher-level ECU 10 contains a cluster manager unit 10a as a manager control device. The cluster manager unit 10a performs management by linking the first through sixth lower-level ECUs 14 through 19, which are all lower-level ECUs connected to the network (corresponding to management target control devices in this disclosure), with their respective cluster information (hereinafter referred to as PNC setting information). More specifically, the cluster manager unit 10a is configured to recognize the link between each of the first through sixth lower-level ECUs 14 through 19 and its PNC setting information by means of a PNC setting table (corresponding to cluster setting information in this disclosure). The PNC setting table is stored in non-volatile memory 10c of the higher-level ECU 10.Because of this, the cluster manager unit 10a can manage, for each of the first six lower-level ECUs 14, which cluster each of the respective lower-level ECUs 14 to 19 belongs to and which cluster each of the lower-level ECUs 14 to 19 does not belong to, based on the PNC setting information associated with the first six lower-level ECUs 14 to 19 in the PNC setting table. The PNC setting information and the PNC setting table are described in detail later. PNC is an abbreviation for Partial Network Clustering. Furthermore, the cluster manager unit 10a of the higher-level ECU 10 has a function to change the PNC setting information of all of the first through sixth lower-level ECUs 14 to 19 connected to the network. Changing the PNC setting information can be described as configuring, setting, reconfiguring, resetting, or updating the PNC setting information.For example, if a need arises to change the PNC setting information of at least one of the first six lower-level ECUs (levels 14 to 19) due to the addition or replacement of these ECUs, or the addition of an application, the cluster manager unit 10a modifies the PNC setting information of these ECUs based on an updated PNC setting table. In this case, the cluster manager unit 10a can configure (reconfigure) the PNC setting information only for the lower-level ECU where the change is made. The cluster manager unit 10a can determine whether the PNC setting information in the PNC setting table matches the PNC setting information held by the first six lower-level ECUs (levels 14 to 19).If it is determined that the PNC setting information in the PNC setting table does not match the PNC setting information held by the first six ECUs (levels 14 to 19) at the lower level, the cluster manager unit 10a can configure (reconfigure) the PNC setting information held by the first six ECUs (levels 14 to 19) at the lower level based on the PNC setting information in the PNC setting table. Additionally, upon receiving a message requesting to configure the PNC setting information of at least one of the first six ECUs (levels 14 to 19) at the lower level, the cluster manager unit 10a can configure (reconfigure) the PNC setting information held by the first six ECUs (levels 14 to 19) at the lower level based on the PNC setting information in the PNC setting table. The wake-up condition (activation condition) of the first to sixth lower-level ECUs (levels 14 to 19) can be modified via the PNC setting information. Therefore, for example, a Cloudserver 40 prepares a PNC setting table on an on-demand basis, in which a change is made to the PNC setting information already applied to at least one lower-level ECU running the downloaded application. For example, it is assumed that a vehicle contains a camera and that the camera is used during driving for an advanced driver assistance function, such as lane keeping assist and obstacle detection. A vehicle user may download an application to provide a surveillance function for monitoring the environments around the vehicle and at home using the camera while parked. In this case, it is necessary that the camera operates not only when the vehicle is moving but also when the vehicle is parked. Therefore, the lower-level ECU controlling the camera must be in wake-up mode (active state) when the vehicle is parked, in addition to when the vehicle is moving.In such a case, the Cloudserver 40 can, for example, prepare the PNC settings table in which a cluster is added for a group of ECUs that are necessary to control the camera when the vehicle is in the parked state. As described, in cases of adding or replacing the first to sixth lower-level ECUs 14 to 19, or adding an application, the PNC settings table, including the PNC settings information, can be prepared by the Cloud Server 40 after a change (corresponding to the cluster settings update information, also referred to as the cluster settings update information of this disclosure). The Cluster Manager Unit 10a can obtain the PNC settings table update information by communicating with the Cloud Server 40 via a TCU 30. The obtained PNC settings table update information is stored in volatile memory 10b, which is a temporary memory.The cluster manager unit 10a then performs a PNC settings table update process described below to update the PNC settings table stored in non-volatile memory 10c based on the PNC settings table of the obtained PNC settings table update information. TCU is an abbreviation for Telematics Control Unit. The PNC settings table update information can be obtained, for example, from a data device (not shown in the drawings) connected to the DLC 31. DLC is an abbreviation for Data Link Coupler. A function of a manager control device can be implemented not only by the higher-level ECU 10, but also by coordinating multiple ECUs. For example, an ECU, apart from the higher-level ECU 10, can receive the PNC setting table update information from the cloud server 40 and store this information in temporary memory. Then, the ECU that stored the PNC setting table update information in temporary memory can cooperate with the higher-level ECU 10 to update the PNC setting table stored in the non-volatile memory 10c of the higher-level ECU 10. Furthermore, the higher-level ECU 10 can download an application for deploying a new function to the vehicle and / or an update program for updating a program already implemented in at least one of the lower-level ECUs 14 to 19 from the cloud server 40 via the TCU 30. The higher-level ECU 10 can deploy the application and update program to the corresponding lower-level ECU 14 to 19. Alternatively, the higher-level ECU 10 can obtain the application and / or update program from the data device (not shown) via the DLC 31. Figure 1 shows a configuration in which the higher-level ECU 10 contains the cluster manager unit 10a, which manages and modifies the PNC setting information of the first through sixth lower-level ECUs 14 through 19. However, the cluster manager unit 10a can be located in any ECU other than the higher-level ECU 10, as long as it is communicable with all of the first through sixth lower-level ECUs 14 through 19 connected to the network. For example, the cluster manager unit 10a can be located in any of the first or third GW ECUs 11 through 13. It should be noted, however, that only one cluster manager unit 10a is located in the vehicle network system 100.This is because, if multiple cluster manager units 10a are provided in the vehicle network system 100, the PNC setting information in the first to sixth lower-level ECUs 14 to 19 may conflict, causing a defect when setting or specifying the PNC setting information. The first to third GW-ECUs 11 to 13 act as relay devices in the network, for example, for bidirectional communication between the first to sixth lower-level ECUs 14 to 19, which are connected to different communication buses 20 to 22. The first to third GW-ECUs 11 to 13 are positioned between the higher-level ECU 10 and the first to sixth lower-level ECUs 14 to 19 and can therefore be called middle-level ECUs. The first to third GW-ECUs 11 to 13 have a sleep mode and a wake-up mode. In sleep mode, the first to third GW-ECUs 11 to 13 perform a function to receive the network management message (“NM message”) and stop other functions. Specifically, the first to third GW-ECUs 11 to 13 contain a communication interface that supports the subnetwork function. The first to third GW-ECUs 11 to 13, in sleep mode, enter wake-up mode upon receiving an NM message to wake up the subordinate unit, which is the first to sixth lower-level ECU 14 to 19, or upon receiving an NM message transmitted by the subordinate unit, which is the first to sixth lower-level ECU 14 to 19, from any of the connected communication buses 20 to 22. In wake-up mode, the first to third GW-ECUs 11 to 13 can perform all functions. For example, the first to third GW-ECUs 11 to 13 can perform the gateway (forward) function of an NM message received from one communication bus 20 to 22 to another communication bus 20 to 22.Between the first to sixth ECUs (14 to 19) at the lower level, control messages containing data and other information related to controls are exchanged in addition to the NM messages to implement the subnetwork. The first to third GW ECUs (11 to 13) in wake-up mode can also perform gatewaying or forwarding of the control messages. Each of the first three GW-ECUs (11 to 13) remains in wake-up mode if one of the first to sixth lower-level ECUs (14 to 19), which are subordinate units of these, is in wake-up mode. In other words, each of the first three GW-ECUs (11 to 13) enters sleep mode after all of the first to sixth lower-level ECUs (14 to 19), which are subordinate units of these, have entered sleep mode. In the example shown in Fig. 1, the first and second lower-level ECUs 14 and 15 are connected to the first GW-ECU 11 via a communication bus 20 as the subordinate units of the first GW-ECU 11. The third and fourth lower-level ECUs 16 and 17 are connected to the second GW-ECU 12 via a communication bus 21 as the subordinate units of the second GW-ECU 12. Furthermore, the fifth and sixth lower-level ECUs 18 and 19 are connected to the third GW-ECU 13 via a communication bus 22 as the subordinate units of the third GW-ECU 13. The number of lower-level ECUs 14 to 19 connected to each communication bus 20 to 22 is not limited to two and can be one, three, or more.Furthermore, a single GW-ECU 11 to 13 can be connected to multiple communication buses, each of which is connected to the lower-level ECUs that are the subordinate units of the single GW-ECU 11 to 13. Examples of the first six ECUs (14 to 19) at the lower level include a control ECU, which executes a control process to control a given control target in the vehicle; a sensor ECU, which executes a computation process to calculate a given physical quantity based on a detection signal detected by a sensor; or a drive ECU, which executes a drive process to output a drive signal to an actuator to power the actuator. Like the first three GW ECUs (11 to 13), the first six ECUs at the lower level (14 to 19) contain a communication interface that supports the subnetwork function.If the first to sixth ECUs (levels 14 to 19) need to control a control object, calculate a given physical quantity based on a sensor detection signal, or drive an actuator, they enter wake-up mode and execute the given control, calculation, or drive process. If the first to sixth ECUs (levels 14 to 19) do not need to execute the given control, calculation, or drive process, they enter sleep mode, which is a sleep state in which functions are stopped except for receiving NM messages. To switch between wake-up and sleep modes, the first six ECUs (levels 14 to 19) each have PNC setting information that specifies the cluster to which they belong among the multiple clusters, which are further subdivided into subdivisions or departments. The PNC setting information is used to group multiple ECUs (levels 14 to 19) into a group of ECUs that are required to wake up within the same time period to provide at least one desired function in the vehicle. During the execution of the given control or calculation process, each of the first six ECUs (levels 14 to 19) periodically transmits the NM message containing active cluster information (also called PN request information) in wake-up mode. This message specifies the cluster to which that particular lower-level ECU belongs as the active cluster. Furthermore, upon receiving the NM message containing the PN request information, which specifies the cluster to which that particular lower-level ECU belongs as the active cluster, that lower-level ECU wakes up from sleep mode if it is in sleep mode and remains in wake-up mode if it is in wake-up mode.This causes two or more lower-level ECUs belonging to the same cluster to be in wake-up mode at the same time interval, so that coordinated control by the two or more lower-level ECUs can be carried out smoothly. The first through sixth ECUs (levels 14 through 19) in wake-up mode stop transmitting the NM message after completing the execution of a given control, computation, or drive process. Each of the first through sixth ECUs (levels 14 through 19) enters sleep mode after a specified time has elapsed during which the NM message, containing the PN request information identifying the cluster to which that lower-level ECU belongs as the active cluster, is not received by that lower-level ECU (the specified time since the last time the NM message was received). Consequently, the first through sixth ECUs (levels 14 through 19) belonging to the same cluster transition from wake-up mode to sleep mode at approximately the same time.In this way, only the necessary ECUs in the cluster units can be woken up, thus realizing the subnetwork. The subnetwork allows only those ECUs whose operation is required to be put into wake-up mode, thereby reducing the power consumption of each individual ECU in the vehicle. The higher-level ECU 10 can include a function for generating and transmitting NM messages to control the switching of the first to sixth lower-level ECUs 14 to 19 between wake-up and sleep modes in cluster units. The higher-level ECU 10 determines, for example, a function to be executed in the vehicle based on the vehicle's state (e.g., driving, stopped, parked, etc., and / or the operating state of various vehicle functions by the user), which is derived from information obtained from a sensor, a switch, and / or another ECU.When a desired function is determined to be executed, the higher-level ECU (ECU 10) generates and transmits the NM message containing the PN request information. This information specifies that the cluster comprising the first six lower-level ECUs (ECUs 14 to 19) must be in wake-up mode at the same time as the active cluster is determined. This causes the desired function to be executed by the lower-level ECUs (ECUs 14 to 19) that are woken up by the NM message. In addition to or instead of the higher-level ECU 10, the function for determining the function to be performed in the vehicle and for transmitting the NM message containing the PN request information can be provided in the first to third GW ECUs 11 to 13 and / or the first to sixth lower-level ECUs 14 to 19. Furthermore, if the vehicle contains multiple higher-level ECUs and multiple lower-level ECUs arranged as subordinate units of each or a respective higher-level ECU, the NM message can be transmitted from another higher-level ECU or from a lower-level ECU arranged as a subordinate unit of another higher-level ECU. The vehicle network system 100 can use CAN (registered trademark) as a communication protocol for the higher-level ECU 10, the first to third GW-ECUs 11 to 13, and the first to sixth ECUs 14 to 19 at the lower level to communicate with each other. CAN is an abbreviation for Controller Area Network. The communication protocol is not limited to CAN. The vehicle network system 100 can use various communication protocols, such as Ethernet (registered trademark), LIN (Local Interconnect Network), FlexRay (registered trademark), and CAN-FD (flexible data rate CAN).For example, different communication protocols can be used for different communication buses, including a communication bus between the higher-level ECU 10 and the first to third GW-ECUs 11 to 13, and a communication bus between the first to third GW-ECUs 11 to 13 and the first to sixth ECUs 14 to 19 of the lower level. In the present embodiment, the vehicle network system 100 is configured such that network management can be performed for each group (i.e., cluster) containing at least one lower-level ECU 14 to 19, in which the operating mode of the lower-level ECU 14 to 19 is switched between wake-up mode and sleep mode. Therefore, the communication protocol used in the vehicle network system 100 is required to support network management. The higher-level ECU 10, the first to third GW-ECUs 11 to 13, and the first to sixth ECUs 14 to 19 of the lower level can each contain a computer, which includes a processor, memory (or RAM), and storage (or data storage). Examples of processors include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), and a DFP (Data Flow Processor), which are capable of executing a given process according to a program. Memory (or RAM) is a volatile storage medium, such as RAM (Random Access Memory), that temporarily stores the result of a computational process performed by the processor. Storage (or data storage) contains a rewritable, non-volatile storage medium, such as flash memory or read-only memory (ROM).Data storage stores various data and programs executed by the processor. Some or all of the functions provided by the higher-level ECU 10, the first to third GW-ECUs 11 to 13, and the first to sixth ECUs 14 to 19 of the lower level can be provided by hardware, such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). Figure 1 shows the cluster manager unit 10a, which is a functional unit provided by software and / or hardware in the higher-level ECU 10. The first through sixth ECUs 14 to 19 of the lower level can each be configured similarly. Fig. 2 shows a block diagram of the functions provided by the first through sixth ECUs 14 to 19 of the lower level with respect to network management. Fig. 2 represents the first ECU 14 of the lower level as a representative example. As can be seen in Fig. 2, the first ECU 14 of the lower level contains a wake / sleep switching unit 23, a cluster information update manager unit 24, volatile memory 25, non-volatile memory 26, and an activation condition change unit 27. The wake / sleep switching unit 23 can be primarily provided by the communication interface that supports the subnetwork function. The wake / sleep switching unit 23 switches the first lower-level ECU 14 to sleep mode upon receiving the NM message containing the PN request information, which specifies the cluster to which the first lower-level ECU 14 belongs as the active cluster. Conversely, the wake / sleep switching unit 23 switches the first lower-level ECU 14 into wake-up mode, in which wake-up mode, upon the elapse of a given time during which the NM message containing the PN request information, in which the cluster to which the first lower-level ECU 14 belongs is determined as the active cluster, is not received by the first lower-level ECU 14 (elapse of the given time since the last time the NM message was received). The first six ECUs (14 to 19) of the lower level may or may not have the communication interface that supports the subnetwork function. In this case, upon receiving the NM message, the wake / sleep switch unit 23 wakes up the first lower-level ECU (14) once while in sleep mode, regardless of whether the wake-up of the first lower-level ECU (14) is specified in the NM message. The wake / sleep switch unit 23 then uses a processing function of the woken-up first lower-level ECU (14) to determine whether the NM message contains the active cluster information, in which the cluster to which the first lower-level ECU (14) belongs is identified as the active cluster.If it is determined that the NM message contains the PN request information that identifies the cluster to which the first lower-level ECU 14 belongs as the active cluster, the wake / sleep switch unit 23 maintains the wake-up state of the first lower-level ECU 14. If it is determined that the NM message does not contain the PN request information that identifies the cluster to which the first lower-level ECU 14 belongs as the active cluster, the wake / sleep switch unit 23 returns the first lower-level ECU 14 to sleep mode. In response to receiving a PNC setting information verification request message (also called a PNC setting value verification request) from the higher-level ECU 10 cluster manager unit 10a, the cluster information update manager unit 24 reads the values ​​(PNC setting values) of the PNC setting information stored in non-volatile memory 26 and sends these values ​​as a response to the cluster manager unit 10a. The cluster information update manager unit 24 then performs the PNC setting information update process to update the PNC setting information stored in non-volatile memory 26 in response to receiving a PNC setting information verification request message (also called a PNC setting request) from the cluster manager unit 10a. In the PNC setting information update process, the cluster information update manager unit 24 first receives the PNC setting information after a change, contained in the PNC setting request message transmitted by the cluster manager unit 10a, and stores this PNC setting information after a change once in volatile memory 25. Next, the cluster information update manager unit 24 checks whether the PNC setting information after a change, stored in volatile memory 25, and the current PNC setting information, stored in non-volatile memory 26, perfectly match.If the verification result is a perfect match, the cluster information update manager unit 24 does not execute a process of writing the PNC setting information stored in volatile memory 25 to non-volatile memory 26. If the verification result is not a perfect match, the cluster information update manager unit 24 executes the process of writing the PNC setting information stored in volatile memory 25 to non-volatile memory 26, thereby updating the PNC setting information stored in non-volatile memory 26. Writing the PNC setting information to non-volatile memory 26 can be either overwriting the PNC setting information stored in non-volatile memory 26 or writing to a different memory location.The Cluster Information Update Manager Unit 24 writes the PNC setting information to the other memory area, making it possible to identify which PNC setting information is the latest. The cluster information update process described above involves writing the PNC setting information to non-volatile memory 26 only if the PNC setting information stored in non-volatile memory 26 does not fully match the PNC setting information stored in volatile memory 25. Typically, non-volatile memory 26 has an upper limit on the number of overwrite operations, and when this limit is reached, it becomes necessary to replace the non-volatile memory 26. According to the present embodiment, the number of times the non-volatile memory 26 is rewritten due to the PNC setting information update process can be reduced. Consequently, it is possible to effectively prevent the number of overwrite operations from reaching this limit.The upper limit of the non-volatile memory rewriting process 26 has been reached. When the PNC setting information of the first lower-level ECU 14 is changed by the cluster manager unit 10a of the higher-level ECU 10, the activation condition change unit 27 determines whether the changed PNC setting information is appropriate. If it determines that the changed PNC setting information is not appropriate, the activation condition change unit 27 changes the activation condition of the first lower-level ECU 14. For example, if the PNC setting information after a change indicates that the first lower-level ECU 14 does not belong to any of the clusters, the activation condition change unit 27 may determine that the PNC setting information is not appropriate. If a change to the PNC setting information by the cluster manager unit 10a is incomplete, the activation condition change unit 27 may also determine that the PNC setting information is inadequate. In a case with a large number of clusters, there may be a situation where the cluster manager unit 10a cannot include the PNC setting information after a change in a single PNC setting request message. In this case, the cluster manager unit 10a divides the PNC setting information after a change into multiple pieces and transmits these multiple PNC setting request messages, each containing the divided pieces of the PNC setting information after a change.If, for any reason, a communication error occurs before the transmission of all PNC setting request messages containing the PNC setting information after a change is complete, the change in the PNC setting information may have been initiated by the cluster manager unit 10a, but it may be incomplete. In the present embodiment, the activation condition change unit 27 has the function of determining whether the change in the PNC setting information is incomplete or not. If it determines that the change in the PNC setting information is incomplete, the activation condition change unit 27 can determine that the PNC setting information is inadequate. If it is determined that the PNC setting information is not appropriate, the activation condition change unit 27 modifies the activation condition of the first lower-level ECU 14. For example, the activation condition change unit 27 can modify the PNC setting values ​​in the PNC setting information so that the first lower-level ECU 14 belongs to all clusters. This allows the first lower-level ECU 14 to be woken up by any NM message containing the PN request information that designates at least one cluster as the active cluster. It is therefore possible to prevent the occurrence of difficulties such as the first lower-level ECU 14 failing to wake up to provide a requested function, and the NM message being unable to wake up the first lower-level ECU 14. This receiving timer is used to measure the time elapsed since the PNC setting value verification request was transmitted from the higher-level ECU 10. As mentioned above, if the first lower-level ECU 14 is woken up by any NM message, it will wake up differently than if it needs to be woken up. Therefore, it may be preferable to reconfigure the PNC setting information of the first lower-level ECU 14 to the appropriate PNC setting information to reduce power consumption. Next, with reference to Fig. 3, examples of the NM message, the PN request information, and the PNC setting information are described in detail. The NM message contains data from Byte0 to Byte7, as shown in Fig. 3. Byte0 contains a Node ID (NID). The Node ID is an identifier unique to each of the ECUS, ECU 10 (higher level), GW ECUs 11 to 13 (first to third level), and ECUs 14 to 19 (first to sixth level). The Node ID identifies the transmission source of the NM message. Byte1 contains a Control Bit Vector (CBV). The Control Bit Vector contains data indicating whether the subnetwork is in use. If the data in the Control Bit Vector indicates subnetwork use, the User Data section from Byte2 to Byte7 contains the PN request information, which is the active cluster information indicating that the cluster is active. In the example shown in Fig. 3, the control bit vector identifies the use of the subnetwork, and the 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 an ECU activation factor or information regarding normality or abnormality. Fig. 3 shows only one example of the NM message format, and the NM message can be in a different format as long as it contains the PN request information. For example, NID and CBV can be omitted. For each of the clusters, which are multiple subdivisions or divisions, the PN request information identifies one active cluster that should be active and one cluster that does not need to be active. More specifically, in the example shown in Fig. 3, the clusters, which are predetermined by subdivision, are 16 clusters. The PN request information contains 16-bit data, one for each of the 16 clusters. That is, the 16-bit data of the PN request information is assigned to the 16 clusters that are predetermined subdivisions. If a particular bit in the 16-bit data of the PN request information is equal to "0", this indicates that the activation of the cluster assigned to that particular bit is not required. This applies to every bit in the 16-bit data.If a specific bit in the 16-bit PN request information is "1", the data indicates that activation of the cluster associated with that specific bit is required. This applies to every bit in the 16-bit data. The PN request information can simply indicate that the cluster is active. Alternatively, the PN request information can simply indicate the cluster that does not require to be active. As described above, an ECU, which can be at least the first to sixth ECU 14 to 19 of the lower level, holds the PNC setting information that identifies the cluster to which that ECU belongs among the multiple clusters that are the multiple subdivisions or departments. More specifically, the PNC setting information of each ECU 14 to 19 of the lower level is stored in non-volatile memory 26. An example of the PNC setting information is shown in Fig. 3. If, in the PNC setting information shown in Fig. 2, the associated clusters are classified as clusters A to P from left to right in Fig. 3, then the PNC setting information in Fig. 3 identifies that the lower-level ECU that has this PNC setting information belongs to clusters D, H, and J.Since the first to sixth ECUs of the 14 to 19 lower level are able to perform various functions by executing programs or the like, the first to sixth ECUs of the 14 to 19 lower level can belong to one or more clusters. Level 14 to 19, the first through sixth ECUs, can receive NM messages containing PN request information through their respective communication interfaces. Upon receiving the NM message, the first through sixth ECUs compare the PN request information and the PNC setting information bit by bit, calculating, for example, logical products as shown in Fig. 3. In other words, each of the first through sixth ECUs determines whether the active cluster, which it is requested to be active by the PN request information contained in the NM message, matches the cluster in the PNC setting information assigned to that ECU. For example, in the diagram in Fig.In the example shown in Figure 3, the active cluster, which is instructed to be active by the PN request information contained in the NM message, is clusters D, G, I, M, N, and O. The cluster to which the lower-level ECU belongs, characterized by the PNC setting information, is clusters D, H, and J. In this case, there is a match in cluster D between the active cluster, which is instructed to be active by the PN request information contained in the NM message, and the cluster containing the PNC setting information. Therefore, the result of the logical product calculation is equal to "1" in cluster D, as shown in Figure 3. If the result of logic products is the presence of "1" for one or more bits, the ECU, which has the PNC setting information shown in Fig. 3, determines that activation is requested. In response to this determination, the lower-level ECU, which has the PNC setting information shown in Fig. 3, transitions from sleep mode to wake-up mode or remains in wake-up mode if it is already in wake-up mode. If the result of logic products is that no bits are equal to "1" and all bits are equal to "0", the ECU, which has the PNC setting information shown in Fig. 3, determines that activation is not requested. In this case, the communication interface of the lower-level ECU, which has the PNC setting information shown in Fig. 3, discards the received NM message.A method for determining whether or not there is a cluster match between the PN request information and the PNC setting information is not limited to a method for calculating logical products. As described, each of the first to sixth ECUs (levels 14 to 19) has the function to identify whether the NM message is a request to activate that lower-level ECU, based on its PNC setting information. Using this NM message identification function, the NM message only wakes up the lower-level ECU (levels 14 to 19) that has the PNC setting information containing the cluster whose activation is requested by the PN request information. For example, Fig. 1 shows an example where the first and third lower-level ECUs 14 and 16 are grouped in cluster C1, the second, fourth, and fifth lower-level ECUs 15, 17, and 18 are grouped in cluster C2, and the sixth lower-level ECU 19 is grouped in cluster C3. If, for example, the higher-level ECU 10 transmits the NM message containing the PN request information that designates cluster C1 as the active cluster, the NM message consequently causes the first and third lower-level ECUs 14 and 16 to enter wake-up mode, while the other lower-level ECUs 15, 17 through 19 remain in sleep mode, thus realizing the subnetwork. In addition to the first to sixth ECUs 14 to 19 of lower level, the PNC setting information for each of the ECUs, ECU 10 of higher level and / or first to third GW-ECUs 11 to 13, can be set or configured to wake up and sleep via NM messages. Next, the details of the processes executed in each of the ECUs, the higher-level ECU 10 and the first through sixth ECUs 14 to 19, for network management, including a realization of the subnetwork in the vehicle network system 100 of the present embodiment, are described with reference to flowcharts and sequence diagrams. An execution of the processes shown in the flowcharts described below by the higher-level ECU 10 and the first through sixth ECUs 14 to 19 corresponds to an execution of the control procedure of the vehicle network system 100 in the present disclosure. The flowchart in Fig. 4 shows an example of a main process routine that can be executed in the higher-level ECU 10 when the cluster manager unit 10a is deployed in the higher-level ECU 10. Upon power-up, the higher-level ECU 10 starts the main process routine shown in the flowchart in Fig. 4. In step S100, the higher-level ECU 10 performs an initialization process. This process includes, for example, initial hardware configuration and a storage medium operational check. In step S110, the higher-level ECU 10 determines whether or not a wake-up factor has occurred. For example, the higher-level ECU 10 might determine that a wake-up factor has occurred upon receiving a signal indicating a need to wake up (trigger signal, toggle signal, sensor signal, etc.) or upon receiving the NM message containing the PN request information, which identifies the cluster to which the higher-level ECU 10 belongs as the active cluster. If step S110 determines that a wake-up factor has not occurred, the higher-level ECU 10 proceeds to step S120 and enters sleep mode.Upon determining that the wake-up factor has occurred, the ECU 10 proceeds to step S130 at a higher level. In step S130, the higher-level ECU 10 performs an activation process. This process includes, for example, reading software containing an operating system (OS) and a program from memory or data storage and saving the read software to memory or main memory. In step S140, the higher-level ECU 10 performs the PNC setting necessity determination process to determine whether or not it is necessary to set or configure the PNC setting information on the first six ECUs (14 to 19) at the lower level. Setting or configuring the PNC setting information can be paraphrased as configuring the PNC setting information. The PNC setting necessity determination process is described in detail later. In step S150, the higher-level ECU 10 determines, based on the result of the PNC setting necessity determination process from step S140, specifically based on the value of a PNC setting flag set in the PNC setting necessity determination process, whether or not it is necessary to set the PNC setting information of the first six ECUs 14 to 19 at the lower level. If it determines that setting the PNC setting information is necessary, the higher-level ECU 10 proceeds to step S160. If it determines that setting the PNC setting information is not necessary, the higher-level ECU 10 proceeds to step S200. In step S160, the higher-level ECU 10 executes the PNC setting process to reconfigure the PNC setting information of the first through sixth lower-level ECUs 14 through 19. The PNC setting process is described in detail later. In step S170, the higher-level ECU 10 determines whether the PNC setting process is complete for all of the first through sixth lower-level ECUs 14 through 19. Specifically, the PNC setting process is executed sequentially for the first through sixth lower-level ECUs 14 through 19. If it is determined that the PNC setting process is incomplete for all of the first through sixth lower-level ECUs 14 through 19, the higher-level ECU 10 proceeds to step S180 to switch the lower-level process target ECU. Then, in step S160, the higher-level ECU 10 executes the PNC setting process for the lower-level process target ECU.Upon determining that the PNC setting process is complete for all of the first to sixth ECUs 14 to 19 at the lower level, the ECU 10 at the higher level proceeds to step S190. In step S190, the higher-level ECU 10 performs a PNC setting completion process, since the PNC setting process is complete for all lower-level ECUs 14 to 19. The PNC setting completion process is described in more detail later. In step S200, the higher-level ECU 10 determines whether or not it is necessary to update the PNC settings table. For example, the higher-level ECU 10 might determine whether or not to update the PNC settings table based on whether or not a request to update the PNC settings table is received from Cloud Server 40. If it determines that an update of the PNC settings table is necessary, the higher-level ECU 10 proceeds to step S210. If it determines that an update of the PNC settings table is not necessary, the higher-level ECU 10 proceeds to step S220. In step S210, the higher-level ECU 10 performs a table update process to update the PNC setting table, which links the first six lower-level ECUs 14 to 19 and their respective PNC setting information. The table update process is described in more detail below. In step S220, the higher-level ECU 10 determines whether all ECUs belonging to the vehicle network system 100 have entered sleep mode. This determination can be based on whether a given time has elapsed since the higher-level ECU 10 received any NM messages from the other ECUs. If the given time has elapsed since the absence of NM messages from all other ECUs, and it is determined that all ECUs have entered sleep mode, the higher-level ECU 10 proceeds to step S230. If it is determined that not all ECUs have entered sleep mode, the higher-level ECU 10 returns to the process of step S140. In step S230, the higher-level ECU 10 determines whether the power is switched off or not. If it determines that the power is switched off, the higher-level ECU 10 terminates the main process routine, which can be seen in the flowchart in Fig. 4. If it determines that the power is not switched off, the higher-level ECU 10 returns to the process from step S110. Next, the PNC setting necessity determination process in step S140 of the flowchart in Fig. 4, which is one of the subroutines of the main process routine in Fig. 4, is described in detail. Fig. 5 is a flowchart showing an example of the details of the PNC setting necessity determination process. In step S300, the higher-level ECU 10 determines whether the PNC setting flag is set to "1" or not. Step S320, described below, sets the PNC setting flag to "1" if it is necessary to reconfigure the PNC setting information of the first six ECUs 14 to 19 at the lower level. If step S300 determines that the PNC setting flag is "1", it is very likely that the PNC setting process (step S160 in Fig. 4) and / or the PNC setting completion process (step S190 in Fig. 4) have not been completed successfully. Therefore, if in step S300 it is determined that the PNC setting flag is equal to “1”, the higher-level ECU 10 terminates the PNC setting necessity determination process shown in the flowchart in Fig. 5, without changing the value of the PNC setting flag to repeat the PNC setting process.If it is determined that the PNC setting flag is not equal to "1", the ECU 10 proceeds to step S310 at a higher level. In step S310, the higher-level ECU 10 determines whether it has received the PNC setting request from the cloud server 40. If it determines that the PNC setting request has been received from the cloud server 40, the higher-level ECU 10 proceeds to step S320 to set the PNC setting flag to "1". As described, upon receiving the PNC setting request from an external device, such as the cloud server 40, the higher-level ECU 10 determines, based on the PNC setting information, that it is necessary to reconfigure the PNC setting information of the first six lower-level ECUs 14 to 19. The higher-level ECU 10 then completes the PNC setting necessity determination process shown in the flowchart in Fig. 5. If it is determined that the PNC setting request has not been received from cloud server 40, the ECU 10 proceeds to step S330 at a higher level. For example, Cloud Server 40 prepares a corrected (modified) PNC settings table so that, if, for instance, an additional application is downloaded to a first through sixth ECU (levels 14 through 19) at a lower level, this lower-level target ECU will wake up when the additional application's functionality is required. While the corrected (modified) PNC settings table is being prepared, Cloud Server 40 transmits a PNC settings table update request to the higher-level ECU (level 10). If the PNC settings table maintained by the higher-level ECU (level 10) is updated in response to this PNC settings table update request, Cloud Server 40 can then transmit the PNC settings request to the higher-level ECU (level 10). Alternatively, if the PNC setting table is updated in the higher-level ECU 10, the higher-level ECU 10 can set the PNC setting flag to "1," regardless of the request from Cloudserver 40. Cloudserver 40 can transmit the PNC setting request at any time other than when the PNC setting table is changed. Furthermore, Cloudserver 40 can prepare a corrected (modified) PNC setting table when a lower-level ECU is replaced or added, or when the software of a lower-level ECU is updated to include a new function. A fixture other than Cloudserver 40, such as the tool fixture described above, can transmit the PNC setting request and the PNC setting table update request to the higher-level ECU 10. In step S330, the higher-level ECU 10 determines whether it has received the PNC setting request message from at least one lower-level ECU 14 to 19. As described in detail later, each of the first through sixth lower-level ECUs 14 to 19 determines whether the PNC setting information is adequate and, if so, transmits the PNC setting request message to the higher-level ECU 10. If it determines that the PNC setting request message has been received from at least one lower-level ECU 14 to 19, the higher-level ECU 10 proceeds to step S320 to set the PNC setting flag to "1". Afterwards, the higher-level ECU 10 completes the PNC setting necessity determination process shown in the flowchart in Fig. 5.If it is determined that the PNC setting request message has not been received by at least one lower-level ECU 14 to 19, the higher-level ECU 10 proceeds to step S340. In step S340, the higher-level ECU 10 determines whether a setting status determination request has occurred. This request is used to determine whether the PNC setting information from each lower-level ECU 14 to 19, as stored in the PNC setting table maintained by the higher-level ECU 10, matches the PNC setting information configured in each lower-level ECU 14 to 19. For example, whether setting status determination is enabled or disabled in the higher-level ECU 10 can be pre-configured (set) by a manufacturer, vendor, or user of the vehicle network system 100. If setting status determination is enabled, the higher-level ECU 10 performs the determination process shown in step S340 and the setting status determination process shown in step S350 periodically or at a specified time.When setting status determination is enabled, for example, Cloudserver 40 or a data device can periodically or at a given time generate the setting status determination request and transmit the setting status determination request to the higher-level ECU 10. The higher-level ECU 10 can then execute the setting status determination process upon receiving the setting status determination request. If step S340 determines that the setting status determination requirement has occurred, the higher-level ECU 10 proceeds to step S350 to execute the setting status determination process. Afterward, the higher-level ECU 10 completes the PNC setting necessity determination process shown in the flowchart in Fig. 5. The setting status determination process is described in detail later. If step S340 determines that the setting status determination requirement has not occurred, the higher-level ECU 10 proceeds to step S360. In step S360, the higher-level ECU 10 sets the PNC setting flag to "0" because it is not necessary to reconfigure the PNC setting information. Afterward, the higher-level ECU 10 completes the PNC setting necessity determination process shown in the flowchart in Fig. 5. The setting status determination process is next described in detail in step S350 of the flowchart in Fig. 5. Fig. 6 is a flowchart showing an example of the details of the setting status determination process. Fig. 7 is a sequence diagram showing an example of the flow of processes in the higher-level ECU 10 and the first six lower-level ECUs 14 to 19 when the setting status determination process is executed. In the setting status determination process, the higher-level ECU 10 first transmits the NM message N times (N being an integer of 2 or more) as the activation request in step S400, as shown in the sequence diagram in Fig. 7. The NM message can wake up all of the lower-level ECUs 14 to 19. For example, as the NM message that can wake up all of the lower-level ECUs 14 to 19, the higher-level ECU 10 can transmit the NM message containing the PN request information, in which the active clusters are clusters, each of which includes all of the lower-level ECUs 14 to 19. Alternatively, the higher-level ECU 10 can transmit the NM message containing a command that instructs all of the lower-level ECUs 14 to 19 to wake up. By transmitting the NM message multiple times, the higher-level ECU 10 can reliably wake up all lower-level ECUs 14 to 19. In step S410, the higher-level ECU 10 resets a receive timer. This receive timer is used to measure the time elapsed since the PNC setting value verification request message was transmitted by the higher-level ECU 10. Then, in step S420, the higher-level ECU 10 transmits the (initial) PNC setting value verification request message to all lower-level ECUs 14 through 19, as shown in the sequence diagram in Fig. 7. At the same time, the higher-level ECU 10 starts the receive timer for a timing measurement. In step S430, the higher-level ECU 10 determines whether it has received an initial PNC setting value verification response message from all lower-level ECUs 14 to 19. This initial PNC setting value verification response message contains the first half of the PNC setting information configured for the lower-level ECUs 14 to 19. If it determines that the initial PNC setting value verification response message has been received by all lower-level ECUs 14 to 19, the higher-level ECU 10 proceeds to step S450. If it determines that the initial PNC setting value verification response message has not yet been received by all lower-level ECUs 14 to 19, the higher-level ECU 10 proceeds to step S440. In step S440, the higher-level ECU 10 determines, based on the time measured by the receive timer, whether a receive timeout period has elapsed. If it determines that the receive timeout period has elapsed, the higher-level ECU 10 proceeds to step S530. If it determines that the receive timeout period has not yet elapsed, the higher-level ECU 10 returns to the process in step S430. If the activation request from the higher-level ECU 10 normally wakes up all of the lower-level ECUs 14 to 19, and all of the lower-level ECUs 14 to 19 are communicable with the higher-level ECU 10, the (initial) PNC setting value verification response message, which contains the first half of the PNC setting information, is expected to be transmitted by each of the lower-level ECUs 14 to 19 within a given time from the time at which the higher-level ECU 10 transmits the (initial) PNC setting value verification request message.In other words, if, at the time when the time measured by the receiving timer since the transmission of the (initial) PNC setting value verification request message reaches the given time (corresponding to the timeout period), there is a lower-level ECU 10 from which the (initial) PNC setting value verification response message has not been received, there is a possibility that an abnormality is occurring in the lower-level ECU, and the lower-level ECU is not normally woken up. Therefore, in step S530, the higher-level ECU 10 sets the PNC setting flag to "1" to reconfigure the PNC setting information of the first six lower-level ECUs 14 to 19. In step S450, the higher-level ECU 10 determines whether the PNC setting value to be transmitted, but not yet transmitted, is still present. This determination is made because, due to the large number of clusters, the lower-level ECUs 14 to 19 cannot transmit all of the PNC setting values ​​from the PNC setting information via a single PNC setting value verification response message. The higher-level ECU 10 can make the determination in step S450 based on the number of PNC setting values ​​in the PNC setting information of the PNC setting table. If it determines that the PNC setting value to be transmitted is still present, the higher-level ECU 10 proceeds to step S460. If it determines that the PNC setting value to be transmitted is absent, the higher-level ECU 10 proceeds to step S500. The flowchart in Fig. 6 shows the processes for cases in which the first to sixth lower-level ECUs (14 to 19) transmit all of the PNC setting values ​​to the higher-level ECU (10) such that the PNC setting value verification request message is transmitted once or twice, and the PNC setting value verification response message is transmitted once or twice. The sequence diagram in Fig. 7 shows an example in which the first to sixth lower-level ECUs (14 to 19) transmit all of the PNC setting values ​​to the higher-level ECU (10) such that the PNC setting value verification request message is transmitted twice, and the PNC setting value verification response message is transmitted twice. In Fig. 6 and Fig. 7, the PNC setting value verification request message is first transmitted as "(initial) PNC setting value verification request."The PNC setting value verification response message is displayed as "(first) PNC setting value verification response" the first time, as "(second) PNC setting value verification request" the second time, and as "(second) PNC setting value verification response" the third time. In the embodiments described below, it is assumed that all PNC setting values ​​are transmitted by transmitting the PNC setting value verification request message once or twice and by transmitting the PNC setting value verification response message once or twice.However, the PNC setting value verification request message can be transmitted three or more times, and the PNC setting value verification response message can be transmitted three or more times, depending on the number of PNC setting values. If it is known in advance that the PNC setting values ​​can be transmitted by a single message, steps S450 to S490 of the flowchart in Fig. 6 can be omitted. In step S460, the higher-level ECU 10 resets the receive timer. Then, in step S470, the higher-level ECU 10 transmits the (second) PNC setting value verification request message to all lower-level ECUs 14 to 19, as shown in the sequence diagram in Fig. 7. At the same time, the higher-level ECU 10 starts the receive timer for a timing measurement. In step S480, the higher-level ECU 10 determines whether the (second) PNC setting value verification response message, which contains the remaining PNC setting values, has been received by all lower-level ECUs 14 to 19. If it determines that the (second) PNC setting value verification response message has been received by all lower-level ECUs 14 to 19, the higher-level ECU 10 proceeds to step S500. If it determines that the (second) PNC setting value verification response message has not yet been received by all lower-level ECUs 14 to 19, the higher-level ECU 10 proceeds to step S490. In step S490, the higher-level ECU 10 determines, based on the time measured by the receive timer, whether the receive timeout period has elapsed. If it determines that the receive timeout period has elapsed, the higher-level ECU 10 proceeds to step S530 to set the PNC setting flag to "1". If it determines that the receive timeout period has not yet elapsed, the higher-level ECU 10 returns to the process in step S480. In step S500, the higher-level ECU (level 10) records the PNC setting values ​​for each lower-level ECU (level 19) contained in the (first) PNC setting value verification response message received from the lower-level ECU (levels 14 to 19), and, if a (second) PNC setting value verification response message is received, the PNC setting values ​​contained in that (second) PNC setting value verification response message. In step S510, the higher-level ECU (level 10) verifies the PNC setting values ​​recorded for each lower-level ECU (levels 14 to 19) against the PNC setting values ​​of the corresponding lower-level ECU (levels 14 to 19) in the PNC setting table maintained by the higher-level ECU (level 10). This verification is performed for all lower-level ECUs (levels 14 to 19).Then, in step S520, the higher-level ECU 10 determines, based on the match result in step S510, whether the match is OK or not. At this time, the higher-level ECU 10 determines that the match is OK if a complete match of all PNC setting values ​​is found for all lower-level ECUs 14 to 19. If a difference is found in at least one PNC setting value for at least one lower-level ECU 14 to 19, the higher-level ECU 10 determines that the match is OK. If step S520 determines that the match is not OK, the higher-level ECU 10 proceeds to step S530 to set the PNC setting flag to "1" to reconfigure the PNC setting information of the first six ECUs 14 to 19 at the lower level. If the match is determined to be OK, the higher-level ECU 10 proceeds to step S540 to set the PNC setting flag to "0", as it is not necessary to reconfigure the PNC setting information of the first six ECUs 14 to 19 at the lower level. Through the setting status determination process described above, it is possible to update the PNC setting values ​​in each of the lower-level ECUs 14 to 19 to match the PNC setting values ​​in the PNC setting table of the higher-level ECU 10, even in cases where, for any reason, the PNC setting values ​​in the PNC setting information of the lower-level ECUs 14 to 19 have become mismatched with the PNC setting values ​​in the PNC setting information of the PNC setting table maintained by the higher-level ECU 10. Accordingly, it is possible to appropriately maintain the PNC setting values, the PNC setting information, of each of the lower-level ECUs 14 to 19. In the example above, the higher-level ECU 10 transmits the PNC setting value verification request message to all lower-level ECUs 14 through 19 at once. Alternatively, the higher-level ECU 10 can transmit the PNC setting value verification request message to the respective lower-level ECUs 14 through 19 in a given sequence and receive the PNC setting value verification response message from the respective lower-level ECUs 14 through 19. Next, the PNC setting process is described in detail in step S160 of the flowchart in Fig. 4, which is one of the subroutines of the main process routine in Fig. 4. Fig. 8 is a flowchart showing an example of the details of the PNC setting process. Fig. 9 is a sequence diagram showing an example of the flow of processes in the higher-level ECU 10 and the first six lower-level ECUs 14 to 19 when the PNC setting process is executed. The sequence diagram in Fig. 9 shows an example where the PNC setting process is executed in response to the PNC setting request from Cloud Server 40. The PNC setting process is executed for the first through sixth ECUs (levels 14 through 19) in the given sequence. Therefore, each of the first through sixth ECUs (levels 14 through 19) must maintain wake-up mode for one rotation to complete the PNC setting process. In step S600, the higher-level ECU (level 10) determines, based on the time measured by a wake-up (WA) timer, whether a given wake-up threshold time has elapsed since the last time the NM message to wake up all ECUs (levels 14 through 19) was transmitted N times (N being an integer greater than or equal to 2). This WA timer measures the time that has elapsed since the higher-level ECU 10 transmitted the NM (Activation Request) message to wake up all of the lower-level ECUs 14 to 19.If it is determined that the given wake-up threshold time has elapsed, the ECU 10 at a higher level proceeds to step S610. If it is determined that the given wake-up threshold time has not elapsed, the ECU 10 at a higher level proceeds to step S630. In step S610, the higher-level ECU 10 resets the WA timer. Then, in step S620, the higher-level ECU 10 transmits the NM message (activation request) to wake up all lower-level ECUs 14 to 19, as shown in the sequence diagram in Fig. 9. At the same time, the higher-level ECU 10 starts the WA timer for a timing measurement. As described above, each lower-level ECU (levels 14 to 19) enters sleep mode after a given sleep threshold has elapsed. During this sleep mode, neither the NM message containing the PN request information, which designates the cluster to which the lower-level ECU belongs as the active cluster, nor the NM messages containing the command instructing all lower-level ECUs (levels 14 to 19) to wake up are received (upon the elapse of the given sleep threshold since the last time the NM message was received). The given wake-up threshold is set shorter than the given sleep threshold of each lower-level ECU (levels 14 to 19). Therefore, it is possible that before the sleep threshold has elapsed, the higher-level ECU (level 10) transmits the activation request to all lower-level ECUs (levels 14 to 19) according to the elapsed wake-up threshold.As a result, it is possible to keep each of the ECUs 14 to 19 at a lower level in wake-up mode until the rotation comes to perform the PNC setting process. In step S630, the higher-level ECU 10 resets the receive timer. This receive timer is used to measure the time elapsed since the (initial) PNC setting request message was transmitted by the higher-level ECU 10. Then, in step S640, the higher-level ECU 10 transmits the (initial) PNC setting request message to the lower-level ECU, which is the target of the PNC setting process, as shown in the sequence diagram in Fig. 9. This (initial) PNC setting request message contains the PNC setting values ​​of the first half of the PNC setting information associated with the lower-level target ECU in the updated PNC setting table. At the same time, the higher-level ECU 10 starts the receive timer for a timing measurement. In step S650, the higher-level ECU 10 increments a transmission time counter by 1, where the transmission time counter counts the number of times the (initial) PNC setting request message is transmitted. In step S660, the higher-level ECU 10 determines whether or not it has received the (initial) PNC setting response message from the lower-level ECU, which is the target of the PNC setting process. If the lower-level ECU, which is the target of the PNC setting process, receives the (initial) PNC setting request message, containing the PNC setting values ​​of the first half of the PNC setting information, from the higher-level ECU 10 and stores these values ​​in its volatile memory 25, the lower-level ECU transmits the (initial) PNC setting response message.If it is determined that the (initial) PNC setting response message has been received by the lower-level ECU that is the target of the PNC setting process, the higher-level ECU proceeds to step S690. If it is determined that the (initial) PNC setting response message has not been received by the lower-level ECU that is the target of the PNC setting process, the higher-level ECU proceeds to step S670. In step S670, the higher-level ECU 10 determines, based on the time measured by the receive timer, whether the receive timeout period has elapsed. If it determines that the receive timeout period has elapsed, the higher-level ECU 10 proceeds to step S680. If it determines that the receive timeout period has not yet elapsed, the higher-level ECU 10 returns to the process in step S660. Therefore, the higher-level ECU 10 can continue with the PNC setting process even if, for any reason, it does not receive the (initial) PNC setting response message from the lower-level ECU, which is the target of the PNC setting process. In step S680, the higher-level ECU 10 determines, based on the value of the transmission counter, whether the number of times the (initial) PNC setting request message has been transmitted is less than or equal to the given number of times. The given number of times can be any greater than one. If it determines that the number of times the (initial) PNC setting request message has been transmitted is still less than or equal to the given number of times, the higher-level ECU 10 returns to the process in step S630 and repeats this transmission of the (initial) PNC setting request message. If it determines that the number of times the (initial) PNC setting request message has been transmitted exceeds the given number of times, the higher-level ECU 10 proceeds to step S770.In this way, by repeatedly transmitting the (initial) PNC setting request message through the higher-level ECU 10, it is possible to increase the probability that the lower-level PNC setting process target ECU will receive the (initial) PNC setting request message. In step S770, the higher-level ECU 10 records a PNC setting abnormality of the lower-level ECU, which is the target of the PNC setting process, in the non-volatile memory medium, because the higher-level ECU 10 does not receive the (initial) PNC setting response message from the lower-level ECU, which is the target of the PNC setting process, despite multiple repeated transmissions of the (initial) PNC setting request message. In step S690, the higher-level ECU 10 determines, considering a large number of clusters, whether the PNC setting value to be transmitted, but not yet transmitted, still exists. If it determines that the PNC setting value to be transmitted still exists, the higher-level ECU 10 proceeds to step S700. If it determines that the PNC setting value to be transmitted, but not yet transmitted, is absent, the higher-level ECU 10 proceeds to step S780. In step S700, the higher-level ECU 10 resets the transmission counter. In step S710, the higher-level ECU resets the receive timer. Then, in step S720, the higher-level ECU 10 transmits the (second) PNC setting request message to the lower-level ECU, which is the PNC setting process target, as shown in the sequence diagram in Fig. 9. The (second) PNC setting request message contains the PNC setting values ​​of the last half of the PNC setting information associated with the lower-level ECU, which is the PNC setting process target, in the updated PNC setting table. At the same time, the higher-level ECU 10 starts the receive timer for a timing measurement. In step S730, the higher-level ECU 10 increments the transmission count counter by 1. In step S740, the higher-level ECU 10 determines whether it has received the (second) PNC setting response message from the lower-level ECU, which is the PNC setting process target. If the lower-level ECU, which is the PNC setting process target, receives the (second) PNC setting request message, containing the PNC setting values ​​of the last half of the PNC setting information, from the higher-level ECU 10 and stores these values ​​in its volatile memory 25, the lower-level ECU transmits the (second) PNC setting response message.If it is determined that the (second) PNC setting response message has been received by the lower-level ECU that is the PNC setting process target, the higher-level ECU proceeds to step S780. If it is determined that the (second) PNC setting response message has not been received by the lower-level ECU that is the PNC setting process target, the higher-level ECU proceeds to step S750. In step S750, the higher-level ECU 10 determines, based on the time measured by the receive timer, whether the receive timeout period has elapsed or not. If it determines that the receive timeout period has elapsed, the higher-level ECU 10 proceeds to step S760. If it determines that the receive timeout period has not yet elapsed, the higher-level ECU 10 returns to the process in step S740. In step S760, the higher-level ECU 10 determines, based on the value of the transmission counter, whether the number of times the (second) PNC setting request message has been transmitted is less than or equal to the specified number of times. If it determines that the number of times the (second) PNC setting request message has been transmitted is still less than or equal to the specified number of times, the higher-level ECU 10 returns to the process in step S710 and repeats this transmission of the (second) PNC setting request message.Upon determining that the number of times the (second) PNC setting request message has been transmitted exceeds the given number of times, the higher-level ECU 10 proceeds to step S770 to record the PNC setting abnormality of the lower-level ECU, which is the PNC setting process target, in the non-volatile memory medium. In step S780, the higher-level ECU 10 resets the transmission count counter in preparation for the PNC setting process for the next lower-level ECU, which is the next PNC setting process target. Then, in step S790, the higher-level ECU 10 determines that the PNC setting process for the lower-level ECU, which is the PNC setting process target, is complete and returns to the process shown in the flowchart in Fig. 4. The PNC setting process shown in the flowchart in Fig. 8 is repeated until the PNC setting process is complete for all lower-level ECUs 14 to 19. Next, the PNC settings completion process in step S190 of the flowchart in Fig. 4, which is one of the subroutines of the main process routine in Fig. 4, is described in detail. Fig. 10 is a flowchart showing an example of details of the PNC settings completion process. In step S800, the higher-level ECU 10 determines whether the PNC setting process described above was executed by Cloud Server 40 in response to the PNC setting request. If it determines that the PNC setting process was executed by Cloud Server 40 in response to the PNC setting request, the higher-level ECU 10 proceeds to step S810. If it determines that the PNC setting process was not executed by Cloud Server 40 in response to the PNC setting request, the higher-level ECU 10 proceeds to step S820. In step S810, the higher-level ECU 10 transmits the PNC setting response to the cloud server 40, indicating that the execution of the PNC setting process is complete, as shown in the sequence diagram in Fig. 9. In step S820, the higher-level ECU 10 sets the PNC setting flag to "0" to indicate that reconfiguring the PNC setting information is not necessary. The higher-level ECU 10 then returns to the process shown in the flowchart in Fig. 4. Next, the table update process in step S210 of the flowchart in Fig. 4, which is one of the subroutines of the main process routine in Fig. 4, is described in detail. Fig. 11 shows an example of the PNC settings table. Fig. 12 is a flowchart showing an example of the details of the table update process. Fig. 13 is a sequence diagram showing an example of the process flow in the higher-level ECU 10 when the table update process is executed. The sequence diagram in Fig. 13 shows an example where the higher-level ECU 10 updates the PNC settings table by interacting with the Cloudserver 40. First, the PNC setting table is described with reference to Fig. 11. The PNC setting table is maintained by the higher-level ECU 10. More precisely, the PNC setting table is stored in the non-volatile memory 10c of the higher-level ECU 10. As shown in Fig. 11, the PNC setting table is a list of data that links the PNC setting information of each lower-level ECU to its corresponding node ID. The node ID is an identifier that is unique for each lower-level ECU 14 through 19. The higher-level ECU 10 can maintain multiple PNC setting tables. From these multiple PNC setting tables, the higher-level ECU 10 can select one to use, for example, based on the vehicle's destination, gradient, vehicle-equipped option, or similar criteria. Specifically, it selects and activates a PNC setting table from among the multiple PNC setting tables. In this case, the higher-level ECU 10 can itself select a PNC setting table based on the vehicle's destination, gradient, or similar criteria. The higher-level ECU 10 can also select a PNC setting table following instructions from an external device, such as the Cloudserver 40.If the vehicle's location of use or option information is changed, the higher-level ECU 10 can switch the PNC setting table to be used, so that the PNC setting table is used according to the vehicle's location of use or the option information. From an external device, such as the Cloudserver 40, the higher-level ECU 10 can receive multiple PNC setting tables of several types that are most likely to be used, so that the higher-level ECU 10 can store these multiple PNC setting tables. In this case, the external device, such as the Cloudserver 40, can issue instructions to the higher-level ECU 10 regarding which PNC setting table to use (to activate) according to a type of ECU actually installed in the vehicle, a function provided by those ECUs, or the like. The PNC setting tables of several types, maintained by the higher-level ECU 10, can include, for example, a PNC setting table for vehicle evacuation runs in addition to a user-customized PNC setting table. The evacuation PNC setting table contains the PNC setting information of ECUs configured so that, for example, only ECUs involved in a vehicle-driving function are awakened, while the other ECUs remain in sleep mode. This facilitates the vehicle's ability to travel a longer distance during evacuation. The higher-level ECU 10 can switch to the evacuation PNC setting table in response to a need arising from a significant abnormality in the vehicle, such as the need for the vehicle to evacuate to a safe area. When the PNC setting table to be used is switched among the PNC setting tables of several types in the higher-level ECU 10, the higher-level ECU 10 performs the PNC setting process described above. Accordingly, the PNC setting information held by the first to sixth lower-level ECUs 14 to 19 is changed based on the switched PNC setting table. The table update process is described next with reference to Fig. 12. In step S900, the higher-level ECU 10 determines whether or not it has received the PNC settings table update request from the cloud server 40, as shown in the sequence diagram in Fig. 13. For example, in the case of adding or replacing the first six lower-level ECUs 14 to 19, or adding an application, the cloud server 40 may prepare the PNC settings table containing the PNC settings information after a change. Once the cloud server 40 has prepared the PNC settings table, it transmits the PNC settings table update request to the higher-level ECU 10.If the ECU 10 determines that the PNC settings table update request has been received, it proceeds to step S910. If it determines that the PNC settings table update request has not been received, the ECU 10 terminates the table update process shown in the flowchart in Fig. 12. In step S910, the higher-level ECU 10 transmits a PNC setting table update response to the cloud server 40, as shown in the sequence diagram in Fig. 13. In response to this PNC setting table update response, the cloud server 40 transmits the PNC setting table containing the updated PNC setting information to the higher-level ECU 10 as the PNC setting table update information (corresponding to cluster setting information to update, also referred to as cluster setting information to update of the present invention). In step S920, the higher-level ECU 10 performs the PNC setting table receive process to receive the PNC setting table update information. Next, an example of the PNC settings table receiving process will be described with reference to the flowchart in Fig. 14. In step S1000, the higher-level ECU 10 performs a masking process to prevent overwriting the current PNC setting table stored in the non-volatile memory medium 10c of the higher-level ECU 10. In this masking process, the higher-level ECU 10 performs masking so that the memory area of ​​the non-volatile memory medium 10c that stores the current PNC setting table cannot be overwritten when PNC setting table update information is received and the PNC setting table is saved. This prevents the current PNC setting table from being accidentally overwritten by the PNC setting table contained in the received PNC setting table update information. It is assumed that the current PNC setting table is directly overwritten by the PNC setting table in the received PNC setting table update information. In this case, if the reception of the PNC setting table update information is interrupted for any reason, the PNC setting values ​​of the PNC setting table in the PNC setting table update information and the PNC setting values ​​in the current PNC setting table can coexist, resulting in an unintended PNC setting table. Therefore, in the present embodiment, the higher-level ECU 10 temporarily stores the PNC setting table from the received PNC setting table update information in a memory area (temporary memory) that is separate from the memory area of ​​the current PNC setting table.This temporary memory can be a memory area of ​​the non-volatile memory 10c, but preferably a memory area of ​​the non-volatile memory 10c that is separate from the non-volatile memory 10b. This is because using the memory area of ​​the non-volatile memory 10b as the temporary memory can reduce the number of overwrite operations of the non-volatile memory 10c. In step S1010, the higher-level ECU 10 initializes the memory area, which is the temporary memory of the PNC settings table in the PNC settings table update information. In step S1020, the higher-level ECU 10 resets and then restarts the receive timer, which measures the reception time of the PNC setting table update information. In step S1030, the higher-level ECU 10 writes the received PNC setting table update information to temporary memory. In step S1040, the higher-level ECU 10 determines whether all PNC setting table update information has been received. This determination can be based, for example, on whether data indicating the end of the PNC setting table update information has been received. If it determines that not all PNC setting table update information has been received, the higher-level ECU 10 proceeds to step S1050.Upon determining that all PNC setting table update information has been received, the ECU 10 proceeds to step S1060 at a higher level. In step S1050, the higher-level ECU 10 determines, based on the time measured by the receive timer, whether the receive timeout period has elapsed. The receive timeout period is defined as a time interval longer than the time required for the higher-level ECU 10 to receive the PNC settings table update information from the cloud server 40 in normal cases. Therefore, if step S1050 determines that the receive timeout period has elapsed, the higher-level ECU 10 returns to the process in step S1100 and, as shown in the sequence diagram in Fig. 13, transmits a receive error response to the cloud server 40, indicating that receiving the PNC settings table update information failed. This receive error response also includes a message to Cloud Server 40 instructing the PNC settings table update information to be retransmitted. Upon receiving the receive error response from the higher-level ECU 10, Cloud Server 40 retransmits the PNC settings table update information to the higher-level ECU 10. When the receive error response is transmitted, the higher-level ECU 10 discards the incomplete PNC settings table update information stored in temporary memory. After executing the process of step S1100, the higher-level ECU 10 completes the PNC setting table receive process shown in the flowchart of Fig. 14. If it is determined in step S1050 that the receive timeout period has not yet expired, the higher-level ECU 10 returns to the process in step S1030. In step S1060, the higher-level ECU 10 determines whether the PNC setting table verification function is enabled or not. Whether the PNC setting table verification function is enabled or disabled in the higher-level ECU 10 can be configured in advance, for example, by a manufacturer, a vendor, or a user of the vehicle network system 100. If it determines that the PNC setting table verification function is enabled, the higher-level ECU 10 proceeds to step S1070. If it determines that the PNC setting table verification function is disabled, the higher-level ECU 10 proceeds to step S1110. In step S1070, the higher-level ECU 10 checks the PNC setting values ​​of the PNC setting information associated with each lower-level ECU 14 through 19 in the PNC setting table of the received PNC setting table update information. Then, in step S1080, the higher-level ECU 10 determines whether all of the PNC setting values ​​associated with the lower-level ECU being checked are equal to "0". If all of the PNC setting values ​​are equal to "0", this means that the lower-level ECU being checked does not belong to any cluster. In this case, the lower-level ECU being checked cannot be woken up by the NM message containing the PN request information that determines the active cluster.For this reason, it should not happen that the correct PNC setting table update information is successfully received by the higher-level ECU 10, and all of the PNC setting values ​​for any one or more of the lower-level ECUs 14 to 19 are equal to "0". In other words, if all of the PNC setting values ​​of the PNC setting information associated with a particular lower-level ECU are equal to "0", this indicates that an abnormality has occurred in the reception of the PNC setting table update information.Therefore, if the higher-level ECU 10 determines that all PNC setting values ​​associated with the lower-level target ECU are equal to "0", it proceeds to step S1100 and transmits the receive error response to Cloud Server 40, indicating that the reception of the PNC setting table update information failed. If it determines that not all PNC setting values ​​associated with the lower-level target ECU are equal to "0", the higher-level ECU 10 proceeds to step S1090. As described, if the PNC setting information in the PNC setting table update information is such that at least one lower-level ECU 14 to 19 does not belong to any cluster, the higher-level ECU 10 transmits the receive error response to Cloud Server 40, thereby requesting Cloud Server 40 to retransmit the PNC setting table update information. Furthermore, the higher-level ECU 10 discards the PNC setting table update information in which the PNC setting information is set such that at least one lower-level ECU 14 to 19 does not belong to any cluster. In step S1090, the higher-level ECU 10 determines whether the verification of the PNC setting values ​​for all lower-level ECUs 14 to 19 is complete. If it determines that the verification of the PNC setting values ​​for all lower-level ECUs 14 to 19 is complete, the higher-level ECU 10 proceeds to step S1110. If it determines that the verification of the PNC setting values ​​for all lower-level ECUs 14 to 19 is incomplete, the higher-level ECU 10 returns to the process of step S1070. In step S1110, the higher-level ECU 10 transmits a receive completion response to the cloud server 40, indicating that the reception of the PNC settings table update information is complete, as shown in the sequence diagram in Fig. 13. In step S1120, the higher-level ECU 10 sets the value of the table update flag to "1", indicating that it is necessary to update the table, and terminates the PNC settings table receive process shown in the flowchart in Fig. 14. As described above, the higher-level ECU 10 sets the table update flag to "1" when the PNC setting table update information is received normally and stored in temporary memory. A table update flag of "1" indicates that it is necessary to update the PNC setting table. Therefore, the higher-level ECU 10 performs the PNC setting table update process described below to update the PNC setting table stored in non-volatile memory 10c using the PNC setting table information received.If the received PNC setting table update information is incomplete or contains a PNC setting information such that at least one lower-level ECU 14 to 19 does not belong to any cluster, the higher-level ECU 10 does not set the table update flag to "1". Therefore, an update of the PNC setting table stored in non-volatile memory 10c based on the PNC setting table in the PNC setting table update information is not performed. This prevents inappropriate updates to the PNC setting table stored in non-volatile memory 10c. As shown in the flowchart in Fig. 12 and the sequence diagram in Fig. 13, after completing the PNC setting table receive process, the higher-level ECU 10 next executes the PNC setting table update process in step S930. Fig. 15 is a flowchart showing an example of the details of the PNC setting table update process. The PNC setting table update process is described below with reference to the flowchart in Fig. 15. In step S1200, the higher-level ECU 10 determines whether the table update flag is set to "1", indicating that it is necessary to update the PNC settings table. If it determines that the table update flag is set to "1", the higher-level ECU 10 proceeds to step S1210. If it determines that the table update flag is not set to "1", the higher-level ECU 10 terminates the PNC table update process shown in the flowchart in Fig. 15. In step S1210, the higher-level ECU 10 determines whether the value of the PNC setting flag is set to "1" or not. If the value of the PNC setting flag is set to "1", this indicates to the lower-level ECUs 14 to 19 that it is necessary to update the PNC setting information. Therefore, it is possible that the higher-level ECU 10 performs the PNC setting process for the lower-level ECUs 14 to 19 based on the PNC setting table stored in non-volatile memory 10c. Accordingly, when the PNC setting table is updated, the PNC configuration process can be performed with the old and new PNC setting tables coexisting. Therefore, when the higher-level ECU 10 determines in step S1210 that the value of the PNC setting flag is set to “1”, it terminates the PNC setting table update process shown in the flowchart in Fig. 15.If it is determined in step S1210 that the value of the PNC setting flag is not set to "1", the ECU 10 proceeds to step S1220 at a higher level. In step S1220, the higher-level ECU 10 releases the masking process on the current PNC setting table stored in non-volatile memory 10c. In other words, assuming the value of the PNC setting flag is set to "0", the higher-level ECU 10 releases the masking process on the current PNC setting table. Therefore, the masking process on the current PNC setting table stored in non-volatile memory 10c is maintained as long as the PNC setting flag is set to "1", specifically while the higher-level ECU 10 configures (modifies) the PNC setting information of the first through sixth lower-level ECUs 14 through 19 based on the PNC setting table stored in non-volatile memory 10c. Then, in step S1230, the higher-level ECU 10 updates the PNC setting table by overwriting the current PNC setting table, stored in non-volatile memory 10c, with the PNC setting table update information stored in temporary memory. In the preceding step, the higher-level ECU 10 can write the PNC setting table update information to a memory area separate from the non-volatile memory 10c containing the current PNC setting table. In this case, the higher-level ECU 10 must identify which PNC setting table is the most recent. In step S1240, the higher-level ECU 10 sets the value of the table update flag to "0" because the PNC setting table update is complete. In step S1250, the higher-level ECU 10 sets the value of the table update flag to "1". This step is provided because, as the PNC setting table is updated, it is necessary to reconfigure the PNC setting information of the first through sixth lower-level ECUs 14 through 19 based on the updated PNC setting table. As described, in response to a PNC setting table update, the present embodiment modifies the PNC setting information of the first through sixth lower-level ECUs 14 through 19 based on the updated PNC setting table. Afterwards, the higher-level ECU 10 completes the PNC setting table update process shown in the flowchart of Fig. 15. Next, various processes performed in the first to sixth ECUs (14 to 19) at the lower level with regard to network management are described with reference to the flowcharts in Figures 16, 17, 18 to 19. The first to sixth ECUs (14 to 19) at the lower level execute the processes described below individually. The flowchart in Fig. 16 shows an example of the main process routine that is executed in each of the first six ECUs (14 to 19) at the lower level. The main process routine executed in the first ECU (14) at the lower level is described below as a representative example. When a power supply is activated, the first ECU (14) at the lower level starts the main process routine shown in the flowchart in Fig. 16. In step S1300, the first lower-level ECU 14 performs an initialization process. This initialization process includes, for example, a hardware initialization and a storage medium operation check. In step S1310, the first lower-level ECU 14 determines whether or not a wake-up factor has occurred for the first lower-level ECU 14. For example, the first lower-level ECU 14 can determine that the wake-up factor has occurred upon: receiving a signal indicating a need to wake up (trigger signal, toggle signal, sensor signal, etc.); receiving the NM message containing the PN request information that designates the cluster to which the first lower-level ECU 14 belongs as the active cluster; or receiving the NM message containing the command that instructs all lower-level ECUs 14 through 19 to wake up.If step S1310 determines that the wake-up factor has not occurred, the first lower-level ECU 14 proceeds to step S1320 to enter sleep mode. If step S1330 determines that the wake-up factor has occurred, the first lower-level ECU 14 proceeds to step S1330. In step S1330, the first lower-level ECU 14 executes the activation process. This process includes, for example, reading software containing an operating system (OS) and a program from memory or data storage and writing the read software to memory or main memory. In step S1340, while executing this process, the first lower-level ECU 14 periodically transmits the NM message containing the active cluster information, which identifies the cluster to which the first lower-level ECU 14 belongs as the active cluster. Also in step S1340, the first lower-level ECU 14 receives messages containing the NM message transmitted by other ECUs containing the higher-level ECU 10, as well as various command messages transmitted by the higher-level ECU 10. In step S1350, the first lower-level ECU 14 determines whether it has received the command message from the higher-level ECU 10. Examples of the command message include at least the (first) PNC setting value verification request message, the (second) PNC setting value verification request message, the (first) PNC setting request message, and the (second) PNC setting request message. If it determines that the command message has been received, the first lower-level ECU 14 proceeds to step S1360. If it determines that the command message has not been received, the first lower-level ECU 14 proceeds to step S1440. In step S1360, the first lower-level ECU 14 determines whether the received command message is the (initial) PNC setting value verification request message or not. If it determines that the received command message is the (initial) PNC setting value verification request message, the first lower-level ECU 14 proceeds to step S1370. If it determines that the received command message is not the (initial) PNC setting value verification request message, the first lower-level ECU 14 proceeds to step S1380. In step S1370, the first lower-level ECU 14 executes the (initial) PNC setting value verification response process. Specifically, the first lower-level ECU 14 generates the (initial) PNC setting value verification response message, which contains the first half of the PNC setting values ​​of the PNC setting information (i.e., the PNC setting information set for the first lower-level ECU 14), and transmits the (initial) PNC setting value verification response message to the higher-level ECU 10. Afterward, the first lower-level ECU 14 proceeds to step S1440. In step S1380, the first lower-level ECU 14 determines whether the received command message is the (second) PNC setting value verification request message or not. If it determines that the received command message is the (second) PNC setting value verification request message, the first lower-level ECU 14 proceeds to step S1390. If it determines that the received command message is not the (second) PNC setting value verification request message, the first lower-level ECU 14 proceeds to step S1400. In step S1390, the first lower-level ECU 14 executes the (second) PNC setting value verification response process. Specifically, the first lower-level ECU 14 generates the (second) PNC setting value verification response message, which contains the last half of the PNC setting values ​​from the PNC setting information, and transmits the (second) PNC setting value verification response message to the higher-level ECU 10. Afterward, the first lower-level ECU 14 proceeds to step S1440. In step S1400, the first lower-level ECU 14 determines whether the received command message is the (initial) PNC setting request message or not. If it determines that the received command message is the (initial) PNC setting request message, the first lower-level ECU 14 proceeds to step S1410. If it determines that the received command message is not the (initial) PNC setting request message, the first lower-level ECU 14 proceeds to step S1420. In step S1410, the first lower-level ECU 14 executes the (initial) PNC setting response process. This (initial) PNC setting response process will be described in detail later. Afterwards, the first lower-level ECU 14 proceeds to step S1440. In step S1420, the first lower-level ECU 14 determines whether the received command message is the (second) PNC setting request message or not. If it determines that the received command message is the (second) PNC setting request message, the first lower-level ECU 14 proceeds to step S1430. If it determines that the received command message is not the (second) PNC setting request message, the first lower-level ECU 14 proceeds to step S1440. In step S1430, the first lower-level ECU 14 executes the (second) PNC setting response process. This (second) PNC setting response process will be described in detail later. Afterwards, the first lower-level ECU 14 proceeds to step S1440. In step S1440, the first lower-level ECU 14 performs a setting status verification process to check whether the PNC setting values ​​are appropriate based on the PNC setting information. This setting status verification process is described in detail later. The setting status verification process can be performed after the PNC setting information has been modified by the higher-level ECU 10. For example, the setting status verification process can be performed after a certain time has elapsed since the (initial) PNC setting request message was received by the higher-level ECU 10, where this certain time is the time required for the first lower-level ECU 14 to complete the PNC setting based on the receipt of the (second) PNC setting request message.Alternatively, the setting status verification process can be performed in response to a determination that a condition for entering sleep mode is met, in step S1450, which is described below. In step S1450, the first lower-level ECU 14 determines whether the condition for entering sleep mode is met. For example, if the first lower-level ECU 14 enters wake-up mode, it executes the given process assigned to it. When the execution of this process is complete and the time during which the NM message containing the PN request information (identifying the cluster to which the first lower-level ECU 14 belongs as the active cluster) is not received reaches the specified time, the first lower-level ECU 14 can determine that the condition for entering sleep mode is met. Upon determining that the condition for entering sleep mode is met, the first lower-level ECU 14 proceeds to step S1460.If it is determined that the condition for transitioning to sleep mode is not met, the first lower-level ECU 14 returns to the process of step S1340. In step S1460, the first lower-level ECU 14 determines whether the power is switched off or not. If it determines that the power is switched off, the first lower-level ECU 14 terminates the main process routine, which can be seen in the flowchart in Fig. 16. If it determines that the power is not switched off, the first lower-level ECU 14 returns to the process from step S1310. Next, the (initial) PNC setup response process in step S1410 of the flowchart in Fig. 16, which is one of the subroutines of the main process routine in Fig. 16, is described in detail. Fig. 17 is a flowchart showing an example of the details of the (initial) PNC setup response process. In step S1500, the first lower-level ECU 14 stores the (initial) PNC setting information (i.e., the first half of the PNC setting values ​​contained in the received (initial) PNC setting request message) in volatile memory 25, which is the temporary memory. In step S1510, the first lower-level ECU 14 transmits the (initial) PNC setting response message to the higher-level ECU 10. When the higher-level ECU 10 receives this (initial) PNC setting response message, it then transmits the (second) PNC setting request message, containing the second PNC setting values ​​(i.e., the last half of the PNC setting values), to the first lower-level ECU 14. In step S1520, the first lower-level ECU 14 determines whether the PNC setting value to be received by the higher-level ECU 10, but not yet received, is present or not. For example, if the higher-level ECU 10 cannot transmit all of the PNC setting values ​​in a single message due to a large number of clusters, the first lower-level ECU 14 may determine that the PNC setting value to be received is still present. If it determines that the PNC setting value to be received is still present, the first lower-level ECU 14 proceeds to step S1530. If it determines that the PNC setting value to be received is not present, the first lower-level ECU 14 proceeds to step S1540. In step S1530, the first lower-level ECU 14 sets the value of the setting status flag to "0". The "0" of the setting status flag indicates that the change to the PNC setting information is not yet complete, as the last half of the PNC setting values ​​has not yet been received; that is, not all of the PNC setting values ​​necessary to change the PNC setting information have been received. Afterward, the first lower-level ECU 14 completes the (initial) PNC response process, which can be seen in the flowchart in Fig. 17. In step S1540, the first lower-level ECU 14 sets the value of the configuration status flag to "1". The "1" of the configuration status flag indicates the state in which the change to the PNC configuration information is complete, as all of the PNC configuration values ​​necessary to change the PNC configuration information have been received. In step S1550, the first lower-level ECU 14 determines whether PNC setting value matching is enabled or not. Whether PNC setting value matching is enabled or disabled in the first lower-level ECU 14 can be configured in advance, for example, by a manufacturer, a vendor, or a user of the vehicle network system 100. If it determines that PNC setting value matching is enabled, the first lower-level ECU 14 proceeds to step S1560. If it determines that PNC setting value matching is disabled, the first lower-level ECU 14 proceeds to step S1580. In step S1560, the first lower-level ECU 14 checks whether there is a perfect match between the PNC setting values ​​of the PNC setting information stored in volatile memory 25 (the temporary memory) and the PNC setting values ​​of the current PNC setting information stored in non-volatile memory 26. Then, in step S1570, the first lower-level ECU 14 determines whether the match result is a perfect match between the two. If a perfect match is determined, the first lower-level ECU 14 terminates the (initial) PNC setting response process, as shown in the flowchart in Fig. 17.More specifically, in the case of a perfect match, the process of updating the PNC setting information by writing the PNC setting information stored in volatile memory 25 to non-volatile memory 26 is not performed by the first lower-level ECU 14. This can reduce the number of overwrite operations of non-volatile memory 26. If it is determined that the result is not a perfect match, the first lower-level ECU 14 proceeds to step S1580. In step S1580, the first lower-level ECU 14 performs the process of updating the PNC setting information by writing the PNC setting information stored in volatile memory 25 to non-volatile memory 26. Afterwards, the first lower-level ECU 14 completes the (initial) PNC response process, which can be seen in the flowchart in Fig. 17. Next, the (initial) PNC setup response process in step S1430 of the flowchart in Fig. 16, which is one of the subroutines of the main process routine in Fig. 16, is described in detail. Fig. 18 is a flowchart showing the details of the (initial) PNC setup response process. In step S1600, the first lower-level ECU 14 determines whether the setting status flag value is set to "1" or not. If it determines that the setting status flag value is set to "1", the first lower-level ECU 14 terminates the (second) PNC setting response process, as shown in the flowchart in Fig. 18, since it is not necessary to respond to the (second) PNC setting request message. If it determines that the setting status flag value is not set to "1", the first lower-level ECU 14 proceeds to step S1610. In step S1610, the first lower-level ECU 14 stores the (secondary) PNC setting information (i.e., the last half of the PNC setting values ​​contained in the received (secondary) PNC setting request message) in the volatile memory 25, which is the temporary memory. In step S1620, the first lower-level ECU 14 transmits a (secondary) PNC setting response message to the higher-level ECU 10. When the higher-level ECU 10 receives this (secondary) PNC setting response message, it switches the lower-level ECU, which is the target of the PNC setting process, as shown in the sequence diagram in Fig. 9. Then, after receiving the (second) PNC setting response message, all ECUs 14 to 19 at lower levels execute the PNC setting completion process. In step S1630, the first lower-level ECU 14 sets the value of the setting status flag to "1". This is because, due to receiving the PNC setting information twice, the first lower-level ECU 14 has already received all the PNC setting values ​​necessary to change the PNC setting information and is in a state where the change to the PNC setting information is complete. In step S1640, the first lower-level ECU 14 determines whether PNC setting value matching is enabled or not. If it determines that PNC setting value matching is enabled, the first lower-level ECU 14 proceeds to step S1650. If it determines that PNC setting value matching is disabled, the first lower-level ECU 14 proceeds to step S1670. In step S1650, the first lower-level ECU 14 checks whether there is a perfect match between the PNC setting values ​​of the PNC setting information stored in volatile memory 25 (the temporary memory) and the PNC setting values ​​of the current PNC setting information stored in non-volatile memory 26. Then, in step S1660, the first lower-level ECU 14 determines whether the match result is a perfect match between the two. If a perfect match is determined, the first lower-level ECU 14 terminates the (initial) PNC setting response process, as shown in the flowchart in Fig. 18. If the result is determined not to be a perfect match, the first lower-level ECU 14 proceeds to step S1670. In step S1670, the first lower-level ECU 14 performs the process of updating the PNC setting information by writing the PNC setting information for the first and second times, which is stored in volatile memory 25, to non-volatile memory 26. Afterwards, the first lower-level ECU 14 completes the (first-time) PNC response process, which can be seen in the flowchart in Fig. 18. Next, the hiring status verification process in step S1440 of the flowchart in Fig. 16, which is one of the subroutines of the main process routine in Fig. 16, is described in detail. Fig. 19 is a flowchart showing an example of the details of the hiring status verification process. In step S1710, the first lower-level ECU 14 refers to the value of the setting status flag. Then, in step S1720, the first lower-level ECU 14 determines whether the value of the setting status flag is "0" or not. For example, if the value of the setting status flag is "0" after a certain time has elapsed since the (first) PNC setting request message was received by the higher-level ECU 10, this indicates that not all of the PNC setting values ​​necessary to change the PNC setting information have been received. This "certain time" is the time required for the first lower-level ECU 14 to complete the PNC setting based on receiving the (second) PNC setting request message.In this case, it is possible to consider that the PNC setting (PNC configuration) has not been performed and the PNC setting values ​​are unsuitable. Therefore, if step S1720 determines that the setting status flag value is "0", the first lower-level ECU 14 proceeds to step S1750. If it determines that the setting status flag value is not "0", the first lower-level ECU 14 proceeds to step S1730. In step S1730, the first lower-level ECU 14 refers to its PNC setting information. Then, in step S1740, the first lower-level ECU 14 determines whether all of the PNC setting values ​​in the PNC setting information are equal to "0". If all of the PNC setting values ​​are equal to "0", this indicates that the first lower-level ECU 14 does not belong to any cluster. In this case, the first lower-level ECU 14 cannot be woken up by the NM message containing the PN request information that determines the active cluster. For this reason, PNC setting values ​​that are all equal to "0" cannot be considered suitable. Therefore, if step S1740 determines that all of the PNC setting values ​​are equal to "0", the first lower-level ECU 14 proceeds to step S1750.If it is determined that not all of the PNC setting values ​​are equal to “0”, the first lower-level ECU 14 terminates the setting status verification process shown in the flowchart in Fig. 19 and returns to the process in the flowchart in Fig. 16. In step S1750, the first lower-level ECU 14 rewrites all PNC setting values ​​in its PNC setting information back to "1". Specifically, if the first lower-level ECU 14 determines that its PNC setting information is not appropriate, it modifies this information so that it belongs to all clusters. This changes the activation condition, allowing the first lower-level ECU 14 to be woken up by any NM message containing the PN request information that designates at least one cluster as the active cluster. Therefore, it is possible to prevent a situation where the first lower-level ECU 14 cannot be activated by the NM message. In step S1760, the first lower-level ECU 14 transmits the PNC setting request message to the higher-level ECU 10. As mentioned above, if the first lower-level ECU 14 changes its activation condition, it will wake up due to any NM message. In this case, the first lower-level ECU 14 wakes up at a time when it should not. By transmitting the PNC setting request message, the higher-level ECU 10 can reconfigure the PNC setting information of the first lower-level ECU 14 to the appropriate PNC setting information. As a result, power consumption can be reduced by preventing the first lower-level ECU 14 from waking up unnecessarily. Modifications Preferred embodiments of the present disclosure have been described above. The present disclosure is not limited to the embodiments described above and can be implemented by various modifications without deviating from the meaning and scope of the present disclosure. First modification In the foregoing embodiments, if the PNC setting information is not adequate, the first to sixth lower-level ECUs 14 to 19 overwrite or rewrite all PNC setting values ​​of the configured PNC setting information to "1" as a change in the activation condition by the activation condition change unit 27. However, the change in the activation condition is not limited to overwriting or rewriting the PNC setting values. For example, if it is determined that the PNC setting information is not adequate, the activation condition change unit 27 of the first to sixth ECUs 14 to 19 at the lower level can change the activation condition so that the first to sixth ECUs 14 to 19 at the lower level wake up in response to the received message, which has a given signal strength or level. In particular, as can be seen in Fig. 20, the activation condition change unit 27 can change the activation condition so that the first to sixth ECUs 14 to 19 at the lower level wake up in response to the communication interface, which detects that the strength or level of the message being transmitted and received over the communication bus 20 to 22 has become dominant. Since the message always has a dominant strength signal or level,If a level signal is present, it is possible to change the activation condition so that the first to sixth ECU 14 to 19 lower levels wake up in response to any message. Alternatively, if it is determined that the PNC setting information is not adequate, the activation condition change unit 27 can change the activation condition so that the first to sixth lower-level ECUs 14 to 19 wake up in response to a message containing a given signal pattern. Specifically, as shown in Fig. 21, the activation condition can be changed so that the first to sixth lower-level ECUs 14 to 19 wake up in response to the communication interface detecting a change from recessive to dominant twice in succession, a signal pattern that is always present in the message transmitted and received over the communication bus 20 to 22. In the case of the above change in the activation condition, it is also possible to wake up the first to sixth ECUs by any message. Second modification The hiring status verification process shown in the flowchart in Fig. 19 can be modified to the one shown in the flowchart in Fig. 22. The hiring status verification process shown in the flowchart in Fig. 22 also includes steps S1705 and S1755, compared to the hiring status verification process shown in the flowchart in Fig. 19. Step S1705 determines whether a PNC non-setting flag value is "1" or not. Step S1755 sets the PNC non-setting flag to "1". Specifically, step S1755 sets the PNC non-setting flag to "1" after step S1750 has rewritten all PNC setting values ​​back to "1". Step S1590 sets the PNC non-setting flag to "0" in response to a write of the PNC setting values ​​stored in temporary memory to non-volatile memory 26, so that all PNC setting values ​​that have been rewritten back to "1" are updated, as shown in the flowchart in Fig. 23.Although not shown in the drawings, the (second) PNC setting response process similarly includes setting the PNC non-setting flag to "0" in response to an update of the PNC setting values ​​stored in non-volatile memory 26 by using the PNC setting value stored in temporary memory. Specifically, after the activation condition has changed, the PNC non-setting flag is set to "1" within a time interval during which the PNC setting information is not updated by the higher-level cluster manager unit 10a of the ECU 10. The PNC non-setting flag becomes "0" when the PNC setting information is updated by the cluster manager unit 10a. In the present modification, as shown in the flowchart in Fig. 22, if step S1705 determines that the value of the PNC non-setting flag is equal to "1", the process jumps to step S1760 to execute the process of transmitting the PNC setting request to the higher-level ECU 10. Therefore, the first through sixth lower-level ECUs 14 through 19 can repeatedly transmit the PNC setting request message until the cluster manager unit 10a updates the PNC setting information. Third modification The systems and methods described in this disclosure can be implemented by a special-purpose computer containing a processor programmed to perform one or more functions embodied by a computer program. The systems and methods described in this disclosure can be implemented using a dedicated hardware logic circuit. The systems and methods described in this disclosure can be implemented by one or more special-purpose computers configured with a combination of a processor executing a computer program and one or more hardware logic circuits.For example, some or all of the functions provided by the higher-level ECU 10, the first to third GW-ECUs 11 to 13, and the first to sixth ECUs 14 to 19 at the lower level can be implemented in hardware. A configuration in which a particular function is implemented by a hardware logic circuit includes a configuration in which the function is implemented using one or more ICs or the like. Some or all of the functions provided by the higher-level ECU 10, the first to third GW-ECUs 11 and 13, and the first to sixth ECUs 14 to 19 at the lower level can be implemented using a system-on-a-chip (SoC), an integrated circuit (IC), or a field-programmable gate array (FPGA). The concept of an IC includes an ASIC (application-specific integrated circuit).The computer program described above can be stored in a computer-readable, non-volatile, tangible storage medium as instructions to be executed by a computer. A hard disk drive (HDD), a solid-state drive (SSD), flash memory, or the like can be used as a storage medium that stores the computer program. The present disclosure includes programs that cause computers to function as the higher-level ECU 10, the first to third GW-ECUs 11 to 13, and the first to sixth ECUs 14 to 19 of the lower level, and non-volatile tangible storage media, such as semiconductor memory, that store the programs. Revelation of the technical idea This specification discloses several technical ideas, which are described in several elements listed below. An element may be described in a multiply dependent form, referring to more than one preceding element in an alternative form. Furthermore, an element may be described in a multiply-multiply dependent form, referring to several elements that contain an element in the multiply dependent form. The element in the multiply dependent form defines several technical ideas. Additionally, the technical ideas described in the following paragraphs are applicable to a control method of a vehicle network system and a manager control device applied to a vehicle network system. Technical Idea 1 A vehicle network system mounted on a vehicle has a variety of control devices that can communicate with each other.The plurality of control devices includes: a management target control device (14 to 19) that holds cluster information specifying a cluster to which the management target control device belongs, among a plurality of clusters, which are subdivisions, and which enters an active state in response to an activation message from another control device containing active cluster information indicating that the cluster corresponding to the cluster specified by the cluster information is active; and a manager control device (10) that includes a storage medium (10c) that stores cluster setting information for configuring the cluster information of the management target control device and has a function for configuring the cluster information of the management target control device based on the stored cluster setting information.The manager control device is capable of receiving cluster setting update information from an external device. When the cluster setting update information is received, the manager control device stores the updated cluster setting information in a storage medium (10b) separate from the storage medium that stores the cluster setting information, or in a memory area separate from a memory area that stores the cluster setting information. Technical Idea 2 In the vehicle network system according to technical idea 1, when the cluster setting information is received and stored for updating, the manager control device updates the stored cluster setting information based on the cluster setting information for updating. Technical Idea 3 In the vehicle network system according to technical idea 2 in response to an update of the cluster setting information, the manager control device modifies the cluster information held by the management target control device based on the updated cluster setting information. Technical Idea 4 In the vehicle network system according to technical idea 2 or 3: the manager control device verifies whether a setting in the stored cluster setting information for updating with respect to the cluster information of the management target control device is such that the management target control device belongs to at least one cluster or not; and if the setting in the stored cluster setting information for updating with respect to the cluster information of the management target control device is such that the management target control device does not belong to any of the clusters, the manager control device does not perform an update of the stored cluster setting information based on the cluster setting information for updating. Technical Idea 5 In the vehicle network system according to technical idea 4, the manager control device discards the cluster setting information for updating if the setting regarding the cluster information of the manager target control device is such that the manager target control device does not belong to any of the clusters. Technical Idea 6 In the vehicle network system according to technical idea 4 or 5, if the setting in the cluster setting information for updating with respect to the cluster information of the manager target control device is such that the manager target control device does not belong to any of the clusters, the manager control device requests from the external device to retransmit the cluster setting information for updating. Technical Idea 7 In the vehicle network system according to one of technical ideas 1 to 6, when the cluster setting information is received and stored for updating, the manager control device masks a memory area that stores the cluster setting information so that the memory area is not overwritten. Technical Idea 8 In the vehicle network system according to one of technical ideas 1 to 7, the manager control device masks a memory area that stores the cluster setting information, so that the memory area is not overwritten while the cluster information of the manager target control device is changed based on the cluster setting information. Technical Idea 9 In the vehicle network system according to one of technical ideas 1 to 8, the cluster setting information of a variety of types can be stored in the manager control device; and the external device issues instructions to the manager control device regarding the cluster setting information to be activated from among the cluster setting information of the variety of types. Technical Idea 10 In the vehicle network system according to technical idea 9, when the activated cluster setting information is changed via instructions from the external device, the manager control device changes the cluster information held by the management target control device based on the newly activated cluster setting information. Technical Idea 11 In the vehicle network system according to one of technical ideas 1 to 10: the cluster setting information of a variety of types is storable in the manager control device; the cluster setting information of the variety of types contains cluster setting information for vehicle evacuation runs; and when it is necessary for the vehicle to perform an evacuation run, the manager control device modifies the cluster information held by the management target control device based on the cluster setting information for vehicle evacuation runs. Technical Idea 12 In the vehicle network system according to one of technical ideas 1 to 11, the storage medium in the manager control device that stores the cluster setting information is a non-volatile storage medium. QUOTES INCLUDED IN THE DESCRIPTION This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature JP 2024-64428A [0002, 0004]

Images