In-vehicle network system, management method for in-vehicle network system, and computer program product

Abstract

The invention discloses an in-vehicle network system, a management method of the in-vehicle network system, and a computer program product. A plurality of lower ECUs have cluster information to which the lower ECUs belong. If the cluster included in the boot cluster information included in the received NM message matches the cluster of the lower ECU, the lower ECU is in a boot state or maintains the boot state. The cluster information of the lower ECU can be rewritten. However, when rewriting of the cluster information is requested, the upper ECU determines, as an appropriate rewriting request, a rewriting request within a rewritable range of the cluster information, said rewriting request being determined on the basis of the attribute of the rewriting request source. Then, the upper ECU rewrites the cluster information in accordance with the rewrite request determined to be appropriate.

Description

Technical Field

[0001] This disclosure relates to an in-vehicle network system having multiple control devices connected to a communication bus in a vehicle and capable of communicating with each other, and a method for managing the in-vehicle network system. Background Technology

[0002] For example, Patent Document 1 discloses an in-vehicle network system comprising a host ECU, an intermediate ECU, and a lower-level ECU. In the in-vehicle network system of Patent Document 1, the intermediate ECU is powered by a power source and, based on a message received from the host ECU, supplies power from the power source to the lower-level ECU. That is, the intermediate ECU keeps the lower-level ECU in a power-off state until it receives a message from the host ECU. Corresponding to the intermediate ECU receiving a message from the host ECU, the lower-level ECU is powered by the power source. Through this power supply, the lower-level ECU transitions from a power-off state to a standby state awaiting instruction.

[0003] Existing technical documents

[0004] Patent documents

[0005] Patent Document 1: Japanese Patent No. 7238650 Summary of the Invention

[0006] As described in Patent Document 1, in conventional vehicle network systems, a specific ECU (e.g., an intermediate ECU) manages the status of other ECUs (e.g., lower-level ECUs).

[0007] In recent years, after a vehicle is sold and circulated in the market, for example, vehicle owners can update the software of the vehicle's ECU (Electronic Control Unit) by downloading any application. In this case, the updated ECU, depending on the function of the downloaded application, may not only activate when the conditions set before the update are met, or instead of activating when the conditions set before the update are met, it may also require activation when other conditions are met.

[0008] However, in the vehicle network system described in Patent Document 1, the relationship between other ECUs and a specific ECU that manages the state of other ECUs is fixed, making it very difficult to flexibly respond to changes in the ECU's activation conditions. On the other hand, if changes to the ECU's activation conditions are allowed without restriction, and inappropriate changes are made to important vehicle functions, the ECU may fail to activate when it should, posing a risk that it cannot perform the required functions in the vehicle.

[0009] This disclosure is made in view of the above points, and its purpose is to provide an in-vehicle network system and a method for managing the in-vehicle network system, which can flexibly respond to the addition or change of the start conditions of the control device, and can prevent inappropriate changes to the start conditions of the control device regarding important functions of the vehicle.

[0010] To achieve the above objectives, the in-vehicle network system of this disclosure has multiple control devices in the vehicle that are connected to a communication bus and capable of communicating with each other, wherein,

[0011] Multiple control devices each possess cluster information indicating the cluster to which they belong within a group of clusters. If a control device receives network management messages from other control devices containing startup cluster information that matches the cluster information, indicating the cluster to be started, then it enters a startup state or remains in a startup state.

[0012] The in-vehicle network system has the following features:

[0013] The determination unit, when requesting the modification of cluster information from at least one of a plurality of control devices, determines that a modification request within the scope of the reproducible cluster information, based on the attributes of the modification request source, is an appropriate modification request; and

[0014] The rewriting department executes the rewriting of cluster information according to the appropriate rewriting request determined by the decision-making department.

[0015] Furthermore, the vehicle network system management method disclosed herein is a management method for a vehicle network system having multiple control devices connected to a communication bus in the vehicle and capable of communicating with each other.

[0016] Multiple control devices each possess cluster information indicating the cluster to which they belong within a group of clusters. If a control device receives network management messages from other control devices containing startup cluster information that matches the cluster information, indicating the cluster to be started, then it enters a startup state or remains in a startup state.

[0017] The management methods for in-vehicle network systems include the following procedures:

[0018] In the event that at least one of a plurality of control devices requests modification of cluster information, modification requests within the scope of reproducible cluster information, determined based on the attributes of the modification request source, are deemed appropriate modification requests; and

[0019] Perform cluster information rewriting according to the determined appropriate rewriting request.

[0020] In the vehicular network system and its management method disclosed herein, multiple control devices each have cluster information indicating which cluster they belong to among multiple clusters. Each control device is configured such that if a network management message sent from another control device contains startup cluster information indicating a cluster to be started that is consistent with the cluster information, then it enters a startup state or remains in a startup state.

[0021] Furthermore, according to the vehicle network system and management method of this disclosure, the cluster information of each of the multiple control devices can be rewritten. Therefore, the multiple control devices can flexibly respond to the addition or change of activation conditions.

[0022] Furthermore, according to the vehicular network system and the management method of the vehicular network system disclosed herein, when a request is made to rewrite cluster information, a rewrite request within the scope of the rewriteable cluster information determined by the attributes of the rewrite request source is deemed an appropriate rewrite request.

[0023] The cluster information is rewritten based on the rewrite request that is deemed appropriate.

[0024] In the vehicular network system and its management method disclosed herein, cluster information is rewritten only to the extent that the cluster information is rewriteable, as determined by the attributes of the rewrite request source. Therefore, regarding critical vehicle functions, changes to cluster information related to the addition or alteration of inappropriate activation conditions of the control device can be prevented as much as possible. Attached Figure Description

[0025] Figure 1 This is a configuration diagram illustrating an example of the configuration of an in-vehicle network system according to an implementation method.

[0026] Figure 2 This is an illustrative diagram illustrating an example of a method for implementing a local network that enables some lower-level ECUs to enter a startup state and others to enter a sleep state based on NM messages and PNC setting information.

[0027] Figure 3 This is a flowchart illustrating the process of adding or changing the startup conditions of lower-level ECUs in an in-vehicle network system.

[0028] Figure 4 This is a diagram illustrating an example of the scope of PNC setting information changes corresponding to the attributes of the PNC setting information change request source.

[0029] Figure 5 This diagram shows an example of the PNC settings information before the change, set in any of the lower-level ECUs.

[0030] Figure 6 It means that it is for those who have Figure 5 The diagram shows an example of PNC setting information included in a PNC change request for any of the lower-level ECUs.

[0031] Figure 7 It means based on Figure 5 PNC settings information before the change and Figure 6 The diagram shows the changed PNC settings information obtained from the change request.

[0032] Figure 8 This is a flowchart illustrating an example of a process for changing the modifiable range of PNC setting information. Detailed Implementation

[0033] Hereinafter, embodiments of the in-vehicle network system and the management method of the in-vehicle network system of this disclosure will be described with reference to the accompanying drawings. However, this disclosure is not limited to the following embodiments, and various modifications described below are also included within the technical scope of this disclosure. Furthermore, in addition to the following, various modifications can be made to implement the system without departing from the spirit of this disclosure. The embodiments and various modifications can be appropriately combined to implement the system without creating technical contradictions. In the following description, for the same or similar configurations, descriptions are sometimes omitted by referring to the same reference numerals in multiple drawings. In addition, when only a part of the configuration is mentioned, descriptions described in other parts can be applied to other parts.

[0034] (First Implementation)

[0035] Figure 1 This is a configuration diagram illustrating an example of the configuration of the vehicle network system 100 according to this embodiment. For example... Figure 1As shown, the vehicle network system 100 includes a higher-level ECU 10 and lower-level ECUs 11 to 16. Furthermore, ECU is short for Electronic Control Unit. The higher-level ECU 10, for example, can function as a domain controller that oversees the control of the lower-level ECUs 11 to 16. A domain refers to a functional unit that broadly divides the functions of a vehicle, such as a powertrain domain, chassis domain, advanced driver assistance domain, body domain, or cabin domain. For example, if the controller for the powertrain domain is the higher-level ECU 10, the lower-level ECUs include various ECUs used to control the vehicle's powertrain, such as the engine ECU, motor (inverter) ECU, battery monitoring ECU, and transmission ECU. Similarly, if the controller for the chassis domain is the higher-level ECU 10, the lower-level ECUs include various ECUs used for chassis control, such as the steering ECU, brake ECU, and suspension ECU.

[0036] The foregoing is one example of domain differentiation, but domain differentiation can also differ from the foregoing example. Furthermore, the higher-level ECU 10 can also be a region controller that centrally manages the lower-level ECUs 11-16 configured in each region of the vehicle. Moreover, in Figure 1 The diagram illustrates an example of an in-vehicle network system 100 having a host ECU 10, but the in-vehicle network system 100 can also be configured to have multiple host ECUs connected to each other in a manner that enables them to communicate with each other. In this case, each host ECU can also be connected to each other in a manner that enables them to communicate with each other, for example, via a gateway ECU.

[0037] The vehicle network system 100 can use CAN (registered trademark, hereinafter the same) as a communication protocol. CAN is short for Controller Area Network. However, the communication protocol is not limited to CAN; the vehicle network system 100 can also use other communication protocols such as CAN-FD (CAN with Flexible Data Rate). However, in this embodiment, the vehicle network system 100 is configured to implement so-called network management, which switches between the normal operating mode (start-up state) and power-saving mode (sleep state) of the lower-level ECUs 11-16 according to each group (referred to as a cluster) containing at least one lower-level ECU 11-16. Therefore, the communication protocol used by the vehicle network system 100 needs to correspond to the network management.

[0038] exist Figure 1 In the example shown, the upper-level ECU 10 is connected to a first communication bus 17, a second communication bus 18, and a third communication bus 19. Thus, in... Figure 1The example shown is that the upper ECU10 is connected to three communication buses 17-19, but the number of communication buses connected to the upper ECU10 can be less than two or more than four.

[0039] exist Figure 1 In this configuration, lower-level ECUs 11 and 12 are connected to the first communication bus 17. Lower-level ECUs 13 and 14 are connected to the second communication bus 18. Lower-level ECUs 15 and 16 are connected to the third communication bus 19. Furthermore, the number of lower-level ECUs 11 to 16 connected to each of the communication buses 17 to 19 can be one or more.

[0040] Each of the lower-level ECUs 11 to 16 is, for example, a control ECU used in the vehicle to control a predetermined controlled object, or a sensor ECU that calculates a predetermined physical quantity based on a detection signal detected by a sensor. When it is necessary to control the controlled object or to calculate a predetermined physical quantity based on a sensor's detection signal, each of the lower-level ECUs 11 to 16 becomes active in normal operating mode and performs normal operations. On the other hand, when it is not necessary, each of the lower-level ECUs 11 to 16 becomes sleep-mode in power-saving mode.

[0041] For this switching between startup and sleep states, each lower-level ECU 11-16 has cluster information (also known as PNC setting information) indicating the cluster it belongs to within a plurality of clusters. PNC setting information is used to group multiple lower-level ECUs 11-16 that need to be in a startup state simultaneously when implementing at least one desired function in the vehicle. PNC setting information will be described in detail later. Furthermore, PNC is short for Partial Networking Clustering.

[0042] The upper-level ECU 10, for example, acts as a domain controller, overseeing the control of the lower-level ECUs 11-16. Furthermore, the upper-level ECU 10 can control the switching between the start and sleep states of the lower-level ECUs 11-16. Specifically, the upper-level ECU 10 determines the function to be executed in the vehicle, and when the desired function needs to be executed, switches the lower-level ECUs 11-16 that need to be in the start state simultaneously to the start state. This switching to the start state can be performed by the upper-level ECU 10 generating a network management message (hereinafter referred to as an NM message) containing start cluster information (also called PN request information) that designates a group of lower-level ECUs 11-16 that need to be in the start state simultaneously as the start cluster, and sending it via each communication bus 17-19. Alternatively, the function of determining the function to be executed in the vehicle and sending an NM message containing PN request information may not be possessed by the upper-level ECU 10, but by any of the lower-level ECUs 11-16. Furthermore, when a vehicle has multiple upper-level ECUs and multiple lower-level ECUs subordinate to each upper-level ECU, NM messages can also be sent from other upper-level ECUs and lower-level ECUs.

[0043] Furthermore, the upper-level ECU 10 performs processing for relaying messages between the lower-level ECUs 11-16 connected to each of the communication buses 17-19. During normal operation in the startup state, each lower-level ECU 11-16 sends messages for cooperative control with other lower-level ECUs 11-16, or sends an NM message indicating that it is in the startup state. These messages can be relayed via the upper-level ECU 10 to other lower-level ECUs 11-16 connected to the communication buses 17-19. Additionally, the upper-level ECU 10 can also enter a sleep state when all lower-level ECUs 11-16 belonging to all clusters are in a sleep state.

[0044] Any ECU belonging to the vehicle network system 100 has an external communication unit 20 capable of wirelessly communicating with external servers such as the data center 30. Figure 1 The diagram shows an example of an external communication unit 20 connected to a host ECU 10. However, the external communication unit 20 can also be connected to an ECU different from the host ECU 10, or it can be mounted on any ECU. For example, the host ECU 10 can download applications for implementing new functions in the vehicle, updates for upgrading programs already installed on at least one lower ECU 11-16, etc., from the data center 30 via the external communication unit 20. These applications and updates can be provided by the vehicle manufacturer (hereinafter also referred to as the OEM) or third parties.

[0045] Furthermore, any ECU belonging to the vehicle network system 100 may also have a data link coupler 21 connected to a data device (not shown). Figure 1 The diagram shows an example of data link coupler 21 connected to host ECU 10. However, data link coupler 21 can also be connected to an ECU different from host ECU 10, or it can be mounted on any ECU. The data device and data center 30 can also provide applications for implementing new functions, update programs for upgrading installed programs, etc.

[0046] The upper-level ECU 10 and lower-level ECUs 11-16 can be constructed from a computer equipped with a processor, memory, and storage. The processor may be, for example, a Central Processing Unit (CPU), a Microprocessor Unit (MPU), a Graphics Processing Unit (GPU), or a Data Flow Processor (DFP) that executes predetermined processes according to a program. Memory is a volatile storage medium that temporarily stores the results of the processor's operations, such as RAM (Random Access Memory). Storage includes non-volatile storage media such as flash memory and ROM (Read Only Memory). Various programs and data executed by the processor are stored in the storage. Some or all of the functions of the upper-level ECU 10 may also be implemented in hardware using, for example, ASICs (Application Specific Integrated Circuits) or FPGAs (Field-Programmable Gate Arrays). Furthermore, in... Figure 1 The diagram shows the functional units, namely the determination unit 10a and the rewriting unit 10b, which can be constructed on the host ECU 10 via software and / or hardware. The determination unit 10a and the rewriting unit 10b will be described in detail later.

[0047] The upper ECU 10 and lower ECUs 11-16 also have a communication interface (communication IF) for communicating with other ECUs. This communication IF, for example, has the function of temporarily switching lower ECUs 11-16 from sleep to active state if an NM message is received while they are in sleep mode. If the communication IF is activated, the lower ECUs 11-16 determine whether their own activation has been requested based on the PN request information and PNC setting information in the NM message. When it is determined that their own activation has been requested, the lower ECUs 11-16 continue in active state. On the other hand, if it is determined that their own activation has been requested, the lower ECUs 11-16 return to sleep mode. Alternatively, the determination based on the PN request information and PNC setting information in the NM message can be performed within the communication IF. In this case, if the communication IF determines that activation has been requested based on the PN request information and PNC setting information, the corresponding ECU is switched from sleep mode to active state.

[0048] Next, refer to Figure 2 An example of a method for implementing partial networking based on NM messages generated by the upper ECU 10, PNC setting information of each lower ECU 11-16, and PNC setting information to set some lower ECUs 11-16 to the start state and others to the sleep state is described.

[0049] NM messages, for example, Figure 2 The data shown includes bytes 0 through 7. Byte 0 includes the Node ID (NID). The Node ID is a unique identifier for both the upper-level ECU 10 and the lower-level ECUs 11 through 16. The Node ID identifies the source of the NM message. Byte 1 includes the Control Bit Vector (CBV). The Control Bit Vector indicates whether a local area network is being used. If the Control Bit Vector indicates that a local area network is being used, bytes 2 through 7 contain cluster startup information, i.e., PN request information, indicating the cluster to be started.

[0050] exist Figure 2 In the example shown, the control bit vector indicates the use of the local network, and PN request information is stored in bytes 6 and 7 of the user data area. The user data area, bytes 2 through 5, can be used to transmit any information, such as wake-up triggering factors, information related to normal or abnormal events, etc. Furthermore, Figure 2 This is just one example of the form of an NM message. An NM message can also take other forms as long as it contains information about the availability of the local network and PN request information.

[0051] The PN request information is organized into multiple clusters, specifying which clusters should be started and which do not. More specifically, in... Figure 2 In the example shown, the clusters are pre-divided into 16 groups. Furthermore, the PN request information contains 16 bits of data corresponding to each of the 16 groups. That is, the 16 bits of the PN request information correspond to the 16 pre-divided clusters. When each of the 16 bits of the PN request information is "0", it indicates that the corresponding cluster does not need to be started. Conversely, when each of the 16 bits of the PN request information is "1", it indicates that the corresponding cluster needs to be started.

[0052] As described above, each lower-level ECU 11-16 has PNC configuration information indicating which cluster it belongs to among the multiple clusters it is divided into. For example, this PNC configuration information... Figure 2 As shown. That is, Figure 2 This shows the PNC setting information of any one of the lower-level ECUs 11 to 16. Figure 2 In the PNC configuration information shown, when the corresponding clusters are classified as A to P from left to right in the diagram, Figure 2 The PNC setting information indicates that the ECU with this PNC setting information belongs to clusters D, H, and J. Each lower-level ECU 11 to 16 can perform various functions through program execution, and therefore can belong to more than one cluster.

[0053] If each lower-level ECU 11-16 receives an NM message containing PN request information via the communication IF, then... Figure 2 As shown, the PN request information and PNC setting information are compared bit by bit, for example, by performing a logical AND operation. That is, if each lower-level ECU 11-16 receives an NM message via the communication IF, it temporarily enters the startup state. Then, each lower-level ECU 11-16 determines whether the cluster requested to be started by the PN request information contained in the NM message sent from the upper-level ECU 10, etc., is consistent with the cluster of the PNC setting information. For example, in Figure 2 In the example shown, the clusters initiated by the PN request information are clusters D, G, I, M, N, and O. The clusters to which the ECU belongs, as indicated by the PNC configuration information, are clusters D, H, and J. In this case, within cluster D, the cluster initiated by the PN request information contained in the NM message is consistent with the cluster in the PNC configuration information. Therefore, as... Figure 2 As shown, the result of the logical AND operation is "1" in cluster D.

[0054] As a result of a logical AND operation, if a bit becomes "1", then it has... Figure 2 The ECU that displays the PNC setting information determines that its startup has been requested. Accepting this determination result, it has... Figure 2 The ECU with the PNC setting information shown will transition to the start state if it was previously in sleep mode, and will remain in the start state if it was already in start state. On the other hand, if the result of the logical AND operation is all 0s and no bits are "1", then... Figure 2 The ECU that displays the PNC setting information determines that its startup is requested. In this case, the ECU with... Figure 2 The ECU that receives the PNC setting information discards the NM message. If the previous state was sleep state, it will return to sleep state again.

[0055] In other words, each lower-level ECU 11-16 performs filtering based on the PNC setting information to determine whether the NM message requests the startup of each lower-level ECU 11-16. Through this filtering based on the PNC setting information, only ECUs with PNC setting information containing clusters that have requested startup by the PN request information become startup upon receiving the NM message, thus realizing a local network.

[0056] For example, in Figure 1 The diagram illustrates an example where lower-level ECUs 11 and 13 are grouped into cluster C1, lower-level ECUs 12, 14, and 15 are grouped into cluster C2, and lower-level ECU 16 is grouped into cluster C3. Therefore, for example, if the upper-level ECU 10 sends an NM message containing PN request information designating cluster C1 as the cluster to be started, then according to this NM message, lower-level ECUs 11 and 13 become active, while the other lower-level ECUs 12 and 14-16 remain in a sleep state. As a result, a local network is implemented where only lower-level ECUs 11 and 13 are active, while the other lower-level ECUs 12 and 14-16 remain in a sleep state.

[0057] Furthermore, if the lower-level ECUs 11-16 transition from the startup state to the normal operating mode, they periodically send NM messages to other ECUs during their normal operation. Then, after performing the necessary processing, if the lower-level ECUs 11-16 reach a state where normal operation is no longer required, they cease sending periodic NM messages. If the time since the lower-level ECUs 11-16 did not receive NM messages from other ECUs belonging to the same cluster reaches a predetermined standby time, they transition from the normal operating mode to the power-saving mode, switching from the startup state to the sleep state.

[0058] In recent years, after vehicles are sold and circulated in the market, vehicle owners can update the software of the vehicle's ECU by downloading any application. In this case, the ECU, whose software has been updated, is required to add or change its startup conditions depending on the functions of the downloaded application. However, if the addition or modification of ECU startup conditions is allowed without restriction, inappropriate changes may result in the ECU failing to start when it should, posing a potential risk of malfunctioning important vehicle functions.

[0059] Therefore, the vehicle network system 100 of this embodiment is configured to flexibly respond to the addition or change of the startup conditions of the lower-level ECUs 11-16, and to prevent inappropriate changes to the startup conditions of the lower-level ECUs 11-16 regarding important functions. Hereinafter, refer to... Figure 3 The flowchart illustrates the process of adding and changing the start-up conditions of lower-level ECUs 11 to 16 in the vehicle network system 100. Figure 3 The execution of the process shown in the flowchart is equivalent to the execution of the management method of the in-vehicle network system in this embodiment.

[0060] Figure 3 The process shown in the flowchart can, for example, be executed by the host ECU 10. However, Figure 3 The process shown in the flowchart can also be performed outside the vehicle, such as in the data center 30 or a data device connected to the data link coupler 21. Furthermore, if performed outside the vehicle, the communication volume for rewriting PNC setting information may increase, so it is preferable that it be performed by an ECU located inside the vehicle. For example, if the host ECU 10 also receives the PNC setting information rewriting request, the communication volume for rewriting the PNC setting information can be suppressed.

[0061] Alternatively, it can be executed by the host ECU10. Figure 3 As shown in the flowchart, part of the process is performed by at least one lower-level ECU 11-16, and the remaining processes are executed. For example, the rewriting process of step S180 (described later) can also be performed by the upper-level ECU 10, and the remaining processes can be performed by at least one lower-level ECU 11-16. Hereinafter, the upper-level ECU 10 will be executed... Figure 3 The flowchart illustrates an example of the processing.

[0062] In step S100, the upper-level ECU 10 receives a change request (rewrite request) for PNC setting information from at least one lower-level ECU 11-16 from the data center 30 or the data device connected to the data link coupler 21. The PNC setting information change request is sent to the upper-level ECU 10 from the data center 30 or the data device connected to the data link coupler 21 along with any application downloaded by the vehicle user from the data center 30 or the data device connected to the data link coupler 21. The PNC setting information change request includes at least information indicating the attributes of the request source requesting the change of PNC setting information, and the changed PNC setting information (change request PNC setting information).

[0063] At least one lower-level ECU 11-16 executing the downloaded application may require additional or modified activation conditions depending on the application's functions. For example, suppose a camera is installed in the vehicle and is used for advanced driver assistance functions such as lane keeping assist and obstacle detection when the vehicle is in motion. Suppose the vehicle user has downloaded an application that uses the camera to monitor the vehicle's surroundings and their home's surroundings when the vehicle is parked. Therefore, the camera needs to be activated not only when the vehicle is in motion but also when the vehicle is parked. In this case, the lower-level ECU 11-16 controlling the camera needs to be activated not only when the vehicle is in motion but also when the vehicle is parked.

[0064] The startup conditions of the lower-level ECUs 11-16 can be changed according to the aforementioned PNC setting information. Therefore, the data center 30 or data device may, as needed, send a request to the upper-level ECU 10 to change the PNC setting information already set on at least one of the lower-level ECUs 11-16 that executes the downloaded application.

[0065] In step S110, the host ECU 10, based on the received PNC change request, determines whether the requesting source has the authority to change the PNC settings. If the host ECU 10 determines that the requesting source has the authority to change the PNC settings, it proceeds to step S120. Conversely, if the host ECU 10 determines that the requesting source does not have the authority to change the PNC settings, it terminates the process. Figure 3 The process is shown in the flowchart.

[0066] The PNC change request, depending on whether the downloaded application was prepared by the vehicle manufacturer (OEM) or a third party, includes information indicating whether the requesting source is an OEM or a third party. Furthermore, in the case of a third party, the PNC setting information may also include information identifying whether the third party is a certified third party recognized by the OEM or a non-certified third party. In addition to the identifier indicating the requesting source, the PNC change request may also include a password corresponding to the attributes of each requesting source.

[0067] In step S110, if the PNC change request includes an identifier indicating an OEM or third party, and a password corresponding to the OEM or third party, the upper-level ECU 10 can determine that the requesting source has the authority to change the PNC setting information. On the other hand, if the PNC change request does not include identifier information or a password, the upper-level ECU 10 can determine that it is an inappropriate PNC change request, and the requesting source does not have the authority to change the PNC setting information.

[0068] In step S120, the host ECU 10 determines the scope of change for the PNC setting information corresponding to the attributes of each request source based on the identifier information contained in the PNC change request. (See below for further details.) Figure 4 This is an example illustrating the scope of changes to PNC setting information corresponding to the attributes of the request source. Furthermore, in Figure 4 The diagram shows an example where the clusters are divided into 12 groups. Furthermore, these 12 groups are categorized as clusters A through L, moving from left to right in the diagram.

[0069] exist Figure 4 In the example shown, when the downloaded application is prepared by the OEM and the request to change the PNC configuration information originates from the OEM (or dealer), the OEM (or dealer), as the administrator, has the authority to change the PNC configuration information for all clusters A through L contained in the PNC configuration information. The OEM is familiar with the functions performed by each lower-level ECU 11-16. Therefore, there is no risk of inappropriate PNC configuration information changes being made in the vehicle, such as lower-level ECUs 11-16 failing to start when they should.

[0070] In addition, Figure 4 In the example shown, if the downloaded application was prepared by a third party (third party X), and the request to change PNC settings originates from third party X, then third party X has the authority to change PNC settings within clusters E to L, excluding clusters A to D. Furthermore, in Figure 4In the example shown, if the downloaded application is prepared by a non-certified third party (third party Y), and the request for changes to PNC setting information originates from third party Y, then third party Y has the authority to change the PNC setting information within clusters I to L, excluding clusters A to H. Certified and / or non-certified third parties may not be familiar with the functions performed by each lower-level ECU 11 to 16. Therefore, when the request source is a certified or / or non-certified third party, the scope of PNC setting information changes is limited to those that do not impede the vehicle's essential functions. Thus, regarding the vehicle's essential functions, changes to PNC setting information related to the addition or alteration of inappropriate startup conditions by lower-level ECUs 11 to 16 can be prevented as much as possible.

[0071] For reference Figure 4 As explained, the modifiable scope of the PNC configuration information corresponding to the attributes of the PNC configuration information change request source is predetermined based on regions divided into two or more clusters. Figure 4 The example shown illustrates dividing cluster A to L into three regions (A to D, E to H, I to L). However, the number of regions in a cluster can be two or more.

[0072] Furthermore, the attributes of the PNC configuration information change request source include higher-level attributes with broad authority, such as administrators (OEMs or distributors), and lower-level attributes with narrower authority, such as third parties. Moreover, a portion of the scope that a request source matching the higher-level attribute can modify (multiple areas of the cluster) becomes the scope that a request source matching the lower-level attribute can modify (at least one area of ​​the cluster).

[0073] When dividing all clusters into two or more regions, they can also be divided based on domains. Each cluster is formed by grouping multiple lower-level ECUs 11-16 that need to be simultaneously activated to achieve at least one desired function in the vehicle. Moreover, at least one desired function can be set to belong to any domain within multiple domains that roughly divide the various functions of the vehicle. Therefore, each cluster can be classified into any domain.

[0074] As mentioned above, in addition to the powertrain domain and chassis domain related to vehicle operation, the domain can also include advanced driver assistance domains related to vehicle driving safety. If the PNC settings related to clusters belonging to these powertrain domains, chassis domains, and advanced driver assistance domains are incorrectly changed, it may impair important functions such as vehicle operation and driving safety. Therefore, when dividing all clusters into two or more regions, for example, it can be divided into a first region containing all clusters and a second region excluding clusters belonging to the powertrain domain, chassis domain, and advanced driver assistance domain.

[0075] Furthermore, when dividing all clusters into two or more regions, the importance of the functions performed by the lower-level ECUs 11-16 grouped to each cluster can be determined on a cluster-by-cluster basis. For example, the system can be divided into a third region containing all clusters that perform specific functions, and a fourth region that does not contain specific clusters. A specific cluster can be equivalent to a cluster used to perform functions related to the aforementioned vehicle operation and driving safety. Additionally, when the vehicle corresponds to a so-called smart key or digital key, the specific cluster can also be the cluster to which the key matching ECU or digital key ECU belongs. This is because the key matching ECU and digital key ECU, by being activated at appropriate times, can ensure user convenience and vehicle security.

[0076] Furthermore, when dividing all clusters into two or more regions, they can be further divided based on the power consumption of the lower-level ECUs 11-16 belonging to each cluster. This can be done by creating a fifth region that covers all clusters, including those belonging to lower-level ECUs 11-16 with relatively high power consumption, and a sixth region that excludes those belonging to lower-level ECUs 11-16 with relatively high power consumption. This is because if the starting conditions are changed in a way that the lower-level ECUs 11-16 with relatively high power consumption are more frequently in the starting state, the possibility of a serious event such as the vehicle's battery being depleted increases.

[0077] In addition, the aforementioned first and second regions based on domains, the third and fourth regions based on clusters, and the fifth and sixth regions based on the current consumption of each lower-level ECU 11 to 16 can be used individually or in any combination.

[0078] Return again Figure 3The flowchart will continue to be explained. In step S130, the upper-level ECU 10 compares the bits of the PNC setting information before the change with the bits of the PNC setting information in the change request range corresponding to the attributes of the PNC setting information change request source. That is, the upper-level ECU 10 determines the bits within the changeable range of the PNC setting information as appropriate change requests (rewrite requests), and determines the bits outside the changeable range as inappropriate change requests (rewrite requests). Moreover, the upper-level ECU 10 compares the bits of the PNC setting information before the change with the bits of the PNC setting information in the change request range of the PNC setting information that meets the criteria for appropriate change requests. In other words, the bits of the PNC setting information outside the changeable range of the PNC setting information are ignored. As a result, the PNC setting information outside the changeable range of the PNC setting information is discarded.

[0079] For example, Figure 5 This shows an example of the PNC settings information before the change on one of the lower-level ECUs 11 to 16. Figure 6 Showing for those with Figure 5 The example shown is of PNC setting information included in a PNC change request for one of the lower-level ECUs 11-16. Additionally, as... Figure 6 As shown, the request source attribute of the PNC change request is set to non-identified third party, i.e., third party Y.

[0080] like Figure 6 As shown, the modifiable range of PNC setting information not recognized by a third party is the range of clusters I to L. Therefore, in step S130, the bits of the PNC setting information within the modifiable range that correspond to the bits of clusters I to L are compared with the PNC setting information before the change and the PNC setting information of the change request. Furthermore, the bits of the PNC setting information that correspond to clusters A to H are ignored because they are outside the modifiable range.

[0081] For example, in Figure 6 In the PNC configuration information of the change request shown, the bits corresponding to clusters C and F (represented by shaded areas) and the bits corresponding to cluster J (represented by dots) are different from the bits in the PNC configuration information before the change. Cluster J is within the scope of change. Therefore, as... Figure 7 As shown, the bits in the modified (rewritten) PNC configuration information that correspond to cluster J are overwritten through the change request PNC configuration information. On the other hand, the bits in the change request PNC configuration information that correspond to clusters C and F are ignored because they are outside the variable range. As a result, the bits in the modified PNC configuration information that correspond to clusters C and F remain the same as the bits in the original PNC configuration information.

[0082] Furthermore, in the aforementioned example, if the change request PNC setting information includes not only PNC setting information within the modifiable range but also PNC setting information outside the modifiable range, the original PNC setting information is changed based on the PNC setting information within the modifiable range, and the PNC setting information outside the modifiable range is discarded. However, if the change request PNC setting information includes PNC setting information outside the modifiable range, the change request accompanying such a change request can be set as an improper change request, and the change request PNC setting information can be discarded without any change to the PNC setting information. In other words, the PNC setting information can be changed only if the change request for the PNC setting information only includes PNC setting information within the modifiable range.

[0083] In step S140, the host ECU 10 determines whether there is a difference between the bits of the PNC setting information before the change and the bits of the PNC setting information requested for the change, within the modifiable range of the PNC setting information. If a difference is found, the host ECU 10 proceeds to step S150. Conversely, if no difference is found, the host ECU 10 ends the process. Figure 3 The process is shown in the flowchart.

[0084] The aforementioned steps S110 to S140 are equivalent to the processing performed by the determination unit 10a built on the upper ECU 10.

[0085] In step S150, the upper-level ECU 10 determines whether the attribute of the change request source for the PNC setting information is an OEM (or distributor) with administrator privileges. If it is determined that the change request source is an OEM (or distributor) with administrator privileges, the upper-level ECU 10 proceeds to step S180. On the other hand, if it is determined that the change request source is a third party without administrator privileges, the upper-level ECU 10 proceeds to step S160.

[0086] In step S160, since the PNC setting information change request source does not have administrator privileges, the upper-level ECU 10 requests the vehicle user (owner) with administrator privileges to agree to the PNC setting information change. In step S170, the upper-level ECU 10 determines whether the vehicle user agrees to the PNC setting information change. This agreement can be implemented by the vehicle user, for example, by entering an authentication code indicating that they are an administrator on the vehicle's infotainment system screen and performing an operation to indicate agreement (touch panel operation, voice operation, etc.). Alternatively, agreement can also be implemented by the vehicle user using their portable terminal to conduct short-range wireless communication with the upper-level ECU 10, sending an ID indicating that they are the vehicle user, and performing an operation to indicate agreement. If it is determined that the vehicle user has agreed, the upper-level ECU 10 proceeds to step S180. On the other hand, if it is determined that the vehicle user has not agreed, the upper-level ECU 10 terminates the process. Figure 3 The process is shown in the flowchart.

[0087] In step S180, the host ECU 10, within the modifiable range of the PNC setting information corresponding to the attribute of the PNC setting information change request source, rewrites the bits of the PNC setting information before the change, specifically the bits of the PNC setting information that differ from the bits of the PNC setting information before the change. This step S180 is equivalent to the processing performed by the rewriting unit 10b constructed in the host ECU 10.

[0088] As explained above, according to the vehicle network system and its management method of this embodiment, PNC setting information is modified (rewritten) only within the modifiable range determined by the attributes of the modification request source. Therefore, regarding important vehicle functions, changes to PNC setting information related to the addition or modification of inappropriate starting conditions of lower-level ECUs 11-16 can be prevented as much as possible.

[0089] (Modified Example)

[0090] The preferred embodiments of this disclosure have been described above, but this disclosure is not limited to the foregoing embodiments and can be implemented in various modifications without departing from the spirit of this disclosure.

[0091] For example, it can also be configured such that the scope of changeable PNC settings information, determined by the attributes of the PNC settings change request source, can be changed by an organization or individual with administrative authority (OEM or dealer, vehicle owner, etc.). (See reference...) Figure 8 The flowchart illustrates an example of the process for changing the modifiable range of PNC settings.

[0092] In step S200, the upper-level ECU 10 receives a change request regarding the modifiable range of the PNC setting information corresponding to the attribute of the change request source. In step S210, the upper-level ECU 10 determines whether the change request is made by an organization or person with administrator authority. For example, whether administrator authority is possessed can be determined based on a password or authentication code established with the administrator. If administrator authority is determined, the upper-level ECU 10 proceeds to step S210. On the other hand, if administrator authority is determined not to be possessed, the upper-level ECU 10 does not change the modifiable range of the PNC setting information and ends the process. Figure 8 The process is shown in the flowchart.

[0093] In step S220, the upper-level ECU10 changes the changeable range of the PNC setting information based on the information contained in the change request for the changeable range of the PNC setting information, which indicates the changed changeable range.

[0094] Furthermore, the authentication code and ID indicating the vehicle's user (owner) are preferably changeable. This allows for appropriate handling of situations where the vehicle's ownership changes due to a transfer of ownership.

Claims

1. A vehicle-mounted network system comprising multiple control devices connected to a communication bus in a vehicle and capable of communicating with each other, characterized in that, Each of the multiple control devices has cluster information indicating the cluster it belongs to among multiple clusters. If a control device receives network management messages from other control devices containing startup cluster information that matches the cluster information, indicating the cluster to be started, then it enters a startup state or remains in a startup state. The in-vehicle network system has the following features: In the case where at least one of the multiple control devices requests the rewriting of the cluster information, the determination unit determines the rewriting request as an appropriate rewriting request within the range of rewriting capabilities of the cluster information, as determined by the attributes of the rewriting request source. as well as The rewriting unit performs the rewriting of the cluster information according to the appropriate rewriting request determined by the determination unit.

2. The vehicle network system according to claim 1, characterized in that, The determination unit will judge and discard rewrite requests that are outside the scope of rewriteability of the cluster information as inappropriate rewrite requests.

3. The vehicle network system according to claim 1, characterized in that, The clusters that were originally divided into multiple groups were further divided into two or more regions. The range of regions of the cluster that can be rewritten varies depending on the attributes of the rewrite request source. The extent to which the cluster information can be rewritten, corresponding to the attributes of the rewrite request source, is determined based on a region that is divided into two or more clusters.

4. The vehicle network system according to claim 3, characterized in that, It also has: When a change request is generated that covers a range of cluster regions that can be rewritten based on the attributes of the source of the rewrite request, the permission determination unit determines whether the change request was made by an organization or person with administrative authority. as well as If the permission determination department determines that the change request was made by an organization or person with administrative authority, the change department shall, in accordance with the change request, change the range of the cluster area that can be rewritten based on the attributes of the rewrite request source.

5. The vehicle network system according to claim 3, characterized in that, The attributes of the rewrite request source include a superordinate attribute with a wider range of permissions and a subordinate attribute with a narrower range of permissions than the superordinate attribute. A portion of the region that the higher-level attribute can rewrite becomes the region that the lower-level attribute can rewrite.

6. The vehicle network system according to claim 5, characterized in that, It also includes a confirmation unit that, if the attribute of the rewrite request source is the lower-level attribute, confirms with the vehicle owner whether they agree to the rewriting of the cluster information. If the confirmation unit confirms that the owner of the vehicle has agreed, the rewriting unit performs the rewriting of the cluster information.

7. The vehicle network system according to claim 6, characterized in that, When the owner of the vehicle agrees, the confirmation unit needs to indicate that it is the owner of the vehicle.

8. The vehicle network system according to any one of claims 3 to 7, characterized in that, The cluster information is used to group multiple control devices that need to be simultaneously activated to achieve at least one desired function in the vehicle. The desired function is defined as belonging to any of the multiple domains that broadly divide the various functions of the vehicle. Two or more regions of a cluster are divided based on the domain.

9. The vehicle network system according to any one of claims 3 to 7, characterized in that, The cluster information is used to group multiple control devices that need to be simultaneously activated to achieve at least one desired function in the vehicle. Two or more regions of a cluster are divided into at least a first region containing a specific cluster and a second region not containing the specific cluster.

10. The vehicle network system according to any one of claims 3 to 7, characterized in that, The cluster information is used to group multiple control devices that need to be simultaneously activated to achieve at least one desired function in the vehicle. The cluster is divided into two or more regions, including a third region containing the cluster to which the control device with relatively high current consumption belongs, and a fourth region not containing the cluster to which the control device with relatively high current consumption belongs.

11. The vehicle network system according to any one of claims 1 to 7, characterized in that, The determination unit is installed in any one of the plurality of control devices.

12. The vehicle network system according to any one of claims 1 to 7, characterized in that, The rewriting unit is installed in any one of the plurality of control devices.

13. A management method for an in-vehicle network system, the in-vehicle network system having multiple control devices connected to a communication bus in a vehicle and capable of communicating with each other, the management method for the in-vehicle network system being characterized in that... Each of the multiple control devices has cluster information indicating the cluster it belongs to among multiple clusters. If a control device receives network management messages from other control devices containing startup cluster information that matches the cluster information, indicating the cluster to be started, then it enters a startup state or remains in a startup state. The management method for the in-vehicle network system includes the following steps: In the event that at least one of the multiple control devices requests the rewriting of the cluster information, a rewriting request within the scope of the rewriting capability of the cluster information, determined based on the attributes of the rewriting request source, is deemed an appropriate rewriting request; and The cluster information is rewritten according to the determined appropriate rewrite request.

14. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the management method of claim 13.

Images