In-vehicle network system, relay node, and method for transferring a start message

Abstract

A technology is provided for reducing the amount of communication of messages related to control of the activation state of a partial network. In steps S230 to S260 and S280 to S320, a calculation unit 224 of a zone ECU 22 generates integrated startup request information by merging startup request information indicated in integration target messages, which are startup messages received from subordinate end nodes, during a predetermined buffering period, and generates an integrated startup message, which is a startup message including the integrated startup request information. In step S330, the calculation unit 224 transfers the generated integrated startup message to a communication port other than the communication port through which the integration target message was received.

Description

[Technical Field]

[0001] The present disclosure relates to an in-vehicle network system. [Background technology]

[0002] Patent Document 1 listed below discloses a partial network technology that selectively controls the wake-up / sleep state of each ECU connected to an in-vehicle network system. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-011228 Summary of the Invention [Problem to be solved by the invention]

[0004] AUTOSAR R22-11: Specification of UDP Network Management, a standard for in-vehicle Ethernet networks, specifies that end nodes periodically transmit NM messages that control their startup status, and that relay nodes forward the NM messages by broadcast. Ethernet is a registered trademark. In other words, each NM message sent from each end node is sent individually to all end nodes. This posed a problem: the volume of NM messages transmitted within the network became enormous.

[0005] One aspect of the present disclosure provides a technique for reducing the amount of communication of messages related to control of the activation state of a partial network. [Means for solving the problem]

[0006] An in-vehicle network system according to one aspect of the present disclosure includes a plurality of relay nodes (21, 22) and a plurality of terminal nodes (23). Each of the relay nodes has a plurality of communication ports (Pi). Each of the terminal nodes is connected to one of the plurality of relay nodes. Each of the plurality of communication ports of a relay node is connected to another relay node or a terminal node subordinate to the relay node. The terminal node includes a startup unit (233). The startup unit is configured to transition from a sleep state to a wake-up state when a startup condition is satisfied within the terminal node, and to transmit a startup message including startup request information indicating an activation cluster to which the terminal node belongs. Furthermore, the terminal node is configured to transition from a sleep state to a wake-up state when a startup message including startup request information indicating an activation cluster to which the terminal node belongs is received. The relay node includes a message integration unit (224: S230 to 260, S280 to S320) and a port forwarding unit (224: S330). The message integration unit is configured to generate integrated startup request information by merging startup request information indicated in integration target messages, which are startup messages received from subordinate end nodes, during a determined buffering period, and to generate an integrated startup message, which is a startup message including the integrated startup request information. The port forwarding unit is configured to forward the integrated startup message generated by the message integration unit to a communication port other than the communication port through which the integration target message was received.

[0007] With this configuration, instead of forwarding a start message as is, an integrated start message that integrates multiple start messages is forwarded, thereby reducing the amount of communication related to start messages between relay nodes and between relay nodes and leaf nodes. As a result, the processing load related to duplicate start messages can be reduced at relay nodes and leaf nodes, and power consumption can be reduced by suppressing unnecessary node start-up.

[0008] A relay node according to one aspect of the present disclosure forms an in-vehicle network system together with other relay nodes (22) and multiple terminal nodes (23), and includes multiple communication ports (Pi) to which other relay nodes or terminal nodes subordinate to the relay node are connected. The relay node includes a message integration unit (224: S230-260, S280-S320) and a port forwarding unit (224: S330). The message integration unit and the port forwarding unit are the same as those described in the in-vehicle network system above.

[0009] With this configuration, it can be used as a relay node that constitutes the above-mentioned in-vehicle network system. A method for forwarding a wake-up message according to one aspect of the present disclosure is applied to a relay node that forms an in-vehicle network system together with other relay nodes (22) and multiple end nodes (23). The relay node has multiple communication ports (Pi) to which other relay nodes or subordinate end nodes are connected. The wake-up message forwarding method includes merging wake-up request information indicated in integration target messages, which are wake-up messages received from subordinate end nodes during a predetermined buffering period, to generate integrated wake-up request information, and generating an integrated wake-up message including the wake-up request information (S230-S260, S280-S320). The wake-up message forwarding method also includes forwarding the generated integrated wake-up message to a communication port other than the communication port through which the integration target messages were received (S330). The definitions of each term in the wake-up message forwarding method are the same as those described above for the in-vehicle network system.

[0010] By implementing this method, it is possible to obtain the same effects as those obtained by the above-mentioned in-vehicle network system. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a block diagram showing a configuration of an in-vehicle network system according to a first embodiment. [Figure 2] FIG. 10 is an explanatory diagram showing the configuration of an NM message. [Figure 3] FIG. 2 is an explanatory diagram showing an outline of a startup process that is executed by a startup unit of a terminal ECU when an NM message is received. [Figure 4] 10 is a flowchart showing a state management process executed by a terminal ECU. [Figure 5] 10 is a flowchart showing a message integration process executed by a zone ECU. [Figure 6] 10A and 10B are explanatory diagrams showing an overview of the message integration process in normal times and when buffer congestion occurs. [Figure 7] FIG. 10 is a block diagram showing the configuration of an in-vehicle network system according to a second embodiment. [Figure 8] FIG. 10 is an explanatory diagram showing the initial setting of the NM table in each zone ECU. [Figure 9] FIG. 10 is an explanatory diagram showing the settings of the NM table updated by adding a terminal ECU and updating a program. [Figure 10] FIG. 10 is a block diagram showing the configuration of an in-vehicle network system according to a third embodiment. [Figure 11] FIG. 2 is an explanatory diagram showing the settings of the NM table of each zone ECU. [Figure 12] FIG. 10 is an explanatory diagram for the case where a plurality of NM tables prepared in advance are selected and used. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. [1. First embodiment] [1-1.Configuration] In the in-vehicle network system 1 shown in Fig. 1, multiple electronic control units (hereinafter referred to as ECUs) 2 mounted on a vehicle are connected to each other via multiple transmission paths 4 that communicate using the Ethernet protocol. Ethernet is a registered trademark.

[0013] The ECU 2 has a wake-up state, which is a normal operating state in which it can execute its own functions without any restrictions, and a sleep state, which is a low-power operating state in which at least some of its functions are restricted. The operating states of the ECU 2 are individually controlled using NM messages. NM stands for Network Management. In other words, the in-vehicle network system 1 is configured as a partial network (hereinafter referred to as PN). In addition, the ECU 2 has at least the function of receiving an NM message in the sleep state and transitioning itself to the wake-up state according to the contents of the NM message.

[0014] The plurality of ECUs 2 are classified into a central ECU 21, a plurality of zone ECUs 22, and a plurality of end ECUs 23. The central ECU 21 forms a communication network including redundant paths with the plurality of zone ECUs 22. The central ECU 21 controls the plurality of zone ECUs 22 and realizes coordinated control of the entire vehicle.

[0015] A zone ECU 22 is provided for each zone that divides the interior of the vehicle. Each zone ECU 22 is connected to a plurality of end ECUs 23 present in the zone via an individual transmission line 4. A zone ECU 22 controls the subordinate end ECUs 23 that are directly connected to the zone ECU, thereby realizing coordinated control within the zone.

[0016] In this embodiment, the vehicle is divided into three zones A to C, and the zone ECUs 22 arranged in the respective zones A to C are referred to as zone ECU_A, zone ECU_B, and zone ECU_C. The number of zones is not limited to three, and the vehicle may be divided into four zones: the front of the vehicle, the rear of the vehicle, one side of the vehicle, and the other side of the vehicle. The vehicle may also be divided into five or more zones.

[0017] As shown in FIG. 1 , the central ECU 21 is connected to the zone ECU_A and the zone ECU_C via their respective transmission paths 4. The zone ECU_A is connected to the central ECU 21 and the zone ECU_B via their respective transmission paths 4. The zone ECU_B is connected to the zone ECU_A and the zone ECU_C via their respective transmission paths 4. The zone ECU_C is connected to the zone ECU_B and the central ECU 21 via their respective transmission paths 4. In other words, the central ECU 21 and the multiple zone ECUs 22 are connected in a loop, and some of the communication ports connected to the transmission path 4 are set as blocking ports to suppress circulation of communication frames. FIG. 1 illustrates a case where the communication port connecting the central ECU 21 and the zone ECU_C is set as a blocking port. Communication through the blocking port is normally prohibited, and the prohibition may be lifted when a failure occurs in the ECU 2 or the transmission path 4. In other words, the blocking port may be used to ensure redundancy of the communication path. The central ECU 21 and the multiple zone ECUs 22 may be referred to as forming a ring topology.

[0018] Three end ECUs 23 are connected to the zone ECU_A in a star configuration via individual transmission paths 4. Hereinafter, the end ECUs 23 connected to the zone ECU_A will also be referred to as end ECU_A, end ECU_B, and end ECU_C. The zone ECU_A and the end ECUs_A to C form a switched network (hereinafter, switched NW). Note that the number of end ECUs 23 connected to each zone ECU 22 as subordinates is not limited to the above example, and is arbitrary.

[0019] Three end ECUs 23 are connected to zone ECU_B in a bus-like manner via one transmission path 4. Hereinafter, the end ECUs 23 connected to zone ECU_A will also be referred to as end ECU_D, end ECU_E, and end ECU_F. In other words, zone ECU_B and end ECUs_D to F form a bus NW.

[0020] A wireless device 3 that communicates with a server or the like on the wide area wireless network is connected to the zone ECU_C. One or more end ECUs 23 may also be connected to the zone ECU_C, but for simplicity, illustration and description thereof are omitted here.

[0021] [1-2.NM Message] An overview of NM messages will be explained using Figure 2. NM messages comply with the AUTOSAR R22-11: Specification of UDP Network Management. The compliant specification is not limited to R22-11, but may also be its successor, R23-11, for example.

[0022] NM messages are sent and received using Ethernet frames. An Ethernet frame consists of a physical header, an Ethernet header, a payload, and a trailer. The physical header is a preamble. The Ethernet header includes a destination address, a source address, etc. The payload is data and carries an NM message. The trailer is a frame check sequence.

[0023] An NM message includes an NID, a CBV, user data, and a PNI. The NID and the CBV are each composed of one byte. The user data is a variable byte, and FIG. 2 shows a case where it is four bytes. The PNI is a variable byte, and FIG. 2 shows a case where it is two bytes. The positions of the NID and the CBV in an NM message may be reversed.

[0024] NID is an abbreviation for Node Identifier, and is information for identifying the node (that is, the end ECU 23) that is the source of the NM message. The user data is an area in which the user can set any data.

[0025] PNI stands for Partial Network Information. PNI is set in the user data area and is represented by multiple bits. Each bit constituting PNI is called a PNC bit. PNC stands for Partial Network Cluster. PNC indicates a group (hereinafter referred to as a PN cluster) of end ECUs 23 that need to be started simultaneously in a node (i.e., ECU 2). A different PN cluster is assigned to each PNC bit. A PNC bit set to a value of 1 indicates that a factor has occurred that will wake up the PN cluster associated with the PNC bit. A PNC bit set to a value of 0 indicates that a factor has not occurred that will wake up the PN cluster associated with the PNC bit. Hereinafter, the PNI carried in the NM message to wake up ECU 2 is called PN request information.

[0026] CBV is an abbreviation for Control Bit Vector, and is information indicating the content of instructions given by the NM message. The CBV includes a PNI bit, a PNL bit, an AW bit, an NMCSR bit, a PNSR bit, and an RMR bit.

[0027] The PNI bit is information indicating whether or not partial network management (hereinafter referred to as partial NM) is supported. In this embodiment, the PNI bit is fixed to a value indicating support for NM. If support for NM is supported, PN request information is included in the user data of the NM message.

[0028] The PNL bit is information indicating whether the NM message is for PNC learning. PNL stands for Partial Network Learning. The AW bit is information that indicates whether the node wakes up based on a request from within the node or based on a request from outside the node. AW is an abbreviation for Active Weakup.

[0029] The NMCSR bit is information indicating whether a synchronized shutdown of the entire network (hereinafter referred to as synchronized shutdown) is requested. NMCSR stands for NM Coordinator Sleep Ready.

[0030] The PNSR bit is information indicating whether the NM message includes a request for synchronous shutdown. PNSR is an abbreviation for PN Shutdown Request. The RMR bit indicates whether a transition to the repeat message state is requested. It is used when collecting various information using NM messages. RMR stands for Repeat Message Request.

[0031] [1-3. Terminal ECU] As shown in FIG. 1, the terminal ECU 23 includes a transmitter 231, a receiver 232, a starter 233, and a calculator 234.

[0032] The transmitting unit 231 has a function of transmitting a message generated by the local terminal ECU 23 . The receiving unit 232 has a function of receiving messages from other ECUs 2 . The activation unit 233 has a function of transitioning the own terminal ECU 23 to a wake-up state based on the NM message received by the receiving unit 232 when the own terminal ECU 23 is in a sleep state.

[0033] The calculation unit 234 has at least a function of monitoring the transmission and reception of NM messages while the own terminal ECU 23 is in a wake-up state, and transitioning the own terminal ECU 23 to a sleep state as necessary.

[0034] The end ECU 23 holds a PNI (hereinafter referred to as PN filter information) in which all PNC bits corresponding to the PN cluster to which the end ECU 23 belongs are set to 1. When the activation unit 233 receives an NM message (hereinafter referred to as a wake-up request) including PN request information, it compares the PN request information indicated in the wake-up request with the PN filter information held by the local terminal ECU 23, bit by bit, as shown in FIG. 3. If the comparison reveals that at least one matching bit exists, the activation unit 233 transitions the local terminal ECU 23 from a sleep state to a wake-up state. The comparison between the PN request information and the PN filter information may be performed by calculating the logical product of the two. In this case, if the result of the logical product is non-zero, it is determined that the PN request information indicates the PNC to which the local terminal ECU 23 belongs, or in other words, that a factor for waking up the local terminal ECU 23 has occurred.

[0035] The activation unit 233 may be configured by hardware. When an activation condition is met, the activation unit 233 transitions its own terminal ECU 23 from a sleep state to a wake-up state. The activation condition includes at least the extraction of a wake-up cause (hereinafter, external cause) based on the received NM message. The activation condition may also include the occurrence of a wake-up cause (hereinafter, internal cause) in the terminal ECU 23. The activation unit 233 may have a function of notifying the calculation unit 234 of information indicating whether the transition from the sleep state to the wake-up state is due to an external cause or an internal cause.

[0036] The calculation unit 234 includes a computer having a CPU and a memory. When the end ECU 23 transitions to the wakeup state, the calculation unit 234 executes at least a state management process. The state management process is a process for managing the operating state of the end ECU 23, determining whether to maintain the wakeup state or transition to a sleep state.

[0037] The state management process executed by the calculation unit 234 of the terminal ECU 23 will be described with reference to the flowchart of FIG. In S110, the calculation unit 234 starts a sleep timer and a periodic transmission timer. The sleep timer is a timer related to the sleep conditions used when transitioning the local terminal ECU 23 from a wake-up state to a sleep state. The sleep timer is set to time out in, for example, 1 second. The periodic transmission timer is a timer that determines the timing of transmitting an NM message. The periodic transmission timer is set to time out in, for example, 10 ms. The timeout times of the sleep timer and the periodic transmission timer are not limited to the above settings and can be set arbitrarily.

[0038] In S120, the calculation unit 234 transmits an NM message including, as PN request information, the PN filter information held by the local terminal ECU 23. Note that instead of using the PN filter information as is as the PN request information, a part of the PN filter information may be used as the PN request information depending on the state of the local terminal ECU 23. For example, the PN cluster to be activated may differ depending on whether the wakeup is due to an external factor or an internal factor.

[0039] In S130, the calculation unit 234 determines whether or not the sleep conditions are satisfied. One of the sleep conditions includes at least the time-out of the sleep timer. If the calculation unit 234 determines that the sleep conditions are satisfied, it ends the process and transitions its own terminal ECU 23 to the sleep state. If the calculation unit 234 determines that the sleep conditions are not satisfied, it proceeds to S140.

[0040] In S140, the calculation unit 234 determines whether or not it has received an NM message (hereinafter, the target NM message) having PN activation information in which the PNC bit corresponding to the PN cluster to which the own terminal ECU 23 belongs is set to 1. If the calculation unit 234 determines that it has received the target NM message, it proceeds to S150, and if it determines that it has not received the target NM message, it proceeds to S160.

[0041] In S150, the calculation unit 234 restarts the sleep timer and returns the process to S130. In S160, the calculation unit 234 determines whether the periodic transmission timer has expired, and if the periodic transmission timer has expired, the process proceeds to S170, and if the periodic transmission timer has not expired, the process returns to S130.

[0042] In S170, the calculation unit 234 restarts the periodic transmission timer, transmits an NM message similar to the NM message transmitted in the previous S120, and returns the process to S130.

[0043] That is, in the wake-up state, the end-user ECU 23 transmits an NM message at regular intervals determined by the setting value of the periodic transmission timer. Also, if the end-user ECU 23 does not receive a target NM message for a regular interval determined by the setting value of the sleep timer, the end-user ECU 23 transitions to the sleep state.

[0044] [1-4. Zone ECU] The plurality of zone ECUs 22 are all configured in the same manner. As shown in FIG. 1, the zone ECU 22 includes a transmitter 221, a receiver 222, a transfer unit 223, and a calculator 224.

[0045] The transmitter 221 has a function of transmitting a message via one of a plurality of communication ports that the own zone ECU 22 has. The receiving unit 222 has a function of receiving a message from another ECU 2 via one of a plurality of communication ports that the own zone ECU 22 has.

[0046] The transfer unit 223 has a function of transferring messages other than NM messages received from other ECUs 2 according to the destination indicated in the message. The calculation unit 224 has the function of merging and integrating the PN request information contained in the NM messages received from the subordinate terminal ECUs 23, and transferring the NM message containing the integrated PN request information (hereinafter referred to as the integrated NM message) to other ECUs 2.

[0047] The calculation unit 224 includes a computer having a CPU and a memory, similar to the calculation unit 234 of the terminal ECU 23. The calculation unit 224 executes at least the message integration process.

[0048] The message integration process executed by the calculation unit 224 when the zone ECU 22 is in the wake-up state will be described with reference to the flowchart of FIG. In S210, the calculation unit 224 starts a sleep timer and a buffering timer. The sleep timer is set in the same manner as the sleep timer used in the state management process of the end-station ECU 23. The buffering timer is a timer that determines the buffering period of the NM message. For example, the buffering timer is set to time out at a time equal to or longer than the time at which the periodic transmission timer used in the state management process of the end-station ECU 23 times out.

[0049] In S220, the calculation unit 224 determines whether the sleep conditions are met. One of the sleep conditions includes at least the timeout of the sleep timer. If the calculation unit 224 determines that the sleep conditions are met, it ends the process and transitions the own zone ECU 22 to the sleep state. If the calculation unit 224 determines that the sleep conditions are not met, it proceeds to S230.

[0050] In S230, the calculation unit 224 determines whether or not an NM message has been received via any of the communication ports of the own zone ECU 22. The NM message here includes an NM message from a subordinate end ECU 23 or an integrated NM message transferred from an adjacent zone ECU 22. If the calculation unit 224 determines that an NM message has been received, the calculation unit 224 proceeds to S240, and if the calculation unit 224 determines that an NM message has not been received, the calculation unit 224 proceeds to S280.

[0051] In S240, the calculation unit 224 restarts the sleep timer. In S250, the calculation unit 224 determines whether the received NM message is a message to be stored. A message to be stored is an NM message received from a subordinate end-point ECU 23. If the calculation unit 224 determines that the received NM message is a message to be stored, it shifts the processing to S260. If the calculation unit 224 determines that the received NM message is not a message to be stored, it shifts the processing to S270. The reason why NM messages from other zone ECUs 22 are excluded from storage is as follows. That is, if NM messages from other zone ECUs 22 are included in the integration targets, an integrated NM message that targets activation of all nodes will ultimately be created. In other words, the integrated NM message will be sent back to all end-point ECUs 23 that were the senders of the NM messages, which may reduce the effect of suppressing unnecessary node activation.

[0052] In S260, the calculation unit 224 buffers the message to be stored in the reception buffer, and returns the process to S220. In S270, the calculation unit 224 transfers the non-storage target message, which is an NM message that is not a storage target message, to all communication ports of the own zone ECU 22 except for the communication port that received the non-storage target message, and returns the process to S220. Note that the non-storage target message is an integrated NM message transferred from another adjacent zone ECU 22.

[0053] In S280, the calculation unit 224 determines whether the buffering timer has timed out, i.e., whether the buffering period has ended. If the calculation unit 224 determines that the buffering timer has not timed out, the process proceeds to S290, and if the calculation unit 224 determines that the buffering timer has timed out, the process proceeds to S300.

[0054] In S290, the calculation unit 224 determines whether the receive buffer of the own zone ECU 22 is congested. For example, a state in which the receive buffer is less than 10% free may be determined to be congested. If the calculation unit 224 determines that the receive buffer is congested, it proceeds to S300. If the calculation unit 224 determines that the receive buffer is not congested, it returns to S220.

[0055] In S300, the calculation unit 224 restarts the buffering timer, that is, ends the current buffering period and starts a new buffering period. In S310, the calculation unit 224 determines whether or not there is an NM message stored in the reception buffer, and if there is an NM message stored, the process proceeds to S320, and if there is no NM message stored, the process returns to S220.

[0056] In S320, the calculation unit 224 generates an integrated NM message based on the NM messages accumulated in the receive buffer during the previously completed buffering period. Specifically, the calculation unit 224 extracts PN request information from each NM message stored in the receive buffer, and merges all of the extracted PN request information by performing a logical OR operation to generate the integrated PN request information. The NM message used to generate the integrated PN request information is deleted from the receive buffer. Then, a new NM message (i.e., an integrated NM message) is generated that includes the generated integrated PN request information.

[0057] In S330, the calculation unit 224 transfers the integrated NM message generated in S320 to all communication ports of the own zone ECU 22 except for the communication port through which the NM message that is the source of the integrated NM message was received, and returns the processing to S220.

[0058] The integration of NM messages in the zone ECU 22 will be described with reference to Fig. 6. Fig. 6 shows a case where the zone ECU_B in Fig. 1 receives NM messages containing NM request information from each of the subordinate terminal ECUs_D to F during the same buffering period. In normal times when the receiving buffer is not congested, an integrated NM message containing integrated NM request information obtained by performing a logical OR operation on the NM request information is generated after the buffering period has expired.

[0059] If congestion of the receiving buffer is detected during the buffering period, the buffering period is forcibly terminated, and an integrated NM message is generated according to the NM messages received at that time from the end ECU_D and end ECU_E.

[0060] The generated integrated NM message is transferred to all communication ports connected to other zone ECUs 22 adjacent to zone ECU_B. In contrast, in the conventional technology that does not use the integrated NM message, the three NM messages received from end ECUs_D to F are transferred to all communication ports connected to other zone ECUs 22 adjacent to zone ECU_B. In other words, in this case, the number of transferred NM messages is one-third compared to the conventional technology.

[0061] Furthermore, the zone ECU_B transfers the integrated NM message received from an adjacent zone ECU 22 (for example, zone ECU_A) to all communication ports of the zone ECU_B other than the communication port that received the integrated NM message.

[0062] If the zone ECU 22 does not receive either an NM message from a subordinate end ECU 23 or an integrated NM message from an adjacent zone ECU 22 for a certain period of time determined by the set value of the sleep timer, the zone ECU 22 transitions to a sleep state.

[0063] [1-5. Central ECU] The central ECU 21 is configured similarly to the zone ECU 22. However, if there is no end ECU 23 that is directly subordinate to the central ECU 21, the calculation unit 224 may omit the execution of the message integration process.

[0064] [1-6. Terminology] In this embodiment, the central ECU 21 and the zone ECU 22 correspond to relay nodes of the present disclosure, and the end ECU 23 corresponds to an end node of the present disclosure. In this embodiment, the PN request information corresponds to the activation request information of the present disclosure, the PN filter information corresponds to the activation filter information of the present disclosure, and the PN cluster corresponds to the activation cluster of the present disclosure. In this embodiment, the NM message corresponds to the activation message of the present disclosure, and the NM table corresponds to the activation table of the present disclosure. In this embodiment, the processes of S230 to S260 and S280 to S320 executed by the calculation unit 224 correspond to a message integration unit of the present disclosure, and the process of S330 corresponds to a port forwarding unit of the present disclosure.

[0065] [1-7.Effects] According to the first embodiment described above in detail, the following effects are achieved. (1a) In the in-vehicle network system 1, the zone ECU 22 does not simply forward the NM message received from the subordinate end ECU 23, but instead generates and forwards an integrated NM message that integrates multiple NM messages received during the buffering period. Therefore, the in-vehicle network system 1 can reduce the amount of NM message communication, and as a result, can reduce the processing load (e.g., unnecessary wake-ups, etc.) and power consumption required for the NM message in each ECU 2.

[0066] (1b) In the in-vehicle network system 1, when the zone ECU 22 detects congestion in the receive buffer, it forcibly ends the buffering period and generates an integrated NM message using the NM messages buffered at that time. Therefore, the in-vehicle network system 1 can prevent the receive buffer of the zone ECU 2 from overflowing, and ultimately prevent the NM messages from being discarded without being transferred due to the overflow.

[0067] (1c) In the in-vehicle network system 1, the connection between the zone ECU 22 and the subordinate terminal ECU 23 can be either a switched network or a bus network, so that cooperative NM operation between different protocols can be realized.

[0068] (1d) In the in-vehicle network system 1, the wireless device 3 is connected to the network via the zone ECU 22 and is configured as an SDV. SDV stands for Software-Defined Vehicle. Therefore, the in-vehicle network system 1 can not only support software downloads and updates via OTA, but also support wake-up instructions from outside the in-vehicle network system 1. OTA stands for Over The Air.

[0069] [2. Second Embodiment] [2-1. Differences from the first embodiment] The second embodiment has the same basic configuration as the first embodiment, so differences will be described below. Note that the same reference numerals as those in the first embodiment indicate the same configuration, and reference will be made to the preceding description.

[0070] The zone ECU 22 of the first embodiment described above outputs the integrated NM message to all communication ports except the receiving port. The receiving port refers to the communication port that received the integrated NM message or the communication port that received the NM message used to generate the integrated NM message. In contrast, the zone ECU 22a of the second embodiment differs from the first embodiment in that it uses an NM table to extract communication ports to which the integrated NM message needs to be forwarded and then forwards the integrated NM message only to the extracted communication ports.

[0071] [2-2.Configuration] As shown in FIG. 7, in the in-vehicle network system 1a, the ECUs 2 are divided into a central ECU 21a, a zone ECU 22a, and an end ECU 23.

[0072] The zone ECU 22 a includes a transmitter 221 , a receiver 222 , a transfer unit 223 , a calculator 224 , a memory 225 , and an update unit 226 . The storage unit 225 stores an NM table.

[0073] As shown in FIG. 8, the NM table is a collection of data linking port numbers, zone categories, node identification data, and PN filter information. The node identification data is information that uniquely identifies the end ECU 23. The node identification data may be any of a node ID, a MAC address, and an IP address. The NM table lists the node identification data for all end ECUs 23 that belong to the in-vehicle network system 1. In FIG. 8, the entry "End A" shown in the node identification data column indicates "end ECU_A." The same applies to FIGS. 9, 11, and 12 below.

[0074] The zone category is information indicating to which zone the end ECU 23 identified by the node identification data (hereinafter referred to as the end ECU 23 of interest) belongs (that is, to which zone ECU 22a it is connected).

[0075] The port number is information that identifies the communication port to which the target end ECU 23 is connected or the communication port that leads to the zone ECU 22a to which the target end ECU 23 is connected. In other words, the port number is information that indicates which communication port can be used to reach the target end ECU 23.

[0076] The PN filter information is a PNI that indicates to which PNC the target end ECU 23 belongs. As shown in FIG. 8, the NM table is set for each zone ECU 22, but all the zone ECUs 22 have the same contents for items other than the port number.

[0077] End ECU_A and end ECU_B identified by the node identification data belong to zone A, and therefore their zone category is set to A. End ECU_D and end ECU_E belong to zone B, and therefore their zone category is set to B.

[0078] Focusing on zone ECU_A, end ECU_A belonging to zone A is connected to communication port P1 of zone ECU_A, and end ECU_B is connected to communication port P2 of zone ECU_A. End ECU_D and end ECU_E belonging to zone B are connected to zone ECU_B, and zone ECU_B is connected to communication port P4 of zone ECU_A. Therefore, in the NM table of zone ECU_A, the port number associated with end ECU_A is set to P1. The port number associated with end ECU_B is set to P2. The port numbers associated with end ECU_D and end ECU_E are both set to P4.

[0079] Focusing on zone ECU_B, end ECU_A and end ECU_B belonging to zone A are connected to zone ECU_A, and zone ECU_A is connected to communication port P1 of zone ECU_B. Furthermore, end ECU_D and end ECU_E belonging to zone B are both connected to communication port P2 of zone ECU_B. Therefore, in the NM table of zone ECU_B, the port numbers associated with end ECU_A and end ECU_B are both set to P1, and the port numbers associated with end ECU_D and end ECU_E are both set to P2.

[0080] [2-3. Port forwarding] In each zone ECU 22a, the port transfer process of S270 and S330 in the message integration process executed by the calculation unit 224 shown in FIG. 5 differs from that of the first embodiment. That is, in this embodiment, when transferring an integrated NM message to each communication port, the NM table is used to extract the communication ports that require the transfer, and the integrated NM message is transferred to the extracted communication ports. Specifically, the logical product of the integrated PN request information indicated in the integrated NM message and the PN filter information of all end-point ECUs 23 indicated in the NM message is individually calculated. Then, end-point ECUs 23 for which the calculation result is non-zero are extracted, and the integrated NM message is transferred only to the communication ports indicated by the port numbers linked to the extracted end-point ECUs 23.

[0081] [2-4. Update section] The update unit 226 updates the NM table when a preset update condition is met. The update condition may include the addition of a new end ECU 23, the updating of a program installed in the end ECU 23, the acquisition of update data for the NM table from an external source, etc. In this embodiment, the update unit 226 is provided separately from the calculation unit 224, but the update unit 226 may also be realized as part of the processing executed by the calculation unit 224.

[0082] 7, a case will be described in which a new end ECU 23 (hereinafter, end ECU_G) is connected to the transmission path 4 connected to the communication port P2 of the zone ECU_B. When the end ECU_G is connected to the transmission path 4 and activated for some reason, it transmits an NM message including its own PN filter information as PN request information.

[0083] The update unit 226 of the zone ECU_B refers to its own NM table, and when it detects that the information of the end ECU_G is not registered in the NM table, it adds an item for the end ECU_G to the NM table, as shown in the upper part of Fig. 9. This addition is also transferred to the other zone ECUs 22, and an item for the end ECU_G is added to the NM table in each zone ECU. When adding an item for the end ECU_G to the NM table, in the zone ECU_B to which the end ECU 23 has been added under its control, the zone category is set to zone B to which it belongs, and the port number is set to P2, which indicates the communication port that received the NM message.

[0084] The other zone ECUs 22a that have received the update information (i.e., the item of the end ECU_G to be added) update their own NM tables in accordance with the update information. Specifically, in accordance with the zone category indicated in the update information, information linking the port number of the communication port to which the zone ECU_B corresponding to the zone category is connected or which leads to the zone ECU_B and the item of the end ECU_G that is the update information is added to the NM table.

[0085] As shown by reference symbol E2 in FIG. 7, a case will be described in which the PN filter information is changed by updating the program of the end ECU_D subordinate to the zone ECU_B. In this case, the end ECU_D transmits an NM message (hereinafter referred to as an update instruction) that includes the changed PN filter information and requests PNC learning (i.e., the PNL bit is enabled). In the zone ECU 22a that receives the update instruction, the update unit 226 updates the PN filter information for the end ECU_D that has been registered in its own NM table in accordance with the contents of the update instruction, as shown in the lower part of FIG. 9. The update unit 226 also transfers the update instruction to the other zone ECUs 22a. As a result, the NM tables in all zone ECUs 22a are updated.

[0086] Furthermore, the update unit 226 may be configured to, for example, when receiving update data for the NM table from the outside via the wireless device 3, update the NM table in accordance with the received update data. [2-5. Effects] According to the second embodiment described above in detail, in addition to the effects (1a) to (1d) of the first embodiment described above, the following effects are also achieved.

[0087] (2a) The zone ECU 22a uses the NM table to transfer the integrated NM message only to the communication port leading to the activation target end ECU 23. Therefore, the in-vehicle network system 1a can further reduce the amount of communication of NM messages.

[0088] (2b) According to the in-vehicle network system 1a, the NM table held by the zone ECU 22a is updated in response to the addition of an end ECU 23 or an update of a program, so that the system can be flexibly adapted to changes.

[0089] 3. Third Embodiment [3-1. Differences from the second embodiment] The third embodiment has the same basic configuration as the second embodiment, and therefore the differences will be described below. Note that the same reference numerals as those in the first and second embodiments indicate the same configurations, and reference will be made to the preceding description.

[0090] In the first embodiment described above, the case where there are two zone ECUs 22 that need to be relayed between the terminal ECUs 23 has been described, but there may be three or more zone ECUs 22 that need to be relayed. For example, there may be a plurality of zone ECUs 22 that are hierarchically connected within one zone.

[0091] As shown in FIG. 10, the in-vehicle network system 1b includes a zone ECU_AA that controls a zone AA, which is part of zone A, under a zone ECU_A, and an end ECU_AA under the zone ECU_AA. The zone ECU_AA is connected to a communication port P5 of the zone ECU_A. The zone ECU_A is connected to a communication port P4 of the zone ECU_AA, and the end ECU_AA is connected to a communication port P1 of the zone ECU_AA. The in-vehicle network system 1b is similar to the in-vehicle network system 1a of the second embodiment, except that an end ECU 23 (only the end ECU_AA is shown in FIG. 10) under the zone ECU_AA and the zone ECU_AA is added. That is, in FIG. 10, the central ECU 21, the zone ECU_C, and some of the end ECUs 23 are omitted from the illustration.

[0092] In the in-vehicle network system 1b shown in FIG. 10, the NM tables of the zone ECU_AA, the zone ECU_A, and the zone ECU_B are set as shown in FIG. In the NM table of the zone ECU_AA, the information of all the end ECUs 23 connected to the other zone ECUs 22 is linked to the port number P4. The zone category of the end ECU_AA is set to AA, and the information of the end ECU_AA is linked to the port number P1.

[0093] In the NM tables of zone ECU_A and zone ECU_B, information on end ECU_AA is added to the contents shown in Fig. 8. However, the information on end ECU_AA is linked to port number P5 in the NM table of zone ECU_A, and to port number P1 in the NM table of ECU_B.

[0094] [3-2. Example of operation] For example, if an NM message indicating PN request information including the PN cluster of the end ECU_AA is transmitted from the end ECU_D, the PN request information of the integrated message generated by the zone ECU_B will naturally include the PN cluster of the end ECU_AA. Therefore, this integrated NM message is transferred to at least communication port P1 in accordance with the information of the end ECU_AA in the NM table, and is received by the zone ECU_A.

[0095] The integrated NM message transferred to zone ECU_A is retransferred to at least communication port P5 in accordance with the information of end ECU_AA in the NM table of zone ECU_A, and is received by zone ECU_AA.

[0096] The integrated NM message transferred to the zone ECU_AA is retransferred to at least the communication port P1 in accordance with the information of the end ECU_AA in the NM table of the zone ECU_AA, and is received by the end ECU_AA.

[0097] [3-3. Effects] According to the third embodiment described above in detail, the effects (1a) to (1d) of the first embodiment and the effects (2a) and (2b) of the second embodiment are achieved, and further, the following effects are achieved.

[0098] (3a) In the in-vehicle network system 1b, the zone ECUs 22 have a hierarchical structure in which multiple stages are connected. This makes it possible to realize a network structure suitable for vehicles with a long overall length, such as commercial trucks.

[0099] 4. Other Embodiments Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms.

[0100] (4a) In the above embodiment, the radio 3 is provided separately from the zone ECU 22. However, the radio 3 may be built into one or more of the zone ECUs 22. (4b) In the above embodiment, the network topology connecting the zone ECU 22 and the subordinate terminal ECU 23 is a mixture of a switched network and a bus network. However, the network topology may be unified into either one of the two.

[0101] (4c) In the above embodiment, when buffer congestion is detected, the buffering period is forcibly terminated, thereby preventing NM messages from being discarded due to receive buffer overflow. Instead of buffering NM messages, discarding of NM messages may be prevented by generating an integrated NM message as follows. That is, NM request information is immediately extracted from the received NM message and stored in a work area of ​​memory. Each time a new NM message is received, the contents of the work area are updated with the result of a logical OR operation between the NM request information extracted from the received NM message and the NM request information stored in the work area. When the buffering period ends, an integrated NM message may be generated using the NM request information stored in the work area and transferred to each communication port. In this case, a new work area is required to update the NM request information, but since there is no need to store the entire received NM message during the buffering period, receive buffer overflow can be prevented.

[0102] (4d) In the above embodiment, each zone ECU 22a uses one NM table. However, as shown in FIG. 12, multiple types of NM tables may be prepared in advance depending on the equipment status of the vehicle equipped with the in-vehicle network system 1a, such as the destination and vehicle grade. In this case, the NM table to be used can be selected, for example, at the time of shipping. The NM table may be selected by a dedicated physical switch or by an external instruction via the wireless device 3. Alternatively, the equipment status of the vehicle may be identified from information flowing through the in-vehicle network system 1a, and an NM table may be automatically selected.

[0103] (4e) The computing units 224, 234 and the methods described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the computing units 224, 234 and the methods described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the computing units 224, 234 and the methods described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium. The methods for implementing the functions of the computing units 224, 234 do not necessarily need to include software; all of the functions may be implemented using one or more hardware devices.

[0104] (4f) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0105] (4g) In addition to the above-described in-vehicle network system, the present disclosure can also be realized in various forms, such as the zone ECU 22 and terminal ECU 23 that are components of the in-vehicle network system, a program for causing a computer to function as the zone ECU 22 or the terminal ECU 23, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and a method for transferring a startup message.

[0106] [5. Technical Ideas Disclosed in the Present Specification] [Item 1] a plurality of relay nodes (21, 22) each having a plurality of communication ports (Pi); a plurality of terminal nodes (23) each connected to any one of the plurality of relay nodes; Equipped with each of the plurality of communication ports of the relay node is connected to another relay node or a terminal node subordinate to the relay node; the terminal node includes a wake-up unit (233) configured to transition from a sleep state to a wake-up state when a wake-up condition is satisfied within the terminal node, and to transmit a wake-up message including wake-up request information indicating an activation cluster to which the terminal node belongs, and to transition from the sleep state to the wake-up state when the terminal node receives the wake-up message including the wake-up request information indicating the activation cluster to which the terminal node belongs; The relay node a message integration unit (224: S230-260, S280-S320) configured to generate integrated activation request information by merging the activation request information indicated in the integration target message, which is the activation message received from the subordinate end node, during a predetermined buffering period, and to generate an integrated activation message, which is the activation message including the integrated activation request information; a port forwarding unit (224: S330) configured to forward the integrated startup message generated by the message integration unit to a communication port other than the communication port through which the message to be integrated is received; Equipped with In-vehicle network system.

[0107] [Item 2] The in-vehicle network system according to item 1, each of the plurality of relay nodes includes a startup table; The startup table lists, for all of the plurality of terminal nodes, information that associates information identifying the terminal nodes, startup filter information that lists the startup clusters to which the terminal nodes belong, information that identifies the relay nodes to which the terminal nodes are connected, and information that indicates the communication ports leading to the terminal nodes; the port forwarding unit is configured to compare the startup request information indicated in the integrated startup message with the startup filter information indicated in the startup table, so that the startup cluster indicated in the startup request information identifies the end node indicated in the startup filter information, and forward the integrated startup message to all the communication ports leading to the identified end node. In-vehicle network system.

[0108] [Item 3] The in-vehicle network system according to item 2, The system further includes an update unit (226) that updates the startup table when a predetermined update condition is met. In-vehicle network system.

[0109] [Item 4] Item 3. The in-vehicle network system according to item 3, the update condition includes receiving the invocation message from the terminal node that is not registered in the invocation table; In-vehicle network system.

[0110] [Item 5] The in-vehicle network system according to item 3 or 4, the update condition includes receiving an update instruction indicating update data for the invocation table from the terminal node registered in the invocation table; In-vehicle network system.

[0111] [Item 6] Item 3 to Item 5: An in-vehicle network system according to any one of items 3 to 5, the update condition includes obtaining update data for the startup table from outside the in-vehicle network system. In-vehicle network system.

[0112] [Item 7] The in-vehicle network system according to any one of items 2 to 6, the relay node is configured to have a plurality of types of the startup tables and to select and use one of the plurality of types of the startup tables according to the state of equipment of a vehicle equipped with the in-vehicle network system; In-vehicle network system.

[0113] [Item 8] A relay node that forms an in-vehicle network system together with other relay nodes (22) and a plurality of terminal nodes (23), and has a plurality of communication ports (Pi) to which the other relay nodes or the terminal nodes subordinate to the relay node itself are connected, a message integration unit (224: S230-260, S280-S320) configured to generate integrated activation request information by merging activation request information indicated in integration target messages, which are activation messages received from the subordinate end nodes during a predetermined buffering period, and to generate an integrated activation message including the activation request information; a port forwarding unit (224: S330) configured to forward the integrated startup message generated by the message integration unit to a communication port other than the communication port through which the message to be integrated is received; Equipped with the activation request information is information indicating an activation cluster to which the leaf node that is the transmission source of the activation message belongs, The wake-up message is transmitted from the end node when a preset wake-up condition is satisfied in the end node, and when the wake-up cluster to which the receiving end node, which is the end node that received the wake-up message, belongs is indicated in the wake-up request information included in the wake-up message, the receiving end node is transitioned from a sleep state to a wake-up state. Relay node.

[0114] [Item 9] A method for transferring a startup message in a relay node that forms an in-vehicle network system together with other relay nodes (22) and a plurality of terminal nodes (23) and has a plurality of communication ports (Pi) to which the other relay nodes or the terminal nodes subordinate to the relay node (22) are connected, During a predetermined buffering period, merging activation request information indicated in integration target messages, which are activation messages received from the subordinate end nodes, to generate integrated activation request information, and generating an integrated activation message including the activation request information (S230 to S260, S280 to S320); Transferring the generated integrated activation message to a communication port other than the communication port through which the integration target message was received (S330); Including, the activation request information is information indicating an activation cluster to which the leaf node that is the transmission source of the activation message belongs, The wake-up message is transmitted from the terminal node when a preset wake-up condition is satisfied in the terminal node, and when the wake-up cluster to which the receiving terminal node, which is the terminal node that received the wake-up message, belongs is indicated in the wake-up request information included in the wake-up message, the receiving terminal node is transitioned from a sleep state to a wake-up state. How the startup message is forwarded. [Explanation of symbols]

[0115] 1, 1a, 1b... in-vehicle network system, 2... ECU, 3... radio, 4... transmission path, 21, 21a... central ECU, 22, 22a... zone ECU, 23... terminal ECU, 221, 231... transmitter, 222, 232... receiver, 223... transfer unit, 224, 234... calculation unit, 225... memory unit, 226... update unit, 233... startup unit.

Claims

1. a plurality of relay nodes (21, 22) each having a plurality of communication ports (Pi); a plurality of terminal nodes (23) each connected to any one of the plurality of relay nodes; Equipped with each of the plurality of communication ports of the relay node is connected to another relay node or a terminal node subordinate to the relay node; the terminal node includes a wake-up unit (233) configured to transition from a sleep state to a wake-up state when a wake-up condition is satisfied within the terminal node, and to transmit a wake-up message including wake-up request information indicating an activation cluster to which the terminal node belongs, and to transition from the sleep state to the wake-up state when the terminal node receives the wake-up message including the wake-up request information indicating the activation cluster to which the terminal node belongs; The relay node a message integration unit (224: S230-260, S280-S320) configured to generate integrated activation request information by merging the activation request information indicated in the integration target message, which is the activation message received from the subordinate end node, during a predetermined buffering period, and to generate an integrated activation message, which is the activation message including the integrated activation request information; a port forwarding unit (224: S330) configured to forward the integrated startup message generated by the message integration unit to a communication port other than the communication port through which the integration target message is received; Equipped with In-vehicle network system.

2. 2. The in-vehicle network system according to claim 1, each of the plurality of relay nodes includes a startup table; The startup table lists, for all of the plurality of terminal nodes, information that associates information identifying the terminal nodes, startup filter information that lists the startup clusters to which the terminal nodes belong, information that identifies the relay nodes to which the terminal nodes are connected, and information that indicates the communication ports leading to the terminal nodes; the port forwarding unit is configured to compare the startup request information indicated in the integrated startup message with the startup filter information indicated in the startup table, so that the startup cluster indicated in the startup request information identifies the end node indicated in the startup filter information, and forward the integrated startup message to all the communication ports leading to the identified end node. In-vehicle network system.

3. 3. The in-vehicle network system according to claim 2, The system further includes an update unit (226) that updates the startup table when a predetermined update condition is met. In-vehicle network system.

4. 4. The in-vehicle network system according to claim 3, the update condition includes receiving the invocation message from the terminal node that is not registered in the invocation table; In-vehicle network system.

5. 4. The in-vehicle network system according to claim 3, the update condition includes receiving an update instruction indicating update data for the invocation table from the terminal node registered in the invocation table; In-vehicle network system.

6. 4. The in-vehicle network system according to claim 3, the update condition includes obtaining update data for the startup table from outside the in-vehicle network system. In-vehicle network system.

7. 3. The in-vehicle network system according to claim 2, the relay node is configured to have a plurality of types of the startup tables and to select and use one of the plurality of types of the startup tables according to the state of equipment of a vehicle equipped with the in-vehicle network system; In-vehicle network system.

8. A relay node that forms an in-vehicle network system together with other relay nodes (22) and a plurality of terminal nodes (23), and has a plurality of communication ports (Pi) to which the other relay nodes or the terminal nodes subordinate to the relay node itself are connected, a message integration unit (224: S230-260, S280-S320) configured to generate integrated activation request information by merging activation request information indicated in integration target messages, which are activation messages received from the subordinate end nodes during a predetermined buffering period, and to generate an integrated activation message including the activation request information; a port forwarding unit (224: S330) configured to forward the integrated startup message generated by the message integration unit to a communication port other than the communication port through which the integration target message is received; Equipped with the activation request information is information indicating an activation cluster to which the leaf node that is the transmission source of the activation message belongs, The wake-up message is transmitted from the end node when a preset wake-up condition is satisfied in the end node, and when the wake-up cluster to which the receiving end node, which is the end node that received the wake-up message, belongs is indicated in the wake-up request information included in the wake-up message, the receiving end node is transitioned from a sleep state to a wake-up state. Relay node.

9. A method for transferring a startup message in a relay node that forms an in-vehicle network system together with other relay nodes (22) and a plurality of terminal nodes (23) and has a plurality of communication ports (Pi) to which the other relay nodes or the terminal nodes subordinate to the relay node itself are connected, During a predetermined buffering period, merging activation request information indicated in integration target messages, which are activation messages received from the subordinate end nodes, to generate integrated activation request information, and generating an integrated activation message including the activation request information (S230 to S260, S280 to S320); Transferring the generated integrated activation message to a communication port other than the communication port through which the integration target message was received (S330); Including, the activation request information is information indicating an activation cluster to which the leaf node that is the transmission source of the activation message belongs, The wake-up message is transmitted from the end node when a preset wake-up condition is satisfied in the end node, and when the wake-up cluster to which the receiving end node, which is the end node that received the wake-up message, belongs is indicated in the wake-up request information included in the wake-up message, the receiving end node is transitioned from a sleep state to a wake-up state. How the startup message is forwarded.

Images